DDD 는 silverbullet일까?

DDD는 silverbullet일까?

DDD(Domain-Driven Design)는 그때나 지금이나 개발자들 사이에서 최고의 해법처럼 회자되는 방법론이다. 정확한 뜻을 몰라도 이름만으로 뭔가 있어 보이는, 오히려 초심자 입장에서 더 끌리게 되는, 그런 매력을 가진 이름이라고 생각한다. 프로젝트 당시 나 또한 그에 끌리는 사람 중 한명이었기 때문에, 프로젝트에 DDD를 도입하자는 팀원들의 제안을 마냥 뿌리치기가 힘들었다.

본격적으로 도입을 준비하면서 공부를 시작했는데, 조금씩 의문이 생기기 시작했다. "우리 프로젝트에서 사용해도 괜찮은가?" "DDD를 해서 우리가 실제로 얻는 게 뭘까?" 하는 질문들이었다. 나도 DDD 전문가는 아니었기 때문에 아키텍처 경험이 있는 지인에게도 조언을 구했는데, 원칙 수준의 조언은 들을 수 있었어도 어떻게 적용해야 하는가에 대한 구체적인 방법은 듣지 못했다. 요지는 결코 어떤 문제에나 적용할 수 있는 만능 해법이 아니니, 프로젝트의 도메인 지식을 잘 이해하고 트레이드오프를 정리하여 결정하라는 것이었다. 처음에는 이 말의 진의를 이해할 수 없었다.

그래서 직접 부딪혀보기로 했다. 테스트 모집 공고(MvpTest) 하나 아래에 진행 단계(Step)와 지원자 목록(MemberTest), 제출된 리포트(Report)까지 전부 묶어서 하나의 애그리거트로 다루려고 했다. 그런데 스텝 하나의 순서를 바꾸거나 가이드라인을 수정하는 사소한 작업이, 모집 인원이나 지원 상태를 다루는 로직과 같은 트랜잭션 경계 안에 물려 있는 구조가 되어버렸다. 게다가 요구사항이 늘어날 때마다 카테고리(Category), 정산(Settlement) 같은 애그리거트가 계속 추가로 정의됐고, 그때마다 관계는 점점 더 복잡해졌다. 그래서 MvpTest, Step, MemberTest, Report를 각각 별도 애그리거트로 쪼갰는데, 이번에는 이 네 개가 서로 어떤 관계를 가져야 하는지, 그리고 각 애그리거트의 경계를 어디까지 넓혀야 하는지가 계속 헷갈렸다. "모집 인원이 다 찼는가"라는 하나의 규칙을 MvpTest가 알아야 하는지, 아니면 지원자 목록 쪽에서 계산해야 하는지 같은 것들이 계속 발목을 잡았다.

관련된 책과 강의를 다시 찾아봤다. "애그리거트는 트랜잭션 일관성 경계다" 같은 원칙은 알려줬지만, 우리 서비스에서 그 경계가 정확히 어디인지는 책에서는 알려주지 않았다. 결국 근본적인 이유는 다른 데 있었다. 팀에 도메인 전문성을 가진 사람이 없었다는 것이다. 또한 팀 안에 도메인 전문성을 가지려는 사람이 없었다는 것이다. DDD의 핵심은 현실의 문제 영역, 즉 도메인 안에서 특정 문제를 엔지니어링으로 복잡성을 관리하는 것인데, 정작 우리는 "MVP 테스터 모집"이라는 도메인 자체에 관심을 가진 사람이 없었다.

이 고민들을 명확히 하고 나니, 지금 상태로 DDD 관점을 계속 밀어붙이는 것은 오히려 개발 교착상태를 유발하고 프로젝트를 지연시킬 뿐이라는 생각이 들었다. 핵심적으로는, 도메인 전문성이 없는 우리 팀에게 지금 DDD를 전면 적용하는 것 자체가 득보다 해가 될 수 있다는 것이었다. 따라서 현재로서는 DDD를 놓아주거나, 최소한의 적용 가능한 범위로 도입하는 쪽으로 방향을 잡을 필요가 있었다.

문제는 이제 와서 이 판단을 팀에 전달하려 하면, DDD에 취해 있는 데다가 이미 개발까지 밀어붙인 팀원들의 반감을 살 것이 분명하다는 점이었다. 반발은 반드시 있을 텐데, 이를 어떻게 최소화하면서 내 의도를 전달하고 프로젝트를 옳은 방향으로 이끌 수 있을지가 핵심 과제였다.

그래서 갑자기 폭탄을 터뜨리는 방법 대신, 소프트하게 주입하는 방향을 택하기로 했다. 아무리 입바른 소리고 옳은 말이라 해도, 지금 그가 작업 중인 것을 부정하는 것은 그 순간에는 오히려 자신의 논리를 방어하게 만든다고 생각했기 때문이다.

나는 먼저 공유 채널에 맥락과 내가 마주친 문제, 우리 프로젝트가 나아가야 할 방향을 정리한 문서를 제시하여 팀원들이 각자 비동기로 생각할 시간을 가질 수 있게 했다. 그리고 마지막에 '이 내용에 대해 여러 생각들이 있을 것이니, 질답세션을 통해 이야기하는 시간을 가져 보자'라고 덧붙였다. 팀원들은 아마 문서를 볼 당시에는 갑자기 이게 무슨 소린가 싶었을 테다. 그러면서도 질답 세션을 준비하면서 나름대로의 논리를 정리했을 것이다.

약간의 텀을 두고 진행된 질답 세션에서 팀원들은 감정적인 부분을 내려놓고 각자 정돈된 생각을 이야기했다. 내가 생각했던 것보다 팀원들은 훨씬 협조적이었고, 최소한의 영역에서만 도메인 분리와 애그리거트를 적용하는 쪽으로 온건하게 의사결정을 통일할 수 있었다. 이후로 팀 안에는 결론부터 던지기보다 근거를 먼저 공유하고 논의하는 문화가 자연스럽게 자리 잡았다.

범위를 줄이기로 합의는 했지만, 그 최소한의 범위 안에서라도 제대로 하려면 결국 도메인 지식이 필요했다. 그래서 우리와 비슷한 실제 매칭형 서비스들을 찾아보기 시작했다. 설문조사 참여형 플랫폼이나 재능 매칭 플랫폼들의 공개된 정책과 온보딩 흐름을 하나씩 뜯어봤다. 예를 들어 지원자가 매칭이 확정되기 전까지는 여러 공고에 동시에 지원할 수 있지만, 확정된 이후에는 다른 공고에 지원할 수 없게 막아둔다는 규칙이 여러 서비스에서 공통적으로 보였다. 책상 위에서는 나오지 않던 도메인 지식이 여기서 채워지기 시작했다.

이걸 바탕으로 전략적 설계를 다시 잡았다. 기업이 테스트를 등록하고 예산·모집조건을 관리하는 쪽과, 테스터가 지원하고 스텝을 진행하며 리포트를 제출하는 쪽은 변경 빈도와 요구되는 일관성 수준이 서로 달랐다. 전자는 자주 안 바뀌고 강한 일관성이 필요했지만, 후자는 지원자 수만큼 빈번하게 상태가 바뀌고 최종적 일관성 정도로도 충분했다. 이 차이를 근거로 모집 컨텍스트와 진행 컨텍스트로 바운디드 컨텍스트를 나누고, 두 컨텍스트 사이는 서로 객체를 직접 참조하지 않고 ID로만 연결하기로 했다. 컨텍스트마다 헷갈리던 용어도 하나로 통일했다. 예를 들어 어떤 팀원은 "지원자"라고 부르고 어떤 팀원은 "테스터"라고 부르던 대상을, 매칭이 확정되기 전까지는 지원자로, 확정된 이후에만 테스터로 부르기로 합의하는 식이었다. 그렇게 최소한의 범위나마 제대로 완성하고 나서 든 생각은, DDD를 한다는 것 자체가 매우 어렵고 험난한 일이라는 것이었다.

 

 

핵심 인사이트

이 일은 나에게 두 가지 생각을 남겼다.

하나는, 소프트웨어 세계에서 각광받는 DDD도 우리의 상황과 우리가 풀어야 하는 문제에 따라서는 독이 될 수 있다는 것이다. 이름값이 아니라 이걸로 뭘 얻는가가 기준이 되어야 한다. 나 역시 그 이름에 흘렸던 사람 중 하나였기 때문에, 프로젝트에 녹여보려 했다가 되려 의사결정을 번복하고 개발을 롤백해야 하는 상황을 맞았다. DDD는 현실 세계의 복잡성을 엔지니어링으로 풀어내는 훌륭한 방법이지만, 팀의 문제 상황과 도메인에 대한 이해 없이 무작정 도입했다가는 역효과를 볼 뿐이었다.

다른 하나는, 도메인 모델링은 개발자들끼리 책상 위에서 말로 풀리는 게 아니라는 것이다. 직접 도메인을 해부하고 그 안의 문제를 이해해야 얻어지는 것이었다. DDD 안에는 정말 많은 개념이 있었고, 그중에서 우리 팀의 상황에 진짜 필요한 개념만 골라 쓰는 것이 결국 가장 어려운 부분이었다. 다음에 비슷한 상황을 만난다면, 이번에는 책보다 도메인을 먼저 들여다볼 것 같다.