AI 시대의 개발자는 검증을 설계한다 (1)

AI가 뚝딱 코드를 짜주는 시대입니다.

하지만 자세히 보면 불필요합니다. 오래 보면 이상합니다. AI가 짠 코드가 그렇습니다.

자연스럽게 이런 생각이 듭니다. 검사도 AI가 해주면 안 되나?

AI한테 E2E 테스트를 짜라고 맡겨 봤습니다. 커피 주문 앱에서 메뉴를 눌러 상세로 진입하는 코드를 줘봤습니다. 한참 코드를 만지던 AI는 결국 돌아가는 테스트를 내놓았습니다.

결과는 정말 구렸습니다.

실패가 떴지만 문제가 없는 코드였고, 멀쩡한 코드인데도 계속 실패가 떴습니다. 정말 제대로 검증을 하는 테스트인가 싶어서 일부러 버그를 내보았습니다. 메뉴 이름을 “아메리카노aaa”로 바꿔봅니다. 통과하네요. 아메리카노aaa는 당연히 버그인데 말이죠.

결국 AI가 해준 검증은 믿을 수가 없었습니다. 제가 뭘 놓친 걸까요?

코딩은 빨라졌는데, 개발은 안 빨라졌다

AI 덕분에 코드 작성은 엄청나게 빨라졌습니다. 다들 이미 코딩은 다 해결됐다. 실행이 싸졌다. 이제 일은 AI가 할 것이다. 이제는 뭘 만들지 안목이 중요하다. 취향이 중요하다. 이런 말들이 나옵니다.

하지만 소프트웨어 제품 개발이 진짜 빨라졌을까요?

아직 아닙니다. 소프트웨어 개발은 아직 비쌉니다.

이유는 간단합니다. 코드 작성은 빨라졌지만, 검증하고 배포하는 속도는 안 빨라졌습니다.

DORA 리포트라는 유명한 보고서가 있습니다. 엔지니어의 생산성과 관련된 통계와 데이터를 다루는데요. 2025년 리포트에 이런 말이 나왔습니다.

검증세 (Verification Tax).

작업을 시작하고 코드를 쓰는 건 빨라졌지만, 거기서 아낀 시간이 다 검증 세금으로 부과된다는 겁니다.

그래도 코드 작성에서 번 시간이 세금보다 크면 되는 거 아니냐? 그렇게 단순하지도 않은 것 같습니다.

소프트웨어 개발은 복잡한 팀 플레이입니다. 작업이 서로서로 의존하고 있죠. 아무리 코드 작성이 빨라져도, 검증이 병목이면 전체 배포 산출량은 그 병목의 속도에 맞출 수밖에 없습니다.

Faros AI가 2025년에 개발자 1만 명, 1,255개 팀의 실제 작업 데이터를 들여다본 리포트가 있습니다. AI를 많이 쓰는 팀은 완료한 작업이 21% 늘었고, 머지한 PR은 98% 늘었습니다. 코드는 확실히 더 많이 나왔습니다.

그런데 같은 팀에서 PR 리뷰 시간은 91% 늘었습니다. 개발자 1인당 버그 9% 증가했고, 평균 PR 크기 154% 증가했습니다. 병목이 리뷰로 옮겨간 겁니다.

AI가 똑똑해져도 개발자가 남는 이유

AI 모델이 더 똑똑해지면 자연스럽게 해결될 문제 아닐까요? 저는 그렇게 생각하지 않습니다.

LLM이 나날이 발전을 해도, 여전히 약간의 실수를 할 겁니다. 제가 시킨 작업 세션 하나에 우리는 수십개의 턴을 거치고, 각 턴의 프롬프트 하나당 LLM은 또 수십 개의 의사결정을 해야합니다. LLM은 확률적입니다. 어딘가에서는 헛발질을 하고, 고장을 내고, 의도를 잘못 이해하겠죠.

마치 동전탑 같습니다. 동전을 하나씩 쌓아올릴 때, 아주 살짝만 어긋나도 계속 쌓다보면 동전탑은 기울어집니다. 결국 무너지고 말죠.

소프트웨어도 마찬가지입니다. 어긋남이 아주 조금씩만 반복되어도 유지보수 불가능한 코드로 무너집니다. 잠깐 쓰고 말 데모 정도는 만들 수 있겠지만, 오래 운영할 소프트웨어는 수천, 수만 개의 턴이 누적되어 진화합니다.

현업 개발자들은 아직도 매턴 마다 AI가 무슨 짓을 했는지, 어디서 어긋났는지 유심히 보고 넘어갑니다. AI가 점점 더 세련된 결과물을 내놓더라도, 개발자가 혹시나 있을 실수를 찾아내기 위해 들어가는 시간은 많이 줄지 않습니다. (버그가 쌓이면 에이전트가 알아서 고쳐주는 시스템을 만들었다. 그런데.. 2주 만에 꺼버렸다.)

‘이제 다 코딩은 AI가 한다던데 개발자 다 없어지는 거 아니야?’ 라는 흔한 생각에도 불구하고, 아직도 개발자가 직업을 유지하는 이유죠.

앞으로도 검증은 AI 코딩, 에이전틱 코딩이 만드는 생산성의 상한을 결정할 겁니다.

그런데 반대로 보면 어떨까요? 상한을 결정한다는 말은, 뒤집으면 지렛대라는 뜻이기도 합니다.

코드 작성 속도는 이미 병목에 막혀있습니다. 검증은 아직 아무도 제대로 풀지 못한 병목입니다.

남들이 다 코드 생성에 집중할 때, 이 병목을 조금만 들어올릴 수 있다면 어떨까요?

루프 안에 있는 사람, 루프 밖에 있는 사람

이 병목을 들어올린다는 게 구체적으로 무슨 그림일까요? 요즘 AI 쪽 얘기를 듣다보면 ‘루프’라는 단어를 들어보셨을 거예요.

프롬프트를 치고, 코딩된 걸 확인하고, 다시 다음 프롬트를 입력합니다. 이 때 우리는 에이전틱 코딩의 루프 ‘안’에 있습니다.

AI가 알아서 코딩하고 검증하고 루프를 돌린다면 어떨까요? 우리는 루프 ‘밖’에 있습니다. 멋진 이야기죠.

요즘 AI 프론티어, AI 구루들은 다 이 ‘루프 바깥’을 이야기합니다.

다들 들어보셨을 ‘랄프톤’은, 얼마나 루프 바깥에 있느냐를 겨루는 대회입니다.

밤새 미친듯이 자동으로 돌면서 ML 모델의 성능을 개선했다는 안드레이 카파시의 오토 리서치를 들어보셨나요? 카파시가 ‘val_bpb’ 지표에 검증을 맡기고 루프 바깥에 있어서 가능했습니다.

요즘 유행 키워드로 떠오른 ‘루프 엔지니어링’은 프롬프트를 직접 치지 말라고 합니다. 더 나아가서 ‘소프트웨어 다크 팩토리를 구현했다’라는 공상과학 같은 얘기도 실리콘 밸리에서는 자주 들리죠.

저는 루프 바깥의 사람이 아직 ‘현실’은 아니라고 생각해요. 하지만 ‘지향점’은 맞다고 생각합니다. 소프트웨어 개발이 정말로 AI 덕분에 싸고 빨라진다면, 우리는 고객한테 가치를 전달하는 일에 더 집중할 수 있을 테니까요.

루프 밖으로 나아가는 첫 관문은 ‘검증 시스템’이다

루프 바깥으로 나아가기 위한 첫 관문은 ‘검증’입니다. (왜 어떤 개발자는 AI를 한번에 몇 시간씩 돌리고, 나는 5분이면 끝날까?)

우리는 더 효율적인 ‘검증 시스템’이 필요합니다.

바꿔 말하자면 저는 이제 개발자가 ‘검증 시스템’을 만드는 사람이 되어야 한다고 생각합니다.

‘자동화된 검증은 어려우니까 다 내가 해야지’가 아니라, 어떤 도구, 설계, 기법을 써서 내 판단력을 기계에게 위임하고, 더 신뢰할 수 있는 검증 시스템을 만들 수 있을지를 고민한다는 거죠.

어떻게 하면 신뢰할 수 있는 검증 시스템을 만들 수 있을까요?

처참한 실패와 의외의 성공에서 얻은 힌트

서두에 커피 주문 앱의 E2E 테스트 실패담을 얘기했는데요. 몇달 전부터 ‘역시 검증이 중요해’라는 생각을 하다가, 한번 뭐라도 해보자 하고, 시도해본 거였습니다. 그리고 바로 처참히 실패해버렸죠.

굳이 저 E2E 에피소드를 꺼낸 이유는 첫째는 저도 이런 말을 하지만 아직 허접이다, 라는 말을 하고 싶었고, 둘째는 검증 시스템을 잘 만드는 게 정말 쉽지 않다는 걸 깨달은 계기였기 때문입니다.

LLM에는 결정적인 검증 기계가 필요하니까, E2E 테스트를 많이 짜보자. 라는 간단한 아이디어였습니다. E2E 테스트라는 게 사실 좋은 건 다 알지만 정말 시간과 노력이 많이 들어가잖아요. 근데 AI가 테스트도 짤 수 있잖아? 그러니까 E2E 테스트를 짜는 것을 한번 AI한테 시켜보자. 이런 생각의 흐름이었죠.

그런데 E2E 테스트의 검증이 전혀 신뢰할 수 없는 것을 보고 깨달았습니다. E2E 테스트에 무엇을, 어떻게 짜야할지 인간이 정해주지 않으면 여전히 쌩 LLM이 하는 리뷰와 다름이 없더라고요.

아 어렵다, 그러면 어떻게 해야하지?

그런데 그 실마리를 의외의 곳에서 찾았습니다.

저는 최근 Lint 만들기에 푹 빠졌습니다. ‘Lint는 가장 저평가된 하네스다’ 라는 글도 썼는데요.

저는 Lint에 별 기대를 갖고 시작하지 않았습니다.

제가 개발하는 코드베이스에는 원래부터 저와 동료들이 선호하는 구조, 스타일이 있었는데요. 그 구조와 스타일을 벗어날 때마다 서로 코드 리뷰를 하고 있었습니다. 이 리뷰를 Lint로 강제하면 안되나? 하면서 Lint를 쌓기 시작했습니다.

그런데 20-30개를 넘어가면서 굉장한 차이를 느끼기 시작했습니다. AI가 점점 저처럼 코드를 짜기 시작하는 겁니다. 서로 Lint를 강제해놓으니까 리뷰할 것도 확 줄어들었습니다.

반대로 Lint가 안 설정된 코드베이스에 가면 ‘뭐야 이렇게 개떡같이 짜?’ 하고 역체감이 느껴지기 시작했습니다. 혹시 내가 LLM을 하위 모델로 잘못 설정했나? 생각할 정도였습니다.

> 똑같은 모델, 똑같은 클로드 코드였는데, 왜 E2E 테스트는 하나도 믿을 수가 없고, Lint를 먹인 LLM은 리뷰를 안해도 될까? 그 차이는 뭐였을까?

저는 이 경험에서 검증 시스템에 대한 3가지 정도 힌트를 얻었습니다.

결정적이고 설명 가능해야 한다

LLM으로 검증을 하는 건 최소화해야 합니다.

물론 LLM한테 검증을 시키는 건 아주 유혹적인 방법인데요. 제 E2E 테스트 실험이 그랬듯이, 무작정 AI가 한 결과물을 AI에게 검증해보라고 하면 결국 실패할 수밖에 없습니다. 여전히 그 검증 또한 확률적이니까요. 일반적인 AI 코드 리뷰가 금방 노이즈가 되는 이유도 같은 맥락입니다.

결국, 어딘가는 받쳐야 합니다. 검증 시스템에 LLM이 적을수록 좋습니다. LLM이 많이 들어갈수록 개발자가 원인을 설명하기 어려워지니까요. 설명할 수 없는 건 책임지기도 어렵습니다.

하지만 결정적이고 설명 가능한 검증을 촘촘하게 깔아둔다면, 우리는 검증을 믿고 맡길 수 있습니다. 우리가 결정적으로 만들어진 저수준 시스템(운영체제의 시스템 콜이나 컴파일러의 동작)을 걱정하지 않는 것처럼요.

생성 단계 사이사이에 깊숙이 들어가야 한다

검증 시스템은 LLM의 생성 단계 사이사이에 깊숙이 들어가야 합니다. 그래서 LLM이 한 턴 한 턴 동전을 쌓을 때마다 어긋남을 감지하고 잡아줍니다.

Lint를 쌓고 나서 제가 가장 놀랐던 건 이거였습니다.

원래 제가 코딩을 할 때 Lint는 많으면 귀찮은, 꼭 해야 하나 싶은 거였어요. 하지만 AI한테는 귀찮음이 없습니다. 매턴, 매커밋마다 Lint를 돌리고 바로 고쳐서 수정합니다.

제가 ‘아 그렇게 짜면 안 되는데’ 하고 쳐다보고 있을 때, AI가 Lint를 돌리고 깔끔한 결과물을 내놓는 걸 보는 경험은 정말 짜릿했습니다.

LLM이 많은 어긋남을 만들기 전에 빠르게 잡으면, 실수가 곱하기로 쌓여 커지는 걸 줄일 수 있습니다. 확률적이고 유연한 LLM이 좋은 선택을 할 수밖에 없도록 계속 좁혀주는 피드백 루프가 되어야 합니다.

그러려면 검증 시스템은 로컬에서 빠르게 돌 수 있어야 하겠죠.

판단 기준은 사람이 세운다

검증 시스템이 결정적으로 무엇을 잡아낼지는, 결국 사람이 정해줘야 합니다.

제 Lint가 그랬습니다. ‘웹에서 좋은 Lint 룰 싹 다 긁어서 알아서 넣어봐’라고 시킨 게 아니었어요.

애초에 저와 동료가 만들고 싶은 좋은 구조가 먼저 있었습니다. 그 주관적인 기준을 먼저 세우고, 그걸 Lint라는 결정적인 규칙으로 옮긴 거였죠. 그래서 이 Lint는 남한테 그대로 공유하기도 어렵습니다. 우리의 판단 기준이 녹아 있으니까요.

E2E는 반대였습니다. 원래도 잘 안 짰는데 좋은 E2E 테스트에 대한 기준이 있을 리가요. ‘딸깍’하고 싶어서, 무엇을 검증하고 싶은지 명확히 정의하지도 않았습니다.

아 그 차이구나, 싶었습니다.

판단 기준을 세우는 건 사람의 일입니다. 무엇을 좋은 코드로 볼지, 무엇을 꼭 검증할지는 사람의 판단에서 나옵니다. 기계는 그 판단을 대신 내려주지 않습니다.

대신, 일단 판단 기준이 정해지면 기계는 그걸 결정적이고 빠르게, 지치지 않고 수행합니다. 사람이 매번 눈으로 하던 판단을 기계가 매턴 대신 집행하는 거죠.

그러니까 이 3가지를 요약해보자면

1. 일단 내 판단력으로 기준과 골격을 세우고,

2. 결정적이고 설명 가능한 시스템으로 바꿔서,

3. 빠르고 효율적으로 AI 생성 사이클에 통합시킨다.

그게 좋은 검증 시스템이 아닐까?

그런 힌트를 얻게 된 거죠.

2026년 개발자가 만들 수 있는 가장 큰 경쟁력

당연하게도 검증 시스템은 완벽할 수 없다고 생각합니다. ‘정말 변경하기 쉬운 좋은 코드인가’ ‘요구사항을 제대로 구현했는가’라는 건 다양한 측면을 봐야합니다. 객관적이기도 하면서 또 주관적입니다. 완전히 기계적으로 해결하는 건 불가능하다고 생각해요.

인간은 최후의 보루로 남아야겠죠. 좋은 판단 기준과 검증의 눈을 가진 인간은 여전히 귀할 거예요.

하지만 약간 다르게 생각해보면, 신뢰할 수 있기 위해 꼭 완벽해야하는 건 아닙니다. 적어도 지금보다 나으면 됩니다. 어쩌면 평균적인 개발자 정도만 되어도 됩니다. 개발자가 하는 검증이 그렇게 완전하냐 하면 그것도 아니니까요.

완벽하지 않지만 신뢰할 수 있는 검증 시스템을 잘 만드는 사람도 희소가치가 있을 겁니다. 이건 앞서 말한 것처럼 LLM 딸깍으로 되지 않습니다. 여전히 ‘좋은 판단 기준’이라는 역량이 필요합니다. 다만 그걸 스케일업 하는 일에 가깝죠.

무엇을 검증해야 할지에 대한 판단 기준, 그것을 어떻게 효율적으로 스케일업할 수 있는가. 이 2가지 전문성은 쉽게 따라할 수 없습니다.

그래서 저는 이 부분이 2026년 시점에 개발자가 만들 수 있는 가장 큰 경쟁력이라고 생각합니다.

> AI 코딩을 자신의 기준으로 검증하는 시스템을, 직접 설계하고 개선해본 적이 있는가?

뉴-클래식을 찾아서

검증 시스템이 그래서 뭐냐고요?

> 타입 검사, Lint, 단위 테스트, 통합 테스트, E2E 테스트, 비주얼 테스트…

다 기계적으로 코드의 구조와 기능 결함을 잡아내는 방법들입니다.

사실 새로운 건 하나도 없습니다. 오히려 너무 당연해서 약간 지루하기까지 한 주제죠.

새로운 건 따로 있습니다. AI가 코드를 생성하는 시대에 이 검증 시스템의 중요성이 훨씬 올라갔다는 것. 그리고 이 시스템을 잘 설계하는 일 자체가 만만치 않은 역량이 됐다는 것.

그렇게 생각하자 그동안 별 관심 없던 이 오래된 정답들이 다르게 보이기 시작했습니다.

1. 구조를 검증하는 Lint

2. 기능을 검증하는 Unit/Integration/E2E Test

3. 값을 검증하는 Type check

4. 외형을 검증하는 Visual test

어떻게 하면 이런 오래된 정답들을 AI로 더 많이, 더 효과적으로 작성할 수 있을까?

저는 요즘 이런 고민을 굉장히 많이 하고 있습니다. 뉴-클래식이랄까요.

사실 저도 힌트만 있을 뿐 정답은 없습니다. 하지만 더 나은 검증을 설계하는 것이 중요한 역량이라고 믿습니다.

그래서 ‘AI 시대의 개발자는 검증을 설계한다’라는 시리즈를 시작해봅니다. 앞으로 더듬거리면서 시도하고 실패하는 얘기 적어보도록 하겠습니다.