나는 매일 아침 8시 30분쯤 출근한다. 일찍 출근해서 커피 한 잔을 즐긴 다음, 본격적으로 업무를 시작하기 전 30분 내의 시간을 사용하여, 마치 하나의 ‘검색엔진 크롤러’처럼 온갖 개발 관련 블로그나 메일링을 훑으며 정보를 수집한다.
이 ‘검색엔진 크롤러’는 아주 치명적인 취약점이 하나 있는데, 관심이 있는 주제를 찾게 되면 한동안 그 주제에 대한 정보 위주로 찾는 취약점이 있다. 도메인 주도 설계를 그렇게 접하게 되었다.
처음 이 책을 읽기 전에 가볍게 목차를 훑어보니 개발과 관련되어 있다는 느낌을 받았다. 이 책을 읽고 난 뒤에는 설계와 관련된 개 발 스킬을 자유자재까지는 아니더라도 설계를 할 때 도메인을 고려하는 내 모습을 상상하기도 했다. 도메인 주도 설계에 대해서 이름 외에는 아는게 없던 나는, 이 분야에서 주로 사용하는 단어가 무엇인지 느낌을 파악하기 위해 가볍게 1차 속독을 했다.
속독을 끝마치고 난 뒤, 큰 충격에 빠졌다. 이 책은 개발 스킬을 전수하는 비법서가 아니었다. 비법서가 아니라서 충격에 빠진 것이 아니다. 왜 이제서야 DDD에 대한 지식, 책을 읽었는지 후회의 충격이었다. 본래 목적은 DDD를 이해하고 프론트엔드 아키텍처에 녹여낼 수 있는지 알기 위해서였다. (짧게 이 부분에 대한 생각을 남기자면, 프론트엔드에서는 DDD를 적용할 수 있는 범위가 많지 않은 것 같다.)
이 책은 DDD에 대한 입문서가 아니다. 읽고 나서 바로 할 수 있도록 지도하지는 않지만, 나처럼 급격하게 관심이 생긴 사람들에게 앞으로 어떤 것을 알아야 하는지에 대한 메타인지를 심어준다. 도메인 주도 설계 구현이나 도메인 주도 설계와 같은 책을 읽기 전에 좋은 디딤돌이 될 것 같다.
책에서는 애자일 프로젝트 관리 제품을 예시로 들어서 DDD를 설명하고 있다. 바로 DDD에 대한 개념을 설명하지 않고, 우리가 흔하게 저지를 수 있는 문제를 재현하기도 하고, 각종 사례를 통해 왜 DDD가 중요한지 설명하고 있다. 언젠가 내가 설계와 관련된 문제에 직면했을 때 했던 몇가지 고민들이 책 안에 사례로 나와서 공감하며 읽었다. 비록 프론트엔드를 주력으로 삼기에 그 수는 많지 않았지만 대부분 나쁜 사례로 소개되었다.
개발적 인 측면에서 많은 정보를 포함하고 있지만, 어떤 부분은 애자일과 크게 관련된 내용도 있다. 나는 DDD가 애자일 조직에서 좋은 소프트웨어를 설계하기 위한 방법론이라고 생각된다. 설계는 애자일 팀원 누구나 할 수 있는 일이고, 공동의 이해를 추구하는 것은 매우 중요한 일이기 때문에 좋은 소프트웨어, 나아가 좋은 제품을 만드는 것에 관심이 있다면 개발자 외의 직군도 읽기 좋은 것 같다. 다른 DDD 서적은 읽지 않아서 모르겠지만, 적어도 이 책은 그렇다.
