AI가 코드를 쓸수록 도메인 주도 설계가 더 중요해지는 이유

• AI가 언어와 프레임워크의 구현 세부를 빠르게 처리해도,
  어떤 문제를 어떤 방식으로 해결해야 하는지 이해하고 모델링하는 일은 여전히 사람이 맡아야 함
• 도메인 모델의 가치는 완성된 문서나 다이어그램이 아니라 개발자와 도메인 전문가가 함께 탐색하며
  사업에 대한 공통의 이해를 만드는 과정에 있음
• 에이전트가 큰 기능을 한 번에 생성하기 전에 팀이 도메인 동작과 기술 설계를 논의하면, 거대한 PR에서 뒤늦게 방향을 논쟁하는 일을 줄일 수 있음
• 코드와 문서, 대화에서 같은 용어를 사용하고 영역별 경계를 명확히 하면 에이전트에 더 정확한 맥락을 제공하고, 비슷해 보이는 개념을 잘못 합치는 문제를 막을 수 있음
• 개발자는 단순한 코드 작성자가 아니라 도메인을 이해하고 결과에 책임지는 전문가가 되어야 하며, AI에 구현은 맡길 수 있어도
  문제를 이해하기 위한 사고까지 전부 위임해서는 안 됨

구현이 쉬워져도 도메인 문제는 그대로 남음

• Domain-Driven Design은 특정 코드 구조나 디자인 패턴보다, 복잡한 사업 영역을 이해하고 소프트웨어 안에 정확하게 표현하는 접근

• 2003년 Eric Evans가 지적한 핵심은 기술적인 프레임워크보다 해결하려는 도메인의 복잡성이 소프트웨어 개발에서 더 어려운 부분이라는 것

• AI 코딩 도구를 사용하면 익숙하지 않은 언어와 프레임워크에서도 비교적 빠르게 동작하는 코드를 만들 수 있음

• 하지만 다음 질문은 모델 성능만으로 해결되지 않음

• 실제로 해결해야 하는 문제가 무엇인가

• 사용자는 어떤 결과를 기대하는가

• 사업 규칙과 예외는 어떻게 동작하는가

• 여러 요구사항 가운데 무엇을 먼저 만들 것인가

• 과거에는 새로운 프레임워크와 마이크로서비스가 도메인 문제를 해결해줄 것처럼 기대했다면, 지금은 모델 벤치마크와 에이전트 설정에 같은 기대를 걸기 쉬움

• 구현 도구를 개선하는 것과 무엇을 구현할지 이해하는 것은 별개의 문제

복잡하고 오래 유지되는 프로젝트를 위한 주장

• DDD는 모든 프로젝트에 적용해야 하는 기본 규칙이 아님
• 개인 프로젝트와 단순 CRUD, 짧게 사용하고 버릴 도구에는 고급 도메인 모델링과 여러 패턴이 불필요할 수 있음
• 여러 팀이 수개월에서 수년간 유지하고 사업 규칙이 계속 변하는 복잡한 시스템에서 가치가 커짐
• 이런 프로젝트에서는 초기 구현 속도보다 팀이 문제를 같은 방식으로 이해하고 변경을 안전하게 이어가는 능력이 중요함
• AI로 코드를 더 빨리 생성할수록 잘못 이해한 요구사항도 더 큰 범위로 빠르게 구현될 수 있어, 복잡한 프로젝트에서는 도메인 이해의 중요성이 오히려 높아짐

도메인 모델은 AI가 만든 문서가 아님

• 도메인 모델은 현실의 사업이 어떻게 동작하는지를 유용한 수준으로 단순화한 추상적인 개념

• 코드와 문서, 다이어그램은 모델 자체가 아니라 이를 표현하는 여러 방법

• 정확한 모델은 설계와 구현을 오가며 새로 배운 내용을 반복적으로 반영하는 과정에서 만들어짐

• DDD는 이러한 과정을 지식 압축(knowledge crunching)이라고 부름

• 사업을 아는 도메인 전문가와 소프트웨어를 만드는 개발자가 함께 다음을 탐색함

• 현재 업무가 실제로 어떻게 진행되는가

• 예외와 충돌은 어디에서 생기는가

• 소프트웨어가 어떤 동작을 지원해야 하는가

• 현실을 어떤 개념과 경계로 표현할 것인가

• Event Storming처럼 개발자와 이해관계자가 사건과 업무 흐름을 함께 펼쳐보는 워크숍도 이를 위한 방법

AI가 모델 문서를 대신 작성할 때 생기는 착각

• 에이전트는 회사 문서와 채팅, 기존 코드를 읽고 그럴듯한 도메인 설명과 설계 문서를 빠르게 만들 수 있음

• 하지만 아무도 읽지 않고 이해하지 않은 긴 문서는 팀의 도메인 모델이 되지 못함

• 모델링 과정의 핵심 결과는 산출물보다 팀 구성원의 머릿속에 생긴 공통 이해

• 소프트웨어 프로젝트가 실패하는 흔한 이유도 문서가 부족해서만은 아님

• 엔지니어가 잘못된 문제를 구현함

• 누구도 무엇을 만들어야 하는지 명확히 모름

• 범위가 계속 커져 모든 것을 한꺼번에 만들려 함

• AI가 완전한 제품 명세를 생성해도 요청한 사람과 구현할 팀이 내용을 이해하지 못하면 생산에 사용할 준비가 된 계획이 아님

• 누가 코드를 작성하든 무엇을 만들고 있는지 팀이 모르는 상태에서는 빠른 구현의 가치가 작음

개발자와 도메인 전문가가 함께 해결책 찾기

• 도메인 전문가는 현재 업무와 문제를 잘 알지만 완성된 해결책까지 알고 있는 것은 아닐 수 있음
• 개발자가 요구사항이 완성될 때까지 기다리고 코딩만 담당하면, 기술적 가능성과 제약이 해결책을 만드는 과정에 반영되지 못함
• 반대로 비기술 관리자가 전체 해결책을 혼자 설계해 구현 명세로 넘기면 실제 시스템에서 필요한 세부 사항을 놓치기 쉬움
• 두 집단이 함께 모델을 만들면 문제와 해결책을 동시에 탐색할 수 있음
• 개발자는 기술적 가능성과 구조를 제시하고, 도메인 전문가는 사업 규칙과 예외를 설명함
• 구현 도중 예상하지 못한 상황이 생기면 이미 공통 모델을 만든 사람들이 함께 다음 결정을 내릴 수 있음
• AI 코딩을 많이 사용하더라도 에이전트를 이끌려면 개발자가 동료에게 설명할 때처럼 도메인을 깊이 이해해야 함

코드를 생성하기 전에 설계하기

• 코드는 읽는 것보다 작성하기 쉬웠고, 에이전트가 큰 기능을 한 번에 생성하면서 그 차이가 더 커짐

• 기능이 실제로 동작해도 팀은 내부 구조와 설계 결정을 알지 못할 수 있음

• 이는 혼자 전체 기능을 만든 뒤 거대한 PR을 던지는 개발자와 비슷한 문제를 만듦

• 리뷰어는 코드 검토와 동시에 요구사항, 설계와 빠진 예외까지 처음부터 파악해야 함

• PR 댓글에서 비동기적으로 설계를 논의하면 여러 차례의 수정과 재검토가 필요해짐

• 구현 전에 팀이 짧게라도 다음 내용을 논의하는 편이 전체 시간을 줄일 수 있음

• 해결하려는 도메인 문제와 예상 동작

• 주요 개념과 경계

• 기술적 접근과 위험

• 작업을 나눌 수 있는 작은 변경 단위

• 모든 세부 사항을 문서화할 필요는 없으며, 화이트보드와 메모로 고수준 계획을 공유하는 것으로 충분할 수 있음

• 코드 리뷰는 접근 방식 자체를 처음 논의하는 장소가 아니라,
  합의한 설계가 올바르게 구현됐는지 재확인하는 단계가 되어야 함

설계가 에이전트의 출력도 개선함

• 에이전트에 “기능을 만들어달라”고만 요청하면 빈 부분을 스스로 추정해 크고 검토하기 어려운 변경을 만들 수 있음
• 팀이 도메인과 기술 설계를 먼저 정리하면 더 정확한 맥락과 작은 작업 단위를 제공할 수 있음
• 에이전트는 탐색과 추측에 쓰는 시간을 줄이고 합의된 방향으로 구현함
• 팀도 결과가 어떤 모습이어야 하는지 알고 있어 코드가 설계를 따르는지 판단하기 쉬움
• 설계 시간을 생략해 얻은 몇 시간보다, 잘못된 구현을 읽고 논쟁하고 다시 만드는 시간이 더 클 수 있음
• AI 시대의 사전 설계는 에이전트를 느리게 만드는 절차가 아니라, 생성과 검토의 반복을 줄이는 방법

잘못된 목표를 정확히 최적화한 사례

• 클라우드 비용을 줄이기 위해 Go 서비스의 메모리 사용량을 찾아 낮추라고 에이전트에 요청함
• 에이전트는 여러 차례 작업해 메모리 사용량을 수십 MB 줄이는 데 성공함
• 그러나 메모리 비용이 매우 낮아 실제 절감액은 월 1달러에 불과했음
• 요청한 목표는 메모리 감소였지만 실제 사업 목적은 클라우드 비용 절감이었음
• 에이전트는 주어진 측정값을 올바르게 최적화했지만, 사용자가 설명하지 않은 상위 목적까지 알아서 선택하지 못함
• 사람 사이에서도 용어와 목적을 잘못 전달하면 같은 문제가 생기며, 에이전트는 이를 더 빠르게 실행할 뿐
• 좋은 프롬프트는 기술 작업뿐 아니라
  왜 그 작업을 하는지와 무엇이 실제 성공인지를 포함해야 함

보편 언어로 사람과 에이전트의 의미 맞추기

• 보편 언어(Ubiquitous Language)는 도메인 전문가와 개발자, 코드와 문서가 같은 개념을 같은 이름으로 부르는 원칙
• 많은 조직에서는 코드의 기술 용어와 실제 사업에서 사용하는 표현이 서로 달라짐
• 에이전트에 문서와 의사결정 기록을 제공해도 용어가 일관되지 않으면 같은 개념과 다른 개념을 구분하기 어려움
• 지식 압축 과정에서 여러 이름이 섞인 개념을 확인하고 가장 정확한 이름을 선택함
• 선택한 이름은 회의와 문서, 코드, 이벤트와 API에서 일관되게 사용함
• 언어는 도메인과 제품이 변하면서 함께 발전하므로 한 번 정하고 끝나는 작업이 아님
• 정확한 도메인 용어는 사람 사이의 오해를 줄이는 동시에 에이전트 프롬프트의 모호함도 줄임

하나의 개념도 영역에 따라 다른 이름을 가짐

• 큰 시스템에서는 하나의 보편 언어를 모든 영역에 강제로 적용하기 어려움

• DDD는 같은 의미 체계를 공유하는 범위를 경계가 있는 맥락(Bounded Context)으로 나눔

• 같은 사람도 시스템마다 다른 개념으로 표현될 수 있음

• 전자상거래에서는
  User

• CRM에서는
  Customer

• 고객지원에서는
  Profile

• 회계에서는
  Account

• 각 영역 안에서는 용어를 일관되게 사용하되, 서로 다른 영역의 모델을 하나로 합치지 않음

• 에이전트는 저장소 전체에서 비슷한 이름과 필드를 찾으면 중복으로 판단해 하나의 공통 모델로 통합하려 할 수 있음

• 서로 다른 개념이 의도적으로 분리돼 있다는 맥락을 문서와 코드 구조에 명확히 남겨야 함

• 경계가 분명하면 팀을 나누고 시스템 간 결합을 낮추기도 쉬워짐

모호한 프롬프트를 도메인 언어로 바꾸기

• “사용자가 생성되면 CRM과 고객지원에 추가”라는 요청은 어떤 사용자를 어떤 방식으로 추가해야 하는지 불분명함

• 도메인과 맥락의 정확한 이름을 사용하면 다음처럼 구체화할 수 있음

• 웹사이트에서 사용자가 가입하면 CRM에 고객 항목을 비동기로 생성함

• 고객지원 시스템에는 별도의 프로필을 비동기로 생성함

• 두 시스템의 객체가 같은 사람을 나타내더라도 독립적인 모델이라는 점이 드러남

• 이런 용어와 경계는 에이전트의 컨텍스트에 포함되어야 함

• 코드 가까이에 최신 Markdown 문서를 두는 방식은 별도 검색 시스템 없이도 에이전트가 도메인 언어를 읽게 하는 간단한 출발점

개발자는 코더보다 도메인 전문가에 가까워짐

• 모델과 에이전트가 좋아져도 결과에 오류가 없는지 완전히 신뢰할 수는 없으며 최종 책임을 질 사람이 필요함
• 시스템을 설계하고 도메인에서 오래 일한 개발자는 어떤 결과가 이상하고 어디서 문제가 생길지 판단할 수 있음
• 복잡한 사업 영역도 지속적으로 다루면 규칙과 예외가 직관적으로 느껴질 만큼 익숙해짐
• 이러한 지식을 가진 개발자는 매우 상세한 지시가 없어도 문제를 찾아 해결책 논의에 참여할 수 있음
• AI로 유명 앱의 단순한 복제품을 만드는 것보다, 도메인을 잘 아는 팀이 비싼 외부 소프트웨어를 내부 요구에 맞게 대체하는 사례가 더 의미 있음
• 성공 가능성은 코드를 빨리 생성해서가 아니라 기존 업무와 예외, 필요한 맞춤 기능을 아는 사람들이 에이전트를 이끌기 때문에 높아짐
• 기업에는 특정 프레임워크 전문가보다 사업 문제를 이해하고 제품 결정을 내릴 수 있는 엔지니어의 가치가 커짐
• 개발자에게도 기술 하나를 깊게 파는 것과 함께 새로운 도메인을 배우고 사업 문제를 해결하는 능력이 중요해짐

사고까지 에이전트에 위임하지 않기

• 복잡한 문제를 오래 생각하고 직접 모델을 만드는 경험이 있어야 에이전트의 답이 타당한지 판단할 수 있음
• AI가 설명과 계획을 대신 만들어주더라도 이를 읽고 판단할 정신 모델이 없다면 잘못된 결과를 알아보기 어려움
• 책 전체를 읽는 경험과 짧은 요약만 읽는 경험의 차이에 비유함
• 책을 읽는 동안 오랜 시간 주제를 생각하고 기존 지식과 연결하면서 복잡한 이해를 구축함
• 요약은 빠르게 핵심을 전달하지만 읽은 직후 잊기 쉽고 스스로 문제를 다룰 깊은 모델을 만들기 어려움
• 사고 능력도 반복적으로 사용해야 발전하며, 복잡한 문제를 모두 에이전트에 넘기면 앞으로의 판단 기반을 쌓지 못할 수 있음
• AI를 사용하지 말자는 주장이 아니라 구현과 조사에는 적극 활용하되,
  문제 이해와 모델 형성에는 사람이 직접 참여해야 한다는 것

DDD가 제공하는 AI 코딩의 기준

• 도메인 전문가와 개발자가 함께 문제를 이해함
• 코드를 생성하기 전에 고수준 설계와 경계를 합의함
• 문서와 코드, 프롬프트에서 일관된 도메인 언어를 사용함
• 경계가 있는 맥락을 명시해 에이전트가 별개 모델을 무리하게 통합하지 못하게 함
• 개발자가 도메인 지식을 쌓아 에이전트 결과의 정확성과 위험을 판단함
• AI가 만든 문서와 코드를 결과물로 받아들이기 전에 팀이 실제로 이해하고 검토함
• DDD의 전술적 패턴을 그대로 적용하는 것보다,
  도메인을 이해하고 함께 모델링한다는 철학이 AI 코딩 시대에 더 중요하다는 주장

댓글과 토론