# gRPC vs REST vs GraphQL: 실무에서 API 선택하는 결정 프레임워크

# 실무에서의 API 선택: REST, gRPC, GraphQL  API 설계는 단순한 기술 선택이 아니다. 시스템이 어떤 문제를 해결하려 하는지, 어떤 철학으로 구조화할 것인지를 결정하는 과정이다. REST, gRPC, GraphQL은 각각 다른 통신 패러다임을 구현하며, 서로 다른 문제에 적합하다. 이 글에서는 세 가지 API 아키텍처의 본질적 차이를 살펴보고, 실무에서 합리적으로 선택할 수 있는 기준을 제시한다.  --- ## 세 가지 서로 다른 관점 API 아키텍처를 논할 때 흔히 성능이나 유연성을 비교한다. 하지만 이는 본질을 놓치는 접근이다. REST, gRPC, GraphQL은 통신 프로토콜을 넘어 각기 다른 설계 철학을 담고 있다.  REST는 자원(Resource) 중심의 세계관을 따른다. 모든 것을 URI로 식별 가능한 자원으로 보고, HTTP 메서드로 행위를 표현한다. 웹의 근간인 하이퍼미디어 원칙을 계승한 설계다. gRPC는 원격 프로시저 호출(RPC)에 기반한다. 네트워크 너머의 서비스를 로컬 함수처럼 다루려는 시도다. GraphQL은 클라이언트가 필요한 데이터의 형태를 직접 정의하는 쿼리 언어로서의 API를 지향한다. 이 차이는 단순히 문법적인 것이 아니다. 각 패러다임은 서로 다른 복잡도, 성능 특성, 개발 경험을 수반한다. 선택의 핵심은 기술적 우열이 아니라, 시스템이 해결하려는 문제와의 적합성에 있다.  ## REST: 자원 중심 설계 REST는 2000년 Roy Fielding의 박사 논문에서 정립된 아키텍처 스타일이다. 핵심은 통일된 인터페이스(Uniform Interface)다. 모든 자원은 URI로 식별되고, HTTP 메서드를 통해 조작되며, 상태는 클라이언트가 관리한다. 이 제약은 단순함을 강제하고, 그 단순함이 확장성으로 이어진다. REST의 가장 큰 강점은 직관성이다. `/users/123`은 ID가 123인 사용자를 가리킨다. `GET`은 조회, `POST`는 생성, `PUT`은 갱신이다. 이 명료함 덕분에 문서 없이도 API를 어느 정도 이해할 수 있다. HTTP 표준 위에 구축되므로 캐싱, 인증, 로드 밸런싱 등 웹 인프라의 혜택을 자연스럽게 누린다.  그러나 자원 중심 사고는 한계가 있다. 복잡한 비즈니스 로직은 자원의 CRUD로 표현하기 어렵다. "결제 승인"이나 "주문 취소" 같은 행위를 어떤 자원의 어떤 HTTP 메서드로 나타낼 것인가? 실무에서는 `/orders/123/cancel` 같은 동사형 엔드포인트로 타협하는 경우가 많다. REST 원칙에는 어긋나지만 현실적인 선택이다. 또 다른 문제는 데이터 페칭의 비효율이다. 클라이언트가 이름만 필요해도 `/users/123`은 사용자의 모든 정보를 반환한다(Over-fetching). 반대로 사용자와 그의 게시글을 함께 조회하려면 두 번의 요청이 필요하다(Under-fetching). 이는 REST의 구조적 한계다. ## gRPC: 효율성과 타입 안정성 gRPC는 Google이 2015년 공개한 RPC 프레임워크다. HTTP/2 기반으로 작동하며, Protocol Buffers(protobuf)를 직렬화 형식으로 사용한다. 핵심은 강타입 계약과 바이너리 통신이다. protobuf는 스키마 정의 언어다. `.proto` 파일에 서비스와 메시지 구조를 명시하면, 컴파일러가 클라이언트와 서버 코드를 자동 생성한다. 이는 타입 안정성을 보장한다. 컴파일 타임에 API 계약 위반을 감지할 수 있고, IDE는 자동완성과 타입 체크를 제공한다. REST의 JSON은 런타임에야 구조를 알 수 있지만, gRPC는 코드 레벨에서 계약을 강제한다. 성능 면에서도 탁월하다. protobuf는 JSON보다 직렬화가 빠르고 페이로드가 작다. HTTP/2의 멀티플렉싱으로 단일 연결에서 여러 요청을 동시에 처리한다. 스트리밍 지원은 실시간 데이터 전송에 유리하다. 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍 모두 가능하다. 다만 진입 장벽이 있다. protobuf 스키마 작성, 코드 생성 파이프라인 구축, HTTP/2 인프라 설정이 필요하다. 브라우저는 gRPC를 직접 지원하지 않는다. gRPC-Web이라는 대안이 있지만 제약이 따른다. REST의 범용성과 비교하면 gRPC는 특정 맥락에 최적화된 도구다. 마이크로서비스 간 내부 통신이나 고성능 백엔드 시스템에서 그 가치가 드러난다. ## GraphQL: 클라이언트가 주도하는 설계 GraphQL은 Facebook이 2015년 공개한 쿼리 언어이자 런타임이다. REST와 gRPC가 서버 중심이라면, GraphQL은 클라이언트 중심이다. 클라이언트가 필요한 데이터의 형태를 쿼리로 명시하면, 서버가 그에 맞춰 응답한다. ```graphql query { user(id: "123") { name posts { title createdAt } } } ``` 이 쿼리는 사용자의 이름과 게시글의 제목, 작성일만 요청한다. REST라면 `/users/123`과 `/users/123/posts`를 각각 호출하고, 불필요한 필드를 클라이언트에서 제거해야 했을 것이다. GraphQL은 단일 엔드포인트에서 모든 것을 처리한다. Over-fetching과 Under-fetching 문제를 구조적으로 해결하는 셈이다. 스키마 기반 개발도 강점이다. 서버는 GraphQL SDL로 API를 정의한다. 이 스키마는 타입, 쿼리, 뮤테이션을 명시하며 클라이언트와 서버 간 계약이 된다. 개발 도구는 이를 기반으로 자동완성, 검증, 문서 생성을 제공한다. Introspection 기능으로 런타임에 API 스키마를 조회할 수도 있다. 그러나 GraphQL은 복잡도를 이전시킬 뿐이다. REST가 복잡도를 서버에 집중시켰다면, GraphQL은 클라이언트와 서버가 나눠 갖는다. 클라이언트는 쿼리 작성 능력을 갖춰야 하고, 서버는 효율적인 Resolver 구현과 N+1 쿼리 문제를 고민해야 한다. DataLoader 같은 도구로 완화할 수 있지만, 근본적으로 GraphQL은 유연성의 대가로 복잡성을 요구한다. 캐싱도 어렵다. REST는 HTTP 캐싱을 활용하지만, GraphQL은 단일 엔드포인트에 POST 요청을 보내므로 전통적인 HTTP 캐싱이 작동하지 않는다. Apollo Client 같은 도구가 클라이언트 측 캐싱을 제공하지만, 이는 추가 학습과 설정을 의미한다. ## 어떻게 선택할 것인가 세 가지 API 아키텍처는 각기 다른 문제를 해결하기 위해 존재한다. 선택의 기준은 시스템이 직면한 요구사항이어야 한다. **REST가 적합한 경우**는 다음과 같다. 공개 API를 설계할 때 범용성과 접근성이 중요하다. CRUD 중심의 단순한 자원 관리 시스템이라면 REST의 자원 모델이 자연스럽게 대응된다. HTTP 인프라의 혜택을 최대한 활용하고 싶거나, 팀이 REST에 익숙하고 빠른 프로토타이핑이 필요할 때도 적합하다. **gRPC가 적합한 경우**도 있다. 마이크로서비스 간 내부 통신처럼 성능과 타입 안정성이 우선일 때다. 실시간 양방향 통신이 필요한 시스템(채팅, 스트리밍, IoT)에서도 유리하다. 다국어 환경에서 일관된 클라이언트 코드 생성이 필요하거나, 네트워크 대역폭이 제한적인 저전력 환경에서도 효율성을 발휘한다. **GraphQL이 적합한 경우**는 클라이언트 요구사항이 다양하고 빠르게 변화하는 환경이다. 모바일 앱이나 SPA가 대표적이다. 여러 데이터 소스를 조합하는 복잡한 페칭 시나리오에도 적합하다. 프론트엔드와 백엔드 팀이 독립적으로 작업하되 명확한 계약이 필요할 때, 또는 API 버전 관리 부담을 줄이고 스키마를 유연하게 진화시키고 싶을 때 유용하다. 중요한 점은, 이 선택이 배타적일 필요는 없다는 것이다. 실무에서는 혼합 전략이 흔하다. 공개 API는 REST로, 내부 서비스 간 통신은 gRPC로, 프론트엔드 BFF는 GraphQL로 구성하는 식이다. 각 도구의 강점을 맥락에 맞게 활용하는 것이 합리적이다. ## 문제를 이해하는 것이 먼저다 API 아키텍처 선택은 트렌드를 따르는 행위가 아니다. 시스템이 해결하려는 문제의 본질을 이해하고, 그 문제에 가장 적합한 도구를 찾는 과정이다. REST는 자원의 명료함을, gRPC는 효율성과 엄밀한 계약을, GraphQL은 클라이언트 주도의 유연성을 제공한다. "어느 것이 더 나은가"는 잘못된 질문이다. 올바른 질문은 "이 시스템에서 우리가 해결하려는 핵심 문제는 무엇인가"다. 그 답이 선택을 결정한다. 기술은 사유를 돕는 도구이지, 사유를 대체하는 해답이 아니다.