느슨한 설계시점 결합을 안하면 무엇이 문제인가?
MSA 기술과 적용 연구 6
<느슨한 설계시점 결합이란 무슨 말인가?> 편을 쓰고 나니 더 찜찜합니다. 쉬운 말로 설명하려면 아직 먼 여정인 듯합니다. 그래도 계속 해봅니다.
느슨한 설계시점 결합을 간과하면 어떻게 될까??
지난 글에서 '설계 시점이 아닌 것'을 물었던 것처럼 또 다시 질문할 수 있습니다.
느슨한 설계 시점 결합이 아닌 것은 무엇인가?
머리가 아프군요. 어디서부터 어떻게 설명해야 할지 가늠할 수 없습니다. 한때 좋아하던 스프링(Spring)이라는 프레임워크에 녹아있는 기업용 프로그램 작성할 때 필요한 자바 진영의 모든 노하우가 떠오릅니다. 그걸 소프트웨어 공학 원리와 연결해서 설명한다면 얼마나 긴 시간이 걸릴 것이며, 몇 사람이나 그걸 이해할 수 있을까요?
그래서 질문을 바꿔봅니다.
느슨한 설계시점 결함을 간과하면 어떻게 될까?
이 질문은 Chris Richardson의 글에서 답을 찾을 수 있습니다. 그는 느슨한 설계시점 결합(design-time coupling)을 간과하면 위험이 닥친다고 경고합니다.
If you neglect design-time coupling, you risk creating a distributed monolith, which combines the complexity of the microservice architecture with the friction of a monolith. While such an architectural disaster might result in conference talk about why microservices are a bad idea, it could create an existential crisis for your business and is best avoided.
위험은 아키텍처 관점에서는 재앙(disaster)이라고 합니다. 안타까운 사실이지만 이러한 재앙을 맞이하고 있는 대한민국 기업은 상당히 많을 듯합니다. 이 글이 앞으로 벌어질 재앙을 막는데 조금이라고 기여했으면 하는 마음입니다.
데이터베이스 하나로 분산 프로그래밍을 하는 일이 최악
분산된 모노리스(distributed monolith)라는 표현 역시 (영어로는) 훌륭한 듯합니다만, 우리 말로 바꿔보면 생소합니다. 완벽한 의미전달을 포기하고, 우리 현실에서 가장 비슷한 시스템 모양을 찾아보면 저는 통DB구조라는 말을 쓰고 싶습니다. (실제로 자주 써왔구요.)
통DB구조라는 말은 결코 우아한 말은 아니지만 짧은 표현으로 모노리식의 부정적 특징을 표현하기에 안성 맞춤입니다. 모노리식 자체가 부정적일 수는 없기에 더 효과적입니다. 모노리식이라는 말을 아예 안 쓰면 '모노리식 vs. 마이크로서비스' 이분법에 따른 오해도 피할 수 있습니다. 바라 보기에 따라 모노리식은 시스템 전체가 하나의 표준으로 이뤄진 시스템으로 볼 수도 있습니다. 모노리식이란 말 자체는 가치 평가가 배제된 표현이죠. MSA 유행에 따라 각종 책이나 설명 자료에서 '모노리식'을 설명할 때 부정적 면만 설명하니 개발자들 사이에서도 오해가 많습니다.
이 정도 하고, 통DB 구조에 대해 설명합니다. 통DB 구조는 다수의 응용 프로그램이 하나의 경직된 데이터베이스와 함께 구동하는 형태를 말합니다. 경직된이라는 형용사가 모호한데, 개발자가 프로그램 수정할 때 데이터베이스를 마음대로 고치지 못한다면 경직되었다고 할 수 있습니다. 프로그램 수정과 테이블 수정이 어긋나기 시작하면 어쩔 수 없이 따로따로 수정을 합니다. 프로그램을 화면이나 출력물을 보고 검증을 할 수 있지만, 레코드 검증은 어려워서 쓰이지도 않는 데이터나 중복 데이터가 쌓여갑니다. 노후한 시스템의 경우는 DB링크 같은 식의 임기응변을 하고 CDC 솔루션 데이터 복제를 쓰는 경우도 바람직하다고 보긴 어렵습니다.
DB Link가 사용이 바로 재앙을 부르는 모노리스
기업용 프로그램의 경우 아직도 DB링크를 써서 테이블 사이에 연관관계를 복제해서 쓰는 경우를 볼 수 있습니다. 이런 시스템은 Chris Richardson이 말한 분산된 모노리스(distributed monolith)에 속한다고 할 수 있습니다. 시스템을 수정해야 하는 개발자 입장에서는 재앙이죠. 이런 조직에 속한 분들은 왜 개발자를 구할 수 없냐고 묻습니다. 정말 너무나도 소프트웨어를 모르는 질문이라는 사실을 알아야 합니다. 그 문제를 해결하지 못하면 영원히 개발자를 구할 수 없을 가능성이 매우 높기 때문입니다.
왜 그럴까요? 엄연히 예전부터 써오던 기술인데, 갑자기 제가 궤변을 말하는 걸까요? 사실, 개발팀이 외주가 아니라면 DB Link를 사용하는게 큰 문제가 없습니다. 제가 아는 유명 인터넷 서비스 기업에서도 CDC 기술을 쓴다는 사실을 확인했지만 재앙이 벌어질 것이라고 생각하지 않습니다. 그들의 직업 일상에서 누군가는 문제를 발견하고, 개발자와 의사결정할 수 있는 사람이 어떤 형태로든 소통할 수 있다면 회사 운영 과정에서 언젠가는 문제를 고칠 수 있습니다. 문제가 되는 경우는 바로 외주 개발에 의존하는 경우입니다.
외주 개발에 의존하는 경우 시스템 구성요소(프로그램, 데이터 구조)에서 아무도 모르는 부분이 생겨납니다. 그 부분이 분리되어 있지 않으면, 자꾸만 다른 프로그램 수정 결과에 영향을 미칩니다. 모르는 내용이기 때문에 누가 선뜻 나설 수도 없습니다. 사실 그 부분이 정확히 어딘지 알 수만 있어도 고칠 수 있을텐데, 진짜 문제는 어디를 모르는지 모르는 경우가 대부분이죠.
시스템을 소유한 기업과 개발자의 소속이 다른 경우, 나아가 시스템을 소유한 기업에 IT담당자가 있지만 개발자와 소통이 어려운 경우라면 재앙이 실제로 벌어집니다. IT담당자 입장에서는 개발자가 떠나는데 딱히 잡을 수도 없고 대안이 존재하지 않는다는 사실이 바로 재앙입니다. 반대로 그곳에 있던 개발자는 알 수 없는 문제가 그에게 쏟아지기 때문에 재앙이죠. 개발자가 그곳을 떠나가는 본질적인 이유입니다.
재앙 = 수정 불가능한 시스템
자, 이쯤에서 재앙의 의미를 다시 돌아볼 필요가 있습니다. 무엇이 재앙인가요? Chris Richardson의 의도는 무엇인지 모르지만, 저는 시스템을 더 이상 수정할 수 없을 때라고 생각합니다. 개발자가 수정을 못하겠다고 하거나 수정을 했지만 오류 투성이라 도저히 쓸 수가 없거나 수정할 개발자가 사라지는 식으로 재앙이 발생하죠. 재앙에 대처하기 위해 많은 기업들이 전면 차세대라는 이름으로 전면 재개발을 합니다. 하지만, 근본적인 해결책이 될 수 없습니다. 사람이 만드는 시스템인데 새로 만든다고 해서 그 문제가 사라질까요?
