소프트웨어 개발의 패러다임이 수없이 변화해왔지만, 객체지향(Object-Oriented)이라는 거대한 뿌리는 여전히 현대 개발의 근간을 이루고 있습니다. 우리가 당연하게 사용하는 프레임워크와 설계 패턴 속에는 수십 년간 쌓아온 객체지향의 철학이 녹아있습니다. 특히, 통합 모델링 언어(UML)의 탄생 이전, 객체지향 방법론의 춘추전국시대를 이끌었던 세 명의 거장, 이바 야콥슨(Ivar Jacobson), 제임스 럼바우(James Rumbaugh), 그레이디 부치(Grady Booch)의 방법론은 오늘날 개발자에게도 깊은 통찰력을 제공합니다.
이들의 방법론인 OOSE, OMT, OOD는 단순히 과거의 유물이 아닙니다. 이는 소프트웨어를 바라보는 세 가지 다른지만 상호 보완적인 관점을 제시하며, 복잡한 시스템을 효과적으로 분석하고 설계하는 지혜를 담고 있습니다. 사용자 중심의 요구사항 분석(OOSE), 데이터와 구조 중심의 모델링(OMT), 그리고 구체적인 구현을 위한 상세 설계(OOD)라는 각각의 핵심 사상은 현대의 애자일, 마이크로서비스 아키텍처(MSA) 환경에서도 변치 않는 가치를 지닙니다. 이 글을 통해 세 가지 방법론의 핵심 개념과 인과관계를 깊이 있게 파고들고, 이들이 어떻게 UML로 통합되었으며, 현재 우리의 개발 방식에 어떤 영향을 미치고 있는지 생생한 사례와 함께 탐험해 보겠습니다.
OOSE (Object-Oriented Software Engineering): 사용자의 목소리에서 시작하는 개발
OOSE의 핵심 철학: 유스케이스(Use Case)
객체지향 소프트웨어 공학, 즉 OOSE는 스웨덴의 컴퓨터 과학자 이바 야콥슨에 의해 주창되었습니다. OOSE가 다른 방법론과 구별되는 가장 혁신적인 지점은 바로 ‘유스케이스(Use Case)’라는 개념을 개발 프로세스의 중심에 두었다는 것입니다. 기존의 기능 명세서가 시스템이 ‘무엇을’ 제공해야 하는지에 집중했다면, 유스케이스는 ‘누가(Actor)’ 시스템을 통해 ‘무엇을’ 하려 하는지에 대한 상호작용과 시나리오에 집중합니다. 이는 개발의 관점을 공급자 중심에서 사용자 중심으로 180도 전환시킨 획기적인 발상이었습니다.
유스케이스는 단순히 기능을 나열하는 것을 넘어, 사용자의 목표를 달성하기 위한 구체적인 이야기(Story)를 담고 있습니다. 예를 들어, ‘온라인 서점’ 시스템에서 ‘도서 검색’이라는 기능 명세 대신, ‘고객이 원하는 책을 검색하여 상세 정보를 확인한다’라는 유스케이스를 정의합니다. 이 유스케이스에는 정상적인 흐름(책을 성공적으로 찾음)뿐만 아니라, 예외적인 흐름(검색 결과가 없음, 시스템 오류 발생 등)까지 포함됩니다. 이처럼 시나리오 기반의 접근 방식은 개발 초기 단계부터 요구사항의 누락이나 오해를 방지하고, 개발자와 사용자, 기획자 간의 명확한 소통 도구로서 기능합니다.
OOSE의 시스템 개발 생명주기 모델
OOSE는 유스케이스를 중심으로 전체 개발 생명주기를 관통하는 5가지 모델을 제시합니다. 이 모델들은 아이디어 구상부터 최종 테스트까지 시스템이 어떻게 발전해 나가는지를 체계적으로 보여줍니다.
- 요구사항 모델 (Requirements Model): 사용자의 요구사항을 파악하고 유스케이스와 액터(Actor)를 식별하여 시스템의 범위와 목적을 명확히 정의하는 단계입니다. 유스케이스 다이어그램이 이 모델의 핵심 산출물입니다.
- 분석 모델 (Analysis Model): 요구사항 모델을 바탕으로 시스템의 구조를 개념적으로 설계합니다. 여기서는 시스템 내부의 객체들을 인터페이스(Interface), 제어(Control), 엔티티(Entity)라는 세 가지 유형으로 구분하여 역할과 책임을 할당합니다. 이는 시스템의 논리적인 구조를 안정적으로 만드는 데 기여합니다.
- 설계 모델 (Design Model): 분석 모델을 실제 구현 환경에 맞게 구체화하는 단계입니다. 특정 프로그래밍 언어나 데이터베이스 시스템을 고려하여 블록(Block) 단위로 상세 설계를 진행하며, 시스템의 성능, 동시성, 분산 처리 등을 고려합니다.
- 구현 모델 (Implementation Model): 설계 모델을 바탕으로 실제 소스 코드를 작성하는 단계입니다.
- 테스트 모델 (Test Model): 유스케이스를 기반으로 테스트 케이스를 도출하고, 시스템이 요구사항을 정확히 만족하는지 검증합니다. 각 유스케이스 시나리오가 하나의 중요한 테스트 기준이 됩니다.
현대 개발에서의 OOSE 유산
OOSE의 유스케이스 중심 접근법은 현대 소프트웨어 개발, 특히 애자일(Agile) 방법론에 지대한 영향을 미쳤습니다. 애자일의 핵심 실천법 중 하나인 ‘사용자 스토리(User Story)’는 유스케이스의 정신을 그대로 계승한 것입니다. “As a [user type], I want [some goal] so that [some reason]” 형식으로 작성되는 사용자 스토리는 사용자의 관점에서 가치를 정의한다는 점에서 유스케이스와 본질적으로 동일합니다.
최근 각광받는 BDD(Behavior-Driven Development, 행위 주도 개발) 역시 OOSE의 영향 아래 있습니다. BDD는 ‘Given-When-Then’ 구조를 사용하여 시스템의 행위를 명세하는데, 이는 유스케이스의 시나리오를 좀 더 정형화된 방식으로 표현한 것이라 할 수 있습니다. 이처럼 OOSE는 단순히 다이어그램을 그리는 기술을 넘어, 사용자의 가치를 최우선으로 생각하고 이를 개발 전 과정의 이정표로 삼는 현대적 개발 철학의 기초를 마련했습니다.
OMT (Object Modeling Technique): 세상을 모델링하는 세 가지 렌즈
OMT의 핵심: 객체, 동적, 기능 모델링
제임스 럼바우가 제너럴 일렉트릭(GE) 연구소에서 개발한 객체 모델링 기술, OMT는 시스템을 세 가지 다른 관점에서 입체적으로 바라보고 모델링하는 강력한 분석 방법론입니다. OMT는 복잡한 시스템을 이해하기 위해 하나의 시각만으로는 부족하다고 보았으며, 정적 구조, 시간의 흐름에 따른 변화, 그리고 데이터의 변환 과정을 각각 분리하여 분석해야 한다고 주장했습니다. 이 세 가지 관점이 바로 객체 모델링, 동적 모델링, 기능 모델링입니다.
- 객체 모델링 (Object Modeling): 시스템에서 가장 중요하고 안정적인 ‘구조’를 파악하는 과정입니다. 시스템을 구성하는 객체(Object)와 클래스(Class)를 식별하고, 그들 간의 관계(연관, 집합, 일반화 등)를 다이어그램으로 표현합니다. 이는 데이터베이스의 ERD(Entity-Relationship Diagram)와 유사하지만, 객체의 행위(메서드)까지 포함한다는 점에서 더 포괄적입니다. OMT의 객체 모델링은 시스템의 뼈대를 세우는 과정으로, 가장 먼저 수행되며 가장 중요한 부분으로 간주됩니다.
- 동적 모델링 (Dynamic Modeling): 시간의 흐름에 따라 객체의 상태가 어떻게 변하는지를 추적하고 표현합니다. 상태 다이어그램(State Diagram)을 사용하여 특정 이벤트(Event)가 발생했을 때 객체의 상태가 어떻게 전이(Transition)되는지를 명시합니다. 예를 들어, ‘주문’ 객체는 ‘주문 접수’ -> ‘결제 완료’ -> ‘배송 중’ -> ‘배송 완료’ 와 같은 상태 변화를 겪게 되는데, 동적 모델링은 이러한 생명주기를 시각적으로 명확하게 보여줍니다.
- 기능 모델링 (Functional Modeling): 시스템 내에서 데이터 값이 어떻게 입력받아 어떤 과정을 거쳐 변환되고 출력되는지를 모델링합니다. 자료 흐름도(DFD, Data Flow Diagram)를 사용하여 데이터의 흐름과 처리 과정을 중심으로 시스템의 기능을 설명합니다. 이는 사용자 관점의 입력과 출력 사이에 어떤 계산이나 변환이 일어나는지를 보여주는 역할을 합니다.
| 모델링 기법 | 관점 | 주요 다이어그램 | 설명 | 예시 (온라인 쇼핑몰) |
|---|---|---|---|---|
| 객체 모델링 | 시스템의 정적 구조 (What) | 객체 다이어그램 | 클래스, 속성, 연산 및 클래스 간의 관계를 정의 | 고객, 상품, 주문 클래스와 그들의 관계를 정의 |
| 동적 모델링 | 시스템의 시간적 행위 (When) | 상태 다이어그램 | 이벤트에 따른 객체의 상태 변화를 시간 순서로 표현 | ‘주문’ 객체의 상태가 ‘결제 대기’에서 ‘배송 준비’로 변하는 과정 |
| 기능 모델링 | 데이터의 변환 과정 (How) | 자료 흐름도(DFD) | 입력 데이터가 어떤 처리 과정을 거쳐 출력 데이터로 변환되는지 표현 | 사용자가 ‘주문하기’ 버튼을 누르면 상품 정보와 고객 정보가 합쳐져 ‘주문’ 데이터가 생성되는 흐름 |
OMT의 분석-설계-구현 프로세스
OMT는 분석, 설계, 구현의 3단계로 개발 프로세스를 정의합니다. 분석 단계에서는 앞서 설명한 세 가지 모델링을 통해 현실 세계의 문제를 이해하고 개념적으로 표현합니다. 이 단계에서는 구현의 제약사항보다는 문제의 본질을 파악하는 데 집중합니다. 설계 단계에서는 분석 단계에서 만들어진 모델을 기반으로 실제 시스템의 아키텍처를 결정합니다. 데이터베이스 스키마 설계, 클래스의 구체적인 인터페이스 정의 등이 이뤄집니다. 마지막 구현 단계에서는 설계된 내용을 바탕으로 프로그래밍 언어를 사용하여 코드를 작성합니다. 이처럼 OMT는 현실 세계에 대한 깊은 이해(분석)로부터 시작하여 점진적으로 구체적인 소프트웨어 시스템(구현)을 만들어나가는 체계적인 경로를 제시합니다.
데이터 중심 시스템에서의 OMT의 가치
OMT는 특히 데이터베이스 설계나 데이터의 흐름이 중요한 정보 시스템 개발에 매우 강력한 방법론입니다. 객체 모델링은 데이터베이스의 논리적 스키마 설계와 직접적으로 연결될 수 있으며, 기능 모델링은 복잡한 비즈니스 로직의 데이터 처리 과정을 명확히 하는 데 도움을 줍니다. 최근 빅데이터 및 AI 시스템이 중요해지면서 데이터의 흐름과 변환을 정밀하게 모델링하는 것이 더욱 중요해졌습니다. OMT의 기능 모델링에서 사용된 DFD의 원리는 현대의 데이터 파이프라인이나 ETL(Extract, Transform, Load) 프로세스를 설계하고 시각화하는 데에도 여전히 유효한 개념적 틀을 제공하고 있습니다.
OOD (Object-Oriented Design): 구현을 위한 정교한 설계도
OOD의 핵심: 미시적, 거시적 관점의 조화
그레이디 부치는 소프트웨어 아키텍처 분야의 대가로, 그의 객체지향 설계(OOD) 방법론은 개념적인 분석 모델을 실제 코드로 구현 가능하도록 만드는 구체적인 ‘설계’ 과정에 집중합니다. OOD의 가장 큰 특징은 시스템을 ‘논리적 구조’와 ‘물리적 구조’, 그리고 ‘미시적(Micro)’ 관점과 ‘거시적(Macro)’ 관점으로 나누어 다각적으로 설계한다는 점입니다.
- 거시적 관점: 시스템 전체의 아키텍처를 설계하는 것입니다. 시스템을 주요 서브시스템이나 모듈로 어떻게 나눌 것인지, 그리고 이들 간의 의존성과 통신 방식을 어떻게 정의할 것인지를 결정합니다. 현대의 마이크로서비스 아키텍처(MSA)에서 각 서비스를 정의하고 이들 간의 API를 설계하는 것이 바로 거시적 설계에 해당합니다.
- 미시적 관점: 개별 클래스와 객체의 내부를 상세하게 설계하는 것입니다. 클래스의 속성(Attribute)과 연산(Method)을 정의하고, 접근 제어(public, private 등)를 결정하며, 객체들 간의 상호작용을 구체적으로 명시합니다. 잘 설계된 클래스는 재사용성이 높고 유지보수가 용이한 코드의 기초가 됩니다.
OOD의 다양한 다이어그램과 프로세스
부치 방법론은 풍부한 다이어그램 표기법으로 유명합니다. 이는 복잡한 소프트웨어의 다양한 측면을 시각적으로 표현하기 위함이며, 후일 UML의 다이어그램에 많은 영감을 주었습니다. 대표적인 다이어그램은 다음과 같습니다.
- 클래스 다이어그램 (Class Diagram): 시스템의 정적 구조를 모델링하며, 클래스와 그들 사이의 관계(상속, 연관, 의존 등)를 보여줍니다. OMT의 객체 모델과 유사하지만, 구현 수준의 상세한 정보를 포함합니다.
- 객체 다이어그램 (Object Diagram): 특정 시점에서의 객체 인스턴스들과 그들의 관계를 보여주는 스냅샷입니다. 클래스 다이어그램이 ‘설계도’라면 객체 다이어그램은 ‘설계도에 따라 지어진 특정 상태의 건물’을 보여주는 것과 같습니다.
- 상태 전이 다이어그램 (State Transition Diagram): 하나의 객체가 가질 수 있는 상태와 상태 간의 전이를 모델링합니다. OMT의 동적 모델과 거의 동일한 역할을 합니다.
- 상호작용 다이어그램 (Interaction Diagram): 여러 객체들이 메시지를 주고받으며 상호작용하는 과정을 시간 순서에 따라 보여줍니다. 이는 특정 유스케이스나 기능이 수행되는 동안 객체들이 어떻게 협력하는지를 명확하게 해줍니다.
OOD가 현대 설계에 미친 영향
OOD는 오늘날 객체지향 설계 원칙(SOLID 등)과 디자인 패턴의 이론적 기반이 되었습니다. 부치가 강조한 ‘클래스 내부의 응집도는 높이고 클래스 간의 결합도는 낮추는’ 원칙은 여전히 좋은 소프트웨어 설계의 제1원칙으로 여겨집니다. 또한, 시스템을 논리적/물리적, 거시적/미시적 관점으로 나누어 바라보는 접근 방식은 복잡한 대규모 시스템을 체계적으로 분해하고 정복해나가는 데 필수적입니다.
예를 들어, 클라우드 기반의 대규모 서비스를 개발할 때, 어떤 기능을 어떤 마이크로서비스로 분리할지 결정하는 것은 OOD의 거시적 설계 관점입니다. 그리고 각 마이크로서비스 내에서 도메인 모델을 정의하고 클래스를 설계하는 것은 미시적 설계 관점에 해당합니다. 이처럼 OOD는 구체적인 코드 작성 전, 시스템의 안정성과 확장성, 유지보수성을 결정하는 청사진을 그리는 핵심적인 지적 활동의 프레임워크를 제공합니다.
통합과 진화: UML의 탄생
1990년대 중반, 객체지향 방법론의 ‘전쟁’은 과열 양상을 보였습니다. 수십 가지의 방법론이 난립하면서 개발자들은 프로젝트마다 다른 표기법과 프로세스를 배워야 하는 비효율을 겪었습니다. 이러한 혼란을 종식시키기 위해 ‘세 명의 친구(Three Amigos)’로 불리는 야콥슨, 럼바우, 부치가 힘을 합쳤습니다. 그들은 각자 자신의 방법론을 개발하던 래셔널(Rational) 소프트웨어사에서 만나, 각 방법론의 장점들을 모아 표준화된 모델링 언어를 만들기로 합의했습니다.
그 결과 탄생한 것이 바로 UML(Unified Modeling Language)입니다. UML은 OOSE의 유스케이스 다이어그램, OMT의 객체 모델링과 상태 다이어그램, OOD의 풍부한 설계 다이어그램 표기법을 모두 계승하고 발전시켜 하나의 통일된 체계로 집대성했습니다. 예를 들어, UML의 유스케이스 다이어그램은 OOSE의 사용자 중심 분석 철학을, 클래스 다이어그램은 OMT와 OOD의 구조적 모델링 기법을, 시퀀스 다이어그램은 OOD의 상호작용 모델링을 기반으로 합니다. UML은 특정 방법론에 종속되지 않고, 다양한 개발 프로세스에 적용할 수 있는 유연한 ‘언어’로서 자리매김했으며, 현재는 객체지향 분석 및 설계의 사실상 표준(de facto standard)으로 인정받고 있습니다.
결론: 과거의 지혜로 현재를 설계하다
OOSE, OMT, OOD는 비록 30년 가까이 된 고전적인 방법론이지만, 그들이 제시한 핵심 사상은 시대를 초월하는 가치를 지닙니다. 소프트웨어 개발의 본질은 결국 ‘사용자가 원하는 가치를(OOSE)’, ‘안정적인 구조 위에서(OMT)’, ‘유지보수하기 좋은 코드로(OOD)’ 만들어내는 것이기 때문입니다. 이 세 가지 관점은 어느 하나도 소홀히 할 수 없는 성공적인 소프트웨어 개발의 삼위일체와 같습니다.
현대의 개발자들은 UML이라는 통합된 도구를 사용하지만, 그 배경에 있는 OOSE, OMT, OOD의 철학을 이해할 때 비로소 각 다이어그램을 더 깊이 있게 활용할 수 있습니다. 예를 들어, 유스케이스 다이어그램을 그릴 때는 OOSE의 사용자 중심 철학을 떠올리고, 클래스 다이어그램을 설계할 때는 OMT의 데이터 구조와 OOD의 책임 할당 원칙을 함께 고민해야 합니다. 빠르게 변화하는 기술 트렌드 속에서 길을 잃지 않으려면, 이처럼 시대를 관통하는 견고한 기본 원리를 이해하는 것이 무엇보다 중요합니다. 과거 거장들의 지혜를 현재 우리의 프로젝트에 녹여낼 때, 우리는 더 나은 소프트웨어를 설계하고 만들어나갈 수 있을 것입니다.