Git스러운 지식 정보의 개정(Revision)

실전 시스템 수준 리팩토링 사례 9회

지난 글에서 택배와 매장 접수 양상이 다른 점이 토론의 출발점이기도 했습니다. 택배의 경우 택배사 시스템의 정보를 통해 택배 추적을 할 수 있습니다. 기부상태와 별개의 배송상태 역시 관리할 필요가 생깁니다.

배송 상태의 도입

MVP 형태로 릴리즈한 기존 버전에는 배송상태 관리가 없었는데, 자연스러운 시스템 진화를 진행하는 것입니다. 자연스럽다고 표현했지만, 사실은 팀의 의사결정에 따른 결과입니다. 릴리즈는 비즈니스 효과를 주로 고려해야 하지만, 사용자는 물론 운영자의 편의성과 업무 효율, 프로그램을 단순 명료하게 유지하기 위한 개선 작업 등 다양한 요소로 고려해야 하죠.

배송 상태를 논의하는 과정에서 동료 기획자가 연동을 저와 다르게 이해하는 현상을 관찰했습니다. 그래서, 연동이 무엇인지에 대해 공론하는 시간도 갖었습니다. 연동에 대해 네이버 국어사전은 다음과 같이 정의합니다.

기계나 장치 따위에서, 한 부분을 움직이면 연결되어 있는 다른 부분도 잇따라 함께 움직이는 일.

동료 기획자는 택배사 주는 데이터에 기초한 배송상태 값을 기부상태에 추가하는 경우를 연동한다고 이해했습니다. 이 경우는 연동보다는 합친다는 의미의 병합 등의 표현이 적절합니다. 연결(聯)되어서 작동(動)하려면 배송상태를 기부상태와 연결하여 해석해야 합니다. 어떤 배송상태가 어떤 기부상태에 해당하는지 말이죠. 말뜻으로 볼 때도 그러하지만, 외부 시스템이 제공하는 상태값을 그대로 쓰는 것은 강한 결합(coupling)을 유발해 시스템을 우리 뜻대로 만들어가기 어렵게 만듭니다.

예를 들어, 특정 택배 시스템에서 상태값을 바꾸었을 때 그것을 그대로 기부 상태에 반영한 경우라면 외부 변화에 우리가 그대로 노출되겠죠. 우리는 여러 택배사를 연결할 생각이기 때문에 문제가 더 심각해집니다. 기부 과정에서 보면 비슷한 상태인데, 우리가 연동한 시스템이 서로 다른 상태값을 쓴다면 어떻게 될까요? 이러한 요소들을 소프트웨어의 의존성(dependency)이라고 하는데, 의존성은 가급적 느슨하게 꼭 필요한 수준으로 유지해야 합니다.

디지털 대화는 지식을 정보로 바꾸는 효과적 수단

다시 지난 시간에 이은 기부 상태 정의 과정으로 돌아가겠습니다. 앞선 제안으로 아래와 같은 대화가 60개의 글타래로 벌어졌습니다. 디지털 공간의 대화는 지식을 정보로 만드는 최초의 기록을 생산한다는 점에서 그 의미가 크다고 할 수 있습니다.

그 중에 놀라운 장면을 발견할 수 있었습니다. 기획자가 택배 연동 과정에서 만들었던 두 개의 상태를 나타낸 표를 소개해서 구체적인 대화를 도우려고 했더니 운영자가 이를 밈(meme)으로 활용하여 쟁점이 잘 드러나는 대화가 펼쳐졌습니다.

밈으로 쓰인 상태표 형식

재택근무중인 운영자가 개발자와 전화 통화를 한 후에 표 형식을 차용해서 본인의 이해한 상태를 표현하는 것입니다.

표는 정말 밈이 되어서 여러 차례 자기 의견을 넣은 상태표로 여러 차례 대화에 드러났습니다. 참고로 밈이란 비유전적 문화요소 또는 문화의 전달단위로, 유전적 방법이 아닌 모방을 통해 습득되는 문화요소를 뜻합니다.

코드 저장소 Revision을 떠올리다

상태표 중심으로 내용이 계속 정제되는 과정을 보려니 코드 저장소 Revision 과정을 보는 듯했습니다. 상태표로 지식을 통합하는 과정에서도 git 을 언급한 바 있습니다. 협업으로 기록을 남기고, 상태도나 상태표 등이 형식화(formalization)를 도와 쟁점이 좁혀졌습니다. 더불어 밈 효과까지 낳아 지식이 디지털 기록으로 점차 구체화 되는 과정을 지켜보며, 프로그램 코드와 굉장히 가깝다는 인상을 받았습니다.