AI 에이전트란 무엇인가?

“에이전트란 무엇인가?”

저는 거의 매일 이 질문을 받습니다. LangChain에서 우리는 개발자들이 LLM (Large Language Model) 애플리케이션, 특히 추론 엔진 (reasoning engines) 역할을 하며 외부 데이터 및 계산 소스와 상호작용하는 애플리케이션을 구축할 수 있도록 돕는 도구들을 만듭니다. 여기에는 흔히 “에이전트 (agents)”라고 불리는 시스템들이 포함됩니다.

모두가 AI 에이전트가 무엇인지에 대해 조금씩 다른 정의를 가지고 있는 것 같습니다. 저의 정의는 아마 대부분의 정의보다 더 기술적일 것입니다:

💡

AI 에이전트란 LLM을 사용하여 애플리케이션의 제어 흐름 (control flow)을 결정하는 시스템입니다.

이 정의조차 완벽하지 않다는 점을 인정합니다. 사람들은 종종 에이전트를 고도로 발전되고, 자율적이며, 인간과 유사한 것으로 생각합니다. 하지만 LLM이 두 가지 서로 다른 경로 사이를 라우팅 (routing)하는 단순한 시스템은 어떨까요? 이는 저의 기술적 정의에는 부합하지만, 에이전트가 무엇을 할 수 있어야 하는지에 대한 일반적인 인식에는 부합하지 않습니다. 에이전트가 정확히 무엇인지 정의하기란 어렵습니다!

그렇기 때문에 저는 지난주 Andrew Ng의 트윗이 정말 마음에 들었습니다. 그는 트윗에서 “어떤 작업을 진정한 AI 에이전트로 포함하거나 제외할지를 두고 논쟁하기보다는, 시스템이 에이전트적 (agentic)일 수 있는 다양한 정도가 있음을 인정할 수 있다”라고 제안했습니다. 예를 들어 자율 주행 자동차 (autonomous vehicles)에 자율성의 단계가 있는 것처럼, AI 에이전트의 능력 또한 스펙트럼 (spectrum)으로 볼 수 있습니다. 저는 이 관점에 전적으로 동의하며, Andrew가 이를 멋지게 표현했다고 생각합니다. 앞으로 누군가 저에게 에이전트가 무엇인지 묻는다면, 저는 대신 대화의 주제를 무엇이 “에이전트적 (agentic)”인지를 논의하는 방향으로 돌릴 것입니다.

에이전트적(agentic)이라는 것은 무엇을 의미하는가?

저는 작년에 LLM 시스템에 관한 TED 강연을 했으며, LLM 애플리케이션에 존재하는 다양한 자율성 단계를 설명하기 위해 아래 슬라이드를 사용했습니다.

LLM이 시스템이 어떻게 행동할지를 더 많이 결정할수록, 그 시스템은 더 “에이전트적 (agentic)”입니다.

입력을 특정 다운스트림 워크플로우 (downstream workflow)로 라우팅하기 위해 LLM을 사용하는 것은 어느 정도의 “에이전트적 (agentic)” 행동을 포함합니다. 이는 위 다이어그램의 Router 카테고리에 해당할 것입니다.

만약 여러 단계의 라우팅 (routing) 단계를 수행하기 위해 여러 개의 LLM을 사용한다면 어떨까요? 이는 Router와 State Machine 사이의 어딘가에 위치할 것입니다.

만약 그 단계 중 하나가 계속 진행할지 아니면 종료할지를 결정하여, 결과적으로 시스템이 완료될 때까지 루프 (loop) 내에서 실행될 수 있도록 한다면 어떨까요? 그것은 State Machine에 해당할 것입니다.

만약 시스템이 도구 (tools)를 구축하고, 이를 기억하며, 이후의 단계에서 이를 활용한다면 어떨까요? 이는 Voyager 논문에서 구현된 방식과 유사하며, 매우 에이전트적 (agentic)이며, 더 높은 단계인 Autonomous Agent 카테고리에 속합니다.

이러한 "에이전트적 (agentic)"이라는 정의는 여전히 상당히 기술적입니다. 저는 LLM 시스템을 설계하고 설명할 때 유용하다고 생각하기 때문에, "에이전트적 (agentic)"이라는 보다 기술적인 정의를 선호합니다.

"에이전트적 (agentic)"이라는 개념이 왜 도움이 될까요?

모든 개념이 그렇듯, 왜 우리가 "에이전트적 (agentic)"이라는 개념을 굳이 필요로 하는지 질문해 볼 가치가 있습니다. 이것이 무엇을 도와줄까요?

시스템이 얼마나 에이전트적인지에 대한 개념을 갖는 것은 시스템을 구축하고, 실행하고, 상호작용하고, 평가하고, 심지어 모니터링하는 것을 포함한 개발 과정 전반에 걸쳐 의사결정을 내리는 데 가이드를 제공합니다.

시스템이 더 에이전트적일수록, 오케스트레이션 프레임워크 (orchestration framework)의 도움이 더 많이 필요합니다. 복잡한 에이전트적 시스템을 설계하고 있다면, 이러한 개념들을 생각할 수 있는 적절한 추상화 (abstractions)를 갖춘 프레임워크를 사용하는 것이 더 빠른 개발을 가능하게 합니다. 이 프레임워크는 분기 로직 (branching logic)과 사이클 (cycles)에 대한 일급 지원 (first-class support)을 갖추고 있어야 합니다.

시스템이 더 에이전트적일수록, 실행하기는 더 어려워집니다. 시스템은 점점 더 복잡해질 것이며, 완료하는 데 오랜 시간이 걸리는 작업들이 생겨날 것입니다. 이는 작업을 백그라운드 실행 (background runs)으로 돌리고 싶어질 것임을 의미합니다. 또한 이는 실행 도중 발생하는 모든 오류를 처리하기 위해 내구성이 있는 실행 (durable execution)이 필요함을 의미합니다.

시스템이 더 에이전트적(agentic)일수록, 실행되는 동안 시스템과 상호작용하고 싶은 욕구가 더 커질 것입니다. 수행되는 정확한 단계가 사전에 알려지지 않을 수 있기 때문에, 내부에서 무슨 일이 일어나고 있는지 관찰할 수 있는 능력이 필요할 것입니다. 또한 에이전트가 의도한 경로에서 벗어날 경우 이를 다시 궤도로 돌려놓기 위해, 특정 시점에 에이전트의 상태(state)나 지침(instructions)을 수정할 수 있는 능력도 필요할 것입니다.

시스템이 더 에이전트적일수록, 이러한 유형의 애플리케이션을 위해 구축된 평가 프레임워크(evaluation framework)를 더 원하게 될 것입니다. 무작위성(randomness)이 복리로 누적되기 때문에 평가(evals)를 여러 번 실행해야 할 것입니다. 최종 출력뿐만 아니라 에이전트가 얼마나 효율적으로 행동하는지 테스트하기 위해 중간 단계(intermediate steps)도 테스트할 수 있는 능력이 필요할 것입니다.

시스템이 더 에이전트적일수록, 새로운 유형의 모니터링 프레임워크를 더 원하게 될 것입니다. 에이전트가 취하는 모든 단계를 상세히 파헤쳐 볼 수 있는(drill down) 능력이 필요할 것입니다. 또한 에이전트가 취하는 단계를 기반으로 실행(runs)을 쿼리할 수 있는 능력도 필요할 것입니다.

시스템의 에이전트적 역량(agentic capabilities)의 스펙트럼을 이해하고 활용하면 개발 프로세스의 효율성과 견고함(robustness)을 향상할 수 있습니다.

에이전트적(Agentic)이라는 것은 새로운 것이다

제가 자주 생각하는 것 중 하나는 이 모든 열풍 속에서 실제로 새로운 것이 무엇인가 하는 점입니다. 사람들이 구축하고 있는 LLM 애플리케이션을 위해 새로운 툴링(tooling)과 새로운 인프라가 필요할까요? 아니면 LLM 이전 시대의 범용적인 도구와 인프라로도 충분할까요?

제 생각에는, 애플리케이션이 더 에이전트적일수록 새로운 툴링과 인프라를 갖추는 것이 더 중요합니다. 그것이 바로 에이전트의 구축, 실행 및 상호작용을 돕는 에이전트 오케스트레이터(agent orchestrator)인 LangGraph와, LLM 앱을 위한 테스트 및 관측성(observability) 플랫폼인 LangSmith를 구축하게 된 동기입니다. 우리가 에이전트적 스펙트럼을 더 멀리 이동함에 따라, 이를 지원하는 툴링 생태계 전체를 재구상해야 합니다.