뉴스레터 목록
라이브노트프리미엄 전용유튜브 라이브

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

라이브

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

첫 섹션은 누구나 읽을 수 있어요. 나머지 섹션의 전문·프롬프트 원문·Q&A는 라이브 프리미엄 멤버십 회원 전용이에요.

책으로 읽은 도메인 스토리텔링을 실제 프로젝트(PT 보조 앱 모핏)에 적용해, 클로드 코드에게 3시간 동안 인터뷰를 받으며 불편함을 정리하고 그걸로 UX를 정한 라이브예요.

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

  1. 워크숍을 열기 전에 AI와 완료 기준·진행 규칙부터 합의하기
  2. AI가 결정을 떠넘길 때, 내가 해결책 얘기로 샐 때 선 긋기
  3. 정리된 불편함에서 "이 순간 누가 무슨 판단을 하고, 그때 어떤 정보가 필요한가"를 물어 화면 요구사항 뽑기

다시보기: https://youtu.be/dMU2QOptF28 (3시간 6분. 워크숍 약 2시간 40분, 끝부분에 Q&A가 몰려 있어요)

목차

기획서보다 완료 기준을 먼저 정했어요 ▶ 0:01:01

재료는 계속 유지보수해 온 모핏(MoFit)이에요. PT 수강생과 트레이너 사이를 돕는 앱이고, 저는 실제 수강생으로서 이 앱의 첫 사용자예요. 지난 회차까지 도메인 스토리텔링 워크숍을 일부 해 뒀으니 그 상태부터 물었어요.

이 프로젝트에 대한 도메인스토리텔링워크숍을 진행했었거든. 관련해서 남은 문서는 무엇인지, 이 내용이 얼마나 구체화됐는지 현황 파악해줘.

워크숍 결과는 docs/DOMAIN.md 한 파일(269줄)에만 남아 있고, 기획서와 코드에는 하나도 반영되지 않았다는 답이 왔어요. AI는 바로 기획을 "재정렬"하자고 했지만, 저는 워크숍을 먼저 끝까지 하자고 했어요. 그리고 끝났는지 판단할 기준부터 정하자고 했어요.

재정렬보다도, 충분히 구체화될때까지 일단 도메인스토리텔링워크숍을 진행하는게 좋아보인다.
일단 도메인스토리텔링워크숍의 완료기준부터 정해볼까?

AI가 낸 기준 7개는 "스토리가 충분히 자세한가"만 따지고 있었어요. 그래서 이 문서를 어디에 쓸 건지를 먼저 알려 줬어요.

내 목적은 도메인스토리를 기반으로 다음과 같은 것들을 하는거야.
1. 현실세계에서 있는, 내가 해결하려는 불편함이 명확히 설명된다.
2. 그 불편함중 이 SW가 해결할 것, 해결하지 않을 것을 명확히 구분한다.
3. 해결할 불편함으로부터 확실한 유저스토리/요구사항(기능목록)을 도출한다.
4. 기능을 완성한 이후, UIUX의 판단기준으로서 도메인스토리를 활용한다.
클로드 코드 화면 — 위에 목적 4가지 프롬프트, 아래에 "지금 넣은 7개 기준은 '스토리가 충분히 자세한가'만 따지고 있어요"라는 지적과 목적별 완료 기준 수정안(목적 1 불편함이 명확하다, 목적 2 해결할 것과 안 할 것이 구분된다)
목적을 주자 완료 기준이 목적별로 다시 짜였어요 ▶ 0:11:27

목적을 이렇게 잡은 이유가 있어요. 바이브 코딩할 때 흔히 하는 실수가 기획을 주는 거예요. 기획부터 주면 내가 무슨 의도로, 현실의 어떤 불편함을 풀려고 이 기획을 했는지가 안 담겨요. ▶ 0:10:33

그 바깥 맥락을 적은 문서가 도메인 스토리고, AI와 인터뷰하며 완성하는 과정이 도메인 스토리텔링 워크숍이에요. 저는 이걸로 기획도 하고, UI/UX도 점검하고, 뺄 기능과 더할 기능도 판단하려고 해요. ▶ 0:11:15

기준이 정해지자 진행 방식도 물었어요.

그래 그러면 우리가 워크숍 프로세스는 어떻게 해야할까?
클로드 코드 화면 — 완료 기준을 네 가지 목적별로 바꿔 넣었다는 보고 아래 "워크숍 진행 방식": 역할(사용자님은 이야기를 들려주는 사람, 저는 질문하는 진행자이자 받아 적는 기록자), 기록 형식(행위자가 작업 객체를 (활동)한다 형태의 번호 붙은 문장)
역할과 기록 형식부터 합의 ▶ 0:13:36

합의한 규칙은 DOMAIN.md에 그대로 남겼어요. 방송 끝 시점 원문이에요.

수강생이 이야기하고, 에이전트가 묻고 받아 적는다. 표기는 그림 대신 `행위자가 작업 객체를 [활동]한다`의 번호 문장이다.
장면 하나가 끝나면 이 파일을 고쳐 diff를 확인받고, 관측 시점을 붙여 커밋한다.

- 에이전트는 추측으로 빈칸을 채우지 않는다. 모르는 것은 가설과 판정 방법으로 적는다.
- AS-IS에는 일어난 일만, 바람은 TO-BE에만 적는다.
- 단계를 닫을지는 에이전트가 완료 기준에 대조해 **판단하고 닫는다.** 수강생에게 묻지 않고 근거와 함께 알린다.
- `해결` / `안 함`처럼 수강생이 정할 것은 에이전트가 근거와 함께 추천하고, 수강생은 동의하거나 고친다.
- 질문은 한 번에 하나만, 짧게. 카톡·스프레드시트·`life-os` 실물은 에이전트가 직접 읽어 대조한다.

"단계를 닫을지는 에이전트가 판단하고 닫는다"는 줄은 처음엔 없었어요. 워크숍 중에 AI가 계속 저에게 물어서 나중에 들어간 규칙이에요(다음 두 섹션 참고). 여기까지 컨텍스트를 9% 썼어요. ▶ 0:13:49

이 뒤는 라이브 프리미엄 멤버십 회원 전용이에요

나머지 섹션의 전문과 프롬프트 원문, Q&A는 라이브 프리미엄 멤버십 회원만 읽을 수 있어요.

프리미엄 혜택 보기 →

지난 라이브노트