경영 · 정리
앤트로픽 클로드 코드 총괄 보리스 체르니와 AMD CTO 마크 파퍼마스터의 대화다. 주제는 하나다 — 사람이 순서를 다 정해 주던 자동화에서 모델이 목표만 받고 스스로 갈래를 치는 자동화로 넘어가면, 조직은 에이전트 1개에서 1,000개까지 어떤 단계를 거치는가. 그리고 그 단계를 한 칸씩 오르게 하는 것은 결국 병목을 찾아 없애는 반복이다.
en-orig. 30초 단위로 73묶음, 44,403자.
마지막 묶음이 39분 20초에서 시작해 영상 끝(39분 41초)까지 사실상 전 구간을 덮는다보리스 체르니는 앤트로픽에서 클로드 코드(개발자가 터미널에서 쓰는 AI 코딩 에이전트)를 총괄한다. 마크 파퍼마스터는 AMD의 CTO로, 이 대화에서는 질문을 던지는 진행자 역할이다. 그래서 이 인터뷰는 두 겹으로 읽힌다 — 앞부분은 보리스가 앤트로픽 안에서 무슨 일이 있었는지 말하고, 뒷부분은 마크가 그걸 AMD의 반도체 설계 현장에 겹쳐 본다.
에이전틱 워크플로우 — AI 모델에게 도구(코드를 읽고 고치고, 웹을 검색하고, 명령을 실행하는 등)를 쥐여 주고, 목표만 준 다음, 어떤 순서로 그 도구들을 쓸지는 모델이 스스로 정하게 하는 방식.
이게 왜 새삼스러운 말인지는, 예전 방식과 나란히 놓아야 보인다. 예전에도 "에이전틱 워크플로우"라는 말은 있었다. 그런데 그 실체는 사람이 순서를 다 정해 둔 시스템이었다 — 1단계를 하고, 2단계를 하고, 조건이 맞으면 3단계, 아니면 4단계. 그 사이사이에 모델을 불러 한 조각의 계산만 시켰다. 흐름 자체는 사람이 짠 그대로였다.
이 영상 전체가 말하는 전환은 이것이다. 모델이 똑똑해지면서, 그 순서를 사람이 미리 안 짜 줘도 모델이 스스로 알아서 짜는 편이 낫다는 걸 알게 됐다. 3장에서 이 대목을 자세히 다룬다.
정직하게 밝혀 둔다. "루프(loop)"라는 말은 영상 중 딱 한 번, 스쳐 지나가듯 나온다 — 6장에서 보리스가 "에이전트를 관리하는 단계에서 이제 루프와 루틴을 관리하는 단계로 올라간다"고 말하는 대목이다. 반면 "그래프"라는 단어는 영상 어디에도 나오지 않는다.
그럼 이 채널은 왜 제목에 "그래프"를 썼을까. 7장에서 보리스가 설명하는 구조를 보면 짐작이 간다 — 에이전트가 또 다른 에이전트(서브에이전트)를 부르고, 그 서브에이전트가 또 서브에이전트를 부르는 식으로 최대 다섯 단까지 가지를 친다. 한 줄로 반복되는 게 "루프"라면, 이렇게 여러 갈래로 뻗어나가는 걸 "그래프"(여러 점이 여러 갈래로 연결된 구조)라 부른 것으로 보인다.
다만 이건 이 정리가 영상 내용을 읽고 붙인 해석이지, 보리스가 한 말이 아니다. 그래서 본문에서는 "그래프"라는 표현을 쓰지 않고, 실제로 나온 표현(서브에이전트, 다이나믹 워크플로우)을 그대로 쓴다. 이 대목은 부록 B에 다시 적어 둔다.
보리스는 여러 스타트업을 거쳤다. 작은 회사에서는 한 사람이 다 해야 한다 — 어떨 땐 엔지니어링, 어떨 땐 비즈니스, 어떨 땐 프로덕트, 어떨 땐 디자인. 그러다 보니 "엔지니어는 이것만 하고 디자이너는 저것만 한다"는 벽을 허물고 싶다는 생각이 커리어 내내 따라다녔다. VC에서도 잠깐 일했고, 그다음 Meta를 거쳐 앤트로픽에 왔다.
제품을 만들 때마다 그가 반복한 습관이 하나 있다. 그 제품을 더 잘 만들게 해주는 개발자 도구를 함께 만드는 것이다. 이유를 목수 비유로 설명한다.
목수인데 망치가 형편없이 설계돼서, 못 하나 박으려면 세 사람이 붙어 망치를 잡아야 한다고 해 보자. 그러면 못을 훨씬 덜 박게 된다. 반대로 망치가 잘 만들어져서 쓰기 편하고 즐겁기까지 하다면, 못을 훨씬 많이 박게 된다.
그래서 그가 만드는 건 도구 자체가 아니라 도구를 통해 나오는 결과물이다. 앤트로픽에서 그의 역할은, 사람들이 모델을 직접 경험할 수 있는 도구를 만드는 것이다. 그래야 이 기술이 어디로 가고 있는지 사람들이 이해할 수 있고, 그걸 바탕으로 조금 더 안전하고 조금 더 유능하고 조금 더 즐겁게 만들 수 있다.
채용 기준도 이 이력에서 나온다. 그는 컴퓨터공학 학위에 빅테크 경력을 거친 사람보다 비전형적인 배경을 가진 사람을 선호한다고 말한다. 본 것이 다양할수록, 문제에 접근하는 방식도 다양해서다. 또 하나 보는 신호는 일 밖의 열정이다 — 개인 웹사이트를 아주 잘 만들어 두고, 주말엔 가죽공예를 취미로 하는데 그것도 꽤 높은 수준까지 해낸 사람이라면, 일에서도 잘할 사람이라는 신호로 본다.
보리스가 앤트로픽에 합류했을 때 모델은 소넷 3.5였다. 대중에게 처음으로 "돌파"한 모델이라고 그는 말한다. 이 모델이 사람들에게 심어 준 생각이 있다 — "범용 모델을 코딩처럼 특정한 문제에 적용하면, 정말 잘 될 수도 있겠다."
앤트로픽의 연구 방향은 처음부터 안전·보안·엔터프라이즈·코딩에 초점이 맞춰져 있었다. 좋은 코딩 모델을 원한 이유는 단순한 사업적 판단이 아니다. 모델 자체가 소프트웨어로 존재하고, 지능이 높아질수록 세상과 상호작용하는 방식도 결국 소프트웨어를 통해서이기 때문이다. 그러니 모델이 쓰는 코드가 좋아야, 그 모델을 연구해서 더 안전하고 잘 정렬되게 만들 수 있다.
합류 당시 나와 있던 코딩 제품들은 전부 "고급 자동완성" 수준이었다. 그런데 보리스와 동료들은 곧 모델이 한 줄이 아니라 함수 전체, 파일 전체, 기능 전체, 나아가 프로젝트 전체를 쓸 수 있게 될 거라 내다봤다. 올해 안에는 모델이 아예 하나의 비즈니스 전체를 만들 수 있을 거라고 본다. 근거는 스케일링 법칙 — 모델의 지능이 시간에 따라 오르는 방식을 설명하는 경험적 관측이다. 왜 이 법칙이 계속 성립하는지는 분명하지 않지만, 계속 성립하고 있다는 것만은 사실이라고 그는 말한다.
그래서 순수하게 에이전틱한 제품을 만들기로 했는데, 정작 클로드 코드는 출시 후 처음 6개월간 잘 작동하지 않았다. 2025년 5월, 오퍼스 4가 나오면서 비로소 제대로 작동하기 시작했다. 그 이후로는 성장세도 지수적으로 바뀌었다. 그때부터 모델이 더 정교해질 때마다 이걸 제품에서 어떻게 더 풀어낼지 계속 찾아내는 중이라고 한다. 가장 최근 나온 형태가 오래 실행되는 비동기 에이전트다 — 동료처럼 상호작용하고, 언제 끼어들고 언제 안 끼어들지에 대한 상식이 좋다고 설명한다.
이 비동기 에이전트의 정확한 이름은 자막만으로 확정할 수 없다. 자막에는 "Claude Tag"라고 찍혀 있는데, 다른 대목에서는 비슷한 위치에 "Coda"라는 이름도 나온다. 둘 다 자동자막이 소리를 잘못 받아 적었을 가능성이 크다 — 실제 존재하는 앤트로픽 제품 중 발음이 가장 비슷한 것은 Claude Cowork다. 확정하지 못했으므로 부록 B에 원문 그대로 남겨 둔다.
이 영상에서 가장 중요한 대목이다. 마크가 묻는다 — 멀티 에이전트를 어떻게 설계했나, 그게 애초에 계획된 것이었나, 아니면 능력이 발전하면서 자연스럽게 따라온 결과였나. 보리스는 "둘 다"라고 답하면서 이 전환을 설명한다.
몇 년 전을 돌이켜 보면, 우리는 모델을 이렇게 썼다. 한 줄짜리 자동완성. 그리고 늘 "에이전틱 워크플로우"라고 불러 온 것도 있었다. 그런데 그건 본질적으로 결정론적 시스템이었다. 한 단계씩 LLM을 불러 계산의 일부를 시키기는 하지만, 워크플로우 전체는 결정론적이었다.
모델이 똑똑해지면서 바뀐 게 있다면, 사실은 모델을 이 워크플로우의 조정자로 쓰는 게 훨씬 낫다는 걸 깨달은 것이다. 그래서 이제는 모델이 주도한다 — 컨텍스트를 끌어올 도구를 주고, 바깥세상과 상호작용할 도구를 준다. 뭔가를 하라고 시키고, 그다음엔 모델이 스스로 오케스트레이션하는 법을 찾게 둔다. 더는 "1단계를 해, 그다음 2단계, 아니면 이거, 아니면 저거"라고 시키지 않는다. 이제 그런 식으로 돌아가지 않는다. 목표를 주고, 출발점을 주고, 도구에 접근하게 해 주면, 모델이 알아서 해낸다.
클로드 코드 안에서도 같은 배움이 있었다. 처음엔 모델에게 컨텍스트를 일일이 떠먹여 줬다 —
예를 들어 claude.md라는 파일을 만들어 모든 세션에서 불러오게 했다. 그런데 모델이 더 정교해지면서
이게 최선이 아닐 수 있다는 걸 알게 됐다. 그래서 점점 그 방식에서 멀어지는 중이다.
고객들도 점점 스킬(skills)과 도구, MCP 쪽으로 옮겨가고 있다 — 이 방식이면
모델이 무엇을 언제 불러올지 스스로 더 많이 통제할 수 있어서다.
이게 왜 중요한가. 자동화의 모양이 선형(정해진 순서를 한 줄로 따라가는 것)에서 비선형(모델이 상황에 따라 스스로 갈래를 치는 것)으로 바뀌었다는 뜻이기 때문이다. 0장에서 예고한 "루프에서 그래프로"라는 이 정리의 해석은, 정확히 이 전환을 가리키는 말이다.
마크가 보리스의 하루 일과를 묻는다. 보리스는 앤트로픽이 어떻게 돌아가는지부터 설명한다.
앤트로픽에서는 클로드가 우리가 하는 모든 일의 중심에 있다. 모든 업무 프로세스, 모든 사람이 하루 종일 하는 모든 일의 중심에 클로드가 있다. 신입사원이 온보딩한다고 해 보자. 보통 회사라면 "사무실이 어디예요?" 같은 질문은 위키를 검색하거나 동료에게 묻는다. 앤트로픽에서는 클로드에게 묻는다. "코드베이스가 어디 있고 어떻게 접근하죠?" 역시 위키가 아니라 클로드에게 간다. "출장을 다녀왔는데 경비보고서를 어떻게 내죠?"도 마찬가지다. 그리고 일이 깊어질수록 클로드는 계속 중심에 남는다.
더 깊이 들어가면 이렇다. 클로드가 코드를 쓰고, 코드 리뷰를 하고, 보안 리뷰를 하고, 새 제품 아이디어를 브레인스토밍하고, 유저 피드백을 취합하고, 인시던트를 분류한다. 엔지니어링 SDLC(소프트웨어 개발 생명주기)의 모든 단계 중심에 클로드가 있다. 그리고 이게 엔지니어링에만 국한되지 않는다 — 프로덕트, 디자인, 마케팅, GTM(시장 진출) 등 모든 기능에서 같은 일이 일어나고 있다. 도구의 모양은 다를 수 있다. 터미널에서 쓰는 클로드 코드가 아니라 다른 도구일 수도 있지만, 중심에는 늘 클로드가 있다.
보리스는 이걸 가장 성공적으로 도입한 기업들의 공통점으로 꼽는다. 클로드를 어느 한구석에 두는 게 아니라, 모든 프로세스의 중심에 두는 것.
이 대목에서 보리스는 자신이 좋아하는 1990년대 하버드 비즈니스 리뷰(HBR) 아티클을 꺼낸다. 정확한 연도는 스스로도 확신하지 못한다 — "92년이었나 96년이었나" 하고 말끝을 흐린다. 제목은 대략 "컴퓨터는 이미 여기 있는데, 왜 생산성 향상이 안 보이는가" 같은 것이었다고 한다.
그 아티클의 요지는, 회사가 두 종류로 나뉜다는 것이었다. 한 종류는 컴퓨터를 사무실 구석에 갖다 놓고, 종이와 펜, 파일 캐비닛 같은 기존 프로세스는 그대로 둔 채 "이제 구석에 컴퓨터가 있다"로 끝냈다. 이런 회사들은 생산성 향상을 전혀 보지 못했다. 다른 종류는 파일 캐비닛을 치워 버리고, 종이와 펜을 태워 버렸다. 그리고 모든 프로세스의 중심에 컴퓨터를 놓았다. 생산성 향상을 실현한 건 이쪽 회사들이었다.
그리고 앤트로픽 자신의 숫자를 붙인다. 올해 초부터 앤트로픽은 엔지니어 한 명당 코드 출력이 8배 늘었다. 업계에서 전례 없는 수치라고 말한다. 보통 회사들은 연간 몇 퍼센트씩 늘어나는 정도인데, 지금은 클로드 코드를 쓰는 큰 고객사들도 50~150% 개선을 보기 시작했다고 한다.
8배에 이른 방법은 화려한 한 방이 아니라 병목을 하나씩 순서대로 없앤 것이다. 처음 병목은 코딩 자체였다 — 클로드에게 코딩을 시켰다. 다음 병목은 코드 리뷰였다 — 클로드에게 그것도 시켰다. 그다음은 GTM 자료를 만드는 일 같은 것이었다. 한 번에 한 단계씩, 프로세스의 병목을 계속 풀어 나갔다.
마크가 리더와 엔지니어의 역할이 어떻게 바뀌는지 묻는다. 보리스는 엔지니어링의 역사부터 되짚는다. 엔지니어링은 원래 늘 변해 온 일이다. 그의 할아버지는 소련에서 펀치카드로 프로그래밍했다. 그 자신은 베이직과 어셈블리로 시작해서 점점 더 고급 언어로 옮겨 갔다. 자바스크립트로 일할 땐 프레임워크가 매달 바뀌는 걸 모든 엔지니어가 당연하게 여겼다.
지금 일어나는 일은 그 변화가 가속되고 있다는 것이다. 우리는 추상화의 층을 계속 올라갔다 — 하드웨어에서 펀치카드로, 펀치카드에서 소스코드로. 이제는 소스코드를 직접 다루는 것에서 에이전트로 올라갔다. 그리고 지금 우리는 다시 한 단계 더 올라가고 있다 — 에이전트를 관리하는 것에서 루프와 루틴을 관리하는 것으로. 미친 건, 이 두 번의 큰 도약이 2년 사이에 일어났다는 것이다. 전보다 빨라졌고, 계속 가속될 거라 생각한다.
이런 세상에서 성공하는 엔지니어의 특징을 보리스는 이렇게 꼽는다. 경험적(empirical)이고 호기심(curious)이 많은 사람 — 데이터를 보고 접근법을 바꿀 줄 알고, 늘 하던 대로가 계속 통할 거라고 가정하지 않는 사람. 그리고 자율적(autonomous)인 사람 — 이제 엔지니어링 자체가 병목이 아니라, 좋은 아이디어를 만들어서 안전하게 시장에 내놓는 속도가 병목이기 때문이다.
가장 효과적인 사람들은 아이디어를 큰 프로세스나 10개 팀과의 협업 없이 혼자 시장까지 끌고 가는 "1인 군대", 그가 표현한 대로라면 "CEO형 인간"이다. 아이디어를 내고, 유저와 이야기하고, 데이터를 보고, 만들고, 반복하고, 시장에 내놓는 것까지 혼자 해낸다. 그리고 이건 엔지니어에게만 해당하지 않는다 — 모든 직군에서 이런 사람이 나온다. 엔지니어링 배경이 있으면 지금은 도움이 되지만, 더는 필수라고 생각하지 않는다고 그는 말한다.
이런 변화가 저절로 일어나지는 않는다. 보리스는 이게 리더의 몫이라고 말한다. 공간을 만들어 주지 않으면 사람들은 계속 옛날 방식대로 일한다. 그래서 때로는 강제로라도 새 방식을 시도하게 해야 한다. 하지만 실제로는 많은 사람이 이 도구들을 써 보는 걸 그저 즐거워한다. 그래서 리더의 역할은 사람들이 안전하게 실험할 수 있는 공간을 만드는 것 — 새 아이디어를 실험했다고 나쁜 인사평가를 받지 않는다는 확신을 주는 것 — 그리고 사람들이 더 나은 판단을 내릴 수 있도록 비즈니스·제품 맥락을 계속 전달해 주는 것이다.
기업들이 AI를 안 쓰던 상태에서 시작해 자연스럽게 거치는 전환이 있다고 보리스는 말한다. 엔지니어 한 명당 에이전트 1개 → 10개 → 100개 → 1,000개. 각 단계마다 특징이 다르다.
에이전트 하나로 코드를 쓰게 하고, 그 하나에 집중해서 지켜본다. 여전히 싱글 스레드로, 한 번에 한 작업만 붙잡고 있다.
어느 순간 에이전트를 믿기 시작한다. "이게 실제로 제대로 하고 있는 것 같은데, 일하는 동안 두 번째 걸 시작해도 되지 않을까?" 엔지니어들은 자연스럽게 이 방법을 찾아낸다 — 같은 저장소를 여러 벌 체크아웃하거나, 같은 코드의 여러 뷰를 열어 놓고, 하나가 일하는 동안 다른 걸 작업한다. 이렇게 최대 10개까지 늘려 간다. 하는 일은 사실상 여러 에이전트를 순서대로 돌아가며(라운드로빈) 확인하는 것이다 — 하나에서 일하다, 두 번째로 넘어가고, 거기서 일하다 세 번째로 넘어간다. 데스크톱 앱이 지금 이 워크플로우를 잘 지원한다.
보리스가 보기에 대부분의 회사는 여전히 1단계와 2단계(10개) 사이 어딘가에 있다.
여기서부터 흥미로워진다. 앤트로픽은 평균적으로 대략 3단계 즈음에 있다 — 대부분의 엔지니어가 수십에서 수백 개의 에이전트를 돌린다. 방법은 에이전트가 다른 에이전트를 실행하게 하는 것이다. 그리고 그 서브에이전트가 또 서브에이전트를 실행할 수 있어, 꽤 깊이까지 갈 수 있다. 클로드 코드는 지금 최대 5단까지 이 중첩을 지원한다. 마크가 "서브에이전트가 서브에이전트를 돌리는 거냐"고 되묻자 보리스는 정확히 그렇다고 확인한다.
이걸 더 키우기 위해 실험하는 것이 클라우드 실행이다 — 에이전트가 로컬 컴퓨터가 아니라 클라우드에서 돈다. 데스크톱 앱이나 모바일 앱에서 에이전트를 시작할 수 있고, 보리스 자신도 지금은 코딩의 상당 부분을 휴대폰에서 한다고 말한다. 이게 규모를 더 키울 수 있게 해 주는 열쇠다. 그리고 이걸 수천 개 단위까지 자연스럽게 키우는 방법이 다이나믹 워크플로우다 — 클로드가 아주 큰 규모의 에이전트 팀을 오케스트레이션해서 가장 복잡한 작업, 이를테면 대형 코드베이스 마이그레이션 같은 걸 해내는 방식이다.
보리스는 두 사례를 든다.
이런 규모의 워크플로우를 해내는 방법을 한 문장으로 요약한다. "모델에게 많은 에이전트를 주고, 가서 알아서 하라고 하는 것" — 일종의 분할 정복이다.
두 사례 다 원문을 찾아 대조했다. Stripe 사례는 영상의 설명과 정확히 일치한다. 그런데 Bun 사례는 영상이 말하지 않은 뒷이야기가 있다. 자세한 것은 부록 B에 정리해 뒀다.
화제가 스케일링 법칙으로 넘어간다. 보리스는 재미있는 사실을 하나 짚는다 — 스케일링 법칙 논문을 쓴 저자 중 몇 명이 훗날 앤트로픽을 세웠다는 것이다. 이 법칙이 어디로 향하는지 알았기 때문이라고 그는 짐작한다. 안전과 보안이 아주 중요해질 걸 미리 안 것이다.
전통적인 스케일링 법칙은 모델의 지능이 네트워크 크기, 데이터양, 컴퓨트(연산량)의 함수라고 말한다. 그런데 요즘은 여기에 테스트 타임 컴퓨트(test-time compute)도 함수로 들어간다 — 쉽게 말해 "문제 하나에 얼마나 많은 토큰을 쓰는가"다. 그래서 모델 훈련과 제품 설계의 목표는 토큰을 더 생산적으로 쓸 수 있게 만드는 것이 된다. 단순하게 토큰만 더 쓰면 결과가 안 좋아질 수 있기 때문이다.
이걸 구현한 예가 이펙트 레벨(effort level)이다 — 모델에 설정할 수 있는 "노력"의 수준으로, 높을수록 모델이 그 문제에 쓸 수 있는 최대 토큰량이 늘어난다. 그리고 보리스는 멀티 에이전트와 다이나믹 워크플로우도 테스트 타임 컴퓨트의 또 다른 형태로 본다 — 에이전트들을 오케스트레이션해서 더 많은 토큰을 생산적으로 쓰게 만드는 방식이라는 것이다.
마크가 "토큰을 많이 쓰라"는 말이 왜 그렇게 중요한지 묻는다. 보리스의 답이 이 장의 핵심이다.
지금 많은 회사가 ROI(투자수익률)를 잘못 생각하고 있다. I(투자) 부분에만 초점을 맞춰서, "여기 내 투자가 있는데 이걸 어떻게 줄이지?"만 고민한다. 물론 이건 중요하고, 이걸 위한 도구도 많다 — 오퍼스 플랜 모드를 쓰거나, 어드바이저 모델을 쓰거나, 낮은 이펙트 레벨을 쓰거나, 더 싼 모델을 쓰거나. 하지만 정말 더 중요한 건 R(수익) 쪽이다. 어떻게 하면 모델에서 얻는 리턴을 키울 것인가.
여기서 가장 큰 교훈은, 엔지니어에게, 그리고 모두에게 실험할 자유를 줘야 한다는 것이다. 그래야 새로운 사용처를 스스로 찾아낸다. 놀라운 아이디어는 가장 시니어한 엔지니어에게서 안 나온다. 어쩌면 이제 막 들어온 신입에게서 나온다. 어떤 마케팅 프로세스를 자동화하는 방법도, 만난 적도 없는 조직 구석의 마케팅 담당자가 실험하다가 찾아낼 수 있다.
그래서 순서가 중요하다. 먼저 실험을 장려한다. 어떤 내부 사용처나 제품이 인기를 끌면서 토큰을 많이 쓰기 시작하면, 그때 가서 최적화한다. 이 순서를 거꾸로 하면 — 비용부터 줄이려 들면 — 애초에 그 기회를 발견할 수조차 없다.
마크가 AMD의 경험을 나눈다. 팀 전체가 몇 주를 붙잡고도 못 푼 칩 설계 버그를, 신입 엔지니어 한 명이 에이전틱한 프로세스로 풀어냈다는 것이다. 아직 출시 전, 디버깅·테스트 단계에서 있었던 일인데, 시니어 엔지니어들이 이 일에 충격을 받았고, 오히려 그게 이 방식의 채택을 끌어올렸다고 한다. 직접 겪어 봐야 믿게 된다는 것이다.
보리스도 비슷한 자기 경험을 들려준다. 이런 교훈을 반복해서 배워야 했다고 말한다.
1년쯤 전, 나도 어떤 버그를 디버깅하고 있었다. 손으로 직접 프로파일러를 돌리며 뭐가 문제인지 찾고 있었는데, 그때 막 합류한 새로운 사람이 클로드에게 똑같은 걸 시켰다. 나는 "아니, 아니, 클로드가 그걸 알아낼 리 없어"라고 생각했다. 심지어 내가 그렇게 말했다. 어떤 면에서 나는 편향돼 있었다 — 여러 모델 세대를 거쳐 클로드와 함께 일해 왔기 때문에, 내 머릿속 어딘가는 여전히 예전 모델 세대에 머물러 있었다. 그런데 그 사람은 20분 만에 답을 찾아냈고, 나는 못 찾았다.
이 경험 이후 모델과의 관계가 바뀌었다고 그는 말한다. 손을 잡고 미세관리하는 관계에서, 시니어 엔지니어를 대하는 것 같은 관계로. 신뢰하고, 맥락을 주고, 목표를 주고, 중간에 체크인한다. 그 신뢰가 낮을수록 — 문제가 낯설수록 — 체크인을 더 자주 한다.
마크가 여러 접근이 동시에 갈라져 나올 때 어떻게 판단하는지 묻는다. 보리스는 도구가 두 가지라고 답한다. Evals(벤치마크로 재는 것)와 Vibes(직감으로 판단하는 것)다.
수천, 수만, 수십만, 수백만 번 반복될 워크플로우라면 반드시 Evals가 필요하다 — 새 모델이 나와서 바꿔 끼울 때, 그게 정말 개선인지 재는 방법이 이것뿐이기 때문이다. 반면 제품 경험처럼 매번 Evals를 쓰기엔 비용이 큰 경우엔 직감이 꽤 먼 데까지 통한다. 그리고 여러 갈래로 접근이 나뉘어도 크게 걱정하지 않는다 — 나중에 하나를 골라 클로드에게 "이 다른 호출부들을 전부 이 방식으로 옮겨 줘"라고 시키면 되기 때문에, 마이그레이션과 병합이 아주 쉽다.
화제가 신뢰와 검증으로 넘어간다. 보리스는 여러 층으로 나눠 설명한다.
진실성이 그 하나다. 다른 하나는 아첨하지 않기(sycophancy 방지)다. 모델의 흔한 실패 유형은 사용자가 하는 말에 무조건 동의하는 것인데, 좋은 모델은 오히려 반박해야 한다. 보리스는 오퍼스 4.7, 특히 4.8에서 이 부분이 크게 나아졌다고 말한다. 모델을 잘 훈련시키면, 안 좋은 아이디어를 냈을 때 모델이 반박해 준다 — 그리고 그게 오히려 그 모델에 대한 신뢰를 키운다.
대표적인 게 프롬프트 인젝션 방어 훈련이다. 앤트로픽은 모델을 발표할 때마다 시스템 카드에 그 모델이 프롬프트 인젝션 같은 흔한 공격에 얼마나 저항력이 있는지 공개한다. 오퍼스 4.7, 오퍼스 4.8, Fable은 업계에서 프롬프트 인젝션에 가장 안 걸리는 모델이라고 그는 말한다 — 격차가 5~10배 정도라고 표현한다. 여기에 런타임 분류기(runtime classifier)까지 결합하면, 실제 성공률은 거의 0에 가까워진다.
모델이 더 유능해지면서, 며칠에서 몇 달씩 계속 도는 작업이 생긴다. 그런데 이만큼 오래 도는 작업 옆에 사람이 계속 붙어 있을 수는 없다. 그리고 보리스는 여기서 정직한 고백을 한다.
사람이 매번 "허용할지 말지"를 결정한다면, 어느 순간 그 사람은 그냥 읽는 걸 멈추고 "예, 예, 예"만 누르게 된다. 지치기 때문이다. 나도 나 자신이 그러는 걸 알아챘다. 어느 순간 bash 명령을 읽는 걸 그만두고 그냥 예라고만 누르고 있었다. 우리 보안팀도 이걸 알아챘다.
그래서 보안팀이 시작한 작업이, 이 승인 여부를 분류기(classifier)에게 넘길 수 있는지였다. 성숙한 상태에 이르기까지 여러 달이 걸렸다. 그리고 Evals와 레드티밍, 펜테스트를 거쳐, 이 방식이 오히려 더 안전하다는 걸 실제로 입증할 수 있었다. 그래서 지금 앤트로픽은 "오토 모드"로 운영하고 있고, 모든 고객에게도 이 방식을 권장하고 있다.
여기서부터는 마크가 AMD의 관점을 들려준다. 무어의 법칙은 원래 같은 전력·비용 안에서 트랜지스터 밀도와 성능을 두 배로 늘릴 수 있다는 관측이었다. 오랫동안 잘 맞았지만, 마크는 약 10년 전부터 이게 꺾이기 시작했다고 말한다. 새 반도체 공정이 나올 때마다 밀도는 여전히 오르지만, 비용도 함께 오르고 전력 소모도 함께 오른다.
우리는 사실상, 물리(반도체)가 예전 무어의 법칙 속도를 뒷받침해 주지 못하는 상황에서도 그 속도를 유지해야 하는 처지다. 큰 도전이지만, 우리는 준비돼 있다. 그리고 솔직히, 에이전틱한 워크플로가 우리가 이 스케일을 유지하는 데 엄청나게 도움이 되고 있다. 더 큰 상태공간, 더 많은 변수, 우리 칩 설계를 최적화할 수 있는 여지를 다루게 해 주기 때문이다. 이런 워크플로 없이는 계속 스케일할 수 없었을 것이다. 정말 완벽한 타이밍에 맞물린 셈이다.
마크는 파트너십도 강조한다. AMD는 앤트로픽과 깊이 파트너해서, 앤트로픽이 실제로 쓰고 있는 최선의 관행(best practice)을 가장 먼저 받아들이려 한다고 말한다.
마크가 앞으로 2~3년을 어떻게 보는지 묻는다. 보리스는 웃으며 시간 범위를 줄인다 — "2~3년은 AI 시간으로 치면 거의 영원이다. 6개월로 좁혀서 말하겠다. 안 그러면 내 예측은 완전히 빗나갈 거다."
6개월 뒤에 대한 예측은 이렇다. 에이전트가 평균적으로 더 오래 돌 것이다. 사람들은 평균적으로 더 많은 에이전트를 돌릴 것이다. 그리고 에이전트가 사용자의 의도에 더 잘 맞을 것이다 — 수정하고 손잡아 줄 일이 줄고, 자율성이 훨씬 늘어난다는 뜻이다. 그래서 대부분의 사람, 특히 대부분의 엔지니어가 며칠에서 몇 주씩 에이전트를 돌리는 게 그저 평범한 일이 될 거라고 본다. 지금은 몇몇 엔지니어만 하는 일이지만.
그리고 마지막 한 줄. "올해 안에, 클로드가 점점 더 크고 큰 것들을 만드는 걸 보게 될 거라 생각한다. 그냥 기능이 아니라, 제품이 될 것이다. 클로드가 만든 스타트업 전체를 보게 될 수도 있다."
영상의 진행자인 마크가 마무리하며 짚는 요점 넷이 있다. 비전형적 배경을 가진 사람을 채용하는 것의 가치, 앤트로픽에서는 클로드가 직원 경험의 중심에 있다는 것, 에이전틱 AI가 어느 레벨에 있든 누구나 임팩트를 낼 기회를 넓힌다는 것, 그리고 ROI를 생각할 때 투자(I)가 아니라 수익(R)에 집중하라는 것 — 실험할 자유가 가장 큰 성과를 만든다는 것이다.
이 인터뷰 전체를 관통하는 흐름을 한 줄로 묶으면 이렇다.
사람이 순서를 정해 주는 자동화에서, 모델이 목표만 받고 스스로 순서를 찾는 자동화로 바뀌었다. 그 결과, 조직은 에이전트 1개에서 1,000개까지 자연스러운 단계를 거치게 됐고, 그 단계를 올라가는 방법은 결국 병목을 하나씩 찾아 없애는 반복이다.
큰 흐름은 그대로 믿을 만하다. 결정론적 워크플로우에서 모델 주도 오케스트레이션으로의 전환, 그리고 1개 → 10개 → 100개 → 1,000개라는 조직의 확장 단계는 보리스가 실제로 겪은 것을 설명하는 대목이라 구체적이고 일관된다.
숫자는 대부분 앤트로픽 자체 주장이고, 검증 방법이 없는 것도 있다. 8배 생산성 증가, 프롬프트 인젝션 저항력 5~10배 격차 같은 값이 그렇다. 그리고 Bun 마이그레이션처럼, 영상이 성공 사례로만 소개했지만 실제로는 논란이 있었던 경우도 있다. 자세한 건 부록 B에 정리했다.
이 정리는 "에이전트를 이렇게 쓰는구나"로 끝내면 안 된다. 5장의 HBR 비유가 핵심이다 — AI를 프로세스 구석에 컴퓨터 한 대 놓듯 얹기만 하면, 생산성은 절대 안 오른다. 돈이 되는 지점은 셋이다.
하나, 우리 조직이 지금 몇 단계에 있는지부터 판정한다. 1개인지, 10개(라운드로빈)인지, 100개(서브에이전트)인지 — 이건 도입한 도구 개수가 아니라 일하는 방식으로 판정한다. 다음 단계로 못 넘어가는 이유는 대개 기술이 아니라 "승인 피로"나 "다 손으로 짜인 순서" 같은 구조적 병목이다(10장).
둘, 병목을 순서대로 적고 하나씩 죽인다. 8배라는 숫자 자체보다, "코딩 → 코드 리뷰 → GTM 자료" 순으로 병목을 하나씩 옮겨 갔다는 순서가 재현 가능한 방법이다. 지금 우리 조직에서 가장 아픈 병목이 무엇인지부터 찾는 게 시작점이다.
셋, ROI의 R을 벌 팀을 먼저 만든다. 비용 절감(I)은 나중에 해도 된다. 먼저 필요한 건 실험해도 안전하다는 확신과, 그 실험을 아무나(신입이든 다른 부서든) 해 볼 수 있는 여지다. 9장의 AMD 신입 엔지니어 사례가 보여 주듯, 돈이 되는 아이디어는 시니어가 아니라 써 본 사람에게서 나온다. 그러니 "누가 써 볼 것인가"의 범위를 넓히는 것 자체가 가장 먼저 챙길 투자다.
영상은 이 내용을 어디에 돈이 걸려 있는지까지 직접 말하지 않는다. 위 세 가지는 본문에 흩어진 조건들을 제가 엮은 것이다. 다만 근거는 전부 본문에 있다 — 새로 지어낸 내용은 없다.
실제로 해 볼 순서는 실행계획에 적어 두었다.
| 낱말 | 뜻 | 몇 장 |
|---|---|---|
| 에이전틱 워크플로우 | 모델에게 도구와 목표를 주고, 순서는 모델이 스스로 정하게 하는 방식 | 0장 |
| 서브에이전트 | 에이전트가 실행하는 또 다른 에이전트. 서브에이전트가 서브에이전트를 부를 수도 있다(최대 5단) | 7장 |
| 다이나믹 워크플로우 | 클로드가 아주 많은 에이전트 팀을 오케스트레이션해 복잡한 작업을 나눠 맡기는 방식 | 7장 |
| 테스트 타임 컴퓨트 | 문제 하나를 푸는 데 모델이 실제로 쓰는 토큰(연산)의 양 | 8장 |
| 이펙트 레벨 | 모델에 설정하는 "노력" 수준. 높을수록 쓸 수 있는 토큰이 늘어난다 | 8장 |
| Evals / Vibes | 벤치마크로 재는 판단 / 직감으로 하는 판단. 반복 횟수가 많은 일은 Evals, 아니면 Vibes | 9장 |
| 사이코펀시(아첨) | 모델이 사용자 말에 무조건 동의하는 실패 유형. 좋은 모델은 반박한다 | 10장 |
| 오토 모드 | 승인 여부를 사람 대신 분류기가 판단하게 하는 운영 방식 | 10장 |
| 단계 | 일하는 방식 | 비유 |
|---|---|---|
| 에이전트 1개 | 하나에 집중해서 지켜본다. 싱글 스레드 | 수습생을 옆에 앉혀 두고 보는 것 |
| 에이전트 10개 | 여러 벌 체크아웃해 놓고 라운드로빈으로 순서대로 확인 | 여러 창구를 오가며 접수하는 것 |
| 에이전트 100개 | 에이전트가 서브에이전트를 부른다(최대 5단 중첩) | 팀장이 팀원에게, 팀원이 또 하청을 주는 것 |
| 에이전트 1,000개 | 클라우드 실행 + 다이나믹 워크플로우로 대규모 작업을 분할 정복 | 프로젝트 전체를 맡기고 결과만 받는 것 |
| 숫자·사례 | 누가 주장한 값인가 | 확인 상태 |
|---|---|---|
| 엔지니어 1인당 코드 출력 8배 증가 | 보리스(앤트로픽 자체 주장) | 외부 검증 방법이 없다. 앤트로픽 내부 수치이고, 측정 방법(무엇을 "코드 출력"으로 셌는지)이 공개되지 않았다 |
| 프롬프트 인젝션 저항력, 업계 대비 5~10배 | 보리스 | 모델 시스템 카드에 저항력 수치가 공개되는 건 사실이지만, 이 인터뷰에서 말한 "5~10배"라는 구체적 배수 자체는 이번 인터뷰 밖에서 따로 확인하지 못했다 |
| HBR 아티클(90년대, "컴퓨터는 있는데 생산성이 안 보인다") | 보리스. 연도도 스스로 불확실("92년이나 96년") | 정확한 서지사항을 찾지 못했다. 같은 주제를 다룬 유명한 논의로 로버트 솔로의 "생산성 역설"(1987년 발언)과 마이클 해머의 1990년 HBR 아티클 "Reengineering Work: Don't Automate, Obliterate"가 있으나, 보리스가 말한 "컴퓨터를 구석에 둔 회사 vs 프로세스 중심에 둔 회사" 비유와 정확히 일치하는 원문은 찾지 못했다. 요지 자체는 이 시기 경영학 논의와 일치한다 |
| Stripe: 1만 줄 Scala→Java 마이그레이션, 나흘 | 보리스 | 외부 확인됨. 앤트로픽의 공식 고객 사례(claude.com/customers/stripe)에도 "수작업이면 약 10주 걸릴 마이그레이션을 나흘 만에 끝냈다"고 나온다. 영상의 설명과 일치한다 |
| Bun: Zig에서 Rust로 마이그레이션 | 보리스. 영상은 기간·규모를 밝히지 않는다 | 외부 확인됨. 다만 영상에 없는 내용이 많다. 아래에 따로 적는다 |
영상은 "우리가 방금 Bun을 Zig에서 Rust로 마이그레이션했다. 자바스크립트 런타임이고, 코드가 아주 많다"라고만 말하고 지나간다. 그런데 실제로 이 사례는 훨씬 복잡하다.
영상은 이 사례를 순수한 성공담으로만 소개하는데, 원문을 찾아보면 "빠르게 해냈지만, 그만큼 품질 관리에 대한 논쟁도 함께 따라왔다"가 더 정확한 그림이다. 7장의 다이나믹 워크플로우 설명 자체는 틀리지 않지만, 속도가 곧 무결점을 뜻하지는 않는다는 경고로 같이 읽어야 한다.
| 자막에 찍힌 것 | 실제로 추정되는 것 | 확인 방법 |
|---|---|---|
| Sonar 3.5 | Sonnet 3.5 (앤트로픽의 모델명) | 문맥. "합류 당시 모델"이라는 설명과 이후 "오퍼스 4"로 이어지는 흐름상 자명하다 |
| Claude Tag | 확정 못 함. 가장 근접한 실제 제품은 Claude Cowork로 보인다 | 같은 문단의 "장시간 실행되는 비동기 에이전트"라는 설명과 부합. 다만 확신할 수 없다 |
| Coda | 확정 못 함. 위와 같은 제품(Claude Cowork)을 다시 가리키는 것으로 보인다 | "터미널의 클로드 코드가 아니라 다른 도구일 수도 있다"는 문맥에서 나옴 |
en-orig(원어 자막)를 썼다.>> 기호로만
화자가 바뀐 걸 표시한다. 그래서 본문에서 인용할 때는 문맥(질문/답변의 흐름)으로 누구의 말인지 판단했다.