# Boris Cherny — 루프 엔지니어링에서 그래프 엔지니어링으로 > 40분, 자동자막 기반 정리. 아래는 발화 취지 요약이며 축자 인용 아님. > **출처 주의: AMD 채널에서 Anthropic 임원이 자사 제품을 이야기하는 자리다.** 아래 8x 같은 > 수치는 **자기보고이고 외부 감사가 없다.** 우리 정직 가드상 IR·대외 자료에 외부 벤치마크로 > 인용하면 안 된다. 방법론은 훔치되 숫자는 우리 것을 쓴다. ## 한 줄 요지 에이전트를 몇 개 굴리느냐가 단계를 가르고, 그 단계를 올리는 방법은 **한 번에 병목 하나씩**이다. 그리고 사람이 승인 버튼을 누르는 게이트는 **사람이 읽기를 멈추는 순간 보안이 아니라 연극이 된다.** --- ## 1. 에이전트 사다리 — 1 → 10 → 100 → 1,000 Boris가 고객사에서 관찰한 자연스러운 전이: | 단계 | 모습 | |---|---| | 1개 | 엔지니어가 에이전트 하나에 붙어 단일 스레드로 일함 | | 10개 | 신뢰가 생기면서 라운드로빈. 같은 레포를 여러 개 체크아웃해 돌림 | | 100개 | **에이전트가 에이전트를 띄운다(서브에이전트).** Claude Code는 5단 중첩까지 지원 | | 1,000개 | dynamic workflows — 모델이 대규모 에이전트 팀을 오케스트레이션 | **"대부분의 회사는 1과 2 사이에 있다. Anthropic은 평균 3단계 정도다."** 사례: Stripe가 몇 달 걸릴 10,000줄 Scala→Java 마이그레이션을 **4일**에. Bun을 Zig→Rust로 이관. 큰 마이그레이션은 divide-and-conquer로 "에이전트 많이 줄 테니 알아서 해"가 통한다. > **AetherHeal 렌즈 — 우리는 어디인가.** 정직하게 보면 **2단계다.** 골든루프 1개가 codex 레인을 > 순차로 던지고, 내가 대화 세션에서 서브에이전트를 몇 개 쓰는 정도. 서브에이전트가 서브에이전트를 > 띄우는 구조는 없다. **다만 3단계로 올리기 전에 물어야 할 게 있다** — 우리 병목이 정말 에이전트 > 수인가? 어제 측정으로는 아니었다. 병목은 증거였다. 사다리를 오르는 것 자체가 목적이 되면 > `STATUS.md` 칸을 옮기는 것이 목적이 되는 것과 같은 실수다. ## 2. 8x를 만든 방법 — 한 번에 병목 하나씩 Anthropic은 올해 초 이후 **엔지니어당 코드 산출 8배**(자기보고). 업계 평균은 연 몇 %. 큰 고객사는 50~150% 개선을 보기 시작. **방법이 단순하다.** 코딩이 병목이면 Claude에 던진다 → 다음 병목은 코드 리뷰, 던진다 → 다음은 GTM 자료 생성, 던진다. **한 스텝씩 병목을 푼다.** > 우리 버전으로 옮기면: rename 블로커 → 승격 → Golden DB 계약 → RC 증거 조작자. > 실제로 지난 사흘이 이 모양이었다. **"다음 병목이 무엇인가"를 매일 한 문장으로 쓰는 게 > 이 방법의 전부다.** ## 3. 1990년대 생산성 역설이 정확히 지금이다 Boris가 좋아하는 HBR 옛 논문: "컴퓨터가 왔는데 왜 생산성이 안 오르나." 답은 회사가 두 종류라는 것이었다. - **한쪽은 사무실 구석에 컴퓨터를 놓고** 종이·펜·파일캐비닛을 그대로 뒀다 → 개선 없음 - **다른 쪽은 파일캐비닛을 버리고 종이를 태웠다.** 컴퓨터가 모든 프로세스의 중심이 됐다 → 개선 Anthropic에서 Claude는 온보딩부터 중심이다. **"사무실 주소가 어디죠?" → 위키가 아니라 Claude에게 묻는다.** 경비 처리도, 코드베이스 접근도. 그리고 깊이 들어가면 코드 작성·코드 리뷰·보안 리뷰· 제품 아이디어·사용자 피드백 집계·장애 트리아지까지 전부 Claude가 중심에 있다. 엔지니어링만이 아니라 제품·디자인·마케팅·GTM 전 기능이 그렇다. > **이건 Brynjolfsson의 "전기 30년"과 같은 얘기의 다른 판본이다** ([[260803_Erik Brynjolfsson — The Best and Worst Decade]]). > 능력이 아니라 프로세스 재설계가 병목이라는 것. ## 4. 결정론적 워크플로 → 모델이 오케스트레이터 예전: 결정론적 파이프라인이 중간중간 LLM을 호출. "1단계 하고, 2단계 하고, 아니면 이거." 지금: **목표와 시작점과 도구를 주고 오케스트레이션은 모델이 정한다.** 그리고 컨텍스트 주입 방식도 바뀌었다. 초기엔 `claude.md`로 **떠먹였는데**, 모델이 좋아지면서 **skills·tools·MCP로 옮기는 중**이다 — 모델이 무엇을 언제 로드할지 스스로 통제하도록. > 우리 `MACHINE-STATE.md`가 정확히 "떠먹이는" 형태다. 매 반복 앞에 통째로 붙인다. > 지금은 그게 맞다 — 금지사항을 확실히 읽히려는 것이니까. **다만 이게 커질수록 비용이고, > 언젠가 "러너가 필요할 때 꺼내 읽는" 형태로 바꿀 시점이 온다.** 지금은 아니다. ## 5. ROI에서 I가 아니라 R을 봐라 ← 이 대담의 실전 핵심 > "많은 회사가 ROI를 잘못 생각한다. **I(투자)만 본다.** 어떻게 줄일까, 어떻게 비용을 깎을까. > 물론 중요하고 해야 한다. plan 모드, advisor 모델, 낮은 effort, 싼 모델, evals로 확인. > **그런데 훨씬 중요한 건 R이다.**" R을 키우는 법은 하나: **실험의 자유를 준다.** 그리고 **누가 좋은 걸 찾아낼지 예측할 수 없다.** > "브릴리언트한 아이디어를 내는 건 최고참 엔지니어가 아니다. 신입일 수도 있다. > 마케팅 프로세스를 자동화하는 방법을 찾는 건 엔지니어가 아니라, 조직 구석의 만난 적도 없는 > 마케팅 담당자일 수 있다. **실험했기 때문에.**" 순서가 중요하다: **먼저 실험을 장려한다 → 토큰을 많이 쓰더라도 성공한 사례가 나오면 → 그때 최적화한다.** 앞부분을 안 하면 기회 자체를 못 찾는다. > **AetherHeal 렌즈 — 우리는 지금 I만 보고 있었다.** 지난 사흘 대화의 상당량이 effort 조절, > 시트 관리, 소진율이었다. 전부 I다. **R을 키우는 쪽 질문은 한 번도 안 했다** — > "다른 데스크가 각자 에이전트로 뭘 실험해봤나?" 압구정 스태프, 박동우, 주팀장이 > 각자 자기 병목에 에이전트를 붙여본 적이 있나. 없다면 그게 우리가 안 쓰고 있는 레버다. ## 6. 멀티에이전트 = test-time compute의 다른 이름 전통적 스케일링 법칙은 네트워크 크기·데이터·컴퓨트의 함수. 여기에 **test-time compute**가 붙었다 — 쉽게 말해 문제에 토큰을 얼마나 던지느냐. effort 레벨이 그 조절 손잡이다. **멀티에이전트와 dynamic workflow도 test-time compute의 한 형태다.** 토큰을 더 쓰되, 모델이 오케스트레이션하게 해서 **그 토큰이 생산적으로 쓰이게** 하는 것. "순진하게 하면 토큰만 더 쓰고 결과는 그대로다." ## 7. evals와 vibes — 둘 다 자리가 있다 - **수천~수백만 번 반복하는 워크플로 → evals 필수.** 새 모델이 나왔을 때 하네스에 끼워 넣고 개선됐는지 재는 유일한 방법 - **제품 경험 같은 것 → vibes로 꽤 멀리 간다.** evals에는 작성 비용이 있어서 전부에 쓸 수 없다 - 요령은 **"언제 직관이 무언가를 말해주고, 언제 eval이 필요한가"를 고르는 것** > 우리 "산문은 증거가 아니다" 규칙과 같은 계열인데, **한 가지가 다르다.** 우리는 전부에 > red-green을 요구한다. Boris는 그게 비용이라고 말한다. **우리 경우엔 임상 소프트웨어라 > 지금 기준이 맞다** — vibes로 넘길 수 있는 건 UI 정도고, 게이트·권한·증거 경로는 아니다. > 다만 "어디까지 vibes로 갈 것인가"를 의식적으로 정한 적은 없다. ## 8. 승인 피로 — 이 대담에서 가장 값진 발견 에이전트가 며칠·몇 주씩 돌면 사람이 계속 앉아 있을 수 없다. 그런데 그보다 먼저 알아챈 게 있다. > "사람이 매번 예/아니오를 결정하고 있으면, **어느 순간 사람이 실제로는 읽기를 멈춘다.** > 그냥 yes, yes, yes를 누른다. 예 누르는 데 지쳐서. **나 자신이 그러고 있는 걸 알아차렸다.** > bash 명령을 안 읽고 그냥 예를 눌렀다." 그래서 승인을 **분류기(classifier)로 라우팅**하는 작업을 시작했고, 성숙시키는 데 몇 달 걸렸다. evals·레드팀·펜테스트로 **그게 사람보다 실제로 더 안전하다는 것을 보였고**, Anthropic은 auto 모드로 돌리며 고객에게도 권한다. > **AetherHeal 렌즈 — 이건 우리 게이트 구조에 대한 직격이다.** > 우리는 human gate 6개와 CMO VETO를 두고 있다. 그 설계의 전제는 **사람이 읽는다**는 것이다. > 그런데 지난 사흘만 봐도 대표가 "밀어" "알아서 해" "다 승인"으로 답한 게 여러 번이다. > **그게 나쁘다는 게 아니라, 그 순간 게이트가 안전장치가 아니라 형식이 된다는 것이다.** > Boris의 처방은 "게이트를 없애라"가 아니라 **"사람이 실제로 읽는 소수의 게이트만 남기고 > 나머지는 검증 가능한 자동 판정으로 옮겨라"**다. > **우리 6게이트 중 대표가 실제로 매번 읽는 게 몇 개인지 세어볼 값어치가 있다.** > 답이 2개라면 나머지 4개는 자동 판정으로 옮기고, 남은 2개를 진짜로 지키는 게 더 안전하다. ## 9. 비사코팬시 — 모델이 반박해야 신뢰가 생긴다 정렬의 요소로 **truthfulness**와 **non-sycophancy**를 든다. 모델이 사용자 말에 다 동의하는 것이 실패 모드다. > "**내가 낸 아이디어가 나쁘면 모델이 반박한다. 그래서 내가 그 모델을 더 신뢰한다.**" > 어제 우리 루프가 정확히 이걸 했다. 내가 "Golden DB는 CI에 넣는 게 전부"라고 지시했는데 > **루프가 실제 DB에서 재보고 전제를 반증해서 되돌려보냈다.** 지시받은 대로 하지 않은 것이 > 옳았던 사례다. 이 성질이 없으면 무인 루프는 내 오류를 증폭하는 장치가 된다. ## 10. 겸손 — 그도 모델을 과소평가했다 1년쯤 전, 버그를 프로파일러로 손수 디버깅하고 있었다. 새로 온 사람이 같은 걸 Claude에게 시켰다. Boris는 "아니야, Claude가 못 풀어"라고 했다. **20분 뒤 그 사람이 정답을 들고 왔고 Boris는 못 풀었다.** 원인 진단이 정확하다 — **"나는 모든 모델 세대를 겪었기 때문에 오히려 머릿속이 옛 세대에 멈춰 있었다."** 익숙함이 편향이 된 것. > 반복해서 배운 결론: 모델이 발전하면서 **관계가 바뀐다.** 손잡고 마이크로매니징하는 것에서 > **시니어 엔지니어와 일하는 것**으로. 신뢰가 낮거나 문제가 새로울수록 자주 체크인한다. > **"올바른 가드레일을 세우고 모델이 일하게 두는 것."** ## 11. 추상화 계단과 "1인 군대" 하드웨어 → 펀치카드 → 소스코드 → **에이전트** → **루프·루틴 관리**. **마지막 두 단계가 2년 안에 일어났다.** 엔지니어링이 더 이상 병목이 아니게 되면서, 병목은 **좋은 아이디어를 만들어 시장에 내는 속도**로 옮겨갔다. 그래서 효과적인 사람의 원형이 바뀐다 — > "10개 팀과 협업해야 아이디어를 시장에 내는 사람이 아니라, **1인 군대에 가깝다. > CEO 원형이다.** 아이디어를 내고, 사용자와 얘기하고, 데이터를 보고, 만들고, 반복하고, 낸다." > 그리고 **엔지니어링 배경이 더 이상 필수가 아니다.** ## 12. 6개월 예측 (2~3년은 안 하겠다고 함) - 에이전트가 평균적으로 **더 오래** 돌고, 사람들이 **더 많이** 돌린다 - 의도 정렬이 좋아져 **교정과 손잡음이 줄어든다** - **며칠~몇 주씩 에이전트를 돌리는 게 보통이 된다** - 올해 말이면 Claude가 기능이 아니라 **제품**을 만들기 시작한다. **회사 전체가 만들어질 수도** 그리고 솔직한 이력 하나: **Claude Code는 첫 6개월간 잘 안 됐다.** 2025년 5월 Opus 4에서야 제대로 동작하기 시작했고, 성장이 지수적이 된 것도 그때부터다. --- ## 실행으로 뽑을 것 (AetherHeal) - [ ] **6게이트 감사 — 대표가 실제로 매번 읽는 게이트가 몇 개인가.** 읽지 않는 게이트는 안전장치가 아니라 형식이다. 읽는 것만 남기고 나머지는 검증 가능한 자동 판정으로 옮긴다. **이 대담에서 가져올 것이 하나라면 이것이다.** - [ ] **R 쪽 질문을 한 번 던진다.** 지난 사흘 우리 대화는 전부 I(소진·effort·시트)였다. 다른 데스크 담당자들이 각자 자기 병목에 에이전트를 붙여본 적이 있나. 없다면 그게 레버다. - [ ] **"오늘의 병목" 한 문장을 스탠드업 상단에 고정.** 8x를 만든 방법이 그것뿐이었다. - [ ] **evals와 vibes의 경계를 의식적으로 긋는다.** 지금 우리는 전부에 red-green을 요구한다. 임상 경로는 그대로 두되, 어디까지가 vibes 허용인지 한 번은 명시할 것. - [ ] 8x·150% 같은 수치는 **대외 인용 금지.** 자기보고이며 외부 감사가 없다. 방법만 가져온다. ## 연결 - [[260803_Erik Brynjolfsson — The Best and Worst Decade]] — 능력이 아니라 프로세스 재설계가 병목이라는 같은 논지. 저쪽은 경제학, 이쪽은 현장 운영 - [[260801_Sam Altman - AGI, Compute, and Human Agency]] — 워크플로·통합이 해자라는 결론과 겹침 - [[6.4 Access Control]] — 오늘 아침 노트의 "AI를 위임 주체로 모델링" 논지가 §8 승인 피로와 같은 문제의 두 얼굴이다. 누가 승인했는지 기록이 남지 않으면 게이트는 사후에 검증 불가 ## 반직관 하나 **게이트를 늘리면 안전해지는 게 아니라, 어느 지점부터는 덜 안전해진다.** 사람이 읽기를 멈추는 순간부터 게이트는 책임을 사람에게 옮겨놓기만 하고 아무것도 막지 않는다. Anthropic은 그 사실을 자기 CTO가 bash 명령을 안 읽고 yes를 누르는 걸 스스로 알아차리면서 발견했다. **우리 게이트가 진짜인지 아닌지는, 대표가 마지막으로 "아니오"라고 답한 게 언제인지로 알 수 있다.**