AI 메모리는 언제 프로젝트 밖의 '공통 규칙'이 될까?

한 프로젝트에서 잘 통했던 규칙을 다른 프로젝트에서도 바로 쓰면 더 똑똑해지는 걸까요?
AI가 기억을 많이 할수록 편해 보이지만, 실제로는 기억의 범위가 넓어질수록 엉뚱한 전제가 따라올 위험도 커집니다.
어제의 정답이 오늘의 다른 저장소에서는 조용한 오답이 될 수 있으니까요.

여기서 필요한 것이 메모리 범위(scope) 입니다.
메모리 범위란 AI가 저장한 사실이나 규칙이 어느 맥락에서만 유효한지 표시하는 기준입니다.
이 기준은 기억을 많이 모으는 기술이 아니라, 기억을 어디까지 믿어도 되는지 정하는 규칙에 가깝습니다.

가장 흔한 혼동: 유용했던 규칙은 곧 공통 규칙이다

가장 위험한 마음속 공식은 이렇습니다.
“A 프로젝트에서 효과가 있었으니, 다음 프로젝트에서도 기본값으로 쓰자.”
이 공식은 빠르고 편합니다.
하지만 한 프로젝트의 구조, 팀 약속, 제품의 상태, 배포 방식에 맞춘 판단까지 공통 규칙으로 올리면, 다른 프로젝트는 시작부터 남의 안경을 쓰게 됩니다.

그래서 메모리 범위 규칙은 프로젝트 범위를 기본값으로 둡니다.
특정 저장소나 제품에 연결된 관례, 설계 결정, 진행 상태는 우선 그 프로젝트 안에 저장합니다.
반면 여러 프로젝트에 걸쳐 적용되는 선호, 작업 흐름, 도구 기본값, 넘지 말아야 할 경계는 전역 범위의 후보가 될 수 있습니다.

분류가 애매하다면 더 좁게 보관하는 편이 낫습니다.
소스는 프로젝트 전용 사실을 나중에 다시 찾는 비용보다, 너무 넓은 가정이 다른 세션에 끼치는 비용이 더 크다고 봅니다.
AI는 기억을 잊었다고 삐치지 않습니다 (아마도요).
하지만 잘못 일반화된 규칙은 아주 성실하게 엉뚱한 조언을 반복할 수 있습니다.

생활 비유: 냉장고 메모와 집안 공지

이 차이를 냉장고 메모로 생각해 봅시다.
“이 반찬은 오늘 먼저 먹기”는 특정 냉장고에 붙여야 하는 메모입니다.
그 문장을 아파트 전체 공지판에 붙이면, 이웃은 이유도 모른 채 자기 반찬부터 찾게 됩니다.

반대로 “공용 현관문은 닫고 나가기”처럼 여러 집에 같은 방식으로 적용되는 원칙은 공지판에 둘 만합니다.
프로젝트 메모는 냉장고 메모이고, 전역 메모리는 공용 공지에 가깝습니다.
둘 다 필요하지만, 붙이는 위치를 바꾸는 일에는 근거가 필요합니다.

승격: 서로 다른 두 프로젝트에서 확인한 뒤에

승격(promotion) 은 프로젝트 안에 있던 패턴을 전역 메모리로 옮기는 일입니다.
이 규칙의 문턱은 분명합니다.
같은 피드백이나 행동이 서로 다른 최소 두 프로젝트에서 확인돼야 하고, 그것만으로는 부족합니다. 두 프로젝트는 일회성을 걸러내는 바닥이지 기준이 아닙니다. 그 위에 하나를 더 물어야 합니다 — 이 규칙이 전체 세션 중 어느 정도 비율에서 발동하는가. 답이 "X 작업을 할 때만"이라면 담길 곳은 전역 규칙이 아니라 X를 담당하는 스킬입니다.

왜 하필 두 프로젝트일까요?
한 프로젝트에서 반복된 사례는 그 프로젝트의 특수성일 수 있습니다.
두 곳에서 확인됐다고 해서 자동으로 보편 법칙이 되는 것은 아니지만, 적어도 한 저장소의 우연을 전역 기본값으로 착각하는 일을 줄여 줍니다.
여기서 ‘서로 다르다’는 판단도 기술 스택이 같다는 이유만으로 끝내면 안 됩니다.
어떤 피드백이 정말 독립된 맥락에서 반복됐는지, 근거를 보고 판단해야 합니다.

승격할 때는 문장만 복사하지 않습니다.
전역 규칙에는 출발점이 된 프로젝트를 가리키는 정보나 참조를 남겨 출처를 보존합니다.
그 뒤 프로젝트 쪽의 같은 규칙은 갱신하거나 제거해, 서로 다른 두 버전이 경쟁하지 않게 합니다.
같은 규칙이 양쪽에서 조금씩 달라지면 AI는 누구 말을 들어야 할지 난처해집니다.
규칙도 복제되면 가끔 쌍둥이 싸움을 합니다.

예를 들어 한 프로젝트에서만 “배포 전 이 설정 파일을 확인한다”가 유효했다면 프로젝트 메모입니다.
별도의 다른 프로젝트에서도 같은 확인 절차가 독립적으로 필요하다는 근거가 생겼을 때, 비로소 더 일반적인 작업 원칙으로 승격을 검토할 수 있습니다.
중요한 점은 문장 모양이 아니라 적용 이유가 반복됐는지입니다.

강등: 전역 규칙을 되돌리는 것도 정상이다

강등(demotion) 은 반대 방향의 정리입니다.
전역 메모리라고 믿었던 규칙이 나중에 보니 한 프로젝트에만 맞는 사실이었다면, 그 규칙을 해당 프로젝트 메모리로 되돌리고 전역 규칙 집합에서는 제거합니다.

이 과정은 실패 기록이 아닙니다.
오히려 전역 영역에 프로젝트 고유의 가정이 섞이는 교차 프로젝트 오염을 고치는 안전장치입니다.
승격은 “이제 모두에게 적용된다”는 선언이 아니라, 현재 근거가 허락하는 범위를 신중히 넓히는 판단입니다.
근거가 바뀌면 범위도 다시 좁혀야 합니다.

따라서 전역 메모리를 검토할 때는 다음 질문을 던져 보세요.

• 이 내용은 특정 저장소의 관례, 설계, 진행 상태인가?
• 서로 다른 두 프로젝트에서 같은 이유로 확인됐는가?
• 이 규칙이 발동하는 세션의 비율은 얼마인가? 특정 작업에서만 필요하다면 스킬 쪽이 맞는 그릇 아닌가?
• 원래 프로젝트를 추적할 수 있게 출처를 남겼는가?
• 나중에 한 프로젝트 전용임이 드러나면, 전역에서 지우고 되돌릴 수 있는가?

정리하면 좋은 AI 메모리는 모든 것을 아는 메모가 아니라 범위를 아는 메모입니다.
처음에는 좁게 저장하고, 독립된 증거가 쌓이면 조심스럽게 넓히고, 지나치게 넓혔다면 기꺼이 되돌리세요.
그 습관이 쌓이면 AI는 많은 기억을 가진 도구가 아니라, 맥락을 함부로 넘지 않는 협업자가 됩니다.
다음에 새 규칙을 저장할 때는 한 번만 더 물어보면 됩니다.
“이건 우리 냉장고 메모일까, 모두가 볼 공지일까?”