80 lines
8.9 KiB
Markdown
80 lines
8.9 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-wikified, technical-documentation]
|
|
title: UML (Unified Modeling Language)
|
|
description: "UML(Unified Modeling Language)은 소프트웨어 엔지니어링에서 시스템 아키텍처와 구조를 시각적으로 표현하기 위해 널리 사용되는 표준화된 모델링 언어이다 [1, 2]."
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# UML (Unified Modeling Language)
|
|
|
|
## 📌 Brief Summary
|
|
UML(Unified Modeling Language)은 소프트웨어 엔지니어링에서 시스템 아키텍처와 구조를 시각적으로 표현하기 위해 널리 사용되는 표준화된 모델링 언어이다 [1, 2]. 클래스 다이어그램, 시퀀스 다이어그램 등 다양한 다이어그램을 제공하여 복잡한 코드베이스의 정적 구조와 동적 상호작용을 명확히 파악할 수 있도록 돕는다 [1, 3, 4]. 엔지니어들 사이의 공통된 시각적 언어로 기능하여 시스템 설계에 대한 소통과 문서화를 지원한다 [4, 5].
|
|
|
|
## 📖 Core Content
|
|
* **표준 및 생태계**
|
|
* OMG(Object Management Group)에 의해 정의된 UML은 소프트웨어 엔지니어링 교육의 필수 요소이자 가장 널리 사용되는 모델링 표준 중 하나이다 [2].
|
|
* 오픈 소스인 PlantUML부터 MagicDraw, Rhapsody와 같은 고급 상용 도구에 이르기까지 다양한 도구를 통해 지원되며, 총 14가지의 다이어그램 유형을 제공한다 [2, 3].
|
|
* **코드베이스 이해를 위한 핵심 다이어그램**
|
|
* **클래스 다이어그램 및 객체 다이어그램 (Class and Object Diagrams):** 가장 일반적으로 사용되는 유형으로, 시스템의 정적 구조를 명확히 표현한다 [3, 4]. 데이터 모델을 정의하며, 클래스 및 객체 간의 연관(Association), 집계(Aggregation), 합성(Composition), 상속(Inheritance), 실체화(Realization), 의존성(Dependency) 관계를 상세히 규정한다 [3].
|
|
* **시퀀스 다이어그램 (Sequence Diagrams):** 시간 흐름에 따른 객체 간의 동적 상호작용과 메시지 교환을 시각화한다 [4, 6]. 대안 경로, 병렬 처리, 루프 등의 상세한 로직을 포함할 수 있어 API 설계와 단위, 통합, 시스템 테스트의 기준을 정의하는 데 매우 유용하다 [6].
|
|
* **기타 다이어그램:** 목적에 따라 유즈케이스(Use-case), 패키지(Package), 상태 차트(Statechart), 통신(Communication), 배포(Deployment), 활동(Activity) 다이어그램 등이 활용된다 [1, 7, 8].
|
|
* **다른 아키텍처 모델과의 관계**
|
|
* 소프트웨어 아키텍처를 계층적으로 표현하는 C4 모델에서, 가장 깊은 수준인 '코드(Level 4: Code)' 계층의 내부 구조를 표현할 때 주로 UML 클래스 다이어그램이 선택적으로 사용된다 [9].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **과도한 복잡성 및 오버스펙 (Over-specification):** UML은 의미론적으로 매우 정밀한 명세를 가능하게 하지만, 이로 인해 다이어그램이 불필요하게 복잡해지거나 오버스펙 상태가 될 위험이 있다 [3].
|
|
* **이해관계자 간의 소통 혼란:** 상기한 복잡성으로 인해, 높은 수준의 기술적 지식이 없는 이해관계자들에게는 오히려 다이어그램의 의도가 왜곡되거나 혼란을 초래할 수 있다 [3].
|
|
* **공식적 검증의 한계:** 특수한 도구를 사용하는 일부 고급 사례를 제외하면, 일반적으로 UML 다이어그램 자체를 코드처럼 엄격하게 공식 검증(formally validated)하기는 어렵다 [5].
|
|
* **코드와의 동기화 및 유지보수 문제:** 과거 IBM Rhapsody와 같은 도구들이 UML 모델을 코드로 자동 생성(Code generation)하고 양방향 동기화(Round-tripping)를 시도했으나, 개발자들이 생성된 코드 대신 직접 작성하는 것을 선호하면서 UML 다이어그램이 실제 코드와 괴리되어 빠르게 무용지물이 되는 현상이 발생하기도 했다 [10].
|
|
|
|
## 🔗 Knowledge Connections
|
|
|
|
### Related Concepts
|
|
|
|
#### [시각적 모델링 및 아키텍처 (Visual Modeling & Architecture)]
|
|
- [[C4 Model]]
|
|
- 연결 이유: C4 모델의 4단계(Context, Container, Component, Code) 중 마지막 코드 레벨 구조를 표현할 때 UML이 직접적으로 사용된다 [9, 11, 12].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상화 수준이 높은 아키텍처 뷰에서 어떻게 UML과 같은 상세 구현 뷰로 논리적으로 전환할 수 있는지 파악할 수 있다.
|
|
- [[Architecture Diagrams]]
|
|
- 연결 이유: UML은 소프트웨어 청사진을 제공하는 아키텍처 다이어그램의 가장 대표적이고 고전적인 표준 규격이다 [2, 13].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라우드 기반 아키텍처 다이어그램 등 다른 유형의 다이어그램과 UML의 목적 및 표현 방식의 차이를 이해할 수 있다.
|
|
|
|
#### [주요 다이어그램 유형 (Diagram Types)]
|
|
- [[Class Diagram]]
|
|
- 연결 이유: UML에서 코드의 데이터 모델과 정적 구조(상속, 의존성 등)를 표현하는 가장 핵심적인 다이어그램이다 [3, 4].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 지향 프로그래밍에서 컴포넌트 간의 결합도와 설계의 구조적 안정성을 파악하는 방법을 이해할 수 있다.
|
|
- [[Sequence Diagram]]
|
|
- 연결 이유: 객체 간의 동적인 상호작용과 API 통신 과정을 표현하는 데 특화된 UML 다이어그램이다 [4, 6].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 로직 내에서 호출 스택의 흐름이나 비동기 작업의 순서를 시각적으로 추적하는 원리를 학습할 수 있다.
|
|
|
|
#### [구현/활용 도구 (Implementation & Tools)]
|
|
- [[PlantUML]]
|
|
- 연결 이유: UML 다이어그램을 코드로 작성(Diagrams as code)할 수 있게 해주는 대표적인 오픈 소스 도구이다 [2, 14, 15].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 텍스트 기반으로 다이어그램을 생성하여 버전 관리와 유지보수의 효율성을 높이는 방법을 배울 수 있다.
|
|
|
|
### Deeper Research Questions
|
|
|
|
- UML 클래스 다이어그램에서 집계(Aggregation)와 합성(Composition)의 차이는 실제 코드베이스(메모리 관리 및 생명주기)에서 어떻게 다르게 구현되는가?
|
|
- 비기술 직군의 이해관계자에게 시스템을 설명할 때, UML의 복잡성을 줄이고 C4 모델이나 클라우드 다이어그램으로 전환해야 하는 판단 기준은 무엇인가?
|
|
- UML 시퀀스 다이어그램을 활용하여 시스템 테스트나 통합 테스트 시나리오를 효과적으로 도출하는 방법론은 무엇인가?
|
|
- 대규모 마이크로서비스 환경에서 UML 모델과 실제 코드 간의 아키텍처 드리프트(Architectural Drift)를 방지하기 위한 자동화 도구(예: vFunction 등)의 원리는 어떻게 동작하는가?
|
|
- 14가지의 UML 다이어그램 중 현대의 애자일 개발 및 클라우드 네이티브 환경에서 여전히 높은 실효성을 가지는 다이어그램은 무엇이며, 도태된 다이어그램의 원인은 무엇인가?
|
|
|
|
### Practical Application Contexts
|
|
|
|
- **Implementation:** 클래스의 의존성, 상속 구조를 설계하거나 파악해야 할 때 클래스 다이어그램을 그려 코드의 응집도와 결합도를 시각적으로 검토할 수 있다 [3, 4].
|
|
- **System Design:** 새로운 API나 복잡한 알고리즘을 구현하기 전, 시퀀스 다이어그램을 작성하여 다양한 대안 경로와 예외 처리(루프, 분기) 시나리오를 설계하고 소통한다 [6].
|
|
- **Operation / Maintenance:** 기존 시스템의 레거시 코드를 읽을 때, 호출 스택을 추적하여 객체 간 메시지 통신을 보여주는 시퀀스 다이어그램을 리버스 엔지니어링하여 동적 특성을 문서화할 수 있다 [4, 6].
|
|
- **Learning Path:** 복잡한 소프트웨어 시스템의 디자인 패턴을 이해하고, 시니어 엔지니어와 원활히 기술적 논의를 하기 위해 필수적으로 익혀야 하는 공통 언어이다 [4, 16].
|
|
- **My Project Relevance:** 문서화되지 않은 레거시 시스템을 리팩토링할 때, PlantUML 등을 활용해 현재의 코드 구조를 UML 다이어그램으로 시각화하여 팀 내 온보딩 속도를 높일 수 있다.
|
|
|
|
### Adjacent Topics
|
|
|
|
- [[Design Patterns]]
|
|
- 확장 방향: UML은 싱글톤, 팩토리, 옵저버 등 구조적/행위적 디자인 패턴의 작동 방식을 설명하고 시각화하는 데 표준적으로 사용되므로 패턴 학습으로 이해를 확장할 수 있다 [16-18].
|
|
- [[Domain-Driven Design (DDD)]]
|
|
- 확장 방향: UML의 객체 및 클래스 모델링 기법을 사용하여 DDD의 핵심 요소인 엔티티(Entity), 값 객체(Value Object), 애그리거트(Aggregate)의 관계를 어떻게 설계하는지 파악할 수 있다 [19].
|
|
|
|
---
|
|
*Last updated: 2026-05-02* |