상태와 이벤트라는 모호한 말이 낳은 결과 찾아내기

전편에 이은 일상 협업 이야기 시리즈입니다. 즉흥적으로 참조 아키텍처를 선정해서 해보자고 동료들에게 제안한 다음에 벌어지는 일은 역시(?) 기대와는 다르게 펼쳐졌습니다. 즉흥성이 갖는 한계를 또 확인하는 순간이었습니다. ^[1] 동료가 복잡한 상태 정의 내용을 저에게 보여주었는데, 자료를 보는 내 자신의 감정이 불편했습니다. 지금에 와서 생각해보면 불편해할 일이 아닌데 복잡한 숙제가 던져진 듯한 느낌을 갖게 되었습니다.

무거운 감정을 걷어내고 뭔가 행동을 하기 위해서 가장 먼저 한 일은 '그림을 보고 왜 내가 불편한가?'를 파악하는 것이었습니다. 한참을 쳐다보다가 드디어 원인을 알았습니다. 첫번째는 내가 가정한 상태와 동료가 생각하는 상태는 일단 용도가 다르다는 데에 있었습니다.

같은 말을 쓴다고 서로 같은 것을 나타낸다는 보장은 없다

나중에 관련한 동료들이 모인 자리에서 설명하면서 명확해졌습니다. 그가 그린 그림은 주문과 관련한 전 과정(장바구니 처리, 결제, 주문 추적, 반품 등)에서 발생할 수 있는 모든 상태를 표현한 결과입니다. 그림을 그린 동료는 이커머스 베터랑인데 이커머스 경험이 별로 없는 두 명의 중국인 동료와 함께 개발하고 있습니다. 자연스럽게 중국인 동료들이 '왜 이렇게 짜야 하느냐?'는 질문을 계속 하는데, 질문에 답을 하다보니 스스로 명확하게 정리해두지 않으면 답변하기 어려워서 그리면서 정리를 했다고 합니다.

반면에 필자가 암묵적으로 상태라고 말하면서 가정한 내용을 끌어내보니 아래와 같았습니다.

• 암묵적으로 마이크로서비스 단위 즉, 모듈^[2] 단위를 객체로 취급했다.
• 상태는 두 개 이상의 모듈이 공유할 필요가 있는 것 위주로 생각했고
• 따라서, 상태 변화는 특정 모듈이 다른 모듈과 소통을 위해 만드는 이벤트이다.(앞선 글의 Order-based Vertex에 해당)

불편한 이유를 글로 써보기

이렇게 깨닫는 과정에서 글을 쓰는 행위는 무척 유익했습니다. 인식이 명확해지고, 글로 써보니 후에 동료들에게 설명할 때도 자연스럽게 설명할 수 있었습니다.

불편한 이유를 글로 써보기

내가 기대한 상태값은 저렇게 많고 세밀한 것이 아니었는데...

이 글을 쓰며 다시 보니 앞선 글에서 쓰인 모호한 표현에서 잘못된 기대의 흔적을 찾습니다.

현재는 주문 상태 머신(Order State Machine)을 구현하는 상황이기 때문에 지금 다루는 이벤트는 모두 주문 관련 이벤트죠

상태란 말에 대해서도 상태를 갖는 주체를 분명히 규정하고 있지 않았습니다. 우리는 마이크로 서비스를 택하고 있는데, 어떤 모듈^[2]의 상태인지를 정하지 않고 생각을 퍼뜨리고 막연하게 비슷한 생각으로 작업을 하기를 기대했습니다. 어리섞은 일이죠.

다시 상태를 규정하기

문제가 모호한 정의였으니 정의를 세밀하게 시도합니다. 어떤 상태와 이벤트를 기대했을까? 현재 프로토타입 수준인 화면을 보고 생각해봅니다. 과거에 동료와 논의하여 정한 업무 절차를 반영한 결과가 화면과 데이터로 표현해둔 결과를 활용합니다.

주문 상태 머신(Order State Machine)에서 다루는 상태를 명확하게 함

그때 생각했던 내용이 일부 다시 떠오릅니다. 내 생각의 함정에 빠지지 않기 위해 해당 화면 개발자와 다른 관련자를 모아 두고 각 상태가 어떤 때를 나타내는지 질문하는 시간을 갖습니다. 그 결과를 요약한 상태도는 아래 내용입니다. 한국 개발자와 중국 개발자가 섞어 있어서 두 개 표현^[3]이 섞여 있습니다.

동료들 의견을 모아 그린 상태도

틈이 더 벌어지기 전에 공유하기

동료들과 우리가 진행하는 일이 여기 글로 공유하는 맥락만 있지는 않습니다. 다양한 개발 상황이 함께 어우러져 있습니다. 그래서, 오해를 깨닫고, 또 제가 다시 정의한 상태에 대해서도 오해가 커지기 전에 이해한 바를 공유합니다. 우리가 하는 일에 대해서 이해가 달랐던 점을 제가 이해하는 선에서 설명하고, 다른 동료들 의견을 듣는 시간을 보냈죠.

이런 협업 경험을 할 때면, 유럽축구팬이기도 한 저는 마치 유명 유럽 프로축구 구단에서 공수간격을 촘촘하게 유지하는 훈련을 하는 일을 연상합니다. 어쩌면 협업의 본질이나 팀웍을 촉진하는 특성을 찾을 수 있을지도 모른다는 막연한 기대를 하면서 말이죠.

그런 가운데 다른 한 동료가 Kafka Streams를 써보기 위해 간단한 샘플 코드를 작성하고 있다는 기쁜 소식을 듣습니다.

주석

[1] 막연히 판타스틱(?)한 다음 행보를 기대했지만, 가장 먼저 확인한 사실은 모호한 기대가 낳는 실망감입니다. .

[2] 특정 마이크로 서비스를 모듈이라고 부르고자 합니다.

[3] 제가 아는 중국어중에서 여기저기 쓰여서 다른 한국 개발자도 유추할 수 있는 단어는 중국어로 씁니다.