이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
API 설계 경험에서 REST를 사용할 때 가장 신경 쓴 것은 리소스 중심의 URL 설계와 HTTP 메서드의 의미를 지키는 것이었습니다. 동사보다 명사로 리소스를 표현하고 상태 변경은 메서드로 구분하면 클라이언트가 API를 예측 가능하게 사용할 수 있었습니다.
gRPC는 내부 서비스 간 통신에서 활용했습니다. 스트리밍이 필요한 경우나 강타입 인터페이스가 오류를 줄이는 데 유리한 상황에서 REST보다 적합했습니다. 프로토콜 버퍼로 스키마를 정의하면 클라이언트와 서버 간 계약이 명확해졌습니다.
API 버저닝은 이미 사용 중인 클라이언트를 깨지 않으면서 기능을 추가하는 전략이 핵심이었습니다. URL 버전 방식과 헤더 방식을 상황에 따라 선택했고, 구버전 지원 기간을 명시하고 공지하면 외부 클라이언트의 전환 준비 시간을 확보할 수 있었습니다.
REST와 gRPC를 함께 운영한 경험은 모놀리식에서 마이크로서비스로 전환하는 6개월 프로젝트에서였습니다. 외부 클라이언트와 연결되는 API는 REST로 유지했고, 내부 서비스 간 통신은 gRPC로 교체했습니다. 전환 초기엔 팀 내에 gRPC 경험자가 없어서 Proto 파일 관리와 서비스 빌드 순서 의존성을 정리하는 데 시간이 예상보다 많이 들었습니다. 외부 API는 브라우저와 모바일 클라이언트가 직접 호출하기 때문에 REST의 표준 호환성이 실질적인 이유였고, 내부 통신은 레이턴시와 강타입 계약이 필요한 서비스부터 순차적으로 gRPC로 전환했습니다. 역할을 분리하고 나니 두 프로토콜의 적합한 용도가 더 명확하게 보였습니다.
gRPC를 내부 통신에 도입하면서 가장 예상하지 못했던 어려움은 브라우저 직접 호출 불가 문제였습니다. 내부 서비스 간에는 잘 동작했지만, 프론트엔드 개발자가 디버깅을 위해 직접 엔드포인트를 호출하려 할 때 gRPC-Web 변환 레이어가 없으면 불가능했습니다.
Postman으로 바로 테스트할 수 없는 것 자체가 초기 개발 속도를 늦췄습니다. 팀 온보딩도 예상보다 오래 걸렸습니다. Proto 파일 변경과 하위 호환성 유지 규칙을 팀원이 체감하려면 직접 실수를 겪어야 하는 경우가 많았습니다. REST는 오랜 생태계 덕분에 도구와 사례가 풍부한데, gRPC는 아직 팀 내에서 레퍼런스를 공유하는 비용이 있다고 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.