SAP 테스트 자동화, AI가 실패 복구까지 해야 진짜 자동화다

테스트 자동화의 진짜 병목은 '실행'이 아니라 '실패 후 수습'입니다. 테스트를 자동으로 만들고, 자동으로 실행하는 시대에 — 실패하면 여전히 사람이 하나씩 고치고 있습니다.

테스트 500건을 돌렸습니다. 결과를 열어봅니다. 73건 실패.

여기서부터가 진짜 일입니다.

실패 건을 하나 엽니다. 로그를 읽습니다. 자재코드가 바뀌어서 매핑이 안 맞았습니다. 테스트 데이터를 수정합니다. 다시 실행합니다. 통과. 다음 건을 엽니다. 이번엔 고객번호가 원인입니다. 수정, 재실행, 통과. 다음 건. 그다음 건. 73건을 이렇게 반복합니다.

테스트 자동화를 도입했는데, 실패 후 수습은 여전히 수작업입니다.
실행은 자동이지만 복구는 수동 — 이 구조가 테스트 자동화의 실질적인 ROI를 갉아먹고 있습니다. AI가 테스트 자동화에 적용되는 영역은 점점 늘어나고 있지만, 정작 가장 많은 시간을 잡아먹는 이 구간은 아직 다뤄지지 않고 있습니다.

SAP 테스트가 실패하는 3가지 구조적 원인

테스트가 실패할 때, 대부분 시나리오 로직 자체가 틀린 게 아닙니다. 시나리오는 맞는데 테스트 데이터가 안 맞아서 실패합니다. 그리고 이 테스트 데이터 불일치에는 세 가지 구조적 원인이 있습니다.

원인 1: 마스터 데이터/필드 값 변경

자재코드 체계가 바뀌었습니다. 고객 마스터에 새 필드가 추가됐습니다. 조건 레코드의 유효 기간이 만료됐습니다. 테스트 시나리오에 박혀 있는 값이 더 이상 시스템에 존재하지 않으니, 실행하면 실패합니다.

SAP 운영 환경에서 마스터 데이터는 매일 바뀝니다. 테스트 환경은 그 변화를 자동으로 반영하지 않습니다. 시간이 지날수록 테스트 데이터와 실제 데이터 사이의 간극이 벌어집니다.

원인 2: SAP 업그레이드/패치 후 필드 구조 변경

분기마다 반복되는 S/4HANA 업그레이드는 Fiori 앱 ID 변경, CDS View 구조 변경, OData 서비스 버전 업을 동반합니다. 테스트 시나리오가 참조하는 필드 이름이 바뀌거나, 필수 입력 값이 추가되거나, 기존 필드가 Deprecated 처리됩니다.

시나리오 로직은 여전히 유효합니다. "판매오더를 생성하고 → 출하를 처리하고 → 청구를 완료한다"는 흐름은 바뀌지 않았습니다. 그런데 그 흐름 안에서 참조하는 테스트 데이터의 구조가 달라졌으니 실행이 멈춥니다.

원인 3: 테스트 환경 vs 운영 환경 데이터 불일치

테스트 환경을 운영에서 복사해왔는데, 복사 시점 이후 운영 데이터가 변경됐습니다. 또는 환경 리프레시 과정에서 일부 데이터가 누락됐습니다. 운영에서는 존재하는 값이 테스트 환경에는 없어서 실패합니다.

세 가지 원인의 공통점이 있습니다. 시나리오를 다시 설계할 필요가 없습니다. 테스트 데이터만 현재 시스템 상태에 맞게 고치면 됩니다. 문제는 그 "고치는 작업"이 사람 손을 타야 한다는 것입니다.

SAP 테스트에서 AI가 적용되는 3가지 레이어

테스트 자동화에 AI를 접목하는 방식은 하나가 아닙니다. AI가 어느 레이어에서 작동하느냐에 따라, 풀 수 있는 문제의 종류와 깊이가 완전히 달라집니다.

레이어 1: 테스트 생성

자연어로 요구사항을 입력하면 AI가 테스트 시나리오를 자동 생성합니다. "판매오더 생성부터 청구까지 E2E 테스트를 만들어줘"라고 하면 실행 가능한 테스트 케이스가 만들어지는 식입니다.

이 레이어는 시나리오를 "만드는" 단계의 효율화입니다. 초기 구축 시간을 크게 줄여주고, 비개발자도 테스트를 설계할 수 있게 합니다. 시장에서 가장 활발하게 투자되고 있는 영역이기도 합니다.

하지만 시나리오를 빠르게 만들어도, 실행 후 실패하면 수습은 여전히 사람 몫입니다.

레이어 2: UI 자동 유지 보수

화면 요소가 변경됐을 때 — 버튼 위치가 바뀌거나, 앱 ID가 달라지거나, CSS 셀렉터가 변경됐을 때 — AI가 새로운 요소를 자동으로 탐지하고 매핑을 갱신합니다. 흔히 "셀프 힐링"이라고 불리는 기능입니다.

이 레이어는 테스트 스크립트가 "깨지지 않게" 유지하는 단계입니다. UI 리플레이 기반 도구에서 특히 중요한 기능이고, 다수의 테스트 자동화 도구가 이 수준의 AI를 제공하고 있습니다.

하지만 앞서 정리한 3가지 실패 원인을 보면, UI가 원인인 경우는 일부에 불과합니다. 자재코드가 바뀐 건 화면 문제가 아닙니다. CDS View 구조가 달라진 건 로케이터로 해결할 수 없습니다. 테스트 환경과 운영 환경의 데이터 간극은 프론트엔드에서 보이지 않습니다. SAP 테스트 실패의 실제 원인 대부분은 UI 아래, 백엔드 데이터 레이어에 있습니다.

레이어 3: 실패 후 자율 복구

테스트가 실패했을 때, AI가 실패 원인을 진단하고 백엔드 데이터 매핑을 자동으로 보정한 뒤 재실행까지 완결합니다. 사람 개입 없이, 테스트가 "성공할 때까지" 자율적으로 수행하는 단계입니다.

레이어 1이 "만드는 속도"를, 레이어 2가 "유지하는 비용"을 줄인다면, 레이어 3은 "실패 후 복구 시간"을 제거합니다.

PerfecTwin은 레이어 3에서 출발합니다. SAP 테스트 현장에서 가장 많은 시간을 소모하는 구간 — 실패 후 수동 디버깅, 테스트 데이터 수정, 재실행의 반복 루프 — 을 AI로 자동화하는 것이 가장 먼저 풀어야 할 문제라고 판단했기 때문입니다.

PerfecTwin의 AI 자율 복구 작동 방식

PerfecTwin의 AI 자율 복구는 UI가 아니라 백엔드 데이터 레이어에서 작동합니다. 실패 감지부터 원인 분석, 데이터 보정, 재실행까지 사람 개입 없이 하나의 루프로 완결됩니다.

Step 1 — 실패 감지

테스트 실행 중 실패가 발생하면 즉시 포착합니다. 단순히 "실패했다"는 결과만 기록하는 게 아니라, 실패 지점의 컨텍스트 — 어떤 트랜잭션에서, 어떤 데이터가, 어떤 값으로 전송됐을 때 실패했는지 — 를 함께 수집합니다.

Step 2 — 원인 분석

AI가 실패 로그, 데이터 매핑 테이블, 그리고 해당 고객사의 SAP 컨피그 값 — 문서 유형, 넘버 레인지, 세금 코드, 가격 결정 프로시저 같은 커스터마이징 설정 — 을 함께 교차 분석합니다. 범용적인 패턴 매칭이 아니라, 이 시스템에서 왜 이 데이터가 안 통하는지를 정확하게 진단합니다.

예를 들어, 자재코드 'MAT-001'로 판매오더 생성을 시도했는데 실패했다면 — AI는 해당 시스템의 자재 유형 설정과 넘버 레인지 컨피그를 읽어, 코드 체계가 변경됐는지, 해당 자재 유형에서 현재 유효한 코드가 무엇인지, 아니면 테스트 환경에서 데이터 자체가 누락된 건지를 판별합니다.

Step 3 — 데이터 매핑 자동 보정

원인 분석 결과에 따라 테스트 데이터를 자동으로 교정합니다. 이때 일반적인 대체 값을 넣는 것이 아니라, 해당 시스템의 컨피그 설정에서 실제로 유효한 값을 찾아서 채웁니다. 변경된 자재코드라면 해당 시스템의 자재 유형 설정과 넘버 레인지를 읽어 유효한 대체 코드를 특정하고, 추가된 필수 필드라면 컨피그에 정의된 기본값을 참조하여 채웁니다.

Step 4 — 자동 재실행

보정된 데이터로 즉시 재실행합니다. 재실행 후 성공 여부를 확인하고, 보정 이력을 기록합니다. 사람이 나중에 검토할 수 있도록 "무엇을 왜 어떻게 고쳤는지"가 투명하게 남습니다.

이 네 단계가 사람 개입 없이 자동으로 순환합니다. 73건의 실패를 한 건씩 열어보는 대신, AI가 루프를 돌면서 스스로 해결하고 결과만 보고합니다.

이 자율 복구가 가능한 구조적 이유가 있습니다. PerfecTwin은 UI를 거치지 않고 SAP 백엔드에 직접 데이터를 전송하는 구조로 작동합니다. 처음부터 백엔드 레이어에서 테스트를 실행하기 때문에, 실패 원인 분석과 데이터 보정도 같은 레이어에서 수행할 수 있습니다. UI 리플레이 기반 도구에서는 구조적으로 구현하기 어려운 접근입니다.

실무 시나리오: 이런 상황에서 작동한다

시나리오 1: 분기별 업그레이드 후 대량 회귀 테스트

S/4HANA 분기 업그레이드를 적용했습니다. 300건의 회귀 테스트를 실행합니다. Fiori 앱 구조 변경과 CDS View 수정으로 40건이 실패합니다. 기존이라면 담당자가 40건을 하나씩 열어서 변경된 필드를 확인하고, 데이터를 수정하고, 재실행해야 합니다. AI 자율 복구가 작동하면, 변경된 필드 구조를 자동으로 파악하고 매핑을 보정한 뒤 재실행합니다. 담당자는 결과 리포트만 확인하면 됩니다.

시나리오 2: 마이그레이션 후 마스터 데이터 전환

ECC에서 S/4HANA로 마이그레이션을 완료했습니다. 자재코드 체계가 전환되면서 기존 E2E 시나리오에 박혀 있던 코드가 전부 무효화됩니다. AI가 신규 코드 체계를 탐지하고, 시나리오 내 테스트 데이터를 자동으로 매핑 전환합니다. 시나리오 자체를 다시 만들 필요 없이 테스트 데이터만 갱신되어 재실행됩니다.

시나리오 3: 테스트 환경 리프레시 후 데이터 불일치

테스트 환경을 운영에서 새로 복사했습니다. 이전 테스트에서 사용하던 고객번호, 오더번호가 리프레시된 환경에는 없습니다. AI가 환경 간 데이터 차이를 분석하고, 현재 환경에서 유효한 대체 값을 찾아 테스트 데이터를 자동으로 조정합니다.

테스트 자동화의 다음 단계

테스트 자동화를 도입한 기업들이 공통적으로 겪는 다음 과제가 있습니다. 실행은 자동화했는데, 실패 후 복구가 여전히 수작업이라는 것입니다.

시나리오 수가 100건일 때는 감당할 수 있습니다. 300건이 되고 500건이 되면, 실패 건 수습에 들어가는 시간이 실행 시간을 넘어섭니다. 회귀 테스트의 속도 병목 중 상당수가 바로 이 구간에서 발생합니다.

PerfecTwin은 이 문제를 AI 기반 자율 복구로 해결합니다. 백엔드 직접 전송으로 실행 속도를 확보하고, 운영 데이터 기반 테스트로 현실적인 검증을 수행하고, AI 자율 복구로 실패 후 수습까지 자동화하는 — SAP 테스트 자동화의 다음 챕터입니다.

PerfecTwin은 레이어 3(자율 복구)에서 시작했지만, AI 적용 범위를 레이어 1(테스트 생성)과 레이어 2(유지보수 자동화)로 점진적으로 확장해 나갈 예정입니다. 궁극적으로 테스트 생성부터 실행, 실패 복구까지 전 구간에서 AI가 작동하는 SAP 테스트 자동화 플랫폼을 지향합니다.

자동화의 완성은 '실행'이 아니라 '실패 후 복구'까지 자동화될 때입니다.