이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가,  비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

잭 도시가 만든 새 협업 앱 Buzz의 기본 팀원 세 명은 사람이 아닙니다. Fizz는 만들고, Honey는 글을 쓰고, Bumble은 조사해요. 블록(Block)이 2026년 7월 21일에 공개한 이 앱은 채팅창 안에 AI 에이전트를 동료로 앉혀 놓고, 그 아래에서 돌아가는 엔진은 언제든 갈아 끼울 수 있게 만들었습니다.

공개되자마자 "슬랙 킬러"라는 별명이 붙었는데, 정작 먼저 써 본 사람은 그 표현이 핵심을 비껴간다고 말해요. 그렉 아이젠버그(Greg Isenberg)가 풀스택 프레임워크 Wasp의 개발자 릴레이션 담당이자 Open SaaS를 만든 빈스 캥거를 불러 화면을 함께 열었습니다. 채팅 몇 줄로 CRM 앱이 만들어져 인터넷에 올라가는 과정까지 함께 살펴봤습니다.

슬랙 킬러라는 이름표

Q. 이번 대화에서 사람들이 뭘 얻어 갔으면 하세요?

Buzz를 어떻게 쓰는지를 가져가면 좋겠어요. 지금 Buzz가 가장 잘 맞는 지점은 솔로프리너(1인 창업가)와 소규모 팀이라고 봅니다. 브레인스토밍을 하고, 여러 에이전트 사이에 맥락을 계속 유지하면서, 제품이나 해결책을 만들고 아이디어를 굴려 보는 용도요. 결국은 뭔가를 더 빨리 세상에 내놓고 더 많이 해내는 데 쓰는 도구입니다.

Q. 저는 이 대화에서 Buzz가 뭔지, 왜 중요한지, 에이전트한테 실제로 일을 시키는 요령까지 알고 싶어요. 그리고 끝났을 때 이걸 써야 할지 아니면 그냥 슬랙을 계속 쓸지 판단이 서면 좋겠습니다. 가능할까요?

가능할 것 같아요. 다만 시작하기 전에 하나 짚고 싶은 게 있습니다. "슬랙 킬러"라는 건 카피로는 잘 뽑은 말이에요. 그런데 제가 Buzz를 처음 봤을 때 마음이 움직인 지점은 거기가 아니었거든요. 저한테 진짜 셀링 포인트는 이게 열려 있다는 점이었어요. 그 개방성이 얼마나 강력한지부터 이야기하고 싶습니다.

Q. 좋아요. 그럼 Buzz를 저한테 한번 팔아 보세요.

첫 번째로, Buzz는 에이전트가 안에 들어와 있는 슬랙이에요. 많은 분들이 딱 그렇게 말합니다. "슬랙인데 에이전트가 들어 있는 거네"라고요. 사실 슬랙에서도 통합 기능을 하나 붙이면 비슷한 걸 할 수 있긴 합니다. 다만 그건 어디까지나 밖에서 끼워 넣는 방식이에요.

그런데 Buzz에서는 에이전트가 1급 시민(first class citizen, 부가 기능이 아니라 시스템의 핵심 구성원)입니다. 팀원인 거예요. 부가 기능이나 곁다리 기능으로 생각하지 않습니다. 앱의 필수적인 일부고, 당신 팀의 일부예요. 그렇게 생각하시면 됩니다.

Q. 앱을 처음 켜면 뭐가 보이나요?

처음 시작하면 기본으로 딸려 오는 에이전트들이 보여요. 저도 이걸 쓴 지 그렇게 오래되지 않았습니다. 나온 지 얼마 안 된 앱이기도 하고요. 저는 원래 뭐든 단순하게 쓰는 편이라 기본 상태 그대로 두고 시작했어요. 그런데 겉으로 보이는 것 아래에 훨씬 강력한 게 하나 있습니다. 에이전트를 직접 수정하고 새로 추가할 수 있다는 거예요.

엔진을 갈아 끼워도 대화는 남는다

Q. 에이전트를 직접 만든다는 게, 성격만 정해 주는 수준인가요?

에이전트한테 지시문(instructions)을 주는 건 결국 시스템 프롬프트를 쓰는 것과 같아요. 그건 그렇게 특별하지 않습니다. 진짜 재미있는 건 그 아래에 깔린 하네스(harness)예요. 우리는 지금 다들 코덱스나 클로드 코드, 아니면 오픈코드(OpenCode) 같은 걸로 코딩 작업을 하고 제품을 만들고 있잖아요. Buzz에서 좋은 점은 이 하네스를 에이전트 아래에서 통째로 바꿔 끼울 수 있다는 겁니다. 여기 들어가서 "나는 클로드 코드를 쓰겠다", "코덱스를 쓰겠다", "구스(goose, 블록이 만든 오픈소스 에이전트)를 쓰겠다"라고 고를 수 있어요. 저는 이 지점에서 이미 "이건 꽤 괜찮은데"라고 생각했습니다.

Q. 하네스를 바꿀 수 있다는 게 왜 그렇게 큰가요?

AI가 워낙 빠르게 움직이니까요. 이 소식을 챙겨 보는 분들은 다 아실 텐데, 오늘은 이 모델이고 내일은 저 모델입니다. 저는 개인적으로 모델 피로(model fatigue)를 느껴요. "이제 막 이쪽으로 옮겼는데, 이 모델에 겨우 익숙해졌는데" 하는 상태가 되는 거죠.

그러다 보면 모델 X가 얼마나 좋은지 듣고 싶지도 않아집니다. 저는 아직 모델 Y를 쓰고 있으니까요. Buzz가 좋은 건 그 위에 한 겹을 덮어 놓고, 아래 엔진은 그냥 바꾸면 되게 만들어 놨다는 거예요. 새 모델이 나왔다는 소식에 매번 이사 준비를 하지 않아도 되는 겁니다.

Q. 바꿀 때 잃는 건 없나요?

그게 제일 좋은 부분입니다. 하네스를 바꿔도 잃는 게 없어요. 에이전트 아래의 엔진을 교체해도 채팅 안에 쌓인 모든 맥락이 그대로 남습니다. 그 에이전트랑 나눈 대화, 시도해 본 것들, 만들고 있던 앱까지 전부 새 하네스, 새 모델로 딸려 옵니다. 그래서 저는 이 부분이 Buzz에서 정말 괜찮다고 생각해요.

Q. 다들 모델과 하네스 사이를 왔다 갔다 하면서 지치는 게 사실이죠. 새 모델로 옮길 때마다 맥락을 처음부터 다시 쌓아야 하니까요. 이런 걸 제품 안에 기본으로 넣었다는 게 인상적인데, 기존에 쓰던 자산들은 어떻게 되나요?

쌓아 놓은 걸 전부 들고 갈 수 있어요. 스킬이나 스킬 폴더를 만들어 두셨다면, 그게 프로젝트 전용이 아니라 전역 디렉토리에 있어서 어디서나 접근 가능한 상태이기만 하면 Buzz가 그대로 읽어 옵니다. 에이전트 스킬을 평소처럼 설치해 두고, 그다음에 하네스를 바꾸고 모델을 바꿔도 채팅 안의 에이전트들이 그 스킬에 전부 접근할 수 있어요. 저는 이게 참 마음에 듭니다.

에이전트와 목소리로 회의하기

Q. 또 하나 눈여겨보고 있는 기능이 있다면요?

에이전트와 함께하는 오디오 허들(audio huddle, 채팅방에서 바로 여는 음성 통화)이 있어요. 에이전트와 음성으로 대화할 수 있고, 에이전트도 채팅방 안에 있으니 대답을 해 줍니다. 다른 사람과 음성 통화를 하다가 에이전트를 불러들여서 같이 이야기할 수 있어요. 그리고 그 에이전트는 오디오 허들 안에서도 그동안 쌓인 채팅 전체의 맥락을 그대로 가지고 있습니다. 저는 아직 직접 써 보지는 않았어요. 유튜브에 이 기능을 처음부터 끝까지 보여 주는 영상이 몇 개 있으니 그걸 참고하셔도 좋습니다.

Q. 저는 라이브로 대화가 오가야 머릿속 생각이 밖으로 나오는 편이라 허들이 반갑네요. 타이핑이든 받아쓰기든 결국 한 번 말하고 기다리는 식이니까요. 그럼 에이전트한테 실제로 일을 시키는 쪽은 어떤가요?

바로 그 아래에 에이전트들이 있고, 당연히 이들이 실제로 일을 해 주기를 바라실 거예요. Buzz는 깃(Git)을 꽤 단단하게 묶어 놨습니다. 에이전트가 코딩을 할 때 프로젝트를 만들고, 피처 브랜치(feature branch)를 만들고, 워크트리(worktree)에서 병렬로 작업합니다. 그러니까 내 컴퓨터에 있는 원본 파일을 건드리지 않아요. 복사본을 하나 떠서 거기서 작업합니다.

Q. 병렬로 작업한다는 게 실제로는 어떤 그림인가요?

예를 들어 동료와 제품 UI나 웹페이지 디자인 얘기를 하고 있다고 해 볼게요. 그 상태에서 에이전트한테 "지금 이 채팅에서 우리가 나눈 아이디어를 바탕으로 랜딩 페이지 세 가지 버전을 만들어 봐"라고 시키면 됩니다.

각각 다른 워크트리에서 동시에 만들어지니까 서로 부딪히지 않아요. 내 컴퓨터에 있는 파일은 그대로 두고 복사본 쪽에서만 손을 대는 거라서, 세 가지가 한꺼번에 돌아가도 원본이 망가질 걱정은 하지 않아도 됩니다.

Q. 만들어진 결과물은 어디서 보나요?

프로젝트 뷰가 최근에 추가됐어요. 설정에 들어가면 실험적 기능(experiments)을 켤 수 있는 항목이 있는데, 거기서 워크플로우와 프로젝트를 켜면 화면에 나타납니다. 에이전트와 함께 코딩하고 작업 중인 앱들이 여기에 모이는 구조예요.

Q. 코드를 어디에 저장하는 건가요? 깃허브를 쓰나요?

깃허브(GitHub)와 연동할 수도 있는데, 그 아래에는 Buzz 자체 깃 호스팅이 따로 있습니다. 그래서 내 릴레이(relay, Buzz에서 대화와 데이터가 오가고 저장되는 서버) 위에 있는 원격 저장소로 코드를 올릴 수 있어요. 조금 기술적인 얘기이긴 한데, Buzz는 릴레이 위에서 돌아갑니다. 릴레이는 내가 직접 띄우거나 블록이 대신 띄워 주는 서버예요. 에이전트가 만든 코드는 그 릴레이 위의 원격 저장소로 올라갑니다.

Q. 그럼 릴레이에는 코드만 있는 게 아니겠네요?

릴레이가 내 정보 전부가 있는 곳이에요. 모든 채팅, 모든 것이 거기서 일어나고 거기에 저장됩니다. 그리고 거기서 나와 대화하는 다른 사람들, 나와 대화하는 에이전트들에게 전달되고요. 그래서 저는 이들이 앞으로 슬랙 하나만 노리는 게 아니라고 봅니다. 깃허브까지 같이 노리고 있어요. 꽤 대담한 시도죠.

Q. 요즘은 비개발자 지인들도 깃허브를 쓰기 시작하더라고요. 10년 전만 해도 "레포(repo)"라고 하면 "내 차 압류하러 왔냐"고 되묻던 사람들인데요. 실제로 비개발자도 쓸 수 있나요?

오히려 이걸 그렇게까지 잘 알 필요가 없다는 게 재미있는 부분이에요. 저는 대체로 개발자들 사이에만 있어서 바깥 분위기는 잘 모르지만, 깃 쪽은 아예 신경 쓰지 않아도 됩니다. 에이전트가 알아서 처리해 주거든요.

저도 여기서 이것저것 시켜 봤는데, 예를 들어 간단한 CRM(고객 관리) 앱을 하나 띄워 달라고 했어요.

Q. 실제로 어떻게 시키셨나요?

"여기 이 채팅을 보고, Wasp 풀스택 프레임워크로 간단한 CRM 앱을 만들어서 레일웨이(Railway, 코드를 올리면 바로 웹에 띄워 주는 호스팅 서비스)에 배포해 줘"라고 했습니다. 물론 여기엔 어느 정도 기술 지식이 들어가 있어요. 특정 프레임워크와 특정 호스팅 업체를 제가 지정했으니까요. 그런데 그걸 다 해냅니다. 코드를 가져다가 원격 저장소에 올리고, 웹에 실제로 배포하고, 심지어 스크린샷까지 보내 줘요. "여기 당신 CRM입니다, 제가 방금 만든 겁니다" 하는 식으로요. 제가 뭘 하고 있는지 확인하기도 전에 이미 끝나 있었어요. 링크를 주고, 미리보기까지 붙여서요. 저는 그게 꽤 인상적이었습니다.

Q. 지시 한 줄에서 배포까지 한 번에 갔다는 게 놀라운데, 어떻게 그게 가능한 걸까요?

에이전트 쪽에 워크플로우와 프롬프트를 이미 많이 심어 놓은 것 같아요. 그래서 이 에이전트들이 처음부터 끝까지 한 흐름으로 일을 굴리면서 실제로 과제를 끝낼 수 있는 거죠. 만드는 사람들이 노린 방향도 그거라고 봅니다.

Q. 만들어 놓고 보니 어떤 생각이 드셨어요?

이미 인터넷에 살아 있는 상태라는 게 크죠. 물론 저는 레일웨이 계정이 이미 있었고, 풀스택 앱을 다루는 법도 조금은 압니다. 그런데 제가 알려 준 건 별로 없어요. "채팅 보이지, 이걸 온라인에 올려"라고만 했거든요. 그러니까 이제 저는 팀원들과 공유할 수 있는, 제대로 돌아가는 CRM 대시보드를 갖게 된 겁니다.

Q. 팀원을 불러온 다음엔 뭘 하나요?

그 채팅방에 팀원들을 추가하고, 어떤 기능이 빠졌는지 뭐가 마음에 안 드는지 이야기하기 시작하면 됩니다. 대화를 나누고 결론이 나면, 그 자리에서 에이전트한테 작업을 시작하라고 시키면 돼요. 그러면 그대로 합니다.

이게 왜 큰일이냐면, 소프트웨어를 그 자리에서 자동으로 만들어 낼 수 있다는 뜻이기 때문이에요. 그것도 품질이 어느 정도 나오고, 배포까지 되고, 한눈에 들어오는 화면에서 관리할 수 있는 상태로요. 회의에서 나온 이야기와 만들어진 결과물 사이의 거리가 거의 사라지는 겁니다.

트윗 대시보드: 컨텍스트를 한 바퀴 돌리는 법

Q. 예를 들어 에이전시를 운영한다면 제안서가 사업의 생명줄이잖아요. 그래놀라(Granola, 회의 내용을 자동으로 받아 적어 주는 AI 노트 앱) 같은 데서 나온 미팅 노트를 넣으면, 에이전트가 그 자리에서 고객사별 제안서를 만들어 주는 그림이 되겠네요. 비슷한 걸 실제로 해 보셨나요?

네, 정확히 그렇습니다. 맥락이 이쪽으로 들어오고, 그게 코드로 만들어진 결과물로 인터넷에 올라가고, 그걸 다시 어디서 보느냐까지가 하나로 이어지는 거죠. 제가 트위터에 올린 영상에서 다룬 게 정확히 그 흐름이었어요.

저는 마케팅 쪽 각도로 접근해서 트윗 리더보드를 하나 만들었습니다. 우리 팀이 얼마나 트윗을 올리는지, 성과가 어떤지, 잘 나간 트윗은 뭔지 같은 정보를 전부 이 풀스택 앱에 모으는 거였어요.

Q. 만들어 놓고 나서 한 단계 더 나갔다고 하셨는데요.

만들기만 하고 끝낼 게 아니라, Buzz가 그 앱에 접속해서 정보를 가져오게 하면 어떨까 싶었어요. 그러면 여기서 매일 리뷰나 다이제스트를 받아 볼 수 있고, 트위터 마케팅 전략에서 뭐가 먹히고 뭐가 안 먹히는지 같이 궁리할 수도 있으니까요. 잘 나간 트윗들 사이의 공통점을 찾게 하고, 거기서 새 아이디어를 뽑아낼 수도 있고요.

Q. 그걸 어떤 방식으로 연결하셨어요?

에이전트한테 두 가지를 시켰습니다. 먼저 외부에서 접근할 수 있는 공개 API를 하나 만들자고 했고, 그다음에 워크플로우를 하나 만들자고 했어요. 그러고 나서는 매일 그 API를 확인해서 수치를 돌려 달라고 시켜 놓기만 하면 됩니다. 채널에 매일 올라오는 트윗 통계가 그렇게 들어온 거예요. 대시보드에 있던 자료를 외부용 API를 통해 가져와서 이 채널에 꽂아 주는 구조입니다. 그러면 저는 거기에 답글을 달면서 Fizz한테 "지난 7일 동안 잘 나간 트윗들의 공통점이 뭐야?"라고 물어볼 수 있어요. 그 기간 데이터도 API로 같이 넘어오니까요.

Q. 그러니까 정보를 넣고, 앱을 통해 다시 빼내고, 그게 전부 에이전트의 맥락 안으로 돌아 들어오는 순환 구조군요.

정확합니다. 예전에는 이걸 클로드 코드나 챗GPT 세션 안에서 했어요. 트윗 데이터를 내보내거나 복사해서 브라우저의 챗GPT에 붙여 넣고, 대화를 나눈 다음 결과를 다시 가져오는 식이었죠. 지금은 X API에서 정보를 끌어와서 그대로 여기 에이전트들의 컨텍스트 창 안에 들어와 있습니다. 여기서 바로 그걸 두고 이야기할 수 있고, 동료들과 "다음엔 어떤 트윗을 밀어 볼까", "다른 마케팅 각도는 뭐가 있을까"를 같은 자리에서 논의할 수 있어요.

Q. 에이전트가 일하는 동안에는 뭘 볼 수 있나요?

일하는 과정이 그대로 보입니다. 터미널에서 이런 걸 보는 데 익숙한 분이라면 반가울 거예요. 어떤 도구를 호출하고 있는지, 지금 무슨 일이 일어나고 있는지가 다 나옵니다. 방금 던진 질문에 대해서도 채널에서 정보를 가져오면서 더 최근 통계가 있는지 확인하고, 결과를 받아 오는 과정이 전부 표시됐어요. 평소엔 커튼 뒤에서 벌어지는 일인데 여기서는 그게 드러납니다.

Q. 이런 건 모든 회사에 다 있는 이른바 지루한 업무인데, 여기서 남들보다 유리한 구조를 만들면 그게 좋은 사업과 그렇지 않은 사업을 가른다고 봅니다. 슬랙에서 같은 걸 하려면 어떻게 달라지나요?

슬랙에서 이 정도를 굴리려면 우선 API 토큰을 받고, 그쪽 플랫폼에 앱을 하나 만들어야 합니다. 그리고 슬랙 쪽 방식은 전부 독점적이라서 구조를 따로 익혀야 해요. 물론 에이전트를 쓰면 그것도 예전보다는 쉬워졌습니다.

그런데 Buzz는 개방형 프로토콜 위에 올라가 있어서 이런 연결을 정말 쉽게 붙일 수 있어요. 그리고 그렇게 하고 나면 일을 도와주는 거대한 컨텍스트 엔진이 하나 생기는 셈입니다. 지금 당장 Fizz한테 "X API에 직접 붙어서 Buzz에서 트윗을 올릴 수 있게 만들어 줘"라고 시켜도 크게 어렵지 않을 거예요. 15분이면 될 겁니다.

Q. 에이전트한테 말을 걸 때 요령이 따로 있나요? 방금 보니 짧고 간결하게 물어보시던데요.

요즘 모델들은 질문 뒤에 깔린 의도를 잘 읽어 냅니다. 그러니 평범한 사람한테 말하듯 대화하시면 돼요. 저는 특별한 방식이 없습니다. 방금 던진 질문은 평소보다 정중한 편이고, 원래는 오타도 그냥 두고 "알짜만 내놔" 같은 식으로 던져요. 그래도 대체로 잘 알아듣습니다. 맥락을 전부 갖고 있으니까요. 저는 보통 질문이든 프롬프트든 직설적이고 간결하게 씁니다.

Q. 결과는 뭐라고 나왔나요?

제가 했던 것들을 정리해서 보여 주네요. "잭의 Buzz를 써 봤다", "Open SaaS를 오픈십(OpenShip, 내 서버에 직접 앱을 배포해 주는 오픈소스 플랫폼)에 배포했다, 자체 호스팅에 처음으로 성공했다" 같은 것들이요. 그러니까 제가 초보자 입장에서 이런 걸 해 보고 배운 걸 보고하는 트윗들이 잘 되고 있다는 겁니다. 잘된 쪽으로는 상위 두 개 트윗이 100만 노출을 넘겼고, 안 된 쪽은 하위 절반이 다 합쳐서 8만 8천 정도였어요. 결론은 이렇게 나왔습니다. 신기함은 도달을 만들고, 마찰은 참여를 만든다. 꽤 쓸 만한 조언이죠. 이런 걸 쉽고 선명하게 만들어 준다는 게 Buzz 안에서 다 굴릴 때의 힘입니다.

비트코인 결제와 컴퓨팅 나눠 쓰기

Q. 피드백 중에 "Buzz에는 비트코인 네이티브 결제를 위한 포석이 숨어 있는데 아무도 얘기를 안 한다"는 말이 있더라고요. 무슨 뜻인가요?

아까 개방형 프로토콜 얘기를 하면서 제가 그냥 넘어간 부분이에요. Buzz는 노스터(Nostr, 특정 회사가 소유하지 않는 개방형 메시징 프로토콜) 위에 올라가 있습니다. 잭 도시를 아신다면 그가 비트코인을 강하게 지지한다는 것도 아실 텐데요. 노스터는 비트코인 라이트닝(Lightning, 비트코인을 빠르고 거의 수수료 없이 주고받는 결제망)과 긴밀하게 붙어 있습니다. 그래서 제 추측은, 노스터가 열려 있으니 라이트닝 결제를 Buzz에 붙일 수 있게 되리라는 거예요.

Q. 설정에 컴퓨팅 공유라는 항목이 있던데요. 뭘 하는 기능인가요?

말 그대로 팀끼리 AI 모델을 나눠 쓰는 기능이에요. 켜면 노트북이나 데스크톱에 내려받을 수 있는 로컬 LLM 몇 가지를 자동으로 추천해 주고, 그걸 팀의 다른 구성원들과 나눠 쓸 수 있습니다. 이것도 결국 Buzz의 개방성에서 나오는 건데, 저를 가장 놀라게 한 부분이기도 합니다.

Q. 누구한테 특히 쓸모가 있을까요?

이제 막 시작하는 사람이요. 대학생인데 괜찮은 아이디어가 있다고 해 볼게요. 시간도 부족하고, 도와줄 사람도 없고, 토큰을 무제한으로 쓰게 해 주는 월 몇백 달러짜리 요금제를 살 돈도 없습니다.

그럼 친구 몇 명이 모여서 사양이 괜찮은 노트북이나 맥 스튜디오, 아니면 성능 좋은 맥 미니를 한 대 마련하는 거예요. 거기에 이 기능을 켜고 컴퓨팅을 공유하면, 각자 다른 노트북에서 채팅하면서도 그 한 대에서 돌아가는 모델 하나를 다 같이 쓸 수 있습니다.

아주 단순한 예시지만, 이들이 모델 선택의 진짜 개방성으로 가는 길을 깔고 있다는 게 보여요. 오픈소스 모델과 로컬 모델은 계속 강해지고 있고, 앤트로픽이나 오픈AI의 프런티어 모델과 경쟁하기 시작했으니까요.

Q. 그런데 왜 로컬이 중요한가요? 일하는 방식의 미래라는 큰 그림에서 보면요.

우선 모델 선택 자체가 하려는 일에 따라 중요합니다. 그리고 이건 슬랙이 내 데이터를 쥐고 있다는 것과 같은 이야기예요. 그 데이터는 굉장히 값이 나갑니다.

이런 도구들이 일을 훨씬 쉽게 만들어 주기는 하지만, 그 안에서 오가는 건 여전히 내 아이디어예요. 그걸 계속 다듬고, 열심히 고민해서 밖으로 내놓는 겁니다. 그런데 그 데이터를 회사 한 곳이 통째로 쥐고 있는 거죠.

슬랙이 대표적입니다. 대화가 전부 그쪽에 쌓여 있으니까요. 슬랙이 지겨워져서 다른 데로 옮기고 싶어도 그걸 통째로 들고 나가는 게 정말 어렵거나 아예 불가능할 수 있습니다. 그래서 그냥 거기 남고, 묶여 버려요.

Q. 모델도 마찬가지라고 보시는 거군요.

똑같습니다. 오늘은 무제한 요금제가 월 200달러예요. 내일은 2,000달러일 수도 있습니다. 아무도 모르는 일이에요. 그래서 앞으로 선택지를 갖고 있는 게 사업의 지속 가능성에 중요합니다. 어떤 모델은 아예 물어볼 수 있는 것에 제한이 걸려 있기도 하고, 정부가 위에서 모델로 뭘 할 수 있고 없는지 방침을 내리기도 해요. 실제로 사람들이 며칠 쓰고 있던 모델이 회수되는 일도 봤습니다. 우리는 이런 도구들 위에 사업을 얹고 있잖아요. 그렇다면 그 도구에 대한 유연성과 자유와 통제권을 가져야 합니다.

Q. 결국 우리가 몰랐던 건 슬랙 같은 제품이 이미 우리의 컨텍스트 창고가 돼 있었다는 사실인 것 같아요. 그리고 어떤 모델이든 최대한 뽑아 쓰려면 맥락이 가장 많이 필요하고요. Buzz가 앞서 나온 도구들과 갈리는 지점도 거기인가요?

그렇습니다. 그게 제가 좋다고 보는 지점이에요. 저는 이들이 뭔가를 제대로 짚었다고 생각합니다. 물론 어떻게 될지는 지켜봐야죠. 오픈클로 이야기를 하는 댓글도 봤어요. 이제 아무도 오픈클로 얘기를 안 한다고요. 오픈클로는 진짜 놀라운 순간이었습니다. 에이전트한테 이만큼 생산적인 일을 시킬 수 있구나 싶었죠. 그런데 저는 거기에 뭔가 빠져 있다고 느꼈어요. 공유되는 맥락입니다. 우리는 팀으로 일하고, 다른 사람들과 함께 일하니까요.

Q. 여기서 말하는 팀에는 에이전트도 포함되는 거죠?

팀이라는 게 내 다른 에이전트들을 뜻할 수도 있어요. 어차피 대화는 하게 되어 있습니다. 상대가 이 에이전트냐 저 에이전트냐의 차이일 뿐이죠. 그런데 이제는 그 팀의 범위를 넓힐 수 있게 됐어요. 말하자면 전역 컨텍스트 창을 키워 놓고, 그걸 팀 전원이 볼 수 있게 만드는 겁니다. 에이전트까지 포함해서요. 그래서 저는 이게 정말 괜찮다고 봅니다.

에이전트 세팅, 이 정도면 충분합니다

Q. 에이전트를 만들고 관리하는 쪽에서 알짜 팁이 있을까요?

깊이 파고드는 걸 좋아하시는 정도에 따라 다르겠지만, 솔직한 제 의견은 그렇게 많이 손댈 필요가 없다는 겁니다. 제가 처음 한 건 하나였어요. 에이전트를 모델에 고정해 둔 겁니다. Fizz는 페이블(Fable) 모델로, Honey는 소넷(Sonnet)으로요. 페이블의 성능을 굳이 쓸 필요가 없어서 토큰을 빠르게 태우지 않아도 되는 작업들이 있으니까요. 그게 제 주된 조언입니다.

Q. 하네스는 뭘 쓰고 계세요?

저는 아래에 클로드 코드만 씁니다. 다만 어댑터가 있어서 오픈클로나 오픈코드, 구스 같은 것도 붙일 수 있어요. 어떤 하네스든 내부에 얹을 수 있습니다.

Q. 모델 고정 말고 또 해 두신 게 있나요?

최고 에이전트 책임자(chief agent officer)라는 걸 하나 만들어 뒀어요. 앞으로 더 구체적인 지시와 시스템 프롬프트를 가진 에이전트를 여럿 만들게 되면, 누구에게 일을 맡길지 정하는 일 자체를 이 친구한테 넘기려고요. "이런 일이 있는데 누가 제일 잘하지?"라고 묻는 식으로요. 카피라이터도 있을 수 있고, 브레인스토머도 있을 수 있고, 코드 리뷰어도 있을 수 있잖아요. 그러다 보면 누가 누군지 잊어버리기도 하니까, 에이전트한테 배분을 맡기는 겁니다. 이쪽에서는 이게 제 조언의 전부예요.

Q. 트위터에서 스킬에 대해 묻는 분들이 있던데요.

앞서 잠깐 말씀드렸는데, 클로드 코드 같은 걸 쓰면서 아래에 깔아 두고 쓰던 것들은 전역으로 설치돼 있기만 하면 Buzz 에이전트도 그대로 씁니다. 스킬 같은 것들을 그대로 활용할 수 있어요. 쌓아 둔 걸 잃지 않는다는 점에서 이것도 좋은 부분입니다.

지금 이 소프트웨어의 솔직한 상태

Q. 실제로 써 보면서 아쉬웠던 부분도 있었나요?

이건 베타 소프트웨어예요. 어쩌면 알파일 수도 있습니다. 초기 프리뷰 단계라고 보시면 돼요. 그래서 잘 안 되는 것들이 있습니다.

저는 워크플로우를 만들어서 반복 작업을 걸어 두려고 했는데, 그게 깔끔하게 붙지 않더라고요. 그게 하나였고요. 또 하나는 좀 느릴 수 있다는 겁니다. 클로드 코드나 코덱스에서 직접 작업하는 데 익숙하다면 그쪽이 확실히 빠릅니다. 내 서버, 그러니까 릴레이와 계속 신호를 주고받는 구조라서 그런 것 같아요.

Q. 그럼 지금 시점에 누구한테 맞는 도구인가요?

지금은 아까 말한 대로 솔로프리너, 그리고 작은 소프트웨어나 작은 아이디어를 굴려 보는 소규모 팀에 정말 잘 맞습니다. 복잡한 소프트웨어 엔지니어링을 하고 계신다면 이건 지금 쓰실 도구가 아닐 수도 있어요. 하지만 가치를 만들어 줄 뭔가를 찾고 있고, 흩어진 지식을 한곳으로 모으고 싶다면 정말 좋은 선택입니다.

Q. 1인에서 10명 규모, 매출 0에서 1,000만 달러 사이의 창업자가 지금 슬랙을 쓰고 있다면, Buzz를 받아서 써 볼 만할까요?

저는 꽤 확신하는 편이에요. Wasp 팀을 설득해서 내부에서 이걸 쓰자고 하고 있거든요. 정확히 그 이유 때문에요. 저희는 작은 스타트업이고 개발자 도구를 만드는 소프트웨어 회사입니다. 그리고 이야기할 게 전부 디스코드에 쌓여 있어요. 저희 커뮤니티도 거기 있고요.

Q. 커뮤니티까지 같이 옮길 수 있나요?

이건 언급해 둘 만한데, 채널을 비공개와 공개로 나눠 만들 수 있습니다. 제품을 쓰는 커뮤니티 사람들을 초대해서 함께 이야기하는 공간을 열어 두고, 팀 전용 비공개 채널을 따로 두는 식이에요. 그러면 그 맥락이 공유됩니다. 이게 굉장히 큰데요. 누가 채팅방에 들어와서 "이거 고쳐졌으면 좋겠다"고 하면, 에이전트로 고치는 게 태그 한 번 거리가 되거든요. Fizz한테 "이 버그 잡아 보자"라고 하면 됩니다. 버그를 신고했거나 기능을 요청한 사람이 보는 앞에서 바로 시제품을 만들어 볼 수도 있고요. 그래서 소규모 팀이라면 확실히 확인해 볼 만합니다.

Q. 저는 이게 팀원보다 에이전트 직원이 더 많아지는 세상을 살짝 보여 준다고 봅니다. 아직 겉만 긁고 있는 단계지만, Buzz를 안 쓰게 되더라도 슬랙을 더 잘 쓰는 법은 배우게 되니 만져 보는 쪽에 손해는 없다고 생각하고요. 이 도구가 앞으로 강해질 수 있다면 그 이유는 뭘까요?

좋은 지적이고, 저도 이들이 이미 모퉁이 너머를 보고 있다고 생각합니다. 그리고 이 분야에서 강한 선수가 될 수 있게 해 줄 요인은 오픈소스라는 점이에요. 개방형 프로토콜 위에 올라간 오픈소스 앱입니다. 그러니 이걸 개선할 아이디어가 있는 사람은 누구든 실제로 손을 댈 수 있어요. 집단지성이 이 도구를 쓰면서 동시에 이 도구를 고치고 있는 셈이라, 방향 자체가 그쪽으로 끌려갈 수 있습니다. "이건 나한테 안 맞네", "다른 도구의 이 점이 좋으니 여기에 넣어야지" 하는 식으로요. 그게 이들에게 아주 유리하게 작용해서, 사람들이 기본으로 켜는 도구가 될 수도 있습니다. 물론 변화가 워낙 빠르니 누가 알겠어요.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의  뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]