AI 코드 생성 도구를 도입한 팀이 처음 느끼는 감각은 대부분 비슷하다. 빠르다. 놀랍도록 빠르다. 그런데 몇 주 지나면 슬그머니 다른 감각이 끼어든다. 왜 이렇게 디버깅이 많아졌지? dev.to에 올라온 한 개발자의 글은 이 감각을 숫자로 정리했다. 30초 만에 생성된 20줄짜리 함수를 고치는 데 세 시간이 걸렸다. 10배의 디버깅 비용이다.
이 역설의 구조는 단순하다. LLM은 평균적인 코드 패턴으로 훈련됐기 때문에 '가장 흔한 구현'을 내놓는다. 당신 팀의 API 규약, 에러 핸들링 컨벤션, 환경 특성 같은 맥락은 없다. 더 나쁜 건 자신감이다. AI는 response.ok 체크도 없이 페이지네이션 루프를 작성하고, 없는 라이브러리 메서드를 있는 것처럼 호출한다. 문법 오류는 금방 잡히지만, 논리적 오프바이원이나 할루시네이션 API 호출은 런타임에서야 터진다. 그리고 당신은 자신이 짜지 않은 코드의 의도를 역설계하느라 시간을 날린다.
문제는 이 비용이 숨어 있다는 점이다. 팀 리드 입장에서 AI 도입 ROI를 측정할 때 '코드 생성 속도 향상'은 보이지만 '디버깅 비용 증가'는 잘 보이지 않는다. 스프린트 속도가 올라간 것처럼 보이는데 버그 리포트가 늘어나는 상황이 생기면, 팀은 AI 탓도 자기 탓도 못 하고 혼란에 빠진다. 실제로 앞서 언급한 개발자는 워크플로우를 바꾸기 전까지 AI 코드의 디버깅 비용이 생성 비용의 10배였다고 밝혔다.
해결책의 방향은 명확하다. AI 출력물을 완성품이 아니라 초안으로 다뤄야 한다. 그리고 그 초안을 검증하는 구조를 워크플로우 안에 명시적으로 설계해야 한다. 같은 글에서 제안한 방식은 현장에서 즉시 적용 가능하다. 프롬프트를 열기 전에 테스트를 먼저 작성한다. 'Jest에서 통과해야 할 입출력'을 정해두고 AI에게 그 테스트를 통과하는 코드를 요청하면, 디버깅 시간이 약 60% 줄었다고 보고했다. 요청 단위도 쪼갠다. '페이지네이션 함수 전체'가 아니라 '오프셋과 리밋을 받아 한 페이지만 가져오는 함수'를 먼저 요청하고 검증한 뒤 다음 단계로 넘어간다. 그렇게 하면 AI가 요청하지 않은 복잡한 로직을 발명하는 것을 막을 수 있다.
이 검증 구조를 프론트엔드로 확장하면 문제가 더 복잡해진다. 백엔드 변경은 테스트 어서션과 로그로 검증 근거를 남길 수 있지만, 프론트엔드는 다르다. 모달이 포커스를 제대로 트랩했는지, 버튼이 요청 중 비활성화됐는지, 긴 이름을 가진 사용자에게 레이아웃이 버텼는지는 diff로 확인되지 않는다. 팀은 슬랙 스크린샷, Loom 영상, 브랜치 직접 체크아웃으로 이 공백을 메웠다. 하지만 AI 에이전트가 프론트엔드 코드를 생성하기 시작하면 이 공백의 비용이 폭발한다. 에이전트가 무엇을 변경했는지는 알아도, 변경 후 실제로 무엇을 봤는지는 알 수 없기 때문이다.
GitHub이 지난주 Copilot의 브라우저 도구를 VS Code에서 정식 출시한 것은 이 공백을 정면으로 겨냥한다. 에이전트가 실제 브라우저에서 클릭하고, 콘솔 에러를 캡처하고, 뷰포트별 스크린샷을 남기고, 그 결과를 코딩 루프에 피드백으로 돌려줄 수 있게 됐다. 컴포넌트를 수정한 동일한 에이전트가 앱을 직접 실행하고 결과를 관찰한다는 의미다. 이는 브라우저 관찰 결과가 코드 생성의 입력값이 된다는 뜻이고, 그 입력값은 반드시 기록으로 남겨야 한다.
그런데 여기서 흔한 함정이 있다. 에이전트가 브라우저를 쓴다고 해서 자동으로 신뢰할 수 있는 건 아니다. 해피 패스만 클릭하고 '작동합니다'라고 선언하는 에이전트는 테스트를 안 한 것과 다름없다. 진짜 검증 가능한 증거는 달라야 한다. 어떤 URL을 열었는지, 어떤 뷰포트를 사용했는지, 어떤 유저 상태로 테스트했는지, 어떤 콘솔 에러가 발생했는지, 무엇을 검증하지 않았는지까지 남겨야 한다. '에이전트가 테스트했다'가 아니라 '에이전트가 1440px와 390px에서 체크아웃 플로우를 실행했고, 결제 콜백은 검증하지 않았다'가 되어야 PR 리뷰의 출발점이 된다. 에이전트 브라우저 도구가 강조하는 격리된 세션과 도메인 제어 기능은 바로 이 신뢰의 조건을 만족시키기 위한 장치다.
세 번째 데이터 포인트는 규모의 맥락을 보여준다. Google DeepMind 소속 개발자 Ammaar Reshi는 Anthropic의 Claude Code를 사용해 2003년 PC 게임 '커맨드 앤 컨커: 제너럴스 제로 아워'를 아이폰과 아이패드에 이식했다. DirectX 8을 Apple Metal API로 전환하는 작업이다. 숙련 개발자 팀이 수 주에서 수개월을 투입할 작업을 이틀 만에 결과물로 냈다. 첫 빌드는 40분, 이후 몇 시간의 디버깅이 뒤따랐다. 그리고 Claude Max 사용 한도를 전부 소진했다. 여기서 주목할 점은 이 사례조차 디버깅을 피하지 않았다는 것이다. AI가 첫 빌드를 냈지만 '몇 시간의 디버깅'이 그 뒤를 이었다. 속도가 압도적으로 향상됐지만 검증 단계는 여전히 인간의 몫이었다.
세 사례가 공통으로 가리키는 방향은 하나다. AI는 생성 속도를 끌어올리지만 검증 비용을 제거하지 않는다. 그리고 검증 구조를 팀이 명시적으로 설계하지 않으면, 그 비용은 숨겨진 형태로 축적된다. 테크 리드가 AI 도입 ROI를 제대로 측정하려면 코드 생성 속도만이 아니라 디버깅 사이클 수, PR당 브라우저 검증 커버리지, 에이전트가 놓친 엣지 케이스 비율을 함께 측정해야 한다.
AI-First 워크플로우의 다음 과제는 더 빠른 생성이 아니다. 생성만큼 빠른 검증이다. 테스트-퍼스트 프롬프팅, 브라우저 기반 자동화 검증, 에이전트 행동의 증거 패킷—이 세 가지를 워크플로우 안에 설계해두지 않으면, 팀은 AI 속도의 혜택보다 AI 신뢰의 비용을 더 많이 치르게 된다. AI를 믿지 말고, AI를 검증하라. 그 회의주의가 역설적으로 팀을 더 빠르게 만든다.