광고성 편지와 달리, 이용자가 무언가를 요청해서 나가는 편지가 있습니다. 가입 확인, 비밀번호 재설정, 결제 영수증이 그렇습니다. 이런 편지는 오지 않으면 서비스 이용 자체가 막히므로, 출시 전에 따로 점검할 가치가 있습니다.
트랜잭션 메일은 무엇이 다른가요?
첫째, 받는 사람이 기다리고 있습니다. 광고 편지는 안 와도 아무 일이 없지만, 재설정 편지가 오지 않으면 이용자는 그 화면에서 멈춥니다. 그래서 도달률이 곧 기능의 완성도가 됩니다.
둘째, 내용이 사람마다 다릅니다. 이름과 주문 내역과 만료 시각이 각각 다르게 들어가므로, 한 통을 확인했다고 모든 경우를 확인한 것이 아닙니다.
셋째, 시점이 정해져 있습니다. 재설정 링크는 곧 만료되고, 확인 링크는 한 번만 쓸 수 있습니다. 늦게 도착한 편지는 아무 가치가 없습니다.
넷째, 실패가 조용합니다. 발송이 실패해도 서비스 화면은 아무 일 없다는 듯 넘어가는 경우가 많아서, 이용자의 문의가 오기 전까지 모릅니다.
이런 성질 때문에 트랜잭션 메일은 기능의 일부로 다루는 편이 맞습니다. 별도의 부가 기능으로 두면 시험 목록에도 빠지고, 출시 점검에서도 잊힙니다. 편지가 나가는 경로를 화면 흐름의 마지막 단계로 보고, 그 단계가 실패했을 때 이용자가 무엇을 보게 되는지까지 정해 두면 훨씬 안전합니다.
무엇을 보낼지 정하는 일도 중요합니다. 모든 사건에 편지를 보내면 이용자는 안내를 읽지 않게 되고, 정작 중요한 편지도 함께 무시됩니다. 꼭 필요한 사건만 골라 두고, 나머지는 화면 안에서 처리하는 편이 낫습니다.
출시 전에 무엇을 확인해야 하나요?
- 편지가 실제로 도착하는가. 시험용 주소로 모든 종류를 한 번씩 받아 봅니다.
- 제목과 본문의 이름과 값이 요청한 사람의 것이 맞는가. 다른 사람의 값이 섞이면 중대한 문제입니다.
- 링크를 눌렀을 때 의도한 화면으로 가는가. 주소가 옛 환경을 가리키는 경우가 흔합니다.
- 링크가 한 번만 유효한가. 두 번 눌렀을 때 무엇이 보이는지 확인합니다.
- 글자가 깨지지 않는가. 긴 이름과 특수 문자가 들어간 값을 넣어 봅니다.
- 같은 요청을 반복했을 때 편지가 몇 통 나가는가. 두 통이 정상인지 한 통이 정상인지 정해 둡니다.
- 수신 거부한 사람에게도 나가는 편지인지 확인합니다. 요청에 따른 편지는 보통 예외입니다.
실패하기 쉬운 자리는 어디인가요?
첫째는 환경 설정입니다. 시험 환경에서 만든 링크가 운영 주소를 가리키거나, 반대로 운영 편지가 시험 화면으로 가는 일이 자주 생깁니다. 주소를 코드에 박아 두면 환경을 옮길 때마다 이 실수가 반복됩니다.
둘째는 글자 인코딩입니다. 이름에 라틴 문자 이외의 글자가 들어가면 제목이 깨지거나, 길이 제한에 걸려 잘리거나, 일부 앱에서 물음표로 보입니다. 제목과 본문을 각각 다른 인코딩으로 다루는 실수도 흔합니다.
셋째는 템플릿의 값 누락입니다. 새로 추가한 항목을 템플릿에 넣지 않으면 빈칸이 그대로 나갑니다. 반대로 더 이상 쓰지 않는 값이 남아 있으면 지난 요청의 값이 섞입니다.
넷째는 만료와 재사용입니다. 링크를 만든 시각과 검사하는 시각을 서로 다른 기준으로 재면, 방금 받은 편지가 이미 만료되었다고 나옵니다.
다섯째는 발송 실패를 삼키는 코드입니다. 예외를 잡아 로그만 남기고 넘어가면 이용자는 이유를 모른 채 기다립니다. 실패를 알리고 다시 시도할 길을 주는 편이 낫습니다.
여섯째는 목록과 실제 발송의 어긋남입니다. 새로 추가한 편지 종류를 점검 목록에 넣지 않으면, 그 편지는 아무도 확인하지 않은 채 운영에 나갑니다. 반대로 더 이상 보내지 않는 편지가 목록에 남아 있으면, 점검 결과가 늘 실패로 표시되어 사람들이 결과를 무시하게 됩니다.
일곱째는 문구의 어색함입니다. 자리 표시자를 치환하지 않고 보낸 편지, 조사가 어긋난 이름, 지역에 맞지 않는 날짜 표기는 자동 점검으로 잡히지 않습니다. 결국 사람이 한 번 읽어야 합니다.
우리 도구로 실제 수신을 확인하는 방법
임시 메일에서 주소를 만들고, 그 주소로 각 종류의 편지를 한 번씩 받아 보세요. 제목과 본문과 링크를 화면에서 그대로 볼 수 있으므로, 사람이 눈으로 하는 최종 점검에 적합합니다. 언어와 지역 설정을 바꿔 가며 같은 편지를 받아 보면 인코딩 문제도 함께 드러납니다.
여기서 받는 편지는 점검을 위한 시험 자료일 뿐이며, 실제 이용자에게 보내는 안내로 쓸 수 없습니다.
여러 언어를 지원한다면 국가별 주소 형식처럼 지역별 표기 차이를 확인하고, 언어마다 같은 목록을 한 번씩 돌려 보세요. 한 언어에서 통과한 편지가 다른 언어에서 깨지는 일은 생각보다 자주 생깁니다.
개발자를 위한 메모: 점검을 자동화할 때
- 편지 종류마다 시나리오를 하나씩 둡니다. 한 시나리오로 여러 종류를 덮으려 하면 어느 종류가 깨졌는지 알 수 없습니다.
- 값이 들어가는 자리를 모두 채운 시험 데이터를 씁니다. 빈 값으로 통과한 시험은 운영에서 처음 실패합니다.
- 링크는 존재만 확인하지 말고 눌러서 도착 화면까지 확인합니다. 주소가 맞아도 화면이 틀릴 수 있습니다.
- 만료와 재사용을 각각 시험합니다. 한 번 쓴 링크를 다시 쓰는 경우와 시간이 지난 링크를 쓰는 경우는 다른 경로입니다.
- 발송 실패를 일부러 만들어 봅니다. 실패를 알리는지, 이용자에게 무엇이 보이는지 확인합니다.
- 목록 자체를 버전 관리합니다. 새 편지 종류를 추가할 때 목록에 넣는 일을 잊지 않게 만드는 편이 좋습니다. 앞 단계의 내용은 인증 흐름 테스트에 정리해 두었습니다.
다음 단계
출시 전에 이 목록을 한 번 그대로 돌려 보시길 권합니다. 그 뒤에는 실제로 도착한 편지 한 통을 열어 두고, 제목과 본문과 링크를 천천히 읽어 보세요. 자동화가 확인하지 못하는 어색한 문구와 빠진 안내는 결국 사람이 찾습니다. 마지막으로 임시 메일에서 주소를 하나 더 만들어 다른 언어 설정으로 같은 편지를 받아 보시길 권합니다.