UML 객체 다이어그램으로 런타임 인스턴스 검증하기

런타임 상태를 한 장의 구조로 확인하는 방법

UML 객체 다이어그램은 특정 시점에 존재하는 객체 인스턴스와 객체 사이의 링크를 스냅샷으로 나타내는 정적 구조 다이어그램이다. 클래스 다이어그램이 정의한 설계가 런타임 데이터에서 어떤 모습으로 실현되는지 확인할 때 적합하다. 복잡한 연관, 다중성, 합성 경계를 실제 데이터와 함께 점검하는 데도 쓸 수 있다.

클래스 다이어그램이 가능한 구조의 범위를 선언한다면, 객체 다이어그램은 특정 시나리오에서 실제로 구성된 구조를 보여준다. 이를 통해 연관 방향, 다중성, 합성 관계, 제약이 지켜졌는지 확인한다.

객체는 objName:Class 형식으로 표기하며, 이름이 없는 객체는 :Class로 표시한다. 객체에는 필요한 속성 슬롯과 값을 함께 두고, 객체 간 관계는 연관 인스턴스인 링크로 연결한다. OCL 등을 포함한 제약 조건의 충족 여부도 이 인스턴스 수준에서 다룬다.

객체에 담을 값과 관계를 고르는 기준

객체의 속성 슬롯에는 식별자, 상태, 금액·수량처럼 비즈니스 판단에 직접 필요한 값을 우선 배치한다. 파생 속성이 필요하면 주석으로 그 사실을 명시한다. 모든 속성을 노출하기보다 시나리오 검증에 필요한 값만 남겨야 구조가 읽힌다.

링크는 클래스 다이어그램의 연관을 실제 객체 사이에 실현한 표현이다. 방향성, 한정자(qualifier), 역할명 등을 인스턴스 차원에서 확인할 수 있다. 1..*, 0..1 같은 다중성 제약은 링크의 실제 개수를 기준으로 검증한다.

합성 관계에서는 부분 객체의 생명주기가 전체 객체에 종속되는 모습을 드러낸다. 삭제 전파와 소유권의 일관성을 확인하는 데 맞는다. 반면 집합 관계는 느슨한 소유를 나타내므로, 복수 소유가 가능한지를 사례로 점검할 수 있다.

객체 다이어그램은 시간 흐름을 표현하지 않는 정적 스냅샷이다. 상태 전이는 별도의 행위 다이어그램으로 보완한다. 동시성 문제 역시 다이어그램 자체에 표기하지 않으며, 상태 불일치가 발견되면 시퀀스 다이어그램이나 상태 다이어그램으로 추적한다.

설계 검증과 테스트 데이터에 연결하기

주문–주문항목–상품–고객 관계를 예로 들면, 객체 다이어그램은 다중성과 가격 합계 제약을 실제 인스턴스로 확인하게 해준다. 추상적인 도메인 모델만 볼 때 놓치기 쉬운 관계의 빈자리나 과도한 연결을 찾는 방식이다.

ORM과 DB 스키마를 대조할 때는 외래키와 연관 매핑이 맞는지, 지연 로딩에서 가정한 객체 존재성이 성립하는지를 점검하는 자료가 된다. 결함 재현 시점의 객체 상태를 시각화하면 원인 분석과 설계 리뷰에도 활용할 수 있다.

테스트에서는 단위·통합 테스트에 필요한 인스턴스와 링크를 정형화한 픽스처 문서로 쓸 수 있다. API 계약에서는 요청과 응답 전후에 전제되는 인스턴스 변화를 명확히 하여 계약 테스트의 신뢰성을 높인다.

시나리오에서 산출물까지의 검증 흐름

작성은 요구사항 시나리오, 클래스 다이어그램, 비즈니스 규칙과 제약(OCL 포함)에서 시작한다. 시나리오에 참여하는 객체 후보를 식별한 뒤, 식별자와 키를 중심으로 핵심 속성 값을 채운다. 이어 연관 링크를 인스턴스화하고 다중성을 검증하며, 합성·집합 경계와 소유 일관성을 점검한다. 마지막으로 유일성, 합계, 상태 제약이 충족되는지 확인한다.

산출물은 객체 다이어그램과 검증 결과 메모로 구성한다. 메모에는 위반 사항과 수정안을 남긴다. 다중성 위반이 발견되면 링크 추가, 모델 수정, 범위 축소 중 하나를 적용한다. 합성 순환이나 이중 소유가 보이면 경계를 재설계하고, 식별자 충돌은 키 설계와 유일성 제약을 보강해 다룬다.

⤢✕

타입 모델과 인스턴스 스냅샷의 차이

구분	클래스 다이어그램	객체 다이어그램
목적	타입 구조 정의	런타임 인스턴스 스냅샷
시점	시간 불변 정의	특정 시점 상태
단위	클래스, 연관, 제약	객체, 링크, 속성 값
사용 시기	초기 설계, 구조 합의	설계 검증, 리뷰, 테스트 데이터
범위/규모	넓은 범위, 전체 도메인	좁은 범위, 시나리오 중심
검증 포인트	모델 일관성, 제약 선언	다중성 실현, 제약 충족, 소유 일관성

읽기 쉬운 스냅샷을 유지하는 선택

시나리오에 직접 기여하는 객체만 포함하면 가독성이 좋아지고 리뷰 시간도 줄어든다. 다만 주변 컨텍스트가 빠지면 그 이해가 늦어질 수 있다.

objName:Class 표기와 중요한 슬롯만 표시하는 규칙을 일관되게 적용하고, 단위·통화는 주석으로 남긴다. 상세 값을 생략할수록 데이터 품질 문제를 놓칠 가능성도 함께 커진다.

합성 관계에서는 소유자와 부분 객체의 생명주기 종속성을 분명히 하고 이중 소유를 검증한다. 이 방식은 실제 시스템의 캐시나 레퍼런스 공유 전략과 맞지 않을 수 있다.

실행 중 스냅샷 추출처럼 자동 생성 도구를 병행하면 최신성을 확보할 수 있다. 대신 런타임 환경 의존성이 늘고 보안 데이터가 노출될 위험이 있다. 상태 변화의 원인까지 분석해야 한다면 시퀀스 다이어그램이나 상태 다이어그램을 함께 관리해야 하며, 그만큼 산출물 유지보수 비용도 증가한다.

객체 다이어그램을 활용하면 설계 리뷰 시간은 2030% 단축되고 논의 초점이 명확해질 가능성이 있다. 다중성·합성 위반의 사전 발견률은 1020%p 향상을 기대할 수 있으며, 픽스처 설계 시간은 30% 내외 절감되고 재사용률이 늘어난다. 신규 인력의 도메인 이해 기간을 줄이고 문서와 코드 사이의 괴리를 낮추는 데도 연결된다.