화면이 같다고 해서 업무가 같다고 할 수는 없다

이전 기고에서는 AI 모더니제이션 (AI Modernization)을 요구사항, 실행 권한, 검증, 인간 승인의 경계 설계로서 정리했다 [1]. 본고에서는 그 공정 설계를 반복하지 않고, 검증 공정 내부에 있는 또 다른 질문을 다룬다.

신구 시스템에서 동일한 입력으로부터 동일한 화면이 표시되었을 때, 그것만으로 업무 시스템으로서 동일하다고 말할 수 있는가?

답은 '아니오'이다.

예를 들어, 발주 등록 완료 화면과 합계 금액이 구 시스템과 일치하더라도, 재고 할당 (Inventory Allocation)이 별도의 트랜잭션 (Transaction)으로 분리되어 외부 전송만 실패했을 가능성이 있다. 재실행에 의해 발주가 이중 등록될 수도 있다. 세액의 총계는 같더라도 명세 단위의 단수 처리 (Rounding)가 바뀌어 회계 연동 시 차이가 나타날 수도 있다. 화면과 최종값의 비교만으로는 갱신 순서, 장애 시의 중간 상태, 재전송 조건, 권한, 감사 추적 (Audit Trail)까지 확인할 수 없다.

AI는 기존 코드의 해석, 변환안 생성, 시험 항목의 열거를 가속화할 수 있다. 하지만 무엇을 동일하다고 간주하고, 어떤 차이를 허용하며, 어떤 증거가 있어야 운영 환경으로 옮길 수 있는지는 코드 생성과는 다른 설계 대상이다. 원전에서 다룬 Tsuneishi Shipbuilding의 사례에서도 AI가 크게 단축한 것은 현행 해석과 재설계의 일부이며, 그 후에는 사양 선택, 데이터 대조, 업무 수용, 운영 전환이 남아 있다 [2].

본고에서는 신구 시스템의 차분을 제로(0)로 만드는 것이 아니라, 보존하는 동작, 의도적으로 변경하는 동작, 폐지하는 동작, 미결된 동작을 분류하고, 각각에 비교 방법, 허용 오차, 증거, 승인 조건을 할당하는 방법을 생각한다. 이 상태를 '업무 등가성 (Business Equivalence)이 설명 가능한 상태'라고 부른다.

등가성을 출력값만으로 판정하지 않는다

업무 등가성이란 구 시스템과 신 시스템의 내부 구현을 동일하게 만드는 것이 아니다. 합의된 업무 결과와 제약 조건이 새로운 구조에서도 충족됨을 나타내는 것이다.

단순한 신구 비교에서는 동일한 입력을 주고 화면, 장표, API 응답, 데이터베이스의 최종값을 대조한다. 이 방법은 필요하지만 비교 대상이 좁다. 발주 등록을 예로 들면, 적어도 다음과 같은 차이가 남는다.

특히 주의해야 할 점은 최종 상태만을 비교하면 처리 도중의 의미가 사라진다는 점이다. 구 시스템에서는 발주, 재고 할당, 전송 예약을 단일 트랜잭션으로 확정하던 것을, 신 시스템에서는 비동기 처리 (Asynchronous Processing)로 나누는 경우가 있다. 정상 종료 시의 결과는 같더라도, 도중 장애로부터의 회복 방법은 별개의 것이 된다.

모더니제이션에서는 구조를 바꾸기 때문에 내부 처리까지 구 시스템과 동일하게 만들 필요는 없다. 반면, 구조 변경으로 인해 업무상 필요한 원자성 (Atomicity), 멱등성 (Idempotency), 시간 제약, 감사 가능성을 잃는다면 이행은 성공한 것이 아니다. 비교 대상을 하나의 '일치'로 몰아넣지 말고, 여러 개의 등가성으로 분해할 필요가 있다.

업무 등가성을 다섯 가지 대상으로 분해한다

업무 결과

가장 먼저 확인하는 것은 이용자와 외부 시스템에서 보이는 업무 결과이다. 금액, 재고 수, 계약 상태, 승인 결과, 마감 처리 결과 등이 이에 해당한다.

정상계 (Happy Path)만으로는 부족하다. 경계값, 취소, 재처리, 과거 날짜, 월말, 해당 데이터 없음, 동일 요청의 재전송도 대상으로 한다. 구 시스템의 시험 항목이 정상계에 치우쳐 있다면, 운영 로그나 장애 기록으로부터 추가 시나리오를 도출한다.

상태 전이와 데이터 갱신

다음으로 최종값에 도달하기까지의 상태 전이를 확인한다. 대상은 갱신 순서, 트랜잭션 경계, 중복 방지, 참조 무결성, 장애 시의 중간 상태이다.

데이터베이스 비교에서는 단순한 행 수 일치보다 다음의 집계가 유효하다.

• 업무 키별 건수
• 상태별 건수 분포
• 금액 열의 합계와 차액
• 중복 키와 고립 참조
• 갱신 전후의 상태
• 동일 처리를 재실행한 후의 증분
• 장애를 주입한 시점에 남는 레코드

예를 들어, 발주 확정 API를 동일한 요청 식별자(Request Identifier)로 2회 호출하여, 발주 건수, 재고 할당 건수, 전송 예약 건수가 1건 그대로 유지되는지 확인한다. 정상 종료를 1회 확인하는 것보다 멱등성 조건을 직접 시험할 수 있다.

외부 연동과 시간 조건

외부 연동은 데이터 형식이 일치하는 것만으로는 불충분하다. 송신 시각, 순서, 재전송, 중복 제거, 타임아웃 후의 처리도 계약에 포함된다.

적어도 다음 조건을 기록한다.

• 송신 기한과 최대 지연
• 순서 보장 여부
• 재전송 횟수와 간격
• 중복 판정 키
• 상대측이 이상 응답을 반환한 후의 상태
• 수동 재개 시작 지점
• 신구 병행 가동 중의 송신원 식별

비동기화나 마이크로서비스화 (Microservices)에 의해 응답 시간이나 재전송 방식은 변할 수 있다. 구 구현과 동일한 내부 절차를 요구하는 것이 아니라, 상대측과 합의한 결과와 시간 조건을 충족하는지를 판정한다.

비기능 요구사항과 통제

업무 결과가 올바르더라도 처리 능력, 복구, 권한, 감사가 요구사항을 충족하지 못하면 운영 환경으로 이관할 수 없다.

비기능 요구사항은 "성능에 문제가 없을 것"과 같은 문장이 아니라, 측정 가능한 조건으로 정의해야 한다.

• 95 퍼센타일(Percentile) 응답 시간
• 시간당 처리 건수
• 동시 실행 수
• 복구 목표 시간(RTO) 및 복구 시점 목표(RPO)
• 역할별 참조·갱신 가능 여부
• 감사 기록의 필수 항목
• 장애 탐지부터 통지까지의 시간

모델 구동형(Model-driven) 레거시 이관에 관한 산업 사례에서도, 기능적 동작뿐만 아니라 중요한 비기능적 특성과 유지보수성을 이관 시 유지해야 할 대상으로 삼고 있다 [3]. 이는 구문 변환(Syntax transformation)의 성공을 시스템 이관의 성공과 동일시할 수 없는 이유이다.

이관 후의 변경 가능성

마지막으로, 이관 후에도 사양 근거, 구현, 시험, 운영 절차를 동일한 변경 단위로 업데이트할 수 있는지 확인한다.

이관 시 대량의 설계서와 시험을 생성하더라도, 이후의 변경에 대응하지 못하면 몇 년 후에는 코드만이 다시 정본(Source of truth)이 된다. 등가성(Equivalence)의 증거는 납품 시의 자료가 아니라, 변경에 따라 업데이트되는 운영 자산이어야 한다.

확인 대상은 다음과 같다.

• 요구사항부터 시험까지의 대응 관계
• 차이(Difference)를 승인한 기록
• 유지보수 책임자와 판단 주체
• 재실행 가능한 시험 데이터
• 의존 관계와 영향 범위
• 장애 시의 복구 절차

이 다섯 가지를 구분하면, "화면과 금액은 일치하지만 재전송 시 중복 등록된다"라거나 "업무 결과는 같지만 감사 추적(Audit trail)이 누락된다"와 같은 차이를 단순한 시험 누락이 아닌 등가성 조건의 부족으로 다룰 수 있다.

차분을 보존·변경·폐지·미결로 분류하기

등가성의 대상을 분해하더라도, 구 시스템의 동작을 모두 보존하기만 하면 되는 것은 아니다. 오랜 개수를 거친 코드에는 현재도 필요한 업무 규칙뿐만 아니라, 폐지된 제도, 과거의 장애 회피책, 구형 기반의 제약, 사용되지 않는 분기(Branch)도 남아 있다.

구 시스템과의 차이는 다음 네 가지 유형으로 분류한다.

세금 계산을 예로 들면, 현재도 유효한 절사(Rounding) 처리는 '보존', 법 개정에 대응한 신규 세율은 '변경', 폐지된 제도의 분기는 '폐지', 적용 기간을 확인할 수 없는 특례는 '미결'이 된다.

여기서 '차이 있음'을 일률적으로 결함으로 간주하면, 개선을 포함하는 모더니제이션(Modernization)이 성립하지 않는다. 반대로 신규 시스템 측의 차이를 모두 개선으로 간주하면, 변환 시의 오류를 정당화하게 된다. 필요한 것은 차분을 없애는 것이 아니라, 차분의 종류와 판단 근거를 고정하는 것이다.

미결(Undecided)을 독립된 상태로 남겨두는 것도 필수적이다. AI가 생성한 설명에 확신도(Confidence)를 부여하더라도, 근거가 충돌하는 처리의 채택 여부는 확정되지 않는다. Reversa는 코드와 사양의 추적 가능성, 확신도의 명시, 인간이 확인해야 할 미결 사항의 보존을 중시하며, 탐색적 사례에서는 517건의 주장, 10건의 미확인 사항, 53건의 등가성 시나리오를 생성하고 있다 [4]. 해당 연구는 최종적인 등가성 확인과 운영 전환을 완료하지 않았기 때문에, 이 수치를 이관 성공의 증거로 삼을 수는 없다. 하지만 미확인 사항을 추측으로 채우지 않고, 이관 판단으로부터 분리하여 남겨두는 설계는 참고할 만하다.

등가성 계약을 시험 설계의 입력으로 사용하기

차분 분류를 회의 자료의 표로만 관리하면, 구현, 시험, 업무 승인이 각기 다른 기대치를 갖기 시작한다. 따라서 동작별로 비교 조건을 정리한 등가성 계약(Equivalence Contract)을 만든다.

계약이라고 부르는 이유는 구 구현을 그대로 사양화하기 위해서가 아니다. 신규 시스템이 충족해야 할 결과, 허용 오차(Tolerance), 실패 조건, 증거, 승인 상태를 시험 코드에서 참조할 수 있는 입도로 고정하기 위해서이다.

발주 확정을 YAML로 표현하면 다음과 같다.

behavior_id: purchase-order-017
scenario: 발주 확정 후 재고 할당 및 외부 전송을 수행함
classification: preserve
...

이는 제품 사양이나 표준 형식이 아니라 관리 단위의 예시이다. expected와 tolerance는 생성된 코드 내부에 매립하지 않고, 승인 가능한 독립된 결과물로 유지한다.

classification: preserve라면 구 시스템의 실행 결과가 주요 비교 대상이 된다. change라면 구 결과와의 차분이 아니라, 승인된 새로운 기대치와 대조한다. 폐지(Deprecated)의 경우, 해당 기능이 호출되지 않는 것뿐만 아니라 이력 참조, 저장 의무, 외부 이용자에게 미치는 영향을 확인한다. 미결(Undecided)은 시험 실패가 아니라 공정 정지 조건이 된다.

시험을 함수 단위에서 업무 트랜잭션 단위로 쌓아 올리기

동등성 계약 (Equivalence Contract)을 만들더라도, 단체 시험(Unit Test)만으로는 업무 전체를 증명할 수 없다. 시험을 다음의 6개 계층으로 나누고, 동일한 동작 ID (Behavior ID)로부터 필요한 계층을 선택한다.

AI를 이용한 코드 변환에서는 업무 규칙(Business Rule)의 추출 정밀도와 생성된 코드의 행동 동등성 (Behavioral Equivalence)을 분리해서 볼 필요가 있다. AgentModernize의 평가에서는 중간 표현(Intermediate Representation)이 정답으로 간주된 업무 규칙의 91.2%를 포착한 반면, 생성된 코드의 평균적인 행동 동등성은 제한적이었으며, 추출된 규칙이 그대로 올바른 구현이 되는 것은 아니다[5]. 이 결과는 8개 시나리오와 특정 모델에 의한 실험이므로, 일반적인 성공률로 사용해서는 안 된다. 그럼에도 불구하고 규칙 추출, 코드 생성, 업무 결과 확인을 별도의 공정으로 분리해야 하는 근거는 된다.

발주 등록의 경우, 단체 시험에서 세액 계산을 확인하고, 처리 연쇄(Process Chain)를 통해 승인부터 발주 확정까지를 추적하며, 데이터 업데이트 시험을 통해 부분 반영과 재실행을 확인한다. 외부 연계 시험에서는 송신 기한과 재전송을 다루고, 업무 수용(Business Acceptance)에서는 담당자, 승인자, 타 부서 참조자라는 서로 다른 역할로 조작한다. 마지막으로 부하 시험, 권한 시험, 장애 복구를 실시한다.

사용자 수용 시험(UAT) 또한 화면을 한 바퀴 도는 확인회로 만들어서는 안 된다. Microsoft의 Dynamics 365를 위한 가이드는, 이관된 데이터와 최신 버전의 시스템을 통합 시험 환경에 배치하고, 업무 사용자, 복잡한 데이터 상호작용, 경계 조건, 역할별 권한을 포함하는 시험을 요구하고 있다[6]. 제품 고유의 절차를 그대로 일반화할 수는 없지만, 실제 데이터, 통합, 권한을 제외한 수용 시험으로는 운영 환경에 가까워질 수 없다는 점은 공통적이다.

AI 생성 테스트는 시나리오 전개에 사용한다

AI는 동등성 계약으로부터 경계값, 이상계 (Exception Path), 조합, 미시험 경로를 전개할 수 있다. 대량의 기존 코드에서 분기 조건을 추출하고, 테스트 데이터 후보를 만들며, 신구 차이점을 설명하는 용도로도 적합하다.

반면, 다음 항목을 AI만으로 확정해서는 안 된다.

이는 생성된 코드와 생성된 테스트가 동일한 추출 결과와 동일한 오해를 공유할 가능성이 있기 때문이다. AI는 시험 케이스를 늘릴 수는 있지만, 동등성 계약에 작성된 기대값과 허용 오차를 시험 실행 시에 변경해서는 안 된다.

예를 들어, 신규 시스템의 처리가 기존 시스템보다 45초 느리고 계약상의 허용 오차가 30초라면, AI에게 "구현상 합리적이므로 합격"이라고 재해석하게 해서는 안 된다. 45초를 수용하려면 성능상의 영향과 외부 접속처의 제약을 확인한 후, 계약을 변경하고 나서 재시험해야 한다. 시험을 통과하기 위해 기대값을 맞추는 것이 아니라, 기대값의 변경 자체를 심사 대상으로 삼아야 한다.

전체 차분 제로가 아니라 미설명 차분 제로를 이관 조건으로 한다

모더니제이션(Modernization)에서는 구 시스템과 신 시스템의 전체 차분(Difference)을 제로로 만들 필요는 없다. 구조, 화면, 운용, 성능 특성을 개선한다면 합의된 차이는 반드시 발생한다.

이관 판정에서 구별해야 할 상태는 다음 세 가지이다.

• 일치함
• 합의된 차이임
• 미설명 차이임

종료 조건은 "차분이 없다"가 아니라, 미설명 차분이 없다는 것이다. 적어도 다음 조건을 만족할 때까지 운영 이관(Production Migration)으로 진행할 수 없다.

• 저장 대상의 필수 시험이 완료되었는가
• 변경 대상의 기대값과 허용 오차가 승인되었는가
• 폐지 대상의 호출원, 이력, 저장 의무에 대한 영향을 확인하였는가
• 고위험 경로에 미결 항목이 남아있지 않은가
• 미설명 차분이 제로인가
• 롤백(Rollback) 절차를 실제로 시험하였는가
• 잔존 리스크와 승인자를 기록하였는가

신구 병행 가동은 정지 시간을 단축하는 배포 방식인 동시에, 동등성의 증거를 수집하는 기간이기도 하다. Microsoft의 모더니제이션 계획에서는 중요한 업무 시스템에 대해 신구 환경을 병행 가동하고, 단계적으로 트래픽을 옮기며, 문제가 있으면 구 환경으로 되돌리는 방법을 제시하고 있다[7]. 기사 중의 5%, 50%, 100%라는 비율은 하나의 예시일 뿐, 그대로 채택할 기준은 아니다. 확대 조건과 롤백 조건을 사전에 결정하고, 각 단계에서 동일한 동등성 계약을 평가해야 한다.

병행 가동 중에 신구 시스템에 동일한 거래를 투입할 수 없는 경우라도, 입력을 복제하지 않고 구 시스템 측의 실행 결과를 기록하여 신 시스템 측에서 재생하는 방법이 있다. 금액, 상태 전이, 외부 송신, 처리 시간, 감사 기록을 동작 ID로 묶으면 차분을 업무 단위로 추적할 수 있다.

미설명 차분이 남은 채로 기한만 맞춰 이관하면, 차분의 의미는 운영 장애의 형태로 판명된다. 반대로 경미한 표시 차이까지 제로로 만들려 하면, 이관 가치가 낮은 수정에 시간을 소비하게 된다. 차분의 유무가 아니라, 차분이 분류되어 증거와 승인으로 연결되어 있는지를 판정해야 한다.

완전 복제가 아니라 설명 가능한 차분을 목표로 한다

AI 모더니제이션 (Modernization)에서 지켜야 할 것은 구형 코드의 모든 동작이 아니다. 구형 시스템 안에는 현재도 필요한 업무 규칙, 폐지해야 할 규칙, 그리고 존재 이유를 확인할 수 없는 처리가 혼재되어 있다. 모든 것을 복제한다면 과거의 제약 사항까지 새로운 기반으로 옮기게 된다.

반면, AI가 생성한 새로운 구현을 새로운 정답으로 취급한다면, 추출 시의 오해나 변환 시의 누락을 검출할 수 없다. 필요한 것은 구형 구현에 대한 맹목적인 일치도, 신규 구현에 대한 무조건적인 신뢰도 아니다.

업무 등가성 (Business Equivalence)을 성립시키는 절차는 다음 순서를 따른다.

• 등가성을 업무 결과, 상태 전이 (State Transition), 외부 연계, 비기능 요구사항, 변경 가능성으로 분해한다
• 각 동작을 보존, 변경, 폐지, 미결로 분류한다
• 기대값, 허용 오차, 증거, 승인 조건을 등가성 계약 (Equivalence Contract)에 기록한다
• 함수 단위부터 업무 트랜잭션 단위까지 시험을 쌓아 올린다
• AI는 시나리오 전개에 사용하며, 기대값의 확정과는 분리한다
• 모든 차분이 제로(0)인 것이 아니라, 설명되지 않은 차분이 제로(0)인 것을 이행 조건으로 한다

모더니제이션의 성공은 신구 시스템이 완전히 동일한 것이 아니다. 어떤 동작을 보존하고, 어떤 동작을 바꾸며, 어떤 차이를 수용했는지를 시험 결과와 판단 기록으로부터 설명할 수 있는 것이다.

참고 문헌

• id774, AI モダナイゼーションで要件・権限・検証を分離する（2026-07-22）. https://zenn.dev/id774/articles/e389d32dcdfa11
• id774, AI モダナイゼーションはなぜ仕様選択と検証で止まるのか（2026-07-29）. https://blog.id774.net/entry/2026/07/29/5158/
• Tobias Böhm ほか, Model-Driven Legacy System Modernization at Scale（2026-02-04）. https://arxiv.org/abs/2602.04341
• Sanderson Oliveira de Macedo, Ronaldo Martins da Costa, Reversa: A Reverse Documentation Engineering Framework for Converting Legacy Software into Operational Specifications for AI Agents（2026-05-18）. https://arxiv.org/abs/2605.18684
• Sheikh Nazib Ahmed, Marnim Galib, AgentModernize: Preserving Business Logic in Legacy Modernization with Multi-Agent LLMs and Behavioral Specification Graphs（2026-05-17）. https://arxiv.org/abs/2605.17535
• Microsoft, Guidance for user acceptance test after data migration in solutions with Dynamics 365（2025-09-30）. https://learn.microsoft.com/en-us/dynamics365/guidance/resources/data-migration-user-acceptance-tests
• Microsoft, Plan your cloud modernization（2025-08-01）. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/modernize/plan-cloud-modernization

Discussion