본문 바로가기

개발 일지

Railway에서 SMTP가 막힌다.

728x90
반응형

현재 진행 중인 사이드 프로젝트에서 railway + supabase 조합을 사용하고 있다. 이전 작업자가 구축해 둔 환경을 그대로 이어받아 사용하게 된 케이스다.

 

railway와 supabase 둘 다 처음 다뤄보는 스택이다 보니, 사용하면서 몇 가지 낯선 부분들을 마주하게 됐다. 예를 들어 postgresql의 스키마를 어떻게 애플리케이션 레벨에서 다룰지, 그리고 railway 환경에서 SMTP를 사용할 때 어떤 제약이 있는지 등을 고민하게 됐다.

 

이 글은 그 중 railway 환경에서 SMTP를 사용하려다 겪었던 문제와 그 해결 과정을 정리한 기록이다.

무엇이 문제인가.

현 사이드 프로젝트에서 사용 중인 railway는 비용이 들어가지 않는 Free Trial 인 상태다.

 

그런 상태에서 이메일 인증 코드를 전송하는 기능을 구현해야 했는데..

 

로컬에서는 잘 동작하던 SMTP로 이메일을 전송하던 코드가 railway 에만 올려놓으면 동작하지 않는 현상을 겪었다. SSL/TLS 방식과 포트를 변경해 가며 여러 차례 시도를 했지만 동작하지는 않았고 코드 상의 문제라기보다는 환경의 제약일 가능성이 높다고 판단했다.

그래서 찾아보니 railway의 Free Trial은 SMTP를 통한 외부 통신을 막는다고 한다.

 

이 사실은 Railway의 다음 문서에서 찾을 수 있었다.

https://docs.railway.com/networking/outbound-networking

Free, Trial, and Hobby plans must use transactional email services with HTTPS APIs. SMTP is disabled on these plans to prevent spam and abuse. However, even when SMTP is available, we recommend transactional email services with HTTPS APIs for all plans due to their enhanced features and analytics.

 

해석하면 다음과 같은 뜻이다.

Free, Trial, Hobby 플랜에서는 반드시 HTTPS API 기반의 트랜잭션 이메일 서비스를 사용해야 합니다.

이 플랜들에서는 스팸 및 악용 방지를 위해 SMTP가 비활성화되어 있습니다.

또한 SMTP를 사용할 수 있는 경우에도, 더 향상된 기능과 분석(analytics)을 제공하기 때문에 모든 플랜에서 HTTPS API 기반 이메일 서비스를 사용하는 것을 권장합니다.

 

Railway 문서에서는 스팸 및 악용 방지를 이유로 SMTP를 비활성화했다고 설명하고 있다. 다만, 구체적으로 어떤 방식의 abuse를 방지하기 위한 것인지는 명시되어 있지 않다.

 

해결 방법은 ?

해당 문서의 하단에는 Free 및 Hobby Plan에서의 이메일 전송 기능을 사용할 것이라면 API(HTTPS) 방식을 사용하라고 권장한다. 추천하는 API 들은 다음과 같다.

Note: These services are required for Free, Trial, and Hobby plans since outbound SMTP is disabled.
Resend - Railway's recommended approach SendGrid Mailgun Postmark

이 중 Resend라는 메일 전송 API를 사용할 수 있으려나 싶었지만 도메인이 따로 필요한 부분이었다. 진행 중인 사이드 프로젝트의 프로덕트 오너가 아직 도메인은 따로 구입하지 않았다고 한다.

 

따로 도메인 구입을 하지 않는다면 Railway를 Pro Plan으로 업그레이드하는 것도 해결법 중 하나였다. 이 방법을 택하면 한 달에 20달러 정도 비용이 발생한다.

 

현실적으로 선택지는 두 가지였다.

  1. Resend와 같은 이메일 API를 사용한다 (도메인 필요)
  2. Railway Pro Plan으로 업그레이드하여 SMTP를 사용한다

각 방법을 간단히 비교해 보면 다음과 같았다.

  • Resend 사용 시 → 비용이 저렴함, 도메인 구매 및 설정 필요 (즉시 적용 어려움)
  • Railway Pro Plan 사용 시→ 기존 SMTP 코드 그대로 사용 가능, 즉시 적용 가능, 월 비용(20$) 발생

비용적으로 보면 첫 번째 방법이 더 싸게 먹힌다. 물론 저렴한 도메인을 구입했다는 가정이 붙겠지만..

 

프로덕트 오너에게 이러한 배경을 설명하고 선택을 위임했다. 결과적으로 별도의 도메인 설정 없이 기존 SMTP 로직을 그대로 유지하면서 문제를 해결할 수 있었다.

 

마치며

로컬에서는 잘 되는데 배포 환경에서는 막히는 상황은 이전에도 몇 번 겪었던 케이스였다. 이번에도 결국 코드 문제가 아니라 환경 제약에서 오는 문제였고, 이메일처럼 외부 통신이 필요한 기능은 처음부터 인프라 조건을 같이 봐야 한다는 쪽으로 생각이 굳어졌다.

728x90
반응형