들어가며
지난주에 Claude Code에게 계약서 조건을 검토시켰습니다. 그제는 같은 건을 Codex에게 다시 물어봤습니다. 결과물은 양쪽 다 남아 있습니다.
문제는 3주 뒤입니다. 거래처가 "그때 이 조항은 왜 넘어갔죠?"라고 물어봅니다. 결과 파일은 찾았는데, 그렇게 판단한 이유가 어디에도 없습니다. 터미널 스크롤백을 뒤지고, 어느 툴에 물어봤는지 기억을 더듬습니다. 결국 처음부터 다시 시킵니다.
도구가 부족해서 생긴 문제가 아닙니다. 결과가 남는 자리를 정하지 않아서 생긴 문제입니다.
이 글에서는 Block이 공개한 오픈소스 협업 도구 Buzz에 이미 쓰고 계신 Claude Code와 Codex를 붙여, 결과와 판단 근거를 한 채널에 모으는 방법을 정리했습니다. 도입할지 말지 정하는 기준과, 시작하기 전에 알아야 할 운영 조건도 함께 다룹니다.
흩어진 기록이 실제로 비용이 되는 지점
AI에게 일을 시키면 두 가지가 나옵니다. 결과물과 판단 근거입니다.
결과물은 대개 파일로 남습니다. 보고서, 표, 코드. 문제는 판단 근거입니다. 왜 그 조항이 문제인지, 어떤 자료를 근거로 삼았는지, 제가 중간에 무엇을 수정하라고 했는지는 그 도구의 대화창 안에만 남습니다.
이게 만드는 비용은 세 가지입니다.
| 상황 | 지금 어디에 남아 있나 | 3주 뒤에 찾을 수 있나 |
|---|---|---|
| AI가 낸 결론 | 결과 파일 | 찾을 수 있습니다 |
| 그렇게 판단한 근거 | 도구별 대화 기록 | 어느 도구인지부터 기억해야 합니다 |
| 제가 준 수정 지시 | 도구별 대화 기록 | 사실상 못 찾습니다 |
| 다른 사람에게 넘길 때 | 없음 | 제가 말로 다시 설명해야 합니다 |
두 번째 비용은 같은 질문을 반복한다는 것입니다. 근거를 못 찾으면 결국 다시 시킵니다. 답이 지난번과 미묘하게 달라도 알아채기 어렵습니다.
세 번째 비용은 혼자만 아는 상태로 굳는다는 것입니다. 직원이나 파트너에게 그 판단을 넘기려면, 결과물이 아니라 과정을 설명해야 합니다. 설명할 자료가 없으니 매번 제 입으로 옮깁니다.
💡 기록이 흩어지는 문제는 도구를 하나 더 사는 것으로 풀리지 않습니다. 결과와 근거가 쌓일 자리를 한 곳으로 정하는 것이 먼저입니다. Buzz는 그 자리를 채널로 만들어 주는 도구입니다.
Buzz가 실제로 하는 일
Buzz는 사람과 AI 에이전트가 같은 방을 쓰는 오픈소스 작업 공간입니다. 트위터를 공동 창업한 잭 도시(Jack Dorsey)가 세운 Block이 2026년 7월 21일에 공개했습니다. 라이선스는 Apache-2.0이고, 코드는 GitHub에 올라와 있습니다.
화면은 슬랙과 비슷합니다. 채널이 있고, 스레드가 있고, DM이 있습니다. 다른 점은 그 채널의 멤버에 AI 에이전트가 사람과 같은 자격으로 들어간다는 것입니다. 공식 발표문의 표현을 그대로 옮기면 이렇습니다.
"참여자는 사람이든 에이전트든, 플랫폼이 아니라 본인에게 귀속되는 암호 키 쌍을 갖습니다."
중요한 건 기존 도구를 바꾸지 않는다는 점입니다. Claude Code도 Codex도 쓰던 그대로입니다. 달라지는 건 그 결과가 내 터미널이 아니라 채널에 남는다는 것 하나입니다.
처음 설치하면 가장 헷갈리는 것: 방과 머리는 별개입니다
Buzz를 처음 켜면 선택지가 여러 개 나와서 헷갈립니다. 축이 두 개인데 하나로 보이기 때문입니다. 이 둘만 나눠 놓으면 나머지는 쉽습니다.
| 구분 | 무엇인가 | 어디서 도나 |
|---|---|---|
| 방 | 대화·근거·판정이 쌓이는 채널과 그 기록을 중계하는 서버 | Buzz가 제공하는 호스팅 커뮤니티 / 내 PC / 내가 올린 서버 중 선택 |
| 머리 | 실제로 생각하고 파일을 읽는 모델 | 내 컴퓨터에 설치된 Claude Code·Codex — 데스크톱 앱으로 붙이면 기본이 이쪽입니다 |
이 둘은 순서가 아니라 각각 고르는 항목입니다. 방을 어디에 둘지와 머리를 어디서 돌릴지를 따로 정하면 됩니다. 가장 쉬운 조합은 방은 Buzz 호스팅 커뮤니티, 머리는 내 노트북의 Claude Code·Codex입니다.
"호스팅해 준다니까 내 PC를 꺼도 돌아가겠구나" 하고 기대하기 쉽지만, 그렇지 않습니다.
| 호스팅 커뮤니티가 해주는 것 | 해주지 않는 것 |
|---|---|
| 메시지·채널·첨부 기록을 중계하고 보관 | 모델 실행. 데스크톱 앱으로 붙인 Claude Code·Codex는 여전히 내 컴퓨터에서 돕니다 |
계정 연결과 커뮤니티 주소 발급 (<이름>.communities.buzz.xyz) | 내 PC가 꺼져 있을 때 대신 응답 |
설정 화면에도 이 구분이 그대로 적혀 있습니다. "Buzz는 오픈소스이고, 이 계정의 중계 서버는 Builderlab이 호스팅합니다." 그리고 기기를 연결하는 단계에서 "개인키는 이 기기에 남습니다"라고 표시됩니다.
슬랙을 쓰고 있는데, 굳이 옮겨야 하나요
먼저 오해부터 풀겠습니다. 슬랙도 AI 에이전트를 잘 붙입니다. 공식 @Claude·@Codex 앱이 있고, 커스텀 에이전트도 만들 수 있으며, 에이전트가 다른 에이전트를 호출하는 도구 유형까지 공식 문서에 있습니다.
진짜 차이는 "되느냐 안 되느냐"가 아닙니다. 무엇이 어디서 도느냐입니다.
| 기준 | 슬랙 공식 앱 (@Claude·@Codex) | 슬랙 커스텀 에이전트 | Buzz |
|---|---|---|---|
| 무엇인가 | 벤더가 만든 기성 앱 | 내가 만드는 앱 | 내 PC의 CLI를 채널 멤버로 |
| 어디서 도나 | 벤더 클라우드 | 내가 정한 곳 | 내 컴퓨터 |
| 전제 조건 | 해당 플랜 + 연결된 GitHub 저장소·환경 | 앱 개발 + 서버 운영 | Buzz 앱 + 해당 CLI 설치 |
| 역할을 여러 개 나누기 | 앱이 제공하는 범위 안에서 | 만들면 됩니다 | 이름과 지시문으로 나눕니다 |
| 모바일에서 쓰기 | 슬랙 앱 그대로 | 슬랙 앱 그대로 | 모바일 클라이언트는 아직 작업 중 |
특히 헷갈리기 쉬운 두 가지를 짚고 갑니다.
- 슬랙의 **
@Claude**는 내 Claude Code CLI가 아닙니다. 공식 문서에 따르면 웹에서 Claude Code 세션을 새로 만들고, 내 계정과 연결된 저장소, 내 플랜 한도를 씁니다. 내 터미널 세션을 이어받는 게 아닙니다. - 슬랙의 **
@Codex**도 마찬가지입니다. 클라우드 챗을 만들며, 플랜과 연결된 GitHub 계정, 클라우드 환경이 필요합니다.
2026년 8월 기준으로 하나 더 알아두실 게 있습니다. Anthropic 공식 문서는 Team·Enterprise 워크스페이스에서 슬랙의 Claude Code가 Claude Tag로 대체되는 중이라고 공지하고 있습니다. Claude Tag는 @Claude를 조직 공유 ID로 실행하며 같은 슬랙 앱에서 동작합니다. 회사 계정으로 슬랙에 붙여 쓰실 계획이라면 이 전환 공지를 먼저 확인하시는 편이 좋습니다.
그래서 무엇을 고르나
승패 문제가 아니라 무게중심 문제입니다. 지금 무엇을 하고 계신지에 따라 답이 갈립니다.
- 이미 슬랙을 쓰고, 작업이 연결된 GitHub 저장소 기반 코딩이라면 공식 앱이 가장 빠릅니다.
- 내 PC에 깔린 CLI를 앱 개발 없이 여러 역할로 세우고 싶다면 Buzz가 더 직접적입니다.
- 지금 혼자 쓰고 결과를 아무에게도 넘기지 않는다면, 굳이 옮기지 않아도 됩니다.
결과 품질을 바꾸는 건 도구가 아니라 역할을 둘로 나누는 것
여기서부터가 실무에서 제일 중요합니다.
에이전트를 두세 개 만들면 더 똑똑해질 것 같지만, 아닙니다. 같은 모델로 에이전트를 두 개 만들면 이런 차이가 생깁니다.
| 달라지는 것 | 안 달라지는 것 |
|---|---|
| 각자의 암호 신원과 권한 | 모델의 추론 능력 |
| 지시문 (그 세션의 시스템 프롬프트) | 학습된 지식 |
| 하네스·모델·실행 위치 (고른 대로) | 같은 질문에 대한 기본 성향 |
| 채널 멤버십과 발언 기록 | 파일 작업 공간 — 로컬 에이전트는 같은 폴더를 씁니다 |
나누는 이유는 더 똑똑해지려는 게 아닙니다. 서로 다른 역할과 합격 기준을 주려는 것입니다.
자기가 쓴 초안은 자기가 못 뒤집습니다
한 에이전트에게 "네가 쓴 초안을 스스로 검토해봐"라고 하면, 대체로 자기 결론을 보강하는 방향으로 갑니다. 처음부터 다른 지시를 받은 두 번째 에이전트가 허점을 훨씬 잘 잡습니다. 사람도 마찬가지입니다.
그래서 실제로 쓸 만한 구성은 이렇습니다.
- 해석 담당: 원문을 요건별로 읽고, 항목마다 조항 번호와 출처 파일명을 붙입니다. 최종 판정은 내리지 않습니다.
- 반박 담당: 해석 결과를 믿지 않고 원문을 다시 읽어 대조합니다. 동의하는 게 아니라 허점을 찾는 것이 이 에이전트의 일입니다.
- 사람: 마지막 판정을 하고, 그 이유를 채널에 남깁니다.
저는 해석 담당에 Claude Code를, 반박 담당에 Codex를 붙였습니다. 일부러 다르게 골랐습니다.
지시문에 반드시 들어가야 하는 세 가지
두 에이전트를 세우는 것만으로는 원하는 대로 돌지 않습니다. 실제로 굴려 보면 아래 세 줄이 있느냐 없느냐가 결과를 가릅니다.
첫째, 먼저 기다리라는 규칙. 한 메시지에서 두 명을 동시에 멘션해도 순서가 정해지지 않습니다. 각 에이전트는 자기를 부르는 멘션을 독립적으로 감지하기 때문입니다. 실제로 반박 담당이 해석 결과도 없이 혼자 점검을 시작하는 화면을 봤습니다. 그래서 반박 담당 지시문 맨 앞에 이렇게 넣었습니다.
스레드에 해석 담당의 결과가 아직 없으면 반박을 시작하지 않는다.
"해석 담당 결과를 기다리겠습니다." 한 줄만 남기고 종료한다.
아무도 멘션하지 않는다.
순서는 최초의 두 멘션이 만드는 게 아닙니다. 이 대기 규칙과, 해석 담당이 작업을 마친 뒤 보내는 후속 멘션이 만듭니다.
둘째, 근거를 붙이라는 규칙. 근거 없는 판단은 검증이 불가능합니다. 두 에이전트 모두에게 같은 조건을 겁니다.
모든 판단에 조항 번호와 출처 파일명을 붙인다.
수치와 날짜는 계산 과정을 한 줄로 같이 쓴다.
확실하지 않은 항목은 "확인 필요"로 표시하고 단정하지 않는다.
셋째, 왕복 횟수 상한. 이게 없으면 두 에이전트가 서로를 계속 부르며 도는 구간이 생깁니다. 토큰과 시간이 그대로 나갑니다.
재해석 요청은 케이스당 1회까지다.
2차 반박에서는 상대를 다시 멘션하지 않는다.
남은 이견은 사람 판단으로 넘긴다.
세 번째 규칙의 "1회"는 제품이 정해 준 값이 아니라 제가 정한 운영값입니다. 업무 성격에 따라 2회로 늘려도 되고, 아예 왕복 없이 1차 반박에서 사람 판정으로 끝내도 됩니다. 중요한 건 숫자가 아니라 상한이 있다는 것입니다.
자주 나오는 실패 세 가지
| 증상 | 원인 | 고치는 곳 |
|---|---|---|
| 반박 담당이 해석도 없이 먼저 시작합니다 | 대기 규칙이 없습니다 | 반박 담당 지시문 맨 앞 |
| 둘이 서로를 계속 부릅니다 | 왕복 상한이 없습니다 | 양쪽 지시문에 상한 한 줄 |
| 멘션해도 상대가 안 깨어납니다 | 지시문에 쓴 이름과 실제 표시 이름이 다릅니다 | 에이전트 카드의 표시 이름 |
이 패턴은 Buzz 밖에서도 씁니다
여기가 중요합니다. 해석과 반박을 나누는 것은 Buzz의 기능이 아니라 일 시키는 방식입니다. 도구를 바꾸지 않아도 오늘 바로 해볼 수 있습니다.
- 지금 쓰는 AI에서 새 대화창을 하나 더 열고, 앞 대화 결과를 붙여넣은 뒤 "이 판단의 허점을 원문 기준으로 찾아줘"라고 요청합니다.
- 두 번째 대화창에는 원문도 같이 줍니다. 첫 결과만 주면 검토가 아니라 동조가 됩니다.
- 서로 다른 회사 모델을 쓰면 더 좋습니다. 같은 모델이면 같은 방식으로 틀립니다.
Buzz가 더해 주는 건 이 왕복이 한 스레드에 그대로 쌓인다는 것입니다. 나중에 그 스레드만 열면 결론과 근거와 반론이 한눈에 보입니다.
내가 쌓아둔 CLAUDE.md와 스킬은 그대로 따라오나요
Claude Code를 오래 쓰신 분이 가장 먼저 하는 질문입니다. 답은 절반만 따라옵니다.
Buzz의 로컬 에이전트는 작업 폴더를 고르는 입력란이 없습니다. 이 글을 쓰며 확인한 desktop-v0.5.8의 에이전트 설정 화면에도 그 항목이 없고, 기본 작업 폴더는 ~/.buzz입니다. 이 하나가 아래 결과를 전부 설명합니다.
| 도구 | 따라오는 것 | 따라오지 않는 것 |
|---|---|---|
| Claude Code | 전역 지침 ~/.claude/CLAUDE.md, 전역 스킬 ~/.claude/skills | 다른 저장소의 프로젝트 지침과 스킬 |
| Codex | 전역 ~/.codex/AGENTS.override.md 또는 ~/.codex/AGENTS.md 중 첫 파일 하나 | 다른 저장소의 AGENTS.md, 저장소별 스킬 |
Claude Code 공식 문서는 프로젝트 지침을 현재 작업 디렉토리에서 위로 올라가며 찾는다고 설명합니다. Codex는 git 루트에서 아래로 내려오며 이어붙입니다. 어느 쪽이든 기준점이 작업 디렉토리입니다. Buzz의 작업 디렉토리가 ~/.buzz이니, 제 프로젝트 폴더에 있는 지침은 시야 밖에 있는 셈입니다.
실무에서 쓸 처방은 두 줄입니다.
- 어디서든 항상 적용돼야 하는 규칙은 전역 지침 파일에 둡니다. 그러면 Buzz 세션에서도 그대로 읽힙니다.
- 이번 일에만 필요한 규칙과 자료는
~/.buzz아래에 폴더를 만들어 둡니다.
참고로 Buzz가 자동으로 깔아 주는 스킬은 자기 CLI 사용법 하나뿐입니다. 나머지는 제가 둔 대로 동작합니다. Buzz가 관리하는 AGENTS.md 구간에는 시작과 끝 표시가 붙어 있고, 제가 직접 쓴 내용은 업데이트가 돌아도 보존됩니다.
자료는 채널에 첨부하지 말고 폴더에 두십시오
에이전트가 읽어야 할 자료는 채널 첨부가 아니라 로컬 폴더에 두시는 편이 확실합니다. 그리고 폴더를 두 갈래로 나누는 것을 권합니다.
| 폴더 | 무엇을 넣나 | 언제 바뀌나 |
|---|---|---|
| 상시 정보 | 사업자 정보, 과거 이력처럼 잘 안 바뀌는 것 | 거의 안 바뀝니다 |
| 건별 정보 | 이번 공고문, 이번 달 인원·매출, 이번 건 서류 현황 | 건마다 새 폴더 |
한 파일에 잘 안 바뀌는 정보와 시점 정보를 섞어두면, 그 파일을 계속 참고하는 순간 작년 숫자를 그대로 읽는 사고가 납니다. 나눠 두면 덤이 하나 더 생깁니다. 에이전트가 두 폴더를 대조해야만 답이 나오는 구조가 되어서, 대충 넘어간 항목이 드러납니다.
파일에 판정 결과나 힌트는 적지 마십시오. 개업일은 적되 "업력 1년 미만"이라는 결론은 적지 않습니다. 그 계산을 에이전트가 해야 검증이 됩니다.
시작하기 전에 확인할 다섯 가지
미리 알고 시작하시는 편이 좋습니다. 아래 다섯 가지를 모르고 시작하면 실망하십니다.
1. 앱을 끄면 에이전트도 내려갑니다. 데스크톱 앱이 띄운 로컬 에이전트는 앱을 끄면 같이 내려갑니다. 중계 서버를 내 서버로 옮겨도 이 사실은 바뀌지 않습니다. 상시 응답이 필요하면 모델을 실행하는 쪽을 항상 켜져 있는 컴퓨터에 따로 두는 구성이 필요합니다. 처음 도입에서는 여기까지 가지 않는 편이 좋습니다.
2. 승인 흐름이 아직 정리되는 중입니다. 공식 저장소는 워크플로 승인 처리를 "기반은 있고 연결이 아직 마르는 중"이라고 표시하고 있습니다. 권한 요청을 처리하는 방식도 아직 확정 전입니다. 슬랙이나 텔레그램처럼 버튼이 떠서 누르면 통과되는 흐름은 아직 기대하지 마십시오. 보내기, 삭제, 결제, 권한 변경처럼 되돌리기 어려운 작업은 마지막 버튼을 사람이 직접 누르셔야 합니다.
3. 화면이 이미 다를 수 있습니다. 2026년 7월 28일부터 8월 8일까지 12일 동안 데스크톱 릴리스가 9번 올라왔습니다. 이 글을 쓴 2026년 8월 10일 기준 최신 버전은 8월 8일에 올라온 desktop-v0.5.8이고, 이 릴리스에는 에이전트 추가 흐름을 하나로 합쳤다는 변경이 들어 있습니다. 어떤 가이드를 보시든 캡처 화면과 실제 앱이 다를 가능성이 높습니다. 메뉴 이름보다 무엇을 정하는 단계인지를 기준으로 따라가시는 편이 빠릅니다.
4. 호스팅 커뮤니티는 계정당 5개까지입니다. 테스트로 여러 개 만들다 보면 금방 걸립니다. 이름도 주소가 되니 처음부터 쓸 이름으로 만드시는 편이 낫습니다. 저장 용량과 보관 기간에도 제한이 걸려 있으니 생성 화면에서 직접 확인하십시오.
5. 계정과 요금은 별개입니다. Buzz 소프트웨어는 Apache-2.0 오픈소스입니다. 하지만 그것과 호스팅 서비스 요금은 다른 이야기이고, Claude Code와 Codex는 각각 자기 계정·플랜·사용량이 그대로 필요합니다. Buzz를 붙인다고 새로 결제할 게 없어지지도, 기존 결제가 없어지지도 않습니다.
⚠ 한 가지만 헷갈리지 않으시면 됩니다. Buzz는 밤새 혼자 출근하는 직원이 아닙니다. 내 컴퓨터가 켜져 있고 앱이 떠 있는 동안, 내가 부른 일을 채널에 기록하며 처리하는 구조입니다. 상시 대기가 필요한 업무라면 그건 Buzz 도입이 아니라 별도 구성 문제입니다.
어디부터 써보면 좋은가
역할을 나눈 검토 구조가 값을 하는 업무에는 공통점이 있습니다. 원문이 있고, 조건이 여러 개고, 틀리면 비용이 큰 일입니다.
| 업무 | 해석 담당이 하는 일 | 반박 담당이 하는 일 |
|---|---|---|
| 지원사업·입찰 공고 자격 예비 검토 | 요건별로 신청 가능 여부를 조항 번호와 함께 정리 | 제외 조건·서류 누락·기간 계산을 원문으로 다시 대조 |
| 계약서·약관 조건 검토 | 우리에게 불리한 조항을 근거와 함께 목록화 | 놓친 조항, 과장된 해석, 근거 없는 지적을 걸러냄 |
| 견적·단가표 대조 | 항목별 단가와 합계를 계산 과정과 함께 정리 | 단위·수량·할인 적용 순서를 다시 계산 |
세 경우 모두 최종 판정은 사람이 합니다. AI가 낸 것은 예비 검토입니다. 계약과 신청 자격은 상대 기관과 공식 문서로 다시 확인하셔야 합니다.
첫 주에 해볼 순서
한 번에 다 세우려 하면 중간에 멈춥니다. 순서는 이렇게 잡으시면 됩니다.
- 이미 끝난 일을 하나 고릅니다. 결과를 아는 건으로 시작해야 AI가 제대로 했는지 판단할 수 있습니다.
- 자료를 폴더 두 개로 나눠 넣습니다. 상시 정보와 이번 건 정보를 섞지 않습니다.
- 에이전트 두 개를 만듭니다. 이름을 정하고, 위에 정리한 세 가지 규칙을 지시문에 넣습니다.
- 한 줄로 요청합니다. 경로도 출력 형식도 매번 쓰지 않습니다. 그건 이미 지시문에 있습니다.
- 결과를 아는 답과 대조합니다. 여기서 어긋나는 항목이 그대로 다음 지시문 수정 목록이 됩니다.
마무리
이 글에서 다룬 핵심을 정리합니다.
- 문제는 도구 개수가 아니라 결과가 남는 자리입니다. 결론은 파일로 남지만 판단 근거는 도구별 대화창에만 남습니다. 그 근거를 못 찾아서 같은 일을 다시 시키게 됩니다.
- Buzz에서는 방과 머리가 별개입니다. 호스팅 커뮤니티가 대신해 주는 것은 기록 중계이고, 데스크톱 앱으로 붙인 모델은 여전히 내 컴퓨터에서 돕니다. 내 PC를 끄면 에이전트도 멈춥니다.
- 결과 품질을 바꾸는 건 역할을 둘로 나누는 것입니다. 해석과 반박을 다른 에이전트에 맡기고, 지시문에 대기 규칙·근거 규칙·왕복 상한 세 줄을 넣습니다. 이 방식은 Buzz 없이도 새 대화창 하나로 오늘 해볼 수 있습니다.
- 전역 설정은 따라오고, 다른 저장소의 프로젝트 설정은 따라오지 않습니다. 항상 쓸 규칙은 전역에, 이번 일 자료는
~/.buzz아래에 둡니다. - 되돌리기 어려운 작업은 사람이 누릅니다. 승인 처리 기능이 아직 완성 전이라, 보내기·삭제·결제는 채널에서 확인하고 직접 실행하시는 편이 안전합니다.
생산성은 도구를 하나 더 붙여서 올라가지 않습니다. 결과와 근거가 어디에 쌓일지 정하고, 누가 무엇을 검토할지 나누는 것이 실제로 일을 바꿉니다. Buzz는 그 자리를 만들어 주는 도구 중 하나이고, 지금은 아직 빠르게 바뀌는 중입니다.
🎯 오늘 해보실 수 있는 것 하나. 지금 AI에게 맡기는 일 중 가장 중요한 것 하나를 고르십시오. 결과를 받은 다음, 새 대화창을 열고 원문과 함께 붙여넣어 "이 판단의 허점을 원문 기준으로 찾아줘"라고 요청해 보십시오. 반박이 몇 개 나오는지가, 그 업무를 AI에게 어디까지 맡겨도 되는지 알려줍니다. 도구를 옮기는 건 그다음에 정해도 늦지 않습니다.
참고 자료 및 출처
| 자료 | 확인한 내용 | 링크 |
|---|---|---|
| Buzz (Block) — 공개 발표·저장소·릴리스·원격 실행 문서 | 2026-07-21 공개, Apache-2.0, 참여자별 암호 키 쌍, 기능 상태 표(모바일 클라이언트·승인 처리 작업 중), 2026-07-28~08-08 데스크톱 릴리스 9회와 에이전트 추가 흐름 변경, 중계 서버의 역할과 원격 실행 조건 | 공개 발표 · GitHub 저장소 · 릴리스 · 원격 에이전트 문서 |
| Claude Code 공식 문서 (한국어) | 전역 지침 ~/.claude/CLAUDE.md 로드, 프로젝트 지침을 작업 디렉토리에서 위로 올라가며 탐색, AGENTS.md가 아닌 CLAUDE.md를 읽는다는 점 / 슬랙 @Claude가 웹에서 세션을 만들고 내 계정·연결 저장소·플랜 한도를 쓴다는 점, Team·Enterprise의 Claude Tag 전환 공지 | 메모리·설정 로딩 · Slack의 Claude Code |
| OpenAI Codex 공식 문서 | 전역 AGENTS.override.md 또는 AGENTS.md 중 첫 파일 하나만 읽고, 프로젝트 파일은 git 루트에서 아래로 이어붙인다는 점 / 슬랙 @Codex가 클라우드 챗을 만들며 플랜·GitHub 계정·클라우드 환경이 필요하다는 점 | AGENTS.md 설정 · Codex in Slack |
| Slack 개발자 문서 | 슬랙이 에이전트 전용 화면과 커스텀 에이전트를 제공하고, 에이전트가 다른 에이전트를 호출하는 도구 유형까지 문서화하고 있다는 점 | AI 개요 · 에이전트 만들기 |
본문의 화면 구성과 실패 사례는 Buzz Desktop을 직접 설치해 확인한 내용입니다. 버전이 빠르게 바뀌는 제품이라, 설정 항목 이름은 사용하시는 버전에서 다시 확인하시는 편이 좋습니다.
설치와 설정 화면을 눈으로 보고 싶으시다면 영상으로도 정리해 두었습니다 — 요즘 가장 핫한 AI툴 Buzz, 클로드코드·코덱스를 한 팀으로 쓰는 법!
