병원 사이트에서 열리지 않는 페이지를 신고하려고 문의 버튼을 눌렀는데, 작성창에 방금 실패한 주소가 통째로 들어간다고 가정해 보겠습니다. 그 주소에는 공개 글의 위치뿐 아니라 개인 예약을 확인하는 값이 섞여 있을 수 있습니다. 오류 페이지에 문의 경로를 남길 때에는 연락이 이어지는지와 함께, 신고를 시작하는 순간 어떤 내용이 다른 창구로 옮겨지는지를 점검해야 합니다.
먼저 자동으로 넣어도 되는 항목을 따로 정합니다. 화면에 표시된 일반 오류 종류, 발생 시각, 개인정보와 연결되지 않는 페이지 유형처럼 담당자가 문제를 구분하는 데 필요한 항목부터 검토합니다. 주소를 넣어야 한다면 누구나 볼 수 있다고 확인한 공개 안내의 경로만 지정합니다. 임의의 주소에서 물음표 뒤를 지웠다는 이유만으로 공개 주소라고 판단하지 않습니다. 경로 중간에도 개인별 식별값이 있을 수 있으므로, 확인되지 않은 경로는 복사하지 않고 ‘예약 확인 화면’ 같은 기능 설명으로 바꿉니다.
정리하는 시점은 메일 제목이나 문의 내용에 값을 넣기 전입니다. 화면에서 주소 일부를 가려도 버튼의 실제 연결 문자열에 원래 값이 남으면 작성창으로 넘어갈 수 있습니다. 주소 끝의 # 뒤는 일반 문서 요청에 실리지 않지만 브라우저의 스크립트가 읽을 수 있으므로 자동 첨부 대상에서 별도로 확인합니다. 한글이나 특수문자를 퍼센트 기호가 포함된 형식으로 바꾸는 인코딩도 정보 삭제가 아닙니다. 작성창에서 다시 읽히는 내용을 기준으로 판단합니다.
주소를 빼면 기술 담당자가 사건을 찾기 어렵다는 이유로 개인 링크를 다시 넣지는 않습니다. 시스템이 별도의 오류번호를 제공한다면 그 번호로 제한된 내부 기록을 찾는 절차가 있는지 확인할 수 있습니다. 이때 오류번호는 예약을 열거나 변경하는 권한을 가진 토큰과 구분해야 합니다. 이름을 ‘오류번호’로 바꾸어도 같은 권한이 남으면 대체한 것이 아닙니다. 번호만 전달받은 사람이 개인 예약이나 원본 로그를 열 수 없는지 담당자가 확인하고, 그런 기능이 없다면 발생 시각과 직전 행동을 설명하도록 안내합니다.
이메일 연결을 쓰는 경우에는 mailto가 수신자와 제목·본문의 초깃값을 전달한다는 점을 반영합니다. 작성창을 열었다는 사실을 신고 접수로 표시하지 않고, 보내기 전에 받는 주소와 자동 입력된 내용을 확인할 수 있게 합니다. 문의 양식으로 연결하는 경우에도 숨겨진 항목에 실패 주소를 그대로 붙여 두었는지 살핍니다. 개인 예약 확인에 필요한 자료는 해당 병원이 정한 본인 확인 창구에서 다루고, 기술 오류 신고 문장에는 불필요하게 옮기지 않습니다.
검수에는 실제 이용자의 링크 대신 구별하기 쉬운 시험표식을 사용합니다. 가상의 주소에서 경로, 물음표 뒤 항목, # 뒤에 서로 다른 표식을 넣고 신고 버튼을 엽니다. 버튼의 연결값과 양식 항목, 메일 작성창을 각각 확인해 어느 표식도 남지 않는지 대조합니다. 인코딩된 문자열만 훑지 말고 사람이 읽는 형태로 해석된 결과까지 봅니다. 실제 외부 전송 없이 확인한 시험이라면 검수 기록도 작성창과 입력값 확인까지로 한정합니다.
반대로 허용한 공개 안내 경로와 일반 오류 설명까지 모두 사라지면 문의를 이해하기 어려울 수 있습니다. 공개 페이지 시험과 개인별 주소 시험을 짝으로 두고, 전자는 필요한 진단 맥락이 남으며 후자는 개인 링크 없이도 문의를 시작할 수 있는지 확인합니다. 최종 기록에는 자동으로 넣을 항목, 제외할 값, 확인한 작성창을 대응시킵니다. 문의 버튼의 완료 기준은 실패 주소의 복사가 아니라, 이용자가 의도하지 않은 개인 접근 정보를 가져가지 않으면서 문제를 설명할 수 있는 상태입니다.
기술 근거: RFC 6068의 mailto 동작·인코딩·보안 설명(https://www.rfc-editor.org/rfc/rfc6068.html), RFC 9110의 URI와 조각 식별자 정보 노출 설명(https://www.rfc-editor.org/rfc/rfc9110.html#section-17.9), OWASP의 로그 식별자 및 제외할 데이터 안내(https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html).