이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 GraphQL을 처음으로 적용해본 경험이 있습니다. REST API를 사용할 때 화면마다 필요한 필드가 달라 오버페칭이 발생하거나, 반대로 여러 엔드포인트를 호출해야 하는 언더페칭 문제가 있었습니다. GraphQL의 가장 큰 장점은 클라이언트가 필요한 필드만 명시할 수 있어 네트워크 비용을 줄일 수 있다는 점이었습니다.
스키마 타입 정의가 백엔드와 프론트엔드 간 계약 역할을 해서, 타입 기반 자동 완성이 되는 개발 경험이 REST보다 편리했습니다. 리졸버 설계에서 N+1 쿼리 문제를 처음 겪었는데, DataLoader 패턴으로 배치 처리해 해결했습니다. 한계는 REST보다 초기 설정이 복잡하고, 간단한 CRUD에서는 오히려 REST가 더 빠를 수 있다는 점입니다. GraphQL은 다양한 클라이언트가 같은 데이터를 다르게 필요로 할 때 진가를 발휘한다는 결을 얻었습니다.
GraphQL을 도입하면서 N+1 쿼리 문제가 생각보다 자주 발생하는 결이 있었습니다. REST API에서는 백엔드가 데이터를 한 번에 조회해 내려주는데, GraphQL은 각 필드 리졸버가 독립적으로 실행되는 구조라 중첩 데이터를 조회할 때 쿼리가 폭발적으로 늘어나는 경우가 있었습니다.
DataLoader 패턴으로 배치 처리해 해결했지만, 이 패턴을 적용하는 것 자체가 추가 복잡도가 됐습니다. 또한 GraphQL 쿼리가 임의로 깊어질 수 있어 악의적인 요청이 서버에 과부하를 줄 수 있는 결도 고려해야 했습니다. GraphQL은 클라이언트 편의를 높이는 만큼 서버 사이드 복잡도가 올라가는 결이 있다는 것을 이 경험에서 배웠습니다.
GraphQL을 처음 설계할 때 스키마 구조를 빠르게 잡다가 나중에 변경 비용이 커지는 경험을 했습니다. 초기에 타입과 필드를 직관적으로 잡았는데, 기능이 추가되면서 기존 타입이 맞지 않는 케이스가 생겼습니다. GraphQL 스키마는 클라이언트가 이미 사용 중인 필드를 쉽게 제거하거나 이름을 바꾸기 어려운 결이 있었습니다. Deprecate하고 새 필드를 추가하는 방식으로 마이그레이션했는데, 오래된 필드와 새 필드가 혼재하는 기간이 생겼습니다. 이 경험에서 GraphQL 스키마는 한 번 쓰이면 수정 비용이 큰 결이 있다는 것을 배웠습니다.
처음 설계 시 도메인 모델을 충분히 검토하는 것이 나중 비용을 줄이는 결이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.