Cursor Build Live Apps: 제공 기능, 가격, 한계 정리

앱은 localhost에서 잘 돌아가지만, 실제로 다른 사람이 쓸 수 있는 링크까지 만드는 단계에서 멈추는 경우가 많다. Cursor가 11월 5일 공개한 Build Live Apps는 그 간극을 줄이려는 기능이다. 변경 로그, 공식 문서, 초기 사용자 질문을 함께 살펴본 결론은 명확하다. Cursor SSO 뒤에서 쓰는 사내 도구와 프로토타입에는 강력하지만, 복잡하거나 규제 요건이 있는 프로덕션 백엔드를 바로 맡기기에는 아직 이르다.

Build Live Apps로 실제 배포되는 것

Build Live Apps는 자연어 요청을 배포된 웹 앱으로 바꾸는 클라우드 에이전트 워크플로다. Cursor는 2026년 11월 5일 변경 로그에서 이 기능을 발표했고, Apps 문서도 같은 흐름을 설명한다. 클라우드 에이전트에 요청하고, 트레이에서 미리 본 뒤, URL을 고르고, 보안 검사를 통과하면 라이브 링크로 게시한다.

요청은 분명하게 작성해야 한다. Cursor 문서는 프롬프트에 에이전트가 앱을 만들도록 명시하라고 안내한다. Cursor Origin에서 새 저장소를 만들며 처음부터 시작할 수도 있고, Cursor가 배포할 기존 GitHub 저장소를 사용할 수도 있다. 앱 생성은 클라우드 에이전트만 지원한다.

저장소가 필요하면 Cursor가 PostgreSQL 데이터베이스를 프로비저닝한다. 호스팅은 사용자 또는 팀마다 전용의 격리된 호스팅 계정에 배치된다. 팀 앱의 인증은 Cursor SSO로 처리되므로, 앱을 열려는 사람은 먼저 Cursor에 로그인해야 한다. 개인 요금제 사용자는 로그인 없이 접근하는 공개 앱도 게시할 수 있다.

처음부터 알아둘 제한도 있다. GitLab 지원은 예정돼 있지만 현재는 제공되지 않는다. 커스텀 도메인 지원 여부도 확정되지 않았다. Cursor는 게시자가 고유 도메인을 선택한다고 설명하고, 문서에는 URL을 나중에 바꿀 수 있다고 적혀 있다. 그러나 어느 쪽에도 커스텀 도메인을 연결하는 절차는 없다.

프레임워크, 런타임, 리전, Postgres 버전, 백업, 확장 방식, 대역폭 할당량, SLA는 어떤 페이지에도 명시돼 있지 않다. 호스팅은 법적으로 Cursor 서비스와 분리돼 있으며 "as is" 및 "as available" 조건으로 제공된다. Cursor는 서브도메인이나 앱을 철회하거나 중단할 권리도 보유한다.

게시 전 관문: 끌 수 없는 4가지 검사와 AI 검토

사용자가 명시적으로 게시하기 전에는 앱이 외부에 공개되지 않는다. 준비만 해둔다고 노출되는 것은 아니다. 별도 AI 검토를 팀에서 비활성화하더라도, 게시할 때마다 다음 네 가지 필수 검사는 항상 실행된다.

• 앱 파일에 API 키나 액세스 토큰이 있으면 게시를 차단한다.
• 프라이빗 키나 서비스 계정 키 같은 자격 증명 파일을 차단한다.
• .env 파일을 게시 번들에서 제외한다.
• 방문자가 브라우저에서 원본 소스를 복원하지 못하도록 소스 맵을 제거한다.

검사에 실패하면 Cursor가 문제를 표시한다. 이후 에이전트에게 수정을 요청하고 다시 시도할 수 있다.

추가 AI 보안 검토는 애플리케이션 파일을 읽고, 심각한 문제가 있으면 게시 전에 막을 수 있다. 팀 관리자는 이 검토 프롬프트에 조직별 지침을 추가할 수 있다. 사용자 지정 지침은 규칙을 더할 수는 있지만 Cursor의 기본 검사를 제거하거나 약화할 수는 없다. 관리자는 일부 게시 차단을 재정의할 수 있지만, 악성 코드·하드코딩된 시크릿·노출된 자격 증명 관련 차단은 재정의할 수 없다. 이 설정 변경은 팀 감사 로그에 남는다.

이 관문이 잡아내는 것보다, 보장하지 않는 것이 더 중요하다.

"The catch: passing security checks doesn't prove your app gives the right people the right access." — @0node0, 실제 사용자

Cursor는 시크릿과 노출된 자격 증명을 검사 사례로 든다. 하지만 앱마다 인가 테스트, 행 수준 권한 테스트, SQL 인젝션 대응 범위, 의존성 스캔, 비즈니스 로직 검토를 제공한다고는 말하지 않는다. TechRepublic의 11월 6일 분석도 같은 지점을 짚는다. 인증된 사용자 한 명이 다른 사용자의 레코드를 읽는 문제까지 검증된다는 근거는 없으므로, 권한 수준이 다른 여러 계정으로 직접 테스트해야 한다.

사용자가 가장 많이 묻는 3가지: 비용, Vercel 대체, 시크릿

호스팅에 별도 비용이 드나? Cursor는 호스팅이나 데이터베이스의 별도 가격을 공개하지 않았다. Build Live Apps 전용 구독도 없다. 클라우드 에이전트 접근 권한이 있는 유료 요금제에 포함된다. 현재 확인할 수 있는 구체적인 가격은 Cursor의 기능 페이지가 아니라 TechRepublic의 요금제 표에서 나온다.

Cursor는 주간 단위로 공유되는 AI 사용량 한도를 적용한다(TechRepublic의 요금제 분석). 다만 이 페이지들에서 Cursor는 티어별 토큰, 요청, 컴퓨팅 수치를 공개하지 않는다. 타사 모델에는 별도 요금이 발생할 수 있다(TechRepublic). 데이터베이스, 스토리지, 트래픽, 동시성 한도 역시 공개되지 않았다. 월 $30은 총 운영비가 아니라 입장권으로 보고, 고객 대상 워크로드를 내장 호스팅에 올리기 전에는 할당량을 확인하는 편이 좋다.

Build Live Apps가 Vercel을 대체하나? 복잡하거나 규제 요건이 있는 프로덕션 백엔드라면 아직 아니다. 내장 경로는 Postgres, SSO, 공유 링크 조합에 잘 맞는다. 반면 GitHub에서 Vercel, Netlify, Railway, Render, 또는 VPS로 이어지는 기존 경로는 커스텀 아키텍처와 규제 대상 데이터를 계속 담당한다. 시나리오별 구분은 아래 표에 정리했다. Reddit의 호스팅 토론에서도 같은 기준이 반복된다. 워크로드가 얼마나 상태를 유지하고 오래 실행되는지가 호스트 선택을 좌우한다.

"Most cursor demos I see on my timeline are focused on the UI… most aren't deployed to live paying users." — @mayowaoshin, 실제 사용자

시크릿은 어디에 저장되며, 에이전트가 볼 수 있나? Cursor 문서에 따르면 코딩 에이전트는 시크릿 값을 절대 보지 못한다. 데이터 웨어하우스나 외부 API가 필요한 앱은 사용자에게 시크릿을 요청한다. 팀 시크릿은 보통 팀 관리자가 Apps 대시보드에서 만들며, 같은 대시보드에서 나중에 추가할 수도 있다.

팀 관리자는 모든 팀 앱과 팀 시크릿을 볼 수 있다. 이는 거버넌스 기능이면서, 프로덕션 키를 붙여넣기 전에 이해해야 할 신뢰 경계이기도 하다. 스크립트, CI 작업, Grok Bot 같은 자동화 클라이언트는 쿠키나 쿼리 매개변수가 아니라 헤더 기반 키(x-cursor-app-token)로 보호된 앱에 접근한다.

내장 배포가 맞는 경우와 기존 배포를 유지할 경우

기존 경로에도 자체 설정 작업은 남는다. MCP 구성, 호스팅 자격 증명, 환경 변수, RLS 강화가 필요하다. 한 빌더가 공개한 랜딩 페이지에서 Vercel, Supabase 인증까지 이어진 4주 과정이 이를 보여준다.

공유 전 확인할 프로덕션 준비 체크리스트

Cursor의 검사는 유출된 시크릿과 자격 증명 파일을 잡아낸다. 그 뒤에 남는 위험은 권한, 환경 구성, 비동기 부작용, 그리고 아무도 읽지 않은 코드다. 내부 도구라도 처음 공유하기 전에는 아래 항목을 점검해야 한다.

1. 깨끗한 상태에서 다시 빌드하고 diff를 읽는다. 에이전트에게 개발 서버가 아닌 실제 프로덕션 빌드를 실행하게 한다. 결제, 인증, 데이터 쓰기와 관련된 변경 파일은 모두 열어 확인한다. 프로젝트가 이미 diff를 검토하기 어려울 정도로 커졌다면, 복잡한 상태에서 프롬프트를 이어가기보다 체크포인트를 복원하고 작업을 나눈다.
2. 두 계정으로 권한을 검증한다. 관리자와 제한된 권한의 멤버로 각각 로그인한다. 사용자 A로 레코드를 만든 후 사용자 B가 읽기, 수정, 삭제를 시도하게 한다. 보안 보고서 통과는 행 소유권이 정확하다는 증거가 아니다.
3. 시크릿 경로를 처음부터 끝까지 감사한다. 키가 프런트엔드 코드에 번들되지 않았는지, .env가 배포되지 않았는지, 외부 자격 증명이 동작에 필요한 최소 권한만 갖는지 확인한다. 에이전트가 접근 가능한 환경에서 프로덕션 데이터베이스 URL을 제거한다. 한 r/cursor 제보에서는 Cursor가 GitHub를 거치지 않고 프로덕션 Supabase에 바로 배포했다고 전한다.
4. 비동기 경로를 실제로 실행해 본다. 실제 웹훅을 발생시키고, 재시도하고, 처리 중간에 중단한다. 동시 사용 상황에서 커넥션 풀 동작도 확인한다. 조용히 실패한 웹훅과 고갈된 풀은 사용자가 출시 후에야 발견했다고 보고하는 유형의 문제다.
5. 업데이트와 롤백 절차를 정한다. 누가 게시할 수 있는지, 누가 차단된 게시를 재정의할 수 있는지, 누가 게시를 취소할 수 있는지, 감사 로그는 어디에 남는지 확인한다. 문서는 게시를 설명하지만 버전 이력이나 롤백은 설명하지 않으므로, 잘못된 게시를 되돌리는 방법과 스키마 마이그레이션을 실행하는 방법도 기록해 둔다.

"Once an app leaves localhost, its secrets come with it." — @1PasswordDev, 앱별 시크릿 격리에 관한 실제 사용자

스테이징 프로젝트, 두 번째 테스트 계정, 롤백 절차처럼 위 항목 중 답하지 못하는 것이 하나라도 있다면, 준비될 때까지 앱은 팀 전용 링크나 기존 스택에 유지하는 편이 낫다.

FAQ

Build Live Apps를 쓰려면 Cursor 유료 요금제가 필요한가?

그렇다. Build Live Apps는 클라우드 에이전트가 활성화된 유료 요금제에서만 실행된다. 월 $8 Plus는 대상이 아니다. 월 $30 Premium이 조건을 충족하는 가장 저렴한 개인 요금제다.

기존 저장소로도 Cursor가 앱을 만들 수 있나?

그렇다. 기존 GitHub 저장소를 사용하거나 Cursor Origin에서 처음부터 만들 수 있다. GitLab은 지원 예정이지만 아직 사용할 수 없으며, 로컬 에이전트는 앱을 만들 수 없다.

팀 앱을 공개로 전환할 수 있나?

Team 및 Enterprise 요금제에서는 공개 공유가 기본적으로 비활성화돼 있다. 관리자가 Apps 대시보드에서 활성화할 수 있다. 개인 요금제는 공개 앱을 직접 게시할 수 있다.

Cursor는 커스텀 도메인을 지원하나?

Cursor는 게시자가 고유 도메인을 선택하고 나중에 변경할 수 있다고 말한다. 하지만 변경 로그와 문서 어디에도 커스텀 도메인 매핑을 확정하는 내용은 없다. Cursor가 별도로 문서화하기 전까지는 Cursor 관리 URL을 사용한다고 가정하는 편이 안전하다.

스크립트나 봇은 비공개 앱에 어떻게 접근하나?

Cursor API 키를 발급하고 모든 요청에 x-cursor-app-token 헤더로 보낸다. 개인 키는 소유자가 열 수 있는 모든 앱을 열 수 있다. 팀 키는 명시적으로 권한을 부여받은 팀 앱만 열 수 있다.

앱 게시를 취소하면 어떻게 되나?

관리자는 모든 팀 앱의 게시를 취소할 수 있으며, 공개 앱을 비활성화하면 기존 공개 앱은 팀 전용 공개 범위로 돌아간다. Cursor는 게시 취소 후 데이터 보존, 백업, 데이터 내보내기 동작을 문서화하지 않았다.

Build Live Apps는 작동하는 프로토타입과 실제로 사용할 수 있는 링크 사이의 호스팅 설정을 없애준다. 하지만 결과물을 다른 사람이 안전하게 쓸 수 있는지 결정하는 검토, 권한 테스트, 소유권 관리까지 없애주지는 않는다.

함께 읽기: Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained