SAP 사용자 인수 테스트(UAT): 누가 책임지고 어떻게 진행하는가

SAP 사용자 인수 테스트(UAT)는 현업 사용자가 구성된 시스템에서 자기 프로세스를 직접 실행해 보고 Go-Live 전에 공식적으로 인수하는 단계입니다. 책임은 현업에 있고, IT와 구축 파트너는 지원합니다. S/4HANA 프로젝트에서 저는 UAT에 최소 6~8주를 계획합니다.

제가 가장 자주 보는 테스트 실패는 단순합니다. UAT와 통합 테스트(SIT)에서 테스트가 충분하지 않은 것입니다. 일정이 밀리면 이 두 단계가 압축되고, 그 공백은 Go-Live 이후에 드러납니다.

아래에서 누가 무엇을 하는지, 준비, 스크립트, 결함 분류, 의미 있는 승인을 다룹니다. UAT가 다른 테스트 유형 사이에서 어디에 위치하는지는 SAP 테스트 완전 정리부터 보십시오.

사용자 인수 테스트의 책임은 현업에 있습니다. 이것이 제 입장이며, 일정이 빡빡해져도 바뀌어서는 안 됩니다.

이유는 이름에 있습니다. 인수란 시스템이 비즈니스를 운영할 수 있는지에 대한 비즈니스 결정이므로, 비즈니스를 운영하는 사람만 내릴 수 있습니다. IT나 파트너가 UAT를 승인한다면 아무도 아무것도 인수하지 않은 것입니다.

SAP의 방법론도 같은 말을 합니다. S/4HANA Cloud Private Edition 테스트 전략 지침은 UAT를 Realize 단계에 둡니다. 파트너의 구성 전문가가 수동 테스트 케이스를 준비하고, 고객의 현업 부서 전문가가 이를 실행하고 결과를 문서화합니다.

현실적인 업무 분담은 다음과 같습니다.

역할	UAT에서 책임지는 것	책임지지 않는 것
현업 프로세스 오너	시나리오 범위, 인수 기준, 자기 프로세스의 최종 승인	구성이나 코드 수정
키 유저와 테스터	스크립트 실행, 결과와 증빙 기록, 발견 사항 제기	결함을 혼자서 ‘결함 아님’으로 판정하는 것
UAT 리드(현업 측)	일일 계획, 진척 관리, 분류 회의 주재, 스폰서에게 준비 상태 보고	기술적 수정
구축 파트너	스크립트 초안 작성, 테스트 시스템 준비, 결함 수정, 재테스트 지원	인수
내부 IT	환경, 접근 권한, 타 시스템 인터페이스, 트랜스포트	인수
데이터 팀	테스트 데이터 로드와 리프레시, 대사 지원	비즈니스 시나리오 설계

UAT 리드는 파트너가 아니라 현업에서 나와야 합니다. 파트너가 이끄는 UAT는 빌드가 작동한다는 것을 증명하는 쪽으로 흘러가는데, 그것은 현업이 그 시스템으로 일할 수 있는지와는 다른 질문입니다.

UAT에는 최소 6~8주가 필요합니다. 그보다 짧으면 현업은 정상 흐름만 한 번 테스트하고, 수정 사항을 다시 테스트할 시간이 없으며, 진짜 문제가 숨어 있는 예외 상황까지는 가지도 못합니다.

이 기간은 UAT가 안정된 시스템에서 시작될 때만 의미가 있습니다. SAP의 지침은 통합이 구성되고 해당 프로세스의 데이터가 마이그레이션된 뒤에 비즈니스 프로세스를 테스트하라는 것입니다. 즉 SIT가 합의된 종료 기준에 따라 먼저 끝나야 합니다. 이 사이클들이 어떻게 연결되는지는 S/4HANA 테스트 전략 가이드에 정리했습니다.

첫 테스터가 로그인하기 전에 다음이 갖춰져 있어야 합니다.

1. 승인된 프로세스 설계. 스크립트는 설계를 바탕으로 작성하므로, 설계가 승인되지 않았다면 스크립트도 확정되지 않은 것입니다.
2. 진입 기준 충족과 기록. SIT 완료, 미해결 치명적 결함 없음, 통제된 수정을 제외하고 테스트 시스템 동결.
3. 운영 환경과 같은 테스트 시스템. 구성, 인터페이스, 역할, 권한이 Go-Live 시점과 같은 상태.
4. 실제와 같은 테스트 데이터. 마스킹되고 운영 수준이며, 테스트 시작 전에 로드와 대사가 끝난 데이터. 방법은 SAP 테스트 데이터 관리 가이드에서 다룹니다.
5. 본업에서 차출된 테스터. 이름을 지정하고, 소속 관리자와 투입 시간을 합의하고, 서면으로 남깁니다.
6. 새 시스템 교육을 받은 테스터. 사용할 Fiori 앱과 트랜잭션을 UAT 도중이 아니라 UAT 전에 짧게 안내합니다.
7. 하나의 테스트 관리 도구. 스크립트, 결과, 증빙, 결함을 여러 스프레드시트가 아니라 한곳에 둡니다.

5번 항목에서 UAT는 대개 조용히 실패합니다. 월 마감과 병행해 UAT를 하라는 요청을 받은 테스터는 월 마감을 먼저 하고, 그것이 옳은 판단입니다.

UAT 스크립트는 트랜잭션 목록이 아니라 비즈니스 시나리오입니다. ‘판매 오더를 생성한다’는 화면을 테스트합니다. ‘신용 보류 상태인 신규 고객의 주문을 받아 보류를 해제하고, 출하하고, 대금을 청구한다’는 비즈니스를 테스트합니다.

스크립트는 승인된 프로세스 설계를 바탕으로 만들고, 각 스크립트에 비즈니스 용어로 된 명확한 기대 결과를 넣으십시오. 테스터가 컨설턴트에게 묻지 않고도 통과인지 실패인지 말할 수 있어야 합니다.

네 종류의 시나리오를 다루십시오.

1. 핵심 흐름. Order to Cash, Procure to Pay, Record to Report처럼 비즈니스를 돌아가게 하는 일상 프로세스.
2. 예외. 반품, 신용 보류, 부분 출하, 가격 변경, 역분개, 반려되는 승인.
3. 기간 마감. 재무팀이 실제로 수행하는 월 마감과 연 마감 단계를 실제 수행 순서대로.
4. 역할 점검. 각 테스터가 Go-Live 때 갖게 될 역할로 작업해 권한 공백이 지금 드러나게 합니다.

스크립트 초안은 파트너가 쓰게 하고, 키 유저가 자기 언어로 다시 쓰게 하십시오. 현업이 도움 없이 스크립트를 따라갈 수 없다면, 그 스크립트는 빌드 팀을 위해 쓰인 것입니다.

SAP Cloud ALM에서 수동 테스트 케이스는 프로세스에서 시작하고, 테스트 계획이 이를 사이클로 묶습니다. 테스터는 각 단계를 통과 또는 실패로 설정하고, 실제 결과를 기록하고, 테스트 실행에서 바로 결함을 등록합니다. 그래서 스크립트와 결함 사이의 연결이 유지됩니다.

테스트 관리에 아직 SAP Solution Manager 7.2를 쓰는 프로젝트라면 메인스트림 유지보수가 2027년 말에 종료된다는 점에 유의하십시오(SAP Support). 신규 프로젝트는 Cloud ALM으로 계획하십시오.

UAT의 모든 발견 사항이 결함은 아닙니다. 전부 결함으로 처리하면 파트너가 감당하지 못하고, 전부 변경 요청으로 처리하면 진짜 실패가 가려집니다.

UAT 기간에는 매일 분류 회의를 여십시오. 현업 UAT 리드가 주재하고, 파트너의 기능 리드와 IT 담당자가 참석합니다. 새로 나온 모든 발견 사항은 유형, 심각도, 책임자가 정해진 상태로 회의를 나가야 합니다.

대부분의 발견 사항은 간단한 분류로 처리할 수 있습니다.

발견 사항 유형	의미	조치 주체	승인에 미치는 영향
결함	시스템이 승인된 설계대로 작동하지 않음	파트너가 수정, 테스터가 재테스트	치명적 및 높음 등급 결함은 승인을 막음
변경 요청	설계는 충족했지만 현업이 이제 다른 것을 원함	설계 권한자가 비용과 일정을 고려해 결정	현업이 그것 없이는 프로세스를 운영할 수 없다고 하지 않는 한 막지 않음
데이터 문제	마스터 데이터나 트랜잭션 데이터가 틀리거나 누락됨	데이터 팀이 수정, 테스터가 재테스트	같은 데이터가 운영에 들어간다면 막음
교육 또는 사용 문제	시스템은 작동하지만 테스터가 사용법을 몰랐음	교육 리드가 자료를 갱신	막지 않지만 교육 계획에 반영
권한 문제	역할에 필요한 접근 권한이 없거나 과도함	보안 팀이 역할을 조정	해당 역할에 대해 막음

심각도 정의는 UAT 시작 전에 비즈니스 용어로 합의하십시오. 치명적 결함은 우회 방법 없이 프로세스를 멈추게 합니다. 높음 등급 결함은 우회 방법이 있지만 현업이 실제 물량에서 감당할 수 없는 경우입니다.

변경 요청 열을 주시하십시오. UAT에서 변경 요청 목록이 길다면 대개 현업이 설계에 제대로 참여하지 않았다는 뜻이고, 다음 웨이브 전에 고쳐야 할 문제입니다.

SAP Activate 교육 자료는 사용자 인수 테스트가 완료되고 승인되면 Realize 단계가 완료된다고 명시합니다. 그 승인을 이메일 스레드가 아니라 문서로 만드십시오.

각 현업 프로세스 오너는 자기 프로세스에 대해 서명합니다. 승인 문서에는 다음이 기록되어야 합니다.

1. 무엇을 테스트했는지. 실행한 시나리오, 통과한 것과 실패한 것, 테스트 도구에 보관된 증빙.
2. 무엇이 아직 미해결인지. 모든 미해결 결함과 그 심각도, 책임자, 목표 일자.
3. 무엇을 우회 방법과 함께 인수했는지. 하나하나 명시하고, 현업이 운영하기로 합의한 우회 방법을 함께 기록.
4. 누가 언제 서명했는지. 위원회가 아니라 프로세스마다 이름이 지정된 한 사람.

종료 기준은 UAT 시작 전에 작성하고, 결과가 나왔을 때 바꾸지 마십시오. 현업이 그래도 공백을 안고 Go-Live하기를 원한다면 서명된 결정으로 기록하십시오. 이 게이트가 단계 전환에 어떻게 맞물리는지는 SAP 품질 게이트 가이드에서 다룹니다.

UAT 승인은 Go-Live 결정이 아닙니다. Go-Live 결정의 입력값입니다.

제가 반드시 요구하는 Go-Live 기준은 사전에 합의된 상세한 컷오버 체크리스트입니다. UAT 승인은 데이터 대사, 교육, 컷오버 리허설과 나란히 그 체크리스트의 한 줄입니다.

승인 후에는 인수된 것을 지키십시오. 지금부터 Go-Live까지의 모든 수정과 트랜스포트는 재테스트가 필요합니다. 이를 통제하는 방법은 SAP 회귀 테스트 가이드에서 설명합니다.

긴 문서는 필요 없습니다. 매번 같은 질문에 답하는 계획 하나를 UAT 시작 전에 작성해 현업의 서명을 받으면 됩니다.

간단한 구성으로 충분합니다.

섹션	내용	책임자
범위	범위 내 프로세스, 조직 단위, 역할, 그리고 명시적으로 제외하는 것	현업 프로세스 오너
일정	시작일과 종료일, 사이클, 재테스트 기간, 기간 마감 실행	UAT 리드
팀	프로세스별 테스터, 본업에서의 차출, 파트너와 IT 지원 담당자	UAT 리드와 소속 관리자
진입 기준	SIT 종료 충족, 테스트 시스템 동결, 데이터 로드 및 대사 완료, 테스터 교육 완료	UAT 리드와 프로젝트 매니저
환경과 데이터	테스트 시스템, 범위 내 인터페이스, 마스킹된 운영 수준 데이터, 리프레시 계획	IT와 데이터 팀
스크립트	프로세스별 시나리오 목록, 기대 결과, 프로세스 설계와의 연결	파트너가 초안 작성, 키 유저가 승인
결함 프로세스	발견 사항 유형, 심각도 정의, 일일 분류, 재테스트 규칙	UAT 리드가 분류 회의 주재
보고	일일 진척, 심각도별 미해결 결함, 스폰서에게 보고할 장애 요인	UAT 리드
종료 기준	심각도별 미해결 결함 허용치, 통과한 시나리오, 합의된 우회 방법	현업 프로세스 오너
승인	프로세스 오너별 서명란, 인수한 우회 방법 목록	현업 프로세스 오너와 스폰서

템플릿은 웨이브가 바뀌어도 똑같이 유지하십시오. 두 번째 롤아웃은 처음부터 다시 시작하지 말고 첫 웨이브의 스크립트와 교훈을 재사용해야 합니다.

이번 달 안에 현업에서 UAT 리드를 지정하고, 각 프로세스 오너에게 투입 시간이 확보된 테스터를 추천하도록 요청하십시오. 그다음 SIT 이후에 UAT 6~8주를 계획에 넣고, 일정이 빡빡해져도 지켜 내십시오.

UAT를 파트너가 진행하고 있거나 UAT가 계속 압축되고 있다면, 제가 이를 제대로 세우도록 돕고 있습니다. 여기에서 연락하실 수 있습니다.

SAP에서 사용자 인수 테스트란 무엇입니까?

현업 사용자가 구성된 SAP 시스템을 실제 프로세스에 대해 테스트하고 Go-Live 전에 공식적으로 인수하는 단계입니다. SAP Activate에서는 통합 테스트 이후 Realize 단계에서 이루어집니다. 키 유저가 시나리오 스크립트를 실행하고, 결과를 기록하고, 발견 사항을 제기하며, 프로세스 오너가 승인합니다.

SAP 프로젝트에서 UAT는 누가 책임집니까?

현업입니다. 프로세스 오너가 범위를 정하고 승인하며, 키 유저가 테스트를 실행합니다. 구축 파트너는 스크립트 초안을 작성하고 결함을 수정하며, 내부 IT는 환경, 접근 권한, 인터페이스를 제공합니다. IT도 파트너도 현업을 대신해 시스템을 인수해서는 안 됩니다.

SAP UAT는 얼마나 걸려야 합니까?

S/4HANA 프로젝트에서는 최소 6~8주를 계획하십시오. 그래야 핵심 흐름, 예외, 기간 마감 단계를 실행하고 수정 사항을 다시 테스트할 시간이 남습니다. 그보다 짧은 UAT는 대개 정상 흐름만 한 번 테스트하고 나머지는 Go-Live 이후에 발견합니다.

SAP에서 SIT와 UAT의 차이는 무엇입니까?

통합 테스트(SIT)는 프로세스와 인터페이스가 모듈과 시스템을 넘나들며 함께 작동하는지 확인하며, 주로 프로젝트 팀이 수행합니다. UAT는 현업이 그 시스템으로 자기 프로세스를 운영할 수 있는지 확인하며, 현업 사용자가 수행합니다. SIT는 UAT가 시작되기 전에 끝나야 합니다.

UAT 승인에는 무엇이 들어가야 합니까?

테스트한 시나리오와 그 결과, 책임자와 일자가 지정된 모든 미해결 결함, 현업이 인수한 우회 방법, 그리고 프로세스 오너별로 이름이 명시된 서명입니다. 종료 기준은 UAT 시작 전에 합의하십시오. 공백이 있는 승인은 기록된 비즈니스 결정이어야 합니다.

SAP Cloud ALM을 UAT에 사용할 수 있습니까?

예. SAP Cloud ALM은 프로세스에서 만든 수동 테스트 케이스, 사이클별 테스트 계획, 단계별 통과 또는 실패 기록, 테스트 실행에서 바로 등록하는 결함을 지원합니다. SAP의 지침에서는 파트너 전문가가 테스트 케이스를 준비하고, 고객의 현업 전문가가 이를 실행하고 결과를 Cloud ALM에 문서화합니다.