건수가 적으면 실데이터를 써도 되나요?

건수와 보호 의무는 별개입니다. 1건이라도 실명과 연락처가 시험 계정에 보이면 승인 없는 반출로 보는 편이 맞습니다.

개발자 PC로 파일을 받아도 되나요?

받지 않는 쪽을 기본으로 둡니다. 꼭 필요하면 승인서에 PC 식별과 파기일을 적고, 시험 서버 안에서 조회하는 방식을 먼저 검토하세요.

마스킹하면 결함 재현이 안 되지 않나요?

식별자를 가짜 값으로 바꿔도 업무 상태와 금액 구간이 남으면 대부분의 시나리오는 재현됩니다. 재현이 꼭 실명을 필요로 하는 케이스는 예외 사유와 함께 최소화합니다.

운영 전환 데이터와 시험 데이터를 같게 두나요?

목적을 나눕니다. 시험은 가린 데이터, 전환 리허설은 별도 승인된 구간. 둘을 한 서버에 섞으면 어느 쪽이 실데이터인지 구분이 안 됩니다.

시험 데이터 마스킹 정하기 - 운영 반출 범위와 승인 칸

운영 데이터를 시험 서버에 그대로 복사해도 된다는 말은 틀린 전제입니다. 시험 계정으로 실명, 계좌, 전화가 보이면 그 환경은 이미 보호 대상이죠. 개발, 검증, 연계로 복사본이 세 벌이면 나중에 지울 곳도 세 벌입니다. 마스킹을 오픈 2주 전에 처음 꺼내면 변환 규칙이 없어 일정은 밀리고, 담당자는 엑셀에서 열을 지우기 시작하죠. 지운 열과 남긴 열이 섞이면 결함 재현도 깨져요. 이번 포스팅에서는 어떤 컬럼을 가리고, 누가 반출을 승인하며, 리허설을 몇 번 돌릴지를 자세히 다뤄보도록 하겠습니다. 연계 시험 전에 데이터 반출 공문을 쓰시는 분이라면 승인 칸부터 보시면 됩니다.

칸	적는 내용	비었을 때
대상	테이블, 건수, 기간	전체 덤프가 나감
변환	컬럼별 방식과 샘플 전후	키 조인이 깨지거나 실명이 남음
승인	정보보호 담당 이름과 날짜	요청과 승인이 같은 사람
파기	삭제일과 확인 담당	프로젝트 종료 후에도 복사본이 남음
리허설	14일 전 시간 측정, 7일 전 시나리오	오픈 전날 첫 수행이 됨

운영 데이터를 시험으로 옮기기 전에 채울 칸

시험 서버라고 운영 복사본을 써도 되나?

보이지 않는 서버가 아닙니다. 화면에서 실명이 보이면 보호 범위는 운영과 같습니다.

시험은 실패를 허용하는 환경이라는 말과, 개인정보를 덜 지켜도 된다는 말은 다릅니다. 계정 30개를 개발자에게 나눠 주면 그 30개 화면이 조회 경로예요.

조회 1번에 이름, 전화, 계좌가 함께 나오면 복사본의 위험은 운영 조회와 같은 급으로 봅니다. 개발 서버, 검증 서버, 연계 서버로 복사본이 3벌이면 유출 경로도 3벌입니다.

Risk(위험) 대장에 데이터 반출을 안 올리면, 위험 목록은 일정만 있고 정보 보호는 빈칸이에요. 빈칸인 채로 오픈 10일 전에 보안 점검이 들어오면, 점검 지적 1건이 데이터 재적재를 요구합니다.

재적재는 보통 2일에서 4일이 걸리고, 그 일수는 임계 일정에서 빠집니다. 복사가 편한 이유만으로 운영 덤프를 시험에 올리지 마세요.

어떤 컬럼을 가리고 어떤 값을 남기나?

식별자는 형식을 유지한 가짜 값으로 바꿉니다. 건수와 금액 분포처럼 시험에 필요한 통계는 남깁니다.

가릴 후보는 이름, 전화, 메일, 계좌, 주민등록번호, 상세 주소입니다. 남길 후보는 상태 코드, 금액 구간, 일자, 조직 코드처럼 업무 흐름을 재현하는 값이죠.

주문 번호처럼 테이블을 잇는 키는 양쪽을 같은 규칙으로 바꿔야 조인이 깨지지 않습니다. 부모만 바꾸고 자식은 운영 키 그대로면, 시험은 첫 조회에서 실패해요.

실패를 데이터 결함으로 오해하면 개발자가 쿼리를 고치고, 고친 쿼리는 운영에서 다시 틀어집니다. QA vs QC로 보면 마스킹 규칙은 시험 케이스보다 먼저 확정할 산출물입니다.

규칙 표에는 컬럼명, 변환 방식, 샘플 전후 1건, 예외 사유를 남기세요. 예외로 실데이터를 남기는 컬럼은 0을 목표로 하고, 남기면 승인자 이름을 같은 줄에 적습니다.

이름 없는 예외는 다음 복사 때 그대로 실데이터가 됩니다.

반출 승인은 누가 어디에 남기나?

요청, 보안 승인, 파기 예정일. 세 칸이 없는 복사 작업은 승인 없는 반출입니다.

반출 요청서에 필요한 칸은 많습니다만, 비우면 안 되는 칸은 세 개입니다. 무엇을 몇 건 가져가는지, 누가 승인했는지, 언제 지울지.

건수를 안 적으면 테이블 전체가 나가죠. 승인이 정보보호 담당이 아니라 개발 PL이면, 요청과 승인이 같은 손이 됩니다.

같은 손의 승인은 나중에 점검에서 승인으로 인정되지 않는 경우가 많아요. 파기일을 오픈일 또는 시험 종료 후 7일로 적고, 그 날짜를 일정에 작업으로 넣으세요.

작업이 없으면 복사본은 프로젝트가 끝나도 디스크에 남습니다. 남은 복사본은 안정화 계획 기간의 인수 항목이 아니라 미파기 지적입니다.

공문 없이 메신저로 덤프 파일을 주고받으면, 그 파일의 보관 위치가 승인서에 안 남아요. 위치가 안 남으면 파기 확인도 불가능합니다.

리허설은 몇 번이 적당하나?

변환 리허설 1회, 업무 시나리오 리허설 1회. 오픈 전 밤에 처음 돌리는 변환은 일정 사고가 됩니다.

마스킹을 오픈 전날 밤에 처음 돌리면 두 가지가 동시에 터집니다. 변환 시간이 예상 4시간을 넘어 8시간이 되거나, 키 불일치로 시나리오 10건 중 4건이 실패하죠.

둘 다 당일 조치가 어렵습니다. 리허설은 본수행 14일 전과 7일 전, 두 번으로 나누세요.

첫 번째는 건수와 소요 시간, 실패 행 수. 두 번째는 검수 시나리오 8건이 변환본에서 끝까지 도는지.

검증(Validation) 시나리오가 실데이터 전제로 적혀 있으면, 변환본에서는 기대값이 바뀝니다. 기대값을 변환 후의 샘플로 다시 적지 않으면 합격 기준이 운영 값에 묶여 있어요.

묶인 기준은 마스킹을 풀라는 압력으로 돌아옵니다. 그 압력에 예외 컬럼을 늘리면 리허설의 의미가 사라집니다.

엑셀로 지운 데이터는 왜 재현이 깨지나?

손으로 지운 파일은 규칙이 없습니다. 같은 결함을 다음 날 다시 만들 수 없어요.

일정이 밀리면 담당자가 상위 1,000건만 엑셀로 받아 이름을 지웁니다. 그 파일로 결함을 재현하면 당일은 넘어가죠.

다음 날 다른 사람이 받은 파일은 지운 열이 다릅니다. 결함 3건이 재현 불가가 되고, 재현 불가는 조치 완료로 오해됩니다.

조치 완료로 닫힌 결함은 오픈 후에 같은 증상으로 돌아와요. 변환은 스크립트나 배치처럼 같은 입력에 같은 출력이 나오는 방식이어야 합니다.

수행 로그에 입력 건수, 출력 건수, 제외 건수, 수행 시각을 남기세요. 네 숫자가 없으면 그 변환은 일회성 작업입니다.

일회성 작업은 데이터 이행 리허설과 따로 놀고, 따로 노는 두 작업은 오픈 주에 서로 다른 건수를 보고합니다. 건수가 다르면 이행 완료 판정을 내릴 수 없습니다.