기획자를 위한 하네스 — 정원 위에 현자를 모시다
1편에서 우리는 문서 시스템을 위한 정원을 심었다. 이번 글은 그 정원에 현자(sage) 가 들어오는 이야기다 — 그리고 그 현자는 개발자가 아니라 기획자의 손에 들리는 도구다.
이 글은 블룸AI 하네스 시리즈 의 세 번째 편이자, 1편 "테크 라이팅 문서 시스템에 하네스를 도입하다" 의 스핀오프다. 1편이 문서가 잘 굴러가는 정원을 보였다면, 본 편은 정원이 다음 단계로 자라기 위해 우리가 발견한 한 가지 — 기획 단계의 현자 영입 — 을 다룬다.
대상 독자는 하네스 엔지니어링이 개발자의 전유물이라고 느꼈던 기획자 — PM(Product Manager, 제품 책임자) / PO(Product Owner, 제품 오너) / BA(Business Analyst, 비즈니스 분석가) — 다.
1. 비개발자가 하네스를 짜기 시작했다
1.1 풍경의 변화
2026년 상반기에 한 가지 흐름이 빠르게 눈에 띄었다. 터미널과 거리가 멀던 사람들이 하네스를 짜기 시작했다. 두 가지 트리거가 동시에 작용했다.
첫째, 클로드 코드 스킬(Skill) 의 진화. 스킬 1.0이 프롬프트 모음이었다면, 스킬 2.0은 트리거가 잡힐 때만 깨어나 CLI를 호출하고 사라지는 작은 앱이다 (2편 §2.1 참고). 비개발자도 자기 도메인의 작업 흐름을 한 묶음의 스킬로 풀어낼 수 있게 됐다.
둘째, Hermes Agent 진영의 등장. 2026년 2월 Nous Research 가 공개한 Hermes Agent는 "The agent that grows with you" 를 표어로 내세웠다. 핵심 차별점은 지속 메모리(persistent memory) 다 — 기존 에이전트가 매 호출마다 백지에서 시작했다면, Hermes는 직전 작업에서 배운 것을 다음 작업에 이어 쓴다. 텔레그램·디스코드·슬랙으로 명령을 받고 백그라운드에서 일을 마친다는 점도, 터미널이 익숙하지 않은 사람들에게 진입 장벽을 낮춰 줬다 (Nous Research, Hermes Agent, NVIDIA Blog, Hermes Unlocks Self-Improving AI Agents).
설치 방법조차 "GitHub URL을 클로드 코드에 붙여 넣고 설치해 달라고 하라" 가 공식 가이드다. 터미널을 직접 다루지 않아도 된다는 신호.
2025년이 "AI가 개발자의 도구가 되는 해" 였다면, 2026년은 "기획자가 AI의 환경 설계자가 되는 해" 가 되고 있다.
1.2 그래도 핵심 원칙은 우리(기획자)의 몫
물론 모든 것이 자동으로 풀리지는 않는다.
- CLI(Command-Line Interface, 명령줄 인터페이스) / CI(Continuous Integration, 지속적 통합) 연동, 에이전트 구동 인프라, 하네스 디렉터리 초기화 같은 기계적인 부분은 개발 동료의 도움으로 해결 가능하다.
- 그러나 "이 하네스가 무엇을 점검해야 하는가" 와 "좋은 기획이란 무엇으로 판정되는가" 는 — 전적으로 기획자의 결정 영역이다.
도구가 생겼다고 판단까지 자동으로 생기는 것은 아니다. 1편이 보여 준 세 겹 토양(햇빛·영양분·물길) 위에서, 햇빛(knowledge)을 무엇으로 채울지는 결국 그 도메인을 가장 잘 아는 사람이 결정해야 한다.
기획자의 도메인이 비어 있는 정원은, 아무리 잘 만든 영양분과 물길이 있어도 꽃이 잘못된 방향으로 자란다.
2. 우리가 오래 무시했던 것 — DDD의 출발점은 기획이었다
2.1 도메인 전문가가 IT 개발에 참여한다는 발상
DDD(Domain-Driven Design)는 보통 개발 설계 방법론 으로 분류된다. 그러나 그 출발점을 자세히 보면, 사실은 기획자와 도메인 전문가가 시스템 설계에 적극 참여한다는 컨셉 이다.
"Effective domain modelers are knowledge crunchers." — Eric Evans, Domain-Driven Design (Addison-Wesley, 2003, ISBN 978-0-321-12521-7)
기획자의 일은 요구사항을 정리 하는 것이 아니라 지식을 압축 하는 것이다 — 도메인 전문가(domain expert, 그 영역을 가장 잘 아는 현업) 의 머릿속에 흩어진 단어·사건·규칙을 이름 붙은 모델 로 압축할 때, 그 모델이 코드보다 오래 산다.
유비쿼터스 언어(Ubiquitous Language): 도메인 전문가와 개발자가 같은 단어로 같은 개념을 칭하는 공통 어휘. 경계된 컨텍스트(Bounded Context): 하나의 도메인 모델이 일관되게 통하는 적용 범위의 경계. 이 두 어휘가 이 글의 핵심 개념이다 — 이후 본문에서 자주 등장하므로 여기서 한 번 정의해 두고 진행한다.
이 컨셉이 2003년에 책으로 나왔다. 그러나 우리(이 글을 쓰는 사람도, 한국의 많은 IT 팀도)는 그동안 시스템 이야기만 하는 IT 개발 문화 안에서 일했다. 도메인 전문가의 참여는 "바쁘니까 나중에" 로 미뤄졌고, 기획자는 PRD를 던지고 빠지는 역할로 축소됐다.
2.2 애자일만 알고 DDD는 몰랐다
흥미로운 사실은 — DDD가 애자일에 깊은 영향을 끼쳤다는 점이다. Eric Evans 본인의 설명에 따르면, 모델을 코드와 함께 리팩터하는 것 과 짧은 이터레이션 이 만났을 때 도메인에 대한 깊은 통찰이 가능해진다 (Eric Evans, Domain Language).
하지만 우리는 애자일만 채택했다. 스프린트, 회고, 칸반 — 형식은 따랐지만, 애자일이 전제하던 도메인 전문가-개발자의 깊은 협업 은 빠진 채였다. DDD의 도메인 모델링, 유비쿼터스 언어, 경계된 컨텍스트 같은 언어와 경계의 작업 은 학습 곡선이 가팔라 보였고, 우리에게 그것을 할 시간이 없었다. PRD(Product Requirements Document, 제품 요구사항 명세서) 한 장을 기능 리스트 로 채워 던지는 흐름이 굳어졌다.
애자일은 원래 방향 의 이야기였는데, 한국 팀에서는 종종 속도 의 이야기로 오해됐다. 속도에 저해되는 모든 것은 채택되지 않았고, 언어 작업(DDD가 가장 강조한 작업)이 가장 먼저 빠졌다.
2.3 AI 시대 — 거인의 어깨를 다시 올라타다
상황이 바뀐 두 가지 이유:
- AI가 무거운 학습 곡선을 평탄하게 만들었다 — DDD의 어휘를 다 외우지 않아도, 어휘를 다 아는 현자(sage) 를 옆에 두고 일할 수 있다.
- 시간 압박이 완화되지는 않았지만, 압축 비용이 낮아졌다 — Evans·Deming 같은 거인의 작업을 직접 읽고 적용 하는 대신, 그들의 사상을 하네스의 한 층으로 얹는 것 이 가능해졌다.
다음 절에서 그 얹는 방법 을 본다.
3. 정원 위에 현자(Sage)라는 층을 얹다
3.1 전문가 위에 있는 것 — 핵심 원칙
1편의 정원은 6명의 전문가(에이전트) 가 협업하는 구조였다 — 정원지기 카카시, 편집장, 검수단 3인, 출판 전문가. 이들 각자는 자신의 영역에서 유능 하지만, 무엇을 좋은 산출물로 볼 것인가 의 상위 원칙은 다른 곳에서 와야 한다.
우리는 그 자리를 현자(sage) 라 부르기로 했다.
| 층위 | 누구 | 다루는 것 |
|---|---|---|
| 현자(Sage) | 에반스, 데밍 | 도메인 전체에 통하는 상위 원칙 (DDD·PDSA 같은 doctrine) |
| 전문가(Specialist) | doc-reviewer, manuscript-architect 등 | 좁은 영역의 집행 (명확성·문체·용어·게시) |
| 정원지기(Tamer) | 카카시 | 정원의 균형, 에이전트 배치 |
비유하자면 — 전문가들은 해당 영역의 장인 이고, 현자는 모든 장인이 따르는 헌장 이다.
3.2 닫힌 루프 vs 열린 루프 — 두 현자를 따로 모시는 이유
우리는 첫 두 현자를 서로 다른 시점 에서 작동하도록 배치했다.
- 닫힌 루프 — 에반스 (DDD) 는 지금 이 작업의 내부 를 본다. 유비쿼터스 언어가 잡혀 있나, 경계된 컨텍스트가 명시됐나, 무엇이 핵심 도메인인가. 지금 사이클 안에서 지침을 주는 현자.
- 열린 루프 — 데밍 (PDSA) 은 작업이 끝난 직후 를 본다. 무엇을 예측했고 무엇이 일치/불일치했나, 이론은 어떻게 갱신되나. 다음 루프를 위해 학습을 누적하는 현자.
두 현자는 충돌하지 않는다. 오히려 순차적으로 부착 된다 — 닫힌 루프 안에서 에반스가 지침을 주고, 사이클이 끝나면 데밍이 학습을 빼내 다음 루프에 얹는다.
4. 첫 번째 현자 — 에릭 에반스 (DDD)
4.1 정체
Eric Evans — 컨설턴트, Domain Language, Inc. 창립자, 그리고 2003년 Domain-Driven Design: Tackling Complexity in the Heart of Software 로 "domain-driven design" 이라는 용어 자체를 만든 사람 (Domain Language, Inc.).
이 책은 마틴 파울러의 서문이 붙어 있고, 출판 이후 20년 동안 기획-개발 협업 의 어휘를 다듬어 온 정전이다. 무료로 공개된 DDD Reference (2015, CC-BY 4.0) 도 같은 어휘로 가다듬어졌다.
4.2 DDD의 전체 그림 — 전략 설계와 전술 설계
DDD가 개발 방법론 이라고만 알려진 것은 절반의 진실이다. 실제로 DDD는 두 층 으로 구성된다.
| 층 | 누가 주도 | 다루는 것 | 산출물 |
|---|---|---|---|
| 전략 설계 (Strategic Design) | 기획자 / 도메인 전문가 / PM | 언어, 경계, 핵심 도메인 식별 | 글로서리, 컨텍스트 맵, Core 선언 |
| 전술 설계 (Tactical Design) | 개발자 | 엔터티, 값 객체, 애그리거트, 리포지토리 | 코드, 데이터 모델 |
핵심 통찰: 전략 설계가 비어 있으면 전술 설계가 잘못된 곳에 내려진다. 글로서리 없이 시작된 프로젝트는 같은 단어가 두 가지 의미로 코드에 박힌다. 컨텍스트 맵 없이 시작된 프로젝트는 어디까지가 우리 모델인지 모른 채 다른 팀의 모델과 충돌한다.
기획자의 자리는 위층 이다. 아래층(전술 설계)을 개발자가 어떻게 짤지는 위층의 결정이 내려진 뒤 자연스럽게 따라온다. 이 절은 위층의 네 가지 도구 — 유비쿼터스 언어 / 경계된 컨텍스트 / 핵심 도메인 증류 / 컨텍스트 맵 — 을 차례로 본다.
4.3 첫 번째 도구 — 유비쿼터스 언어 (Ubiquitous Language)
"To communicate effectively, the code must be based on the same language used to write the requirements — the same language that the developers speak with each other and with domain experts." — Eric Evans, DDD (2003)
유비쿼터스 언어 — 문자 그대로 어디에나 통하는 언어. 기획서·회의·이메일·코드·테스트 시나리오 모두에서 같은 단어가 같은 뜻으로 쓰이는 공통 어휘다.
왜 그렇게 중요한가
같은 개념을 PM은 "주문", 운영자는 "오더", 개발자는 "Order" 라 부르면 — 세 사람이 같은 회의에서 같은 단어를 입에 올려도 서로 다른 그림 을 그리고 있다. 한 사람이 "취소된 주문도 매출에 포함되나요" 라 물으면, 운영자는 오더 라이프사이클 의 관점에서, PM은 재무 보고 의 관점에서 답한다. 대화가 됐다고 착각 한 채 다음 단계로 넘어가는 것 — 이것이 모든 기획 사고의 출발점이다.
글로서리는 PRD의 부록이 아니라 머리말
전략 설계의 첫 산출물은 글로서리(glossary) 다. PRD 부록이 아니라 머리말 자리. 형태는 단순하다.
| 용어 | 정의 | 인접 용어와의 차이 |
|---|---|---|
| 주문 (Order) | 고객이 결제 직전 카트에 확정한 상품 묶음 | 카트(Cart) 와 달리 결제 의사가 명시됨 |
| 배송 (Shipment) | 창고에서 출고된 상품의 물리적 이동 단위 | 한 주문이 여러 배송으로 쪼개질 수 있음 |
| 할인 (Discount) | 주문 금액에 적용되는 마이너스 조정 | 쿠폰(Coupon) 은 할인을 발생시키는 원인 |
핵심은 인접 용어와의 차이 칸이다. 단어를 고립 시켜 정의하면 다음 사람이 또 다른 단어를 그 옆에 슬쩍 끼워 넣는다. 인접 용어와의 대조 가 들어가야 글로서리가 살아 있다.
만들기 — 지식 압축(Knowledge Crunching)
에반스는 글로서리를 만드는 과정을 지식 압축(Knowledge Crunching) 이라 부른다. 도메인 전문가 머릿속의 흩어진 단어·사건·규칙 을 이름 붙은 모델 로 짜는 작업이다.
"Effective domain modelers are knowledge crunchers." — Eric Evans, DDD (2003)
실제 절차 (30분~1시간 워크숍 1회 분량):
- 단어 채집 — 도메인 전문가와 함께 도메인에서 자주 쓰이는 단어를 40~60개 적는다 (포스트잇 권장)
- 동의어 정리 — 오더 / 주문 / 발주 처럼 같은 것을 가리키는 변형을 하나로 묶는다. 묶는 것 자체가 합의다
- 인접어 비교 — 비슷하지만 다른 단어들을 옆에 배치한다 (주문 vs 카트, 배송 vs 출고). 차이를 한 줄로 적는다
- 첫 정의 부착 — 핵심 용어 10개에 1~2줄 정의를 붙인다. 완벽할 필요 없다. 다음 회의에서 다듬는다
이 워크숍을 한 번 돌리면 — 생각보다 많은 단어가 같은 그릇에 두 가지를 담고 있다 는 것을 알게 된다. 그 자리가 바로 다음 도구인 경계된 컨텍스트 의 후보다.
4.4 두 번째 도구 — 경계된 컨텍스트 (Bounded Context)
"A Bounded Context defines the range of applicability of each model. Total unification of the domain model for a large system will not be feasible or cost-effective." — Eric Evans, DDD (2003); 마틴 파울러 정리: martinfowler.com/bliki/BoundedContext.html
경계된 컨텍스트 — 하나의 도메인 모델이 일관되게 통하는 적용 범위의 경계. 한 문장으로: "이 안에서는 이 단어가 이 뜻이다" 의 그 이 안.
경계의 신호 — 같은 단어, 다른 뜻
글로서리를 짜다 보면 반드시 마주치는 상황:
주문 이라는 단어가 — 판매 컨텍스트 에서는 "결제까지 끝난 확정 매출 단위" 이고, 물류 컨텍스트 에서는 "출고할 작업 단위" 다.
세 가지 대응이 가능하다:
| 대응 | 결과 |
|---|---|
| ❌ 두 뜻을 강제로 하나로 합친다 | "주문" 단어가 부풀어 올라 모든 회의에서 어느 의미냐 를 다시 묻는다 |
| ❌ 단어를 새로 만든다 (판매주문 vs 물류주문) | 단어가 늘어나 글로서리가 비대해지고, 현업이 안 쓴다 |
| ✅ 두 컨텍스트로 분리한다 | 같은 단어 "주문" 이 어느 컨텍스트에서 쓰였는지로 의미가 결정된다 |
같은 단어가 두 가지 의미로 쓰이는 자리 — 이것이 컨텍스트 경계의 신호다. 에반스의 표현으로: 경계는 발견되는 것이지 발명되는 것이 아니다.
마이크로서비스와의 흔한 오해
"마이크로서비스 N개 = 경계된 컨텍스트 N개"
에반스 본인은 2018·2019년 InfoQ 인터뷰에서 이 도식을 명시적으로 부정 했다 (InfoQ 2018, InfoQ 2019).
- 경계는 언어의 차이 로 정해진다 — 같은 단어가 다른 뜻으로 쓰이는 자리
- 서비스 분할은 운영의 차이 로 정해진다 — 배포 단위, 장애 격리, 팀 소유권
두 결정이 때로 일치 할 수 있지만, 원리적으로 일치할 이유가 없다. 컨텍스트 경계는 기획자가 그릴 수 있는 모델 이고, 서비스 경계는 개발자가 운영을 보고 정하는 모델 이다.
컨텍스트 사이의 9가지 관계 패턴
두 컨텍스트가 서로 어떻게 관계 맺는가 — 에반스는 이를 9가지 표준 패턴으로 정리했다. 기획자에게는 그 사이의 다리 가 어떤 모양인지를 미리 그릴 수 있는 도구다.
| # | 패턴 | 한 줄 설명 | 기획자에게 의미 |
|---|---|---|---|
| 1 | Partnership (파트너십) | 두 팀이 같이 망하고 같이 산다 — 일정·요구를 공동 결정 | 서로의 변경이 즉시 영향. 같은 회의에 동석 |
| 2 | Shared Kernel (공유 커널) | 작은 공통 모델 일부를 두 컨텍스트가 공동 소유 | 변경 시 양쪽 승인 필요 — 사용 최소화 권장 |
| 3 | Customer-Supplier (고객-공급자) | 한쪽이 공급자, 한쪽이 고객 — 공급자가 고객 요구를 우선 | 공급자 팀의 백로그에 고객 팀 요구 가 들어감 |
| 4 | Conformist (순응자) | 한쪽이 다른 쪽 모델을 그대로 따라간다 — 협상 없음 | 외부 시스템(정부 API, 결제사) 등에 맞출 때 |
| 5 | Anti-Corruption Layer (부패 방지 계층, ACL) | 외부 모델이 우리 모델을 오염시키지 않게 가운데 번역 계층 을 둔다 | 레거시·외부 API 와 연동 시 반드시 한 겹 둠 |
| 6 | Open Host Service (개방형 호스트 서비스) | 자신의 모델을 명시적 공개 인터페이스 로 외부에 제공 | API를 제품 으로 다루는 자세 |
| 7 | Published Language (게시된 언어) | 둘 이상의 컨텍스트가 합의된 공용 언어(예: 표준 스키마)로 대화 | 산업 표준·EDI·이벤트 스키마 |
| 8 | Separate Ways (각자의 길) | 통합이 비용 대비 가치 없음 이라 판단해 연결을 끊는다 | 적극적 연결 거부 도 정당한 결정 |
| 9 | Big Ball of Mud (빅볼) | 경계가 암묵적 인 비공식 상태 — 회피 대상 | 새 컨텍스트가 빅볼에 섞이지 않게 명시 |
기획자가 컨텍스트 맵을 그릴 때 — 바로 이 9개 패턴 중 어느 것 으로 다리를 그릴지를 결정한다. 가장 자주 쓰이는 두 가지는 Customer-Supplier 와 Anti-Corruption Layer 다.
4.5 세 번째 도구 — 핵심 도메인 증류 (Core Domain Distillation)
모든 도메인이 동등하지 않다는 것이 DDD의 세 번째 발견이다.
| 분류 | 정의 | 예시 (이커머스 가정) |
|---|---|---|
| Core Domain (핵심 도메인) | 우리 조직의 경쟁 우위 가 발생하는 영역 — 이게 흔들리면 사업이 흔들린다 | 추천 알고리즘, 가격 정책 엔진 |
| Supporting Domain (지원 도메인) | Core가 작동하기 위해 필요하지만, 그 자체로는 차별화 없음 | 주문 관리, 회원 관리 |
| Generic Domain (일반 도메인) | 어느 회사나 같은 모양 — 남이 만든 것을 사 쓰는 영역 | 결제, 이메일 발송, 로그인 |
"전부가 Core" = "Core가 없다"
기획자가 가장 흔히 빠지는 함정: 우리 제품의 모든 부분 이 다 중요해 보인다. 그래서 모든 영역을 Core로 분류한다.
이것은 분류하지 않은 것과 같다. Core의 의미는 "여기에 자원을 몰빵한다" — 따라서 Core가 아닌 곳에서는 자원을 빼야 한다. 모든 것이 Core이면 자원 분배의 결정이 없는 것이고, 결국 모든 영역이 평균 이하 가 된다.
Core 선언은 한 문장으로
좋은 Core 선언의 형식:
"우리 제품의 경쟁 우위는 {한 영역} 의 {한 능력} 이다."
예시:
- "우리 제품의 경쟁 우위는 추천 알고리즘의 개인화 정확도 다."
- "우리 제품의 경쟁 우위는 가격 정책 엔진의 실시간 동적 가격 이다."
이 한 문장이 적혀 있으면 — 분기 로드맵의 70%가 Core의 위 문장 을 강화하는 작업으로 정렬된다. Generic 영역(결제·이메일 등)은 남이 만든 것을 사 쓰는 결정이 자연스럽게 따라온다. 인하우스로 만들 이유가 없는 것에 엔지니어를 박지 않는다.
4.6 네 번째 도구 — 컨텍스트 맵 (Context Map)
앞의 세 도구 — 유비쿼터스 언어 / 경계된 컨텍스트 / 핵심 도메인 증류 — 를 한 장의 그림 으로 모은 것이 컨텍스트 맵 이다.
기획자가 직접 그리는 모델 — 화이트보드, 노트북, 파워포인트, 종이 어디에 그려도 된다. UML(Unified Modeling Language, 통합 모델링 언어)도 아니고 ERD(Entity-Relationship Diagram, 개체-관계 다이어그램)도 아니다. 발견된 컨텍스트들 + 그 사이의 관계 를 한 장에 표시하면 그것이 컨텍스트 맵이다.
좋은 컨텍스트 맵에 들어가는 요소:
- 컨텍스트 N개 — 각자 이름 부여
- 분류 표시 — Core (★), Supporting (■), Generic (□) 등 시각 구분
- 관계 패턴 — 9개 패턴 중 어느 것인지 다리에 라벨 (예: ACL, Customer-Supplier)
- 외부 시스템 — 우리가 통제하지 못하는 영역은 점선으로 구분
- 변경 영향 표시 (선택) — 이번 분기 기획이 어느 컨텍스트를 건드리는지
이 한 장이 PRD 첫 페이지에 들어가면 — 우리가 어디서 싸우는지(Core), 어디서 협력 정책을 정해야 하는지(다리 패턴), 어디서 살을 빼야 하는지(Generic) 가 회의 첫 30초에 합의된다.
4.7 sage-evans 에이전트 — 위 네 도구를 자동으로 점검하는 헌장
하네스 카카시 배포 의 harness/agents/sage-evans.md 는 위 네 도구를 자동 점검 가능한 규칙 으로 운용한다.
호출 조건 — 무엇이 발동시키나
| 상황 | 자동 호출 |
|---|---|
| PRD·기획서·요구사항 문서 작성·수정 | ✅ |
| 도메인 모델 초안(글로서리·이벤트·엔터티 명명) 작성 | ✅ |
| 시스템 컨텍스트 다이어그램 / 마이크로서비스 경계 논의 | ✅ |
| 새 도메인 진입(신규 프로덕트·신규 사업 도메인) | ✅ |
| 코드만 변경(도메인 어휘·경계 무변경) | ❌ |
| 인프라/CI/빌드 변경 | ❌ |
기획자가 명시적으로 부르고 싶을 때 의 트리거:
| 트리거 문구 | 용도 |
|---|---|
| "에반스 소환" / "에반스 호출" | 전체 6축 평가 발동 |
| "DDD 평가" / "DDD 점검" | 동일 |
| "전략 설계 점검" / "기획 단계 평가" / "기획 검토" | 동일 |
| "유비쿼터스 언어 점검" | 글로서리 1축만 좁게 |
| "경계된 컨텍스트 점검" / "컨텍스트 맵 점검" | 컨텍스트·관계 2축 |
자연어 트리거이므로 — 위 문구를 어딘가에 명시 만 해 두면 발동된다. 슬랙 댓글, 깃 커밋 메시지, 회의 노트 끝줄 어느 자리든.
평가 6축
| 축 | 확인 질문 | 통과 기준 |
|---|---|---|
| 유비쿼터스 언어 | 도메인 용어가 글로서리에 정의되어 있는가 | 핵심 용어 ≥ 10개, 인접 용어 비교 포함 |
| 언어 일관성 | 같은 개념이 문서 전체에서 같은 단어로 쓰이는가 | 동의어 혼용 0건 또는 컨텍스트별 분리 명시 |
| 컨텍스트 명시 | 시스템이 다루는 영역이 컨텍스트로 분리되어 있는가 | 컨텍스트 ≥ 2개 + 분류(Core/Supporting/Generic) |
| 컨텍스트 관계 | 컨텍스트 간 관계가 명시되어 있는가 | 9개 관계 패턴 중 선택, ACL 지점 표시 |
| Core 선언 | 무엇이 경쟁 우위인지 한 문장으로 적혀 있는가 | 단일 Core, Generic은 외부 의존 명시 |
| 변경 영향 범위 | 이번 기획이 어느 컨텍스트의 무엇을 바꾸는가 | 영향 컨텍스트 + 영향 종류(언어/구조/통합) |
합격선: 6축 중 ≥ 5개 ✅. Core 선언 ❌ 면 자동 불합격 — 이 한 가지는 경쟁 우위의 위치 를 명시하지 않은 기획으로, 다른 5축이 완벽해도 발신지가 없는 상태이기 때문이다.
출력 형식 — 누락은 missing 으로 명시
평가가 끝나면 작업 로그에 다음 블록이 부착된다 (sage-evans.md §5):
## DDD 전략 설계 평가 (sage-evans)
### 산출물
- 대상: {파일 경로 또는 산출물 식별}
- 도메인: {평가하는 비즈니스 도메인 한 줄}
### 6축 점검
| 축 | 결과 | 비고 |
|---|---|---|
| 유비쿼터스 언어 | ✅ / ⚠️ / ❌ | {누락 시 missing 표기} |
| ...
### 누락 사항
- ubiquitous-language: missing ← 글로서리 자체가 없음
- context-map: implicit ← 경계가 암묵적임 (Big Ball of Mud 위험)
- core-domain: undeclared ← 경쟁 우위 미선언
### Evans 인용
> "{인용문}" — Eric Evans, {출처}
### 다음 한 걸음
- {구체 권고 1}
- {구체 권고 2}
### 합격 여부
- 결과: 합격 | 부분 합격 | 불합격
데밍의 prediction: missing 과 같은 사상이다 — 없는 것은 없다고 명시한다. 추정으로 채우지 않는다.
안티패턴 — 에반스가 거부하는 것
규칙에 명시된 자동 거부 목록 (sage-evans.md §6):
| 거부 대상 | 거부 이유 |
|---|---|
| "용어는 코드 짜면서 정리한다" | 언어 작업은 첫 번째 산출물. 그 뒤로 미루면 영원히 미뤄짐 |
| 모든 컨텍스트에서 단어를 통일 | 같은 단어의 다른 의미 는 컨텍스트 분리의 신호 — 합치면 신호를 죽임 |
| "마이크로서비스 N개 = 컨텍스트 N개" | 에반스 본인이 2018·2019 InfoQ 에서 명시적으로 부정 |
| 기획자가 스키마·API·테이블 형태 를 지시 | 기획자가 다루는 영역은 언어와 경계 — 그 아래층은 위임 |
| 모든 도메인을 Core | "전부가 Core" = "Core 가 없다" |
| Evans 어록을 paraphrase | 정전의 권위는 단어 그대로의 인용 에서 온다 — 원문 + 출처 URL 필수 |
| 데밍 PDSA 를 건너뛰고 본인부터 평가 | 베이스는 항상 데밍, 에반스는 후속 — 학습 루프가 먼저 |
| 코드 변경만 있는 작업에 자동 발동 | 도메인 어휘·경계 무변경이면 호출 안 함 |
데밍과의 관계 — 항상 위에 얹힘
중요한 규칙: 에반스는 데밍 위에 얹힌다. 기본 평가는 항상 데밍 PDSA. 도메인이 매칭되는 작업에 한해 그 위에 에반스 6축이 덧대어진다. 이 순서가 거꾸로 되면 — 학습 루프 없이 도메인 점검만 받는 상황이 된다. 그러면 이번 분기에 무엇을 배웠는지 가 누락된 채 다음 사이클로 넘어간다.
4.8 기획자에게 일어나는 일 — 첫 30일
에반스 현자를 영입한 정원에서 기획자의 작업이 형태가 바뀌는 순서 는 대체로 이렇다.
1주차 — 글로서리 first draft
PRD 첫 페이지를 기능 리스트 가 아닌 글로서리 로 시작한다. 핵심 용어 10개, 각자 한 줄 정의 + 인접 용어 차이. 완벽할 필요 없다. 이번 회의에서 다듬는다.
도메인 전문가와의 첫 30분 워크숍 — 단어 채집 → 동의어 정리 → 인접어 비교. 그 자리에서 sage-evans가 자동으로 유비쿼터스 언어 축에 ⚠️ 또는 ✅ 를 매긴다.
2주차 — 같은 단어, 두 가지 의미를 찾는다
글로서리를 다듬다 보면 반드시 발견된다 — "주문이 두 가지 뜻으로 쓰이고 있어요". 이 자리가 컨텍스트 경계 의 후보. 두 컨텍스트로 분리하거나, 한쪽 단어를 양보한다.
여기서 컨텍스트 명시 축이 ✅ 로 전환된다.
3주차 — Core 선언
분기 로드맵 회의에서 한 문장을 적는다 — "우리 제품의 경쟁 우위는 {한 영역} 의 {한 능력} 이다." 한 문장에 합의가 안 되면 그 자체가 분기의 가장 큰 과제 다.
Core 가 선언되면 — 그 외 영역의 자원 배분이 자동으로 정해진다. Generic 영역의 인하우스 빌드 중단, Supporting 영역의 외주 검토 등.
4주차 — 컨텍스트 맵 첫 장
지금까지 발견한 컨텍스트·관계·Core 를 한 장에 그린다. 화이트보드면 충분하다. 사진을 찍어 PRD 첫 페이지에 붙인다.
이 시점에 sage-evans 6축이 5개 이상 ✅ 로 통과한다.
한 달의 끝에 기획서의 한국말이 정돈된 것 을 가장 먼저 알아채는 사람은 작성자 자신 이다. 같은 단어를 두 번 쓰지 않게 됐고, 모든 항목이 어느 컨텍스트의 변경인지 표시된다. 이것은 문장력의 향상 이 아니라 모델의 압축 의 부수효과다.
5. 두 번째 현자 — W. Edwards 데밍 (PDSA)
5.1 정체
W. Edwards Deming (1900–1993) — 통계학자, 컨설턴트, 제2차 세계대전 직후 일본 품질 혁명의 핵심 인물. 1951년 제정된 데밍상(Deming Prize) 은 세계에서 가장 오래된 국가 품질상 이며, 그의 영향이 80년이 지난 지금까지도 살아 있다는 증거다 (deming.org).
5.2 사상 — PDSA, Not PDCA
여기서 한국 기획자에게 가장 중요한 사실 한 가지:
데밍은 PDSA(Plan–Do–Study–Act) 를 의도했고, PDCA(Plan–Do–Check–Act)는 일본어→영어 번역 과정에서 왜곡된 변형 이라고 본인이 명시적으로 진술했다.
차이는 세 번째 단계 에 있다.
| Check (PDCA) | Study (PDSA) | |
|---|---|---|
| 묻는 것 | "한대로 했나?" | "무엇을 배웠나?" |
| 자세 | 컴플라이언스 | 가설 검증 |
| 결과 | Pass/Fail | 갱신된 이론 |
Check 는 컴플라이언스 — 즉 지침대로 했는지 여부 만 확인한다. Study 는 학습 — 즉 이번 사이클에서 새로 알게 된 것 을 빼낸다.
한국 기업의 애자일 회고 가 종종 컴플라이언스 회고 로 떨어지는 이유가 여기에 있다. "스프린트 목표를 다 마쳤나" 만 묻고 "우리가 무엇을 배웠나" 는 묻지 않는다. 그러면 다음 스프린트의 이론은 지난 스프린트와 같다.
애자일은 원래 방향 의 이야기였다. 방향을 갱신하려면 Study 가 Check 를 대체해야 한다.
5.3 sage-deming 에이전트 — 항상 작동하는 베이스 평가
하네스 카카시 배포 의 harness/agents/sage-deming.md 는 다른 에이전트들과 호출 조건이 다르다 — 도메인 매칭 이 아니라 작업이 끝나는 모든 순간 이다.
즉, 어떤 작업이든 (개선부 Mode A, 수행부 엔진, 에이전트 단독 실행 등) 종료 직전에 자동으로 PDSA 블록을 부착 한다.
| 블록 | 내용 |
|---|---|
| Plan | 목표 / 이론(예측) / 지표 |
| Do | 실행 요약 / 규모(small-scale, full-rollout) / 예상 외 발생 |
| Study | 예측 vs 실제 (일치/부분일치/불일치) / 새 학습 / 이론 수정 |
| Act | 결정(Adopt/Adapt/Abandon) / 다음 사이클의 이론 / 후속 평가 호출 |
| Cycle Health | 예측 명시 Yes/No / 학습 발생 Yes/No / 다음 적용 명확 Yes/No |
특히 Cycle Health 가 중요하다 — 예측 명시: No 가 나오면 PDCA 퇴화 로 표시된다. 즉, 예측을 적지 않고 진행한 작업은 학습이 약하다 는 신호가 자동으로 남는다.
"It is not enough to do your best; you must know what to do, and then do your best." — W. Edwards Deming
PDSA의 Plan(이론) 과 Study(학습) 는 이 문장의 운영적 구현이다. 베스트를 다하기 전에 무엇을 해야 하는지 알고, 다 한 뒤에 무엇을 배웠는지 안다. 그 둘 사이에 Do 가 있다.
5.4 기획자에게 일어나는 일
데밍 현자를 영입한 정원에서 기획자의 회고 는 형태가 바뀐다. 회고의 첫 항목이 더 이상 "무엇을 끝냈는가" 가 아니라 "이번 사이클의 예측은 무엇이었는가" 가 된다. 그리고 마지막 항목은 "잘했음/문제 없음" 같은 비학습 문구로 채워지지 않는다 — 그러면 Cycle Health: 학습 발생 No 가 자동으로 찍힌다.
처음에는 예측을 명시적으로 적는 것 자체가 어색하다. 하지만 두세 사이클이 지나면 — 예측이 얼마나 자주 빗나가는지 를 보면서 — 기획의 불확실성에 대한 감각 이 정량화된다. 그 감각은 다음 분기 로드맵을 더 단단하게 만든다.
6. 두 현자의 합주 — 한 사이클을 다 함께 본다
두 현자를 모두 모신 정원에서 한 사이클 의 여정은 두 정거장을 지나는 작은 산책길과 닮았다.
- 첫 정거장 — 에반스의 다실: 기획서·도메인 모델 초안을 들고 들어가면, 글로서리·컨텍스트 맵·Core 선언이 다듬어진다. 닫힌 루프 안에서 방향이 잡힌다.
- 중간 작업 구간: 다듬어진 모델을 들고 실제 기획·문서·개발이 진행된다.
- 두 번째 정거장 — 데밍의 정자: 사이클이 끝나면 예측 vs 실제, 새 학습, Adopt / Adapt / Abandon 이 한 장의 PDSA 블록으로 부착된다. 열린 루프가 다음 사이클로 이론을 전달한다.
여기서 두 현자의 분업 이 분명해진다:
- 에반스 — 작업이 시작될 때 / 산출물이 갱신될 때 의 언어와 경계 를 점검. 닫힌 루프 안에서 방향 을 잡아준다.
- 데밍 — 작업이 끝날 때 의 학습 을 추출. 열린 루프로 다음 사이클 에 이론을 전달한다.
이 분업이 무너지면 둘 중 한 사람만 영입한 정원 이 된다 — 데밍만 있으면 학습은 누적되지만 매번 잘못된 언어로 시작 한다. 에반스만 있으면 언어는 단정하지만 사이클 간 학습이 누적되지 않는다. 두 사람이 같이 있어야 한 바퀴 가 완전해진다.
Evans → Deming 의 순서는 우연이 아니다. 닫힌 루프에서 지침 을 받은 작업만이, 열린 루프에서 의미 있는 예측-실제 비교 의 재료가 된다.
7. 마치며 — 완성되지 않은 첫 여정
이 글이 완성된 정원 의 이야기였다면 거짓말이다. 우리는 이제 막 두 현자 를 모셨고, 아직 영입할 거인의 자리 는 많이 비어 있다. 칸반의 뿌리(린) 도, 시스템 사고(피터 셍게) 도, 결과 기반 사고 — OKR(Objectives and Key Results, 목표·핵심 결과) / MBO(Management by Objectives, 목표 관리) — 도 어느 한 자리에 들어올 후보들이다.
중요한 것은 하네스의 형태 자체 다. 정원이라는 느슨한 골격 위에 — 햇빛(knowledge), 영양분(agents), 물길(engine) 의 3층 토양 위에 — 현자(sage) 라는 위층 이 얹힐 자리가 비어 있다는 것을 우리가 발견한 것. 그 자리에 기획자가 직접 거인을 모셔 올 수 있다 는 것을 보인 것.
처음에는 정원이 글을 다듬는다. 다음 단계에서는 정원이 기획 을 다듬는다. 그리고 그 다음 — 정원이 다음 세대 기획자의 학습 곡선 을 다듬는다.
애자일도, DDD도 — 한 번도 학습 곡선이 평탄했던 적이 없다. 우리에게 그것을 천천히 익힐 시간이 없었다. 그러나 이제 하네스 엔지니어링 은 현자를 옆에 두고 일하면서 동시에 배우는 길을 만들어 준다.
이것은 완성되지 않은 첫 여정이다. 갑자기 터미널을 다루는 것도, 하네스를 짜는 것도 — 우리 중 누구에게도 자연스럽지 않다. 그러나 우리는 채택 하고, 학습 하고, 성장 하기로 했다.
지켜봐 주시길.
Roma non uno die aedificata est. — 로마는 하루아침에 이루어지지 않았다. 정원도 마찬가지다.
참고
- 현자(Sage) 영입의 본거지:
- BlumnAI-Studio/harness-kakashi — 하네스 카카시 배포팩, sage-evans·sage-deming 정의 파일이 들어 있다
- Eric Evans / DDD:
- Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003, ISBN 978-0-321-12521-7)
- Domain Language, Inc. — 에반스 본인의 컨설팅
- DDD Reference (2015, CC-BY 4.0) PDF
- 마틴 파울러 — BoundedContext
- InfoQ 2018 — DDD Is Not Done
- InfoQ 2019 — Improve Language with DDD
- Eric Evans on Domain Driven Design — InfoQ Interview
- W. Edwards Deming / PDSA:
- 2026년 하네스/에이전트 흐름:
- Nous Research — Hermes Agent — 지속 메모리 기반 오픈 에이전트, 비개발자 진입 가능
- NVIDIA Blog — Hermes Unlocks Self-Improving AI Agents
- Blumn.AI — 하네스 AI 엔지니어링 (시리즈의 출발점)
- 자매 글: