느슨한 설계시점 결합이란 무슨 말인가?
MSA 기술과 적용 연구 5
링크드인에서 발견한 글에 감탄하고 페이스북에 올린 내용입니다.
페이스북으로 박제된 저 순간에는 일종의 경외심마저 들었습니다. 다름 아닌 loose design-time coupling 이라는 표현을 포함한 고도의 함축적인 전달에 감탄했습니다. 혼자만 즐기지(?) 않기 위해 그의 글을 인용해 생각을 풀어낼까 합니다. 다만 그의 글을 쭉 따라가는 형식이 아니라 마이크로 서비스를 떠올릴 때 함께 고려해 볼 문제에 대해 여러분들 생각을 자극하는 것이 이 글의 목적입니다.
대강의 줄거리를 생각해두지 않으면 지극히 개인적인 감상이 될 우려가 있어 잠시 끄적끄적 한 후에 이야기 골자를 잡아봅니다. 먼저 Chris Richardson(이하 '크리스') 글에서 중요한 표현을 추출해서 그 개념을 이해하기로 하겠습니다. 그리고 나서 우리 현실에 맞춘 제 경험을 풀어 보겠습니다. 그 뒤는 독자님들 각자의 몫입니다.
loose coupling 을 이해하기
먼저 그가 MSA(microservice architecture)의 필수적 특성(essential characteristic)이라 설명한 느슨한 설계시점 결합(loose design-time coupling)부터 이해해야 합니다. 그게 뭘까요?
An essential characteristic of the microservice architecture is loose design-time coupling. In a loosely coupled architecture, changes to a service rarely require other services to be changed in lockstep. As a result, it’s easier to make changes. What’s more, teams need to spend much less time coordinating their work.
쉬운 개념은 아닌데, 마침 <소프트웨어 커플링의 의미는 무언가?>편을 써둔 것이 쓸모가 있네요. 해당 글에 다음과 같은 표현이 있습니다.
변화에 따라 영향을 주는 것끼리만 커플링하라
결합은 coupling을 우리말로 대치한 것입니다. 결합과 커플링은 같은 말입니다. 말뜻도 중요하지만, 위 문장에는 소프트웨어 공학 분야의 오랜 문제의식이 담겨 있다고 해도 과언이 아닙니다. 바로 느슨한 결합을 뜻하는 말입니다. 이쯤에서 다시 고민을 합니다. 프로그래밍 경험이 없는 분이 읽으면 결합 자체가 어떤 행위인지 감이 없기에 계속 글을 따라가기 어려울 듯합니다. 설명을 달리 해보죠.
결합은 어떻게 구현되는가?
프로그래밍을 해본 적이 없다면 결합이란 말에 대한 감각이 전혀 없을 가능성이 높습니다. 제가 결합 구현의 핵심만 아주 간결하게 설명해보겠습니다. 아래는 구글링으로 찾은 변수에 대한 개념 설명 이미지입니다.
출처: 구글 이미지프로그램에서 변수(variable)는 변하는 값을 저장하는 추상적인 저장소 개념으로 만들어집니다. 그래서 내용물은 바뀔 수 있지만 위 그림에서 상자 앞에 쓰인 글자는 바꿀 수 없습니다. 아이러니하게 변수 값은 바뀔 수 있지만, 변수 이름은 바꿀 수 없는 일이 생깁니다. :)
이제야 프로그래밍 경험이 없는 분들이 이해할 수 있는 수단이 생긴 듯합니다. 두 개의 프로그램 코드가 있다고 해보겠습니다. A와 B라고 부르죠. A에서 B의 일부를 가져다 쓰고 싶다면 코드 복사해서 가져오는 방법이 있고, 대체로 더 나은 방법은 A가 쓰고 싶은 B의 일부를 블록으로 묶은 후에 변수로 만들어서 A가 불러서 쓰는 방법이 있습니다. 불러서 쓴다고 해서 흔히 호출이라고 말합니다.
두 가지 경우의 수에 대해서 결합을 이야기할 수 있습니다. 첫 번째 방법처럼 복사를 한 경우 원래의 코드에 변경이 필요한 일이 생기면 복사를 해간 A도 해당 영역을 찾아서 수정해야 합니다. 수정하는 사람이 같은 사람이면 어렵지 않은 일이겠지만, 다른 사람이거나 심지어 다른 회사의 프로그램이라면 간단한 문제가 아닐 수 있습니다. 반면에 두 번째 방법은 변수명에 해당하는 일부 내용(구체적으로 변수명만은 아닙니다)만 고치는 식으로 영향을 줄일 수 있습니다. 이들 둘 사이에 묶여 있는 느낌을 받으실 수 있을 것입니다. 이를 지칭하는 말이 바로 결합 혹은 커플링입니다. 그리고 두 방법사이에 결합의 강도에 말할 수 있는데, 이러한 감각이 생기셨나요?
그럼, 느슨한 결합은 무엇인가?
자, 결합을 이해했습니다. 느슨한(loose)이라는 형용사가 무엇을 말하는지 조금 더 설명해봅니다. 느슨하다는 말은 비유적인 표현이기 때문에 행동으로 변환하기 위해서는 경험을 요구합니다. 개발업무에서 형용사적 표현으로 무엇을 할 수 있겠습니까? 결국, 어떤 행위의 기준을 세울 때 쓸 수 없다면 형용사적 표현은 우리의 협업과 사고를 방해할 뿐입니다. 저는 느슨한에 대한 확고한 감각이 있지만, 목적은 (자랑이 아니라) 가능한 많은 독자들의 이해이기 때문에 다시 한번 (Kent Beck에서 비롯한) 지난 번에 써둔 글을 인용합니다.
<소프트웨어 응집력(cohesion)은 무언가?>편을 보면 안전한 변경과 부작용이 없는 응집력 갖춘 코드라는 표현이 등장합니다. Kent Beck의 글을 바탕으로 하여 안전하게 수정할 수 있으려면 어떻게 해야 할까요? 결합이란 물질의 최종 상태일 뿐, 가치부여를 하는 인간을 제외하고 옳고 그름을 논할 수 없습니다. 안전하다는 표현도 가치 판단에 대한 값입니다. Kent Beck은 소프트웨어의 가치에 대해 말할 때, 경제적 가치로 좁혀서 생각하게 돕습니다. 그의 방식을 채택한다고 해도 경제적 가치를 정확하게 이해하려면 경험이 필요합니다. 여러분이 경제적 가치를 여러분의 직업 공간이나 경험속에서 이해하도록 돕기 위해 몇 가지 예를 들어보죠. 다음의 경우 우리는 소프트웨어가 경제적이지 않다고 말할 수 있습니다.
어떤 회사는 주문 관련 수정이 포함되면 꼬박 4일을 어떻게 수정할지와 부작용에 대해서 논의만 한다.
영업에서 무언가 요구하면 IT부서는 작은 것도 3개월 이후에 가능하다고 답한다.
과거에 제가 실제로 직접 보고 들은 사례인데, 결합이 비즈니스의 발목을 잡은 상태입니다. 서양에서는 기술부채라는 상당히 가치중립적인 표현을 씁니다만, 문제의 본질이 기술에 있다는 듯하여 적절한 표현이 아닌 듯도 합니다.
자, 여기까지 어느 정도 따라 오셨나요? 아리송하더라도 느낌만 아시고 정의를 하겠습니다. 다음 문장은 느슨한 결합에 대해 제가 정의한 내용입니다.
수정이 필요할 때 커다란 부담없이 고칠 수 있는 결합상태
설계시점결합 design-time coupling 이란
느슨한 결합을 이해하셨으면, 이제 설계시점 결합을 이해할 차례입니다. 결합에 시점이 있을까요? 마침 순간적으로 흥미로운 비유가 생각났습니다. 요즘은 사진을 보고 상대를 만나는 데이팅앱이 유행이라 들었습니다. 그런데 과거의 결혼 정보 서비스는 그게 아니라고 들었는데 고증은 하지 않겠습니다. 결혼정보서비스가 연회비를 받고 조건을 입력하면 그에 합당한 상대가 나온다고 가정하겠습니다.
이때 회원(결혼정보서비스 이용자)이 입력한 조건은 해당 서비스가 제대로 수행되기 위해 필수불가결한 요소입니다. 반면에 실제로 파트너로 누가 나올지는 약속한 바가 없습니다. 약속 장소에 누군가 나오기만 한다면 상대가 조건에 부합하는지만 강제됩니다.
이런 상황을 프로그래밍을 표현하는 일에서 설계시점design-time 에 대응할 수 있습니다. 설계시점에 대한 감각이 생기려면 설계시점이 아닌 것은 무엇인지 알아야 합니다. 구글링 해보니 What is the difference between run-time and design-time objects? 페이지가 있습니다. 좋네요. 설계시점의 반대는 실행시점runtime 이라고 단순화 해보죠. (다른 시점이 존재할 수 있지만, 이 글의 주제를 벗어나서 이분법을 씁니다.)
앞선 비유로 시점 개념을 대응시켜볼까요?
설계시점에는 회원은 요구할 조건을 입력한다 (조건에 맞지 않으면 만남을 갖지 않는다)
실행시점에 조건에 부합하는 파트너가 나타나면 된다
느슨한 설계시점 결합이란 무슨 말인가?
그래서 결론적으로 느슨한 설계시점 결합이란 무엇일까요? 정교한 설명은 아니지만 실행할 때 벌어질 구체적인 연관성은 최대한 자유도를 주어야 합니다. 설계할 때 다시 말해서, 프로그램을 고안할 때 반드시 연관성을 지어야 하는 것만 서로 결합하게 합니다. 결합한다는 말은 무엇인가요? 이 글을 어느 정도 따라 오셨다면 아래 두 가지 기준을 다시 스크롤해서 찾아보거나 가늠해보실 수 있기를 기대합니다.
변할 때 반드시 바뀌어야 하는 내용을 모아두기
변수 이름에 해당하는 내용은 최소로 유지하기
마음에 들지 않는 마무리인데, 일단 하고 싶은 말을 다 써두고 글을 개선하기로 합니다. 쓰기 시작하니 굉장히 중요한 내용이란 생각이 들어 읽기 어렵더라도 관련한 내용을 다 풀어놓은 후에 점진적으로 개선하는 방식을 취하려고 합니다.
