이슈를 발견하고 올라타는 것에 매우 능숙한 Marc Lou (마크 루). 지난주 인스타툰에서 다룬 TrustMRR의 성공은 이런 Hype Jacking이 전략의 거의 전부라고 할 수 있는데요.
* Hype Jacking : 급상승 트렌드나 키워드에 올라타는 전략
아무리 그래도 테스트도 해봐야 하고, 눈에 보이지 않는 할 일이 진짜 얼마나 많은데,
하루 만에 만드는 게 말이 됨?
AI로 딸깍한다 해도 24시간 안에 만들 수 있는 건 한계가 있고, 보이지 않는 시스템 구멍들도 있을 거 같고 오만가지 걱정이 먼저 드는데, 이런 저의 사고방식에서 벗어나고자 그냥 마크 슨배님이 어떻게 그렇게 빠르게 작업하시는지 한번 배워보는 시간을 가져보았습니다.
어디 한번 나도 Hype Jacking인지 뭔지 해보자! 🔥
2025년 3월 10일 Marc Lou의 유튜브 채널에 업로드된 영상 How I use AI to build startups 10X FASTER을 기준으로 마크의 워크플로를 살펴보았어요. TrustMRR은 2025년 10월 31일에 출시되었는데 6개월 사이에 개발 방법이 뭐 대단히 바뀌진 않았겠죠?
오, 근데 썸네일 보니까 AI Agents가 비법인가?
마크가 말아주는 AI로 10배 빠른 개발 방법
마크가 작성하는 코드의 80%는 AI가 한다고 하고, 이런 식으로 한 30개 정도 출시했다고 하더라고요.
✅ 코드 에디터는 Cursor
✅ 언어 모델은 Claude Sonnet 3.5
코드 작성은 오직 Cursor 하나만 사용하는데, 그냥 모든 걸 심플하게 유지하는 것이 마크 같은 인디 해커들의 특징 같아요. 영상에서는 1년 전이라 Claude 3.5 Sonnet을 쓴다고 했는데, 그냥 매번 최신 버전으로 바꿔서 쓸 것 같고요.
일단, Cursor Settings 메뉴에서 Rules for AI를 작성하라고 하더라고요.
✅ Cursor > Setting > Cursor Settings > Rules, Skills, Subagents
![[ Cursor > Setting > Cursor Settings ] 에서 Rules 입력](https://cdn.maily.so/du/twojob/202604/1777271804627043.png)
✅ Rules for AI에 복붙
아래 내용은 "코드 이렇게 써달라는 규칙, UI는 DaisyUI랑 Tailwind CSS 사용해라" 등등 본인 코딩 취향을 알려주는 (어찌 보면 당연한) 말들이 쓰여 있네요. 요즘은 Rules에 이렇게 스택 선언이나 세세한 문법 규칙 일일이 안 쓴다고 하더라고요. 마크는 같은 스택으로 거의 모든 프로젝트를 만들어서 아예 세팅해 놓고 쓰는 건가 싶은데 (사실 모름)..
근데 첫 문장 자세히 보니까, ShipFast라는 단어가 나오는데, 마크가 만든 199~299달러짜리 Next.js Boilerplate이라는 것 같더라고요. 1인 SaaS에서 많이 쓰는 코드 모음집 같은 건가 봐요.
결국 이게 시간 단축을 도와준 것일까요? 일단 후보 ☝️.
* Boilerplate : 매번 반복되는 기본 코드를 미리 모아놓은 템플릿

뭐야, AI Agent 전혀 안 쓰는데?
영상의 나머지 내용은 마크가 Cursor AI를 어떻게 사용하는지 설명하는데요.
✅ inline은 CSS 수정이나 SVG를 React 형식에 맞게 바꾸는 등의 부분 수정에 사용하고,
✅ Chat은 일부 로직을 짜거나, 전체 코드 베이스에 어떻게 적용할지 같은 브레인스토밍에 쓰고,
✅ Composer로 대부분의 코드를 실험하고, 조합하고 작성하는 것에 사용하고,
✅ Components 이름 알아보기 쉽게 잘 정리해서 쓰고 있고, 등등
근데 이건 Cursor 쓰는 사람이면 다 비슷하게 쓸 거 같은데요?
어떻게 보면 Cursor 만든 사람이 저렇게 쓰라고 만든 것에 가깝고, 마크만의 방법이라고 하기 좀 어렵지 않나 생각이 들었어요. 그리고 사실 저렇게 말하면서 남들에 비해 대단히 생산적으로 시간을 단축했다고 말하기에는, 다들 집에 AI 하나쯤은 있는 시대에 뭐랄까.. 좀 애매하고요.
이 뉴스레터를 쓰기 시작할 때만 해도 "뭔가 있겠지, 나도 해보고 자랑해야징 헤헿" 이거였는데, 아무리 영상을 봐도 뭐가 없어서 (썸네일은 무슨 AI Agents로 분신술을 펼친 것처럼 보이지만, 9분 31초짜리 영상에서 뭘 바래 ..), 셀프로 TrustMRR 기준으로 분석해 보기로 했답니다.
그전에, ShipFast가 뭘까?
일단 1차 부스터 후보였던, ShipFast에 대해 살펴보죠.
- 로그인/회원가입
- 결제
- 이메일 시퀀스
- DB 연결
- 랜딩 페이지
- 가격
- 테스티모니얼
등등 SaaS 만들 때 매번 똑같이 들어가는 코드 모음이고요. 마크가 프로젝트 30개 만들면서 매번 반복했던 코드를 GitHub 레포 하나에 묶어서 1인 개발자 대상 패키지 상품으로 만든 거래요.
AI로 코딩해도 최종 검수는 결국 내가 해야 하는 거고, 근데 나는 경험이 적고, 성공한 사람의 노하우가 녹아든 잘 작동하는 코드 가져다가 쓸 수 있다면 (좀 비싸긴 하지만) 월 천 빨리 벌면 되니까 나쁘지 않은데? 마크처럼 빨리하는 게 목적이니까 이걸 사? 말아? 고민하고 있었는데..
ShipFast 보안 이슈가 있었다는 것을 봐버렸죠.
발단은, 어느 날 마크가 "누군가의 제보로 보안 문제를 찾았고, 고맙다는 의미로 300달러를 보내줬다"라고 트윗했는데, 다들 보.안.문.제.라는 단어에 꽂혔는지 ShipFast 포함 마크의 모든 서비스의 보안 이슈 사냥이 시작되었는데요.
문제는 사람들이 찾아낸 보안 이슈가 사용자 민감 데이터 노출, 결제 시스템 우회 등등 생각보다 크리티컬한 거였고, 그래서 X에서 엄청나게 저격했는데, 마크가 이걸 마녀사냥으로 받아들이거나 별거 아니라는 식으로 표현하면서 문제가 점점 커졌다고 하고요.

X에 올라온 코멘트 중에 '인턴 수준의 실수'라는 걸 보면 백엔드 플랫폼에서 할 수 있는 기본 처리도 안 했다는 얘기처럼 들리는데요. "일단 출시하고 나중에 고친다"라는 철학이 마크 혼자 운영하는 서비스면 사실 망하든지 말든지 싶지만, ShipFast를 $299 주고 산 사람 서비스에까지 적용되는 거라면 얘기가 다르죠.

ShipFast 도큐멘테이션 스샷 속 기능 목록도 봤는데,
Features 항목에 있는 기능들은 반복적이고 귀찮은 로직들 잘 처리해 놓은 것일지도 모르니까 패스하고, Components 항목 보면 그냥 랜딩 페이지에 들어가는 것들 같고, Testimonials를 Single, Triple, Grid로 쪼개놓는 것까지 포함해서 10개 정도인데 솔직히 얘기해서 이 부분은 빼고 가격을 매겨야 할 것 같다는 생각이고요. "결제, 로그인, DB 연결"도 Supabase, Stripe, Google OAuth, Resend 등등의 공식 도큐멘테이션을 다시 정리한 수준이라면 글쎄요.. 근데 로그인, 결제, DB 연결이 Flow로 그리면 초보자 입장에서는 생각보다 복잡할 수 있으니까, 그런 걸 정리해 놓은 거라면 돈 주고 살 수도 있을 것 같기는 하고요.
여튼 마크는 본인 프로젝트에 썼다고 말하고, 개발 속도를 높이는 데 일부 기여는 했을 것 같지만, 결정적인 것 같지는 않아요.
💡 몰랐던 사실
이런 1인 개발자를 겨냥한 Boilerplate는 ShipFast보다 먼저 나온 것들이 엄청 많고, 심지어 Vercel SaaS Starter 같은 무료 템플릿도 있고, 이렇게 다 모아놓은 사이트도 있고요. 그냥 제가 개발자가 아니라서 몰랐던 것. ShipFast가 젤 늦게 나왔는데 저렇게나 팔린 것 보면, 대단하기는 합니다.
TrustMRR을 하루 만에 만든 비결_최종
그럼 결론적으로, TrustMRR을 24시간안에 만들 떄,
ShipFast가 기여했을 법한 부분은
- 로그인/회원가입
- 일부 Styled Components
- 간단한 DB 세팅
이를 제외한 MVP의 메인 기능인
- 리더보드
- Stripe API 읽어서 매출 실시간으로 불러오고
- 그래프 그려주는 기능
메인 기능 항목별로 뜯어보면요.
- 검색이랑 정렬은 Supabase에서 기본으로 제공하는 기능 + Cursor 살짝 썼을 것 같고,
- Stripe API 연동은 공식 문서,
- 그래프는 Recharts 같은 거 썼을 것 같고,
- 리더보드는 이건 기존 프로젝트에서 복붙해서 썼을 것 같고,
보통 그렇게들 하니까, 비슷하게 했을 것 같고요.
다만 약간 차이점은,
마크 프로젝트 특징이 저 메인 기능 3가지를 꽤 자주 넣는다는 거예요. (e.g. IndiePage의 Stripe 연결 & 그래프 보여주기, ShipFast와 TrustMRR의 리더보드) 그래서 제 생각엔 본인만의 성공 공식이 있어서 앱 만들 때마다 비슷한 패턴으로 만들고, 결국 거의 모든 프로젝트가 본인 템플릿을 가져다 조합하는 거라 24시간 개발 납득된다, 이것이 오늘의 결론입니다. (나도 이런 결론일 줄 몰랐)
📌 교훈: 나의 프로젝트 패턴을 파악하고, 틈틈이 모듈화하자
아주 예전에 인스타툰에서도 다룬 프로그래밍좀비 님도 대량 생산이 하고 싶으면, 코드 모듈화를 하라고 자주 얘기하셨고, 마크도 결국엔 비슷한 거네요.
사람이 할 수 있는 생각의 패턴이 있어서 비슷한 요소를 계속 넣게 되는 경향이 있는 것 같기도 하고요. 저도 새로운 앱 만들고 정신 차리고 보면 항상 넣는 거 또 넣고요. 그래서 한두 개 서비스 터진 게 있으면 핵심 요소 꼭 모듈화해서 정리해야겠다 싶었어요.
끌로드한테 심심해서 저렇게 만들면, 마크는 얼마나 걸릴까? 물어봤더니

7-10시간이면 하고도 남는다는 거예요?
그래서 그러면 나 스택이 이런데 내가 하면 얼마나 걸릴까? 물어봤더니 끌로드가

ㅇㅇ 넌 2~3주 이러더라고요?
아 왜 나 무시함 이러면서 다시 칭얼댔더니 1~2주로 줄여주긴 했는데,
그래서 다음 주에 실제로 얼마나 걸리는지 시간 재면서 해보려고요. 물론 일주일 넘어가면 마무리 안 한 상태로 끝날 수도 있지만 여튼 그래서 다음 편은 SaaS 모듈화 실습 편입니다.





의견을 남겨주세요