Raw SQL과 Boundary Validation으로 구축한 고신뢰성 부동산 데이터 파이프라인

Building NewHomie property analytics tool — Part 1

Meng Lin2026년 4월 16일9분intermediate

AI 요약

Context

부동산 데이터 수집을 위해 Next.js 기반 사이트를 타겟팅하였으나, Akamai 봇 탐지와 불안정한 데이터 구조로 인한 파이프라인 신뢰성 확보가 필수적인 상황. 초기 LLM 생성 코드의 중복 검증 로직과 추상화된 SQL 쿼리 빌더 사용으로 인한 데이터 오염 문제가 발생함.

Technical Solution

Next.js의 NEXT_DATA JSON 페이로드 직접 추출을 통한 HTML 파싱 오버헤드 제거 및 데이터 구조 안정성 확보
Playwright on AWS Lambda 배포를 통한 실환경 봇 탐지 우회 검증 및 빠른 반복 개발 주기 구축
Zod 기반의 Boundary Validation 도입으로 404 페이지 등 예외 케이스를 조기에 식별하여 하위 변환 로직 단순화
Kysely 등 ORM/Query Builder 대신 Raw SQL을 사용하여 테이블별 서로 다른 Upsert 및 Deduplication 전략을 명시적으로 제어
SQS 기반 워커 분산 처리 및 Grafana LGTM 스택을 통한 CPU/Memory 이용률 및 에러 패턴의 시각적 분석
AWS Batch Fargate의 프로비저닝 오버헤드(약 1분)를 고려하여 워커당 50개 지역(Locality)을 처리하는 배치 설계로 오버헤드 10% 미만 유지

실천 포인트

1. 데이터 파이프라인 설계 시 추상화된 쿼리 빌더보다 Raw SQL이 Conflict Handling의 명확성을 높이는지 검토할 것

2. 데이터 유입 접점(Boundary)에서 Zod와 같은 스키마 검증기를 배치하여 데이터 정제 비용을 최소화할 것

3. 서버리스 인프라 도입 시 프로비저닝 시간에 따른 Cold Start 오버헤드를 계산하여 적절한 배치 사이즈를 산정할 것

4. 가설 기반의 튜닝보다 OTEL과 시각화 도구를 통한 실제 병목 지점 파악 후 아키텍처를 개선할 것

태그

#Idempotency #AWS Batch #Boundary Validation #Data Pipeline #Observability

원문 읽기