AI 코딩으로 코드는 늘었는데, 확인은 오히려 줄었습니다

AI 코딩 도구를 쓰면 만드는 속도는 확실히 오릅니다. 그런데 만든 것을 확인하는 일은 같이 빨라지지 않습니다. 개발자 22,000명을 2년간 관찰한 자료를 보면, 확인은 느려진 정도가 아니라 건너뛰어지기 시작했습니다. 이 글은 그 격차가 어디서 생기는지, 그리고 지금 쓰이는 확인 방법 3가지가 각각 어디서 막히는지 짚습니다.

AI 코딩으로 늘어난 것과 무너진 것

엔지니어링 분석 회사 Faros AI가 2026년 4월 12일 공개한 AI 엔지니어링 리포트 2026은 개발자 22,000명, 팀 4,000곳의 2년치 기록을 같은 조직 안에서 AI 사용이 가장 적었던 시기와 가장 많았던 시기로 나누어 비교했습니다.

먼저 좋아진 쪽입니다.

• 처리한 작업 +33.7%
• 완료한 기획 단위 +66%
• 코드 묶음이 합쳐진 비율 +16.2%

AI 코딩이 만드는 속도를 올린다는 것은 숫자로 확인됩니다. 문제는 같은 기간, 같은 조직에서 다른 쪽이 이렇게 움직였다는 점입니다.

• 코드를 확인하는 시간(중앙값) +441.5%
• 확인 없이 그대로 합쳐진 코드 묶음 +31.3%
• 코드 묶음 하나당 장애 발생 비율 +242.7%
• 개발자 1인당 오류 +54%

같은 조직에서 만드는 속도는 오르고 확인은 무너졌습니다

숫자 하나만 다시 보겠습니다. 확인 없이 그대로 합쳐진 코드가 31.3% 늘었습니다.

이것이 이 글에서 가장 중요한 대목입니다. 흔히 "AI 때문에 확인이 병목이 되었다"고 말합니다. 그런데 자료가 보여 주는 것은 병목이 아닙니다. 병목이었다면 코드가 확인을 기다리며 쌓였을 것입니다. 실제로 일어난 일은 확인을 하지 않고 내보내는 쪽으로 기울었다 는 것입니다.

확인이 시작되려면 먼저 있어야 하는 것

왜 만드는 일만 빨라지고 확인은 같이 빨라지지 않을까요.

코드를 쓰는 일과 확인하는 일은 필요한 재료가 다릅니다. 코드를 쓰는 데는 "무엇을 만들지"만 있으면 됩니다. AI 코딩 도구가 잘하는 부분이 정확히 여기입니다. 그런데 확인에는 하나가 더 필요합니다. 무엇이 맞는 상태인지에 대한 기준입니다.

• 결제 화면에서 3만 원 미만이면 안내 창이 떠야 하는가, 뜨지 않아야 하는가
• 만료된 회원은 막아야 하는가, 연장 화면으로 보내야 하는가
• 첫 화면에 이 항목이 보여야 하는가, 로그인 뒤에만 보여야 하는가

이 답은 코드 안에 없습니다. 코드에는 지금 그렇게 되어 있다는 사실만 적혀 있을 뿐이고, 그것이 의도한 대로인지 아닌지는 적혀 있지 않습니다. 사람이 정해 둔 규칙이거나, 아직 아무 데도 적혀 있지 않고 만든 사람 머릿속에만 있는 경우가 대부분입니다.

확인에는 무엇이 맞는 상태인가라는 기준이 하나 더 필요합니다

그래서 AI 코딩 도구가 아무리 좋아져도 확인이 자동으로 따라오지 않습니다. 도구가 못해서가 아니라, 기준이 도구 바깥에 있기 때문입니다.

AI 코딩 결과를 확인하는 3가지 방법

그렇다면 지금 사람들은 어떻게 확인하고 있을까요. 크게 3가지입니다.

1. 직접 눌러 봅니다

가장 정확합니다. 사람이 화면을 보고 판단하니 기준이 머릿속에 이미 있습니다. 문제는 시간입니다. 고치는 데 3분 걸린 것을 확인하는 데 30분이 듭니다. 그리고 배포할 때마다 처음부터 다시 해야 합니다. 앞의 자료에서 확인 없이 나가는 코드가 늘어난 이유가 여기 있습니다. 사람이 게을러진 것이 아니라, 사람 속도로는 따라갈 수 없는 양이 들어온 것입니다.

2. AI에게 확인까지 맡깁니다

가장 자연스러운 선택입니다. 코드를 AI가 썼으니 확인도 AI가 하면 될 것 같습니다. 이 문제는 AI에게 테스트를 맡겼을 때 생기는 일에서 더 자세히 다뤘습니다. 여기서 앞서 말한 기준 문제가 그대로 돌아옵니다. AI는 코드를 읽고 "지금 이렇게 되어 있다"를 확인할 수는 있지만, "이렇게 되는 것이 맞다"는 판단의 근거를 갖고 있지 않습니다. 그래서 통과했다는 결과가 나와도 그 통과가 무엇을 뜻하는지 알기 어렵습니다.

이어서 읽기AI에게 테스트를 맡겼는데, 왜 오류가 났을까요?AI 테스트노코드 테스트6분

3. 테스트 코드를 만듭니다

가장 확실한 방법이고, 개발자라면 이 길로 가는 것이 맞습니다. Playwright 같은 도구는 실제 브라우저를 열어 사람이 하던 조작을 그대로 재현합니다. AI에게 그 코드를 만들게 할 수도 있어서, 예전보다 시작하는 부담이 크게 줄었습니다.

이어서 읽기Playwright MCP란? 강점 7가지와 상황별 선택 3가지playwright mcpplaywright9분

다만 두 가지가 남습니다. 첫째, 코드를 읽고 고칠 수 있어야 합니다. 화면이 바뀌면 테스트도 손봐야 하는데 그 일이 계속 돌아옵니다. 둘째, 여기서도 무엇을 확인할지는 사람이 정해야 합니다. 도구는 정해 준 것만 확인합니다.

직접 눌러보기·AI에게 맡기기·테스트 코드 3가지 모두 같은 자리에서 막힙니다

3가지 모두 같은 자리에서 막힙니다. 무엇을 확인할지 정하는 일입니다. 사람이 직접 하면 시간이 들고, AI에게 맡기면 기준이 없고, 테스트 코드로 옮기면 그 코드를 유지할 사람이 필요합니다.

그래서 무엇이 남는가

이 문제를 한 편으로 정리할 수는 없다고 봅니다. 그래서 이어지는 글에서 하나씩 다루려고 합니다.

• 무엇을 확인할지 정하는 일은 왜 사람 몫인가 — 기준을 세우는 일과 실행하는 일을 나누면 무엇이 달라지는지
• 어제는 되고 오늘은 안 되는 확인 — 같은 코드인데 결과가 흔들리면 그 확인은 신뢰를 잃습니다
• 오류가 났을 때 무엇이 남아야 하나 — 실패했다는 사실만으로는 아무도 고칠 수 없습니다
• 우리 확인이 진짜 잡는지 우리는 어떻게 아는가 — 통과율은 방어력이 아닙니다

우리는 이 문제를 이렇게 봅니다

Specnote를 만들면서 저희가 내린 결론은 하나입니다. 기준을 정하는 일과 확인을 실행하는 일을 나누면 된다는 것입니다.

무엇을 확인할지는 사람이 정합니다. 이 판단은 옮길 수 없습니다. 대신 정해진 것을 실제 브라우저에서 반복해 확인하는 일은 사람이 할 이유가 없습니다. Specnote는 AI가 무엇을 만들었는지 목록으로 정리해 보여 주고, 사람이 그 목록을 확인해 승인하면, 승인된 범위만 실제 브라우저에서 확인합니다. 코드를 읽지 못해도 됩니다. 목록을 읽고 판단하는 일은 만든 사람이 이미 할 수 있는 일이기 때문입니다.

이 방식이 모든 경우에 맞지는 않습니다. 코드를 읽고 고칠 수 있다면 테스트 코드를 직접 만드는 편이 더 정밀합니다. 저희가 겨냥한 자리는 그 일을 할 시간이나 사람이 없는 쪽입니다.

---

이 글에 인용한 수치는 Faros AI가 2026년 4월 12일 공개한 AI 엔지니어링 리포트 2026에서 가져왔습니다. 개발자 22,000명, 팀 4,000곳의 2년치 기록을 조직별로 AI 사용이 가장 적었던 시기와 가장 많았던 시기로 나누어 비교한 자료입니다.