본문 바로가기
IT적응기

챗GPT 프롬프트, 잘 쓰는 사람과 못 쓰는 사람의 결정적 차이

by IT적응기 2026. 5. 9.

챗GPT 프롬프트, 잘 쓰는 사람과 못 쓰는 사람의 결정적 차이 참조 이미지
잘 쓰는 사람과 못 쓰는 사람의 결정적 차이

챗GPT 프롬프트, 잘 쓰는 사람과 못 쓰는 사람의 결정적 차이

개발 현장에서 15년 가까이 지내다 보면 도구를 다루는 사람과 도구에 끌려다니는 사람의 차이가 눈에 들어온다. 예전에는 그 기준이 IDE를 얼마나 잘 쓰느냐, 디버거를 얼마나 능숙하게 다루느냐였다면, 요즘은 챗GPT 프롬프트를 어떻게 쓰느냐가 그 자리를 대신하고 있다. 같은 질문을 해도 누구는 쓸 수 있는 답을 받아오고, 누구는 "이건 내가 원하는 게 아닌데"를 반복한다. 그 차이가 뭔지, 경험을 바탕으로 정리해봤다.

못 쓰는 사람은 질문을 던지고, 잘 쓰는 사람은 상황을 설명한다

API 연동 오류가 났을 때 "왜 에러나?"라고 물으면 AI는 일반적인 원인 목록을 나열한다. 쓸모가 없진 않지만, 내 상황과 맞지 않는 경우가 절반이다. 반면 "Python 3.11에서 requests 라이브러리로 POST 요청을 보내는데 ConnectionError가 뜬다. 로컬에서는 되는데 도커 컨테이너 안에서만 안 된다"라고 쓰면 답변의 밀도가 확 달라진다.

마치 응급실에서 "어디가 아파요?"와 "어제 저녁 7시부터 오른쪽 아랫배가 콕콕 찌르는 것처럼 아파요"의 차이다. 의사가 후자에서 훨씬 더 정확한 진단을 내리는 건 당연하다. AI도 마찬가지다. 맥락이 없으면 일반론만 나온다.

현장에서 느낀 단점은 처음엔 상황 설명을 길게 쓰는 게 귀찮다는 거다. 타이핑하는 데 시간이 걸린다. 그런데 그 30초를 쓰면 뒤에서 5분짜리 엉뚱한 답을 걸러내는 시간을 아낀다. 결국 총 시간은 줄어든다.

못 쓰는 사람은 답을 요청하고, 잘 쓰는 사람은 역할을 부여한다

"코드 리뷰해줘"와 "너는 10년 경력의 시니어 백엔드 개발자야. 이 코드를 코드 품질, 성능, 보안 세 가지 관점으로 리뷰해줘. 각 항목에서 문제점과 개선 방법을 명확하게 써줘"는 출력 품질이 완전히 다르다. 전자는 일반적인 코멘트가 나오고, 후자는 내가 원하는 시각으로 정리된 분석이 나온다.

이걸 처음 깨달은 건 문서 작성 때였다. 기술 명세서를 고객사용으로 바꿔야 했는데, "이 문서를 쉽게 써줘"보다 "이 문서를 IT 비전공 중간관리자가 읽는다고 가정하고, 전문 용어를 모두 풀어서 다시 써줘"가 훨씬 목적에 맞는 결과를 냈다. 역할을 지정하는 건 AI에게 렌즈를 씌우는 거다. 어떤 렌즈를 쓰느냐가 결과물의 초점을 결정한다.

단점은 역할 설명이 너무 구체적이면 오히려 그 역할 범위에 갇혀서 필요한 말을 안 하는 경우가 생긴다. 균형 잡기가 필요하다.

못 쓰는 사람은 한 번에 다 받으려 하고, 잘 쓰는 사람은 단계를 나눈다

처음 챗GPT를 쓸 때 나도 그랬다. "이 프로젝트 전체 설계해줘"라고 던졌다가 너무 표면적인 답이 돌아와서 실망했다. 마치 뷔페에서 접시 하나에 모든 음식을 다 올려놓으려는 것처럼, 다 넣으면 정작 제대로 담기는 게 없다.

잘 쓰는 사람은 단계를 나눈다. "먼저 요구사항 분석만 해줘. 다음에 DB 설계 물어볼게." 이런 식으로 쪼개면 각 단계에서 깊이 있는 답이 나온다. 특히 복잡한 시스템 설계나 긴 글쓰기에서 이 방식이 확실히 더 좋은 결과를 낸다. 현장에서 느낀 건, 이게 결국 내가 생각을 정리하는 과정과 같다는 거다. 나 스스로도 문제를 잘게 쪼개서 생각해야 해결책이 보이는 것처럼, AI에게도 같은 방식이 통한다.

못 쓰는 사람은 첫 답을 그대로 쓰고, 잘 쓰는 사람은 대화를 이어간다

챗GPT는 채팅 도구다. 그런데 많은 사람이 검색 엔진처럼 쓴다. 한 번 치고, 답 받고, 끝. 이 방식으로는 진짜 가치를 절반도 못 뽑는다.

첫 답이 80점이라면 "이 부분은 좀 더 구체적으로 써줘", "이 예시를 실제 코드로 보여줘", "이 내용을 표로 정리해줘" 같은 후속 요청으로 95점까지 끌어올릴 수 있다. 마치 목수가 대패로 한 번에 끝내는 게 아니라, 거칠게 다듬고, 사포 치고, 마감재 바르는 과정처럼 반복 작업이 품질을 만든다.

이게 현장에서 특히 문서 작업에서 빛났다. 첫 버전 받고, 톤 조절 요청하고, 불필요한 부분 삭제 요청하고, 마지막으로 분량 조정하면 혼자 처음부터 썼을 때보다 훨씬 나은 결과물이 나왔다.

못 쓰는 사람은 AI를 믿고, 잘 쓰는 사람은 AI를 검증한다

이게 제일 중요하다. AI가 자신 있게 쓴 내용이 틀린 경우가 생각보다 잦다. 특히 최신 정보나 구체적인 수치가 들어가는 경우. 나도 초반에 AI가 알려준 라이브러리 버전 정보를 그대로 썼다가 호환성 문제로 반나절을 날린 적 있다.

잘 쓰는 사람은 AI 결과물을 초안으로 본다. 방향을 잡는 데 쓰고, 세부 사실은 공식 문서나 직접 실행으로 확인한다. AI는 만능이 아니라 초고 작성기에 가깝다. 그 한계를 인정하고 검증 단계를 유지하는 것, 그게 실무에서 챗GPT를 제대로 쓰는 사람과 쓰는 척하는 사람의 결정적 차이다.

나는 왜 뒤늦게 이걸 깨달았나: 경험에서 나온 반성

솔직히 말하면, 챗GPT를 처음 접했을 때 "이건 별거 없는 검색엔진 고도화 버전이네"라고 생각했다. 개발자 특유의 의심병이 도구에 대한 선입견을 만들었다. 그 선입견 때문에 제대로 써보지 않은 채 한동안 그냥 지나쳤다.

다시 잡게 된 건 현장 프로젝트에서 일정이 터졌을 때였다. 문서 작업 마감이 이틀 남았는데 혼자 감당이 안 되는 분량이었다. 그때 반신반의하면서 프롬프트를 구체적으로 짜서 써봤는데, 결과물이 생각보다 훨씬 쓸 만했다. 그게 출발이었다.

이후로 프롬프트를 쌓아가면서 알게 된 건, 이게 결국 커뮤니케이션이라는 거다. 좋은 프롬프트는 좋은 업무 지시서와 같다. 명확하고, 맥락이 있고, 기대치가 구체적이다. 15년간 후배한테 일 지시하면서 배운 것들이 프롬프트 작성에 그대로 적용됐다. AI가 새로운 기술을 요구하는 게 아니라, 원래 잘해야 했던 커뮤니케이션 역량을 다른 방향으로 쓰는 것이었다.

이 깨달음이 있고 나서부터는 프롬프트 실패를 AI 탓으로 돌리지 않게 됐다. "내가 질문을 잘못 했구나"라고 먼저 되돌아본다. 그 태도 하나가 결과물의 질을 꾸준히 끌어올리는 가장 실질적인 방법이었다.

출처 및 검색 태그

  • 참고 출처 경로: OpenAI 프롬프트 엔지니어링 공식 가이드 (https://platform.openai.com/docs/guides/prompt-engineering),
  • Anthropic 프롬프트 가이드 (https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
  • Learn Prompting (https://learnprompting.org)

소개 및 문의 · 개인정보처리방침 · 면책조항

© 2026 깜짝,황금이 아빠 IT적응기

서치어드바이저