DDD는 죽지 않았습니다. 카고 컬트(Cargo-Cult) DDD가 죽었을 뿐입니다.

이것은 도메인 주도 설계 (Domain-Driven Design, DDD)에 대한 공격이 아닙니다.

DDD의 핵심 가치는 여전히 중요하며, 어쩌면 AI 시대에는 훨씬 더 중요할지도 모릅니다.

복잡한 비즈니스 도메인 (Business Domain) 이해
바운디드 컨텍스트 (Bounded Contexts) 정의
엔지니어와 도메인 전문가 간의 언어 정렬
불변량 (Invariants) 발견
상태 전이 (State Transitions)를 명시적으로 표현
변화가 어디에서 고통을 줄지 이해

코드 생성 (Code Generation)이 빨라진다고 해서 이러한 것들의 중요성이 줄어들지는 않습니다.

사실, 이들은 더욱 중요해집니다.

AI는 강력하지만, 명확한 경계, 정밀한 언어, 명시적인 제약 조건, 그리고 잘 정의된 동작에 대한 필요성을 제거하지 않습니다. 오히려 AI는 이러한 요소들이 부재할 때 상황을 더 위험하게 만듭니다. 코드를 생성하는 비용이 저렴해질수록, 불분명한 도메인 사고의 비용은 더욱 눈에 띄게 됩니다.

따라서 문제는 DDD 자체가 아닙니다.

문제는 다른 것입니다: 카고 컬트 (Cargo-Cult) DDD입니다.

더 정확히 말하자면:

문제는 전술적 DDD (Tactical DDD)를 조직적 통제의 도구로 사용하는 것입니다.

이해를 위한 DDD vs 통제를 위한 DDD

아키텍처에는 매우 다른 두 가지 용도가 있습니다.

이해를 위한 설계 (Design for understanding)
통제를 위한 설계 (Design for control)

최상의 상태에서의 DDD는 이해를 위한 설계입니다.

DDD는 팀이 비즈니스를 이해하도록 돕습니다. 사람들에게 언어를 명확히 하도록 강제합니다. 섞이지 말아야 할 컨텍스트를 분리합니다. 불변량과 상태 전이를 드러냅니다. 모델이 도메인을 반영하기 때문에 변화를 더 관리하기 쉽게 만듭니다.

그것은 가치 있는 일입니다.

하지만 많은 소프트웨어 제품 조직에서, 특히 팀이 성장함에 따라, 전술적 DDD (Tactical DDD)는 종종 다른 무언가로 변질됩니다.

엔티티 (Entity) 생성
밸류 오브젝트 (Value Object) 생성
레포지토리 (Repository) 추가
유스 케이스 (Use Case)에 작업 넣기
경계 데이터를 DTO로 변환
컨트롤러 (Controller)를 얇게 유지
매퍼 (Mapper) 작성
기존 디렉토리 구조 따르기

이러한 패턴들 중 본질적으로 나쁜 것은 없습니다.

엔티티, 밸류 오브젝트, 레포지토리, 유스 케이스, DTO, 그리고 매퍼를 사용해야 하는 타당한 이유들이 있습니다.

하지만 문제는 패턴의 존재 여부가 아닙니다.

질문은 이것입니다:

이 구조가 도메인 복잡성 (Domain Complexity)을 표현하고 있는가?
아니면 단순히 조직을 관리하기 쉽게 만들 뿐인가?

그 차이가 중요합니다.

전술적 DDD (Tactical DDD)가 제대로 사용될 때, 이는 엔지니어가 비즈니스를 추론하는 데 도움을 줍니다.

전술적 DDD (Tactical DDD)가 잘못 사용될 때, 그것은 표준화된 양식 채우기 작업이 됩니다. 모두가 어떤 파일을 만들어야 하는지 알고 있습니다. 리뷰어는 어떤 형식적인 규칙을 강제해야 하는지 압니다. 주니어 개발자에게는 작고 기계적인 작업들을 할당할 수 있습니다. 외부 벤더를 더 쉽게 온보딩할 수 있습니다. 사람들이 떠나더라도 적은 혼란 속에서 대체될 수 있습니다.

그 시점에서, 아키텍처는 더 이상 일차적으로 기술적인 도구가 아닙니다.

그것은 관리적 통제의 도구가 됩니다.

더 직설적으로 말하자면:

그것은 더 이상 복잡한 비즈니스 도메인을 다루기 위한 설계가 아닙니다.
그것은 복잡한 조직 내부에서 개발자들을 상호 교체 가능하게 만들기 위한 설계입니다.

전술적 DDD가 아키텍처적 서류 작업이 될 때

다시 말하지만, 패턴 그 자체가 문제는 아닙니다.

Value Object (값 객체)는 불변식 (Invariant)을 보호한다면 유용할 수 있습니다.

Repository (레포지토리)는 영속성 (Persistence) 관련 관심사를 도메인으로부터 격리한다면 유용할 수 있습니다.

Use Case (유스 케이스)는 의미 있는 비즈니스 연산을 나타낸다면 유용할 수 있습니다.

DTO (데이터 전송 객체)는 컨텍스트 (Context), API, 프로세스, 또는 신뢰 영역 (Trust Zone) 사이의 경계를 표시한다면 유용할 수 있습니다.

그러한 경우, 패턴은 의미를 가집니다.

하지만 다른 버전이 존재합니다.

Value Object (값 객체)는 그저 래퍼 클래스 (Wrapper Class)일 뿐입니다.
Repository (레포지토리)는 그저 이름만 바꾼 DAO일 뿐입니다.
Use Case (유스 케이스)는 그저 프레임워크가 코드를 넣으라고 지시한 장소일 뿐입니다.
DTO (데이터 전송 객체)는 의미론적 경계가 없는 복사된 데이터일 뿐입니다.
Mapper (매퍼)는 단지 한 객체에서 다른 객체로 필드를 옮길 뿐입니다.
디렉토리 구조는 진지해 보이지만, 모델은 거의 아무것도 말해주지 않습니다.

이것은 도메인 모델링 (Domain Modeling)이 아닙니다.

이것은 아키텍처적 서류 작업 (Architectural Paperwork)입니다.

코드베이스는 일련의 양식 (Forms)이 되어버립니다:

Controller (컨트롤러) 필드
Use Case (유스 케이스) 필드
Repository (레포지토리) 필드
Boundary (경계) 페이로드 필드
Mapper (매퍼) 필드
Entity (엔티티) 필드

개발자의 업무는 적절한 칸을 채워 넣는 것이 됩니다.

그것은 조직의 규모 확장 (organizational scaling)에 유용할 수 있습니다. 변동성을 줄여줄 수도 있습니다. 리뷰를 더 쉽게 만들어 줄 수도 있습니다. 경험이 적은 개발자들이 좁은 경계 안에서 안전하게 기여할 수 있게 해줄 수도 있습니다.

하지만 우리는 이것을 있는 그대로 불러야 합니다.

이것이 반드시 설계의 정교함 (design sophistication)을 의미하는 것은 아닙니다.

이것은 아키텍처 (architecture)로 표현된 관료주의 (bureaucracy)입니다.

AI는 이러한 종류의 작업을 훨씬 더 빠르게 만듭니다

AI는 이러한 형태의 작업에 매우 능숙합니다.

코드베이스에 이미 유사한 예시가 많이 포함되어 있다면, AI는 이를 빠르게 모방할 수 있습니다.

AI는 다음과 같은 것들을 생성할 수 있습니다:

요청 (Request) 및 응답 (Response) 객체
매퍼 (Mappers)
리포지토리 인터페이스 (Repository interfaces)
유스 케이스 (Use Case) 클래스
컨트롤러 (Controller) 변경 사항
테스트 스캐폴딩 (Test scaffolding)
CRUD 변형
레이어 간 데이터 이동 (Layer-to-layer data shuffling)
기존 패턴을 따르는 코드
구조에 관한 리뷰 코멘트에 대한 수정 사항

이것이 바로 AI가 즉각적으로 유용하다고 느껴지는 바로 그런 종류의 작업입니다.

그리고 분명히 말하자면, 생산성은 향상됩니다.

AI를 사용하는 경험이 적은 개발자는 이전보다 훨씬 더 빠르게 DDD 스타일의 상용구 코드 (boilerplate)를 만들어낼 수 있습니다. 그들은 기존 패턴을 따르고, 반복적인 클래스를 생성하며, 레이어 간에 데이터를 이동시키고, 형식적인 리뷰 코멘트에 높은 속도로 대응할 수 있습니다.

이것은 실제적인 생산성입니다.

하지만 이는 좁은 의미의 생산성입니다.

이것이 반드시 조직이 설계를 개선하기 위해 AI를 사용하는 법을 배웠다는 것을 의미하지는 않습니다. 단지 조직이 기존의 문서 작업 (paperwork) 비용을 더 저렴하게 만들었다는 것만을 의미할 수도 있습니다.

AI가 조직의 구조를 자동으로 바꾸지는 않습니다.

기존의 관료주의에 AI를 투입한다면, AI가 가장 먼저 하는 일은 그 관료주의를 가속화하는 것입니다.

만약 기존 프로세스가 가치를 창출한다면, 그 가속화는 유용합니다.

만약 기존 프로세스가 대부분 형식적인 절차 (ceremony)라면, AI는 그 형식을 가속화합니다.

얕은 결론: "AI는 개발자를 대체하지 못할 것이다"

이 지점에서 많은 조직이 잘못된 결론을 내리게 됩니다.

그들은 기존 프로세스에 AI를 도입하고 다음과 같은 현상을 관찰할 것입니다:

AI를 도입했습니다.
생산성이 향상되었습니다.
하지만 여전히 개발자가 필요합니다.
따라서, AI는 개발자를 대체하지 못할 것입니다.

이것은 합리적으로 들립니다.

하지만 이는 종종 피상적인 관찰에 불과합니다.

더 정확한 진술은 다음과 같을 것입니다:

그들은 AI의 한계를 관찰하고 있는 것이 아닙니다.
그들은 자신들의 조직이 AI를 사용하는 방식의 한계를 관찰하고 있는 것입니다.

만약 AI에게 요청 객체 (request objects), 리포지토리 (repositories), 매퍼 (mappers), 유스 케이스 (use cases), 그리고 테스트 스캐폴딩 (test scaffolding)을 생성하도록만 요구한다면, 당연히 인간은 여전히 필요합니다.

하지만 어떤 종류의 인간이 필요한 것일까요?

강력한 조직에서 필요한 인재는 다음과 같은 일을 할 수 있는 사람들입니다:

비즈니스 경계 (business boundaries) 정의
언어 (language) 명확화
불변량 (invariants) 발견
상태 전이 (state transitions) 설계
고객 가치와 구현 (implementation) 연결
테스트, 타입 (types), 그리고 명세 (specifications)를 통해 AI 출력 제어
시스템의 의미 있는 부분에 대한 소유권 (ownership) 보유

관료적인 조직에서 필요한 인재는 종종 다음과 같은 사람들입니다:

예상된 파일이 존재하는지 확인
유스 케이스 (Use Case)가 올바른 폴더에 있는지 확인
리포지토리 (Repository)가 사용되었는지 확인
매퍼 (Mapper)가 기존 스타일을 따르는지 확인
코드가 형식적인 절차 (ceremony)를 준수하는지 확인

이것은 매우 다른 종류의 필요성입니다.

AI는 개발자가 대체될 수 없음을 증명한 것이 아닙니다.

AI는 단지 이 조직이 개발자들을 기존 프로세스에 가두어 두는 작업에만 AI를 국한시켰음을 증명했을 뿐입니다.

더 날카롭게 말하자면 다음과 같습니다:

AI가 미성숙한 것이 아닙니다.
AI에게 할당된 작업이 미성숙한 것입니다.

생성 비용은 낮아지지만, 의미 확인 비용은 낮아지지 않습니다.

AI 보조 소프트웨어 개발에서 가장 중요한 구분은 다음과 같습니다:

생성 비용 (Generation cost)
의미 확인 비용 (Meaning-checking cost)

AI는 보일러플레이트 (boilerplate)를 생성하는 비용을 획기적으로 낮춥니다.

AI는 레이어 (layers), 클래스 (classes), 인터페이스 (interfaces), 커맨드 객체 (command objects), 쿼리 객체 (query objects), 스키마 클래스 (schema classes), 어댑터 (adapters), 테스트 (tests), 그리고 문서화 (documentation)를 매우 빠르게 생성할 수 있습니다.

하지만 의미론적 정확성 (semantic correctness)을 확인하는 비용은 사라지지 않습니다.

누군가는 여전히 다음과 같이 물어야 합니다:

이 유스케이스 (Use Case)가 실제로 의미 있는 비즈니스 운영인가?
이 엔티티 (Entity)가 정말로 식별성 (identity)을 가지고 있는가?
이 밸류 오브젝트 (Value Object)가 실제로 불변식 (invariant)을 보호하고 있는가?
이 레포지토리 (Repository)는 진정한 추상화인가, 아니면 단순히 이름만 바꾼 DAO인가?
이 경계 객체 (boundary object)가 계약 (contract)을 보호하는가, 아니면 단순히 데이터를 옮겨 다니는 (data shuffling) 역할만 하는가?
이 레이어 (layer)가 변경 가능성 (changeability)을 높이는가, 아니면 파일 개수만 늘리는가?

AI가 생성하는 무의미한 구조가 많아질수록, 인간은 그것을 읽어내는 데 더 많은 시간을 써야 합니다.

따라서 위험은 AI가 의례적인 아키텍처 (ceremonial architecture)를 즉각적으로 제거할 것이라는 점이 아닙니다.

위험은 AI가 의례적인 아키텍처를 더 저렴하게 생산하게 만들어, 결과적으로 그것을 더 흔하게 만들 수 있다는 점입니다.

AI는 의례 (ceremony)의 생성 비용을 제로(0)에 가깝게 밀어붙입니다.

하지만 그 의례를 이해하는 데 드는 비용을 제로로 밀어붙이지는 않습니다.

따라서 무의미한 의례는 더 빠르게 기술 부채 (technical debt)가 됩니다.

이것이 핵심적인 문제입니다.

AI는 관료주의를 파괴하기 전에 오히려 확장할 수 있습니다

AI가 약한 조직을 즉시 파괴하지는 않습니다.

처음에는 오히려 조직을 확장할 수도 있습니다.

그 패턴은 다음과 같습니다:

AI가 더 많은 다층 구조의 코드 (multi-layered code)를 생성합니다.
인간이 더 많은 AI 생성 코드를 검토합니다.
공식적인 검토 규칙이 더 중요해집니다.
기존의 매니저와 테크 리드 (tech leads)가 여전히 필요하게 됩니다.
조직은 인간이 여전히 필수적이라는 결론을 내립니다.

하지만 이것이 인간의 업무가 높은 레버리지 (high-leverage)를 가진다는 것을 증명하지는 않습니다.

그저 조직이 스스로 만들어낸 복잡성을 정리하고 감독하기 위해 이제 인간이 필요해졌음을 증명할 뿐일 수도 있습니다.

이것이 아이러니입니다.

AI는 낭비를 줄일 잠재력을 가지고 있습니다.

하지만 조직이 낭비를 중심으로 구축되어 있다면, AI는 먼저 그 낭비를 더 저렴하게 만듭니다.

AI는 관료주의 (bureaucracy)를 먼저 제거하지 않습니다.

AI는 먼저 관료주의를 더 감당하기 쉽게 (affordable) 만듭니다.

그리고 관료주의가 저렴해지면, 조직은 종종 그것을 유지합니다.

진짜 경쟁은 조직 외부에서 일어납니다

"AI가 개발자를 대체할 것인가?"라는 질문은 너무 좁습니다.

더 중요한 경쟁은 항상 동일한 조직 내부에서만 일어나는 것이 아닙니다.

그것은 서로 다른 조직 형태 간의 경쟁입니다.

AI의 도움을 받는 거대 관료주의적 엔지니어링 조직
vs
AI로 역량이 증폭된 소규모 고책임(High-ownership) 팀

첫 번째 유형은 국소적인 생산성 향상을 경험할 것입니다.

티켓(Tickets) 처리 속도가 빨라집니다.
CRUD 작업이 더 빠르게 완료됩니다.
리뷰 코멘트가 더 빠르게 처리됩니다.
문서화(Documentation)가 더 빠르게 생성됩니다.
경계 객체(Boundary objects)와 매퍼(Mappers)가 더 빠르게 추가됩니다.

내부에서 보기에는 이것이 진보처럼 보입니다.

하지만 외부에서 볼 때, 조직은 여전히 느릴 수 있습니다.

너무 많은 회의
불분명한 책임(Ownership)
형식적인 리뷰
취약한 실행 가능한 명세(Executable specifications)
비즈니스 도메인이 아닌 조직도에 기반한 경계
큰 의미의 변화 없이도 많은 레이어를 건드려야 하는 변경 사항들

두 번째 유형은 AI를 다르게 사용합니다.

소규모 고책임 팀은 시스템을 안전하게 변경할 수 있는 능력을 키우기 위해 AI를 사용합니다.

그들은 다음 사항에 집중합니다:

실행 가능한 명세 (Executable specifications)
강력한 경계 (Strong boundaries)
자동화된 테스트 (Automated tests)
타입 레벨 제약 (Type-level constraints)
런타임 검증 (Runtime validation)
명시적인 상태 전이 (Explicit state transitions)
빠른 피드백 루프 (Fast feedback loops)
명확한 책임 (Clear ownership)
프로덕션에서의 관찰 가능성 (Observability in production)

그들에게 AI는 주로 보일러플레이트(Boilerplate) 생성기가 아닙니다.

AI는 시스템 소유권(System ownership)을 위한 승수(Force multiplier)입니다.

이 차이는 매우 거대합니다.

취약한 조직은 기존의 업무를 더 빠르게 수행하기 위해 AI를 사용합니다.

강력한 조직은 그러한 업무의 필요성 자체를 제거하기 위해 AI를 사용합니다.

원격 근무 저항도 같은 뿌리를 가지고 있습니다

이 패턴은 또 다른 흔한 조직적 행동인 원격 근무에 대한 저항과도 관련이 있습니다.

이것은 단순히 원격 근무가 좋은가 나쁜가의 문제가 아닙니다.

더 깊은 질문은 다음과 같습니다:

조직은 무엇을 신뢰의 근거로 사용하는가?

강력한 엔지니어링 조직은 다음과 같은 것들을 신뢰하는 경향이 있습니다:

명확한 책임 (Clear ownership)
명시적인 목표 (Explicit goals)
검토 가능한 산출물 (Reviewable artifacts)
실행 가능한 테스트 (Executable tests)
문서화된 결정 사항 (Written decisions)
관찰 가능한 프로덕션 동작 (Observable production behavior)
잘 정의된 인터페이스 (Well-defined interfaces)
문서화된 트레이드오프 (Documented trade-offs)

관료주의적 조직은 다음과 같은 것들을 신뢰하는 경향이 있습니다:

사무실에 있는 것
눈에 보이는 것
회의에 참석하는 것
방해받을 수 있는 상태로 있는 것
기존 프로세스를 따르는 것
바빠 보이는 것
비공식적인 감독을 받는 것

첫 번째 유형은 결과와 구조를 통해 관리합니다.

두 번째 유형은 존재감과 절차를 통해 관리합니다.

이것이 바로 DDD 스타일의 관료주의와 원격 근무 반대 문화(anti-remote-work culture)가 종종 결합되는 이유입니다.

원격 근무는 존재감에 의한 관리(management by presence)를 무너뜨립니다.

사무실에서는 사람들이 눈에 보입니다. 누군가 책상에 있는지 확인할 수 있습니다. 회의를 소집할 수 있습니다. 그들을 방해할 수 있습니다. 업무가 진행되고 있다는 느낌을 받을 수 있습니다.

원격 근무는 그러한 가시성(visibility)을 제거합니다.

그렇다면 조직은 산출물(artifacts)을 통해 관리해야 합니다: