작업이 끝난 뒤 데이터는 어떻게 처리하는가
민감하면서 재사용 불가능한 것은 하드 삭제, 비민감하면서 재사용성이 높은 것은 구조화해서 경험 라이브러리에 침전, 비민감하면서 재사용 불가능한 공학 쓰레기는 바로 정리, 강한 민감이지만 마스킹 가능한 것은 마스킹 후 구조와 로직만 남긴다.
데이터 민감도, 재사용 가치, 컴플라이언스 제약 세 차원으로 작업이 생산한 모든 상태를 분류한다.
1층 · 4사분면 상태 분류
| 사분면 | 정의 | 전형적 예시 | 처치 |
|---|
| 1사분면 | 민감하고 재사용 불가 | 고객 개인정보, 결제 일련번호, 계약 원본 | 컴플라이언스 제약을 받으므로 보존 기한 정책에 따라 삭제 또는 아카이빙 |
| 2사분면 | 비민감하지만 재사용성 높음 | 분석 지표 기준, 계산 파라미터 설정, 최적 모델 파라미터 조합 | 작업 공간에서 추출해 경험 라이브러리에 저장 |
| 3사분면 | 비민감하고 재사용 불가 | 중간 계산 결과, 임시 파일 인덱스, 폐기된 로직 분기 | 작업 종료 시 바로 정리 |
| 4사분면 | 강한 민감이지만 마스킹 후 재사용 가능 | 고객 이름이 포함된 분석 리포트 | 마스킹 후 리포트 구조와 분석 로직을 남겨 템플릿 참고용으로 |
2층 · 업무 경험의 구조화 침전
올바른 방식은 작업마다 경험 추출 체크리스트를 유지하며 완전한 폐루프를 도는 것이다:
- 작업 종료 전, 시스템이 이번 실행의 설정 스냅샷, 계산 기준, 파라미터 조합, 예외 처리, 회신 경로를 자동으로 스캔
- 템플릿에 따라 경험 요약으로 추출 (작업 실행 스냅샷 → 〔시스템 자동 스캔〕→ 경험 요약〔템플릿 기반 추출〕)
- 요약을 경험 라이브러리에 저장
- 다음 동종 작업이 시작되기 전, 시스템이 자동으로 경험 라이브러리를 검색해 관련 항목을 작업 설정에 주입 (폐루프 적용 / 자동 검색 주입)
3층 · 삭제의 실행과 검증 폐루프
| 컴플라이언스 요구 | 내용 | 반례 vs 정례 |
|---|
| 1. 복구 불가능성 | 논리 삭제가 아니라 덮어쓰기를 사용해, 어떤 롤백 메커니즘으로도 데이터를 복원할 수 없게 보장 | ✗ UPDATE table SET is_deleted = 1(롤백으로 복원되기 쉬움) / ✓ 0x00 0x00 0x00 0x00 물리적 말소로 복구 불가 |
| 2. 캐스케이드 영향 검사 | 테이블 하나를 삭제하기 전에 상·하류에 이 데이터에 의존하는 작업이 없는지 확인하고, 삭제 후에는 시스템이 모든 연관 작업의 무결성이 손상되지 않았는지 검증 | 상류 의존 ←검증→ 대상 데이터 ←검증→ 하류 작업 |
| 3. 삭제 감사 로그 | 누가, 언제, 왜, 어떤 데이터를 삭제했는지 기록 | 로그 자체가 데이터와 함께 지워져서는 안 된다 |
이 세 가지를 못 하면 데이터베이스를 비웠더라도 컴플라이언스 관문을 통과하지 못한다.
핵심 통찰
- 「전부 삭제」와 「전부 보존」은 같은 오류의 두 형태다 — 둘 다 판단을 포기한 것이다. 전부 삭제는 재사용 가능한 업무 경험을 쓰레기로 버리고, 전부 보존은 민감 데이터를 시한폭탄으로 만든다. 진짜 공학 능력은 분류 기준이 있고 그것을 자동으로 실행할 수 있는 것에서 드러나지, 한쪽 극단을 골라 편하게 가는 데 있지 않다.
- 상태를 남길지 말지는 저장 비용 문제가 아니라 생명주기 문제다 — 묻는 것은 「디스크가 충분한가」가 아니라 「이 상태가 업무적으로 아직 생명이 있는가」다. 민감도 / 재사용 가치 / 컴플라이언스 제약 세 차원으로 생명주기를 정의하면 처치는 테이블 조회 작업이 된다.
- 민감도와 재사용 가치는 직교하는 두 축이므로 답은 이분법이 아니라 4사분면이다 — 대부분은 「민감하면 삭제, 비민감하면 보존」만 답하고 「민감하지만 마스킹 후에도 재사용 가치가 있는」 칸을 빠뜨린다. 4사분면(마스킹 후 재사용)이야말로 변별력이 가장 높은 답이다.
- 경험은 추출되지 않으면 존재하지 않는 것과 같다 — 「경험을 남긴다」는 것은 작업 디렉터리를 그대로 두는 것이 아니다. 작업 공간에 흩어진 설정과 기준에는 구조도 검색 입구도 없어서 다음 작업 때 아무도 뒤지지 않는다. 추출 → 요약 → 입고 → 자동 주입이라는 사슬에서 어느 하나가 빠지면 경험은 침전되지 않은 것과 같다.
- 삭제는 검증이 필요한 동작이지 구문 한 줄이 아니다 — 논리 삭제(
is_deleted = 1)는 컴플라이언스 맥락에서 삭제로 치지도 않는다. 롤백으로 복원될 수 있기 때문이다. 컴플라이언스 삭제 = 물리적으로 복구 불가 + 캐스케이드 무결성 검증 + 독립적으로 보존되는 감사 로그.
- 감사 로그는 삭제된 데이터보다 오래 살아야 한다 — 「로그 자체가 데이터와 함께 지워지면 안 된다」가 이 단락에서 가장 놓치기 쉬운 문장이다. 데이터를 지우고 삭제 기록까지 지우면 컴플라이언스를 자증할 수 없어 지우지 않은 것보다 나쁘다.
- 경험 라이브러리 자체에도 거버넌스가 필요하며, 그러지 않으면 오염된다 — 침전 메커니즘이 자동화되는 순간 잘못된 설정도 자동으로 침전된다. 그래서 입고에는 사람의 승인 노드가, 사용에는 효과 피드백이, 나쁜 경험에는 자동 강등이 있어야 한다. 자동으로 축적되는 모든 지식 베이스에는 역방향 도태 채널이 필요하다.
- 기준(口徑)류 지식이 가장 값진 침전이다 — 「성장률은 월 대비가 아니라 주 동기 대비를 쓴다」 같은 한 줄짜리 설정은 사람이 외우지도 못하고 문서에서 찾지도 못하지만 리포트 한 장의 정오를 결정한다. 기준을 경험 라이브러리 안의 주입 가능한 설정 한 줄로 만드는 것이 위키에 쓰는 것보다 이득이 훨씬 크다.
엔지니어링 실전 Tips
- 「삭제」와 「아카이빙」을 두 개의 동작으로 다룰 것: 1사분면의 처치는 「보존 기한 정책에 따라 삭제 또는 아카이빙 실행」이지 무조건 삭제가 아니다. 기한 내에는 아카이빙하고 기한이 되면 삭제하는 것이 정책이다.
- 논리 삭제는 업무 롤백에만 적합하고 컴플라이언스 삭제에는 적합하지 않다:
is_deleted = 1인 데이터는 여전히 저장소에 있고 여전히 롤백으로 복원될 수 있어 컴플라이언스상으로는 지우지 않은 것과 같다. 컴플라이언스 장면에서는 덮어쓰기로 물리적 말소를 할 것.
- 삭제 전에 의존 검사를 먼저 돌리고 「이 테이블은 아무도 안 쓴다」를 믿지 말 것: 상류 의존과 하류 작업을 모두 검증하고, 삭제 후에도 연관 작업의 무결성이 손상되지 않았는지 한 번 더 검증하는 것이 「폐루프」라는 두 글자의 실제 의미다.
- 감사 로그는 별도로 저장하고 별도의 보존 기간을 설정할 것: 삭제된 데이터와 다른 생명주기, 다른 저장 위치를 두어 한 번의 정리로 증거까지 지우는 일을 피할 것.
- 경험 입고에 승인 문턱을 두고 고가치에만 열 것: 완전 자동 입고는 잘못된 설정까지 함께 침전시킨다. 사람의 확인 노드가 오염 방지의 첫 번째 관문이다.
- 경험마다 사용 기록과 효과 피드백을 매달 것: 3회 재사용 모두 후속 작업 오류를 유발하면 자동으로 강등 표시를 하고 담당자에게 재검토를 통지하게 하라. 경험 라이브러리가 스스로 도태 메커니즘을 갖게 해야지 늘어나기만 하고 줄지 않으면 안 된다.
- 「통째로 묶어 NAS에 저장」을 보존 정책으로 착각하지 말 것: 전량 패키징은 분류도 마스킹도 없이 처치 책임을 감사 당일로 미루는 것일 뿐이다.