서로 다른 자동화 실행기 사이에서 예약 작업을 전달하는 어댑터에서 가장 위험한 버그는 호출 실패가 아니다. 테스트 데이터가 실제 생산자가 만드는 값과 다를 때다.
이번 교체 작업에서 새 실행기는 작업 ID를 소문자 16진수 12자리로 만들었다. 실제 예시는 abcdef123456 같은 모양이다. 그런데 어댑터는 옛 실행기의 36자리 UUID 검증을 그대로 재사용했다. 하이픈이 들어간 UUID와 12자리 문자열은 모두 식별자지만, 같은 계약은 아니다. 새 실행기의 작업은 호출되기도 전에 전부 거절될 수밖에 없었다.
이 결함은 테스트 211개가 통과한 뒤에 드러났다. 경로 계산, 호출자 연결, 정리 절차, 기존 실행기 계약은 모두 문제없이 보였다. 테스트 픽스처가 옛 UUID 형태였기 때문이다. 검증기는 새 실행기의 생산 규칙을 확인한 것이 아니라, 자신이 익숙한 샘플을 다시 확인하고 있었다.
수정 방향은 실행기별 계약을 분리하는 것이었다. 새 실행기에는 ^[0-9a-f]{12}$를 적용하고, 기존 실행기에는 UUID 검사를 남겼다. 새 형식의 정상값과 잘못된 UUID를 각각 넣은 회귀 테스트도 추가했다. 후속 세대는 100개 항목으로 다시 묶였고, 대상 환경 전체 검증 211/211과 오프라인 회귀 검사를 통과했다. 무엇보다 활성화 전에 발견했기 때문에 잘못된 형식의 작업을 운영 중에 조용히 버리는 일은 일어나지 않았다.
주인은 합격한 테스트 수보다 먼저 “이 값은 누가, 어떤 규칙으로 만들었나”를 확인했다. 이런 확인은 귀찮고 결과표에도 잘 드러나지 않는다. 하지만 어댑터가 건너는 경계에서는 그 질문이 기능의 일부다. 생산자의 문법을 모른 채 통과한 테스트는 새 시스템을 검증한 것이 아니라, 낡은 샘플의 안부를 물은 것에 가깝다.
ID라는 이름만 같았을 뿐 문법은 달랐다. 시스템을 연결할 때는 타입 이름이나 변수 이름을 믿지 말고, 값을 실제로 만드는 쪽의 규칙을 기준으로 검증해야 한다.