당신은 지금 Claude Code에게 500줄짜리 PRD를 던지고 있다. 그리고 그 절반은 무시당한다. 나머지 절반은 당신이 미처 정하지 못한 부분을 Claude가 알아서 추측해 채운 뒤, 엉뚱한 방향으로 300줄을 짜고, 당신이 "아니 그게 아니라"를 세 번 반복하는 동안 토큰이 타들어간다.
토큰비를 태우는 건 긴 프롬프트가 아니다. 방향이 틀린 채로 돌아가는 코드다. 입력 토큰은 싸다. 잘못 생성된 300줄을 버리고 다시 짜는 출력 토큰, 그걸 위해 파일을 다시 읽는 도구 호출, 그 왕복이 비싸다.
해법은 하나다. 지시를 거꾸로 뒤집어라. 당신이 Claude에게 요구사항을 설명하지 말고, Claude가 당신을 인터뷰하게 하라.
왜 인터뷰가 토큰을 아끼는가
인터뷰 기법이 작동하는 이유는 세 가지다. 셋 다 실제 비용과 직결된다.
1. 값싼 Q&A로 비싼 생성을 대체한다. 질문과 대답은 짧은 턴이다. 코드 생성은 긴 턴이다. 결정을 앞단의 짧은 대화에서 전부 끝내면, 비싼 코드 생성은 딱 한 번, 제대로 일어난다. "짜고 → 틀리고 → 다시 짜고"의 반복이 사라진다.
2. PRD를 당신이 안 써도 된다. 인터뷰가 끝나면 확정된 내용을 Claude가 PRD로 정리한다. 당신은 빈 문서 앞에서 30분을 고민하는 대신, 날아오는 질문에 답만 하면 된다. 문서 작성 노동이 대화로 바뀐다.
3. 당신이 몰랐던 결정을 수면 위로 끌어올린다. 좋은 인터뷰어는 당신이 안 정한 것을 정확히 짚는다. "이 목록이 비었을 땐 뭘 보여줄까요?" "동시에 두 명이 수정하면요?" — 이 질문들은 당신이 PRD에 절대 안 적었을 것들이고, Claude가 침묵 속에서 마음대로 정했을 것들이다. 방향을 당신 쪽으로 고정하는 건 바로 이 질문들이다.
한 줄로 요약하면 이렇다. 결정을 코드보다 먼저, 그리고 값싼 대화 안에서 끝내라.
바로 쓰는 인터뷰 프롬프트 10개
복사해서 그대로 쓰면 된다. 세 국면으로 나눴다 — 시작 전(요구사항 뽑기), 진행 중(방향 유지), 끝난 뒤(디버깅·회고).
A. 시작 전 — 요구사항을 심문으로 뽑아낸다
① 착수 금지 + 인터뷰 시작
바로 코드 짜지 마. 이 기능을 구현하기 전에 네가 나를 인터뷰해. 요구사항·제약·엣지케이스를 확정하는 데 필요한 질문을 한 번에 하나씩, 가장 중요한 것부터 물어봐. 내 답이 모호하면 다시 파고들어. 더 물을 게 없으면 "인터뷰 종료"라고 말하고 확정된 요구사항을 요약해.
가장 기본이자 가장 강력한 프롬프트다. "한 번에 하나씩"이 핵심 — 질문 20개를 한꺼번에 던지면 당신도 대충 답하게 된다.
② 결정하지 말고 선택지를 내놔라
내가 안 정한 걸 네가 대신 정하지 마. 결정이 필요한 지점마다 멈추고, 2~3개 선택지를 트레이드오프와 함께 제시한 뒤 내 선택을 기다려.
Claude가 조용히 기본값을 고르는 걸 막는다. 라이브러리 선택, 데이터 구조, 상태 관리 방식 — 전부 당신이 고르게 된다.
③ 코드베이스부터 읽고 질문하라
먼저 이 레포를 훑어봐. 그다음 이 기능이 기존 구조와 충돌하거나, 내가 몰랐던 결정을 강요하는 지점을 질문 목록으로 만들어. 코드는 그 질문이 다 풀린 뒤에.
기존 프로젝트에 기능을 얹을 때 필수. 컨벤션을 무시한 코드가 나오는 걸 원천 차단한다.
④ 엣지케이스 심문
이 기능의 happy path는 명확해. 이제 나를 심문해서 내가 놓친 엣지케이스·실패 모드·경계 조건을 끄집어내. 각 케이스마다 "이럴 땐 어떻게?"로 물어.
빈 상태, 동시성, 권한 없음, 네트워크 실패 — 나중에 버그로 돌아올 것들을 앞에서 잡는다.
⑤ 인터뷰를 PRD로 굳혀라
방금 인터뷰에서 확정된 내용을 PRD로 정리해. 목표 / 비목표 / 요구사항 / 엣지케이스 / 완료 기준 순으로. 이 문서를
docs/에 저장하고 앞으로 이 작업의 기준 문서로 삼아.
이제 PRD가 생겼다. 당신이 한 글자도 안 쓰고. 비목표(Non-goals) 항목을 꼭 넣게 하라 — 안 할 일을 명시하는 게 할 일을 적는 것보다 방향을 더 강하게 고정한다.
B. 진행 중 — 방향을 계속 내 쪽으로 잡는다
⑥ 계획 먼저, 승인 후 실행
구현 계획을 단계별로 먼저 보여줘. 각 단계에서 어떤 파일을 어떻게 바꿀지. 내가 "진행"이라고 하기 전엔 코드를 쓰지 마.
계획은 읽고 고치기 싼 몇 줄이다. 코드는 비싸다. 틀린 방향은 계획 단계에서 잡는 게 100배 싸다.
⑦ 모르면 지어내지 말고 물어봐
확신이 안 서는 지점을 추측으로 채우지 마. 모르는 값, 불명확한 요구사항, 존재를 확인 못 한 API가 나오면 멈추고 나에게 물어.
환각으로 인한 재작업을 막는 안전장치. 존재하지 않는 함수를 지어내 30줄을 짜는 사고를 예방한다.
⑧ 내 코드 취향을 인터뷰해서 CLAUDE.md로
내 코드 취향을 인터뷰해. 네이밍, 파일 구조, 에러 처리, 테스트 방식, 주석 밀도에서 내가 선호하는 걸 질문으로 뽑아낸 뒤, 답변을
CLAUDE.md로 정리해. 앞으로 이걸 따라.
한 번 하면 계속 남는다. 프로젝트마다 같은 잔소리를 반복할 필요가 없어진다.
C. 끝난 뒤 — 디버깅과 회고
⑨ 디버깅도 역질문부터
바로 고치려 들지 마. 이 버그에 대해 나를 인터뷰해서 재현 조건·최근 변경·관측된 증상을 좁혀. 가설을 세우고, 가능성 높은 것부터 하나씩 검증할 계획을 제시해.
"고쳐줘" 한마디에 Claude가 이 파일 저 파일 헤집으며 토큰을 태우는 걸 막는다. 진단을 먼저 시킨다.
⑩ 회고 인터뷰로 다음을 개선
이 작업 끝났어. 나를 인터뷰해서 무엇이 잘 됐고 어디서 네가 헛다리를 짚었는지 정리해. 그 교훈을 다음에 반복 안 하도록
CLAUDE.md에 규칙으로 추가해.
세션을 자산으로 바꾼다. 오늘의 실수가 내일의 규칙이 되면, 같은 토큰을 두 번 태우지 않는다.
이걸 매번 치기 귀찮다면 — 습관으로 굳혀라
10개를 손으로 칠 필요는 없다. 두 곳에 박아두면 기본 동작이 된다.
첫째, CLAUDE.md에 원칙으로 넣는다.
## 작업 원칙
- 새 기능·버그를 시작할 때는 코드보다 먼저 나를 인터뷰한다.
- 질문은 한 번에 하나씩, 중요한 것부터.
- 내가 안 정한 결정은 선택지로 제시하고 승인을 기다린다.
- 모르는 건 추측하지 말고 멈춰서 묻는다.
둘째, 자주 쓰는 인터뷰 프롬프트를 슬래시 커맨드로 만든다. .claude/commands/interview.md에 프롬프트 ①을 저장하면, 이제 /interview만 치면 된다.
바로 코드 짜지 마. 이 기능을 구현하기 전에 네가 나를 인터뷰해.
요구사항·제약·엣지케이스를 확정하는 데 필요한 질문을 한 번에 하나씩,
가장 중요한 것부터 물어봐. 더 물을 게 없으면 "인터뷰 종료"라고 말하고
확정된 요구사항을 요약해.
정리 — 지시하지 말고 심문당하라
Claude Code를 잘 쓰는 사람과 못 쓰는 사람의 차이는 프롬프트를 얼마나 길게 쓰느냐가 아니다. 결정을 코드보다 먼저 끝내느냐다.
- PRD를 던지지 말고, 인터뷰당하라 → 문서 노동이 대화로 바뀐다
- 결정을 맡기지 말고, 선택지를 받아라 → 방향이 당신 쪽에 고정된다
- 짜기 전에 계획을 승인하라 → 틀린 방향을 값싼 단계에서 버린다
이 세 가지만 지켜도 재작업이 사라지고, 재작업이 사라지면 토큰비가 준다. 오늘 다음 기능을 시작하기 전에 딱 한 문장만 먼저 쳐보라. "바로 짜지 마. 나를 인터뷰해."
AX LABS는 이런 에이전트 활용 방식을 대기업 임원과 실무진에게 현장에서 가르친다. 조직이 Claude Code를 자기 언어로 다루기 시작하면, AI 도입은 그때부터 운영에 정착한다.
