1. 거대한 모놀리식 아키텍처, ‘루비 DB’의 시대
2015년, 배달의민족은 하루 주문량 5만 건 이하의 규모였습니다. 당시 시스템은 모놀리식 아키텍처로 구성되어 있었고, ‘루비 DB’라고 불리는 하나의 거대한 MS SQL 데이터베이스를 모든 서비스가 공유하고 있었죠. 프론트 서버, 회원, 결제, 주문 등 모든 기능이 이 루비 DB에 의존했습니다. 이 시스템에는 약 700개의 테이블과 4,000개가 넘는 스토어드 프로시저가 얽혀 있었다고 해요. 상상만 해도 어마어마한 규모죠?
이러한 모놀리식 아키텍처는 초기에는 개발과 관리가 용이하다는 장점이 있지만, 서비스가 성장하면서 치명적인 단점으로 다가왔습니다.
- 단일 장애점: 루비 DB에 문제가 생기면 모든 서비스가 멈춰버렸습니다. 예를 들어, 리뷰 테이블에 작은 문제가 생겼을 뿐인데, 데이터베이스 전체에 부하가 걸리면서 서비스가 올스톱되는 상황이 발생했죠.
- 성장 한계: 매년 주문량이 2.3배 이상 폭증하는데, 하나의 거대한 덩어리 시스템으로는 트래픽을 감당하기 어려웠습니다. CPU 사용량이 모니터링 화면에 들어오지 못할 정도로 치솟는 일도 있었다고 해요.
- 배포 및 개발의 어려움: 작은 기능을 하나 추가하거나 수정하려 해도 전체 시스템에 영향을 미칠까 봐 조심해야 했고, 배포 시간도 오래 걸렸습니다.
이런 상황 속에서 우아한형제들 개발팀은 깊은 고민에 빠졌습니다. 이대로라면 계속해서 장애가 날 테고, 이는 곧 회사의 생존 문제와 직결된다고 판단했죠. 바로 이때, 넷플릭스가 마이크로서비스를 기술적인 선택이 아닌 ‘생존’의 문제로 접근했다는 사실에 영감을 얻습니다.
2. 생존을 위한 대전환, 마이크로서비스로의 여행 시작
2016년, 배민은 시스템의 대대적인 변화를 결심합니다. 첫 번째 단계는 마이크로서비스 아키텍처의 도입과 AWS 클라우드로의 이전을 결정하는 것이었습니다. 개발 언어도 PHP에서 자바로 전환했죠. 자바는 대용량 트래픽 대응에 안정적이며, 국내에 개발 인력 수급이 용이하다는 장점이 있었기 때문입니다.
최초의 마이크로서비스: 결제 시스템 (2016)
가장 먼저 분리된 것은 결제 서비스였습니다. 이 서비스는 데이터베이스까지 완전히 독립하여 루비 DB의 영향권에서 벗어났습니다. 이제 결제 시스템에 장애가 발생해도 고객들은 전화 주문을 통해 음식을 시킬 수 있게 되었죠. 이렇게 시스템 장애가 전체 서비스로 확산되지 않고 특정 영역에 국한되는 장애 격리 효과를 경험하게 됩니다.
기적의 AWS 이전: 선착순 할인 이벤트 (2016)
2016년 7월, 배민은 선착순 치킨 할인 이벤트를 진행합니다. 마케터들의 흥미로운 이벤트였지만, 개발자들에게는 트래픽 폭탄을 의미했죠. 예상보다 몇 배나 많은 트래픽이 몰리자, 메인 페이지 서버가 마비되는 대참사가 벌어졌습니다. 이때 개발팀은 한 달로 계획했던 AWS 이전을 단 하루 만에 해내는 기적을 보여줍니다. 장비를 수백 대 증설하며 트래픽을 막아냈고, 비록 다음 날에는 주문 서버가 장애를 겪었지만, 이 경험을 통해 클라우드 인프라의 유연성과 확장성을 몸소 체감하게 되었습니다.
대장애의 시대와 전사적 공감대 (2017)
2017년, 하루 주문량 20만 건을 돌파하며 배민은 ‘대장애’의 시대에 돌입합니다. 주말 오후만 되면 긴장 속에서 모니터를 지켜봐야 했고, 시스템 장애는 단순히 개발팀만의 문제가 아니었습니다. 사장님들과 영업사원들의 고통, 그리고 치킨을 기다리던 고객들의 분노까지, 시스템 불안정성은 모두의 문제였죠. 이 시기를 거치며 ‘시스템 안정성이 가장 중요하다’는 전사적 공감대가 형성됩니다.
3. 복잡한 시스템 분리, 그리고 이벤트 기반 아키텍처의 도입
마지막 대장, 주문 시스템 분리 (2018 후반기)
배민 시스템의 심장이자 모놀리식 아키텍처의 마지막 대장이었던 주문 시스템이 드디어 분리됩니다. 주문은 결제, 포인트, 쿠폰, 정산, 중개 등 모든 서비스와 연결되어 있어 분리 난이도가 가장 높았습니다. 여기서 배민은 혁신적인 이벤트 기반 마이크로서비스 아키텍처를 도입합니다.
- 명확한 이벤트 정의: ‘주문 생성’, ‘주문 접수’, ‘배달 완료’ 등 주문의 모든 생명주기를 명확한 이벤트로 정의했습니다.
- 이벤트 발행과 구독: 주문 시스템은 단순히 이벤트를 발행하고, 리뷰, 정산, 라이더스 등 관련된 다른 시스템들은 이 이벤트를 구독하여 각자의 비즈니스 로직을 처리하는 방식입니다.
- 제로 페이로드 방식: 이벤트 메시지 자체에는 복잡한 데이터가 아닌 ‘가게 ID’ 같은 최소한의 정보만 담습니다. 필요한 데이터는 구독 시스템이 직접 API를 호출하여 가져오는 방식이죠. 이는 데이터의 일관성을 유지하고, 불필요한 데이터 전송을 줄이는 효과적인 방법입니다.
이러한 이벤트 기반 아키텍처 덕분에, 한 시스템에 장애가 발생해도 전체 서비스가 멈추지 않고, 장애가 복구되면 쌓여 있던 이벤트를 처리하여 데이터를 동기화할 수 있게 되었습니다. 이제 개발팀은 다른 시스템에 “연동해 주세요”라고 부탁할 필요 없이, 원하는 이벤트를 구독하여 새로운 기능을 쉽게 추가할 수 있게 되었죠.
CQRS 아키텍처의 완성 (2019)
마침내 배민은 시스템 전체를 CQRS(Command and Query Responsibility Segregation) 아키텍처로 완성합니다. 이는 명령(Command)과 조회(Query)를 철저히 분리하는 방식입니다.
이미지를 보면 명확히 알 수 있듯이, 배민은 안정성과 성능이라는 두 가지 목표를 위해 데이터 저장소를 이원화했습니다.
- 명령(Command) 시스템: 광고, 가게/업주 등 핵심 비즈니스 로직을 담당하는 시스템은 안정성이 가장 중요합니다. 이를 위해 관계형 데이터베이스인 **오로라 DB(Aurora DB)**를 사용했습니다.
- 조회(Query) 시스템: 가게 노출, 광고 리스팅, 검색 등 고객 접점에서 발생하는 트래픽을 처리하는 시스템은 고성능이 필수적입니다. 이들은 비즈니스 상황에 맞춰 다양한 데이터베이스를 사용했습니다.
- 가게 노출: 빠른 조회를 위해 **DynamoDB, MongoDB(NoSQL), Redis(Cache)**를 사용했습니다.
- 광고 리스팅, 검색: 검색 엔진으로는 Elasticsearch를 활용했습니다.
- 실시간 결제: 캐싱 용도로 Redis를 사용했습니다.
이러한 분리를 통해, 대용량 트래픽이 몰려와도 조회용 시스템만 부하를 받아 장애가 격리되고, 핵심 비즈니스 로직은 안정적으로 유지될 수 있게 되었습니다.
4. 배민의 마이크로서비스 여행에서 얻은 교훈과 꿀팁
배민의 마이크로서비스 아키텍처 전환은 기술적인 도전을 넘어, 조직 문화와 의사결정 방식의 변화를 이끌어낸 사례입니다. 이들의 경험을 통해 얻을 수 있는 몇 가지 중요한 교훈을 정리해 보았습니다.
FAQ: 마이크로서비스, 무조건 도입해야 하나요?
Q. 우리 회사도 무조건 마이크로서비스로 가야 할까요? A. 배민의 사례는 ‘규모의 경제’가 뒷받침되었기 때문에 성공할 수 있었습니다. 시스템 규모, 트래픽, 개발 인력 등 충분한 자원이 확보되지 않은 상황에서 섣불리 마이크로서비스 아키텍처를 도입하면 오히려 개발 비용이 10배 이상 증가할 수 있습니다. 초기 단계의 서비스는 모놀리식으로 시작하고, 성장에 맞춰 점진적으로 분리하는 것이 현명한 방법일 수 있습니다.
마이크로서비스 성공을 위한 꿀팁
- 전사적인 공감대 형성: 개발팀만의 문제가 아닌, 회사의 생존 문제라는 인식을 공유해야 합니다. 배민처럼 “시스템 안정성이 최우선”이라는 원칙을 세우는 것이 중요합니다.
- 점진적인 분리: 한 번에 모든 것을 바꾸려 하지 마세요. 결제, 주문처럼 비즈니스 도메인 단위로 하나씩 분리해 나가며 경험을 쌓는 것이 좋습니다.
- 이벤트 기반 아키텍처 고려: 복잡한 시스템 간의 의존성을 줄이고 싶다면, 이벤트 기반 아키텍처를 고민해 보세요. 시스템 간 결합도를 낮춰 장애가 확산되는 것을 막을 수 있습니다.
- 개발자와 기획자의 협업: 기술적인 결정은 서비스의 방향과 직결됩니다. 배민처럼 기획자와 개발자가 함께 문제를 해결하고 의사결정을 내리는 문화가 중요합니다.
5. 마치며: 여행의 끝이 아닌 새로운 시작
배달의민족의 마이크로서비스 여행은 2019년, 마지막 회원 인증 시스템까지 분리되면서 일단락됩니다. 이들은 거대한 모놀리식 아키텍처의 한계를 극복하고, 급격한 성장을 안정적으로 뒷받침할 수 있는 시스템을 구축했습니다.
이들의 이야기는 단순히 기술적인 성과를 넘어, ‘생존’을 위한 치열한 고민과 도전, 그리고 팀원들의 열정이 만들어낸 값진 결과입니다. 만약 지금 여러분의 시스템이 성장통을 겪고 있다면, 배민의 마이크로서비스 아키텍처 여행기를 참고하며 미래를 위한 계획을 세워보는 것은 어떨까요? 그들의 용기 있는 결정이 여러분에게도 큰 영감을 줄 것입니다.