설계서가 아니라 의사소통
도메인 스토리텔링 연구 No. 4
대학을 졸업하던 시절 우리나라는 소프트웨어 불모지였다. 전산실에 들어가면 프로그래밍을 안하거나 하면프로그래밍을 서른 다섯이면 은퇴해야 한다는 말이 정설처럼 돌았다. 돌아보면 그들의 미신은 현실이 아니었다. 아무튼 나는 그런 현실을 타개하려고 소프트웨어 공학과 UML을 공부했다. 그리고 사회 초년에 UML 강의를 하고 모델링 하는 방법을 나보다 나이 많은 이들에게 가르치는 일로 가득찬 적이 있었다.
설계는 소프트웨어 개발 협업의 구심점
덕분에 나는 소프트웨어 개발이 전혀 생소한 조직과 일하면서도 설계를 하고, 이를 설명하는 일에 매우 익숙해져 있다. 이와 같이 한 사람이 설계를 끌어갈 경우는 그가 협업의 구심점이 되는 경우가 많다.
이 경우는 프로그래머(개발자와 구분없이 혼용해서 사용함)들이 생각하는 전형적인 설계와는 의미가 조금 다르다. 프로그래머는 자신이 개발할 내용에 부합할 경우만 설계로 취급하는 경향이 있다. 반면에 프로그래밍 경험이 없고, 개발 프로젝트가 낯선 사람들은 그렇게 대화할 수 없다. 따라서, 소프트웨어 개발이 생소한 조직에서는 굉장히 포괄적인 대화 방식이 필요하다. 이때, 설계가 그 역할을 담당하기 쉽다.
벽에 붙은 메모는 복제를 낳는다
다년간 두 곳의 조직에서 활용해서 소득을 본 일이 있다. 바로 벽에 그릴 수 있는 소재의 무언가를 붙여두는 일이다. 내가 누군가와 대화할 일이 생기면, 메모를 하여 시각화를 해둔다. 도처에 그렇게 쓰여진 내용은 훌륭한 본보기가 되고 머지않아 밈(meme)으로 복제되었다. 아래는 (나의 필체가 아니기에) 그 증거다.
2013년경 인도 아키텍트와 함께 일한 적이 있다. 둘은 애자일 이야기를 할 때마다 죽이 잘 맞았다. 어느날 그가 나에게 설명을 하면서 벽에 그린 다이어그램을 핸드폰 사진을 찍으며 자신은 이렇게 (캐주얼하게) 설계하기를 좋아한다고 말했다. 나는 그렇게 찍은 다음에 다시 그려서 나누냐고 말했더니. 왜 그런 중복작업을 하느냐며 그건 애자일하지 않다고 말했다.
그렇다 굳이 재작업하여 예쁘게 포장할 이유는 없다. 결국 내용 전달을 위해 눈에 보여야 한다. 그렇게 되면 해당 내용뿐 아니라 자주 보며 따라하는 부수효과가 생긴다. 언젠가 소프트웨어와는 거리가 멀게 살아오신 분이 기부 물품을 담는 박스는 뜯어 중요한 규칙을 써둔 것을 볼 때 나는 애자일 역설을 하던 인도 친구가 또 생각났다.
설계서가 아니라 의사소통
물론, 박스에 글씨를 쓰신 분은 애자일 전문가는 아니다. 그럼에도 불구하고 내가 애자일을 떠올린 이유는 본질적인 가치를 여건에 맞게 활용하는 기민함때문이다.
시간을 거슬러 약 20년 전으로 돌아가보자. 나는 대기업 출신의 소프트웨어 설계를 담당한 분들께 UML로 모델링 하는 법을 강의하고는 했다. 당시 고구마 먹듯 너무다 답답했던 일은 사람들이 배운만큼 설계서를 그린 후에, 새로 배운 사실을 발견하면 절대로 자신이 만든 모델에 반영하지 않는다는 사실이었다. 그림은 그냥 그릴 뿐이었다. 나는 도무지 납득할 수 없었지만, 몇 년 후에 그 이유를 알았다. 그렇게 그림을 그린 분들은 설계서만 남겨두고 프로젝트를 떠났다. 그리고 하청업체 성격의 개발회사 개발자들이 다시 돌아왔다. 공식적으로는 설계가 끝났으니 개발만 하면 된다는 터무니없는 소리와 함께 그들의 일을 시작되었다.
설계서는 함께 대화하는 맥락(다른 말로 도메인이라고 함)안에서만 힘을 갖는다.
따라서 프로젝트가 정교하게 설계되었고, 전문가들이 참여하는 경우가 아니라면 설계서 자체는 효용가치가 매우 낮다. 설계 결과로 그림이나 표를 이용하면 모호한 대화가 한결 명확하진다. 설계는 의사소통을 위한 활용이 되어야 한다.
지난 도메인 스토리텔링 연구
3. 도메인이 무엇인가요?
