GraphQL스러운 코드는 무엇일까? 3편: GraphQL의 철학 이해하기

1편: REST와 GraphQL의 같은 의도와 다른 표현

GraphQL 스러운 코드는 무엇일까? 1편: REST와 GraphQL의 같은 의도와 다른 표현

2편: 다른 표현을 위한 GraphQL에서 요청을 처리하는 방식

GraphQL 스러운 코드는 무엇일까? 2편: 다른 표현을 위한 GraphQL에서 요청을 처리하는 방식

 

Preview 

앞선 글에서는 REST와 GraphQL이 같은 목적을 서로 다른 방식으로 표현한다는 점과, GraphQL 요청이 Schema와 Resolver를 통해 서버 코드로 연결되는 과정을 살펴봤습니다.

지금까지 GraphQL을 친숙하게 느끼는 것에서 시작해 다른 표현에 익숙하는데 집중했다면 이번 글은 이 시리즈의 제목인 GraphQL스럽다는 게 무엇인지, GraphQL을 쓰면 어떤 생각의 변화가 자연스럽게 이뤄지는지 알아보려고 합니다.

 

GraphQL스러운 코드는 무엇일까? 

REST를 그대로 GraphQL 옮긴다면 아래와 같이 나오게 됩니다.

type Query {
  getUserProfile(userId: ID!): UserProfile!
  getUserPosts(userId: ID!): [Post!]!
  getUserFollowers(userId: ID!): [User!]!
}

이것도 GraphQL입니다. 동작도 잘합니다. 그러나 GraphQL스럽지는 않습니다.

기능 단위 API를 Query로 옮겼을 뿐, 데이터 모델을 중심으로 설계하지 않았기 때문입니다.

 

반면 GraphQL스럽게 쓰면 아래와 같습니다. 

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

type User {
    id: ID!
    profile: Profile!
    posts: [Post!]!
    followers: [User!]!
}

 

이 구조에서는 API를 추가하는 것이 아니라 기존 데이터 모델을 확장하게 됩니다.

User는 하나의 화면을 위한 타입이 아닙니다. Profile 화면에서도, Home 화면에서도, 게시글 화면에서도 같은 User를 사용할 수 있습니다.

 

GraphQL에서는 새로운 기능이 생겼을 때 "새로운 Query를 만들까?"보다 "기존 User나 Post에 어떤 관계를 추가하는 것(재사용)이 자연스러울까?"를 먼저 고민하게 됩니다.

공식 문서에서 이야기하는 GraphQL의 지향점: 제품 중심(Product-centric)

GraphQL 공식 문서를 보면 GraphQL은 단순히 새로운 API 문법이나 REST를 대체하기 위한 기술로 소개하지 않습니다.

GraphQL은 클라이언트 애플리케이션을 만들기 위한(Query Language designed to build client applications) 질의 언어라고 설명합니다

 

GraphQL이 추구하는 철학으로 다음과 같은 특징을 제시합니다.

• Product-centric
• Hierarchical
• Strongly typed
• Client-specified response
• Self-documenting

가장 중요한건 제품 중심(Product-centric)으로 서버 내부 구현보다 UX가 필요로 하는 데이터 모델 중심으로 설계가 되게 됩니다.

 

제품 중심이란 말의 뜻

제품 중심이란 말이 좀 추상적으로 느껴집니다. 이 부분을 좀 더 구체적으로 말하면 아래와 같습니다.

GraphQL에서는 REST처럼 엔드포인트를 먼저 설계하기보다, 클라이언트가 탐색할 수 있는 데이터 모델과 관계를 Schema로 표현합니다.

 

REST를 사용할 때는 "API 하나 만들어주세요." 라는 요청이 많았다면,
GraphQL을 사용하면서는

• User에서 couple도 같이 받을 수 있을까요?
• posts 아래에서 commentCount도 선택할 수 있으면 좋겠습니다.

같은 Schema와 데이터 관계에 대한 이야기가 더 많아졌습니다.
물론 REST도 이와 같이 개발을 할 수는 있습니다. 다만 GraphQL을 쓰면 API를 추가하는 것보다 기존 데이터 모델을 어떻게 확장할 것인지에 대한 논의가 좀 더 자연스럽게 됩니다. 

GraphQL은 API를 늘리는 것이 아니라 데이터를 확장하는 방향으로 설계하도록 유도합니다.

GraphQL을 쓰게되면 화면보다 재사용 가능한 타입을 먼저 고민하게 됩니다.

REST API를 설계할 때는 서버가 어떤 API를 제공할지부터 고민하는 경우가 많았습니다. 반면 GraphQL에서는 화면에서 어떤 데이터가 필요한지에 대한 논의가 먼저 시작되는 경우가 많았습니다.

 

GraphQL은 조합을 서버가 아니라 클라이언트에게 넘깁니다.

 

REST에서는

UserDetailResponse
UserPageResponse
HomeResponse

GET /home
{
    "user": ...
    "posts": ...
}

 

가 계속 생깁니다.

GraphQL에서는

User
Post
Comment

 

를 만들고 화면은

query {
    user {
        nickname
    }

    posts {
        title
    }
}

쿼리로 조합해 데이터를 요청합니다.

 

REST에서는 서버가 어떤 화면인지 알고 응답을 조합합니다.

GraphQL에서는 클라이언트가 필요한 화면을 직접 조합합니다.

 

이게 GraphQL다운 설계입니다.

기능을 추가하는 것이 아니라 User라는 데이터 모델을 풍부하게 만드는 방향으로 발전합니다.

그래서 REST는 API를 추가하는 방향으로 생각하게 만들고, GraphQL은 기존 데이터 모델을 어떻게 확장할지 고민하게 만듭니다

결국 GraphQL스럽다는 건 기능(Function)을 먼저 만드는 것이 아니라 데이터(Model)를 먼저 표현하는 것입니다.

REST와 GraphQL은 지향점이 다릅니다. 

지금까지만 보면 REST보다 GraphQL이 뛰어나다고 느낄 수 있는데 그렇진 않습니다. REST도 여전히 강점이 있습니다. 

 

REST는 HTTP의 철학에 충실한 API 구조입니다.

• 리소스를 URL로 식별합니다.
• HTTP Method의 의미를 사용합니다.
• 상태 코드를 응답 의미에 활용합니다.
• ETag, Last-Modified, Cache-Control 같은 HTTP 캐시 기능을 활용합니다.
• 중간 프록시와 CDN이 URL과 HTTP Method를 기준으로 동작할 수 있습니다.

즉 REST는 HTTP가 제공하는 의미(URL, Method, Cache)를 적극적으로 활용하도록 설계되었습니다.

 

그에 반해 GraphQL은 일반적으로 여러 요청이 하나의 /graphql 엔드포인트와 POST 요청으로 전달됩니다. 

POST /graphql

 

이 때문에 CDN이나 브라우저가 일반적인 REST GET 요청처럼 요청의 의미를 바로 파악하고 캐시하기 어렵습니다. 별도의 persisted query, GET 기반 Query, 응답 캐시 전략 등이 필요할 수 있습니다.

또한 파일 다운로드, 정적 리소스, 웹훅, HTTP 리다이렉션처럼 HTTP 자체의 의미가 중요한 API는 REST나 일반 HTTP 엔드포인트가 더 자연스러울 수 있습니다.

 

GraphQL을 이해하는 가장 좋은 방법은 REST를 버리는 것이 아니라, REST와 GraphQL이 각각 어떤 문제를 더 자연스럽게 해결하는지 이해하는 것입니다.

마무리

GraphQL스럽다는 것은 단순히 Query를 사용하는 것이 아니라 Schema 중심, 데이터를 중심으로 사고하는 것입니다.

GraphQL스럽게 설계하면 User, Post, Comment처럼 객체와 관계가 자연스럽게 늘어납니다.

하지만 객체 간 관계를 세밀하게 표현할수록 또 다른 문제가 생깁니다.
User를 조회하면 Post를 조회하고, Post에서 Comment를 조회하고, Comment에서 Author를 조회하는 구조가 만들어질 수 있습니다.
이것이 GraphQL에서 자주 이야기하는 N+1 문제로 이어집니다.

 

GraphQL의 장점은 표현력입니다. 그리고 표현력이 커질수록 그 표현을 효율적으로 실행하는 것이 다음 과제가 됩니다.

다음 글에서는 GraphQL의 표현력을 유지하면서도 성능과 도메인 구조를 어떻게 설계하는지 이야기해보겠습니다.