pile·
아키텍처·카카오 스타일 (지그재그)카카오 스타일 (지그재그)·

크로키의 스택 - 마이크로서비스

지그재그가 모놀리식에서 마이크로서비스로 넘어간 과정을, 2012년 첫 서비스 구조부터 시간 순으로 되짚은 글이다. 아키텍처를 먼저 정하고 시작한 게 아니라 필요가 생길 때마다 쪼개 온 흐름이 그대로 드러난다.

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

이 글과 비슷한

  1. 아키텍처·aws-architectureAWS Architecture·

    일관성이 새로운 지연이다: 데이터 레이어에서의 AI

    AI 에이전트가 데이터베이스 레이어에서 겪는 데이터 정합성 문제를 다룬다. 비동기 복제 지연(replication lag)으로 stale 데이터를 읽은 에이전트가 잘못된 판단을 내리는 "조용한 독"을 AWS 서비스 기반 세 가지 아키텍처 패턴으로 해결하는 방법을 제시한다. "빠르지만 틀린 답이 약간 느리지만 맞는 답보다 비싸다"는 주장 아래, 데이터베이스 아키텍처를 AI 신뢰성의 기반으로 재정의한다.

    요약 이어보기
    #ai-agent#data-consistency#aurora+2
  2. 아키텍처·flexflex·

    사람도 에이전트도, 덜 읽을수록 더 잘 고칩니다

    flex 팀이 코드베이스의 모듈 경계 설계가 AI 에이전트의 코드 탐색 효율에 미치는 영향을 실측한 글이다. 193개 에이전트 작업 로그를 분석하고, 잘 나뉜 모듈과 뭉친 모듈을 비교한 결과 — 도메인이 물리 모듈로 분리된 저장소에서 에이전트가 불필요한 파일을 덜 읽고 목표 코드에 더 집중했다. 사람도 에이전트도 컨텍스트 한도가 있어, 무관 코드를 덜 읽을수록 수리 성공률이 높다는 것이 핵심 결론이다.

    요약 이어보기
    #llm-agent#context-window#modular-architecture+1
  3. 아키텍처·aws-architectureAWS Architecture·

    데이터 거주 요건을 충족하는 재해 복구 전략

    데이터 거주(data residency) 규정을 지키면서 재해 복구(DR)를 구현해야 하는 조직을 위해 AWS가 세 가지 전략 프레임워크를 제시한다. 금융, 의료, 공공 부문처럼 지리적 데이터 보관 의무가 있는 환경에서도 복구 목표(RTO/RPO)를 달성할 수 있는 아키텍처 선택지를 비교한다.

    요약 이어보기
    #multi-cloud#compliance#disaster-recovery+2