본문으로 건너뛰기

© 2026 Molayo

Qiita헤드라인2026. 05. 14. 04:12

AI와 무료 인프라로 「도쿄의 DJ 이벤트 정보 사이트」를 자동 생성하고 있는 이야기

요약

본 글은 도쿄의 로컬 DJ 이벤트 정보를 수집하고 정리하는 웹사이트를 구축한 과정을 기술적으로 설명합니다. 이 프로젝트는 단순히 데이터를 스크레이핑하는 것을 넘어, LLM(대규모 언어 모델)을 활용하여 비정형 데이터(Unstructured Data)를 정규화(Normalization)된 구조적 데이터로 변환하는 것이 핵심입니다. 전반적인 파이프라인은 X API, OCR, Google Place API 등을 거쳐 LLM으로 데이터를 가공하고, GitHub Actions와 Cloudflare Pages 같은 관리형 서비스를 이용해 자동화된 방식으로 배포됩니다.

핵심 포인트

  • DJ 이벤트 정보의 비정형성 문제를 해결하기 위해 단순 스크레이핑 대신 LLM을 활용한 데이터 정규화(Normalization)가 필수적입니다.
  • 데이터 수집 파이프라인은 X API, OCR, Google Place API 등을 조합하여 데이터를 모으고, 이를 LLM으로 구조화된 JSON 형태로 변환합니다.
  • GitHub Actions와 Cloudflare Pages 같은 관리형 서비스를 사용함으로써 개발 과정의 추상화 수준이 높아져, 인간은 코어 가치 창출에 집중할 수 있게 되었습니다.
  • 현대적인 AI 기반 개발 환경에서는 파서, 크롤러, 스키마 정의 등 많은 부분을 AI에게 맡기고, 인간은 문제 정의와 핵심 가치(Core Value) 발굴에 집중해야 합니다.

라는, 로컬 DJ 이벤트 정보를 집약하는 사이트를 만들었습니다.

아직 β(베타) 버전이지만, 도쿄의 DJ 이벤트 정보를 수집·정리하여 목록화하고 있습니다.

이번에는 「왜 만들었는가」가 아니라, 어떻게 만들었는가

의 기술적인 이야기를 쓰겠습니다.

상당히 2026년스러운 구성입니다.

먼저 전제로서,

DJ 이벤트 정보는 너무 흩어져 있습니다.

  • X
  • Club 공식 사이트
  • Resident Advisor
  • Flyer(전단지) 이미지
  • 개인 공지

게다가,

  • 포맷이 제각각임
  • 정보가 도중에 바뀜
  • 같은 이벤트라도 표기 불일치 발생
  • DJ 이름도 불일치
  • 날짜 작성 방식도 제각각

평범하게 스크레이핑(Scraping)만 해서는 깔끔한 DB(데이터베이스)가 되지 않습니다.

즉 필요했던 것은,

「수집」

이 아니라,

「정규화 (Normalization)」

였습니다.

여기서 LLM(대규모 언어 모델)이 상당히 효과적입니다.

아주 거칠게 말하자면:

X API / Google API / Web ↓ Event raw data ↓ LLM normalize ↓ Structured Event DB ↓ Static site generate ↓ Cloudflare Pages

와 같은 구성입니다.

사상으로는,

「AI 중심 (AI-centric)」

을 철저히 하고 있습니다.

먼저 가장 강력한 정보원은 X입니다.

DJ 이벤트는,

「X에서 실시간으로」

돌아가고 있기 때문에,

이곳을 보지 않으면 시작되지 않습니다.

수집하고 있는 것은:

  • 이벤트 공지
  • 출연 공지
  • 리포스트(Repost) 연쇄
  • 플라이어(Flyer) 이미지
  • 날짜 정보
  • venue(공연장) 명칭
  • DJ lineup(라인업)

등입니다.

하지만 문제가 대량으로 있습니다.

예를 들어:

text 「이번 주 금요일!! 시부야에서 돌립니다!! 놀러 오세요~」

라고만 적혀 있기도 합니다.

일시가 어디냐고.

DJ 업계는 아직도 플라이어 문화가 강합니다.

즉:

  • 일시
  • venue
  • lineup

전부 이미지입니다.

OCR(광학 문자 인식)이 필수입니다.

예를 들어:

  • VENT
  • Vent Tokyo
  • vent
  • ベント (벤트)

전부 같습니다.

DJ 이름도 상당히 불일치합니다.

X API에는 무료 할당량이 없어 돈이 듭니다...

개인의 지갑에는 은근히 아픕니다.

Google Maps / Place API 계열도 이용.

이것은:

  • venue 정보
  • location(위치) 정규화
  • geo(지리) 보완

등에 사용하고 있습니다.

특히 공연장 정보는,

Google 측이 더 안정적입니다.

이곳이 이번의 핵심입니다.

일반적인 스크레이핑과 다른 점은,

「LLM을 활용한 데이터 정규화 (Data Normalization)」

점입니다.

예를 들어 생텍스트나 OCR 결과를 그대로 입력하여,

json { "event_name": "...", "venue": "...", "date": "...", "djs": [...] }

로 변환합니다.

나아가:

  • DJ 이름 통합
  • venue 통합
  • 날짜 보완
  • typo(오타) 수정
  • event 분류

까지 수행합니다.

즉,

「비정형 데이터 (Unstructured Data)」

를,

「정형 데이터 (Structured Data)」

로 변환하고 있습니다.

옛날처럼 정규 표현식(Regular Expression) 지옥을 쓸 필요가 없습니다.

운용의 자동화는 기본입니다.

이벤트 수집 파이프라인은 기본적으로:

「GitHub Actions」

으로 돌리고 있습니다.

예를 들어:

  • 정기 크롤링 (Crawl)
  • API fetch
  • OCR
  • LLM normalize
  • static build

전부 Actions입니다.

즉:

프론트는 Cloudflare Pages.

이것도 상당히 좋습니다.

이유:

  • 정적 사이트 속도가 매우 빠름
  • CDN 포함
  • 무료 할당량이 강력함
  • GitHub 연동이 간편함

Phase 0에는 충분합니다.

지금 시대에,

「우선 돌아가는 것을 내놓는다」라면,

이곳이 상당히 강력합니다.

최근 2026년의 개발을 하며 강하게 느낀 것은,

「개발의 추상화 수준이 높아졌다」

는 것입니다.

옛날이라면:

  • scraper 작성
  • parser 작성
  • 정규화 지옥
  • 서버 운용
  • cron
  • queue
  • worker
  • infra

와 같은 느낌이었습니다.

번거로운 것은 전부 뒤로 미뤄집니다. 품질 향상까지 손이 닿지 않습니다.

하지만 지금은,

「AI와 관리형 서비스가 인프라를 담당」

하므로,

인간은:

  • 가치 체험
  • UX
  • 정보 설계
  • 코어 밸류 (Core Value) 창출

에 집중할 수 있습니다.

이것은 상당히 큽니다.

최근에는 상당히 AI 주도(AI-driven)로 개발하고 있습니다.

특히:

  • Claude Code
  • GPT 계열
  • Codex

를 조합하면,

소규모 서비스의 개발 속도가 상당히 달라집니다.

이번에도:

  • parser
  • crawler
  • schema
  • UI
  • build pipeline

을 상당히 (거의 전부) AI에게 맡기고 있습니다.

다만 중요한 것은,

「무엇이 문제인지 (Pain Point)와 코어 밸류」

만큼은 인간이 감각을 가질 필요가 있다는 것입니다.

고통(Pain)이나 코어 밸류가 보이지 않는 분야는, 아무리 AI가 있어도 도달할 수 없습니다.

그 피부로 느끼는 감각은, 그 세계에 몸을 던져보지 않으면 절대로 알 수 없습니다.

아직 Phase 0입니다.

지금은 오로지:

  • 이벤트 정보 수집
  • 정규화 (Normalization)
  • 시각화 (Visualization)

뿐입니다.

하지만 우선은,

를 평범하게 볼 수 있는 상태를 만들고 싶습니다.

로컬 DJ 컬처 (Local DJ Culture),

정보가 너무 흩어져 있기 때문에.

AI 시대,

이런

서비스,

상당히 늘어날 것 같다고 생각합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0