AI-First 워크플로우로 전환한 팀이 공통적으로 마주치는 질문이 있다. "AI가 빠르게 만들어줬는데, 이거 실제로 믿어도 되나?" 속도는 확실히 올라갔다. 그런데 그 결과물이 정말 작동하는지, 측정값이 실제를 반영하는지는 별개의 문제다. 최근 세 가지 사례가 이 질문을 정면으로 건드린다. AI의 프로젝트 추정 편향, AI 빌더로 만든 앱의 허상, 그리고 eval 데이터 오염으로 만들어진 가짜 성과 지표. 세 문제는 서로 다른 레이어에서 발생하지만, 공통 구조는 하나다. AI 생성물을 검증하는 구조가 없으면, 빠름이 오히려 리스크가 된다.
핵심 이슈: 세 가지 신뢰성 구멍
첫 번째 구멍: AI는 여전히 2023년 기준으로 일정을 짠다. dev.to의 러셀 존스가 지적한 것처럼, Claude Code를 포함한 대부분의 AI 코딩 어시스턴트는 프로젝트 스펙을 요청하면 "6~8주" 같은 추정을 돌려준다. 실제로는 하루에 끝낼 수 있는 5개짜리 작업 패키지에 대해서도. 이유는 간단하다. 모델의 학습 데이터 대부분이 AI 보조 개발이 일반화되기 이전, 2019~2021년 스택오버플로우와 엔지니어링 블로그에서 왔다. 모델은 AI가 개발 속도를 바꿨다는 사실을 알고 있다. 그러나 그 지식을 추정치에 기본으로 적용하지 않는다. 매번 명시적으로 재보정을 요구해야 하고, 그걸 안 하면 엉뚱한 일정으로 만들어진 작업 분해가 그 아래를 모두 오염시킨다.
두 번째 구멍: 완성처럼 보이는 앱이 실제로는 연결되어 있지 않다. AI 빌더로 만든 앱은 샘플 데이터로 화면을 채워 "완성된 것처럼" 보이게 한다. 문제는 그게 진짜 데이터인지 하드코딩된 목업인지 눈으로는 구별이 안 된다는 점이다. 실제 사용자가 쓰기 시작하면 빈 화면이 나오거나, 입력한 데이터가 새로고침 후 사라지거나, 백엔드 연결이 애초에 없었던 사실이 드러난다. 빌더가 아닌 실제 사용자가 첫 번째 버그를 발견하는 구조다.
세 번째 구멍: 0.94라는 숫자가 5주 동안 거짓이었다. dev.to의 에단이 공개한 사례는 더 충격적이다. 티켓 라우팅 시스템의 few-shot 예시 선택기가 eval 세트와 동일한 파일에서 데이터를 가져오고 있었다. 결과적으로 모델은 평가 케이스 자체를 few-shot 예시로 받아 답을 '복사'했다. 5주 동안 아무도 0.94를 의심하지 않았다. 완벽한 1.0이었다면 누군가 버그라고 열었겠지만, 0.94는 "좋은 분기 성과"처럼 보였다. 그 숫자가 슬라이드에 올라갔고, 화살표가 위를 가리켰다.
맥락 해석: 왜 지금 이 세 문제가 동시에 터지나
세 문제의 공통 원인은 AI 속도에 대한 신뢰가 검증 구조보다 앞서 나갔기 때문이다. AI-First 전환 초기에는 "AI가 이렇게 빨리 만들어줬는데 설마 틀렸겠어"라는 심리가 팀 전체에 퍼진다. 타임라인 추정은 AI가 뱉은 숫자를 그냥 쓰고, 앱은 화면이 그럴싸하면 배포하고, eval 점수는 높게 나오면 믿는다. 검증에 쓰던 시간을 AI가 '절약'해줬다고 착각하는 순간, 그 절약이 나중에 더 큰 비용으로 돌아온다.
특히 세 번째 eval 오염 사례는 팀 구조 문제를 드러낸다. few-shot 풀 PR과 eval 세트 PR은 각각 별개로 리뷰됐고, 각각의 리뷰어는 각자의 질문을 잘 했다. 그런데 "이 두 파일이 같은 행을 읽고 있는가"라는 질문은 어떤 diff에서도 보이지 않았다. 파일과 파일 사이의 공간을 검토하는 프로세스가 없었던 것이다. 이건 개인의 실수가 아니라 리뷰 구조의 공백이다.
시사점: AI-First 팀이 지금 당장 설계해야 할 것
타임라인 추정엔 명시적 재보정 템플릿을 쓴다. 스펙 프롬프트에 "이 작업은 AI 보조 개발로 진행됩니다. 작업 패키지는 일 단위가 아니라 시간 단위로 추정하고, 각 WP는 단일 집중 세션 내에 완료 가능한 범위로 설정하세요"를 기본으로 넣는다. 추정치 없이 "5개 WP, 의존성 순서"만 받는 것도 유효한 전략이다. 일정 숫자가 없으면 그로 인한 작업 분해 오염도 없다.
앱 검증은 세 가지 체크로 1분 안에 끝낸다. 실제 데이터를 입력 후 강제 새로고침, 백엔드 연결을 의도적으로 끊어서 에러 발생 여부 확인, 브라우저 네트워크 탭에서 실제 요청이 나가는지 확인. 세 가지 중 하나라도 이상하면 배포 전에 잡아야 한다. 이 체크를 배포 체크리스트에 넣는 것만으로 "AI 빌더가 만든 앱 허상" 문제의 90%는 막을 수 있다.
eval 파이프라인엔 오염 검사를 CI에 포함시킨다. few-shot 풀과 eval 세트가 동일한 소스에서 왔는지를 콘텐츠 해시로 체크하는 스크립트를 CI에 넣는다. eval 오염 사례처럼 두 파일이 각각 올바르게 보여도 조합했을 때 문제가 생기는 케이스는 자동화된 크로스 체크 없이는 인간 리뷰로 잡기 어렵다.
전망: 속도와 신뢰는 함께 설계해야 한다
AI-First 전환의 1단계는 속도를 올리는 것이었다. 지금 우리가 진입하고 있는 2단계는 그 속도를 신뢰할 수 있는 구조를 만드는 것이다. AI 타임라인 추정 편향은 학습 데이터가 현실을 따라잡는 데 몇 년이 더 걸릴 것이다. eval 오염 문제는 RAG 기반 시스템이 늘수록 더 자주 발생할 것이다. AI 빌더 앱의 허상 문제는 비개발자가 더 많이 배포를 시도할수록 더 많은 팀에서 반복될 것이다.
AI가 만든 것을 믿으려면, 믿을 수 있는 구조를 먼저 설계해야 한다. 검증 없는 속도는 기술 부채가 아니라 신뢰 부채다. 그리고 신뢰 부채는 언제나 가장 나쁜 타이밍에 청구서를 보낸다.