LLM Agent

지난 몇 년간 LLM 애플리케이션의 보안 논의는 대체로 prompt injection에 집중되어 있었습니다. 신뢰되지 않은 텍스트가 모델의 지시 사항인 척 끼어드는 문제입니다. 그런데 이 논의의 전제 하나가 조용히 바뀌었습니다. 초기의 LLM 호출은 요청 하나가 끝나면 그 세션의 상태도 함께 사라지는 stateless 구조였지만, 지금의 에이전트는 대화·경험·선호를 세션 경계 너머로 저장하는 지속 메모리를 기본으로 갖추고 있습니다. 그런데 지속 메모리는 편의만 가져온 게 아닙니다. 새로운 attack surface도 함께 열렸습니다. Prompt injection의 payload는 응답이 끝나면 컨텍스트와 함께 사라집니다. 하지만 그 payload가 메모리 쓰기 한 번을 성공시키면, 원본 텍스트가 사라진 뒤에도 저장된 항목은 남습니다. 이 글에서는 이것을 “payload는 휘발되지만 쓰기 결과는 잔존한다"는 성질로 부르겠습니다. memory poisoning을 prompt injection과 따로 다뤄야 하는 것도 이 때문입니다. ...

컨텍스트 윈도우만 늘려서는 풀리지 않는 문제 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로 풀었습니다. 이 글은 학계의 분류 체계, 두 편의 대표 논문, 그리고 매니지드 서비스가 메모리를 어떻게 다루는지를 한 번에 묶어 정리합니다. ...