좋은 프롬프트는 좋은 질문에서 나온다

이 시리즈에서 저는 계속 같은 이야기를 해왔습니다. AI는 증폭기이고, 증폭할 정의가 비어 있으면 결과도 빈다고요. 업무를 정의할 수 있어야 AI에게 일을 시킬 수 있다고요. 프롬프트의 본질은 꼼수가 아니라 명확하게 생각하고 명확하게 말하는 능력이라고요.

그러면 당연히 이런 질문이 나옵니다. “그래서, 어떻게 정의하는데요?”

이번 글은 그 질문에 답합니다.

현상을 던지는 사람, 문제를 정의하는 사람

교육 현장에서 실습을 하면, AI에게 도움을 요청하는 방식이 두 부류로 갈립니다.

한쪽은 현상을 그대로 던집니다. “보고서 퀄리티가 낮아요, 어떻게 하면 되나요?” “회의가 너무 길어요, 줄이는 방법 알려주세요.” “고객 응대가 잘 안 돼요.” 느끼고 있는 불편함을 그 상태 그대로 AI에게 넘기는 겁니다.

다른 쪽은 한 발 더 들어갑니다. “주간 보고서를 팀장에게 올리는데, 핵심 수치는 있지만 그게 좋은 건지 나쁜 건지 판단 기준이 빠져서 매번 되물음을 받습니다.” 같은 보고서 고민이지만, AI가 받아들이는 정보의 밀도가 완전히 다릅니다.

차이가 어디서 오느냐면, 앞의 사람은 증상을 말한 것이고, 뒤의 사람은 문제를 말한 겁니다.

증상과 문제는 다릅니다

“매출이 떨어지고 있다”는 증상입니다. “가격에 민감한 신규 고객층에게 재구매 유인이 없어 3개월 내 이탈률이 40%를 넘는다”는 문제입니다. 증상은 누구나 보입니다. 문제는 파고들어야 보입니다.

AI에게 증상을 던지면, AI는 가장 흔한 답을 돌려줍니다. “매출 올리는 10가지 방법” 같은 범용 리스트요. 그럴듯합니다. 하지만 우리 상황에 맞는 답은 아닙니다. AI가 못 해서가 아닙니다. 우리가 무엇이 문제인지를 건네지 않았기 때문입니다.

다섯 번째 글에서 저는 이렇게 썼습니다. “AI에게는 ‘전에 하던 대로’가 없다. 빈칸을 가장 흔한 값으로 채울 뿐이다.” 현상을 그대로 던지는 것은 빈칸을 잔뜩 남겨둔 채로 AI에게 넘기는 것과 같습니다.

‘왜’를 세 번 물으면 문제가 보입니다

그러면 증상에서 문제로 어떻게 내려갈 수 있을까요. 방법은 의외로 간단합니다. ‘왜’를 반복해서 물으면 됩니다.

보고서 퀄리티가 낮다. 왜? 분석은 있는데 판단 기준이 빠져 있다. 왜? 이 보고서를 읽는 사람이 어떤 의사결정을 하려는지 모르고 쓴다. 왜? 보고서를 요청한 사람의 맥락을 확인하는 절차가 없다.

세 번 ‘왜’를 물었을 뿐인데, 출발점과 도착점이 완전히 달라졌습니다. “보고서를 잘 쓰는 법”이 아니라 “보고 대상의 의사결정 맥락을 먼저 파악하는 것”이 진짜 문제였습니다. 이걸 알면 AI에게 시킬 일도 달라집니다. “보고서 잘 쓰는 팁 알려줘”가 아니라 “팀장이 주간 회의에서 이 데이터로 예산 조정 여부를 판단합니다. 판단에 필요한 기준선과 비교 구조를 포함한 보고서 초안을 써주세요”가 됩니다.

탐정이 사건을 풀 때 하는 일이 이겁니다. 눈에 보이는 단서(증상)에서 출발해, “왜 이 단서가 남았는가”를 반복하며 범인(근본 원인)까지 내려갑니다. 이 과정을 교육에서는 Why Tree라고 부릅니다. 별다른 도구가 필요 없습니다. 종이에 적든, 머릿속으로 하든, “왜?”만 세 번 물으면 대부분의 업무 문제는 한 층 아래까지 내려갑니다.

사실 이 방법은 새로운 게 아닙니다. 1950년대 도요타 생산 시스템에서 시작된 ‘5 Whys’라는 기법이 원형입니다. 공장에서 불량이 발생하면, 현장 작업자가 “왜?”를 다섯 번 반복해 눈에 보이는 증상이 아니라 공정 설계의 근본 결함까지 추적하는 방식이었습니다. 이후 식스시그마, 린(Lean), 품질경영 전반으로 퍼졌고, 제가 교육 현장에서 10년 넘게 다뤄온 도구이기도 합니다.

흥미로운 건, 이 방법이 70년 전 제조 현장에서 만들어졌다는 사실 자체가 이 글의 요점을 증명한다는 겁니다. 문제를 정의하는 기술은 AI 때문에 필요해진 게 아닙니다. 원래 필요했습니다. 다만 그동안은 사람의 감과 경험이 이 단계를 대신해줬기 때문에 많은 직무에서 명시적으로 훈련하지 않았을 뿐입니다. AI는 그 감과 경험이 통하지 않는 상대입니다. 그래서 70년 전의 도구가 지금, 제조 현장이 아닌 사무실 책상 위에서 다시 필요해진 겁니다.

네 칸을 채우면 프롬프트가 됩니다

‘왜’로 근본 원인까지 내려갔으면, 다음 단계는 그것을 한 문장으로 정리하는 겁니다. 저는 이 문장을 Problem Statement라고 부릅니다. 공식은 간단합니다.

[누가] + [어떤 상황에서] + [무엇을 겪고] + [어떤 결과가 발생한다]

아까 보고서 예시로 채워보겠습니다.

[주간 보고서를 작성하는 실무자가] + [팀장의 주간 예산 회의에 올릴 보고서를 쓸 때] + [판단 기준 없이 수치만 나열하게 되어] + [매번 되물음을 받고 수정을 반복한다]

이 문장이 생기면, AI에게 건넬 프롬프트는 거의 완성된 겁니다. 네 칸의 정보가 AI에게 맥락·목적·제약·기대 결과를 한꺼번에 건네기 때문입니다. 프롬프트 프레임워크라고 불리는 것들 — 역할을 주고, 맥락을 주고, 형식을 정하고 — 이 결국 하는 일이 이 네 칸을 채우는 것과 같습니다.

차이가 있다면, 프롬프트 프레임워크는 “AI에게 잘 전달하는 형식”에서 시작하고, Problem Statement는 “내가 풀려는 문제를 이해하는 것”에서 시작합니다. 순서가 다릅니다. 그리고 그 순서가 결과를 가릅니다.

형식부터 채우면, 빈칸이 남습니다. 역할을 정해도 그 역할이 왜 필요한지를 모르면 엉뚱한 역할을 줍니다. 맥락을 쓰라고 해도 무슨 맥락이 중요한지 모르면 불필요한 정보를 잔뜩 붙입니다. 하지만 문제부터 정의하면, 형식은 자연스럽게 따라옵니다. 무엇이 문제인지 아는 사람은 누구에게 어떤 형태로 답을 받아야 하는지도 압니다.

‘어떻게’를 물으면 해결이 구체화됩니다

‘왜’가 문제를 찾는 방향이라면, 반대 방향도 있습니다. ‘어떻게’를 반복하는 겁니다.

“판단 기준이 포함된 보고서를 쓰자.” 어떻게? “팀장이 보는 핵심 지표 3개를 먼저 확인하자.” 어떻게? “주간 회의 전에 팀장에게 5분 선 확인을 하자.” 어떻게? “매주 월요일 오전에 슬랙으로 지표 확인 메시지를 보내자.”

추상적인 해결 방향이 실행 가능한 행동으로 내려옵니다. 이것을 How Tree라고 부릅니다. Why Tree가 탐정이라면, How Tree는 설계도입니다.

AI에게 일을 시킬 때도 이 방향이 있으면 다릅니다. “보고서 써줘”가 아니라 “이 세 가지 지표를 기준으로, 지난주 대비 변화율을 계산하고, 예산 조정이 필요한 항목을 표시한 보고서를 써줘”가 됩니다. AI가 달라진 게 아닙니다. 건네는 지시의 구체성이 달라진 겁니다.

이것은 AI 기술이 아닙니다

여기까지 읽으신 분은 눈치챘을 겁니다. 이 글에서 말한 것 중 AI에 고유한 내용은 하나도 없습니다. ‘왜’를 반복해 근본 원인을 찾고, 문제를 한 문장으로 정의하고, ‘어떻게’를 반복해 실행 단위로 내리는 것. 이건 AI 이전부터 있던 사고 도구입니다.

“문제를 잘 정의하면 절반은 성공이다”라는 말은 아인슈타인이 했다고도 하고, 그보다 훨씬 전부터 쓰였다고도 합니다. 출처가 누구든, 본질은 같습니다. 문제를 정의하는 데 시간을 쓰면, 해결은 빨라집니다.

AI가 바꾼 건 한 가지입니다. 이 오래된 지혜가 눈에 보이는 차이로 나타나게 되었다는 것. 예전에는 문제 정의를 대충 해도 경험과 감으로 어느 정도 결과를 만들 수 있었습니다. 하지만 AI에게는 감이 없습니다. 정의가 명확하면 결과가 날카롭고, 정의가 모호하면 결과가 뭉뚱그려집니다. 그 차이가 즉각적으로, 반복적으로 드러납니다.

그래서 좋은 프롬프트를 쓰고 싶다면, 프롬프트 기법을 외울 게 아니라 자기가 풀려는 문제를 한 문장으로 써보는 것부터 시작하시길 권합니다. 네 칸을 채워보세요. 누가, 어떤 상황에서, 무엇을 겪고, 어떤 결과가 발생하는지. 그 문장이 또렷해지는 순간, 프롬프트는 이미 절반 완성입니다.