매출 스프레드시트를 앱으로 만든 Cursor, 배포한 링크는 누가 관리할까?

월요일 아침, 영업 팀장이 챙겨야 할 고객사를 한 페이지에서 보고 싶어 합니다. 숫자는 스프레드시트에 있고 고객사 배정 규칙은 다른 탭에 있습니다. 팀원마다 조금씩 다른 사본을 가지고 있습니다. 개발자가 오후 한나절이면 쓸 만한 대시보드를 만들 수 있습니다. 영업 팀장이 링크를 달라고 하면 답하기 까다로운 질문이 시작됩니다.

코딩 환경 Cursor를 만드는 Anysphere가 2026년 11월 5일 Live Apps를 출시했습니다. Cursor 클라우드 에이전트에 웹 앱을 요청하면 호스팅과 인증을 설정하고, 필요할 경우 Postgres 데이터베이스를 마련할 수 있습니다. 보안 검토를 거쳐 사용자가 직접 게시하면 접속할 수 있는 URL이 생깁니다. 클라우드 에이전트가 활성화된 유료 요금제에서 사용할 수 있습니다. 새로 만들거나 이미 사용 중인 Cursor Origin 또는 GitHub 저장소의 코드를 사용할 수 있습니다. Cursor 출시 공지

덕분에 스프레드시트 사본과 주간 메시지로 처리하던 업무에도 내부 앱을 도입할 수 있습니다. 그만큼 시제품이 동료가 의존하는 도구로 넘어가는 속도도 빨라집니다. 영업 대시보드와 온보딩 포털을 예로, 언제 시제품을 공개할지 판단하는 방법과 누가 데이터에 접근하고 수정하거나 앱을 내릴 수 있는지 확인하는 방법을 살펴봅니다.

배포 버튼을 누르면 운영이 시작됩니다

Cursor에서는 앱을 원한다고 명시하고 클라우드 에이전트를 사용해야 합니다. 로컬 코딩 세션에서 소스 작업을 도울 수 있고, Cursor 문서에 나온 Apps 절차는 클라우드 에이전트에서 진행합니다. 처음부터 시작하면 Cursor Origin에 저장소를 만들 수 있습니다. 팀 앱이 지원되는 저장소에 이미 있다면 그 소스를 사용할 수 있습니다. Cursor는 앱 실행에 필요한 리소스를 마련하고, 게시 담당자가 URL과 공유 시점을 정합니다. Apps 설정 및 배포

소스에서 공개 URL까지 이어지는 과정. 접근 대상과 데이터 원본을 따로 표시했습니다. Telli.sh 자체 제작.

Cursor는 게시 전 검토를 두 가지로 설명합니다. 정해진 규칙에 따른 검사는 파일에 비밀 값이 기록된 경우처럼 미리 정의할 수 있는 문제를 포착합니다. AI 보안 검토는 앱 소스를 살펴 심각한 문제를 찾습니다. Cursor에 따르면 팀 관리자는 자체 규칙을 추가하고, 팀 앱과 비밀 설정을 확인하고, 앱을 내릴 수 있습니다. AI 검토에 걸린 게시 중 일부는 관리자가 승인할 수도 있습니다. 악성 코드, 코드에 직접 적은 비밀 값, 노출된 인증 정보에 대한 차단은 유지됩니다. 앱에 어떤 인증 정보가 필요한지는 앱 담당자가 결정합니다. Cursor 출시 공지 · Apps 보안 및 관리

첫 화면에는 매출 합계가 나오고 상세 요청에는 모든 고객사가 반환되는 앱을 생각해 봅시다. 영업 관리자가 로그인해 보면 권한이 잘 적용된 것처럼 보일 수 있습니다. 하지만 동료가 상세 URL을 추측하거나, 표에서 볼 수 없는 영업 구역을 서버에 직접 요청할 수도 있습니다. 배포 전 검토는 구현상 결함을 발견하는 데 도움이 됩니다. 구역별 접근 규칙은 팀의 접근 정책을 기준으로 삼고, 배포 테스트에서 실제 역할별로 확인해야 합니다.

실제로 열리는 URL이 생기는 순간 이런 결정의 영향이 커집니다. 동료가 즐겨찾기에 추가했다면 보고서가 깨져 아침 회의가 지연될 수 있습니다. 의사결정이나 승인을 앱에만 남기기 시작하면 앱 데이터베이스도 업무 절차의 일부가 됩니다. 작은 앱에도 숫자가 이상할 때 이유를 설명할 담당자가 필요합니다.

읽기 전용 대시보드부터 시작하기

영업 운영팀이 두 구역의 영업 기회를 한눈에 보려 한다고 합시다. 첫 앱에는 단계별 영업 기회 건수, 마지막 갱신 시각, 상세 내용을 볼 CRM 링크를 넣으면 됩니다. 먼저 가상의 고객사로 동작을 확인합니다. 화면이 정확해지면 대시보드에 필요한 항목만 포함한 보고서나 데이터베이스 뷰를 읽는 권한을 연결합니다. 고객사 배정과 메모 관리는 CRM에서 계속 담당합니다. 첫 배포에서 업무 기록의 수정을 제외하고, 합계를 별도로 대조할 기준도 확보할 수 있습니다.

Cursor의 Apps 문서에 따르면 데이터 웨어하우스나 외부 리소스의 비밀 값은 앱 설정 또는 Apps 대시보드에 입력할 수 있습니다. Cursor는 에이전트가 그 값을 볼 수 없다고 설명합니다. 게시된 앱이 요청을 보낼 때는 그 인증 정보가 권한을 결정합니다. 연결 처리를 서버 코드에 두고 조회 범위를 좁히세요. 완성된 페이지와 네트워크 응답에서 서버에만 있어야 할 항목이 노출되는지도 확인합니다. 읽기 전용 인증 정보를 연결하려면 실제 계정이 대상 데이터에 대해 읽기 권한만 갖고 있어야 합니다. Cursor Apps 비밀 설정

세 사람의 관점에서 대시보드를 열어 보세요. 정상 이용자에게는 정확한 합계와 갱신 시각이 보여야 합니다. 다른 구역의 동료는 링크나 요청을 바꾸더라도 정책이 허용한 행만 볼 수 있어야 합니다. 공유 대상이 아닌 사람은 대시보드 데이터를 받기 전에 접근이 차단돼야 합니다. 만든 사람이 혼자 테스트하면 두 번째 문제가 특히 눈에 띄기 어렵습니다.

합계를 대조할 때는 기준 시스템의 특정 시점 데이터를 사용합니다. 기간, 시간대, 포함 기준, 각 구역의 정확한 예상 합계를 기록하세요. 차트에서 월요일 영업 기회가 누락된 것처럼 보여도 보고서가 시간 범위를 다르게 해석했을 수 있습니다. 첫 테스트에는 결과가 비어 있는 경우, 원본 시스템이 시간 내 응답하지 않는 경우, 데이터가 오래된 경우를 넣으세요. 마지막으로 성공한 갱신 시각과 명확한 오류 메시지를 보여주면 팀원이 시스템 장애와 실제 영업 기회 감소를 구분할 수 있습니다.

온보딩 포털이 저장할 항목은 하나씩 정합니다

기존 정책 페이지에 링크만 거는 포털이라면 새 데이터베이스가 필요 없을 수 있습니다. 완료 여부를 표시하는 체크리스트를 추가하면 상태를 저장해야 합니다. Cursor는 앱에 필요한 경우 Postgres를 마련하므로 두 번째 버전을 만들기가 쉬워집니다. 먼저 보존할 항목을 적어 보세요. 체크리스트 단계 ID, 완료 시각, 인증된 사용자를 일관되게 식별하는 값이면 충분할 수 있습니다. 관리자의 메모 사본, 정부 발급 신분증 번호, 직원 집 주소를 저장하면 체크리스트가 좋아지지 않고 다룰 위험만 커집니다. Cursor Apps 리소스

직원이 온보딩을 진행하는 데 필요한 데이터와 담당자가 여러 명의 진행 상황을 관리하는 데 필요한 데이터를 나눕니다. 직원은 자신에게 배정된 필수 문서의 읽기 완료 여부를 표시할 수 있습니다. 담당자는 같은 입사 그룹의 기한이 지난 단계를 봐야 할 수도 있습니다. 담당자 화면에 별도의 접근 규칙을 적용하고, 그 화면의 조회 동작도 따로 점검하세요. 두 화면은 같은 로그인 화면을 쓰더라도 필요한 권한 범위가 다릅니다.

내부 앱 하나에 필요한 세 가지 접근 확인. Telli.sh 자체 제작.

실제 온보딩 정보를 저장하기 전에 가상 직원 한 명과 테스트용 담당자로 소규모 시험을 진행할 수 있습니다. 출시 여부를 판단할 실패 조건을 분명히 정합니다. 직원이 브라우저 요청에서 ID를 바꾸더라도 다른 사람의 완료 상태를 덮어쓸 수 없어야 합니다. 같은 단계를 두 번 완료해도 중복 기록이 생기지 않고 최종 상태가 같아야 합니다. 동료의 실제 정보를 사용하지 않고도 동작을 확인하는 것이 이 시험의 목적입니다.

이런 앱에는 인수인계 체크리스트가 도움이 됩니다. 새 담당자가 접근 권한을 얻는 방법, 가이드 내용을 편집할 위치, 퇴직자의 접근 권한을 삭제할 담당자, 이미 기록된 완료 정보의 처리 방식을 적어 두세요. 변경이 실패했을 때 필요한 상태를 어떻게 복원할지도 정합니다. Cursor가 데이터베이스를 마련할 수 있고, 체크리스트에 맞는 복구와 보존 정책은 팀이 정합니다.

사용자 초대와 연동 키의 역할을 구분하기

Cursor의 Apps 문서는 공유 방식 세 가지를 설명합니다. 초대 전용 앱은 소유자와 지정된 사람 또는 그룹이 로그인해 사용할 수 있습니다. 팀 공유를 사용하면 로그인한 Cursor 팀원 전체가 접근할 수 있습니다. 공개 앱은 URL을 아는 누구나 열 수 있으며, Teams와 Enterprise에서는 관리자가 허용해야 공개 공유를 사용할 수 있습니다. 출시 공지에서는 개인 요금제의 공개 공유 기능을 소개합니다. 링크가 열린다는 사실만으로 접근 범위를 판단하기 어려우므로, Apps 대시보드에서 실제 공개 범위를 확인하세요. Cursor Apps 공유

같은 문서에는 자동 요청용 API 키도 나옵니다. 키를 HTTP 헤더에 넣으면 특정 개인이 보낸 요청이 아니라 자동화 요청으로 식별됩니다. 스크립트에서 앱을 호출할 때 유용하지만 예상치 못한 요청을 조사하는 방법도 달라집니다. 사용자 로그인과 API 키를 모두 지원한다면 자동화에는 필요한 앱 동작만 허용하세요. 키가 쓰이는 위치와 교체 담당자도 기록합니다. 중요한 동작이 모두 동료가 링크를 여는 것으로 시작한다면 첫 시험에서는 사용자 로그인만 사용해도 됩니다. Cursor Apps API 키

앱이 웨어하우스를 조회한다면 권한을 세 단계에서 시험해야 합니다. Cursor는 링크를 열 수 있는 대상을 정합니다. 앱은 이용자에게 허용할 동작과 데이터 행을 정합니다. 원본 시스템은 앱의 서비스 인증 정보가 읽을 수 있는 범위를 정합니다. 한 단계의 설정이 잘못되면 다른 단계의 제한이 피해를 줄일 수 있습니다. 내부 대시보드에 집계 수치만 필요한데도 CRM의 모든 기록을 읽을 권한을 주면 작은 앱 오류도 크게 번질 수 있습니다.

확인 절차는 간단합니다. 새 브라우저 세션에서 초대한 사람, 접근 권한 없이 로그인한 팀원, 로그인하지 않은 사람으로 각각 링크를 여세요. 접근 가능한 세션에서는 볼 수 있는 구역의 기록과 다른 구역의 기록을 하나씩 요청합니다. 스크립트가 키를 사용한다면 헤더 없이 보낸 요청과 폐기한 키로 보낸 요청이 모두 거절되는지 확인하세요. 각각 다른 종류의 오류를 드러내는 테스트입니다.

첫 배포의 범위를 좁히면 검토가 빨라집니다

1. 업무 하나와 이용 대상 하나를 정합니다. 대시보드라면 가상 기록으로 단계별 주간 영업 기회 합계와 갱신 시각, CRM 링크를 표시하도록 요청합니다. 포털이라면 가상 직원 계정으로 작은 체크리스트를 만들어 보세요.
2. 클라우드 에이전트를 시작하고 앱을 만들어 달라고 명시합니다. 나중에 운영을 맡을 사람이 접근할 수 있는 저장소를 사용하세요. 담당자가 경로, 데이터 모델, 오류 처리 방식을 설명할 수 있을 정도로 첫 변경을 작게 유지합니다.
3. 무엇을 저장하고 어떤 요청에서 수정할 수 있는지 명시합니다. 가상 데이터로 검증한 뒤에만 앱 설정에서 범위가 좁은 인증 정보를 연결합니다. 에이전트에게 인증 정보를 쓰는 곳과 접근 대상을 확인하는 지점을 보여 달라고 합니다.
4. 게시 전 검토를 실행하고 결과를 확인합니다. URL을 정해 직접 게시하고 필요한 최소 그룹에 공유합니다. 동료가 업무에 쓰기 전에 배포된 링크에서 허용과 거절이 각각 의도대로 동작하는지 확인하세요.
5. 앱 담당자, 앱이 호출하는 외부 서비스, 앱을 내릴 수 있는 담당자를 기록합니다. 공개 범위, 커넥터, 인증 정보가 바뀌면 핵심 확인을 다시 진행합니다. 앱이 잠시 중단됐을 때 동료가 사용할 수 있는 대체 링크나 절차도 둡니다.

에이전트가 만들 수 있는 기능을 첫 버전에 모두 담을 필요는 없습니다. 계산 방식에 이견이 있는 화면 여섯 개보다 매일 아침 믿을 만한 숫자 하나를 보여주는 대시보드가 더 유용할 수 있습니다. 잘 관리된 온보딩 체크리스트도 담당자 화면을 나중으로 미뤄도 반복 안내를 줄일 수 있습니다. 첫 배포를 작게 하면 운영 담당자가 실제로 어떤 변경, 권한 요청, 지원 문의가 들어오는지 살펴볼 수 있습니다.

평소처럼 일하는 한 주를 기준으로 결과를 살펴보세요. 따로 알리지 않아도 동료가 얼마나 자주 앱을 열고, 수치에 의문이 생길 때 출처를 찾을 수 있고, 문제가 생기면 담당자가 얼마나 빨리 고치는지 관찰합니다. 하루 몇 분씩 절약하는 앱도 충분히 쓸모가 있습니다. 여전히 스프레드시트를 열어 확인한다면 새 앱의 어떤 결과를 아직 믿기 어려운지 알아보세요.

Cursor의 새 기능으로 이런 실험을 시작하기가 쉬워졌습니다. 11월 5일 발표에서는 앱 제작, 데이터베이스, 인증, 호스팅, 공유 링크를 한 흐름으로 묶었습니다. 이전에는 호스팅 담당자를 찾거나 로그인 화면을 준비하다가 실험이 멈출 수도 있었습니다. 이제는 누가 쓰고, 어떤 데이터를 다루고, 어떤 조건에서 배포할지 명확히 설명하는 데 더 많은 판단이 필요합니다. 결과물은 동료가 쓸 수 있고 담당자가 관리할 줄 아는 링크입니다. Cursor 출시 공지

출처

• 2026년 11월 5일 Cursor Live Apps 출시
• 설정, 공유, 관리 기능을 설명하는 Cursor Apps 문서

---

내부 도구를 만들며 나눈 대화와 결정을 검색할 수 있게 정리하려면 Telli.sh 계정을 만들어 보세요.