얼굴에 주먹을 맞을 준비가 된 팀이어야 한다 - Claude 플랫폼 200명이 말하는 에이전트의 시대

얼굴에 주먹을 맞을 준비가 된 팀이어야 한다

TL;DR

• 지난 1년의 변화가 한 문장으로 규정되는데 가장 두드러진 변화는 모델이 더 오래 일하는 데 정말 능숙해졌고 더 똑똑해졌으며 더 많은 일을 할 수 있게 됐다는 것이다. 1년 전에는 모델을 한 방향으로 몰기 위해 온갖 것을 그 주변에 지어야 했는데 지금은 그냥 가서 하라고 하면 그냥 한다. 대신 에이전트가 자기 오류에서 회복하고 오래 실행되게 하는 다른 종류의 문제가 남았다.
• 실무자가 부딪히는 벽이 정확히 지목되는데 사람들이 부딪히는 벽은 그 에이전트들을 둘러싼 인프라이고 차별화되지 않는 부분이지만 그래도 제대로 해내야 한다는 것이다. 구조적 해법도 구체적이다. 하네스 곧 에이전트의 뇌는 내구성 있는 서버에서 돌리고 실행이 필요할 때만 샌드박스를 띄워 일하고 끝나면 허물어서, 샌드박스가 죽어도 에이전트 전체가 죽지 않게 한다.
• 비용에 대한 답이 통념을 뒤집는데 직관에 반하게 더 크고 비싼 모델을 쓰는 것이 실제로 답일 수 있고, 모든 토큰이 정확하다면 아무것도 낭비하지 않고 그 문제를 완벽하게 푼 것이기 때문이다. 실측도 붙는다. 오퍼스가 조언하며 소네트가 실행하면 거의 오퍼스급 성능이 나오는데 소네트만 쓰는 것보다 실제로 더 싸고, 오퍼스가 일을 더 잘하도록 가르쳐서 토큰을 덜 썼기 때문이다.
• 가장 흔한 실패는 사람 절차를 그대로 옮기는 것인데 덕트테이프로 붙여 놓았지만 작동하는 사람 절차를 가져다가 사람의 비효율이 보이는 자리에 에이전트를 그냥 끼워 넣는 것이 근본적 오류라는 것이다. 대안은 재설계다. 야심찬 프로젝트를 골라도 신입이 할 만한 가장 기본 단위로 공격적으로 쪼갠 뒤 그 절차를 에이전트 우선으로 다시 발명해야 한다.
• 조직 이야기가 가장 인상적인데 플랫폼과 제품 인프라를 통틀어 200명이고 1년 전에 이 인원으로 이걸 한다고 했다면 절대 불가능하다고 답했을 것이라고 한다. 그런데 새 병목이 생겨서 프로젝트를 띄우면 엔지니어들이 이틀 뒤에 끝냈다고 하는데 모두를 같은 페이지에 올려놓는 일을 할 시간이 없었고, 그래서 우리는 얼굴에 주먹을 맞을 준비가 정말로 된 팀이어야 한다는 표어를 쓴다.

Source

[한영자막] Anthropic의 Claude Platform 팀이 말하는 에이전트의 시대 — Angela Jiang × Caitlyn Les(Anthropic Claude Platform) × Kleiner Perkins Builders 시즌2, Tech Bridge, 43분 59초

_{Source: [한영자막] Anthropic의 Claude Platform 팀이 말하는 에이전트의 시대 — Tech Bridge, 43분 59초}

Knowledge

문제가 모델 밖으로 이동했다

대담은 지난 1년의 변화를 묻는 질문에서 시작한다. 답이 모델 능력에서 출발한다. 가장 두드러진 변화는 모델이 더 오래 일하는 데 정말 능숙해졌고 더 똑똑해졌으며 더 많은 일을 할 수 있게 됐다는 것이다. 1년 전에는 하는 모든 일에 사람이 루프 안에 있는 상태였고 챗봇과 대화하며 일을 끝내는 방식이었는데, 지난 1년 동안 모델이 오래 일하고 배경에서 일을 끝낼 수 있는 쪽으로 점점 더 들어왔다.

그래서 모델 주변의 것들이 중요해진 이유가 설명된다. 그것을 해내려면 그 능력을 활용할 올바른 인프라가 있어야 하고 모델에서 최선을 짜내거나 비용을 최적화하는 데 얽힌 엔지니어링 문제가 많다는 것이다. 모델이 더 오래 일하는 데 좋아졌다는 사실 자체가 그 주변의 문제들을 두드러지게 만들었다는 진단이다.

같은 변화를 다른 각도에서 표현한 대목이 더 선명하다. 1년 전 세계에서는 모델을 아주 아주 특정한 한 방향으로 몰기 위해 온갖 것을 그 주변에 지어야 했다는 것이다. 그런데 지금은 그냥 가서 그것을 하라고 말하면 그냥 한다. 대신 다른 종류의 문제가 남는다. 에이전트가 기본적으로 자기 오류에서 회복하게 하고 안전하고 규정에 맞는 방식으로 일하게 하는 인프라가 많이 필요하다는 것이다. 정리가 대비로 온다. 모델에게 한 방향으로 가라고 말하는 데 모든 노력을 쓰는 대신, 모델이 이미 하고 있으니 더 오래 실행하고 실행하며 오류에서 회복하도록 가능하게 해 주는 것이다.

DCF 하나가 보여 주는 차이

장기 실행 에이전트가 무엇을 새로 가능하게 하는지 금융 예시로 설명된다. 과거에는 아주 구체적인 과제를 줬다는 것이다. 이 엑셀 스프레드시트가 있고 여기와 여기를 계산해야 한다는 식으로 아주 이산적이고 작았다. 그리고 모델을 그것에 겨누고 원하는 셀만 정확히 편집하도록 주변에 발판을 세우는 방향이었다.

지금은 층이 달라진다. 내가 실제로 하고 싶었던 전체는 그 회사의 현금흐름 할인 모형을 만들고 적정 가격에 투자해야 할지 결정하는 것이었다고 말하는 층이라는 것이다. 그러면 장기 실행 에이전트가 모든 작업을 한다. 스프레드시트를 실제로 열고 계산하고 그다음 검증해서 이건 확실히 잘못 계산했으니 다시 해 보겠다고 말한다. 그런데 사람이 끼어들 필요가 없었다는 점이 핵심이다. 들어가서 다시 확인했는지 챙기라고 말할 필요가 없었다는 것이다.

적용 범위도 넓게 잡는다. 금융과 의료, 어떤 종류의 지식 노동이든 동료 어소시에이트에게 하듯 결과만 주는 방식이면, 작업이 에이전트에게 직접 넘어가고 사람들이 그 혁신을 통해 더 생산적이 되기 시작한다는 것이다. 그리고 성격을 한마디로 규정한다. 거의 전방위에서 일어나고 있는데 어떤 의미에서는 조금 눈에 보이지 않는다는 것이다.

스트라이프에서 갈라졌다가 다시 만난 두 사람

두 사람의 이력이 흥미롭게 얽힌다. 둘 다 스트라이프에서 스트라이프 커넥트를 함께 일했고 같은 시기에 팀의 불행 속에 함께 떠났는데, 완전히 다른 연구소로 갔다. 팀은 너희가 조율한 것 아니냐고 했지만 서로 이야기하지 않았다고 한다. 한 사람은 앤스로픽으로, 다른 한 사람은 오픈AI로 갔다.

문제 공간의 유사성이 지목된다. 개발자 플랫폼을 다루는 고객들과 일하고 그들이 자기 제품 안에 가치를 심으려 하며 원시 구성 블록 해법을 원하는 쪽과 더 완성된 해법을 원하는 쪽 사이 스펙트럼에 걸쳐 함께 일한다는 점이다. 그래서 같은 사고방식을 그대로 가져왔다고 말한다. 개발자 플랫폼을 만들어 사람들이 이 기반 기술로 자기 제품과 시스템을 강화하게 하는 것이다.

전직을 결심하게 한 순간이 구체적이다. 스트라이프에서 V2 계정 API를 만들었는데, 그 회사는 처음부터 API를 버전 관리해 왔고 추상을 만들면 수십 년을 갈 것이어야 한다는 개념이 있었다. 그래서 버전 올림을 받을 자격을 갖추려면 앞으로 수십 년 치를 담아야 했고 팀이 그것을 공들여 만들었다. 그런데 사용자 조사 인터뷰에서 고객이 준 문서를 그냥 커서에 넣고 통합해 달라고 했다. 결과가 70퍼센트 정확하게 돌아왔다. 반응이 그대로 남는다. 세상에, 방금 무슨 짓을 한 거냐는 것이었고 미래가 여기 있다는 것을 깨달았다는 것이다.

이후 두 사람이 서로를 자기 연구소로 데려오려고 밀고 당겼다. 한쪽은 엣지 파트너가 필요하다 하고 다른 쪽은 제품 파트너가 필요하다 했고 결국 앤스로픽 쪽이 이겼다. 남기는 말이 조직 문화에 대한 것이다. 지금 일어나고 있는 것이 정말로 기술의 혁명이고 혁명이라면 올바른 편에 있다고 느끼고 싶다는 것이다. 그리고 이 기술이 그토록 강력해질 것이라면 세상에서 정말 좋은 결과를 만들어 내기를 바란다는 데 전부를 걸고 있다고 말한다. 그 사려 깊음이 상상할 수 있는 가장 어려운 문제들과 함께 온다는 점도 인정한다. 안전과 상업적 사업, 지능, 그리고 이 모든 것의 교차점에서 매일 결정을 내린다는 것이다.

차별화되지 않지만 제대로 해내야 한다

관리 에이전트의 철학이 분업 원칙으로 제시된다. 플랫폼 위에서 만드는 사람으로서 당신을 차별화하는 것을 해야 하고 차별화되지 않는 것은 하지 않아도 되어야 한다는 것이다. 그래서 차별화되지 않는 것으로 분류되는 것이 인프라다. 정말 어려운 문제이고 분산 시스템 문제이며 고객이 정말 훌륭한 에이전틱 경험을 갖게 하려면 큰 규모가 필요하다는 것이다. DCF를 대신 해 주는 장기 실행 에이전트 예시로 돌아가면, 그것이 그냥 작동하게 만드는 데 상당한 작업이 들고 요즘은 순수한 하네스 최적화 문제라기보다 대체로 인프라 문제라는 진단이다.

하나의 참된 하네스가 모든 것을 한다는 철학에 대한 판정도 나온다. 경험적으로 그것이 사실이라고 보지 않는다는 것이다. 대신 해야 할 최적화에 서로 다른 층이 있다고 보고 그 층들을 통제할 권한을 어떻게 더 줄지를 고민한다. 그래서 혁신해야 할 위치가 지정된다. 고객을 정말 잘 이해하고 문제 공간을 아는 층에서, 그 통찰을 가져와 최고 수준에서 조각들을 조정해 최고 성능과 최고 고객 경험을 얻는 것이다. 차별화되지 않는 층에서 모든 작업을 하는 것은 어렵고 도전적이지만 바라는 사업 성과로 이어지지 않을 것이라는 경고가 붙는다.

실무자가 부딪히는 벽이 정확히 규정된다. 모델이 더 오래 일하는 데 좋아지니 사람들이 장기 실행 과제를 하겠다고 했는데, 많은 사람이 부딪히는 벽이 그 에이전트들을 둘러싼 인프라라는 것이다. 그리고 조건이 붙는다. 차별화되지 않는 부분이지만 그래도 제대로 해내야 한다는 것이다.

뇌는 남기고 손발만 허문다

샌드박스의 한계가 기술적으로 설명된다. 사람들이 에이전트가 무언가를 이룰 수 있어야 하지만 통제를 벗어나면 안 된다고 생각하니, 가드레일이 필요하고 샌드박스에 넣는다는 것이다. 사람들이 샌드박스라고 부르지만 그냥 컨테이너이고 거기서 놀면 아무것도 망치지 않는다는 발상이다.

문제는 샌드박스를 구동하는 기술의 성질에 있다. 샌드박스는 대체로 일시적이도록 만들어졌고 장기 실행 인프라가 되도록 만들어진 것이 아니라는 것이다. 그래서 많은 시간과 에너지를 쓴 방향이 재구조화였다. 에이전트를 더 모듈화되고 쪼개진 아키텍처로 다시 생각해서, 하네스 또는 에이전트의 뇌는 내구성 있는 서버에서 돌리고 무서운 부분인 실행이 필요할 때 샌드박스를 띄워 그 안에서 하고 끝나면 허무는 것이다.

효과가 명확하다. 그 세계에서는 샌드박스가 죽거나 연결이 끊겨도 에이전트 전체가 죽지 않는다는 것이다. 그리고 이 결론의 출처를 밝힌다. 내부와 제품 안에서 에이전트를 많이 만들면서 형성한 의견이고 그 개념을 플랫폼에 넣어 사람들이 아키텍처와 인프라 관점에서 같은 문제를 반복해 풀지 않고도 모델의 장기 실행 능력을 활용할 수 있게 하려는 것이다.

임원이 어디서 시작해야 하는가

포춘 500 기업 임원이 무엇부터 해야 하느냐는 질문에 답이 단순하다. 관리 에이전트를 쓰라는 것이고 실제로 이 제품을 설계한 이유 중 하나가 그것이라고 한다. 고차 추상 집합이고 더 낮은 층에도 접근할 수 있다는 구조가 제시된다. 그래서 생애 주기가 그려진다. 막 시작한다면 직원들이 원하는 장기 실행 절차를 위해 뭔가 작동하는 것을 만들게 하려고 온갖 복잡한 세부를 걱정할 필요가 없어야 한다는 것이다. 시간이 지나 프롬프트 캐싱을 어떻게 하고 싶은지 아주 구체적인 의견이 생기면 더 낮은 층의 원시 요소로 내려가면 된다.

근거가 심리적이다. 많은 리더가 반대편의 투자 대비 수익을 보거나 상상할 수 있는데, 시작하는 것이 정말 어렵다는 것이다. 그래서 마찰을 줄여 무언가에 결과를 주면 실제로 그것을 만들어 낸다는 것을 쉽게 보게 하는 것이 가능성을 열어 준다.

내부 관행이 이 주장을 뒷받침한다. 누군가 에이전트를 띄워 일을 하겠다고 하면, 프롬프트 캐싱이나 컨텍스트 관리의 세계 최고 전문가라도 관리 에이전트 위에 만든다는 것이다. 이유가 명확하다. 매번 그것을 다시 해킹하는 것이 시간의 가장 높은 레버리지 사용이 아니라는 것이다. 그러면서 노출된 통제 지점이 열거된다. 시스템 프롬프트를 조율할 수 있고 스킬을 설정할 수 있고 외부 맥락에 MCP 연결을 둘 수 있다. 그래서 낮은 층의 하네스 엔지니어링 없이도 관심 있는 것에 정말 능하게 만들 통제력이 충분하다.

신뢰 문제도 두 층으로 정리된다. 첫째는 아키텍처에 구워진 것으로, 에이전트가 일할 때 보안 경계 안에서 하도록 보장하는 것이다. 자기 샌드박스를 가져오는 선택지 같은 것들이 제공되는데, 에이전트가 프로덕션 시스템을 건드리고 민감한 내부 데이터로 일한다면 그것이 어떻게 일어나는지 정확히 통제해야 한다는 이유다. 둘째는 에이전트의 관측 가능성이다. 이것은 좋은 종류의 문제라는 규정이 붙는다. 에이전트가 일을 할 수 있기를 바라고 그렇게 되면 다음 단계의 문제로 들어가는데, 제대로 했는지와 감사 가능한지, 바라는 방식으로 실행되는지를 확인하는 문제라는 것이다.

모든 토큰이 같지 않다

비용 절감을 위해 오픈소스 모델을 쓰고 싶다는 질문에 대한 답이 이 대담의 백미다. 사람들이 비용 절감 기제로 모델을 집어 든다는 것을 인정하면서도 질문을 바꾼다. 실제로 무엇을 하려고 했는지 묻는다는 것이다. 그러면 답은 보통 이 제품을 더 빨리 출하하려 했다거나 팀을 더 효율적으로 만들려 했다는 것이고 그 끝에 실제 사업 성과가 있다.

그래서 방향이 달라진다. 다양한 모델을 항상 집어 드는 것이 최선의 해법이라고 보지 않고 원하는 결과를 더 잘 이해한 다음 그 결과로부터 절대적으로 가장 효율적인 경로를 택하는 일을 더 잘해야 한다고 본다는 것이다. 그리고 결론이 통념을 뒤집는다. 때로 그것은 직관에 반하게 더 크고 더 비싼 모델을 쓰는 것일 수 있다는 것이다. 조건이 붙는다. 그 모델의 모든 토큰이 정확하기만 하다면 아무것도 낭비하지 않고 그 문제를 완벽하게 푼 것이므로, 순수하게 토큰 관점에서 보이는 것보다 훨씬 싸게 끝난다.

토큰이 균질하다는 통념도 반박된다. 토큰에 줄 수 있는 서로 다른 직무를 놓고 팀이 많은 실험을 하고 있다는 것이다. 그리고 잘 작동한 전략 셋이 제시된다.

첫째는 조언이다. 더 작은 모델이 실행하다가 문제의 더 어려운 부분에서 더 큰 모델에 도움이나 조언을 청하는 것이다. 실측이 붙는다. 오퍼스가 조언하며 소네트가 실행하면 거의 오퍼스급 성능이 나오는 평가 결과가 있고 실제로 소네트만 쓰는 것보다 더 싸다는 것이다. 이유가 명확하다. 오퍼스가 일을 더 잘하도록 가르쳐서 일을 끝내는 데 토큰을 덜 썼기 때문이다.

둘째는 채점이다. 관리 에이전트 안에 결과라는 개념이 있어서 좋은 것이 어떤 모습인지 채점 기준을 주면 두 번째 에이전트를 채점자로 배치한다는 것이다. 첫 에이전트가 시도하면 채점자가 아직 충분하지 않으니 다시 하라고 하고 그렇게 채점자와 실행자가 함께 일해 결국 더 나은 결과에 도달한다.

셋째는 꿈꾸기다. 지난 세션들을 돌아보며 기억에 쓰고 개선을 위해 스킬을 쓰는 것이다. 그래서 결론이 지표로 정리된다. 토큰에 실행 말고 다른 직무를 주면 무작정 실행하는 것보다 달러당 지능이 더 나은 구성에 도달할 수 있다는 강한 증거가 있다는 것이다. 다만 지향점은 자동화다. 시간이 지나면 사용자가 자기들만큼 열심히 그 전략을 고안하게 하고 싶지 않고 그런 것을 기본으로 더 많이 자동으로 해 주고 싶다는 것이다.

하네스는 루프다

하네스가 무엇이냐는 질문에 농담 섞인 정의가 나온다. 하네스는 루프라는 것이다. 가장 기본적인 형태는 사용자에게서 입력을 받고 모델에게 어떻게 생각하는지 묻고 도구를 호출하는 것을 왔다 갔다 하는 while 루프이고 그것을 계속 돌리는 것이다. 모델을 붙들고 대화의 모든 부분을 관리하는 것이라는 규정이 붙는다.

그런데 에이전트가 더 많은 일이나 더 오래 걸리는 일을 하려 하면 부품이 늘어난다. 도구를 실행하고 그 작업을 할 안전한 환경이 필요하고 대화를 멈추고 나중에 이어 가려면 대화 상태를 어딘가 저장해야 한다. 그리고 자격 증명 처리가 정교하다. MCP 같은 것으로 외부 시스템에 손을 뻗으려면 안전한 자격 증명을 주입해야 하는데, 에이전트가 그 자격 증명 자체를 보지는 않기를 원하므로 특정 시점에 주입하는 별도의 시스템 부분이 된다는 것이다.

용어 남용도 자인한다. 하네스라는 단어를 지금은 사실상 애플리케이션까지 뜻하도록 과용해 왔다는 것이다. 그래서 층을 구분한다. 핵심 조각들을 제대로 하면 토큰에 직무를 주고 그것들을 진정으로 대체 가능하지 않은 것으로 취급하기 시작하는 자리로 갈 수 있다는 것이다. 그 다음 층에 어떤 사람들은 메타 하네스라는 단어를, 이 팀은 전략이라는 단어를 쓴다.

전략 층에서 일어나는 일이 구체적이다. 핵심 실행이 끝나면 에이전트를 조금 다르게 조율하고 서로 관여하게 하고 서로의 루프에 되먹임하게 하고 조금씩 다른 직무를 주는 것이다. 그리고 판정이 온다. 요즘 그 영역에서 더 많은 알파가 만들어지고 있다는 것이다. 이유는 가장 기본적인 것들이 이제 어느 정도 이해 가능해졌기 때문이다. 오류를 처리하고 루프가 일어나게 하고 장기 실행이 되게 하는 부분이다. 대신 문제 공간과 도메인에 따라 그 전략들을 어떻게 조합하는지가 상당히 다른 성능 결과를 낳는 것을 실제로 봤다고 한다.

사람 절차를 그대로 옮기는 실패

에이전트에 대한 가장 흔한 오해와 실수를 묻는 질문에 답이 규모 판단에서 시작한다. 사람들이 첫 문제로 씹을 수 있는 것보다 크게 물려는 경향이 있다는 것이다. 예컨대 거대한 은행의 고객 확인 절차 전체를 자동화하겠다는 식이다. 그것을 원하는 직관은 많은 사람이 이해할 수 있는데, 절대적 핵심 조각들로 쪼개지 않았기 때문에 현실로 만들기가 정말 어려워진다는 것이다.

근본적 오류가 명확하게 지목된다. 덕트테이프로 붙여 놓았지만 작동하고 온갖 정책이 딸린 아주 사람다운 절차를 가져다가, 사람의 비효율이 보이는 자리에 정확히 에이전트를 끼워 넣으려는 것이다. 그러면 현실에서 작동하지 않고 사람이 하려던 것에 에이전트를 정확히 맞추려 애쓰게 된다.

훨씬 나은 성공 방식이 제시된다. 여전히 정말 야심찬 프로젝트를 골라도 되지만 신입이 할 만한 가장 기본적인 것으로 상당히 공격적으로 쪼갠 다음 그 절차를 에이전트 우선으로 다시 발명하는 것이다. 그리고 결과가 놀랍기도 하다는 점을 짚는다. 때로는 에이전트가 무언가를 하고 나서 더 유익한 방향으로 돌아오는 것을 원하지 않는 편이 낫다는 것이다. 자율적으로 스스로 고치고 필요할 때만 사람에게 올리게 하는 편이 나았다는 관찰이다.

그런데 사람의 선호는 반대라는 대비가 인상적이다. 주제 전문가에게 물으면 그렇게 하고 싶지 않다고 할 가능성이 높고 그것이 일을 하고 나서 내게 피드백을 청하며 계속 왔다 갔다 하는 편을 선호한다고 말한다는 것이다. 그런데 그것이 잘 작동하지 않는다. 이유는 에이전트가 워크플로 자체를 다시 발명하고 있기 때문이다. 그래서 결론이 온다. 더 본래적으로 다시 표현하고 이전 절차와 설계를 일부 지우고 처음부터 설계할수록 더 성공하게 된다는 것이다.

형태는 오히려 더 사람처럼

앞으로의 상호작용 형태를 묻는 질문에 변화의 속도가 먼저 언급된다. 2년 전만 해도 모두가 채팅이라며 채팅 상자를 온갖 곳에 던져 넣었다는 것이다. 그런데 지금은 그러고 싶지 않고 에이전트와 직접 관여하고 에이전트가 모든 일을 하기를 원하는 자리에 왔다.

그래서 관통하는 선이 역설적으로 표현된다. 오히려 조금 더 사람처럼 되기를 원한다는 것이다. 인공 지능이니 역설이 아닐 수도 있다는 말을 덧붙이며 지향점이 규정된다. 정말 훌륭한 동료, 최고 수준의 그런 동료처럼 행동하는 자리에 도달하는 것이다. 성질이 열거된다. 옳은 지점에서 되밀어낼 수 있고 모든 일을 하고 결코 불만하지 않고 전체 맥락을 정말로 이해하는 동료다. 그런 세계라면 지금까지 함께 일해 본 최고의 동료보다도 더 많이 관여하게 될 것이라고 본다.

실제 형태 사례가 슬랙이다. 사람들이 서로 관여하는 곳이기 때문에 그 형태를 택했다는 것이다. 그리고 구조가 정리된다. 멋진 것들 대부분이 후드 아래에서 일어나고 실제로는 모든 잡일을 해서 결국 끝내 주는데, UI 층은 그저 익숙하다는 것이다. 늘 알던 슬랙 그대로다. 그래서 그 방향이 에이전트를 모두에게 민주화하는 길이라고 본다. 다른 누구와도 쓰는 형태이기 때문이다.

배경 실행의 경험도 다뤄진다. 팀원 중에 어려운 문제가 있으면 오늘 밤 잘 때 에이전트 몇 개를 보내고 아침에 무엇을 가져오는지 보겠다고 하는 사람이 있다는 것이다. 그래서 남는 과제가 명확하다. 배경에 에이전트들이 있고 나를 위해 일하고 있지만 내가 실제로 원하는 것을 표현하고 원하는 방향으로 몰아갈 올바른 방법을 갖는 경험이 중요해질 것이라는 점이다. 그리고 정직하게 덧붙인다. 아직 아무도 그에 대한 완벽한 답을 가지고 있지 않다고 생각한다는 것이다.

12년 걸릴 마이그레이션이 3개월이 된다

제품으로 풀 것과 배치 엔지니어가 들어가 손을 더럽혀야 할 것을 어떻게 구분하느냐는 질문에, 가장 이상적인 상태가 먼저 제시된다. 가장 마법 같은 결과이자 커지는 모델 능력에 가장 충실한 것은, 실제로 당신을 돕는 유일한 것이 모델뿐인 상태라는 것이다. 가장 순수한 의미에서 어떤 문제든 그냥 클로드에게 말하면 클로드가 모든 것을 하는 방식이다. 자기 표현을 더 잘하도록 돕거나 발판을 만들어 주거나 심지어 제품을 만들어 줘서 그것으로 다시 표현하게 하고 그다음 허물고 원하던 절차를 만드는 것까지 포함한다.

물론 아직 거기 없다는 점을 인정하며 현실적 구분이 이어진다. 회사로서 하고 싶은 것이 직원들에게 가능성의 예술을 보여 주는 것이라면 제품을 집어 들어 초기 감각을 얻는 편이 낫다는 것이다.

그다음 대목이 이 절의 백미다. 새 직원이 들어와 갑자기 클로드 제품에 접근할 수 있게 되면, 누구에게도 허가를 청할 필요 없이 그냥 원하던 것을 만들 수 있다는 것을 깨닫는다는 것이다. 원하는 것이 아주 작은 대시보드일 때도 있는데, 과거에는 온갖 사람에게 가서 청해야 했고 거기에는 주체성이 많지 않았다. 지금은 클로드에게 말했고 클로드가 배포했다고 말한다는 것이다. 그러면 이제 뭔가를 할 수 있다고 느끼게 되고 그것이 조직과 회사를 가속하는 방법의 일부라고 본다.

반대편 사례도 구체적이다. 정말 어려운 문제이고 맞춤 제품이 없는 기초적 사업 문제, 예컨대 완수하는 데 문자 그대로 12년이 걸릴 대규모 코드 마이그레이션이 오랫동안 회사에 세금이었던 경우다. 그런 것은 제품을 사서 해결하지 않을 것이고 배치 엔지니어가 들어오거나 자기 엔지니어들이 AI와 함께 쓰려는 사고방식을 갖추고 절차를 맞춤 설계하고 반복하는 방식이 된다. 결과가 수치로 온다. 12년의 마이그레이션 노력이 3개월 정도로 바뀐다는 것이다. 그리고 효과가 인식의 확장으로 정리된다. 그것을 할 수 있다면 또 무엇을 할 수 있겠느냐는, 놀라운 사고방식의 개방이라는 것이다.

200명과 새로운 병목

팀 규모가 200명이라는 사실에 대한 질문이 나온다. 수백만 고객과 수십억 달러 매출을 이야기하는 상황이라는 전제가 붙는다.

답이 인력 구조로 시작한다. 오랫동안 업계에서 팀을 생각해 온 방식과 비슷하게 생각한다는 것이다. 시스템의 특정 부분을 이해하는 사람들의 집합이 있고 그들이 그것을 어디로 가져갈지와 어떤 문제를 풀지에 제품 소유권을 갖는다. 차이는 레버리지다. 가진 도구나 즉석에서 스스로 만드는 도구로 훨씬 레버리지가 커졌다는 것이다.

그런데 새로운 병목이 정확히 지목된다. 과거에는 프로젝트를 시작하면 엔지니어들이 가서 코드를 두드리고 일이 끝나는데, 그 시간에 제품 매니저나 테크 리드, TPM 같은 조율 역할이 모두를 정렬시키고 같은 페이지에 올려놓는 일을 할 수 있었다는 것이다. 그런데 지금은 프로젝트를 띄우고 방향에 대한 감을 가지면 엔지니어들이 이틀 뒤에 끝났다고 하고 모두를 같은 페이지에 올려놓을 시간이 없었다. 그래서 그런 역할들이 고전하고 있다는 것이다. 그리고 그것이 팀이 지금 여정 중인 문제로 규정된다. 이제 병목이 된 것들을 시간이 지나며 덜 병목이 되게 하고 사람들이 더 잘 성공하도록 만드는 방법이다.

규모에 대한 감탄도 솔직하다. 플랫폼과 제품 인프라, 하고 있는 모든 것을 통틀어 200명이고 1년 전에 이 인원으로 이걸 한다고 했다면 절대 불가능하고 방법이 없다고 답했을 것이라는 것이다.

제품 관리 직무의 변화가 특히 인상적이다. 이제 사람들이 거의 자기 직무의 가장 순수한 형태여야 한다고 느낀다는 것이다. 제품 관리에는 조율과 프로젝트 관리, 사람들을 같은 페이지에 올려놓고 앞으로 나아가게 하는 기관차 같은 부분이 많은데, 그런 것들이 훨씬 덜 중요해졌다. 너무 빨리 일어나기 때문이고 어느 엔지니어링 팀의 2주 스프린트를 무엇에 배정하겠다는 식의 일이 이제는 그냥 클로드와의 대화이며 그냥 일어난다는 것이다.

그래서 남는 것이 규정된다. 절대적으로 가장 어려운 층, 거의 가장 순수한 층에서 작동해야 한다는 것이다. 우리가 정말로 무엇을 풀어야 하는가, 실제로 누구를 위해 풀어야 하는가다. 말하기는 단순하게 들리지만 거의 가장 순수한 형태의 문제 해결이라는 평가가 붙는다. 그래서 취하는 베팅과 세우는 가설, 가진 논지가 정말로 중요해진다.

제품 방식 자체도 바뀌었다고 말한다. 보통은 숙제를 하고 베팅을 고르고 거기에 두 배로 걸겠지만 여기서는 불확실성의 공간이 너무 크고 그 분포에서 결과가 너무 변동성이 커서 아주 빠르게 포트폴리오를 만들어야 한다는 것이다. 그래야 베팅 중 어느 것이든 맞으면 이기는 셈이 된다. 스스로도 이상한 방식이라고 인정한다. 초집중이 아니라 포트폴리오를 원하는 것이고 투자와 조금 더 비슷하다는 비유가 나온다. 이유는 만들어야 할 것 대부분이 즉각적으로 만들어질 수 있기 때문이다. 그래서 우선순위 지정에 초집중할 필요가 없고 다만 절대적으로 가장 높은 층에서만 중요하다. 그리고 사고방식이 정리된다. 어떤 결과가 나와도 긍정적 외부 효과가 되도록 표현과 그릇을 만드는 것이다.

얼굴에 주먹을 맞을 준비

실패에 대한 관용도가 높아야 한다는 지적에 엔지니어링 쪽은 조금 덜하다고 웃으며 답하지만 팀과 나누는 표현이 인상적이다. 우리는 얼굴에 주먹을 맞을 준비가 정말로 된 팀이어야 한다는 것이고 문자 그대로 팀과 쓰는 문구라고 한다. 근거가 붙는다. 계획을 가지고 뭔가를 하고 있지만 얼굴에 주먹을 맞기 전까지는 모두 계획이 있다는 것이다.

주먹의 정체도 구체적이다. 정말 어려운 안전 문제나 정말 어려운 인프라와 규모 문제라는 것이다. 6개월 전에는 지금 처한 이 정도로 극단적인 규모 상황을 아무도 생각하지 못했을 것이라고 한다.

규모 변화를 보여 주는 개인 일화가 좋다. 크리스마스에 뉴욕 집에 갔을 때 가족들이 무슨 일을 하느냐, 클로드가 무엇이냐고 물었다는 것이다. 그런데 부활절 무렵 다시 갔을 때 사촌이 자기 맥 미니 설정을 보여 주겠다고 했고 클로드에서 일하는 게 멋지다고 했다. 그 사이 시간에 세상에서 클로드로 흘러 들어오고 나가는 모든 토큰이 이 팀이 만든 시스템을 통과하게 됐다는 것이다. 그래서 1월에 세운 계획과 베팅 배치를 조금 다르게 생각하도록 방향을 틀어야 했고 이 시대에는 그것이 상수일 것이라고 본다.

개인 워크플로도 공유된다. 한쪽은 자기 제품을 도그푸딩하기가 훨씬 쉬워진 점을 든다. 예전에는 자기 API와 통합하려고 코드를 많이 써야 실제 작동을 경험할 수 있었는데, 이제는 고객들이 플랫폼으로 만든 흥미로운 것을 보고 싶을 때 브라우저를 열고 여러 서비스에 계정을 만들어 만져 보는 대신, 관리 에이전트에게 이 제품들을 다 써 보고 스크린샷을 가져오라고 할 수 있다는 것이다. 그래서 상황이 이렇게 표현된다. 에이전트를 테스트하려고 에이전트를 쓰는 것이 훨씬 쉽고 빠르며 조금 메타적이지만 멋진 세계에 살고 있다는 것이다.

다른 한쪽은 원격 에이전트에 전부를 걸었다고 한다. 방식이 소박하다. 에이전트가 뭔가를 할 때마다 그것을 기억하기를 원하므로, 클로드에게 문자 그대로 기억하고 기억에 저장하라고 말한다는 것이다. 그리고 계속 대화하며 만족스럽지 않을 때마다 그것은 틀렸고 틀렸다는 것을 기억하고 다시 하지 말고 기억에 저장하라고 말한다. 기억에 저장되는 것을 지켜보고 계속 왔다 갔다 한다. 평가가 명확하다. 지금까지 중 가장 단순한 일이었고 자기가 엄청나게 더 생산적이 된 것을 발견했다는 것이다. 이유는 무엇을 좋아했고 좋아하지 않았는지 기억하기 때문이고 아무것도 클릭하거나 할 필요 없이 클로드에게 말하기만 하면 되는 것이 좋다는 것이다.

마지막으로 조직 내 위치가 정리된다. 플랫폼이 정말로 가운데 앉아 있다는 것이다. 덜 알려진 사실 하나가 언급된다. 외부 고객이 그 위에 만드는 것과 정확히 같은 API와 정확히 같은 플랫폼 위에 1차 제품들이 전부 만들어져 있다는 것이다. 그래서 1차 제품들이 이 팀의 고객이 된다. 그리고 아래로는 가속기와 추론, 연구, 모델 위에 앉는다. 협업 방식은 규모 덕분이라고 말한다. 앤스로픽이 아직 이 모든 문제를 다루는 여러 팀과 그냥 가장 친한 친구가 될 수 있을 만큼 작다는 것이다. 새 모델 계열이 나오면서 종단간으로 잘 작동해야 할 때, 여러 기능에 걸쳐 특정 문제에 전부를 거는 사람들의 묶음, 즉 타이거 팀을 아직 꾸릴 수 있을 만큼 기민하다고 한다. 그래서 결론이 소박하다. 강한 관계와 기민하게 함께 일할 올바른 방법을 찾는 것 외에 비법은 없다는 것이다.

더 생각해보기

• 오퍼스가 조언하고 소네트가 실행하는 구성이 소네트 단독보다 싸다면, 모델 선택을 비용으로 접근하는 관행은 어디까지 재검토돼야 하는가.
• 뇌는 내구성 서버에, 실행은 일시적 샌드박스에 두는 분리는 자체 구축 조직이 직접 따라할 수 있는 수준인가.
• 사람 절차를 그대로 옮기지 말고 에이전트 우선으로 재발명하라는 처방은, 규제나 감사 요건이 절차를 규정하는 산업에서 어떻게 적용되는가.
• 주제 전문가가 선호하는 왔다 갔다 하는 방식이 실제로는 덜 효과적이라면, 도입 과정에서 그 선호를 어떻게 다루어야 하는가.
• 조율 역할이 병목이 됐다는 진단은 그 역할을 줄여야 한다는 뜻인가, 아니면 조율 자체를 자동화해야 한다는 뜻인가.
• 베팅 대신 포트폴리오를 빠르게 만든다는 제품 방식은 자원이 제한된 조직에서도 성립하는가.
• 차별화되지 않는 층을 플랫폼에 맡기라는 권고와 벤더 종속 우려는 어떻게 균형을 맞추는가.
• 관측 가능성이 좋은 종류의 문제라는 규정은, 감사와 책임 소재를 실제로 어떻게 해결하는가.
• 200명으로 이 규모를 운영한다는 사실은 인력 계획의 기준선을 바꾸는가, 아니면 예외적 사례로 남는가.