동료의 상태도를 검토하기
한국의 마틴 파울러가 되기
형식을 갖춘 상태도의 등장
짝 모델링으로 감을 잡은 동료는 금세 형식화된 상태도를 만들어냈습니다. 시각화 도구를 이용해 만들어진 모습은 분명 가독성도 높고 보기 좋지만 그럴싸하게 보이는 착시를 주기도 합니다. 중요한 것은 정보의 정확성과 유용성입니다.
동료는 이 그림이 등장한 후에도 여러 차례 수정을 가했습니다. 동료는 정확성을 위해 인터뷰를 하며 계속해서 상태도를 수정했습니다.
하지만, 유용성은 동료 혼자서 판단하기는 어렵습니다. 애초에 모델러 즉, 그리는 사람만 보는 그림은 유용하다고 할 수가 없습니다. 그렇다면 어떻게 해야 유용한 그림을 그릴 수 있을까요?
과거의 실전 경험 소환하기
과거에 필자는 상태도를 이용해 3명의 개발자가 함께 사용할 프로그래밍 기준을 만들고 동시에 테스트 케이스의 기준이 될 상태표 작성의 기준으로도 사용한 일이 있습니다. 상태도가 없었다면 프로그램을 만들지 못했을 정도라고 해도 과언이 아닐 정도로 핵심적인 역할을 했던 경험입니다. 그 흔적은 문서로도 일부 남겨져 있습니다.
그런데 무려 2010년의 일이라 당시의 동료와 지금의 동료는 전혀 다른 사람들입니다. 상황도 다르고요. 결국 지금 상황에 맞춰 응용해야 합니다. 과거의 경험은 하나의 패턴으로 다시 유용하게 쓰일 수 있기를 기대할 뿐입니다.
동료의 회고를 살펴 다음 단계로 나아가기
협업도구 두레이 소통이 문화로 정착해서 좋은 점은 의사소통 비용이 적게 들고 소통 기회도 늘어난다는 점입니다. 아래 동료의 기록을 보고 대면 소통으로 상의할 항목을 짚어 봅니다.
그전에 상태도의 대표적인 기능 두 가지를 확인합니다. 제 경험도 그랬기 때문에 동료의 회고 기록이 일종의 패턴이라 판단했기에 대표적인 기능이라고 쓴 것입니다. 상태도를 그리면서 주요 사태의 변화를 비교적 정교하게 이해(붉은색 1번 표기)하게 됩니다. 물론, 논리적 추론이 바탕이 되어야 하는데, 이에 대해서는 다른 글에서 쓸 기회가 있을 듯합니다. 또한, 추가 확인이 필요한 부분을 발견(붉은색 2번 표기)하여 소통을 촉진하거나 효과를 높일 수 있죠.
대면 소통으로 다룰 것은 3번입니다. 모델러 스스로 쓰임새를 찾았지만, 협업에 쓸 수 있는지를 모색해 보는 것이죠.
지난 한국의 마틴 파울러가 되기 연재
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기
13. 설계는 변화에 대한 준비인가?
