모핏에 도메인 스토리텔링을 적용해 AI 인터뷰로 PT 서비스 기획과 UX 기준을 구체화했다.

01핵심 개요

• 모핏 코드베이스에서 클로드 코드를 활용해 도메인 스토리텔링 워크숍의 구체화 수준과 완료 기준부터 점검했다.
• AI가 한 번에 하나씩 질문하도록 설정해 PT 수업, 개인 운동, 식단 기록에서 느낀 불편함을 약 124개 질문으로 수집했다.
• 운동 루틴·휴식 시간·자세 코칭·측정 기록·식단 리마인드 등 해결 후보 불편함이 18개로 정리됐다고 설명했다.
• 도메인 문서는 문제와 현실 맥락을 다루고, 이를 바탕으로 유저 스토리·UX·UI·구현으로 넘어가야 한다고 구분했다.
• AI에는 맥락과 인사이트를 제공하되, 워크숍 진행과 의사결정 흐름은 AI가 주도하도록 역할 경계를 반복해 설정했다.

02핵심 주장 / 논점 구조

• 바이브코딩에서 바로 기획을 주면 현실의 불편함과 기획 의도가 빠질 수 있으므로, 먼저 도메인 맥락을 AI에 전달해야 한다고 말했다.
• 도메인 스토리텔링은 현실에서 겪는 불편함, 소프트웨어가 해결할 범위와 해결하지 않을 범위를 명확히 하는 과정으로 설명됐다.
• 도메인 스토리를 바탕으로 유저 스토리를 만들고, 이를 UX 판단과 UI 설계 및 구현의 기준으로 활용하는 흐름을 제시했다.
• 사용자는 문제 상황과 인사이트를 제공하고, AI 에이전트는 인터뷰 진행과 다음 단계 판단을 맡는 구조가 이상적이라고 정리했다.

03모핏과 클로드 코드로 워크숍 시작

• 기존에 계속 유지보수해 온 모핏 코드베이스에 도메인 스토리텔링 기법을 실제 적용하겠다고 밝혔다.
• 클로드 코드에 로그인한 뒤, 기존 도메인 스토리텔링 워크숍 결과가 얼마나 구체화됐는지 확인하도록 요청했다.
• 워크숍 결과만으로는 충분히 구체화되지 않았다고 보고, 도메인 스토리텔링 워크숍의 완료 기준과 진행 프로세스부터 정했다.
• 코딩 작업 전 인터뷰에 컨텍스트를 사용했으며, 약 50분 인터뷰 시점에는 컨텍스트 사용량이 15%라고 언급했다.

04PT 수업 불편함을 파고든 AI 인터뷰

• 트레이너가 낮은 무게로 고반복을 시키는 방식 때문에 자세가 무너진 채 힘들기만 한 운동이 된다는 아쉬움을 말했다.
• 벤치프레스·데드리프트·스쿼트 같은 대근육 운동에서는 약 15회 수준보다 정확한 자세와 목표 근육 자극을 더 원한다고 설명했다.
• 트레이너의 피드백이 '힘을 주세요'처럼 모호해 전문적이지 않다고 느꼈고, 피아노 선생님의 구체적 피드백과 대비했다.
• PT는 주 1~2회 진행하며 당시 남은 수업은 8회, 모두 소진하는 데는 약 10주가 걸릴 것으로 답했다.
• 질문이 루틴, 일정 변경, 지각한 수업, 다음 수업 이월 여부 등 세부 운영 상황까지 수렴하는 과정을 보여줬다.

05운동·식단·측정 기록의 판단 기준

• 운동 후 근육 자극이 충분했는지는 즉시 판단하기 어렵고, 방법이 문제인지 노력의 문제인지 알고 싶다고 말했다.
• 개인 운동 때 세트 사이 휴식 시간에 무게와 횟수를 채팅으로 기록하는 일은 크게 번거롭지 않다고 답했다.
• 음식 기록은 동행과 대화 중 놓치기 쉽고, 먹은 음식의 단백질량을 정확히 알기 어려워 리마인드가 필요하다고 말했다.
• 단백질 섭취량 160% 이상, 운동 5가지 이상, 수면 7시간 이상 같은 일일 실천 여부를 확인하는 기준을 언급했다.
• 눈바디와 둘레 측정은 자세·힘을 주는 상태·줄자 사용 기준이 모호하면 이전 기록과 비교하기 어렵다고 지적했다.

06불편함 수집 후 UX 요구사항 구체화

• 불편함 수집 단계에서는 '어떻게 소프트웨어를 만들지'를 논의하지 말고, 무엇이 불편하고 어떻게 되면 좋은지만 말해야 한다고 강조했다.
• AI가 불편함 수집을 마친 뒤 해결 방안을 제안했고, 해결할 불편함이 18개라고 정리된 과정을 보여줬다.
• 트레이너가 수업을 마칠 때 다음 수업 일정과 운동 부위를 입력하고, 측정 시점도 함께 확인하는 흐름을 논의했다.
• 수업 중 운동별 세트 완료를 클릭하면 타이머, 휴식 시간, 무게와 횟수 기록이 이어지는 화면 구상을 제안했다.
• 개인 운동에서 남긴 이상 징후와 해당 부위 기록을 트레이너가 수업 루틴 작성 및 수업 중에 참고하는 방안을 다뤘다.

07AI 진행자에게 역할 경계 설정하기

• AI가 워크숍 단계를 닫을지 사용자에게 판단을 넘기려 할 때, 진행자인 AI가 결정해야 한다고 반복해서 선을 그었다.
• AI가 해결책 논의로 너무 빨리 넘어가면 현재는 해결책이 아니라 불편함 수집 단계라고 되돌리며 범위를 통제했다.
• 질문 68번째와 100번째를 지나 최종적으로 질문 124개, 약 2시간 30분의 인터뷰 끝에 워크숍이 종료됐다고 말했다.
• 인터뷰 답변 하나하나가 이후 판단 기준이 되므로, 귀찮더라도 충분한 시간을 써서 구체적으로 답하는 편이 효율적이라고 평가했다.
• 오프라인 강의에서는 종료 조건을 넣은 워크숍이 약 15분 만에 끝난 사례도 언급하며 종료 기준 설정을 권했다.
• 문서·품질 게이트·에이전트 운영 원칙: 커밋 시 빠르게 실행하는 pre-commit 품질 게이트로 check docs, lint, test fast 등을 사용한다고 소개했다.
• 문서·품질 게이트·에이전트 운영 원칙: 승인 없이 문서를 생성하면 거부되는 check docs 규칙을 두고, 린트 규칙 등 프로그램적 검증 장치를 마련한다고 말했다.
• 문서·품질 게이트·에이전트 운영 원칙: 코드에서 알 수 없는 정보만 문서로 남기며, 화면 기능이나 아키텍처처럼 코드에서 파악 가능한 정보를 중복 문서화하지 않는다고 밝혔다.
• 문서·품질 게이트·에이전트 운영 원칙: 작업을 다음 세션으로 넘길 때는 완료된 일을 무겁게 문서화하기보다, 아직 하지 않은 일을 투두로 남기고 커밋 기록을 활용한다고 설명했다.
• 문서·품질 게이트·에이전트 운영 원칙: AI 에이전트를 이틀 동안 자율적으로 돌리기보다 티켓 단위로 중간 보고와 판단을 받는 방식을 선호한다고 말했다.

08용어 사전