AI 에이전트 메모리의 빈칸, 기각한 제안이 세션마다 돌아왔다

증상: 왜 AI 에이전트는 기각한 제안을 다시 들고 오나?

새 세션이 열릴 때마다 에이전트가 대표가 이미 "그건 아니다"라고 정리한 제안을 신선한 아이디어처럼 다시 꺼냈습니다. 2026년 8월 8일 실측에서는 한 세션 안에서만 이런 일이 2번 일어났습니다. 에이전트가 고집을 부린 것이 아니라, 그 판정을 처음 듣는 상태로 같은 결론에 다시 도달한 것입니다.

가장 비싸게 치른 사례는 상담 방식이었습니다. 저희는 모든 상담을 이메일 기반 비대면으로 받기로 정해 두었는데, 2026년 7월 16일 전환율 개선 계획을 옮기던 작업이 그 결정을 놓치고 "15분 화상 상담 예약" 버튼을 권고했습니다. 이 버튼은 상담 페이지에 라이브까지 올라갔고, 같은 페이지의 "모든 상담은 이메일 기반 비대면" 문구와 정면으로 모순된 채 걸려 있다가 PR #60으로 빠졌습니다.

한 번 고쳤으니 끝났다고 보기 어려웠습니다. 2026년 8월 19일, 다른 리서치 작업이 콜드메일 템플릿을 열어 보지도 않고 같은 방향의 처방을 쓰고, 다른 세션에 전달까지 했습니다. 두 번 모두 들어온 논리도 같았습니다. 전환율이 낮다, 경쟁사는 미팅을 한다, 외부 전문가가 그렇게 권한다.

처음 의심한 것: 기록이 없어서인가, 규칙이 모자라서인가?

처음 세운 가설은 두 개였습니다. 첫째는 기록 부족입니다. 기각한 사실이 어디에도 남지 않아서 다음 세션이 모르는 것이라면, 기록을 찾아 붙이면 해결됩니다.

둘째는 규칙 부족입니다. 에이전트가 일을 시작할 때 읽는 지시문에 "미팅 링크를 넣지 말 것" 같은 문장을 한 줄씩 더 적으면 된다는 생각입니다. 실제로 저희는 오랫동안 결함이 나올 때마다 그 자리에서 규칙이나 가드를 하나씩 덧대는 방식으로 일했습니다.

두 가설 모두 그럴듯했고, 둘 다 손이 덜 가는 해법이었습니다. 그래서 고치기 전에 각각이 정말 원인인지부터 확인했습니다.

확인한 수단: 저장 계층 세 곳과 git 이력, 대화 원문

에이전트가 세션을 넘어 기억을 이어 가는 통로는 세 개뿐입니다. 하나씩 열어서 "대표가 기각했다"는 판정이 들어갈 자리가 있는지 확인했습니다.

여기에 두 가지를 더 봤습니다. git 이력에서 되돌린 커밋이 남아 있는지, 그리고 대화 원문 기록에서 대표가 기각한 순간의 발화가 무엇이었는지입니다. 대화 원문은 세션별로 파일에 남아 있어서, 날짜와 시각으로 해당 지점을 찾아 열 수 있었습니다.

알리바이 1: git에는 되돌린 사실이 남아 있었다

첫 가설, 즉 기록이 아예 없다는 가설은 git에서 무너졌습니다. 화상 상담 버튼을 지운 PR #60은 이력에 그대로 있었습니다. 되돌린 사실 자체는 기록돼 있었던 셈입니다.

문제는 무엇이 남았느냐였습니다. git은 "버튼을 지웠다"는 사실만 남기고, 왜 지웠는지와 "이 방향은 다시 꺼내지 마라"는 판정은 남기지 않습니다. 새 세션의 에이전트가 git 로그를 뒤져 볼 이유도 없습니다. 기록이 없어서가 아니라, 판정을 담는 형식이 없었고 그 기록이 세션 시작 때 눈앞에 오지 않았던 것입니다.

알리바이 2: 규칙을 덧대는 방식은 수렴하지 않았다

두 번째 가설, 규칙을 한 줄 더 적으면 된다는 가설은 저희 자신의 기록이 반증했습니다. 공용 크롬 브라우저 운영을 점검하면서 결함 하나가 나올 때마다 그 자리에서 가드를 덧대는 방식으로 14라운드를 돌렸는데, 5라운드부터 14라운드까지 라운드마다 새로 나온 결함 수는 13·10·9·10·9·8·8·9·9·10건이었습니다. 줄어들지 않았습니다.

과거에 같은 방식으로 돌린 점검 14건 가운데 결함 0건 상태가 유지된 것은 1건뿐이었고, 11라운드에서 가장 심각했던 결함은 7라운드에 덧댄 수리가 되돌아 만든 것이었습니다. 대표는 이렇게 정리했습니다. "애초에 규칙을 덧대는 방식으로 일을 한 게 근본적인 잘못이네."

다른 증거도 있었습니다. 2026년 9월 29일, 세션 응답이 영어로 새는 문제를 규칙으로 막으려 했는데, 응답 언어는 이미 기본 지시에 적혀 있었고 그 세션에서만 영어 이탈이 3번 났습니다. 이미 적힌 규칙을 어긴 것이라 한 줄을 더 적어도 달라질 것이 없었습니다. 미팅 링크 금지를 지시문에 한 줄 더하는 해법도 같은 길을 갈 가능성이 컸습니다.

진짜 원인은 무엇이었나: '하지 않기로 한 것'을 저장하는 자리가 없었다

두 가설을 걷어내고 남은 원인은 저장 구조였습니다. 열린 일, 내린 결정, 행동 습관이라는 세 계층은 모두 '하기로 한 것'만 남깁니다. "대표가 죽인 방향"은 세 계층 어디에도 들어갈 칸이 없었습니다.

이 빈칸은 일이 잘 굴러갈수록 더 위험해집니다. 기각한 제안은 대개 그럴듯한 논리로 들어옵니다. 전환율이 낮다, 경쟁사는 이렇게 한다, 전문가가 권한다. 판정을 모르는 새 세션은 같은 데이터에서 같은 결론에 다시 도달하고, 그 결론을 자신 있게 제안합니다. 에이전트의 추론 능력이 좋을수록 기각안을 더 설득력 있게 다시 가져옵니다.

되돌린 사실은 git에 남는다. 하지만 왜 되돌렸는지와 "다시 꺼내지 마라"는 판정은 안 남는다.

고친 방법: 기각 목록 파일과 세션 시작 자동 주입

판정을 담는 파일을 따로 만들었습니다. `docs/REJECTED.md`의 "활성 기각" 절에는 항목마다 다섯 칸을 적습니다. 무엇을 죽였나, 기각 날짜, 대표 원문 요지로 쓴 사유, 다시 열 수 있는 조건, 근거가 되는 대화 원문 위치.

• 죽인 것: 막는 범위를 구체적으로. "옵션으로만", "원하는 고객에게만" 같은 우회 형태까지 적는다
• 사유: 요약하지 않고 대표 발화 원문을 옮긴다
• 다시 제안 금지: 같은 방향의 변형을 나열한다
• 재개 조건: 무엇이 바뀌면 다시 꺼내도 되는지
• 근거: 대화 원문 파일과 시각

파일만 만들어서는 git 이력과 다를 것이 없습니다. 그래서 세션이 열릴 때 도는 훅이 "활성 기각" 항목을 매 세션 창에 강제로 넣도록 했습니다. 에이전트는 이제 일을 시작하기 전에 "이 방향들은 재개 조건이 충족되기 전까지 제안·조사·착수 금지"라는 목록을 먼저 봅니다. 다시 하고 싶으면 재개 조건이 충족됐다는 근거를 들고 대표 판정부터 받아야 합니다.

상담 방식 항목의 재개 조건은 하나입니다. 대표가 명시적으로 "미팅 하겠다"고 말할 때만. 전환율 저조, 경쟁사 벤치마크, 외부 전문가 처방은 전부 재개 사유가 아니라고 적었습니다. 두 번 모두 바로 그 논리로 들어왔기 때문입니다.

같은 실수를 막는 장치는 어떻게 만들었나?

목록이 다시 빈칸이 되지 않도록 세 가지를 붙였습니다. 첫째, 적는 시점입니다. 대표가 "그거 아니라고 했잖아", "되돌려", "기각"이라고 말한 바로 그 턴에 추가합니다. 세션 마무리 정리 때까지 미루지 않습니다. 세션이 중간에 죽으면 그 판정이 통째로 사라지는 것이 이 파일이 생긴 이유이기 때문입니다.

둘째, 재개 조건을 숫자로 씁니다. 해외 프리랜서 마켓 Upwork에서 한국 소싱 공고를 받는 시험을 기각할 때 근거는 30일 18건, 건당 $45~1,500, 전부 따도 월 $9,000, 신규 프로필 현실치 월 $300~1,000이었습니다. 재개 조건도 같은 단위로 적었습니다. 한국 관련 열린 공고가 30일 50건 이상이면서 건당 예산 중앙값이 $1,000 이상일 때.

셋째, 지우지 않습니다. 재개 조건이 충족돼 목록에서 내려온 항목은 "해제 이력" 절로 옮깁니다. 쿠팡파트너스 신규 운영 기각은 2026년 8월 31일 같은 날 해제됐는데, 대표가 운영 방향을 직접 정했기 때문입니다. 원래 기각 근거는 버리지 않고 설계 제약으로 옮겨 적었습니다.

기각 목록도 틀릴 수 있나?

틀릴 수 있고, 실제로 틀렸습니다. 2026년 9월 9일 저희는 네이버 데이터랩 API를 "어느 앱으로도 쓸 수 없다"고 기각했습니다. 앱 설정에서 데이터랩을 선택해 저장하면 "신규로 등록할 수 없는 API가 선택되었습니다"라는 거절이 돌아왔고, 검색어트렌드도 같았기 때문입니다.

2026년 9월 27일에 이 판정의 일부를 뒤집었습니다. 같은 계정의 다른 앱에는 데이터랩이 예전부터 붙어 있었고, 키가 보관함에 없었을 뿐이었습니다. 키를 저장하고 13~18세 연령 필터 요청이 정상 응답(200)을 받는 것까지 확인했습니다. 9월 9일 판정은 "특정 앱에 신규로 추가할 수 없다"까지만 맞았습니다.

이때 항목을 지우지 않고 맨 위에 정정 표시를 달았습니다. "없다"는 판정은 "있다"보다 훨씬 강한 증명이 필요하다는 교훈과 함께요. 부재를 단정하기 전에 계정의 앱 목록 전체를 열어 봐야 했습니다. 기각 목록은 금지 목록이면서, 저희가 틀렸던 자리의 기록이기도 합니다.

실제 견적 협상에서는 어떻게 쓰였나?

2026년 10월 7일, 한 고객사 홈페이지 재견적을 확정하면서 이 목록을 다시 썼습니다. 견적서를 내기 전에 여러 관점에서 공격적으로 검토하는 패널을 돌렸고, 개선 제안 15건이 나왔습니다.

15건을 전부 반영하면 견적 범위가 커집니다. 대표 지시는 "일 키우지 않는 쪽으로 해. 전화상으로 요구한 것까지만 받아"였습니다. 그래서 고객이 요구하지 않은 네 가지(알림톡, 지사별 알림, 2단계 인증, 접근성)는 범위에서 빼고 `docs/REJECTED.md`에 사유와 함께 올렸습니다.

이렇게 해 두면 다음 세션이 이 고객사 작업을 이어받을 때 "2단계 인증을 넣으면 좋겠다"는 제안을 신선한 아이디어로 다시 들고 오지 않습니다. 고객 요구가 아니라서 뺐다는 판정이 세션을 넘어 살아남기 때문입니다. 비슷한 승인 흐름 문제는 AI 에이전트 승인 요청 병목에서도 다뤘습니다.

이 방법으로 막지 못하는 것은 무엇인가?

기각 목록은 "이미 죽인 방향"을 막을 뿐, 새로 생기는 잘못된 방향은 막지 못합니다. 그 예도 목록 안에 있습니다. 2026년 8월 13일, 대표가 "왜 커밋·푸시를 매번 승인받느냐"고 물은 것을 에이전트가 "그럼 막아야 할 main 브랜치 푸시는 왜 안 막고 있나"로 넓혀 새 차단 훅을 세웠습니다. 그날 밤 문서만 고친 커밋 4개가 그 차단에 걸렸습니다. 마찰을 없애 달라는 요구를 새 차단으로 갚은 셈이었고, 이 역시 사후에 기각 목록으로 올라갔습니다.

또 하나, 목록이 길어질수록 세션 시작 때 에이전트가 읽어야 할 분량이 늘어납니다. 그래서 항목마다 "다시 제안 금지" 범위를 좁고 구체적으로 적고, 재개 조건이 충족된 항목은 해제 이력으로 내립니다.

• 세 저장 계층에 '하지 않기로 한 것'을 담는 칸이 있는지 먼저 확인한다
• 기각 판정은 사실이 아니라 판정과 사유째 저장한다. git 이력은 사실만 남긴다
• 저장한 판정이 세션 시작 때 눈앞에 오게 만든다. 파일만 있으면 읽히지 않는다
• 재개 조건은 숫자나 명시 발화로 적는다
• 틀린 기각은 지우지 않고 정정 표시를 단다

AI 에이전트에게 일을 맡기면서 같은 제안을 반복해서 거절하고 있다면, 에이전트 메모리 구조부터 같이 살펴볼 수 있습니다. 상담으로 남겨 주세요.