GraphQL vs REST, 3개 프로젝트 해보고 내린 결론

첫 번째 프로젝트: GraphQL에 반하다

2024년, 사내 어드민 대시보드를 만들 때 GraphQL을 처음 도입했다. 프론트에서 필요한 데이터만 골라서 요청할 수 있다는 게 매력적이었다. REST였으면 유저 정보에 주문 내역에 배송 상태까지 3개 API를 따로 호출했을 텐데, GraphQL은 쿼리 하나로 끝이었다.

Apollo Client의 캐시도 좋았다. 같은 데이터를 다시 요청하면 네트워크 없이 바로 가져왔다. 초기 세팅에 3일 걸렸지만 그 이후로는 개발 속도가 꽤 빨랐다.

여기까지는 좋은 얘기다

문제는 스키마 관리였다. 백엔드 개발자가 스키마를 바꾸면 프론트에서 쿼리를 같이 수정해야 하는데, 이 동기화가 안 맞는 경우가 생겼다. type-safe하다고 했는데 런타임에 에러가 터지면 그게 type-safe인가.

그리고 N+1 문제. 관련 데이터를 자유롭게 요청할 수 있으니까 프론트에서 깊은 중첩 쿼리를 날렸고, 백엔드 DB에서 쿼리가 147개 나간 적이 있다. DataLoader를 넣어서 해결했지만 디버깅에 하루가 갔다.

(147개라니. 프론트에서 자유도가 높으면 이런 일이 생긴다.)

두 번째 프로젝트: REST로 돌아가다

다음 프로젝트는 팀원이 6명으로 늘었고 백엔드와 프론트 역할이 분리됐다. GraphQL을 또 쓰려고 했는데 백엔드 팀에서 반대했다. "REST가 익숙한데 굳이 왜?" 라는 반응.

결국 REST로 갔다. 처음엔 좀 답답했다. 필요 없는 필드까지 내려오는 over-fetching이 신경 쓰였고, 화면 하나 그리려면 API를 3-4개 호출해야 했다.

근데 솔직히 개발 속도는 REST가 더 빨랐다. Swagger 문서 하나면 프론트-백 커뮤니케이션이 충분했고, 에러 추적도 간단했다. HTTP 상태 코드만 보면 됐으니까.

세 번째 프로젝트: 선택적으로 쓰다

세 번째에서는 둘 다 썼다. 메인 CRUD는 REST로, 대시보드처럼 여러 리소스를 한 번에 보여줘야 하는 화면만 GraphQL로. BFF(Backend for Frontend) 패턴이라고 부르는 건데, 이게 제일 현실적이었다.

대신 복잡도가 올라갔다. 두 가지 패턴을 동시에 관리해야 하니까 신규 팀원 온보딩 시간이 1.5배로 늘었다.

결론이라고 하기엔 좀 그렇지만

팀이 작고 프론트-백 같이 하면 GraphQL이 생산성 좋다. 팀이 크고 역할이 분리돼 있으면 REST가 커뮤니케이션 비용이 낮다. 대시보드처럼 데이터를 많이 조합해야 하면 GraphQL이 맞고, 단순 CRUD 위주면 REST가 맞다.

근데 현실에서는 프로젝트 특성보다 팀의 경험치가 더 중요한 것 같다. GraphQL을 아는 사람이 있으면 GraphQL, 없으면 REST. 기술 선택의 현실이 이렇다.