9월 28일 월요일
신뢰할 수 있는 에이전트는 프롬프트의 문장력보다 하네스의 상태 관리, 통제 실험, 실패 신호, 승격 기준에서 만들어진다.
프롬프트를 프로그램으로 승격시키는 다섯 개의 층
도구·메모리·독립 검토·정책 게이트·실행 단위 평가가 결합될 때 스킬은 재현 가능한 하네스가 된다.

길고 반복적인 에이전트 작업을 프롬프트 묶음이 아니라 검증 가능한 시스템으로 만들려면 무엇을 분리해야 하는가?
프롬프트를 길게 만드는 방식은 모델의 기본 선택과 자기 확증, 세션 단절, 하네스별 권한 차이를 함께 해결하지 못한다. Impeccable 사례는 전문 하위 스킬, 결정론적 스크립트, 브라우저 증거, 훅, 장기 메모리, 모델별 빌드를 결합해 스킬을 하네스 확장으로 바꾼다. Project Paradox는 한 단계 더 나아가 개별 응답 대신 전체 실행을 평가하고, 기억·출처·불확실성·재계획을 제한된 정책 표면으로 둔다. 두 사례의 공통점은 모델에게 더 좋은 말을 건네는 것이 아니라 상태와 증거, 승격 조건을 외부 시스템에 고정한다는 데 있다.
- 01
독립 검토와 결정론적 검사를 분리한다
자기 결과를 같은 대화에서 다시 평가시키면 생성 당시의 앵커가 남는다. Impeccable은 사람처럼 계층과 사용성을 보는 비평과 대비·간격 같은 측정 가능한 검사를 서로 보지 못한 상태로 실행한 뒤 메인 단계에서 합친다. 한 평가기의 확신이 다른 평가를 오염시키지 않게 하는 구조다. 코드 리뷰라면 구조적 판단과 테스트·린터, 보안 감사라면 공격자 관점과 정적 분석을 별도 트랙으로 수집할 수 있다.
- 02
상태는 기록하되 사실·믿음·출처를 섞지 않는다
장기 실행에서는 기억량보다 기억의 의미가 문제다. Project Paradox의 사회적 에이전트는 시간이 지나며 소문의 출처를 잃고 불확실한 말을 확정 사실처럼 전하거나, 알고 있는 사실을 행동에 반영하지 못했다. 원시 사건 기록과 현재 믿음을 분리하고, 직접 본 정보와 전해 들은 정보를 표시하며, 변경된 사실이 계획을 갱신하는 조건을 명시해야 한다. 단순한 검색 증강 메모리는 이 상태 전이를 대신하지 못한다.
- 03
평가 단위를 한 응답에서 전체 실행으로 올린다
짧은 데모의 자연스러운 답변은 장기 행동을 보장하지 않는다. 통제 시나리오를 고정하고 관찰, 대화, 기억 쓰기, 검색, 믿음 변화, 행동을 구조화된 trace로 남겨야 한다. 도달률만 높이면 사적 정보까지 과도하게 전파될 수 있으므로 출처 유지, 불확실성 보존, 행동 일관성, 재계획 시간, 정보 봉쇄를 함께 본다. 한 지표가 좋아지고 가드레일이 나빠지면 이전 정책으로 롤백하는 래칫이 필요하다.
- 04
하네스와 모델의 차이를 빌드 단계에서 흡수한다
도구 호출 문법, 훅 실행 시점, 백그라운드 작업 가능 여부, 모델의 과적합 패턴은 하네스마다 다르다. 하나의 스킬 디렉터리를 그대로 복사하면 어떤 환경에서는 검토 단계나 완료 이벤트가 빠질 수 있다. Impeccable은 모델·하네스별 파일과 규칙을 생성하고, 약한 모델이 건너뛸 수 없는 게이트와 통과 상태를 둔다. 공통 명세와 플랫폼 어댑터를 나누고 실제 배포 조합별 회귀 평가를 운영해야 한다.
- 05
자동 평가는 필터이고 승격은 별도 결정이다
기능적 오류는 스크립트와 모델 심사로 줄일 수 있지만 taste나 조직별 위험 허용치는 자동 점수 하나로 환원되지 않는다. Impeccable은 여러 모델과 분야에서 반복 평가하고 규칙 제거 실험도 수행하지만, 디자인의 최종 판단은 사람에게 남긴다. Project Paradox도 자동 연구가 제안한 정책을 곧바로 배포하지 않고 균형 점수표와 안전 가드레일을 통과한 변경만 보존한다. 생성, 평가, 승격 권한을 같은 에이전트에 몰아주지 않는 것이 핵심이다.
구현 순서는 명확하다. 먼저 하네스가 제공하는 도구·권한·이벤트를 목록화하고, 장기 상태의 스키마와 trace를 고정한다. 다음으로 재현 가능한 시나리오와 균형 지표를 만든 뒤, 자동 개선에는 기억·통신·신뢰·재계획처럼 작은 정책 표면만 연다. 독립 검토와 결정론적 검사를 함께 통과하고 전체 실행의 가드레일이 유지될 때만 새 정책을 승격한다. 이 구조가 없으면 프롬프트 개선은 성공 사례만 남기는 수동 튜닝으로 되돌아간다.
최적화 루프를 믿기 전에 증거의 층을 쌓아라
trace에서 후보를 만들고, 재현 가능한 경주에서 검증하며, 최고점이 아니라 실패의 바닥까지 확인하는 흐름이다.
에이전트가 스스로 시스템을 개선했다는 주장을 어떤 순서로 검증해야 하는가?
- 1
1. 보상 점수 앞에 trace를 보존한다
강화학습식 단일 보상은 도구 호출, 환경 응답, 오류 메시지에 든 진단 정보를 한 숫자로 압축한다. GEPA는 전체 실행 trace와 텍스트 피드백을 성찰 모델에 주어 프롬프트나 코드 후보를 수정한다. 적용 전제는 성공률뿐 아니라 어떤 입력에서 어떤 도구가 왜 실패했는지 재구성 가능한 로그다.
- 2
2. 최고 후보 하나 대신 서로 다른 강점을 보존한다
GEPA는 평균 점수가 가장 높은 후보만 남기지 않고 적어도 한 학습 예시에서 이긴 후보를 Pareto pool에 유지한다. 서로 다른 실패 영역의 강점을 보존해 지역 최적점에 갇히는 위험을 줄이는 방식이다. 발표 사례에서 3개 예시와 한 차례 성찰이 25,000회 롤아웃의 GRPO보다 큰 이득을 냈지만, 이 수치는 제시된 과제와 평가기의 범위 안에서 해석해야 한다.
- 3
3. 작은 과제의 승리를 재현 가능한 경주로 만든다
Prime Intellect의 nanoGPT 최적화 경주는 목표 손실과 변경 범위를 고정하고 여러 에이전트가 실험을 선택·실행·재검증하는 과정을 비교했다. Claude Code와 Codex는 당시 인간 기록을 줄였지만, 알려진 연구를 영리하게 조합했을 뿐 새 optimizer나 메커니즘을 만들지는 못했다. 여러 seed와 동일 조건, 전체 trace가 없으면 한 번의 기록을 연구 능력으로 일반화할 수 없다.
- 4
4. 성능의 천장과 실패의 바닥을 따로 잰다
더 높은 벤치마크 점수는 새 능력의 천장이 올라간 결과일 수도 있고, 어이없는 실패가 줄어든 결과일 수도 있다. 긴 워크플로에서는 최고 성공보다 작은 실패의 누적이 비용을 만든다. 따라서 성공률 평균과 함께 최악 사례, 중단 빈도, 복구 가능성, 추론·행동의 관찰 가능성을 별도 지표로 둬야 한다. 효율화가 추론 흔적을 줄이면 비용은 낮아져도 감사 가능성은 나빠질 수 있다.
- 5
5. 탐색 결과와 배포 결정을 분리한다
텍스트 성찰은 프롬프트뿐 아니라 에이전트 하네스, 스킬, 스케줄링 정책까지 빠르게 바꿀 수 있다. 빠른 변화는 평가기가 놓친 허점을 함께 확대할 수 있으므로 후보 생성과 운영 승격 사이에 독립 검증이 필요하다. 작은 벤치마크에서 얻은 개선은 더 큰 모델·데이터·시간 범위에서 다시 확인하고, 인간 문헌 접근 수준과 하네스 조건을 공개해야 독창성과 재현성을 구분할 수 있다.
실전 파이프라인은 trace 수집, 텍스트 후보 생성, 다양성 보존, 고정 시나리오 재실행, 다중 seed 검증, 실패 바닥 감사, 독립 승격의 순서가 된다. GEPA가 보여 준 샘플 효율은 탐색기를 강하게 만들지만, nanoGPT 경주가 보여 준 독창성의 한계와 페이싱 논의가 제기한 해석 가능성 문제를 제거하지 않는다. 최적화 속도를 높일수록 평가 환경과 롤백 규칙을 더 느리고 엄격하게 운영해야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…