2026 개발 트렌드: AI 에이전트 변경의 품질은 ‘검증 범위 선언’에서 갈린다

AI 코딩 에이전트는 한 요청에서 구현, 리팩터링, 테스트, 문서, 설정 파일을 동시에 바꿀 수 있습니다. 반복 작업은 줄어들지만 review와 CI에는 새 질문이 남습니다. “테스트가 30개 추가됐고 파이프라인이 green인가?”보다 중요한 질문은 **이 diff가 실제로 바꾼 행동은 무엇이고, 그 행동을 어떤 증거가 덮었으며, 무엇은 아직 검증하지 않았는가?**입니다.

문제는 CI가 없어서가 아니라 너무 많은 신호를 하나의 green check로 압축한다는 데 있습니다. 45분짜리 전체 테스트가 통과해도 새 authorization 분기가 mock에만 갇혔을 수 있고, 반대로 README와 fixture만 바꾼 PR이 같은 45분을 기다릴 수 있습니다. agent가 생성량을 늘릴수록 이 둘을 구분하지 못하는 비용이 커집니다.

여기서 필요한 것이 Verification Scope Manifest(VSM) 입니다. VSM은 agent의 자기평가서를 믿자는 제안이 아닙니다. 변경이 주장하는 행동, 영향받는 경계, 실행한 검증, 제외한 검증, 불확실성, rollback 신호를 PR과 CI가 함께 검토할 수 있게 남기는 계약입니다. 이 글은 저장소별 AI 코딩 에이전트 평가, AI 생성 테스트와 Mutation Quality Gate, Reviewable Stack, AI 보조 전달 지표를 연결합니다.

이 글에서 얻는 것

• 전체 CI green, code coverage, agent가 쓴 테스트 수가 단독 품질 지표가 아닌 이유를 이해합니다.
• 변경별 검증 범위를 행동·데이터·권한·운영 경계로 나눠 선언하는 방법을 배웁니다.
• manifest와 실제 diff·테스트·CI 정책이 어긋날 때 fast lane을 멈추는 기준을 만듭니다.
• 2주 canary에서 CI 시간은 줄이면서 escaped defect와 review 재질문을 늘리지 않는 측정법을 얻습니다.

핵심 개념/이슈

1) 전체 통과는 필요한 증거일 수 있어도 충분한 증거는 아니다

전체 테스트가 통과하면 known regression 일부를 막았다는 뜻입니다. 하지만 agent가 새로 건드린 동작과 test suite coverage가 맞물렸는지는 별개입니다.

에이전트가 만든 테스트는 행복 경로와 구현 세부사항을 복제하기 쉽습니다. “테스트 파일이 12개 늘었다”는 말은 증거 목록의 시작일 뿐입니다. Mutation Quality Gate처럼 고위험 분기의 조건을 일부 바꿨을 때 test가 실패하는지, failure mode가 assertion에 담겼는지를 별도로 봐야 합니다.

2) VSM은 변경을 작게 만드는 도구가 아니라 불확실성을 보이게 한다

좋은 manifest는 ‘영향 없음’을 선언하지 않습니다. 자동 분석이 payments/*와 shared/auth 파일을 찾았는데 agent가 “UI 문구만 변경”이라고 적으면 reviewer는 더 빠르게 불일치를 발견할 수 있습니다.

verification_scope:
  change_id: pr-1842
  risk: high
  claimed_behavior: ["expired coupon은 checkout에서 거절한다"]
  changed_surfaces: ["POST /checkout", "coupon eligibility", "coupon.expires_at read only"]
  required_evidence:
    - "coupon_expired_returns_422"
    - "checkout query count <= baseline + 1"
    - "1% canary; checkout_422_rate"
  excluded: ["full provider sandbox: contract unchanged"]
  uncertainty: ["legacy mobile error-code parsing not replayed"]
  rollback: "feature flag: coupon_expiry_enforcement"

excluded와 uncertainty가 핵심입니다. 모든 테스트를 돌리지 않았다는 사실을 숨기지 않고, 누가 승인할지를 보이게 합니다. low-risk 문서 변경의 manifest는 아주 작을 수 있고, auth·결제·data deletion은 더 많은 근거와 owner 승인을 요구합니다.

3) manifest는 agent의 출력이 아니라 CI와 reviewer의 교차검사 대상이다

agent가 VSM을 썼다고 신뢰하면 자연어 checklist 하나가 늘어날 뿐입니다. manifest를 diff·policy·실행 결과와 대조해야 합니다.

• migrations/ 또는 ORM entity가 바뀌었는데 data surface가 비어 있으면 review-required로 올립니다.
• dependency lockfile이 바뀌었는데 dependency review 또는 license/security evidence가 없으면 fast lane을 막습니다.
• auth, payment, admin, egress 경로가 바뀌었는데 risk가 low이면 policy가 승격합니다.
• 변경 파일이 25개 이상인데 required evidence가 unit test 하나뿐이면 stack 분할 또는 owner review를 요청합니다.
• manifest의 test가 CI에서 실행되지 않았거나 flaky로 skip됐다면 green이 아니라 incomplete입니다.

static call graph, CODEOWNERS, API spec diff, migration detector는 false positive와 false negative를 냅니다. 자동 분석은 최종 판정이 아니라 추가 근거가 필요하다는 신호여야 합니다. agent가 자신 있게 범위를 좁혀도 시스템은 반증할 경로를 유지해야 합니다.

실무 적용

1) 처음에는 다섯 필드만 강제한다

VSM이 긴 설계 문서가 되면 복사·붙여넣기가 됩니다. 2주 파일럿은 다섯 필드로 시작합니다.

1. claimed behavior: 사용자가 관찰할 변화 한두 개
2. risk label: low / standard / high / blocked
3. changed surfaces: API, domain, data, dependency, permission, deployment
4. required evidence: test, analysis, canary, manual check
5. rollback or observation: flag, 되돌릴 commit, 배포 후 signal

excluded는 standard 이상, uncertainty는 high에서만 필수로 늘려도 충분합니다. low-risk 문서 PR에 rollout metric을 요구하면 문서 수정 자체가 느려지고, high-risk 결제 변경이 “unit tests passed” 한 줄로 merge되면 안 됩니다.

2) CI를 fast, evidence, slow lane으로 분리한다

VSM은 선택적 테스트를 정당화하는 면허가 아닙니다. 변경이 어떤 검증 lane을 반드시 지나야 하는지 명시하게 하는 장치입니다.

standard PR은 fast와 필요한 evidence lane을 통과하면 merge할 수 있고, slow lane은 nightly로 비교할 수 있습니다. 단 DB migration, authentication, public API breaking change는 slow lane 또는 별도 canary를 merge 전 또는 release 전 필수로 올립니다. fast lane 10분 목표를 위해 특정 경계의 필수 검증을 빼서는 안 됩니다.

3) manifest와 실제 결과를 receipt로 남긴다

PR 본문은 수정될 수 있고 CI link는 만료될 수 있습니다. merge artifact에는 manifest digest와 실행 결과를 남깁니다.

verification_receipt:
  change_id: pr-1842
  source_commit: 91d7c12
  manifest_digest: sha256:...
  policy_revision: verify-policy-2026.10.27
  lanes: {fast: passed, evidence: passed, slow: scheduled-nightly}
  skipped_checks: ["provider-sandbox: contract unchanged; owner approved"]
  rollout_signal: checkout_422_rate
  rollback: feature_flag:coupon_expiry_enforcement

이 receipt는 감시 기록이 아닙니다. 배포 뒤 오류가 나면 “어떤 경계를 검증했다고 믿었고 무엇을 제외했는가”를 재구성하는 운영 증거입니다. AI 보조 전달 지표에서 말한 rework와 rollback을 해석할 때도 PR 수보다 이 기록이 유용합니다.

4) 2주 동안 정확도와 비용을 함께 비교한다

전체 저장소에 강제하지 말고 agent가 자주 수정하는 service 하나에서 시작하세요. 첫 주는 manifest를 권고하고 diff·CI 결과·review comment에서 누락 패턴을 봅니다. 둘째 주에는 dependency 변경과 auth/data surface에만 evidence lane을 강제합니다.

성공은 CI 시간이 짧아진 것만으로 판단하지 않습니다. reviewer가 “무엇이 바뀌었나”를 다시 묻는 비율, manifest와 diff가 불일치해 승격된 비율, required check p95와 불필요 runner minutes, merge 뒤 7일의 rework·rollback·escaped defect를 같은 risk label에서 비교합니다. runner minutes가 18% 줄었지만 high-risk PR rework가 6%p 늘었다면 확대할 단계가 아닙니다.

트레이드오프/주의점

reflection, dynamic query, feature flag, 원격 configuration, shared library는 정적 diff에서 빠지기 쉽습니다. “영향 없음”을 자동 merge 근거로 쓰지 말고 uncertainty가 남는 변경을 사람·canary·더 넓은 test로 보내야 합니다. 모든 change에 최대 테스트·지표·rollback을 요구하면 작은 개선까지 병목이 되므로 low-risk에는 짧은 fast lane을 제공합니다. Reviewable Stack처럼 큰 diff는 독립 검증 단위로 나누는 편이 낫습니다.

verification receipt에는 prompt 원문, 고객 데이터, secret, 상세 token trace를 넣지 마세요. source commit, policy version, 실행한 check, 요약 지표, owner 정도의 최소 사실로도 대부분의 운영 판단은 가능합니다.

체크리스트 또는 연습

• PR의 사용자·운영 행동과 changed surface(API, data, permission, dependency, deployment)를 분리해 적는다.
• risk label이 diff detector·CODEOWNERS·migration/dependency policy와 어긋나면 review-required로 승격된다.
• required evidence는 test뿐 아니라 contract, migration, query/performance, canary 중 필요한 종류를 포함한다.
• skipped check에는 이유·승인자·만료 또는 재실행 조건이 있다.
• fast, evidence, slow lane과 high-risk merge/release gate가 구분돼 있다.
• receipt에 commit, manifest/policy digest, 실제 실행 결과, rollback signal이 남는다.

연습으로 최근 agent PR 하나를 고르세요. diff를 보지 않고도 “무슨 행동이 바뀌었나, 어떤 경계가 위험한가, 어떤 검증은 실행했고 무엇은 하지 않았나, 문제면 무엇을 관찰하고 어떻게 되돌리나”에 5분 안에 답할 수 있는지 적어 보세요. 답하기 어렵다면 다음 개선은 더 긴 구현 prompt가 아니라, 검증 범위를 선언하고 CI가 반증할 수 있게 만드는 일입니다.

관련 글

• AI 코딩 에이전트의 저장소별 실행 계약
• AI 생성 테스트와 Mutation Quality Gate
• Reviewable Stack으로 큰 변경을 쪼개는 법
• AI 보조 전달 지표: Review Latency와 품질
• CI 변경 예산