런칭 전 개밥 먹기, 그리고 Codex에 밤새 맡기기

내가 만든 도구를 내가 먼저 써 보면 무엇이 보일까요? Vooster(부스터) MVP 공개를 앞두고 '개밥 먹기'를 하면서, Claude Code와 찾은 개선점은 findings 문서로, 구현은 그 문서를 묶어 Codex에 넘기는 식으로 일을 나눴어요.

이 노트를 읽고 나면 할 수 있는 것

1. 내 제품을 실제 사용 방식 그대로 써 보는 개밥 먹기 시나리오를 AI와 함께 정하기
2. 논의는 Claude, 구현은 Codex로 나누고 그 사이를 findings·cycle 문서로 잇기
3. 사용자 만족도를 재는 로그를 "해석" 대신 "사실"로 남기도록 정책부터 문서화하기

다시보기: https://youtu.be/UfaTG1pR-A0 (3시간 11분). 말없이 작업하는 구간이 길어서, 아래 목차의 시점으로 건너뛰며 보는 편이 편해요.

목차

• 만들었으면 먼저 먹어 봐요 ▶ 0:04:28
• 얼리 액세스 설문이 와우 모먼트를 알려 줬어요 ▶ 0:20:37
• 만족도는 해석이 아니라 사실로 남겨요 ▶ 0:47:11
• Codex가 화면 작업은 Claude에 넘기게 했어요 ▶ 0:55:16
• 시청자 질문 하나가 랜딩 섹션이 됐어요 ▶ 1:30:46
• 논의는 Claude와, 결과는 문서로 넘겨요 ▶ 1:59:27
• 검증 게이트가 느리면 하네스 전체가 느려져요 ▶ 2:20:23
• 자기 전에 목표를 걸어 둬요 ▶ 3:05:11
• Q&A ▶ 0:56:38
• 오늘 해볼 것 ▶ 3:08:06

만들었으면 먼저 먹어 봐요 ▶ 0:04:28

Vooster는 코딩 에이전트에 연결해 쓰는 AI 에이전트용 기획 하네스예요. 기획과 스펙을 구조화된 데이터로 관리해서, 에이전트가 모호한 요구사항으로 바로 코드를 짜지 않게 붙잡아 줘요. 방송 전에 랜딩 페이지를 만들어 얼리 액세스 신청을 받아 두었어요. ▶ 0:03:29

그런데 바로 런칭하지 않았어요. 그 전에 개밥 먹기(dogfooding), 만든 사람이 자기 제품을 먼저 써 보는 단계를 거쳐야 하거든요.

개밥을 만들었으면 내가 먹어보고 런칭을 해야 된다, 맛이 괜찮네라는 결론까지는 도달해야 된다는 거죠. ▶ 0:04:31

QA와는 목적이 달라요. QA가 버그가 없는지를 찾는다면, 개밥 먹기는 지금 사람들한테 배포해도 될 만큼 경험의 품질이 완성됐는지를 봐요. ▶ 0:11:49 그래서 MVP는 일단 개밥 먹을 수 있는 상태까지 만드는 걸 목표로 잡는 게 좋아요. ▶ 0:11:10

첫 시나리오는 Vooster 레포 자체의 유지보수에 Vooster CLI(vspec)를 쓰는 거였어요. Claude가 vspec을 직접 부르는 방향으로 계획을 세우자 바로 방향을 틀었어요. 실제 사용자는 vspec을 직접 치지 않거든요.

원래 vspec은 클로드 코드 같은 코딩 에이전트에 연동해 주고, 쓰는 사람은 프롬프트로만 지시하는 게 컨셉이잖아요. ▶ 0:12:24

그래서 개밥 먹기도 claude -p(Claude Code를 대화창 없이 한 번 실행하는 headless 모드)로 에이전트를 띄우고, 그 에이전트가 vspec을 쓰게 설계했어요.

보충: 이 설계는 레포에 docs/findings/2026-05-25T1516-persona-dogfood-harness.md(페르소나 dogfood 하네스)로 남았어요.