[DocuFlow] 민감한 문서는 어디서 처리되는지가 먼저 보여야 했다

민감한 문서를 다루는 제품에서 “안전하다”는 문장만 크게 보여 주는 방식은 오래 버티지 못한다. 사용자는 파일이 어디에서 열리고, 어떤 처리가 브라우저 안에서 끝나며, 어느 단계에서 서버가 필요한지 알고 싶어 한다. DocuFlow의 문제는 보안 원칙이 없어서가 아니라 그 경계가 화면에 충분히 드러나지 않는다는 데 있었다.

신뢰는 처리 위치에서 시작된다

파일을 올린 뒤 아무 설명 없이 진행되면 사용자는 결과가 안전한지 추측해야 한다. 반대로 “이 파일은 기기 안에서 열렸다”, “이 단계는 서버 처리가 필요하다”는 정보가 흐름에 맞게 보이면 선택할 수 있다. 보안 문구를 한 번 더 쓰는 것보다 처리 위치를 정확하게 말하는 편이 낫다.

DocuFlow에서 생각한 기본 흐름은 단순했다. 브라우저에서 문서를 열고, 민감정보 후보를 찾고, 사용자가 마스킹 결과를 확인한 뒤 내보낸다. 이 순서를 숨기지 않는 것이 기능을 더하는 것보다 먼저였다.

로컬 우선이 모든 답은 아니다

그렇다고 모든 처리를 브라우저에서 끝내겠다고 약속할 수도 없다. OCR이나 대용량 변환은 기기의 성능과 파일 크기에 따라 부담이 커진다. 중요한 것은 무조건 로컬이 아니라, 서버 처리가 필요한 순간을 사용자가 알고 선택하게 하는 일이다.

Private-PDF와 privacy-shield-pdf를 보며 고민한 것도 같은 지점이다. 민감한 원본과 검토가 필요한 단계는 가능한 한 로컬에 두되, 무거운 작업을 서버에서 처리할 때는 그 사실과 이유를 숨기지 않아야 한다. 편의와 보호 중 하나를 구호로 고르는 대신 경계를 제품의 일부로 다뤄야 했다.

보여 주지 않으면 통제할 수 없다

처리 위치를 알려 주는 것은 정책 페이지의 문제가 아니다. 사용자가 파일을 넣는 순간부터 어떤 데이터가 움직이는지 확인할 수 있어야 한다. 민감정보를 찾은 결과도 자동으로 확정하지 않고, 내보내기 전에 사람이 검토할 수 있어야 한다.

이 경계를 설명하는 데 서버와 클라이언트의 용어만 늘어놓으면 오히려 흐려진다. 사용자가 지금 무엇을 선택할 수 있는지, 선택하지 않으면 어떤 일이 일어나는지를 화면에서 말하는 편이 더 정확하다.

마치며

DocuFlow에서 안전을 구현한다는 것은 “안전하다”고 선언하는 일이 아니었다. 파일이 어디에 있고, 어떤 처리가 끝났고, 다음 단계에 무엇이 필요한지 계속 보여 주는 일이었다. 보안은 보이지 않는 약속이 아니라 사용자가 확인할 수 있는 흐름이어야 한다.