REST vs GraphQL

둘 다 클라이언트가 서버의 데이터와 기능을 사용하도록 API를 만들 수 있습니다. HTTP, JSON, 인증, 권한, 캐시, 오류 처리 같은 공통 문제가 있으며 서로를 완전히 대체해야 하는 관계도 아닙니다.

REST
→ 서버가 Endpoint와 응답 구조를 정의

GraphQL
→ 서버가 스키마를 정의하고 클라이언트가 필요한 필드를 선택

REST:

GET /users/1
GET /users/1/posts

GraphQL:

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

• 일반적인 관리자 페이지 CRUD
• 자원 구조와 화면 요구가 단순함
• 공개 API를 많은 외부 개발자가 사용함
• HTTP 캐시와 CDN을 적극적으로 활용함
• 팀이 단순한 운영 구조를 선호함

• 웹·모바일의 데이터 요구가 크게 다름
• 화면 하나에서 여러 연관 데이터를 조합함
• 프론트엔드 요구 변화가 잦음
• 타입 기반 자동 완성과 코드 생성이 중요함
• 복잡한 질의를 통제하고 운영할 역량이 있음

“GraphQL은 한 번만 요청하므로 항상 빠르다”

요청 수는 줄어도 서버 내부에서 많은 DB 조회가 발생할 수 있습니다. N+1 문제와 지나치게 복잡한 질의를 관리해야 합니다.

“REST는 필요한 데이터만 받을 수 없다”

필드 선택 Query, 화면 전용 Endpoint, BFF를 통해 조절할 수 있습니다. 다만 이런 요구가 매우 많아지면 GraphQL의 일관된 질의 모델이 유리할 수 있습니다.

“GraphQL을 쓰면 버전 관리가 필요 없다”

필드를 점진적으로 폐기하기 좋지만, 스키마 변경과 호환성 관리는 여전히 필요합니다.

처음부터 GraphQL을 도입하기보다 다음 질문을 확인합니다.

1. 실제로 Over-fetching이나 다중 요청이 큰 문제인가?
2. 여러 클라이언트의 요구가 자주 충돌하는가?
3. 서버가 임의 질의의 비용과 권한을 안전하게 통제할 수 있는가?
4. 팀이 스키마·Resolver·클라이언트 캐시를 운영할 수 있는가?

문제가 단순하다면 REST로 시작하는 것이 합리적입니다. 복잡한 데이터 조합이 반복적으로 문제가 된다면 GraphQL을 검토합니다.

REST는 서버가 정의한 자원별 인터페이스가 강점이고, GraphQL은 클라이언트가 필요한 데이터 모양을 선택할 수 있다는 점이 강점이다.