feat: 문제 깊이 개편 — 실무 앵커·인지 수준·정답 누출 차단 (SYS)

[kmjnnhyk]

화면 / 영역

SYS 시스템 (문제 생성 파이프라인) — 결과물은 S3 Play · S4 Insight 전체에 반영

무엇을 / 왜

2026-08-03 도그푸딩에서 나온 문제 품질 피드백 5건을 하나의 목표로 묶는다.

• 실무 사용처 → 실제 백엔드 혹은 리액트 코드 혹은 개념을 예시로 들면 좋을듯
• "다음 코드에 대한 설명으로" — 예시가 ts가 아니라 수도코드로
• 문제들이 개념 겉핥기 느낌. 제대로 알았다는 느낌이 안 듦
• 묘하게 문제만 잘 읽으면 답이 나옴
• 오히려 문제 → 개념. 개념 → 문제가 되어야

마지막 항목이 이 이슈의 뿌리다. 지금 학습자는 "TCP 3-way handshake"라는 교과서 목차에서 출발한다. 왜 배우는지 모른 채 시작하니 풀어도 남는 게 없다. 매일 쓰는 기술의 docs 용어에서 출발해 그 밑에 깔린 CS 원리로 내려가면, 어디에 쓰이는지 알고 배우게 된다.

진입점 (실무)	도착점 (원리)
Spring 커넥션 풀 크기를 왜 튜닝하나	TCP 연결 수립 비용 · 소켓
Node가 파일 I/O는 스레드풀을 쓰는데 네트워크는 안 쓰는 이유	blocking I/O vs epoll/kqueue
React key 없이 리스트를 렌더하면 왜 느려지나	재조정 diff · 자료구조
@Transactional을 걸었는데 롤백이 안 되는 이유	프록시 · 트랜잭션 격리 · 락
useEffect cleanup을 빼먹으면 왜 메모리가 새나	참조 도달 가능성 · GC

진단 — 난이도와 깊이는 다른 축이다

#194는 회고의 "너무 어렵다" 에서 출발했고, 이 이슈는 "너무 얕다" 에서 출발한다. 반대로 보이지만 직교하는 축이다.

	얕다	깊다
쉽다	데드락 발생 조건 4가지 중 아닌 것은?	이 코드를 스레드 2개로 돌리면 가끔 멈춘다. 왜?
어렵다	TIME_WAIT의 기본 지속 시간은?	커넥션 풀을 늘렸더니 TIME_WAIT이 쌓인다. 무엇을 봐야 하나?

현재 파이프라인은 난이도만 조절한다. 슬롯이 하2·중2·상1로 고정이고, QuizGenerationPromptBuilder의 CONTENT_LEVEL_BASIC / CONTENT_LEVEL_ADVANCED도 "개념의 깊이를 낮춰라/높여라"라고만 지시한다 — 왼쪽 열 안에서 위아래로 움직일 뿐, 오른쪽 열로 가는 지시가 프롬프트 어디에도 없다.

피드백 5건은 전부 오른쪽 열로 옮기는 하나의 작업이다.

결정 사항 (2026-08-03 논의 확정)

• D1. 실무 앵커를 모든 문제에 붙인다. 코스 목차는 지금처럼 CS 주제로 두되, 각 문제의 지문이 실무 기술의 구체적 상황에서 시작한다. 별도 "알아두기" 블록을 만들지 않는다 — 앵커는 지문 자체여야 한다.
• D2. 앵커의 기술 스택은 문제마다 자연스러운 것으로 고른다. 학습자별 스택 선택은 넣지 않는다(필요해지면 feat(app): 관심 코스 선택 (S1) #71 온보딩에 붙인다).
• D3. 지문 코드는 수도코드가 기본, 언어 고유 동작을 묻는 문제만 실제 코드를 허용한다. 판정 기준을 문장으로 정의한다.
  • 수도코드: lock(mutex) / counter ← counter + 1 / unlock(mutex)
  • 실제 코드 허용: setTimeout(() => log(1), 0) vs Promise.resolve().then(...) 의 실행 순서
• D4. 회상형 발문을 금지하고 판단·적용·예측형만 낸다. 세트 구성(하2·중2·상1)은 유지한 채 발문의 인지 수준만 올린다.
• D5. 지문만 읽고 풀리는 문제를 실패로 규정한다. #194에 적힌 "정답 근거가 지문에 있는가" 체크 항목은 이 결정과 충돌하므로 삭제한다.
• D6. 해설의 explanationExample은 복붙 가능한 실제 코드로 규격화한다. 지문(수도코드)과 해설(실제 코드)의 역할을 분리한다.

작업 단위

PR을 나눠 올린다. 순서대로 진행하되 A가 나머지 전부의 정본이다.

A. 문제 품질 기준 + 골든 샘플 정의 — docs/, 코드 0줄

AI가 초안을 쓰고 사람이 검수한다.

• 인지 수준 4등급(회상·이해·적용·분석) 정의와 회상형 금지 선언
• 실무 앵커 규칙 — 앵커 대상 선정 기준, 지문에 녹이는 방식
• 앵커 할루시네이션 방지 규칙 — 버전에 따라 변하는 구체값(기본 풀 크기, 타임아웃 기본값, 특정 버전의 동작)을 앵커에 쓰지 않는다. 안정적인 동작·설계 의도만 가리킨다
  • 허용: "커넥션 풀 크기를 늘렸더니" / 금지: "HikariCP 기본 풀 크기 10을"
• 정답 누출 금지 규칙 — 지문만으로 풀리면 실패
• 코드 지문 정책(D3)의 판정 기준을 문장으로
• 규칙마다 좋은 예 / 나쁜 예 한 쌍 = 골든 샘플. B의 few-shot과 C의 테스트 픽스처가 여기서 나온다

B. 생성 프롬프트 개편 — scope: server

• QuizGenerationPromptBuilder에 앵커 지시·발문 템플릿·few-shot 반영
• CONTENT_LEVEL_* 힌트를 난이도 축과 깊이 축으로 분리
• 생성 성공률 회귀 측정 — B 적용 전후 비교치를 이슈에 기록

C. 자동 검증기 — scope: server

기계로 잡히는 것만 넣는다. 나머지는 A의 사람 검수 항목으로 남긴다.

• 선택지 길이 편차 — 정답만 유독 길면 티가 난다
• 지문–정답 어휘 중복률 — 정답 누출 탐지
• 회상형 발문 패턴 탐지
• 검증기 추가 후 성공률 재측정 (fix(server): 문제 생성 성공률 29% — 검증기가 생성 프롬프트와 어긋난다 (SYS) #270 되먹임 루프가 흡수하는지 확인)

D. 해설 "실무 사용처" 실제 코드화 — scope: server + scope: app

• explanationExample을 실제 코드로 규격화 (프롬프트 + 검증)
• app 해설 화면에서 코드 블록 렌더링 (신택스 하이라이트)

완료 기준 (Acceptance)

• A~D 작업 단위 전부 완료
• 새 기준으로 생성한 코스 1개를 도그푸딩해 "겉핥기 느낌"이 해소됐는지 확인
• 생성 성공률이 개편 전(29%, fix(server): 문제 생성 성공률 29% — 검증기가 생성 프롬프트와 어긋난다 (SYS) #270 기준) 대비 하락하지 않음
• 라이브 문제 재검수는 이 이슈가 아니라 #194에서 처리 (기준만 넘겨준다)

추적 / 의존

• 추적 ID: -
• 선행: fix(server): 문제 생성 성공률 29% — 검증기가 생성 프롬프트와 어긋난다 (SYS) #270 — 생성 성공률 29%. 검증 실패 사유를 재시도 프롬프트에 되먹이는 작업이 먼저 끝나야 규칙을 더 얹을 수 있다
• 관련: feat(server): 문제 난이도·품질 기준 재정립 + 라이브 문제 재검수 (SYS) #194 (난이도 기준 + 라이브 재검수 — 품질 기준 정의 항목은 이 이슈로 이관, 충돌 항목 삭제), feat(app): 코드 제시형 문제 (S3) #6 (코드 제시형 문제 — D3의 코드 정책이 선행), feat: 문제별 난이도 선택 (S3) #195 (문제별 난이도 선택), feat(app): 관심 코스 선택 (S1) #71 (관심 코스 선택 — D2의 확장 지점)

분류 근거

• 임팩트: 높음 — 문제가 곧 제품이다. 모든 코스·모든 학습자에게 반영된다
• 빨리 만들 수 있나: 아니오 — 기준 정의 + 프롬프트 + 검증기 + 앱 렌더링에 걸친다
• → 마일스톤: M3