# 유럽 주요 결제처리업체, Google Workspace 사용자에게 이메일 전송 불가 > Clean Markdown view of GeekNews topic #26652. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26652](https://news.hada.io/topic?id=26652) - GeekNews Markdown: [https://news.hada.io/topic/26652.md](https://news.hada.io/topic/26652.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-13T12:33:23+09:00 - Updated: 2026-02-13T12:33:23+09:00 - Original source: [atha.io](https://atha.io/blog/2026-02-12-viva) - Points: 1 - Comments: 1 ## Topic Body - 유럽 대형 결제업체 **Viva.com**이 `Message-ID` 헤더 없이 인증 메일을 발송해 **Google Workspace 서버가 이를 거부**함 - RFC 5322(2008년 제정)에서 `Message-ID`는 필수 수준의 헤더로 규정되어 있으며, Google은 이를 엄격히 적용 - Gmail 개인 주소로는 메일이 수신되어, **Google Workspace와 Gmail의 처리 차이**가 드러남 - Viva.com 고객지원은 기술적 문제를 인정하지 않고, 사용자가 우회한 결과만 확인하는 **비전문적 대응**을 보임 - 기본 RFC 준수조차 지키지 못한 사례로, **유럽 핀테크 인프라의 품질과 경쟁력 저하 문제**를 드러냄 --- ### 인증 메일이 도착하지 않은 문제 - Viva.com 계정 생성 과정에서 인증 메일이 전혀 도착하지 않음 - Google Workspace 기반의 커스텀 도메인 이메일을 사용했으며, 스팸함에도 메일이 없었음 - Google Workspace의 **Email Log Search** 결과, 상태는 “Bounced”로 표시됨 - 반송 사유는 “Messages missing a valid Message-ID header are not accepted” - Google은 RFC 5322 규격 위반으로 메일을 거부함 - Viva.com의 발신 메일에는 `Message-ID` 헤더가 누락되어 있었으며, 이는 2008년부터 필수로 요구된 항목임 ### 임시 해결책 - 개인용 **@gmail.com** 주소로 변경하자 인증 메일이 정상적으로 수신됨 - Gmail의 수신 인프라가 더 관대하거나 다른 경로로 처리된 것으로 보임 - 그러나 **비즈니스용 결제 플랫폼** 가입에 개인 이메일을 사용해야 했다는 점은 문제로 지적됨 ### 고객지원의 대응 - Viva.com 고객지원에 Google Workspace 로그 스크린샷과 문제 설명을 전달함 - 지원팀은 “귀하의 계정은 이미 인증된 이메일을 가지고 있으므로 문제가 없다”고 회신 - 기술적 문제에 대한 인식이나 엔지니어링 팀 전달은 없었음 - 사용자가 직접 우회한 결과를 문제 없음으로 간주한 대응임 ### 문제의 본질 - `Message-ID`는 모든 이메일 시스템이 기본적으로 생성하는 **기본 헤더**임 - 이를 누락하려면 메일 파이프라인이 심각하게 잘못 구성된 상태여야 함 - RFC 5322에서는 `Message-ID`를 “SHOULD”로 규정하지만, Google은 이를 **사실상 필수(MUST)** 로 취급 - Viva.com이 이를 준수하지 않음으로써 Google Workspace 사용자에게 메일이 도달하지 않음 - 유럽 전역에서 결제를 처리하는 기업이 기본 RFC 규격을 지키지 못한 점은 **기술 신뢰성에 의문**을 제기함 ### 유럽 핀테크 인프라의 구조적 문제 - 유럽의 기업용 API·서비스에서 **문서 불완전, 오류 처리 미흡, 비전문적 지원**이 반복적으로 발생 - 이는 엔지니어 역량 문제가 아니라 **시장 경쟁 부족과 우선순위 문제**로 지적됨 - Stripe가 높은 개발자 경험 기준을 세웠지만, **유럽 지역 결제망(예: IRIS)** 을 완전히 지원하지 않아 대체재가 부족함 - Stripe 수준의 경쟁자가 등장하지 않는 한, 이 같은 품질 문제는 계속될 가능성이 있음 ### 기술적 수정 제안 - Viva.com은 발신 메일에 `Message-ID` 헤더를 추가해야 함 - 예시: `Message-ID: ` - 대부분의 이메일 라이브러리는 이를 자동 생성하며, **한 줄 수정으로 해결 가능** - Google Workspace 사용자들이 정상적으로 인증 메일을 받을 수 있도록 즉각적인 수정 필요 ### RFC 용어 구분과 Google의 정책 - RFC 2119에 따르면 - **MUST**: 절대적 요구사항 - **SHOULD**: 특별한 이유가 있을 때만 생략 가능 - **MAY**: 완전한 선택사항 - `Message-ID`가 SHOULD인 이유는 일부 클라이언트가 서버에 위임하기 때문 - Google은 스팸 방지를 위해 이를 **강제적 요건으로 적용**, RFC보다 실질적 표준 역할을 수행 - Viva.com이 이를 의도적으로 생략했다면, 최소한 “Google Workspace와 호환되지 않음” 경고를 제공해야 함 - 아무런 안내 없이 운영하는 것은 SHOULD 규정의 취지에도 어긋남 ## Comments ### Comment 51107 - Author: neo - Created: 2026-02-13T12:33:23+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46989217) - Viva.com의 인증 이메일에 **Message-ID 헤더**가 없다는 점이 문제로 지적됨 RFC 5322의 [섹션 3.6](https://www.rfc-editor.org/rfc/rfc5322.html)에 따르면 “every message SHOULD have a Message-ID field”라고 되어 있는데, SHOULD는 MUST가 아니므로 ‘요구사항’이라 보기 어렵지 않느냐는 의문을 제기함 - SHOULD는 사실상 **의무적 요구사항**임을 설명함 특별한 사유가 없는 한 따라야 하며, 단순히 “귀찮아서”는 예외가 될 수 없다고 함 과거에는 MUA가 Message-ID 없이 메일을 보내면 서버가 자동으로 추가했기 때문에 SHOULD로 표현되었다고 함 관련 내용은 [RFC 6409 섹션 8.3](https://www.rfc-editor.org/rfc/rfc6409.html#section-8.3)에 명시되어 있음 - RFC2119에 따르면 SHOULD는 “특정 상황에서 무시할 수 있으나, 그 결과를 충분히 이해하고 신중히 판단해야 함”을 의미함 Google이 이를 어떻게 해석했는지는 모르겠다고 함 - 호스팅 회사의 **postmaster**로서, 실제 운영 환경에서는 Message-ID가 반드시 필요하다고 강조함 테스트 메일은 몰라도, 실서비스 메일에 없으면 스팸 필터링 등에서 문제가 생김 Message-ID가 없다는 건 보통 **허술한 커스텀 발송 시스템**의 신호라고 함 - Message-ID는 필수가 아니지만, Amazon SES처럼 기존 Message-ID를 덮어쓰는 서비스도 있어 불만이라고 함 - 기술적으로는 없어도 되지만, **정상적인 이메일로 분류되려면 사실상 필수**라고 봄 특히 결제 서비스가 Google Workspace 같은 주요 메일 서비스에서 테스트조차 안 한 건 황당하다고 함 - ESP(Email Service Provider)에서 일했던 경험으로, 대부분의 서버 소프트웨어는 Message-ID 없는 메일을 거부했다고 함 Google 같은 주요 수신자에게서 오는 **반송(bounce)** 을 무시하는 건 상상하기 어렵다고 함 - 현실적으로는 표준보다 **사용자 문제를 막는 게 더 중요**하다고 함 상대 시스템이 비합리적이라도, 사용자 불편을 막기 위해 맞춰주는 게 낫다고 함 - Google Workspace로 메일을 보내려면 Message-ID는 사실상 **MUST**임 이를 넣기 싫다면 “Google Workspace 사용자에게는 서비스 불가”라고 명시해야 한다고 주장함 - 하지만 대부분의 기업은 이런 기술적 세부사항에 관심이 없고, **“빨리 서비스만 되면 된다”** 는 태도라고 함 Viva나 Google 모두 너무 커서 일부 고객의 문제는 신경 쓰지 않는다고 봄 - 유럽 기업 중심이라 Google Workspace 비중이 크지 않을 수도 있다고 지적함 - 이메일의 **text/plain 대체 파트**를 엉망으로 보내는 서비스들에 대한 불만도 나옴 링크가 빠진 텍스트 버전이나 “이건 plain text 이메일입니다” 같은 쓸모없는 내용만 보내는 경우가 있다고 함 - 알림창에 “귀여운 문구”만 뜨는 plain text 버전이 가장 짜증난다고 함 이메일 클라이언트가 AI로 HTML을 요약해주는 기능이 필요하다는 농담도 함 - 어떤 서비스는 다른 고객의 예약 정보를 plain text에 포함시켜 보냈다고 함 (Avis 사례) - HTML을 Lynx 브라우저로 덤프해 text/plain을 만드는 구현을 본 적 있는데, 그게 실제로 가치가 있는지 궁금하다고 함 - text/plain에 HTML 소스나 CSS를 그대로 넣는 경우도 봤다고 함 - 금융기관의 **기술적 무능함**을 꼬집는 댓글도 있었음 “Major European Payment Processor”는 사실상 “Major European Incompetence Center”라고 표현함 - 다른 사용자는 과장된 말 같지만, 실제로 금융기관의 보안 수준이 끔찍했다고 함 예를 들어 Harland Financial Systems는 **2바이트 XOR 암호화**를 쓰고, 키를 연결 초반에 평문으로 보냈다고 함 - 또 다른 사용자는 미국 금융기관의 **부패 사례**(잘못된 승인, 무단 계좌 개설 등)를 언급하며 유럽도 비슷한지 묻는 의견을 남김 - Gmail에서 Fastmail로 옮긴 사용자가 Google의 **엄격한 스팸 필터링**에 일정 부분 공감함 Fastmail에서는 스팸과 피싱 메일이 더 많이 들어온다고 함 - 다른 사용자는 Message-ID는 자동 메일에 **사실상 업계 표준**이라며 Google의 조치가 과하지 않다고 함 스타트업이 기본 템플릿을 그대로 써서 피싱으로 오인받는 사례도 있다고 함 - Fastmail은 시간이 지나면 스팸 필터가 학습되어 좋아진다고 조언함 - 오랜 Fastmail 사용자로서, 가끔 스팸이 새지만 **LinkedIn 메일만 유일하게 통과**한다고 농담함 - Fastmail은 주기적으로 스팸 대응이 느려질 때가 있지만, 전반적으로 만족스럽다고 함 - RFC 상으로는 Viva.com이 틀렸지만, Google도 **SHOULD 항목을 이유로 메일을 거부하는 건 부적절**하다고 보는 의견도 있음 다만 스팸 가능성이 높다면 스팸함으로 보내야지, 거부는 과하다고 함 - 고객지원팀이 문제를 기술팀에 전달하지 않고 **형식적인 답변만 반복**하는 현실을 지적함 - 지원 담당자 입장에서는 문제를 인정하면 **성과 평가에 불이익**이 있어 어쩔 수 없었다는 내부 경험담도 공유됨 - 이메일 표준은 현실적으로 완벽히 작동하지 않으며, **모든 규칙이 사실상 “SHOULD” 수준**이라는 냉소적 의견도 나옴 - Viva.com이 Google Workspace와의 메일 송신 문제를 **테스트조차 안 한 점**이 가장 심각하다고 지적됨 - 실제로는 사용자 가입 실패를 통해 “실시간 테스트” 중인 셈이라며 풍자함 문제는 Google 쪽 변경일 수도 있지만, **모니터링 부재**가 더 큰 문제라고 함 - “세상 모든 기업이 Google Workspace를 쓰는 건 아니지 않느냐”는 반론도 있었음 - Viva.com이 이런 문제를 **얼마나 오래 인지하지 못했는지** 의문을 제기함 일반적인 메일 소프트웨어라면 이런 문제는 생기지 않았을 것이라며, misconfiguration 가능성을 언급함 SHOULD는 MAY가 아니며, 구현하지 않으면 문제를 감수해야 한다고 함 Google이 에러 메시지로 원인을 알려준 건 오히려 다행이라고 평가함 - Message-ID는 원래 **Usenet에서 유래된 필수 필드**로, 이메일의 **스레딩, 회신, 아카이빙**에 모두 필요하다고 설명함 Message-ID가 없다는 건 “답장도 원치 않고 기록도 남기고 싶지 않다”는 의미로, **수상한 행위**로 보인다고 함 - 유럽 기업 API의 품질 문제를 지적한 원문에 대해, 이런 현상은 지역 문제가 아니라 **전 세계 스타트업과 금융기관 공통의 패턴**이라고 함 대기업은 API를 부가 사업으로 여기거나, **규제 대응용으로 억지로 운영**하는 경우가 많다고 함 반면 Stripe 같은 회사는 API가 생명줄이기 때문에 품질이 높다고 함 스타트업은 리소스 부족으로 **“사용하기 좋은 API”보다 “돌아가는 API”** 를 우선시할 수밖에 없다고 덧붙임