API 기술 비교 | REST vs GraphQL vs gRPC 완벽 정리

API 기술, 어떤 것을 선택해야 할까?

2026년 현재 REST, GraphQL, gRPC 3가지 API 스타일이 경쟁하고 있습니다.

각각의 장단점과 사용 사례를 정확히 이해해야 올바른 선택을 할 수 있습니다.

1. REST (Representational State Transfer)

역사: 2000년 Roy Fielding 박사 논문 발표

특징:

• HTTP 표준 활용
• 자원(Resource) 중심의 URL 설계
• GET, POST, PUT, DELETE 메서드

예:

GET /api/users/123           # 사용자 조회
POST /api/users              # 사용자 생성
PUT /api/users/123           # 사용자 수정
DELETE /api/users/123        # 사용자 삭제

REST의 장점

✅ 가장 단순하고 직관적

• 개발자 접근 쉬움
• 문서화 간편 (Swagger, OpenAPI)

✅ 캐싱 최적화

• HTTP 표준 캐시 활용 가능
• CDN 사용 용이

✅ 광범위한 지원

• 모든 언어·프레임워크 지원
• 라이브러리 풍부

✅ CORS 설정 단순

• 브라우저 보안 이슈 적음

REST의 단점

❌ Over-fetching 문제

• 필요 없는 필드도 받음

// 사용자 이름만 필요한데
GET /api/users/123
// 응답: {id, name, email, phone, address, ...} 전체

❌ Under-fetching 문제

• 필요 데이터를 위해 여러 요청 필요

// 사용자 + 게시물 + 댓글을 모두 필요하면
GET /api/users/123        # 1번 요청
GET /api/users/123/posts  # 2번 요청
GET /api/posts/456/comments # 3번 요청

❌ 버전 관리 복잡

• /api/v1/users vs /api/v2/users
• 여러 버전 동시 지원 필요

2. GraphQL

역사: 2012년 Facebook 내부 개발 → 2015년 공개

특징:

• 쿼리 언어로 필요한 데이터만 명시
• 단일 엔드포인트 (/graphql)
• 강한 타입 시스템

예:

query {
  user(id: 123) {
    name
    email
    posts {
      title
      comments {
        text
      }
    }
  }
}

GraphQL의 장점

✅ 정확한 데이터만 전송

• Over/Under-fetching 해결
• 네트워크 대역폭 30-70% 절감

✅ 강한 타입 시스템

• 자동 문서화
• 자동 코드 생성

✅ 실시간 기능 (Subscription)

• WebSocket 기반 실시간 업데이트

subscription {
  userUpdated(id: 123) {
    name
    email
  }
}

✅ 단일 요청으로 관련 데이터 획득

• N+1 쿼리 문제 해결

GraphQL의 단점

❌ 학습곡선 가파름

• 새로운 쿼리 언어 학습 필요
• 팀의 이해도 높아야 함

❌ 캐싱 어려움

• HTTP 캐시 활용 어려움
• 별도 캐싱 전략 필요

❌ 파일 업로드 제약

• GraphQL 기본은 파일 업로드 미지원
• 추가 구현 필요

❌ 복잡한 쿼리의 성능 문제

• 깊은 중첩 쿼리 → 백엔드 부하 증가
• 쿼리 복잡도 제한 필요

❌ 디버깅 상대적 어려움

• 일반 HTTP 도구로는 테스트 어려움
• GraphQL Playground 등 특화 도구 필요

3. gRPC

역사: 2015년 Google 개발

특징:

• Protocol Buffers 기반 (바이너리 직렬화)
• HTTP/2 활용 (멀티플렉싱)
• 강한 타입, 높은 성능

예:

service UserService {
  rpc GetUser(UserRequest) returns (User);
  rpc ListUsers(Empty) returns (stream User);
}

gRPC의 장점

✅ 최고의 성능

• REST 대비 7배 빠름 (성능 테스트)
• 바이너리 직렬화 (JSON 대비 작은 용량)

✅ 양방향 스트리밍

• 실시간 통신 최적화

rpc Chat(stream Message) returns (stream Message);

✅ 언어 중립적

• 80+ 언어 지원
• 자동 코드 생성

✅ HTTP/2 기반

• 연결 재사용
• 헤더 압축

gRPC의 단점

❌ 브라우저 지원 제한

• gRPC-Web 필요 (추가 구현)
• 일반 JavaScript 클라이언트 사용 불가

❌ 디버깅 어려움

• Postman 같은 도구 미지원
• grpcurl 등 특화 도구 필요

❌ 학습곡선 가파름

• Protocol Buffers 학습 필요
• 팀의 이해도 높아야 함

❌ 구형 인프라 미지원

• HTTP/2 미지원 환경 제약
• 로드 밸런서 설정 복잡

성능 비교 (벤치마크)

API 유형        응답시간    대역폭    처리량
─────────────────────────────────────────
REST (JSON)     200ms      100KB    1000 RPS
GraphQL         150ms      40KB     2000 RPS
gRPC           30ms       10KB     7000 RPS

(실제 성능은 구현과 환경에 따라 다름)

선택 기준

상황

추천

웹 브라우저 클라이언트	REST 또는 GraphQL
모바일 앱 (대역폭 제한)	GraphQL 또는 gRPC
마이크로서비스 간 통신	gRPC
리얼타임 피드백 필요	GraphQL (Subscription) 또는 gRPC
간단한 CRUD 작업	REST
복잡한 관계 데이터	GraphQL
최고 성능 필요	gRPC
개발 속도 우선	REST

2026년 API 시장 현황

사용률:

• REST: 72% (여전히 대다수)
• GraphQL: 18% (스타트업·핀테크 증가)
• gRPC: 10% (마이크로서비스, 모바일)

트렌드:

• REST → GraphQL 전환 증가 (특히 네트워크 제약 있는 환경)
• 마이크로서비스 기업은 gRPC 중심으로 전환
• GraphQL + REST 하이브리드 (장점 결합)

하이브리드 전략 (2026년 권장)

클라이언트 → GraphQL/gRPC (빠른 통신)
              ↓
      마이크로서비스들
              ↓
외부 API → REST (표준 준수)

예: Netflix 아키텍처

• 내부: gRPC (성능)
• 공개 API: REST (표준)
• 모바일: GraphQL (효율)

더 자세한 정보는 API 설계 최고의 실천과 웹 개발 로드맵을 참고하세요.

결론: 상황에 따라 선택

완벽한 선택은 없습니다. 각 기술의 장단점을 이해하고 프로젝트의 요구사항에 맞춰 선택하세요.

• 빨리 시작? REST
• 효율 최우선? GraphQL
• 성능 절대 우선? gRPC

3가지를 모두 알고 있는 개발자가 진정한 풀스택 개발자입니다.

핵심 체크리스트

• [ ] 이 글의 핵심 내용을 이해했는가?
• [ ] 나의 상황에 적용할 수 있는 부분은?
• [ ] 추가로 확인할 사항은?

---

관련 콘텐츠: IT 기술