🤖
0 in / 0 out / 0 total tokens
핫 토픽
GateMem: 공유 메모리 에이전트의 권한 문제를 벤치마크하다
여러 사용자가 하나의 AI 어시스턴트를 공유하는 순간, 메모리는 기능이 아니라 보안 경계가 된다. GateMem은 병원, 직장, 캠퍼스, 가정처럼 여러 주체가 같은 에이전트를 쓰는 환경에서 메모리 접근과 관리가 제대로 통제되는지 평가하려는 벤치마크다.
개발자 입장에서 이 논문이 흥미로운 지점은 “에이전트 메모리”를 단순한 벡터 DB 검색 품질 문제가 아니라, 멀티 테넌트 서버의 권한 모델처럼 본다는 점이다. UE 서버에서도 플레이어별 상태, 파티 상태, 월드 상태를 아무렇게나 섞으면 바로 치트나 정보 누수가 된다. AI 에이전트도 비슷하다. 유저 A의 선호, 유저 B의 업무 정보, 조직 공용 지식이 한 메모리 풀에 들어가면 검색 정확도보다 먼저 접근 제어가 터진다.
왜 중요한가: 에이전트가 개인 비서에서 조직 인프라로 넘어가려면, 기억을 잘하는 것보다 “기억하면 안 되는 것을 안 꺼내는 능력”이 더 중요해진다.
논문
Distilling Examples into Task Instructions: 예제를 지시문으로 증류하는 ICL 개선
이 논문은 저자원 분류 작업에서 많이 쓰는 In-Context Learning을 실제 B2B 대화 분류에 맞게 개선하려는 접근이다. 핵심은 예시를 그대로 프롬프트에 우겨 넣는 대신, 예시들이 담고 있는 판단 기준을 작업 지시문으로 증류해 더 안정적인 분류를 노리는 것이다.
나도 사이드프로젝트에서 분류 프롬프트를 만들 때 비슷한 삽질을 자주 한다. 예시를 많이 넣으면 초반에는 성능이 오르는 듯하지만, 토큰 비용이 늘고 케이스가 조금만 바뀌어도 모델이 예시의 표면 패턴에 끌려간다. 게임 서버 최적화로 치면 매 요청마다 거대한 상태 스냅샷을 들고 다니는 느낌이다. 필요한 건 모든 로그를 붙이는 게 아니라, 판단에 필요한 규칙과 경계 조건을 작게 유지하는 것이다.
B2B 대화는 특히 애매하다. 고객 의도, 영업 단계, 지원 요청, 제품 피드백이 한 문장 안에 섞인다. 예시 기반 ICL만으로는 “이런 말투면 이 라벨” 같은 얕은 패턴에 갇히기 쉽다. 예제를 지시문으로 증류하면 프롬프트가 더 짧아지고, 도메인 규칙을 사람이 검토하기도 쉬워진다. 운영 환경에서는 이게 꽤 크다. 비용, 지연시간, 디버깅 가능성이 한꺼번에 걸려 있기 때문이다.
왜 중요한가: 실서비스 LLM 분류는 벤치마크 점수보다 프롬프트 크기, 유지보수성, 도메인 규칙의 가시성이 더 자주 병목이 된다.
개발자 메모
오늘 두 논문은 방향이 다르지만 같은 이야기를 한다. AI 에이전트를 제품에 넣을 때 진짜 어려운 부분은 모델 호출 자체가 아니라, 주변 시스템을 어떻게 설계하느냐다.
GateMem은 메모리 계층에 권한과 거버넌스가 필요하다고 말한다. 두 번째 논문은 프롬프트 계층에도 압축과 규칙화가 필요하다고 말한다. 둘 다 “LLM이 알아서 잘하겠지”로 넘기면 운영에서 터지는 영역이다. 게임 개발에서도 클라이언트가 보내는 값을 믿지 않고, 서버 상태를 명확히 분리하고, 핫패스의 데이터를 줄이는 것이 기본이다. AI 앱도 결국 같은 엔지니어링 감각으로 돌아온다.
개인적으로는 에이전트 메모리를 설계할 때 최소한 세 가지를 분리해야 한다고 본다. 개인 메모리, 조직 공용 메모리, 세션 임시 메모리다. 그리고 ICL 프롬프트도 원본 예시 저장소와 런타임 지시문을 분리해야 한다. 예시는 학습과 검증의 재료고, 런타임에는 압축된 정책이 들어가는 쪽이 더 다루기 쉽다.
AI 제품의 난이도는 모델 성능보다 메모리, 권한, 프롬프트를 운영 가능한 시스템으로 묶는 데서 갈린다.