예약 발송 메시지 이벤트의 보관·전달·파기 정책 설계법

미래의 나에게 메시지를 보내는 타임캡슐 이벤트와 예약 편지 캠페인은 사용자가 오늘 작성한 문장을 미래의 특정 날짜에 다시 전달하는 방식입니다.

오늘 메시지 작성
→ 일정 기간 보관
→ 예약일 도착
→ 메시지 발송

일반적인 댓글 이벤트는 제출과 동시에 콘텐츠가 공개되거나 이벤트 기간 안에 심사가 끝납니다.

예약 발송 이벤트는 메시지를 몇 달에서 1년 이상 보관할 수 있습니다.

이 때문에 이벤트 페이지 제작뿐 아니라 다음 장기 운영 정책이 필요합니다.

• 메시지를 어디에 저장하는가?
• 누가 내용을 볼 수 있는가?
• 사용자가 수정하거나 취소할 수 있는가?
• 예약 날짜는 어떻게 계산하는가?
• 발송 실패 시 몇 번 다시 시도하는가?
• 연락처가 바뀌면 어떻게 하는가?
• 발송이 끝난 메시지는 언제 삭제하는가?
• 이벤트 접수 종료 후 서버는 누가 운영하는가?

이벤트 페이지 운영 1개월
≠
전체 시스템 운영 1개월

접수 기간은 짧아도 마지막 예약 메시지가 발송되고 데이터가 파기될 때까지 시스템을 계속 유지해야 합니다.

구체적인 개인정보 보유 기간과 처리 기준은 캠페인 구조에 따라 개인정보·법무 담당자나 전문가의 검토를 받아야 합니다.

예약 발송 정책의 4개 영역

1. 메시지 수집
2. 안전한 보관
3. 정확한 발송
4. 발송 후 파기

이 네 영역을 별도로 설계하되 하나의 일정으로 연결해야 합니다.

1. 메시지 수집 정책

먼저 어떤 내용을 누구에게 보내는 이벤트인지 정해야 합니다.

자기 자신에게 발송

작성자
= 수신자

본인이 인증한 이메일과 휴대전화로만 보낼 수 있습니다.

장점:

• 스팸과 사칭 위험 감소
• 수신자 동의 구조 단순화
• 이벤트 콘셉트 명확

다른 사람에게 발송

작성자
≠
수신자

감사 메시지와 초대, 기념일 캠페인으로 확장할 수 있지만 다음 문제가 발생할 수 있습니다.

• 수신자가 원하지 않는 메시지
• 타인의 연락처 입력
• 광고성 메시지
• 괴롭힘과 위협
• 사칭
• 동의 없는 개인정보 제공

미래의 나에게 보내는 캠페인이라면 인증된 본인 연락처로 제한하는 것이 운영하기 쉬울 수 있습니다.

2. 필요한 정보만 받는다

예약 메시지 발송에 필요한 정보는 채널에 따라 다릅니다.

이메일 발송

• 이메일 주소
• 수신 날짜
• 메시지
• 인증 상태
• 동의 기록

문자·알림톡

• 휴대전화 번호
• 수신 날짜
• 메시지 또는 메시지 링크
• 인증 상태
• 동의 기록

회원 보관함

• 회원 ID
• 메시지
• 수신 날짜
• 알림 채널

이름과 생년월일, 주소가 실제 발송에 필요하지 않다면 받지 않을 수 있습니다.

3. 연락처 인증

잘못된 연락처에 메시지를 보내지 않도록 인증을 사용할 수 있습니다.

이메일 입력
→ 인증 링크
→ 인증 완료
→ 예약 확정

휴대전화 입력
→ 인증번호
→ 인증 완료
→ 예약 확정

인증 전 상태

• 임시 작성
• 인증 대기
• 예약 미확정

인증 후 상태

• 예약 확정
• 발송 대상

인증하지 않은 임시 메시지를 얼마 동안 보관할지도 정해야 합니다.

인증 대기 메시지
→ 24시간 후 삭제

실제 기간은 정책에 맞게 정합니다.

4. 작성 가능한 콘텐츠 기준

미래 메시지는 개인적인 내용이 포함될 수 있습니다.

기본적으로 비공개로 저장하더라도 시스템 악용을 막기 위한 기준이 필요할 수 있습니다.

• 과도한 대량 메시지
• 불법적인 내용
• 피싱 링크
• 타인의 개인정보
• 광고·스팸
• 위협과 괴롭힘
• 악성 코드 링크

사용자의 사적인 문장을 운영자가 일일이 검수하는 방식은 적절하지 않을 수 있습니다.

대량 자동화와 외부 URL, 타인 수신 등의 위험 요소를 시스템 수준에서 제한할 수 있습니다.

5. 메시지 길이와 형식

발송 채널에 따라 메시지 길이를 정합니다.

이메일

긴 문장과 이미지, 편지 형식에 적합합니다.

문자

길이가 길면 여러 건으로 나뉘거나 비용이 늘어날 수 있습니다.

알림톡

승인된 템플릿과 버튼 구조가 필요할 수 있습니다.

링크 방식

도착 알림
→ 인증된 메시지 페이지
→ 전체 편지 확인

메시지가 길다면 알림에는 짧은 안내만 보내고 웹페이지에서 확인하게 할 수 있습니다.

6. 예약 날짜 정책

고정 날짜

모든 메시지:
12월 31일 발송

운영은 단순하지만 발송량이 특정 시각에 몰립니다.

상대 날짜

작성일로부터 30일
100일
1년

사용자마다 발송일이 다릅니다.

직접 선택

사용자가 날짜 지정

선택 가능한 최소·최대 기간을 정해야 합니다.

최소:
7일 후

최대:
1년 후

7. 시간대 기준

사용자가 날짜만 선택했더라도 실제 발송 시각이 필요합니다.

예약일 오전 9시

또는 작성 시각과 같은 시간에 발송할 수 있습니다.

해외 사용자가 있다면 사용자 현지 시간과 서비스 기준 시간 중 무엇을 사용할지 정해야 합니다.

안내 예시

선택한 날짜의 오전 9시,
한국 표준시를 기준으로 발송됩니다.

8. 보관 기간을 계산한다

예약 메시지의 보관 기간은 다음으로 구성될 수 있습니다.

작성일부터 예약 발송일까지
+ 발송 실패 재시도 기간
+ 문의 대응 기간

예시:

최대 예약:
1년

재시도:
7일

문의 대응:
30일

최대 운영:
약 13개월 이상

캠페인 계약과 서버 비용을 이벤트 접수 기간만 기준으로 잡으면 안 됩니다.

9. 메시지 저장 상태

임시 저장
인증 대기
예약 확정
발송 대기
발송 중
발송 성공
발송 실패
재시도
취소
파기 예정
파기 완료

상태를 구분해야 운영자가 어떤 메시지를 처리해야 하는지 알 수 있습니다.

10. 메시지 본문 암호화와 접근 권한

미래 메시지는 개인적인 감정과 경험을 포함할 수 있습니다.

운영자가 필요 없이 메시지 본문을 읽을 수 있는 구조는 피하는 것이 좋습니다.

관리자에서 기본적으로 볼 정보

• 예약 번호
• 발송 날짜
• 발송 채널
• 연락처 마스킹
• 발송 상태
• 오류 코드

제한된 본문 접근

문의와 장애 대응에 정말 필요한 경우에만 별도 권한으로 접근할 수 있습니다.

접근 기록

관리자:
접근 시각:
접근 목적:
예약 번호:

시스템과 조직의 보안 정책에 맞게 설계해야 합니다.

11. 메시지와 연락처를 분리해서 저장한다

가능하다면 메시지 본문과 수신자 연락처를 논리적으로 분리할 수 있습니다.

예약 ID
→ 메시지 본문

예약 ID
→ 수신 연락처

한 영역의 데이터만으로 전체 내용을 바로 식별하기 어렵게 만들 수 있습니다.

구체적인 기술 구조는 보안 담당자와 검토해야 합니다.

12. 사용자 수정 정책

예약 후 메시지를 수정할 수 있게 할지 정합니다.

수정 허용

• 오탈자 수정
• 생각 변경
• 연락처 변경
• 발송 날짜 변경

수정 제한

발송 작업에 들어가기 전까지만 가능합니다.

발송 24시간 전까지 수정 가능

수정 이력

최초 작성
수정 시각
변경된 발송 날짜

본문의 이전 버전을 계속 보관할 필요가 있는지 검토해야 합니다.

13. 예약 취소와 삭제

사용자는 발송 전 예약을 취소할 수 있습니다.

예약 내역
→ 취소
→ 메시지 삭제

취소한 메시지를 즉시 삭제할지 일정 기간 후 파기할지 정해야 합니다.

본인 확인

• 로그인
• 인증 링크
• 이메일 재인증
• 휴대전화 인증

누구나 예약 번호만으로 다른 사람의 메시지를 삭제할 수 없어야 합니다.

14. 연락처 변경

1년 뒤에는 이메일과 휴대전화 번호가 바뀔 수 있습니다.

회원 기반

마이페이지에서 수신 연락처를 변경할 수 있습니다.

비회원 기반

예약 확인 링크와 인증을 통해 변경할 수 있습니다.

변경 마감

발송 24시간 전까지

이미 발송 작업이 시작된 경우 변경이 어려울 수 있습니다.

15. 발송 작업 설계

시스템은 정해진 간격으로 발송 대상 메시지를 확인할 수 있습니다.

매시간
→ 발송 대상 조회
→ 발송 요청
→ 결과 기록

대량 발송

특정 기념일에 메시지가 몰리면 발송 업체 한도를 확인해야 합니다.

12월 31일 오전 9시
→ 메시지 100,000건

필요하면 일정 시간에 나누어 발송할 수 있습니다.

16. 중복 발송 방지

서버가 재시작되거나 작업이 중복 실행될 수 있습니다.

발송 작업 A
→ 메시지 발송

발송 작업 B
→ 같은 메시지 다시 발송

예약 ID를 기준으로 한 번만 처리되어야 합니다.

발송 기록

• 발송 요청 ID
• 요청 시각
• 업체 응답
• 성공·실패
• 재시도 횟수

17. 발송 성공의 기준

외부 발송 업체가 요청을 받았다는 것과 사용자가 실제 메시지를 확인했다는 것은 다릅니다.

API 요청 성공
→ 발송 업체 접수

이메일 열람
→ 사용자가 확인했을 가능성

이메일 열람 추적은 정확하지 않을 수 있습니다.

정책상 발송 성공의 기준을 외부 시스템 접수 또는 전달 결과로 정의할 수 있습니다.

18. 발송 실패와 재시도

실패 원인:

• 잘못된 이메일
• 존재하지 않는 번호
• 발송 업체 장애
• 네트워크 오류
• 템플릿 오류
• 수신 거부
• 일일 발송 한도

재시도 예시

1차 실패
→ 10분 후 재시도

2차 실패
→ 1시간 후 재시도

3차 실패
→ 다음 날 재시도

최종 실패
→ 운영자 확인

무제한 재시도하면 비용과 중복 발송 위험이 커질 수 있습니다.

19. 대체 발송 채널

알림톡이 실패하면 문자로 보낼 수 있습니다.

이메일 실패 시 다른 연락처로 자동 발송하는 것은 사용자의 사전 선택과 동의가 필요할 수 있습니다.

기본 채널:
알림톡

실패 시:
문자

대체 채널과 비용, 메시지 길이를 사전에 정해야 합니다.

20. 발송 완료 후 사용자 경험

도착한 메시지에는 사용자가 과거의 자신이 보낸 편지라는 사실을 바로 이해할 수 있게 해야 합니다.

100일 전의 당신이 보낸 메시지가 도착했습니다.

이메일 구성

• 작성 날짜
• 메시지 본문
• 캠페인명
• 답장 쓰기
• 새로운 예약
• 개인정보 문의

브랜드 광고가 개인 메시지보다 크게 보이지 않도록 균형을 잡는 것이 좋습니다.

21. 발송 후 다시 보관할까?

즉시 파기

발송 성공 후 바로 삭제할 수 있습니다.

단점:

• 발송 문의 대응 어려움
• 사용자가 다시 확인할 수 없음

일정 기간 보관

발송 후 30일
→ 재확인·문의
→ 파기

회원 보관함

사용자가 장기 보관을 선택하면 마이페이지에 남길 수 있습니다.

이 경우 일회성 이벤트 데이터가 아니라 회원 콘텐츠로 처리되는 별도 정책이 필요할 수 있습니다.

22. 발송 후 파기 정책

파기 대상:

• 메시지 본문
• 수신 연락처
• 인증 정보
• 발송 기록의 개인 식별 정보
• 임시 파일

운영 리포트에는 개인 메시지를 제외한 익명 통계만 남길 수 있습니다.

전체 예약 수
발송 성공률
실패율
선택 기간

23. 취소·실패 메시지의 파기

인증하지 않은 메시지

짧은 기간 후 자동 삭제할 수 있습니다.

사용자가 취소한 메시지

취소 처리 후 정해진 일정에 따라 삭제합니다.

최종 발송 실패

문의 대응 기간 동안 보관한 뒤 파기할 수 있습니다.

각 상태별 파기 규칙이 필요합니다.

24. 이벤트 종료 후 운영 주체

접수 페이지가 닫힌 뒤에도 다음 담당자가 필요합니다.

• 서버 운영
• 발송 시스템
• 발송 비용 결제
• 오류 알림
• 사용자 수정·취소
• 개인정보 삭제 요청
• 최종 파기

제작사와의 계약이 접수 종료일에 끝나면 장기 발송을 운영할 주체가 사라질 수 있습니다.

25. 관리자 기능

• 예약 수
• 발송 예정일
• 발송 채널
• 인증 상태
• 발송 상태
• 실패 원인
• 재시도
• 사용자 취소
• 파기 예정일
• 파기 완료
• 관리자 접근 기록

본문 검색과 대량 다운로드는 꼭 필요한지 신중하게 검토해야 합니다.

정책 일정 예시

8월 1일~31일
→ 메시지 접수

최대 예약일
→ 다음 해 8월 31일

발송 실패 재시도
→ 최대 7일

문의 대응
→ 발송 후 30일

최종 파기
→ 마지막 문의 기간 종료 후

예약 발송 정책 양식

캠페인 목적:
작성자와 수신자:
발송 채널:
연락처 인증:
메시지 길이:
URL 허용:
예약 가능 기간:
발송 시각:
시간대:
수정 마감:
취소:
연락처 변경:
보관 기간:
관리자 본문 접근:
발송 재시도:
대체 채널:
발송 후 보관:
파기:
최종 운영 종료일:

QA 체크리스트

[ ] 인증하지 않은 예약이 발송 대상에 포함되지 않는다.
[ ] 선택한 날짜와 실제 발송일이 일치한다.
[ ] 시간대와 윤년·월말 날짜를 처리한다.
[ ] 발송 전 메시지와 연락처를 수정할 수 있다.
[ ] 취소된 예약이 발송되지 않는다.
[ ] 동일 메시지가 두 번 발송되지 않는다.
[ ] 발송 실패 후 정해진 횟수만 재시도한다.
[ ] 대체 채널 정책이 정확하게 적용된다.
[ ] 관리자에서 연락처가 마스킹된다.
[ ] 메시지 본문 접근 권한이 제한된다.
[ ] 이벤트 접수 종료 후에도 발송 작업이 유지된다.
[ ] 발송 후 보관 기간이 적용된다.
[ ] 취소·미인증·최종 실패 데이터가 파기된다.
[ ] 최종 파기 완료 기록이 남는다.

마무리

예약 발송 메시지 이벤트는 감성적인 카피와 편지 작성 화면만으로 완성되지 않습니다.

메시지 수집
→ 안전한 보관
→ 약속한 날짜의 전달
→ 실패 대응
→ 최종 파기

이 전 과정을 운영할 수 있어야 합니다.

특히 이벤트 접수 기간보다 실제 시스템 운영 기간이 훨씬 길 수 있으므로 마지막 예약 메시지가 파기되는 날짜까지 서버와 담당자, 발송 비용을 함께 계획해야 합니다.