ETag·Last-Modified precondition을 구분한다

오늘의 질문

strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다. weak ETag를 byte identity처럼 쓰거나 Last-Modified만으로 동시 write 충돌이 없다고 가정한다.를 방치하면 자동화가 빠르게 반복될수록 잘못된 효과와 비노출 사고도 함께 확대됩니다.

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

01 · 같이 연습해요

작은 문제부터 하나씩 직접 풀어봐요

먼저 예상하고, 한 단계씩 확인하고, 막힌 곳을 고쳐 봐요. 도움을 열어도 괜찮아요. 도움을 본 문제는 나중에 모양을 바꿔 다시 풀어보면 됩니다.

연습에서 작성 중인 답0 / 8

01
찾아보기 · 기초
aa39 recognize · ETag·Last-Modified precondition을 구분한다: strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.을 지키는 exchange와 위반하는 exchange를 header·body·effect 표식으로 판별한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
정답과 비교
02
먼저 생각하기 · 기초
aa39 predict · ETag·Last-Modified precondition을 구분한다: weak ETag를 byte identity처럼 쓰거나 Last-Modified만으로 동시 write 충돌이 없다고 가정한다.가 주입된 다음 response·effect·checkpoint 상태를 실행 전에 순서대로 예측한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
움직임과 비교
03
순서 따라가기 · 익힌 것을 써보기
aa39 trace · ETag·Last-Modified precondition을 구분한다: request 준비부터 validator kind/value hash·selected precondition·resource version·condition result receipt 확정까지 authority·attempt·effect owner를 시간순으로 추적한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
움직임과 비교
04
내 말로 설명하기 · 익힌 것을 써보기
aa39 explain · ETag·Last-Modified precondition을 구분한다: strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.이 필요한 이유를 network·application·durable-effect 경계로 나눠 설명한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
설명 기준과 비교
05
빈칸 채우기 · 익힌 것을 써보기
aa39 complete · ETag·Last-Modified precondition을 구분한다: 비어 있는 policy·guard·redaction·checkpoint 단계를 채워 conditional read와 optimistic update를 분리하는 validator policy를 구현한다.을 fail-closed로 완성한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
답과 설명 함께 비교
06
틀린 곳 고치기 · 익힌 것을 써보기
aa39 debug · ETag·Last-Modified precondition을 구분한다: weak ETag를 byte identity처럼 쓰거나 Last-Modified만으로 동시 write 충돌이 없다고 가정한다.를 local synthetic trace로 재현하고 최초 위반 지점만 수정한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
답과 설명 함께 비교
07
직접 만들기 · 새 문제
aa39 implement · ETag·Last-Modified precondition을 구분한다: conditional read와 optimistic update를 분리하는 validator policy를 구현한다.을 deterministic clock·local fake server·synthetic credential만으로 구현한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
정답과 비교
08
새 문제에 써보기 · 새 문제
aa39 transfer · ETag·Last-Modified precondition을 구분한다: 동시에 수정되는 configuration resource 안전 갱신에 계약을 이식하고 달라진 trust·quota·schedule 경계를 방어한다.
이 문제는 주어진 내용과 정답 기준을 더 만드는 중이에요. 지금 적은 답은 연습 메모로만 저장돼요.
관찰 → 규칙 → 결론 순서20자 이상 작성한 뒤 내 답과 맞춰 볼 기준을 확인하세요.
정답 대신 4단계 힌트 보기
1. 관찰
  aa39에서는 status만 보지 말고 method, normalized target, selected headers, body schema, elapsed budget, attempt와 effect receipt를 분리하세요.
2. 개념
  strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.
3. 다음 도움
  내 생각을 먼저 적고 ‘내 답과 맞춰 볼 기준 보기’을 누르면, 풀 순서와 더 자세한 도움을 열어 드려요.
설명 기준과 비교

8개 답이 남았습니다.

02 · 막힌 곳을 찾아요

틀린 답에서 생각이 갈라진 첫 지점 찾기

헷갈림 01

weak ETag를 byte identity처럼 쓰거나 Last-Modified만으로 동시 write 충돌이 없다고 가정한다.

겉으로 보이는 막힘: ETag·Last-Modified precondition을 구분한다의 성공·실패·재시도 판정이 provider 응답과 어긋나 외부 효과 상태가 모호해진다.
막힌 까닭: strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.을 request 전·response 후 guard로 실행하지 않았다.
다시 해보는 방법: conditional read와 optimistic update를 분리하는 validator policy를 구현한다.에 fail-closed guard를 넣고 동일 synthetic 사건을 replay한다.

헷갈림 02

ETag·Last-Modified precondition을 구분한다의 network receipt와 durable commit 사이에서 process가 중단된다.

겉으로 보이는 막힘: 재시작 뒤 이미 처리한 효과를 반복하거나 처리하지 않은 항목을 완료로 표시한다.
막힌 까닭: attempt·effect·checkpoint의 owner와 commit 순서가 하나의 상태 machine으로 정의되지 않았다.
다시 해보는 방법: stable run identity와 idempotent commit 경계를 추가하고 crash-before/after 변형을 모두 재생한다.

헷갈림 03

validator kind/value hash·selected precondition·resource version·condition result receipt를 만들면서 URL query·Authorization·cookie·body의 민감 값을 그대로 직렬화한다.

겉으로 보이는 막힘: 학습 artifact와 CI log에 secret 또는 private payload가 남고 증거를 안전하게 공유할 수 없다.
막힌 까닭: 관찰 후 마스킹하는 방식에 의존했고 수집 전 allowlist·synthetic sentinel scan을 두지 않았다.
다시 해보는 방법: redaction을 관찰 경계 앞에 배치하고 금지 sentinel negative control로 bundle을 다시 검증한다.

03 · 내게 맞는 도움 고르기

같은 목표를 원하는 도움만큼 연습해요

안내 받으며

안내형

ETag → Last-Modified → If-Match → precondition 순서로 request plan·response facts·effect state·next action·redacted evidence 칸을 채운다.

ETag·Last-Modified precondition을 구분한다의 request 계획, local response, policy 결정, durable effect와 redacted receipt를 번호와 선 종류로 구분한 도식에서 색상 외에도 request·response·attempt·effect·checkpoint·verdict label과 선 종류를 함께 표시한다.

혼자 해보기

내 힘으로

aa39 ETag·Last-Modified precondition을 구분한다: strong/weak entity tag와 modification date의 정밀도 차이를 이해하고 read/write 목적에 맞는 If-None-Match·If-Match·date precondition을 선택한다.의 처음 보는 synthetic fixture를 먼저 판정한 뒤 exact Python 3.14.6·Requests 2.34.2·HTTPX 0.28.1 local harness에서 replay하고 불일치만 공식 계약으로 교정한다.

공식 문서·문법·library API는 열 수 있지만 해당 변형의 exact response sequence·retry verdict·effect state·hidden grader 판정은 먼저 제공하지 않는다.

더 도전하기

심화형

동시에 수정되는 configuration resource 안전 갱신의 quota·schedule·partial failure 축을 하나 추가하고 같은 contract와 checkpoint를 deterministic replay한다.

ETag·Last-Modified precondition을 구분한다에서 throughput보다 bounded latency·중복 효과 방지·비노출·복구 가능성·운영 설명력을 우선하고 비용을 기록한다.