Supabase Auth 이메일은 왜 이제 제품 보안 경계가 됐나: 기본 SMTP에서 내 발신 도메인으로 넘어가는 10분 점검

• 카테고리: web_app_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 로그인 메일이 잘 도착한다는 이유만으로, 우리 제품의 인증 흐름이 운영 가능한 상태라고 말할 수 있을까?
• 핵심 출처:
  • Changes to Email Template Customisation on Free Tier - 2026-06-03 게시, 2026-06-09 확인
  • Send emails with custom SMTP - 게시일 미표기, 2026-06-09 확인
  • Email Templates - 게시일 미표기, 2026-06-09 확인
  • Passwordless email logins - 게시일 미표기, 2026-06-09 확인
  • Email authentication - Microsoft Defender for Office 365 - 게시일 미표기, 2026-06-09 확인

1. 왜 지금 봐야 하나

2026년 6월 3일 Supabase는 새 free-tier 프로젝트에서 기본 이메일 제공자를 쓰는 경우 Auth 이메일 템플릿을 더 이상 수정할 수 없다고 공지했다. 이유는 기능 축소가 아니라 남용 대응이다. 악성 사용자가 무료 프로젝트를 만들고, 확인 메일·비밀번호 재설정 메일·매직 링크 템플릿을 피싱 문구로 바꾼 뒤, Supabase의 발신 인프라를 통해 제3자에게 메일을 보내는 패턴이 늘었다는 설명이다.

이 변화는 “무료 플랜에서 브랜딩이 불편해졌다”로만 보면 작게 보인다. 웹앱 개발자에게 더 중요한 메시지는 따로 있다. 인증 이메일은 UI 문구가 아니라 계정 소유권, 비밀번호 복구, 매직 링크 로그인, 보안 알림이 지나가는 신뢰 경계라는 점이다.

작은 팀은 Supabase Auth를 붙일 때 보통 이렇게 생각한다.

1. signInWithOtp()를 호출한다.
2. 이메일이 간다.
3. 사용자가 링크를 누른다.
4. 로그인된다.

하지만 제품 운영 관점에서는 중간에 더 많은 질문이 숨어 있다.

• 누가 이 메일을 보냈다고 사용자가 믿는가?
• 링크가 프리뷰·추적·보안 게이트웨이에서 변형되면 어떻게 되는가?
• 발신 평판이 나빠져서 비밀번호 재설정 메일이 스팸으로 가면 고객 지원은 어떻게 감당하는가?
• AI 코딩 도구가 만든 템플릿에 잘못된 URL, 토큰, 과장 문구가 들어가도 검토할 장치가 있는가?

이번 글의 핵심은 Supabase 한 기능의 변경이 아니다. “백엔드 없이 빠르게 만든다”는 감각에서 “인증 채널도 내가 운영하는 제품 표면이다”라는 감각으로 넘어가는 것이다.

2. 핵심 개념

1) 기본 SMTP는 개발 편의, 커스텀 SMTP는 제품 책임이다

Supabase Auth 문서는 기본 SMTP를 시작·데모·템플릿 테스트용으로 설명하고, 프로덕션에는 커스텀 SMTP 서버를 설정하라고 권한다. 기본 SMTP에는 전달 보장 SLA가 없고, 발신량 제한이 있으며, 제한은 서비스 평판 보호를 위해 바뀔 수 있다. 기본 제공자는 “가입 흐름이 어떻게 생겼는지 확인하는 장치”에 가깝지, 사용자 수천 명의 로그인·복구 흐름을 맡길 운영 인프라가 아니다.

커스텀 SMTP를 쓴다는 것은 단순히 no-reply@myapp.com으로 보낸다는 뜻이 아니다. 다음 책임을 가져온다는 뜻이다.

• 발신 도메인과 From 주소를 정한다.
• SMTP 자격 증명을 비밀로 관리한다.
• SPF, DKIM, DMARC 같은 DNS 인증을 맞춘다.
• 발신량 제한과 남용 방어를 조정한다.
• 인증 메일이 실제 받은편지함에 도착하는지 모니터링한다.

즉 개발자가 다루는 단위가 “이메일 템플릿 HTML”에서 “인증 채널 운영”으로 커진다.

2) 이메일 템플릿은 보안 로직의 일부다

Supabase 이메일 템플릿은 확인 URL, OTP, token hash, redirect URL, 사용자 메타데이터 같은 변수를 사용한다. 이 변수들은 보기 좋은 문구를 넣기 위한 값이 아니라 인증 흐름의 동작을 바꾼다.

예를 들어 서버 사이드 렌더링 앱에서 매직 링크를 처리하려면 기본 링크가 바로 클라이언트로 세션 fragment를 넘기는 흐름과 다르게, token_hash를 받아 서버 엔드포인트에서 verifyOtp를 호출하는 패턴을 쓸 수 있다. 이때 템플릿이 잘못되면 사용자는 링크를 받아도 로그인되지 않거나, 반대로 의도하지 않은 redirect 경로로 흘러갈 수 있다.

또 외부 이메일 제공자의 링크 추적 기능이 Supabase 이메일 안의 링크를 다시 쓰면 인증 링크가 기대대로 동작하지 않을 수 있다는 문서 경고도 있다. 마케팅 이메일에서는 클릭 추적이 당연해 보여도, 인증 이메일에서는 실패 모드가 된다.

3) 이메일 발신 평판은 인증 UX의 숨은 의존성이다

Microsoft의 이메일 인증 문서는 SPF, DKIM, DMARC가 서로 다른 문제를 푼다고 설명한다. SPF는 허용된 발신 서버인지, DKIM은 메시지가 도중에 바뀌지 않았는지, DMARC는 From 도메인과 인증 결과가 맞지 않을 때 받는 쪽이 어떻게 처리할지를 정한다.

웹앱 개발자가 여기서 가져갈 원리는 간단하다. 로그인 메일은 애플리케이션 내부 이벤트처럼 보여도, 실제로는 메일 생태계의 평판과 정책 위에서 동작한다. 코드가 완벽해도 발신 도메인이 인증되지 않았거나, 새 SMTP 제공자의 rate limit을 넘거나, DMARC 정렬이 깨지면 사용자는 “로그인이 안 된다”고 느낀다.

3. 최신 이슈와 연결

Supabase의 6월 3일 변경은 이전 흐름의 연장선에 있다. Supabase는 이미 기본 SMTP가 프로덕션 용도가 아니며, 팀 멤버 주소 위주 테스트와 제한된 용도에 맞는다고 문서화해 왔다. 이번에는 무료 플랜의 기본 SMTP와 자유 템플릿 조합이 피싱 발송 통로가 될 수 있다는 현실적 비용이 드러났다.

영향 범위도 정확히 봐야 한다.

• 2026년 6월 3일부터 새 free-tier 프로젝트가 Supabase 기본 이메일 제공자를 쓰면 Auth 이메일 템플릿을 수정할 수 없다.
• 기존 free-tier 프로젝트의 기존 템플릿은 그대로 유지된다.
• Pro 이상 유료 플랜은 기존처럼 템플릿 커스터마이징이 가능하다.
• free-tier라도 커스텀 SMTP를 구성하면 템플릿 커스터마이징을 계속 할 수 있다.

여기서 중요한 실무 포인트는 “무료라서 제한됐다”가 아니다. Supabase가 비용을 사용자에게 떠넘긴 것이 아니라, 공유 발신 인프라의 평판을 보호하기 위해 위험한 조합을 줄인 것이다. 우리 앱도 같은 구조를 갖는다. 여러 사용자가 이메일 기반 초대, 매직 링크, 비밀번호 재설정을 사용할수록 인증 메일은 남용 가능한 발신 표면이 된다.

특히 AI-assisted 개발 흐름에서는 이 문제가 더 쉽게 숨어든다. AI가 “브랜드 톤에 맞게 이메일 템플릿을 만들어줘”라는 요청을 잘 처리해도, 그 결과가 인증 링크 변수, redirect allow list, 추적 링크, 보안 알림 문구, rate limit 정책과 맞는지는 별도 검토가 필요하다. 이메일은 보기 좋은 카피보다 실패 조건이 먼저다.

4. 개발자 관점 해석

레이어 1. 인증 채널을 앱 코드 밖 의존성으로 본다

Supabase Auth를 쓰면 로그인 API는 간단해진다. 하지만 인증 채널은 여전히 외부 시스템이다. SMTP 제공자, DNS 레코드, 메일 수신자 정책, 스팸 필터, 보안 게이트웨이, 링크 프리뷰 봇이 모두 관여한다.

그래서 “로컬에서 메일 한 번 받아봤다”는 검증이 부족하다. 최소한 다음 세 상황은 따로 봐야 한다.

• 신규 가입 확인 메일
• 비밀번호 재설정 메일
• 매직 링크 또는 OTP 로그인 메일

각각은 사용자 심리가 다르다. 가입 확인은 조금 기다릴 수 있지만, 비밀번호 재설정과 로그인 OTP는 지연이 곧 이탈이다. 제품에서 중요도가 다르면 rate limit, 문구, 지원 플로우도 달라져야 한다.

레이어 2. 템플릿 커스터마이징은 권한 있는 변경으로 취급한다

이메일 템플릿에는 사용자의 계정 상태를 바꾸는 링크가 들어간다. 따라서 코드 리뷰 없이 바뀌면 안 된다. 특히 다음 변경은 위험하다.

• {{ .ConfirmationURL }} 대신 직접 만든 URL을 쓰면서 token_hash 처리를 빼먹는 변경
• {{ .RedirectTo }}를 신뢰하면서 redirect allow list 검토를 하지 않는 변경
• 외부 추적 링크나 URL shortener를 넣는 변경
• 보안 알림 메일에서 “본인이 아니면 무시하세요”처럼 실제 대응을 약하게 만드는 문구
• 메일 본문에 토큰이나 전체 인증 URL을 로그·분석 도구로 흘리는 코드

좋은 규칙은 “인증 이메일 템플릿 변경은 UI 카피 변경이 아니라 auth 설정 변경”으로 취급하는 것이다.

레이어 3. 커스텀 SMTP는 켠 뒤가 시작이다

커스텀 SMTP를 켜면 모든 주소로 보낼 수 있고, 브랜딩도 가능해진다. 하지만 Supabase 문서처럼 새 발신 서비스의 평판 보호를 위해 기본 낮은 rate limit이 걸릴 수 있다. 이 제한을 무작정 높이면 공격자가 가입·OTP·재설정 플로우를 발신 폭탄으로 바꿀 수 있다.

따라서 운영 순서는 보통 이렇게 가야 한다.

1. 개발·스테이징에서는 기본 SMTP 또는 낮은 한도의 커스텀 SMTP로 흐름을 검증한다.
2. 프로덕션 전에는 전용 발신 도메인, SPF, DKIM, DMARC를 맞춘다.
3. 가입·OTP·재설정 요청에 CAPTCHA, IP 기반 제한, 사용자 단위 쿨다운을 둔다.
4. 정상 트래픽을 보며 rate limit을 올린다.
5. 메일 미도착·스팸 분류·링크 실패를 고객 지원 이슈로만 보지 말고 지표로 본다.

5. 내 프로젝트에 적용할 체크포인트

오늘 Supabase Auth를 쓰는 프로젝트라면 아래 질문에 답해보자.

• 프로덕션 프로젝트가 Supabase 기본 SMTP에 의존하고 있지 않은가?
• 새 free-tier 프로젝트에서 Auth 이메일 템플릿 수정이 필요한 경우, 커스텀 SMTP 또는 유료 플랜 필요성을 알고 있는가?
• no-reply@... 발신 도메인의 SPF, DKIM, DMARC 설정을 누가 소유하는가?
• 이메일 제공자의 링크 추적 기능이 인증 링크를 다시 쓰지 않도록 꺼져 있는가?
• 매직 링크, OTP, 비밀번호 재설정의 만료 시간과 재요청 rate limit을 제품 위험도에 맞게 조정했는가?
• redirect URL allow list가 운영 도메인, 프리뷰 도메인, 모바일 deep link를 과하게 열어두지 않았는가?
• 이메일 템플릿 변경이 코드 리뷰 또는 설정 변경 리뷰를 거치는가?
• 비밀번호 재설정 메일 미도착을 감지할 수 있는 지원·로그·모니터링 루프가 있는가?
• 가입 봇이 이메일 발송량을 소진시키는 경우를 막기 위해 CAPTCHA나 별도 제한을 두었는가?

6. 오늘 10분 액션

10분만 투자해서 “우리 인증 이메일이 제품 운영 기준에 맞는가”를 확인해보자.

1. Supabase Dashboard에서 현재 프로젝트의 Authentication > SMTP settings를 연다.
2. 기본 SMTP를 쓰는지, 커스텀 SMTP를 쓰는지 기록한다.
3. 커스텀 SMTP라면 발신 도메인과 From 주소를 적는다.
4. DNS 관리 화면에서 SPF, DKIM, DMARC 레코드가 있는지 확인한다. 값의 완벽한 해석까지 못 해도 “누가 관리하는지”를 적는다.
5. Email Templates 화면에서 confirmation, recovery, magic link 템플릿을 열고 ConfirmationURL, Token, TokenHash, RedirectTo 중 무엇을 쓰는지 표시한다.
6. 이메일 제공자에서 click tracking이 켜져 있는지 확인하고, 인증 이메일에는 끄는 것을 이슈로 등록한다.
7. 마지막으로 README나 docs/auth-email.md에 다음 한 줄을 남긴다.

Auth emails are production auth infrastructure: SMTP provider, DNS authentication, redirect allowlist, rate limits, and templates must be reviewed together.

이 액션의 목적은 완벽한 메일 보안 설정이 아니다. 인증 이메일을 “누군가 나중에 보겠지”가 아니라 팀이 소유한 운영 표면으로 이름 붙이는 것이다.

7. 더 볼 자료

• Supabase: Changes to Email Template Customisation on Free Tier: 2026년 6월 변경의 직접 배경과 영향 범위를 확인한다.
• Supabase Auth: Send emails with custom SMTP: 기본 SMTP의 제한, 커스텀 SMTP 설정, 남용 방어, 발신 평판 관리 포인트를 본다.
• Supabase Auth: Email Templates: 템플릿 변수, 서버 사이드 인증 링크 처리, 이메일 추적 기능 주의점을 확인한다.
• Supabase Auth: Passwordless email logins: 매직 링크와 OTP가 같은 API 흐름에서 어떻게 갈라지는지, 만료와 rate limit을 확인한다.
• Microsoft: Email authentication: SPF, DKIM, DMARC가 각각 어떤 문제를 푸는지 운영 관점에서 정리한다.

중복 회피 메모

로컬 content/generated와 Supabase의 최근 web_app_dev 글을 확인했다. 최근 웹앱 글은 Next.js 16.2의 AI 디버깅 인터페이스, Expo 제품 운영 전환, Android 배포 신원 검증, Next.js 인증 경계, Supabase의 신규 테이블 GRANT/RLS 기본값을 다뤘다. 이번 글은 Supabase를 다시 언급하지만, 이전 Supabase 글의 데이터 API 노출·RLS·Postgres 업그레이드가 아니라 Auth 이메일 발신 인프라, 템플릿 권한, SMTP 평판, SPF/DKIM/DMARC라는 인증 채널 운영 경계에 집중해 관점을 분리했다.