Context Degradation 패턴 마스터

AI 모델에게 전달하는 컨텍스트가 많아질수록 오히려 성능이 떨어지는 현상을 다룹니다. 프로덕션 환경에서 발생하는 5가지 주요 패턴과 이를 완화하는 4가지 전략을 실전 사례와 함께 살펴봅니다.

---

목차

1. 박시니어의_실패_사례
2. Lost_in_Middle_Effect
3. Context_Poisoning
4. Distraction_Confusion_Clash
5. 완화_전략_WSCI
6. 실전_사례_분석

---

1. 박시니어의 실패 사례

박시니어 씨는 10년차 시니어 개발자입니다. 최근 회사에서 AI 기반 코드 리뷰 시스템을 프로덕션에 배포했는데, 이상한 일이 벌어지기 시작했습니다.

분명 개발 환경에서는 완벽하게 동작했는데, 실제 운영 환경에서는 AI의 응답 품질이 형편없이 떨어진 것입니다.

Context Degradation은 AI 모델에 제공하는 컨텍스트가 많아질수록 오히려 모델의 성능이 저하되는 현상입니다. 마치 책상 위에 서류가 너무 많으면 정작 필요한 문서를 찾기 어려운 것과 같습니다.

이 현상을 이해하지 못하면 "더 많은 정보를 주면 더 좋은 결과가 나오겠지"라는 잘못된 가정 하에 시스템을 설계하게 됩니다.

다음 코드를 살펴봅시다.

# 박시니어의 프로덕션 코드 - 문제가 된 버전
def review_code(code_snippet: str) -> str:
    # 관련 문서를 최대한 많이 가져옴 (잘못된 접근)
    all_docs = retrieve_all_related_documents(code_snippet)

    # 컨텍스트 윈도우를 꽉 채움
    context = "\n".join([doc.content for doc in all_docs])

    # 정작 중요한 코드는 맨 마지막에 배치
    prompt = f"""
    참고 문서:
    {context}  # 수십 페이지 분량

    리뷰할 코드:
    {code_snippet}  # 정작 중요한 부분
    """
    return call_llm(prompt)

박시니어 씨는 회사에서 인정받는 베테랑 개발자입니다. 새로운 기술 도입에도 적극적인 그는 최근 AI를 활용한 코드 리뷰 자동화 시스템을 구축했습니다.

개발 환경에서 몇 가지 샘플로 테스트했을 때는 결과가 훌륭했습니다. 그런데 프로덕션에 배포하고 일주일 후, 개발팀에서 불만이 쏟아지기 시작했습니다.

"AI가 엉뚱한 부분을 지적해요", "핵심 버그는 못 찾고 사소한 스타일만 언급해요", "가끔 아예 관련 없는 답변을 해요". 박시니어 씨는 당황했습니다.

분명 같은 모델, 같은 프롬프트인데 왜 결과가 다른 걸까요? 원인은 의외로 단순했습니다.

개발 환경에서는 테스트용 작은 코드 조각만 넣었지만, 프로덕션에서는 실제 대규모 코드베이스의 관련 문서들이 함께 전달되었습니다. 박시니어 씨의 시스템은 "더 많은 컨텍스트가 더 좋은 결과를 만든다"는 가정 하에 설계되었습니다.

관련 문서, 이전 리뷰 기록, 코딩 가이드라인 등 모든 정보를 컨텍스트에 담았습니다. 문제는 AI 모델이 이 모든 정보를 동등하게 처리하지 않는다는 것입니다.

컨텍스트 윈도우가 채워질수록 모델은 정보의 우선순위를 잃어버립니다. 마치 시험 전날 교과서 전체를 벼락치기하면 정작 중요한 핵심 개념도 기억나지 않는 것과 같습니다.

특히 박시니어 씨의 코드에서는 정작 리뷰해야 할 코드가 프롬프트의 맨 마지막에 배치되어 있었습니다. 수십 페이지 분량의 참고 문서 뒤에 말이죠.

연구에 따르면 이런 구조에서 모델의 정확도는 10-40%까지 떨어질 수 있습니다. 박시니어 씨는 이 경험을 통해 중요한 교훈을 얻었습니다.

AI 시스템에서는 "얼마나 많은 정보를 주느냐"보다 "어떤 정보를, 어떤 순서로, 얼마나 정제해서 주느냐"가 훨씬 중요하다는 것입니다. 이제부터 Context Degradation의 5가지 주요 패턴을 하나씩 살펴보겠습니다.

각 패턴을 이해하면 박시니어 씨와 같은 실수를 피할 수 있습니다.

실전 팁

💡 - 프로덕션 배포 전 실제 규모의 컨텍스트로 테스트하세요

• 컨텍스트 길이와 응답 품질의 상관관계를 모니터링하세요
• "더 많이"보다 "더 정확히"가 AI 시스템의 핵심입니다

---

2. Lost in Middle Effect

김개발 씨는 RAG 시스템을 구축하던 중 이상한 현상을 발견했습니다. 분명 검색된 문서 중에 정답이 있는데, AI가 자꾸 엉뚱한 답변을 내놓는 것입니다.

검색 결과를 확인해보니 정답은 문서 목록의 중간쯤에 있었습니다.

Lost-in-Middle Effect는 긴 컨텍스트에서 중간에 위치한 정보를 모델이 제대로 활용하지 못하는 현상입니다. 마치 두꺼운 책의 중간 챕터 내용이 잘 기억나지 않는 것처럼, AI 모델도 프롬프트의 처음과 끝 부분에 있는 정보를 더 잘 기억합니다.

이로 인해 10-40%의 정확도 저하가 발생할 수 있습니다.

다음 코드를 살펴봅시다.

# Lost-in-Middle Effect 시연
def demonstrate_lost_in_middle():
    documents = [
        "문서1: 일반적인 파이썬 소개",      # 위치: 처음 (잘 기억됨)
        "문서2: 변수와 자료형",
        "문서3: 조건문과 반복문",
        "문서4: 정답 - API 키는 'sk-abc123'", # 위치: 중간 (놓침!)
        "문서5: 클래스와 객체",
        "문서6: 예외 처리",
        "문서7: 파이썬 모범 사례",           # 위치: 끝 (잘 기억됨)
    ]

    # 해결책: 중요한 정보를 처음이나 끝으로 이동
    reordered = prioritize_by_relevance(documents, query)
    # 또는 가장 관련성 높은 문서만 선별
    top_k = select_top_k(documents, k=3)

김개발 씨는 고객 문의에 자동 응답하는 RAG 시스템을 개발하고 있었습니다. 시스템은 고객 질문과 관련된 문서를 검색해서 AI에게 전달하고, AI가 답변을 생성하는 구조였습니다.

어느 날 고객이 "API 키 발급 방법"을 물었습니다. 시스템은 7개의 관련 문서를 찾아냈고, 그중 4번째 문서에 정확한 답변이 있었습니다.

그런데 AI는 "API 키 발급에 대한 정보를 찾을 수 없습니다"라고 답변했습니다. 김개발 씨는 처음에 검색 엔진이 문제라고 생각했습니다.

하지만 검색 결과를 확인해보니 정답이 분명히 포함되어 있었습니다. 단지 목록의 중간에 있었을 뿐입니다.

이것이 바로 Lost-in-Middle Effect입니다. 2023년 스탠포드 연구에서 처음 체계적으로 밝혀진 이 현상은, 대형 언어 모델이 긴 컨텍스트를 처리할 때 U자 형태의 주의력 분포를 보인다는 것을 발견했습니다.

쉽게 말해, 모델은 프롬프트의 처음 부분과 끝 부분에 있는 정보에 더 집중합니다. 반면 중간에 있는 정보는 상대적으로 덜 주목받습니다.

마치 긴 회의에서 처음과 마지막에 말한 내용만 기억나는 것과 비슷합니다. 이 효과는 컨텍스트가 길어질수록 심해집니다.

10개의 문서에서는 미미할 수 있지만, 20개, 30개로 늘어나면 중간 문서의 정보 활용률은 급격히 떨어집니다. 연구에 따르면 이로 인한 정확도 저하는 **10%에서 최대 40%**까지 발생할 수 있습니다.

특히 정답이 정확히 중간 지점에 있을 때 가장 심각합니다. 해결책은 여러 가지가 있습니다.

가장 간단한 방법은 관련성 순으로 재정렬하여 가장 중요한 문서를 처음에 배치하는 것입니다. 또 다른 방법은 문서 수를 줄이는 것입니다.

7개 전부가 아니라 가장 관련성 높은 3개만 선별하면 Lost-in-Middle 효과를 크게 줄일 수 있습니다. 김개발 씨는 이 사실을 알고 시스템을 수정했습니다.

검색된 문서들을 관련성 점수순으로 재정렬하고, 상위 5개만 컨텍스트에 포함시켰습니다. 그 결과 응답 정확도가 30% 이상 향상되었습니다.

실전 팁

💡 - 가장 관련성 높은 정보를 프롬프트 처음에 배치하세요

• 검색 결과는 관련성 순으로 정렬 후 상위 K개만 사용하세요
• 컨텍스트 길이가 길어질수록 이 효과는 심해집니다

---

3. Context Poisoning

이주임 씨는 채팅봇 시스템에서 이상한 패턴을 발견했습니다. 처음에는 정확했던 AI 응답이 대화가 길어질수록 점점 이상해지는 것입니다.

마치 처음에 했던 작은 실수가 눈덩이처럼 커지는 것 같았습니다.

Context Poisoning은 컨텍스트 내의 잘못된 정보나 오류가 이후 응답에 계속 영향을 미치는 현상입니다. 마치 물에 잉크 한 방울을 떨어뜨리면 전체가 물드는 것처럼, 한 번 주입된 부정확한 정보는 전체 대화의 품질을 오염시킵니다.

특히 피드백 루프가 형성되면 오류가 스스로 증폭됩니다.

다음 코드를 살펴봅시다.

# Context Poisoning 예시 - 피드백 루프
conversation_history = []

def chat(user_input: str) -> str:
    # 위험: 이전 AI 응답(잘못될 수 있음)을 그대로 포함
    context = "\n".join(conversation_history)

    response = call_llm(f"{context}\nUser: {user_input}")

    # AI의 응답을 히스토리에 추가 (오류 포함 가능)
    conversation_history.append(f"AI: {response}")

    return response

# 해결책: 컨텍스트 검증 및 정제
def safe_chat(user_input: str) -> str:
    # 1. 주기적으로 히스토리 요약 및 정제
    context = summarize_and_validate(conversation_history)
    # 2. 핵심 정보만 유지
    context = extract_key_facts(context)
    # 3. 최신 N개 턴만 유지
    context = keep_recent_turns(conversation_history, n=5)

이주임 씨는 고객 상담 챗봇을 운영하고 있었습니다. 어느 날 한 고객과의 대화 로그를 분석하다가 흥미로운 패턴을 발견했습니다.

대화 초반에 AI가 "저희 회사의 반품 기한은 14일입니다"라고 잘못 답변했습니다. 실제로는 30일인데 말이죠.

문제는 그 이후였습니다. 고객이 다른 질문을 해도 AI는 계속 "14일"이라는 틀린 정보를 기준으로 답변했습니다.

"14일 이내에 반품하시면 됩니다", "14일이 지나면 환불이 어렵습니다", "아직 14일이 안 지났으니 가능합니다". 한 번의 실수가 전체 대화를 오염시킨 것입니다.

이것이 Context Poisoning입니다. AI 시스템에서 컨텍스트는 대화의 기억 역할을 합니다.

그런데 이 기억에 잘못된 정보가 들어가면, 마치 바이러스처럼 퍼져나갑니다. 더 심각한 것은 피드백 루프가 형성될 때입니다.

AI의 응답이 다시 컨텍스트에 추가되고, 그 컨텍스트를 바탕으로 다음 응답이 생성됩니다. 만약 잘못된 응답이 컨텍스트에 들어가면, 그것이 다음 응답에 영향을 미치고, 그 응답이 또 컨텍스트에 추가되고...

오류가 스스로를 강화하는 악순환이 시작됩니다. 실제 프로덕션 환경에서 이 문제는 예상보다 자주 발생합니다.

특히 긴 대화에서 두드러집니다. 처음 몇 턴은 괜찮다가 대화가 20턴, 30턴을 넘어가면 응답 품질이 급격히 떨어지는 현상을 보입니다.

해결책은 주기적인 컨텍스트 정제입니다. 이주임 씨는 시스템을 개선했습니다.

첫째, 10턴마다 대화 내용을 요약하여 핵심 정보만 남겼습니다. 둘째, 숫자나 날짜 같은 중요 정보는 원본 데이터베이스와 교차 검증했습니다.

셋째, 최신 5개 턴만 전체 내용을 유지하고 나머지는 요약본으로 대체했습니다. 또 다른 방법은 컨텍스트 리셋입니다.

대화 주제가 바뀌거나 일정 시간이 지나면 컨텍스트를 초기화하는 것입니다. 완전한 초기화가 부담스럽다면 핵심 사실만 추출하여 새로운 컨텍스트로 시작할 수도 있습니다.

Context Poisoning을 예방하려면 "AI의 응답도 틀릴 수 있다"는 전제 하에 시스템을 설계해야 합니다. 신뢰할 수 없는 정보가 컨텍스트를 오염시키지 않도록 방어 장치를 마련하는 것이 중요합니다.

실전 팁

💡 - 긴 대화는 주기적으로 요약하여 컨텍스트를 정제하세요

• 중요한 팩트는 원본 데이터와 교차 검증하세요
• AI 응답을 그대로 재사용하지 말고 검증 후 사용하세요

---

4. Distraction Confusion Clash

최대리 씨는 RAG 시스템의 검색 결과를 보다가 한숨을 쉬었습니다. 하나의 질문에 관련 문서 20개가 검색되었는데, 그중 절반은 주제와 살짝 벗어나고, 일부는 서로 상충되는 내용을 담고 있었습니다.

AI에게 이걸 그대로 줘도 될까요?

Context Degradation에는 세 가지 추가 패턴이 있습니다. Distraction Effect는 관련 없는 정보가 주의를 분산시키는 현상입니다.

Context Confusion은 비슷하지만 다른 여러 개념이 뒤섞여 혼란을 일으킵니다. Context Clash는 상충되는 정보가 존재할 때 모델이 일관성 없는 응답을 생성하는 현상입니다.

다음 코드를 살펴봅시다.

# 세 가지 패턴 예시
def problematic_context():
    # Distraction: 관련 없는 정보가 섞임
    context_distraction = """
    [관련 문서] Python 리스트 메서드
    [비관련] 오늘 날씨가 좋습니다  # 노이즈!
    [관련 문서] 리스트 컴프리헨션
    """

    # Confusion: 비슷한 개념이 혼재
    context_confusion = """
    React의 useState는...
    Vue의 ref는...           # React 질문인데 Vue 정보?
    Angular의 signal은...    # 혼란 가중
    """

    # Clash: 상충되는 정보
    context_clash = """
    [2020년 문서] 타임아웃은 30초로 설정하세요
    [2024년 문서] 타임아웃은 5초가 권장됩니다  # 충돌!
    """

# 해결책
def clean_context(docs, query):
    relevant = filter_by_relevance(docs, threshold=0.7)
    deduplicated = remove_similar_concepts(relevant)
    consistent = resolve_conflicts(deduplicated, prefer="latest")
    return consistent

최대리 씨는 기술 문서 검색 시스템을 개발하고 있었습니다. 개발자가 질문을 하면 관련 문서를 찾아 AI가 답변하는 시스템이었습니다.

어느 날 한 개발자가 "Python에서 리스트를 정렬하는 방법"을 물었습니다. 시스템은 20개의 문서를 검색했습니다.

최대리 씨가 결과를 살펴보니 상황이 복잡했습니다. 먼저 Distraction Effect 문제가 있었습니다.

20개 중 5개는 Python 리스트와 거의 관련이 없는 문서였습니다. "리스트"라는 단어가 포함되어 있어서 검색되었지만, 실제로는 "할 일 리스트 앱 만들기", "이메일 리스트 관리" 같은 내용이었습니다.

이런 노이즈는 AI의 주의력을 분산시킵니다. 정작 중요한 정보에 집중해야 하는데, 관련 없는 정보를 처리하느라 리소스를 낭비하게 됩니다.

다음으로 Context Confusion 문제도 발견되었습니다. Python 정렬 방법을 묻는 질문인데, JavaScript의 sort(), Java의 Collections.sort(), Ruby의 sort 메서드에 대한 문서도 함께 검색되었습니다.

언어마다 문법이 다르고 동작 방식도 조금씩 다릅니다. AI가 이 모든 정보를 받으면 "Python에서는 list.sort()를 사용하고 Java에서는..."처럼 혼란스러운 답변을 생성할 수 있습니다.

가장 심각한 것은 Context Clash였습니다. Python 정렬에 대한 문서 중에서도 버전에 따라 다른 내용이 있었습니다.

오래된 문서는 "key 파라미터 대신 cmp 함수를 사용하세요"라고 하고, 최신 문서는 "cmp는 Python 3에서 제거되었습니다"라고 합니다. 이렇게 상충되는 정보가 있으면 AI는 어떤 것을 따라야 할지 모릅니다.

결과적으로 "cmp를 사용할 수도 있고 key를 사용할 수도 있습니다"같은 모호한 답변이 나옵니다. 최대리 씨는 세 가지 해결책을 적용했습니다.

첫째, 관련성 필터링입니다. 검색 결과 중 관련성 점수가 0.7 이하인 문서는 제외했습니다.

이것만으로도 Distraction Effect를 크게 줄일 수 있었습니다. 둘째, 개념 중복 제거입니다.

비슷한 내용을 다루는 문서가 여러 개 있으면 가장 품질이 좋은 하나만 남겼습니다. 다른 프로그래밍 언어의 문서는 명시적으로 필터링했습니다.

셋째, 충돌 해결 정책입니다. 상충되는 정보가 있을 때는 최신 문서를 우선시하도록 규칙을 정했습니다.

또한 문서의 작성 날짜를 메타데이터로 함께 전달하여 AI가 맥락을 이해할 수 있게 했습니다. 이 세 가지 패턴은 서로 연결되어 있습니다.

컨텍스트에 잡음이 많으면(Distraction) 핵심을 파악하기 어렵고, 비슷한 개념이 뒤섞이면(Confusion) 정확한 답변이 어려우며, 정보가 충돌하면(Clash) 일관성이 무너집니다. 깨끗한 컨텍스트가 좋은 응답의 시작입니다.

실전 팁

💡 - 검색 결과는 관련성 점수로 필터링하세요 (threshold 0.7 이상 권장)

• 질문과 다른 도메인/언어의 문서는 명시적으로 제외하세요
• 날짜 메타데이터를 활용하여 최신 정보를 우선시하세요

---

5. 완화 전략 WSCI

Context Degradation의 다섯 가지 패턴을 알게 된 김개발 씨가 물었습니다. "패턴은 알겠는데, 그래서 어떻게 해결하나요?" 박시니어 씨가 화이트보드에 네 글자를 적었습니다.

Write, Select, Compress, Isolate. 이것이 WSCI 프레임워크입니다.

Context Degradation을 완화하는 네 가지 전략이 있습니다. Write는 컨텍스트를 명확하게 구조화하여 작성하는 것입니다.

Select는 가장 관련성 높은 정보만 선별하는 것입니다. Compress는 정보를 요약하여 밀도를 높이는 것입니다.

Isolate는 다른 유형의 정보를 분리하여 처리하는 것입니다.

다음 코드를 살펴봅시다.

# WSCI 프레임워크 구현
class ContextOptimizer:
    def optimize(self, query: str, documents: list) -> str:
        # 1. SELECT: 관련성 높은 문서만 선별
        selected = self.select_relevant(documents, query, top_k=5)

        # 2. COMPRESS: 각 문서를 핵심만 요약
        compressed = [self.summarize(doc) for doc in selected]

        # 3. ISOLATE: 유형별로 분리
        facts = self.extract_facts(compressed)
        examples = self.extract_examples(compressed)

        # 4. WRITE: 구조화된 컨텍스트 작성
        context = self.write_structured_context(
            query=query,
            facts=facts,      # 핵심 정보 먼저
            examples=examples  # 예시는 뒤에
        )
        return context

    def write_structured_context(self, query, facts, examples):
        return f"""[질문] {query}
[핵심 정보] {facts}
[참고 예시] {examples}"""

박시니어 씨는 팀 세미나에서 WSCI 프레임워크를 소개했습니다. 이것은 Context Degradation을 체계적으로 완화하는 네 가지 전략입니다.

첫 번째 전략: Write (구조화된 작성) 컨텍스트는 아무렇게나 던져주는 게 아닙니다. 마치 좋은 보고서처럼 구조가 있어야 합니다.

핵심 질문을 먼저 제시하고, 관련 정보를 논리적 순서로 배치합니다. 박시니어 씨는 예를 들었습니다.

"보고서를 쓸 때 결론을 맨 뒤에 숨기나요? 핵심을 먼저 말하고 근거를 나열하죠.

프롬프트도 마찬가지입니다." 좋은 구조의 예시는 이렇습니다: [질문] → [핵심 정보] → [보조 정보] → [예시]. 이렇게 하면 Lost-in-Middle 효과를 줄이고 모델이 중요한 정보에 집중할 수 있습니다.

두 번째 전략: Select (선별) "다다익선"은 AI 컨텍스트에서 통하지 않습니다. 오히려 "소수정예"가 맞습니다.

검색된 문서가 100개라도, 정말 관련성 높은 5개만 선별하는 것이 낫습니다. 선별 기준은 여러 가지가 있습니다.

관련성 점수, 문서 품질, 최신성, 신뢰도 등을 종합적으로 고려합니다. 중요한 것은 버리는 용기입니다.

70점짜리 문서 10개보다 95점짜리 문서 3개가 더 좋은 결과를 만듭니다. 세 번째 전략: Compress (압축) 선별된 문서도 그대로 사용하면 너무 깁니다.

10페이지짜리 문서의 핵심은 보통 1페이지로 요약할 수 있습니다. 압축은 단순히 길이를 줄이는 게 아닙니다.

정보 밀도를 높이는 것입니다. 압축 방법은 여러 가지가 있습니다.

LLM을 사용한 요약, 핵심 문장 추출, 키워드 중심 재구성 등입니다. 중요한 것은 질문과 관련된 부분을 중심으로 압축하는 것입니다.

문서 전체를 균등하게 줄이는 게 아니라, 질문에 답할 수 있는 부분을 남기고 나머지를 과감히 버립니다. 네 번째 전략: Isolate (분리) 서로 다른 유형의 정보는 분리해서 처리하는 것이 좋습니다.

예를 들어, 사실 정보와 의견, 최신 정보와 과거 정보, 확실한 정보와 추측을 구분합니다. 분리의 또 다른 형태는 다단계 처리입니다.

복잡한 질문은 여러 단계로 나눠서 처리합니다. 각 단계에서 필요한 컨텍스트만 제공하면 Context Degradation을 최소화할 수 있습니다.

박시니어 씨는 강조했습니다. "WSCI는 순서대로 적용하는 게 아닙니다.

상황에 따라 필요한 전략을 조합하세요. 때로는 Select만으로 충분하고, 때로는 네 가지를 모두 적용해야 할 수도 있습니다." 김개발 씨가 고개를 끄덕였습니다.

"결국 핵심은 '적절한 정보를, 적절한 양으로, 적절한 구조로'네요." "맞아요. 그게 Context Engineering의 본질입니다."

실전 팁

💡 - Write: 중요한 정보일수록 프롬프트 앞쪽에 배치하세요

• Select: 관련성 점수 상위 5개 문서면 대부분 충분합니다
• Compress: 질문 중심으로 문서를 요약하세요
• Isolate: 복잡한 작업은 여러 단계로 나눠 처리하세요

---

6. 실전 사례 분석

이론은 충분히 배웠습니다. 이제 실제 프로덕션 환경에서 Context Degradation을 어떻게 해결했는지 살펴볼 차례입니다.

박시니어 씨는 팀이 운영하는 코드 리뷰 시스템의 개선 사례를 공유했습니다.

실전에서 Context Degradation을 해결하려면 측정, 진단, 개선, 검증의 사이클이 필요합니다. 단순히 이론을 적용하는 것이 아니라, 실제 데이터를 기반으로 어떤 패턴이 문제인지 파악하고, 그에 맞는 전략을 선택해야 합니다.

이 과정에서 A/B 테스트와 메트릭 모니터링이 중요한 역할을 합니다.

다음 코드를 살펴봅시다.

# 실전 Context Degradation 모니터링 시스템
class ContextDegradationMonitor:
    def __init__(self):
        self.metrics = {
            "context_length": [],
            "response_quality": [],
            "position_of_key_info": [],
        }

    def analyze_correlation(self):
        # 컨텍스트 길이와 품질의 상관관계 분석
        correlation = calculate_correlation(
            self.metrics["context_length"],
            self.metrics["response_quality"]
        )

        if correlation < -0.3:  # 음의 상관관계
            print("경고: Context Degradation 감지됨")
            self.diagnose_pattern()

    def diagnose_pattern(self):
        # Lost-in-Middle 진단
        middle_accuracy = self.get_accuracy_by_position("middle")
        edge_accuracy = self.get_accuracy_by_position("edge")

        if edge_accuracy - middle_accuracy > 0.2:
            return "Lost-in-Middle Effect 확인"

        # Context Poisoning 진단
        early_quality = self.get_quality_by_turn("early")
        late_quality = self.get_quality_by_turn("late")

        if early_quality - late_quality > 0.15:
            return "Context Poisoning 의심"

박시니어 씨는 코드 리뷰 시스템의 개선 과정을 처음부터 설명하기 시작했습니다. 1단계: 문제 측정 처음에는 "AI 응답 품질이 안 좋다"는 막연한 불만만 있었습니다.

박시니어 씨는 먼저 객관적인 측정 체계를 구축했습니다. 모든 AI 응답에 대해 컨텍스트 길이, 응답 시간, 사용자 만족도(1-5점), 응답의 정확성(사람이 검토)을 기록했습니다.

2주간의 데이터를 분석한 결과, 놀라운 패턴이 발견되었습니다. 컨텍스트가 4000 토큰 이하일 때 평균 만족도는 4.2점이었지만, 8000 토큰을 넘어가면 3.1점으로 떨어졌습니다.

컨텍스트 길이와 품질 사이에 명확한 음의 상관관계가 있었습니다. 2단계: 패턴 진단 단순히 "컨텍스트가 길면 안 좋다"는 것만으로는 해결책을 찾기 어렵습니다.

어떤 패턴이 주요 원인인지 파악해야 했습니다. 박시니어 씨는 추가 분석을 진행했습니다.

핵심 정보의 위치별 정확도를 측정했더니, 프롬프트 시작 부분에 정보가 있을 때 정확도가 85%, 중간에 있을 때 62%, 끝에 있을 때 78%였습니다. 전형적인 Lost-in-Middle Effect였습니다.

또한 긴 대화에서 후반부 응답 품질이 떨어지는 패턴도 발견했습니다. 이것은 Context Poisoning의 징후였습니다.

3단계: 전략 적용 진단 결과를 바탕으로 WSCI 프레임워크를 적용했습니다. Lost-in-Middle을 해결하기 위해 Write 전략을 적용했습니다.

프롬프트 구조를 재설계하여 리뷰할 코드를 맨 앞에, 참고 문서를 그 뒤에 배치했습니다. 기존에는 참고 문서가 앞에, 코드가 뒤에 있었습니다.

Context Poisoning을 해결하기 위해 Compress 전략을 적용했습니다. 이전 리뷰 기록은 전체가 아닌 요약본만 포함했습니다.

또한 5턴마다 컨텍스트를 정제하도록 했습니다. 전체적인 컨텍스트 길이를 줄이기 위해 Select 전략을 적용했습니다.

검색되는 관련 문서를 최대 10개에서 5개로 제한하고, 관련성 점수 0.8 이상만 포함하도록 했습니다. 4단계: 결과 검증 개선된 시스템을 2주간 운영한 후 다시 측정했습니다.

평균 컨텍스트 길이는 7200 토큰에서 3800 토큰으로 줄었습니다. 평균 만족도는 3.4점에서 4.3점으로 상승했습니다.

응답 정확도도 71%에서 86%로 개선되었습니다. 박시니어 씨는 결론을 내렸습니다.

"Context Degradation은 피할 수 없습니다. 하지만 측정하고, 진단하고, 적절한 전략을 적용하면 충분히 완화할 수 있습니다.

중요한 것은 추측이 아닌 데이터 기반의 접근입니다." 김개발 씨가 정리 노트를 덮으며 말했습니다. "이제 왜 '더 많은 컨텍스트'가 답이 아닌지 확실히 알겠어요.

앞으로는 '더 나은 컨텍스트'를 고민해야겠네요." "맞아요. 그게 바로 Context Engineering의 핵심입니다."

실전 팁

💡 - 반드시 기준 메트릭을 먼저 측정하세요 (개선 전 상태 파악)

• A/B 테스트로 각 전략의 효과를 검증하세요
• 지속적인 모니터링 체계를 구축하세요 (Context Degradation은 언제든 재발할 수 있습니다)

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!