Go 개발자가 UML을 사용한 이유
연휴[1]를 마치고 출근해서 처음으로 머리써서 처리한 일은 동료 개발자가 두레이에 남겨 놓고 간 작업입니다. 필자가 먼저 서울에 갔을 때 북경에 남아 있던[2] 그가 갱신한 작업 내용을 보고, 필자가 '무얼 더 개선할 수 있을까?' 생각하는 일입니다. 그가 나에게 작업을 요청한 것이 아니라 우리가 서로 나눴던 의견을 상기하고, 그의 개선에 대해 살펴보는 일인 터라 매우 느슨한 협업이라 할 수 있습니다.
그는 왜 UML 그림을 그렸는가?
지난 번에 둘이 만나 나눈 이야기부터 떠올려봅니다. 매일 일상이 Go로 프로그램을 짜는 그가 굳이 UML 도해를 그려 두레이에 공유했습니다. 필자가 Go 개발자가 아닌 탓도 있겠지만, 그가 UML로 표현하는 목적을 친절하게 써두었습니다.
UML로 표현하는 목적 Product Availability 코드가 점점 복잡해 지고 있다. UML로 표현이 안되면 코드 복잡도가 일정 수준 이상을 넘어선 것이라고 보자! 쓰임새가 복잡할수록 엔티티를 단순하게 유지하자. 코드가 길어지더라도 엔티티를 단순하게 유지하자.
효과적인 전략으로 보입니다. 코드로 구현한 내용을 잠시 멈춰서 개념을 그려보고 복잡도를 진단해보자는 식이네요. 코드 복잡도가 일정 수준 이상을 넘어서면 무엇을 할 수 있을까요? 그와 함께 협업하고 있으니 그가 일하는 맥락을 잘 알고 있긴 하지만, 필자가 주관적으로 추정해보면 두 가지가 떠오릅니다.
- 덩어리 즉, 모듈(마이크로 서비스)이나 Bounded Context를 나누기
- 개념을 명확하게 다시 정의하고 뒤따르는 리팩토링 수행하기
클래스도의 용도
아래는 동료가 최초에 그린 UML 클래스도를 필자와 함께 소통하며 수정한 내용입니다. 둘이 만났을 때에는 주로 제가 질문을 하는 식으로 소통을 시작합니다. 당시는 즉흥적으로 했던 질문이지만, 돌아보면 만든 이에게 왜 그러한 이름으로 했는지와 책임을 정확한 대상에게 할당했는지가 질문의 기준이라 할 수 있습니다.
주요 엔티티를 표현한 클래스도
결과를 다시 살펴보니 이러한 검토회에서 필자의 관심 중에 눈에 띄는 부분은 아래와 같습니다.
- 모호한 단어를 작성자가 딱 의도한 '그것'을 지칭하는 말로 바꾸려고 노력한다.
- 개발자와 필자 양쪽 모두가 편안하게[3] 받아들이는지 관찰한다.
논의한 이후 보름 정도가 지나서 다시 그려진 그림을 보니 느낌이 새롭네요. 다시 한번 돌아볼 기회일 수도 있다는 생각이 듭니다.
소수만 그리는 상태도
대략 10여년 전에는 UML을 사용하는 사람이 많았지만, 비교적 소수만 상태도를 그려 사용했습니다. 뜻밖에 동료가 상태도를 그려왔습니다. 몇 가지 오류가 있었지만, 제가 할 수 있는 일이 생겨서 좋은 일이었죠. 그리고, 이제는 수정한 상태도를 볼 수 있고, 아마도 상태도 수정과 더불어 그가 작성한 분기문에 있을 법한 오류 가능성도 줄지 않았을까 기대해 봅니다.
동료가 작성한 상태도
우리 개발 상황을 구체적으로 설명해야만 공감할 수 있는 로직 설명은 생략합니다. 여기서는 '어떤 경우 상태도가 유용할까?' 하는 점을 글로 공유하려 합니다. 그는 왜 표기법도 익숙치 않은 생소한 상태도를 그리려고 했을까요? 그가 부가 설명으로 두레이에 기록한 특이사항 3가지 항목에서 힌트를 찾을 수 있습니다.
- 지불 후 SaleOrderFinished 상태에 머물러 있음
- StockDistributed 상태인데 배송은 시작하지 못함
- 환불시 Product Availability는 어떻게 동작해야 하나?
까다로운 비즈니스 로직을 명확하게 표현할 도구로 선택했다는 추측을 할 수 있습니다. 또한, 두레이 댓글에 다른 동료의 글이 올라와 있는데 직접 관련이 있는 주문 모듈 개발자의 글입니다. 다른 모듈 혹은 객체와 상호 연관이 있을 때 정합성을 유지하기 위해 상태도를 그리는 일은 매우 유익합니다. 필자의 경우도 직접 개발하던 시절 두 번 정도 상태도를 그려 구현에 사용한 일이 있는데 아래 경우였습니다.
- 원자력 발전소 제어기 시뮬레이터 설계/구현
- 회계 결산 제어기 설계/구현
Go 개발자가 UML을 사용한 이유
이쯤에서 다시 제목으로 돌아가 보겠습니다. 동료의 말을 간단하게 요약해서 써보겠습니다.
쓰임새가 늘어나도 코드를 단순하게 유지하기 위해, 코드가 적정선 이상으로 복잡해졌는지 확인하는 방법으로 UML을 그려 본다.
보편적으로 말하자면 프로그램이 많이 쓰이고, 다양한 경우를 포용할수록 그 프로그램은 점차 유용해진다고 할 수 있습니다. 하지만, 동시에 코드가 늘어나고 디렉토리가 복잡해지는 일은 사실은 바람직하다고 할 수 있습니다. 그만큼 수정이 까다로워지기 때문입니다. 그래서, 당연한 말이지만 제때에 방책을 만들어둬야 합니다. 필자가 소개한 동료 방법은 UML을 이용해서 복잡도를 측정하고 코드를 개선하는 식입니다. 그 과정에서 필자와 검토회를 하고, 필자의 질문에 답하며 스스로 개선하는 행위는 소프트웨어 공학에서 말하는 응집성(cohesion)을 놓이기 위한 활동의 전형으로 보였습니다. 여기서 키는 물론 UML이 아닙니다.
그게 무엇이든 실천을 하기 위해서는 도구가 필요하고, 상황에 맞는 도구를 찾을 줄 알아야 합니다. 또한, 내 손에 안성맞춤으로 만드는 시간 혹은 훈련이 필요합니다. Go 프로그램 서적 저자기도 한 필자의 동료는 이렇게 말했습니다.
Go는 비즈니스 로직이 눈에 띄게 하는 데에는 정말 유용하지 않습니다. 그래서, (복잡한 로직에 대해서는) UML로 그려 봐야 하겠다고 생각했습니다.
정말 멋진 말입니다.
상태도에 대한 필자의 생각
앞서 필자는 경력에서 딱 두 번만 상태도를 의미있게 사용했다고 했습니다. 두 번 모두 서로 다른 절차를 가진 덩어리를 다루는 일이었습니다. 원자력 발전소 제어기의 경우 '종이 절차서'라는 것을 대체하기 위해 시도였는데, 안전을 위해서 엄청나게 많은 다수의 책으로 만들어진 절차서가 상호 참조하는 일이 해야 할 일을 배경이었습니다. 회계 결산 제어기도 마찬가지죠. 결산이란 행위가 일 결산 혹은 일 마감과 월 단위 결산 행위의 연속으로 이뤄집니다. 그리고, 해마다 공시를 위해 연 단위 결산을 합니다. 마감 과정에서 오류가 발생하면 취소를 해야 하는데 연쇄적으로 영향을 미치죠. 이런 경우 복잡한 경우의 수를 따지는 일에 실수가 발생할 가능성이 아주 큽니다. 이런 일들은 필자 말고도 많은 사람들이 비슷한 시스템 개발에 참여하고 있을텐데, 왜 우리나라에서 상태도는 소수만 사용하는 도구일까요?
답을 알 수는 없지만, 관련 있는 몇 가지 현상이 있기는 합니다. 담론으로 다뤄지는 표현을 빌리면 원천 기술 개발보다는 당장 이익을 내는 일에 집중하는 우리나라 소프트웨어 환경이 영향을 미쳤다고 봅니다. 그렇다 보니 DB가 제공하는 트랜젝션 관리 기능은 절대적인 요소처럼 받아들여져 과도하게 쓰이는 현상을 쉽게 관찰할 수 있습니다. 다른 영역이지만 멀티 쓰레드 프로그래밍은 극소수가 할 수 있는 일처럼 치부되는 현상도 외산 기술 의존이 과해지고 우리나라 개발자의 응용 기술이 약해지는데 한 몫을 한 부분도 있지 않을까 싶습니다.
지금까지 그래왔다고 하더라도 앞으로는 개선이 필요하다 생각하는 부분이 있습니다. 바로 내가 담당하는 모듈 혹은 마이크로 서비스가 담당하는 주요 이벤트의 처리 상태나 엔티티의 상태의 일관성을 보장할 수 있도록 사고를 키워야 한다는 점입니다. 우리나라에 마이크로 서비스 아키텍처가 유행처럼 번지고 있는데, 그러한 사고력이 뒷받침하지 않는 기술 채용은 모래성을 쌓는 일이 될 수 있기 때문입니다. 사고력을 키우는데 있어서 자기 업무에 관련한 상태도를 그리는 일이 알고리즘 문제 풀이보다 일상에서 유용하게 쓸 수 있는 훈련법일 수 있습니다.
커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글)
4편. 상품 정보 다룰 때 BoundedContext 와 엔터티
6편. DDD의 BoundedContext가 우리의 이야기와 밀접해지다
주석
[1] 우리나라의 설날과 같은 날을 기준으로 하지만, 중국은 이동거리가 긴 탓인지 회사마다 다르지만 열흘에서 2주 정도의 춘절(春节) 연휴가 있습니다.
[2] 작업을 하는 현재 시점에서 필자의 위치는 북경인데, 동료는 인도네시아 아니면 한국에 있을 듯 합니다. 서로 위치를 바꿔가며 협업하는 모습이 느슨함을 대변하는 듯해서 흥미롭네요.
[3] '편안하게'라는 부분은 해당 개념 정의에 대한 구현과 지속성을 보장하는 주관적인 지표로 사용합니다.