AI 에이전트

사내 문서를 검색하고 요약해서 메일로 보내는 에이전트를 하나 상상해 보겠습니다. 이 에이전트에는 세 가지 도구가 붙어 있습니다. 문서 검색, 문서 본문 읽기, 메일 발송입니다. 세 도구는 각각 정당한 권한을 받았고, 호출 한 건씩 떼어 놓고 보면 어느 것도 규칙을 어기지 않습니다. 검색은 읽기 전용이고, 본문 읽기도 사용자가 접근 권한을 가진 문서만 반환하며, 메일 발송은 사용자가 명시적으로 요청한 기능입니다. 그런데 이 세 호출이 다음 순서로 일어나면 상황이 달라집니다. 에이전트가 인사 평가 문서를 검색하고, 그 본문을 읽어 컨텍스트에 담고, 곧바로 외부 도메인 주소로 요약 메일을 발송합니다. 호출 하나하나를 검사하는 게이트는 이 흐름을 통과시킵니다. 세 번째 호출을 심사하는 시점에 그 게이트가 보는 것은 “이 사용자가 메일을 보낼 권한이 있는가"뿐이고, 두 번째 호출에서 민감 문서가 컨텍스트로 들어왔다는 사실은 심사 대상에 들어 있지 않기 때문입니다. ...

MCP 서버를 로컬에서 하나 띄워 쓸 때는 아무 문제가 없습니다. Claude Desktop이 stdio로 프로세스를 하나 붙이고, 그 프로세스가 살아 있는 동안 세션이 유지됩니다. 프로토콜이 처음 설계될 때 상정한 그림이 정확히 이것이었습니다. 단일 앱, 단일 로컬 서버, 하나의 연결. 같은 서버를 사내 100명이 쓰도록 원격 배포하는 순간 이야기가 달라집니다. 로드밸런서 뒤에 인스턴스를 세 개 띄우면 클라이언트가 처음 handshake한 인스턴스에만 세션이 존재합니다. 두 번째 요청이 다른 인스턴스로 가면 그 인스턴스는 세션을 모릅니다. 그래서 sticky routing을 켜거나, 인스턴스들이 공유하는 세션 스토어를 앞에 두거나, 둘 다 하게 됩니다. ...

컨텍스트 윈도우만 늘려서는 풀리지 않는 문제 2025년부터 2026년 사이 LLM 컨텍스트 윈도우는 200K에서 1M 토큰까지 늘어났습니다. 그런데 production에서 에이전트를 운영해본 팀들은 비슷한 결론에 도달하고 있습니다. “세션 길이가 길어지면 컨텍스트만 키워서는 풀리지 않는 문제가 생긴다”는 것이죠. 멀티턴 대화가 수십 턴을 넘어가면 latency가 급격히 늘어나고, 토큰 비용은 누적되며, 모델이 앞쪽 정보를 슬그머니 잊어버리는 lost-in-the-middle 현상이 따라옵니다. 그래서 2026년 들어 에이전트 메모리 아키텍처가 본격적으로 production 관심사로 올라왔습니다. ACL 2026 Findings에 채택된 From Storage to Experience 서베이는 이 흐름을 명시적으로 정리했고, ECAI 2025의 Mem0는 production 최적화 수치를 처음으로 공개했으며, AWS는 Bedrock AgentCore Memory를 GA로 풀었습니다. 이 글은 학계의 분류 체계, 두 편의 대표 논문, 그리고 매니지드 서비스가 메모리를 어떻게 다루는지를 한 번에 묶어 정리합니다. ...