UML을 설계·리뷰·자동화 흐름에 연결하는 학습 로드맵

UML은 설계 대화를 기록하는 공통 언어다

UML(Unified Modeling Language)은 소프트웨어와 시스템 설계를 시각적으로 표현하는 표준 모델링 언어다. 객체 지향 분석·설계에서 요구사항, 정적 구조, 행위를 문서화할 때 사용한다. 목적은 다이어그램 자체를 만드는 데 있지 않다. 이해관계자가 같은 설계 판단을 공유하게 하고, 변경 관리와 추적성을 유지하는 데 있다.

구조 다이어그램은 클래스, 컴포넌트, 배치, 패키지처럼 시스템의 정적 구성을 다룬다. 유스케이스, 시퀀스, 활동, 상태 다이어그램은 동작 흐름과 상태 전이를 표현한다. 모든 다이어그램을 같은 비중으로 익히기보다 프로젝트에 맞는 핵심 다이어그램 4~5종에 먼저 집중하는 20/80 접근이 실용적이다.

표기법 다음에는 추적성과 협업 흐름을 붙인다

학습은 기초 표기법에서 시작하지만, 모델을 요구사항·코드·테스트와 연결할 수 있어야 실제 설계 산출물로 기능한다. 표기법, 핵심 다이어그램, 요구사항 추적, 아키텍처 모델링, 코드·테스트 연계, 팀 자동화의 흐름으로 확장한다.

텍스트 기반 도구인 PlantUML과 Mermaid, GUI 기반 도구인 StarUML과 Visual Paradigm을 함께 이해할 필요가 있다. 스테레오타입과 프로파일로 도메인에 맞춘 표현을 만들고, UML 2.x 표준을 기준으로 관계와 표기의 일관성을 관리한다. 모델 리뷰, 트레이서빌리티 링크, 변경 요청 워크플로우를 운영하고 CI에 모델 검증과 다이어그램 생성 파이프라인을 연결하는 단계까지가 범위다.

학습 산출물을 설계 작업으로 이어가기

⤢✕

기초 단계에서는 UML 표기법과 각 다이어그램의 목적을 구분하고, 연관·집합·합성·일반화 관계를 익힌다. 이때 남겨야 할 산출물은 도메인 용어사전, 표기법 치트시트, 간단한 예제 다이어그램이다.

그다음 유스케이스, 클래스, 시퀀스, 활동, 상태 다이어그램을 중심으로 기능 범위와 주요 클래스, 인터랙션 시나리오, 핵심 흐름을 모델링한다. 복잡도를 늘리기보다 설계 대화에 반복해서 쓰이는 모델을 우선 확보하는 단계다.

요구사항 ID를 유스케이스·클래스·테스트 케이스와 연결하면 변경이 발생했을 때 영향을 추적할 수 있다. 이 단계의 결과물은 트레이스 매트릭스, 변경 영향도(Impact) 목록, 누락·중복 탐지 리포트다.

아키텍처 단계에서는 컴포넌트, 배치, 패키지 다이어그램으로 계층·경계·배포 구조를 명시한다. GoF/DDD 패턴을 적용하면서 경계·엔티티·서비스 구조, 배포 노드와 네트워크 제약, 비기능 요구사항 매핑을 남긴다.

모델을 코드와 테스트에 연결할 때는 모델에서 코드 스캐폴딩을 만들고, 시퀀스 다이어그램에서 계약 기반 테스트 시나리오를 추출한다. 코드 골격, 테스트 케이스 스텁, 모델-코드 싱크 규칙이 이 단계의 산출물이다.

마지막으로 PR 리뷰 체크리스트, 모델 린팅, CI 다이어그램 생성 파이프라인을 팀 흐름에 정착시킨다. 모델 가이드라인, 린트 룰셋, 자동화 스크립트가 운영 기반이 된다.

모델링 작업은 입력부터 변경 이력까지 관리한다

입력은 요구사항 정의서, 도메인 용어, 기존 시스템 문서다. 요구사항에 맞는 다이어그램을 선택하고 모델을 작성한 뒤 자동 검증(린팅), 리뷰·수정, 트레이스 링크 생성을 수행한다. 결과물은 버전관리된 모델 리포지토리, PDF/HTML 산출물 패키지, 변경 이력으로 관리한다.

요구사항의 모호성이 드러나면 질문 리스트를 만들고 PO/BA 확인 라운드로 넘긴다. 모델 불일치가 발견되면 린트 룰을 적용해 수정 커밋을 만들고 리뷰를 다시 요청한다.

도구는 협업 방식과 모델의 성격에 맞춰 고른다

텍스트 기반 도구는 Git과 CI에 연결하기 쉽지만 대규모 모델을 탐색하는 데 한계가 있다. GUI 모델러는 탐색과 레이아웃, 일관성 검사에 강점이 있는 대신 협업과 버전 충돌 관리를 별도로 다뤄야 한다. draw.io와 FigJam 같은 화이트보드·캔버스 도구는 초기 아이데이션에 적합하지만 표준의 엄격성과 추적성에는 한계가 있다.

접근 방식	성능	확장성	일관성	안정성	운영 편의
텍스트 기반(PlantUML/Mermaid)	상	상	중(룰 추가 시 상)	상	상(Git/CI 연계 용이)
GUI 모델러(StarUML/VP)	중	상	상(내장 검사)	상	중(협업 세팅 필요)
화이트보드/다이어그램 툴	상	하	하	중	상(학습 부담 낮음)

모델을 쓰는 장면에서 확인할 수 있는 변화

신규 기능 킥오프에서는 요구사항 워크샵 뒤에 유스케이스·시퀀스를 작성하고, 클래스 스케치와 트레이스 매핑을 거쳐 리뷰한다. 이 2주 프레임에서는 시나리오 누락 30% 감소와 개발 착수 전 리스크 가시화를 기대할 수 있다.

레거시 역공학과 리팩터링에서는 코드에서 클래스·컴포넌트 다이어그램을 추출하고 순환 의존을 감지한 뒤 패키지 경계를 다시 설계한다. 컴파일 타임 의존성 25% 축소, 빌드 시간 15% 단축이 결과로 제시된다.

마이크로서비스 경계를 설계할 때는 컨텍스트 맵에서 컴포넌트·배치 모델로 이어가고, API 시퀀스와 비기능 요구사항을 매핑한다. 서비스 간 결합도를 낮추고 장애 격리성을 높이는 데 사용한다.

요구·설계 단계의 결함 유입률은 2035% 감소할 수 있고, 설계 리뷰 시간은 1530% 단축될 수 있다. 영향도 분석 자동화는 변경 리드타임을 1025% 단축하며, 신규 인력 온보딩 기간은 20% 내외로 줄어들 수 있다. 모델 린팅과 체크리스트를 적용하면 리뷰 재작업률도 1020% 감소한다.

모델을 코드처럼 관리하는 습관

경계·엔티티·서비스를 구분하는 명명 규칙과 스테레오타입을 정하고, 관계 라벨도 일관되게 유지한다. 요구사항 ID에서 유스케이스, 시퀀스, 테스트 케이스로 이어지는 링크를 필수로 관리한다.

모델은 Git 브랜치·PR·CI를 사용하는 코드와 같은 방식으로 버전관리한다. 커밋 훅에서 다이어그램 재생성과 린팅을 수행하고, 리뷰에서는 다이어그램이 목적에 맞는지, 불필요하게 상세하지 않은지, 책임과 경계가 명확한지를 확인한다.

주문 도메인 모델 예시

실행 전제는 Java 11+와 PlantUML 1.2023.x다.

@startuml
title 주문 도메인 클래스 다이어그램

class Order {
  - id: Long
  - status: OrderStatus
  + addItem(i: OrderItem)
  + total(): Money
}

class OrderItem {
  - price: Money
  - qty: int
}

class Customer {
  - id: Long
  + placeOrder(): Order
}

enum OrderStatus {
  CREATED
  PAID
  SHIPPED
}

Customer "1" --> "many" Order
Order "1" *-- "many" OrderItem

@enduml

UML의 가치는 표기법을 많이 아는 데서 생기지 않는다. 핵심 다이어그램으로 설계 판단을 공유하고, 추적성과 일관성 검증을 유지하며, 이를 리뷰와 CI 흐름에 연결할 때 팀의 작업 방식이 된다.