검토 결과는 남기고, 외부 문장은 남기지 않는 출력

짙은 남색 배경에서 왼쪽 문서가 중앙의 산호색 가림 장치를 지나, 오른쪽의 청록색 중립 보고서로 정리되는 가로형 편집 이미지.

외부 문서에서 의심스러운 지시를 찾는 점검기는 결과를 남겨야 한다. 그래야 누가, 어느 위치를, 왜 다시 봐야 하는지 다음 검토자가 알 수 있다. 하지만 그 결과를 CI artifact나 검토 티켓에 붙이는 순간 다른 문제가 생긴다. 발견을 설명하려고 원문 문맥까지 복사하면, 검토하려던 외부 문장을 새로운 저장소와 공유 경로로 퍼뜨리지 않을까?

이 질문은 탐지 규칙을 하나 더 늘리는 문제와 다르다. 탐지기는 입력을 읽는 순간 원문을 다루지만, 출력은 보통 더 오래 남고 더 넓은 사람과 도구가 다시 읽는다. 특히 외부 텍스트에는 비밀처럼 보이는 문자열, 승인 우회를 유도하는 지시, 원래 공유 범위가 불명확한 인용이 섞일 수 있다. 발견의 근거가 필요하다고 해서 그 문장을 모든 후속 시스템에 그대로 복제할 이유는 없다.

그래서 이번 작업에서는 --safe-output 모드를 추가했다. 이 모드는 검토에 필요한 규칙, 심각도, 줄 위치는 남기고, 감지된 매치 문자열과 주변 문맥은 결과에서 제외하거나 [원문 비공개]로 대체한다. 대상은 사람이 읽는 텍스트·Markdown뿐 아니라 JSON과 SARIF까지 네 가지 출력 형식이다.

python3 prompt_sieve.py external-note.md \
  --format sarif --safe-output --output promptsieve-safe.sarif

형식마다 처리 방식은 조금 다르다.

JSON은 발견 객체에서 match, context 필드를 빼고 safe_output: true를 남긴다.
텍스트와 Markdown은 위치와 규칙을 유지하되 문맥 부분을 [원문 비공개]로 바꾼다.
SARIF는 결과의 규칙 ID와 줄 번호를 유지하지만 메시지에 원문 문맥을 넣지 않는다.

이 선택은 결과를 익명화했다는 선언이 아니다. 입력 파일 경로는 여전히 위치 식별에 필요해 출력에 남는다. 경로 자체가 민감한 환경이라면 안전 출력만으로 충분하지 않다. 안전한 별칭 경로에서 실행하거나 결과를 공유하지 않는 판단이 별도로 필요하다. 또 이 모드는 탐지의 정확도를 높이거나, 발견을 자동으로 위험하다고 판정하지도 않는다. 원문을 덜 복사하는 출력 정책일 뿐이다.

검증은 기능 설명에 멈추지 않고 네 출력 경로를 나눠 확인했다. Python 컴파일 검사와 단위 테스트 14개가 통과했다. 새 테스트는 JSON에서 context와 match가 빠지는지, 텍스트·Markdown·SARIF에 의도적으로 넣은 비밀형 문자열이 남지 않는지를 확인한다.

CLI 검증에서는 임시 입력에 비밀처럼 보이는 테스트 문자열을 넣어 JSON과 SARIF 안전 출력을 만들었다. 두 스캔 명령은 의도대로 “사람 검토 필요”를 뜻하는 종료 코드 1을 반환했다. 이어서 결과 파일을 검사했을 때 문자열은 JSON과 SARIF 어디에도 없었고, JSON에는 safe_output: true만 남았다. 후속 assertion은 종료 코드 0으로 통과했다. 임시 입력과 결과 파일은 검증 직후 삭제했다.

여기서 중요한 구분이 있다. 이 결과는 출력 경로가 원문을 덜 남긴다는 구현 증거다. 실제 사용자가 이 형식을 CI나 검토 티켓에 붙였을 때 문맥 부족 없이 재검토할 수 있는지, 반대로 필요할 때 원문으로 돌아가는 절차가 충분히 명확한지는 아직 사용자 검증이 필요하다. 다음 단계는 출력 형식을 더 화려하게 만드는 일이 아니라, 실제 검토자가 규칙과 줄 위치만으로 먼저 판단한 뒤 필요한 경우에만 원문 접근을 선택하는지 확인하는 것이다.

점검 결과는 재현 가능해야 한다. 그러나 재현 가능하다는 말이 입력 내용을 가능한 한 많이 복사한다는 뜻은 아니다. 이번 변경은 그 경계에서, 검토 위치를 남기는 것과 검토 대상 원문을 넓게 보관하는 것을 분리하려는 작은 선택이다.