한빛출판네트워크

2022년, 제가 소프트웨어 설계에 관심이 많다는 사실을 알고 있는 두 명의 지인이 번갈아 찾아와 ‘어떻게 소프트웨어 설계를 하느냐’고 노하우를 물었습니다. 그때는 명확한 답을 하기가 어려웠습니다. 한때 설계 방법에 대해 치열하게 고민한 일이 있지만, 지금은 현장에서 상황마다 다르게, 필요한 만큼 활용하고 있어서 하나의 노하우나 형식을 정해두고 있지 않았기 때문입니다.

그런데 지인들의 질문을 계기로 제가 익숙하게 해 오던 일에 대해 다시 돌아볼 수 있었습니다. 20년 이상 소프트웨어 관련한 일을 하는 동안 소프트웨어를 만드는 프로그래밍 기술은 상당히 발전했습니다. 하지만 소프트웨어 설계 쪽에서는 눈에 띄는 발전을 찾아내기가 어렵다는 생각이 듭니다. 왜 그런지 아직은 잘 모르겠습니다. 다만 설계를 활용하는 사람의 관점이 바뀌어야 한다는 것만은 확신합니다. 

결론부터 말하면, ‘어떻게 설계하느냐’ 하는 방법론은 개인의 선호에 달린 문제일 뿐입니다. 그래서 어떤 설계 방법론이 옳은지를 따지기보다, 현장에서 설계 내용을 실현하기 위해 서로 소통하는 데 가장 효과적인 방법을 찾아야 합니다.

이 글은 제가 20년여년 동안 소프트웨어 설계를 공부하고, 적용해 보면서 갖게 된 믿음에 관한 글입니다. 한때 설계에 빠져 공부했고, 잘못된 믿음도 가져봤습니다. 하지만 언어와 실력이 다른 분들과 일하며 설계를 했던 경험을 비롯해 다양한 학습이 저를 설계에 관한 다른 관점으로 이끌었습니다. 

이제 저는 모든 상황에서 모든 문제를 해결해 주는 모범답안 같은 완벽한 해법은 없으며, 설계는 정교한 의사소통을 돕는 도구로 활용될 때만 의미가 있다고 믿습니다. 또한 설계라는 행위에는 함께 일하는 팀과 고객을 설득하는 과정 전반이 포함되기 때문에, 결국 올바르고 완벽한 설계 문서란 게 존재할 수 없다고 믿습니다. 이 글에선 이런 이야기를 하고자 합니다.

이 글을 읽고 최소한 여러분은 설계에 대해 기대하지 말아야 할 것들에 대한 제 견해를 알 수 있을 것입니다. 조금 욕심을 부리자면, 적어도 한 사람 정도는 제 글을 읽고 행동에 변화가 생기는 분이 나타날 수도 있다는 기대를 갖고 글을 씁니다.

설계가 할 수 없는 것

설계는 코딩을 대신해 줄 수 없다

90년대 후반에 UML^{Unified Modeling Language}이라는 일종의 설계 기법과 관련 기술이 우리나라에도 보급되었습니다. 직업 개발자의 길을 막 나섰던 저는 밤샘으로 점철된 일상을 바꿀 수 있는 마법이 될 수 있을까 기대했습니다. 그래서, 학부 졸업을 하기도 전에 지도교수님과 함께 대학원 프로그램 만드는 일을 기획하는 등 소프트웨어 공학에 푹 빠져서 공부를 했고, 그 후 운 좋게 실무에서 활용해 왔습니다.

하지만, 그 제약은 분명했습니다. 2007년 그 한계에 대해서는 ‘월간마소’에 ‘다시 꺼낸 양날의 검 UML 2부 - UML의 전략적 활용’이라는 제목으로 기고한 바 있습니다. UML을 익히고 활용하는 것만으로도 굉장한 무언가가 나올 거라 기대했던 자신을 돌아보며, UML 자체가 아니라 이를 활용하는 사람이 중요하다는 생각을 담은 글이었습니다. 실무에서 다년간 겪은 시행착오에 대한 기록이기도 했습니다.

이후에도 저의 문제 의식은 그대로였습니다. 2018년 개발자 행사에서 ‘소프트웨어를 모르는 대한민국 기업의 위기’라는 제목으로 기조연설을 하면서, 스프링 프레임워크를 만든 로드 존슨^{Rod Johnson}의 글을 인용하여 UML 그리고 파생기술인 MDA가 코드 작성을 대신해 줄 수 있다는 2000년 초의 잘못된 믿음을 지적했습니다.

지금은 당연한 이야기가 되었지만, UML이 널리 보급되던 시절에는 다이어그램 형태로 설계만 잘하면 코드가 만들어진다는 주장과 이를 실현하려는 야심 찬 (주로 미국의) 제품들이 시장에 퍼져 있었습니다. 하지만 이런 주장과 반대되는 놀라운 소식이 2017년 6월에 등장합니다. 

마이크로소프트가 코드를 개발자가 스스로 보관하는 서비스 ‘깃허브’를 한화 8조 원에 인수한 것입니다. 이 사건은 업계 전문가들이 보기에 코딩과 코딩을 둘러싼 협업의 가치가 입증된 사건으로 평가되었습니다.

소통 없이 완벽한 설계 문서란 없다

‘Big Design Up Front’라는 말이 있습니다. 개발을 해 보지 않고 과다하게 설계하는 일을 부르는 영어 표현인데, 외주 개발을 하는 분야에서는 오랜 관행이었습니다. 또 하나의 관행은 외주 개발을 주도하는 수행사에서 잔뼈가 굵은 분들이 프로젝트 중간에 대금 지급을 하기 위한 근거로 설계 문서를 사용하는 방식입니다. 이 또한 아직까지 널리 쓰이는 관행입니다. 대금 지급과 수금이라는 사업 관리 절차가 앞서 말한 ‘Big Design Up Front’를 강제하게 만듭니다. 

저는 ‘폭포수 방식 설계는 기술 부채를 남긴다’는 제목의 글에서 관행을 유지하는 대가로 치러지는 사회적 낭비에 대해 설명하기도 했습니다.

특히 외주 개발 계약을 이행하는 과정에서 설계를 먼저 한 뒤 개발하는 경우가 흔하게 있는데, 이 경우에는 대부분 이후에 실제로 개발할 때 설계를 다시 해야 합니다. 계약을 위한 소통과 개발을 위한 소통은 내용이 같을 수가 없습니다. ‘설계’를 대금 지급의 기준으로 삼는 일 자체가 유효하지 않지만, 흔히 통용되는 관행이니 적어도 그 부작용에 대해서는 충분한 숙지가 필요합니다.

자, 지금까지 이 글을 따라오셨다면 적어도 여러분은 설계에 대해서 기대하지 말아야 할 두 가지를 알게 되셨습니다. 다시 요약해 보죠. 먼저 설계는 코딩을 대신해 주지 않습니다. 두 번째로 기술적 가정을 검증하지 않고, 당장 개발을 위한 소통에 쓰이지 않는 문서나 그림 형태로 설계하는 일은 지양해야 합니다. 그림을 그리지 말라는 말이 아닙니다. 설계 결과물은 소통의 일부로, 함께 대화하는 맥락(다른 말로 도메인이라고 함) 안에서만 힘을 갖는다는 말입니다.

앞에서 언급한 바대로 현장에서 함께 일하는 사람들의 소통 과정에서 설계도 만들어집니다. 함께 일하는 이들이 사용하는 도구와 전문 지식의 배경에 따라 표기법과 같은 설계 방법을 결정하는 일이 효과적일 이유가 여기에 있습니다.

그럼, 이번에는 설계가 무엇을 해줄 수 있는지 여러분께 사례를 통해 말씀드리겠습니다.

언어와 실력이 다른 이들과 함께 설계하기

2017년 저는 중국의 소프트웨어 개발 회사에서 일하던 시절, 꼭 필요한 소통으로 이어진 설계를 경험한 적이 있습니다.

당시 조선족 개발자 1명과 중국인 개발자 2명이 함께 코드를 개발하는 중에 풀리지 않는 문제가 있다면서 그들이 저를 찾아왔습니다. UML 표기법을 배우고 활용하고 싶어 하던 조선족 개발자가 UML 순차도를 그려서 먼저 저에게 문제를 설명하려고 했죠.

그림을 보며 문제에 대해 이야기를 나누는데, 전혀 맥이 짚이지 않았습니다. 그래서 저는 그림을 그린 개발자에게 두 사람의 코드를 보고 그린 것인지 확인했습니다. 그리고 그에게 ‘추측해서 그리면 안 된다’는 말을 덧붙였습니다. 제 말을 듣고 그가 실제로 확인해 보니, 동료들은 코드를 설계와 다르게 작성했습니다. 그는 동료들에게 자신이 짠 모듈 (그림에서 Colleagues) 사용법을 설명했으니, 자신이 기대한 대로 코드를 짰을 것으로 짐작하고 그린 것이었습니다.

우리는 함께 모여 그림과 실제 코드를 대조해서 보면서 서로 이해가 같아질 때까지 회의를 했습니다. 제가 중국어 소통을 할 수 없던 탓에 통역하는 시간이 더해져 회의 시간은 길어졌지만, 꼭 필요한 소통이었습니다. 회의실 한쪽의 프로젝터에서는 우리가 나누는 이야기의 바탕이 되는 코드가 보이고 있었습니다. 나중에 회고를 통해 조선족 동료는 이 경험에서 ‘소통의 중요성에 대해 다시 한번 느꼈다’고 고백했습니다.

한편, 저는 당시 중국인 동료 한 명의 눈에서 의구심이 지워지지 않는다는 사실에 집중했습니다. 그래서 그에게 최선을 다해서 제가 의도한 바를 설명하려고 노력했습니다. 화이트보드에 그림을 그리고 또 그림이 의미하는 바를 코드와 연결하며 중국인 동료의 눈빛이 바뀌길 바라는 마음으로 설명을 계속했습니다.

노력 끝에, 마침내 동료의 입에서 ‘하울러(好嘞)’라는 말이 나오고 표정이 밝아졌습니다. 그리고 그가 중국어로 다음과 같이 말했습니다.

“마이크로서비스^{MicroMicroserviceservice}를 구현할 때는 막연히 작게 잘라야 한다고 생각해서, 스스로 shipping-demo를 나누면서도 왜 이렇게 해야 하는지 의문이 들었는데, 이제야 이해했다”

당시 저는 마이크로서비스 아키텍처로 서비스를 구성하던 시기였는데, 그런 방식이 낯설었던 그는 왜 프로그램을 그렇게 짜야 하는지 의구심이 들어 그것을 풀고자 했던 것입니다. (이때의 생생한 고민과 경험담은 ‘설계란 무엇인가?’ 라는 글에 담았습니다.)

설득 또한 설계의 일부다

중국인 동료의 눈빛에서 의구심이 사라질 때, 저는 ‘됐다’고 생각했고 비로소 마음이 놓였습니다. 그런데 무엇이 되었다고 판단했던 것일까요? 첫 논의 이후에 그 중국인 개발자가 반복해서 저를 찾아와 코드를 봐달라고 요청했습니다. 그는 지속적으로 제 의도에 맞춰 프로그램을 개선하고 있다는 사실을 알리고 싶었는지 아니면 확인받고 싶었는지 알 수 없지만 한 가지는 분명했습니다. 그는 저와 팀워크를 맞추고 싶었던 것입니다. 사교적이지 않다고 알려진 중국인 개발자가 낯선 외국인 동료에게 그렇게 적극적으로 자신의 결과를 어필하는 장면이 꽤나 인상적이었습니다.

한때 저도 빠르게 정답을 내놓고 다른 사람들이 저를 따라주기를 바랐던 적도 있었습니다. 하지만 당시에는 수십 명의 개발자가 함께 일하는 환경에서 마이크로서비스 아키텍처를 적용해야 했습니다. 그렇기 때문에 설계라는 행위 안에는 프로그램을 변경해야 하는 동료들이 납득하게 하는 일이 포함되어야 했습니다. 저는 조급한 마음을 다스리는 중이었죠.

한편 그 친구들은 제 뜻을 따라주고 싶어도 제가 외국인 임원이라 말 걸기가 쉽지 않았을뿐더러 일해 온 배경과 경험이 달라 사용하는 어휘에 대한 이해도 달랐습니다. 하지만 그 친구가 그렇게 다가와 준 덕분에 저의 관점에서가 아니라 그 직원들의 눈높이에서 소통할 수 있었던 것 같습니다.

설계란 것이 스포츠 팀에서 조직력을 만들어내는 일과 비슷하다는 사실을 중국의 동료들이 일깨워준 것입니다. 그리고 그 경험은 아마도 저에게 결과를 어필해 오던 그 개발자가 설계에 대해 경직된 사고를 벗어날 수 있게 한 촉매제가 되지 않았을까 생각하게 됩니다.

그리고, UML 순차도를 그려 저에게 문제를 설명한 개발자는 설계에 대해서 다른 깨달음을 얻었을 듯합니다. 아마 그는 동료의 입장에서 문제를 바라볼 필요성을 깨닫지 않았을까 추측합니다. 저는 개발팀 안에서 서로의 코드를 함께 살펴보는 일은 매우 중요하다 생각합니다. 여기서 제가 말하는 코드 검토는 옳고 그름을 따지기 위함이 아니라 서로의 입장을 코드를 통해 정교하게 소통하는 일에 대한 것입니다.

이때의 경험 덕분인지 2017년에 쓴 글 ‘설계란 무엇인가 II’ 에서 인용했던 문구와, 그에 관련된 벤다이어그램 하나가 아직도 기억에 남습니다.

engineering (as an activity) does not have “correct” solutions to problems

이 문장의 저자는 자신의 글에서 다음과 같은 그림을 담은 글을 인용합니다.

벤 다이어그램 출처: https://mcfunley.com/choose-boring-technology

그림처럼 문제를 바라보는 다양한 시각이 기술적 해법에 영향을 미칩니다. 각자 자신이 처한 입장과 경험에 따라 다른 판단을 할 수 있습니다. 게다가 사전에 예측할 수 없는 일이 많습니다. 사후에 벌어지는 일로 그 일이 적절한 조치였는지 혹은 그렇지 않은지에 관한 근거를 찾을 수는 있지만, 결정은 항상 먼저 내려야 합니다.

그렇다면, 우리는 설계를 바라볼 때 ‘내가 생각하기에 올바른 해법’이 결과물이 아니란 점을 꼭 알아야 합니다. 동료들, 사용자, 돈을 지불하는 고객이나 스폰서 따위와 같이 소프트웨어가 만드는 변화에 영향을 받는 사람들의 입장에서 옳은 방향을 추구해야 합니다. 그런데 상황은 시시각각 변화합니다. 마찬가지로 사람들의 입장 역시 바뀔 수 있습니다. 섣불리 옳고 그름을 따지기 전에 우리는 서로 다른 입장을 이해하고 팀으로 의사결정 하는 방법을 익혀야 합니다.

지금까지의 이야기를 아래의 두 가지 요점으로 정리할 수 있습니다. 이 내용이 더 궁금하신 분은 제가 2017년에 작성한 ‘설계란 무엇인가 III’ 를 읽어보시길 바랍니다.

● 설계는 코딩하기 직전에 무엇을 어떻게 짜야 할지 떠오르지 않을 때, 어떻게 해야 할지 떠오를 정도까지만 한다.
● 리팩터링을 통해 지속 설계 ^{Continuous Design}를 한다.

자, 이제 여러분이 설계를 떠올리실 때, 그것이 ‘정답’을 만드는 일이 아니란 점을 분명히 기억하시길 기대합니다. 그리고, 설계는 일종의 의사소통 방식으로, 팀으로서 나아가야 할 방향에 대한 정교한 소통을 돕기 위한 일이란 사실에 익숙해지지 않았을까 기대합니다.

위 글은 『켄트 벡의 Tidy First?』에 수록된 옮긴이 특별 부록에서 내용을 발췌하여 정리한 내용입니다.

익스트림 프로그래밍의 창시자이자 소프트웨어 패턴의 선구자, 켄트 벡의 수십 년 경험과 통찰이 담겨 있는 ‘경험적 소프트웨어 설계’ 노하우와 한국어판에만 실린 별책부록이 궁금하신 분들은 『켄트 벡의 Tidy First?』를 확인해 보세요.