에이전트가 첫 시도에서 곧바로 정답을 내는 경우는 생각보다 드물다. 실무에서 에이전트를 운영해보면 코드 한 줄이 안 돌아가거나 답변에 조건 하나가 빠져 있는 경우가 흔하고, 그래서 최근 에이전트 설계에서는 결과를 내놓은 뒤 스스로 무엇이 잘못됐는지 되짚어보는 ‘반성(Reflection)’ 단계를 별도로 두는 방식이 자리잡고 있다.
Reflexion, 가중치 대신 언어로 행동을 교정한다
가장 널리 인용되는 접근은 노아 신(Noah Shinn) 등이 2023년 NeurIPS에 발표한 Reflexion이다. 이 방식은 모델 가중치를 다시 학습시키는 대신, 실패 원인을 자연어 문장으로 정리한 반성문을 만들고 이를 에피소드 메모리에 저장해둔다. 다음 시도에서는 이 반성문을 프롬프트에 함께 넣어, 같은 실수를 반복하지 않도록 유도한다. 연구진은 이 방식을 그래디언트 업데이트 없이 언어만으로 행동을 교정한다는 의미에서 ‘언어적 강화학습(verbal reinforcement learning)‘이라 불렀다.
효과는 벤치마크로도 확인됐다. Reflexion을 적용한 에이전트는 HumanEval 코드 생성 벤치마크에서 pass@1 기준 91%를 기록해, 당시 GPT-4의 80%를 앞선 것으로 보고됐다. 정답을 미리 알려주지 않고 반성 루프만으로 정확도를 14%포인트 끌어올렸다는 점이 특히 주목받았다.
| 모델 | HumanEval pass@1 |
|---|---|
| Reflexion 적용 에이전트 | 91% |
| GPT-4 (당시) | 80% |
자기 수정이 오히려 답을 망치는 경우
다만 반성이 언제나 성능을 끌어올리는 것은 아니다. 주 황(Jie Huang) 등이 2023년 발표한 ‘Large Language Models Cannot Self-Correct Reasoning Yet’ 연구는, 외부 피드백 없이 모델이 순수하게 자기 판단만으로 답을 고쳐 쓰는 ‘내재적 자기 수정(intrinsic self-correction)‘의 경우 성능이 개선되지 않거나 오히려 나빠지는 사례를 보고했다. 맞는 답을 스스로 틀렸다고 판단해 오답으로 바꿔버리는 경우도 관찰됐다.
엇갈린 결과의 이유, 반성의 재료
두 연구의 결과가 엇갈리는 이유는 ‘반성의 재료’가 다르기 때문이다. Reflexion은 코드가 실제로 테스트를 통과했는지, 과제를 완수했는지처럼 외부 환경에서 온 명확한 성공·실패 신호를 반성의 근거로 삼는다. 반면 황 등이 지적한 실패 사례는 그런 외부 신호 없이, 모델이 자기 답을 자기가 다시 채점하는 상황이었다. 채점 기준 자체가 모델 내부에만 있으면, 반성은 근거 없는 자기 의심으로 흐르기 쉽다는 뜻이다.
CRITIC, 외부 도구로 사실을 확인한다
이런 한계를 보완하는 방법으로 제시된 것이 CRITIC(Tool-Interactive Critiquing)이다. 초기 답변을 생성한 뒤, 검색이나 코드 실행기 같은 외부 도구를 호출해 사실 여부나 실행 결과를 확인하고, 그 결과를 근거로 답을 다시 고치는 3단계 구조다. 연구진은 여러 과제에서 모델 혼자만의 판단으로는 신뢰할 만한 자기비평이 어렵다는 점을 재확인하며, 외부 도구 연동이 핵심이라고 강조했다.
실무적으로 정리하면, 반성 루프를 넣는 것 자체보다 그 반성이 무엇을 근거로 이뤄지는지가 더 중요하다.
외부에서 검증 가능한 신호에 반성을 고정한다
테스트 통과 여부, 검색 결과, 계산기 실행값처럼 외부에서 확인 가능한 신호가 있다면 반성은 실제로 품질을 끌어올린다. 반대로 아무 근거 없이 “다시 한번 확인해봐”라고만 지시하면, 맞는 답이 오히려 틀린 답으로 바뀌는 역효과가 날 수 있다. 실제 코딩 에이전트들이 답을 내놓기 전에 테스트 스위트를 돌려보게 하거나, 리서치 에이전트가 답변마다 근거 문서 링크를 확인하게 만드는 것도 결국 같은 원리다 — 반성의 대상을 모델의 느낌이 아니라 외부에서 검증 가능한 결과로 고정해두는 것이다.
테스트 타임 컴퓨팅과의 관계
이 흐름은 앞서 다룬 테스트 타임 컴퓨팅과도 맞닿아 있다. 사전 학습을 더 크게 하는 대신 답을 낼 때 연산을 더 쓴다는 점에서, 반성 루프 역시 테스트 타임에 투입하는 연산의 한 형태로 볼 수 있다. 다만 단순히 더 오래 생각하게 하는 것과, 검증 가능한 외부 신호를 근거로 답을 고치는 것은 품질 개선의 메커니즘 자체가 다르다는 점이 이번 연구들이 주는 시사점이다.
정리
물론 반성 단계가 늘어날수록 응답 시간과 비용도 함께 늘어난다. 검색 호출이나 코드 실행을 매 단계마다 거치면 지연시간이 눈에 띄게 길어지고, API 비용도 그만큼 누적된다. 그래서 모든 요청에 반성 루프를 걸기보다, 실패 확률이 높거나 오류의 비용이 큰 작업 — 금융 계산, 코드 배포, 법률·의료 관련 답변처럼 틀렸을 때 파급력이 큰 영역 — 에 선별적으로 적용하는 쪽으로 무게중심이 옮겨가는 추세다. 결국 반성 루프의 설계는 ‘얼마나 자주 되돌아볼 것인가’가 아니라 ‘무엇을 근거로 되돌아볼 것인가’를 먼저 정하는 일에서 시작된다.