REST vs GraphQL — 핵심 정리
- 핵심 개념 (간단)
- REST: HTTP 메서드(GET/POST/PUT/DELETE 등)를 사용해 여러 엔드포인트에서 자원(Resource)을 주고받는 전통적 API 스타일
- GraphQL: 단일 엔드포인트에 쿼리를 보내 필요한 필드만 정확히 요청하는 데이터 요청 언어(API 규약). 페이스북이 개발함
REST 주요 특징
-
장점
- 설계가 단순하고 널리 사용되어 툴·라이브러리·문서가 풍부함
- HTTP 표준(상태 코드, 캐싱 등)을 자연스럽게 활용 가능
- 보안·운영 인프라(WAF, API Gateway 등)와의 호환성이 좋음
-
단점
- 오버페칭(불필요한 데이터 전송) / 언더페칭(필요한 데이터 부족) 발생 가능
- 여러 엔드포인트 관리로 버전 관리·유지보수 부담 발생
-
적합한 경우
- 단순 CRUD 서비스, 캐시 활용이 중요한 서비스, 기존 시스템과의 호환성이 우선인 경우
GraphQL 주요 특징
-
장점
- 클라이언트가 정확히 필요한 필드만 요청해 네트워크 효율 개선
- 단일 엔드포인트로 다양한 데이터 조합 처리 → 프론트 개발 생산성 증가
- 타입 기반 스키마로 문서화·자동완성 제공
-
단점 / 위험요소
- 복잡한 쿼리로 인한 DoS 위험(쿼리 깊이/비용 제한 필요)
- Introspection으로 내부 스키마·민감 필드 노출 가능성
- 필드 레벨 권한 관리 필요 — 인증만으론 부족할 수 있음
- 전통적 보안 솔루션이 바로 적용되지 않는 경우 존재
-
적합한 경우
- 클라이언트별 맞춤 응답이 많고, 여러 자원을 한 번에 조합해야 하는 SPA/모바일 앱 등
보안 관점 핵심 포인트 (GraphQL 특히 주의)
- 쿼리 복잡도(depth)와 비용(cost) 제한 및 시간 제한 설정
- 필드 레벨 인가(authorization) 적용 — 권한 체크를 각 필드/리졸버에서 수행
- Introspection은 프로덕션에서 접근 제어 또는 비활성화 고려
- 입력값 검증 및 쿼리 파서의 안전성 확보
- 로깅·모니터링으로 비정상 쿼리 패턴 탐지 및 자동 차단 규칙 마련
도입/전환 시 실무 팁
- 점진적 도입: 기존 REST를 한 번에 바꾸지 말고 일부 클라이언트/엔드포인트부터 도입
- API Gateway/게이트웨이 전략: 인증, 레이트 리밋, 로깅을 공통 계층에서 처리
- 스키마 설계: 민감 데이터는 별도 타입으로 분리하고 기본 숨김 처리
- 모니터링: 쿼리 비용, 응답시간, 에러율 지표화 후 자동 대응 정책 마련
- 검증 도구 사용: GraphQL 쿼리 복잡도 미들웨어, 제한 라이브러리 등 활용
간단 비교표 (한눈에)
- 엔드포인트: REST — 여러 엔드포인트 / GraphQL — 단일 엔드포인트
- 응답 구조: REST — 고정된 응답 / GraphQL — 요청 필드 지정 가능
- 네트워크 효율: REST — 오버페칭 가능 / GraphQL — 효율적이나 과다 쿼리 주의
- 보안·운영 성숙도: REST — 성숙·도구 풍부 / GraphQL — 추가 보호 로직 필요
결론(추천)
- 안정성·호환성 우선이면 REST 권장
- 클라이언트 맞춤 응답 및 네트워크 효율이 중요하고, 보안·모니터링 역량을 갖추고 있다면 GraphQL 고려
- 어느 쪽을 선택하든 권한 검증, 입력 검증, 로깅·모니터링, 과금·성능 보호(레이트 리밋 등) 는 반드시 구현해야 함
빠른 체크리스트 (도입 전)
- 서비스 요구: 클라이언트별 데이터 조합이 잦은가? → GraphQL 고려
- 보안/운영 역량: 쿼리 제어·모니터링 가능한가? → GraphQL 도입 전 필수 점검
- 기존 생태계: WAF·모니터링 연동이 쉬운가? → REST가 더 단순
- 팀 생산성: 프론트 개발자 생산성 향상이 우선인가? → GraphQL 장점
