예시 답변 1
스키마 설계 경험을 통해 배운 점
개인 프로젝트에서 GraphQL 스키마를 처음 설계할 때, REST처럼 엔드포인트마다 응답 형태를 고정하지 않고 클라이언트가 필요한 필드만 요청할 수 있게 타입을 나눴습니다. 처음엔 타입을 너무 세분화해서 오히려 쿼리가 복잡해졌는데, 자주 함께 쓰이는 필드를 묶어 다시 정리하고 나서야 사용하기 편해졌습니다.
과도한 세분화라는 시행착오를 통해 배운 점을 담았습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
개인 프로젝트에서 GraphQL 스키마를 처음 설계할 때, REST처럼 엔드포인트마다 응답 형태를 고정하지 않고 클라이언트가 필요한 필드만 요청할 수 있게 타입을 나눴습니다. 처음엔 타입을 너무 세분화해서 오히려 쿼리가 복잡해졌는데, 자주 함께 쓰이는 필드를 묶어 다시 정리하고 나서야 사용하기 편해졌습니다.
GraphQL로 목록과 상세 정보를 함께 조회하는 쿼리를 만들었는데, 항목 수가 늘어나자 응답 속도가 눈에 띄게 느려졌습니다. 원인을 찾아보니 항목마다 관련 데이터를 각각 조회하고 있어서 요청이 항목 수만큼 늘어나는 문제였습니다. 이 문제를 완전히 해결하지는 못했지만, 관련 자료를 찾아보며 배치로 묶어 조회하는 방법이 있다는 걸 알게 됐습니다.
REST API를 먼저 써봤기 때문에, GraphQL을 처음 접했을 때 왜 하나의 엔드포인트만 있는지 이해하기 어려웠습니다. 여러 리소스를 조합해 한 번에 조회할 수 있다는 점이 REST와 가장 다르다는 걸 직접 쿼리를 짜보고 나서야 체감했습니다. 다만 작은 프로젝트에서는 이 장점이 크게 와닿지 않기도 했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.