오늘 나온 개발 실무 자료 중에는 Microsoft의 Only believe what you can validate가 상당히 유용합니다. Microsoft 직원이 작성한 실무 관점의 글이며 Microsoft 전체의 공식 AI 정책이라기보다는 agentic application modernization 경험을 정리한 엔지니어링 프레임워크로 보는 것이 정확합니다. devblogs.microsoft.com
문제의 출발점은 간단합니다.
AI가 COBOL 같은 레거시 모듈을 몇 분 만에 분석해 2,500단어짜리 문서를 만들면 사람이 앞부분 몇 줄만 보고:
“대충 맞는 것 같은데?”
라고 판단하기 쉽습니다.
하지만 작성자는 AI 실패를 크게 세 종류로 나눕니다.
Miss — 중요한 것을 누락
Hallucination — 없는 것을 생성
Misinterpretation — 사실은 읽었지만 잘못 해석
그리고 AI + Human + Deterministic Tool 가운데 어느 하나만으로는 충분히 검증할 수 없다고 봅니다. devblogs.microsoft.com
코드 생성에서 제안하는 검증 계층
글에서 제시하는 방향을 압축하면:
Build → Lint → Security Scan → Unit Test → Integration Test → 실제 데이터 비교 → 성능 테스트 → E2E → Shadow run
순으로 검증 수준을 높여가는 방식입니다. devblogs.microsoft.com
여기서 중요한 개념은:
검증 작업에는 반드시 기계적으로 남는 결과가 있어야 한다.
입니다.
“전문가가 리뷰했다”가 아니라:
어떤 business rule을 확인했고, 무엇을 수정했으며, correction rate가 얼마인지
처럼 결과를 데이터화해야 합니다.
산업·실무 영향
코딩 에이전트가 빨라질수록 사람이 만드는 코드보다 검증되지 않은 코드 증가 속도가 더 빨라질 수 있습니다.
따라서 AI 개발 생산성의 실제 병목은 점점:
Generation throughput
보다
Verification throughput
이 됩니다.
오늘 바로 적용할 수 있는 것
에이전트가 코드 변경을 만들면 최소한:
Build → Lint → Test → Security → Agent Review → Human Review
를 자동 실행하고, 각 단계에서 Pass/Fail artifact를 남기는 구조가 좋습니다.
“Codex가 다 했다고 한다”는 것은 검증 결과가 아닙니다.