정지용
기술스택 목록
도구

GraphQL

프로젝트 2에서 사용했습니다. 각 프로젝트에서 어떤 역할로 썼는지 아래에 정리했습니다.

이 기술은 무엇인가요?

클라이언트가 필요한 데이터만 정확히 요청할 수 있게 하는 API 쿼리 언어이자 런타임

GraphQL은 서버가 제공하는 데이터의 타입과 관계를 스키마로 정의하고, 클라이언트가 이 스키마를 기반으로 필요한 필드만 골라 요청할 수 있게 하는 API 쿼리 언어입니다. REST에서 흔한 오버페칭(불필요한 데이터까지 받는 것)과 언더페칭(부족해서 여러 번 요청하는 것) 문제를 해결하기 위해 만들어졌습니다. 하나의 엔드포인트로 조회(query), 변경(mutation), 실시간 구독(subscription)을 모두 처리할 수 있고, 스키마 자체가 API 문서 역할을 하며 코드 생성 도구와 연동해 타입 안전성을 확보하는 데도 많이 활용됩니다.

이럴 때 사용합니다

  • 화면마다 필요한 데이터 형태가 달라 REST 엔드포인트가 파편화될 때
  • 프런트엔드-백엔드 간 타입 안전한 API 계약과 자동 코드 생성이 필요할 때
  • 여러 리소스를 한 번의 요청으로 조합해 가져와야 할 때
  • API 스키마 자체를 문서 겸 계약으로 팀 간에 공유하고 싶을 때

핵심 개념

Schema
서버가 제공하는 타입, 필드, 관계를 정의한 명세로, 클라이언트가 어떤 데이터를 어떻게 요청할 수 있는지의 계약 역할을 합니다.
Query
데이터를 조회하기 위한 요청으로, 클라이언트가 필요한 필드만 선택해 서버에 전달합니다.
Mutation
데이터를 생성·수정·삭제하는 등 서버 상태를 변경할 때 사용하는 요청 타입입니다.
Resolver
스키마에 정의된 각 필드의 실제 값을 어떻게 가져올지 구현하는 서버 측 함수입니다.
Codegen
스키마 정의로부터 클라이언트 코드의 타입이나 훅을 자동으로 생성해 API 연동의 타입 안전성을 높이는 도구입니다.

기본 스키마와 쿼리 예시

User 타입과 조회 쿼리를 스키마로 정의하고, 클라이언트는 필요한 필드(name, email)만 선택해 요청합니다.

예시
# 스키마 정의
type User {
  id: ID!
  name: String!
  email: String!
}

type Query {
  user(id: ID!): User
}

# 클라이언트가 보내는 쿼리
query GetUser {
  user(id: "1") {
    name
    email
  }
}

처음 쓸 때 흔한 함정

  • GET/POST 같은 REST 캐싱 방식이 그대로 통하지 않아 별도 캐싱 전략이 필요합니다.
  • 중첩 쿼리를 잘못 설계하면 리졸버가 과도하게 호출되는 N+1 문제가 발생할 수 있습니다.
  • 스키마 변경이 여러 클라이언트에 영향을 주므로 필드 폐기(deprecation) 관리가 중요합니다.

위 개요는 기술 학습을 돕기 위해 자동 생성된 일반 설명입니다. 정확한 사양과 최신 정보는 공식 문서를 확인하세요.

프로젝트별 활용 방식

위 개념이 실제 프로젝트에서 어떻게 쓰였는지 보여줍니다.

함께 사용한 기술

위 프로젝트들에서 같이 쓰인 다른 기술입니다.