올해 2월과 3월에 썼던 두 편의 설계 관련 글이 계기가 되어서 개인 브런치에 틈이 날 때마다 생각을 기록하기 시작했습니다. 2월에 쓴 글: 소프트웨어 설계 20년 해보고 깨달은 ‘좋은 설계’의 조건3월에 쓴 글: 느슨한 결합(loosely coupled) 원칙을 활용한 소프트웨어 설계 19편의 기록을 남기면서 설계에 대한 생각을 꾸준히 하는 중에 마침 동료의 모델링 과정을 도우면서 새롭게 느끼는 점을 공유합니다. 설계도의 좋은 쓰임새는 무엇인가 개발자가 아닌 동료가 업무 프로세스를 정리하며 개발자를 돕고자 하는 상황이었습니다. 저는 그에게 모델링을 해 보라고 권했습니다. 처음 그렇게 권한 의도는 그가 업무를 구성하는 핵심 지식을 빠르게 파악하할 수 있도록 돕기 위함이었습니다. 모델링 방법으로는 상태도를 권했는데, 다른 방법을 생각할 수도 있었지만, 상호작용이 많은 시스템 특성을 고려할 때 먼저 상태도를 그리는 것이 좋다는 생각이 들어서였습니다. 다양한 요인에 의해 시스템 전반의 상태가 어떻게 바뀌는지를 아는 일은 굉장히 중요한 일이라고 여겼기 때문이죠. 물론, 목록을 만들어 기록할 수도 있겠지만 그림 형태로 그려 나가면 정보가 목적을 향해 응집되는 효과가 있습니다. 몇 차례 수정이 가해진 후에 동료의 그림은 아래와 같은 형태가 되었습니다. <출처: 작가 브런치> 그런데 동료는 이 그림을 다 그리자마자 이렇게 자문하는 것이었습니다. “이제는 뭘 해야 하지?” 저는 그가 지금까지의 성취를 간과하고 있다고 생각했습니다. 사실 그림이 단번에 그려질 수는 없습니다. 더군다나 모르는 일을 대상으로 다룰 때는 더욱 그렇죠. 수없이 질문하고 생각하는 과정에서 생소한 업무 지식을 배웁니다. 동료는 저 그림을 그리면서 논리적으로 옳고 그름을 따져 물었고, 사용자뿐 아니라 개발자를 포함한 다른 동료들과 소통을 할 수 있었습니다. 다시 말해서, 그림을 그리는 순간 거기에 이미 뜻을 다 이룬 하나의 쓰임새가 있는 것입니다. 그런데 보통은 이를 간과합니다. 개발자에게 도움을 주고 싶다는 마음이 너무 앞선 나머지 스스로 문제 정의하는 과정을 과소평가하는 경향이 있습니다. 스스로 정리되지도 않은 말을 너무나도 쉽게, 그것도 자신 있게 전달하는 사람들이 많은 현실을 고려하면, 엄밀한 도식 과정으로 무엇을 전달하고, 무엇을 전달하지 말아야 하는지를 스스로 묻고 따지는 일은 사실 굉장히 중요합니다. 아무튼 그는 상태도를 그 완성한 자체에 쓰임새가 있다고 생각하기 보다, 상태도가 개발자에게 도움을 주는 데 쓰여야 한다는 마음이 강했는지,다시 막막해졌습니다. 그림을 설계도라고 생각하면 개발자에게 전달하여 개발에 도움을 줘야 합니다. 하지만 그가 그린 그림에는 개발자가 원하는 정보가 충분하지 않아 당장의 효용성이 분명하지 않았습니다. 그리고 그의 경험 속에서는 아무리 고민해 봐도 개발자들에게 어필할 수 있는 아이디어가 나오지 않습니다. 왜냐하면, 언어를 사용한 대화는 서로 공유된 기억이 있을 때만이 성립하기 때문입니다. 다시 말해서, 개발 경험이 전무한 동료는 개발자와 교류하며 공유된 기억이 생기기 전까지는 아무리 노력해도 개발자가 원하는 것을 모르거나 공감하지 못할 가능성이 매우 높습니다. 그렇다고 개발 경험이 없다면 소프트웨어 개발에서 자신의 역할이 없다고 말하는 것은 아닙니다. 그렇다면, 이 동료처럼 개발 경험이 없는 사람이 개발에서 역할을 하려면 어떻게 해야 할까요? 이렇게 동료의 입장에서 업무 정의에 대한 고민을 하는 과정에서 하나의 단서를 얻었습니다. 소프트웨어 설계에 대해 잔뼈가 굵다고 믿었던 제 경험에서도 배우지 못하던 발상인데, 그 내용이 독자님 중에 단 한분에게라도 도움을 줄 수 있기를 바라는 마음으로 글을 씁니다. 현대적인 소프트웨어 설계, 새로운 정의가 필요하다일단, 두괄식으로 주장부터 제시하죠. 우선 저의 주장은 ‘전통적인 설계에 대한 인식을 벗어나자’는 것입니다. 소프트웨어 개발의 양상은 이미 상당히 바뀌었습니다. 소프트웨어를 원하는 고객이 돈을 들고 개발자를 찾아가 원하는 것을 만들어 달라고 하고 무작정 기다리던 시절과는 세상이 많이 바뀌었습니다. 인터넷 기업은 전통적 의미에서는 고객이어야 할 사람이 사장이 되고 개발자가 같은 회사 직원으로 일하는 경우라고 할 수도 있습니다. 앱스토어를 보면 개발자가 스스로 사업을 해서 먹고 사는 일도 가능합니다. 여기서 저는 현재의 개발 양상이 전통적인 개발 방식과 어떻게 달라졌느냐를 자세히 설명할 생각은 없습니다. 다만 과거의 전형적인 역할 구분이 별로 소용 없는 현실을 지적하는 것입니다. 그래서 저는 소프트웨어 설계를 조금 더 포괄적으로 정의할 필요성이 있다고 느낍니다. 현재 수준에서 저의 정의는 이렇습니다. “소프트웨어 설계란 배경지식이 다른 사람과 함께 힘을 합쳐서 최상의 사용자 경험과 고객 가치를 전달하기 위한 소통 활동으로, 그 과정에서 최종 구현(코딩)을 제외한 다양한 중간 산출물을 도구로 활용할 수 있습니다. 하지만, 건축업처럼 긴 시간 보편적으로 쓰인 표준이 없어서 도면 자체가 중요하지 않다는 점에 주의할 필요는 있습니다.” 즉, 위 에피소드에서 소개한 동료처럼 개발을 모르는 이들이 다른 모델링 기법을 배워 개발자가 이해할 수 있는 설계도를 그려야 하는 게 아니라, 개발 지식이 없는 사람과도 소통할 수 있는 것이라면 어떤 것이든 설계 도구로 인정해야 한다는 것입니다. 설계의 형식과 표기법이 본질은 아니다사실 동료는 도메인 스토리텔링이라는 표기법으로 소프트웨어 활용에 대해 익숙하게 묘사하고 사용자, 개발자, 디자이너 등과 협업한 일이 있습니다. <출처: 작가> 도메인 스토리텔링은 서로 다른 배경을 가진 사람들을 모아 도메인 전문가가 도메인에 관한 스토리를 전달하고 그것을 참가자들이 시각화하면서 도메인 지식을 비즈니스 소프트웨어로 변환하는 협업 모델링 기법입니다. 도메인 전문가가 도메인의 작동 방식을 이야기하면 참가자 중 한 명이 그것을 아이콘, 화살표, 텍스트 등으로 구성된 다이어그램으로 기록하는데, 그 기록을 통해 도메인 지식이 잘 전달되었는지, 참가자들이 잘 이해하고 있는지를 즉각적으로 확인할 수 있습니다. 피드백에 따라 시각화 자료를 개선하면서 서로 다른 배경을 가진 참가자들이 모두 이해할 수 있도록 돕는 방식입니다. 이 방식은 시스템 사용자와 그가 수행하는 작업 그리고 그 결과물을 비교적 자유로운 도식으로 표현할 수 있습니다. 흐름이나 상호작용을 표기할 때는 매우 훌륭합니다. 하지만 모든 경우에 적합한 것은 아니죠. 한편, 같은 도메인 스토리텔링 표기법을 쓴다고 해도 표현하는 내용에 따라 그림을 다르게 그려야 합니다. 마치 자연어를 써도 담고 있는 이야기가 제대로 전달되기 위해 대화법이 필요한 이치죠. 아래 그림은 동료가 사용자 구분에 따라 접근하는 정보가 달라지는 점을 일목요연하게 표현한 그림입니다. <출처: 작가> 요약하자면, 동료는 도메인 스토리텔링으로 표현하는 내용에 대한 활용법은 알고 있지만 상태도로 그린 내용을 활용하는 방법에 대해서는 경험이 부족했습니다. 하지만, 여기서 문제의 초점은 표기법은 아닙니다. 제 생각에는 동료는 일시적인 정리와 전달을 위해 모델링을 하는 방법만 알고 있는 듯합니다. 앞선 상태도는 UML(Unified Modeling Language)라는 형식을 따르기는 했지만, 지식을 알아나가는 과정에서 그려지는 그림은 특정한 형식이 중요하지 않을 수도 있습니다. 예를 들어 업무를 잘 아는 사람이 개발자를 만나서 설명하는 경우라면 아래 그림과 같이 서로 알 수 있는 정도로만 개념이나 흐름을 표현할 수 있습니다. <출처: 작가> 이러한 소통은 결과물을 만들어가는 중간 과정이고, 종국에는 최종 결과물로 드러나는 화면 혹은 사용자 경험을 통해 확인이 됩니다. 그림 자체는 이후에 쓰임새가 없어지기 때문에 화이트보드에 그리고 지운다 해도 아무런 문제가 되지 않죠. 사실 앞서 동료가 작성한 상태도의 첫 번째 형태도 종이에 펜으로 그린 그림이었습니다. 내가 파악한 내용이 맞는지 확인할 때부터 모델링 도구를 이용하여 번거롭게 작업할 이유는 없습니다. <출처: 작가> 설계 형식과 표기보다 소통이 먼저다물론 모델링 도구를 활용하는 이점도 있습니다. 반복해서 수정할 필요가 있는 경우에 유용합니다. 펜으로 종이에 그림을 그린 경우에는 새로운 내용을 추가하고자 할 때 기존 내용을 지울 수 없거나 종이에 복잡한 얼룩이 남을 수 있으니 소프트웨어 도구를 사용하는 것이 더 용이합니다. 특히 새로 알게 된 내용을 수정하는 과정에서, 이전 내용이 완전히 삭제되는 게 아니라 내가 배운 기록하고 확인할 수 있다는 이점도 있죠. 그럼에도 중요한 것은 형식이나 표기가 아닙니다. 개발자가 활용할 수 있도록하는 설계 형식이나 표기라는 것에 정답은 없습니다. 다만 같은 상태도라도 본인의 경험에 따라 그것을 응용하는 방식이 달라지는 것뿐입니다. 개발자와 더 많이 소통하고 여러 번 프로젝트를 진행할수록 그것은 더욱 분명해집니다. 중요한 것은 어떤 모델링 기법으로 어떤 설계도를 그리느냐가 아니라 소통이 가능하게 하는 것이죠. 간단한 표를 활용해서도 전달하고자 하는 바를 전할 수 있습니다. 다음 그림은 필자가 실제로 특정 프로젝트에서 그리고 사용했던 상태도와 관련 표입니다. 상태의 변화를 어떻게 감지할 것인지, 그리고 정상적으로 상태가 바뀌었다는 것을 어떻게 확인할 수 있는지 규정한 내용의 일부입니다. <출처: 작가> 상태도와 쌍을 이루는 표를 이용하여 개발팀에서는 테스트 케이스를 만들었습니다. 다양한 상태 변화에 대해 모두 테스트를 했는지 그리고 각각 어떻게 테스트를 할 것인지에 대한 요약 정보는 상태도와 이를 보완하는 표가 제시합니다. 물론, 실제로는 인용한 상태도 하나가 아니라 몇 가지 유형으로 나눈 여러 쌍의 상태도가 있었지만 그 부분은 이 글의 핵심과 맞지 않으므로 넘어가겠습니다. 여기서 중요한 것은 업무 흐름을 이해하기 위해 정리한 상태도가 그 목적 이외의 쓰임새를 가질 수 있다는 점입니다. 간단한 보완을 통해 협업에 활용할 수도 있는 것이죠. 저의 경우 상태도에 표를 더해 그다음 업무로 이어질 수 있도록 한 것이고요. 저에게는 있고, 동료에게는 없는 경험이 바로 이렇게 상태도를 구심점으로 사용하여 다양하게 응용해 본 경험입니다. 또한, 동료가 상태도를 그릴 때 필자의 도움이 필요했던 이유 역시 개발자 출신이 아니라 시스템 구성에 대한 감이 없기 때문입니다. 개발 초기라 시스템의 대략적인 덩어리 구분이 확연히 구현하기 전이라 아키텍처에 대한 구상이 머릿속에 있는 저와 그렇지 못한 동료 차이에 배경 지식 차이에 의해 제 도움이 일부 필요했던 것이죠. 어쨌든 상태도라는 그 형식 자체의 문제는 아닌 것입니다. 설계 방법은 각자의 팀에 맞게 만들어 간다이 글이 독자들에게 가치가 있으려면 내가 무언가 따라 해 보거나 응용할 수 있어야 한다고 생각합니다. 앞서 동료의 경험 부족도 그것을 문제로 삼을 수는 없습니다. 경험이 적은 사람이 설계 방법을 배워야만 일을 할 수 있는 것이 아니라는 의미입니다. 동료가 한 순간에 그 경험을 채울 수는 없으니 경험이 없어도 당장 실천할 수 있는 방법이 필요합니다. 이를 보편적인 상황으로 확대해 보면, 팀의 구성과 개인의 역량이 모두 다른데 어떻게 할 수 있는지 질문을 던질 수 있습니다. 가장 좋은 방법은 나부터 시작하고 확산시키는 방법입니다. 나부터 해야 한다는 점을 분명히 하고 싶습니다. 스스로 효능을 모르는 방법을 다른 사람에게 강요하는 일은 설득력을 가질 수 없습니다. 그래서 실용을 체험하고 공감할 수 있는 형태로만 확산이 가능하다고 생각합니다. 과거에 UML의 경우는 UML이라는 표준 자체를 정의하는 기관과 해당 표준을 이용한 도구를 만드는 기업들이 주도했습니다. 표준 자체의 통용이 이익에 부합하니까 그렇게 할 수 있었습니다. 그런데, 빠르게(적은 비용으로) 개발을 하고 사용자가 만족하는 인터넷 서비스를 만들거나 매출이 일어나는 제품을 만드는 팀 입장에서는 표준 자체는 부차적인 문제입니다. 그래서 설계도는 팀의 문제와 팀의 구성에 맞춰서 서서히 만들어가야 합니다. 소프트웨어 설계라는 포괄적인 활동아무튼 최근에 동료를 도운 경험은 흥미로운 자극이 되었습니다. 과거에 설계를 실무로 다뤘을 때는 개발자를 겸하거나 개발로 이어지는 설계를 담당하는 경우가 많았습니다. 그런데, 이번에는 개발자와 무관하게 업무를 파악하는 동료를 돕는 과정에 간헐적으로 참여하면서 전과 다른 입장에서 ‘설계란 무엇인가?’라는 질문을 던지게 되었습니다. 코드로 이어지는 완결되는 설계 업무가 아닌 경우에도, 그 일을 하는 사람이 스스로 ‘설계’로 인식하는지도 궁금했습니다. 그러던 차에 과거에 쓴 글에서 인용한 이미지가 생각의 길을 열어 주었습니다. 아래 그림의 저자가 그림으로 표현한 의도와 맥락은 비슷하지만 다르게 생각해 보았습니다. 그래서 애초의 이미지에 글자를 올려 조금 수정하였습니다. <출처: 작가> 소프트웨어를 만드는 일은 기본적으로 외부 세계에 대한 우리의 인식을 시스템으로 구현하는 일입니다. 그림에서 저자가 작은 구름으로 묘사한 외부 세계의 한 부분은 ‘현상’ 혹은 ‘개념’이라고 할 수 있습니다. 사실 뭐라고 불러도 결과는 같습니다. 정교한 단위로 포착하는 것이 아니기 때문입니다. 반면에 네모 상자로 그려진 시스템 내부의 구성요소는 이들에 대응해야 합니다. 구성요소를 보편적으로 기능이라고 부르는 경우가 많지만, 이 역시 정확하게 단위화 하는 경우는 드물어서, 정확하게 무엇이냐 하는 질문은 대개의 경우 그다지 중요하지는 않습니다. 그리고 그림은 단순하게 표현하려고 일대일 대응으로 그렸지만, 실제로 그렇게 하기는 어렵습니다. 총체적으로 생각하거나 필요한 개념을 모두 담아내야 사용자가 만족하게 됩니다. 그렇지 못하면 수정을 해야 하고, 제때 수정을 못하거나 수정을 해도 필요한 개념을 모두 충족하지 못하면 시스템이 버려질 수도 있습니다. 열심히 해서 시스템이 잘 작동한다고 해도 필연적으로 외부 세상을 그대로 대응시킬 수 없기 때문에 불일치가 발생합니다. 하지만, 시스템 내부적으로는 나름의 일관성을 유지하도록 통합해야 합니다. 이 때문에 시스템의 상태를 알아야 하는 경우가 발생합니다. 스스로 묻고 따지면서 기본적으로 소프트웨어는 외부 세상을 바라보는 현상적 이해를 구현한 결과란 점을 깨닫습니다. 그러고 나니 설계란 소프트웨어 구현으로 가는 과정에서의 다양한 이해와 의사결정 양상을 총체적으로 담을 수 있는 말이란 점도 확인할 수 있었습니다. 덤으로 글의 핵심 주제는 아니지만, 상태도가 필요한 본질적인 이유도 알게 되었습니다. 마치며동료를 돕는 과정이 나에게도 피드백을 합니다. 과거의 경험으로 배운 사실이 지금도 유용한지 항상 물어야 합니다. 그리고 나에게 쓸모 있었다고 해서 그에게도 도움이 될지는 확실치 않다고 생각합니다. 이런 여지를 두고 조언하고 상대의 반응을 보면 나 스스로에게도 상당한 피드백이 됩니다. 이 글은 최초에는 상태도 그리기를 돕는 과정에서 문제를 바라보았지만, 기록으로 남겨져 있던 동료의 행적과 과거 제가 썼던 설계에 대한 글이 생각을 발전시켰습니다. 그래서 설계란 결국 현실 세계의 현상을 대상으로 쓸모 있는 기능을 만들기 위해 개념을 잘 정의하고 조직화하는 과정에서 구현에 도움을 주는 다양한 활동이라는 점을 확인합니다. 글은 여기서 마무리하지만, 이렇게 배운 자극을 통해 과거의 제 경험이 지금의 상황에는 들어맞지 않는 부분도 발견했습니다. 그래서, 이후에는 앞서 썼던 두 개의 글도 이번에 받은 영감으로 다시 해석하는 기회를 만들어 보기로 했습니다. ©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
