이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
전공 수업과 PM 공부를 통해 RESTful API와 GraphQL의 차이를 이해했습니다. REST는 리소스별로 엔드포인트가 고정돼 있어 클라이언트가 여러 엔드포인트를 호출해야 하는 오버패칭·언더패칭 문제가 생길 수 있습니다. GraphQL은 단일 엔드포인트에 쿼리를 보내 필요한 데이터만 가져오는 구조라 클라이언트 측 유연성이 높습니다. 토이 프로젝트에서 REST를 쓸 때는 화면마다 다른 데이터 조합이 필요해 API 호출이 3~4번 중첩됐고, GraphQL로 바꾼 뒤 호출 수가 줄었습니다. 단점으로는 GraphQL은 캐싱 전략이 복잡하고 초기 설계 비용이 높다는 점이 있습니다. PM으로서 중요한 것은 어느 쪽이 더 좋다는 판단보다 데이터 소비 패턴과 팀의 경험치에 따라 선택이 달라진다는 맥락을 이해하는 것이라고 생각합니다.
REST와 GraphQL을 비교하며 제가 또 본 건 캐싱과 복잡도의 차이입니다. REST는 엔드포인트별 캐싱이 간단하지만, 오버패칭·언더패칭이 생겼습니다. GraphQL은 필요한 데이터만 가져와 유연하지만, 단일 엔드포인트라 캐싱 전략이 복잡하고 초기 설계 비용이 높았습니다. 토이 프로젝트에서, 화면마다 다른 데이터 조합이 필요해 REST 호출이 3~4번 중첩됐는데, GraphQL로 바꾸니 호출 수가 줄었습니다. 막연히 '뭐가 좋다'가 아니라, 각각 무엇을 얻고 무엇을 감수하는지로 봤습니다.
장점만 보면, 도입 후 캐싱이나 설계 부담을 놓쳤습니다. 그래서 양면을 함께 봐야 했습니다.
REST와 GraphQL 사이에서 제가 의식한 건 어느 쪽이 더 좋다가 아니라, 무엇에 맞느냐입니다. 데이터 소비 패턴과 팀의 경험치에 따라 선택이 달라졌습니다. 화면마다 데이터 조합이 다양하면 GraphQL이 유리했고, 단순하고 캐싱이 중요하면 REST가 나았습니다. 또 팀이 GraphQL 경험이 없으면, 초기 설계 비용이 부담이었습니다.
한쪽을 무조건 미는 게 아니라, 맥락에 맞게 고르는 게 PM의 역할이라고 봤습니다. 기술 자체보다, 그 결정이 개발 속도와 유지보수에 어떤 영향을 주는지를 이해해야 했습니다. 그래서 정답을 외우기보다, 상황에 맞는 선택을 돕는 게 중요했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.