개발자 커뮤니티를 눈팅하다가 문득 "진정한 의미의 성능 개선이란 뭘까?"라는 고민을 하게 됐고 그러다 포트폴리오에 적었던 한 문장이 떠올랐다.
"GraphQL 사용으로 REST 대비 API 호출 횟수를 평균 5회 → 1회로 줄임."
그때는 이 부분에 대해 "성능 개선"이라 표현했는데.. 과연 그게 맞는 표현이었을까??
API 호출 횟수 감소 == 성능 개선???
협업 과정에서 GraphQL을 도입하고, 프론트엔드가 GET API 호출 횟수를 줄였다는 것은 프론트엔드에서의 데이터 조합 부담이 줄었다는 뜻이다. (당신들이 바란다면야 열심히 리졸버 만들어주지)
먼저 생각을 말해보자면 성능 개선보다는 프론트엔드 최적화라는 표현이 더 적절했지 않았을까 싶다.. 아니면 프론트엔드의 개발 효율을 개선이라고 표현하던가
왜냐하면 단순 호출 수가 줄었다고 해서 백엔드 비용이나 DB 부하가 줄어든 건 아니기 때문.
네트워크 레벨에서는(특히 모바일 환경이나 느린 네트워크에서) 호출 횟수가 줄어드는 게 확실히 도움이 되겠지만
내부적으로 보면 GraphQL은 한 번에 많은 데이터를 요청하기 때문에 백엔드의 처리 비용이나 DB 접근 횟수는 오히려 늘어날 수도 있다.
그래서 무조건 "성능 개선"이라고 단정짓기는 어렵다고 생각한다.
왜 GraphQL에서 오히려 DB 쿼리가 많아지는데?
예컨대 REST에서는 GET /user, GET /posts, GET /comments로 나눠 받던 데이터를 GraphQL에서는 한 요청으로 한 엔드포인트에서 통합해서 받게 되는데,
이때 N+1 문제나 Nested query로 인해 DB 접근 횟수가 오히려 늘어날 수 있다.
특히 GraphQL은 클라이언트가 요청 구조를 설계하기 때문에 불필요하게 많은 필드나 딥한 네스팅 구조로 인한 성능 병목이 생길 가능성도 있다.
query {
users {
id
name
posts {
id
title
comments {
id
content
createdAt
}
createdAt
}
}
}
[필드마다 개별 resolver 함수가 실행되는 방식]
(페이지네이션 X, DataLoader X라고 가정 – 즉 아무런 최적화 없이 순수하게 리졸버만 사용한 경우)
1. 먼저users리졸버에서 모든 유저를 가져옴 (예: 100명)
2. 각 유저에 대해posts리졸버 실행 → 100번 실행 (유저 수만큼)
3. 각 포스트에 대해comments리졸버 실행 → 포스트 수만큼 실행 (ㄱ-)
이런.. 상상만해도 골이 아프다.. 결국 이렇게 되기 때문에 GraphQL 도입의 결과인 API 호출 횟수 감소가 성능 개선에 직결되는 요소는 아니라는 것
덧붙여서 GraphQL을 도입할 땐 단순히 프론트 편하자고 도입하는 게 아니라 쿼리 성능과 리졸버 구조까지 백엔드에서 함께 고민하고 설계하는 게 중요하다.
그래그래 이건 알았어 그러면 진짜 성능 개선이란 뭘까? 조금 더 본질적인 고민
이건 약간 다른 방향의 고민이긴 한데 "성능 개선" 이라는 단어를 쓰고 싶다면 단편적인 숫자 놀음에서 끝날게 아니라 더 복잡한 관점(비즈니스 목표, 사용자 경험, 개발자 경험 등등등) 에서 바라봐야 하지 않을까?
결국 GraphQL을 도입해서 성능 개선이라고 마냥 생각했던 이번 케이스는 프론트엔드 개발 효율(요청 병합, 프론트엔드 개발자의 개발 경험 등등)이 올라간 것을 핵심으로 마무리 지을 수 있을 것 같다.
그리고 성능 개선에 대한 이야기는 시간내서 포스팅 해볼만 한 것 같다.
다음부터는..
- 단순히 API 호출 수가 줄었다고 해서 쉽게 "성능 개선"이라 표현하지 않기
- 앞으로 이런 케이스일 때는 "프론트엔드 최적화", "개발 효율 개선"이라는 표현을 우선 고려해보기
- 성능 개선을 언급하려면 사용자 체감 or 비즈니스 성과와 연결해서 설명해보기
