서론
이 글은 리더, 경영진, 그리고 실무 개발자들을 대상으로 합니다. MSA 전환을 고려하거나 이미 추진 중인 조직의 이해관계자들이, 전환 과정에서 발생할 수 있는 문제와 그 해결 방안을 이해하는 데 도움이 되기를 기대합니다.
마이크로서비스 아키텍처(MSA)는 현재 많은 조직에서 주니어 개발자 채용 공고에도 우대사항으로 언급될 만큼 널리 채택되고 있는 아키텍처 패턴입니다. 그러나 MSA 전환은 단순한 기술 도입 이상의 도전으로, 조직 내 모든 구성원의 협력과 상당한 노력이 필요합니다. 기술적인 변화를 성공적으로 이루기 위해서는 단순히 시스템 구조를 변경하는 것만으로는 충분하지 않습니다. 조직의 문화, 비즈니스 전략, 그리고 운영 모델 전반에 걸친 변화가 필요하며, 이러한 변화는 경영진의 확고한 의지와 실무진의 기술적 역량, 그리고 다양한 부서 간의 긴밀한 협력을 통해서만 이루어질 수 있습니다.
이 글은 MSA의 기본 개념에 대한 사전 지식이 필요하며, 기존 모놀리틱 아키텍처 기반의 대규모 시스템을 MSA로 전환하는 과정에서 발생할 수 있는 실패 요인들을 실무진과 경영진이 마주하는 기술적, 비즈니스적 난관을 중심으로 비판적으로 이야기합니다.
배경
이 글에서 등장하는 배경은 픽션입니다
회사의 기술 리더는 최신 기술 트렌드와 시스템의 확장성을 강조하며 MSA 전환을 추진했습니다. 기존의 모놀리틱 시스템은 유지보수가 어렵고 새로운 기능 추가 시 전체 애플리케이션을 재배포해야 하는 문제들이 있었습니다. 리더는 이러한 문제를 해결하고자 MSA로의 전환을 강력히 주장했고, 경영진도 이에 동의하여 전사적인 프로젝트가 시작되었습니다.
그러나 프로젝트가 진행되면서 예상치 못한 여러 난관에 직면하게 되었습니다. 각 서비스 간의 의존성 관리 문제, 복잡한 트랜잭션 관리, 그리고 전사적인 협력이 부족해지는 등의 문제가 연이어 발생했습니다. 외부 부서의 지원은 불충분했고, 각 팀은 자신의 업무에만 집중하며 협업이 원활히 이루어지지 않았습니다. 또한, 기술적인 난이도와 학습 곡선이 높아 일부 팀원들은 새로운 기술 스택에 적응하기 어려움을 겪었습니다.
경영진은 초기 계획보다 비용이 더 많이 들고 프로젝트가 지연되자 점차 불안해졌고, 이러한 불확실성은 실무진의 사기 저하로 이어졌습니다. 프로젝트 설계 전, MSA 전환 경험이 있는 SI 업체와도 계약했지만, 실제 코드 작성을 담당한 계약업체 실무진의 기술 수준이 기대에 미치지 못해 코드의 확장성과 유지보수성이 떨어지는 문제가 발생했습니다. 계약업체 실무진들은 프로덕트를 완성하는 것에만 집중했기 때문에 코드의 품질이 낮아졌고, 이는 프로젝트의 장기적인 성공 가능성을 더욱 낮추는 요인이 되었습니다. 결국, 경영진은 프로젝트 중단을 고려하기에 이르렀고, 실무진은 계속되는 업무 변화와 과도한 요구, 데드라인 압박에 지쳐 퇴사를 선택하는 사람들도 생겨났습니다.
이러한 가상의 시나리오를 바탕으로 MSA 전환에서 실패할 수 있는 다양한 요인들을 나열하고 구체적으로 어떤 상황인지 전달합니다.
MSA 한 입
마이크로서비스 아키텍처(Microservices Architecture)는 대형 애플리케이션을 여러 개의 독립적인 작은 서비스로 분리하여 관리하는 방식입니다. 각 서비스는 특정 기능을 수행하며, 독립적으로 개발, 배포, 확장이 가능합니다.
기존 모놀리틱 아키텍처에서는 모든 기능이 하나의 거대한 애플리케이션에 통합되어 있어 새로운 기능 추가나 수정 시 전체 애플리케이션을 다시 배포해야 하는 비효율성이 존재했습니다.
반면, MSA에서는 각 기능이 독립적인 서비스로 나뉘어 있어 개별적으로 개발 및 배포가 가능하여 확장성과 유지보수 측면에서 훨씬 유리합니다. 이러한 이점을 기대하며 많은 기업이 MSA를 도입하기 시작했습니다.
그러나 MSA 전환은 단순한 기술 도입을 넘어, 조직 전반의 문화적 변화를 요구하기도 합니다. 팀 단위의 자율성과 책임감 강화, 서비스 간 명확한 경계 설정(의존 분리), 배포와 모니터링의 자동화 등 다양한 요소들이 함께 고려되어야 합니다.
설계부터 잘못된다면
어? 순서 보장 안돼요?
기존 모놀리틱 아키텍처에서는 트랜잭션 관리가 비교적 단순했지만, MSA로 전환하게 되면 분산된 서비스 간 트랜잭션 관리를 위한 부담이 증가합니다. 각 서비스가 독립적으로 운영되기 때문에 기존의 일관된 트랜잭션 관리가 어려워지고, 이를 해결하기 위해 분산 트랜잭션을 위한 SAGA 패턴, 이벤트 드리븐 아키텍처 등 복잡한 설계를 도입해야 합니다.
특히, 이러한 패턴들은 실시간으로 발생하는 대규모 트래픽에 대응할 수 있도록 충분히 성숙된 상태에서 적용되어야 하며, 이는 시스템의 신뢰성과 안정성을 보장하는 데 중요한 요소로 작용합니다.
또한, 데이터 일관성 유지 역시 큰 도전 과제입니다. 모놀리틱 환경에서는 단일 데이터베이스를 사용하여 일관성을 유지하기가 상대적으로 용이했으나, MSA 환경에서는 각 서비스가 독립적인 데이터베이스를 가지므로 데이터 동기화와 일관성을 유지하기 위한 전략이 필수적입니다. 이를 해결하기 위해 데이터 이벤트 소싱이나 CQRS(Command Query Responsibility Segregation)와 같은 패턴을 적용할 수 있지만, 이러한 패턴의 적용에는 높은 기술적 이해와 경험이 요구됩니다. 더 나아가, 비즈니스에 대한 높은 이해만으로는 데이터 정합성 문제가 발생할 수 있는 리스크를 내포하고 있습니다. 기술적인 이해도가 부족할 경우 각 서비스 간 데이터 불일치나 동기화 실패로 인해 비즈니스적인 문제로 확산될 가능성도 존재합니다.
또한, MSA 전환에 필요한 다양한 스택(Redis, Kafka, k8s 등)이 어떻게 작동하는지에 대한 이해도 필수적입니다. 각각의 특성과 사용 방법을 정확히 이해하고 있어야 효과적으로 설계를 진행할 수 있기 때문이죠. 그러나 이러한 기술을 단기간에 충분히 습득하고 응용하는 것은 쉽지 않으며, 이로 인해 설계 단계에서 결함이 발생할 위험이 존재합니다.
캐시가 죽으면? 디비도 죽으면? 서버도 죽으면?
쿠버네티스도 죽으면?
또한, 오버 엔지니어링 문제도 고려해야 합니다. MSA는 각 서비스의 독립성을 보장하기 위해 다양한 Fallback 메커니즘을 도입해야 할 때가 많습니다. 예를 들어, 서버가 다운되거나, 데이터베이스가 실패하거나, 캐시가 손실될 경우, 이벤트가 유실될 경우 등 이를 대비한 여러 계층의 Fallback을 설계하게 되는데, 이러한 과정을 적정선에서 절제하지 못하면 오버 엔지니어링으로 이어질 수 있습니다. 즉, 복잡성을 무작정 높이는 것이 아니라, 비즈니스 가치와 기술적 필요성을 균형 있게 고려하여 최적의 솔루션을 도출하는 것이 중요합니다. 이러한 역량 또한 결국 MSA에 대한 깊은 이해와 연관있죠.
유관 부서가 협조를 안해준다
우리 팀도 바빠서요
지금은 어렵네요
대규모 프로젝트일수록 유관 부서의 협조는 필수적입니다.
각 부서 간 의존성이 크기 때문에, MSA 전환 과정에서 다른 부서의 적극적인 지원이 없으면 프로젝트 성공 가능성이 낮아질 수밖에 없습니다. 특히, 부서 간 의사소통의 원활함이 전환의 성패에 큰 영향을 미칩니다.
MSA 전환은 단순히 개발 부서의 문제로 그치지 않고, 운영, 보안, 인프라, 코어 등 다양한 부서와의 긴밀한 협력이 요구됩니다. 만약 이러한 부서 간의 협업이 원활하지 않을 경우, 서비스의 독립성과 자율성이 오히려 프로젝트의 발목을 잡는 요인이 될 수 있습니다.
쉽게 말해, 우리에겐 당장 필요한 정보인데, 유관 부서에서는 중요 업무가 아니어서 제공 우선순위가 낮아지는 상황말이죠. (나만 급한 상황)
특히 외부 조직의 협조를 이끌어내기 위해서는 그들에게도 동기를 부여하는 것이 중요합니다. 우리에게는 MSA 전환이 큰 성과일 수 있지만, 외부 조직에게는 그저 부가적인 업무로 인식될 수 있기 때문에 우선순위가 낮아질 가능성이 큽니다.
이를 해결하기 위해 MSA 전환을 전사적인 목표로 설정하고, 서포트하는 조직에도 혜택이 돌아가도록 설계하는 방법을 고려해야 합니다. 이러한 역할은 주로 경영진의 적극적인 개입과 지원을 통해 이루어질 수 있으며, 이를 통해 조직 전체의 협력을 이끌어내는 것이 필수적입니다.
따라서 조직 내에서 명확한 책임 분담과 협업 구조가 필요하며, 이를 위한 커뮤니케이션 도구와 절차를 마련해야 합니다.
다른 부서는 왜 공감하지 못하는가
개발자들은 MSA의 장점인 독립적 배포와 확장성을 충분히 이해할 수 있지만, 비개발 부서에서는 이러한 기술적 이점을 쉽게 공감하지 못할 수 있습니다. 특히 고객에게 가시적인 변화가 없는 상황에서는, 신규 개발이 지연되거나 기존 업무가 지체될 경우 MSA 전환이 불필요한 업무로 인식될 가능성이 큽니다. MSA로의 전환은 비개발 부서에게는 비용 증가, 일정 지연, 복잡성 증가로 느껴질 수 있으며, 이러한 부정적 인식을 변화시키기 위해서는 경영진과 비개발 부서에게 기술적 전환이 가져올 장기적인 비즈니스 가치를 명확하게 전달해야 합니다.
결국, 경영진의 지원이 필수적입니다. 경영진은 기술적 전환이 단기적인 비용 증가와 리소스 할당 문제를 수반할 수 있음을 이해하고, 이를 통해 얻을 수 있는 장기적인 비즈니스 이점에 대해 충분히 납득해야 합니다. 경영진 간에도 상호 설득이 필요하며, 특히 큰 규모의 전환일수록 전사적인 협조가 중요합니다. 이러한 협조는 경영진이 직접 이끌어내야 하며, 이를 위해서는 MSA의 도입이 조직의 비즈니스 목표 달성에 어떻게 기여할 수 있는지에 대한 명확한 비전과 구체적인 계획을 제시할 필요가 있습니다.
하지만, 말이 쉽지 타 부서의 공감을 바라는 것은 현실적으로 많이 어렵습니다.
고독한 싸움을 하는 여러분을 응원합니다.
비용 을 구체적으로 고려했는가
한 달에 5억이라고?
기존 모놀리틱 구조에서는 특정 서비스에 트래픽이 몰리더라도 전체 애플리케이션을 확장해야 했습니다. 반면, MSA는 각 서비스를 개별적으로 확장할 수 있으므로 클라우드 환경에서의 비용 효율성을 기대할 수 있습니다. 하지만 이러한 확장은 클라우드 서비스 사용에 따른 비용 관리의 복잡성을 수반합니다. (AWS 비싸요)
MSA의 특성상 각 서비스가 별도의 인프라 자원을 필요로 하게 되고, 이는 곧 클라우드 자원 사용의 증가로 이어질 수 있습니다. 이러한 비용은 각 서비스의 사용 패턴, 스케일링 요구사항, 데이터 처리량 등에 따라 크게 달라질 수 있으며, 예측이 어려운 경우도 많습니다.
또한, MSA는 각 서비스의 독립성을 보장하기 위해 여러 개의 데이터베이스와 네트워크 인프라를 필요로 하며, 이는 운영비용의 증가를 초래할 수 있습니다. 클라우드를 사용한다면 운영 비용 예측의 정확성을 높여야 하며, 온프레미스 환경도 함께 고려해야 합니다.
클라우드 비용을 정확히 예측하고 이를 경영진에게 설득하는 과정은 MSA 전환의 중요한 과제 중 하나입니다. 비용 절감이 아닌 비용 증가로 이어질 수 있는 부분을 간과한다면 경영진의 신뢰를 잃을 수 있으며, 이는 프로젝트의 중단으로 이어질 수 있습니다. 또한, Kubernetes(K8s)를 사용한다고 해서 무작정 확장하는 것은 Silver Bullet이 아닙니다. 확장 전략은 신중하게 계획되어야 합니다.
수레를 끌 힘이 있는 조직인가
MSA 전환의 성공 여부는 리더의 경험과 실무진의 기술적 역량에 크게 의존합니다. 일부 기업은 MSA 경험이 풍부한 리더를 TF 리더로 선출하고 소수의 숙련된 인원으로 TF 조직을 구성하여 성공적인 MSA 전환을 이끌어냅니다. 그러나 리더와 실무진 모두 경험이 부족하거나 외부 컨설팅에만 의존한다면 성공 가능성은 매우 낮다고 생각합니다. MSA 전환에는 기술적 지식뿐만 아니라, 팀원 간의 원활한 협력, 문제 해결을 위한 사고, 다양한 도구와 기술 스택의 이해 등 복합적인 역량이 요구되기 때문이죠.
SI와의 계약도 신중해야 합니다. 리더들이 아무리 경험이 풍부하고 솔루션 프로덕트가 많다고 해도, 실제 코드를 구현하는 실무진은 그렇지 않을 수 있거든요.
시간이 지나 계약이 종료되고 SI는 떠나고, 유지보수나 기능 확장이 어려운 대환장 파티가 열릴 수 있습니다.
실무진은 대규모 프로젝트의 트래픽 처리, 트랜잭션 관리, 배포 전략, 모니터링 등 다양한 기술적 도전 과제를 해결할 수 있는 역량을 갖춰야 하며, 이를 위한 교육과 학습도 필수적입니다. 또한, 기술적 역량 외에도 각 서비스의 비즈니스 가치를 이해하고 이를 기반으로 최적의 기술적 결정을 내릴 수 있는 비즈니스적 역량도 중요합니다. 기본적으로, 실무진의 역량을 강화하고, 내부적으로 MSA 전환을 주도할 수 있는 전문가를 양성하는 것이 필요합니다.
구현 디펜던시
아, 또 변경됐어요?
아, 또 추가됐어요?
기존 하나의 서비스를 A와 B 두 개의 서비스로 나눈 상황을 가정해 봅시다. B 서비스는 "회원이 보유한 카드 정보 조회" API를 제공해야 하지만 아직 구현되지 않았고, A 서비스는 이 정보를 필요로 합니다. 따라서 A 서비스는 B 서비스가 완성되기 전까지 모킹된 응답을 사용하게 되며, 이후 요건이 변경되면 모킹을 수정하고 A 서비스도 다시 구현해야 합니다.
이러한 의존성 문제는 서비스 간의 설계와 구현의 일관성을 유지하는 데 큰 도전 과제가 되죠. 서비스 간 의존성으로 인한 이러한 복잡성은 프로젝트 진행 속도를 크게 저하시킬 수 있으며, 서비스가 많아질수록 이러한 문제는 더 악화됩니다.
더욱이 서비스 간 의존성이 복잡해지면, 잦은 요건 변경과 의존성 문제로 인해 하나의 업무에 집중하기 어려운 환경이 조성될 수 있습니다. (안그래도 바쁜데 여기저기서 업무들이 동시다발적으로 치고 들어오는 상황을 떠올려보세요)
구현 중에도 새로운 요구사항을 반영하고, 모킹된 데이터를 실제 서비스로 변경하며 이를 조율해야 하는 등의 이슈가 발생할 수 있는거죠. 이를 해결하기 위해서는 서비스 간 명확한 역할 및 상호작용 규칙을 정의하고, 초기 설계 단계에서 잠재적인 비즈니스 변경 사항이나 미래 기능 확장 가능성을 고려하여 API 포맷을 신중하게 설정해야 합니다. 한 번 설계가 됐다면 추후에 "아 나중에 이 상품이 추가된다면?" 같은 생각은 하지 않는 것이 모두에게 행복한 길일 수 있습니다.
결국 리더는, 실무진들의 업무를 효과적으로 관리할 수 있는 체계를 구축해야 합니다. 또한, 설계 단계에서 실질적인 대안을 마련하여 변경이 필요할 때의 혼란을 줄이는 것이 중요합니다.
흔들리는 경영진, 퇴사하는 실무진
저도 실패할까 봐 무서워요
(by. 경영진)
위와 같은 이유들로.. MSA 전환 과정에서 리더는 예상치 못한 리스크에 직면할 수 있습니다. 리더의 불확실한 결정은 실무진의 불안감을 가중시키며, 이는 프로젝트의 사기 저하로 이어질 수 있습니다.
특히 MSA 전환은 초기 단계에서 비용과 복잡성이 증가할 수 있어 리더 또는 경영진이 기대한 성과를 단기간 내에 달성하기 어렵다는 점에서 불안감을 초래할 수 있죠. 이러한 상황에서 리더나 경영진이 명확한 비전과 일관된 지원을 제공하지 못한다면, 실무진은 프로젝트의 방향성에 의문을 가지게 되고, 이는 사기 저하로 이어질 수 있습니다.
(좋게 표현해서 사기저하이고 퇴사할 수도 있습니다)
경영진의 확고한 지원과 실무진의 사기 유지는 프로젝트 성공의 중요한 요소입니다. 이를 위해 경영진은 MSA 전환의 장기적 목표와 이에 따른 성과를 명확히 제시하고, 실무진이 이를 달성하기 위한 명확한 역할과 책임을 부여해야 합니다. 또한, 실무진이 기술적 도전 과제를 해결할 수 있도록 필요한 리소스와 지원을 아끼지 않아야 하며, 이를 통해 실무진의 자율성과 책임감을 고취시켜야 합니다.
결론
MSA 전환은 많은 장점을 제공하지만, 이를 성공적으로 이루기 위해서는 기술적 역량, 조직 내 협력, 명확한 비즈니스 목표 설정 등이 필수적입니다. 충분한 준비와 경험이 없다면 MSA 전환은 실패할 가능성이 높습니다.
실무진의 기술적 역량 강화뿐 아니라, 리더나 경영진의 명확한 지원, 부서 간 협력 강화가 필수적으로 뒷받침되어야 합니다.
또한, 기술적 도전 과제를 해결하기 위한 체계적인 계획 수립, 각 부서 간의 원활한 의사소통, 비용에 대한 명확한 이해와 관리 등 여러 요소들이 종합적으로 작용해야 합니다.
즉, 단순히 기술적 전환을 넘어, 조직 문화와 운영 방식 전반에 걸친 변화를 수반해야 합니다. 성공적인 MSA 전환을 위해서는 조직 내 모든 구성원이 그 가치를 이해하고, 이를 달성하기 위해 함께 노력하는 환경이 조성되어야 할 것입니다.
지금도 어디선가 MSA 전환에 힘쓰고 있는 모든 실무진과 리더들을 응원합니다.
'Tech > Server' 카테고리의 다른 글
| 서버는 어떻게 늘려야할까? (2) | 2021.12.19 |
|---|
인프런 지식공유자로 활동하고 있으며 MSA 전환이 취미입니다. 개발과 관련된 다양한 정보를 몰입감있게 전달합니다.
