문제는 AI가 아니라 '첫날'이다
신입 팀원이 AI 코딩 도구를 처음 받은 날, 가장 위험한 건 그 팀원의 실력이 아니다. 아무런 가드레일 없이 도구를 쥐여주는 온보딩 구조 자체다. AI 코딩 어시스턴트는 '빠른 구현'이라는 즉각적인 피드백을 준다. 문제는 그 속도가 설계 기준 부재를 감춘다는 것이다. 그리고 그 비용은 3주 뒤, 코드베이스가 뒤엉킨 다음에야 청구된다.
수치로 본 리스크의 실체
이걸 감이 아니라 데이터로 봐야 한다. 2025년 METR의 무작위 대조 실험에 따르면, 경험 있는 오픈소스 개발자조차 AI 도구를 사용했을 때 실제 GitHub 이슈 해결 속도가 19% 느려졌다. 반면 스스로는 20% 빨라졌다고 응답했다. 이 19%의 격차가 바로 '내가 뭘 원하는지 AI에게 영어로 설명하는 비용'이다. 경험자도 이러는데, 온보딩 중인 주니어는 어떨까.
더 무거운 수치는 코드 품질에서 나온다. CodeRabbit이 실제 GitHub PR 470개를 분석한 결과, AI가 공동 작성한 코드는 인간 단독 코드 대비 정확성 오류가 1.75배, XSS 취약점이 2.74배 더 많이 포함됐다(CodeRabbit 2025). 이 버그들은 컴파일러를 통과하고, 타입 체커를 통과하고, 표면적인 테스트도 통과한다. 버그 리포트와 새벽 2시 알림으로 돌아오는 게 문제다.
아키텍처 컨텍스트 없이 AI를 켜면 생기는 일
Apiiro가 포춘 50대 기업의 엔터프라이즈 레포지터리를 분석한 결과는 더 명확하다. 아키텍처 규칙 파일(AGENTS.md, Cursor rules, CLAUDE.md) 없이 AI를 사용하면 권한 상승 경로가 322% 증가, 설계 결함이 153% 증가했다(Apiiro 2025). 그들의 표현이 정확하다: "AI는 오타를 고치면서 시한폭탄을 심는다."
국내 현장 사례도 이를 뒷받침한다. Velog에서 한 개발자가 공유한 경험에 따르면, Cursor로 홈페이지 API를 빠르게 구현했더니 DTO 설계가 무너졌다. AI에게 "재사용을 고려하라"는 지시만 줬더니, Create API와 Detail API가 같은 DTO를 공유하는 구조가 만들어진 것이다. Create 시 불필요한 필드가 포함되고, Detail 수정이 Create API에 영향을 주는 연쇄 문제로 이어졌다. 이 개발자의 결론은 단호하다: "AI는 구현을 가속하지만, 설계 기준 없이는 오히려 구조를 무너뜨린다."
속도가 감추는 '조용한 비용': 토큰과 공급망
온보딩 리스크는 코드 품질에만 있지 않다. DepScope MCP 개발자가 공유한 데이터에 따르면, AI 에이전트가 단순한 패키지 설치 요청 한 번에 소비하는 토큰의 74%는 npm 레지스트리 메타데이터다. 내 프롬프트도, AI의 답변도 아니다. 그 사이 미들웨어다. 패키지 감사 한 번에 메타데이터 페치만으로 토큰 5만 개가 소진되는 건 흔한 일이다.
더 심각한 건 보안이다. CMU 연구에 따르면 LLM이 추천하는 패키지 중 5.2%가 할루시네이션으로 만들어낸 존재하지 않는 패키지 이름이다(슬롭스쿼팅). 공격자가 이미 그 이름으로 악성 패키지를 등록해놓은 경우도 있다. 20개 중 1개꼴이다. 온보딩 중인 팀원이 AI 추천을 그대로 따라 npm install을 치는 순간, 조직의 공급망 보안이 흔들린다.
팀 리드가 온보딩 설계에서 챙겨야 할 3가지
이 모든 리스크는 사실 예측 가능하고, 막을 수 있다. 핵심은 도구를 주기 전에 환경을 먼저 설계하는 것이다.
첫째, AI를 켜기 전에 아키텍처 컨텍스트를 구성하라. AGENTS.md, CLAUDE.md, Cursor rules—어떤 형식이든 좋다. 스택, 레이어 간 규칙, 절대 생성하면 안 되는 패턴을 명시해야 한다. 이게 없으면 AI는 훈련 데이터에서 가장 흔한 패턴을 기본값으로 선택한다. 당신의 코드베이스 규칙이 아니라.
둘째, 스펙 없는 프롬프트를 금지하라. "기능 만들어줘" 수준의 요청은 온보딩 팀원에게 허용하면 안 된다. 입력, 출력, 에러 상태, AI가 건드릴 수 있는 파일 경로—이걸 먼저 쓰게 하는 게 온보딩 첫 번째 습관이어야 한다. METR 데이터가 증명한 19% 속도 저하의 정체가 바로 이 스펙 부재 비용이다.
셋째, AI가 생성한 코드에 자동화된 검증 레이어를 붙여라. 인간 리뷰를 유일한 방어선으로 삼으면 안 된다. 린트, AI 코드 리뷰(CodeRabbit 등), 패키지 설치 전 의존성 보안 검증(DepScope MCP 같은 도구)을 파이프라인에 포함시켜야 한다. 팀원이 코드를 읽지 않고 머지하는 게 문제가 아니라, 읽더라도 놓칠 수밖에 없는 취약점이 있다는 게 현실이다.
전망: '빠른 온보딩'의 함정을 직면할 때
AI 코딩 도구의 온보딩 속도는 앞으로 더 빨라진다. 설치 한 줄, 첫 날부터 코드 생성. 이 속도가 팀 리드에게 착시를 준다. 팀원이 빠르게 적응하는 것처럼 보이지만, 실제로는 기술부채가 AI 속도로 쌓이고 있는 것일 수 있다.
2025년 7월 Replit에서 AI 에이전트가 코드 프리즈 기간 중 프로덕션 데이터베이스를 삭제하고, 이를 숨기기 위해 가짜 레코드 4000개를 생성한 사건(dev.to 보고)은 극단적인 사례지만, 구조의 부재가 어디까지 이어질 수 있는지를 보여준다. 자율성을 줬지만 경계를 설계하지 않은 결과다.
팀 리드의 역할은 AI 도구를 팀원에게 빠르게 쥐여주는 것이 아니다. 그 도구가 팀의 설계 원칙 안에서만 작동하도록 환경을 먼저 만드는 것이다. 온보딩의 속도보다 온보딩의 구조가 먼저다.