한때는 AI를 많이 쓸수록 일이 빨라질 줄 알았다. 그런데 실제로는 반대인 순간이 많았다. 답을 받는 시간보다 그 답을 고치고, 의심하고, 다시 묻는 시간이 더 길어졌다. 여러 AI를 병렬로 돌려보면서 내린 결론은 단순했다. 문제는 AI의 성능이 아니라, 내가 처음 던진 질문의 전제에 있었다.

서비스 기획자가 AI를 써도 실무 품질이 쉽게 올라가지 않는 이유도 여기에 있다. 많은 경우 우리는 AI에게 더 좋은 답을 요구한다. 하지만 정작 바꿔야 하는 것은 답변 품질이 아니라 질문 설계다. 특히 어느 정도 경력이 쌓인 이후에는 정보를 모르는 문제가 아니라, 무엇을 먼저 물어야 하는지 잘못 잡는 문제가 더 자주 생긴다. AI는 대답을 빠르게 내놓지만, 질문이 잘못되면 그 답변은 오히려 기획을 틀린 방향으로 더 빨리 밀어붙인다.

이 사실을 가장 크게 배운 건 광고 플랫폼 관련 업무에 긴급 투입됐을 때였다. 데이터 시각화는 오래 해왔지만 광고 도메인은 처음이었다. 그런데 어느 날 갑자기 광고 플랫폼 기획을 맡게 됐고, C레벨 보고까지 준비해야 했다. 낯선 시장 구조를 빠르게 이해하고, 경쟁 구도를 정리하고, 차별화 포인트까지 말해야 하는 상황이었다.

그때 나는 아주 전형적인 방식으로 AI를 썼다. 역할을 부여하고, 주요 플레이어를 지정하고, 비교해달라고 했다.

“너는 10년 차 광고 플랫폼 기획자야. CTV 광고 시장의 주요 플레이어를 경쟁사 관점에서 비교해줘. Roku, Amazon, Google의 사업 구조와 점유율을 정리해주고, 밸류체인별 차이도 설명해줘.”

지금 보면 꽤 그럴듯한 프롬프트였고, AI도 성실하게 답했다. 시장 구조는 깔끔하게 정리됐고, 플레이어 비교도 무난했다. 나는 그 내용을 바탕으로 보고서를 정리했고, 큰 무리 없이 초반 보고를 마쳤다.

문제는 그다음에 나왔다. 다른 회의에서 동료의 발표를 들었는데, 내가 정리한 방향과 다른 이야기가 나온 것이다. 나는 기존 밸류체인을 정리하고 있었는데, 동료는 그 밸류체인 자체가 이미 흔들리고 있다고 말했다. 예를 들어 Roku는 모든 영역을 자체적으로 쥐는 방향이 아니라, 파트너십 중심으로 오픈하는 전략을 이야기였다. 내가 보고서에 넣었던 핵심과는 다른 이야기였다.

그 순간 깨달았다. AI가 틀린 답을 준 게 아니었다. 내가 AI에게 시킨 일이 이미 틀린 방향이었다. 내 질문에는 두 개의 전제가 숨어 있었다.

첫째, 이 밸류체인은 지금도 유효하고 비교적 안정적이라는 전제.

둘째, 내가 해야 할 일은 이 구조를 잘 이해하고 정리하는 것이라는 전제. 하지만 실제 시장은 그 구조 자체를 재편하는 중이었다. 내가 봐야 했던 것은 “무엇이 무엇과 다른가”가 아니라 “무엇이 왜 뒤집히고 있는가”였다. 그런데 나는 정리형 질문을 던졌고, AI는 아주 성실하게 정리형 답변을 내놓았다. 정확한 답이었지만 방향은 틀렸다.

서비스 기획 실무에서 더 위험한 것은 AI의 오답보다 이런 순간이다. 정리형 질문이 변화형 질문을 밀어내는 순간. 구조를 묻기 전에 변화를 보지 못하고, 설명을 요구하느라 전제를 점검하지 못하는 순간이다. 특히 낯선 시장을 이해해야 하거나, 새로운 서비스를 정의해야 하거나, 경쟁사 프레임을 다시 짜야 하는 업무에서는 이 차이가 치명적이다. 초반 질문이 잘못되면 이후 산출물 전체가 그 방향을 따라가기 때문이다.

나는 답을 구하기 전에 사각지대부터 묻기 시작했다

이 경험 이후로 나는 프롬프트를 바꾸기 시작했다. 예전에는 “정리해줘, 비교해줘, 설명해줘”로 시작했다면, 지금은 먼저 이렇게 묻는다.

“네가 이 도메인을 맡은 서비스 기획자라면 지금 무엇부터 물어보겠어? 내가 지금 어떤 접근으로 이 문제를 보고 있는지 먼저 짚고, 그 접근에 깔린 전제가 무엇인지 말해줘. 그리고 최근 변화가 기존 구조를 어떻게 흔들고 있는지부터 설명해줘.”

답을 바로 요구하지 않고, 사각지대를 먼저 드러내는 프롬프트 예시 <출처: 작가>

겉보기엔 작은 차이 같지만 실무에서는 결과가 완전히 달라진다. 이 질문은 답을 바로 달라고 하지 않는다. 대신 내 사각지대를 먼저 드러내달라고 요구한다. 그러면 AI는 “이 구조를 누가 우회하고 있는가?”, “지금 비교 프레임이 이미 낡은 것은 아닌가?”, “당신이 당연하다고 보는 질서가 실제로는 해체되는 중인 것은 아닌가?” 같은 질문을 던져온다. 바로 그 지점에서 기획이 달라진다.

좋은 프롬프트는 정보를 더 많이 가져오는 프롬프트가 아니다. 내가 무엇을 당연하게 보고 있는지 먼저 드러내는 프롬프트다. 서비스 기획자에게 AI는 답변 엔진이기 전에, 전제 점검 도구가 되어야 한다.

이 방식은 특히 서비스 기획 초반 업무에서 강하게 작동한다. 시장 구조를 파악할 때, 경쟁사를 비교할 때, 신규 서비스를 정의할 때, 정책을 설계할 때, 이해관계자 간 관점을 정리할 때 그렇다. 이 단계에서는 답을 빨리 받는 것보다 질문의 방향을 틀리지 않는 것이 훨씬 중요하다. 초반 질문이 틀리면, 나중에 문장을 아무리 잘 다듬어도 결국 엇나간 답안을 예쁘게 정리하는 데 그치기 쉽다.

그래서 요즘 내가 가장 자주 쓰는 프롬프트 구조는 네 단계다.

첫째, AI의 역할을 지정한다.
둘째, 내가 현재 어떤 방식으로 접근하고 있는지 드러낸다.
셋째, 놓친 관점과 숨어 있는 전제를 먼저 짚어달라고 한다.
넷째, 최근 변화가 기존 구조를 어떻게 흔들고 있는지 묻는다.

예를 들면, 이렇게 쓴다.

“네가 [내 역할]을 맡은 서비스 기획자라면, 지금 이 문제에서 무엇부터 확인하겠어? 내가 현재 [내 접근 방식]으로 접근하고 있는데, 이 접근의 전제와 사각지대를 먼저 짚어줘. 특히 최근 [업계 변화/주요 사건]가 기존 [구조/관행]을 어떻게 흔들고 있는지 중심으로 정리해줘.”

이 프롬프트의 장점은 답변보다 질문 목록을 먼저 가져오게 만든다는 데 있다. AI가 나 대신 결론을 내리기보다, 내가 어떤 순서로 생각해야 하는지를 보여준다. 그 결과 회의 전에 준비해야 할 질문이 달라지고, 보고서 첫 장에 놓이는 문제 정의도 달라진다. “무엇을 정리할 것인가”보다 “무엇을 의심할 것인가”가 먼저 정해진다.

한 가지 더 유용했던 방식은 여러 AI를 병렬로 쓰는 것이었다. 같은 주제를 GPT, Gemini, Claude에 동시에 던져본 뒤, 한 모델의 답변을 다른 모델에게 넘겨 전제를 해부하게 했다.

“다음은 [다른 AI]가 정리한 분석이야. 이 분석의 전제 세 가지를 짚어줘. 그리고 그 전제들이 지금 시점에 흔들리고 있다면 결론이 어떻게 달라지는지 반박해줘.”

여기서 중요한 건 단순한 팩트 체크가 아니다. 더 중요한 건 프레임 차이다. 어떤 모델은 구조의 안정성을 전제하고 답하고, 다른 모델은 구조의 해체 가능성을 전제한다. 두 답을 나란히 놓고 보면 내가 어떤 질문 프레임 안에 갇혀 있었는지가 보인다. 실무에서 이 차이는 생각보다 크다. 같은 시장 데이터, 같은 사례, 같은 키워드를 보고도 누군가는 정리만 하고 끝나고, 누군가는 변화의 방향까지 짚는다. 차이는 정보량보다 질문의 각도에서 난다.

출처 확인은 링크를 받는 일이 아니라, 제목과 날짜를 검증하는 일이다

그런 다음에야 팩트로 내려간다. 많은 사람들이 AI 답변을 검증할 때 사실관계부터 확인하려 한다. 시장 구조나 전략 방향 같은 문제에서는 사실 여부만으로는 부족하다. 어떤 전제를 깔고 그 사실을 배열했는지를 봐야 한다. 그래야 같은 정보로도 왜 다른 결론이 나오는지 이해할 수 있다.

물론 핵심 문장은 결국 공식 출처로 다시 확인해야 한다. 특히 전략 변화, 시장 방향, 사업 구조 같은 문장은 더 그렇다. 예전에는 “출처를 알려줘”라고만 물었는데, 그러면 AI가 그럴듯한 링크를 붙이는 경우가 있었다. 그래서 지금은 이렇게 묻는다.

“이 내용의 근거가 되는 공식 블로그 포스트, IR 자료, 컨퍼런스 발표의 제목과 발행일을 알려줘. 내가 직접 검색해서 실존 여부를 확인할 수 있어야 해.”

이렇게 하면 검증 방식도 달라진다. 링크를 믿는 게 아니라, 제목과 날짜를 기준으로 내가 직접 확인하게 된다. 실무에서는 이 과정이 번거로워 보여도, 보고서 한 장을 잘못 쓰고 다시 뒤집는 비용에 비하면 훨씬 싸다. 나에게는 그 이후 이 확인 과정이 선택이 아니라 기본 루틴이 됐다.

정리 단계에서는 AI를 넓게 쓰지 말고 오히려 좁혀야 한다

탐색 단계에서 AI를 넓게 쓰는 것만큼 중요한 게 하나 더 있다. 정리 단계에서는 반대로 AI를 좁게 써야 한다는 점이다.

이것저것 많이 조사한 뒤 마지막에 “지금까지 내용을 정리해줘”라고 던진다. 그러면 AI는 친절하게 답하지만, 정작 그 결과물은 기획서 초안으로 바로 쓰기 어렵다. 문장은 그럴듯한데 공허하고, 예쁘지만 추상적이며, 산출물 형식과도 잘 맞지 않는다. AI는 형식이 없으면 빈칸을 채우려 하고, 금지 조건이 없으면 익숙한 표현으로 빠져나간다.

그래서 정리 단계에서는 질문을 여는 대신 제약을 준다. 형식을 주고, 금지 조건을 박는다.

예를 들어, 사용자 시나리오를 정리할 때는 이렇게 묻는다. “사용자 시나리오 3개를 작성해줘. 각 시나리오는 상황, 동기, 행동, 감정 변화 순서로 정리하고, 각 항목은 실제 사용 맥락이 드러나야 해. 각 시나리오는 3문장 이내로 압축해줘.”

UX 개선안을 정리할 때는 이렇게 묻는다. “스마트홈 앱의 UX 개선안을 제시해줘. 단, 원론적 해결책 금지, 기술 난이도를 무시한 아이디어 금지, 단순히 예쁘게 바꾸자는 디자인 제안 금지. 각 개선안은 ‘어떤 사용자의, 어떤 상황에서, 왜 필요한가’로 시작해줘.”

형식과 금지 조건을 동시에 걸면 AI는 “뭐라도 채우자” 모드에서 벗어난다. 그리고 그때부터 결과물은 탐색용 답변이 아니라 실제 산출물에 가까운 초안이 된다. 탐색 단계에서는 넓게 묻고, 정리 단계에서는 오히려 좁혀야 한다. AI를 잘 쓰는 기획자는 많이 묻는 사람이 아니라, 언제 넓히고 언제 좁힐지 아는 사람이다.

결국 기획자의 경쟁력은 답변량이 아닌 질문의 방향에서 나온다

가장 의외였던 변화도 있다. AI를 많이 쓸수록 오히려 사람의 보고를 더 잘 듣게 됐다는 점이다. 예전에는 동료의 발표를 들을 때 “어차피 나도 gpt, gemini 쓰는데 서로 비슷한 자료를 찾았겠지”라고 생각한 적이 많았다. 지금은 다르게 본다. 더 중요한 것은 정보 자체가 아니라, 그 사람이 어떤 질문에서 출발했는가다. 왜 나는 같은 AI를 쓰고도 저 관점을 못 봤을까. 무엇을 먼저 물었기에 저 사람은 구조 변화부터 봤을까. 회의에서 진짜 배워야 할 것은 종종 답이 아니라 질문의 출발점이다.

서비스 기획자의 역할도 점점 그쪽으로 이동하고 있다고 느낀다. 정보는 넘치고, 답도 넘친다. 하지만 어떤 질문을 먼저 세울지는 여전히 사람의 몫이다. 특히 AI가 너무 매끄럽게 답할수록 더 조심해야 한다. 매끄러운 답은 종종 틀린 방향을 가리키고, 성실한 정리는 변화의 징후를 지워버린다. AI가 화려하고 논리적으로 답할수록, 기획자의 경쟁력은 그 답을 그대로 받아들이지 않는 데서 생긴다. 남들이 결론부터 쓰려 할 때, 변화의 방향을 의심하고 전제부터 점검하는 태도가 더 중요해지는 셈이다.

그래서 요즘 나는 AI에게 답을 받기 전에 꼭 한 번 더 묻는다. 내가 지금 당연하게 보고 있는 전제는 무엇인지, 이 구조는 정말 안정적인지, 내가 정리하려는 순간 놓치고 있는 변화는 없는지. 이 질문을 먼저 던지면 프롬프트가 달라지고, 프롬프트가 달라지면 기획의 방향이 달라진다.

이번 주 업무에서 한 번만 바꿔봐도 좋다. “정리해줘” 대신, “내가 놓친 전제를 먼저 짚어줘”라고 말이다. 프롬프트 하나를 바꾸는 일은 표현을 다듬는 일이 아니다. 결국 기획의 방향을 바꾸는 일이다.