MSA의 혈관을 뚫어주는 기술: REST를 넘어 gRPC와 Protocol Buffers의 세계로
반갑습니다, 여러분. 15년 동안 백엔드 인프라와 시스템 프로그래밍 분야에서 키보드와 씨름하며 산전수전 다 겪은 시니어 개발자입니다. 오늘은 조금 묵직하지만, 알면 개발 인생이 바뀌는 이야기를 해보려 합니다. 혹시 마이크로서비스 아키텍처(MSA)를 야심 차게 도입했다가 서비스 속도가 오히려 느려지는 기이한 경험을 해보신 적 있나요? "분명 이론상으로는 도메인별로 완벽하게 분리했는데, 왜 통신 비용 때문에 전체 응답 시간이 2배가 늘어났지?"라는 고민으로 밤잠 설친 적, 저도 참 많았습니다. ☕
처음 제가 월간 활성 사용자(MAU) 500만의 대규모 트래픽 시스템을 리팩토링할 때가 생각납니다. 수백 개의 마이크로서비스가 서로 JSON을 주고받으며 대화를 나누는데, 마치 꽉 막힌 출근길 강남대로 같았죠. 텍스트 기반의 REST API는 사람에게는 친절하지만, 0과 1로 대화하는 기계에게는 너무나 수다스럽고 비효율적인 방식이었던 겁니다. 그때 만난 구세주가 바로 gRPC와 Protocol Buffers(Protobuf)였습니다. 단순히 "구글이 만들었으니 쓰세요"가 아닙니다. 이건 시스템의 혈류 속도를 근본적으로 개선하는 '차세대 API 기술'이자, 로우 레벨 최적화를 다루는 '시스템 프로그래밍'의 정수입니다. 오늘 이 글을 다 읽으실 때쯤이면, 여러분은 왜 넷플릭스, 스퀘어, 그리고 구글이 내부 통신망을 이 기술로 도배했는지 뼈저리게 이해하게 되실 겁니다.
1. 왜 우리는 REST API만으로는 부족한가? (문제의 본질)
우리가 흔히 쓰는 REST API는 훌륭합니다. 직관적이고, 웹 브라우저와 친하며, Curl 명령어로 쉽게 테스트할 수 있어 디버깅하기도 쉽죠. 하지만 '시스템 간 통신(Server-to-Server)'의 영역으로 넘어오면 이야기가 완전히 달라집니다. 제가 겪었던 실제 프로젝트 사례를 구체적으로 들려드리죠. A사는 하루 트래픽이 1,000만 건이 넘는 글로벌 이커머스 플랫폼이었습니다. 주문 하나가 들어오면 [주문 서비스] -> [재고 서비스] -> [회원 등급 서비스] -> [쿠폰 서비스] -> [결제 서비스] -> [배송 서비스]를 순차적으로, 혹은 병렬적으로 거쳐야 했습니다.
문제는 이 모든 과정이 JSON 텍스트로 이루어진다는 점이었습니다. JSON은 필드 이름(key)을 매번 반복해서 보냅니다. 예를 들어, 데이터 100만 건을 보낼 때 "product_id"라는 10바이트짜리 문자열도 100만 번 전송됩니다. 이는 네트워크 대역폭을 낭비할 뿐만 아니라, 텍스트를 파싱(Parsing)하고 직렬화(Serialization)하는 데 엄청난 CPU 자원을 소모하게 만듭니다. 실제로 Go pprof 도구를 사용해 프로파일링을 해보니, 전체 CPU 사용량의 40%가 단순히 JSON을 씹고 뜯고 맛보고 즐기는 데(Marshal/Unmarshal) 쓰이고 있었습니다. 비즈니스 로직을 돌려야 할 서버가 번역하느라 지쳐버린 꼴이었죠. 충격적이지 않나요?
📉 REST/JSON의 3가지 치명적 한계점
첫째, 페이로드(Payload)가 비대합니다. 앞서 말했듯 중복된 필드명과 텍스트 포맷은 바이너리 데이터에 비해 덩치가 큽니다. 모바일 환경처럼 네트워크가 불안정한 곳에서는 이 몇 킬로바이트의 차이가 사용자 이탈을 부릅니다. XML보다는 낫지만, 여전히 기계 입장에서는 군살이 너무 많습니다.
둘째, 타입 안정성(Type Safety)이 부족합니다. "분명 프론트엔드에서는 숫자로 보냈는데 백엔드에서는 문자열로 받았네?" 같은 경험 있으시죠? REST는 명시적인 스키마가 강제되지 않아서, 개발자 간의 의사소통 비용이 증가하고 런타임 에러가 발생하기 쉽습니다. Swagger 문서를 아무리 잘 써도 코드로 강제하는 것만 못하며, 이는 대규모 협업 시 잦은 버그의 원인이 됩니다.
셋째, HTTP/1.1의 구조적 문제입니다. 요청 하나를 보내고 응답을 받아야 다음 요청을 보낼 수 있는 'Head-of-Line Blocking' 문제 때문에, 동시성을 확보하려면 TCP 연결을 여러 개 맺어야 합니다. 이는 서버의 파일 디스크립터(File Descriptor)와 메모리 리소스를 갉아먹는 주범입니다.
2. gRPC의 핵심: HTTP/2와 바이너리의 만남
gRPC(Google Remote Procedure Call)는 구글이 10년 넘게 내부적으로 사용하던 'Stubby'라는 기술을 다듬어 오픈소스로 공개한 것입니다. 이름에서 알 수 있듯이, 로컬 함수를 호출하듯이 원격 서버의 함수를 호출할 수 있게 해줍니다. 하지만 gRPC의 진정한 위력은 그 기반이 되는 HTTP/2 프로토콜에서 나옵니다. 이는 단순한 프로토콜의 버전 업이 아니라, 전송 계층의 패러다임 시프트입니다.
🚀 HTTP/2가 가져온 혁명: 멀티플렉싱(Multiplexing)
HTTP/1.1이 편도 1차선 국도라면, HTTP/2는 왕복 10차선 고속도로입니다. gRPC는 이 고속도로를 100% 활용합니다. 가장 큰 특징은 멀티플렉싱입니다. 하나의 TCP 연결(Connection) 안에서 여러 개의 요청과 응답을 동시에, 순서에 상관없이 주고받을 수 있습니다.
예를 들어볼까요? 기존에는 웹 페이지에서 이미지 10장을 불러오려면 10번의 연결을 맺거나 앞선 요청이 끝날 때까지 순차적으로 기다려야 했습니다. 하지만 gRPC를 사용하면 단 하나의 연결을 맺고, 그 안에서 10개의 스트림(Stream)을 동시에 쏘아 올립니다. 이로 인해 TCP 핸드셰이크(Handshake) 비용이 획기적으로 줄어들고, SSL/TLS 협상 시간도 단축되어 지연 시간(Latency)이 극적으로 감소합니다. 제가 직접 벤치마킹했을 때, 대량의 작은 데이터를 주고받는 시나리오에서 HTTP/1.1 대비 약 7배 빠른 속도를 보여주었습니다. 이는 실시간 게임이나 주식 거래 시스템에서 엄청난 경쟁력이 됩니다.
📦 헤더 압축 (HPACK)
웹 통신에서 헤더(Header)는 생각보다 큽니다. User-Agent, Cookie, Auth Token 등이 매 요청마다 반복해서 전송되죠. HTTP/1.1에서는 이 헤더가 텍스트로 매번 전송되었습니다. HTTP/2는 HPACK이라는 압축 기술을 사용하여, 중복된 헤더는 인덱스(Index)만 전송하고 변경된 부분만 허프만 코딩으로 압축해서 보냅니다. 이로 인해 오버헤드가 수 킬로바이트에서 수 바이트 수준으로 줄어듭니다. 트래픽이 초당 수만 건 발생하는 서버에서는 이 작은 차이가 한 달에 수백 기가바이트의 데이터 전송 비용 절감으로 이어집니다.
3. Protocol Buffers: 작고 빠른 데이터의 비밀
gRPC의 엔진이 HTTP/2라면, 그 안을 흐르는 연료는 Protocol Buffers(Prot
댓글
댓글 쓰기