API·통신 기술 전체 비교
2026.10.01 · 3분
1. 같은 수준의 개념은 아니다
REST, GraphQL, RPC, gRPC, WebSocket, SSE는 자주 함께 비교되지만 정확히 같은 종류의 개념은 아닙니다.
| 기술 | 정확한 성격 |
|---|---|
| HTTP | 요청과 응답을 전달하는 통신 프로토콜 |
| REST | HTTP를 활용하는 API 설계 스타일 |
| GraphQL | API 질의 언어, 타입 시스템, 실행 방식 |
| RPC | 원격 기능을 호출하는 통신 개념 |
| gRPC | RPC를 구현하는 프레임워크 |
| WebSocket | 지속적인 양방향 통신 프로토콜 |
| SSE | HTTP 기반 서버 → 클라이언트 이벤트 스트리밍 방식 |
따라서 “무엇이 가장 좋은가?”보다 “현재 문제에 어떤 성격이 필요한가?”를 물어야 합니다.
2. 한눈에 비교하기
| 기술 | 통신 형태 | 강점 | 대표 용도 |
|---|---|---|---|
| REST | 요청 → 응답 | 단순성·범용성·HTTP 활용 | CRUD, 공개 API |
| GraphQL | 질의 → 원하는 모양의 응답 | 유연한 데이터 선택 | 복잡한 화면 데이터 |
| RPC | 메서드 호출 → 결과 | 명령을 직관적으로 표현 | 내부 기능 호출 |
| gRPC | 타입 기반 RPC·스트리밍 | 성능·코드 생성·타입 | 마이크로서비스 |
| WebSocket | 지속 양방향 | 양쪽의 즉시 메시지 | 채팅·게임·관제 |
| SSE | 지속 단방향 | 단순한 서버 스트리밍 | AI·로그·알림 |
3. 하나의 서비스에서 조합하는 예
text
React / React Native
├─ REST: 로그인, 회원, 프로젝트 CRUD
├─ WebSocket: 실시간 채팅과 기기 제어
└─ SSE: AI 답변과 작업 진행률
API 서버
└─ gRPC: 주문·결제·알림 서비스 간 내부 호출GraphQL을 사용한다면 여러 화면의 조회 데이터를 GraphQL로 제공하고, 파일 업로드나 단순 명령은 REST Mutation 또는 별도 Endpoint로 처리하는 식의 조합도 가능합니다.
4. 요구사항에서 기술로 연결하기
| 요구사항 | 우선 검토할 기술 |
|---|---|
| 단순한 조회·등록·수정·삭제 | REST |
| 화면별 데이터 조합이 매우 복잡 | GraphQL |
| 원격 기능을 명령처럼 호출 | RPC |
| 내부 서비스 간 타입·성능·스트리밍 중요 | gRPC |
| 양방향 실시간 상호작용 | WebSocket |
| 서버에서 결과를 계속 내려줌 | SSE |
5. 기술 선택의 실제 비용
기능 적합성 외에도 다음을 확인해야 합니다.
- 팀이 이미 알고 있는 기술인가?
- 디버깅과 모니터링 도구가 준비되어 있는가?
- 로드밸런서·프록시·CDN이 지원하는가?
- 브라우저와 모바일 환경에서 제약이 없는가?
- 인증과 권한을 일관되게 적용할 수 있는가?
- 장애 시 재시도와 중복 요청을 안전하게 처리하는가?
- 기술을 추가할 만큼 현재 문제가 실제로 큰가?
6. 단순하게 시작하는 원칙
작은 서비스라면 REST만으로 시작해도 충분한 경우가 많습니다.
text
일반 CRUD 필요
→ REST로 시작
실시간 채팅 요구가 생김
→ WebSocket 추가
AI 답변 스트리밍 요구가 생김
→ SSE 또는 HTTP 스트리밍 추가
내부 서비스가 커지고 고빈도 호출이 병목
→ 측정 후 gRPC 검토각 기술은 새로운 코드, 장애 지점, 학습 비용, 운영 도구를 함께 가져오므로, 기술을 많이 쓴다고 아키텍처가 좋아지지는 않습니다.
7. 학습 관점에서 기억할 기준점
- REST와 GraphQL: 데이터를 어떤 인터페이스로 요청할 것인가?
- RPC와 gRPC: 원격 기능 호출을 어떻게 계약하고 실행할 것인가?
- WebSocket과 SSE: 지속적인 실시간 데이터를 어느 방향으로 전달할 것인가?
- HTTP: 위 기술 다수의 바탕이 되는 통신 규칙
8. 핵심 정리
API 기술은 데이터 구조·통신 방향·사용 환경·운영 비용에 맞춰 필요한 것만 골라 조합한다.