다시 연 공지에서 본문이 오지 않는 까닭
어제 열었던 행사 공지를 오늘 다시 엽니다. 화면에는 어제와 같은 글이 보이는데 통신 기록에는 ‘304 Not Modified’만 있고, 새로 받은 본문은 비어 있습니다. 이 기록을 읽은 AI는 ‘공지에 내용이 없다’고 적어도 될까요?
웹에는 이미 받은 자료를 다시 쓸 수 있는지 묻는 절차가 있습니다. 클라이언트가 조건을 붙여 GET이나 HEAD 요청을 보내고 서버가 그 조건에 따라 304를 돌려주면 응답에는 본문이 실리지 않습니다. 이때 화면에 표시할 글은 앞서 저장한 사본에서 찾습니다.
‘행사 일정 A’와 판본표 v1
실습을 열면 브라우저에는 ‘행사 일정 A’와 판본표 v1이 들어 있습니다. ETag는 서버가 자료의 특정 판본을 식별하는 데 쓰는 값입니다. 브라우저는 If-None-Match 헤더에 자신이 가진 값 v1을 넣어 서버에 보냅니다.
서버의 판본도 v1이면 이 예시에서는 상태 304가 돌아옵니다. ‘응답 본문’ 칸에는 새로 온 글이 없어도 ‘표시할 문서’에는 행사 일정 A가 남아 있습니다. AI가 문서 내용에 답하려면 상태 숫자와 함께 어떤 사본을 읽었는지 확인해야 합니다.
서버의 판본을 바꾸면
이제 저장한 ETag는 v1로 두고 ‘서버 ETag’만 v2로 바꿔 보세요. 서버의 공지는 ‘행사 일정 B’로 바뀌었습니다. 이전 판본과 일치하지 않으므로 이 실습의 GET 요청에는 200과 새 본문이 돌아옵니다.
두 화면을 나란히 떠올려 보세요. 상태가 304인 화면에서는 저장해 둔 A를 읽었고, 200인 화면에서는 방금 내려받은 B를 읽었습니다. 화면을 채운 글의 출처까지 따라가면 같은 동작처럼 보이던 ‘다시 열기’의 차이가 드러납니다.
판본표만 있고 본문을 잃어버렸다면
‘처음 값으로’를 누르고 ‘저장 본문 있음’의 체크를 해제해 보세요. 판본표 v1은 남겨 둔 채 본문만 잃어버린 상황입니다. 서버의 답은 여전히 304지만 이번에는 독자에게 내줄 글이 없습니다.
이 경우에는 조건을 빼고 다시 요청해 본문을 확보할 수 있습니다. AI가 그전에 기록할 수 있는 사실은 ‘판본은 확인했고 본문은 확보하지 못했다’는 데까지입니다. 원래 문서의 길이나 문장은 본문을 얻은 뒤에 확인할 수 있습니다.