535 5.7.8 인증 실패 (앱 비밀번호)

문제

수년간 조용히 메일을 보내던 스크립트·프린터·CRM·백업 작업이 갑자기 로그인을 못 합니다: 535-5.7.8 Username and Password not accepted. 비밀번호를 확인합니다. 맞습니다. 조심스럽게 다시 붙여넣습니다. 여전히 거부. 당신 자격증명은 아무것도 안 바뀌었는데 — 무엇이 허용되는 자격증명인지에 대한 규칙이 바뀌었고, 그걸 알리는 이메일은 거의 아무도 안 보냅니다. 보내는 비밀번호는 아마 맞지만 더 이상 허용되지 않는 것, 이건 오타와는 미치도록 다른 문제입니다.

증상

• SMTP 서버가 535 5.7.8 Username and Password not accepted(Gmail 전체 형태는 https://support.google.com/mail/?p=BadCredentials를 가리킴)나, 사촌인 534 5.7.9 Application-specific password required를 반환합니다.
• 똑같은 사용자 이름과 비밀번호가 브라우저 웹메일 UI 로그인에선 되는데 SMTP/IMAP에선 실패합니다.
• 서서히가 아니라 어느 날짜에 딱 끊겼습니다 — 흔히 제공사 마감 직후나, 누가 계정에 2단계 인증을 켠 직후.
• 자동 발신자(cron 작업, 네트워크 스캐너, 복합기, 레거시 앱)는 실패하는데 최신 메일 클라이언트를 쓰는 사람들은 멀쩡합니다.

이 에러가 실제로 뜻하는 것

확장 상태 코드가 단서입니다. RFC 3463에 따르면 5.7.8은 영구(5), 보안 또는 정책(7), *인증 자격증명 무효(8)*로 해독됩니다. SMTP AUTH 확장인 RFC 4954는 명시합니다: 535 5.7.8 응답은 자격증명이 무효이거나 불충분해 인증이 실패한 것이며, 클라이언트는 사용자에게 새 자격증명을 요청해야 합니다. 스팸 판정도, 블록리스트도, 꽉 찬 메일함도, DNS 문제도 아닙니다. 서버는 당신 로그인 시도를 이해했고 거부한 것입니다.

2026년이 다른 점은 이제 “무효”에 기술적으로 맞는 자격증명도 포함된다는 것입니다. 제공사들은 서드파티 앱의 비밀번호 전용 인증을 수년에 걸쳐 죽였습니다. Google은 개인 Gmail의 ‘less secure apps’ 토글을 2022년 5월 30일에 없앴고, Workspace의 비밀번호 전용 접근과 Google Sync를 2024년 9월 30일에 종료했으며, 모든 Workspace 계정에서의 차단을 2025년에 걸쳐 완료했습니다. 각 날짜 뒤로, 전날 되던 그 비밀번호가 535 5.7.8을 내기 시작했습니다 — 비밀번호가 맞고 틀리고와 무관하게, 연결 방식(SMTP AUTH 위의 평문 비밀번호)이 허용되는 방식이기를 멈췄기 때문입니다.

가장 흔한 원인 3가지

1. 앱 비밀번호가 필요한 곳에 계정 비밀번호를 보냄. 압도적으로 흔한 경우. 계정에 2단계 인증이 켜져 있거나(또는 제공사가 비밀번호 전용 인증을 아예 폐기했거나) 해서 일반 비밀번호가 거부됩니다. 해법은 16자리 앱 비밀번호: 한 번 생성해 SMTP 비밀번호로 붙여넣는 앱별 자격증명입니다. Gmail에선 먼저 2단계 인증이 켜져 있어야 합니다 — 그것 없이는 앱 비밀번호가 없습니다. 서버가 구체적일 수 있으면 534 5.7.9 Application-specific password required로 말해줍니다.
2. 2단계 인증이 아예 설정 안 됨 — 그래서 앱 비밀번호를 못 만드는데 비밀번호 전용 로그인은 이미 막혀 있음. 답답한 막다른 길입니다: 계정이 당신 비밀번호를 거부할 만큼은 최신 보안 체제에 있지만, 대체재를 발급할 만큼은 설정돼 있지 않은 것. 계정에 2단계 인증을 먼저 켜고 그다음 앱 비밀번호를 생성해야 합니다.
3. 자격증명은 멀쩡한데 로그인의 다른 뭔가가 틀림. 틀린 사용자 이름(서버가 user가 아니라 전체 [email protected]을 원함), 틀린 SMTP 호스트나 포트, 서버가 광고하지 않는 인증 방식, 또는 잠기거나 정지되거나 의심 활동으로 표시된 계정. 여기서 5.7.8은 엄밀히는 진실을 말합니다 — 인증이 성공 안 했으니까 — 하지만 실제로 보내는 것을 고치기 전엔 어떤 앱 비밀번호도 이걸 못 고칩니다.

DechoNet으로 진단

• 이메일 점검은 당신 SMTP 비밀번호를 시험할 수 없습니다 — 제공사 밖의 누구도 못 합니다 — 하지만 그다음으로 유용한 일을 합니다: 바깥에서, 도메인이 해석되고 메일 레코드(MX·SPF·DKIM·DMARC)가 존재하고 온전한지 확인합니다. 이게 중요한 이유는 535 5.7.8을 실제로 DNS 문제인 배달 실패와 헷갈리기 쉽기 때문입니다. 이메일 점검이 메일 도메인이 건강하다고 보이면, DNS 계열 원인 전체를 배제하고 싸움이 에러가 말하는 그곳 — 클라이언트 측 인증 — 에 있음을 확인한 것이니, DNS를 쫓는 대신 자격증명을 고치면 됩니다.

해결 체크리스트

• 발신 계정의 앱 비밀번호를 생성해 SMTP 비밀번호로 공백 없이 그대로 쓰세요. Gmail/Workspace에서 이건 535 5.7.8 대다수와 모든 534 5.7.9의 해법입니다.
• 어디서 만드는지 못 찾으면 계정에 2단계 인증을 먼저 켜세요 — 앱 비밀번호는 그것 없이 존재하지 않습니다.
• 클라이언트가 지원하면 OAuth 2.0(XOAUTH2)을 우선하세요. 최신 메일 클라이언트는 저장된 비밀번호 대신 “Google로 로그인”으로 계정을 다시 추가하게 해줍니다; 제공사가 실제로 원하는 경로이고 미래의 비밀번호 인증 차단에도 살아남습니다.
• 사용자 이름 형식을 확인하세요 — 대부분 서버는 사서함 이름이 아니라 전체 이메일 주소를 기대합니다.
• 호스트·포트·암호화를 확인하세요: Gmail은 smtp.gmail.com의 587(STARTTLS)이나 465(SSL). 틀린 포트나 빠진 TLS 모드가 인증 실패로 나타날 수 있습니다.
• 올바른 앱 비밀번호로도 계속 실패하면 계정 보안 페이지에서 계정 잠금이나 보안 경고를 확인하세요 — 표시된 계정은 유효한 자격증명도 거부합니다.

에스컬레이션 시점

• 앱 비밀번호를 설정하고 사용자 이름과 호스트를 확인했는데도 여전히 535 5.7.8이면, 계정 웹 UI에 로그인해 보안 프롬프트나 차단된 로그인 알림을 찾으세요; 계정 자체에 사람이 풀어야 할 표시가 걸렸을 수 있습니다.
• Microsoft 365 / Exchange Online은 기본 SMTP AUTH가 기본으로 꺼져 있고 Microsoft가 OAuth로 전환하며 폐기 중입니다 — 거기서 535는 대개 테넌트나 사서함에 SMTP AUTH가 꺼진 것이고, 클라이언트에서 고칠 비밀번호가 아니라 관리자 설정입니다.
• 여러 시스템이 인증하는 공유·역할 사서함이라면, 갑작스러운 535를 자격증명 교체나 제공사 측 정책 변경 가능성으로 보고, 루프로 재시도하기 전에 도메인 메일을 관리하는 담당자와 확인하세요 — 반복된 로그인 실패가 잠금을 유발해 상황을 더 악화시킬 수 있습니다.