[한영자막] 왜 이제 '루프'가 아니라 '그래프'를 설계해야 할까?

URL: https://www.youtube.com/watch?v=nfUKLULchXE
영상 ID: nfUKLULchXE
날짜: 2026-08-12 (처리일)
원본 업로드일: 2026-08-11 (yt-dlp 메타데이터 확인)
채널: Tech Bridge
영상 길이: 39:41
대화: Boris(Anthropic의 Claude 관련 제품·개발 리더)와 Mark(AMD 측 인터뷰어)

자막의 cloud code, quad code, cloud tag, enthropic 등 ASR 오인식은 문맥에 따라 각각 Claude Code, Claude Code, Claude Cowork, Anthropic으로 보정했다. 발언의 의미와 흐름은 자동 영어 자막 전체를 기준으로 정리했다.

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI를 업무에 얹는 데서 멈추지 말고, AI 에이전트가 조정하는 동적 그래프(dynamic graph)로 업무 자체를 다시 설계해야 하는가?==

• 단순 자동완성에서 함수·파일·기능·프로젝트, 나아가 제품과 스타트업을 만드는 에이전트로 추상화 수준이 올라가고 있다.
• 고정된 step 1 → step 2 → if/else 루프 대신, 모델에 목표·출발점·도구를 주고 모델이 맥락에 맞게 순서를 조정하는 방식이 더 강력해지고 있다.
• Anthropic은 Claude를 엔지니어링뿐 아니라 온보딩, 제품, 디자인, 마케팅, GTM 등 모든 업무 프로세스의 중심에 두고 병목을 하나씩 제거하며 코드 생산량을 엔지니어 1인당 8배 높였다고 설명한다.
• 생산성의 핵심은 AI 도입 비용(Investment)을 줄이는 데만 있지 않고, 누구나 실험할 수 있게 해 새로운 활용처와 수익(Return)을 발견하는 데 있다.

이 대화는 Claude Code의 제품 진화, 멀티 에이전트와 동적 워크플로, AI 네이티브 조직의 채용·리더십, 테스트 타임 컴퓨트(test-time compute), 신뢰·검증·보안, 그리고 향후 6개월의 변화를 한 흐름으로 연결한다. 핵심 메시지는 “도구를 기존 프로세스 옆에 놓는 것”과 “AI를 프로세스의 중심에 놓고 업무 그래프를 다시 짜는 것”은 전혀 다르다는 점이다.

---

1. 여러 역할을 경험한 사람이 제품과 도구를 함께 설계한다

Boris는 자신의 창업·VC·Meta 경험을 거쳐 Anthropic에서 모델을 실제로 경험하게 하는 도구를 만드는 이유를 설명한다.

1.1. 실패와 다기능 경험이 제품 감각을 만든다

1. 창업마다 다른 모자를 썼다

   1. 매번 스타트업이 잘되지 않았지만, 실패할 때마다 많이 배웠다고 말한다.
   2. 어떤 때는 엔지니어링(Engineering), 어떤 때는 비즈니스(Business), 제품(Product), 디자인(Design)을 맡았다.
   3. 작은 회사에서는 이 역할을 모두 직접 해야 하므로, 엔지니어와 디자이너가 “각자 자기 일만 한다”는 벽을 일찍부터 허물게 됐다.
   4. 이후 여러 스타트업과 짧은 VC 경험을 거쳐 Meta에서 일했다.

2. 개발자 도구는 더 좋은 최종 제품을 만들기 위한 수단이다

   1. 제품을 만들 때마다 자신이 더 나은 제품을 만들 수 있도록 개발자 도구(Developer Tools)를 함께 만들었다.
   2. 아이디어를 구현하는 도구가 쉬울수록 그 아이디어를 실제 제품으로 만들 가능성이 높아진다는 직관이 있기 때문이다.
   3. 비유로, 망치가 형편없이 설계되어 못 하나를 박는 데 세 사람이 망치를 잡아줘야 한다면 사람들은 못을 훨씬 덜 박게 된다.
   4. 반대로 잘 설계되어 쓰기 쉽고 사용하는 것이 즐거운 망치라면 더 많은 못을 박게 된다. 따라서 좋은 도구는 제작 행동의 빈도와 결과물을 동시에 바꾼다.

3. 도구 자체가 목적은 아니다

   1. “중요한 것은 도구가 아니라 제품의 최종 결과(the end result of the product)”라는 관점을 Meta와 Anthropic에 가져왔다.
   2. Anthropic에서 가장 중요한 최종 기준은 안전 미션(Safety Mission)이다.
   3. Boris의 역할은 사람들이 모델을 직접 경험하고 모델이 어디로 향하는지 이해하도록 도구를 만드는 것이다.
   4. 그 경험이 모델을 더 안전하고(safe), 더 유능하고(capable), 더 즐겁게(delightful) 만들 수 있게 한다.

1.2. 채용에서 보는 것은 정형화된 이력보다 넓은 경험과 열정이다

1. 비전통적 배경을 선호한다

   1. 컴퓨터과학 교육을 받고 대형 빅테크에서만 일한 사람만을 전형으로 삼지 않는다.
   2. 서로 다른 배경과 다양한 경험을 가진 사람이 문제를 여러 관점에서 바라볼 가능성이 높다고 본다.
   3. 많은 문제를 여러 방식으로 풀어본 경험이 많을수록 새로운 문제에 가져올 수 있는 것이 많아진다.

2. 일 바깥의 몰입도 신호로 본다

   1. 업무뿐 아니라 다른 일에도 열정적인 사람을 좋아한다고 말한다.
   2. 개인 프로젝트나 취미가 있고, 예를 들어 훌륭한 개인 웹사이트를 만들면서 주말에는 가죽공예(leather working)를 높은 수준으로 하는 사람이 좋은 신호다.
   3. 한 분야를 스스로 깊게 파고 결과를 낸 사람은 업무에서도 높은 수준으로 수행할 가능성이 있다고 본다.

---

2. 자동완성에서 에이전트, 제품, 스타트업으로 올라간 Claude의 추상화

Anthropic은 처음부터 코딩 모델을 만들려 했지만, 제품 형태는 모델 능력이 올라갈 때마다 스스로 바뀌었다.

2.1. Anthropic의 코딩 모델 방향은 안전과 세계 상호작용에서 출발했다

1. Claude 3.5 Sonnet의 대중적 돌파

   1. Boris가 Anthropic에 합류했을 때 모델은 Claude 3.5 Sonnet이었다.
   2. 이 모델은 범용 모델을 특정 문제, 특히 코딩에 적용하면 매우 잘할 수 있다는 사실을 대중에게 인식시킨 첫 모델이라고 평가한다.
   3. Anthropic의 연구 방향은 안전(Safety), 보안(Security), 엔터프라이즈(Enterprise), 코딩(Coding)에 오랫동안 집중되어 있었다.

2. 모델이 소프트웨어이기 때문에 코딩이 중요하다

   1. 모델 자체가 소프트웨어로 존재하고, 지능이 높아질수록 세계와 상호작용하는 통로도 소프트웨어가 된다.
   2. 모델이 쓰는 코드가 좋아야 모델이 세계와 잘 상호작용할 수 있다.
   3. 좋은 코드가 있어야 연구자들이 모델을 더 잘 관찰하고, 더 안전하고 정렬된(aligned) 모델로 개선할 수 있다.
   4. 따라서 Boris의 초기 과제는 “Anthropic이 만들 코딩 제품은 무엇인가?”를 찾는 일이었다.

2.2. 제품 형태는 선형적으로 커지는 모델 능력을 따라가야 했다

1. 화려한 자동완성의 한계

   1. 당시 시장의 코딩 제품은 한 줄을 이어 쓰는 “fancy autocomplete”였다.
   2. 처음 써보면 놀라운 경험이었지만, 모델이 곧 한 줄을 넘어 전체 함수를 작성할 수 있을 것으로 봤다.
   3. 다음 단계는 전체 파일, 전체 기능(feature), 전체 프로젝트(project)이며, 영상에서는 연말에 전체 비즈니스(business)를 만들 수 있을 것이라는 전망까지 제시한다.

2. 스케일링 법칙과 지수적 진행

   1. 모델 지능이 시간에 따라 올라가는 스케일링 법칙(scaling laws)이 계속 작동하고 있다.
   2. 왜 계속 작동하는지는 분명하지 않은 경험적 관찰이지만, 실제로는 그 상승이 멈추지 않고 오히려 빨라지는 것처럼 보인다.
   3. 현재 수준의 제품으로는 앞으로의 모델 능력을 사용자가 경험하기 어렵기 때문에, 단순 보조가 아닌 순수 에이전트형(purely agentic) 제품이 필요했다.

3. Claude Code의 초기 실패와 전환점

   1. Claude Code는 처음 약 6개월 동안 기대만큼 잘 작동하지 않았다.
   2. 모델이 제품을 따라잡는 데 시간이 필요했고, Boris는 전환점을 2025년 5월 Claude Opus 4로 꼽는다.
   3. 그 시점부터 제품의 성장도 지수적으로 변했다. 처음부터 지수적이었던 것이 아니라, 모델이 충분히 성숙한 뒤 성장이 가속됐다.
   4. 모델이 더 정교해질 때마다 제품 안에서 잠겨 있던 새로운 사용 방식을 발견하며, Anthropic은 계속 자기 제품을 스스로 disrupt할 것이라고 말한다.

2.3. 최신 형태는 동료처럼 상호작용하는 장시간 비동기 에이전트다

1. Claude Cowork의 방향

   1. Claude Cowork는 긴 시간 실행되는 비동기 에이전트(long-running asynchronous agent)다.
   2. 사용자는 명령을 한 번씩 내리는 대신 동료(co-worker)와 상호작용하듯 일을 맡긴다.
   3. 좋은 상식(common sense)을 갖고 언제 개입해야 하고 언제 개입하지 않아야 하는지 판단하는 능력이 핵심이다.

2. 폼팩터는 계속 바뀐다

   1. Claude Code, Cowork 등은 종착점이 아니라 모델 능력을 해방하는 현재의 폼팩터(form factor)다.
   2. 모델이 계속 발전하면 Anthropic은 다음 폼팩터를 찾기 위해 다시 자기 제품을 해체하고 재설계할 것이다.
   3. 따라서 지금의 도구 이름을 고정된 정답으로 보기보다, 모델 능력과 함께 바뀌는 인터페이스로 봐야 한다.

---

3. ‘루프’에서 ‘그래프’로: 모델이 워크플로의 코디네이터가 된다

영상 제목의 핵심은 에이전트 수가 늘어난다는 사실 자체가 아니라, 업무의 실행 순서를 사람이 미리 고정하지 않는다는 구조적 변화다.

3.1. 결정론적 에이전틱 워크플로에서 동적 오케스트레이션으로

1. 기존 방식은 LLM이 끼어든 결정론적 루프였다

   1. 과거에는 한 단계씩 진행되는 결정론적(deterministic) 시스템을 에이전틱 워크플로라고 불렀다.
   2. 각 단계가 어떤 계산을 위해 LM을 호출하더라도 전체 흐름은 사람이 정해둔 순서대로 움직였다.
   3. 예를 들면 “1단계 실행 → 2단계 실행 → 2단계가 아니면 A, 아니면 B”처럼 조건문과 루프를 사람이 설계했다.

2. 새 방식은 모델이 워크플로를 조정한다

   1. 모델 지능이 올라가면서 모델을 워크플로의 코디네이터(coordinator)로 쓰는 편이 더 나아졌다.
   2. 사람은 목표(goal), 시작점(starting point), 도구(tools), 외부 세계와 상호작용할 권한을 제공한다.
   3. 모델은 필요한 맥락을 가져오고 어떤 도구를 어떤 순서로 호출할지 스스로 결정한다.
   4. 더 이상 사람이 모든 분기와 순서를 사전에 지정하지 않는다. 같은 목표라도 상황에 따라 다른 경로를 선택하는 그래프가 된다.

3. 핵심 전환은 통제권의 재배치다

   1. 사람이 모든 행동을 미리 결정하는 방식에서, 사람이 목표와 가드레일을 정하고 모델이 실행 그래프를 탐색하는 방식으로 바뀐다.
   2. 이는 무제한 자율성을 뜻하지 않는다. 도구 권한, 검증, 평가, 보안 규칙을 함께 설계해 모델이 안전한 범위에서 경로를 선택하게 한다.

3.2. 맥락을 프롬프트에 모두 넣는 대신 스킬·도구·MCP로 분산한다

1. 초기에는 모델에게 맥락을 spoon-feed했다

   1. Claude Code 초기에는 모델이 일을 잘하도록 필요한 맥락을 사람이 미리 많이 넣어줬다.
   2. 모든 세션에 로드되는 CLAUDE.md 같은 파일을 사용해 공통 지침과 정보를 제공했다.
   3. 모델이 발전하면서 이 방식이 항상 최선은 아니라는 사실을 배웠다.

2. 동적으로 필요한 맥락을 불러오게 한다

   1. 고객들은 점점 더 많은 정보를 고정 파일에 쑤셔 넣는 대신 스킬(skills), 도구(tools), MCP(Model Context Protocol)로 옮기고 있다.
   2. 모델이 언제 어떤 맥락을 불러올지 더 많이 제어할 수 있기 때문이다.
   3. 즉, 맥락도 정적인 프롬프트 덩어리가 아니라 모델이 필요에 따라 연결하는 그래프의 노드가 된다.

3.3. Anthropic 내부에서 Claude는 모든 업무 그래프의 중심이다

1. 신입 온보딩부터 Claude를 호출한다

   1. 보통 회사라면 신입이 사무실 주소를 위키에서 찾거나 동료에게 묻는다.
   2. Anthropic에서는 Claude에게 사무실 위치와 주소를 묻는다.
   3. 코드베이스가 어디에 있고 어떻게 접근하는지, 출장 경비를 어떻게 신고하는지도 위키 검색이나 동료 질문 대신 Claude에게 물어본다.

2. 엔지니어링 SDLC 전부를 연결한다

   1. Claude가 코드를 작성한다.
   2. Claude가 코드 리뷰(code review)와 보안 리뷰(security review)를 수행한다.
   3. 새로운 제품 아이디어를 브레인스토밍하고 사용자 피드백을 모은다.
   4. 인시던트를 분류·처리(triage)한다.
   5. 따라서 Claude는 코드 작성 도구 하나가 아니라 엔지니어링 소프트웨어 개발 생명주기(SDLC) 전체를 잇는 중심 노드다.

3. 엔지니어링 밖으로 확장한다

   1. 제품, 디자인, 마케팅, GTM(Go-To-Market) 등 모든 직무에서도 같은 중심 구조가 나타난다.
   2. 직무에 따라 터미널 속 Claude Code를 쓰기도 하고 Cowork 같은 도구를 쓰기도 하지만, Claude를 프로세스의 중심에 둔다는 원리는 같다.
   3. 가장 성공적으로 Claude를 도입한 고객은 기존 프로세스 옆에 도구를 하나 더 놓는 것이 아니라 모든 프로세스의 중앙에 배치한다.

---

4. AI를 구석에 놓지 말고 프로세스 중심에서 병목을 제거한다

4.1. 1990년대 컴퓨터 도입 논쟁이 주는 교훈

1. 컴퓨터를 사무실 구석에 둔 회사

   1. 1990년대 Harvard Business Review의 “컴퓨터가 도입됐는데 왜 생산성 효과가 보이지 않는가?”라는 취지의 글을 소개한다.
   2. 한 유형의 회사는 컴퓨터를 사무실 구석에 갖다 놓고도 종이, 펜, 서류 캐비닛 기반 업무를 그대로 유지했다.
   3. 컴퓨터는 존재하지만 업무의 중심에는 없으므로 생산성 향상이 일어나지 않았다.

2. 종이와 서류 캐비닛을 버린 회사

   1. 다른 유형의 회사는 종이와 펜, 서류 캐비닛을 버리고 모든 프로세스의 중심에 컴퓨터를 놓았다.
   2. 이 회사들이 생산성 향상을 얻었다.
   3. AI도 마찬가지로 기존 업무 옆에 챗봇을 붙이는 것과 업무 설계 자체를 AI 중심으로 바꾸는 것은 다르다.

4.2. 8배 생산성은 한 번의 마법이 아니라 병목의 연쇄 제거다

1. 관찰된 수치

   1. Anthropic은 올해 초부터 엔지니어 1인당 코드 출력(code output)이 8배(8x) 증가했다고 말한다.
   2. 일반 기업의 생산성 향상이 보통 연간 몇 퍼센트 수준이라는 점과 비교하면 업계에서 전례가 드문 변화다.
   3. Claude Code를 사용하는 대형 고객들은 50%, 100%, 150% 수준의 개선을 보기 시작했다.

2. 병목별로 Claude를 투입한다

   1. 처음 병목은 코딩이므로 Claude가 코딩을 맡는다.
   2. 코딩이 빨라지면 다음 병목은 코드 리뷰가 되므로 Claude가 리뷰를 맡는다.
   3. 이후 GTM 자료 생성 같은 다른 병목에 Claude를 투입한다.
   4. 한꺼번에 완벽한 자동화를 만들기보다, 한 단계의 병목을 없앤 뒤 드러난 다음 병목을 제거하는 방식이다.

3. 자기 업무에서 출발하는 자기강화 루프

   1. Anthropic은 자신들이 실제로 겪는 문제를 해결하기 위해 제품을 쓰므로, 개발 우선순위가 실제 가치와 연결된다.
   2. 사용하면서 막히는 지점을 발견하고, 그 지점을 제품에 반영해 다시 더 많은 일을 처리한다.
   3. AI 네이티브 조직은 이 자기강화 사이클을 다른 기업보다 빠르게 돌린다.

---

5. 에이전트 시대의 사람, 리더, 조직문화

5.1. 추상화 수준이 올라갈수록 변화 속도와 요구 역량이 달라진다

1. 프로그래밍 추상화의 계단

   1. Boris는 할아버지가 소련에서 펀치카드(punch card)를 프로그래밍했다고 말한다.
   2. 자신은 성장하면서 BASIC과 어셈블리(assembly)를 익혔고, 이후 더 높은 수준의 언어를 배웠다.
   3. JavaScript를 쓰던 시절에는 매달 새로운 프레임워크가 나와 엔지니어가 계속 새 기술을 익혀야 했다.
   4. 하드웨어 → 펀치카드 → 소스코드(source code) → 에이전트(agent) → 루프·루틴(loops and routines)을 관리하는 단계로 추상화 수준이 올라가고 있다.

2. 최근 두 단계는 2년 안에 일어났다

   1. 소스코드를 직접 조작하는 단계에서 에이전트를 관리하는 단계로, 다시 에이전트와 루프·루틴을 관리하는 단계로 이동했다.
   2. 이 마지막 두 단계가 약 2년이라는 짧은 기간에 진행됐다.
   3. 엔지니어링의 변화는 계속 빨라질 것이며, 과거 방식이 영원히 유효할 것이라고 가정하면 안 된다.

3. 성공하는 사람의 특성

   1. 경험적(empirical)이고 호기심 많은(curious) 사람은 데이터를 보고 접근 방식을 바꾼다.
   2. 늘 하던 방식이 계속 통할 것이라고 가정하지 않고, 실제 작업 결과에서 피드백을 받는다.
   3. 엔지니어링이 더 이상 가장 큰 병목이 아니므로, 좋은 아이디어를 만들고 안전하게 시장에 가져가는 속도가 새로운 병목이 된다.
   4. 효과적인 사람은 여러 팀의 승인 절차와 협업을 기다리는 대신 아이디어를 내고, 사용자와 대화하고, 데이터를 보고, 만들고, 반복하고, 출시하는 “1인 군대(one-person army)”에 가깝다.
   5. 이런 사람은 엔지니어만이 아니라 제품·마케팅 등 모든 직무에서 나올 수 있다.

5.2. 엔지니어링 배경보다 적응력과 실험이 중요해진다

1. CS 전공이 더 이상 필수 조건은 아니다

   1. 엔지니어링 배경은 여전히 도움이 되지만, 에이전트 기반 작업을 수행하는 데 반드시 필요한 것은 아니라고 말한다.
   2. 문제를 정의하고 결과를 판단하며 사용자를 이해하는 능력이 더 넓은 직무에서 중요해진다.

2. 강조해야 할 역량

   1. 변화에 적응하는 능력(adaptability)이 필요하다.
   2. 변화에 겁먹지 않는 태도와 호기심이 필요하다.
   3. 이전에는 불가능했던 규모와 속도로 가설을 실험하고 학습해야 한다.
   4. 지난 7개월~1년 동안 새 에이전틱 워크플로가 반복(iteration)과 학습 주기를 크게 단축했다.

5.3. 리더의 역할은 공간과 맥락을 제공하는 것이다

1. 새 방식으로 실험할 공간을 만든다

   1. 리더가 공간을 만들지 않으면 조직은 계속 옛 방식으로 일한다.
   2. 새 도구를 시험할 시간을 확보하고, 필요하면 구성원이 새 방식으로 일하도록 유도해야 한다.
   3. 실험이 실패했다고 해서 나쁜 성과평가를 받지 않을 것이라는 심리적 안전감이 필요하다.

2. 결정에 필요한 맥락을 준다

   1. 리더는 구성원에게 비즈니스 맥락과 제품 맥락을 제공해야 한다.
   2. 맥락이 있으면 구성원이 매 단계마다 상사의 지시를 기다리지 않고 더 나은 결정을 내릴 수 있다.
   3. AI를 아직 업무 중심에 두지 않은 기업은 모범 사례 교육, 전 직원 교육, 문화 변화를 함께 추진해야 한다.

---

6. 1명당 1개에서 수천 개까지: 멀티 에이전트와 동적 워크플로

6.1. 에이전트 수가 늘어나는 단계

1. 1개 에이전트: 집중형 코딩

   1. 처음에는 엔지니어가 에이전트 하나를 붙잡고 한 작업을 처리한다.
   2. 사람과 에이전트 모두 하나의 과업에 집중하므로 사실상 단일 스레드(single-threaded)다.

2. 10개 에이전트: 신뢰와 라운드 로빈

   1. 에이전트가 올바른 결과를 낼 수 있다고 믿기 시작하면 두 번째 세션을 실행한다.
   2. 같은 저장소의 여러 체크아웃이나 코드의 여러 뷰를 두고, 하나가 일하는 동안 다른 작업을 한다.
   3. 한 에이전트에서 작업을 시작하고 두 번째로 이동한 뒤 세 번째로 이동하는 라운드 로빈(round robin) 방식이다.
   4. Claude Code와 Cowork 데스크톱 앱은 여러 세션을 병렬로 실행하고 오갈 수 있게 지원한다.

3. 수십~수백 개 에이전트: 에이전트가 에이전트를 만든다

   1. Anthropic 평균 엔지니어는 대략 수십~수백 개의 에이전트를 실행하는 단계에 있다.
   2. Claude Code는 서브에이전트(sub-agent)가 또 다른 서브에이전트를 생성하는 중첩을 지원한다.
   3. 현재 최대 5개 레이어까지 중첩할 수 있다.
   4. 대부분 기업은 아직 1개에서 2개 사이에 있지만, Anthropic은 평균적으로 3단계에 가깝다고 설명한다.

6.2. 클라우드 실행과 모바일이 규모를 열어준다

1. 로컬 컴퓨터의 한계를 넘는다

   1. 클라우드 실행(Cloud Execution)을 사용하면 에이전트가 사용자의 컴퓨터가 아니라 클라우드에서 실행된다.
   2. 데스크톱 앱이나 모바일 앱에서 에이전트를 시작할 수 있다.
   3. Boris는 실제로 요즘 휴대전화로 코딩하는 일이 많다고 말한다. 에이전트가 클라우드에서 계속 실행되기 때문이다.

2. 수천 개 에이전트와 동적 워크플로

   1. 다음 단계는 에이전트 수를 수천 개까지 늘리는 것이다.
   2. 동적 워크플로(dynamic workflows)는 Claude가 매우 큰 에이전트 팀을 오케스트레이션하도록 한다.
   3. 모델에 “이 큰 작업을 나눠서 해결하라”고 주면, 모델이 일을 분할하고 에이전트에 배분하고 결과를 조정한다.
   4. 이는 정해진 반복문이 아니라, 하위 작업의 상태에 따라 다음 노드와 경로가 달라지는 동적 그래프다.

6.3. 대규모 코드 마이그레이션 사례

1. Stripe의 Scala → Java 전환

   1. Stripe가 동적 워크플로를 사용해 대규모 코드베이스를 마이그레이션한 사례를 언급한다.
   2. 약 10,000줄 규모의 Scala에서 Java로의 마이그레이션이 기존에는 수개월 걸릴 작업이었지만, 약 4일에 완료됐다.

2. Bun의 Zig → Rust 전환

   1. JavaScript 런타임인 Bun도 Zig에서 Rust로 마이그레이션했다.
   2. 코드가 매우 많고 큰 작업이지만, 여러 에이전트에게 분할해 처리하는 방식으로 진행했다.

3. AMD의 주말 애플리케이션

   1. AMD의 AI 소프트웨어 개발 리더는 필요한 Rust 기반 애플리케이션을 주말 동안 만들었다.
   2. 출시 전 테스트, 회귀(regression), 검증은 별도로 통과해야 했지만, 이전에는 상상하기 어려운 속도였다.
   3. 멀티 에이전트가 단순 코딩 보조가 아니라 조직의 개발 리드타임과 경쟁 구도를 바꾼다는 사례다.

---

7. 테스트 타임 컴퓨트, ROI, 그리고 기회의 민주화

7.1. 모델의 지능은 학습 컴퓨트뿐 아니라 추론에 쓰는 토큰에도 좌우된다

1. 스케일링 법칙의 확장

   1. 전통적인 스케일링 법칙은 네트워크 크기, 데이터 양, 학습 컴퓨트에 따라 모델이 확장된다고 설명한다.
   2. 이제는 테스트 타임 컴퓨트(test-time compute), 즉 문제를 풀 때 모델에 얼마나 많은 토큰을 쓰게 하느냐도 결과에 영향을 준다.
   3. 단순히 토큰을 많이 쓰는 것이 아니라, 토큰을 생산적으로 사용해 더 나은 결과를 만들어야 한다.

2. 노력 수준과 토큰 예산

   1. 모델에는 effort level을 설정할 수 있다.
   2. 높은 effort를 주면 해당 문제에 사용하려는 최대 토큰량이 늘어난다.
   3. 멀티 에이전트와 동적 워크플로는 여러 에이전트의 토큰을 모델이 생산적으로 배분하는 테스트 타임 컴퓨트의 한 형태다.

7.2. ROI에서 I보다 R을 먼저 키워야 한다

1. 비용 절감은 중요하지만 시작점이 아니다

   1. ROI를 생각할 때 많은 기업이 Investment만 보고 비용을 줄이는 데 집중한다.
   2. 비용 최적화 수단으로 Opus의 plan mode, advisor 모델, 낮은 effort 설정, 더 저렴한 모델을 쓸 수 있다.
   3. 모든 작업에 Opus가 필요하지 않으며 Haiku나 Sonnet을 쓸 수도 있고, eval을 통해 어떤 모델이 충분한지 판단할 수 있다.

2. Return을 높이는 실험이 더 중요하다

   1. 더 중요한 질문은 모델에서 얻는 Return을 어떻게 높이느냐다.
   2. 직원 모두에게 새로운 사용 사례를 실험할 자유를 주면 조직이 예상하지 못한 활용처를 발견한다.
   3. 가장 뛰어난 아이디어를 반드시 가장 senior한 엔지니어가 내는 것은 아니다.
   4. 신입사원이나 조직 한구석의 마케팅 담당자가 반복적인 마케팅 업무를 자동화하는 훌륭한 아이디어를 낼 수도 있다.
   5. 먼저 실험해 기회를 발견하고, 실제로 내부 도구나 제품이 성공한 뒤에 토큰과 비용을 최적화해야 한다. 첫 단계 없이 최적화만 하면 새로운 기회 자체를 발견하지 못한다.

7.3. 직접 경험하면 계층을 넘어 채택이 확산된다

1. AMD의 칩 버그 사례

   1. AMD의 엔지니어링 팀이 몇 주 동안 해결하지 못한 칩 설계 버그가 있었다.
   2. 한 주니어 엔지니어가 “제가 해결할 수 있을 것 같다”고 말하고 에이전틱 프로세스를 적용했다.
   3. 제품 출하 전 디버그·테스트 단계에서, 여러 조건이 동시에 맞아야 재현되는 매우 복잡한 버그를 해결했다.
   4. 이 경험은 senior 엔지니어들을 충격에 빠뜨렸고 AMD 내부 에이전트 접근법 채택을 끌어올렸다.
   5. 리더들은 말로 설명을 들을 때보다, 자신들이 풀지 못한 문제나 큰 생산성 향상을 직접 경험할 때 즉시 신뢰하는 쪽으로 바뀐다.

2. 모델보다 사람의 겸손이 필요하다

   1. Boris도 모델에게 일을 넘기기 전까지 자신의 방식대로 수동 디버깅을 고집했다고 말한다.
   2. 약 1년 전, 자신이 프로파일러로 버그를 분석하던 중 새로 합류한 팀원이 Claude에게 같은 문제를 맡겼다.
   3. Boris는 “Claude가 알아낼 리 없다”고 생각했지만, 팀원은 20분 안에 올바른 해결책을 찾았고 Boris는 찾지 못했다.
   4. Boris가 이전 모델 세대와 일한 경험 때문에 이미 더 발전한 현재 모델을 과소평가했던 사례다.

3. 새로운 관계: 마이크로매니저에서 senior 엔지니어와의 협업으로

   1. 모델이 발전할수록 모델을 손으로 이끌고 모든 단계를 마이크로매니징할 필요가 줄어든다.
   2. 모델을 senior 엔지니어처럼 보고 맥락과 목표를 주며, 신뢰 수준에 따라 확인 빈도를 조절한다.
   3. 문제에 새로 투입된 모델을 덜 신뢰하면 더 자주 확인하고, 충분히 검증된 모델이면 덜 자주 개입한다.
   4. 핵심은 올바른 가드레일을 세운 뒤 모델이 일을 하게 두는 것이다.

7.4. Evals와 Vibes를 용도에 따라 나눈다

1. 반복 규모가 큰 워크플로는 eval로 측정한다

   1. 수천·수만·수십만·수백만 번 반복될 워크플로라면 eval이 필요하다.
   2. 새 모델을 평가 하네스(harness)에 교체해 넣고 결과가 실제로 좋아졌는지 측정할 수 있다.

2. 제품 경험은 vibes도 유효하다

   1. 제품 경험처럼 모든 요소에 eval을 만들기에는 비용이 큰 경우, 직관과 실제 사용감(vibes)이 충분히 유효할 수 있다.
   2. 모든 것을 동일한 측정 방식으로 평가하지 말고, 무엇이 intuition으로 판단 가능한지와 무엇이 정량 eval을 요구하는지 골라야 한다.
   3. 여러 구현이 동시에 존재해도 모델을 통해 코드를 쉽게 마이그레이션하고 병합할 수 있으므로, 최종 접근을 택한 뒤 다른 호출부를 새 워크플로로 옮기라고 Claude에 맡길 수 있다.

---

8. 신뢰·검증·보안이 자율성의 전제다

8.1. 신뢰는 모델 정렬, 진실성, 비아첨에서 시작한다

1. 모델은 안전하고 신뢰할 수 있어야 한다

   1. 모델이 비즈니스 프로세스의 중심이 될수록 안전(safe), 신뢰성(reliable), 신뢰성(trustworthy), 사용자의 의도에 대한 정렬(alignment)이 필수다.
   2. Anthropic은 이를 하나의 체크리스트가 아니라 여러 층위에서 다룬다.

2. 정렬의 구체적 요소

   1. 모델 정렬에는 진실성(truthfulness), 즉 올바른 내용을 말하는 능력이 포함된다.
   2. 또 다른 실패 모드는 사용자의 말에 무조건 동의하는 아첨(sycophancy)이다.
   3. 좋은 모델은 사용자가 나쁜 아이디어를 제시했을 때 무조건 맞장구치지 않고 반박해야 한다.
   4. 영상에서는 이후 모델 세대인 Opus 4.7·4.8이 이런 부분에서 크게 진전했다고 언급한다.

8.2. 프롬프트 인젝션과 사람 승인 피로를 함께 다룬다

1. 프롬프트 인젝션 방어

   1. 보안은 모델 훈련 과정에 포함되며, 공개하는 각 모델의 시스템 카드(system card)에 프롬프트 인젝션 같은 공격에 얼마나 강한지 설명한다.
   2. 영상에서는 Opus 4.7, Opus 4.8, Fable 계열이 업계에서 프롬프트 인젝션에 가장 강한 모델이며, 격차가 5~10배 정도라고 주장한다.
   3. 모델 훈련과 런타임 프롬프트 인젝션 분류기(runtime classifier)를 함께 사용한다.
   4. 레드팀(red teaming)과 침투 테스트(penetration testing)를 거친 실제 환경의 성공률은 거의 0에 가까워졌다고 설명한다.

2. 사람이 매번 Yes를 누르는 것도 위험하다

   1. 모델이 시스템과 더 많이 상호작용하고 며칠·몇 주·몇 달씩 실행되면 사람이 매번 승인할 수 없다.
   2. 더 근본적으로, 사람이 매번 Yes/No를 결정하게 하면 피로 때문에 어느 순간 내용을 읽지 않고 “yes, yes, yes”를 누르게 된다.
   3. Boris도 Bash 명령을 제대로 읽지 않고 Yes를 누르기 시작한 자신의 경험을 예로 든다.
   4. Anthropic 보안팀은 사람 대신 분류기가 판단하도록 라우팅하는 방식을 개발했다.
   5. 이 작업은 성숙해지는 데 여러 달이 걸렸지만 eval, 레드팀, 침투 테스트를 통해 사람 승인보다 실제로 더 안전하다는 것을 확인했다.
   6. Anthropic은 내부에서 auto mode를 사용하고 고객에게도 이를 권장한다.

8.3. 규모가 커질수록 가드레일과 파트너십이 중요해진다

1. 제품을 계속 재발명한다

   1. 모델과 에이전트가 커질수록 기존 제품 형태에 집착하지 않고 다시 설계해야 한다.
   2. 컴퓨트를 감당할 파트너를 찾고, 동적 워크플로가 올바른 일을 하도록 가드레일을 세워야 한다.

2. AMD의 물리적 스케일링 문제

   1. AMD는 과거 Moore의 법칙처럼 같은 전력·비용 범위에서 트랜지스터 밀도와 성능을 두 배로 높이는 흐름을 누려왔다.
   2. 약 10년 전부터 반도체 노드가 발전해도 비용과 전력이 올라가면서 예전 속도가 둔화됐다.
   3. 반도체 물리학이 예전 Moore의 법칙을 그대로 지원하지 않아도 그 속도를 유지해야 하는 큰 문제가 생겼다.
   4. 에이전틱 워크플로는 더 많은 변수와 칩 설계 상태 공간(state space)을 다루며 최적화할 수 있게 해 AMD가 계속 확장하는 데 큰 도움을 준다.
   5. AMD는 Anthropic과의 협력 등 업계 파트너십을 통해 좋은 관행을 빠르게 먼저 도입하는 것도 스케일링의 핵심이라고 본다.

---

9. 예측 가능한 다음 단계와 인터뷰의 최종 메시지

9.1. 2~3년 대신 6개월을 예측한다

1. AI에서 2~3년은 너무 길다

   1. Mark가 2~3년 뒤를 묻자 Boris는 AI의 시간 감각에서 2~3년은 너무 길어 예측이 틀릴 가능성이 크다고 답한다.
   2. 그래서 보다 현실적인 6개월을 전망한다.

2. 6개월 뒤의 에이전트

   1. 에이전트는 평균적으로 더 오랫동안 실행될 것이다.
   2. 사람들은 평균적으로 더 많은 에이전트를 동시에 실행할 것이다.
   3. 에이전트는 사용자의 의도에 더 잘 정렬되어 코스 수정과 손잡이가 줄어들 것이다.
   4. 더 많은 자율성이 생겨 대부분의 사람, 특히 대부분의 엔지니어가 에이전트를 며칠 또는 몇 주씩 실행하는 일이 정상적인 업무가 될 것이다.

3. 연말에는 기능에서 제품으로

   1. 영상의 연말 전망은 Claude가 더 큰 것을 만드는 방향이다.
   2. 단순 기능(feature)이 아니라 제품(product)을 만들고, 나아가 Claude가 전체 스타트업을 만드는 사례가 나타날 수 있다.
   3. Boris는 이 진행을 안전하고 즐겁게 사용할 수 있도록 만드는 것이 Anthropic의 과제라고 말한다.

9.2. 진행자의 마무리에서 추린 네 가지 takeaway

1. 비전통적 배경의 가치: 다양한 경험과 열정을 가진 사람을 채용하면 문제를 다른 시각에서 풀 수 있다.
2. Claude를 업무의 중심에 놓기: Anthropic에서는 Claude가 직원 경험과 모든 비즈니스 프로세스의 중앙에 있다.
3. 기회의 민주화: 에이전트는 직급과 직무에 관계없이 누구나 조직에 큰 영향을 줄 수 있게 한다.
4. ROI의 R에 집중하기: 투자 비용만 줄이기보다 실험의 자유를 제공해 가장 큰 승리를 만들어낼 활용처를 먼저 찾아야 한다.

---

주요 발언 모음

“중요한 것은 도구가 아니다. 중요한 것은 제품의 최종 결과다.”

“Claude를 쓰는 가장 성공적인 사람들은 Claude를 모든 프로세스의 중심에 둔다.”

“목표를 주고, 출발점을 주고, 도구에 접근하게 하면 모델이 그것을 어떻게 조정할지 알아낸다.”

“이제 엔지니어링이 병목이 아니다. 좋은 아이디어를 만들고 그것을 안전하게 시장에 가져가는 속도가 병목이다.”

“사람들이 실험할 자유를 주면 그들은 여러분을 놀라게 할 것이다.”

“처음부터 토큰을 최적화하면 기회를 절대 발견하지 못한다. 먼저 기회를 찾고, 그다음 다른 엔지니어링 문제처럼 최적화해야 한다.”

“나는 Claude가 알아낼 리 없다고 말했다. 그런데 새로 온 팀원이 20분 안에 올바른 해결책을 찾았고, 나는 찾지 못했다.”

“핵심은 올바른 가드레일을 세우고 모델이 일을 하게 두는 것이다.”

“사람이 매번 승인하게 하면 결국 읽지 않고 Yes, Yes, Yes를 누르게 된다.”

“6개월 뒤에는 대부분의 엔지니어가 에이전트를 며칠 또는 몇 주씩 실행하는 일이 정상적이 될 것이다.”

핵심 데이터 & 수치

• 약 6개월: Claude Code가 초기에는 충분히 잘 작동하지 않았던 기간이다.
• 2025년 5월: Claude Opus 4가 제품이 실제로 작동하기 시작한 전환점으로 언급됐다.
• 8배(8x): Anthropic이 보고한 엔지니어 1인당 코드 출력 증가량이다.
• 연간 몇 퍼센트: 일반적인 기업 생산성 개선과 비교하기 위해 제시한 수준이다.
• 50%·100%·150%: Claude Code를 쓰는 대형 고객들이 보기 시작한 생산성 향상 사례다.
• 2년: 소스코드 조작에서 에이전트 관리, 다시 루프·루틴 관리로 이동한 최근 두 추상화 단계가 걸린 기간이다.
• 1→10→100→1,000개: 한 사람당 운영하는 에이전트 수가 늘어나는 개념적 단계다.
• 5개 레이어: Claude Code가 지원하는 서브에이전트 중첩 깊이다.
• 10,000줄·4일: Stripe의 Scala→Java 마이그레이션 규모와 소요 기간으로 언급됐다.
• 수 주: AMD 팀이 해결하지 못한 칩 버그와 Anthropic 내부에서 흔히 다루는 장기 워크플로의 시간 단위다.
• 20분: 새로 합류한 팀원이 Boris가 수동으로 풀지 못한 버그의 올바른 해결책을 Claude로 얻은 시간이다.
• 5~10배: 영상에서 주장한 최신 모델의 프롬프트 인젝션 내성 격차다.
• 수일·수주·수개월: 사람의 개입 없이 모델이 실행될 수 있어야 하는 장기 워크로드의 시간 범위다.
• 약 10년 전: Moore의 법칙에 따른 비용·전력·밀도 개선이 둔화되기 시작한 시점으로 AMD 측에서 언급됐다.
• 6개월: Boris가 예측 가능한 미래로 선택한 기간이다.

결론 및 시사점

1. AI 도입과 AI 중심 재설계는 다르다: 챗봇이나 자동완성을 기존 프로세스 옆에 두는 것만으로는 생산성 혁신이 일어나지 않는다. 종이와 펜을 버리고 컴퓨터를 프로세스 중심에 둔 회사처럼, 업무의 중심 노드를 Claude로 바꿔야 한다.
2. 루프보다 그래프를 설계하라: 사람이 모든 순서와 분기를 고정하는 결정론적 루프 대신, 목표·초기 맥락·도구·가드레일을 설계하고 모델이 상황에 맞는 경로를 조정하게 해야 한다.
3. 병목을 하나씩 찾아라: 코딩 자동화가 끝이 아니다. 코드 리뷰, 보안 리뷰, GTM 자료, 사용자 피드백, 인시던트 처리로 병목이 이동할 때마다 다음 노드를 연결해야 8배와 같은 누적 효과가 나온다.
4. 사람의 역량은 실행보다 판단·맥락·학습으로 이동한다: 비전통적 경험, 호기심, 데이터에 근거한 수정, 자율성, 사용자 이해가 중요해지고 CS 전공이나 특정 프레임워크 숙련만으로는 충분하지 않다.
5. 리더는 실험의 안전망을 제공해야 한다: 구성원이 실패해도 불이익을 받지 않는 공간과 올바른 비즈니스·제품 맥락을 제공해야 조직 전체의 학습 사이클이 빨라진다.
6. 에이전트 수를 늘리는 것보다 오케스트레이션이 중요하다: 1개에서 10개, 100개, 1,000개로 늘릴 때 핵심은 단순 병렬 실행이 아니라 서브에이전트, 클라우드 실행, 동적 분할, 결과 통합을 포함한 그래프 설계다.
7. ROI의 순서는 Return 발견 후 비용 최적화다: 처음부터 싼 모델과 적은 토큰만 고르면 아직 발견하지 못한 기회를 잃는다. 모두에게 실험할 자유를 주고 성공한 워크플로를 eval과 비용 최적화로 다듬어야 한다.
8. 자율성은 신뢰·검증과 함께 키워야 한다: 모델 정렬, 비아첨, 프롬프트 인젝션 방어, 런타임 분류기, eval·레드팀·침투 테스트, 권한 가드레일을 에이전트 그래프의 일부로 설계해야 장기 실행이 안전해진다.
9. 가장 좋은 첫 실행은 작고 실제적인 병목이다: 조직 전체를 한 번에 바꾸기보다 실제 팀이 매일 겪는 코딩·리뷰·디버깅 같은 병목에서 시작하고, 성공을 직접 경험한 구성원이 다음 프로세스의 설계자가 되게 해야 한다.
10. 다음 폼팩터는 더 큰 제품과 조직 자체다: 영상의 전망대로라면 가까운 시기에 에이전트가 며칠·몇 주 동안 자율적으로 일하고, 기능을 넘어 제품과 스타트업 단위의 결과물을 만들게 된다. 따라서 지금부터 중요한 것은 특정 UI를 익히는 것이 아니라, 안전한 동적 업무 그래프를 설계하는 능력이다.

핵심 요약 (20줄)

1. 핵심 질문은 AI를 기존 업무 옆에 붙일지, 아니면 업무 프로세스의 중심에 놓고 다시 설계할지다.
2. Anthropic의 Boris는 여러 스타트업과 VC, Meta 경험을 거치며 엔지니어링·비즈니스·제품·디자인의 경계를 넘나들었다.
3. 그는 좋은 개발자 도구가 좋은 최종 제품을 만들게 하지만, 도구 자체가 아니라 결과가 목적이라고 강조했다.
4. Anthropic의 코딩 모델 방향은 소프트웨어로 세계와 상호작용하는 모델을 더 안전하게 연구하고 정렬하는 데서 출발했다.
5. Claude 3.5 Sonnet은 범용 모델을 코딩이라는 특정 문제에 적용할 수 있다는 사실을 대중에게 보여줬다.
6. 코딩 제품은 자동완성에서 함수·파일·기능·프로젝트, 제품과 스타트업을 만드는 에이전트로 발전하고 있다.
7. Claude Code는 초기 약 6개월 동안 약했지만 2025년 5월 Claude Opus 4 이후 실제로 작동하기 시작했다.
8. Claude Cowork는 동료처럼 상호작용하는 장시간 비동기 에이전트로 다음 폼팩터의 방향을 보여준다.
9. 과거 에이전틱 워크플로는 고정된 순서와 조건문을 따르는 결정론적 시스템이었다.
10. 이제는 목표·출발점·도구를 주고 모델이 맥락과 실행 순서를 조정하는 동적 그래프가 더 강력하다.
11. 사용자는 모든 맥락을 고정 파일에 넣기보다 스킬·도구·MCP를 통해 모델이 필요한 때 불러오게 한다.
12. Anthropic에서는 Claude가 온보딩, 코드 작성, 리뷰, 보안, 제품 아이디어, 피드백, 인시던트 등 모든 업무의 중심에 있다.
13. Anthropic은 병목을 코딩에서 리뷰, GTM 자료 생성으로 하나씩 옮겨가며 엔지니어당 코드 출력 8배를 보고했다.
14. 에이전트 사용은 1개에서 10개, 100개, 1,000개로 늘어나며 최대 5개 레이어의 중첩과 클라우드 실행으로 확장된다.
15. Stripe의 10,000줄 Scala→Java 마이그레이션이 수개월에서 4일로 줄었고 Bun도 Zig에서 Rust로 옮겨졌다.
16. 테스트 타임 컴퓨트는 모델에 더 많은 토큰을 무작정 주는 것이 아니라 멀티 에이전트로 생산적으로 배분하는 문제다.
17. ROI는 비용 절감만 뜻하지 않으며 신입과 비엔지니어도 실험해 새로운 Return을 발견하도록 해야 한다.
18. Boris는 새 팀원이 자신이 못 푼 버그를 Claude로 20분 만에 해결한 경험을 통해 모델을 senior 엔지니어처럼 신뢰하는 법을 배웠다.
19. 장기 자율 실행에는 정렬, 진실성, 비아첨, 프롬프트 인젝션 방어, 분류기, eval과 레드팀을 포함한 검증 그래프가 필요하다.
20. 향후 6개월에는 에이전트가 며칠·몇 주씩 일하고 기능을 넘어 제품과 스타트업을 만드는 일이 정상에 가까워질 수 있다.