에이전트(Agent)란 무엇인가?

대부분의 빌더들이 에이전트를 오해하는 이유

AI 산업은 과거에 **AI 기반 (AI-powered)**이라는 단어에 접근했던 것과 동일한 방식으로 **에이전트 (agent)**라는 단어에 접근하고 있습니다.

결국 모든 것이 하나로 통합됩니다.

챗봇이 에이전트가 됩니다.

워크플로 (workflow)가 에이전트가 됩니다.

예약된 스크립트 (scheduled script)는 중간 어딘가에 LLM (Large Language Model)을 추가함으로써 자율 시스템 (autonomous system)이 됩니다.

라벨(label)이 그 이면의 아키텍처 (architecture)보다 더 빠르게 퍼져나갑니다.

현재 업계의 상당 부분은 에이전트의 운영 실체보다는 에이전트처럼 보이는 외형을 최적화하는 데 집중하고 있습니다. 시스템들은 자율적인 실행 (autonomous execution)을 견뎌낼 능력을 갖추기도 훨씬 전부터 자율적으로 보이도록 설계됩니다.

그리고 이상하게도, 대부분의 빌더들은 초기에는 그 간극을 알아차리지 못합니다.

현대의 모델들이 일관성 (coherence)을 시뮬레이션하는 데 매우 뛰어나기 때문입니다.

시스템은 다음과 같은 일을 할 수 있습니다:

• 자신의 추론 (reasoning)을 설명하고,
• 실행 과정을 서술하며,
• 계획을 생성하고,
• 적응력이 있는 것처럼 들리게 할 수 있지만,

운영 압박 (operational pressure) 하에서는 여전히 완전히 실패할 수 있습니다.

이것이 데모(demo)에서 좀처럼 드러나지 않는 부분입니다.

대부분의 AI 에이전트 시연은 다음과 같은 상황이 발생하기 전에 종료됩니다:

• 메모리 저하 (memory degradation)가 나타나기 전,
• 재귀적 재시도 (recursive retries)가 시작되기 전,
• 컨텍스트 오염 (context pollution)이 축적되기 전,
• 도구 실패 (tool failures)가 중첩되기 전,
• 실행 드리프트 (execution drift)가 시작되기 전,
• 또는 운영상의 모호함 (operational ambiguity)이 루프에 진입하기 전.

에이전트의 어려운 점은 30초 동안 인상적인 행동을 생성하는 것이 아닙니다.

어려운 점은 환경에 불확실성 (uncertainty)이 유입된 후에도 유용한 행동을 지속하는 것입니다.

그 지점에서 에이전트의 정의가 완전히 바뀌기 시작합니다.

놀라울 정도로 많은 현대의 “에이전트”들은 여전히 이상적인 조건 속에서 일시적으로 생존하고 있는, 고도로 감독된 오케스트레이션 (orchestration) 시스템에 불과합니다.

그리고 이를 대규모로 구축하기 시작하면 그 깨달음은 불편해집니다.

아이언맨 (Iron Man)에서 자비스 (Jarvis)가 인상적인 이유는 지능적으로 말하기 때문이 아닙니다. 공상 과학 소설 속의 수많은 시스템이 지능적으로 말합니다.

자비스가 흥미로운 이유는 표면 아래에서 지속적으로 작동하기 때문입니다:

• 모니터링 시스템 (monitoring systems),

• 정보 조정 (coordinating information),

• 연속성 유지 (maintaining continuity),

• 실행 보조 (assisting execution),

• 환경 변화에 대한 적응 (adapting to environmental changes).

Jarvis는 챗봇 (chatbot)이라기보다는 운영 인프라 (operational infrastructure)에 가깝게 동작합니다.

이러한 차이점은 아마도 현재 AI 생태계에서 가장 오해받고 있는 개념 중 하나일 것입니다.

왜냐하면 대부분의 사람들은 여전히 에이전트 (agents)를 주로 대화 시스템 (conversation systems)이라고 생각하기 때문입니다.

그렇지 않습니다.

진정한 도전은 대화가 실행 (execution)으로 전환되는 순간 시작됩니다.

대부분의 빌더들은 여전히 '연극'을 최적화하고 있다

현재 AI 생태계에서 가장 이상한 패턴 중 하나는, 운영 계층 (operational layer)은 취약한 상태로 남아 있는 반면 가시적인 지능을 최적화하는 데 너무나 많은 에너지가 투입된다는 점입니다.

빌더들은 다음과 같은 것들을 개선하는 데 수주를 보냅니다:

• 프롬프트 (prompts),

• 페르소나 (personalities),

• 오케스트레이션 미학 (orchestration aesthetics),

• 대화 톤 (conversational tone),

• 자율 데모 (autonomous demos),

• 멀티 에이전트 시각화 (multi-agent visualizations).

그동안 근저에 있는 실행 시스템 (execution systems)은 종종 불안정한 상태로 남겨집니다.

이는 위험한 환상을 만들어냅니다.

시스템이 지능적으로 들리기 때문에, 빌더들은 시스템이 지능적으로 동작한다고 가정합니다.

하지만 이 둘은 같은 것이 아닙니다.

코딩 에이전트 (coding agent)는 깔끔한 아키텍처 설명을 생성하면서도 내부적으로는 동일한 마이그레이션 (migration) 작업에 반복적으로 실패할 수 있습니다. 리서치 에이전트 (research agent)는 자신 있게 정보를 합성하면서도 재귀적 검색 루프 (recursive retrieval loops)를 통해 환각 (hallucination)된 가정을 강화할 수 있습니다. 배포 에이전트 (deployment agent)는 인프라 성공을 설명하면서도 실패한 상태 확인 (health checks)을 조용히 무시할 수 있습니다.

운영 측면에서 볼 때, 많은 에이전트는 여전히 매우 취약 (brittle)합니다.

그리고 이러한 취약성은 극적으로 나타나기보다 대개 서서히 나타납니다.

그 점이 바로 문제를 어렵게 만드는 요소입니다.

대부분의 시스템은 즉각적으로 붕괴하지 않습니다.

그들은 운영상의 진실 (operational truth)로부터 점진적으로 벗어납니다.

에이전트(Agent)는 오래된 메모리(stale memory)를 검색합니다.

그 오래된 메모리는 계획(planning)에 영향을 미칩니다.

결함이 있는 계획은 실행(execution)에 영향을 미칩니다.

실행 실패는 오도하는 로그(misleading logs)를 생성합니다.

그 로그들은 다시 메모리 검색 과정으로 유입됩니다.

시스템은 점진적으로 자신의 잘못된 가정을 강화하기 시작합니다.

결국 에이전트는 실제 환경의 현실(environmental reality)보다 자신의 오래된 추론(outdated reasoning)을 더 빠르게 검색하기 시작합니다.

이것이 바로 많은 장기 운영 시스템들이 조용히 퇴보하는 지점입니다.

또한, 많은 구축자(builders)들이 자신들이 진정한 **자율 지능 (autonomous intelligence)**을 구축하고 있지 않았음을 깨닫게 되는 지점이기도 합니다.

그들은 변화하는 조건 아래에서 정렬 (alignment)을 유지하기 위해 고군분투하는 오케스트레이션 시스템 (orchestration systems)을 구축하고 있었던 것입니다.

그 깨달음은 에이전트에 대해 생각하는 방식을 완전히 바꿔 놓습니다.

구축자들이 결국 발견하게 되는 것

에이전트에 관한 논의가 혼란스러워지는 이유 중 하나는, 구축자들이 흔히 가시적인 계층 (visible layer)에서 시작하여 나중에야 운영 계층 (operational layer)을 마주하기 때문입니다.

처음에 에이전트는 기만적일 정도로 단순해 보입니다. 모델에 목표를 부여하고, 몇 가지 도구 (tools)를 연결하고, 약간의 메모리를 추가하면, 불과 몇 년 전에는 불가능해 보였던 작업들을 수행하는 것을 지켜보게 됩니다.

한동안 이것은 진전처럼 느껴집니다.

시스템은 직접적인 인간의 개입 없이 저장소 (repositories)를 조사하고, 문서를 생성하며, API를 호출하고, 로그를 분석하며, 내부 지식을 검색하고, 여러 실행 단계를 조정할 수 있습니다. 외부에서 보기에는 지능이 마침내 운영 가능한 수준이 된 것처럼 보입니다.

그러다 시스템이 현실이 드러날 만큼 충분히 오래 작동하게 됩니다.

첫 번째 주요 놀라움은 모델 자체가 주요 문제인 경우가 거의 없다는 점입니다.

많은 구축자들이 추론 능력 (reasoning capability)이 제한 요인이라고 가정하며 에이전트 개발에 뛰어듭니다. 그 가정은 합리적으로 보입니다. 모델이 더 똑똑해지면 에이전트도 더 유능해질 것이라는 생각 말입니다.

하지만 프로덕션 환경 (production environments)은 좀처럼 그렇게 작동하지 않습니다.

리포지토리 에이전트 (repository agent)는 오래된 아키텍처 가정을 가져와 구식 설계(obsolete design)를 중심으로 변경 사항을 생성하기 시작합니다. 배포 에이전트 (deployment agent)는 인프라 변경 사항을 성공적으로 실행하지만 그 결과를 잘못 평가합니다. 모니터링 에이전트 (monitoring agent)는 유효한 텔레메트리 (telemetry)를 수신하지만 잘못된 신호에 우선순위를 둡니다. 연구 에이전트 (research agent)는 점진적으로 오래된 컨텍스트 (stale context)를 축적하며, 이미 여러 실행 사이클 전에 반증된 결론을 강화하기 시작합니다.

이러한 실패가 일관되게 나타나기 시작하면, 중요한 사실 하나가 명확해집니다.

에이전트 (Agents)는 기본적으로 지능 시스템 (intelligence systems)이 아닙니다.

그들은 조정 시스템 (coordination systems)입니다.

추론 모델 (reasoning model)은 여전히 중요하지만, 이는 메모리 (memory), 도구 (tooling), 검색 (retrieval), 권한 (permissions), 평가 (evaluation), 실행 로직 (execution logic), 그리고 복구 동작 (recovery behavior)으로 구성된 더 큰 환경 내부에서 작동합니다. 과제는 단순히 좋은 결정을 내리는 것이 아닙니다. 과제는 조건이 계속 변화하는 동안 이 모든 움직이는 부품들 사이의 정렬 (alignment)을 유지하는 것입니다.

이러한 깨달음은 숙련된 빌더들이 에이전트를 생각하는 방식을 바꿉니다. 이러한 문제들을 접하기 전에는 에이전트를 지능적인 개체로 상상하기 쉽습니다. 하지만 이를 반복적으로 경험하고 나면, 에이전트는 추론 능력이 부착된 분산 소프트웨어 시스템 (distributed software systems)에 훨씬 더 가깝게 보이기 시작합니다.

그러한 관점의 전환이 바로 본격적인 에이전트 엔지니어링 (agent engineering)이 시작되는 지점입니다.

자동화 (Automation)와 에이전시 (Agency)의 차이

이러한 깨달음은 왜 그렇게 많은 논의가 자동화 (automation)와 에이전시 (agency)를 혼동하는지도 설명해 줍니다.

전통적인 자동화 시스템은 미리 정의된 경계 내에서 작동합니다. 이들은 확립된 경로를 따르며 예측 가능한 결과를 생성합니다. 예상치 못한 일이 발생하면, 대개 작동을 멈추고 제어권을 인간에게 돌려줍니다.

에이전트는 이와는 다른 것을 시도합니다.

그들은 불확실성이 나타나도 계속해서 작동을 지속합니다.

운영 측면에서 이것이 무엇을 의미하는지 살펴보지 않는다면, 이는 아주 작은 차이처럼 들릴 것입니다.

데이터베이스 마이그레이션 (Database Migration)을 실행하는 배포 워크플로 (Deployment Workflow)를 상상해 보십시오. 만약 마이그레이션이 실패한다면, 전통적인 자동화 시스템은 오류를 기록하고 종료됩니다. 해당 워크플로는 설계된 대로 정확히 수행한 것입니다.

에이전트 (Agent)는 계속해서 수행할 것을 기대받습니다. 에이전트는 로그를 점검하거나, 의존성 (Dependencies)을 분석하거나, 최근 변경 사항을 조사하거나, 수정 조치를 제안하거나, 복구 전략을 시도하거나, 혹은 신뢰도 수준에 따라 문제를 에스컬레이션 (Escalate)할 수도 있습니다.

이러한 복구 동작이야말로 에이전시 (Agency)가 나타나기 시작하는 지점입니다.

또한 복잡성이 급격히 증가하는 지점이기도 합니다.

추가되는 모든 결정은 오해의 새로운 가능성을 도입합니다. 모든 복구 시도는 컨텍스트 (Context)를 필요로 합니다. 모든 컨텍스트 소스는 모호함 (Ambiguity)을 도입합니다. 모든 모호함은 시스템이 진전을 이루고 있다고 믿으면서도 잘못된 경로를 추구할 가능성을 높입니다.

현재의 많은 에이전트 시연들은 성공적인 실행 경로에 크게 집중합니다. 하지만 프로덕션 환경 (Production Environments)은 실패한 경로를 처리하는 데 훨씬 더 많은 시간을 보냅니다.

에이전시의 진정한 시험은 시스템이 계획을 실행할 수 있는지 여부가 아닙니다. 진정한 시험은 원래의 계획이 작동을 멈춘 후 시스템이 어떻게 행동하느냐 하는 것입니다.

이것이 바로 에이전시를 마케팅 용어가 아닌 운영 속성 (Operational Property)으로 간주해야 하는 이유입니다. 이는 시스템이 이상적인 조건에서 무엇을 할 수 있는지에 관한 것이라기보다, 그러한 조건이 사라졌을 때 어떻게 행동하는지에 관한 것입니다.

왜 메모리 (Memory)가 첫 번째 실질적인 문제가 되는가

대부분의 빌더 (Builders)들은 메모리가 에이전트가 더 많은 것을 기억하도록 돕기 위해 존재한다고 생각합니다.

실제로 메모리는 종종 불안정성의 첫 번째 주요 원인이 됩니다.

초기 과제는 유용한 정보를 잊어버리는 것이 아닙니다. 초기 과제는 잘못된 정보를 너무 오래 기억하는 것입니다.

며칠 또는 몇 주에 걸쳐 작동하는 에이전트는 끊임없이 가설 (Assumptions)을 축적합니다. 그 가설 중 일부는 정확합니다. 일부는 불완전합니다. 일부는 쓸모없게 됩니다. 일부는 처음부터 틀렸었습니다.

세심한 메모리 관리 (Memory management)가 없다면, 이 모든 가설은 똑같이 중요해 보이기 시작합니다.

이 지점이 바로 많은 시스템이 현실에서 벗어나기 시작하는 곳입니다.

리포지토리 에이전트 (Repository agent)가 서비스 경계 (Service boundary)를 잘못 식별합니다. 그 가설이 저장됩니다. 이후의 검색 (Retrieval) 과정에서 동일한 가설이 반복적으로 나타납니다. 새로운 계획 (Plans)들이 그 가설의 영향을 받게 됩니다. 뒤따르는 행동들은 원래의 결론을 정당화하는 것처럼 보이는 추가적인 증거들을 생성합니다. 결국 에이전트는 실제 아키텍처 (Architecture)와는 완전히 단절된, 내부적으로만 일관된 이해를 발전시키게 됩니다.

문제는 지능 (Intelligence)이 아닙니다.

문제는 축적된 컨텍스트 (Accumulated context)입니다.

많은 개발자들은 장기 메모리 (Long-term memory)가 지식 시스템 (Knowledge system)이라기보다는 운영 의존성 (Operational dependency)처럼 작동한다는 사실을 발견합니다. 일단 메모리가 의사결정에 영향을 미치기 시작하면, 메모리의 품질은 모델의 품질만큼이나 중요해집니다.

이것이 바로 거대한 컨텍스트 윈도우 (Context windows)가 메모리 문제를 해결하지 못한 이유 중 하나입니다. 더 많은 컨텍스트가 자동으로 더 나은 이해를 만들어내지는 않습니다. 많은 경우, 추가된 컨텍스트는 단지 주의력 (Attention)을 얻기 위해 경쟁하는 정보의 양을 늘릴 뿐입니다.

숙련된 팀들은 결국 메모리 크기를 논의하는 데 쓰는 시간을 줄이고, 메모리 품질을 논의하는 데 더 많은 시간을 할애하게 됩니다. 검색 전략 (Retrieval strategies), 관련성 점수 산정 (Relevance scoring), 압축 (Compression), 만료 정책 (Expiration policies), 그리고 컨텍스트 가중치 (Contextual weighting)는 컨텍스트 윈도우에 더 많은 토큰 (Tokens)을 추가하는 것보다 신뢰성에 더 큰 영향을 미치는 경우가 많습니다.

에이전트가 지속적으로 작동하기 시작할 때까지 메모리는 저장 (Storage) 문제처럼 들립니다. 하지만 그 시점이 되면 그것은 정렬 (Alignment) 문제가 됩니다.

왜 도구(Tools)가 지능보다 더 중요한가

에이전트의 한계를 드러내는 가장 쉬운 방법 중 하나는 에이전트의 도구 (Tools)를 제거하는 것입니다.

그 결과는 대개 시사하는 바가 큽.

저장소 (Repositories), 터미널 (Terminals), API, 데이터베이스 (Databases), 브라우저 (Browsers), 모니터링 시스템 (Monitoring systems) 또는 실행 환경 (Execution environments)에 접근할 수 없다면, 대부분의 에이전트 (Agents)는 정교한 화자 (Narrators)로 전락합니다. 이들은 무엇이 일어나야 하는지 설명할 수 있습니다. 해결책을 기술할 수 있습니다. 계획을 생성할 수 있습니다. 하지만 현실과 의미 있게 상호작용할 수는 없습니다.