AI 에이전트가 '까먹는' 건 버그가 아니다
"분명히 컨벤션 지키라고 했는데, 다섯 프롬프트 지나니까 다시 제멋대로 짜고 있어요."
Reddit, Discord, X(트위터)—AI 코딩 에이전트를 실무에 도입한 개발자들이 공통으로 겪는 좌절이다. 에이전트가 '기억을 잃어버린 것처럼' 행동하는 이 현상, 버그가 아니다. 컨텍스트 압축(context compression)이 설계대로 작동한 결과다. Five Things Your Coding AI Agent Wishes You Understood(dev.to)가 지적하듯, LLM은 호출 간 영구 상태(persistent state)를 갖지 않는다. '기억'처럼 느껴지는 건 매 턴마다 대화 히스토리 전체를 프롬프트로 재전송하는 것뿐이다. 컨텍스트 창이 차면 오래된 메시지부터 요약·삭제된다. 여러분의 아키텍처 결정이 그렇게 사라진다.
프롬프트 드리프트: 의도와 결과 사이의 조용한 균열
There's an Entire Ecosystem Yet to Be Built(dev.to)는 이 현상에 이름을 붙인다—프롬프트 드리프트(Prompt Drift). 개발자가 에이전트에게 원하는 걸 전달했다고 생각하지만, LLM은 '해피 패스 코딩'으로 흘러간다. 겉보기엔 동작하는 것 같은데, 실제로는 핵심 기능이 비어 있다. 더 심각한 건 그 의도가 어디에도 기록되지 않는다는 점이다. 3개월 뒤 그 코드를 다시 열었을 때 "왜 이렇게 지었지?"라는 물음에 답할 수 있는 사람이 없다. git 히스토리에 커밋 메시지는 있어도, 그 코드를 낳은 대화 컨텍스트는 증발해 있다.
기존 코드 리뷰 도구들(BugBot, CodeRabbit, Greptile 등)이 diff와 커밋 구조에서 의도를 추론할 수밖에 없는 이유가 여기 있다. 실제 인텐트는 애초에 어디에도 저장되지 않았으니까.
첫 번째 축: 인텐트를 코드와 함께 저장하라
이 문제에 직접 응답하는 도구가 Entire다. CLI 형태로 동작하며, 에이전트 세션 전체를 캡처해 git 커밋에 붙인다. 코드 히스토리와 프롬프트 히스토리가 나란히 살아남는 구조—이 '체크포인트(Checkpoint)' 개념이 핵심이다. 설치 후엔 IDE 훅에 자동으로 붙기 때문에 별도의 관리 오버헤드가 없다.
중요한 건 Entire 자체보다 그것이 여는 가능성이다. 인텐트가 .entire 폴더에 구조적으로 저장되는 순간, 그 데이터를 읽는 새로운 툴링 레이어가 가능해진다. 글쓴이가 만든 Nimbus가 그 사례다—diff와 프롬프트 히스토리를 함께 읽어 "이 코드가 당신이 만들려 했던 것과 실제로 일치하는가?"를 묻는 코드 리뷰 도구다. 기존 도구가 답하지 못했던 질문이다.
두 번째 축: 스킬로 CLI 오케스트레이션을 구조화하라
프롬프트 드리프트의 다른 원인은 반복 지시의 비효율이다. 매번 "우리 프로젝트는 conventional commits 써"라고 알려줘야 한다면, 그건 시스템이 아니라 수작업이다.
Skills Are the New CLI(dev.to)는 이 문제를 스킬 파일로 해결한다. 단일 마크다운 파일(SKILL.md)로 정의되는 스킬은 git, npm, gh 등 기존 CLI를 오케스트레이션하면서, 동시에 프로젝트 컨텍스트를 자동으로 선로딩한다. ! 접두사로 시작하는 명령은 스킬 활성화 순간 셸을 실행해 최신 git 상태·diff·로그를 에이전트에게 주입한다. 에이전트가 프로젝트를 '알고 있는 상태'에서 작업을 시작하는 것이다.
더 강력한 건 자연어 트리거다. description 필드가 활성화 조건을 정의하기 때문에, "기능 다 됐어, 테스트 돌리고 PR 열어줘" 한 문장이 validate-code → ship → create-pull-request 세 스킬을 순서대로 호출한다. 슬래시 명령도 없고, 수동 파이프도 없다. 의도를 기술하면 스킬이 실행 계획을 세운다.
그리고 이 스킬은 Claude Code, Cursor 등 주요 에이전트 툴에서 동일하게 동작하는 오픈 스탠다드를 따른다. 도구를 바꿔도 스킬 파일은 이식된다.
세 번째 축: '전부 프롬프팅'이라는 사실을 메모리 설계에 적용하라
dev.to의 코딩 에이전트 심층 분석이 강조하는 핵심 명제가 있다—에이전트의 모든 행동은 프롬프트의 결과다. 시스템 프롬프트, 툴 설명, 스킬 파일, 대화 히스토리—이 모두가 컨텍스트 창으로 흘러드는 텍스트다. 에이전트를 '설정'하는 게 아니라 '프롬프팅'하는 것이다.
이걸 이해하면 메모리 설계가 달라진다. Claude Code의 CLAUDE.md 혹은 Cursor의 Rules 파일은 컨텍스트 압축 사이클에서 살아남는 영구 인스트럭션이다. 아키텍처 결정, 코딩 컨벤션, 반드시 지켜야 할 경계—이런 정보는 대화 안에 두면 압축에 희생된다. memory/ 디렉터리나 프로젝트 루트의 설정 파일에 외부화해야 컨텍스트 창 순환에 독립적으로 살아남는다.
툴도 마찬가지다. MCP 툴이 많아지면 툴 설명만으로도 컨텍스트를 잠식한다. Claude Code의 ENABLE_TOOL_SEARCH 옵션이 활성화되면 긴 툴 목록이 ToolSearch 단일 인터페이스로 치환된다—필요할 때만 불러오는 온디맨드 로딩이다. 컨텍스트 창을 예산처럼 관리하는 사고방식이 여기서 빛난다.
시사점: '에이전트를 제대로 쓰는 법'은 구조 문제다
세 소스가 수렴하는 지점은 하나다—에이전트 워크플로우의 품질은 프롬프트 작성 실력보다 구조 설계에 달려 있다.
- 인텐트 캡처: 프롬프트-코드 연결을 커밋 단위로 저장하지 않으면, 미래의 당신도 AI도 '왜'를 알 수 없다.
- 스킬 오케스트레이션: 반복 지시를 스킬 파일로 외부화하면, 에이전트는 컨텍스트를 '받는' 게 아니라 '선로딩'한다.
- 메모리 계층 분리: 지속돼야 할 정보는 압축 사이클 바깥에 두어야 드리프트를 막을 수 있다.
이 세 축이 없으면 에이전트는 강력한 일회성 도구에 머문다. 세 축이 갖춰지면 에이전트는 프로젝트의 맥락을 유지하는 파트너로 작동하기 시작한다.
전망: 인텐트가 새로운 소스코드가 된다
"머신이 만든 아티팩트를 읽는 도구"의 시대에서 "인간의 인텐트를 읽는 도구"의 시대로—이게 Entire 같은 툴이 열고 있는 방향이다. 린터, 리뷰 도구, 문서 생성기가 diff가 아니라 프롬프트 히스토리를 소스로 쓸 수 있다면, 코드 리뷰의 질문 자체가 바뀐다. "이 코드가 컨벤션에 맞나?"에서 "이 코드가 처음 의도한 것을 구현했나?"로.
스킬 파일이 CLI의 진화라면, 인텐트 캡처는 git의 진화다. 지금은 초기 에코시스템이지만, 이 레이어 위에 쌓일 툴링을 생각하면 지금 구조를 잡아두는 게 이득이다. 결국 프롬프트 드리프트를 막는 가장 확실한 방법은—드리프트할 여지 없이, 처음부터 컨텍스트를 구조로 설계하는 것이다.