Lovable로 만든 앱, 데이터가 유출되면 책임은 누구에게 있습니까?

제품 관리자가 내부 대시보드가 필요합니다. 티켓을 제출하고 엔지니어링 팀의 처리를 한 분기 기다리는 대신, Lovable을 열어 원하는 것을 평이한 영어로 설명하고 회사의 Google Workspace에 연결한 다음, 같은 날 오후에 작동하는 앱을 배포합니다. 이 앱은 Drive를 읽고, 몇 개의 스프레드시트를 가져오며, 주간 요약을 이메일로 보냅니다. 잘 작동합니다. 모두가 만족합니다.

하지만 6개월 후 보안 심사자나 규제 기관이 던질 질문, 즉 그 앱이 다루는 데이터를 어떻게 처리하는지에 대한 책임은 누구에게 있는가라는 질문을 아무도 묻지 않습니다.

답은 코드를 생성한 플랫폼이 아닙니다. 그것을 배포한 회사입니다. 이 글에서는 "AI로 만들었다"는 것이 방어 논리가 될 수 없는 이유, AI로 만든 앱에서 구체적으로 무엇이 잘못되는지, 그리고 문제가 격앙된 어조로 제기되기 전에 어떻게 가시성을 확보할 수 있는지 설명합니다.

"AI로 만든 앱"이 실제로 의미하는 것

Lovable, Base44, Bolt.new, Cursor를 비롯해 점점 늘어나고 있는 도구들은 자연어 프롬프트만으로 실제 웹 애플리케이션을 만들고 배포할 수 있게 해주는 새로운 범주의 도구입니다. 흔히 "바이브 코딩(vibe coding)" 플랫폼이라고 불립니다. 매력은 분명합니다. 개발자가 아닌 사람도 이전에는 팀 전체가 필요했던 결과물을 만들어낼 수 있으며, 이를 몇 시간 안에 해낼 수 있습니다.

이러한 앱들은 장난감이 아닙니다. 실제 사용자에게 배포되며, 일반적인 OAuth 승인을 통해 Google Workspace, Salesforce, 내부 데이터베이스 등 실제 회사 시스템에 연결됩니다. 데이터의 관점에서 볼 때, 프롬프트로 오후에 만든 앱과 엔지니어링 팀이 몇 달에 걸쳐 만든 앱은 동일하게 보입니다. 둘 다 액세스 토큰을 보유하고 있으며, 둘 다 해당 토큰이 허용하는 범위 내에서 데이터를 읽을 수 있습니다.

이 대칭성이 문제의 핵심입니다. AI 빌더를 매력적으로 만드는 속도는, 누구도 그 데이터로 무엇을 하는지 검토하지 않은 채 앱이 민감한 데이터에 도달하게 만드는 그 속도와 동일합니다.

AI로 만들었다는 것과 안전하다는 것은 다릅니다

여기서는 정확하고 공정하게 짚어볼 필요가 있습니다. Lovable이나 Base44로 만든 앱이 본질적으로 안전하지 않은 것은 아닙니다. 이러한 플랫폼들은 충분히 합리적인 애플리케이션을 만들어낼 수 있으며, 실제로 많은 경우가 그렇습니다. 위험은 AI가 나쁜 코드를 작성한다는 것이 아닙니다. 위험은 거버넌스이며, 이는 세 가지 예측 가능한 방식으로 드러납니다.

배포자가 코드를 읽는 경우는 거의 없습니다. 바이브 코딩의 전체 가치 제안은 바로 그렇게 하지 않아도 된다는 것입니다. 그래서 앱을 배포한 사람은 종종 데이터를 어떻게 저장하는지, 민감한 필드를 로그로 남기는지, 정보를 어디로 전송하는지, 무엇을 얼마나 보관하는지 말하지 못합니다. 책임을 지는 당사자가 자신이 책임지는 대상에 대해 가장 적은 가시성을 가지고 있는 것입니다.

액세스 권한은 광범위하고 눈에 보이지 않습니다. AI 빌더는 데모가 작동하도록 하는 범위(scope)를 요청하며, "작동하게 만든다"는 것은 종종 광범위한 읽기 액세스를 의미합니다. 단 하나의 폴더만 읽으면 되었던 내부 대시보드가 Drive 전체에 대한 읽기 액세스를 보유하게 될 수 있습니다. 이 승인은 일반적인 OAuth 동의 화면을 통해 이루어졌기 때문에, 누구의 보안 레이더에도 나타나지 않았습니다. 이는 정의상 섀도 IT입니다.

문서화된 데이터 처리 정책이 없습니다. 직접 구축한 프로덕션 시스템의 보존 정책을 물으면 보통 답을 얻을 수 있습니다. 하지만 지난 화요일 동료가 생성한 앱의 보존 정책을 물으면 기록된 것이 아무것도 없습니다. 데이터 보호법 하에서 "데이터를 얼마나 보관하는지 모른다"는 것은 중립적인 답변이 아닙니다. 그것은 하나의 지적 사항(finding)입니다.

왜 회사가 아니라 플랫폼이 책임을 지지 않는가

여기서 사람들이 놀라는 부분이 나옵니다. AI로 만든 앱이 데이터를 잘못 처리했을 때, 법적·규제적 책임은 그것을 생성한 AI 빌더가 아니라 그것을 배포한 조직에게 돌아갑니다.

이는 현재 AI 법 전반을 재편하고 있는 것과 동일한 책임 전환입니다. EU의 일반 데이터 보호 규정(GDPR) 하에서, 개인 데이터 처리의 목적과 방법을 결정하는 주체가 데이터 컨트롤러이며, 컨트롤러는 적법한 처리 근거, 데이터 최소화, 보관 제한, 그리고 이 모든 것을 입증할 의무를 부담합니다. 귀사가 고객 데이터를 처리하는 앱을 배포하면, 귀사가 컨트롤러입니다. 빌더 플랫폼은 최대해봐야 귀사가 사용한 도구일 뿐입니다.

2026년의 더 넓은 법적 환경도 같은 방향을 가리킵니다. 법원들은 AI 시스템을 사용하는 회사가 그 행동에 책임을 진다는 태도를 보이기 시작했습니다. 미국의 *Mobley v. Workday* 소송은 대리(agency) 이론에 근거하여 진행되었고, 이후 전국적 집단소송(collective action)에 대한 조건부 승인을 받았습니다. 독일에서는 OLG 함(Hamm) 고등법원이 AI 시스템이 고객에게 전달하는 정보에 대한 책임을 다루었으며, 일반적인 "보증 없음" 면책 조항만으로는 배포 회사가 보호받지 못한다는 신호를 보냈습니다. EU AI 법은 여기에 배포자 특유의 의무를 추가로 부과하며, 고위험 사용에 대해서는 상당한 처벌이 따릅니다. 이러한 변화에 대해서는 AI 에이전트가 데이터를 유출했을 때 책임은 누구에게 있는가에 대한 개요에서 자세히 다루고 있습니다.

공통된 맥락은 이렇습니다. AI로 만든 앱을 배포하는 것은 귀사가 내린 결정이며, 법은 결정에 책임이 따른다고 봅니다. AI가 코드를 작성했다는 사실은 회사 데이터에 그것을 연결하기로 선택한 주체가 누구인지에 대해 아무것도 바꾸지 않습니다.

구체적으로 본 사각지대

조각들을 맞춰보면 특정하고 흔한 실패 양상이 드러납니다.

• 비기술적인 직원이 AI 빌더로 앱을 만듭니다.
• 이 앱은 OAuth를 통해 Google Workspace에 연결되고 광범위한 범위(scope)를 부여받습니다.
• 이 앱은 연락처, 이메일 내용, 파일 등 고객 또는 직원의 개인 데이터에 접근합니다.
• 아무도 데이터 처리를 검토하지 않았고, 기록된 보존 정책도 없습니다.
• 보안팀은 이 앱에 대한 인벤토리 항목을 가지고 있지 않습니다. 검토 과정을 거치지 않았기 때문입니다.

각 단계는 개별적으로는 합리적입니다. 그러나 이 모든 것이 합쳐지면, 개인 데이터를 처리하고, 귀사가 법적으로 책임을 지며, 귀사의 보안팀이 존재하는지조차 모르는 애플리케이션이 만들어집니다. 이것이 바로 감사자가 캐묻고 침해 사고가 파고드는 틈입니다.

이 틈을 어떻게 메울 것인가

해결책은 AI 빌더를 금지하는 것이 아닙니다. 그 경주는 이미 끝났고, 생산성 향상은 실재합니다. 해결책은 가시성과 증거입니다. 어떤 AI로 만든 앱이 연결되어 있는지, 각각이 무엇에 접근할 수 있는지 알고, 그것들을 통제(governed)했음을 입증할 수 있어야 합니다.

8200.dev가 정확히 그 역할을 합니다. 귀사의 Google Workspace에 연결된 OAuth 앱을 발견하고, Lovable, Base44, Bolt.new, Cursor 및 유사한 서비스에서 비롯된 앱들을 앱 이름과 리디렉션 호스트(redirect-host) 시그니처, 그리고 이미 광범위한 범위를 보유한, 최근 생성되었으며 검증되지 않은 앱이라는 특유의 패턴을 통해 플래그로 표시합니다. 각 앱에 대해 빌더 플랫폼, 정확히 부여된 범위, 승인자, 그리고 위험 점수를 확인할 수 있으며, 이는 나머지 AI 에이전트 및 OAuth 앱과 함께 전용 AI로 만든 앱(AI-Built Apps) 뷰에 표시됩니다.

AI로 만든 앱이 고객 PII에 접근할 수 있거나, 문서화된 보존 정책 없이 광범위한 액세스를 보유한 경우, 특정 지적 사항(finding)이 발생합니다. 이를 통해 그 틈은 담당자가 있는 작업 항목이 되며, 감사 중에 갑작스럽게 발견되는 일이 없어집니다. 그리고 모든 AI로 만든 앱은 AI 에이전트 레지스트리에 기록될 수 있어, 어떤 커넥터도 도달하지 못하는 앱조차도 하나의 완전한 인벤토리에 나타납니다. 전체 기능 목록은 여기에서 확인하실 수 있습니다.

핵심은 귀사의 팀 속도를 늦추는 것이 아닙니다. 규제 기관, 감사자, 또는 고객의 보안 심사에서 질문이 제기될 때, 그에 답할 수 있도록 하는 것입니다. "AI로 만들었으니 그것은 플랫폼의 문제입니다"라는 답변은 방어 논리가 되지 못합니다. 대신 "여기 그 앱이 있고, 정확히 무엇에 접근할 수 있는지, 그리고 우리가 이를 검토했다는 증거가 여기 있습니다"라고 답할 수 있어야 합니다. 심사자들이 현재 무엇을 요구하는지 더 깊이 알아보려면 2026년 감사자가 AI 거버넌스에 요구하는 것을 참고하십시오.

AI로 만드는 것은 빠릅니다. 만든 것에 대해 책임을 지는 것은 선택 사항이 아닙니다. 이 둘은 단 하나로 조화될 수 있습니다. 바로 귀사의 AI로 만든 앱이 실제로 무엇에 접근할 수 있는지 아는 것입니다.

먼저 귀사의 Workspace에 이미 연결된 것이 무엇인지 확인하십시오. 무료 플랜에서도 AI로 만든 앱을 매핑하고, 그 액세스를 점수화하며, 첫 번째 증거 자료를 생성할 수 있습니다. 요금제를 확인하고 무료로 시작하십시오.

*이 글은 일반적인 정보 제공을 목적으로 하며, 법률 자문이 아닙니다. 귀사의 상황에 맞는 구체적인 조언은 자격을 갖춘 법률 전문가와 상담하시기 바랍니다.*