AI 코딩 시대, DDD가 더 필요해진 이유

Go 서비스에 DDD-lite와 Clean Architecture를 적용하면 뭐가 다를까? 안녕하세요, 금융쇼핑 PA 서버 Tech Lead 김지원입니다. 뱅크샐러드 서버는 대부분 Go로 만든 마이크로서비스입니다. 제가 입사하기 전 얘기라 정확하진 않은데, 마이크로서비스니까 각 서비스는 작을 거고, 그러니 로직은 핸들러에 다 담자고 했던 것 같습니다. 서비스가 작을 때는 이게 오히려 알맞을 수도 있겠습니다. 문제는 시간이 지나면서 일부 서비스들은 점점 커져서 마이크로서비스가 아닌 모놀리식 서비스가 되어버렸다는 건데요, 대표적으로 저희 금융쇼핑 PA 에는 신용 서비스 credit 과 대출비교 서비스 loancompare 가 있습니다. 핸들러에 로직이 다 들어가 있다보니 비슷한 코드가 여기저기 복사되고, 한 군데 고치면 다른 곳이 깨지는 사이드이펙트를 파악하기가 어려워졌죠. 다들 체감은 하는데 제대로 뜯어고칠 여유는 없어서 pkg, util 같은 폴더를 만들어 조금씩 옮기는 정도로 버텨온 것으로 보였고, 폴더는 그럴듯하게 나뉘어 있는데 의존성은 여전히 꼬여 있는 상태가 되어버렸습니다. 2025년 초에 팀에서 리팩토링 얘기가 나왔고, 저는 DDD(Domain-Driven Design) 를 제안했습니다. 정말 단순히 말하자면, 코드를 handler 나 repository 같은 기술 단위가 아니라 신용점수나 대출 같은 비즈니스 개념 단위로 나누자는 겁니다. 하지만 이런 DDD 는 정해진 답이 없고 조직의 공용 언어(Ubiquitous Language)와 비즈니스 도메인에 맞춰 리팩토링을 해야 합니다. 그래서 여러 책을 읽어보며 진행해도 우리 조직에는 어떻게 적용 해야할지 시행착오를 겪어야 했고, 그걸 또 구성원 전원이 같은 기준으로 따르게 만드는 게 어려웠습니다. 그래서 DDD와 함께 Clean Architecture 원칙을 일부 가져와서 코드 구조 자체로 기준을 잡았습니다. 쉽지 않을 거라고 예상은 했는데 예상보다 오래 걸렸고, 아직도 진행 중입니다. 그동안 AI 코딩 에이전트가 점점 대중화되었는데요, “이제 어차피 AI 가 코딩해줄텐데 구조를 잘 잡을 필요가 있나?” 라는 생각도 들었습니다. 하지만 저는 적어도 지금까지의 경험으로는 AI 가 작업하기 쉬운 환경을 만들기 위해서라도 DDD 는 아주 중요하다는 생각이 AI 를 사용할수록 강해졌습니다. 코드는 점점 AI가 작성할 텐데 그 코드를 감당할 수 있게 만드는 건 ...