AI가 코드를 생성하는 것은 이제 놀랍지 않다. 놀라운 건 그 다음이다. AI가 작성한 코드가 프로덕션에서 조용히 실패하고, 그 버그를 찾는 데 3일이 걸리며, 정작 수정은 10분으로 끝나는 아이러니—이 간극이 에이전트 시대 QA의 핵심 문제다.
침묵하는 실패가 가장 비싸다
dev.to에 올라온 한 개발자의 회고는 AI 생성 코드의 엣지 케이스 위험을 적나라하게 보여준다. 그는 AI에게 사용자 입력 리스트를 처리하는 함수를 맡겼다. 코드는 깔끔했고, 테스트는 통과했으며, PR은 다음 날 아침 스탠드업에서 승인됐다. 문제는 이틀 뒤 빈 리스트를 가진 사용자가 엔드포인트를 호출했을 때 터졌다. 함수는 에러도, 경고도, 로그 메시지도 없이 그냥 아무것도 반환하지 않았다. UI는 응답을 기다리며 멈췄고, 사용자는 혼란에 빠졌다.
원인은 단순했다. AI는 리스트가 항상 최소 하나의 아이템을 가진다고 가정했다. 개발자는 AI가 엣지 케이스를 처리했을 것이라고 가정했다. 두 가정 모두 틀리지 않았지만, 둘 다 검증되지 않았다. if not items: return []—딱 한 줄이면 됐다. 이 줄을 찾는 데 3일이 걸렸다. AI는 훈련 데이터의 대부분이 아이템이 있는 리스트였기 때문에 빈 리스트 시나리오를 자연스럽게 건너뛰었다. 생성 단계에서의 맹점은 리뷰 단계에서 반드시 걸러야 한다.
버그 리포팅도 AI가 바꾼다—단, 제대로 설계할 때
버그를 찾는 문제만큼이나 버그를 보고하는 문제도 팀의 생산성을 잡아먹는다. 같은 플랫폼의 또 다른 글은 이 문제를 실용적으로 해결한 사례를 공유한다. PM이 "checkout이 안 돼요"라는 캡션과 함께 스크린샷 하나를 팀 채팅에 던지면, 개발자는 플랫폼이 뭔지, 재현 스텝이 뭔지 추측해야 한다. 이 반복되는 마찰을 없애기 위해 그는 Telegram 봇 + Next.js + Google Gemini Vision API + Jira REST API로 자동화 파이프라인을 구축했다.
워크플로우는 이렇다. PM이 스크린샷과 짧은 설명을 봇에 전달하면, Gemini Vision이 이미지를 분석해 버그 제목, 재현 스텝, 기대 결과, 실제 결과를 구조화된 JSON으로 반환한다. 이 결과가 Jira 티켓으로 자동 생성되고, 15초 안에 티켓 링크가 채팅에 올라온다. 비개발자의 습관을 바꾸려고 싸우는 대신, 그 습관 그대로를 AI가 번역하는 구조다. 'garbage in, garbage out'의 법칙을 AI 레이어가 흡수한 셈이다.
에이전트 네이티브 워크플로우의 본질은 '게이트'다
GitHub Copilot의 데스크톱 에이전트 워크플로우 발표, OpenAI의 Codex 생산성 레이어 확장—dev.to의 분석대로 신호는 명확하다. 에이전트는 이제 편집기 옆의 채팅 박스가 아니라 개발 워크플로우 자체의 일부가 되고 있다. 그런데 이 전환에서 정작 중요한 질문은 "얼마나 빨리 코드를 생성하냐"가 아니다. "생성된 코드를 얼마나 신뢰할 수 있는 구조로 검증하냐"다.
에이전트가 변경한 코드에 대해 팀이 물어야 할 질문들이 있다. 어떤 에이전트가 무엇을 바꿨는가? 기존 아키텍처를 이해하고 수정했는가? 테스트는 실제로 의미 있는가, 아니면 그냥 초록색인가? 이 diff는 머지해도 안전한가? 그리고 최종 결정의 책임은 누가 지는가? 이 질문들에 답하지 못하면 "AI가 내 생산성을 높였다"는 말은 조용히 "AI가 내가 신뢰할 수 없는 리뷰 큐를 만들었다"로 바뀐다.
실용적인 에이전트 리뷰 게이트는 복잡하지 않다. diff 요약, 위험 영역 리스트, 테스트 실행, 보안 민감 파일 플래그, 그리고 에이전트가 확신하지 못하는 부분의 명시적 고백—이 다섯 가지를 에이전트가 먼저 보여주고, 머지 승인은 사람이 한다. YAML 한 조각이 아니라, 에이전트에게 작업을 위임하면서도 인간이 최종 게이트를 쥐는 구조적 원칙이다.
시사점: '무엇을 검증하냐'가 워크플로우의 품질을 결정한다
세 가지 사례가 하나의 방향을 가리킨다. AI 생성 코드는 빈 리스트처럼 당연하게 여겨지는 엣지 케이스를 놓친다. 비구조적인 버그 리포트는 AI Vision으로 구조화할 수 있다. 에이전트 네이티브 환경에서 경쟁 우위는 모델 품질이 아니라 오케스트레이션과 검증 설계에서 나온다. 이 세 가지 모두 '생성 이후'의 문제다.
빠른 프로토타이핑 → 검증 → 고도화 사이클을 진지하게 운영하는 팀이라면, 지금 당장 에이전트를 더 크게 쓰는 것보다 리뷰 루프를 더 신뢰할 수 있게 만드는 것에 먼저 투자해야 한다. 출시 전 "이 함수에 아무것도 들어오지 않으면 어떻게 되는가?"를 묻는 30초짜리 질문 하나가, 프로덕션에서의 3일짜리 디버깅을 막는다. AI 에이전트도 마찬가지다—스코프를 좁히고, 증거를 요구하고, 머지 결정은 사람이 쥔다. 더 크게 쓰는 게 아니라, 더 안전하고 매끄럽게 쓰는 것이 목표다.
전망: 검증 인프라가 다음 경쟁 축이 된다
다음 세대 개발 도구의 경쟁은 모델 성능 벤치마크가 아니라 에이전트 오케스트레이션과 검증 가시성에서 결정될 가능성이 높다. 여러 에이전트의 변경사항을 비교하고, 체크를 재실행하고, 리뷰 컨텍스트를 유지하는 도구—이것이 실제 팀이 필요로 하는 것이다. 더 많은 AI 출력이 아니라, 더 촘촘한 피드백 루프와 더 깔끔한 diff가 필요하다. QA 자동화의 다음 전선은 버그를 발견하는 AI와 코드를 리뷰하는 AI가 하나의 신뢰 가능한 파이프라인으로 연결되는 지점에 있다.