ActivityPub이 평범한 웹 기술로 살아남은 이유

ActivityPub이 평범한 웹 기술로 살아남은 이유

IT & AI 뉴스 썸네일

ActivityPub은 HTTP 요청, URL, JSON 객체처럼 웹 개발자에게 익숙한 재료로 서로 다른 소셜 서비스를 연결해요. 구현 장벽을 낮춘 단순한 구조가 Mastodon과 PeerTube, Lemmy 같은 제품이 각자의 기능을 유지한 채 소셜 그래프를 공유하는 바탕이 됐어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
연합 구조	서버가 원격 inbox로 활동을 보내요	서비스마다 제품 구조를 통일하지 않아도 연결할 수 있어요
구현 방식	HTTP·URL·JSON을 그대로 활용해요	기존 웹 개발 경험과 도구를 재사용할 수 있어요
남은 부채	오래된 서명 초안과 암호화 부재가 남았어요	운영자가 인증과 신뢰 경계를 직접 설계해야 해요
운영 정책	각 서버가 다른 서버와의 연결을 끊을 수 있어요	개방성과 콘텐츠 중재를 함께 다뤄야 해요
다음 단계	하위 호환 개정과 계정 이동 규격을 검토해요	기존 사용자의 소셜 그래프를 깨지 않고 개선해야 해요

1. 연합형 소셜은 익숙한 웹 구성요소로 움직여요

ActivityPub은 클라이언트와 서버 사이의 API, 서버끼리 연결하는 연합 프로토콜을 정의해요. 실제 페디버스에서는 서버 간 연합이 중심이에요. 사용자나 서비스 같은 행위자는 inbox와 outbox를 가지고, 서버는 상대 서버의 inbox URL에 활동 객체를 POST 방식으로 보내요. 행위자 문서와 게시물, 컬렉션도 URL로 가져와요. 2

게시물보다 사회적 행위를 전달해요

활동 객체는 주어·동사·목적어를 가진 문장과 비슷해요. 누군가 글을 만들고, 다른 사용자를 팔로우하고, 게시물을 공유하거나 차단을 취소하는 행동을 객체로 표현해요. 서버 사이에는 콘텐츠와 함께 그 콘텐츠를 둘러싼 반응과 관계가 전달돼요.

728x90

이 최소 합의 덕분에 참여 서비스가 데이터베이스나 화면, 가입 정책, 추천 순위까지 맞출 필요는 없어요. Mastodon은 마이크로 블로그로, PeerTube는 동영상 서비스로 남을 수 있어요. 서로 다른 제품이 같은 사회적 관계망에 참여하는 데 필요한 교환 형식만 맞추는 방식이에요. 2

배포된 네트워크는 오래된 인증 방식도 품고 있어요

단순한 전송 구조가 모든 문제를 없애지는 못했어요. 많은 서버가 만료된 `draft-cavage-http-signatures-12`를 기준으로 요청 서명을 구현했어요. IETF가 2024년에 발행한 RFC 9421 HTTP Message Signatures는 설계가 달라요. 이미 작동 중인 서버를 한꺼번에 바꾸기 어려워 설치 기반과 최신 표준 사이에 간격이 생겼어요. 2

수신자를 지정하고 비공개 객체 요청을 거부하는 접근 제어는 가능해요. 종단 간 암호화는 기본으로 제공하지 않아요. 콘텐츠를 저장한 인스턴스의 관리자와 백업, 객체 저장소, 로그, 검색 인덱스가 신뢰 범위에 들어갈 수 있어요. 자체 서버를 운영할 때도 데이터가 실제로 머무는 모든 경로를 점검해야 해요.

개방형 네트워크에서는 운영 정책도 호환성의 일부예요

누구나 서버를 열 수 있으므로 악성 서버나 스팸을 다루는 방식도 필요해요. 페디버스 운영자는 한 서버가 다른 서버와의 연결을 끊는 디페더레이션을 사용해요. 차단 기준은 중앙 조직이 정하지 않아요. 각 커뮤니티가 정책을 세우고 공유 차단 목록이나 운영자 간 경고를 참고해 판단해요.

프로토콜은 활동 객체의 전달법을 정할 수 있지만 어떤 표현과 운영 관행을 허용할지는 정하지 않아요. 서버마다 다른 중재 기준이 연합 관계에 직접 영향을 줘요. 기술 명세만 구현한다고 운영 호환성까지 자동으로 생기지는 않아요. 1

왜 중요한가요

ActivityPub의 사례는 여러 제품을 연결할 때 합의 범위를 어디까지 줄일지 보여줘요. 공통 데이터베이스나 화면을 강제하지 않고 행위자, 객체, 활동의 교환 규칙만 맞췄기 때문에 100개가 넘는 구현체가 생길 수 있었어요. 새 연합형 서비스를 만드는 팀이라면 전체 제품 모델보다 외부로 교환할 식별자와 행위부터 설계할 수 있어요. 2

규모가 커질수록 하위 호환 비용도 함께 커져요. W3C Social Web Working Group은 기존 구현을 깨지 않는 문서 개정을 추진하고 있어요. 계정 이동 규격 LOLA처럼 신원과 소셜 그래프를 옮기는 작업도 검토 대상이에요. 서명, 개인정보 보호, 콘텐츠 중재를 개선하면서 기존 네트워크를 유지해야 해 전면 재작성보다 점진적 협의가 현실적인 경로예요. 2

대형 플랫폼 참여도 시험대예요. Threads 같은 상용 서비스가 연합에 들어오면 이용자는 더 넓은 네트워크와 연결될 수 있어요. 동시에 대형 플랫폼의 독점 기능과 배포 규모가 사실상의 표준을 만들 수도 있어요. 독립 서버가 동등한 참여자로 남으려면 계정 이동, 검색, 중재, 신뢰 모델의 개방형 구현이 먼저 실제 서비스에서 작동해야 해요.

참고 자료

1. ActivityPub은 지루했기에 승리했다 — GeekNews
2. ActivityPub Won by Being Boring — Owl Owl OÜ
3. ActivityPub Recommendation — W3C
4. HTTP Message Signatures — IETF