REST·GraphQL·gRPC·WebSocket 차이: API 통신 방식 고르는 기준

REST, GraphQL, gRPC와 WebSocket은 같은 층의 “프로토콜 목록”이 아니다. HTTP와 WebSocket은 통신 프로토콜이고, REST는 아키텍처 스타일이며, GraphQL은 쿼리 언어와 실행 규칙, gRPC는 원격 프로시저 호출 프레임워크다. 먼저 층을 구분해야 “무엇이 더 빠른가”가 아니라 클라이언트와 서버 사이의 계약을 어떻게 만들 것인가를 판단할 수 있다.

먼저 용어의 층을 분리한다

이름	성격	주로 해결하는 질문
HTTP	요청·응답 의미를 정의하는 애플리케이션 프로토콜	요청과 응답을 어떻게 교환할까
HTTPS	TLS로 보호되는 HTTP 통신	전송 중 기밀성·무결성과 서버 인증을 어떻게 확보할까
REST	분산 하이퍼미디어 시스템의 아키텍처 스타일	자원과 표현, 상태 없는 상호작용을 어떻게 설계할까
GraphQL	타입 시스템을 가진 쿼리 언어와 실행 규칙	클라이언트가 필요한 필드 모양을 어떻게 요청할까
RPC	원격 동작을 함수 호출처럼 모델링하는 방식	서비스의 동작 계약을 어떻게 표현할까
gRPC	RPC 프레임워크와 wire protocol	타입 계약·코드 생성·스트리밍을 어떻게 제공할까
WebSocket	지속 연결에서 양방향 메시지를 교환하는 프로토콜	양쪽이 독립적으로 메시지를 보내야 하는가

SOAP도 XML 기반 메시징 프로토콜이며 WSDL·WS-* 계약을 사용하는 기존 시스템에서 여전히 만날 수 있다. 다만 새 API를 고르는 글에서 REST와 “HTTP, SOAP, GraphQL, RPC”를 모두 동급 프로토콜로 놓으면 각 방식이 해결하는 문제가 흐려진다.

HTTP와 HTTPS는 API 모양을 정하지 않는다

HTTP는 메서드, 상태 코드, 헤더, 캐시와 요청·응답의 의미를 정의한다. JSON을 쓸지, URL을 자원 중심으로 설계할지, 단일 endpoint에 GraphQL 문서를 보낼지는 그 위의 API 설계가 결정한다.

HTTPS는 별도의 API 스타일이 아니라 HTTP 통신을 TLS로 보호하는 방식이다. TLS는 전송 중 도청·변조 위험을 낮추고 서버 인증을 제공하지만 다음을 대신하지 않는다.

• 사용자 인증과 권한 검사
• 입력 검증과 rate limit
• 로그·데이터베이스의 저장 시 암호화
• 애플리케이션 내부의 민감정보 노출 방지

공개 인터넷을 지나는 API라면 HTTP와 HTTPS를 장단점 비교로 두기보다 HTTPS를 기본 전제로 두는 편이 안전하다.

REST가 잘 맞는 경우

REST는 Roy Fielding이 정리한 아키텍처 스타일이다. 실무에서 “REST API”라고 부르는 많은 API는 HTTP 메서드와 자원 URL을 사용하는 정도부터 REST 제약을 폭넓게 적용한 형태까지 다양하다.

다음 조건에서 HTTP 자원 중심 API는 좋은 출발점이다.

• 브라우저·모바일·외부 파트너가 함께 사용하는 공개 API
• HTTP 상태 코드, 캐시, 프록시와 관측 도구를 그대로 활용하고 싶다.
• 자원 단위의 CRUD와 명확한 URL이 문제에 잘 맞는다.
• OpenAPI 같은 문서·SDK 생태계를 활용한다.

GET /users/42/orders?status=paid
Accept: application/json

단점은 화면마다 필요한 데이터 모양이 크게 다르면 endpoint나 응답 DTO가 늘 수 있다는 점이다. 그렇다고 REST가 항상 over-fetching을 만들거나 실시간 통신을 못 한다는 뜻은 아니다. 응답 설계, 필드 선택, HTTP streaming이나 별도 이벤트 채널로 해결할 수 있다.

GraphQL이 잘 맞는 경우

GraphQL은 클라이언트가 스키마에 공개된 필드 중 필요한 모양을 요청하게 한다.

query OrderSummary($userId: ID!) {
  user(id: $userId) {
    name
    orders(status: PAID) {
      id
      createdAt
    }
  }
}

여러 클라이언트가 서로 다른 화면을 빠르게 바꾸고, 하나의 도메인 그래프에서 필요한 필드를 조합해야 할 때 유용하다. 하지만 “단일 endpoint라 관리가 쉽다”로 끝나지 않는다.

• 필드별 권한 검사가 필요하다.
• query depth·복잡도·페이지네이션 제한을 설계해야 한다.
• resolver가 N+1 조회를 만들지 관측해야 한다.
• HTTP 캐시를 자원 URL처럼 바로 활용하기 어렵다.
• 스키마 변경과 deprecation을 운영해야 한다.

GraphQL 명세는 전송 방식에 독립적이다. 흔히 HTTP 위에서 사용하지만 “GraphQL 자체가 HTTP를 대체하는 네트워크 프로토콜”은 아니다. GraphQL over HTTP도 별도의 명세 작업으로 HTTP 의미와 연결한다.

gRPC가 잘 맞는 경우

gRPC는 서비스를 메서드와 메시지 계약으로 정의하고 여러 언어의 클라이언트·서버 코드를 생성할 수 있는 RPC 프레임워크다. Protocol Buffers를 흔히 사용하지만 gRPC 자체가 특정 데이터 형식에만 묶인 것은 아니다.

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc WatchOrders(WatchOrdersRequest) returns (stream OrderEvent);
}

다음 상황에서 후보가 된다.

• 조직 내부 서비스 간 호출이며 양쪽 런타임을 통제한다.
• 명시적인 타입 계약과 코드 생성이 중요하다.
• unary뿐 아니라 client·server·bidirectional streaming이 필요하다.
• deadline, cancellation, metadata와 표준 error model을 일관되게 쓰고 싶다.

gRPC는 HTTP/2 기반 transport와 스트리밍을 활용하지만 “항상 REST보다 빠르다”는 결론은 검증 없이 낼 수 없다. payload 크기, 직렬화, 호출 수, 프록시·서비스 메시, 언어 구현과 부하 패턴이 결과를 바꾼다. 장기 stream은 시작 후 부하분산이 어려워질 수 있고 디버깅 복잡도도 늘어난다.

브라우저에서는 일반 gRPC와 같은 방식으로 직접 호출하지 못하는 제약이 있어 gRPC-Web이나 gateway를 검토한다.

WebSocket이 필요한 경우

WebSocket은 opening handshake 뒤 하나의 지속 연결에서 클라이언트와 서버가 각각 메시지를 보낼 수 있게 한다. 채팅, 협업 편집, 멀티플레이 상태처럼 양쪽에서 낮은 지연의 이벤트가 계속 발생할 때 잘 맞는다.

WebSocket이 HTTP와 반드시 다른 포트를 써야 하는 것은 아니다. 일반적으로 ws는 HTTP와 같은 80, wss는 HTTPS와 같은 443을 사용할 수 있다.

지속 연결을 선택하면 애플리케이션이 다음을 직접 설계해야 한다.

• 인증 만료와 재인증
• 재연결과 누락 이벤트 복구
• 메시지 순서·중복·idempotency
• backpressure와 느린 소비자 처리
• 연결 수와 fan-out 관측
• 배포·장애 시 연결 종료 정책

서버에서 브라우저로만 이벤트를 보내면 SSE가 더 단순할 수 있다. WebSocket과 SSE, 롱폴링의 선택은 실시간 통신 방식 비교에서 별도로 다룬다.

요구사항으로 고르는 짧은 기준

요구사항	우선 검토할 방식	추가 확인
외부 공개 CRUD API	HTTPS 기반 자원 중심 API	캐시, 버전, 오류 계약
화면별 조회 모양이 크게 다름	GraphQL	권한, 복잡도, N+1, 캐시
통제된 내부 서비스 간 타입 계약	gRPC	gateway, 관측성, deadline
지속적인 양방향 이벤트	WebSocket	재연결, backpressure, 연결 운영
서버에서 브라우저로 단방향 이벤트	SSE	proxy timeout, resume, 인증
기존 WS-* 계약과 조직 표준	SOAP	변경 비용과 호환성

하나의 제품에서 여러 방식을 함께 쓰는 것도 자연스럽다. 외부 API는 HTTPS 기반 자원 API, 내부 서비스는 gRPC, 알림 스트림은 SSE를 쓸 수 있다. 중요한 것은 유행하는 이름 하나로 통일하는 것이 아니라 계약, 클라이언트 환경과 운영 실패 모드가 가장 단순해지는 조합을 선택하는 일이다.

참고 자료

• RFC 9110: HTTP Semantics
• Roy Fielding: REST 아키텍처 스타일
• GraphQL Specification
• GraphQL over HTTP Working Draft
• gRPC 공식 소개
• RFC 6455: The WebSocket Protocol