이 기사는 DDD 그 자체를 비판하는 것이 아니다.

오히려, DDD의 본래 강점은 AI 시대에도 남는다.

• 복잡한 업무 영역을 이해하는 것
• 경계가 정해진 컨텍스트 (Bounded Context)를 만드는 것
• 용어를 통일하는 것
• 불변 조건 (Invariant)이나 상태 전이 (State Transition)를 발견하는 것
• 변경의 영향 범위를 보이게 하는 것

이것들은 AI로 코드 생성이 빨라질수록 더욱 중요해진다.

왜냐하면, AI에게 올바르게 일을 시키기 위해서는 모호한 업무 지식을 그대로 던져주는 것만으로는 부족하기 때문이다. 업무의 경계, 용어, 제약, 기대되는 동작을 AI가 다룰 수 있는 형태로 명시할 필요가 있다.

그런 의미에서, DDD의 본질은 AI 시대에도 가치가 있다.

다만, 소프트웨어 기업이나 프로덕트 개발 조직에서 자주 보이는 "DDD 같은 것"은 DDD의 본질과는 별개의 것이 되어 있는 경우가 있다.

• Entity를 만든다
• ValueObject를 만든다
• Repository를 끼워 넣는다
• UseCase에 둔다
• DTO로 옮겨 담는다
• Controller를 얇게 만든다
• Mapper를 작성한다

이러한 전술적 DDD (Tactical DDD) 패턴은 본래 업무상의 복잡성을 다루기 위한 도구였을 것이다.

하지만 실제로는 상당한 장면에서 "누구나 똑같은 형태로 작성할 수 있게 하기 위한" 관리 기술이 되어 있다.

즉, 문제는 DDD가 아니다. 문제는 전술적 DDD를 조직 통제의 도구로 사용하는 개발 구조이다.

영어권 표현을 빌리자면, 이는 cargo-cult DDD에 가깝다. 왜 그 형태가 필요한지를 이해하지 못한 채, DDD스러운 구조만을 모방하는 상태이다.

인식을 위한 설계와, 통제를 위한 설계

설계에는 적어도 두 종류가 있다.

• 인식을 위한 설계
• 통제를 위한 설계

DDD 본래의 가치는 전자에 있다.

업무를 이해한다. 용어를 통일한다. 경계를 나눈다. 불변 조건을 발견한다. 상태 전이를 명시한다. 변경의 영향 범위를 보이게 한다.

이것은 소프트웨어를 업무 이해의 도구로 만들기 위한 설계이다.

반면, 조직 내에서 의식화된 DDD는 종종 후자가 된다.

• 누가 작성해도 같은 형태가 된다
• 리뷰에서 형식적으로 지적할 수 있다
• 신입에게도 태스크를 할당하기 쉽다
• 퇴직자가 나와도 인수인계가 쉽다
• 외주나 대량 채용에 견디기 쉽다
• 개인의 재량을 낮추고, 개발자의 교체 가능성을 높인다

즉, 코드 품질을 높이기보다는 조직이 사람을 관리하기 쉽게 만들기 위한 구조가 되어 있다.

이 경우, 아키텍처는 기술이 아니라 조직 통제의 수단이 된다.

날카롭게 말하자면, 다음과 같다.

복잡한 업무를 다루기 위한 설계가 아니라, 복잡한 조직에서 개발자를 교체 가능하게 만들기 위한 설계가 되어 있다.

전술적 DDD가 장부화된다

물론, Repository, DTO, UseCase, ValueObject 등이 항상 나쁜 것은 아니다.

그것들이 업무상의 의미를 가지고 있다면 유효하다.

• ValueObject가 불변 조건을 가두고 있다
• Repository가 영속화의 상세를 숨기고 도메인을 보호하고 있다
• UseCase가 정말로 업무상의 조작 단위를 나타내고 있다
• DTO가 경계를 넘기 위한 명시적인 계약이 되어 있다

이 경우, 그것들은 설계이다.

하지만 현실에서는 그렇지 않은 케이스도 많다.

• 왜 필요한지 설명할 수 없다
• 그저 기존의 디렉토리 구성에 맞춘다
• 리뷰에서 지적받지 않을 형태로 만든다
• Controller에 쓰면 혼나니까 UseCase로 옮긴다
• Entity에서 DTO로 옮겨 담기만 하는 Mapper를 양산한다
• Repository가 단순한 DAO가 되어 있다
• ValueObject가 단순한 래퍼 클래스 (Wrapper Class)가 되어 있다

이 상태에서는 설계가 업무 이해의 도구가 아니다. 그저 기입란이 된다.

코드를 작성한다기보다, 정해진 양식에 정보를 채워 넣고 있을 뿐이다.

• Controller란
• UseCase란
• Repository란
• DTO란
• Mapper란
• Entity란

이것은 아키텍처라기보다, 형식이 정해진 장부(帳票)이다.

AI는 DDD풍의 장부 작업을 고속화한다

AI를 도입하면 이러한 종류의 조직에서도 생산성은 올라간다.

그것은 틀림없다.

예를 들어, 다음과 같은 작업은 AI와 매우 상성이 좋다.

• DTO 만들기
• Mapper 작성하기
• Repository interface 생성하기
• UseCase로 로직 옮기기
• Controller 가볍게 만들기 (Thin Controller)
• 테스트 템플릿 (Scaffold) 작성하기
• Entity에서 Response로 데이터 옮겨 담기
• 기존 패턴을 모방하여 CRUD 추가하기
• 리뷰 지적 사항에 맞춰 계층(Layer) 이동하기

이러한 작업은 AI를 통해 상당히 빨라진다.

특히 프로젝트 내에 이미 대량의 기존 패턴이 존재하는 경우, AI는 이를 모방하는 데 능숙하다. "이 기존 구현과 같은 형태로, 다른 기능에도 똑같이 추가해줘"라고 말하면 상당한 양의 코드가 생성된다.

따라서 관료적인 DDD 조직에서도 AI 활용은 진전된다. 그리고 국소적으로는 확실히 편리해진다.

다만, 그것은 설계 능력이 확장되었다기보다, 기존 구조 안에 있는 다음과 같은 작업들이 빨라졌다는 의미다.

• 템플릿 생성
• 계층 간 데이터 변환 (Data Mapping)
• 기계적인 접착 코드 (Glue Code)
• 기존 패턴의 모방
• 형식적인 리뷰 대응

AI는 조직의 구조를 자동으로 바꿔주지 않는다. 기존 구조에 AI를 도입하면 우선 기존의 작업들이 빨라질 뿐이다.

만약 기존의 작업이 가치를 창출하고 있다면 그것은 좋은 일이다. 하지만 기존의 작업이 의례화된 장부 기입이라면, AI는 우선 그 장부 기입을 고속화할 뿐이다.

"AI로 개발자가 퇴출되지 않는다"라는 관측

이런 종류의 조직에서 AI 활용은 대개 다음과 같은 형태에 머문다.

경험이 적은 저비용 개발자
+ AI
+ DDD풍의 다층 템플릿
...

여기서 오해해서는 안 될 점은, 이 조합만으로도 생산성은 상당히 올라간다는 사실이다.

경험이 적은 개발자라도 AI를 사용하면 기존 패턴에 따른 차분(Diff)을 상당히 빠르게 만들 수 있다. 비슷한 화면을 수평 전개한다. 기존의 계층 구조에 맞춘다. 명명 규칙(Naming)이나 디렉터리 구성을 주변과 맞춘다. 테스트 템플릿을 만든다. 리뷰 코멘트를 반영한다.

이 범위 내에서 AI는 매우 유효하다.

그리고 그 결과로 조직은 다음과 같이 말한다.

• AI를 도입했다
• 생산성은 올라갔다
• 하지만 개발자는 여전히 필요했다
• 그러므로 AI로 개발자가 퇴출되지는 않는다

이는 언뜻 타당해 보인다.

하지만 정확히 말하면 틀렸다.

AI의 한계를 보고 있는 것이 아니라, 그 조직의 AI 활용 능력의 한계를 보고 있는 것이다.

AI가 개발자를 퇴출하지 못한 것이 아니다. AI를 개발자를 퇴출할 수 없는 업무 형태에 가두고 있는 것이다.

AI에게 시키고 있는 일이 애초에 저수준의 기계적 작업에 한정되어 있다.

• 비슷한 구현을 다른 화면으로 수평 전개하고
• 이 처리를 기존 계층 구조에 맞춰 분할하고
• 명명과 디렉터리 구성을 주변과 맞추고
• 리뷰 코멘트의 형식적인 지적 사항만 반영하고
• 테스트의 이름과 템플릿만 맞추는 일

이것은 설계가 아니다. 코드를 작성하는 사무 처리다. 구조화된 장부 기입이다.

그 범위 내에서 AI를 사용하며 "역시 개발자는 필요하네요"라고 말하고 있다면, 그것은 AI의 한계를 말하는 것이 아니다. 그 조직이 AI를 어느 정도의 업무에밖에 사용하지 못하고 있는지를 말하고 있을 뿐이다.

더 짧게 말하자면 이렇다.

AI가 미숙한 것이 아니다. AI에게 맡기고 있는 일이 미숙한 것이다.

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

AI 시대에 중요한 것은 생성 비용(Generation Cost)과 확인 비용(Verification Cost)을 나누어 생각하는 것이다.

AI는 보일러플레이트 (Boilerplate)의 생성 비용을 크게 낮춘다.

• Repository
• DTO
• UseCase
• Mapper
• Command
• Query
• Test scaffold

이러한 계층이나 템플릿은 AI가 생성하기 쉽다.

하지만 생성된 다층 코드의 의미적 정합성을 확인하는 비용은 그리 낮아지지 않는다. 오히려 의미가 희박한 계층이 늘어날수록 비용은 올라간다.

인간은 다음 사항들을 확인해야만 한다.

• 이 UseCase가 정말로 비즈니스의 한 단위인가
• 이 Entity가 정말로 동일성 (Identity)을 갖는가
• 이 ValueObject가 불변 조건 (Invariant)을 캡슐화하고 있는가
• 이 Repository가 영속화의 추상화인가, 아니면 단순한 DAO인가
• 이 DTO 변환이 경계 (Boundary)를 지키고 있는가, 아니면 단순한 데이터 옮겨 담기인가
• 이 계층이 변경 용이성 (Changeability)을 높이고 있는가, 아니면 단순히 파일 수만 늘리고 있는가

AI가 코드를 대량으로 생성할수록 이 확인 작업은 무거워진다.

즉, 다음과 같은 상황이 벌어진다.

AI는 의례(Ritual)의 생성 비용을 제로에 가깝게 만든다.

하지만 의례의 의미를 확인하는 비용은 제로로 만들지 못한다.

따라서 의미가 희박한 의례는 AI 시대에 부채 (Debt)가 된다.

이 점은 상당히 중요하다고 생각한다.

AI에 의해 의미가 희박한 다층 구조는 금방 사라지지 않는다. 오히려 일시적으로는 더 늘어날 것이다.

왜냐하면, 만드는 비용이 저렴해지기 때문이다.

AI는 관료제를 일시적으로 연명시킨다

AI는 약한 조직을 즉시 파괴하지 않는다. 오히려 처음에는 연명시킨다.

기존의 관료적 프로세스에 AI가 도입되면 다음과 같은 일이 일어난다.

• AI가 다층 코드(Multi-layered code)를 대량 생성한다
• 인간이 그것을 리뷰한다
• 형식 체크(Format check)의 양이 늘어난다
• 리뷰 문화가 온존된다
• 기존의 관리직이나 리드 엔지니어의 업무가 남는다
• "역시 인간은 필요하다"라고 말한다

이것은 인간의 지적 가치가 증명되었다는 뜻이 아니다.

자신들이 만든 복잡성의 뒷수습을 위해 인간이 필요해졌을 뿐이다.

이 점은 상당히 아이러니다.

AI는 본래 불필요한 작업을 줄일 가능성을 가지고 있다. 하지만 조직이 그 불필요한 작업을 전제로 설계되어 있다면, AI는 우선 그 불필요함을 가속화한다.

그 결과, 불필요한 구조는 일시적으로 강화된다.

AI에 의해 불필요함이 사라지는 것이 아니라,

AI에 의해 불필요함의 비용이 저렴해지는

단계가 먼저 찾아온다.

그리고 불필요함의 비용이 저렴해지면, 조직은 그것을 온존하기 쉬워진다.

리모트 워크를 싫어하는 조직과의 상성

이 이야기는 단순히 "리모트 워크(Remote work)에 대한 이해가 있느냐 없느냐"의 문제가 아니다.

조직이 무엇을 신뢰의 근거로 삼고 있는가의 문제이다.

강한 개발 조직은 신뢰의 근거를 다음과 같이 둔다.

• 명확한 소유 범위 (Ownership)
• 실행 가능한 테스트 (Executable test)
• 사양의 명문화 (Specification)
• 리뷰 가능한 산출물 (Reviewable artifact)
• 비동기로 읽을 수 있는 설계 판단 (Asynchronous design decision)
• 변경의 영향 범위 (Impact scope)
• 운영 환경에서의 관측 가능성 (Observability)

반면, 관료적인 개발 조직은 신뢰의 근거를 다음과 같이 두는 경향이 있다.

• 출근해 있다
• 자리에 있다
• 회의에 참석하고 있다
• 즉시 말을 걸 수 있다
• 상사가 상태를 확인할 수 있다
• 리뷰에서 형식을 지키고 있다
• 기존의 방식에서 벗어나지 않는다

즉, 전자는 성과와 구조로 관리한다. 후자는 존재와 절차로 관리한다.

그렇기에 DDD풍의 관료제와 리모트 워크 기피는 상성이 매우 좋다.

이유는 단순하다. 리모트 워크는 존재에 의한 관리를 파괴하기 때문이다.

사무실에 있으면 적어도 사람은 보인다. 자리에 있는지 알 수 있다. 회의에 참석했는지 알 수 있다. 곤란해 보이면 말을 걸 수 있다. 진척이 모호해도 "어떻게든 일하고 있는 느낌"은 관측할 수 있다.

하지만 리모트 워크에서는 그것이 사라진다.

그러면 조직은 산출물, 소유 범위, 사양, 테스트, 리뷰, 문서, 의사결정 로그로 관리할 수밖에 없게 된다.

이는 강한 개발 조직에게는 자연스러운 일이다.

• 누가 무엇을 소유하고 있는가
• 무엇이 완료 조건인가
• 어떤 사양이 정답인가
• 어떤 테스트가 불변 조건(Invariant)을 지키고 있는가
• 어떤 변경이 어느 경계(Boundary)에 영향을 주는가

이것들이 명확하다면 리모트 환경에서도 큰 문제는 없다. 오히려 비동기로 진행하기 쉬워진다.

하지만 관료적인 개발 조직은 다르다.

• 소유자가 모호함
• 사양이 모호함
• 완료 조건이 모호함
• 테스트가 취약함
• 리뷰 기준이 형식적임
• 의사결정이 회의나 구두로 폐쇄되어 있음
• 경계가 업무가 아닌 조직도로 나뉘어 있음

이 상태에서 리모트 워크를 하게 되면 관리자는 불안해진다.

왜냐하면, 원래 성과를 관리했던 것이 아니라 사람이 관리 가능한 것처럼 보이는 상태를 관리해 왔기 때문이다.

여기서 자주 등장하는 말이 "커뮤니케이션"이다.

• 리모트 워크를 하면 커뮤니케이션이 줄어든다
• 리모트 워크를 하면 일체감이 없어진다
• 리모트 워크를 하면 주니어(Young talent)가 성장하지 못한다
• 리모트 워크를 하면 잡담이 없어진다
• 리모트 워크를 하면 진척이 보이지 않는다

이것들은 일부 맞다.

하지만 전부 본질적인 것은 아니다.

많은 경우 "커뮤니케이션"이라고 불리는 것의 실체는 실제로는 다음과 같다.

• 동기적으로 끼어들 수 있는 것
• 모호한 지시를 구두로 보완하는 것
• 책임 범위의 모호함을 대화로 메우는 것
• 설계 판단을 기록하지 않고 끝내는 것
• 성과가 아니라 분위기로 진척을 파악하는 것

즉, 리모트 워크가 파괴하고 있는 것은 커뮤니케이션이 아니다.

모호함을 모호한 채로 운용하는 능력이다.

이는 DDD풍의 관료제와도 매우 닮아 있다.

DDD풍의 다층 아키텍처(Multi-layered architecture)는 업무 이해를 깊게 하기 위해서가 아니라, 개발자를 교체 가능하게 만들기 위해 사용되는 경우가 있다.

리모트 워크를 싫어하는 조직에서 사무실 또한 협업의 장이라기보다, 개발자를 관리 가능하게 만들기 위한 장치로 기능하는 경우가 있다.

• 아키텍처로 코드를 관리 가능하게 만든다
• 사무실로 사람을 관리 가능하게 만든다
• 회의로 책임의 모호함을 흡수한다
• 리뷰로 형식적인 통일을 유지한다

이 네 가지는 같은 방향을 향하고 있다.

그것은 강력한 소유권 (Ownership)을 가진 소수의 개발자가 자율적으로 가치를 창출하는 구조가 아니다. 교체 가능한 개발자를 형식과 장소에 의해 관리하는 구조이다.

그렇기에 이런 조직에서는 AI 활용도 리모트 워크 (Remote Work)도 똑같이 왜곡된다.

AI는 설계 능력을 증폭하기 위해서가 아니라, DDD풍의 장부 작업 (帳票作業)을 빠르게 하기 위해 사용된다. 리모트 워크는 성과를 비동기적으로 내는 업무 방식이 아니라, 관리자로부터 보이지 않는 위험한 상태로 취급된다.

둘 다 뿌리는 같다.

• 소유권을 믿지 않는다
• 결과물로 관리할 수 없다
• 검증 가능한 사양 (Specification)이 없다
• 비동기 의사결정에 서툴다
• 사람을 교체 가능한 작업자로 취급한다

이 구조에서 출근은 단순한 업무 장소가 아니다. 조직 통제의 인터페이스 (Interface)가 된다.

바꿔 말하면 이렇다.

리모트 워크를 싫어하는 이유가 오피스의 가치를 믿기 때문이라고 단정할 수는 없다.

성과로 관리하는 메커니즘을 가지고 있지 않기에, 존재로 관리할 수밖에 없는 것이다.

물론 모든 출근 방침이 나쁜 것은 아니다.

온보딩 (Onboarding), 기밀 정보, 하드웨어, 고객 대응, 긴급 대응, 팀 형성 등 대면이 유효한 상황은 있다.

문제는 대면의 필요성을 구체적으로 설명하지 못한 채, "역시 출근이 중요하다"라고 말하는 경우이다.

그 경우, 출근은 협업을 위해서가 아니라 관리 불안을 낮추기 위해 사용되고 있다.

그리고 그러한 조직일수록 AI에 대해서도 비슷한 결론을 내린다.

• AI는 편리하지만, 인간은 아직 필요하다
• 리모트는 편리하지만, 역시 출근은 필요하다

둘 다 어느 정도는 맞다.

하지만 더 정확하게는 이렇다.

• AI를 설계 능력의 증폭에 사용하지 못하고 있기 때문에, 인간의 장부 작업이 남아 있다
• 성과와 소유권으로 관리하지 못하고 있기 때문에, 출근을 통한 가시성이 필요해지고 있다

AI와 리모트 워크는 둘 다 조직의 약점을 드러낸다.

AI는 의미 없는 작업과 의미 있는 설계를 분리한다.

리모트 워크는 성과로 관리할 수 있는 조직과 존재로 관리하는 조직을 분리한다.

따라서 DDD풍의 관료제를 선호하는 조직이 리모트 워크를 싫어하기 쉬운 것은 자연스러운 일이다.

둘 다 본질적으로는 같은 불안에 대한 반응이기 때문이다.

• 개발자를 신뢰할 수 없다
• 소유권을 넘겨줄 수 없다
• 결과물로 판단할 수 없다
• 구조로 검증할 수 없다
• 그래서 형식과 장소로 관리한다

이런 의미에서 오피스 회귀와 DDD풍 관료제는 상당히 유사한 현상이다.

한쪽은 코드상의 통제, 다른 한쪽은 업무 방식상의 통제다.

둘 다 소수 인원의 높은 소유권을 가진 팀과는 상성이 나쁘다.

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

"AI로 인해 개발자가 불필요해질 것인가"라는 질문은 다소 성급하다고 생각한다.

더 중요한 것은 동일한 조직 내에서 사람이 AI로 대체되느냐가 아니다. 진짜 경쟁은 조직 외부에서 일어난다.

AI로 보조되는 대규모 관료적 개발 조직
vs
AI로 증폭된 소수 인원의 고소유권 팀

이 승부가 된다.

전자는 내부적으로 생산성이 올라간 것처럼 보인다.

• 티켓 (Ticket) 소화가 빨라진다
• CRUD 구현이 빨라진다
• 리뷰 코멘트 대응이 빨라진다
• 문서 작성이 빨라진다
• DTO나 Mapper 추가가 빨라진다

하지만 후자의 입장에서 보면 여전히 무겁다.

• 회의가 많다
• 소유자가 모호하다
• 리뷰가 형식적이다
• 사양이 실행 가능하지 않다
• 경계가 업무가 아닌 조직도로 나뉘어 있다
• 변경할 때마다 다층 코드를 가로질러야 한다

소수 인원으로 강력한 소유권을 가진 팀은 AI를 다른 방식으로 사용한다.

• 사양을 실행 가능하게 만든다
• 경계마다 변경을 가둔다
• 테스트로 불변 조건 (Invariant)을 고정한다
• 타입을 통해 부정 상태를 표현 불가능하게 만든다
• 상태 전이 (State Transition)를 명시한다
• 작은 소유 범위를 AI를 통해 넓게 움직인다
• 코드 생성보다 검증과 변경 속도를 높인다

여기서 AI는 장부 작업의 보조가 아니다. 시스템 변경 능력의 증폭 장치이다.

이 차이는 매우 크다.

약한 조직은 AI를 사용하여 기존의 작업을 빠르게 만든다.

강한 조직은 AI를 사용하여 기존의 작업 그 자체를 없앤다.

AI 시대에 남는 DDD

DDD가 죽는 것은 아니다.

죽는 것은 DDD를 표방하는 관료제이다.

AI 시대에 남는 것은 다음과 같은 것들이라고 생각한다.

• 업무 경계 (Bounded Context)
• 유비쿼터스 언어 (Ubiquitous Language)
• 불변 조건 (Invariant)
• 상태 전이 (State Transition)
• 책임을 가진 소유자
• 실행 가능한 테스트
• 타입 · 제약 · 검증
• 변경 시 깨지는 지점에 대한 가시성

반대로 다음과 같은 것들은 가치가 떨어진다.

• Repository를 경유할 것
• DTO로 옮겨 담을 것
• UseCase에 둘 것
• Controller를 얇게 만들 것
• 기존 디렉터리 구조에 맞출 것
• 리뷰에서 지적받지 않는 형태로 만들 것

물론, 이러한 패턴들이 항상 불필요하다는 뜻은 아니다. Repository가 필요한 상황이 있다. DTO가 필요한 상황도 있다. UseCase 계층이 유효한 상황도 있다.

문제는 그것이 비즈니스상의 복잡성 (Complexity)을 표현하고 있는가, 아니면 단순한 조직상의 안심 장치로 전락했는가 하는 점이다.

설계로서 의미가 있다면 남는다. 조직 통제로서의 의미밖에 없다면, AI에 의해 그 가치는 하락한다.

필요한 것은 의식이 아니라 방파제

AI 시대의 설계에서 중요한 것은 인간이 모든 코드를 읽는 것이 아니다. 그것은 이미 현실적이지 않게 되어가고 있다.

중요한 것은 AI가 변경을 수행하더라도, 문제가 생겼을 때 즉시 알 수 있어야 한다는 점이다.

• 잘못된 상태를 만들 수 없음
• 부적절한 전이 (Transition)를 통과할 수 없음
• 경계를 넘을 때 변환 및 검증됨
• 사양 (Specification) 위반이 테스트에서 실패함
• 타입 (Type)으로 부적절한 값을 표현할 수 없음
• 변경의 영향 범위가 한정되어 있음

즉, 코드 리뷰에서 인간이 힘겹게 지켜내는 설계에서, 타입·제약·테스트·실행 가능한 사양으로 지켜내는 설계로 전환해야 한다.

인간이 리뷰로 지키는 설계
↓
테스트·타입·제약·사양으로 지키는 설계

이러한 전환을 하지 못하는 조직에서 AI는 단순한 장부 기입 요원이 된다.

• AI가 DTO를 만든다
• AI가 Mapper를 작성한다
• AI가 UseCase로 옮긴다
• 인간이 그것을 확인한다
• 그리고 "AI는 편리하지만, 아직 개발자는 필요하네요"라고 말한다

하지만 그것은 AI 시대의 본질이 아니다.

AI 시대에 필요한 것은 DDD의 의식이 아니다.

AI가 생성한 변경 사항을 안전하게 받아내는, 비즈니스 의미의 방파제다.

• 경계 (Boundary)
• 언어 (Language)
• 불변 조건 (Invariant)
• 상태 전이 (State Transition)
• 검증 가능한 사양 (Verifiable Specification)

이러한 것들을 갖추지 못한 다층 아키텍처 (Multi-layered Architecture)는 그저 조직 통제의 잔해일 뿐이다.

현시점의 전망

조만간 개발자가 완전히 불필요해지는 일은 일어나지 않을 것이다. 오히려 많은 조직에서 AI에 의해 개발자의 작업은 당분간 유지될 것이다.

다만, 그 유지가 반드시 강함을 의미하지는 않는다.

경험이 적은 저비용 개발자에게 AI를 활용해 DDD풍의 템플릿 생성이나 계층 간 데이터 채우기를 돕게 한다. 그럼에도 국소적인 생산성은 극적으로 올라간다. 그래서 조직은 "AI로 개발자가 배제되지는 않는다. 편리해지긴 했지만 아직 멀었다"라고 말한다.

하지만 그러한 관찰은 얕다.

그들이 보고 있는 것은 AI의 한계가 아니다. 자신들의 조직이 AI를 저수준의 기계적 작업에밖에 사용할 수 없다는 한계다.

진정으로 파괴적인 것은 경험이 적은 개발자가 AI로 DDD풍의 장부 작업을 빠르게 하는 것이 아니다.

진정으로 파괴적인 것은 높은 오너십 (Ownership)을 가진 개발자가 AI를 통해 조직 구조 그 자체를 가볍게 만드는 것이다.

DDD는 죽지 않는다.

DDD풍의 관료주의가 죽을 뿐이다.

AI 시대에 가장 먼저 일어나는 일은 개발자의 완전한 배제가 아니다. 무의미한 조직 구조의 연명이다.

다만, 연명된 조직은 AI로 증폭된 소수의 고오너십 팀에게 외부로부터 패배하게 된다.

Discussion