소프트웨어 설계 사상의 역사적 흐름 (with. AI)

2024 / 12 / 12

1장: 객체지향 개념의 태동과 초기 사상

1.1 복잡성 증가와 새로운 패러다임의 필요성

1950~60년대에 이르러 소프트웨어는 다양한 산업·과학 분야로 확산되며 점차 대규모화되고 복잡해지고 있었다. 과학 계산, 기업 정보 처리, 시뮬레이션 등 새로운 요구사항에 맞추어 프로그램 규모가 커질수록, 기존의 절차적(Procedural) 프로그래밍 패러다임은 유지보수나 요구사항 변화 대응에 한계를 노출했다. 단순히 명령어를 순서대로 나열하는 방식만으로는 복잡한 문제를 효율적으로 관리하기 어려웠다.

이런 상황에서 소프트웨어 공학자들은 프로그램을 현실 세계의 개념에 가까운 단위로 추상화하고, 이를 통해 시스템 복잡성을 제어하려는 시도를 시작했다. 문제 영역(도메인)의 개체들을 코드 구조로 자연스럽게 매핑하고, 데이터와 로직을 밀접하게 결합한 새로운 추상화 방식—바로 객체 개념이 주목받기 시작했다.

1.2 Simula: 객체 개념의 원류

객체지향 사상의 기원을 논할 때, 1960년대 중반 노르웨이 컴퓨팅 센터(NCC)의 올레-요한 달(Ole-Johan Dahl)과 크리스텐 뉘고르드(Kristen Nygaard)가 개발한 Simula 언어는 빼놓을 수 없는 중요한 출발점이다. 특히 Simula 67은 클래스(Class) 개념을 도입하여 프로그램 내에서 현실 세계의 개념을 추상 단위로 정의하고, 이를 바탕으로 인스턴스(객체)를 생성함으로써 시뮬레이션을 수행할 수 있게 했다.

이로써 데이터와 행위를 하나의 단위로 묶는 추상화와 캡슐화의 아이디어가 싹텄다. 비록 당대에는 산업적 주목을 크게 받지 못했지만, Simula는 이후 객체지향 언어 발전의 토대가 되며, 도메인 중심 사고의 가능성을 열어주었다.

참고 자료:

  • Dahl, O.-J., & Nygaard, K. (1966). SIMULA—an ALGOL-based simulation language. Communications of the ACM.
  • Nygaard, K., & Dahl, O.-J. (1978). The development of the SIMULA languages. History of Programming Languages, ACM.

1.3 Alan Kay와 Smalltalk: 객체지향 철학의 정립

Simula에서 탄생한 객체 개념은 미국 Xerox PARC(Palo Alto Research Center)에서 Alan Kay와 동료들이 1970년대 개발한 Smalltalk 언어를 통해 철학적 깊이를 더했다. Kay는 객체지향을 단순한 언어 기법이 아닌 사고방식으로 정의했으며, 시스템을 자율적인 객체들이 메시지를 통해 협력하는 유기체로 바라보았다. 이 관점에서 객체는 내부 구현을 감추고 메시지로만 상호작용하는 분산된 지능과 상호작용의 단위였다.

Kay의 비전과 시대적 맥락

Alan Kay가 그린 큰 그림은 개인용 컴퓨팅과 교육적 활용, 직관적 상호작용에 대한 비전이었다. 그는 “Dynabook”이라는 휴대 가능한 개인용 컴퓨터 개념을 통해 아이나 성인이 직관적으로 컴퓨터와 상호작용하면서 학습하고 창조할 수 있는 미래를 상상했다. 이 비전에서 객체지향은 단순히 코드를 구조화하는 방법이 아니라, 인간 친화적이고 학습 친화적인 컴퓨팅 환경을 구현하는 핵심 추상화 원리였다.

Xerox PARC는 당시 마우스, 고해상도 디스플레이, 그래픽 사용자 인터페이스(GUI), WYSIWYG 편집기 등을 실험하며, 모든 사용자가 그래픽 모니터와 마우스를 사용하게 될 것이라는 가정을 바탕으로 혁신적 기술을 탐구하고 있었다. Smalltalk 환경은 “모든 것이 객체”인 세계에서 이러한 상호작용 방식을 구현하기에 이상적이었다. 여기서 GUI는 객체지향 철학을 직관적 시각 인터페이스 형태로 실현하는데 중요한 역할을 했으나, GUI 그 자체가 객체지향의 목표는 아니었다. 오히려 객체지향 사고를 통해 상호작용적, 교육적, 개인화된 컴퓨팅 비전을 구현하는 과정에서 GUI는 자연스럽게 부각된 도구였다.

  • 당시 Xerox PARC 의 연구 내용들에 관심이 많았던 스티브 잡스가 직접 객체지향에 대해 설명했던 자료도 존재한다.
  • 잡스는 애플을 떠난 뒤 넥스트사를 세워 세계 최초의 객체지향 운영체제인 ‘넥스트 스텝’을 개발한 이력도 있다. 
  • 넥스트 스텝은 Objective-C 로 개발되었고, Rhapsody 를 거쳐 현재 우리가 널리 사용하는 OS X 으로 발전되었다.

Smalltalk의 기여

Smalltalk는 메시지 패싱, 동적 바인딩, 통합 개발 환경 등 객체지향 패러다임의 핵심 요소를 순수하고 일관되게 구현한 언어로 꼽힌다. 이후 C++, Objective-C, Java, C# 등 수많은 언어들이 Smalltalk의 아이디어를 받아들이고 변용하면서 객체지향은 소프트웨어 개발의 주류 패러다임으로 성장했다.

참고 자료:

  • Kay, A. C. (1993). The Early History of Smalltalk. ACM SIGPLAN Notices.
  • Ingalls, D. H. H. (1981). Design principles behind Smalltalk. BYTE.

1.4 초기 객체지향 사상의 본질

초기 객체지향 사상은 단순한 기술적 개선을 넘어 다음과 같은 본질적인 변화를 예고했다.

  • 추상화와 캡슐화: 객체 단위로 데이터와 행위를 묶고, 내부 구현을 은닉함으로써 복잡성을 통제하고 재사용성을 높였다.
  • 메시지 중심 상호작용: 객체가 메시지를 주고받으며 협력하는 모델은, 시스템 유연성과 변경 용이성을 제고한다.
  • 인간 친화적 모델링: 현실 세계 개념을 코드로 투영해 문제를 더 자연스럽게 표현하고, 직관적인 시스템 이해를 지원한다.

이러한 특징은 소프트웨어 개발을 기술적 활동에서 도메인 이해를 통한 복잡성 제어 활동으로 인식하는 큰 전환점이었다.

1.5 이후를 향한 흐름: 도메인 모델링과 DDD로의 진화

객체지향 개념만으로 대규모 엔터프라이즈 도메인 복잡성을 모두 해결할 수는 없었다. 1980~90년대 Grady Booch, James Rumbaugh, Ivar Jacobson 등이 객체지향 분석·설계(OOAD)와 UML(Unified Modeling Language)을 발전시켜 복잡한 도메인을 구조적으로 모델링할 수 있는 방법론을 마련했다. 이로써 도메인 모델링 개념이 산업계 전반에 확산되었고, 궁극적으로 Eric Evans가 2003년 제안한 DDD(Domain-Driven Design)가 도메인 지식 중심의 전략적 설계 철학으로 결실을 맺었다.

2장: 객체지향 분석·설계 방법론의 발전과 UML의 탄생

2.1 서론: 언어에서 방법론으로

1장에서 우리는 객체지향 프로그래밍(OOP)의 태동 과정을 살펴보았다. Simula와 Smalltalk는 객체지향 사고방식을 언어 차원에서 구현하고 실험하는 장을 열었다. 그러나 산업 현장에서 규모가 큰 소프트웨어를 개발할 때는 단순히 언어적 특성만으로 복잡한 도메인을 효과적으로 관리하기 어려웠다. 즉, “어떻게 객체를 찾고, 어떻게 이들을 협력하도록 조직화하며, 어떻게 요구사항을 객체 모델로 전환할 것인가?”라는 더 상위 수준의 문제에 답할 필요가 있었다.

1980년대 후반부터 1990년대 중반까지 산업계와 학계는 객체지향을 분석(Analysis) 및 설계(Design) 단계에 본격적으로 적용하기 시작했다. 이 시기는 다양한 객체지향 분석·설계 방법론(OOAD Methodologies)이 등장하고 경쟁한 ‘방법론의 격동기’였다. 이러한 방법론들은 점진적으로 통합되어 마침내 UML(Unified Modeling Language) 이라는 산업 표준 시각화 언어로 결실을 맺게 된다.

2.2 객체지향 분석·설계 방법론의 부상

2.2.1 Booch 방법론 (Grady Booch)

Grady Booch는 1980년대 후반부터 객체지향 개발 기법을 정리하여, 1991년 출간한 저서 Object-Oriented Design with Applications에서 객체지향 분석·설계 접근법을 제시했다. Booch는 클래스와 객체를 식별하고, 시스템을 오브젝트 단위로 구조화하는 방식을 정립했다. 또한 그가 고안한 그래픽 표기법과 설계 아이콘은 나중에 UML 개발 시 참고 대상이 되었다.

Booch 방법론의 특징은 다음과 같다.

  • 풍부한 표현 요소: 클래스, 객체, 관계를 나타내는 기호들과 아키텍처를 계층적으로 표현하기 위한 풍부한 노테이션 활용.
  • 반복적·점진적 접근: 대규모 시스템을 한 번에 완성하기보다, 설계와 구현을 반복하고 개선하는 개발 사이클을 강조.

참고 자료:

  • Booch, G. (1991). Object-Oriented Design with Applications. Benjamin/Cummings.

2.2.2 OMT(객체모델링기법) - James Rumbaugh

James Rumbaugh와 그의 동료들이 제안한 OMT(Object Modeling Technique)는 분석 단계에서 도메인의 개념적 모델을 구축하기 위한 시스템적 접근을 제공했다. OMT는 객체 모델, 동적 모델, 기능 모델의 세 가지 관점을 통해 문제를 구조화했다. 특히 객체 모델은 클래스, 객체, 속성, 관계 등 도메인의 정적 구조를 잘 드러내도록 설계되어 도메인 중심 사고를 장려했다.

Rumbaugh의 방법론은 엔지니어들이 복잡한 문제 영역을 계층적이고 정돈된 객체 다이어그램으로 표현하도록 함으로써, 요구사항을 명확히 하고 나중에 설계 및 구현으로 연결하기 쉽게 했다.

참고 자료:

  • Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). Object-Oriented Modeling and Design. Prentice Hall.

2.2.3 OOSE(객체지향 소프트웨어 엔지니어링) - Ivar Jacobson

Ivar Jacobson은 1992년 저서 Object-Oriented Software Engineering: A Use Case Driven Approach를 통해 “Use Case(유즈케이스)” 개념을 소프트웨어 분석의 중심 기법으로 제안했다. 유즈케이스는 사용자(또는 외부 행위자) 관점에서 시스템의 기능적 요구사항을 표현하는 방식으로, 객체 모델을 구축하기 전 사용자 목표와 시스템 반응을 명확하게 기술할 수 있었다.

OOSE 방법론에서 유즈케이스는 객체지향 설계로 이어지는 가교 역할을 했으며, 개발팀이 도메인의 요구사항을 이해하고 적절한 객체들을 식별하는 실용적 수단을 제공했다.

참고 자료:

  • Jacobson, I., Christerson, M., Jonsson, P., & Övergaard, G. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley.

2.3 방법론 통합과 UML의 형성 배경

1990년대 초중반, 객체지향 분석·설계 방법론 분야는 Booch, OMT, OOSE 외에도 여러 경쟁 방법론들이 난립한 상태였다. 산업계에서는 어떤 방법론을 채택해야 할지 혼란스러워했고, 상호 호환성도 낮았다. 이때 세 명의 거장인 Booch, Rumbaugh, Jacobson—훗날 “Three Amigos”라 불리게 된 이들은 각각의 방법론 장점을 결합하는 통일된 표준 모델링 언어를 만드는 작업에 착수했다.

Rational Software사(나중에 IBM에 인수)는 세 인물을 영입하여 각 방법론의 베스트 프랙티스를 통합하고, 산업 표준으로 삼을 만한 언어를 개발하도록 지원했다. 이 과정에서 “통일된” 모델링 언어, 즉 UML의 초기 버전들이 제안되었다.

2.4 UML(Unified Modeling Language)의 탄생과 표준화

2.4.1 UML의 목표와 특징

UML은 1997년 OMG(Object Management Group) 에 의해 공식 표준으로 채택되며 객체지향 분석·설계 커뮤니티의 표준 언어가 되었다. UML의 목표는 다음과 같이 요약할 수 있다.

  1. 공통 시각화 언어 제공: 도메인 모델, 설계, 아키텍처를 표현하기 위한 일관된 그래픽 노테이션 세트를 제공.
  2. 방법론 중립성: UML 자체는 특정 개발 프로세스나 방법론에 종속되지 않고, 다양한 객체지향 방법론을 지원할 수 있는 범용 모델링 언어로 설계됨.
  3. 표준화된 의미론: 클래스 다이어그램, 시퀀스 다이어그램, 유즈케이스 다이어그램 등 여러 유형의 다이어그램을 통해 도메인 개념, 객체 상호작용, 시스템 동작 흐름을 정형화된 방식으로 표현.

2.4.2 UML의 주요 다이어그램과 도메인 모델링

UML의 핵심 다이어그램 중 클래스 다이어그램(Class Diagram) 은 도메인을 객체로 추상화하는 데 핵심적인 역할을 한다. 클래스, 속성, 연관관계, 일반화(상속), 집합(합성, 집약) 등의 요소를 표준화된 기호로 표현함으로써, 도메인 모델은 누구나 이해할 수 있는 형태로 문서화될 수 있었다.

아울러 유즈케이스 다이어그램(Use Case Diagram) 은 Jacobson의 유즈케이스 개념을 UML 표준의 일부로 정착시킴으로써 요구사항 분석과 도메인 이해를 지원했다. 이외에도 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 스테이트 머신 다이어그램, 액티비티 다이어그램 등 다양한 UML 다이어그램이 시스템 동작과 객체 상호작용을 다각적으로 표현할 수 있도록 했다.

참고 자료:

  • Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley.
  • OMG 공식 표준 문서: UML Specification (초기판은 1997년, 이후 버전 업데이트)

2.4.3 산업계 수용과 도구 지원

UML이 OMG 표준으로 채택되자, 수많은 CASE(Computer-Aided Software Engineering) 도구 업체들이 UML 지원을 내세우며 모델링 툴을 출시했다. Rational Rose, TogetherJ, Enterprise Architect 등이 대표적인 예다. 이 도구들은 개발팀이 도메인 모델과 설계 산출물을 일관된 방식으로 유지, 공유, 버전관리하도록 도왔다.

산업계는 UML을 통해 서로 다른 팀, 다른 조직 간에도 공통된 모델 표현 방식을 갖추게 됐다. 이는 대규모 시스템 개발에서 의사소통 비용을 줄이고, 도메인 요구사항을 명료하게 공유하며, 재사용 가능한 설계 자산을 만드는 기반을 마련했다.

2.5 UML 이후: 도메인 모델링과 객체지향의 융합

UML의 정착은 객체지향 사상을 단순한 언어 기능 차원을 넘어, 도메인 분석, 시스템 아키텍처 설계, 구현 전 과정에 녹아들게 하는 데 중요한 이정표였다. 이제 개발자들은 “도메인 모델”을 UML 클래스 다이어그램 등으로 명확히 표현하고, 이를 코드 구현과 연계하는 체계적인 프로세스를 갖추게 되었다.

하지만 UML과 OOAD의 확산에도 불구하고, 여전히 한 가지 문제가 남아 있었다. UML 다이어그램이 아무리 정교해도, 이것이 실제 비즈니스 도메인의 지식과 요구사항 변화를 지속적으로 반영하고 개선하는 메커니즘으로 작동하지 않으면 무용지물이 되는 경우가 많았다. 즉, 단순히 모델링 표기법과 프로세스가 정교해지는 것만으로는 실제 도메인 복잡성을 근본적으로 해결하기 어렵다는 인식이 서서히 확산되었다.

이러한 문제 의식은 2000년대 초반 Domain-Driven Design(DDD) 라는 새로운 패러다임이 부상하는 씨앗이 되었다. DDD는 도메인 모델을 설계의 중심에 두고, 모델 자체를 비즈니스 전문가와 개발자가 공유하는 “언어”로 발전시키는 접근을 통해 도메인 복잡성을 해결하고자 한다.

3장: 도메인 모델링의 재발견과 도메인 주도 설계(DDD)의 탄생

3.1 도메인 모델링의 가치 재조명

2장에서 살펴보았듯, 1990년대 후반까지 객체지향 분석·설계와 UML은 소프트웨어 엔지니어링 커뮤니티에 널리 확산되었다. 이로써 개발자들은 도메인을 시각적으로 모델링하고, 아키텍처적으로 체계화하는 수단을 갖추게 되었다. 하지만 대규모 엔터프라이즈 시스템 개발 현장에서는 단지 UML 다이어그램과 객체지향 원칙만으로 복잡한 도메인 문제를 완전히 해결하기는 어려웠다.

1990년대 말~2000년대 초, 기업 시스템(Enterprise Application) 환경은 그 규모와 복잡성이 급증하고 있었다. 전자상거래, 온라인 뱅킹, 글로벌 공급망 관리, 대형 ERP와 CRM 솔루션 등은 수많은 비즈니스 규칙, 프로세스, 예외상황을 다루어야 했고, 이들 요구사항은 빈번하게 바뀌었다. 기술 스택 또한 점차 다양해져 데이터베이스, 메인프레임, 분산 객체, 웹 프레임워크, 메시지 큐 등 복합적 인프라를 다루는 일이 일상화되었다.

이러한 환경에서 “도메인 모델링”은 더 이상 단순한 설계 단계 산출물이 아닌, 개발 전 과정에서 유지·진화해야 할 지식의 집합으로 간주될 필요가 있었다. 도메인 모델이 현장의 비즈니스 로직을 제대로 반영하지 못하면, 시스템은 요구사항 변화에 취약하고 유지보수 비용이 극도로 커지며, stakeholder(이해관계자) 간 의사소통 문제가 심화되었다.

3.2 엔터프라이즈 애플리케이션 패턴과 아키텍처 사상가들

이러한 문제의식을 반영하여, 2000년대 초반 몇몇 사상가들은 엔터프라이즈 개발을 체계화하기 위한 패턴과 원칙을 정리하기 시작했다. 그중 대표적인 인물이 Martin Fowler이다. Fowler는 2002년 출간한 Patterns of Enterprise Application Architecture(EAA) 에서 레이어드 아키텍처, 도메인 모델 패턴, 데이터 매퍼, 트랜잭션 스크립트, 서비스 레이어 등의 개념을 정리했다. 이 패턴들은 엔터프라이즈 애플리케이션 구현의 복잡한 인프라 문제를 해결하는 데 유용했지만, 정작 비즈니스 도메인 자체를 깊이 파고드는 접근에 대해서는 상대적으로 간략한 언급에 그쳤다.

참고 자료:

  • Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.

Fowler의 패턴 모음집은 인프라와 아키텍처 층위에서 문제를 해결하는 다양한 모범 사례를 제시했지만, “도메인 로직을 어떻게 더 효과적으로 다룰 것인가?”라는 근본적인 질문에는 한 단계 더 진전된 해답이 필요했다. 엔터프라이즈 개발자들은 여전히 기술적 난제뿐만 아니라, 비즈니스 규칙 이해 및 변경 관리에 대한 어려움과 씨름하고 있었다.

3.3 Eric Evans와 DDD의 등장 (2003년)

이런 상황에서 Eric Evans가 2003년 출간한 Domain-Driven Design: Tackling Complexity in the Heart of Software는 도메인 모델링 접근을 전면적으로 재조명했다. Evans는 소프트웨어 개발의 핵심 문제를 “도메인 복잡성”으로 규정하고, 이를 제대로 다루기 위한 전략적·전술적 패턴을 체계적으로 정리했다.

DDD(Domain-Driven Design)는 단순히 새로운 방법론이 아니라, 도메인 지식을 탐구하고, 모델을 통해 그 지식을 코드로 구현하며, 도메인 전문가와 개발자가 긴밀히 협력하는 과정 전반을 가리키는 사상이었다. Evans는 이 책에서 “모델-구현-언어”의 긴밀한 연결을 핵심으로 강조했다. 이는 다음과 같은 개념들로 구체화된다.

  • Ubiquitous Language (보편 언어) : 도메인 전문가와 개발자가 공유하는 공통 언어를 확립하고, 이를 코드와 모델명에 반영함으로써 의사소통 단절을 줄이는 전략.
  • Bounded Context (경계(Context)의 설정) : 하나의 대규모 시스템을 비즈니스 하위 도메인 단위로 나누어 각 컨텍스트 별로 독립적이고 일관성 있는 모델을 유지, 관리하는 구조적 개념.
  • Aggregate, Entity, Value Object, Domain Service, Domain Event 등의 전술적 패턴: 도메인 모델을 어떻게 코드 구조로 명료하게 옮길지에 대한 지침.
  • Strategic Design: 도메인 전반을 조망하여 어떤 부분을 심층적으로 모델링할 것인지, 어디에 어떤 경계를 설정하고 팀 간 협력 방식을 어떻게 할지 결정하는 상위 수준 전략.

참고 자료:

  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
  • Evans, E. (2004). Domain-Driven Design: A Conversation with Eric Evans and Bruce Eckel. Artima Developer Interview.

Evans의 접근은 기술적 관점이 아닌 지식(knowledge) 중심 접근을 제안했다. 그는 DDD를 “지식 정제(knowledge crunching)” 과정으로 설명하며, 소프트웨어 개발을 단순히 기능 구현에서 벗어나 도메인 이해를 통해 비즈니스 가치를 극대화하는 학습 과정으로 바라보았다.

3.4 DDD의 의의: 도메인 중심 사고의 부활

DDD는 기존 객체지향 분석·설계 방법론과 UML이 제안한 모델링 언어를 활용하되, 그 초점을 도메인 자체의 이해와 모델 정련(Refinement) 에 맞추었다. 이 접근은 다음과 같은 의의를 지닌다.

  1. 도메인 전문가와 개발자의 협력 강화:

기존 모델링 활동은 종종 개발자 내부 언어로 끝나거나, 문서화된 모델이 현실 요구사항과 괴리되는 문제가 있었다. DDD는 보편 언어를 통해 도메인 전문가가 이해할 수 있는 모델을 만들고, 이 모델을 기반으로 의사소통함으로써 상시적인 요구사항 정제와 지식 공유를 가능하게 했다. 2. 모델-구현 간 불일치 최소화:
UML 다이어그램이나 분석 단계 산출물이 실제 코드와 멀어지는 “모델 부식(Model Decay)” 문제는 자주 발생했다. DDD는 모델 요소를 코드(클래스, 메서드 명), 테스트 명세, 문서에 일관되게 반영하여, 모델과 구현이 동기화되도록 했다. 3. 복잡성의 전략적 관리:
Bounded Context 개념은 대규모 시스템을 한 번에 해결하려는 시도를 지양하고, 각 하위 도메인을 명확히 경계 지어 독립적으로 모델링하고 발전시키는 전략을 제시했다. 이는 추상화 수준을 올리고, 팀 단위로 관리 가능한 규모로 도메인을 나누어 복잡성을 체계적으로 제어하는 기법을 제공했다.

3.5 커뮤니티와 실천 사례의 확산

DDD의 사상은 출간 이후 수년 동안 점진적으로 커뮤니티와 실무진 사이에 스며들었다. 초기에는 새로운 개념에 익숙지 않은 개발자와 기업들이 DDD 적용을 주저했으나, 점차 성공 사례들이 나타나기 시작했다. 온라인 포럼, 컨퍼런스(OOPSLA, QCon, DDD Europe 등), Eric Evans와 다른 DDD 선구자들의 워크숍과 세미나를 통해 DDD는 “복잡한 도메인 문제를 다루는 유용한 사상”으로 자리매김했다.

이후 Vaughn Vernon이 2013년 출간한 Implementing Domain-Driven Design을 통해 DDD 패턴 적용에 대한 구체적 실무 지침을 제시하며, 커뮤니티가 더욱 확장되었다. Alberto Brandolini의 Event Storming 기법은 도메인 이벤트를 시각화하는 워크숍 형식으로, 도메인 전문가와 개발자가 짧은 시간 내에 도메인 이해를 공유하는 실천적 방법을 제시했다.

참고 자료:

  • Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley.
  • Brandolini, A. (2013년경 처음 언급한 Event Storming, 이후 책: Introducing EventStorming, 2017).

3.6 마이크로서비스 아키텍처와 DDD

2010년대 중반 이후, 클라우드와 DevOps 문화의 확산으로 마이크로서비스 아키텍처가 부상했다. 마이크로서비스는 대규모 시스템을 작은 서비스 단위로 나누어 개발·배포·운영하는 방식이다. 이때 Bounded Context 개념은 마이크로서비스를 나누는 기준으로 널리 활용되었고, DDD를 통한 도메인 기반 서비스 분할은 마이크로서비스 아키텍처 설계의 모범 사례 중 하나로 자리 잡았다.

Event Sourcing, CQRS(Command-Query Responsibility Segregation) 등의 패턴도 DDD에서 강조하는 도메인 모델링 가치관과 결합하여, 분산 환경에서 복잡한 비즈니스 로직을 다루는 새로운 길을 열었다. 이는 DDD가 2000년대 초반 등장 이래로 단절되지 않고, 산업 환경 변화에 맞추어 확장·적응해 왔음을 보여주는 증거다.

4장: 현대 도메인 모델링의 확장과 진화

4.1 서론: 도메인 모델링의 새로운 시대

3장에서 살펴본 것처럼, DDD(Domain-Driven Design)는 엔터프라이즈 애플리케이션 개발의 복잡성을 도메인 지식을 통해 관리하고, 도메인 전문가와 개발자 간 협업을 강화하는 패러다임으로 자리 잡았다. 2000년대 중반부터 DDD는 점진적으로 업계에 침투했으며, 2010년대 이후 기술 환경이 급격히 변화하면서 DDD 사상은 새로운 아키텍처 스타일, 방법론, 도구와 결합하게 된다.

클라우드 컴퓨팅, 컨테이너 오케스트레이션(Kubernetes), DevOps 문화의 정착은 소프트웨어 릴리스 속도를 높이고, 서비스 단위를 더 작게 쪼개는 마이크로서비스 아키텍처를 탄생시켰다. 이 환경에서 DDD의 Bounded Context 개념은 마이크로서비스의 서비스 경계를 설정하는 유용한 가이드라인으로 널리 활용되며, 도메인 모델링은 더 작고 독립적인 단위로 이루어지게 된다.

이러한 흐름 속에서 이벤트 주도 아키텍처, 이벤트 스토밍, BDD, DSL 같은 다양한 접근법들이 도메인 모델링과 만나 도메인 중심 사고를 더욱 강화하고 있다.

4.2 마이크로서비스 아키텍처와 DDD의 재해석

4.2.1 Bounded Context와 서비스 경계

마이크로서비스 아키텍처는 2010년대 중반 대두되었으며, Amazon, Netflix 등 대규모 인터넷 기업들이 모놀리식(monolithic) 애플리케이션을 작은 서비스 단위로 나누어 독립적으로 배포하는 전략을 통해 민첩성을 확보한 사례가 주목을 받았다. 이때 DDD의 Bounded Context 개념은, 도메인 모델을 특정 하위 도메인 경계 내에서 일관성 있게 유지한다는 점에서 마이크로서비스의 서비스 경계 설정에 이상적인 준거점이 되었다.

이로써 도메인 모델링은 단순한 설계 단계 활동을 넘어, 서비스 아키텍처 설계의 핵심 기준으로 떠올랐다. 마이크로서비스는 독립적으로 배포 가능한 작은 단위일 뿐 아니라, 해당 서비스가 책임지는 도메인 로직의 집합이라는 관점에서 접근할 때, 도메인 모델링은 아키텍처 의사결정과 직결되었다.

참고 자료:

  • Newman, S. (2015). Building Microservices. O’Reilly.
  • Vernon, V. (2016). Reactive DDD. (QCon London 발표)
  • Wolff, E. (2016). Microservices: Flexible Software Architecture. Addison-Wesley.

4.2.2 이벤트 드리븐 아키텍처와 도메인 이벤트

마이크로서비스 환경에서 서비스 간 통신은 종종 비동기 메시징과 이벤트 주도(Event-Driven) 방식으로 이뤄진다. DDD에서 말하는 Domain Event 개념은 도메인에서 의미 있는 상태 변화를 나타내며, 이를 시스템 경계를 넘어 공유하는 방식이 이벤트 드리븐 아키텍처(EDA)와 자연스럽게 결합되었다. 도메인 이벤트를 중심으로 한 EDA는 시스템 구성 요소들이 느슨하게 결합되어 변화에 유연하게 대응할 수 있는 환경을 제공한다.

참고 자료:

  • Fowler, M. (2017). What do you mean by “Event-Driven” (martinfowler.com 블로그 포스팅)
  • Newman, S. (2019). Monolith to Microservices. O’Reilly.

4.3 Event Storming: 도메인 모델링 워크숍의 진화

DDD 커뮤니티는 도메인 전문가와 개발자가 짧은 시간 내에 복잡한 도메인을 시각화하고 이해할 수 있는 기법을 고안했다. Alberto Brandolini가 제안한 Event Storming(이벤트 스토밍) 은 대형 화이트보드와 포스트잇을 활용해 도메인에서 발생하는 이벤트를 시간축에 따라 나열하면서, 도메인 개념, 액터, 명령, 정책 등을 식별하는 워크숍 기법이다.

Event Storming의 장점은 다음과 같다.

  1. 빠른 지식 공유: 도메인 전문가와 개발자가 한 공간에 모여 짧은 시간 내에 도메인 전반의 이벤트 흐름을 파악.
  2. 비가시적 규칙 노출: 비즈니스 규칙이나 프로세스 상의 ‘숨겨진’ 제약사항이 이벤트 흐름을 통해 쉽게 드러난다.
  3. Bounded Context 식별 지원: 이벤트들의 상호연관성을 통해 자연스럽게 도메인 하위 영역을 구분하고 서비스 경계를 설정할 단서를 얻을 수 있다.

참고 자료:

  • Brandolini, A. (2017). Introducing EventStorming: An act of deliberate collective learning. Leanpub.
  • DDD Europe, DDD Meetup 커뮤니티 발표 자료.

Event Storming은 DDD 철학—즉, 도메인 모델은 살아있는 지식 집합이라는 관점—을 실제로 구현하는 도구로 널리 쓰이고 있으며, 이를 통해 팀 단위로 도메인 모델을 형성, 개선하는 문화가 확산되었다.

4.4 BDD(Behavior-Driven Development)와 도메인 서술

DDD가 도메인 지식을 설계와 코드에 반영하는 전략이라면, BDD(Behavior-Driven Development)는 도메인 요구사항을 행동(Behavior) 중심의 시나리오로 표현하고 이를 실행 가능한 테스트로 전환함으로써, 개발 전 과정에 비즈니스 가치를 부각하는 접근이다.

Dan North가 2000년대 중반 제안한 BDD는 “User Story”와 “Scenario”를 통해 사용자 관점에서 시스템의 기대 행위를 명세하고, 이를 자연어에 가까운 DSL(Gherkin 언어 등)로 표현한다. 이렇게 정의된 시나리오는 자동화 테스트로 실행 가능하며, 요구사항 변경 시 빠른 피드백을 제공한다. BDD는 DDD와 궁극적으로 목표를 공유한다: 도메인 이해를 개선하고, 모델과 구현을 정렬하는 것이다. DDD 모델이 도메인 개념에 초점을 맞춘다면, BDD는 그 개념이 실질적으로 어떻게 작동해야 하는지(행위) 테스트 가능한 명세로 만든다.

참고 자료:

  • North, D. (2006). Introducing BDD. Dan North의 블로그 포스팅.
  • Wynne, M., & Hellesoy, A. (2012). The Cucumber Book: Behaviour-Driven Development for Testers and Developers. Pragmatic Bookshelf.

BDD는 도메인 모델링과 테스트 자동화, 그리고 사용자 요구사항 간을 긴밀히 연결함으로써, 도메인 모델링 결과물을 검증 가능하고 실용적인 형태로 발전시킨다.

4.5 DSL(Domain-Specific Language)과 도메인 표현력 향상

도메인 모델이 깊어지고 복잡해질수록, 그 도메인을 표현하는 언어와 표현력이 중요해진다. DDD에서 강조한 “Ubiquitous Language” 개념은 일반 프로그래밍 언어의 표현 한계를 넘어, 도메인 개념을 더 자연스럽게 기술할 수 있는 전용 언어, 즉 DSL(Domain-Specific Language)을 활용하는 시도를 촉진했다.

Martin Fowler는 Domain-Specific Languages(2010)에서 DSL을 정의하고, 내부 DSL(Internal DSL)과 외부 DSL(External DSL)을 비롯한 다양한 구현 패턴을 소개했다. DSL을 도입함으로써 도메인 로직을 더욱 명확하고 간결하게 표현하고, 도메인 전문가가 이해할 수 있는 형태로 구현을 발전시킬 수 있다. 이는 도메인 모델을 코드 차원에서 더욱 풍부하게 표현하고, 변경 요구에도 탄력적으로 대응하는 기반을 제공한다.

참고 자료:

  • Fowler, M. (2010). Domain-Specific Languages. Addison-Wesley.
  • Mernik, M., Heering, J., & Sloane, A. (2005). When and how to develop domain-specific languages. ACM Computing Surveys, 37(4).

4.6 지식 공유와 커뮤니티 발전

DDD와 현대 도메인 모델링 접근법들은 커뮤니티 활동을 통해 급속히 전파되고 개선되었다. DDD Europe, Explore DDD, QCon, O’Reilly Software Architecture, MicroXchg 등의 국제 컨퍼런스, Meetup 그룹, Slack/Discord 커뮤니티 등은 사례 연구, 워크숍, 세미나를 활발히 진행하며, 도메인 모델링 기법과 패턴을 전 세계로 확산했다. 이를 통해 다양한 산업 도메인(금융, 제조, 의료, 전자상거래, 물류 등)에 적용된 성공 사례가 공유되고, 축적된 경험을 통해 기법들이 성숙해가는 선순환이 이어졌다.

4.7 미래를 향한 시사점

현대의 도메인 모델링 패러다임은 DDD를 주축으로 마이크로서비스, 이벤트 주도 아키텍처, BDD, DSL 같은 다양한 방법론 및 기술적 흐름과 결합하며, 도메인 중심 사고를 산업 전반에 확산시키고 있다. 이러한 조류는 몇 가지 중요한 시사점을 가진다.

  1. 지속적인 도메인 이해의 중요성:

기술 스택은 끊임없이 변하지만, 도메인 지식 축적과 모델 정련 활동은 변하지 않는 핵심 자산이다. 2. 확장 가능한 협업 모델:
이벤트 스토밍이나 BDD와 같은 기법은 도메인 전문가, 디자이너, 개발자, 운영자 등 다양한 역할자가 참여하는 협업 모델을 제시한다. 3. 미래 기술과 도메인 모델링의 융합:
AI, 데이터 사이언스, 머신러닝, 블록체인, IoT 등 새롭게 부상하는 기술 영역에서도 도메인 모델링의 원칙(도메인 중심 사고, 모델 정제, 지식 축적)이 유용하게 적용될 수 있으며, 이에 대한 탐색이 계속되고 있다.

5장: 소프트웨어 개발 패러다임 변화의 의미와 미래 전망

5.1 역사적 흐름의 재조명

1장에서 우리는 객체지향 프로그래밍(OOP)의 기원으로 거슬러 올라가, Simula와 Smalltalk를 통해 객체지향 사상이 어떻게 탄생했는지를 살펴보았다. 이 초기 단계에서 객체지향은 단지 프로그래밍 언어 기능이 아닌, 세계를 객체 상호작용으로 바라보는 새로운 사고방식을 제시했다.

2장에서는 객체지향 개념이 언어 차원을 넘어 분석·설계 방법론(OOAD) 으로 발전하는 과정을 추적했다. Booch, Rumbaugh, Jacobson 등 선구자들의 방법론이 UML로 통합되면서, 도메인 모델을 표준화된 언어로 표현하고 공유하는 기반이 마련되었다. 이 과정에서 객체지향은 단순한 코딩 스타일이 아닌, 시스템 설계와 문서화, 커뮤니케이션의 공용 언어로 자리 잡았다.

3장에서는 UML과 객체지향 분석·설계의 확산에도 불구하고 산업 현장에서 여전히 남아있던 “도메인 복잡성” 문제를 해결하기 위해 등장한 Domain-Driven Design(DDD)을 다루었다. DDD는 도메인 지식에 집중하고 모델-언어-구현을 긴밀히 연결함으로써 도메인 모델링의 본질적 가치를 재조명했다. Eric Evans의 철학은 소프트웨어 개발을 지식 형성(knowledge crunching)의 과정으로 바라봄으로써, 개발자와 도메인 전문가가 함께 도메인 이해를 심화하는 학습적, 진화적 프로세스를 제안한 것이다.

4장에서는 DDD 이후 시대를 조망하며, 마이크로서비스, 이벤트 주도 아키텍처(EDA), Event Storming, BDD, DSL 등 현대적 기법들이 DDD 사상과 결합하는 과정을 조명했다. 이로써 도메인 모델링은 대규모 분산 환경, 빠른 릴리스 주기, 다양한 이해관계자 간 협업, 자동화 테스트, 도메인 특화 언어 등과 결합하여 더욱 실용적이고 생태계화된 패러다임으로 발전하고 있음을 확인했다.

5.2 변화된 소프트웨어 개발 문화

이 일련의 역사는 소프트웨어 개발 문화를 어떻게 바꾸었을까?

  1. 개발자 중심에서 도메인 중심으로:

초기 소프트웨어 개발은 주로 개발자 기술 스택, 프로그래밍 언어 특징, 알고리즘 및 자료구조 중심의 사고방식이었다. 그러나 OOP, UML, DDD를 거치면서 개발 과정은 비즈니스 문제, 도메인 전문가 지식, 모델링 활동에 대한 강조로 옮겨갔다. 기술적 해결책보다 “무엇을 해결하고자 하는가”에 초점을 맞추게 된 것이다. 2. 수직적 지식전달에서 협력적 지식공유로:
과거에는 요구사항 분석가, 설계자, 개발자가 수직적으로 이어지는 흐름에서 지식을 전달했다. 그러나 DDD, Event Storming, BDD 등을 통해 실무자, 도메인 전문가, 테스트 엔지니어, 운영자 등 다양한 역할자가 한자리에 모여 공동으로 도메인 지식을 탐구하고, 모델을 발전시키는 협력 문화가 형성되었다. 이는 팀 조직 구조와 커뮤니케이션 방식을 크게 변화시켰다. 3. 문서에서 실행 가능한 모델로:
예전에는 분석·설계 문서는 구현 시점에서 점차 쓸모를 잃어가는 경향이 있었다. 그러나 BDD 시나리오, DSL, Event Storming의 결과물, 코드에 반영된 DDD 모델 등은 실행 가능하고 유지 가능한 모델로 구현에 긴밀하게 결합되고, 지속적인 검증과 진화를 거치며 실제 개발 흐름에 참여한다. 모델은 정적인 문서가 아니라, 코드와 테스트, 서비스 경계, 워크숍 활동 등으로 살아 움직이는 실체가 되었다.

5.3 비즈니스 가치 극대화와 요구사항 변화 대응

도메인 모델링의 진화는 궁극적으로 소프트웨어가 비즈니스 가치를 극대화하는 데 중요한 역할을 한다.

  • 지속적인 요구사항 변화 대응:
    비즈니스 환경은 늘 변화한다. 새 규제, 시장 트렌드, 경쟁우위 전략에 따라 도메인 규칙이 달라진다. 도메인 모델링 패러다임을 정립한 조직은 이러한 변화에 탄력적으로 대응할 수 있다. 모델-코드-테스트-서비스 구조의 일관된 관리 덕분에 새로운 요구사항을 신속히 반영하고, 시스템 전체가 무너지지 않는 안정성을 확보한다.
  • 지식 축적을 통한 장기적 경쟁력 강화:
    도메인 지식은 시간과 함께 축적되는 자산이다. DDD와 현대 모델링 접근법을 도입한 팀은 매 릴리스마다 모델을 개선하고, Event Storming 세션마다 새로운 인사이트를 얻으며, BDD 시나리오를 통해 요구사항을 명세화·자동화하는 과정에서 도메인 지식을 체계적으로 쌓는다. 이러한 축적된 지식은 향후 신기술 도입이나 서비스 확장 시에도 강력한 기반이 된다.

5.4 새로운 기술 시대와 도메인 모델링

앞으로 다가올 시대에도 도메인 모델링 철학은 변함없이 유효할까? 인공지능, 머신러닝, 데이터 사이언스, 클라우드 네이티브 기술, IoT, 블록체인 등 새로운 패러다임이 계속해서 등장하고 있다. 이들은 각기 독특한 기술적 특성과 요구사항을 갖고 있지만, 결국 “도메인에 맞춰 기술을 적용”하는 기본 원리는 변하지 않는다.

DDD와 도메인 모델링 철학은 “복잡성을 인간적이고 이해 가능한 수준으로 관리”하고 “기술보다 문제 자체에 집중”하는 자세를 강조한다. 이는 미래 기술 트렌드에도 여전히 유효한 원칙이다. 예를 들어, 머신러닝 모델을 비즈니스 도메인 맥락에서 이해하고, 모델 출력 결과를 도메인 논리에 일관되게 통합하며, 변경되는 비즈니스 룰에 맞게 AI 모델을 재학습하는 과정도 결국 도메인 모델링 원칙을 필요로 할 것이다.

5.5 결론: 도메인 중심 사고의 지속성

이 글이 다룬 객체지향→도메인 모델링→DDD→현대 도메인 모델링에 이르는 흐름은 단순한 기술 발전사가 아니다. 이는 소프트웨어 개발의 철학적 전환이며, 인간과 비즈니스 가치를 중심에 두는 문화적 변화다. 도메인 모델링의 역사는 “어떻게 하면 소프트웨어가 현실의 복잡한 문제를 더 충실히 담아내고, 변화와 성장에 적응하며, 사람들과 지식의 흐름을 증진시킬 수 있는가?”라는 질문에 대한 끝없는 모색의 과정이었다.

이 장을 마치며, 우리는 다음과 같이 요약할 수 있다.

  • 객체지향 사상은 세상을 객체 상호작용으로 바라보는 추상화 철학에서 출발했다.
  • OOAD와 UML로 대표되는 방법론적 발전은 도메인 모델링을 구조화하고 표준화했다.
  • DDD는 도메인 중심 사고를 통해 모델·언어·코드의 일체화를 제안하며, 지식 형성 과정으로서 소프트웨어 개발을 재해석했다.
  • 현대 도메인 모델링 기법은 DDD 철학을 바탕으로 마이크로서비스, EDA, Event Storming, BDD, DSL 등으로 확장·응용되어, 협업과 적응성을 극대화하고 있다.
  • 이러한 변화는 기술뿐 아니라 소프트웨어 개발 문화, 비즈니스 가치 창출 방식, 협업 생태계 전반에 영향을 미치며, 미래에도 유효할 전망이다.

궁극적으로 이 역사는 “기술을 넘어, 문제 해결에 초점을 둔 도메인 중심 접근”이 어떻게 소프트웨어 산업을 진화시켜 왔는지 보여주는 하나의 긴 흐름이다. 이 글이 독자들에게 그 흐름을 명확히 이해하고, 미래의 도메인 모델링과 소프트웨어 개발 방향성을 모색하는 데 도움이 되길 바라며 글을 마친다.

Previous Article
LLM 시대 해석하기 (with. AI)