커버리지 저하 (Coverage decay): 스타일 프롬프트가 스스로를 잊어버릴 때

긴 LLM 출력물에서 추론 구조를 안정화하기

저자: Nic Omolabi

형식: 기술 기사 / 재현 프로토콜 (reproducibility protocol)

날짜: 2026년 5월

GitHub 저장소: PROMETHEUS-74/cogito-coverage-decay

요약 (Executive summary)

대규모 언어 모델 (LLM)은 항상 한꺼번에 실패하지 않습니다. 종종 점진적으로 실패합니다.

첫 번째 문단은 당신의 지침을 따릅니다. 두 번째 문단은 여전히 당신이 요청한 구조와 유사합니다. 세 번째 문단에 이르면 답변이 느슨해지기 시작합니다. 다섯 번째 문단에 이르면, 답변은 유능하고 유창하며 일반적인(generic) 수준이 되어버립니다.

이것은 지식의 문제가 아닙니다. 모델은 정답을 알고 있을 수도 있습니다. 심지어 당신의 선호도 알고 있을 수도 있습니다. 실패의 원인은 일관성(consistency)입니다. 즉, 당신이 요청한 추론 구조 (reasoning structure)가 전체 응답 과정 동안 유지되지 않는 것입니다.

나는 이를 **커버리지 저하 (coverage decay)**라고 부릅니다.

이 기사에서 **커버리지 (coverage)**는 추론 패턴과 관련된 구조적 표식(structural markers)의 존재를 의미합니다: 인과 관계 설명 (causal explanation), 예외 사례 식별 (edge-case identification), 구체화 (concretisation), 분해 (decomposition), 그리고 운영적 추론 (operational reasoning) 등이 이에 해당합니다. 이는 추론 자체에 대한 직접적인 측정값이 아니라, 구조적 지속성 (structure persistence)을 나타내는 실질적인 대리 지표 (proxy)입니다.

커버리지 저하가 중요한 이유는 가장 가치 있는 AI 출력물이 단 한 문단의 답변인 경우가 드물기 때문입니다. 그것들은 보고서, 기술적 설명, 설계 문서, 연구 노트, 운영 분석, 정책 논거, 제품 계획, 그리고 장문 추론 작업들입니다. 이곳들이 바로 구조가 가장 중요하게 작용하는 지점이며, 동시에 스타일 프롬프트 (style prompts)가 누수되기 시작하는 바로 그 지점입니다.

Cogito는 이러한 드리프트 (drift)를 줄이기 위한 경량 제어 루프 (control loop)입니다. 한 번 생성하고 지침이 유지되기를 바라는 대신, 다음과 같은 간단한 사이클을 실행합니다:

생성 (generate) -> 평가 (evaluate) -> 비판 (critique) -> 개선 (refine)

목표는 거창한 철학적 의미에서 모델이 "인간처럼 생각하게" 만드는 것이 아닙니다. 목표는 더 좁고 유용한 것입니다: 요청된 추론 구조가 답변 전체에 걸쳐 유지되도록 하는 것입니다.

이 글은 실패 모드(failure mode)인 Cogito 메커니즘과, 반복적인 선호도 적용(iterative preference application)이 시스템 프롬프트(system prompt) 단독 사용보다 추론 구조(reasoning structure)를 더 잘 안정화하는지 테스트하기 위해 설계된 재현 가능한 실험을 설명합니다.

핵심 주장은 거창하기보다 정밀합니다:

이 글은 긴 형태의 LLM 출력에서 측정 가능한 실패 모드로서 커버리지 저하(coverage decay)를 소개하고, 이를 줄이기 위한 실용적인 프롬프팅 계층(prompting-layer) 방법론인 Cogito를 제시합니다.

이 메커니즘은 한 줄로 요약될 수 있습니다:

시스템 프롬프트는 선호도(preference)를 기술합니다. Cogito는 선호도를 적용합니다. 커버리지 추적(coverage tracking)은 선호도가 유지되었는지 확인합니다.

기여 사항 (Contributions)

이 글은 세 가지 기여를 합니다:

요청된 추론 구조가 초반에는 나타나지만 뒤로 갈수록 약화되는 현상, 즉 긴 형태의 LLM 출력에서 발생하는 실질적인 실패 모드로서 **커버리지 저하 (coverage decay)**를 식별합니다.
생성(generate) -> 평가(evaluate) -> 비판(critique) -> 개선(refine) 반복을 통해 해당 저하를 줄이도록 설계된 프롬프팅 계층 제어 루프인 Cogito를 소개합니다.
문단 위치에 따른 **구조적 지속성 (structure persistence)**을 측정하고, Cogito를 일반(vanilla) 및 시스템 프롬프트 베이스라인과 비교하기 위한 재현 가능한 프로토콜을 정의합니다.

1. 문제점: 긴 답변의 표류 (long answers drift)

대부분의 프롬프트 개인화(prompt personalisation)는 처음 접했을 때는 설득력 있게 느껴집니다.

모델에게 다음과 같이 지시합니다:

결론을 내리기 전에 메커니즘을 설명하세요. 예외 사례(edge cases)를 포함하세요. 구체적으로 작성하세요. 모호한 비유는 피하세요. 운영상의 시사점(operational implications)을 보여주세요.

모델은 강력한 도입부와 함께 응답합니다. 메커니즘을 설명합니다. 한두 가지 실패 모드를 언급합니다. 지시 사항을 이해한 것처럼 보입니다.

하지만 답변이 길어지면 다른 행동이 드러납니다. 모델은 종종 요청된 구조로 시작하지만, 점차 유창하고 일반적인 기본 레지스터(default register)로 돌아가며 느슨해집니다. 후반부 문단들도 여전히 유용하긴 하지만, 처음에 요청했던 특정 추론 패턴을 더 이상 유지하지 않습니다.

이것이 바로 **초기 준수 (initial compliance)**와 구조적 지속성 (structural persistence) 사이의 간극입니다.

일반적인 시스템 프롬프트 (system prompt)는 사용자의 선호도를 인코딩할 수 있습니다. 하지만 그 자체만으로는 답변 전체에 걸쳐 해당 선호도가 활성 상태로 유지되는 것을 보장하지 못합니다. 문제는 단순히 모델이 지시 사항을 따를 수 있느냐가 아닙니다. 문제는 모델이 여러 단락에 걸친 출력물 전체에서 구조를 지속할 수 있느냐 하는 것입니다.

이것이 바로 이 프로젝트의 이면에 있는 실질적인 실패 모드 (failure mode)입니다.

제가 Cogito를 구축한 이유는 AI 시스템이 제가 사고하는 방식과 더 유사하게 응답하기를 원했기 때문입니다. 즉, 인과적 (causal)이고, 예외 상황 (edge-case)을 인지하며, 구체적 (concrete)이고, 실행 가능하며 (operational), 분해적 (decompositional)이고, 아이디어가 어디서 무너지는지를 기꺼이 검토하는 방식입니다. 시스템 프롬프트는 그러한 선호도를 기술할 수는 있습니다. 하지만 이를 안정적으로 유지할 수는 없었습니다.

나중에 설명할 실험은 다음과 같은 간단한 질문을 던집니다.

긴 LLM 출력물에 걸쳐 추론 구조를 안정화할 수 있는가?

2. Cogito란 무엇인가

Cogito는 긴 형식의 LLM 출력물을 위한 프롬프팅 계층 제어 루프 (prompting-layer control loop)입니다.

일반적인 시스템 프롬프트는 사용자가 선호하는 추론 스타일을 한 번 기술합니다. Cogito는 해당 선호도를 명시적으로 만들고, 생성된 답변에 여전히 그 선호도가 포함되어 있는지 확인하며, 구조가 약해질 때 답변을 비판 (critique)하고, 모델에게 수정을 요청합니다.

이는 미세 조정 (fine-tuning)을 필요로 하지 않습니다. 모델의 가중치 (weights)를 변경하지도 않습니다. 추론을 직접 측정한다고 주장하지도 않습니다. 대신 실질적인 대리 지표 (proxy)를 사용합니다. 즉, 사용자가 선호하는 추론 패턴의 구조적 표식 (structural markers)이 답변 전체에 걸쳐 지속되는지 여부를 확인합니다.

메커니즘은 간단합니다:

1. 초기 답변을 생성한다.
2. 선호하는 추론 패턴의 커버리지 (coverage)를 측정한다.
3. 가장 강력한 선호도에 따라 답변을 비판한다.
...

중요한 차이점은 Cogito가 더 나은 시스템 프롬프트를 가지고 있다는 것이 아닙니다. 차이점은 Cogito가 생성을 단발성 이벤트 (one-shot event)로 취급하지 않는다는 것입니다. Cogito는 선호도 적용을 하나의 루프 (loop)로 전환합니다.

작동 가설은 긴 형식의 개인화 (personalisation)에는 세 가지 요소가 필요하다는 것입니다:

Encoding (인코딩): 사용자가 선호하는 추론 패턴 (reasoning patterns)을 명시적으로 표현합니다.
Application (적용): 해당 패턴이 약해질 때 모델이 이를 수정하도록 강제합니다.
Verification (검증): 응답 전반에 걸쳐 해당 패턴이 지속되는지 측정합니다.

대부분의 프롬프트 기반 개인화 (personalisation)는 첫 번째 단계에서 멈춥니다. Cogito는 두 번째와 세 번째 단계를 추가합니다.

3. 구체적인 예시

아래 예시는 설명용입니다. 이는 이 실험이 테스트하도록 설계된 동작을 보여줍니다. 최종 공개 버전에서는 이 섹션이 스모크 테스트 (smoke test)의 로그 출력값으로 교체되거나 보완되어야 합니다.

프롬프트 선호도 (Prompt preference)

사용자는 프로젝트가 커짐에 따라 빌드 시스템이 왜 느려지는지에 대한 설명을 요청합니다. 개인화 지침은 다음과 같습니다:

결론을 내리기 전에 메커니즘을 설명할 것. 예외 사례 (edge cases)를 포함할 것. 구체적일 것. 운영상의 영향 (operational implications)을 보여줄 것.

표준 시스템 프롬프트 동작 (Standard system-prompt behaviour)

첫 번째 문단은 종종 지침에 부합하는 것처럼 보입니다:

빌드 시스템이 느려지는 이유는 의존성 그래프 (dependency graphs)가 확장되고, 캐시 무효화 (cache invalidation)가 어려워지며, 작은 변경 사항이 대규모 재빌드를 유발하기 시작하기 때문입니다. 근본적인 메커니즘은 단순히 "더 많은 코드"가 아니라, 의존성 해결 (dependency resolution), 파일 와칭 (file watching), 컴파일 경계 (compilation boundaries), 그리고 캐시 정확성 (cache correctness) 사이의 관계입니다.

이는 강력한 시작입니다. 결론 전에 메커니즘을 설명하고 있습니다.

하지만 뒷부분의 문단으로 넘어가면서 답변이 벗어날 수 있습니다:

이를 해결하기 위해 팀은 도구를 개선하고, 빌드 프로세스를 검토하며, 적절한 곳에 캐싱을 사용하고, 의존성을 관리 가능한 수준으로 유지해야 합니다. 정기적인 유지보수와 좋은 엔지니어링 관행은 마찰을 줄이고 개발자 생산성을 높이는 데 도움이 될 수 있습니다.

두 번째 문단이 틀린 것은 아닙니다. 다만 일반적일 뿐입니다. 예외 사례 (edge cases)는 사라졌습니다. 운영상의 영향 (operational implications)은 모호합니다. 프롬프트가 요청한 구조가 유지되지 않았습니다.

Cogito 스타일 동작 (Cogito-style behaviour)

Cogito로 정제된 답변은 응답의 더 깊은 부분까지 구조를 보존해야 합니다:

실패 모드는 보통 컴파일러가 갑자기 느려지는 것이 아닙니다. 빌드 그래프 (build graph)가 개발자가 변화가 격리되어 있다고 생각하는 방식과 일치하지 않게 되는 것입니다. 경계 (boundaries)가 너무 거칠면, 공유 모듈에서의 한 줄 변경이 수십 개의 다운스트림 타겟 (downstream targets)을 무효화할 수 있습니다. 캐싱 (Caching)은 캐시 키 (cache key)가 안정적이고 의존성 그래프 (dependency graph)가 정확할 때만 도움이 됩니다. 생성된 파일, 환경 변수, 타임스탬프 (timestamps), 또는 암시적 의존성 (implicit dependencies)이 포착되지 않을 때 캐싱은 실패합니다. 따라서 운영상의 해결책은 단순히 일반적인 의미에서 "캐싱을 추가하라"가 아닙니다. 무효화 경로 (invalidation paths)를 측정하고, 큰 타겟을 분할하며, 숨겨진 의존성을 제거하고, 어떤 파일이 불균형적으로 큰 재빌드 (rebuilds)를 유발하는지 추적하는 것입니다.

차이점은 유창함이 아닙니다. 두 답변 모두 유창합니다.

차이점은 **구조적 지속성 (structure persistence)**입니다. 두 번째 답변은 인과 관계 메커니즘 (causal mechanism), 예외 사례 (edge cases), 그리고 운영상의 결과 (operational consequences)가 문단 전체에 걸쳐 사라지지 않도록 유지합니다.

베이스라인 (baseline)에서는 예외 사례 및 운영상의 추론이 도구 개선, 캐싱 사용, 의존성 유지와 같은 광범위한 조언으로 붕괴됩니다. Cogito 스타일의 답변에서는 이러한 패턴들이 활성 상태로 유지됩니다: 숨겨진 의존성, 불안정한 캐시 키, 생성된 파일, 타임스탬프, 무효화 경로, 그리고 측정 절차 등이 모두 가시적으로 남아 있습니다.

그것이 바로 Cogito가 안정화시키고자 하는 것입니다.

4. 이것이 중요한 이유

커버리지 저하 (Coverage decay)는 일상적인 대화에서는 놓치기 쉽지만, 긴 형식의 작업 (long-form work)에서는 비용이 많이 들게 됩니다.

AI 어시스턴트가 기술 보고서를 초안 작성하고 있다면, 문제는 그가 그럴듯한 서론을 작성할 수 있느냐가 아닙니다. 문제는 문서의 중간과 끝까지 요청된 구조를 유지할 수 있느냐입니다.

이는 다음과 같은 여러 실제 맥락에서 중요합니다:

기술 문서 작성 (Technical writing): 메커니즘과 예외 상황 (edge cases)이 명시적으로 유지되어야 하는 경우.
연구 보조 (Research assistance): 유창함보다 논증 구조가 더 중요한 경우.
운영 분석 (Operational analysis): 권장 사항에 구체적인 실패 모드 (failure modes)가 포함되어야 하는 경우.
제품 기획 (Product planning): 지속적인 트레이드오프 (trade-off) 추론에 따라 의사결정이 내려지는 경우.
경영진 보고 (Executive reporting): 일반적인 요약이 의사결정자에게 필요한 세부 사항을 가리는 경우.
학습 및 튜터링 (Learning and tutoring): 학생이 단편적으로 잘 쓰인 문단보다 일관된 설명 구조로부터 도움을 받는 경우.

출력이 길어질수록 구조 유지 (structure persistence)의 가치는 더욱 커집니다.

짧은 답변의 경우 시스템 프롬프트 (system prompt)만으로 충분할 수 있습니다. 하지만 긴 답변의 경우, 모델은 생성이 시작된 후 요청된 구조가 여전히 유지되고 있는지 확인할 수 있는 방법이 필요합니다.

이것이 바로 핵심 질문이 단순히 "모델이 내 스타일을 따를 수 있는가?"가 아닌 이유입니다.

더 나은 질문은 다음과 같습니다:

모델이 답변의 시작부터 끝까지 요청된 추론 구조를 유지할 수 있는가?

5. 상세 메커니즘

Cogito는 사용자의 추론 선호도를 가중치가 부여된 인지 프로필 (cognitive profile)로 나타냅니다.

재구성된 엔진은 10개의 추론 패턴 연산자 (reasoning-pattern operators)를 사용합니다:

연산자 (Operator)	이 실험에서의 의미
causal	메커니즘, 원인, 결과, 그리고 어떤 일이 발생하는 이유를 설명함.
...

샘플 프로필은 다음과 같을 수 있습니다:

{
  "causal": 0.90,
  "edge_cases": 0.85,
...

이 프로필은 심리학적 의미에서 인지 (cognition)를 완전히 포착한다고 주장하는 것이 아닙니다. 이는 생성된 텍스트 내의 구조적 선호도를 실용적으로 표현한 것입니다.

5.1 생성 (Generation)

Cogito는 먼저 모델에게 전체 인지 프로필을 제공합니다. 이를 통해 모델이 시스템 프롬프트 (system-prompt) 기준점과 동일한 선호도 정보를 갖도록 보장합니다.

5.2 커버리지 점수 산정 (Coverage scoring)

초기 답변이 생성된 후, Cogito는 프로필을 기준으로 답변의 점수를 매깁니다. 현재의 탐지기는 정규 표현식 (regex) 기반입니다. 예를 들어, causal 연산자는 다음과 같은 어휘적 표식 (lexical markers)을 찾습니다:

r"\b(because|causes?|due to|results? in|leads? to|mechanism|why)\b"
r"\b(underlying|fundamental|root cause)\b"

이는 의도적으로 단순하며 검사 가능하도록 설계되었습니다. 또한 제한적이기도 합니다. 이는 추론 (reasoning) 자체를 측정하는 것이 아니라, 스타일 표식 (style-marker)의 지속성을 측정합니다.

5.3 비판 (Critique)

커버리지 (coverage)가 목표 임계값 (threshold) 미만인 경우, 모델은 사용자의 가장 강력한 선호도를 통해 답변을 비판하도록 요청받습니다:

인과 추론 (causal reasoning)이 약화된 부분은 어디인가?
언급되었으나 분석되지 않은 엣지 케이스 (edge cases)는 무엇인가?
선호되는 패턴 중 비중이 낮은 것은 무엇인가?

비판은 답변을 다시 작성하지 않습니다. 대신 답변이 요청된 구조를 놓친 지점을 식별합니다.

5.4 개선 (Refinement)

그 후 모델은 비판 내용을 사용하여 답변을 수정합니다. 수정된 답변은 다시 점수가 매겨집니다 (rescored). 만약 커버리지가 개선되었다면, 그것이 새로운 작업 답변 (working answer)이 됩니다. 만약 퇴보했다면, 이전 답변이 작업 답변으로 유지됩니다.

이 루프는 답변이 목표 임계값에 도달하거나 최대 반복 횟수에 도달할 때까지 계속됩니다.

요약하자면:

system prompt = 선호도 기술 (preference description)
Cogito = 선호도 기술 (preference description) + 비판 루프 (critique loop) + 커버리지 확인 (coverage check)

6. 실험

이 실험은 Cogito가 시스템 프롬프트 (system prompt)만 사용하는 것보다 긴 출력물에 대해 추론 구조를 더 효과적으로 안정화할 수 있는지 테스트합니다.