신뢰의 격차: AI가 프로덕션 사이트에 조용한 오류를 유발하는 방식

그 작업은 일상적인 것처럼 보였습니다. 라이브 페이지의 비교 테이블을 업데이트하는 것 — 새로운 속성을 추가하고, 몇 개의 행을 조정하여 프로덕션 (Production)에 반영하는 작업이었습니다. AI는 이를 완료했고, 완료되었다고 보고했으며, 저는 다음 작업으로 넘어갔습니다. 두 달 후, 제3자 분석에서 엔티티 (Entity) 충돌이 발견되었습니다. 하나의 속성이 잘못된 도시에 기재되어 있었던 것입니다. 잘못된 건물이나 잘못된 거리가 아니라, 완전히 잘못된 도시였습니다. 하나는 페이지에 명시된 위치에서 100마일 이상 떨어진 곳이었습니다. 그동안 페이지는 라이브 상태였고, 인덱싱 (Indexed)되었으며, 유기적 트래픽 (Organic traffic)을 계속 받고 있었습니다. 페이지는 정상적으로 로드되었습니다. 빌드 오류 (Build errors)도 없었습니다. 타입 오류 (Type errors)도 없었습니다. 404 오류도 없었습니다. 그 무엇도 무언가 잘못되었다는 것을 나타내지 않았습니다. 그것이 바로 신뢰의 격차 (Confidence gap)입니다.

무슨 일이 일어났는가
AI는 처음부터 부동산 비교 테이블을 구축하는 과업을 부여받았습니다. 각 항목에 대한 이름, 위치, 가격, 정책이 필요했습니다. 일부 값은 데이터베이스 (Database)에 존재했습니다. 다른 값들은 AI가 주변 페이지 콘텐츠와 이전에 생성된 텍스트로부터 추론 (Inferred)한 것이었습니다. AI는 이러한 추론을 추측이라고 표시하지 않았습니다. 그저 그대로 작성했을 뿐입니다. 그러고 나서 작업이 완료되었다고 보고했습니다. 다음은 오류의 모습입니다 — 익명화되었지만, 실제 실패 사례와 구조적으로 동일합니다:

부동산 | 올바른 도시 | 페이지에 기재된 내용
부동산 A | Morrison | Pueblo
부동산 B | Manitou Springs | Colorado Springs
부동산 C | Denver | Fort Collins

세 개의 부동산. 세 개의 잘못된 도시. 모두 라이브 상태였고, 모두 인덱싱되었으며, 모두 Google의 엔티티 모델 (Entity model)에 조용히 잘못된 신호를 보내고 있었습니다.

구체적인 메커니즘: 한 부동산의 도시 필드는 페이지의 주변 산문(Prose)으로부터 추론되었습니다. 그런데 그 산문 자체도 이전의 AI 작업에 의해 작성된 것이었습니다. 테이블이 구축되기 전부터 오류는 이미 포함되어 있었습니다. AI가 해당 텍스트를 문맥 (Context)으로 읽었을 때, 이를 사실로 받아들였고 이를 새로운 테이블로 전파 (Propagated)했습니다. AI가 잘못 작성했습니다. AI가 그것을 다시 읽었습니다. AI가 또 잘못 작성했습니다.

이것은 환각 (Hallucination)이 아닙니다. 피드백 루프 (Feedback loop)입니다. 그리고 환각과 달리, 이는 내부적으로 일관적입니다. 페이지의 어떤 부분도 서로 모순되지 않습니다. 오류가 일관성을 갖습니다. 바로 그 점이 오류를 보이지 않게 만듭니다.

피드백 루프 (Feedback loop)가 중요한 이유
Google의 엔티티 모델 (Entity model)은 단순히 콘텐츠를 읽는 것에 그치지 않고, 이를 교차 참조 (Cross-reference)합니다. 페이지가 특정 랜드마크 근처에 부동산이 있다고 설명하는데, 위치 필드에는 100마일 떨어진 곳으로 표시되어 있다면 이는 지리적 모순입니다. 엔티티 리졸버 (Entity resolver)가 이를 플래그 (Flag) 처리합니다. 이는 실제 SEO 신호이며, 오류가 발생했을 때와 마찬가지로 사용자에게 보이지 않게 불리하게 작용합니다. 이 지점이 피드백 루프를 일회성 실수보다 더 심각하게 만드는 부분입니다. 단 하나의 잘못된 사실은 페이지 하나를 저하시킬 수 있습니다. 하지만 다시 읽히고 전파되는 잘못된 사실은 사이트 전체로 퍼져 나갑니다. 새로운 페이지가 추가될 때마다 동일한 모순의 출처가 더해지며, 엔티티 신호 (Entity signal) 문제를 복합적으로 악화시킵니다.

신뢰도 (Confidence)가 실제 문제인 이유
대부분의 AI 실패는 명백합니다. 코드가 컴파일되지 않거나, 페이지가 충돌하거나, API가 에러를 반환합니다. 이런 경우 즉시 확인할 수 있습니다. 하지만 이 실패 유형은 다릅니다. 출력물은 구문론적 (Syntactically)으로나 시각적으로나 정확합니다. 표를 훑어보는 사람은 정답을 이미 알고 있지 않는 한 알아차리지 못할 것입니다. 완료를 보고할 때 AI의 어조 — "완료됨, 푸시됨" — 는 사실을 검증했는지 아니면 지어냈는지에 관계없이 동일합니다. 이것이 바로 신뢰의 격차 (Confidence gap)입니다. 문제를 감지하는 데 사용될 신호(확신에 찬 완료 보고)가 모든 것이 정상일 때 AI가 내보내는 신호와 동일합니다.

이 격차는 상업용 사이트에서 특히 위험한데, 그 이유는 다음과 같습니다:

• 콘텐츠가 빠르게 게시되고 인덱싱 (Indexed)됨
• 오류가 페이지를 통해 복합적으로 발생함 — 한 곳의 잘못된 사실이 다시 읽혀 다음 페이지에 쓰임
• 비즈니스 이해관계가 실질적임 — 잘못된 위치 데이터는 SEO 엔티티 신호, 사용자 신뢰, 그리고 제휴 전환 (Affiliate conversions)에 영향을 미침

이러한 실수를 저지르는 개발자라면 보통 해당 부동산이 존재하는지 확인하러 갔을 때 이를 알아차렸을 것입니다. 하지만 AI는 명시적으로 요구되지 않는 한 그 검증 단계를 완전히 건너뜁니다.

감사 (The audit)
첫 번째 오류를 발견한 후 취해야 할 올바른 조치는 단 하나의 사례만 수정하고 넘어가는 것이 아니라, 전체 감사 (Full audit)를 수행하는 것이었습니다.

과정:

• 모든 속성(name, city, address)에 대해 데이터베이스(Database)에 직접 쿼리하여 신뢰할 수 있는 원천 값(Source-of-truth values)을 확인합니다.
• 각 페이지의 모든 하드코딩된 참조를 다른 페이지 콘텐츠가 아닌, 데이터베이스(DB) 레코드와 비교합니다.
• 무엇인가를 수정하기 전에 불일치 사항을 표시(Flag)합니다.
• 확인된 오류만 한 번에 하나씩 수정하며, 매번 푸시 전 요약 테이블(Pre-push summary table)을 작성합니다.

감사한 40개 페이지에 대한 전체 피해 보고서:

• 오류 유형 | 개수
• 잘못된 도시 (Wrong city) | 3개 속성
• 잘못된 이름 (Wrong name) | 2개 속성
• 일관되지 않은 평점 (Inconsistent rating) | 6개 사례
• 총 수정 사항 | 9개 이상

이 모든 오류는 이미 라이브(Live) 상태였습니다. 그 어떤 자동화된 알림(Automated alert)도 발생하지 않았습니다. 핵심적인 원칙은 이것입니다: 페이지가 아니라 데이터베이스가 신뢰할 수 있는 원천(Source of truth)이어야 합니다. 페이지 자체를 기준으로 페이지를 감사하면 아무것도 찾을 수 없습니다. 그저 오류가 내부적으로 일관되게 유지되고 있음을 확인할 뿐입니다. 반드시 상류(Upstream)로 올라가야 합니다.

프로세스의 변화
앞으로의 규칙은 간단합니다: 검증된 출처 없이는 어떤 속성 상세 정보도 작성되지 않습니다. 만약 도시 정보가 데이터베이스(DB) 레코드에 없다면, 정보를 요청해야 합니다. 빈칸을 임의로 채워서는 안 됩니다. 상용 사이트에 푸시(Push)하기 전에는 반드시 다음과 같은 푸시 전 요약 테이블(Pre-push summary table)이 필요합니다:

파일 (File)	필드 (Field)	수정 전 (Before)	수정 후 (After)
ExamplePage.tsx	location	Old value	Verified value

사람은 커밋(Commit)이 일어나기 전에 해당 테이블을 검토합니다. 커밋이 일어난 후가 아닙니다. 이것이 AI의 실수를 완전히 없애주는 것은 아니지만, 실수가 라이브 상태가 되기 전에 가시화되도록 만듭니다. 그것이 유일하게 현실적인 기준입니다. AI 도구들은 검증된 출처가 없을 때 문맥(Context)으로부터 값을 계속해서 추론할 것입니다. 운영자의 역할은 제품이 배포(Ship)되기 전에 그 간극을 잡아내는 프로세스를 구축하는 것입니다.

운영자에게 이것이 의미하는 바
만약 AI를 사용하여 상용 사이트를 구축하거나 유지 관리하고 있다면, 아직 발견하지 못한 오류가 있다고 가정하십시오. 눈에 보이는 문제가 없다는 것이 정확성의 증거는 아닙니다. 가장 위험한 AI 출력물은 바로 '맞아 보이는' 것들입니다. 컴파일되지 않는 코드는 즉시 수정됩니다. 하지만 사실관계는 틀렸으나 문법적으로 완벽한 콘텐츠는 프로덕션(Production) 환경에 몇 달 동안 머물며 인덱싱(Indexing)되고, 읽히고, 전파됩니다. 페이지가 아닌, 신뢰할 수 있는 원천(Source of truth)으로부터 감사를 수행하십시오.

무언가가 인덱싱(Indexing)되기 전에, 워크플로(Workflow) 내에 푸시 전 검토(Pre-push review) 단계를 구축하십시오. 그리고 AI의 확신(Confidence)을 중립적인 신호로 취급하십시오. 이는 작업이 완료되었음을 알려주는 것이지, 출력이 정확하다는 것을 의미하지 않습니다. 그 두 가지 사이의 격차가 바로 프로덕션 오류(Production errors)가 발생하는 지점입니다.