숫자부터 직면하자
72%의 개발자가 AI 코딩 도구를 매일 사용한다. 그런데 그 도구가 만든 코드를 신뢰한다는 개발자는 4%에 불과하다. SonarSource의 State of Code 2026 보고서는 여기서 한 걸음 더 나아간다. 개발자의 61%가 AI 생성 코드가 "겉으론 맞아 보이지만 신뢰할 수 없다"고 답했고, 절반 가까이는 기능 자체가 틀렸다고 본다. Stack Overflow 조사에서는 AI 도구 사용률이 84%로 올라가는 동안 신뢰도는 오히려 29%로 추락했다.
채택률과 신뢰도가 반대 방향으로 움직이는 이 현상을 dev.to 필자 adioof는 '채택-신뢰 역설(Adoption-Trust Paradox)'이라고 부른다. 우리는 믿지 않는 코드를 매일 쓰고 있다. 그리고 그 코드를 근거로 팀 규모를 줄이는 의사결정이 이미 내려지고 있다.
왜 '쓰는데 못 믿는' 상태가 됐나
이 역설의 뿌리는 단순하다. 측정 지표와 실제 품질 사이의 시차다. AI는 PR 수, 병합된 커밋, 배포된 피처 등 대시보드에 잡히는 숫자를 빠르게 올린다. 경영진이 보는 지표는 전부 초록불이다. 그런데 보안 취약점, 유지보수 비용, 기술 부채는 대시보드에 잡히지 않다가 뭔가 터졌을 때 한꺼번에 드러난다.
보안 연구들은 AI 생성 코드의 40~62%가 알려진 취약점을 포함한다고 보고한다. 개발자 10명 중 약 7명은 실제로 AI가 끼워넣은 보안 결함을 자기 시스템에서 발견한 경험이 있다. 더 심각한 건 AI 코드를 커밋 전에 일관되게 리뷰하는 팀이 48%에 불과하다는 사실이다. 나머지 절반은 그냥 머지한다.
개발자들이 게을러서가 아니다. 마감은 코드 리뷰 프로세스를 기다려주지 않고, 관리자는 '10배 생산성' 헤드라인을 보며 스프린트 속도가 왜 안 오르냐고 묻는다. 결국 탭 완성 버튼을 누르고 넘어가는 선택이 쌓인다.
에이전트를 여러 개 굴리면 문제는 배로 커진다
신뢰 문제가 개인 개발자 레벨에서 끝나면 그나마 관리가 된다. 그런데 팀 전체가 AI-First 워크플로우로 전환하고, 병렬로 여러 에이전트를 돌리기 시작하면 전혀 다른 차원의 혼돈이 열린다.
Switchman 개발자가 dev.to에 공유한 실험은 그 현실을 날것 그대로 보여준다. 하나의 레포에 여러 AI 에이전트를 동시에 투입했을 때 발생한 문제 목록이다: 두 에이전트가 같은 파일을 동시에 수정한다. 한 에이전트가 공유 모듈을 바꾸면 다른 에이전트가 쌓아올린 작업이 조용히 낡아버린다. 브랜치 각각은 멀쩡해 보이는데 머지 타임에 충돌이 터진다. 그리고 결국 사람이 에이전트들의 스케줄러 역할을 하느라 정작 배포는 못 한다.
브랜치 전략이나 Git worktree로는 이 문제를 해결할 수 없다. Isolation(격리)은 줄 수 있어도 Orchestration(조율)은 주지 못하기 때문이다. 누가 어떤 파일을 작업하는지, 어떤 작업이 선행되어야 하는지, 무엇이 먼저 머지되어야 하는지—이 의사결정 레이어가 없으면 병렬 에이전트는 생산성을 높이는 게 아니라 오버헤드를 배로 만든다.
신뢰는 도구 업그레이드로 오지 않는다
그렇다면 AI 코드를 팀이 실제로 신뢰하게 만들려면 무엇이 필요한가. 내 답은 간단하다: 워크플로우 설계다. 도구가 좋아질 때까지 기다리는 건 전략이 아니다.
dev.to의 AI-Powered Dev Workflows 가이드가 제시하는 2026년 실전 프랙티스는 이 방향을 구체화한다. 핵심 원칙 세 가지만 뽑으면:
첫째, Context Engineering. 프롬프트 엔지니어링이 아니다. AI에게 코드 생성을 요청할 때 사용 데이터베이스, 인증 방식, 에러 처리 규격, 성능 요구사항, 프로젝트 스타일 가이드까지 구조화된 컨텍스트를 주지 않으면 범용적이고 취약한 코드가 나온다. 좋은 AI 코드의 전제조건은 좋은 컨텍스트다.
둘째, AI-Human 피드백 루프. PR 리뷰에서 AI가 문법, 스타일, 일반 취약점 등 기계적 검사의 80%를 담당하고, 사람은 비즈니스 로직 판단에 집중하는 구조다. 핵심은 AI가 생성한 PR은 자동화 보안 스캐너 승인 + 사람의 비즈니스 로직 사인오프 없이는 절대 머지되지 않는다는 규칙을 명문화하는 것이다.
셋째, 자율 테스트 생성의 품질 기준. AI가 만드는 테스트가 teardown도 없고, mock도 없고, 엣지케이스도 없는 취약한 코드라면 테스트 자체가 거짓 안도감을 준다. 테스트 프레임워크와 mock 구조를 컨텍스트로 제공하고, NoSQL injection 같은 실제 공격 시나리오까지 포함한 테스트를 생성하도록 설계해야 한다.
팀 레벨에서 신뢰를 설계하는 실전 포인트
이 세 원칙을 팀에 적용할 때 테크 리드가 직접 설계해야 할 것들이 있다.
AI 코드 리뷰를 프로세스로 고정하라. '가능하면 리뷰한다'가 아니라 'AI 생성 코드는 반드시 이 단계를 거친다'를 CI/CD 파이프라인에 하드코딩해야 한다. 보안 스캐너를 선택적 단계가 아니라 머지 블로커로 걸어두는 것부터 시작이다.
멀티 에이전트를 운영한다면 조율 레이어를 먼저 설계하라. 에이전트에게 작업을 넘기기 전에 파일 소유권, 의존성 순서, 머지 우선순위를 결정하는 사람(혹은 시스템)이 있어야 한다. 이 레이어 없이 병렬 에이전트를 돌리면 개발자가 에이전트 PM이 되어버린다.
라이브러리 버전과 패턴을 시스템 프롬프트로 고정하라. AI가 deprecated된 라이브러리 패턴이나 프로젝트 컨벤션을 무시한 코드를 생성하는 건 모델 문제가 아니라 컨텍스트 문제다. "Next.js 15 App Router만 사용