프롬프트 엔지니어링의 신화: 결국 명확한 소통의 문제다

한 가지 사고 실험을 해보자. 동료에게 다음과 같은 슬랙(Slack) 메시지를 보낸다고 상상해 보자:

“저기, 시간 되실 때 이것 좀 봐주실 수 있나요? 괜찮은지 확인만 한번 해보고 싶어서요.”

이제 똑같은 문장을 ChatGPT에 그대로 붙여넣는다고 생각해 보자.

두 경우 모두 어떤 답변이든 돌아올 것이다. 하지만 둘 중 어느 쪽도 당신이 실제로 필요로 하는 것을 주지 못한다. 문제는 상대방이 누구인가에 있지 않다. 문제는 메시지 그 자체에 있다.

’프롬프트 엔지니어링’이라는 거대한 산업 전체가 잘못된 전제 위에 세워져 있다. 바로 LLM과 대화하는 데는 사람과 대화하는 것과는 완전히 구별되는 특별한 기술이 필요하다는 착각이다. 그렇지 않다. ChatGPT로부터 훌륭한 결과를 이끌어내는 기술—명확한 의도, 구체적인 제약 조건, 구조화된 요청, 명확한 예시—은 지난 세월 동안 인간으로부터 좋은 결과를 이끌어냈던 기술과 정확히 같다. 우리는 그동안 그저 게을렀을 뿐이다. 인간은 사회적 추론으로 행간의 빈틈을 메워주지만, LLM은 그렇지 않기 때문이다.

해결책은 두 가지 소통 스타일을 따로 배우는 것이 아니다. 단 하나의 제대로 된 소통 습관을 익히는 것이다.

간극은 생각보다 훨씬 좁다

인간은 말투, 상황 맥락, 그리고 지금까지 맺어온 관계의 역사를 통해 상대의 목표를 추론한다. LLM은 그렇지 못하다. 차이는 그것뿐이다. 하지만 현실을 직시해야 한다. 인간 역시 이 작업을 불완전하게 수행한다. 사람들은 끊임없이 잘못 넘겨짚는다. 요점을 놓치고, 엉뚱한 질문에 답하며, 요구하지도 않은 것을 내놓는다. 이메일 한 통으로 끝났을 무의미한 회의에 참석해 본 사람이라면 누구나 겪어본 일이다.

실패 모드는 본질적으로 같다. 단지 LLM에서 그 결과가 더 빠르게 드러날 뿐이다.

동료가 명확한 요구사항 없이 긴 글을 던져줄 때, 당신은 clarification 질문을 던지거나 스스로 짐작해 보며 결국 그가 무엇을 원하는지 알아내려 한다. LLM도 똑같이 행동한다. 다만 LLM의 ’짐작’은 가능한 모든 응답에 대한 확률 분포에 기반할 뿐이며, 명확한 신호가 없으면 가장 그럴듯하고 뻔한 답변으로 기본값을 설정한다. 반면 인간은 가장 호의적인 해석을 기본값으로 삼는다. 그러나 둘 다 과녁을 빗나가기는 마찬가지다.

따라서 LLM과의 소통을 바로잡는 기법은 인간과의 소통 역시 바로잡아 준다. 단지 그 교정 효과가 훨씬 더 즉각적으로 체감될 뿐이다.

어디서나 통하는 여섯 가지 습관

이것들은 결코 프롬프트 엔지니어링 꼼수가 아니다. 뛰어난 테크니컬 라이터, 군사 작전 전달자, 그리고 유능한 관리자들이 이미 오래전부터 실천해 온 소통의 기본 원칙이다.

1. 요구사항(Ask)을 맨 앞에 두라

요청을 맨 위에 쓰고, 맥락은 그 아래에 두라. 군대에서 사용하는 BLUF(Bottom Line Up Front, 핵심 결론 우선) 방식이며, 이는 컴퓨터가 발명되기 훨씬 전부터 존재했다.

모호한 표현: “우리가 3개월 동안 이 프로젝트를 진행해 왔는데 클라이언트가 자꾸 변덕을 부리고 팀원들은 지쳐가고 있어서 일정 관련해서 어떻게 해야 할지 도움이 좀 필요합니다.”

명확한 표현: “프로젝트 일정 조정에 도움이 필요합니다. 클라이언트가 3개월 동안 범위를 두 번 변경했고 팀은 포화 상태입니다. 세 번째 범위 변경 가능성을 고려한 수정된 6주 일정 계획안을 작성해 주십시오.”

슬랙에서든 ChatGPT에서든 똑같이 작동한다. 두 청자 모두 당신이 진정으로 원하는 것이 무엇인지 알기 위해 장문의 서론 세 단락을 헤매고 싶어 하지 않는다.

2. 필요한 만큼의 맥락만 주고, 거기서 멈추라

사람은 상대가 장황하게 늘어놓으면 집중을 잃는다. LLM 역시 입력이 길어지면 주의(attention)가 분산된다. 컨텍스트가 늘어날수록 모델의 집중도가 떨어진다는 점은 트랜스포머 어텐션 메커니즘의 잘 알려진 특성이다. 특정 요청에 반드시 필요한 맥락만 제공하라. 동료에게 이메일을 쓸 때 그의 전 직장 이력까지 모두 첨부하지 않는 것처럼, LLM에게도 그렇게 하지 말아야 한다.

가장 이상적인 지점은 둘 다 동일하다. 배경 설명 한두 문장, 그리고 바로 핵심 요구사항이다.

3. 모호한 단어를 구체적인 단어로 대체하라

“더 좋게 만들어줘”라는 말은 동료에게도, LLM에게도 완전히 무의미하다. “도입부를 두 문장으로 줄이고 세 번째 문단 뒤에 구체적인 사례를 하나 추가해 줘”라는 요청은 둘 모두에게 즉각적으로 작동한다.

어디서나 실패를 부르는 단어들이 있다: 더 좋게, 더 멋지게, 더 전문적으로, 개선해 줘, 향상해 줘, 좋은, 나쁜. 이는 주관적인 가치 판단일 뿐이며, 사람마다 그 의미가 다르고 모델이 실행될 때마다 해석이 달라진다.

해결책은 디자이너에게 말하든 Claude에게 말하든 같다. ’더 낫다’는 것이 구체적으로 무엇을 의미하는지 정의하는 것이다. “더 전문적으로”는 “구어체 표현을 제거하고, 축약어를 풀어서 쓰며, 정중한 인사말을 추가해 줘”가 된다. “더 매력적으로”는 “도입부에 놀라운 통계 수치를 하나 넣고 단락을 3문장 이내로 줄여줘”가 된다.

구체성은 일종의 근육이다. LLM을 상대로 훈련할수록, 사람을 대할 때도 자연스럽게 발휘된다.

4. 제약 조건을 창의적 도구로 활용하라

“좋은 글 한 편 써줘”는 상대를 마비시킨다. “물병에 대한 150단어 분량의 제품 설명서를 써줘. 톤앤매너는 냉소적이면서도 절제된 톤으로”라는 지시는 상대에게 해방감을 준다.

제약 조건은 사람의 집중을 돕고 LLM에게는 명확한 과녁을 제공한다. 150단어 제한은 족쇄가 아니라 프레임(frame)이다. 글을 쓰는 주체(사람이든 기계든)에게 어떤 종류의 결과물을 기대하는지 정확히 알려준다. 제약 조건이 명시된 크리에이티브 브리프는 곧 훌륭한 프롬프트다. 잘 다듬어진 프롬프트는 훌륭한 크리에이티브 브리프와 같다. 구조도 같고 기능도 같다.

5. 말로만 설명하지 말고 보여주라 (Show, don’t just tell)

“이런 느낌으로: [예시]“라는 표현은 현존하는 가장 강력한 소통 도구다. 디자인 리뷰에서는 이를 모델링(modeling)이라 부르고, LLM 연구에서는 퓨샷 프롬프팅(few-shot prompting)이라 부른다. 메커니즘도 같고 결과도 같다.

잘 고른 예시 하나는 설명 한 문단을 대체한다. 당신이 무슨 말을 하는지 머릿속에 그리지 못하는 동료에게도 효과적이고, 확률 분포 속에서 당신의 의도를 해석해야 하는 LLM에게도 효과적이다. 예시는 추상적인 생각을 구체화한다. 모호성을 단숨에 해결한다. 그것은 보편적인 명확화 도구다.

6. 대화를 통해 반복 개선하라

첫 번째 요청만으로 동료에게서 완벽한 답변을 얻는 경우는 드물다. 후속 질문을 하고, 명확히 다듬으며, 방향을 재조정한다. LLM에게도 똑같이 하라.

“내용은 좋은데, 어조가 너무 격식체네요. 대화하듯 편하게 바꿔주세요. 그리고 세 번째 항목은 비용 절감과 관련된 내용으로 교체해 주세요.” 이 피드백은 사람과 기계 모두에게 완벽하게 통한다. 더 정확하게 방향을 잡아줄수록 필요한 반복 횟수는 줄어든다.

완벽한 프롬프트를 짜겠다고 20분을 허비하지 마라. 의도를 말하고, 핵심 맥락을 주고, 전송하라. 돌아온 결과를 평가하라. 정확하게 방향을 틀어주어라. 그리고 멈춰야 할 타이밍을 알아야 한다. 수확 체감의 법칙은 엄연히 존재하며, 90% 정도 완성되었을 때는 스스로 가져와 마무리 손질을 하는 것이 훨씬 빠르다.

4초의 필터

누군가에게—사람이든 LLM이든—요청을 던지기 전에 다음 네 가지 질문을 머릿속으로 빠르게 스캔해 보라. 일주일만 지나면 자동으로 몸에 밴다.

내가 실제로 필요한 것은 무엇인가? 원하는 최종 결과물과 지금 던지려는 질문을 분리해 보라. 때로는 방금 하려던 요청이 진정 원하던 결과에 전혀 도움이 되지 않기도 한다.

듣는 이가 알아야 할 것은 무엇이며, 불필요한 정보는 무엇인가? 배경 설명을 핵심적인 것만 남기고 덜어내라. 동료가 이미 프로젝트 상황을 알고 있다면 다시 장황하게 설명하지 마라. LLM과 새 대화를 시작할 때도 오직 이번 요청에 필요한 맥락만 포함하라.

오해의 소지가 있는가? 지칭 대상이 불분명한 대명사(“그거 고쳐줘”), 모호한 범위(“전부 다”), 주관적인 형용사(“좋게”, “전문적으로”)를 찾아내어 구체적으로 바꾸어라.

원하는 것을 얻었는지 어떻게 알 수 있는가? 명확한 성공 기준(success criterion)이 있어야 답변을 제대로 평가할 수 있다. 이는 질문 자체를 정밀하게 다듬도록 강제하여, 애초에 좋은 답변이 나올 수밖에 없게 만든다.

전과 후 비교

다음 예시들은 동일한 의도가 두 가지 방식으로 표현된 것을 보여준다. ‘개선 후’ 버전은 슬랙으로 동료에게 보내든, LLM 프롬프트에 넣든 완벽하게 똑같은 효과를 발휘한다.

모호함: “제 발표 자료 좀 보시고 어떤지 말씀해 주실래요?”

명확함: “이 발표 자료의 4~7번 슬라이드를 검토해 주실 수 있나요? 비전공자가 보기에 데이터 흐름이 명확하지 않을까 걱정됩니다. 헷갈리는 부분이 있다면 표시해 주시고 필요하다면 구조 재배치를 제안해 주세요.”

모호함: “경쟁사 X 신기능에 관한 글을 읽었는데 저번 분기에 우리가 냈던 아이디어가 생각나더라고요. 다시 한번 검토해 보면 좋을 것 같은데 어떻게 생각하시는지 정리 좀 해주시겠어요?”

명확함: “3분기 기능 아이디어를 다시 검토해 보려 합니다. 경쟁사 X가 방금 비슷한 기능을 출시했습니다. 우리가 우선순위를 재조정할 가치가 있는지 판단할 수 있도록, 그들의 접근 방식과 우리의 방식을 비교하는 1페이지 분량의 요약본을 작성해 주시겠습니까?”

모호함: “홈페이지에 들어갈 문구 좀 써줘.”

명확함: “홈페이지 히어로 섹션(첫 화면) 문구를 작성해 줘. 타깃: 자동화 도구를 한 번도 써보지 않은 소상공인. 톤: 자신감 있으면서도 지나치게 사무적이지 않은 어조. 헤드라인은 최대 40자, 서브헤드는 20자 이내.”

모든 ‘명확함’ 버전은 동일한 기술을 쓴다. 명시된 의도, 구체적인 제약 조건, 명확한 청자, 구체적인 형식. 프롬프트 엔지니어링 같은 건 없다. 그저 명확한 생각을 명확하게 표현했을 뿐이다.

실제로 다른 단 한 가지

인간과의 소통과 LLM과의 소통 사이에 유의미한 차이가 있다면 딱 하나다. 바로 ’사전에 공유된 맥락(shared context)’을 얼마나 전제할 수 있는가이다. 오랜 시간 손발을 맞춘 동료에게는 “평소 하던 방식으로”라고만 해도 통한다. 하지만 LLM에게는 그 ’평소 방식’이 무엇인지 일일이 말해주어야 한다.

그러나 한 번 더 생각해 보라. 이 차이는 ‘인간’ 대 ’LLM’이라는 범주보다, 사실 ‘사람 대 사람’ 사이에서 훨씬 더 크게 갈린다. 새로 입사한 신입 사원 역시 당신의 평소 방식을 모른다. 외주 계약자 역시 팀 내부의 은어나 줄임말을 이해하지 못한다. 요약을 요청하는 임원과 같은 내용을 묻는 엔지니어가 가진 배경지식도 완전히 다르다.

뛰어난 소통가는 이미 상대에 맞춰 맥락의 수준을 조절한다. LLM을 대할 때는 그저 상대의 사전 맥락을 ’0’으로 설정할 뿐이다. 이는 새로운 협업자와 일할 때 취하는 태도와 정확히 같다.

LLM을 넘어 이것이 중요한 이유

‘프롬프트 엔지니어링’ 시대의 역설은, 이 열풍이 사람들에게 본의 아니게 더 나은 소통법을 가르쳐주고 있다는 점이다. ChatGPT로부터 훌륭한 결과를 얻어내는 기법들—의도를 먼저 밝히고, 구체적으로 요구하며, 요청을 구조화하고, 예시를 드는 것—은 이메일을 더 명확하게 만들고, 회의 시간을 줄이며, 슬랙 메시지의 실행력을 높이는 기법과 정확히 같다.

새로운 언어를 배우는 것이 아니다. 이미 사용하고 있던 언어를 더 예리하게 벼리는 과정일 뿐이다.

최고의 소통가들은 언제나 이렇게 소통해 왔다. 결론부터 말하고, 제약 조건을 명시하며, 예시를 들고, 요구사항에 번호를 매긴다. 첫 응답이 빗나가면 정교하게 다시 짚어주고, 사안의 중요도에 맞춰 세부 묘사의 수위를 조절한다.

이제 나머지 사람들도 그 뒤를 따르고 있다. 상대방이 사회적 눈치가 전혀 없고, 분위기를 파악하거나 숨은 의도를 읽어내지 못하며, 행간을 메워주지도 못할 때, 비로소 자신이 진짜로 전하고자 하는 바를 명확히 말해야만 한다는 사실을 깨달았기 때문이다.

그리고 그것은 결국, 인간 모두를 위한 훌륭한 훈련이 된다.

지금 바로 시작할 수 있는 한 가지 습관

이 글에서 단 하나만 기억해야 한다면 이것이다. 항상 첫 문장에 당신의 의도를 밝혀라. 배경 이야기가 아니다. 전후 사정도 아니다. 긴 서론도 아니다. 바로 ’의도’다.

“X와 Y 사이에서 결정을 내리는 데 도움이 필요합니다.” “헤더 디자인에 대한 피드백을 받고 싶습니다.” “React와 Vue를 비교 중인데 장단점 분석이 필요합니다.”

이것이 습관화되면—약 일주일이면 충분하다—다음 습관을 더하라. 하나의 구체적인 제약 조건을 다는 것이다. 그다음에는 훌륭한 결과물이 어떤 모습인지 예시를 하나 제시하라. 한 달 안에 이메일은 더 명료해지고, 회의는 짧아지며, 슬랙 메시지에는 더 빠른 답장이 올 것이고, LLM과의 대화는 훨씬 더 뛰어난 결과를 만들어낼 것이다.

모두 같은 원리에서 비롯된 습관이다. 하나의 목소리로, 모든 대화 상대를 향해.