Anthropic이 재귀적 자기 개선을 공식 운영 시스템으로 발표했다.

에이전트가 다음 에이전트를 개선하는 피드백 루프다. 인간이 하던 구현·실험 작업 일부가 AI 시스템으로 넘어가며 개발 속도가 가속된다. 충분한 컴퓨트가 붙으면 에이전트 개발 자체가 에이전트에 의해 가속된다. 2026년 6월, Anthropic Institute가 이것을 연구 가설이 아니라 운영 중인 시스템으로 공개했다.

같은 패턴이 OpenAI에서도 확인됐다. Codex 기반 세금 신고 에이전트는 production trace와 practitioner feedback, eval 루프를 결합해 6주 만에 정확도를 25%에서 86%로 끌어올렸다. 모델을 교체한 것이 아니다. 루프를 설계했다.

개선되고 있다는 것이 문제가 된다

두 사례가 공통으로 가리키는 것이 있다. 에이전트는 이제 스스로 나빠지고 스스로 나아지는 시스템이 됐다는 것. 이것은 “AI가 더 똑똑해진다”는 이야기가 아니다.

핵심은 방향이다. 개선되고 있다는 것은 알겠는데, 어떤 기준으로 개선되고 있는가. 누가 그 기준을 설계했는가. 기준이 잘못되면 에이전트는 빠른 속도로 잘못된 방향으로 정교해진다. 잘못된 방향의 정교함은 잘못된 방향의 단순함보다 더 위험하다.

기존 에이전트는 배포하면 거기서 멈췄다. 루프가 없었다. 지금의 에이전트는 배포 이후에도 계속 변한다. PM이 배포 전에 작성한 명세는 루프가 돌기 시작하면 빠르게 현실과 어긋난다. “출시할 때는 맞았는데 지금은 왜 이런 결과가 나오는지 모르겠다”는 말이 나오기 시작하는 시점이 바로 여기다.

PM의 1차 산출물이 달라진다

기존 PM 역할의 기본 흐름은 이랬다. 기능 명세 → 개발팀 → QA → 배포. PM은 “무엇을 만들지”를 정의하는 사람이었다. 배포 이후에는 사용자 피드백을 모아 다음 명세에 반영했다. 루프가 분기 단위로 돌았다.

자기 개선 루프가 있는 에이전트에서는 이 흐름이 작동하지 않는다. 루프는 배포 직후부터 돌기 시작하고, 주 단위가 아니라 실행 단위로 에이전트를 바꾼다. PM이 분기 회고에서 변화를 발견했을 때는 이미 루프가 수백 번 돌았을 수 있다.

PM의 1차 산출물은 세 가지로 이동한다.

eval set 설계. 이 에이전트가 잘하고 있는지 어떻게 판단할 것인가. 정확도 외에 무엇을 측정할 것인가. OpenAI Codex 사례에서 25%→86%라는 수치가 가능했던 것은 “좋아졌다”를 측정하는 기준이 먼저 있었기 때문이다. 기준이 없으면 루프는 존재하지만 PM은 루프를 통제하지 못한다.

정정 로그 관리. 어떤 오류가 반복되는가. 어떤 사용자 행동이 루프를 비틀고 있는가. 반복 오류를 태깅하고 개선 티켓으로 연결하는 것이 PM의 일상 업무가 된다. Anthropic의 재귀적 자기 개선 시스템이 실제로 활용하는 것이 이 로그다. 피드백 없는 루프는 노이즈를 증폭시킨다.

롤백 기준 명세. 개선이 잘못된 방향으로 흘렀을 때 어디로 되돌릴 것인가. 권한 경계와 검증 조건을 사전에 명세하지 않으면 루프는 자율적으로 확장된다. “에이전트가 다음 에이전트를 개선하는 루프를 얼마나 안전하게 설계하는가”가 PM의 핵심 역량이 된다는 것이 Anthropic의 판단이다.

루프 설계는 선택이 아니다

자기 개선 루프는 더 이상 연구 주제가 아니다. Anthropic은 공식 운영 시스템으로 공개했고, OpenAI는 실제 세금 신고 도메인에서 6주 성과로 검증했다. 이 구조가 빅테크 기본 제품 레이어로 진입했다는 것은, 루프 없이 배포된 에이전트는 점점 뒤처진다는 뜻이기도 하다.

PM이 배포를 “마침표”로 쓰던 시대는 끝났다. 배포는 루프의 시작점이다.

에이전트가 개선되고 있다면, 그 기준을 누가 설계했는가. 지금 당신의 팀에서 이 질문에 답할 수 있는 사람이 있는가.