규칙 관리
이관할 테이블, 대상 스키마, 건수 제한, 직접 작성한 SQL, 정렬 기준, 연계 테이블을 규칙 하나로 묶습니다. 승인이 끝나면 그 시점의 규칙이 실행본으로 복사되어 이후 원본을 고쳐도 승인된 작업에는 영향이 없습니다.
TestBed는 운영 데이터베이스의 데이터를 신청과 승인 절차를 거쳐 개발·테스트 환경으로 옮깁니다. 옮기는 순간 성명·주민번호·전화번호는 형식만 남기고 다른 값으로 바뀝니다.
자릿수, 형식, 참조 관계를 유지한 채 지정한 컬럼의 값만 교체합니다. 테스트 화면과 검증 로직은 운영과 똑같이 동작하고, 실제 사람의 정보만 사라집니다.
성은 그대로 두고 이름 두 글자를 표본 명단의 값으로 교체합니다.
표의 값은 변환 방식을 설명하기 위한 예시이며 실제 데이터가 아닙니다. 주민등록번호 뒷자리는 화면 표기에서 가렸습니다.
계정마다 열 수 있는 화면이 다릅니다. 규칙을 짜는 사람, 승인하는 사람, 실행을 보는 사람의 권한을 따로 부여합니다.
이관할 테이블, 대상 스키마, 건수 제한, 직접 작성한 SQL, 정렬 기준, 연계 테이블을 규칙 하나로 묶습니다. 승인이 끝나면 그 시점의 규칙이 실행본으로 복사되어 이후 원본을 고쳐도 승인된 작업에는 영향이 없습니다.
운영과 테스트 스키마를 구분해 등록하고 노출 순서를 정합니다. 규칙은 여기 등록된 스키마 안에서만 대상을 고릅니다.
변환할 컬럼을 그룹으로 묶습니다. 문자형 컬럼만 대상으로 고를 수 있고, 그룹 단위로 사용 여부를 켜고 끕니다.
제목과 사유, 사용 기간, 결제라인, 적용할 규칙을 담아 신청합니다. 결제라인은 순서를 가진 승인자 목록으로 따로 관리하고, 한 사람이 반려하면 그 자리에서 신청이 끝납니다.
예약된 작업의 큐 상태를 보고 지금 실행, 취소, 재실행 예약을 지시합니다. 작업별 로그와 시도·처리 건수가 그대로 남습니다.
운영과 테스트의 테이블·프로시저·함수·패키지 정의를 비교합니다. 차이가 있으면 운영 기준 정의를 테스트 스키마 이름으로 바꿔 다시 만듭니다.
STEP 01
사용 목적과 사용 기간, 적용할 이관 규칙, 결제라인을 골라 신청서를 등록합니다. 누가 어떤 데이터를 언제까지 쓰는지가 이 한 장에 남습니다.
STEP 02
결제라인에 지정된 순서대로 승인이 넘어갑니다. 한 사람이 반려하면 사유와 함께 그 자리에서 종료되고, 승인 이력은 누가 언제 처리했는지까지 남습니다.
STEP 03
승인된 시점의 규칙을 실행본으로 복사해 둡니다. 이후 원본 규칙이 바뀌어도 이미 승인된 작업은 승인 당시 내용 그대로 실행됩니다.
STEP 04
정해진 시각에 그날 실행할 작업을 큐에 담고 순서대로 처리합니다. 일정 행 단위로 읽어 변환한 뒤 적재하며, 실패가 잦으면 스스로 멈추고 취소 지시도 실행 중에 반영됩니다.
STEP 05
사용 기간이 끝난 데이터는 삭제 작업으로 정리합니다. 같은 규칙이 다시 필요하면 재실행을 예약해 새 작업으로 만듭니다.
업무 시스템은 손대지 않습니다. TestBed가 운영에서 승인된 대상만 읽고, 변환한 결과를 테스트에 적재합니다.
운영 DBREAL
테스트 DBTEST
설정 DBCONF
아래 화면은 TestBed 관리 페이지의 항목과 테이블 구조를 바탕으로 예시 데이터를 넣어 재구성했습니다.
표를 좌우로 밀어 나머지 열을 볼 수 있습니다.
운영 데이터베이스 구성과 반출 절차, 개인정보 항목 범위에 맞춰 TestBed의 적용 범위와 구축 방식을 검토합니다.