상품 페이지를 스트리밍 가지치기로 받아 수신 단계에서 메모리 바운드

[m-a-king]

Situation

• 상품 페이지를 가져올 때 응답을 통째로 메모리에 올린 뒤 잘랐다. 자르기 직전 피크가 두 배로 뛴다. 원본 바이트와 문자열 사본이 동시에 살아 있기 때문이고, 동시 파싱 수만큼 곱해진다
• 코드를 열어 보니 같은 자리에 두 가지가 더 있었다
  • Content-Type 검사 부재: 링크가 50MB 영상이나 압축파일을 가리켜도 전부 받아 HTML 로 디코딩하려 들었다
  • 이중 파싱: 같은 HTML 을 파이프라인이 한 번, 빈 셸 판정이 또 한 번 통째로 팠다

Task

원래 이슈는 "받은 뒤 자르는 지점을 앞당기자"였다. 그런데 자르는 것 자체가 손해라는 게 드러나면서, "다 받은 뒤 어떻게 자르나"가 아니라 "다 안 받는다" 로 문제를 다시 잡았다.

제약 둘: 절단도 실패도 recall 을 깎는다. 그리고 새 실패 code 를 만들면 3 repo 순차 PR 이 된다.

Action

접근 선택

안	상한을 넘겼을 때	비용	판단
초과 시 실패 (원안)	확정 실패로 종결	새 permanent code 라 카탈로그, core 매핑, extractor 로 3 repo 순차 PR	채택 안 함. 지금 앞부분으로 추출에 성공하던 페이지가 실패로 바뀐다
수신 단계에서 절단	앞부분만 남김	단일 PR	채택 안 함. JS 와 style 을 걷어내기 전에 자르면 같은 길이에 담기는 상품 정보가 준다
흘리며 가지치기	애초에 안 넘김	단일 PR	채택. 버리는 대상이 어차피 하류가 버릴 것들이라 잃는 정보가 없다

수신 단계

• 흘리며 가지치기: 응답을 스트림으로 읽으며 태그가 닫히는 순간마다 남길지 정한다. style, 주석, 데이터가 아닌 script 는 그 자리에서 버린다. 거대 inline JS 가 메모리에 한 번에 하나씩만 스쳐 간다
• Content-Type 게이트: 영상, 음성, 이미지, 압축파일 등 명백한 바이너리는 본문을 한 바이트도 안 읽고 끊는다. 다만 HTML 을 text/plain 이나 헤더 없이 주는 몰이 실재해, 거부는 명백한 것만 하고 미상은 통과시킨다
• charset 우선순위 보존: 앞 4KB 만 엿봐 인코딩을 정한 뒤 그 인코딩으로 나머지를 읽는다. 헤더, 문서 내 선언, UTF-8 순서는 그대로다
• 상한 둘: 읽을 바이트 상한(끝나지 않는 스트림용, 압축 해제 후 기준)과 남긴 분량 상한(가지쳐도 안 줄어드는 문서용). 정상 페이지는 어느 쪽에도 안 닿는다

조용히 깨질 뻔한 자리

• 구조화 파서에 평범한 JS script 를 훑어 가격을 찾는 경로가 있었다(유니클로 계열의 전역 상태 변수). "데이터 script 가 아니면 버린다"로 짰다면 그 사이트의 가격 추출이 컴파일도 테스트도 안 깨진 채 죽었다
• 반대로 LLM 입력에서는 같은 script 를 일부러 버린다. 코드 덩어리라 토큰만 먹고 오판을 부른다
• 그래서 보존 규칙이 두 벌이라는 사실 자체를 한 곳에 박고, 무엇을 찾는지 아는 쪽이 표지 상수를 소유하게 했다

규칙	남기는 것
수신 가지치기	데이터 script + 전역 상태 변수를 담은 JS script
LLM 입력	데이터 script 만

구조 정리

• 페이지 표현을 문자열에서 파싱된 문서로 바꿨다. 하류(구조화 파서, LLM 게이트, sanitize, 셸 판정)가 전부 문서를 원하고 있어 문자열은 중간 표현일 뿐이었다. 그 결과 위에 적은 이중 파싱이 함께 사라졌다
• 헤드리스 렌더 경로도 같은 가지치기를 통과시켜, 두 전략이 하류에 넘기는 문서 모양이 갈리지 않게 했다

안전 상한은 설정이 아니라 상수로

처음엔 두 상한을 기존 방식대로 @ConfigurationProperties 에 두고 이름만 새 의미에 맞게 고쳤다. 리뷰 중에 그 전제를 다시 봤다.

• 이 값들이 설정이던 근거는 이관 규율("하드코딩 상수를 외부화하되 기본값 유지")인데, 그 규율은 명시적으로 이관 기간 한정이었고 이관은 끝났다. 되돌아본 적이 없었을 뿐이다
• SSM 실측: /piki-extractor/app/ 에 있는 파라미터는 4개(Gemini 키 2개, 렌더 서비스 주소, 렌더 스위치)뿐이고 이 값들은 없다. 설정으로 둔 내내 아무도 지정한 적이 없다
• 같은 성격의 다른 상한(GeminiHtmlExtractor.MAX_LLM_CHARS 20만, 렌더 응답 해제 상한 64MB)은 이미 상수다. 이쪽만 설정이면 같은 종류가 두 방식으로 갈린다
• 튜닝 손잡이가 아니라 안전장치다. 밖에서 바꿀 수 있게 두면 조절할 일도 없으면서 키 이름이 드리프트할 자리만 생긴다

그래서 상수로 내렸다. 부수효과로 설정 키 개명 리스크 자체가 사라진다 - 옛 키로 지정해 둔 값이 조용히 무시되는 사고는 키가 없으면 일어날 수 없다.

상한을 인자로 받는 오버로드는 package-private 으로 남겼다. 상한 동작 검증에 3백만 자 픽스처가 필요해 실용적이지 않기 때문이고, 패키지 밖(수신 경계)에서는 안 보여 안전장치를 우회할 수 없다.

구현 좌표

구분	대상
신설	PruningHtmlParser
수신	HttpPageFetcher(toEntity → exchange, MAX_FETCH_BYTES 상수), FetchProperties(크기 상한 제거)
계약	PageContent(String → Document + retainedChars), DataScripts(retainForParsing), StructuredDataExtractor(표지 상수 공개)
하류	HtmlSnapshotPipeline, EmptyShellDetector, DefaultProductLinkExtractor, HttpHeadlessRenderer, HeadlessExtractionProperties

Result

• 함정이 막혔다는 증거: 기존 유니클로, Next.js 가격 보강 테스트 2개가 가지친 문서를 먹고 통과한다. 이 둘이 그 경로의 회귀 가드다
• "본문을 안 읽는다"와 "상한에서 끊는다"를 실제 바이트 수로 증명: 응답 스트림을 직접 쥐는 rig 를 만들어 읽힌 바이트를 셌다. 바이너리 6종 모두 0바이트
• 메모리 주장 자체를 테스트로 고정: 5MB 짜리 inline JS 가 섞인 문서에서 남은 분량이 1,000자 미만이고 본문은 그대로다
• 읽는 중 연결이 끊기면 일시 실패인지는 추론이 아니라 테스트로 확인했다. exchange 콜백의 IO 예외가 어떻게 번역되는지는 라이브러리 동작에 달려 있어서다
• 상한의 알갱이 한계: 남긴 분량 상한은 태그 단위로 걸린다. 거대한 텍스트 노드 하나짜리 문서는 이쪽이 아니라 바이트 상한이 잡는다
• 응답 계약 무변경: 새 code 가 없어 카탈로그와 core 매핑을 안 건드린다. 다만 비HTML 링크의 결과가 결정론적으로 바뀌어(전에는 받아서 파싱해 봐야 알았다), 그 서술은 NOT_PRODUCT_PAGE 가 비HTML 응답도 포함함을 계약에 명시 infra#55 로 먼저 반영했다
• 크기 상한의 설정 표면이 0이 됐다. fetch 설정에는 UA 와 타임아웃, redirect hop 상한만 남는다. 이건 장애 때 실제로 만지고 싶어질 수 있는 값들이라 밖에 둔다
• 바이트 상한은 주입이 아니라 실제 상수로 검증한다. 17MB 본문을 흘려 정확히 16MiB 에서 끊겼는지를 본다. 부등호로 두면 몇 바이트만 읽고 끝나도 통과해 상한이 걸렸다는 증거가 안 된다

---

연관 이슈

• close 상품 페이지 fetch 를 스트리밍 가지치기로 바꿔 수신 단계에서 메모리를 바운드한다 #47

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 835370bf-b7d2-4cc9-94f8-ad40148b9ef7

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}