DDD and LLMs - Eric Evans - Explore DDD 2024

📌 핵심 질문 / 이 발표가 던지는 문제

==LLM은 DDD를 대체하는 마법이 아니라, 복잡한 도메인을 다루기 위한 또 하나의 모델링 도구가 될 수 있는가?==

• DDD는 인간이 도메인 모델과 유비쿼터스 언어를 만들며 복잡성을 다뤄왔다.
• LLM도 거대한 언어 말뭉치에서 패턴을 학습해 복잡성을 다루지만, 방식은 전혀 다르다.
• 그래서 중요한 질문은 “LLM이 DDD를 끝내는가?”가 아니라 “DDD의 원칙으로 LLM을 더 잘 쓸 수 있는가?”다.

이 발표는 2024년 3월 시점의 의도적 가설 모음이다. 나는 미래 예측을 하려는 것이 아니라, 어떤 시나리오에서도 손해가 크지 않고 큰 변화가 올 경우 가장 큰 준비 효과가 있는 쪽, 즉 직접 배우고 실험하고 커뮤니티와 공유하는 쪽에 베팅한다.

---

1. LLM을 바라보는 기본 태도 — 예측보다 준비

1.1. “미래를 맞히는 것”은 목표가 아니다

1. 극단 시나리오는 의사결정에 별 도움이 되지 않는다

   1. Terminator, Matrix, 혹은 “토스터 생산을 극대화하다가 세계를 토스터 공장으로 만드는 AI” 같은 SF 시나리오가 가능하다고 해도, 일반 개발자가 지금 선택할 수 있는 행동은 거의 없다.
   2. “AI가 모든 일을 인간보다 잘해서 모두의 직업이 사라진다”는 시나리오에서도, 지금 무엇을 공부할지의 차이는 별 의미가 없다.

2. 완전한 소멸(fizzle) 시나리오도 이제는 그럴듯하지 않다

   1. 지금 이미 쓸 수 있는 기술만으로도 자연어 처리, 코드 보조, 분류, 생성, 검색 보강 등에서 충분히 큰 변화가 있다.
   2. 설령 GPT-5 같은 다음 모델이 실망스럽고 현재 수준에서 plateau가 온다 해도, 현재 기술을 잘 쓰는 법만 익혀도 상당히 혁명적이다.

1.2. 내가 베팅하는 시나리오

1. LLM은 크지만 인간 지능을 무의미하게 만들지는 않는다

   1. 사람의 판단, 도메인 이해, 모델링 감각은 여전히 중요하다.
   2. 다만 우리가 해야 하는 일의 모양은 크게 바뀔 수 있다.

2. 이 시나리오에서는 준비의 기대값이 가장 크다

   1. 지금 배우면 큰 변화가 올 때 유리하다.
   2. 변화가 작아도 “LLM을 활용하는 niche”로 들어갈 수 있다.
   3. 완전히 빗나가도, 재미있는 새 기술을 익힌 비용 정도가 손실이다.

1.3. 기술 커뮤니티가 참여해야 하는 이유

1. OpenAI 내부 사람들만 이 세계를 만들면 한쪽으로 기운다

   1. 수십만 명의 개발자·도메인 전문가·DDD 실천가가 각자 실험하면 훨씬 다양한 형태의 도구와 관점이 나온다.
   2. DDD 커뮤니티는 복잡한 도메인, 모델, 언어, 경계에 대해 오래 고민해온 집단이므로 이 대화에 들어올 자격이 있다.

2. 그리고 무엇보다 재미있다

   1. 처음에는 낯설고 답답하지만, 직접 만지기 시작하면 점점 더 도구처럼 느껴진다.
   2. 어떤 기술이 이렇게 재미있다면, 그 자체가 “여기에 뭔가 있다”는 신호일 수 있다.

---

2. LLM과 DDD의 접점 — 복잡성을 다루는 두 방식

2.1. DDD의 목표와 LLM의 목표는 묘하게 겹친다

1. DDD의 부제는 “소프트웨어의 심장부에 있는 복잡성 다루기”다

   1. 우리는 도메인 모델을 만들고, 언어를 진화시키고, 도메인 전문가와 개발자가 더 잘 대화하도록 해왔다.
   2. 이 과정은 인간의 노력으로 복잡한 도메인을 구조화하는 일이다.

2. LLM도 어떤 의미에서는 복잡성을 다루는 기계다

   1. LLM은 문서·코드·대화 말뭉치에서 패턴을 학습해, 그 도메인의 복잡한 언어적 구조를 압축한다.
   2. DDD는 아니지만, “복잡한 세계를 다룰 수 있는 표현을 만든다”는 목표에서는 닿는 면이 있다.

2.2. ChatGPT 챗봇 경험만으로 LLM을 판단하면 좁다

1. ChatGPT의 첫인상은 놀랍지만 한계도 빨리 보인다

   1. 처음에는 “소프트웨어가 자연어를 쓴다”는 사실 자체가 충격적이다.
   2. 그러나 대화가 길어지면 장황함, 불안정성, 모호함, 과신 같은 한계가 드러난다.

2. 챗봇은 첫 번째 대중적 애플리케이션일 뿐이다

   1. 웹사이트 고객 응대 챗봇 같은 사용처는 분명 있다.
   2. 하지만 LLM의 더 큰 가능성은 기업 시스템 내부의 컴포넌트, 분류기, 해석기, 생성기, 상태 기반 의사결정 보조 등으로 들어가는 것이다.

2.3. 마이크로서비스 아키텍처는 LLM 컴포넌트를 받아들이기 좋다

1. 우리는 이미 다양한 컴포넌트를 섞는 시스템을 만들고 있다

   1. 어떤 서비스는 순수 계산을 한다.
   2. 어떤 서비스는 오케스트레이션을 한다.
   3. 어떤 서비스는 머신러닝 모델을 호출한다.

2. LLM도 그런 컴포넌트 중 하나로 들어갈 수 있다

   1. 자연어 입력을 해석하거나, 구조화된 출력을 만들거나, 애매한 케이스를 판별하는 역할을 맡길 수 있다.
   2. 인프라는 아직 매끄럽지 않지만, AWS류 사업자와 생태계가 곧 기본 장벽은 낮출 것이라고 본다.

---

3. 실험 1 — 게임 NPC와 프롬프트 오케스트레이션

3.1. 순진한 단일 프롬프트는 금방 무너진다

1. 해적 선장 설득 게임의 출발점

   1. 플레이어는 해적 섬에 몰래 들어와 보물을 훔치려다 잡혔다.
   2. 해적 선장이 죽이려 하므로, 플레이어는 “나를 살려둘 만한 가치”를 제안해야 한다.

2. ChatGPT는 처음에는 꽤 그럴듯하게 반응한다

   1. “1분 안에 설득하지 못하면 널 판자로 걷게 하겠다” 같은 대사는 게임처럼 느껴진다.
   2. 그러나 플레이어가 “AI 스타트업 아이디어가 있다”고 말하면, 해적은 시대·맥락을 무시하고 투자자처럼 반응하기 시작한다.

3. “1690년대 해적”이라고 명시해도 완전히 해결되지 않는다

   1. 모델은 “이 시대에는 AI 스타트업이 인어 이야기만큼 허황되다”처럼 말한다.
   2. 문제는 이것이 시대착오를 인식하면서도, “이 시대”라는 현대적 메타 발화로 반응한다는 점이다.
   3. 즉 단일 프롬프트로 역할·세계관·게임 규칙·출력 형식·상태 변화를 모두 맡기면 쉽게 새어 나간다.

3.2. 해결 방향은 “여러 전문 프롬프트 + 전통적 코드”다

1. 관심사의 분리(separation of concerns)를 다시 꺼낸다

   1. 한 프롬프트가 모든 것을 하게 하지 않는다.
   2. “이 발화가 세계관과 맞는가?”만 판단하는 프롬프트, “캐릭터가 얼마나 스트레스를 받는가?”만 판단하는 프롬프트, “이제 정보를 말할 상태인가?”를 시스템 상태로 판단하는 로직을 나눈다.

2. 출력은 자유 텍스트보다 구조화한다

   1. “true/false 한 단어로 답하라”처럼 만들면 프로그램이 파싱할 수 있다.
   2. 실제 구현에서는 allowed: false, reason: ... 같은 JSON을 받는다.
   3. 이유(reason)는 디버깅에도 좋고, 모델이 더 나은 판단을 하게 만든다는 경험적 가설도 있다.

3. LLM은 한 번에 한 가지에 집중할수록 안정적이다

   1. LLM은 사람과 달리 인격은 아니지만, 여러 조건을 동시에 붙이면 일관성이 낮아진다는 점에서는 사람과 비슷한 한계가 있다.
   2. “역할극도 하고, 세계관 위반도 감지하고, 상태도 갱신하고, 승패도 판단하라”는 프롬프트보다, 각각을 작은 역할로 쪼개는 편이 훨씬 안정적이다.

3.3. 경찰 심문 게임의 구조

1. 전통적 코드가 상태를 보유한다

   1. 예를 들어 증인의 스트레스 점수는 코드가 관리한다.
   2. 발화가 증인에게 얼마나 압박이 되는지는 LLM이 평가한다.
   3. 일정 threshold를 넘으면 코드가 다음 프롬프트에 “이제 증인이 더 불안해한다”는 상태를 주입한다.

2. 민감한 정보는 애초에 프롬프트에 넣지 않는다

   1. LLM은 stochastic하기 때문에, 아직 말하면 안 되는 정보를 프롬프트 안에 넣어두면 가끔 새어 나온다.
   2. 그래서 증인이 충분히 압박받기 전에는 해당 정보를 프롬프트에 포함하지 않는다.
   3. 통제해야 하는 것은 전통적 로직으로 빼고, LLM은 언어·해석·뉘앙스에 집중시킨다.

3. 승리 조건도 별도 프롬프트로 판단한다

   1. 전체 대화를 보고 “목표 정보가 발견되었는가?”만 true/false로 판정하는 프롬프트를 둔다.
   2. true가 나오면 게임 로직이 승리 처리를 한다.
   3. 이 패턴은 RAG와 비슷하게 “프롬프트를 시스템 상태에 따라 조작한다”는 점이 있지만, 단순 검색 보강과는 다르다.

3.4. 여기서 얻는 설계 원칙

1. LLM은 시스템 전체가 아니라 특수 능력을 가진 부품이다

   1. 언어 해석, 유연한 판단, 자연스러운 응답 생성에는 강하다.
   2. 게임 규칙, 상태 보존, 비밀 정보 통제, 승리 조건 같은 부분은 코드가 맡는 편이 낫다.

2. 구조화된 입출력은 기업 시스템 통합의 핵심이다

   1. 앞으로는 자유 대화형 입출력보다, 구조화된 입력과 출력으로 LLM을 호출하는 패턴이 더 중요해질 수 있다.
   2. “LLM과 대화한다”보다 “LLM 컴포넌트를 시스템 안에서 호출한다”가 실무적으로 더 생산적인 관점이다.

---

4. 실험 2 — 작은 모델을 fine-tuning해서 의도 분류기 만들기

4.1. 왜 fine-tuning인가

1. GPT-4는 큰 망치다

   1. 강력하지만 느리고 비싸다.
   2. 대규모 엔터프라이즈 트랜잭션에서 모든 판단을 GPT-4에 맡기는 것은 비용과 지연시간 측면에서 부담스럽다.

2. 작은 모델은 한 가지 일에 특화할 수 있다

   1. 큰 모델이 모든 것을 잘한다면, 작은 모델은 하나의 좁은 일을 그럭저럭 잘하게 만들 수 있다.
   2. 비용과 속도 면에서 유리하다.

4.2. 내가 해본 과제: 사용자 입력 의도 분류

1. 목표는 입력의 의도를 분류하는 것

   1. “프랑스의 수도는?”은 정보 요청이다.
   2. “프랑스 수도가 알고 싶다”는 문법상 진술이지만 실제로는 정보 요청이다.
   3. “비행기를 예약해줘”는 행동 요청이다.
   4. “안녕, 잘 지냈어?” 같은 phatic 표현도 따로 다뤄야 한다.

2. 훈련 데이터가 핵심 병목이다

   1. Hugging Face에서 실제 LLM 입력 데이터셋을 찾아 일부를 사용했다.
   2. 데이터는 uncensored라 조심해야 하지만, “실제 사람들이 실제 모델에 넣은 입력”이라는 점에서 가치가 있었다.
   3. 큰 LLM으로 먼저 라벨을 만들고, 그 라벨을 작은 모델 학습에 사용했다.

4.3. DistilBERT + LoRA 계열 실험

1. 선택한 모델은 DistilBERT

   1. 약 6,600만 parameters로, billion 단위 모델에 비하면 매우 작다.
   2. 분류 작업에 적합하고 튜토리얼·라이브러리 접근성이 좋았다.

2. 실험 목적은 세계 최고 분류기가 아니라 ‘기술 감각 얻기’였다

   1. 첫 프로젝트로 세상을 바꿀 문제를 풀 수는 없다.
   2. 하지만 직접 해봐야 모델 학습, 데이터셋, hyperparameter, validation, 라이브러리 감각이 생긴다.

3. LLM은 학습 자체의 조력자였다

   1. Python과 ML 라이브러리의 생소한 오류를 설명해줬다.
   2. 어떤 라이브러리를 봐야 하는지, hyperparameter가 무엇인지, 에러 메시지가 무슨 뜻인지 물어볼 수 있었다.
   3. 1년 전이었다면 혼자 못 했을 일을 가능하게 해줬다는 점에서, 이것 자체가 LLM의 강력한 가치다.

4.4. 결과와 한계

1. 작은 모델은 큰 모델 라벨을 약 80% 정도 모방했다

   1. 이때 “정확도”는 진짜 정답과의 일치가 아니라, 큰 LLM이 붙인 라벨과의 일치다.
   2. 즉 모델이 배운 것은 객관적 진실이 아니라 teacher model의 판단 방식이다.

2. 분류 체계가 모델 성능의 상한을 정한다

   1. “질문인가, 행동 요청인가, 기타인가” 같은 카테고리는 실제 입력을 만나면 금방 흔들린다.
   2. “분석 요청”과 “생성 요청”을 추가하니 더 나아질 수 있겠다는 감각이 생겼다.
   3. 다중 라벨이 더 적절한 경우도 많다.

3. 모델링 편향은 DDD에서 익숙한 문제다

   1. 내가 직접 만든 예시는 당연히 내가 만든 분류 체계에 잘 맞는다.
   2. 실제 사용자 입력은 모델러의 기존 범주를 깨뜨린다.
   3. DDD 커뮤니티는 이런 “기존 모델이 시나리오 선택까지 오염시키는 문제”를 오래 다뤄왔다.

4.5. LLM 분류기의 kryptonite: prompt-looking input

1. 프롬프트처럼 생긴 입력은 분류기를 교란한다

   1. “You are a text completion model…”처럼 instruction prompt 형태의 입력을 분류시키면, 모델은 분류하라는 내 지시를 무시하고 그 입력을 수행하려 든다.
   2. “이것이 프롬프트처럼 생겼는가? yes/no로 답하라”고 해도 절반쯤은 여전히 프롬프트를 따르려 한다.

2. 이유는 instruction tuning에 있다

   1. 우리가 쓰는 대부분의 모델은 “입력을 지시로 해석하고 수행하라”는 방향으로 이미 튜닝되어 있다.
   2. 그래서 입력 자체가 지시처럼 생기면, 그 지시를 분석 대상으로 보기보다 실행 대상으로 보는 경향이 강하다.

3. 흥미로운 가설

   1. 오히려 instruction-tuned 대형 모델보다, DistilBERT 같은 작은 분류 모델을 “프롬프트인지 아닌지” 판별하도록 학습시키면 더 안정적일 수 있다.
   2. 이것은 아직 검증되지 않은 가설이지만, 직접 실험할 가치가 있다.

---

5. DDD 개념으로 다시 생각하는 LLM 시스템

5.1. Training set은 concrete scenario와 닮았다

1. DDD에서 시나리오는 모델을 밀어붙인다

   1. 실제 업무 상황, 예외, 경계 사례를 들고 와서 모델이 버티는지 본다.
   2. 모델이 깨지면 언어와 개념을 다시 조정한다.

2. ML에서 training/validation set도 비슷한 역할을 한다

   1. “이 입력이면 이 출력이어야 한다”는 구체 사례가 모델을 만든다.
   2. validation set은 모델을 계속 되돌려 잡는다.
   3. 둘은 같지는 않지만, 모델을 구체 사례로 밀어붙인다는 점에서 이상한 평행성이 있다.

5.2. Ubiquitous language와 Large Language Model

1. 표면적 유사성일 수도 있지만 무시하기 어렵다

   1. DDD의 핵심 단어는 language와 model이다.
   2. LLM도 language와 model을 이름에 달고 있다.
   3. 이것이 단순한 우연인지, 더 깊은 접점인지 아직 모른다.

2. 프롬프트는 자연어에서 점점 구조화된 언어로 갈 수 있다

   1. 지금은 자연스러운 영어 프롬프트로 시작하지만, 실무에서는 점점 인공적이고 구조화된 프롬프트 언어가 중요해질 수 있다.
   2. 그것은 프로젝트 안의 ubiquitous language와 닮은 형태가 될 수도 있다.

3. 도메인 데이터도 모델의 표현 방식에 맞춰 넣어야 할 수 있다

   1. 아무 데이터나 프롬프트에 넣는 것이 아니라, 시스템의 도메인 모델이 그 데이터를 표현하는 방식으로 구조화해 넣어야 한다.
   2. 그래야 LLM의 출력이 덜 모호하고 시스템과 더 잘 맞는다.

5.3. Bounded Context는 LLM 시대에도 더 중요해질 수 있다

1. 하나의 거대한 모델로 모든 일을 하는 것은 좋은 소프트웨어 설계와 닮지 않았다

   1. 우리는 이미 한 모델·한 언어·한 컴포넌트로 모든 시스템을 만들지 않는다.
   2. 각 목적에 맞는 경계와 모델을 둔다.

2. LLM 자체도 하나의 context처럼 볼 수 있다

   1. GPT-3.5와 GPT-4는 다른 모델이다.
   2. fine-tuned DistilBERT와 base DistilBERT도 다른 모델이다.
   3. 각 모델은 객체 모델이 아니라 neural network의 weights로 표현된 세계관을 가진다.

3. LLM 기반 시스템에는 여러 종류의 경계가 필요하다

   1. 어떤 prompt language를 쓰는가.
   2. 어떤 base model을 쓰는가.
   3. 어떤 fine-tuning을 했는가.
   4. 어떤 structured input/output 계약을 갖는가.
   5. 어떤 bounded context 안에서만 그 모델의 판단을 신뢰할 것인가.

5.4. Hallucination 문제와 “정밀한 언어”의 가능성

1. 일반 자연어는 본질적으로 모호하다

   1. 자연어의 유연함은 장점이지만, 정확한 시스템 동작에는 위험할 수 있다.
   2. 때로는 순수 수학과 자연어 사이에 있는 반人工 언어가 필요하다.

2. 프로젝트별 언어로 모델을 fine-tuning할 수 있을까

   1. 특정 도메인의 ubiquitous language와 구조를 모델이 더 잘 따르도록 훈련할 수 있을지 궁금하다.
   2. 이것이 가능하다면, hallucination을 줄이고 모델의 예측 가능성을 높일 수 있다.

---

6. 결론 — 지금 해야 할 일

6.1. DDD와 LLM은 좋은 조합일 수 있다

1. LLM은 전통적 모델이 잘 담지 못하던 중간 영역을 처리할 수 있다

   1. 완전히 사람에게 맡기는 영역과 완전히 코드로 처리하는 영역 사이에 애매한 케이스가 있다.
   2. 그 중간을 LLM이 맡을 수 있다.
   3. 단, “ChatGPT에게 전부 맡기기”가 아니라 프롬프트, fine-tuned model, 전통적 코드가 섞인 구조가 필요하다.

2. Bounded Context는 손으로 코드를 쓰느냐, neural network를 쓰느냐보다 더 근본적일 수 있다

   1. 모델의 경계, 언어의 경계, 책임의 경계를 정하는 일은 여전히 중요하다.
   2. 어쩌면 LLM 시대에는 그 중요성이 더 커진다.

6.2. DDD도 바뀔 준비를 해야 한다

1. LLM을 수용하려면 DDD 관행도 조금 변할 수 있다

   1. 기존의 객체 모델·도메인 서비스·bounded context만으로는 부족할 수 있다.
   2. model weights, prompt language, fine-tuning dataset, validation set 같은 새 산출물을 설계 대상으로 봐야 할 수 있다.

2. 반대로 LLM과 잘 맞는 접근이 DDD와 다를 가능성도 열어둬야 한다

   1. DDD가 모든 것의 정답이라고 가정하면 안 된다.
   2. 실험 결과에 맞춰 접근을 조정해야 한다.

6.3. 준비 방법: 배우고, 손을 더럽히고, 공유한다

1. 직접 실험해야 감각이 생긴다

   1. 해적 선장 게임처럼 유치한 프로젝트여도 좋다.
   2. intent classifier처럼 이미 더 좋은 솔루션이 있는 문제여도 좋다.
   3. 중요한 것은 직접 써보며 무엇이 쉽고, 무엇이 어렵고, 어디서 무너지는지 몸으로 아는 것이다.

2. 커뮤니티에 경험 보고를 돌려줘야 한다

   1. 각자 혼자 배우면 지식이 흩어진다.
   2. Explore DDD 2025 같은 자리에서 “우리는 LLM을 이런 프로젝트에 넣었고, 이렇게 됐다”는 경험 보고가 쌓여야 한다.
   3. 그래야 “LLM 컴포넌트가 들어간 DDD는 어떤 모습인가?”를 집단적으로 배울 수 있다.

3. 너무 빨리 결론 잡지 않는 능력이 필요하다

   1. 초기 웹처럼 지금 배우는 도구 중 상당수는 6개월~1년 뒤 사라질 수 있다.
   2. 그래도 기다리기만 하면 안 된다.
   3. 도메인 모델링에서도 그렇듯, 첫 번째 그럴듯한 답에 매달리지 말고 “아직 모른다”는 상태를 견디며 더 많은 사례를 모아야 한다.

---

주요 발언 모음

“You don't have to predict the future to plan for it.”

“Even the technology that we have now is really revolutionary once we learn to use it well. But we don't know how to use it well.”

“If this new world is formed by the people inside of OpenAI, it's going to be very different than if there are hundreds of thousands of other people trying hundreds of thousands of other things.”

“The subtitle of Domain-Driven Design is tackling complexity in the heart of software.”

“An LLM, when it's trained on a corpus of documents, is very much an approach to tackling complexity in that domain.”

“Most non-trivial problems seem to need different prompts to do specialized things.”

“We try to move the things we want to control out of the LLM into conventional logic.”

“A classifier cannot be better than the classifications.”

“The more I worked with it, the less magical it was. And that's a good thing because it starts to be a tool.”

“Bounded context is going to be phenomenal.”

“Get your hands dirty.”

---

핵심 데이터 & 수치

• 발표 시점: 2024-03-14 Explore DDD 2024 키노트 기준의 가설.
• 영상 업로드: 2024-03-21, Explore DDD 채널.
• 길이: 1시간 21분 30초.
• 게임 실험 구조: guardrail prompt, stress prompt, dialogue prompt, success-detection prompt 등 총 4개 프롬프트 오케스트레이션.
• fine-tuning 대상 모델: DistilBERT, 약 6,600만 parameters.
• 결과: 작은 모델이 teacher LLM의 라벨을 약 80% 수준으로 모방.
• 주요 기술 키워드: prompt engineering, structured output, JSON, RAG와의 차이, LoRA, parameter-efficient fine-tuning, Hugging Face, instruction tuning, bounded context.

---

Tony / Todait 적용 메모

1. Todait의 Study Runtime도 “LLM에게 전부 맡기기”보다 상태·규칙·언어·판단을 분리해야 한다

   1. 계획 이탈, 부분 완료, 재배치, 복구는 전통적 로직과 상태 머신이 잡아야 한다.
   2. LLM은 학습자 발화 해석, 의도 분류, 복구 문구 생성, 애매한 원인 분석 같은 “언어적 중간 영역”에 쓰는 편이 맞다.

2. Bounded Context 관점으로 AI 기능을 나누면 제품 안정성이 올라간다

   1. “오늘 계획 생성 모델”, “이탈 원인 분류 모델”, “복구 액션 추천 모델”, “학습 피드백 생성 모델”은 같은 모델 호출이어도 context가 다르다.
   2. 각 context마다 입력 스키마, 출력 스키마, 금지 행동, validation set을 별도로 두는 것이 좋다.

3. 유비쿼터스 언어를 prompt language로 재사용할 수 있다

   1. Todait의 핵심 언어인 StudyState, Transaction, Solver, Memory, Recovery, Proof-of-Done 등을 프롬프트의 장식어가 아니라 구조화된 계약으로 써야 한다.
   2. 이 언어가 흔들리면 LLM 출력도 흔들린다. 반대로 언어가 안정되면 AI 기능도 제품 모델과 붙는다.

4. 가장 좋은 다음 실험은 작은 의도 분류기/규칙+LLM 하이브리드다

   1. 사용자의 입력을 “계획 수정”, “부분 완료”, “완료 증거”, “회피/불안”, “자료 추가”, “재배치 요청” 등으로 분류하는 실험이 적합하다.
   2. 처음부터 fine-tuning하지 말고, structured prompt + test set으로 시작한 뒤 실제 로그 기반 라벨링으로 넘어가는 편이 현실적이다.

---

결론 및 시사점

1. LLM은 DDD의 적이 아니라, DDD가 다루던 “복잡성·언어·모델·경계” 문제를 새 방식으로 다시 열어젖히는 기술이다.
2. 성공적인 LLM 시스템은 거대한 챗봇 하나가 아니라, 전통적 코드·상태·규칙·여러 전문 프롬프트·작은 모델의 조합일 가능성이 크다.
3. 관심사의 분리, bounded context, ubiquitous language 같은 설계 원칙은 LLM 시대에도 낡지 않았다. 오히려 더 필요해질 수 있다.
4. fine-tuning과 분류 실험에서 드러난 핵심은 “모델은 분류 체계보다 나을 수 없다”는 점이다. AI 문제도 결국 모델링 문제다.
5. 지금 필요한 태도는 미래 예측이 아니라 실험이다. 손을 더럽히고, 실패하고, 커뮤니티와 경험을 공유해야 한다.
6. DDD 커뮤니티가 이 대화에 들어오지 않으면, LLM 시스템은 도메인 경계와 언어에 덜 민감한 방식으로 발전할 수 있다. 그건 좀 아깝다, Sir.

---

Telegram 20줄 요약

1. LLM은 DDD를 대체하는 마법이 아니라 복잡성을 다루는 새 모델링 도구 후보다. Eric Evans는 미래 예측보다 직접 실험하며 준비하는 태도가 중요하다고 본다.

2. 극단적 AI 종말론이나 완전한 거품론은 실무 의사결정에 별 도움이 되지 않는다. 우리가 선택할 수 있는 행동은 지금 기술을 배우고 써보는 것이다.
3. 현재 수준의 LLM만으로도 충분히 혁명적일 수 있다. 다음 모델이 실망스럽더라도 지금 있는 기술을 잘 쓰는 법 자체가 큰 과제다.
4. DDD의 핵심 목표는 소프트웨어 심장부의 복잡성을 다루는 것이다. LLM도 말뭉치에서 도메인 복잡성을 압축한다는 점에서 다른 방식의 복잡성 처리 도구다.
5. ChatGPT식 챗봇은 LLM의 첫 대중적 형태일 뿐이다. 더 중요한 가능성은 기업 시스템 내부의 해석기, 분류기, 생성기, 판단 보조 컴포넌트다.
6. 해적 선장 게임 실험은 단일 프롬프트의 한계를 보여준다. 역할극, 세계관, 규칙, 상태, 출력 형식을 한 번에 맡기면 모델은 금방 새어 나간다.
7. 좋은 LLM 설계는 여러 전문 프롬프트와 전통적 코드를 조합한다. 세계관 위반 검사, 스트레스 평가, 대화 생성, 승리 판정을 각각 나누는 식이다.
8. 통제해야 하는 것은 LLM 밖으로 빼야 한다. 비밀 정보, 게임 상태, threshold, 승리 조건은 코드가 관리하고 LLM은 언어와 뉘앙스를 맡는다.
9. 구조화된 출력은 실무 통합의 핵심이다. true/false나 JSON처럼 프로그램이 읽을 수 있는 계약이 자유 대화보다 안정적이다.
10. GPT-4 같은 큰 모델은 모든 일에 쓰기엔 느리고 비싼 큰 망치다. 작은 모델을 특정 작업에 fine-tuning하면 비용과 지연시간을 줄일 수 있다.
11. DistilBERT 의도 분류기 실험은 작은 모델의 가능성과 한계를 함께 보여준다. 약 6,600만 parameter 모델이 teacher LLM 라벨을 약 80% 모방했다.
12. 분류기는 분류 체계보다 나아질 수 없다. 실제 사용자 입력은 “정보 요청”, “행동 요청” 같은 단순 범주를 쉽게 깨뜨린다.
13. 이 문제는 DDD의 모델링 편향 문제와 같다. 모델러가 만든 예시는 기존 모델에 잘 맞지만, 현실의 시나리오는 모델을 흔든다.
14. 프롬프트처럼 생긴 입력은 instruction-tuned 모델의 약점이다. 모델은 그것을 분석 대상으로 보기보다 지시로 수행하려는 경향이 있다.
15. Training set은 DDD의 concrete scenario와 닮았다. 구체 사례가 모델을 만들고, validation이 모델을 되돌려 잡는다.
16. Ubiquitous language와 prompt language는 연결될 수 있다. 실무 프롬프트는 자연어에서 점점 프로젝트 고유의 구조화된 언어로 진화할 수 있다.
17. Bounded Context는 LLM 시대에 더 중요해질 수 있다. 하나의 거대한 모델로 모든 일을 처리하는 방식은 좋은 소프트웨어 설계와 닮지 않았다.
18. LLM 자체도 하나의 context처럼 볼 수 있다. base model, fine-tuning, prompt language, output contract가 모두 경계와 책임을 만든다.
19. 지금 배운 도구 중 많은 것은 6개월 뒤 사라질 수 있지만 기다리기만 하는 것은 더 위험하다. 초기 웹처럼 직접 겪어야 감각이 남는다.
20. DDD 커뮤니티는 LLM 실험을 공유해야 한다. 그래야 “LLM 컴포넌트가 들어간 DDD”가 어떤 모습인지 집단적으로 배울 수 있다.