AI에게 에어비앤비 CEO식 리뷰를 받으며 개발하는 법

📝 한줄 요약

Claude Code에 2단계 기획 리뷰 & 개발 리뷰 스킬을 얹었더니, 코딩 전에 빠진 기획과 기술적 허점을 미리 잡아줘서 에러 없이 한 번에 되는 경우가 확실히 늘었습니다.

🎯 이런 분들께 도움돼요

• Claude Code를 이미 쓰고 있는데, "더 잘 쓰는 방법"이 궁금한 분

• AI한테 코딩은 시키는데 기획/리뷰까지 시킬 수 있다는 걸 몰랐던 분

• 바이브코딩 하다가 에러 지옥에 빠져본 경험이 있는 분

😤 바이브코딩의 함정

계획서가 있는데도 왜 구현하면 에러가 나지? 이게 바이브코딩의 함정이에요. AI가 코드는 잘 짜주는데, 뭘 만들어야 하는지는 내가 정해줘야 하거든요. 근데 그 "뭘"이 모호한 상태로 코딩을 시작하면 삽질이 기하급수적으로 늘어납니다. 아무리 계획을 촘촘히 짜더라도 예상치 못한 빈틈은 생기기 마련이죠.

이 의문을 안고 있던 차에, 에어비앤비 창립자 브라이언 체스키의 방법론을 개발에 도입하는 글을 보았어요. CEO가 디테일에 직접 개입해서 질문을 던지는 방식 — 이걸 AI에게 시키면 어떨까? 마침 이걸 Claude Code 스킬로 만든 사람이 있었습니다.

🛠️ gstack — Y Combinator CEO가 만든 오픈소스 스킬팩

gstack은 Y Combinator 대표 Garry Tan이 만든 Claude Code용 오픈소스 스킬 모음입니다. Palantir 초기 엔지니어이자 Posterous 공동창업자(Twitter 인수)인 그가, YC CEO 업무를 하면서도 60일간 60만 줄 이상의 프로덕션 코드를 작성하며 만든 도구예요.

핵심 철학은 "Claude Code를 가상 엔지니어링 팀처럼 운영하는 것". 15개의 슬래시 커맨드가 각각 CEO, 엔지니어링 매니저, QA 리드 등의 역할을 맡습니다. 저는 이 중 두 가지를 집중적으로 씁니다:

• /plan-ceo-review — CEO/창업자 관점에서 유저 임팩트 리뷰

• /plan-eng-review — 시니어 엔지니어 관점에서 기술 리뷰

관련 게시글

여기에 bkit 플러그인의 /plan-plus(브레인스토밍 기획)를 더해서, 코딩 전에 두 번 리뷰하는 워크플로우를 씁니다.

🔧 이 워크플로우가 "그냥 리뷰해줘"와 다른 이유

CEO 리뷰 — "작게 고치려고 했는데, 제대로 만들게 됐다"

Claude Code한테 "이 계획 검토해줘"라고 하면 "좋은 계획입니다. 몇 가지 개선 사항이 있습니다..." 하고 무난한 답변이 돌아옵니다. /plan-ceo-review가 다른 건, 스킬 안에 구체적인 행동 지침이 들어있기 때문이에요.

특히 강력한 건 SCOPE EXPANSION 모드입니다. 이 모드에서 CEO 리뷰는 세 가지 질문을 순서대로 던집니다:

1. "2배 노력으로 10배 더 좋은 버전은?" — 지금 계획의 확장판을 구체적으로 그려줌

2. "12개월 후 이 시스템의 이상적인 모습은?" — 현재 → 이번 계획 → 미래 비전을 테이블로 정리

3. "30분 이내로 추가할 수 있는 '딜라이트 기회'는?" — 사용자가 "오, 이것까지 생각했네" 하게 만드는 작은 터치들

실제 사례를 보여드릴게요. OAuth 서비스 연결 화면에서 버그가 있었습니다:

연결하기 버튼 누르면 연결은 되는데, 다시 메인 홈에 떨어져. 설정 화면으로 돌아와야하는데. 그리고 동기화를 한 번 더 해줘야 하는 것 같고... 연결된 서비스 순서도 정리됐으면 좋겠어.

제 원래 계획은 "리다이렉트 버그 수정 + 자동 동기화 + 정렬" — 소소한 수정 3개였어요. 여기에 /plan-ceo-review를 돌렸더니 SCOPE EXPANSION 모드가 이렇게 제안했습니다:

10x 점검: 지금 계획은 '수동 → 반자동'으로의 이동입니다. 10x 버전은:

• OAuth 팝업이 열려 있는 동안 해당 카드에 '연결 중...' 스피너 표시

• 연결 완료 후 자동으로 모든 서비스 한 번에 동기화하는 '모두 동기화' 버튼

• 마지막 동기화 시간을 '3시간 전' 같은 상대 시간으로 표시

• 연결 완료 시 카드 테두리가 살짝 빛나는 애니메이션

딜라이트 기회라는 프레임으로 보니까, 이런 작은 터치들이 "다 됐다!"는 느낌을 주는 데 중요하더라고요. 결국 딜라이트 5개 중 2개를 이번에 같이 구현했습니다. 리다이렉트 버그 3개 고치려던 게, 사용자 경험 전체를 다듬는 작업이 됐습니다.

Eng 리뷰 — 코드 작성 전에 버그를 잡는다

"버그 찾아줘"는 코드가 있어야 가능하잖아요. /plan-eng-review는 계획서 단계에서 기술 허점을 잡아줍니다. 설계 → 코드 품질 → 테스트 → 성능, 4개 관점을 순서대로 훑으면서, 안 고치면 어디서 터지는지까지 설명해줘요.

위 기능의 Eng 리뷰에서는 이런 걸 잡았습니다:

• "API 호출과 DB 조회를 순서대로 하면 5초, 동시에 하면 1초" → 나중에 "왜 느리지?" 하며 다시 고칠 뻔한 것

• "30건 배치 처리에서 중복 체크를 건당 DB 호출하면 30번" → 한 번에 조회하는 함수 추가

결과: 빌드 한 번에 성공, 에러 0개.

✏️ 오픈소스 스킬, 나에게 맞게 고쳐 쓰기

gstack이 훌륭하긴 한데, 처음에 불편한 점이 있었습니다.

영어로 질문이 나왔어요. "What is the minimum set of changes that achieves the stated goal?" — 해석부터 해야 하니까 사고의 흐름이 끊기더라고요. 그리고 개발 용어가 너무 많았습니다. "N+1 쿼리 문제가 있습니다", "race condition이 발생할 수 있습니다" 같은 질문이 오면 그게 뭔지부터 찾아봐야 했어요.

Claude Code 스킬은 결국 마크다운 파일이라 편집이 쉽습니다. 세 가지 규칙을 추가했어요:

• 한국어 출력 필수 — 내부 분석은 영어 OK, 나한테 보여줄 때만 한국어

• 전문 용어는 쉬운 설명 병기 — "데이터를 가져올 때 불필요하게 반복 호출하는 문제 (N+1 쿼리)"

• 결과를 먼저 쓰기 — "일부 사용자한테만 먼저 적용해보고, 문제 없으면 전체에 적용합니다 (feature flag)"

바꾸고 나니 리뷰 질문에 "A" 한 글자로 즉답할 수 있게 됐어요. 오픈소스 스킬을 그대로 쓰는 것보다, 나한테 맞게 한 번 다듬으면 체감이 완전히 달라집니다.

✅ 결과 (After)

💬 AI 활용 팁

1. CEO 리뷰 먼저, Eng 리뷰 나중에. "뭘 만들까"를 확정하고 "어떻게 만들까"를 검증하는 순서. 반대로 하면 기술적으로 완벽한데 유저한테 쓸모없는 걸 만들게 됩니다.

2. 작은 기능이라도 리뷰를 거치세요. 매번 뭔가 하나는 잡아줍니다. 귀찮아도 하세요.

3. 오픈소스 스킬은 나에게 맞게 고쳐 쓰세요. 영어 → 한국어, 전문 용어 → 쉬운 표현. 이것만 바꿔도 체감이 다릅니다.

📋 재사용 가능한 프롬프트

순서: 기획이 모호 → /plan-plus로 구체화 → /plan-ceo-review로 유저 관점 검증 → /plan-eng-review로 기술 검증 → 구현

각 스킬은 Plan 문서가 있는 상태에서 슬래시 커맨드로 실행하면 됩니다. gstack은 git clone 한 줄로 30초 만에 설치 가능합니다.