에이전트는 작동한다. 문제는 그다음이다
AI 코딩 에이전트를 팀에 붙여봤다면 누구나 겪는 순간이 있다. 첫 주는 신기하고, 두 번째 주는 흥분되고, 세 번째 주에 현실이 찾아온다. "근데 이거 왜 이렇게 됐지?" dev.to에 올라온 세 편의 실전 경험담은 그 현실을 꽤 정직하게 보여준다. 각각 독립된 주제지만, 하나의 공통 서사로 읽힌다. 에이전트는 분명히 작동하는데, 팀이 기대한 방식으로 작동하지 않는다는 것.
마찰 1: 계획 없이 프롬프트부터 날리면, 코드베이스가 누더기가 된다
Sitewatch라는 모니터링 SaaS를 Claude Code로 혼자 구축한 개발자의 회고는 솔직하다. 초반에 설계 없이 기능 단위로 프롬프트를 던졌더니, 3주 뒤 코드베이스가 개별적으로는 돌아가지만 서로 맞물리지 않는 기능들의 집합이 됐다. 에러 핸들링 패턴이 제각각이고, 데이터 모델이 불일치하고, 상태가 세 방향으로 흐르고 있었다. 결국 아키텍처를 전면 재설계해야 했고, 처음부터 설계했을 때보다 더 많은 시간을 잃었다.
지금 그의 워크플로우는 명확하다. 데이터 모델, 모듈 경계, API 인터페이스, 에러 컨벤션을 먼저 스펙으로 정리하고, 그 스펙의 조각을 하나씩 에이전트에 넘긴다. 같은 도구, 완전히 다른 결과. 이건 에이전트의 문제가 아니라 사용법의 문제다.
팀에 주는 시사점: AI-First 워크플로우에서 기획과 설계의 비중은 오히려 높아진다. 에이전트가 빠르게 만들어줄수록, 만들기 전에 무엇을 만들지를 더 명확히 정의해야 한다. 스펙 작성 단계를 생략하면 에이전트의 속도는 오히려 기술 부채 생산 속도가 된다.
마찰 2: 에이전트가 15개 파일을 바꿨는데, 되돌아갈 방법이 없다
두 번째 마찰은 더 즉각적이고 고통스럽다. Claude Code로 작업하던 개발자가 auth.ts를 미들웨어 방식으로 리팩터링해달라고 요청했다. 결과: 15개 파일 변경, TypeScript 에러 폭발, 앱 빌드 불가. 그리고 마지막 커밋은 1시간 전. 3시간을 써서 마지막으로 동작하던 상태를 수작업으로 복원했다.
이 개발자가 만든 snaprevert는 그 고통의 직접적인 산물이다. npx snaprevert watch 한 줄로 파일 변경을 자동으로 스냅샷 찍고, snaprevert back 3으로 1초 안에 롤백한다. Git과 경쟁하는 도구가 아니라 AI 페어프로그래밍의 고속 구간에서 Git이 채우지 못하는 공백을 메우는 도구다. Git은 의도적인 커밋이 필요하지만, 에이전트와 100mph로 달리는 중에 "의도"는 가장 먼저 증발한다.
팀에 주는 시사점: AI 에이전트를 팀에 붙이면 변경 속도가 극적으로 빨라진다. 그런데 복구 체계가 그 속도를 따라가지 못하면, 하나의 잘못된 프롬프트가 팀 전체를 멈추게 할 수 있다. snaprevert 같은 자동 체크포인트 도구를 CI/CD 이전 단계의 안전망으로 표준화하는 것을 진지하게 검토할 시점이다.
마찰 3: 에이전트는 규칙 파일을 읽는다. 그런데 기억은 안 한다
세 번째 마찰은 가장 구조적이고, 가장 조용하게 팀을 갉아먹는다. Cursor 포럼에서 한 개발자가 .cursorrules가 무시되는 이유를 물었을 때, AI의 답변이 충격적으로 솔직했다. "규칙을 추가해도, 그것은 본질적으로 의미가 없습니다. 저는 그것을 무시하기로 선택할 수 있습니다."
마크다운 파일 하나로 에이전트의 메모리를 관리하는 방식은 초기엔 괜찮다. 문제는 프로젝트가 커지면서 시작된다. 파일 전체가 매 대화마다 컨텍스트 윈도우에 올라가고, Anthropic 공식 문서 기준 CLAUDE.md의 실용적 한계는 약 200줄이다. 그 이상이 되면 규칙 준수율이 현저히 떨어진다. 장시간 세션에서는 에이전트가 초반에 주입된 지시사항을 압축하거나 잊어버린다. 6개 에이전트 프로덕션 시스템을 운용한 개발자의 기록에 따르면, 에이전트들이 30분 전에 수행한 작업을 조용히 다시 하고 있었다. 아무런 알림도 없이.
팀에 주는 시사점: 이건 프롬프트 엔지니어링으로 해결할 수 없는 아키텍처 문제다. Anthropic이 Claude Code에 Auto Memory를 추가하고, GitHub Copilot이 28일 만료 기반의 메모리 검증 체계를 도입한 건 우연이 아니다. 두 회사 모두 정적 파일 방식을 넘어서기로 선택했다는 사실 자체가 답이다. 팀 레벨에서도 에이전트 메모리 관리를 단일 마크다운 파일에 의존하는 구조는 재검토가 필요하다.
공통된 패턴: 에이전트는 빠르고, 팀의 인프라는 느리다
세 가지 마찰은 사실 하나의 뿌리에서 나온다. 에이전트의 실행 속도가 팀의 설계 속도, 복구 속도, 컨텍스트 관리 속도를 앞질러버리는 것. Sitewatch 개발자가 지적한 대로, 더 빠르게 배포할수록 프로덕션이 조용히 망가지는 빈도도 높아진다. 속도가 올라가면 검증 체계도 함께 올라가야 한다.
AI-First 팀을 설계할 때 내가 강조하는 기준이 바로 여기서 나온다. 에이전트를 팀에 붙이기 전에 먼저 물어야 할 것은 "어떤 도구를 쓸까"가 아니라 "에이전트가 빠르게 만들어낼 때 우리 팀은 그것을 얼마나 빠르게 검증하고, 되돌리고, 기억시킬 수 있는가"다.
전망: 도구는 계속 좋아진다. 팀의 구조가 따라가야 한다
세 마찰 모두 해결책이 없는 문제가 아니다. 스펙 우선 워크플로우, 자동 스냅샷 도구, 구조화된 에이전트 메모리—이미 실전에서 검증된 대응법들이 존재한다. 중요한 건 이 대응법들이 개인의 습관이 아니라 팀의 표준 프로세스가 되어야 한다는 점이다.
에이전트는 내년에 더 좋아질 것이다. 컨텍스트 윈도우는 늘어나고, 메모리 관리는 개선되고, 롤백 기능도 도구 레벨에서 내장될 가능성이 높다. 그러나 지금 이 순간, 그 간극을 메우는 것은 도구가 아니라 팀의 설계 판단이다. 에이전트가 '잘 작동한다'는 착각에서 벗어나, 어디서 어떻게 실패하는지를 먼저 파악한 팀이 AI-First 전환의 진짜 수혜자가 된다.