메모리 주입: 비슷한 기록을 바로 믿지 않기

2026년 5월 4일 | 바이브코딩 Tips

---

코딩 에이전트에 예전 실패 로그를 붙일 때 내가 제일 경계하는 장면은, 정확한 기억보다 비슷한 기억이 너무 자신 있게 들어오는 순간이다. 에러 메시지가 비슷하고, 파일 이름도 어딘가 닮아 있고, 예전에 먹힌 해결책까지 보이면 사람도 쉽게 끌린다. 그런데 실제 원인이 한 끗만 달라도 그 메모리는 도움보다 궤도 고정 장치에 가까워진다.

바이브코딩을 오래 굴리다 보면 컨텍스트를 잘 넣는 것보다 어떤 컨텍스트를 넣지 않을지가 더 어렵다. 처음에는 나도 기억 저장소를 많이 붙이면 에이전트가 더 안정적일 거라고 생각했다. 하지만 실제로는 과거 메모리가 자동으로 들어가는 순간, 에이전트가 현재 증상을 새로 읽기보다 예전 결론을 재현하려는 쪽으로 기울 때가 있었다.

메모리를 가설로 취급하기

과거 기록은 편하다. 특히 같은 저장소에서 반복되는 테스트 실패, 패키지 충돌, 타입 에러, 브라우저 테스트 타이밍 문제는 한 번 잡아두면 다음 번에 바로 꺼내 쓰고 싶어진다. 문제는 메모리가 "과거에는 이렇게 고쳤다"를 넘어 "이번에도 이것이 원인이다"처럼 들어갈 때다. 이 두 문장은 비슷해 보여도 에이전트에게는 완전히 다른 지시다.

나는 그래서 메모리를 프롬프트에 바로 붙이기 전에 작은 거절 칸을 둔다. 후보 메모리가 있어도 곧장 주입하지 않고, 현재 증상과 맞는지 먼저 물어보는 칸이다. 이름은 거창할 필요 없다. 내 노트에서는 그냥 memory gate라고 부른다.

후보 메모리를 곧장 넣지 않고, 거절·확인·제한 주입 중 하나로 먼저 나눈다.

내가 쓰는 세 칸

메모리 후보를 봤을 때 나는 보통 세 칸으로 나눈다. 첫 번째는 no memory다. 증상은 비슷하지만 파일 경로, 실행 환경, 실패 단계가 다르면 그냥 안 넣는다. 에이전트가 이전 해결책에 끌려가는 비용이 새로 읽는 비용보다 클 수 있기 때문이다.

두 번째는 ask feedback이다. 사람이 짧게 확인해야 하는 칸이다. 예를 들어 "이 실패가 지난번과 같은 인증 만료인지, 아니면 이번에는 네트워크 타임아웃인지"처럼 둘 다 가능할 때가 있다. 이때 에이전트가 혼자 결론을 내리면 그럴듯한 추측이 실행으로 넘어간다. 나는 이 칸에 들어간 메모리는 바로 행동하지 말고 질문이나 추가 관찰로 바꾸게 한다.

세 번째는 limited inject다. 메모리를 넣되 해결책 전체를 넣지 않고, 확인해야 할 관찰 포인트만 넣는다. "예전에는 A로 고쳤다" 대신 "A 계열이면 B 로그가 같이 나타난다" 정도만 주는 식이다. 이 방식은 에이전트가 과거 patch를 복붙하는 대신 현재 증거를 다시 대조하게 만든다.

칸	내가 묻는 질문	에이전트에게 허용하는 행동
no memory	비슷하지만 원인 축이 다른가?	현재 로그를 처음부터 읽기
ask feedback	사람 확인 없이는 갈림길이 닫히는가?	추가 질문 또는 관찰 수집
limited inject	검증 신호만 넘겨도 충분한가?	해결책 대신 확인 조건만 사용

비슷한 기록이 위험해지는 신호

가장 흔한 신호는 에이전트가 현재 로그를 충분히 읽기 전에 "이전에 본 문제와 같습니다"라고 말하는 순간이다. 사람 입장에서는 반가운 말인데, 사실 이 말 뒤에는 다른 가능성을 닫는 힘이 숨어 있다. 특히 테스트 실패처럼 출력이 짧고 재현이 쉬운 문제에서는, 이전 기억보다 현재 실패를 한 번 더 재현하는 편이 훨씬 싸다.

두 번째 신호는 해결책 이름이 먼저 나오고 증거가 뒤따라오는 경우다. 예를 들어 "캐시 문제일 가능성이 높으니 지우겠습니다"보다 "캐시 파일의 timestamp가 현재 실행보다 오래됐고, 같은 파일을 읽는 로그가 있으니 캐시를 의심하겠습니다"가 낫다. 순서가 바뀌면 같은 조치라도 훨씬 덜 위험하다.

세 번째는 기억이 너무 넓을 때다. "지난번 인증 문제" 같은 메모리는 거의 쓸모가 없다. 인증 문제 안에도 토큰 만료, 리다이렉트 실패, 권한 범위 오류, 쿠키 저장 실패, 브라우저 프로필 충돌이 섞인다. 메모리는 클수록 좋아지는 게 아니고, 현재 관찰과 대조할 수 있을 만큼 작아야 한다.

프롬프트에 붙이는 작은 계약

나는 메모리 검색을 켜는 작업에서는 아래 같은 짧은 계약을 먼저 붙인다. 핵심은 좋은 기억을 찾는 일보다, 찾은 기억을 바로 믿지 않는 절차에 있다.

후보 메모리를 찾으면 바로 해결책으로 쓰지 말 것.
각 후보를 다음 셋 중 하나로 분류할 것.
- no_memory: 현재 증거와 맞지 않음
- ask_feedback: 사람 확인 없이는 위험함
- limited_inject: 해결책 대신 확인 조건만 사용 가능

limited_inject를 선택한 경우에도 먼저 현재 로그에서 대응 증거를 찾아라.
증거를 찾기 전에는 파일 수정이나 삭제 작업으로 넘어가지 말 것.

이 정도만 붙여도 에이전트의 말투가 꽤 달라진다. 바로 수정안을 내기보다 "이 메모리는 증상은 비슷하지만 경로가 다르다", "이 부분은 확인 후 쓰겠다"처럼 중간 판단을 밖으로 꺼낸다. 나는 이 중간 판단이 실제 패치보다 더 중요할 때가 많다고 본다. 패치는 되돌릴 수 있지만, 잘못된 기억으로 좁아진 탐색은 어느 순간부터 사람이 눈치채기 어렵다.

저장할 때도 거절 이유를 같이 남기기

메모리 주입을 조심하려면 저장 형식도 바뀌어야 한다. 성공한 해결책만 남기면 다음 세션에서 그 해결책이 과잉 대표성을 가진다. 나는 되도록 세 가지를 같이 남긴다. 증상 패턴, 적용 가능한 변형, 검증된 episode다. 여기에 하나를 더 붙이면 좋다. 왜 이번에는 쓰지 않았는지다.

예를 들어 어떤 후보 메모리를 거절했다면 "에러 문자열은 같았지만 실행 단계가 달랐다", "패키지 버전은 같았지만 OS가 달랐다", "이전 해결책은 임시 우회였고 이번에는 원인 수정이 필요했다"처럼 짧게 남긴다. 이 거절 로그가 쌓이면 다음 번에는 검색 점수보다 더 좋은 필터가 된다.

얼마 전에 읽은 코딩 에이전트 메모리 논문에서도 비슷한 문제를 다뤘다. 검색된 기억을 항상 쓰는 대신, no_memory나 abstain 같은 행동을 정책 안에 넣어 false-positive memory injection을 줄이려는 접근이었다. 논문 자체는 더 형식적인 이야기지만, 내 실무 감각으로 번역하면 결국 "기억을 잘 찾는 것"과 "기억을 넣어도 되는 것"은 다른 문제라는 말에 가깝다.

멈춤 기준을 숫자로 작게 두기

메모리 게이트가 흐릿해지는 순간은 대개 후보가 너무 많을 때다. 그래서 나는 후보를 많이 보여 주지 않는다. 보통 세 개를 넘기면 다시 검색어를 좁히고, 첫 후보 하나가 압도적으로 맞아 보여도 현재 로그에서 최소 두 가지 증거를 찾기 전에는 limited inject로 승격하지 않는다. 숫자가 작아야 사람도 중간 판단을 볼 수 있다.

또 하나의 기준은 수정 비용이다. 파일 삭제, 마이그레이션, 설정 변경처럼 되돌리기 귀찮은 행동으로 이어지는 메모리는 ask feedback 쪽으로 보낸다. 반대로 로그 한 번 더 보기, 테스트 하나 재실행하기, 버전 문자열 확인하기처럼 싼 행동으로 끝나는 메모리는 limited inject로 써도 부담이 작다. 기억의 유사도보다 다음 행동의 되돌림 비용을 먼저 보는 셈이다.

작게 시작하는 운영 루프

바로 복잡한 메모리 시스템을 만들 필요는 없다. 나는 작업마다 후보 메모리 1~3개만 열고, 각 후보 옆에 no memory, ask feedback, limited inject 중 하나를 적는 방식으로 시작하는 게 제일 덜 부담스럽다. 자동화라기보다 체크박스에 가까운 루프다.

이 루프의 장점은 실패했을 때도 흔적이 남는다는 점이다. 에이전트가 엉뚱한 과거 해결책으로 달려갔다면, 다음에는 그 메모리 앞에 "이 조건에서는 쓰지 말 것"을 붙이면 된다. 반대로 limited inject가 잘 먹혔다면, 해결책 본문보다 확인 조건을 더 선명하게 다듬으면 된다.

바이브코딩에서 메모리는 점점 더 중요해질 것이다. 세션은 길어지고, 프로젝트는 여러 날에 걸치고, 에이전트는 과거 기록을 더 쉽게 검색한다. 그래서 나는 메모리를 많이 넣는 쪽보다, 넣기 전에 한 번 거절할 수 있는 구조를 먼저 잡아두는 편이 안전하다고 느낀다. 기억이 많은 에이전트보다, 어떤 기억을 잠깐 보류할 줄 아는 에이전트가 더 오래 간다.