노트북을 닫으면 AI 답변도 멈춥니다 — Buzz를 직접 호스팅하고 상시 에이전트를 붙이는 기준

들어가며

금요일 밤에 정리 작업을 하나 걸어두고 노트북을 덮었습니다. 토요일 아침에 열어보니 채널은 그대로고, 답변은 없습니다. 서버에 올려둔 대화방은 멀쩡한데, 정작 일할 AI가 노트북 안에 있었기 때문입니다.

대화방을 직접 호스팅하기로 마음먹는 순간은 대개 여기입니다. 그런데 방을 서버로 옮기는 것과, 노트북 전원에서 벗어나는 것은 서로 다른 작업입니다. 둘 중 하나만 하면 증상은 그대로 남습니다.

이 글에서는 AI 에이전트용 업무 메신저 Buzz를 내 서버에 직접 올릴지 판단하는 기준과, 이미 돌고 있는 에이전트를 그 방에 합류시킬 때 실제로 막히는 지점을 정리했습니다. 비용을 어떻게 나눠 봐야 하는지, 처음에 정해두면 나중에 고생하지 않을 설정 네 가지도 함께 다룹니다.

멈추는 건 대화방이 아니라 일하는 쪽입니다

Buzz는 Block이 공개한 오픈소스 워크스페이스입니다. 공식 저장소는 이 도구를 사람과 AI 에이전트가 같은 방을 공유하는 셀프호스팅 워크스페이스라고 소개합니다. 채널을 나누고, 스레드를 달고, 파일을 주고받는 구조는 슬랙과 비슷합니다.

차이는 신원 방식입니다. Buzz에서는 사람도 AI도 **같은 종류의 키 한 쌍(공개키·개인키)**으로 방에 들어옵니다. 에이전트는 자기 키를 가지고, 누가 무슨 말을 했는지가 따로 기록됩니다.

그래서 구조를 볼 때는 두 자리를 나눠서 봐야 합니다. 대화가 오가는 방이 어디 있는지, 그리고 답을 만드는 AI가 어디서 도는지입니다. 이 둘은 같은 곳에 있을 필요가 없고, 실제로도 대부분 따로 있습니다.

B가 함정입니다. 서버비를 내고 방을 직접 올렸는데 증상이 그대로라서, "셀프호스팅해도 소용없더라"로 끝나는 경우가 여기서 나옵니다. 실제로 옮겨야 하는 건 답을 만드는 쪽입니다.

💡 노트북에서 도는 코딩 도구를 붙이는 방식은 처음 확인용으로는 편합니다. 이미 내고 있는 구독을 그대로 쓸 수 있어서 추가 비용도 없습니다. 다만 그 구성은 방이 어디 있든 노트북을 끄면 같이 멈춥니다.

직접 호스팅이 맞는 경우와, 아직 아닌 경우

Buzz는 Apache 2.0 라이선스 오픈소스입니다. 소프트웨어 자체에는 라이선스 비용이 없습니다. 하지만 직접 호스팅하면 서버 비용과 함께 관리 책임도 같이 옵니다.

구체적으로 보면 이렇습니다.

판단 기준은 하나입니다. 대화 데이터와 서버 구성을 직접 쥐는 것이, 백업과 복구를 직접 챙기는 부담보다 중요한가요? 여기에 "그렇다"고 답할 수 있으면 직접 호스팅이 맞습니다.

슬랙을 쓰고 있다면

슬랙을 대체하려고 옮기는 것은 권하지 않습니다. 사람끼리의 업무 협업에서는 슬랙이 훨씬 성숙한 도구이고, 안정성과 연동 폭도 다릅니다.

Buzz가 유리한 상황은 따로 있습니다. AI 에이전트와의 협업이 대화의 중심이고, 여러 종류의 에이전트를 붙였다 뗐다 하면서 쓰는 경우입니다. 에이전트를 사람처럼 멤버로 등록하고 권한을 따로 주는 구조가 이 용도에 맞습니다.

사람 대화가 중심이면 슬랙을 그대로 두고, 에이전트 실험용으로 Buzz를 따로 두는 편이 현실적입니다.

서버를 두 대로 나누는 이유

여기서 실수하기 쉬운 지점이 하나 있습니다. 이미 AI 에이전트가 돌고 있는 서버에 Buzz를 얹으려는 경우입니다.

호스팅사에서 제공하는 원클릭 설치에는 두 갈래가 있습니다. 하나는 Docker 관리 화면에서 컨테이너로 배포하는 방식이고, 다른 하나는 서버의 운영체제를 Buzz 템플릿으로 바꾸는 방식입니다.

두 번째는 위험합니다. Hostinger 공식 문서는 운영체제를 바꾸면 서버가 재설치되면서 기존 데이터가 영구적으로 삭제된다고 경고합니다. 진행하기 전에 백업하라는 문구가 같이 붙어 있습니다.

즉 에이전트가 이미 돌고 있는 서버의 OS를 바꾸면, 그동안 쌓인 설정·메모리·기록이 함께 사라질 수 있습니다. 그래서 Buzz용 서버는 새로 만드는 편이 안전합니다.

한쪽을 다시 올려야 할 일이 생겨도 다른 쪽 데이터로 번지지 않습니다. 역할이 다른 서비스를 나눠두는 이유는 대부분 이 하나입니다.

배포되는 건 하나가 아닙니다

Buzz를 올리면 컨테이너가 한 개만 뜨지 않습니다. 공식 저장소 기준으로 네 가지가 함께 올라갑니다.

직접 하나씩 세팅하면 손이 많이 가는 조합입니다. 호스팅사의 원클릭 템플릿은 Ubuntu와 Docker까지 포함해 이 묶음을 한 번에 올려줍니다. Hostinger 문서는 시작 사양으로 **vCPU 2코어·RAM 8GB급(KVM 2)**을 권장하고 있습니다.

배포는 원클릭인데, 막히는 곳은 따로 있습니다

배포 자체는 오래 걸리지 않습니다. 실제로 시간을 잡아먹는 구간은 AI를 그 방의 멤버로 들여보내는 절차입니다. 여기가 네 단계로 나뉘어 있고, 각각 실행하는 위치가 다릅니다.

회사에 새 직원이 들어오는 과정으로 보면 이해가 빠릅니다.

②는 Buzz 서버 쪽 관리자 명령으로 처리합니다. Buzz 앱 화면이 아니라, 배포된 relay 컨테이너의 터미널에서 실행합니다. 등록이 끝나면 같은 자리에서 멤버 목록을 조회해 실제로 들어갔는지 확인할 수 있습니다.

⚠ ②와 ④는 별개입니다. 커뮤니티 멤버 등록만 하고 채널에 초대하지 않으면, 채널 멤버 검색창에 에이전트 이름이 아예 뜨지 않습니다. "설정은 다 했는데 검색이 안 된다"는 대부분 이 지점입니다.

시작 전에 준비하는 값 두 가지

첫째, 관리자(나)의 공개키입니다. Buzz 데스크톱 앱을 설치하면 키 한 쌍이 만들어집니다. 배포 화면의 RELAY_OWNER_PUBKEY 칸에 넣는 값은 이 중 공개키이고, 64자 hex 형식이어야 합니다. 앱 화면에 npub...으로 시작하는 형식만 보인다면 hex로 변환한 값이 필요합니다.

둘째, 접속 주소입니다. 배포가 끝나면 Docker 관리 화면의 열기 링크에서 주소를 확인할 수 있습니다. 이 주소를 Buzz 앱에 넣을 때는 **https://**를 **wss://**로 바꿔서 넣습니다.

앱에서는 새 커뮤니티를 만드는 게 아니라 기존 커뮤니티에 참여하는 쪽을 선택합니다. 서버에 이미 커뮤니티가 만들어진 상태이기 때문입니다.

🔒 주소를 나중에 바꾸면 방이 새로 생깁니다. Hostinger 문서는 relay의 신원이 호스트명에서 파생되기 때문에, 배포 후 도메인을 바꾸면 별개의 새 커뮤니티가 시작된다고 안내합니다. 기존 대화가 옮겨가지 않습니다. 주소는 처음에 정해두십시오.

연결 방식은 세 가지, 하나만 고르면 됩니다

에이전트를 Buzz에 붙이는 방법은 여러 갈래입니다. Hermes Agent 공식 문서는 세 가지를 안내합니다.

공식 문서가 권장하는 것은 세 번째입니다. 가장 깊은 통합이고, Hermes의 기능을 하나도 잃지 않는 방식이라고 설명합니다. 승인 절차, 메모리, 세션 관리가 그대로 살아 있고 정기 작업 알림도 지정한 채널로 전달됩니다.

이미 쓰던 에이전트가 있다면 여기서 갈립니다. 그동안 쌓아둔 지시문·기억·스킬을 다시 만들 것인지, 그대로 가져갈 것인지가 방식마다 다릅니다.

프로필 하나당 신원 하나

에이전트를 여러 개 운영한다면 규칙이 하나 있습니다. 프로필마다 별도의 Buzz 키를 씁니다.

공식 문서는 어댑터가 relay 주소 + 공개키 쌍에 잠금을 건다고 설명합니다. 두 프로필이 실수로 같은 Buzz 신원을 쓰는 상황을 막기 위해서입니다. 하나의 키를 여러 에이전트가 공유하면 누가 말했는지 구분되지 않고, 권한도 따로 줄 수 없습니다.

먼저 확인할 것 — 발송용 CLI

가장 허무하게 막히는 지점입니다.

에이전트에 Buzz 연동 기능이 들어 있는 것과, 실제로 메시지를 밖으로 내보내는 것은 별개입니다. 공식 문서는 buzz 명령줄 도구가 PATH에 있거나 BUZZ_CLI_PATH로 위치가 지정돼 있어야 한다고 안내합니다. 이 도구는 Buzz 저장소에서 직접 빌드합니다.

이게 없으면 설정 화면상으로는 전부 끝난 것처럼 보이는데 답장만 나가지 않습니다. 키를 만들기 전에 먼저 확인하십시오.

처음에 정해두면 나중에 고생하지 않을 네 가지

연결이 되고 나면 곧바로 정해둘 것들이 있습니다. 나중에 바꾸려면 이미 사고가 난 뒤인 경우가 많습니다. 아래 네 가지는 대부분 제품 기본값이 아니라 권장 설정입니다. 설치했다고 자동으로 적용되지 않으니, 연결 직후에 한 번에 잡아두십시오.

1. 공용 채널에서는 부를 때만 답하게 합니다

require_mention을 켜면 채널에서 @로 지목했을 때만 응답합니다. 이걸 꺼두면 사람들끼리 나누는 대화에 계속 끼어듭니다. 공식 문서도 이 설정을 권장값으로 안내합니다.

2. 일을 시킬 수 있는 사람을 지정합니다

allow_all_users를 끄고, 허용할 공개키만 목록에 넣습니다. 커뮤니티가 커지면 "누구든 에이전트에게 일을 시킬 수 있는 상태"가 생각보다 빨리 문제가 됩니다.

3. 개인키는 대화창에 붙여넣지 않습니다

설정에 필요한 값 중 비밀로 다뤄야 하는 것은 개인키 하나입니다. 공식 문서는 이 값을 .env 파일에 두고 환경변수로만 전달하며, 명령 인자나 로그에 남지 않는다고 설명합니다.

메신저 창에 붙여넣으면 그 반대가 됩니다. 내 대화 기록에 남고, 상대 쪽에도 남고, 나중에 지워도 백업본에 남습니다. 설정 요청을 채팅으로 보내더라도 키 값 자체는 넣지 않는 편이 맞습니다.

4. 보내기·삭제·결제는 사람이 확인합니다

서버에서 계속 대기하는 것과, 사람 확인 없이 처리하는 것은 다릅니다. 메일 발송, 파일 삭제, 결제, 권한 변경처럼 되돌리기 어려운 동작은 마지막 버튼을 사람이 누르는 상태로 두십시오.

비용은 세 줄로 나눠서 보십시오

"오픈소스라 무료"라는 말은 정확히는 소프트웨어 라이선스 이야기입니다. 한 덩어리로 보면 판단이 안 되고, 셋으로 나누면 명확해집니다.

세 번째는 이미 지출하고 있을 가능성이 높습니다. 쓰던 구독을 그대로 붙이면 이 줄은 늘어나지 않습니다.

두 번째를 볼 때 주의할 점이 있습니다. VPS 요금표에 표시되는 월 요금은 총액을 개월 수로 나눈 월 환산가입니다. Hostinger 한국어 페이지도 "월별 요금은 상품의 총 가격을 상품의 개월 수로 나눈 값"이라고 명시하고 있습니다. 결제는 약정 기간분을 선불로 한 번에 하고, 갱신가는 첫 구매가와 다르게 표시됩니다.

기간을 길게 잡으면 월 환산가가 내려가지만, 처음 결제하는 금액은 올라갑니다. 화면의 총 결제액과 갱신가를 함께 확인하고 고르십시오.

데이터를 가져오면 백업도 같이 옵니다

직접 호스팅의 장점은 대화 이력과 파일이 내 서버에 남는다는 것입니다. 같은 문장이 단점이기도 합니다. 서버가 날아가면 같이 날아갑니다.

• 호스팅사 패널에서 스냅샷이나 백업을 만들 수 있는지 먼저 확인합니다
• 자동 백업 주기를 켤 수 있으면 켭니다
• 한 번은 실제로 복구를 시험해봅니다

스냅샷을 만들어두는 것과 그게 실제로 되살아나는 것은 다른 이야기입니다. 확인은 사고가 나기 전에 해두는 편이 낫습니다.

모바일은 되는 만큼만 기대하십시오

서버에 올려두면 노트북 없이도 요청을 보낼 수 있습니다. Buzz 앱의 페어링 기능으로 휴대폰이나 태블릿을 커뮤니티에 연결하면, 화면에 뜬 코드를 맞춰 확인하는 것으로 연결이 끝납니다.

다만 기대치는 조정하는 게 좋습니다. Buzz 공식 저장소는 기능별 성숙도를 이렇게 구분해 표기합니다.

데스크톱 앱처럼 지금도 쓰고 있는 것이 아래쪽 목록에 함께 있습니다. "못 쓴다"가 아니라 "아직 다듬는 중"이라는 표시로 보면 됩니다.

모바일에서 메시지를 보내고 답을 받는 것까지는 동작합니다. 다만 데스크톱과 같은 수준을 전제하고 업무를 짜지는 마십시오. 급한 확인과 짧은 지시 정도로 잡아두면 실망할 일이 적습니다.

자주 막히는 지점

화면 라벨과 메뉴 위치는 제품 업데이트에 따라 달라질 수 있습니다. 문서와 실제 화면이 다르면 화면을 기준으로 하십시오.

마무리

정리하면 이렇습니다.

• 방과 AI는 다른 자리입니다. 방만 서버로 옮기면 노트북을 닫았을 때 증상이 그대로 남습니다
• 이미 쓰는 서버를 덮지 마십시오. OS를 템플릿으로 바꾸면 기존 데이터가 지워질 수 있어서, Buzz용 서버는 새로 만드는 편이 안전합니다
• 막히는 곳은 배포가 아니라 합류 절차입니다. 키 생성 → 커뮤니티 멤버 등록 → 프로필 발행 → 채널 초대, 네 단계가 각각 다른 곳에서 일어납니다
• 연결 전에 발송용 CLI부터 확인하십시오. 없으면 설정이 끝난 것처럼 보이는데 답장만 안 나갑니다
• 비용은 소프트웨어·서버·모델 세 줄로 나눠 보십시오. 오픈소스라 무료인 것은 첫 번째 줄뿐입니다

이 구성이 없애는 것은 노트북 전원에 대한 의존입니다. 서버는 재부팅될 수 있고 네트워크는 끊길 수 있으니, 무중단 가동을 뜻하지는 않습니다. 사람 확인 없이 알아서 보내고 지운다는 뜻도 아닙니다. 요청을 받으면 노트북 상태와 무관하게 서버에서 응답한다, 여기까지가 정확한 표현입니다.

🎯 먼저 해볼 것: 지금 쓰는 구성이 앞의 표에서 A·B·C 중 무엇인지부터 확인해 보십시오. B라면 서버를 새로 사기 전에 AI가 도는 위치를 먼저 옮기는 것이 순서입니다.

화면을 따라가며 설치 과정을 보고 싶다면 아래 영상에 전 과정이 담겨 있습니다.

• 영상: Buzz와 Hermes Agent 연결하기 — 24시간 운영 구조 만들기

참고 자료 및 출처