← 목차

Context Window 위생과 실전 체크리스트 · 퀴즈

7 문항 · Bloom: Remember:1, Understand:3, Apply:1, Analyze:1, Create:1

Q1 Understand mcq_single

Context Rot을 한 문장으로 가장 정확히 설명한 것은?

정답: B
Context Rot은 '토큰은 늘어나는데 신호는 줄어든다'는 역설적 상태 — 즉 SNR 저하로 정의된다. 단순한 token limit 초과나 tool stale, memory compaction 실패와는 구분되는 개념이다.
오답 해설:
  • A. 흔한 오해: context window overflow와 혼동. rot은 한계 미만에서도 발생한다.
  • C. tool description의 노후화는 별개 이슈이며 rot의 정의가 아니다.
  • D. compaction 유실은 memory 전략의 실패 모드일 뿐, rot의 본질은 SNR 저하다.
Q2 Remember mcq_multi

class에서 소개한 Context Rot의 '4대 대표 증상'에 해당하는 것을 모두 고르시오. (정답 4개)

정답: A, B, C, D
S4.C1에서 제시한 4대 증상은 중복 few-shot, stale memory, 과잉 tool 노출, 대화 잔해다. E의 embedding 차원은 retrieval 설계 이슈로 rot 증상 목록에는 포함되지 않는다.
오답 해설:
  • E. retrieval 품질 문제와 rot 증상을 혼동한 오답. rot은 '이미 들어와 자리만 차지하는 토큰' 문제다.
Q3 Analyze mcq_single

다음 로그 스니펫에서 '3색 라벨 루브릭(working/reference/noise)'을 적용할 때 가장 먼저 제거해야 할 항목은? [system] 역할·금지사항·출력 포맷 정의 [memory] 2026-04-21: plan A 채택 [memory] 2026-04-21: plan A 취소, plan B로 변경 [memory] 2026-04-22: plan B 실행 중 [user] 현재 plan B의 3단계에서 에러가 났습니다. 원인 분석 부탁해요.

정답: B
'plan A 채택' 줄은 바로 다음 줄에서 취소된 상태 — 전형적 stale memory(noise, 빨강)다. system prompt는 reference(노랑), 현재 plan B 상태와 user 질문은 working(초록)으로 유지해야 한다.
오답 해설:
  • A. system prompt는 reference 토큰으로 유지 대상이다.
  • C. 현재 실행 중인 plan은 working 토큰 — 지금 결정에 직접 쓰인다.
  • D. user의 현재 질문은 가장 핵심적인 working 토큰이다.
Q4 Apply mcq_single

다음 네 개의 anti-pattern 수정안 중, '우선순위 = impact × 1/난이도' 기준으로 가장 먼저 적용해야 하는 것은?

정답: A
A는 impact(−3.5k noise 제거, 정확도 개선 기대)가 크고 난이도(10분)가 매우 낮아 우선순위 점수가 가장 높다. B는 impact는 있으나 난이도가 커 후순위, C·D는 impact 자체가 불명확하거나 미미하다.
오답 해설:
  • B. impact는 있으나 3일 재인덱싱 비용이 커 우선순위에서 밀린다.
  • C. '친근한 톤'은 정확도 impact가 검증되지 않은 취향 작업이다.
  • D. 포맷 마이그레이션은 정확도와 무관한 형태 변경 — impact가 거의 0이다.
Q5 Understand true_false

참/거짓: "참조되지 않는 토큰은 모델에 중립적이므로, 의심스러우면 일단 context에 넣어두는 편이 안전하다."

정답: B
거짓이다. note의 '흔한 실수'에서 강조하듯 참조되지 않는 토큰은 중립이 아니라 **능동적 방해물**이다. 모델의 attention이 분산되며, 이것이 rot의 출발점이 된다. '다 넣어두면 언젠가 쓰이겠지'는 대표적 오개념.
오답 해설:
  • A. 흔한 오개념: '넣어둬서 나쁠 건 없다'. 실제로는 attention 분산과 SNR 저하로 성능이 떨어진다.
Q6 Understand mcq_single

다음 중 '배포 전 리뷰 게이트로 기능하는 좋은 체크리스트 항목'에 가장 가까운 것은?

정답: C
좋은 체크리스트 항목은 (1) 답이 명확하고 (2) 5분 안에 확인 가능하며 (3) 'No'가 나오면 바로 수정 액션으로 이어진다. C는 Yes/No로 판정 가능하고 로그로 5분 내 확인 가능하며, Yes면 곧장 tool 삭제 액션으로 이어진다. A·B·D는 설명문/지침문이라 리뷰 판정이 불가능하다.
오답 해설:
  • A. '명확해야 한다'는 지침일 뿐 — Yes/No 판정이 불가능하다.
  • B. '잘 관리할 것'은 기준이 모호해 Needs review로만 귀결된다.
  • D. '유의한다'는 추상적 권고 — 구체적 확인 동작으로 이어지지 않는다.
Q7 Create short_answer

당신의 프로젝트(또는 가상의 '고객 문의 자동 응답 에이전트')를 상정하고, **Tool 목록 블록**에 들어갈 체크리스트 질문 한 줄을 직접 작성하시오. 조건: (1) Yes/No/Needs review로 답할 수 있는 질문 형태, (2) 5분 안에 확인 가능한 검증 동작이 떠올라야 하며, (3) S4.C1에서 배운 anti-pattern(중복 few-shot·stale memory·과잉 tool 노출·대화 잔해) 중 최소 하나를 걸러낼 수 있어야 한다. 답안에는 작성한 질문 한 줄과, 그 질문이 어떤 anti-pattern을 어떻게 걸러내는지 1~2문장 해설을 함께 제출하시오.

모범 답안 예시: "각 tool의 description을 읽고 호출 시점이 혼동 없이 결정되는가? (Yes / No / Needs review)" — 이 질문은 과잉 tool 노출과 중복/모호한 tool을 동시에 걸러내며, description을 순서대로 읽어보는 것만으로 5분 내 판정 가능하다. 다른 예: "최근 30일간 한 번도 호출되지 않은 tool이 남아 있는가?" → 과잉 tool 노출 제거로 직결.채점 기준:
  • total_points
  • criteria
  • pass_threshold
  • common_failure_modes