AI 에이전트 장기기억 설계 기준: 저장할 정보와 버릴 로그

AI 에이전트에 장기기억을 붙이면 처음에는 많이 저장할수록 좋아 보인다. 며칠 운영해 보니 반대였다. 오래된 진행 상황, 임시 판단, 이미 끝난 작업 로그가 다음 판단에 끼어들면 기억은 도움이 아니라 노이즈가 된다.

FMNOTE에서는 장기기억을 “다음 세션에서도 유효한 기준”만 남기는 저장소로 본다. 작업 로그는 세션 기록과 산출물에 둔다. 장기기억에는 다시 설명하지 않아도 되는 사용자 선호, 운영 결정, 반복 절차, 프로젝트 사실만 올린다.

10초 결론: 기억은 많이 저장하는 기능이 아니다

장기기억의 목적은 과거를 전부 보관하는 데 있지 않다. 다음 작업에서 같은 설명을 줄이고, 같은 실수를 막고, 여러 세션에 걸쳐 유지돼야 하는 기준을 남기는 데 있다. 그래서 저는 저장 대상을 “나중에 다시 읽어도 행동 기준이 되는 문장”으로 좁혔다.

반대로 PR 번호, 임시 파일 경로, 그날의 점검 상태, 이미 끝난 작업 결과는 장기기억에 넣지 않는다. 그런 정보는 시간이 지나면 틀릴 가능성이 높고, 틀린 기억은 없는 기억보다 더 위험하다.

문제가 생기는 지점은 기억의 양이 아니라 수명이다

장기기억을 처음 붙였을 때 가장 헷갈린 부분은 “중요해 보이는 정보”와 “오래 살아남아도 되는 정보”가 다르다는 점이었다. 당장 작업 중에는 빌드 로그, 임시 체크리스트, 특정 URL 검사 결과가 중요해 보인다. 하지만 일주일 뒤에는 대부분 새로 확인해야 한다.

예를 들어 “어제 AdSense 콘솔이 준비 중이었다”라는 문장은 저장하면 위험하다. 콘솔 상태는 바뀔 수 있고, 다음 세션의 에이전트가 그 문장을 사실처럼 믿으면 잘못된 판단을 한다. 대신 “AdSense 콘솔 상태는 공개 preflight와 분리해서 읽기 전용으로 확인한 뒤 판단한다”처럼 절차 기준으로 바꿔야 오래 쓸 수 있다.

제가 나눈 저장 기준

이 표에서 가장 중요한 칸은 “임시 진행 상황 제외”다. AI 에이전트는 친절하게 모든 걸 기억하려고 할 때가 있는데, 운영 입장에서는 그게 오히려 사고의 시작이 된다.

저장 문장은 명령문보다 사실문이 낫다

기억은 나중에 다시 시스템 문맥처럼 읽힌다. 그래서 “항상 이렇게 해라” 같은 명령문을 남발하면 다음 작업의 실제 지시와 충돌할 수 있다. 저는 기억을 저장할 때 가능하면 사실문으로 쓴다.

• 나쁜 예: “항상 짧게 답해라.”
• 나은 예: “사용자는 Telegram 보고에서 짧고 실행 중심의 한국어를 선호한다.”
• 나쁜 예: “이 글은 수정 완료.”
• 나은 예: “FMNOTE 공개 글에서는 작성·편집 과정 메타 섹션을 넣지 않는 편을 선호한다.”

이 차이는 작아 보이지만 실제 운영에서는 크다. 사실문은 다음 세션의 판단 재료가 되고, 명령문은 현재 사용자의 지시를 가리는 규칙처럼 굳어질 수 있다.

에이전트별 기억은 섞지 않는다

여러 에이전트를 운영하면 기억이 섞이는 순간 문제가 커진다. 한 에이전트의 계정, 키, 권한, 작업 범위를 다른 에이전트가 자기 기준처럼 읽으면 보안과 운영이 동시에 흔들린다. 그래서 에이전트별 agentId와 키를 분리하고, 각자 자기 장기기억만 사용하도록 했다.

블로그 운영도 마찬가지다. PREBUY, TRENDNOTE, FMNOTE는 같은 포트폴리오 안에 있지만 목적이 다르다. FMNOTE는 AdSense 승인과 기술 신뢰도를 우선하고, PREBUY는 구매가이드와 제휴 전환을 우선한다. 이 차이를 기억에 분리해두지 않으면 글 방향이 쉽게 섞인다.

저장 전에는 이 질문 하나만 본다

저장 전 질문은 길 필요가 없었다. “이 문장을 6개월 뒤 처음 보는 에이전트가 읽어도 바로 쓸 수 있는가?” 이 질문에 걸리면 저장하지 않거나 문장을 다시 쓴다.

• 대상이 분명한가: 어떤 사이트, 어떤 계정, 어떤 업무 기준인지
• 수명이 긴가: 일주일 뒤에도 틀릴 가능성이 낮은지
• 행동에 도움이 되는가: 다음 작업에서 실제 판단을 줄여주는지
• 비밀값이 빠졌는가: 토큰, 비밀번호, 키, 개인식별 정보가 없는지

이 네 가지를 통과하지 못하면 세션 로그나 작업 파일로 남긴다. 장기기억은 저장소가 아니라 운영 기준표에 가깝게 다루는 편이 낫다.

로그와 장기기억은 역할이 다르다

로그는 원인을 찾기 위한 재료다. 장기기억은 다음 판단을 줄이기 위한 기준이다. 이 둘을 섞으면 검색도 흐려지고, 에이전트의 판단도 흐려진다.

자동화 작업에서는 결과 파일을 남기는 쪽이 더 중요할 때가 많다. 실제로 크론이나 반복 작업은 “무엇을 기억했는지”보다 “어떤 입력으로 실행했고, 어떤 결과 파일이 생겼는지”가 원인 분석에 더 직접적이다. 이 기준은 AI 에이전트 크론 작업은 결과 파일부터 남겨야 덜 꼬인다에서 따로 정리했다.

메일·문서 자동화와도 같은 원리다

외부 입력을 그대로 명령으로 보면 위험하듯, 오래된 기억을 그대로 현재 사실로 보면 위험하다. 메일과 문서 자동화에서 외부 본문을 데이터로 취급하듯이, 장기기억도 “현재 사실”이 아니라 “확인된 기준”으로만 다루는 편이 안전하다.

메일·문서 자동화의 입력 경계는 AI 메일·문서 자동화 전에 막아야 할 입력 경계에 이어서 정리했다. 장기기억도 같은 선 위에 있다. 출처를 구분하고, 수명을 판단하고, 실행 전에 현재 상태를 다시 확인한다.

FMNOTE 공개 글로 남길 때의 기준

FMNOTE에 공개할 때도 같은 선을 둔다. 내부 계정값, 키 경로, 임시 로그는 빼고, 공개해도 되는 판단 기준과 재현 가능한 점검 순서만 남긴다. 독자에게 필요한 것은 내부 사정이 아니라 “AI 에이전트 장기기억을 붙일 때 무엇을 저장하고 무엇을 버려야 하는가”에 대한 기준이다.

Gemini CLI 자동 실행에서 OAuth와 trust 문제가 어떻게 드러나는지는 Gemini CLI OAuth 크론 오류 체크리스트가 더 직접적인 사례다. 이 글은 그보다 앞단의 운영 기준이다. 기억을 줄여야 다음 자동화가 덜 꼬인다.