YC 오피스 아워 (Office Hours)
핵심 개념
두 가지 모드
스타트업 모드 (Startup Mode)
YC 파트너가 창업자에게 던지는 것으로 유명한 6개의 강제 질문을 적용한다. 이 질문들은 "멋진 아이디어"를 "실제로 동작하는 사업"으로 검증하는 필터 역할을 한다.
| 질문 프레임 | 목적 | 예시 |
|---|---|---|
| 수요 현실 (Demand Reality) | "지금 이걸 원하는 사람이 실제로 있는가?" | 10명에게 물어봤나? 돈을 낼 의향이 있다고 했나? |
| 상태 유지 (Status Quo) | "지금은 어떻게 하고 있나?" | 엑셀로 관리하나? 카카오톡으로 공유하나? |
| 절박한 구체성 (Desperate Specificity) | "가장 고통받는 한 사람은 누구인가?" | 동아리 회장 중 가장 공지 관리로 고통받는 사람 |
| 가장 좁은 쐐기 (Narrowest Wedge) | "MVP로 해결할 수 있는 가장 작은 문제는?" | 공지 업로드만, 멤버 가입은 나중에 |
| 관찰 (Observation) | "이걸 쓰는 사람을 직접 본 적 있나?" | 실제로 회장님이 공지를 어떻게 올리는지 지켜봤나? |
| 미래 적합성 (Future-Fit) | "이 방향이 3년 뒤에도 의미있나?" | 슬랙/디스코드가 대체하지 않을 이유는? |
빌더 모드 (Builder Mode)
스타트업 수익보다 학습·구현·공유에 집중하는 사이드 프로젝트, 해커톤, 오픈소스 맥락에서 디자인 씽킹 방식으로 브레인스토밍을 진행한다.
- 공감 (Empathize): 사용자(또는 자신)의 불편을 구체적으로 표현한다.
- 정의 (Define): 해결하려는 문제를 한 문장으로 명확히 한다.
- 발산 (Ideate): 제약 없이 아이디어를 넓게 탐색한다.
- 프로토타입 (Prototype): 가장 작은 단위의 구현 계획을 그린다.
- 테스트 (Test): 누구에게, 어떻게 검증할 것인지 정한다.
세션 마지막에 **설계 문서(design doc)**를 저장해 후속 /plan-ceo-review, /plan-eng-review의 입력으로 활용한다.
plan 스킬들과의 연계
office-hours (아이디어 검증)
↓
plan-ceo-review (비즈니스 타당성 검토)
↓
plan-eng-review (기술 실현 가능성 검토)
↓
executing-plans (실제 구현)office-hours는 이 파이프라인의 가장 첫 관문이다. 여기서 아이디어가 통과하지 못하면 뒤의 단계에서 시간을 낭비하지 않을 수 있다.
한 줄 요약
스타트업 모드와 빌더 모드 두 가지로 구동되는 아이디어 검증 스킬로, Y Combinator(YC) 오피스 아워 스타일의 날카로운 질문으로 수요 현실·상태 유지·가장 좁은 쐐기를 탐색하거나, 디자인 씽킹 방식으로 사이드 프로젝트·해커톤·오픈소스 아이디어를 브레인스토밍하고 설계 문서를 저장한다.
프로젝트에 도입하기
bash
/office-hoursSKILL.md 파일 위치: ~/.claude/skills/office-hours/SKILL.md
커스터마이징이 필요하면 SKILL.md 내용을 복사 후 수정한다.
실전 예제 (대학생 관점)
상황: 동아리 공지 게시판 프로젝트를 개발하면서, 공지 외에 "동아리 부원 설문 기능"을 추가하면 어떨까 하는 아이디어가 생겼다. 개발을 시작하기 전에 검증이 필요하다.
시나리오 1: 스타트업 모드로 수요 검증
> 동아리 부원 대상 설문 기능을 공지 게시판에 추가하려고 해.
만들 가치가 있을지 오피스 아워 해 줘.Claude가 던지는 YC 스타일 강제 질문들:
[수요 현실]
Q: 지금 동아리에서 설문을 어떻게 하고 있나요?
A: 구글 폼 링크를 카카오톡에 올린다...
→ 인사이트: 이미 구글 폼이라는 "작동하는" 솔루션이 있다.
새 기능이 구글 폼보다 확실히 나은 이유가 있어야 한다.
[절박한 구체성]
Q: 지금 설문 방식으로 가장 고통받는 사람은 누구인가요?
A: 총무 담당자. 구글 폼 결과를 다시 엑셀에 정리해야 한다...
→ 인사이트: 핵심 페인은 "설문 생성"이 아니라 "결과 집계·관리"다.
이걸 해결하는 것이 더 가치 있을 수 있다.
[가장 좁은 쐐기]
Q: MVP로 만들 수 있는 가장 작은 기능은?
A: 예/아니오 투표 기능 (공지에 첨부)
→ 인사이트: "설문 플랫폼 전체"가 아니라 "공지 찬반 투표" 하나가 MVP.
이걸로 수요가 있는지 먼저 확인하자.시나리오 2: 빌더 모드로 해커톤 아이디어 탐색
> 다음 주 해커톤에서 "캠퍼스 내 유실물 찾아주기 앱"을 만들어 보고 싶어.
빌더 모드로 아이디어 정리해 줘.Claude가 진행하는 디자인 씽킹 세션:
[공감]
대학교에서 물건을 잃어버렸을 때 어떻게 하나요?
- 학생처 게시판에 손으로 쓴 공고
- 에브리타임·카카오톡 그룹채팅 공지
- 그냥 포기
[정의]
"캠퍼스에서 물건을 잃거나 찾았을 때,
신고·조회·연결이 한 곳에서 빠르게 되지 않는 문제"
[발산]
아이디어 목록:
1. 사진 + 위치 태그로 유실물 신고
2. AI 이미지 매칭 (잃어버린 물건 사진 vs 발견된 물건 사진)
3. QR 코드 분실물 태그
4. 익명 연락 채널 (번호 노출 없이)
5. 학교 구역별 분실 핫스팟 지도
[프로토타입 — 24시간 해커톤 MVP]
- 공지 게시판 코드베이스(Next.js 15 + Supabase) 재활용
- 핵심: 사진 업로드 + 위치(건물) 선택 + 연락 방법(오픈 채팅 링크)
- 제거: AI 이미지 매칭 (시간 부족), QR 태그 (물리적 물건 필요)
[테스트]
- 해커톤 당일 학교 카카오톡 그룹채팅에 링크 공유
- 5명이 24시간 내 실제 게시물을 올리면 성공설계 문서 저장 및 후속 연계
ts
// office-hours가 저장하는 설계 문서 예시 (design-doc.md)
/*
# 유실물 찾기 앱 — 설계 문서
생성일: 2026-04-12
## 문제 정의
캠퍼스에서 물건을 잃거나 찾았을 때, 신고·조회·연결이 한 곳에서 빠르게 되지 않는다.
## 핵심 사용자
잃어버린 학생 (절박함 높음, 빠른 해결 원함)
찾은 학생 (귀찮음 낮추는 것이 중요)
## MVP 기능
1. 유실물 신고 (사진, 건물/위치, 설명, 연락처)
2. 분실물 신고 (사진, 특징, 연락처)
3. 목록 + 검색 (키워드, 건물 필터)
## 기술 스택
- Next.js 15 App Router (공지 게시판 코드 재활용)
- Supabase (DB + Storage for 사진)
- Tailwind CSS + shadcn/ui
## 다음 단계
→ /plan-eng-review 로 기술 구현 계획 검토
*/학습 포인트 / 흔한 함정
- 아이디어를 "검증"하는 것과 "실행"하는 것은 다르다: 많은 대학생이 아이디어가 생기면 바로 코드를 짠다. Office Hours 스킬은 "먼저 물어보는" 습관을 길러준다. YC의 통계에 따르면 많은 스타트업이 "아무도 원하지 않는 것을 만들었기" 때문에 실패한다.
- "좁은 쐐기"가 핵심이다: MVP의 범위를 결정할 때 항상 "이것보다 더 작게 만들 수 없나?"를 자문하자. 해커톤 24시간에 "설문 플랫폼 전체"를 만들려다 망하는 것보다, "공지에 찬반 버튼 하나"를 완성하는 게 낫다.
- 구글 폼이 이미 있다는 것은 좋은 신호이기도 하다: 기존 해결책(상태 유지)이 있다는 것은 문제가 실재한다는 증거다. 기존 방식보다 "10배 나은" 이유를 설명할 수 있다면 가치가 있다.
- 빌더 모드 vs 스타트업 모드 선택: 수익 모델이 없는 학교 프로젝트나 해커톤은 빌더 모드로 시작하자. 수익화, 투자 유치, 실제 서비스 론칭을 목표로 한다면 스타트업 모드로 더 날카롭게 검증해야 한다.
- 흔한 함정 — "친구들이 좋다고 했어요": 지인의 긍정적 피드백은 수요 증거가 아니다. Office Hours 스킬은 "돈을 낼 의향", "지금 대안", "가장 고통받는 사람" 등 더 구체적인 증거를 요구한다.
관련 리소스
- plan-ceo-review — CEO 관점 계획 검토
- plan-eng-review — 엔지니어링 관점 계획 검토
- writing-plans — 구현 계획서 작성
| 항목 | 내용 |
|---|---|
| 원본 URL | https://docs.anthropic.com/en/docs/claude-code/skills |
| 작성자/출처 | Anthropic |
| 라이선스 | 해설 MIT, 원본 참조용 |
| 해설 작성일 | 2026-04-12 |