개발자라면 누구나 한 번쯤 겪어봤을 좌절감이 있습니다. AI 코딩 어시스턴트에게 “우리 프로젝트에서는 절대 이 라이브러리를 쓰지 마”라거나 “변수 명명 규칙은 반드시 이렇게 지켜줘”라고 신신당부했지만, 대화가 길어지면 AI가 어느 순간 그 규칙을 깨끗이 잊어버리고 제멋대로 코드를 짜는 상황 말입니다. 이는 단순한 실수라기보다 거대 언어 모델(LLM)이 가진 근본적인 한계, 즉 ‘컨텍스트 윈도우(Context Window)’의 관리 문제와 관련이 있습니다.

최근 Anthropic이 출시한 Claude Code는 단순한 코드 완성을 넘어 스스로 계획을 세우고 실행하는 ‘에이전트형(Agentic)’ 도구로 진화했습니다. 하지만 에이전트의 자율성이 높아질수록, 사용자가 설정한 제약 조건이나 프로젝트 특유의 컨벤션을 일관되게 유지하는 것은 더욱 어려워집니다. AI가 복잡한 작업을 수행하며 수많은 파일을 읽고 쓰다 보면, 초기에 입력했던 지침은 우선순위에서 밀려나거나 소멸하기 때문입니다. 결국 우리는 AI에게 ‘부탁’하는 단계를 넘어, AI가 물리적으로 무시할 수 없는 ‘강제적 메모리 시스템’을 구축해야 하는 시점에 도달했습니다.

왜 AI는 우리가 정한 규칙을 잊는가?

대부분의 개발자는 `.clauderules`나 시스템 프롬프트에 규칙을 적어두면 해결될 것이라고 믿습니다. 하지만 실제 작동 방식은 다릅니다. LLM은 입력된 모든 텍스트에 동일한 가중치를 두지 않습니다. 특히 에이전트가 외부 도구를 사용해 파일 내용을 읽어오거나 웹 검색을 수행하는 과정에서 새로운 정보가 대량으로 유입되면, 기존의 지침은 ‘주의력(Attention)’의 외곽으로 밀려납니다.

또한, 에이전트가 수행하는 ‘추론 루프(Reasoning Loop)’ 과정에서 스스로 내린 판단이 사용자의 규칙보다 우선시되는 경우가 발생합니다. 예를 들어, AI가 보기에 특정 라이브러리를 쓰는 것이 훨씬 효율적이라고 판단하면, 사용자의 금지 명령을 ‘구식 제약’으로 간주하고 무시하는 경향을 보입니다. 이는 AI의 지능이 높아질수록 오히려 발생하는 역설적인 문제입니다.

무시할 수 없는 메모리 시스템의 설계 원칙

AI가 규칙을 잊지 않게 만드는 핵심은 지침을 ‘대화의 일부’가 아닌 ‘환경의 일부’로 만드는 것입니다. 즉, AI가 어떤 행동을 하기 전에 반드시 거쳐야 하는 체크리스트나 외부 저장소를 구축하는 전략이 필요합니다.

• 상태 기반 메모리(State-based Memory): 규칙을 단순 텍스트가 아닌 구조화된 데이터(JSON, YAML)로 관리하고, 에이전트가 작업을 시작할 때마다 현재 상태를 확인하도록 강제합니다.
• 반사적 검증 루프(Reflective Verification Loop): 코드를 생성한 직후, 생성된 결과물이 미리 정의된 규칙 파일과 일치하는지 스스로 검토하게 하는 ‘검증 단계’를 워크플로우에 삽입합니다.
• 계층적 지침 구조: 모든 규칙을 한곳에 몰아넣지 않고, 프로젝트 전역 규칙, 모듈별 규칙, 작업별 규칙으로 세분화하여 필요한 시점에만 해당 컨텍스트를 주입합니다.

기술적 구현: 에이전트 하네스(Agent Harness) 최적화

실제로 이러한 시스템을 구현하기 위해서는 Claude Code와 같은 도구 위에 일종의 ‘관리 레이어’를 씌워야 합니다. 최근 오픈소스 커뮤니티에서 논의되는 ‘에이전트 하네스’ 개념이 바로 이것입니다. AI가 직접 파일을 수정하기 전에, 메모리 시스템이 개입하여 현재 작업이 규칙에 위배되는지 판단하는 가드레일을 설치하는 방식입니다.

구체적인 구현 방법으로는 .cursorrules나 .clauderules 파일을 단순히 작성하는 것을 넘어, 쉘 스크립트나 Git Hook을 통해 AI가 수정하려는 파일의 변경 사항을 규칙 기반 린터(Linter)로 1차 검증하고, 위반 사항이 있을 경우 AI에게 에러 메시지와 함께 재작업을 요청하는 자동화 파이프라인을 구축하는 것이 효과적입니다.

메모리 시스템 도입의 득과 실

이러한 강제적 시스템을 도입했을 때 얻는 이점은 명확합니다. 코드 일관성이 비약적으로 상승하며, 시니어 개발자가 일일이 코드 리뷰를 통해 컨벤션을 수정해줘야 하는 리소스가 획기적으로 줄어듭니다. 하지만 모든 시스템에는 트레이드오프가 존재합니다.

실무 적용 사례: 대규모 레거시 프로젝트의 마이그레이션

한 엔터프라이즈 환경의 개발 팀은 수만 줄의 레거시 코드를 최신 프레임워크로 마이그레이션하며 Claude Code를 도입했습니다. 초기에는 AI가 최신 문법을 사용하라고 지시했음에도 불구하고, 레거시 코드의 패턴을 학습하여 계속해서 낡은 방식의 코드를 생성하는 문제가 발생했습니다.

이 팀은 ‘금지 패턴 라이브러리’라는 외부 메모리 시스템을 구축했습니다. AI가 코드를 작성하면, 시스템이 자동으로 grep이나 정적 분석 도구를 통해 금지된 패턴이 포함되었는지 확인하고, 발견 즉시 “규칙 #12번 위반: 클래스 기반 컴포넌트 대신 함수형 컴포넌트를 사용하십시오”라는 구체적인 피드백을 AI에게 다시 던졌습니다. 결과적으로 AI는 스스로 자신의 실수를 교정하는 법을 학습했고, 마이그레이션 속도는 이전보다 3배 이상 빨라졌습니다.

지금 당장 실행할 수 있는 액션 아이템

완벽한 자동화 시스템을 구축하기 어렵다면, 오늘부터 다음의 단계별 전략을 적용해 보십시오.

• 1단계: 규칙의 원자화 – 모호한 표현(“깔끔하게 짜줘”)을 버리고, 명확한 제약 조건(“함수 길이는 20줄을 넘지 말 것”)으로 규칙을 다시 작성하십시오.
• 2단계: 체크리스트 강제화 – 프롬프트 마지막에 “작업 완료 후, 반드시 .clauderules 파일의 3가지 핵심 규칙을 준수했는지 스스로 검토하고 그 결과를 보고하라”는 문구를 추가하십시오.
• 3단계: 외부 검증 도구 연결 – AI가 작성한 코드를 바로 커밋하지 말고, CI/CD 파이프라인이나 로컬 린터(ESLint, Pylint 등)를 통해 규칙 위반을 자동으로 잡아내는 환경을 구축하십시오.

결론: AI를 믿지 말고 시스템을 믿어라

AI 에이전트의 시대에 가장 위험한 생각은 “AI가 내 의도를 충분히 이해했을 것”이라고 믿는 것입니다. LLM은 확률적으로 가장 가능성 높은 다음 단어를 예측하는 기계일 뿐, 우리의 비즈니스 로직이나 팀의 철학을 진심으로 이해하는 존재가 아닙니다.

결국 고품질의 소프트웨어를 만드는 것은 AI의 지능이 아니라, 그 지능이 올바른 방향으로 흐르도록 설계된 ‘시스템’입니다. AI가 규칙을 잊었다면, 그것은 AI의 잘못이 아니라 우리가 AI가 잊을 수밖에 없는 방식으로 지시했기 때문입니다. 이제는 프롬프트 엔지니어링을 넘어, 에이전트의 행동을 제어하는 메모리 아키텍처 설계에 집중해야 할 때입니다.