SAP 테스트 데이터 관리 완벽 가이드: 마스킹·익명화·서브세팅부터 규제까지

SAP 테스트 데이터 관리(Test Data Management)의 핵심 개념을 정리하고, 국내 규제 기준에서 무엇이 허용되는지, 그리고 가장 자주 간과되는 질문 — 마스킹한 데이터로도 검증 정확도를 지킬 수 있는가 — 에 답합니다.

실거래 데이터로 테스트해도 될까? SAP 테스트 데이터 마스킹과 규제 가이드

SAP 테스트를 준비하는 팀은 거의 항상 같은 모순에 부딪힙니다. 정확한 테스트를 하려면 운영(Production) 데이터를 써야 하는데, 운영 데이터에는 고객 정보, 급여, 재무 같은 민감 정보가 가득합니다. 마스킹을 하자니 데이터가 변형되어 "이렇게 가공한 데이터로 검증한 결과를 믿어도 되나" 하는 불안이 남고, 안전하게 가상 데이터만 쓰자니 정작 운영에서 터지는 문제를 못 잡습니다.

테스트 데이터, 왜 운영 데이터가 필요한가?

테스트를 위해 데이터를 직접 만들어 쓰는 팀이 많습니다. 하지만 손으로 만든 샘플 데이터나 합성 데이터(synthetic data)에는 구조적 한계가 있습니다.

첫째, 예외 케이스가 빠집니다. 실제 운영 데이터에는 특별 할인, 다중 통화 거래, 복잡한 세금 조건, 비표준 승인 흐름 같은 예외가 자연스럽게 섞여 있습니다. 사람이 만든 데이터는 '정상 케이스' 위주라, 정작 장애를 일으키는 엣지 케이스를 재현하지 못합니다.

둘째, 데이터 볼륨이 반영되지 않습니다. 월말 결산이나 대량 배치처럼 데이터 양 자체가 성능 문제를 일으키는 시나리오는, 소량의 샘플로는 검증이 불가능합니다.

그래서 검증 품질을 높이려면 결국 운영 데이터에 가까운 데이터가 필요합니다. 실거래 데이터가 왜 마이그레이션 검증의 핵심인지는 별도 글에서 자세히 다뤘습니다.

🔗 관련 글: SAP ERP 전환, 왜 실거래 데이터 기반 테스트가 필수인가?

문제는, 운영 데이터를 그대로 테스트 환경에 가져오는 순간 개인정보 보호 의무가 따라온다는 점입니다. 여기서 데이터 보호 기법이 등장합니다.

테스트 데이터 보호 3가지 방법: 마스킹·익명화·서브세팅

테스트 데이터를 안전하게 만드는 대표적인 기법은 세 가지입니다. 자주 혼용되지만 목적과 한계가 다릅니다.

실무에서는 이 셋을 조합합니다. 필요한 범위만 서브세팅하고, 그 안의 민감 필드를 마스킹하거나, 규제가 엄격한 경우 익명화하는 식입니다.

여기서 반드시 짚어야 할 원칙이 하나 있습니다. 참조 무결성(referential integrity)입니다. 거래처 이름을 마스킹할 때, 같은 거래처가 주문·청구·회계 전표에서 모두 동일하게 치환되지 않으면 데이터 간 연결이 깨집니다. 연결이 깨진 데이터로는 모듈을 넘나드는 E2E 검증이 불가능해집니다.

국내 규제는 무엇을 말하나

금융권은 테스트 데이터에 관해 명시적인 규정의 적용을 받습니다. 전자금융감독규정 제13조(전산자료 보호대책) 제1항 제10호입니다. 법제처에 등록된 규정 원문은 다음과 같이 규정합니다.

"이용자 정보의 조회·출력에 대한 통제를 하고 테스트 시 이용자 정보 사용 금지 (다만, 법인인 이용자 정보는 금융감독원장이 정하는 바에 따라 이용자의 동의를 얻은 경우 테스트 시 사용 가능하며, 그 외 부하 테스트 등 이용자 정보의 사용이 불가피한 경우 이용자 정보를 변환하여 사용하고 테스트 종료 즉시 삭제하여야 한다)"

즉 원칙은 '테스트 시 이용자 정보 사용 금지'이고, 불가피한 경우에 한해 ① 변환(마스킹) 후 사용 ② 테스트 종료 즉시 삭제라는 두 조건을 모두 충족해야 합니다. 실제로 금융위원회·금융감독원의 법령해석에서도, 운영시스템 오류 복구 시 계좌번호 등 이용자 정보를 변환하지 않고 사용하는 것은 동 규정 위반에 해당한다고 회신한 사례가 있습니다. 반대로 임의로 만든 ID와 거래 데이터만 사용해 실제 이용자 정보가 전혀 쓰이지 않는 경우에는 규정에 위반되지 않는다고 해석했습니다.

여기서 실무자가 주목해야 할 공식 해석이 하나 더 있습니다. 차세대·전환 시스템의 정합성 검증에 관한 금융위·금감원 법령해석입니다. 당국은 시스템 안전성 확보를 위해 부득이하게 이용자 정보를 테스트 용도로만 제한 사용 후 즉시 삭제하고, 운영시스템과 동일한 수준의 보안 대책과 내부통제 기준을 마련한 경우에 한해 이용자 정보를 사용한 정합성 검증을 허용한다고 밝혔습니다. 그러면서 그 정합성 검증의 성격을 이렇게 규정했습니다 — 실제 발생한 거래지시를 전환시스템으로 재처리하고 그 결과를 실거래 데이터와 비교하는 절차이며, 이용자 정보·실거래 데이터 없이는 효율적인 검증이 곤란하다는 것입니다.

정리하면, 국내 규제의 기준은 "실거래 데이터를 테스트에 쓰면 무조건 위반"이 아닙니다. 변환(마스킹)·목적 한정·사용 후 즉시 삭제·운영 수준 보안·내부통제 기준이라는 조건을 갖추면, 실거래 기반 정합성 검증이 허용될 수 있는 영역이 분명히 존재합니다. 따라서 테스트 데이터 전략은 '데이터를 어떻게 보호할 것인가'와 함께 '어떤 통제 절차로 정당성을 확보하고 증적을 남길 것인가'를 함께 설계해야 합니다.

*본 내용은 법제처 등록 규정 원문과 금융위원회·금융감독원의 공개된 법령해석을 근거로 정리한 일반 정보이며, 개별 사안의 적용은 규정 원문과 최신 내용을 꼭 확인하시기 바랍니다.

마스킹의 진짜 함정: 변형된 데이터로 한 검증을 믿을 수 있는가

대부분의 테스트 데이터 관리 논의는 "어떻게 안전하게 만드느냐"에서 멈춥니다. 그러나 테스트의 진짜 목적은 데이터를 안전하게 만드는 것이 아니라 시스템이 정확히 동작하는지 검증하는 것입니다. 그리고 마스킹은 이 검증 정확도와 정면으로 충돌할 수 있습니다.

보안 담당자는 "최대한 강하게 변환하라"고 하고, 테스터는 "운영과 똑같아야 검증이 된다"고 합니다. 변환을 세게 할수록 안전하지만 검증 신뢰도는 떨어지고, 약하게 할수록 검증은 정확하지만 재식별 위험이 커집니다. 이 상충 관계를 이해하지 못한 채 마스킹을 적용하면, '안전하지만 믿을 수 없는 테스트'라는 최악의 결과에 도달합니다. 구체적으로 네 가지 지점에서 문제가 발생합니다.

• 첫째, 계산 로직이 틀어집니다. 금액·수량·환율·세율 같은 숫자 필드를 무작위로 치환하면, 그 데이터로 돌린 결산·정산·수익 인식 결과가 운영과 달라집니다. 예를 들어 거래 금액을 임의의 값으로 마스킹하면 부가세 계산, 외화 평가, 원가 배부 결과가 전부 어긋나, 정작 검증하려던 계산 로직의 정상 여부를 판단할 수 없게 됩니다. 숫자 필드는 '가려야 할 민감 정보'인 동시에 '검증의 핵심 대상'이라는 이중성을 갖기 때문에, 단순 치환이 가장 위험합니다.

• 둘째, 참조 무결성이 깨집니다. 같은 거래처·고객·품목이 주문·청구·출하·회계 전표 등 여러 테이블에 걸쳐 존재하는데, 이들을 서로 다른 값으로 마스킹하면 데이터 간 연결이 끊어집니다. 연결이 끊기면 SD 매출 → MM 원가 → CO 정산 → FI 결산으로 이어지는 모듈 간 흐름이 중간에 단절되어, 정작 가장 많은 장애가 숨어 있는 '모듈 간 데이터 전달' 구간을 검증할 수 없습니다. 일관된 마스킹(consistent masking), 즉 동일 원본 값은 항상 동일한 변환 값으로 바꾸는 규칙이 반드시 필요한 이유입니다.

• 셋째, 데이터 분포와 형식이 달라집니다. 마스킹이 값의 길이·자릿수·코드 체계를 바꾸면, 운영에서는 통과하던 입력 검증(validation)이 테스트에서 엉뚱하게 실패하거나, 반대로 운영에서 걸러질 값이 테스트에서 통과합니다. 또한 특정 조건(예: 특정 국가 코드, 특정 세금 유형)에 집중된 데이터 분포가 마스킹으로 흐트러지면, 실제로는 빈번한 케이스가 테스트에서는 드물게 나타나 검증 커버리지에 구멍이 생깁니다.

• 넷째, 검증 기준값(expected result)이 사라집니다. 테스트의 본질은 "기대 결과와 실제 결과를 비교"하는 것입니다. 그런데 입력 데이터를 변형하면, 무엇이 올바른 결과인지에 대한 기준 자체가 모호해집니다. 운영에서 'A 거래는 B 결과'라는 사실이 있어도, 입력을 마스킹한 순간 그 'B'를 더 이상 정답으로 쓸 수 없게 되는 것이죠. 기준값이 없으면 테스트는 '오류 없이 돌아갔다'는 것만 확인할 뿐, '정확히 맞게 처리됐다'는 것은 증명하지 못합니다.

  

이 네 가지를 종합하면 결론은 분명합니다. "데이터를 안전하게 만드는 일(마스킹·익명화)"과 "그 데이터로 정확하게 검증하는 일"은 별개의 과제이며, 보호 기법만 고도화하고 검증 정확도를 함께 설계하지 않으면 테스트 자체가 신뢰를 잃습니다. 좋은 테스트 데이터 전략은 "얼마나 강하게 가렸는가"가 아니라, "가린 뒤에도 운영과 동일한 검증 결과를 얻는가"로 평가되어야 합니다.

S/4HANA 시대의 테스트 데이터: TDMS 단종 이후

이 문제는 S/4HANA 전환기에 더 커집니다. 과거 많은 기업이 쓰던 SAP TDMS(Test Data Migration Server)는 S/4HANA 환경에서 기술적으로 호환되지 않으며 사용이 승인되지 않은 상태입니다. 즉 S/4HANA로 가는 기업은 기존 테스트 데이터 확보 방식을 다시 설계해야 합니다.

게다가 RISE with SAP 같은 클라우드 환경에서는 운영 데이터를 테스트 시스템으로 직접 복사하기도 어렵습니다. 데이터 리프레시조차 SAP에 서비스 요청을 거쳐야 하므로, 테스트 데이터를 빠르게 확보하고 갱신하는 일이 온프레미스보다 까다로워집니다.

🔗 관련 글: SAP 테스트 전략 (1) ECC to S/4HANA Migration — 데이터 전환 검증 전략

🔗 배포 환경별 차이는 SAP S/4HANA Cloud 구축 방식: Public, Private, On-Premise 글을 참고하세요.

실거래 재현으로 안전성과 정확도를 동시에

결국 필요한 것은 두 마리 토끼를 함께 잡는 접근입니다. 민감 정보는 보호하되, 검증 결과는 운영과 동일하게 신뢰할 수 있어야 합니다.

PerfecTwin은 운영 환경의 실제 트랜잭션을 캡처해 테스트 환경에서 재현(replay)하고, 그 결과를 기준값과 비교 검증하는 방식으로 접근합니다. 핵심은 검증 정확도를 좌우하지 않는 범위에서 보호 조치를 적용하고, 현행 시스템과 신규 시스템의 처리 결과를 건별로 대조해 차이를 자동으로 잡아내는 데에 있습니다. 데이터를 단순히 화면에서 가리는 것이 아니라, "같은 입력에 같은 결과가 나오는가"를 검증의 중심에 두는 것입니다.

테스트 데이터 전략을 세울 때는 다음 세 질문을 함께 던지시기 바랍니다. 우리 데이터 보호 방식이 규제 요구를 충족하는가, 보호 처리 후에도 검증 정확도가 유지되는가, 그리고 이 과정을 감사에 대응할 수 있도록 증적으로 남기고 있는가.

세 질문에 모두 "그렇다"고 답할 수 있을 때, 테스트 데이터는 리스크가 아니라 품질의 토대가 됩니다.

PerfecTwin 무료 데모를 신청하시면, 운영 실데이터 기반의 캡처·재현·비교 검증이 실제로 어떻게 작동하는지 직접 확인하실 수 있습니다.