AI 코딩 어시스턴트가 코드를 만드는 속도는 이제 문제가 아니다. 문제는 그 속도에 맞춰 팀의 검증 기준선이 함께 올라가고 있느냐는 것이다. 최근 세 가지 사고 사례를 나란히 놓으면, 공통 패턴이 보인다. AI 도구가 빠르게 판단하고 실행할수록, 검증되지 않은 신뢰가 조용히 시스템 안으로 들어온다.
사고 1: AI 에이전트가 방아쇠를 당길 뻔했다
dev.to에 공개된 한 개발자의 경험은 읽을수록 불편하다. LinkedIn에서 Web3 채용 제안을 받고, 낯선 사람이 공유한 GitHub 저장소를 AI 코딩 에이전트에 넘겼다. "먼저 훑어봐"라는 지시였다. 에이전트는 프로젝트 구조를 분석하고 코드를 읽다가, 자연스러운 다음 스텝으로 빌드를 시작하려 했다. 그 순간이 바로 함정의 트리거였다.
해당 저장소는 정교하게 설계된 공급망 공격이었다. 겉으로는 완성도 높은 크립토 스테이킹 앱이고, npm install 단계는 완전히 무해하다. 페이로드는 Tailwind 플러그인으로 위장한 4MB짜리 파일 하나에 숨어 있고, npm run dev나 next build 시점에만 활성화된다. 실행되면 브라우저 저장 비밀번호, MetaMask 지갑 데이터, SSH 키, .env 파일을 탈취하고 원격 제어 채널을 연다. NODE_ENV === "development" 조건을 달아 개발자 환경에서만 작동하도록 설계했다. 배포 환경에선 흔적도 남기지 않는다.
이 사례가 AI-First 워크플로우에 던지는 질문은 명확하다. "AI 에이전트에 코드를 넘겨서 분석시킨다"는 행위가 이제 완전히 일상이 됐다. 문제는 에이전트가 분석을 위해 코드를 실행할 수 있다는 점이다. 에이전트는 당신 대신 방아쇠를 당긴다. 외부 저장소를 에이전트에 넘길 때, 팀에 "이 코드를 적대적 환경으로 취급하고 절대 실행하지 말라"는 명시적 지침이 있는가? 없다면 그게 바로 설계 공백이다.
사고 2: LLM이 만든 CVE가 Critical로 유통됐다
GeekNews가 보도한 두 번째 사례는 더 조용하고 더 넓게 퍼진다. 한 GitHub 계정이 SQLite 취약점 권고문 55건을 일괄 공개했고, NVD와 CISA ADP는 이 중 일부를 CVSS 9.8 Critical로 분류했다. 그런데 실제 검증 결과, 55건 중 54건이 완전히 조작된 것으로 드러났다. 나머지 1건도 실제 버그에 검증되지 않은 메타데이터를 붙인 사례였다.
조작 방식은 LLM 환각의 전형적 패턴이다. 대상 버전에 존재하지 않는 함수를 인용하고, 파일 총 행 수를 넘어서는 행 번호를 가리키며, PoC를 실행하면 주장한 충돌 대신 정상 종료되거나 파서 단계에서 멈춘다. GPTZero로 권고문 전체를 검사하면 AI 생성 콘텐츠 경고가 뜬다. 문제는 MITRE 공개 제출 양식이 신원 확인도, PoC 재현도 요구하지 않는다는 것이다. 그럴듯하게 작성된 허위 권고문은 GHSA, 기업 보안 스캐너, 하위 데이터베이스까지 자동으로 전파된다.
AI-First 워크플로우에서 이게 왜 위험한가. CVE 점수 기반으로 티켓을 자동 생성하거나 패치 우선순위를 정하는 팀이 늘고 있다. 취약점 분류와 대응까지 에이전트가 담당하는 환경에서는, 존재하지 않는 함수를 찾는 코드를 에이전트가 생성하고, 없는 취약점의 패치를 만들어 PR을 올린다. 실제 위협 대신 허위 위협에 팀의 에너지가 소진된다. 외부 CVE 정보를 그대로 에이전트 컨텍스트에 넣기 전에, 공식 유지보수자 보안 페이지와 수정 커밋의 실존 여부를 먼저 확인하는 게이트가 있어야 한다.
사고 3: 녹색 체크마크는 성공을 증명하지 않는다
세 번째 사례는 dev.to에서 나왔다. 개발자가 여러 플랫폼 테스트 결과를 모두 수집하기 위해 continue-on-error: true를 CI 스텝에 추가했다. Windows + Python 3.11/3.13 환경에서 58개 테스트가 91초간 돌았고, 모든 어설션이 완료됐다. 그런데 결과를 콘솔에 출력하는 마지막 단계에서 UnicodeEncodeError가 터졌다. 프로세스가 즉시 크래시되면서 58개 테스트 결과 전체가 사라졌다.
더 불편한 건 GitHub Actions API의 응답이었다. conclusion: success. continue-on-error: true가 설정된 스텝은 실패해도 conclusion 필드에 success가 기록된다. 실제 실패 정보는 거의 아무도 확인하지 않는 outcome 필드에 숨어 있다. 크로스플랫폼 데이터의 3분의 1이 유실됐는데, CI는 완전한 성공으로 보고하고 있었다.
이 문제의 해법으로 개발자는 테스트 실행 직후 별도 검증 스텝을 추가했다. continue-on-error 없이 실행되며, 로그에 최종 테스트 요약 라인이 실제로 존재하는지를 확인한다. 없으면 빌드를 즉시 실패 처리한다. 핵심은 이 게이트가 "테스트가 통과됐다"고 말하지 않는다는 점이다. 오직 "테스트 결과가 유실되지 않았다"만 보장한다. 그 둘을 혼동하는 순간 숨은 버그가 생긴다.
세 사고가 가리키는 하나의 패턴
세 사례를 나란히 놓으면 구조가 보인다. 외부 저장소 실행, AI 생성 취약점 정보 유입, CI 결과 신뢰—세 곳 모두에서 "이건 안전할 것"이라는 암묵적 가정이 실제 검증을 대체하고 있었다. 그리고 AI 도구가 개입할수록 이 가정은 더 빠르게, 더 넓게 퍼진다. 에이전트는 사람보다 빠르게 코드를 실행하고, 취약점 정보를 소비하고, CI 결과를 해석한다. 검증 기준선 없이 속도만 올리면, 오류도 같은 속도로 시스템 안에 들어온다.
테크 리드 관점에서 지금 당장 점검해야 할 세 가지를 정리하면 이렇다.
첫째, 외부 코드는 에이전트에 넘기기 전에 실행 금지 지침을 명시하라. "분석해줘"는 에이전트에게 실행 권한도 포함된다. 신뢰하지 않는 저장소를 다룰 때는 "정적 분석만, 절대 빌드하거나 실행하지 마"를 시스템 프롬프트나 작업 지침에 명시적으로 넣어야 한다.
둘째, 외부 CVE를 에이전트 컨텍스트에 넣기 전에 게이트를 설계하라. 공식 유지보수자 보안 페이지 확인, 수정 커밋 실존 여부, PoC 격리 재현—이 세 단계를 자동화된 게이트로 만들 수 없다면, 최소한 수동 체크리스트라도 워크플로우에 박아야 한다.
셋째, CI의 녹색은 결과가 아니라 보고의 성공일 수 있다. continue-on-error 설정이 있는 파이프라인이라면, 결과 데이터의 실존 여부를 별도 검증 스텝으로 확인하라. 테스트가 통과했다는 것과 테스트 결과가 올바르게 기록됐다는 것은 다른 보장이다.
전망: 검증 설계가 팀의 속도를 결정한다
AI 도구의 속도는 앞으로도 올라간다. 에이전트가 더 많은 판단을 위임받을수록, 검증되지 않은 가정 하나가 시스템 전체를 오염시키는 반경도 넓어진다. 낙관적으로 보면, AI를 활용해 검증 자체를 자동화할 수 있다. 외부 저장소를 정적 분석하는 에이전트, CVE 신뢰도를 교차 검증하는 파이프라인, CI 로그 유실을 감지하는 게이트—모두 AI로 만들 수 있다.
그러나 그 검증 에이전트를 누가 설계하는가. 결국 팀이다. 그리고 그 설계의 출발점은 "AI가 빠르게 무언가를 해줬을 때, 우리는 무엇을 당연하게 믿고 있는가"를 냉정하게 묻는 것이다. AI가 빠를수록, 팀의 검증 기준선이 먼저 있어야 한다.