▲

캘린더, 연락처, 파일용 JMAP이 Stalwart에 추가됨

 (stalw.art)
1P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 오픈소스 협업 서버 Stalwart가 4년간의 개발 끝에 캘린더, 연락처, 파일 저장 및 공유용 JMAP을 완전 구현하며 새로운 이정표를 달성
  • 이번 릴리스로 Stalwart는 JMAP 전체 프로토콜군을 완전 지원하는 최초의 서버가 되었으며, 이메일을 넘어 협업 전반으로 확장된 통합 API를 제공
  • JSON 기반의 단일 프레임워크를 통해 기존 WebDAV·CalDAV·CardDAV의 복잡성과 비효율을 대체하고, 개발자 친화적인 구조를 실현
  • 새로운 JSCalendar와 JSContact 포맷은 iCalendar와 vCard의 복잡성을 제거하고, 명확하고 일관된 데이터 모델을 제공
  • 이는 오픈 표준 기반 협업 기술의 진화를 상징하며, 향후 캘린더링·파일 공유·메일 통합 생태계의 혁신 가속화를 예고

새로운 세대의 프로토콜

  • 최근 몇 년간 IETF는 이메일, 캘린더, 연락처의 동기화 및 공유 방식을 재정의하고 있음
    • 기존 JMAP for Mail의 성공을 기반으로, 캘린더·연락처·파일·공유용 확장 프로토콜이 새롭게 도입됨
    • JMAP for Calendars - CalDAV 와 CalDAV 스케쥴링의 현대적인 대체제
    • JMAP for Contacts – CardDAV의 강력한 대체제
    • JMAP for File Storage – WebDAV 기반 파일 저장소를 대체
    • JMAP Sharing – WebDAV ACL의 현대적인 후계자
    • JSCalendar - 깔끔한 JSON 기반으로 진화한 iCalendar
    • JSContact – vCard의 현대화된 JSON 기반 후계자
  • 이들 표준은 분절된 WebDAV 기반 기술을 대체하는 통합적이고 우아한 생태계를 제공
    • 수십 년간의 호환성 문제를 해결하고, 단일한 데이터 모델로 협업 기능을 단순화함

기존 기술의 한계

  • WebDAV, CalDAV, CardDAV 등은 오랜 기간 안정적으로 사용되어 왔지만, XML 기반 설계로 인해 과도하게 장황하고 일관성이 부족함
    • 데이터가 HTTP 헤더, XML 페이로드, iCalendar 데이터 등 여러 위치에 흩어져 있어 클라이언트와 서버 간 상호운용성 문제가 빈번히 발생
  • iCalendar와 vCard 역시 수십 년간의 기술 부채를 안고 있음
    • 사용 빈도가 낮거나 폐기된 속성이 많고, 버전별 구현이 불일치하여 복잡한 파싱 로직이 필요
  • 이러한 구조적 복잡성은 유지보수와 확장성을 저해하며, 현대적 협업 환경에 부적합한 상태

현대적 요구에 맞는 JMAP의 등장

  • JMAP 프로토콜은 원래 IMAP과 SMTP를 대체하기 위해 개발된 효율적이고 단순한 메일 전송 프로토콜
    • JSON over HTTPS 기반으로 명확성과 네트워크 효율성을 동시에 확보
  • 이제 JMAP for Calendars, Contacts, Files, Sharing의 도입으로 동일한 설계 철학이 협업 전반으로 확장됨
    • 메일, 캘린더, 연락처, 파일, 공유 리소스를 위한 통합적이고 일관된 API 제공
  • JSCalendar와 JSContact는 기존 iCalendar와 vCard를 JSON 기반 포맷으로 재구성
    • 불필요한 속성을 제거하고, 명확하고 일관된 데이터 모델을 제공
    • 사람이 읽기 쉽고 개발자 친화적이며, 파싱 효율이 높아 현대 애플리케이션에 최적화됨
  • JMAP과 이 새로운 데이터 모델의 결합은 캘린더링, 연락처 관리, 파일 공유를 더 빠르고 신뢰성 있게 구현할 수 있게 함

이번 릴리스의 의미

  • 이번 릴리스는 단순한 기능 추가를 넘어, 그룹웨어 프로토콜 설계 방식의 전환점을 의미
    • 개발자와 조직이 메일, 연락처, 캘린더, 공유 리소스를 단일 JSON 기반 프레임워크 위에서 구축 가능
  • JMAP의 단순성과 예측 가능성은 클라이언트와 서버가 프로토콜 처리보다 기능과 사용자 경험에 집중할 수 있도록 지원
  • 결과적으로 상호운용성 문제 감소, 개발 속도 향상, 혁신 가속화가 기대됨
    • 이는 협업 소프트웨어 전반의 표준화와 효율성 향상을 촉진하는 계기

클라이언트 지원과 생태계 확장

  • Stalwart는 현재 JMAP 전체 프로토콜군을 완전 지원하는 최초의 서버로, 클라이언트 지원은 아직 초기 단계
  • 그러나 이미 여러 프로젝트가 새로운 표준을 채택 중
    • Mailtemi, Parula, OpenCloud 등이 JMAP Calendars, Contacts, File Storage 클라이언트를 개발 중
  • 생태계는 빠르게 성장 중이며, 개발자들이 JMAP의 우아함과 강력함을 직접 경험함에 따라 급속한 확산이 예상됨
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 내가 보기엔 Stalwart는 훌륭한 JMAP 서버임
    JMAP은 이메일 클라이언트를 만들기에 아주 좋은 프로토콜이라고 생각함
    직접 호스팅은 피하고 싶지만, Stalwart를 클라이언트의 서버 컴포넌트로 써서 기존 IMAP 데이터를 동기화하고 JMAP API로 접근할 수 있다면 흥미로울 것 같음
    IMAP-IMAP 동기화 같은 방식이 가능하다고 들었는데, 혹시 Stalwart로 시도해본 사람이 있는지 궁금함
    이런 접근이 가능해지면 기존 IMAP 메일박스를 JMAP으로 접근할 수 있게 되어, 새로운 세대의 이메일 클라이언트 개발이 촉진될 것 같음
    • “excellent”라는 표현이 과장이 아님을 강조하고 싶음
      Stalwart는 정말 아름답게 구조화된 소프트웨어임
      신뢰를 쌓으며 점진적으로 완성도를 높여온 점이 인상적임
      게다가 거의 한 명의 개발자가 주도했다는 사실이 놀라움
      GitHub 기여자 그래프
    • IMAP ↔ IMAP 동기화 도구인 mbsync를 쓰면 간단히 구현 가능함
      원격 IMAP을 Stalwart의 로컬 IMAP 서버로 주기적으로 동기화하면, Stalwart가 내부적으로 이를 JMAP으로 변환해 제공함
      처음엔 maildir 단계를 거쳐야 할 줄 알았는데, IMAP ↔ IMAP만으로 충분히 가능해 보임
    • 이런 걸 오랫동안 기다려왔음
      지금까지 찾은 건 너무 비싸서, 이런 발전이 반가움
    • 나도 같은 이유로 고민 중이었음
      아직 결과물은 없지만 계속 생각 중임
  • “클라이언트가 없다”는 말을 많이 보는데, 당연히 서버 구현이 먼저 나와야 함
    Stalwart가 사실상 JMAP의 첫 서버 구현이라 이제 클라이언트를 만들 이유가 생긴 셈임
    참고로 Mozilla의 새 메일 서비스도 JMAP을 사용할 예정이라, 큰 추진력이 될 것 같음
    • Stalwart가 진짜 게임 체인저가 될 수도 있다고 생각함
      예전엔 Nextcloud나 SoGo 같은 그룹웨어를 써봤지만 실망스러웠음
      그런데 이제 Nextcloud가 Stalwart와 협력하고, Opencloud와 Mozilla/Thunderbird도 JMAP을 통합 중이라 기대됨
      특히 Thunderbird의 웹메일 프로젝트 Stormbox도 진행 중이라 흥미로움
      지금은 Big Tech에서 벗어나려는 흐름이 강해, 타이밍도 완벽함
    • 참고로 Stalwart는 JMAP의 연락처와 캘린더를 처음 구현한 서버임
      Cyrus는 JMAP 메일만 지원했음
    • FastMail은 이미 JMAP을 실서비스에 사용 중이며, RFC 공동 저자이기도 함
    • 최근 Pimsync에 JMAP 캘린더 동기화를 구현했음
      이제 CalDAV, JMAP, 파일시스템 간 동기화가 가능함
    • JMAP 클라이언트는 존재함
      나는 aerc라는 클라이언트를 사용 중임
  • JMAP은 웹 API 설계 측면에서 매력적이지만, 모든 새로운 프로토콜이 HTTP 위에서만 만들어져야 하는지는 의문임
    파일 공유, 그룹웨어, 메일, 캘린더 같은 건 JSON 오버헤드 없이 더 효율적으로 설계할 수도 있을 것 같음
    그래도 HTTP 기반 설계에는 분명 이유가 있겠지 싶음
    • 이메일은 원래 바이너리 프로토콜이 아니었음
      대부분의 초기 인터넷 프로토콜이 텍스트 기반 Telnet 위에서 만들어졌기 때문임
      HTTP/3는 본질적으로 바이너리 프로토콜이고, JSON은 구조적이고 압축 효율이 좋아서 실제로 꽤 효율적임
      “JSON over HTTP”는 “custom text over telnet”보다 미묘하지만 확실한 개선임
    • 직접 직렬화 포맷을 만들면 오히려 문제만 늘어남
      capnproto, grpc, ASN.1 같은 프레임워크를 써도 각각의 복잡함이 있음
      JSON은 단순하고 한계가 명확해서 다루기 쉬움
      반면 Microsoft Exchange 프로토콜처럼 구현에 종속된 설계는 장기적으로 문제를 낳음
    • HTTP 위에 얹는 게 항상 좋은 건 아님
      경우에 따라 TCP가 아닌 다른 프로토콜이 더 나을 수도 있음
      개인적으로 JSON은 싫고, DER 포맷이 더 낫다고 생각함
      Gemini, Scorpion 같은 “small web” 프로토콜도 흥미로움
    • 이메일을 HTTP로 가져오는 데 드는 오버헤드는 크지 않음
      오히려 웹 클라이언트 호환성 측면에서 HTTP가 유일한 선택임
      HTTP를 안 쓰는 이점은 거의 없다고 봄
    • HTTP/2, HTTP/3는 이미 바이너리 프로토콜임
      JSON 대신 CBOR을 쓰면 페이로드도 바이너리화 가능함
      HTTP는 상태 전송(state transfer) 프로토콜이라 동기화에 적합함
      여기에 Braid 확장을 추가하면 상태 동기화(state synchronization) 프로토콜로 확장 가능함
      나는 Braid 프로젝트에서 일하고 있음
  • Fastmail이 JMAP의 캘린더와 연락처 부분을 빨리 구현하길 바람
    메일은 이미 지원하지만, 아직 CardDAV/CalDAV를 병행해야 함
    • 현재 내부적으로 오래된 JMAP 버전을 사용 중임
      10년 전 작성한 caldav_sync 코드가 아직 돌아가고 있음
      최근에는 objectid 생성 로직을 개선해 ID 크기를 줄이고 정렬성을 높였음
      이제 최신 JMAP 스펙으로 캘린더와 연락처를 업데이트할 예정임
      파일 시스템은 시간이 좀 더 걸릴 듯함
    • JMAP Calendar 스펙은 아직 정식 승인되지 않음
      초안 문서 참고
      Contacts는 RFC 9610으로 10개월 전에 승인됨
    • Thunderbird, K-9 Mail, iPhone 메일 앱 등 주요 클라이언트가 지원하지 않으면 JMAP은 확산되기 어려움
      기존 솔루션 대비 어떤 문제를 해결하는지도 명확하지 않음
  • JMAP은 좋은 프로토콜이지만 클라이언트 지원이 부족함
    Apple Mail, Thunderbird, Outlook 같은 주요 클라이언트가 지원해야 함
    Canary나 Spark 같은 소규모 클라이언트가 차별화 포인트로 도입해도 좋을 텐데 의외로 안 함
    • Outlook은 이미 MS365 전용으로 바뀌는 중임
      새 Outlook은 모든 데이터를 Azure에 저장하고, 실제 서버와는 프록시로 통신함
      JMAP을 지원할 가능성은 거의 없음
    • JMAP은 웹메일 같은 얇은 클라이언트에는 좋지만, 로컬 상태를 저장하는 데스크톱 앱에는 큰 이점이 없음
    • 주요 메일 제공자가 지원하지 않으면 JMAP의 차별점이 약함
      (IMAP을 옹호하는 건 아님)
    • 서버 지원이 먼저 필요함
      Gmail이나 iCloud가 지원하지 않으면 클라이언트를 만들어도 의미가 적음
      듀얼 지원은 가능하겠지만, 시장이 좁음
    • JMAP이 성공하려면 메일뿐 아니라 캘린더, 연락처, 파일 공유 등 통합 그룹웨어 프로토콜로 발전해야 함
      하지만 그건 아직 많은 “if”가 남은 이야기임
  • Stalwart 덕분에 이메일 셀프호스팅이 훨씬 쉬워졌음
    완전 통합형 서버라 새로운 시대가 열린 느낌임
    Maddy도 괜찮지만 유지보수는 덜 활발함
    • 나도 Maddy+Postfix+Dovecot+Rspamd 조합에서 Stalwart로 옮기는 중인데, 문서 품질이 부족하다고 느낌
      옵션과 기본값, 상호 관계를 한눈에 볼 수 있는 문서가 없음
      Web UI 설정은 가능하지만 선언적 배포와 충돌함
      .toml 파일이 읽기 전용이면 오류가 발생함
    • 쓸만한 JMAP 웹메일 클라이언트가 있는지 궁금함
      FastMail이나 Topicbox 외에는 마땅한 게 없음
      Roundcube나 Wildduck처럼 HTTPS로 셀프호스팅 가능한 게 필요함
    • Postfix+Dovecot 대비 실질적 이점이 있는지 모르겠음
      “Rust로 새로 썼다” 외에는 뚜렷한 차별점이 없어 보임
  • Sieve를 JSON 기반으로 대체하려는 건 아닌지 걱정됨
    좋은 MUA(메일 클라이언트)가 없는 상황에서 JMAP이 도움이 될지 의문임
    서버는 이미 해결된 문제지만, 클라이언트는 정체되어 있음
    IMAP4의 기능조차 대부분 구현되지 않았고, Sieve 클라이언트도 형편없음
    • “서버는 해결된 문제”라는 말엔 동의하지 않음
      Dovecot은 아직 UTF-8도 완벽히 지원하지 않음
      Stalwart 같은 프로젝트가 이런 레거시 한계를 극복하려는 시도임
      클라이언트도 Apple Mail처럼 발전한 사례가 있음
    • 결국 서버와 클라이언트 둘 다 필요함
      둘 중 하나만 발전해선 의미가 없음
      이제 좋은 서버가 생겼으니, 남은 건 좋은 클라이언트임
  • Google Workspace나 Outlook 환경에서 JMAP 스타일의 JSON API를 원한다면 Nylas가 대안이 될 수 있음
    Nylas는 강력하지만 가격이 높음
    대규모에서는 계정당 월 $1.50이라 SaaS 마진에 영향을 줄 수 있음
    그래도 실시간 이메일 분석이나 커스텀 UI 구축에는 매우 유용함
  • Stalwart를 설치해봤는데, 웹서버와 메일서버가 통합되어
답변달기