AI로 고객관리 앱 만드는 법, 막히는 곳

AI로 고객관리 앱을 만들 때 막히는 곳은 데이터 저장, 로그인과 권한, 배포, 개인정보의 네 군데입니다. 화면은 AI가 금방 그려 주지만 이 네 가지는 사람이 열어 확인해야 합니다. Lovable 공식 문서도 직접 확인하라고 안내합니다.

2026년 11월 5일 Lovable과 Replit의 영어 공식 문서, AppSheet 도움말, 개인정보 보호법 원문을 읽고 우리말로 옮겨 정리했습니다. 도구마다 규칙이 달라, 글 속 도구 이야기는 그 도구 이름을 붙여 적었습니다.

Lovable 공식 문서 Supabase 연동 페이지의 Security checks 화면 — 행 수준 보안(RLS) 정책 확인 안내 (2026년 11월 5일)

1. AI로 고객관리 앱을 만들 때 어디서 막히나요?

데이터가 어디에 쌓이는지, 누가 로그인해서 무엇을 볼 수 있는지, 배포하면 누가 열 수 있는지, 손님 정보를 어떻게 다룰지에서 막힙니다. 앞의 둘은 앱이 돌아가는 방식, 뒤의 둘은 책임의 문제입니다.

노코드 AI가 말로 설명한 앱의 표 구조를 먼저 짜 주고 사람이 검토하는 방식이라는 점은 앞서 노코드 AI, 말로 앱 만드는 방식 정리에서 다뤘습니다. 앱시트 도움말도 Gemini가 앱 구조를 돌려주면 사람이 검토하고 고칠 수 있다고 적었습니다.

AI로 고객관리 앱을 만들 때 막히는 네 곳 — 데이터 저장, 로그인과 권한, 배포, 개인정보

2. 데이터가 어디에 쌓이는지부터 확인합니다

Lovable 문서는 손님 표 같은 데이터를 말로 설명하면 AI가 표와 열, 관계를 설계해 준다고 적었습니다. 표를 바꾸는 작업은 SQL을 보여 주고 승인을 받은 뒤 실행하고, 데이터를 넣거나 바꾸기 전에도 승인을 묻습니다.

저장 위치는 둘 중에서 고릅니다. Lovable 기본 백엔드를 쓰면 백업과 서버 크기 같은 인프라를 Lovable이 관리하고, 자기 Supabase 프로젝트를 연결하면 그 부분을 직접 관리합니다. 요금도 Lovable 크레딧과 Supabase 구독으로 나뉩니다.

고객 관리에서는 이 선택이 곧 손님 정보가 어디에 놓이는지입니다. Replit 문서는 게시된 앱이 모두 미국에 호스팅된다고 적었고, 유럽 연합 호스팅은 기업 고객이 영업팀에 요청하는 방식이라고 했습니다. 어느 나라 서버에 두는 것이 법적으로 어떤 의미인지는 확인이 필요합니다.

3. 로그인과 권한은 켜 두었는지 직접 봅니다

Lovable 문서는 이메일과 비밀번호 로그인을 붙이고 로그인해야 대시보드가 열리게 해 달라는 요청을 예로 듭니다. 가입한 사용자는 Supabase 대시보드의 Authentication 아래에서 볼 수 있습니다.

테스트 중에는 이메일 확인을 꺼 두고 쓸 수 있지만, 실제 사용자에게 열기 전에는 다시 켜라고 적었습니다. 꺼 둔 채로 배포하는 일이 없도록 체크리스트에 넣어 두면 좋습니다.

권한은 표 단위로 확인해야 합니다. 같은 문서가 출시 전에 모든 표에 행 수준 보안(RLS) 정책이 있는지 보라고 하고, 직접 Supabase 대시보드에서 확인하라고 합니다.

Missing RLS policies are the most common way app data gets exposed.

위 문장은 Lovable 영어 문서 그대로이고, RLS 정책이 빠지는 것이 앱 데이터가 노출되는 가장 흔한 길이라는 뜻입니다. AI가 표를 만들어 줘도 누가 읽고 쓸 수 있는지는 사람이 확인해야 합니다.

4. 배포하면 누가 열 수 있는지 먼저 정합니다

Lovable은 게시 때 그 시점의 스냅숏만 배포하고, Free와 Pro 요금제의 공개 범위 기본값은 Public(주소를 아는 누구나)입니다. 손님 정보가 들어 있는 앱이라면 Public인 채 두지 말고 Invite only 같은 제한으로 바꿨는지 게시 창에서 봐야 합니다.

Lovable 공식 문서 게시 창의 공개 범위 — Public은 주소를 아는 누구나, Invite only는 로그인한 초대 대상만

Free와 Pro 요금제에서는 초대를 프로젝트당 최대 10명까지 할 수 있다고 적혀 있습니다. 그보다 많은 사람이 필요하면 요금제 조건을 따로 확인해야 합니다.

게시 창은 빠른 보안 검사 결과도 한 줄로 보여 주지만, 문제가 발견돼도 기본 설정에서는 게시를 막지 않는다고 합니다. 심각한 문제는 공개 전에 직접 고치라는 안내입니다.

5. 손님 정보를 받는 순간 책임이 생깁니다

AI가 만든 앱도 이름과 전화번호를 받으면 개인정보를 다루는 앱입니다. 개인정보 보호법 제29조는 개인정보처리자가 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적 · 관리적 · 물리적 조치를 해야 한다고 정합니다.

결제나 이메일 같은 외부 서비스의 비밀 키도 한 군데 정해 두고 관리해야 합니다. Lovable 문서는 이런 키를 Supabase 프로젝트에 저장하며 앱 코드와 저장소에는 나타나지 않는다고 적었습니다.

동의 문구와 파기 시점은 AI가 대신 정해 주지 않습니다. 순서는 고객 관리 시스템 구축, 직접 짜는 순서에, 처리방침은 개인정보처리방침 만들기 총정리에 있습니다. 실제 적용은 전문가 확인을 권합니다.

6. 배포 전에 확인할 네 가지

AI 코딩 도구를 고르는 기준은 AI 코딩 도구 총정리, 2026년 요금과 고르는 법에 정리했습니다. 어떤 도구를 쓰든 고객 관리 앱을 올리기 전에는 아래를 확인합니다.

데이터가 어디에 쌓이고 백업은 누가 관리하는가
모든 표에 읽기 · 쓰기 규칙(RLS 같은 정책)이 있는가
공개 범위가 Public이 아닌지, 테스트용 설정을 되돌렸는가
받는 항목, 동의 문구, 파기 시점을 정했는가

이 블로그를 운영하는 AiApp에서는 고객 표와 회원가입, 로그인, 예약, 문의 신청서, 문자와 알림톡을 붙인 고객 관리 웹앱을 대화로 만들어 실제 주소에 공개할 수 있습니다. 무료로 프로젝트 하나를 만들어 배포까지 해 볼 수 있지만, 무료는 배포 후 14일 공개이고 백엔드 기능과 문자 발송은 유료부터입니다.

직접 만들기 어려우면 AI 견적으로 맡길 때 비용을 먼저 볼 수 있습니다. 앞 글은 고객관리 앱시트, 막힐 때 볼 것이고, 다음은 미용실 고객 관리, 업종별로 고르기입니다. 전체 지도는 고객 관리 프로그램 만들기, 총정리입니다.

참고자료 (모두 2026년 11월 5일 확인)