API 프로토콜은 REST뿐만이 아니라고?!

지금까지 개발을 하면서 REST가 아닌 다른 프로토콜을 접해볼 기회는 거의 없었습니다. 그러다 보니 자연스럽게 REST만 사용해 왔던 것 같습니다. REST의 장점은 사용하기 편하다는 점에 있다고 생각합니다. HTTP 메서드, 헤더, 요청과 응답 구조가 직관적이고 이해하기 쉬워서
다른 프로토콜을 굳이 학습해야겠다는 필요성을 느끼지 못했던 것 같습니다. 하지만 API 프로토콜은 생각보다 REST만 존재하는 것이 아니었습니다. 이번 기회를 통해 각 프로토콜의 특징과, 왜 사용되는지에 대해 알아보고자 합니다.

들어가기에 앞서

올바른 API 프로토콜은 성능, 보안 및 확장성에 매우 중요합니다. 개발자는 다음 요소를 고려해야 합니다

• gRPC는 REST보다 빠르고 더 많은 설정이 필요합니다.
• Websockets는 실시간 상호작용을, SSE는 단반향 업데이트를 위한 대안이 될 수 있습니다.
• SOAP는 메시징의 기밀성 및 인증 절차를 강제합니다.
• REST는 GraphQL보다 설정하기 쉽지만, GraphQL은 데이터를 다양한 방법으로 가져올 수 있습니다.
•  REST와 GraphQL은 확장성이 좋지만, gRPC는 지연 시간이 적기 때문에 마이크로 서비스에 더 효율적입니다.

SOAP

SOAP(Simple Object Access Protocol)는 네트워크를 통해 애플리케이션 간 정보를 교환하기 위한
고도로 구조화된 XML 기반 메시징 프로토콜입니다.

SOAP는 일반적으로 HTTP의 POST 요청을 중심으로 통신합니다. 이 때문에 REST처럼 HTTP 메서드의 의미(GET, PUT, DELETE 등)를 활용한 캐싱이나 리소스 중심 설계가 어렵습니다. 또한 메시지가 XML로 작성되기 때문에 구조가 복잡하고,
메시지 크기 역시 상대적으로 큽니다.

REST가 각 자원의 행위를 URL과 HTTP 메서드로 표현하는 반면, SOAP는 하나의 엔드포인트(URL)를 통해 요청을 보내고
실제 동작의 의미는 XML 메시지 내부에 포함시킵니다. 이러한 특성 때문에 브라우저 기반의 웹 환경,
특히 프론트엔드와 백엔드가 분리된 구조에서는 사용하기가 쉽지 않습니다.

SOAP는 주로 서버와 서버 간 통신에서 사용되었으며, 엄격한 메시지 구조와 표준화된 오류 처리, 보안 기능을 바탕으로
여러 단계를 거치는 복잡한 비즈니스 트랜잭션을 처리하는 데 적합했습니다.
이러한 이유로 과거 금융권이나 대규모 기업 시스템에서 많이 사용되었습니다.

SOAP의 장점

• SOAP API는 프로그래밍 언어와 플랫폼에 독립적이어서 높은 상호 운용성을 제공합니다.
• WS-Security를 통해 암호화, 인증, 디지털 서명과 같은 강력한 보안 메커니즘을 기본적으로 지원합니다.
• SOAP Fault를 활용한 구조화된 오류 처리 메커니즘을 제공합니다.
• XML 스키마 기반의 엄격한 검증을 통해 일관되고 예측 가능한 데이터 구조를 보장합니다.

SOAP의 단점

• XML 기반 메시지는 장황하고 복잡하여 메시지 크기가 큽니다.
• REST나 gRPC에 비해 더 많은 대역폭을 요구하므로, 모바일 환경이나 저 대역폭 환경에서는 비효율적입니다.
• WSDL(Web Services Description Language) 및 XML 스키마 검증과 같은 추가적인 설정이 필요합니다.
• XML만 지원하며, REST처럼 JSON, YAML 등 다양한 데이터 형식을 지원하지 않습니다.
• REST API와 달리 AJAX나 JavaScript 프레임워크에서 웹 브라우저 차원의 기본 지원이 어렵습니다.

REST

REST는 이전에 포스트를 작성한적이 있습니다.

REST API란 무엇일까?

REST(Representational State Transfer)는
웹 애플리케이션을 설계하는 데 가장 널리 사용되는 API 설계 방식 중 하나입니다.
클라이언트–서버 모델을 기반으로 하며, 통신을 단순화하기 위해 표준 HTTP 메서드를 사용합니다.

REST의 핵심 특징은 다음 세 가지로 정리할 수 있습니다.

• 단순성(Simple)
• 확장성(Scalability)
• 무상태성(Statelessness)

이러한 특성 덕분에 REST는 웹 환경에서 사실상의 표준처럼 사용되고 있습니다.

REST의 장점

REST의 주요 장점은 다음과 같습니다.

• REST API는 표준 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하므로 구현과 이해가 비교적 쉽습니다.
• 무상태성을 기반으로 하기 때문에 서버가 세션 상태를 유지하지 않으며, 서버 인스턴스를 추가하는 방식으로 수평 확장이 용이합니다.
• REST API는 프로그래밍 언어에 의존하지 않기 때문에 웹 애플리케이션, 모바일 앱, IoT 장치, 기타 백엔드 시스템 등
  다양한 환경에서 사용할 수 있습니다.
• HTTP 캐시(Cache-Control, ETag 등)를 활용하여 응답 성능을 향상하고 서버 부하를 줄일 수 있습니다.
• REST는 거의 모든 최신 프로그래밍 언어와 테스트 도구에서 지원되어 생태계가 매우 성숙해 있습니다.

REST의 단점

강점에도 불구하고 REST는 몇 가지 구조적인 한계를 가지고 있습니다.

• REST API는 고정된 응답 구조를 가지기 때문에 불필요한 데이터를 과도하게 전달하는 오버페칭(필요 없는 것까지 같이 받는 것)이나,
  한 번의 요청으로 필요한 데이터를 모두 얻지 못하는 언더페칭(한 번에 안 끝나서 여러 번 시키는 것) 문제가 발생할 수 있습니다.
• 요청–응답 모델을 기반으로 하기 때문에 실시간 데이터 전송이나 서버 주도의 이벤트 전달에는 적합하지 않습니다.
• API 규모가 커질수록 엔드포인트와 리소스 구조를 RESTful하게 유지하는 데 점점 더 많은 설계 비용이 발생합니다.
• REST는 주로 JSON과 같은 텍스트 기반 포맷을 사용하기 때문에, gRPC의 Protocol Buffers와 같은 이진 프로토콜에 비해
  직렬화·역직렬화 비용과 처리 오버헤드가 상대적으로 큽니다.

gRPC

gRPC는 구글에서 개발한 고성능 오픈 소스 API 프로토콜로,
애플리케이션이 네트워크를 통해 효율적으로 통신할 수 있도록 설계되었습니다.

앞서 살펴본 SOAP와 비슷한 위치의 프로토콜로 볼 수 있으며,
웹 브라우저를 대상으로 한 통신보다는 서버와 서버 간 통신을 주 용도로 지향합니다.

gRPC의 또 다른 특징은 양방향 통신을 지원한다는 점입니다. 하나의 연결을 유지한 상태에서 클라이언트와 서버가
서로 독립적으로 메시지를 주고받을 수 있으며, 이로 인해 단순한 요청–응답 구조를 넘어선 통신 방식이 가능합니다.

gRPC의 핵심 특징

1. HTTP/2 기반 

• 다중화(Multiplexing)
  하나의 연결에서 여러 요청과 응답을 동시에 처리할 수 있습니다.
• 헤더 압축(Header Compression)
  HPACK을 사용해 반복되는 헤더 정보를 압축하여 오버헤드를 줄입니다.
• 서버 푸시(Server Push)
  서버가 클라이언트의 추가 요청 없이도 데이터를 전송할 수 있습니다.
• 양방향 스트리밍(Bidirectional Streaming)
  전이중 통신을 지원하여 지속적인 데이터 교환이 가능합니다.

2. Protocol Buffers 사용

• 효율적인 직렬화
  JSON 대비 더 빠른 직렬화·역직렬화를 제공합니다.
  (※ 수치는 환경에 따라 달라질 수 있음)
• 작은 페이로드
  바이너리 포맷을 사용해 메시지 크기를 줄입니다.
• 강력한 타입 시스템
  컴파일 타임에 타입 검증이 이루어집니다.
• 하위 호환성
  필드 추가·변경 시에도 기존 메시지와의 호환성을 유지할 수 있습니다.

 

장점

 

• 타입 안전성
  컴파일 타임 검증을 통해 런타임 오류를 줄일 수 있습니다.
• 개발 생산성
  자동 생성된 코드로 IDE 자동 완성 지원이 우수합니다.
• 명확한 계약
  .proto 파일 자체가 API 계약이자 문서 역할을 합니다.
• 버전 관리 용이성
  하위 호환성을 고려한 스키마 설계가 가능합니다.

 

단점

 

• 브라우저 지원 제한
  브라우저 환경에서는 gRPC-Web과 같은 추가 계층이 필요합니다.
• 디버깅 어려움
  바이너리 프로토콜 특성상 사람이 바로 읽기 어렵습니다.
• 학습 곡선
  REST에 비해 개념과 초기 설정이 상대적으로 복잡합니다.

 

GraphQL

graphQL은 프로토콜이 아니라 API를 위한 쿼리 언어이자, 이러한 쿼리를 실행하기 위한 런타임입니다.
2015년에 Facebook에서 개발된 이 기술은 클라이언트가 필요한 데이터만 요청할 수 있도록 하여,
기존 REST API에 비해 더 유연하고 효율적인 API 사용 방식을 제공합니다.

그렇다면 GraphQL은 어떻게 통신할까요?

GraphQL은 쿼리 중심으로 통신합니다.

기존 REST는 서버 중심의 통신 방식이었습니다. 서버가 미리 정의한 자원 단위로 데이터를 내려주다 보니,
프런트엔드에서 API를 사용할 때 불필요한 데이터까지 함께 내려오는 오버페칭 문제가 발생하곤 했습니다.

GraphQL의 접근 방식은 다릅니다. 서버가 내려주는 응답 형태를 고정하지 않고,
클라이언트가 필요한 데이터 구조를 직접 정의하여 요청하도록 합니다.

query {
  user(id: 1) {
    name
    posts {
      title
    }
  }
}

이 예시만 봐서는 크게 와닿지 않을 수 있지만, GraphQL은 서버 앞단에 하나의 인터페이스를 두고,
내부적으로는 기존 REST API나 서비스 로직과 통신하되, 클라이언트 입장에서는 훨씬 편하게 데이터를 조회할 수 있도록 만드는 구조라고 이해할 수 있습니다.

 

그럼 어떨때 사용이 될까요?

GraphQL은 다음과 같은 상황에서 특히 효과적입니다.

1. 프런트엔드 요구사항이 자주 변경되는 경우
2. 여러 클라이언트(웹, 모바일 등)가 동일한 API를 사용하는 경우
3. BFF(Backend For Frontend) 패턴을 적용하는 경우
   (BFF:특정 프런트엔드(웹, 모바일 등)를 위해 맞춤형으로 설계된 백엔드 레이어)

4. 조회(Read) 중심의 서비스인 경우

장점

필요한 데이터만 조회 
클라이언트가 필요한 필드만 요청할 수 있어 오버페칭·언더페칭 문제를 줄일 수 있습니다.

프론트 개발 생산성
화면 단위로 데이터 구조를 정의할 수 있어 프론트엔드 요구사항 변화에 유연하게 대응할 수 있습니다.

명확한 계약
Schema(Type, Query, Mutation)가 곧 API 계약이자 문서 역할을 하며, 자동 문서화 및 IDE 자동 완성을 지원합니다.

단일 엔드포인트
하나의 엔드포인트로 다양한 조회를 처리할 수 있어 API 엔드포인트 관리가 단순해집니다.

단점

서버 복잡도 증가
Resolver 구현과 데이터 조합 책임이 서버로 이동하며, N+1 문제 등 추가적인 설계 고려가 필요합니다.

캐싱 어려움
REST처럼 URL 단위 캐싱이 어렵고, 별도의 캐싱 전략을 설계해야 합니다.

성능 제어 필요
쿼리 복잡도에 따라 서버 부하가 커질 수 있어 쿼리 깊이 제한, 비용 분석 등의 방어 로직이 필요합니다.

모든 상황에 적합하지 않음
단순 CRUD나 서버 간 통신과 같은 경우에는 REST나 gRPC가 더 적합할 수 있습니다.

구분	REST	SOAP	gRPC	GraphQL
성격	아키텍처 스타일	메시징 프로토콜	RPC 프로토콜	쿼리 언어 + 런타임
주요 대상	클라이언트 ↔ 서버	서버 ↔ 서버	서버 ↔ 서버	클라이언트 ↔ 서버
통신 방식	HTTP 메서드 중심	XML 메시지	HTTP/2 + Protobuf	HTTP + Query
데이터 포맷	JSON	XML	Protobuf (바이너리)	JSON
실시간 통신	❌	❌	⭕ (스트리밍)	⭕ (Subscription)
타입 안정성	❌	⭕	⭕	⭕
브라우저 친화성	⭕	❌	❌	⭕
주요 장점	단순함, 생태계	강한 보안·계약	고성능, 저지연	조회 유연성
주요 단점	오버/언더페칭	복잡, 무거움	학습 비용	서버 복잡도
적합한 사용처	일반 웹 API	금융·레거시	MSA 내부 통신	BFF, 프론트 API

마무리

API 프로토콜이라고 하면 REST만 존재하는 줄 알았습니다. 하지만 공부하다 보니 REST뿐만 아니라 SOAP, gRPC, graphQL 그리고 작성하지 않은 websocket, SSE, webhook이 존재하였습니다. 기존에는 서버에서 API를 작성하고 그것을 프런트에서 가져오는 방식만 있는 줄 알았습니다. REST의 최대 단점이라고 하면, 실시간성이 부족하다는 건데 그 이유는 스테이레스 하기 때문으로 알고 있습니다. 하지만 REST의 이러한 단점을 해결? 하고자 다양한 방식들이 거론되었습니다. 특히 gRPC, grpahQL, websocket, SSE는 실시간에 특화가 되어있는 프로토콜입니다. 마지막으로 SOAP은 XML로 작성되어 있어 무겁다는 이슈가 있었죠. 이를 해결하기 위해 gRPC가 탄생이 되었다고 생각합니다. 물론 각자 역할이 조금씩 다릅니다. 서버에서 프런트로 전달하는 REST, 서버끼리 통신을 하는 SOAP, gRPC, API의 제약을 서버에 두지 않고 이를 역전한 graphQL을 학습하면서 API 프로토콜들이 이렇게 많다는 것을 느꼈던 거 같습니다.