이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학교 프로젝트에서 실시간 채팅 기능을 만들 때 REST API와 WebSocket 중 어느 것을 쓸지 결정하는 것이 첫 번째 어려움이었습니다. REST로 구현했더니 폴링 방식에서 클라이언트가 0.5초마다 요청을 보내 서버 부하가 급격히 올라가는 문제가 생겼습니다. WebSocket으로 전환 후 연결 유지와 재연결 로직을 직접 구현했는데, 네트워크가 끊겼을 때 메시지 유실을 어떻게 처리하는지가 두 번째 어려움이었습니다. 이것은 클라이언트 측에서 메시지에 ID를 붙이고, 재연결 시 마지막 수신 ID 이후 메시지를 재요청하는 방식으로 해결했습니다. 세 번째 어려움은 양방향 통신에서 클라이언트 상태와 서버 상태를 어떻게 동기화하는가였는데, 서버를 단일 진실 공급원으로 삼고 클라이언트는 로컬 캐시를 갖되 주기적으로 검증하는 구조를 택했습니다.
통신 설계는 "연결됐을 때"보다 "연결이 끊겼을 때"를 먼저 설계하는 것이 더 중요하다는 것을 배웠습니다.
개인 프로젝트에서 서비스 간 통신에 REST JSON으로 시작했는데, 페이로드 크기와 직렬화 속도에서 병목이 생겼습니다. gRPC와 Protobuf로 전환하면서 같은 데이터를 JSON보다 훨씬 작은 크기로 직렬화하고 파싱 속도도 빨라지는 것을 확인했습니다. 어려웠던 것은 Protobuf 스키마 정의와 코드 생성 파이프라인을 처음 구성하는 것이었습니다. 스키마 변경 시 하위 호환성을 유지하지 않으면 기존 클라이언트가 깨지는 문제가 생겨서, 필드 번호를 변경하지 않고 신규 필드를 추가하는 방식으로 버전 관리를 맞췄습니다. HTTP/2 기반이라 멀티플렉싱 덕분에 다수 요청이 동시에 처리되는 것도 확인했습니다. 결과적으로 서비스 간 응답 시간이 줄고 네트워크 사용량도 낮아졌습니다. gRPC는 마이크로서비스 간 통신에서 페이로드 크기와 속도를 동시에 개선합니다.
Protobuf 하위 호환성 관리가 서비스 업그레이드를 안전하게 만듭니다. HTTP/2 멀티플렉싱이 동시 요청 처리 효율을 높입니다.
서버-클라이언트 통신에서 보안을 처음 구현할 때 TLS 설정을 제대로 이해하지 못해 삽질한 경험이 있습니다. 자체 서명 인증서로 로컬 테스트를 하다가 프로덕션에서 클라이언트가 인증서를 신뢰하지 못해 연결이 거부됐습니다. CA에서 발급한 인증서와 자체 서명 인증서의 차이를 그때 제대로 이해했습니다. 인증서 만료일을 놓치면 서비스가 멈추는 문제도 겪었는데, 인증서 만료일을 모니터링하고 사전에 자동 갱신하는 스크립트를 추가해 해결했습니다. 인증서 핀닝은 보안을 강화하지만 인증서가 바뀔 때마다 앱 업데이트가 필요한 트레이드오프가 있다는 걸 알게 됐습니다. 결과적으로 프로덕션 환경에서 안정적인 HTTPS 통신 구조를 갖추게 됐습니다.
인증서 만료 모니터링과 자동 갱신이 TLS 운영의 핵심입니다. 자체 서명 인증서와 CA 발급 인증서의 차이를 프로덕션에서 처음 배웠습니다. 인증서 핀닝은 보안과 유지보수 부담 사이의 트레이드오프가 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.