인터뷰 주도 개발(IDD): 코드 전에 인터뷰부터

---

아이디어가 떠오르면 우리는 곧바로 Claude Code를 켭니다.
그리고 3달 동안 Opus 4.6(200k) 같은 모델에 1억 토큰 가까이를 쏟아붓습니다.
그렇게 완성한 제품을 세상에 내놓으면 어떤 일이 벌어질까요?

아무도 제품에 관심을 가지지 않습니다.

이건 초보 개발자만의 이야기가 아닙니다.
경력 10년 차 개발자도 반복하는 실수입니다.
(사실 제 이야기)

문제는 AI Agent가 아니라 개발의 순서입니다.

---

3개월 동안 만들고도 사용자 0명

아이디어만 믿고 코딩부터 시작하면,
실력과 무관하게 3개월 뒤 사용자 0명이라는 결과를 맞기 쉽습니다.

TDD가 테스트로 시작하듯, IDD는 인터뷰로 시작합니다.
Interview Driven Development(IDD)란 제품 개발의 출발점을 코드가 아니라 인터뷰에 두는 방법론입니다.

많은 제품 개발은 대체로 이렇게 흘러갑니다.

코딩 → 출시 → 피드백 → 대규모 수정

문제는 "무엇을 만들 것인가"가 명확하지 않은 상태에서 코딩을 시작한다는 점입니다.
AI 코딩 도구는 이 속도를 더 끌어올립니다.
하지만 속도가 빨라질수록, 방향이 틀렸을 때의 손실도 더 커집니다.

IDD는 이 순서를 바꿉니다.

인터뷰 → SPEC.md → 개발 → 검증

---

IDD 워크플로우

IDD는 인터뷰 → 스펙 → 계획 → 개발 → 배포 → 성과 검증의 순환 구조를 가집니다.

인터뷰 단계에서는 이런 질문들을 던집니다.

파악할 것	질문 예시
현재 워크플로우	지금은 이 문제를 어떻게 해결하고 계신가요?
페인포인트	그 방법에서 가장 불편한 점은 무엇인가요?
기대 가치	이 문제가 해결되면 하루가 어떻게 달라지나요?
지불 의사	돈을 내고서라도 해결하고 싶은 부분이 있나요?
경쟁 제품의 한계	비슷한 도구를 써보셨다면, 왜 그만두셨나요?

핵심은 솔루션을 설명하는 것이 아니라,
사용자가 실제로 겪는 문제를 발견하는 것입니다.

인터뷰가 끝나면 스펙을 작성합니다.
스펙이 모호하면 다시 인터뷰로 돌아갑니다.
성과 검증 단계에서 새로운 문제가 발견되면 또다시 인터뷰로 복귀합니다.

중요한 것은 완벽한 스펙을 한 번에 만드는 일이 아닙니다.
반복을 통해 문제를 정제하는 구조를 만드는 일입니다.

---

TDD vs SDD vs IDD

IDD는 기존 SDD 방법론을 대체하려는 개념이 아닙니다.
오히려 제품 개발의 출발점을 한 단계 더 앞당기는 개념에 가깝습니다.

구분	TDD	SDD	IDD
시작점	테스트 코드	스펙 문서	인터뷰
기준	테스트	SPEC.md	인터뷰 → SPEC.md

SDD는 스펙이 이미 존재한다고 가정합니다.
반면 IDD는 그보다 한 단계 앞에서,
"그 스펙은 어디서 오는가?"를 다룹니다.

---

왜 인터뷰가 중요한가

AI 에이전트는 명확한 지시를 받으면 매우 잘 수행합니다.
하지만 대부분의 문제는 구현이 아니라 문제 정의에 있습니다.

AI는 빠르게 구현할 수 있습니다.
하지만 무엇을 만들어야 하는지까지 대신 결정해주지는 않습니다.

우리는 종종 이렇게 묻습니다.

"X라는 사업 아이디어가 있는데, 좋은 아이디어 같나요?"

"X라는 서비스가 있는데, 사용할 의향이 있으신가요?

"X라는 제품을 제공할 예정인데, 얼마 정도 지불하실 생각이 있으신가요?"

하지만 제품을 만들 때 더 중요한 질문은 이런 것입니다.

✅ "평소에 어떤 불편을 겪고 계신가요"

✅ "왜 그 제품이나 서비스를 사용하게 되셨나요?"

✅ "마지막으로 그 서비스를 사용했을 때, 어떤 식으로 이용했는지 자세히 설명해주실 수 있나요?"

---

건축가의 질문법

좋은 건축가는 벽돌부터 쌓지 않습니다.
먼저 의뢰인에게 질문부터 합니다.

"어떤 집에 살고 싶으세요?"

이 한마디 안에는 목표, 사용자, 핵심 기능, 제약 조건, 일정이 모두 들어 있습니다.

건축가의 질문	개발자의 질문
몇 명이 사나요?	타깃 사용자는 누구인가요?
어떤 공간이 가장 중요한가요?	핵심 기능은 무엇인가요?
예산은 얼마인가요?	기술 제약과 가용 리소스는 무엇인가요?
언제까지 필요하신가요?	MVP 일정은 언제인가요?

설계도 없이 벽돌부터 쌓으면, 나중에 허물어야 합니다.
코드와 프로젝트도 마찬가지입니다.

인터뷰는 솔루션을 검증하는 과정이 아니라
문제를 발견하는 과정입니다.

---

실전: IDD 인터뷰 시작하기

X에서 220만 뷰, 1만 4천 북마크를 기록한 @trq212의 트윗이 있습니다.
핵심은 단순합니다.
스펙 문서를 바탕으로 AI가 질문하게 만드는 것입니다.

Claude Code에서는 아래 세 줄이면 시작할 수 있습니다.

@SPEC.md를 읽고 AskUserQuestionTool로 저를 인터뷰해 주세요.
기술 구현, UI/UX, 우려 사항, 트레이드오프 등 모든 측면을 심층적으로 다루되,
뻔하지 않은 질문을 해주세요. 인터뷰가 끝나면 스펙을 파일에 작성하세요.

---

피드백 루프가 전부다

많은 사람들이 이렇게 묻습니다.

"일단 만들고 피드백을 받으면 안 되나요?"

물론 가능합니다.
하지만 3개월 동안 개발한 뒤 사용자가 없어 피벗하는 것과,
1주일 인터뷰 후 방향을 수정하는 것은 비용이 전혀 다릅니다.

IDD는 매 단계에서 이전 단계로 돌아갈 수 있도록 설계되었습니다.

• 스펙이 모호하면 → 인터뷰로 돌아갑니다.
• 계획이 흔들리면 → 스펙을 수정합니다.
• 배포 후 지표가 나쁘면 → 다시 인터뷰합니다.

IDD는 완벽함을 목표로 하지 않습니다.
방향을 최적화합니다.

---

내일 당장 시작하는 방법

1. 잠재 사용자 5명을 적어봅니다.

2. 15분 통화/미팅/커피챗을 요청합니다.

3. 이렇게 묻습니다

   "지금 이 문제를 어떻게 해결하고 계세요?"

4. 공통 패턴을 찾습니다

5. 그 내용을 SPEC.md로 정리합니다.

6. 실전: IDD 인터뷰 시작하기 프롬프트로 인터뷰를 진행합니다.

7. SPEC.md가 어느 정도 선명해지면, 그때 코드를 시작합니다.

늦지 않습니다.
오히려 가장 빠른 길입니다.