행사 4개에 연 4만 3천 달러(약 5,800만 원). 한 AI 개발자 콘퍼런스가 행사 운영 SaaS에서 받은 견적이에요. 주최 측은 이 돈을 내는 대신 상금 1만 달러를 걸고 "AI로 복제해 보라"는 공모를 열었습니다. 돈 내고 쓰는 SaaS, 직접 만들까요, 계속 살까요?
작품 72개가 들어왔지만 실제 운영팀이 써 보고 도입할 만하다고 본 건 5개였어요. 공모를 연 사람은 AI 엔지니어 대상 뉴스레터·팟캐스트 Latent Space와 콘퍼런스 AI 엔지니어(AI Engineer)를 운영하는 스와이(swyx)예요. 겉보기엔 대부분 그럴듯했지만, 실제 사람처럼 써 보면 막히는 곳이 있었죠. 이번 글에서는 10월 13일 공개된 스와이의 실험 보고와 결선 3명의 인터뷰를 주제별 문답으로 옮겨, 복제를 잘한 사람들이 프롬프트보다 먼저 준비한 것을 살펴봅니다.
연 4.3만 달러 견적 앞에서 "올해는 생각을 바꿨다"
Q. 연 4.3만 달러 견적이 왜 문제였나요?
스와이 | 연사 관리용으로 세션보드(Sessionboard) 같은 행사 소프트웨어를 알아보고 있었는데, 이번에 필요했던 그 소프트웨어는 행사 4개 기준으로 연 4만 3천 달러 견적이 나왔어요. 그런데 저희는 그 업체가 파는 것의 3분의 1 정도만 써요. 안 쓰는 부분을 깎아 주지는 않고요.
기성 소프트웨어에 변경 요청을 넣으면 3개월에서 6개월, 아니면 영영 안 나오는 경우가 많아요. 행사를 일곱 번 치르며 이 분야 소프트웨어가 얼마나 별로인지 잘 알게 됐죠.
그래도 몇 년 동안 회사 설립 계약서에 '제 명시적 승인 없이는 누구도 사내 소프트웨어를 만들 수 없다'는 조항을 넣어 뒀어요. 그냥 사면 되는 범용 소프트웨어를 직접 만드느라 한눈팔기 쉽거든요.
그런데 올해 생각을 바꿨어요.
이제 에이전트가 저희만의 맞춤 소프트웨어를 가질 수 있을 만큼 좋아졌다고 봤고, 실제 제 돈을 걸고 시험해 보기로 했습니다.
Q. 그래서 사지 않고 공모를 열었군요. 무엇을 시험하고 싶었나요?
거의 즉흥적으로 '킬 마이 사스(Kill My SaaS)'라는 공모를 열었어요. 누구나 참가할 수 있고, 저는 이 소프트웨어의 명세와 해야 할 일을 줍니다. 가장 얻기 어려운 건 구현 방식엔 관심 없고 일이 되기만 바라는 실제 구매자의 평가예요.
저희 행사팀이 바로 그런 사람들이에요. 기술직이 아니라서 어떤 에이전트나 모델을 썼는지 신경 쓰지 않아요. 실제로 사서 쓸 만한지만 봅니다.
참가자들은 제가 쓴 브리프, 실제 제품 둘러보기 영상, 브리프에 넣은 스크린샷 42장을 받았어요. 우승 상금은 1만 달러였고, 진지하게 도전한 사람에게는 토큰(AI 사용량을 세는 단위) 비용을 최대 500달러까지 보전해 줬어요. 최종 판단은 제가 아니라 실제 행사팀이 했습니다.
Q. 행사 운영 소프트웨어가 왜 생각보다 어려운가요?
이건 전형적인 '중간급 업무 소프트웨어'예요. 세일즈포스도 아니고, 하루 만에 바이브 코딩(코드를 읽지 않고 AI에게 말로 시켜 만드는 방식)으로 만드는 물건도 아니죠. 그 중간에 평범한 사람들이 매일 쓰는 형편없는 소프트웨어가 수십억 달러어치 있어요.
연사가 발표를 제출하면 심사와 채택을 거쳐, 프로필 사진과 슬라이드를 올릴 연사 포털이 필요해요. 일정표의 방에 배치하고, 제목이 바뀌면 공개 일정에 반영돼야 하죠. 이걸 초청 연사, 후원사, 참가자에게 다시 다 해야 합니다.
게다가 한 사람이 동시에 역할을 두세 개 가질 수 있어요. 연사이면서 후원사이고 참가자일 수도 있죠. 그때그때 역할을 새로 만들기도 해요.
행사하는 사람들이 위험을 싫어하는 데는 이유가 있어요. 소프트웨어 때문에 마감을 일주일 넘기면 사람들이 엉뚱한 장소에 오거나 행사가 아예 안 열립니다. 저희도 다 겪어 봤어요.
작품 대부분이 걸려 넘어진 세 가지
Q. 제출작 대부분이 공통으로 놓친 건 무엇이었나요?
스와이 | 참가자들이 계속 걸려 넘어진 건 대략 세 가지였어요. 첫째는 포털이에요. 연사, 초청 연사, 후원사가 각자 자기 포털이 필요한데, 대부분은 별로 유연하지 않은 포털 한 종류만 만들었어요.
켈시(AI 엔지니어 운영 책임자) | 야진 님의 컨퍼런서는 폼과 포털의 차이를 제대로 가려낸 몇 안 되는 작품이라 좋았어요. 다만 가장 아쉬웠던 것 중 하나는, 저희는 포털이 여러 개라는 점이에요. 발표 공모(CFP) 포털, 후원사 포털, 초청 연사 포털이 따로 있죠.
관리자가 그 여러 포털을 각각 다르게 설정할 수 있어야 해요. 세션보드에도 있는 기능인데, 이 작품에서는 보지 못한 몇 안 되는 것 중 하나였어요.
스와이 | 둘째는 끌어다 놓기(drag and drop)예요. 모델이 구현하기 어려운 복잡한 UI죠. 세션을 끌어다 놓으면 실제로 옮겨지는지, 확정됐는지 알아볼 수 있는지를 봤어요. 한 사람이 두 세션에 들어가거나 같은 시간 같은 방이 겹치면 안 되니까요.
켈시 | 어떤 작품은 도움말 말풍선이 '여기를 눌러 세션을 만드세요'라고 알려 주는데, 그냥 그 자리에서 버튼을 눌러 세션을 추가할 수 있어야죠. 제 기준 중 하나가 일정표를 끌어다 놓을 수 있느냐였어요. 그걸 보면 지시를 제대로 따랐는지 알 수 있었거든요.
스와이 | 셋째는 발표 공모 신청서를 거치는 척하지 않고 세션을 바로 추가하는 기능이었어요. 초청 연사나 VIP에게는 꼭 필요하죠. 세 가지 모두 저희 문서에도, 세션보드에도 제대로 적혀 있지 않았어요. 실제 사람처럼 써 봐야 바로 드러나는 것들이에요.
Q. 기능은 많이 만들었는데 왜 하나의 앱으로는 엉성했나요?
스와이 | 자기 앱을 직접 써 보지 않고 제출했기 때문이에요.
기능 하나하나는 따로 만들 수 있어요. 그런데 결국 하나의 앱으로 엮어야 하고, 많은 사람이 거기서 넘어졌어요. 토큰은 많이 쓰면서, 서로 연결되지 않은 기능을 중복으로 만들었죠.
Latent Space가 10월 11일 낸 보고서는 제출 기록 72건 중 행사팀이 심사한 69건의 메모를 손으로 분류했는데, 한 메모가 여러 문제를 함께 짚기도 했어요. 메모 원문은 짧고 직접적이에요. "CFP 없이는 세션을 못 만든다." "시간 칸이 안 보여서 어디로 끌어다 놓는지 모르겠다." "포털'들'이라더니 하나만 보인다."
폼이 누구에게나 같은 신청서를 내미는 접수 창구라면, 포털은 찾아온 사람이 누구인지 알고 그 사람이 낼 것과 진행 상태를 보여 주는 전용 창구에 가까워요. 보고서는 이렇게 정리했어요. "폼은 정보를 모을 수 있다. 하지만 운영 제품은 그 사람이 누구인지, 어떻게 들어왔는지, 무엇을 내야 하는지, 상태가 바뀌면 무엇이 달라지는지 알아야 한다."
AI 심사는 출발점, 판정은 사람이
Q. AI 심사위원도 있었다던데, 사람의 판단과 얼마나 맞았나요?
스와이 | 사람 심사와는 잘 맞지 않았어요. AI 상위 10개 중 6개를 저희 행사팀은 '약함'으로 봤고, 최종 우승작은 AI 순위 19위였거든요.
일부러 그런 면도 있어요. 명세를 기계적으로 베끼기보다 좋은 사용자 경험을 스스로 정의해 보라고, 명세에서 벗어나는 걸 허용했거든요. 저희가 찾은 건 코딩 에이전트를 다루는 취향이에요.
대회 중에 공개한 AI 심사는 애초에 우승자를 고르려던 게 아니라, 앱을 제대로 돌아가게 만들도록 돕는 점검용이었어요. Claude가 역할별로 로그인해 평범한 사용 흐름으로 쓴 시나리오 20개를 클릭하고, 다시 Claude가 채점했죠.
AI 심사를 돌린 앱은 56개였고, 그중 40개가 순위를 매길 만큼 결과가 나왔어요. 상위 7개가 2.3점 안에 몰려 사실상 포화 상태였죠. 자동 평가로 점수를 올리는 건 초기 단계로는 아주 유용해요.
이런 대회를 연다면 꼭 권하고 싶어요. 앱 전체를 직접 클릭하는 모습을 녹화하고, 그걸 시나리오로 만들어 공개하세요. 그러면 참가자들이 그 시나리오로 점수를 올려 갈 수 있어요. 반응도 꽤 좋았어요.
참가자 오픈세시(Opensesh)는 가장 공들인 부분 대부분이 AI 심사 범위 밖이었다고 했는데, 맞는 말이었어요. 사람이 모든 앱을 클릭해 봤기에 알 수 있었죠.
트랙스테이지(3위)의 작업 회고에 따르면, 이 팀은 주최 측이 대회 중 공개한 평가 키트로 자체 측정 점수를 94.4까지 올리고도 "점수보다 판정 사유를 읽는 게 더 중요했다"고 적었어요. 키트가 '확인할 수 없음'으로 넘긴 항목 3개 중 2개는 실제로 틀려 있었고, 반대로 자체 브라우저 테스트를 매번 통과한 화면에서 AI 심사가 "보이지 않는 덮개가 버튼을 가린다"고 짚은 것도 사실이었어요.
도구 이름보다 '누가 무엇을 맡았나'
Q. 그럼 이긴 AI 도구가 있었나요?
스와이 | Claude Code와 Codex(각각 Anthropic과 OpenAI의 코딩 에이전트)는 사실상 동률이었어요. 66개 중 40개는 둘 다 썼고요. 거의 모두가 상당한 결과물을 냈는데, 공개 저장소의 코드 줄 수 중앙값이 9만 1천 줄이었어요.
결선 3명 모두 GPT Sol(참가 양식에 있던 OpenAI의 GPT 모델 항목)을 골랐지만, 나머지 66개 중 50개도 골랐어요. 모델 선택 자체는 비결이 아니었어요.
제가 가장 흥미롭게 본 건 일을 나누는 방식이에요. 저는 맥락이 한곳에 모이도록 프로젝트마다 모델을 하나만 쓰거든요. 그런데 많은 참가자가 모델마다 역할을 바꿔 맡겼어요.
패턴은 세 가지였어요. 첫째, 똑똑한 모델이 무엇을 할지 정하고 더 싼 모델이 정해진 대로 코드를 쏟아 냅니다. 둘째, 한 모델이 만들고 다른 모델이 검사해요. 보통 브라우저를 다루거나 테스트를 더 잘하는 쪽이 검사를 맡죠.
셋째, 어떤 모델도 자기 작업을 스스로 승인하지 않아요. 그린룸(Greenroom HQ)은 Claude 팀과 Codex 팀을 따로 돌렸고, 상대가 검증하기 전에는 어느 쪽도 병합(각자 만든 코드를 본 코드에 합치는 일)할 수 없게 했어요. 에이전트는 남의 작업보다 자기 작업에 더 관대해요. 사람도 그렇죠.
보고서도 브라우저 테스트를 어느 모델에 맡겼는지는 팀마다 정반대였다며, "Claude Code와 Codex를 썼다"보다 각 에이전트가 무엇을 맡고 결과를 어떻게 확인했는지를 기록하라고 적었어요.
"프롬프트는 거의 마지막 단계였다"
Q. 결선 3명은 프롬프트 전에 무엇을 했나요?
스와이 | 셋 다 코드를 쓰기 전에 한 일이 아주 많았어요. 아무도 프롬프트 하나 치고 자리를 떴다고 말하지 않았죠. 프롬프트는 거의 마지막 단계였고, 일의 대부분은 이 소프트웨어가 실제로 무슨 일을 하는지 알아내는 것이었어요.
3위 마르코는 예전에 고객사 일로 앱을 복제해 본 적이 있어요. 그의 원칙은 모든 걸 먼저 계획하는 거예요.
마르코 | UX와 UI(사용 흐름과 화면 디자인)가 끝나 있으면, 저는 8~9시간 앉아서 데이터 구조와 업무 규칙을 아주 잘게, 거의 의사코드(말로 적은 코드 설계도) 수준까지 계획해요. 웃긴 건 제가 4~5년 전에 하던 그런 작업과 디자인을 지금은 LLM(챗GPT·Claude 같은 AI 모델)에 넣고 두세 시간 자리를 비우면, 픽셀까지 맞춘 결과물이 나온다는 거예요.
이번 대회에서 마르코 팀이 저장소에 남긴 작업 회고(PROCESS.md)를 보면, 스크린샷 42장은 에이전트 5개가 나눠 맡아 입력칸과 빈 화면 상태까지 화면별 명세로 옮겼어요. 세션보드의 공개 API(외부 프로그램이 기능을 불러 쓰는 창구)는 기능 주소(엔드포인트)별로 정리하며 "API 문서는 기능 전수 목록 역할도 한다"고 적었고, 에이전트 여러 개의 기억은 채팅창이 아니라 규칙·결정·작업 기록 세 문서에 두게 했어요.
마르코 | 숀(스와이)이 공유한 둘러보기 영상과 세션보드의 API 문서는 말 그대로 Claude에 넣었어요. 그리고 실시간 데이터베이스 Convex를 비롯해 제가 선호하는 개발 도구 조합을 쓰라고 했죠. 속도 같은 게 아주 중요하니까요.
Q. 2위 야진은 어디서부터 시작했나요?
야진 | 프롬프트 전 첫 단계는 조사였어요. 브리프를 마크다운(AI가 읽기 쉬운 서식 문서) 파일로 바꾸고, 웹사이트를 통째로 긁어 오는 파이어크롤(Firecrawl)로 세션보드 도움말 포털 전체와 검색에 걸린 비슷한 사이트 몇 곳을 긁었어요. 최대한 많은 정보를 모으려고 했죠.
보고서와 저장소 작업 기록(PR #6)에 따르면 야진은 그 자료로 기능 목록을 정리해 GPT Sol로 계획하고, AI 코드 편집기 커서(Cursor)에서 Claude Opus로 4시간 반 동안 구현했어요. 디자인 시스템(색·글꼴·버튼 같은 화면 규칙을 모은 문서) 첫머리엔 "이 파일에서 벗어난 페이지가 버그다"라고 적혀 있고요. 마감 전날엔 45개 화면을 '캡처 → UX 비평 → 구현 → 다시 캡처'로 훑으며 비평은 GPT Sol, 구현은 Grok(xAI의 AI 모델)에 맡겼어요.
Q. 우승한 발렌틴은 에이전트 작업을 어떻게 짰나요?
발렌틴 | 프로젝트마다 이 가드레일(에이전트가 규칙을 벗어나지 못하게 막는 장치) 작업을 매번 다시 해야 했어요. 코드 검사 규칙이며 코드 리뷰며 갖추는 데 시간을 정말 많이 썼고, 이제는 깃허브 템플릿으로 만들어 새 저장소마다 복제해 써요. 완전히 오픈소스예요.
보고서와 저장소 기록에 따르면 발렌틴은 GPT Sol이 계획하고 Grok이 구현하고 DeepSeek(중국 기업 딥시크의 AI 모델)가 반대 입장에서 흠을 찾게 했어요. 공용 파일은 '통합 담당'만 바꿀 수 있고, 작업 규칙 문서에는 '그 칸이 있다'만 확인한 검토가 기본 드롭다운에서 작동하지 않는 규칙을 세 번 통과시켰다가 시나리오를 끝까지 걸어 보고서야 잡았다고 적혀 있어요.
발렌틴 | 먼저 Codex에게 "이 앱의 모든 기능의 모든 흐름을 그려 달라"고 했어요. 자료가 유튜브 영상이라 에이전트가 영상을 프레임 단위로 캡처해 가며 파악했고, 기능마다 기대 동작을 적은 마크다운 폴더가 잔뜩 생겼어요.
그다음 그걸 동시에 할 일과 순서대로 할 일로 나누고, 단계마다 에이전트를 몇 개까지 동시에 돌릴지 계획해 전부 실행했죠.
다 끝난 뒤 직접 확인해 보니 완벽하지 않았는데, 에이전트가 앱을 자기 컴퓨터(로컬)에서 한 번도 실행하지 않았더라고요. 그래서 로컬에서 앱을 실행하는 과정을 넣어 전체를 다시 돌렸어요.
결선 3명은 자기 앱을 쓰고 또 썼다
Q. 결선 3명은 결과물이 제대로 되는지 어떻게 확인했나요?
스와이 | 결선 3명이 모두 한 화려하지 않은 일이 있어요. 자기 제품을 실제 사용자처럼 쓰고 또 썼죠. 한 명은 에이전트가 만드는 건 잘하는데 UX 문제를 알아채는 건 꽤 못한다고 적었어요.
프로필 사진 업로드 기능은 사진을 어딘가에 저장했는데, 따로 만들어진 공개 연사 페이지는 엉뚱한 곳에서 읽고 있었어요. 발렌틴의 방식은 5분 테스트였어요.
발렌틴 | 행사팀 입장이 돼서 '제품을 시험할 시간이 5분뿐이라면?' 하고 생각했어요. 그 5분이 매끄럽지 않으면 뭔가 빠진 거예요. 제품에 대한 맥락이든, 기대하는 동작에 대한 맥락이든, 아니면 에이전트가 제품의 현재 상태를 확인할 수단이 없든요.
그래도 손으로 고치는 게 목표는 아니었어요. 온보딩(처음 쓰는 사람을 안내하는 첫 과정)이 이상하면 에이전트에게 작업 기록을 뒤져 원인을 찾게 했어요. 그랬더니 명세에 '온보딩'이라는 제목만 있고, 좋은 온보딩이 뭔지는 아무 정보가 없었다는 거예요. 그래서 좋은 온보딩과 나쁜 온보딩을 조사하는 단계를 넣어 전체 흐름을 다시 돌리게 했어요.
야진 | 에이전트가 보내 준 결과를 직접 클릭해 보다가 화면 사이를 오가는 게 정말 불편하다는 걸 알았어요. 다른 화면으로 가려면 로그아웃했다가 다시 로그인해야 했죠.
그래서 로그인 정보와 포털 전환, 메일 발송 기능을 넣었어요. '이건 고쳐야지' 싶은 걸 목록으로 계속 적어 가며 클릭했죠.
켈시 | 컨퍼런서에서 손보신 부분 정말 좋았어요. 저희 콘텐츠 매니저에게 보여 줬더니 "뭐야, 이게 다 한 페이지에 있어? 상태를 보려고 양식마다 들어가 볼 필요가 없네?" 하면서 정말 놀라워했어요.
트랙스테이지의 작업 회고에는 테스트를 세 번 연속 통과해야 배포하게 했더니 세 번째 실행에서 수신자가 25명을 넘는 일괄 메일의 나머지가 멈추는 버그가 잡혔다고 적혀 있어요. 제품을 만들지 않은 새 에이전트는 실제 운영 키가 개발 서버로 갈 뻔한 문제를 찾았고요.
"작동하는 것처럼 보이는 복제는 쉬운 부분"
Q. 그럼 결국 AI가 SaaS를 죽인 건가요?
스와이 | 이제 AI로 SaaS를 완전히 없앨 수 있다는 생각에 반론을 해 볼게요. 제출작 대부분은 솔직히 첫 시도치고 괜찮은 복제였어요.
작동하는 것처럼 보이는 복제는 정말 쉬운 부분이에요.
하지만 누군가는 그걸 계속 돌려야 해요. 버그 신고를 받고, 새벽 2시에 고쳐야 하죠. 바로 어젯밤에도 행사가 진행 중인 상황에서 팀원이 공개 직전의 프로그램에 Codex 에이전트를 열두 개쯤 붙이고 있었어요.
망가뜨리면 책임져야 해요. 요즘은 반대로 말하는 사람도 많죠. 내 것이면 망가뜨려도 된다고요. 이 부분은 켈시가 저보다 더 잘 설명해요.
Q. 운영팀이 실제로 걱정한 건 무엇이었나요?
켈시 | 저희는 여러 시스템이 API로 땜질돼 연결돼 있어요. 등록 데이터가 후원사 포털로, 후원사 포털이 바로 일정표로 이어지는 하나의 시스템을 원하고, 더 잘할 수 있다는 것도 알아요.
하지만 시간이 없어요. 에이전트에게 프롬프트를 쓰고 있을 수가 없어요. 뭔가 고장 나면 바로 들어가서 고칠 사람이 필요해요.
한번은 후원사가 "티켓 배정을 취소할 수가 없다"는 버그를 알려 왔어요. 저는 업체 채팅 지원에 문의했고, 지원팀은 엔지니어에게, 엔지니어는 다시 지원팀에, 지원팀은 저에게 돌아와서 이렇게 말했어요. "캐시를 새로 고쳐 보시겠어요?"
두 단계 건너의 버그를 고치려고, 수백만 달러 규모 회사에 다니는 후원사 담당자에게 캐시를 지워 달라고는 못 해요. 어떻게 고치든 상관없어요.
안 망가지기만 하면 돼요.
5개의 합격작, 그리고 사느냐 소유하느냐
Q. 그래서 실제로 쓸 만한 앱은 몇 개였나요?
스와이 | 저희가 실제로 도입하거나 구매를 진지하게 고려할 기준을 넘은 앱은 5개였어요. 결선 3개와 2개 더요. 앱 전체를 쓰진 않더라도 아이디어는 가져오고 싶은 프로젝트도 12개 있었고요.
3위 상금 1천 달러는 트랙스테이지의 마르코 크레머예요. 일정표 끌어다 놓기가 참가작 중 가장 깔끔했고 저장소 문서도 잘 정리돼 있었어요.
2위 5천 달러는 컨퍼런서의 야진이에요. 앱 전체를 오가는 클릭 경험이 단연 최고였고, 모든 제출물을 한 페이지에 보여 줬으며 연사 단계마다 실제 메일이 나갔어요.
우승 1만 달러는 오픈로스트럼(OpenRostrum)의 발렌틴 드 마토스예요.
그는 소프트웨어 공장을 만들고, 그 공장을 디버깅했어요.
여러 포털과 저희 팀이 실제로 쓰고 싶어 한 일정표를 냈죠. 아마 2027년 AI 엔지니어 행사에서 쓰게 될 거예요. 그때 돌릴 건 오픈로스트럼과 컨퍼런서에 나머지 12개의 아이디어를 섞은 모습일 거고요.
Q. 그럼 복제에는 얼마가 드나요?
스와이 | 중간급 SaaS 하나를 복제하는 데는 구독 기준으로 토큰이 약 1,000달러, 거기에 AI 엔지니어링 전문성에 1만 달러쯤 더 든다고 봐요. 대신 그때부터 유지는 우리 책임이에요. 가벼운 거래는 아니지만, 에이전트 덕분에 우리 팀에 맞춘 소프트웨어를 유지하고 고치는 일이 12개월 전보다 훨씬 현실적이 됐어요.
참가자 쪽 비용은 셈법이 달라요. 보고서에 따르면 무거운 작업을 한 참가자들이 밝힌 사용량은 스와이처럼 정액 구독이 아니라 API 요금으로 환산하면 4,000~12,000달러였어요.
스와이 | 저희 팀은 정말 신이 났어요. 2006년이 아니라 2026년에 만든 행사 소프트웨어가 어떤 모습일 수 있는지 알게 됐고, 그걸 소유하며 실제 사용자 피드백으로 고칠 수 있으니까요.
팀에서 코드를 가장 많이 쓰는 사람은 엔지니어가 아니라 디자이너, 도메인 전문가, 운영 담당이에요.
진짜 목적은 아낀 돈으로 그동안 못 하던 개선을 하는 거예요. 참가자와 후원사, 연사가 즐겁게 쓰는 소프트웨어를 만드는 데 토큰을 쓰고 싶어요.
1인 창업자를 위한 체크리스트
스와이의 실험을 바탕으로 편집자가 정리한 점검 목록이에요.
1. 끊기 전에 실제로 쓰는 기능부터 세어 보세요. 스와이는 그 업체가 파는 것의 3분의 1 정도만 쓴다고 했고, 기성 소프트웨어는 변경 요청에 3개월에서 6개월, 아니면 영영 답이 없다고 했어요. 쓰는 범위와 기다리는 시간이 복제를 따져 볼 출발점이에요.
2. 화면 목록 말고 한 사람의 여정을 적으세요. 제출작 대부분이 놓친 역할별 포털, 일정 끌어다 놓기, 신청서 없는 초청 연사 추가는 모두 문서에 제대로 적혀 있지 않았고, 실제 사람처럼 써 봐야 드러나는 것이었어요. 역할이 겹치는 사람과 예외로 들어오는 사람을 따로 적어 두세요.
3. 프롬프트 전에 도움말과 API 문서부터 모으세요. 야진은 도움말 포털 전체를 긁었고, 마르코는 API 문서를 기능 전수 목록으로 썼어요. 발렌틴의 에이전트는 영상을 프레임 단위로 캡처해 기능별 기대 동작을 적었어요.
4. 만드는 AI와 검사하는 AI를 나누세요. 만들지 않은 에이전트의 검토가 실제 운영 키가 개발 서버로 갈 뻔한 문제를 찾았어요. 어떤 모델도 자기 작업을 스스로 승인하지 않게 해 두세요.
5. 5분 동안 직접 써 보세요. 막히는 곳이 나오면 화면을 손으로 고치기 전에, 발렌틴처럼 어떤 맥락이 빠졌는지 찾아 과정에 넣으세요. 자동 점수를 받았다면 점수보다 판정 사유를 읽으세요. 직접 클릭한 흐름을 녹화해 시나리오로 적어 두면, 스와이처럼 자동 점검도 그 시나리오로 돌릴 수 있어요.
6. 유지할 사람을 먼저 정하세요. 켈시가 바란 건 새 기능이 아니라 고장 나면 바로 고칠 사람이었어요. 버그를 누가 받고 언제 고칠지 답할 수 없다면, 그 SaaS는 아직 사는 쪽이 낫습니다.
연 4.3만 달러 견적에서 시작한 실험은 켈시의 한마디로 돌아와요. "어떻게 고치든 상관없어요. 안 망가지기만 하면 돼요." 행사팀은 처음부터 어떤 에이전트를 썼는지가 아니라 실제로 쓸 만한지만 봤죠.
그렇게 드러난 건 AI가 SaaS를 통째로 없앤다는 게 아니라, 그럴듯하게 베끼는 건 쉬워졌고 소유하고 고치는 게 진짜 일이 됐다는 것입니다. 돈 내고 쓰는 SaaS가 있다면, 오늘은 그 제품으로 하는 일 하나를 처음부터 끝까지 적어 보세요. 그 목록이 직접 만들지 계속 살지를 정하는 첫 자료가 될 거예요.
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 14기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
의견을 남겨주세요