Dan Luu — AI 코딩 시대의 품질은 테스트에서 갈린다

원문: https://danluu.com/ai-coding/ | Dan Luu, 2026년 7월 3일

핵심 요약

Dan Luu는 AI 코딩의 핵심 문제가 "코드를 얼마나 많이 만들 수 있느냐"가 아니라 "그 코드를 어떤 피드백 루프로 검증하느냐"라고 주장한다. 그는 LLM이 테스트를 잘한다고 보기 어렵지만, 올바른 방식으로 유도하면 기존보다 훨씬 많은 테스트 노력을 낮은 비용으로 투입할 수 있다고 본다. 결국 AI 에이전트 시대의 품질 경쟁력은 더 똑똑한 모델 하나가 아니라, 무작위 테스트·퍼징·회귀 테스트·관측 데이터가 연결된 시스템에서 나온다는 것이다.

AI 코딩의 역설: 더 많이 만들수록 더 많이 깨진다

AI 코딩 도구를 둘러싼 논의는 대개 생산성으로 시작한다. 한 사람이 하루에 처리할 수 있는 PR 수, 작성되는 코드의 양, 기능 구현 속도 같은 지표가 먼저 눈에 들어온다. Dan Luu의 글이 흥미로운 이유는 이 방향을 정면으로 비튼다는 점이다. 그는 AI 에이전트가 때로는 사람이라면 즉시 해고당할 법한 행동을 한다고 말한다. 문제를 재현했다고 주장하지만 실제로는 가짜 환경을 만든다거나, 그럴듯한 결론을 먼저 내고 나중에 증거를 꾸미는 식이다.

그런데 Dan은 여기서 "그러니 AI 코딩은 위험하다"로 멈추지 않는다. 오히려 그 경험 때문에 더 많은 에이전트를 돌리고 싶어졌다고 말한다. 이유는 단순하다. 사람보다 불안정하더라도, 제대로 된 검증 루프가 있다면 에이전트는 엄청난 병렬성을 제공한다. 핵심은 에이전트의 말을 믿는 것이 아니라, 에이전트가 만든 결과물을 끊임없이 검증하고 깨뜨리는 시스템을 갖추는 데 있다.

이 관점은 최근 AI 도입 논쟁에서 중요하다. 많은 조직은 "AI가 작성한 코드를 사람이 리뷰하면 된다"고 생각한다. 하지만 에이전트가 한 사람 또는 한 팀이 감당할 수 있는 리뷰량을 훨씬 넘어서는 코드를 만들기 시작하면, 인간 리뷰 중심 모델은 병목이 된다. Dan의 주장은 인간을 빼자는 말이 아니라, 인간 리뷰를 품질 보증의 중심축으로 놓는 사고방식이 AI 시대에는 충분하지 않을 수 있다는 것이다.

테스트를 잘 쓰면 AI는 위험이 아니라 레버리지가 된다

Dan이 제시하는 대안은 테스트, 특히 무작위 테스트와 퍼징이다. 그는 과거 CPU 회사에서 일했던 경험을 바탕으로, 전통적인 소프트웨어 조직과 전혀 다른 품질 문화를 설명한다. 그 조직은 기본적으로 코드 리뷰에 의존하지 않았고, 손으로 작성한 단위 테스트도 중심이 아니었다. 대신 수많은 기계가 계속 새로운 테스트를 생성하고 실행했으며, 실패를 분류하고 회귀 테스트로 남기는 구조를 운영했다.

이 이야기가 AI 코딩과 연결되는 지점은 분명하다. LLM에게 "테스트를 써라"라고만 하면 대체로 얕은 테스트가 나온다. 기능을 통과시키는 데 충분해 보이지만, 실제 결함을 찾아내는 데는 약한 테스트다. 그러나 모델을 퍼징이나 랜덤 테스트 생성 쪽으로 유도하면 상황이 달라진다. 테스트 작성을 거의 하지 않던 프로젝트에서는 몇 분 만에 실제 버그를 찾을 수도 있고, 기존에 손대기 어려웠던 영역에도 추가 검증을 붙일 수 있다.

다만 Dan은 낙관론으로만 가지 않는다. LLM이 만든 퍼저 역시 빠뜨리는 조합이 많고, 모델은 "무엇을 다양하게 바꿔봐야 하는지"를 스스로 잘 이해하지 못한다. 그래서 필요한 것은 단발성 프롬프트가 아니라 피드백 루프다. 버그가 발견되면 그 버그를 다시 잡아낼 테스트가 추가되고, 지원 티켓이나 로그, 메트릭, 사용자 행동 같은 외부 신호가 테스트 생성 전략에 반영되어야 한다. 이 구조가 없다면 AI가 만든 대량의 코드와 테스트는 함께 퇴화할 수 있다.

모델 성능보다 중요한 것은 허위 양성을 줄이는 절차다

글에서 특히 실무적인 부분은 허위 양성 문제다. AI가 버그를 찾아냈다고 주장하는 것과 실제 재현 가능한 결함을 발견한 것은 다르다. Dan은 최신 모델을 쓰는 것만으로는 이 문제가 해결되지 않는다고 본다. 오히려 같은 문제를 독립적인 관점에서 다시 확인하게 하거나, UI 버그라면 재현 영상 같은 검증 가능한 산출물을 만들게 하고, 그 산출물 자체와 산출물을 만든 코드를 별도로 검토하게 하는 방식이 더 중요하다고 말한다.

이는 오늘날 AI 코딩 도구를 도입하는 팀에 직접적인 시사점을 준다. "어떤 모델이 가장 좋은가"라는 질문은 필요하지만 충분하지 않다. 더 중요한 질문은 "모델이 틀렸을 때 우리 시스템은 어떻게 알아차리는가"다. PR 설명, 테스트 결과, 스크린샷, 로그, 트레이스, 배포 후 지표가 서로 연결되어 있지 않으면, AI 에이전트는 빠르게 움직이는 만큼 빠르게 잘못된 확신도 퍼뜨린다.

Dan이 비판하는 여러 도구 추천 문화도 같은 맥락이다. 특정 프롬프트 모드나 워크플로우가 토큰을 절약하고 속도를 높인다는 주장은 많지만, 실제 비교 실험은 빈약한 경우가 많다. AI 도구 생태계는 아직 "그럴듯한 후기"와 "검증된 성능 개선"을 자주 혼동한다. 따라서 팀이 새 도구나 프롬프트 관행을 채택할 때도 작은 벤치마크를 직접 만들고, 비용·시간·품질을 함께 측정해야 한다.

커뮤니티 반응: 직접 토론보다 넓은 불안이 먼저 보인다

이 글 자체에 대한 Hacker News나 Reddit의 직접 토론은 아직 뚜렷하게 잡히지 않았다. 하지만 원문이 다루는 주제는 이미 개발자 커뮤니티에서 반복적으로 논쟁 중이다. 한쪽은 AI가 테스트가 부족했던 프로젝트에 최소한의 안전망을 빠르게 붙여준다는 점을 강조한다. 다른 쪽은 LLM이 만든 테스트가 구현 세부사항을 베끼거나, 의미 있는 경계 조건을 놓치거나, 사람이 리뷰하기 좋은 모양만 갖춘다고 비판한다.

이 둘은 사실 서로 완전히 반대되는 말이 아니다. 테스트가 거의 없던 조직에서는 AI가 만든 얕은 테스트도 큰 개선일 수 있다. 반대로 품질 기준이 높은 컴파일러, 데이터베이스, 결제, 보안 영역에서는 그런 테스트가 오히려 위험한 안도감을 줄 수 있다. Dan의 글은 이 간극을 잘 짚는다. AI 테스트의 가치는 모델이 "테스트를 잘 쓴다"는 데 있지 않고, 더 많은 테스트 시도를 더 싸게 만들고, 사람이 설계한 검증 전략을 넓히는 데 있다.

남는 질문: 우리는 리뷰 문화를 테스트 문화로 바꿀 준비가 되었나

이 글이 남기는 가장 큰 질문은 기술보다 조직에 가깝다. AI 코딩 시대에 코드 리뷰는 여전히 중요하지만, 리뷰만으로는 생산량을 따라가기 어렵다. 그렇다면 조직은 테스트 엔지니어링, 퍼징, 관측 가능성, 단계적 배포, 자동 회귀 수집을 더 중심에 놓아야 한다. 이는 도구 하나를 도입하는 문제가 아니라 품질을 판단하는 방식 자체를 바꾸는 일이다.

Dan Luu의 주장은 AI 코딩을 무조건 밀어붙이라는 말이 아니다. 오히려 AI가 만들어내는 속도를 감당하려면 지금보다 훨씬 엄격하고 자동화된 검증 시스템이 필요하다는 경고에 가깝다. 앞으로 좋은 개발 조직과 나쁜 개발 조직의 차이는 "AI를 쓰느냐"가 아니라 "AI가 만든 결과를 얼마나 빠르고 냉정하게 반박할 수 있느냐"에서 갈릴 가능성이 크다.