법률 사무소가 AI 툴에 의뢰인의 모든 기록을 맡기는 시대입니다. 그런데 그 데이터는 정말 안전할까요? 보안 연구자 Alex Schapiro가 10억 달러 가치의 AI 법률 플랫폼 Filevine에서 발견한 취약점은, AI 열풍 속에서 기본적인 보안 원칙마저 무시되고 있는 현실을 보여줍니다.

보안 연구자 Alex Schapiro가 AI 법률 기술 기업 Filevine의 시스템을 분석하던 중, 인증 없이 한 법률 사무소의 전체 파일시스템에 접근할 수 있는 치명적 취약점을 발견했습니다. HIPAA로 보호되는 의료 기록부터 법원 명령으로 봉인된 문서까지, “confidential”을 검색했을 때만 거의 10만 건의 결과가 나왔죠. 이 글은 그가 어떻게 이 허점을 찾았고, 이것이 AI 시대의 보안에 던지는 질문이 무엇인지 살펴봅니다.

출처: How I Reverse Engineered a Billion-Dollar Legal AI Tool and Found 100k+ Confidential Files – Alex Schapiro

간단했던 발견 과정

Schapiro는 Filevine의 데모 환경을 찾기 위해 하위도메인 검색을 시도했습니다. 대신 발견한 것은 margolis.filevine.com이라는 실제 고객사 도메인이었죠. 페이지는 무한 로딩 상태였고, 개발자 도구에서도 일반적인 네트워크 요청이 보이지 않았습니다.

핵심은 미니파이된 자바스크립트 코드 안에 숨어 있었습니다. 코드를 분석한 결과 /prod/recommend라는 API 엔드포인트와 AWS의 API Gateway 주소를 찾아냈죠. 그는 적절한 페이로드 구조를 파악한 뒤 테스트 요청을 보냈습니다.

{"projectName":"Very sensitive Project"}

인증 토큰도, API 키도 필요 없었습니다. 응답으로 돌아온 것은 boxToken—해당 법률 사무소의 Box 파일 시스템에 대한 완전한 관리자 권한 토큰이었습니다.

심각성: 수백만 건의 민감 문서

이 토큰으로 Schapiro는 Box API를 통해 법률 사무소의 모든 파일에 접근할 수 있었습니다. 단순히 “confidential”을 검색했을 때만 거의 10만 건의 결과가 나왔죠. 여기에는 다음과 같은 문서들이 포함되어 있었습니다:

• HIPAA로 보호되는 의료 기록
• 법원 명령으로 봉인된 문서
• 내부 메모와 급여 기록
• 의뢰인-변호사 간 특권으로 보호되는 통신 기록

악의적인 공격자였다면 모든 파일을 다운로드하고, 랜섬웨어 공격을 시도하거나, 경쟁 법률 사무소에 정보를 팔 수도 있었습니다. Schapiro는 영향을 확인한 즉시 테스트를 중단하고 책임있게 공개했습니다.

AI 열풍이 놓친 기본 원칙

이 취약점이 보여주는 건 단순한 코딩 실수가 아닙니다. 여기엔 여러 층위의 보안 실패가 겹쳐 있었죠:

하위도메인 노출: 고객사 도메인이 공개적으로 검색 가능했습니다. 공격자가 타깃을 찾기 쉬운 구조였죠.

인증 부재: API가 아무런 인증도 요구하지 않았습니다. 누구나 요청을 보낼 수 있었어요.

과도한 권한: 반환된 토큰이 전체 파일시스템에 대한 관리자 권한을 가졌습니다. 필요한 최소 권한 원칙을 완전히 무시한 거죠.

클라이언트 측 비밀 노출: 민감한 API 엔드포인트와 구조가 자바스크립트에 하드코딩되어 있었습니다.

Hacker News에서 한 댓글 작성자가 지적했듯이, “이건 2010년대 버그 패턴을 2025년 AI 포장지로 싼 것”입니다. 하위도메인 검색, 무인증 API, 과도한 권한 토큰—모두 익숙한 실수들이죠. 진짜 “AI”인 부분은 모델 학습을 위해 모든 문서를 한곳에 모았다는 점뿐이고, 그게 오히려 보안 사고의 피해 범위를 극대화했습니다.

보안 인증의 한계

Filevine은 웹사이트에서 SOC2 인증과 정기적인 보안 테스트를 자랑합니다. 그런데 어떻게 이런 기본적인 허점을 놓쳤을까요?

Hacker News 토론에서 보안 전문가들은 이구동성으로 지적했습니다. SOC2 같은 인증은 본질적으로 체크박스 작업이라는 거죠. 한 댓글 작성자는 “SOC2는 주로 질문에 답했는지만 확인하지, 답변이 무엇인지나 실제 보안 상태는 깊이 파지 않는다”고 말했습니다. 자동화된 취약점 스캐너는 인증되지 않은 API나 과도한 권한 같은 로직 결함을 찾아내지 못하죠.

더 큰 문제는 조직 구조입니다. 보안팀이 취약점을 발견해도, 어느 팀이 해당 코드를 소유하는지 찾고, 수정을 우선순위에 넣도록 설득하고, 법무팀과 조율하는 데만 몇 주가 걸립니다. Schapiro가 10월 27일에 신고했지만 Filevine이 확인 메일을 보낸 건 일주일 후인 11월 4일이었고, 수정 완료는 11월 20일이 되어서였습니다. 그 사이 3주 이상 취약점은 그대로 열려 있었죠.

책임있는 공개의 딜레마

Schapiro는 모범적인 절차를 따랐습니다. 즉시 신고하고, 수정을 기다렸으며, 공개 전에 회사의 동의를 받았죠. Filevine도 전문적으로 대응했습니다.

하지만 Hacker News에서는 논쟁이 일었습니다. 이렇게 심각한 취약점을 조용히 수정하도록 놔두는 게 정말 옳은 일일까요? 한 댓글 작성자는 이렇게 물었습니다: “10억 달러 기업이 이렇게 망쳤는데, 비공개로 수정하게 해주는 게 올바른 일인가? 그럼 기업들이 결과 없이 계속 고객 돈을 받아먹는 거 아닌가?”

반대 의견도 있었습니다. 즉각 공개하면 악의적 공격자들이 패치 전에 악용할 수 있다는 거죠. 하지만 이렇게 단순한 취약점이라면요? 하위도메인 검색과 API 테스트만으로 찾을 수 있는 허점을 Schapiro만 발견했다고 믿을 수 있을까요?

일부는 더 강경한 입장을 제시했습니다. 고객 데이터가 심각한 위험에 처한 경우, 수정될 때까지 서비스를 즉시 중단하라고 요구해야 한다는 거죠. 불편하겠지만, 잠재적 데이터 유출보다는 낫다는 논리입니다.

우리가 배워야 할 것

이 사건은 AI 툴 특유의 문제는 아닙니다. API 통합을 잘못한 어떤 SaaS 회사에서든 일어날 수 있는 일이죠. 하지만 AI 열풍이 문제를 악화시킵니다.

경쟁사보다 먼저 AI 기능을 출시하라는 압박이 커지면서, 기본적인 보안 원칙이 “나중에 추가할 것”으로 밀려납니다. 최소 권한, 적절한 토큰 범위, 인증 계층화—이런 것들은 영업 과정에서 마찰로 여겨지죠. “당신 회사의 모든 문서를 AI로 검색 가능하게 만들겠다”는 피치 덱에서는 “예”라고 답하는 게 계약을 따내는 길이지, “아니오”라고 하는 게 아닙니다.

법률 사무소는 “AI 어시스턴트”를 산다고 생각하지만, 실제로 사는 건 “검증되지 않은 제3자에게 제도적 기억의 루트 접근 권한을 주는 것”입니다. 그 시점에서 흥미로운 질문은 이런 버그가 더 있는지가 아니라, 이런 시스템 중 얼마나 많은 것이 호기심 많은 블로거보다 동기가 강한 누군가의 진지한 레드팀 테스트를 견뎌낼 수 있느냐입니다.

Filevine은 취약점을 수정했고, 이번에는 아무도 악용하지 않았습니다. 다음번에도 그럴까요?

참고자료

• Hacker News 토론 – 400+ 댓글의 업계 반응

Like?