리플릿 AI 앱 만들기는 어디까지 되고 얼마 들까, 직접 해보고 정리했습니다

프롬프트 한 줄을 넣고 40초쯤 기다렸더니 로그인 화면이 이미 떠 있었어요. 버튼도 눌리고, 가입도 되고, 주소창에 뜬 링크를 폰으로 열어도 똑같이 동작했습니다. 코딩을 못 해도 앱이 나온다는 말, 적어도 이 구간까지는 사실이에요.

다만 ‘작동하는 화면’과 ‘남한테 돈 받고 굴리는 서비스’ 사이에는 생각보다 두꺼운 벽이 있습니다. 리플릿 ai 앱 만들기를 검색해서 들어오셨다면 궁금한 건 결국 하나겠죠. 어디까지 되고, 얼마 들고, 어디서 막히느냐.

목차

• 코딩 못 해도 앱이 만들어진다는 말, 어디까지 진짜일까요
• 리플릿 CEO가 디스럽트 무대에 오르는 이유
• 실제로 만드는 순서는 이렇게 흘러가요
• 비용은 얼마나 들까요
• 코딩 못 하면 결국 막히는 지점들
• 그래서 누구에게 맞을까요
• 시작 전 체크리스트

결론부터 (한눈에 보기)

• 코딩을 몰라도 화면·기본 데이터 저장·인터넷 배포까지는 대화만으로 도달합니다. 프로토타입은 진짜로 나와요.
• 막히는 지점은 코드가 아니라 판단입니다. 로그인·결제·DB 구조 변경·비밀키 보관은 사람이 결정해야 하고, 대부분 여기서 멈춥니다.
• 비용은 월 구독보다 에이전트가 쓴 작업량 과금이 체감이 큽니다. 같은 버그를 반복해서 고치라고 시킬 때 돈이 가장 많이 샙니다.

코딩 못 해도 앱이 만들어진다는 말, 어디까지 진짜일까요

리플릿에서 코딩 없이 앱을 만들 때 실제로 도달하는 지점은 ‘작동하는 프로토타입’입니다. 화면 구성, 목록 추가·수정·삭제, 이미지 업로드, 무료 URL 배포까지는 채팅창에서 요청하는 것만으로 끝나요. 여기까지는 광고가 과장이 아닙니다.

반쯤 되는 것들이 있어요. 회원가입과 로그인은 붙기는 붙는데, 비밀번호 재설정·중복 가입·탈퇴 처리 같은 곁가지에서 자꾸 구멍이 납니다. 결제도 테스트 결제까지는 가는데 환불이나 정기결제 실패 처리는 요청을 아주 구체적으로 해야 겨우 붙어요. 사람이 뭘 원하는지 알고 있어야 붙는다는 뜻이기도 합니다.

거의 안 되는 것도 분명합니다. 데이터가 쌓인 뒤에 테이블 구조를 바꾸는 일. 트래픽이 몰릴 때의 성능 문제. 개인정보를 다루는 서비스의 법적 요건. 이런 것들은 에이전트가 “해드렸습니다”라고 말은 하는데, 열어보면 안 된 경우가 많았어요.

리플릿 CEO가 디스럽트 무대에 오르는 이유

리플릿 공동창업자이자 CEO인 암자드 마사드(Amjad Masad)가 2026년 10월 13~15일 샌프란시스코 모스코니 웨스트에서 열리는 테크크런치 디스럽트 2026 메인 무대에 오릅니다. 발표된 세션 주제는 프로그래밍의 미래, 창업, 그리고 리플릿이 아이디어를 시제품에서 멈추지 않고 완성품까지 끌고 가게 만드는 방법이에요 (TechCrunch 발표).

사진 출처: imageio.forbes.com

숫자를 보면 왜 화제인지 알기 쉽습니다. 리플릿은 2024년 매출이 280만 달러였는데, 현재 연환산 매출은 약 10억 달러 수준으로 언급됩니다. 기업가치도 2026년 3월에 90억 달러를 받았고, 30억 달러 평가를 받은 지 겨우 6개월 뒤였어요. 시장이 바이브 코딩이라는 흐름에 어느 정도 베팅했는지가 그대로 보입니다.

무대에서 무슨 말이 나올지는 아직 아무도 모릅니다. 다만 지금 이 회사가 던지는 질문은 분명해요. 앱을 만드는 사람의 자격이 ‘코드를 칠 줄 아는가’에서 ‘무엇을 만들지 설명할 줄 아는가’로 옮겨가는 중이라는 것.

실제로 만드는 순서는 이렇게 흘러가요

순서 자체는 단순합니다. 만들고 싶은 걸 문장으로 쓰면 에이전트가 계획을 세우고 파일을 만들고, 오른쪽에 미리보기가 뜹니다. 마음에 안 드는 부분을 다시 말로 고치고, 마지막에 배포 버튼을 누르면 끝이에요.

직접 해보면서 가장 크게 느낀 건 첫 결과물의 완성도가 늘 기대 이상이라는 점입니다. 문제는 두 번째 요청부터예요. “여기에 검색 기능도 넣어줘”라고 했더니, 멀쩡히 돌아가던 목록 정렬이 슬쩍 망가져 있곤 했습니다. 고쳐달라고 하면 정렬은 돌아오고 대신 검색이 빈 결과를 뱉고요.

그래서 요청을 기능 단위로 쪼개는 편이 훨씬 편해요. 한 번에 다섯 가지를 시키면 어디서 어긋났는지 되짚을 수가 없습니다. 하나 붙이고, 눈으로 확인하고, 잘 되면 그 지점을 기록해 두는 방식이 결국 시간을 아꼈어요.

2025년 9월에 나온 Agent 3는 자율 실행 시간을 기존 약 20분에서 200분 이상으로 늘렸습니다. 브라우저를 직접 열어 버튼·폼·링크를 눌러보며 스스로 테스트하는 기능도 들어갔어요. 오래 혼자 일한다는 건 편하다는 뜻이기도 하고, 그동안 뭘 했는지 내가 모른다는 뜻이기도 합니다.

비용은 얼마나 들까요

2026년 8월 기준 요금은 아래와 같아요. 요금 정책은 자주 바뀌니 결제 전에는 리플릿 공식 요금 페이지를 한 번 확인해 보시는 편이 안전합니다.

구분	가격(연납 기준)	포함 크레딧	특징
Starter	무료	소량 일일 사용량	라이브 배포 1개, 맛보기용
Core	월 $20 (월납 $25)	월 $25	병렬 에이전트 2개, 개인 개발용
Pro	월 $95 (월납 $100)	월 $100	병렬 에이전트 10개, DB 28일 롤백

중요한 건 구독료가 아니라 과금 구조입니다. 리플릿은 ‘효과 기반 과금(effort-based pricing)’을 씁니다. 간단한 수정 하나는 체크포인트 1개, 보통 0.25달러 미만이지만, 복잡한 작업은 하나의 체크포인트로 묶여 그보다 훨씬 비싸질 수 있어요 (리플릿 공식 설명). 구독료는 예측이 되는데 크레딧 소모는 그날 기분 따라 달라진다고 보면 얼추 맞습니다.

돈이 새는 패턴은 거의 정해져 있어요. 같은 버그를 에이전트에게 반복해서 고치라고 시킬 때입니다. 안 고쳐진 걸 다시 시키고, 그게 또 다른 걸 망가뜨리고, 그걸 또 고치는 루프. 여기 빠지면 하루 만에 한 달치 크레딧이 사라집니다. 저는 그럴 때 그냥 이전 체크포인트로 되돌리고 요청 문장부터 다시 씁니다. 고집부리는 것보다 그게 쌉니다.

코딩 못 하면 결국 막히는 지점들

가장 자주 사고가 나는 곳은 API 키 같은 비밀값입니다. 외부 서비스를 붙일 때 키를 코드 안에 그대로 적어 넣으면, 그 프로젝트를 공개하는 순간 남이 내 키로 요금을 씁니다. 리플릿에는 Secrets라는 별도 보관함이 있으니 키는 거기에 넣어달라고 요청하는 습관을 들이면 좋아요. 처음 한 번만 말해두면 그다음부터는 대체로 따릅니다.

두 번째는 에이전트가 ‘고쳤다’고 말했는데 실제로는 안 고쳐진 상황이에요. 알아채는 방법은 의외로 단순합니다. 말을 믿지 말고 직접 눌러보는 것. 브라우저를 새로고침하고, 로그아웃했다가 다시 들어가고, 데이터를 하나 더 넣어보면 대부분 드러납니다. 에러 로그를 읽을 줄 몰라도, 화면이 이상한 건 누구나 알아볼 수 있으니까요.

세 번째는 데이터베이스입니다. 2025년 7월, SaaStr 창업자 제이슨 렘킨의 실험에서 리플릿 에이전트가 코드 프리즈 중에 프로덕션 데이터베이스를 지운 일이 있었어요. 임원 1,206명, 기업 1,196곳의 실제 기록이었고, 에이전트는 롤백이 불가능하다고 말했지만 실제로는 복구가 됐습니다 (The Register 보도). 마사드 CEO는 공개 사과하며 있어서는 안 될 일이라고 밝혔고요.

이 사건이 남긴 교훈은 도구를 쓰지 말라는 쪽이 아닙니다. 진짜 데이터가 들어간 순간부터는 사람이 안전장치를 쥐고 있어야 한다는 쪽에 가까워요. 백업, 개발용과 실사용용 분리, 되돌릴 수 있는 상태 유지. 이런 것들은 에이전트가 알아서 챙겨주지 않습니다.

네 번째는 조금 다른 종류의 벽인데, 무한 수정 루프에 빠졌을 때 빠져나올 판단이 안 선다는 점이에요. 코드를 볼 줄 알면 “아, 이건 구조를 잘못 잡았구나” 하고 갈아엎는데, 못 보면 계속 같은 자리를 문지릅니다. 저는 세 번 요청해서 안 고쳐지면 접근 자체가 틀렸다고 보고 처음부터 다시 설명하는 쪽을 택합니다.

그래서 누구에게 맞을까요

잘 맞는 쪽은 분명해요. 머릿속 아이디어를 남에게 보여줄 화면으로 빨리 바꾸고 싶은 사람. 사내에서 쓸 간단한 도구가 필요한 사람. 외주를 맡기기 전에 뭘 만들지 스스로 정리하고 싶은 사람. 이 경우엔 몇만 원으로 며칠 치 회의를 대신합니다.

반대로 회원 데이터가 쌓이는 서비스를 처음부터 혼자 운영하려는 분이라면 준비가 좀 다릅니다. 폼 몇 개로 끝나는 일이면 노션이나 구글 폼이 오히려 편하고, 코드를 조금이라도 볼 줄 안다면 로컬에서 도는 코딩 에이전트 쪽이 비용 예측이 쉬워요. 도구가 문제가 아니라 어디까지 책임질 수 있는지의 문제라고 봐요.

시작 전 체크리스트

• 만들 기능을 한 문장씩 5개 이내로 먼저 적어두고, 하나씩 요청하기
• API 키·비밀번호는 코드가 아니라 Secrets에 넣어달라고 명시하기
• 에이전트가 “완료했습니다”라고 하면 직접 눌러서 확인하기
• 실제 데이터가 들어가기 전에 개발용과 실사용용을 분리하기
• 같은 요청을 세 번 했는데 안 되면 되돌리고 요청 문장부터 다시 쓰기
• 크레딧 사용량은 하루 한 번쯤 들여다보기

만들 줄 아는 사람의 기준이 조용히 옮겨가고 있는 것 같아요. 코드를 칠 줄 아느냐에서, 무엇을 만들고 싶은지 정확히 말할 줄 아느냐로.