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

포지셔닝

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

시장과 문제 정의

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

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

핵심 타깃과 페르소나

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

가치 제안과 차별점

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

핵심 사용자 흐름

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

비즈니스 모델 가설

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

타깃 광고/스폰서드 노출, 동일 카테고리 안에서 협찬 이벤트가 우선 노출되는 sponsored tier (Firestore sponsored_tier·sponsored_until 필드·만료 로직 이미 구현 완료, 자동으로 만료 시 일반 노출로 강등)
기획 메뉴 크래딧 언락, 공모전·이벤트 참여에 도움되는 심화·전문 자료를 기획 메뉴에 두고, 전문 열람만 공유 크래딧 1개로 차감(서비스 본문은 전부 무료). 차감 인프라는 공통 unlockContent 정책에 연결(구현 대기)
이벤트 운영자 유료 등록 · 라이선싱, 기관/소상공인이 자기 이벤트를 직접 입력·홍보하는 셀프서브 채널, 그리고 큐레이션 데이터 자체를 타 서비스(대학 커뮤니티, 취업 사이트 등) 에 공급

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

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

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

2. “별도 API 서버 없이 운영 비용을 0에 가깝게 떨어뜨린다” → 백엔드는 별도 애플리케이션 서버 없이 Firebase Firestore(명명 DB libsac) 를 단일 데이터 소스로 쓰는 서버리스 구조입니다. 프론트엔드는 Astro 정적 SSG 로 빌드해 Firebase Hosting 에 올리고, 동적 카운터·목록은 React island 가 클라이언트에서 Firestore 를 직접 읽습니다. 상시 켜 둘 서버가 없어 인프라 비용·콜드 스타트·운영 부담이 모두 사라졌습니다.

일별 데이터 입수 → 정적 빌드 → Firebase Hosting 노출 파이프라인

flowchart TD
    Crawl[크롤 스케줄러
GitHub Actions · 03:00 KST]
    Sources[외부 소스
allcon · incruit · kopis · tippingkorea]
    AI[AI 정규화
OpenAI gpt-4o-mini]
    FS[(Firestore named DB libsac
events · articles
sponsored_tier · view/click count)]
    Storage[(Firebase Storage
libsac/posters/…)]
    Deploy[배포 스케줄러
GitHub Actions · 04:00 KST]
    Astro[Astro 정적 SSG
web/dist]
    Hosting[Firebase Hosting
site: libsac]
    User[사용자
정적 HTML + React island hydration]

    Crawl --> Sources
    Sources -->|fetch| AI
    AI -->|enrich·정규화| FS
    AI -->|포스터 미러링| Storage
    Deploy --> Astro
    FS -->|빌드 타임 read| Astro
    Astro --> Hosting
    Storage -->|OG·포스터 URL| Hosting
    Hosting --> User
    FS -->|클라이언트 read
view/click 카운트| User

크롤·정규화·정적 빌드·호스팅이 모두 관리형 서비스(GitHub Actions·Firestore·Firebase Hosting) 위에서 돌아 1인 운영이 가능한 구조.

기술 결정과 트레이드오프

Frontend: Astro 정적 SSG + React island + TypeScript + Tailwind CSS (web/). 페이지 골격과 OG 메타는 빌드 타임에 정적 HTML 로 굳히고, 이벤트 목록·카운터·달력처럼 동적인 부분만 React island 로 클라이언트에서 hydrate. SSR 호스팅 비용·콜드 스타트·플랫폼 lock-in 없이도 공유 미리보기에 필요한 정적 HTML 을 확보.
Backend: 별도 API 서버 없음. Firebase Firestore(명명 DB libsac) 를 단일 데이터 소스로 쓰고, 데이터 접근은 web/src/api/*.ts(events.ts·articles.ts) 의 Firestore 쿼리 래퍼로만. 복합 인덱스 요구를 피하려고 활성 이벤트를 한 번에 읽어 JS 에서 정렬·필터한다.
AI enrichment: OpenAI gpt-4o-mini 로 크롤한 원문을 제목·설명·날짜·태그로 정규화(tools/lib/ai.ts). enrichment 가 batch 작업이고 latency 비민감, 정확도/단가 비율이 미니 모델로 충분.
포스터 저장: Firebase Storage(libsac/posters/…) 에 외부 포스터를 미러링(tools/lib/mirror.ts). 핫링크 차단·rate limit·외부 링크 깨짐을 자체 스토리지로 차단.
언어: 한국어 전용. 대상 이벤트·공모전·공연이 국내 정보라 다국어·언어 선택기를 의도적으로 두지 않음.

운영 자동화

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

크롤링 + AI 정규화, GitHub Actions 크롤 스케줄러(매일 03:00 KST) 가 allcon·incruit·kopis·tippingkorea 등 외부 채널을 돌며 정보를 수집하고, OpenAI gpt-4o-mini 로 카테고리·태그·요약·날짜를 정규화해 Firestore events 에 적재. 사람 손 없이 일 단위 데이터 입수.
포스터 미러링, 외부 사이트의 포스터 이미지를 Firebase Storage 의 프로젝트 폴더(libsac/posters/…) 로 미러링. 외부 링크 깨짐·핫링크 차단·rate limit 위험을 자체 스토리지로 차단.
SEO 자동화, 매일 04:00 KST 배포 스케줄러가 사이트를 다시 빌드·배포해 활성 이벤트가 정적 HTML 로 갱신되게 한다. Astro 가 빌드 타임에 이벤트 포스터를 OG 이미지로 박아 카카오·페이스북·X 공유에서 그대로 노출되게 만든다. SPA 와 달리 별도 prerender 단계 없이 빌드 산출물 자체가 정적 HTML.
sponsored tier 만료, 협찬 노출은 Firestore sponsored_until 기준으로 만료되면 자동으로 일반 노출로 강등. 운영자가 노출 라이프사이클을 손으로 추적할 필요 없음.

현재 상태와 운영 신호

상태: 운영 중 (지속 자동 입수)
시작: 2025-10 (Next.js 기반 첫 출시), 이후 Astro 정적 SSG + Firebase 아키텍처로 재구축
인프라: 별도 서버 없는 서버리스 구조, Firebase Firestore(명명 DB libsac) + Firebase Storage + Firebase Hosting(project mrlatte, site libsac), 배포는 GitHub Actions
자동화: 일별 스케줄러 2종(crawl 03:00 KST / rebuild·deploy 04:00 KST) + AI enrichment, 사람 손 없이 일 단위 콘텐츠 갱신
검증 완료 신호: 활성 이벤트 상시 노출, 일별 크롤·배포 파이프라인 정상 가동, 카카오·페이스북·X 공유 시 이벤트 포스터 OG 정상 표시

회고와 다음 가설

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

비슷한 결의 작업 의뢰

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

마감·즉시성 기반 디스커버리 서비스, 채용 공고, 부동산 매물, 한정 판매, 공모전 등 “놓치면 끝나는” 정보를 다루는 모든 영역
외부 다채널 크롤링 + AI 정규화 파이프라인, 흩어진 데이터를 일관된 스키마로 정리해 자동 입수 채널을 만드는 작업
SEO / 정적 사이트 자동화, 동적 데이터를 다루면서도 OG 이미지 깨짐, 검색 인덱싱 누락, 카카오 공유 미리보기 문제를 정적 SSG(Astro) + 일별 재빌드로 해결
서버리스 데이터 파이프라인, 별도 API 서버 없이 Firestore + Firebase Hosting + GitHub Actions cron 만으로 크롤·정규화·배포를 자동화하는 저비용 운영 구조 설계와 구현

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