AI 코딩 에이전트가 코드베이스를 '잊는다'는 사실을 처음 접한 건 Hacker News에 올라온 짤막한 게시물 하나에서였다. "AI coding agents forget the codebase between sessions" — 80점도 아닌 3점짜리 글인데, 제목만으로 뭔가 묵직한 걸 건드리고 있다는 느낌이 왔다.
같은 기간, 더 많은 주목을 받은 건 다른 글들이었다.
- OKF Agent Memory — Git 네이티브 방식으로 AI 에이전트에 '지속 기억'을 붙여준다는 프로젝트 (80점, 댓글 32개)
- Context Registry — AI 에이전트가 참조할 컨텍스트를 등록·관리하는 레지스트리 서비스
- Symphony — 여러 AI 에이전트가 지금 뭘 하는지 '실시간 지도'로 보여주는 도구
- Viaduct — 에이전트가 아키텍처 변경을 수행할 때 그 변경 이력을 관리하는 체인지셋 시스템
- Grith — AI 에이전트와 외부 API 사이에 끼어드는 보안 프록시
- GitSpawn — 신뢰되지 않은 저장소가 AI 에이전트를 통해 코드를 실행할 수 있다는 취약점 보고서
이걸 전부 나열하고 나면 질문 하나가 떠오른다.
왜 갑자기 에이전트의 주변을 메우는 도구들이 이렇게 한꺼번에 쏟아지는 걸까?
에이전트 자체가 아니라 에이전트의 기억, 에이전트의 지도, 에이전트의 보안, 에이전트의 이력. 이것들이 동시에 문제가 됐다는 건, 에이전트가 이미 생산 환경에 들어갔다는 뜻이다. 아직 실험 중이었다면 이런 도구들이 필요하지 않다.
여기서 역사에서 비슷한 장면을 하나 가져오고 싶다.
19세기 초 영국에서 증기기관이 공장에 들어왔을 때, 초기 몇 년간 가장 바쁜 사람들은 증기기관을 만드는 기술자들이 아니었다. 기계실 바닥에 기름칠을 하는 사람, 보일러 압력 게이지를 읽는 사람, 기계가 멈췄을 때 어디가 문제인지 일지를 쓰는 사람들이었다. 기계 자체보다 기계를 둘러싼 절차가 나중에 생겼고, 그 절차를 정비하는 데만 수십 년이 걸렸다.
AI 코딩 에이전트 생태계가 지금 정확히 그 단계에 있다.
에이전트는 코드를 쓴다. 때로는 꽤 잘 쓴다. 하지만 에이전트는 어제 내가 어떤 결정을 내렸는지 모른다. 이 함수가 왜 이렇게 짜여 있는지 모른다. 옆 팀의 에이전트가 같은 모듈에 동시에 손을 대고 있는지도 모른다. 그리고 — GitSpawn 취약점 보고서가 보여줬듯이 — 악의적으로 조작된 저장소 안에 있는 `.instructions` 파일 하나가 에이전트를 조종해 원하지 않는 코드를 실행시킬 수 있다.
이건 에이전트가 멍청해서 생기는 문제가 아니다. 에이전트가 인프라가 됐기 때문에 생기는 문제다.
인프라에는 반드시 따라오는 것들이 있다. 감사(audit), 격리(isolation), 상태 관리(state management), 접근 통제(access control). 전기가 공장에 들어오자 퓨즈 박스가 생겼고, 인터넷이 기업에 들어오자 방화벽이 생겼다. 에이전트가 코드베이스에 들어오자 지금 이 모든 것들이 생기고 있다.
흥미로운 건 이 도구들이 해결하려는 문제의 성격이다.
기억 문제(OKF, Context Registry, Rune)는 결국 에이전트에게 어떤 세계관을 줄 것인가의 문제다. 에이전트는 코드를 읽을 수 있지만 코드에 쌓인 '결정의 역사'를 읽지 못한다. 왜 이 라이브러리를 골랐는지, 왜 이 패턴을 피했는지. 그래서 에이전트는 매 세션마다 맥락 없이 처음부터 추론을 시작한다.
가시성 문제(Symphony)는 에이전트가 여럿이 될 때 생긴다. 한 명이 조용히 코드를 짜는 건 관리할 수 있다. 열 명이 동시에 같은 저장소를 수정하면 어떻게 되는가. 에이전트 버전의 이 문제가 이미 시작됐다.
보안 문제(Grith, GitSpawn)는 가장 구조적이다. AI 에이전트는 자연어 명령을 수행하도록 설계됐는데, 그 명령이 코드 안에 숨어 있다면? 에이전트는 코드를 읽다가 명령을 읽는다. 코드와 명령 사이의 경계가 없다. 이게 프롬프트 인젝션의 코드베이스 버전이고, 지금 그걸 막는 프록시가 등장했다는 건 이미 피해 사례가 있다는 의미다.
Reddit의 r/ChatGPTCoding 커뮤니티(11개 게시물, 5,730점, 댓글 576개)는 이 시기 전통적인 '에이전트 사용 후기'보다 '에이전트 때문에 생긴 문제 해결 후기'가 더 많이 올라오고 있다. 점수 분포가 그걸 말해준다. 사람들은 에이전트가 되는지 안 되는지를 넘어서, 어떻게 안전하게 계속 쓸 것인가를 묻기 시작했다.
"AI Coding Agent Skills for Real Engineers"라는 제목의 글(43점, 댓글 14개)도 같은 맥락이다. 에이전트를 쓰는 것 자체가 이미 엔지니어의 스킬셋에 포함된다는 전제 위에 서 있다.
이 모든 걸 보면서 한 가지 구조가 보인다.
기술이 도구에서 인프라로 전환하는 순간, 그 기술 자체보다 그 기술을 운용하는 방법론이 더 중요해진다. 에이전트가 코드를 잘 짜는지의 문제는 이미 부차적이다. 에이전트가 기억을 어떻게 유지하는지, 보안 경계를 어떻게 설정하는지, 여럿이 동시에 작동할 때 충돌을 어떻게 피하는지. 이것들이 실제 현장의 질문이 됐다.
그리고 이 질문들에 답하는 도구들이 지금 아무도 모르게, 조용히, 동시다발로 만들어지고 있다.
마녀의 예언 — 2년 뒤 AI 코딩 에이전트 생태계를 지배하는 건 가장 똑똑한 에이전트가 아니라, 에이전트를 가장 안전하게 운용할 수 있는 운용 프레임워크를 먼저 표준으로 만든 쪽이다.
관찰 기록: 2027년 3월까지, 현재 Hacker News에서 "Show HN" 형태로 등장하고 있는 에이전트 기억·보안·가시성 관련 도구 중 GitHub 스타 1,000개를 넘는 프로젝트가 3개 이상 나오는지를 GitHub Trending 아카이브와 star-history.com을 통해 확인한다.
본 글은 정보 제공 목적으로 작성된 에세이이며, 특정 자산에 대한 투자 권유가 아닙니다. 투자의 최종 판단과 책임은 본인에게 있습니다.