# gRPC vs REST vs GraphQL: 실무에서 API 설계의 본질을 묻다

# gRPC vs REST vs GraphQL: 실무에서 API 설계의 본질을 묻다  API 선택은 기술 스펙 비교가 아닌, 시스템의 본질과 제약에 대한 이해다. REST의 범용성, gRPC의 효율성, GraphQL의 유연성은 각각 다른 문제를 해결한다. 올바른 선택은 '어느 것이 우수한가'가 아닌 '무엇을 최적화할 것인가'에서 출발한다. --- ## 기술 선택이라는 착각  API 설계 방식을 선택할 때, 우리는 흔히 기술 명세서를 펼쳐놓고 스펙을 비교한다. HTTP/2 지원 여부, 직렬화 방식의 효율, 타입 안정성의 보장. 이 모든 것이 중요하지만, 정작 핵심은 다른 곳에 있다. API는 시스템 간 계약이며, 그 계약의 형식은 시스템이 해결하려는 문제의 본질을 반영해야 한다. REST, gRPC, GraphQL은 각기 다른 시대적 맥락과 기술적 제약 속에서 탄생했다. REST는 웹의 확장성 문제를, gRPC는 마이크로서비스의 성능 문제를, GraphQL은 클라이언트의 데이터 요구 복잡성을 다룬다. 선택의 기준은 '어느 것이 더 나은가'가 아니라 '우리 시스템은 어떤 문제와 싸우고 있는가'여야 한다. 이 글은 세 가지 API 설계 방식의 기술적 특성을 넘어, 각각이 전제하는 시스템 구조와 설계 철학을 탐구한다. 실무에서의 선택은 결국 이 철학적 일관성 위에서만 정당화될 수 있다. ## REST: 웹의 제약이 만든 보편성  REST는 Roy Fielding의 박사 논문(2000)에서 체계화된 아키텍처 스타일이다. 그는 웹이라는 분산 하이퍼미디어 시스템의 제약 조건—stateless, cacheable, layered system—을 명시적으로 정의했고, 이 제약들이 오히려 시스템의 확장성과 단순성을 보장한다는 점을 증명했다. REST의 본질은 리소스 중심 사고다. 모든 것은 URI로 식별 가능한 리소스이며, HTTP 메서드는 그 리소스에 대한 표준화된 동작을 정의한다. `GET /users/123`은 단순한 엔드포인트가 아니라, "123번 사용자라는 리소스의 현재 상태를 조회한다"는 의미론적 계약이다. 이 단순함은 캐싱, 로드밸런싱, 프록시 등 웹 인프라의 모든 레이어에서 투명하게 작동하는 호환성을 제공한다. 그러나 REST의 강점은 동시에 한계다. 리소스 중심 설계는 복잡한 비즈니스 로직을 표현하기 어렵다. "사용자의 최근 30일 활동 중 특정 카테고리에 속한 항목만 필터링하여 연관 추천 포함"과 같은 요구사항은 여러 엔드포인트 호출이나 과도한 쿼리 파라미터로 귀결된다. N+1 문제는 REST의 구조적 특성이며, 클라이언트는 항상 over-fetching 또는 under-fetching의 딜레마에 직면한다. 그럼에도 REST가 여전히 지배적인 이유는 명확하다. 웹 표준과의 완벽한 정렬, 인프라의 광범위한 지원, 그리고 학습 곡선의 완만함. 공개 API, 써드파티 통합, 레거시 시스템과의 연동이 필요한 상황에서 REST는 가장 안전한 선택이다. 기술 부채가 적고, 팀의 역량이 다양하며, 시스템의 수명이 긴 경우—REST의 보수성은 미덕이 된다. ## gRPC: 효율성이라는 절대 명제 gRPC는 Google이 내부 RPC 프레임워크 Stubby를 오픈소스화하며 2015년 공개한 프로토콜이다. 그 설계 목표는 분명했다. 마이크로서비스 간 통신의 지연을 최소화하고, 네트워크 대역폭을 절약하며, 타입 안정성을 보장하라. HTTP/2 기반의 바이너리 프로토콜, Protocol Buffers를 통한 직렬화, 그리고 IDL(Interface Definition Language) 기반의 코드 생성. 이 세 가지 기둥은 gRPC를 REST와 근본적으로 다른 영역에 위치시킨다. JSON 대비 3~10배 빠른 직렬화 속도, 헤더 압축을 통한 대역폭 절약, 그리고 컴파일 타임 타입 체크는 고빈도 내부 통신에서 결정적 이점이다. 더 중요한 것은 스트리밍의 일급 지원이다. Unary, Server Streaming, Client Streaming, Bidirectional Streaming—네 가지 통신 패턴은 실시간 데이터 파이프라인, 로그 수집, 채팅 시스템 등에서 REST로는 불가능했던 설계를 가능하게 한다. WebSocket이 해결하려 했던 문제를 프로토콜 레벨에서 표준화한 것이다. 하지만 gRPC의 효율성은 복잡성의 대가를 요구한다. Protocol Buffers 스키마 관리, 코드 생성 파이프라인, HTTP/2 디버깅의 어려움. 브라우저 네이티브 지원 부재는 gRPC-Web이라는 우회로를 강제하며, 이는 추가적인 프록시 레이어를 의미한다. 조직의 기술 성숙도가 낮거나 개발 속도가 우선시되는 초기 스타트업에서 gRPC는 과도한 투자일 수 있다. gRPC는 성능이 비즈니스 가치와 직결되는 지점에서 빛난다. 마이크로서비스 간 내부 통신, 실시간 데이터 처리, IoT 디바이스 통신—네트워크가 병목이고, 타입 안정성이 신뢰를 보장하며, 팀이 그 복잡성을 감당할 수 있을 때, gRPC는 선택이 아닌 필연이다. ## GraphQL: 클라이언트 주도 설계의 혁명 GraphQL은 Facebook이 모바일 앱의 데이터 요구사항 복잡성을 해결하기 위해 2012년 개발하고 2015년 오픈소스화한 쿼리 언어다. 그 출발점은 근본적 질문이었다. 왜 서버가 클라이언트에게 필요한 데이터의 형태를 강제하는가? REST의 고정된 엔드포인트 구조는 클라이언트의 다양한 요구를 수용하기 어렵다. 모바일 앱은 최소한의 데이터를, 데스크톱 대시보드는 상세한 정보를, 관리자 패널은 관계 데이터까지 필요로 한다. 이를 REST로 해결하려면 엔드포인트가 증식하거나, 클라이언트가 여러 요청을 조합해야 한다. GraphQL은 이 문제를 스키마와 쿼리의 분리로 해결한다. 서버는 타입 시스템으로 가능한 모든 데이터를 정의하고, 클라이언트는 필요한 것만 정확히 요청한다. `{ user(id: "123") { name, posts(limit: 5) { title } } }`—하나의 요청으로 사용자 정보와 최근 게시물을 동시에 가져온다. Over-fetching과 under-fetching의 문제는 구조적으로 소멸한다. Introspection은 GraphQL의 또 다른 핵심이다. 스키마 자체가 쿼리 가능하므로, 자동 문서화, IDE 자동완성, 클라이언트 코드 생성이 표준 기능이 된다. 개발자 경험의 혁신은 여기서 나온다. 그러나 GraphQL은 복잡성을 클라이언트에서 서버로 이전시킨다. N+1 쿼리 문제는 DataLoader 같은 배칭 메커니즘으로 해결해야 하고, 쿼리 깊이 제한, 복잡도 분석, 권한 제어는 서버 개발자의 몫이다. 캐싱은 URL 기반이 아닌 쿼리 내용 기반이므로 HTTP 캐시를 활용할 수 없으며, CDN 통합도 복잡하다. REST의 단순함이 주던 인프라 레벨의 이점을 포기하는 셈이다. GraphQL은 클라이언트 다양성이 핵심 과제인 시스템에서 정당화된다. BFF(Backend for Frontend) 패턴을 자연스럽게 구현하고, 프론트엔드 팀의 자율성을 극대화하며, API 버저닝 없이 진화할 수 있다. 하지만 그 대가로 서버의 복잡성 증가와 성능 최적화 부담을 감수해야 한다. ## 선택의 기준: 최적화 대상을 정의하라 세 가지 방식의 기술적 차이는 명확하다. 하지만 실무에서의 선택은 기술 스펙이 아닌 시스템의 제약과 우선순위에서 결정된다. REST를 선택하는 순간은 공개 API 또는 써드파티 통합이 핵심일 때, 팀의 기술 스택이 다양하고 표준화가 필요할 때, 시스템의 수명이 길고 유지보수성이 최우선일 때, 웹 인프라(CDN, 캐시, 로드밸런서)를 최대한 활용해야 할 때다. gRPC를 선택하는 순간은 마이크로서비스 간 내부 통신이 빈번하고 성능이 중요할 때, 실시간 스트리밍이나 양방향 통신이 필수일 때, 타입 안정성과 계약 기반 개발이 조직 표준일 때, 네트워크 대역폭이 제약이고 바이너리 프로토콜의 효율이 필요할 때다. GraphQL을 선택하는 순간은 다양한 클라이언트(모바일, 웹, 관리자 패널)가 서로 다른 데이터를 요구할 때, 프론트엔드 팀의 자율성과 개발 속도가 우선일 때, API 버저닝 없이 스키마를 점진적으로 진화시켜야 할 때, 개발자 경험과 타입 안정성이 비즈니스 가치를 창출할 때다. 중요한 것은 하나의 선택이 다른 것을 배제하지 않는다는 점이다. 공개 API는 REST로, 내부 서비스 통신은 gRPC로, 모바일 BFF는 GraphQL로—각각의 문제 영역에 최적화된 방식을 혼용하는 것이 현실적이다. Netflix, Airbnb, Uber 등 대규모 시스템은 모두 하이브리드 전략을 택한다. ## 본질은 문제의 이해다 API 설계 방식의 선택은 기술의 우열을 가리는 게임이 아니다. REST의 보편성, gRPC의 효율성, GraphQL의 유연성은 각각 다른 축을 최적화하며, 그 어떤 것도 절대적 정답이 아니다. 올바른 선택은 시스템이 직면한 제약을 명확히 인식하는 데서 시작된다. 성능이 병목인가, 개발 속도가 경쟁력인가, 클라이언트 다양성이 복잡도를 키우는가. 이 질문에 정직하게 답할 때, 기술 선택은 자연스럽게 따라온다. 기술은 도구이며, 도구의 가치는 그것이 해결하는 문제의 본질과 정렬될 때만 발현된다. API 설계의 지혜는 최신 트렌드를 좇는 것이 아니라, 자신의 시스템을 깊이 이해하는 데 있다.