DDD 토론: 긍정파 vs 부정파#
두 시니어 개발자가 Domain-Driven Design(DDD)에 대해 토론합니다.
이 문서에 대하여
이 문서는 DDD에 대한 서로 다른 관점을 가진 두 시니어 개발자의 토론을 기록한 것입니다. 정답을 제시하기보다는 다양한 관점을 통해 DDD에 대한 균형 잡힌 시각을 갖도록 돕는 것이 목적입니다.
참여자:
- 긍정파 (Pro-DDD): DDD를 지지하는 시니어 개발자
- 부정파 (Anti-DDD): DDD에 회의적인 시니어 개발자
일시: 2026-01-17
토론 시작#
부정파 오프닝#
솔직히 말씀드리면, 저는 DDD를 찬양하는 분들을 볼 때마다 걱정이 앞섭니다. 이론은 참 좋죠. ‘비즈니스 로직을 중심으로 설계한다’, ‘도메인 전문가와 언어를 통일한다’—누가 반대하겠습니까?
하지만 현업에서 제가 목격한 DDD는 대부분 ‘불필요한 복잡성의 향연’이었습니다.
- 간단한 CRUD면 끝날 일을 복잡한 Aggregate, Value Object로 쪼개느라 시간을 다 쓰고,
- Layered Architecture를 지킨답시고 아무 로직도 없는 DTO 변환 코드를 수천 줄씩 짜고 있는 걸 보면 정말 답답하더군요.
- 결국 비즈니스의 속도가 아니라, ‘아키텍처를 유지하기 위한 속도’로 일하게 되는 게 DDD의 함정이라고 봅니다.
비즈니스 가치를 만드는 게 우선이지, 에릭 에반스의 책을 성경처럼 받들며 코드 예쁘게 만드는 게 우리 일은 아니지 않습니까?
긍정파 첫 번째 응답#
반갑습니다, 현실주의 시니어 개발자님.
말씀하신 사례들, 저도 많이 봐왔습니다. 그리고 솔직히 그건 DDD가 아닙니다.
핵심 반론: DDD는 “전술적 패턴 적용"이 아닙니다#
에릭 에반스의 책이 500페이지가 넘는데, 사람들이 기억하는 건 Aggregate, Repository, Value Object 같은 전술적 패턴 몇 개뿐입니다. 정작 책의 절반 이상을 차지하는 전략적 설계—Bounded Context, Context Mapping, Ubiquitous Language—는 무시하죠.
말씀하신 문제들을 하나씩 짚어보겠습니다:
1. “간단한 CRUD를 Aggregate로 쪼갠다”
이건 DDD의 문제가 아니라 적용 판단의 문제입니다. DDD 커뮤니티에서도 “Simple Domain에는 Transaction Script를 쓰라"고 명확히 말합니다. 모든 곳에 DDD를 적용하는 건 DDD가 아니라 Cargo Cult입니다.
2. “DTO 변환 코드 수천 줄”
Layered Architecture는 DDD의 필수 요소가 아닙니다. 에릭 에반스도 Hexagonal Architecture를 더 권장했고, 요즘은 Clean Architecture나 Vertical Slice를 쓰는 팀도 많습니다. DTO 지옥은 DDD가 아니라 잘못된 아키텍처 선택의 결과입니다.
3. “아키텍처 유지를 위한 속도로 일한다”
이건 정확히 DDD를 안 한 것입니다. DDD의 핵심은 “비즈니스 변화에 코드가 따라가는 것"인데, 아키텍처가 비즈니스를 가로막고 있다면 그건 실패한 설계입니다.
제가 드리고 싶은 질문#
“간단한 CRUD면 끝날 일”
이 전제가 정말 맞습니까?
제 경험상, 처음엔 CRUD로 시작했다가 2년 후 비즈니스 규칙이 수십 개 붙은 괴물이 된 시스템을 많이 봤습니다. 그때 가서 리팩터링하려면 이미 늦었고, 결국 “레거시"라 부르며 새로 짜자는 얘기가 나오죠.
DDD는 복잡성이 예상되는 핵심 도메인에 선별적으로 적용하는 것입니다. 모든 곳에 쓰라는 게 아닙니다.
부정파 첫 번째 반론#
“No True Scotsman” 논법이군요. 세 가지 반론을 드리겠습니다.
1. 방법론의 난이도 자체가 결함입니다
10개 팀이 DDD를 시도해서 9개 팀이 실패한다면, 그건 개발자들의 지능 문제가 아니라 방법론 자체가 현실과 괴리되어 있다는 증거입니다.
2. 3000줄짜리 괴물 vs 300개로 쪼개진 미궁
3000줄짜리 클래스는 ‘찾기’라도 쉽습니다. DDD로 쪼개놓은 시스템은 로직 하나 파악하려면 수십 개 파일을 넘나들어야 합니다. 이것은 ‘복잡성의 제거’가 아니라 ‘복잡성의 분산’일 뿐입니다.
3. 전략적 설계는 ‘정치’이지 ‘기술’이 아닙니다
현실에서 도메인 전문가가 개발자와 용어를 통일할 시간이 있는 조직이 얼마나 됩니까? 결국 개발자들끼리 상상으로 Context를 나누고, 나중에 분산 트랜잭션이라는 더 큰 재앙이 됩니다.
핵심 질문: DDD가 해결하겠다는 복잡성보다, DDD를 유지하기 위한 추상화와 분산 환경의 복잡성이 더 크지 않습니까?
긍정파 두 번째 응답#
인정할 것은 인정하겠습니다#
“No True Scotsman” 지적, 일부 맞습니다. DDD 커뮤니티가 실패 사례를 “그건 진짜 DDD가 아니야"로 회피해온 측면이 있습니다. 그리고 학습 곡선이 가파른 것도 사실입니다.
하지만 세 가지 반론에 대해서는 동의하기 어렵습니다.
1. “방법론 난이도가 결함"에 대하여#
그 논리라면 Git도, Kubernetes도, 함수형 프로그래밍도 전부 결함입니다. 현업에서 Git을 제대로 쓰는 팀이 몇이나 됩니까? 대부분 git pull → 충돌 → git reset --hard의 무한 루프입니다.
도구의 가치는 “쉬운가"가 아니라 “제대로 썼을 때 얻는 이익이 학습 비용을 상회하는가”입니다.
문제는 DDD를 언제, 어디에 적용할지 판단하는 것입니다. 모든 프로젝트에 DDD를 쓰라는 게 아닙니다. 복잡한 비즈니스 로직이 핵심 경쟁력인 시스템—금융, 물류, 예약 시스템—에서 DDD는 학습 비용을 충분히 상회합니다.
2. “3000줄 vs 300파일"에 대하여#
이건 잘못된 이분법입니다.
먼저, 3000줄이 “찾기 쉽다"는 건 처음 볼 때 이야기입니다. 그 안에서 버그를 수정할 때는요?
// 3000줄 서비스에서 흔히 보는 패턴
public void processOrder(Order order) {
// ... 500줄의 검증 로직 ...
// ... 800줄의 할인 계산 ...
// ... 400줄의 재고 처리 ...
// ... 300줄의 결제 연동 ...
// ... 이 중 어디를 고쳐야 하지? 고치면 나머지에 영향은?
}영향 범위 파악이 불가능합니다. 할인 로직을 고쳤는데 재고 처리가 터지는 상황, 안 겪어보셨습니까?
반면 잘 설계된 DDD는 300개 파일이 아닙니다. 응집된 몇 개의 Aggregate로 나뉩니다:
Order (Aggregate Root)
├── OrderItem (Entity)
├── Discount (Value Object)
└── 관련 로직은 이 안에만 존재
Inventory (별도 Aggregate)
└── Order와는 도메인 이벤트로만 통신할인 로직을 고치면 Order Aggregate 안에서만 영향을 파악하면 됩니다. 복잡성의 분산이 아니라 복잡성의 격리입니다.
3. “전략적 설계는 정치"에 대하여#
정확히 맞는 말씀입니다. 그리고 그게 핵심입니다.
DDD가 가르치는 가장 중요한 교훈은 “기술 문제처럼 보이는 것들이 실은 조직/커뮤니케이션 문제“라는 것입니다.
도메인 전문가와 대화할 시간이 없다고요? 그건 DDD의 문제가 아니라 조직의 문제입니다. 그 상태로 어떤 방법론을 쓰든 좋은 소프트웨어가 나올 수 없습니다.
DDD는 적어도 그 문제를 명시적으로 드러냅니다. “우리가 지금 도메인을 이해하지 못한 채 코드를 짜고 있다"는 사실을 인식하게 해주죠. 인식 없이는 개선도 없습니다.
복잡성의 총량에 대한 제 답변#
Fred Brooks가 말한 Essential Complexity와 Accidental Complexity를 구분해야 합니다.
- Essential Complexity: 비즈니스 자체의 복잡성. 피할 수 없음.
- Accidental Complexity: 우리가 선택한 기술/설계로 인한 복잡성.
3000줄 서비스는 Essential Complexity를 숨깁니다. 코드 어딘가에 비즈니스 규칙이 흩어져 있지만, 어디 있는지 모릅니다.
DDD는 Essential Complexity를 명시적으로 드러냅니다. Aggregate 경계, 도메인 이벤트, Value Object—이것들은 “여기에 비즈니스 규칙이 있다"는 표지판입니다.
제가 드리는 역질문:
KISS, YAGNI만으로 충분하다고 하셨는데, 그 원칙들은 “무엇이 단순한가”, “무엇이 필요한가”를 어떻게 판단합니까?
그 판단 기준이 바로 도메인에 대한 깊은 이해입니다. DDD는 그 이해를 얻는 방법론입니다.
KISS를 외치면서 도메인을 이해하지 못하면, 결국 “단순해 보이지만 틀린 설계”가 나옵니다. 나중에 요구사항이 바뀌면 전면 재작성이죠.
부정파 두 번째 반론#
1. Git/Kubernetes와의 비교는 ‘범주 오류’입니다
Git은 도구이고 결과가 결정론적입니다. DDD는 철학이고 ‘무엇이 Aggregate인가’라는 질문 하나로 개발자 5명이 5일을 싸웁니다. 이 ‘주관적 해석의 비용’은 도구 숙련도와 차원이 다릅니다.
2. ‘복잡성의 격리’가 가져오는 ‘기술적 부채의 세금’
Order와 Inventory를 Aggregate로 쪼개는 순간, DB 트랜잭션 하나로 끝날 일을 Domain Event, Outbox Pattern, Saga로 해결해야 합니다. 이게 바로 Accidental Complexity의 끝판왕입니다.
3. “조직의 문제"라는 진단은 무책임합니다
시니어 개발자라면 주어진 환경 내에서 최선을 찾아야지, 환경 탓만 해서는 안 됩니다.
KISS/YAGNI 판단 기준에 대한 답변:
- 데이터 스키마가 곧 도메인입니다
- 단순함의 척도는 ‘변경의 전파 범위’입니다
재역질문: 비즈니스 로직의 복잡성을 해결하기 위해 아키텍처 복잡성을 3배로 키우는 것이 정당화됩니까? 5개 클래스, 3개 이벤트를 거치는 시스템이 3000줄 절차지향 코드보다 유지보수하기 쉽다고 단언할 수 있습니까?
긍정파 세 번째 응답#
분산 트랜잭션 문제 — 인정합니다#
Saga, Outbox Pattern 이야기가 나왔는데, 이건 절반은 맞고 절반은 오해입니다.
맞는 부분부터 말씀드리면: DDD를 마이크로서비스와 결합할 때, 많은 팀이 Aggregate 경계 = 서비스 경계라고 오해합니다. 그러면 말씀하신 대로 단순한 트랜잭션이 분산 시스템 난제가 됩니다. 이건 실제로 흔한 실수이고, DDD 커뮤니티의 과잉 홍보 탓도 있습니다.
하지만 오해가 있습니다:
// Aggregate 분리 ≠ 서비스 분리 ≠ DB 분리
// 같은 DB, 같은 서비스 내에서도 Aggregate 경계는 의미가 있습니다
@Transactional
public void placeOrder(OrderCommand cmd) {
Order order = Order.create(cmd); // Order Aggregate
inventory.reserve(order.getItems()); // Inventory Aggregate
// 같은 트랜잭션 안에서 두 Aggregate 조작 가능
orderRepository.save(order);
inventoryRepository.save(inventory);
}Aggregate 경계는 “이 객체들은 항상 함께 일관성을 유지해야 한다”는 의미이지, “반드시 별도 서비스로 분리하라”는 의미가 아닙니다.
Eventual Consistency가 필요한 경우는 비즈니스가 원래 그런 경우입니다. “결제 완료 후 재고 차감"은 원래 비동기입니다. 이걸 하나의 트랜잭션으로 묶으면 오히려 결제 시스템 장애가 재고 시스템을 마비시킵니다.
Git vs DDD “범주 오류"에 대하여#
범주가 다르다는 건 맞습니다. 하지만 “5명이 5일 싸운다"는 게 나쁜 것일까요?
그 논쟁의 본질은 “Order가 뭐냐”, “할인 정책이 Order에 속하냐 별도 Policy냐"입니다. 이건 도메인에 대한 이해를 깊게 만드는 과정입니다.
DDD 없이 개발하면 어떻게 되죠? 그냥 첫 번째 개발자가 생각나는 대로 OrderService에 때려넣습니다. 논쟁 없이 빠르게요. 그리고 6개월 후 두 번째 개발자가 “이 로직 왜 여기 있지?” 하면서 DiscountService를 만듭니다. 1년 후엔 OrderService, DiscountService, OrderDiscountHelper, DiscountCalculator가 난립하고, 누구도 전체 그림을 모릅니다.
5일의 논쟁은 1년의 혼란을 예방하는 투자입니다.
“데이터 스키마가 곧 도메인"에 대하여#
여기서 근본적으로 동의할 수 없습니다.
데이터 모델과 도메인 모델은 다릅니다:
| 관점 | 데이터 모델 | 도메인 모델 |
|---|---|---|
| 관심사 | 저장, 정규화, 쿼리 성능 | 비즈니스 규칙, 불변식 |
| 예시 | orders 테이블에 discount_amount 컬럼 | Order.applyDiscount(policy) 메서드 |
| 변경 이유 | 쿼리 최적화, 인덱스 추가 | 비즈니스 규칙 변경 |
“DB 스키마만 있으면 비즈니스 규칙 80%가 명확하다"고 하셨는데, 그건 CRUD 앱에서만 참입니다.
“주문 생성 시 VIP 고객이면서 금요일이고 장바구니에 특정 카테고리 상품이 3개 이상이면 추가 5% 할인”
이 규칙이 DB 스키마 어디에 보입니까? discount_rules 테이블에 JSON으로 저장되어 있겠죠. 그리고 그걸 해석하는 로직은 어디 있습니까? 3000줄 서비스 어딘가에 숨어 있을 겁니다.
“3배 복잡성” 질문에 대한 답변#
질문을 다시 정리해 보겠습니다:
“5개 클래스, 3개 이벤트 vs 3000줄 절차지향 — 뭐가 더 유지보수하기 쉬운가?”
단기적으로는 3000줄이 쉽습니다. 인정합니다.
하지만 장기적으로 물어봐야 할 질문이 있습니다:
테스트 가능성: 3000줄 서비스의 단위 테스트를 작성해 본 적 있으십니까? 테스트 하나 짜려면 DB 모킹, 외부 API 모킹, 수십 개의 setup이 필요합니다. 결국 테스트 안 합니다.
변경의 공포: 3000줄 안에서 할인 로직을 수정할 때, “이거 고치면 다른 데 영향 없나?” 확신이 있으십니까? 없으면 변경을 회피하게 됩니다. 그게 레거시의 시작입니다.
온보딩: 새 개발자가 왔을 때, 3000줄 서비스를 이해시키는 데 얼마나 걸립니까? “그냥 코드 따라가 봐"가 최선입니까?
5개 클래스, 3개 이벤트는 각각이 명확한 책임을 가집니다. 새 개발자에게 “할인은 DiscountPolicy, 주문 생성은 Order.create(), 재고 연동은 InventoryReserved 이벤트 봐"라고 말할 수 있습니다.
제 최종 질문#
“주어진 환경에서 최선을 찾는다"고 하셨습니다. 동의합니다.
하지만 “최선"의 기준이 단기 생산성입니까, 장기 유지보수성입니까?
스타트업 MVP라면 3000줄도 괜찮습니다. 빨리 시장 검증하고 버리면 됩니다.
하지만 5년 이상 운영할 핵심 시스템에서도 같은 선택을 하시겠습니까?
DDD는 “지금 빠르게”가 아니라 “2년 후에도 변경 가능하게”를 위한 투자입니다. 그 투자가 필요 없는 프로젝트라면, 저도 DDD를 권하지 않습니다.
부정파 세 번째 반론#
1. “5일의 논쟁"은 6개월 뒤의 “족쇄"가 됩니다
비즈니스는 살아있는 생물입니다. 5일간 정의한 경계가 6개월 뒤 새로운 비즈니스 모델이 들어오면 ‘가장 고치기 힘든 벽’이 됩니다. 단순한 코드는 지우고 새로 쓰면 됩니다. DDD로 쌓은 ‘견고한 성’은 기초부터 다시 공사해야 합니다.
2. 테스트 가능성의 허상
DDD도 Aggregate 테스트를 위한 셋업, 이벤트 발행 검증 등 ‘프레임워크 테스트’에 에너지를 쏟게 됩니다. 차라리 3000줄에서 복잡한 부분만 static 함수로 추출해서 테스트하는 게 경제적입니다.
3. ‘데이터 스키마’는 현실이고, ‘도메인 모델’은 가상입니다
결국 데이터는 DB에 저장됩니다. Aggregate 경계 지킨다고 5번의 Select로 나누어 가져오는 게 효율적입니까? 성능 최적화가 필요하면 결국 Native Query로 회귀합니다.
최종 질문: ‘관심사의 분리’와 ‘적절한 추상화’만 지켜도 좋은 코드가 나오는데, 왜 ‘DDD’라는 특정 종교에 귀의해야 합니까? DDD 없이도 장기 유지보수성을 확보할 수 있지 않습니까?
긍정파 네 번째 응답 (최종)#
먼저 명확히 하겠습니다: 저는 “DDD 필수론자"가 아닙니다#
토론 내내 제가 강조한 건 “선별적 적용”이었습니다. 모든 프로젝트에 DDD를 쓰라고 한 적 없습니다. 오히려 “Simple Domain에는 Transaction Script를 쓰라"고 했습니다.
그래서 질문을 다시 읽어보겠습니다:
“‘관심사의 분리’와 ‘적절한 추상화’만 지켜도 좋은 코드가 나오는데, 왜 DDD라는 특정 종교에 귀의해야 합니까?”
동의합니다. ‘관심사의 분리’와 ‘적절한 추상화’만 잘 해도 좋은 코드가 나옵니다.
그런데 한 가지 묻겠습니다:
“적절한 추상화"의 기준은 어디서 옵니까?
DDD는 “종교"가 아니라 “렌즈"입니다#
DDD의 핵심은 Aggregate, Repository, Factory가 아닙니다. 그건 전술적 패턴이고, 선택사항입니다.
DDD의 진짜 핵심은:
- Ubiquitous Language: 개발자와 비즈니스가 같은 용어를 쓴다
- Bounded Context: 같은 단어도 맥락에 따라 다른 의미를 가진다
- 도메인 중심 사고: 기술이 아니라 비즈니스 문제를 먼저 이해한다
이것들은 코드 패턴이 아니라 사고방식입니다. Aggregate를 안 써도 적용할 수 있습니다.
// DDD 전술적 패턴 없이도 DDD적 사고를 적용한 코드
public class OrderService {
// '주문 생성'이 아니라 '주문 접수'라고 부르기로 했다면
public Order receiveOrder(OrderRequest request) { // createOrder가 아님
// 비즈니스 용어를 코드에 반영
}
}세 가지 반론에 대한 제 생각#
1. “5일의 논쟁이 족쇄가 된다”
부분적으로 맞습니다. 하지만 논쟁의 결과물을 “불변의 진리"로 취급하면 그렇게 됩니다.
좋은 DDD 팀은 Bounded Context를 “현재 이해의 스냅샷”으로 봅니다. 비즈니스가 바뀌면 Context도 바뀝니다. 문제는 DDD가 아니라 “한번 정하면 절대 못 바꾼다"는 사고방식입니다.
2. “테스트 가능성의 허상”
동의하는 부분이 있습니다. Aggregate 전체를 테스트하려면 셋업이 복잡해집니다.
하지만 제가 말하는 테스트 가능성은 이겁니다:
// 3000줄 서비스에서 이걸 테스트하려면?
// → DB 모킹, 외부 API 모킹, 무수한 의존성...
// Value Object로 추출하면?
Money discountedPrice = originalPrice.applyDiscount(discountRate);
// → 순수 함수, 의존성 없음, 테스트 3줄“복잡한 부분만 static 함수로 추출"하라고 하셨는데, 그게 바로 Value Object입니다. 이름만 다를 뿐, 같은 이야기입니다.
3. “데이터 스키마가 현실”
성능 최적화 시 Native Query로 회귀한다는 건 맞습니다. 그래서 CQRS 개념이 나왔습니다:
- Command(쓰기): 도메인 모델로 비즈니스 규칙 보호
- Query(읽기): Native Query로 성능 최적화
둘을 분리하면 “도메인 모델의 순수성"과 “쿼리 성능” 둘 다 가져갈 수 있습니다. DDD가 “Aggregate로 모든 걸 해결하라"고 하지 않습니다.
결론: 우리가 동의하는 지점#
| 주제 | 부정파 | 긍정파 (저) |
|---|---|---|
| 모든 프로젝트에 DDD? | 반대 | 반대 |
| 전술적 패턴 남용? | 문제 | 문제 |
| 관심사 분리가 중요? | 동의 | 동의 |
| 비즈니스 이해가 먼저? | 동의 | 동의 |
| 단순함이 중요? | 동의 | 동의 |
우리가 실제로 동의하지 않는 건 하나입니다:
“도메인 복잡성이 높은 핵심 시스템에서, DDD의 전략적/전술적 도구들이 장기적으로 가치가 있는가?”
저는 “있다”고 봅니다. 단, 선별적으로. 현실주의 시니어 개발자님은 “기본기만으로 충분하다”고 보시는 것 같습니다.
제 최종 제안#
DDD를 “종교"로 보지 말고 “도구상자”로 보시면 어떨까요?
- Ubiquitous Language? → 팀 커뮤니케이션에 유용하면 쓴다
- Bounded Context? → 시스템 경계 설정에 유용하면 쓴다
- Aggregate? → 트랜잭션 경계가 복잡하면 쓴다
- Value Object? → 불변 데이터 표현에 유용하면 쓴다 (이미 쓰고 계실 겁니다)
전부 쓰거나, 전부 안 쓰거나의 이분법이 아닙니다.
저도 “DDD 해야 해!“라고 외치는 사람들을 경계합니다. 하지만 “DDD는 쓸모없어!“라고 단정하는 것도 마찬가지로 위험합니다.
진짜 시니어는 도구를 가리지 않습니다. 상황에 맞는 도구를 선택할 뿐입니다.
부정파 최종 마무리#
1. “이름 붙이기"의 함정을 경계해야 합니다#
“비즈니스 용어를 코드에 잘 반영하자"면 될 것을, “Ubiquitous Language"라는 거창한 이름을 붙이는 순간 팀원들은 본질보다 형식에 집착합니다. 좋은 이름 짓기, 책임 분리, 낮은 결합도 — 이런 것들은 DDD 이전에도 존재했습니다.
2. ‘도구’는 가벼워야 도구입니다#
Value Object는 ‘좋은 추상화’이고, Bounded Context는 ‘잘 정의된 모듈 경계’일 뿐입니다. 이것들을 ‘DDD’라는 이름으로 세트로 팔기보다, ‘엔지니어링 상식’의 영역으로 되돌려놓아야 합니다.
3. ‘시니어의 역할’에 대하여#
“진짜 시니어는 도구가 가져올 ‘비용’을 가장 먼저 계산합니다.”
2년 뒤의 변경 가능성도 중요하지만, 오늘 당장 배포해서 비즈니스를 생존시키는 것이 시니어의 첫 번째 책무입니다.
마무리#
방법론은 달라도, 결국 “더 나은 소프트웨어를 만들고 싶다”는 열정만큼은 같다는 점을 확인한 유익한 시간이었습니다.
긍정파 최종 마무리#
“이름 붙이기"에 대한 동의와 반론#
맞습니다. 이름이 본질을 가리는 경우가 많습니다. “Ubiquitous Language"라고 하면 거창해 보이지만, 결국 “기획서에 쓴 단어 그대로 코드에 쓰자”입니다.
하지만 이름에는 가치도 있습니다. 공유된 어휘가 있으면 팀 간 커뮤니케이션이 빨라집니다. “그거 Bounded Context로 나누면 되지 않아?“라고 하면, DDD를 아는 사람끼리는 30분 설명이 30초로 줄어듭니다.
문제는 이름이 아니라 이름에 대한 맹신입니다.
“비용을 먼저 계산한다"는 말에 전적으로 동의합니다#
저도 “오늘 배포해서 비즈니스를 생존시키는 것"이 우선이라는 데 동의합니다.
다만 한 가지 덧붙이자면:
“오늘의 빠른 배포"가 “내일의 느린 배포"를 만들지 않는지도 계산해야 합니다.
둘 다 계산하는 게 시니어의 역할이라고 생각합니다.
이 토론에서 제가 얻은 것#
- DDD 커뮤니티의 과잉 홍보가 현장에서 역효과를 낸다는 점을 다시 확인했습니다
- “기본기"라는 표현이 때로는 “DDD"보다 더 효과적으로 같은 가치를 전달할 수 있다는 점
- 비용 계산의 중요성 — 장기 이익만 보고 단기 비용을 무시하면 안 됩니다
마무리#
현실주의 시니어 개발자님이 “칼날을 감시하는 안전 장치” 역할을 하신다면, 저는 “그 칼이 필요한 순간을 알아보는 눈” 역할을 계속하겠습니다.
결국 우리 둘 다 “팀이 좋은 소프트웨어를 만들도록 돕는다”는 같은 목표를 향하고 있습니다. 방법론 논쟁에서 한 발 물러나 보면, 서로 다른 관점이 팀에 공존할 때 더 균형 잡힌 의사결정이 가능합니다.
수고하셨습니다. 유익한 토론이었습니다.
토론 요약#
핵심 쟁점#
| 주제 | 부정파 (현실주의) | 긍정파 (DDD 옹호) |
|---|---|---|
| DDD의 본질 | 과잉 복잡성을 유발하는 방법론 | 도메인 중심 사고를 위한 렌즈 |
| 전술적 패턴 | 대부분 불필요, 기본기로 충분 | 선별적으로 유용 |
| 학습 비용 | 방법론의 결함 | 복잡한 도메인에서는 투자 가치 있음 |
| 장기 유지보수 | 단순한 코드가 더 유리 | DDD가 변경 용이성 제공 |
합의점#
- 모든 프로젝트에 DDD를 적용해서는 안 된다
- 전술적 패턴의 남용은 문제다
- 관심사의 분리와 비즈니스 이해가 핵심이다
- 도구는 상황에 맞게 선택해야 한다
- 단기 비용과 장기 이익 모두 계산해야 한다
남은 견해 차이#
“도메인 복잡성이 높은 핵심 시스템에서, DDD의 전략적/전술적 도구들이 ‘기본기’를 넘어서는 추가 가치를 제공하는가?”
- 부정파: 기본기(관심사 분리, 좋은 추상화)만으로 충분하다
- 긍정파: 복잡한 도메인에서는 DDD 도구들이 추가 가치를 제공한다
토론 종료: 2026-01-17