아니요, 난 당신의 문의 양식을 채우기 싫습니다

 (adamjones.me)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 문의 양식은 이메일 주소 공개보다 고장·접근성·기록 부재·불필요한 개인정보 요구가 많아, 사용자와 운영자 모두에게 더 큰 부담을 만들기 쉬움
  • B&Q, AWS abuse contact form, Axa, Vodafone, Virgin Mobile 사례처럼 양식이 제출되지 않거나, 유효한 이메일을 거부하거나, 보조기술 사용자에게 불리하게 동작할 수 있음
  • UK Charity Commission의 불만 양식은 페이지마다 약 6~7초가 걸리고 11페이지를 거쳐야 하며, National Grid 양식은 사소한 피드백에도 주소·전화번호 같은 개인정보를 요구함
  • 이메일은 초안 작성, 예약 발송, 기록 보관, 워크플로 통합이 가능하지만, 문의 양식은 제출 확인이나 내용 사본조차 주지 않아 사용자가 스크린샷으로 증거를 남겨야 하는 경우가 많음
  • 구조화된 데이터 수집, 팀 배정, 스팸 방지, 보안, 접근성은 대개 이메일·자동응답·공유 메일함·고객지원 도구로 해결 가능하므로, 일반 문의에는 이메일 공개가 더 단순함

문의 양식이 사용자에게 불리한 이유

  • 문의 양식은 웹사이트에 이메일 주소를 올리는 방식보다 사용자에게 나쁜 경험을 주는 경우가 많음
  • WordPress 업그레이드나 CRM 변경 같은 이유로 양식이 조용히 고장날 수 있고, 사용자는 제출 버튼을 누른 뒤에야 실패를 알게 됨
  • B&Q의 문의 양식은 제출이 불가능한 상태였고, 네트워크 요청상 프런트엔드에는 없는 title 속성 누락 때문에 오류가 난 것으로 보임
    • 오류 메시지는 다시 시도해도 해결되지 않는 상황에서 사용자에게 빠져나갈 방법을 주지 않음
  • AWS의 abuse contact form은 수개월간 고장났다는 Hacker News 사례가 있었고, Elastoplast 문의 양식도 문제 사례로 언급됨

일부 사용자에게만 깨지는 양식

  • Axa의 문의 양식은 일부 유효한 이메일 주소를 잘못 거부함
    • test+test@example.com, tést@example.com, test@éxample.com은 RFC 6532 기준으로 유효하지만 해당 양식에서 거부됨
    • 양식에는 관련 Axa 제품이 모두 표시되지 않음
  • Vodafone의 분실·도난 기기 신고 양식은 사이트가 야간 유지보수로 자주 사용할 수 없는 상태가 됨
    • 휴대폰을 도난당한 사용자가 신고하려 할 때 유지보수 화면을 만날 수 있음
  • 많은 문의 양식은 기본적인 웹 접근성 기준을 충족하지 못해 보조기술 사용자가 작성하기 어려움
    • Virgin Mobile의 불만 페이지는 선택 표시를 숨겨 키보드 탐색이 거의 불가능함

작성 시간과 개인정보 요구

  • UK Charity Commission의 불만 양식은 각 페이지 로딩에 약 6~7초가 걸리고, 완료하려면 11페이지를 거쳐야 함
    • 페이지 로딩 대기만 약 75초가 소요됨
    • 진행 상태 표시가 없음
    • 입력 필드에 autocomplete 속성이 없어 사용자가 각 항목을 직접 다시 확인해야 함
    • 드롭다운 옵션이 그룹화되거나 일관되게 정렬되어 있지 않음
  • National Grid의 contact·feedback 양식은 간단한 피드백에도 집 주소와 전화번호 같은 개인정보를 요구함
    • 전화번호 형식 같은 단일 실수만 있어도 입력 내용을 지우고 처음부터 다시 작성하게 만듦
  • 일부 불만 양식은 생년월일이나 신분증 사본처럼 더 민감한 데이터를 요구함
    • 해당 조직이 원래 그 정보를 보유하지 않는 경우에도 요구될 수 있어, 보안 확인 목적으로 기존 기록과 대조하는 것도 아님
  • 일반 문의 양식에서 직함, 직무, 회사 규모, 유선전화 번호 같은 항목은 실제로 필요하지 않을 가능성이 큼
  • 불필요한 개인정보 수집은 데이터 탈취와 신원 사기 위험을 높이고, 신뢰하기 어려운 조직에서는 스팸 가능성도 키워 사용자가 제출을 포기하거나 허위 정보를 입력하게 만듦

이메일이 주는 실용적 이점

  • 이메일은 사용자가 초안을 만들고, 예약 발송하고, 대화 기록을 쉽게 남길 수 있게 함
  • 나중에 후속 조치를 위해 메시지를 스누즈하는 등 기존 워크플로와 통합하기도 쉬움
  • 문의 양식은 이런 기능을 대개 제공하지 않으며, 정상 동작하더라도 사용자가 나중에 참고할 수 있는 확인 메시지를 받지 못하는 경우가 많음
    • 제출한 모든 세부 내용을 담은 확인본은 더 드묾
  • 일부 회사가 양식 제출을 잃어버렸다가, 사용자가 저장해둔 스크린샷을 제시한 뒤에야 다시 찾은 경험이 있음
  • 문의 양식은 제대로 만들고 유지하는 데 시간과 에너지가 들지만, 뒤에서는 거의 항상 이메일이나 이메일을 받는 시스템으로 라우팅됨
    • 중간 단계를 없애고 이메일 주소를 공개하는 편이 단순함
  • 양식으로 받은 문의에 답변할 때 사용자가 원래 어떤 내용을 보냈는지 기억하지 못하는 상황도 생김
    • 처음부터 이메일이었다면 원문을 함께 확인할 수 있음

성가신 인터페이스 사례

  • Sainsbury’s 문의 양식은 긴 옵션 트리를 따라 내려가게 한 뒤, 모달에서 다시 같은 주제를 선택하게 함
  • 이후 표시되는 양식 창이 매우 작아 작성하기 거의 불가능한 수준임
  • 문의 양식은 위 사례 외에도 여러 방식으로 사용자에게 불필요한 마찰을 만들 수 있음

구조화된 데이터가 필요할 때

  • 문의 양식으로 구조화된 데이터를 받아 요청 처리 시간을 줄이고 싶을 수 있음
    • 고객 식별자를 정확히 받거나, 문의를 자동으로 올바른 팀에 배정하는 목적이 있을 수 있음
  • 이런 방식은 일부 상황에서 괜찮을 수 있음
    • Amazon은 최근 구매 항목을 보여주고, 반품 요청 같은 일반 고객지원 흐름을 셀프서비스로 처리하게 하면서도 사람에게 연결되는 경로를 비교적 쉽게 제공함
  • 훌륭한 고객 서비스 포털이 없다면, 일반 문의 목적에는 이메일이 더 나음
  • 필요한 세부 정보는 합리적인 자동응답으로 받을 수 있음
    • GP at hand의 자동응답은 전체적으로 명확하고 길이도 과하지 않은 예로 다뤄짐
  • 사용자가 처음부터 필요한 정보를 넣도록 mailto links에 제목과 본문 파라미터를 넣을 수도 있음
    • 예시는 관련 지원 페이지, 이름, 계정 번호, 문의 내용을 미리 채우는 방식임

문의 분류와 팀 운영

  • 문의를 자동으로 팀에 배정하기 전에 실제로 그 자동화가 필요한지 확인해야 함
    • 하루에 이메일 두 통을 받거나, 어차피 모두 같은 사람에게 가는 작은 팀이라면 문의 양식으로 분류할 필요가 약함
  • 정말 자동 배정이 필요하다면 Zendesk AI 같은 플랫폼을 검토할 수 있음
    • 이런 분류 작업은 LLM이 잘 처리하는 종류의 작업일 수 있음
    • 경우에 따라 정규식만으로도 충분할 수 있음
  • 팀 단위 메시지 관리는 이메일로도 가능함

연락 장벽, 스팸, 보안, 접근성

  • 문의 양식이 연락 장벽을 낮춘다는 생각은 경험적으로 잘 맞지 않았음
    • 3개 조직에서 이메일 공개로 전환한 뒤에도 진짜 문의 수가 양식 사용 때와 비슷했음
    • 엄밀한 데이터 분석과 공개가 있으면 다른 사람을 설득하는 데 도움이 될 수 있음
  • 아주 낮은 노력의 피드백 양식은 예외일 수 있음
    • 친근하게 비공식 이메일도 환영한다고 명확히 쓰면 완화될 수 있음
  • 익명성을 선호하는 상황에서는 양식이 장벽을 낮출 가능성이 있음
    • 성적 지향을 공개하지 않은 사람이 관련 댓글을 자기 이메일과 쉽게 연결하고 싶지 않을 수 있음
    • GOV.UK에는 익명 피드백 수집에 잘 작동하는 단순한 예시가 있음
  • 이메일을 공개하면 스팸이 늘어난다는 걱정은 실제 경험과 다를 수 있음
    • WordPress 양식보다 이메일 공개 후 스팸이 더 적었던 경우가 있었음
    • 익명 양식은 쓰레기 입력을 넣기 쉽지만, 오늘날 스팸 필터를 통과할 평판 좋은 이메일을 보내는 일은 더 어려울 수 있음
  • 걱정된다면 이메일을 스팸 봇에게 덜 보이게 난독화할 수 있지만, 이런 스팸은 드물고 스팸 필터가 좋아졌기 때문에 대개 시간 낭비일 수 있음
    • 난독화 과정에서 잘못 구현해 무언가를 망가뜨릴 위험도 있음
  • 이메일은 과거에 암호화되지 않아 매우 안전하지 않았지만, 2024년에는 일반적인 설정이라면 다른 이메일 트래픽의 약 99% 처럼 안전하게 암호화될 가능성이 큼
    • 고객이 암호화를 지원하지 않는 이메일 제공자를 쓸 이론적 가능성은 있음
    • UK National Cyber Security Centre도 자체 연락 이메일을 공개함
    • 문의 양식을 쓰고도 이후 이메일로 답변한다면, 이메일 보안만을 이유로 주소를 공개하지 않는 논리는 약해짐
  • 접근성 표준 준수를 위해 문의 양식이 필요하다는 주장은 사실이 아님
    • 이메일 주소를 공개하는 방식은 문의 양식보다 파싱하고 이해하기 쉬울 가능성이 큼
    • Equality and Human Rights Commission, Scope, AbilityNet도 연락 이메일을 공개함

의도적으로 어렵게 만든 양식

  • 일부 조직은 규제상 요구되는 연락 경로를 실제로는 사용하기 어렵게 만들고 싶어 할 수 있음
  • Meta는 데이터 보호 관련 연락을 매우 어렵게 만들며, 여러 자선단체가 Meta 양식이 찾기 어렵고 작성하기 어렵다고 지적한 바 있음
  • 작성자 경험상 Meta의 관련 절차는 복잡하고 오래 걸렸으며, 여러 깨진 양식으로 안내받았음
  • 규제기관은 법과 규정의 문구뿐 아니라 취지까지 따르는 행위자가 보상받도록 기준을 더 적절히 설정해야 함

결론

  • 문의 양식은 제대로 만들기 어렵고, 관련된 모든 사람에게 더 나쁜 경험이 되기 쉬움
  • 일반 문의에는 문의 양식을 제거하고 웹사이트에 이메일 주소를 공개하는 편이 나음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 나이가 들고 까칠해질수록, 가능하면 관여하지 않는 것이 최선이라는 걸 깨달았음
    식당이 더럽거나 직원이 무례하면 가지 않고, 웹사이트에 다크 패턴이 있거나 문의 양식이 안 되면 그 사이트를 쓰지 않음
    이유는 두 가지인데, 대부분의 사업자는 자기들이 망가진 걸 알면서도 신경 쓰지 않고, 나쁜 경험을 피하는 게 내 스트레스에도 좋기 때문임
    물론 의료 같은 필수 서비스에는 적용하기 어렵다

    • 몇 년째 그렇게 해왔지만, 지금은 구직 중이라 피할 수가 없음
      구직 사이트, 에이전시, 고용주 사이트가 전부 끔찍함
      가장 압권은 스스로 Easy Apply라고 부르던 고용주 사이트였는데, 이력서를 올리면 형편없이 파싱해서 수많은 텍스트 상자에 아무렇게나 뿌렸음
      PDF가 문제인가 싶어 Word 문서로 다시 했지만 결과가 같았고, 아마 Word를 PDF로 내보낸 뒤 같은 엉망 파서를 쓰는 듯했음
      그 텍스트를 다시 맞는 칸에 옮기는 것도 짜증 나는데, 평범한 입력칸도 아니고 입력 반응이 매우 느린 조악한 JavaScript 덩어리였음
      그러면서 고용주들은 좋은 직원을 찾기 어렵다고 투덜댐
    • 동의함. 뉴스레터 모달, 쿠키 동의 모달, 회원가입해야 읽을 수 있는 구조 같은 마찰 요소와 시간 낭비인 저품질 콘텐츠 사이에는 강한 상관관계가 있음
      이걸 깨달은 뒤로 그런 신호가 보이면 바로 탭을 닫고 뒤돌아보지 않아서 시간과 노력을 많이 아꼈음
      저품질 콘텐츠 제작자들이 알아보기 쉽게 만들어줘서 고마울 정도임
    • 어릴 때 어머니가 해준 가장 현명한 조언 중 하나는, 어떤 상호작용에서 내가 원하는 게 무엇인지 항상 생각하라는 것이었음
      문자, 이메일, 댓글, 논쟁을 하기 전에 목표가 무엇이고, 거기서 얻을 수 있는 최선이 무엇인지 따져보라는 뜻임
      이 조언 덕분에 그냥 흘려보내기가 훨씬 쉬워짐
      웹사이트가 형편없고 더 잘 만들 수 있다는 것도 맞고, 대화 상대가 명백히 틀린 것도 맞지만, 관여해봤자 약간의 카타르시스 말고 얻을 게 없고 모두의 시간만 낭비하게 됨
      그래서 그냥 놓아주는 게 낫다
    • 전적으로 동의함. 다만 최근 동네 술집에서 바 쪽에 있던 사람들이 어떤 대의를 위해 기부하고 싶게 만들어서 방법을 물었더니 결제 포털 URL을 줬음
      원래는 그 정도로 쉬웠어야 하는데, 실제로는 사용자명, 이메일, 전화번호, 특정 조건을 만족하는 비밀번호까지 요구하는 전체 계정 생성을 시켰음
      유효한 비밀번호를 세 번 만들지 못하자 그들은 내가 술을 너무 많이 마셨다고 생각하고 도와주려 했지만, 그들 역시 여러 번 시도해도 내 돈을 받기 위한 계정을 만들 수 없었음
      자기들의 웹사이트와 불필요한 계정 생성 정책이 전환을 적극적으로 막은 셈이라 한참 웃었음
      물론 웃음을 받은 사람들은 이 문제의 핵심 당사자가 아니었으니 우쭐함은 누르고, 동료들에게 알려보라고 제안했음
    • 완전히 동의함. 무례한 직원을 만나는 건 손해처럼 느껴질 수 있지만, 맞서 싸운다고 해서 이기지는 못함
      기술적으로 이기더라도 스트레스와 정신 상태를 생각하면 그냥 넘기는 편이 훨씬 낫다
      모든 일에 해당하진 않겠지만, 삶의 대부분의 사소한 짜증에는 적용될 듯함

  • “문의 양식을 채우고 싶지 않다”는 말은 맞지만, 회사나 정부도 당신에게 연락받고 싶어 하지 않음
    그들에게는 비용이기 때문임
    평균적인 “영업 견적 문의” 양식은 평균적인 “불만 접수/질문” 양식보다 더 명확하고 마찰도 적음
    사람들이 이메일 대신 양식을 쓰는 이유 중 하나는, 어떤 웹사이트에 손님으로 들어가 그쪽 양식을 채우는 상황과 맥락 때문일 수 있음
    내 이메일함에 있을 때와 남의 사이트에 있을 때는 행동 방식이 달라질 수 있음
    GitHub 이슈 템플릿의 때로 과한 질문들이 예인데, 필요한 정보를 강제하는 동시에 내가 손님이고 상대의 소통 규범을 따라야 한다는 점을 암시함

    • 솔직히 이런 도구는 상대가 자기들을 위해 과하게 맞춰주길 바라는 사람들을 걸러내는 데 꽤 잘 작동함
      누군가의 양식을 채우는 데 몇 분 쓰는 것조차 고집스럽게 거부한다면, 이후 모든 상호작용에서도 요구가 많고 협조적이지 않을 가능성이 큼
      물론 그런 사람들은 스스로를 그렇게 보지 않음
    • 회사가 판매를 하려면 고객이 연락하고 구매할 방법이 있어야 함
      형편없는 문의 양식을 두는 건 식당 웨이터가 손님 얼굴에 침을 뱉으며 인사하는 것만큼 말이 안 됨
      지금 세상이 돌아가는 걸 보면 몇 년이나 몇 달 안에 그게 표준이 될지도 모르겠지만

  • 문의 양식을 만든다면 최소한 “메시지를 받았습니다” 자동 이메일이라도 보내줬으면 함
    그래야 백엔드가 실제로 받았고 유용한 어딘가로 갔을 거라는 최소한의 확신이 생김
    자동 응답이 없으면 제대로 작동했는지 늘 의심하게 됨

    • 모든 문의 양식에는 기록 보관을 위해 Google Forms의 “응답 사본 보내기” 같은 기능이 있어야 함
    • 그게 그렇게 좋은 생각인지는 모르겠음
      악의적인 사람이 이런 양식 여러 곳에 남의 이메일을 넣어서 스팸을 보내는 걸 무엇이 막을 수 있을까
      무작위로 생성한 이메일을 잔뜩 넣어 사이트를 디도스하는 건 또 무엇이 막을까
      그리고 이런 양식 스팸이 이메일 클라이언트에서 스팸으로 보이게 만들면, 진짜 중요할 수 있는 메시지까지 스팸으로 버려지고 자동 삭제될 수 있음
    • 제출한 모든 정보도 다시 보내줘야 함

  • “공유 메일함, 협업형 받은편지함, Zendesk, Zoho Desk, Freshdesk, Zammad, osTicket, FreeScout 같은 기성 고객지원 솔루션을 이메일에 연결하라”는 목록에는 고전이자 여전히 훌륭한 Request Tracker가 빠져 있음
    https://bestpractical.com/request-tracker
    https://github.com/bestpractical/rt
    관련은 없고 요청 제출자 입장에서만 써봤지만, 항상 직관적이고 안정적이었음
    같은 시스템이 20년가량 계속 작동해왔다는 점도 가치가 있고, 한 작은 기관에서 대형 프린터 작업 제출용으로 Request Tracker를 연결해 쓰는 걸 본 적도 있을 만큼 유연함

    • 한 회사에서 썼는데, 그 회사는 Jira로 옮겼음
      RT가 그립다. 못생겼지만 좋았음
    • 어떤 걸 다른 서비스와 엉망으로 합쳐놓지 않으면 그냥 계속 잘 작동하기가 얼마나 쉬운지 웃김
      Zendesk는 아직도 사용자를 삭제할 수 없는데, 그 기능은 우리가 쓰지 않는 “Support”의 일부라서 그렇고, 사용자를 만드는 건 여전히 “Chat”의 일부라 가능함
    • 마지막으로 RT를 다뤘을 때는 뭔가 커스텀하려면 Perl로 스크립트를 짜야 했음
      Perl은 수십 년째 인기 언어가 아니고, 2024년에 Perl 개발자를 채용해보면 쉽지 않을 것임
      AI가 도와줄 수 있는 경우일지도 모르지만, AI도 RT “스크립틀릿”을 알고 있을지는 확실치 않음

  • 문의 양식은 죽었음. 요즘은 상자에 글을 입력하면 LLM이 내 문제와 전혀 관련 없는 답 몇 개를 줌
    지원팀에 연락하고 싶으면 해지하겠다고 위협해야 함
    그조차 신경 쓴다면 말이지만

    • 요즘 회사들은 조용히 오래 착취할 수 없는 고객은 놓아줘도 된다고 생각하기 시작한 것 같음
      예전에는 케이블 회사에 전화해 해지하겠다고 하면 고객 유지 전담자에게 넘겨서 몇 년 전 가격 수준으로 낮춰주는 거래를 제안하곤 했음
      마지막으로 그 수법을 써봤을 때는 잠깐 대기시키더니 “알겠습니다, 고객님. 오늘부로 서비스가 해지되었습니다. 더 도와드릴 일이 있을까요?”라고 돌아왔음
    • 2024년에 지원을 받는 방법은 소셜 미디어를 통하는 것임
      회사 계정을 태그해 불만을 올리고, 필요하면 이를 증폭해줄 대형 언론사나 유명 인터넷 창작자 태그도 몇 개 더 붙임
      예를 들어 최근 몇 년 동안 YouTube 창작자가 해킹당한 계정을 되찾은 거의 모든 사례는 Twitter 등에서 Team YouTube를 태그해서 해결된 경우였음
      요즘은 소셜 미디어 PR 악몽 가능성만이 회사를 움직이는 듯함
    • 지금까지 LLM 지원 챗봇은 하나밖에 못 봤고, 실제로는 대체로 도움이 됐음
      100%는 아니어도 꽤 괜찮았고, “이 FAQ 항목이 문제를 해결하나요?”만 반복하는 옛날 지원 챗봇보다는 나았음
      그런 FAQ는 절대 문제를 해결하지 못했으니까
    • 해지하겠다고 하면 오히려 역공으로 계정 해지/삭제 수수료 €20을 청구할 수도 있음 [0]
      [0] https://news.ycombinator.com/item?id=40246171
    • 요즘 취미는 이런 AI 고객지원 챗봇을 탈옥시키는 것임

  • 양식으로 들어오는 스팸 비율은 대체로 시간에 따라 일정하지만, 공개된 이메일 주소로 들어오는 스팸은 사이트가 스팸 봇에 반복적으로 스캔되고 주소가 점점 더 많은 스패머 목록에 추가되면서 증가함
    스팸 탐지는 좋아졌지만 완벽하지 않고, 전체 스팸 양이 늘수록 필터를 뚫고 들어오는 양도 늘어남
    어느 시점부터는 스팸함에서 오분류된 실제 메일을 찾는 것도 불가능해지고, 결국 압도되어 이메일을 바꿔야 함
    공개 이메일 주소를 올릴 거라면, 스팸 양이 너무 많아지면 교체할 소모성 자원으로 봐야 함
    글쓴이가 이걸 겪지 않았다면 공개 웹사이트에 살아 있는 이메일 주소를 여러 해 둬보지 않았기 때문일 수 있음

    • 내 이메일 주소는 최소 15년 동안 공개 웹사이트에 올라와 있었고, 스팸 수준은 일정하고 관리 가능했음
      물론 내가 충분히 유명하지 않아서 그 문제를 못 겪는 것일 수도 있음
    • 내 경험상 이메일 스팸의 정점은 15~20년 전이었음
      한때는 스팸함에 하루 약 500개가 들어왔지만, 지금 같은 주소의 평균은 하루 2개 정도임
      오래전부터는 스팸이 통과하는 것보다 스팸 필터가 정상 메일을 스팸으로 표시하거나 아예 전달하지 않는 문제가 훨씬 더 큼
    • 글을 읽어줘서 고맙고, 이 지점은 글에서 다루지 않았으며 실제로 생각하지 못했음
      준경험적으로는 이메일과 문의 양식을 5년 이상 올려둔 사이트들을 운영했지만 이런 효과를 눈치채지 못했음
      다만 정량적으로 충분히 조사한 건 아니라 확실히 말하긴 어렵고, 데이터가 있다면 분석을 보고 싶음
      안타깝게도 해당 받은편지함들은 시간이 지나면 스팸을 자동 삭제해서 기록이 남아 있지 않음
      이 데이터를 갖고 있다면 누군가 공개해주면 좋겠고, 분석 링크를 글에 기꺼이 추가하겠음
      이론적으로는 문의 양식 링크도 시간이 지나며 점점 더 많은 목록에 추가되어 같은 문제가 생기지 않을까 싶음
      양식에서도 이런 패턴을 보지는 못했으니 실제로 그렇다고 주장하는 건 아니고, 논리상 떠올린 사고실험에 가까움

  • 방금 회사용 신규 고객 문의 양식을 만들었음
    이메일 대신 양식을 쓴 이유는, 첫째 양식이 더 비인격적으로 느껴져서 거래하고 싶지 않은 잠재 고객에게 답하지 않아도 죄책감이 덜하고, 둘째 JavaScript 없이도 작동하며 JS 난독화 없이 이메일을 표시하면 스팸이 더 많이 올 것 같았기 때문임

  • EU인지 독일인지 확실하진 않지만, 온라인으로 영업하는 모든 회사가 고객 연락용으로 실제 확인하는 이메일 주소를 가져야 한다는 규정은 마음에 듦
    회사로부터 신뢰할 수 있고 지속되는 매체로 서면 답변을 받을 수 있는 거의 유일한 방법일 때가 많음
    기업 지원 채팅은 보통 끔찍하고, 전화는 분쟁이 생겼을 때 증거가 남지 않음

    • 지금은 EU 규정도 있을 수 있지만, 적어도 독일에서는 2007년에 Telemediengesetz가 도입됐고, §5 “Allgemeine Informationspflichten”가 Impressum 필요성을 담당함
      https://www.gesetze-im-internet.de/tmg/__5.html

  • noreply@에서 이메일을 보내지 말아줬으면 함
    내 이메일을 원하지 않는다면 나도 그쪽 이메일을 원하지 않음

  • 한 가지 단서는 있음. 큰 회사라면 자원이 있으니 채우기 쉬운 문의 양식을 둬야 한다고 생각하지만, 혼자 프로젝트를 만드는 개발자로서는 문의 양식으로 쓸데없는 요청을 정말 많이 받음
    스팸도 아니고, 상당수 사용자는 문의 양식을 챗봇처럼 여기며 개인적이거나 게으른 질문을 던짐
    때로는 질문도 아니고 “제품을 쓰고 싶어요” 같은 일회성 문장만 보냄
    그럼 그냥 쓰면 되는 거 아닌가
    너무 이상해서 양식을 더 숨기고 필드를 추가해 약간의 마찰을 넣게 됐음

답변달기