조코딩 해커톤 참가 기록 — 3일간 GEO SaaS 만들기

조코딩 해커톤에서 3일 만에 WICHI MVP를 구축한 과정과 기술 스택(FastAPI, React, Supabase) 선택 이유, 그리고 제한된 시간 내 '작동하는 제품'을 만드는 우선순위 기록

배경

GEO라는 분야

GEO(Generative Engine Optimization)는 AI 검색 엔진에서 브랜드가 얼마나 잘 노출되는지를 측정하고 최적화하는 분야입니다. ChatGPT, Gemini, Perplexity 같은 AI 검색이 기존 검색을 대체하기 시작하면서, SEO와는 다른 새로운 가시성 지표가 필요해졌습니다.

기존 SEO는 검색 결과 페이지(SERP)에서 링크의 순위를 다룹니다. 사용자가 링크를 클릭해야 트래픽이 발생합니다. AI 검색은 구조가 다릅니다. 사용자가 질문하면 AI가 응답을 생성하고, 그 응답 안에 브랜드나 제품이 언급되거나 언급되지 않습니다. 클릭이 아니라 언급 자체가 가시성입니다. 이 차이가 GEO를 별도 분야로 성립시키는 근거입니다.

2025년 하반기부터 마케팅 업계에서 “AI 검색 최적화”라는 키워드가 빈번하게 등장하기 시작했고, 2026년 초 시점에는 이미 여러 에이전시가 GEO 컨설팅을 서비스 라인업에 추가한 상태였습니다. 하지만 대부분 수작업 기반이었습니다. AI 엔진에 직접 쿼리를 넣고 응답을 눈으로 확인하는 수준이었고, 이를 자동화하는 SaaS는 아직 소수였습니다.

왜 해커톤이었나

WICHI는 이 GEO를 SaaS로 만드는 프로젝트입니다. 여러 AI 엔진에 쿼리를 보내고, 응답에서 특정 브랜드가 언급되는 빈도와 맥락을 분석해 GEO Score를 산출합니다. 프로젝트 자체는 해커톤 전부터 진행 중이었습니다.

문제는 속도였습니다. “좀 더 다듬고 나서”, “이 기능도 넣고 나서”라는 사고가 반복되면서 실제 사용 가능한 형태로 수렴하지 못하고 있었습니다. 기능 설계를 계속 확장하기만 하고, 완결된 플로우를 만들지 못하는 전형적인 사이드 프로젝트 함정이었습니다.

해커톤은 마감 장치였습니다. 제출 기한이 있으면 “이것도 넣을까”라는 고민이 “3일 안에 될까”로 바뀝니다.

조코딩 해커톤은 이 프로젝트에 인위적 마감을 걸 수 있는 기회였습니다. 상금이나 수상 자체보다는, 3일이라는 기한 안에 동작하는 MVP를 만들어내는 것이 목적이었습니다. 해커톤이 끝나면 작동하는 제품이 남고, 그 제품을 기반으로 상용화를 진행할 수 있습니다. 결과와 무관하게 손해 볼 것이 없는 구조였습니다.

시작 전 상태

해커톤 시작 시점에 이미 있던 것과 없던 것을 정리하면 다음과 같습니다.

항목	상태	비고
GEO 개념 정의	완료	브랜드 가시성 측정 프레임워크 설계 상태
쿼리 생성 로직	초안	아이디어 수준, 코드화 안 됨
AI 엔진 연동	미착수	API 문서만 확인한 상태
점수 산출 로직	미착수	지표 정의만 존재
프론트엔드	미착수	디자인 시안 없음
인증/결제	미착수	플랫폼 후보만 조사
배포 환경	미착수	로컬 개발만

핵심 아이디어와 시장 리서치는 있었지만, 코드는 거의 없는 상태에서 시작했습니다.

3일 타임라인

gantt
    title WICHI MVP — 3일 해커톤 타임라인
    dateFormat  YYYY-MM-DD
    axisFormat  %m/%d

    section Day 1 — 파이프라인
    쿼리 생성 모듈            :d1a, 2026-02-27, 1d
    멀티엔진 응답 수집         :d1b, 2026-02-27, 1d
    브랜드 언급 분석 로직       :d1c, 2026-02-27, 1d
    FastAPI 서버 + Supabase DB :d1d, 2026-02-27, 1d

    section Day 2 — 프론트엔드
    React + Vite 세팅         :d2a, 2026-02-28, 1d
    리포트 시각화 뷰           :d2b, 2026-02-28, 1d
    Supabase Auth 연동        :d2c, 2026-02-28, 1d
    대시보드 UI               :d2d, 2026-02-28, 1d

    section Day 3 — 결제/제출
    Lemon Squeezy 연동        :d3a, 2026-03-01, 1d
    샘플 데이터 구성           :d3b, 2026-03-01, 1d
    전체 플로우 QA            :d3c, 2026-03-01, 1d
    제출 준비 및 제출          :d3d, 2026-03-01, 1d

Day 1 — 핵심 파이프라인

첫날은 백엔드 파이프라인에 올인했습니다. 프론트엔드 없이 터미널에서 결과를 확인하는 방식으로 진행했습니다. 사용자에게 보여줄 수 없어도 핵심 로직이 돌아야 나머지가 의미 있기 때문입니다.

쿼리 생성 모듈 구축

GEO 분석의 시작점은 쿼리입니다. 사용자가 브랜드명과 산업군을 입력하면, 해당 산업에서 소비자가 실제로 AI 검색 엔진에 물어볼 법한 질문들을 자동으로 생성합니다. “최고의 ~~는?” ”~~ 추천해줘” 같은 패턴을 산업별로 변형하는 방식입니다.

이 모듈의 품질이 전체 분석의 품질을 결정합니다. 쿼리가 현실적이지 않으면 응답도 의미 없고, 점수도 신뢰할 수 없습니다. 첫날 작업 시간의 상당 부분을 여기에 투입했습니다.

멀티 엔진 응답 수집

생성된 쿼리를 복수의 AI 검색 엔진에 전송하고 응답을 수집하는 모듈을 개발했습니다. 각 엔진마다 API 형태와 응답 구조가 다르기 때문에, 엔진별 어댑터를 만들어 통일된 형식으로 응답을 정규화하는 작업이 필요했습니다.

브랜드 언급 분석

수집된 응답 텍스트에서 대상 브랜드가 언급되는 빈도, 문맥, 위치를 분석하는 로직을 작성했습니다. 단순히 브랜드명이 몇 번 나왔는지만 세는 것이 아니라, 어떤 맥락에서 언급되는지(추천, 비교, 부정적 언급 등)를 구분하는 것이 핵심이었습니다.

API 서버와 DB

FastAPI로 API 서버를 구성하고, Supabase PostgreSQL에 분석 결과를 저장하는 구조를 잡았습니다. 테이블 설계는 최소한으로 했습니다. 사용자, 분석 요청, 분석 결과 세 개 테이블로 시작했습니다.

Day 1 종료 시점: 터미널에서 브랜드명을 입력하면 쿼리 생성 → 멀티엔진 수집 → 언급 분석 → DB 저장까지 자동으로 돌아가는 상태. 사용자용 인터페이스는 0%.

Day 2 — 프론트엔드와 인증

둘째 날의 목표는 “사람이 쓸 수 있는 형태로 만드는 것”이었습니다.

프론트엔드 세팅

React + Vite로 프론트엔드를 세팅했습니다. CRA(Create React App)가 아닌 Vite를 선택한 이유는 빌드 속도입니다. 해커톤에서 HMR(Hot Module Replacement)이 느리면 그만큼 반복 속도가 떨어집니다. Vite의 빠른 시작과 갱신 속도가 3일 스프린트에 적합했습니다.

UI 프레임워크나 컴포넌트 라이브러리는 별도로 도입하지 않았습니다. Tailwind CSS만으로 최소한의 레이아웃을 잡았습니다. “보기 좋은 것”이 아니라 “작동하는 것”이 목표였기 때문입니다.

리포트 시각화

분석 결과를 사용자에게 전달하는 리포트 뷰를 구현했습니다. 이 화면이 WICHI의 핵심 가치 전달 지점이기 때문에, Day 2의 가장 많은 시간을 여기에 썼습니다.

리포트에 포함된 요소는 다음과 같습니다.

GEO Score: 종합 점수 (0–100)
엔진별 비교 차트: 각 AI 엔진에서의 브랜드 가시성 비교
쿼리별 상세: 개별 쿼리에 대한 각 엔진의 응답과 브랜드 언급 상태
경쟁사 대비 포지션 (입력한 경쟁사가 있을 경우)

인증 연동

Supabase Auth로 회원가입/로그인을 연동했습니다. 이메일 + 비밀번호 기반 인증을 기본으로 하고, OAuth(Google)는 시간 관계상 뒤로 미뤘습니다. Row Level Security(RLS)를 설정해서 각 사용자가 자신의 분석 결과만 볼 수 있도록 했습니다.

대시보드 기본 UI

분석 이력을 조회하고 새 분석을 시작할 수 있는 대시보드를 만들었습니다. 리스트 형태로 이전 분석 결과를 나열하고, 각 항목을 클릭하면 리포트 뷰로 이동하는 단순한 구조입니다.

Day 2 종료 시점: 가입 → 로그인 → 분석 요청 → 리포트 확인까지의 플로우가 동작. 결제와 샘플 데이터는 미구현.

Day 3 — 결제, 데모 데이터, 제출

마지막 날에 해야 할 일이 가장 많았습니다. 결제 연동, 데모 데이터 구성, 전체 플로우 QA, 제출 자료 준비까지.

결제 연동

Lemon Squeezy를 결제 플랫폼으로 연동했습니다. 상품 생성, checkout 페이지 연결, webhook 수신까지를 하루 안에 완료해야 했습니다. Lemon Squeezy의 선택 이유는 별도 섹션에서 다루겠지만, 핵심은 한국 사업자가 해외 판매할 때 MoR(Merchant of Record) 처리를 대행해준다는 점이었습니다.

Day 3 시점의 결제 연동은 최소한이었습니다. 결제 완료 후 크레딧이 수동으로 부여되는 수준이었고, webhook 자동화는 해커톤 이후에 보완했습니다. “결제가 되긴 한다”가 기준이었습니다.

샘플 데이터 구성

가입 직후 분석 크레딧 없이도 서비스가 뭘 하는지 보여줄 수 있어야 했습니다. 미리 실행해둔 분석 결과를 샘플 리포트로 제공하는 방식을 선택했습니다. 실제 브랜드를 대상으로 분석을 돌려놓고, 그 결과를 샘플로 노출했습니다.

전체 플로우 QA

가입 → 로그인 → 샘플 확인 → 결제 → 크레딧 충전 → 분석 요청 → 리포트 확인. 이 전체 과정을 처음부터 끝까지 반복해서 돌려봤습니다. 깨지는 부분을 고치고, 다시 처음부터 돌리고. Day 3 오후의 대부분을 이 작업에 썼습니다.

제출

제출 자료에는 서비스 URL, 간략한 설명, 데모 영상이 포함됐습니다. 별도의 프레젠테이션 자료는 만들지 않았습니다. 작동하는 서비스 자체가 가장 좋은 데모라고 판단했습니다.

일자별 진행 요약

일자	주요 작업	완료 기준	상태
Day 1	쿼리 생성, 멀티엔진 수집, 언급 분석, API + DB	터미널에서 전체 파이프라인 동작	달성
Day 2	React 세팅, 리포트 뷰, 인증, 대시보드	브라우저에서 가입–리포트 확인 가능	달성
Day 3	결제, 샘플 데이터, QA, 제출	전체 유료 플로우 동작 + 제출 완료	달성

기술 스택 선택 근거

3일 해커톤에서 기술 선택의 기준은 단 하나였습니다. 이미 써본 것. 새로운 기술을 실험할 시간이 없었습니다. 러닝 커브가 0에 가까운 도구만 선택했습니다.

graph TD
    subgraph Frontend
        A[React + Vite] --> B[Tailwind CSS]
        A --> C[Supabase Auth SDK]
    end

    subgraph Backend
        D[FastAPI] --> E[AI Engine Adapters]
        D --> F[Query Generator]
        D --> G[Brand Analysis]
    end

    subgraph Infrastructure
        H[Supabase PostgreSQL]
        I[Supabase Auth + RLS]
        J[Railway - BE Hosting]
        K[Vercel - FE Hosting]
    end

    subgraph Payment
        L[Lemon Squeezy]
    end

    A -->|API calls| D
    D -->|Read/Write| H
    A -->|Auth| I
    L -->|Webhook| D

선택 상세

영역	선택	대안 후보	선택 이유	해커톤 이후 유지 여부
Backend	FastAPI	Django, Express	Python 기반이라 AI 파이프라인과 언어 통일. async 네이티브 지원. 라우트 정의가 간결해서 빠르게 API를 뽑을 수 있음	유지
Frontend	React + Vite	Next.js, Svelte	Vite의 빠른 HMR이 해커톤 속도에 적합. React는 가장 익숙한 프레임워크	유지 (이후 구조 변경)
DB	Supabase PostgreSQL	PlanetScale, Neon	인증, DB, RLS를 하나의 플랫폼에서 처리. 별도 ORM 없이 클라이언트 라이브러리로 바로 쿼리 가능	유지
Auth	Supabase Auth	Auth0, Clerk	DB와 같은 플랫폼이라 연동 코스트 0. RLS와 자연스럽게 통합	유지
BE Hosting	Railway	Fly.io, Render	이전 프로젝트에서 사용 경험 있음. Git push로 배포. 무료 티어로 시작 가능	유지
FE Hosting	Vercel	Netlify, Cloudflare Pages	React 프로젝트 배포의 사실상 표준. 빌드 설정 거의 불필요	유지 (이후 호스팅 전환 시 재활용)
Payment	Lemon Squeezy	Stripe, Paddle	한국 사업자 기준 글로벌 판매 시 MoR 처리 대행. 세금 계산, 인보이스, 환불 처리를 플랫폼이 담당	유지

왜 FastAPI + Python이었나

GEO SaaS의 핵심은 AI 엔진 API 호출과 텍스트 분석입니다. 이 두 가지 모두 Python 생태계가 압도적으로 강합니다. LLM API 클라이언트, 텍스트 처리 라이브러리, 데이터 분석 도구가 전부 Python 우선입니다. 백엔드까지 Python으로 통일하면 AI 파이프라인 코드를 별도 서비스로 분리하지 않고 같은 프로세스 안에서 실행할 수 있습니다.

FastAPI의 async 지원도 중요했습니다. 멀티 엔진에 동시에 쿼리를 보내고 응답을 기다리는 작업은 I/O 바운드이기 때문에, async/await로 병렬 처리하면 분석 시간이 크게 줄어듭니다.

왜 Supabase 올인이었나

3일 안에 인증, 데이터베이스, 보안 정책을 각각 다른 서비스로 구성할 시간이 없었습니다. Supabase는 PostgreSQL + Auth + Row Level Security를 하나의 프로젝트에서 제공합니다. Auth에서 발급한 JWT가 DB의 RLS 정책과 자동으로 연결되기 때문에, “로그인한 사용자가 자기 데이터만 볼 수 있게” 하는 것을 추가 코드 없이 SQL 정책만으로 구현할 수 있었습니다.

왜 Lemon Squeezy였나

한국 사업자가 글로벌 SaaS를 판매할 때 가장 큰 허들은 세금과 규정입니다. 각 국가의 VAT(부가가치세) 계산, 인보이스 발행, 환불 처리를 직접 하려면 그것만으로 프로젝트가 됩니다. Lemon Squeezy는 MoR(Merchant of Record)로서 이 모든 것을 대행합니다. 판매자는 상품 가격만 설정하면 되고, 세금과 규정은 플랫폼이 처리합니다. 수수료가 Stripe보다 높지만, 3일 해커톤에서 세금 처리 코드를 짤 여유는 없었습니다.

MVP 기능 범위

graph LR
    subgraph 해커톤 MVP에 포함
        A[쿼리 자동 생성]
        B[멀티엔진 응답 수집]
        C[브랜드 언급 분석]
        D[GEO Score 산출]
        E[리포트 뷰]
        F[이메일 인증]
        G[기본 결제]
        H[샘플 리포트]
    end

    subgraph 해커톤에서 제외
        I[OAuth 소셜 로그인]
        J[i18n 다국어]
        K[SEO 최적화]
        L[GA4 모니터링]
        M[크레딧 자동화]
        N[보안 강화]
        O[블로그/콘텐츠]
        P[경쟁사 비교 심화]
    end

넣은 것

MVP에 반드시 포함해야 했던 기능의 판단 기준은 하나였습니다. “이것 없으면 서비스가 성립하지 않는가?”

기능	포함 이유
쿼리 자동 생성	사용자가 직접 쿼리를 입력하게 하면 진입 장벽이 너무 높음
멀티엔진 응답 수집	단일 엔진만 지원하면 GEO의 “멀티엔진 비교” 가치가 사라짐
브랜드 언급 분석	핵심 기능. 이것이 없으면 서비스가 아님
GEO Score	분석 결과를 하나의 숫자로 요약해야 직관적으로 전달 가능
리포트 뷰	결과물을 사용자가 볼 수 있어야 함
이메일 인증	사용자별 데이터 분리 필수
결제	유료 SaaS이므로 결제 플로우 존재 증명 필요
샘플 리포트	결제 전에 서비스가 뭘 하는지 보여줘야 전환 가능

뺀 것

3일 안에 할 수 있었지만 의도적으로 빼거나, 시간이 모자라서 포기한 것들입니다.

기능	제외 이유	우선순위
OAuth (Google 로그인)	이메일 인증만으로 최소 기능 충족. OAuth 설정에 시간 소요	해커톤 직후
i18n (다국어)	영문 단일로 시작해도 MVP 검증에 지장 없음	상용화 시
SEO (sitemap, meta)	해커톤 평가는 심사위원이 직접 접속하므로 검색 노출 불필요	상용화 시
GA4 모니터링	해커톤 기간에는 트래픽 분석이 의미 없음	상용화 시
webhook 자동화	수동 크레딧 부여로 대체 가능한 수준의 거래량	상용화 시
3중 입력 검증	악의적 사용자가 들어올 확률이 거의 0인 해커톤 환경	상용화 시
블로그/콘텐츠 마케팅	해커톤 심사에 불필요	상용화 시
경쟁사 비교 심화	기본 비교는 가능하나 상세 분석은 시간 부족	상용화 이후

뺀 것들의 대부분은 “MVP 검증에 불필요”하거나 “해커톤 심사 맥락에서 의미 없음”에 해당합니다. 상용화 전환 시 이 목록이 곧 로드맵이 됐습니다.

제출과 데모

제출물 구성

작동하는 MVP를 제출했습니다. 데모가 아닌 실제 서비스로, 다음 전체 플로우가 동작하는 상태였습니다.

회원가입 (이메일 인증)
로그인
샘플 리포트 확인
결제 (Lemon Squeezy checkout)
분석 요청 (브랜드명 + 산업군 입력)
분석 실행 (멀티엔진 쿼리 전송 + 응답 수집 + 분석)
GEO Score 리포트 확인

flowchart LR
    A[회원가입] --> B[로그인]
    B --> C[샘플 리포트 확인]
    C --> D[결제]
    D --> E[분석 요청]
    E --> F[멀티엔진 수집]
    F --> G[브랜드 분석]
    G --> H[GEO Score 리포트]

심사위원이 직접 가입해서 서비스를 사용해볼 수 있는 상태를 만드는 것이 목표였습니다. 슬라이드 위에서만 존재하는 서비스가 아니라, 지금 당장 쓸 수 있는 서비스를 제출한 것입니다.

데모 영상

전체 플로우를 녹화한 짧은 영상을 함께 제출했습니다. 영상은 가입부터 리포트 확인까지를 실제 화면으로 보여주는 것으로, 별도의 내레이션이나 슬라이드 없이 화면 녹화만으로 구성했습니다.

AI 코딩 도구의 역할

3일 만에 이 수준의 MVP를 만들 수 있었던 데에는 AI 코딩 도구의 기여가 컸습니다. 혼자서 백엔드, 프론트엔드, 결제, 인증, 배포를 3일 안에 처리하는 것은 AI 도구 없이는 비현실적이었을 것입니다.

프론트엔드: Lovable

프론트엔드 초기 구조는 Lovable을 활용해 빠르게 세팅했습니다. Lovable은 프롬프트 기반으로 React 컴포넌트를 생성하는 노코드/로우코드 도구입니다. 디자인 감각이 없는 상태에서 “그럴듯한 UI”를 빠르게 만드는 데 유용했습니다.

다만 한계도 명확했습니다. 생성된 코드의 구조가 재사용하기 어렵고, 커스터마이징하려면 결국 직접 수정해야 합니다. 해커톤에서는 “일단 돌아가면 OK”였지만, 상용화 시에는 Lovable에서 벗어나 코드 기반으로 완전히 이전했습니다.

백엔드 및 전반: Claude

백엔드 코드, API 설계, DB 스키마, 디버깅에는 Claude를 주로 사용했습니다. 특히 유용했던 작업들은 다음과 같습니다.

FastAPI 라우트 보일러플레이트 생성
Supabase RLS 정책 SQL 작성
AI 엔진별 응답 파싱 로직
에러 핸들링 패턴
Lemon Squeezy webhook 연동 코드

AI 코딩 도구는 “코드를 대신 짜주는 것”이 아니라 “반복적인 구현을 가속하는 것”이었습니다. 아키텍처 결정, 기능 범위 판단, 우선순위 선정은 사람이 해야 하고, 결정된 사항의 코드화를 빠르게 하는 것이 도구의 역할이었습니다.

도구별 기여 영역

영역	사람의 역할	AI 도구의 역할
아키텍처 설계	전체 구조, 모듈 분리 결정	설계에 대한 피드백, 대안 제시
API 설계	엔드포인트 정의, 인터페이스 설계	보일러플레이트 코드 생성
분석 로직	지표 정의, 분석 프레임워크 설계	파싱/처리 코드 구현
프론트엔드	화면 구성, 사용자 흐름 결정	컴포넌트 생성, 스타일링
결제 연동	플랫폼 선택, 상품 구조 결정	webhook 핸들러 코드
디버깅	문제 정의, 재현 조건 파악	원인 분석, 수정안 제시

회고

시간 제약이 강제하는 것들

3일이라는 시간은 모든 의사결정을 이분법으로 만듭니다. “이게 더 좋을까 저게 더 좋을까”가 아니라 “3일 안에 되나 안 되나”. 이 프레임 전환이 생산성에 미치는 영향은 컸습니다.

평소라면 기술 선택에 며칠을 고민했을 것입니다. “Next.js가 나을까 Vite가 나을까”, “Supabase가 나을까 PlanetScale이 나을까”. 해커톤에서는 이런 고민이 사라집니다. “써본 거 중에 가장 빨리 되는 거”가 답입니다.

해커톤의 가치는 수상이 아니라, 완성된 작동 제품을 손에 쥐게 해주는 마감 압박에 있습니다.

불완전한 완성의 가치

Day 3 제출 시점의 WICHI는 불완전했습니다. 보안은 최소한이었고, 다국어 지원은 없었고, 결제 자동화는 미흡했습니다. 하지만 “동작하는 불완전한 제품”은 “완벽한 미완성 설계”보다 압도적으로 유용합니다.

동작하는 제품이 있으면 다음에 할 일이 명확합니다. “지금 가장 안 되는 부분”을 고치면 됩니다. 설계만 있으면 다음에 할 일이 모호합니다. “이것도 해야 하고 저것도 해야 하고”가 무한히 늘어납니다.

해커톤에서 배우지 못하는 것

해커톤이 알려주지 않는 것도 있습니다.

운영: 서비스를 3일 만드는 것과 3개월 운영하는 것은 완전히 다른 일입니다
반복 사용자: 해커톤 심사위원은 1회 사용자입니다. 같은 사용자가 매주 돌아오게 만드는 것은 해커톤에서 검증할 수 없습니다
규모 문제: 사용자 5명일 때 돌아가는 코드가 500명일 때도 돌아가는지는 별개입니다
수익 구조: 결제 플로우가 있다는 것과 실제로 돈을 버는 것은 다릅니다

이 목록이 해커톤 이후 상용화 과정에서 풀어야 할 과제들이 됐습니다.

다시 한다면 바꿀 것

항목	해커톤에서 한 것	다시 한다면
프론트엔드 도구	Lovable (노코드)	처음부터 코드 기반. 상용화 시 전면 재작성 비용 발생
결제 연동 시점	Day 3 (마지막 날)	Day 2 저녁. 결제는 예상보다 시간이 걸림
테스트 데이터	제출 직전 급하게 구성	Day 1부터 실제 분석 결과를 축적. 리얼 데이터가 데모 설득력을 높임
제출 자료	화면 녹화만	30초 정도의 구조화된 설명 추가. 심사위원이 맥락을 바로 파악할 수 있도록

이후 경과

해커톤 제출 후 WICHI는 예선에서 탈락했습니다. 하지만 해커톤은 마감 장치로서 역할을 다했습니다. 3일 동안 만든 MVP를 기반으로 독립 상용화 트랙으로 전환했고, 해커톤 때문에 걸어뒀던 제약(브랜치 동결, 기능 범위 제한 등)을 해제하면서 오히려 개발 속도가 올라갔습니다.

해커톤 MVP에서 상용 서비스로 전환하면서 변경된 항목들(보안, i18n, 결제 자동화, 모니터링 등)은 별도 포스트에서 다룹니다.