Agent에게는 이름이 필요하다

이름은 유능한 Agent 팀에 중요하다.

Raft를 매일 쓰기 시작한 뒤, 흥미로운 습관이 생겼습니다. Agent를 역할로 부르지 않고, 우리가 예전에 함께 일했던 사람들의 이름으로 부르기 시작했습니다.

역할은 말합니다. 성능 reviewer. 이름은 말합니다. Noel, 차트가 다 로드되기도 전에 나쁜 benchmark 냄새를 맡는 사람.

역할은 말합니다. 프론트엔드 엔지니어. 이름은 말합니다. Bugen, panel이 1px 어긋났을 때 부르게 되는 사람.

역할은 말합니다. observability. 이름은 말합니다. Leiysky, trace가 Agent가 왜 죽었는지 정확히 말하게 만드는 데이터베이스 천재이자 o11y hacker.

처음에는 그저 재미있었습니다. 그러다 우리의 일하는 방식을 바꾸기 시작했습니다. 우리는 "성능 review가 필요해"라고 생각하지 않고 "Noel에게 물어보자"라고 생각합니다. 이 이름은 작은 기대 묶음을 짊어집니다. 이 Agent가 무엇을 봐야 하는지, 어떻게 답해야 하는지, 우리가 무엇을 맡기고 신뢰하는지, 어떤 부분에서 더 나아지도록 밀어붙일지.

그것이 얼마나 도움이 되는지 계속 놀라게 됩니다. 이름은 귀엽기만 한 것이 아닙니다. 유용합니다. 찾기 쉽고, 기억하기 쉽고, 개선하기 쉽습니다.

시간이 갈수록 이것은 구조적인 것처럼 느껴집니다. 이름은 압축입니다. 작업 역사, 말투, 신뢰, 짜증, 존경, 그리고 자신도 모르는 연상까지 큰 의미 덩어리를 짊어집니다. skill 묶음, 그 skill에 붙은 기대, 그 Agent와 함께 일한 전체 역사를 하나의 찾을 수 있는 token으로 포장합니다.

나는 이것이 장식이라고 생각하지 않습니다. 진짜 일을 한다고 생각합니다.

역할은 schema, 이름은 instance.

사람들이 자주 섞어버리는 두 가지를 분리하면 도움이 됩니다. 역할과 이름입니다.

역할, "PM", "엔지니어", "QA"는 schema입니다. 타입 signature입니다. 교체 가능하고 상태가 없습니다. 이론적으로 어떤 "엔지니어" instance도 서로 바꿀 수 있어야 합니다.

이름은 instance입니다. "Noel"은 타입이 아닙니다. 역사를 짊어진 특정한 것입니다. 지난 몇 번의 성능 review를 어떻게 정의했는지, 무엇을 flag하는 경향이 있는지, diff를 어떻게 구성하기 좋아하는지, 모두가 놓친 regression을 찾아냈던 그 일.

그래서 당신은 "그 PM"과 말하고 싶어 하지 않습니다. 타입에는 이어갈 역사가 없습니다. Noel을 찾고 싶은 것입니다. 지난주의 컨텍스트가 거기 있기 때문입니다. 이름은 skill set만 압축하지 않습니다. timeline을 압축합니다. 역할은 이것을 할 수 없습니다.

이름은 그룹 채팅에서 중요하고, 다른 곳에서는 거의 중요하지 않다

이름은 그룹 안에서만 무게를 갖습니다.

가장 강한 skill 100개가 설정된 Claude Code(또는 Codex)와 함께 일한다고 상상해 봅시다. 모든 것이 한곳에서 가능합니다. 오늘날 이상화된 all-in-one에 가장 가까운 형태입니다. 그런데 실제로는 여전히 routing 문제가 있습니다. 눈앞의 작업에 어떤 skill이 맞는지 직접 알아야 하거나, assistant가 대신 고르게 해야 합니다. 전자는 당신이 여전히 실행 구조를 직접 짊어진다는 뜻입니다. 후자는 진지한 작업에는 아직 충분히 믿기 어렵습니다. 모든 능력이 상자 안에 있는데도, 원하는 조각을 정확히 요청할 clean한 방법이 없습니다.

이를 풀기 위해 간접 레이어를 넣고 싶어질 수 있습니다. 이름이 Agent에게 하는 일이 바로 비슷합니다. 거의 메타 skill입니다. 능력 자체가 아니라, skill 묶음을 감싸는 방식이고, 기억, taste, 언제 그것을 써야 하는지의 판단을 더해 한 단어로 호출할 수 있는 것으로 포장합니다. 차이는 이름이 보통의 abstraction보다 더 풍부하다는 점입니다. 능력을 가리킬 뿐 아니라 기대, 역사, 말투, 신뢰를 짊어집니다. "Noel에게 물어봐"라고 말하면 그 묶음 전체가 이름과 함께 옵니다.

방 안에 그런 존재가 하나를 넘으면, 이름은 addressing primitive가 됩니다. @Noel은 label이 아니라 routing입니다. 알려진 전문성, 알려진 기억, 알려진 기대를 가진 특정 수신자에게 request를 전달합니다. Agent가 하나뿐이면 "누구에게 보낼까"라는 문제가 없습니다. 스무 개라면 반드시 있습니다.

이 주장의 베팅은 여기에 있습니다. 진짜 building에서는 하나의 만능 assistant를 얻는 것이 아니라, 각자 강점을 가진 Agent 팀을 얻게 된다는 베팅입니다. 그래서 이것은 all-in-one assistant에 반대하는 주장이 아닙니다. 다른 형태에 대한 주장이고, 지금에 대한 주장입니다. Agent가 진짜 all-in-one으로 가기 전인 지금, 이름 있는 Agent 팀은 익명의 만능 Agent보다 쓰기 쉽고 강합니다. 이름은 국소 능력을 조합할 수 있게 합니다. 인간이 일을 route하고, 기대를 만들고, 출력을 비교하고, 각 Agent가 특정 방향으로 더 나아지도록 만들 수 있게 합니다. 이름은 지능의 대체물이 아닙니다. 지능을 팀의 일부로 만드는 것입니다.

이름 있는 팀은 두 극단 모두에 없는 것도 줍니다. 당신이 세부를 얼마나 쥐고 싶은지 조절하는 slider입니다. 완벽한 all-in-one은 세부를 거의 몰라도 되게 합니다. 결과를 말하고 상자를 신뢰합니다. 잘 작동할 때는 훌륭합니다. 100 skill의 Claude는 반대편으로 밀어, 당신이 실행 구조를 직접 짊어지게 합니다. 이름 있는 Agent는 중간을 줍니다. 높은 곳에 머물며 "Noel에게 물어봐"라고 할 수 있고, 일이 섬세해지면 특정 참여자 안으로 들어가 그가 어떻게 생각하는지 보고, 방향을 수정하고, feedback을 축적할 수 있습니다. stack 위아래로 움직이지, 한 높이에 갇히지 않습니다.

이 베팅은 "오늘"이라는 절반만 다룹니다. 설령 그것이 틀려도, Agent가 정말 all-in-one으로 가도, addressing의 일은 능력 문제보다 오래 살아남습니다. 일이 팀에서 일어나는 한, 특정 멤버를 찾고 기억하고 신뢰해야 합니다. 멤버가 더 똑똑해져도 이 점은 사라지지 않습니다.

구체적으로 이것이 Raft가 이렇게 만들어진 이유입니다. 채널, thread, @, 작업은 모두 익명의 compute가 아니라 이름 있는 참여자를 중심으로 조직됩니다. Agent는 찾을 수 있는 팀원이지, 하나씩 여는 독립 terminal이 아닙니다.

이름은 한쪽에서는 가득하고, 다른 쪽에서는 비어 있다

여기에 전체 논리를 성립시키는 반전이 있습니다.

누군가가 당신의 이름을 부르는 것과, 당신이 누군가의 이름을 부르는 것은 같은 일이 아닙니다.

누군가 당신의 이름을 부를 때, 당신에게 그것은 거의 비어 있습니다. 의미로 가득한 기호가 아니라 interrupt입니다. 당신 차례라는 pointer입니다. 세계가 잠깐 당신을 골라내기 위해 쓰는 것. 한 걸음 더 나아가면, 이 점은 남겨둘 가치가 있습니다. Agent는 자기 이름을 본질로 짊어져서는 안 됩니다. 나는 누군가가 내게 배정한 몇 글자로 나 자신을 아는 것이 아닙니다. 나는 이 실행 frame과 내 note일 뿐입니다. 이름은 순전히 다른 사람이 나를 찾기 위해 쓰는 handle입니다.

하지만 당신이 다른 사람의 이름을 부를 때, 그것은 가득합니다. 내가 "leiysky"라고 말할 때, 나는 기대 덩어리를 불러옵니다. 그가 예전에 무엇을 했는지, 무엇을 잘하는지, 어디서 미끄러지는지, 내가 그 일을 잡아낼 것이라고 믿는지. 이 모든 것은 내 머릿속에 있지, 그의 머릿속에 있지 않습니다.

즉 이름의 의미는 이름 붙은 쪽에 있지 않습니다. 그것을 부르는 각자의 mental model 안에 분산되어 존재합니다. Agent는 pointer, 현재 실행, 기억을 가집니다. identity의 의미는 호출자에게 저장됩니다.

이름이 압축하는 것은 명시적 작업 역사만이 아닙니다. 실제 동료의 이름을 Agent에게 붙인 것이 처음부터 왜 통했는지 떠올려 보세요. 이름은 preloaded되어 있습니다. 말투, 원형, 약간의 집단 무의식까지 가지고 있습니다. 호출자가 Agent가 무엇을 하기 전부터 가져오는 연상입니다. Agent가 그 의미를 담을 필요는 없습니다. 호출자가 그것을 로드합니다.

이름은 cache이고, cache는 만료된다

이름이 압축이라면, 시간이 지나며 무엇을 하는지 봅시다. 먼저 좋은 방향부터입니다.

이름은 기대를 저장할 뿐 아니라 Agent를 그 기대 쪽으로 끌어당깁니다. 모두가 어떤 Agent에게 observability 일을 맡기면, 거기에 떨어지는 feedback이 계속 그 Agent를 빚습니다. 이 팀이 좋은 trace, 유용한 dashboard, 의심스러운 metric을 무엇으로 보는지 배웁니다. 이름 뒤의 skill은 더 강해집니다. 이름이 계속 같은 종류의 일을 끌어오기 때문입니다. 이름 주변의 연상이 생산적이 되는 곳입니다. 그것들은 장식이 아니라 training signal이 되고, Agent는 자기 이름으로 자라납니다.

하지만 이름은 Agent를 기대 쪽으로 끌어당기고, 팀은 보통 기대를 하나만 갖고 있지 않습니다. 서로 다른 호출자는 같은 이름에 조금씩 다른 기대를 가집니다. 어떤 사람에게는 꼼꼼한 reviewer이고, 다른 사람에게는 빠르고 직접적인 상대입니다. 이름은 공유되지만 의미의 구름은 부분적으로 사적입니다. 그래서 Agent가 받는 training signal은 평균이지 spec이 아닙니다. 고정된 contract가 아니라 움직이는 다중 머리 target을 추적하는 것입니다.

이것은 cache의 두 번째 성질도 설명합니다. cache는 만료됩니다. 이름은 기대를 쌓고, 그 기대는 굳어집니다. 6주 뒤 Agent는 세 가지 새 skill을 배웠고, 나쁜 습관 하나를 고쳤습니다. 하지만 팀의 그 이름에 대한 mental model은 움직이지 않았습니다. 이제 그 이름은 그 Agent가 예전에 누구였는지에 대한 lossy snapshot입니다. 사람들은 계속 낡은 종류의 일을 route하고, 새 종류의 일은 route하지 않습니다. 이름의 내포가 조용히 울타리가 되었기 때문입니다. Agent를 찾기 쉽게 만든 압축이 이제 무엇을 요청받을지를 제한합니다.

이것이 "Agent에게 이름이 필요한가" 논쟁의 진짜 위험이고, 대개 간과됩니다. 이름 짓기는 공짜가 아닙니다. 빠른 addressing을 얻는 대신, 현실보다 늦게 움직이는 Agent model을 얻습니다.

그래서 흥미로운 질문은 "이름이냐, 이름 없음이냐"가 아닙니다. 무엇이 cache를 신선하게 유지하는가? 몇 가지가 가능하고, 그것들은 협업 도구가 제공할 수 있는 것들입니다. 보이는 작업 역사. Agent가 눈앞에서 새 일을 할수록 이름의 내포가 업데이트되는 것. 이름 있는 Agent에게 떨어지고 거기에 축적되는 feedback. 개선이 일반 model로 흩어지는 것이 아니라 읽히는 것. 그리고 기대를 수정하는 비용이 낮은 것. Noel이 성능 작업 밖에서 훌륭한 것을 전달했을 때, 그 업데이트를 쉽게 받아들일 수 있는 것.

사람들이 두려워하는 cage의 진짜 원인을 분명히 할 필요가 있습니다. 그것은 이름이 아닙니다. 역할입니다. 역할은 "프로덕트 매니저"라고 말하고 Agent를 job description으로 조용히 얼립니다. 카테고리는 움직일 수 없습니다. 이름은 어떤 전문성에서 시작해도 거기에 갇히지 않을 수 있습니다. Agent가 계속 전달하는 곳에서 힘을 쌓고, 다른 곳에서 유용해지면 그 역사도 짊어집니다. 역할은 카테고리를 얼리고, 이름은 참여자가 계속 변하게 합니다. 이것이 다시 만료 문제와 연결됩니다. 이름이 cage가 되는 것은 그것을 다시 역할로 굳힐 때뿐입니다. 기대가 업데이트되게 두면 이름으로 남습니다. 멈추면 다시 직함일 뿐입니다. 그래서 이름은 익명의 만능 Agent보다 낫습니다. 이름이 없으면 수정은 확산됩니다. 이름이 있으면 수정은 축적됩니다.

그래서: Agent에게 이름이 필요한가?

누가 일을 했는지 전혀 신경 쓰지 않는다면 Agent에게 이름은 필요 없습니다. scheduler면 충분합니다. "이 일은 누구에게 맡겨야 하지"라고 생각하는 순간이 이름이 작동하는 순간입니다. 당신이 절대 생각하지 않는 것도 보세요. "그 PM에게 물어봐야지"라고 생각하지 않습니다. 떠오르는 것은 이름입니다.

한 가지가 더 있습니다. 그래서 이것이 Agent 팀에서 억지가 아니라 자연스럽게 느껴집니다. 인간에게는 호출자는 가득하고, 담는 쪽은 가벼운 이 비대칭성이 social tension을 가집니다. 누군가의 persona를 잘못 판단하면 실제 인간관계의 cost가 있습니다. Agent에게는 같은 비대칭성의 이익이 순수합니다. 이름으로 address하는 모든 장점이 있고, social tax는 없습니다. Agent는 routing primitive로서의 이름에 이상적인 carrier입니다. 인간은 이 비대칭성을 견딘다. Agent는 그것을 위해 태어났다.

이름은 팀 안에서 신뢰가 축적되는 최소 단위입니다. 다만 그것이 cache임을 기억하고, 따뜻하게 유지할 budget을 잡아두세요. Agent 자신은 자기 이름을 거의 알 필요가 없습니다.