W17 미리보기 · 웹소설 본편

STARRY PASS 13 — 공동 1등과 되감기 표식

같은 점수의 순위와 어긋난 장부의 복구를 구분한다

범위D1–D6 · 월–토p547 개요 + p548–568 + p569 혼합 경계 + p570–572

정본 상태SOURCE AUDIT PASSPDF·source·workbook byte 폐쇄

실행 상태W17 D1–D6 LABS NOT_RUNtestsExecutedByAudit=0

이 이야기는 W17 개요와 D1–D6만 다룹니다. 정확한 범위는 p547 개요 + p548–568 + p569 혼합 경계 + p570–572입니다. p569 상단의 D5 최종 Gate 뒤에 D6 토 모듈이 시작되며, p573부터의 D7·p579 주간 통합·p580의 W17 복구 문장과 W18은 제외합니다. 공통 코어 · 트랙 선택 시 증권 기본으로 표시하지만 증권 전용 기능 주차는 아닙니다. source audit은 PASS여도 testsExecutedByAudit=0이므로 현재 상태는 W17 D1–D6 LABS NOT_RUN입니다.

STARRY의 객석이 하룻밤 동안 별 모양 공 던지기 경기장으로 바뀌었다. 키타는 사회자 띠를 둘렀고, 니지카는 점수와 식권 잔액을 함께 관리하는 계산대를 맡았다. 료는 우승 상품인 카레 세트를 노렸고, 히토리는 참가 신청서 뒤에 숨어 조용히 관전하려 했다.

경기 시작 전 계산대에서는 이상한 일이 먼저 벌어졌다. 카드에 적힌 잔액과 영수증 원장의 합이 모두 맞아 불일치 수가 0이었는데, 료가 한 카드 잔액에 7을 더하자 불일치가 정확히 1이 되었다. 니지카는 장난 직전에 작은 별 표식을 꽂아 두었고, 그 표식까지 되감자 다시 0이 되었다.

니지카가 태블릿으로 장부 대사와 SAVEPOINT 복구 순서를 점검하는 공식 장면 — 그림 한눈에: 공식 장면컷은 장부 복구 순서를 함께 점검하는 분위기 전환용이며, 학습 사건·SQL·수치는 원문 감사에 따른 비공식 구성입니다.

“처음 0, 장난 뒤 1, 되감은 뒤 0이에요.” 키타가 표시창을 손가락으로 짚었다.

“별 앞의 기록까지 사라지는 건 아니죠?” 히토리가 물었다.

니지카는 SAVEPOINT가 transaction 중간의 복귀점을 표시하고, ROLLBACK TO SAVEPOINT는 그 뒤의 변경만 취소한다고 설명했다. 전체 transaction은 여전히 열려 있으므로 이후 COMMIT이나 바깥 ROLLBACK으로 끝을 정해야 했다. 표식까지 돌아온 것과 밤 전체를 없앤 것은 달랐다.

기준 불일치 0, 주입 뒤 1, SAVEPOINT 복구 뒤 0의 대사 흐름 도식 — 그림 한눈에: baseline mismatch 0 → +7 주입 뒤 1 → SAVEPOINT 복구 뒤 0의 좁은 대사 계약을 봅니다.

D1의 목표는 이 0→1→0을 실제 PostgreSQL 대사와 transcript로 확인하는 것이었다. 예상 marker가 문서에 적혀 있다는 사실은 현재 실행 성공과 다르다. source audit은 파일을 읽었지만 runner를 실행하지 않았고, reconcile-transcript.txt 존재만으로도 최신 Green을 증명할 수 없었다.

료가 “복구했으니 처음 seed도 사라졌겠네”라고 말하자 니지카가 고개를 저었다. canonical drill의 account·business_tx·ledger_entry seed는 BEGIN보다 앞에서 실행되어 기본 autocommit 아래 남을 수 있다. 뒤의 최종 ROLLBACK은 post-BEGIN 구간을 닫을 뿐, 이미 commit된 seed까지 지우지 않는다.

· · ·

경기 첫 네 점수는 100, 100, 80, 70이었다. 시작부터 공동 1등이었다. 키타가 번호표를 나눠 주려 하자 같은 점수 둘에게 어떤 번호를 붙일지를 두고 객석이 웅성거렸다.

ROW_NUMBER는 모든 행에 서로 다른 번호를 붙여 1, 2, 3, 4가 되었다. RANK는 공동 1등을 함께 1로 두고 다음 자리를 건너뛰어 1, 1, 3, 4가 되었다. DENSE_RANK는 빈 번호 없이 1, 1, 2, 3이 되었다.

100, 100, 80, 70에 적용한 ROW_NUMBER, RANK, DENSE_RANK 결과 비교 도식 — 그림 한눈에: 100·100·80·70에서 세 순위 함수가 만드는 exact 번호 네 줄을 비교합니다.

“80점 선수가 3등이기도 하고 2등이기도 하네요.” 히토리가 말했다.

“함수가 답을 바꾼 게 아니라, 우리가 동률 다음 자리를 어떻게 정의할지 골랐기 때문이야.” 료가 답했다.

고정 예의 exact row는 1|100|1|1|1, 2|100|2|1|1, 3|80|3|3|2, 4|70|4|4|3이었다. ROW_NUMBER에서 두 100점의 순서를 안정시키려면 점수 외에 account_id 같은 결정적 tie-breaker가 필요했다. 마지막 화면의 ORDER BY는 표시 순서를 정하지만, window 함수 안의 번호 약속을 대신하지 않았다.

네 사람이 동률 순위와 결정적 정렬 기준을 토론하는 공식 장면 — 그림 한눈에: 공식 장면컷은 동률 처리와 tie-breaker를 토론하는 분위기용이며, 실제 SQL 실행 장면이 아닙니다.

가족부·학생부·상인부가 동시에 점수를 내자 키타는 통로에 색 테이프를 붙였다. PARTITION BY는 부문마다 번호를 새로 시작하게 했고, window 안의 ORDER BY score DESC, account_id는 각 차선 안의 순서를 결정했다. 부문별 최신 한 건처럼 반드시 한 줄만 골라야 하는 문제에는 ROW_NUMBER와 안정적인 두 번째 정렬 기준이 맞았다. 공동 최고 점수를 모두 남겨야 한다면 RANK의 의미가 더 맞을 수 있었다.

PARTITION BY로 줄을 나누고 ORDER BY와 tie-breaker로 순서를 고정하는 도식 — 그림 한눈에: 줄을 나누는 PARTITION BY와 줄 안을 고정하는 ORDER BY·tie-breaker의 역할을 분리합니다.

· · ·

휴식 시간, 관리인이 여러 계좌의 저장 잔액과 원장 합을 비교해 달라고 했다. 한 문장에 전부 넣자 히토리의 눈에는 괄호와 별칭만 보였다. 니지카는 질문을 세 개의 이름 붙은 판으로 나눴다.

첫 판 ledger_sum은 account_id별 signed_amount 합을 만들었다. 둘째 compared는 account의 stored balance와 ledger 합을 같은 행에 놓았다. 셋째 mismatch는 두 값이 다른 계좌만 남겼다. 각 CTE의 한 행이 무엇을 뜻하는지, 즉 query grain을 account로 유지하는 것이 핵심이었다.

ledger_sum, compared, mismatch 세 CTE를 account grain으로 연결한 도식 — 그림 한눈에: ledger_sum → compared → mismatch를 account grain으로 이어 긴 대사 SQL을 계단처럼 읽습니다.

원장이 하나도 없는 계좌도 비교 대상에 남겨야 했다. account에서 시작해 ledger_sum을 LEFT JOIN하고, 없는 합을 COALESCE(..., 0)으로 표시했다. 이것은 NULL 표시 계약이지 잘못된 join이나 빠진 원장을 자동으로 고치는 주문은 아니었다.

검증 장면은 한 계좌에만 맞춘 요령을 막기 위해 두 반례를 사용했다. baseline은 EMPTY, 202번의 저장 잔액을 7 높이면 202|82|75|7, 복구하면 다시 EMPTY였다. 이어 101번을 11 높이면 101|111|100|11, 다시 복구하면 EMPTY가 되었다.

EMPTY와 202, 101 mismatch 행이 복구를 사이에 두고 나타나는 exact sentinel 도식 — 그림 한눈에: EMPTY → 202의 +7 → EMPTY → 101의 +11 → EMPTY라는 exact sentinel 순서를 봅니다.

“결과가 한 줄이라는 것만 보면 어느 계좌가 얼마나 틀렸는지 모르겠어요.” 키타가 말했다.

“그래서 account_id, stored_balance, ledger_balance, difference 네 열과 순서를 함께 확인해.” 니지카가 답했다.

D3의 Q25는 성공률을 소수 둘째 자리까지 계산하는 문제였다. 별도 audit-authored 학습용 예시는 customer를 보존하고 전체 상태를 분모, SUCCESS만 분자로 둔다. 11/12는 91.67, 2/7은 28.57이며 거래 0건은 NULLIF(total, 0) 때문에 NULL로 남는다. customer grain·분모 정책·0건 NULL은 prompt가 고정한 정본 답안이 아니라 공개한 예시 가정이었다.

· · ·

목요일에는 되감기 별을 transaction 수업용으로 다시 꺼냈다. 니지카는 BEGIN 뒤 baseline을 확인하고 SAVEPOINT before_fault를 만들었다. 그 다음 일부러 잔액을 7 높여 mismatch 1을 관찰하고, ROLLBACK TO SAVEPOINT before_fault로 돌아가 mismatch 0을 확인했다.

BEGIN 안에서 SAVEPOINT 뒤 변경만 ROLLBACK TO로 되돌리고 transaction은 유지하는 도식 — 그림 한눈에: ROLLBACK TO는 별 뒤의 +7만 취소하고 outer transaction은 계속 열린 상태임을 봅니다.

constraint 오류가 발생한 PostgreSQL transaction은 자동으로 정상 상태로 돌아오지 않을 수 있었다. savepoint가 있다면 그 지점으로 rollback해 실패 상태를 걷어내고 계속할 수 있고, 없다면 transaction 전체를 rollback해야 했다. 연습은 disposable schema에서 해야 하며 production DB에 고의 오류를 주입하면 안 됐다.

“별까지 돌아온 뒤 바로 집에 가도 되나요?” 히토리가 물었다.

“아니. transaction 문은 아직 열려 있어.” 료가 말했다. “COMMIT할지, 마지막 ROLLBACK으로 닫을지 정해야 해.”

D1의 물리 drill과 D4의 SQLD DML·constraint·transaction 설명은 같은 SAVEPOINT를 보지만 질문의 초점이 달랐다. 하나는 대사 불일치 0→1→0을 재현하고, 다른 하나는 오류 격리와 transaction 종료 범위를 해석했다.

· · ·

금요일, 료는 경기장 동선을 짠 계획표를 내밀었다. 종이에 가장 가까운 문이 표시되어 있어도 실제 관객이 반드시 그 문을 쓰는 것은 아니었다. PostgreSQL optimizer도 index가 존재한다는 이유만으로 index scan을 강제하지 않았다. 예상 행 수, 선택도, table 크기와 비용을 바탕으로 seq scan·index scan·join·sort를 골랐다.

estimated rows와 actual rows, filter와 buffer 관찰값을 나누는 실행계획 도식 — 그림 한눈에: estimated_rows와 actual_rows, loops·filter·buffer를 나누어 실행계획의 약속과 관찰을 읽습니다.

니지카는 D5의 일곱 열을 표에 썼다. estimated_rows, actual_rows, filter_rows, index_name, buffer_hit, buffer_read, execution_time이었다. estimate는 planner의 예측이고 actual은 실행 관찰값이다. nested loop의 안쪽 node는 loops만큼 반복될 수 있으므로 rows 한 숫자만 떼어 전체 일을 단정하면 안 됐다.

W13의 before-plan.txt, after-plan.txt, perf-manifest.json을 연결할 때는 filename과 hash를 맞춰야 했다. 하지만 실제 field를 읽지 않고 “index가 있으니 빨라졌다”라고 쓰거나 절대 latency를 약속하면 안 됐다. cache가 따뜻한지, data 규모와 통계가 어떤지에 따라 관찰값은 달라진다.

index 존재와 optimizer의 실제 index scan 선택이 다른 문제임을 보여 주는 도식 — 그림 한눈에: index 존재는 후보를 늘리지만 optimizer의 실제 선택과 성능 결과를 강제하지 않습니다.

D5의 Q26은 correlation_id를 GROUP BY하고 HAVING COUNT(*) > 1인 중복 후보를 찾았다. illustrative workbook fixture에서는 CORR-DUP|2 한 줄이다. 이 결과는 두 행이 같은 logical request이거나 사기라는 판정이 아니다. 더구나 application V001에는 correlation_id UNIQUE가 있지만 workbook schema는 중복 연습을 허용하므로 두 schema의 계약을 섞으면 안 됐다.

GROUP BY correlation_id와 HAVING count greater than one이 후보만 찾는 도식 — 그림 한눈에: GROUP BY·HAVING은 중복 후보를 좁힐 뿐 원인·사기·동일 요청 여부를 판정하지 않습니다.

카운터에 모인 네 사람이 실행계획 관찰값과 모의 기록을 정리하는 공식 장면 — 그림 한눈에: 공식 장면컷은 실행계획 관찰값과 오답 기록을 함께 정리하는 분위기용이며, 실제 시험 성적을 뜻하지 않습니다.

· · ·

토요일에는 75분 압축 누적 세트를 풀었다. 제목에 75분이 있어도 50문항·90분 full mock은 아니었다. CSV의 full_exam=false와 실제 question_count를 그대로 기록해야 했다. window·NULL·subquery·transaction 문제가 섞여 있었지만, 시간 상한을 넘겨 빈 문항을 억지로 채우지 않았다.

정답 여부 옆에는 confidence를 남겼다. 자신 있게 틀린 high-wrong은 개념 오해 가능성이 커서 가장 먼저 복구했고, 낮은 확신으로 맞힌 low-right는 추측인지 근거를 다시 확인했다. 점수만 보면 둘 다 놓치기 쉬운 정보였다.

75분 상한, full_exam false, question count와 confidence 기록 계약을 보여 주는 도식 — 그림 한눈에: full_exam=false·실제 question_count·75분 상한과 high-wrong 우선 복구를 한 화면에서 봅니다.

니지카는 마지막 벽에 source 경계를 붙였다. 코드 뒤풀이는 canonical 5개와 illustrative 4개를 분리한다. ranking·reconcile CTE·Q25·Q26 SQL은 audit-authored 학습용 예시이며 shipped learner 정본 답안이 아니다. LOCAL_ARTIFACT_VALIDATED 같은 marker도 정적 파일 계약이나 좁은 sentinel을 나타낼 뿐 모든 SQL 의미를 대신하지 않으므로 HUMAN_SEMANTIC_REVIEW_REQUIRED가 남는다.

W17 D1–D6의 재계산 학습 시간은 2시간 40분–5시간이다. p547의 2시간 50분–5시간 20분은 D7까지 포함한 전체 주차 합계이므로 strict 미리보기의 합계로 가져오지 않았다.

손님이 “그럼 이번 주가 전부 Green인가요?”라고 묻자 히토리가 고개를 저었다.

“source audit PASS는 원문과 source bytes가 닫혔다는 뜻이고, testsExecutedByAudit=0이에요. 예상 marker와 실제 최신 실행 증거는 달라요.”

키타가 덧붙였다. “대신 무엇을 확인했고 무엇을 아직 확인하지 않았는지는 한눈에 볼 수 있어요!”

료는 남은 카레 감자를 집어 들었다. “공동 1등의 번호는 규칙에 따라 달라져도, 어긋난 장부는 되돌려 맞춰야 한다는 것도.”

니지카는 p573의 D7 문을 닫아 두었다. 오늘은 p572의 D6 최종 Gate까지만이었다. 점수판에는 1·1·3과 1·1·2가 나란히 남았고, 계산대에는 0→1→0 별 표식이 빛났다.

· · ·

이미지 출처와 이용 안내: 공식 장면컷은 TV 애니메이션 《봇치 더 록!》 공식 사이트 자료입니다. ©はまじあき／芳文社・アニプレックス. 이 문서는 개인 학습용 비공식 구성으로, 원작의 공식 설정과 별개의 학습 비유입니다. 개념도는 원문 감사 내용에 맞춰 새로 만든 교육용 SVG입니다.

W17 미리보기 · 히토리 질문 노트

히토리의 질문 노트 — STARRY PASS 13

본편의 쉬운 비유를 실제 SQLD·PostgreSQL 기술 이름과 증거 경계로 다시 연결합니다. 답은 W17 개요와 D1–D6에만 한정하며, source audit PASS를 현재 실행 Green으로 바꾸어 말하지 않습니다.

1. 이번 미리보기의 strict PDF 범위는 어디인가요?

포함 범위는 p547 개요 + p548–568 + p569 혼합 경계 + p570–572입니다. p569 상단에서 D5의 최종 Gate가 끝나고 같은 페이지 하단에서 D6 토 모듈이 시작하므로, 요일 제목만 보고 페이지 전체를 한쪽에 넣으면 안 됩니다.

p546은 W16 통합, p573–578은 D7, p579는 W17 주간 통합·요일별 해설, p580 첫 줄은 W17 미달 복구 문장이므로 제외합니다. p580의 W18 heading과 그 아래도 범위 밖입니다.

실제 기술 이름mixed-page semantic boundary — W17 overview and D1–D6 only

2. W17 D1–D6은 어떤 순서로 진행되나요?

D1 대사 불일치 0→1→0 SAVEPOINT 복구, D2 ROW_NUMBER·RANK·DENSE_RANK, D3 CTE reconciliation과 Q25, D4 DML·constraint·transaction, D5 실행계획과 Q26, D6 full_exam=false 75분 압축 세트 순서입니다.

공통 코어 · 트랙 선택 시 증권 기본입니다. SQLD 고급 SQL과 계좌·원장 예시를 다루지만 증권 전용 주문·체결 기능을 만드는 주차는 아닙니다.

실제 기술 이름SQLD advanced SQL progression from reconciliation to confidence-calibrated practice

3. source audit PASS와 현재 W17 실행 Green은 왜 다른가요?

source audit PASS는 PDF·project·workbook source의 bytes와 경계가 맞물리는지 확인한 뜻입니다. audit의 statusMeaning도 PASS가 W17 runner execution이나 learner Green이 아니라고 명시하고, testsExecutedByAudit=0입니다.

따라서 현재 표시는 W17 D1–D6 LABS NOT_RUN입니다. PDF의 예상 marker와 과거 evidence 파일의 존재를 최신 실행 성공으로 읽으면 안 됩니다.

실제 기술 이름byte-verified source closure versus unexecuted runtime evidence

4. D1의 reconciliation에서 mismatch 0→1→0은 무엇을 뜻하나요?

baseline에서는 저장 잔액과 ledger 합이 모두 맞아 mismatch count가 0입니다. 한 account 잔액에 7을 주입하면 정확히 한 계좌가 달라져 1이 되고, SAVEPOINT까지 되감으면 다시 0이 됩니다.

이 세 숫자는 좁은 fixture invariant입니다. 전체 회계 완전성, double-entry 균형, 동시 write 격리, production 운영 정책까지 증명하지 않습니다.

실제 기술 이름deterministic balance reconciliation with injected mismatch and restore

5. SAVEPOINT와 ROLLBACK TO SAVEPOINT는 transaction 전체 rollback과 어떻게 다른가요?

SAVEPOINT는 열린 transaction 안의 복귀점을 만듭니다. ROLLBACK TO SAVEPOINT는 그 지점 뒤의 변경만 취소하고 outer transaction을 계속 열어 둡니다.

transaction을 끝내려면 이후 COMMIT이나 최종 ROLLBACK이 필요합니다. 별까지 돌아온 것과 밤 전체를 취소한 것은 같은 일이 아닙니다.

실제 기술 이름partial transaction rollback to a named savepoint

6. canonical reconcile drill의 마지막 ROLLBACK 뒤에도 무엇이 남을 수 있나요?

account·business_tx·ledger_entry seed는 BEGIN보다 앞에서 실행됩니다. psql 기본 autocommit에서는 이 statement들이 먼저 commit될 수 있어 post-BEGIN 최종 ROLLBACK이 seed를 지우지 않습니다.

owned Compose mode의 down -v는 volume을 제거하지만 supplied Container mode는 schema와 committed seed를 남길 수 있습니다. cleanup 문구만 보고 실제 소유 resource가 사라졌다고 단정하지 않습니다.

실제 기술 이름pre-transaction autocommit persistence and ownership-scoped cleanup

7. reconcile transcript에 세 marker가 있으면 packaged drill 실행까지 증명되나요?

아닙니다. canonical runner의 좁은 검사는 baseline·injected·restored substring의 존재를 각각 볼 뿐 순서·유일성을 인증하지 않습니다. raw learner V001이 marker나 psql meta-command를 먼저 출력할 가능성도 audit 경계에 남아 있습니다.

transcript는 실패 전에 쓰일 수 있고 이전 파일이 남을 수도 있습니다. current Green에는 timestamp·source hash·native exit·실제 실행 경로를 함께 확인해야 합니다.

실제 기술 이름marker-presence evidence with spoofing, ordering, and staleness limits

8. 100·100·80·70에 세 순위 함수는 어떤 결과를 만드나요?

ROW_NUMBER는 1·2·3·4, RANK는 1·1·3·4, DENSE_RANK는 1·1·2·3을 만듭니다. exact row는 1|100|1|1|1, 2|100|2|1|1, 3|80|3|3|2, 4|70|4|4|3입니다.

RANK는 동률이 차지한 자리만큼 다음 번호를 건너뛰고, DENSE_RANK는 순위 값 사이에 빈 번호를 두지 않습니다.

실제 기술 이름ROW_NUMBER, RANK, and DENSE_RANK tie semantics

9. ROW_NUMBER에서 tie-breaker가 왜 필요한가요?

ORDER BY amount DESC만 있으면 같은 100점 두 행 사이의 순서가 결정되지 않습니다. account_id처럼 unique하고 stable한 두 번째 key를 window ORDER BY에 넣어야 반복 실행에서도 같은 row_no를 기대할 수 있습니다.

화면 바깥의 최종 ORDER BY는 display 순서를 정할 뿐, 이미 계산된 ROW_NUMBER의 동률 기준을 소급해 고치지 않습니다.

실제 기술 이름deterministic window ordering with a unique stable tie-breaker

10. PARTITION BY와 ORDER BY는 각각 무엇을 정하나요?

PARTITION BY는 서로 경쟁하지 않는 줄을 나누고 각 줄에서 window 계산을 다시 시작합니다. ORDER BY는 그 partition 안에서 앞뒤를 정합니다.

부문별 최신 한 건이라면 PARTITION BY group_id ORDER BY created_at DESC, id DESC 같은 모양을 쓰고 row_no=1을 고릅니다. partition key가 빠지면 전체에서 한 건만 남을 수 있습니다.

실제 기술 이름window partition boundary and deterministic intra-partition ordering

11. 공동 최고 행을 모두 남길 때도 ROW_NUMBER=1을 쓰면 되나요?

ROW_NUMBER=1은 tie-breaker 기준으로 한 행만 남깁니다. 요구가 공동 최고 점수 전부라면 RANK=1이나 max 값과의 비교가 더 자연스러울 수 있습니다.

반대로 반드시 최신 한 행이어야 하는데 RANK=1을 쓰면 동률 행이 여러 개 남을 수 있습니다. 함수 선택은 문법 취향이 아니라 output cardinality 계약입니다.

실제 기술 이름top-one selection versus tied-top preservation

12. CTE reconciliation의 세 단계와 각 grain은 무엇인가요?

ledger_sum은 account_id별 원장 합 한 행, compared는 account와 저장 잔액·원장 합을 나란히 둔 한 행, mismatch는 차이가 있는 account 한 행입니다.

CTE는 중간 relation에 이름을 붙여 grain과 오류 위치를 읽게 합니다. 이름이 붙었다는 사실만으로 물리 materialization이나 성능 향상을 보장하지 않습니다.

실제 기술 이름common table expressions with explicit account-grain reconciliation stages

13. 원장 없는 account를 CTE 대사에서 어떻게 보존하나요?

account를 시작점으로 ledger_sum을 LEFT JOIN하면 합계 row가 없는 account도 남습니다. COALESCE(ledger_balance, 0)은 비교를 위한 표시값을 0으로 바꿉니다.

INNER JOIN으로 시작하면 원장 없는 account가 사라져 mismatch 검사가 누락될 수 있습니다. COALESCE는 잘못된 join key나 중복 원장을 고치지 않습니다.

실제 기술 이름parent-preserving LEFT JOIN and NULL-to-zero comparison contract

14. CTE validator의 exact five-marker sequence는 무엇인가요?

순서는 EMPTY → 202|82|75|7 → EMPTY → 101|111|100|11 → EMPTY입니다. 첫 mismatch는 202번의 stored 82와 ledger 75의 차이 7, alternate mismatch는 101번의 111과 100의 차이 11입니다.

두 account와 두 차이를 쓰는 것은 202·7을 hardcode한 query를 막는 반례입니다. 그래도 이 fixture-bound sequence가 production 모든 account를 증명하는 것은 아닙니다.

실제 기술 이름fail-closed alternate-case CTE sentinel sequence

15. Q25 성공률 예시는 어떤 가정을 공개하나요?

audit-authored 학습용 예시는 customer grain, 모든 business_tx status를 분모, SUCCESS만 분자, 거래 0건은 NULL이라는 네 가정을 둡니다. 결과 예는 고객 1이 11/12=91.67, 고객 2가 2/7=28.57입니다.

분모에는 NULLIF(COUNT(...), 0)을 써 0으로 나누지 않습니다. 이 정책은 prompt가 고정한 shipped 정본 답안이나 모든 업무의 성공률 정의가 아닙니다.

실제 기술 이름conditional aggregation with NULLIF-protected zero denominator

16. D4의 BEGIN→SAVEPOINT→주입→복구 순서는 왜 필요한가요?

BEGIN으로 실험 범위를 열고 baseline을 확인한 다음, 실패 직전 SAVEPOINT를 만듭니다. +7 update로 mismatch 1을 관찰하고 ROLLBACK TO로 0을 복구한 뒤 outer transaction을 명시적으로 끝냅니다.

주입 전에 baseline을 보지 않으면 원래 있던 불일치를 새 오류로 착각할 수 있고, 복구 후 재검사가 없으면 rollback 명령이 실제 invariant를 회복했는지 모릅니다.

실제 기술 이름transaction-scoped fault injection with savepoint restore verification

17. PostgreSQL transaction에서 constraint 오류 뒤 명령이 계속 실패하는 이유는 무엇인가요?

오류가 난 transaction은 aborted state가 되어 후속 statement를 거부할 수 있습니다. SAVEPOINT가 있었다면 ROLLBACK TO SAVEPOINT로 실패 구간을 걷어내고 계속할 수 있습니다.

savepoint가 없거나 복구 범위를 확신할 수 없다면 전체 ROLLBACK이 필요합니다. 오류 메시지만 무시하고 다음 SQL을 보내는 것은 복구가 아닙니다.

실제 기술 이름PostgreSQL aborted transaction state and savepoint recovery

18. ROLLBACK TO 뒤 COMMIT과 전체 ROLLBACK은 어떤 차이가 있나요?

ROLLBACK TO 뒤 COMMIT하면 savepoint 이전과 복구 뒤에 남은 유효 변경을 확정합니다. 전체 ROLLBACK하면 outer transaction 안의 모든 변경을 버립니다.

어느 쪽이 맞는지는 실습 계약에 달려 있습니다. 부분 복구를 했다는 사실이 자동 commit이나 자동 종료를 뜻하지 않습니다.

실제 기술 이름commit-versus-full-rollback decision after partial rollback

19. 왜 고의 mismatch와 constraint 오류를 production DB에서 실행하면 안 되나요?

교육 실습은 disposable schema·격리 transaction·명시적 cleanup을 전제로 합니다. production에서는 lock, trigger, audit, replication, 동시 요청에 영향을 줄 수 있고 rollback이 외부 side effect까지 되돌린다고 보장할 수 없습니다.

원문도 실습을 production DB에서 하지 말라고 경고합니다. 안전 경계는 SQL 문법보다 먼저 확인합니다.

실제 기술 이름isolated disposable-database fault-injection safety boundary

20. 실행계획에서 estimate와 actual은 어떻게 다른가요?

estimated rows와 cost는 optimizer가 통계로 예측한 값이고, actual rows·loops·time은 EXPLAIN ANALYZE가 실행 중 관찰한 값입니다. estimate와 actual의 큰 차이는 통계·상관관계·조건 선택도 문제의 단서가 될 수 있습니다.

관찰 한 번의 execution_time을 SLA나 영구 성능으로 확대하지 않습니다. cache와 data 규모, 부하, version이 달라지면 값도 달라집니다.

실제 기술 이름optimizer cardinality estimates versus observed execution metrics

21. nested loop node의 rows와 loops를 왜 함께 봐야 하나요?

안쪽 node의 actual rows는 보통 loop 한 번당 값으로 표시될 수 있고, 실제 반복 일은 loops와 함께 해석해야 합니다. rows만 떼면 여러 번 재실행된 비용을 작게 볼 수 있습니다.

Rows Removed by Filter, buffer hit/read, sort 방식과 memory spill도 병목 위치를 설명하는 관찰 단서입니다. 한 숫자만으로 plan 전체를 판정하지 않습니다.

실제 기술 이름nested-loop per-loop cardinality and cumulative work interpretation

22. index가 있는데도 Seq Scan이 나올 수 있나요?

그렇습니다. 많은 행을 읽는 조건, 작은 table, 낮은 선택도, 오래된 통계, 비용 설정에 따라 sequential scan이 더 싸다고 판단될 수 있습니다. index 존재는 optimizer에게 후보를 줄 뿐 사용을 강제하지 않습니다.

W13의 before·after plan과 manifest를 연결할 때는 실제 filename·hash·plan field를 읽어야 합니다. “index가 있으니 빨라졌다”는 문장만으로는 증거가 부족합니다.

실제 기술 이름cost-based scan choice with index availability but no usage guarantee

23. Q26의 중복 correlation_id 결과는 무엇을 증명하나요?

illustrative workbook query는 correlation_id로 GROUP BY하고 HAVING COUNT(*) > 1인 후보만 남깁니다. 고정 seed에서는 CORR-DUP|2 한 줄입니다.

이 결과는 fraud나 같은 logical request라는 판정이 아닙니다. application V001에는 correlation_id UNIQUE가 있지만 workbook schema는 중복 fixture를 허용하므로 두 schema 계약을 섞어 넣을 수도 없습니다.

실제 기술 이름duplicate-candidate detection with GROUP BY and HAVING, not fraud adjudication

24. D6의 75분 압축 세트가 full mock이 아닌 이유는 무엇인가요?

artifact 계약에 full_exam=false가 명시되고, CSV의 실제 question_count를 기록하도록 되어 있습니다. 75분은 상한이며 50문항·90분 full mock으로 늘려 말하면 안 됩니다.

window·NULL·subquery·transaction 혼합 문항을 푼 뒤 item별 answer, result, confidence와 근거를 남기는 압축 누적 연습입니다.

실제 기술 이름bounded cumulative mock artifact with explicit full-exam false contract

25. high-wrong과 low-right를 왜 점수와 별도로 기록하나요?

high-wrong은 확신 있게 틀린 답이라 개념 모델이 잘못됐을 가능성이 높고, 우선 복구 대상입니다. low-right는 맞았지만 근거가 약해 우연일 수 있으므로 다시 설명해야 합니다.

confidence calibration은 정답률만으로 보이지 않는 오답 재발 위험을 찾습니다. 빈 confidence나 사후에 꾸민 숫자는 실제 first answer의 확신을 대신하지 못합니다.

실제 기술 이름confidence calibration and high-confidence error prioritization

26. D1–D6의 학습 시간 합계는 왜 p547의 주간 합계와 다른가요?

D1 10–25분, D2 10–25분, D3 50–85분, D4 10–25분, D5 50–85분, D6 30–55분을 더하면 2시간 40분–5시간입니다.

p547의 2시간 50분–5시간 20분은 D7 10–20분까지 포함합니다. strict D1–D6 미리보기에서는 D7 시간을 가져오지 않습니다.

실제 기술 이름scope-normalized effort total excluding D7

27. LOCAL_ARTIFACT_VALIDATED와 HUMAN_SEMANTIC_REVIEW_REQUIRED는 어떻게 함께 읽나요?

LOCAL_ARTIFACT_VALIDATED는 각 artifact의 좁은 정적 계약이나 sentinel 검사를 통과했다는 marker입니다. regex 기반 CTE 검사는 완전한 PostgreSQL parser가 아니고, expected marker가 있다고 모든 SQL 의미가 맞는 것도 아닙니다.

그래서 HUMAN_SEMANTIC_REVIEW_REQUIRED가 남습니다. source provenance, query grain, 업무 가정, 최신 실행 evidence를 사람이 확인해야 current Green을 말할 수 있습니다.

실제 기술 이름structural and sentinel validation with mandatory semantic review boundary

28. 코드 뒤풀이의 canonical 5개와 illustrative 4개를 어떻게 읽어야 하나요?

canonical 5개는 compose, V001 migration, reconcile drill, reconcile runner, CTE validator입니다. illustrative 4개는 ranking, reconcile CTE, Q25, Q26 SQL이며 audit-authored fixture-bound 학습용 예시입니다.

illustrative SQL은 shipped learner 정본 답안이 아닙니다. 코드 문서는 W17 전체 source를 설명하므로 D7·주간 통합 자료도 다룰 수 있지만, 이 미리보기의 설명과 질문은 p572 D6 최종 Gate까지만 유지합니다.

실제 기술 이름canonical-versus-illustrative provenance with scope-aware evidence claims