코드 리뷰는 예전에 모두가 불평하던 부분이었습니다. 느리고, 까다로우며, 당신과 제품 출시 사이를 가로막는 장애물이었죠.

그리고 한동안, AI 코딩 에이전트(AI coding agents) 덕분에 코드 리뷰는 선택 사항처럼 느껴지기도 했습니다. 에이전트가 코드를 작성하고, 코드가 컴파일되며, 테스트를 통과하면 바로 출시하면 되었으니까요.

하지만 단순히 자신의 저장소(repo)를 넘어 산업 전체를 넓게 보았을 때, 그것이 실제로 어떤 모습일지 궁금해본 적이 있나요? 그리 좋지 않습니다. 검증 격차에 대한 산업 분석에 따르면, 2026년 3월 기준으로 AI가 생성한 코드의 40~62%가 보안 또는 설계 결함이 있는 상태로 출시되었으며, 올해 발생한 침해 사고 약 5건 중 1건은 AI가 작성한 코드로 거슬러 올라갑니다. 코드 생성은 정말 빨라졌습니다. 하지만 검증(Verification)은 같은 속도로 따라잡지 못했습니다. 당신의 팀에 인력이 배치되어 있든 아니든, AI 코딩 에이전트를 제대로 테스트하는 것이 바로 그 격차가 존재하는 지점입니다.

실제로 무엇이 망가지고 있는가?

구체적으로 살펴보겠습니다.

2026년 6월 말, Adversa AI의 보안 연구원들은 GuardFall이라고 불리는 것을 공개했습니다. 이는 Aider, Cline, Goose, OpenHands를 포함한 11개의 인기 오픈 소스 AI 코딩 및 컴퓨터 사용 에이전트 중 10개에 대해 작동하는 셸 해석 우회(shell-interpretation bypass) 방식입니다. 에이전트들은 명령어를 실행하기 전 원시 명령 텍스트(raw command text)의 위험성을 확인했지만, bash는 실제로 실행되기 전에 인용(quoting), 치환(substitution), 확장(expansion)을 통해 해당 텍스트를 다시 작성합니다. 따라서 안전 점검 시에는 무해해 보이는 명령어가 셸이 이를 처리하는 순간 폭발할 수 있습니다. 그리고 조사 대상 도구 중 단 하나만이 실제로 견뎌냈습니다!

The check reads the label. It never sees what the parcel turns into.

그리고 이는 에이전트(agents)를 로컬에서 실행하는 사람들에게만 해당하는 예외적인 사례가 아닙니다. 이미 프로덕션(production) 환경에서 운영 중인 5,600개의 바이브 코딩(vibe-coded) 앱을 스캔한 결과, 2,000개의 매우 심각한 취약점과 400개의 노출된 비밀 정보(exposed secrets)가 발견되었으며, 이 중 일부는 의료 기록과 결제 정보를 노출하고 있었습니다. Georgia Tech의 Vibe Security Radar는 이 추세가 개선되기는커녕 악화되고 있음을 추적했습니다: 2026년 1월에 6건, 2월에 15건, 3월에 35건의 AI 생성 취약점이 확인되었습니다.

Even Kernel doesn't like where this evidence is pointing.

모델이 훨씬 좋아졌는데 왜 이런 일이 발생할까요?

글쎄요, 바로 그 지점이 사람들이 거꾸로 생각하고 있는 부분입니다.

더 나은 모델이 검증(verification)의 필요성을 없앤 것이 아니라, 단지 병목 현상(bottleneck)의 위치를 옮겼을 뿐입니다. 솔루션을 생성하는 것은 이미 오래전에 어려운 부분이 아니게 되었습니다. 이제 어려운 부분은 그 솔루션을 실제로 신뢰할 수 있는지 결정하는 것이며, 기업 의사 결정권자의 55.4%가 이미 에이전트의 신뢰성(reliability)과 환각 관리(hallucination management)를 프로덕션 환경의 최우선 과제로 꼽고 있습니다. 코드는 컴파일되고 테스트는 통과하지만, 리뷰어들은 해당 변경 사항이 안전한지 판단하기 전에 그 변경 사항이 무엇을 하려고 했는지부터 다시 재구성해야 합니다.

저는 실제로 이 일을 해봤습니다, 그리고 결코 화려한 작업이 아닙니다

저는 외부인의 입장에서 이 글을 쓰는 것이 아닙니다. 최근 저는 본격적으로 가속하기 전 제품 시장 적합성 (PMF)을 찾아가고 있는 초기 단계의 스타트업과 함께 일했습니다. 저는 그 제품의 첫 번째 내부 테스트 계층 역할을 맡았는데, 그 제품은 스스로 진화하는 슈퍼 에이전트 (self-evolving super agent)였습니다 (더 이상 밝힐 수는 없으니 조금 모호하게 남겨두겠습니다 ㅎㅎ). 제 업무 전체는 핵심 사용자들이 에이전트를 접하기 전에 버그를 잡아내는 것이었습니다. 또한 저는 엄격한 규칙에 기반한 에이전트 체인 (agent chain) 형태의 내부 도구를 구축했습니다. 이 도구는 에이전트의 데이터 로그를 추출하고 이를 평가하여, 피드백과 실제 시나리오로부터의 자기 학습 (self-learning)이 환각 (hallucination)을 일으키고 있지는 않은지, 그리고 에이전트가 가이드라인 자체를 조작하려 하지는 않는지 확인하는 역할을 했습니다. 또한 지연 시간 (latency) 및 발생 가능한 성능 저하에 대한 보고서를 생성했습니다. 왜냐하면 "작동하는 것 같다"는 것은 테스트 전략이 될 수 없으며, 숫자가 전략이기 때문입니다.

Someone has to stand between the output and the door. That someone had a job title.

그전에는 Keploy에서 API 테스트를 시연하기 위한 샘플 앱을 구축하고 개선하는 데 시간을 보냈습니다. 따라서 제가 에이전트의 출력을 테스트하는 것이 단순히 체크박스 하나를 채우는 일이 아니라, 실제로 인력을 배치해야 하는 직무라고 말하는 것은 헤드라인에서 따온 자극적인 의견이 아니라, 제가 실제로 돈을 받고 했던 일입니다.

그리고 에이전트 자체에 대해 공정하게 말하자면, 그들은 진정으로 빠르고 진정으로 유용합니다. 저는 Claude Code, Antigravity, Codex를 매일 사용하며, 그렇지 않은 척할 생각도 없습니다. 문제는 그들이 작성하는 코드가 평균적으로 나쁘다는 것이 아니었습니다. 문제는 "평균적으로"라는 기준이 보안과 정확성 측면에서는 완전히 잘못된 기준이라는 점입니다. 왜냐하면 실패는 당신이 구체적으로 확인하지 않은 5~10%의 구간에 집중되어 나타나기 때문입니다.

(그리고 맞습니다, 이 포스트는 제가 직접 만든 에이전트 기술(agent skill)로 초안을 작성했으며, 게시하기 전에 제가 직접 검토하고 수정할 예정입니다. 이는 아이러니가 아니라 바로 핵심입니다. 초안은 사실 관계와 구조를 정확하게 잡을 수 있지만, 어떤 근거(receipts)가 실제로 여기에 포함되어야 하는지, 그리고 에이전트의 입장을 얼마나 강력하게 옹호(steelman)해야 하는지를 결정하는 것은 여전히 인간의 몫입니다. 이 경우에는 저의 몫이죠.)

실제로 무엇을 다르게 해야 할까요?

에이전트의 결과물을 당신 자신의 코드를 리뷰하는 방식대로 검토하는 것을 멈추세요. 대신, 숙련도가 빠른 주니어 개발자의 아주 첫 번째 PR(Pull Request)을 리뷰하는 방식처럼 검토하기 시작하세요. 즉, 역량은 있다고 가정하되, 모든 것, 특히 실행(execution)에 직접적인 영향을 미치는 부분은 반드시 검증해야 합니다.

구체적으로는 다음과 같습니다: 중간에 실제 평가자(evaluator)를 두지 않은 채, 에이전트가 검토되지 않은 가공되지 않은 문자열(raw strings)을 셸(shell)로 직접 전달하게 두지 마세요. GuardFall이 존재하는 이유는 팀들이 문자열 매칭(string-matching)만으로 충분하다고 가정했기 때문입니다. 실제 인간의 리뷰 시간을 '있으면 좋은 것(nice-to-have)'이 아니라, 이러한 도구들을 사용하는 데 드는 '고정 비용'으로 예산에 편성하세요. 그리고 조지아 공대(Georgia Tech)가 업계의 취약성을 추적했던 방식처럼 당신만의 취약성 추세선(vulnerability trend line)을 추적하세요. 왜냐하면 "아직 망가지지 않았다"는 것이 "괜찮다"는 것과 같은 의미는 아니기 때문입니다.

또한 에이전트를 테스트한다는 것은 단순히 배포 전에 버그를 잡는 것만을 의미하지 않습니다. 그것은 에이전트가 시간이 지남에 따라 당신에게 조용히 어떤 비용을 발생시키는지 관찰하는 것이기도 합니다. 제가 처음에 내부 지연 시간 추적(latency-tracking) 도구를 만든 이유가 바로 그것입니다. 속도 저하에 대한 수치는 사용자가 불만을 제기하기 훨씬 전부터 문제를 포착해 냅니다. 직접 구축하고 싶지 않다면, 이를 대신 해주는 도구들이 등장하고 있습니다. 최근에 Maxim AI의 Bifrost를 발견했는데, 이는 당신과 코딩 에이전트 사이에 위치하는 게이트웨이로, 지연 시간(latency), 비용, 토큰 사용량을 하나의 대시보드에서 제공하며, 모델이 오작동하기 시작할 때를 위한 폴백 로직(fallback logic)도 제공합니다. 요즘 우리 대부분처럼 수많은 에이전트와 LLM(대규모 언어 모델)을 다루고 있다면 살펴볼 가치가 있습니다.

이 에이전트들을 사용하세요. 정말로 사용하세요. 이들은 사라지지 않을 것이며, 제 개인적인 워크플로우(workflow)에서도 그 자리를 확고히 차지했습니다. 하지만 에이전트를 테스트하는 것을 사후 고려 사항이 아닌, 실제 업무의 핵심으로 취급하세요. 왜냐하면 현재 대부분의 팀에게 테스트는 여전히 사후 고려 사항에 머물러 있기 때문입니다.

만약 여러분이 AI 도구를 위한 자체적인 테스트 레이어(testing layer)를 구축하고 있거나, 테스트 레이어가 없는 도구 때문에 피해를 본 적이 있다면, 진심으로 그 이야기를 듣고 싶습니다. 댓글로 남겨주세요. 저는 swapnoneel.site에서 에이전트 툴링(agent tooling)과 AI를 활용한 구축에 대해 더 많은 글을 작성하고 있으며, 여기에는 제가 어떻게 스스로 개선되는 글쓰기 에이전트를 만들었는지에 대한 내용도 포함되어 있습니다. 또한 X (swapnoneel123)에서도 저를 찾으실 수 있습니다.

Your turn. What did your testing layer catch?