이메일 스타트업 공동묘지: 왜 대부분의 이메일 스타트업은 실패하는가

 (forwardemail.net)
2P by GN⁺ | ★ favorite | 댓글 6개

이메일 스타트업 실패 매트릭스

  • 이메일 스타트업 다수는 Amazon SES나 Postfix 같은 기존 인프라 위에 단순 UI를 얹는 형태였음
  • Skiff, Sparrow, Email Copilot, ReplySend, Nveloped, Jumble, InboxFever 등은 모두 실패하거나 인수 후 종료
  • YC와 Techstars가 배출한 이메일 스타트업 대부분은 피벗(pivot)하거나 조기 종료
  • 인프라를 직접 구축하지 못한 서비스는 단기 생존에 그침

인프라 현실 점검

  • 대부분의 이메일 스타트업은 실제 서버를 구축하지 않고 앱이나 클라이언트만 개발
  • 성공한 회사들은 SendGrid, Mailgun, Postmark처럼 SMTP API·전달 인프라를 제공
  • 프로토콜을 바꾸려 하기보다는 기존 워크플로 강화가 성공 패턴

왜 대부분의 이메일 스타트업은 실패하는가

  • 1. 프로토콜은 잘 작동하지만 구현은 어렵다

    • SMTP, IMAP, POP3는 수십 년간 검증됨
    • 문제는 새로운 프로토콜이 아니라 구현 품질

  • 2. 네트워크 효과는 절대적이다

    • 이메일은 40억 명 이상이 사용, 모든 플랫폼과 호환
    • 교체 비용이 높아 다른 서비스로 전환하기 어려움

  • 3. 잘못된 문제를 겨냥한다

    • “이메일은 복잡하다”, “AI가 필요하다”, “보안이 약하다” 등 잘못된 가정
    • 실제 중요한 문제는 전달 안정성, 스팸 필터링, 개발자 도구

  • 4. 기술 부채가 크다

    • SMTP 서버 운영, 스팸 대응, 대용량 저장소, 인증·전달 인프라 모두 구축이 까다로움

  • 5. 인프라는 이미 존재한다

    • Amazon SES, Postfix, Dovecot, SpamAssassin 등 오픈소스·상용 인프라 풍부

이메일 스타트업 실패 사례 연구

  • Skiff 사례

    • “프라이버시 우선 이메일 및 생산성 플랫폼” 으로 포지셔닝 하며 상당한 벤처 캐피털 투자 유치
    • 2024년 2월 Notion이 Skiff를 인수하며 통합·지속 개발을 약속했음
    • 실제로는 인수 후 수개월 만에 즉시 서비스 종료하고, 창업자들은 Notion을 떠나 Cursor로 합류
    • 수천 명의 사용자가 강제로 서비스 이전

  • 액셀러레이터 별 분석

    • Y Combinator: 이메일 앱 팩토리

      • Emailio (2014): 모바일 이메일 클라이언트 → 웰니스로 피벗
      • MailTime (2016): 채팅형 이메일 → 분석 서비스로 피벗
      • reMail (2009): iPhone 이메일 검색 → 구글에 인수 후 종료
      • Rapportive (2012): Gmail 소셜 프로필 → LinkedIn 인수 후 종료
      • 성공률: 일부 인수 성공(reMail, Rapportive) 사례가 있으나 다수는 피벗 또는 인재 인수(acqui-hire)로 종료

    • Techstars: 이메일 공동묘지

      • Email Copilot (2012): 인수 후 종료
      • ReplySend (2012): 완전 실패
      • Nveloped (2012): “Easy. Secure. Email” → 실패
      • Jumble (2015): 이메일 암호화 서비스 → 실패
      • InboxFever (2011): 이메일 API → 실패
      • 패턴: 모호한 가치 제안, 실질적 기술 혁신 부재, 빠른 실패

  • 벤처캐피털의 함정

    • VC Funding Paradox: 이메일 스타트업은 단순해 보이지만 실제로는 불가능에 가까움
    • 투자자들을 끌어들이는 전제 자체가 실패를 보장하는 구조
    • 현실: 이메일 인프라와 프로토콜은 이미 견고하며, 새로운 스타트업이 이를 대체하기는 불가능

현대 이메일 스택의 기술적 현실

  • 대부분의 이메일 스타트업은 자체 인프라를 새로 구축하지 않고, 기존 이메일 서버·프로토콜 위에서 클라이언트 애플리케이션을 얹는 형태

  • 이로 인해 기본적인 한계와 성능 문제가 반복적으로 발생하며, 스타트업 실패의 한 축을 담당함

  • 메모리 과다 사용 (Memory Bloat)

    • 현대 이메일 클라이언트는 주로 Electron 기반 웹앱으로 제작되어 RAM을 과도하게 소모함
    • Mailspring: 기본 이메일 동작만으로도 500MB+ 메모리 사용
    • Nylas Mail: 종료 전 1GB+ 메모리 사용
    • Postbox: 대기 상태에서조차 300MB+ 차지
    • Canary Mail: 메모리 문제로 빈번한 크래시 발생
    • Thunderbird: 시스템 메모리의 최대 90%까지 사용 보고 사례
    • Electron 성능 위기:
      • Electron, React Native 같은 크로스 플랫폼 프레임워크는 개발자에게 편리하지만, 리소스를 비효율적으로 사용
      • 결과적으로 단순 이메일 기능을 위해 수백 MB~수 GB까지 메모리를 잡아먹는 상황 발생

  • 배터리 소모 (Battery Drain)

    • 비효율적인 코드와 동작 방식으로 인해 모바일 및 노트북 환경에서 배터리 소모 심각.
    • 백그라운드 프로세스가 항상 실행 상태 유지
    • 수 초마다 불필요한 API 호출 발생
    • 연결 관리가 비효율적
    • 필수 기능 외에 불필요한 서드파티 의존 없음에도 리소스 낭비 심각

인수 패턴: 성공 vs 실패

  • 두 가지 패턴

    • 클라이언트 앱 패턴 (대부분 실패)
      • 이메일 클라이언트 애플리케이션은 인수 이후 대개 빠르게 종료됨
      • 새로운 사용자 경험 제공을 내세우지만, 인프라 의존성과 네트워크 효과 장벽을 넘지 못해 유지 불가능
    • 인프라 패턴 (종종 성공)
      • SMTP·API 같은 핵심 이메일 인프라를 제공하는 기업은 인수 후에도 성장하거나 플랫폼에 통합되어 지속적 성과를 냄

  • 최근 사례

    • 클라이언트 앱 실패

      • Mailbox → Dropbox → Shutdown (2013–2015)
      • Sparrow → Google → Shutdown (2012–2013)
      • reMail → Google → Shutdown (2010–2011)
      • Skiff → Notion → Shutdown (2024)

    • 예외적 성공

      • Superhuman → Grammarly (2025)
        • 전략적 통합으로 성공적인 인수 사례. 이메일 클라이언트 분야에서는 드문 성공적 엑시트

    • 인프라 성공

      • SendGrid → Twilio (2019): 30억 달러 규모 인수, 이후 지속 성장
      • Mailgun → Sinch (2021): 전략적 인수로 통합
      • Postmark → ActiveCampaign (2022): 플랫폼 기능 확장에 기여
  • 클라이언트 앱은 인수 후 서비스 종료로 귀결되는 경우가 많지만, 인프라 제공 기업은 인수 후에도 살아남아 플랫폼의 핵심 요소로 자리잡는 경향이 뚜렷함

산업의 진화와 통합

  • 자연스러운 산업 발전

    • 이메일 산업은 시간이 지남에 따라 대형 기업이 소규모 회사를 인수하여 기능을 통합하거나 경쟁을 제거하는 형태로 발전해 왔음
    • 이는 부정적 현상만은 아니며, 대부분의 성숙한 산업에서 나타나는 자연스러운 발전 과정임

  • 인수 이후의 전환

    이메일 기업이 인수되면 사용자들이 겪는 변화는 다음과 같음:
    • 서비스 마이그레이션: 새로운 플랫폼으로 계정과 데이터를 옮겨야 함
    • 기능 변화: 특화된 기능이 사라지거나 다른 방식으로 대체됨
    • 가격 조정: 구독 모델과 요금제가 바뀔 수 있음
    • 통합 기간의 불편: 서비스 통합 과정에서 일시적 장애나 중단 발생 가능

  • 전환기에 사용자가 고려할 점

    산업 통합 시기에 사용자가 취할 수 있는 대응:
    • 대체 서비스 검토: 유사 기능을 제공하는 다른 공급자를 탐색
    • 마이그레이션 경로 파악: 대부분의 서비스는 내보내기 도구를 제공하므로 이를 활용
    • 장기적 안정성 고려: 오랜 기간 운영되고 신뢰성 있는 공급자를 선택하는 것이 유리

Hacker News 현실 점검

모든 이메일 스타트업은 Hacker News에서 반복적으로 같은 피드백을 받음:

현대의 AI 이메일 스타트업 열풍

  • 최신 물결

    2024년에는 "AI 기반 이메일" 스타트업의 새로운 물결이 등장했으며, 이미 첫 번째 주요 성공적 인수가 이루어짐:
    • Superhuman: 총 $3,300만 투자 유치, 2025년 Grammarly에 인수 — 드문 성공 사례로 평가되는 클라이언트 앱 인수
    • Shortwave: Gmail을 기반으로 AI 요약 기능을 추가한 래퍼
    • SaneBox: 실제로 동작하는 AI 이메일 필터링, 하지만 혁신적이진 않음

  • 여전한 문제들

    "AI"를 붙여도 이메일의 근본적 문제는 해결되지 않음:
    • AI 요약: 대부분의 이메일은 이미 짧고 간결함
    • 스마트 답장: Gmail은 이미 수년 전부터 제공하고 있음
    • 이메일 예약 발송: Outlook이 기본적으로 지원
    • 우선순위 감지: 기존 이메일 클라이언트에 이미 효과적인 필터링 시스템 존재
      핵심 현실: AI 기능은 실제로는 상대적으로 작은 불편을 해결하는 데 비해 막대한 인프라 투자가 필요하다는 점에서 근본적 해결책이 되지 못함

실제로 성공한 이메일 사례들

  • 인프라스트럭처 기업 (성공한 사례들)

  • 이메일 서비스 제공자 (생존자들)

    • FastMail: 25년 이상 운영, 수익성 있는 독립 기업
      • JMAP 투자 논란: Fastmail은 10년 넘게 도입이 미미한 JMAP 프로토콜에 자원을 투자하면서, 동시에 많은 사용자가 요청하는 PGP 암호화를 거부함. 이는 사용자 요구보다 프로토콜 혁신을 우선한 전략적 선택으로 평가됨. 여전히 대부분의 이메일 클라이언트는 IMAP/SMTP에 의존
    • ProtonMail: 개인정보 보호 중심, 지속 가능한 성장
    • Zoho Mail: 대규모 비즈니스 제품군의 일부로 안정적 운영
    • Forward Email(We): 7년 이상 운영, 수익성과 성장을 동시에 달성
    • 기업 성공 사례: Forward Email은 케임브리지 대학 30,000명의 동문 이메일 솔루션을 지원하여 연간 $87,000 절감 효과 제공
    • 패턴: 이들은 이메일을 대체하지 않고 강화함.

  • 예외적 성공 사례: Xobni

    Xobni는 기존 이메일 환경을 개선함으로써 드물게 성공한 스타트업임.
    • 올바른 전략:
      • 기존 이메일 위에 구축: Outlook과 연동
      • 실제 문제 해결: 연락처 관리 및 이메일 검색 문제를 해결
      • 통합 중심: 기존 워크플로우에 맞게 작동
      • 엔터프라이즈 초점: 생산성 향상에 돈을 지불할 기업 시장 타겟팅
    • 성과: 2013년 Yahoo가 $6천만 달러에 인수, 투자자에게 의미 있는 수익 제공.
    • 창업자들의 이후 성과:
      • Matt Brezina: 활발한 엔젤 투자자로 Dropbox, Mailbox 등에 투자
      • Adam Smith: 생산성 분야에서 계속 성공적인 기업 창업
      • 두 창업자 모두 "이메일 성공은 대체가 아닌 개선에서 온다" 는 점을 입증

  • 성공의 패턴

    이메일 분야에서 성공한 기업들의 공통점:
    • 1. 인프라를 구축 → SendGrid, Mailgun
    • 2. 기존 워크플로우를 강화 → Xobni, FastMail
    • 3. 신뢰성에 집중 → Amazon SES, Postmark
    • 4. 개발자를 지원 → API와 도구 제공, 최종 사용자 앱이 아님

이메일을 성공적으로 재발명한 사례가 있는가?

이 질문은 이메일 혁신의 본질을 파고드는 중요한 물음임
짧은 답변은 다음과 같음: 누구도 이메일을 대체하는 데 성공하지 못했지만, 이메일을 ‘강화’하는 데는 성공한 사례가 있음.

  • 실제로 자리 잡은 혁신들

    지난 20년간 이메일에서 정착한 혁신들은 모두 기존 프로토콜을 대체하지 않고 강화한 것들임:

  • 이메일을 대체하지 않고 보완하는 도구들

    • Slack: 팀 채팅 도구지만 이메일 알림을 여전히 전송
    • Discord: 커뮤니티 중심 플랫폼이지만 계정 관리는 이메일 기반
    • WhatsApp: 메시징에 최적화되어 있으나 비즈니스는 이메일을 계속 사용
    • Zoom: 화상 회의 필수 도구지만, 회의 초대장은 이메일로 발송

  • HEY 실험

    Basecamp의 HEY는 최근 가장 진지하게 이메일을 “재발명”하려 한 시도임.
    • 출시: 2020년, 대대적인 홍보와 함께 등장
    • 접근법: 선별·번들링·워크플로우 등 새로운 이메일 패러다임 제시
    • 반응: 일부는 열광했으나, 다수는 기존 이메일 사용을 유지
    • 현실: 결국 여전히 SMTP/IMAP 기반 이메일에 새로운 인터페이스를 덧붙인 것에 불과
    • 실증적 사례: 창업자 DHH는 자신의 개인 도메인 dhh.dk에서 수년간 Forward Email을 사용하고 있음. 이는 이메일 혁신가조차 검증된 인프라에 의존함을 보여줌.

  • 실제로 효과적인 것들

    가장 성공적인 이메일 혁신은 다음과 같음:
    • 1. 더 나은 인프라: 더 빠른 서버, 개선된 스팸 필터링, 향상된 전달율
    • 2. 강화된 인터페이스: Gmail 대화형 보기, Outlook 캘린더 통합
    • 3. 개발자 도구: 이메일 전송 API, 추적용 웹훅
    • 4. 특화된 워크플로우: CRM 연동, 마케팅 자동화, 트랜잭션 이메일

결론: 지금까지 어떤 혁신도 이메일을 대체하지 못했으며, 모두 이메일을 더 나아지게 만드는 방향으로 성공함

기존 이메일 프로토콜을 위한 현대적 인프라 구축: 우리(Forward Email)의 접근법

실패 사례를 다루기 전에, 이메일에서 실제로 효과적인 것이 무엇인지 이해하는 것이 중요함
이메일 자체가 깨져 있는 것이 아니라, 많은 회사들이 이미 잘 작동하는 시스템을 "고치려" 하면서 문제가 발생함

  • 이메일 혁신 스펙트럼

    이메일 혁신은 크게 세 가지 범주로 나눌 수 있음:
    • 1. 프로토콜 강화: SMTP, IMAP, POP3 같은 표준을 더 안정적이고 빠르게 구현
    • 2. 워크플로우 개선: 기존 이메일 사용 흐름을 더 효율적으로 만드는 도구와 기능
    • 3. UI/UX 혁신: 새로운 인터페이스를 통한 접근성 및 사용성 강화

  • 우리가 인프라에 집중하는 이유

    우리는 새로운 앱을 만들기보다는 현대적인 이메일 인프라를 구축하기로 선택했음. 그 이유는 다음과 같음:
    • 검증된 이메일 프로토콜: SMTP는 1982년부터 안정적으로 작동해왔음
    • 문제는 구현 품질: 많은 이메일 서비스가 여전히 낡은 소프트웨어 스택을 사용함
    • 사용자가 원하는 것 = 신뢰성: 새로운 기능이 아니라 안정적이고 깨지지 않는 워크플로우
    • 개발자 필요성: 더 나은 API와 관리 인터페이스 제공 필요

  • 이메일에서 실제로 효과적인 것들

    성공적인 패턴은 단순함: 기존 이메일 워크플로우를 대체하지 않고 강화하는 것
    • 더 빠르고 신뢰성 있는 SMTP 서버 구축
    • 정상 이메일을 방해하지 않으면서 더 나은 스팸 필터링
    • 기존 프로토콜을 활용할 수 있는 개발자 친화적 API 제공
    • 올바른 인프라를 통한 전달률 개선
      결론: 이메일의 혁신은 "대체"가 아니라 인프라를 통해 기존 시스템을 더 나아지게 만드는 것임

우리의 접근법: Forward Email이 다른 이유

  • 우리가 하는 일 (What We Do)

    • 실제 인프라 구축: SMTP/IMAP 서버를 처음부터 직접 개발
    • 신뢰성에 집중: 99.99% 가동 시간 보장 및 올바른 오류 처리
    • 기존 워크플로우 강화: 모든 이메일 클라이언트와 호환되며 안정적 작동
    • 개발자 지원: 실제로 쓸 수 있는 API와 도구 제공
    • 완전한 호환성 유지: SMTP / IMAP / POP3 표준 완벽 준수

  • 우리가 하지 않는 일 (What We Don’t Do)

    • “혁신적”이라는 이름의 새로운 이메일 클라이언트 개발
    • 기존 이메일 프로토콜 대체 시도
    • 불필요한 AI 기능 추가
    • 이메일을 “고치겠다”는 허황된 약속
      핵심은 검증된 프로토콜 위에서 안정성과 호환성을 높이는 것이며, 보여주기식 혁신 대신 실제 동작하는 인프라에 집중함

우리가 실제로 작동하는 이메일 인프라를 구축한 방법

  • 우리의 반(反)스타트업 접근법 (Our Anti-Startup Approach)

    다른 회사들이 수백만 달러를 태우며 이메일을 재발명하려 할 때, 우리는 단순히 신뢰성 있는 인프라 구축에 집중해왔음:
    • 피벗 없음: 7년 이상 이메일 인프라에만 전념
    • 인수 전략 없음: 단기 매각이 아닌 장기적 운영 목표
    • 혁신 과장 없음: 이메일을 "고치는" 것이 아니라 더 잘 작동하게 만드는 것

  • 우리가 다른 이유 (What Makes Us Different)

    • 정부 규격 준수: Section 889 규정 준수, 미국 해군사관학교 등 기관 고객 보유
    • OpenPGP + OpenWKD 지원: Fastmail이 거부한 PGP 암호화를 지원, 사용자가 원하는 실제 암호화 기능 제공
    • 기술 스택 차별화:
      • 전체 스택을 JavaScript로 개발 (1980년대 C 코드 기반 Postfix 대비)
      • 단일 언어로 글루 코드 불필요
      • 웹 네이티브 아키텍처, 유지보수성 뛰어남
      • 레거시 부채 없음, 현대적 코드베이스
    • Privacy by Design:
      • 이메일을 디스크나 DB에 저장하지 않음
      • 메타데이터, 로그, IP 주소 미저장
      • 포워딩 시 메모리 내에서만 처리
    • 기술 백서와 문서를 통해 보안·아키텍처 세부 구현을 공개

  • 왜 우리가 성공하는가 (Why We Succeed Where Others Fail)

    • 1. 앱이 아니라 인프라 구축: 서버와 프로토콜에 집중
    • 2. 대체가 아닌 강화: 기존 이메일 클라이언트와 호환성 유지
    • 3. 자체 수익성 확보: VC 압박 없이 지속 가능한 운영
    • 4. 깊은 기술 이해: 7년 이상 이메일 전문 경험
    • 5. 개발자 중심: 실제 문제 해결에 도움 되는 API와 도구 제공

이메일 인프라의 보안 과제

이메일 보안은 모든 서비스 제공자가 직면하는 복잡한 도전 과제임
개별 사고 사례보다 공통적으로 해결해야 할 보안 고려사항을 이해하는 것이 중요함

  • 공통 보안 고려사항 (Common Security Considerations)

    • 데이터 보호: 사용자 데이터와 통신을 안전하게 보호
    • 접근 제어: 인증 및 권한 관리
    • 인프라 보안: 서버와 데이터베이스 방어
    • 규제 준수: GDPR, CCPA 등 규정 충족
    • 고급 암호화 적용 : Forward Email의 보안 정책:
      • ChaCha20-Poly1305 기반 메일박스 암호화
      • LUKS v2 기반 디스크 전체 암호화
      • 저장·메모리·전송 구간 전반의 암호화 적용

  • 투명성의 가치 (The Value of Transparency)

    보안 사고 발생 시 가장 중요한 대응은 투명성과 신속한 조치임. 모범 사례는 다음과 같음:
    • 즉시 공개: 사용자들이 상황을 인지하고 대응할 수 있도록 함
    • 상세 타임라인 제공: 문제의 범위와 이해 수준을 보여줌
    • 빠른 수정 조치: 기술적 역량 증명
    • 교훈 공유: 업계 전체의 보안 개선에 기여

  • 지속적인 보안 과제 (Ongoing Security Challenges)

    이메일 보안은 계속 진화 중이며, 다음과 같은 영역에서 지속적 개선이 필요함:
    • 암호화 표준: TLS 1.3 같은 최신 암호화 방식 적용
    • 인증 프로토콜: DKIM, SPF, DMARC 강화
    • 위협 탐지: 스팸·피싱 필터링 고도화
    • 인프라 강화: 서버 및 데이터베이스 보안 강화
    • 도메인 평판 관리: Microsoft onmicrosoft.com 스팸 급증 사례처럼 새로운 위협에 대응하는 차단 규칙 마련

결론: 앱이 아닌 인프라에 집중하라

  • 명확한 증거 (The Evidence Is Clear)

    수백 개의 이메일 스타트업을 분석한 결과:
    • 실패율 80%+: 대부분의 이메일 스타트업은 완전히 실패 (실제 수치는 더 높을 가능성 큼)
    • 클라이언트 앱은 대부분 실패: 인수는 곧 서비스 종료로 이어짐
    • 인프라는 성공 가능: SMTP/API 서비스를 구축하는 기업들은 종종 번창함
    • VC 자금 압박: 벤처 자금은 비현실적인 성장 압력을 만듦
    • 기술 부채 누적: 이메일 인프라 구축은 예상보다 훨씬 어려움

  • 역사적 맥락 (The Historical Context)

    지난 20년간 스타트업들은 계속해서 이메일의 종말을 예언했음:
    • 2004: “소셜 네트워크가 이메일을 대체할 것”
    • 2008: “모바일 메시징이 이메일을 죽일 것”
    • 2012: “Slack이 이메일을 대체할 것”
    • 2016: “AI가 이메일을 혁신할 것”
    • 2020: “원격 근무 시대에는 새로운 커뮤니케이션 도구가 필요하다”
    • 2024: “AI가 마침내 이메일을 고칠 것”
      하지만 이메일은 여전히 존재하고, 성장 중이며, 필수적임

  • 진짜 교훈 (The Real Lesson)

    이메일이 개선될 수 없다는 교훈이 아니라, 올바른 접근법을 택해야 한다는 교훈임:
    • 1. 이메일 프로토콜은 유효함: SMTP, IMAP, POP3는 검증된 표준
    • 2. 인프라가 핵심: 화려한 기능보다 안정성과 성능이 중요
    • 3. 대체보다 강화: 이메일과 싸우지 말고 함께 작동하는 개선책을 제공
    • 4. 성장보다 지속가능성: 수익성 있는 기업이 VC 주도의 “빠르게 성장하고 망가뜨리기” 모델보다 오래 살아남음
    • 5. 개발자 지원: 최종 사용자 앱보다 개발자를 위한 도구와 API가 더 큰 가치를 만듦
    • 핵심 기회: 이미 검증된 프로토콜을 더 잘 구현하는 것, 새로운 프로토콜을 만드는 것이 아님
    • 더 깊은 분석: 79 Best Email Services (2025)
  • 이메일 스타트업을 만들고 싶다면, 앱이 아니라 인프라를 구축하는 것을 고려해야 함
    • 세상에 필요한 것은 더 많은 이메일 앱이 아니라, 더 나은 이메일 서버임

확장된 이메일 묘지: 더 많은 실패와 서비스 종료들

  • 구글의 이메일 실험 실패 (Google's Email Experiments Gone Wrong)

    구글은 Gmail을 보유하고 있음에도 불구하고 여러 이메일 프로젝트를 종료함:
    • Google Wave (2009–2012): “이메일 킬러”라 불렸으나 아무도 이해하지 못함
    • Google Buzz (2010–2011): 소셜 이메일 통합 시도, 실패
    • Inbox by Gmail (2014–2019): Gmail의 “스마트” 후속작으로 출시되었지만 결국 중단
    • Google+ (2011–2019): 이메일 기능 통합을 시도했으나 실패
    • 패턴: Gmail을 가진 구글조차 이메일을 성공적으로 재발명하지 못함

  • 뉴턴 메일의 세 번의 죽음 (The Serial Failure: Newton Mail's Three Deaths)

    Newton Mail은 무려 세 번 죽음을 맞음:
    • 1. CloudMagic (2013–2016): 초기 이메일 클라이언트, Newton에 인수됨
    • 2. Newton Mail (2016–2018): 브랜드 재출시, 구독 모델 실패로 종료
    • 3. Newton Mail Revival (2019–2020): 부활 시도, 다시 실패
    • 교훈: 이메일 클라이언트는 구독 모델을 지속할 수 없음

  • 출시조차 못한 앱들 (The Apps That Never Launched)

    많은 이메일 스타트업은 출시 전에 사라짐:
    • Tempo (2014): 캘린더-이메일 통합 시도, 출시 전 중단
    • Mailstrom (2011): 이메일 관리 툴, 출시 전 인수됨
    • Fluent (2013): 이메일 클라이언트, 개발 중단

  • 인수 후 종료 패턴 (The Acquisition-to-Shutdown Pattern)

    여러 이메일 앱이 인수 후 곧바로 종료됨:

  • 이메일 인프라 통합 (Email Infrastructure Consolidation)

    인프라 영역에서도 통합과 종료가 빈번함:

오픈소스 이메일 묘지: "무료"가 지속 불가능할 때

  • Nylas Mail → Mailspring: 실패한 포크

  • Eudora: 18년간의 죽음 행진

    • 1988–2006: Mac/Windows에서 지배적 이메일 클라이언트로 군림
    • 2006: Qualcomm 개발 중단 선언
    • 2007: "Eudora OSE"로 오픈소스화
    • 2010: 프로젝트 완전 중단
    • 교훈: 성공적인 이메일 클라이언트도 결국은 사라짐

  • FairEmail: Google Play 정책에 의해 사망

    • FairEmail: 개인정보 보호 중심의 안드로이드 이메일 클라이언트
    • Google Play: "정책 위반" 사유로 퇴출
    • 현실: 플랫폼 정책에 의해 이메일 앱이 하루아침에 사라질 수 있음

  • 유지보수 문제 (The Maintenance Problem)

    오픈소스 이메일 프로젝트들이 실패하는 이유:
    • 복잡성: 이메일 프로토콜을 올바르게 구현하기 어려움
    • 보안: 끊임없는 보안 업데이트 필요
    • 호환성: 모든 이메일 제공자와 호환되어야 함
    • 자원 부족: 자원봉사 개발자들의 소진(burnout)

AI 이메일 스타트업 붐: "지능"이라는 이름의 반복 역사

  • 현재 AI 이메일 골드러시 (2024)

  • 자금 조달 열풍

    • 2024년 한 해에만 VC가 $100M+ 투자
    • 반복되는 약속: "혁신적인 이메일 경험"
    • 반복되는 문제: 기존 인프라 위에서만 구축
    • 반복되는 결과: 대부분 3년 이내 실패 예상

  • 왜 다시 실패할 것인가

    • 1. AI는 이메일의 ‘문제가 아닌 문제(non-problem)’를 해결하려 함 – 이메일은 이미 잘 작동 중
    • 2. Gmail은 이미 AI 기능 제공 – 스마트 답장, 우선순위 편지함, 스팸 필터링
    • 3. 프라이버시 우려 – AI는 모든 이메일을 읽어야 함
    • 4. 비용 구조 문제 – AI 처리 비용은 높고, 이메일은 본질적으로 저가 서비스
    • 5. 네트워크 효과 – Gmail/Outlook의 지배적 위치를 무너뜨릴 수 없음

  • 불가피한 결과

    • 2025: Superhuman → Grammarly 인수 (드문 성공 사례)
    • 2025–2026: 대부분의 AI 이메일 스타트업은 피벗 또는 폐업
    • 2027: 일부 생존 기업은 인수되지만 성패가 엇갈림
    • 2028: "블록체인 이메일" 같은 새로운 유행이 등장할 가능성

통합의 재앙: "생존자"가 재앙이 될 때

  • 대규모 이메일 서비스 통합

    이메일 산업은 급격히 통합(consolidation) 되었음

  • Outlook: 멈추지 않는 문제를 가진 "생존자"

    Microsoft Outlook은 여전히 업계 주류지만 지속적인 문제 발생
    • 메모리 누수: 수 GB RAM 사용, 잦은 재시작 필요
    • 동기화 문제: 이메일이 사라졌다가 다시 나타나는 현상
    • 성능 문제: 시작 속도 느림, 자주 충돌
    • 호환성 문제: 타사 이메일 제공자와 충돌 발생

    실제 현장 사례: 표준 IMAP 구현을 따름에도 Outlook이 자주 깨짐

  • Postmark 인프라 문제

    ActiveCampaign 인수 이후 발생한 문제들

  • 최근 이메일 클라이언트 사망 사례 (2024–2025)

  • 이메일 확장/서비스 종료 사례

  • 실제로 살아남은 이메일 기업들

    • Mailmodo: YC 출신, 인터랙티브 이메일 캠페인, Sequoia Surge에서 $2M 투자
    • Mixmax: 총 $13.3M 투자, 영업 참여 플랫폼으로 운영 중
    • Outreach.io: $4.4B+ 평가, IPO 준비 중
    • Apollo.io: 2023년 $1.6B 평가, $100M 시리즈 D 유치
    • GMass: Gmail 확장 기반, 월 $140K 부트스트랩 성공 사례
    • Streak CRM: Gmail 기반 CRM, 2012년부터 안정적으로 운영
    • ToutApp: 2017년 Marketo에 인수 성공
    • Bananatag: 2021년 Staffbase에 인수, "Staffbase Email"로 지속 운영

  • 핵심 패턴

    • 성공 기업들은 이메일을 대체하지 않고, 워크플로우를 보강(enhance)
    • 이메일 인프라와 협력적으로 작동하는 도구를 만들었음

결론

  • 이메일 스타트업의 80% 이상은 실패
  • 앱 중심 접근은 실패, 인프라 중심 접근은 성공
  • 핵심 교훈:
    • 1. 이메일 프로토콜은 이미 잘 작동
    • 2. 인프라의 안정성과 성능이 중요
    • 3. 교체보다는 강화가 효과적
    • 4. 지속 가능한 비즈니스 모델이 필요
    • 5. 개발자를 위한 도구와 API가 성공의 열쇠

함께 보면 좋은 글 β

princox   [-]

중간까지만 읽고 hey.com 사례는 없을까? 하자마자 내용에 바로 등장하네요 ㅎㅎ
이메일이라는 제품은 항상 무궁무진한 동시에 기존 플레이어의 지위를 탈환하기가 어려운 시장 같아요..

답변달기
bungker   [-]

구축해 놓으면 여기저기서 스팸메일서버로 등록해서 이거 푸는게 일입니다 고객님한테 안된다고 갑자기 연락받으면 대부분 스팸서버 등록이더라구요

답변달기
nemorize   [-]

아직 성공했다, 실패했다 논하기엔 규모가 작은 제품이지만,
Mimestream 이라는 지메일 클라이언트를 아주 즐겁게 잘 사용하고 있습니다.

https://mimestream.com/

지금껏 써온 메일 클라이언트들 중에서 제일 만족스럽습니다... 베타때부터 쓰기 시작해 이제 거의 5년째네요.

답변달기
t7vonn   [-]

음.. "해커뉴스 현실 점검(The Hacker News Reality Check)" 부분 링크가 다 이상하네요. 애초에 원문부터 이상한 링크로 걸어놨네요.

답변달기
xguru   [-]

어라 그렇네요. 원문을 찾아봐도 찾기가 어려워서 걍 둬야할듯합니다.

답변달기
GN⁺   [-]
Hacker News 의견
  • 나는 SendGrid에서 12번째 엔지니어로 일했고, IPO 이후 Twilio의 인수 후에 회사를 떠남. 인프라를 담당하면서 여러 이메일 마케팅 회사들의 기반이 되어 성과를 냄. 금광 시대에 삽을 파는 것처럼 비즈니스가 성장함. 더 큰 마케팅 시장에 진입하는 제품적인 측면에서는 더 힘들었음. 그곳에서 팀 리딩, 스케일링, 그리고 하루 80억 건 이상의 이메일 인프라 확장 등 많은 경험을 쌓음
    • 이메일 마케팅 회사들이라면 스패머를 의미하는 것 아닌지 궁금함
    • 구직 중임이 느껴짐
  • 모든 "이메일 스타트업"은 기존 인프라 위에 UI만 덧씌우는 일임. 실제 이메일 서버를 만드는 게 아니라 이미 구축된 인프라에 연결되는 앱을 만드는 것임. 내가 Mailpace를 만들면서 정말 충격을 받았던 부분임. 다들 직접 smtp 서버를 운영한다고 생각했는데, 실제로는 YC나 여러 곳에서 aws ses에 래퍼만 붙이는 회사를 엄청나게 펀딩하고 있는 상황임
    • YC와 여러 곳에서 aws ses 래퍼에 집중적으로 투자하는 게 모든 분야를 송두리째 혁신할 대단한 일인 듯 말하지만, 이것이 피자 배달까지 바꿀 거라고 비꼬는 유머임
    • Gmail 인박스에 메일을 넣는 일이 엄청 복잡하고 까다롭기 때문에(스팸 문제 때문임), 그렇기에 스패머들이 이런 래퍼 서비스를 활용하는 것을 이해할 수 있음
  • 이메일 스타트업의 20%나 성공한다는 사실에 놀라움. 꽤 괜찮은 성공률이라 생각함
  • Electron과 React Native로 개발된 현대적 이메일 클라이언트들이 메모리 점유와 성능 문제에 시달리는 것에 대해, 실제(진짜) 고객들은 전혀 신경 쓰지 않는다고 말함. 예를 들어 Discord와 Slack처럼 비대하지만 거의 모든 사람이 사용하는 Electron 앱들이 이를 증명함. 나는 개인적으로 React를 싫어하지만, 기술 결정이 스타트업의 장기적 성공에는 큰 영향을 미치지 않는다고 봄(고객 경험이나 기능에 크게 방해되지 않는 한). 이메일 스타트업 중 80% 이상이 완전히 실패한다는 수치도 실제로는 실패율이 훨씬 높을 거라고 내기 걸 수 있음. 게다가 20%의 이익률이 나쁜 결과라고 하는 것도 잘 이해가 안 됨, 특히 이메일처럼 지루한 분야에서라면 더욱 그렇다고 생각함. 자원봉사자들이 엔터프라이즈급 소프트웨어를 지속적으로 운영할 수 없다고 쓴 글에 대해선, 오픈소스 계에서 openssl, Linux 등 많은 소프트웨어가 대다수 자원봉사자에 의해 잘 운영되고 있음을 상기함. 이 글을 읽으니 오히려 이메일을 재발명할 방법을 더 고민하게 됨
    • "진짜" 고객은 성능에 신경 쓰지 않는다는 주장에 반박함. 내가 일했던 두 회사의 "일반" 사용자들도 Electron 기반 앱의 불편한 경험 때문에 다른 도구를 찾고 있었음. 일부 사례일 수 있지만, 그만큼 사용 경험이 나쁘면 평범한 사람들도 충분히 신경 씀
    • 나는 실제 Discord 사용자인데, M1 MacBook과 게이밍 PC에서 너무 느려서 대체 앱을 적극적으로 찾고 있음. 내가 평균적인 고객을 대표한다고 주장하지는 않지만, 이런 불편을 느끼는 사람이 많다는 점을 강조하고 싶음
    • "고객이 신경 안 쓴다"는 말은 사실이 아님. 기술에 관심 적은 내 여자친구조차 Teams 같은 채팅 앱 하나가 컴퓨터 전체를 느리게 만든다고 불평했음. 평균적인 사용자는 Electron이나 React 자체를 싫어하진 않아도, 이들로 인해 발생한 나쁜 경험은 분명히 싫어함
    • 엔터프라이즈급 소프트웨어가 자원봉사자로 유지될 수 없다는 주장에, Postfix 역시 대부분 커뮤니티 자원봉사자에 의해 잘 운영되고 있음
    • 모두가 설치한 Electron 앱 예시로 Discord와 Slack을 들었지만, 난 그 둘 다 설치 안 한 유일한 사람인 듯함
  • Hey가 언급되지 않은 게 의외임. 최근 이메일 재발명을 시도한 곳은 그 예시밖에 모르겠음. 단독 회사가 아니고 Basecamp의 일부분이라서 빠진 걸 수도 있지만, "누구도 이메일을 재발명하지 못했다"는 논지를 펼친다면 꼭 다뤄야 한다고 생각함
    • 언급되어 있음. "The HEY Experiment"라는 섹션이 별도로 존재함
    • 재발명이라는 게 UX만을 의미하는지 궁금함. Fastmail은 뛰어난 오픈 프로토콜로 이메일을 재해석하고 있음
  • Techstars 사례처럼 이메일 관련 28개 회사 중 5개만 엑시트라 실패율 80% 가까운 게 문제로 보이지만, 사실 전체 스타트업 실패율과 비교하면 훨씬 나은 수치임. 실패율 80%라면 이메일 회사에 더 투자할 것 같음. 전체 분석이 메시지에 맞도록 왜곡된 느낌이고 Cyrus IMAP, SpamAssassin을 언급하는 것조차 과거에 머물러 있는 듯함. 자가 펀딩이니 이런 논조가 이해되긴 하지만, 좀 더 객관적 관점이 필요하다고 생각함
  • 만약 Fastmail을 스타트업 범주에 포함한다면, Posteo와 Mailbox.org 같은 회사들도 포함해야 하는 것 아님? Runbox.com은 한 명이 운영하지만, 이런 회사들도 수십 년간 꾸준히 성장 중임. Posteo는 VC 투자도 받지 않았고(이로 인해 실패 가능성이 줄었다고 기사에서는 지적함), Migadu처럼 변함없이 운영되는 서비스 또한 언급이 없음
    • "AI"가 그런 회사들의 언급 데이터를 충분히 학습하지 않아서 빠졌을 수 있음
    • Runbox.com은 소규모 팀은 맞지만, 한 명이 전부는 아님. Runbox 팀 소개 자료를 참고하면 다수의 팀원이 있음. (직접 이용 중인 고객임)
  • Mailbox가 600만 달러를 투자받아 1억 달러에 엑시트했는데도 실패로 분류된다는 건 이해가 잘 안 됨
    • Rapportive가 12만 달러 투자로 1,500만 달러 엑시트한 사례도 주목받을 만함
답변달기