SAP 테스트 데이터 관리: 마스킹된 운영 규모 데이터

SAP 테스트 데이터 관리는 실제 사람의 정보를 노출하지 않으면서 모든 테스트 시스템에 운영 데이터처럼 움직이는 데이터를 주는 방법입니다. 제 원칙은 단순합니다. 마스킹하되, 물량과 현실성은 운영 수준으로 유지하는 것입니다.

얇게 손으로 만든 데이터는 중요한 결함을 가립니다. 마스킹하지 않은 운영 데이터는 고객, 공급업체, 직원 기록을 운영 환경보다 통제가 약한 시스템에 둡니다.

테스트 데이터는 더 큰 테스트 계획의 한 부분입니다. 테스트 유형, 책임자, SAP Activate에서의 위치는 SAP 테스트 완전 정리 가이드에서 다룹니다.

테스트는 그 데이터가 일으킬 수 있는 문제만 찾아낼 수 있습니다. 미결 항목이 5건인 고객과 5만 건인 고객은 다르게 움직이고, 테스트 클라이언트에 아무도 만들지 않은 가격 조건은 테스트 클라이언트에서 절대 실패하지 않습니다.

제가 가장 자주 본 테스트 실패는 통합 테스트(SIT)와 사용자 인수 테스트(UAT)에서 테스트가 충분하지 않은 것입니다. 부실한 테스트 데이터는 그런 일이 조용히 일어나는 경로 중 하나입니다. 테스트 케이스는 실행되고 결과는 녹색으로 보이지만, 실패했어야 할 케이스에는 실패할 데이터가 아예 없었던 것입니다.

그래서 저는 운영 수준의 데이터를 고집합니다. 여기에는 네 가지 의미가 있습니다.

1. 물량. 테이블 크기가 운영 환경에 가까워야 보고서, 배치 작업, 검색이 현실적인 행 수에서 실행됩니다.
2. 다양성. 운영 환경에 실제로 있는 특이한 레코드들입니다. 차단된 공급업체, 부분 출하, 대변 메모, 외화, 오래된 미결 항목.
3. 이력. 연령 분석, 감가상각, 연말 작업이 의미를 가질 만큼 충분한 마감 기간.
4. 무결성. 복사와 마스킹 후에도 모듈 사이에서 올바르게 연결되는 전표.

물량은 성능에 가장 중요합니다. 성능 테스트는 반드시 Go-Live 전에 해야 하며, 제 경험상 중요한 것은 많은 사용자가 동시에 작업하는 동시성 테스트입니다.

거의 비어 있는 데이터베이스에서 하는 동시성 테스트로는 증명되는 것이 거의 없습니다. 이런 테스트를 구성하는 방법은 SAP 성능 테스트 가이드에서 다룹니다.

테스트 시스템에 있는 운영 데이터도 여전히 개인정보입니다. 테스트 시스템과 품질 시스템은 보통 운영 환경보다 접근 범위가 넓고, 마스킹은 바로 그 위험을 막기 위해 존재합니다.

EU 일반개인정보보호법(GDPR)은 대부분의 조직이 기준으로 삼는 규정이며, 여러 국가의 법도 비슷한 방향을 따릅니다. GDPR 전문 제26항은 모든 SAP 팀이 알아야 할 구분을 제시합니다.

1. 가명처리된 데이터는 여전히 개인정보입니다. 매핑 테이블 같은 추가 정보로 데이터를 특정인에게 다시 연결할 수 있다면 규정이 계속 적용됩니다.
2. 익명 데이터는 적용 범위 밖입니다. 더 이상 누구도 식별할 수 없는 데이터는 대상이 아닙니다.

실무적인 결론은 이렇습니다. 대부분의 마스킹은 익명 데이터가 아니라 가명처리된 데이터를 만듭니다. 마스킹한 테스트 시스템에도 접근 통제, 목적, 보존 규칙이 필요합니다. 감사인이 묻고 나서가 아니라 첫 복사 전에 개인정보 보호 책임자(DPO)와 마스킹 규칙을 합의하십시오.

흔히 쓰는 경로는 다섯 가지입니다. 테스트 단계마다 필요한 것이 다르기 때문에 대부분의 프로젝트는 둘 이상을 씁니다.

적합성을 가르는 기준으로 비교해 표에 정리했습니다.

방식	얻는 것	물량	개인정보 처리	가장 잘 맞는 곳
전체 시스템 복사	모든 클라이언트와 테이블을 포함한 운영 환경의 정확한 복사본	전체	복사 후, 사용자에게 접근 권한을 주기 전에 마스킹 실행 필요	성능 테스트, 모의 전환, 컷오버 리허설
클라이언트 복사	시스템 안에서 또는 시스템 간에 클라이언트 하나를 복사, 마스터 데이터와 트랜잭션 데이터 포함 여부는 복사 프로필이 결정	전체 또는 커스터마이징만	애플리케이션 데이터를 복사하면 시스템 복사와 같음	새 테스트 또는 교육 클라이언트, 클라이언트를 알려진 상태로 초기화
SAP Test Data Migration Server(TDMS)	기간이나 조직 단위로 선택하고 스크램블링을 적용한 축소 복사본	축소	도구 안의 스크램블링 규칙	이미 라이선스를 보유한 기존 SAP Business Suite 랜드스케이프
파트너의 선택적 복사 도구	선택한 비즈니스 오브젝트나 데이터 일부를 필요할 때 복사하며 전송 중 마스킹	축소, 대상 지정	복사 중에 적용되는 도구 안의 마스킹 규칙	정기 리프레시, 회귀 테스트 데이터, 결함 재현
직접 만들거나 마이그레이션한 데이터	스크립트, 마이그레이션 로드, 수작업 입력으로 만든 데이터	만드는 만큼	처음부터 만들었다면 실제 개인정보 없음	초기 단위 테스트, Go-Live 전 그린필드 프로젝트

전체 시스템 복사와 클라이언트 복사

전체 시스템 복사는 테스트에 쓸 수 있는 가장 현실적인 데이터를 줍니다. 동시에 운영 환경이 가진 모든 개인정보 위험도 그대로 복사합니다. 이 방식을 쓴다면 마스킹이 실행되고 확인될 때까지 시스템을 잠가 두십시오.

클라이언트 복사는 클라이언트를 만들고 초기화하는 일상적인 도구입니다. 중요한 결정은 복사 프로필입니다. 구성만 옮길지, 마스터 데이터와 트랜잭션 데이터까지 함께 옮길지를 복사 프로필이 정하기 때문입니다.

SAP Test Data Migration Server

SAP Test Data Migration Server(TDMS)는 운영 데이터로 축소된 비운영 시스템을 만들고 민감한 필드를 스크램블링합니다. SAP Business Suite에서 성장한 도구이며, SAP Help Portal의 현재 문서는 릴리스 4.0 SP14 기준입니다.

현재 S/4HANA 릴리스에 대한 TDMS 지원 범위나 공식 후속 제품에 대한 SAP의 공식 입장은 찾지 못했습니다. TDMS에 의존할 계획이라면 RISE with SAP를 포함해 귀사의 목표 릴리스와 배포 모델을 지원하는지 SAP에 서면으로 문의하십시오.

SAP Landscape Transformation과 셸 복사

SAP Landscape Transformation은 SAP가 선택적 데이터 전환에 사용하는 분석 및 변환 도구 모음입니다. SAP Learning은 셸 전환을 마스터 데이터와 트랜잭션 데이터 없이 운영 시스템을 복사한 뒤 S/4HANA로 전환하는 것으로 설명합니다.

같은 아이디어가 테스트 데이터에도 도움이 됩니다. 셸은 비즈니스 데이터 없이 운영 환경의 저장소와 구성만 제공하고, 그다음 테스트에 필요한 데이터만 채우면 됩니다.

여러 파트너 제품이 선택한 비즈니스 데이터를 SAP 테스트 시스템으로 복사하면서 마스킹합니다. 아래는 공급업체 자체 사이트에서 주장을 확인할 수 있었던 제품이며, 순서에 의미는 없습니다.

1. EPI-USE Labs Data Sync Manager. SAP ABAP 랜드스케이프 전반에서 데이터를 복사하고 마스킹하는 제품군으로, 경량 클라이언트, 오브젝트 단위 복사, 사전 정의 규칙을 통한 마스킹을 포함합니다. EPI-USE Labs는 Data Sync Manager가 SAP S/4HANA 및 S/4HANA Cloud와의 통합 인증을 받았으며 RISE with SAP와 함께 작동한다고 밝힙니다.
2. SNP Kyano Test Data Organizer. 시스템 전체가 아니라 테스트에 필요한 데이터만 추출하고, 데이터를 제공하는 과정에서 민감한 데이터를 마스킹합니다. SNP는 Test Data Organizer가 RISE with SAP Private Cloud Edition과 호환된다고 설명합니다.
3. Qlik Gold Client. 선택한 트랜잭션 데이터를 운영 환경에서 비운영 대상으로 복사하고 동기화하며, 기존 시스템에는 정적 마스킹을, 전송 중인 데이터에는 동적 마스킹을 적용합니다.
4. Natuvion DCS Protect. 개인정보를 찾아내고 테스트, 품질, 개발, 교육 시스템에서 익명화나 가명처리를 적용합니다. Natuvion은 이 제품을 테스트 마이그레이션과 지속적인 운영용으로 소개하지만 해당 페이지에 S/4HANA는 언급되어 있지 않으므로 지원 범위를 직접 확인하십시오.

구매 전에 각 공급업체에 귀사 시스템을 기준으로 다음 질문에 답하도록 요청하십시오.

1. 현재 어떤 S/4HANA 릴리스와 배포 모델을 지원합니까?
2. 데이터가 운영 환경을 떠나기 전에 마스킹합니까, 대상 시스템에 도착한 뒤에 마스킹합니까?
3. 연결된 시스템 사이에서 마스킹이 일관되게 유지되어, S/4HANA에서 마스킹된 고객이 CRM이나 데이터 웨어하우스의 같은 고객과 일치합니까?
4. 운영 물량 기준으로 회사 코드 하나를 리프레시하는 데 얼마나 걸립니까?
5. 커스텀 테이블이나 필드를 추가하면 마스킹 규칙은 누가 유지보수합니까?

테스트 단계마다 데이터가 필요한 이유가 다릅니다. 제가 S/4HANA 프로젝트에서 테스트 데이터를 계획할 때 출발점은 다음과 같습니다.

테스트 단계	데이터가 해야 할 일	일반적인 출처
단위 테스트	개발자가 오브젝트 하나가 작동함을 증명할 수 있게 함	직접 만든 데이터 또는 작은 마스킹 데이터 일부
통합 테스트 라운드	모듈과 인터페이스를 넘나드는 전체 프로세스 체인을 실행	마스킹된 운영 수준 복사본 또는 선택적 복사
사용자 인수 테스트 라운드	현업 사용자가 자기 사례를 알아볼 수 있도록 그들의 데이터처럼 보임	마스킹된 운영 수준 데이터, 라운드마다 리프레시
회귀 테스트	실행 간 결과를 비교할 수 있도록 안정적으로 유지	초기화 가능한 고정 데이터 세트와 리프레시 계획
성능 테스트	동시성 결과가 의미를 갖도록 운영 물량과 일치	전체 마스킹 복사본 또는 운영 규모의 물량
모의 전환과 컷오버 리허설	실제 데이터 형태로 마이그레이션을 증명	운영 환경 전체 복사본, 핵심 팀 외부 인원이 접근하는 경우 마스킹

UAT에는 각별한 주의가 필요합니다. 사용자 인수 테스트의 책임은 현업에 있어야 하며, 제 생각에는 최소 6~8주가 필요합니다.

사용자가 알아볼 수 있는 데이터를 주십시오. 이름이 마스킹되어 있더라도 그들 자신의 고객, 자재, 가격표여야 합니다. 진행 방법은 SAP 사용자 인수 테스트 가이드에서 다룹니다.

모의 전환도 같은 논리를 따릅니다. 브라운필드 전환에서 저는 모의 전환을 세 번 계획하며, 각각 최근의 운영 환경 복사본으로 실행해야 합니다.

제 경험상 데이터 마이그레이션은 프로젝트 공수의 30~40%를 차지합니다. 그러니 이 실행들을 위한 데이터 접근은 마이그레이션 팀과 함께 계획하십시오. 모의 로드가 어떻게 맞물리는지는 SAP 데이터 마이그레이션이 실패하는 이유에 관한 제 글에서 설명합니다.

두 랜드스케이프, 두 리프레시 계획

프로젝트 기간 동안 저는 랜드스케이프를 두 개로 분리해 운영합니다. 하나는 프로젝트용, 하나는 일상 운영(BAU)용입니다. 그러면 운영 지원 변경과 프로젝트 변경을 따로 테스트할 수 있습니다.

랜드스케이프마다 자체 테스트 데이터 계획이 필요합니다. BAU 테스트에는 오늘의 운영 환경에 가까운 데이터가 필요합니다. 운영 지원 수정은 오늘의 문제에 대응하기 때문입니다.

프로젝트 테스트에는 새 설계에 맞는 데이터가 필요하며, 이는 전환된 복사본이나 선택적 로드일 수 있습니다. 각각의 리프레시 일정을 따로 두어, 한쪽의 리프레시가 다른 쪽에서 아직 필요한 테스트 데이터를 지워 버리는 일이 없게 하십시오.

테스트는 프로젝트 공수의 약 35%를 차지합니다. 테스트 데이터는 SIT 전 주가 아니라 그 공수 안에서 계획하십시오.

저라면 다음 순서를 따릅니다.

1. 원칙을 서면으로 합의합니다. 운영 수준의 마스킹된 데이터라는 원칙을 프로젝트 스폰서, 개인정보 보호 책임자, 현업 오너가 승인합니다.
2. 개인정보와 민감한 데이터를 찾습니다. 고객, 공급업체, 직원, 은행 정보, 연락처, 자유 텍스트 필드, 첨부 파일, 그리고 이를 담고 있는 모든 커스텀 테이블.
3. 마스킹 규칙을 작성합니다. 필드별로 무엇을 대체하고, 유지하고, 삭제할지 정하고, 연결된 시스템 사이에서 대체값을 일관되게 유지합니다.
4. 데이터를 각 테스트 단계에 매핑합니다. 위의 표를 출발점으로 삼고, 성능 테스트와 동시성 테스트의 물량부터 산정합니다.
5. 복사 방식과 도구를 고릅니다. 물량이 중요한 곳에는 전체 복사, 속도와 빈도가 중요한 곳에는 선택적 복사를 쓰고, 귀사 릴리스에 대한 도구 지원 여부를 확인합니다.
6. 리프레시 일정을 정합니다. 랜드스케이프마다 하나의 계획을 두고, 각 SIT와 UAT 라운드, 각 모의 전환 전에 리프레시 시점을 맞춥니다.
7. 마스킹이 확인될 때까지 접근을 잠급니다. 마스킹 점검을 통과하기 전에는 핵심 기술 팀 외에 누구도 새 복사본에 로그인하지 않습니다.

그다음 이를 게이트로 만드십시오. 사이클별 전략, 진입 기준, 종료 기준은 S/4HANA 테스트 전략 가이드에 정리했으며, 테스트 데이터 준비 상태는 모든 라운드의 진입 기준에 들어가야 합니다.

구체적인 다음 단계는 이렇습니다. 현재 운영 데이터 복사본을 보관하고 있는 모든 비운영 시스템을 나열하고, 그중 어느 것이 마스킹되었는지 확인하십시오.

S/4HANA 프로젝트의 테스트 데이터 접근 방식이나 테스트 계획에 대해 독립적인 의견이 필요하시면 여기에서 연락하실 수 있습니다.

SAP 테스트 데이터 관리란 무엇입니까?

SAP 테스트 시스템의 데이터를 계획하고, 만들고, 복사하고, 마스킹하고, 리프레시하는 방법입니다. 목표는 봐서는 안 될 사람에게 실제 개인정보를 노출하지 않으면서 물량과 현실성 면에서 운영 데이터처럼 움직이는 데이터입니다.

SAP 테스트에 운영 데이터를 사용해도 됩니까?

마스킹한 뒤에만 가능하며, 그때도 접근 통제가 필요합니다. GDPR에서 가명처리된 데이터는 여전히 개인정보이므로, 마스킹한 복사본에도 목적, 접근 규칙, 보존 규칙이 필요합니다. 첫 복사 전에 개인정보 보호 책임자와 마스킹 규칙을 합의하십시오.

SAP TDMS는 S/4HANA에서도 여전히 사용할 수 있습니까?

SAP Help Portal의 현재 TDMS 문서는 릴리스 4.0 SP14 기준이며, TDMS는 SAP Business Suite에서 성장한 도구입니다. 현재 S/4HANA 릴리스에 대한 지원 범위에 관한 SAP의 공식 입장은 찾지 못했습니다. TDMS를 전제로 계획하기 전에 SAP에 서면으로 문의하십시오.

선택적 SAP 테스트 데이터를 만드는 도구에는 무엇이 있습니까?

SAP Test Data Migration Server와 함께 EPI-USE Labs Data Sync Manager, SNP Kyano Test Data Organizer, Qlik Gold Client 같은 파트너 제품이 있습니다. Natuvion DCS Protect는 테스트 시스템의 데이터 익명화와 가명처리에 초점을 둡니다. 각 제품을 귀사의 S/4HANA 릴리스와 배포 모델에 맞춰 확인하십시오.

SAP 성능 테스트에는 테스트 데이터가 얼마나 필요합니까?

운영 수준의 물량이 필요합니다. 성능 문제는 실제 테이블 크기와 많은 동시 사용자 아래에서 드러나므로, 얇은 데이터 세트로 하는 테스트로는 증명되는 것이 거의 없습니다. 성능 테스트와 동시성 테스트에는 보통 운영 환경의 전체 마스킹 복사본을 사용합니다.