2018년, 메신저 기반 고객 상담이 아직 일반적이지 않던 시기에 한 상담 서비스의 초기 기술 설계와 개발을 이끌었다. 이후 여러 연관 서비스를 개발하고 운영했다.
2020년에 DDD를 알게 됐다. 복잡한 업무 규칙과 서비스 간 경계를 정리하는 데 도움이 될 것 같아 깊이 공부했다. 이 글은 이후 DDD를 조직에 적용했던 과정과 한계, 그리고 AI 시대에 다시 시도하고 있는 방법에 대한 회고다.
DDD가 잘 진행되는 것처럼 보였던 시간
코드 안에 도메인의 언어를 담으려 했다. 비즈니스 로직을 단순한 데이터 처리와 분리하고, 객체에 책임을 부여하며, 계층과 의존성을 정리하려 했다.
2022년부터는 내가 맡아 운영하던 조직에 DDD를 본격적으로 전파하고 교육하기 시작했다. 특히 기획자들의 반응이 좋았다. 개발 용어로만 보였던 DDD가 실제로는 업무의 언어와 규칙, 예외와 책임을 함께 이야기하는 방법이라는 점에 공감했다.
몇 년 동안은 잘 진행되는 것처럼 보였다. 회의에서 같은 용어를 사용하려 했고, 기능을 논의할 때 업무 경계와 모델을 먼저 살펴보려 했다. 좋은 모델과 일관된 코드 규칙이 쌓이면 조직의 개발 방식도 달라질 수 있다고 생각했다.
하지만 KPI 달성 압박과 프로젝트 일정이 앞에 놓이면 모델링과 교육은 우선순위에서 밀렸다. 도메인 언어와 예외를 함께 검토하는 시간은 부가적인 활동이 됐고, 별도의 직무와 책임으로 정의되지 않은 도메인 전문가 역할은 점차 흐려졌다.
이 문제는 누군가 DDD를 충분히 공부하지 않았기 때문만은 아니었다. 한 명의 개발자나 한 번의 교육만으로는 다음 질문에 계속 답할 수 없었다.
- 어떤 업무 책임을 하나의 경계로 묶을 것인가?
- 서로 충돌하는 현업의 규칙 중 무엇을 기준으로 삼을 것인가?
- 데이터와 업무 판단의 최종 소유자는 누구인가?
- 하나의 기능이 여러 부서에 걸칠 때 누가 결정을 내릴 것인가?
- 그 경계를 어느 팀이 장기간 책임질 것인가?
나는 교육을 시작하고 모델링을 제안할 수는 있었지만, 이 역할과 시간을 KPI와 프로젝트 일정 속에서도 지속되는 운영 구조로 만들지는 못했다. 지금 돌아보면 DDD 지식의 문제가 아니라 역할, 우선순위와 비용의 문제였다.
도메인 전문가는 필요했지만 현실에는 그 직군이 없었다
에릭 에반스의 『도메인 주도 설계』를 다시 읽으며 가장 크게 다가온 역할은 Domain Expert였다.
도메인 전문가는 요구사항을 정리해 개발자에게 넘겨주는 사람이 아니다. 특정 업무 영역에서 실제 판단의 의미와 규칙, 예외, 우선순위를 알고 있는 사람이다. 그리고 개발자와 함께 공통 언어를 만들고, 시나리오와 동작하는 소프트웨어를 통해 그 모델을 계속 수정하는 공동 모델러다.
책에서는 도메인 전문가도 완성된 정답을 가진 사람으로 묘사되지 않는다. 개발자가 질문하고 프로토타입을 보여주면 전문가 역시 자신의 설명에 있던 모호함과 모순을 발견한다. 개발자와 전문가는 서로에게 배우며 모델을 만든다.
그러나 현실의 조직에서는 이런 역할이 좀처럼 공식화되지 않았다. Domain Expert라는 직군이 따로 있는 것도 아니었다.
현업 전문가는 운영, 매출, 정산, 심사 같은 본래 업무로 평가받는다. 개발자와 용어를 정리하고 예외 시나리오를 검토하는 시간은 정식 업무라기보다 회의 비용처럼 취급된다. 개발팀은 기획서나 티켓을 통해 요구사항을 전달받고, 현업과 개발자 사이에는 여러 전달 계층이 생긴다.
업무 지식은 여러 사람에게 흩어져 있었고, 누구도 도메인 모델을 지속해서 관리할 책임과 시간을 부여받지 못했다. 그 결과 도메인 전문가는 이름 없는 역할이 됐고, 개발자는 업무의 의미를 충분히 알지 못한 채 시스템의 구조를 결정하게 됐다.
DDD의 효과는 장기적으로 나타나지만 도메인 전문가의 시간, 반복적인 모델링 세션과 조직 간 합의 비용은 당장 발생한다. 엔지니어링 관점에서도 이 비용이 어떤 매출과 장애 감소, 변경 속도로 돌아오는지 미리 증명하기는 쉽지 않다. 현실의 조직이 DDD의 용어와 일부 패턴은 받아들이면서도 이 운영 구조까지 정착시키지 못한 이유라고 생각한다.
그래서 내가 경험한 방식의 DDD 도입은 결국 한 차례 실패했다고 본다. 방법론의 내용이 틀려서가 아니라, 그 방법론을 유지하는 데 필요한 역할과 비용을 조직 안에 만들지 못했기 때문이다.
도메인 전문가가 상시 참여해야만 유지되는 DDD라면, 도메인 전문가라는 역할이 예산과 책임 구조에 없는 조직에서는 정착하기 어렵다.
MSA가 답처럼 보이던 시절
내가 DDD를 조직에 전파하던 시기에는 MSA에 대한 관심도 빠르게 커지고 있었다. 국내외 기술 사례를 접하며 받은 인상은 DDD보다 MSA 자체가 목표나 해답처럼 이야기되고 있다는 것이었다. 내가 속한 조직도 크게 다르지 않았다.
나는 서비스부터 나누기 전에 업무의 경계를 먼저 찾아야 한다고 여러 번 이야기했다. 하지만 DDD는 주로 Entity, Repository와 계층 구조를 정리하는 코드 아키텍처 정도로 받아들여졌다. 정작 현업과 함께 언어와 규칙을 만들고 모델을 계속 수정하는 도메인 전문가의 역할은 충분히 논의되지 않았고, 실제 운영 책임으로 이어지지도 않았다.
그래서 나는 MSA를 적극적으로 적용하지 않았다. MSA를 반대해서가 아니라, 그보다 먼저 DDD를 통해 내가 운영하는 시스템의 Bounded Context를 찾고 코드의 경계를 다시 세우는 리팩터링이 필요하다고 생각했기 때문이다.
DDD에서 Bounded Context는 단순히 코드를 나누는 단위가 아니다. 특정 언어와 모델이 일관되게 의미를 갖는 경계이며, 그 안에서 업무 책임과 데이터 소유권이 분명해야 한다. 반면 Microservice는 실행과 배포의 경계다. 둘이 항상 1:1이어야 하는 것은 아니다.
내가 생각한 순서는 다음과 같았다.
- 업무의 의미와 책임 경계를 발견한다.
- 데이터와 의사결정의 소유자를 정한다.
- 코드에서 모듈과 의존성의 경계를 검증한다.
- 독립 배포나 확장, 장애 격리 같은 운영상의 이유가 생겼을 때 서비스를 분리한다.
그러나 첫 번째 단계부터 큰 비용이 필요했다. 이미 운영 중인 시스템의 경계를 다시 찾고 코드를 옮기는 일은 작은 개선이 아니라 상당한 리팩터링이었다. 하루가 다르게 발생하는 운영 이슈와 KPI, 프로젝트 일정 앞에서 이 작업은 계속 뒤로 밀렸다. 결국 나는 경계를 충분히 다시 세우지 못했고, 지금까지도 그 위에 MSA를 적용하지 못했다.
그렇게 MSA의 흐름을 한동안 지켜봤다. 시간이 지나자 “MSA는 실패했고 다시 모놀리스로 돌아가야 한다”는 글이 하나둘 보이기 시작했다. 솔직히 말하면 그때 속으로는 ‘그럴 줄 알았다’고 생각했다.
하지만 이것을 MSA 자체가 틀렸다는 뜻으로 받아들이지는 않는다. 업무 경계를 합의하기 전에 네트워크와 배포 단위부터 나누면, 기존의 결합도에 분산 시스템의 복잡성까지 더해질 가능성이 크다. 내가 경계 리팩터링을 먼저 하려 했던 이유도 여기에 있었다.
업무의 경계를 합의하지 않은 채, 네트워크와 배포 단위로 그 경계를 대신 확정해서는 안 된다.
AI는 이 문제를 해결할 수도, 훨씬 빠르게 악화시킬 수도 있다
이제 우리는 AI가 코드를 작성하는 시대에 들어왔다.
AI는 API를 만들고, 서비스를 분리하고, 이벤트와 DTO를 생성하고, 테스트와 문서를 작성할 수 있다. 문제는 AI가 합의되지 않은 경계까지 매우 빠르게 코드로 굳힐 수 있다는 점이다.
과거에는 한 팀이 잘못된 서비스 경계를 만드는 데 몇 달이 걸렸다면, AI를 활용한 팀은 같은 실수를 며칠 만에 훨씬 큰 규모로 반복할 수 있다. 이름이 비슷하다는 이유로 개념을 합치고, 테이블이 분리돼 있다는 이유로 서비스를 나누고, 현재 코드의 우연한 구조를 업무의 진실로 오해할 수도 있다.
AI가 더 많은 코드를 작성할수록 DDD가 덜 필요한 것이 아니다. 오히려 사람이 모든 코드를 직접 읽고 경계를 교정할 수 없게 되기 때문에, 도메인 모델과 책임 경계는 이전보다 더 명시적이어야 한다.
그래서 나는 오히려 AI를 새로운 도메인 전문가의 역할에 배치해야 한다고 생각한다.
여기서 역할과 최종 책임은 구분해야 한다. AI가 실제 업무 결과에 법적·조직적 책임을 질 수는 없다. 그러나 그렇다고 도메인 모델을 만들고 유지하는 일까지 계속 사람에게만 맡겨야 하는 것은 아니다.
내가 생각하는 AI Domain Expert Agent는 일반적인 코드 작성 에이전트와 다른 역할을 가진다. 업무 문서와 정책, 코드, 데이터와 변경 이력을 지속해서 읽고, Bounded Context와 Ubiquitous Language, 업무 규칙과 시나리오를 관리한다. 다른 AI 에이전트가 제안한 모델과 구현이 기존 언어와 경계를 침범하는지 검사하고, 충돌하는 의미를 발견하며, 필요한 반례와 질문을 만든다. 도메인 모델링을 수행하는 여러 AI 사이에서 일관성을 통제하는 모델링 책임자에 가깝다.
전문성은 역할 이름을 붙인다고 생기지 않는다. 어떤 근거를 읽었는지, 어떤 모델과 용어를 현재 기준으로 삼는지, 과거의 결정과 예외를 어떻게 기억하는지가 함께 고정돼야 한다. 하네스가 필요한 이유도 여기에 있다.
이미 승인된 정책과 책임 경계 안에서 발생하는 반복적이고 되돌릴 수 있는 모델 변경은 이 에이전트가 판단할 수 있어야 한다. 반면 고객 결과, 정책, 데이터 소유권, 조직 책임, 법적·보안 위험이나 되돌리기 어려운 변경처럼 중요한 결정은 사람이 맡아야 한다. 사람에게 필요한 것은 모든 모델 문장을 검수하는 일이 아니라, 실제 책임을 수반하는 판단을 이해하고 승인하는 일이다.
그래서 AI 시대에는 하네스가 필요하다
내가 생각하는 AI 하네스는 AI에게 일을 더 많이 시키는 자동화 도구가 아니다.
하네스는 AI가 무엇을 근거로 판단해야 하는지, 어떤 역할이 모델을 통제하는지, 어디까지 스스로 결정할 수 있는지, 어떤 위험에서 사람에게 판단을 넘겨야 하는지를 고정하는 통제 구조다.
DDD와 MSA의 실패를 반복하지 않으려면 적어도 다음을 붙잡아야 한다.
1. 하나의 권위 있는 도메인 모델
Bounded Context, Ubiquitous Language, 업무 규칙, 예외와 시나리오가 코드 밖에서도 명시돼 있어야 한다. 모든 AI는 작업을 시작하기 전에 영향을 받는 컨텍스트와 현재 모델을 읽어야 한다.
코드, DB 스키마와 기존 API는 중요한 증거지만 그 자체가 업무의 진실은 아니다. 오래된 구현에는 과거의 오해와 임시방편도 함께 남아 있기 때문이다.
2. AI Domain Expert Agent라는 통제 역할
코드를 작성하는 에이전트와 도메인 모델을 통제하는 에이전트는 역할이 분리돼야 한다. 구현 에이전트가 편의를 위해 용어를 바꾸거나 경계를 넓히려 할 때, AI Domain Expert Agent는 현재 모델과 근거를 기준으로 이를 거절하거나 모델 변경 절차로 돌려야 한다.
이 에이전트는 단순한 검토자가 아니다. 새로운 자료를 모델에 반영하고, 용어의 충돌을 조정하고, 시나리오와 업무 규칙을 갱신하며, 변경 영향을 다른 에이전트에게 전달하는 능동적인 모델 관리자여야 한다.
3. 위험에 비례하는 사람의 승인
모든 변경을 사람에게 승인받게 하면 검토 대기와 승인 피로가 쌓인다. 사람이 읽지 못한 채 형식적으로 누르는 승인은 통제가 아니라 또 다른 위험이다.
하네스는 사소한 모델 편집과 되돌릴 수 있는 구현 판단은 AI 역할 사이에서 처리하고, 중요한 의미 변경만 사람에게 올려야 한다. 무엇이 바뀌었는지, 왜 중요한지, 고객과 조직에 어떤 결과가 생기는지, 선택 가능한 대안은 무엇인지를 사람의 언어로 압축해야 한다.
4. 사람이 읽고 판단하는 Board
사람이 Markdown 경로, 모델 ID, 해시와 에이전트 로그 전체를 읽을 필요가 없어야 한다. Board는 도메인 경계, 정책, 열린 질문, 변경 영향, 위험과 필요한 결정을 사람이 읽을 수 있는 제목과 설명으로 보여줘야 한다.
기술 ID와 원문, revision과 실행 증거는 사라지는 것이 아니라 근거로 남는다. 다만 사람에게 먼저 보여줄 것은 기술 메타데이터가 아니라 “무엇을 결정해야 하고 그 결과가 무엇인가”여야 한다.
5. 도메인에서 코드와 테스트까지 이어지는 추적성
업무 규칙이 어떤 프로젝트와 작업을 거쳐 어떤 코드와 테스트로 구현됐는지 연결돼야 한다.
도메인 시나리오 → 업무 규칙 → 작업 → 코드 → 테스트 → 실행 증거
이 연결이 없다면 AI는 테스트를 통과시키면서도 업무 의미를 훼손할 수 있다. 빌드 성공과 도메인 정확성은 같은 것이 아니다.
6. 경계를 침범하지 못하게 하는 검증기
서비스 간 의존 방향, 데이터 소유권, 금지된 직접 참조, 공유 DB, 동기 호출 사슬과 시나리오 커버리지를 기계적으로 검사해야 한다. 사람의 좋은 의도만으로는 빠른 AI 변경을 따라가기 어렵다.
검증기는 도메인의 의미를 결정하지 않는다. 대신 이미 합의한 경계가 구현 과정에서 조용히 무너지는 것을 발견한다.
7. 위험에서만 멈추는 실행 루프
AI의 기본 실행은 계획 → 모델 확인 → 변경 → 검증 → 증거로 계속 이어져야 한다. 근거가 부족하거나 모델이 충돌하거나 승인 경계를 넘는 중요한 변경이 발생했을 때만 Board에 판단을 요청하고 멈춰야 한다.
속도만 높이는 자동화도, 매 단계마다 사람을 기다리는 자동화도 답이 아니다. 일상적인 판단은 AI가 지속하고, 잘못된 방향으로 빠르게 달릴 위험이 있을 때만 사람이 개입할 수 있어야 한다.
내가 document-harness에 옮긴 것
내가 만든 document-harness에는 지금까지의 DDD 경험에서 얻은 이 생각을 옮기고 있다.
Domain Landscape, Context Map, Bounded Context별 모델, Ubiquitous Language와 실행 가능한 시나리오를 하나의 권위 있는 도메인 모델로 두었다. 고객, 기획자, 설계자, 개발자, QA와 AI가 서로 다른 문서를 갖는 대신 같은 모델을 역할에 맞게 읽도록 했다. 용어와 Aggregate, 업무 규칙과 시나리오에는 안정적인 ID를 부여하고, 프로젝트와 작업, 코드, QA와 실행 증거까지 이어지도록 했다.
Board에서는 이 구조를 사람이 읽을 수 있는 제목과 요약으로 투영한다. 도메인 모델과 정책, 검토가 필요한 항목, 실행 상태와 근거를 분리해서 보여주고, 설명이 준비되지 않은 기술 문서를 확정된 판단처럼 노출하지 않는다.
현재의 document-harness는 안전한 출발점으로서 현재 도메인 모델의 정확한 내용에 사람의 승인을 요구한다. 그러나 내가 생각하는 최종 형태는 사람이 모든 문서의 모든 변경을 계속 승인하는 구조가 아니다. AI Domain Expert Agent가 일상적인 모델링과 다른 AI의 변경을 통제하고, 하네스는 변경의 위험을 분류해 정말 중요한 결정만 Board로 올리는 방향으로 발전해야 한다.
DDD와 AI로 PoC부터 운영까지
최근에는 사내 AI 사용 권한과 실행을 중계하는 플랫폼을 PoC부터 기획, 도메인 설계와 기술 설계, UI 디자인, 개발, QA와 운영 배포까지 직접 이끌었다. Gateway, 권한과 계정 영역을 관리하는 Control Plane, 요청 실행을 중계하는 Runtime Router, 운영 Console, 사용량과 감사 체계, 배포 인프라가 함께 움직이는 중간 규모의 사내 플랫폼이다.
이 작업에서 DDD와 AI는 분리된 수단이 아니었다. DDD는 코드 패턴이 아니라 전체 SDLC의 판단 기준이었고, AI는 업무 자료와 정책, 코드와 변경 이력을 읽으며 용어와 경계, 규칙의 일관성을 관리하는 도메인 전문가 역할을 맡았다. 사용자와 권한, 계정 영역, 요청 실행, 사용량과 운영 책임의 경계를 나누고, 기획 문서부터 구현과 테스트, 릴리스 증거까지 같은 용어와 규칙으로 연결했다. PoC로 시작한 시스템은 검증 환경을 거쳐 실제 운영 환경까지 이어졌다.
이 플랫폼만의 경험은 아니다. 여러 프로젝트에도 같은 방식을 적용했고, 지금까지 개발이 의도한 방향에서 크게 벗어난 경우는 없었다. 한계는 AI의 구현보다 내가 다음 아이디어를 충분히 구체화하지 못했거나, 작업을 이어갈 시간과 토큰이 부족할 때 나타났다.
AI가 없었다면 이 과정에서 도메인 모델을 계속 읽고 관리하는 역할은 유지되기 어려웠을 것이다. 이 경험을 통해 DDD가 좋은 모델만으로 유지되는 것이 아니라, 모델을 지속해서 관리하는 역할과 이를 작업, QA와 릴리스까지 연결하는 통제 구조가 함께 있어야 한다는 점을 확인했다. 현재의 document-harness는 이때 필요했던 구조를 반복 가능하게 만들기 위해 정리하고 있다.
사람에게 같은 비용을 다시 청구해서는 안 된다
과거 DDD가 현실에 안착하지 못한 이유 중 하나는 지속적인 도메인 모델링 비용을 사람의 시간으로만 지불해야 했기 때문이다. AI를 도입한 뒤에도 용어 하나, 시나리오 하나, 모델의 작은 변경 하나까지 다시 사람에게 검토하도록 요구한다면 같은 비용을 다른 화면으로 청구하는 셈이다.
그것은 다시 실패로 가는 길이다.
사람이 맡아야 할 것은 최종 책임이 걸린 결정이다.
- 새로운 업무 정책이나 고객 결과를 확정하는 일
- Bounded Context와 데이터 소유권, 조직 책임을 바꾸는 일
- 법적·보안·재무 위험과 예외를 수용하는 일
- 되돌리기 어렵거나 비용이 큰 선택을 승인하는 일
그 사이의 지속적인 모델링, 용어 정합성, 반례 탐색, 변경 영향 분석, 추적성 유지와 경계 검증은 AI Domain Expert Agent와 하네스가 담당해야 한다. 그래야 DDD가 요구했던 깊이를 유지하면서도 과거에 감당하지 못했던 운영 비용을 낮출 수 있다.
DDD, MSA 그리고 AI
DDD는 개발자 혼자 잘해서 성공하는 방법론이 아니었다.
MSA는 서비스를 많이 만들면 얻어지는 아키텍처가 아니었다.
AI 역시 코드를 많이 만들게 한다고 더 나은 시스템을 만들어주지는 않을 것이다.
AI Domain Expert Agent가 도메인의 언어와 책임 경계를 지속해서 관리한다. 사람은 중요한 책임과 위험만 Board에서 판단한다. 그다음 모델과 코드를 나누고, 마지막으로 프로세스와 배포를 나눈다. 하네스는 AI가 이 순서를 지키게 한다.
결국 내가 AI에 기대하는 핵심 역할은 코드 작성이 아니다. DDD가 필요로 했지만 현실에서는 지속하기 어려웠던 도메인 전문가의 역할을 맡는 것이다.
이것이 지난 실패와 최근의 경험을 거쳐 지금 내가 바라보는 방향이다.
참고
- Eric Evans, 『Domain-Driven Design: Tackling Complexity in the Heart of Software』