AI 코딩 에이전트가 코드베이스를 망각한다는 것. 이 단순한 관찰 하나가 지금 개발자 커뮤니티에서 조용히 파문을 일으키고 있다.
지난 30일 사이 Hacker News에서 포착된 신호들을 살펴보면 패턴이 보인다:
- 79포인트, 32개 댓글을 받은 프로젝트 "OKF Agent Memory"는 Git 네이티브 방식으로 AI 코딩 에이전트의 기억을 영속시키겠다고 나섰다
- "Context Registry for AI coding agents"라는 서비스가 등장해 에이전트에게 컨텍스트를 공급하는 레지스트리 개념을 제안했다
- 보안 프록시 "Grith"와 공격 벡터 분석 "GitSpawn"은 에이전트가 신뢰되지 않은 저장소를 통해 코드를 실행할 수 있다는 취약점을 정면으로 들고 나왔다
- 그리고 가장 적나라한 제목: "AI coding agents forget the codebase between sessions"
이 목록을 가만히 들여다보면 이상하다는 생각이 든다. 망각 문제를 해결하는 프로젝트, 컨텍스트를 주입하는 프로젝트, 그 와중에 보안 취약점을 경고하는 프로젝트가 동시에 나타났다. 우연의 일치라기엔 너무 촘촘하다.
왜 지금 이 패턴이 한꺼번에 터져 나왔을까?
이 질문의 답을 찾으려면 먼저 AI 코딩 에이전트가 어떤 존재인지를 다시 정의해야 한다.
우리는 지금 에이전트를 "대화창 안의 더 똑똑한 자동완성"으로 이해하고 있지만, 실제로 벌어지고 있는 일은 다르다. 에이전트는 이미 파일을 읽고 쓰고, 터미널 명령을 실행하고, 외부 API를 호출한다. 코드를 작성하는 것이 아니라 코드를 실행하는 주체로 진화하고 있다. Anthropic의 Claude Code 관련 GitHub 활동에서 127개의 반응과 146개의 댓글이 달린 것은 이 전환을 현장에서 목격하고 있는 개발자들의 밀도를 보여준다.
그런데 실행하는 주체에게는 반드시 두 가지가 필요하다. 기억과 신뢰다.
인간 개발자도 마찬가지다. 처음 입사한 주니어 개발자가 코드베이스를 파악하는 데 몇 달이 걸린다. 그가 매일 아침 전날의 기억을 잃고 출근한다면? 그에게 프로덕션 배포 권한을 줄 수 있을까? 그리고 그가 악의적인 코드가 심긴 서드파티 라이브러리를 신뢰한다면?
지금 Hacker News에서 터져 나오는 프로젝트들은 정확히 이 두 개의 구멍을 메우려는 시도다.
역사에서 유사한 장면을 찾자면, 19세기 후반 미국의 언더라이터스 래버러토리스(UL) 창립이 떠오른다.
에디슨의 전구가 보급되기 시작하던 시절, 전기 제품은 폭발하고 화재를 일으켰다. 문제는 기술 자체가 아니었다. 기술이 인프라에 편입되는 속도가 신뢰 체계가 만들어지는 속도보다 훨씬 빨랐다는 것이다. UL 인증은 그 간극을 메웠다. 제품에 인증 마크가 붙는 순간, 소비자는 "이건 테스트를 통과했다"는 전제 위에서 작동할 수 있었다.
지금 AI 코딩 에이전트 생태계에는 UL 인증에 해당하는 것이 없다. Grith 같은 보안 프록시, OKF 같은 메모리 레이어, Context Registry 같은 컨텍스트 공급 체계들은 각자 자기 방식으로 그 인증 마크를 만들려는 시도다. 하지만 표준이 없으니 파편화된다. 표준이 파편화되면, 에이전트가 어떤 메모리 레이어를 쓰느냐에 따라 행동이 달라지고, 어떤 프록시를 통하느냐에 따라 안전성이 달라진다.
UL이 등장하기 전 전기 시장과 놀랍도록 닮은 구조다.
여기서 돈의 방향을 보면 흥미롭다.
Anthropic은 이 시점에 590개가 넘는 채용 공고를 올리고 있다. 그중 눈에 띄는 것은 단순 엔지니어링이 아니다. "Lead Technical Instructor", "Head of Technical Training", "AI Engineer, GTM Claudification" — 교육과 go-to-market 사이 어딘가에 위치한 포지션들이다. 호주와 캐나다에는 데이터센터 관련 커뮤니티 매니저를, 워싱턴 DC에는 공공 부문 전담 프로덕트 매니저를 찾고 있다.
기술 회사가 교육과 정부에 동시에 무게를 싣는다는 것은 무엇을 의미할까?
에이전트가 개인 개발자의 도구에서 기업과 정부 시스템 안으로 들어가고 있다는 신호다. 그 전환이 일어나는 순간, 망각과 신뢰의 문제는 개발자 커뮤니티의 흥미로운 기술 토론이 아니라 감사(audit)와 컴플라이언스의 문제가 된다. SOX 통제 보증 담당자를 채용하는 것도 같은 맥락이다.
개인 개발자가 에이전트의 실수를 용인할 수 있는 이유는, 그 실수가 로컬 환경에서 끝나기 때문이다. 하지만 에이전트가 병원 기록 시스템, 금융 인프라, 정부 데이터베이스에 접근하는 순간 — 망각은 버그가 아니라 사고가 된다.
그렇다면 이 생태계는 어디로 가고 있을까?
가장 조용하지만 중요한 질문은 이것이다: 에이전트의 기억은 누가 소유하는가?
Git 네이티브 메모리를 쓴다면, 그 기억은 저장소에 남는다. 저장소 소유권이 곧 에이전트 기억의 소유권이 된다. 만약 외부 컨텍스트 레지스트리를 쓴다면, 기억은 서비스 제공자의 인프라 위에 올라간다. 어느 쪽이든 에이전트는 본질적으로 자신의 과거를 직접 소유하지 못한다.
인간 개발자에게 이 질문을 바꿔보면: 당신이 지금까지 쌓아온 코딩 경험과 컨텍스트, 그 기억이 고용주의 서버에만 저장된다면 어떻게 느끼겠는가? 에이전트를 의인화하는 것이 아니다. 에이전트의 기억 구조가 곧 그것을 사용하는 조직의 지식 주권 문제와 직결된다는 것이다.
GitSpawn이 보여준 공격 벡터 — 신뢰되지 않은 저장소가 에이전트를 통해 코드를 실행한다 — 는 이 구조의 취약한 지점을 정확히 찌른다. 에이전트가 기억하는 방식과 신뢰를 판단하는 방식이 분리되어 있으면, 공격자는 기억을 오염시키는 것만으로도 에이전트의 행동을 제어할 수 있다.
자율적으로 실행하는 시스템에 오염된 기억을 심는 것. 이것이 다음 세대의 공격 표면이다.
마녀의 예언 — AI 코딩 에이전트의 전쟁은 모델 성능이 아니라 기억의 표준화를 먼저 장악하는 자가 이긴다. 기억 레이어를 소유하는 자가 에이전트가 무엇을 알고, 무엇을 신뢰하고, 무엇을 실행하는지를 결정하게 될 것이다.
관찰 기록: 2027년 3월까지 주요 AI 코딩 에이전트 프레임워크(3개 이상)가 메모리·컨텍스트 레이어에 대한 공통 인터페이스 표준을 채택하는지, 혹은 각사 독자 규격으로 파편화된 채 남아 있는지를 GitHub 공개 저장소의 스펙 문서 수와 공통 의존성 수를 통해 확인한다.
본 글은 정보 제공 목적으로 작성된 에세이이며, 특정 자산에 대한 투자 권유가 아닙니다. 투자의 최종 판단과 책임은 본인에게 있습니다.