DDD의 재발견
DDD 강의를 하는 박재성님을 만났다. 그 분이 DM을 보내 만나게 되었다. 아마도 얼마전에 한국에 다녀간 일민형이 호감을 갖고 있는 분인데 그 인연으로 만난 듯도 하다. 한편, 박재성님은 나와 만나기 전에 페이스북을 통해 DDD가 유럽에서 활발하게 커뮤니티를 형성하고 있다는 사실을 일깨워주었다.
반가운 도메인 스토리텔링 서문 시작 문장
그리고 우연치 않게 박재성님을 만난 다음 날 Domain Storytelling 종이책을 선물 받았다. 책을 받은 김에 쓱 훑어 보는데 linkedin에서 자주 만나는 Vaughn Vernon 시그너처 시리즈다. 이북으로 볼 때는 검색해서 보기 때문에 서문은 읽지 않았는데, 서문을 읽자마자 혼자 호들갑을 떨다가 이 글까지 쓰게 되었다. :)
In 2004, Eric Evans published Domain-Driven Design, a timeless book that has become an all-time classic in software engineering literature.
와우! 너무나 반가운 말이다. 그 이유는 바로 박재성님이 사주는 짜장면을 먹으면서 내가 뱉은 DDD 감상평과 비슷해서 그렇다.
나는 박재성님께 DDD 책은 출간 당시(2000년 초반) 혹은 그 이전만 해도 소프트웨어 개발은 원시적인 (협업) 문화였다고 말했다. 그렇기 때문에 18년이 지난 지금에도 그 책이 널리 회자되는 것이며, 복잡한 소프트웨어 개발을 어떻게 하는지를 다루는 클래식이라고 주장했다.
인용문에 등장하는 timeless 그리고 all-time class 이라는 표현이 반가웠던 것이다.
MSA와 DDD의 궁합
나의 이야기를 듣던 박재성님이 또 한가지 사실을 알려주었다. MSA 거장인 Chris Richardson이 자신의 책에서 MSA와 DDD는 궁합이 잘 맞다는 표현을 했다는 것이다. 그렇군!
나는 재성님을 주장을 떠올리자 곧바로 DDD 책 표지의 Complexity를 떠올렸다. 궁합을 만들어주는 고리는 바로 복잡도에 있다.
MSA는 분산환경을 전제로 하기 때문에 MSA를 채택하기 전에 비해 무조건 복잡해진다. 소위 말하는 분산과 분할에 따르는 오버헤드 다른 말로 번거로운 부수작업이 뒤따른다. 하지만, 합당한 서비스 응답시간이나 확장성 혹은 빈번한 배포 주기를 얻기 위해를 어쩔 수 없이(?) 그 오버헤드를 지는 그런 일이다.
바로 그렇게 MSA를 택할 때 어떻게 협업을 할 것인가? 복잡한 코드를 인간이 다룰 수 있게 구성하는 방법을 가장 실용적인 책은 DDD라 할 수 있다. 그 궁합이구나!
살아 있는 DDD 커뮤니티
개발을 안하고 있으니(저는 개발자 출신 스타트업 경영자입니다) 그저 SNS 친구 관계로 접해서 우연하게 알게 되고 쓰고 있는 도메인 스토리텔링 기법도 (이제서야) 다시 보니 바로 DDD 커뮤니티를 이끌어가는 선각자들이 만든 도구였다.
링크드인에서 DDD 관련 외국 엔지니어들과 친구관계를 맺고 있어 알게된 Domain Storytelling 도구를 시험삼아 써봤더니 효과가 있었다.
물론, 아쉽게도 우리말이 아닌 영어로 하기에 우리나라 사람들에게는 비교적 높은(?) 허들이 있다. 아무튼 오래된 책이라고 여겼던 DDD가 생생한 커뮤니티로 유럽을 중심으로 핫하게 개발되고 있음을 깨달았다. 그리고 한 가지 더 깨달은 바가 있다.
주도권이 개발자에게 고객으로
내 페북 DDD 관련 글에 댓글을 달아주신 Raymond Hyuksoo Jang 님의 페북 글을 읽고 감탄한 일이 있다.
도메인 주도 설계는 그 주도권을 도메인 전문가에게 넘기겠다는 선언과 같다. 마치 지도 제작 전문가들이 지도를 어떻게 그려야 올바른지 잘 알면서도 그 지도를 사용하는 사람들의 이해관계에 따라 왜곡된 형태로 그려내는 것과 같다고 본다. 그러니 도메인을 이해하려고 노력하는 대신, 도메인 전문가의 말을 제대로 알아듣도록 노력을 하는 것이 올바른 방향이지 않을까 싶다.
키야~ 멋진 문장이다. 나는 이 글을 읽고 Agile Manifesto가 떠올랐다. 박재성님과 대화에서도 이러한 감상을 일부 공유한 적이 있다.
그 후에 회사 동료에게 같은 이야기를 다시 하면서 표현을 다듬었다. 나는 애자일 선언(Manifesto)을 소프트웨어 개발에 있어 르네상스 비슷한 것이라고 비유했다. 그 전에 존재했던 CMU 주도의 소프트웨어 공학 서적들은 개발전문가(2022년 한국에서 말하는 개발자와 조금 다를 수 있다)들이 다 알아서 요구사항부터 잘 정리할테니 고객은 돈이나 줘라. (그래놓고 쓰지도 못할 개떡같은 소프트웨어를 엄청 비싼 가격에 팔던)
그런 방식이 더 이상 무효하다는 반성이 애자일 선언의 배경에 있다. 그리고 그 유명한 스프링 프레임워크도 높은 주급을 받고 금융권에서 일했던 Rod Johnson 이 처참한 소프트웨어 결과물을 보고 내놓은 해법(시작은 책)에서 출발한 것이다.
혁명적인 저작골방에서 소프트웨어 개발하지 않는 시대
혼자 쓰는 프로그램을 만드는 것이 아니라면 개발자가 시장을 이길 수는 없다. 이런 생각을 담아 나는 박재성씨와 대화에서 저 때를 원시시대라고 표현했다.
아무튼 내가 DDD를 재발견한 포인트가 2개다. 하나는 아직 활발하게 개발되고 있다는 사실이다. 책은 18년 전에 나왔지만, 어떻게 적용하는지에 대한 노하우가 활발하게 쓰이고 공유되고 있다는 사실을 새로 알았다. 그리고 두 번째는 20 년이 지난 지금 보니 원시시대가 끝났다.
MVP라는 말로 대변되는 릴리즈를 빨리 하는 문화를 가진 기업이 과거의 소프트웨어 개발 방식을 취하는 기업에 비해 높은 경쟁력을 갖는다. 쉽게 말해 우월하다. 원시시대는 이미 지난 것이다. 그렇다면 지금 시대는 무엇이라 부를 것인가? 나는 클라우드(구름)라는 말이 마음에 든다. 나는 소프트웨어 개발 역시 조만간 표준화 되고 보편화 되는 산업의 일부로 변모할 것이라고 본다. 아직은 그게 어떤 모양인지 분명하지 않다는 점에서 클라우드를 떠올린다. 하지만 아주 머지 않은 시점에 정형화 될 수 있으리라 생각한다. 그 흐름에 합류해야 소프트웨어 개발에 대해 낡은 소리를 하며 '라떼'를 외치는 사람이 되지 않을 수 있다.
