AI 코딩 에이전트 도입 첫 주는 대부분 비슷하게 흘러간다. 슬랙에 축하 이모지가 넘치고, PR이 쏟아지고, '드디어 속도가 붙었다'는 말이 나온다. 그런데 2~3주가 지나면 분위기가 달라진다. 인시던트가 하나둘 터지고, 팀은 슬그머니 AI 도구를 탓하기 시작한다. dev.to에 공유된 한 팀의 사례가 정확히 이 패턴을 보여준다. 에이전트가 2019년부터 깨져 있던 함수를 처음으로 '올바르게' 호출했고, 그제야 숨어 있던 버그가 터졌다. AI가 문제를 만든 게 아니었다. 팀이 6년 넘게 우회하며 쌓아온 집이 무너진 것이다.
이 현상의 핵심은 단순하다. AI는 코드베이스의 빛을 밝게 만든다. 기존에 눈에 보이지 않던 결함—레이스 컨디션, 묵시적 타입 강제, 문서화되지 않은 가정들—이 에이전트가 그 코드를 호출하거나 수정하는 순간 전면에 드러난다. 문제는 팀이 이 '밝아진 빛'을 감당할 준비 없이 속도만 올렸다는 데 있다. AI가 가속기라면, 그 가속기는 현재 향하는 방향을 더 빠르게 갈 뿐이다. 기반이 탄탄하면 복리로 쌓이고, 기반이 금이 가 있으면 균열이 먼저 찾아온다.
에이전트는 판단력이 없다, 설계가 채워야 한다
'whetstone'과 'ai-skills' 프로젝트를 6개월간 직접 운용한 개발자가 dev.to에 정리한 관찰이 이 문제를 잘 짚는다. AI 코딩 에이전트의 공통 결함은 문법을 알지만 규율이 없다는 것이다. 400줄짜리 diff를 리뷰 가능한 단위로 쪼개지 않고, 루트 커즈를 확인하기 전에 픽스를 적용하며, 실제로 동작하는지 검증하기 전에 완료를 선언한다. 이 문제를 프롬프트 품질로만 해결하려는 팀은 곧 한계에 부딪힌다. 프롬프트는 방향을 줄 수 있지만 프로세스 게이트가 될 수 없다.
해당 프로젝트가 제시하는 접근은 '스킬을 행동 계약으로 만드는 것'이다. 예를 들어 디버깅 스킬은 루트 커즈를 파일·라인 단위 증거로 확인하기 전까지 픽스를 금지한다. 코드 리뷰 스킬은 diff가 300줄을 넘거나 보안·마이그레이션을 건드리면 자동으로 전문 에이전트를 병렬 소환한다. 이건 제안이 아니라 통과해야 하는 관문이다. 이 관점은 AI-First 팀 설계에 그대로 적용된다. 에이전트에게 코드를 맡기기 전에, 팀은 '에이전트가 절대 건너뛸 수 없는 검증 게이트'를 먼저 설계해야 한다.
AI 생성 코드는 왜 특히 위험한가
AI가 생성한 코드가 유독 검증하기 어려운 이유가 있다. dev.to의 다른 글이 정확하게 짚는다. AI 출력물은 겉보기에 깨끗하다. 컨벤션을 따르고, 경고 없이 컴파일되고, 표면적 리뷰를 통과한다. 버그는 보이지 않는 곳에 숨는다—엣지 케이스 처리, 시스템 특유의 가정 불일치, 입력 검증 공백. AI 모델은 여러분의 특정 시스템이 어떤 불변 조건 위에서 돌아가는지 알지 못한다. 코드가 '그럴듯해 보인다'는 것과 '실제로 올바르게 동작한다'는 것은 전혀 다른 문제다.
이 간극을 메우는 도구들은 이미 존재한다. Jest·Pytest의 파라미터화 테스트는 AI 생성 함수의 경계값을 체계적으로 커버한다. ESLint와 Semgrep은 정적 분석으로 에러를 조용히 삼키는 패턴, 입력 위생 처리 누락, 보안 취약 패턴을 사전에 잡는다. SonarCloud는 파일 단위가 아닌 프로젝트 전체에서 AI 코드가 지속적으로 심는 중복 로직이나 복잡도 증가를 가시화한다. 이 도구들은 서로 대안이 아니라 레이어다. 정적 분석 → 동작 검증 → 의존성 스캔 순으로 쌓아야 비로소 AI 생성 코드를 신뢰할 수 있는 구조가 된다.
팀이 먼저 갖춰야 할 세 가지
이 세 가지 신호를 종합하면 실용적인 체크리스트가 나온다.
첫째, 코드베이스 부채를 먼저 직면하라. AI 도입 전에 '에이전트가 이 함수를 직접 호출하면 무슨 일이 생기나'를 시뮬레이션해보는 것이 좋다. 6년간 우회해온 깨진 함수가 있다면, 에이전트가 그걸 발견하기 전에 팀이 먼저 고쳐야 한다. 스펙 문서, 불변 조건 정의, 로컬 개발 환경 정비—이건 AI 도입 이전의 과제다.
둘째, 프로세스 게이트를 코드로 만들어라. 에이전트에게 '잘 해줘'라고 요청하는 건 작동하지 않는다. 루트 커즈 확인 없이 픽스 금지, diff 크기 초과 시 리뷰어 소환, 검증 게이트 통과 전 완료 선언 불가—이런 규칙은 프롬프트가 아니라 워크플로우 구조 안에 박혀 있어야 한다.
셋째, 검증 레이어를 CI에 먼저 심어라. AI 코드가 PR에 올라오기 전에 ESLint·Semgrep이 돌아야 하고, 머지 전에 파라미터화 테스트가 경계값을 커버해야 하며, 배포 전에 의존성 취약점 스캔이 완료되어야 한다. 이 레이어 없이 AI 속도만 올리면, 더 빠른 속도로 검증되지 않은 코드가 프로덕션에 쌓인다.
속도보다 방향이 먼저다
AI-First 팀 리빌딩에서 가장 많이 보는 실수는 도구를 먼저 켜고 구조를 나중에 생각하는 것이다. 에이전트는 빠르다. 그 속도가 올바른 방향을 향하고 있을 때만 자산이 된다. 지금 당장 에이전트를 도입하는 것보다 중요한 질문은 이것이다. '에이전트가 우리 코드베이스에서 가장 취약한 가정을 건드렸을 때, 우리 팀은 그걸 감지할 수 있는가?' 그 질문에 '예스'라고 답할 수 있는 구조를 먼저 설계하는 것—그게 AI-First 팀이 속도를 올리기 전에 해야 할 진짜 준비다.