535. 서비스 간 동기 통신 - REST API, gRPC (Protocol Buffers)

핵심 인사이트 (3줄 요약)

1. 본질: 서비스 간 동기 통신(Synchronous Communication)은 마이크로서비스 시대에 찢어진 50개의 서버들이 서로 데이터를 요청하고 "대답이 올 때까지 꼼짝 않고 전화통을 붙잡고 기다리는(Blocking)" 가장 직관적이고 1차원적인 실시간 대화 방식이다.
2. 가치: 구현이 너무 쉽고 "내가 던진 요청의 성공/실패 여부"를 그 자리에서 즉시(Real-time) 알 수 있어 로직 짜기가 압도적으로 편하다. 대중적인 **REST API(JSON)**와, 속도의 한계를 부수고 구글이 벼려낸 차세대 초고속 바이너리 통신망 **gRPC(Protocol Buffers)**의 양대 산맥이 시장을 양분하고 있다.
3. 융합: "기다리다 죽는다"는 동기식 통신의 치명적인 나비효과(Cascading Failure)를 막기 위해, 인프라 단에 **서킷 브레이커(Circuit Breaker, 장애 차단기)**와 타임아웃(Timeout) 룰을 강제로 융합시켜야만 MSA 생태계의 연쇄 붕괴를 간신히 틀어막을 수 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 모놀리식 시절엔 옆 부서 데이터를 원하면 그냥 함수 하나 불렀다(userService.getUser()). MSA로 찢어지자 함수 호출이 아니라 '네트워크 통신'이 되었다. A서버가 B서버에게 HTTP로 "유저 정보 내놔!"라고 찌르고, B서버가 JSON을 만들어 뱉어줄 때까지 A서버의 스레드(Thread)는 아무 일도 못 하고 허공을 보며 기다려야(동기/Blocking) 한다.

• 필요성: 회원가입을 하려는데 유저가 친 '이메일 주소'가 중복인지 아닌지 DB 서버에 물어봤다. 이때 "나중에 시간 나면 알려줘~"라고 비동기(Kafka)로 던질 수 있을까? 절대 안 된다. 지금 당장 중복 여부를 알아야 1초 뒤 유저 화면에 '가입 성공'을 띄워줄 거 아닌가. 이처럼 **"지금 당장 결과값을 받아야만 내 다음 로직을 진행할 수 있는 즉시성(Immediacy)이 생명인 비즈니스"**에서는 무조건 전화를 걸어 대답을 듣는 동기 통신(REST/gRPC) 뼈대가 100% 필수적이다.

• 💡 비유: 동기 통신은 **'짜장면 배달 전화'**와 똑같습니다. 손님(A서버)이 중국집(B서버)에 전화를 겁니다. "짜장면 하나요!" 손님은 전화를 끊지 않고 수화기를 들고 기다립니다. 주방장(B서버)이 "네~ 출발했습니다!"라고 대답을 해줘야만 손님이 비로소 수화기를 내려놓고(응답 완료) 숟가락을 세팅할 수 있습니다. 가장 확실한 소통법이지만, 주방장이 화장실에 가서 10분 동안 전화를 안 받으면 손님도 10분 동안 수화기를 들고 화장실도 못 가는 멍청한 상태(Blocking 렉)가 유지되는 것이 최대 딜레마다.

• 등장 배경 및 발전 과정:

  1. SOAP과 XML의 무거운 시대 (과거): 2000년대엔 SOAP이라는 규격을 썼다. 규칙이 너무 빡빡하고 XML이라는 엄청나게 무겁고 뚱뚱한 텍스트로 데이터를 말아 보내서 서버가 헉헉댔다.
  2. REST API와 JSON의 천하통일 (2010s): "다 치워! 그냥 HTTP 주소로 직관적으로 부르고, 텍스트는 가벼운 괄호 덩어리(JSON)로 주고받자!" 인간이 읽기 편한 REST가 나타나 전 세계 백엔드와 프론트엔드 통신을 완전히 지배했다.
  3. gRPC와 Protobuf의 역습 (현재): MSA가 50개로 찢어지며 서버끼리 1초에 1만 번씩 통신한다. 인간이 읽기 편한 JSON(문자열)을 계속 만들어 쏘려니 CPU 압축/해제 비용(Overhead)이 너무 커졌다. 구글이 빡쳐서 "인간 눈치 보지 마! 기계끼리 가장 빨리 주고받게 압축된 0과 1의 쇳덩어리(바이너리)로만 쏴!" 라며 gRPC를 내놓아 서버 간 통신(Backend-to-Backend)의 왕좌를 찬탈 중이다.

• 📢 섹션 요약 비유: REST API(JSON)가 외국인 두 명이 **'느리지만 누구나 이해하는 쉬운 만국 공통어(영어 텍스트)'**로 대화하는 것이라면, gRPC(바이너리)는 쌍둥이 스파이가 **'모스부호(0과 1)로 1초에 100문장을 따다닥 쏘아 올리며 타인은 절대 해독할 수 없는 극강의 암호 통신'**을 하는 것입니다. 상황에 맞춰 편안함(REST)과 스피드(gRPC)를 골라 써야 합니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. REST API (Representational State Transfer)의 빛과 그림자

가장 만만하고 가장 사랑받지만, 덩치가 커질수록 발목을 잡는다.

• 원리: HTTP 프로토콜의 4대 동사(GET, POST, PUT, DELETE)를 써서, 자원(Resource, URI)의 상태를 주고받는다. 포맷은 { "name": "Kim", "age": 20 } 같은 텍스트 기반 JSON을 쓴다.
• 장점:
  • 범용성의 황제다. 브라우저, 모바일 앱, 파이썬, 자바 등 전 세계 모든 플랫폼이 HTTP와 JSON을 기본으로 알아먹으므로 통역사(별도 라이브러리)가 필요 없다.
  • 인간이 포스트맨(Postman)으로 찔러보고 눈으로 읽으며 디버깅하기 환상적이다.
• 단점 (MSA에서의 한계):
  • 텍스트(String) 덩어리라서 무겁다. 20이라는 숫자를 보내는데 문자열 2와 0으로 변환해서 쏘느라 네트워크 대역폭(Bandwidth)을 낭비한다.
  • 타입(Type)을 강제할 수 없다. A서버가 "나이"를 Int로 쐈는데, B서버가 String으로 받다가 런타임에 뻥 터지는 타입 에러(Type Mismatch) 지옥이 열린다.

2. 구글의 걸작: gRPC와 Protocol Buffers (Protobuf)

REST의 낭만(인간의 가독성)을 찢어버리고 오직 '기계의 속도'에 미쳐버린 흑마법.

• 원리 (HTTP/2 + 바이너리):

  • Protocol Buffers(프로토부프)라는 언어로 뼈대(IDL)를 짠다. int32 age = 1; string name = 2;
  • 기계가 이 뼈대를 컴파일하면, JSON 텍스트가 아니라 '10101100' 같은 초압축 바이너리(쇳덩어리) 패킷으로 데이터를 찌그러뜨린다.
  • 이 압축된 쇳덩어리를 HTTP/2 라는 최신 고속도로(다중화, 양방향 스트리밍)에 태워 쏜다.

• 장점 (압도적 성능): REST(JSON)보다 데이터 크기가 1/3로 줄어들고, 파싱(해독) 속도는 10배 이상 빠르다. MSA 50개가 서로 통신할 때 네트워크 병목을 물리적으로 박살 낸다. 양 서버가 프로토부프 도면을 나눠 가지므로 타입(Type-safe) 에러가 컴파일 타임에 즉시 차단된다.

• 📢 섹션 요약 비유: REST API는 물건을 보낼 때 **'내용물이 다 보이는 투명한 뽁뽁이 비닐(JSON)'**에 싸서 일반 택배(HTTP/1.1)로 보내는 겁니다. 배달원이나 받는 사람이 안을 보기 참 쉽습니다. gRPC는 물건을 **'진공 압축기로 부피를 1/10로 납작하게 누른 뒤 티타늄 캡슐(바이너리)'**에 담아 KTX 특급열차(HTTP/2)로 쏘는 겁니다. 인간은 안을 못 열어보지만, 도면(Protobuf)을 가진 로봇끼리는 0.1초 만에 조립해서 풀어버리는 마법입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 동기 통신 양대 산맥의 실전 채점표 (REST vs gRPC)

아키텍트가 벤더 연동과 사내망 통신을 가를 때 꺼내는 칼이다.

과목 융합 관점

• 클라우드 / 데브옵스 (API Gateway와의 융합): 외부 모바일 앱(React Native)은 gRPC를 못 읽는다. 무조건 JSON을 줘야 한다. 하지만 사내 백엔드 MSA 50대는 지들끼리 광속 gRPC 통신을 하고 싶다. 아키텍트는 앞단 정문에 **API Gateway (Kong, Envoy 등)**를 융합시킨다. 고객의 모바일 앱이 Gateway로 JSON(REST)을 날리면, Gateway가 0.1초 만에 그걸 바이너리(gRPC)로 찌그러뜨려서 뒷단 서버로 쏴준다. "외부엔 인간의 언어(REST)를, 내부엔 기계의 언어(gRPC)를" 이분화하는 프록시 변환 아키텍처가 현대 클라우드의 1티어 뼈대다.

• 소프트웨어 공학 (동기 통신의 지옥, Cascading Failure): 동기 통신의 낭만은 1분 만에 끝난다. A ➡ B ➡ C ➡ D 서버로 이어지는 결제 로직. D서버가 DB 락(Lock)에 걸려 30초 동안 대답을 안 한다. C서버 스레드 뻗고, B뻗고, A뻗고, 결국 1만 명의 모바일 앱 화면이 하얗게 얼어붙었다(연쇄 폭발). 아키텍트는 519장에서 배운 **서킷 브레이커(Circuit Breaker, Resilience4j)**와 엄격한 Timeout(3초 안 오면 강제 에러 처리) 룰을 무조건 이 동기 통신 코드 사이사이에 방파제로 발라놔야만 회사 시스템 전체가 동반 자살하는 사태를 막을 수 있다.

• 📢 섹션 요약 비유: 이 릴레이 붕괴는 고속도로의 **'안전거리 미확보 연쇄 추돌'**과 같습니다. 동기 통신(REST/gRPC)은 앞차(D서버)가 멈출 때까지 내 차(A서버)도 꼼짝없이 멈춰서 기다려야 하는 줄서기입니다. 앞차가 브레이크를 밟으면 뒷차 50대가 쾅쾅쾅 다 부딪혀 터집니다(Cascading Failure). 그래서 반드시 중간중간에 **'3초 기다리다 앞차가 안 가면 핸들을 꺾어버리는 자동 회피 시스템(서킷 브레이커)'**을 범퍼(코드)에 달아놔야만 내 차가 살아남을 수 있습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — Swagger(REST) 문서의 거짓말과 타입 에러 대폭발: 백엔드 팀이 REST API(JSON)를 만들고 Swagger 문서를 띄워 프론트엔드 팀에게 줬다. 프론트 팀은 문서를 보고 amount를 '숫자(Int)'로 예쁘게 파싱해서 화면을 짰다. 1달 뒤, 백엔드 주니어가 "금액이 너무 커지네" 라며 서버에서 amount를 '문자열(String)'로 슬쩍 바꿨는데 Swagger 문서 갱신을 까먹었다. 배포 당일 프론트엔드 화면이 전부 500 에러를 뿜으며 피를 토했다(런타임 타입 붕괴). JSON의 유연함이 낳은 완벽한 계약 파기(Contract Breach)다.

   • 아키텍트의 해결책: REST API의 강결합 계약 부재(Lack of Strict Contract)가 낳은 비극이다. 아키텍트는 사내 서버 간, 혹은 프론트-백엔드 간의 중요 통신 뼈대를 **gRPC (Protocol Buffers)**로 갈아엎어야 한다. gRPC는 문서(Swagger) 나부랭이가 필요 없다. *.proto 라는 파일에 int32 amount = 1; 이라고 딱 1줄 치면, 그 도면 파일 자체가 자바(Java), 타입스크립트(TS) 코드로 자동 컴파일되어 양쪽 팀에 뿌려진다. 백엔드가 이걸 String으로 바꾸려면 저 .proto 뼈대 자체를 수정해야 하므로 양쪽 코드가 동시에 빌드 에러를 내며(컴파일 타임 차단) 인간의 멍청한 거짓말을 물리적으로 완벽히 쳐낸다.

2. 시나리오 — 1,000만 건의 엑셀 다운로드, REST API 메모리 터짐 현상: 고객이 "최근 10년 치 구매 내역 엑셀 다운로드"를 눌렀다. 백엔드 서버가 DB에서 데이터 1,000만 줄을 읽어와서 거대한 JSON 텍스트 1개로 뭉치기 시작했다(REST API의 한계). 서버 메모리(RAM) 용량을 넘어서자 OutOfMemoryError(OOM)가 뜨면서 서버가 통째로 사망했다. JSON은 기본적으로 "모든 데이터를 다 만들 때까지 기다렸다가 한방에 쏘는" 단발성 규격이기 때문이다.

   • 아키텍트의 해결책: 대용량 동기 처리 시 Payload 한계를 뚫어내는 스트리밍(Streaming) 아키텍처다. 아키텍트는 100만 건을 JSON 한 덩이로 묶는 멍청한 짓을 멈추게 해야 한다. gRPC의 Server Streaming 기능이나, 스프링(Spring)의 WebFlux(Server-Sent Events, SSE)를 융합 도입한다. 서버가 DB에서 10줄을 읽자마자 클라이언트에게 바로바로 10줄씩 쪼개서 쏘아 보내는(Streaming) 수도관 파이프라인을 뚫어버린다. 서버 메모리는 10줄분량(1MB)만 먹은 채로 1,000만 건의 데이터를 우아하게 고객 폰에 100% 끊김 없이 흘려보내는 궁극의 메모리 방어 설계다.

도입 체크리스트

• 조직적: 모바일 팀과 인프라 팀 간의 HTTP/2 호환성 체크 완료? 아키텍트가 속도 빠르다며 사내망을 gRPC로 다 도배했다. 그런데 구형 안드로이드 폰과 회사 앞단의 낡은 L4 로드밸런서 스위치가 HTTP/1.1밖에 지원하지 않는 고철 덩어리였다! gRPC는 무조건 최신 HTTP/2.0 프로토콜 위에서만 도는 까탈스러운 귀족이다. 낡은 장비들이 트래픽을 다 뱉어내어 서비스가 망했다. gRPC 도입은 코딩 스킬이 아니라, 우리 회사의 모든 라우터, 로드밸런서(ALB/NLB), 프록시 인프라가 HTTP/2 멀티플렉싱을 지원하는지에 대한 대규모 인프라 실사(Audit)가 선행되어야 하는 전쟁이다.
• 기술적: API 하위 호환성 (Backwards Compatibility) 룰을 박아넣었는가? gRPC의 .proto 도면에 int32 age = 2; 라고 써놨다 치자. 내일 "이 필드 필요 없네" 하고 코드를 쓱 지우고 3번 필드를 새로 만들었다. 구버전 모바일 앱(업데이트 안 한 고객)이 2번 필드로 데이터를 쏘면 서버가 터진다. gRPC의 절대 헌법: "한 번 부여한 번호(Tag Number)는 우주가 멸망할 때까지 절대 수정하거나 지울 수 없다(Append-Only)." 기존 필드는 놔두고 새로운 번호를 계속 뒤로 추가해 나가는, 뼈를 깎는 설계자의 자기 통제력이 없으면 gRPC 생태계는 1달 만에 지옥으로 변한다.

안티패턴

• "동기 통신(REST/gRPC)으로 50개 서버 릴레이 찌르기 (Distributed Monolith)": 쇼핑몰에서 '주문 완료' 버튼을 눌렀다. 주문 서버가 ➡ 결제 서버 찌르고 ➡ 배송 서버 찌르고 ➡ 쿠폰 서버 찌르고 ➡ 포인트 서버 찌른 뒤에야 사용자 화면에 "완료!"가 뜬다. (동기식 릴레이 안티패턴). 서버 5대가 꼬리를 물고 기다리느라 5초가 걸렸다. 중간에 포인트 서버가 1초 멈추면 사용자 화면은 6초 동안 멈춘다. "동기 통신(REST/gRPC)은 무조건 '조회(GET)' 하거나 '꼭 지금 당장 답변을 들어야 하는 핵심 결제 로직' 1~2 뎁스(Depth)에서만 써라. 나머진 무조건 카프카(Kafka) 같은 큐(Queue)에 던지고 쿨하게 뒤도 안 돌아보는 '비동기(Asynchronous)'로 끊어쳐야만 마이크로서비스는 생존한다." (다음 장 536번 연계)

• 📢 섹션 요약 비유: 동기 통신 릴레이는 **'전화 끊지 말고 잠깐 기다려봐! (통화 무한 대기)'**와 똑같습니다. A가 B에게 전화해서 답을 묻고, B는 대답하려고 C한테 전화를 또 겁니다. A는 B와 C가 통화를 끝낼 때까지 멍하니 전화기를 붙잡고 귀만 대고 있어야 합니다(스레드 낭비). 진짜 효율적인 통신(비동기)은 A가 B에게 "나 이거 했으니까, 나중에 다 되면 카톡 줘!" 하고 전화를 끊은 뒤(스레드 반납) 자기 할 일(다른 손님 받기)을 하러 가는 완벽한 비대면 쿨거래입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• GraphQL의 왕좌 위협 (조회 최적화의 끝판왕): REST API의 가장 큰 불만은 "사용자 이름 1개만 필요한데, 서버가 User 객체 안의 전화번호, 주소, 쿠폰 내역 100개를 다 뭉쳐서 뚱뚱한 JSON으로 던져준다(Over-fetching)"는 것이었다. 그래서 페이스북이 프론트엔드가 딱 원하는 칼럼 1개만 핀셋으로 뽑아(Query)오게 만드는 GraphQL을 세상에 내놨다. 미래의 읽기(Read) 통신은 프론트엔드의 자유도를 무한대로 보장하는 GraphQL이 집어삼키고, 무거운 서버 간 로직 통신은 gRPC가 양분하는 투-트랙(Two-track) 생태계로 재편 중이다.
• eBPF와 gRPC의 무결점 인프라 결합: 현재 gRPC 서버들끼리 통신하려면 이스티오(Istio) 사이드카를 붙여서 트래픽을 가로챈다. 그런데 사이드카를 거치는 것조차 느리다며 징징대는 하이엔드 아키텍트들이 나타났다. 결국 리눅스 커널의 뇌(eBPF)에 직접 손을 대어, 컨테이너 밖으로 패킷이 나가기도 전에 커널 바닥에서 gRPC 통신을 가로채고 라우팅해버리는 '초음속 에이전트리스(Agentless) 통신망'이 클라우드 네이티브 성능 최적화의 다음 10년을 지배할 마스터키로 떠오르고 있다.

참고 표준

• HTTP/2 & HTTP/3 Protocol: gRPC가 미친 듯이 날아다닐 수 있게 밑바닥을 깔아준 차세대 통신 고속도로. 한 번의 악수(TCP 연결)로 수백 개의 요청을 양방향(Multiplexing)으로 동시에 쏘아버리는 통신 규격의 헌법.
• Protocol Buffers (Protobuf): 구글이 "JSON은 뚱뚱한 쓰레기야!" 라며 빡쳐서 만든 기계들의 언어. .proto 텍스트 파일 하나만 짜면 자바, 파이썬, C++ 어떤 언어로든 1초 만에 클래스 파일을 뚝딱 생성해 내는 전 우주급 API 인터페이스 정의 언어(IDL).

서비스 간 동기 통신(REST API, gRPC)은 소프트웨어 공학이 **"인간이 읽기 편한 텍스트의 낭만(REST)을 즐길 것인가, 아니면 피도 눈물도 없는 기계의 0과 1의 극한 속도(gRPC)에 목숨을 걸 것인가"**를 저울질하는 거대한 아키텍처의 철학적 선택이다. 50개로 찢어진 마이크로서비스 세상에서, 네트워크(통신)는 더 이상 0.001초 만에 닿는 하드디스크가 아니다. 선이 끊기고, 패킷이 유실되고, 옆 서버가 무한정 뻗어버리는 지옥의 무법지대(Network is unreliable)다. 기술사는 무지성으로 전화를 걸고 마냥 응답을 기다리는 순진한 타자수(Coder)가 되어서는 안 된다. 가장 유연한 언어(JSON)로 외부의 손님을 맞이하되, 성안의 병사(서버)들끼리는 번개같이 빠르고 차가운 쇳덩어리(Protobuf) 암호로 소통하게 훈련시켜라. 그리고 3초 안에 대답이 없으면 망설임 없이 수화기를 부숴버리고(Circuit Breaker) 다음 플랜(Fallback)을 가동하는 냉혹한 결단력, 그것만이 끊어진 선(Network) 위에서 10조 원의 비즈니스를 무중단으로 굴려내는 위대한 심포니(Symphony)의 지휘술이다.

• 📢 섹션 요약 비유: REST API와 gRPC의 선택은 **'비행기 화물칸 테트리스'**와 똑같습니다. 과자 박스를 보낼 때 겉에 매직으로 "과자 100개, 딸기맛"이라고 크게 적어 보내는 것(REST/JSON)은 사람이 상하차할 때 보고 옮기기 참 편합니다(가독성). 하지만 비행기 짐칸(네트워크)은 비좁고 비쌉니다. 아키텍트(물류 센터장)는 매직 글씨를 다 지우고, 과자들을 기계로 1/10 크기로 꽉꽉 찌그러뜨린 뒤 겉에 바코드(gRPC/바이너리) 딱 하나만 붙여 비행기에 쑤셔 넣어야 합니다. 사람은 바코드를 못 읽지만 컨베이어 벨트 기계 로봇은 1초 만에 찍고 배송을 끝냅니다. 이 극한의 짐 싸기 최적화가 클라우드 트래픽 요금을 수억 원 아껴줍니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 내가 친구한테 1+1 정답을 물어보려고 **'전화(동기 통신)'**를 걸었어요. 친구가 답을 계산하느라 10분 동안 말없이 고민하면, 나도 전화를 끊지 못하고 10분 동안 화장실도 못 가고 기다려야 하죠(블로킹 에러).
2. 이때 친구랑 한국말(REST API/JSON)로 길고 친절하게 대화하면 알아듣긴 쉽지만 말이 길어져서 답답해요.
3. 그래서 우리 둘은 **'우주인 비밀 암호(gRPC/바이너리)'**를 만들어서 "1! 1!" 하면 "2!" 라고 0.1초 만에 툭 뱉고 전화를 끊어버리는 엄청난 빛의 속도 대화법을 연습했어요. 이렇게 상대방이 답을 줄 때까지 전화통을 붙잡고 즉시 대답을 받아내는 통신 기술을 **'동기 통신'**이라고 부른답니다!