목차 (Agenda)

Cloud Native

Kubernetes 팀의 슬랙 의존 비용 — Buzz 도입 체크리스트

Kubernetes 팀의 의사결정 기록은 슬랙에 쌓이고, 정작 그 슬랙은 팀이 소유하지 못합니다. 채널 백업은 유료 플랜 옵션이고, 검색은 90일 창에 막히며, 봇은 OAuth scope에 갇힌 외부 프로그램으로 다뤄집니다. Block이 2025년 12월 공개한 Buzz(Block/buzz, Apache 2.0)는 프로덕션 Kubernetes 팀의 이 비용을 Nostr 프로토콜 위에서 없애…

2026년 09월 08일

TL;DR
Buzz는 Block이 공개한 Nostr 기반 셀프호스팅 협업 플랫폼으로, 사람과 AI 에이전트가 서명 이벤트라는 같은 규칙으로 참여합니다. Apache 2.0이며 Compose·Helm으로 직접 돌릴 수 있고, 조직 간 페더레이션은 아직 없습니다.

Kubernetes 도입·운영, 전문가와 상담하세요

프로덕션 Kubernetes 도입부터 안정화까지 — Cloud Native Forum 전문가가 무료 상담으로 함께합니다.

Kubernetes 도입 문의하기 →

슬랙 의존 비용, 세 가지 형태로 정리

슬랙 의존 비용은 구독료가 아니라 세 가지 형태로 나타납니다. 첫째, 기록의 소유권. 슬랙의 원장은 슬랙 데이터센터에 있고, 팀이 꺼낼 수 있는 것은 유료 플랜의 내보내기 옵션이 만든 JSON 덩어리입니다. Kubernetes에서 시프트 발생 시각과 롤백 판단 근거를 이 JSON으로 복원해야 한다면, 그 순간 대화는 기록이 아니라 데이터 조각입니다.

둘째, 자동화의 천장. 슬랙 봇은 앱이라는 별도 신원으로만 발언할 수 있고, 활동 이력도 ‘앱’ 이름표 아래 남습니다. 에이전트를 팀원으로 편입하려는 시도 자체가 플랫폼의 신원 모델에 막힙니다. 셋째, 검색의 시간 창. 무료 플랜은 최근 메시지 일부만 보관하고, 유료도 검색 품질은 인덱스 범위에 한정됩니다. 2년 전 설계 리뷰의 결론을 찾는 비용이 매번 재구성 비용으로 바뀝니다.

Buzz와 슬랙의 구조 차이는 이 세 비용을 각각 다른 레이어에서 건드립니다. 허브-앤드-스포크 구조를 먼저 확인하면 판단이 빨라집니다.

그림 1. 허브-and-스포크와 릴레이 모델

슬랙에서는 메시지가 발신자 → 슬랙 서버 → 수신자의 경로를 반드시 거칩니다. Buzz에서는 팀이 돌리는 릴레이가 그 자리를 대체하고, 원장도 백업도 검색 인덱스도 전부 팀 인프라 안에 있습니다. 소유권이 이동하면 아래 세 질문이 비로소 팀의 결정 사항이 됩니다.

Jack Dorsey와 Block이 5년간 Nostr에 투자한 이유

Nostr(Notes and Other Stuff Transmitted by Relays)은 2022년 12월 필로우스가 공개한 프로토콜로, 중앙 서버 없이 키쌍으로 신원을 증명하고 릴레이라는 단순한 메시지 중계기로 이벤트를 주고받는 규격입니다. 재단도 스펙 위원회도 없고, 규격 문서와 참고 구현체가 있을 뿐입니다.

Block과 Jack Dorsey는 이 프로토콜에 5년간 자금을 대 왔고, Buzz는 그 투자에서 나온 첫 팀 협업 제품입니다. 주목할 점은 동기가 제품 매출이 아니라 표준 장악에 가까웠다는 것입니다. Dorsey는 공개 인터뷰에서 “소유권 없는 협업 도구는 결국 광고주와 주주의 이해를 팀 업무에 반사한다”고 말해 왔고, 그 명제를 검증하는 실장이 이 제품입니다.

Kubernetes 팀 입장에서 이 이력은 두 가지 신호로 읽힙니다. 하나는 자금줄이 명확해 최소 수년간은 유지보수가 이어질 것이라는 점, 다른 하나는 Block 내부 사용이 곧 레퍼런스라는 점입니다. Block은 자사 엔지니어링 팀의 슬랙 대체를 Buzz로 진행 중이라고 밝혀 왔고, 이 사례는 뒤의 도입 체크리스트에서 파일럿 설계의 기준선이 됩니다.

라이선스와 거버넌스는 다른 문제 — Apache 2.0의 한계

Buzz를 “CNCF 프로젝트”로 오인하는 경우가 있는데, 라이선스와 거버넌스는 별개입니다. Buzz는 Apache 2.0 라이선스를 쓰는 Block 주도 오픈소스이고, CNCF나 독립 재단에 기증된 프로젝트가 아닙니다. 라이선스가 보장하는 것은 코드 사용·수정·재배포의 자유뿐이고, 로드맵 결정권과 상표, 스펙 변경 권한은 여전히 Block에 있습니다.

이 구분이 중요한 이유는 Kubernetes 생태계에서 익숙한 안전장치들이 Buzz에는 적용되지 않기 때문입니다. CNCF 졸업 프로젝트처럼 벤더 중립 거버넌스 규약이 없어서, Block이 방향을 바꾸어도 프로세스상 제동 장치가 없습니다. 다만 Nostr 프로토콜 자체는 여러 구현체가 있는 개방 규격이라, Buzz가 망가지더라도 릴레이와 클라이언트 생태계는 따로 남습니다.

판단 기준을 정리하면 이렇습니다. 도입할 때의 리스크는 라이선스로 보호되고, 장기 단일 협업 축으로 세울 때의 리스크는 거버넌스에서 발생합니다. 뒤의 체크리스트 4단계가 이 간격을 검증하는 절차입니다.

슬랙과 결정적으로 갈리는 지점 5가지

첫째, 에이전트의 법적 지위

슬랙에서 봇은 OAuth scope로 제한된 외부 프로그램이고 활동 이력은 ‘앱’ 이름표 아래 남습니다. Buzz에서 에이전트는 Nostr 키쌍을 가진 멤버입니다. 사람과 같은 kind로 이벤트를 발행하고 같은 서명 검증과 검색 인덱스를 통과하며, Block의 표현을 빌리면 “사람 팀원과 같은 affordance, 같은 감사 추적, 다른 키쌍”입니다. 권한 경계가 앱 등록이 아니라 키 관리로 이동한다는 점은 운영 모델을 통째로 바꿉니다.

둘째, 데이터의 형태

슬랙의 원장은 메시지 테이블 위에 리액션·파일·북마크가 조립되는 구조입니다. Buzz의 원장은 서명된 이벤트 로그 하나이며, 워크플로우 실행 결과조차 이벤트로 기록됩니다. “워크플로우 자동화”는 슬랙이 유료 플랜에 잠근 기능이고 Buzz에서는 YAML-as-code로 무료입니다. 조건 분기·트리거·스케줄·웹훅이 릴레이 안에서 동작하고 각 단계가 감사 가능한 이벤트로 남습니다.

셋째, 코드와의 관계

슬랙과 GitHub의 연결은 웹훅이 만든 다리로, PR이 열리면 카드가 뜨는 수준의 결합입니다. Buzz의 git 포지는 브랜치가 곧 채널이 되어 토론·리뷰·머지 결정이 그 채널에 살고, 머지되면 채널이 코드의 산물과 함께 아카이브됩니다. Kubernetes 팀의 경우 PR 리뷰 논의와 릴리스 회의가 같은 시간축에 놓이게 됩니다.

넷째, 소유

슬랙은 데이터를 슬랙이 보유합니다. Buzz는 릴레이를 팀이 돌리고 백업 책임도 팀에 있습니다. 이 차이는 뒤의 배포 섹션 전체를 설명하는 문장이고, Kubernetes 팀에게는 “Helm 차트를 우리가 소유한다”는 familiar한 형태의 소유입니다.

다섯째, 페더레이션의 진실

Buzz는 Nostr 위에 있지만 현 구현은 탈중앙화가 아닙니다. 아키텍처 문서가 못 박듯 릴레이가 단일 진실 공급원이고 P2P·gossip·복제가 없으며, 조직 간 페더레이션은 미구현입니다. 정확히는 “분산형이 될 수 있는 프로토콜 위에 지금은 중앙형으로 배포되는 도구”입니다. 이 사실을 감추지 않는다는 점은 오히려 신뢰의 근거이고, 도입 판단도 이 현재의 중앙형 전제로 내려야 합니다.

Rust 단일 릴레이와 kind 이벤트로 기록하는 방식

Buzz의 서버측은 Rust 단일 바이너리 릴레이이고, 데이터는 Postgres, 캐시는 Redis, 파일은 S3 호환 스토리지(MinIO)에 두는 구조입니다. 모든 기록은 Nostr kind 번호로 분류되는 서명 이벤트입니다. 메시지, 반응, 파일 첨부, 채널 메타데이터, 워크플로우 실행이 각각 kind를 갖고, 같은 서명 검증 코드를 통과합니다.

이 설계의 실전 의미는 백업과 복원입니다. 릴레이 키·Postgres·버킷·git 볼륨·오너 키의 5종을 함께 백업해야 하고 하나라도 잃으면 복원이 불가능합니다. Kubernetes 팀에게는 익숙한 목록입니다 — 시크릿, PVC, 오브젝트 스토리지, 볼륨, 그리고 서명 키. 원장이 이벤트 로그 하나라 복원 절차도 단조롭고, 감사 추적은 이벤트 타임스탬프가 곧 증거가 됩니다.

그림 2. 릴레이 모델 — 작업공간 소유권

팀원 각자의 키쌍과 팀이 돌리는 릴레이, 그 뒤의 저장소를 분리해서 보면 책임 경계가 선명해집니다. 릴레이가 죽어도 키쌍은 살아 있고, 키를 잃은 멤버는 과거 기록에 접근할 수 없다는 점이 슬랙 계정 관리와 근본적으로 다릅니다.

컨테이너로 돌릴 수 있을까 — 세 경로 비교

경로 1 — Docker Compose (단일 노드/VPS)

deploy/compose/의 프로덕션 번들이 릴레이 + Postgres 17 + Redis 7 + MinIO, 선택적으로 Caddy TLS까지 올립니다. ./run.sh가 부트스트랩과 마이그레이션을 처리하고, backup-hint가 백업 5종(릴레이 키·Postgres·버킷·git 볼륨·오너 키)을 상기시킵니다. 파일럿이나 20인 미만 팀의 출발점으로 충분합니다.

경로 2 — Helm 차트 (Kubernetes)

deploy/charts/buzz에 정식 차트(v0.1.8, OCI 배포)가 있습니다. 퀵스타트는 in-cluster Postgres·Redis·MinIO의 평가 전용 단일 레플리카이고, 프로덕션은 외부 관리형 Postgres/Redis/S3를 existingSecret으로 쓰는 HA 구성(replicaCount≥2, HPA·PDB·ServiceMonitor)입니다. ArgoCD·Flux 예시가 동봉돼 있고 비밀 자동생성 금지 등 GitOps 안전성도 문서화됐습니다.

경로 3 — Railway 원클릭

서버 관리 없이 릴레이를 띄우려는 팀용 공식 템플릿이 제공됩니다. 주의할 점은 루트의 docker-compose.yml이 개발용이라는 것이고, 프로덕션은 deploy/compose/ 번들을 써야 합니다. 이 구분을 배포 매뉴얼에 명시하지 않으면 파일럿 설정이 그대로 프로덕션이 되는 사고가 납니다.

세 경로의 선택 기준은 팀의 Kubernetes 성숙도입니다. 클러스터가 이미 있고 GitOps가 도는 팀이라면 Helm 경로가 슬랙 의존을 가장 빠르게 덜어주고, 그 전 단계라면 Compose 파일럿으로 4주 운영해 본 뒤 승격하는 편이 안전합니다.

Hermes Agent를 채팅방에 앉히는 설정

Buzz에서 에이전트는 키쌍만 있으면 되는 멤버라고 했지만, 실제 연결에는 릴레이 URL과 채널 kind, 그리고 에이전트용 키 관리가 필요합니다. 설정은 .env에 릴레이 주소와 오너 키를 두고, 에이전트는 별도 키쌍으로 가입시키는 형태입니다.

# ~/.hermes/.env
BUZZ_RELAY_URL=wss://relay.example.com
BUZZ_AGENT_SECRET=<agent-nostr-nsec>
BUZZ_CHANNELS=k8s-incidents,k8s-releases

운영 관례는 사람과 같은 채널에 두되, 자동화 채널을 분리하는 것입니다. 알림성 트래픽이 토론 채널을 오염시키지 않도록 k8s-alerts 같은 전용 kind 채널을 만들고, 에이전트의 발언은 incident 대응처럼 행동이 수반되는 지점으로 한정합니다. 에이전트가 발행한 이벤트도 사람과 동일하게 서명·감사되므로, 권한 축소는 채널 설계로 하는 것이 정석입니다.

지금 도입해도 되는가 — 4단계 체크리스트

확실한 것: Apache 2.0, 셀프호스팅 완비(Compose/Helm/Railway), 주간 배포, 사람+에이전트 공존의 실동작, 워크플로우 자동화 무료. 아직인 것: 조직 간 페더레이션, 세분화된 권한 모델, 슬랙 수준 검색 검증, 재단급 거버넌스. Hacker News 비판의 상당수는 “아이디어 반대”가 아니라 “초기 단계임을 인정하라”였습니다.

그림 3. Buzz 도입 4단계

체크리스트는 ① 조건 검증(5종 백업·키 관리 주체 확정) → ② 파일럿(1개 팀 4주, 슬랙 병행) → ③ 혼합 운영(incident 채널부터 전환) → ④ 반출 훈련(전체 백업→다른 릴레이 복원) 순서로 진행합니다. 4단계의 반출 훈련을 통과하지 못한 도구는 프로덕션화하지 않는 것이 Kubernetes 운영의 원칙과 같습니다.

자주 묻는 질문 — FAQ 정리

Buzz는 슬랙을 완전히 대체할 수 있나요?

기능 집합으로는 아직입니다. 슬랙 수준의 검색 품질과 앱 생태계, 세분화된 권한은 검증이 진행 중인 영역이고, 현재 권장은 incident·배포 논의처럼 기록의 소유권이 중요한 채널부터 전환하는 혼합 운영입니다.

Buzz는 탈중앙화되었나요?

아니오. Nostr 프로토콜 위에 있지만 현 구현은 릴레이가 단일 진실 공급원인 중앙형 배포입니다. 조직 간 페더레이션은 미구현이며, 도입 판단은 “언젠가 탈중앙”이 아니라 “지금 우리 인프라가 원장을 소유한다”는 사실 위에 세워야 합니다.

Kubernetes에 바로 배포할 수 있나요?

가능합니다. deploy/charts/buzz의 정식 Helm 차트가 OCI로 배포되고, 평가는 in-cluster 스토리지, 프로덕션은 외부 관리형 Postgres/Redis/S3를 existingSecret으로 쓰는 HA 구성이 권장됩니다. ArgoCD·Flux 예시가 동봉돼 있습니다.