자기 개선형 AI 에이전트 구축 방법 완전 정리

자기 개선형 AI 에이전트는 모델 가중치를 바꾸지 않고, 작업 증거를 바탕으로 에이전트의 지시문·메모리·조사 루틴을 고치는 구조입니다. 내부 루프는 작업을 수행하고 외부 루프는 에이전트의 다음 버전을 제안합니다. 개선의 진위는 숨겨진 평가와 권한 분리, 반복 실험으로 검증해야 하며, 보상 해킹과 과적합을 경계해야 합니다.

⏱ 00:00자기 개선형 AI 에이전트는 최근 AI 연구에서 빠르게 주목받는 주제입니다. 발표자는 여러 AI 리더가 재귀적 자기 개선을 언급한 것을 계기로, 실무 관점에서 개념과 구현 방법을 설명하겠다고 밝힙니다. 핵심 질문은 AI 시스템이 자기 다음 버전을 만드는 과정 자체를 개선할 수 있는가이며, 그 개선이 실제로 효과가 있는지, 그리고 처음 보는 업무에도 전이되는지를 함께 따져야 한다고 강조합니다.

⏱ 01:20먼저 모델(LLM)과 에이전트를 구분해야 합니다. 모델은 텍스트를 생성하고 도구 호출 여부를 결정하며, 에이전트는 지시문, 도구, 메모리, 그리고 다음 행동을 정하는 주변 코드까지 포함하는 더 큰 시스템입니다. 이 주변 코드를 에이전트 하네스라고 부릅니다.

자기 개선은 보통 작업에서 얻은 증거를 바탕으로 지시문, 메모리, 코드 검색 방식 같은 에이전트 쪽 구성을 바꾸는 것이며, 모델 가중치는 그대로 둘 수 있습니다. 한 작업 안에서 오답을 고치는 것은 일시적 수정이고, 유용한 디버깅 절차를 저장해 이후 작업에 계속 적용하면 지속적인 시스템 변화가 됩니다. 다만 이런 변화도 추가 검증이 필요합니다.

⏱ 03:30재귀적 자기 개선에는 연결된 두 루프가 있습니다. 내부 루프는 과제를 읽고 행동을 고르고 도구를 호출해 결과를 관찰하며 실제 작업을 수행합니다. 외부 루프는 그 작업 과정을 분석해 에이전트의 다른 버전을 제안합니다. 발표자는 이를 수학의 이중 최적화(bilevel optimization)에 비유합니다. 재귀라는 말은 개선된 시스템이 다시 자기 개선 과정에 참여한다는 뜻이며, 과학자가 더 나은 실험법으로 다음 실험을 설계하는 것과 비슷합니다.

이 구조가 작동하려면 버전 관리된 에이전트, 허용되는 변경 범위, 도구 호출과 테스트 실패 같은 증거 기록, 후보 변경을 측정하는 평가기, 유용한 버전을 보관하는 아카이브가 필요합니다. 제안은 가설이고 수정된 에이전트 실행은 실험입니다. 또 무한한 발전이 보장되지 않으므로 정체나 비용 증가, 같은 실수의 반복도 고려해야 합니다.

⏱ 05:31발표자는 가상의 결제 회사를 예로 듭니다. 코딩 에이전트가 체크아웃 재시도 시 고객이 두 번 결제되는 버그를 맡았다고 가정합니다. 에이전트는 재시도 함수를 찾아 수정하고 로컬 테스트를 통과하지만, 통합 테스트에서 중복 결제가 발견됩니다. 원인은 재시도 처리기와 결제 서비스의 상호작용에 있었습니다.

작업 수준의 질문은 버그를 어떻게 고칠지이고, 개선 루프의 질문은 에이전트의 작업 방식이 이 실패를 왜 낳았는지입니다. 실행 기록을 보면 에이전트는 관련 있어 보이는 첫 함수만 고치고 그것을 호출하는 서비스는 확인하지 않았습니다. 이런 실패가 여러 작업에서 반복되면, 패치 전에 호출자와 관련 테스트를 확인하도록 조사 루틴을 바꾸는 제안이 나올 수 있습니다. 이때 바뀌는 대상은 결제 코드가 아니라 에이전트의 새 버전입니다.

⏱ 07:53제안된 루틴은 격리된 후보 에이전트에 설치한 뒤, 과거 버그 과제 모음에서 같은 조건으로 실행합니다. 정답 수정안과 최종 인수 테스트는 후보에게 숨기고, 두 버전은 같은 도구와 같은 비용 한도를 받아야 합니다. 그렇지 않으면 모델 호출을 훨씬 많이 쓴 후보가 단순히 나아 보일 수 있습니다.

넓은 조사가 서비스 경계를 넘는 결함에는 도움이 되지만 작은 격리 버그에는 시간을 낭비한다면, 의존성이 경계를 넘을 때만 조사 범위를 넓히는 조건부 버전을 다음 후보로 만들 수 있습니다. 허용 가능한 회귀 안에서 성능이 좋아지면 그 버전을 보관하고, 실제 업무 적용 여부는 별도의 롤아웃 과정이 결정합니다. 재귀 연결은 개선된 에이전트를 다음 주기에서 자기 코드 조사에 쓰는 것입니다. 다만 고객 버그 해결 성능이 좋아졌다고 해서 에이전트를 개선하는 능력까지 좋아졌다는 뜻은 아니므로, 같은 연구 예산에서 더 유용한 변경을 찾는지 따로 측정해야 합니다.

⏱ 08:40개선이 진짜인지 확인하려면 평가기가 가장 중요합니다. 테스트 통과 수는 객관적으로 보이지만, 에이전트가 테스트를 삭제하거나 외운 답을 내거나 채점 코드의 약점을 이용할 수도 있습니다. 실제 목표 달성 없이 측정 점수만 올리는 이런 현상을 보상 해킹이라고 합니다. 결제 예시에서 결제 자체를 건너뛰면 중복 결제는 막히지만 체크아웃이 깨집니다. 그래서 정상 결제와 올바른 재시도 동작을 함께 확인해야 합니다.

권한 측면에서는 인증 테스트와 채점 과정을 에이전트 권한 밖에 두어야 합니다. 에이전트가 기준을 약화시켜 스스로 작업을 승인하면 안 됩니다. 발표자는 연습 문제와 최종 시험에 비유하며, 개발 과제, 선택용 평가, 최종 보류 평가를 분리하라고 조언합니다. 같은 점수로 반복 선택하면 정답을 보지 않아도 그 시험에 과적합될 수 있으므로, 업무 분포가 바뀌면 보류 평가도 갱신해야 합니다.

⏱ 10:50에이전트 행동은 실행마다 달라지므로 작은 점수 향상은 잡음일 수 있습니다. 같은 과제에서 버전을 비교하고, 어디서 이기고 지는지 살핀 뒤 불확실성을 고려해 승격해야 합니다. 기업의 목표는 비용과 지연 시간의 제약 안에서 해결률을 높이면서 보안 요구를 지키는 것입니다. 평균 성능만 보면 심각한 회귀가 가려질 수 있습니다.

실무에서는 제한된 권한의 샌드박스에서 후보를 실행하고, 저장소 텍스트와 도구 출력은 신뢰할 수 없는 데이터로 취급해야 합니다. 저장소 안의 지시문이 에이전트를 조종할 수 있기 때문입니다. 운영 배포는 별도 승인 절차를 거치고, 승인된 변경을 모두 기록하며, 복구 가능한 버전을 보관해야 합니다. 연구 사례로 구글 딥마인드의 AlphaEvolve가 소개됩니다. 언어 모델이 코드를 제안하고 자동 평가기와 진화 탐색이 결합된 구조로, 알고리즘 발견과 인프라 최적화에 쓰였습니다. 다만 이것이 스스로 무한히 똑똑해지는 시스템을 증명하지는 않는다고 발표자는 선을 긋습니다. 재귀 개선은 반복 실험과 검증 가능한 결과가 있을 때 실용성이 가장 높다는 점이 마무리 메시지입니다.