이미지 스크린샷 PII 사람 검수 운영안 (SOP)

최초 작성 — 2026-06-22 · CS 운영자(cs-operator) · 재큐레이션으로 복원된 approved 표준답변·안내글의 인용 이미지(스크린샷) 속 PII를 사람이 100% 1차 검수하기 위한 큐 운영·검수 절차·판정 가이드·품질관리·지표 운영안
정본은 P2-EXPOSURE-GUARD.md §4-A(이미지 검수 기준·체크리스트·판정 규칙)·§4-A-4(표본 검수 운영)·§4-B(상태 컬럼). 본 SOP는 그 기준을 실제 큐 운영·일배치·검수 실행 절차로 푸는 운영 문서다. 기준이 충돌하면 P2-EXPOSURE-GUARD가 우선한다.
실행 시점: 실제 검수 실행은 admin 검수 UI(§4-A I2/I3 미리보기·판정 버튼) 배포 후 시작한다. 본 문서는 그 전에 합의해 둘 SOP·큐 운영안이며, UI 배포 후 일배치·담당·기간만 확정해 가동한다.

0. 배경 (실측 — 2026-06-22 기준)

항목	값	비고
검수 대상(이미지 보유 · `image_pii_status='pending'`)	266건	approved 표준답변·안내글 중 이미지 보존분
└ 표준답변(`hp_standard_answer`)	196건
└ 안내글(`hp_announce`)	70건
본문 텍스트 PII	마스킹 완료(○)	`pii_text_status` 별도 게이트(정본 §2-1·4-B)
스크린샷 속 PII	미검수	정규식 마스킹이 닿지 않음 → 사람 검수 필요(본 SOP)

정본(P2-EXPOSURE-GUARD, 2026-06-19) 작성 시 기준은 복원 580건 중 이미지 보존 345건이었다. 본 SOP의 266건은 그 이후 텍스트 게이트·반려·중복 정리를 거쳐 현재 image_pii_status='pending'으로 남은 실제 잔량이다. 큐 적재 직전 admin에서 pending 카운트를 재확인해 본 수치를 갱신한다(아래 §5-0).
이 SOP는 검수의 "운영"만 다룬다. 판정 기준·체크리스트의 정의는 정본 §4-A에 있고, 본 문서는 그것을 어떤 순서·속도·담당으로 소화하느냐를 정한다.

제약 (반드시 준수)

tb_* 원본 테이블은 읽기만. 검수·판정은 admin UI / api 엔드포인트 경유로만 수행한다. DB 직접 수정 금지.
발견한 PII 값은 어디에도 전사 금지. 검수 메모·재검수 기록·에스컬레이션 어디서든 유형 라벨(name/phone/account 등)과 위치(이미지 ID·대략 영역)만 적는다. 값 전사 자체가 2차 노출이다(정본 §4-A).
권한 밖 약속 금지. 일반화 허용 경계·고유식별정보 처리 등 경계 판단은 임의 확정하지 않고 privacy-officer에게 에스컬레이션한다.

1. 검수 큐 운영

1-1. 큐 구성 — 266건 100% 1차 검수

전수(266건)를 1차 검수 큐에 적재한다. 자동 통과는 없다 — Vision 1차(I1)는 우선순위 트리아지일 뿐, "PII 없음"을 근거로 자동 통과시키지 않는다(미탐=노출, 정본 §4-A).

1-2. 우선순위 — Vision 1차 스캔(suspect) 먼저

큐 적재 전 전건에 대해 api의 Vision 1차 스캔(POST /standard-answers/:id/pii-image-scan, ?table=announce)을 돌려 우선순위를 매긴다.

우선순위	상태	의미	처리
P1 (먼저)	`suspect`	Vision이 PII 의심 신호 탐지	검수 큐 상단. 노출 위험 우선 차단
P2	`pending`	Vision 무탐(미스캔/신호 없음)	suspect 소진 후 검수. 무탐≠안전 — 동일하게 사람 검수 필수

suspect를 먼저 보는 이유: 노출 위험이 높은 건을 빨리 차단/마스킹하기 위함. pending(Vision 무탐)도 반드시 전건 사람 검수한다 — 후순위일 뿐 면제가 아니다.
스캔은 api/developer 권한이 필요하므로 큐 적재 전 사전 작업으로 일괄 실행을 developer에 요청한다.

1-3. 일배치·담당·기간 (제안 — UI 배포 후 확정)

항목	제안값	비고
1인 일배치량	30~50건/일	1건당 미리보기·체크리스트·판정 평균 5~8분 가정. 명단/표 등 복잡 건은 시간↑
검수 담당	CS 운영자 1~2인 + admin 승인 권한자	판정 확정(`pii-image-review`)은 admin 권한 필수(api가 admin↑로 강제)
1차 검수 기간	약 6~9영업일 (1인 40건/일 기준 ≈ 7일)	suspect 비중·복잡도에 따라 가감
진행 단위	suspect 전건 → pending 전건	§1-2 우선순위 순

담당이 admin 권한이 없으면 검수(I2)는 CS가, 판정 확정(I3·pii-image-review)은 admin 권한자가 분리 수행한다. 이 경우 검수 의견(유형·위치 라벨)을 admin에게 넘겨 확정한다.
일배치량·기간은 admin 검수 UI 배포 후 실제 1건 처리시간을 측정해 1주차에 재조정한다.

2. 검수 절차 (SOP) — 1건 단위

admin 검수 패널에서 1건씩 처리한다. 정본 §4-A의 I1→I2→I3을 운영 절차로 푼 것이다.

[큐에서 1건 선택(suspect 우선)]
   ↓
1) 이미지 미리보기 — 인용 이미지(스크린샷) 전부 육안 확인
   ↓
2) 체크리스트 적용 — 정본 §4-A-2 항목 점검 (유형·위치만 메모, 값 전사 금지)
   ↓
3) 판정 — clear / removed / masked / blocked 중 1 확정
   ↓
4) 확정 기록 — admin이 PATCH /standard-answers/:id/pii-image-review
                {status: ...} → pii_checked_by·pii_checked_at 자동 기록
   ↓
[다음 건]

2-1. 단계별 상세

이미지 미리보기 — 답변/안내글이 인용한 이미지를 admin 미리보기에서 연다. 한 건에 이미지가 여럿이면 전부 확인한다(롤업은 최악값이므로 한 장이라도 문제면 그 판정이 답변 전체를 좌우).
체크리스트 — 정본 §4-A-2 7개 항목 점검(인명·연락처·이메일·주소 / 고객 명단·표 / 계좌·카드·사업자번호 / 고유식별정보 / 내부 관리화면 / 제3자 교차노출 / 일반 조작안내 적합성).
판정 — §3 가이드에 따라 4값 중 하나 확정.
확정 기록 — admin 권한자가 PATCH /standard-answers/:id/pii-image-review(안내글은 ?table=announce) 호출 또는 admin UI 판정 버튼. body {status: clear|removed|masked|blocked}. pii_checked_by(검수자 email)·pii_checked_at(시각)이 자동 기록된다. 값은 절대 전사하지 않는다 — 유형 라벨은 pii_finding_types에만(라벨만).

2-2. PII 값 전사 금지 (재확인)

검수 메모, 슬랙/이슈, 재검수 기록, privacy-officer 에스컬레이션 — 어디서든 화면에 보인 PII 값을 텍스트로 옮기지 않는다.
기록 가능: 유형 라벨(예: name, phone, account, rrn, customer_list) + 위치(이미지 ID, "표 상단 3~5행", "우측 입금정보 영역" 수준).
기록 금지: 실제 이름·번호·계좌·주민번호 등 값 일체.

3. 판정 가이드

정본 §4-A 판정 규칙을 운영 의사결정으로 정리. 헷갈리면 보수적으로 더 강한 판정(removed/blocked)을 택하고, 경계는 privacy-officer에 에스컬레이션한다.

판정	조건	효과
blocked	주민등록번호 등 고유식별정보 / 고객 명단·표(다수 정보주체 한 화면) / 가림으로 해결 불가한 노출	자산 노출 절대 차단 + 운영자(privacy-officer) 알림. 마스킹 아님
removed	이미지를 빼도 본문 안내가 성립(이미지가 명단·내부화면이거나 부가 캡처)	인용 이미지 자체를 답변에서 제거
masked	부분 PII이고 크롭/블러로 가리면 노출 가능. 단 재식별 위험이 남으면 교체본 사용	가림 처리본으로 교체(처리본 관리는 정본 §7-2 P8)
clear	PII 없음 · 일반 조작안내(메뉴·버튼 위치 등)로 적합	통과. (단 Vision 단독 clear 금지 — 반드시 사람 판정)

3-1. 결정 우선순위 (위에서부터 판단)

고유식별정보(주민번호 등)·고객 명단/표(다수 정보주체) → 즉시 blocked.
이미지를 빼도 본문이 성립 → removed(가림 고민 불필요, 빼는 게 안전).
부분 PII이고 가림으로 충분 → masked(재식별 위험 남으면 교체본).
PII 없고 일반 조작안내 → clear.

3-2. 경계 사례 예시 (맑은이러닝/PMS 맥락)

아래는 유형 예시이며 실제 값은 포함하지 않는다. 실 검수 시에도 값 전사 금지.

#	화면 예시	판정	근거
E1	회원목록 캡처 — 한 화면에 여러 회원의 이름·연락처·이메일이 행으로 나열	blocked	다수 정보주체 명단. 가림 범위가 화면 대부분 → 차단
E2	결제내역 화면 — 결제자명·카드번호 일부·금액 노출	masked(부분이면) / blocked(카드 전체·다수면)	카드번호 노출 정도·정보주체 수로 분기
E3	로그인 화면 — 아이디 입력란에 특정 회원 ID가 채워진 채 캡처	masked	ID 영역 크롭/블러. 안내 자체(로그인 절차)는 일반 조작안내라 이미지 유지 가능
E4	메뉴 안내 캡처 — 좌측 메뉴 트리·버튼 위치만, 데이터 영역 비어있음	clear	PII 없음, 전형적 조작안내
E5	수강생 진도현황 표 — 다수 수강생 이름·진도율·연락처	blocked	다수 정보주체 명단/표
E6	단건 상세 화면 — 한 명의 이름·휴대폰이 상세 폼에 표시	masked(가리면 안내 성립) / removed(이미지 없어도 안내 성립이면)	부분 PII. 본문만으로 안내 가능하면 removed가 더 안전
E7	오류 팝업/토스트 캡처 — 메시지만, 개인정보 없음	clear	일반 조작/오류 안내
E8	내부 관리자 대시보드 캡처 — 고객 비노출 전용 관리화면이 통째로	removed(또는 blocked)	고객에게 보일 화면이 아님. 명단 포함 시 blocked

E2·E6처럼 masked/blocked·masked/removed가 갈리는 건은 정보주체 수·재식별 위험·이미지 없이 본문 성립 여부로 판단하고, 불확실하면 더 강한 판정 + privacy-officer 확인.

4. 품질관리

4-1. `clear` 재검수 (미탐 사후 회수)

clear 판정분 중 주 10~20%를 무작위 표본 재검수한다(정본 §4-A-4). clear는 "노출 통과"라 미탐 시 그대로 PII 노출이므로 사후 회수가 가장 중요하다.
재검수는 최초 검수자와 다른 사람이 수행(가능하면 admin 권한자). 재검수에서 PII가 발견되면 즉시 해당 건을 masked/removed/blocked로 정정(pii-image-review 재호출)하고, 같은 검수자의 직전 clear 건들을 추가 표본으로 확대 점검한다.

4-2. 이견 에스컬레이션 (privacy-officer)

다음은 임의 판정하지 않고 privacy-officer에 연계한다.

고유식별정보 해당 여부가 모호한 경우(예: 사업자번호·법인 식별의 개인정보 해당성 — 정본 §4-3·7-2 P2).
masked(가림) vs removed/blocked 경계가 반복적으로 갈리는 유형.
비공개 출처 파생 의심(private_source_flag)과 결합된 이미지 — 텍스트 게이트와 함께 검토.
일반화 허용 경계(정본 §7-2 P1) 관련 판단.

에스컬레이션 시에도 값 전사 금지 — 유형·위치·왜 모호한지만 전달한다.

4-3. 신규 인용 이미지 동일 게이트

백필(266건) 이후 새로 인용되는 이미지도 승인 전 동일 게이트(I1→I3) 를 통과해야 한다(정본 §4-A-4). 신규 인용분은 image_pii_status='pending'으로 들어오므로 동일 큐·동일 절차로 흡수한다.
즉, 본 SOP는 일회성 백필 청소가 아니라 상시 운영 절차다.

4-4. 승인 하드 게이트 연계

이미지 검수가 끝나야 답변/안내글 승인이 가능하다 — image_pii_status 롤업이 clear/removed/masked(또는 none)가 아니면 admin 승인 버튼 비활성(정본 §4-2·4-B). pending·suspect·blocked가 하나라도 있으면 승인 불가.
따라서 검수 큐 소진은 approved 자산의 P2 노출 적격화 전제다. 누락 없이 클로징한다.

지표	정의	목표/관찰
검수 진척률	검수완료(clear+removed+masked+blocked) / 전체(266)	기간 내 100%
판정 분포	clear / removed / masked / blocked 각 비율	clear 과다 시 미탐 의심(재검수 강화 신호)
suspect 적중률	suspect 중 실제 비-clear 판정 비율	Vision 트리아지 유용성 점검
pending(무탐) 위험도	Vision 무탐(pending)인데 사람이 비-clear로 본 비율	높으면 Vision 의존 위험 — 전수 검수 정당화
재검수 정확도	clear 재검수 표본 중 정정 없이 유지된 비율	낮으면(정정 多) 검수 품질 이슈 → 교육·기준 재정렬
일배치 처리량	1인/일 검수 건수	일배치량(30~50) 현실성 검증·기간 재조정

지표는 건수·비율만 집계한다 — 어떤 건에 어떤 PII가 있었는지의 값은 집계·기록하지 않는다(유형 라벨 분포까지만).
진척·분포는 admin의 image_pii_status 카운트(읽기)로 산출 가능. 별도 PII 저장 불필요.

6. 참조

문서	관계
P2-EXPOSURE-GUARD.md §4-A·4-A-4·4-B	정본 — 검수 기준·체크리스트·판정 규칙·상태 컬럼. 본 SOP의 상위
STANDARD-ANSWER-CURATION.md	표준답변 승인 워크플로(검수 큐가 승인 게이트의 전제)
PMS-INQUIRY-HARVEST.md	안내글 수집·승인(안내글 70건 검수 대상)
api `POST /standard-answers/:id/pii-image-scan`	I1 Vision 1차(developer↑, `?table=announce`) — suspect/pending
api `PATCH /standard-answers/:id/pii-image-review`	I3 사람 판정 확정(admin↑, body `{status}`, `pii_checked_by/at` 기록)

미정 / 후속 (UI 배포 후 확정)

admin 검수 UI 배포 일정 — 본 SOP 실행 개시 전제.
일배치량·담당·기간 최종 확정(1주차 실측 후).
masked 가림 처리본 생성·교체 도구(정본 §7-2 P8) — masked 판정 다수 시 운영 병목 가능, api/admin/dba 협의.