주니어 PM의 도메인 주도 설계 관점에서 생각해보기
[개발자처럼 생각하기] 0.5 걸음 정도 잘 내딛었습니다
01. DDD..?
근 몇 개월 간은 저 개인에게도, 팀에게도 도전적인 프로젝트를 하고 있습니다. (자세한 내용은 프로젝트가 완료된 후 팀 블로그 등을 통해서 정리해보면 좋을 것 같네요.) 프로젝트의 중요한 목표 중 하나가 서비스 확장성 높이기 입니다. 그래서 데이터 구조 개편부터, 백오피스가 실무 프로세스를 닮도록 리뉴얼하기 까지. 평소와 달리 백엔드 엔지니어 분들과 밀접하게 일할 수 있는 기회가 늘었습니다.
눈에 보이지 않는, 실체가 없는 무언가를 어떻게든 구체화해서 협업할 수 있도록 함께 일하는 백엔드 엔지니어 분들을 자주 찾아뵈었습니다. 하위 기획까지 완전히 다 끝난 다음에 개발에 들어가는 것이 아니라 기획/개발이 중첩된 일정이 있다는 점이 우려되었는데, 조언을 주신 덕분에 [변하지 않을 전제와 가변성이 있는 영역을 정의]하면서 더 미루지 않고 프로젝트를 킥오프하는 데에 큰 도움을 받기도 했습니다.
전제 설명을 위한 미팅 때 인쇄해서 나눠드린 자료 일부. 제작하면서 내 머릿 속 구체화에도 큰 도움이 되었다"어려운 일이지만, 이번 프로젝트에서는 PM 분들이 [개발자처럼 생각]해주시면 정말 큰 도움이 될 것 같아요"라는 조언도 해주셨는데요. 그래서 자리도 개발자와 가까운 자리로 바꾸고, 잡담과 미팅 등을 통해 귀동냥을 열심히 해보니 DDD 라는 이야기가 자주 들렸습니다. 도메인 주도 설계 라는 사전적 정의는 몇 번 들어본 적이 있지만 여전히 낯선 이야기였는데요. 그간 우리가 실무에서 함께 고민했던 것들의 예를 들어 생각해보니- 제가 PM으로서 갖고 있는 지식 (기획서, 비즈니스 도메인 개념 etc)을 구현에 필요한 요소 (DB, 백오피스 로직 etc)로 치환해 설명하려고 할 때 난감했던 대부분의 것들이 설명되고 있는 방법론이라는 점을 알게 되었습니다.
제가 직접 소프트웨어를 설계하거나 개발하고 있지는 않기 때문에 DDD를 개발 설계 방법론보다는 기획의 가시화 관점에서 공부하고 활용하면 유용하겠다는 생각이 들었습니다. DDD 자체가 비즈니스의 현실 로직을 닮은 소프트웨어를 만듦으로써 도메인 전문가 (기획자) 와 개발자 모두가 공통의 언어로 소통하는 데에 도움을 주는 방법론인 만큼, [개발자처럼 생각하기]를 익히기에도 유용한 접근방식이 될 수 있을 것 같고요.
하여 오늘은 약 한 달간 프로젝트를 진행하면서 배우게 된 'DDD에서 파생된, 제게 유용했던 기획 방식'을 기록해보려고 합니다.
02. 유비쿼터스 언어 사용하기
개발 실무를 시작하기 직전에 개발자 분들께서 PM까지 포함해 주요 개념의 유비쿼터스 용어를 지정하는 미팅을 주최해주셨습니다. '같은 용어 사용하는 거 중요하지 그렇지 그렇지..' 정도로만 생각하고 참여했는데, 후에 DDD 관점에서는 이것이 정말 핵심적인 절차라는 것을 알게 되었습니다.
비즈니스를 하는 사람과 소프트웨어를 제작하는 사람이 서로 어떤 이야기를 하는지 이해를 못 하면 서로의 본진 (비즈니스와 소프트웨어)을 닮게 만드는 것 자체가 어렵기 때문입니다. 더불어 용어를 고민하는 과정에서 그 용어를 어떻게 설명할 것인지도 생각하게 되는데요. 이 과정에서 '어 같은 개념인 줄 알았는데 사실은 구분이 되는 개념이네? 분리해야겠다'와 같이, 아래에서 다룰 '관심사 분리하기'에 용이한 의사결정을 할 수도 있었습니다.
지금 저희 팀은 기획서 내 주요 용어 목록을 뽑고 > 기획자가 한글 설명과 한글 용어를 붙이면 > 개발자가 영어 용어를 붙여서 차근차근 채워나가고 있습니다. 유비쿼터스 언어의 필요성은 개발자 분들께서 먼저 제시해주셨지만 앞으로 채워나가는 과정은 PM들이 더 주도적으로 해보면 좋을 것 같다는 생각을 안고 다음 주 주요 to-do에 [유비쿼터스 용어사전 채우기]를 슬그머니 작성해봅니다.
03. 각 요소가 자기 자신만으로도 온전할 수 있게 하기
제가 백엔드 개발요청문서를 제작할 때 염두에 두었던 것은 '비슷한 것은 2개 이상 만들지 않는다'였습니다. 그게 효율적일 것이라고 생각했기 때문입니다. 그래서 서로 참조가 가능하면 가급적 동일한 속성을 가지지 않도록 설계 요청 문서를 작성했습니다. 기획서 피드백을 받으며 이 전제에만 매몰되었을 때의 문제를 알게 되었습니다. 요소 간 상호 참조 관계가 너무 복잡하게 연결되어 있어 탐색 비용이 더 커져 오히려 더 비효율적일 수 있고, 각 요소가 자신의 온전한 존재를 설명하기 위한 충분한 정보를 담고 있지 않아 요소들을 이해하기 위한 복잡도 역시 높아질 수 있다는 점이었습니다. 실제로 개발자 피드백을 받고 수정한 기획 사항 중 하나는 아래와 같습니다.
전제
(1) 트리거 [가] 발생시 A의 판매 가능 상태를 조회해서 O인 경우에만 검증 조건 통과시킨다
(2) A는 하위 개념인 B 여러 개로 구성되며 B가 하나라도 판매가 가능하면 A는 판매 가능한 상태이다
BEFORE 기획 : [판매 가능 상태]라는 속성은 B에만 있음
트리거 [가] 발생시 A에 속한 B의 판매 가능 상태를 조회하고 모든 B 요소가 판매 가능하면 A가 판매 가능하다고 판단하고 검증 조건을 통과시킨다
AFTER 기획 : [판매 가능 상태]라는 속성은 A,B 모두에 있음
모든 B 요소가 판매 가능한 상태가 되면 A의 판매 가능 상태는 O가 된다. 트리거 [가] 발생시 A의 판매 가능 상태를 조회해 검증 조건을 실행시킨다
BEFORE 기획에서는 트리거가 발생할 때마다 B의 뎁스까지 들어가야 하는 비효율성이 발생하고, A가 검증 조건으로 활용되는 중요도 높은 요소임에도 불구하고 자기 자신 혼자만으로는 온전하게 설명되기 어려운 불완전성이 발생합니다. 트리거 [가] 발생시 궁극적으로 알고 싶은 것은 A가 판매 가능한 상태인가? 이지, A의 하위 개념인 B들의 판매 가능 상태가 아닙니다. 그래서 A에도 [판매 가능 상태]가 명시적으로 존재할 수 있도록 기획서를 수정했습니다.
이 때 받았던 피드백을 DDD 관점에서 이해하고나니, 다른 기획건도 선제적으로 검토할 수 있었습니다. 무조건 분리해! 무조건 통합해! 와 같은 절대적인 원칙이 있는 것이 아니라, 지금 우리가 풀어야 하는 문제를 앞에 두고 각 관점의 비용/이점을 고려해 결정해야 한다는 것도 새삼 느꼈고요. 앞으로 비즈니스를 투영한 데이터 구조 설계를 요청할 때 이 관점을 꼭 적용해봐야겠습니다.
04. 관심사 분리하기
기획서 공유 미팅 후에 백엔드 엔지니어 분들께서 ERD 초안을 제작해 공유해주셨습니다. ERD를 보면서 발견한 것은 기획서 상에 명시된 개념 (ex. 주문, 수강) 외에도 개념과 개념을 연결하기 위한 테이블도 있다는 점이었습니다.
주문과 수강이 연결되는 것은 비즈니스 로직 구현을 위해 필요한 것이지 주문과 수강 각각의 독립성을 위해 꼭 필요한 정보는 아닙니다. 어찌 보면 관심사 밖의 영역이라고 볼 수 있습니다. 다만 비즈니스에서 아주 중요한 결합 관계이기 때문에 이 둘이 결합되었을 때 추가되어야 하는 맥락이 많은데요. 그래서 이 결합 관계 자체를 하나의 고유한 개념으로 만들어 구현하려고 하신다는 것을 알게 되었습니다.
기획서를 작성할 때에는 각 요소의 독립성보다는 요소들이 어떻게 연결되고 어떤 로직에서 활용되어야 하는가, 를 중심으로 생각하게 됩니다. 그래서 하나의 요소가 활용되는 맥락/조건이 한 개가 아니라 여러 개가 되면 그 수만큼 머리가 복잡해지게 되는데요. 이 때 마치 ERD를 그리는 것처럼 개념을 분리해보면 기획 사고를 간결하게 하는 것 (+) 제가 생각한 것을 개발자와 비슷한 언어로 치환해서 설명하는 것 에 큰 도움이 되겠다 싶었습니다.
프로젝트 1차 마일스톤이 종료되기까지 1달 반 정도 남았습니다. 남은 마일스톤을 더 수월하게 진행하기 위해 / 그 다음 프로젝트의 시행착오를 줄이기 위해 선택할 수 있는 공부 소재는 정말 많을 것입니다. 저는 지난 한 달 간 엿보기로나마 배운 DDD 관점에서 기획 사고를 굴려보는 것이 아주 유용했습니다. 그래서 남은 1달 반 동안 틈틈이 아래 책으로 '구현 방법보다는 생각의 관점으로써' DDD를 공부해보려고 합니다. 더 얻는 바가 분명해지겠지요? 공부하고 브런치에 또 남기겠습니다 총총.
