체크리스트

바이브 코딩으로 만든 앱, 공유하기 전에 보안 점검하는 법

바로 답하면

AI로 만든 앱을 동료가 쓰기 전에 먼저 네 가지를 확인하세요. 회사 로그인을 거치지 않고는 아무도 들어올 수 없는지, 회사 계정만 들어오는지, 브라우저에서 실행되는 코드에 키가 없는지, 앱을 거치지 않고는 데이터베이스를 읽을 수 없는지. 그다음 앱 안에서 누가 무엇을 할 수 있는지, 내가 떠나면 누가 담당하는지 확인하세요.

AI로 만든 앱에서 생기는 유출은 대부분 교묘한 공격이 아니에요. 열린 문이에요. 공개 링크, 규칙이 꺼진 데이터베이스, 페이지에 들어간 키. 이 체크리스트는 앱을 만든 사람과 그 앱을 검토하는 IT 담당자를 위한 거예요. 항목마다 무엇이 잘못되는지, 평소 말로 확인하는 방법, TeamOnly가 맡는 것과 여전히 내가 챙겨야 하는 것을 적었어요.

마지막 업데이트 TeamOnly가 썼어요. 저희는 AI로 만든 사내 앱을 호스팅하고, 항목마다 저희가 돕는 부분과 돕지 않는 부분을 솔직하게 적었어요.

01왜 중요한가요

AI로 만든 앱에서 무엇이 잘못되나요

AI 툴은 앱이 돌아가게 만드는 데는 능숙해요. 그 앱이 또 누구에게 열려 있는지는 덜 신경 써요. 지난 2년 동안 나온 세 가지 결과가 그 패턴을 보여 줘요.

380,000
2026년 5월 보안 회사 Red Access가 Lovable, Base44, Netlify, Replit에서 찾은, 공개적으로 닿을 수 있는 자산의 수예요. 그중 약 5,000개에 민감한 회사 데이터가 있었고, 많은 수가 Google에 색인돼 있었어요.
1,645개 중 170개
2025년 3월에 확인한 Lovable 앱 중, 데이터베이스 접근 규칙이 없거나 잘못돼서 로그인 없이 누구나 Supabase 데이터베이스의 데이터를 읽거나 바꿀 수 있었던 앱의 수예요(CVE-2025-48757).
205,474
2025년의 한 연구에서 AI 모델 16개가 코드 샘플 576,000개에 걸쳐 제안한, 존재하지 않는 패키지 이름의 수예요. 공격자는 그 이름으로 패키지를 올려 두고 누군가 설치하기를 기다릴 수 있어요.

어느 것도 교묘한 공격자가 필요하지 않았어요. 문이 열려 있었어요. 좋은 소식이기도 해요. 열린 문은 확인하기 쉽고, 코드를 읽지 않아도 확인할 수 있어요.

2026년 10월 26일 확인. 출처: Security Boulevard on Red Access’s findings(2026년 5월), Matt Palmer, statement on CVE-2025-48757(2025년), Spracklen et al., “We Have a Package for You!”(USENIX Security 2025).

02체크리스트

링크를 공유하기 전에 확인할 11가지

순서대로 하세요. 앞쪽 항목은 낯선 사람을 막고, 뒤쪽 항목은 회사 안의 실수를 잡아요.

  1. 회사 로그인 전에는 아무것도 열리지 않아요

    무엇이 잘못되나요
    AI 툴은 로그인 화면을 앱의 페이지 하나로 만드는 경우가 많아요. 앱의 나머지 부분과 API는 그 페이지를 건너뛰거나 API를 직접 호출하는 누구에게나 여전히 답해요. Red Access는 주소에 닿기만 하면 누구에게나 관리자 권한을 주는 회사 앱을 찾았어요.
    직접 확인하기
    시크릿 창에서 앱을 여세요. 로그인 화면만 보이고 다른 건 아무것도 보이지 않아야 해요. 그다음 AI 툴에게 물어보세요. “모든 API 경로를 나열하고, 로그인 없이 작동하는 게 어떤 건지 알려 줘.” 답은 “없음”이어야 해요.
    TeamOnly에서는
    처리돼요. 모든 앱의 모든 요청은 내 코드가 실행되기 전에 확인되고, API 호출도 마찬가지라 세션이 없으면 401을 받아요. 앱을 공개로 바꾸는 설정은 없어요.
  2. 회사 계정만 들어와요

    무엇이 잘못되나요
    “Google로 로그인”은 기본적으로 개인 Gmail을 포함해 어떤 Google 계정이든 들여보내요. Google의 hd 설정은 계정 선택 화면만 좁혀 줄 뿐이고, 요청이 바뀔 수 있어서 Google도 이것에 의존하지 말라고 경고해요. 도메인은 서버에서 확인해야 해요.
    직접 확인하기
    개인 Gmail이나 Outlook 계정으로 로그인해 보세요. 돌려보내져야 해요. AI 툴에게 서버가 이메일 도메인을 어디서 확인하는지, Google이 서명한 토큰을 확인하는지 아니면 브라우저가 보낸 값을 확인하는지 물어보세요.
    TeamOnly에서는
    처리돼요. 동료들은 회사 Google, 회사 Microsoft, 또는 회사 이메일로 받은 코드로 로그인해요. 검증된 로그인 토큰의 도메인을 회사 도메인과 대조하고, 개인 계정은 거부해요.
  3. 회사 안에서도 맞는 사람만

    무엇이 잘못되나요
    급여, 평가, 고객 데이터가 담긴 앱이 기본값이라는 이유로 회사 전체에 공유돼요. 아니면 AI가 아무도 업데이트하지 않는 허용 목록을 코드에 직접 만들어요.
    직접 확인하기
    물어보세요. 회사의 모든 사람이 이 데이터를 봐야 하나요? 아니라면 봐야 하는 사람의 이름을 적고, 그 목록 밖의 사람이 돌려보내지는지 확인하세요.
    TeamOnly에서는
    처리돼요, 선택은 내가 해요. 접근 범위는 회사 전체나 지정한 목록이고, 대시보드나 npx teamonly access only priya@acme.com으로 정해요. 요청마다 확인하기 때문에 누군가를 빼면 1분 안에 적용돼요.
  4. 공개 링크도, 검색 결과도 아니에요

    무엇이 잘못되나요
    일부 앱 빌더는 비공개를 고르지 않으면 공개 주소에 게시해요. 공개 앱은 발견돼요. Red Access는 노출된 회사 앱 중 많은 수가 Google과 다른 검색 엔진에 색인돼 있었다고 보고했어요.
    직접 확인하기
    Google에서 site: 뒤에 앱 주소를 붙여 검색하세요. 앱을 만든 플랫폼에서 프로젝트 공개 설정을 확인하세요. 공개로 돼 있다면 다른 무엇보다 먼저 바꾸세요.
    TeamOnly에서는
    처리돼요. 앱은 로그인 화면 뒤의 yourapp.yourcompany.teamonly.app에 있어요. 로그인 화면을 포함한 모든 응답이 검색 엔진에 색인하지 말라고 알리고, 로그인 화면에는 앱 이름과 로그인 방법만 보여요.
  5. 브라우저에서 실행되는 코드에 키가 없어요

    무엇이 잘못되나요
    AI 툴은 API 키를 React 코드나 VITE_, NEXT_PUBLIC_으로 시작하는 변수에 넣어요. 브라우저로 보내지는 건 앱을 여는 누구나 읽을 수 있어요. Supabase는 secret 키가 모든 데이터베이스 규칙을 건너뛰기 때문에 절대 브라우저에 두면 안 된다고 해요.
    직접 확인하기
    AI 툴에게 물어보세요. “화면 코드나 VITE_ 변수, 커밋된 .env 파일에 키, 토큰, 비밀번호가 있어?” 브라우저에서 개발자 도구를 열고 불러온 파일에서 key, secret, sk_를 검색하세요. 키가 한 번이라도 노출됐다면 그 키를 발급한 서비스에서 바꾸세요.
    TeamOnly에서는
    일부 처리돼요. 키는 npx teamonly secrets set NAME으로 코드 밖에 저장되고, 앱의 서버 코드만 읽을 수 있어요. TeamOnly가 추가하는 안내는 AI 툴에게 VITE_ 키를 절대 쓰지 말라고 해요. 내가 직접 코드에 키를 붙여 넣는 걸 막지는 못하니, 그래도 확인하세요.
  6. 앱을 거치지 않고는 데이터베이스를 읽을 수 없어요

    무엇이 잘못되나요
    Supabase 같은 서비스에서는 브라우저가 데이터베이스와 직접 이야기하고, 접근 규칙(행 수준 보안)이 무엇을 볼 수 있는지 정해요. 그 규칙이 꺼져 있거나 잘못돼 있으면, 공개 키를 가진 누구나 테이블 전체를 읽거나 바꿀 수 있어요. Lovable 사례가 바로 그거였어요.
    직접 확인하기
    Supabase에서 Advisors를 열고 Security Advisor로 가세요. “RLS disabled in public” 오류가 있다면 누구나 읽을 수 있는 테이블이 있다는 뜻이에요. 규칙이 있는 것만으로는 부족해요. 일반 동료로 로그인해서 다른 사람의 기록을 열어 보세요.
    TeamOnly에서는
    외부인에 대해서는 처리돼요. 각 앱의 데이터베이스는 인터넷에 자체 주소가 없어요. 로그인한 뒤 앱의 서버 코드를 통해서만 닿을 수 있어요. 로그인한 사람마다 어떤 행을 볼 수 있는지는 여전히 앱의 코드가 제대로 해야 해요(8번 항목 참고).
  7. 앱마다 데이터가 분리돼 있어요

    무엇이 잘못되나요
    더 빨라서 여러 앱이 데이터베이스 하나나 저장소 버킷 하나를 같이 써요. 그러면 한 앱의 키나 버그가 전부를 열어요.
    직접 확인하기
    물어보세요. 이 앱과 같은 데이터베이스, 저장소, 키를 쓰는 다른 앱이 있나요? 있다면 가장 약한 앱이 전부의 안전을 정해요.
    TeamOnly에서는
    처리돼요. 앱마다 첫 배포 때 자체 데이터베이스, 파일 저장소, 시크릿을 받고, 세션 쿠키는 그 앱의 주소에 묶여요. 앱끼리 서로의 데이터에 닿을 수 없어요.
  8. 누가 무엇을 할 수 있는지, 서버에서 확인해요

    무엇이 잘못되나요
    AI가 대부분의 사람에게 승인 버튼을 숨기지만, 승인 경로는 로그인한 누구에게나 열어 둬요. 아니면 서버가 브라우저가 보낸 역할이나 이메일을 믿어요. 접근 제어 실패는 OWASP Top 10의 1위예요. 확인하지 않은 입력도 비슷한 문제예요. 음수 금액, 텍스트 상자로 만든 SQL 쿼리 같은 것들이요.
    직접 확인하기
    일반 동료로 로그인해서 관리자만 해야 하는 일을 해 보세요. AI 툴에게 물어보세요. “API 경로마다 누가 호출할 수 있고, 서버의 어디서 그걸 확인해? 모든 데이터베이스 쿼리가 플레이스홀더를 써?”
    TeamOnly에서는
    일부 처리돼요. 앱은 검증된 사람(ctx.user)과 대시보드에서 준 역할(ctx.user.roles)을 받고, 위조된 신원 헤더는 제거돼요. 안내는 AI 툴에게 쿼리 플레이스홀더를 쓰고 서버에서 입력을 확인하라고 해요. 경로마다 역할을 확인하는 건 앱의 코드이고, TeamOnly는 그걸 검토하지 않아요.
  9. 모든 패키지가 진짜이고 필요해요

    무엇이 잘못되나요
    AI 툴은 가끔 존재하지 않는 패키지를 제안해요. 공격자가 그 이름으로 패키지를 올리기 때문에, 설치하면 낯선 사람의 코드가 내 앱 안에서 실행돼요.
    직접 확인하기
    package.json을 여세요. 모르는 이름이 있으면 npmjs.com에서 찾아보세요. 진짜 패키지는 이력, 연결된 소스 저장소, 꾸준한 다운로드가 있어요. 배포하기 전에 npm audit을 실행하고, 앱이 더 이상 쓰지 않는 패키지는 지우세요.
    TeamOnly에서는
    처리되지 않아요. TeamOnly는 패키지를 검사하지 않아요. 앱은 자기 데이터와 키에만 닿을 수 있어서 나쁜 패키지가 건드릴 수 있는 범위가 제한되지만, 그 앱 안에서는 여전히 모든 걸 읽을 수 있어요.
  10. 누가 무엇을 바꿨는지 남는 기록

    무엇이 잘못되나요
    무언가가 승인되거나, 지워지거나, 바뀌었는데 누가 했는지 아무도 몰라요. AI로 만든 앱은 요청하지 않으면 이력을 거의 남기지 않아요.
    직접 확인하기
    AI 툴에게 각 기록을 누가 언제 만들고 마지막으로 바꿨는지 남기고, 승인과 삭제에 대한 이력 테이블을 두라고 하세요. 직접 해 보세요. 기록을 바꾸고 거기에 내 이름이 있는지 확인하세요.
    TeamOnly에서는
    일부 처리돼요. 대시보드에 모든 앱의 모든 배포가 누가 언제 했는지와 함께 보이고, 실시간 로그도 있어요. 로그는 실시간이고 저장되지 않아요. 로그인과 접근 변경에 대한 감사 로그는 Business 요금제에 있고, 함께 설정해 드려요. 앱 안의 이력(누가 경비를 승인했는지)은 앱이 할 일이에요.
  11. 담당자, 백업, 퇴사자 대비

    무엇이 잘못되나요
    만든 사람이 떠나도 앱이 그 사람의 개인 계정으로 계속 돌아가거나, 그 사람의 카드가 해지되면 멈춰요. 아니면 잘못된 변경으로 테이블이 지워졌는데 사본이 없어요.
    직접 확인하기
    앱의 담당자와 넘겨받을 사람을 적어 두세요. 코드는 회사 Git 저장소에 두세요. AI 툴에게 주요 테이블의 CSV 내보내기를 추가해 달라고 하고, 직접 해 보세요.
    TeamOnly에서는
    일부 처리돼요. 앱은 회사 소유이고, 관리자가 앱을 새 담당자에게 넘길 수 있어요. 누군가의 회사 계정을 끄면 새 로그인이 막혀요. 이미 로그인한 사람은 세션이 끝날 때까지 남아 있고, 그 기간은 관리자가 8시간에서 30일 사이로 정해요. 지금은 대시보드에 백업이나 내보내기 버튼이 없으니, 내보내기를 앱 안에 만들어 두세요.

03인쇄해 두세요

1분 점검

예/아니요 질문 11개예요. “아니요”가 나오면 그게 다음에 고칠 거예요.

이 앱을 공유하기 전에

  1. 시크릿 창에서 회사 로그인 화면만 보이고 다른 건 보이지 않아요.
  2. 개인 Gmail이나 Outlook 계정은 돌려보내져요.
  3. 이 데이터가 필요한 사람만 열 수 있어요.
  4. 앱 주소로 site: 검색을 하면 아무것도 나오지 않아요.
  5. 브라우저 코드나 저장소에 키, 토큰, 비밀번호가 없어요.
  6. 앱을 거치지 않고는 데이터베이스에 닿을 수 없어요.
  7. 이 앱의 데이터와 키를 다른 앱과 같이 쓰지 않아요.
  8. 일반 동료는 관리자만 해야 하는 일을 할 수 없어요.
  9. package.json의 모든 패키지가 진짜이고 아직 쓰여요.
  10. 기록에 누가 만들고 바꿨는지 보여요.
  11. 내가 떠나면 이 앱의 담당자가 누구인지 다른 사람이 알고 있고, 데이터를 내보낼 수 있어요.

텍스트로 필요하세요? 이 페이지의 Markdown 버전에 바로 붙여 넣을 수 있는 목록이 있어요(영어).

04IT 팀용

누군가 만든 앱 검토하기

만든 사람과 화면을 공유하며 15분이요. 코드를 한 줄씩 읽는 게 아니라 설정을 확인하는 거예요.

  1. 어디에 있고 누가 닿을 수 있나요

    주소를 받으세요. 로그인하지 않은 기기와 개인 계정으로 열어 보세요. 어느 플랫폼이 호스팅하고 누구 계정이 비용을 내는지 물어보세요. 개인 계정이라면 그게 가장 먼저 바꿀 거예요.

  2. 어떤 데이터를 담나요

    무엇이 들어가고 어디서 오는지 물어보세요. 고객 개인정보, 결제 데이터, 건강 데이터, 다른 시스템의 비밀번호가 있다면 기준이 높아지고, 앱을 지정한 목록으로 제한해야 할 수도 있어요.

  3. 키는 어디에 있나요

    앱이 호출하는 외부 서비스를 모두 적으세요. 키는 각각 호스팅 서비스의 시크릿 설정에 있어야 하고, 앱에 필요한 범위로 제한돼야 하며, 다른 앱과 같이 쓰지 않아야 해요. 코드나 채팅에 한 번이라도 들어간 키는 바꾸세요.

  4. 누가 무엇을 할 수 있나요

    만든 사람이 일반 사용자로 로그인하거나 동료에게 부탁해서 관리자 동작을 해 보세요. 만든 사람에게 AI 툴로 API 경로마다 어디서 역할을 확인하는지 나열하게 하세요. 여기서 빈틈이 보이면 앱의 코드에서 고쳐요.

  5. 패키지와 코드

    package.json을 같이 보고 npm audit을 실행하세요. 코드가 만든 사람의 노트북에만 있지 않고 회사 Git 저장소에 있도록 요청하세요.

  6. 담당자, 그리고 그 사람이 떠나는 날

    앱, 담당자, 대체 담당자, 데이터, 사용자를 앱 목록에 적으세요. 담당자가 떠나면 어떻게 할지 합의하세요. 섀도 AI 앱 가이드에 그대로 복사해 쓸 수 있는 한 페이지짜리 정책이 있어요.

05FAQ

자주 묻는 질문

모든 질문과 답변

바이브 코딩으로 만든 앱을 동료와 공유해도 안전한가요?

안전할 수 있어요. 흔한 문제는 앱이 어디에 있고 어떻게 설정됐는지예요. 공개 링크, 제대로 된 로그인 없음, 브라우저에 들어간 키, 꺼진 데이터베이스 규칙. 각각 몇 분이면 확인할 수 있어요. 링크를 보내기 전에 이 페이지의 체크리스트를 따라 해 보세요.

바이브 코딩 앱에서 가장 큰 보안 위험은 무엇인가요?

로그인하지 않고도 누구나 닿을 수 있는 데이터예요. 보통 두 가지 중 하나로 생겨요. 앱이 로그인 없이 공개 링크에 있거나, 데이터베이스가 요청에 직접 답하는데 접근 규칙(Supabase의 행 수준 보안)이 꺼져 있는 경우예요. 둘 다 AI가 나쁜 코드를 써서가 아니라 설정 문제예요.

Supabase anon 키를 브라우저에 넣어도 안전한가요?

anon 키나 publishable 키는 브라우저에 두라고 만든 키예요. 다만 행 수준 보안이 그 키로 닿을 수 있는 범위를 제한하기 때문이에요. 테이블에 행 수준 보안이 꺼져 있으면, 그 키를 가진 누구나 읽고 바꿀 수 있어요. secret 키나 service_role 키는 절대 브라우저에 두면 안 돼요. 모든 규칙을 건너뛰어요.

“Google로 로그인”만으로 앱을 우리 회사로 제한할 수 있나요?

그것만으로는 안 돼요. 기본적으로 개인 Gmail을 포함해 어떤 Google 계정이든 로그인할 수 있어요. Google의 hd 설정은 계정 선택 화면만 좁혀 줄 뿐이고, Google도 이것에 의존하지 말라고 해요. 앱의 서버가 요청마다 검증된 로그인 토큰의 도메인을 확인해야 해요.

내 앱이 Google에 색인됐는지 어떻게 확인하나요?

Google에서 site: 뒤에 앱 주소를 붙여 검색하세요. 예를 들어 site:myapp.lovable.app. 페이지가 나오면 앱이 공개돼 있고 색인된 거예요. 앱을 비공개로 바꾸거나 회사 로그인 뒤로 옮기고, 도메인을 소유하고 있다면 Search Console의 삭제 툴로 Google에 페이지 삭제를 요청하세요.

AI 툴에게 안전한 코드를 쓰라고 말해야 하나요?

네, 한 번 부탁하는 것보다 항상 적용되는 안내를 주는 게 좋아요. 프로젝트의 규칙 파일(CLAUDE.md, AGENTS.md, Cursor 규칙)이 키를 어디에 두는지, 데이터베이스 쿼리를 어떻게 쓰는지, 역할을 어디서 확인하는지 툴에 알려 줘요. TeamOnly 앱에는 npx teamonly init이 이걸 추가해요. 그래도 확인은 직접 하세요. 안내는 실수를 줄여 줄 뿐 없애 주지는 않아요.

TeamOnly가 내 앱 코드의 보안 문제를 검사하나요?

아니요. TeamOnly는 모든 앱 앞에 회사 로그인을 두고, 앱마다 데이터와 키를 분리하고, 앱이 검색 엔진에 나오지 않게 해요. 코드를 검토하거나, 패키지를 검사하거나, 앱 안의 규칙을 확인하지는 않아요. 체크리스트의 그 항목들은 여전히 내 몫이에요.

AI로 만든 앱을 승인하기 전에 IT 팀은 무엇을 확인해야 하나요?

어디에 호스팅되고 누가 닿을 수 있는지, 로그인이 어떻게 제한되는지, 키가 어디에 있는지, 어떤 데이터를 담는지, 담당자가 누구인지, 그 사람이 떠나면 어떻게 되는지예요. 이 페이지의 “IT 팀용” 섹션은 만든 사람과 함께 15분이면 끝나는 짧은 검토예요.

얼리 액세스

열린 문은 플랫폼이 닫게 하세요.

명령어 하나로 배포하면 앱이 회사 로그인 뒤에, 검색에서 빠진 채로, 자체 데이터베이스와 시크릿과 함께 올라가요. 카드 없이 14일 무료로 써 보세요.

14일 무료 체험하기아니면 지금 구독하기

무료 체험에는 카드가 필요 없어요. 그 뒤로 월 $19부터, 언제든 해지할 수 있어요.

아직 준비가 안 됐나요? 소식 받기

회사 이메일을 써 주세요. 메일은 가끔, 보낼 만한 소식이 있을 때만 보내요.

질문은 hello@teamonly.dev로 보내 주세요. 사람이 직접 답해요.