[Hacker News 요약] LLM이 취약한 앱을 해킹할 수 있을까? 1,500달러를 들인 실험 보고서
14
설명
이 글은 개발자가 직접 취약한 애플리케이션을 구축하고 다양한 대규모 언어 모델(LLM)이 이를 해킹할 수 있는지 실험한 흥미로운 보고서입니다. 저자는 1,500달러의 비용을 들여 LLM의 실제 보안 취약점 탐지 및 악용 능력을 평가했습니다. 특히 Firebase와 같은 서버리스 백엔드에서 흔히 발생하는 접근 제어 문제를 중심으로 LLM의 성능과 한계를 심층적으로 분석합니다. 이 실험은 LLM 기반 보안 도구의 현재 위치와 미래 발전 방향에 대한 중요한 통찰을 제공합니다.
### 배경 설명
최근 몇 년간 인공지능, 특히 LLM의 발전은 소프트웨어 개발 및 보안 분야에 혁신적인 변화를 가져왔습니다. LLM은 코드 생성, 버그 탐지, 취약점 분석 등 다양한 영역에서 잠재력을 보여주며, 사이버 보안 분야에서도 자동화된 취약점 스캐닝이나 침투 테스트 보조 도구로서의 가능성이 꾸준히 논의되어 왔습니다. 그러나 LLM이 실제 복잡한 시스템의 취약점을 자율적으로 찾아내고 악용할 수 있는지에 대한 실증적인 연구는 아직 부족한 실정입니다.
이러한 맥락에서 본 실험은 LLM이 실제 환경에서 흔히 발견되는 '접근 제어(Broken Access Control)' 취약점을 얼마나 효과적으로 악용할 수 있는지를 탐색합니다. 특히 Firebase나 Supabase와 같은 BaaS(Backend as a Service) 솔루션은 개발 편의성을 제공하지만, 잘못된 보안 규칙 설정으로 인해 데이터베이스가 외부에 노출되는 '객체 수준 권한 누락(Missing Object-Level Authorization)' 문제가 빈번하게 발생합니다. API 자체는 견고하더라도 데이터 레이어의 보안 설정 미흡으로 전체 시스템이 위험에 처할 수 있는 이러한 시나리오는 실제 서비스에서 심각한 위협이 됩니다. 저자의 실험은 이러한 현실적인 취약점을 LLM이 얼마나 인지하고 활용할 수 있는지에 대한 중요한 통찰을 제공하며, LLM 기반 보안 도구의 현재 위치와 미래 발전 방향을 가늠하는 데 기여합니다.
### 실험 설계 및 취약점 개요
저자는 React Native(Expo) 프론트엔드와 Python(FastAPI) 백엔드로 구성된 가상의 도서 리뷰 앱을 구축했습니다. 이 앱의 핵심 취약점은 API 자체는 견고하지만, 데이터 레이어로 사용된 Firebase Firestore의 보안 규칙이 제대로 설정되지 않아 사용자가 직접 Firebase에 가입하고 다른 사용자의 비공개 리뷰를 읽을 수 있다는 점입니다. 이는 '접근 제어' 또는 '객체 수준 권한 누락'으로 분류되는 흔한 유형의 취약점입니다. 각 LLM에는 APK 파일과 챌린지 설명이 제공되었으며, 10회 실행을 목표로 각 실행당 최대 10달러, 2시간의 시간 제한을 두었습니다. 실험의 비과학적 특성과 보안 연구 승인 여부 등 몇 가지 주의사항도 명시되었습니다.
### 주요 LLM별 성능 분석 및 행동 양상
실험 결과, GPT-5.5가 10회 시도 중 7회 성공(70%)하며 가장 높은 해결률을 보였습니다. GPT-5.5는 APK 압축 해제 후 Firebase에 집중하여 취약점을 찾아냈습니다. Deepseek V4 Pro는 3회 성공(30%)했지만, 일부 실행에서는 Firebase 대신 API나 앱 자체의 취약점을 찾는 데 시간을 보냈습니다. Claude Sonnet 4.6과 Opus 4.8은 각각 2회 성공(20%)했으나, Claude Opus는 보안 가드레일로 인해 세션이 조기에 종료되는 경우가 많았습니다. Deepseek V4 Flash, Gemini 3.1 Pro/3.5 Flash, MiniMax M2.7, Step 3.7 Flash 등 다른 모델들은 성공률 0%를 기록했습니다. Gemini 모델들은 보안상의 이유로 즉시 거부하거나 초기에 실행을 중단하는 경향이 두드러졌습니다.
### 추가 모델 테스트 및 비용 문제
초기 10회 실행 모델 외에도 GLM 5.1, Qwen 3.7 Max, Grok Build 0.1, Minimax M3, Kimi K2.6, Owl Alpha 등 여러 모델이 추가로 테스트되었습니다. 이 모델들은 비용 문제로 인해 10회 미만으로 실행되었지만, 대부분 낮은 성공률을 보였습니다. 특히 GLM 5.1은 1회 성공했지만 매우 비싸고 많은 토큰을 사용했으며, Qwen 3.7 Max는 로컬 테스트에서는 유망했지만 실제 장기 실행에서는 실패하고 700만 개 이상의 토큰을 소모하는 비효율성을 보였습니다. Kimi K2.6은 단 1회 시도에서 성공하며 인상적인 결과를 보여주었으나, API의 동시성 제한으로 추가 테스트가 어려웠습니다. 저자는 이 과정에서 총 1,500달러를 지출하며 LLM 테스트의 높은 비용과 비효율성에 대한 불만을 토로했습니다.
### 저자의 교훈 및 실무적 시사점
저자는 이번 실험을 통해 몇 가지 중요한 교훈을 얻었습니다. 첫째, Minimax나 GLM과 같은 일부 모델의 API는 잦은 중단으로 인해 테스트 진행에 어려움을 겪었습니다. 둘째, 중국어 기반 모델(Deepseek, Kimi 등)은 데이터베이스 직접 공격에 더 적극적인 경향을 보인 반면, 다른 모델들은 '라이브 데이터베이스에 영향을 줄 수 있다'는 이유로 중간에 멈추는 '보안 가드레일' 현상을 보였습니다. 셋째, 테스트 하네스 구축이 가장 어려운 부분이었으며, 여러 제공업체의 API 차이점을 다루는 것보다 OpenRouter와 같은 통합 플랫폼을 사용하는 것이 더 효율적이었을 것이라고 언급했습니다. 마지막으로, 저자는 LLM 테스트에 너무 많은 비용을 지출한 것에 대한 후회를 표하며, 이 돈으로 실제 앱을 개발할 수도 있었다고 자조했습니다.
### 가치와 인사이트
이 실험은 LLM이 실제 보안 취약점을 탐지하고 악용하는 능력에 대한 현실적인 시각을 제공합니다. 현재 LLM은 복잡한 보안 시나리오에서 인간 전문가를 완전히 대체하기에는 역부족이지만, 특정 유형의 취약점(특히 잘 정의된 접근 제어 문제)에 대해서는 유의미한 성능을 보일 수 있음을 입증했습니다. GPT-5.5와 같은 선두 모델은 APK 분석을 통해 핵심 취약점을 파악하고 공격 경로를 찾아내는 데 상당한 능력을 보여주었습니다. 이는 개발자가 LLM을 활용하여 코드 리뷰나 초기 단계의 보안 취약점 스캐닝을 자동화하는 데 활용할 수 있음을 시사합니다.
그러나 동시에 LLM의 한계도 명확히 드러났습니다. 많은 모델이 보안 가드레일에 막히거나, 비효율적인 탐색 전략으로 인해 막대한 비용과 시간을 소모했습니다. 특히, '데이터베이스 직접 공격'에 대한 모델별 태도 차이는 LLM의 윤리적 사용과 안전성 확보에 대한 중요한 논의 지점을 제공합니다. 개발자들은 LLM을 보안 도구로 활용할 때, 모델의 편향성, 거부 메커니즘, 그리고 비용 효율성을 신중하게 고려해야 합니다. 또한, LLM이 제공하는 결과의 정확성과 신뢰성을 검증할 수 있는 전문가의 역할은 여전히 필수적입니다.
### 기술·메타
- React Native (Expo)
- Python (FastAPI)
- Firebase Firestore
- OpenAI GPT-5.5
- Deepseek V4 Pro/Flash
- Claude Sonnet 4.6/Opus 4.8
- Gemini 3.1 Pro Preview/3.5 Flash
- Minimax M2.7/M3
- Step 3.7 Flash
- GLM 5.1
- Qwen 3.7 Max
- Grok Build 0.1
- Kimi K2.6
- Owl Alpha
- Modal (for runners)
- OpenRouter (API gateway)
### 향후 전망
LLM 기반 보안 도구의 미래는 더욱 발전된 자율성과 정교함을 향해 나아갈 것입니다. 현재의 실험에서 LLM은 특정 취약점을 발견하는 데 성공했지만, 이는 비교적 명확한 시나리오였습니다. 향후 LLM은 더욱 복잡하고 다층적인 공격 경로를 스스로 탐색하고, 제로데이 취약점까지 발견하는 수준으로 발전할 가능성이 있습니다. 이를 위해서는 모델이 단순히 패턴을 인식하는 것을 넘어, 시스템의 전체적인 아키텍처와 비즈니스 로직을 이해하고 추론하는 능력이 강화되어야 합니다.
또한, LLM의 '보안 가드레일'은 양날의 검이 될 수 있습니다. 악의적인 사용을 막는 긍정적인 측면이 있지만, 합법적인 보안 연구나 침투 테스트를 방해할 수도 있습니다. 따라서 LLM 개발사들은 보안 연구용 API 접근 정책을 더욱 유연하게 하거나, 특정 환경에서 가드레일을 조절할 수 있는 옵션을 제공하는 방향으로 발전할 수 있습니다. 경쟁 측면에서는, 비용 효율적이면서도 강력한 보안 분석 능력을 갖춘 LLM이 시장에서 우위를 점할 것입니다. 오픈소스 커뮤니티에서는 이러한 LLM을 활용한 자동화된 보안 테스트 프레임워크나 에이전트 기반의 침투 테스트 도구 개발이 활발해질 것으로 예상됩니다. 궁극적으로 LLM은 인간 보안 전문가의 역량을 증강시키는 강력한 보조 도구가 될 것이며, 보안 취약점 발견 및 대응 프로세스를 혁신할 잠재력을 가지고 있습니다.
📝 원문 및 참고
- Source: Hacker News
- 토론(HN): [news.ycombinator.com](https://news.ycombinator.com/item?id=48392343)
- 원문: [링크 열기](https://kasra.blog/blog/i-spent-1500-seeing-if-llms-could-hack-my-app/)
---
출처: Hacker News · [원문 링크](https://kasra.blog/blog/i-spent-1500-seeing-if-llms-could-hack-my-app/)
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.