우리는 왜 22년 전 책의 저자를 정원에 들였나 — 에릭 에반스(Eric Evans)를 sage로 영입한 카카시 하네스 v1.8.0

TL;DR

카카시 하네스의 평가 시스템에 두 번째 현자가 들어왔다.

v1.4.0의 데밍이 "모든 작업의 학습 루프(PDSA)"였다면,

v1.8.0의 에릭 에반스는 기획 단계의 언어와 경계 점검이다.

후속 평가가 처음으로 코드 외부 — 즉 PRD·기획서·도메인 모델 — 를 본다.

1. 데밍이 답하지 못한 한 가지

v1.4.0 이후 우리 하네스의 모든 작업은 PDSA로 회고됐다. 무엇을 예측했고, 무엇이 실제로 일어났고, 무엇을 배웠는가.

일관된 학습 루프가 어디에나 부착되는 건 강력하다. 하지만 운영하다 보면 한 가지가 계속 걸렸다.

가장 비싼 실수는 작업이 시작되기 전에 결정된다.

도메인 전문가가 평소 쓰는 "사용자"를 PRD에서 "유저", "회원", "가입자"로 통일시켜 버리는 순간 — 회의마다 단어가 흔들리기 시작한다

모든 도메인을 같은 깊이로 모델링하려는 순간 — 핵심 도메인이 매몰되고 일반 도메인이 코드를 잠식한다

마이크로서비스 분리를 "서비스 1개 = 컨텍스트 1개"로 등치하는 순간 — 복잡도가 코드에서 서비스 사이의 공간으로 이동한다

이런 결정들은 회고(PDSA)로는 늦다. 코드가 한 줄 짜이기 전, 첫 PRD 한 페이지가 쓰이는 그 시점에 누군가 옆에서 묻고 있어야 한다.

"이 단어는 누구의 단어인가? 경계는 어디인가? 무엇이 핵심인가?"

데밍은 작업이 끝난 뒤 학습을 묻는다. 우리에게 필요한 두 번째 현자는 작업이 시작되기 전 언어를 묻는 사람이어야 했다.

2. 왜 22년 전 책의 저자인가

항목	내용
정전	Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003, ISBN 978-0-321-12521-7)
서문	Martin Fowler
부속	DDD Reference (2015, CC-BY 4.0, 무료 PDF)
운영체	Domain Language, Inc. (Evans 본인의 컨설팅 회사)
한국어 번역	도메인 주도 설계, 이대엽 옮김, 위키북스, 2023

22년이 지나도 그의 한 문장은 여전히 칼끝이다.

"The heart of software is its ability to solve domain-related problems for its user."

— Eric Evans, Domain-Driven Design (2003)

그리고 2024년 Explore DDD에서도 그는 살아서 새 명제를 던졌다:

"a trained language model is a bounded context."

— Eric Evans, Explore DDD (Denver, 2024) (InfoQ)

LLM 시대에도 그의 어휘가 여전히 작동한다. 22년 전 개념이 낡지 않은 것이 아니라 원형이라서 새로운 도메인을 흡수한다. 이것이 우리가 그를 sage(현자)로 분류한 이유다 — 도메인 전문가는 도구를 가지지만, 현자는 사상을 가진다.

3. 한국 기획자가 만나게 될 6축의 칼

sage-evans는 PRD·기획서·도메인 모델을 받으면 6개 축으로 평가한다.

각 축은 통과(✅) / 부분(⚠️) / 누락(❌) 셋 중 하나로 표시된다.

축	묻는 것	❌의 의미
유비쿼터스 언어	도메인 용어가 글로서리에 정의되어 있는가	회의마다 단어가 다시 정의된다
언어 일관성	같은 개념이 문서 전체에서 같은 단어인가	동의어 혼용으로 의미가 흐려진다
컨텍스트 명시	시스템 영역이 컨텍스트로 분리되어 있는가	Big Ball of Mud로 직진한다
컨텍스트 관계	컨텍스트 간 관계가 9개 패턴 중 하나로 명시되는가	통합 지점에서 모델이 서로 부패한다
Core 선언	무엇이 경쟁 우위인지 한 문장으로 적혀 있는가	우선순위가 흔들리고 핵심에 자원이 안 모인다
변경 영향 범위	이번 기획이 어느 컨텍스트의 무엇을 바꾸는가	사이드 이펙트가 보이지 않게 누적된다

합격선: 6축 중 최소 5개 ✅, 0개 ❌, 그리고 Core 선언 ❌는 어떤 경우에도 불가.

평가 결과는 데밍 PDSA 블록 뒤에 부착된다 — 즉, 한 번의 기획 작업이 끝나면 자동으로 두 현자가 차례로 의견을 남긴다.

4. 데밍과 에반스 — 두 현자의 역할 분담


[기획·도메인 모델링 작업 종료]
   │
   ├─ [기본 평가] PDSA — sage-deming (항상)
   │    · Plan → Do → Study → Act
   │    · 무엇을 예측했고 무엇을 배웠나
   │
   └─ [후속 평가] 전략 설계 — sage-evans (기획·도메인 매칭 시 자동)
        · 유비쿼터스 언어 / 컨텍스트 / Core 6축 점검
        · 누락은 데밍의 'prediction: missing'과 동등한 학습 손상으로 기록

데밍은 회고의 현자, 에반스는 사전 점검의 현자.

두 사람은 충돌하지 않는다 — 같은 작업의 다른 시점을 본다.

하네스 진화 측면에서 v1.8.0이 갖는 의미

이전 후속 평가들(security, performance, test-sentinel, build-doctor 등)은 모두 "코드 변경 → 그 코드를 본다" 였다.

sage-evans는 처음으로 "PRD 변경 → 그 언어를 본다" 다. 후속 평가가 코드 외부 산출물까지 확장된 첫 사례.

5. 베스트 프롬프트 — 어떻게 부르나

/harness-kakashi-creator를 한 번 부른 뒤에는 슬래시 없이도 동작한다. 실전 시나리오 5종.

5-1. 새 프로덕트의 첫 기획서를 통째로 검토받을 때


에반스 호출. 첨부한 PRD는 신규 사업 도메인 'O2O 반려동물 케어'의 첫 기획서다.
유비쿼터스 언어 글로서리·컨텍스트 분리·Core 선언이 충분한지 6축으로 점검하고,
누락된 항목은 Evans 본인의 어록을 인용하며 다음 한 걸음을 제안해줘.

산출물 경로: docs/prd/pet-care-v0.md
도메인 전문가: 수의사 2명, 펫시터 1명, 기존 사용자 패널 5명
일정 제약: 다음 분기 시작 전 v1 확정 필요

기대: 6축 평가표 + 누락 항목별 인용 + 30분 EventStorming 등 구체 권고

5-2. 도메인 용어가 회의마다 흔들릴 때


도메인 주도 점검. 우리 팀이 "주문/구매/거래/결제"를 혼용 중이다.
이 4단어가 같은 컨텍스트의 동의어인지, 컨텍스트가 분리되어야 할 신호인지 판단해줘.
참고로 결제는 외부 PG가 처리하고, 환불 정책은 우리 도메인에 있다.

기대: "비슷한 단어 여러 개 = 컨텍스트 경계 신호"라는 Evans의 휴리스틱 적용, 4개 컨텍스트로 분리 또는 단일화 권고

5-3. 마이크로서비스 분리 직전 컨텍스트 점검


전략 설계 점검. 현재 모놀리식을 5개 마이크로서비스로 쪼개려 한다.
서비스 경계와 컨텍스트 경계가 일치하는지, "1 서비스 = 1 컨텍스트" 함정에 빠지지
않았는지 봐줘. 첨부는 ADR-007 (마이크로서비스 분리 결정안).

기대: Evans 본인이 2018~2019년에 명시적으로 부정한 "ms = bc" 도식 적용 검증, "복잡도가 코드에서 서비스 사이로 이동"하지 않는지 점검

5-4. 글로서리만 따로 점검받고 싶을 때


유비쿼터스 언어 점검. docs/glossary.md 한 파일만 6축 중 '유비쿼터스 언어'
'언어 일관성' 두 축으로 평가해줘. 도메인 전문가 인터뷰 노트(notes/interviews/)
도 함께 참고해서, 실제 현업 단어와 글로서리가 일치하는지 확인.

기대: "인접 용어 비교 누락" 같은 글로서리 구조 결함 식별, 현업 단어 vs 글로서리 단어 mismatch 표

5-5. 다음 분기 Core 도메인 재선언


기획 단계 평가. 이번 분기 OKR을 보고, 우리 프로덕트의 Core Domain이
지난 분기와 같은지 다시 선언해줘. 시장 상황(첨부 메모)과 경쟁사 동향이 바뀌었다면
Core 자체가 이동했을 가능성도 검토.

원칙: "Core는 하나에 가깝다", "Generic은 외부에서 사 와야 한다"

기대: 한 문장 Core 선언 ("이 프로덕트의 경쟁 우위는 {X}다") + Supporting/Generic 재분류 표 + 전 분기 대비 이동 사항

6. 다음 사이클

이번 영입은 끝이 아니라 시작이다. 정원지기(tamer)의 PDSA가 다음 세 가지를 다음 사이클로 넘겼다.

첫 실전 호출 케이스 확보 — 가까운 기획 작업 한 건을 sage-evans에 흘려보내 6축 평가가 실제로 통과되는 사례를 harness/logs/sage-evans/에 남긴다

EventStorming 보조 도구화 — 사용자가 글로서리/컨텍스트 맵을 못 그릴 때 sage-evans가 Brandolini의 EventStorming 진행을 안내하는 워크플로우 추가 검토

세 번째 현자 후보 검토 — 마틴 파울러(진화적 설계) 또는 E.F. Codd(관계형 정규화). DDD 도입으로 데이터 모델링 영역의 사상이 비어 있음이 드러났다

부록 A — 한국어 용어 매핑 (Wikibooks 번역본 기준)

임의 신조어 금지. 위키북스 한국어판 (이대엽 옮김, 2023)을 1차 기준으로 채택.

영문	한국어 (본 하네스에서 사용)
Ubiquitous Language	유비쿼터스 언어
Bounded Context	경계된 컨텍스트
Context Map	컨텍스트 맵 / 컨텍스트 지도
Core Domain	핵심 도메인
Supporting Subdomain	지원 하위 도메인
Generic Subdomain	일반 하위 도메인
Anticorruption Layer (ACL)	부패 방지 계층
Published Language	공표된 언어
EventStorming	이벤트 스토밍

부록 B — 1차 출처

Blue Book (publisher): InformIT — Domain-Driven Design

DDD Reference (2015, CC-BY 4.0): domainlanguage.com PDF

DDD Community — What is DDD?: dddcommunity.org

Martin Fowler — Bounded Context: martinfowler.com

Martin Fowler — Ubiquitous Language: martinfowler.com

InfoQ — DDD Matters Today (Evans, 2015): infoq.com

InfoQ — DDD and Microservices (Evans, 2016): infoq.com

InfoQ — DDD is Not Done (Evans, 2018): infoq.com

InfoQ — Evans on DDD + LLMs (2024): infoq.com

EventStorming (Alberto Brandolini): eventstorming.com

Korean translation (Wikibooks, 2023): wikibook.co.kr

부록 C — 본 하네스 내부 정전 위치

harness/agents/sage-evans.md — 에이전트 정의 (19개 트리거, 6축, 8개 안티패턴)

harness/knowledge/methodology/ddd-evans.en.md — 영문 1차 정전

harness/knowledge/methodology/ddd-planning-playbook.ko.md — 한국 기획자 운용 플레이북

harness/knowledge/methodology/evaluation-base-pdsa.md — 후속 평가 매핑

harness/engine/toad-summoning.md — 현자 카탈로그 (sage_count: 2)

harness/knowledge/lore/naruto-worldview.md — 세계관 등록

harness/docs/v1.8.0.md — 영입 기록

"Effective domain modelers are knowledge crunchers."

— Eric Evans, Blue Book

기획자의 일은 요구사항 정리가 아니라 지식의 압축이다.

도메인 전문가의 머릿속에 흩어진 단어·사건·규칙을 이름 붙은 모델로 압축할 때, 그 모델이 코드보다 오래 산다.

에반스가 평가하는 것은 그 압축의 정밀도다.