이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
업그레이드 경로를 고려한 시스템 설계에서 가장 먼저 결정한 것은 API 버전 전략이었습니다. v1과 v2를 동시에 운영하면 클라이언트가 전환할 시간을 벌 수 있고, 급하게 끊지 않아도 되는 여유를 제공했습니다. 버전 전환 기간을 미리 공지하면 협업하는 팀들이 일정을 맞출 수 있었습니다.
하위 호환성 유지에서는 필드 추가는 허용하되 제거나 타입 변경은 신 버전에서만 하는 원칙을 세웠습니다. 기존 클라이언트가 새 필드를 무시할 수 있도록 설계하면 점진적으로 기능을 확장하면서도 기존 클라이언트가 깨지지 않았습니다.
마이그레이션 가이드도 중요했습니다. 변경 사항과 전환 방법을 문서로 제공하면 각 팀이 스스로 판단해 전환할 수 있었고, 지원 문의가 줄고 전환 속도가 빨라졌습니다. 주요 변경사항은 CHANGELOG에 버전별로 정리해 이력을 추적할 수 있게 했습니다.
API 버전을 올린 뒤 기존 클라이언트가 응답을 파싱하다 오류가 나는 경험을 했습니다. 새 버전에서 응답 필드를 추가했는데, 구버전 클라이언트가 예상 못 한 필드를 받으면서 파싱 실패가 났습니다.
이후엔 버전 업 시 구버전 클라이언트 흐름을 재현하는 회귀 테스트를 먼저 작성하고 그 테스트가 통과한 뒤에만 배포하는 방식을 만들었습니다. v1, v2 클라이언트 시나리오를 각각 테스트 케이스로 만들어 두니 새 버전 배포 시 기존 동작이 유지되는지 자동으로 확인할 수 있었습니다.
이 경험으로 하위 호환성은 선언이 아니라 회귀 테스트가 보증하는 것이라는 걸 배웠습니다. 테스트가 없으면 "호환된다고 생각하는 것"일 뿐입니다.
하위 호환성을 고려하지 않고 deprecated 표시한 필드를 바로 제거했다가 기존 클라이언트가 실패하는 경험을 했습니다. 일정이 촉박해서 충분한 기간을 두지 않고 제거했는데, 아직 구버전을 쓰는 클라이언트가 남아 있었습니다.
이후엔 deprecated 필드는 최소 2개 마이너 버전 동안 유지하는 정책을 팀과 합의했습니다. X-Deprecated 헤더로 경고를 내려보내고, 기간이 지난 후에야 실제 제거를 진행하는 점진적 방식을 정착시켰습니다.
이 경험으로 하위 호환성은 제거 시점이 아니라 충분한 유예 기간 설계에서 결정된다는 걸 배웠습니다. 제거 속도보다 클라이언트가 대응할 시간이 더 중요했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 현대자동차 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.