마이크로서비스

마이크로서비스란?

마이크로서비스를 도입하면 가장 먼저 달라지는 것은 코드가 아니라 배포 단위와 책임의 경계입니다. 모놀리식에서는 한 줄만 고쳐도 전체를 다시 빌드해 새벽 점검 시간에 올렸지만, 서비스가 나뉘면 각 팀이 자기 서비스를 자기 일정에 배포합니다. 장애의 범위도 달라져서 알림 서버가 죽어도 주문은 계속 받습니다. 결국 아키텍처를 바꾸는 일이라기보다 조직이 일하는 방식을 바꾸는 일에 가깝습니다.

경계를 어디서 자르느냐가 성패를 가릅니다. 실무에서는 기술 계층이 아니라 업무 도메인 단위로 자르고, 한 서비스를 팀 하나(보통 5~9명)가 끝까지 책임질 수 있는 크기로 맞춥니다. 서비스마다 데이터베이스를 따로 두는 것이 원칙이라 SQL 한 방으로 끝나던 조회가 API 호출과 이벤트 전달로 바뀌고, 즉시 일치 대신 몇 초 뒤 맞춰지는 최종 일관성을 받아들여야 합니다. 겉만 나누고 DB를 공유하면 기존 SOA나 모듈러 모놀리식과 구분되지 않습니다.

공짜가 아닙니다. 서비스가 10개를 넘어가면 컨테이너 오케스트레이션, 중앙 로그, 분산 추적, 온콜 당번 없이는 장애 원인조차 찾지 못합니다. 그래서 개발 인원이 10명 안팎이거나 배포가 월 1~2회인 조직이라면 모놀리식을 잘 나눠 쓰는 편이 훨씬 빠릅니다. 실제 전환도 한 번에 뒤엎지 않고 트래픽이 몰리거나 변경이 잦은 기능부터 하나씩 떼어내는 방식이 일반적입니다.

가장 흔한 오해는 잘게 쪼갤수록 좋다는 생각입니다. 서로를 동기 호출로 줄줄이 부르게 만들면 배포는 여전히 같이 해야 하고 장애도 그대로 번지는 분산 모놀리식이 됩니다. 주문 하나에 서비스 일곱 개가 순서대로 응답해야 하는 구조라면 각각 99.9%로 동작해도 전체 성공률은 99.3%로 내려앉고, 한 곳이 느려지는 순간 호출 대기가 쌓여 연쇄 장애가 됩니다. 나눈 만큼 운영 비용이 늘어난다는 전제를 먼저 계산하고 시작해야 합니다.