개발 실무에서 UML을 어디까지 그려야 할까?

들어가며

실무에서 UML을 그려야 하는 상황에 부딪히면 다음과 같은 고민이 생긴다.

"이걸 어디까지 그려야 하지?", "UML을 잘 그리는 방법이 뭐지?"

실무에서 내가 선택한 기준과 작성방법을 정리해 보았다.

나는 UML에 대한 개념을 아래 자료를 통해 배웠고, C++ 스타일로 조금 변형해 사용하고 있다.
https://github.com/ashishps1/awesome-low-level-design

UML은 어떻게 작성하는가

다이어그램 작성에는 draw.io 웹 서비스를 사용한다.

클래스 다이어그램을 기본으로 선택한 뒤,

"UML"과 "VMware Validated Design" 탭을 추가해 아이콘을 적극 활용한다.

UML의 작성 목적은 의사소통으로, "이 UML을 누가 읽을 것인가?"를 항상 먼저 고려한다.

 

클래스 다이어그램을 작성할 땐 UML Class Diagram Explained with Examples 글을 C++스타일로 변형해 작성한다.

화살표의 방향이나 모양 접근성과 같은 기본 규칙들은 매번 동일해야 하며,

팀 내에서 약속된 규칙으로 유지되는 것이 중요하다.

UML 어디까지 기술해야 하는가

개발자인 나는 UML을 주로 팀원과의 소통 도구로 사용한다.

UML을 보는 사람은 각자의 배경지식과 목적이 다르고, 개발자인지 클라이언트인지도 다르다.

이점을 고려해 하나의 큰 다이어그램보다는 목적이 분명한 작은 다이어그램 여러 개를 선호한다.

 

UML(Unified Modeling Language) 역시 하나의 언어이기 때문에,

대화에서 불필요한 말이 오히려 방해가 되듯

연관성이 없거나 생략 가능한 요소는 과감히 제거한다.

 

필요하다면 그림이나 간단한 주석을 추가하는 편이 의사소통에는 훨씬 효과적이다.

그림/주석 을 추가한 Class Diagram

UML 언제 작성하는가

사실 나는 다음과 같은 이유로 UML작성을 좋아하는 편은 아니다.

• UML에 투자하는 시간이 아깝다 → 네이밍, 예외 상황 등을 고민하다 보면 UML도 계속 수정된다
• 처음부터 모든 상황을 고려한 UML은 사실상 불가능하다
• 시간이 지나면 코드와 UML 사이에 이격이 발생한다

그럼에도 내가 UML을 작성하는 시점은 "개발을 들어가기 전", "남이 작성한 코드를 분석할 때" 두 경우이다.

1. 개발을 들어가기 전

구현해야 할 기능을 빨간 박스로 하나씩 추가하며 설계를 시작한다.

클래스를 나누거나 합치며 구조를 다듬고, 역할과 구조에 맞는 좋은 이름을 고민한다.

구현단계에 들어가면, 구현이 끝난 기능은 검은색으로 변경해 가며 진행 상황을 시각적으로 관리한다.

 

색으로 진행도를 표현한 Class Diagram

2. 남이 작성한 코드를 분석할 때

이 경우 가장 중요한 점은 과감히 생략하는 것이다.

코드에는 있지만 불필요한 내용을 UML에서 제외한다.

• 현재 이해에 필요 없는 변수나 함수
• 당연히 따라오는 구현 디테일
• 목적에 연관성 없는 기능 또는 클래스

불필요한 요소를 제거하면 핵심 구조에만 집중할 수 있고, 다이어그램의 목적도 훨씬 뚜렷해진다.

통신기능 Class Diagram

다이어그램의 목적이 분명해지면

이를 바탕으로 아키텍처를 요약하거나 계층 구조로 정리하기 쉬워지고, 코드의 전체 흐름 파악에 도움을 준다.

계층도로 요약한 그림

마무리

내가 생각하는 UML은 전달력, 목적성에 중점을 둔다.

읽는 사람을 고려해 필요한 만큼 그리는 것,

그것이 내가 UML 사용하는 방식이다.

 

부족한 점도 많고 미숙한 생각일 수 있지만,

UML 작성이 필요한 누군가에게 조금이나마 도움이 되었으면 좋겠다.

이전 글에서 아키텍처 글을 작성하며 UML에 대해서도 한 번 정리해 보고 싶다는 생각이 들었다.
이렇게 개념을 정리하는 시간이
프로그래머로서 시야를 넓히는 데 확실히 도움이 된다고 느낀다.

다음 글에서는
이전 회사에서 Git을 사용하다가,
이직 후 SVN을 사용하며 느낀
VCS(Version Control System)에 대한 생각을 정리해 보려 한다.

 

Windows·Linux에서 시스템 권한을 다루는 올바른 아키텍처 설계