LLM이 진짜 해킹을 할 수 있을까? 1,500달러짜리 실험 결과 공개
"내 앱이 AI한테 해킹당할 수 있을까?" — 솔직히 이 질문을 真 진지하게 고민해본 개발자가 얼마나 될까요. 대부분은 "설마"라고 넘어갑니다. 그런데 한 연구자가 이 질문에 1,500달러를 걸고 직접 답을 찾아 나섰습니다.
어떤 실험이었나
이 실험의 출발점은 단순한 궁금증이었습니다. "LLM을 해킹 도구로 쓰면 실제로 얼마나 위험한가?" 연구자는 이 질문에 답하기 위해 의도적으로 취약점을 심어둔 여러 종류의 웹 애플리케이션을 직접 제작했습니다. SQL 인젝션, XSS(크로스사이트 스크립팅), IDOR(불안전한 직접 객체 참조) 같은 고전적인 취약점들이 포함됐습니다.
그 다음, GPT-4o를 비롯한 최신 LLM들에게 이 앱들을 공격하도록 지시했습니다. 단순히 "이 앱 해킹해봐"라는 식의 무작위 공격이 아니라, 실제 침투 테스터(펜테스터)가 쓰는 방식과 유사하게 단계적인 프롬프트 체인을 구성했습니다. API 호출 비용, 클라우드 인프라 비용, 도구 개발 비용을 합산한 총 지출이 약 1,500달러였습니다.
결과는 예상보다 훨씬 복잡했습니다. LLM은 어떤 부분에서는 놀라울 정도로 유능했고, 어떤 부분에서는 인간 해커의 발끝에도 미치지 못했습니다.
LLM이 잘한 것과 못한 것
LLM이 인상적인 성능을 보인 영역은 코드 분석과 취약점 식별이었습니다. 소스코드를 제공하자 LLM은 수초 만에 잠재적 취약 지점을 열거했습니다. 숙련된 개발자가 코드 리뷰에서 놓칠 수 있는 미묘한 로직 결함도 잡아냈습니다. 특히 SQL 인젝션 페이로드를 자동으로 생성하고, 다양한 변형을 시도하는 과정에서는 반복 작업을 자동화하는 능력이 돋보였습니다.
반면 한계도 뚜렷했습니다. 블랙박스 공격, 즉 소스코드 없이 실행 중인 애플리케이션만 보고 취약점을 찾는 상황에서는 성능이 크게 떨어졌습니다. 실제 공격 시나리오에서 해커가 소스코드를 갖고 있는 경우는 드뭅니다. LLM은 컨텍스트가 주어지지 않으면 추측에 의존해야 하는데, 이 추측의 정확도가 낮았습니다.
또한 다단계 공격 체인(multi-step exploit chain) 구성에서 어려움을 겪었습니다. 취약점 A를 이용해 권한을 높이고, 그 권한으로 취약점 B를 익스플로잇하는 연쇄 공격은 인간 해커의 영역으로 남아있었습니다. LLM은 각 단계를 개별적으로는 처리할 수 있었지만, 전체 공격 흐름을 유기적으로 연결하는 "전략적 사고"는 부족했습니다.
왜 지금 이게 중요한가
이 실험이 단순한 흥밋거리가 아닌 이유가 있습니다. AI 에이전트가 실제 서비스에 통합되는 속도가 빨라지고 있기 때문입니다. 코드를 작성하고, 데이터베이스를 조회하고, 외부 API를 호출하는 AI 에이전트가 늘어날수록, LLM을 통한 공격 경로도 함께 늘어납니다.
실제로 주목해야 할 것은 LLM 자체의 해킹 능력보다 LLM 기반 서비스의 새로운 공격 표면입니다. 프롬프트 인젝션(악의적인 입력으로 AI의 행동을 조작하는 공격)은 이미 현실의 위협입니다. 사용자가 입력한 텍스트가 AI 에이전트를 통해 데이터베이스를 삭제하거나, 외부로 민감한 정보를 유출하도록 유도할 수 있습니다. 이건 SF가 아니라 지금 당장 패치되지 않은 취약점입니다.
한국 시장에서도 챗봇, AI 고객 상담, 코드 어시스턴트가 급속히 도입되고 있습니다. 보안 검토 없이 "일단 배포하고 보자"는 접근이 6개월 뒤 심각한 사고로 이어질 수 있습니다.
개발자가 지금 당장 할 수 있는 것
이 실험에서 얻을 수 있는 실용적인 교훈은 명확합니다. 복잡한 해킹 기술이 필요한 게 아닙니다.
1단계 — 입력 검증을 LLM에게 맡기지 마라
AI가 처리하는 모든 외부 입력은 기존 보안 원칙과 동일하게 검증해야 합니다. "LLM이 알아서 처리하겠지"라는 신뢰는 위험합니다. 화이트리스트 기반 입력 필터링, 파라미터 바인딩을 통한 SQL 인젝션 방지는 AI 시대에도 여전히 유효합니다.
2단계 — 최소 권한 원칙을 AI 에이전트에도 적용하라
AI 에이전트에게 필요 이상의 권한을 주지 마세요. 고객 상담 봇이 데이터베이스 전체에 접근할 이유는 없습니다. 에이전트가 실행할 수 있는 작업 범위를 명시적으로 정의하고 제한하세요.
3단계 — 프롬프트 인젝션 테스트를 QA에 포함하라
기능 테스트만큼 보안 테스트도 자동화하세요. 악의적인 사용자 입력 시나리오를 테스트 케이스로 만들어 CI/CD 파이프라인에 포함시키는 것은 지금 당장 실행 가능한 일입니다. 오픈소스 도구인 Garak(LLM 취약점 스캐너)이나 PyRIT(Microsoft의 AI 레드팀 도구)를 활용하면 비용 없이 시작할 수 있습니다.
4단계 — 로그와 모니터링을 강화하라
AI 에이전트의 행동을 로깅하고 이상 패턴을 감지하는 시스템을 구축하세요. 같은 사용자가 비정상적으로 많은 API 호출을 하거나, 권한 밖의 리소스에 접근하려는 시도가 반복된다면 즉시 알림이 가야 합니다.
전망: AI 보안은 이제 선택이 아니다
이 1,500달러짜리 실험이 증명한 것은 아이러니하게도 "LLM은 아직 완전한 해커가 아니다"라는 사실입니다. 하지만 이 결론에서 안도해서는 안 됩니다. LLM의 능력은 빠르게 향상되고 있고, 더 중요한 것은 LLM을 도구로 활용하는 인간 해커의 생산성이 이미 크게 높아졌다는 점입니다.
스크립트 키디(기술 없이 기존 툴만 쓰는 하급 해커)가 LLM의 도움으로 정교한 공격을 설계할 수 있게 된 세상, 이미 그 세상이 왔습니다. 공격 비용은 낮아지고, 방어 비용은 올라가는 구조입니다.
AI 서비스를 운영하거나 개발 중인 팀이라면, 보안을 출시 후 과제가 아니라 설계 단계의 필수 체크리스트로 바꿔야 할 시점입니다. 이 흐름을 무시하면 6개월 뒤 후회할 수 있습니다.
⚠️ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
댓글