현업 개발자와 같이 읽는 『도메인 스토리텔링』 5~16장 (완독)

한 줄 핵심

『도메인 스토리텔링』은 도메인 이해를 공통 기반으로 정리한 뒤 요구 사항·테스트·코드로 단계적으로 압축하는 방법을 설명하며, AI 코딩 시대에는 사람보다 코딩 에이전트가 이 과정을 더 잘 수행하게 설계하는 것이 핵심이라는 주장이다.

시간별 요약

1. 0:12
   진행 방식과 1부·2부의 구분 1부는 도메인 스토리텔링 워크숍을 준비하는 이론과 팁을 다루고, 2부는 그 결과물을 현실 문제 해결에 어떻게 적용할지를 설명한다. 실제 바이브 코딩에서는 5~7장은 상대적으로 덜 중요하고, 8장부터가 실무 적용의 핵심이다.
2. 8:00
   사례로 보는 현실 적용 흐름 알폰 자동차 리스 주식 회사 사례는 넓은 범위의 프로세스를 먼저 파악한 뒤, 복잡한 신용 위험 평가를 더 깊게 쪼개고, 시스템 용어를 걷어낸 순수한 스토리로 되돌려 본다. 그 다음 개선 가능한 기존 프로세스와 신규 서비스 스토리까지 단계적으로 도출해 실제 적용 흐름을 보여 준다.
3. 17:06
   도메인 언어를 배우는 법 도메인 전문가의 언어를 배우는 일은 업무와 요구 사항을 정확히 이해하기 위한 핵심 역량이며, 문서만 읽기보다 대화와 인터뷰로 먼저 이해도를 높이는 편이 효과적이다. 도로 공사 기관 사례처럼 현업의 반발이 있더라도 문서가 설명하지 못하는 부분을 워크숍으로 메워야 한다.
4. 26:01
   순수한 스토리와 관찰의 한계 시스템이 섞인 디지털화된 스토리보다 사람과 업무의 관계만 드러나는 순수한 스토리가 도메인 학습에 더 적합하다. 관찰은 행동만 보여 줄 뿐 의도와 맥락을 드러내지 못하므로, 실제 업무를 이해하려면 반드시 대화가 필요하다.
5. 34:02
   번역가를 두지 말고 직접 소통하게 하라 도메인 전문가와 개발자 사이에 중간 번역가가 끼면 뉘앙스와 기술적 맥락이 손실되기 쉽다. PM이나 PO의 역할은 내용을 대신 번역하는 것이 아니라 양쪽이 직접 소통하도록 자리를 만들고 대화를 진행 가능하게 돕는 것이다.
6. 50:01
   도메인에서 요구 사항으로 넘어가는 단계 도메인 지식과 코드 사이에는 요구 사항이라는 중간 단계가 필요하며, 도메인 스토리는 공통 기반, 요구 사항은 구현 가능한 기능 명세, 코드는 최종 산출물로 역할이 분리된다. 요구 사항은 한 번에 고정하는 문서가 아니라, 도메인 담당자와 지속적으로 논의하며 다듬어 가는 결과물이다.
7. 1:01:02
   유저 스토리와 요구 사항 추출 도메인 스토리에서 유저 스토리를 먼저 뽑고, 이를 바탕으로 요구 사항을 구체화하는 흐름이 적절하다. 다만 도메인 전문가의 말을 그대로 모델링하면 안 되며, 그들이 잘 설명하지 못하는 문제를 해석하고 소프트웨어화하는 책임은 개발 쪽에 있다.
8. 1:15:05
   도메인 모델과 코드 설계 도메인 지식은 소프트웨어에 가까운 방식으로 압축되어 도메인 모델이 되고, 그 모델은 코드와 테스트로 이어진다. 객체의 메소드 이름과 행동은 도메인 스토리의 동사와 맥락을 반영해야 하며, 그렇지 않으면 단순한 getter/setter 중심의 빈약한 설계가 된다.
9. 1:25:02
   테스트와 오버엔지니어링의 경계 잘 정리된 도메인 스토리는 수용 테스트와 시나리오 테스트를 쉽게 도출하게 해 준다. 동시에 아름다운 설계는 비용이 따르므로, 도메인 규모에 비해 과도한 구조를 추가하는 오버엔지니어링은 피해야 한다.

실무 인사이트

• 도메인 스토리텔링 워크숍은 사람이 직접 하기보다 AI 인터뷰 에이전트로 돌리고, 사람은 답변과 검토에 집중하는 방식이 효율적이다.
• 기획·요구 사항 정리는 비개발자가 스스로 완결하기보다, 코딩 에이전트가 요구 사항과 구현안을 함께 정리하게 두고 사람은 검증하는 구조가 더 안전하다.
• 좋은 코드보다 먼저 좋은 도메인 맥락이 필요하므로, 구현 전에는 현재 서비스가 현실의 도메인 문제를 제대로 설명하고 있는지부터 점검해야 한다.