소프트웨어 커플링의 의미는 무언가?
소프트웨어의 Coupling & Cohesion
이 글은 지난 주 페북을 통한 지인 요청으로 쓰는 글이다. 또한 Kent Beck의 글에 대해 짧게 페북에 올린 내용에서 비롯한 일이다. 독자들은 배경을 이해하기 위해서 아래 캡춰를 보실 필요가 있다.
말미에 부연하겠지만 소프트웨어 공학에서 가장 중요한 개념 중 하나가 Coupling & Cohesion 이다. 업계 구루인 Kent Beck도 유사한 생각이 듯하다. 10 수년에 걸쳐 그 개념에 대해 고찰하고 글도 쓴 것을 봐서는…
변화에 따라 영향을 주는 것끼리만 커플링하라
위 그림에 등장하는 지인이 쓴 기록이다. 퀴즈 프로그램처럼 결과만 간단히 답하면 맞다. 다만, 1/4에만 해당한다고 답했다. 나머지 3/4인 뭔지 Kent Beck의 원문을 보고 주장해보겠다.
tl;dr Coupling (& later Cohesion)
먼저 원문의 아래 문구를 보자.
“Coupling” is the “how many things change” part of the quote above. If I change this element & as a result I have to also change that element, those two elements are coupled with respect to that change.
번역은 필자가 하지 않고 papago 번역을 이용한다. Coupling은 결합도라고 쓰는 곳도 있는데요. 파파고는 커플링이라 번역했다.
프로그램(혹은 소프트웨어)을 구성하는 요소(보통 코드)사에서 관계가 있는 부분 중에 한 곳을 고칠 때 다른 곳을 고쳐야 할 경우 커플링 혹은 결함이 있다고 말한다. 그런데 프로그램 하는 사람의 의도에 따라 두 곳의 문제로 그치지 않는다. 그 결합이 퍼져나가(Coupling cascade)는 경향이 있기 때문에 이 개념이 중요하게 다뤄진다. 또한, 1:1 관계로 퍼져나가는 것이 아닌지라 마치 복리나 기하급수의 형태로 복잡해질 수 있다. 이에 대해 Kent Beck은 아래와 같이 설명합니다.
If that’s as far as the changes went, coupling wouldn’t matter. Coupling cascades. Most changes are small. When the avalanche starts, tho, the changes, while initially small, compound to become enormous compared to “ordinary” changes.
avalanche(눈사태) 같은 생소한 단어가 쓰였지만 은유로는 좋다. 눈덩이처럼 커져서 인간이 판단하기 어려운 속도로 심각한 사태를 만들 수 있다는 점을 연상할 수 있다.
자! 여기까지 읽고 쓸 때 제가 느끼는 느낌은 지인의 말로 표현할 수 없다.
변화에 따라 영향을 주는 것끼리만 커플링하라
도리어 빙산의 일각처럼 표면적인 부분만 드러낸다는 느낌을 준다. 그래서 댓글을 달았고 나머지 부분 설명이 이 글의 목적이다.
출처: 구글 이미지자, 그럼 약속대로 3/4을 설명해보자.
Form Follows Fuction 공학원리
첫 번째는 1/3은 원칙(공학원리) 차원의 설명이다. 이건 커플링 자체에 대한 이야기가 아니라 설계를 고민할 때 질문을 어떻게 하는가 혹은 문제를 어떻게 바라봐야 하는가에 대한 덧붙임이다. 나는 이런 시각을 갖는 것이 올바른 설계를 하기 위해 필수라고 보기에 (즉흥적으로) 1/3 이라고 주장한다.
설명을 쉽게 하기 위해 동료의 글을 인용한다. :)
갑자기 이 원리가 왜 나오냐? 커플링과 FFF는 매우 밀접한 관련이 있지만, 나는 저자의 질문 자체에서 안티패턴을 느꼈다.
제가 만나본 대부분의 사람은 형태에 대한 내용만으로 결론을 내리려는 경향이 매우 높다. (지난 주에 멘토링한 사람들 여럿도 똑같은 안티패턴을 보여줬다.) 마치 머릿속으로 이런 목표를 가지고 대화를 하는 사람들처럼
그래서 결론이 뭡니까? 어떤 모양이 되어야 한다는 거죠?
모양을 먼저 정할 수는 없다. 모양은 항상 목적이나 기능이 결정한다. 변화에 따라 영향을 주는 요소끼리만 커플링한다는 말은 거의 사전 정의랑 비슷하다. 왜 그래야 하는지? 어느 수준까지 할 것인지? 목표가 무엇인지? 이런 질문을 던지지 않는다면 Kent Beck 의 글을 안 읽은 것과 같다.
경계를 나누는 행위와 기준은 무엇인가?
두 번째 1/3은 내가 할 수 있는 행동과 연결하는 일이다. 소프트웨어 공학을 책으로만 배우면 무용하다. 결국은 소프트웨어 구현에 활용해야 한다. 커플링을 높이고 낮추는 행위는 우리가 코딩하는 과정에서 어떤 일과 관련이 있나? 변수로 쓰이고, 어떤 연산을 할 때 하나의 함수에서 다른 함수를 부르고 하는 일들로 세밀한 단위들이 모두 후보이다.
결국 인간은 할 만한 일로 만들기 위해서 덩어리로 정의해야(혹은 나눠야) 한다. 경계를 지어야 한다. 덩어리에 대한 이름과 형태는 아주 다양하다. struct, function, method, enum, class, object, module, array, ...
단 하나의 비결을 찾는 일은 불가능하다. 설사 최고의 방법을 찾았다고 해도 사회적 활동이니 다른 사람에 의해 변한다. 자유롭게 누군가 언어를 만들고, 같은 언어에서도 패턴을 구현한 프레임워크 같은 것들을 만들고, 또 각자가 자기 스타일로 코딩할 수 있다. 소프트웨어란 어차피 상상력의 산물이라 말랑말랑하기 그지 없다.
아무튼 이때 경계를 정하고 나누는 행위를 설계(design)라고 한다.
The economic goal of software design is to balance the cost of coupling versus the cost of decoupling.
설계를 보는 관점은 다양하겠으나 Kent Beck의 글은 경제적 목적(economic goal)에 맞춰져 쓰여져 있다. 제가 오늘의 문제만 우아하게 해결하기란 글을 쓴 일이 있는데, 같은 맥락이다. 너무 깊이 들어가면 설명이 아니라 함정으로 독자를 빠뜨릴 수 있다는 생각에 정리한다.
커플링은 결국 경제성의 원칙에 따라 설계를 바라보게 하는 기준이다. 소프트웨어 업계에서 흔히 들을 수 있는 아래 개념이 연관성이 있다. 업계는 실용적인 문제를 다루니까, 공학적 개념 분류의 함정에서 벗어날 수 있다.
Lean & Agile practices
MVP(Minimum Viable Product)
Technical Debt
무엇이 경제적인가?
마지막 1/3을 설명해보자. 위에서 Coupling에 대해 아는 분들은 느닷없이 왜 MVP야? 하며 불편하실 수 있다. MVP 같은 상업적 고려는 전통적인 소프트웨어 공학의 범주도 아니고, 소프트웨어 자체의 커플링에 대한 이야기가 아니니까 충분히 불편할 수 있다.
개발자 출신 스타트업 경영자이기 때문에 두 개의 문제를 함께 보려고 노력한다. 그래야 내 직분인 좋은 사업가가 될 수도 있고, 100세 시대에 사회적 쓸모도 분명해지기 때문이다. 요약하면 커플링(이건 뭐건)도 경제적 문제로 볼 필요가 있다는 주장이다.
다시 Kent Beck의 글로 가자. 그가 경제성을 바라볼 때는 사업적 맥락을 빼고 소프트웨어 개발과 서비스(혹은 시스템) 운영에 있어 매우 실용적인 포인트만 뽑아냈다. 이것 때문에 그가 '아멘'을 외쳤을까?
@BethCodes summary focuses on safety, that is (as I understand it) when I change behavior in one way, does behavior change elsewhere in the system in an undesirable way. Do I break shit?
경제적 목표의 핵심 요소로 안전(safety)을 말한다. 우리말 단어만으로는 오해하가 쉽상인지라 papago 번역 후 설명을 해보자.
부작용이 일어나지 않는가? 라는 질문으로 바꿔도 될 듯하다. 그러한 확신이 있는 상태, 변경에 대한 영향이 명확한 상태가 안전이라고 할 수 있고, 그 반대는 불안이다. 그게 경제성과 무슨 관계지? 계속해서 비슷한 방법으로 설명해자.
Safety is a big part of the cost. Safety records the likelihood that you’ll be done paying when you think you’re done paying. When you’ve made an unsafe change, you pay much more to find, fix, & apologize to users for the times you make a mistake.
점점 실용적인 내용들이 나타난다.
화가 난 사용자를 찾아서 사과하는 시간과 사과하는 당사자를 생각해보자. 그가 코드를 수정한 개발자 본인이 아니라고 생각해보자. 그가 다친 마음과 그의 불안도 커다란 비용이고, 이걸 고려해야 안전한 수정이 된다. (이런 지난 주에 이 문제를 실제로 다뤘잖아!) 이쯤 되면 커플링을 통제해야 할 이유가 분명해진다. (소프트웨어 공학책에 나오는 뜨뜨미지근한 정의와는 다르다.)
A second part of the cost of unsafe changes are the changes you don’t even attempt because you are (rightly) afraid of the cost of mistakes. This opportunity cost can dwarf the costs of the actual mistakes.
그런 불안감은 수정을 매우 더디게 만든다. 외주 개발을 하는 대형(?) 시스템들을 보면 사실 표피(?)에 해당하는 코드만 수정하는 경우를 아주 흔하게 볼 수 있다. 어떤 이들을 이를 기술 부채 문제라고도 한다.
소프트웨어 공학 관점만으로는 아무 문제가 없어 보인다. 그러나 상업적 영역으로 나오면 문제가 커진다. 수정을 두려워하기 때문에 일상이 '고치자 vs 오래 걸린다'의 대립으로 점철된다. 회사 차원에서는 시장에서 경쟁력이 저하된다. 결국 다수의 개인(?)을 위해서 수정을 줄이기로 암묵적으로 합의를 한다. 고치자고 주장하던 사람도 문제가 너무 커지고 외로워지면 포기하기 십상이다. 워낙 복잡한 상태라 도덕적으로 문제 의식을 느끼기도 어렵고 경영자들은 자기 문제라고 생각하지 않기 때문에 시스템은 거의 수정할 수 없는 상태로 고착화 된다. 수백억, 수천억으로 진행하는 차세대 프로젝트의 씨앗은 여기서 만들어진다.
Reducing coupling reduces the number of elements changing at once & reduces the chances that you’ll miss one of the elements that need to change in sync.
그래서 결론적으로 커플링을 줄이라고 하지만 그 방법이 그렇게 간단치는 않다. 테스트 코드를 작성하고, 운영에 배포하기 전에 개발 시스템이나 스테이징에서 무언가 확인하고, 다양한 설정 파일을 만들고 등등의 일련의 수많은 업무와 유관한 문제인데... 이에 대해서는 Kent Beck의 다음 글을 풀어보며 저희가 짧은 시간에 배울 수 있는 게 있을지 기대를 해본다.
내 인생에 소프트웨어 공학이 다가온 이유
나는 대학을 졸업하고 SI 업체(S모사와 L모사 등의 대기업) 말고는 취업할 곳이 없다는 사실에 절망했다. 1990년대 말의 이야기인데, 학교 다니면서 알바를 하면서 증권사 등의 현실을 봤다. 내가 영어 교재에서 본 내용과는 거리가 멀었고, (선배) 실무자들은 실무(?)를 할 능력이 없었다. 적어도 내 기준으로는 그랬다. 덕분에 나는 조금만 일하고 큰 돈을 벌 수 있었는데, 그건 알바(땜빵)일 때 가능한 것이고, 정규직 신입이 이 현실에서 할 수 있는 일은 한심하게 설계된 실무에서 시다를 하는 것뿐이었다. 표현을 일부러 적나라하게 적는다. 당시 나의 감상에 독자들이 공감할 수 있게 하기 위함이다. 아내는 나의 이런 비하를 싫어하지만 할 수 없다. 나는 동시대인들과 공감하기 위해 아내가 싫어하는 어투를 그대로 쓰기로 한다.
암튼, 그래서 나는 대학원을 만들었다. 당연히 혼자는 아니고, 지도 교수님이 외모와 달리 열혈이였는데 BK21 사업을 추진하고 있던 모양이다. 당시 나는 (내가 보는 수준의) 대학원은 미취업자의 도피처로 여겼다. 거길 내가 왜 들어가나? 하지만, 거래는 성사되었다. 당시 내가 보던 HBR에 나오는 미국의 도전은 실전에 강한 지식정보 노동자를 키우는 교육을 만드는 일이었다. 그들은 그걸 골드칼라라고 불렀다. 나는 교수님과 커리큘럼을 함께 짜고, 강사도 내가 요구했고 교수님은 50% 정도를 그들로 채워줬다. 강사는 내가 아는 업계 최강자로 짜여졌고, 그렇게 시효가 2년으로 끝난 IT전문대학원을 만들고 다녔다. (지금은 망해서 사라졌다.)
Coupling과 Cohesion, 어떻게 접했는가?
그렇게 해도 만든 대학원에서는 논문을 쓰는 대신 실전 프로젝트 50%와 이론 50%를 공부했다. 보통 대학원보다 수업을 더 많이 들으면서 동시에 프로젝트를 해야 했다. 굉장히 유익한 비중이었다고 본다. 물론, 의도대로 수행한 사람은 우리 랩에서 5% 정도였다. 대충 따라간 사람은 20% 이고, 80%는 사실상 낙오자에 가깝지만, 졸업 논문이 없기 때문에 수료에 문제는 없었던 것으로 기억한다.
그렇게 나름 열심히 배운 소프트웨어 공학 중에서 (실전을 빼고) 이론적인 면에서 가장 중요한 내용을 키워드만 나열하면 1번은 Integrity 이고 두 번째가 Coupling & Cohesion, 세 번째가 Scalability 이다. 졸업후 나는 운 좋게 들어간 IT컨설팅 회사 두 곳에서 15년 정도 일하면서 아키텍트 역할을 주로 했는데, 그때 나의 펀더먼털을 구성한 이론을 저 세 개념으로 요약할 수도 있다. 소셜 스킬을 빼면 정말 저 개념 셋일 지도 모른다. 그 정도로 Coupling & Cohesion 개념은 중요하다.
