요즘 개발 이야기에서 빠지지 않는 주제가 AI 코딩입니다.
코드를 짜는 일은 AI가 상당 부분 대신해 줍니다.
그런데 개발 현장에서 가장 어려운 일은 그대로 남아 있습니다.
바로 이 시스템이 어떤 비즈니스 문제를 풀어야 하는지 아는 일입니다.
20년 전에 나온 이론인 DDD(도메인 주도 설계)가 AI 시대에 오히려 다시 주목받는 이유를 3가지로 정리합니다.
하나. 코드는 쉬워졌지만, 도메인은 여전히 어렵습니다
DDD는 Domain-Driven Design의 줄임말로, 우리말로 도메인 주도 설계입니다.
DDD 뜻을 한 문장으로 말하면, 소프트웨어가 풀어야 할 비즈니스 문제를 설계의 중심에 두는 방법론입니다.
여기서 도메인은 개발하려는 분야 그 자체를 가리킵니다.
숙박 예약이 도메인이 될 수 있고, 배달 주문이 도메인이 될 수 있습니다.
이 개념은 2003년 에릭 에번스의 책에서 처음 정리됐습니다.
에번스는 개발자가 프레임워크 정비에 매여 있고, 정작 어려운 도메인 이해는 다른 사람에게 맡겨졌다고 지적했습니다.
해외 개발 블로그 Three Dots Labs는 이 실수가 지금도 이어진다고 짚습니다.
프레임워크 대신 모델 벤치마크와 AI 코딩 도구 세팅에 힘을 쏟을 뿐이라는 분석입니다.
구현 세부는 AI가 잘 처리합니다.
그래서 남는 어려움은 결국 이 시스템이 어떻게 동작해야 하는가라는 질문입니다.
기술이 쉬워질수록, 도메인을 아는 일이 상대적으로 더 어려운 일이 됩니다.
둘. AI가 만든 문서는 팀의 이해가 되지 않습니다
도메인 주도 설계에는 지식 정제(Knowledge Crunching)라는 표현이 있습니다.
도메인을 잘 아는 사람과 개발자가 함께 도메인을 다듬어 모델로 만들고, 그 모델을 코드에 옮기는 과정입니다.
이 과정은 시간과 협업이 많이 들기 때문에, AI에게 맡기고 싶어집니다.
에이전트는 문서와 채팅 기록, 코드를 훑어보고 그럴듯한 도메인 모델 문서를 만들어 줍니다.
하지만 같은 글은 이 방법이 빗나간다고 지적합니다.
모델을 다루는 일의 가치는 산출물이 아니라, 우리 팀이 도메인을 이해하게 됐다는 데 있습니다.
에이전트가 만든 방대한 문서는 정작 읽는 사람 없이 묻히기 쉽습니다.
이어지는 개념이 유비쿼터스 언어(Ubiquitous Language)입니다.
팀 전체와 코드에서 같은 용어를 쓰자는 원칙입니다.
이 글에는 좋은 사례가 나옵니다.
클라우드 비용을 줄이려고 에이전트에게 메모리 사용량을 줄이라고만 지시한 일입니다.
에이전트는 메모리를 수 MB 아꼈지만, 실제 절감액은 월 1달러에 그쳤습니다.
비용 절감이라는 진짜 목표를 알려주지 않았기 때문입니다.
사람끼리 협업할 때 생기는 소통 문제와 같은 문제입니다.
그래서 도메인 용어를 문서와 코드에 통일해 두면, 에이전트가 읽는 맥락에도 같은 언어가 들어갑니다.
코드 곁에 두는 마크다운 문서가 좋은 출발점입니다.
에이전트에게 시킨 일이 계속 빗나간다면, 먼저 용어부터 점검하십시오.
셋. 남는 어려운 일은 생각과 판단입니다
에이전트의 결과물이 맞는지 판단하려면, 문제를 오래 생각해 본 경험이 필요합니다.
글쓴이는 첫 직장에서 종이에 그림을 그리며 문제를 붙들었고, 키보드는 거의 만지지 않았다고 회상합니다.
그날 느낀 '일해서 생각했다'는 감각이, 지금은 결과물 중심으로 흐려지고 있다는 지적입니다.
이어지는 비유가 인상적입니다.
책을 직접 읽으면 주제를 몇 시간씩 생각하게 되고, 머릿속에 모형이 만들어집니다.
요약문은 탭을 닫으면 10초 만에 잊힙니다.
도메인을 아는 개발자의 가치도 함께 커집니다.
대표적인 사례가 비싼 라이선스비를 내던 외부 소프트웨어를 자체 개발로 대체하는 일입니다.
그 팀이 자기 버전을 믿을 수 있는 근거는, 그 도메인에서 쌓은 지식입니다.
여기에 AI 코딩의 속도가 더해지면, 라이선스보다 저렴하고 원하는 기능을 더한 대체품을 만들 수 있습니다.
에이전트의 출력을 판단하는 능력은, 출력 이전의 생각에서 나옵니다.
DDD가 빛나는 조건, 그리고 한계
다만 이 방법론이 모든 프로젝트의 정답은 아닙니다.
같은 글도 단순한 CRUD 화면이나 사이드 프로젝트에 고급 패턴까지 챙길 필요는 없다고 분명히 합니다.
반대로 여러 해 유지되고 도메인이 복잡한 시스템에서는 이 설계가 빛을 발합니다.
오래 살아남는 시스템일수록, 기술보다 도메인 이해가 자산이 되기 때문입니다.
정리하면 DDD 뜻은 도메인을 설계의 중심에 두는 것이고, AI 코딩 시대에는 이 원칙이 오히려 더 단단해집니다.
코드는 AI가 짜도, 무엇을 만들지와 무엇이 맞는지는 사람의 몫으로 남습니다.
개발만 하는 업체와 운영까지 하는 업체, 그 차이를 아시나요?
개발만 하는 업체는 기능을 완성하면 일이 끝납니다.
운영까지 하는 업체는 출시 뒤에 생길 문제까지 고려해서 만듭니다.
에그코드는 자체 서비스를 직접 운영하는 개발사입니다.
그 운영 노하우를 바탕으로 외주 개발을 진행합니다.
함께 읽어보세요 — AI코딩의 진짜 문제, 아무도 시스템을 모를 때 생기는 4가지 · AI시대 개발자가 코드 작성 말고 진짜 하는 일 3가지 · MSA 뜻, 모놀리식과 차이와 도입 시점 · 에그코드 외주 개발 서비스