크로키의 스택 - Thrift

카카오스타일(당시 크로키닷컴)이 2016년 마이크로서비스로 전환하면서 서비스 간 통신 프로토콜로 Apache Thrift를 선택한 이유와 1년 넘게 사용하면서 겪은 문제점, 그리고 GraphQL로 이전한 배경을 설명한다. REST API 대신 RPC/직렬화 프레임워크를 선택하는 기술 결정 과정의 생생한 기록이다.

핵심 포인트 - 마이크로서비스 통신은 한번 정하면 바꾸기 어려운 핵심 결정 — 신중하게 Thrift를 선택 - 검토 대상: Thrift, Avro, Protocol Buffers (당시 gRPC는 고려 외) - Thrift 선택 이유: Avro보다 작은 직렬화 크기, JSON 배열의 용량 문제 해소, VCNC 적용 사례 검증 - JavaScript/Node.js 공식 지원이 불충분해 포크해서 TypeScript 지원 추가 후 사용 - TCP 소켓의 오토스케일링 충돌 문제로 결국 HTTP 통신으로 후퇴 - 1년+ 운영 후 GraphQL로 전환: 라이브러리 비활성화·코드 생성 불편이 주요 이유

상세 정리 - REST API의 한계: 마이크로서비스 간 다양한 API를 REST로 표현하기 어려움 - Protocol Buffers 미선택 이유: 당시 JavaScript 공식 튜토리얼이 Node.js를 포함하지 않음 - Avro 미선택 이유: Thrift/Protobuf 방식보다 직렬화 크기가 클 것으로 판단 - 카카오스타일만의 필드 선택 패턴: Read API에 원하는 필드 ID 리스트를 같이 전달 - Update API도 단일 엔드포인트로 여러 요구사항 대응, 업데이트할 필드 명시 방식 - Thrift IDL로 struct ZigzagNotice + service ZigzagNoticeService 정의 예시 포함 - Node.js 공식 지원: 클라이언트 JavaScript 용으로 제한, Node.js 관용 코드 미생성 - TypeScript 지원 직접 추가: github.com/croquiscom/thrift (croquis-171130 브랜치) - TCP 통신 목표: 연결 재사용으로 오버헤드 감소 → 오토스케일링(ephemeral 인스턴스)과 충돌 - 현실 타협: HTTP 통신으로 전환, 수백개의 Thrift API 운영 중 - GraphQL 전환 계기: Thrift 라이브러리 JS/Node.js 쪽 비활성, TypeScript 미지원, 매 변경 시 코드 생성 번거로움 - 2017년 말부터 GraphQL 검토 시작, 이후 신규 API는 모두 GraphQL로 작성

왜 읽나: 마이크로서비스 통신 프로토콜 선택(REST vs Thrift vs Protobuf vs GraphQL)에서 실제 프로덕션 경험 기반의 트레이드오프와 기술 부채 청산 과정을 공유하는 드문 실전 기록이다.