0. 읽기 전에
- 본 글에 소개된 ‘도메인 주도 설계’라는 책의 내용이 궁금하신 분들에게는 적합하지 않을 수 있습니다.
- 이전 글 참고(클릭)
1. 우리는 같은 언어를 사용중인가?
2장에서도 이전 장에서 강조되었던 ‘모델’의 개념이 계속 등장합니다.
모델이란?
- 도메인에 대한 통찰력/개념을 반영한 것
- 개발자가 도메인을 익히는 것에 압도되는 부담을 해소해주기위한 도구
- 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
저의 경우 새로운 프로젝트를 진행하며, 모델을 정의하고 구체적인 비즈니스 로직까지 재정비하는 리팩토링을 진행중입니다. 이 과정에서의 팀원 또는 이해 당사자간의 소통은 필수인데요, 다음의 구절이 와닿았습니다.
(생략)… 마찬가지로 도메인 전문가도 개발자 간의, 그리고 다른 도메인 전문가 간의 언어를 번역해줘야 한다. 심지어 개발자 사이에서도 서로 번역해줘야할 때도 있다. 모델의 개념을 혼란스럽게 만드는 번역은 해로운 코드 리팩터링으로 이어진다…(생략)
의사소통이 직접적으로 일어나지 않아 개념이 분열돼도 이 같은 상태가 겉으로 드러나지 않는다. 즉, 팀원들이 용어를 다르게 써도 그것을 알아차리지 못한다. 결과적으로 조화가 깨진, 신뢰할 수 없는 소프트웨어가 만들어진다.
이 구절을 읽고 저희 조직이 과거에 경험했던 사례가 떠올랐습니다.
📌 서비스 홍보 타임
혹시… 귀여운 반려동물과 삶을 함께하고 계신 보호자님이신가요? 그러시다면 분명 우리 아이를 집에 두고 나오기 불안하기도 하고, 걱정도 되신 적이 분명 있으실 텐데요, 저희 ‘도기보기’는 이러한 보호자님의 마음을 조금이라도 위로해드리고자 개발된 반려동물 CCTV 어플리케이션입니다.
스마트폰 공기계에 저희 앱을 설치하시고, 평상시 사용하시는 폰과 연동한 뒤 아이가 잘 보이는 곳에 배치만 하면 끝! 집에 홀로 남겨진 우리 아이를 실시간으로 보실 수 있고, 우리 아이만 나온 녹화 영상과 함께 AI로 분석된 하울링/짖음, 활동량 리포트를 받아보실 수도 있습니다!
📌 평화롭던 어느 날…
하루는 한 사용자께서 고객센터로 기능 추가 건의를 해주셨습니다.
스마트폰 공기계의 자원(카메라, 라이트, 조도 센서 등)을 활용할 수 있기 때문에 저희 또한 내부적으로 고려하고있던 기능이었는데요, 감사하게도 해당 사용자 뿐만아니라 여러 사용자분들께서 건의를 해주셔서 구현의 우선순위를 높이게 되었습니다.
📌 기능을 구현해봅시다
우선 사용자 문의 관련 담당자님은 업무 관련 칸반보드에 업무 카드를 생성합니다.
그리고 주간 회의를 통해 해당 업무를 이번 주부터 진행하기로 급하게 결정하고, 관련한 시안을 디자이너님에게 요청합니다.
이제 시안과 기획이 완료되었습니다. 이제는 구현을 시작해야겠죠?
해당 기능은 다음과 같은 개발자들의 협업이 필요합니다.
(1) 백엔드 개발자(뷰어 앱의 요청을 처리하여 공기계 앱에 요청 전송)
(2) 뷰어 앱 개발자(라이트를 켜고 끄는 요청을 구현)
(3) 공기계 앱 개발자(라이트를 실제로 켜고 끄는 로직 구현)
이처럼 여러 개발자가 각자 구현을 시작하는데, 다음과 같은 PR 내용과 문서가 생성되었습니다(예시).
(1) 백엔드 개발자
(2) 공기계 앱 개발자
(3) 뷰어 앱 개발자
음… 뭔가 찝찝한 느낌이 드시진 않았나요? 분명 같은 기능을 구현하는데, 개발자마다 사용하는 언어가 달랐습니다.
여기까지만 보면 저희 회사를 디스(?)하는 느낌이 들기 시작합니다만, 회사 내에서 이러한 상황이 발생하지 않도록 경각심을 가지자는 차원에서 공개적으로 기록을 해봅니다ㅎㅎ 이 글을 작성하는 시점에는 이와 같은 상황이 발생하지 않도록 주의하고있습니다.
📌 같은 공간에서 다른 언어를 사용하는 우리
- 사용자 : “LED 켤 수 있게 해주세요”
- 사용자 문의 담당자 : 공기계앱 라이트 켜기/끄기
- 디자이너 : 야간 조명 라이트(on/off) 기능
- 백엔드 개발자 : 라이트 on/off
- 공기계 앱 개발자 : 플래시 기능
- 뷰어 앱 개발자 : 라이트 켜기/끄기
이런 상황 속에서, 다음과 같은 상황이 발생하였습니다.
- 묘한 커뮤니케이션의 어려움
(공기계 앱 개발자) : “백엔드 개발자님, 혹시 라이트 on/off 로직 백엔드 쪽이랑 같이 테스트 해볼 수 있을까요?
(백엔드 개발자) : 네…??? (약간의 적막 후) 아, 플래시 기능이요? 네네 가능하죠~ - 개발된 코드에서의 변수명이 묘하게 다름
(뷰어앱 개발자) : lightOn
(백엔드 개발자) : flashOn - 클라이언트에서 코드가 혼란스러워짐
- API 관련 응답 데이터의 필드명과 코드에서 사용되는 변수명이 다르기 때문에, 클라이언트 앱의 코드의 경우 하나의 파일에 flash와 light라는 변수명이 공존함.
때로는 여러 언어가 필요할 때도 있지만 도메인 전문가와 개발자 사이에 언어적 분열이 일어나서는 안된다.
모델을 언어의 근간으로 사용하라. 팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용하는 데 전념하라. 다이어그램과 문서에서, 그리고 특히 말할 때 동일한 언어를 사용하라.
물론 이 책에서는 도메인 전문가와 개발자 사이의 소통에 대해서 주로 다루고있지만, 최근의 서버 리팩토링 프로젝트 뿐만 아니라 평상시 서비스 개발에 있어 저희 팀 내부의 소통에 빗대어 생각해보게 되었습니다.
📌 프로세스를 개선합시다
결국은 뒤늦게 상황을 인지하였고, 개발 관련된 용어를 모든 파트에 걸쳐 통일하였습니다.
이전보다 한결 코드 리뷰도 쉬워지고, 이해하기 쉬운 코드가 되었습니다. 추가적으로는 단순히 개발에 사용되는 변수명 뿐만 아니라, 팀원들끼리 구두 또는 문서에서 사용하는 언어를 통일하고 구현을 시작하게 되었습니다.
2. 마치며
긴 시간은 아니지만 개발 업무를 하는 조직을 매니징하면서 ‘소통’에 대해 생각해볼 일이 많았는데요, 이번 2장을 읽으며 우리는 회의를 하거나 업무 중에 구두로 나누는 대화에서 그치는 것이 아니라, 우리가 언어를 사용하는 모든 영역(문서, 회의, 코드 등)에 있어 동일한 언어를 사용하는 것이 중요하다고 다시 한 번 생각할 수 있었습니다.
(추가) 다른 기업이나 조직에서는 이를 위해 어떻게 노력하고있는지 궁금해지기도 했고, 좋은 방식이 있다면 도입해보고 싶네요ㅎㅎ
