[Claude] Claude Code gstack /office-hours 스킬 활용 및 설치 방법

이번 글에서는 gstack의 '/office-hours' 스킬을 살펴보고자 합니다.

 

gstack은 Y Combinator의 Garry Tan이 공개한 Claude Code 스킬 모음입니다. Claude를 CEO·디자이너·엔지니어링 매니저·QA 같은 역할로 분리해 가상의 개발팀처럼 굴리는 게 골자입니다. Claude Code를 일차 타깃으로 하지만 setup 스크립트는 Codex, Cursor 같은 다른 코딩 에이전트 환경에도 붙일 수 있도록 구성되어 있습니다. gstack에 포함된 다수의 스킬 중 하나가 `/office-hours`입니다. 코드를 짜기 전 단계에서 동작하는 스킬로, "이거 만들 가치가 있나"를 같이 따져주는 brainstorming 파트너 역할을 합니다.

 

1. 어떤 상황에서 호출되는가

`/office-hours`는 구현 단계가 아니라 그 앞에 붙는 스킬입니다. 다음과 같은 입력에서 자동으로 활성화되도록 설계되어 있습니다.

 

• "이거 좀 brainstorm 해줘"
• "아이디어가 하나 있는데"
• "이거 만들 만한 가치가 있을까"
• "이 디자인 좀 같이 생각해 줘"

 

반대로 코드가 이미 있는 리팩토링이나 버그 수정에는 호출되지 않습니다. 출력물도 의도적으로 코드가 아닙니다. SKILL.md에는 "구현 스킬을 절대 호출하지 말 것, 코드를 작성하지 말 것"이라는 hard gate(예외 없이 막아두는 차단선)가 명시되어 있습니다. 결과물은 디자인 문서 한 장입니다.

 

데이터 사이언스 쪽에서 보면 노트북을 켜기 전 EDA 가설 정리를 같이 해주는 짝꿍에 가깝습니다. 모델 구조나 파이프라인을 짜기 전에 "이 문제를 푸는 게 정말 가치 있나"를 한 번 걸러주는 게이트 역할을 합니다.

 

2. Startup Mode와 Builder Mode

스킬은 사용자의 의도를 먼저 묻고 두 모드 중 하나로 분기합니다.

 

Startup Mode는 창업자나 사내 신사업 담당자용입니다. 아래 6가지 forcing question(피해 갈 수 없는 압박 질문)을 하나씩 던집니다.

 

1. Demand Reality - "원한다"가 아니라 "필요하다"는 증거가 있는가
2. Status Quo - 사람들이 지금은 어떤 임시방편으로 견디고 있는가
3. Desperate Specificity - 이걸 가장 필요로 하는 실제 사람의 이름을 대볼 수 있는가
4. Narrowest Wedge(가장 좁게 파고들 수 있는 진입점) - 이번 주에 돈을 받을 수 있는 가장 작은 버전은 무엇인가
5. Observation - 남들이 못 본 걸 직접 목격한 적이 있는가, 누군가 이걸 쓰는 모습에서 의외였던 점은 무엇이었는가
6. Future-Fit - 3년 뒤 이 문제는 더 중요해지는가, 덜 중요해지는가

 

Builder Mode는 해커톤·오픈소스·학습용 프로젝트 같이 시장 검증 부담이 덜한 빌더용입니다. 같은 진단 자리에 더 발산적인 질문이 들어옵니다. "이 아이디어의 가장 멋진 버전은 어떤 모양인가", "이미 있는 도구 중 어디에 얹는 게 가장 빠른가", "10배로 키우면 어떻게 되는가" 같은 식입니다.

 

두 모드 모두 어떤 입장으로 이 아이디어를 들고 왔는지를 1단계에서 직접 명시하게 만듭니다.

 

3. 6단계 워크플로우

전체 흐름은 6단계로 고정되어 있습니다. 아래 단계명은 SKILL.md의 Phase 1~6 명칭을 가독성을 위해 의역해 정리한 것입니다.

 

Phase 1. Context Gathering    : CLAUDE.md / TODOS.md 훑기 + 의도 파악
Phase 2. Mode Diagnostic      : Startup 6문항 또는 Builder 발산 질문
Phase 3. Premise Challenge    : 핵심 가정 깨기, 기존 코드 재사용 가능성, 유통 경로
Phase 4. Alternatives         : 최소/이상/창의 3가지 안 제시 → AskUserQuestion으로 선택
Phase 5. Design Document      : 마크다운 디자인 문서 작성, DRAFT → APPROVED
Phase 6. Handoff              : 사용 횟수에 따라 다른 마무리 메시지

 

여기서 AskUserQuestion은 gstack 스킬이 사용자 선택을 받기 위해 사용하는 내장 도구 이름입니다. YC 식 멘토링을 그대로 옮겨놓은 듯한 흐름이라 6단계 자체가 일종의 mini Y Combinator office hour처럼 느껴지기도 합니다.

 

Phase 3의 Premise Challenge가 특히 단단합니다. "이거 정말 새로 만들어야 하나, 기존 라이브러리에 얹으면 안 되나", "만들고 나면 누구한테 어떻게 도달시킬 건가" 같은 질문이 자동으로 따라붙습니다. 옵션으로 Codex나 Claude 서브에이전트를 불러 second opinion을 받게 되어 있습니다. gstack 자체가 한 명의 Claude를 여러 역할로 쪼개어 굴리는 multi-agent 구조 위에 설계된 만큼, 이 second opinion 호출도 그 설계의 자연스러운 연장선입니다.

 

Phase 4는 최소 2개 안을 제시합니다. 비자명한 설계에는 3개를 권장합니다. 가장 빠른 안, 가장 깔끔한 안, 그리고 선택적으로 가장 lateral(사고를 비트는)한 안입니다. 한 안만 들이밀면 안 되는 이유는 단순합니다. 비교 대상이 있어야 의사결정이 가능해지기 때문입니다.

 

Phase 5에서 만들어지는 디자인 문서는 SKILL.md의 경로 규칙에 따라 `~/.gstack/projects/{slug}/` 아래에 `design-{timestamp}.md` 형태로 저장됩니다(파일명 규칙은 버전에 따라 브랜치/사용자명이 prefix로 붙기도 합니다). 같은 브랜치에서 다음 디자인이 나오면 이전 문서를 supersede하는 방식이라 이력이 남습니다.

 

4. 디자인 문서에 들어가는 항목

산출물의 골격은 정해져 있습니다. 작성 도중 adversarial spec review(반대 입장에서 명세를 깎아내는 검토) 루프가 최대 3회까지 돌며 빈칸이나 모호한 표현을 잡아냅니다.

 

• Problem Statement: 풀려는 문제를 한 문단으로 압축
• Demand Evidence: "원한다"가 아닌 "필요하다"는 근거
• Target User: 가상의 페르소나가 아닌 구체적 사용자
• Premises: 이 디자인이 성립하기 위한 전제 조건
• Recommended Approach: 3개 안 중 추천안과 그 이유
• Open Questions: 아직 답하지 못한 질문 목록
• Success Criteria: 성공/실패를 판가름할 측정 기준
• Distribution Plan: 만든 뒤 어떻게 사용자 손에 들어가는가
• Assignment: 다음 단계에서 호출할 구현 스킬 지정

 

마지막의 Assignment 항목이 실용적입니다. 여기에는 다음에 호출할 스킬이 아니라 "고객 3명에게 프로토타입 시연 후 반응 기록하기"처럼 현실에서 취할 구체적 행동 하나를 적습니다. 구현 착수보다 검증 행동을 우선하는 설계입니다. `/office-hours`가 끝나면 디자인 문서를 `/plan-ceo-review`, `/plan-eng-review` 같은 다음 스킬이 자동으로 찾아가므로 문서 자체가 다음 작업의 입력이 됩니다.

5. Anti-Sycopahncy 룰

스킬 정의에서 눈에 띄는 부분은 anti-sycophancy 섹션입니다. AI 특유의 두루뭉술한 동의 문장을 명시적으로 금지합니다.

 

• "That's interesting"
• "There are many ways to think about this"
• "You might want to consider"
• "That could work"
• "I can see why you'd think that"

 

대신 입장을 잡고, 근거를 요구하고, 모호한 표현을 구체화하라는 지침이 들어 있습니다. 일반 Claude Code 세션이 어떤 아이디어든 일단 좋다고 받아주는 경향이 있다면, `/office-hours`는 의도적으로 반대 방향으로 튜닝된 스킬입니다. 만들고 싶은 걸 그대로 인정받고 싶을 때보다 진짜로 검증받고 싶을 때 호출해야 의미가 있습니다.

 

Phase 6의 마무리 메시지도 사용 횟수에 따라 톤이 다릅니다. 첫 세션은 강점을 짚어주는 introduction tier, 2~3회차는 welcome-back tier, 4~7회차는 패턴을 돌아보는 regular tier, 8회 이상은 데이터로만 말하는 inner_circle tier입니다. 익숙해질수록 군더더기를 빼는 구조입니다.

6. 설치와 호출

gstack 설치는 한 줄로 끝납니다. 아래 명령은 저장소를 `~/.claude/skills/gstack/` 아래로 얕은 클론으로 받고, `setup` 스크립트가 각 스킬을 Claude Code가 인식하는 위치로 심볼릭 링크해 줍니다. 설치 위치는 권장 경로일 뿐이고 다른 디렉토리에 클론한 뒤 `./setup`만 실행해도 결과는 같습니다.

 

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

호출은 일반 슬래시 커맨드와 같습니다.

 

/office-hours

 

또는 자연어로 "이 아이디어 좀 brainstorm 해줘"라고 입력해도 트리거 됩니다. 결과 디자인 문서는 `~/.gstack/projects/` 아래에 누적되므로 나중에 같은 주제를 다시 다룰 때 이전 진단을 참고하기 좋습니다.

 

`/office-hours`는 Claude Code를 코드 생성 도구가 아니라 검증 파트너로 쓰는 스킬입니다. 6단계 진단을 거쳐 디자인 문서를 만들고, 그 문서가 다음 구현 스킬의 입력이 되는 구조라 gstack 워크플로의 진입점 역할을 합니다.

 

작업 중인 분야가 아이디어를 빠르게 코드로 옮기기 쉬운 쪽이라면, 한 단계 앞에 검증 게이트를 두는 것만으로도 만드는 것의 총량이 줄어듭니다. 만들기 전에 정말 만들 가치가 있는지 같이 확인할 사람이 필요할 때 한 번 사용해 볼 만한 스킬입니다.

 

📌 Claude Code 관련 글 모음

• Claude Code 2.0 설치 방법 (Windows)
• Claude Code 토큰 사용 팁 정리
• Claude Code에서 Subagent 생성 및 활용하는 방법
• Claude Code 자주 사용하는 명령어 정리
• Claude Code에서 Skills 활용하는 방법

 

<참고>

1. garrytan/gstack GitHub 저장소
2. gstack /office-hours SKILL.md
3. GStack 공식 사이트
4. Garry Tan open-sources gstack - Augment Code
5. gstack: Installing Garry Tan's Claude Code Setup in One Click - SitePoint