치킨 할인 이벤트가 배달앱을 다운시킬 수 있다

MSA, 계란과 서비스는 다른 바구니에 담자

1.
MSA(Microservice Architecture, 아주 작게 쪼갠 설계 방식)라는 구조가 있습니다. 개발자들의 용어에서 종종 등장하는데요. 말 그대로 커다란 소프트웨어 하나를 독립적인 여러 개의 작은 프로그램으로 쪼개서 운영하는 방법입니다.

2.
주로 네이버, 카카오, 배민처럼 서비스 규모가 커진 IT 기업에서 사용하는데요. 서비스가 너무 커져서 한 덩어리로 관리하기 힘들 때 "우리 이제 MSA로 가야 할 것 같아요"라는 말이 나오기 시작합니다.

3.
과거 방식인 모놀리식(Monolithic, 통으로 된 덩어리)은 '1인 기업'과 비슷합니다. 사장님 혼자서 전화도 받고 배송도 하고 회계도 하는데, 만약 사장님이 독감에 걸려 누우면 회사 전체가 멈추게 되죠. 반면 MSA는 '대기업'의 분업 시스템과 같습니다. 고객센터팀, 배송팀, 회계팀이 따로 있어서 배송팀 전원이 독감에 걸려도 고객센터는 여전히 전화를 받을 수 있는 구조입니다.

4.
국내에서 이 과정을 잘 보여주는 실제 사례가 배달의민족입니다. 2016년 이전만 해도 배민은 모든 기능이 하나로 뭉쳐진 '거대한 덩어리'였는데요. 7000원 치킨 할인 이벤트로 사람들이 몰리자 서비스 장애가 생기기도 했죠. 리뷰 이벤트로 사진 업로드가 폭증하면 리뷰 서비스뿐만 아니라 아무 상관 없는 '주문하기' 버튼까지 먹통이 되는 구조였고요. 모든 기능이 한 몸(모놀리식)이었기 때문인데요. 이후 배민은 가게 노출, 주문, 결제, 리뷰를 완전히 분리했습니다.

5.
이제 배민은 리뷰 시스템에 사람이 몰려 장애가 나도, '주문'과 '결제'는 다른 건물(서버)에서 돌아가기 때문에 전혀 지장이 없습니다. 장애가 발생해도 서비스 전체가 죽지 않고 "리뷰 서비스만 잠시 점검 중입니다"라고 대응을 할 수 있게 된 것이죠. 덩어리를 쪼개는 것만으로도 서비스 전체의 생존율을 높인 셈입니다.

6.
기획자가 회의실에서 MSA 구조를 떠올릴 때 핵심은 안내데스크 역할을 하는 API 게이트웨이(API Gateway, 서비스들의 입구)입니다. 쇼핑몰 사용자가 '구매하기'를 누르면 이 안내데스크가 주문 담당 서비스로 요청을 보내고, 주문 서비스는 다시 재고 담당 서비스에 "한우 세트 남았니?"라고 JSON 데이터({"status": "available", "count": 1} 같은 모양)를 주고받으며 소통합니다. 재고 서비스가 점검 중이라도 사용자는 여전히 상품 검색이나 장바구니 담기는 할 수 있는 게 MSA의 진짜 힘입니다.

7.
"그냥 한 번에 다 합쳐서 만들면 관리하기 편한 거 아니야?"라고 생각할 수도 있습니다. 하지만 서비스가 커질수록 그 '한 번'의 실수가 '전체 중단'이라는 부메랑으로 돌아올 수 있죠. "이 기능이 죽었을 때 다른 기능까지 같이 죽어야 하나?"를 고민해보면, 쪼개는 것은 단순히 기술적 유행이 아니라, 리스크를 분산하는 경영 전략입니다.

8.
더 자세히 알고 싶으신 분들은 '배민 MSA 여행기'라는 글을 찾아보시면 이 험난한 과정이 아주 잘 정리되어 있습니다. 우아콘에서 강연한 영상도 있고요. 카카오톡에서 가끔 내 프로필 사진은 안 바뀌는데 메시지는 잘 보내지는 상황도 바로 프로필 서비스와 메시지 서비스가 분리된 MSA의 흔적이니 한 번 유심히 관찰해 보세요.

[세 줄 이해]
- MSA는 커다란 앱을 작은 기능 단위로 쪼개서 운영하는 것이다.
- 기능 하나가 고장 나도 서비스 전체가 멈추지 않게 하기 위해 사용한다.
- 개발 속도가 빨라지고 장애 대응이 쉬워지지만, 관리해야 할 포인트는 더 늘어난다.