변경을 해석합니다
공급자의 릴리스 안내와 실제 시험 페이로드를 확인합니다. 선택 필드가 필수로 바뀌거나 숫자 단위가 바뀌면 JSON 문법이 정상이어도 업무 결과가 달라질 수 있습니다. 과거에 저장된 요청을 재실행할 때 어느 버전으로 해석해야 하는지도 정합니다.
대응표의 가정 예시
다음은 의미 차이를 논의하는 예시이며 실제 공급자의 규격이 아닙니다. 변환에서 버려지는 정보와 기본값은 명시적으로 검토합니다.
contract v1: estimated_price = monthly KRW amount
contract v2: estimate.amount + estimate.period + estimate.currency
adapter rule: accept v1 only with documented monthly KRW meaning
unknown version: stop downstream action and record review state
missing period in v2: validation error, never assume annual/monthly
호환 기간
기존 폼·예약 작업·캐시된 클라이언트가 이전 형식을 계속 보낼 수 있습니다. 양쪽을 받는 기간과 종료 조건을 정하고 과거 형식 수신을 관찰합니다. 새 형식 배포만으로 이전 형식이 즉시 사라진다고 가정하지 않습니다.
시험 순서
- 지원하는 각 버전의 정상 예시를 준비합니다.
- 필수 누락·자료형 오류·미지원 버전을 시험합니다.
- 변환 후 업무 의미와 후속 결과를 대조합니다.
- 이전 요청 재실행과 되돌리기 경로를 확인합니다.
실제 고객 페이로드를 저장소에 넣어 고정 시험 자료로 사용하지 않습니다. 필요한 구조만 남긴 가정 데이터를 만들고 입력 계약의 보안·개인정보 조건도 유지합니다. 어댑터가 오류를 숨겨 기본값으로 통과시키는지 확인합니다.
완료 기준
새 형식 수신과 기존 업무의 연속성이 함께 검증돼야 합니다. 지원 종료일과 미지원 요청 처리, 담당자를 남겨 다음 변경에서 추측하지 않게 합니다. 자동화가 계속 실행된다는 사실만으로 같은 업무를 수행한다고 볼 수 없으므로 핵심 금액·분류·상태의 의미를 결과 원장까지 확인합니다.
자주 묻는 질문
- 필드가 하나 늘어도 버전을 바꿔야 하나요?
- 호환 가능한 선택 필드 추가와 기존 의미를 바꾸는 변경을 구분합니다. 어떤 조건에서 새 버전이 필요한지 정해 불필요한 이름 증가와 조용한 의미 변경을 모두 피합니다.
- 모르는 버전은 최신 형식으로 추측하면 되나요?
- 틀린 추측으로 잘못된 업무가 실행될 수 있습니다. 지원 범위를 명시하고 미지원 형식은 보류·거절·담당자 확인 중 정한 경로로 처리합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.