혼자 119개 마이크로 사이트를 1년 운영한 솔직 회고

예상보다 잘 된 것, 예상치 못한 트래픽, 깨진 빌드와 가족과의 시간까지 — 1년 회고의 1인칭 기록.

2024년 4월에 첫 마이크로 사이트를 띄울 때만 해도, 한 해 뒤에 119개를 운영하고 있을 거라고는 상상하지 못했습니다. 솔직히 말하면 그때 저는 "한 5개쯤 만들고 그중 한두 개가 자리 잡으면 좋겠다" 정도의 얇은 기대를 갖고 있었습니다. 1년이 지난 지금, 5개도 아니고 119개. 숫자만 보면 거창해 보이지만, 그 안쪽은 그렇게 깔끔한 그림이 아닙니다. 이 글은 광고도 자랑도 아니고, 1년 동안 혼자 사이트들을 굴리며 제가 진짜로 마주한 장면을 한 번 정리해 두는 1인칭 기록입니다.

1년이 지난 시점의 운영자 정체성

본격적인 회고를 시작하기 전에 한 가지 짚어 두고 싶은 게 있습니다. 1년 전의 운영자는 "마이크로 SaaS 를 만드는 사람" 이었고, 지금의 운영자는 "마이크로 SaaS 119개를 운영하는 사람" 입니다. 비슷해 보이지만 이 둘은 다른 정체성입니다. 전자는 0 에서 1 을 만드는 사람의 사고방식이고, 후자는 1 을 1.2 로 다듬는 사람의 사고방식입니다. 1년 회고는 이 정체성 전환을 글로 적어 두는 작업이기도 합니다. 다음 1년에 다시 0 에서 1 로 돌아가지 않기 위해서 입니다.

사람이 안 오는 사이트도 많다

가장 먼저 솔직하게 말해야 할 것은, 119개 중 다수가 별로 사람이 오지 않는다는 사실입니다. GA4 대시보드를 열면 항상 같은 진실이 적혀 있습니다. 상위 5개 사이트가 전체 트래픽의 70% 가까이를 가져갑니다. 나머지 100여 개는 한 달에 두 자리 UV 도 채 안 되는 것이 절반이 넘습니다. 이걸 처음 알았을 때는 잠깐 무력감이 왔습니다. "내가 이걸 만든 시간들이 다 무의미한가" 같은 생각도 했습니다.

그런데 한참 들여다보다 보니 다른 그림이 보였습니다. 상위 5개를 만들 수 있었던 건, 그 아래 100개를 만드는 동안 제가 인프라·SEO·AEO·도메인 운영 감각을 손으로 익혔기 때문이라는 것. 그러니까 나머지 100개는 "실패"가 아니라 "수련"이었다고 인정하기로 했습니다. 사이트를 4시간 안에 라이브에 올릴 수 있는 손이 만들어지기까지 100개의 시도가 필요했습니다.

예상치 못한 트래픽 — 한 줄짜리 추천이 광고보다 강한 한국

예상치 못한 트래픽도 있었습니다. 2026년 5월 4일, 예방접종 안내 도구(yebang)가 갑자기 24시간 동안 138 UV를 찍었습니다. 평소에는 하루 두세 명 들어오던 사이트였습니다. 처음에는 봇인 줄 알고 GA4 의 봇 필터를 한참 봤는데, 검색 유입과 직접 유입이 섞여 있었습니다. 알고 보니 그 전날 제가 Threads 에 짧게 소개 글을 하나 올린 게 작게 퍼졌던 모양입니다.

그 다음날에는 firekr (한국 FIRE 시뮬레이터)가 53 UV. 두 번 다 광고 없이, 정말 글 한 줄 차이로 일어난 일이었습니다. 한 가지 확실히 배운 게 있다면, 한국 사용자에게는 검색만큼이나 짧은 추천 한 줄이 강하다는 것입니다. SEO 만 의지하는 마이크로 SaaS 운영자는 한국 시장에서 큰 레버리지 한 축을 놓치는 셈입니다. Threads, X, 카카오톡 오픈채팅, 블라인드 같은 한국 특유의 짧은 추천 채널을 처음부터 운영 동선에 포함시켰어야 했다고 1년 회고 시점에서 후회합니다.

짧은 추천 채널의 자산화

이 spike 경험은 운영 동선에 작은 변화를 가져왔습니다. 도구를 출시하면 그날 안에 Threads, X, 카카오톡 오픈채팅 중 한 곳에 짧은 소개 글을 한 줄 올리는 습관을 만들었습니다. 글 한 줄에 5분이 들고, 그 5분이 전체 1년 트래픽의 작지 않은 부분을 차지합니다. 글로벌에서는 SEO 가 절대적이지만, 한국에서는 짧은 추천 한 줄과 SEO 가 거의 동등한 채널입니다.

비용 — AWS 는 예상대로, GHA 는 예상 외

비용 이야기도 빼놓을 수 없습니다. 처음에 저는 "마이크로 SaaS 니까 비용은 거의 안 들 것"이라고 생각했습니다. 1년 굴려본 결과는 조금 달랐습니다. AWS S3 + CloudFront + ACM + Route 53 합쳐서 월 3~5만 원선. 도구가 늘어나도 이 숫자는 거의 안 변합니다. 여기까지는 예측대로였습니다.

문제는 GitHub Actions 였습니다. 사이트가 늘어나고 하루에 5번씩 배포가 돌아가던 시기에, 무료 한도를 우습게 넘기고 추가 청구가 나왔습니다. 이걸 한 달 만에 정리하고 microsaas-infra/scripts/local-deploy.sh 라는 로컬 배포 스크립트로 영구 전환했습니다. 이게 단순히 비용 절약이 아니라, 배포라는 행위 자체를 "내 손으로 책임지는 것"으로 옮겨준 변화여서 더 좋았습니다. 빌드가 깨졌을 때 GHA 로그를 들여다보는 것보다, 내 터미널에서 곧장 다시 돌리는 게 심리적으로도 훨씬 빠릅니다.

도메인 비용도 처음에 큰 결정이었습니다. bal.pe.kr 한 도메인 안에서 서브도메인으로 119개를 운영하기로 한 것. 사이트당 도메인을 따로 사면 119 × 연간 1만 원 = 연 119만 원이 됩니다. 이걸 처음부터 합친 게 가장 큰 단일 비용 절약이었습니다. 다만 그 대가로 도메인 차원의 SEO/AdSense 정책이 한 번 흔들리면 119개가 동시에 영향을 받습니다. 트레이드오프는 분명합니다.

가장 비싸게 배운 두 가지 실수

첫째, 사이트마다 CloudFront OAC 와 Lambda Function 을 새로 만들었다는 점. 6개월쯤 지나서 청구서를 보고 "어, 이게 왜 이렇게 늘었지" 싶어 들여다봤더니, 동일한 도메인 하위에서 OAC 과 Function 만 빠르게 늘어나면서 비용을 6배 가깝게 키워놓고 있었습니다. 그 뒤로는 공유 bal-pe-kr-rewrite-2 Function 과 static-shorts-oac 하나로 모든 신규 사이트가 들어가도록 패턴을 바꿨고, 이게 운영 메모리에 박힐 만큼 중요한 표준이 됐습니다.

둘째, CDK BucketDeployment 의 invalidation 타임아웃. 사이트 5개를 한 스택에 묶었더니 배포 중간에 타임아웃이 나면서 UPDATE_ROLLBACK_FAILED 라는 무서운 상태로 굳어버린 적이 있었습니다. 그날 새벽 3시까지 continue-update-rollback 을 skip 시키고, 직접 S3 sync 로 폴백을 친 다음에야 정상으로 돌렸습니다. 이 절차도 이제는 메모리에 박혀 있습니다. 마이크로 SaaS 100개를 운영하기로 한 운영자라면, 이런 복구 절차 두세 가지는 반드시 손에 박혀 있어야 합니다.

가족과의 균형 — 첫 아이가 1년 회고의 분기점

기술 외에 한 가지 더 솔직하게 적어두고 싶은 게 있습니다. 2025년 5월 27일에 첫 아이가 태어났습니다. 운영 1년의 후반부는, 솔직히 사이트보다 아이의 첫 옹알이가 훨씬 더 중요한 시기였습니다. 그런 와중에도 119개를 굴릴 수 있었던 이유는 두 가지.

하나는 인프라를 한번 표준화해두면 새 사이트 하나 띄우는 데 30분이면 충분해진다는 점. 또 하나는 "오늘은 이거 하나만 한다"고 내려놓을 줄 알게 됐다는 점입니다. 회사·가정·사이드 사이에서 시간을 다투다 보면, 가장 큰 적은 비효율이 아니라 욕심이라는 걸 배웠습니다. 한 분기에 1개 진짜로 끝내는 사람이, 매주 5개 시작하기만 하는 사람보다 1년 뒤에 훨씬 멀리 가 있습니다.

아이가 태어난 뒤로는 출시하는 도구의 결도 바뀌었습니다. 이유식 단계 안내, 영유아 발달 마일스톤, 예방접종 안내. 이건 시장 분석이 아니라 그냥 내가 매일 검색하던 키워드를 그대로 도구로 만든 것입니다. 본인이 매주 쓰는 도구가 가장 좋은 도구라는 말은 정말 맞는 말입니다.

GA4 데이터 한 가지만 더 — 봇 트래픽

2026년 4~5월 평균 일간 활성 사용자는 사이트 전체 합쳐 약 250~400 사이를 오갔고, 봇 트래픽이 30~40% 섞여 있다는 걸 5월 8일에야 알아냈습니다. 그날부터 GA4 의 --no-bots 분석 모드를 기본으로 쓰고 있습니다.

봇을 거르고 보는 진짜 사용자 수는 처음엔 좀 시무룩한 숫자입니다. 하지만 정확한 숫자가 정확한 의사결정을 만듭니다. 봇이 30% 섞인 통계로 "어, 이 사이트 잘 되네" 했다가 광고 ROI 결정을 잘못한 적이 있어서 이건 두 번 안 틀리려 합니다. 미국·네덜란드·세이셸 desktop direct 시그니처가 한국향 마이크로 SaaS 의 30~40% 를 차지한다는 사실은 한국 1인 개발자들 사이에 공유될 가치가 있는 데이터라고 봅니다. 다만 봇 IP 자체를 차단하지는 않습니다. 분석에서만 제외하면 충분하고, IP 차단은 운영 부담을 늘립니다.

1년이 남긴 가장 큰 자산

1년 회고를 마치면서 누군가 묻는다면, 119개를 만들었다는 사실보다 "안 만들 수 있는 것을 안 만드는 감각"을 얻었다는 점이 더 큰 자산입니다. 처음에는 모든 도구가 새로 만들어야 할 무엇이었다면, 지금은 이미 있는 컴포넌트를 props 만 갈아끼우는 일이 80% 입니다. 시간이 비효율적으로 새지 않고, 본업과 가족이 1순위인 시기에도 사이트가 멈추지 않는 이유입니다.

다음 1년의 목표는 숫자를 더 늘리는 게 아니라, 상위 5~10개 사이트가 천천히, 그러나 정직하게 사용자에게 닿는 것을 다듬는 일입니다. 신규 119개는 안 만듭니다. 신규 출시는 분기당 1~2개로 줄이고, 대신 yebang·firekr 같이 이미 사람이 오는 사이트의 사용자 경험을 한 번 더 정직하게 깎습니다.

1년 동안 만난 의외의 사실 5가지

회고의 마지막에 한 가지 더 적어두고 싶은 게 있습니다. 1년 동안 만난, 운영 시작 전에 알았더라면 좋았을 의외의 사실 5가지입니다.

첫째, 글 한 편의 영향력이 도구 한 개보다 클 수 있습니다. yebang 사이트의 138 UV spike 는 새 도구가 아니라 Threads 글 한 편이 만든 결과였습니다. 코드 시간 6시간보다 글 시간 30분이 트래픽으로는 더 큰 결과를 줍니다. 1인 운영자가 코드와 글의 시간을 7:3 정도로 두는 게 1년 회고 시점의 결론입니다.

둘째, AdSense 의 콘텐츠 평가가 글의 구조 균일성에 민감합니다. 24편의 블로그가 모두 같은 H2 트리를 따르면 자동 생성 의심을 받습니다. 같은 정보를 5가지 다른 톤(회고·Q&A·데이터 분석·인터뷰·빌드 노트) 으로 나누는 게 그래서 의미가 있습니다. 글의 양보다 톤의 다양성이 AdSense 통과에 더 중요한 시그널일 가능성이 있습니다.

셋째, CloudFront Function 의 한도. v1 함수가 한도를 채워서 신규 사이트에 더 못 붙는 시점이 옵니다. v2 함수로 미리 옮겨두지 않으면 어느 날 갑자기 신규 사이트 deploy 가 막힙니다. 운영자 메모리에 박혀 있어야 할 표준입니다.

넷째, 사이트의 절반은 만든 사람조차 정확히 기억하지 못합니다. 119개 중 운영자가 한 번에 떠올릴 수 있는 사이트는 30~40개입니다. 나머지는 검색해서 찾아야 합니다. 이건 단점이 아니라 분산형 마이크로 SaaS 의 자연스러운 결과입니다. 모든 사이트를 머리에 두려고 하지 마세요.

다섯째, 본업의 인프라 패턴이 사이드에 더 큰 영향을 줍니다. 사이드의 결과물이 본업에 흘러들어가는 건 알기 쉽지만, 그 반대 방향이 훨씬 큽니다. 본업에서 AWS 인프라를 매일 만지는 사람만이 119개를 월 3~5만 원에 굴릴 수 있습니다. 본업이 사이드의 가장 큰 자산이라는 점을 1년차에 알게 된 게 다행입니다.