REST vs GraphQL: 무엇이 다르고 어떤 것을 써야 할까?

REST와 GraphQL은 API를 설계하는 두 가지 방식입니다. API는 앱의 화면(또는 다른 프로그램)이 백엔드에 데이터를 요청하는 약속된 방법입니다. REST에서는 /customers나 /orders처럼 대상별로 URL이 따로 있고, 각 URL은 정해진 형태의 데이터를 반환합니다. GraphQL에서는 보통 URL이 하나이며, 호출하는 쪽이 돌려받고 싶은 필드를 정확히 적어 보냅니다. AI로 만드는 대부분의 앱에는 REST가 더 단순하고 나은 기본 선택입니다.

AI로 만들 때 이것이 중요한 이유

AI 빌더에 "백엔드가 있는 앱"을 요청하면, 프런트엔드와 백엔드가 어떻게 통신할지 정해야 합니다. 매번 직접 결정할 필요는 없지만, 코드, 문서, 외부 서비스 연결에서 이 용어들을 보게 됩니다. 어떤 서비스는 한 가지 방식만 제공합니다. 많은 서비스가 REST API를 제공하고, Shopify나 GitHub처럼 GraphQL을 제공하거나 선호하는 서비스도 있습니다. 차이를 알면 지금 보고 있는 것이 무엇인지 이해하고, 필요 없는 복잡성을 더하지 않도록 도움이 됩니다. "API"가 낯설다면 API란 무엇인가부터 읽어 보세요.

일상적인 비유

REST는 식당의 세트 메뉴입니다. 각 요리(엔드포인트)는 주방이 정해 둔 그대로 나옵니다. "고객" 요리를 주문하면 이름만 원해도 이메일, 주소, 가입일이 담긴 접시 전체를 받게 됩니다. 고객의 최근 주문 내역도 필요하다면 그건 또 다른 요리를 주문해야 합니다.

GraphQL은 한 웨이터에게 단품으로 주문하는 방식입니다. 원하는 것을 정확히 적습니다. "고객의 이름과 최근 주문 3건의 날짜 및 합계"처럼요. 주문 한 번, 접시 하나, 요청한 것만 나옵니다. 다만 주방은 고객이 적을 수 있는 모든 조합을 처리할 수 있도록 준비되어 있어야 합니다.

같은 요청을 두 방식으로

고객 페이지에 고객 이름과 최근 주문 3건이 필요하다고 해 봅시다.

REST로 하면 보통 요청 두 개가 필요합니다.

GET /api/customers/42
GET /api/customers/42/orders?limit=3

첫 번째 응답에는 페이지에 필요한 것보다 많은 정보가 들어 있을 수 있습니다.

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

GraphQL로 하면 보통 /graphql 같은 단일 엔드포인트에 쿼리를 담아 POST로 요청 한 번이면 됩니다.

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

응답은 쿼리의 구조를 그대로 따릅니다.

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

두 방식 모두 JSON을 반환합니다. 차이는 응답의 형태를 누가 정하느냐입니다. REST에서는 서버가 정하고, GraphQL에서는 서버 스키마가 허용하는 범위 안에서 호출하는 쪽이 정합니다.

나란히 비교

각 방식이 맞는 곳

REST를 고를 때:

• 예약 시스템, CRM, 대시보드, 쇼핑몰처럼 일반적인 앱을 만들 때.
• 프런트엔드 하나가 백엔드 하나와 통신하고, 둘 다 직접 관리할 때.
• 디버그, 캐시, 보안 적용이 가장 단순한 방식을 원할 때.
• 다른 서비스가 내 앱을 호출할 때(웹훅과 대부분의 연동은 REST 스타일 엔드포인트를 기대합니다).

GraphQL을 고려할 때:

• 웹사이트, 모바일 앱, 파트너 연동처럼 여러 클라이언트가 같은 데이터의 서로 다른 부분을 아주 다르게 필요로 할 때.
• 데이터가 깊게 연결되어 있어서(제품, 변형 상품, 리뷰, 판매자, 재고) 화면마다 여러 방식으로 조합해야 할 때.
• GraphQL을 주된 API로 제공하는 서비스를 사용할 때.

유용한 기준: GraphQL이 꼭 필요한지 확신이 없다면 아마 아직 필요하지 않습니다. 나중에 추가하는 것이 제거하는 것보다 쉽습니다.

핵심 용어

흔한 오해

• "GraphQL은 더 새로우니까 더 낫다." 특정 문제를 해결하기 위한 도구입니다. 프런트엔드가 하나뿐인 단일 앱에서는 큰 이점 없이 작업만 늘리는 경우가 많습니다.
• "GraphQL은 데이터베이스다." 아닙니다. API 계층이며, 그 뒤의 서버는 여전히 데이터베이스에서 데이터를 읽습니다.
• "GraphQL은 항상 더 빠르다." 요청 수가 적으면 느린 모바일 네트워크에서 도움이 될 수 있지만, 제한 없는 쿼리는 방대한 양의 데이터를 불러올 수 있습니다. 성능은 백엔드에 따라 달라집니다.
• "REST는 엄격한 표준이다." 실제로 "REST API"는 리소스 URL, HTTP 메서드, JSON을 느슨하게 뜻합니다. 좋은 API들도 공식 규칙을 많이 벗어납니다.
• "상태 200이면 성공이다." GraphQL에서는 errors 필드를 확인하세요. 요청이 일부만 실패하고도 200을 반환할 수 있습니다.

AI 빌더에 요청할 내용

• "명확한 이유가 없다면 JSON을 쓰는 단순한 REST API를 사용하세요. GraphQL이 필요하다고 생각하면 이유를 설명하세요."
• "모든 엔드포인트, 반환하는 내용, 호출할 수 있는 사람을 나열하세요."
• "고객 페이지에는 페이지가 사용하는 필드만 반환하세요."
• "목록 엔드포인트에 페이지네이션을 추가해서 한 번에 수천 행이 반환되지 않게 하세요."
• "이 서비스는 GraphQL API만 제공합니다. 서버에서 호출하고, 키는 시크릿에 보관하고, 필요한 필드만 요청하세요."
• "올바른 HTTP 상태 코드와 JSON 오류 메시지를 반환하세요."

Mythex의 REST와 GraphQL

Mythex 문서에는 시작 프롬프트가 있는 REST API 백엔드 구축 레시피가 있으며, 백엔드는 웹 앱과 함께 Node, Python(FastAPI), C#, Java에서 실행할 수 있습니다. 문서에는 GraphQL 템플릿에 대한 설명이 없으므로, 필요하다면 명시적으로 요청하고 이유를 밝히세요. 서드파티 GraphQL API 호출은 다른 외부 서비스와 같은 방식으로 작동합니다. 자세한 내용은 API 통합을 참고하세요. 관련 글: 프런트엔드 vs 백엔드와 REST API 만드는 방법.

자주 묻는 질문