AI 코딩 에이전트의 메모리도 결국 부채가 됩니다 — 감사와 정리의 기록

몇 달째 AI 코딩 에이전트를 실무에 쓰고 있습니다. 처음 이 도구에 매료된 이유 중 하나는 "기억"이었습니다. 매 세션마다 같은 지시를 반복하지 않아도 되고, 프로젝트의 맥락을 한번 붙여두면 다음 대화에서 알아서 참고합니다. 반복 지시를 없애준다는 것 하나만으로도 충분히 매력적이었습니다.

그래서 저는 부지런히 기억을 쌓았습니다. 전역 규칙을 적고, 자주 하는 작업을 스킬로 묶고, 특정 영역을 전담하는 서브에이전트를 정의하고, 세션이 끝날 때마다 배운 것을 메모로 남겼습니다. 추가는 언제나 쉬웠고, 무언가를 적어둘 때마다 자산이 늘어나는 뿌듯함이 있었습니다.

그런데 어느 순간부터 그 기억이 저를 방해하기 시작했습니다. 분명히 방침을 바꿨는데 에이전트가 옛 방식을 고집하고, 어떤 규칙은 서로 어긋난 채 양쪽 모두 로드되고 있었습니다. 돌이켜 생각해보면 당연한 일이었습니다. 쌓아 올린 모든 상태가 그렇듯, 기억도 결국 썩기(rot) 때문입니다.

가장 위험한 건 "폐기된 정책의 화석"입니다

메모리가 낡는 방식에는 여러 가지가 있지만, 그중 가장 위험한 것은 단순한 오타나 오래된 정보가 아니었습니다. 저는 그것을 폐기된 정책의 화석이라고 부르기로 했습니다. 한때는 분명히 옳았던 규칙이, 방침이 바뀐 뒤에도 요약이나 포인터의 형태로 남아 매 세션마다 반대 방향의 신호를 계속 보내는 경우입니다.

문제는 이 화석이 최신 규칙과 나란히 로드된다는 데 있습니다. 에이전트 입장에서는 두 지침이 모두 "공식 기억"이므로, 어느 쪽이 이미 죽은 규칙인지 알 방법이 없습니다. 오래된 쪽이 더 구체적이거나 더 단호하게 적혀 있으면, 오히려 그쪽을 따르는 일마저 생깁니다.

단순한 오타는 에이전트를 잠시 헷갈리게 할 뿐, 대개 스스로 회복합니다. 그러나 화석은 다릅니다. 에이전트가 확신을 갖고 정확히 반대 방향으로 걸어가게 만듭니다. 기억이 없었다면 차라리 그 자리에서 저에게 물었을 텐데, 낡은 확신이 그 질문을 막아버립니다. 솔직히 말하면, 저를 가장 오래 고생시킨 문제들은 대부분 이 화석에서 나왔습니다.

에이전트 메모리 부채에도 유형이 있습니다

화석만 있는 것은 아니었습니다. 하나씩 걷어내다 보니 제가 쌓아둔 부채는 몇 가지 유형으로 정리되었습니다. 각각을 구분해두면 무엇을 먼저 손봐야 할지 판단하기가 한결 수월해집니다.

유형	증상	왜 문제인가
단일 출처 위반	같은 규칙이 여러 곳에 복제됨	한쪽만 고치면 나머지가 어긋나 서로 다른 말을 하게 됨
스코프 오표기	"전역"이라 적어두고 실제 참조는 한 곳만 가리킴	다른 맥락에서 불러오면 조용히 빗나감
죽은 참조	옮기거나 지운 대상을 포인터가 여전히 가리킴	따라가면 빈손, 혹은 엉뚱한 자리로 안내함
과잉 규율	모델이 이미 잘하는 일을 장황하게 다시 규정함	토큰만 쓰고 판단을 좁혀 오히려 경직됨
비용 > 가치	매번 로드되지만 실효는 낮은 큰 본문	정작 중요한 규칙이 놓일 자리를 밀어냄

이렇게 늘어놓고 보니, 대부분의 부채가 "적을 때는 옳았다"는 공통점을 갖고 있었습니다. 애석하게도 옳았던 기억일수록 지우기가 더 망설여집니다. 그래서 부채를 걷어내는 일은 새 규칙을 추가하는 일보다 훨씬 더 신중해질 수밖에 없었습니다.

"불완전한 것"이 아니라 "없는 게 나았을 것"을 찾습니다

정리를 시작할 때 저는 질문을 하나 바꿨습니다. 처음에는 "무엇이 불완전한가"를 물었는데, 그러자 끝이 없었습니다. 세상의 모든 문서가 그렇듯, 메모리도 더 다듬을 여지는 언제나 남아 있기 때문입니다.

그래서 질문을 "무엇이 아예 없었으면 나았을까"로 바꿨습니다. 개선의 여지가 있는 것과, 있다는 것 자체가 손해인 것은 전혀 다른 문제입니다. 앞의 것은 취향이고, 뒤의 것은 순부채(net-negative)입니다. 감사의 목표는 취향을 만족시키는 게 아니라 순부채를 걷어내는 것이라는 생각이 들었습니다.

이 구분을 세우고 나니 작업이 훨씬 단순해졌습니다. "더 좋게 만들 수 있다"는 유혹은 일단 접어두고, "이게 없었다면 에이전트가 더 정확했을까"라는 질문에 그렇다고 답할 수 있는 것들만 후보로 올렸습니다.

수집만으로는 부족합니다 — 스스로를 반박하게 만들었습니다

후보를 모으는 단계는 필연적으로 과잉으로 흐릅니다. "문제일지도 모른다"는 의심은 값이 싸기 때문에, 수집만 하면 실제보다 훨씬 많은 지적이 쌓입니다. 그래서 저는 수집한 지적을 그대로 믿지 않고, 하나하나를 독립적으로 반박해보기로 했습니다.

여기서 중요한 것은 판정을 둘로만 나누지 않는 것이었습니다. 참과 거짓으로만 가르면, "결론은 맞지만 세부가 조금 부정확한" 지적이 통째로 버려집니다. 그건 아까운 일입니다. 그래서 판정을 세 갈래로 두었습니다. 확정, 부정확하지만 방향은 맞음(교정문을 달고 살아남음), 그리고 기각입니다.

{ verdict: CONFIRMED | IMPRECISE | REFUTED,
  correction: "IMPRECISE일 때 — 방향은 맞으나 X는 실제로 Y",
  confidence: 0.0 ~ 1.0 }

이렇게 세 갈래로 두자, "불확실하면 일단 기각"이라는 거친 태도를 버릴 수 있었습니다. 확신이 서지 않으면 기각이 아니라 신뢰도를 낮추면 그만이었습니다. 덕분에 사소한 부정확함 때문에 참인 핵심까지 함께 폐기되는 일이 크게 줄었습니다.

검증에도 근거 부담에 따라 힘을 다르게 줍니다

검증도 결국 비용입니다. 모든 지적에 똑같이 무거운 반박을 붙이면, 정리하자고 시작한 일이 또 다른 부채가 됩니다. 그래서 저는 지적마다 검증의 두께를 달리했습니다.

기준은 그 지적이 결론을 바꾸는지 여부였습니다. 결론을 좌우하는 주장에는 여러 각도로 두껍게 반박을 붙이고, 보조적인 주장에는 얇게, 배경 상식에 가까운 것은 아예 검증하지 않았습니다. 판단의 무게를 근거의 부담에 맞춘 셈입니다.

한 가지 더 지켰던 원칙은, 이 분류를 다시 에이전트에게 맡기지 않는 것이었습니다. 무엇이 결론을 바꾸는 주장인지 고르는 일은 규칙, 그러니까 코드나 단순한 검색으로 결정적으로 처리했습니다. 에이전트를 아끼자고 에이전트를 더 부르는 것은 앞뒤가 맞지 않기 때문입니다.

관찰보다 실측이 먼저입니다

정리를 하다 겪은 일 중 하나는, 그럴듯하게 지적된 문제가 실제로는 존재하지 않았던 경우였습니다. 관찰만으로는 분명히 어긋나 보였는데, 막상 대상을 직접 열어보니 이미 정상적으로 처리되고 있었습니다.

만약 그 지적을 믿고 손을 댔다면, 멀쩡한 것을 건드려 새 부채를 만들 뻔했습니다. 그 뒤로 저는 원칙을 하나 세웠습니다. 관찰이 아무리 그럴듯해도, 직접 열어 확인하기 전에는 고치지 않는다는 것입니다.

돌이켜 생각해보면, 정리 작업에서 가장 위험한 순간은 부채를 발견했을 때가 아니라 "발견했다고 믿었을 때"였습니다. 헛수정은 아무것도 하지 않느니만 못합니다. 결국 실측이 먼저이고, 수정은 그다음입니다.

기각한 것도 기록으로 남깁니다

검증 과정에서 그럴듯했지만 결국 기각된 제안들이 있었습니다. 이를테면 "비슷하니 하나로 합치자"는 통합 제안이 그렇습니다. 겉보기엔 깔끔해지지만, 두 규칙이 서로 다른 시점에 발동하도록 설계되어 있으면 합치는 순간 둘 다 망가집니다.

옮기자는 제안도 마찬가지였습니다. 어떤 규칙은 적용 범위가 넓어서, 좁은 자리로 옮기는 순간 나머지 맥락에서 조용히 구멍이 생깁니다. 이런 것들은 "하지 않기로 한" 결정이지만, 그 이유를 남겨두지 않으면 다음에 똑같은 의심이 또 올라옵니다.

그래서 저는 기각한 제안과 그 이유를 함께 기록해두었습니다. 왜 안 했는지를 남기는 것은, 무엇을 했는지 남기는 것만큼이나 중요하다는 생각이 들었습니다. 그러지 않으면 같은 고민을 매번 처음부터 반복하게 됩니다.

고치는 순서에도 안전한 길이 있습니다

무엇을 걷어낼지 정한 다음에는, 어떤 순서로 손댈지가 남습니다. 저는 되돌리기 쉬운 것부터 건드렸습니다. 파급이 없다는 것이 실측된 한 줄짜리 수정을 먼저 하고, 영향 범위가 넓은 것은 뒤로 미뤘습니다.

문서를 먼저 고치고 코드를 나중에 고친 것도 같은 이유에서였습니다. 설명이 앞서 정리되어 있으면, 실제 동작을 바꿀 때 무엇을 기준으로 삼아야 하는지가 분명해집니다. 순서를 안전하게 두는 것만으로도 실수의 여지가 크게 줄었습니다.

마지막으로 지킨 것은, "완료"라고 말하기 전에 실제로 동작하는지 확인하는 일이었습니다. 부끄럽지만 예전의 저는 고쳤다는 사실만으로 끝났다고 여긴 적이 많았습니다. 그러나 고쳤다는 것과 고쳐졌다는 것은 다릅니다.

결론 — 메모리에도 가비지 컬렉터가 필요합니다

정리를 마치고 나니, 결국 문제는 기억을 쌓는 능력이 아니라 덜어내는 능력의 부재였다는 것을 깨달았습니다. 추가는 언제나 쉽고 뿌듯합니다. 그러나 덜어내는 일은 근거를 요구하고, 때로는 한때 옳았던 것을 지우는 망설임까지 요구합니다.

프로그램이 메모리를 계속 할당하기만 하고 회수하지 않으면 언젠가 무너지듯, 에이전트의 기억도 마찬가지라는 생각이 들었습니다. 쌓기만 하는 기억은 결국 자산이 아니라 부채가 됩니다. 그래서 저는 이 감사를 한 번의 이벤트가 아니라, 주기적으로 돌릴 수 있는 능력으로 남겨두기로 했습니다.

기억을 붙일 수 있다는 것은 여전히 이 도구의 가장 큰 미덕입니다. 다만 그 미덕을 지키려면, 무엇을 기억할지만큼 무엇을 잊을지도 함께 설계해야 합니다. 메모리에도, 가비지 컬렉터가 필요합니다.