# 캘린더, 연락처, 파일용 JMAP이 Stalwart에 추가됨 > Clean Markdown view of GeekNews topic #23867. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23867](https://news.hada.io/topic?id=23867) - GeekNews Markdown: [https://news.hada.io/topic/23867.md](https://news.hada.io/topic/23867.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-24T02:39:34+09:00 - Updated: 2025-10-24T02:39:34+09:00 - Original source: [stalw.art](https://stalw.art/blog/jmap-collaboration/) - Points: 4 - Comments: 2 ## Topic Body - 오픈소스 협업 서버 **Stalwart**가 4년간의 개발 끝에 **캘린더, 연락처, 파일 저장 및 공유용 JMAP**을 완전 구현하며 새로운 이정표를 달성 - 이번 릴리스로 Stalwart는 **JMAP 전체 프로토콜군을 완전 지원하는 최초의 서버**가 되었으며, 이메일을 넘어 협업 전반으로 확장된 통합 API를 제공 - **JSON 기반의 단일 프레임워크**를 통해 기존 WebDAV·CalDAV·CardDAV의 복잡성과 비효율을 대체하고, 개발자 친화적인 구조를 실현 - 새로운 **JSCalendar**와 **JSContact** 포맷은 iCalendar와 vCard의 복잡성을 제거하고, 명확하고 일관된 데이터 모델을 제공 - 이는 오픈 표준 기반 협업 기술의 진화를 상징하며, 향후 **캘린더링·파일 공유·메일 통합 생태계의 혁신 가속화**를 예고 --- ### 새로운 세대의 프로토콜 - 최근 몇 년간 **IETF**는 이메일, 캘린더, 연락처의 동기화 및 공유 방식을 재정의하고 있음 - 기존 **JMAP for Mail**의 성공을 기반으로, 캘린더·연락처·파일·공유용 확장 프로토콜이 새롭게 도입됨 - [JMAP for Calendars](https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars) - CalDAV 와 CalDAV 스케쥴링의 현대적인 대체제 - [JMAP for Contacts](https://datatracker.ietf.org/doc/rfc9610/) – CardDAV의 강력한 대체제 - [JMAP for File Storage](https://datatracker.ietf.org/doc/draft-ietf-jmap-filenode/) – WebDAV 기반 파일 저장소를 대체 - [JMAP Sharing](https://datatracker.ietf.org/doc/rfc9670/) – WebDAV ACL의 현대적인 후계자 - [JSCalendar](https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendarbis/) - 깔끔한 JSON 기반으로 진화한 iCalendar - [JSContact](https://datatracker.ietf.org/doc/rfc9553/) – 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의 **우아함과 강력함**을 직접 경험함에 따라 **급속한 확산**이 예상됨 ## Comments ### Comment 45402 - Author: t7vonn - Created: 2025-10-24T11:21:43+09:00 - Points: 1 좋네요!! ### Comment 45380 - Author: neo - Created: 2025-10-24T02:39:34+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45672336) - 내가 보기엔 **Stalwart**는 훌륭한 **JMAP 서버**임 JMAP은 이메일 클라이언트를 만들기에 아주 좋은 프로토콜이라고 생각함 직접 호스팅은 피하고 싶지만, Stalwart를 클라이언트의 서버 컴포넌트로 써서 기존 IMAP 데이터를 동기화하고 JMAP API로 접근할 수 있다면 흥미로울 것 같음 IMAP-IMAP 동기화 같은 방식이 가능하다고 들었는데, 혹시 Stalwart로 시도해본 사람이 있는지 궁금함 이런 접근이 가능해지면 기존 IMAP 메일박스를 JMAP으로 접근할 수 있게 되어, 새로운 세대의 이메일 클라이언트 개발이 촉진될 것 같음 - “excellent”라는 표현이 과장이 아님을 강조하고 싶음 Stalwart는 정말 **아름답게 구조화된 소프트웨어**임 신뢰를 쌓으며 점진적으로 완성도를 높여온 점이 인상적임 게다가 거의 **한 명의 개발자**가 주도했다는 사실이 놀라움 [GitHub 기여자 그래프](https://github.com/stalwartlabs/stalwart/graphs/contributors) - IMAP ↔ IMAP 동기화 도구인 [mbsync](https://isync.sourceforge.io/mbsync.html)를 쓰면 간단히 구현 가능함 원격 IMAP을 Stalwart의 로컬 IMAP 서버로 주기적으로 동기화하면, Stalwart가 내부적으로 이를 JMAP으로 변환해 제공함 처음엔 maildir 단계를 거쳐야 할 줄 알았는데, IMAP ↔ IMAP만으로 충분히 가능해 보임 - 이런 걸 오랫동안 기다려왔음 지금까지 찾은 건 너무 비싸서, 이런 발전이 반가움 - 나도 같은 이유로 고민 중이었음 아직 결과물은 없지만 계속 생각 중임 - “클라이언트가 없다”는 말을 많이 보는데, 당연히 **서버 구현이 먼저** 나와야 함 Stalwart가 사실상 JMAP의 첫 서버 구현이라 이제 클라이언트를 만들 이유가 생긴 셈임 참고로 Mozilla의 새 메일 서비스도 JMAP을 사용할 예정이라, 큰 **추진력**이 될 것 같음 - Stalwart가 진짜 **게임 체인저**가 될 수도 있다고 생각함 예전엔 Nextcloud나 SoGo 같은 그룹웨어를 써봤지만 실망스러웠음 그런데 이제 Nextcloud가 Stalwart와 협력하고, Opencloud와 Mozilla/Thunderbird도 JMAP을 통합 중이라 기대됨 특히 [Thunderbird의 웹메일 프로젝트 Stormbox](https://github.com/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 확장](https://braid.org)을 추가하면 **상태 동기화(state synchronization)** 프로토콜로 확장 가능함 나는 Braid 프로젝트에서 일하고 있음 - Fastmail이 JMAP의 **캘린더와 연락처** 부분을 빨리 구현하길 바람 메일은 이미 지원하지만, 아직 CardDAV/CalDAV를 병행해야 함 - 현재 내부적으로 오래된 JMAP 버전을 사용 중임 10년 전 작성한 caldav_sync 코드가 아직 돌아가고 있음 최근에는 **objectid 생성 로직**을 개선해 ID 크기를 줄이고 정렬성을 높였음 이제 최신 JMAP 스펙으로 캘린더와 연락처를 업데이트할 예정임 파일 시스템은 시간이 좀 더 걸릴 듯함 - JMAP Calendar 스펙은 아직 **정식 승인되지 않음** [초안 문서](https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/) 참고 Contacts는 [RFC 9610](https://www.rfc-editor.org/rfc/rfc9610.html)으로 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](https://www.nylas.com/)는 강력하지만 가격이 높음 대규모에서는 계정당 월 $1.50이라 SaaS 마진에 영향을 줄 수 있음 그래도 실시간 이메일 분석이나 커스텀 UI 구축에는 매우 유용함 - Stalwart를 설치해봤는데, **웹서버와 메일서버가 통합**되어