운영 데이터 비식별 이관 시스템

테스트 데이터를 실제처럼,
개인정보는 남지 않게.

TestBed는 운영 데이터베이스의 데이터를 신청과 승인 절차를 거쳐 개발·테스트 환경으로 옮깁니다. 옮기는 순간 성명·주민번호·전화번호는 형식만 남기고 다른 값으로 바뀝니다.

REALTEST변환 예시
  • 성명김도현김서준
  • 주민901123-1●●●●●●900718-1●●●●●●
  • 전화010-2345-6789010-2345-1408
  • 성명박서연박지우
  • 주민880417-2●●●●●●881025-2●●●●●●
  • 전화010-8812-3345010-8812-7734
  • 성명이준호이하람
  • 주민950902-1●●●●●●950316-1●●●●●●
  • 전화010-4471-9028010-4471-2065
운영 원본테스트 적재본
비식별 변환

바뀌는 건 값뿐,
구조는 그대로 둡니다.

자릿수, 형식, 참조 관계를 유지한 채 지정한 컬럼의 값만 교체합니다. 테스트 화면과 검증 로직은 운영과 똑같이 동작하고, 실제 사람의 정보만 사라집니다.

WISE.HT_CUSTOMER운영 DB · 원본
CUST_NOCUST_NMREG_NOMOBILE_NO
C0001824김도현901123-1●●●●●●010-2345-6789
C0001825박서연880417-2●●●●●●010-8812-3345
C0001826이준호950902-1●●●●●●010-4471-9028
C0001827최민아021214-4●●●●●●010-3390-5512
TESTBED.HT_CUSTOMER테스트 DB · 적재본
CUST_NOCUST_NMREG_NOMOBILE_NO
C0001824김서준900718-1●●●●●●010-2345-1408
C0001825박지우881025-2●●●●●●010-8812-7734
C0001826이하람950316-1●●●●●●010-4471-2065
C0001827최유나020630-4●●●●●●010-3390-8841

성은 그대로 두고 이름 두 글자를 표본 명단의 값으로 교체합니다.

표의 값은 변환 방식을 설명하기 위한 예시이며 실제 데이터가 아닙니다. 주민등록번호 뒷자리는 화면 표기에서 가렸습니다.

관리 항목

대상 정의부터 사후 정리까지
화면 하나씩 나눠 둡니다.

계정마다 열 수 있는 화면이 다릅니다. 규칙을 짜는 사람, 승인하는 사람, 실행을 보는 사람의 권한을 따로 부여합니다.

01

규칙 관리

이관할 테이블, 대상 스키마, 건수 제한, 직접 작성한 SQL, 정렬 기준, 연계 테이블을 규칙 하나로 묶습니다. 승인이 끝나면 그 시점의 규칙이 실행본으로 복사되어 이후 원본을 고쳐도 승인된 작업에는 영향이 없습니다.

02

Schema 관리

운영과 테스트 스키마를 구분해 등록하고 노출 순서를 정합니다. 규칙은 여기 등록된 스키마 안에서만 대상을 고릅니다.

  • Real
  • Test
03

Column 변환 관리

변환할 컬럼을 그룹으로 묶습니다. 문자형 컬럼만 대상으로 고를 수 있고, 그룹 단위로 사용 여부를 켜고 끕니다.

  • 변환 그룹
  • 변환 구분
04

사용 신청과 결제라인

제목과 사유, 사용 기간, 결제라인, 적용할 규칙을 담아 신청합니다. 결제라인은 순서를 가진 승인자 목록으로 따로 관리하고, 한 사람이 반려하면 그 자리에서 신청이 끝납니다.

  • 신청서
  • 결제 순서
  • 승인 · 반려
05

이관 관리

예약된 작업의 큐 상태를 보고 지금 실행, 취소, 재실행 예약을 지시합니다. 작업별 로그와 시도·처리 건수가 그대로 남습니다.

  • 작업 큐
  • 실행 로그
  • 재예약
06

DB 비교와 동기화

운영과 테스트의 테이블·프로시저·함수·패키지 정의를 비교합니다. 차이가 있으면 운영 기준 정의를 테스트 스키마 이름으로 바꿔 다시 만듭니다.

  • TABLE
  • PROCEDURE
  • FUNCTION
  • PACKAGE
이관 절차

신청서 한 장이
테스트 데이터가 되기까지.

  1. STEP 01

    사용 신청

    사용 목적과 사용 기간, 적용할 이관 규칙, 결제라인을 골라 신청서를 등록합니다. 누가 어떤 데이터를 언제까지 쓰는지가 이 한 장에 남습니다.

    • 제목 · 사유
    • 사용 기간
    • 규칙 선택
  2. STEP 02

    순차 승인

    결제라인에 지정된 순서대로 승인이 넘어갑니다. 한 사람이 반려하면 사유와 함께 그 자리에서 종료되고, 승인 이력은 누가 언제 처리했는지까지 남습니다.

    • 결제 순서
    • 반려 사유
    • 승인 이력
  3. STEP 03

    규칙 확정

    승인된 시점의 규칙을 실행본으로 복사해 둡니다. 이후 원본 규칙이 바뀌어도 이미 승인된 작업은 승인 당시 내용 그대로 실행됩니다.

    • 실행본 복사
    • 대상 고정
  4. STEP 04

    예약 실행

    정해진 시각에 그날 실행할 작업을 큐에 담고 순서대로 처리합니다. 일정 행 단위로 읽어 변환한 뒤 적재하며, 실패가 잦으면 스스로 멈추고 취소 지시도 실행 중에 반영됩니다.

    • 예약 시각
    • 배치 커밋
    • 중단 · 취소
  5. STEP 05

    사용 종료

    사용 기간이 끝난 데이터는 삭제 작업으로 정리합니다. 같은 규칙이 다시 필요하면 재실행을 예약해 새 작업으로 만듭니다.

    • 삭제 작업
    • 재실행 예약
데이터 흐름

운영 DB 는 읽기만,
쓰기는 테스트 DB 에만.

업무 시스템은 손대지 않습니다. TestBed가 운영에서 승인된 대상만 읽고, 변환한 결과를 테스트에 적재합니다.

운영 DBREAL

  • 업무 스키마조회 전용
  • 객체 정의구조 조회

테스트 DBTEST

  • 테스트 스키마변환된 데이터
  • 동기화 객체운영 기준 정의

설정 DBCONF

  • 스키마 · 변환 그룹 · 규칙
  • 신청서 · 결제라인 · 승인 이력
  • 이관 작업과 실행 결과
관리 화면

실제 운영 항목을 기준으로
화면을 구성합니다.

아래 화면은 TestBed 관리 페이지의 항목과 테이블 구조를 바탕으로 예시 데이터를 넣어 재구성했습니다.

TestBed 관리페이지규칙 관리 · 예시 데이터

규칙 관리

검색어여신
번호규칙명Table대상 스키마변환연계이관 건수
1여신_기본세트HT_CUSTOMERWISE → TESTBED32전체
2여신_기본세트HT_ACCOUNTWISE → TESTBED1-50,000
3고객_마스터HT_GUARANTORWISE → TESTBED2110,000
4정산_월마감HT_SETTLE_DAYWISE → TESTBED--전체
연계를 지정한 테이블은 옮긴 행이 참조하는 다른 테이블의 데이터까지 함께 가져옵니다.

표를 좌우로 밀어 나머지 열을 볼 수 있습니다.

도입 문의

지금 쓰고 있는 테스트 데이터부터
함께 살펴보겠습니다.

운영 데이터베이스 구성과 반출 절차, 개인정보 항목 범위에 맞춰 TestBed의 적용 범위와 구축 방식을 검토합니다.