문의 폼 개인정보, 개발 전에 무엇을 정해야 할까

프로젝트 상담, 고객 지원과 뉴스레터 신청은 필요한 정보와 후속 처리 방식이 다릅니다. 하나의 폼에 가능한 정보를 모두 받기보다 어떤 문의를 누가 처리하고 어떤 답변을 위해 정보가 필요한지 먼저 정해야 합니다.

개인정보 보호법은 개인정보를 수집할 때 목적에 필요한 최소한의 정보만 수집하도록 하고, 최소 정보 외의 수집에 동의하지 않았다는 이유로 서비스 제공을 거부해서는 안 된다고 규정합니다. 회사명, 연락처, 예산과 첨부 파일도 실제 처리 목적에 필요한지 항목별로 확인합니다.

체크박스만 필수로 두고 무엇에 동의하는지 찾기 어렵게 만들면 사용자는 자신의 정보가 어떻게 쓰이는지 판단하기 어렵습니다. 수집·이용 목적, 항목, 보유·이용 기간과 동의를 거부할 권리 및 거부에 따른 영향을 폼 가까이에서 확인할 수 있어야 합니다.

선택 정보와 별도 목적은 필수 문의 처리 동의에 섞지 않습니다. 개인정보 처리방침 링크만 제공하고 폼의 실제 수집 항목과 처리 흐름이 다르면 안내와 구현이 어긋납니다. 문구를 확정한 담당자와 변경 시 함께 갱신할 화면·문서를 기록합니다.

브라우저의 필수 입력과 이메일 형식 표시는 사용자가 실수를 줄이도록 돕지만 임의로 만든 요청까지 막지는 못합니다. 서버는 이름과 문의 내용의 길이, 이메일 형식, 선택값의 허용 범위와 동의 여부를 다시 검증하고 잘못된 입력을 저장하거나 전달하지 않아야 합니다.

OWASP 입력값 검증 안내는 신뢰할 수 없는 입력을 가능한 한 이른 단계에서 구문과 업무 의미 기준으로 확인하고, 허용 목록을 우선 사용하도록 권고합니다. 오류 응답에는 내부 경로, 메일 설정과 입력 원문 전체를 노출하지 않고 사용자가 고칠 항목을 구체적으로 알려 줍니다.

폼이 성공 화면을 보여도 담당자에게 알림이 도착하지 않거나, 반대로 전송은 끝났지만 브라우저가 응답을 받지 못할 수 있습니다. 브라우저, 서버, 이메일·업무 도구와 담당자 확인 중 어느 지점까지 끝나야 접수 성공인지 정해야 합니다.

문의 내용은 업무상 필요한 담당자만 열람하도록 하고 개인 메신저, 공개 이슈와 분석 이벤트로 복사하지 않습니다. 관리자 알림 제목과 운영 로그에도 이름, 이메일, 연락처와 문의 원문을 불필요하게 반복하지 않도록 확인합니다.

데이터베이스에 저장하지 않아도 이메일 수신함, 발송 기록, 백업과 첨부 파일에 문의 정보가 남을 수 있습니다. 어느 시스템이 기준 보관 장소인지, 상담이 끝났다는 상태를 누가 판단하는지와 다른 법적 보존 의무가 있는 자료를 어떻게 분리할지 정해야 합니다.

개인정보 보호법은 보유 기간이 지나거나 처리 목적을 달성해 개인정보가 불필요하게 되었을 때 지체 없이 파기하도록 규정합니다. 삭제 버튼의 존재만으로 끝내지 않고 원본, 첨부, 내보낸 파일과 승인된 백업 범위에서 삭제가 어떻게 반영되는지 운영 절차로 확인합니다.

사용자가 전송 버튼을 여러 번 누르거나 서버 응답이 늦으면 같은 문의와 자동응답이 중복될 수 있습니다. 제출 중에는 다시 누르기 어렵게 하고, 서버에서는 같은 요청을 구분할 기준을 두며, 처리 결과가 모호하면 무조건 다시 전송하지 않고 실제 접수 상태를 확인합니다.

외부 이메일 서비스가 실패했을 때 입력 전체를 오류 로그에 남겨 재처리하는 방식은 피합니다. 안전한 접수 식별자, 실패 단계와 시각처럼 운영에 필요한 정보만 남기고, 임시 데이터가 생겼다면 보관 기한과 삭제 방법을 함께 정합니다.

폼 항목만 정리한 문서에는 전달 대상, 열람 권한과 삭제 책임이 빠지기 쉽습니다. 항목마다 목적, 필수 여부, 검증 규칙, 전달 위치, 열람 역할, 보관 종료와 오류 대응을 한 행에 적으면 화면 문구와 서버 처리가 같은 기준을 사용하는지 확인할 수 있습니다.

인캔트는 확정된 운영 기준만 구현값으로 사용합니다. 미정인 스팸 방지 서비스, 보관 기간과 외부 전송 경로를 임의로 채우지 않고 결정 담당자와 확인 시점을 표시합니다. 정상·잘못된 입력·중복·전달 실패·삭제 요청을 실제 흐름으로 검수하고 운영 담당자가 같은 결과를 재현할 수 있을 때 인계합니다. 전체 운영표는 인캔트 공식 원문에서 확인할 수 있습니다.