안녕하세요, 여러분. 15년 차 백엔드 개발자이자, 주말에는 기술 서적을 집필하며 커피를 사랑하는 여러분의 멘토입니다. 오늘은 우리가 흔히 겪는 API 개발의 고질적인 문제, 바로 '데이터 비만'과 그 치료법에 대해 깊이 있게 이야기해보려 합니다. 혹시 프론트엔드 개발자 동료에게 "화면에는 사용자 이름만 나오면 되는데 왜 주민등록번호부터 혈액형, 가입 로그까지 다 보내주나요?"라는 불평을 들어보신 적 있으신가요? 혹은 모바일 앱 로딩 속도가 느려 터져서, 네트워크 탭을 열어보니 수 메가바이트짜리 JSON 덩어리가 날아오고 있는 끔찍한 광경을 목격한 적은요? 네, 저도 압니다. 그 심정, 정말 뼈저리게 잘 알죠.
이것이 바로 REST API의 대표적인 병폐인 '오버페칭(Over-fetching)'입니다. 마치 뷔페에 가서 김밥 한 줄만 먹고 싶은데, 입장료를 다 내고 100가지 음식을 강제로 접시에 담아오는 것과 같습니다. 이는 서버 리소스 낭비일 뿐만 아니라, 사용자 경험을 해치는 주범입니다. 오늘은 이 문제를 해결하기 위해, 페이스북(Meta)이 만들고 아폴로(Apollo)가 꽃피운 그래프QL(GraphQL)의 세계로 여러분을 안내하려 합니다. 단순히 "어떻게 쓰냐"를 넘어, "왜 이렇게 설계되었고, 실무에서 어떻게 최적화하여 성능을 200% 끌어올리는지" 그 깊은 원리를 파헤쳐 드리겠습니다. 커피 한 잔 딱 준비하시고, 시작해볼까요? ☕
1. REST API의 한계: 왜 우리는 고통받는가?
우리가 10년 넘게 사랑해온 REST API는 리소스 중심의 훌륭한 아키텍처입니다. 하지만 모바일 시대와 복잡한 프론트엔드 요구사항이 폭발적으로 증가하면서 그 한계가 명확해졌습니다. 제가 5년 전 대규모 이커머스 프로젝트를 리딩할 때의 일입니다. 상품 상세 페이지를 띄우는데 API 호출이 무려 8번이나 일어났고, 그중 절반 이상의 데이터는 화면에 쓰이지도 않았습니다. 결과는 참담했습니다. 사용자는 로딩 스피너만 3초 동안 바라봐야 했고, 이탈률은 45%까지 치솟았습니다. 이 경험은 저에게 API 효율성에 대한 깊은 고민을 안겨주었습니다.
오버페칭(Over-fetching): 필요 없는 데이터의 습격
오버페칭은 클라이언트가 실제로 필요한 것보다 더 많은 데이터를 서버로부터 받는 현상을 말합니다. 예를 들어, 모바일 앱의 사용자 프로필 카드에는 '닉네임'과 '아바타 이미지' 두 가지 정보만 있으면 됩니다. 그런데 REST API의 `/users/1` 엔드포인트를 호출하면 서버는 이메일, 주소, 가입일, 포인트 내역, 친구 목록 등 데이터베이스에 있는 사용자 테이블의 모든 컬럼을 JSON으로 직렬화해서 던져줍니다. 실제로 제가 분석했던 한 프로젝트에서는 화면에 필요한 데이터는 2KB였지만, 실제 응답 크기는 150KB에 달했습니다. 무려 75배의 데이터 낭비가 발생하고 있었던 것이죠.
이게 왜 심각한 문제일까요? 첫째, 네트워크 대역폭 낭비입니다. 5G 시대라고 하지만, 불안정한 네트워크 환경에서 1KB와 100KB의 차이는 체감 속도에서 엄청난 격차를 만듭니다. 둘째, 클라이언트 메모리 및 배터리 소모입니다. 쓰지도 않을 데이터를 파싱하고 메모리에 들고 있어야 하므로 저사양 기기에서는 앱이 버벅거릴 수 있습니다. 셋째, 보안 이슈입니다. 개발자의 실수로 민감한 개인정보나 내부 관리용 키값이 프론트엔드로 노출될 가능성이 높아집니다. 실제로 비밀번호 해시값이나 관리자 메모가 API 응답에 포함되어 나가는 보안 사고는 생각보다 빈번합니다.
언더페칭(Under-fetching): 여러 번 호출의 지옥
반대 상황인 언더페칭 또한 고통스럽습니다. 언더페칭은 하나의 엔드포인트가 충분한 데이터를 주지 못해, 추가적인 API 호출을 연쇄적으로 해야 하는 상황입니다. 블로그 포스트를 예로 들어보죠. `/posts`를 호출해서 글 목록을 가져왔습니다. 그런데 각 글의 작성자 정보가 필요해서 `/users/{id}`를 글 개수(N)만큼 호출해야 하고, 댓글 미리보기를 위해 `/posts/{id}/comments`를 또 호출해야 합니다. 이를 'N+1 문제'라고도 부르는데, HTTP 요청 오버헤드와 네트워크 레이턴시(지연 시간)가 누적되어 전체 로딩 속도를 끔찍하게 만듭니다.
💡 시니어의 통찰:
REST API에서는 이 문제를 해결하기 위해 보통 '맞춤형 엔드포인트'를 만듭니다. `/posts-with-author-and-comments` 같은 괴물 같은 URL이 탄생하죠. 하지만 화면 기획이 조금만 바뀌어도 백엔드 개발자는 또 새로운 API를 만들어야 합니다. 이것이 바로 백엔드 개발자의 야근 주범이자 생산성 저하의 핵심 원인입니다. 유지보수성은 바닥을 치게 됩니다.
2. REST vs GraphQL: 한눈에 보는 비교 분석
백문이 불여일견입니다. REST API와 GraphQL(Apollo)이 어떻게 다른지, 왜 GraphQL이 오버페칭의 해결사인지 명확한 비교표를 통해 확인해보겠습니다. 이 표를 이해하면 기술 도입을 위한 설득 근거로도 활용하실 수 있습니다.
| 비교 항목 |
REST API |
GraphQL (Apollo) |
| 데이터 요청 방식 |
서버가 정의한 고정된 구조 수신 |
클라이언트가 필요한 필드만 쿼리 |
| 엔드포인트 |
리소스별 다수 존재 (/users, /posts) |
단일 엔드포인트 (/graphql) |
| 오버/언더페칭 |
빈번하게 발생 (구조적 한계) |
구조적으로 완벽하게 해결 |
| API 문서화 |
Swagger 등 별도 도구 필요 및 동기화 어려움 |
스키마 자체가 문서 (Self-documenting) |
| 버전 관리 |
v1, v2 등 URL 변경 필요 |
버전 없이 필드 추가/Deprecated로 관리 |
3. 구원투수 등판: 아폴로(Apollo)와 스키마의 미학
그래프QL은 "클라이언트가 필요한 데이터를 정확히 명시해서 요청한다"는 철학을 가지고 있습니다. 쿼리 언어(Query Language)라는 이름처럼, 마치 SQL을 짜듯이 서버에 데이터를 요청하는 것이죠. 그리고 아폴로(Apollo) 서버는 이 그래프QL을 가장 쉽고 강력하게 구현할 수 있게 해주는 업계 표준 라이브러리입니다. 아폴로는 단순한 서버
댓글
댓글 쓰기