민간 경매정보사이트(지지옥션, 굿옥션, 옥션원 등) 수준의 서비스를 구축하려면 단순 크롤러가 아니라 데이터 수집 → 정규화 → 분석 → 검색 → 서비스 제공까지 포함된 전체 데이터 플랫폼 아키텍처가 필요합니다.
아래는 실제 상용 서비스 수준의 아키텍처를 단계별로 상세히 설명한 것입니다.
1. 전체 시스템 아키텍처 개요
[법원 경매정보 사이트]
↓
[크롤러 Cluster]
↓
[Raw Database]
↓
[ETL / 데이터 처리 서버]
↓
[분석 서버]
↓
[검색 서버]
↓
[API 서버]
↓
[Web / Mobile 서비스]
각 계층은 독립적으로 설계하는 것이 핵심입니다.
2. Layer 1 — 크롤러 시스템 (Data Ingestion Layer)
가장 중요한 핵심 구성 요소입니다.
역할
- 법원경매정보 데이터 수집
- 사건, 물건, 기일, 결과, 문서 수집
- 변경사항 감지
크롤러 서버 구성
Crawler Master
├ Scheduler
├ Job Queue
└ Worker 관리Crawler Worker
├ HTTP 요청
├ 데이터 파싱
└ DB 저장
기술 스택 (추천)
| 구성 | 기술 |
|---|---|
| 언어 | Python |
| HTTP | requests, httpx |
| 파싱 | BeautifulSoup, lxml |
| 브라우저 자동화 | Selenium, Playwright |
| 작업 스케줄 | Celery, cron |
| 큐 | Redis, RabbitMQ |
Worker 구조 예시
def crawl_case(case_id):
html = request(case_url)
parsed = parse(html)
save(parsed)
크롤링 전략
1. Full crawl (최초 1회)
전체 사건 수집
2. Incremental crawl (이후)
변경된 사건만 수집
기준:
- 사건번호
- 수정일
- 기일 변경 여부
3. Layer 2 — Raw Database (원본 저장소)
크롤링 데이터를 그대로 저장
정규화하지 않은 상태
추천 DB
PostgreSQL (강력 추천)
또는
- MySQL
- MongoDB (보조용)
테이블 구조
사건 테이블
cases
-----
id
court
case_number
case_year
created_at
updated_at
물건 테이블
properties
-----------
id
case_id
address
minimum_price
status
created_at
기일 테이블
auctions
---------
id
property_id
auction_date
result
price
문서 테이블
documents
----------
id
property_id
type
file_url
4. Layer 3 — ETL / 데이터 처리 서버
Raw 데이터를 정규화하고 분석용으로 변환
ETL = Extract Transform Load
역할
Raw data
↓
정규화
↓
분석용 DB 저장
수행 작업
주소 정규화
서울특별시 → 서울
숫자 변환
1,000,000 → 1000000
중복 제거
ETL 기술
추천:
- Python
- Apache Airflow (대형 시스템)
5. Layer 4 — 분석 서버 (Analysis Layer)
민간 경매사이트의 핵심 경쟁력
단순 데이터 → 분석 데이터로 변환
분석 종류
1. 권리분석
등기부 기반
근저당
임차인
전세권
권리 위험도 계산
2. 낙찰가 분석
낙찰가율 =
낙찰가 / 감정가
3. 투자 수익률 계산
ROI 계산
4. 시세 비교
외부 데이터 연동:
- 국토부 실거래가
- 네이버 부동산
6. Layer 5 — 검색 서버 (Search Layer)
빠른 검색을 위해 필요
일반 DB로는 속도 부족
추천 기술
Elasticsearch
역할
빠른 검색 가능:
서울 아파트
감정가 5억 이하
유찰 2회 이상
검색 속도:
10ms 수준
Elasticsearch 구조
index: properties
document:
address
price
auction_date
7. Layer 6 — API 서버 (Application Layer)
Frontend와 Backend 연결
역할
검색 요청
↓
DB 조회
↓
JSON 반환
추천 기술
| 기술 | 추천 |
|---|---|
| Python | FastAPI (강력 추천) |
| Node.js | Express |
| Java | Spring Boot |
API 예시
GET /api/properties?city=서울&price_max=500000000
응답:
{
"results": [...]
}
8. Layer 7 — Frontend (Web / Mobile)
사용자 인터페이스
Web
추천:
- React
- Next.js
Mobile
추천:
- Flutter
- React Native
9. 캐시 시스템 (필수)
성능 향상
Redis 사용
검색 결과 캐시
인기 물건 캐시
속도:
DB 100ms
Redis 1ms
10. 파일 저장소
감정평가서 등 저장
추천:
- AWS S3
- 또는 로컬 storage
11. 전체 아키텍처 다이어그램
[법원경매정보]
│
┌───────┴────────┐
│ Crawler Cluster │
└───────┬────────┘
│
[Raw DB]
│
[ETL 서버]
│
[Analysis DB]
│
┌─────────────┴─────────────┐
│ │
[Search Server] [API Server]
│ │
└─────────────┬─────────────┘
│
[Frontend]
12. 서버 구성 예시 (실제 서비스 기준)
초기:
Crawler 서버 1대
DB 서버 1대
API 서버 1대
Web 서버 1대
확장:
Crawler 서버 3~10대
DB 서버 cluster
Search 서버 cluster
API 서버 load balancing
13. 추천 클라우드 구성
AWS 기준
EC2 → 서버
RDS → DB
S3 → 파일
ElasticSearch → 검색
Redis → 캐시
14. 데이터 흐름 예시
크롤러 실행
↓
법원 사이트 요청
↓
데이터 수신
↓
Raw DB 저장
↓
ETL 실행
↓
Analysis DB 저장
↓
Elasticsearch index
↓
사용자 검색
↓
API 반환
15. 실제 상용 서비스 핵심 기술 TOP 5
가장 중요:
- 크롤러 안정성
- DB 설계
- 검색 속도 (Elasticsearch)
- 권리분석 엔진
- 캐시 시스템
16. 권장 기술 스택 (최적 조합)
Crawler → Python + requests
DB → PostgreSQL
Search → Elasticsearch
Cache → Redis
Backend → FastAPI
Frontend → React
Storage → AWS S3
Infra → AWS EC2
17. 개발 난이도 (현실 기준)
| 수준 | 기간 |
|---|---|
| 기본 크롤러 | 1~2주 |
| DB 구축 | 2주 |
| API 서버 | 2주 |
| 검색 서버 | 2주 |
| 전체 시스템 | 2~4개월 |
| 상용 서비스 수준 | 6개월~1년 |
18. 핵심 결론
민간 경매사이트는 단순 웹사이트가 아니라
데이터 플랫폼 + 분석 시스템 + 검색 엔진의 조합입니다
핵심 구성:
Crawler
DB
ETL
Analysis
Search
API
Frontend
Cache
원하시면 다음도 매우 구체적으로 설명해드릴 수 있습니다:
- 실제 PostgreSQL 테이블 설계 (SQL 포함)
- Elasticsearch index 설계
- Python 크롤러 전체 코드
- FastAPI 서버 구현 예제
- AWS 배포 아키텍처