2024년 봄에 첫 마이크로 SaaS 사이트를 띄우고, 1년 뒤에 119개가 되어 있을 거라고는 진심으로 상상하지 못했습니다. 처음에는 "한 5개쯤 만들어 그중 하나가 사람을 끌면 좋겠다" 정도의 기대였는데, 인프라가 한 번 자리잡고 나니까 도구 한 개가 평균 4~6시간 안에 라이브로 떨어졌고, 결과적으로 1년치 누적이 세 자리를 넘었습니다. 이 글은 그 119개를 운영하면서 손으로 익힌 것을 한 번 정리한 회고입니다. 비싼 실수와 가장 큰 레버리지를 같이 적어 두는 게 다음 1년에 같은 함정을 안 밟는 데에 도움이 될 것 같아서 입니다.
119개 도구 1년 운영의 핵심 숫자
- LIVE 도구 119개 (한국 사용자 향 104 + 글로벌 향 34, 일부 중복)
- 단일 운영자, 본업 별도 (AWS·백엔드 엔지니어)
- 도구당 평균 0→1 소요 시간 4~6시간 (인프라 표준화 이후)
- AWS 인프라 비용 월 3~5만 원 (S3 + CloudFront + ACM + Route 53)
- 트래픽 분포: 상위 5개 사이트가 전체 GA4 트래픽의 약 70%
- AdSense 첫 USD 100 지급까지 6개월 소요
- 2025-05-27 첫 아이 출생 — 후반부 운영 패턴이 크게 바뀐 기준점
숫자만 보면 거창해 보이지만, 그 안쪽은 깔끔한 그림이 아니라 평일 출근 전 1시간 + 퇴근 후 1~2시간 + 주말 오전 2~3시간을 1년 누적한 결과입니다. 1주에 합쳐서 10시간 안팎. 많지 않습니다. 그래서 더더욱 인프라 표준화와 "안 만드는 결정"이 결정적이었습니다.
가장 비싼 실수 5가지
1. 사이트마다 CloudFront OAC·Function 신규 생성
초기에 사이트를 띄울 때마다 CloudFront Origin Access Control 과 CloudFront Function 을 신규로 만들었습니다. 도메인이 같고 origin 패턴이 같은데도 자원만 늘어났습니다. 6개월쯤 지나 청구서를 다시 보니 비용이 6배 가까이 증가해 있었습니다. 그때부터 공유 bal-pe-kr-rewrite-2 Function 과 static-shorts-oac 하나로 모든 신규 사이트가 통과하도록 표준을 박았습니다. 이 패턴이 내 운영 메모리에 영구로 박힐 만큼 중요한 표준이 됐습니다. v1 함수는 한도를 도달해 이제 신규 사이트는 무조건 v2 함수를 씁니다.
교훈: 같은 도메인은 OAC + Function 을 공유한다. 인프라 자원의 90% 는 사이트별로 다를 이유가 없습니다.
2. GitHub Actions 무료 한도 초과
사이트가 늘어나고 하루에 4~5번씩 배포가 돌아가던 시기에 GitHub Actions 의 무료 한도를 우습게 넘기고 추가 청구가 나왔습니다. 한 달 사이에 정리한 결론은 단순합니다. 정적 사이트 배포는 어차피 S3 sync 와 CloudFront invalidation 두 단계만 필요합니다. 그걸 microsaas-infra/scripts/local-deploy.sh 라는 로컬 스크립트로 옮기고 운영자 노트북에서 직접 실행하는 구조로 영구 전환했습니다. 비용 절감만큼이나 큰 부수 효과는, 배포가 깨졌을 때 GHA 로그를 들여다보는 것보다 내 터미널에서 곧장 다시 돌리는 게 심리적으로 훨씬 빠르다는 점이었습니다.
3. CDK BucketDeployment invalidation 타임아웃
스택 1개에 5개 이상 사이트를 묶었더니 invalidation 타임아웃 → UPDATE_ROLLBACK_FAILED 상태로 굳어버린 적이 있습니다. 그날 새벽 3시까지 continue-update-rollback 을 skip 시키고 직접 S3 sync 로 폴백을 친 다음에야 정상으로 돌렸습니다. 이후로는 CDK 스택을 사이트당 1개로 분리하고, invalidation 은 직접 boto3 호출로 처리하는 패턴을 표준으로 잡았습니다.
4. 메타데이터 i18n 누락
영문 title/description 을 누락시킨 채 6개월을 그냥 흘려보낸 사이트가 몇 개 있었습니다. 그 결과 글로벌 검색 유입을 6개월 동안 손해 봤습니다. 지금은 빌드 시점에 i18n 메타가 누락되면 빌드가 실패하도록 lint 스크립트를 박아 둡니다. 단순한 안전 장치인데 사이트 100개를 굴리는 운영자에게는 결정적입니다.
5. 같은 도구 코드를 8개 사이트에 복붙
레거시 KR 풀에서 발생한 일입니다. 동일한 컴포넌트 트리가 8개 사이트에 복붙으로 들어가 있었고, 한 군데를 고치면 일곱 군데가 그대로 남았습니다. microsaas-shared 패키지로 공통 컴포넌트를 묶고, 사이트별 차이는 props 로만 주입하는 구조로 리팩하면서 정리됐습니다. 지금은 새 사이트의 70% 가까이가 공통 컴포넌트 위에서 props 만 바꿔 끼우는 구조라서, 신규 사이트 한 개가 평균 4~6시간이면 라이브에 올라갑니다.
가장 큰 레버리지 5가지
1. 서브도메인 + 툴당 레포
bal.pe.kr/{tool} 같은 단일 도메인 + 경로 구조 대신 {tool}.bal.pe.kr + 툴당 GitHub 레포 구조로 갔습니다. 이 결정 한 번이 빌드 격리, 배포 충돌 제거, SEO 분리, AdSense 슬롯 관리까지 한 번에 해결해 줬습니다. 빌드 충돌은 0 입니다. 한 사이트 빌드가 깨져도 다른 사이트는 영향이 없습니다.
2. 공유 인프라 (CloudFront / ACM / S3)
OAC + Function + ACM 1개로 119개 사이트가 모두 굴러갑니다. 신규 사이트 추가 사이클이 처음 6시간에서 30분으로 줄었습니다. 인프라가 한 번 표준화되면 그 뒤로는 사이트가 5개여도 119개여도 사이클이 같다는 게 진짜 마이크로 SaaS 운영의 핵심입니다.
3. AEO 우선 (llms.txt)
전 사이트에 llms.txt 표준을 적용한 후 ChatGPT·Perplexity 의 인용률이 27% 가량 상승했습니다. 이건 GA4 referrer 분포로 직접 확인한 숫자입니다. AI 검색이 트래픽의 작지만 의미 있는 비율로 자리 잡고 있고, SEO 만 의존하던 시기보다 트래픽 내성도 훨씬 좋아졌습니다.
4. 7인 work-pool 팀 운영
분기에 한 번씩 대규모 개선 캠페인을 돌립니다. 그때는 운영자 1명이 모든 사이트를 손으로 만지지 않습니다. architect 1 + worker 5 + reviewer 1 의 7인 work-pool 구조로 Claude Code 에이전트를 병렬 dispatch 합니다. 2026 Q2 의 119개 사이트 종합 개선 캠페인이 2주 안에 완료된 것이 이 구조의 결과입니다.
5. 데이터 중심 의사결정
매주 일요일 GA4 + Search Console + 도구별 사용 로그를 30분 정도 회고합니다. 상위 5개에 80% 노력을 집중하고, 나머지는 자동화 유지보수만 합니다. 봇 트래픽 (미국·네덜란드·세이셸 desktop direct 시그니처) 이 전체의 30~40% 를 차지한다는 사실을 5월 8일에 알아낸 후로는, 분석 시 --no-bots 모드를 기본으로 씁니다. 봇이 30% 섞인 통계로 ROI 결정을 잘못한 적이 있어서 이건 두 번 안 틀리려 합니다.
운영자 체크리스트 10가지
다음은 신규 사이트 출시 시 운영자 본인이 매번 확인하는 항목입니다.
- [ ] 신규 사이트에 OAC·Function 신규 생성을 하지 않는다 (공유 자원 ARN 만 참조)
- [ ] llms.txt 가 sitemap 으로부터 자동 생성된다
- [ ] i18n 메타 누락 시 빌드가 실패한다
- [ ] 로컬 deploy 스크립트가 표준이다 (GHA 비상용)
- [ ] CDK 스택이 사이트당 1개로 분리되어 있다
- [ ] 공통 컴포넌트는 shared 레포에 있고 복붙이 아니다
- [ ] 주간 GA4 + GSC 리포트가 자동 생성된다
- [ ] 상위 5개 사이트에 SLA 99.9% 모니터가 붙어 있다
- [ ] AEO 인용률을 월 1회 추적한다 (ChatGPT 인용, Perplexity referrer)
- [ ] 분기 1회 운영 회고를 글로 남긴다
개인 SaaS 만드려는 사람을 위한 조언 5가지
- 첫 도구는 본인이 매주 쓰는 것 — 동기·디테일·디버깅 의지 세 가지가 한 번에 향상됩니다. 사용자 인터뷰가 필요 없습니다, 본인이 인터뷰 대상입니다.
- 인프라는 미리 표준화 — 5개째부터 카피 가능하도록 첫 도구를 만들 때 OAC, Function, lint, prerender 구조를 미리 박아두세요. 그러면 6개째부터 사이클이 30분으로 줍니다.
- SEO + AEO 동시 구축 — llms.txt 는 첫날부터 sitemap 과 같이 생성하도록 하세요. AI 검색 인입은 작지만 의미 있고, 첫 인덱싱이 빠를수록 누적이 큽니다.
- 로컬 배포 스크립트 — GHA 비용은 트랩입니다. S3 sync + CloudFront invalidation 두 단계는 로컬에서 충분합니다.
- 스코어링 → 우선순위 → 회고 — 모든 결정을 데이터로 남기세요. 본인 직관을 그대로 두면 6개월 뒤에 같은 실수를 반복합니다.
함께 보면 좋은 도구
1년 운영이 가르쳐 준 5가지 작은 진리
위에서 정리한 실수와 레버리지 외에, 글로 적기 애매하지만 1년 운영이 손에 박아 준 작은 진리가 몇 개 있습니다. 이걸 적어 두지 않으면 2년차에 잊어버리고 같은 실수를 할 것 같아서 같이 남깁니다.
첫째, "안 만드는 결정"이 "만드는 결정"보다 훨씬 어렵습니다. 운영자에게는 매주 새 도구 아이디어가 한두 개씩 떠오릅니다. 그중 90% 는 안 만들어야 합니다. 안 만드는 결정의 기준은 단 하나입니다 — "내가 매주 쓸 것 같은가?" 이 질문에 yes 가 안 나오면 안 만듭니다. 검색량이 많아도, 아이디어가 흥미로워도, 본인이 안 쓰는 도구는 디테일이 채워지지 않습니다.
둘째, 운영 일지가 콘텐츠보다 비싼 자산입니다. 이 글을 쓰면서 가장 도움이 된 것은 1년 동안 매일 적어둔 짧은 빌드 노트였습니다. 어느 날 어떤 결정을 왜 했는지가 적혀 있지 않으면, 6개월 뒤에 같은 결정을 다시 하게 됩니다. 짧게라도 매일 적는 게 정답입니다.
셋째, 트래픽보다 사용자 한 명의 얼굴이 운영을 지속시킵니다. yebang 의 138 UV spike 보다, "예방접종 일정 헷갈렸는데 덕분에 정확히 맞췄어요" 라는 단 한 통의 메일이 더 큰 연료가 됐습니다. GA4 숫자만 보면 번아웃에 빠집니다. 사용자 한 명의 메시지를 캡처해 두는 습관이 필요합니다.
넷째, 빠른 도구가 좋은 도구입니다. 마이크로 SaaS 의 정체성은 결국 "1초 안에 답을 준다" 입니다. 디자인이 화려한 도구보다, 빈 화면에서 input 한 칸만 떠 있는 도구가 더 잘 굴러갑니다. 사용자는 디자인을 보러 오지 않습니다.
다섯째, 글쓰기는 도구의 일부입니다. 도구만 잘 만들면 사용자가 알아서 오는 시대는 끝났습니다. AdSense 심사도, AEO 인용도, 사용자 신뢰도 모두 글이 만들어 줍니다. 코드와 글의 비중을 7:3 으로 두는 게 1년 회고 시점의 결론입니다.
정리 — 119개 만들고 남은 한 문장
119개를 만들고 1년이 지난 지금, 누가 한 문장으로 정리해달라 하면 이렇게 답할 것 같습니다. "중복을 제거하고, 자동화하고, 측정한다." 이 세 가지가 안 되면 5개째에서 사이트 개수가 멈춥니다. 이 세 가지가 되면 5개째부터는 사이클이 거의 같아져서 100개도 가능해집니다.
다음 1년의 목표는 숫자를 더 늘리는 게 아니라, 상위 5~10개 사이트가 천천히, 그러나 정직하게 사용자에게 닿게 다듬는 일입니다. 신규 출시는 분기당 1~2개로 줄이고, 그 대신 yebang·firekr 같이 이미 사람이 오는 사이트의 사용자 경험을 한 번 더 정직하게 깎습니다. 글도 두세 편이 아니라 한 편을 두 번 다듬는 쪽으로 갑니다. 그 다음에 2026 회고를 쓰러 다시 돌아오겠습니다.