← AI Engineer
테스트 · TDD

커버리지는 통과해도 기능은 안 본다 — AI 코드에 되살린 레드-그린 TDD

커밋이 한 해 10억 건에서 주 2억 7500만 건으로 늘어난 수치를 들며, 코드량이 는 것과 생산성이 는 것은 다른 문제라는 개발자 12만 명 연구를 소개함. 어느 팀은 PR은 늘었는데 품질이 떨어져 되돌아가 고치느라 실효 증가가 1%에 그쳤다는 사례가 나옴. 덮은 줄만 세는 테스트가 왜 다듬을 때마다 깨지는지, AI가 스스로를 두둔하는 시험을 만드는 문제, 그리고 붉게-푸르게-다듬기 세 걸음의 무게가 어디로 옮겨 가는지를 짚음.

Marlene Mhangami Microsoft발표 2026-05-2619분 30초AI Engineer

한줄 코멘트. 덮은 줄이 다 초록인데 기능은 안 본 상태가 이 발표가 겨누는 자리다. AI에게 시험까지 맡기면 그 위험이 커진다 — 스스로를 두둔하는 시험을 만들기 때문이다. 값나가는 대목은 세 걸음의 무게가 옮겨 간다는 진단이다. 앞의 둘이 빨라진 만큼 사람이 시간을 쏟을 자리는 마지막 칸이 된다.

1. 커밋이 폭증한다

마이크로소프트와 깃허브 양쪽에서 개발자 쪽 일을 한다는 사람이 발표한다.

수부터 놓는다. 2025년에 커밋 10억 건이 올라왔고 그것이 그때까지 가장 많은 해였다. 2026년 들어 그 증가가 더 빨라지고 있는데 공식 집계는 아직 없다고 밝힌다.

대신 며칠 전 임원이 올린 글을 든다. 주마다 2억 7500만 건쯤이 올라온다는 것이다. 그대로 늘려 보면 연말에 140억 건 남짓이 된다.

여기서 하나를 짚는다. 그중 AI가 함께 지은이로 적히는 몫이 늘고 있는데, 어떤 도구는 그 표시를 남기고 어떤 도구는 안 남긴다.

2. 그런데 생산성은 늘었나

물음이 여기서 뒤집힌다. AI가 정말로 개발자를 더 생산적으로 만드나.

인용하는 근거는 개발자 12만 명을 본 연구다. 결론은 그럴 수 있다는 것이되, 어떻게 쓰느냐가 가장 중요하다는 쪽이다.

무엇으로 갈리느냐는 코드베이스가 깨끗한지다. 깨끗한 코드베이스는 AI가 주는 이득을 키우고, 점검 없이 쓰는 AI는 무질서를 키운다.

사례가 붙는다. 어느 회사가 점검 없이 썼더니 내놓는 PR 수는 늘었는데 품질은 떨어졌고, 그 코드를 되돌아가 고치는 데 시간을 더 썼다. 실효로 늘어난 산출은 1%였다.

그래서 권하는 것은 평범하다. 시험 *커버리지, 타입이 얼마나 붙었는지, 문서가 있는지, 부품이 나뉘어 있는지다.

3. 테스트가 왜 짐이 되나

속을 짚은 테스트는 깨진다

테스트를 무엇에 매어 두나

속을 짚는다그 함수 이름에 매인다기능이 그대로여도이름만 바꾸면 깨진다
겉을 짚는다나온 값과 굳은 약속에 매인다안쪽을 갈아엎어도그대로 산다
테스트가 왜 짐이 되는지에 대한 진단이다. 덮은 줄만 세다 보면 속을 짚게 되고, 속을 짚은 테스트는 다듬을 때마다 깨진다.

여기서 발표가 오래된 논쟁을 끌어온다. 2014년에 이 방식은 죽었다고 선언된 적이 있다. 어느 유명한 프레임워크를 만든 사람이 글을 내면서, 낱개 시험에 지나치게 매달리는 것을 짚었다.

문제의 뿌리를 이렇게 짚는다. 덮은 줄만 세다 보면 속을 짚게 된다.

예가 또렷하다. 할인이 붙은 값을 셈하는 자리에서 시험이 그 함수 이름에 바로 매여 있으면, 기능은 그대로인데 이름만 바꿔도 시험이 깨진다.

그래서 겉을 짚으라고 한다. 마지막에 나온 값이나 바깥에 내어 놓은 굳은 약속 같은 것이다. 그러면 안쪽을 갈아엎어도 살아남는다.

AI가 붙으면서 이 문제가 커진다고 말한다. AI가 스스로를 두둔하는 시험을 만들기도 한다는 것이다. 그러면 화면은 온통 초록인데 정작 그 물건이 제대로 도는지는 아무도 안 본 상태가 된다.

4. 붉게, 푸르게, 다듬기

세 걸음의 무게가 옮겨 간다

붉게없는 기능이니 먼저 실패하는 시험을 쓴다
푸르게통과만 시킨다. 품질은 여기서 안 본다
다듬기이제 품질만 본다
앞의 둘이 빨라진 만큼 마지막 칸이 커진다
발표가 든 세 걸음이다.

되살리려는 방식은 세 걸음이다.

먼저 아직 없는 기능이니 실패하는 시험부터 쓴다. 다음 걸음에서는 통과시키는 데만 매달린다 — 이 자리에서는 코드 품질을 안 본다. 마지막에 가서야 품질만 본다.

AI가 붙으면 무엇이 달라지느냐가 이 발표의 답이다. 앞의 두 걸음이 빨라진다. 그러니 사람이 가장 오래 붙어 있을 자리는 마지막 칸이 된다.

5. 붙이는 법과 데모

시험을 브라우저에서 실제 조작처럼 돌리는 도구를 쓴다. 여러 언어를 받고, 화면을 띄우지 않고 뒤에서 돌릴 수도 있다.

코딩 에이전트와 잇는 세 갈래

갈래무엇인가
서버로 붙이기도구 규격에 맞춰 연결한다
명령줄 도구그쪽이 편하면 이것을 쓴다
딸린 역할들계획하는 것·만드는 것·고치는 것 세 몫이 파일로 깔린다

데모는 장난감 회사 개발자 설정이다. 검색과 거르개를 붙여 달라는 메일 요청에서 시작한다. 여기서 짚는 것이 하나 있다. 예전에는 클래스에 함수를 하나 붙이는 것이 시험을 쓰는 계기였는데, 이제는 기능 요청이 그 계기여야 한다는 것이다.

에이전트가 가장 먼저 하는 일은 코드베이스를 훑어보는 것이다. 그다음 실패하는 시험을 쓰고, 통과시키는 코드를 짜고, 돌려 본다. 데모에서는 검색도 거르개도 제대로 돌아 시험이 다 통과했다.

마지막 권고가 실무적이다. 시험 화면을 갈무리해 PR에 붙이고, 화면 없이 돌리고, 에이전트가 고치기 전에 먼저 커밋해 두고, 기능 하나에 시험 하나를 만든다.

6. 발표가 밝히지 않은 것

140억 건은 잰 값이 아니다. 주간 수치를 그대로 늘려 본 어림이고, 공식 집계는 아직 없다고 발표자가 직접 말한다.

1%는 남의 연구에서 든 한 사례다. 어느 회사인지, 무엇을 실효 산출로 셌는지가 없다.

커밋이 늘었다는 것과 AI가 늘렸다는 것이 이어지지 않는다. 함께 지은이로 적히는 몫이 는다고만 하고 그 몫이 얼마인지가 없다. 게다가 표시를 안 남기는 도구가 있다고 스스로 말하므로 그 몫은 셀 수도 없다.

이 방식이 값을 한다는 증거가 없다. 세 걸음을 밟은 팀과 안 밟은 팀을 견준 자리가 없다.

스스로를 두둔하는 시험이 얼마나 나오는지 없다. 그런 일이 있다고만 하고 빈도가 없다.

데모가 성공한 한 판뿐이다. 실패했을 때 무엇을 하는지는 나오지 않는다. 고치는 몫이 딸려 온다고만 말한다.

용어

*커버리지
시험이 코드의 몇 줄을 밟았는지를 세어 놓은 비율