REST, gRPC 또는 API 설계 및 운영 경험을 통해 어떤 문제를 해결했는지 구체적으로 설명해 주세요. | 무신사 백엔드 면접 질문

Q: REST와 gRPC 차이는 어떻게 보세요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 성능과 호환이 충돌하면 어떻게 풀까요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

Q: 본 직무에 어떻게 적용하시겠어요?

면접관이 답변에 이어 던질 수 있는 후속 질문입니다.

무무신사백엔드직무 역량2026년 출제

답변 미리보기

API 설계 경험에서 REST를 사용할 때 가장 신경 쓴 것은 리소스 중심의 URL 설계와 HTTP 메서드의 의미를 지키는 것이었습니다. 동사보다 명사로

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

맥락 결을 짚는가?

API·범위·기간 결을 짚는 흔적이 강합니다. 막연한 '경험 있다'만 답하면 면접관이 결을 다시 묻는 자리가 자주 보입니다.

방법 결이 구체인가?

계약·버전·관측 결을 짚는 흔적이 답에 있어야 합니다. 한 결만 답하면 면접관이 결을 다시 캐는 결이 자주 통합합니다.

본인 사례 결을 받치는가?

구체 케이스·결과 결을 자기 언어로 짚는 흔적이 강하게 통합합니다. 이론만 답하면 면접관이 적용을 다시 묻는 자리가 강합니다.

한계도 인정하는가?

약한 영역·대안 결을 짚는 흔적이 자주 통합합니다. 만점 평가만 답하면 면접관이 객관화를 다시 캐는 자리가 강합니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

무신사 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

REST 설계 원칙·gRPC 스트리밍 활용·API 버저닝 전략으로 API 운영 결약 84초 마이크로서비스 전환기에 REST 외부 공개와 gRPC 내부 통신으로 분리한 맥락 결약 72초 gRPC 브라우저 호환 부재와 팀 온보딩 비용을 한계로 인정한 결약 70초

예시 답변 1

약 84초

REST 설계 원칙·gRPC 스트리밍 활용·API 버저닝 전략으로 API 운영 결

API 설계 경험에서 REST를 사용할 때 가장 신경 쓴 것은 리소스 중심의 URL 설계와 HTTP 메서드의 의미를 지키는 것이었습니다. 동사보다 명사로 리소스를 표현하고 상태 변경은 메서드로 구분하면 클라이언트가 API를 예측 가능하게 사용할 수 있었습니다.

gRPC는 내부 서비스 간 통신에서 활용했습니다. 스트리밍이 필요한 경우나 강타입 인터페이스가 오류를 줄이는 데 유리한 상황에서 REST보다 적합했습니다. 프로토콜 버퍼로 스키마를 정의하면 클라이언트와 서버 간 계약이 명확해졌습니다.

API 버저닝은 이미 사용 중인 클라이언트를 깨지 않으면서 기능을 추가하는 전략이 핵심이었습니다. URL 버전 방식과 헤더 방식을 상황에 따라 선택했고, 구버전 지원 기간을 명시하고 공지하면 외부 클라이언트의 전환 준비 시간을 확보할 수 있었습니다.

이 결의 특징

이 결은 REST 설계의 핵심을 리소스 중심 URL과 HTTP 메서드의 의미 분리로 귀결시킵니다. 동사보다 명사로 리소스를 표현하고 상태 변경을 메서드로 구분하면 클라이언트가 API를 '예측 가능하게' 사용할 수 있다는 관찰입니다. gRPC는 내부 서비스 간 통신에 활용했고, 스트리밍이 필요하거나 강타입 인터페이스가 오류를 줄이는 경우에 REST보다 적합했다는 구체적 판단입니다. 프로토콜 버퍼 스키마 정의로 클라이언트와 서버 간 계약이 명확해진 경험이 분명합니다.

이 결이 통하는 자리

API 설계의 일관성과 확장성을 중시하는 조직에서 통합니다. 외부 클라이언트 생태계가 있는 공개 API 플랫폼, 다양한 직군이 API 계약을 신뢰해야 하는 팀, gRPC와 REST를 용도에 맞게 병행하는 성숙한 마이크로서비스 환경에서 이 이중 프로토콜 전략이 공명합니다.

예시 답변 2

약 72초

마이크로서비스 전환기에 REST 외부 공개와 gRPC 내부 통신으로 분리한 맥락 결

REST와 gRPC를 함께 운영한 경험은 모놀리식에서 마이크로서비스로 전환하는 6개월 프로젝트에서였습니다. 외부 클라이언트와 연결되는 API는 REST로 유지했고, 내부 서비스 간 통신은 gRPC로 교체했습니다. 전환 초기엔 팀 내에 gRPC 경험자가 없어서 Proto 파일 관리와 서비스 빌드 순서 의존성을 정리하는 데 시간이 예상보다 많이 들었습니다. 외부 API는 브라우저와 모바일 클라이언트가 직접 호출하기 때문에 REST의 표준 호환성이 실질적인 이유였고, 내부 통신은 레이턴시와 강타입 계약이 필요한 서비스부터 순차적으로 gRPC로 전환했습니다. 역할을 분리하고 나니 두 프로토콜의 적합한 용도가 더 명확하게 보였습니다.

이 결의 특징

이 결은 모놀리식에서 마이크로서비스로 전환한 6개월 프로젝트에서의 구체적 선택을 보여줍니다. 외부 클라이언트 연결 API는 REST로 유지하고 내부 서비스 간 통신은 gRPC로 교체한 전략적 판단, 팀 내 gRPC 경험 부족으로 Proto 파일 관리와 빌드 순서 의존성 정리에 예상보다 오래 걸린 실질적 비용입니다. REST의 표준 호환성이 브라우저와 모바일 클라이언트 직접 호출을 가능하게 하는 '실질적 이유', 내부는 레이턴시와 강타입이 필요한 서비스부터 순차적으로 전환한 점진적 접근입니다.

이 결이 통하는 자리

기술 부채와 팀 역량을 균형 맞춰 마이그레이션해야 하는 조직에서 통합니다. 레이턴시 SLO가 엄격한 내부 통신, 외부 호환성이 관건인 공개 인터페이스를 분명히 구분하는 아키텍처 철학, 신기술 도입 시 팀 온보딩 비용을 사전에 평가하는 성숙도 높은 환경에서 이 타협의 지혜가 울립니다.

예시 답변 3

약 70초

gRPC 브라우저 호환 부재와 팀 온보딩 비용을 한계로 인정한 결

gRPC를 내부 통신에 도입하면서 가장 예상하지 못했던 어려움은 브라우저 직접 호출 불가 문제였습니다. 내부 서비스 간에는 잘 동작했지만, 프론트엔드 개발자가 디버깅을 위해 직접 엔드포인트를 호출하려 할 때 gRPC-Web 변환 레이어가 없으면 불가능했습니다.

Postman으로 바로 테스트할 수 없는 것 자체가 초기 개발 속도를 늦췄습니다. 팀 온보딩도 예상보다 오래 걸렸습니다. Proto 파일 변경과 하위 호환성 유지 규칙을 팀원이 체감하려면 직접 실수를 겪어야 하는 경우가 많았습니다. REST는 오랜 생태계 덕분에 도구와 사례가 풍부한데, gRPC는 아직 팀 내에서 레퍼런스를 공유하는 비용이 있다고 봅니다.

이 결의 특징

이 결은 gRPC 도입의 '예상하지 못했던 어려움'을 정직하게 드러냅니다. gRPC-Web 변환 레이어 부재로 브라우저 직접 호출이 불가능해진 구체적 문제, Postman에서 바로 테스트할 수 없어 초기 개발 속도가 늘어난 현실적 영향입니다. Proto 파일 변경과 하위 호환성 유지 규칙이 팀원이 직접 실수를 겪어야 체감되는 온보딩 비용도 명시됩니다. REST의 긴 생태계가 도구와 사례 풍부함의 이점으로, gRPC는 팀 내 레퍼런스 공유 비용이 남아 있다는 비교입니다.

이 결이 통하는 자리

새 기술 도입이 개발자 경험과 생산성 향상으로 귀결되는지를 엄격히 측정하는 조직에서 통합니다. 프론트엔드 개발자의 디버깅 자유도를 중시하는 팀, 개발자 도구 생태계가 충실해야 채택률이 높아진다는 현실을 아는 조직, 새 기술의 장점뿐만 아니라 팀 확대 시 온보딩 비용을 함께 평가하는 의사결정에서 이 균형 감각이 울립니다.

위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹REST와 gRPC 차이는 어떻게 보세요?

貳성능과 호환이 충돌하면 어떻게 풀까요?

參본 직무에 어떻게 적용하시겠어요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. 무신사 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히

개인정보처리방침 이용약관 문의

무무신사백엔드직무 역량2026년 출제

답변 미리보기

API 설계 경험에서 REST를 사용할 때 가장 신경 쓴 것은 리소스 중심의 URL 설계와 HTTP 메서드의 의미를 지키는 것이었습니다. 동사보다 명사로

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

맥락 결을 짚는가?

API·범위·기간 결을 짚는 흔적이 강합니다. 막연한 '경험 있다'만 답하면 면접관이 결을 다시 묻는 자리가 자주 보입니다.

방법 결이 구체인가?

계약·버전·관측 결을 짚는 흔적이 답에 있어야 합니다. 한 결만 답하면 면접관이 결을 다시 캐는 결이 자주 통합합니다.

본인 사례 결을 받치는가?

구체 케이스·결과 결을 자기 언어로 짚는 흔적이 강하게 통합합니다. 이론만 답하면 면접관이 적용을 다시 묻는 자리가 강합니다.

한계도 인정하는가?

약한 영역·대안 결을 짚는 흔적이 자주 통합합니다. 만점 평가만 답하면 면접관이 객관화를 다시 캐는 자리가 강합니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

무신사 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

예시 답변 1

약 84초

REST 설계 원칙·gRPC 스트리밍 활용·API 버저닝 전략으로 API 운영 결

이 결의 특징

이 결이 통하는 자리

예시 답변 2

약 72초

마이크로서비스 전환기에 REST 외부 공개와 gRPC 내부 통신으로 분리한 맥락 결

이 결의 특징

이 결이 통하는 자리

예시 답변 3

약 70초

gRPC 브라우저 호환 부재와 팀 온보딩 비용을 한계로 인정한 결

이 결의 특징

이 결이 통하는 자리

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹REST와 gRPC 차이는 어떻게 보세요?

貳성능과 호환이 충돌하면 어떻게 풀까요?

參본 직무에 어떻게 적용하시겠어요?

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. 무신사 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

개인정보처리방침 이용약관 문의