혼자 다 하게 된 경위
초기 스타트업에서 개발자가 저 한 명이었습니다. Flutter 앱, Next.js 어드민, NestJS API, Python 자동화 스크립트. 선택의 여지가 없었습니다.
처음엔 불가능하다고 생각했지만, 기술 선택을 잘 하면 한 사람이 커버할 수 있는 범위가 넓어집니다.
처음엔 불가능하다고 생각했지만, 기술 선택을 잘 하면 한 사람이 커버할 수 있는 범위가 넓어집니다.
기술 선택 기준: 빨리 만들 수 있는 것
최고의 기술이 아니라 가장 빠르게 프로덕션에 올릴 수 있는 기술을 골랐습니다. Flutter는 iOS/Android 동시 배포, Next.js는 SSR + 어드민 한 방, NestJS는 TypeScript로 타입 공유.
DB는 Firestore로 시작해서 유저가 늘면 PostgreSQL로 마이그레이션하는 전략을 세웠죠. 초기에 아키텍처에 시간 쓰는 건 낭비입니다.
DB는 Firestore로 시작해서 유저가 늘면 PostgreSQL로 마이그레이션하는 전략을 세웠죠. 초기에 아키텍처에 시간 쓰는 건 낭비입니다.
운영팀 자동화: Slack API + 크론잡
운영팀에서 매일 물어보는 것들을 자동화했습니다. DAU, 매출, 에러율을 매일 아침 Slack에 보내도록 Python 크론잡을 만들었습니다.
python
# daily_report.py - 매일 09:00 Slack 리포트
import requests
from datetime import datetime, timedelta
from firebase_admin import firestore
def send_daily_report():
db = firestore.client()
yesterday = datetime.now() - timedelta(days=1)
# DAU 집계
dau = db.collection('sessions') \
.where('date', '==', yesterday.strftime('%Y-%m-%d')) \
.count().get()[0][0].value
# 매출 집계
revenue = sum(
doc.to_dict()['amount']
for doc in db.collection('payments')
.where('created_at', '>=', yesterday)
.where('status', '==', 'completed')
.stream()
)
# Slack 전송
requests.post(SLACK_WEBHOOK, json={
'text': f'일일 리포트 ({yesterday:%Y-%m-%d})\n'
f'DAU: {dau:,}명\n'
f'매출: {revenue:,.0f}원\n'
f'크래시율: {crash_rate:.2f}%'
})
# crontab: 0 9 * * * python3 /app/daily_report.pyCS 자동화로 시간 벌기
고객 문의의 70%는 패턴이 같거든요. 결제 환불, 비밀번호 초기화, 기능 문의. Slack 봇으로 키워드 기반 자동 응답을 만들었습니다.
남은 30%만 직접 대응하면 되니 하루에 CS에 쓰는 시간이 2시간에서 30분으로 줄었습니다.
남은 30%만 직접 대응하면 되니 하루에 CS에 쓰는 시간이 2시간에서 30분으로 줄었습니다.
혼자서 할 수 없는 것
디자인은 포기했습니다. Figma 커뮤니티 템플릿을 가져다 쓰고, Material Design 가이드를 최대한 따랐습니다. 이상한 커스텀 디자인보다 기본 컴포넌트가 낫습니다.
마케팅도 못 해요. 이건 공동 창업자나 외주로 해결해야 하거든요.
마케팅도 못 해요. 이건 공동 창업자나 외주로 해결해야 하거든요.
번아웃 관리
6개월쯤에 번아웃이 왔어요. 밤 11시까지 코딩하고 주말에도 버그 수정하는 패턴이 반복됐습니다.
해결법은 단순해요. 근무 시간을 정하고 지키는 것. 오후 7시 이후에는 긴급 장애가 아니면 코드를 안 보죠. 주말 중 하루는 완전 오프. 이게 지속 가능한 방법입니다.
해결법은 단순해요. 근무 시간을 정하고 지키는 것. 오후 7시 이후에는 긴급 장애가 아니면 코드를 안 보죠. 주말 중 하루는 완전 오프. 이게 지속 가능한 방법입니다.
'다 할 수 있다'와 '다 해야 한다'의 차이
기술적으로 혼자 다 할 수 있다는 건 증명했습니다. 하지만 다 해야 한다는 뜻은 아닙니다.
제품이 성장하면 병목은 개발 속도가 아니라 한 사람의 컨텍스트 스위칭 비용입니다. 매일 앱, 서버, 인프라, CS를 오가면 깊은 작업이 불가능해집니다.
제품이 성장하면 병목은 개발 속도가 아니라 한 사람의 컨텍스트 스위칭 비용입니다. 매일 앱, 서버, 인프라, CS를 오가면 깊은 작업이 불가능해집니다.
결론
스타트업 풀스택은 좋은 경험이지만 장기적으로는 팀이 필요하죠. 혼자 하면서 배운 가장 큰 교훈은 '안 만드는 기능이 가장 빠른 기능'이라는 겁니다.
프로덕트에 꼭 필요한 것만 만들고, 나머지는 서드파티를 쓰세요.
프로덕트에 꼭 필요한 것만 만들고, 나머지는 서드파티를 쓰세요.