AI 지원 운영(AI-assisted operations)의 세계에서, 스스로 주도하는 모델과 지시를 받는 모델의 차이는 새벽 2시에 잠을 몇 시간이나 설칠지를 결정할 수 있습니다. 최근 Claude Opus와 GPT Codex 간의 실제 장애 비교를 통해 자율적인 문제 해결 능력에서 놀라운 격차가 있음이 드러났습니다.

목차
장애 상황: 계정 잠김 사용자
테스트: 동일한 장애, 두 개의 엔진
이것이 중요한 이유
진짜 원인: Gmail의 마침표(Dot)
더 넓은 패턴
운영 환경에서의 Driver/Worker 패턴
새벽 2시의 교훈
핵심 요약
운영 팀을 위한 빠른 체크리스트

장애 상황: 계정 잠김 사용자
한 사용자가 Android 폰에서 가입을 할 수 없었습니다. 브리핑 내용은 다음과 같습니다: 이름과 "Google 기기". SEV-3 등급, 8분간의 세션, 227번의 클릭, 분노의 클릭(rageclicks) 포함.

함정: 가입 실패는 익명입니다. 식별(identify) 이벤트는 성공 시에만 발생하므로, 분석 데이터(analytics)에는 이메일, 사용자 이름, 사용자 ID가 없습니다. 검색(grep)할 수 있는 것이 아무것도 없습니다.

테스트: 동일한 장애, 두 개의 엔진
동일한 저장소(repo), 자격 증명(credentials), 기술(skills)을 가진 두 AI 엔진에 동일한 장애 상황을 부여했습니다.

이것이 중요한 이유
Opus는 전체 조사를 스스로 수행했습니다. Opus는 중단된 가입은 식별(identify) 이벤트를 발생시키지 않는다는 점을 깨달았고, 시간, 플랫폼, 등록 이벤트를 통해 익명 세션을 삼각 측량(triangulated)했습니다. 또한 PostHog 리플레이 블롭(blobs)을 해독하고, Supabase에서 중복 계정을 확인했으며, 재설정 이메일이 발송되지 않았음을 증명했고, 마스킹되지 않은 DOM 필드에서 근본 원인을 찾아냈습니다.

GPT는 어떤 도구를 사용해야 하는지 알려주는 것을 포함하여, 인간이 세 번이나 방향을 잡아주어야 했습니다. GPT는 "요청 수락됨(200), 완료 관찰되지 않음" 단계에서 멈췄습니다. 틀린 말은 아니지만, 잘못된 질문이었습니다.

리셋 엔드포인트(reset endpoint)에서 발생하는 200 응답은 의도적인 안티-열거(anti-enumeration) 기법이며, 어떤 주소에 대해서도 발생합니다. 200은 예의상 보내는 응답일 뿐, 사실이 아닙니다. Opus는 검증을 위한 제어 사용자(control user)를 활용하여 세 가지 계층(데이터베이스 트리거, 감사 로그, 메일 제공업체) 전체에서 메시지가 전달되지 않았음을 증명했습니다.

진짜 범인: Gmail의 점(Dot)
근본 원인은 잘못 놓인 점 하나였습니다:

• Gmail은 로컬 파트(local part)의 점을 무시하므로, 두 철자 모두 동일한 편지함에 도달합니다.
• 인증 데이터베이스(auth database)는 가공되지 않은 문자열(raw strings)을 비교하므로, 이들은 서로 다른 두 명의 사용자로 인식됩니다.
• 입력된 값: .NN@gmail.com (숫자 앞에 점이 있음)
• 실제 값: .NN@gmail.com (이름 뒤에 점이 있음)

잘못 놓인 점 하나가 10번의 로그인 실패, 작동하지 않는 비밀번호 재설정, 그리고 왜 "이미 존재함(already exists)" 메시지가 여전히 발생했는지(가입 화면에서만 자동 완성 기능이 올바른 철자를 제공함)를 모두 설명해 줍니다. 사용자 입장에서는 자신의 이메일이 그냥 자신의 이메일이었을 뿐입니다. 사용자가 맞았지만, 결과적으로 계정은 잠겨버렸습니다.

더 넓은 패턴
이러한 차이는 단일 사건에 국한되지 않습니다. 침투 테스트(PTES 방법론)를 통해 이 모델들을 비교한 연구는 일관된 패턴을 보여줍니다:

• Claude Opus는 우수한 적응력을 보여주며, 길고 일관된 대화를 유지하고, 초기 시도가 실패했을 때 대안적인 공격 경로를 제안합니다.
• GPT-4는 침투(exploitation) 및 보고(reporting) 단계에서 여전히 가치가 있지만, 때때로 수동 조정과 더 일반적인 명령어를 필요로 합니다.
• Claude Opus는 더 맥락에 특화된 제안을 제공하므로, PTES의 모든 단계에서 보조 도구로 권장됩니다.

운영 환경에서의 드라이버/워커(Driver/Worker) 패턴
많은 팀이 이제 이 모델들 중 하나를 선택하는 대신 계층적으로 운영하고 있습니다:

• Claude Code (Opus 4.7/4.8)는 드라이버(driver) 역할을 합니다. 계획을 세우고, 아키텍처를 유지하며, 무엇을 넘길지 결정합니다.
• Codex (GPT-5.5)는 워커(worker) 역할을 합니다. 드라이버가 위임한 긴 터미널 실행 작업을 수행합니다.
  이 패턴은 복잡한 리팩토링(refactors), 전체 WordPress 마이그레이션, 그리고 처음부터 시작하는 SaaS 재구축 과정 전반에서 유효함을 입증했습니다.

이 방식이 작동하는 이유:

Opus의 자기 검증 서브 에이전트 (self-verification sub-agents)와 긴 문맥 일관성 (long-context coherence)은 계획 수립 및 아키텍처 설계 (planning and architecture)에 이상적입니다.
Codex의 터미널 자율성 (terminal autonomy), 45분 이상의 지속적인 실행, 그리고 약 72% 적은 출력 토큰 (output tokens)은 실행 (execution)에 이상적입니다.

새벽 2시의 교훈
운영 (ops) 상황에서 새벽 2시에 가장 희소한 자원은 토큰이 아니라 인간의 주의력 (human attention)입니다. 스스로를 구동했던 엔진은 200 (HTTP 200 OK) 상태에서 멈추기를 거부했던 엔진이기도 했습니다. 배포된 수정 사항의 절반은 바로 그 엔진 덕분에 존재할 수 있었습니다. 만약 점(dot)을 찾아내지 못했다면, "점의 UX를 수정하라"는 작업은 결코 배포될 수 없었을 것입니다.

핵심 요약 (Key Takeaways)

• 장애 대응 (incident response)에서는 자율성 (autonomy)이 중요합니다. 인간의 조종 (human steering)은 시간과 주의력을 소모합니다.
• 200 (HTTP 200)을 맹신하지 마십시오. 여러 계층에 걸쳐 검증하십시오.
• 복잡한 작업에는 드라이버/워커 (driver/worker) 아키텍처를 고려하십시오.
• 작은 디테일(점과 같은)이 모든 것을 망가뜨릴 수 있으며, 깊이 파고드는 AI가 이를 찾아냅니다.
• "스스로를 구동했던 엔진은 200 상태에서 멈추기를 거부했던 엔진이기도 했습니다."

운영 팀을 위한 빠른 체크리스트 (Quick Checklist for Ops Teams)
[ ] 벤치마크뿐만 아니라 실제 장애 시나리오 (real incident scenarios)에서 AI 도구를 테스트하십시오.
[ ] 어떤 모델이 주도하고 (drives) 어떤 모델이 지시를 받는지 (gets driven) 평가하십시오.
[ ] 모델을 계층적 (hierarchical, driver/worker)으로 실행하는 것을 고려하십시오.
[ ] 여러 데이터 계층 (data layers)에 걸쳐 AI의 결론을 검증하십시오.
[ ] HTTP 200 응답을 액면 그대로 받아들이지 마십시오.
[ ] 어떤 작업에 어떤 모델이 가장 성능이 좋은지 문서화하십시오.