해커톤 탈락 후 — 독립 SaaS로 전환한 과정

탈락 통보

2026년 3월 2일, 조코딩 해커톤 예선 탈락 결과를 받았습니다. 3일간 작동하는 MVP를 만들어 제출했지만 본선에 올라가지 못했습니다. 탈락 사유에 대한 별도 피드백은 없었습니다.

피드백이 없다는 것은 개선 방향을 알 수 없다는 뜻이기도 하지만, 동시에 제품 자체의 결함이 지목된 것은 아니라는 뜻이기도 합니다. 어느 쪽이든 사실관계만 남깁니다: 3일간 만든 MVP를 제출했고, 본선에 오르지 못했습니다.

탈락 원인 분석

공식 피드백이 없으므로 가능한 원인을 역추정할 수밖에 없습니다. 해커톤 심사의 일반적인 평가 기준과 제출물의 특성을 교차해서 몇 가지 가설을 세웠습니다.

가설 1: 시장 적합성 시연의 한계

GEO(Generative Engine Optimization)는 2026년 기준으로도 아직 초기 시장입니다. AI 검색 최적화라는 개념 자체가 SEO만큼 보편적이지 않습니다. 심사위원이 이 시장의 크기와 긴급성을 즉시 납득하기 어려웠을 가능성이 있습니다.

해커톤 심사는 보통 3~5분 내에 “이 문제가 왜 중요한가”를 전달해야 합니다. GEO의 중요성을 설명하려면 먼저 AI 검색이 기존 검색을 대체하고 있다는 전제를 공유해야 하고, 그 위에서 브랜드 가시성 측정이 필요하다는 논증을 쌓아야 합니다. 3분 안에 이 두 단계를 모두 설득력 있게 전달하기는 쉽지 않습니다.

가설 2: 데모 완성도

작동하는 MVP를 제출했지만, “작동한다”와 “인상적이다”는 다른 차원입니다. 해커톤에서 높은 점수를 받는 데모는 보통 시각적 임팩트가 있거나, 한 가지 핵심 기능을 극적으로 보여줍니다.

WICHI의 핵심 가치는 여러 AI 엔진의 응답을 수집하고 분석하는 파이프라인에 있습니다. 이 과정은 본질적으로 백그라운드 작업이며, 화면에서 극적으로 보여주기 어렵습니다. 리포트 화면은 데이터를 정확하게 표시하지만, 시각적으로 “와우 모먼트”를 만들어내는 종류의 데모는 아니었습니다.

가설 3: 경쟁 구도

해커톤에는 다양한 프로젝트가 참가합니다. GEO SaaS보다 직관적으로 이해하기 쉬운 프로젝트, 예를 들어 챗봇, 이미지 생성, 교육 도구 같은 주제가 더 유리했을 수 있습니다. 심사위원의 배경과 관심사에 따라 결과가 달라지는 것은 해커톤의 구조적 특성입니다.

가설 요약

가설	가능성	통제 가능 여부
시장 적합성 시연 한계	높음	부분적 (설명 방식 개선 가능, 시장 자체는 변경 불가)
데모 시각적 완성도	중간	가능 (UI/UX 투자로 개선 가능)
경쟁 구도 및 심사 기준	중간	불가 (외부 변수)
제품 자체의 결함	낮음	가능 (전체 플로우가 작동하는 상태로 제출)

통제 불가능한 변수가 2개, 부분적으로만 통제 가능한 변수가 1개입니다. 이 분석에서 중요한 결론은 하나입니다: 탈락이 제품의 가치를 부정하지 않습니다.

해커톤이 걸어둔 제약

해커톤 참가 기간 동안 WICHI에는 몇 가지 인위적인 제약이 있었습니다. 이 제약들은 해커톤 맥락에서는 합리적이었지만, 제품을 실제 사용자에게 전달하는 관점에서는 불필요하거나 심지어 해로운 것들이었습니다.

시간 제약이 만든 기술 부채

3일이라는 기한은 “지금 되는 방법”을 선택하게 만듭니다. 아키텍처를 깔끔하게 설계할 여유가 없고, “일단 작동하면 된다”는 기준으로 코드를 작성하게 됩니다. 이것은 해커톤의 의도된 특성이기도 합니다. 문제는 그 기술 부채가 해커톤이 끝난 뒤에도 코드베이스에 남는다는 점입니다.

범위 제한이 만든 불완전한 제품

해커톤 심사에 직접 기여하지 않는 기능은 의도적으로 뒤로 미뤘습니다. 다국어 지원(i18n), SEO 최적화, 블로그, 온보딩 개선 같은 항목들은 제품의 상용화에는 필수이지만 해커톤 심사 점수에는 기여하지 않습니다. 합리적인 우선순위 결정이었지만, 그 결과 제출된 제품은 “작동하지만 불완전한” 상태였습니다.

서사 제약이 만든 왜곡

해커톤 제출물에는 서사가 필요합니다. “어떤 문제를 발견했고, 이렇게 해결했다”는 구조입니다. WICHI의 경우 실제로는 해커톤 전부터 개발 중이던 프로젝트였지만, 제출 자료에서는 해커톤 기간 동안의 성과를 중심으로 이야기를 구성해야 했습니다. 이 서사 제약은 프로젝트의 실제 맥락과 깊이를 전달하기 어렵게 만들었습니다.

제약 전체 목록

제약 유형	구체적 내용	해커톤 내 합리성	상용화 관점 영향
브랜치 동결	안정 브랜치 유지, 기능 실험 불가	높음 (제출 안정성)	부정적 (개발 속도 저하)
제출 규격	심사 기준에 맞춘 데모 흐름	높음 (심사 대응)	부정적 (실제 UX와 괴리)
CTA 왜곡	심사 친화적 가입 유도 흐름	중간 (인상 관리)	부정적 (전환율 최적화 불가)
기능 범위 제한	심사 무관 기능 제거/보류	높음 (집중)	부정적 (불완전한 제품)
기술 부채 허용	속도 우선, 품질 타협	높음 (시간 내 완성)	부정적 (리팩토링 비용)
서사 구성	해커톤 기간 중심 스토리	높음 (심사 규칙)	부정적 (프로젝트 맥락 누락)

탈락 후 내린 결정

해커톤은 마감 압박을 활용하기 위한 수단이었고, 탈락했다고 제품의 가치가 바뀌는 것은 아닙니다.

결정까지 오래 걸리지 않았습니다. 해커톤용 프로덕트를 상용 SaaS로 전환하기로 했습니다. 이 결정은 감정적 반응이 아니라 조건 점검의 결과였습니다.

의사결정 프레임워크

탈락 직후 세 가지 선택지를 검토했습니다.

graph TD
    A[해커톤 탈락] --> B{선택지 검토}
    B --> C[옵션 1: 프로젝트 중단]
    B --> D[옵션 2: 다른 해커톤 대기]
    B --> E[옵션 3: 독립 SaaS 전환]

    C --> C1[매몰비용만 남음]
    C --> C2[작동하는 MVP 폐기]

    D --> D1[다음 해커톤까지 개발 정체]
    D --> D2[해커톤 제약 재적용]

    E --> E1[즉시 개발 재개]
    E --> E2[제약 전면 해제]
    E --> E3[시장 타이밍 활용]

    style E fill:#f0f0f0,stroke:#333
    style E1 fill:#f0f0f0,stroke:#333
    style E2 fill:#f0f0f0,stroke:#333
    style E3 fill:#f0f0f0,stroke:#333

옵션 1(중단)은 이미 작동하는 MVP를 폐기하는 것이므로 비합리적이었습니다. 옵션 2(대기)는 개발 모멘텀을 잃고 다시 해커톤 제약에 묶이는 것이므로 후퇴에 가까웠습니다. 옵션 3(독립 전환)만이 지금까지 투입한 자원과 이미 검증된 파이프라인을 최대한 활용하는 방향이었습니다.

전환 결정의 3가지 근거

1. 시장 타이밍

GEO 시장은 성장 초기 단계에 있습니다. AI 검색 엔진의 사용량이 늘고 있고, 브랜드의 AI 검색 가시성을 측정하려는 수요가 실재합니다. 초기 시장에서 선점 효과를 확보하려면 빠르게 움직여야 합니다. 해커톤 결과를 기다리거나 다른 외부 이벤트에 일정을 맞추는 것은 시장 진입을 지연시킬 뿐입니다.

2. 기존 코드베이스의 가치

3일간의 해커톤으로 만든 것이지만, 핵심 파이프라인은 실제로 작동합니다. 가입부터 결제, 분석 실행, 리포트 확인까지 전체 플로우가 돌아가는 상태입니다. 이 코드베이스를 버리는 것은 단순한 매몰비용 오류가 아니라 실질적인 자산 폐기입니다.

3. 해커톤 독립적 제품 가치

해커톤은 동기 부여 장치였을 뿐, 제품의 존재 이유는 해커톤과 무관합니다.

WICHI가 해결하려는 문제 — AI 검색 엔진에서 브랜드 가시성 측정 — 는 해커톤이 있든 없든 존재합니다. 해커톤은 마감 압박을 활용해 초기 MVP를 빠르게 만드는 수단이었고, 그 역할은 이미 수행되었습니다.

매몰비용 vs 기회비용 분석

“이미 투자했으니까 계속한다”는 매몰비용 오류에 빠질 위험은 의식적으로 점검했습니다. 핵심 질문은 이것이었습니다: 해커톤에 투입한 시간을 제외하고, 지금 이 제품을 처음부터 만들겠는가?

답은 “예”였습니다. GEO 시장의 성장, 기존 파이프라인의 작동 상태, 기술 스택의 확장 가능성을 고려하면 신규 프로젝트로 시작해도 같은 결정을 내렸을 것입니다. 이미 만들어진 코드베이스가 있다는 것은 출발선이 앞에 있다는 의미일 뿐, 계속해야 하는 이유가 되지는 않습니다.

이 구분을 통과한 뒤에야 전환을 확정했습니다.

해제한 제약 목록

전환을 결정한 직후, 해커톤 때문에 걸어뒀던 제약을 전면 해제했습니다.

graph LR
    subgraph "해커톤 모드"
        H1[브랜치 동결]
        H2[데모 규격 맞추기]
        H3[심사 친화 CTA]
        H4[기능 범위 제한]
        H5[기술 부채 허용]
    end

    T[탈락 / 전환 결정]

    subgraph "독립 SaaS 모드"
        S1[자유로운 브랜치 전략]
        S2[실제 사용자 흐름]
        S3[전환 최적화 CTA]
        S4[풀 로드맵 복원]
        S5[리팩토링 시작]
    end

    H1 --> T --> S1
    H2 --> T --> S2
    H3 --> T --> S3
    H4 --> T --> S4
    H5 --> T --> S5

    style T fill:#f0f0f0,stroke:#333

구체적으로 해제한 항목과 그 효과를 정리합니다.

해제한 제약	해커톤 모드 (Before)	독립 모드 (After)	실질적 효과
브랜치 동결	안정 브랜치 1개 유지	기능 브랜치 자유 생성/머지	병렬 개발 가능, 실험 비용 감소
데모 흐름	심사 기준에 맞춘 시나리오	실제 사용자 여정 기반 UX	전환율 최적화 시작 가능
CTA 구성	해커톤 평가 의식한 가입 유도	마케팅 채널별 독립 설계	A/B 테스트, 채널 최적화 가능
기능 범위	심사 기여 기능만 포함	전체 로드맵 복원	i18n, SEO, 블로그, 온보딩 착수
코드 품질	”작동하면 됨” 기준	프로덕션 품질 기준 적용	리팩토링, 테스트 추가 시작
서사	해커톤 기간 중심 스토리	제품 비전 중심 커뮤니케이션	마케팅 메시지 자유도 확보

실행 계획: 해커톤 MVP에서 프로덕션으로

독립 전환을 결정한 뒤, 해커톤 MVP와 프로덕션 타겟 사이의 간극을 구체적으로 정의했습니다.

해커톤 MVP vs 프로덕션 타겟

영역	해커톤 MVP	프로덕션 타겟	우선순위
언어	한국어 단일	한국어 + 영어 (i18n)	1순위
SEO	없음	메타태그, sitemap, Search Console	1순위
온보딩	최소한의 설명	샘플 분석 데이터 기반 체험 플로우	2순위
인증	기본 Supabase Auth	소셜 로그인 추가, 세션 관리 개선	2순위
결제	단일 플랜	플랜 체계 정비, 무료 체험 기간	2순위
블로그	없음	GEO 관련 콘텐츠 마케팅	3순위
모니터링	없음	에러 트래킹, 사용 로그	3순위
분석 엔진	초기 세트	엔진 추가 및 응답 파싱 고도화	지속

기능 해금 타임라인

전환 후 실제로 풀리는 기능들의 의존 관계를 정리했습니다.

graph TD
    T[전환 결정 3/2] --> A[i18n 브랜치 머지]
    T --> B[Search Console 등록]
    T --> C[STATUS.md 재작성]

    A --> D[영문 UI 완성]
    B --> E[sitemap 제출]
    D --> F[글로벌 마케팅 채널 구성]
    E --> F

    A --> G[블로그 i18n 기반 구축]
    G --> H[GEO 콘텐츠 발행 시작]

    C --> I[상용화 마일스톤 설정]
    I --> J[샘플 분석 시스템]
    I --> K[플랜 체계 정비]
    J --> L[온보딩 개선]
    K --> L

    style T fill:#f0f0f0,stroke:#333

이 타임라인에서 중요한 것은 i18n이 여러 후속 작업의 선행 조건이라는 점입니다. 해커톤 기간 동안 보류해뒀던 i18n 브랜치를 즉시 머지한 것은 이 의존 관계를 풀기 위해서였습니다.

전환 당일 실행 내역 (3월 2일)

결정한 날 바로 실행으로 옮겼습니다. 전환이 “의향”이 아니라 “사실”이 되려면 당일 안에 구체적인 변경이 코드베이스와 인프라에 반영되어야 한다고 판단했습니다.

1. STATUS.md 재작성

프로젝트의 상태 문서를 해커톤 트랙에서 상용화 트랙으로 전면 수정했습니다. 목표, 마일스톤, 블로커, 다음 할 일이 모두 바뀌었습니다. STATUS.md는 이 프로젝트의 진실 공급원(source of truth)이기 때문에, 이 문서를 바꾸는 것이 전환의 공식적인 선언에 해당합니다.

2. Google Search Console 등록

wichi.app 도메인 속성을 Google Search Console에 등록했습니다. 해커톤 기간에는 SEO가 우선순위 밖이었기 때문에 미뤄뒀던 작업입니다. 독립 SaaS로 전환한 이상 검색 노출은 기본 인프라입니다.

3. i18n 브랜치 머지

해커톤 기간 동안 보류했던 다국어 지원 브랜치를 메인에 합쳤습니다. 이 머지가 풀어준 것은 단순히 영문 UI가 아니라, 글로벌 사용자를 대상으로 한 모든 후속 작업의 전제 조건이었습니다.

하루 안에 “해커톤 프로젝트”에서 “독립 SaaS”로 전환을 완료했습니다. 해커톤이 걸어둔 제약을 풀자 오히려 할 수 있는 일이 명확해졌습니다.

회고: 해커톤을 어떻게 봐야 하는가

해커톤은 검증 도구지 목적지가 아닙니다

해커톤의 가치는 입상이 아니라 구조화된 압박입니다. 짧은 기한 안에 “작동하는 무언가”를 만들어야 한다는 강제가 의사결정 속도를 끌어올립니다. “더 좋은 방법이 있을 텐데”라는 고민을 “지금 되는 방법”으로 바꿔줍니다.

WICHI의 경우 해커톤이 없었다면 초기 MVP 완성이 최소 2~3주는 더 걸렸을 것입니다. 3일 마감이라는 압박이 “가입 → 결제 → 분석 → 리포트” 전체 플로우를 한 번에 관통하게 만들었습니다. 이 관통 경험은 해커톤의 결과와 무관하게 남는 자산입니다.

탈락은 정보이지 판결이 아닙니다

해커톤 탈락에서 추출할 수 있는 정보는 제한적이지만 존재합니다.

• 시장 설명의 난이도가 높다 (GEO 개념이 아직 대중적이지 않음)
• 데모의 시각적 임팩트가 부족할 수 있다
• 심사 기준과 제품 가치는 항상 일치하지 않는다

이 정보들은 다음 단계에서 개선할 수 있는 구체적인 항목입니다. 시장 설명 방법을 개선하고, UI/UX에 투자하고, 제품 가치를 직접 사용자에게 전달하는 채널을 확보하면 됩니다.

멘탈 모델: 해커톤 → 검증 → 분기

graph TD
    A[아이디어] --> B[해커톤 참가]
    B --> C[MVP 완성]
    C --> D{결과}

    D -->|입상| E[상금 + 노출 + 모멘텀]
    D -->|탈락| F[MVP + 학습 + 자유]

    E --> G[독립 SaaS 전환]
    F --> G

    G --> H[상용화 트랙]

    style G fill:#f0f0f0,stroke:#333

입상하든 탈락하든 최종 목적지는 같습니다. 입상하면 상금과 초기 노출이라는 보너스가 붙고, 탈락하면 해커톤 제약에서 즉시 자유로워진다는 다른 종류의 보너스가 있습니다. 어느 경로든 작동하는 MVP와 검증된 파이프라인은 그대로 남습니다.

차이가 있다면 속도입니다. 입상했다면 노출을 통해 얼리어답터를 확보하는 경로가 빨라졌을 것이고, 탈락했기 때문에 제품 자체의 완성도를 먼저 올리는 경로를 택하게 되었습니다. 두 경로 모두 유효합니다.

1인 개발에서의 피봇 비용

팀이 아닌 1인 프로젝트에서 피봇의 비용은 상대적으로 낮습니다. 합의해야 할 사람이 없고, STATUS.md를 수정하는 것이 곧 방향 전환의 전부입니다. 해커톤에서 상용화로의 전환은 코드 변경보다 문서 변경이 대부분이었습니다. 코드베이스는 그대로 두고, 그 위에 올라가는 우선순위와 로드맵만 바꾸면 됩니다.

이것은 1인 개발의 구조적 장점입니다. 방향 전환의 커뮤니케이션 비용이 0에 가깝기 때문에, “결정 → 실행”의 간극이 최소화됩니다. 3월 2일 탈락 통보를 받고, 같은 날 전환을 완료한 것은 이 구조 덕분입니다.

이 글에서 다루지 않는 것

이 글은 의사결정 과정을 기록합니다. 다음 항목은 별도의 글에서 다룹니다.

• 해커톤 3일간의 개발 타임라인 (별도 글 참조)
• 프론트엔드 호스팅 마이그레이션 상세 (별도 글 참조)
• 상용화 이후의 기술적 변경 사항
• 구체적인 시스템 아키텍처나 내부 구현 상세