기억은 학습이 아닙니다: AI 에이전트가 같은 실수를 반복하는 이유

AI 요약

AI 에이전트가 과거 대화와 실행 기록을 기억해도 같은 실수를 반복하는 이유는 정보의 축적과 경험을 통한 학습이 다르기 때문입니다. 글은 한 헤지펀드 임원이 팀원이 에이전트를 새로 쓰기 시작하면 모든 것이 초기화된다고 말한 사례에서 출발합니다. 에이전트에 과거 사례와 실행 이력, 검색 문서를 더했지만 독립 평가에서 성능이 일관되게 나아지지 않았고, 일부 설정에서는 오히려 나빠졌다고 설명합니다. 정보를 더 많이 제공하는 것보다 현재 판단에 필요한 정보만 적절한 순간에 보여주는 편이 나을 수 있다는 주장입니다.

사실과 학습을 구분합니다

고객 계약 만료일이나 API 인증 요건, 저장소에서 결제 서비스를 찾는 위치처럼 세계에 관한 정보는 데이터베이스와 문서 저장소에 넣을 사실입니다. 반면 장애 조사 때 최근 배포부터 확인하라거나, 출처가 충돌하면 의미상 가까운 문서보다 최근 검증한 출처를 우선하라는 내용은 경험에서 얻은 행동 지침입니다. 실행 로그가 에이전트가 무엇을 했는지 기록한다면 경험 기억은 다음에 무엇을 다르게 해야 하는지와 그 이유를 담습니다.

글은 기억 시스템의 절차를 Capture, Evaluate, Consolidate, Retrieve, Update로 제시합니다. Capture에서는 모든 대화가 아니라 의미 있는 경험을 기록합니다. Evaluate에서는 전략이 효과가 있었는지, 결과를 독립적으로 확인했는지 따집니다. Consolidate에서는 비슷한 실패가 반복될 때 기억을 여러 개 쌓는 대신 재사용 가능한 교훈으로 정리합니다. Retrieve는 상황에 맞는 교훈을 꺼내고, Update는 환경이 변하면 기억을 수정하거나 삭제합니다. 몇 달 전 유효했던 전략도 API나 정책이 바뀌면 위험해질 수 있습니다.

필요한 정보만 점진적으로 제공합니다

정확한 기억도 잘못된 시점에 제시하면 방해가 됩니다. 글은 현재 결정에 필요한 최소 정보를 먼저 보여주고, 필요할 때 더 많은 맥락을 제공하는 점진적 공개(progressive disclosure)를 제안합니다. 목표는 최대한 많이 회상하는 것이 아니라 적절한 시점에 맞는 정보를 바탕으로 더 나은 결정을 내리는 것입니다. 에이전트가 결과를 관찰하고 교훈을 추출한 뒤 검증하고 다음 판단에 적용하는 과정이 반복되면 경험이 쌓입니다. 도움이 된 교훈은 유지하고, 낡거나 해로운 교훈은 갱신하거나 제거해야 합니다. 글은 평가와 기억, 피드백을 따로 두지 않고 연속된 시스템으로 다루는 접근을 Loop Engineering이라고 부릅니다.

dev.to 반응

• @glenallen — 검증 단계가 있어야 이 학습 루프를 신뢰할 수 있습니다. 에이전트가 어떤 전략을 반복해 성공을 관찰해도 그 전략이 결과를 실제로 만들었는지, 단지 운이 좋았거나 환경이 바뀐 것인지는 모를 수 있습니다. IT Path Solutions에서는 신뢰할 수 있는 AI 워크플로를 만들 때 실행 이력과 검증된 학습을 분리하는 일이 중요하다고 봅니다. 교훈이 마지막으로 검증된 시점과 적용 조건도 기록하겠습니다. 그래야 API나 정책, 시스템 동작이 바뀐 뒤에도 기억이 영구 규칙처럼 조용히 굳어지지 않습니다. 목표는 모든 결과를 기억하는 게 아니라 알맞은 조건에서 유용한 교훈을 보존하는 것입니다.
• @alexshev — 절차가 말이 됩니다. 특히 사실과 행동 지침을 구분한 점이 좋습니다. 실패한 결과가 나왔을 때 학습한 전략을 갱신할지, 환경 변화나 작업별 잡음으로 볼지 어떤 신호를 기준으로 삼나요? 이 구분이 없으면 확신에 찬 낡은 규칙을 통합 과정에서 보존할 수 있습니다.
• @jabinpou — 갱신 단계도 검색만큼 신경 써야 합니다. 각 교훈이 어떤 조건에서 효과가 있었는지 보존하고 무효화할 방법을 두고 싶습니다. 그렇지 않으면 "배포부터 확인하라"가 어느새 "항상 배포가 원인이라고 생각하라"로 굳어질 수 있습니다.
• @marcusykim — 독립 평가를 했다는 점이 중요합니다. 교훈을 추출하는 데 쓴 사례와 시험에 쓸 사례를 분리하겠습니다. Consolidate 뒤에 새 기억이 있는 상태와 없는 상태로 새로운 작업을 각각 한 번 재생하고 도구와 시작 상태를 고정합니다. 원래 실패 사례에서만 이긴다면 유용한 전략을 배운 게 아니라 그 사례를 외웠을 수 있습니다. 이 방법은 교훈을 유지하거나 범위를 좁히거나 폐기할 구체적인 근거를 Update에 제공합니다.
• @izgorodin — 같은 실수를 반복하는 일은 루프의 세 지점에서 생길 수 있고 각각 해결책이 다릅니다. 교훈이 애초에 기록되지 않았거나, 기록됐지만 다른 항목이 더 높은 순위에 올라 이 작업에서 검색되지 않았거나, 맥락에 들어갔는데도 에이전트가 따르지 않은 경우입니다. 마지막 경우에는 1절에서 말한 것처럼 기억을 더해도 도움이 안 되고 줄이는 편이 나을 수 있습니다. 결과만 보면 세 경우 모두 실수가 반복된 것으로 보입니다. 제시된 절차에는 어떤 교훈이 각 결정을 내릴 때 맥락에 있었는지 기록하는 항목이 없습니다. 이 기록이 없으면 결과와 교훈을 연결하는 근거는 작업이 교훈과 관련 있어 보였다는 점뿐입니다. 실제로 검색되지 않은 작업에서 성공해도 교훈이 강화될 수 있고, 교훈이 주어지지 않은 작업에서 실패한 뒤 올바른 교훈을 좁히거나 폐기할 수도 있습니다. 기록이 있으면 교훈이 제시된 경우에만 결과를 교훈에 유리하거나 불리한 증거로 삼을 수 있습니다. 교훈이 없었던 실패는 그 교훈이 아니라 Retrieve 단계를 가리킵니다.
• @statewave — 저는 통합 단계에 힘을 주겠습니다. 반복 실패를 하나의 교훈으로 합치는 결정은 서로 다른 기록을 병합하는 결정과 같고, 나중에 문제가 되는 지점이기도 합니다. 저희는 반대 방향으로 처리했습니다. 새 내용이 오래된 내용을 대체하면 두 기록을 모두 남깁니다. 오래된 기록의 유효 기간을 닫아 검색에는 나오지 않게 하고 감사 기록에서는 볼 수 있게 합니다. 병합하면 나중에 가장 자주 필요한 정보, 즉 시스템이 전에 무엇을 믿었고 언제 믿음을 바꿨는지를 잃게 됩니다. 이 방식에서 잘못 처리한 점은 두 가지입니다. 첫째, 기존 기록을 닫으면서 무엇이 그 기록을 대체했는지 적지 않았습니다. 그래서 "이 교훈이 저 교훈을 대체했다"는 연결을 따라갈 수 없습니다. 설계 결정이 아니라 저희 쪽의 미해결 버그입니다. 결정 시점에 기록하면 거의 비용이 들지 않지만 나중에 복원하기는 어렵습니다. 둘째, 저장보다 더 어려운 일은 어떤 기록을 대체 대상으로 삼을지 정하는 조건입니다. 저희 규칙은 단어 중복이나 명시적으로 등록한 키를 사용합니다. 표현을 바꾼 교훈은 이전 기록과 연결되지 않고, 더 일반적인 새 교훈이 조건을 담은 좁은 교훈을 삼켜버릴 수도 있습니다. 교훈 저장소에서는 두 번째 문제가 더 위험합니다. "스테이징 클러스터에서는 제외하고 배포부터 확인하라"가 조용히 "배포부터 확인하라"로 바뀌는 식입니다. 그래서 조건 필드와 대체 관계 링크를 함께 추가하겠습니다. 조건이 없는 교훈은 제대로 대체할 수 없고 그저 교체될 뿐입니다.

원문: dev.to / 번역·요약: Trawling