지금 읽는 곳14일 이내 통지 의무는 무엇을 요구하는가목차
STEP 1 초급·기초 › 1-4. 필수 법률·컴플라이언스 › 과목 25 › 레슨 09
수신거부 처리 결과 통지: 유저가 수신 거부를 신청했을 때 14일 이내에 처리 결과를 이메일/문자로 안내해야 하는 법적 의무
"거부 접수했습니다"라는 응답 한 줄만 보내고 끝내면 안 되는 이유와 14일 기한을 관리하는 방법을 다룹니다.
핵심요약
- 수신자가 수신동의, 수신거부, 동의철회 의사를 표시하면 14일 이내에 처리 결과를 통지해야 한다
- 이 의무는 정보통신망법 제50조 제7항 및 시행령에 근거한 별도의 법적 의무다
- 접수 채널(080, 회신 문자, 웹 링크 등)마다 접수 시각을 정확히 기록해야 기산일을 놓치지 않는다
- 처리 결과 통지는 '접수했다'는 안내뿐 아니라 '실제로 반영됐다'는 확인까지 포함하는 것이 안전하다
- 접수부터 통지까지의 처리 과정을 자동화하지 않으면 대량 접수 시 기한을 넘기기 쉽다
14일 이내 통지 의무는 무엇을 요구하는가
정보통신망법 제50조 제7항과 시행령은 수신자가 수신동의, 수신거부 또는 수신동의 철회 의사를 표시한 날부터 14일 이내에 그 처리 결과를 해당 수신자에게 알리도록 규정합니다. 이는 앞선 레슨에서 다룬 '수신거부 이후 전송 금지' 원칙과 짝을 이루는 의무입니다. 수신거부를 금지하는 것만으로는 부족하고, 수신자가 자신의 의사표시가 실제로 어떻게 처리됐는지 확인할 수 있도록 별도로 통지해야 한다는 것이 이 조항의 취지입니다.
이 의무의 기산일은 수신자가 의사표시를 접수한 날입니다. 즉 발신자가 그 의사표시를 언제 확인했는지가 아니라, 수신자가 언제 거부 의사를 표시했는지가 기준이 됩니다. 회신 문자, 080 전화, 이메일 구독취소 링크 클릭 등 접수 채널이 다양할수록 각 채널의 접수 시각을 정확히 기록해두는 시스템이 필요합니다.
접수 채널별로 시각을 어떻게 기록해야 하나
080 서비스는 ARS로 접수된 시각이 로그로 남는 경우가 많아 비교적 기록이 명확합니다. 반면 문자 회신("거부"라고 답장)이나 이메일 원클릭 구독취소는 발송 시스템에 접수 이벤트를 자동으로 기록하도록 설정해두지 않으면, 실제 접수 시각과 담당자가 그 사실을 인지한 시각 사이에 며칠씩 차이가 날 수 있습니다. 만약 담당자가 매주 월요일에만 회신 문자를 수동으로 확인한다면, 화요일에 접수된 거부 의사는 다음 주 월요일에야 발견되고, 그 시점부터 14일을 세면 이미 상당한 시간이 흘러버린 상태로 남은 기한이 촉박해집니다.
이런 문제를 막으려면 모든 접수 채널에서 수신자의 의사표시가 들어오는 즉시 접수 시각이 타임스탬프로 자동 기록되는 구조를 만들어야 합니다. 접수 시각 기록이 자동화돼 있어야 "언제부터 14일을 세야 하는지" 자체가 명확해지고, 뒤늦게 발견해서 기한을 넘기는 사고를 막을 수 있습니다.
'접수 확인'과 '처리 결과 통지'는 다르다
많은 조직이 수신거부 요청에 대해 "수신거부가 접수되었습니다"라는 자동 응답만 보내고 이 의무를 다했다고 여기는 경우가 있습니다. 그러나 법이 요구하는 것은 '접수 확인'이 아니라 '처리 결과'의 통지입니다. 접수됐다는 사실과 실제로 발송 리스트에서 제외 처리가 완료됐다는 사실은 다른 단계이며, 접수만 되고 실제 시스템 반영이 지연되는 경우도 실무에서 종종 발생합니다.
안전한 방식은 접수 즉시 "요청을 접수했습니다"라는 1차 안내를 보내고, 실제 시스템에서 발송 대상 제외 처리가 완료된 시점에 "처리가 완료되었습니다"라는 2차 안내를 보내는 이중 구조입니다. 처리가 즉시 자동으로 완료되는 시스템이라면 두 단계를 하나의 메시지로 합쳐도 무방하지만, 수동 처리 단계가 남아있는 시스템이라면 접수와 처리완료를 구분해서 관리하는 편이 실제 처리 여부를 놓치지 않는 데 도움이 됩니다.
대량 접수 시 기한을 넘기기 쉬운 이유
평소에는 문제없이 처리되던 프로세스도 대규모 캠페인 직후 수신거부가 한꺼번에 몰리면 기한을 넘기기 쉬워집니다. 예를 들어 대량 발송 캠페인 하나가 나간 직후 수백 건의 거부 요청이 짧은 시간에 몰리면, 수동으로 하나씩 확인·통지하는 프로세스로는 14일 기한 내에 전건을 처리하지 못할 위험이 커집니다. 이런 상황을 대비해 접수부터 처리 결과 통지까지의 흐름을 시스템으로 자동화해두면, 접수 건수가 급증하더라도 개별 건의 처리 시각이 밀리지 않습니다.
자동화가 어려운 소규모 조직이라면 최소한 접수 건수가 일정 수준을 넘어서면 담당자에게 알림이 가는 임계값 경보를 설정해두어, 처리 지연을 조기에 인지할 수 있는 안전장치를 마련하는 것이 필요합니다.
통지 문구와 채널은 어떻게 정하나
처리 결과 통지는 수신자가 의사표시를 전달한 것과 같은 채널로 보내는 것이 일반적입니다. 문자로 거부를 요청했다면 문자로, 이메일 링크로 요청했다면 이메일로 결과를 알리는 방식입니다. 통지 문구에는 어떤 채널·정보 유형에 대한 수신이 중단됐는지 구체적으로 명시하는 것이 좋습니다. 여러 채널에 각각 동의한 수신자가 문자만 거부했는데 통지 문구가 "모든 광고성 정보 수신이 중단됐습니다"처럼 모호하게 적혀 있으면, 수신자가 이메일은 여전히 받게 된다는 사실을 오해할 수 있습니다.
통지를 하지 않으면 어떤 리스크가 생기나
처리 결과 통지 의무 자체는 앞서 다룬 야간 전송 위반이나 표기의무 위반만큼 눈에 띄지 않는 조항이라, 실무에서 우선순위가 밀리기 쉽습니다. 그러나 이 의무는 수신거부·동의철회 처리와 짝을 이루는 독립적인 법적 의무이므로, 아무리 실제로 발송 리스트에서 제외 처리를 제때 완료했더라도 통지 자체를 누락하면 별도의 위반으로 지적될 수 있습니다. 즉 "결과적으로 광고를 안 보냈으니 문제없다"는 판단은 이 조항 앞에서는 성립하지 않습니다.
또한 수신자 입장에서 자신의 요청이 어떻게 처리됐는지 확인할 방법이 없으면, 처리가 제대로 됐는지 불안해서 같은 요청을 여러 채널로 반복하거나 고객센터에 재문의하는 상황이 생깁니다. 이는 CS 응대 비용을 늘리는 부수적인 손실로도 이어지므로, 통지 프로세스를 제대로 갖추는 것은 법적 의무 이행을 넘어 운영 효율에도 도움이 됩니다.