반응형 에이전트 구축을 멈추세요: 왜 귀하의 아키텍처에 System 1과 System 2가 필요한가
Source: Dev.to
최근에 LLM 에이전트를 만든 적이 있다면, “자율성 벽”에 부딪혔을 가능성이 높습니다.
에이전트에게 웹 검색 도구와 “도움을 주라”는 프롬프트, 그리고 작업을 부여합니다. 처음 두 번의 턴에서는 마법처럼 보이지만, 세 번째 턴에서는 위키피디아의 토끼굴에 빠집니다. 열 번째 턴이 되면 다운로드하지도 않은 파일의 구문 오류를 고치려는 무한 루프에 갇히게 됩니다.
대부분의 개발자는 시스템 프롬프트에 더 많은 지시문을 넣어 해결하려고 합니다: “같은 행동을 두 번 반복하지 마! 단계별로 생각해!”
하지만 문제는 프롬프트가 아니라 아키텍처입니다. 하나의 실행 루프에 대화/행동(저지연, 고대역폭)과 계획(느리며 심사숙고하는 추론)이라는 완전히 다른 두 작업을 강제하고 있기 때문입니다.
반응형 에이전트의 문제점
표준 에이전트(예: 순진한 ReAct 루프)는 평면적인 순서대로 동작합니다:
Observe → Think → Act → Observe → Think → Act …에이전트가 “생각”할 때는 사용자에게 무엇을 말할지, 장기적인 전략은 무엇이어야 할지를 결정하려고 합니다. LLM은 자동회귀 모델이기 때문에, 즉각적인 컨텍스트(마지막 사용자 발화 또는 마지막 API 오류)가 주의 집중을 압도적으로 차지합니다.
에이전트의 유일한 “플래너”가 실제 작업을 수행하고 있는 동일한 루프라면, 두 가지 실패 모드가 나타납니다:
- 얕은 탐색 – 에이전트가 즉각적인 작업에 지나치게 집중해 새로운 하위 목표를 전혀 발견하지 못합니다.
- 통제 불능 탐색 – 에이전트가 원래 목표를 완전히 잊어버리고 끝내지 못합니다.
Dual‑Process Architecture
Fast (System 1) Loop
- Reactive and low‑latency.
- Looks at the immediate context and executes the next tactical step.
- In an interview scenario, it simply asks the next question, decides whether to probe deeper, or transitions to a new topic.
- It does not consider the global strategy.
Deliberative (System 2) Loop
- Runs asynchronously in the background (e.g., every k turns).
- Examines the entire interaction history, zooms out, and optimizes the overarching trajectory.
- Operates by simulating rollouts: it generates hypothetical futures, scores them against a utility function (e.g., maximize new information while minimizing token cost), and updates a shared “Agenda” that System 1 reads from.
SparkMe: 사례 연구
최근 스탠포드 논문, SparkMe: Adaptive Semi‑Structured Interviewing for Qualitative Insight Discovery (arXiv:2602.21136)는 이 아키텍처를 실제로 구현한 사례를 보여줍니다. 저자들은 에이전트를 두 개의 뚜렷한 시스템으로 나누었습니다:
- 빠른 반응 루프 – 질문을 제시하고 즉각적인 탐색을 처리합니다.
- 심사숙고 플래너 – 주기적으로 인터뷰 경로를 시뮬레이션하고, 높은 효용성을 가진 경로를 선택하며, 의제(agenda)를 업데이트합니다.
논문 링크:
실행과 계획을 분리하는 이점
| Control Knob | Description |
|---|---|
| Planning frequency | 플래너를 n 단계마다 실행합니다(예: 5턴마다). 매 마이크로‑액션마다 깊은 “Chain of Thought”를 강제하는 것보다 연산량을 절감할 수 있습니다. |
| Look‑ahead horizon | 미래에 시뮬레이션할 단계 수를 정의합니다(예: 3단계 앞까지). |
| Optimization objective | 모호한 프롬프트 지시 대신 유틸리티 함수(정보 획득, 토큰 비용, 사용자 만족도 등)를 명시적으로 인코딩합니다. |
요약
- 한 번에 완벽하게 작동해야 하는 단일 “God Prompt”를 만들려고 애쓰는 것을 멈추고, 동시에 4‑D 체스를 두는 것을 그만두세요.
- 빠른 에이전트가 행동을 실행하도록 두고, 느린 에이전트가 미래를 시뮬레이션하도록 하세요.
If you enjoy architecture notes like this, you can follow the Telegram channel: