AI가 코드를 작성합니다. 같은 AI가 그 코드를 검토합니다. 문제를 발견할까요?
발견하지 못합니다. 정확히 말하면, 같은 편향을 가진 존재가 자기 결과물을 검토하면 같은 맹점을 공유합니다. 이건 AI만의 문제가 아닙니다. 사람도 마찬가지입니다. 자기가 쓴 글에서 오타를 찾는 것보다 남이 쓴 글에서 오타를 찾는 게 더 쉽습니다.
하지만 AI 시스템에서는 이 문제가 더 심각합니다. 사람은 경험과 성격이 다르지만, 같은 AI 모델은 같은 학습 데이터, 같은 추론 패턴을 가지고 있기 때문입니다. 그래서 우리는 다른 AI 모델을 검증에 투입하기로 했습니다.
• • •
자기 검토의 한계
Harness 프레임워크 초기에는 하나의 AI가 코드를 작성하고, 같은 AI에게 "이 코드를 검토해줘"라고 요청하는 방식이었습니다. 결과는 예상대로였습니다.
코드 검토 결과가 거의 항상 "좋습니다"였습니다. 문법적 오류나 명백한 버그는 잡았지만, 설계 수준의 문제나 보안 취약점은 놓치는 경우가 많았습니다. 왜냐하면 그 설계를 한 것도 같은 AI이고, 그 설계가 "합리적이라고 판단한" 것도 같은 AI이기 때문입니다.
구체적인 예를 들면, 설정 파일을 수정하는 코드를 작성하면서 기존 설정을 백업하지 않는 실수가 있었습니다. 같은 AI에게 리뷰를 요청하면 "설정 수정 로직이 정상입니다"라고 답합니다. 백업이 필요하다는 판단 자체를 하지 못하는 거죠. 왜냐하면 처음부터 "백업 없이 수정해도 된다"는 전제로 코드를 작성했으니까요.
자기 검토는 자기가 보지 못한 것을 보지 못하는 구조적 한계를 가지고 있습니다.
• • •
다른 모델이 검증하는 이유
해결책은 단순하지만 효과적입니다. 코드를 작성하는 AI와 검증하는 AI를 분리하는 것. 그것도 다른 모델로.
서로 다른 AI 모델은 서로 다른 학습 데이터와 추론 방식을 가지고 있습니다. A 모델이 놓친 패턴을 B 모델이 잡아낼 수 있고, B 모델이 간과한 보안 이슈를 C 모델이 감지할 수 있습니다.
이것은 소프트웨어 업계에서 오래 전부터 쓰던 방법론의 AI 버전입니다. 코드 리뷰를 왜 다른 개발자가 하는지, 감사를 왜 외부 감사인이 하는지. 같은 원리입니다. 검증의 가치는 검증자가 제작자와 다를 때 극대화됩니다.
| 항목 | 같은 모델 검증 | 다른 모델 검증 |
|---|
| 편향 | 동일한 편향 공유 | 서로 다른 관점 |
| 맹점 발견 | 자기 맹점을 놓침 | 교차 검증으로 발견 |
| 검토 깊이 | 문법/구문 수준 | 설계/보안/성능 수준 |
| 신뢰도 | 자기 확증 편향 | 독립적 판단 |
• • •
4단계 검증 흐름
Harness 프레임워크의 검증 체인은 4개의 단계로 구성됩니다. 각 단계는 별도의 AI 모델이 담당하며, 각 단계가 통과해야 다음 단계로 넘어갑니다.
4단계 검증 체인
Stage 1 — 계획 검증 에이전트
이 작업이 승인된 범위에 맞는가?
CEO가 승인한 요구사항과 실제 구현 계획을 대조합니다. 범위를 벗어난 작업이 포함되어 있으면 경고를 발생시킵니다. 스코프 크리프를 구조적으로 차단합니다.
Stage 2 — 코드 검증 에이전트
보안, 성능, 품질 교차 검사
별도 AI 모델이 작성된 코드를 검토합니다. 보안 취약점, 성능 병목, 코드 품질, 국제화(i18n), UX 영향을 다각도로 검사합니다.
Stage 3 — 스펙 확인 에이전트
결과물이 요구사항과 일치하는가?
구현된 결과물이 원래 요구사항을 충족하는지 확인합니다. 누락된 기능이나 변경된 동작을 감지합니다.
Stage 4 — 배포 보호 에이전트
배포해도 안전한가?
배포 직전 최종 관문입니다. 자동화 테스트 통과 여부, 이전 단계 검증 결과 확인, 환경 설정 검증.
4단계 전부 통과 → CEO 승인 요청 → 배포
핵심은 순서입니다. 계획 검증이 통과해야 코드 검증으로 넘어가고, 코드 검증이 통과해야 스펙 확인으로 넘어갑니다. 하나라도 실패하면 체인이 멈춥니다. 그리고 모든 검증이 끝난 후에도 최종 판단은 사람이 합니다.
• • •
자동 트리거 방식
검증 체인에서 중요한 것은 "잊지 않는 것"입니다. 사람이 매번 "검증해줘"라고 요청해야 한다면, 바쁠 때 빠뜨리기 마련입니다.
Harness에서는 자동 트리거를 사용합니다. 코드 수정이 완료되면 검증 체인이 자동으로 시작됩니다. 이 자동화가 중요한 이유는 일관성 때문입니다. "이번엔 간단한 수정이니까 검증 안 해도 되겠지"라는 판단이 사고를 만듭니다.
자동 검증 흐름
코드 수정 완료
→
자동 트리거
→
4단계 체인
→
결과 보고
수동 요청 없이, 코드 변경 시 자동으로 전체 검증 체인이 시작됩니다.
• • •
차단이 발생하면
검증 에이전트는 세 가지 등급으로 결과를 보고합니다.
통과. 문제가 발견되지 않았습니다. 다음 단계로 진행합니다.
경고. 잠재적 이슈가 있지만 심각하지는 않습니다. 사유를 기록하고 CEO에게 보고합니다.
차단. 심각한 문제가 발견됐습니다. 배포가 즉시 중단됩니다.
차단은 무겁습니다. 하지만 차단이 존재하기 때문에 검증 체인이 의미를 가집니다. 멈출 수 있어야 진짜 관문입니다.
• • •
검증 체인의 효과
4단계 검증 체인을 도입한 후 가장 큰 변화는 "사고의 성격이 바뀐 것"입니다.
이전에는 배포 후에 문제를 발견하는 일이 있었습니다. 검증 체인 도입 후에는 문제가 배포 전에 발견됩니다.
물론 완벽하지는 않습니다. 4단계를 모두 통과했는데도 놓치는 문제는 있습니다. 하지만 "검증 없이 배포하는 것"과 "4단계 검증을 거친 후 배포하는 것"의 차이는 확연합니다.
진짜 견제는 같은 존재가 모자만 바꿔 쓰는 게 아니라, 다른 존재가 다른 관점에서 보는 것입니다. 그리고 마지막 판단은 반드시 사람이 합니다.
검증 체인은 AI를 신뢰하지 않겠다는 선언이 아닙니다. AI를 더 잘 활용하기 위한 구조입니다.
AI writes the code. The same AI reviews that code. Will it find the problems?
It won't. To be precise, when an entity with the same biases reviews its own output, it shares the same blind spots. This isn't unique to AI. Humans are the same. It's easier to find typos in someone else's writing than in your own.
But in AI systems, this problem is more severe. Humans have different experiences and personalities, but the same AI model has the same training data and same reasoning patterns. That's why we decided to deploy different AI models for verification.
• • •
Limits of Self-Review
In the early days of the Harness framework, one AI would write code and we'd ask the same AI to "review this code." The results were predictable.
Code review results were almost always "looks good." It caught syntax errors and obvious bugs, but frequently missed design-level issues and security vulnerabilities. Because the same AI that made the design also judged that design as "reasonable."
Concretely, there was a case where code was written to modify a configuration file without backing up the existing settings. When the same AI reviewed it, the response was "the configuration modification logic is correct." It couldn't even judge that a backup was necessary — because from the start, it had written the code with the premise that "modifying without backup is fine."
Self-review has the structural limitation of being unable to see what it couldn't see in the first place.
• • •
Why Different Models Verify
The solution is simple but effective: separate the AI that writes code from the AI that verifies it. Using different models.
Different AI models have different training data and reasoning approaches. Patterns that Model A misses can be caught by Model B, and security issues that Model B overlooks can be detected by Model C.
This is the AI version of a methodology the software industry has used for decades. Why code reviews are done by different developers, why audits are done by external auditors. Same principle. Verification value is maximized when the verifier is different from the creator.
| Aspect | Same Model Verification | Different Model Verification |
|---|
| Bias | Shared identical bias | Different perspectives |
| Blind Spots | Misses own blind spots | Cross-verification catches them |
| Review Depth | Syntax/grammar level | Design/security/performance level |
| Reliability | Confirmation bias | Independent judgment |
• • •
4-Stage Verification Flow
The Harness framework's verification chain consists of 4 stages. Each stage is handled by a separate AI model, and each must pass before moving to the next.
4-Stage Verification Chain
Stage 1 — Plan Review Agent
Does this work fit the approved scope?
Compares CEO-approved requirements against the actual implementation plan. Raises warnings if out-of-scope work is included. Structurally prevents scope creep.
Stage 2 — Code Review Agent
Security, performance, quality cross-check
A separate AI model reviews the written code. Examines security vulnerabilities, performance bottlenecks, code quality, internationalization (i18n), and UX impact from multiple angles.
Stage 3 — Spec Check Agent
Does the output match requirements?
Verifies that the implementation meets original requirements. Detects missing features or changed behaviors.
Stage 4 — Deploy Guard Agent
Is it safe to deploy?
The final gate before deployment. Checks automated test pass status, previous stage results, and environment configuration.
All 4 stages pass → CEO approval request → Deploy
Sequence is key. Plan review must pass before code review, code review before spec check. If any fails, the chain stops. And even after all verification completes, the final judgment is made by a human.
• • •
Auto-Trigger Mechanism
The critical thing in the verification chain is "not forgetting." If someone has to manually request "run verification" every time, it will get skipped when busy.
Harness uses auto-triggers. When code modification is complete, the verification chain starts automatically. This automation matters for consistency. "This is a simple change, skip verification" — that kind of judgment causes incidents.
Automated Verification Flow
Code Change Complete
→
Auto-Trigger
→
4-Stage Chain
→
Results Report
Without manual request, the full verification chain starts automatically on code changes.
• • •
When a Block Occurs
Verification agents report results in three grades:
Pass. No issues found. Proceed to next stage.
Warn. Potential issues exist but aren't critical. Reasons are logged and reported to CEO.
Block. Serious problem found. Deployment is immediately halted.
Pass
No issues
Proceed to next stage
Warn
Potential issues
CEO judgment needed
Block
Serious problem
Deploy immediately halted
Blocks are heavy. But blocks give the verification chain meaning. A gate that can't stop anything isn't a real gate.
• • •
Impact of the Verification Chain
The biggest change after introducing the 4-stage verification chain was that the nature of incidents changed.
Previously, problems were sometimes discovered after deployment. After the verification chain, problems are found before deployment.
It's not perfect. Some issues still slip through all 4 stages. But the difference between "deploying without verification" and "deploying after 4-stage verification" is dramatic.
Real accountability isn't the same entity wearing different hats — it's different entities examining from different angles. And the final judgment must always be made by a human.
The verification chain isn't a declaration of distrust in AI. It's a structure for leveraging AI better.
