저는 5일 동안 실제 사용자처럼 무료 플랜을 사용해봤습니다. 가격 페이지에 적힌 대로가 아니라요. 그리고 진행하면서 일어난 일을 그대로 기록했습니다. 스크린샷만 찍고 넘어가는 방식으로는 세부 조항을 발견할 수 없습니다. 일주일 동안 실제로 뭔가를 만들면서 어떤 벽에 부딪히는지 확인하는 것만이 답입니다. 그 기록을 공유합니다.
월요일 오전 9시 40분 — 카드 없이 가입
코드를 한 줄도 쓰기 전에 가장 먼저 확인한 것: 카드 정보를 요구하는지 여부였습니다. 요구하지 않더군요. 평소라면 이런 디테일은 그냥 넘어갈 텐데, 아무것도 만들기 전에 결제 정보부터 요구하는 무료 플랜은 사용자를 어떻게 생각하는지를 보여주는 신호라서, 기록해두고 본격적으로 빌드를 시작했습니다.
테스트 프로젝트로 소규모 비즈니스 사이트를 골랐습니다 — 특별할 것 없이 랜딩 페이지, 문의 폼, 블로그 섹션 정도였습니다. 10시 15분에는 무료 서브도메인에 첫 버전이 배포되어 있었습니다. "빌드"와 "게시" 사이에 결제 장벽이 없었는데, 많은 무료 플랜이 여기서 슬그머니 데모 수준으로 그치곤 합니다.
월요일 오후 2시 — 반복 수정 루프, 벽에 부딪힐 거라 예상한 지점
가장 의심스러웠던 부분이 바로 이 지점입니다. 첫 번째 빌드는 어떤 에이전트에게든 쉽습니다 — 깔끔한 요구사항, 조율할 기존 코드도 없으니까요. 그래서 플랫폼이 첫 빌드에서는 무료 플랜을 후하게 보이게 하고 두 번째 빌드부터 서서히 비용을 뽑아낼 수 있습니다. 저는 이 루프를 집중적으로 테스트했습니다: "헤더를 고정시켜줘", "모바일 내비게이션 고쳐줘", 콘텐츠 수정 한 번, 그 뒤로 작은 수정 두 번. 실제 수정이 늘 그렇듯, 각 요청이 처음 요청한 것보다 더 많은 파일을 건드렸습니다. 그날 한도에 도달하지는 않았지만, 한도가 어디쯤 있는지는 느낄 수 있었습니다 — 할당량은 명백히 이런 완전한 한 사이클 정도에 맞춰져 있지, 다섯 번을 감당할 수준은 아니었습니다.
오후 중반에는 무료 계정에서 컴퓨팅 비용을 아끼려고 리뷰 단계를 건너뛰는지도 확인했습니다. 건너뛰지 않더군요 — 완료 표시가 되기 전에 동일한 린팅, 동일한 보안 검사, 동일한 기능 검증이 이루어졌습니다. 이 부분을 특히 파고든 이유는, 제가 이 사업을 운영한다면 마진 압박이 있을 때 가장 먼저 잘라낼 부분이기 때문인데, 실제로는 잘려나가지 않았습니다.
화요일 오전 11시 — 백엔드 한도를 확인하기 위해 두 번째 프로젝트를 진행
실제 백엔드가 필요한 두 번째 아이디어를 시작했습니다 — 데이터베이스, API 라우트까지 전부요. 여기서 진짜 제한을 예상했고, 실제로 발견했습니다: 무료 계정당 실행 중인 서버 기반 앱은 하나뿐이라는 것이었습니다. 첫 번째 앱과 함께 두 번째 호스팅 백엔드를 띄우려 했지만, 두 개를 동시에 실행할 수는 없었습니다.
놀라웠던 건 오히려 해당되지 않는 것들이었다. 그 주 후반에 작은 다운로드형 도구를 만들었는데 — 서버 없이 그냥 패키징된 앱이었다 — 문제없이 게시됐고, 라이브 백엔드와 경쟁하지도 않았다. 비용 구조를 생각해보면 당연한 일이다. 호스팅되는 백엔드는 아무도 접속하지 않아도 계속 켜져 있고 비용이 발생하지만, 정적이거나 설치형 빌드는 그냥 파일이 놓여 있을 뿐이다. 리소스가 제한되는 건 오직 상시 가동되는 쪽뿐이다.
화요일 오후 4시 30분 — 동시성을 깨보려 한 시도
빌드를 시작해 놓고, 진행 도중에 어시스턴트에게 전혀 관련 없는 작업을 시작해달라고 요청했다. 병렬로 실행되는 대신 대기열에 들어갔다. 90초 정도는 짜증났지만 그 후엔 상관없어졌다 — 어차피 첫 빌드의 미리보기를 보고 있었으니, "다음 작업을 시작하기 전에 끝날 때까지 기다리는 것"은 어차피 내가 했을 행동이었다. 콘텐츠 생성 에이전트와 빌드 재구성 에이전트를 동시에 두 파이프라인으로 돌리는 팀이라면 이게 더 크게 문제될 것 같지만, 그건 내 사용 패턴과는 다른 얘기다.
수요일 — 라이브러리 기능, 그리고 그것이 체험판용 기능이 아닌 이유
수요일에는 축적 기능 — 지식 베이스, 참조 이미지, 템플릿 — 이 무료 플랜에서도 실제로 작동하는지, 아니면 유료 전용 맛보기인지 테스트하는 데 시간을 썼다. 제한이 걸려 있지 않았다. 3일째가 되자 플랫폼은 내가 다시 설명하지 않아도 내 브랜드 톤과 참조 스크린샷을 재사용하고 있었는데, 이것이야말로 지식 레이어의 핵심이다. 이걸 잠가버리면 무료 사용자는 제품이 점점 쌓여가는 경험을 절대 볼 수 없고, 그러면 애초에 유료로 전환할 이유도 없어진다.
테넌트 데이터 격리가 무료 플랜에서 어떤 식으로든 "약화"되어 있는지도 살펴봤다 — 부분적 격리, 격리 검사 대기열이 더 느리다든지 하는 것들. 그렇지 않았고, 사실 구조적으로 그럴 수가 없다. 격리는 이분법적인 문제다. 백그라운드 작업과 쿼리가 테넌트별로 완전히 분리되어 있거나 아니거나, 둘 중 하나이지 80%만 격리해서 저렴하게 파는 버전이란 게 존재할 수 없다. 무료와 유료 모두 동일한 보장을 받는데, 이건 짐작은 했지만 그냥 믿기보다 실제로 확인하고 싶었다.
목요일 — 스토어 게시, 거의 시도하지 않을 뻔한 항목
앱 스토어에 배포하는 건 당연히 유료 전용일 거라고 지레짐작해서 이 테스트를 거의 건너뛸 뻔했다 — 많은 사람들이 이렇게 생각하지만, 틀렸다. 화요일에 만든 작은 도구를 설치형으로 패키징했더니 플랫폼 측 게시 과정은 유료 계정에서 기대할 만한 것과 동일하게 작동했다. 유일한 걸림돌은 내가 사용 중인 플랜과는 무관한, 구글 자체의 개발자 등록비였다. 존재하지도 않는 한계를 스스로 상상해서 지레 포기하는 사람들을 봐왔기에 이 점은 분명히 짚어둘 가치가 있다.
금요일 — 다음번엔 건너뛸 것들
이 테스트를 다시 한다면 화요일 오후의 동시성 실험은 건너뛸 것 같다 — 2분도 안 돼서 답이 나왔는데 이후 40분을 들여 이런저런 변형을 시도했지만 결과는 똑같았다. 테넌트 격리 확인도 3일째가 아니라 첫날로 앞당길 것이다. 사람들이 플랫폼에 실제 서비스를 올리기 전에, 나중이 아니라 미리 알아야 할 사실이니까.
건너뛰지 않을 것: 월요일의 반복 작업 루프 테스트. 무료 플랜이 사실은 미끼 상품에 불과하다는 게 드러나는 지점은 대개 거기이며, 이게 진짜 제품인지 아니면 마케팅만 그럴싸한 체험판인지 판단하려면 직접 시간을 들여 재현해볼 가치가 있는 부분이다.
| 테스트한 내용 | 실제로 벌어진 일 |
|---|---|
| 가입 | 카드 등록 불필요 |
| 반복 작업 루프 (수정 5회 이상) | 한 사이클 내내 사용량 여유가 유지됨; 더 무겁게 쓰면 빠듯해질 수 있음 |
| 검토/검증 단계 | 유료와 동일 — 생략되지 않음 |
| 두 번째 라이브 백엔드 | 차단됨 — 서버 기반 앱은 한 번에 하나만 가능 |
| 정적/설치형 빌드 | 백엔드 슬롯과 경쟁하지 않음 |
| 병렬 빌드 | 동시 실행이 아니라 대기열에 순서대로 처리됨 |
| 라이브러리(지식/참조/템플릿) | 완전히 사용 가능하며, 한 주 동안 계속 누적됨 |
| 테넌트 격리 | 유료와 동일한 보장, 부분 버전은 존재하지 않음 |
| 스토어 게시 | 제한 없음; 유일한 걸림돌은 스토어 자체 수수료 |
정리하자면: 실제로 내가 부딪힌 문제와 예상했지만 실제로는 부딪히지 않은 문제를 기준으로, 업그레이드할 정당한 이유는 세 가지다. 처음 한 달에 누구나 한 번쯤 겪는 정도가 아니라 반복 작업 루프를 여러 번 소진해본 경우 — 소진 시 실제로 어떤 일이 벌어지는지 참고하자. 아무것도 사라지지 않지만, 반복되는 패턴이라면 신호로 볼 만하다. 호스팅 백엔드 두 개를 동시에 운영해야 한다면, 이건 예산으로 해결할 수 있는 문제가 아니라 무료 플랜이 애초에 지원하도록 설계되지 않은 구조적 필요다. 아니면 만들었던 것이 테스트를 넘어서 실제로 수익을 내기 시작했다면, 그때는 한계에 근접해서 운영하는 것이 기술적 비용이 아니라 심리적 부담이 된다.
이번 주에는 이 중 어느 것도 나에게 해당되지 않았다. 실제 사이트 하나와 실제 다운로드형 도구 하나를 만들었고, 둘 다 반복 작업을 거쳐 둘 다 게시했으며, 유일하게 마주친 한계는 정확히 약관에 명시되어 있던 그 지점이었다.
