2025. 7. 23. 21:01ㆍIT 독후감
개발을 하다 보면 설계 문서에 UML 다이어그램이 등장할 때가 있다.
하지만 나는 UML을 볼 때마다 복잡하다는 느낌부터 들었다.
도형과 선, 기호들이 잔뜩 있는 그림을 보며 “이걸 꼭 알아야 하나?” 싶었다.
그러다 이 책, **『UML 실전에서는 이것만 쓴다』**를 읽게 되었다.
제목 그대로였다. UML 중에서도 실제 프로젝트에서 ‘진짜’ 쓰이는 것만 보여준다.
이 책을 덮고 나니, UML이 단순히 ‘문서화 수단’이 아니라
팀과 함께 설계를 공유하고, 문제를 예방하는 강력한 커뮤니케이션 도구라는 걸 알게 되었다.
📜 UML을 잘 쓰는 법은 ‘많이 아는 것’이 아니다
책에서는 UML을 ‘전문가처럼’ 그릴 필요가 없다고 말한다.
오히려 다 같이 이해할 수 있는 언어로, 필요한 만큼만, 명확하게 표현하는 것이 핵심이다.
저자는 우리가 실제로 자주 쓰는 다이어그램만 간결하게 설명한다.
- 클래스 다이어그램: 객체와 속성, 관계의 구조를 이해할 때
- 유스케이스 다이어그램: 사용자 요구와 기능을 설계 단계에서 정리할 때
- 시퀀스 다이어그램: 객체 간 메시지 흐름을 시간 순서로 표현할 때
- 상태 다이어그램: 객체의 상태 변화가 핵심일 때 (예: 로그인 → 인증 → 세션 유지)
중요한 건 “왜 이걸 쓰는가?”에 대한 명확한 이유였다.
그냥 ‘그리기 위해 그리는 UML’이 아니라, 의도를 전달하고 오해를 줄이기 위한 도구로 쓰자는 것이다.
🧭 문서가 아니라, 대화의 시작점으로
인상 깊었던 부분은 UML을 **“대화를 위한 시각적 언어”**로 정의한 점이다.
문서화가 목적이 아니라, 설계에 대해 팀원들과 함께 고민하고, 공유하고, 더 나은 구조를 찾아가는 출발점이라는 것.
그래서 복잡한 툴보다는 종이와 펜, 화이트보드에 그려가며 팀원들과 이야기하라는 조언도 나온다.
디자인을 시각화하는 순간, 추상적인 아이디어가 구체적인 토론 거리로 바뀐다.
이건 실제 회의에서도 충분히 경험할 수 있는 장면이라, 깊이 공감됐다.
🛠️ UML이 어려운 이유는 ‘욕심’ 때문
책을 읽고 나니, UML이 어려웠던 이유는 **“모든 걸 완벽히 표현하려 했기 때문”**이었던 것 같다.
그 대신 이 책은 “실제로 필요한 만큼만 쓰라”고 말한다.
- 오버스펙 설계는 피하라
- UML이 목적이 되지 않게 하라
- 이해 가능한 설계가 가장 좋은 설계다
즉, UML을 쓰는 목적은 ‘디자인을 정리하는 도구’이지, 멋진 다이어그램을 그리는 게 아니라는 것.
이 실용주의적 관점은 개발자에게 꼭 필요한 태도라고 느껴졌다.
✍️ 마무리하며 – 개발자는 코드 이전에 구조를 생각하는 사람
『UML 실전에서는 이것만 쓴다』는 UML을 멋지게 그리는 법이 아니라,
**“실제 개발에서 UML을 어떻게 활용할 수 있는가”**에 대한 책이다.
이 책 덕분에 나는 UML을 필요할 때 꺼내 쓰는 도구로 자연스럽게 인식하게 되었다.
꼭 복잡한 설계를 위한 게 아니라, 간단한 클래스 관계 하나, 흐름 하나를 공유할 때도 충분히 쓸 수 있는 유용한 무기라는 걸 알게 된 것이다.
코드를 잘 짜기 위해선, 그 전에 구조를 잘 이해해야 한다.
그리고 그 구조를 공유하고 설계하는 과정에서 UML은 강력한 도구가 된다.
특히 현업에서 개발 중이지만 UML이 부담스러웠던 사람,
그리고 설계나 요구사항을 좀 더 시각적으로 정리하고 싶은 사람에게 이 책은 강력히 추천 하고 싶다.

'IT 독후감' 카테고리의 다른 글
| 『테스트 주도 개발』 – 코딩이 아닌 ‘생각하는 습관’을 만드는 연습 (1) | 2025.07.24 |
|---|---|
| 『소프트웨어 장인 정신 이야기』 – 기술 이전에 태도와 철학부터 (1) | 2025.07.24 |
| 『클린 애자일』 – 변하는 시대, 변하지 않는 민첩함 (0) | 2025.07.23 |
| 『클린 소프트웨어』 – 기술보다 오래가는 원칙 (2) | 2025.07.23 |
| 『클린 아키텍처』 – 좋은 구조는 나이 들수록 빛난다 (1) | 2025.07.22 |