캡처 이미지 공유 전 5분 마스킹 루틴

캡처를 올리고 나서 뒤늦게 이메일이나 내부 주소를 발견한 적이 있다. 설명하려던 버튼만 보고 주변을 안 봤기 때문이다. 그 뒤로는 공개 전에 같은 순서로 한 번씩 훑는다. 오래 걸리지는 않지만 순서를 정해두면 빠뜨리는 게 줄어든다.

먼저 화면을 작게 본다

확대한 상태에서는 내가 설명하려는 오류 문구나 버튼만 보게 된다. 이미지를 화면에 맞춘 뒤 네 모서리부터 확인하면 주소창, 브라우저 탭, 계정 메뉴, 하단 상태바가 눈에 들어온다.

내가 먼저 찾는 건 다음 항목이다.

• 이름, 이메일, 전화번호, 프로필 사진
• API 키, 토큰, 세션 값, QR 코드
• 저장소 이름, 프로젝트 ID, 내부 URL, 로컬 파일 경로
• 고객명, 팀원 이름, 대화 상대처럼 내가 공개를 결정할 수 없는 정보
• 결제 금액, 주문번호, 주소처럼 글 설명에 필요 없는 값

관리자 화면은 본문보다 헤더와 사이드바가 더 위험한 경우가 많다. 터미널은 프롬프트의 사용자명과 절대 경로를 놓치기 쉽다. 오류 한 줄만 필요하다면 화면 전체를 남기지 않고 필요한 부분만 자르는 게 가장 안전하다.

블러와 단색 박스를 구분해서 쓴다

블러는 주변 맥락을 남기면서 글자를 읽지 못하게 할 때 편하다. 사람 얼굴, 긴 이메일 목록, 여러 줄의 부가 정보가 여기에 맞는다. 다만 짧은 숫자나 토큰은 약한 블러에서도 글자 모양이 남을 수 있다.

API 키, 계좌번호, 전화번호, 짧은 이름처럼 한 글자라도 읽히면 곤란한 값은 단색 사각형으로 완전히 덮는다. 보기 좋은 결과보다 다시 읽을 수 없는 결과가 우선이다. 블러 강도를 애매하게 고민할 바에는 박스로 덮는 편이 빠르다.

zozincanvas에서는 블러가 원본 픽셀에 바로 반영되고, 사각형·화살표·텍스트는 별도 객체로 남는다. 그래서 민감한 값은 먼저 가리고, 설명할 위치는 나중에 표시하는 순서가 편했다.

강조 표시는 가림 작업 뒤에 한다

민감한 부분만 잔뜩 덮으면 독자는 어디를 봐야 하는지 모른다. 설명할 버튼에는 사각형을 두고, 이동 경로나 순서는 화살표로 표시한다. 오류 문구를 설명한다면 전체 문장을 강조하지 않고 핵심 줄만 남긴다.

색은 한 장에 하나만 쓰는 편이 낫다. 빨간 박스, 노란 화살표, 초록 밑줄을 한꺼번에 쓰면 무엇이 중요한지 다시 설명해야 한다. 캡처 이미지는 디자인 결과물이 아니라 글을 덜 길게 만들기 위한 보조 자료다.

저장한 파일을 다시 연다

편집 화면에서 끝내지 않고 다운로드한 PNG나 WebP를 새로 연다. 브라우저 확대를 200% 정도로 올렸을 때 글자가 남아 있는지, 이미지 가장자리가 잘리지 않았는지, 화살표가 엉뚱한 곳을 가리키지 않는지 본다.

현재 zozincanvas 코드는 파일을 FileReader로 읽고 Canvas에 그린 뒤, 결과를 toDataURL로 내려받는다. 이미지 업로드용 fetch나 XMLHttpRequest 호출은 없다. 즉 현재 코드 기준으로 원본은 브라우저 안에서 처리된다. 그래도 원본 파일을 다른 곳에 직접 올리거나, 가리지 않은 버전을 첨부하면 소용없다. 도구가 대신 판단해 주지는 않는다.

내가 실제로 쓰는 순서

1. 화면 전체를 맞춰 놓고 네 모서리부터 본다.
2. 이름, 계정, 토큰, 내부 경로를 먼저 가린다.
3. 짧고 민감한 값은 단색 박스로 덮는다.
4. 설명할 버튼이나 오류 줄만 화살표와 사각형으로 표시한다.
5. 파일을 내려받아 다시 확대해 본다.
6. 글에 필요한 영역만 남도록 마지막으로 자른다.

이 과정을 거친 뒤에도 애매하면 이미지를 안 쓰는 게 낫다. 코드 한 줄이나 오류 문장만 텍스트로 옮겨도 설명이 되는 경우가 많다.

zozincanvas 프로젝트 페이지에는 현재 기능과 한계를 따로 정리했다. 이 도구의 목적은 편집을 잘하는 게 아니라 공개 실수를 한 번 줄이는 것이다.