정원에 두 번째 현자를 모시다 — 'User'는 하나가 아니다, LLM 시대에 다시 발견하는 DDD

3줄 요약 • 복잡한 도메인에서 문제는 대개 모델이 너무 적어서가 아니라, 하나의 명사에 너무 많은 시간대·책임·변화 단계를 억지로 넣는 데서 시작된다. 'User', 'Order', 'Product'처럼 자연스러운 명사일수록 설계에서는 위험 신호다. • 같은 대상을 언제(Time) 보는가, 누구의 책임 관점에서(Angle) 보는가, 어느 깊이로(Depth) 모델링하는가를 분리하면 경계와 전환이 보인다 — 그리고 그렇게 찾은 경계가 변화에 견딜지는 **결합(Coupling)**이라는 별도의 축으로 검증한다. • 이것은 20년 전 DDD가 던진 질문의 2026년형 재발견이다. 에릭 에반스의 어휘(경계·언어·모델)는 낡지 않았다 — AI 에이전트 워크플로우를 설계하는 순간, 이 세 차원은 은유가 아니라 실행 구조가 된다. 우리 정원의 원탁이 그 실물이다.

1. 너무 자연스러운 명사는 위험 신호다

당신이 이런 상태라면 이 글은 당신을 위한 것이다. 회의 때마다 "유저"라는 같은 단어를 쓰는데 결론은 계속 어긋난다. 코드에는 if (user == null) 같은 방어문과 플래그가 자란다. 에이전트를 붙여 개발은 빨라졌는데, User 클래스는 가입자·결제 책임자·권한 보유자·고객지원 대상을 한 몸에 담은 채 점점 부풀어 오른다. 무엇이 잘못됐는지는 모르겠지만, 무언가 잘못되고 있다는 감각.

이번 편은 그 감각에 이름을 붙여 주는 글 한 편을 정원에 씨앗으로 심는다 — 'User'는 하나가 아니다 — 시간·관점·깊이로 다시 설계하는 소프트웨어 모델. 이번 편 전체가 이 씨앗에서 자라났으므로, 아래에서는 씨앗 글이라 부른다. 씨앗 글은 Damian Płaza의 Time, angle and depth: dimensions in software design(2025-07)을 발판으로, "사용자", "주문", "상품", "세션"처럼 너무 자연스러워서 아무도 의심하지 않는 명사가 어떻게 설계를 조용히 망가뜨리는지를 해부한다. 핵심 진단은 한 문장이다.

복잡한 도메인에서 문제는 대개 모델이 너무 적어서가 아니라, 하나의 명사에 너무 많은 시간대·책임·변화 단계를 억지로 넣는 데서 시작된다.

그리고 이 진단은 우리 정원이 3편에서 데밍을 모신 이래 두 번째 현자를 부르는 초대장이기도 하다. 명사를 의심하고, 경계를 긋고, 언어를 다듬는 학문 — 2003년 에릭 에반스의 DDD(Domain-Driven Design, 도메인 주도 설계)다. 다만 이번 편의 방향은 "DDD를 배우자"가 아니다. 씨앗 글이 보여주듯, DDD의 질문을 시간·관점·깊이라는 세 개의 움직이는 차원으로 다시 발견하는 것 — 그리고 그 차원들이 LLM(Large Language Model) 에이전트 시대에 어떻게 실행 구조가 되는지 확인하는 것이다.

2. 하나의 명사가 대화를 망가뜨리는 방식

씨앗 글이 빌려 온 Płaza의 이야기는 바닥재 판매·창고·시공 회사에서 출발한다. 판매 담당자에게 바닥재는 고객이 고른 경험이자 상품 약속이다. 창고 담당자에게는 입고·재고·보관 조건·출고 참조번호가 중요하다. 시공자에게는 현장 습도, 자재 상태, 설치 가능 여부가 핵심이다. 세 사람은 같은 단어를 쓰지만 같은 모델을 공유하지 않는다.

소프트웨어에서도 같은 일이 반복된다. 씨앗 글의 표를 그대로 옮긴다.

절대적으로 보이는 명사	실제로 섞인 관점
User	가입자, 인증된 주체, 결제 책임자, 권한 보유자, 고객지원 대상
Product	카탈로그 항목, 판매 가능한 재고 단위, 배송 물품, 설치 자재
Order	구매 의도, 결제 시도, 이행 요청, 회계 기록
Session	인증 전 앱 상태, 인증 완료 상태, 토큰 갱신 상태, 만료·로그아웃 상태

DDD의 바운디드 컨텍스트(Bounded Context)가 중요한 이유가 정확히 여기에 있다 — 큰 모델을 여러 컨텍스트로 나누고 그 관계를 명시해야, 팀과 시스템이 서로 다른 뜻을 같은 말에 숨기는 일을 줄일 수 있다. 하지만 씨앗 글은 여기서 멈추지 않고 한 발 더 나간다. 컨텍스트만 그려서는 충분하지 않다. 컨텍스트가 언제 어떤 순서로 만나고, 그 안에서 모델이 얼마나 깊게 다뤄져야 하는지가 빠지면, 설계는 다시 정적인 상자 그림이 된다. 그 부족분을 채우는 것이 세 개의 차원이다.

3. 세 개의 차원 — 관점·시간·깊이

씨앗 글의 관용구는 "시간·관점·깊이"다. 그러나 이 절은 관점부터 본다 — 시간은 관점 위에 얹혀야 비로소 핸드오프가 보이고, 깊이는 그 둘이 보인 뒤에야 고를 수 있는 축이기 때문이다. 세 차원은 같은 명사를 서로 다른 방향에서 자르는 세 개의 칼이다.

3.1 관점(Angle) — '누가 무엇을 책임지는가'

여기서 관점은 단순한 사용자 화면 관점이 아니다. 특정 목적과 책임 때문에 같은 대상을 다르게 단순화하는 업무적·기술적 시선이다.

관점이 잘 분리된 설계는 "바닥재"를 억지로 공유 엔터티 하나로 만들지 않는다. 창고 컨텍스트에는 InventoryItem, 시공 컨텍스트에는 InstallationMaterial이 있을 수 있다. 둘이 같은 물리 자재를 가리키더라도, 하나는 재고·위치·보관을 책임지고 다른 하나는 현장 조건·설치 가능성·품질을 책임진다.

판매 ──주문 요청──▶ 창고 ──출고 통지──▶ 시공
 ▲                                      │
 └──────────────완료 결과────────────────┘

관점 분리의 목적은 이름을 늘리는 것이 아니다. 각 모델에서 불필요한 세부사항을 제거하고, 그 모델의 결정과 불변식(invariant, 항상 참이어야 하는 규칙)을 선명하게 하는 것이다. 그래서 질문의 순서가 바뀐다 — "이 필드는 어느 서비스에 둬야 하나?"보다 먼저 물어야 할 것은 **"이 사실을 이용해 결정을 내리고, 그 결과에 책임지는 사람(컨텍스트)은 누구인가?"**다.

우리 정원에서는 — 검수 하네스가 이 원리로 서 있다. 같은 원고 한 편을 문서 검토관은 명료성의 관점에서, 문체 감독은 표기의 관점에서, 용어 사서는 용어 일관성의 관점에서 본다. "원고"라는 명사는 하나지만 모델은 세 개이고, 각자 자기 결정에만 책임진다. 관점을 합치지 않은 것이 이 정원이 가장 잘한 설계였다.

3.2 시간(Time) — 상태가 아니라 '전환'을 보라

씨앗 글이 짚는 가장 실용적인 통찰은 이것이다 — 관점을 시간축에 올리는 순간, 정적인 컨텍스트 지도가 핸드오프(handoff, 인계) 지도가 된다. 판매·창고·시공이 각자 존재한다는 사실보다 중요한 것은, 주문 정보가 판매에서 창고로, 자재가 창고에서 시공으로, 완료 사실이 다시 고객 경험으로 넘어가는 순서다.

시간축을 추가하면 비로소 이런 질문이 가능해진다.

• 이 사실은 어느 시점에 처음 생기는가?
• 어느 컨텍스트가 다음 컨텍스트에 무엇을 넘겨야 하는가?
• 전달 전에는 불가능하고, 전달 후에만 가능한 행동은 무엇인가?
• 지연, 재시도, 취소, 보상은 어디에서 일어나는가?

판매 ──▶ 창고 : 자재 예약
창고 ──▶ 판매 : 예약 완료 or 재고 없음
창고 ──▶ 시공 : 자재 출고
시공 ──▶ 시공 : 현장 조건 검증
시공 ──▶ 판매 : 설치 완료 or 반려

이 관점은 코드 속의 흔한 풍경을 다시 읽게 한다. "User가 null인가?" 같은 조건문은 단순한 방어 코드가 아니라, 아직 이름 붙이지 못한 시간적 전환의 신호다. 앱이 토큰이 없을 때와 생긴 뒤에 완전히 다른 규칙으로 동작한다면, AppState 하나에 선택 필드를 계속 쌓기보다 UnauthorizedAppState → AuthenticatedAppState라는 상태 전환을 모델링하는 편이 정직하다. 상태 기계는 정확히 이런 식으로 상태와 전이를 명시하고, 자극에 따라 달라지는 시스템의 반응을 드러내는 오래된 도구다.

우리 정원에서는 — 12편의 원탁이 이 원리의 실물이다. 원탁의 일곱 라운드(문제 정의 → 독립 의견 → 발산 → 교차 질문 → 레드팀 → 수렴 → 결정)는 회의라는 모호한 명사를 전환의 연쇄로 분해한 것이다. 각 라운드는 이전 라운드의 산출물이 넘어와야만 시작되고, 서브에이전트의 완료 이벤트가 다음 라운드를 연다 — "회의 중"이라는 상태 하나가 아니라, 무엇이 언제 가능해지는지의 핸드오프 지도다.

3.3 깊이(Depth) — '어느 해상도까지 내려갈 것인가'

시간과 관점이 보인다고 곧바로 가장 정교한 모델을 만들어야 하는 것은 아니다. 깊이는 특정 문제를 어느 해상도로 표현할지 선택하는 축이다. 씨앗 글의 표가 이 축을 잘 요약한다.

질문	깊이	언제 충분한가	흔한 표현
무엇을 저장하는가?	데이터	조회·전달 중심일 때	DTO(Data Transfer Object), 테이블, 속성
무엇을 할 수 있고 무엇이 금지되는가?	규칙/행위	불변식이 중요할 때	메서드, 도메인 규칙, 검증
어떤 조건에서 다른 존재가 되는가?	상태 전환	순서와 수명주기가 핵심일 때	상태 기계, 이벤트, 프로세스
한 모델이 왜 분리·변형되는가?	변화/Becoming	기존 명사가 여러 책임을 숨길 때	컨텍스트 분리, 이벤트 흐름, 새로운 모델

예를 들어 Install() 전에 Delivered가 참이어야 한다면, 처음에는 메서드 안의 가드 절 하나면 충분할 수 있다. 하지만 배송과 설치가 서로 다른 책임·실패 모드·시간대를 가진다면, 그 가드는 더 깊은 구조의 신호다 — InventoryItem과 InstallationMaterial을 분리하고, 배송이 둘을 잇는 명시적 이벤트가 될 수 있다.

핵심 문장은 이것이다. 깊이는 복잡성의 반대말이 아니다. 너무 얕으면 중요한 전환이 null 검사와 플래그 속에 숨고, 너무 깊으면 변화가 적은 문제에 과도한 의식과 모델을 들이민다. 좋은 설계는 가장 깊은 모델을 찾는 것이 아니라, 현재 위험을 설명하는 데 필요한 최소 깊이를 찾는다.

우리 정원에서는 — 이 절제를 배우는 데 오래 걸렸다. 가벼운 문안 교정에는 검수자 한 명이면 족하고(데이터 깊이), 게시 승급에는 3인 검수와 루브릭이 붙고(규칙 깊이), 방향이 걸린 결정에만 원탁의 7라운드가 열린다(상태 전환 깊이). 모든 일에 원탁을 열었다면 정원은 회의로 말라 죽었을 것이다.

4. 차원을 함께 움직이기 — 질문법과 결합 검증

차원은 하나씩 쓸 때보다 함께 움직일 때 힘이 난다. 순서도 있다 — 먼저 세 차원으로 경계를 찾고(탐색), 그 경계가 변화에 견디는지를 결합으로 되묻는다(검증).

4.1 세 차원을 함께 움직이는 질문법

세 차원을 한 번에 적용하면 "클래스를 어떻게 나눌까?"라는 질문이 설계 탐색으로 바뀐다. 씨앗 글이 제공하는 진단표는 그대로 실무에 붙일 수 있다.

진단 신호	가능한 설계 이동	던질 질문	먼저 움직일 차원
같은 단어로 회의가 계속 어긋난다	바운디드 컨텍스트·용어 분리	누가 어떤 결정에 책임지는가?	Angle
플래그·null·순서 의존 조건이 늘어난다	상태 기계·이벤트·핸드오프 모델	무엇이 언제 가능해지는가?	Time
도메인 규칙이 컨트롤러와 DB 사이에 흩어진다	행위 모델·불변식 캡슐화	이 규칙은 데이터인가 행위인가 전환인가?	Depth
공유 모델 하나를 모든 팀이 수정한다	소유권·계약·변환 경계 명시	어떤 사실을 누가 만들고 누가 소비하는가?	Angle + Time
분리했는데 변경 비용이 더 커졌다	결합 재조정·거리 축소 또는 계약 단순화	공유 지식·변화 빈도·거리는 어떤가?	Coupling

4.2 결합(Coupling) — 찾은 경계를 검증하는 별도의 축

표의 마지막 행이 중요한 구분을 연다. 씨앗 글은 Vlad Khononov의 Balanced Coupling 프레임워크를 이어 붙인다 — 결합을 단일 숫자가 아니라 **강도(Strength), 변동성(Volatility), 거리(Distance)**로 보는 틀이다. 소개되는 식 Pain = Strength × Volatility × Distance는 자동 산출 공식이 아니라 변경 비용을 논의하기 위한 휴리스틱이다.

이 구분이 이 글에서 가장 정교한 대목이다. 시간·관점·깊이는 현실을 잘라 모델을 발견하는 탐색 차원이고, 결합의 강도·변동성·거리는 그렇게 분리한 모델이 변화 앞에서 얼마나 고통스러운지 묻는 검증 차원이다.

• 공유 지식이 많고 자주 변한다면, 두 모델을 멀리 떼어 놓을수록 계약·동기화 비용이 커질 수 있다.
• 반대로 공유 지식이 약하거나 변화가 드물다면, 분리는 독립 배포와 이해 가능성을 높인다.
• 그래서 "마이크로서비스로 나누자 vs 모놀리식으로 두자"는 이분법은 과녁이 빗나갔다 — 진짜 질문은 어떤 결합을 어느 거리에서 감당할 것인가다.

우리 정원에서는 — 이 이중 구조가 낯설지 않다. 탐색과 검증의 분리 — 12편의 원탁이 발산 라운드와 수렴 루브릭을 분리하고, 모든 제안에 레드팀 라운드를 별도로 붙인 것과 같은 문법이다. 좋은 방법론은 발견하는 축과 반증하는 축을 섞지 않는다.

5. AI 에이전트에 적용하기 — 그리고 우리 원탁이라는 실물

이 사고법이 2026년에 각별히 절실한 이유가 있다. 씨앗 글의 후반부는 이것을 AI 에이전트와 장기 실행 워크플로우에 직접 적용한다. "에이전트"라는 단어 하나에 계획 수립, 검색, 도구 실행, 승인, 감사, 기억을 모두 넣으면 대개 책임이 뭉개진다 — 'User'에서 벌어졌던 그 일이, 지금 'Agent'에서 그대로 반복되고 있다.

에이전트 시스템에서의 적용	차원
Planner(계획), Executor(실행), Verifier(검증), Auditor(감사)는 같은 목표를 보지만 서로 다른 책임을 갖는다	Angle
목표 수신 → 컨텍스트 획득 → 계획 → 도구 실행 → 검증 → 승인/배포 → 감사 기록의 전환을 명시한다	Time
단순 작업은 프롬프트·도구 호출이면 되지만, 고위험 작업은 권한 상태·예산·재시도·사람 승인·복구 모델까지 내려간다	Depth
도구 계약, 메모리 스키마, 평가 기준이 함께 자주 바뀌는지와 각 컴포넌트의 거리를 점검한다	Coupling 검증

목표 ─▶ Planner ─▶ Executor ─▶ Verifier ─▶ 감사 기록 (승인 시)
           ▲                       │
           └────────수정 필요───────┘

씨앗 글은 이 흐름의 핵심을 정확히 못박는다 — 에이전트를 여러 개 만든다는 데 있지 않다. 각 단계가 언제 다음 상태로 갈 수 있는지, 무엇을 넘기며, 실패가 어디로 되돌아가는지를 계약으로 만드는 데 있다. 이것이 시간 차원을 빠뜨린 "멀티에이전트 역할표"와 실제로 작동하는 워크플로우의 차이다.

여기서 12편의 규약("설계도 말고 실물을 못박아라")을 지킬 차례다. 위 표는 우리 정원에서 이론이 아니다. 원탁의 실제 배선이 정확히 이 구조다.

씨앗 글의 요소	우리 원탁의 실물 (12편에서 공개)
Planner / Executor / Verifier / Auditor (Angle)	원탁지기(진행)·전문가 서브에이전트(의견)·붉은 가시 CRUCIBLE(반증)·강제 회의록(감사)
전환의 명시 (Time)	7라운드 — 각 라운드는 이전 산출물의 인계로만 열리고, 완료 이벤트로 다음이 시작된다
위험도별 깊이 (Depth)	교정 1인 → 승급 3인+루브릭 → 방향 결정만 원탁 7라운드
결합 검증 (Coupling)	전문가 간 직접 호출 금지, 진행자만 허브 — 격리 소환이 곧 거리 관리

재현 고지. 이 대응은 사후 발견이다 — 우리는 씨앗 글을 읽고 원탁을 지은 것이 아니라, 지어 놓고 이 글을 만나 포개어 보니 맞아떨어졌다. 이 겹침이 오히려 논지의 증거라고 생각한다. 멀티에이전트 시스템을 정직하게 지으면, 시간·관점·깊이를 분리하라는 처방에 저절로 도착한다. 20년 전 질문이 여전히 유효하다는 말의 실물이 이것이다. 다만 우리 원탁이 유일한 답은 아니며, 같은 차원에서 다른 구조가 나올 수 있음을 함께 밝혀 둔다.

6. 실전 워크숍 — 30분 설계 리셋

씨앗 글은 담론으로 끝나지 않고 화이트보드 절차를 준다. 문제가 되는 명사 하나를 고른 뒤, 다음 순서로만 진행해도 모델의 막힘이 자주 풀린다.

1. 명사를 의심한다 — "이 User/Order/Product는 정확히 어느 순간의, 누구에게 중요한 대상인가?"
2. 관점을 세 개 이상 적는다 — 소비자·운영자·감사자, 또는 판매·창고·시공처럼 실제 책임자를 기준으로 삼는다.
3. 핸드오프를 시간 순서로 그린다 — 누가 어떤 사실을 만들고, 누가 소비하고, 실패하면 어디로 돌아가는지 적는다.
4. 가장 아픈 규칙 하나만 깊게 판다 — 전체를 DDD화하지 말고, 순서·불변식·복구가 중요한 지점 하나만 상태/행위 모델로 내린다.
5. 변경 시뮬레이션을 한다 — 요구사항 하나가 바뀐다고 가정하고 강도·변동성·거리 관점에서 비용을 토론한다.
6. 최소 세 모델을 비교한다 — 단일 모델 유지, 컨텍스트 분리, 상태 전환 도입처럼 서로 다른 선택지의 비용을 나란히 놓는다.

네 번째 항목을 다시 읽어 보라 — "전체를 DDD화하지 말라." 이것이 씨앗 글과 20년치 DDD 실패담의 갈림길이다. 방법론을 의식(儀式)으로 도입한 조직은 모든 것을 애그리거트(aggregate, 하나의 일관성 경계로 묶는 객체 뭉치)로 만들다 지쳤고, 이 워크숍은 가장 아픈 지점 하나에 최소 깊이만 요구한다.

우리 정원에서는 — 이 워크숍의 축소판이 이미 돌고 있다. 원탁의 개회 다섯 질문(목적·오늘 결정할 것·모르는 것·필요한 전문가·산출물)이 그것이다. 명사 하나를 의심하는 30분이, 우리에게는 회의 하나를 여는 다섯 줄이다.

7. 마치며 — 모델은 정답이 아니라 관측 장비다

씨앗 글의 가장 좋은 문장은 마지막에 있다 — '절대 개념'을 경계하라. User나 Product라는 이름이 틀렸다는 뜻이 아니다. 다만 그 이름이 너무 많은 질문을 멈추게 한다면, 그것은 편리한 모델이 아니라 복잡성을 숨기는 덮개다. 시간은 "언제 가능한가"를 묻게 하고, 관점은 "누가 책임지는가"를 묻게 하며, 깊이는 "어느 해상도까지 내려가야 하는가"를 묻게 한다. 그리고 결합 비용은 그렇게 찾은 경계가 변화에 견딜지를 검증한다. 좋은 모델은 현실 전체를 복제하지 않는다. 지금 내려야 할 결정을 더 잘 보이게 만든다.

이제 이 글이 왜 "LLM 시대에 다시 발견하는 DDD"인지 정리할 수 있다. 에릭 에반스가 2003년에 낸 구체적 답(객체 그래프, 두꺼운 도메인 레이어)은 시효가 다해간다. 그러나 그가 던진 질문 — 복잡성은 기술이 아니라 도메인에 있다, 그것을 다루는 언어와 경계를 어떻게 세울 것인가 — 은 에이전트 시대에 더 절실해졌다.

창시자 본인도 같은 방향을 보고 있다. 에반스는 2024년, LLM 통합 실험을 권고하며 "파인튜닝된 모델 자체가 하나의 바운디드 컨텍스트"라 했고, 2026년 DDD Europe 키노트에서는 "AI는 DDD를 증폭하는가, 대체하는가"를 정면으로 물었다. 그의 가설 — 모델도, 경계도, 언어도 여전히 중요하다. 다만 다르게 보일 것이다. 씨앗 글은 그 "다르게"의 구체형이다. 경계는 상자 그림에서 핸드오프 계약으로, 유비쿼터스 언어(Ubiquitous Language)는 사람의 규율에서 에이전트가 읽는 컨텍스트로, 모델은 정답에서 관측 장비로.

마지막으로 실 하나를 당겨 둔다. 관측 장비는 세워 두는 것으로 끝나지 않는다 — 관측한 것에서 배워야 다음 관측이 나아진다. 지난 20년 DDD를 "도입"한 조직 대부분은 다이어그램과 용어집을 체크하고도 형식만 남겼지만, 창시자는 자기 방법론이 왜 작동했는지를 다시 배우며 그것을 진화시키고 있다. 점검(Check)은 방법론을 박제하고, 학습(Study)은 방법론을 살린다 — 12편의 회고에서 스치듯 만난 데밍의 그 구분이다.

다음 편에서 그 질문으로 정면으로 들어간다. 3편에서 모셔 온 첫 번째 현자, 데밍의 PDSA(Plan-Do-Study-Act) 심화편이다. 왜 점검만으로는 아무것도 지켜지지 않는가, 왜 "왜 그렇게 작동하는지"를 배우는 조직만이 도구를 진화시키는가 — 데밍이 말년에 Check라는 글자를 거부하면서까지 지키려 한 것의 정체를 캔다.

정원 은유로 맺는다. 오늘 정원에 들어온 현자는 'User'라고 적힌 커다란 화분 앞에 멈춰 서서 이렇게 물었다 — 이 화분에 몇 종류의 꽃이 심겨 있는지 세어 본 적 있는가. 언제 핀 꽃인지, 누가 돌보는 꽃인지, 뿌리는 얼마나 깊은지. 화분의 이름표 하나로 그 모든 질문을 덮어 두지는 않았는가.

Nomina si nescis, perit et cognitio rerum — 이름을 알지 못하면, 사물에 대한 앎도 사라진다. 식물학자 린네의 말이다. 정원의 일이 곧 설계의 일이다.

하네스의 이야기는 계속됩니다. 감사합니다 💙

참고 자료

씨앗 글

• 'User'는 하나가 아니다 — 시간·관점·깊이로 다시 설계하는 소프트웨어 모델 (웹노리 기고)

원출처

• Damian Płaza — Time, angle and depth: dimensions in software design (2025-07) — 씨앗 글의 출발점
• Martin Fowler — Bounded Context
• Martin Fowler — State Machine
• Vlad Khononov — Balanced Coupling — 강도·변동성·거리
• Alec Sharp & Patrick McDermott, 『Workflow Modeling』 — 핸드오프 다이어그램
• Eric Evans, 『Domain-Driven Design: Tackling Complexity in the Heart of Software』 (Addison-Wesley, 2003)
• InfoQ — Eric Evans Encourages DDD Practitioners to Experiment with LLMs (2024-03)
• DDD Europe 2026 — Opening Keynote: Eric Evans
• W. Edwards Deming, 『The New Economics』 (1993) — PDSA, "Check가 아니라 Study"

함께 읽으면 좋은 글 (같은 저자의 DDD 연작)

• DDD가 만든 세 갈래 길 — 에릭 에반스, 반 버논, 그렉 영을 다시 읽어야 하는 이유
• DDD의 한계를 정확히 보기 — 그 한계 위에 세우는 AI 시대 우리만의 방식

시리즈 내부 연결

• 3편: 기획자를 위한 하네스 — 정원 위에 현자를 모시다 (데밍 현자 영입)
• 12편: 빈 원탁에 꽃이 앉다 — 정원에 회의실을 짓고 첫 회고를 열다 (원탁 7라운드·격리 소환·"실물을 못박아라" 규약)