9월 16일 수요일
에이전트의 성능은 모델 이름 하나가 아니라 탐색 가능한 작업 공간, 삭제 가능한 하네스, 업무별 평가와 실패를 가두는 실행 경계의 조합에서 결정된다.
좋은 하네스는 모델을 통제하는 코드가 아니라 바뀌어도 남는 경계다
거대한 프롬프트와 도구 체인을 줄인 뒤에도 무엇을 직접 소유해야 하는지, 세 구현 사례를 하나의 설계 원칙으로 묶어 본다.

모델이 강해질수록 에이전트 하네스에서는 무엇을 지우고 무엇을 더 단단하게 남겨야 하는가?
세 사례가 가리키는 방향은 ‘오케스트레이션을 없앤다’가 아니라 제어의 위치를 바꾸는 일이다. Vercel의 데이터 에이전트는 스키마를 넣은 거대한 프롬프트에서 역할별 다중 에이전트, 상태를 공유하는 단일 에이전트를 거쳐 파일시스템과 스킬을 탐색하는 구조로 이동했다. 파일 기반 에이전트 사례도 직접 작성한 Python 루프를 공통 프레임워크에 넘긴 뒤, 격리된 원격 샌드박스와 범용 도구를 제공하는 단계까지 제어 코드를 줄인다. Codex의 설계 원칙은 이 축소를 모델과 하네스의 공동 설계로 설명한다. 모델이 곧 흡수할 행동을 임시 규칙으로 과도하게 고정하지 않되, 권한·실행 환경·도구 계약·관찰 가능성·평가는 모델이 좋아져도 시스템이 계속 소유해야 한다. 따라서 하네스의 품질은 코드 줄 수나 도구 수가 아니라, 모델이 자율적으로 탐색할 공간과 실패가 밖으로 번지지 않을 경계를 동시에 제공하는지로 판단해야 한다.
- 01
처방적 체인에서 탐색 가능한 작업 공간으로
Vercel의 DZero는 처음에 질의·계획·SQL·보고 에이전트를 잇고 각 역할의 도구를 제한했다. 그러나 단계 사이에는 요약만 전달돼 실패 경로를 되짚기 어려웠고, 최대 100단계의 단일 에이전트로 합친 뒤에도 제작자가 약 30%를 맞힌다고 본 평가와 실제 사용자의 낮은 체감 품질 사이에 간극이 남았다. 전환점은 파일 읽기·쓰기와 Bash를 중심으로 한 샌드박스였다. 모델이 의미 계층을 직접 탐색하고 중간 결과를 파일에 남기자 평가 점수가 사실상 두 배가 됐다. 핵심은 전문 도구를 무한히 추가하는 대신 모델이 이미 익숙한 작은 인터페이스 위에 회사 고유 지식만 얇게 올리는 것이다.
- 02
루프는 런타임으로, 비밀과 권한은 환경으로
파일 중심 에이전트의 다른 구현 경로는 도구 호출·상태·재시도·오류 처리를 애플리케이션 코드에서 관리형 런타임으로 옮긴다. 개발자는 AGENTS.md와 SKILL.md에 도메인 규칙과 절차를 두고, 에이전트에는 Bash·파일시스템·검색 같은 원자적 능력을 제공한다. 원격 실행에서는 샌드박스가 코드를 격리하고 네트워크 프록시가 요청 시점에 자격 증명을 주입해 모델이 실제 토큰을 보지 않게 한다. 허용 도메인으로 네트워크 범위를 제한하면 자율성과 보안 경계를 분리할 수 있다. 코드가 줄어도 비밀 관리와 접근 통제가 사라지는 것이 아니라 더 낮은 환경 계층으로 이동한다.
- 03
곧 사라질 목발과 오래 남을 기반을 구분하기
Codex 사례에서 하네스는 현재 모델이 놓치는 테스트나 안전 행동을 개발자 메시지와 실행 규칙으로 보완하는 ‘목발’이다. 모델 훈련이 그 행동을 흡수하면 지시문과 강제 규칙을 제거할 수 있으므로, 가까운 모델 개선이 해결할 문제에 큰 우회 구조를 쌓지 않는 판단이 필요하다. 반면 로컬 샌드박스의 권한 요청, 관리형 VM의 격리, 도구와 프로토콜, 자원·데이터 접근 계약은 모델 능력과 별개인 시스템 책임이다. 하네스를 작게 만드는 목표는 이런 기반까지 없애는 것이 아니라, 일시적 행동 보정과 지속적 실행 경계를 구별해 전자의 유지비만 줄이는 데 있다.
- 04
프로덕션의 차별점은 회사 지식과 검증 루프
범용 모델과 공통 런타임은 누구나 살 수 있지만, 어떤 데이터를 언제 조회하고 무엇과 연결할지에 관한 조직의 의미 계층은 기성 에이전트가 대신 만들 수 없다. Vercel은 실제 질의에서 반복 패턴을 추출해 약 100개의 스킬로 축적했고, Eve에 내구성·격리 실행·모델 교체·커넥션·도구 호출 추적과 비용 관찰을 결합했다. 파일 기반 구현도 개발자가 소유할 대상을 도메인 규칙, 워크플로, 원자적 도구와 평가로 좁힌다. Codex의 코드 리뷰 사례까지 연결하면 기계적 정확성과 보안 검사는 자동화하되, 사람은 의도·데이터 접근·자원 한도·불변조건을 먼저 합의해야 한다. 에이전트 아키텍처의 핵심 자산은 복잡한 라우터가 아니라 검토 가능한 지식과 반복 가능한 평가다.
설계 기준은 ‘더 많은 도구’도 ‘무조건 코드 삭제’도 아니다. 먼저 파일과 범용 도구로 모델이 스스로 탐색할 수 있게 하고, 반복 성공은 스킬과 의미 계층으로 외부화한다. 다음으로 상태·재시도·격리·비밀 주입은 공통 런타임과 환경에 맡긴다. 마지막으로 회사는 권한 계약, 도메인 지식, 평가, 관찰 가능성과 인간 승인 지점을 직접 소유한다. 새 모델이 나왔을 때 행동 보정 코드는 지울 수 있어야 하지만, 실패를 감지하고 피해를 제한하는 경계는 더 명시적이어야 한다. 하네스가 단순해질수록 무엇을 믿고 무엇을 검증하는지가 코드 밖에서 읽혀야 한다.
점수 하나를 버리면 보이는 네 가지 운영 신호
모델의 원시 성능과 코드 탐색 하네스의 효율을 같은 숫자로 섞지 않고, 완료 시간·도구 호출·가드레일·정직성을 따로 측정한다.
에이전트 성능을 한 점수로 합치지 않고 어떤 운영 신호로 나눠 읽어야 하는가?
- 1
탐색 하네스
Graft는 같은 에이전트와 작업을 차가운 검색 방식과 그래프 우선 방식으로 162회 비교했다. 평균 작업 시간 60%, 도구 호출 46%, 토큰 42%, 비용 32% 감소가 보고됐다. 모델을 교체하지 않고 탐색 왕복과 컨텍스트 팽창을 줄였다는 점을 따로 본다.
- 2
실행형 과제
Terminal-Bench v4.0은 60개가 넘는 과제에서 에이전트가 준비된 컨테이너의 명령을 실행하고 마지막 상태를 검증기로 판정한다. 약 40~42% 구간의 성능 절벽은 종합 평균이 숨기는 모델 계층의 분산을 보여 준다.
- 3
업무 가드레일
AutomationBench는 600개가 넘는 과제로 금융·인사·마케팅·운영·영업·지원의 여섯 도메인을 평가한다. 목표를 달성해도 요청하지 않은 상태 변경이나 가드레일 위반이 있으면 결과를 다르게 보므로 완료율과 부작용 회피를 분리할 수 있다.
- 4
정직한 중단
AA-Omniscience는 정답, 오답, 부분 답변, 시도하지 않음의 네 상태를 구분하고 모른다고 멈추는 선택에는 점수 변화를 주지 않는다. 장기 체인에서는 앞단의 환각이 다음 단계 입력을 오염시키므로 신뢰 가능한 중단을 별도 성공 조건으로 둬야 한다.
이 수치들은 하나의 순위표로 합치지 않는다. Graft 결과는 도구 팀의 공개 벤치마크이고 작은 프로젝트에서는 제거할 검색 자체가 적다. 공개 모델 벤치마크도 비용·속도·가드레일과 포함 모델이 다르다. 실제 채택 전에는 팀의 저장소 규모와 대표 업무, 실패 비용을 반영해 같은 모델의 기본 하네스와 개선 하네스를 비교하고 성능·비용·속도·정직성을 따로 기록해야 한다.
이번 주 구현 결정을 흔드는 세 신호
장시간 컴퓨터 사용, 모바일 스택의 비용 변화, AI 산출물의 품질 규칙을 독립된 설계 질문으로 남긴다.
- 01
a16z24시간 실행은 능력 선언보다 운영 경계의 시험이다
Astra가 컴퓨터 사용으로 최대 24시간 장기 작업을 수행했다는 사례는 에이전트 평가 단위를 한 번의 답변에서 지속 실행으로 옮긴다. 동시에 안전·보안·정렬을 배포 직전 필터가 아니라 학습·개발·평가의 아키텍처로 다뤄야 한다는 요구도 커진다. 장시간 성공률뿐 아니라 권한 범위, 중간 검증, 중단과 복구 조건을 함께 측정해야 한다.
- 02
t3dotgg에이전트가 낮춘 구현비가 모바일 추상화의 값을 다시 묻는다
Shopify의 네이티브 재평가는 React Native의 실패 선언이 아니다. 에이전트가 Swift·Kotlin 구현과 이식·테스트 비용을 낮추면서 ‘한 번 작성’의 경제성이 약해진 반면, OTA 업데이트와 Expo 생태계, Meta가 축적한 네이티브 품질은 여전히 남는다. 실제 선택은 플랫폼별 테스트 능력, 긴급 배포 방식, 네이티브 의존성, 팀 전문성을 함께 비교해야 한다.
- 03GeekNews
생성 속도 뒤의 병목은 정보 위계와 데이터 계약이다
하루의 개발 신호들은 AI가 다이어그램·대시보드·발표 자료를 빠르게 만드는 것과 좋은 결과를 만드는 일이 다르다고 모인다. 디자인 규칙, 사용자가 먼저 내려야 할 판단, 검증된 레이아웃이 없으면 산출물은 쉽게 무너진다. 에이전트 업무에서도 데이터 품질·의미·사용 권한을 시스템 차원에서 명시해야 하며, 생성기는 이런 계약을 대신 발명할 수 없다.
아직 못 읽은 북마크
북마크를 고르는 중…