MSA를 대하는 개발자의 필수 마음자세
MSA 기술과 적용 연구 13
지난 글인 <MSA는 조직의 성장과 동반해야 한다> 편은 개발자에 초점을 두고 쓴 글은 아니다. 이번에는 개발자를 대상으로 어떤 점이 중요한지 의견을 써보려고 한다.
DDD에서 도메인(domain)의 의미
<토비의 스프링 3>로 유명한 이일민 씨와 대화에서 그는 한국의 개발자들이 DDD라고 하면 주로 Eric Evans 책에서 빌딩 블록을 코딩에 활용하는 수준이라고 말한다. 다시 말해 도메인 전문가와의 대화나 유기적인 지식 체계를 만드는 일은 전혀 염두하지 멋한다는 판단이다. 개발을 하고 있지 않지만 내 판단도 비슷하다. 이미 <도메인 모델, Ongoing 설계 그리고 정원관리> 편에서 썼듯이 우리 사회에서 도메인 모델링에 대한 이력은 매우 희박하다. 대부분의 개발자들은 그 말의 뜻도 잘 모를 수 있다.
암튼 그걸 내가 여기서 다 정리할 수는 없고, DDD를 말할 때 나는 (빌딩 블록 이외에) 두 가지는 알면 좋겠다는 생각이다. 특히, MSA를 적용한다고 할 때.
하나는 Domain Driven이 무슨 말인가 하는 것이다. Domain Driven은 무작정 무언가를 따라 해보는 방식의 반대다. <MSA 기술이전 사업을 시작하다> 편에 언급한 대로 묻지마로 API Gateway 도입부터 고민하는 방식의 정반대가 Domain Driven이다. 여기서 도메인(Domain)이란 '우리'를 말한다.
우리 회사의 서비스, 사용자, 우리의 비즈니스 그리고 우리의 운영방식
그건 어떤 기술이나 다른 회사의 성공 사례보다 우선해야 할 가치다. DDD가 출간된 지 10년을 넘어서도 아직도 회자되는 이유는 거기에 있다고 본다. (그것만 중요하다는 말은 아니지만)
경계를 나누는 기준
DDD를 도입해서 얻을 수 있는 또 다른 이점 중에 하나는 Bounded Context라는 개념 활용이다. 같은 말이라도 맥락에 따라 의미가 달라질 수 있다. 그 맥락이 영어로 Context이다. 그리고 프로그램 사용 중에 오른쪽 마우스를 누르면 매번 달라지는 메뉴가 있다. 이를 Context-sensitive Menu라고 부른다. 맥락에 따라 달라지는 메뉴란 뜻이다.
또 다른 용례로 <나는 애자일이 싫다> 편에서 조직의 협업이나 애자일을 다룰 때 아래 그림을 인용한 바 있는데 그 가운데 Bounded Context라는 말이 있다. DDD의 용어인데, 왜 애자일 이야기에서도 이를 다룰까?
우선 Eric Evans의 정의를 살펴보자. 사실 Bounded context는 Eric Evans 책에서 한 장의 제목도 아니다. Context Map이라는 장의 부가 요소일 뿐이다. 그러면 Context Map 정의를 먼저 보자. (Eric Evans 책 344쪽)
A CONTEXT MAP is in the overlap between project management and soft ware design.
연이어 Bounded context에 대한 기록을 보자.
An individual BOUNDED CONTEXT still does not provide a global view. The context of other models may still be vague and in flux.
시쳇말로 '케바케'를 말한다. 그리고 내 언어로는 <성공적 대화를 돕는 그림>을 말한다.
CRUD 중심 사고를 보여주는 현상
개발자에게 와닿을 수 있는 사례를 들어 그 개념을 알아보자. 두 개의 서비스가 별도로 배포되어 운영되는 분산 프로그래밍 상황에 대한 논의가 있었다. 현대적인 개발 경험이 없는 시니어 멤버 한 분이 접수 데이터는 한번 만들어지면 못 고쳐진다는 사실을 주니어 개발자들이 모를까 봐 우려하는 질문을 했다. 그는 다음 사항을 강조했다.
사용자는 한번 입력하면 못 고친다
나는 바람직하지 않은 낡은 시스템 관행이 퍼져나가는 일을 막기 위해 일어나서 그림을 그렸다. 두 개의 접수 데이터는 물리적으로 다른 것임을 강조했다. 내가 나선 중요한 이유는 개발자의 경험적 한계나 편행이라는 지극히 공급자적인 이유(모노리틱 시스템과 획일화된 데이터 구조) 때문에 사용자 불편을 가치인 양 강조하는 관행에 맞서기 위함이었다.
전산실(?) 경력이 많은 사람은 이런 구조가 바람직한 것이라고 믿고 있지만, 사실은 그렇지 않다. 맥락에 따라 동일한 데이터(개념)를 다르게 다룰 수 있다. 이런 구분이 Bounded Context라는 개념과 설명하려는 가치다.
분산 트랜젝션을 말하는 사람을 조심하라
세상이 바뀌고 상황이 바뀌어도 '예전에 다 해봤어' 하는 태도로 매사를 다루는 사람은 조심해야 한다. 경험은 유용한 것이지만, 경험으로 해석 능력을 키울 수도 있지만 경험에 갇히는 사람도 존재한다. MSA를 논하는데 혹시 아직도 분산 트랜젝션이나 2 Phase Commit 같은 말을 하는 사람이 있다면 조심해야 한다.
분산 프로그래밍 초기에는 트랜젝션을 원격으로 관리하는 일이 난이도 높은 일이었다. 하지만, 지금은 단순한 프로그램을 분산 운용하는 상황이 아니라 분산을 전제로 서비스를 구축하는 일이다. 그 차이를 모르는 사람들이 매우 많다.
트랜젝션은 단일 서비스 내부의 문제이다. 서비스를 넘나들어 일관성이 유지되어야 하는 처리는 도메인 이벤트를 정의하여 개발하는 방법을 권장한다. 도메인 이벤트까지는 몰라도 카프카 등을 이용한 구현 기법은 다양하게 존재할 수 있다. 다만, 딱 한 가지 방법은 고려 대상이 될 수 없다. 그게 바로 분산 트랜젝션이라는 구시대의 유물이다.
