Show GN: 핫딜모음 게시판 여러 곳 크롤링해서 AI로 요약해주는 사이드 프로젝트 만들었습니다 (핫덕) — 개발자가 알아야 할 핵심 정리

Show GN: 핫딜모음 게시판 여러 곳 크롤링해서 AI로 요약해주는 사이드 프로젝트 만들었습니다 (핫덕)

1. 핫딜 크롤링 + AI 요약, 왜 필요한가

핫딜 정보를 찾는 한국 사용자에게 '뽐뿌, 에펨코리아, 클리앙, 퀘이사존, 루리웹' 같은 다양한 커뮤니티를 매번 직접 둘러보는 일은 시간 소모가 크다. 같은 핫딜이 여러 게시판에 중복으로 올라가기도 하고, 본문이 길어 어떤 딜이 핵심인지 한눈에 들어오지 않을 때가 많다. 핫덕은 이런 불편함을 줄이기 위해 등장한 사이드 프로젝트로, 여러 커뮤니티의 핫딜 게시글을 자동으로 수집하고 AI가 핵심만 추려 요약해 보여준다.

긱뉴스 원문 설명에 따르면 핫덕은 '뽐뿌, 에펨코리아, 클리앙 등 주요 핫딜 게시판을 주기적으로 크롤링'해 각 딜의 '핵심 정보(가격, 배송비, 만료일 등)'를 추출하고, LLM으로 한 줄 요약 + 태그 분류까지 수행한다. 사용자 입장에서는 무한 스크롤로 새 딜이 쌓이는 피드를 받게 되므로, 원하는 카테고리(가전/게임/식품 등)만 필터링해서 받아볼 수도 있다.

2. 아키텍처 — 크롤러 + LLM 요약 + 알림

핫덕의 핵심 구조는 크게 세 컴포넌트로 나뉜다. 첫 번째는 크롤러로, 각 커뮤니티의 핫딜 게시판을 주기적으로(예: 5~10분 단위) 탐색해 신규 글을 수집한다. 두 번째는 중복 제거 + 정규화 단계로, 동일 딜이 여러 게시판에 올라온 경우를 상품명·가격·URL 해시로 병합한다. 세 번째는 LLM 요약 단계로, OpenAI·Anthropic·로컬 LLM 등 다양한 백엔드를 사용해 '한 줄 요약 + 카테고리 태그'를 생성한다. 마지막으로 알림 단계에서 텔레그램/디스코드/웹훅으로 구독자에게 새 딜을 푸시한다.

LLM 요약 단계의 핵심 설계 결정은 (a) '요약 길이'를 1~2줄로 강제해 모바일 푸시 알림에 들어가게 하거나 (b) 가격/배송비 같은 구조화된 필드는 별도 컬럼으로 추출해 필터링 가능하게 만드는 것이다. 핫덕은 후자 쪽에 가까운데, JSON 스키마로 정의된 필드를 우선 추출하고 자연어 한 줄 요약은 그 위에 얹는 방식으로 구현한 것으로 보인다. 이런 구조화 추출은 function calling 또는 JSON mode를 지원하는 모델에서 안정적으로 동작한다.

async def summarize_deal(raw_text: str) -> dict:
    """크롤링한 원문을 (1) 구조화 필드 + (2) 자연어 한 줄 요약으로 변환."""
    prompt = f"""다음 핫딜 게시글에서 핵심 정보를 추출하세요.
    - product: 상품명 (브랜드 + 모델명)
    - price_krw: 가격(원) 정수
    - shipping_krw: 배송비(원) 정수, 없으면 0
    - expires: '오늘 자정' 같은 상대 만료 표현 또는 ISO 날짜
    - summary: 50자 이내 한국어 한 줄 요약

    게시글: {raw_text}
    JSON만 출력하세요."""
    resp = await llm_client.chat(prompt, response_format={'type':'json_object'})
    return json.loads(resp.text)

3. 운영하면서 부딪힌 함정 — 봇 차단 + 가격 변동

핫딜 크롤러를 운영하면서 가장 자주 만나는 문제는 사이트의 봇 차단이다. 에펨코리아와 클리앙은 짧은 주기로 동일 IP에서 다수 요청이 들어오면 CAPTCHA 또는 임차단으로 대응한다. 현실적인 회피책은 (a) 커뮤니티별 User-Agent + 적절한 요청 간격(예: 5~10초), (b) requests.Session으로 쿠키를 유지하면서 사람처럼 보이는 패턴 유지, (c) RSS 피드가 제공되는 커뮤니티는 RSS 우선 사용 (봇 차단 회피) 정도다.

또 다른 함정은 가격 변동이다. 핫딜은 본문 작성 시점과 사용자가 알림을 받는 시점 사이에 가격이 바뀌거나 품절되는 일이 잦다. 핫덕이 이런 경우를 어떻게 처리하는지 정확히 명시되어 있지는 않지만, 일반적인 접근법은 (1) 알림 발송 직전에 원본 URL을 다시 fetch해 가격을 재확인하고, 변동 시 '가격 변동' 플래그를 붙여 발송하거나, (2) TTL이 짧은 (예: 1~2시간) 캐시만 사용해 너무 오래된 딜은 노출하지 않는 것이다.

4. 실전 활용 — 나만의 핫딜 큐레이션

핫덕 같은 프로젝트는 백엔드 개발자라면 주말 작업으로 만들어볼 만한 규모다. 기술 스택은 FastAPI + Celery(주기적 크롤링) + Postgres(딜 저장) + OpenAI/Anthropic API(요약) 정도면 충분하고, 알림은 텔레그램 봇으로 연결하면 모바일에서 즉시 확인 가능하다. 실제 배포까지 가지 않더라도 로컬에서 돌려서 '관심 카테고리'만 RSS로 받아보는 형태면 일상적인 핫딜 탐색 시간을 크게 줄일 수 있다.

더 작은 시작점으로, 처음부터 직접 크롤러를 만들지 않고 RSS-Bridge 같은 중간 매개를 활용해 봇 차단을 우회하거나, Hugging Face의 transformers 로 로컬 LLM(Qwen2.5-7B 정도)을 돌려 API 비용을 0으로 만드는 것도 가능하다. 어차피 핵심 가치는 '크롤링 + 중복 제거 + 요약'을 한 파이프라인으로 묶는 아이디어이므로, 스택 선택은 자유도가 높다.

5. 요약 — 핫덕에서 배울 수 있는 패턴

핫덕은 '여러 소스의 비슷한 정보를 한 곳에서 요약해 보여주는' 구조로, LLM 시대의 대표적인 활용 패턴이다. 핫딜 도메인뿐 아니라 (a) GitHub trending + Reddit 토론 요약, (b) IT 뉴스 여러 매체 통합 피드, (c) 채용 공고 중복 제거 + 요약 같은 다양한 도메인으로 동일한 패턴을 확장할 수 있다. 크롤링 + LLM 요약 + 알림의 3단 구조는 LLM 기반 개인 프로젝트를 구상할 때 가장 먼저 떠올릴 수 있는 청사진이라, 핫덕의 README와 코드를 한 번 훑어보면 다양한 사이드 프로젝트 아이디어로 분기할 수 있다.

원문: 긱뉴스 토픽 #31942

---

📰 원본 출처 · https://news.hada.io/topic?id=31942 (#N=31942)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.