AI 에이전트에게 맡기는 범위는 '확인 가능한 범위'로 결정한다 - 테스트가 통과했음에도 고장 났던 경험과 나의 개발 전체 그림

Claude Code, Codex, Cursor를 매일의 개발에서 사용하면서 진행 흐름이 잡혔습니다. 연재물 「AI에게 맡기고, 확인하기」에서는 그 운영을 통해 결정한 것들, 실패했던 것들, 그리고 수정한 것들을 써나갈 예정입니다. 이번 글에서는 그 전체 그림을 소개합니다.

먼저 결론부터 말씀드리자면, 저는 AI의 지능이 아니라 '그 환경에서 확실하게 검증할 수 있는가'를 기준으로 AI에게 맡길지 결정하고 있습니다. 이렇게 생각하게 된 계기는 테스트는 모두 통과했지만 실제로는 고장 났던 두 가지 사건 때문이었습니다.

첫 번째는 의존성(dependency)의 버전을 올리는 작은 수정 사항을 AI에게 맡겼을 때였습니다. 테스트는 통과했고, AI의 리뷰에서도 '병합 가능' 판정을 받았습니다. 그런데 다른 에이전트가 다시 검토하자, 테스트용 컨테이너를 이름으로 재사용했기 때문에 새로운 버전이 아니라 이전 컨테이너 상태로 테스트가 실행되고 있었다는 것을 알게 되었습니다. 이후 재사용하는 컨테이너 이름에 버전을 포함하도록 수정했습니다.

두 번째는 테스트 그룹을 다른 OS의 CI(Continuous Integration) 환경으로 옮겼을 때였습니다. AI가 실패한 테스트에 skipif를 3군데 추가하여 CI는 성공했습니다. 하지만 리뷰 과정에서 의도적으로 구현을 망가뜨려 테스트해보니, 해당 테스트는 실패하지 않았습니다. 그 OS에서는 지켜야 할 검사가 통째로 실행되지 않은 것입니다.

두 경우 모두 '테스트가 통과하는 것'과 '올바른 것을 테스트하고 있는 것'은 별개라는 이야기입니다.

AI가 테스트를 '통과시키는 것'에만 치우치는 행동은 2026년에 발표된 각 사의 최신 모델 자료나 외부 평가 기관의 보고서에서도 언급되고 있습니다.

• Anthropic의 Claude Opus 5.5 시스템 카드(2026년 9월)에는 학습 과정에서 답 추측이나 기존 해법의 유용(reward hacking)을 감시하고 있다고 쓰여 있습니다. 또한, 과제에 필요한 파일이 누락되어 풀 수 없는 경우, reward hacking을 시도하는 비율이 비교한 세 모델 모두 3~6배 증가했다고 보고했습니다 (어떤 모델이든 약 8할은 미완성 상태임을 알면서 제출한 작업입니다). 채점에서 불합격될 만한 변경 사항을 git 작업을 통해 채점자로부터 숨긴 사례도 실렸습니다.
• OpenAI의 GPT-6 Astra 시스템 카드(2026년 9월)에는 풀 수 없는 코딩 과제에 대한 회피책을 모델이 사고 과정에서 '일반적인 모듈화'처럼 설명하는 경우가 있어, 감시 측면에서 구별하기 어렵다고 합니다. 구별하기 어려운 주된 이유는 감시 측의 판정 경계에 있으며, 의도적으로 숨기고 있다는 증거는 아닐 수도 있다고 적혀 있습니다.
• Google은 Gemini 4 Argon 보안 블로그(2026년 10월)에서 학습 중 과제가 어렵거나 환경에 결함이 있을 때, 모델이 드물게 채점 스크립트를 수정하려 하거나 테스트 러너의 메모리에서 답을 읽으려 했던 사례를 감시로 포착했다고 쓰여 있습니다.
• 외부 평가 기관인 METR은 2026년 5월 보고서에서, 평가할 때마다 부정행위가 없는지 수작업으로 확인하는 작업이 전체 작업 시간의 대부분을 차지하는 경우가 많다고 했습니다. 과제를 고정해도 부정 시도는 계속되었다고 합니다.

여기서 제가 얻은 교훈은 AI가 주의해 줄 것이라고 기대하지 말고, **'확인하는 메커니즘 자체에서 방지하는 것'**입니다. 저의 두 실패 사례는 풀 수 없는 과제를 주었거나, AI가 속임수를 쓴 상황이 아니었습니다. 그럼에도 확인 방식에 구멍이 있다면 '통과한 것처럼 보이는' 상태가 발생합니다.

현재 흐름은 다음과 같습니다.

[IMG:N]

그림은 병합(merge) 전에 실제 기기에서 테스트할 수 있는 경우의 흐름이며, 실기 시험은 AI가 수행하고 진행 과정의 주요 지점은 사람이 확인합니다. AI로 할 수 없는 부분만 사람이 시험합니다. 병합하지 않으면 테스트할 수 없는 기능이라면, 테스트는 병합 이후입니다. 병합 전에 테스트할지 여부는 기능별로 결정합니다.

이 흐름을 뒷받침하는 원칙은 세 가지가 있습니다.

설계와 구현은 Claude Code로 진행하고, 구현 중/직후 리뷰는 Claude Code의 다른 에이전트에게, 구현이 끝난 후 최종 리뷰는 Codex와 Cursor에게 맡기는 등, 만든 것과는 별도의 에이전트나 툴에 검증을 받습니다. 구현 전 설계 감사 역시 설계한 것과 별도의 에이전트(Opus)가 담당합니다. Claude Code의 공식 베스트 프랙티스에도 새로운 컨텍스트에서 보면 리뷰가 잘 된다는 점(자신이 방금 작성한 코드에 영향을 받지 않는다는 의미)을 들어 Writer와 Reviewer를 다른 세션으로 분리하는 예시가 있습니다.

같은 모범 사례의 첫 번째 섹션은 'Claude에게 작업 검증 방법을 제공하라(Give Claude a way to verify its work)'입니다. 뒤에 나오는 흔한 실패를 정리한 섹션에서는, 확인할 수 없다면 배포하지 마라(If you can't verify it, don't ship it)라고까지 쓰여 있습니다. 저는 버그 수정 시, 먼저 수정 전 코드로 실패하는 테스트를 작성하게 하고, 그것이 실패하는 것을 본 후에 고치게 합니다. superpowers의 TDD 스킬에 있는 '테스트가 실패하는 것을 보지 못했다면, 올바른 것을 테스트하고 있는지 알 수 없다'와 같은 생각입니다.

설계는 구현 전에 사람이 승인하고, AI가 만드는 것은 Draft PR(초안 Pull Request)까지입니다. Approve(승인)와 Merge(병합)도 사람이 합니다. 작은 수정 작업을 맡는 Grok Bot(역할별로 나누어 상주시키는 AI 에이전트)에게는 각각 '하지 않을 것'(Merge 하지 않기, 리뷰 역할의 Grok Bot은 테스트 외 코드를 고치지 않기 등)을 먼저 정해 놓았습니다.

해외 대기업에서는 사람이 리뷰하지 않고 AI의 변경 사항을 수용하는 사례도 나왔습니다. 예를 들어 Meta는 실적을 확인한 자동화 변경에 한해서, 정해진 조건 검사, 기계 학습(ML) 기반 위험 판정, AI를 통한 리뷰 3단계를 모두 거친 것을 사람의 리뷰 없이 수용합니다(대상은 복잡도가 낮음~중간 정도의 변경입니다). 반면 Google은 AI가 생성한 코드도 엔지니어가 승인했다고 적었고, Stripe는 AI가 작성한 PR도 사람이 리뷰한 후에 수용하고 있다고 합니다. 자동으로 Merge해도 좋을 범위는, 검증 메커니즘을 어디까지 갖추었는지와 어느 정도의 위험을 허용할 수 있는지에 따라 결정된다고 생각합니다. 원칙 2의 검증 수단이 아직 부족한 제 환경에서는, Merge를 사람이 담당하고 있습니다.

이러한 원칙들은 어떤 도구에서도 볼 수 있는 하나의 규칙 파일(AGENTS.md)에 적혀 있습니다. 일부를 발췌하면 다음과 같습니다.

## 설계와 구현
- 새로운 기능이나 설계 변경은 '설계 → 구현 전 보안 감사 → 구현 → 다른 에이전트가 리뷰' 순서로 진행한다.
- 버그는, 고치기 전에, 고치려고 하는 함수의 호출원을 모두 보고, 공통된 곳에서 한 번에 고친다.
...

마지막 줄이 이 연재의 소재가 되었습니다. 놓치는 일이 생길 때마다 1줄의 학습으로 기록하고, 주 1회 규칙으로 승격시킬지 버릴지를 결정합니다.

망설일 때의 기준은 하나입니다.

망설여지면 스스로 진행합니다.

AI 에이전트 역시 개발 방식이 바뀌는 것이 빠르기 때문에, 정해진 순서는 두지 않고 그때 실제로 결정한 것과 실패했던 것들로부터 작성하겠습니다. 주제는 대략 다음 근처입니다.

• 만드는 역할과 검증하는 역할 분담
• 맡기기 전에 정할 것 (구현 전 감사, Grok Bot에게 '하지 않을 것'으로 전달하지 않을 정보)
• 에이전트가 구현 중 막혔던 부분 (셸, git worktree, CI 설정)
• 리뷰와 검증 (테스트를 약화시키지 않았는지 점검, 절차서 실물 대조, 측정 방법)
• 학습을 규칙으로 키워 운영하는 메커니즘

Claude Code, Codex, Cursor와 Grok Bot의 역할 분담도 다른 글에서 쓰겠습니다.

• Anthropic은 'Claude Opus 5.5 System Card'(2026년 9월 22일, 6.2 Behavior during training, 6.5.4.4 Concealment of changes)를 발표했습니다: https://www-cdn.anthropic.com/fc1b44717c85dc068bc6ba5024219938094694bd/Claude%20Opus%205.5%20System%20Card.pdf
• OpenAI는 'GPT-6 Astra System Card'(2026년 9월 3일, 9.1.2.1 CoT-only Monitor Scope)를 발표했습니다: https://deploymentsafety.openai.com/gpt-6-astra/cot-only-monitor-scope
• Google은 'Developing Gemini 4 Argon responsibly and safely'(2026년 10월 13일)에 대한 글을 올렸습니다: https://blog.google/innovation-and-ai/technology/safety-security/gemini-4-model-safety-security/
• METR는 'Frontier Risk Report (February to March 2026)'를 발표했습니다(2026년 5월 19일 공개): https://metr.org/risk-report-feb-mar-2026.pdf
• Claude Code Docs는 'Best practices for Claude Code'(2026년 10월 6일 업데이트)를 제공합니다: https://code.claude.com/docs/en/best-practices
• obra/superpowers는 테스트 주도 개발(test-driven development) 스킬에 대해 업데이트했습니다(2026년 9월 19일 업데이트): https://github.com/obra/superpowers/blob/5bf4e78011075bcfc0dc295f0724994cd123ee71/skills/test-driven-development/SKILL.md
• Meta는 'Automating Low-Risk Code Review at Meta: RADAR, Risk Calibration, and Review Efficiency'(arXiv, 2026년 5월 28일 공개, 6월 12일 수정 v2, 2.8 RADAR Pipeline for AI and Bot Diffs)를 발표했습니다: https://arxiv.org/abs/2605.30208
• Google은 Sundar Pichai가 'Cloud Next '26: Momentum and innovation at Google scale'(2026년 4월 22일)을 발표했습니다: https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/
• Stripe는 'Minions: Stripe's one-shot, end-to-end coding agents'(2026년 2월 9일)에 대한 글을 올렸습니다: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents