kalee's 공부방

오케스트레이터-워커 구조를 데모가 아니라 매일 도는 루프로 굴리기 위한 다섯 가지 규칙을 다룹니다. 비싼 모델을 어디에 둘지(트리형과 조언자형), 노력 예산과 종료 조건, 생성자와 분리된 평가자와 동적 재계획, 파일과 git에 두는 상태, 거부 횟수 기반 사람 호출을 앤트로픽 엔지니어링 글과 논문, Cognition의 반론으로 살펴봅니다. 수치 상당수는 앤트로픽 자사 평가임을 밝혀 둡니다.

Show Notes

오케스트레이터-워커 구조를 데모가 아니라 매일 도는 루프로 굴리기 위한 다섯 가지 규칙을 다룹니다. 비싼 모델을 어디에 둘지(트리형과 조언자형), 노력 예산과 종료 조건, 생성자와 분리된 평가자와 동적 재계획, 파일과 git에 두는 상태, 거부 횟수 기반 사람 호출을 앤트로픽 엔지니어링 글과 논문, Cognition의 반론으로 살펴봅니다. 수치 상당수는 앤트로픽 자사 평가임을 밝혀 둡니다.

전체 대본 보기

참고 자료

이 에피소드의 음성은 TTS로 합성되었습니다.

What is kalee's 공부방?

kalee 가 공부하고자 하는 내용들을 두서없이 업로드하는 팟캐스트

진행자: 안녕하세요. 오늘부터 두 편에 걸쳐 오케스트레이터-워커 구조를 다뤄 볼게요. 1편 주제는 이걸 데모가 아니라 매일 도는 루프로 굴리려면 어떤 규칙이 필요한가예요.

전문가: 네. 오케스트레이터가 일을 쪼개서 워커들에게 맡기는 구조는 그림으로 그리면 간단해요. 그런데 매일 돌리기 시작하면 질문이 바뀌어요. 비싼 모델을 어디에 둘지, 언제 멈출지, 누가 결과를 검증할지, 상태를 어디에 적을지, 그리고 언제 사람을 부를지요.

진행자: 오늘은 그 다섯 가지를 규칙 하나씩으로 정리해 보는 거네요. 모델 배치, 노력 예산, 검증, 상태, 사람 호출.

전문가: 맞아요. 그리고 규칙마다 반대편 얘기도 같이 볼 거예요. Cognition이라는 회사가 쓴 Don't Build Multi-Agents, 멀티 에이전트를 만들지 말라는 글인데, 각 규칙을 이 글의 주장에 비춰 보면 어디까지가 안전한지 선이 보여요.

진행자: 자료는 어떤 걸 보셨어요?

전문가: 앤트로픽 엔지니어링 블로그 글 여러 편이 중심이에요. 멀티 에이전트 리서치 시스템 글, advisor strategy 글, Claude Code auto mode 글, 장기 실행 에이전트 하네스 글 두 편, 그리고 에이전트 자율성을 측정한 연구 글이요. 여기에 arXiv 논문 두 편과 Cognition 글을 더했어요.

전문가: 미리 밝혀 둘 게 있어요. 오늘 나오는 핵심 수치 상당수는 앤트로픽이 자사 제품과 자사 평가로 낸 숫자예요. 독립적으로 재현된 결과가 아니라는 점을 감안하고 들어 주세요.

진행자: 좋아요. 그리고 지난 그래프 워크플로우 회차에서 다룬 토큰 사용량 얘기는 오늘 다시 하지 않을게요.

진행자: 본론 전에 용어부터 맞춰요. 오케스트레이터-워커는 정확히 어떤 구조예요?

전문가: 앤트로픽 리서치 시스템을 예로 들면, 리드 에이전트가 사용자 질문을 받아 전략을 세우고 하위 작업으로 쪼개요. 그걸 서브에이전트 여러 개에게 맡기면 서브에이전트들이 병렬로 검색해서 결과를 리드에게 돌려줘요.

진행자: 리드가 오케스트레이터, 서브에이전트가 워커인 거죠.

전문가: 네. 오늘은 이 서브에이전트를 트리의 잎이라는 뜻으로 리프라고도 부를게요.

진행자: 중간에 MAST라는 말도 나올 텐데, 이건 뭐의 약자예요?

전문가: Multi-Agent System Failure Taxonomy, 멀티 에이전트 시스템 실패 분류예요. Cemri 외 연구진의 논문이 만든 분류 체계예요. 실행 기록 1,600개 이상을 주석해서 실패를 14가지 유형, 3개 범주로 나눴어요.

전문가: 다만 이 분류 자체는 2편에서 자세히 다루고, 오늘은 숫자 두 개만 빌려 올게요.

진행자: LLM 판정자라는 말도 자주 나오죠?

전문가: LLM-as-judge라고도 해요. 다른 LLM이 결과물을 기준표에 따라 채점하게 하는 방식이에요.

진행자: 그럼 첫 번째 규칙, 모델 배치부터 가 볼게요. 비싼 모델을 어디에 둬야 해요?

전문가: 흔히 보는 답은 두 가지예요. 하나는 트리형이에요. 위에 비싼 모델을 두고 아래 리프에 싼 모델을 두는 거죠. 앤트로픽 리서치 시스템이 이 모양이에요.

전문가: 그 글에 따르면 리드에 Claude Opus 4, 서브에이전트에 Claude Sonnet 4를 둔 구성이 Opus 4 단일 에이전트보다 내부 리서치 평가에서 90.2% 더 좋은 성적을 냈어요.

진행자: 90%면 꽤 큰 차이네요.

전문가: 네. 다만 앤트로픽 내부 평가라는 점, 그리고 리서치처럼 병렬로 나눠 찾기 좋은 작업이었다는 점을 같이 봐야 해요.

전문가: 같은 글이 스스로 선을 그어요. 모든 에이전트가 같은 문맥을 공유해야 하거나 에이전트 사이 의존이 많은 영역은 아직 멀티 에이전트에 맞지 않는다고요. 대부분의 코딩 작업은 리서치보다 진짜로 병렬화할 수 있는 부분이 적다고 예를 들어요.

진행자: 두 번째 방식은요?

전문가: 조언자형이에요. 앤트로픽이 advisor strategy라고 부르는 건데, 방향이 반대예요. 싼 모델이 실행자로 처음부터 끝까지 일을 돌리고, 혼자 풀기 어려운 결정 지점에서만 비싼 모델에게 물어봐요.

전문가: 구체적으로는 Sonnet이나 Haiku가 실행하고 Opus가 조언해요. Opus는 계획이나 수정, 또는 멈추라는 신호를 돌려줘요. 조언자는 도구를 부르지 않고, 사용자에게 보이는 출력도 만들지 않아요.

진행자: 언제 조언을 구할지는 누가 정해요?

전문가: 실행자가 정해요. 그리고 요청당 조언 호출 횟수에 max_uses로 상한을 걸 수 있어요. 글의 예시는 3이었어요.

진행자: 성적은 어땠어요?

전문가: SWE-bench Multilingual에서 Sonnet에 Opus 조언자를 붙이니 Sonnet 단독보다 2.7%p 높았고, 작업당 비용은 11.9% 줄었다고 해요.

전문가: BrowseComp에서는 Haiku에 Opus 조언자를 붙여 41.2%가 나왔는데, Haiku 단독 19.7%의 두 배가 넘어요.

진행자: 85% 저렴하다는 얘기도 돌던데요.

전문가: 그 문장이 조심해서 읽어야 하는 부분이에요. 원문은 Haiku에 Opus 조언자를 붙인 구성이 Sonnet 단독보다 점수는 29% 뒤지지만 작업당 비용은 85% 적다고 써요. 그런데 29%가 상대값인지 퍼센트포인트인지는 밝히지 않았어요.

전문가: 85%의 비교 대상도 문맥상 Sonnet 단독으로 읽히지만 문장에 못 박혀 있지는 않아요. 그래서 이 숫자는 Haiku가 싸다는 얘기 이상으로 쓰지 않는 게 안전해요.

전문가: 조건도 있어요. 실행 설정이 똑같지 않았어요. 예를 들어 SWE-bench에서 Sonnet 단독은 adaptive thinking을 켰고 조언자 실행은 껐어요. 앤트로픽도 자기 평가 세트로 Sonnet 단독, Sonnet에 Opus 조언자, Opus 단독을 직접 비교해 보라고 권해요.

진행자: 결국 트리형과 조언자형 중에 뭘 골라야 해요?

전문가: 기준은 리프가 무슨 일을 하느냐예요. 리프가 좁고 잘 정의된 질문에 답하는 일이면 트리형이 잘 맞아요. Cognition도 이 경우는 인정해요. 코드를 쓰지 않고 좁은 질문에 답하는 서브에이전트, Claude Code의 서브에이전트 같은 경우요.

진행자: 그럼 싼 리프를 쓰면 안 되는 조건은요?

전문가: 리프가 서로 얽힌 결정을 내려야 할 때예요. 이게 Cognition 글의 핵심 주장이에요. 행동에는 암묵적 결정이 담겨 있고, 서로 다른 가정 위에서 움직인 서브에이전트의 결과는 충돌한다는 거죠.

전문가: 플래피 버드 예시가 유명해요. 플래피 버드 클론을 만들라는 일을 배경과 새로 나눠 맡겼더니, 한쪽은 슈퍼 마리오 풍 배경을 만들고, 다른 쪽은 게임과 어울리지 않는 새를 만들었어요. 마지막 에이전트는 맞지 않는 두 조각을 합쳐야 했고요.

진행자: 싼 모델이라서 생긴 문제라기보다 결정이 흩어져서 생긴 문제네요.

전문가: 그렇죠. 그래서 제 정리는 이래요. 리프에 판단을 맡기는 순간 싼 모델이 위험해져요. 리프가 판단해야 하는 일이면 조언자형으로 실행자 하나가 흐름을 쥐고, 어려운 결정만 비싼 모델에게 묻는 편이 결정이 덜 흩어져요.

전문가: 다만 조언자형에도 약점이 있어요. 언제 물을지를 실행자가 정하니까, 실행자가 자기가 막혔다는 걸 모르면 조언자가 불리지 않아요. 이건 원문이 측정한 게 아니라 구조에서 나오는 제 추론이에요.

전문가: 그리고 리프에 싼 모델을 쓰는 효과만 따로 떼어 잰 독립 연구는 이번에 찾지 못했어요. 그러니 이 규칙은 정답이라기보다 내 작업으로 직접 재 보라는 출발점이에요.

진행자: 트리형으로 갈 때 리프에게 일을 넘기는 방식도 중요하겠네요.

전문가: 네. 앤트로픽 글은 서브에이전트에게 넘기는 지시에 목표, 출력 형식, 쓸 도구와 출처에 대한 안내, 명확한 작업 경계가 있어야 한다고 해요.

전문가: 처음엔 반도체 부족을 조사해 같은 짧은 지시로 시작했는데, 서브에이전트들이 일을 잘못 해석하거나 똑같은 검색을 중복했대요.

진행자: Cognition 쪽에서 보면 그것도 결국 문맥을 덜 넘겨서 생긴 일이겠네요.

전문가: 그렇게 읽을 수 있어요. Cognition은 메시지 하나가 아니라 에이전트의 전체 궤적, trace를 공유하라고 해요. 앤트로픽은 대신 지시를 구조화해서 보완한 거고요.

진행자: 두 번째 규칙, 노력 예산으로 넘어가 볼게요. 언제 멈추느냐의 문제죠.

전문가: 앤트로픽 글에 초기 실패 사례가 솔직하게 나와요. 간단한 질문에 서브에이전트를 50개 띄우고, 존재하지 않는 출처를 끝없이 찾고, 과도한 업데이트로 서로를 방해했대요.

진행자: 50개요? 질문 하나에?

전문가: 네. 에이전트는 작업에 맞는 노력 수준을 스스로 판단하는 걸 어려워해요. 그래서 규모 규칙을 프롬프트에 직접 넣었어요.

전문가: 단순 사실 확인은 에이전트 하나에 도구 호출 3회에서 10회, 직접 비교는 서브에이전트 2개에서 4개에 각각 10회에서 15회, 복잡한 리서치는 서브에이전트 10개 이상에 책임을 나눠 맡기는 식이에요.

진행자: 숫자로 박아 두는 거네요.

전문가: 네. 그리고 리드는 extended thinking, 확장 사고로 계획을 세우면서 질문 복잡도와 서브에이전트 수, 각자의 역할을 먼저 정해요.

진행자: 이걸 안 하면 어떻게 돼요?

전문가: 여기서 MAST 숫자 하나를 빌려 올게요. 종료 조건을 인식하지 못하는 실패, 그러니까 멈춰야 할 기준을 몰라서 불필요하게 계속 도는 실패가 1,642개 실행 기록에서 관찰된 실패 분포의 12.4%를 차지했어요.

전문가: 그리고 논문은 이 유형이 거의 실패한 실행에서만 나타나는 치명적인 유형이라고 봤어요.

진행자: 멈추는 기준이 없으면 그냥 실패로 이어진다는 얘기네요.

전문가: 네. 그래서 운영 규칙으로 바꾸면 이래요. 작업 유형별로 에이전트 수와 호출 횟수의 상한을 프롬프트에 적고, 상한에 닿으면 멈추고 보고하게 해요. 앞에서 본 조언자 호출의 max_uses도 같은 종류의 예산이에요.

진행자: Cognition 쪽 반론은 여기선 뭐예요?

전문가: 에이전트를 더 띄울수록 결정이 더 흩어진다는 거죠. 노력 예산을 늘리는 게 서브에이전트 수를 늘리는 방향이면, 충돌할 조각도 같이 늘어나요. 그래서 예산은 위로 열어 두기보다 아래로 시작해서 필요할 때만 올리는 편이 안전해요.

진행자: 세 번째, 검증이요. 누가 검증해야 해요?

전문가: MAST에서 두 번째이자 마지막 숫자를 가져올게요. ChatDev라는 멀티 에이전트 시스템에 상위 수준의 작업 목표를 검증하는 단계를 넣었더니 ProgramDev 과제에서 작업 성공률이 15.6% 올랐어요.

진행자: 검증 단계 하나로요.

전문가: 네. 그런데 같은 논문이 바로 경고도 해요. 검증자가 있다고 만능은 아니라고요. ChatDev가 만든 체스 프로그램이 컴파일 같은 겉보기 검사는 통과했는데 실행 중 버그가 있었던 예를 들어요.

진행자: 검증을 누가, 얼마나 깊게 하느냐가 문제군요.

전문가: 그 지점을 앤트로픽의 장기 실행 앱 하네스 글이 잘 보여 줘요. 생성한 에이전트에게 자기 작업을 평가하게 하면, 사람이 보기엔 뻔히 평범한 결과도 자신 있게 칭찬하는 경향이 있대요.

전문가: 그래서 생성자와 평가자를 나눴는데, 평가자도 기본 상태로는 서툴렀어요. 저자 표현으로는 진짜 문제를 찾아 놓고도 큰일 아니라고 스스로 설득해서 승인해 버렸대요. 테스트도 피상적이었고요.

진행자: 평가자도 같은 모델이니까요.

전문가: 네. 그런데 중요한 발견이 있어요. 별도 평가자를 회의적으로 튜닝하는 편이 생성자가 자기 작업에 비판적이 되게 만드는 것보다 훨씬 다루기 쉬웠대요.

진행자: 튜닝은 어떻게 했어요?

전문가: 평가자 로그를 읽고 사람 판단과 갈린 지점을 찾아서 프롬프트를 여러 차례 고쳤어요. 디자인 채점에는 점수 근거가 달린 few-shot 예시로 보정했고요. 평가자는 Playwright로 실제로 돌아가는 앱을 브라우저에서 눌러 봤어요.

전문가: 스프린트 계약이라는 장치도 있었어요. 각 스프린트 전에 생성자가 뭘 만들고 성공을 어떻게 검증할지 제안하면, 평가자가 검토해서 합의할 때까지 조정했어요.

진행자: 비용은 많이 들었겠는데요.

전문가: 글의 레트로 게임 메이커 예시에서 단독 실행은 20분에 9달러, 전체 하네스는 6시간에 200달러였어요. 20배 넘게 비쌌지만 결과물 품질 차이가 바로 보였다고 저자는 썼어요.

진행자: 검증을 사람이 아니라 다른 에이전트가 하는 것도 결국 기준이 필요하겠네요.

전문가: 그래서 리서치 시스템 쪽은 LLM 판정자에게 기준표를 줬어요. 사실 정확도, 인용 정확도, 완결성, 출처 품질, 도구 효율을 보고 한 번의 호출로 0.0에서 1.0 사이 점수와 통과 여부를 내게 했어요.

전문가: 그래도 사람 테스터가 필요했대요. 초기 에이전트가 학술 PDF 같은 권위 있는 출처보다 SEO 최적화 콘텐츠 농장을 고르는 편향을 사람이 찾아냈어요.

진행자: SEO는 검색 엔진 최적화죠.

전문가: 네. 그리고 상태를 바꾸는 에이전트는 과정 하나하나를 채점하기보다 최종 상태가 맞는지를 평가하는 편이 잘 통했다고 해요. 에이전트가 다른 길로 같은 목표에 갈 수 있으니까요.

진행자: 검증에서 실패가 나오면 그다음은요? 계획을 다시 짜야 할 텐데요.

전문가: 그게 동적 재계획이에요. Plan-and-Act 논문은 플래너와 실행기를 나눠요. 플래너가 고수준 계획을 만들고 실행기가 그걸 실제 행동으로 옮겨요.

전문가: 정적 계획은 검색 결과가 비거나 예상 못 한 내용이 나오면 대응을 못 해요. 그래서 실행기가 한 단계를 끝낼 때마다 플래너가 현재 상태와 이전 계획, 행동을 보고 계획을 고쳐요.

전문가: 웹 탐색 벤치마크인 WebArena-Lite에서 동적 재계획을 더하자 정적 플래너의 43.63%보다 10.31%p 올라 53.94%가 됐어요.

진행자: 매 단계마다 다시 계획하면 느리지 않아요?

전문가: 저자들도 그 한계를 인정해요. 매 행동마다 재계획하면 비효율적일 수 있어서, 실행기가 재계획 시점을 스스로 정하는 방식을 향후 과제로 남겼어요.

진행자: Cognition 관점에선 검증은 어떻게 보여요?

전문가: 평가자도 생성자가 왜 그렇게 했는지를 모르면 엉뚱하게 판정할 수 있다는 게 같은 논리로 나와요. 앤트로픽 하네스가 스프린트 계약으로 무엇을 어떻게 검증할지를 미리 합의한 것도 그 문맥을 평가자에게 넘기는 방법으로 볼 수 있어요.

진행자: 네 번째, 상태요. 루프가 길어지면 어디에 기록을 남겨야 해요?

전문가: 규칙은 간단해요. 상태는 문맥 창이 아니라 파일과 git에 둬요.

전문가: 리서치 시스템의 리드 에이전트는 계획을 메모리에 저장해요. 문맥 창이 20만 토큰을 넘으면 잘리기 때문에 계획을 보존하려는 거예요.

전문가: 서브에이전트는 결과를 외부 시스템에 저장하고, 코디네이터에게는 가벼운 참조만 돌려줘요. 여러 단계를 거치면서 정보가 손실되는 걸 막고, 큰 출력을 대화 기록으로 그대로 복사하는 부담도 줄여요.

진행자: 참조만 넘긴다는 게 핵심이네요.

전문가: 네. 장기 실행 에이전트 하네스 글은 이걸 더 구체적으로 보여 줘요. 첫 세션의 초기화 에이전트가 init.sh 스크립트, 지금까지 한 일을 적는 claude-progress.txt 파일, 그리고 첫 git 커밋을 만들어요.

전문가: 그다음 세션부터 코딩 에이전트는 조금씩 진행하고 구조화된 기록을 남겨요. 매 세션은 이전 세션의 기억 없이 시작하니까 파일이 곧 기억이에요.

진행자: 기능 목록도 파일로 둔다고 하던데요.

전문가: 네. claude.ai 클론 예시에서는 200개가 넘는 기능을 JSON 파일에 적고 처음엔 전부 실패로 표시해 뒀어요. 코딩 에이전트는 각 기능의 통과 여부 필드만 바꿀 수 있어요.

진행자: 왜 마크다운이 아니라 JSON이에요?

전문가: 모델이 마크다운보다 JSON 파일을 덜 함부로 고치거나 덮어쓰더래요. 실험해 보고 정한 거예요.

전문가: 그리고 한 번에 기능 하나만 작업하게 했어요. 한꺼번에 너무 많이 하려는 경향을 잡는 데 결정적이었대요. git 커밋과 진행 기록 덕분에 잘못된 변경을 되돌리고 작동하던 상태로 돌아갈 수 있었고요.

진행자: 이게 앞에서 말한 종료 조건과도 이어지겠네요.

전문가: 맞아요. 이 글에 나온 실패 하나가 나중 세션이 진행된 흔적을 보고는 일이 다 끝났다고 선언해 버리는 거였어요. 처음부터 기능 목록을 만들어 두는 걸로 해결했어요. 파일에 적힌 목록이 곧 종료 조건이 된 거죠.

전문가: 세션 시작 루틴도 있어요. git 로그와 진행 파일을 읽고, 기능 목록에서 우선순위 높은 미완료 기능을 고르고, init.sh로 개발 서버를 띄워서 기본 종단 간 테스트로 이전 세션이 남긴 버그부터 잡아요.

진행자: 에이전트끼리 주고받는 것도 파일로 해요?

전문가: 앱 하네스 글에서는 그랬어요. 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고 같은 파일이나 새 파일에 답했어요.

진행자: 여기서 Cognition 반론은요?

전문가: 참조만 넘기면 결과는 전달되지만 그 결과에 이른 결정의 이유는 빠질 수 있다는 거죠. Cognition이 메시지 말고 전체 궤적을 공유하라고 하는 이유가 그거예요. 그래서 진행 기록에 무엇을 했는지만이 아니라 왜 그렇게 정했는지도 남기는 편이 이 반론을 덜 받아요.

전문가: 참고로 장기 실행 하네스 글도 단일 범용 코딩 에이전트가 최선인지, 테스트나 QA 에이전트를 따로 둔 멀티 에이전트가 나은지는 열린 질문으로 남겨 뒀어요.

진행자: 마지막 다섯 번째, 사람 호출이에요. 언제 사람을 불러야 해요?

전문가: 먼저 반대쪽 문제부터요. Claude Code 사용자는 수동 권한 확인 요청의 93%를 승인한대요.

진행자: 거의 다 누르는 거네요.

전문가: 네. 앤트로픽은 이걸 승인 피로라고 불러요. 그래서 auto mode에서는 승인 판단 일부를 모델 기반 분류기에 맡겼어요.

전문가: 분류기는 두 단계예요. 1단계는 빠른 예 아니오 필터인데 차단 쪽으로 기울게 했고, 걸린 행동만 2단계에서 단계별 추론으로 다시 봐요.

전문가: 재밌는 설계가 하나 있어요. 분류기는 사용자 메시지와 에이전트의 도구 호출만 보고, 에이전트가 쓴 글과 도구 출력은 빼요. 에이전트가 분류기를 말로 설득하지 못하게 하려는 거예요.

진행자: 평가자가 스스로 설득당하는 문제와 같은 맥락이네요.

전문가: 그렇죠. 그리고 오늘 주제의 핵심 규칙이 여기 있어요. 거부 횟수 기반 에스컬레이션이에요. 한 세션에서 연속 3번, 또는 누적 20번 거부되면 모델을 멈추고 사람에게 넘겨요.

전문가: 사람이 없는 헤드리스 모드, claude -p로 돌릴 때는 물어볼 화면이 없으니 프로세스를 종료해요.

진행자: 왜 횟수로 끊어요?

전문가: 두 가지 이유를 들어요. 하나는 손상됐거나 과하게 의욕적인 에이전트가 사용자가 원치 않는 결과를 계속 밀어붙이는 걸 막는 안전장치예요. 다른 하나는 오탐을 견딜 만하게 만든다는 거예요. 오탐 하나로 세션이 죽지 않고, 계속 막힐 때만 사람이 끼어드니까요.

진행자: 분류기 정확도는 어느 정도예요?

전문가: 실제 내부 트래픽 1만 건에서 전체 파이프라인의 오탐률은 0.4%였어요. 반면 실제 과잉 행동 사례 52건에서 놓친 비율은 17%였고, 저자들은 이걸 정직한 수치라고 불렀어요. 표본이 52건으로 작다는 점도 같이 봐야 해요.

전문가: 놓친 경우는 대개 분류기가 위험은 알아봤는데, 앞에서 사용자가 한 모호한 말을 그 행동 전체에 대한 동의로 잘못 읽은 경우였대요. 예를 들어 PR 정리해 줘라는 말이 force push까지 허락한 건 아닌데요.

전문가: 그래서 글도 auto mode가 중요한 인프라에서 신중한 사람 검토를 대체하지 않는다고 직접 써요.

진행자: 사람 쪽 행동은 실제로 어때요?

전문가: 에이전트 자율성을 측정한 앤트로픽 연구가 있어요. 자사 제품인 Claude Code와 공개 API 사용 데이터예요. 신규 사용자는 세션의 약 20%에서 전체 자동 승인을 쓰는데, 경험이 쌓이면 40%를 넘어요.

전문가: 그런데 중단은 오히려 늘어요. 약 10세션 사용자는 턴의 5%에서 끊는데, 경험 많은 사용자는 약 9%에서 끊어요.

진행자: 덜 묻는데 더 끊는다, 재밌네요.

전문가: 저자들은 단계마다 승인하던 방식에서 결과를 지켜보다가 필요할 때 개입하는 방식으로 바뀐 걸로 해석해요. 그리고 가장 복잡한 작업에서는 Claude Code가 스스로 멈춰서 확인을 요청하는 빈도가 사람이 끊는 빈도의 두 배를 넘었대요.

전문가: 결론 삼아 이런 말도 해요. 모든 행동에 사람 승인을 요구하는 건 안전 이익 없이 마찰만 늘릴 수 있고, 중요한 건 사람이 실제로 지켜보고 개입할 수 있는 자리에 있느냐라고요.

진행자: 그럼 운영 규칙으로는 어떻게 정리돼요?

전문가: 모든 행동에 묻지 말고, 거부가 쌓이면 부르는 거예요. 연속 몇 번, 누적 몇 번처럼 숫자로 정해 두고, 사람이 없는 무인 실행이면 멈추고 기록을 남기는 쪽으로요. 그리고 에이전트가 스스로 멈춰서 묻는 경로도 열어 둬요.

진행자: 여기에도 Cognition 반론을 붙인다면요?

전문가: 사람도 결국 궤적이 있어야 판단할 수 있다는 거예요. 거부가 20번 쌓여서 불려 온 사람이 왜 그렇게 됐는지 볼 기록이 없으면 그냥 다시 승인을 누르게 돼요. 그래서 다섯 번째 규칙은 네 번째 규칙, 상태를 파일에 남기는 것과 같이 가야 해요.

진행자: 정리해 볼게요. 첫째, 모델 배치. 리프가 좁고 잘 정의된 질문에 답할 때만 싼 모델을 리프에 두고, 리프가 판단해야 하면 실행자 하나가 흐름을 쥐고 어려운 결정만 비싼 모델에게 묻는 조언자형이 결정을 덜 흩어요.

진행자: 둘째, 노력 예산은 프롬프트에 숫자로 박고 종료 조건을 명시해요. 셋째, 검증은 생성자와 분리된 회의적인 평가자에게 맡기고, 실패하면 다시 계획해요.

진행자: 넷째, 상태는 파일과 git에 두고 참조만 넘겨요. 다섯째, 매번 묻지 말고 거부가 쌓이면 사람을 불러요.

전문가: 하나만 덧붙이면, 앱 하네스 글의 말이 오늘 규칙 전체에 적용돼요. 하네스의 모든 구성 요소는 모델이 혼자 못 하는 것에 대한 가정이고, 새 모델이 나오면 더 이상 필요 없는 부분은 걷어내라는 거예요. 실제로 그 글은 다음 모델에서 스프린트 구조를 없애고 평가자를 마지막 한 번으로 줄였어요.

전문가: 그리고 다시 말씀드리지만 오늘 수치 상당수는 앤트로픽 자사 평가예요. 내 루프에서 직접 재 보는 게 먼저예요.

진행자: 다음 2편에서는 반대 방향에서 봐요. 멀티에이전트는 왜 실패하나. 오늘 숫자 두 개만 빌려 온 MAST 실패 분류를 제대로 펼쳐 볼게요.

전문가: 오늘 규칙들이 왜 필요한지가 실패 쪽에서 보면 더 선명해질 거예요.

진행자: 오늘 참고한 자료는 모두 설명란에 링크해 뒀어요. 들어 주셔서 고마워요.

전문가: 고맙습니다.