AI로 레거시를 옮길 때: 계약 테스트와 병행 전환의 경계 정하기

코드 생성 능력보다 검증 가능한 동작이 먼저입니다

Anthropic은 2026년 2월 5일 여러 에이전트로 C 컴파일러를 만드는 실험을 공개하며, 장기 작업을 이끄는 테스트와 실행 구조의 중요성을 설명했습니다. 이 실험이 모든 레거시 전환의 성공을 뜻하지는 않습니다. 실무에 가져올 질문은 AI가 얼마나 많은 코드를 옮겼는지가 아니라 새 구현이 기존 시스템의 어떤 동작을 보존했는지입니다.

• Anthropic · Building a C compiler with a team of parallel Claudes (2026-02-05)

가상의 정산 서비스를 오래된 프레임워크에서 새 서버로 이전한다고 생각해 보세요. 응답 필드가 같아도 소수점 처리, 마감 시각, 환불 반영 순서가 바뀌면 정산 결과가 달라집니다. 기존 코드의 모든 우연한 동작을 복제할 필요는 없지만 유지할 정책과 수정할 오류를 구분해야 합니다. 이 결정을 에이전트가 변환 과정에서 암묵적으로 내리게 두지 않습니다.

연결 계약과 업무 결과를 다른 검사로 보호합니다

Pact의 계약 테스트는 소비자가 사용하는 요청·응답의 기대를 공급자 구현과 대조하는 방식입니다. 필수 필드, 오류 형식, 메시지 구조를 보존하는 데 유용하지만 재고 차감이나 세금 계산 자체의 정확성을 모두 확인하지는 않습니다. 계약 검사와 별도로 대표 거래의 최종 결과, 데이터 불변 조건과 상태 전이를 검증할 사례가 필요합니다.

기존 서비스에서 관찰한 응답을 기준 사례로 만들 때는 변경 가능한 시각·식별자와 업무상 중요한 필드를 구분합니다. 무조건 전체 JSON을 같게 만들면 의미 없는 차이가 쌓이고, 너무 많은 필드를 제외하면 정책 변경을 놓칩니다. 비교에서 허용할 차이와 금지할 차이를 업무 담당자와 먼저 정해 두면 검토 결과가 일관됩니다.

병행 검증은 두 시스템에 같은 쓰기를 실행하는 뜻이 아닙니다

Microsoft의 Strangler Fig 패턴은 기능을 나눠 기존 시스템과 새 시스템 사이의 요청 경로를 점진적으로 바꾸는 접근입니다. 읽기 요청은 동일 입력의 결과를 비교하기 쉽지만 쓰기 요청은 별도 설계가 필요합니다. 새 구현의 계산을 분리된 데이터나 외부 연동을 차단한 환경에서 실행하고, 결과 비교가 실제 결제나 고객 메시지를 다시 발생시키지 않도록 합니다.

전환 기간에 두 저장소를 함께 갱신한다면 어느 쪽이 원본인지와 실패 복구 순서를 정해야 합니다. 한쪽 기록만 성공했을 때 무작정 재시도하면 순서가 뒤집힐 수 있습니다. 거래 ID, 중복 방지 규칙, 재처리 대기열과 대조 작업을 설계하고, 어떤 불일치를 자동 수정할 수 있는지 검토하세요. AI가 만든 연결 코드도 이 운영 규칙 안에서 검사해야 합니다.

되돌리기는 트래픽과 데이터 두 가지를 포함합니다

먼저 위험이 낮고 경계가 분명한 조회 기능을 옮긴 뒤 관찰 결과를 보고 전환 범위를 넓힐 수 있습니다. 복귀 시 이전 서비스가 새 데이터 형식을 읽지 못한다면 라우팅만 바꿔서는 복구되지 않습니다. 관찰 기간, 불일치 기준, 복귀 책임자와 호환성 유지 기간을 함께 정하세요. 이전 코드의 제거는 비교와 복귀 가능성 검토가 끝난 뒤 별도 변경으로 진행합니다.

• 인터페이스 계약과 업무 결과 검사가 분리되어 있는가
• 의도한 정책 변경과 보존할 동작을 구분했는가
• 병행 실행이 외부 쓰기를 중복시키지 않는가
• 이전 버전으로 돌아갈 때 데이터 호환성도 유지되는가