경력·사례·글은 한국어 원문으로 제공됩니다.

← 모든 기록

기술 글 / 데이터

Ego Lite·Jina·Exa의 웹 수집 최신성 비교

Ego Lite와 Agent Reach의 Jina·Exa backend로 같은 URL의 변경을 읽었다. 본문 숫자와 SHA-256을 대조하니 호출 성공과 현재 내용 확보는 다른 결과였다.

작업 2026.10

약 7분 소요3,160자

#11월 2일 추가 · 실제 기사 관측은 마감했다

후속 관측은 10월 30일 04:20 KST에 종료했다. 누적 원문 ID 208개에서 동일 원문의 일반 업데이트 14건을 확인했다. 표기·문법 교정 2건은 이 14건에 포함되며 따로 더하지 않는다. 사실 정정과 기사 삭제는 각각 0건이어서, 실제 정정·삭제의 감지율이나 누락률은 측정하지 못했다.

중간 기록에서 Exa가 확보하지 못했던 FN 교정문과 UPS의 새 제목은 이후 확보했다. 반면 다른 표본 한 건의 현재 제목은 종료까지 확보하지 못했다. 이 차이에는 요청 간격·순서와 공급자 대기 공백이 포함되므로 엔진 고유 속도로 해석하지 않았다.

아래 7/7·0/7 표는 내용을 직접 바꾼 합성 시험의 결과다. 실제 기사 관측의 최종 성공률이 아니며, 후속 확보가 있었다고 합성 시험의 당시 결과를 덮어쓰지도 않았다.

#10월 28일 중간 기록

#성공한 요청에서 놓친 것

수집 도구가 성공했다고 답하면 우선 요청은 끝났다고 생각하기 쉽다. 그런데 페이지를 직접 열었을 때 보이는 문장과 도구가 돌려준 문장이 달랐다. 본문이 바뀌었는데 이전 내용이 남아 있는 경우를 따로 확인해야 했다.

202를 받았는데 아무것도 수집되지 않았다에서는 요청 접수와 처리 완료를 구분했다. 이번에는 처리가 끝난 뒤 받은 내용이 얼마나 최신인지 살폈다.

실제 기사 변경을 기다리는 관측과, 내가 내용을 바꿀 수 있는 시험 페이지를 나눴다. 시험 페이지의 회사·기사·숫자는 모두 가상으로 만들었다. 실제 기사에서는 언제 어떤 내용이 바뀔지 통제할 수 없었기 때문이다.

브라우저 쪽은 Ego Lite로 페이지를 열었다. Reader 쪽은 Agent Reach 1.6.0의 고정 CLI에서 --backend jina와 --backend exa를 지정했다. 요청 제한은 --timeout 25, 동시 읽기는 2개로 유지했다. Jina에는 기존의 X-No-Cache: true도 그대로 보냈다. 도구나 대기 조건을 매번 바꾸면 본문 차이의 원인을 좁히기 어려웠다.

Jina Reader 저장소는 URL을 읽을 본문으로 바꾸는 상위 프로젝트의 설명이고, Exa Contents 문서는 URL 내용 조회 API의 설명이다. 여기의 비교는 고정한 Agent Reach 경로를 사용한 결과다. 두 서비스를 모든 옵션으로 시험한 결과는 아니다.

#주소를 그대로 두고 내용을 바꿨다

Ego Lite, Jina, Exa가 같은 URL의 최초 본문을 확보한 뒤 제목만 바꾸고, 본문의 숫자를 바꿨다. 이어 삭제 안내, 삭제 상태 재확인, 정상 복구, HTTP 503 오류, 오류 후 복구를 차례로 만들었다.

이 7회 변경 관측에서 Ego Lite와 Jina는 각각 7/7 현재 상태를 확보했다. Exa는 0/7로 이전 기준선을 계속 반환했다. 최초 읽기를 포함한 호출·탐색은 세 방법 모두 8/8 성공했다.

방법호출·탐색 성공변경 후 내용 일치
Ego Lite8/87/7
Jina8/87/7
Exa8/80/7

가상 본문을 100건에서 120건으로 바꾼 단계가 작은 대조군이었다. Ego와 Jina에는 새 숫자 120건이 있었고, Exa에는 이전 숫자 100건이 남았다. 삭제 안내를 띄운 뒤에도 Exa에서는 과거 본문이 돌아왔다.

제목·숫자·삭제와 오류 문구를 직접 대조하고, 응답 본문의 SHA-256도 비교했다. Exa의 최초 읽기와 이후 7개 응답은 해시가 모두 같았다. 해시는 같은 내용이 돌아왔는지 확인하는 보조 수단이다. 해시가 달라졌다는 이유만으로 사실 정정이라고 세지는 않았다. 이 결과만으로 공급자 내부의 캐시 위치나 갱신 주기를 알아낸 것도 아니다.

#오류 페이지도 읽기에는 성공했다

Agent Reach의 Jina 결과는 원 서버가 HTTP 503을 반환할 때 오류 안내를 가져왔지만 ok: true였다. 이 값은 수집 도구의 결과 필드다. 원 서버가 정상 기사에 HTTP 200을 보냈다는 뜻이 아니다. 필요한 상태를 읽어 온 셈이지만, 이 플래그만 보고 정상 기사로 저장하면 뜻이 달라진다.

그래서 오류 문구가 있는지, 정상 본문은 없는지, 복구 후에는 현재 제목과 본문이 돌아왔는지 확인했다. 삭제도 첫 안내 한 번으로 확정하지 않고 다음 관측에서 같은 상태가 유지되는지 봤다.

속도 비교에도 주의가 필요했다. 상태 변경 뒤 요청 시작을 맞추려고 약 6초를 기다렸고 방법마다 계측 위치도 달랐다. 기록된 경과 시간을 그대로 엔진 속도 순위로 바꾸지 않았다.

#합성 시험과 실제 기사는 따로 남겼다

보존된 실제 응답을 다시 읽는 재생 검사 16개도 통과했다. 이 검사는 판정 규칙과 기존 사건의 분류를 확인한 것이다. 새 네트워크 요청으로 얻은 감지 속도는 아니다.

실제 기사 관측에서 일반 설명 추가를 확인한 경우에도 사실 정정이나 삭제로 세지 않았다. 제목·본문이 달라진 것, 잘못된 사실이 바로잡힌 것, 기사가 사라진 것은 각각 근거가 필요했다. 합성 페이지에서 삭제를 감지한 결과도 실제 언론사의 삭제 성공 건수에 더하지 않았다.

이 결과는 같은 URL을 짧게 관측한 시험에 한정된다. 주소 조건이 달라지면 갱신 양상도 달라져 추가로 비교했다. 이 표로 실제 기사의 정정·삭제 누락률이나 최초 감지 지연을 계산하지는 않았다.

이후 실제 기사 관측에는 공백이 생겼다. Reader가 공급자 대기 상태에 들어가 Jina와 Exa 요청을 실행하지 못한 회차가 있었다. 그동안 Ego 관측은 이어갔지만, 그 결과로 Reader의 빈칸을 채우지 않았다. 회전 표본을 바꾼 경우에도 Reader의 첫 본문을 확보하지 못했다면 기준선 미확보로 남겼다.

요청했지만 실패한 것, 보내기 전에 거절된 것, 대기 때문에 요청하지 않은 것은 서로 다른 기록이었다. 이 중간 기록 이후 관측은 10월 30일 04:20 KST에 마감했다. 최종 결과에서도 Reader의 공백과 실제 사실 정정·삭제 사건이 없었다는 한계를 함께 읽어야 한다.

지금 남길 수 있는 판단은 분명하다. 수집 완료 플래그 뒤에 현재 제목과 본문을 대조하는 검사가 더 필요했다. 이후 운영 수집 방식을 바꿀지는 그 검사 결과를 쌓은 뒤 판단할 일이다.

작성 2026-11-03

2026년 10월 28일 통제 시험·중간 기록에 10월 30일 최종 마감 결과를 추가했다. 공급자 대기로 요청하지 못한 관측도 포함한다. 실제 언론사 정정·삭제 성능과 공급자 전체의 우열은 미검증이다.