당신의 크롤러가 상세 페이지 수만 건을 모은다. 저장 용량을 아끼려고 HTML 을 본문 텍스트로 바꾸고 script 태그 를 지운다. 수집은 오류 없이 끝나고 텍스트도 멀쩡하다. 그런데 지도에 찍을 좌표 칸이 전부 비어 있다 — 좌표 누락이다. 좌표는 본문이 아니라 지도 초기화 스크립트 안에만 있었다. 혹은 지도에 시·도 경계를 그리려고 Douglas–Peucker 로 폴리곤을 단순화했는데, 어떤 지역은 판이 통째로 사라지고 화면 맞춤 범위까지 엉뚱하게 잡힌다. 이번에도 오류는 한 줄도 없다.
줄이는 변환은 왜 오류 없이 내용을 버리나
원문을 줄이는 변환(텍스트 추출·도형 단순화·압축)은 입력이 그 변환의 가정을 벗어나도 실패하지 않고 그럴듯한 결과를 낸다. 그래서 변환 전과 후에 지키려는 것(필드 채움률·점 수·면적·풀어 낸 내용)을 세어 맞대 봐야 빠진 것이 보인다.
줄이는 변환은 원래 무언가를 버리는 일이다. 버리는 것이 일이니 "버렸다"는 사실만으로는 이상 신호가 안 된다. 문제는 무엇을 버려도 되는지에 대한 가정이 변환 안에 숨어 있다는 점이다.
- HTML → 텍스트 변환은 "뜻 있는 값은 본문에 있다"고 가정한다. 값이 스크립트 안에 있으면 그 값은 버려도 되는 것으로 분류된다
- Douglas–Peucker 는 "첫 점과 끝 점을 잇는 기준선이 있다"고 가정한다. 닫힌 고리는 첫 점과 끝 점이 같아 기준선 길이가 0 이고, 모든 점의 거리가 0 으로 계산돼 고리 전체가 두 점으로 무너진다
- 압축은 "같은 입력이면 같은 바이트"를 약속하지 않는다. DEFLATE 명세(RFC 1951)는 압축된 데이터의 형식만 정하고 압축기가 어떤 바이트를 내야 하는지는 정하지 않는다. 그래서 압축 결과를 비교하는 검사는 내용이 같아도 기계에 따라 갈린다
세 경우 모두 변환은 성공한다. 가정을 벗어난 입력이 와도 결과의 모양은 정상이고, 빠진 것은 결과만 봐서는 안 보인다. 원문과 견줘야 보인다.
무엇을 세면 되나
변환이 무엇을 지켜야 하는지 먼저 한 줄로 적고, 그것을 변환 앞뒤에서 같은 자로 잰다. 흔한 예로 옮기면 이렇다.
- 크롤링·스크래핑: 꼭 있어야 할 필드(좌표·가격·ID)의 채움률. 쇼핑몰 상품 가격이 JSON-LD 스크립트 안에만 있는 사이트를 텍스트로 바꾸면 가격 칸이 빈다. 채움률 100% 에서 0% 로 떨어지면 변환이 그 값을 버린 것이다
- 도형 단순화: 고리 하나당 남은 점 수(최소 3개 이상)와 면적. 면적이 원본의 몇 % 안쪽으로 남는지 문턱을 둔다. 폴리곤이 두 점이 되면 면적이 0 이라 바로 걸린다
- 압축·직렬화: 압축된 바이트가 아니라 풀어 낸 내용. 지키려는 것은 내용이지 압축 결과가 아니다
가정 밖의 입력은 어떻게 다루나
세는 것은 빠진 것을 알려 줄 뿐이다. 빠지지 않게 하려면 변환이 버리기 전에 가정 밖의 경우를 따로 처리한다.
- 버리기 전에 뽑는다. 스크립트를 지우는 정리 단계 앞에서 스크립트 안의 값(좌표·ID)을 먼저 정규식이나 파서로 뽑아 따로 저장한다. 원문을 버리는 단계는 맨 마지막에 둔다
- 가정을 깨는 꼴을 갈라서 넣는다. 닫힌 고리는 시작점에서 가장 먼 점으로 둘로 나눠 각각 단순화한 뒤 잇는다. 나눌 수 없을 만큼 작은 고리는 단순화하지 않는다
- 작은 표본으로 먼저 돌린다. 전수 수집·전체 변환 전에 수백 건만 돌려 필드 채움률과 점 수를 확인한다. 몇 시간짜리 전수를 다 돌린 뒤에 빈 칸을 발견하면 다시 돌려야 한다
- 검사가 지키는 것을 결과물이 아니라 내용에 둔다. 커밋해 둔 압축 파일과 다시 구운 파일을 비교하는 테스트는 양쪽 다 압축을 푼 뒤 비교한다
에이전트에게 맡길 때는 이렇게 적어 둔다.
원문을 줄이는 변환(텍스트 추출, 도형 단순화, 압축, 요약)을 넣거나 고칠 때:
1. 이 변환이 지켜야 할 것을 한 줄로 적는다 (예: 좌표 필드, 고리당 점 수와 면적, 풀어 낸 내용).
2. 변환 앞뒤에서 그것을 같은 방식으로 센다. 줄었으면 실패로 멈춘다.
3. 원문을 버리는 단계 앞에서, 원문에만 있는 값(스크립트 안 값 등)을 먼저 뽑는다.
4. 변환의 가정을 깨는 입력(닫힌 고리, 빈 기준선 등)을 찾아 따로 처리한다.
5. 전수 처리 전에 수백 건 표본으로 2번의 수를 확인한다.
우리가 겪은 일
- 공공 정보공시 수집(2026-10): 상세 페이지 수만 건을 모으며 HTML 을 텍스트로 바꿀 때 script 를 지웠더니, 지도 초기화 코드에만 있던 위도·경도가 오류 없이 사라졌다. 정리 단계 앞에서 스크립트 안 좌표를 먼저 뽑도록 고치고, 첫 수백 건에서 좌표 채움률을 본 뒤 전수 수집을 돌렸다
- 지도 경계 판(2026-10): 시·도 경계를 Douglas–Peucker 로 줄였더니 첫 점과 끝 점이 같은 닫힌 고리가 두 점으로 무너져 판이 사라지고 화면 맞춤 범위도 틀어졌다. 고리를 시작점에서 가장 먼 점으로 둘로 나눠 줄인 뒤 잇자 판이 돌아왔다
- 구운 압축 데이터 검사(2026-10): 커밋해 둔 gzip 파일이 굽는 코드의 지금 출력과 같은지 바이트로 비교하는 테스트가 로컬에서는 통과하고 CI 에서만 실패했다. 같은 입력·같은 압축 수준이었다. 양쪽을 풀어서 내용을 비교하게 바꾸자 기계와 무관하게 통과했다
확인 목록
- 이 변환이 지켜야 할 것을 한 줄로 적었는가
- 그것을 변환 앞뒤에서 같은 자로 세는가, 줄면 멈추는가
- 원문을 버리기 전에 원문에만 있는 값을 뽑았는가
- 변환의 가정을 깨는 입력을 찾아 따로 처리했는가
- 전수 처리 전에 표본으로 채움률을 봤는가