상담 신청 버튼이 메일앱만 열던 지사 홈페이지, 접수를 서버로 옮긴 기록

이름과 연락처를 넣고 상담 신청 버튼을 눌렀습니다. 화면에는 빈 메일 작성 창이 떴습니다.

받는 사람 칸에는 지사 주소가 들어 있었습니다. 방금 적은 내용은 본문 어디에도 정리돼 있지 않았습니다.

PC에 메일 프로그램을 설정해 둔 사람이라면 여기서 전송을 누를 수도 있습니다. 설정이 없는 사람에게 그 버튼은 아무 일도 하지 않는 버튼이었습니다.

보험대리점(GA) 지사 홈페이지에서 실제로 있던 장면입니다. 그리고 그 버튼을 그렇게 만든 사람은 저였습니다.

껍데기 화면에서 시작된 일

처음 들어온 신고는 "홈페이지가 엉뚱한 화면으로 바뀌었다"였습니다. 지사 소개 대신 플랫폼 기본 껍데기 화면이 뜨고 있었습니다.

이 사이트는 여러 지사를 얹도록 만든 플랫폼 위에 얹혀 있었습니다. 앞단은 도메인을 보고 뒷단 API에 "이 주소는 어느 지사냐"를 물어 화면을 골랐습니다.

추적해 보니 서버 저장소 볼륨을 다시 만드는 작업에서 그 뒷단 API가 사라져 있었습니다. 앞단은 조회가 실패하면 막지 않고 통과시키게 짜여 있었습니다.

그래서 에러 화면 대신 기본 껍데기로 떨어졌습니다. 겉으로는 누가 사이트를 덮어쓴 것처럼 보였지만 데이터는 살아 있었습니다.

저장소 1판과 DB 54판

결정은 공용 플랫폼에서 떼어 내 정적 단독 사이트로 가는 것이었습니다. 문구와 사진을 어디서 가져올지가 먼저 걸렸습니다.

코드 저장소에 콘텐츠 파일이 있었는데 1판이었습니다. DB에 남은 콘텐츠는 54판까지 고쳐져 있었습니다.

저장소 파일을 믿었다면 54판까지 고쳐 온 문구를 버리고 옛 판을 박제할 뻔했습니다. 그래서 DB에서 추출한 54판을 정본으로 삼아 사이트에 넣었습니다.

사이트를 옮기는 작업을 맡기실 때도 이 질문은 꼭 하세요. 지금 화면의 내용이 어느 저장소의 몇 번째 판인지 물어보시면 됩니다.

메일 창 방식을 고른 이유와 대가

정적 사이트로 떼면서 상담폼도 손봐야 했습니다. 예전에는 뒷단 API가 접수를 받았는데 그 API가 없어졌기 때문입니다.

그때 저는 뒷단 없이 바로 쓸 수 있는 방식을 골랐습니다. 버튼을 누르면 지사 주소로 메일 창을 여는 mailto 방식입니다.

서버에 저장되는 개인정보가 0이라는 장점도 있었습니다.

대가는 방문자가 치렀습니다. 휴대폰 기본 메일앱이 비어 있거나 PC에 메일 계정을 안 붙인 사람에게는 이 버튼이 막다른 길입니다.

그런 방문자는 버튼을 누르고 아무 반응이 없으니 창을 닫습니다. 지사 쪽에는 흔적조차 남지 않습니다.

새는 문의는 새는지조차 보이지 않는다는 점이 이 방식의 가장 큰 문제였습니다.

서버 접수로 바꾸면 달라지는 것

나흘 뒤 접수를 서버로 옮겼습니다. 버튼은 입력값을 사이트 서버로 보내고, 서버가 메일 발송 서비스를 통해 지사 메일함으로 알림을 보냅니다.

확인할 것	mailto 방식	서버 접수
메일 계정 없는 방문자	접수 불가	접수됨
접수 확인 문구	없음	"상담 신청이 접수되었습니다"
실패했을 때	방문자도 지사도 모름	실패 안내와 대안 표시
봇·스팸 거르기	불가	서버에서 거름

방문자가 할 일은 버튼 한 번으로 줄었습니다. 이메일을 보낼 줄 아는지는 더 이상 접수 조건이 아닙니다.

착수 전에는 발송 도메인 인증에 몇 시간이 걸릴 거라고 걱정했습니다. 막상 조회해 보니 같은 지사의 계약관리 CRM을 세팅할 때 도메인 인증이 이미 끝나 있었습니다.

작업 전에 실제 상태부터 보니 계획이 절반으로 줄었습니다. 이 착각은 보름 뒤에 한 번 더 반복됩니다.

접수 창구에 넣은 방어선

공개 웹에 접수 창구를 열면 사람만 들어오지 않습니다. 서버 쪽에는 이런 장치를 넣었습니다.

• 이름·연락처 형식을 서버에서 다시 검증합니다. 화면 검증은 우회할 수 있어서입니다.
• 사람 눈에 안 보이는 숨은 입력칸을 둡니다. 자동 프로그램은 이 칸까지 채우므로 거기 값이 있으면 버립니다.
• 방문자가 적은 글은 HTML 이스케이프를 거친 뒤 메일 본문에 넣습니다. 입력란에 태그를 넣어도 지사 메일함에서 실행되지 않습니다.
• 서버 로그에는 이름과 연락처를 남기지 않습니다. 오류가 나도 개인정보가 로그 파일에 쌓이지 않게 했습니다.
• 잘못된 입력과 서버 오류를 다른 응답 코드로 돌려줍니다. 그래야 화면이 상황에 맞는 안내를 고를 수 있습니다.

화면 쪽에는 전송 중 표시를 붙이고 버튼을 잠갔습니다. 반응이 느리다고 두세 번 누르면 같은 상담이 여러 건 들어가기 때문입니다.

전송이 실패하면 실패했다고 알리고 다른 연락 방법을 띄웁니다. 실패한 방문자를 빈손으로 돌려보내지 않으려는 장치입니다.

마지막으로 라이브 사이트에서 테스트 신청을 넣었습니다. 발송 서비스 기록에 delivered가 찍히고 실제 지사 메일함에 도착한 것까지 보고 나서 끝냈습니다.

보름 뒤에 찾은 빈 값

여기서 끝났다면 좋았을 겁니다. 보름쯤 지나 지사 대표 주소로 오는 메일을 담당자에게 돌려야 하느냐는 질문을 받고 발송 설정을 다시 열었습니다.

보내는 사람 주소를 담는 설정값이 빈 문자열이었습니다. 코드는 값이 비면 발송 서비스의 공용 샘플 주소로 보내게 되어 있었습니다.

테스트 메일은 도착했으니 그때는 몰랐습니다. 하지만 포털 메일이 이런 공용 주소를 스팸으로 분류하면 상담 알림이 통째로 사라질 수 있었습니다.

이번에도 저는 "도메인 인증부터 다시 해야 한다"고 먼저 말했고, 틀렸습니다. 인증은 멀쩡했고 값만 비어 있었습니다.

원인으로 보이는 것은 배포 도구의 동작이었습니다. 비대화형으로 환경변수를 넣으면 "추가됨" 메시지는 뜨는데 값은 빈 문자열로 저장됐습니다.

누군가 설정했다고 믿고 넘어간 자리였고, 그 누군가에는 저도 들어갑니다. 값을 다른 경로로 다시 넣고 지사 도메인 주소로 바꿨습니다.

다시 보낸 알림이 받은편지함에 스팸 분류 없이 들어오고, 발신자가 지사 도메인으로 찍힌 것을 확인했습니다. 그 주소로 들어오는 회신이 담당자 메일함으로 전달되는 것도 함께 확인했습니다.

검색 유입을 아무리 늘려도 폼 제출이 지사에 닿지 않으면 소용이 없습니다. 그날 한 작업 가운데 가장 값진 수정이 이 한 칸이었을 수 있습니다.

코드로는 안 보이던 가림

같은 사이트 개편 때 잡은 문제가 하나 더 있습니다. 휴대폰 화면 하단에 고정한 상담 버튼이 첫 화면의 숫자 띠를 덮고 있었습니다.

코드를 읽어서는 보이지 않았습니다. 둘 다 화면 아래에 붙도록 각자 바르게 짜여 있었기 때문입니다.

데스크톱 1440px와 모바일 390px 폭으로 전 구간을 실제 캡처해 읽다가 잡혔습니다. 모바일에서만 숫자 띠 아래에 72px 여백을 주어 버튼과 겹치지 않게 고쳤습니다.

고정 상담 버튼은 누르기 쉬워서 답니다. 그런데 이 사이트에서는 그 버튼이 첫 화면의 성과 숫자를 가리고 있었습니다.

접수 다음 칸은 CRM

지금 이 상담폼은 지사 메일함에 알림을 보내는 데까지 와 있습니다. 메일함은 놓치기 쉬운 곳이라 다음 연결을 잡아 두었습니다.

이 지사는 공개 홈페이지와 내부 계약관리 CRM을 한 회사 시스템으로 씁니다. 발송 도메인도 CRM 세팅 때 함께 생겼습니다.

그래서 들어온 상담을 CRM의 상담 목록으로 바로 넣는 것이 자연스러운 다음 단계입니다. 담당자 배정과 연락 이력이 한 화면에 남게 됩니다.

지사 홈페이지를 새로 만들거나 손볼 계획이라면 GA 지사 홈페이지 구성을 먼저 보세요. 상담 이후의 관리까지 이을 생각이면 지사용 계약관리 CRM이 그 다음 칸입니다.

홈페이지 문의 동선 점검 5문항

지금 운영 중인 홈페이지를 열고 아래를 직접 눌러 보세요. 개발자가 아니어도 확인할 수 있는 것만 골랐습니다.

1. 상담 신청 버튼을 눌렀을 때 메일 프로그램이 열립니까? 열린다면 메일 계정 없는 방문자의 문의는 지금도 새고 있습니다.
2. 봇을 거르는 장치가 있습니까? 광고성 신청이 하루에 몇 건씩 섞여 들어온다면 숨은 입력칸 같은 장치가 없을 가능성이 큽니다.
3. 방문자의 이름과 연락처가 서버 로그에 남습니까? 제작사에 로그에 무엇을 기록하는지 물어보세요.
4. 실제 수신함 도착까지 확인했습니까? 발신 주소가 지사 도메인인지, 스팸함에 들어가지 않는지 휴대폰으로 신청해 보면 압니다.
5. 휴대폰에서 하단 고정 버튼이 내용을 가리지 않습니까? 첫 화면을 맨 아래까지 천천히 내려 보세요.

한 문항이라도 걸린다면 디자인을 바꾸기 전에 접수 동선부터 고치시길 권합니다. 어디서 새는지 함께 확인하고 싶으시면 문의 폼에 지금 주소와 걸린 문항 번호만 적어 주셔도 됩니다.