[요약] Part 1. 마이크로서비스 도입 전 던져야 할 질문들

1. 마이크로서비스에 대한 위험한 오해들

많은 팀들이 명확한 근거 없이 유행처럼 아키텍처를 변경합니다. 다음의 흔한 착각들을 경계해야 합니다.

• "대기업이 하니까 우리도 해야 한다"는 착각
• 넷플릭스, 아마존 등의 기업은 "수천 명의 개발자"가 충돌 없이 동시에 코드를 배포하기 위한 '조직적 이유'로 MSA를 채택했습니다.
• 소규모 팀이나 초기 스타트업에게는 거대 기업의 솔루션이 오히려 과도한 복잡성이라는 독이 됩니다.
• "코드가 쪼개지면 개발이 쉬워진다"는 착각
• 개별 서비스의 코드는 짧아질 수 있지만, 서비스 간 네트워크 통신이 추가되면서 시스템 전체의 복잡도는 기하급수적으로 상승합니다.
• "MSA는 언제나 모놀리스보다 우월하다"는 착각
• 모든 상황에 들어맞는 완벽한 아키텍처(은탄환)는 존재하지 않으며, 팀의 규모와 비즈니스 단계에 맞는 도구를 선택하는 것이 중요합니다.

2. 잊혀진 강자, 모놀리식 아키텍처의 재발견

모놀리스(Monolith)는 낡고 버려야 할 레거시 시스템이 아닙니다. 빠른 실행이 필요한 단계에서는 최고의 무기입니다.

• 최고의 개발 및 배포 효율성
• 하나의 코드베이스, 하나의 데이터베이스로 구성되어 개발 환경 세팅이 매우 단순합니다.
• 코드 수정을 위해 여러 저장소를 넘나들 필요가 없으며, 단 한 번의 빌드로 전체 시스템을 배포할 수 있습니다.
• 통신의 안정성과 속도
• 외부 네트워크망을 타지 않고 메모리 내부에서 '함수 호출'로 통신하므로 응답이 빠르고 실패 확률이 거의 없습니다.
• 비즈니스 변화에 대한 압도적 유연성
• 초창기 비즈니스 모델이 수시로 바뀔 때, IDE의 리팩토링 도구를 활용해 전체 시스템의 구조를 쉽고 안전하게 뜯어고칠 수 있습니다.

3. 분산 시스템이 청구하는 숨겨진 비용 (고통의 시작)

서버를 물리적으로 쪼개는 순간, 개발자는 비즈니스 로직 개발보다 인프라와 에러 관리에 더 많은 에너지를 쏟아야 합니다.

• 피할 수 없는 네트워크 지연과 실패
• 함수 호출과 달리 네트워크 통신은 필연적으로 느리며, 타임아웃이나 연결 끊김 등 수많은 실패 변수가 존재합니다.
• 이를 방어하기 위한 재시도(Retry) 및 장애 대응 코드가 필수적으로 요구됩니다.
• 데이터 정합성 유지의 지옥
• 서비스별로 데이터베이스가 쪼개지기 때문에, 여러 서비스에 걸친 '단일 트랜잭션' 처리가 불가능해집니다.
• 한쪽 서비스의 저장은 성공하고 다른 쪽은 실패했을 때, 데이터를 원래대로 돌려놓는 보상(Compensating) 로직을 짜는 것은 극도로 까다롭습니다.
• 치솟는 유지보수 및 디버깅 난이도
• 사용자의 요청이 수많은 서버를 거쳐가기 때문에, 에러가 발생했을 때 어느 서버에서 문제가 시작되었는지(Trace) 추적하기가 매우 어렵습니다.

4. 도입 전 스스로에게 던져야 할 질문

만약 당신의 팀이 마이크로서비스 전환을 고민하고 있다면, 다음 질문들에 객관적으로 답해보세요.

• 현재 단일 서버의 코드가 너무 방대해서, 개발자 간의 배포 충돌이 심각하게 발생하고 있는가?
• 현재 단일 데이터베이스로는 물리적인 트래픽 한계를 도저히 극복할 수 없는가? (단순한 스케일 업으로 해결 불가능한가?)
• 분산 트랜잭션, 서비스 메시, 중앙 집중형 로그 추적 등 복잡한 분산 인프라를 운영할 인력과 역량이 충분한가?

이 질문들에 모두 "Yes"라고 대답할 수 없다면, 아직 마이크로서비스를 도입할 때가 아닙니다.