🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

내 고객에게 자동으로 메일 보내는 시스템은 단순한 발송 앱이 아니라 구독자 관리, 편집기, 발송 파이프라인, 도메인 신뢰도, 비용 구조까지 함께 설계해야 하는 작은 뉴스레터 SaaS다.

📌 핵심 요점

1. 뉴스레터 발송 시스템의 최소 범위는 이메일 수집, 구독자 관리, 뉴스레터 작성·미리보기·테스트 발송, 즉시·예약 발송, 관리자 대시보드로 정리된다.
2. 대량 이메일 발송에서는 Gmail API나 직접 SMTP 서버보다 리샌드, Amazon SES 같은 전문 발송 인프라가 현실적인 선택지로 다뤄진다.
3. 초기 AI 기획안은 리샌드와 SES를 함께 쓰는 구조처럼 비용과 복잡도를 키울 수 있어, 실제 운영 규모와 비용 기준으로 재검토가 필요하다.
4. 영상의 최종 방향은 개인이 운영 가능한 작은 SaaS에 맞춰 Amazon SES, Next.js, SQLite를 중심으로 구성하고 S3, CloudFront, 리샌드 등은 제외하는 것이다.
5. 실제 발송 테스트에서는 기능 자체는 작동했지만, SES 도메인 검증 보류와 샌드박스 제한 때문에 스팸함 도착이나 수신 실패 같은 운영 리스크가 확인됐다.

🧩 배경과 문제 정의

• 고객에게 자동으로 뉴스레터 이메일을 보내는 작은 SaaS를 만들기 위해 구독자 수집, 편집기, 발송 파이프라인, 관리자 기능의 최소 범위를 정리한다.
• 대량 이메일 발송에서는 단순 발송 기능보다 도메인 신뢰도, 스팸 차단, 반송·수신거부 처리, 발송 비용이 더 큰 리스크가 된다.
• AI가 제안한 기획안을 그대로 따르면 리샌드와 Amazon SES를 동시에 사용하는 등 구조와 비용이 불필요하게 커질 수 있어 재검토가 필요하다.
• 최종 방향은 개인이 운영 가능한 작은 SaaS에 맞춰 Amazon SES, Next.js, SQLite를 중심으로 기능을 줄이고 PRD를 명확히 정리하는 것이다.

🕒 시간순 섹션별 상세정리

1. 뉴스레터 발송기 아이디어를 독립적으로 좁히기

• 먼저 간단한 아이디어를 제시한 뒤, 챗GPT로 뉴스레터 발송기 서비스의 초기 기획을 구체화한다 [01:55]
• 챗GPT 메모리가 이전 대화 맥락을 끌어올 수 있으므로, 임시 채팅에서 뉴스레터 발송기 아이디어만 기준으로 논의를 진행한다 [02:25]

2. 구독자 입력과 이메일 발송 인프라 정하기

• 사용자의 이메일 주소를 입력하고 수집하는 기능을 서비스의 출발점으로 설정한다 [03:21]
• 이메일 발송에는 리샌드나 Amazon SES 같은 외부 이메일 발송 서비스 연동이 필요하다고 판단한다 [03:39]

3. 편집기·대시보드와 발송 기능 범위 확장

• 뉴스레터 편집기에는 텍스트, 속성, 이미지, 유튜브, 링크, 사운드 삽입 기능이 필요하다고 정리한다 [05:26]
• 디자인이 반영된 이메일을 보내기 위해 HTML 포맷 전송을 기본 방향으로 잡는다 [05:41]

4. AI 기획안 재검증과 SES 중심 선택

• 챗GPT의 기획안을 그대로 따르면 리샌드와 SES를 함께 쓰는 중복 구조가 될 수 있음을 확인한다 [07:06]
• 스스로 반박할 지식이 부족할수록 다른 AI나 직접 검토를 통해 기획안을 다시 검증해야 한다고 본다 [07:21]

5. 구독자 수집, HTML 렌더링, 발송 파이프라인 정리

• 이메일 주소 수집 방식은 직접 입력, 구독 페이지 입력, CSV 명단 가져오기로 구분한다 [08:53]
• 에디터는 텍스트 기반 입력을 유지하되, 발송 단계에서는 HTML로 렌더링해야 한다고 정리한다 [09:07]

6. 작은 SaaS에 맞춘 최종 기술 스택 결정

• AI가 제안한 기술 스택에는 Next.js, Postgres, React 이메일 에디터, S3, CloudFront가 포함된다 [09:56]
• 작은 개인 SaaS 규모에서는 S3와 CloudFront까지 도입하는 것은 과하다고 판단한다 [10:11]

7. 뉴스레터 SaaS 요구사항과 발송 흐름 정리

• 발송 전에는 콘텐츠 작성, 미리보기 확인, 테스트 메일 발송 단계를 거친다 [12:01]
• 테스트 메일 수신이 확인되면 즉시 발송 또는 예약 발송으로 계속된다 [12:16]

8. PRD 기반 프로젝트 생성과 클라우드 데스크톱 작업 시작

• 수정·삭제를 마친 PRD를 클립보드에 복사해 개발 입력값으로 준비한다 [13:03]
• 클라우드 데스크톱에서 새 프로젝트 폴더를 만들고 프로젝트명을 “바이브 랩스 뉴스레터”로 지정한다 [13:18]

9. 초기 기술 선택과 개발 범위 확정

• DB 접근 방식은 프리즈마와 드리즈를 비교한 뒤 추천안인 드리즈로 결정한다 [14:45]
• 뉴스레터 에디터는 티테 블록 에디터와 경량 커스텀 블록 에디터 중 추천안을 선택한다 [15:02]

10. Amazon SES 접근과 비용 구조 확인

• 구글 검색 결과에서 “Amazon Simple Email Service” 링크를 열어 SES 페이지로 이동한다 [16:56]
• AWS 프로필 로그인과 이메일 입력을 거쳐 콘솔 진입 절차를 진행한다 [17:11]

11. AWS 가입과 결제 인증 절차

• 무료 플랜을 선택한 뒤 AWS 가입 절차를 시작한다 [19:46]
• 청구 국가, 카드 번호, 만료일, 보안 코드, 카드 이름, 주소, 결제 연락처 이메일을 입력해 결제 인증을 진행한다 [20:01]

12. 이메일·도메인 인증과 SMTP 자격증명 생성

• SES API 설정을 위해 이메일 주소와 도메인 인증을 1단계 작업으로 정리한다 [21:02]
• 클라우드 인 크롬이 화면을 제어하며 인증에 필요한 이메일 주소와 도메인 정보를 요청한다 [21:17]

13. AWS SES SMTP 정보 확보와 가비아 CNAME 등록

• SES SMTP 설정에서 호스트, 포트, 유저네임, 패스워드를 핵심 정보로 기록한다 [24:07]
• 도메인 인증에 필요한 CNAME 레코드 3개를 별도로 기록한다 [24:22]

14. SMTP 자격증명 정리와 Next.js 발송 방식 조정

• SES 설정 핵심은 이메일 계정 확인, 도메인 DNS 전파 대기, 가비아 CNAME 3개 등록으로 압축된다 [26:00]
• SMTP 연결에는 호스트, 587 포트, 유저네임, 패스워드가 필요하다 [26:16]

15. Nodemailer 기반 SES SMTP 적용과 1차 테스트 발송

• Nodemailer로 SES SMTP 발송 경로를 추가하고, 필요한 ENV 자격증명을 등록한다 [28:08]
• 발송 경로가 자동 선택되도록 조정한 뒤 프로덕션 빌드 통과까지 확인한다 [28:23]

16. Cloudflare DNS 확인과 SES 도메인 검증 보류

• DNS 확인처럼 웹 접속이 필요한 작업은 클라우드 데스크톱보다 클라우드의 크롬 환경에 맡기는 편이 적절하다고 판단한다 [31:02]
• 맥락이 없는 환경에서도 바로 실행할 수 있도록 독립적인 작업서를 만들어야 한다 [31:17]

17. DNS 전파 지연 속 뉴스레터 앱 실행과 테스트 캠페인 발송

• Cloudflare DNS 설정은 정상으로 보이지만 SES 도메인 검증은 아직 완료되지 않고 보류 상태다 [32:39]
• 가비아 DNS 변경은 반영까지 짧게 24시간, 길게 48시간까지 걸릴 수 있다 [32:54]

18. 구독자 추가 후 실제 발송 지연과 디버깅 진입

• 캠페인 화면에는 예약 발송 기능도 있으며, 구독자가 없으면 실제 발송 대상이 없어 메일이 나가지 않는다 [34:46]
• 구독자를 추가한 뒤 기존 캠페인을 다시 열어 발송 대상이 1명으로 바뀐 것을 확인한다 [35:02]

19. 발송 실패 원인 확인과 이메일 공급자 선택의 제약

• 캠페인은 발송 처리됐지만 수신자 1명은 실패 상태로 표시된다 [36:24]
• 이메일 주소 자체는 정상으로 보이므로 실패 원인은 별도로 확인해야 한다 [36:39]

20. SES 설정 난도와 도메인 신뢰도, 비용 구조

• Amazon SES는 도메인 이동, Cloudflare 접속, SES 설정이 모두 얽혀 있어 개발자에게도 까다로운 작업이다 [37:47]
• 자동화 도구의 도움을 받더라도 SES 설정 자체의 난도는 여전히 높다는 점을 확인하며 마무리한다 [38:02]

🧾 결론

• 이 영상의 핵심은 “AI로 앱을 만들었다”보다 “메일 발송 SaaS를 실제 운영 가능한 수준으로 좁히는 과정”에 가깝다.
• 뉴스레터 시스템은 화면과 에디터보다 도메인 인증, DKIM, DNS 전파, SMTP 자격증명, SES 샌드박스 같은 보이지 않는 설정이 더 큰 난관으로 등장한다.
• Amazon SES는 영상 내 비교 기준에서 1,000통당 약 0.1달러 수준으로 비용 경쟁력이 크지만, 설정 난도와 이메일 신뢰도 관리는 사용자가 직접 감당해야 한다.
• 작은 SaaS를 만들 때는 처음부터 모든 기능을 넣기보다 리샌드 연동, 다중 조직, 자동화 시나리오, AB 테스트, 템플릿 마켓 같은 범위를 제외하는 판단이 중요하다.
• 검증 필요: SES 도메인 검증 완료 여부, Cloudflare·가비아 DNS 전파 상태, SES 샌드박스 해제 여부, 실제 대량 발송 시 스팸함 비율과 반송·수신거부 처리 안정성은 영상 시점에서 추가 확인이 필요한 영역이다.

📈 투자·시사 포인트

• 뉴스레터 SaaS의 비용 구조는 발송량이 늘어날수록 중요해지며, 구독형 발송 서비스와 SES 같은 종량제 인프라의 차이가 수익성에 직접 영향을 줄 수 있다.
• 개인 또는 소규모 팀이 만드는 SaaS에서는 저렴한 인프라보다 “설정과 운영을 감당할 수 있는가”가 실제 성공 가능성을 좌우한다.
• 이메일 발송 제품은 단순 기능 구현만으로는 충분하지 않고, 도메인 평판, 스팸 방지, 수신거부, 반송 처리 같은 운영 품질이 핵심 경쟁력이 된다.
• AI 기획 도구는 PRD 작성과 개발 출발점을 빠르게 만들 수 있지만, 비용·아키텍처·운영 리스크에 대한 사람의 재검토가 없으면 과한 설계로 이어질 수 있다.
• 시장 관점에서는 “메일을 보내는 기능” 자체보다 작은 사업자가 쉽게 설정하고 신뢰도 있게 운영할 수 있도록 도와주는 온보딩·자동화·검증 기능에 기회가 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서 언급된 SES 비용과 리샌드 요금은 서비스 선택의 핵심 근거로 쓰였지만, 실제 적용 전에는 최신 요금제와 무료 크레딧 조건을 공식 페이지에서 다시 확인해야 한다.
• SES 도메인 인증은 영상 중점에서 아직 보류 상태였고, DNS 전파가 완료됐는지 여부는 확인되지 않았다.
• 테스트 메일은 스팸함에 도착했으므로, 도메인 인증 완료 후에도 SPF, DKIM, DMARC, 발신 평판, 콘텐츠 품질에 따른 실제 도달률 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 뉴스레터 SaaS PRD에서 핵심 범위를 구독자 수집, 뉴스레터 작성, 테스트 발송, 즉시·예약 발송, 수신거부 처리로 다시 압축한다.
• Amazon SES 사용 전 이메일 인증, 도메인 인증, DKIM CNAME 등록, SMTP 자격증명 발급 상태를 체크리스트로 점검한다.
• Cloudflare 또는 도메인 DNS에서 SES용 CNAME 3개가 올바르게 등록됐는지 확인하고, 프록시 설정이 필요한 레코드가 아닌지 검토한다.
• SES 샌드박스 상태에서는 검증된 수신자에게만 발송 가능한지 확인하고, 실제 운영 전 프로덕션 액세스 요청 절차를 준비한다.

❓ 열린 질문

• 개인이 운영하는 작은 뉴스레터 SaaS에서 SES의 낮은 발송 비용이 설정 난도와 운영 부담을 상쇄할 만큼 충분한가?
• 초기 MVP에서 리샌드를 제외하고 SES로 바로 가는 선택이 빠른 출시에는 유리한가, 아니면 인증·DNS 설정 때문에 오히려 개발 속도를 늦출 수 있는가?
• 뉴스레터 에디터는 경량 커스텀 블록 에디터로 충분한가, 아니면 이미지·링크·유튜브 삽입을 고려해 더 구조화된 에디터가 필요한가?