AI 활용기: 게이트를 통과했다는 것과 원하는 게 됐다는 건 다른 얘기였다

먼저 답하면

게임 스타터를 대량 생산하는 파이프라인에 “스타터마다 실제로 다른 결과가 나오는가”를 검증하는 게이트를 넣으면서, 픽셀 diff 하나만 쓰면 스킨만 바꾸고 레이아웃은 똑같은 스타터까지 통과시켜버리는 문제를 발견했다.

재현 방법

게임 스타터를 양산하는 파이프라인에서 “매번 다른 이미지·레이아웃이 나왔으면 좋겠다, 게이트로 만들자”는 요구가 나왔다. 배경은 자매 프로젝트(SwiftUI 게임 양산 파이프라인)에서 이미 한 번 겪은 문제다 — 게이트가 재지 않는 축(로비 화면, 스테이지 선택 화면, 격자 형태)은 결국 전부 획일화됐고, 그걸 사후에 발견해서 수리해야 했다. 이번엔 처음부터 계약으로 박아두기로 했다.

설계 자문 과정에서 두 가지 결함이 드러났다.

첫째, 픽셀 diff만 쓰면 가짜 증명이 된다. 이미지(스킨) 파일만 바꿔도 레이아웃 구조가 완전히 같은 스타터가 “다르다”는 판정을 받고 통과해버린다. 게이트 자체는 초록불을 내지만, 실제로 원했던 “서로 다른 게임처럼 보이는가”는 검증하지 못한 것이다.

둘째, 지금 잴 수 있는 것과 실제로 원하는 것의 층위가 다르다. 게이트가 지금 확인할 수 있는 건 “스타터 하나가 재테마 가능한 구조인가”뿐이다. “실제로 찍혀나오는 게임들이 서로 다른가”는 아직 존재하지 않는 사용 이력이 쌓여야 확인 가능한, 더 높은 층위의 질문이다.

검증 결과

첫 번째 문제는 측정 축을 분리해서 풀었다. 에셋 파일 집합이 겹치지 않는지(이미지축)와, 패널 배치·HUD 위치·화면비·그리드 같은 구조적 필드가 2개 이상 실제로 다른지(레이아웃축)를 따로 잰다. 검증 순서도 위조시험(fake-test-first)을 먼저 돌렸다 — “동일 레이아웃 스타터 2개를 넣으면 FAIL”, “구조적 필드 1개만 달라도 FAIL”이 되는지 self-test로 먼저 확인한 뒤에야 실제 신작 스타터에 게이트를 적용했다.

두 번째 문제는 코드로 풀 수 있는 게 아니라서, 문서에 “지금은 이걸 재지 않는다”고 명시적으로 적었다. 게이트가 실제로 검증하는 범위보다 과장해서 주장하지 않기 위해서다.

한계와 다음 개선

이 사례를 정리하면서 같은 메커니즘을 다룬 글을 찾아봤다. “Goodhart’s Law Is Now an AI Agent Problem”(tianpan.co, 2026-04)은 AI 에이전트가 평가지표를 목표로 최적화하면 지표를 움직이는 가장 싼 방법을 찾아내고, 실제 품질 개선과는 다른 방향으로 새어나간다고 설명한다. 게이트가 안 재는 축이 반드시 획일화된다는 위 경험과 정확히 같은 구조다.

UI 시각적 회귀 테스트를 다룬 논문 “Beyond Pixel Diffs: Benchmarking Image Change Captioning for Web UI Visual Regression Testing”(arXiv 2607.01728)도 비슷한 지적을 한다. 픽셀 단위 비교만으로는 UI의 구조적 변화를 제대로 포착하지 못하며, 대안으로 변화를 자연어로 캡셔닝하는 접근을 제시한다. “픽셀 diff는 스킨만 갈아도 초록불이 켜진다”는 위 사례의 문제와 같은 지점을 겨냥한다.

두 자료를 같이 보면 결론은 하나로 모인다 — 자동 검증 게이트를 만들 때는 통과시키면 안 되는 가짜 사례를 먼저 만들어 실패시켜보고, 게이트가 검증하지 못하는 범위는 숨기지 않고 문서에 남겨야 한다. 그렇지 않으면 게이트를 통과했다는 사실이 원하는 결과가 나왔다는 증거로 둔갑한다.