💡 ‘그땐 정답이었으나 지금은 아니다’의 마음을 가지고 이 긁을 읽어야 한다.
💡 해당 글은 누구나 공감할 수 있도록 실제 회사의 사례가 아닌 가상의 사례로 작성한 것입니다.
💡 MSA가 만능이라는 글이 아닙니다.
인트로
10년 동안 거대한 용이 돼버린 우리의 서비스, 과연 이대로 괜찮은가? 고민해볼 필요가 있다.
우리가 가진 문제
높은 기능 결합도(coupling), 낮은 기능 응집도(cohesion)
결합도란 소프트웨어 코드의 한 요소가 다른 것과 얼마나 강력하게 연결되어 있는지, 얼마나 의존적인지 나타내는 정도이다.
응집도란 소프트웨어의 한 요소가 해당 기능을 수행하기 위해 얼마만큼 연관된 책임과 아이디어가 뭉쳐있는지 나타내는 정도이다.
현재 서비스를 구성하는 요소 중 일부는 높은 기능 결합도와 낮은 기능 응집도를 가지고 있다.
(A에 관련된 기능을 수정했는데 검사 결과 B 기능이 동작하지 않는다던지… C영역에 있어야 할 기능이 D에 구현돼있다던지…)
이러한 상황에서 새로운 기능을 추가하고 유지보수하는 것은 아주 어려운 뿐더러 하고 싶지 않은 작업이다.
(단, 딱 한 발자국, 기능의 동작 여부만 본다면 아주 쉬운 작업이 될 수도 있다.)
결론적으로 서비스의 모든 기능을 알고 있지 않으면 개발을 하기 어려운 환경, 즉 진입 장벽이 높은 개발 환경을 만들었다.
사용자 서비스의 성장으로 인한 데이터/트래픽 관리 & 장애 대응 부담
2020년 코로나 대유행과 함께 트래픽이 2019년도 대비 약 3배 증가했고 2021년엔 2020년도 대비 2배 증가했다.
트래픽이 크게 증가하였으나 사용자 서비스 시스템 설계가 대량의 데이터 & 트래픽에 대한 대응이 용이하게 구성되지 않았기 때문에 늘어난 트래픽을 버티지 못 했고 이로 인해 크고 작은 장애가 발생했다.
당시엔 기술을 활용한 적극적인 대응보단 인력 기반의 보수적인 대응을 하던 때라 사람이 일일이 대응했다.
이러한 특징은 높은 운영 및 개발 피로도의 원인으로 작용했다.
스케쥴링 기반 서비스 운영 & 낮은 운영 가시성
스케쥴링 기반의 서비스 운영은 장, 단점이 존재한다.
단점은 각 행위가 하나의 트랜잭션으로 관리되지 않기 때문에 수행 상태를 확인하기 어렵다는 것
또 데이터베이스 내 상태 값 (Y, N, F 등 어떠한 프로세스의 수행 상태를 나타내는 값)을 사용해 프로세스를 관리하나 값이 추가될 수록 정합성을 유지하기 어렵다는 것이 있다.
운영 가시성은 현재 서비스의 기능 또는 프로세스 수행 상태가 시각적으로 보이는 정도를 의미하는데 운영 가시성이 낮다는 것은 정말 크리티컬한 문제다.
어느 서버에서 어떠한 프로세스가 수행 중인지 모르는 상태, 장애가 발생할 경우 수많은 서버를 샅샅이 뒤져야 하는 상태를 야기할 수 있다. (물론 실제로 야기했다.)
이러한 특징은 높은 운영 및 개발 피로도, 높은 진입 장벽의 원인으로 작용했다.
필요성
진입 장벽이 높은 개발 환경 없애기
높은 기능 결합도, 낮은 기능 응집도라는 특징을 가지고 있는 사용자 서비스는 손을 대고 싶지 않다.
내가 작업한 한 줄의 코드가 해당 기능에만 영향을 미치는 것이 아니라 사용자 서비스 전체의 장애로 이어질 수 있다는 사실은 개발자에게 정말 무서운 사실이다.
그러나 반대로 생각하면 낮은 기능 결합도, 높은 기능 응집도를 가지는 코드는 신입이 오더라도 쉽고 빠르게 이해할 수 있고, 영향을 미칠 수 있는 범위가 한정돼있기 때문에 무섭더라도 도전은 할 수 있다는 뜻이다.
기술 부채 해결
진입 장벽이 높은 개발 환경 없애기와 비슷한 맥락의 항목이다.
기술 부채란 현 시점에서 더 오래 소요될 수 있는 더 나은 접근 방식을 사용하는 대신 쉬운 솔루션을 채택함으로 발생되는 추가적인 재작업의 비용을 반영하는 행위를 말한다.
쉽게 이야기하면 기술적으로 해결해야 할 문제를 뒤로 미루고 비즈니스 문제를 해결하는 시점을 당기는 것이다.
A : 이 문제는 이러 기술/기능을 적용하면 쉽게 해결할 수 있어요!
B : 괜찮아! 우린 새로운 쳐내느라 바쁘거든!이러한 기술 부채가 반복해서 쌓이다 보면 아래와 같은 현상을 야기할 수 있다.
- 유지 보수 시간이 오래 걸린다.
- 유지 보수 비용이 증가한다.
- 오랫동안 시스템을 담당하고 있는 사람 또는 조직이 아니면 다를 수 없는 소프트웨어가 된다.
- 기술 부채는 주변을 부채화시킨다.
- 비즈니스 경쟁력을 해친다.
- 기술 부채가 지나치게 커지면, 개발자들은 포기 상태가 된다.
- 자신이 거대한 블랙 박스를 다루고 있다는 생각에 새로운 시도를 할 엄두를 내지 못 한다.사업 속도의 가속화 대응 & 용이한 사용자의 요구 사항 대응
새로운 사업이라고 하면 여러 개발 방법이 있겠으나 기존 시스템 + 새로운 기능 추가로 진행하는 경우가 있다.
이와 유사하게 사용자의 요구 사항 대응은 새로운 기능 추가 또는 기존 기능 개선으로 진행하는 경우가 있다.
이 또한 높은 기능 결합도, 낮은 기능 응집도라는 특징 때문에 매우 조심스럽게 진행하게 된다.
조심스럽게 한다는 것은 낮은 생산 속도, 높은 개발 부담을 포함하고 있다.(웃긴 얘기지만 아무리 조심스럽게 진행해도 장애/오류는 발생한다.)
목적 & 목표
문제 / 필요성에서 언급한 내용이 다시 언급될 수 있다.
개발 진입 장벽 낮추기
높은 기능 결합도, 낮은 기능 응집도를 갖고 있는 거대한 소스 코드를 수정하기 위해선 막대한 도메인 지식이 필요하다. 신입이 혼자 수정하기 거의 불가능하다는 뜻이다.
하지만 이를 기능 단위 서비스로 분리하여 필요한 도메인 지식의 수준을 낮추고 소스 코드 수정이 영향을 미칠 수 범위를 좁혀 신입도 수정/개선/추가할 수 있는 사용자 서비스 개발 환경을 만들고자 한다.
조직원 구조와 아키텍처의 일체화
개발 조직에는 모든 커뮤니케이션의 창구가 도메인 지식이 많은 사람에게만 집중되는 현상이 있다.
그 이유는 그 시스템을 그 사람 밖에 모르기 때문이다. 이는 개인 업무 부하는 물론 시스템 고착화라는 결과를 야기할 수 있다.
이러한 업무 부하와 시스템 고착화를 해결하기 위해 조직원 구조와 아키텍처의 일체화가 필요하다.
설명하자면 어떠한 기능/모듈의 담당자가 생기고 기능/모듈에 대한 모든 요청은 담당자가 처리할 수 있는 환경을 만들고자 한다.
사용자 서비스 경량화
이전까지는 특정 데이터의 분리, 기능 위임 등의 작업이 필요하지 않았으나 지금은 서비스의 발전에 대응하기 어려운 구조, 기술적 한계 등에 부딪힌 상태이다.
그러한 원인 중 하나는 모든 책임이 사용자 서비스에 있다는 것이다.
사용자 서비스는 오류를 핸들링하는 것이 아니라 성공/실패 여부로 프로세스를 핸들링하는 것이 임무이나 내부 시스템에서 오류가 발생할 경우 사용자 서비스에서 이를 핸들링하고 있다는 것이다.
(오해 마시라, 그것이 잘못됐다는 것은 아니다. 다만 미래 방향성에 어긋난다는 이야기다.)
따라서 사용자 서비스를 기반으로 무엇이라도 하려면 사용자 서비스에서 굳이 하지 않아도 되는 기능을 기능 단위 서비스로 분리하는 것이라는 필요하다.
이것이 표현이 사용자 서비스 경량화의 해석이 될 거 같다.
서비스 운영 가시화
스케쥴링 기반의 시스템에서 어떠한 프로세스가 수행 중인지 모르는 상태, 장애가 발생할 경우 수많은 서버를 샅샅이 뒤져야 하는 상태를 해결하기 위해
이벤트 기반 시스템으로 전환, 모니터링 & 로그 분석 시스템 구축, 애플리케이션 & 서버 운용 도구 (컨테이너 & 오케스트레이션) 도입으로 서비스 운영 가시화를 이루고자 한다.
MSA가 완료된다면 어떤 모습일까?
매뉴얼과 가이드만 있으면 누구나 사용자 서비스/기능 단위 서비스를 개발할 수 있는 개발 환경이 만들어 질 것
현재 모놀리식의 프로젝트가 마이크로 서비스로 변한다면 레거시를 다루기 위해 필요한 지식에 비해 필요한 도메인 지식의 양이 줄어들고 영향 범위도 줄어들 것이다.
기능 단위 서비스 개발에 필요한 지식은 매뉴얼/가이드만으로 습득 가능한 환경이 될 것이다.
결론적으로 신입도 성과 내기 좋은 환경, 신입도 서비스에 변화를 일으킬 수 있는 환경으로 변할 것이다.
소스 코드를 다루는 업무의 난이도가 대폭 하락 & 각종 자동화 환경이 만들어 질 것
복잡하고 거대한 하나의 소스 코드에서 작고 간단한 다수의 소스 코드로 변하면서 코드를 다루는 업무의 난이도가 대폭 하락할 것이다.
업무 난이도 하락에 따른 여러 긍정적인 현상이 있으나 그 중 몇 가지 예시를 작성해보겠다.
- 배포 & 서버 관리 등 단순 반복 작업은 소스 코드로 대체돼 자동화될 것
- 누구나 특정 분야에 대한 체계를 만들 수 있을 것
- 누구나 다양한 도전을 할 수 있을 것
- 누구나 결과물을 만들 수 있고 영향을 미치는 것을 눈으로 볼 수 있을 것
조직원 구조 / 시스템 아키텍처와 유사한 의사소통 관계가 정착될 것
지금까진 사용자 서비스 등의 단위로 묶이는 영역의 담당자를 통해 의사소통을 했다면 앞으론 특정 영역의 담당자에게 직접 이야기할 수 있는 의사소통 관계가 될 것이다.
예를 들어 사용자 서비스 기능 중 결제에 대한 개선이 필요하다면 현재는 [요청 → 사용자 서비스 총괄 개발자 → 사용자 서비스 개발자] 의 흐름으로 전달됐으나
앞으론 [요청 → 결제 파트 개발 담당자]으로 변할 것이다.
(참고로 의사소통과 의사결정은 서로 다른 이야기이다.)
잘 할 수 있는 영역을 더 잘 할 수 있는 환경과 함께 각 영역의 전문가가 탄생할 것
마이크로 서비스화가 진행될수록 기능 단위 서비스가 많아져 담당자가 생길 것이고 자신의 영역을 깊게 연구할 수 있는 환경이 만들어 질 것이다.
사업 속도 가속화 & 늘어나는 사용자의 요구 사항에 신속하게 대응이 가능한 환경이 만들어 질 것
개발 난이도가 낮아지면서 자연스럽게 사업 속도 가속화 & 늘어나는 사용자의 요구 사항에 신속하게 대응이 가능한 환경으로 변할 것이다.
적절한 표현인지 모르겠으나 보수적인 개발에서 열려있는 개발 문화로 변할 것이라는 의미다.
('신속하게'라는 단어 앞에는 '정확하고'라는 표현이 생략돼있다. (어떤 일을 해결하는 가장 빠른 방법은 정확하게 가는 것이다.))
마음가짐
개발, 사업 측면에서 당장 효과를 보기는 어려우나 장기적으로는 큰 효과를 볼 수 있을 것 (투자의 개념)
마이크로 서비스화라는 것이 당장 무엇이 좋아지는지 알고 또 눈에 띄게 개선되기는 어렵다.
개발 외부에서 볼 땐 '어차피 만들어 놓은 기능 똑같이 만드는 거 아니야?', '뗀다고 고객이 뭐 좋아할까?' 라는 생각을 할 수 있다.
개발 내부에서 볼 땐 '애플리케이션, 서버가 많아지고 복잡해 지는 거 같은데... 할 일만 많아지는 거 아니야?' 라는 생각을 할 수 있다.
모두 맞는 말이다. 과도기다. 똑같은 기능을 만드는 것이고 애플리케이션과 서버가 많아지고 관리 포인트가 늘어난다.
과도기가 힘든 것은 당연하다.
그러나 현재가 편하면 미래가 불편한 것이 소프트웨어 세계라고 생각한다.
그렇기 때문에 미리 문제들을 해결하여 지금 고통을 나눠서 받고 미래에 받을 고통을 줄이는 최선의 방법이다.
미래를 보고 앞으로 가보자.
