당신의 캐시 히트율은? CDN·캐싱·이미지/동영상 서빙 파이프라인 퀴즈
매일 쓰지만 정확히는 모르는 것들을 물어봅니다. 예를 들어 no-cache가 실제로 무슨 뜻인지, 304가 왜 공짜가 아닌지, 코덱과 컨테이너가 어떻게 다른지를 묻습니다.
→ 퀴즈 풀어보기
대부분의 객관식 퀴즈는 학습 도구가 아니라 소거법 연습입니다. 오답 보기가 허술하면 내용을 몰라도 "제일 길고 그럴듯한 것"을 골라 맞힐 수 있기 때문입니다.
cachehit은 그 문제를 설계 단계에서 막았습니다.
모든 오답은 실제 오개념에서 가져옵니다. 즉석에서 지어낸 보기는 쓰지 않습니다. 주제별 오개념 원장을 먼저 만들고, 문항의 오답은 거기서 가져와 씁니다. 각 오답에는 어떤 유형의 오해인지 태그가 붙습니다: 인접 개념 치환, 방향 반전, 과잉 일반화, 한 단계 부족한 답, 벤더 혼동, 시대 지난 정답, 그럴듯한 수치.
핵심 게이트는 하나입니다. "이 보기를 고른 사람은 무엇을 오해한 것인가"를 한 문장으로 쓸 수 없으면 그 보기는 버립니다. 통과하면 그 문장이 곧 오답 해설이 됩니다.
근거는 실제로 열리는 링크입니다. 각 문항의 source 텍스트는 data/sources.json 레지스트리와 RFC 표기 규칙을 거쳐 원문 링크가 됩니다. tools/check-links.mjs가 그 URL에 전부 실제로 요청을 보내 확인합니다. 죽은 링크는 화면에서 지어낸 근거와 구분되지 않기 때문입니다. 봇을 막는 사이트(Medium·ISO)의 403은 실패로 세지 않고, 연결 오류는 curl로 한 번 더 확인합니다(측정해 보니 itu.int와 ijg.org는 curl에서는 200인데 Node fetch에서는 ETIMEDOUT이었습니다. fetch만 믿었으면 멀쩡한 링크 둘을 지웠을 겁니다).
링크가 열리는 것과 그 문서가 주장을 뒷받침하는 것은 다릅니다. 후자가 훨씬 치명적인 결함입니다. 클릭 한 번으로 드러나고, 하나가 드러나면 나머지 인용 전체의 신뢰가 같이 떨어집니다. 그래서 인용을 두 가지 방법으로 검사합니다. 하나는 tools/check-rfc-sections.mjs로, RFC 절 번호와 괄호에 적은 이름을 원문 목차와 대조합니다. 이 검사를 만든 당일에 46개 인용 중 9개가 틀려 있었습니다: Vary를 RFC 9110 §12.5.5가 아니라 §12.5.1(실제 제목 "Accept")로 적은 문항 세 건, If-Range를 §13.1.4(실제 "If-Unmodified-Since")로, stale-if-error를 RFC 5861 §4가 아니라 §3(실제는 stale-while-revalidate)로 적은 것 등입니다. 다른 하나는 사람이 하는 대조인데, 이 검사로 잘 알려진 출처를 인용해 두었지만 그 문서가 주장을 뒷받침하지 않는 인용 13건을 지웠습니다(AWS 개념인 Origin Shield를 GCP 발표 자료로 인용한 것, 배포 카나리 사실을 CDN 페일오버 근거로 인용한 것 등). 지우는 비용은 거의 들지 않았습니다. 벤더 문서가 이미 진짜 근거였기 때문입니다.
기계가 검사합니다. tools/validate.mjs가 길이 편향(정답이 오답 평균의 1.4배 초과), "위의 모든 것"류 보기, 문법 단서, 절대 표현 편중, 정답 위치 편중, 부정형 발문 과다, 오답 유형 단일화, 그리고 발문이 결함을 전제하는데 "문제 없다"고 답해 읽자마자 소거되는 보기를 자동으로 잡아냅니다. 통과하지 못하면 빌드되지 않습니다.
기계로 안 잡히는 것은 블라인드 감사로 잡습니다. 정답과 해설을 제거한 세트를 만들어(tools/blind.mjs) 다른 모델에게 풀게 하고, 문항마다 **"지식 없이 요령만으로 답을 고를 수 있었나"**를 묻습니다. 1차 감사에서 77문항 중 40건이 지목됐고, 그중 진짜 결함은 16건이었습니다. "보기가 발문과 모순되어 소거됐다"는 지적은 그 모순을 알아채는 데 도메인 지식이 필요하다면 결함이 아니기 때문입니다.
가장 많이 나온 결함은 발문이 답을 진단해 주는 것이었습니다. "순서와 대소문자가 달라 중복 캐시되고 있다. 해법은?"이라고 물으면 정답은 발문을 되풀이하는 보기가 되고, 내용을 몰라도 발문과 어휘가 겹치는 보기를 고르면 맞습니다. 지금은 "히트율이 60%에서 40%로 떨어졌다. 로그에 w=640&q=75 와 Q=75&w=640 이 함께 잡힌다."처럼 증상만 서술합니다.
감사 자체가 재현되지 않는다는 것도 측정했습니다. 같은 89문항을 같은 기준·같은 모델로 3번 감사했더니 지목률이 51.9% → 5.6% → 13.5%로 나왔고, 2차와 3차가 지목한 문항의 자카드 유사도는 0.13이었습니다. 두 라운드가 서로 거의 다른 문항을 지목한 셈입니다. 2회 이상 지목된 것은 12건, 정확히 1회만 지목된 것은 32건이었습니다. 그래서 반복 지목만 신호로 취급하고, 1회 지목은 고치지 않습니다. 한 라운드를 근거로 고치고 그 라운드를 다시 돌려 0건을 만들려는 시도는 수렴하지 않습니다. 지금 규약은 "라운드 3개를 병렬로 돌리고 2회 이상 지목된 것만 고친다"입니다. 문항을 60개 늘린 뒤 같은 절차를 그 60문항에 다시 돌렸을 때도 지목 수가 3 / 1 / 12건, 라운드 쌍의 자카드가 0.00 · 0.08 · 0.15로 같은 결론이 나왔습니다. 한 번의 우연이 아니라는 뜻입니다. 그 세 라운드는 60문항을 모두 100% 맞혔는데도 6건을 반복 지목했습니다. 정답률은 이 감사가 측정하는 지표가 아니라는 뜻입니다.
그 과정에서 한쪽을 고치면 다른 쪽이 다시 생기는 결함 한 쌍도 발견했습니다. "정답이 둘 이상으로 읽힌다"는 지적을 발문에 조건을 넣어 해결하면(예: "브라우저 지원 비율은 이미 확인했다"), 그 조건이 경쟁 보기를 읽자마자 소거되는 보기로 바꿉니다. 두 결함은 상호 배타적이라, 조건을 넣는 대신 보기 자체를 다른 오개념으로 교체해야 했습니다. 어느 쪽인지 가르는 기준은 경쟁 보기가 거짓인데 참처럼 읽히는지(조건 추가), 아니면 그냥 참인지(교체)입니다. 후자는 조건을 넣어도 참이 거짓이 되지 않기 때문입니다. 전체 purge를 묻는 문항이 그랬습니다. 경쟁 보기 둘(무효화 전파가 끝나기 전의 시간 창, purge가 브라우저 캐시에 닿지 않음)이 둘 다 사실이었고 "가장 근본적인"이라는 한정만이 순위를 매기고 있어서, 오답 셋을 모두 거짓인 결함 서술로 바꿨습니다.
반복 지목에서 가장 많았던 유형은 결함을 묻는 발문에서 결함을 서술한 보기가 정답 하나뿐인 것이었습니다. "무엇이 깨지는가?"라고 물으면 오답은 처방("~하면 해결된다")이나 방어("~를 켜면 관리가 된다")로 쓰기 쉬운데, 그러면 내용을 몰라도 문형만 보고 답이 특정됩니다. 지금은 오답 셋을 모두 다른 결함 서술로 쓰고, 그것들이 실제로 참일 때는 발문에 "가장 근본적으로"를 넣어 정답과 경쟁하되 밀리게 합니다. node tools/validate.mjs --defect-stems가 이 형태의 발문을 모아 주지만, 게이트는 결함 서술 여부까지 판정하지는 않습니다. 게이트는 대상만 지목하고 판정은 사람이 합니다.
측정되지 않는 것은 측정되지 않는다고 적었습니다. 이 두 결함(발문 어휘 반복, 구체성 격차)을 검사하는 코드를 구현해 지목군 12건과 대조군 8건의 분포를 비교했지만, 두 군이 전혀 분리되지 않았습니다(격차 최대 +1, 대조군에도 +1). 토큰 겹침으로는 의미적 반복을 잡을 수 없다는 뜻이라 검사를 제거했습니다. 무력한 게이트는 "통과"를 "결함 없음"으로 잘못 읽히게 만들기 때문입니다. 실측 기록은 tools/validate.mjs 상단에 남아 있습니다.
세 번째로 검토한 항목도 결과가 같았습니다. 오답의 해설(why)이 자기 보기가 아니라 다른 보기 이야기를 하고 있는 결함이 4건 발견됐는데(오답 텍스트는 "계산이 수 초 걸려 병목"인데 해설은 "단일 지표는 게이팅에 약하다"를 말하고 있었습니다), 어휘 겹침으로 596개 보기 전부를 측정해 보니 겹침 0인 보기가 42%였고 지목된 4건도 그 분포의 한가운데에 있었습니다. 오답의 해설은 원래 보기를 되풀이하지 않고 그 오해를 설명하는 글이니 겹침이 낮은 것이 정상입니다. 즉 이 지표에는 신호가 없습니다. 그래서 게이트를 만들지 않았습니다.
| 장치 | 근거 |
|---|---|
| 4지선다 | 단답형과 비교해도 최종 파지 차이가 작다 (Smith & Karpicke, 4개 실험 종합 d=0.07). 형식보다 인출 성공률이 중요하다 |
| 보기 4개 (오답 3개) | 기능하는 오답이 2~3개일 때 난이도와 변별력이 가장 좋다 |
| 확신도 입력 | 확신했는데 틀린 오류가 가장 강하게 교정된다 (hypercorrection). 결과 화면에서 그 문항을 따로 모아 보여준다 |
| "모르겠음"이 아니라 "찍었어요" | 건너뛰기 버튼은 인출 시도를 없앤다. 실패한 인출도 이후 학습을 향상시키고, 즉시 교정 피드백이 있으면 추측 때문에 오답이 기억에 남을 위험은 거의 사라진다. 그래서 답은 반드시 고르게 하고 찍었음을 신고받는다. 결과에서 찍어서 맞은 문항을 따로 모으고, 점수도 그것을 뺀 값을 나란히 보여준다 |
| 즉시 해설 + 오답별 해설 | 객관식의 오답 노출은 해설 없이 두면 오개념을 심을 수 있고, 정답 확인 피드백이 그 부작용을 없애면서 파지 이득은 키운다. 정답 이유뿐 아니라 당신이 고른 답이 왜 틀렸는지를 보여준다 |
| 약한 문항 재도전 | 교정에 성공한 오류도 시간이 지나면 되돌아오므로, 같은 세션 안에서 한 번 더 인출시킨다. 대상은 틀린 문항 + 찍어서 맞은 문항 |
| 10문항 / 20문항 선택 | 한 라운드를 끝까지 마치는 것이 중요하다. 기본은 10문항이다. 짧게 끝내고 한 번 더 하는 편이, 긴 라운드를 중간에 그만두는 것보다 낫다 |
| 원문 링크 | 해설에서 바로 원문으로 넘어갈 수 있어야 퀴즈가 학습의 입구가 된다. 149문항 중 147문항에 링크가 붙는다 (나머지 둘은 근거가 유료 ISO 표준이라 공개 링크가 없다) |
| 문항 복사 | 채점된 문항을 보기·정답·오답 해설·원문 링크까지 마크다운으로 복사한다. 마지막 줄에 무엇을 물어볼지까지 적혀 있어, Claude 같은 도구에 붙여넣으면 그 자리에서 더 파고들 수 있다 |
자세한 규약과 근거 문헌 목록: AUTHORING.md (§0 설계의 근거, §9 근거 문헌)
현재 149문항입니다.
- HTTP 캐싱 —
Cache-Control디렉티브, 조건부 요청,Vary, 휴리스틱 신선도, 캐시 스탬피드 - CDN — 캐시 키 설계, tiered caching / origin shield, 히트율과 비용, Signed URL, 멀티 CDN
- 이미지 — 포맷 트레이드오프, 동적 리사이즈 아키텍처, 포맷 협상, 화질 지표
- 동영상 — 코덱과 컨테이너, ABR 래더, HLS/DASH/CMAF, 트랜스코딩 파이프라인
- 스토리지·업로드 — presigned URL, multipart/resumable, 스토리지 클래스, 접근 제어
오답의 출처를 설명할 수 있다면 환영합니다.
git clone https://github.com/midagedev/cachehit
cd cachehit
# 1. 오개념 원장에 근거가 있는지 확인, 없으면 추가
# data/misconceptions/<topic>.md
# 2. 문항 추가
# data/questions/<topic>.json
# 3. 게이트 통과
node tools/validate.mjs # 전체
node tools/validate.mjs --topic cdn # 주제별로 나눠 쓸 때는 자기 주제만
node tools/build.mjs게이트 통과는 필요한 검증의 절반일 뿐입니다. 발문·보기를 고쳤다면 §3-9(발문이 답을 진단해 주지 않는다)를 스스로 점검하세요. 정답을 모르는 상태를 가정하고 발문과 어휘가 가장 많이 겹치는 보기를 골라 봤을 때 그게 정답이면 아직 실패입니다. 이 결함은 기계가 잡지 못합니다.
PR에 각 오답이 어느 오개념에서 왔는지 한 줄씩 적어 주세요. 출처를 설명하지 못하는 오답이 있는 PR은 병합하지 않습니다.
문항 오류나 더 나은 오답 아이디어는 이슈로 알려 주세요.
빌드 도구가 필요 없습니다. 정적 파일이 전부입니다.
node tools/build.mjs # data/questions/*.json → data/questions.json (원문 링크 부착 포함)
node tools/check-links.mjs # 근거 URL이 전부 살아 있는지 (네트워크 필요)
python3 -m http.server 8000퀴즈 흐름 회귀 테스트(선택 사항, 20문항을 자동으로 풀어 확신도 집계와 결과 화면을 검증):
npm i -D playwright && npx playwright install chromium
node tools/e2e.mjs