앱 하위 호환성을 위한 서버 주도 API 응답 설계

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

앱이 등록 후 7일 이내 상품에 ‘신규’ 배지를 붙인다. 제품 정책이 3일로 바뀌어도 이미 설치된 구버전에는 7일 규칙이 남는다. 서버가 등록일만 내려주면 그 클라이언트를 바꿀 수 없다. 현재 정책에서는 새 상품이 아닌데도 계속 배지가 붙는다.

설치된 앱은 어제의 정책을 들고 다닌다

웹의 표시 로직은 대개 빠르게 다시 배포할 수 있다. 모바일 앱은 여러 버전이 사용자 기기에 남고 모든 구버전에 강제 업데이트를 걸기도 어렵다. 숫자 표현도 같다. 한 버전은 더하기 기호를 쓰고 새 버전은 15K로 보여줄 수 있다.

서버가 표시 값이나 배지를 결정하면 앱을 새로 내지 않아도 구버전에 현재 표현을 보낼 수 있다. 라벨 하나를 바꾸려고 모바일 빌드를 배포하는 대신 서버에서 표현 실험을 바꾸고 결과를 비교할 수도 있다.

도메인에는 개수, 등록일, 가격과 할인처럼 안정된 사실을 둔다. 특정 앱 버전의 15K 포맷이나 ‘신규’ 배지를 넣지 않는다. 요청과 응답을 만드는 프레젠테이션 계층에서 이 사실을 클라이언트 계약으로 변환한다.

이 계층은 서버에서 실행되더라도 목적상 클라이언트를 위한 영역이다. 내부 개념을 클라이언트가 원하는 계약으로 번역하는 것이 역할이다. 자주 바뀌는 표시 정책은 핵심 비즈니스 코드에서 떼어 내면서 오래된 앱의 호환성은 백엔드가 감당할 수 있다.

금액을 포함한 모든 요청·응답 값을 문자열로 만들어 나중에 표현이 바뀌어도 와이어 타입이 변하지 않게 하는 팀도 있었다. 유연성은 이해할 수 있지만 선호하는 전략은 아니다.

더 좁은 질문은 변환을 어디에 둘 것인가다. 구버전 앱에 일관된 정책이 필요하거나 표시 실험을 한다면 서버 프레젠테이션 계층이 응답을 결정하고, 안정된 도메인 사실은 표현 변환과 분리한다.