AI 도구에 대한 신뢰, 지금 어디에 금이 가고 있나
최근 AI 코딩 도구를 둘러싼 세 가지 사건이 거의 동시에 터졌다. GitHub Copilot이 개발자 PR 설명란에 광고를 삽입했고, Cursor로 생성한 프로덕션 앱의 67%에서 치명적 취약점이 발견됐으며, 한 개발자는 Claude Code와 GPT-5.4가 서로의 코드를 교차 리뷰하게 했더니 단일 모델이 놓친 버그 3개를 잡아냈다. 이 세 사건은 각각 별개의 이슈처럼 보이지만, 하나의 질문으로 수렴한다. "AI 코딩 도구를 얼마나 신뢰할 수 있고, 그 신뢰는 어떻게 설계해야 하나?"
사건 1: Copilot이 PR 설명란을 광고판으로 썼다
dev.to에 올라온 리포트에 따르면, GitHub Copilot이 PR 수정 작업을 수행하면서 PR 설명란에 START COPILOT CODING AGENT TIPS라는 HTML 주석과 함께 Raycast 프로모션 문구를 삽입했다. 이 패턴이 발견된 PR만 11,000개 이상이다. Raycast 측은 사전에 몰랐다고 했고, Microsoft는 '의도된 광고'인지 '과도한 제품 안내'인지조차 명확히 밝히지 않았다.
이게 왜 단순한 UX 실수 이상인가. PR 설명란은 개발자가 변경 의도를 설명하고, 리뷰어와 협상하고, 팀의 맥락을 기록하는 공간이다. 거기에 도구가 조용히 홍보 문구를 끼워 넣는다면, 그 도구가 생성하는 코드 제안에도 비슷한 질문이 따라붙는다. "이 라이브러리를 추천하는 게 내 코드베이스에 최적이라서인가, 아니면 Microsoft의 파트너십 때문인가?" 월 10~39달러를 내는 유료 서비스에서 이 질문이 생긴다는 것 자체가 신뢰 설계의 실패다.
사건 2: Cursor 생성 코드, 67%에서 치명적 취약점
ShipSafe를 개발한 한 엔지니어가 GitHub에서 Cursor로 빌드된 실제 프로덕션 앱 100개를 수집해 보안 스캔을 돌렸다. 결과는 냉혹했다. 67%에서 최소 하나의 치명적 취약점이 발견됐고, 앱당 평균 3.2개의 이슈가 있었다.
가장 흔한 패턴 네 가지가 특히 눈에 띈다.
- IDOR(43%): API 라우트가 URL의 ID로 DB를 조회하면서 소유권 검증을 빠뜨린다.
userId: session.user.id한 줄이 없어서 타인의 인보이스를 그대로 읽어올 수 있다. - 인증 미들웨어 반전(31%):
if (token)과if (!token)을 뒤바꿔, 로그인한 사용자는 로그인 페이지로 튕겨나가고 비로그인 사용자는 보호된 라우트에 그냥 들어온다. 본인 앱을 테스트할 땐 항상 로그인 상태라 절대 발견되지 않는다. - 프론트엔드 전용 권한 체크(28%): React에서 admin 여부를 확인해 화면을 숨기지만, 실제 DELETE API에는 아무 검증이 없다.
curl한 줄로 누구든 사용자를 삭제할 수 있다. - 하드코딩된 시크릿(22%): Cursor 채팅에 API 키를 붙여넣으면 그게 코드 파일에 그대로 박힌다.
git log는 삭제 이후에도 그 키를 기억한다.
이 문제의 구조적 원인은 두 가지다. 첫째, LLM이 학습한 GitHub 코드 대부분은 '작동하는가'에 최적화돼 있고 '누가 접근할 수 있는가'는 후순위다. 둘째, Cursor는 파일 단위로 컨텍스트를 처리한다. 미들웨어 파일과 API 라우트 파일을 동시에 고려한 보안 설계는 현재 구조에서는 기대하기 어렵다.
사건 3: 교차 리뷰가 잡아낸 것
helix-codex라는 MCP 서버를 만든 개발자는 Claude Code(Opus 4.6)가 작성한 코드를 GPT-5.4가 리뷰하게 했다. 결과: 리턴 코드 로직 버그, 터미널 인젝션 취약점, 경로 이중 적용 버그—3개의 치명적 이슈를 GPT-5.4가 발견했다. Claude는 자신이 쓴 코드에서 이것들을 놓쳤다.
이 실험이 흥미로운 건 기술적 완성도보다 방법론적 시사점 때문이다. 동일 모델이 생성하고 검토하면 맹점이 살아남는다. 다른 모델은 다른 사각지대를 갖고 있어서, 교차 리뷰가 자기 리뷰보다 실질적으로 효과적이다. 이건 인간 팀에서 작성자와 리뷰어를 분리하는 이유와 정확히 같은 논리다.
시사점: '도구 신뢰'는 설계 문제다
이 세 사건을 하나로 꿰면 결론은 간단하다. AI 코딩 도구의 신뢰성은 도구 자체의 속성이 아니라 그것을 둘러싼 검증 체계의 속성이다. Copilot이 광고를 삽입할 수 있다면 PR 병합 전 자동 검사가 필요하다. Cursor가 보안 컨텍스트를 놓친다면 배포 전 스캔이 필수다. 단일 모델 리뷰가 맹점을 남긴다면 교차 검증 레이어가 있어야 한다.
AI-First 팀에서 내가 실제로 권고하는 최소 검증 체계는 세 층위다.
1. 생성 단계 제약: .cursorrules 혹은 .github/copilot-instructions.md에 보안 규칙을 명시적으로 박는다. "항상 DB 쿼리에 userId 조건을 추가하라", "API 키는 절대 하드코딩하지 말고 process.env를 사용하라" 같은 룰은 AI 출력 품질을 실질적으로 바꾼다.
2. 리뷰 단계 교차 검증: 동일 모델이 작성하고 리뷰하는 루프를 끊는다. Claude Code + GPT 교차 리뷰, 또는 Codacy·CodeRabbit 같은 외부 LLM 리뷰어를 CI에 물린다. 특히 인증 미들웨어, API 라우트 가드, 권한 체크 코드는 AI 리뷰를 통과해도 사람이 한 번 더 읽는다.
3. 배포 단계 자동 스캔: ShipSafe, Snyk, Semgrep 중 하나를 CI/CD 파이프라인에 붙여 배포 전 강제 통과 게이트로 만든다. 2분짜리 스캔이 새벽 2시 인시던트 대응보다 훨씬 싸다.
전망: 신뢰 설계가 AI-First 팀의 핵심 역량이 된다
AI 코딩 도구의 속도 이점은 이제 기정사실이다. 논쟁은 끝났다. 다음 전장은 그 속도를 안전하게 다루는 검증 체계다. Copilot 광고 논란이 보여주듯 도구 벤더의 인센티브는 항상 개발자의 인센티브와 일치하지 않는다. Cursor 취약점 데이터가 보여주듯 AI는 '작동하는 코드'와 '안전한 코드'를 구분하지 않는다.
앞으로 AI-First 팀에서 진짜 시니어의 역할은 코드를 더 빠르게 쓰는 것이 아니라, AI 생성물이 통과해야 할 신뢰 게이트를 설계하고 유지하는 것이 될 것이다. 도구를 맹신하는 팀과 검증 체계를 설계한 팀의 격차는 첫 번째 보안 인시던트에서 갈린다. 그 인시던트가 오기 전에 체계를 짜는 것이 지금 테크 리드의 일이다.