서버의 JSON 응답에 필드나 상태 값을 추가하려 합니다. 업데이트하지 않은 모바일 앱이 왜 실패할 수 있으며 어떻게 검증하나요?

필드를 추가하면 대체로 안전해 보이지만 소비자가 모르는 필드를 거절하거나, 서명·캐시 키·직렬화 순서에 의존하면 문제가 될 수 있습니다. 구조의 추가뿐 아니라 의미와 기본값이 기존 클라이언트에게 어떻게 보이는지를 확인해야 합니다.

다음은 설명용 응답입니다. 구버전 앱이 status로 active와 closed만 처리한다면 새 값 paused를 어떻게 해석해야 할지 모릅니다.

{"id": 42, "status": "paused", "pauseReason": "maintenance"}

모르는 pauseReason 필드를 무시하는 것과, 모르는 status를 active로 취급해도 되는지는 다른 문제입니다. 사용을 중단해야 하는 상태라면 안전하게 제한하거나 업데이트를 안내해야 합니다.

응답에 새로운 상태 값을 추가했다고 하겠습니다. 문자열 필드 자체는 그대로여도 클라이언트가 기존 세 값만 처리하면 예외가 나거나 잘못된 기본 동작을 할 수 있습니다. 저는 알 수 없는 값의 처리 정책과 기존 값의 의미를 유지하는지 확인하겠습니다. 요청의 선택 필드를 필수로 바꾸거나 기본 동작을 바꾸는 것도 명백한 호환 변화입니다.

배포는 공급자와 소비자가 같은 순간에 바뀐다고 가정하지 않겠습니다. 오래된 모바일 앱과 배치 작업을 포함한 소비자 목록을 확인하고, 계약 테스트와 실제 사용 지표로 구버전이 남아 있는지 보겠습니다. 큰 의미 변경은 명시적인 버전이나 새 필드로 나누고, 폐기 일정과 관측을 둡니다. 테스트에서는 새 서버에 구클라이언트, 구서버에 신클라이언트가 각각 어떻게 동작하는지 확인하겠습니다. JSON 파싱이 성공했다는 것보다 같은 요청이 의도한 동작을 유지하는지가 호환성의 기준입니다.

구조 변화와 의미 변화를 나눕니다

선택적 필드 추가는 알 수 없는 필드를 무시하는 소비자에게 안전할 수 있지만, 응답을 엄격한 스키마로 검증하거나 전체 JSON을 서명하는 소비자에게는 그렇지 않습니다. null, 생략, 빈 배열을 구분하는 클라이언트라면 기본값을 임의로 정하지 않습니다. active, closed만 처리하던 앱에 paused를 추가할 때 default 분기를 active로 보내면 사용자가 중지된 기능을 실행할 수 있습니다. 화면 장식용 필드는 무시하고, 권한·상태·금액처럼 행동을 바꾸는 필드는 새 필드나 버전으로 분리하겠습니다.

양방향 혼합 버전을 시험합니다

새 서버-구앱뿐 아니라 구서버-신앱도 실행해야 합니다. 계약 테스트에서는 파싱 성공 외에 상태별 버튼 노출, 재시도 여부, 오류 안내, 캐시 적중과 서명 검증을 확인합니다. 운영에서는 앱 버전별 알 수 없는 enum, 특정 필드 접근 오류, 정상 흐름 실패를 집계해 드문 배치 소비자도 찾습니다. 폐기할 필드는 사용량이 0인지 확인하고, 의미 변경은 이전 endpoint를 일정 기간 유지합니다. 서버가 새 응답을 내려도 클라이언트가 요청을 재시도해 주문을 중복시키지 않게 요청 ID와 멱등성 계약도 함께 점검하겠습니다.

구체적인 경계 사례

요청 호환성도 방향이 있습니다. 서버가 선택적 필드를 추가로 받는 것은 기존 요청을 허용하지만, 원래 선택적이던 필드를 필수로 바꾸면 구앱이 실패합니다. 반대로 새 앱이 보내는 필드를 구서버가 엄격하게 거절하면 서버 롤백도 불가능해질 수 있습니다. 스키마 차이만 검사하지 않고 실제 요청·응답 표본을 버전 조합별로 실행하겠습니다.

폐기 예정 endpoint의 최근 요청이 없다는 것만으로 모든 소비자가 사라졌다고 단정하지 않습니다. 월말 배치나 장기 미접속 앱처럼 관측 창 밖 소비자가 있을 수 있습니다. 지원 기간과 최소 앱 버전 정책을 정하고, 기능별 사용 근거와 오류 안내·업데이트 경로를 준비한 뒤 호환 경로를 제거하겠습니다.