도메인 이벤트 처리 구조 개발의 시작
디지털 코어의 시작 5
<도메인 이벤트 정의하기>편에 소개했던 깃허브 이슈에 대한 동료의 첫 작업을 리뷰했다.
깃허브를 이용한 업무 범위 구체화와 우선순위 조정
개발 우선순위 조정과 범위 변경은 깃허브 이슈에서 대화로 진행되었다. 먼저 <도메인 이벤트 정의하기>편을 동료에게 읽어 보라고 조언했다.
동료가 나름의 판단을 해서 질문을 올렸다.
나는 데이터 수집을 해서 보여주는 처리와 새로운 프로그래밍 구조를 모두 반영하면 난이도가 높아지고, 병목이 생길 우려가 있으니 중요한 것에 집중하자는 생각을 하고 동료에게 의사를 전달했다.
비대면 협업과 대면 리뷰의 힘
HBR에서도 하이브리드 근무에 대해 다룰 정도로 코로나팬데믹 이후 비대면 협업가 필수인 환경이다. 협업 관점에서 비대면이 좋은 점은 업무 할당이나 협의한 이후 데모나 리뷰 이전까지는 개입 없이 작업자에게 자유가 주어진다는 사실이다. 그렇게 되면 작업자가 업무 요청을 보낸 사람에게 의존하려는 욕구를 떨쳐 내고 온전히 자기 의지로 작업하는 자율성을 높아지게 된다. 입장을 바꿔보면 작업을 요청한 사람 입장에서 작업자가 눈에 보이는 경우 쉽게 작업자의 중간 과정에 개입할 수 있는데 비대면은 이런 개입이 원천 봉쇄된다.
우리의 사례에서는 애초에 내가 요청한 이슈(업무)의 제목이 '도메인 이벤트 기반의 처리 첫 반영 경험'일 정도로 모호하기 때문에 비대면이 도리어 효율을 높였다는 생각이 든다. 물론, 사후 판단이다.
하지만, 그렇게 스스로 결정한 부분이 많은 만큼 동료는 비대면 검토가 꼭 필요하다 느낀 듯하다. 다른 동료를 포함하여 3자로 진행한 비대면 검토는 많은 영감과 다자 교류를 낳았다.
의도한 도메인 이벤트 처리 구조의 원형 생산
팀의 성과로 말하면 내가 의도한 도메인 이벤트 처리 구조의 원형이 만들어졌다. 그리고 위임이 잘 이루어졌고 개발자(동료)가 범위를 잘 조절한 탓에 비교적 짧은 시간에 적절한 수준의 원형이 만들어졌다. 그는 깃허브에 공개된 샘플을 찾은 후에 불필요한 기술을 모두 제거하고, 도메인 코어의 맥락에 맞춰서 간단한 응용 사례를 새로 만들었다. 이에 대한 구체적인 내용은 우리 회사의 작업 공간인 깃허브 OSS에서 언젠가 공유하기로 한다. 개발자인 동료가 해야 할 일이기 때문에 언제일지는 모른다. :)
아무튼 대면 회의 결과로 동료는 아래 두 작업을 스스로 만들었다. 그에 대해 역시 앞에서처럼 업무 범위 조정과 우선순위 설정을 위한 소통이 있었지만 이는 생략한다.
한편, 앞서 대면 리뷰의 효과로 많은 영감과 다자 교류를 말했다. 작업을 요청한 나는 기대했던 바와 모르던 사실을 알게 되었다. 그리고, 개발자와 양자 소통을 하면서 다음 단계에 대한 그림을 머릿속에 그릴 수 있었다. 많은 영감은 바로 이 머릿속에서 벌어진 현상인데, 대면 미팅이니 그 자리에서 따끈따끈할 때 동료들에게 공유할 수 있다. 즉흥적인 생각인지라 짧게 인상만 전달한다. 그저 무언가 나도 영감을 얻었고, 앞으로 나아갈 방향에 대해 대강의 방향이 있음을 알릴 목적이라 지루해지지 않게 짧게 말하는 일이 중요했다.
앞으로 적절한 주기로 업무 요청을 하고, 제품으로 키워갈 수 있는 다른 기회와 조정을 할 생각들이 구체화되는 것을 느꼈다.
대화의 힘 그리고 대화가 만들어가는 설계
또 다른 이점인 다자 교류의 흔적이 칠판에 남았다. 도메인 스토리텔링을 하는 다른 동료는 개발자 출신이 아니라 기술 구조에 대한 이야기를 이해하는데 어려움이 있었다. 하지만, 그는 논리적 사고가 가능해서 어느 정도 이해하고 싶어 했다. 다만, 기술을 좋아하는 탓에 영감을 받아서 넘겨짚고 마음대로 이해하는 내용 속에 비약이 많았다. 나는 지나치다 싶은 부분에서 일어나서 그림을 하나 그렸다.
<MSA에서 정합성 보장은 어떻게 하나요?> 혹은 <분산 트랜젝션 대신에 도메인 이벤트 MSA 패턴>편에서 일부 다룬 지식이지만, 불특정 다수가 아닌 그 동료에게 맞춘 설명을 할 수 있었다. 이것이 바로 대화의 힘이고, 대면 리뷰가 기회를 제공한다. 이렇게 또 대화의 힘을 강조했더니 며칠 전 요즘IT에 기고한 글에서 강조했던 문장들이 떠오른다.
설계 결과물은 소통의 일부로 함께 대화하는 맥락(다른 말로 도메인이라고 함) 안에서만 힘을 갖는다는 말입니다.
위 그림에 대해 아주 간단하게만 설명하면, 분산 환경에서 정합성 보장은 DBMS가 제공하는 트랜젝션 처리에 의존하지 않거나 제한적으로 의존하는 일이다. 그림에서 왼쪽 통이 DBMS를 묘사한 것인데 논리적으로 Lock을 걸어 줄을 세우는 일로 묘사했다. 반대편의 그림은 다수의 DBMS를 쓸 때 순서가 꼬이거나 누락도 있을 수 있음을 설명한 흔적이다. 그래서 결국 별도의 프로그램이 이를 처리해줘야 한다. 리뷰를 요청한 개발자가 그 방법을 구현해서 리뷰한 이후라 개발 경험이 없는 다른 동료에게 이 정도 설명만 보강하면 어느 정도 작동 방식을 비슷하게 이해할 수 있겠다는 생각이 들었다. 가운데 의사결정 기호(마름모)는 이벤트에 대한 기록을 보며 정합성 판단을 하는데, 해당 프로그램에서 이를 결정하는 기준은 시간순서 아니면 비즈니스 규칙에 따라 하게 된다는 기본적인 원칙을 쓴 것이다.
협업의 결과물
앞서 말한 대로 팀의 성과란 관점에서는 내가 의도한 도메인 이벤트 처리 구조의 원형이 만들어졌다. 하지만, 그 과정에서 개발자가 자율적으로 결정한 부분이 많다. 그는 통제력에 대한 자신감을 획득하는 방식으로 진행을 했다. 이는 기술 부채가 만들어질 가능성을 줄인다. 그리고, 리뷰 전과 후에 깃허브 이슈와 두레이 업무의 비대면 소통에서 그리고 대면 리뷰 대화 과정에서 결과물이 나오는 속도(velocity)에 대한 중요성을 공감했다. 그리고 대화 과정에서 서로의 기준과 원칙에 대한 암묵지도 알게 된다. 이는 코딩만이 아닌 전체 개발 속도에 긍정적인 영향으로 누적될 것이라고 믿는다.
지난 디지털 코어의 시작 연재
2. 도메인 이벤트 정의하기
3. 왜 디지털 코어인가?
