AI 에이전트 자기개선, 네 가지 방식과 검증기의 역할

게시 2026.07.18 · 약 6분 분량

AI 에이전트 자기개선은 에이전트가 자기 출력이나 실행 결과를 스스로 평가하고 그 피드백을 다음 시도에 되먹여 결과를 끌어올리는 기법이다. 2026년 7월 기준 실무에서 참고할 만한 접근은 크게 두 갈래로 나뉜다. 모델 가중치는 그대로 두고 실행 중에 반성 루프만 도는 방식과, 스스로 만든 데이터나 코드로 에이전트 자체를 다시 학습시키는 방식이다. 앞쪽 대표가 NeurIPS 2023에서 발표된 Reflexion과 Self-Refine, 뒤쪽 대표가 STaR와 Sakana AI의 Darwin Gödel Machine이다. 이 글은 대형 언어모델(LLM, 사람이 쓴 방대한 텍스트로 학습해 문장을 생성하는 모델) 기반 에이전트를 기준으로 각 기법의 원리와 한계를 정리하며, 특정 프레임워크의 설치나 설정 방법은 다루지 않는다.

마침 이 두 갈래를 아우르는 체계적인 정리도 나왔다. 2026년 7월 14일 arXiv에 공개된 97쪽 서베이 Self-Improvements in Modern Agentic Systems: A Survey(공저자에 LSTM 공동 개발자 위르겐 슈미트후버가 포함됐다)는 현대 에이전트를 파운데이션 모델과 운영 스캐폴드(프롬프트·메모리·도구·제어 메커니즘)의 결합으로 모델링하고, 자기개선을 모델 파라미터 또는 스캐폴드 요소를 에이전트가 스스로 수정하는 과정으로 정의한다. 이 서베이는 기존 연구를 수정 대상(무엇을 고치나)과 구동 신호(무엇이 개선을 촉발하나)로 분류하고 평가 방법론과 남은 과제를 정리했다. 이 글의 구분으로 보면 실행 중 반성은 스캐폴드 수정에, 재학습은 모델 파라미터 수정에 해당한다.

자기개선 에이전트는 보통 에이전트와 무엇이 다른가

차이는 루프에 있다. 일반 에이전트는 답을 한 번 내면 그걸로 끝이지만, 자기개선 에이전트는 자기 답을 검증하는 단계를 따로 두고 그 결과를 다음 시도의 입력으로 돌린다. 그래서 어떤 자기개선 방식이든 최소 두 조각으로 이뤄진다. 답을 만드는 생성기와, 그 답이 쓸 만한지 판정하는 평가기다.

갈리는 지점은 개선이 언제 일어나느냐다. Reflexion이나 Self-Refine처럼 실행 중에만 도는 방식은 가중치를 건드리지 않는다. 한 과제 안에서만 나아지고 세션이 끝나면 배운 내용이 사라진다. 반대로 STaR나 코드 진화 방식은 스스로 만든 결과로 모델이나 에이전트를 다시 학습시키므로 개선이 다음 과제까지 남는다. 에이전트의 유형 자체가 헷갈린다면 LLM 에이전트를 세 축으로 나눈 글을 먼저 보면 이 구분이 더 또렷해진다.

실행 중에 반성하는 방식: Reflexion과 Self-Refine

Reflexion은 가중치를 고치는 대신 언어로 된 피드백만으로 에이전트를 강화한다. Noah Shinn 등이 NeurIPS 2023에서 발표한 Reflexion 논문은 에이전트를 세 역할로 나눈다. 행동을 만드는 액터, 그 행동이 과제를 풀었는지 판정하는 평가기, 실패 원인을 짧은 반성문으로 적는 자기반성 모듈이다. 이 반성문은 에피소드 메모리에 쌓여 다음 시도의 프롬프트에 붙는다. 논문에 따르면 이 방식으로 GPT-4가 코드 생성 벤치마크 HumanEval에서 91%를 기록했다. 평가기는 도메인에 따라 단위 테스트가 될 수도, 규칙이 될 수도, 다른 LLM 프롬프트가 될 수도 있다.

Self-Refine은 더 단출하다. Aman Madaan 등의 Self-Refine 논문(NeurIPS 2023)은 하나의 LLM이 생성기·피드백·수정기를 동시에 맡는다. 먼저 초안을 만들고, 같은 모델이 그 초안을 비평하고, 그 비평을 반영해 다시 고치는 순환을 별도 학습 없이 반복한다. 논문은 코드 최적화 과제에서 GPT-4 성능이 8.7포인트 올랐다고 보고했다. 두 방식 모두 원리는 아래 반복 루프로 요약된다.

# Self-Refine 방식의 반복 루프 (개념 예시)
output = model.generate(task)
for _ in range(max_iters):
 feedback = model.critique(task, output) # 같은 모델이 자기 출력을 평가
 if feedback.is_good_enough:
 break
 output = model.refine(task, output, feedback)

대신 반복마다 LLM을 여러 번 더 호출하므로 토큰과 지연 시간이 늘어난다. 반성 한 번이 곧 호출 한 번이라는 점을 설계 단계에서 비용에 넣어야 한다. 원문은 Reflexion 논문과 Self-Refine 논문에서 확인할 수 있다.

가중치까지 바꾸는 방식: STaR와 코드 진화

여기서부터는 개선이 모델 안에 새겨진다. Eric Zelikman 등이 2022년 공개한 STaR(Self-Taught Reasoner) 논문은 모델이 스스로 만든 풀이 과정을 학습 데이터로 되쓴다. 문제를 풀게 한 뒤 정답에 도달한 풀이만 남겨 그걸로 모델을 미세조정하고, 나아진 모델로 다시 풀이를 생성하는 과정을 반복한다. 틀린 문제는 정답을 미리 알려 주고 근거를 만들게 하는 합리화 단계로 메운다. 다만 새로 맞히는 문제가 더는 안 나오면 루프가 멈춘다는 한계가 있다.

에이전트 코드 자체를 고치는 방식도 있다. Sakana AI 등 연구진이 2025년 공개한 Darwin Gödel Machine(DGM)은 에이전트가 자기 파이썬 코드를 바꾸고, 그 변경이 나아졌는지를 코딩 벤치마크로 실제 검증한 뒤 반영한다. 논문에 따르면 실제 깃허브 이슈를 자동으로 고치는 벤치마크 SWE-bench에서 성능이 20.0%에서 50.0%로, 여러 언어 과제를 다루는 Polyglot에서 14.2%에서 30.7%로 올랐다. 이는 위르겐 슈미트후버가 제안한 원래 괴델 머신과 결이 다르다. 원래 개념은 변경이 이롭다는 걸 증명해야 코드를 바꾸지만, DGM은 증명 대신 벤치마크 점수라는 경험적 근거로 판단한다. 자세한 내용은 Darwin Gödel Machine 논문에 정리돼 있다.

방식별 차이 한눈에 보기

네 방식은 무엇을 바꾸는지와 무엇으로 검증하는지에서 갈린다. 아래 표로 정리했다.

정리하면 위 두 줄은 그때그때 나아지고 배선이 가볍지만 세션이 끝나면 리셋된다. 아래 두 줄은 개선이 영구적으로 남는 대신 학습 비용과 검증 인프라가 든다. 지금 손에 든 문제가 한 과제 안에서만 좋아지면 되는지, 다음 과제까지 학습이 남아야 하는지가 선택의 첫 갈림길이다.

무엇이 자기개선의 성패를 가르나

핵심은 평가 신호가 얼마나 정확하고 싼가다. 위 네 방식이 전부 생성기와 평가기로 이뤄진다는 점을 떠올리면, 결국 평가기의 품질이 천장을 정한다. 평가가 틀리면 루프는 잘못된 방향으로 더 확신을 갖고 나아갈 뿐이다.

그래서 자기개선은 성공 여부를 기계가 값싸게 확인할 수 있는 영역에서 가장 잘 통한다. 코드가 대표적이다. 단위 테스트를 돌리면 통과와 실패가 바로 나오니 평가기가 거의 공짜인 데다 신뢰도도 높다. Reflexion과 DGM이 코딩 벤치마크에서 큰 폭으로 좋아진 데에는 이 점이 크게 작용했다. 반대로 정답이 하나로 안 떨어지는 글쓰기나 전략 판단 같은 영역에서는, 같은 모델에게 자기 답을 채점시키는 순간 편향이 그대로 증폭될 위험이 있다.

실무 순서도 여기서 나온다. 반복 루프를 붙이기 전에 믿을 만한 평가기부터 만들어야 한다. 단위 테스트든 정답 데이터든 별도 검증 규칙이든, 성공을 값싸게 판정할 방법이 없다면 루프를 늘려도 비용만 불어난다. AI가 코드를 대신 써 주는 시대에 검증과 이해가 오히려 병목이 된다는 관점과도 맞닿는 지점이다. 자기개선 에이전트를 얹기 전에, 그 에이전트가 옳게 나아가는지 무엇으로 확인할지부터 정하는 편이 순서에 맞다.