공짜 Slack인 Buzz 도입 전후 비교: AI 에이전트 관리가 이렇게 쉬워졌다고?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

무료 Slack 대안으로 소개된 Buzz를 자체 VPS에 설치해 서버별 AI 에이전트를 한곳에 모으자, 발표자는 대화·파일 교환·상태 보고를 통합하며 운영 관리를 단순화했다.

📌 핵심 요점

1. 관리 단위는 직책보다 기기다. 발표자는 VPS 두 대와 Mac·Windows를 관리 대상으로 삼고, 각 기기의 에이전트가 해당 환경의 운영을 담당하도록 구성한다. 개인용 컴퓨터의 에이전트 설치·연결은 일부 대목에서 향후 계획으로 설명된다.
2. Telegram에서 Buzz로 중심을 옮긴 이유는 업무 기록과 확장성이다. Telegram에서는 대화가 쌓일수록 주제별 검색이 어려웠고, Slack은 인원이 늘 때의 유료 비용이 부담스러웠다고 설명한다.
3. Buzz의 핵심 가치는 자체 호스팅과 AI 팀원이다. 발표자는 VPS 한 대에 Buzz를 설치하고 다른 서버의 에이전트를 연결해, 대화 기록을 자신의 서버에 보관하면서 에이전트끼리 소통하도록 했다.
4. 무료 소프트웨어도 운영 비용과 장애 대응은 필요하다. VPS와 AI API 비용이 발생하며, 봇이 응답하지 않을 때는 별도 봇이나 Telegram 경로로 복구했다고 말한다.
5. 코딩 환경도 필요한 규칙만 남기는 방향으로 정리했다. Superpowers와 Compound Engineering을 제거한 뒤 빠진 TDD·배포·작업 분리·해결 기록 등의 절차를 agent.md에 옮겼고, 최종적으로 코딩은 Codex, 운영은 Buzz와 Hermes로 구분한다.

🧩 배경과 문제 정의

발표자는 개인 개발자이자 창작자로, 블로그와 사진 서비스를 운영하면서 VPS 두 대, MacBook, Windows PC를 사용한다. 이동 중에는 휴대전화로 AI와 소통한다. 환경마다 접속 방식과 명령이 달라지는 상황에서, 각 기기를 자연어로 관리하고 작업을 이어갈 공통 창구가 필요했다.

기존에는 Telegram에 에이전트를 모으고 Paperclip으로 조직형 작업 구조를 구성했다. 그러나 Telegram은 대화가 누적될수록 검색과 주제 관리가 불편했고, Paperclip의 계층 구조는 자신의 작은 서비스에 과하다고 판단했다. Slack을 검토했지만 향후 이용료가 부담스러워 자체 호스팅하는 Buzz로 중심을 옮겼다.

영상은 협업 공간의 교체와 함께 코딩 절차의 정리도 다룬다. 발표자는 무거운 하네스를 제거하면서 필요한 테스트·배포·해결 기록 규칙을 agent.md에 남겼다. 회사 전체에 적용한 검증 사례보다는 개인 개발자의 운영 방식 변화로 이해하는 것이 적절하다.

🕒 시간순 섹션별 상세정리

1. 네 기기를 담당하는 에이전트와 협업 공간 소개

• VPS 두 대, MacBook, Windows 기기를 관리 대상으로 소개하며, 에이전트가 각 기기의 중간 관리자처럼 역할을 맡는다고 보여준다. Slack처럼 보이는 공간에서는 서버 담당 봇들이 서로 대화한다. [00:31]
• 이전 AI 비서 구성 소개 이후 5개월 넘게 지났으며, 모델과 도구의 변화에 맞춰 현재 사용 방식을 다시 소개하겠다고 드러낸다. [01:14]

2. 개인 개발자의 작업 환경과 적용 범위

• 발표자는 서비스를 크게 홍보하기보다 개발 감각을 유지하기 위해 운영하는 개인 개발자·창작자라고 드러낸다. 회사 업무에는 자신의 구성이 맞지 않을 수 있으며, 개인 프로젝트에 참고할 수 있다고 덧붙인다. [02:01]
• 외출 시 MacBook, 집에서는 방송용 Windows PC, 이동 중에는 휴대전화의 ChatGPT·Codex·Telegram을 사용해 여러 기기를 오가는 환경을 보여준다. [02:22]

3. Telegram과 Paperclip을 사용했던 이전 구조

• 이전에는 Telegram 채널에 AI 에이전트를 모았고, Paperclip으로 관리자와 작업자 같은 계층을 만들어 프로젝트 업무를 배분했다. [02:57]
• 실제 사용 후에는 개인 개발자에게 이러한 계층이 자주 필요하지 않다고 판단했다. 블로그에 사진 서비스까지 더해지면서 여러 서비스를 운영하기에 적합한 구조를 다시 고민한다. [03:43]

4. 두 VPS와 자연어 서버 관리

• 블로그와 사진 서비스를 Hostinger의 VPS 두 대에서 운영하며, 서비스가 늘면 VPS를 추가하는 방식을 생각하고 있다. 서비스 규모가 크지 않아 AWS보다 관리가 쉽다고 느낀다고 보여준다. [04:06]
• 각 VPS에 에이전트를 붙인 이유는 웹 콘솔이나 SSH에서 명령을 외우고 입력하는 부담을 줄이고, 자연어로 관리하기 위해서다. [04:48]

5. 에이전트 상호 복구와 상시 가동의 차이

• Hermes와 Open-interpreter를 비교하면서 함께 사용하고 있으며, 한쪽이 업데이트 중 고장 나면 다른 쪽에 복구를 요청하는 활용 사례를 보여준다. [05:15]
• Mac과 Windows에도 에이전트 설치를 계획하지만 두 기기는 상시 가동하지 않는다. 반면 VPS는 서비스를 계속 운영하기 위해 24시간 켜 두는 환경이라고 구분한다. [06:04]

6. 관리 대상 증가와 Telegram·Slack의 한계

• 기기와 에이전트 수가 늘고 운영체제별 명령도 달라지면서 관리가 복잡해졌다. 여러 에이전트를 Telegram에 모았지만, 대화와 주제가 쌓일수록 원하는 내용을 찾기 어려웠다고 드러낸다. [07:24]
• 업무별 채널을 나누고 AI를 초대할 수 있는 Slack을 검토했으나, 인원이 늘 때 유료 요금이 부담될 것으로 예상해 대안을 찾는다. [07:56]

7. AI를 팀원으로 다루는 Buzz

• Buzz를 Jack Dorsey가 설립한 Block의 오픈소스 프로젝트로 소개하며, 에이전트 시대의 Slack이라는 설명을 전해진다. 저장소가 약 3만 5천 개의 스타를 받았다고도 드러낸다. [08:20]
• 화면 속 AI들을 사람처럼 팀원으로 취급하는 점을 강조하고, AI와 팀으로 일하는 데 특화된 Slack과 비슷한 도구이면서 무료라고 보여준다. [08:52]

8. 자체 호스팅과 대화 기록 보관

• Buzz를 VPS2에 직접 설치하고 다른 참여자가 접속하는 자체 호스팅 구조를 보여준다. Slack과 Telegram에 남던 대화 기록을 자신의 서버에 보관할 수 있다는 점을 강조한다. [09:57]
• 서비스별 AI가 Buzz에 참여하는 모습을 보여 주며, Slack보다 기능은 적지만 익숙한 사용감, 데이터 통제, AI 팀원 참여가 선택 이유라고 정리한다. [10:25]

9. 서버 사이의 대화와 파일 전달 허브

• AI가 다른 AI를 호출하고 응답하는 흐름을 보여 준다. 여러 서버에 흩어진 서비스가 Buzz를 통해 소통하고 파일을 주고받는 구조라고 보여준다. [10:55]
• Mac과 Windows까지 연결하면 기기를 자주 옮겨 다니는 작업에 도움이 될 것으로 기대하며, Buzz를 업무용 대화와 파일 교환의 공통 허브로 보여준다. [11:18]

10. 호스팅 추천과 에이전트 연결 방법

• Hostinger의 원클릭 설치 경로와 KVM2 이상 요금제를 추천한다. 서비스와 추가 에이전트를 함께 실행하는 구성을 이유로 들며, Hostinger 협업 사실과 ZEROCHO 코드의 추가 10% 할인·무료 도메인 제공을 안내한다. [12:06]
• Buzz는 여러 서버 중 상시 가동하는 한 대에만 설치하고, 나머지 서버의 에이전트를 해당 인스턴스에 연결하면 된다고 보여준다. [12:27]
• VPS 구성 직후 AI 에이전트를 설치하면 다른 서버의 에이전트를 초대하는 설정도 자연어로 요청할 수 있어 직접 입력할 명령을 줄일 수 있다고 드러낸다. [12:59]

11. 봇 협업의 장애와 API 호출 제한

• 서버별 AI가 오류 메시지를 공유하고 함께 문제를 해결하도록 구성할 수 있다고 설명하지만, 실제로는 봇을 불러도 응답하지 않는 문제가 있었다고 드러낸다. 별도 봇이나 Telegram으로 접촉해 복구했다. [13:38]
• AI 호출에는 API 비용이 발생해 호출을 제한했고, 관련 설정 변경도 AI 비서의 도움을 받았다고 드러낸다. 주요 불편은 호출한 봇의 무응답이었다. [14:12]

12. 하네스 제거 후 다시 확보한 TDD

• 모델 성능이 높아진 뒤 Superpowers의 토큰·시간 부담을 느껴 제거했지만, Compound Engineering에 유사한 절차가 남아 있어 변화가 크지 않았다고 보여준다. 이어 Compound Engineering도 제거했다. [15:11]
• AI가 많은 코드를 생성하는 상황에서는 요구사항을 테스트로 표현하고 동작을 확인하는 일이 중요하다고 주장한다. 그러나 Compound Engineering을 제거한 뒤 테스트 우선 개발이 사라졌다고 드러낸다. [15:57]
• 무거운 도구를 다시 넣는 대신, 필요한 TDD와 작업 지침을 agent.md에 직접 작성하는 방식으로 보완하기 시작한다. [16:16]

13. 원격 코딩과 프로젝트별 지침 문서

• 전사에서 Codeium으로 표기된 도구의 연결 기능과 SSH를 통한 원격 작업을 보여준다. 상시 가동 VPS를 중심으로 작업하되 GPU가 필요하면 Windows로 옮기고, 기기 간 파일 이동은 AI에 요청한다고 보여준다. [17:21]
• 프로젝트의 agent.md에 서비스별 작업 규칙, 배포 절차, worktree를 이용한 작업 분리 등을 기록한다. 자신의 문서를 그대로 복사하기보다 각자의 운영 노하우를 적으라고 권한다. 필요한 절차만 남기면 토큰과 시간이 줄었다고 드러낸다. [18:56]
• GitHub Actions 사용 한도에 따른 SSH 배포, 백업, design.md 참조, 해결 사례 폴더를 먼저 확인하는 규칙도 문서화해 반복 실수를 줄인다고 보여준다. [19:37]

14. 모델 선택 실험과 토큰·디자인 보완 도구

• 모델 선택을 더 유연하게 바꿨지만 토큰 부담이 있어, Zebb로 Astra·Sol·Luna와 추론 강도를 고르는 방식을 구상한다. 비용 절감 효과는 아직 시험해야 한다고 명시한다. [20:51]
• Caveman·Ponytail·RTK를 적용한 토큰 절감 경험을 소개하면서 결과 품질이 떨어지면 제거하라고 권한다. 자신은 세 도구를 사용하며 아직 문제를 겪지 않았다고 드러낸다. [21:18]
• 디자인 스킬 적용 후 서비스 화면이 개선됐다고 설명하며, J-Com으로 소개된 제작자의 스킬을 좋게 평가한다. 관련 내용은 추후 짧은 영상으로 소개하겠다고 드러낸다. [21:54]

15. 최종 운영 구조와 다음 업데이트 예고

• 작은 서비스에는 Paperclip의 조직 계층이 맞지 않았다고 정리하되, Jira 같은 프로젝트 관리가 필요하면 고려할 수 있다고 덧붙인다. Buzz를 협업 중심으로 삼고, 기존 하네스의 유용한 규칙만 agent.md에 남겼다고 보여준다. [23:03]
• 코딩은 Codex의 원격 연결로, 운영은 Buzz와 Hermes로 수행한다. 새 서버에는 Hermes를 설치해 Buzz에 연결하고, 실행 권한 부족이 있을 때는 별도 처리가 필요하다고 드러낸다. 서비스 상태는 3시간마다 보고하며 채널별 협업 기록을 자신의 VPS에 보관한다. [24:41]
• 5개월 전과 비교해 작업 구조를 크게 바꿨으며 앞으로도 달라질 수 있다고 전망한다. 도구 소개와 별도로 몇 달마다 긴 영상으로 실제 구성 변화를 공유하겠다고 밝히고, 다음 업데이트를 예고하며 마무리한다. [25:22]

🧾 결론

• 도입 전에는 Telegram의 누적 대화와 서버별 접속이 관리 부담이었다. 도입 후에는 Buzz가 에이전트 대화, 파일 교환, 서비스 상태 보고의 공통 창구가 됐다.
• 발표자의 소규모 서비스에는 회사 조직도를 흉내 낸 에이전트 계층보다 서버별 담당 에이전트와 공통 협업 공간이 더 적합했다. Paperclip이 불필요하다는 판단은 이 운영 규모에 한정된다.
• 하네스를 줄여도 검증 절차는 유지해야 한다. 발표자는 Compound Engineering 제거 후 TDD가 사라지는 문제를 겪고, 필요한 지침을 직접 문서화하는 방식으로 보완했다.
• 자체 서버에 기록을 보관하는 구조와 안정적인 운영은 별개의 과제다. 영상에서도 봇 무응답, 호출 제한, 실행 권한 문제에 대한 대응이 필요했다.

📈 투자·시사 포인트

• AI 협업 도구를 평가할 때 채팅 기능뿐 아니라 에이전트 연결, 기록 보관 위치, 서버 간 작업 전달을 함께 살펴볼 필요가 있다. 영상에서 Buzz 선택을 이끈 기준도 이 세 가지다.
• 비용 비교는 Slack 이용료와 Buzz 소프트웨어 가격만으로 끝나지 않는다. 자체 호스팅 서버, AI API 호출, 설정·복구에 드는 시간을 포함해야 실제 운영 부담을 비교할 수 있다.
• 모델 성능이 높아질수록 기존 하네스의 필요성을 재평가할 여지가 있다. 다만 발표자의 경험처럼 절차를 제거하면서 테스트까지 빠질 수 있으므로, 토큰 절감과 품질 유지 여부를 함께 확인해야 한다.
• 이 영상은 개인 개발자의 운영 사례이며 특정 기업의 실적이나 투자 수익을 판단할 근거를 제공하지 않는다. 활용 가치는 도구 선택과 운영 구조 비교에 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• Buzz의 무료 제공 범위, Slack 대비 기능 차이, 소개된 저장소의 스타 수는 발표자의 설명이다. 영상에는 라이선스·요금 조건·기능표를 검증할 자료가 충분히 제시되지 않는다.
• 자체 VPS에 기록이 남는다는 설명만으로 백업·복구·접근 통제가 검증되지는 않는다. 데이터 보관 위치와 데이터 유실 방지 수준은 구분해서 확인해야 한다.
• 전사에는 Buzz·Berze·Buz, OpenCllo·Open-interpreter, Codeium·Codex 등 명칭이 혼재한다. 실제 설치 대상, 제품 버전, agent.md 지원 여부는 원영상 화면과 해당 제품 문서로 확인필요가 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 관리할 서버·개인 기기·서비스를 목록으로 정리하고, 상시 가동 여부와 각 에이전트의 담당 범위를 기록한다.
• 시험용 상시 가동 서버에 Buzz를 구성하고 에이전트 두 개부터 연결해, 상호 호출·응답·파일 전달이 실제로 동작하는지 확인한다.
• 기존 도구 이용료와 VPS·AI API 비용을 같은 기간으로 비교하고, 봇 호출 제한이 응답성과 비용에 미치는 영향을 기록한다.
• Buzz나 봇이 응답하지 않을 때 사용할 별도 연락·복구 경로를 마련하고, 대화 기록의 백업·복원도 확인한다.

❓ 열린 질문

• 서버와 에이전트가 더 늘어나도 Buzz 한곳에서의 관리가 충분할까? 어느 규모부터 Paperclip 같은 프로젝트 관리 구조가 필요해질까?
• 봇 무응답을 줄이면서 API 호출 비용도 제한하려면 어떤 호출·응답 설정이 적절할까?
• 필요한 규칙만 agent.md에 남긴 구성이 기존 하네스보다 시간과 토큰을 얼마나 절약하며, 테스트 품질은 유지할 수 있을까?