UML (Unified Modeling Language)
요구 모델링을 할 때 어떤 기호/표기법으로
그림을 그릴 것인가?는 생각보다 중요하다.
표기법이 제각각이면 같은 시스템을 보고도
서로 다르게 해석할 수 있기 때문이다.
그래서 실무에서 가장 보편적으로 쓰이는
표준 표기법이 UML(Unified Modeling Language) 이다.
UML은 소프트웨어 모델링을 위한 공통 언어라고 보면 된다.
UML은 “표기법”이지 “방법론”이 아니다
많이 헷갈리는 포인트.
- UML은 소프트웨어를 표현하는
표준 기호/다이어그램(표기법) 이다. - UML 자체가 “이 순서로 개발해라” 같은
프로세스/방법론을 정해주진 않는다.
다만 UML을 활용하는 대표적인 흐름은
보통 이런 성격을 권장한다.
- 유스케이스 주도(use-case driven)
- 아키텍처 중심(architecture-centric)
- 반복/점진(iterative & incremental)
즉, UML은 “지도(표현)”이고,
방법론은 “여행 루트(프로세스)”에 가깝다.
UML의 역사: 왜 ‘Unified’일까?
UML의 Unified(통합된) 는 말 그대로
1990년대 후반에 존재하던 여러 객체지향
분석/설계 표기법을 통합해서 표준화했다는 의미다.
초안은 크게 아래 3가지
객체지향 방법론 표기법이 합쳐진 것이다.
- Grady Booch 방법론
- James Rumbaugh의 OMT
(Object-Modeling Technique) - Ivar Jacobson의 OOSE
(Object-Oriented Software Engineering)
이 배경 덕분에 UML은 원래부터
객체지향 스타일(클래스/객체/관계/상호작용) 을 잘 지원하고,
객체지향 개념에 익숙할수록 UML을 더 쉽게 이해할 수 있다.
UML 다이어그램: “정적(구조)” + “동적(동작)”을 같이 본다
소프트웨어가 복잡한 이유 중 하나는
구조(정적) 와 동작(동적) 을 동시에 가진다는 점이다.
- 코드를 처음 볼 때는
클래스/메서드/데이터 구조 같은
정적 요소를 먼저 보게 된다. - 실행 흐름을 이해하려면
시간이 지나며 상태가 바뀌고 메시지가 오가는
동적 요소를 상상해야 한다.
UML은 이 두 관점을 모두 다루도록 다이어그램을 제공한다.
UML 2.x 다이어그램 분류 (총 13개)
UML 2.x는 다이어그램을 크게
구조(Structure) 와 동작(Behavior) 로 나눈다.
1) 구조 다이어그램(정적) — 6개
시간 개념이 없고 “무엇이 있고 어떻게 연결됐는지”를 보여준다.
- 클래스 다이어그램
- 객체 다이어그램
- 컴포넌트 다이어그램
- 배치(Deployment) 다이어그램
- 패키지 다이어그램
- 컴포지트 구조(Composite Structure) 다이어그램
2) 동작 다이어그램(동적) — 7개
시간 흐름/상태 변화/프로세스 흐름을 보여준다.
- 유스케이스 다이어그램
- 액티비티 다이어그램
- 상태 다이어그램
- 인터랙션(상호작용) 다이어그램 4종
- 시퀀스 다이어그램
- 커뮤니케이션 다이어그램
- 인터랙션 오버뷰 다이어그램
- 타이밍 다이어그램
UML도 “언어”다: 문법(Syntax)과 의미(Semantics)
모델링 언어도 프로그래밍 언어처럼
규칙(문법)과 뜻(의미) 로 정의된다.
- 구문(Syntax)
: 표준 기호가 어떻게 생겼고,
다이어그램에 어떻게 배치하는가 - 의미(Semantics)
: 그 기호가 무엇을 뜻하는가
예를 들어 유스케이스 다이어그램의
액터(사람 모양)는 보통 이런 의미로 이해한다.
- 시스템 밖에 존재하는 사용자/외부 요소
- “사람” 그 자체라기보다 역할(Role) 을 나타냄
UML은 엄밀히 정의되어 있지만,
실무에서는 이해를 돕기 위해 약간의
비공식 표기(메모/주석/간단한 표시)를 섞기도 한다.
다만 공식 문법/의미에서 너무 멀어지면
서로 해석이 달라져 위험해진다.
요구 모델링에서 특히 많이 쓰는 UML 5대 다이어그램
요구 모델링에서 보통 이 5개가 핵심이다.
1) 유스케이스 다이어그램
- 무엇을 표현?
누가(액터) 어떤 업무를(유스케이스)
시스템과 상호작용하는지 - 언제 쓰나?
시스템 범위/큰 그림(업무 프로세스)을 잡을 때
2) 클래스 다이어그램
- 무엇을 표현?
도메인 개념(클래스)과
관계(연관/상속/집합 등), 속성/오퍼레이션 - 언제 쓰나?
“이 시스템에서 중요한 개념이 뭐지?”를 구조로 정리할 때
(= 도메인 모델의 핵심 도구)
3) 시퀀스 다이어그램
- 무엇을 표현?
유스케이스(업무 흐름)를 수행할 때
객체들이 시간 순서대로 어떤 메시지를 주고받는지 - 언제 쓰나?
“이 기능이 실제로 어떻게 굴러가야 하지?”를
팀이 같은 그림으로 맞출 때
4) 상태 다이어그램
- 무엇을 표현?
상태(state)와 상태 전이(transition) - 언제 쓰나?
상태 의존적/반응적 시스템에서 특히 유용
(예: 결제 진행 상태, 주문 상태, 로그인 상태, 승인/취소 흐름 등)
5) 액티비티 다이어그램
- 무엇을 표현?
작업(activity) 중심의 흐름,
자료/제어 흐름, 분기/병렬/동기화 - 언제 쓰나?
복잡한 업무 흐름(프로세스)을 단계별로 정리할 때
UML 모델링 과정
UML 모델링은 “클래스만 그리면 끝”이 아니라
구조 + 동작을 함께 맞춰가며 완성도를 높이는 방식이 자연스럽다.
대표적인 진행 흐름 예시는 아래처럼 정리할 수 있다.
- 요구를 유스케이스로 정리하고 유스케이스 다이어그램 작성
- 클래스 후보를 찾아 개념적 도메인 모델 작성
- 유스케이스 기반으로 시퀀스 다이어그램 작성
- 클래스 속성/오퍼레이션/관계 확정 → 도메인 모델 보완
- 상태/액티비티 등 필요한 다이어그램 추가해 모델 완성
- 서브시스템을 파악하고 전체 구조(아키텍처) 설계
- 적당한 객체를 선정/커스터마이징/새로 설계
모델링을 잘 하려면 (체크리스트)
- 복잡한 문제라면 도메인을
잘 아는 전문가와 같이 모델링한다. - 각 모델의 목적을 잘 이해하고 모델링을 위하여
어떤 정보가 필요한지 잘 알아둔다. - 한 번 그린 모델로 만족하지 않고
계속 논의하고 향상시켜 나간다.(=리팩토링이라 함) - 소그룹 회의를 열어 모델을 화이트보드에 그리고 토의한다.
- 디자인 패턴을 잘 숙지하고 필요하면 이를 이용한다.
마무리
UML은 소프트웨어 모델을 표현하는 업계 표준 공통 언어다.
그리고 UML의 핵심 가치는 “그림을 예쁘게 그리는 것”이 아니라,
- 복잡한 시스템을 정적(구조) + 동적(동작) 으로 나눠 이해하고
- 팀이 같은 해석을 하도록 의사소통 비용을 줄이는 것에 있다.
요구 모델링 단계에서 UML을 잘 써두면,
설계/구현으로 넘어갈 때 “말이 통하는 속도” 자체가 달라진다.
'개주 훈련일지 > 📚 코살대 교본 학습' 카테고리의 다른 글
| SQL) ORDER BY절 (0) | 2026.01.17 |
|---|---|
| 정적 모델링 (0) | 2026.01.17 |
| SQL) GROUP BY, HAVING절 (1) | 2026.01.13 |
| SQL) 함수 (0) | 2026.01.12 |
| SQL) WHERE절 (0) | 2026.01.12 |