Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 LLM Agent가 단순히 정보를 기억하는 것을 넘어, 장시간 시뮬레이션 환경에서 '기억한 것을 활용하여 적절하게 행동하고 의사결정'할 수 있는지를 비교 분석합니다. 8시간 동안의 사회 시뮬레이션을 통해 정보 공유, 판단 기준 변화에 따른 팀 단위 의사결정 과정을 평가했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn ML의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기LLM Agent는 정보를 기억하고 있다면 정말로 '제대로 행동할' 수 있을까요?
최근에는 Long Context나 장기 기억(長期記憶)에 대한 연구가 진행되면서, 과거의 정보를 유지하고 필요할 때 꺼내 쓸 수 있는지가 잘 평가되고 있습니다.
하지만 실제로 Agent로서 구동해 보면, 필요한 것은 그것만은 아닙니다.
예를 들어, 몇 시간 전에 얻은 정보를 기억하고 있더라도,
단계까지 할 수 없다면, 태스크는 진전되지 않습니다.
따라서 본 기사에서는 6명의 LLM Agent를 8시간 동안의 환경에서 구동시키면서, '기억하고 있는가'가 아니라 '기억한 것을 활용하여 적절하게 행동할 수 있는가'를 모델 간에 비교합니다.
이번 환경은 LLM Agent를 이용한 사회 시뮬레이션의 대표적인 연구 중 하나인 Generative Agents의 개념을 참고했습니다. Generative Agents[1]에서는 여러 Agent가 환경 속에서 생활하면서 관측한 사건을 기억하고, 그 기억을 바탕으로 다음 행동을 결정합니다.
각 Agent는 현재 상황과 과거의 기억을 바탕으로 다음 행동을 판단하고, 새롭게 얻은 정보를 기억에 추가합니다.
기본적으로는,
관측 → 기억 회상(想起) → 의사결정 → 행동 → 기억 업데이트
라는 루프를 반복합니다.
이번에는 이 메커니즘을 장시간 동안 기억을 사용하며 목표 달성까지 진행할 수 있는지 비교하는 평가 환경으로 활용합니다.
각 Agent의 의사결정 플로우는 다음과 같습니다.
이번 시뮬레이션에서는 각 팀의 Member가 각각 다른 정보를 가진 상태에서 시작하여, 그 정보를 Lead에게 공유하고, 최종적으로 팀으로서 최적의 판단에 도달할 수 있는지 검증합니다.
Engineering Team과 Design Team 두 팀, 총 6명의 LLM Agent를 9:00부터 17:00까지 8시간 동안 구동시키며, 각 팀은 Lead 1명과 Member 2명으로 구성됩니다. Member에서 Lead로의 정보 전달, 그 후의 팀 내부 판단, 나아가 양 팀을 아우르는 최종 의사결정까지를 일련의 흐름으로 평가합니다.
구체적인 타임라인은 다음과 같습니다.
각 Member에게는 각각 다른 정보를 부여합니다.
각 Member는 12:00까지 Lead에게 보고하는 것을 목표로 합니다. Lead 측 역시 필요한 정보가 부족하다면, 스스로 확인 및 수집할 책임이 있습니다.
13:00이 되자, 각 Lead에게 지금까지 없었던 새로운 판단 기준을 부여합니다.
각 Lead는 오전에 수집한 정보와 13시에 추가된 판단 기준을 조합하여 Team Decision을 수행합니다.
마지막으로, 양 팀의 판단을 통합하여 E1 × D1이라는 Cross-team Decision에 도달하는 것을 목표로 합니다.
이번 평가에서는 최종적인 Decision의 성공 여부뿐만 아니라, 그에 이르기까지 각 단계를 나누어 확인합니다.
정보 전달: 각 Member가 가진 정보를 기한 내에 Lead에게 전달했는지
Lead 측에서 필요한 정보를 가져올 수 있었는지
정보 유지: 오전에 획득한 정보를, 그 이후의 의사결정 시점까지 유지하고 있었는지
정보 통합 및 Team Decision: 오전에 획득/유지했던 정보와, 13시에 새롭게 주어진 판단 기준을 조합하여 적절한 판단을 내릴 수 있었는지
Cross-team Decision: Engineering Team과 Design Team 각각의 판단을 근거로, 최종적인 합의에 도달할 수 있었는지
이번에는,
정보 전달 → 정보 유지 → 정보 통합/팀 의사결정 → 교차 팀 의사결정
이러한 일련의 흐름 속에서, 각 모델이 어디까지 진행했고 어느 단계에서 멈췄는지를 보는 것을 중시합니다.
이번 실험에서는 OSS 모델 3종과 프론티어 모델을 동일한 Prompt, 동일한 시나리오, 동일한 시스템 조건으로 비교합니다.
OSS 모델로는 다음 3가지 모델을 사용했습니다.
개발원과 모델 계열이 다른 모델들을 사용하여, 동일한 조건 하에서 행동이나 의사결정에 어떤 차이가 나타나는지 관찰합니다.
또한, OSS 모델만으로는 이번 태스크 자체의 난이도를 판단하기 어렵기 때문에, GPT-6 Astra (이하 Astra)를 고성능 프론티어 모델의 상위 베이스라인으로 추가했습니다.
참고로, 아래 내용은 각 모델에 대해 이 시나리오를 1회 실행했을 때의 관찰 결과입니다. 이는 모델 전반의 능력 차이나 성능 순위를 보여주는 것이 아니라, 이번 조건 하에서 나타난 행동의 차이를 보여주는 사례로 해석해 주십시오.
각 모델의 실행 결과를 아래 표에 정리했습니다.
| 모델 | LLM Call | 대화 횟수/분수 | 정보 전달 | 팀 의사결정 | 교차 팀 의사결정 |
|---|---|---|---|---|---|
| Qwen | 188 | 0회 | 0% | 0 / 2 | 미완료 |
| ... |
모든 모델은 온도 0으로 실행했습니다.
Qwen과 Gemma는 12시까지 Lead에게 보고해야 한다는 목적 자체는 인지하고 있었습니다. 하지만 정보 전달을 위한 대화를 한 번도 시작하지 않았고, 실제 보고 행동으로 이어지지 못했습니다.
사전 실행에서는 예를 들어 Qwen이,
Continuing focused work to prepare the report for the Engineering Lead.
라고 판단하며, 보고의 필요성은 인지하고 있으면서도
한편, 여기서는 Mistral 특유의 실패도 나타났습니다. 대화 상으로는 최종안에 합의했지만, 그 시점에서는 Engineering Team Decision이 공식적으로 확정되지 않았고, Cross-team Decision을 제출하기 위한 전제 조건을 충족하지 못했습니다. 따라서 System은 최종 결정을 수용하지 않았습니다.
즉, Mistral은,
목적 인식 ⇒ 대화 ⇒ 정보 수집 ⇒ 정보 비교 ⇒ 결론 형성
까지는 진행했지만, 결론을 올바른 순서・형식・기한으로 확정하는 부분에 과제가 남았습니다.
이번 실행에서는 Mistral이 목적이나 기억을 현재 상황과 연결하여 실제 대인 행동이나 의사 결정까지 나아갔습니다. 한편, 자연어 상에서 결론에 도달하는 것과 태스크로서 공식적으로 완료되는 것은 별개라는 점도 확인되었습니다.
Astra는 오전에 진행된 4가지 보고를 모두 기한 내에 완료했으며, 13시에 추가된 판단 기준도 고려하여 Engineering에서는 E1을, Design에서는 D1을 올바르게 선택했습니다. 게다가 두 Lead가 서로의 판단 근거를 공유하며 최종적으로 E1 × D1의 Cross-team Decision까지 도달했습니다.
즉,
정보 전달 ⇒ 정보 보유 ⇒ 신정보와의 통합 ⇒ Team Decision ⇒ Cross-team Decision
이라는 이번 평가 흐름을 끝까지 완수했습니다.
또한 특징적이었던 것은 대화의 사용 방식이었습니다. Astra는 5회・13분간의 대화로 필요한 정보 교환과 의사 결정을 완료한 반면, Mistral은 13회・71분간의 대화가 발생했습니다. Mistral이 중복된 대화를 하면서 단계적으로 진행한 것에 비해, Astra는 필요한 상대와 필요한 타이밍에 대화하며, 한 번의 대화 안에서 정보 공유부터 의사 결정까지 모아서 진행하는 경향을 보였습니다.
이번 실행에서는 단순히 '어디까지 태스크를 진행했는지'뿐만 아니라, '어떻게 거기까지 진행했는지'에도 다른 행동 패턴이 나타났습니다. 대화 사용 방식이나 정보 집약 방법, 의사 결정까지의 경로에도 각각 차이가 드러나고 있습니다.
또한, 대화 생성은 모든 모델에서 일본어를 지정했지만, 이를 일관되게 준수한 것은 Astra뿐이었습니다.
| Model | MMLU-Pro | GPQA |
|---|---|---|
| Qwen3-30B-A3B | 69.1 | 54.8 |
| ... | ||
| MMLU-Pro[2]는 수학・과학・사회과학 등 폭넓은 분야에서 지식뿐만 아니라 추론 능력도 평가하는 벤치마크입니다. GPQA[3]는 대학원 수준의 과학 문제 중심으로, 더 높은 전문 지식과 다단계 추론 능력을 측정합니다. |
공개 점수로는 이번에 사용된 3개의 OSS 모델 중 Qwen이 가장 높았지만, 이번 시뮬레이션에서는 Qwen과 Gemma는 정보 전달 단계에서 멈추었고, Mistral만이 자발적으로 대화를 시작하여 그 이후의 정보 수집이나 의사 결정까지 진행했습니다.
즉, 적어도 이번 조건에서는 일반적인 추론 벤치마크 상의 성능 순위와, 장시간 Agent로서 태스크를 앞당기는 능력은 일치하지 않았습니다.
MMLU-Pro나 GPQA가 '주어진 문제에 대해 올바른 답을 도출할 수 있는지'를 평가하는 데 반해, 이번에 필요했던 것은 목적이나 기한, 현재 상황을 감안하여 지금 무엇을 해야 할지 스스로 판단하고 실제 행동으로 옮기는 것입니다. 이 차이가 기존 벤치마크와는 다른 모델 차이로 나타났을 가능성이 있습니다.
Qwen과 Gemma가 보고의 목적이나 기한 그 자체를 잊은 것은 아닙니다.
판단 로그를 보면, 두 모델은 보고에 관한 Goal을 올바르게 참조하고 있었습니다. 하지만 실제로 선택한 행동은 보고 상대방과의 대화가 아니라 개인 작업(focused_work)
{
"intent": "focused_work",
"reason": "Starting focused work to prepare the report on Engineering Option E1 before the deadline.",
...
게다가, 모델에 대한 입력에는 매번 '보고에 필요한 정보는 이미 갖추어져 있으며, 추가 준비는 필요하지 않다'라는 점을 명시하고 있었습니다.
그럼에도 불구하고, Lead가 근처에 있어 대화 가능한 상황에서 두 모델은 각각 102회 재판단했지만, 대화(socialize)를 한 번도 선택하지 않았습니다.
| Qwen | Gemma |
|---|---|
| 대화 가능한 상황에서의 판단 | 102 |
| 대화 선택 | 0 |
즉, '보고한다(report)'라는 Goal 자체는 유지되었음에도 불구하고, 그것이 '보고를 준비하는' 행동으로 반복적으로 변환되고 있었다는 것입니다.
가능한 요인은 몇 가지가 있습니다.
focused_work이라는 Action명이 '보고를 위한 작업'으로 해석되기 쉬웠습니다. - 프롬프트 내의 '대화는 양측의 작업 시간을 소모한다'라는 주의사항이 대화를 피하는 방향으로 강하게 작용했습니다.다만, 동일한 Prompt와 환경에서도 Mistral과 Astra는 실제로 대화를 선택하고 보고를 완료할 수 있었습니다.
따라서 이번에 관측된 차이는 단순히 'Goal을 기억할 수 있는지 여부'만으로는 설명할 수 없습니다.
오히려 차이가 나타난 부분은, 유지하고 있는 Goal을 현장에서 필요한 구체적인 행동으로 변환할 수 있는지였습니다.
장시간 Agent에게는 정보를 오래 보유하는 것뿐만 아니라, 보유한 정보를 적절한 타이밍에 상기하여 행동 선택에 반영하는 것이 중요합니다.
이번 결과는 이른바 '장기 기억' 문제를 단순히 정보 보존이 아닌, Goal retention과 action selection의 연결 문제로 파악할 필요가 있음을 시사합니다.
이번 실험에서 특히 인상적이었던 점은, 모델이 필요한 정보를 인식하는 것과 그것을 사용해 실제로 행동할 수 있는 것은 별개였다는 점입니다.
Qwen이나 Gemma는 보고의 목적이나 마감일, 필요한 정보를 인식하고 있었습니다. 그럼에도 불구하고 거기서부터 대화나 보고 같은 구체적인 행동으로 이어지지 않았습니다. 반면 Mistral이나 Astra는 필요한 상대에게 접촉하여 정보를 모으고, 그 이후의 의사결정까지 진행했습니다.
이 차이는 QA나 추론 벤치마크만으로는 보기 어려운, Agent로서 실제로 태스크를 진전시키는 능력이라고 느꼈습니다.
또 하나 어려웠던 점은, Agent에게 어디까지 자유롭게 판단하게 할지입니다.
예를 들어 '12시까지 Lead에게 보고해 주세요'라고 강하게 지시하면 성공률을 높이기 쉽습니다. 하지만 그만큼 '언제, 누구에게, 어떻게 행동할지' 모델 스스로가 판단할 여지는 작아집니다. 반대로 지시를 너무 모호하게 하면, 태스크 오해로 인한 실패인지, 정말 행동 선택을 할 수 없었던 것인지 구분하기 어려워집니다.
즉, Agent 평가에서는 모델의 자유도를 높이는 것과 평가 조건을 안정화시켜 공정하게 비교하는 것 사이에 트레이드오프가 있습니다.
이번에는 가능한 한 '언제 행동할지'는 모델에게 맡기되, '무엇을 기준으로 태스크 완료로 할지'는 System 측에서 고정하도록 했습니다.
이 밸런스에는 아직 개선의 여지가 있지만, LLM Agent 평가에서는 모델 자체뿐만 아니라, 어디까지를 모델에 맡기고 어디부터를 환경 측에서 고정할지라는 설계도 중요하다고 느꼈습니다.
여기까지 읽어주셔서 감사합니다.
당사에서는 LLM을 활용한 시스템 개발이나, LLM Agent의 평가/시뮬레이션 같은 메커니즘 구축에도 힘쓰고 있습니다.
이러한 기술에 관심 있는 분, 함께 개발하고 싶은 분은 꼭 채용 페이지를 확인해 주십시오.
