뜨거운 감자: 대부분의 AI 에이전트 팀은 사실 '컨텍스트 엔지니어링' 팀이다
Hot take: most AI agent teams are secretly just “context engineering” teams
핵심 요약
AI 에이전트 개발의 핵심은 모델 자체가 아니라 복잡한 인프라와 컨텍스트 관리라는 지적.
- 인프라 복잡성 — LLM보다 벡터 DB, 캐시, 오케스트레이션 등 주변 인프라 구축에 더 많은 시간이 소요됨.
- 컨텍스트 엔지니어링 — 에이전트의 기억, 권한, 감사 로그 등을 관리하는 시스템 구축이 본질적인 작업이 됨.
- 기존 스택의 한계 — 검색/검색 아키텍처를 재활용하는 방식은 장기 실행 자율 에이전트 확장에 부적합함.
- 운영의 중요성 — 인간의 개입이 줄어든 에이전트 환경에서는 결정론적이고 감사 가능한 시스템 설계가 필수적임.
AI 에이전트를 다루는 시간이 길어질수록, 진짜 문제는 LLM이 아니라는 생각이 점점 강해집니다.
문제는 그 주변의 엉망진창인 인프라입니다.
오늘날 진지하게 에이전트를 다루는 스택은 결국 다음과 같은 형태가 됩니다:
LLM + 벡터 DB + 캐시 + 검색 파이프라인 + 커넥터 + 권한 + 메모리 계층 + 관측 가능성 + 감사 로그 + 오케스트레이션 글루(glue)
그리고 팀들은 몇 달 동안 다음과 같은 질문에 답하느라 시간을 보냅니다:
- 에이전트가 지금 정확히 무엇을 알고 있는가?
- 왜 이것을 검색했는가?
- 메모리가 최신 상태인가?
- 감사가 가능한가?
- 왜 갑자기 지연 시간이 끔찍해졌는가?
- 엔터프라이즈 환경 내에 어떻게 배포하는가?
어느 순간, 팀들이 더 이상 에이전트를 만드는 게 아니라는 느낌이 듭니다.
그들은 분산 컨텍스트 엔지니어링 시스템을 구축하고 있는 것입니다.
흥미로운 점은 현재 스택의 상당 부분이 장기 실행 자율 에이전트를 위해 근본적으로 설계된 것이 아니라, 검색/검색 아키텍처에서 물려받은 것처럼 보인다는 것입니다.
어딘가에 추상화가 빠져 있는 것 같습니다:
에이전트의 메모리, 컨텍스트, 권한, 그리고 행동이 여러 도구에 걸쳐 흩어져 있는 대신, 이들이 함께 공존할 수 있는 적절한 시스템 말입니다.
저희는 Areev AI에서 이 아이디어를 탐구하고 있으며, 이 개념을 중심으로 '에이전트 하네스 데이터베이스(agent harness database)'라고 부르는 초기 버전을 구축했습니다. 아직 초기 단계이지만, 현재의 스택으로는 프로덕션급 에이전트로 깔끔하게 확장되지 않을 것 같다는 느낌이 점점 강해집니다.
에이전트 시스템을 구축 중인 다른 분들도 같은 문제를 겪고 있는지 궁금합니다:
- 현재 스택에서 가장 엉망인 부분은 무엇인가요?
- 보통 어디서 문제가 발생하나요?
- 빠져 있는 인프라 계층이 무엇이라고 생각하시나요?
