한 프랑스의 AI 코딩 유튜버가 월 20달러인 자신의 Kimi K3 구독 서비스를 열고, 다른 1인 창업자의 앱에서 보안 취약점을 찾아 나섰습니다. 그는 몇 가지 취약점을 찾아냈고, 그 전 과정을 촬영하여 게시했습니다.

그에게는 서면 승인도, 모의 해킹(Pentest) 계약도 없었습니다. 그저 자신의 것이 아닌 운영 중인 앱(Production app)을 해체하는 누군가의 화면 녹화 영상이 있었을 뿐입니다.

댓글은 몇 분 만에 두 진영으로 나뉘었습니다. 한쪽은 이를 명백한 침해이자, 변호사의 전화를 받게 될 수도 있는 본인 소유가 아닌 시스템에 대한 무단 접속이라고 불렀습니다. 다른 한쪽은 취약점을 점검하지 않고 제품을 출시하는 경우가 대부분인 커뮤니티를 위한 무료 보안 테스트로서, 일종의 공공 서비스라고 불렀습니다.

저는 이 싸움에서 어느 한 편을 들지 않겠습니다.

윤리 논쟁은 건너뛰십시오. 대신 가격표를 보십시오.

그가 그 영상에서 해낸 일은 3년 전이었다면 수년간 축적된 공격 보안(Offensive security) 기술이 필요했을 것입니다. 하지만 오늘날에는 월간 구독료와 한가한 오후 시간만 있으면 가능합니다.

우리가 진지하게 고민해 봐야 할 부분은 바로 이 지점입니다. 그가 영상을 올려도 되었는지, 허가를 받았는지, Medium이나 어딘가의 변호사가 그의 방식에 동의하는지 여부가 아닙니다. "일반 개발자"와 "당신의 앱 취약점을 찾아낼 수 있는 사람"을 구분 짓던 **장벽(Barrier)**이 대부분 사라졌다는 사실입니다. 그리고 그 장벽은 그 한 사람만을 위해 사라진 것이 아닙니다. 저 또한 여기서 그의 이름을 언급하지 않겠습니다. 이런 행위에 대한 무료 광고는 하지 않을 것이며, 그는 저로부터 오는 트래픽이 필요하지도 않습니다.

50달러와 오후 시간만 있는 스크립트 키디(Script kiddy)라도 이제 AI를 SaaS에 겨냥하여 무언가를 얻어낼 수 있습니다. 매번 완전한 침해(Breach)가 일어나는 것은 아니겠지만, "앱을 보호할 여력이 없었다"라는 말이 변명이 아니라 선택처럼 들리게 만들기에는 충분합니다.

과거에는 수년간의 훈련이 필요했던 문턱이 이제는 신용카드 한 장이면 통과할 수 있게 되었습니다.

수치는 이것이 단순한 해프닝이 아닌 추세임을 말해줍니다.

이것은 단지 유튜브 채널을 가진 운 좋은 한 명의 이야기가 아닙니다. 이는 측정된 결과이며, 측정값들은 계속해서 같은 지점을 가리키고 있습니다.

Hadrian이 보고한 한 연구에 따르면, 2026년 2월에 발표된 학술 논문을 바탕으로 사이버 보안 교육을 전혀 받지 않은 한 학생이 오픈 소스 공격 보안 프레임워크 (Offensive Security Framework)인 CAI를 사용하여 오스트리아 국가 CTF (Capture The Flag) 대회에서 수개월 동안 훈련한 중급 경쟁자 수준의 성적을 거둔 것을 추적했습니다. 부트캠프(Bootcamp)도, 멘토도 없었으며, 단지 도구(Tooling)가 정찰 (Reconnaissance) 단계의 힘든 작업을 대신 수행했을 뿐입니다. 이를 XP 파밍 (XP farming)이라고 생각하십시오. 다만 그 과정이 자동화되어 있고 캐릭터 시트가 하룻밤 사이에 스스로 채워지는 것과 같습니다.

The Hacker News가 인용한 Sonatype의 데이터에 따르면, 매년 게시되는 **악성 패키지 (Malicious packages)**의 수는 2022년 55,000개에서 2025년 454,600개로 증가했습니다. Penligent이 인용한 Bugcrowd의 2026년 연구에 따르면, 버그 바운티 헌터 (Bug bounty hunters) 중 이미 워크플로 (Workflow)에 AI를 도입한 비율은 82%에 달하며, 주로 자동화 (Automation) 및 코드 분석 (Code analysis)을 위해 사용되고 있습니다. PentestPad가 인용한 HackerOne의 2026년 설문 조사에 따르면, AI 지원 도구를 사용하는 연구자들은 수동 작업보다 더 높은 심각도 (Severity) 분포를 보이며, 매달 28% 더 많은 유효한 보고서를 제출하는 것으로 나타났습니다.

저는 이전에 해커들이 이미 당신보다 AI를 더 잘 사용하는 방법에 대해 글을 쓴 적이 있으며, 이 모든 수치들은 그 사실을 확인해 줄 뿐입니다. 도입이 다가오고 있는 것이 아닙니다. 이미 반대편에서는 그것이 기본값 (Default)입니다.

하지만 이 이야기가 종말론적인 헤드라인처럼 들리지 않게 만드는 부분이 있습니다. 동일한 PentestPad 기사는 독립적인 벤치마크인 CVE-Bench를 지목하는데, 여기서 GPT-4는 설명이 주어졌을 때 알려진 CVE의 87%를 악용(Exploit)할 수 있지만, 공개되지 않은 실제 취약점에 대해서는 스스로 13%만을 찾아냅니다. "흥미로운 것을 발견했다"와 "실제로 침입했다" 사이의 간극은 여전히 넓습니다. AI는 정찰 (Recon) 및 **탐색 (Discovery)**에는 진정으로 뛰어납니다. 하지만 익스플로잇 (Exploit)을 끝까지 수행하는 데에는 여전히 평범한 수준입니다 (메인프레임을 장악하는 Skynet이라기보다는, 당신의 파일을 조용히 읽고 있는 HAL 9000에 더 가깝습니다). 이것이 완전한 자율 해킹이 아닌, 가끔 금을 찾아내는 금속 탐지기에 더 가까운 현재의 솔직한 상태입니다.

감사(Audit) 비용이 들지 않을 때 책임은 누구에게 있는가

이 지점이 바로 혼자서 SaaS를 출시하는 모든 이들에게 흥미로워지는 부분이라고 생각합니다. "내 앱을 감사할 예산이나 기술이 없었다"라는 기존의 방어 논리는 빠르게 설득력을 잃고 있습니다. 만약 20달러짜리 구독 서비스가 오후 한나절 만에 실제 구멍들을 찾아낼 수 있다면, "감당할 여력이 없었다"는 말은 기술적인 한계가 아니라 단지 오후 한나절을 투자하지 않기로 한 결정처럼 보이기 시작합니다.

제 생각에는 (이것이 법적으로 정확히 어디에 위치할지는 틀릴 수도 있습니다만), 에어백이 자동차 제조사에게 합리적인 안전의 기준을 바꾼 것과 마찬가지로, 1인 개발자에게 무엇이 합리적인 **보안 노력 (Security effort)**인가에 대한 기준이 방금 이동했다고 봅니다. 사이드 프로젝트를 출시하기 전에 보안 업체를 고용해야 할 법적 의무가 있다고 말하는 사람은 아무도 없습니다. 하지만 도구의 가격이 저렴해질수록, 현실적으로 점검할 방법이 없었다는 주장은 매달 약해지고 있습니다. 저는 변호사가 아니며, 이것은 법적 조언이 아닙니다. 그리고 이 문제를 기정사실로 받아들이기 전에, 실제로 이 분야에서 활동하는 전문가의 의견을 진심으로 듣고 싶습니다.

제가 계속해서 떠올리게 되는 것은 이 모든 것과는 전혀 관련이 없는, 훨씬 오래된 기억입니다. 아주 오래전, 저는 단순히 복제 방지 기술(copy protection)을 깨뜨리는 스릴을 위해 Amstrad에서 게임을 분해(disassemble)하곤 했습니다. 퍼즐 그 이상의 목적은 없었습니다. 그리고 짜증 나는 점은, 게임이 완전히 크랙되는 순간 그것이 가진 매력이 기본적으로 모두 사라진다는 것이었습니다. 핵심은 게임 자체가 아니라 도전(challenge) 그 자체였기 때문입니다. 왜 이 글을 쓰는 동안 그 기억이 계속 떠오르는지 모르겠지만, 계속 떠오릅니다. 아마도 두 가지 모두 허가 여부에는 상관하지 않고, 무언가를 충분히 파고들었을 때 무엇이 가능한지에 대해서만 관심을 갖는 동일한 종류의 호기심을 포함하고 있기 때문일지도 모릅니다.

1인 창업자(solo founder)에게 실질적인 질문은 "내가 법적 책임을 지는가"가 아니라, "카메라 앞에서 고통스러운 방식으로 직접 깨닫고 싶은가, 아니면 내 방식대로 먼저 알아내고 싶은가"입니다. 이 두 가지는 매우 다른 오후를 만들어낼 것입니다.

누군가 하기 전에 당신의 앱을 감사(Audit)하세요

저는 이미 별도의 글을 통해 이 문제를 깊이 있게 다룬 적이 있습니다. 'vibe-coded' 앱 모음 전반에 걸친 Supabase 및 RLS 설정에 대한 감사였습니다. 2026년 1분기에 점검한 앱의 91.5%가 적어도 하나 이상의 노출된 행 수준 보안 (row-level security, RLS) 취약점을 가지고 있었습니다. 희귀한 버그가 아니었습니다. 빠르게 출시하고 다시 돌아보지 않음으로써 발생하는 전형적인 종류의 문제였으며, 모든 1인 개발자가 너무나 잘 알고 있는 고전적인 "내 컴퓨터에서는 작동하니 프로덕션에 배포하고, 아무도 확인하지 않는다"는 사이클의 결과였습니다.

저의 3-프롬프트 Supabase 감사 방식은 여전히 유효합니다. 누군가 당신의 허점을 찾아내는 모습을 영상으로 찍기 전에, 이번 주에 다음 3가지 사항을 점검하십시오:

• RLS가 활성화된 모든 테이블에 단순히 토글만 켜져 있는 것이 아니라, 실제로 정책(policies)이 부착되어 있는가
• 어떤 API 경로도 인증된 세션(authenticated session)과 대조 확인 없이 클라이언트가 제공한 사용자 ID를 신뢰하지 않는가
• 쓰기 권한이 있는 환경 변수(environment variable)가 프론트엔드 번들(frontend bundle)에 노출되지 않았는가

이 중 그 어떤 것도 보안 배경 지식을 요구하지 않습니다. 필요한 것은 20분의 시간과 실제로 살펴보려는 의지뿐입니다. 이는 제가 _Vibe Coding, For Real_에서 언급했던, 당신의 로컬 환경에서 작동하는 데모와 낯선 이들과의 접촉(실제 사용) 속에서도 살아남는 앱 사이의 간극에 대한 의지와 동일한 것입니다.

출처

• The AI Hacking Boom: What 70 New Offensive Security Tools Mean for Defenders, Hadrian, April 2026
• 2026: The Year of AI-Assisted Attacks, The Hacker News, May 2026
• Pentest AI, What Actually Matters in 2026, Penligent
• How AI Is Changing Penetration Testing in 2026, PentestPad, May 2026

이 포스트에는 제휴 링크가 포함되어 있을 수 있습니다. 링크를 클릭하시면 저에게 소정의 수수료가 지급될 수 있습니다 (귀하에게는 비용이 발생하지 않으며, 제가 매일 여러분의 즐거운 독서를 위해 양질의 기사를 계속 발행하는 데 도움이 됩니다).