OO 모델링

OO 모델링이란 무엇인가

OO 모델링(Object-Oriented Modeling, 객체지향 모델링)은 현실 세계의 사물과 개념을 객체로 인식해 시스템을 분석하고 설계하는 방법론이다. 데이터와 그 데이터를 다루는 행위를 하나의 단위로 묶어, 시스템을 기능의 나열이 아니라 상호작용하는 객체들의 집합으로 바라본다.

과거의 절차 중심 사고가 처리 흐름을 따라 시스템을 쪼갰다면, 객체 중심 사고는 책임을 가진 주체를 먼저 식별한 뒤 그 주체들이 주고받는 협력으로 동작을 구성한다. 이 관점의 전환 덕분에 업무 도메인의 구조가 코드 구조에 비교적 자연스럽게 반영된다.

분석과 설계를 잇는 다리

OO 모델링의 가치는 분석 단계의 현실 인식과 설계 단계의 구현 구조를 하나의 사고 체계로 잇는 데 있다. 분석에서는 업무 영역에 등장하는 핵심 객체와 그들의 관계, 책임을 식별하고, 설계에서는 이를 클래스·인터페이스·연관 관계로 구체화한다.

분석 모델과 설계 모델이 동일한 객체 개념 위에 서 있으므로, 요구사항이 변하면 어느 객체의 책임이 흔들리는지 추적하기 쉽다. 이 연속성은 분석에서 설계로 넘어갈 때 발생하는 의미 손실을 줄여 준다.

한 줄 정의대로 OO 모델링은 분석·설계 단계를 관통하는 모델링 활동이며, 별도의 단계가 아니라 두 단계를 일관되게 묶는 사고 틀이다.

캡슐화·상속·다형성

객체지향 모델링은 캡슐화, 상속, 다형성이라는 세 축 위에서 작동한다. 캡슐화는 객체의 내부 상태를 감추고 정해진 통로로만 접근하게 해, 변경의 파급을 객체 안쪽으로 가둔다.

상속은 공통 속성과 행위를 상위 개념으로 끌어올려 중복을 줄이고 일반·특수 관계를 명료하게 표현한다. 다형성은 동일한 요청에 객체마다 다르게 응답하도록 허용해, 조건 분기로 가득한 코드를 책임의 위임으로 바꾼다.

이 세 가지가 맞물려야 변경에 강하고 재사용 가능한 구조가 만들어진다. 개념을 외워 적용하는 것이 아니라, 도메인을 보는 눈으로 체화해야 모델이 견고해진다.

UseCase 모델과의 결합

OO 모델링은 단독으로 쓰이기보다 UseCase 모델과 함께 사용될 때 위력을 발휘한다. UseCase 모델이 사용자가 시스템에서 얻고자 하는 목표와 상호작용 시나리오를 외부 관점에서 정의한다면, 객체 모델은 그 시나리오를 실제로 수행할 내부 객체들의 협력을 설계한다.

즉 무엇을 해야 하는가를 UseCase가 규정하고, 어떻게 그것을 책임 분담으로 풀 것인가를 객체 모델이 답한다. 두 모델을 오가며 시나리오마다 어떤 객체가 어떤 책임을 지는지 검증하면, 누락된 책임이나 과도하게 비대해진 객체를 조기에 발견할 수 있다.

외부 요구와 내부 구조를 분리해 보되 서로 검증하게 만드는 것이 핵심이다.

좋은 모델과 나쁜 모델

객체를 잘게 나누기만 한다고 좋은 모델이 되는 것은 아니다. 책임이 한 객체에 과도하게 몰리면 변경이 그 객체를 통째로 흔들고, 책임이 지나치게 흩어지면 협력 경로가 복잡해져 추적이 어려워진다.

좋은 모델은 객체 사이의 결합도를 낮추고 각 객체의 응집도를 높여, 하나의 변경이 한 곳에서 마무리되도록 만든다. 또한 도메인 용어와 객체 이름이 일치할수록 분석가·개발자·현업이 같은 언어로 대화하게 되어 의사소통 비용이 줄어든다.

모델의 품질은 다이어그램의 화려함이 아니라, 변경 요청이 들어왔을 때 영향 범위가 얼마나 좁게 한정되는가로 드러난다.

ooCBD로 이어지는 흐름

OO 모델링으로 식별된 객체와 책임은 그대로 멈추지 않고 컴포넌트 단위의 재사용 설계로 발전한다. 응집된 책임을 가진 객체 묶음을 명확한 인터페이스로 감싸면, 독립적으로 개발하고 교체할 수 있는 컴포넌트가 된다.

이렇게 객체지향 기술을 컴포넌트 기반 개발과 결합한 접근이 ooCBD이며, OO 모델링은 그 출발점에 해당하는 분석·설계 활동이다. 모델 단계에서 책임 경계를 잘 그어 두면 구현 단계에서 컴포넌트 분할이 한결 수월해진다.

결국 분석에서 그린 객체 경계가 구현의 부품 경계로 이어지는 셈이다.