공모전·이벤트·공연·강연처럼 '놓치면 끝나는' 정보를 한 흐름으로 모아 D-day 중심으로 우선순위를 정해주는 큐레이션·자동화 플랫폼.

포지셔닝

잎싹(Libsac)은 흩어진 마감 정보를 매일의 행동 가능한 피드로 정리해주는 오퍼튜니티 디스커버리 플랫폼입니다. 공모전·이벤트·공연·강연처럼 “놓치면 끝나는” 정보를 한 흐름 안에서 발견하고, D-day 기준으로 우선순위를 잡고, 관심 항목을 행동 계획으로 옮기는 데까지 이어지도록 설계했습니다.

시장과 문제 정의

기회 정보 자체는 매년 폭증하지만 채널은 더 분절됐습니다. 공모전 한 건당 정보가 흩어져 있는 채널은 평균 다섯 곳 이상이고, 공연·강연은 SNS·뉴스레터·기관 사이트·커뮤니티 게시판으로 더 흩어져 있습니다. 사용자는 동일한 탐색을 매번 처음부터 반복해야 하고, 그 비용 때문에 “알았다면 도전했을” 기회가 결국 마감 후에야 인지되는 패턴이 반복됩니다.

대형 포털·통합 검색은 정보의 양은 채워주지만 “지금 행동해야 하는가” 라는 우선순위 신호가 약합니다. 잎싹은 정보의 양보다 마감의 즉시성과 카테고리간 일관된 행동 흐름을 핵심 가치로 두고 출발했습니다.

핵심 타깃과 페르소나

기회를 자주 놓치는 학생·취업 준비생 — 공모전·세미나·체험단을 마감 기준으로 추적하고 싶음
문화 활동을 적극 탐색하는 사용자 — 공연·강연·지역 이벤트를 한 캘린더에서 한눈에 보고 싶음
커뮤니티 기여형 운영자 — 자기 소속 기관·소모임의 새 정보를 직접 등록·확산시키는 사용자

가치 제안과 차별점

카테고리 다중 · 흐름 단일 — 공연을 검색하던 사용자가 같은 인터페이스로 공모전·강연으로 자연스럽게 전환된다. 기존 채널은 카테고리마다 별도 사이트를 다시 익혀야 한다.
마감 신호의 시각화 — D-day · 마감 임박 배지 · 캘린더 뷰가 동일 데이터에서 자동 생성. 사용자는 “지금 해야 하는 것” 을 한눈에 본다.
공유 친화 SEO — 카카오·페이스북·X 같은 한국 사용자의 공유 채널에서 이벤트 포스터가 OG 이미지로 정확히 노출되도록 정적 HTML 을 매일 자동 생성한다. 단순 SPA 로는 풀 수 없는 부분을 운영 layer 로 풀었다.

핵심 사용자 흐름

진입: 카테고리 또는 마감 임박 배지에서 시작
선별: D-day · 태그 · 키워드 조합으로 “지금 봐야 할” 정보만 남김
행동: 외부 신청 페이지로 1-탭 이동, 동시에 클릭 통계가 운영 데이터에 누적
재방문: 매일 새 마감이 갱신되므로 일/주 단위 반복 사용 패턴 형성

비즈니스 모델 가설

수익화는 단계적으로 검증할 계획이며, 현재는 데이터셋 자산화 단계입니다.

타깃 광고/스폰서드 노출 — 동일 카테고리 안에서 협찬 이벤트가 우선 노출되는 sponsored tier (DB 컬럼·만료 로직 이미 구현 완료, 자동으로 만료 시 일반 노출로 강등)
이벤트 운영자 유료 등록 — 기관/소상공인이 자기 이벤트를 직접 입력·홍보하는 셀프서브 채널
타기관 라이선싱 — 큐레이션 데이터 자체를 타 서비스(대학 커뮤니티, 취업 사이트 등) 에 공급

시스템 아키텍처 (기획 결정을 시스템으로)

기획적으로 가장 무거운 결정 두 가지가 시스템 구조를 결정했습니다.

1. “마감의 즉시성은 표면 UI 만의 문제가 아니라 운영 layer 까지 깔려야 한다” → 매일 03:00 KST 외부 채널을 크롤링·AI 로 정규화하는 스케줄러, 04:00 KST 정적 HTML 을 미리 생성해 S3 에 PUT 하는 prerender 스케줄러, SPA 재배포 시 새 빌드 hash 로 전체 이벤트 HTML 을 force regenerate 하는 deploy hook 까지 3-단계 자동화로 풀었습니다. 사용자가 D-day 배지를 보는 것과 운영자가 손 안 대도 매일 새 데이터가 들어오는 것이 같은 시스템에 묶여 있습니다.

2. “여러 서비스가 동일한 운영 코어를 공유해야 한다” → 백엔드는 9개 서비스(libsac 포함) 가 단일 Hono 서버를 공유하는 host-routing 구조. api.<도메인> 헤더로 라우터를 분기하고 서비스별 DB·S3 버킷은 분리하되 인프라·로깅·배포 파이프라인은 통합했습니다. 한 서비스의 비용을 N분의 1로 떨어뜨리는 결정.

일별 데이터 입수 → 정적 HTML → CDN 노출 파이프라인

flowchart TD
    Crawl[일별 스케줄러
03:00 KST]
    Prerender[일별 스케줄러
04:00 KST]
    API[Hono API
AWS Lightsail · 9 services 공용]
    DB[(MySQL
events · sponsored_tier
click·view counters)]
    S3[(S3 libsac.com
web/e/<short>
web/events/<slug>-<short>)]
    CDN[CloudFront]
    User[사용자
SPA hydration on prerender]
    Crawler[SNS 크롤러
정적 HTML + OG 이미지]

    Crawl -->|외부 채널 fetch
AI enrichment| API
    API --> DB
    Prerender -->|활성 이벤트 HTML 생성| API
    DB --> API
    API -->|PUT static HTML| S3
    S3 --> CDN
    CDN -->|Cache-Control max-age=300| User
    CDN --> Crawler

크롤·정규화·prerender·캐싱이 한 운영 layer 에 묶여 있어 1인 운영이 가능한 구조.

기술 결정과 트레이드오프

Frontend: Vite + React 19 + SPA + S3 + CloudFront (기존 Next.js + Vercel 에서 마이그레이션). SSR 이 실제로 필요한 페이지가 share URL 의 OG 메타뿐이고, 그건 매일 prerender cron 으로 정적 HTML 을 만들어 해결 가능. SSR 호스팅 비용·콜드 스타트·플랫폼 lock-in 을 모두 제거하고 정적 사이트 호스팅 비용 수준으로 떨어뜨림.
Backend: Hono on Node + PM2 on AWS Lightsail (서버리스 대신). 9개 서비스가 동일 core 를 공유하므로 콜드 스타트 없이 항상 warm 한 단일 프로세스가 비용·복잡도 모두 우위. 서버리스로 쪼갰다면 9 × N 의 deploy/log/observability 비용이 따라옴.
DB: MySQL 8.0 (Postgres 대신). 기존 운영 친숙도. JSON 컬럼·고급 기능은 사용 안 하고 컴포지트 인덱스 + DATETIME 비교 위주라 엔진 차이가 의사결정에 영향 없음.
AI: OpenRouter / GPT-mini 계열로 enrichment (자체 호스팅 모델 대신). enrichment 가 batch 작업이고 latency 비민감, 정확도/단가 비율이 미니 모델로 충분.
포기한 것: 실시간 동기화, 사용자 계정·로그인. 큐레이션 가설 검증 단계에선 운영 부담만 키웠을 결정.

운영 자동화

1인 운영을 가능하게 만드는 핵심 layer 는 다음과 같습니다.

크롤링 + AI 정규화 — 토큰 인증된 스케줄러가 외부 채널을 매일 동시 크롤링하고 AI 로 카테고리·태그·요약·이미지 메타를 정규화. 사람 손 없이 일 단위 데이터 입수.
포스터 미러링 — 외부 사이트의 포스터 이미지를 S3 의 시간 기반 prefix(files/public/posters/<yyyy>/<mm>/) 로 미러링. 외부 링크 깨짐·rate limit 위험을 자체 CDN 으로 차단.
SEO 자동화 — 매일 04:00 prerender cron 이 활성 이벤트마다 정적 HTML 을 S3 에 PUT. 이벤트 포스터를 OG 이미지로 박아 카카오·페이스북·X 공유에서 그대로 노출되게 만들었다. SPA 재배포 시 새 빌드 hash 로 전체 force regenerate 하는 hook 까지 한 묶음.
만료 cleanup — 90일 지난 이벤트는 정적 HTML 자동 삭제 + sponsor tier 자동 만료. 운영자가 이벤트 라이프사이클을 손으로 추적할 필요 없음.

현재 상태와 운영 신호

상태: 운영 중 (지속 자동 입수)
시작: 2025-10 (Next.js 기반 첫 출시), 2026-04 Vite + S3 아키텍처로 재구축
인프라: AWS Lightsail 단일 인스턴스 + 서비스별 S3 버킷 + CloudFront, 9개 서비스 공용
자동화: 일별 스케줄러 3종(crawl / prerender / mobile build) + AI enrichment, 사람 손 없이 일 단위 콘텐츠 갱신
검증 완료 신호: 30+ 활성 이벤트 상시 노출, prerender cron 실패율 0%, 카카오·페이스북·X 공유 시 이벤트 포스터 OG 정상 표시

회고와 다음 가설

잘 작동한 것: “마감의 즉시성 = 시스템의 즉시성” 이라는 도식. 기획 가치를 cron · 정적 HTML · CDN 캐시까지 일관되게 깔았더니 1인 운영이 가능한 구조로 정착.
다시 한다면: 초기 Next.js + Vercel 선택은 SEO 를 빠르게 풀어주는 듯했지만 운영 단계에서 호스팅 비용·콜드 스타트·플랫폼 lock-in 이 부담이었다. 처음부터 SPA + prerender cron 조합으로 갔으면 마이그레이션 비용을 절감했을 것.
다음 가설: (1) 사용자 계정·관심 키워드 알림으로 retention 가설 검증, (2) 이벤트 운영자 셀프서브 등록으로 큐레이션 비용 절감, (3) 큐레이션 데이터셋 자체의 라이선싱 가능성 탐색.

비슷한 결의 작업 의뢰

잎싹을 단독으로 기획·구현·운영하면서 만들어낸 핵심 역량은 다른 도메인에도 그대로 적용 가능합니다.

마감·즉시성 기반 디스커버리 서비스 — 채용 공고, 부동산 매물, 한정 판매, 공모전 등 “놓치면 끝나는” 정보를 다루는 모든 영역
외부 다채널 크롤링 + AI 정규화 파이프라인 — 흩어진 데이터를 일관된 스키마로 정리해 자동 입수 채널을 만드는 작업
SEO / 정적 prerender 자동화 — SPA 환경에서 OG 이미지 깨짐, 검색 인덱싱 누락, 카카오 공유 미리보기 문제를 정적 HTML 자동 생성으로 해결
멀티서비스 백엔드 아키텍처 — 여러 서비스가 운영 코어·인프라·CI/CD 파이프라인을 공유하는 구조 설계와 구현

기획부터 시스템 구축, 운영 자동화까지 한 사람이 끝까지 들고 가는 형태의 작업을 선호합니다. 의뢰는 /work-with-me 또는 /contact 로 연락주세요.