이번 달, 우리는 PostNL에서 Employee Central Payroll (ECP)/Employee Central (EC) 테스트 환경을 새로고침 하는 작업을 진행했습니다. 이들은 약 200,000개의 ‘Central Person’ 기록과 25만 개 이상의 직원 기록을 보유하고 있으며, 일부는 ECP에만 존재하지만, 대부분은 EC에도 포함되어 있습니다.
EC Instance Refresh는 SAP SuccessFactors 에서 제공하는 서비스로, 일반적으로 계약의 일부로 포함되어 있으며, 운영 인스턴스의 모든 데이터와 구성을 QA 또는 테스트 환경으로 업데이트합니다. 이에 따른 과제는 연결된 급여 시스템을 어떻게 처리할지입니다. 전체 시스템 복사(system copy) 는 후처리 작업에서 매우 번거로울 수 있으며, 테스트 시스템에서 운영 시스템과 동일한 디스크 공간이 필요합니다. 그러나 이를 생략하면 새롭게 새로고침된 EC 인스턴스와 ECP의 오래된 데이터 간의 불일치가 발생합니다. 여기서 EPI-USE Labs가 등장합니다. 문제를 해결하기 위해 여러 기술을 활용하는 방법에는 선택지가 있습니다.
약 4년 전에 이 프로세스를 마지막으로 수행했을 때, 우리는 Data Sync Manager™ (DSM)의 Object Sync™ for SuccessFactors Add-on 엔진을 활용하여 ECP 데이터를 가져오면서 동시에 SuccessFactors 데이터를 마스킹했습니다.
이번에는 Client Sync™ 엔진 (DSM Suite의 일부)과 DSM Data Secure™ for SuccessFactors Add-on을 사용하는 다른 접근 방식을 채택했습니다. DSM 의 Client Sync 기능은 일반적으로 대규모 시스템 변경 작업을 위해 Basis 팀에서 사용하며, 시스템 복사를 대체하기 위한 목적으로 사용됩니다.
이번에 다른 방식을 선택한 이유는 두 가지입니다.
준비하는 단계는 여전히 필요하지만, 이번 접근 방식은 훨씬 더 반복 가능하도록 설계되었습니다. EPI-USE Labs 컨설팅 팀의 구현 및 프로세스 정의 후, 고객 스스로 이 작업을 수행할 수 있거나, 대안적으로 관리 서비스를 제공할 수도 있습니다.기술적 프로세스: 데이터 갱신
우리는 SAP SuccessFactors가 SuccessFactors 운영 인스턴스에서 인스턴스 새로 고침된 이미지를 가져오는 것과 동시에 Client Sync 내보내기를 예약했습니다. Client Sync 제품 내의 특정 ‘HCM 전용’으로 셋팅된 프로파일을 사용하여 SAP의 다른 영역 데이터를 변경하지 않고 HCM 데이터만 업데이트할 수 있습니다. HCM 관련 커스터마이징을 선택적으로 포함할 수 있지만, 이번 사용 사례에서는 필요하지 않았습니다.
이번 프로젝트에서는 Client Sync의 ‘시간 분할’ 기능을 활용해 최근 2년간의 급여 클러스터 데이터만 가져오는 것이 중요했습니다. 그렇지 않으면 QA 시스템에 적합하지 않은 대량 데이터가 포함될 수 있었습니다.
내보내기가 완료된 후, 우리는 QA ECP 인스턴스에 데이터를 가져오는 작업을 시작했습니다. 이상적으로는 SAP 운영 팀이 데이터베이스 Re-do 로그를 비활성화하는 것이 좋지만, 불가능한 경우에는 Client Sync를 낮은 프로세스 수로 조정 할 수 있습니다. 우리는 네 개의 프로세스로 시도했지만, 데이터베이스 로그가 가득 차는 시점이 있었고, 다행히도 자동으로 복구되었습니다. 최악의 시나리오는 SAP 운영 팀이 일부 로그를 비우기 위해 기다리는 지연이 발생했을 수 있지만, 리두 로그가 비활성화되었을 때 성능이 더 나아졌을 것입니다. Client Sync와 관련된 오랜 권장 사항 중 하나이지만, HCM 데이터가 포함된 경우 더 유연하게 적용할 수 있습니다. HCM 데이터는 최근 2년간의 거래로 필터링되었을 경우 일반적으로 훨씬 더 작기 때문입니다.
가져오기가 완료된 후, 우리는 클라이언트에게 복제를 활성화하고 검증하도록 요청했습니다. 이 시점에서 ‘copy back’이 성공했음을 확인했으며, 이제 테스트 환경에서 민감한 개인 데이터가 노출되지 않도록 스크램블링 작업으로 넘어갔습니다. SAP 데이터 처리 계약(SAP Data Processing Agreement)에서 테스트 시스템에 실제 데이터가 존재해서는 안 된다고 명시하고 있다는 사실을 알고 계셨나요? Paul이 몇 년 전에 이에 대한 블로그를 작성한 바 있습니다. SuccessFactors에는 일부 마스킹 기능이 있지만, ECP의 클러스터 데이터와 같은 복잡한 데이터를 처리하지는 못합니다. 따라서, 이를 위해 DSM의 다른 기능인 Data Secure 가 필요했습니다.
DSM Data Secure™ for SuccessFactors Add-on 기능은 비교적 최근에 추가된 것으로, Object Sync SuccessFactors 이후 몇 년 후에 도입되었습니다. 이 기능은 ABAP 스택 Data Secure 스크램블링 엔진을 확장하여 OData API를 통해 EC로 익명화된 값을 읽고 전송할 수 있도록 지원합니다. 이번이 이 프로세스에서 이를 처음 활용한 사례입니다. 새로 고침된 클라이언트에서 Central Person 번호의 작업 목록을 작성했습니다. 마스킹은 이를 기반으로 진행되며, 여러 고용 기록(한 사람에게 여러 pernrs가 있는 경우)이 있는 경우에도 동일한 값으로 처리되도록 보장합니다.
우리는 너무 많은 데이터를 처리하기 전에 몇명 되지 않는 소수의 직원으로 마스킹 정책을 테스트하여 결과에 만족할 수 있도록 했습니다. 마스킹은 ECP 데이터뿐만 아니라 Infotypes, 클러스터, 그리고 이제는 비클러스터화된 급여 결과에 변경된 이름, 주소 등을 동시에 업데이트합니다. 최근 2년간의 급여 기록만 가져온 또 다른 이점은 마스킹해야 할 데이터가 줄어든다는 것입니다. 작업은 여러 백그라운드 프로세스에 분할할 수 있으며, OData 인터페이스에서 HTTPS 오류가 발생하면 다시 시작할 수 있습니다. 이 예에서는 데이터를 5000개 또는 10,000개 그룹으로 묶는 것이 최적이었으며, 각 실행에서 4-6개의 프로세스를 사용하는 것이 적절했습니다.
불가피하게 OData API에서 오류가 발생할 수 있으며, ECP에서는 데이터가 스크램블되었지만 EC에서는 완전히 처리되지 않는 경우가 있을 수 있습니다. 종종 이름을 포함하여 이러한 데이터 불일치가 발생합니다. Data Secure는 ‘같은 값이면 유지’ 논리를 사용하므로, 한 번 정렬되지 않은 데이터는 계속해서 정렬되지 않은 상태로 유지됩니다.
이를 해결하기 위해 우리는 이전 프로젝트에서 개발한 접근 방식을 사용했습니다. 직원 데이터를 "John Doe"와 같은 고정된 값으로 스크램블하여 데이터를 정렬한 후, 무작위 이름 생성 옵션으로 다시 처리했습니다. 우리는 또한 영향을 받은 모든 기록을 식별하는 데 도움이 되는 유틸리티를 개발했으며, 이 유틸리티는 곧 표준 DSM 유틸리티로 제공될 예정입니다.
이 작업을 마지막으로 수행했을 때, 인스턴스 새로 고침 후에도 남아 있는 문제를 해결하기 위해 몇 가지 유틸리티를 추가로 개발했습니다. 문서 링크가 그중 중요한 예입니다. 문서 자체는 더미 문서로 대체되지만, 문서 제목은 여전히 남아 있었습니다. EPI-USE Labs의 라이브러리 코드를 사용해 OData 요청을 생성함으로써, 문서 이름에 민감한 데이터를 포함할 수 있는 첨부 파일 유형(예: ‘Jane Doe의 의사 소견서’ 또는 징계 문서)을 선택적으로 삭제할 수 있었습니다.
또한 개인 사진을 삭제하는 유틸리티도 필요했습니다. 일부 직원이 단순히 프로필 사진(인스턴스 새로 고침 시 SAP에서 선택적으로 제거하는 항목)을 업로드한 것을 넘어 배경 전체를 개인 사진으로 설정한 경우가 있었기 때문입니다. 이는 세대적인 특징일 수도 있겠죠…
그리고 제가 가장 좋아하는 추가 기능: 첫 번째 새로 고침을 시작하기 전에, 조직은 기존 데이터 로드에서 수정된 후 유지 관리되던 특별한 급여 구역을 유지하고 있었습니다. 이 구역은 명확하고 독립적인 테스트 세트를 제공하기 위해 만들어졌습니다. 그러나 일부 실제 키를 기반으로 생성되었기 때문에, Object Sync로 가져온 실제 데이터와 충돌이 발생했습니다. 데이터를 유지하려고 하기보다는, 사용자 지정 변환을 구축하여 특정 직원을 이 전문 급여 구역으로 이동시켜 분리된 테스트 세트를 형성할 수 있도록 했습니다. 물론 언제든지 운영환경에서 데이터를 다시 복사할 수 있으며, Data Secure와 동일한 마스킹 정책을 적용해 해당 급여 구역에서 제거하고 실제 급여 구역으로 복원할 수 있습니다.
EC와 ECP를 사용하거나 EC와 연결된 온프레미스 급여 시스템이 있는 경우, EC에서 인스턴스 새로 고침을 수행할 때 ABAP 시스템을 어떻게 업데이트하시나요? 수천 명 규모 수준의 직원을 보유한 소규모 조직이라면 SAP 클라이언트 복사가 효과적일 수 있습니다. 하지만 급여 시스템이 전체 FI/CO 데이터를 포함하는 경우, 전체 시스템 복사에 의존해야 할 수도 있습니다.
DSM(Data Sync Manager)을 사용하면 전체 시스템 복사를 피할 수 있으며, HCM 관련 데이터만 가져오고 급여 및 근태 레코드를 필터링하여 최근 2년치 데이터만 가져오는 것도 가능합니다. 데이터를 확보한 후에는 데이터 프라이버시는 어떻게 처리하나요? 또는 테스트 시스템에서 항상 운영환경과 유사한 권한을 유지하시나요?
Jack Naudé
PostNL의 시니어 솔루션 컨설턴트로 활동 중인 Jack Naudé는 SAP HCM 및 SuccessFactors 전문가로서 20년 이상의 경력을 보유하고 있으며, 다국적 조직을 위한 맞춤형 HR 솔루션을 제공해 왔습니다. 그는 깊은 기술 지식과 HR 프로세스에 대한 전략적 통찰력을 바탕으로 효율성을 증대시키고, 워크플로를 자동화하며, 글로벌 규모에서 규정 준수를 보장하는 데 뛰어난 역량을 발휘합니다.
Paul Hammersley
EPI-USE Labs에서 ALM 제품의 수석 부사장인 Paul Hammersley는 테스트 데이터 관리, 시스템 환경 최적화, 아카이빙을 포함한 포트폴리오를 담당하고 있습니다. 그는 SAP 분야에서 20년 이상 탁월한 기술 전문가로 활동해 왔으며, Data Sync Manager (DSM)를 구현하고 고객들이 SAP 시스템 전반에 걸쳐 데이터를 관리할 수 있도록 돕는 풍부한 실무 경험을 보유하고 있습니다.