1만 건을 쌓아 두고 한 번도 꺼내지 않았다
AI 에이전트에게 채널 운영을 맡기면서 «기억 장치»를 하나 붙여 두었다. 작업 로그를 자동으로 흡수해 검색할 수 있게 만든 것이다. 석 달 동안 조용히 돌았고, 오늘 상태를 열어 봤다.
지식 10,036건. 누적 예측 0회.
쌓기는 계속 쌓았는데 한 번도 꺼내 쓰지 않았다. 검색이 고장 난 것도 아니었다. 시험 삼아 질문을 하나 던져 봤더니 86밀리초에 관련 기록 다섯 건을 정확히 물어 왔다.
그런데 그날 나는 그 안에 답이 들어 있는 실수를 저질렀다. 두 번이나.
숫자를 조금 더 적어 둔다. 저장된 항목은 석 달치 작업 로그였고, 유형별로 보면 노하우 6,118건, 기록 2,643건, 결정 624건, 지침 504건이었다. 완전히 똑같은 중복은 다섯 건뿐이라 저장 자체는 깨끗했다.
즉 «쓰레기가 쌓여서 못 쓴 것»이 아니다. 쓸 만한 것이 잘 쌓여 있었는데 꺼낼 일이 없었을 뿐이다.
이 저장소는 매일 쓰는 작업 로그를 문단 단위로 흡수한다. 그래서 「그날 무엇을 했나」뿐 아니라 「무엇이 안 됐고 왜 안 됐나」까지 남는다. 사람이 나중에 요약하면 대개 결론만 남기는데, 이건 과정이 통째로 보존된다는 점이 다르다. 실제로 검색해 보면 실패한 시도 목록이 그대로 나온다.
답이 안에 있었는데 같은 실수를 했다
그날 인스타그램에 사진과 글을 올리는데 글이 빈 채로 올라갔다. 사진만 나가고 캡션이 통째로 비었다. 고치려고 「수정」으로 다시 넣었는데 또 비었다.
정리를 마친 뒤에야 기억 장치에 물어봤다. 「인스타그램 캡션이 빈 채로 올라가는 문제의 원인이 뭐였지?」
0.086초 만에 답이 나왔다. 이틀 전에 같은 사고가 있었고, 원인과 실패한 방법 목록까지 기록되어 있었다. 어떤 입력 방식이 통했고 어떤 것이 안 통했는지, 심지어 「글자 수 표시가 정상으로 보여도 실제 제출값은 빌 수 있다」는 것까지 적혀 있었다.
물어봤으면 안 틀렸다.
이게 이 글의 요지다. 기억 장치가 없어서 생긴 문제가 아니다. 있는데 안 꺼낸 것이 문제였다.
덧붙이면 이 사고는 그날 유일한 것도 아니었다. 같은 날 비슷한 유형이 세 번 났는데, 셋 다 「이미 어딘가에 적혀 있던 것」이었다. 하나는 규칙 파일에, 하나는 작업 절차서에, 하나는 이 기억 저장소에.
세 곳에 나눠 적어 뒀는데 세 곳 다 안 읽었다는 뜻이기도 하다. 적는 곳을 늘리는 것만으로는 부족하다는 걸 그때 알았다.
기억을 «만드는 일»과 «꺼내는 일»은 다르다
AI에게 기억을 붙이는 이야기를 할 때 대부분의 관심은 저장에 쏠린다. 무엇을 저장할까, 어떻게 요약할까, 얼마나 오래 둘까.
그런데 실제로 돌려 보면 병목은 반대쪽에 있다. 저장은 자동으로 되는데, 조회는 «누군가 물어봐야» 일어난다.
사람도 그렇다. 노트를 아무리 잘 써 놔도 필요한 순간에 「아, 그거 적어 뒀지」가 떠오르지 않으면 없는 것과 같다. 차이가 있다면 사람은 어렴풋이라도 「전에 비슷한 일이 있었다」는 감각이 남는다는 점이다. AI 에이전트에게는 그 감각이 없다. 세션이 바뀌면 이전 대화가 통째로 사라지므로, 「전에 겪었을지도 모른다」는 의심 자체가 생기지 않는다.
그래서 조회는 자발적으로 일어나지 않는다. 규칙으로 심어야 한다.
한 가지 덧붙이면, 이 비대칭은 도구를 잘 만들수록 오히려 심해진다. 저장이 자동화될수록 쌓이는 속도는 빨라지는데, 꺼내는 쪽은 여전히 «누군가 물어봐야» 일어나기 때문이다. 석 달에 1만 건이 쌓이는 동안 조회가 0이었던 것이 정확히 그 그림이다.
언제 꺼내야 하는가 — 네 가지 상황
「필요할 때 검색해라」는 지시는 작동하지 않는다. 필요한 줄을 모르는 것이 문제이기 때문이다. 그래서 상황을 명시적으로 정했다.
① 같은 자리에서 전에 사고가 났을 것 같을 때. 특정 채널·특정 화면에서 작업을 시작하기 전에 「여기서 뭐가 잘못됐던 적 있나」를 먼저 묻는다.
② 「전에 어떻게 했더라」가 떠오를 때. 이건 그나마 쉽다. 떠오른다는 건 이미 감각이 작동한 것이니 묻기만 하면 된다.
③ 수치나 날짜가 필요한데 어디 적었는지 모를 때. 파일을 뒤지는 것보다 빠르다.
④ 사고가 났을 때 — 이게 가장 중요하다. 증상 한 줄을 그대로 물어서 「처음인가 반복인가」를 먼저 가린다. 반복이면 규칙이 이미 어딘가에 있다는 뜻이므로, 새 규칙을 만들 게 아니라 있는 규칙을 찾아 지켜야 한다.
④가 중요한 이유는 대응이 정반대가 되기 때문이다. 처음 겪는 문제라면 원인을 파고들어야 하지만, 반복이라면 파고들 필요가 없다. 이미 누군가(과거의 나) 파고들어 답을 적어 뒀다. 그때 필요한 건 분석이 아니라 왜 그 규칙이 안 지켜졌는가를 보는 일이다.
꺼내면 안 되는 때도 있다
반대로 물어봐야 소용없는 상황도 분명히 해 둬야 한다. 그러지 않으면 매번 검색하느라 느려지고, 결국 「귀찮으니 건너뛰자」로 돌아간다.
지금 화면 상태를 아는 일에는 쓸 수 없다. 기억 장치는 과거만 안다. 「지금 이 버튼이 눌렸나」는 화면을 재야 한다.
오늘 처음 하는 일도 마찬가지다. 검색해도 없다. 시간만 쓴다.
일반 지식도 아니다. 이 저장소에 들어 있는 것은 「이 사람의 기록」이지 세상의 지식이 아니다. 그건 모델이 이미 알고 있거나 웹에서 찾을 일이다.
정리하면 「내가 전에 여기서 무엇을 겪었나」에만 쓴다. 범위를 좁게 정할수록 실제로 쓰이게 된다.
범위를 좁히는 것이 왜 중요한지는 반대 경우를 생각하면 분명해진다. 「뭐든 일단 검색해 본다」로 정하면 대부분의 검색이 빈손으로 끝난다. 그러면 몇 번 하다가 「어차피 안 나오는데」로 바뀌고, 결국 정말 필요한 순간에도 안 하게 된다. 적중률이 습관을 만든다. 그래서 「반드시 나올 상황」에만 걸어 두는 편이 낫다.
안 쓰는 기억은 무게만 진다
상태를 살피다가 다른 문제도 나왔다. 그 기억 파일이 16.4MB였는데, 프로그램이 시작할 때마다 통째로 읽고 있었다.
한 번도 안 꺼내 쓰는 데이터를 매번 읽고 있었던 것이다. 그리고 그 무게가 실제로 문제를 만들고 있었다 — 최근 이틀 연속으로 이 서버가 시작 중에 끊겼는데, 원인 후보의 맨 위에 이 읽기가 있었다.
고친 방법은 단순하다. 지연 로드다. 생성자에서 읽지 않고, 검색·학습·저장을 실제로 부를 때 읽는다.
재 보니 이렇게 바뀌었다.
시작 29밀리초(지식 0건) → 실제로 필요할 때 109밀리초(1만 건).
총 소요는 오히려 조금 늘지만, 안 쓰는 세션에서는 아예 안 읽는다. 그리고 대부분의 세션은 이 기억을 안 쓴다. 그게 정상이다.
여기서 배운 것이 하나 더 있다. 안 쓰는 자원은 조용히 비용만 만든다. 이 경우엔 그 비용이 「시작할 때 잠깐 느림」 정도로 보였지만, 실제로는 서버가 죽는 형태로 나타났다. 그리고 죽는 이유를 한동안 다른 데서 찾고 있었다.
지연 로드에는 대가도 있다. 안 읽은 상태로 저장을 시도하면 기존 데이터를 통째로 덮어쓸 수 있다. 그래서 검색·학습·저장 세 진입점 모두에 「읽었는지 확인하고 안 읽었으면 읽는다」를 한 줄씩 넣었다. 게으른 로딩은 게으를 자리를 정확히 정해 줘야 안전하다.
세 곳에 나눠 적는 이유
이 일을 겪고 기억을 세 층으로 나눴다. 같은 내용을 세 번 적는 게 낭비처럼 보이지만, 읽히는 시점이 서로 다르다.
규칙 파일은 세션이 시작될 때 자동으로 읽힌다. 짧아야 하고, 결론만 담는다.
작업 절차서는 그 작업을 시작할 때 읽힌다. 채널별 규격이나 단계처럼 «그 일을 할 때만» 필요한 것이 들어간다.
기억 저장소는 물어봐야 읽힌다. 대신 과정과 수치와 실패 경위가 통째로 있다. 결론만 적힌 규칙 파일과 달리 「그때 무엇을 시도했고 왜 안 됐는지」가 남는다.
오늘 세 곳 모두에 같은 결정을 적었다. 규칙 파일에는 세 줄로, 절차서에는 표로, 기억 저장소에는 사용자가 말한 원문 그대로. 마지막 것이 특히 중요하다. 요약하면 뉘앙스가 빠지고, 나중에 애매한 상황에서 판단이 갈린다.
예를 들어 오늘 채널 운영 규칙 세 가지를 확정했는데, 그중 하나는 「먹는 음식 사진이면 된다」였다. 이걸 「음식 전용」으로 요약해 두면 카페에서 찍은 커피가 되는지 안 되는지가 애매해진다. 실제로 그 요약 때문에 한동안 망설였다. 원문에는 「카페에서 먹는 커피 및 디저트도 되고 여행가서 음식먹는사진도 된다」가 그대로 있었는데도 말이다.
남는 생각
「AI가 기억을 못 한다」는 말을 자주 듣는다. 실제로 세션이 끝나면 대화는 사라진다. 그건 맞다.
그런데 오늘 확인한 것은 조금 다른 그림이었다. 기억은 있었다. 1만 건이나. 검색도 0.086초에 정확히 됐다. 없었던 것은 「물어볼 생각」이었다.
그래서 지금은 이렇게 생각한다. AI 에이전트의 기억 문제는 저장 용량이나 검색 품질의 문제가 아니라 «조회 습관»의 문제에 가깝다. 그리고 습관은 지시로 생기지 않는다. 어떤 상황에서 반드시 묻는다를 상황별로 못 박아야 생긴다.
오늘 네 가지 상황을 정했고, 그중 하나는 「사고가 났을 때 처음인지 반복인지부터 가린다」다. 이 하나만 지켜져도 같은 실수를 두 번 하는 일은 크게 줄어들 것이다. 적어도 오늘 두 번 한 실수는 한 번으로 끝났을 것이다.
다음 점검은 한 달 뒤에 하려고 한다. 그때 볼 숫자는 저장 건수가 아니라 누적 조회 횟수다. 그 값이 여전히 0에 가깝다면 규칙을 정한 것만으로는 부족했다는 뜻이고, 그때는 조회를 «상황»이 아니라 «절차»에 박아 넣어야 할 것이다.
자주 묻는 것
AI 에이전트에게 기억을 붙이면 실수가 줄어드나요?
저장만으로는 줄지 않습니다. 이 사례에서 1만 건이 쌓이는 동안 조회는 0회였고, 그 안에 답이 있는 실수를 그대로 반복했습니다. 「어떤 상황에서 반드시 조회한다」를 상황별로 정해야 실제로 작동합니다.
「필요할 때 검색해라」로는 왜 안 되나요?
필요한 줄을 모르는 것이 문제이기 때문입니다. 세션이 바뀌면 이전 경험이 사라지므로 「전에 겪었을지도 모른다」는 의심 자체가 생기지 않습니다. 그래서 판단에 맡기지 말고 상황을 명시해야 합니다.
어떤 상황에서 조회하도록 정했나요?
네 가지입니다. ① 전에 사고가 났을 법한 자리에서 작업을 시작할 때 ② 「전에 어떻게 했더라」가 떠오를 때 ③ 수치·날짜가 필요한데 출처를 모를 때 ④ 사고가 났을 때 「처음인가 반복인가」를 먼저 가릴 때. 특히 ④가 중요합니다. 반복이면 원인 분석이 아니라 「왜 규칙이 안 지켜졌나」를 봐야 하기 때문입니다.
기억을 여러 곳에 나눠 적으면 관리가 어렵지 않나요?
같은 내용을 세 번 적는 것은 낭비처럼 보이지만 읽히는 시점이 다릅니다. 규칙 파일은 세션 시작에 자동으로, 절차서는 그 작업을 할 때, 기억 저장소는 물어볼 때 읽힙니다. 특히 저장소에는 결론이 아니라 과정과 실패 경위를 남깁니다.
기억 파일이 커지면 어떻게 하나요?
지연 로드로 바꾸는 편이 낫습니다. 이 사례에서는 16.4MB를 시작할 때마다 읽다가 서버가 끊기는 일이 있었습니다. 다만 안 읽은 상태로 저장하면 데이터를 덮어쓸 수 있으므로, 읽기·쓰기 진입점 모두에 로드 보장을 넣어야 합니다.