한국의 마틴 파울러가 되기
동료의 빠른 업무 파악을 위해 상태도 작성을 권했습니다. 왜 그랬을까요? 경험에 바탕을 둔 직관적 행동이라 근거가 언어로 떠오르지 않았습니다. 제 행동 패턴을 찾기 위해 브런치 글을 '상태도'로 검색해 보니 29개 페이지가 있습니다. 이를 쓱 훑어보니 과거 행적이 떠오릅니다. 예전에도 특정 업무의 핵심 개발자로 성장하고자 하는 동료에게 상태도를 권했던 흔적이 있네요. 다음은 상태도에 대해 다뤘던 기존 글 중에서 상태도와 관련성이 많은 글을 추린 내역입니다.
상태도를 왜 쓰는지 그리고 어떤 효용성이 있는지는 동료의 상태도 그리기가 어느 정도 마무리 된 후에 다시 회고하며 기록으로 추출하기로 합니다.
동료 검토(peer review)를 하다 보면 보이지 않던 것들을 볼 기회가 생깁니다. 산출물을 제가 작성할 때는 내용에 집중합니다. 하지만, 검토는 조금 다릅니다. 예를 들어 동료가 그린 아래 상태도를 볼 때 내가 떠올린 생각들을 대강 열거하면 다음과 같은 식입니다.
빠진 내용이 없나?
용어 사용에 대해 (나도 모르게) 내 취향에 빗대어 비교하거나 평가한다
표기법 상의 오류를 바라본다
특정 내용에 대해 주목한다
종합적으로 말하면 다양한 인지 작용을 감지할 수 있습니다. 그러다가 이 중에서 어떤 내용을 입 밖으로 꺼내는 것이 유용할까 고민하죠.
다양한 제 생각이 있다고 해도 듣는 이에게 제대로 전달될 때만이 대화(对话)가 제 의미를 갖습니다. 이런 사실을 명징하게 이해하게 한 사건은 10년쯤 전에 인도 엔지니어링 관리자 Prasad Prabhakaran와 일할 때 그와 함께 한 회의입니다. 그는 회의를 시작할 때 항상 'look at the same page'라고 말하고 이해의 기반을 마련했습니다. 제 기억이 맞는지 확실치 않아 구글링 해 보니 다음 영어 표현이 주로 등장하네요.
아무튼 이해를 같이 하기 위해서는 관심사를 좁힐 필요가 있습니다. 제 버전으로 이를 그린 그림이 <성공적 대화를 돕는 그림>의 교집합이기도 합니다.
교집합의 구현은 한 번에 하나씩 초점을 맞춰 다루는 일입니다. 상태도를 실전에 활용한 적이 있고, 모델링 경력이 스무 해 가까이 되는 제가 2, 3년 정도 모델링을 경험한 사람에게 생각을 그대로 쏟아내서는 효과적인 소통이 될 리가 없습니다.
그래서 저는 이렇게 말했죠.
일단, 표기법은 무시하고, 중요한 내용이 모두 담겼는지만 초점을 맞춰 보죠.
돌아보니 상태도를 그리기 앞서 대상이 되는 사태의 중요한 내용을 한 장에 담아두는 일이 좋은 시작일 수 있습니다.
2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기
4. 기술 부채를 Code Smell로 관리할 수 있는가?
6. 설계 요소의 사분면
7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기
8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기
13. 설계는 변화에 대한 준비인가?