설계: 생각을 ‘차려’ 물질로 만드는 힘
동료들 사이에서 코드를 설명하는 과정에서 그려진 그림을 보고 모델링에 대한 이야기를 하고 싶은 충동이 들었습니다. 왜 하필 이 그림을 예시로 삼고 싶었을까요?
당장 생각이 떠오르지 않았습니다. 다행히 며칠이 지난 후에 그 이유를 알게 된 듯합니다. 꽤 오래전 일이지만, UML 사용이 대규모 프로젝트에서 유행처럼 번지던 시절이 있었습니다. 당시 저는 프로젝트에 참여하여 분석가 혹은 설계자 역할을 하는 분들에게 UML 표기법과 모델링 방법을 가르치기도 하고, 코칭이나 검토를 하는 일을 했습니다. 그런데 몇 번을 반복하고 나자 '과연 이런 방식이 도움이 되는지'[1] 회의적이 되었습니다.
지금 와서 생각해 보면, PM은 프로젝트 비용의 30%라는 거액을 받아야 하고, 이를 위한 장치가 설계 검토인 경우가 많았습니다. 흔히 말하는 폭포수(waterfall) 모델의 프로젝트 진행의 구조적 문제로 볼 수도 있고, 애자일 선언에서 '계약 협상보다는 고객 협업을 우선'해야 한다고 강조한 배경으로 볼 수도 있습니다.
이렇게 연결해 보니 제가 쓴 <소프트웨어 ‘설계’의 정의는 변해야 한다>에서 주장했던 말인 '설계 형식과 표기보다 소통이 먼저다' 라는 말이 떠오릅니다.
동료의 그림을 보며 그런 제 생각과 부합하는 시도라고 여기고, 여기서 뭔가 배울 수 있다는 촉이 발동한 것이 아닐까요?
다시 그림으로 돌아가 봅니다. 아래 그림은 개발에 참여한 동료가 새로 참여해야 하는 동료에게 전체적인 프로그램 구성을 설명하기 위해 자발적으로 그린 그림입니다. 아마도 모델러의 1차 목표는 가장 빠르게 핵심이 되는 지식을 전달하는 일이었을 것이라고 짐작할 수 있습니다.
그림을 보는데 여러 가지 생각이 들었습니다. 예를 들면 다음과 같은 생각들이죠.
code와 business로 구분한 것은 왜일까?
어떤 내용은 영어고 어떤 내용은 한글이네
code 하위분류는 각각 무엇과 대응이 될까?
그리고 나도 모르게 <성공적 대화를 돕는 그림>이 떠오르고, 그린 사람과 보는 사람이 합의하는 내용으로 바로 가려는 효율 중심의 습관이 제 안에 있다는 사실도 깨달았습니다.
하지만, 다행스럽게도 의사소통에 대한 다년간의 훈련 덕분에 관성을 멈추고 단계를 밟는 힘이 생겼습니다. 결과적 효용성을 따지거나 판단하기 전에 사실부터 확인할 필요가 있습니다. 적어도 모델러는 프로그램 전체를 그와 같은 형상으로 인식하고 있다는 사실 말이죠.
<어떻게 원하는 것을 얻는가>에서 배운 태도 즉, 나의 다양한 믿음들로 상대의 생각을 평가하는 습관을 버리고 상대의 믿음과 나의 믿음을 각각 존중하고 원하는 것을 얻는 데 집중하는 태도를 '협상론적 세계관'이라고 부릅니다. 이에 따르면, 다음과 같은 전략 항목이 있습니다.
상대의 머릿속 그림을 그려라.
상대방이 따르는 표준을 활용하라.
앞서 제가 던졌던 질문을 이와 같이 상대의 머릿속 그림과 상대의 표준을 따져 봐야 알 수 있거나 따져 보고 난 후에 헤아리는 편이 좋겠다는 생각이 들었습니다.
<뇌과학으로 배우는 대화라는 작용>에서 다룬 내용인데, 많은 사람들이 사실과 감정과 의미를 섞어서 대화하는 경우가 많다고 합니다. 우리는 서로 처한 위치나 당시 기분이나 취향에 따라 사실조차 다르게 받아들일 수 있습니다. 그래서, 서로 어떻게 인식했는지 따져 보고, 그 과정에서 서로 다른 의미 부여 즉, 가치관도 확인할 수 있습니다. 그 과정에서 감정도 작용하게 되는데, 이를 구분할 수 있어야 제대로 소통이 가능하다 하겠습니다.
이 글을 처음 시작할 때는 '모델링은 왜 하는가?'를 제목으로 염두했습니다. 그런데, 다른 사람이 모델링한 결과에 대해서는 그의 의도와 바탕을 물어야 하는데, 경험적으로 이를 간과하기 쉽다는 생각이 들어 이를 강조한 제목으로 바꾸고 이를 풀어 보았습니다.
주석
[1] 2007년 월간마소에 기고한 <다시 꺼낸 양날의 검 UML 2부 - UML의 전략적 활용>이라는 기사가 인터넷에 공유되어 있습니다.