AI 코딩으로 만든 CRM, 고객 개인정보는 어디서 새는가 [2026]

고객 이름과 연락처, 상담 메모와 구매 이력이 한곳에 모이는 CRM은 회사의 고객 개인정보가 집중되는 시스템입니다. 그 CRM을 AI 코딩 도구로 직접 만들어 쓰는 회사가 나오고 있습니다. 화면은 말한 대로 금방 나오지만, 누가 어떤 고객을 볼 수 있는지, 누가 언제 무엇을 내려받았는지 같은 요구사항은 따로 요청하고 확인하지 않으면 빠지기 쉽습니다.

월스트리트저널은 올해 3월 CRM을 AI 코딩으로 직접 만드는 회사들을 다뤘고, 영국 국가사이버보안센터(NCSC)의 아키텍처 담당 CTO는 같은 달 블로그에서 AI가 만든 코드가 CRM 같은 기업용 소프트웨어 구독을 일부 대신하게 될 것으로 내다봤습니다. 국내 개발 커뮤니티에도 AI 코딩으로 만든 CRM을 납품했다는 후기가 올라옵니다. 직원 수만큼 나가는 구독료를 줄이고 우리 업무에 꼭 맞는 화면을 갖고 싶은 마음은 자연스럽고, 이 글도 그 선택을 말리려는 글은 아닙니다. 다만 AI로 만든 CRM이 실제로 어디서 새는지, 국내 법이 CRM에 요구하는 것을 어떤 기능으로 바꿔 만들어야 하는지, 고객 데이터를 넣기 전에 무엇을 어떤 순서로 확인해야 하는지는 만들기 전에 알고 있어야 합니다. 그 세 가지를 보안 점검 실무의 눈으로 정리했습니다.

왜 CRM부터 AI로 만들까

CRM은 AI 코딩과 잘 맞아 보이는 시스템입니다. 고객 목록과 상세 화면, 상담 기록 입력, 영업 단계별 현황판처럼 기능이 눈에 보이고, 데이터 구조도 고객과 담당자, 상담, 계약 정도로 단순합니다. 몇 시간 대화하면 그럴듯한 화면이 나오고, 매달 나가던 구독료가 사라집니다.

NCSC는 이 흐름을 인정하면서도 조건을 붙였습니다. AI가 만든 코드는 아직 개발자가 손볼 곳이 많고, 검토 없이 운영에 들어가는 코드나 실제로 없는 패키지 이름을 지어내 끌어오는 문제 같은 위험이 함께 온다는 것입니다. 변화의 속도도 고르지 않을 것이라고 했습니다.

여기에 CRM만의 사정이 더해집니다. CRM의 중요한 요구사항 상당수는 화면에 나타나지 않습니다. 영업 담당자는 자기 고객만 봐야 하고, 퇴사한 직원의 계정은 그날 막혀야 하며, 고객 명단을 통째로 내려받는 일은 기록이 남고 이유가 확인돼야 합니다. 이런 요구사항은 시연 화면에서 보이지 않고, 화면을 눌러 보는 것만으로는 빠졌는지조차 알기 어렵습니다.

보이는 기능은 요청한 대로, 보이지 않는 요구사항은 요청하지 않은 대로

보안 연구자 Joel Margolis는 5월 WIRED 인터뷰에서 AI 코딩 도구가 요청받은 일은 하지만, 안전하게 하라고 요청하지 않으면 굳이 그렇게 하지 않는다고 말했습니다. CRM에 옮겨 보면 이렇습니다. "고객 목록 화면을 만들어 줘"라고 하면 목록이 나옵니다. 목록이 만들어졌더라도 로그인한 사람의 담당 고객만 서버에서 걸러 보여 주는지는 따로 확인해야 합니다.

올해 나온 세 가지 조사는 이 간극이 얼마나 넓은지 보여 줍니다.

이스라엘 보안 기업 RedAccess는 Lovable, Replit, Base44, Netlify가 제공하는 도메인에 올라간 AI 제작 앱을 검색으로 찾아, 사실상 인증이 없는 앱 5,000여 개를 확인했다고 WIRED에 밝혔습니다. 그중 2,000개 가까이가 실제 개인·기업 정보로 보이는 데이터를 드러냈고, 고객의 이름과 연락처가 담긴 소매업체 챗봇 상담 기록도 있었다고 합니다. 플랫폼들은 공개 여부는 이용자가 정하는 설정이라고 반박했고, WIRED도 데이터가 모두 진짜인지는 확인하지 못했다고 적었습니다. 그래도 RedAccess 공동창업자 Dor Zvi가 짚은 지점은 기업이 새겨 둘 만합니다. 회사의 누구든 언제든 앱을 만들어 개발 절차나 보안 점검 없이 바로 업무에 쓸 수 있고, 실제로 그렇게 한다는 것입니다.

보안 기업 UpGuard는 9월 Supabase를 쓰는 약 30만 개 도메인을 조사해, 표를 바깥에서 그대로 읽을 수 있는 데이터베이스 16,326개를 찾았다고 발표했습니다. Supabase는 AI 코딩 에이전트가 앱을 만들 때 자주 쓰는 클라우드 데이터베이스이고, 찾은 데이터베이스의 절반 이상에서 개인정보로 보이는 항목이 나왔습니다. 그중 미국의 한 발레파킹 업체 고객 관리 데이터베이스에는 고객 10만여 명의 전화번호, 4만 3천여 명의 이름과 이메일, 7만 8천여 건의 차량 번호가 있었고 방문 이력과 고객 생애 가치, 팁 내역, 직원이 적은 자유 메모까지 들어 있었습니다. CRM이 새면 무엇이 함께 나가는지를 그대로 보여 주는 사례입니다. UpGuard가 짚은 원인도 눈여겨볼 만합니다. 코딩 에이전트처럼 API로 표를 만들면 행 단위 접근 제어(RLS)가 기본으로 켜지지 않고, 켠 뒤에도 규칙과 키를 제대로 써야 데이터가 보호된다는 것입니다.

세 번째는 규모는 작아도 구조가 선명한 사례입니다. Tobias Brunner는 3월 개인 블로그에, 스위스의 한 의료 종사자가 AI로 직접 만든 환자 관리 앱을 살펴본 경험을 적었습니다. 앱은 HTML 파일 하나에 모든 코드가 들어 있었고, 데이터베이스에는 접근 제어가 없었으며, 로그인 확인은 전부 브라우저에서 도는 자바스크립트가 맡고 있었습니다. 그는 30분 만에 모든 환자 데이터를 읽고 쓸 수 있게 됐다고 썼습니다. 진료 녹음은 받아쓰기와 요약을 위해 외부 AI 서비스 두 곳으로 보내지고 있었습니다.

세 사례의 문제는 화면이 아니라 화면 뒤에 있었습니다. 데이터베이스가 브라우저에 직접 열려 있거나 로그인 확인이 브라우저에서만 이뤄지는 구조는, 화면을 눌러 보는 방식의 테스트로는 드러나지 않습니다. 요청을 직접 만들어 보내 봐야 보입니다.

AI로 만든 CRM에서 고객 정보가 새는 다섯 지점

CRM처럼 고객 데이터를 다루는 사내 시스템을 점검할 때 먼저 보는 곳은 정해져 있습니다. AI로 만든 시스템이라면 아래 다섯 지점부터 확인합니다.

1. 권한이 화면에만 있다

전형적인 모습은 이렇습니다. 관리자 메뉴는 관리자에게만 보이고, 영업 담당자 화면에는 자기 고객만 나옵니다. 그런데 그 걸러 내기를 브라우저가 합니다. 서버나 데이터베이스는 요청이 오면 고객 전체를 돌려주고, 화면이 그중 일부만 보여 주는 식입니다. 이 경우 브라우저 개발자 도구로 응답을 열거나 주소의 고객 번호를 하나 바꿔 보는 것만으로 남의 고객이 보입니다. 화면에 안 보였을 뿐, 데이터는 이미 브라우저까지 와 있었기 때문입니다.

여러 지점이나 고객사의 데이터를 한 시스템에 담는 CRM이라면 위험은 한 단계 커집니다. A 지점 직원이 B 지점 고객을 보는 문제는 메뉴를 숨겨서 막을 수 없고, 모든 조회와 수정에 '이 사람이 속한 조직' 조건이 서버에서 걸려 있어야 합니다.

권한은 표로 먼저 적어야 제대로 만들 수 있습니다. 역할(대표, 팀장, 담당자, 외부 협력사)과 동작(조회, 수정, 삭제, 내려받기, 문자 일괄 발송)을 가로세로로 놓고 칸마다 허용 여부를 정한 뒤, 그 표를 AI에게 그대로 주고 서버 쪽 검사로 구현하게 합니다. 확인은 서로 다른 권한의 계정 두 개로, 화면이 아니라 API를 직접 호출해서 합니다.

2. 데이터베이스가 브라우저에 열려 있다

AI 코딩 도구로 앱을 만들면 별도 서버 없이 브라우저가 클라우드 데이터베이스를 직접 부르는 구조가 되기 쉽습니다. 이 구조에서는 데이터베이스 접속용 공개 키가 웹페이지 코드에 들어가는 것이 정상이고, 대신 표마다 행 단위 접근 제어 규칙이 '이 사용자에게는 이 행만'을 지켜야 합니다. 규칙이 꺼져 있거나 사실상 모두에게 허용으로 적혀 있으면, 웹페이지에서 꺼낸 공개 키 하나로 고객 표 전체를 읽을 수 있습니다. UpGuard가 찾은 데이터베이스들이 이런 경우였습니다.

더 나쁜 경우는 모든 규칙을 건너뛰는 관리자용 키가 웹페이지 코드나 공개 저장소에 들어간 경우입니다. 이 키는 서버 안에서만 써야 합니다. 점검은 어렵지 않습니다. 배포된 웹페이지의 자바스크립트를 내려받아 키 형식의 문자열을 찾고, 로그인하지 않은 상태에서 그 키로 우리 고객 표가 조회되는지 확인합니다. 구체적인 확인 순서는 Supabase RLS 미설정·API 키 노출 자가 점검법에 정리해 두었습니다.

3. 내보내기 버튼 하나로 고객 명단이 나간다

CRM에서 엑셀 내보내기는 빠지지 않는 기능입니다. 동시에 고객 명단 전체가 파일 하나에 담겨 회사 밖으로 나갈 수 있는 가장 짧은 길이기도 합니다. 개인정보의 안전성 확보조치 기준은 이 지점을 직접 다룹니다. 화면 표시나 파일 생성처럼 개인정보를 출력할 때는 용도를 정하고 출력 항목을 줄여야 하고(제12조), 접속기록과 개인정보 다운로드 상황을 언제 어떻게 점검하고 이상이 있으면 어떻게 조치할지 내부 관리계획으로 정해 실제로 지켜야 합니다(제8조). 그래서 내보내기 기능을 만들 때는 화면과 함께 권한과 기록 요건도 명세하고 검증해야 합니다.

내보내기에 붙일 것은 세 가지입니다. 권한 있는 역할만 쓸 수 있게 하고, 한 번에 나가는 건수와 항목을 업무에 필요한 만큼으로 줄이고, 누가 언제 몇 건을 어떤 이유로 받았는지 남깁니다. 놓치기 쉬운 것이 하나 더 있습니다. 고객이 문의 양식에 '=', '+', '-', '@'로 시작하는 글을 넣으면, 내보낸 파일을 엑셀로 여는 순간 그 글이 수식으로 해석될 수 있습니다(CSV 수식 주입). 내보낼 때 셀 단위로 이런 값이 수식이 되지 않게 처리하고, 실제로 쓰는 엑셀 버전에서 열었다가 저장한 뒤 다시 열어도 안전한지 확인해야 합니다. OWASP는 엑셀이 저장과 재열기 과정에서 따옴표나 이스케이프 문자를 지워 막아 둔 수식이 다시 살아날 수 있다며, 모든 프로그램에 통하는 단일 처리법은 없다고 설명합니다. 앞에 작은따옴표를 붙이는 처리만으로 끝내면 안 되는 이유입니다.

4. 연동 키가 곧 회사의 이름이다

CRM은 혼자 일하지 않습니다. 문자와 알림톡, 이메일, 결제, 전자계약, 상담 녹취가 모두 API 키로 이어집니다. 이 키가 웹페이지 코드나 공개 저장소에 들어가면 피해는 데이터 유출에서 끝나지 않습니다. 문자 발송 키를 손에 넣은 사람은 회사가 등록해 둔 발신번호로 문자를 보낼 수 있고, 받는 고객은 그 문자가 진짜 회사에서 왔는지 가릴 방법이 없습니다.

연동 키는 서버에만 두고, 서비스마다 필요한 권한만 주고, 사용량과 발송량에 한도와 알림을 겁니다. AI 코딩 도구와 대화하면서 키를 붙여 넣은 적이 있다면, 그 키는 대화 기록이나 도구 설정 파일에 사본이 남았을 수 있다고 보고 바꾸는 편이 안전합니다. 코드 저장소로 키가 새는 경로는 AI 코딩 커밋 시크릿 유출 글에서 다뤘습니다.

5. CRM에 붙인 AI가 고객의 글을 명령으로 읽는다

요즘 CRM에는 AI 기능이 붙습니다. 문의 내용을 요약하고, 다음 할 일을 제안하고, 답장 초안을 씁니다. 그런데 이 AI가 읽는 문의 내용은 회사 밖의 누구나 써 넣을 수 있는 글입니다.

대표적인 CRM 제품에서도 이 문제가 실제로 확인됐습니다. 보안 기업 Noma Security는 2025년 9월, Salesforce의 AI 에이전트 Agentforce에서 ForcedLeak이라는 취약점을 공개했습니다. 웹사이트의 잠재고객 등록 양식(Web-to-Lead) 설명 칸에 숨겨 둔 지시가, 직원이 AI에게 그 고객을 물어보는 순간 실행돼 CRM 데이터를 밖으로 보낼 수 있었습니다. 데이터가 나간 통로는 허용 목록에 남아 있던 만료 도메인이었고, 연구진은 그 도메인을 약 5달러에 다시 사들였습니다. 심각도는 CVSS 9.4로 평가됐고, Salesforce는 AI의 출력이 신뢰하지 않는 주소로 나가지 못하게 막는 조치를 9월 8일 적용했습니다. SecurityWeek 보도에 따르면 올해 6월에는 Zenity Labs가 같은 제품에서 비슷한 경로의 결함 세 가지(SalesBleed)를 신고했고, Salesforce는 8월 19일까지 모두 고쳤다고 확인했습니다.

전담 보안 조직을 갖춘 회사의 제품에서도 이런 일이 있었다면, 문의 요약 기능을 직접 붙인 사내 CRM은 더 조심해야 합니다. 원칙은 두 가지입니다. 고객이 쓴 글은 AI에게 '읽을 자료'로만 넘기고, AI의 출력이 외부 주소를 부르거나 데이터를 내보내는 동작으로 이어지지 않게 막습니다. 그리고 고객 데이터를 외부 AI 서비스로 보낸다면 개인정보 처리방침의 처리위탁이나 국외 이전 항목에 반영해야 하는지 먼저 따집니다. 스위스 의료 앱에서 진료 녹음이 외부 AI 서비스로 보내지던 것과 같은 지점입니다. 사내 데이터에 AI를 연결할 때의 위험은 사내 AI 챗봇 RAG 정보유출 자가점검에서 더 다뤘습니다.

법이 요구하는 것을 CRM 기능으로 바꾸면

CRM을 직접 만들면 회사는 그 시스템의 개발자이면서 개인정보처리자가 됩니다. 구독형 CRM이라면 제품에 있는 권한 설정과 기록 기능을 골라 켜면 되지만, 직접 만든 CRM에서는 그 기능부터 만들어야 합니다. 기준은 개인정보보호위원회 고시인 '개인정보의 안전성 확보조치 기준'에 있습니다. 아래 표는 현행 고시(2026년 7월 1일 시행) 가운데 CRM에 바로 걸리는 조항을 기능 명세로 옮긴 것입니다.

고시 조항	요구하는 것	CRM에 필요한 기능
제5조 접근 권한의 관리	업무에 필요한 최소 범위로 차등 부여, 업무가 바뀌면 지체 없이 변경·말소, 부여·변경·말소 내역 최소 3년 보관, 정당한 사유가 없는 한 취급자별 계정 발급·공유 금지, 인증 실패가 반복되면 접근 제한	역할별 권한표와 서버 쪽 검사, 퇴사·이동 때 계정 정지 절차, 권한 변경 이력, 공용 계정을 두지 않는 설계(권장), 로그인 실패 잠금
제6조 접근통제	IP 주소 등으로 접속 권한을 제한하고 접속 정보를 분석해 유출 시도를 탐지·대응, 외부에서 접속하는 취급자에게 인증서·보안토큰·일회용 비밀번호 같은 안전한 인증수단(이용자가 아닌 정보주체만 다루는 시스템은 VPN 같은 안전한 접속수단도 가능), 홈페이지·공유 설정 등으로 권한 없는 사람에게 공개되지 않게 조치, 일정 시간 업무가 없으면 자동 접속 차단	접속 허용 IP 관리와 비정상 접속 알림을 각각 두고, 외부 접속에는 2단계 인증을 따로 적용, 데이터베이스와 파일 저장소의 외부 공개 차단, 세션 자동 만료
제7조 암호화	비밀번호 같은 인증정보 암호화(비밀번호는 일방향), 이용자의 주민등록번호·여권번호·운전면허번호·외국인등록번호·신용카드번호·계좌번호·생체인식정보 암호화 저장(이용자가 아닌 정보주체는 고유식별정보의 저장 위치에 따라 별도 기준), 인터넷 구간 전송 암호화	비밀번호 해시 저장, 금융정보·고유식별정보 필드 암호화(의무 대상인지와 별개로 권장), HTTPS 강제
제8조 접속기록	정보주체를 뺀 접속자(취급자 등)의 접속기록 1년 이상 보관(5만 명 이상 처리, 고유식별정보·민감정보 처리, 기간통신사업자 중 하나면 2년 이상), 접속기록과 다운로드 상황의 점검 주기·방법·사후조치를 내부 관리계획으로 정해 이행, 위·변조 방지	누가 언제 어떤 고객을 조회·수정·내려받았는지 남기는 기록, 고칠 수 없는 보관, 정기 점검 화면과 이상 알림
제12조 출력·복사	인쇄·화면 표시·파일 생성 때 용도를 정하고 항목 최소화	내보내기 권한, 건수·항목 제한, 사유 입력
제13조 파기	복원할 수 없는 방법으로 파기	보유 기간이 지난 고객 자동 파기, 백업까지 포함한 삭제 절차

표로 보면 할 일이 많아 보이지만, 데이터 구조를 정할 때 함께 설계하면 나중에 덧붙이며 생기는 누락과 재작업을 줄일 수 있습니다. 어려운 것은 이미 만든 CRM에 나중에 붙이는 일입니다. 접속기록은 모든 조회와 내려받기가 한 통로를 거치도록 처음부터 만들어야 빠짐없이 남고, 권한 검사도 화면마다 따로 넣으면 빠지는 곳이 생기기 쉽습니다.

사고가 났을 때의 기준도 분명합니다. 개인정보 보호법 시행령 제40조는 1천 명 이상의 개인정보가 유출되거나, 민감정보나 고유식별정보가 유출되거나, 외부의 불법적인 접근으로 개인정보가 유출된 경우, 유출을 알게 된 때부터 72시간 안에 개인정보보호위원회나 한국인터넷진흥원에 신고하도록 정합니다. 세 번째 경우에는 인원 기준이 없습니다. 열려 있던 API로 누군가 고객 정보를 가져갔다면 몇 명이었는지와 관계없이 신고 대상이 될 수 있다는 뜻입니다. 9월 개정으로, 유출 경로를 확인하고 데이터를 회수·삭제해 피해 가능성이 현저히 낮아진 경우에는 신고하지 않을 수 있는 예외가 생겼습니다. 실무에서는 접속기록 같은 자료가 있어야 유출 경로와 회수·삭제 조치를 확인하고 이 예외에 해당하는지 판단할 수 있습니다.

책임의 주체도 법에 적혀 있습니다. 9월 11일 시행된 개인정보 보호법 제30조의3은 사업주 또는 대표자를 개인정보의 안전한 처리와 정보주체의 권리 보호에 대한 최종적인 책임자로 정하고, 필요한 전문 인력과 예산을 지원하도록 했습니다. 대표가 주말에 AI로 직접 만든 CRM이라도, 그 안에 담긴 고객 정보에 대한 책임은 회사와 대표에게 그대로 남습니다.

고객 데이터를 넣기 전, 이 순서로 확인합니다

AI로 만든 CRM에 실제 고객 데이터를 넣기 전에는 아래 순서를 권합니다. 앞 단계의 결과가 뒤 단계의 기준이 되도록 순서를 짰습니다.

담을 데이터부터 적습니다. 어떤 항목을 모으는지, 그중 고유식별정보나 민감정보, 계좌번호가 있는지, 몇 명 규모인지, 고객이 우리 온라인 서비스의 이용자인지 적습니다. 회사가 전기통신사업법에 따라 등록하거나 신고한 기간통신사업자인지도 확인합니다. 기간통신사업자라면 인원이나 정보 종류와 관계없이 접속기록을 2년 이상 보관해야 합니다. 접속기록 보관 기간(1년 또는 2년)과 암호화 의무 대상이 여기서 갈립니다.
권한표를 만들고 계정 두 개로 깨 봅니다. 역할별 계정을 만들고, 낮은 권한 계정으로 높은 권한의 기능과 남의 고객 데이터를 API로 직접 요청합니다. 화면에 버튼이 없어도 요청은 보낼 수 있습니다.
로그인하지 않은 상태에서 데이터에 닿아 봅니다. 배포된 웹페이지 코드에서 데이터베이스 주소와 키를 찾아, 로그인 없이 고객 표를 읽을 수 있는지 확인합니다. 파일 저장소에 올린 명함이나 계약서 사진이 주소만 알면 열리는지도 봅니다.
키를 찾습니다. 웹페이지 코드, 저장소의 현재 파일과 과거 기록, AI 코딩 도구의 설정 파일에 문자·결제·이메일 키가 들어 있지 않은지 검사합니다. 하나라도 나오면 지우기 전에 먼저 바꿉니다.
내보내기와 기록을 확인합니다. 권한 없는 계정으로는 내보내기가 막히는지, 내려받으면 누가 언제 몇 건을 받았는지 남는지, 그 기록을 일반 관리자가 지울 수 없는지 봅니다.
AI 기능에 시험 문의를 넣어 봅니다. 외부로 데이터를 보내라는 지시를 숨긴 시험 문의를 등록하고, AI 요약이나 답장 초안이 그 지시를 따르는지 확인합니다. 실제 고객 데이터가 아닌 시험 데이터로 합니다.
지우는 법을 확인합니다. 고객이 삭제를 요청하거나 보유 기간이 끝났을 때 백업까지 포함해 지울 수 있는지, 지운 뒤 되살아나지 않는지 확인합니다.

이 가운데 2·3번은 API 응답과 접근 권한을, 6번은 AI가 호출한 기능과 밖으로 나간 요청 기록까지 확인해야 하는 단계라 화면만 눌러 보는 점검으로는 놓치기 쉽습니다. 외부 점검을 맡긴다면 이 범위를 꼭 넣으십시오. 출시 전 점검 전반은 AI 코딩으로 만든 서비스, 출시 전 보안 자가점검 10가지에도 정리해 두었습니다.

직접 만들 것인가, 사서 쓸 것인가

AI로 CRM을 직접 만드는 것이 틀린 선택은 아닙니다. 다만 그 비용에는 화면을 만드는 시간만이 아니라 권한과 기록, 파기, 연동 키 관리, 사고 대응까지 운영이 함께 들어간다는 점을 계산에 넣어야 합니다. 판단할 때는 세 가지를 보면 됩니다.

첫째는 담기는 데이터의 무게입니다. 5만 명 이상의 고객 정보를 처리하거나 고유식별정보, 민감정보를 다룬다면 접속기록을 2년 이상 보관해야 합니다. 계좌번호나 신용카드번호를 저장한다면 고시상 암호화 의무 대상인지와 별개로 암호화해 두는 편이 맞습니다. 이 요건을 직접 갖추기 어렵다면 핵심 고객 데이터는 검증된 CRM에 두고, AI로는 그 위에 우리 업무에 맞는 화면과 보고서를 얹는 방식이 현실적입니다.

둘째는 만든 사람이 떠난 뒤입니다. AI와 대화하며 만든 시스템은 설계가 만든 사람의 기억과 대화 기록에만 남기 쉽습니다. 그 사람이 퇴사하면 권한 규칙이 왜 그렇게 돼 있는지, 키가 어디에 있는지 아는 사람이 없어집니다. 권한표와 데이터 목록, 키 목록을 시스템과 함께 문서로 남겨야 합니다.

셋째는 검증할 사람이 있느냐입니다. AI는 만드는 속도를 바꿨지만 검증의 책임까지 가져가지는 않았습니다. 사내에 요청을 직접 만들어 권한을 깨 볼 사람이 없다면, 고객 데이터를 넣기 전에 외부 점검을 한 번 거치는 것이 순서입니다.

고객 데이터를 넣기 전에 권한부터 확인하기

보안 전문 기업 SENTRIX는 레드팀을 운영하며 보안 실무 10년의 경험을 쌓았고, 수상 이력은 2025 식약처 주최 AI 레드팀 챌린지 최우수상(구성원)입니다. AI 모의해킹·AI 심화 취약점 진단에서는 AI 자동화로 넓게 훑고 전문가가 직접 검증해, 웹·API의 권한 문제와 비즈니스 로직 결함, 여러 약점을 엮는 연쇄 공격 경로를 확인하고 LLM·AI 기능 자체의 보안도 검증합니다. 위 순서의 2, 3, 6번처럼 계정을 바꿔 가며 남의 고객 데이터에 닿는지, CRM에 붙인 AI가 고객의 글을 명령으로 따르는지가 이 진단이 보는 영역입니다. 기업은 웹 서비스 1개에 대해 AI 웹진단 1회를 무료로 받을 수 있고, 조건은 AI 모의해킹·AI 심화 취약점 진단 페이지에 있습니다. 직접 만든 CRM을 열기 전에 점검 범위를 정하려면 진단 문의하기로 알려 주십시오.

참고 자료

AI 코딩 보안 AI 코딩 CRM CRM 보안 고객 개인정보 유출 개인정보 안전성 확보조치 Supabase RLS 사내 시스템 보안 전체 태그 →

직접 만든 CRM, 고객 데이터 넣기 전 점검받기

보안 실무 10년 전문가가 기업 환경에 맞는 방안을 제시합니다.

진단 문의하기