AI 에이전트 - AI 코딩 에이전트의 품질을 높이기 위한 실무적 제안

https://addyo.substack.com/p/agentic-verification

2026.10.14
[Agentic Verification]

 

 

 

 

 

 

 

 

핵심 주제: AI 코딩의 병목은 ‘코드를 작성하는 능력’에서 ‘작성한 코드가 올바른지 판별하는 능력’으로 이동하고 있다.[1]

이 글은 실험 논문이 아니라 AI 코딩 에이전트의 품질을 높이기 위한 실무적 제안입니다. 본문 전체를 확인했으며, 아래는 원문의 도입부와 실제 소제목 순서를 따릅니다. 저자의 주장과 분석·권고를 구분하여 설명합니다.

 

1. 도입부 — 좋은 모델보다 중요한 것은 검증 수단

핵심 내용

저자는 AI 에이전트에 자신의 작업을 독립적으로 검증할 수 있는 수단을 제공하면 결과물의 품질을 크게 높일 수 있다고 주장합니다. 테스트·벤치마크·명세·실제 E2E 실행을 에이전트의 작업 과정에 포함하고, 인간은 모든 코드 줄을 읽기보다 에이전트가 반복 실행할 검증 루프를 설계해야 한다는 관점입니다.[1]

여기에 두 가지 원칙을 덧붙입니다.

• 에이전트가 틀린 사항은 공유 설정·훅·테스트에 기록하여 재발을 방지한다.
• 최종 배포의 책임은 인간에게 남으며, 인간은 변경사항뿐 아니라 검증 증거를 검토한다.[1]

분석

이 글에서 말하는 Agentic Verification은 에이전트가 자신에게 “이 코드가 맞는가?”라고 질문하는 자기평가와 다릅니다.

핵심은 다음 구조입니다.

코드 변경 → 실행 가능한 검사 → 실패 증거 확인 → 수정 → 재검사

즉, 에이전트의 확신이 아니라 실행 결과를 피드백으로 사용하는 방식입니다. 여기서 ‘독립적’이라는 표현도 별도 조직의 독립 감리를 뜻하기보다는, 코드 생성자의 설명과 구분되는 테스트·실행 환경의 판정 수단으로 읽는 것이 적절합니다.

한계와 실무 시사점

[확인 필요] “품질이 크게 개선된다”는 주장을 뒷받침하는 비교 실험, 표본 수, 결함 감소율은 본문에 제시되지 않습니다.

실무 권고: AI 개발 도입의 성숙도를 모델 성능만으로 평가하지 말고, 다음을 함께 확인해야 합니다.

• 에이전트가 실제 실행 환경에 접근할 수 있는가?
• 합격 기준이 코드 변경 전에 정의되어 있는가?
• 실패 원인을 재현 가능한 증거로 전달하는가?
• 발견된 오류가 회귀 테스트로 축적되는가?

 

2. 「Verification is the bottleneck」 — 검증이 병목이다

핵심 내용

저자는 인간이 중심이 되는 피드백 루프와 에이전트가 검증을 수행하는 루프를 대비합니다.[1]

구분	인간 중심 루프	에이전트 검증 루프
변경 수행	에이전트가 코드 작성	에이전트가 코드 작성
오류 발견	인간이 코드·테스트·앱 확인	에이전트가 검사 실행
피드백 전달	인간이 오류를 설명	실패 출력을 직접 해석
수정 반복	인간의 개입을 기다림	인간 검토 전까지 반복
인간 역할	반복적인 오류 탐지	기준·증거·잔여 위험 검토

저자는 “조금 더 나은 모델보다 훨씬 더 나은 피드백 루프를 선호한다”고 말합니다. 테스트는 버그 탐지와 리팩터링뿐 아니라 에이전트가 시스템 상태를 인식하고 작업 완료를 판단하는 수단이라는 것입니다.[1]

분석

이 장의 중요한 변화는 테스트를 사후 품질검사에서 작업 제어 수단으로 재정의한다는 점입니다.

• 전통적 관점: 구현 이후 테스트로 오류를 찾는다.
• 에이전트 관점: 테스트 결과를 이용하여 다음 행동과 종료 여부를 결정한다.

따라서 테스트의 설계 오류는 검증 단계에만 영향을 주지 않습니다. 에이전트를 잘못된 구현 방향으로 유도하거나, 미완료 상태를 완료로 판단하게 할 수 있습니다.

한계와 실무 시사점

[보완 필요: 본문 「Verification is the bottleneck」] 검사 통과는 검사가 포괄한 조건의 충족이지, 요구사항 전체의 충족을 보장하지 않습니다.

예를 들어 기능 테스트가 통과해도 접근권한, 개인정보 처리, 장애 복구, 성능 요구는 누락될 수 있습니다.

실무 권고: ‘완료’를 단일 테스트 성공이 아니라 다음처럼 분리하십시오.

기능 검증 통과 + 필요한 비기능 검증 통과 + 미해결 위험 공개 + 승인권자의 판단

 

3. 「There’s a whole spectrum of tests」 — 목적에 따라 검증 수단을 조합한다

이 장은 E2E 테스트, 속성 기반 테스트, 차등 테스트를 설명합니다. 서로 대체하기보다 각각 다른 종류의 오류를 찾아내는 수단으로 이해하는 것이 적절합니다.[1]

3.1. 「E2E tests」 — 실제 사용자 흐름을 검증한다

핵심 내용

저자는 하나의 테스트 유형만 선택해야 한다면 E2E 테스트를 선택하겠다고 말합니다. 회원가입, 장바구니 추가, 결제, 확인 화면과 같이 실제 사용자가 수행하는 흐름을 검증하기 때문입니다.[1]

특히 목 기반 단위 테스트에서는 에이전트의 구현과 테스트가 같은 오해를 공유하여 함께 통과할 수 있다고 지적합니다. 반면 E2E는 사용자에게 보이는 전체 동작을 확인하는 판정 기준, 즉 oracle로 제안됩니다.[1]

좋은 E2E 테스트의 조건도 제시합니다.

• 중요한 사용자 흐름에 집중한다.
• 스크린샷·트레이스·실패 단계로 원인을 설명한다.
• 로컬 환경과 배포 환경에서 사용할 수 있다.
• “기능을 구현하라”를 “이 사용자 흐름을 통과시켜라”로 구체화한다.[1]

추가로, 실행 중인 앱을 조작·관찰하는 유지관리된 스킬이나 CLI와 feature map을 권고합니다. Feature map은 기능 목록뿐 아니라 사용자 진입 경로, 단축키·선택자, 기대 결과, 주의사항을 담는 사용자 관점의 안내도입니다.[1]

분석

핵심은 테스트 파일을 제공하는 것만으로는 부족하다는 점입니다.

에이전트에는 다음이 함께 필요합니다.

앱 실행 방법 + 조작 방법 + 관찰 방법 + 기대 결과

이 구성이 있어야 에이전트가 코드 수준의 추정에서 벗어나 실제 동작을 확인할 수 있습니다.

한계와 실무 시사점

저자도 E2E가 단위 테스트보다 느리고 불안정할 수 있으므로, 소수의 고가치 흐름을 선별해야 한다고 인정합니다.[1]

[보완 필요: 본문 「E2E tests」] “사용자 화면이 성공하면 전체 시스템이 올바르다”는 해석은 피해야 합니다. 화면의 성공 메시지와 실제 DB 저장·외부 연계·후속 처리의 성공은 다를 수 있습니다.

실무 권고: 중요한 업무에서는 E2E의 완료 조건을 다음까지 확장하십시오.

• 화면에서 완료가 표시되는가?
• API 응답이 기대 조건을 만족하는가?
• 실제 데이터가 정확하게 저장되었는가?
• 외부 연계와 후속 처리가 완료되었는가?

 

3.2. 「Property-tests: constraints that can’t break」 — 예시보다 불변조건을 검증한다

핵심 내용

예시 기반 테스트는 “이 입력이면 이 결과”를 확인합니다. 속성 기반 테스트는 여러 입력에 걸쳐 성립해야 하는 규칙을 정의하고, 도구가 많은 입력을 생성하여 반례를 찾습니다.[1]

본문의 대표 속성은 다음과 같습니다.

속성	원문의 예시	검증하는 대상
왕복 일치	인코딩 후 디코딩하면 원래 값과 같음	정보 보존
불변조건	정렬 후 원소 수와 내용이 유지됨	구조·내용 보존
멱등성	같은 정규화·재시도를 반복해도 효과가 같음	중복 처리 방지
동등성	최적화 함수가 기준 함수와 같은 결과를 냄	구현 간 의미 일치

저자는 JS/TS의 fast-check, Python의 Hypothesis, Rust의 proptest를 예로 들며, 실패 입력을 작은 반례로 축소하는 기능을 설명합니다.[1]

또한 에이전트가 자신이 만든 코드에 유리한 예시만 작성할 수 있으므로, 생성기가 만드는 입력에 대해서도 규칙을 지키게 하는 것이 중요하다고 봅니다.[1]

분석

이 장은 검증 범위를 ‘알고 있는 사례’에서 요구사항의 구조적 조건으로 확장합니다.

사용자의 데이터 정제·품질관리 업무에 적용하면, 아래는 분석자가 제안하는 속성 예시입니다.

• 정제 함수를 다시 적용해도 결과가 변하지 않는다.
• 필수 식별자가 정제·변환 과정에서 유실되지 않는다.
• 입력 건수와 정상 처리·제외·실패 건수가 정합하다.
• 허용되지 않은 코드값이 최종 데이터에 남지 않는다.
• 레코드 순서를 바꿔도 업무적으로 동일한 결과가 나온다.

한계와 실무 시사점

[보완 필요: 본문 「Property-tests」] 많은 생성 입력을 통과했다는 사실은 모든 입력에 대한 수학적 증명이 아닙니다. 보장 범위는 정의한 속성과 입력 생성 범위에 제한됩니다.

본문은 Lean·TLA+를 활용한 모델링도 언급하지만, 이를 속성 기반 테스트와 동일한 검증 수준으로 보아서는 안 됩니다.[1]

실무 권고: 순수 함수부터 시작하고, 속성을 자연어로 먼저 정의하며, 발견된 최소 반례를 회귀 테스트로 보존하십시오. 이는 원문의 도입 권고와도 일치합니다.[1]

 

3.3. 「Differential tests: the old system is the oracle」 — 기존 시스템과 비교한다

핵심 내용

재작성·마이그레이션에서는 새 테스트를 통과하더라도 기존 시스템의 작고 문서화되지 않은 동작과 달라질 수 있습니다. 저자는 같은 입력을 기존 시스템과 신규 시스템에 넣고 결과를 비교하는 차등 테스트를 권고합니다.[1]

입력은 무작위 생성, 실제 트래픽 표본 재생, 또는 둘의 조합으로 구성합니다. 결과 불일치는 신규 오류이거나 의도적인 변경이므로 구분하여 처리해야 합니다.[1]

실무상 주의사항은 다음과 같습니다.

• 의미 없는 차이와 의미 없는 순서는 정규화한다.
• 의도한 변경은 이유를 포함한 승인 목록으로 관리한다.
• 비교 결과를 이용하여 마이그레이션을 반복 개선한다.[1]

분석

차등 테스트의 가치는 문서에 없는 실제 동작을 포착하는 데 있습니다.

특히 레거시 전환에서는 공식 명세만으로 기존 사용자들이 의존하는 예외 동작을 완전히 설명하기 어렵습니다. 기존 시스템을 비교 기준으로 삼으면 그 동작을 하나씩 새로 명세화하지 않고도 차이를 발견할 수 있습니다.

다만 다음 두 질문은 분리해야 합니다.

“기존 시스템과 같은가?”와 “업무적으로 올바른가?”는 다른 질문이다.

한계와 실무 시사점

[보완 필요: 본문 「Differential tests」] 기존 시스템에도 오류가 있을 수 있습니다. 무조건적인 일치 요구는 기존 결함을 신규 시스템에 복제할 위험이 있습니다.

또한 정규화를 과도하게 적용하면 실제 의미 차이가 사라질 수 있습니다. 예를 들어 적용일자·금액·권한 차이를 단순 비교 노이즈로 제거해서는 안 됩니다.

실무 권고: 불일치를 다음과 같이 분류하십시오.

분류	처리 방향
신규 시스템 결함	수정 후 재검증
기존 시스템 결함	업무 근거와 승인에 따라 개선
승인된 기능 변경	변경 근거와 기대 결과를 명세화
비교 환경·정규화 오류	검증 하네스 수정
원인 미확정	확인 필요 상태로 유지

 

4. 「Make the loop fast and deterministic」 — 빠르고 결정적인 검증 루프

핵심 내용

저자는 느리거나 불안정한 테스트가 에이전트에 잘못된 행동 유인을 준다고 주장합니다.[1]

• 간헐적으로 실패하는 테스트는 수정 대신 재실행을 유도한다.
• 오래 걸리는 테스트는 검사 빈도를 낮추고 변경을 크게 묶게 한다.
• 변경을 크게 묶으면 어떤 수정이 실패를 유발했는지 파악하기 어렵다.[1]

따라서 다음과 같은 검증 환경을 제안합니다.

• 핵심 루프는 매 반복에 실행할 만큼 빠르게 만든다.
• 난수 시드·시간·네트워크·상태를 통제한다.
• 불안정한 테스트를 주 검증 경로에서 격리한다.
• 성공 로그보다 구체적인 실패 정보를 제공한다.
• 빠른 검사와 통합 전의 무거운 E2E·차등 검사를 분리한다.[1]

추가로 성공 기준 재확인, 새 컨텍스트나 별도 리뷰 에이전트 활용, 생성된 테스트 자체의 검토도 권고합니다.[1]

분석

이 장의 본질은 속도 최적화보다 피드백의 신뢰성입니다.

검증 결과를 믿을 수 없다면 에이전트는 다음을 구별하기 어렵습니다.

코드가 잘못된 것인가, 검증 환경이 불안정한 것인가?

본문의 ‘학습’ 표현은 문맥상 반복 작업에서 형성되는 행동 전략과 유인을 뜻하는 것으로 읽어야 합니다. 테스트 재실행이 실제로 모델 가중치를 갱신한다는 구현 설명은 없습니다.

한계와 실무 시사점

[확인 필요] “느린 테스트가 에이전트의 품질을 낮춘다”는 메커니즘은 설득력 있는 실무 가설이지만, 본문에는 이를 정량적으로 검증한 실험이 없습니다.

[보완 필요] 고정된 시드는 재현성에는 유리하지만 입력 다양성을 제한할 수 있습니다. 또한 불안정 테스트를 격리하면서 해당 기능의 검증 공백을 방치해서는 안 됩니다.

실무 권고 — 분석자 제안:

검증 단계	주요 목적	구성 예시
빠른 내부 루프	수정 직후 오류 탐지	타입·단위·핵심 속성 검사
변경 통합 전	전체 흐름과 호환성 확인	E2E·통합·차등 검사
별도 확장 검증	드문 오류와 비기능 위험 탐지	다양한 시드·부하·보안·장애 검사

원문의 ‘subsecond’는 핵심 루프에 대한 바람직한 목표이지, 모든 테스트에 적용되는 의무 기준은 아닙니다.[1]

 

5. 「Write the check before the code」 — 코드보다 성공 기준을 먼저 정의한다

핵심 내용

마지막 장은 앞선 논의를 하나의 원칙으로 묶습니다.

에이전트에게 구현을 요청하기 전에, 무엇을 충족하면 성공인지 알아야 한다. 그 기준은 사용자 흐름, 속성, 기존 시스템과의 비교 등으로 표현할 수 있습니다.[1]

저자는 인간의 역할을 모든 출력 줄을 읽는 것에서 성공의 정의를 제공하는 것으로 이동시킵니다. 또한 무엇이 일어나야 하는지 보여주는 예시와, 무엇이 일어나면 안 되는지 정의하는 속성을 함께 요구합니다.[1]

분석

이는 단순히 “테스트를 먼저 작성하라”는 개발 순서의 문제가 아닙니다. 더 넓게 보면 요구사항을 실행 가능한 합격 기준으로 바꾸라는 주장입니다.

예를 들어:

추상적 요구	실행 가능한 검증 기준 — 분석자 예시
중복 전송을 방지한다	동일 요청을 반복해도 업무 레코드가 추가 생성되지 않음
정제 과정에서 데이터를 보존한다	정상·제외·실패 건수와 입력 건수가 정합함
기존 기능을 유지한다	승인된 변경을 제외한 비교 결과가 일치함
업무 처리를 완료한다	사용자 화면뿐 아니라 저장·연계 결과까지 확인됨

한계와 실무 시사점

[보완 필요: 본문 「Write the check before the code」] 모든 요구가 자동 검사로 완전히 표현되지는 않습니다. 법적 적정성, 정책 해석, 사용자 경험, 운영 책임 같은 항목은 별도의 전문 판단이 필요할 수 있습니다.

또한 에이전트가 구현과 테스트를 모두 수정할 수 있다면, 구현을 고치는 대신 테스트를 느슨하게 만들어 통과시키는 위험도 관리해야 합니다.

실무 권고: 합격 기준의 변경은 구현 변경과 구분하여 승인하고, 테스트 변경 이력·기대 결과의 근거·독립 검토를 유지하십시오.

 

6. 종합 평가 — 실행 가능한 검증과 그 증거를 중심으로 품질을 관리하라

이 글의 기여

이 글의 중요한 기여는 새로운 테스트 기법의 제안보다, 기존 검증 수단을 에이전트의 작업 수행 루프에 통합한다는 데 있습니다.

• E2E는 실제 사용자 흐름을 확인합니다.
• 속성 기반 테스트는 일반적 불변조건을 확인합니다.
• 차등 테스트는 기존 동작과의 호환성을 확인합니다.
• 빠르고 결정적인 하네스는 수정과 검증의 반복을 지원합니다.
• 인간은 성공 기준, 예외, 배포 판단을 책임집니다.[1]

 

결론적으로, 이 글은 “AI가 검증하면 인간 검토가 필요 없다”는 주장이 아닙니다. 인간의 판단을 반복적인 오류 탐지에서 검증 기준의 적정성, 증거의 신뢰성, 잔여 위험과 배포 책임으로 이동시키자는 제안입니다.

이를 실무 원칙으로 정리하면 다음과 같습니다.

검증 기준을 먼저 정의하고, 에이전트가 실제로 실행하게 하며, 통과했다는 설명이 아니라 실행 증거를 검토한다. 다만 그 증거가 보장하는 범위를 넘어서 품질을 주장하지 않는다.

Sources

[1] https://addyo.substack.com/p/agentic-verification — Addy Osmani — Agentic Verification