brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Oct 11. 2023

동료의 상태도를 검토하기

한국의 마틴 파울러가 되기

형식을 갖춘 상태도의 등장

짝 모델링으로 감을 잡은 동료는 금세 형식화된 상태도를 만들어냈습니다. 시각화 도구를 이용해 만들어진 모습은 분명 가독성도 높고 보기 좋지만 그럴싸하게 보이는 착시를 주기도 합니다. 중요한 것은 정보의 정확성과 유용성입니다.

동료는 이 그림이 등장한 후에도 여러 차례 수정을 가했습니다. 동료는 정확성을 위해 인터뷰를 하며 계속해서 상태도를 수정했습니다.


하지만, 유용성은 동료 혼자서 판단하기는 어렵습니다. 애초에 모델러 즉, 그리는 사람만 보는 그림은 유용하다고 할 수가 없습니다. 그렇다면 어떻게 해야 유용한 그림을 그릴 수 있을까요?


과거의 실전 경험 소환하기

과거에 필자는 상태도를 이용해 3명의 개발자가 함께 사용할 프로그래밍 기준을 만들고 동시에 테스트 케이스의 기준이 될 상태표 작성의 기준으로도 사용한 일이 있습니다. 상태도가 없었다면 프로그램을 만들지 못했을 정도라고 해도 과언이 아닐 정도로 핵심적인 역할을 했던 경험입니다. 그 흔적은 문서로도 일부 남겨져 있습니다.

그런데 무려 2010년의 일이라 당시의 동료와 지금의 동료는 전혀 다른 사람들입니다. 상황도 다르고요. 결국 지금 상황에 맞춰 응용해야 합니다. 과거의 경험은 하나의 패턴으로 다시 유용하게 쓰일 수 있기를 기대할 뿐입니다.


동료의 회고를 살펴 다음 단계로 나아가기

협업도구 두레이 소통이 문화로 정착해서 좋은 점은 의사소통 비용이 적게 들고 소통 기회도 늘어난다는 점입니다. 아래 동료의 기록을 보고 대면 소통으로 상의할 항목을 짚어 봅니다.

그전에 상태도의 대표적인 기능 두 가지를 확인합니다. 제 경험도 그랬기 때문에 동료의 회고 기록이 일종의 패턴이라 판단했기에 대표적인 기능이라고 쓴 것입니다. 상태도를 그리면서 주요 사태의 변화를 비교적 정교하게 이해(붉은색 1번 표기)하게 됩니다. 물론, 논리적 추론이 바탕이 되어야 하는데, 이에 대해서는 다른 글에서 쓸 기회가 있을 듯합니다. 또한, 추가 확인이 필요한 부분을 발견(붉은색 2번 표기)하여 소통을 촉진하거나 효과를 높일 수 있죠.


대면 소통으로 다룰 것은 3번입니다. 모델러 스스로 쓰임새를 찾았지만, 협업에 쓸 수 있는지를 모색해 보는 것이죠.


지난 한국의 마틴 파울러가 되기 연재

1. 현실과 시스템의 불일치, 그리고 UX의 역할

2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기

3. Code Smells 비유와 기술 부채

4. 기술 부채를 Code Smell로 관리할 수 있는가?

5. 형상 구성단위로 TestCase 유용할까?

6. 설계 요소의 사분면

7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기

8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기

9. 소프트웨어 설계에서 입자의 응용

10. 소프트웨어 설계에서 파동의 응용

11. 설계란 무엇인가 IV Part.1

12. 설계란 무엇인가 IV Part.2

13. 설계는 변화에 대한 준비인가?

14. 대상이 되는 사태의 주요 내용을 한 장에 담다

15. 스윔레인으로 경계와 상호작용 드러내기

16. 짝 프로그래밍처럼 함께 설계하기

17. 짝 모델링으로 탄생한 상태도 초안

이전 17화 짝 모델링으로 탄생한 상태도 초안
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari