AI 깊이 이해하기 · 12편 | 부분 관측, 오래된 스냅샷, 읽기 증거
공개 문서의 변경 사항을 보고하는 Agent가 오전 9시에 문서를 읽었다. 9시 3분에 원문이 바뀌었고, 9시 5분에 Agent는 “변경 없음”이라는 보고서를 완성했다. 비교 계산에는 오류가 없을 수 있다. 문제는 그 계산이 어느 시점의 문서를 대상으로 했는지다.
이 장면은 설명을 위해 만든 합성 사례다. 실제 서비스 장애나 모델 성능 측정 결과가 아니다. 이번 편에서는 지난 편의 작업 계약에 읽기 증거를 붙인다. 목표는 시스템 전체를 다 안다고 주장하는 것이 아니라, 지금 확보한 관측으로 어디까지 말할 수 있는지 구분하는 것이다.
1. 외부 상태, 관측, 판단을 나누기
외부 상태는 실제 문서의 내용과 버전이다. 관측은 읽기 도구가 특정 시점에 반환한 응답이다. 판단은 그 응답과 과거 기록을 이용해 만든 결론이다. 세 가지는 연결돼 있지만 같은 값은 아니다. 도구가 성공 응답을 반환했어도 캐시된 사본일 수 있고, 목록만 읽었다면 본문 변화는 아직 보지 못했을 수 있다.
부분 관측(partial observability)은 Agent가 현재 상태 전체를 직접 알 수 없고 제한된 관측을 바탕으로 판단하는 상황을 가리킨다. Poole과 Mackworth의 AI 교재는 POMDP에서 상태에 의존하는 관측과 실제 상태를 구분한다. 여기서는 그 구분을 활용한다. 웹 문서를 읽는 예제 전체를 확률 모델로 구현했다는 뜻은 아니다.
| 구분 | 합성 사례의 값 | 여기서 알 수 있는 것 |
|---|---|---|
| 외부 상태 | 9:03부터 원문 v8 | 사례를 만든 사람이 정한 실제 상태 |
| 도구 관측 | 9:00에 읽은 v7 | 그 읽기에서 v7이 반환됐음 |
| Agent 판단 | 변경 없음 | v7을 비교한 결과. 9:05의 원문 상태는 미확인 |
2. “읽었다”에 필요한 최소 기록
본문 문자열만 남기면 나중에 그 문자열이 어디서 왔는지 재구성하기 어렵다. 문서 변경 보고용으로 다음 필드를 함께 남기는 설계를 사용할 수 있다. 이 필드 이름은 교육용 제안이며 특정 제품의 표준 스키마가 아니다.
- source_id: 같은 주소처럼 보여도 다른 문서나 언어판을 혼동하지 않도록 하는 식별자
- observed_at: 응답을 확보한 시각. 문서 자체의 수정 시각과 구분한다
- version 또는 validator: 서버가 제공한 버전, ETag 등. 없으면 없다고 기록한다
- content_digest: 저장한 바이트에서 계산한 해시. 서로 다른 인코딩·정규화 방식이면 단순 비교하지 않는다
- coverage: 전체 본문인지, 목록인지, 일부 페이지인지
- read_status: 성공, 실패, 부분 응답, 미확인 등 실제 읽기 결과
observed_at은 “그때 이 응답을 받았다”는 기록이다. 원문이 그때 수정됐다는 의미가 아니다. ETag 역시 보통 시각이 아니라 선택된 표현의 검증자다. RFC 9110은 강한 ETag 비교와 약한 비교를 구분한다. 약한 ETag가 같다는 이유로 바이트까지 동일하다고 가정하면 안 된다.
3. 최신성은 한 개의 타임스탬프로 해결되지 않는다
캐시가 방금 응답했더라도 그 안의 내용은 더 일찍 만들어졌을 수 있다. RFC 9111은 캐시 응답의 나이와 freshness lifetime을 구분해 신선도를 판단한다. HTTP의 캐시상 fresh와 우리 업무의 “이 버전을 지금 사용해도 되는가”는 별도 질문이다. 캐시가 재사용해도 되는 응답이어도 업무가 더 엄격한 재확인을 요구할 수 있다.
예를 들어 교육용 작업 계약에서 관측 허용 나이를 120초로 정했다고 하자. 9:00에 확보한 관측을 9:05에 쓰면 나이는 300초다. 따라서 재확인 대상으로 분류된다. 120초는 설명용 값이며 권장 운영 기준이 아니다. 문서의 변화 빈도, 잘못 보고했을 때의 영향, 읽기 비용에 맞춰 정해야 한다.
반대로 30초 된 관측이 이 정책을 통과했다고 해서 그 사이 원문이 변하지 않았다는 증거가 생기지는 않는다. 나이 검사는 사용할 수 있는 관측을 제한하는 규칙이다. 원문의 현재 버전을 보증하는 장치는 아니다.
4. 변경 없음과 확인 실패를 분리하기
| 읽기 결과 | 가능한 결론 | 다음 처리 |
|---|---|---|
| 전체 범위, 기준과 같은 버전 | 이 관측에서 비교 대상의 변경 없음 | 관측 시각과 범위를 보고서에 남긴다 |
| 전체 범위, 다른 버전 | 비교할 새 후보가 있음 | 내용 차이를 계산한다 |
| 시간 초과 또는 일부만 반환 | 변경 여부 미확인 | 이전 결과를 최신으로 바꾸지 않고 재확인 또는 중단 |
같은 URL에 대해 적절한 조건부 요청을 보냈고 서버가 304 Not Modified를 반환했다면, 그 요청의 검증 조건에 따라 저장된 표현을 재사용할 근거가 된다. 아무 응답이나 비어 있다고 304와 같은 뜻으로 처리해서는 안 된다. 권한 오류, 누락된 페이지, 필터가 다른 목록은 각각 별도로 해석해야 한다.
5. 교육용 판정 규칙을 손으로 따라가기
아래는 HTTP 캐시 전체를 구현한 코드가 아니다. 이미 확보한 관측 메타데이터를 교육용 계약에 대조하는 작은 함수다. 네트워크 요청, 문서 읽기, 모델 호출을 수행하지 않는다. expected_source는 계약에서 정한 문서 식별자다. max_age는 응답 확보 이후의 허용 경과 시간일 뿐이다.
def assess(obs, now_s, max_age, expected_source):
if obs["source_id"] != expected_source:
return "wrong_source"
if obs["status"] != "ok" or not obs["complete"]:
return "unknown"
age = now_s - obs["observed_at_s"]
if age < 0:
return "clock_error"
if age > max_age:
return "recheck"
return "usable_observation"가상의 시계에서 9:00을 0초, 9:05를 300초로 둔다. source_id가 맞고 status가 ok이며 complete가 참인 관측에서 observed_at_s=0, now_s=300, max_age=120이면 recheck다. now_s=30이면 usable_observation이다. 두 번째 반환값은 최신 원문 보증이나 내용의 진실성 판정이 아니다. 정해진 입력 조건을 충족했다는 뜻이다.
이 코드는 학습용 예시로 제시한다. 여기서 실제 사이트의 읽기 성공률, 지연 시간, 모델 정확도를 측정하지 않았다. 운영 코드로 옮길 때는 필드 타입 검증, 시계 차이, 부분 응답 판정, 캐시 메타데이터와 문서별 버전 정책을 추가해야 한다.
6. 재확인해도 남는 시간의 틈
보고서 생성 직전에 원문을 다시 읽으면 오래된 입력을 사용할 위험을 줄일 수 있다. 그러나 재확인 직후 원문이 다시 바뀔 수 있다. 따라서 “현재 원문과 언제나 일치한다”는 결론 대신 “이 관측 시각의 이 버전을 바탕으로 작성했다”는 결론을 저장하는 편이 정확하다.
동일 서비스가 조건부 쓰기를 지원한다면 관측한 버전이 아직 일치할 때만 변경을 허용하는 방법을 검토할 수 있다. RFC 9110의 If-Match가 그 예다. 이 연재의 문서 보고 Agent는 원문을 수정하지 않으므로 그런 쓰기를 수행하지 않는다. 여러 원문을 차례로 읽었다고 해서 모든 문서의 동일 순간 스냅샷이 확보되는 것도 아니다.
7. 이번 편에서 작업 계약에 추가할 것
- 읽을 대상과 범위: 어떤 문서의 어느 표현을 비교하는가
- 근거의 묶음: 관측 시각, 버전 또는 검증자, 본문 해시, 읽기 결과
- 미확인 처리: 읽기 실패와 변경 없음을 구분하고 이전 근거를 최신으로 승격하지 않기
- 보고 범위: 확인한 버전과 시각을 명시하고, 확인하지 못한 범위를 함께 남기기
문서가 변했는지 모르는 상태에서 그럴듯한 보고서를 더 길게 쓰는 일은 도움이 되지 않는다. 이번 편의 산출물은 답변 한 문장에 붙일 수 있는 읽기 증거다. 다음 편에서는 그 증거와 보고서 파일, 작업 진행 상태를 어떻게 연결해 저장할지 살펴본다.
이어 읽기
- 1편: LLM의 학습과 추론, 연재의 전체 출발점
- 11편: AI Agent 자율성 설계와 작업 계약
- 기초 글: Context에 무엇을 남길 것인가
- 다음 13편: 작업 진행과 외부 상태를 일치시키는 상태 전이와 불변 조건
참고 자료
- Poole·Mackworth, Artificial Intelligence 3E, 12.5 Decision Processes: 완전 관측과 부분 관측의 구분
- RFC 9110, 8.8.3 ETag 및 13.1 Preconditions: 검증자와 조건부 요청
- RFC 9111, 4.2 Freshness: 캐시 응답의 신선도
자료 확인: 2026-10-03. 모든 시각·버전·정책 값은 명시된 합성 예시이며 실서비스 측정값이 아니다.