Toss의 gRPC

토스(Toss)는 대한민국 금융 IT 업계에서 gRPC를 가장 적극적이고 수준 높게 사용하는 기업 중 하나로 유명합니다. 토스의 기술 블로그나 컨퍼런스(Slash) 발표 내용을 보면, 그들이 왜 그리고 어떻게 gRPC를 쓰는지 실무적인 힌트를 많이 얻을 수 있어요. 🚀

토스가 gRPC를 다루는 방식은 우리가 앞서 이야기한 '실무 레벨의 쇼핑몰' 설계에 아주 좋은 이정표가 됩니다.

 

1. 📂 토스의 gRPC 관리법: "IDL 중앙 집중화"

토스는 수백 개의 마이크로서비스가 얽혀 있는 구조입니다. 각 팀이 자기 맘대로 .proto 파일을 만들면 관리가 안 되겠죠?

• 중앙 저장소: 모든 서비스의 .proto 파일을 하나의 Git 레포지토리에서 관리합니다.
• 자동화된 배포: 누군가 .proto 파일을 수정해서 푸시하면, CI/CD 파이프라인이 동작하여 Java(Spring), Go, Node.js용 라이브러리를 자동으로 빌드하고 사내 넥서스(Private Repository)에 배포합니다.
• 결과: 개발자는 그저 dependency에 한 줄 추가하면 최신 gRPC 스텁(Stub) 코드를 바로 쓸 수 있습니다. 📦

2. 🛡️ 보안과 인증 (Internal Security)

금융 서비스인 만큼 보안이 생명이죠. 토스는 gRPC의 인터셉터(Interceptor)를 적극 활용합니다.

• 공통 인터셉터: 모든 gRPC 호출 시점에 토큰을 검증하거나, 호출하는 서비스가 누구인지(Client ID) 확인하는 로직을 공통 라이브러리로 만들어 배포합니다.
• 어노테이션 기반 권한 제어: 스프링 부트 환경에서 특정 gRPC 메서드에 @RoleCheck 같은 커스텀 어노테이션을 붙여 권한을 관리하기도 합니다. 👮‍♂️

3. 📊 관찰성 (Observability)

서비스가 복잡해지면 "어디서 에러가 났지?"를 찾는 게 일입니다.

• Distributed Tracing: gRPC 헤더에 Trace ID를 실어 보내서, 하나의 요청이 여러 서비스를 거쳐갈 때의 전체 경로를 시각화합니다. (Zipkin이나 Jaeger 활용)
• 표준 에러 핸들링: gRPC는 HTTP 상태 코드와 다른 독자적인 에러 코드를 가집니다. 토스는 이를 사내 표준에 맞춰 맵핑하여, 에러 발생 시 어느 레이어에서 문제가 생겼는지 즉시 알 수 있게 설계합니다. 🔍

💡 토스도 "Outbox 패턴"을 쓸까요?

네, 당연히 씁니다! gRPC가 아무리 빨라도 '비동기 처리'가 필요한 영역은 반드시 존재하기 때문입니다.

• gRPC 구간: 송금 요청, 잔액 조회, 카드 승인 등 사용자가 결과를 바로 확인해야 하는 구간 💸
• Kafka(Outbox) 구간: 송금 완료 후 푸시 알림, 내역 저장, 혜택 포인트 지급 등 조금 늦어도 정확히 처리되어야 하는 구간 🔔