GraphQL 기초와 REST 비교 완벽 가이드

GraphQL의 핵심 개념부터 REST API와의 차이점까지 초급 개발자가 알아야 할 모든 것을 다룹니다. 실무에서 언제 GraphQL을 선택해야 하는지 명확하게 이해할 수 있습니다.

---

목차

1. GraphQL이란?
2. Query와 Mutation 개념
3. Schema와 Type 정의
4. REST vs GraphQL 비교
5. Over-fetching/Under-fetching 해결
6. GraphQL 사용 시기 판단

---

1. GraphQL이란?

시작하며

여러분이 식당에서 음식을 주문할 때를 상상해보세요. "오늘의 정식"을 시키면 반찬 5개가 나오는데, 정작 여러분은 김치랑 된장찌개만 먹고 싶었던 적 있지 않나요?

나머지 반찬들은 그냥 남기게 되죠. 기존의 REST API도 마찬가지예요.

서버에서 정해진 데이터를 통째로 보내주기 때문에, 필요 없는 데이터도 함께 받아야 했어요. 마치 정식 메뉴처럼요.

바로 이런 불편함을 해결하기 위해 Facebook(현 Meta)에서 2015년에 만든 것이 GraphQL이에요. GraphQL을 사용하면 마치 뷔페처럼 "나는 김치랑 된장찌개만 줘!"라고 정확히 원하는 것만 요청할 수 있답니다.

개요

간단히 말해서, GraphQL은 API를 위한 쿼리 언어예요. 클라이언트가 필요한 데이터의 구조를 직접 정의해서 요청하면, 서버가 정확히 그 구조대로 데이터를 보내주는 방식이죠.

왜 이게 필요할까요? 모바일 앱을 만든다고 생각해보세요.

화면마다 필요한 데이터가 다른데, REST API는 고정된 형태로만 데이터를 줘요. 그래서 어떤 화면에선 데이터가 부족하고, 어떤 화면에선 너무 많은 데이터를 받게 되죠.

GraphQL은 각 화면에 딱 맞는 데이터만 가져올 수 있어서 앱이 더 빨라져요. 기존 REST API에서는 사용자 정보를 가져오려면 /users/1을 호출하고, 그 사용자의 게시글을 가져오려면 다시 /users/1/posts를 호출해야 했어요.

두 번 요청해야 하는 거죠. 하지만 GraphQL에서는 한 번의 요청으로 사용자 정보와 게시글을 동시에 가져올 수 있어요.

GraphQL의 핵심 특징은 세 가지예요. 첫째, 클라이언트가 데이터 구조를 결정해요.

둘째, 하나의 엔드포인트(/graphql)만 사용해요. 셋째, 강력한 타입 시스템이 있어서 어떤 데이터를 요청할 수 있는지 미리 알 수 있어요.

코드 예제

// GraphQL 쿼리 예시 - 원하는 데이터만 정확히 요청
const query = `
  query GetUser {
    user(id: "1") {
      name
      email
      posts {
        title
        createdAt
      }
    }
  }
`;

// fetch로 GraphQL 서버에 요청 보내기
const response = await fetch('/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query })
});

설명

이것이 하는 일: GraphQL 쿼리를 작성하고 서버에 보내서 원하는 데이터만 받아오는 거예요. 첫 번째로, query GetUser라는 쿼리를 정의해요.

이건 마치 "나 사용자 정보 가져올 거야"라고 선언하는 것과 같아요. GetUser는 쿼리의 이름인데, 원하는 대로 지을 수 있어요.

그 다음으로, 중괄호 안에 원하는 데이터 구조를 적어요. user(id: "1")은 "1번 사용자를 찾아줘"라는 뜻이고, 그 안에 name, email, posts를 적으면 이 세 가지 정보만 달라는 거예요.

posts 안에도 title과 createdAt만 적었으니, 게시글의 다른 정보(내용, 좋아요 수 등)는 안 가져와요. 마지막으로, fetch를 사용해서 이 쿼리를 서버에 보내요.

모든 GraphQL 요청은 POST 방식으로 /graphql 하나의 주소로만 보내면 돼요. 서버는 요청받은 구조 그대로 데이터를 JSON으로 돌려줘요.

여러분이 이 방식을 사용하면 네트워크 트래픽을 줄이고, 프론트엔드 개발 속도를 높일 수 있어요. 백엔드 개발자에게 "이 필드 추가해주세요"라고 부탁할 필요도 줄어들죠.

실전 팁

💡 GraphQL은 SQL과 이름이 비슷하지만 데이터베이스 쿼리 언어가 아니에요. API 통신을 위한 언어예요.

💡 모든 GraphQL 요청은 POST 방식을 사용해요. GET은 쿼리 문자열 길이 제한이 있거든요.

💡 GraphQL Playground나 Apollo Studio 같은 도구를 사용하면 쿼리를 쉽게 테스트할 수 있어요.

💡 쿼리 이름(GetUser)은 선택사항이지만, 디버깅할 때 매우 유용하니 항상 붙이는 습관을 들이세요.

---

2. Query와 Mutation 개념

시작하며

여러분이 도서관에 갔다고 상상해보세요. 책을 빌리러 갈 때는 "이 책 좀 보여주세요"라고 하고, 새 회원증을 만들 때는 "회원 등록해주세요"라고 하죠.

하나는 정보를 보는 것이고, 하나는 정보를 바꾸는 것이에요. GraphQL에서도 이 두 가지를 명확하게 구분해요.

데이터를 읽기만 하는 건 Query, 데이터를 생성하거나 수정하거나 삭제하는 건 Mutation이라고 불러요. 이렇게 구분하는 이유가 있어요.

Query는 여러 번 실행해도 결과가 같지만, Mutation은 실행할 때마다 데이터가 바뀌거든요. 마치 책을 보는 건 몇 번을 봐도 책이 그대로지만, 책에 밑줄을 긋는 건 실행할 때마다 밑줄이 늘어나는 것처럼요.

개요

간단히 말해서, Query는 "읽기 전용" 작업이고, Mutation은 "쓰기" 작업이에요. REST API로 비유하면 Query는 GET 요청, Mutation은 POST/PUT/DELETE 요청과 비슷해요.

Query를 사용하는 경우를 생각해볼게요. 사용자 목록 보기, 특정 게시글 상세 보기, 검색 결과 가져오기 등 데이터를 "조회"만 하는 모든 작업이 Query예요.

아무리 많이 실행해도 서버의 데이터는 변하지 않아요. Mutation은 언제 사용할까요?

회원가입, 게시글 작성, 프로필 수정, 댓글 삭제 등 서버의 데이터를 "변경"하는 모든 작업이에요. 한 번 실행하면 데이터베이스에 변화가 생겨요.

중요한 점은 Mutation도 데이터를 반환할 수 있다는 거예요. 예를 들어 게시글을 작성하면, 새로 만들어진 게시글 정보를 바로 받아올 수 있어요.

그래서 "저장 후 새로고침"을 할 필요가 없어지죠.

코드 예제

// Query - 데이터 읽기 (사용자와 게시글 조회)
const GET_USER = `
  query GetUserWithPosts($userId: ID!) {
    user(id: $userId) {
      name
      posts {
        id
        title
      }
    }
  }
`;

// Mutation - 데이터 변경 (새 게시글 작성)
const CREATE_POST = `
  mutation CreatePost($input: PostInput!) {
    createPost(input: $input) {
      id
      title
      createdAt
    }
  }
`;

설명

이것이 하는 일: Query와 Mutation을 사용해서 데이터를 읽고 쓰는 작업을 명확하게 구분하는 거예요. 첫 번째 Query 예시를 볼게요.

query GetUserWithPosts라고 선언하고, $userId라는 변수를 받아요. $가 붙은 건 변수라는 뜻이에요.

ID!에서 느낌표는 "필수값"이라는 의미예요. 이 쿼리는 사용자 정보와 그 사용자의 게시글 목록을 한 번에 가져와요.

두 번째 Mutation 예시를 볼게요. mutation CreatePost로 시작해요.

Query 대신 mutation이라고 쓴 게 보이죠? $input으로 게시글 데이터를 받고, createPost를 실행해요.

그리고 새로 만들어진 게시글의 id, title, createdAt을 바로 돌려받아요. 이렇게 구분하면 코드만 봐도 "이건 읽기 작업이구나", "이건 데이터가 바뀌는 작업이구나"를 바로 알 수 있어요.

팀원들과 협업할 때도 의도가 명확해지고, 실수로 데이터를 바꾸는 일도 줄어들어요.

실전 팁

💡 Query는 동시에 여러 개를 병렬로 실행할 수 있지만, Mutation은 순서대로 하나씩 실행돼요.

💡 Mutation 이름은 동사로 시작하세요. createUser, updatePost, deleteComment처럼요.

💡 Mutation 후에는 변경된 데이터를 반환받아서 화면을 즉시 업데이트하세요. 추가 Query가 필요 없어요.

💡 Query와 Mutation을 헷갈리면 "이 작업을 100번 해도 같은 결과인가?"를 생각해보세요. 같으면 Query예요.

💡 실무에서는 Subscription도 있어요. 실시간 데이터를 받을 때 사용하는데, 이건 나중에 배워도 돼요.

---

3. Schema와 Type 정의

시작하며

레고 블록을 조립할 때 설명서가 있으면 어떤 블록이 어디에 들어가는지 알 수 있죠? GraphQL의 Schema는 바로 그 설명서 역할을 해요.

"우리 API에서는 이런 데이터를 주고받을 수 있어"라고 알려주는 거예요. 만약 설명서 없이 레고를 조립한다고 상상해보세요.

어떤 블록이 있는지도 모르고, 어디에 끼워야 하는지도 모르면 정말 막막하겠죠? 기존 REST API가 그랬어요.

문서를 따로 만들어야 했고, 문서와 실제 API가 달라지는 일도 많았어요. GraphQL Schema는 API의 "계약서" 같은 거예요.

서버와 클라이언트가 "우리는 이 규칙대로 데이터를 주고받자"라고 약속하는 거죠. 이 계약서가 있으면 잘못된 요청을 보내기 전에 미리 알 수 있어요.

개요

간단히 말해서, Schema는 GraphQL API의 청사진이에요. 어떤 타입의 데이터가 있고, 어떤 Query와 Mutation을 사용할 수 있는지 모두 정의해놓은 거죠.

Type은 데이터의 모양을 정의해요. 예를 들어 User 타입에는 id, name, email이 있다고 정의하면, User를 요청할 때 이 세 가지 필드만 요청할 수 있어요.

없는 필드를 요청하면 에러가 나요. GraphQL에는 기본 타입들이 있어요.

String(문자열), Int(정수), Float(소수), Boolean(참/거짓), ID(고유 식별자)가 그것이에요. 이 기본 타입들을 조합해서 우리만의 타입을 만들어요.

느낌표(!)는 "필수"라는 뜻이에요. String!이라고 쓰면 이 필드는 절대 null이 될 수 없다는 거예요.

대괄호([])는 배열을 의미해요. [Post]!는 "Post의 배열인데, 배열 자체는 null이 아니다"라는 뜻이에요.

코드 예제

// GraphQL Schema 정의 예시
const typeDefs = `
  type User {
    id: ID!
    name: String!
    email: String!
    age: Int
    posts: [Post!]!
  }

  type Post {
    id: ID!
    title: String!
    content: String!
    author: User!
  }

  type Query {
    user(id: ID!): User
    users: [User!]!
    post(id: ID!): Post
  }

  type Mutation {
    createUser(name: String!, email: String!): User!
  }
`;

설명

이것이 하는 일: GraphQL API에서 사용할 수 있는 모든 데이터 타입과 작업을 정의하는 거예요. 먼저 type User를 보세요.

User라는 데이터 타입을 만들었어요. id는 ID!니까 필수 고유 식별자, name과 email은 필수 문자열이에요.

age는 Int인데 느낌표가 없으니 null일 수 있어요. posts는 [Post!]!인데, 이건 "Post 배열이고, 배열 안의 각 Post도 null이 아니고, 배열 자체도 null이 아니다"라는 뜻이에요.

type Post는 User와 연결되어 있어요. author: User!를 보면 Post의 작성자는 User 타입이에요.

이렇게 타입끼리 연결할 수 있어서 관계형 데이터를 표현하기 좋아요. type Query와 type Mutation은 특별해요.

이 두 타입에 정의된 것들만 클라이언트가 요청할 수 있어요. user(id: ID!) 는 id를 받아서 User를 반환하는 쿼리예요.

이 Schema 덕분에 개발자 도구가 자동완성을 제공하고, 잘못된 쿼리는 실행 전에 에러를 잡아줘요. 문서를 따로 안 써도 Schema 자체가 문서 역할을 해요.

실전 팁

💡 느낌표 위치에 주의하세요. [Post]!와 [Post!]와 [Post!]!는 모두 다른 의미예요.

💡 Schema는 백엔드 개발자가 먼저 정의하고, 프론트엔드 개발자는 이를 보고 쿼리를 작성해요.

💡 GraphQL Playground에서 오른쪽 Docs 탭을 열면 Schema를 탐색할 수 있어요.

💡 커스텀 스칼라 타입(DateTime, Email 등)을 만들어서 더 정확한 타입을 정의할 수도 있어요.

💡 Schema는 점진적으로 확장하세요. 처음부터 완벽하게 설계하려 하지 말고, 필요할 때 추가해요.

---

4. REST vs GraphQL 비교

시작하며

여러분이 친구 집에 놀러 간다고 해볼게요. REST API는 마치 친구가 "거실 구경해", "주방 구경해", "방 구경해"라고 방마다 따로따로 안내하는 것과 같아요.

GraphQL은 "어디 보고 싶어?"라고 물어보고 여러분이 "거실이랑 주방만"이라고 하면 그것만 보여주는 거예요. 둘 다 집을 구경하는 목적은 같지만 방식이 다르죠?

REST API는 10년 넘게 업계 표준으로 사용되어 왔고, 지금도 대부분의 서비스에서 사용해요. GraphQL은 2015년에 등장해서 특정 상황에서 REST의 한계를 극복하기 위해 만들어졌어요.

어떤 게 더 좋다고 말하기는 어려워요. 상황에 따라 맞는 도구가 다르거든요.

드라이버와 망치 중에 뭐가 더 좋냐고 물으면 대답하기 어려운 것처럼요.

개요

간단히 말해서, REST는 URL로 자원을 구분하고, GraphQL은 쿼리로 원하는 데이터를 명시해요. REST API의 특징을 볼게요.

각 자원마다 URL이 있어요(/users, /posts, /comments). HTTP 메서드(GET, POST, PUT, DELETE)로 행동을 구분해요.

응답 구조가 서버에서 정해져 있어요. 이 방식은 단순하고 이해하기 쉬워서 오랫동안 사랑받았어요.

GraphQL의 특징은요? 단 하나의 URL(/graphql)만 사용해요.

클라이언트가 쿼리로 원하는 데이터 구조를 직접 지정해요. 여러 자원을 한 번에 요청할 수 있어요.

강력한 타입 시스템이 기본 제공돼요. 실무에서 느끼는 가장 큰 차이는 유연성이에요.

REST에서 새 필드가 필요하면 백엔드에 요청해야 하지만, GraphQL은 Schema에 있기만 하면 프론트엔드에서 바로 사용할 수 있어요.

코드 예제

// REST API 방식 - 여러 번 요청 필요
const user = await fetch('/api/users/1').then(r => r.json());
const posts = await fetch('/api/users/1/posts').then(r => r.json());
const followers = await fetch('/api/users/1/followers').then(r => r.json());
// 총 3번의 요청, 불필요한 데이터도 포함될 수 있음

// GraphQL 방식 - 한 번에 필요한 것만
const query = `
  query {
    user(id: "1") {
      name
      posts { title }
      followers { name }
    }
  }
`;
const result = await fetch('/graphql', {
  method: 'POST',
  body: JSON.stringify({ query })
}).then(r => r.json());
// 1번의 요청, 필요한 데이터만 포함

설명

이것이 하는 일: 같은 데이터를 REST와 GraphQL로 각각 어떻게 가져오는지 비교해요. REST 방식을 먼저 볼게요.

사용자 정보, 게시글 목록, 팔로워 목록을 가져오려면 세 개의 다른 URL로 세 번 요청해야 해요. 각 응답에는 우리가 필요 없는 데이터도 포함될 수 있어요.

예를 들어 사용자 정보에서 이름만 필요한데, 주소, 전화번호, 가입일 등 모든 정보가 다 와요. GraphQL 방식은 달라요.

하나의 쿼리에 사용자의 name, 게시글의 title, 팔로워의 name만 정확히 지정했어요. 한 번의 요청으로 세 가지 데이터를 가져오고, 딱 필요한 필드만 응답에 포함돼요.

네트워크 요청 횟수가 3번에서 1번으로 줄었어요. 모바일 환경처럼 네트워크가 느린 곳에서는 이 차이가 크게 느껴져요.

데이터 전송량도 줄어들어서 더 빠르게 화면을 보여줄 수 있어요. 하지만 REST가 나쁜 건 아니에요.

간단한 CRUD 작업이나, 캐싱이 중요한 경우, 파일 업로드 등에서는 REST가 더 적합할 수 있어요.

실전 팁

💡 REST는 HTTP 캐싱을 기본 지원하지만, GraphQL은 별도의 캐싱 전략이 필요해요.

💡 팀에 GraphQL 경험자가 없다면 학습 비용을 고려하세요. REST가 진입장벽이 더 낮아요.

💡 GraphQL이라고 무조건 빠른 게 아니에요. 복잡한 쿼리는 서버에 부담을 줄 수 있어요.

💡 두 가지를 섞어 쓸 수도 있어요. 기존 REST API 위에 GraphQL 레이어를 얹는 방식이요.

💡 API 소비자가 다양하다면(웹, 앱, 외부 개발자) GraphQL이 유리할 수 있어요.

---

5. Over-fetching/Under-fetching 해결

시작하며

마트에 장을 보러 갔는데, 우유 하나만 필요한데 우유+계란+빵 세트로만 판다면 어떨까요? 필요 없는 것까지 사야 하니 돈이 아깝겠죠?

이게 바로 Over-fetching이에요. 필요한 것보다 더 많은 데이터를 받는 거예요.

반대로 우유를 샀는데 뚜껑이 따로 판매된다면요? 우유를 마시려면 또 뚜껑을 사러 가야 해요.

이게 Under-fetching이에요. 한 번에 필요한 데이터를 다 못 받아서 추가 요청을 해야 하는 거죠.

REST API를 사용하다 보면 이 두 가지 문제를 정말 자주 겪어요. 특히 여러 화면에서 같은 API를 사용할 때 심해져요.

어떤 화면에선 데이터가 남고, 어떤 화면에선 부족하고. GraphQL은 이 문제를 근본적으로 해결해줘요.

개요

간단히 말해서, Over-fetching은 안 쓸 데이터까지 받는 것, Under-fetching은 필요한 데이터를 다 못 받아서 추가 요청하는 것이에요. Over-fetching의 실제 예를 볼게요.

사용자 목록 화면에서 이름과 프로필 사진만 보여주면 되는데, /users API가 사용자의 모든 정보(이메일, 주소, 전화번호, 가입일, 최근 접속일 등)를 다 보내줘요. 모바일에서 이런 불필요한 데이터 전송은 배터리와 데이터 요금을 낭비해요.

Under-fetching의 예도 볼게요. 사용자 프로필 화면에서 사용자 정보와 최근 게시글 3개를 보여줘야 해요.

REST API에서는 먼저 /users/1을 호출하고, 그 다음 /users/1/posts?limit=3을 호출해야 해요. 두 번째 요청은 첫 번째가 끝나야 시작할 수 있어서 시간이 더 걸려요.

GraphQL에서는 쿼리를 작성할 때 필요한 필드만 정확히 지정하니까 Over-fetching이 없어요. 그리고 관련 데이터를 한 쿼리에 다 담을 수 있으니 Under-fetching도 없어요.

코드 예제

// REST의 Over-fetching 문제
// 이름만 필요한데 모든 정보가 옴
const response = await fetch('/api/users/1');
// 결과: { id, name, email, phone, address, birthdate, ... }

// REST의 Under-fetching 문제
// 두 번 요청해야 함
const user = await fetch('/api/users/1');
const posts = await fetch('/api/users/1/posts');

// GraphQL로 해결 - 딱 필요한 것만 한 번에
const query = `
  query GetUserProfile($id: ID!) {
    user(id: $id) {
      name
      profileImage
      posts(limit: 3) {
        title
        thumbnail
      }
    }
  }
`;

설명

이것이 하는 일: REST에서 발생하는 데이터 낭비와 추가 요청 문제를 GraphQL이 어떻게 해결하는지 보여줘요. 첫 번째 REST 예시는 Over-fetching이에요.

/api/users/1을 호출하면 서버가 사용자의 모든 정보를 보내요. 화면에 이름만 표시할 건데 이메일, 전화번호, 주소까지 다 받아야 해요.

데이터 양이 많아지면 로딩 시간도 길어져요. 두 번째 REST 예시는 Under-fetching이에요.

프로필 화면을 그리려면 사용자 정보도 필요하고 게시글도 필요해요. 두 개의 API를 따로 호출해야 하고, 보통 순차적으로 호출하니까 총 로딩 시간이 늘어나요.

화면이 복잡해질수록 API 호출 횟수가 늘어나요. GraphQL 해결책을 보세요.

하나의 쿼리에 name, profileImage, posts(limit: 3)을 다 적었어요. posts도 title과 thumbnail만 가져와요.

한 번의 요청으로 필요한 모든 데이터를, 필요한 필드만 정확히 받아요. 실제 서비스에서 이 차이는 크게 느껴져요.

특히 모바일 앱이나 느린 네트워크 환경에서 사용자 경험이 확 달라져요.

실전 팁

💡 프론트엔드 화면별로 어떤 데이터가 필요한지 먼저 정리하고, 그에 맞는 쿼리를 작성하세요.

💡 너무 많은 데이터를 한 쿼리에 담으면 오히려 느려질 수 있어요. 적절히 나누세요.

💡 Persisted Queries를 사용하면 쿼리 문자열을 매번 보내지 않아도 돼서 더 효율적이에요.

💡 DataLoader 같은 도구를 사용하면 서버에서 N+1 문제도 해결할 수 있어요.

---

6. GraphQL 사용 시기 판단

시작하며

망치가 좋은 도구라고 해서 모든 문제를 망치로 해결할 순 없잖아요? GraphQL도 마찬가지예요.

정말 좋은 도구지만, 모든 상황에 GraphQL이 정답은 아니에요. "요즘 GraphQL이 핫하다던데, 우리 프로젝트도 도입해야 하지 않을까?"라는 생각이 들 수 있어요.

하지만 잠깐! 먼저 우리 프로젝트에 GraphQL이 정말 필요한지 생각해봐야 해요.

기술 선택은 트렌드를 따라가는 게 아니라, 문제를 해결하기 위한 거예요. GraphQL이 해결하는 문제가 우리 프로젝트에 있는지, 도입 비용 대비 이점이 있는지 따져봐야 해요.

개요

간단히 말해서, 복잡한 데이터 요구사항이 있고, 클라이언트가 다양하며, 팀이 GraphQL을 학습할 여유가 있을 때 도입하면 좋아요. GraphQL이 빛나는 상황들이 있어요.

첫째, 모바일 앱과 웹이 같은 백엔드를 쓰는데 필요한 데이터가 다를 때예요. 둘째, 화면마다 필요한 데이터 조합이 많이 다를 때예요.

셋째, 프론트엔드와 백엔드 팀이 분리되어 있고, 서로 독립적으로 개발하고 싶을 때예요. 반면 REST가 더 나은 상황도 있어요.

간단한 CRUD 작업만 있을 때, 파일 업로드가 주요 기능일 때, HTTP 캐싱이 매우 중요할 때, 팀원 대부분이 GraphQL 경험이 없을 때예요. 도입 비용도 고려해야 해요.

서버 구축, Schema 설계, 클라이언트 라이브러리 설정, 팀 교육 등 초기 투자가 필요해요. 작은 프로젝트에서는 이 비용이 부담될 수 있어요.

코드 예제

// GraphQL 도입 체크리스트 - 코드로 표현
const shouldUseGraphQL = {
  // 이런 상황이면 GraphQL 고려
  goodFit: [
    '여러 클라이언트(웹, 앱, 외부 API)가 같은 백엔드 사용',
    '화면마다 필요한 데이터 조합이 자주 바뀜',
    'Over-fetching으로 성능 문제 발생',
    '프론트엔드가 백엔드 변경 없이 유연하게 개발하고 싶음',
    '복잡한 관계형 데이터를 자주 조회'
  ],

  // 이런 상황이면 REST 유지
  stickWithREST: [
    '단순한 CRUD 위주의 API',
    '파일 업로드/다운로드가 주요 기능',
    'HTTP 캐싱이 매우 중요',
    '팀에 GraphQL 경험자가 없음',
    '빠른 MVP 출시가 목표'
  ]
};

설명

이것이 하는 일: GraphQL 도입 여부를 결정할 때 고려해야 할 요소들을 정리해요. goodFit 배열을 먼저 볼게요.

웹과 모바일 앱이 같은 API를 쓰는데 필요한 데이터가 다르다면 GraphQL이 좋아요. 화면별로 REST 엔드포인트를 만들 필요 없이 각자 원하는 데이터만 요청하면 되니까요.

복잡한 관계형 데이터(사용자→게시글→댓글→좋아요)를 자주 조회한다면 GraphQL의 중첩 쿼리가 유용해요. stickWithREST 배열도 볼게요.

게시판처럼 단순한 CRUD만 있다면 REST가 더 간단해요. 이미지나 동영상 업로드가 주요 기능이라면 REST가 낫고요.

팀에 GraphQL 경험자가 없다면 학습 시간을 고려해야 해요. 결국 "우리 프로젝트의 문제가 뭔가?"를 먼저 파악해야 해요.

Over-fetching이나 Under-fetching으로 성능 문제가 있다면 GraphQL이 답일 수 있어요. 하지만 그런 문제가 없다면 굳이 바꿀 필요 없어요.

새 프로젝트를 시작한다면, 처음엔 REST로 빠르게 만들고, 필요성이 생기면 그때 GraphQL을 도입하는 것도 좋은 전략이에요.

실전 팁

💡 "GraphQL이 좋다더라"가 아니라 "우리에게 필요한가?"를 먼저 물어보세요.

💡 작은 부분에 먼저 적용해보고, 효과가 있으면 확대하세요. 한꺼번에 전환하지 마세요.

💡 BFF(Backend For Frontend) 패턴으로 REST 백엔드 위에 GraphQL 레이어를 얹을 수도 있어요.

💡 Apollo, Relay 같은 클라이언트 라이브러리의 학습 비용도 고려하세요.

💡 팀원들과 충분히 논의하고, 작은 PoC(Proof of Concept)를 먼저 해보세요.

---