0. 읽기 전에
- 본 글은 글쓴이가 회사 내에서 서비스 리팩토링 프로젝트를 진행하던 도중, ‘도메인 주도 설계’라는 책을 접하며 느낀 점과 생각들을 함께 정리한 글입니다.
- 본 글에 소개된 ‘도메인 주도 설계’라는 책의 내용이 궁금하신 분들에게는 적합하지 않을 수 있습니다.
1. 들어가며
📌 서비스 홍보 타임
혹시… 귀여운 반려동물과 삶을 함께하고 계신 보호자님이신가요? 그러시다면 분명 우리 아이를 집에 두고 나오기 불안하기도 하고, 걱정도 되신 적이 분명 있으실 텐데요, 저희 ‘도기보기’는 이러한 보호자님의 마음을 조금이라도 위로해드리고자 개발된 반려동물 CCTV 어플리케이션입니다.
스마트폰 공기계에 저희 앱을 설치하시고, 평상시 사용하시는 폰과 연동한 뒤 아이가 잘 보이는 곳에 배치만 하면 끝! 집에 홀로 남겨진 우리 아이를 실시간으로 보실 수 있고, 우리 아이만 나온 녹화 영상과 함께 AI로 분석된 하울링/짖음, 활동량 리포트를 받아보실 수도 있습니다!
📌 진짜로 들어가며…
현재 저희 회사 내에서는 서비스 리팩토링을 준비하고있습니다. ‘서비스’ 리팩토링이라… 좀 더 설명이 필요할 것 같습니다. 여기서 말하는 리팩토링이라 함은, 다음과 같은 것들을 목표로 하고있습니다.
- 서비스 개선
- 신기능 출시가 용이한 구조
- 레거시 청산
(1) 서비스 개선
서비스를 운영하며 제일 문의도 많고 아쉬웠던 점은, 공기계 한 대에 대해서만 연동이 가능하다는 점이었습니다. 보통은 아이(반려견)가 집에 홀로 남겨진 경우에는 활동량이 많지 않기 때문에, 아이가 주로 시간을 보내는 하나의 장소가 보이도록 설치하는 것으로도 충분하다고 생각할 수 있습니다. 하지만 여러 장소에 여러개의 카메라를 설치할 수 있다면 사각지대 없이 아이를 관찰할 수 있을 것입니다. 아쉽게도 서비스를 출시하던 당시에 설계한 구조에 의하면 여러 대의 공기계를 연동하기에 적합하지 않았고, 사용자들의 문의를 받기 시작할 시점에는 이미 비즈니스 로직도 걷잡을 수 없을 정도로 복잡해진 뒤였습니다. 따라서 공기계 여러 대를 연동할 수 있는 구조로 변경이 필요한 상황이었습니다.
또다른 아쉬운 점은 공기계 연동 과정이 복잡하다는 점이었습니다. 서비스를 이용하기 위해서는 스마트폰 공기계에 ‘CCTV 앱’을 설치해야하고, 이러한 영상을 보기위한 ‘뷰어 앱’을 각각 설치해야 합니다. 또한 뷰어 앱과 CCTV 앱을 연동하기 위해서는 QR코드 스캔 과정이 필요한데요. 이러한 과정의 앞뒤에 회원가입이라던지, 반려동물 정보 입력과 같은 UX가 포함되어있어 사용성을 헤치고 있다고 판단하였습니다. 최대한 빠르게 설치/연동 후 우리 아이를 보고싶은 보호자분들의 마음을 너무나도 잘 알기에, 이 과정을 최대한 간소화할 필요가 있었습니다.
(2) 신기능 출시가 용이한 구조
CCTV 기능을 중심으로, 서비스를 통해 제공할 수 있는 가치를 더하기 위해 새로운 기능들을 실험하고 있습니다. 이 과정에서 어엿히 자리잡은 기능들이 많이 생겼는데요, 그 외로 예를들면 분리불안을 겪고있는 반려견과 보호자를 위한 기능들 처럼 새로운 기능을 앞으로도 추가할 계획입니다. 이러한 계획에 있어, 현재의 구조보다는 새롭게 정돈된 아키텍처가 있다면 신기능 출시가 용이할 것이라고 판단하였습니다.
(3) 레거시 청산
클라이언트(뷰어 앱 등)의 경우에는 비교적 최근에 개발되어 괜찮지만, 이를 뒷받침해주는 백엔드 서버나 데이터베이스의 경우 서비스가 첫 출시된 이후 별도의 리팩토링을 하지 않았습니다. 다양한 개발자분들께서 거쳐간 영광의 흔적들(?)을 정리하고 정해진 룰에 따른 코드 작성과 DB 구조가 필요했습니다.
📌 리팩토링 초반의 애로사항
위에서 나열한 목표들을 해결하겠다는 굳은 의지를 가지고 진행한 리팩토링의 초반은 쉽지 않았습니다. 회의는 또다른 회의를 낳고, 코드 한 줄은 커녕 변수 하나도 선언하지 못할 정도로 의사결정하는 것이 어려웠습니다.
이러한 어려움의 원인들은 다음과 같았습니다(구체적인 예시로 묘사되지 않아 리팩토링시의 애로사항이 잘 전달될지 모르겠습니다).
(1) 리팩토링해야할 서비스의 범위가 넓다보니 논의해야할 내용이 많고 복잡함. 아무리 작은 단위로 쪼개고 하나씩 해결한다해도 회의 진행이 쉽지 않았음. 예를들어 전 날에 회의에서 이야기한 내용을 다음날 다시 리마인드해야하는데, 회의록을 보고 이것들을 다시 떠올린 후 논의해야하는 시간이 비효율적이라고 생각하였음.
(예) “어제는 사용자의 A 시나리오를 위한 DB 구조 설계에 대해서 논의했는데요, a라는 콜렉션 b라는 콜렉션의 관계에 대해서 이야기했습니다. (중간 생략) … 근데 왜 두개의 콜렉션으로 정했었죠?”
“…”
(2) 운영 중인 큼직한 서비스의 종류가 한 개가 아니다보니 해당 서비스에 대한 구조 관련 논의를 가지쳐가면서 깊이 설계할 수록 점점 윗단계의 논의로 못올라올 정도로 머리가 복잡해짐.
(예) “A 상황에서는 B해야되니까 C 방식으로 설계 하실까요? C는 D가 필요하니까 더 논의해야할 것 같고… (중략) 근데 A 상황이랑 동시에 논의해야하는 A` 상황은 어떡하죠?”
“…”
(3) 서비스 개선에 있어 우리가 의사결정해야할 것들이 있다보니 이것들을 결정하면서 설계하는데에 시간이 소요됨. 팀 내부적으로 이러한 상황에서는 서비스의 기획과 개발이 구분되어있지 않다보니, 개발 관련 설계도 어려운데 서비스에 대한 기획도 동시에 해야했음.
(예) “A 상황에서는 사용자가 몇 명까지 연동 가능해야할까요? 이후에 유료 플랜 출시할 경우를 대비해서 3명까지로 제한할까요?”
“…”
회의를 진행하는 도중, 그리고 회의를 마무리하며 자리로 돌아올 때마다 이러한 과정들의 개선의 필요성을 느꼈습니다. 분명 전세계의 수많은 기업과 단체에서 소프트웨어를 새로 설계하거나 리팩토링을 진행하였을텐데, 분명 관련된 많이 사용되는 방법론이 있을 것이라고 생각했습니다. 그날 저녁 퇴근하며 무작정 서점으로 달려갔고, 여러 책들 중에서 에릭 에반스의 ‘도메인 주도 설계(소프트웨어의 복잡성을 다루는 지혜)’라는 제목에 꽂혀 바로 해당 책을 구매하였습니다.
아직은 책의 초반 부분이지만, 현재 저희가 겪고있는 상황들을 대입하여 읽어보았습니다.
2. (1장) 지식 탐구
모델
이 책의 1장에서는 도메인, 모델이라는 단어를 작가의 실제 경험을 예시로 설명하고, 이것들에 대해 이야기합니다.
두 단어 모두 개발 업무를 하다보면 자주 접하는 단어이기 때문에, 낯선 단어는 아니죠?
‘철수님 회사는 도메인이 뭐에요?’ ‘아, 저희는 자산 관리 관련 핀테크입니다ㅎㅎ’
작가는 PCB(인쇄 회로 기판) 설계 소프트웨어 툴을 설계하였던 일화를 소개합니다. PCB 설계자와 작가는 서로의 분야에 대한 질문과 설명을 주고받으며, 개발하고자하는 툴에 대한 브레인스토밍과 정제의 과정을 통해 모델에 대해 알아가죠. 여기서 제가 이해한 모델의 개념은 다음과 같습니다.
- 도메인에 대한 통찰력/개념을 반영한 것
- 개발자가 도메인을 익히는 것에 압도되는 부담을 해소해주기위한 도구
- 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
저희 서비스에 대입해서 생각해보면, 리팩토링을 위한 회의를 하며 자주 언급된 단어와 개념을 떠올려보니 집에 설치하는 ‘CCTV용 공기계’와 ‘영상을 보는 사용자’를 생각해볼 수 있을 것 같습니다(예. ‘사용자는 CCTV 앱을 언제 설치할까?’, ‘사용자는 CCTV 영상을 주로 언제 확인할까?’).
지식탐구
책을 읽으며 저희의 리팩토링 관련한 논의와 소통의 시간들이 주마등처럼 흘러가기도 했습니다.
효과적으로 도메인 모델링을 수행하는 사람들도 지식을 면밀히 탐구한다. 그들은 엄청난 양의 정보 속에서 아주 미미한 관련성을 찾아낸다. 그들은 전체를 이해할 수 있는 간결한 관점을 찾아 체계적인 아이디어들을 차례로 시도해본다. 그 과정에서 수많은 모델이 시도, 거부, 변형된다. 모든 세부사항에 들어 맞는 일련의 추상적 개념이 나타나면 비로소 성공에 이른다. 이렇게 해서 뽑아낸 정수는 가장 적절한 것으로 밝혀진 특정 지식을 엄밀하게 표현한 것이다.
이처럼 팀이 합심해서 모델간의 관련성을 찾아내고, 여러 아이디어들에 대해 사용 시나리오를 그려가며 로직이 성립되는지 실험하는 과정들은 어쩌면 잘못된 것은 아니었다는 위로도 받았습니다.
한편으로는 뜨끔한 대목도 있었습니다.
훌륭한 프로그래머라면 애초부터 추상화를 시작해서 더욱 많은 일을 해낼 수 있는 모델로 발전시킬 것이다. 하지만 이 같은 과정이 도메인 전문가와 협업없이 기술적인 측면에서만 일어난다면 개념은 초보적인 수준에 머무를 것이다. 이러한 피상적인 지식은 기초적인 역할만 수행하는 소프트웨어를 만들어낼 뿐 도메인 전문가의 사고방식과 긴밀하게 연결되지는 않는다. 모든 구성원이 함께 모델을 면밀히 만들어 나가면 팀 구성원 간의 상호작용은 그 양상을 달리한다. 도메인 모델의 지속적인 정제를 토대로 개발자는 기능만을 기계적으로 만드는 데 머무르지 않고 자신이 보조하고 있는 업무의 중요 원칙들을 배운다.
각자의 아이디어와 의견을 주고받다보면, 개발이 어려워서, 나중에 관리하기 어렵다는 이유로 보수적이었던 순간들도 많았습니다. 누구의 말도 틀리지 않았지만 여러 의견들 중 하나만을 선택을 해야만하는 순간들도 있었고, 이러한 ‘지속적인 정제’의 과정이 개인에게 스트레스가 되기도 했습니다. 하지만 이 책에서처럼 모든 구성원이 서로 소통하면서 도메인 모델을 지속적으로 정해나간다면, 팀원들 모두가 본인의 업무에 대한 중요 원칙들을 배울 수 있을 것이며 결국에는 구현에 있어서도 명료해질 수 있다는 믿음을 가지게 되었습니다.
3. 다음 편에서는…
본 글을 작성하는 과정에서 현재 저희의 프로젝트 진행 상황을 돌아보고, 그동안의 소통(대화, 문서 등) 방식들도 다시 한 번 생각해볼 수 있었습니다. 여전히 모델을 설계하는 것은 쉽지 않지만, 우연히 이 책을 만난 것도 운명(?)이라고 생각하고 저희의 상황에 맞게 프로젝트 관련 소통을 효율적으로 하는 것에 집중하고자 합니다.
이후에는 ‘의사소통과 언어 사용’, ‘모델과 구현의 연계’ 등이 있는데, 실제로 리팩토링을 진행하며 이를 적용한 경험을 다음 글에서 공유하고자 합니다.
