Deep Interview 스킬로 요구사항을 명확하게 만드는 방법: Plan Mode 전에 해야 할 일

여러분, AI 코딩 에이전트의 성능은 정말 빠르게 좋아지고 있습니다. Codex, Claude Code, Cursor 같은 도구를 쓰면 예전보다 훨씬 긴 작업도 맡길 수 있고, 단순 코드 작성뿐 아니라 분석, 리팩토링, 테스트, 문서화까지 한 번에 처리할 수 있죠. 그런데 같은 도구를 써도 결과물의 품질은 사람마다 크게 달라집니다.

제가 그 차이의 핵심 원인으로 보는 건 요청의 명확도입니다. 에이전트에게 충분히 구체적인 지시를 주면 결과물도 안정적입니다. 반대로 요구사항이 비어 있으면 AI는 그 빈칸을 추측으로 채웁니다. 결과는 빨리 나오지만, “내가 원한 건 이게 아닌데”라는 상태에 자주 도달하게 됩니다.

Deep Interview 스킬은 이 문제를 정면으로 다룹니다. 처음부터 완벽한 프롬프트를 쓰려고 애쓰는 대신, AI가 거꾸로 나에게 질문을 던져서 요구사항을 구체화하게 만드는 방식이죠. 결론부터 말하면, 좋은 프롬프트를 한 번에 작성하는 기술이 아니라 모호한 생각을 실행 가능한 요구사항으로 바꾸는 인터뷰 루프라고 보시면 됩니다. 제가 매일 쓰는 스킬인데, 단 하나만 추가해야 한다면 저는 이 스킬을 고르겠습니다.

핵심 요약

• Deep Interview 스킬은 AI가 사용자에게 역으로 질문해 목표, 범위, 제약, 완료 기준을 구체화하는 요구사항 정리 방식입니다.
• 좋은 결과물을 얻으려면 에이전트에게 넘기기 전에 요구사항의 빈칸을 줄여야 합니다.
• Plan Mode는 유용하지만 계획을 너무 빨리 끝낼 수 있으므로, 모호한 요청에서는 Plan Mode 전에 Deep Interview를 거치는 것이 효과적입니다.
• 핵심은 질문을 많이 하는 것이 아니라 가장 큰 불확실성 하나를 골라 한 번에 하나씩 푸는 것입니다.
• 질문 형식은 현재 이해, 막힌 결정, 추천 답안, 질문 한 개의 네 가지 요소로 구성됩니다.
• 코드베이스를 보면 답할 수 있는 질문은 사용자에게 묻지 않고 직접 확인해야 합니다.
• 목표, 포함 범위, 제외 범위, 제약, 완료 판단 기준, 열린 질문이 정리되면 인터뷰를 종료할 수 있습니다.

왜 명확한 프롬프트 작성이 어려운가

사용자는 처음부터 완성된 결과를 모른다

명확한 지시가 중요하다는 말은 누구나 알고 있습니다. 문제는 그 명확한 지시를 작성하는 일이 생각보다 어렵다는 점이죠. 나도 내가 뭘 원하는지 정확히 모르는 상태인 경우가 많거든요. 처음부터 최종 결과물의 완성된 모습을 그려내기란 정말 쉽지 않습니다. 만들고 싶은 건 있지만, 어디까지 포함해야 하는지, 어떤 제약을 지켜야 하는지, 무엇을 완료로 볼 것인지는 대화를 통해 드러나는 경우가 많습니다.

이 상태에서 바로 코딩 에이전트에게 작업을 넘기면 AI는 빈칸을 추측합니다. 예를 들어 “관리자 페이지 개선해줘”라고 요청하면, 에이전트는 디자인을 바꿀지, API를 손볼지, 테이블 구조를 개선할지, 접근성을 챙길지 스스로 가정해야 합니다. 이런 추측은 빠른 실행을 가능하게 하지만, 사용자의 실제 의도와 어긋날 가능성도 커집니다.

빈칸이 많을수록 결과물은 우연에 가까워진다

요구사항이 비어 있으면 에이전트는 일반적인 패턴을 적용합니다. 일반적인 패턴이 항상 나쁜 것은 아니지만, 특정 제품과 코드베이스에는 고유한 맥락이 있습니다. 운영 환경, 팀의 선호, 배포 방식, 기존 컴포넌트, 데이터 모델, 사용자 흐름 같은 요소가 반영되지 않으면 결과물은 겉보기에는 그럴듯해도 실제로 쓰기 어렵습니다.

Deep Interview는 이 빈칸을 줄이는 장치입니다. 사용자가 스스로 모든 것을 정리해서 말하게 하는 게 아니라, AI가 질문을 통해 암묵적인 가정과 판단 기준을 드러내도록 돕는 거죠. 그 결과 에이전트에게 넘길 최종 지시가 더 좁고 명확해집니다.

Deep Interview의 핵심 구조

소크라테스식 질문으로 요구사항을 끌어낸다

Deep Interview의 기본 철학은 답을 대신 정해 주는 게 아닙니다. AI가 사용자를 대신해 임의로 결론을 내리면 그것도 결국 또 다른 추측이 되니까요. 대신 소크라테스식 질문을 통해 사용자의 판단 기준이 드러나도록 합니다.

이 방식에서는 AI가 “제가 보기엔 A로 하겠습니다”라고 바로 실행하지 않습니다. 먼저 현재 이해를 요약하고, 가장 큰 불확실성이 무엇인지 짚고, 가능한 선택지를 제시한 뒤, 하나의 질문을 던집니다. 사용자는 그 질문에 답하면서 자신의 의도를 조금씩 구체화하게 됩니다.

Deep Interview의 목표는 질문을 많이 하는 것이 아니라, 가장 중요한 불확실성을 순서대로 제거하는 것입니다.

한 번에 하나의 질문만 한다

AI가 요구사항을 물을 때 흔히 하는 실수는 한 번에 너무 많은 질문을 던지는 것입니다. 목표, 예산, 디자인, API, 배포, 권한, 테스트 기준을 한꺼번에 물으면 답하는 입장에서도 힘들죠. 결국 일부 질문은 대충 답하거나 건너뛰게 됩니다.

그래서 Deep Interview에서는 한 번에 하나의 질문만 던지는 게 핵심입니다. 현재 가장 큰 불확실성 하나를 선택하고, 그것을 풀어야 다음 단계로 넘어갑니다. 이 방식은 속도가 느려 보일 수 있지만, 실제로는 중요한 결정을 놓치지 않기 때문에 후반부의 재작업을 줄여 줍니다.

질문 형식: 네 가지 구성 요소

현재 이해

먼저 AI는 사용자의 요청을 현재까지 어떻게 이해했는지 짧게 정리합니다. 이 단계는 사용자와 AI가 같은 문제를 보고 있는지 확인하는 역할을 합니다. 이해가 틀렸다면 사용자는 바로 수정할 수 있고, 맞다면 다음 결정으로 넘어갈 수 있습니다.

예를 들어 “현재 이해: 블로그 자동화 기능을 만들고 싶고, 새 YouTube 영상을 감지해 글 초안을 생성하는 흐름이 필요합니다”처럼 정리할 수 있습니다. 이 요약은 길 필요가 없습니다. 중요한 것은 현재 대화의 기준점을 공유하는 것입니다.

막힌 결정

다음으로 지금 진행을 막고 있는 결정이 무엇인지 명확히 합니다. 모든 불확실성이 같은 중요도를 갖는 것은 아닙니다. 지금 당장 정하지 않아도 되는 세부사항과, 지금 정하지 않으면 설계가 흔들리는 결정은 구분해야 합니다.

예를 들어 “새 글을 자동으로 발행할지, draft로 저장할지”는 워크플로우 전체에 영향을 줍니다. 반면 태그 이름의 세부 표현은 나중에 조정해도 됩니다. Deep Interview는 이런 우선순위를 정해 가장 큰 결정부터 풉니다.

추천 답안

사용자에게 열린 질문만 던지면 답하기 어렵습니다. 그래서 Deep Interview는 2-3개의 선택지를 먼저 제시하고, 그중 하나를 추천합니다. 추천 답안은 결정을 강제하는 것이 아니라 사용자가 빠르게 판단할 수 있도록 기준점을 제공하는 역할입니다.

예를 들어 “A: 자동 발행, B: draft 저장 후 검수, C: 제목만 생성”처럼 선택지를 제시하고, “추천은 B입니다. 콘텐츠 품질 검수가 필요하기 때문입니다”라고 설명할 수 있습니다. 사용자는 추천을 받아들일 수도 있고, 다른 선택지를 고를 수도 있습니다.

질문 한 개

마지막에는 질문을 하나만 남깁니다. 이 질문은 다음 진행을 위해 반드시 필요한 결정이어야 합니다. “어떤 방식으로 할까요?”처럼 넓은 질문보다 “초안은 자동 발행이 아니라 draft로 저장하는 방식으로 가도 될까요?”처럼 좁은 질문이 좋습니다.

이 형식을 반복하면 대화는 산만해지지 않습니다. 매 턴마다 현재 이해가 갱신되고, 하나의 결정이 풀리며, 요구사항은 점점 실행 가능한 형태로 좁혀집니다.

Plan Mode 전에 Deep Interview가 필요한 이유

Plan Mode는 계획을 빠르게 만든다

Codex, Claude Code, Cursor 같은 도구에는 계획을 세우는 흐름이 기본적으로 들어가 있습니다. Plan Mode는 작업 전에 접근법을 정리하는 데 유용하죠. 그런데 제가 더 중요하게 보는 건 이겁니다. Plan Mode만으로 요구사항을 명확히 하기엔 부족할 수 있다는 거예요. 제 생각에 Plan Mode는 계획을 너무 빨리 끝내 버립니다.

모호한 요청에서 바로 계획을 세우면, 계획은 빠르게 나오지만 그 계획의 전제가 불분명할 수 있습니다. 사용자는 계획을 승인했는데, 실제로는 중요한 결정이 아직 열려 있는 거죠. 그러다 구현 단계에 가서야 “이건 내가 원한 방향이 아닌데”라는 문제가 드러납니다.

Deep Interview는 계획의 입력을 정리한다

Deep Interview는 Plan Mode를 대체하기보다 Plan Mode 앞단에서 입력을 정리하는 역할에 가깝습니다. 먼저 목표와 범위, 제외 범위, 제약, 완료 기준을 인터뷰로 정리한 뒤, 그 결과를 바탕으로 계획을 세우면 계획의 품질이 올라갑니다.

실무에서는 다음 순서가 자연스럽습니다.

1. 러프한 요청을 받습니다.
2. Deep Interview로 모호한 지점을 한 번에 하나씩 줄입니다.
3. 요구사항이 실행 가능한 수준이 되면 확장된 계획을 작성합니다.
4. 계획을 승인한 뒤 코딩 에이전트에게 구현을 맡깁니다.

이 구조는 장시간 작업을 맡길수록 더 중요해진다고 봅니다. 요즘 코딩 에이전트가 점점 긴 시간 동안 작업하게 되는데, 오래 달릴수록 초기에 잘못된 방향으로 출발했을 때의 비용이 커지기 때문이죠.

질문 축과 종료 기준

어떤 축을 확인해야 하는가

Deep Interview에서 자주 확인해야 할 축은 목표, 범위, 제외 범위, 제약, 완료 기준, 맥락, 영향 범위입니다. 목표는 무엇을 달성하려는지이고, 범위는 어디까지 포함할지입니다. 제외 범위는 이번 작업에서 하지 않을 일을 명확히 합니다.

제약은 기술 스택, 일정, 보안, 운영 정책처럼 반드시 지켜야 하는 조건입니다. 완료 기준은 작업이 끝났다고 판단할 수 있는 기준입니다. 맥락과 영향 범위는 기존 코드베이스나 사용자의 워크플로우에 어떤 영향을 주는지를 확인합니다.

질문 축	확인해야 할 내용
목표	무엇을 달성해야 하는가
범위	이번 작업에 포함되는 것은 무엇인가
제외 범위	이번에는 하지 않을 것은 무엇인가
제약	기술, 보안, 일정, 운영상 제한은 무엇인가
완료 기준	무엇을 보면 끝났다고 판단할 수 있는가
영향 범위	어떤 사용자, 코드, 문서, 시스템에 영향을 주는가

언제 멈춰야 하는가

인터뷰는 끝없이 이어지면 안 됩니다. 목표가 충분히 선명해지고, 포함 범위와 제외 범위가 정리되며, 지켜야 할 제약과 완료 판단 기준이 명확해졌다면 멈춰야 합니다. 남은 열린 질문이 있더라도 구현을 막지 않는 수준이면 계획 단계로 넘어갈 수 있습니다.

종료 기준이 중요한 이유는 Deep Interview가 실행을 지연시키는 도구가 되어서는 안 되기 때문입니다. 목적은 완벽한 문서를 만드는 것이 아니라, 에이전트가 잘못된 추측으로 구현을 시작하지 않게 만드는 것입니다.

코딩 외 작업에도 적용하기

콘텐츠 기획과 제품 기획

Deep Interview는 꼭 코딩할 때만 쓰는 스킬이 아닙니다. 실제로 이 콘텐츠를 기획할 때도 제가 Deep Interview를 썼습니다. 콘텐츠 기획, 업무 자동화, 제품 기획처럼 시작점이 모호한 작업이라면 같은 방식이 그대로 적용됩니다.

예를 들어 “AI 강의 하나 만들어줘”라는 요청은 너무 넓습니다. Deep Interview는 대상 수강생, 강의 목표, 실습 범위, 제외할 내용, 완료 산출물 같은 질문을 통해 요청을 좁힙니다. 그 결과 단순한 아이디어가 실제 제작 가능한 기획안으로 바뀝니다.

업무 자동화 요구사항 정리

업무 자동화에서도 Deep Interview는 유용합니다. 자동화 요청은 “반복 업무를 줄이고 싶다”처럼 시작되는 경우가 많지만, 실제로는 입력 데이터, 승인 절차, 실패 시 처리, 알림 방식, 보안 제약이 모두 중요합니다. 이런 요소를 묻지 않고 바로 자동화를 만들면 운영 중 문제가 생기기 쉽습니다.

Deep Interview는 이런 암묵적 조건을 초기에 드러냅니다. 특히 사용자에게 직접 묻지 않아도 코드베이스나 기존 문서에서 확인할 수 있는 내용은 AI가 직접 확인하도록 설계하는 것이 좋습니다. 그래야 인터뷰가 귀찮은 질문 목록이 아니라 실제로 필요한 의사결정 루프가 됩니다.

공유 레포에서 바로 확인하기

제가 소개한 Deep Interview 스킬은 GitHub에 공개된 devbrother2024/skills 레포에서 확인할 수 있습니다. 직접 적용해 보고 싶다면 해당 레포의 스킬 구조를 참고해 자신의 Codex, Claude Code, Cursor 워크플로우에 맞게 가져오면 됩니다.

처음부터 모든 규칙을 그대로 복사하기보다는, 한 번에 하나의 질문만 던지는 원칙과 현재 이해, 막힌 결정, 추천 답안, 질문 한 개의 형식을 먼저 적용해 보는 것이 좋습니다. 이후 실제 작업에서 반복적으로 막히는 지점을 기준으로 질문 축과 종료 기준을 조금씩 조정하면 됩니다.

마무리

제가 말하고 싶은 건 이겁니다. Deep Interview의 핵심은 AI에게 더 많은 일을 시키기 전에, AI가 올바른 일을 하도록 요구사항을 선명하게 만드는 데 있습니다. 에이전트의 성능이 좋아질수록 오히려 초기 지시의 품질이 더 중요해진다고 봅니다. 강력한 에이전트가 잘못된 방향으로 오래 달리면 그만큼 수정 비용도 커지니까요.

좋은 프롬프트를 처음부터 완성하려고 애쓰기보다, AI가 거꾸로 나에게 질문하게 만드는 쪽으로 접근하면 부담이 훨씬 줄어듭니다. 현재 이해를 공유하고, 막힌 결정을 고르고, 추천 답안을 제시하고, 질문 하나를 던지는 루프만 지켜도 요구사항은 훨씬 실행 가능한 형태가 됩니다.

결론적으로 Deep Interview는 Plan Mode 전에 놓기 좋은 준비 단계입니다. 모호한 요청을 바로 실행하지 말고, 한 번에 하나씩 불확실성을 줄여 나가 보면 좋겠습니다. 그러면 코딩 에이전트의 결과물도 더 안정적이고, 내가 원하는 방향에 훨씬 가까워질 겁니다.

---

관련 영상

이 글과 연결된 영상은 개발동생 유튜브 채널에서 보기에서 확인할 수 있습니다.