AI가 코드를 쓸수록 도메인 모델링이 중요해지는 이유, DDD가 아직 가르치는 것

TL;DR

• Smółka는 DDD의 핵심이 코드가 아니라 문제 영역을 이해하고 모델링하는 일이라고 보고, 구현 비용이 내려간 지금 이 부분이 더 중요해졌다고 주장한다. 어려운 것은 여전히 도메인의 복잡성이다.
• 도메인 모델은 산출물이 아니라 팀이 함께 이해에 도달하는 과정이다. AI가 만든 긴 명세서는 아무도 읽지 않는 문서가 되기 쉽다.
• 설계 논의는 코드 작성 전에 팀이 하는 편이 리뷰 비용을 줄인다. 작은 화이트보드 수준의 합의면 충분하다.
• 공통 언어와 경계 컨텍스트는 에이전트에게도 통한다. 모호한 프롬프트는 엉뚱한 목표를 최적화하며, 글의 사례에서는 메모리를 줄였지만 비용 절감은 월 1달러에 그쳤다.
• 이 주장은 수개월에서 수년 유지되는 복잡한 프로젝트를 전제로 하며, 단순한 CRUD나 토이 프로젝트에는 적용하지 않는다고 저자가 밝힌다.

바뀌지 않은 것, 어려운 부분은 도메인이다

글은 Eric Evans가 2003년에 낸 『도메인 주도 설계』의 핵심 메시지를 다시 꺼낸다. 소프트웨어 공학에서 어려운 부분은 문제 영역을 이해하고 코드로 잘 모델링하는 일이고 기술 인력은 그 일을 남에게 맡긴 채 정교한 프레임워크를 만드는 데 몰두하는 경향이 있다는 것이다. Smółka가 보기에 AI 도구는 구현 세부를 덜 중요하게 만들었다. 프로그래밍 언어나 프레임워크를 깊이 몰라도 어느 정도 생산적일 수 있고 다른 기술 스택으로 옮기기도 쉬워졌다.

그런데 지금의 유행은 Evans가 2003년에 지적한 실수를 반복한다. 프레임워크 대신 모델 벤치마크를 따라가며 에이전트 설정을 다듬고 기술로 도메인 문제를 풀려고 한다. 저자는 이번에는 경영진도 같은 방향으로 밀어붙인다고 꼬집는다. 남는 질문은 결국 “이것이 어떻게 동작해야 하는가”이고 누가 알려 주면 토큰을 쏟아 구현하면 되지만 아무도 모르면 에이전트에게 계획을 짜게 하자는 발상으로 흐른다. 글은 이 지점이 틀렸다고 본다.

도메인 모델은 산출물이 아니다

DDD의 토대는 도메인이 어떻게 돌아가는지를 코드로 표현한 모델을 만드는 모델 주도 설계다. 모델은 추상적 개념이라 문서, 다이어그램, 코드 어느 쪽으로든 표현할 수 있고 모두 단순화일 뿐이다. 정확한 모델은 설계와 구현을 오가며 배운 것을 거듭 적용해야 나온다. DDD는 이것을 지식 소화(knowledge crunching)라고 부르며 업무를 아는 도메인 전문가와 소프트웨어를 만드는 엔지니어가 함께 해야 한다. 이벤트 스토밍처럼 포스트잇으로 업무 흐름을 그리는 워크숍이 한 예다.

이 일이 힘드니 AI에게 맡기고 싶어진다. 에이전트는 조사와 분석에 뛰어나고 문서와 대화, 코드에 접근할 수 있으니 도메인 모델을 만들고 구현까지 할 것처럼 보인다. 저자는 그 순진한 접근이 요점을 놓친다고 말한다. 모델을 만드는 일의 가치는 팀이 도메인이 어떻게 돌아가는지 이해하게 되는 데 있고 AI가 쓴 긴 글은 그 이해를 주지 못한 채 아무도 읽지 않는 산출물만 남긴다.

프로젝트는 대개 다른 이유로 실패한다. 엔지니어가 잘못된 일을 하거나 무엇을 해야 하는지 아무도 모르거나 한꺼번에 다 만들려다 범위가 불어난다. 저자가 여러 번 빠진 함정도 소개한다. 개발자는 패턴과 모범 사례를 안다는 자신감에 요구만 누가 알려 주면 된다고 생각하지만 도메인 전문가도 문제는 알아도 해법은 아직 모른다. 다른 극단은 비기술 관리자가 해법을 다 짜서 넘기거나 요즘처럼 AI로 만든 명세를 읽지도 않고 전달하는 경우다. 어느 쪽이든 아무도 무엇을 하는지 모르는 상태이고 코드를 누가 얼마나 빨리 쓰든 가치가 낮다. 그래서 AI로 대부분 코딩하더라도 도메인에 깊이 익숙해져 동료를 이끌듯 에이전트를 이끌어야 한다는 것이 결론이다. 저자는 에이전트 설정이나 LLM 선택보다 해법에 대한 명확한 멘탈 모델이 더 중요하다고 본다.

코드 전에 설계하면 리뷰가 쉬워진다

코드를 쓰는 일은 읽는 일보다 늘 쉬웠고 에이전트가 큰 기능을 한 번에 만들어 주는 지금은 더 극단적이다. 동작하더라도 내부에서 무슨 일이 일어나는지 모른다. 리뷰에서 막히는 일이 늘었지만 새로운 문제는 아니다. 설계 논의 없이 완성된 기능을 거대한 PR로 던지는 독불장군 개발자와 일하는 것과 같다. 저자가 여러 프로젝트에서 효과를 본 방법은 코딩 전에 팀이 해법을 설계하고 논의하는 것이다. 먼저 도메인 부분, 그다음 기술 부분을 다룬다. 모든 세부에 합의하거나 완전한 명세를 쓸 필요는 없고 모두가 아는 상위 수준 계획이면 된다. 포스트잇과 화이트보드로 충분하다.

설계 변경의 최적기는 코드를 쓰기 전이다. 그렇게 하면 PR 리뷰가 매끄럽고 설계를 PR 댓글로 토론하지 않으니 작업을 작은 단위로 쪼개기 쉬우며 프로덕션에 올라간 뒤의 빈틈도 줄어든다. 설계를 건너뛰면 회의가 줄어 시간을 아낀다고 느끼지만 팀이 기능을 PR에서 처음 알게 되면 비동기 리뷰에서 여러 차례 댓글이 오가며 더 오래 걸린다. 코드 리뷰는 구현이 맞는지 이중 점검하는 자리여야 하고 접근법이 맞는지 토론을 시작하는 자리가 되면 안 된다. 같은 원리가 에이전트에도 적용된다. 질 높은 맥락을 더 많이 주면 출력이 정확해지고 코딩 시간이 짧아진다.

공통 언어와 경계 컨텍스트는 에이전트에게도 통한다

저자의 사례는 이렇다. 클라우드 비용을 줄이려고 에이전트에게 Go 서비스에서 메모리를 가장 많이 쓰는 곳을 찾아 줄이라고 시켰다. 몇 차례 실행하자 수 메가바이트가 줄었지만 메모리는 싸서 실제 절감액은 월 1달러였다. 에이전트에게 비용 절감이 목적이라는 말을 하지 않고 메모리 사용량만 목표로 줬기 때문이다. 사람들 사이에서 벌어지는 일과 똑같고 팀에서 소통을 돕는 관행이 AI와 일할 때도 유효하다는 얘기다.

DDD는 언어에 관한 생각으로 이를 다룬다. 첫째는 유비쿼터스 언어로, 팀과 코드가 같은 말을 쓰는 것이다. 많은 팀에서 코드의 기술 용어는 회사의 나머지가 쓰는 이름에서 멀어진다. 지식 소화 중에 개념에 붙은 이름을 점검하고 이미 쓰는 이름이나 더 정확한 이름을 골라 문서와 대화, 코드에 일관되게 쓴다. 이벤트 스토밍이 이름을 고르기에 좋은 자리이고 언어는 프로젝트와 함께 진화하므로 한 번으로 끝나지 않는다. 둘째는 경계 컨텍스트다. 고객은 지원 컨텍스트에서는 프로필이고 전자상거래 컨텍스트에서는 사용자일 수 있고 이름은 컨텍스트 안에서 일관되면 된다. 에이전트는 저장소 전체를 보며 이름을 찾기 때문에 비슷한 엔티티를 순진하게 통합하려 할 수 있다. 분리된 이유가 있음을 분명히 해야 한다.

저자가 든 프롬프트 예가 이 차이를 보여 준다. “사용자가 생성된 뒤 CRM과 지원에 추가”라는 모호한 지시보다, 사용자가 웹사이트에 가입하면 비동기로 CRM의 고객 항목과 지원 시스템의 프로필을 만들라는 정확한 지시가 목표를 분명히 한다. 도메인 언어의 세부를 에이전트의 컨텍스트에 두어야 하므로 문서를 최신으로 유지할 이유가 하나 더 생긴다. 코드 가까이에 두는 마크다운 파일이 좋은 출발점이다. 별도의 통합 없이 가져올 수 있기 때문이다.

개발자가 도메인 전문가가 되고 생각은 위임하지 않는다

모델과 에이전트는 좋아지지만 완전히 믿을 수는 없다. 실수하고 결국 책임질 사람이 필요하다. 결과가 맞는지 어떻게 아는가에 대한 저자의 답은 도메인에서 일하며 쌓은 신뢰다. 시스템을 설계하고 작동 방식을 아는 사람만이 무엇이 잘못될 가능성이 높은지 말해 줄 수 있다. 호기심 있는 엔지니어에게는 복잡한 업무 도메인도 시간이 지나며 직관적이 된다. 저자는 요즘의 AI 서사를 둘로 나눈다. 누구나 유명 앱의 복제품을 만들 수 있다는 이야기는 처음엔 충격이었지만 길게 보면 흥미롭지 않다. 더 흥미로운 이야기는 경험 많은 엔지니어가 더 복잡한 애플리케이션을 만들 수 있게 됐다는 것이다. 예를 들어 팀이 비싼 서드파티 소프트웨어를 자체 솔루션으로 바꾸는 경우, 그 버전이 잘 동작한다고 믿을 근거는 그 도메인에서 일하며 쌓은 지식이다.

글의 마지막 주제는 생각을 위임하지 말라는 것이다. 저자는 첫 직장에서 펜과 종이로 몇 시간 끄적이다 키보드는 거의 만지지 않고 어려운 문제를 풀었던 기억을 꺼낸다. 당시에는 생각하는 일로 월급을 받는다는 사실에 놀랐는데, 지금은 결과물에 더 집중하고 생각마저 AI에게 시키자는 분위기라고 말한다. 그가 에이전트 출력의 타당성을 판단할 수 있는 것은 과거에 그런 문제를 오래 생각해 봤기 때문이다. 복잡한 문제를 다루려면 두뇌를 써야 하고 생각 없이는 새로운 멘탈 모델을 만들 수 없다는 것이 그의 입장이다. 책을 읽는 것과 요약을 읽는 것의 비유가 핵심 근거다. 책을 읽으면 몇 시간 주제를 붙들고 다른 지식과 연결하며 복잡한 모델을 쌓지만 요약은 탭을 닫으면 10초 뒤에 잊힌다.

적용 범위와 남은 질문

이 글은 저자의 의견이며 실험이나 측정 결과가 아니다. 저자는 수개월에서 수년 유지되고 팀이 고전하는 복잡한 프로젝트를 이야기하며 토이 프로젝트나 CRUD에 고급 패턴을 쓸 이유는 없다고 분명히 선을 긋는다. 그러니 DDD 전체를 모든 AI 코딩에 적용하라는 주장으로 읽으면 안 된다. 글에서 가장 설득력 있는 부분은 구체적 사례가 받쳐 주는 쪽이다. 월 1달러 사례와 모호한 프롬프트의 대비가 그렇다. 반면 “개발자가 도메인 전문가가 되면 자체 솔루션이 라이선스보다 싸다”는 전망은 저자의 관찰이며 비용 비교가 제시되지 않았다. 저자는 모범 사례를 아직 아무도 모르니 실험해 볼 때라고 말하고 전술적 패턴을 다룬 후속 글을 예고한다.

참고 자료

Miłosz Smółka — Domain-Driven Design matters more when AI writes your code (Three Dots Labs)