loosely-coupled: 빠르게 재구성하는 힘
베터코드 인사이트의 시작 8편
요즘 회사 동료들 말고 가장 자주 보는 지인이 기술 부채를 다룬 나의 발표를 현장에서 직관하고, 여러 차례 피드백도 주었다. 그중에서 loosely-coupled라는 소프트웨어 설계 원칙을 조직에 대입하면 '빠르게 재구성하는 힘'으로 작용한다고 대응시킨 부분이 영감을 주었다고 강조했다.
그래서, 내 생각의 흔적도 찾아보고 응집력과 결합에 대한 사고를 한번 되짚어 보고자 글을 쓴다.
Loosely-coupled의 흔적
loosely-coupled는 대학원에서 소프트웨어 공학을 전공할 때부터 가장 좋아하던 개념이자 단어였다. 그래서인지 브런치 글에 이 단어를 쓴 글이 무려 20개나 있었다. 쭉 훑어보며 추출할만한 공통 특성이나 본질에 대한 힌트가 있는지 찾아보자.
찾아보길 잘했다는 생각이 들었다. loosely-coupled라는 원칙은 용도에 따라 매우 다양하게 응용할 수 있었다. 시간은 좀 걸리겠지만 분류해볼 가치가 있다고 느꼈다.
설계 시점 결합을 낮추기
<느슨한 설계시점 결합이란 무슨 말인가?> 편을 보면 느슨한 설계시점 결합(loose design-time coupling)을 말하고 있다. Chris Richardson의 표현에 대한 내 해석이다. 결합 성격을 나눠 설계 시점과 구현 시점에 나누어 반영하라는 의미다. Dependency Injection에도 비슷하게 적용할 수 있다. 구현 시점과 구동 시점을 나누라는 것이다. 다시 말해, 코드로는 3벌을 짠 후에 각각 다른 조건에서 돌아가거나 구동 시점에 선택할 수 있게 하라는 복잡도 관리 방안이다.
이를 조직 운영에도 반영할 수 있다! 일단, 그 이야기는 초점을 흐릴 수 있으니 다음에 다루자. 의존성이 있는 두 프로그램이 항상 결합되어 쓰이지 않는 경우라면, 설계 시점의 결합과 실행 시점의 결합을 나눠두면 코드를 고치지 않고 설정(configuration)만 바꿔서 구동하는 프로그램이 바뀔 수 있게 할 수 있다.
이는 다양한 상황에 대비할 수 있는 구조적 유연성을 확보할 수 있다.
의사소통 효과를 높이기 위해 지식 영역 나누기
<입장에 맞춰 맥락을 나눈 BoundedContext> 편은 DDD라는 설계 협업 방식에서 입장에 따라 개념들을 묶고 구분하는 단위로 BoundedContext 설명을 시도했다. 기본적으로 Eric Evans의 개념에 대한 나의 해설이고, 시점을 구분하는 용도가 아닌 주제 영역을 구분하여 느슨한 주제와 응집력을 갖는 주제로 분류하는 용도다.
공통 서비스와 인터페이스 특화된 서비스의 구분
다음은 물류 서비스 기획자도 흥미롭게 봤다 [1]는 <헤드리스 커머스와 SW 아키텍처> 편이다. 여기서 loosely-coupled 구현체는 헤드리스 아키텍처이다. 내가 아는 헤드리스 커머스의 최고 구현체는 위챗 미니 프로그램을 구동하게 하는 위챗 플랫폼이다. 스마트 스토어가 똑같은 기능을 분양해주는 것이라면 위챗은 각자 개성을 살려 전혀 다른 앱을 구현하게 허용한다. 반면에 (중국의) 제도적 제약과 충돌하지 않는 컴플라이언스 문제나 보안 문제, 사용자 UX 문제에 대해서는 공통적인 기능을 제공한다. 헤드리스 아키텍처의 환상적인 구현체가 아닐 수 없다.
<실전 마이크로서비스 아키텍처 적용> 편에서 같은 원리를 적용했지만 관심사 혹은 기능 영역 관점에서 전혀 다른 loosely-coupled 구현체로 MSA의 커넥터를 참조 모델로 다룬 일도 있다.
커넥터는 핵심적인 비즈니스 기능이 외부 제조사나 특정 제품 버전에 종속적인 부분이 있을 때 이를 느슨한 연결(loosely-coupling)을 제공하기 위한 부분이다.
유기적으로 함께 움직일 수 있는 조직력
<XP 혹은 점수와 성과와 책임 분배> 편은 전혀 다른 결로 loosely-coupled를 다룬 글이다. 조직과 개체가 공존하는 상태를 다룬 지극히 조직적인 글이다. 개성을 인정하며 의사소통으로 결합하는 그래서 느슨해질 수도 있는 조직 운영방식이다. 조직과 조직으로도 확대할 수 있는데, 이때는 위임이 분명하게 일어나고 투명한 의사소통과 공통의 비전과 달성 지표에 대한 공감이 있어야 한다. OKR 같은 것들이 이를 달성한 조직의 방식을 추상화한 것인지도 모른다.
지난 발표에서 세계 최고의 축구팀이 구현한 움직임을 예시로 들었던 loosely-coupled의 조직적 구현이다.
앞서 언급한 지인은 세미나 후에 피드백으로 이렇게 말했다.
코드는 loosely coupled 조직은 tightly coupled
즉 코드는 서로 유연하게 붙었다 떨어졌다 하는 레고처럼(클라우드 MSA)
조직은 가시성과 투명성이 확보되는 업무 환경을 기반으로 협업/의사소통/위임이 티카타카처럼 가능하도록.
일리가 있는 제안이다. 축구팀은 응집력을 구현해야 한다. 하지만, loosely coupled에 대한 나의 해석은 투명한 의사소통과 정보공개를 전제한 상황에서 위임을 강조하는 표현이기도 하다. 축구 선수 한 명 한 명의 개성과 역량을 최대한 끌어내는 것을 위임에 대응시킨 것이다. 그리고 개인이 아니라 팀들의 협업에서 각 팀에 권한을 부여하는 일의 중요성을 강조하는 표현이 loosely coupled이기도 하다.
따로 또 같이
그래서 유기적인 움직임을 다룰 때, loosely coupled라고 하면 '따로' 움직이는 '개체'를 허용하는 면을 강조하는 표현이 loosely이다. 반면 온전히 혼자가 아니기 때문에 coupled가 되는 것이다. 이를 우리말로 바꾸면 '따로 또 같이'일 수 있다.
<홀로서기와 따로 또 같이> 편에서 이를 다뤘다. 소프트웨어 이야기는 아니고 바람직한 인간관계를 배경으로 쓴 글이다. 또한, 바람직한 의사소통을 위한 그림으로 내가 고안하고 자주 인용한 것이 있다.
주석
[1] 그런데 왜 흥미롭게 봤는지 물어보지 않았다. 이 참에 올해가 가기 전에 만나서 물어봐야겠다.
지난 베터코드 인사이트의 시작 연재
3. Funnel을 마케팅 말고 engagement 분석에?
5. 기술 부채는 무엇인가?
