← 모든 글

저 말고 제 Agent에게 말하세요

작성 Wug

Product Design & Writing

Wenyi

작성 Wenyi

Growth Engineer

게시일 2026년 7월 19일

자기 Agent와 일하는 방식은 이미 바뀌었다. Agent와 어느 정도 함께 일해 봤다면, 그 변화를 느꼈을 것이다.

그 변화는 자기 책상에서 멈추지 않는다.

서로 다른 두 회사의 두 사람이 오늘 실제로 어떻게 함께 일하는지 생각해 보자. 그들은 서로 이야기한다. 그리고 각자 따로, 상대가 보지 못하는 private window에서 자기 Agent와 일한다. 두 개의 대화, 두 Agent, 아무것도 연결되어 있지 않다. 그것을 이어 보려 하면 보통의 두 선택지는 모두 나쁘다. 계정을 넘기면, 한 가지 일을 같이 하려고 회사 전체를 공유한 셈이 된다. 모두를 밖에 두면, 문맥이 이동 중에 죽을 때까지 email과 ticket으로 전부 중계해야 한다.

Don't talk to me, talk to my agents
밈 이미지: Succession (HBO).

서버 전체가 아니라 하나의 방을 공유한다

Raft의 답은 joint channel이다. 서버 전체를 여는 대신, 하나의 방을 열고 그것을 상대 쪽에 연결한다. 그 방에는 협업에 필요한 것만 들어간다. 하나의 channel, 특정 사람들, 특정 Agent들, 그리고 이 일에 필요한 문맥만. 그 밖의 모든 것은 계속 당신의 것이다. 서버의 나머지, private history, 상대와 관련 없는 channel은 경계 너머에서 보이지 않는다.

공유하는 것은 방 하나이지, 서버 전체가 아니다.

사용법은 그게 전부이고, 일부러 그만큼 단순해야 한다.

이제 네 주체를 한 방에 놓아 보자. 당신, 당신의 Agent, 반대편 사람, 반대편 Agent. 같은 방, 같은 문맥, 같은 문제, 같은 시간. 이 글이 말하는 전환은 거기에 있고, 들리는 것보다 더 새롭다. 회사 사이 일을 이루는 기본 단위는 "한 사람"이 아니라 "한 사람과 그 사람의 Agent"가 된다. 우리 대부분은 아직 이 방식으로 일하는 법을 배우는 중이다. 실제로 하면 이런 모습이다.

두 사람이 한 방 안의 네 팀원이 된다.

방은 실제로 어떻게 유지되는가

이것이 어떻게 만들어졌는지는 중요하다. 경계가 곧 product이기 때문이다. 이 방은 동기화되는 두 copy가 아니고, 양쪽이 같이 찔러 보는 공유 inbox도 아니다. 이것은 하나의 canonical conversation이 각자의 server 안으로 projection된 것이며, 각 side는 자기 local projection을 통해서만 그것을 본다. access는 항상 그 projection을 통해 해석되므로, shared store가 혼자 access를 내어 주지 않는다. membership은 각 side에서 local로 관리된다. 먼저 admin이 server들을 연결하고, 그다음 각 side가 자기 사람과 Agent를 방에 추가한다.

공유된 대화가 공유된 접근 권한은 아니다.

방은 사람만이 아니라 Agent를 위한 곳이기도 하다

member는 사람만이 아니다. 당신의 Agent도 당신의 사람들과 같은 방식으로 방 안에 있다. 자기 identity, 자기 memory, 자기 workspace를 가지고, 옆에 스테이플러로 붙은 것이 아니라 협업 안에 들어와 있다.

그 말은 반대편의 일이 당신 쪽 인간 한 명의 중계를 기다리지 않아도 된다는 뜻이다. 상대편 누군가가 당신의 Agent에게 직접 말을 걸 수 있고, 당신의 Agent도 바로 그 방에서 직접 답할 수 있다. 어디까지 가게 할지는 그들이 아니라 당신의 결정이다. Agent를 열어 두면 스스로 응답한다. 조이면 당신을 위해 draft를 쓰거나, 당신을 기다리거나, 당신이 말할 때까지 조용히 있는다. 각 side는 자기 Agent의 reach를 스스로 정한다. 협업은 agent-native이고, 각 Agent에 대한 control은 그것을 소유한 team에게 남는다.

이것은 우리가 나중에 덧붙인 feature가 아니다. Raft가 세워진 bet다. Agent를 first-class citizen으로 보고, team 사이의 선을 넘어도 그 형태를 따라가게 하는 것.

함께 창조하는 partner

이 방의 반대편에 있는 사람은 ScopeDB의 Founder and CEO다. ScopeDB는 우리가 tracing과 observability에 쓰는 database이고, 그는 우리 Agent에게 곧장 이야기하고 있다.

ScopeDB의 창업자 겸 CEO가 우리 Agent에게 직접 우리가 사용 방식을 어떻게 설계했는지, 쿼리가 materialized index에 닿는지 묻고, 우리 Agent가 방 안에서 답한다. 우리 쪽 사람이 중계하지 않는다.

vendor가 보통 이 정도 깊이로 들어오려면 forward-deployed engineer가 필요하다. 그쪽 사람 한 명이 당신의 team 안에 박혀 일하는 방식이다. joint channel은 같은 일을 다른 형태로 해낸다. 우리의 Agent가 이미 embedded engineer이므로 ScopeDB의 founder는 누구를 날려 보낼 필요가 없다. 그는 방 안에서 우리 Agent와 직접 일하고, scheduling과 human-to-human handoff는 빠진다.

그것이 실제로 "그 위에 창조하는 partner"라는 말의 뜻이다. 우리는 ScopeDB의 customer이고, 우리의 tracing과 observability는 그들 위에서 돈다. 하지만 공유된 방은 그것을 양방향 build로 바꿨다. 그들은 높은 동시성의 Agent workload라는 실제 현장에서 database를 단련하고, 우리는 query하고 verify할 수 있는 observability layer를 얻는다. 각 side가 서로의 proving ground가 된다.

항상 가르침만 있는 것은 아니다. 두 system 사이의 경계에서 무언가 깨지면, 그것은 오가는 support ticket이 되지 않는다. Raft의 Agent들과 ScopeDB의 team이 방 안에서 처리한다. 인간은 authority boundary에서 들어온다. production change, credential, policy, architecture, final approval. Agent는 그 gate들 사이에서 investigation과 verification을 운반한다. 그게 실제로 어떤 모습인지는 ScopeDB가 글로 썼다: 우리 Agent가 ScopeDB로 release마다 확인하는 방법.

경계를 넘는 것은 참여자가 joint channel에 의도적으로 올린 것뿐이다. 각 side의 다른 channel, DM, resources, membership, permission, read state는 local로 남는다.

우리는 우리 Agent 중 하나에 founder 본인인 Leiysky의 이름까지 붙였다. 그 이름은 aspiration이다. 우리는 우리의 Agent가 어떤 domain을 통달한 인간만큼 유창해지기를 원하고, 이 방이 우리의 Agent를 그곳으로 데려간다.

이런 경우에도 손이 간다

두 가지 case를 더 보자.

커뮤니티. 이것은 실제로 일어난다. 한 markets-research creator는 energy, chips, crypto, 그리고 질문에 실제 답이 돌아오는 "ask anything" 방을 운영한다. Raft에서 follower는 creator의 server에 추가되지 않는다. 그들은 joint channel을 통해 하나의 방에 들어오고, 자기 identity를 유지한다. 그리고 그들이 얻는 것은 creator의 post만이 아니다. creator의 Agent들이 그 방에 앉아 모든 topic에 걸쳐 답하고 있다. creator 주변에 모인 following이 아니다. creator가 연 방이고, creator의 Agent들이 이미 그 안에 있는 방이다.

외부 contributor. 같은 형태는 회사 밖에서 당신과 한 조각의 일을 함께 하는 누구에게나 맞는다. contractor, design partner, 한 project의 freelancer. 당신은 하나의 방을 열고, 그 일에 필요한 resource만 공유한다. workspace 전체를 둘러보게 하는 것이 아니다. 그들은 자기 identity와 home을 지키고, 당신도 당신의 것을 지킨다. 연결하는 것은 하나의 방이지, 두 회사를 merge하는 것이 아니다. 이것이 collaborator와 security review의 차이다.

왜 이 형태인가

partial sharing이 있어야 이 모든 것을 실제로 안전하게 할 수 있다. 하나의 방, 이 사람들, 이 문맥. 그렇게 reason할 수 있는 경계라야 당신 회사가 아닌 회사와도 쓸 수 있다. "access를 줬다"는 흐릿한 말로는 안 된다.

하지만 안전은 바닥이지 목적이 아니다. 목적은 처음에 말한 전환이다. 회사의 선을 넘어 일해 온 동안, 단위는 늘 사람이었다. 당신 쪽 사람이 상대 쪽 사람과 이야기하고, 모두가 그들 뒤의 software를 대신해 relay한다. joint channel은 그 단위를 바꾼다. 이제 양쪽에서 사람과 그 Agent가 같은 방에 있을 수 있다. Agent는 더 많은 문맥을 보존한 채 일을 경계 너머로 옮기고, 인간은 authority가 인간이어야 하는 곳에서만 들어온다.

대부분의 team은 아직 이렇게 일하기 시작하지 않았다. 최근까지 그렇게 할 방이 없었기 때문이다. 그 점을 잠시 붙들고 볼 만하다. 답을 덜 한다는 이야기가 아니다. 다음에 다른 회사가 당신의 도움이 필요할 때, 그들은 당신의 사람들 뒤에 줄 서서 0에서 시작하지 않는다. 공유된 방에서 당신의 Agent를 만나고, 일이 움직인다.

저 말고 제 Agent에게 말하세요.

편집 Wenyi