타이니그램

CMS를 만들고 있습니다

Sun, 31 May 2026 00:00:00 GMT

CMS는 블로그 엔진, 사이트 빌더, 이커머스 플랫폼, 헤드리스 CMS, 노코드/로우코드 등 다양한 용어만큼이나 각각의 도구는 목적과 서비스 지향점에 따라 기능의 차이가 있지만 포괄적으로는 모두 CMS의 성격을 가지고 있습니다. 그리고 그만큼 레드오션인 제품 영역입니다.

1인 개발을 시작하기로 했을 때 평소 생각했던 아이디어가 몇 가지 있었지만, 대부분 플랫폼 성격의 서비스들이었고 이들은 공급자, 소비자 사이드 모두가 필요한 양면 시장을 다루는 서비스라 1인 개발로 시작하기에는 무리가 있다는 판단이 있었습니다.

하지만 CMS는 레드오션 제품일지라도 공급자 사이드를 소비자로 하는 B2B 성격이 강하고, 제가 만들어갈 CMS는 콘텐츠 비즈니스 기능에 중점을 둔 크리에이터를 위한 수익화 도구를 지향하기 때문에 1인 개발자인 저와 소비자인 크리에이터가 동질성을 가지며 함께 성장할 수 있을 거라는 기대가 있습니다.

이커머스 도구

콘텐츠 비즈니스 도구로서의 CMS를 만들어 보고 싶다고 생각했던 계기는 공방을 준비하면서 이커머스 도구를 찾아볼 때입니다.

셀러들을 위한 이커머스 도구는 여러 선택지가 있지만 크게 채널과 인프라 소유권으로 분류해 보면 대체로 손이 많이 갈수록 브랜딩, 결제, 운영 자유도가 높지만 서비스 운용 비용이 증가하고, 플랫폼에 종속될수록 편리하고 비용이 낮지만 그만큼 많은 제약이 따릅니다.

구분	브랜딩 자유도	결제 자유도	장단점
입점형	최저	최저	유입과 결제 신뢰를 얻지만, 고객이 내 것이 아니고 수수료가 계속 나감
임대형	중상	중	자체 브랜드로 빠르게 시작하지만, 월정액과 솔루션 틀에 묶임
설치형	최고	최고	수수료 없이 전부 통제하지만, 구축과 운영을 직접 떠안음

마켓플레이스 입점형: 쿠팡, G마켓, 11번가, 스마트스토어, Amazon
쇼핑몰 솔루션 임대형: 카페24, 고도몰, 아임웹, 식스샵, Shopify
셀프호스팅 설치형: XE 커머스, 영카트, WooCommerce

추가로 자체 개발하는 독립형과 링크페이, 블로그페이 등의 결제 레이어도 있습니다.

콘텐츠 비즈니스 도구

공방 쇼핑몰 사이트는 임대형인 아임웹에서 시작했습니다. 브랜딩과 편리함 그리고 운영 자유도를 위한 적절한 선택이었다고 생각합니다.

개발자라 그런지 처음에는 익숙한 이름의 Shopify를 선택했었지만, 준비 과정 중 결제와 송장 출력 문제로 국내 서비스로 변경했습니다.

당시 블로그 수익화에도 관심이 있었기에 수익화 가능한 CMS들을 찾아봤고, 콘텐츠 비즈니스 도구로서의 CMS는 이커머스와 구도는 유사하지만 분류에 따라 조금씩 차이가 있다는 것을 알게 됐습니다.

구분	브랜딩 자유도	결제 자유도	장단점
입점형	최저	최저	발견과 추천으로 독자를 얻지만, 구독자 명단과 결제가 플랫폼에 묶여 못 가져옴
임대형	중상	중하	발행부터 수익화까지 통합 제공되지만, 국내 결제가 막혀 실효성이 떨어짐
설치형	최고	최고	구독자와 결제 관계를 온전히 소유하지만, 조립할 부품이 너무 많음

콘텐츠 플랫폼 입점형: 네이버 블로그, 티스토리, 브런치, 네이버 프리미엄콘텐츠, 포스타입, Medium, Substack, Patreon
퍼블리싱 솔루션 임대형: 메일리, 스티비, 아임웹, Ghost(Pro), beehiiv, Kit, Squarespace, Webflow
셀프호스팅 설치형: 그누보드, 라이믹스, 텍스트큐브(종료), WordPress, Ghost, Strapi

이커머스와 수익 구조의 차이는 있지만 입점형은 콘텐츠 쪽에도 많은 플랫폼이 있고, 설치형은 이커머스 기반이지만 콘텐츠 수익화 용도로도 어느 정도 활용 가능한 상황입니다. 하지만 임대형은 국내 활용 가능한 편리한 전용 도구가 부재합니다.

Ghost(Pro)와 WordPress.com 모두 수익화를 위해서는 국내에 막혀 있는 Stripe를 요구하고 스티비, 메일리는 뉴스레터 기반이며 카페24, 아임웹, 식스샵은 이커머스 중심이라 콘텐츠 비즈니스 전용 도구로는 부족합니다.

이커머스와 마찬가지로 콘텐츠도 운영과 수익화 측면에서 임대형이 절충안입니다. 조사 당시 콘텐츠 비즈니스 전용 도구의 부재는 상당히 의외였고 이것이 바로 창업자들이 말하는 페인포인트인지, 돈이 안 되니까 여태 없는 것인지는 모르겠지만 기업 규모가 아닌 1인 개발 창업자에게는 충분한 시장이지 않을까 하는 막연한 생각이 들었습니다.

1인 개발 준비하기 6 - 생태계

Thu, 12 Feb 2026 00:00:00 GMT

1인 개발 준비하기 시리즈
1편 - 웹 개발 전환
2편 - 웹 프레임워크
3편 - 외주 개발
4편 - 인프라
5편 - 최종 스택

프로젝트에 들어가기 전, 모던 웹 개발의 기초라고 생각한 TypeScript, React, Next.js, Express.js는 공식 문서와 Udemy 강의, 유튜브 튜토리얼로 익혔습니다. JavaScript는 필요할 때마다 모던 JavaScript 튜토리얼을 찾아봤습니다. freeCodeCamp의 커리큘럼도 눈에 들어왔는데, 분량이 많아 시간 여유가 있을 때 볼 생각입니다.

Astro는 아일랜드 아키텍처(Islands Architecture)에 평소 관심이 있었고, 개발 블로그를 정적 사이트로 만들면서 공식 문서와 튜토리얼로 학습했습니다. TanStack Router와 Start, Hono, 클라우드플레어는 공식 문서를 간략히 훑은 뒤 프로젝트를 진행하며 익혔고 지금도 계속 이어가고 있습니다.

PHP와 jQuery, JavaScript로 이어지는 웹의 큰 흐름은 대략 알고 있었기에, 도메인을 웹으로 넓히기로 한 이상 PHP로 만들어지는 웹사이트가 궁금했습니다. Laracasts의 기초 시리즈 PHP For Beginners는 Laravel 없이 PHP만으로 웹사이트를 만드는 과정, 그리고 리팩터링을 거쳐 아주 작은 프레임워크를 직접 만들어 가는 과정을 보여줍니다. 웹과 웹 프레임워크를 이해하는 데 도움이 많이 됐습니다. 실무에서 TypeScript 풀스택을 쓰더라도 한 번쯤 볼 가치가 있다고 생각합니다. 기회가 되면 jQuery도 직접 써 보고 싶습니다.

새로운 도메인을 접하면 뉴스레터를 구독하는 편입니다. 바쁠 때는 내용까지 보지 않아도 제목만으로 트렌드와 주요 이슈를 확인할 수 있습니다.

Hacker News, DEV, daily.dev도 가끔 보기 좋지만, GeekNews를 슬랙으로 받아 보면 편리하고 뉴스레터도 제공합니다.

뉴스레터는 생태계를 따라가기에 효과적이지만 재미는 없습니다. 유튜브에서는 이런 채널을 즐겨 봅니다.

CultRepo - 텀은 길지만 꾸준히 올라오는 명작 다큐멘터리
OfferZen Origins - TypeScript와 Svelte 다큐멘터리가 있지만 새 업로드는 멈춘 듯
Syntax, Fireship - 재미있고 유익한 최애 채널
코딩애플 - 의외로 유익

마지막으로 아웃사이더님의 RetroTech 팟캐스트는 첫 JavaScript 프레임워크인 prototype.js부터 jQuery, Angular.js를 거쳐 React, Vue.js, Svelte까지 주요 프레임워크를 소개합니다. JavaScript를 중심으로 에피소드가 구성되어 방대한 웹 생태계의 일부만 다루지만, 지금 쓰는 메인 기술 스택이 어떻게 발전해 왔는지 알 수 있는 유익한 시리즈입니다.

십여 년 전 Vue로 웹 개발을 처음 접했을 때 상당히 매력적이라고 느꼈는데, 왜 더 빨리 웹으로 넘어오지 않고 iOS만으로 직장 생활을 마무리했는지 후회될 만큼 웹 개발은 즐겁습니다.

1인 개발 준비하기 5 - 최종 스택

Tue, 03 Feb 2026 00:00:00 GMT

1인 개발 준비하기 시리즈
1편 - 웹 개발 전환
2편 - 웹 프레임워크
3편 - 외주 개발
4편 - 인프라

스택의 중심은 웹 코어 하나입니다. 어떤 제품이든 이 코어를 공유하고, 유형에 따라 감싸는 방식만 달라집니다.

하나의 웹 코어로 시작

웹 코어는 TanStack Start와 React입니다. SaaS든 일반 웹앱이든 공개 사이트든, 서버 렌더링(SSR)이 필요한 제품은 여기서 출발합니다. React 진영에서 가장 대중적인 선택은 Next.js지만 이번에는 고르지 않았습니다. 가장 큰 이유는 4편에서 정한 인프라와 맞물립니다. Next.js는 Vercel을 우선하는 프레임워크라 클라우드플레어에서는 어댑터를 경유해야 하고 그만큼 제약이 따르는 반면, TanStack Start는 클라우드플레어를 정식 파트너로 두고 어댑터 없이 곧장 배포됩니다. 인프라를 클라우드플레어로 정한 이상, 그 위에서 가장 매끄럽게 도는 프레임워크를 고르는 편이 자연스러웠습니다.

이유는 더 있습니다. TanStack Start는 TanStack Router를 기반으로 하기 때문에, 뒤에서 이야기할 어드민 SPA를 만들 때 라우팅을 따로 익힐 필요가 없습니다. 웹 제품과 어드민이 같은 라우터를 공유합니다. 데이터 패칭에서 널리 쓰이는 TanStack Query도 같은 팀이 만들었으니 궁합이 좋으리라 기대했습니다. 정식 버전 직전 단계인 RC(Release Candidate)이긴 하지만 기능은 사실상 완성됐고 API도 안정적이라 호환성을 깨는 큰 변경은 예정에 없고, 하나둘 전환 후기가 올라오는 것도 마음을 놓게 하는 근거였습니다. 무엇보다 테너 린슬리가 예고한 그들만의 방식의 RSC(React Server Components)와 TanStack 생태계 전반에 대한 기대가 컸습니다. 서버 우선 아키텍처에 전부를 내어 주는 대신, RSC를 또 하나의 서버 사이드 상태로 두고 캐싱하고 합성하겠다는 방향입니다. 같은 이유로 SPA도 여전히 일급 시민으로 남습니다.

어드민처럼 서버 렌더링이 필요 없는 내부 도구는 TanStack Router만으로 SPA를 구성합니다. 웹 코어가 이미 Start를 통해 같은 라우터를 쓰고 있으니, 추가 학습 없이 그대로 이어집니다. 순수하게 콘텐츠 중심인 사이트, 이를테면 문서나 블로그, 랜딩은 Astro로 갑니다.

API가 필요하면 Hono로 만들어 Cloudflare Workers에 배포합니다. 워커 하나를 하나의 작은 서비스로 두고, 필요한 자원은 바인딩으로 연결하는 방식입니다. 같은 코드베이스에서 CLI와 MCP 서버를 함께 뽑아 클로드와 연동하면 운영까지 하나의 흐름으로 이어지는데, 이 부분은 확장 이야기에서 다시 다룹니다.

인증은 외부 서비스에 기대지 않고 BetterAuth로 자체 호스팅해 내재화합니다. 4편에서 인증은 내재화하는 편이 낫다고 짧게 언급했는데, 그 이야기입니다.

모바일은 이 웹 코어를 모바일 우선으로 반응형 설계한 뒤 하이브리드로 감싸는 데서 출발합니다.

모바일도 웹에서 시작

모바일 앱도 결국 같은 웹 코어에서 시작합니다. 1편에서 모바일은 초기에 웹뷰를 감싸는 하이브리드로 처리하고 넘어간다고 했는데, 그 방침은 지금도 유효합니다. 모바일 우선으로 반응형을 적용한 웹을 React Native나 Flutter, 또는 안드로이드와 iOS 네이티브 등으로 감싸 앱으로 배포합니다. 무엇으로 감쌀지는 팀 사정과 이후 계획에 따라 달라집니다. 이 부분은 좀 더 연구해 볼 필요가 있어 추후 별도 포스트로 다뤄 보겠습니다.

핵심은 처음부터 전부 네이티브로 만들지 않는다는 데 있습니다. 하이브리드로 출발한 뒤, 성능이 중요하거나 UI/UX가 중요한 화면만 골라 점진적으로 네이티브로 옮깁니다. 반대로 공지사항이나 마케팅, 이벤트처럼 자주 바뀌고 앱 심사와 무관하게 갱신하고 싶은 부분은 웹으로 남겨 둡니다. 초기 네이티브 전환은 기능을 늘리기보다 동작의 자연스러움과 성능에 초점을 맞추는 편이 좋습니다. 사용자가 가장 먼저 체감하는 지점이 바로 거기이기 때문입니다.

이 전략이 성립하려면 한 가지 원칙이 필요합니다. 비즈니스 로직은 가능한 한 서버로 밀어 두고, 프론트는 화면을 그리는 역할에 가깝게 두는 것입니다. 로직이 프론트에 두껍게 얹혀 있으면 플랫폼마다 그것을 다시 구현하게 되고, 네이티브로 옮기는 순간마다 부담이 커집니다. 반대로 로직이 서버에 모여 있으면, 프론트가 웹이든 네이티브든 같은 서버를 바라보기만 하면 되므로 전환이 한결 가벼워집니다.

안드로이드와 iOS 네이티브 개발자들은 앱 안에 클린 아키텍처를 비롯한 여러 구조를 독립적으로 적용하려 애쓰는 경우가 많습니다. 필요한 부분이 없지는 않지만, 설계가 지나치고 레이어가 잘게 나뉠수록 복잡도가 올라가 초기 생산성이 떨어집니다. 하나의 서비스를 이루는 시스템 전체로 보면 앱의 본질은 프레젠테이션 레이어입니다. 담당 개발자는 자기 구현에만 몰두하기 쉽지만, 지금 비즈니스가 어느 단계에 와 있는지 파악하는 일이 무엇보다 중요합니다.

확장은 필요해진 다음에

여기까지가 출발 지점의 스택입니다. 중요한 것은 이 스택이 성공을 전제로 처음부터 크게 설계되지 않았다는 점입니다. 필요가 생길 때, 그러니까 서비스가 어느 정도 성공했을 때 그만큼만 확장합니다.

처음에는 웹 워커 하나가 데이터베이스를 직접 바라보게 둡니다. 공통 로직을 별도 패키지로 빼 두면, 웹은 별도의 API 호출 없이 그 로직으로 데이터를 읽습니다. 거의 모노리스처럼 단순합니다. 그러다 CLI나 어드민, 혹은 외부에서 같은 데이터를 필요로 하는 순간이 오면, 같은 로직을 API 워커로 떼어내 HTTP로 엽니다. 로직 자체는 그대로이므로 다시 짤 일이 없습니다. 웹은 계속 직접 읽고, 새로 붙는 클라이언트는 API를 거칩니다.

서비스가 더 늘면 워커를 더 쪼갭니다. 도메인 하나에 가벼운 게이트웨이 워커를 두고 기능별로 경로를 나눠 독립 워커에 매핑하면, 각 기능이 독립적으로 배포되고 확장됩니다. 워커끼리 내부에서 호출해야 할 때는 서비스 바인딩으로 잇습니다. 같은 스레드에서 지연 없이, 추가 비용 없이 이어집니다. 모노리스인 듯 아닌 듯 여러 워커를 두는 데 부담을 느낄 필요가 없습니다. 필요한 만큼 나누고, 필요 없으면 합쳐 두면 그만입니다.

인프라도 같은 방식으로 넓혀 갑니다. 처음에는 워커와 R2만으로 이미지를 다루다가, 리사이징이나 최적화가 본격적으로 필요해지면 Cloudflare Images로 옮깁니다. 데이터베이스는 D1의 SQLite로 시작하되, 기능이나 성능이 부족해지는 시점이 오면 Neon과 Hyperdrive를 얹어 정식 PostgreSQL로 전환합니다. 어느 쪽이든 처음부터 큰 것을 들이지 않고, 벽에 부딪히는 그 지점에서만 한 칸씩 올립니다.

인증도 마찬가지입니다. 인증 자체는 BetterAuth로 내재화해 워커 안에서 끝나지만, 인증 과정에서 사용자에게 메일을 보내야 하는 경우에는 전송 수단을 하나 붙여야 합니다. 지금은 Resend 같은 외부 발송 서비스를 연결하거나, 아예 구글 같은 소셜 로그인만 지원해 메일 발송 자체를 없애는 방법이 있습니다. 다만 이 의존도 오래가지 않을 것 같습니다. Cloudflare Email Service가 지금은 비공개 베타지만 가까운 시일에 열리면, 이미지에 이어 이메일까지 플랫폼 안으로 들어와 커버리지가 한층 넓어집니다.

마지막은 운영입니다. 확장이 진행될수록 손이 가는 곳도 늘어납니다. 이때 필요한 것이 앞서 말한 CLI와 MCP 서버입니다. API를 그대로 소비하는 얇은 CLI를 두면 반복 작업을 명령 한 줄로 처리할 수 있고, 같은 API를 MCP로 노출해 클로드와 연동하면 운영의 상당 부분을 대화로 넘길 수 있습니다.

덧붙이면 여기 적은 것이 전부 검증된 이야기는 아닙니다. 직접 만들어 확인한 부분이 있고, 아직 계획에 머문 부분도 있습니다. Cloudflare Email Service나 Hyperdrive와 Neon 조합이 후자입니다. 포트폴리오와 데모 프로젝트를 진행하면서 다듬어 볼 생각이고, 그 과정은 따로 포스트로 공유하겠습니다.

참고

Why choose TanStack Start and Router? - 타입 안전 라우팅, SPA 지원, Query 통합, RSC를 서버 사이드 상태로 다루는 방향
TanStack Start v1 Release Candidate - RC 도달, API 안정, RSC 지원 예고
Why Cloudflare, Netlify, and Webflow are collaborating to support Open Source tools like Astro and TanStack - 클라우드플레어의 Astro·TanStack 후원과 파트너십
Announcing Cloudflare Email Service's private beta - 워커 바인딩 기반 이메일 발송, 비공개 베타

1인 개발 준비하기 4 - 인프라

Wed, 28 Jan 2026 00:00:00 GMT

2편에서 제품에 쓸 기술 스택을 고르는 동안, 어느 인프라를 사용할지 고민하고 있었습니다. Laravel이라면 저렴한 해외 VPS를 쓰고, .NET이라면 애저를 사용합니다. PHP/Laravel용 저렴한 해외 VPS 호스팅 업체는 많고, .NET은 애저와의 통합이 매끄럽기 때문입니다. 다른 방법으로는 AWS Lightsail로 출발해 규모에 맞춰 AWS로 옮겨 가는 것도 가능합니다. Lightsail은 AWS의 다른 서비스로 확장, 이전하는 도구를 잘 갖추고 있습니다. 모두 합리적인 선택이라 생각했습니다. 하지만 기술 스택을 TypeScript 풀스택으로 결정하면서 인프라도 처음부터 다시 생각하게 됐습니다.

반복 실험을 방해하는 고정비

1인 창업은 여러 실험을 빠르게, 그것도 반복해서 돌려 봐야 하는 일입니다. 이 관점에서 다시 보니 VPS와 AWS의 복잡한 관리 요소, 그리고 만만치 않은 고정비가 부담으로 다가왔습니다. 서버를 띄워 두는 것만으로 매달 비용이 빠져나가는 구조는, 성공을 장담할 수 없는 실험을 여러 번 시도해야 하는 상황과는 잘 맞지 않습니다. 게다가 이 비용은 프로젝트 수만큼 쌓입니다. 사용자가 없는 MVP 하나를 더 띄우는 것만으로도 고정비가 따라 붙어서, 시도 횟수를 늘릴수록 청구서도 같이 불어납니다.

그래서 기준을 바꿔 초기 고정비가 없거나 적어서 부담 없이 몇 번이고 다시 실행해 볼 수 있는 서버리스 제품이 낫다고 판단했습니다. 유휴 상태에서는 비용이 0으로 내려가고(scale-to-zero) 트래픽이 붙을 때만 과금되는 구조라면, 실험의 문턱이 크게 낮아집니다.

물론 AWS, 애저, GCP 3대 클라우드도 서버리스를 제공합니다. 다만 MVP 하나를 굴리기에는 앞서 말한 관리 요소와 고정비 부담이 여전해서, 좀 더 가벼운 업체를 고를 필요가 있었습니다.

편리함이 부르는 확장 부담

서버리스 업체는 결이 제각각입니다. 컴퓨팅, 스토리지, 데이터베이스, CDN 같은 인프라 중심 업체가 있는가 하면, 인증, 메일, 검색, CMS, 결제 같은 서비스 중심 업체도 있습니다. 분류 기준도 많고 저마다 커버리지가 달라서, 이름값만으로 줄을 세우기가 어렵습니다.

파이어베이스와 슈파베이스는 인증, DB, 스토리지, 함수를 하나로 묶은 균형 잡힌 BaaS(Backend as a Service)로 평판이 좋습니다. 특히 초기 프로젝트를 빠르게 구현할 수 있는데, 무엇보다 귀찮고 까다로운 인증 시스템을 손쉽게 통합할 수 있다는 것이 장점입니다.

문제는 그다음입니다. 인증 시스템이 내재화되지 않고 핵심 비즈니스 로직을 서버리스 함수에 기대야 한다는 점은, 훗날 서비스를 확장하거나 이전할 때 만만치 않은 비용으로 돌아옵니다. 파이어베이스로 초기 구성을 하고 성장하면서 자연스럽게 GCP로의 확장을 생각해 볼 수 있습니다. 하지만 회사에서 볼륨 있는 프로젝트로 몇 차례 시도해 본 경험을 떠올리면, 과금이 특별히 저렴하지도 않았고 확장을 위한 DB 재설계와 앱 아키텍처 변경 등 이전에 드는 리팩터링 비용이 상당했습니다.

파이어베이스나 슈파베이스를 큰 아키텍처 변경 없이 끝까지 쓸 수 있고 과금도 감당 가능한 수준이라면, 나쁘지 않은 선택입니다. 다만 점진적 개선과 확장을 위한 리팩터링을 지향하는 방향과는 맞지 않아서, 데모나 토이 프로젝트 정도로만 권할 만합니다.

참고로 Clerk, Auth0 같은 인증 서비스도 초기 편리함과 무료 티어만 보고 택하기보다는, 같은 이유에서 BetterAuth로 자체 호스팅해 내재화하고 SMTP 릴레이 정도만 외부 서비스를 쓰는 편이 낫습니다.

Vercel과 Netlify는 좋은 개발자 경험으로 인기가 많습니다. 웹을 호스팅하기에 최적화되어 있고 서버리스 함수도 갖췄지만, 범용 컴퓨팅 인프라로 보기에는 아쉬운 구석이 있고 자체 데이터베이스가 없어 외부 서비스를 빌려 써야 합니다. 거기에 이따금 들려오는 Vercel의 과금 이슈는, 그럴 만한 사정이 있다 해도 1인 개발자에게는 괴담처럼 들려 막연한 거부감을 남겼습니다.

이처럼 업체마다 커버리지와 장단점이 갈리다 보니, 여럿을 조합해 쓰면 이번에는 관리 요소가 불어납니다. 그나마 커버리지가 넓은 파이어베이스도 인증 내재화라는 숙제가 남아 고민이 이어졌습니다. 결국 더 범용적이면서 저렴하고, 적용 범위까지 넓은 서버리스 플랫폼 하나가 필요했습니다.

클라우드플레어 하나로

그러다 예전에 찜해 두고 잊고 있던, 개발자를 위한 클라우드플레어를 다룬 영상 하나가 눈에 들어왔습니다. 그동안 클라우드플레어는 CDN과 DDoS 방어, GitHub Pages 비슷한 Pages 정도로만 알고 있었는데, Cloudflare Developer Platform은 그보다 훨씬 넓은 개발 플랫폼이었습니다.

혼자서도 컴퓨팅부터 DB, KV(키-값 저장소), 스토리지까지 한 플랫폼에서 한 번의 배포로 끝낼 수 있어 따로 조립하고 운영할 것이 거의 없었습니다. 실시간 통신과 WebSocket은 Durable Objects로 처리합니다. 유휴 시 scale-to-zero로 내려가고, egress(데이터 송신)가 무료이며, 기본 DDoS 방어가 포함되고, 요금이 예측 가능해 청구 폭탄을 걱정할 일이 적었습니다. 여기에 더해, 요금이 프로젝트가 아니라 계정 단위로 매겨진다는 점이 컸습니다. 요구사항에 맞춰 무료 플랜이나 월 5달러 유료 플랜 하나로 MVP를 몇 개든 얹을 수 있으니, 시도 횟수가 곧바로 비용으로 불어나지 않습니다. 반복 실험을 전제로 하는 1인 창업에는, 이만큼 마음 편한 비용 구조도 드뭅니다. 엔터프라이즈급 시스템이 필요한 서비스가 아니라면, 클라우드플레어만으로도 상당한 수준의 요구사항까지 수용할 수 있어, 서비스를 운영하는 동안 확장이나 이전을 위해 구조를 크게 손볼 일이 많지 않습니다.

아쉬운 점이 없지는 않습니다. D1이 SQLite라는 점, 하위 플랜에서는 서울 엣지가 보장되지 않는다는 점, 조직 단위 관리 개념이 아직 자리 잡지 않았고 개발자 경험도 최상급이라 하긴 어렵다는 점이 그렇습니다. 그럼에도 비용 걱정 없이 반복 가능한 1인 창업이라는 목적에는, 이만한 조합을 찾기 어려웠습니다.

인프라를 고르는 기준도 스택과 크게 다르지 않았습니다. 기능이 얼마나 많은지, 취향에 맞는지보다는 실패를 몇 번이고 감당할 수 있는 비용 구조와 성공했을 때 갈아엎지 않아도 될 확장성을 보고 클라우드플레어를 선택했습니다.

참고

1인 개발 준비하기 3 - 외주 개발

Fri, 23 Jan 2026 00:00:00 GMT

직접 만들 제품의 스택을 고민하는 한편으로, 외주 개발 고객에게 제안할 기술 스택도 함께 검토하고 있었습니다. 외주 스택은 금방 정해졌습니다. 모바일은 React Native나 Flutter, 프론트엔드 SPA는 React, SSR이 필요하면 Next.js, 백엔드는 Spring이나 NestJS. 인프라는 빠른 MVP나 투자 유치용 데모 단계에는 슈파베이스, 정식 서비스에는 AWS. 현업에서 대중적이고 익숙한, 당연해 보이는 선택이었습니다.

몇 가지 고민이라면 1인 외주 개발자가 안드로이드와 iOS 두 네이티브를 모두 소화하기 어렵다는 점과, Flutter나 Spring 대신 React Native와 NestJS를 골라 TypeScript로 스택을 통일해 두면 고객이 나중에 인력을 충원하거나 제품을 확장할 때 더 낫지 않을까 하는 점이었습니다.

그런데 정작 외주 개발 고객이 누구인지는 따져 보지 않았습니다.

이미 외부 투자를 받은 스타트업이라면 자체 인력을 꾸리거나 규모 있는 외주 개발사를 선택합니다. 1인 외주 개발자가 백엔드부터 웹과 모바일, 백오피스까지 하나로 묶어 턴키로 제공한다면, 찾아올 고객은 그쪽이 아닙니다. 외부 투자 없이 제품을 키우는 부트스트래퍼(Bootstrapper)이거나, 투자 유치를 위한 데모 제품이 필요한 쪽일 가능성이 큽니다.

결국 내 고객은 스스로 0 to 1을 만들어 내려는, 지금의 나와 비슷한 상황일 가능성이 큽니다. 제품을 만들며 쌓이는 노하우와 스택을 외주에도 그대로 쓰는 것이 최선이지 제품과 외주의 스택을 둘로 나누는 것은 추가 학습 시간과 관리 비용만 늘릴 뿐입니다.

그렇다고 제품의 기술 스택 후보였던 Laravel과 .NET 중 하나를 선택할 수는 없습니다. 제품을 납품하는 것과 고객이 그 제품으로 서비스를 운영하는 것은 다른 문제입니다. 서비스 운영에는 지속적인 기능 업데이트가 따르고, 성장에 맞춘 아키텍처 변경과 대규모 리팩토링도 필요해집니다. 그 과정에서 인력 구성 역시 바뀔 수밖에 없습니다. 국내 개발 인력 시장은 특정 스택으로 상당히 편중되어 있어서, 마이너한 기술 스택은 인력 충원이나 외주 개발사 섭외를 어렵게 만듭니다. 자칫 업데이트 시기를 놓쳐 경쟁 제품에 뒤처질 수 있습니다.

제품 자체가 사업의 속도를 따라가지 못해 병목이 되어서는 안 됩니다. 가능한 한 대중적인 기술 스택을 선택하거나, 적어도 다른 스택으로 전환하기 용이한 상태를 만들어 두어야 합니다. Laravel과 .NET보다 TypeScript 풀스택이 이 조건에 더 잘 맞습니다. 인력 시장이 넓어 충원이 수월하고, 서비스 성장에 맞추어 기술 스택을 점진적으로 확장하고 전환하기에도 유리합니다.

결과적으로 개인적인 취향은 뒤로 미루기로 했고, 고객에게 권할 스택을 그대로 제품에 쓰기로 했습니다.

1인 개발 준비하기 2 - 웹 프레임워크

Tue, 20 Jan 2026 00:00:00 GMT

결론부터 말하면 TypeScript 풀스택입니다.

뻔한 결론 같지만, 선택 과정에는 여러 방향과 고민이 있었고 결과적으로 개인적 취향과는 전혀 다른 선택을 하게 됐습니다.

풀스택의 두 가지 의미

하나는 프론트엔드와 백엔드 두 역할을 혼자 모두 개발한다는 의미의 풀스택이고, 다른 하나는 단일 웹 프레임워크로 하나의 제품을 개발하는 방식입니다.

전자는 지금까지 현업에서 해온 방식이라 익숙하고, 역할 구분이 외부에서 물리적으로 이루어져 경계가 명확하지만 초기 개발 오버헤드가 있습니다. 후자는 보다 전통적인 웹 개발 방식으로 초기 진행이 빠르지만, 서비스를 고도화하려면 레이어 분리와 추가 개발이 필요해질 수도 있습니다.

이 선택은 쉬웠습니다. 전편에서 언급했듯이, 성공할지 아직 모르는 서비스에 많은 비용과 시간을 들이는 것보다, 서비스 성장과 함께 점진적 개선을 추구하는 린 스타트업 방식에는 풀스택 웹앱이 더 잘 맞습니다.

성능과 스케일 이슈가 생기면 기존 웹앱을 BFF(Backend for Frontend)로 남기고 백엔드를 분리·확장하고, 모바일 앱이 필요하면 하이브리드로 감싼 뒤 모바일 고도화 시점에 웹뷰를 점진적으로 네이티브로 전환하고, SaaS라면 마케팅 사이트와 웹앱을 SPA로 분리합니다.

물론 라이브 서비스를 리팩토링하고 시스템 아키텍처를 변경하는 일은, 달리는 차에서 엔진을 교체하는 것에 비유될 만큼 리스크가 크고 어려운 작업입니다. 하지만 이런 요구사항이 생긴다는 것 자체가 서비스의 성공 가능성이 보인다는 신호이고, 막상 이런 리팩토링을 해보면 나름의 쾌감이 있기도 합니다. 무엇보다 불확실성에 필요 이상의 비용을 투입하지 않아야 합니다.

취향보다 생태계

풀스택 웹 프레임워크 선택은 여기서부터 상당히 고민스러웠습니다.

메인 후보는 Ruby on Rails, PHP Laravel, Python Django, C# .NET(Blazor), Swift Vapor였고, Elixir Phoenix, Rust Rocket, Go Gin, Kotlin Ktor는 마이너 후보로 두었습니다. 어디까지나 개인적인 분류입니다. 선택 기준은 취향에 맞는 언어, 배터리 포함(batteries included) 여부, 생태계 성숙도였습니다.

웹 개발로 전환하기 전에는 C/C++로 윈도우와 임베디드 리눅스를 개발하고, Objective-C/Swift로 iOS를 개발해 왔습니다. 모두 컴파일 언어이자 정적 타입 언어입니다. 이런 경력이 쌓이다 보니 Ruby, Python, JavaScript 같은 스크립트 언어에서는 미묘한 이질감을 느낍니다. 특히 JavaScript는 누군가는 쉽다는 이유로 웹 개발 입문자에게 추천하는 언어이지만, 복잡한 생태계는 차치하고서라도 그 동작 방식이 난해하게 느껴져서 JavaScript 웹 프레임워크는 후보에서 제외했습니다. 이때는 그랬습니다.

컴파일 언어를 좋아하고 Swift가 가장 익숙하다 보니 Vapor를 공부해 봤지만, 생태계가 너무 미성숙해서 실망했습니다. API 서버로는 나쁘지 않지만 풀스택 웹 프레임워크로는 턱없이 부족합니다. Rails, Laravel, Django, .NET을 제외하면 나머지 후보들도 생태계 성숙도 측면에서 부족한 부분이 있었습니다. 물론 저마다 성공적인 실제 사례가 있지만, 1인 개발자가 선택하기에는, 특히 API 서버가 아닌 풀스택 웹앱 개발을 목표로 하기에는 진입 문턱이 높을 것으로 예상됐습니다.

Laravel과 .NET

네 후보 중 Laravel과 .NET을 두고 오래 고민했습니다. Laravel은 인디, .NET은 엔터프라이즈 성격이 강하고, 둘 다 풍부한 배터리와 성숙한 생태계를 갖추고 있습니다.

풍부한 배터리 내장이 중요한 이유는, 프레임워크가 추구하는 '하나의 올바른 정답'이 생산성을 높인다고 보기 때문입니다. 굳이 비유하자면 Vue와 React의 관계와 비슷합니다.

10여 년 전, TIPS(정부 기술창업 지원 프로그램) 단계의 소규모 팀을 리딩한 적이 있습니다. SPA가 주류로 자리 잡기 시작한 지 얼마 지나지 않았을 때라, 프론트엔드 담당자와 함께 React, Vue, Angular 세 가지를 검토해야 했습니다. 지금도 그렇듯 당시에도 React가 대세였지만, 팀은 Vue를 선택했습니다. 프레임워크가 추구하는 하나의 올바른 방식과 쉬운 사용법이, 담당자가 바뀌어도 제품의 균질한 품질과 생산성을 보장해 줄 것이라는 판단에서였습니다.

1인 개발자에게는 이런 판단이 필요하지 않을 수도 있습니다. 하지만 라이브러리를 직접 검증하고 선택하는 시간과 실수를 줄여 준다는 점에서는 여전히 유효하고, Laravel과 .NET은 그 조건을 충분히 만족시킵니다.

.NET Blazor는 꽤나 심각하게 고민했습니다. C#을 HTML, CSS와 함께 JavaScript를 대체하는 언어로 쓸 수 있다는 점, 그리고 웹어셈블리(WebAssembly)를 편리하게 통합할 수 있다는 점이 좋아 보였습니다. (웹어셈블리로 프론트엔드의 언어 선택을 넓히려는 흐름은 웹의 진보 방향이라고 봅니다. 다만 아직 엣지 기술이라 실무 허들은 큽니다.) 게다가 .NET은 웹, 모바일, 데스크탑, 서버, 게임까지 거의 모든 것을 아우르는 강력한 플랫폼입니다. 거대 빅테크에 영혼만 팔면 고민 없이 편안함을 누릴 수 있습니다. 마이크로소프트와 애플의 지배 아래 수년간 개발해 와서 잘 압니다. 나름의 어려움이 있더라도 확실히 편할 겁니다.

Laravel은 특히 해외 인디해커(Indie Hacker) 사이에서 인기가 많습니다. 많은 것이 갖추어져 있고, Laravel Cloud라는 인프라까지 서비스하고 있어서 다른 걱정 없이 제품에만 집중하면 될 것처럼 보입니다. 한국에서 PHP의 인식이 좋지 않지만, 최근 PHP는 많이 개선됐고 Swift가 익숙한 입장에서 봐도 상당히 모던한 언어로 보입니다. $로 시작하는 변수만 빼면 그렇습니다.

태생이 백엔드 언어인 PHP와 달리, 동갑내기 JavaScript는 열흘 만에 설계된 초기의 결함을 이미 퍼져 나간 웹과의 호환 때문에 고치지 못한 채 안고 왔습니다. 언어 자체의 진화라는 조건은 PHP 쪽이 나았지만, 정작 지금의 웹을 지배하는 쪽은 JavaScript입니다.

Livewire를 사용하면 .NET Blazor처럼 JavaScript 없이 프론트엔드를 구성할 수 있다는 것도 큰 장점입니다. 지금도 두 프레임워크의 홈페이지와 개발 문서, 공식 유튜브 채널을 가끔 다시 찾습니다. 볼 때마다 무언가 만들어 보고 싶어집니다.

그럼에도 선택은 TypeScript 풀스택이었습니다. 결정을 바꾼 것은 직접 만들 제품이 아니라, 외주 개발 고객의 기술 스택을 정하던 과정이었습니다.

참고

I built 10 web apps... with 10 different languages - Fireship

1인 개발 준비하기 1 - 웹 개발 전환

Thu, 15 Jan 2026 00:00:00 GMT

iOS 개발자로 15년을 일했습니다. 회사 조직 개편으로 퇴사한 뒤, 다시 취업하는 대신 1인 개발자가 되기로 했습니다. 결정 자체는 오래 걸리지 않았습니다. 정작 고민이 길었던 쪽은 무엇부터 준비할 것인가였습니다.

평소 생각해 둔 아이디어가 몇 개 있고 지금 상태로도 앱 개발을 시작할 수는 있습니다. 백엔드가 필요하면 슈파베이스 같은 서버리스를 붙이면 됩니다. 앱 하나를 출시하는 데까지는 지금 가진 기술만으로 충분합니다.

하지만 문제는 그다음입니다. 요즘의 앱 서비스는 스탠드얼론 앱이 아닌 이상 앱 하나로 끝나지 않습니다. 마케팅을 위한 랜딩 페이지가 필요하고, 운영을 위한 어드민이 필요합니다. 외부 서비스 연동이 늘어날수록 직접 다뤄야 할 백엔드도 늘어납니다. 결국 프론트엔드와 백엔드를 포함한 웹 개발 전반을 알아야 기술 제약 없이 다양한 서비스를 여러 번 시도할 수 있습니다.

여러 번 시도할 수 있어야 한다고 생각하게 된 것은 몇 년 전 공방 창업 경험 때문입니다. 취미 겸 사이드잡으로, 최대한 작은 규모로 시작했습니다. 그럼에도 작업실 임차료, 사이트 호스팅까지 고정 비용이 생각보다 상당했습니다.

원래 계획은 작은 매출의 사업을 조금씩 늘려가는 것이었습니다. 하지만 비개발 사업은 그 작은 시도조차 고정비가 개인에게 부담이었습니다. 하나를 굴리는 데 자금이 묶이니 두 번째 시도를 꺼낼 여지가 남지 않았습니다. 확장이 막힌 것이 아니라 시도 횟수 자체가 제한됐습니다.

1인 창업은 한 번에 큰 비용을 들이는 것보다, 가능한 한 적은 비용으로 여러 번 시도하는 편이 유리합니다. 그 조건을 가장 잘 만족시키는 것이 개발 기반 창업이었습니다. 개발로 시작해 자리를 잡은 뒤 비개발 영역으로 확장하는 순서가 맞겠다고 생각한 계기이기도 합니다.

물론 1인 개발 창업에도 비용은 존재합니다. 지금 상태로 진행한다면 경로는 대체로 이렇습니다.

iOS 앱을 먼저 출시합니다. 반응이 오면 안드로이드를 추가 개발하거나 크로스 플랫폼으로 전환합니다. 서비스 형태를 갖추려면 마케팅 사이트와 어드민 같은 백오피스가 붙습니다. 더 성장하면 슈파베이스에서 AWS나 애저 같은 인프라로 이전하고, 그에 맞는 백엔드를 새로 개발합니다.

1인 개발 창업이 상대적으로 비용이 적게 드는 것은 사실입니다. 다만 위 단계들은 제품이 정상적으로 성장한다면 언젠가 반드시 필요해지는 것들이고, 그동안의 업무 경험으로 어렵지 않게 예상됩니다. 각 단계마다 플랫폼, 언어, 프레임워크 학습과 개발 비용이 상당량 추가됩니다. 시작하기도 전에 이 비용이 부담으로 다가왔습니다.

그래서 1인 개발은 결국 모든 것을 혼자 만들 수 있는 풀스택 웹 개발자가 되어야 한다고 판단했습니다. 모바일 퍼스트 전략을 택하더라도 제품 초기에는 웹뷰를 감싸는 하이브리드 방식으로 처리하고 가는 편이 전체 개발 비용을 낮추고 시도 기회를 늘리는 길입니다.

무엇보다 오래전부터 만들고 싶었던 제품은 자유롭게 개발하고 배포할 수 있는 웹 서비스였습니다. 오랫동안 앱을 만들다 보니 플랫폼에 독립적인 제품에 대한 갈망이 컸던 것 같습니다.

이런 이유로 1인 개발 창업을 준비하며, 먼저 풀스택 웹 개발자가 되기로 했습니다.