[창업을 마치며]창업~현재 타임라인 정리, 다시 창업을 한다면.

2024.07 – 아이디어 구체화

• 수공예 작가를 위한 모루인형 커스터마이징 웹 서비스 기획
• 핵심 기능: 파츠 등록·판매, 커뮤니티 공유, 커미션 관리
• 서비스 명: DIY KITTEN

2024.08~09 – MVP 개발

• React + fabric.js로 파츠 디자인 기능 구현
• 캔버스 드래그, 회전, 앞/뒤 분리, 옵션(childData) 처리 등
• 서버는 Flask + S3 기반으로 파일 업로드 구성
• 디자인툴처럼 UX 구성 고민 → 좌표 저장, 중앙 배치 등 개발

2024.09 – 사업계획서 작성

• 시장 분석 + TAM/SAM/SOM, 경쟁사 비교
• 작가 커미션 수익 모델 제시
• 정부지원사업 신청용 자료 작성 및 제출
• 파트너 역할 설정 & MVP 로드맵 구체화

2024.10 – 사용자 반응 실험

• X(트위터) 할로윈 RT 이벤트 실시
• 플리마켓 부스 참여 + 사용자 설문지 수집
• 결과: 참여 저조, 감정적 부담 증가 → 현실적인 방향 점검
• 사람에게 도움을 청할 때 생기는 기대 불일치 경험

2024.11 – 전략 수정 & 콘텐츠 확장

• 크리스마스 카드뉴스 등 SNS 콘텐츠 시도
• Next.js 리팩토링 고민 (SSR, SEO 대응 목적)
• DIY 키트는 보류하고, 작가 중심의 서비스 체험단 운영 계획 수립

2024.12 – 서비스 체험단 & 보증금 실험

• 작가 체험단 운영: 파츠 등록 + 판매 체험 유도
• 단순 가입이 아닌, 보증금 환급 조건으로 실질 체험 유도
• 서비스 흐름에 대한 구체 피드백 확보 → 온보딩 개선

2025.01~03 – 한계 직면 & 정리 결심

• 유저 확보와 수익 검증에 어려움
• 주변 협업자의 기대와 실현 간 간극 체감 → 신뢰 흔들림
• 혼자 감당하는 운영과 기획의 무게 → 감정적 소진
• 결국, “지금은 유보하자”는 판단

2025.04 – 회고 작성 & 다음 준비

• 타임라인 및 교훈 정리
• 오픈소스 전환 여부 검토
• 구직 활동 재개 & 포트폴리오 정리 중

 

창업을 마치며 

혼자서 창업을 시작했을 땐, 처음부터 모든 걸 완벽하게 만들고 싶었다. 아키텍처를 짜고, 코드 구조를 정리하고, 파츠 데이터를 어떻게 저장할지 고민하고… 그런데 지금 돌아보면, 그 시간에 차라리 사용자를 더 만났다면 훨씬 큰 인사이트를 얻었을 것 같다.

혼자 하는 창업에서 중요한 건 완벽한 구조보다 빠른 실행이다. 유저가 원하는 게 뭔지 확인하지 않은 상태에서 만드는 건, 혼자서 끝도 없는 정글을 헤매는 것과 같다. 결국 시간도 에너지도 방향도 잃는다.

그리고 주변 사람들에게 도와달라고 요청했을 땐, 좋은 마음으로 시작했지만 결국 서로 기대하는 바가 달랐다. 나는 ‘같이 만들자’고 생각했지만, 그들은 ‘내 포트폴리오가 될 수 있을까’를 생각하고 있었던 거다. 기획이 조금만 바뀌어도, 그들의 기대는 어긋나고, 나에 대한 신뢰도 같이 떨어졌다.

이걸 겪고 나니 확실히 알겠다.
진짜 검증이 먼저다. 유저가 반응하고, 가능성이 보일 때, 비로소 좋은 동료들이 자발적으로 합류할 수 있다.

다음에 또 창업을 하게 된다면,
노코드든 뭐든 최대한 빠르게 유저 피드백을 받아보고,
‘사업이 될 수 있다’는 증거를 쌓는 게 가장 먼저다.

그 이후에 함께할 누군가를 찾는 건, 오히려 그때가 가장 자연스럽다.
그땐 나도 덜 흔들리고, 함께하는 사람도 방향을 더 명확히 볼 수 있을 테니까.

 

다음에 다시 창업한다면

이번 창업은 유보했지만, 만약 또다시 창업을 하게 된다면, 난 아마 이런 순서로 움직일 거다.

1. 기술보다 유저를 먼저 검증한다

아키텍처? 구조? 처음엔 전혀 중요하지 않다.
노코드든 뭐든, 유저가 이걸 ‘원하는지’부터 확인해야 한다.
기능은 그다음이다. 아니, 유저가 생기면 기능은 그때부터 더 빠르게 만들어진다.

2. 혼자서 검증하고, 그 후에 함께할 사람을 찾는다

사람들과 함께 시작하면 기대와 책임이 뒤엉기기 쉽다.
기획이 바뀌면 관계도 흔들린다.
그래서 처음엔 혼자서 유저 검증을 해보고,
가능성이 보이면 그때 함께할 사람을 자연스럽게 맞이하면 된다.

3. 온보딩은 ‘가입’이 아니라 ‘행동’으로 설계한다

그냥 가입시키는 건 의미 없다.
직접 등록해보고, 써보게 만들어야 한다.
보증금 환급 모델처럼 ‘가벼운 책임’을 주는 구조가 행동을 유도할 수 있다.

4. 실험에는 반드시 배움이 남아야 한다

실패했더라도, 그 실험이 나에게 어떤 통찰을 줬는지 정리해두자.
실패가 쌓이면 무기력해지지만, 배운 게 쌓이면 다음 시도는 훨씬 빠르다.

5. 버티는 건 기술이 아니라 감정이다

창업은 체력싸움이 아니라 정서적인 지속력이 중요하다.
혼자일수록 더 그렇다.
기술 말고도, 나를 지탱할 무언가를 마련해두는 게 필요하다.
사람일 수도, 일기일 수도, 루틴일 수도 있다.