결론부터 말씀드리겠습니다. AI가 짠 코드는 결국 사람이 테스트합니다. 더 정확히는, AI가 코드 생산량을 늘릴수록 “이 코드가 맞는가”를 판단하는 부담은 사라지지 않고 사람에게 더 쏠립니다. 작성은 자동화됐지만 검증은 자동화되지 않았기 때문입니다.
흥미로운 데이터가 하나 있습니다. 2025년 METR이 평균 100만 줄 규모의 실제 오픈소스 저장소에서 숙련 개발자 16명에게 246개 작업을 시킨 실험에서, 이들은 AI 도구를 쓰면 20% 빨라졌다고 느꼈지만 실제로는 19% 느려졌습니다. 체감과 실측이 반대로 간 겁니다. 오늘은 이 간극이 어디서 생기는지, 그리고 AI 코드 테스트의 책임을 어디에 다시 세워야 하는지 이야기해보겠습니다.
AI는 작성을 자동화했지 검증을 자동화하지 못했다
프레드 브룩스는 1986년 「은총알은 없다」에서 소프트웨어의 어려움을 본질적 난이도와 부수적 난이도로 나눴습니다. 부수적 난이도는 코드를 타이핑하고 문법을 맞추는 노동입니다. 본질적 난이도는 “무엇을 만들 것이며, 무엇이 옳은 동작인가”를 정하는 일입니다. AI가 극적으로 줄여준 것은 전자입니다. 후자는 그대로 남아 있습니다. (오히려 무거워졌다고 봅니다.)
코드를 쓰는 속도가 빨라지면 검증해야 할 표면적도 같은 속도로 늘어납니다. 그런데 리뷰와 테스트의 처리량은 사람의 속도에 묶여 있습니다. 자연히 병목은 작성에서 검증으로 옮겨갑니다. 이미 코드의 절반은 이미 AI가 쓰고 있다는 현실에서, 사람이 한 줄도 들여다보지 않은 코드의 비율은 계속 올라갑니다.
품질 지표도 이 방향을 가리킵니다. GitClear가 2020년부터 2024년까지 2억 1100만 줄의 코드 변경을 분석한 결과는 다음과 같습니다.
| 지표 | 2020~2021년 | 2024년 |
|---|---|---|
| 복사-붙여넣기된 코드 비율 | 8.3% | 12.3% |
| 리팩터링(이동)된 코드 비율 | 25% | 10% 미만 |
| 커밋 2주 내 재수정되는 코드 | 3.1% | 5.7% |
| 5줄 이상 중복 블록 발생 | 기준치 | 약 8배 |
복사된 코드가 정리된 코드를 처음으로 추월한 해가 2024년입니다. 중복 코드는 한 곳을 고치면 다른 곳을 놓치기 쉬워 결함의 온상이 됩니다. 생산량이 늘어난 만큼 기술 부채도 눈에 보이지 않는 곳에 함께 쌓이고 있다는 뜻입니다.
커버리지 90%가 안심을 주지 못하는 이유
많은 팀이 이 불안을 테스트 커버리지 숫자로 달랩니다. 그러나 커버리지는 테스트가 실행한 코드 라인의 비율일 뿐, 그 코드가 옳다는 증명이 아닙니다. 다익스트라가 남긴 문장이 본질을 찌릅니다.
테스트는 버그의 존재를 보여줄 수 있을 뿐, 버그의 부재를 증명하지는 못한다. — 에츠허르 다익스트라
마틴 파울러도 같은 맥락에서, 커버리지는 테스트되지 않은 코드를 찾는 도구로는 유용하지만 목표 수치로 삼으면 해롭다고 지적합니다. 여기서 굿하트의 법칙이 작동합니다. 측정값이 목표가 되는 순간 그 측정값은 좋은 지표이기를 멈춘다. 커버리지 90%를 강제하면, 사람이든 AI든 단언(assertion) 없이 함수만 호출하고 지나가는 테스트를 양산합니다. 숫자는 채워지지만 검증은 일어나지 않습니다.
AI에게 테스트까지 맡길 때 더 미묘한 함정이 생깁니다. 같은 모델이 구현과 테스트를 함께 생성하면, 테스트가 명세가 아니라 구현을 그대로 베끼는 자기참조 테스트가 되기 쉽습니다.
# 구현에 버그가 있다 (10% 할인인데 부호가 반대)
def apply_discount(price, rate):
return price + price * rate # 의도는 price - price * rate
# AI가 구현을 보고 만든 테스트 — 버그를 정답으로 고정한다
def test_apply_discount():
assert apply_discount(100, 0.1) == 110 # 통과하지만 틀렸다
# 명세에서 출발한 테스트 — 사람이 "옳은 동작"을 먼저 정한다
def test_apply_discount_spec():
assert apply_discount(100, 0.1) == 90 # 실패하며 버그를 드러낸다위쪽 테스트는 초록불을 켜고 커버리지를 올리지만, 잘못된 동작을 영구히 보증합니다. 테스트가 구현의 거울이 되면 그 거울은 버그까지 충실히 비춥니다. 커버리지가 잡아내는 것과 놓치는 것을 구분하면 이렇습니다.
| 커버리지가 보장하는 것 | 커버리지가 침묵하는 것 |
|---|---|
| 해당 라인이 한 번 실행됐다 | 그 라인이 옳은 값을 냈는가 |
| 분기가 양쪽으로 갈렸다 | 명세를 충족했는가 |
| 코드가 예외 없이 돌았다 | 엣지 케이스를 다뤘는가 |
그래서 사람은 어디에 서야 하는가
답은 사람을 검증의 위쪽으로, 즉 “코드가 맞는가”에서 “무엇이 맞는가를 정의하고 그 정의를 지키는 일”로 옮기는 것입니다. AI 코드 테스트에서 사람이 사수해야 할 자리는 세 곳입니다.
첫째, 명세는 사람이 정합니다. 골든 케이스와 엣지 케이스, 즉 “이 입력에는 반드시 이 출력”이라는 계약은 구현과 독립적으로 사람이 먼저 적습니다. 그다음에야 AI에게 그 계약을 통과시키라고 시킵니다. 구현 생성과 테스트 생성을 다른 컨텍스트로 분리하는 것만으로도 자기참조 함정의 상당 부분을 막을 수 있습니다.
둘째, 사람은 코드가 아니라 테스트를 리뷰합니다. 코드 리뷰는 코드를 보는 일이 아니다에서 짚었듯, 리뷰의 본질은 의도와 결과의 일치를 확인하는 일입니다. AI가 100개의 테스트를 쏟아낼 때, 사람이 던질 질문은 “이 테스트들이 정말 중요한 실패를 잡는가”입니다. 속성 기반 테스트나 계약 테스트처럼 수많은 입력을 자동으로 탐색하는 기법은, 사람이 일일이 케이스를 적는 대신 “지켜야 할 속성”을 선언하게 해줍니다. AI와 잘 맞는 조합입니다.
셋째, 자동화 인프라에 투자합니다. 검증의 처리량을 사람의 손에서 떼어내야 작성 속도를 따라잡습니다. 실제로 제가 예전에 한 팀에서 테스트 자동화와 CI 파이프라인을 정비했을 때, 회귀 검증에 들던 수작업이 사라지면서 QA 프로세스 효율이 40% 가까이 올라갔던 기억이 있습니다. 흥미로운 건 그 효과가 단순히 빨라진 게 아니라, 사람이 비로소 “무엇을 테스트할지”를 고민할 시간을 되찾았다는 점이었습니다. 또 다른 커뮤니티 서비스에서는 출석·배지 판별 같은 핵심 로직에 단위 테스트를 깔면서 다양한 입력 형식과 엣지 케이스를 직접 정의했는데, 정작 버그가 잡힌 곳은 늘 제가 “설마 이런 입력이 들어올까” 의심했던 경계값이었습니다. 그 경계를 의심하는 일은 지금도 사람의 몫입니다.
여기엔 트레이드오프가 있습니다. 명세를 먼저 쓰고 테스트를 사람이 리뷰하면, 코드가 쏟아지는 속도만큼 빠르게 머지하지는 못합니다. 단기 처리량을 일부 포기하는 대신, 버그를 프로덕션 너머로 흘려보내지 않는 안전을 얻습니다. 앞서 스탠퍼드 연구가 던진 단서도 같은 방향입니다. AI를 덜 신뢰하고 프롬프트와 결과를 더 깊이 따져본 참가자일수록 더 안전한 코드를 작성했습니다. 검증은 도구가 아니라 태도의 문제이기도 합니다.
결론
AI가 코드를 더 많이 쓸수록, 사람의 일은 “쓰기”에서 “무엇이 맞는지 정의하고 그것을 끝까지 지키는 일”로 옮겨갑니다. 테스트 커버리지 숫자는 그 책임을 대신 져주지 않습니다. 그것은 코드가 실행됐다는 알리바이일 뿐, 옳다는 증거가 아니기 때문입니다. 흥미롭게도 채용 면접이 먼저 이 방향으로 움직였습니다. AI가 짠 코드를 읽고 버그를 짚어내게 하는 코드 리뷰 라운드가 등장한 것도, 이제 사람의 값어치가 작성이 아니라 검증에 있다는 신호입니다.
그래서 “AI가 짠 코드는 누가 테스트하는가”라는 질문의 답은 단순합니다. 여전히 사람입니다. 다만 키보드 앞이 아니라, 무엇이 옳은 동작인가를 정의하는 자리에서입니다. AI는 우리가 명세를 더 또렷하게 적어야 하는 시대를 데려왔습니다. 검증을 게을리할 자유가 아니라요. 여러분의 팀에서 AI가 만든 코드가 통과한 그 초록불은, 무엇을 증명하고 있습니까?
참고 자료
- METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (2025), arXiv:2507.09089
- GitClear, “AI Copilot Code Quality: 2025 Research” (2025) — 2020~2024년 코드 변경 2억 1100만 줄 분석
- Neil Perry, Megha Srivastava, Deepak Kumar, Dan Boneh, “Do Users Write More Insecure Code with AI Assistants?”, ACM CCS (2023)
- Fred Brooks, “No Silver Bullet — Essence and Accident in Software Engineering” (1986)
- Edsger W. Dijkstra, “Notes on Structured Programming” (1970)
- Martin Fowler, “TestCoverage” (martinfowler.com, 2012)
