OOD [7] - UML 다이어그램을 그릴 줄 알아도 왜 객체 설계 면접에서 점수를 못 받는가
OOD, Object Oriented Design 모델링 디자인 예제 UML 에 대해 알아봅니다.
이전 챕터에서 주차장 시스템을 Python으로 직접 구현하면서 SOLID와 패턴을 느껴보셨죠? 이번 챕터에서는 그걸 그림으로 정리하는 법을 배워봅니다.
바로 UML(Unified Modeling Language)입니다.
Introduction to Object-Oriented Analysis and Design (OOAD)
OOAD = Object-Oriented Analysis + Design
Analysis (분석)
“무엇을 만들어야 하나?” → 요구사항 이해, 유스케이스 찾기
Design (설계)
“어떻게 만들까?” → 클래스 구조, 상호작용, 흐름 설계
Why UML?
UML(Unified Modeling Language)은 소프트웨어 설계를 시각화하는 표준 언어로, 클래스 다이어그램, 시퀀스 다이어그램 등 다양한 그림으로 복잡한 시스템을 명확하게 표현합니다.
하지만,
Google, Facebook 등 빅테크 기업
“Facebook, Google 같은 곳에서 UML 거의 안 쓴다”고 해요. 이유? 아웃소싱(외주) 시에만 사용, 내부에서는 애자일 때문에 “코드가 문서”라는 문화. Google은 간단한 시퀀스/플로우차트만 쓰고, 전체 UML 스펙은 과잉이라고 봅니다.
Jeff Bezos (Amazon)
Amazon의 “Working Backwards” (고객 중심 문서부터 시작) 문화는 UML 같은 시각화보단 PR/FAQ 문서 중시. 복잡성을 피합니다. 또한, Facebook 엔지니어들은 “UML은 학술적, 실무에선 덜 필요”라고 언급하며, 애자일 영향으로 “빠른 프로토타입 > 다이어그램”.
Linus Torvalds (Linux 창시자, 빅테크 영향력자)
UML 비판적. “UML은 다이어그램으로 코드를 꾸미는 거, 실제 코딩이 더 중요” 비슷한 의견. 그는 형식적 방법론을 싫어해요.
위와 같은 상황들 때문에 팀에서 공식적으로 설계하는데 시간을 이 도구에 사용하거나 하는 것 보다는 혼자 설계를 해야 되는 상황 또는 팀원들에게 설명할 때 유용할 수 있어서 개인적으로는 알아두는 것을 권장합니다.
1. Use Case Diagram
무엇을 보여주나?
누가(Actor) 시스템을 어떻게(Use Case) 사용하는지
시스템 경계(Boundary) 안/밖 구분
주요 요소
Actor (사람/외부 시스템): stick figure
Use Case: 타원
Include / Extend 관계
System Boundary: 네모 박스
주차장 예시
[Driver] ----> (Enter Parking Lot)
[Driver] ----> (Park Vehicle)
[Driver] ----> (Pay Fee) <<include>> (Calculate Fee)
[Driver] ----> (Exit Parking Lot)
[Payment Gateway] ----> (Process Payment) <<extend>> (Apply Discount)요구사항 문서 → 액터 찾기 → 각 액터가 하는 일(동사) → 유스케이스 목록화
→ 이게 없으면 나중에 “이 기능은 누가 쓰는 거지?” 할 수 있습니다.
2. Class Diagram (클래스 다이어그램)
무엇을 보여주나?
시스템의 정적 구조 (클래스, 속성, 메서드, 관계)
주요 요소
Class
직사각형 (위→아래: 이름 / 속성 / 메서드)
관계
Association, Inheritance(화살표 삼각), Aggregation(빈 다이아몬드), Composition(꽉 찬 다이아몬드)
주차장 예시
+-----------------+
| <<abstract>> |
| Vehicle |
+-----------------+
| - licensePlate |
| + getType() |
+-----------------+
^
|
+----------+ | +----------+
|Motorcycle|-----+----- | Car |
+----------+ +----------+
| |
v v
+-----------------+ +-----------------+
| MotorcycleSpot | | CompactSpot |
+-----------------+ +-----------------+주차장처럼 Vehicle ↔ ParkingSpot 관계가 핵심 → Association + multiplicity (1..*, 0..1 등) 잘 표시하세요. 면접에서 자주 물어봅니다. 하지만 인터뷰에 따라 다르기 때문에 인터뷰어가 원하지 않는 경우도 있고 시간이 부족한 경우가 있습니다. 그래서 그림으로 설명드려도 되는지 의견을 구하고 사용하는 것을 권장드립니다.
3. Sequence Diagram (시퀀스 다이어그램)
무엇을 보여주나?
특정 시나리오(예: 입차)에서 시간 순서대로 객체 간 메시지 교환
주요 요소
Lifeline (세로 점선): 객체/액터
Message (화살표): 동기(실선) / 비동기(점선)
Activation bar (세로 직사각형): 처리 중
주차장 입차 예시
Driver ParkingLot ParkingFloor ParkingSpot
| | | |
|---enter()-->| | |
| |--findSpot()->| |
| | |---canPark()-->|
| |<--spot-------| |
| |---park()---->| |
|<--Ticket----| | |“이 기능이 어떻게 동작하나?” 설명할 때 최고. alt/loop/opt 프레임으로 분기 표현 가능.
이 시퀀스 다이어그램은 꽤 많이 사용됩니다. 개발 실무에서도 문서화 된 부분들을 회사에 따라 다르겠지만 보실 수 있습니다.
4. Activity Diagram (액티비티 다이어그램)
무엇을 보여주나?
프로세스 흐름 (플로우차트 + UML 버전)
주요 요소
Action (둥근 사각형)
Decision (다이아몬드)
Fork/Join (굵은 바): 병렬 처리
Swimlane: 역할별 구분
주차장 출차 예시
[Start] → [Present Ticket] → [Validate Ticket?]
↓ Yes ↓ No
[Calculate Fee] [Reject Exit]
↓
[Process Payment] → [Open Gate] → [End]비즈니스 프로세스나 복잡한 로직 설명할 때 사용. Swimlane 넣으면 “누가 뭐 하는지” 명확해짐.
Quiz
시스템의 정적 구조를 보여주는 다이어그램은?
Class Diagram
사용자와 시스템의 기능적 상호작용을 보여주는 다이어그램은?
Use Case Diagram
특정 시나리오의 시간 순서 메시지 흐름을 보여주는 다이어그램은?
Sequence Diagram
프로세스 흐름과 분기·병렬을 표현하는 다이어그램은?
Activity Diagram
“새로운 차종 추가 시 기존 클래스 다이어그램 거의 안 고치고 확장”하려면 어떤 관계를 써야 하나?
Generalization (상속, 삼각 화살표)
마무리 한마디
UML은 “그림 그리는 기술”이 아니라 생각을 정리하고 소통하는 도구예요.
처음엔 어색해도, 3~4번 그려보면 “아 이렇게 하는거구나” 싶으실겁니다.
노트에 자신이 구현해야 하는 기능을 설계할 때도 그려보는 것이 도움이 됩니다.
또한 개발 문서화가 부족하다면 이러한 다이어그램으로 문서화를 해서 회사 히스토리 관리에 기여할 수도 있습니다.