AI 개발이 빨라질수록 보안 사고도 가까워진다: AX 컨설턴트 필수 점검표

AX 컨설턴트 보안 브리핑

AI 개발이 빨라질수록
보안 검증은 더 엄격해야 합니다

‘모두의창업’ 정보유출 사례에서 배우는 API·권한·데이터 보호의 기본 원칙

이번 사건의 핵심은 단순한 “AI 해킹”이 아닙니다. 민감정보를 반환하는 API, 누락된 권한 검사, 잘못된 키 관리와 부족한 검수 절차가 결합한 기본 보안의 실패입니다. 즉, 개발 도구가 무엇이었는가보다 “누가 어떤 데이터에 접근할 수 있는지, 무엇을 외부로 내보내는지, 배포 전에 제대로 확인했는지”가 더 중요합니다.

먼저 이렇게 생각하면 쉽습니다웹서비스를 하나의 사무실이라고 보면, 로그인은 건물 출입증, 권한 검사는 각 사무실의 열쇠, API는 자료를 전달하는 창구, API 키·토큰은 관리자용 마스터키와 비슷합니다. 출입증만 있다고 모든 방을 열 수 있게 하거나, 자료 창구가 주민번호·평가자료까지 한꺼번에 내보내거나, 마스터키를 책상 위에 올려두면 사고 가능성이 커집니다.

1기사 바로가기

↗ ‘모두의창업’ 해킹…“협력사 사이트 엉망진창”디일렉(THE ELEC) 원문 보기

2무슨 일이 있었나

5,000명프로젝트 합격자 비공개 정보가 노출된 것으로 조사

3종이메일 주소·심사평·창업 아이디어 요약

API비공개 정보와 복호화에 필요한 키까지 함께 노출

기사에 따르면 플랫폼 일부 API에 비공개 정보가 포함돼 있었고, 외부에서 웹 크롤링 등으로 API를 수집하는 과정에서 정보가 유출됐습니다. 데이터는 암호화돼 있었지만 이를 풀 수 있는 키까지 함께 노출돼 암호화의 실효성이 사라졌습니다.

민감정보가 포함된
API 응답

→

외부 자동 수집과
복호화 가능

→

개인정보·아이디어
외부 노출

사업 참여 AI 솔루션 업체가 비공개 이메일 주소를 확보해 홍보 메일을 보내면서 문제가 알려졌고, 사고 이전에 외부 보안팀이 유사한 API 취약점을 제보한 사실도 보도됐습니다.

예시화면에는 이름만 보이는데 API에는 이메일·평가의견·내부 ID까지 포함되어 있다면?
일반 사용자는 화면에서 보지 못해도 개발자 도구나 자동 수집 프로그램을 통해 API 응답 전체를 확인할 수 있습니다. 따라서 “화면에 안 보이니까 안전하다”는 판단은 위험합니다.

3기사에서 지적한 반복적 취약점

권한

로그인은 있지만 권한 검사가 없음

인증된 사용자가 자신에게 허용되지 않은 다른 사람이나 다른 프로젝트의 정보까지 조회할 수 있는 문제입니다.

예: A기업 담당자가 URL의 projectId만 바꿨는데 B기업 자료가 조회되는 경우

노출

DB와 관리자 기능의 외부 공개

방화벽·접근 제한·인증 없이 데이터베이스나 관리자 페이지가 인터넷에 노출되는 문제입니다.

예: 테스트용 관리자 페이지 주소를 알기만 하면 로그인 없이 접근되는 경우

데이터

테스트 서버에 실제 자료 사용

ACL과 접근통제가 부족한 개발·테스트 환경에 실제 고객 데이터를 올리는 문제입니다.

예: 데모를 위해 실제 고객 명단이나 상담내역을 테스트 DB에 그대로 복사하는 경우

비밀정보

토큰과 암호키 노출

액세스 토큰, 리프레시 토큰, 복호화 키가 코드·파일·API 응답을 통해 드러나는 문제입니다.

예: GitHub에 올린 소스코드 안에 API Key가 그대로 들어 있거나 브라우저 소스에서 확인되는 경우

3-1AX 컨설팅 현장에서는 어떤 문제가 생길 수 있나

AX 컨설팅에서는 짧은 기간에 PoC와 프로토타입을 만드는 경우가 많습니다. 이때 “일단 동작하게 만들기”에 집중하면 보안 점검이 뒤로 밀리기 쉽습니다. 특히 비개발자 담당자와 함께 바이브 코딩을 진행할 때는 아래 상황을 주의해야 합니다.

① 고객 엑셀을 그대로 업로드테스트를 빨리 하기 위해 이름, 전화번호, 이메일이 포함된 실제 파일을 사용하면 외부 AI 서비스나 테스트 저장소에 데이터가 남을 수 있습니다.

② AI가 만든 로그인 기능을 그대로 사용로그인은 되지만 사용자별 데이터 접근 제한이 빠져 있을 수 있습니다. “로그인 성공”과 “권한 통제 성공”은 다른 문제입니다.

③ 공개 GitHub에 코드 업로드.env 파일이나 API Key가 포함된 상태로 커밋하면 짧은 시간 안에도 자동 수집될 수 있습니다.

④ 임시 테스트 URL을 계속 운영개발용 주소가 검색되거나 링크가 전달되면서 외부 접근이 가능해질 수 있습니다. 테스트가 끝나면 비활성화하거나 접근을 제한해야 합니다.

핵심 원칙: “PoC니까 괜찮다”가 아니라, PoC 단계부터 운영으로 넘어갈 가능성을 전제로 최소한의 보안 장치를 넣습니다.

기사를 읽을 때 구분할 점
API 정보유출 경위와 피해 범위는 조사 결과로 확인됐지만, 해당 시스템이 실제로 바이브 코딩으로 개발됐다는 내용은 발표자의 추정입니다. 또한 기사에 언급된 일부 기관·기업 사례는 발표자의 주장으로 소개됐으며, 각 기관의 반론이나 현재 조치 상태는 기사에 포함돼 있지 않습니다.

문제는 AI를 썼다는 사실이 아니라,
검증되지 않은 결과를 운영에 올릴 수 있는 구조입니다.

4컨설팅 현장에서 지킬 간단한 주의사항

실데이터부터 넣지 않습니다.
PoC·데모·테스트에는 합성 또는 비식별 데이터를 사용합니다.

예: 실제 고객 100명의 명단 대신 ‘홍길동1, test1@example.com’처럼 가짜 데이터를 만들어 사용합니다.

로그인과 권한을 구분합니다.
서버에서 사용자·역할·고객·프로젝트별 접근권한을 확인합니다.

예: 팀장, 일반직원, 외부 고객이 각각 볼 수 있는 메뉴와 데이터 범위를 구분합니다.

API 응답은 최소화합니다.
화면에 필요한 필드만 반환하고 DB 객체 전체를 그대로 내보내지 않습니다.

예: 화면에 회사명만 필요하면 이메일·휴대전화·내부 메모까지 함께 보내지 않습니다.

키와 토큰을 코드에서 분리합니다.
`.env`, 비밀 저장소 등을 사용하고 브라우저·로그·GitHub에 노출하지 않습니다.

예: OpenAI·Google·Slack API Key 등을 소스코드에 직접 입력하지 않습니다.

개발·테스트·운영을 분리합니다.
계정, 데이터베이스, 키와 공개 주소를 환경별로 나눕니다.

예: 테스트 DB와 운영 DB를 분리하고, 테스트용 키가 운영 데이터에 접근하지 못하도록 합니다.

AI의 “완료”를 검증 완료로 보지 않습니다.
다른 검토자와 자동 테스트를 거쳐 실제 결과를 확인합니다.

예: “다른 사용자 데이터 URL을 입력해도 막히는가?”, “로그아웃 상태에서 API 호출이 차단되는가?”를 직접 확인합니다.

고객에게 운영 방법까지 인계합니다.
계정 변경, 키 교체, 백업·복구, 장애 중단과 담당자를 문서화합니다.

예: 담당자가 퇴사해도 API Key를 교체하고 서비스를 중단·복구할 수 있도록 절차를 남깁니다.

5고객에게 확인할 다섯 가지 질문

이 시스템은 어떤 개인정보와 민감정보를 처리합니까?
누가 어떤 고객·프로젝트의 자료를 볼 수 있습니까?
API 키·토큰·비밀번호는 어디에 보관하고 누가 교체합니까?
개발·테스트 환경에 실제 고객자료가 들어가 있습니까?
배포 전 누가 어떤 테스트를 하고 최종 승인합니까?

6고객 답변을 들을 때 이렇게 해석합니다

“로그인 기능은 있습니다”

추가 확인: 로그인한 사람이 다른 고객·다른 프로젝트 자료까지 볼 수 없는지 확인해야 합니다.

“데이터는 암호화되어 있습니다”

추가 확인: 암호화 키가 같은 서버나 코드에 노출되어 있지 않은지, 누가 키를 관리하는지 확인합니다.

“테스트용이라 실제 서비스가 아닙니다”

추가 확인: 실제 개인정보가 들어가는 순간 테스트 시스템도 보호 대상이 됩니다.

“AI가 다 만들어 줬습니다”

추가 확인: 기능 완성과 보안 검증은 별개입니다. 배포 전 별도의 검토 절차가 필요합니다.

※ 이 질문들은 보안 감사를 대신하기 위한 것이 아니라, AX 컨설턴트가 초기 위험을 빠르게 발견하기 위한 기본 확인 질문입니다.

컨설턴트의 역할 빠른 개발을 막는 사람이 아니라, 빠르게 만든 결과가 고객의 개인정보·업무·신뢰를 해치지 않도록 안전장치를 함께 설계하는 사람입니다.

찰리초이 스토리 블로그

이 블로그 검색