지그재그가 모놀리식에서 마이크로서비스로 넘어간 과정을, 2012년 첫 서비스 구조부터 시간 순으로 되짚은 글이다. 아키텍처를 먼저 정하고 시작한 게 아니라 필요가 생길 때마다 쪼개 온 흐름이 그대로 드러난다.
핵심 포인트- 2012년 중반 첫 서비스는 웹 계획이 없어 단순 API 서버만 필요했고, Rails 같은 성숙한 프레임워크 대신 Node.js + Express 로 구성했다.
- 알파 테스트 단계에서 데이터를 보고 조작할 관리용 웹이 필요해지자 기존 서버에 관리용 API 를 얹었다.
- 2014년 외주 프로젝트에서는 관리용 웹 기능이 많아져 서버 프로세스를 분리했다. 다만 코드는 대부분 공유하고 프로세스에 따라 라우트만 다르게 설정하는 구조였다.
- 2015년 지그재그는 반대였다. 사용자용 API 는 아주 적은데 관리용 API 가 많았고, 업주용 웹까지 붙으면서 세 API 가 겹치는 부분이 없어 모델 코드만 공유하고 나머지는 완전히 분리했다.
- 이때 디렉터리를 서버·클라이언트가 아니라 **타겟별**로 구분했다(사용자용 API / 관리용 웹 / 업주용 웹).
상세 정리- 한때는 여기에 계약 관리용 웹까지 별도로 존재했다고 덧붙여, 분리가 계속 늘어난 정황을 남긴다.
- 마이크로서비스의 필요성은 설계상의 이상이 아니라 "서비스가 점점 복잡해지면서 자연스럽게" 느껴진 것으로 서술한다.
- 즉 이 글은 마이크로서비스를 권하는 글이 아니라, 어떤 압력이 쌓였을 때 그 선택지가 떠오르는지를 시간 순으로 보여주는 기록이다.
왜 읽나마이크로서비스 전환 시점을 가늠하는 팀에게, 조직과 제품이 어떻게 변했을 때 분리가 필요해지는지를 실제 궤적으로 보여준다.