AI 에이전트를 팀에 도입하기로 했다. 그러면 가장 먼저 뭘 해야 할까? 도구를 설치하고, Cursor나 Claude Code를 열고, 첫 번째 프롬프트를 날리는 것? 틀렸다. 현장에서 실제로 도입을 진행해보면, 첫 주에 설계하지 않은 것들이 두 달 후 예상치 못한 방식으로 터진다. 자격증명 유출, 클라우드 비용 폭증, 그리고 "AI는 쓸 줄 아는데 결과물은 검증 못 하는" 팀원이 그것이다.
세 가지 실전 사례가 이 문제를 정확하게 짚는다. 보안 설정을 처음부터 제대로 잡는 법(dev.to의 The Boring Setup That Prevents Disaster), GCP 크레딧을 Claude Code에 연결하는 비용 라우팅 설계(My Team Had GCP Credits. Claude Code Wanted an Anthropic Key.), 그리고 AI 보조 코딩이 면접 기준으로 자리 잡는 시대에 팀원의 역량을 어떻게 평가하고 온보딩할 것인가(Vibe Coding Interview Guide)다. 세 가지를 하나의 체크리스트로 엮으면, AI 에이전트 도입 첫 주에 팀 리드가 실제로 설계해야 할 것들이 보인다.
1. 에이전트가 읽는 것부터 통제하라: 보안 레이어 설계
AI 코딩 에이전트의 가장 큰 맹점은 바로 컨텍스트다. Claude Code, Cursor 같은 도구들은 레포 전체를 인덱싱한다. .gitignore에 올려두었다고 안심하는 팀이 많은데, 이건 착각이다. .gitignore는 커밋을 막을 뿐, 에이전트가 워킹 디렉터리에서 파일을 열어 읽는 것을 막지 않는다.
실제 사례를 보면 문제가 명확해진다. dev.to에 공개된 Cloudflare Workers 프로젝트 셋업 경험담에서 저자는 Vercel 자격증명 유출 사고 이후, 보안 설정을 처음부터 다시 설계했다. 핵심은 세 개 파일이다.
첫째, .claude/settings.json의 denyList. 에이전트가 .env.local을 읽거나, cat이나 printenv로 환경변수를 출력하는 것을 명시적으로 차단한다. .env.example은 허용해서 변수명은 참조할 수 있게 열어두되, 실제 키 값은 에이전트의 컨텍스트 윈도우에 절대 들어가지 않도록 설계하는 것이다.
둘째, 도구별 ignore 파일. Cursor는 .gitignore를 인덱서 기준으로 쓰지 않는다. .cursorignore를 별도로 만들어야 한다. 사용하는 AI 도구마다 컨텍스트 제외 파일을 따로 확인하고 설정하는 것이 기본이다.
셋째, AGENTS.md. 에이전트에게 ".env* 파일의 값을 절대 출력하지 말 것"이라는 명시적 규칙을 문서로 남긴다. 기술적으로 접근이 가능한 상황에서도 행동 기준을 명시하는 것이다.
한 가지 더. 어떤 설정 파일도 막을 수 없는 벡터가 있다. IDE 안에서 직접 시크릿을 붙여 넣는 것이다. .env.local은 반드시 IDE 밖 터미널에서 생성하고 값을 입력해야 한다. 에이전트가 이미 실행 중인 IDE 환경에서는 키스트로크까지 컨텍스트가 된다. 그리고 curl 명령에 Bearer 토큰을 직접 인자로 넘기는 것도 금지다. ps aux로 프로세스 목록을 보면 토큰이 평문으로 노출된다. 임시 파일에 헤더를 쓰고 --config로 참조한 뒤 삭제하는 패턴이 정답이다.
팀 적용 포인트: 에이전트를 처음 셋업할 때 보안 설정 PR을 먼저 머지하라. 기능 코드보다 앞에 와야 한다.
2. 비용은 어디서 나오는가: 인프라 라우팅 설계
팀에 Claude Code를 도입하면 곧바로 현실적인 질문이 온다. "Anthropic API 키를 별도로 만들고 결제 계정을 또 추가해야 하나?" GCP, Azure, AWS 크레딧을 이미 쓰고 있는 팀이라면 이건 단순한 불편함이 아니라 비용 가시성 문제다. 청구서가 분산되면 AI 도구 ROI를 측정하기가 사실상 불가능해진다.
dev.to에 공개된 GCP + Claude Code 연동 사례는 이 문제를 로컬 게이트웨이로 해결한다. Claude Code는 Anthropic Messages API 포맷으로 요청을 보내고, Vertex AI는 전혀 다른 엔드포인트 구조를 쓴다. 이 둘을 직접 연결하면 프로토콜이 맞지 않는다. 중간에 로컬 프록시(CliGate)를 두면, Claude Code는 http://localhost:8081로 요청을 보내고, 게이트웨이가 Vertex AI의 Claude 또는 Gemini 엔드포인트로 라우팅한다. Claude Code 입장에서는 Anthropic 서버와 통신하는 것처럼 보이고, 실제 비용은 팀이 이미 쓰고 있는 GCP 크레딧에서 나간다.
이 설계의 실질적 가치는 모델 교체 유연성이다. 게이트웨이 설정 하나만 바꾸면 Claude-on-Vertex에서 Gemini-on-Vertex로 전환할 수 있고, 팀의 CLI 도구는 전혀 건드릴 필요가 없다. 비용 대시보드도 게이트웨이 한 곳에서 통합 관리된다.
팀 적용 포인트: AI 도구 도입 전에 비용이 어느 계정에서 나가는지, 어떻게 측정할 것인지를 먼저 설계하라. 도입 후에 사후 추적하는 것은 거의 불가능하다.
3. 팀원을 어떻게 평가하고 온보딩할 것인가: 역량 기준 설계
AI 에이전트를 팀에 도입했을 때 가장 예상하기 어려운 문제는 도구가 아니라 사람이다. "AI 쓸 줄 안다"는 것과 "AI와 함께 품질을 유지하며 일할 수 있다"는 것은 완전히 다른 역량이다. 그리고 이 구분은 이제 면접 현장에서도 명확하게 갈리고 있다.
Vibe Coding 면접 가이드(dev.to)는 2025~2026년 주요 테크 기업의 채용 트렌드를 정리한다. Shopify는 AI 허용 코딩 라운드를 두 개 운영하고, Meta는 GPT-5·Claude Sonnet·Gemini를 포함한 CoderPad 환경을 면접에 도입했다. 이들이 실제로 평가하는 것은 코드 완성도가 아니다. 분해 명확성(vague한 문제를 buildable 단위로 쪼개는 능력), 프롬프트 정밀도(원하는 결과를 1~2번 시도로 끌어내는 능력), AI 출력 검증(에이전트가 생성한 코드에서 보안 취약점·엣지 케이스 누락·존재하지 않는 함수 호출을 잡아내는 능력)이 핵심 평가 기준이다.
이 세 가지 기준은 팀 온보딩 설계에도 그대로 적용된다. AI 도구 사용법을 가르치는 것이 온보딩의 전부가 되면 안 된다. 에이전트가 생성한 코드를 비판적으로 읽는 훈련, 잘못된 출력에서 복구하는 디버깅 루프, 그리고 "내가 이 코드를 프로덕션에서 직접 설명할 수 있는가"라는 오너십 기준을 팀 문화로 심어야 한다. 가이드에서 강조하는 표현이 정확하다. "AI는 패턴을 많이 아는 빠른 주니어이고, 가끔 확신에 차서 환각을 일으킨다." 이 주니어를 관리하는 역량이 곧 AI-First 팀원의 역량이다.
팀 적용 포인트: 신규 입사자와 기존 팀원 모두에게 "AI 출력 검증" 워크숍을 첫 주에 배치하라. 도구 설치보다 검증 습관이 먼저다.
시사점: "지루한 설계"가 팀을 지킨다
세 가지를 다시 정리하면 이렇다. 보안 레이어—에이전트가 읽을 수 있는 것과 없는 것을 명시적으로 구분한다. 비용 라우팅—AI 도구 비용이 어느 계정에서 얼마나 나가는지 처음부터 측정 가능하게 설계한다. 역량 기준—AI 출력을 검증하고 오너십을 가지는 능력을 팀원 평가와 온보딩의 기준으로 삼는다.
이것들은 전부 "지루한" 설계다. 에이전트가 놀라운 속도로 코드를 뽑아내는 동안, 팀 리드는 deny 리스트를 설정하고 게이트웨이를 배선하고 검증 체크리스트를 작성해야 한다. 하지만 이 지루한 작업을 첫 주에 하지 않으면, 두 달 후에 자격증명 로테이션과 비용 폭증과 AI가 짠 버그를 추적하는 데 훨씬 더 긴 시간을 쓰게 된다.
AI 에이전트 도입의 속도는 실재한다. 하지만 그 속도가 팀에 유리하게 작동하려면, 에이전트가 움직이는 경계선을 먼저 설계한 팀만이 그 속도를 안전하게 소화할 수 있다. 기반이 지루할수록 위에 쌓이는 것은 단단해진다.