Claude Code 워크플로우 (2) — gstack `/office-hours`로 AI에게 제품 인터뷰를 받아봤다

시리즈 로드맵

• (1) gstack + Superpowers — 두 플러그인만 남긴 이유
• (2) gstack /office-hours로 AI에게 제품 인터뷰를 받아봤다 ← 현재 글
• (3) Boris Cherny "Why Coding Is Solved" 강연 후기 — YC와 loop 워크플로우

TL;DR

• gstack의 /office-hours는 코드를 짜기 전에 Claude가 PM처럼 인터뷰를 진행해주는 명령어다.
• 직접 받아보니 가장 강한 느낌은 "내가 아이디어를 얼마나 모호하게 갖고 있었는지"가 드러난다는 점이었다.
• 인터뷰 자체보다 답변하는 동안 스스로 정리되는 효과가 더 컸다. 사람이 하는 인터뷰와 결정적으로 다른 점이 여기에 있다.
• 결과물은 단순한 회의록이 아니라 "합의된 전제 + 다음 한 주 과제"로 떨어진다. 이게 코드 작성 전에 손에 쥐어진다는 게 핵심이다.

환경

• Claude Code (글로벌 설치)
• gstack: ~/.claude/skills/gstack/
• 인터뷰 대상 프로젝트: StudOX (PDF 학습 자료에서 OX 퀴즈를 자동 생성·복습하는 Electron 데스크톱 앱)
• 인터뷰 진행일: 2026-04-08
• 소요 시간: 약 30분

/office-hours가 뭔가

gstack에 포함된 슬래시 커맨드입니다. 실행하면 Claude가 창업 액셀러레이터의 오피스 아워에 온 PM처럼 질문을 던지기 시작합니다. "뭘 만들고 싶어?"가 아니라 "누가 이걸 정말 필요로 하는지 근거가 뭐야?" 식으로요.

저는 처음에 "AI한테 인터뷰 받는다는 게 뭐 다를 게 있겠나" 싶었습니다. 그런데 30분쯤 지나고 나니 손에 인터뷰 정리본이 한 장 남았는데, 이게 단순한 회의록이 아니었습니다.

인터뷰가 어떻게 진행되는가

순서는 대략 이렇습니다.

1. 프로젝트 한 줄 소개 → Claude가 핵심 포지셔닝 질문
2. 수요 근거(Demand Evidence) → "정말 원한다는 증거가 뭐야?"
3. 현재 대안(Status Quo) → "지금은 어떻게 해결하고 있어?"
4. 타깃 유저 → "구체적으로 누구야?"
5. 경쟁 환경 → "이미 있는 도구들과 뭐가 달라?"
6. 합의된 전제 → 지금까지 나온 답을 표로 정리
7. 다음 한 주 과제 → "이번 주에 뭐 할래?"

각 단계에서 Claude는 만족할 만한 답이 나올 때까지 한두 번 더 압박합니다. "그건 너무 모호한데, 더 구체적으로 말해봐"가 자주 나옵니다.

강했던 질문 3개

전체 흐름 중에서 답하기 어려웠던 질문이 세 개였습니다. 어려웠다는 건, 그 영역을 제가 제대로 정리하지 못한 채 시작하려 했다는 뜻입니다.

1. "누군가가 이걸 정말 원한다는 가장 강한 근거는?"

처음엔 "사람들이 PDF 공부할 때 퀴즈 만들고 싶어 하잖아요"라고 답했습니다. Claude의 반응은 *"그건 너의 추측이지, 근거가 아니다"*에 가까웠습니다. 답변을 바꿔야 했습니다.

최종 답변은 *"친구/동기들이 시험 공부 중 직접 요청했고, NotebookLM을 쓰면서 '오답노트가 없다'는 구체적 불만을 토로했다"*로 좁혀졌습니다.

이때 깨달은 것: "사람들이 원할 것 같다"와 "특정인이 active pain 상태에서 요청했다"는 완전히 다른 신호입니다. 후자만 진짜 수요 신호입니다.

2. "지금 이 문제를 어떻게 해결하고 있는가?"

이 질문이 의외로 컸습니다. "아무도 안 풀고 있다"고 답하려다 멈췄습니다. 진짜로 그런가? 다시 보니 NotebookLM을 이미 쓰고 있고, 거기서 막힌 부분이 있다가 정확한 답이었습니다.

"아무것도 없다"가 아니라 "있는데 부족하다" — 이게 훨씬 좋은 출발점이라는 걸 이때 알게 됐습니다. 사용자가 이미 행동하고 있다는 뜻이고, 대체 비용도 낮다는 뜻이니까요.

3. "구체적으로 누가 이걸 가장 필요로 하는가?"

"공부하는 사람들"이라고 답했더니 *"그건 6천만 명이다"*라는 식의 압박이 왔습니다. 좁혀야 했습니다.

세 번 정도 좁힌 끝에 "고시·편입 준비생 (하루 10시간+, 수개월~수년 단위 PDF 교재 학습)"이 나왔습니다. 이 정도까지 좁히고 나니, 그 사람들에게 닿을 수 있는 채널(고시 카페, 독서실, 편입 학원)도 같이 떠올랐습니다. 타깃이 흐릿할 땐 채널이 안 보이고, 타깃이 또렷해지면 채널이 따라옵니다.

AI 인터뷰가 사람과 다른 점

받기 전엔 "그래 봐야 ChatGPT랑 한 번 더 말하는 거 아닌가" 싶었는데, 끝나고 나니 결정적으로 다른 점이 두 개 있었습니다.

첫째 — 답변하는 사람이 정리된다

사람과의 인터뷰는 인터뷰어가 정보를 모으는 활동입니다. 답하는 쪽은 "내가 아는 걸 말하는" 입장이라서 새로 정리되는 건 적습니다.

/office-hours는 반대였습니다. 답하는 동안 내가 정리됐습니다. 질문을 받고 입력하는 그 30초 동안, 머릿속에서 "어, 잠깐. 내가 이걸 왜 만들고 있더라?"가 자주 나왔습니다.

곰곰이 생각해보니 이건 새로운 현상이 아닙니다. "질문 받으면서 스스로 정리되는 경험"은 좋은 시니어와 1:1을 할 때 흔히 일어나는 일이고, 더 옛날로 가면 코칭이나 상담의 핵심 메커니즘이기도 합니다. 다만 그런 시니어/코치의 시간은 비싸고 약속을 잡아야 하는데, AI는 30분짜리 슬롯을 즉시 만들어줍니다. 이게 차별점이라면 차별점입니다.

둘째 — 결과물의 형식이 강하다

사람과의 인터뷰는 보통 메모로 끝납니다. 내가 다시 정리해야 회의록이 됩니다.

/office-hours는 끝나면 자동으로 다음 형식이 손에 쥐어집니다.

## 합의된 전제 (Premises)
| # | 전제 | 상태 |
|---|------|------|
| 1 | 핵심 가치는 오답노트 시스템이지, 퀴즈 생성이 아니다 | 합의 |
| 2 | 고시/편입 준비생이 첫 번째 타겟 시장이다 | 합의 |
| ...

## 핵심 과제 (The Assignment)
> 이번 주: 고시/편입 준비생 5명을 찾아서 StudOX를 줘라.
> 옆에서(또는 화면공유로) 처음 사용하는 걸 지켜봐라.
> 도와주지 마라. 설명하지 마라.
> 가장 중요한 관찰 포인트: 오답노트를 스스로 열어보는가, 아니면 무시하는가?

"합의된 전제"와 "이번 주 과제" — 이 두 섹션이 자동으로 떨어지는 게 핵심입니다. 코드를 짜기 전에 무엇이 합의됐고, 무엇을 검증해야 하는지가 글로 정리돼 있습니다.

실제로 받은 과제

인터뷰 끝에 받은 과제는 *"이번 주에 코드 더 쓰지 말고, 5명에게 줘봐라"*였습니다.

저는 인터뷰 들어갈 때 *"오답노트 화면을 메인으로 승격하면 좋을까?"* 같은 기능 단위 질문을 가지고 있었는데, 결론은 "그 질문에 답하기에 충분한 사용자 데이터가 없다"였습니다.

3가지 옵션이 제시됐습니다.

	접근	기간	리스크
A	오답노트 Deep — 메인 화면 승격, 간격 반복 등	1~2주	낮음
B	백엔드 구축 + 커뮤니티 기능	3~4주	중간 (사용자 없이 인프라 위험)
C	5명 테스트 — 아무것도 만들지 말고 관찰	이번 주	낮음

C → A 순서로 결론이 났습니다. 즉, 만들기 전에 본다가 우선이고, 본 결과를 바탕으로 오답노트를 메인으로 승격할지 결정하는 흐름입니다.

이게 인터뷰의 효용이라고 생각합니다. 들어갈 때 "기능 우선순위"를 묻고 있던 사람이, 나올 땐 "검증 우선순위"를 들고 나옵니다. 질문의 층이 한 단 위로 올라갑니다.

한계와 남은 의문

• AI는 진짜 사용자가 아닙니다. /office-hours가 잘 잡아주는 건 "내 사고의 공백"이지, "시장의 공백"이 아닙니다. 결국 진짜 인터뷰는 5명에게 직접 줘보고 옆에서 보는 일로만 가능합니다. 인터뷰는 그 진짜 인터뷰를 잘 설계하기 위한 사전 단계입니다.
• 답변자가 솔직해야 효용이 납니다. Claude는 "그럴듯한 답"이 들어오면 더 압박하지 않고 넘어가기도 합니다. 모르는 건 모른다고, 추측은 추측이라고 표시하는 솔직함이 결과물의 품질을 좌우합니다.
• 포맷이 너무 강하다는 점은 양날의 검입니다. "수요 근거 → 대안 → 타깃 → 경쟁 → 전제 → 과제" 흐름이 깔끔하지만, 이 틀에 안 맞는 종류의 프로젝트(예: 인프라 도구, 내부 툴)에는 어색할 수 있습니다. 그런 경우엔 인터뷰 도중에 "이 질문은 우리 케이스에 안 맞아"라고 명시하고 넘어가는 게 낫습니다.
• 인터뷰 결과를 신성시하면 안 됩니다. 합의된 전제는 "지금까지 합의된 것"일 뿐이고, 5명 테스트 후에 첫 번째로 바뀌어야 할 것이 바로 이 전제 표입니다. 살아있는 문서로 다뤄야 합니다.

핵심 정리

• /office-hours는 코드 짜기 전 30분짜리 PM 인터뷰다. AI가 액셀러레이터 오피스 아워처럼 질문을 던진다.
• 인터뷰의 진짜 효용은 답하는 동안 스스로 정리되는 것이다. 인터뷰어가 정보를 얻기보다, 답변자가 자기 사고의 공백을 발견하는 도구다.
• 강했던 질문 3개: "수요 근거", "현재 대안", "구체적 타깃". 이 셋에 막히면 만들기 시작하면 안 된다.
• 결과물은 회의록이 아니라 "합의된 전제 표 + 이번 주 과제" 형태로 떨어진다. 코드를 짜기 전에 손에 쥐어진다는 게 핵심.
• 들어갈 땐 기능 우선순위를 묻던 사람이, 나올 땐 검증 우선순위를 들고 나온다. 질문의 층이 한 단 올라간다.

참고 자료

• 시리즈 (1)편: gstack + Superpowers 두 플러그인만 남긴 이유
• gstack: garrytan/gstack
• 영감을 받은 원칙: Y Combinator — "Make Something People Want"
• 관련 노트: [[Office Hours 인터뷰 정리 (2026-04-08)]], [[Claude Code 플러그인 워크플로우 (gstack + Superpowers)]]

다음 글

(3)편에서는 이 인터뷰 경험과 정확히 맞물리는 강연을 다룹니다. Anthropic의 Boris Cherny가 AI Ascent 2026에서 한 "Why Coding Is Solved" 발표인데, 거기서 "사용자 인터뷰가 곧 프롬프트 설계"라는 통찰이 나옵니다. (2)편에서 느낀 감각이 더 큰 그림으로 연결되는 지점입니다.

---