주니어 스타트업 개발자가 마음대로 해석한 Domain Driven Design의 핵심 개념

요약

나는 개발자가

• 서비스를 잘 이해해야 하고
• 서비스 개선에 개발자로서 참여할 수 있어야 하고
• 서비스를 토대로 코드를 설계해야 한다고 생각한다.

이것이 내가 생각하고 해석한 도메인 드리븐 디자인의 개념이다.

 

서비스 로직대로 코드를 짜고 있긴 했었다

내가 처음 회사에서 서비스를 구현할 당시, 코드에는 아주 느슨한 규칙만 있었던 걸로 기억한다. 으레 초기 스타트업이 그렇듯 빠르게 개발하는 게 우선이었고, 내가 이해한 만큼의 서비스를 ㄱ내가 빠르게 구현할 수 있는 방식으로 코딩하였다. 먼저 누군가 개발해놓은 상태관리 store가 있으면 그냥 import해서 사용하였다. 만약 기존 코드로 해결할 수 없다면 해당 store에 기능을 추가하거나 나만의 store를 만들어냈다. 서비스 로직대로 코드를 짜긴 했으나, 코드 전체 설계는 서비스의 모양이 전혀 아니었다.

그림1. 규칙없이 되는대로 코딩한, 서비스의 모양이 보이지 않는 구조

잠깐 짚고 넘어가는 서비스 기반 설계 vs 데이터 기반 설계

서비스 로직대로 코드를 짜지 그럼 어떻게 짜?

이런 의문이 생길 수 있다. 나는 코드가 서비스 로직대로 동작하는 것을 말하는게 아니라, 코드의 모양이 서비스 구조와 비슷한지를 말하려한다. 엄격한 규칙에 따라 만들었더라도(설계가 깔끔하더라도),  코드의 모양이 서비스 구조와 다를 수 있다. 이것에 대해서 잠깐 설명하고 넘어가겠다.

 

나는 게시판을 만드는 것으로 개발을 배우기 시작했다. 게시판에는 유저, 게시글, 댓글, 좋아요 등과 같은 데이터가 있다. 그 데이터를 기반으로 각각을 CRUD하는 api가 있고 그렇게 서버를 설계하면 아래 그림과 같은 설계가 된다. 이게 내가 생각하는 데이터 기반 설계이다.

그림2. 데이터 기반 설계 예시

단순한 게시판은 서비스 로직이 단순해서 데이터 기반 설계를 해도 이해에 어려움이 없을 수 있다. 하지만 실제 서비스는 훨씬 복잡한 경우가 많아서, 데이터 기반 설계가 오히려 코드를 이해하는데 어려움을 주기도 한다. 예를 들어, 구매데이터와 회원 권한 데이터가 서비스에서 밀접한 관계라고 하자(권한과 관련된 모든 수정이 구매쪽에서만 발생한다). 구매모듈과 권한모듈을 따로 만드는 것 보다 같은 모듈로 묶는 것이 서비스와 코드를 이해하는데 더 도움이 될 것이다. 그림2로 예시를 들면, 글과 댓글, 좋아요가 모두 글과 강한 연관성이 있으므로 하나의 모듈로 만들 수 있을 것 같다.

 

인하우스 개발자이지만 외주 개발을 하는 것 같았다

입사초기에는 프로덕트의 기획이 완료되면 디자인이 진행되면서 개발자에게도 요청이 왔다. 나는 기획의도를 잘 이해하기 위해서 노력했다. 질문도 하고, 설계도 생각하다보면 개발자로서 더 좋은 것 같은 방안도 생각났다. 그런 제안이 반영될 때도 있었지만, 이미 기획된 내용을 엎어버려야 할 때도 있어서 반영하기 힘들 때도 많았다. 내가 낸 제안이 반영되지 못하는, 그런게 몇 번 반복되면 사람은 아예 좋은 방안을 생각해내지 않는 쪽으로 바뀌기 쉬운 것 같다. 내가 그랬고 그냥 기획한대로 개발하는 사람이 되어가고 있었다. 외주 개발자와 별로 다를게 없다는 생각에 동기부여도 많이 떨어졌던 것 같다.

 

우리가 도입한 도메인 드리븐 디자인(Domain Driven Design)의 형태

개발팀이 더 이해하기 쉬운 코드의 구조를 고민할 때, 당시 개발팀장이었던 타코는 도메인 드리븐 디자인(이하 DDD)에 푹 빠져있었다. 나는 당시 그 개념이 쉽게 이해되지 않아서 시큰둥한 반응을 보였던 것 같다. 그럼에도 불구하고 타코는 링크를 공유하고, 책을 사서 보는 등 열렬히 DDD를 설파했다. 그러다 DDD의 일부를 팀에 적용해보기로 얘기되었고, 이벤트 스토밍(Event Storming)이라는 개념을 만나게되었다.

우리는 이벤트 스토밍을 이런 과정으로 진행했다.

1. PM(or 기획자)이 생각하는 프로덕트의 초안과, 그에 따라 발생하는 주요 이벤트, 정책 등을 정리해온다. 여기서 이벤트란 "유저가 로그인한다", "구매를 완료한다" 등 서비스에서 발생하는 사건과 그 후 서비스에서 처리되는 플로우를 얘기한다.
2. PM에게 설명을 듣고, 이벤트나 정책에서 수정할 부분을 수정하며 디테일한 이벤트 차트를 완성시킨다. 이때 디자이너나 개발자가 각자의 도메인 지식을 활용해서 개선할 수 있는 부분에 대한 의견 제시를 할 수 있다. 제시된 의견은 보통 PM이 종합하여 의사결정에 참고한다.
3. 이렇게 이벤트 차트를 정리하면, 정의가 필요한 용어가 생긴다. 이런 용어를 기획,디자인,개발이 모두 이해하는 언어로 작성한다. 이런 언어를 유비쿼터스 언어라고 한다.
4. 만든 이벤트 차트를 기반으로 개발이나 디자인을 한다. 하다보면 이벤트 차트의 수정이 필요한 경우가 생긴다. 그러면 PM등 관련자와 소통하고 수정한다.
5. 프로덕트를 완성할 때까지 4를 반복한다.

개발자는 이벤트를 바탕으로 데이터 모델을 만들고, 이벤트와 정책을 모아서 모듈을 만든다. 우리는 보통 모듈별로 한 사람씩 맡아 작업하였다.

 

이전과 비교하여 좋아진 점

1. 프로덕트에 기여도가 높아졌다고 느끼며, 프로덕트에 대한 애정도 더 생겼다

이전에는 의견이 있더라도 언제 제안해야할지, 제안하는게 선을 넘는 건 아닌지 고민했었다. 또, 의견이 반영되기 힘들것이라는 선입견도 있었다. 하지만 명시적으로 절차(이벤트스토밍)가 생기면서 그런 불안이 없어졌다. 내가 개발 지식으로 프로덕트에 도움을 줄 수 있다는 사실이 좋았다. 심지어 실제로는 의견을 내지 않았어도 이전보다 프로젝트에 더욱 기여하고 있다고 느껴졌다. 개발 전에 전체 프로덕트에 대한 설명을 들을 수 있는 것도 좋았다. 기획의도를 이해할 때까지 마음껏 질문할 수 있었다. 이전보다 더 "우리 프로덕트"라는 느낌이 들었다.

2. 이해하기 쉬운 코드를 쓸 수 있었다

1에서 말한대로 서비스를 깊게 이해하였고, 이를 바탕으로 모듈을 설계하였다. 서비스의 모양과 유사한 형태로 모듈이 작성되었고, 코드를 이해하기가 쉬워졌다. 서비스에서 관계에 따라 모듈을 만들었기 때문에, 모듈간 연결도 전에 비해 많이 느슨해졌다. 같은 기능이나 데이터를 두번 만드는일도 적어졌으며, 유비쿼터스 언어 덕분에 다른 사람의 변수명을 이해하기도 쉬워졌다. 이전에는 기획에서 쓰는 용어와 개발에서 쓰는 용어가 달라 의사소통에 혼동이 있었는데, 그런 것 또한 줄어들었다.

DDD를 적용하며 어려웠던 점

• 이벤트 스토밍을 할 때, 개발자들끼리 "어떻게 구현을 할것인가" 에 대한 주제로 얘기가 길어질 때가 종종 발생했다. 적당히 끊기도 애매했던게, 그 논의의 결과에 따라 이벤트 스토밍 결과도 달라질 수 있기 때문이었다. 이 때 개발자가 아닌 사람들은 멍하니 기다릴 수 밖에 없었는데, 적당히 끊고 결과에 영향이 조금 가더라도 나중에 개발자끼리 얘기했어야 했나 싶다. 그런데 실제로 해보면 그게 잘 안됐다.
• 어디까지가 "개발자로서의 의견" 인지가 애매할 때가 있다. 기획자가 의도한 플로우나 정책이 맘에 들지 않을 수 있는데, 그걸 "내가 고객이라면~" 하면서 의견 제시하는 것이 선을 넘는 행위일 수 있기 때문. 그런 문제는 보통 답이 없는 경우가 많고, 그런 경우 토론하기 시작하면 딱 시간만 잡아먹기 좋은 주제가 된다. 조심하려고 하지만 한번씩 마음에서 튀어나와 후회하게 되는 것 같다.

 

마무리

큰 기업에선 좀 더 개발과 관련된 고민(로딩 속도, 인덱싱 최적화 같은)을 하느라 서비스에 쏟을 관심이 적어질 수도 있다고도 생각한다. 하지만 나는 내가 하는 서비스를 더 잘 알고 싶고 더 많이 기여하고 싶은 사람인가보다. 그리고 그런 사람들이 스타트업에 많을거라고 생각하기도 하고.