localhost 앱을 팀 도구로 옮기기 전: Cursor Apps의 DB·인증·공개 승인 경계

노트북에서만 열리는 대시보드를 동료가 쓰게 하려면 코드를 만드는 일 다음에 호스팅, 데이터 저장, 로그인, 공개 범위를 결정해야 한다. Cursor가 2026년 11월 5일 발표한 Apps는 Cloud Agent가 이 연결 작업을 맡는 경로다. 다만 “링크가 생긴다”와 “아무나 열 수 있다”, “보안 검사가 있다”와 “업무용으로 안전함이 입증됐다”는 각각 다른 말이다. 공식 발표와 Apps 문서를 구분해 보면, 이번 기능을 평가할 질문은 코드 생성 속도보다 팀의 데이터·열람·게시 권한을 어디에 둘 것인가에 가깝다.

내부 버그 접수 도구라면 공개 링크부터 만드는 대신 초대 대상, 저장할 데이터, 게시 승인자를 먼저 정하는 편이 맞다. 아래 판단표와 배포 경계도는 그 결정을 돕기 위한 자체 분석이다. 그림은 공식 UI를 촬영한 화면이 아니라 문서의 관계를 다시 그린 설명도다.

1. 로컬 에이전트가 아니라 Cloud Agent의 앱 배포 경로다

공식 문서는 앱을 만들겠다는 의도를 명시하고 Cloud Agent를 사용하라고 안내한다. 로컬 에이전트에서는 이 기능을 지원하지 않는다. 새로 시작하면 Cursor Origin에 저장소를 만들 수 있고, 기존 GitHub 저장소의 앱 배포도 요청할 수 있다. 이미 돌아가는 localhost 앱을 어떤 환경에서도 그대로 옮겨 준다는 호환성 보장은 아니다. GitLab 등 다른 공급자를 현재 지원한다고 읽어서도 안 된다. 발표에서 다른 git 공급자 지원은 향후 계획으로 구분된다.

문서상 Cursor는 팀 또는 개인을 위한 전용 호스팅 계정을 만들고 다른 팀·사용자의 계정과 격리한다. 데이터베이스가 필요한 앱에는 Postgres를 자동 마련한다. 여기서 “필요하면”이 중요하다. 모든 앱에 데이터베이스가 무조건 생긴다는 뜻도, 기존 사내 데이터가 자동으로 연결된다는 뜻도 아니다. 다른 시스템을 쓰려면 연결 자원과 필요한 비밀값을 별도로 설정해야 한다.

앱 제작과 배포 자원을 맡기는 경로와 팀에 남는 운영 판단은 다르다. 공식 문서 기반 자체 설명도이며 제품 UI가 아니다. 출처: cursor.com/docs/cloud-agent/apps.

이 구조를 내부 도구에 적용한다면 먼저 읽기 전용 자료와 합성 입력으로 작은 범위를 정하는 것이 합리적이다. 이는 제품이 보장하는 기본 동작이 아니라 도입 위험을 줄이기 위한 편집상 권고다. 예를 들어 버그 접수 앱의 첫 검토에서는 실제 고객정보 대신 가상의 제목·상태만 쓰고, 저장 기능이 정말 필요한지와 누가 내용을 볼 수 있어야 하는지부터 나눌 수 있다.

2. 링크 전달과 접근 허용은 같은 작업이 아니다

공식 문서에서 비공개·팀 앱은 Cursor 로그인 뒤에 있다. 초대한 특정 팀원·그룹만 허용하는 범위와 팀 전체 범위는 구분된다. Public은 링크를 가진 누구나 열 수 있는 범위다. 개인 요금제 이용자는 앱을 공개 공유할 수 있지만, Teams와 Enterprise의 공개 공유는 기본적으로 꺼져 있으며 관리자가 활성화할 수 있다. 따라서 내부 팀 앱의 링크를 외부 고객에게 보냈다는 사실만으로 고객이 열 수 있다고 판단하면 안 된다.

비공개·팀 앱은 Cursor 로그인을 요구한다. Teams·Enterprise 공개 공유는 기본 꺼짐이며 관리자가 활성화할 수 있다. 출처: cursor.com/docs/cloud-agent/apps.

만들려는 도구·상황	먼저 선택할 접근 범위	검토할 구체적 경계
특정 담당자만 쓰는 버그 접수 도구	초대한 팀원·그룹	담당자가 아닌 계정으로 접수 내용이 보이지 않아야 한다는 요구를 정한다.
조직 공용 운영 대시보드	팀 전체	같은 팀이라는 이유만으로 모든 데이터 열람을 허용해도 되는지 검토한다.
외부에 보여 줄 마이크로사이트	공개 공유 가능 여부부터	개인·팀 요금제의 차이와 관리자 설정을 확인하고, 공개할 데이터만 남긴다.
자동화 스크립트의 앱 이용	사람의 로그인과 별도 검토	API 키 접근 허용 정책과 키의 권한을 별도로 검토한다.

표는 실제 접근 시험 결과가 아니라 문서에 근거한 요구사항 분해다. 특히 로그인할 수 있다는 사실만으로 앱 내부의 모든 업무 권한이 적절하게 구현됐다고 결론내릴 수 없다. 작성자는 열람자와 수정자를 어떻게 구분할지, 민감한 항목을 누가 볼지 등 앱 수준의 요구사항도 남겨야 한다. 관리형 인증을 선택해도 이런 업무 판단까지 자동으로 끝나는 것은 아니다.

3. 비밀값 입력 경로와 게시 파일 검사는 분리해 읽는다

Apps 문서는 외부 시스템 연결에 필요한 비밀값을 입력받는 경로에서 에이전트가 그 값을 보지 않는다고 설명한다. 일반적으로 팀 비밀값은 관리자가 만들고, 권한이 있으면 개인 비밀값도 추가할 수 있다. 이는 공급자가 설명한 처리 경로이며, 이 글에서 비밀 유출이 불가능함을 독립 검증했다는 의미는 아니다. 또한 문서는 팀 관리자가 팀의 모든 앱과 비밀값을 볼 수 있다고 안내하므로 “관리자도 접근할 수 없다”는 식으로 범위를 넓히면 안 된다.

이와 별도로 게시할 때에는 항상 켜져 있는 네 가지 검사가 있다. 앱 파일에 하드코딩된 API 키·토큰을 차단하고, 개인키·서비스 계정 키 등 자격 증명 파일을 차단하며, .env 파일과 소스맵은 배포물에서 제외한다. 앞의 두 항목은 게시 차단, 뒤의 두 항목은 배포 제외라는 동작 차이도 유지해야 한다. 단순히 “위험 파일 네 종류를 모두 삭제한다”로 줄이면 원문 의미가 바뀐다.

항상 켜진 네 가지 검사와 추가 AI 검토를 분리했다. 일부 관리자 예외는 가능하지만 악성 코드·하드코딩 비밀값·노출 자격 증명은 제외된다. 출처: cursor.com/docs/cloud-agent/apps.

추가 AI 보안 검토는 앱 파일을 읽고 심각한 문제를 찾아 게시를 막는 계층이다. 관리자의 사용자 지정 검토 지침은 규칙을 추가할 수 있지만 Cursor의 기본 검사를 없앨 수는 없다. 문서가 말하는 검사 계층을 앱의 기능 정확성, 데이터 접근 설계, 독립 보안 감사와 혼동하지 않는 것이 핵심이다. 예를 들어 비밀값이 파일에 없다는 검사와 다른 팀원의 비공개 기록을 읽지 못한다는 요구사항은 서로 다른 질문이다.

4. Publish 선택, 검사, 관리자 예외를 한 흐름으로 본다

공식 흐름은 준비된 앱을 미리 보고, 사용자가 Publish를 선택해 URL을 고르고, 검사 결과에 따라 공개 링크를 받는 순서다. 사용자가 게시하기 전에는 앱이 공개되지 않는다고 문서는 설명한다. 검사가 실패하면 수정할 항목을 확인해 에이전트에게 고치도록 요청한 뒤 다시 게시한다. 이 글은 그 버튼을 누르거나 앱을 배포하지 않았다.

관리자 예외는 별도로 읽어야 한다. 팀 관리자는 검토가 막은 게시 중 일부를 승인할 수 있지만, 악성 코드·하드코딩된 비밀값·노출된 자격 증명은 예외 승인 대상에서 제외된다. “검사가 막으면 누구도 어떤 경우에도 승인할 수 없다”도, “관리자는 모든 검사를 우회한다”도 문서와 맞지 않는다. 팀 설정 변경은 감사 로그에 기록된다.

작성한 도입 판단 예시다. 합성 데이터, 역할별 요구사항과 게시·중단 담당자를 정리하며 실제 배포나 권한 시험을 수행한 결과가 아니다. 출처: cursor.com/docs/cloud-agent/apps.

팀 관리자는 앱 기능이나 공개 공유, API 키 접근의 허용 여부를 제어할 수 있고, 앱의 게시를 취소할 수도 있다. 공개 앱을 허용하지 않도록 바꾸면 기존 공개 앱은 팀 공개 범위로 돌아간다는 설명도 있다. 그래서 도입 검토에는 최초 게시 승인뿐 아니라 잘못 공유했을 때 누가 범위를 바꾸고 게시를 중단할지도 포함하는 편이 낫다. 이것은 제품의 자동 사고 대응을 주장하는 것이 아니라 문서상 관리 기능을 운영 책임에 연결한 해석이다.

5. 내부 버그 접수 도구라면 이렇게 요구사항을 좁힌다

다음은 실행된 프롬프트나 배포 로그가 아닌 작성 예시다. “버그 접수 앱을 만들어 줘”만 요청하는 대신 다음처럼 목적·범위·제외 사항을 남길 수 있다.

Cloud Agent로 팀 내부 버그 접수 앱을 설계한다. 처음에는 합성 데이터만 사용한다. 접수 제목과 상태를 저장해야 하므로 Postgres 사용 필요성을 검토한다. 열람 대상은 초대한 팀원으로 제한하고 외부 공개는 요구하지 않는다. 외부 시스템 비밀값을 코드에 넣지 않는다. 미리보기에서 확인할 항목과 게시 전에 결정해야 할 권한을 정리한다.

이 예시가 제품에 그대로 수용됐거나 보안 설정이 자동 완성됐다는 증거는 없다. 실무 효용은 요구사항을 분리하는 데 있다. 저장이 필요 없다면 DB 없는 단순 표시 도구부터 검토하고, 팀 전체가 볼 수 없는 자료라면 팀 범위를 선택하지 않으며, 외부 시스템 연결이 필수가 아니라면 첫 시험에서 제외하는 식이다.

미리보기 검토에서도 “화면이 보인다” 하나로 끝내기보다 접수·조회·수정에 기대하는 동작을 각각 적는 것이 좋다. 초대받지 않은 사용자, 다른 팀원, 관리자라는 서로 다른 역할에서 어떤 결과가 나와야 하는지 정리하면, 나중에 실제 시험에서 무엇을 확인할지 선명해진다. 이 글은 그런 역할 시험을 수행하지 않았으며, 표나 그림을 실제 통과 기록으로 제시하지 않는다.

6. 도입 결론: 배포 연결은 맡길 수 있어도 운영 판단은 남는다

Apps는 Cloud Agent 접근이 가능한 유료 요금제에서 제공된다고 문서는 안내한다. 이것을 무료·무제한 호스팅이나 특정 DB 비용 보장으로 바꿔 말할 근거는 없다. 이번 확인 자료만으로 정확한 추가 비용·할당량·가용성 보장 수치를 확정하지 않는다. 문서는 호스팅을 별도로 제공하며 현 상태·가용한 상태를 전제로 한다고 설명하므로, 중단이 큰 손실로 이어지는 업무는 비용과 운영 조건을 추가 확인해야 한다. 이는 법률 해석이나 서비스 적합성 인증이 아니다.

2026년 10월 16일의 Cloud Agent Canvases 발표는 완성된 캔버스를 팀과 공유하는 작업을 다뤘다. 이번 글은 그 공유 방법을 반복하기보다 호스팅·선택적 데이터베이스·로그인·게시 승인이라는 운영 앱의 경계를 다룬다. 판단 기준도 “팀원이 링크를 받았는가”가 아니라 “의도한 데이터만 의도한 사람에게 열리며, 공개를 누가 승인하고 중단하는가”다.

소규모 내부 도구를 시험할 후보라면 먼저 데이터 저장 필요성과 접근 대상을 고정하고, 공개 전 검토 책임자를 정하는 순서가 유용하다. 반대로 외부 고객 접근, 민감 데이터 처리, 엄격한 가용성 요건이 핵심이라면 링크 생성의 편리함만으로 적합성을 결정하기 어렵다. 관리형 배포가 줄이는 것은 연결 작업이지, 팀의 운영 책임 자체가 아니다.

참고 자료와 확인 범위

• Cursor — Build Live Apps in Cursor: 2026년 11월 5일 발표와 지원 저장소, Cloud Agent 시작 경로.
• Cursor Docs — Apps: 호스팅·DB·인증·공유 범위, 비밀값, 게시 검사, 관리자 예외와 제공 조건.
• Cursor — Cloud Agent Canvases and Environment Improvements: 2026년 10월 16일 이전 기능과의 주제 구분에만 사용.

2026년 11월 6일 수집·동결된 공식 원문을 바탕으로 AI를 활용해 작성한 해설이다. 이 글은 공식 문서에 근거한 설계 판단이며, 실제 앱 배포·보안 감사·성능 실험을 수행한 결과가 아니다. 본문 표·프롬프트·그림은 작성한 분석 및 예시이고 제품 화면이나 실측 결과가 아니다.