기부상태 UL로 만들어보기
실전 시스템 수준 리팩토링 사례 10회
제목을 뭐라 붙일까 잠시 고민하다가 굳이 필요하지 않지만 제가 좋아하는 개념인 Ubiquitous Language라는 용어를 슬쩍 끼워넣습니다. 소통 간격을 좁혀 바르셀로나 축구처럼 소프트웨어 개발 협력을 멋지고 세련되게 할 수 있다는 긍정적 거품을 담은 용어입니다. :)
그래서 기부 상태를 무엇으로 할 것이냐?
지난 글에서 소개한 바대로 수면 아래의 쟁점을 꺼내는 것도 좋고, 활발한 소통이 벌어진 일도 좋지만 소프트웨어 개발은 경제성을 지키는 수준에서 구현해야 합니다. 시간은 유한하고, 다른 할 일도 많죠. 다행히 새로운 편의점 택배 시스템 연동을 내보낼 시간이 우리에게 바람직한 방아쇠(trigger)로 작동했습니다. 해당 개발자가 그래서 일단 현재 기부 상태를 정해보자고 저와 기획자를 불렀습니다. 어떤 일이 벌어지게 촉진하는 역할을 해준 것이죠. 릴리즈 계획이 유용한 이유는 바로 이런 경제성을 지켜주는 일상의 장치가 되어 줍니다. 이 문장이 무슨 뜻인지 모르는 분들은 애자일을 전혀 모르신다고 봐도 좋습니다. :)
마침 회의실을 모두 점유 당해서 화이트보드를 쓸 수 없었습니다. 셋이니 둘러 앉아 종이에 쓰기로 하고, 생각이 가장 구체적인 개발자가 기록을 했습니다. 빠르게 의견을 물으며 수렴을 해가는 대화죠. 앞선 논의 과정이 우리에게 수렴을 향해가는 대화의 물길을 만들어주는 것입니다. 우리는 빠르게 현재 수준에서 구현 가능한 상태값들을 결정합니다. 대화는 길지 않았습니다. 맞은 편에 앉아서 제가 거꾸로 쓴 글씨인 확정이란 글자가 눈에 띄네요.
지식 정보를 디지털로 바꾸기
아주 짧은 순간 질문이 오갑니다. 서로 배려를 하거나 기다리는 순간이라 생각합니다.
종이를 누가 가져갈까요?
제가 종이를 가로채서 기획자에게 두레이 입력하시려면 종이를 가져가시는 것이 어떠냐고 제안합니다. 기획자는 흔쾌히 받아갑니다. 저는 지식 정보를 디지털로 바꾸기 위한 경로 설정을 한 것이고, 제가 이 조직에서 안내자 역할을 하면 우리가 구현한 정보 생산 역량을 확인하는 장면입니다. (저와 일해본 경험이 없는) 많은 독자분들은 이 문장들이 낯설 수 있습니다. 자연스러운 일입니다. 제가 다년간 해온 방식에 의미를 붙이고 개념화 하여 공유하는 것이니까요.
우리가 논의를 아무리 잘 마쳤어도, 구현 과정 쉽게 말해서 개발자들이나 프로그램에 입력하는 사람들이 오타를 만들면 그만입니다. 오타는 그나마 괜찮은데 의미를 오해해서, 맥락이 잘못 만들어지면 그걸 되돌리기는 더욱 어렵습니다. 디지털은 지식을 유통 가능하게 해줍니다. 기획자가 종이를 찍어 두레이에 등록하고, 회의에 참여한 사람들이 볼 수 있게 하는 일에서부터 지식의 유통은 시작됩니다. 그 기록을 토대로 제가 이 글을 쓰기도 하지만, 이 기록을 쓰기에 앞서 상태도를 그리고 개발자들이 모두 열람할 수 있게 할 것이기 때문입니다.
디지털 기록을 상태도로 바꾸는 과정
기획자가 아래와 같이 정의한 내용을 토대로 먼저 상태도를 그립니다.
상태도 표기 자체가 중요하지는 않습니다. 위에 기록한 내용으로 충분할 수도 있습니다. 다만 상태도가 주는 엄밀한 형식화 과정에서 우리가 누락한 내용이 있는지 보려는 목적으로 일단 그려보기로 합니다. 흥미롭습니다. 제가 기계가 아니고 사람이다보니 그림을 그리면서 또 생각하고, 새로운 제안을 그림에 추가하는 행동을 스스로 관찰하며 그렇게 느낍니다.
물론, 상태도 작성자의 결정에 따른 것입니다. 논의한 것을 그대로 그릴 수도 있습니다. 하지만, 저는 두 가지 논점을 추가하여 상태도를 기획자가 등록한 정보와 다르게 바꾸었습니다. 여기서 중요한 사실은 디지털로 기록이 바뀌어도 대화의 과정이라는 사실을 잊지 않는 것입니다.
그래서, 저는 함께 보는 협업 시스템에 아래와 같이 기록을 남기고 함께 논의한 분들의 의견을 구합니다. 상태도 확정은 그 다음에 이뤄지겠죠.
지속 가능한 형식화 과정
앞서 그린 상태도에서 취소에 이르는 길은 더 많이 존재할 것으로 추정합니다. 그렇지만, 현재는 의도적으로 하나면 표현했습니다. 동료 기획자가 후속 과업이라고 기록한 내용과 발맞추려는 의도입니다.
사용자 UI에서 기부 데이터가 만들어졌지만, 다양한 이유로 실제로 기부가 벌어지지 않는 부분에 대해 그간 적극적으로 대처하지 못한 부분에 대해 개선 방안을 마련하자고 논의했습니다. 그러한 방안이 만들어지지 않았는데, 상태도라는 그림만 상세하게 그리는 것은 공허한 활동입니다. 사용자가 있고, 지속 가능한 개발조직이 존재할 때 소프트웨어는 살아남을 수 있습니다.
예전에 제가 시도하는 협업 방식에 의문을 가진 분이 있었습니다. 개발 관리를 십 수년간 했던 분인지라 이렇게 질문했습니다.
그렇게 계속 변경하면, 프로그램이 만들어진 다음에 현행화는 어떻게 합니까?
제가 어떻게 답변했는지는 정확히 기억나지 않지만, 대략 아래와 같았습니다.
아주 중요한 질문입니다. 그 어려운 것을 해내는 것이 관건입니다.
그리고, 몇 개월이 지난 지금 그 일을 하고 있습니다. 확정적인 계획과 분명한 방법을 물었던 그 분은 우리와 함께 시작했지만 지금은 같이 하고 있지 않습니다. 당시 그 분은 본인이 이해할 수 있는 방법을 알기 원했지만, 사람은 자기가 해보지 않은 방법에 대해 설명을 듣는다고 해서 그걸 그대로 이해하거나 신뢰할 수 있을까요? 간단한 일이라면 가능할 수 있지만, 낯설고 두려운 일에 대해서는 설명을 듣는다고 해서 확신이 생기기 쉽지 않습니다. 우리의 기억과 이해는 경험에 기초하기 때문에 해보지 않는 낯선 일에 대한 다른 사람의 해법을 듣는 일은 그저 발을 뗄 수 있는 용기와 힌트를 줄 뿐입니다.
앞으로 이 연재를 통해 제가 계속 설명하려고 노력할 방법은 바로 이렇게 기록한 지식 정보가 바뀌는데 어떻게 유지하고, 지식 정보의 또 다른 형태인 코드(프로그램)과 어떻게 함께 활용(혹은 공존)하느냐에 대한 이야기입니다.
