현대의 AI 코딩 어시스턴트(AI coding assistants)들은 놀라울 정도로 환각(hallucinations)을 잘 피합니다. 이들은 존재하지 않는 함수를 만들어내지 않으며, 코드베이스(codebase)의 컨벤션(conventions)을 존중하고, 요청된 범위 내에서 작업합니다. 적어도 확립된 워크플로(workflow) 내에서 합리적인 가드레일(guardrails)과 함께 프롬프트(prompted)를 제공했을 때는 말이죠. 하지만 어떤 가드레일도 잡아내지 못하고 자동화된 테스트(automated tests)도 놓치는, 이들이 조용히 만들어내는 일종의 버그 유형이 있습니다. 저는 Claude Code(IDE 내 구현자로서)와 Cowork 모드의 Claude(기획 및 리뷰 동료로서)를 사용하여 개인 프로젝트를 빌드하는 동안 이를 발견했으며, 이는 AI 지원 개발에서의 품질에 대한 제 생각을 바꾸어 놓았습니다.

가드레일의 밝은 면: 성공하는 지점
제가 다듬어 온 워크플로의 상당 부분은 예방(prevention)에 집중되어 있습니다. 일관되게 작동하는 패턴들은 코드 생성(code generation)을 위한 프롬프트 엔지니어링(prompt engineering)에 대해 읽어본 사람이라면 누구에게나 익숙한 것들입니다:
⦁ 사전 읽기 규율(Pre-reading discipline). 무엇인가를 작성하기 전에, 어시스턴트는 관련 파일과 프로젝트의 방법론 문서(methodology docs)를 읽습니다. 이는 출력물을 학습된 사전 지식(trained priors)이 아닌 실제 컨텍스트(context)에 고정시킵니다.
⦁ 허가 없는 새로운 의존성(dependencies) 추가 금지. 작업 중간에 라이브러리(library)를 도입하려면 명시적인 요청이 필요합니다. 이는 코드베이스를 비대하게 만드는 "그냥 X를 추가할게요" 패턴을 차단합니다.
⦁ 범위 규율(Scope discipline). 구현 중간에 발견된 리팩터링(Refactors) 사항은 현재 변경 사항에서 실행되는 대신 나중을 위해 캡처됩니다.
⦁ 의무적인 반박(Mandatory pushback). 요청이 모호할 경우, 어시스턴트는 추측하는 대신 멈추고 질문합니다.
이러한 것들이 갖춰지면 출력물은 깔끔합니다. 컴파일(Compiles)됩니다. 프로젝트 컨벤션(conventions)을 따릅니다. API를 지어내지 않습니다. 2년 전 사람들을 걱정시켰던 종류의 "환각(hallucination)"은 워크플로 수준에서 대체로 해결된 문제입니다.
하지만 "환각을 일으키지 않는다"는 것은 제가 예상했던 것보다 낮은 기준임이 드러났습니다.

가드레일(guardrails)이 있음에도 지속되는 버그들

프로젝트의 UI를 수동으로 클릭하며 확인하던 중, 위에서 언급한 그 어떤 가드레일도 잡아내지 못했을 뿐만 아니라 자동화된 테스트(automated tests)에서는 조용히 '통과(green)' 상태를 유지했던 문제들의 범주를 발견했습니다.

⦁ 컴파일은 정상적으로 되었으나 클릭 시 아무런 동작도 하지 않는 UI 버튼들. 핸들러(handler)는 존재했지만, 그것에 대한 바인딩(binding)이 누락되어 있었습니다.
⦁ 유닛 테스트(unit tests)에서는 작동했지만, 의존성(dependencies)이 DI 컨테이너(DI container)에 등록되지 않아 런타임(runtime)에서 실패하는 다이얼로그(dialogs).
⦁ 한 유형의 사용자에게는 데이터를 반환하지만, 다른 유형의 사용자에게는 에러 메시지 없이 조용히 실패하는 권한 부여(authorization) 경로.

이 중 그 어느 것도 환각(hallucinations)은 아닙니다. 코드는 기술적으로 유효합니다. 컴파일도 됩니다. 컨벤션(conventions)도 따르고 있습니다. 주의 깊은 주니어 개발자가 작성할 법한 종류의 코드입니다. 버그는 레이어(layer) 사이의 이음새(seams) — 즉 UI와 커맨드(command) 사이, 클래스(class)와 DI 등록 사이, 엔드포인트(endpoint)와 소비자(consumer) 사이의 연결부 — 에 존재하며, 각 레이어를 고립시켜 보았을 때는 모두 올바르게 보입니다.

이것이 바로 격차(gap)입니다. 그리고 이 격차는 AI가 코드를 덜 생성할 때가 아니라, 더 많이 생성할수록 점점 더 커집니다.

원인 찾기

테스트는 설계된 목적에 맞는 것들만 잡아냅니다. 유닛 테스트는 고립된 상태의 로직을 검증합니다. 통합 테스트(integration tests)는 엔드포인트가 응답하는지 검증합니다. 보안 리뷰(security reviews)는 취약점을 잡아냅니다. 하지만 이 중 어떤 레이어도 "실제 버튼을 클릭하는 인간이 약속된 결과를 얻는가?"라는 질문을 던지지는 않습니다.

핸들러 바인딩이 없는 버튼은 해당 뷰모델(viewmodel)의 모든 유닛 테스트를 통과합니다. DI 등록이 누락된 다이얼로그는 의존성을 모킹(mock)한 모든 테스트를 통과합니다. 특정 사용자 역할에서 실패하는 엔드포인트는 다른 역할로 인증하는 테스트를 통과합니다.

레이어 사이의 이음새는 자동화된 테스트가 가장 적은 신호(signal)를 얻는 지점입니다. 왜냐하면 각 레이어의 테스트는 서로를 격리하도록 설계되었기 때문입니다.

그렇다면... 이 격차를 어떻게 줄일 수 있을까요?

제가 취한 변화는 테스트를 더 많이 작성하는 것이 아니었습니다. 예방(prevention)과는 구별되는 두 번째 품질 관리(quality control) 범주인 탐지(detection)를 추가하는 것이었습니다.

이제 한 단계가 아닌, 세 단계의 QA가 실행됩니다:

1. 자동화 (Automated). 테스트가 통과되고 보안 검토 (security review)가 깨끗한 상태. 이는 이미 구축되어 있었습니다.
2. 구현자가 아닌 검증자(verifier)에 의한 수동 시각적 엔드 투 엔드 (end-to-end) 테스트. 이것이 핵심적인 추가 사항입니다. 코드를 작성한 에이전트(또는 사람)는 스스로를 검증할 수 없습니다. 확증 편향 (confirmation bias) 때문에 성공을 기대하며 클릭하게 될 것이 자명하기 때문입니다.
3. 유닛 (unit) 또는 스프린트 (sprint) 완료를 선언하기 전, 모든 신규 또는 수정된 컨트롤 (control)에 대한 스모크 테스트 (smoke test). 계획에 나열된 각 컨트롤과, 예상된 동작을 생성하는지 확인된 각 클릭을 검증합니다. "검증자는 구현자가 아니다"라는 규칙이 가장 큰 변화를 가져옵니다. AI 어시스턴트와 함께 단독으로 작업할 때, 인간이 유일하게 유효한 검증자입니다. 그것은 당신이 위임할 수 없는 역할입니다. 실무적으로 이는 이제 계획 발표 시 구현 후 클릭해야 할 모든 UI 컨트롤을 나열해야 하며, 각 컨트롤이 물리적으로 클릭되어 작동이 확인될 때까지 유닛을 종료할 수 없음을 의미합니다. 환각 방지 가드레일 (Anti-hallucination guardrails)은 예방 (prevention)을 담당합니다. 이 두 번째 계층은 탐지 (detection)를 담당합니다. 이들은 중복되는 것이 아니라 상호 보완적입니다.

결론
환각 방지 가드레일은 노이즈를 줄여줍니다. 구현자가 아닌 검증자를 포함한 다단계 QA는 빠져나가는 것들을 잡아냅니다. 두 계층 모두 필요합니다.
AI 어시스턴트가 점점 더 많은 양의 코드를 생성함에 따라, "모든 테스트 통과"를 "배포 준비 완료"로 간주하는 것은 대부분의 AI 지원 워크플로우가 여전히 메워나가고 있는 격차라고 생각합니다. 버그는 AI가 환각을 일으킨 곳에 있는 것이 아닙니다. 버그는 AI가 기술적으로는 정확하지만 연결 부위에서 제대로 맞물리지 않는 코드를 작성했을 때, 그리고 팀의 검증 프로세스가 사용자에게 보이는 결과를 확인하지 않고 초록색 체크 표시만을 신뢰했을 때 발생합니다.
이는 조용한 격차입니다. 하지만 일단 그것을 찾기 시작하면, 어디에나 존재합니다.