저는 LLM(Large Language Model)의 행동 규칙을 자기 조절형 어텐션 큐(self-regulating attention cues)로 전환하는 Claude Code 설정을 구축하는 데 2주를 보냈습니다. 그 과정에서 직관에 반하는 사실을 하나 발견했습니다. 바로 웹 검색이 모델의 사전 학습 메모리(pretraining memory)보다 종종 더 나쁜 코드를 생성한다는 점입니다.

검색이 출력을 오염시키는 세 가지 방식

1. 버전 오염 (Version Pollution)

당신이 "React createRoot 예시"를 검색한다고 가정해 봅시다. 최상단 결과는 ReactDOM.render를 사용하는 2022년 블로그 포스트입니다. 이제 모델은 두 가지 상충하는 신호를 갖게 됩니다. 즉, React 18을 알고 있는 사전 학습(pretraining) 데이터와 이를 모르는 검색 결과 사이의 충돌입니다. 중재 규칙(arbitration rule)이 없다면, 더 최신의 신호가 승리하게 됩니다. 여기서 "최신"이란 "방금 가져온 것"을 의미할 뿐, "더 정확한 것"을 의미하지는 않습니다.

2. 스타일 오염 (Style Pollution)

블로그 코드는 프로덕션(production)용 코드가 아닙니다. 블로그 코드는 정확성보다 가독성을 우선시하며, 에러 처리(error handling)가 생략되거나, 정리(cleanup) 과정이 누락되거나, 값이 하드코딩되어 있는 경우가 많습니다. 검색 결과가 이러한 패턴을 프롬프트 컨텍스트(prompt context)에 주입하면, 모델은 당신이 프로덕션 코드를 요청했을 때조차 블로그 스타일의 코드를 작성하기 시작합니다.

3. 오류 전파 (Error Propagation)

추천수가 300개 달린 그 StackOverflow 답변 말인가요? 채택된 솔루션에는 287명의 투표자가 알아차리지 못한 미묘한 레이스 컨디션(race condition)이 포함되어 있습니다. 모델은 이를 구별할 수 없습니다. 모델은 권위 신호(추천수, 도메인 평판)를 보고 이를 정확성의 보증으로 취급합니다.

신뢰성 체인 (The Reliability Chain)

모든 소스가 동등한 것은 아닙니다. 실제로 효과가 있는 순서는 다음과 같습니다:

공식 소스 코드/문서 (Official source code/docs)
  > 고품질 GitHub 리포지토리 (High-quality GitHub repos)
    > StackOverflow 고득점 답변 (StackOverflow high-vote answers)
...

핵심 통찰: 사전 학습 메모리(pretraining memory)는 중간 단계의 소스입니다. 최고는 아니지만, 당신이 얻게 될 검색 결과의 절반보다는 낫습니다. React, Python 또는 TypeScript에 대한 모델의 내부 지식은 수백만 개의 정확한 예시를 본 결과이며, 이는 단일 검색 쿼리가 따라올 수 없는 신호 대 잡음비(signal-to-noise ratio)를 가집니다.

내가 변경한 것

저는 LLM의 행동 교정(behavior calibration)에 한 줄을 추가했습니다:

SEARCH: docs→official source first · web code→lint-pass before adopt
  · ≥2 independent sources (official/original author exempt)
  · pretraining vs search conflict→newer+authoritative wins

형식이 중요합니다. 이것들은 사람이 보는 규칙이 아닙니다. 1M 컨텍스트 윈도우 (context window)를 가진 모델을 위한 어텐션 큐 (attention-cues)입니다. ·로 구분된 각 절은 하나의 자기 조절 (self-regulation) 지점입니다. 모델은 추론 (inference) 시점에 이를 읽고, 그에 따라 '검색 후 신뢰' (search-then-trust) 행동을 조정합니다.

이것이 해결하지 못하는 것

코드 실행 (code execution)은 "에러가 발생하지 않음"을 검증할 수는 있지만, "정확함"을 검증할 수는 없습니다. npm test를 실행하는 것은 코드가 기존 테스트를 통과한다는 것을 알려줄 뿐입니다. 그것이 로직이 맞는지, 엣지 케이스 (edge cases)가 커버되었는지, 혹은 아키텍처 (architecture)가 타당한지는 알려주지 않습니다. 그 영역은 여전히 인간의 영역입니다.

더 큰 패턴

이 SEARCH 규칙은 제가 LLM 설정을 위해 유지 관리하는 8가지 행동 교정 (behavior-calibration) 규칙 군에 속합니다. 각 규칙은 알려진 베스트 프랙티스 (best practice) (예: "공식 문서를 확인하라", "신뢰하기 전에 검증하라")를 가져와서, 모델이 추론 중간에 참조할 수 있는 가장 밀도 높은 형태로 압축합니다. 이는 시스템 프롬프트 (system prompt)로서가 아니라, 정체성 (identity)과 실행 (execution) 사이에 위치하는 교정 레이어 (calibration layer)로서 작동합니다.

놀라운 점은, 규칙이 작동하기 위해 길 필요는 없다는 것입니다. 단지 적절한 시점에 적절한 위치에 있으면 됩니다. 즉, 모델이 검색 결과의 신뢰 여부를 결정하는 어텐션 윈도우 (attention window) 안에 있으면 됩니다.