AI가 ‘도구’가 아니라 ‘팀원’이 되는 회사 (Buzz)

잭 도시의 Block이 공개한 협업 플랫폼 ‘Buzz’가 보여주는 미래

우리는 이미 업무에서 인공지능을 사용하고 있다.

메일을 정리하고, 문서를 요약하고, 코드를 작성하고, 회의 내용을 정리한다. 그러나 현재의 AI는 대부분 업무를 돕는 보조 도구에 머물러 있다.

사람이 AI에게 질문한다.
AI가 답변을 만든다.
그리고 실제 업무는 다시 사람이 처리한다.

하지만 AI가 단순히 질문에 답하는 도구가 아니라, 프로젝트에 직접 참여하는 팀원이라면 어떨까?

AI가 팀 채팅방에 들어오고, 과거 대화를 검색하고, 코드를 수정하고, 테스트를 실행하고, 리뷰를 요청한다. 사람은 AI가 수행한 작업을 확인하고 승인한다.

2026년 7월, 잭 도시가 이끄는 Block이 공개한 오픈소스 협업 플랫폼 Buzz는 바로 이런 업무 환경을 지향한다.

Buzz를 한 문장으로 표현하면 다음과 같다.

Slack의 팀 대화, GitHub의 코드 관리, CI/CD 자동화, 사내 검색, AI 에이전트를 하나로 통합한 업무 플랫폼

단순히 여러 서비스를 한 화면에 모은 제품은 아니다.

Buzz가 던지는 더 중요한 질문은 이것이다.

AI는 앞으로 회사에서 어떤 지위로 일하게 될 것인가?

---

흩어진 업무 도구를 하나로 연결하다

현재 대부분의 개발 조직은 여러 개의 서비스를 동시에 사용한다.

Slack이나 Microsoft Teams에서 대화하고, GitHub에서 코드를 관리한다. GitHub Actions나 Jenkins로 테스트와 배포를 자동화하고, Notion이나 Confluence에 문서를 정리한다.

AI 코딩 도구도 별도로 사용한다.

하나의 프로젝트를 진행하지만 업무 기록은 여러 공간에 흩어진다.

팀원이 Slack에서 기능 개발 방향을 논의한다. 개발자는 GitHub에 코드를 올린다. 테스트 결과는 다른 자동화 도구에 저장된다. 왜 이런 결정을 내렸는지는 문서나 과거 메시지를 다시 찾아야 한다.

시간이 지나면 코드 자체는 남지만, 그 코드가 만들어진 배경은 쉽게 사라진다.

Buzz는 이 모든 활동을 하나의 업무 공간에서 연결하려 한다.

• 팀 대화
• 프로젝트 채널
• 코드 저장소
• 코드 변경과 리뷰
• 자동화 워크플로
• AI 에이전트의 작업
• 검색과 감사 기록

사람과 AI가 같은 공간에서 대화하고, 작업하고, 결과를 남기는 구조다.

---

AI 에이전트를 정식 팀원처럼 다룬다

Buzz에서 가장 눈에 띄는 개념은 AI 에이전트의 위치다.

일반적인 협업 서비스에서 AI는 대개 채팅방에 연결된 봇이다. 질문을 받으면 답변하거나, 특정 명령을 실행하는 정도다.

Buzz는 AI 에이전트를 조금 다르게 다룬다.

사람과 마찬가지로 AI 에이전트도 고유한 신원과 암호화 키를 가질 수 있다. 참여할 수 있는 채널과 접근할 수 있는 프로젝트가 정해지고, 어떤 작업을 수행했는지 활동 기록이 남는다.

예를 들어 버그 수정 에이전트는 다음과 같은 과정을 처리할 수 있다.

1. 팀 채널에 등록된 오류 내용을 확인한다.
2. 관련 프로젝트의 과거 대화를 검색한다.
3. 코드 저장소를 분석한다.
4. 수정 코드를 작성한다.
5. 테스트를 실행한다.
6. 수정안을 제출한다.
7. 사람 개발자에게 리뷰를 요청한다.

중요한 점은 AI가 모든 회사 정보에 자유롭게 접근하는 것이 아니라는 것이다.

AI 에이전트도 사람과 마찬가지로 허용된 채널과 저장소에만 접근하도록 구성할 수 있다. 특정 프로젝트에 참여시키고 싶다면 해당 에이전트를 프로젝트 채널에 초대하는 방식이다.

이는 AI를 단순한 기능이 아니라 권한과 책임 범위를 가진 업무 주체로 취급하는 접근이다.

---

Git 브랜치 하나가 프로젝트 채팅방이 된다

Buzz가 제시하는 흥미로운 방식 가운데 하나는 Git 브랜치와 채팅 채널을 연결하는 것이다.

개발자가 새로운 기능을 만들기 위해 브랜치를 생성하면, 해당 브랜치 전용 프로젝트 채널을 만들 수 있다.

예를 들어 결제 기능을 개발한다고 해보자.

feature/payment-api라는 브랜치가 만들어지면 관련 채널에서 다음 활동이 함께 진행된다.

• 기능 요구사항 논의
• 코드 변경
• AI 에이전트의 분석
• 테스트 결과
• 코드 리뷰
• 수정 요청
• 최종 승인
• 병합 결정

기존 환경에서는 이 정보가 Slack, GitHub Pull Request, 자동화 로그 등에 나뉘어 저장된다.

Buzz에서는 코드와 대화가 같은 프로젝트 흐름 안에 들어간다.

나중에 문제가 발생했을 때 단순히 “어떤 코드가 변경됐는가”만 보는 것이 아니라, “왜 이 코드를 변경했는가”까지 확인할 수 있다.

AI 에이전트 입장에서도 큰 차이가 생긴다.

코드만 읽는 것이 아니라 코드가 작성된 배경, 관련 대화, 테스트 결과, 리뷰 의견을 함께 이해할 수 있기 때문이다.

---

대화와 코드가 하나의 조직 기억이 된다

기업이 AI를 업무에 적용할 때 가장 어려운 문제 중 하나는 정보가 분산돼 있다는 것이다.

AI가 제대로 답변하려면 여러 장소에서 자료를 가져와야 한다.

• Slack의 대화
• GitHub의 코드
• Notion의 문서
• Jira의 이슈
• CI/CD 테스트 기록

각 서비스의 데이터를 수집하고, 검색 시스템에 넣고, 서로 연결해야 한다.

Buzz는 처음부터 대화와 코드 활동을 같은 이벤트 구조로 저장하는 방향을 택했다.

팀 메시지, 코드 변경, 리뷰 승인, 워크플로 실행, AI 작업 등이 하나의 연속된 기록으로 남는다.

예를 들어 서비스 장애가 발생했을 때 AI에게 이렇게 물을 수 있다.

이 오류가 과거에도 발생한 적이 있는가?

AI는 단순히 문서에서 비슷한 문장을 찾는 데 그치지 않는다.

과거의 장애 대화, 당시 수정된 코드, 테스트 결과, 작업한 사람, 재발 방지 조치까지 함께 찾아낼 수 있다.

이렇게 축적된 기록은 회사의 조직 기억이 된다.

사람이 퇴사하거나 담당자가 바뀌어도 프로젝트가 어떤 과정을 거쳐 현재 모습이 됐는지 추적할 수 있다.

---

모든 작업에 서명이 붙는다

Buzz는 Nostr 프로토콜의 이벤트 구조를 활용한다.

메시지 작성, 코드 변경, 리뷰 승인, 워크플로 실행과 같은 활동이 이벤트로 기록되고, 각 이벤트에는 작업을 수행한 주체의 암호화 서명이 붙는다.

이를 통해 다음 내용을 확인할 수 있다.

• 누가 작업했는가
• 사람인가, AI 에이전트인가
• 어떤 권한으로 작업했는가
• 어떤 요청에서 작업이 시작됐는가
• 어떤 코드가 변경됐는가
• 누가 검토하고 승인했는가

AI가 실제 코드를 수정하고 업무를 수행하는 환경에서는 결과만큼이나 과정이 중요하다.

AI가 어떤 정보를 참고했는지, 어떤 권한을 사용했는지, 최종적으로 누가 승인했는지가 명확하게 남아야 한다.

Buzz는 AI 에이전트 시대의 협업에서 감사 가능성과 책임 추적이 중요한 요소가 될 것임을 보여준다.

---

정말 탈중앙화된 플랫폼일까

Buzz는 오픈소스와 자기주권적인 운영 방식을 강조한다.

기업이나 조직은 Buzz를 자신의 서버에 설치할 수 있다. 대화, 코드, 파일과 같은 데이터를 외부 SaaS 기업에 맡기지 않고 직접 관리하는 것도 가능하다.

그러나 이를 완전한 P2P 탈중앙 네트워크로 이해해서는 안 된다.

현재 Buzz의 각 커뮤니티는 하나의 중앙 릴레이 서버를 중심으로 작동한다. 사용자의 읽기와 쓰기, 검색, 이벤트 처리도 해당 릴레이가 담당한다.

릴레이끼리 데이터를 자동으로 교환하거나 복제하는 완전한 분산형 구조는 아니다.

따라서 Buzz가 말하는 탈중앙화는 다음 의미에 더 가깝다.

• 특정 SaaS 기업에 종속되지 않는다.
• 조직이 자체 서버를 운영할 수 있다.
• 조직이 자신의 데이터와 도메인을 소유한다.
• 사용자가 암호화 신원을 사용할 수 있다.
• 소스 코드가 공개돼 있다.

즉, 시스템 내부가 완전히 탈중앙화돼 있다기보다, 여러 조직이 각자의 서버를 소유할 수 있는 분산 배포형 오픈소스 플랫폼에 가깝다.

---

아직은 완성된 기업용 제품이 아니다

Buzz는 흥미로운 비전을 제시하지만, 현재는 개발 단계에 있는 프로젝트다.

팀 채널, 개인 메시지, 공동 캔버스, 검색, 감사 로그, 데스크톱 앱, Git 호스팅, 워크플로와 같은 기능은 구현돼 있다.

반면 모바일 앱, 푸시 알림, 일부 승인 워크플로와 고급 에이전트 기능은 계속 개발되고 있다.

Slack, GitHub, Notion, Jenkins처럼 오랫동안 검증된 서비스를 한 번에 대체할 만큼 안정적인지는 아직 확인이 필요하다.

자체 호스팅 방식에도 책임이 따른다.

조직은 직접 서버를 운영하고, 보안을 관리하고, 데이터를 백업하고, 장애와 업데이트에 대응해야 한다.

오픈소스라는 이유만으로 운영 비용과 관리 부담까지 사라지는 것은 아니다.

---

Buzz가 보여주는 것은 제품보다 조직의 변화다

[Inference] Buzz의 의미는 단순히 새로운 협업 서비스 하나가 등장했다는 데 있지 않다.

더 중요한 변화는 AI를 바라보는 관점에 있다.

현재 기업은 AI를 직원이 사용하는 도구로 본다.

직원
→ AI에게 질문
→ AI가 답변
→ 직원이 실제 업무 수행

Buzz가 지향하는 구조에서는 AI가 업무 과정 안으로 직접 들어온다.

사람과 AI가 같은 프로젝트에 참여
→ AI가 대화와 코드를 확인
→ AI가 작업 수행
→ 사람이 검토하고 승인
→ 전체 과정이 기록으로 보존

[Inference] 앞으로의 회사에서는 AI가 단순히 생산성을 높이는 프로그램이 아니라, 특정 역할을 맡아 반복적으로 일하는 디지털 구성원이 될 가능성이 있다.

한 AI는 버그를 분석하고, 다른 AI는 코드를 리뷰할 수 있다. 또 다른 AI는 문서를 정리하고 프로젝트 진행 상황을 요약할 수 있다.

사람은 모든 작업을 직접 처리하기보다, 목표와 권한을 설정하고 결과를 검토하는 역할로 이동할 수 있다.

이때 회사에 필요한 것은 더 강력한 챗봇 하나가 아니다.

AI가 어떤 정보에 접근할 수 있는지, 어떤 행동을 할 수 있는지, 누가 결과를 승인하는지 관리할 수 있는 새로운 업무 시스템이다.

Buzz는 바로 그 문제를 먼저 설계하려는 시도다.

---

AI 시대의 협업 도구가 갖춰야 할 조건

[Inference] Buzz의 구조를 통해 앞으로의 AI 협업 플랫폼에 필요한 조건을 정리해볼 수 있다.

첫째, AI 에이전트마다 독립적인 신원이 필요하다.

여러 AI가 같은 계정과 권한을 공유하면 어떤 에이전트가 어떤 작업을 했는지 구분하기 어렵다.

둘째, 최소 권한 원칙이 필요하다.

AI가 필요 이상의 대화와 코드에 접근하지 못하도록 프로젝트 단위의 권한을 부여해야 한다.

셋째, 모든 실행 과정이 기록돼야 한다.

AI가 어떤 요청을 받고, 어떤 자료를 참고하고, 무엇을 변경했는지 추적할 수 있어야 한다.

넷째, 중요한 작업에는 사람의 승인이 남아야 한다.

AI가 작업을 수행하더라도 배포, 결제, 데이터 삭제처럼 위험도가 높은 행동은 사람이 검토하는 구조가 필요하다.

다섯째, 대화와 실행 기록이 분리되지 않아야 한다.

AI가 업무 맥락을 이해하려면 코드뿐 아니라 그 코드가 만들어진 이유까지 볼 수 있어야 한다.

---

AI 팀원이 출근하는 시대

Buzz가 성공적으로 정착할지는 아직 알 수 없다.

기존 협업 도구를 대체하기에는 부족한 기능이 있고, 자체 서버 운영에 따른 부담도 존재한다. Block 내부에서 효과적으로 사용되더라도 다른 기업에서도 같은 방식이 통할지는 더 지켜봐야 한다.

그러나 Buzz가 던진 문제는 분명하다.

AI가 실제 업무를 수행하기 시작하면 회사는 더 이상 AI를 단순한 플러그인이나 채팅 기능으로만 관리할 수 없다.

AI에게도 신원이 필요하고, 권한이 필요하며, 활동 기록과 책임 범위가 필요하다.

사람과 AI가 함께 일하는 회사는 단순히 기존 업무 도구에 AI 버튼 하나를 추가한 모습이 아닐 가능성이 크다.

대화, 코드, 권한, 실행, 승인, 기록이 모두 연결된 새로운 업무 환경이 필요하다.

Buzz는 그 미래를 완성한 제품은 아니다.

하지만 AI가 도구의 자리를 넘어 팀원의 자리로 이동할 때 회사의 운영체제는 어떻게 바뀌어야 하는가라는 질문을 가장 구체적으로 보여주는 사례 중 하나다.

Buzz — Your people, your agents, your project — all in one place.