Gold: 64-state evidence shiproom에서 release를 방어한다

오늘의 질문

malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다. 이를 생략하면 demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다. 상황에서도 데모는 보일 수 있지만 제품·검증·운영 책임을 방어할 수 없습니다.

아직 답을 몰라도 괜찮아요. 아래 작은 예시를 보고 먼저 예상해 보세요.

01 · 혼자 확인해요

연습한 문제를 다시 풀며 혼자 확인하기

지금은 방금 연습한 문제를 다시 보는 시간이에요.아직 “완전히 익혔다”고 기록하지 않아요. 나중에 모양이 다른 문제도 도움 없이 풀면 그때 다시 확인할 수 있어요.

답과 과정 확인: 80% 이상
내 말로 설명: 80% 이상
막힌 곳 고치기: 80% 이상
다른 문제에 써보기: 80% 이상

스스로 확인하며 작성 중인 답0 / 4

01
먼저 생각하기 · 기초
cp64 predict · Gold: 64-state evidence shiproom에서 release를 방어한다: AI 없이 “demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.”를 실행했을 때 exit·state·artifact·evidence가 어떻게 달라질지 먼저 예측한다.
상황
깨진 입력·429 의존성·모호한 commit crash·artifact drift를 demo-only부터 evidence-first-release까지 네 정책으로 처리합니다.
문제
각 scenario-policy 조합의 final verdict와 release gate 결과를 예측하고, final phase 전에는 왜 판정을 봉인해야 하는지 설명하세요.
제공 자료
- Input fixture: 4 scenarios × 4 policies, phase 1–3 evidence partial, phase 4 release replay
- guarded-run은 위험한 실행을 멈출 수 있지만 모든 scenario의 복구·재현 증거를 만들지는 않습니다.
- tested-recovery는 실행 복구를 증명해도 artifact drift에서는 README와 manifest gap이 남을 수 있습니다.
- evidence-first-release는 요구·실행·복구·release bundle을 모두 같은 run으로 재현합니다.
- 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
- Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
- 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
- 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
- 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.
비교표 · 외운 답에 기대지 않았는지 밝히고, 내 까닭과 “항상 맞다”는 말을 깨는 장면까지 쓰기20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.
움직임과 비교
02
내 말로 설명하기 · 익힌 것을 써보기
cp64 explain · Gold: 64-state evidence shiproom에서 release를 방어한다: malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.이 필요한 이유와 4×4×4 state receipt·acceptance trace·private fault recovery·source/test/wheel/SBOM/CI/attestation identity·AI disclosure·signed SHIP/REWORK/BLOCK verdict가 입증하지 못하는 범위를 함께 설명한다.
상황
artifact는 저장됐지만 checkpoint 전에 process가 종료되어 재시작 시 commit 여부가 모호합니다.
문제
왜 단순 retry가 중복 부작용을 만들며 stable operation id·content fingerprint·lookup·atomic checkpoint가 어떻게 exactly-once 관찰을 만드는지 설명하세요.
제공 자료
- Input fixture: operation=order-summary-17, artifact fingerprint=f17, checkpoint absent, restart
- exactly-once는 transport가 아니라 같은 logical operation의 관찰 결과가 한 건이라는 application contract입니다.
- idempotency key는 payload 의미가 같을 때만 재사용하며 다른 fingerprint와 충돌하면 차단합니다.
- lookup 결과와 local checkpoint는 같은 artifact fingerprint를 가리켜야 합니다.
- 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
- Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
- 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
- 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
- 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.
까닭을 함께 쓰는 설명 · 외운 답에 기대지 않았는지 밝히고, 내 까닭과 “항상 맞다”는 말을 깨는 장면까지 쓰기20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.
설명 기준과 비교
03
틀린 곳 고치기 · 익힌 것을 써보기
cp64 debug · Gold: 64-state evidence shiproom에서 release를 방어한다: 독립 mutant로 “demo·test·CI green 중 하나만 근거로 source·wheel·SBOM·attestation·incident·AI disclosure가 서로 다른 subject인 release를 승인한다.”를 재현하고 최초 위반 지점만 수정한다.
상황
source와 pytest는 통과하지만 README command는 삭제된 option을 사용하고 runtime manifest와 run log는 이전 dependency fingerprint를 가리킵니다.
문제
release pipeline을 단계별로 디버그해 최초 drift를 찾고, 최소 수정·regression gate·fresh-environment replay를 설계하세요.
제공 자료
- Input fixture: source r22, tests green, README --legacy, manifest fp21, run log fp21, expected fp22
- 테스트 성공은 test가 실행한 interface만 증명하며 README command의 실행 가능성을 자동 보장하지 않습니다.
- artifact drift는 파일 수정 시간보다 canonical content와 semantic command test로 판정합니다.
- 고친 bundle은 깨끗한 local sandbox에서 install·run·compare 순서로 재현합니다.
- 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
- Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
- 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
- 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
- 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.
순서대로 적기 · 외운 답에 기대지 않았는지 밝히고, 내 까닭과 “항상 맞다”는 말을 깨는 장면까지 쓰기20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.
답과 설명 함께 비교
04
새 문제에 써보기 · 새 문제
cp64 transfer · Gold: 64-state evidence shiproom에서 release를 방어한다: 실제 조직 release review를 축소한 capstone 공개 구두 방어와 operator handoff로 계약을 옮겨 AI 보조의 변경점과 사람이 최종 승인할 근거를 방어한다.
상황
AI 보조로 만든 Python CLI를 학습 demo에서 제3자가 설치·실행·실패 복구·검토할 수 있는 release candidate로 전환합니다.
문제
M1–M11 역량을 evidence chain에 배치하고 보안·SBOM·관측성·incident·AI disclosure를 포함한 evidence-first shiproom 계획을 작성하세요.
제공 자료
- Input fixture: AI-generated CLI, synthetic fixtures, partial tests, draft README, no release dossier
- M1–M11의 타입·제어·컬렉션·함수·환경·파일·예외·객체·test·API·data evidence를 현재 artifact에 연결합니다.
- secret scan·dependency inventory·least privilege·structured logging은 기능 test와 별도 gate입니다.
- AI 산출물은 prompt 공개 자체가 아니라 생성 범위·사람의 검증·독립 실행 proof로 평가합니다.
- 판정 경계: 화면의 성공 여부가 아니라 요구·인수 기준·CLI·파일·API·pandas 실행·fault recovery·source·tests·README·run log·failure review·AI disclosure의 연결 증거를 채점합니다.
- Privacy: 실제 사용자·운영 저장소·credential·환경변수·live endpoint를 읽지 않고 synthetic input과 고정된 local fixture만 사용합니다.
- 공개/비공개 경계: 공개 DTO에는 client-safe 자기검토 설명만 둡니다. executable oracle·hidden expected protocol·private deterministic seed·secret sentinel은 production import graph 밖에 둡니다.
- 검증 조건: exact Python·pytest·패키징 도구 결과를 추정하지 않습니다. 환경 플래그와 이미 준비된 로컬 QA image가 모두 있을 때만 exact-runtime 증거를 주장하며 image pull이나 다른 runtime 대체는 허용하지 않습니다.
- 과장 금지: 한 번의 성공 demo, 녹색 test, 생성된 README, AI 추천은 복구 안전성·artifact 재현성·보안·자격 합격을 보증하지 않습니다.
순서대로 적기 · 외운 답에 기대지 않았는지 밝히고, 내 까닭과 “항상 맞다”는 말을 깨는 장면까지 쓰기20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
연습과 같은 문제를 다시 풀어 보는 시간이에요. 힌트 없이 먼저 생각해 보세요. 지금 적은 답은 바로 합격으로 기록되지 않아요.
설명 기준과 비교

4개 답이 남았습니다.

02 · 나중에 한 번 더

모양이 다른 문제에서도 같은 생각을 써봐요

cp64 Gold: 64-state evidence shiproom에서 release를 방어한다: malformed input·rate-limited dependency·ambiguous commit crash·artifact drift의 네 scenario를 demo-only·guarded-run·tested-recovery·evidence-first-release 정책과 네 phase로 교차해 동일 release identity와 사람 판정으로 닫는다.의 미공개 local failure variant에서 AI 없이 acceptance trace·test·runtime receipt·recovery proof를 만들고 human accept/refactor/reject verdict를 제출한다.

검증 과제

AI가 제안한 Gold: 64-state evidence shiproom에서 release를 방어한다 구현에 ambiguous requirement, boundary input, timeout·429·5xx 또는 dtype drift, partial write, config/dependency drift, secret leakage, false-green test 중 하나 이상을 주입해 최초 contract divergence를 찾아 수정한다.