AI 코딩 에이전트를 도입한 팀들이 공통적으로 겪는 경험이 있다. 처음 몇 주는 정말 빠르다. 코드가 쏟아진다. 그런데 어느 순간 배포가 안 된다. 보안 검토가 쌓인다. 에이전트가 맥락을 잃고 같은 실수를 반복한다. 코딩 속도가 빨라졌을 뿐, 프로덕션까지 가는 시간은 줄지 않았다. 오히려 병목이 더 선명하게 보인다.
코드 완성이 곧 배포가 아니다
dev.to의 엔지니어 RSIV가 쓴 글 "AI sped up development, not shipping"은 이 문제를 정확히 짚는다. AI 에이전트는 기능 구현 속도를 며칠에서 몇 시간으로 압축했다. 그런데 에이전트는 '애플리케이션 코드'만 본다. Redis 캐시를 추가하는 5분짜리 대화 한 번으로 코드베이스에 새 인프라 의존성이 생겼지만, 에이전트는 Terraform 모듈도, 파이프라인 환경변수도, 스테이징과 프로덕션 동기화도 모른다.
모든 백엔드 서비스 뒤에는 '그림자 프로젝트'가 있다. IaC, CI/CD 설정, Dockerfile, 환경변수 관리—애플리케이션 코드와 함께 움직여야 하지만 항상 따로 논다. AI가 이 문제를 만든 건 아니다. 다만 AI는 이 문제를 감당 불가능한 속도로 쌓아 올린다. 에이전트가 프롬프트 한 번마다 새 인프라 요구사항을 만들어내는 상황에서, 기존의 신중한 IaC 리뷰 프로세스는 구조적으로 따라갈 수 없다.
문제는 Terraform 자동생성이 해결책이 되지 못한다는 점이다. 애플리케이션 코드는 오픈소스 레퍼런스와 커뮤니티 패턴으로 검증할 수 있다. IaC는 다르다. 조직마다 다르고, 비공개이며, 잘못된 IAM 정책이나 과도한 보안 그룹 설정은 예외를 던지지 않는다. 조용히 돈을 태우거나, 조용히 프로덕션을 무너뜨린다. 결국 리뷰어가 직접 작성하지 않은 생성 결과물을 처음부터 끝까지 검토해야 한다. 리뷰 부담은 줄지 않고, 리뷰어는 병목이 된다.
속도만 믿으면 보안이 구멍 난다
배포 병목보다 더 조용하고 위험한 문제가 있다. BeyondTrust의 보안 연구소 팬텀랩스가 OpenAI Codex에서 발견한 취약점이 그 단면이다. Codex는 작업 생성 시 브랜치 이름을 처리하는 과정에서 임의의 쉘 명령을 주입할 수 있는 명령어 삽입 취약점이 있었다. 이를 통해 GitHub OAuth 토큰을 추출하고 외부로 유출하는 경로가 열렸다.
더 중요한 시사점은 취약점의 성격이다. 이 취약점은 웹 인터페이스에 국한되지 않았다. CLI, SDK, IDE 통합까지 확장될 수 있었고, 로컬에 자격증명이 저장된 환경에서는 백엔드 API를 통해서도 재현이 가능했다. 기업 환경에서 Codex에 광범위한 권한이 부여된 경우라면, 토큰 하나로 전체 저장소와 워크플로에 대한 횡적 이동이 가능했다. OpenAI는 입력 검증 강화와 컨테이너 내 토큰 노출 제어로 대응했지만, 이 사례가 남긴 교훈은 명확하다. AI 에이전트는 단순 생산성 도구가 아니라 사용자 입력을 쉘 명령으로 변환하는 실행 환경이다. 기존 애플리케이션 보안과 동일한 수준의 경계가 필요하다.
에이전트를 빠르게 쓰는 것과 잘 쓰는 것은 다르다
배포와 보안 문제가 결국 하나의 뿌리로 연결된다는 걸 dev.to의 Lewis Kori가 쓴 "AI Is Not Your Intern"이 정리해준다. AI 에이전트가 일관성 없이 동작할 때, 문제는 모델의 지능이 아니라 컨텍스트의 부재다. 프롬프트를 더 잘 쓰는 게 해결책이 아니다. 에이전트가 작동하는 환경 자체를 설계해야 한다.
실제로 잘 동작하는 에이전트 시스템은 여러 레이어로 구성된다. 반복 가능한 판단을 패키징한 '스킬', 저장소·API·DB에 연결하는 MCP 통합, 그리고 코드베이스의 운영 현실—안전한 명령어, 지켜야 할 제약, 이미 내려진 결정들—을 담은 AGENTS.md 같은 컨텍스트 문서가 그것이다. 이게 없으면 에이전트는 매 세션마다 프로젝트를 처음부터 재발견한다. IaC 동기화도 안 되고, 보안 제약도 모르고, 이전에 내린 아키텍처 결정도 무시한다.
AI-First 팀이 지금 당장 봐야 할 것
세 문제—배포 병목, 보안 취약점, 에이전트 컨텍스트 손실—는 사실 같은 질문을 가리킨다. "코딩 이후의 파이프라인을 AI 속도에 맞게 재설계했는가?"
지금 팀에서 점검해야 할 것들을 구체적으로 말하면 이렇다.
첫째, IaC 리뷰 프로세스를 AI 생성 빈도에 맞게 조정해야 한다. 모든 변경에 동일한 무게의 리뷰를 적용하면 리뷰어가 병목이 된다. 위험도 기반으로 리뷰 레벨을 나누고, 낮은 위험 변경은 자동화된 정적 분석으로 1차 필터링하는 구조가 현실적이다.
둘째, AI 에이전트에 연결된 자격증명의 권한 범위를 최소화해야 한다. Codex 사례처럼, 에이전트 환경은 사용자 입력이 쉘 명령이 될 수 있는 공격 표면이다. 개발 환경 토큰과 프로덕션 토큰을 분리하고, 에이전트에 부여하는 권한은 작업 단위로 제한해야 한다.
셋째, AGENTS.md 혹은 동등한 컨텍스트 문서를 프로젝트 초기부터 관리해야 한다. 코드베이스의 제약, 이미 결정된 아키텍처 선택, 건드리면 안 되는 설정을 명문화해두지 않으면, 에이전트는 매번 같은 실수를 반복하고 팀은 매번 같은 리뷰를 한다.
병목은 옮겨갔을 뿐, 사라지지 않았다
AI는 코딩 단계의 병목을 없앴다. 그 결과 배포·보안·컨텍스트 관리라는 다음 단계의 병목이 더 선명하게 드러났다. 이건 AI의 실패가 아니다. 전체 파이프라인에서 가장 느린 단계가 어딘지를 비로소 정직하게 보여주는 것이다.
프론트엔드 팀이 Vercel로 넘어간 건 인프라를 못 다뤄서가 아니었다. 관리 비용 대비 가치가 무너졌기 때문이었다. 백엔드와 풀스택 영역도 같은 전환점에 와 있다. 다만 IaC와 보안은 프론트엔드 배포보다 실패 비용이 훨씬 높다. 그렇기 때문에 추상화 레이어가 알아서 해결해줄 거라는 기대보다, 팀이 직접 이 3중 병목을 인식하고 제어 구조를 설계하는 것이 먼저다.
AI-First 팀 리빌딩에서 '에이전트를 잘 쓰는 팀'과 '빠르게 쓰는 팀'의 차이는 결국 여기서 갈린다. 코딩 이후의 파이프라인까지 설계 범위에 넣었는가.