실전 바이브코딩 - 도메인 스토리텔링 적용하기

한 줄 핵심

도메인 스토리텔링 워크숍으로 현실의 불편함과 맥락을 먼저 끝까지 캐낸 뒤, 그 결과를 바탕으로 유저 스토리·UI·구현을 이어 가는 방식이 바이브 코딩의 품질을 가장 크게 올린다.

시간별 요약

1. 0:00
   도메인 스토리텔링을 실제 코드에 적용 기존에 공부했던 도메인 스토리텔링 기법을 실제 코드베이스에 적용하기 위해 Claude Code를 사용해 워크숍을 진행한다. 목표는 기능을 바로 만드는 것이 아니라, 먼저 현실 문제와 제품의 맥락을 충분히 구체화하는 것이다.
2. 1:02
   도메인 워크숍 준비와 작업 방식 이전에 진행한 도메인 스토리텔링 워크숍의 결과를 바탕으로 현재 구체화 수준을 점검한다. 작업 도구와 프롬프트는 멤버십 자료로 관리되며, 로그인 후 바로 인터뷰형 작업을 시작한다.
3. 2:01
   워크숍 결과의 구체화 수준 확인 프로젝트의 도메인 스토리텔링이 얼마나 구체화됐는지 먼저 파악하도록 지시한다. 이후 출력이 기대와 조금 달라 프롬프트를 조정하고, 모델의 응답 속도와 반응을 보면서 작업 방식을 다듬는다.
4. 4:00
   불편함의 초안을 충분히 넓게 수집 도메인 스토리텔링의 핵심은 무엇을 해결할지와 함께 무엇을 해결하지 않을지도 구분하는 데 있다. 처음에는 대략적인 부채화 수준에서 시작하지만, 불편함이 충분히 구체화될 때까지 워크숍을 계속 진행한다.
5. 8:00
   도메인 스토리로 유저 스토리의 뼈대 만들기 도메인 전문가와의 인터뷰를 통해 현실의 불편함을 명확히 하고, 그로부터 유저 스토리를 뽑아내는 것이 목적이다. 이 과정은 기획서 작성이 아니라, 제품이 해결할 문제의 범위를 정확히 정의하는 작업이다.
6. 10:00
   기획보다 먼저 필요한 바깥 맥락 바이브 코딩에서 흔한 실수는 기획만 바로 던지는 것이다. 하지만 기능의 의도, 현실 세계의 문제, 해결 범위가 함께 담긴 도메인 스토리가 있어야 AI가 정확한 판단을 할 수 있다.
7. 15:01
   인터뷰형 워크숍으로 세부 불편함을 끌어내기 에이전트가 한 번에 하나씩 질문하도록 만들어 답하기 쉽게 한다. 운동, PT, 루틴, 기록 방식, 피드백 방식 등 구체적인 상황을 묻고 답하면서 실제 불편함을 촘촘히 수집한다.
8. 31:04
   불편함은 해결 가능한 문제와 그렇지 않은 문제로 나뉨 트레이너의 피드백이 모호하고, 운동 중 자극이 잘 들어갔는지 판단하기 어렵고, 기록도 번거롭다는 문제가 드러난다. 모든 것을 해결하지 않아도 되지만, MVP로 무엇을 다룰지는 먼저 모두 파악해야 한다.
9. 43:04
   연장 판단과 일상 루틴의 평가 기준 운동 효과나 PT 연장 여부는 단일 지표보다 여러 일상 기준으로 판단하는 편이 현실적이다. 단백질 섭취, 운동 빈도, 수면, 주간 노력량 같은 반복적인 행동이 실제 목표 달성에 더 큰 영향을 준다.
10. 50:10
    트레이너를 보조하는 하네스 설계로 확장 새 시스템은 트레이너에게 목표를 상기시키고, 불편사항을 반복하지 않게 강제하는 보조 역할을 할 수 있다. 즉, 문제를 직접 해결하는 도구라기보다 사람의 작업 품질을 높이는 하네스에 가깝다.
11. 1:01:02
    워크숍 중 핵심 경계선은 AI가 아니라 사람이 잡기 AI가 자꾸 해결책으로 넘어가려 할 때는, 역할 경계를 다시 선명하게 그어야 한다. 불편함을 수집하는 단계와 솔루션을 설계하는 단계를 분리해야 도메인 스토리텔링의 효과가 유지된다.
12. 1:09:04
    도메인 스토리텔링은 설계 전 단계의 핵심 작업 도메인 스토리텔링은 PRD나 구현 설계가 아니라, 제품이 다룰 현실 문제를 문서화하는 과정이다. 이 단계가 잘 되면 유저 스토리, UX, UI, 구현 순서로 자연스럽게 이어지고, AI에게도 정확한 개발 맥락을 전달할 수 있다.
13. 2:48:03
    문서보다 중요한 것은 코드 구조와 검증 장치 AI가 문서를 과하게 만들게 두는 것은 오히려 위험할 수 있다. 코드로부터 알 수 없는 정보만 문서로 남기고, 나머지는 레이어링이 잘된 코드 구조와 린트·테스트 같은 검증 게이트로 관리하는 편이 더 실용적이다.
14. 3:04:02
    워크숍의 결론과 다음 단계 이번 세션은 도메인 스토리텔링 워크숍을 통해 불편함을 충분히 수집하고, 그 맥락으로 UI/UX 방향까지 정리한 성공적인 사례였다. AI에게 판단을 계속 위임하되 진행자는 계속 경계를 잡아 주는 방식이 가장 이상적이라는 결론으로 마무리된다.

실무 인사이트

• 바이브 코딩에서는 기능 요구사항보다 현실의 불편함과 그 불편함이 발생하는 맥락을 먼저 인터뷰로 캐내야 AI가 덜 엇나간다.
• AI가 솔루션으로 너무 빨리 뛰어들면, 계속해서 역할 경계를 다시 지정하고 '지금은 불편함 수집 단계'라고 선을 그어야 한다.
• 문서를 많이 남기는 것보다 코드 구조를 깔끔하게 하고, 꼭 필요한 정보만 문서화하는 편이 유지보수와 에이전트 활용 모두에 유리하다.