코딩 에이전트 구축 중 발견한 문제점과 Oracle Agent Memory 소개

최근 코딩 에이전트를 만들다가 빠르게 나타나는 문제에 부딪혔습니다. 바로 장시간 세션이 전체 기록(full-history) 컨텍스트를 비용이 많이 들고 노이즈가 많게 만든다는 것입니다. 일반적인 접근 방식은 매 턴마다 전체 채팅 기록을 다시 전송하는 것입니다. 80번째 턴이 되면, 실제로 중요한 몇 가지 세부 정보를 복구하기 위해서 엄청난 양의 컨텍스트를 처리하게 됩니다. Oracle의 Agent Memory는 다른 접근 방식을 취합니다:

→ Working: 에이전트가 현재 무엇을 하고 있는지

→ Semantic: 사용자/프로젝트에 대한 지속적인 사실(durable facts)

→ Episodic: 과거 세션에서 무슨 일이 일어났는지

→ Procedural: 에이전트가 어떻게 행동해야 하는지에 대한 규칙

오래된 턴들은 요약될 수 있고, 지속적인 사실들이 추출될 수 있으며, 관련 있는 메모리만 프롬프트로 다시 불러올 수 있습니다. Oracle의 80턴 벤치마크 결과: 메모리를 사용할 경우 요청당 약 1.3K 입력 토큰 vs 전체 기록을 사용할 경우 약 13.9K입니다. 벤치마크에서 48턴일 때 더 나은 답변을 보여주며, 이는 전체 기록 사용 시 13턴 대비 개선된 수치입니다. 저에게 가장 큰 시사점은 이것입니다. 에이전트 메모리는 단순히 컨텍스트 크기를 키우는 문제가 아니라 시스템 설계(system-design) 문제입니다. 자세한 분석과 코드는 여기를 확인하세요:

https://t.co/lhU8RLnr4m

@OracleDevs와 협력하여