설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
설계: 생각을 ‘차려’ 물질로 만드는 힘
<모델링 과정의 효용성과 모델링 결과의 쓰임새>를 읽고 설계에 관심이 많은 yeTi 님이 카톡으로 값진 피드백을 주었습니다.
제 입장에서는 모델링이라는 개념을 적당히 잘 설명하신 글로 와닿았습니다. 한편으로 모델링이 문서화라는 것과 개념이 연결되는 특성이 있다고 생각하는데요. 여기까지 확장해 보면 문서화된 모델링 자료는 해당 시점의 생각의 스냅샷으로 보는 것이 자연스럽게 느껴집니다.
여기서 제가 받은 영감 중에서 공유할 가치가 있다고 느끼는 내용을 담아 글로 씁니다.
폭포수 방식 설계는 기술 부채를 남긴다
먼저 저는 yeTi 님에게 카톡 답변으로 이렇게 대답했습니다.
yeTi 님은 문서화가 강요(?)되던 환경에서도 경험을 쌓은 것으로 알고 있어서… 그런 식으로 다가올 수 있겠네요
이러한 추정은 yeTi 님이 쓴 <나에게 설계란?>에 바탕을 두고 있습니다.
2012년 개발이라는 활동을 하면서 설계라는 활동을 시작하게 되었습니다. 당시에 설계는 검수를 받기 위한 산출물을 작성하는 활동이었고 개발을 시작하는 시점에는 어느 정도 참고는 했지만 시간이 지남에 따라 설계라는 문서는 실용성이 떨어지는 것을 느꼈습니다.
한편, 실용성이 떨어진다는 판단에 대해서도 나름대로 잘 풀어냈다는 생각이 들었습니다. 그 근거는 yeTi 님이 쓴 <설계의 목적과 검수하는 문화>입니다. 이 글을 다시 따라가 보면 제가 쓴 <폭포수 방식 설계는 기술 부채를 남긴다>는 안타까운 사실을 담은 불편할 수 있는 글을 몇 번이나 읽었다는 내용이 나옵니다.
아마 공감할 수 있는 경험이 있다는 의미겠죠.
공교롭게도 글을 쓰는 시점을 기준으로 이틀 전에 대기업 외주 개발에 참여하고 있는 후배가 전화로 아직도 이 같은 환경에서 일하고 있음을 알리는 푸념을 전한 일이 있습니다.
아니, 지난번에도 자기가 설계만 하고 개발을 맡겨서 내가 전부 다시 했는데...
O 치우는 것도 아니고, 이번에도 똑같이 시켜서 못하겠다고 했어.
실타래를 풀려면 실이 엉켜 있다는 사실을 알아차려야 한다
후배의 푸념을 듣는데, 최근에 켄트 벡의 책을 번역하며 배운 표현이 떠올랐습니다.
실타래를 풀려면 실이 엉켜 있다는 사실을 알아차려야 시작할 수 있다.
함께 일하는 사람 중에 한 사람만 문제가 있다고 생각하면 문제를 풀 수 없습니다. 해결하려면 당사자들이 문제를 함께 인식해야 합니다. 보통 이런 상황에서 당연한 사실이지만 자주 간과되는 사실이 있습니다.
바로 사람의 인식은 모두 다르다는 사실입니다. 이에 대해서는 이미 <같은 현상도 서로 다른 일로 인식할 수 있으니 차리기>에서 자세히 서술한 바 있습니다. 후배가 불평한 설계(?)를 반복 수행한 분은 듣기로는 자신의 일과 역할에 상당한 자부심을 갖고 인정받고 있는 분입니다. 그렇지만, 자신이 설계에 문제가 있다는 사실을 모르니 연속해서 같은 방식으로 노력을 했을 뿐입니다. 후배가 어려움을 토로해도 그저 불평으로 들을 뿐, 그 불평이 자신이 인정받아 왔던 설계 능력과 관련이 있다고는 생각지 못한다고 짐작할 수 있습니다.
주제가 조금 다르지만 비슷한 경험이 있습니다. 중국에서 일하던 2016년 한 개발자가 저에게 와서 중국 개발자에게 리팩터링을 하자고 했더니, '잘 돌아가는 기능을 왜 고치냐?'라고 따지면 거부했다고 하소연을 했습니다. 저는 당시 중국 개발자의 행동에 문제제기를 한다는 사실을 인지했지만 즉답을 피하고 듣기만 했습니다. 사실 일방적으로 리팩터링을 강요한다고 해서 유지되지도 않을뿐더러, 한쪽 생각이 옳고 한쪽이 잘못되었다고 생각할 문제도 아니라고 보았습니다. 코드가 정상 작동한다면 그 모양은 각자의 가치관에 따라 충분히 다른 판단을 내릴 수 있습니다.
설계의 목적은 무엇인가?
하지만, 인식과 판단이 다르다고 해도 함께 일하려면 신뢰가 필요하고, 함께 이해하기 위한 기반도 필요합니다. 그리고 코드를 함께 수정하게 될 경우는 마치 공동생활을 하듯 서로 지켜야 할 규칙과 질서가 만들어질 수밖에 없습니다.
마찬가지로 설계라는 활동 역시 함께 달성할 공동의 목표에 대한 공감이나 합의 위에서 작동합니다. 이는 각자가 개인적으로 지닌 '설계가 무엇이냐?' 혹은 '설계를 어떻게 해야 하느냐?'에 대해 갖고 있는 신념보다 더 중요한 문제입니다.
한 사람만 옳다고 여기는 방법으로 설계를 해도 좋은 경우는 혼자서 하는 설계 활동일 때뿐입니다. 흔히 설계를 말할 때는 함께 작업하는 상황이 많기 때문에 함께 바라볼 수 있는 결과를 만들어야 합니다.
이미 요즘IT에 썼던 설계 관련 글에서 '설득 또한 설계의 일부'라고 주장한 이유도 비슷한 맥락입니다.
설계나 문서나 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
이제 제가 전하려는 메시지를 분명히 할 때가 되었네요. 서두에 예를 든 Yeti님 경험이나 후배의 사례를 보면 개발자가 받아들이기 어렵거나 개발에 사용할 수 없는 수준에서 진행하는 '설계'라는 활동을 통해 어떤 결과물이 만들어집니다. 이는 보통 계약과 수금을 위한 검수를 위한 것이거나 화면 정의서를 만들면서 기능 범위를 정하고 개괄적인 범위 산정을 한 후에 개발 일정을 관리할 목적으로 수행된 경우들이 대부분입니다.
하지만, 이 내용만으로 개발을 할 수 있는 경우는 없다고 해도 과언이 아닙니다. 과거에 프로젝트 관리 체계가 잡혀 있고 성숙도가 있는 팀에서는 이를 분석이나 개념 설계 단계라고 부르며 설계 단계를 구분하기도 했습니다. 구체적인 방법을 떠나 그런 단계를 두면 최소한 개발자에게 여지를 줍니다. 그런데, 만일 이미 설계를 했다는 이유로 개발자가 스스로 문제를 풀기 위한 의사결정 시간이 부족하다고 느낀다면 불만이 쌓일 수 있고, 압박감 속에서 만든 결과물도 좋지 않을 수 있습니다. 실제로 그런 경우를 많이 보아 왔습니다.
그러니 설계라는 것을 가급적 굉장히 구체적으로 누가 누구를 위해서 무엇을 하는 일인가 생각하고, 그 생각을 팀 내에서 공유할 필요가 있다고 생각합니다. 문서화나 설계는 개발 활동에 수반하는 방법일 뿐입니다. 또한, 둘 다 모두 소통을 위한 것입니다. 그렇기 때문에 만든 사람의 방식과 생각과 형식을 읽는 사람에게 강요하면 읽히지 않는 문서나 설계 결과로 전락할 수 있습니다.
앞서 <모델링 과정의 효용성과 모델링 결과의 쓰임새>에서 살펴본 대로 전형적인 설계 활동 중에 하나인 모델링은 개발자 스스로가 생각을 정리하기 위해 하는 경우도 많습니다. 이는 예외적인 경우죠. 이와 달리 다른 사람에게 쓰일 내용이라면 저자와 독자가 서로 다른 역할, 인식과 취향을 가진 존재라는 사실을 분명히 하고 설계의 의미와 결과에 대해 구체적으로 생각해 볼 필요가 있습니다.
