하네스가 실행 중에 자신을 고쳤습니다.

구글·스탠퍼드·UW 연구팀이 공개한 RRSI(Recursive Self-Improving Systems Infrastructure)는 에이전트가 작업을 수행하면서 자신의 실행 구조 — 하네스를 직접 수정한다는 것을 실측했습니다. 기존 에이전트 논의의 전제를 뒤집는 결과입니다. 설계자가 하네스를 만들고 에이전트가 그 위에서 동작한다는 구도가 바뀝니다. 이제 에이전트가 하네스의 공저자입니다.

이 방향이 어디까지 가고 있는지는 OpenAI의 사례가 보여줍니다. OpenAI가 Agents API를 통해 구축한 세금 처리 에이전트는 6주 만에 완수율이 25%에서 86%로 올랐습니다. 사람이 하네스를 매번 업데이트한 것이 아닙니다. 에이전트가 반복 실행 과정에서 자신의 처리 흐름을 조정했습니다. 같은 시기에 OpenAI는 Decisions API도 출시했습니다. 에이전트가 실행 중 분기 조건을 동적으로 등록하고 외부 시스템에 판단을 위임하는 API입니다. 설계 시점에 고정되던 논리가 런타임으로 넘어갔습니다.

연결 수도 같이 올라갔습니다. Lainner의 Actions MCP는 연결 가능한 서비스를 1,100개로 늘렸고, Nango는 1,000개 API를 커버하는 통합 레이어를 출시했습니다. 에이전트가 ‘계속 일하는’ 구조를 만드는 인프라 측 퍼즐 조각이 맞춰지는 속도입니다.

PM에게 이 흐름이 가리키는 것은 질문의 이동입니다.

지금까지 에이전트 설계 단계의 질문은 두 층이었습니다. 첫째, 어떤 업무를 에이전트에게 맡기는가. 둘째, 그 업무를 어떤 실행 흐름으로 처리하게 하는가. RRSI와 Decisions API가 말하는 것은 이 두 번째 층이 정적이지 않다는 것입니다. 하네스가 런타임에 바뀐다면, 설계했던 실행 구조가 에이전트에 의해 변형될 수 있습니다.

이는 새로운 질문을 만듭니다. 에이전트가 하네스를 고칠 때, 그 변경이 의도된 것인지 누가 어떻게 확인하는가. OpenAI 세금 에이전트의 완수율 상승은 긍정적 결과였습니다. 그러나 같은 자기수정 루프가 다른 방향으로 작동할 수 있다는 조건은 설계 단계에서 설정해야 합니다.

이것이 모델 선택이나 하네스 설계와 구분되는 세 번째 역량입니다. 자기수정 루프의 감시 설계.

실용적으로 쓸 수 있는 틀은 세 축입니다.

변경 로그를 가시화합니다. 에이전트가 하네스의 어떤 부분을 수정했는지를 관측할 수 없으면 디버깅 불가능한 시스템이 됩니다. 실행 구조의 변경 이벤트를 로그로 남기는 것은 이 단계의 최소 조건입니다.

자기수정의 범위를 사전에 정의합니다. 어떤 레이어까지 에이전트가 수정할 수 있고, 어떤 레이어는 사람이 승인해야 하는지를 설계 시점에 구분합니다. 런타임에 권한 경계를 설정할 수 없습니다.

멈춤 조건을 먼저 씁니다. ’에이전트가 계속 일한다’는 것은 에이전트가 멈추는 조건을 PM이 명확하게 정의했을 때만 안전합니다. Lainner 1,100개 연결, Nango 1,000개 API를 에이전트에 붙이기 전에, 멈춤 트리거 목록이 먼저입니다.

하네스를 설계하는 역량이 시장 가치가 된 것은 지난주의 신호였습니다. 하네스를 감시하는 역량이 다음 전선입니다.

지금 여러분 팀의 에이전트는 자신의 실행 구조를 수정할 수 있습니까 — 그리고 그 변경을 추적하고 있습니까?