AI 코딩 에이전트를 며칠만 써 보면 누구나 비슷한 불만을 갖게 된다. 분명 어제 설명했던 저장소 구조와 금지 규칙을 오늘 또 설명해야 하고, 방금 실패한 이유를 같은 세션이 아니면 다시 모르는 것처럼 행동한다는 점이다. 그래서 많은 팀이 “모델이 아직 부족하다”라고 결론내리지만, 실제 문제는 성능보다 메모리 설계에 있는 경우가 많다.
지속형 자동화에서 메모리는 단순한 대화 저장 기능이 아니다. 메모리는 에이전트가 다음 실행에서 무엇을 다시 배우지 않아도 되는지를 정하는 운영 계층이다. 메인 허브 글인 지속형 AI 에이전트 운영 가이드: 메모리·승인·재개 구조를 함께 설계하는 법에서도 강조했듯, 세션이 끝나도 이어지는 자동화를 만들려면 기억의 단위를 먼저 설계해야 한다.
왜 채팅 로그만으로는 부족한가
채팅 로그는 정보량이 많지만 운영 관점에서는 잡음도 많다. 중간 시도, 우회 설명, 이미 폐기한 아이디어까지 모두 섞여 있기 때문이다. 사람이야 대충 읽고 맥락을 복원할 수 있지만, 에이전트는 그렇지 않다. 관련 없는 맥락까지 함께 불러오면 오히려 현재 작업 판단이 흔들린다.
그래서 장기 운영에서 중요한 것은 “무엇을 저장할까”보다 “무엇을 다시 불러오지 않을까”다. 모든 대화를 다 기억하게 하는 접근은 언뜻 좋아 보이지만, 실제로는 다음 문제를 만든다.
- 현재 작업과 무관한 과거 맥락이 다시 섞인다.
- 결정이 아니라 추측 단계까지 남아 판단 기준이 흐려진다.
- 컨텍스트 비용이 커져 필요한 정보가 묻힌다.
결국 메모리는 많이 남길수록 좋아지는 저장소가 아니라, 재실행에 필요한 신호만 선별하는 운영 도구에 가깝다.
코딩 에이전트가 기억해야 하는 것은 다섯 가지다
실무에서 유용한 메모리는 대체로 다섯 범주로 나뉜다.
1. 결정
이미 합의된 방향이다. 예를 들어 “블로그 글은 tech-trend 폴더에 넣는다”, “GitHub PR 생성은 로컬 outbox로 넘긴다” 같은 규칙이 여기에 해당한다. 같은 결정을 매번 다시 추론하게 만들면 자동화가 느려지고 흔들린다.
2. 제약
하지 말아야 할 것, 접근할 수 없는 것, 승인 없이는 넘기면 안 되는 것이 여기에 들어간다. 예를 들어 “GitHub plugin write는 쓰지 않는다”, “승인 없이 main에 push하지 않는다” 같은 제약은 장기 자동화의 안전선이다.
3. 실패 원인
과거 실패가 왜 일어났는지 남겨야 같은 실수를 줄일 수 있다. 단순히 “실패함”이 아니라 “파일 선택 명령이 공백 처리 때문에 깨짐”, “중복 발행 방지를 위해 queued 상태는 건너뜀”처럼 재발 방지에 직접 도움이 되는 형태여야 한다.
4. 재개 지점
장기 실행 자동화에서는 “어디까지 끝났는가”가 중요하다. 초안은 생성됐는지, outbox는 큐에 들어갔는지, 승인 대기인지, merge 완료인지 같은 상태는 다음 런이 이어받는 핵심 단서다.
5. 독자 또는 업무 맥락
한국 독자를 위한 톤, 선호하는 글 구조, 자주 연결하는 내부 링크 같은 정보는 매번 새로 추론할 필요가 없다. 다만 이 범주는 영구 규칙보다 느슨하게 두고, 시간이 지나면 갱신할 수 있어야 한다.
메모리를 파일로 둘 때의 장점
에이전트 메모리를 외부 파일이나 구조화된 저장소에 두면 장점이 분명하다. 우선 사람이 직접 읽고 수정할 수 있다. 또 어떤 정보가 운영 기본값으로 쓰이는지 투명해진다. 마지막으로 세션이 끊겨도 같은 경로에서 다시 불러올 수 있으므로 재개가 쉬워진다.
반대로 메모리를 전적으로 내부 대화 문맥에만 기대면 다음과 같은 문제가 생긴다.
- 세션이 바뀌는 순간 기억이 끊긴다.
- 어떤 규칙이 최신인지 사람이 검토하기 어렵다.
- 다른 자동화나 다른 담당자가 같은 운영 지식을 재사용하기 어렵다.
따라서 코딩 에이전트의 메모리는 “보조 기능”이 아니라 운영 문서와 상태 파일의 중간 형태로 보는 편이 현실적이다.
좋은 메모리는 요약이 아니라 행동 기준을 남긴다
많은 팀이 메모리를 만들 때 “오늘 한 일 요약”을 쌓는다. 이것도 나쁘진 않지만, 장기 운영에 더 중요한 것은 행동 기준이다. 다음 런이 그 메모리를 보고 무엇을 다르게 해야 하는지가 드러나야 하기 때문이다.
예를 들어 아래 두 문장을 비교해 보자.
- “오늘 GitHub outbox 파일을 만들고 Slack 알림을 보냈다.”
- “queued 상태는 재처리하지 않고, outbox 생성 직후 history에
github_outbox_enqueued를 기록한다.”
첫 문장은 요약이고, 둘째는 행동 기준이다. 지속형 에이전트는 둘째 문장에서 훨씬 더 큰 도움을 받는다. 메모리를 설계할 때는 정보의 양보다 다음 액션에 미치는 영향력을 기준으로 선별하는 편이 낫다.
메모리 체크리스트
지속형 코딩 에이전트 운영을 점검할 때는 아래 항목을 보면 된다.
- 결정, 제약, 실패 원인, 재개 지점이 분리되어 저장되는가.
- 채팅 로그 전체가 아니라 재사용 가치가 큰 신호만 구조화되어 있는가.
- 사람이 직접 읽고 수정할 수 있는 파일 또는 저장소에 남는가.
- 다음 실행이 메모리를 읽고 실제 행동을 바꿀 수 있는가.
- 시간이 지나면 낡는 규칙과 거의 변하지 않는 규칙이 구분되어 있는가.
- 승인 이력과 예외 처리 기준이 메모리로 축적되는가.
메모리 설계가 잘 되면 코딩 에이전트는 덜 잊어버리는 것을 넘어, 다음 실행에서 더 빨리 판단하고 같은 실수를 덜 반복하게 된다. 결국 지속형 자동화의 품질은 모델이 무엇을 생성하느냐만이 아니라, 무엇을 기억하고 무엇을 잊게 설계했느냐에서 갈린다.
메모리만으로 자동화가 완성되지는 않는다. 오래 돌리는 운영 구조 전체는 지속형 AI 에이전트 운영 가이드: 메모리·승인·재개 구조를 함께 설계하는 법에서 이어서 볼 수 있다.