연 5,800만 원짜리 SaaS 견적을 받고, 돈을 내는 대신 AI로 베끼게 한 주최자가 있습니다.
AI 개발자 콘퍼런스 AI 엔지니어와 뉴스레터·팟캐스트 Latent Space를 운영하는 스와이(swyx)입니다. 행사 4개를 운영할 소프트웨어 견적이 연 4만 3천 달러, 우리 돈 약 5,800만 원이었어요. 그의 말로는 그 업체 기능의 3분의 1 정도만 쓰는데, 안 쓰는 부분을 깎아 주지는 않았다고 해요. 그래서 상금 1만 달러를 걸고 "AI로 복제해 보라"는 공모 킬 마이 사스(Kill My SaaS)를 열었습니다. 10월 13일 공개된 실험 보고와 결선 3명 인터뷰를 조쉬의 뉴스레터에서 정리했고, 그중 직접 만들지 계속 살지 고민하는 사람에게 필요한 대목만 추렸어요.
작품 72개가 들어왔습니다. 72는 사람 수가 아니라 제출 기록 수이고, 행사팀은 그중 69건을 심사했어요. 최종 판단은 스와이가 아니라 개발자가 아닌 실제 행사팀이 맡았습니다. 어떤 에이전트나 모델을 썼는지는 신경 쓰지 않고, 실제로 사서 쓸 만한지만 봤다고 해요.
결선 3개와 강함 2개, 합쳐서 5개가 도입이나 구매를 진지하게 고려할 기준을 넘었습니다. 앱 전체를 쓰진 않더라도 아이디어는 가져오고 싶은 프로젝트가 12개 더 있었고요.
행사팀 심사를 받은 69건의 분류. 결선 3과 강함 2를 합친 5건이 도입 검토 대상이다. 이미지 출처 : 원영상과 Latent Space 보고서를 바탕으로 조쉬의 뉴스레터 재구성
스와이에 따르면 참가자들이 계속 걸려 넘어진 곳은 대략 세 군데였습니다. 첫째는 연사·초청 연사·후원사마다 따로 들어가는 화면이에요. 사람마다 낼 것과 볼 것이 다른데, 대부분은 누구에게나 같은 화면 하나만 만들었습니다. 둘째는 끌어다 놓는 일정표, 셋째는 신청서를 거치지 않고 초청 연사를 바로 넣는 기능이었어요.
행사 운영이 까다로운 이유도 여기 있습니다. 한 사람이 연사이면서 후원사이고 참가자일 수 있거든요. 스와이는 세 가지 모두 자기네 설명서에도, 원래 쓰던 소프트웨어 설명서에도 제대로 적혀 있지 않았고 직접 써 봐야 바로 드러난다고 했습니다.
한 사람이 여러 역할로 거치는 행사 운영 흐름과 초청 연사의 예외 경로. 이미지 출처 : 원영상과 Latent Space 보고서를 바탕으로 조쉬의 뉴스레터 재구성
Latent Space 보고서가 심사 메모 69건을 손으로 분류해 보니 사람마다 따로 들어가는 화면 문제를 짚은 메모가 36건, 일정표 문제가 18건, 신청서·설정이 좁다는 지적이 15건이었어요.
69건 심사 메모에서 반복된 지적. 한 메모가 여러 문제를 짚기도 해 더한 값이 아니다. 이미지 출처 : Latent Space
스와이의 정리로는 결선 3명 모두 코드를 쓰기 전에 한 일이 아주 많았습니다. "프롬프트는 거의 마지막 단계였고, 일의 대부분은 이 소프트웨어가 실제로 무슨 일을 하는지 알아내는 것이었다"고 해요.
2위 야진은 과제 설명을 AI가 읽기 쉬운 문서로 바꾸고, 원래 소프트웨어의 도움말 사이트 전체와 비슷한 사이트 몇 곳을 통째로 긁어 기능 목록을 만들었습니다. 3위 마르코 팀은 스크린샷 42장을 에이전트 5개에 나눠 화면별 명세로 옮겼고, 공개 API 문서를 기능별로 정리하며 "API 문서가 기능 목록 역할도 한다"고 적었어요. 우승자 발렌틴은 Codex에게 "이 앱의 모든 기능의 모든 흐름을 그려 달라"고 하는 데서 시작했고, AI가 소개 영상을 한 장면씩 캡처해 기능별 설명서를 만들었습니다.
결선 3명이 코드를 쓰기 전에 모으고 정리한 자료. 이미지 출처 : 원영상과 Latent Space 보고서, 참가자 저장소를 바탕으로 조쉬의 뉴스레터 재구성
어떤 AI를 썼는지는 비결이 아니었습니다. 스와이는 Claude Code와 Codex가 사실상 동률이었다고 했어요. 대신 많은 참가자가 모델마다 역할을 나눴습니다. 한 모델이 만들고 다른 모델이 검사하게 하거나, 어떤 AI도 자기 작업을 스스로 통과시키지 못하게 하는 식이었죠.
결선 3명이 모두 한 화려하지 않은 일도 있었습니다. 자기 제품을 실제 사용자처럼 쓰고 또 쓴 거예요. 발렌틴은 행사팀 입장이 돼서 '시험할 시간이 5분뿐이라면?' 하고 써 봤다고 합니다. 그 5분이 매끄럽지 않으면 제품 맥락이든 기대 동작이든 뭔가 빠진 것으로 봤어요.
그는 막힌 화면을 손으로 고치지 않았습니다. 처음 쓰는 사람을 안내하는 화면이 어색하자 AI에게 작업 기록을 뒤져 원인을 찾게 했고, 설명서에 '온보딩'이라는 제목만 있고 좋은 안내가 뭔지는 아무 정보가 없었다는 걸 알아냈어요. 그래서 좋은 안내와 나쁜 안내를 조사하는 단계를 넣어 처음부터 다시 돌렸습니다.
막힌 곳을 손으로 고치지 않고 빠진 조사 단계를 과정에 넣어 다시 돌린 발렌틴의 방식. 이미지 출처 : 원영상을 바탕으로 조쉬의 뉴스레터 재구성
스와이는 "그럴듯하게 돌아가는 복제는 정말 쉬운 부분"이라고 했습니다. 누군가는 그걸 계속 돌리고, 버그 신고를 받고, 새벽 2시에 고쳐야 한다는 거예요.
운영 책임자 켈시의 이야기도 같은 방향입니다. 후원사가 알려 온 버그를 업체 지원팀에 물었더니, 지원팀과 엔지니어를 돌고 돌아 "캐시를 새로 고쳐 보시겠어요?"라는 답이 왔다고 해요. 그가 바란 건 새 기능이 아니라 고장 나면 바로 고칠 사람이었습니다. "어떻게 고치든 상관없어요. 안 망가지기만 하면 돼요."
끊기 전에 실제로 쓰는 기능과 변경 요청을 기다리는 시간부터 세어 본다
화면 목록 말고 한 사람이 처음부터 끝까지 거치는 길을 적는다
프롬프트 전에 도움말과 API 문서부터 모은다
만드는 AI와 검사하는 AI를 나눈다
딱 5분 직접 써 보고, 막히면 빠진 정보부터 찾는다
버그를 누가 받고 언제 고칠지 답할 수 없다면 아직은 사는 쪽이 낫다
전체 글은 뉴스레터에서 볼 수 있어요. AI 심사와 사람 판단이 얼마나 갈렸는지, 결선작 저장소에 남은 검증 방식, 복제 비용에 대한 스와이의 어림값까지 담았습니다.
https://maily.so/josh/posts/wdr98v77olx
조쉬의 뉴스레터는 AI와 함께 일하는 창업가·빌더의 이야기를 매주 보내 드려요.
