객체 상태도의 실전 활용
실전 시스템 수준 리팩토링 사례 7회
관리자 화면에서 기부완료와 기부확정이라는 상태 표현을 보는 순간 제가 그린 기부 상태도가 떠올랐습니다. 바로 아래 그림인데, 관리 화면에 버젓이 있는 기부완료나 기부확정 같은 것은 보이지 않습니다. 각자 서로 다른 말을 쓰는 것에 무감각하고 동료(회사 소속을 떠나 관련하여 함께 일하는 사람을 통칭함) 아무렇지 않은 상황입니다. (필자의 머리속에는 Ubiquitous Language가 바로 떠오르지만, 전문용어 늪에 빠지기 전에 헤어 나오기로 합니다.)
UML과 상태도 쓰임새는 의사소통
UML과 상태도를 그리는 진짜 목적인 의사소통 개선의 순간입니다. 서로의 인식 차이를 확인했으니 개선의 길이 그 중 어딘가에 있는지를 소통해야 합니다.
기획자와 운영자의 상태 인식 묻기
기획자와 운영자에게 상태도니 뭐니 이런 것들 처음부터 들이미는 것은 좋은 소통 방법이 아닙니다. 사람들은 낯선 내용으로 대화를 시작하면 위축되기 마련이니까요. 그리고, 마음이 편안해야 소통이 원활해지죠. 그래서, 협업시스템에서 운영자님을 멘션하며 이렇게 글을 올렸습니다.
뒤이어 바로 기획자에게도 질문을 올려봅니다.
둘 다 앞서 설명한 소프트웨어 디자인 개선을 위한 비대면 협업의 사례죠. 소프트웨어 디자인은 개발자만 하는 일은 아닙니다. :)
고맙게도 바로 수 시간 이내에 피드백이 왔습니다. 그리고, 기대(?)한대로 기획자와 운영자 인식이 달랐습니다. UI 기획 의도와 실제 현장의 인식 차이가 있는지 확인하고 싶었는데, 이를 찾은 듯하여 반가운 기분이었습니다.
제 사고의 변화 과정을 정교하게 기록하기 위해 운영자와 기획자의 피드백을 각각 나눠서 다뤄보겠습니다.
운영자가 인식하는 기부완료와 기부확정
먼저 운영자는 기부확정과 기부완료에 대해 물었는데, 이 둘을 택배기부와 매장기부 맥락을 구분해서 답을 했습니다. 그리고, 제가 쓰는 표현과 비교하면 부가적인 단어를 덧붙여 이 둘을 부릅니다. 예를 들어, 택배기부는 행동이 벌어지는 편의점을 덧붙여서 편의점택배서비스라고 부르네요. 그리고, 이 경우는 서비스라고 표현합니다. 한편, 매장기부는 큐알이라는 앱에서 사용하는 수단을 지칭하는 단어를 넣어서 부릅니다. 그리고, 서비스가 아니라 시스템이라고 부르네요. 이 분이 서비스와 시스템을 어떻게 구분하는지 궁금하네요. 이 차이를 인식하고 의도적으로 구분해서 쓰는지 자신도 모르게 입에 붙은 말인지도 궁금하네요.
아무튼 이러한 특징을 지나서 질문한 내용에 대한 답을 보면, 기부 확정은 매장에서 기부를 접수받은 후에 메모가 없는 상태라고 인식한 듯합니다. 메모가 있다면 접수 완료이고, 기부 확정은 아니죠. 참고로, 메모가 있다는 것은 기부가액 판정 같은 후속 업무가 필요하다는 기록을 남기는 것을 뜻합니다.
기획자가 인식하는 기부완료와 기부확정
이번에는 기획자가 쓴 글도 비슷하게 분석해볼까요? 기획자는 기부 완료는 택배나 매장기부 모두에서 쓰이는 상태로 설명하네요. 관리자 화면에서 기부를 최초로 등록하면 전부 이 상태가 된다고 설명합니다. 관리자 화면을 기획한 사람의 입장이 잘 드러나는 듯합니다. 하지만, 운영을 하면 쓰는 분의 입장과 작은 차이가 있다는 사실이 흥미롭습니다.
두 번째로 기부 확정에 대해서는 전혀 다른 답이네요. 기부 확정에 이르는 어떤 행위의 주체를 운영자는 관리자(천사 또는 매니저)로 인식하는데 반해, 기획자는 기부자가 금액을 확인한 상태라고 합니다.
두 사람의 생각이 배치되는지 질문을 던지기 전에 시각적으로 확인하는 방법이 있어 시도를 해보겠습니다. 개발자들은 git/svn 같은 도구로 코드 저장소에 자기 작업을 올리는데, 이때 이전에 같았던 내용을 서로 다르게 고치면 충돌이 발생하고 이를 해결하고 병합(merge) 해야 합니다. 이와 동일한 이치로 상태도 하나에 두 사람의 가정을 모두 그려보면 생각의 차이가 무엇인지 시각화해서 확인해볼 수 있습니다.
생각 차이를 Git을 쓰듯이 확인해보기
먼저 운영자님의 기록을 바탕으로 앞서 그렸던 상태도를 수정해봤습니다.
앞선 그림과의 차이는 기부라는 객체(혹은 행위) 안에서 택배접수냐 매장접수냐에 따라 시작의 맥락이 달라집니다. 그래서, 기부가 시작되는 상태가 3가지 경우의 수가 있네요. 그리고, 처음의 상태도는 향후 방향(TO-BE)을 고려해서 기부가액 산정이란 상태를 독립적으로 두었는데요. 다시 그리면서 운영자님이 보고 있는 현재(AS-IS) 시스템의 상태를 표현해서 소통을 원활하게 하는 것이 좋겠습니다. 제 머릿속에 있는 개선 방향을 상태도에 담으면 그걸 설명하기 전까지 논란이 생길 수 있으니까요.
여기에 기획자님의 생각을 따로 그리지 말고 그대로 반영을 해야 앞서 말한 생각의 충돌을 확인할 수 있습니다. 시도해보겠습니다. 일단, 시작부터 난항이네요. 아래와 같은 고민을 하게 됩니다.
택배 접수와 매장 접수 구분을 유지할 것인가?
매장 접수의 경우 기부완료 다음에 접수완료란 단계가 또 있는 것인가?
기부 확정이 확인서/영수증 발급 이후의 단계이면, 앞의 그림과 반대로 그려야 하는데 둘 다 지원하면 무한루프다!
확실한 충돌을 확인할 수 있습니다. 한 화면에 그릴 수가 없습니다. 차이를 확인하기 위해서 기획자의 의도 그대로를 따로 상태도로 표현해보겠습니다.
상태도의 실전 활용
거듭 강조하지만 모델링 결과의 쓰임새는 무엇보다 의사소통입니다. 매우 세밀한 상호작용까지 고려하여 비즈니스 규칙을 정교하게 소통할 때 바로 상태도가 빛을 발합니다. 실전의 사례를 기록한 것인데, 아주 전형적인 예시가 되었네요. 충돌이 생겼으니 말이죠. 앞서 제가 효과적인 협업을 위해서는 의사소통 과정에서 쟁점을 통해 갈등을 드러내는 일이 중요하다고 주장했습니다. 갈등은 비단 감정적 마찰만을 의미하지 않습니다. 서로 다르게 알아 충돌이 발생하는 일을 갈등이라고 부르지는 않지만 혼선과 낭비를 낳습니다. 그런 경우 표면적으로 나타나지 않았을 뿐, 결과적으로는 갈등을 초래합니다. 도리어 문제가 드러나지 않아 개선이 더 어려울 뿐이죠.
자 이제 서로의 생각차이가 드러났습니다. 그 차이를 명확하게 표현하는 서로 다른 상태도가 있으니 보다 정교한 소통을 할 수 있는 준비가 되었습니다. 일단, 뒤의 두 개를 갖고 기획자와 운영자가 함께 소통하는 자리를 마련하면 상호 이해도가 높아지는 기회가 생길 듯합니다. 그리고 나서 제가 왜 기부가액 산정을 바깥으로 두려고 했는지를 소통하면, 집단 지성으로 우리 팀에 가장 유리한 의견이 만들어질 수 있을 듯합니다. 그럼 저는 도전하러 가겠습니다.
