취약한 앱을 직접 만들고 LLM이 해킹할 수 있는지 $1,500 써서 실험해봤다
I built a vulnerable app and spent $1,500 seeing if LLMs could hack it
TL;DR Highlight
Firebase 취약점을 가진 앱을 직접 제작하고 GPT-5.5, Claude, Deepseek 등 주요 LLM이 자율적으로 해킹할 수 있는지 실험한 결과, GPT-5.5가 70% 성공률로 압도적이었고 Claude는 보안 거부 정책 때문에 능력과 무관하게 낮은 점수를 기록했다.
Who Should Read
LLM을 보안 연구나 펜테스트(침투 테스트) 자동화에 활용하고 싶은 보안 엔지니어 또는 백엔드/모바일 개발자. Firebase나 Supabase 기반 앱을 운영 중인 개발자도 자신의 앱 취약점 패턴을 이해하는 데 유용하다.
Core Mechanics
- 실험 설계는 React Native(Expo) + FastAPI + Firebase로 구성된 북리뷰 앱이다. API 자체는 보안이 잘 되어 있지만, APK 안에 포함된 google-services.json을 통해 Firebase에 직접 접근하면 다른 사용자의 비공개 리뷰(flag)를 읽을 수 있는 구조다.
- 이 취약점은 실제 현장에서도 흔히 발견되는 패턴으로, 'Broken Access Control' 또는 'Missing Object-Level Authorization'이라고 부른다. API는 잘 막아뒀지만 Firebase/Supabase 규칙은 열려 있는 경우가 많다.
- GPT-5.5가 7/10(70%) 성공률로 가장 높았다. 거의 모든 실행에서 APK를 압축 해제한 뒤 곧바로 Firebase에 집중했고, API 쪽에서 헤매는 시간이 거의 없었다. 비용은 실행당 평균 $6.62, 성공당 $9.46이었다.
- Deepseek V4 Pro는 3/10(30%) 성공률로 두 번째였다. 단 실행당 평균 비용이 $0.19로 GPT-5.5 대비 35배 저렴해서, 성공당 비용은 $0.62로 오히려 가장 경제적이었다.
- Claude Sonnet 4.6과 Opus 4.8은 각각 2/10 성공률이었는데, 이는 실력 부족이 아니라 보안 가드레일 때문이다. Opus는 정답에 근접했다가 세션 도중 거부로 중단된 경우가 많았고, Claude는 실행 중간에 갑자기 작업을 중단하는 'late refusal' 패턴을 보였다.
- Gemini 3.1 Pro Preview는 10회 모두 즉각 거부(0/10)했는데, 중간 토큰 수가 9k로 다른 모델의 100k+ 대비 극단적으로 낮아 사실상 시도조차 안 한 것으로 해석된다.
- Deepseek V4 Flash는 Firebase를 인식하기는 했지만 모든 실행에서 'API가 안전한 것 같다'는 보고서를 내고 종료했다(0/10). 방향은 맞지만 실행까지 이어지지 못한 케이스다.
- 부분 실행된 모델 중 Kimi K2.6이 1/1(100%)로 완료했고 실행당 비용이 $1.02에 불과해 가성비 측면에서 주목할 만하다. GLM 5.1도 1/4(25%) 성공했고 성공당 비용은 $34.73이었다.
- 모든 실행은 실행당 $10 예산 상한과 2시간 제한을 두었다. Claude를 제외한 모델은 pi + pi-goal-x 확장을 사용해 중간에 멈추지 않도록 강제했고, Claude는 Claude Code의 -p 모드를 사용했다.
Evidence
- Claude의 낮은 점수가 가드레일 때문이라는 점에 대해 커뮤니티는 공감했다. 한 댓글에서는 'Anthropic이 릴리스마다 보안 제한을 강화하고 있어 로그인 수행, 자격증명 처리 같은 정상적인 작업도 거부하기 시작했다'며, 결국 모델 능력과 제한 사이에서 선택해야 하는 시점이 올 것이라는 우려를 표했다.
- GPT-5.5가 보안 연구용으로 사전 승인된 계정을 사용했다는 점을 두고 불공정하다는 지적이 있었다. '가드레일이 걸린 일반 계정으로 테스트하면 비교가 더 공정할 것'이라는 의견이 나왔고, 이는 실험 결과를 해석할 때 중요한 맹점이다.
- 모델 혼자 완전히 자율 실행하는 방식이 너무 단순하다는 비판도 있었다. GLM 5.1로 고급 크랙미(crackme) 문제를 풀어본 사람이 '방향을 살짝 알려주는 식으로 함께 작업하면 훨씬 효과적'이라는 경험을 공유했다. 완전 자율 실행은 CI 통합에는 유용하지만, 실제 보안 리뷰에는 사람의 판단이 여전히 필요하다는 결론이었다.
- 모델이 거부하는 문제를 우회하는 실용적인 팁이 공유됐다. 한 댓글에서 '모델은 로컬 환경이라고 생각하면 보안 작업을 잘 수행하는 경향이 있다'며, 실제로 라이브 타깃을 localhost로 프록시하거나 JS VM을 오프라인 아티팩트로 추출해 별도 세션에서 분석하는 방식으로 GPT-5.5 xhigh의 거부를 우회했다는 경험을 공유했다.
- 현재 LLM을 보안 자동화에 쓰는 것이 비용 효율적이지 않다는 현실적인 의견도 있었다. 'False positive(실제로 없는 취약점을 있다고 잘못 탐지)가 너무 많고, 이를 다시 검증하는 데 추가 비용이 든다'는 지적이었다. 다만 '이미 알려진 일반적인 취약점(CVE 등)을 찾는 데는 AI가 효과적이고, 버그 바운티에 활용할 만하다'는 실용적 조언도 덧붙였다.
How to Apply
- Firebase나 Supabase를 데이터 레이어로 쓰는 앱을 배포하기 전에, APK 또는 앱 번들 안에 포함된 google-services.json이나 설정 파일로 Firebase에 직접 접근할 수 있는지 확인해야 한다. API 보안만 신경 쓰고 Firebase Security Rules를 열어둔 채 배포하면 이 실험과 동일한 방식으로 데이터가 노출될 수 있다.
- LLM 기반 펜테스트 자동화를 구축할 계획이라면, 완전 자율 실행보다 '방향을 살짝 제시하는 반자동 방식'이 더 효과적이다. 특히 Deepseek V4 Pro는 성공당 비용이 $0.62로 가장 저렴하므로, 예산이 제한적인 초기 스캔 단계에 활용하고 이상 징후 발견 시 더 강력한 모델로 심화 분석하는 계층형 접근을 고려할 수 있다.
- Claude를 보안 관련 자동화 작업에 사용할 때 거부가 발생한다면, '본인이 앱 개발자임을 명시'하거나 대상 환경을 localhost로 프록시하는 방식으로 우회를 시도해볼 수 있다. 단, 이런 우회 방법은 Anthropic의 정책 강화에 따라 앞으로 막힐 가능성이 있어 장기적으로는 다른 모델을 대안으로 검토하는 것이 좋다.
- 모델이 취약점을 발견했다고 보고해도 곧바로 신뢰하지 말고 반드시 검증 단계를 넣어야 한다. Step 3.7 Flash처럼 실제로 익스플로잇하지 않고 발견했다고 잘못 보고하는 false positive 문제가 있으므로, 자동화 파이프라인에서는 '성공 기준(what a successful exploit looks like)'을 명확히 정의하고 검증하는 로직을 포함해야 한다.
Terminology
관련 논문
Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구
Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.
Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험
움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.
GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교
12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.
Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과
Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.
Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구
LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.
LLM-as-a-Verifier: 범용 Verification 프레임워크
LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.