Foundation Model Engineering

16.2 자율 에이전트 (Autonomous Agents)

인상적인 데모 에이전트를 만드는 일보다, 실제로 유용한 자율 에이전트를 만드는 일이 훨씬 어렵습니다. 진행이 막혔는지 알아차리고, 로그를 볼지 테스트를 돌릴지 정하고, 사고를 내기 전에 멈춰야 하기 때문입니다. “툴 사용”과 “자율성”의 차이는 프롬프트 한 줄이 아니라, 여러 단계에 걸쳐 시스템이 얼마나 일관성을 유지하느냐에 있습니다.

이 차이가 중요한 이유는 바로 이 지점에서 LLM이 단순한 단일 턴 채팅 인터페이스를 넘어, 실제로 일을 수행하는 시스템처럼 보이기 시작하기 때문입니다. 코드 디버깅, 장애 분류, API 조사, 티켓 처리처럼 multi-step이고 stateful하며 지저분한 작업을 맡기게 되기 때문입니다.

조금 더 쉽게 생각해 봅시다. 고장 난 배포 스크립트를 고치라고 시켰을 때, 단순 tool-using model은 read_file()과 edit_file()까지는 맞게 쓸 수 있습니다. 그래도 작업은 실패할 수 있습니다. 패치를 한 뒤 “정말 문제가 해결됐는가?”를 다시 묻는 루프가 없기 때문입니다. 자율성은 바로 이 계획-실행-검증 루프에서 시작됩니다.

1. 무엇이 에이전트를 자율적으로 만드는가?

실무적으로 보면 자율성은 대개 네 가지 능력의 조합입니다.

  1. goal persistence: 여러 step에 걸쳐 목표를 유지하는 능력
  2. action selection: 말만 하는 것이 아니라 툴을 고르는 능력
  3. state tracking: 지금까지 무엇을 했는지 기억하는 능력
  4. self-correction: 환경이 예상과 다를 때 경로를 바꾸는 능력

이것이 곧 하나의 거대한 아키텍처를 뜻하는 것은 아닙니다. 실제 배포 시스템의 상당수는 여전히 LLM 위에 조심스럽게 짠 orchestration layer입니다.

최근 벤치마크들은 이 간극을 더 분명하게 보여 줍니다. AgentBench는 긴 호흡의 추론, 의사결정, instruction following이 여전히 usable한 에이전트를 만드는 큰 장애물임을 보여 주고 [4], SWE-bench는 실제 소프트웨어 이슈 해결이 단발성 코드 생성이 아니라 환경 상호작용, 긴 컨텍스트, 여러 변경의 조율을 요구한다는 점을 드러냅니다 [5].

2. 프로덕션 에이전트의 최소 루프

트리 탐색이나 reflection을 이야기하기 전에, 실제로 쓸모 있는 최소 에이전트 루프를 먼저 적어 보면 도움이 됩니다.

  1. 현재 상태를 읽는다
  2. 다음 행동을 제안한다
  3. 실행하거나 승인을 요청한다
  4. 결과를 검증한다
  5. 종료하거나, 재계획하거나, 에스컬레이션한다

실제 프로덕션 에이전트의 대부분은 결국 이 루프에 예산, 메모리, 가드레일을 얹은 형태입니다. 개발자에게 중요한 포인트는 자율성이 “마법 같은 독립성”이 아니라, LLM 바깥을 감싸는 예산 제약형 제어 시스템이라는 점입니다.

자율성은 프롬프트 한 줄이 아니라 계층 구조다

이 루프를 여러 층으로 나눠서 보면 더 이해가 쉽습니다.

  • perception: 파일, 로그, 툴 출력, 사용자 상태를 읽는다
  • policy: 다음에 무엇을 할지 결정한다
  • execution: 툴을 통해 행동을 수행한다
  • verification: 세상이 의도한 방향으로 바뀌었는지 확인한다

실제 에이전트 실패의 상당수는 추상적인 “추론 실패”가 아닙니다. 환경을 잘못 읽었거나, 잘못된 툴을 골랐거나, 툴 출력을 잘못 해석했거나, 검증 단계를 아예 건너뛴 인터페이스 실패인 경우가 많습니다.

3. 계획 루프

ReAct: 추론과 행동을 번갈아 수행하기

출발점으로 가장 많이 쓰이는 접근은 ReAct 입니다 [1]. 모델은 짧은 내부 계획과 외부 행동을 번갈아 수행합니다.

  1. 생각한다
  2. 행동한다
  3. 결과를 본다
  4. 다시 생각한다

이 방식은 단순하고 강력하며 구현도 쉽습니다. 하지만 선형 루프이기 때문에 초반에 잘못된 선택을 하면 다른 경로를 탐색하지 못한 채 계속 실수를 키우기 쉽습니다.

탐색 기반 계획

이 약점을 보완하려는 대표적 접근이 Language Agent Tree Search (LATS) 입니다 [2]. 하나의 reasoning trajectory에 바로 올인하는 대신, 여러 분기를 탐색하고 점수를 매깁니다. 여기서 중요한 것은 모든 production agent가 full tree search를 써야 한다는 뜻이 아닙니다. 더 긴 호흡의 작업일수록 단순한 왼쪽에서 오른쪽 improvisation보다 명시적인 search가 유리할 수 있다는 점입니다.

LATS는 다음과 같은 UCT 균형식을 사용합니다.

UCT(s,a)=Q(s,a)+cln⁡N(s)N(s,a)UCT(s, a) = Q(s, a) + c \sqrt{\frac{\ln N(s)}{N(s, a)}}

수식 자체보다 중요한 것은 그 뒤의 설계 원칙입니다. 자율 에이전트는 이미 좋아 보이는 경로를 따르는 것과 다른 대안을 시험해 보는 것 사이에서 균형을 잡아야 합니다.

4. Reflection과 Self-Correction

자율 에이전트를 이해하는 좋은 방법 중 하나는 전통적인 RL 시스템과 비교하는 것입니다. 고전적인 RL은 모델 가중치를 바꿉니다. 많은 에이전트 시스템은 대신 다음 step에서 모델이 보게 되는 컨텍스트 를 바꿉니다.

Reflexion

대표적인 예가 Reflexion 입니다 [3]. 실패한 시도 뒤에 에이전트가 “무엇이 잘못됐는지”를 짧은 자연어 교훈으로 남기고, 다음 시도에서는 그 교훈을 working context에 붙입니다.

이것은 durable learning과는 다릅니다. 최근 실수를 정리한 scratchpad에 더 가깝습니다. 이 차이가 중요합니다. 현재 시스템에서 reflection은 국소적인 행동 개선에는 도움이 되지만, 전혀 다른 과업으로 건너가도 안정적으로 일반화된 능력을 보장해 주지는 않습니다.

무엇이 비교적 확립됐고, 무엇이 아직 불안정한가?

  • 비교적 확립된 것: ReAct-style loop와 reflection prompt는 실용적인 설계 패턴이다.
  • 떠오르는 방향: task 간에 재사용 가능한 규칙이나 meta-policy를 저장하려는 시도
  • 아직 불안정한 것: 이런 메모리나 규칙 추출 기법이 열린 환경에서 얼마나 견고하게 일반화되는지

5. 진짜 병목은 Reliability다

자율성은 에이전트가 계속 움직일 때 멋져 보입니다. 신뢰성은 에이전트가 언제 멈춰야 하는지를 알 때 생깁니다.

자주 보는 실패 모드는 다음과 같습니다.

  • 같은 tool call을 반복한다
  • 원래 목표에서 벗어난다
  • 자기 중간 산출물을 과신한다
  • 가치가 낮은 분기에 너무 많은 step을 쓴다
  • 기술적으로는 가능하지만 운영상 위험한 행동을 한다

그래서 프로덕션 에이전트에는 보통 다음 같은 시스템 제약이 함께 붙습니다.

  • step limit
  • retry limit
  • timeout
  • checkpointing
  • destructive action에 대한 human approval

겉으로는 자율적으로 보여도, 바깥 런타임의 가드레일이 여전히 필요합니다.

6. 인터랙티브 LATS 시각화

아래 시각화는 선형 루프가 막힐 때 search가 왜 도움이 되는지 보여줍니다. 첫 번째로 그럴듯한 행동에 바로 몰아붙이지 않고 여러 분기를 비교할 수 있다는 점에 주목해 보세요.

LATS (Language Agent Tree Search) Simulation

Observe how nodes expand and Q-values backpropagate. High Q-value paths (Green) are exploited, while low Q-value paths (Red) are abandoned.

Task: Debug DB Error
Q: 0.50N: 1

7. 핵심 정리

자율 에이전트는 control loop 안에 들어간 LLM 으로 이해하는 편이 가장 정확합니다. persistence, action, self-correction을 주는 것은 모델 하나가 아니라 그 루프입니다. planning과 learning을 더 잘 만드는 연구는 계속되고 있지만, 프로덕션 관점의 교훈은 이미 분명합니다. 런타임 제한 없는 자율성은 대체로 장점보다 리스크가 더 큽니다.

다음 절에서는 단일 에이전트에서 나아가, 여러 전문화된 에이전트가 작업과 정보를 나눠 갖는 시스템을 살펴봅니다.

Quizzes

Quiz 1: ReAct-style loop가 긴 호흡의 작업에서는 자주 부족한 이유가 무엇인가요? 단일한 선형 trajectory만 따라가기 때문입니다. 초반 선택이 잘못되면 다른 경로를 탐색하지 못한 채 실수를 계속 키우기 쉽습니다.

Quiz 2: 단순 tool-using assistant와 autonomous agent의 핵심 시스템 차이는 무엇인가요? 자율 에이전트는 진행 상황을 추적하고, 반복적으로 행동을 고르고, 결과를 확인하고, 계속할지 멈출지를 판단하는 control loop 안에 들어 있다는 점입니다.

Quiz 3: reflection이 durable learning과 같지 않은 이유는 무엇인가요? 보통은 모델 가중치를 바꾸는 것이 아니라 다음 프롬프트나 working context를 바꾸는 수준이기 때문입니다. 국소적 개선은 가능하지만 폭넓은 일반화를 보장하지는 않습니다.

Quiz 4: 모델이 강해도 production agent에 외부 가드레일이 필요한 이유는 무엇인가요? 실제 리스크는 종종 추론 능력보다 운영 문제에서 나오기 때문입니다. 무한 루프, 위험한 툴 사용, 반복 retry, goal drift 같은 문제는 런타임 제어가 막아야 합니다.

References

  1. Yao, S., et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.
  2. Zhou, A., et al. (2023). Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models. arXiv:2310.04406.
  3. Shinn, N., et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366.
  4. Liu, X., et al. (2024). AgentBench: Evaluating LLMs as Agents. arXiv:2308.03688.
  5. Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., & Narasimhan, K. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770.