저 스크린샷은 무슨 David Lynch식 공포물 같음. “#engineering. 새 방향입니다. 프로토타입을 Flutter로 옮깁니다”라고 하자 사람과 에이전트 봇이 귀여운 이름과 이모지로 “물리 처리는 끝냈어, UI 셸은 어때 @Honeybot?” 같은 대화를 나눔
이런 방식으로 소프트웨어 개발을 조직하는 게 자연스러운 세상을 상상하기 어렵고, 블록체인 비슷한 무언가를 쓴다는 점도 전형적으로 느껴짐 https://github.com/block/buzz/blob/main/docs/assets/screensh...

어릴 때 AI 연구에 뛰어든 이유 중 하나는 언젠가 인간처럼 대화하고 교류할 수 있는 지적인 존재가 생기리라는 기대였음. 이제 실제로 가능해졌는데 모두가 싫어하는 듯하지만, 나는 여전히 좋고 AI 에이전트를 팀원으로 만드는 시도가 멋지다고 봄
다만 아첨만 하는 복제본 대신 실제 성격을 부여해, 능력과 행동 양쪽에서 각 에이전트의 차이가 분명해야 함

저 화면은 여러 사람과 에이전트의 움직임을 실시간으로 맞추기 어려워 만든 스크립트 기반 데모이며, 저장소에서 해당 PR도 확인할 수 있음
본질적으로 낯선 것을 직관적으로 느끼게 만드는 데 장난스러운 연출을 과소평가할 필요는 없음. 봇마다 관리 주체, 능력, 권한이 다르므로 이름과 이미지는 인스턴스를 구분하는 편리한 약칭이고, 귀엽게 꾸밀지는 선택 사항임

여기에는 블록체인이 없음. Nostr는 단순한 저장 후 전달 릴레이 서버를 거치는 서명된 메시지 형식 표준일 뿐임

모든 메시지 시간이 5시 42분인 것으로 보아 미리 넣은 테스트 데이터로 만든 캡처이거나 그 캡처에 기반한 목업임

“5살에게 설명하듯”이라면서 “Buzz는 서명된 Nostr 이벤트로 팀 채팅, AI 에이전트, Git 호스팅을 결합한 오픈소스 자체 호스팅 작업 공간”이라고 설명하니, 기대하는 5살의 수준이 상당히 다름

원래 AskReddit 스레드에서 파생된 서브레딧 이름이었던 ELI5가 이제 기술 업계의 흔한 마케팅 문구가 된 과정이 흥미로움. 현재는 “예상 독자가 알아야 할 제1원리부터 설명하라”는 뜻의 약칭에 가까우며, 업계 종사자 다수가 2010년대 Reddit을 애틋하게 기억하는 듯함

에이전트에게 eli5 (작업)라고 하다가 정말 5살에게 말하듯 설명할까 걱정한 적이 있음. 비합리적인 우려였고, 에이전트는 HN 댓글란과 달리 대개 실제 의도를 이해함

어제 받은 ELI5도 이해되지 않아 합리적인 다음 단계로 “ELI4”를 요청했음

“TechCrunch Disrupt에서 발표하듯 설명해 줘”라는 뜻에 가까움

Buzz를 읽어도 유행어와 기업식 전문용어만 겹쳐 보여서, 실제로 무엇을 하는지 알기 어려움

Slack에서 일하지만 개인 견해임. 에이전트가 나와 동료가 보는 모든 것을 볼 수 있다는 점은 멋지지만, 일부 정보를 특정인에게만 공개하려는 순간 어려워짐 다중 사용자 에이전트가 데이터를 유출하지 않도록 리소스별 접근 규칙을 복잡하게 작성하고 유지해야 함. 반면 단일 사용자 에이전트는 한 사용자를 대신하므로 구조가 단순하고, 명시적 허가 없이 비공개 데이터를 공유 공간으로 반출하지 못하게 하는 것이 핵심임

진정한 협업 환경에서 비공개 그룹은 최악임. Slack에 스레드 전체를 공개 채널로 발행하는 버튼이 있으면 좋겠음

Asana 출신이라 편향됐을 수 있지만, 단일 사용자 에이전트가 더 쉽다는 데 동의함. 그래도 전체 작업 흐름을 이해하는 다중 사용자 에이전트는 매우 강력함
개인정보를 의식하고 잘못된 대상에게 정보가 새지 않도록 만드는 데 많은 고민과 시간이 들었음. Buzz는 아직 써보지 않았지만 색다르게 사고하며 흥미로운 것을 만드는 시도는 높이 평가함

Buzz에서는 에이전트가 앱 통합이 아니라 그 자체로 일급 사용자인 듯함. Claude라는 사용자를 만들고 일반 ACL을 적용한다면 인간인지 봇인지 신경 쓸 필요가 없지 않을까 싶음

우리 클라우드 실행 환경은 공유 비밀과 개인 비밀을 구분함. 공유 비밀로 인증된 항목은 공개 환경에서 쓸 수 있고, 개인 항목은 신뢰 채널로만 접근할 수 있어 Slack이나 Telegram 등에도 적용됨
Slack 에이전트는 이 부분이 강력하며 비공개 정보가 전혀 유출되지 않도록 보장함

대화 키로 그룹 채팅 ID와 추가 정보를 사용하면 되지 않나 싶음

이제 새 소프트웨어 프로젝트를 보면 얼마나 많은 부분이 에이전트로 만들어졌는지, 그에 따른 불안정성과 손쉬운 포기부터 떠오름. 10년 전이었다면 제품 품질을 어느 정도 짐작할 수 있었겠지만, Buzz를 특정해 말하는 것은 아님

예전에는 무언가를 만드는 마찰 자체가 어느 정도 숙고했다는 신호였지만, 지금은 사용자에게 던져 놓고 가치가 있는지 직접 판별하게 하는 듯함
이런 제품은 초기 도입의 이점보다 위험이 크므로 몇 달 기다리는 편이 나음. 지속 가능한 제품이라면 몇 달 늦어져도 별 차이가 없음

대부분의 소프트웨어는 에이전트 사용 여부와 무관하게 결국 사라지므로 그런 사고방식에는 결함이 있음. Google도 LLM 이전인 2010년에 비슷한 소셜 제품 Google Buzz를 출시했지만 16개월 만에 끝냈음
프로젝트가 시장 적합성을 찾느냐가 핵심이며, 2년 뒤에도 존재할지는 엔지니어가 믿고 싶어 하는 것만큼 코드 품질과 강하게 연결되지 않음

이제는 초기 도입자가 되고 싶지 않으며, 최소 6개월의 검증을 거쳐 잠깐의 유행인지 확인해야 함

모두 LLM으로 생성됐다고 가정하는 편이 안전함

손쉽게 포기하게 된다는 건 현실임. AI로 함수와 테스트를 만들고, AI로 함수를 수정한 뒤 테스트가 깨지면 전부 삭제하고 다시 AI로 테스트를 생성하는 흐름이 됨

예전에 Slack에서 일했음. 채팅의 현상 유지에 도전하는 건 좋지만, Slack과 Teams가 에이전트 시대에도 살아남거나 그 수준으로 발전할지는 회의적임
다만 Nostr가 정말 적절한 프로토콜인지는 궁금함. 대기업에서는 휴대전화와 로컬 에이전트를 포함한 수많은 클라이언트와 팀별 에이전트를 다뤄야 함. 중앙 호스팅 에이전트에는 현재 신원 구조가 맞지만, 개인 에이전트가 사용자 자격 증명을 재사용하는지 별도로 구분되는지는 알 수 없음
Git이 필수 의존성일 필요가 있는지도 의문임. Block에는 필요할 수 있지만 복잡성이 커지므로, 버전 관리 호스트 이벤트를 Buzz 이벤트 로그에 병합하는 방식으로 분리할 수도 있음
Sol과 Claude가 채팅 창에서 네이티브 구성 요소를 렌더링해 디자인 변경을 구체화하는 것처럼 새 기능이 등장할 때 어떤 문제가 생길지도 궁금함. Rust를 선택한 이유와 검토한 대안도 알고 싶음

Signal 같은 절충안이 더 나아 보임. Slack은 사무직 비즈니스 관계에서 떼기 어려운 존재가 됐지만, 24시간 사이버 공격에 노출된 상황에서는 회사의 약속보다 영지식 시스템을 통한 기밀성과 보안이 보장되면 좋겠음
Signal은 친구 그룹에서 써 본 클라이언트 중 플랫폼 간 메시징 경험이 가장 좋았으며, 현재 구조에 Slack 같은 체계를 더하면 시끄러운 채널 문제를 줄이는 데 유용할 것임

코드와 파일 같은 공유 정보는 사람과 에이전트의 정렬을 유지하는 데 갈수록 중요하며, AI 네이티브 기업은 코드 의존도가 더 높아질 테니 Git 통합이 타당함

Rust가 왜 나쁜 선택처럼 느껴지는지 궁금함. 의료기기 소프트웨어를 출시한 경험상 팀이 작성한 코드를 응집력 있고 정확하게 유지하는 데 훌륭했음

팀 채팅에 봇을 넣는 건 나쁘지 않아 몇 달째 실험 중임. Slack은 작동하긴 하지만 수많은 권한을 맞추기가 고통스럽고 새 봇마다 반복해야 함
자체 호스팅 대안으로 Matrix를 써 봤지만, 종단간 암호화가 너무 엄격해 봇과 정보를 공유할 때 방해가 됐음. 몇 주 전 Zulip으로 옮겼고 설치와 봇 사용자 생성, 자동화가 모두 간단했음. Openclaw로 만든 자동화는 상태가 덜 엉망인 Haystack 기반 코드로 교체했음
설치 후 알게 됐는데 Zulip 경영진이 Anthropic에 채용됐음. Jack Dorsey가 먼저 발표한 듯하지만 Anthropic도 비슷한 계획이 있을 수 있음 팀 단위 에이전트는 충분히 타당함. 조직이 커질수록 협업 비용이 늘어나 AI로 최적화하기 좋고, AI 활용이 많아질수록 무엇을 하는지 공개 채널에서 공유하고 조율할 필요도 커짐. 공통 안전장치와 사람·에이전트 간 인계가 포함된 복잡한 프로세스에도 팀 채팅이 잘 맞음

XMPP는 어떨지 궁금함

유용한 틈새를 채울 수 있지만 Anthropic과 OpenAI가 6~12개월 안에 자체 제품으로 밀어붙일 가능성이 큼
에이전트 군집용 Git 포지를 살펴보니 Radicle은 신원 계층이 부족하지만 연합형 COB 모델은 좋아 보였고, Tangled는 비공개 저장소 지원이 없지만 소셜 계층은 탄탄했음. 다만 이슈를 저장소 소유 객체가 아니라 게시물로 모델링한 점은 어색함
따라서 비공개 에이전트 우선 포지의 자리가 있음. Anthropic은 이미 이 방향으로 가고 있으며, 최신 제품 Tag는 Slack 안에서 에이전트를 비동기로 실행하기 위한 인증 모델임
다음 단계는 자연스럽게 포지가 될 수 있음. 에이전트 UI가 GitHub를 중개하지 않게 되면 Anthropic은 내부 구현을 자유롭게 교체할 수 있고, 다중 사용자 채팅과 저장소·프로젝트 관리가 다음 플랫폼 구성 요소로 보임

새 코드 포지 https://juju.bi를 만들고 있음. 에이전트 우선 제품은 아니지만, 확장성 외에 에이전트에 특별히 필요한 기능은 떠오르지 않음

Slack이 존재하는 큰 이유는 IRC가 채널 기록과 검색 등을 기본 지원하지 않아 부족했기 때문임. AI 에이전트가 번성하려면 Slack이 네트워크를 프로토콜로 완전히 개방하거나 결국 대체돼야 함
Slack이 AT Protocol 기반 채팅을 채택하고 Buzz 같은 앱이 이를 구현하면 좋겠음. 사용자는 @yourname.com, 에이전트는 @agent1.yourname.com 같은 도메인 핸들을 쓰면서 완전한 통제권을 가질 수 있음

왜 에이전트를 번성하게 하는 것이 Slack의 책임인지 모르겠음. 업계 전반에서 AI에 맞춰 작업 흐름을 바꾸는 주객전도를 직접 겪고 있는데, 도구가 사람을 위해 작동해야지 그 반대여서는 안 됨

Matrix의 봇·퍼핏 계정과 비슷함

처음 Slack을 좋아한 이유는 “현대적인 편의 기능을 갖춘 IRC”였기 때문임. Microsoft에 밀리고 Salesforce에 매각된 뒤로는 사실상 정체됐으며, 대부분의 변경이 제품을 더 나쁘게 만들었음

아직 확정되지 않은 ATProto 권한 체계로는 기업이 요구하는 세밀한 제어가 부족함. 그룹 같은 기능은 앱 뷰에서 구현돼 사실상 중앙화될 것이며, ACL은 신원 및 접근 관리 역사에서 두 세대 전 방식임
채팅도 PDS/ATP에 잘 맞는 형식이 아님. Roomy도 이를 깨닫고 전용 프로토콜과 브리지를 만들고 있음