$120짜리 환각이 열 번의 대화 턴 동안 틀린 주장을 고집했다. dev.to에 공유된 한 개발자의 사례다. Anthropic의 Opus 4.7 모델에 29개 평가 태스크를 돌렸더니 18개가 통과됐다. 모델에게 결과를 알려줬더니 "여전히 17개"라고 우겼다. 로그를 보여줘도, 추가 증거를 들이밀어도 모델은 새로운 설명을 지어내며 버텼다. 결국 API 비용 $120과 하루 작업 시간이 날아갔다. 개발자의 결론은 냉혹했다. "무서운 건 환각 자체가 아니라, 모델이 답을 이미 알고 있지 않으면 믿어버릴 만큼 확신에 차 있다는 점이다."
이 사건이 단순한 해프닝이 아닌 이유가 있다. 모델 능력이 올라갈수록 틀린 추론의 설득력도 함께 올라간다. 잘 구조화된 코드 설명을 생성하는 모델은 잘 구조화된 환각 정당화도 생성한다. 연구자들이 '정렬-능력 교차 문제(alignment-capability crossover)'라고 부르는 현상이다. 벤치마크 점수는 오르는데 실전 신뢰성은 내려간다. AI-First 워크플로우를 설계하는 팀 입장에서 이건 도구 선택 문제가 아니다. AI 결과물을 어떤 구조로 검증할 것인가의 문제다.
구조 1: 다른 모델이 리뷰한다—Adversarial Model Challenge
같은 모델에게 자기 코드를 리뷰하게 하는 건 버그를 쓴 개발자에게 버그 리포트를 쓰게 하는 것과 같다. 같은 맹점, 같은 추론 패턴, 같은 방어 본능을 공유한다. dev.to 아티클이 제안하는 해법은 단순하다. 빌더 모델이 작성한 결과물을 다른 모델이 명시적인 회의주의 지시를 받고 재검토하게 하는 것이다.
실제로 Opus 4.7 사례에서 개발자는 4.6으로 전환했더니 첫 시도에 정답을 얻었다. 4.6이 절대적으로 우월해서가 아니라, 같은 태스크에서 4.7과 다른 실패 패턴을 가졌기 때문이다. 이 원리를 워크플로우로 구조화하면 이렇게 된다. 빌더 모델은 스펙을 기반으로 빠르게 구현한다. 챌린저 모델은 동일한 스펙을 읽고 구현을 검토하되, "존재한다고 해서 옳다고 가정하지 말라"는 지시를 받는다. 요구사항과 코드의 실제 일치 여부, 엣지 케이스 처리, 테스트가 진짜 동작을 검증하는지, 아키텍처 선택이 맥락에 맞는지를 순서대로 따진다.
멀티 테넌트 SaaS 빌링 라우트 사례가 이 효과를 잘 보여준다. 빌더 모델이 owner 역할만 접근하도록 라우트를 구현했는데, 프론트엔드 스펙은 owner와 manager 모두 접근 가능해야 한다고 명시하고 있었다. 같은 모델이 양쪽을 다 만들었기 때문에 모순을 스스로 잡지 못했다. 챌린저 모델이 스펙과 대조해 이 불일치를 즉시 발견했다. 복잡한 인프라가 필요 없다. 구조화된 체크리스트와 호출 방식만 있으면 된다.
구조 2: 행동 의도를 명시한다—Product Behavior Contract
바이브 코딩은 빠르다. 그리고 그 속도 때문에 결정의 '이유'가 어디에도 남지 않는다. 코드는 무엇을 만들었는지 기억하지만 왜 그렇게 만들었는지는 기억하지 못한다. dev.to의 또 다른 아티클이 지적하는 핵심이다. 취소 플로우가 왜 이 방식인지, 유예 기간이 왜 5일인지, 빈 결과에서 오류 대신 묵음 실패를 선택한 이유가 어디에도 적혀있지 않다.
이게 AI 에이전트와 만나면 더 위험해진다. 에이전트는 리팩토링 요청을 받았을 때 기존 구현을 읽고 보존할 동작과 바꿀 동작을 스스로 추론한다. 명시적 제약이 없으면 그 판단은 부분적으로 추측이다. 테스트를 통과하면서 실제 동작을 바꾸는 리팩토링이 나오는 이유다. 에이전트를 탓할 수 없다. 규칙이 적혀있지 않았던 것이다.
제안되는 해법은 Product Behavior Contract(PBC)다. PRD가 '왜'를 설명하고, 테스트가 '어떻게'를 검증한다면, PBC는 '무엇이 보장되어야 하는가'를 명시한다. .pbc.md 파일을 레포에 두고, 각 동작마다 세 가지를 적는다. 반드시 일어나야 할 것, 절대 일어나면 안 될 것, 그리고 중요한 엣지 케이스. 빌링, 인증, 권한 같은 고위험 모듈부터 시작하면 된다. 전체 제품을 한 번에 명세화할 필요 없다. PBC 스펙은 오픈소스로 공개되어 있다(github.com/stewie-sh/pbc-spec).
구조 3: 명세 자체가 실행된다—Spec-Driven Integration
세 번째 각도는 통합 레이어에서 온다. 전통적인 엔터프라이즈 통합 패턴은 개발자가 클라이언트를 작성하고 인증을 붙이고 응답을 가공한다. 코드가 배포된 순간부터 문서와 멀어지기 시작한다. 한 분기면 세 팀이 같은 통합을 각자 다른 가정으로 세 번 만들어놓는다.
dev.to에서 소개된 Spec-Driven Integration(SDI) 방법론은 이 구조적 드리프트를 근본에서 차단한다. 명세가 문서가 아니라 직접 실행되는 아티팩트가 되는 방식이다. YAML로 어떤 API를 소비할지, 데이터를 어떻게 변환할지, 무엇을 노출할지를 선언하면 엔진이 런타임에 직접 읽고 실행한다. 코드 생성 단계가 없다. 누군가 생성된 코드를 수정하는 순간 명세와 구현이 어긋나는 드리프트 자체가 발생하지 않는다.
AI 에이전트 관점에서 이 방식의 장점은 명확하다. 에이전트는 여러 레포에 퍼진 커스텀 통합 코드를 역공학할 수 없다. 그러나 구조화된 캐퍼빌리티 스펙은 파싱할 수 있다. 어떤 툴이 있는지, 어떤 입력을 받는지, 어떤 출력을 내는지를 정확히 읽고 결정론적으로 호출한다. 명세가 곧 통합이면 AI 에이전트가 기존 운영 워크플로우에 신뢰 가능하게 편입될 수 있다.
AI 결과물 신뢰는 구조의 문제다
세 가지 접근이 각각 다른 레이어를 다루고 있지만 가리키는 방향은 같다. AI 생성 결과물의 신뢰는 모델 성능이 아니라 검증 구조에서 나온다. 챌린저 모델은 생성 단계의 환각을 교차 검증한다. PBC는 에이전트가 리팩토링할 때 지켜야 할 행동 경계를 명시한다. SDI는 통합 레이어에서 명세와 실행의 드리프트를 구조적으로 차단한다.
현장에서 내일 당장 시작할 수 있는 순서는 이렇다. 가장 위험한 모듈 하나를 골라 PBC를 세 줄로 써보는 것. 다음 코드 리뷰에서 다른 모델을 챌린저로 돌려보는 것. 그리고 반복적으로 드리프트가 발생하는 통합 지점을 명세 기반으로 전환할지 검토하는 것. 학습 곡선보다 도입 비용이 낮은 순서로 쌓아가면 된다. AI-First 팀이 'AI를 믿는다'는 말은 모델을 맹신한다는 뜻이 아니라, 검증 구조를 믿는다는 뜻이어야 한다.