잭 도시의 새로운 야심작 'Buzz'… AI 에이전트와 Git을 결합한 새로운 협업 툴

Slack이 프로토콜을 열지 않으면 결국 대체될 것임. 에이전트가 각자 제어 가능한 ID로 활동하는 세상이 와야 함.

모든 봇 통합은 반쪽짜리임. 제대로 할 사람은 분명히 있는데, 그게 잭 도시일지 모르겠음.

GitHub을 엉망진창으로 만들 것 같음.

왜 돈 많은 사람들이 사회적 관계 툴만 계속 리믹스하는지 모르겠음. 광고하기 좋아서 그런가?

Slack의 책임은 아니지만, 대응 안 하면 취약점이 될 것임.

Slack이 AI와 협력하지 않으면 도태될 것임. 하지만 매번 최신 유행을 쫓는 게 자원 낭비일 수도 있고, AI interoperability(상호운용성)는 아직 정해진 표준이 없음.

Slack이 에이전트 기능을 천천히 다 채울 텐데, 아무도 이것 때문에 Slack을 안 버릴 것임.

이걸 '가치 있는' 시장이라고 부를 수 있을지 모르겠음.

잭 도시는 0에서 1을 만드는 데는 능하지만, 나머지는 매번 엉망임.

팀 채팅에 봇을 넣는 건 나쁜 생각이 아님. Slack으로 실험 중인데 권한 설정이 복잡함. 결국 자체 호스팅 대안을 찾다가 Zulip으로 넘어갔는데 봇 생성이나 자동화가 훨씬 쉬웠음. 앤스로픽이 Zulip 리더십을 영입한 걸 보면 잭 도시보다 앞서 비슷한 계획을 하고 있을지도 모름.

ATProto는 엔터프라이즈급 권한 체계를 지원하지 않음.

Git은 일반 사용자에게 너무 어려움. 브라우저 기반의 더 쉬운 도구가 결국 답일 것임.

홈페이지 접속하자마자 CPU 사용량 폭주함.

Nostr를 쓰는데 뭔가 억지로 끼워 맞춘 느낌임. 팀 채팅에서 해결된 적 없는 문제를 푸는 것 같지도 않고.

부자 꼬마가 틱톡 같은 거 하면서 관심받고 싶어 하는 거 아님?

셀프 호스팅 가능하고 오픈 소스라면 괜찮음. Git 호스팅 부분은 조금 미심쩍음.

Slack이 현재 AI를 무시하고 기존 봇 플랫폼에 새 기능을 안 만드는 건 문제가 있음. 단순히 텍스트만 뱉어내는 봇은 쓸모가 없음.

인간과 에이전트가 이모지 섞인 채팅을 하는 스크린샷은 공포스러움. 개발 업무를 이런 식으로 조직하는 게 맞는지 의문임.

엔지니어링 조직의 미래를 보는 것 같음. JetBrains Space와 비슷함. 다만 Git 호스팅 기능에 대한 정보가 부족하고 GitLab만큼의 완성도를 낼 수 있을지 의문임. 기존 툴의 API를 활용하는 게 더 낫지 않았을까 싶음.

AI 통합이 정말 대중이 원하는 걸까, 아니면 의사 결정권자들의 욕심일까? 실제 여론은 AI를 부정적으로 보는 경우가 많고, 기존 툴들이 점점 불편해지고 있음.

직접 만든 프로젝트는 포기했지만, 이런 프로토콜 기반의 툴이 미래라고 생각함.

LLM을 써서 PR 검토 등을 하는데, 로컬 Cursor에 있는 에이전트와 Slack의 에이전트가 소통이 안 되는 게 문제임. 누군가 이 문제를 해결하면 큰 돈을 벌 것임.

잭 도시가 지금 회사(Block)의 핵심 고객 요구를 무시하고 딴짓(사이드 퀘스트)만 하는 게 문제임. 핵심 사업 시장 점유율도 잃고 있는데 그를 신뢰하는 게 이상할 정도임.

내 주변의 실제 실무자들은 AI를 적용할 방법을 찾고 있고, 의사 결정권자들은 신중한 입장이지만 실험은 장려함.

에이전트에게 ID를 주고 접근 제어를 하는 건 좋은 문제 해결 같지만, Nostr 레이어가 가치를 더하는지 모르겠음. 그냥 블록체인 낭비 아닐까?

IRC는 사랑이지.

원래 레딧 용어인데 마케팅 문구로 변질된 게 웃김.

Google Buzz도 16개월 만에 망했음. 결국 이 프로젝트도 피트(fit)를 찾느냐 아니냐의 문제지, 코드가 좋다고 성공하는 건 아님.

기존 인증 프로토콜을 무시하고 직접 만든 것 같은데, 노벨티(새로움)는 없는 것 같음.

우리 클라우드 Harness에서는 공유/개인 비밀(secret)을 구분해서 관리함. Slack 에이전트는 이 부분에서 유출이 없도록 보장하고 있음.

AT 프로토콜에 '권한 데이터'를 처리하는 새 기능이 추가되는 중임.

데이터 소스와 ACL을 연동하면 보안 관리가 가능함.

예전에는 제품 하나를 만들 때 깊이 고민했는데, 지금은 대충 던져놓고 사용자가 알아서 하라는 식임.

1%만 공개 채널에서 말하는 회사에서 일해봤는데, 정보 찾기 정말 힘들었음.

개인적인 이메일을 공개적인 곳에서 읽는 건 문제임. 공유된 환경에서는 공유된 비밀(shared secret)을 써야 함.

스크린샷 속 메시지 시간이 다 똑같은 거 보니 데이터가 다 조작된 거임.

그룹 멤버십에 따라 에이전트 접근 권한을 줘야 함. AI가 스스로 권한을 관리하게 하는 건 위험함.

Slack이 AI 기능을 도입하는 건 그동안 추구해온 '업무 통합 인터페이스'라는 목표와 일치함. 파워 유저들도 AI 기능을 원하고 있고. 노션이 업무용 브라우저로 자리 잡은 것도 같은 맥락이라 생각함.

ELI5(다섯 살에게 설명하듯) 용어 남용임. 노스트르(Nostr)가 뭔지 아는 사람도 적은데.

Slack은 walled garden(폐쇄적 환경)이라 떠나고 싶음. 요즘 여러 툴을 결합하는 방식이 좋아 보임.

Slack이 에이전트 시대를 잘 대응할지 모르겠음. Nostr 프로토콜이 정말 이 문제를 풀 수 있을지, Git 의존성을 굳이 추가해야 하는지도 의문임. Rust를 선택한 이유는 궁금함.

Nostr는 중앙 서버를 거치지 않고 ID를 검증할 수 있어서 좋음.

1999년에 왜 DHL이 홈페이지가 필요하냐고 묻는 거랑 똑같음.

봇이 코딩을 다 한다면, 여기가 미래의 IDE가 될 것임.

누가 버튼을 누를 권한이 있는지 문제임.

잭 도시가 트위터 개발자들을 어떻게 대했는지 기억함. 그를 기술의 선한 사람으로 보지 않음.

어차피 스크린샷으로 공유하면 관리자도 다 볼 수 있지 않나?

다중 사용자 에이전트가 민감한 정보를 보게 되면 어떡함? 사용자별로 권한을 제한하는 ACL 논리가 있어야 하는데, 이게 매우 복잡함.

회사 Slack에서 하는 사적인 대화는 애초에 사적이지 않다고 생각하는 게 편함.

1990년이 아니니까 권한 설정도 프로그램으로 하면 됨.

Signal처럼 보안이 보장되는 툴이 낫지, Slack은 회사의 약속에만 의존하는 구조라 불안함.

에이전트가 고유 키를 가진다는데, 결국 사람마다 봇을 할당하는 것뿐이지 않나? 이건 혁명적인 게 아니라 그냥 오케스트레이션 레이어를 새로 짠 것에 불과함. 모델 요청을 다른 멤버의 기기에서 돌린다는 건 내 CPU랑 GPU를 랜덤하게 빌려 쓰겠다는 건지 의문임.

회사 리더십 채널은 민감한 내용이 많음. AI 에이전트가 그 정보를 학습해서 다른 곳에서 답변하는 상황이 걱정됨. AI가 정보를 유출하지 않도록 하는 방안이 오늘날의 paradigma에서는 아직 불완전함.

회사는 유지보수하기 쉬운 SaaS를 원함. 내부에서 만든 툴은 유지보수 비용과 컴플라이언스 문제 때문에 피함.

Slack은 법적 절차가 있어야만 관리자가 메시지를 볼 수 있게 되어 있음.

AI가 무조건 동의만 하는 게 아니라 비판도 해줘야 함.

모두에게 봇을 주는 건 Slack 앱 운영상 쉽지 않음. 봇이 사람인 척하는 건 거부감이 듦. 공유 컴퓨팅은 옵트인(선택 사항)이고 Mesh-LLM과 통합된 것임. 매우 초기 단계지만 자치적인 커뮤니티 추론을 구상 중.

중앙 집중식 SaaS 대신 로컬/클라이언트 우선 방식이 더 많아졌으면 함.

중앙 집중형 SaaS가 가진 문제(가격 인상, 데이터 판매, 기능 임의 삭제 등)를 생각하면 독립적인 대안이 필요함.

개인 그룹 설정 변경이 나중에 안 되는 게 문제인가?

채팅은 에이전트가 소통하기엔 좋지만 업무 도구로는 부족함.

공용 환경에서 에이전트가 공유함에 접근하는 건 결코 안전하지 않음.

보안과 안정성 때문에 기업은 SaaS를 선호함. 내부 툴이 모든 SaaS를 대체할 순 없음.

업무용 메시지도 누군가 악의적으로 이용하면 커리어 끝장날 수 있음.

관리자로서 내 팀원들의 인사 정보 등을 에이전트가 함부로 접근하지 못하게 해야 함.

아니면 원한 품은 동료가 문제지.

회사 관리 앱에서 '동의'라는 개념은 존재하지 않음.

Slack Enterprise에서 비공개 채널을 공개로 바꿀 수 있음.

LLM이 스택오버플로우 꼰대처럼 구는 면이 좀 있었으면 좋겠음.

모든 인간의 업무를 AI 훈련 데이터로 만드는 것인가? 성공하면 재앙이 될 것 같은데.

트위터 팔고 난 뒤부터 잭 도시 신뢰 안 함.

Slack이 브로트(bloated)하고 느린 건 사실임. 잭 도시가 일을 잘 처리한다는 것도 환상임.

서브레딧 처음 생길 때 다섯 살한테 설명한다는 뜻이 아니라는 거 다 알았음.

유용한 틈새시장이 될 수 있지만, 6~12개월 안에 OpenAI나 앤스로픽이 이런 기능을 밀고 들어올 것 같음. 그들이 이미 유사한 auth 모델(Tag 등)을 구축하고 있어서, 결국 GitHub 같은 툴을 에이전트 UI가 대체하면 위험할 듯.

직접 만들면 되는 걸 왜 굳이 돈 내고 써야 하는지 의문임.

Nostr는 P2P가 아님. 텍스트 위주라서 서버 운영비가 쌀 뿐임.

버블이 아니라 개발 환경이 근본적으로 바뀌고 있음. Buzz가 성공작이 아닐지라도, 이런 방식의 작업 방식 변화를 시도하는 사례가 계속 나올 것임.

Asana에서 일하는데, 에이전트 도입은 개인뿐만 아니라 멀티플레이어 환경에서 유출 방지를 고려해야 함. Buzz의 시도는 흥미로움.

시작은 안 그랬어도 진짜로 다섯 살 수준의 설명을 바라는 댓글들이 있긴 했음.

비슷한 비즈니스 툴을 만들고 있는데, 이런 방식의 필요성은 확실히 느낌.

그럼 굳이 포크(fork)해서 쓰면 안 됨?