회사 이메일 주소 정하기: hello@ vs info@

작명 문제처럼 보이지만 실은 구조 문제다. 첫날 만든 주소가 누가 무엇에 답할 수 있는지, 누가 나갈 때 무슨 일이 생기는지, 2년 뒤 스팸을 얼마나 읽게 될지를 정한다.

hello@ vs info@ vs contact@

의미는 서로 바꿔 써도 되므로 두 가지 기준으로 고른다 — 어감과 스팸. info@는 기관처럼, hello@는 작고 사람답게, contact@는 중립적으로 읽힌다. 이건 진짜로 브랜드 결정이고 틀린 답은 없다.

스팸 차이는 취향 문제가 아니다. info@는 30년 동안 가장 먼저 찍히는 주소였고, 그래서 주소 수집 목록이 이걸로 가득 차 있다 — 갓 만든 도메인의 갓 만든 info@는 첫 진짜 메일보다 스팸을 먼저 받는다. hello@는 덜 찍히고, 그 덕에 첫 1년이 조용하다. 그 이상으로 영구적인 이점은 없다.

첫날 만들 만한 주소

마지막 두 개는 장식이 아니다. postmaster@와 abuse@는 다른 메일 운영자가 도메인 소유자에게 연락할 때 쓰는 역할 주소이고, 여기서 반송이 나는 도메인은 내 메일을 믿을지 판단하는 시스템들에게 관리되지 않는 곳으로 보인다. 메인 메일함을 가리키는 별칭으로 두면 비용은 0이다.

개인 이름 주소의 문제

jane@mybrand.com은 제인에게는 맞는 주소이고 어디든 오래 남는 곳에 적기에는 틀린 주소다. 제인이 나가면 그 주소를 저장해둔 모든 고객이 아무도 읽지 않는 메일함에 편지를 쓰게 되고, 서명란에 그 주소가 박힌 모든 계약서가 막다른 길을 가리키게 된다.

흔한 해법은 지루하고 잘 통한다. 사람에게는 개인 주소, 기능에는 역할 주소를 주고, 웹사이트·청구서 양식·메일 서명에는 역할 주소만 적는다. 누가 나가면 그 사람 주소를 인수자를 가리키는 별칭으로 바꾸면 되고, 회사 밖에서는 아무도 눈치채지 못한다.

no-reply@ 는 만들지 말 것

no-reply@ 발신자는 고객에게 "당신의 답장은 버려졌다"고 말하는 셈인데, 방금 말을 걸어온 사람에게 하기엔 이상한 말이다. 게다가 스팸 필터가 "사람들이 이 메일을 원한다"는 증거로 읽는 반응 신호를 없앤다. 자동 메일을 보낸다면 결국 사람이 읽는 주소에서 보낼 것 — 답장이 그냥 support@로 떨어지더라도.

이게 예산 문제였던 시절

위 목록은 전부 주소를 만드는 데 돈이 안 든다는 전제 위에 있다. 좌석 과금에서는 그렇지 않다. 메일함이 곧 라이선스라서 billing@과 press@가 사람을 한 명 더 쓰는 것과 같은 값이 된다. 팀은 그룹과 별칭으로 우회하는 법을 배우는데, 나쁘지는 않지만 문제를 풀기 위해서가 아니라 청구 방식의 부작용을 피하려고 관리 콘솔을 배우는 일이다.

메일을 도메인 단위로 과금하면 이 질문이 사라지고, 청구서를 피해 다니는 대신 위에 적은 이유들로 주소를 지을 수 있게 된다 — 애초에 작명을 제대로 하려던 목적이 그것이다.