요약
한 주 사이 대형 보안 사고가 잇따랐고, LLM이 버그 발견부터 공격까지의 시간을 몇 시간으로 줄였습니다.
영국 정부 관련 일을 하는 개발자 드루 실콕이 10월 셋째 주에 몰려 터진 보안 사고를 정리했습니다. 그는 스스로 보안 전문가가 아니라고 밝히면서, 이런 한 주가 앞으로 일상이 되는지 물었습니다.
왜 중요한가
- 버그가 있다는 소식만 퍼져도 몇 시간 안에 자동화된 공격이 시작되는 환경이 됐다는 진단입니다.
- 다만 이번 사고 상당수는 사람이 찾은 평범한 버그였습니다. 그래서 모든 것을 AI 탓으로 돌리는 논의는 지나치다고 봤습니다.
핵심 내용
- PHP2Shell로 불린 PHP 원격 코드 실행(공격자가 서버에서 코드를 돌리는 공격) 취약점은 인터넷의 약 70%에 영향을 준다는 추정이 나왔습니다.
- 이 취약점은 LLM으로 찾았고, 엠바고(약속한 시각까지 공개를 미루는 합의) 전에 정보가 새면서 패치 전부터 공격이 벌어졌습니다.
- 같은 주에 클라우드 업체 레일웨이의 환경 변수 유출과 LiteLLM 악성 버전 배포 사고도 겹쳤습니다.
- 해법으로 코드 전면 비공개, AI 적극 도입, 대응 절차 표준화를 따져 봤지만 모두 비용이나 한계가 크다고 봤습니다.
- 당장 할 일로는 패치 전에 세부 사항을 알리지 않기, 고객 소통 개선, 공격받는다는 전제로 대비하기를 꼽았습니다.
HN 반응
- 미리 통보받는 대형 업체 말고는 정보 없이 대응해야 한다는 불만과, 조율된 공개 관행이 곧 무너질 것이라는 전망이 나왔습니다.
- AI가 만든 코드가 보안에 취약하다는 주장과, 오히려 방어적으로 짜서 평균 품질이 올랐다는 반론이 맞섰습니다.
여기엔 두 가지 측면이 있습니다. 하나는 치명적인 취약점과 익스플로잇이 발견되는 속도가 지금 훨씬 빨라졌다는 점이고, 다른 하나는 발견부터 대규모 악용까지 걸리는 시간이 훨씬 짧아졌다는 점입니다.
LLM이 버그를 전부 찾아서 고치고 나면 발견 속도는 잦아들 거라고들 합니다. 뭐, 그렇게 믿고 싶으시면 그러시든가요. 하지만 그래도 시간 간격이 훨씬 짧아졌다는 문제는 그대로 남고, 그건 당분간 사라지지 않습니다.
업계에서 뭔가를 부수는 게 직업이나 취미인 쪽에 서 계시다면 이 모든 게 아주 흥미진진할 겁니다. 하지만 부서지지 않게 막는 게 일인 쪽에 서 계시다면 정말 최악입니다.
저는 어제 하루를 통째로 날렸습니다. 큰 업체 몇 곳이 뭔가를 발견해서 다른 큰 업체들에게 알렸고, 공개 정보를 "실수로" 충분히 흘려서 다른 모두가 알아차리게 해 놓고는, 나머지 사람들은 대응할 정보도 거의 없는 채로 알아서 하라며 내버려 뒀기 때문입니다.
올해만 벌써 몇 번째 반복되는 패턴입니다. 대형 호스팅 업체 명단에 들어 있으면 무슨 일이 터질지 미리 통보받고 먼저 패치도 받습니다. 거기 못 들면 안됐지만 어쩔 수 없고, 오늘 다른 계획이 없었길 바라야죠.
저 같은 사람들에게 이건 LLM이 제 삶을 실질적으로 더 나쁘게 만드는 또 하나의 방식일 뿐입니다.
협조적 공개(coordinated disclosure)는 조만간 끝날 수밖에 없습니다. 이상적으로는 방어하는 쪽에서 취약점을 발견하면 "선한 편"에게만 알리고 악당에게는 알리지 않는 게 맞죠. 하지만 세상은 그렇게 돌아가지 않으니, 유출할 가능성이 낮은 소수의 중요한 대형 주체에게만 알려서 모두가 알게 되기 전에 최대한 많은 대응을 하자는 식으로 타협했던 겁니다.
이제는 어떤 소프트웨어에 악용 가능한 메모리 문제가 있을지도 모른다는 사실만 알아도, 악의적인 쪽이 LLM을 거기에 들이대서 몇 시간 안에 문제를 찾아낼 수 있습니다. 이건 갈수록 심해질 겁니다.
결국 속도 싸움이 될 겁니다. 취약점을 찾았다면 차라리 곧바로 모두에게 공개하는 게 낫습니다. 인터넷에 노출된 소프트웨어를 운영하는 사람은 누구나 공개되는 취약점을 24시간 지켜보고 자동으로 분류하는 에이전트가 필요해질 겁니다. 업그레이드하든, 보호용 껍데기로 필터링을 강화하든, 사람이 도와줄 수 있을 때까지 서비스 전체를 내리든 말이죠. 그래야 24시간 지켜보다가 자동으로 공격하는 공격 에이전트를 따라갈 수 있습니다.
저는 다음과 같은 식의 첫 익스플로잇이 나오기까지 얼마나 걸릴지 궁금합니다.
악의적인 쪽이 유명 소프트웨어에서 이론상 심각하지만 실제로 악용하기는 쉽지 않은 진짜 취약점을 찾습니다. 예를 들어 RCE로 100% 털릴 수 있지만, 플랫폼 Y에서 커널 버전 Z로 구성 X를 쓰고, 그것도 화요일이어야 하는 식의 익스플로잇입니다.
그 취약점은 막으면서 자기들만 아는 더 위험한 취약점을 슬쩍 여는 패치를 설계합니다. 그 패치를 LLM 리뷰어들에게 몰래 테스트해 보면서, 새로 심은 취약점이 자동 리뷰에서 대체로 걸리지 않을 때까지 방식을 다듬습니다.
그러고는 원래 익스플로잇을 "책임 있게 공개"하면서 친절하게 패치도 공유합니다. 원래 익스플로잇을 급히 고치느라 패치 자체는 건성으로만(클로디하게, 코덱시하게) 리뷰됩니다. 이쯤 되면 이런 일이 하도 많이 반복돼서, 클로드센(ClodSed)이 내놓은 코드 변경을 그냥 적용하고 보는 게 기본이 되어 있습니다.
새 취약점이 결국 발견되더라도 "아, 제 에이전트가 그건 못 잡았네요"라고 그럴듯하게 말할 수 있고, 실제로 그건 사실입니다. 그동안 그들은 자기들만 아는 새 익스플로잇을 씁니다.
이것도 통하지 않습니다. 공격자들은 훨씬 더 동기가 강하고 그런 것들을 주시할 여력도 되니까요.
목표가 취약점을 찾는 것이든 돈을 훔치는 것이든 뭐든, 새 익스플로잇을 찾는 데 모든 에너지를 쏟게 됩니다.
나머지 세상 사람들은 해야 할 다른 일이 있고(사용자 의견 듣기, 서비스 운영하기 등등), 공지가 올라올지도 모른다고 세상 모든 소셜 미디어를 지켜보는 데 공격자만큼 시간을 쓸 수는 없습니다. 정의상 불가능하죠.
그래서 데이터 유출로 잃을 게 많은 곳이라면 시스템의 껍데기를 단단히 강화해서 아예 취약하지 않게 만들든가(제대로 하기가 아주 어렵습니다), 취약점 소식을 듣고 대응하는 과정을 자동화하는 게 좋을 겁니다.
네, 저도 안 믿습니다. 지금 GitHub만 봐도 자기가 뭘 하는지 기초도 모르는 사람들이 바이브 코딩으로 만든 프로젝트로 완전히 쓰레기장이 됐잖아요. LLM을 많이 쓰면 새로운 익스플로잇투성이 코드가 나올 겁니다. 그래도 상황이 정리되고 나면, 이런 익스플로잇이 발견되는 빈도를 LLM 친화적인 기여 정책과 비친화적인 정책에 따라 비교해 보면 확실히 알 수 있을 테니 흥미로울 것 같습니다.
저는 정반대로 봅니다. 이런 바이브 코딩 프로젝트가 최고 실력의 사람이 만든 것보다도 보안 수준이 훨씬 높습니다.
요즘 최상위 에이전트에게 할 일 관리 앱을 만들어 보라고 시켜 보세요. 안티 CSRF, XSS, CSP, 보안 쿠키, HMAC, 로그인 속도 제한, 들어본 적도 없는 온갖 것까지 엔터프라이즈급 보안을 구축하는 걸 보게 될 겁니다.
간단한 OAuth를 구현하라고 시켰더니 들어오는 IP를 사설/공인 서브넷으로 분류하고, 아주 이론적인 DNS 리바인딩 공격에 대한 우회책까지 넣는 걸 봤습니다.
LLM이 뭐든 과하게 설계하길 좋아한다는 건 다들 알잖아요. 정적인 3페이지짜리 블로그를 암호화폐 거래소급 보안으로 바꿔 놓으면서 아주 신나게 놉니다.
그 말이 맞을 수도 있지만, 지금 얘기하는 건 주요 프로젝트들이 쓰는 핵심 라이브러리의 취약점이지, 아무도 신경 안 쓰는 일회성 프로젝트가 아닙니다.
악의적인 쪽은 본래 감수하는 위험이 더 크고, 선한 쪽은 여전히 신중한 고민과 조심성이 필요하다 보니, 익스플로잇이 발견되고 배포되는 속도가 수리되는 속도보다 더 빨리 늘어나는 시점이 오지 않을까 싶습니다. 그렇게 되면 인터넷과 디지털 경제가 대부분 멈춰서 무너지지 않을까요? 이 사이트 사람들 상당수에게는 그게 나쁜 일이겠죠. 어쩌면 편리함이 후퇴하고, 사회에서 기능하려면 대면 상호작용이 더 필요해질 수도 있습니다. 이런 패턴은 이미 고등교육에서 나타나고 있는 걸 볼 수 있습니다. 어쩌면 더 깊은 차원에서는 이게 인류를 낫게 만들지도 모르죠?
제가 읽은 모든 자료가 그렇다고, 이게 새로운 일상이라고 말합니다.
Mythos가 처음 발표됐을 때, 제가 이야기를 나눈 보안 전문가는 거의 전부 그냥 기겁을 했습니다. 지금 제 업무의 상당 부분은 AI가 만든 익스플로잇의 영향을 완화하는 일입니다.
AI가 만들어내는 코드의 양도 이 상황을 더 악화시킬 겁니다. AI가 생성한 코드는 보안에 악명 높게 형편없으니까요.
AI가 생성한 코드가 정말 보안에 악명 높게 형편없습니까?
제 경험상 AI 코드는 아주 방어적이고 '뻔한' 실수를 최소화하는 데 능합니다.
지금 비교 대상이 옛날 모델이 생성한 코드입니까, 아니면 Mythos급 모델입니까?
프롬프트와 테스트 스위트부터 시작해서 어떻게 생성하느냐에 크게 달려 있고, 무엇보다 여러분의 태도가 중요합니다. 보안을 더 챙기려면 시간과 돈이 듭니다.
출시 속도가 전부고 그 밖의 건 무시해도 된다고 생각하는 사람들이 여전히 많습니다. "컴파일되네? 출시해!"는 1990년대 말인데, LLM은 이런 접근을 훨씬 쉽게 만들어 줄 뿐입니다. 산탄총을 맞은 체처럼 보안이 구멍투성이인 기계 생성 소프트웨어가 넘쳐나게 될 겁니다.
프롬프트만의 문제는 아니고, 무엇으로 학습했느냐의 문제이기도 합니다.
요즘은 최전선 모델들이 전반적으로 꽤 괜찮지만, 예전에는 생성된 php/javascript는 미심쩍었고, ts는 조금 나았고, Rust는 일관되게 괜찮았습니다.
README의 최대 너비를 80자로 제한하느냐, 풀 마크다운을 쓰느냐만으로도 나오는 C 코드가 크게 달라질 수 있습니다.
제 생각에는 훨씬 더 안전한 코드를 쓰는 건 꽤 쉽습니다. 의존성을 줄이고, 쓰는 의존성도 필요한 일만 하도록 하고 불필요한 코드가 컴파일돼 들어가지 않게 하면 됩니다. 그렇게 구성하는 건 예전엔 너무 번거로웠지만, 이제는 프롬프트 한 번이면 됩니다.
대부분의 소프트웨어는 보안을 전혀 생각하지 않고 만들어집니다. 보안은 비용이 드니까요. LLM 이전에도 그랬고, LLM이 나왔다고 달라질 것 같지 않습니다.
그런데 이런 생각이 듭니다. LLM은 소유한 회사가 조종하는 것이니, 그 회사들이 어떻게든 보안을 더 낫게 만들 수 있다는 뜻 아닐까요? 물론 양날의 검입니다. 한 회사가 세상 코드의 상당 부분을 읽고 생성할 수 있다는 것 자체가 위험이니까요.
오픈소스 메인테이너로서 확실히 말씀드릴 수 있는 건, 평균적인 PR의 품질은 이제 더 좋아졌다는 겁니다. 제가 겪는 문제는 오히려 일부 사람들이 AI를 여러 방식으로 "쏟아붓고" 오용하는 쪽입니다. 그래도 그 사람들의 AI가 그 사람들보다 코드를 더 잘 씁니다.
저는 AI가 잘 관리되는 라이브러리를 쓰지 않고 그냥 직접 만들어 버리는 쪽을 택할 수도 있다는 게 더 나쁘다고 생각합니다.
아니면 오래된 라이브러리를 쓰기도 합니다.
저희는 "개발자가 어느 정도 거드는" AI 개발을 하고 있는데, AI가 어떤 라이브러리를 쓰겠다고 계획했습니다. 그 라이브러리를 찾아봤더니 GitHub 페이지에 "더 이상 유지보수되지 않음, 다른 라이브러리 Z를 사용할 것"이라고 되어 있었습니다. 그걸 알려 주자 AI가 수긍하고 원래 라이브러리와 새 라이브러리를 비교해 줬는데(도움은 됐습니다), 활발한 개발 여부보다 GitHub 스타 수에 훨씬 큰 비중을 두는 것 같았습니다.
SCA나 SBOM 같은 도구는 여러분이 쓰는 것들이 오래되지 않았는지 확인하려면 여전히 필요합니다. LLM이 해결해 주는 문제가 아닙니다.
프로젝트가 스타 수를 자랑하면 저는 곧바로 불신합니다.
보통 다운로드 수나 스타 수는 VC에게 보여 주는 신호인데, 그래서 간접적으로는 저한테도 부정적인 신호가 됩니다.
바로 이런 부분을 안목 있고 해당 분야 지식이 넓은 사람이 리뷰하면서 알아채야 합니다. 아니면 최소한 에이전트에게 그걸 확인하라고 지시하든가요. 물론 그런 사람이 아직도 그 역할로 고용돼 있다면 말이죠.
많은 프로젝트가 쓰는 의존성 자체가 공격 대상이 되는 걸 생각하면, 그게 가끔은 장점이 될 수도 있습니다.
의사야, 네 병이나 고쳐라?
LLM에게 피드백 루프 안에서, 처음 만들 때의 맥락은 전혀 없는 상태로 자기 시스템을 뚫어 보라고 시키면 어떨까요? 반복하다 보면 '안전한' 상태에 도달해야 하지 않나요(쓰고 싶은 토큰 한도 안에서요)?
제 경험상 적대적 리뷰를 항상 따라 주지는 않습니다.
우리 같은 무지렁이들은 특별한 "보안" 전용 모델을 쓰는 축복을 못 받았기 때문이겠죠.
우리가 나쁜 이유로 익스플로잇을 찾고 있을지도 모르니까요, 아마도요.
LLM이 어디에 사각지대가 있느냐에 달렸습니다.
적대적 수정이라. 마음에 드네요.
코드만이 아니라 소프트웨어를 배포하는 일도 마찬가지입니다. 대화 중에 'AI'가 가장 기본적인 보안 원칙조차 제대로 따르게 하거나 더 안전한 방향으로 가게 하려고 계속 고쳐 주고 이끌어야 합니다. 지금은 시간과 에너지가 넘치긴 하지만 의욕만 앞서서 꼼꼼히 감독해야 하는 인턴 같다는 느낌입니다.
AI 코드는 AI로 테스트하면 됩니다.
(참 멋진 신세계에 살고 있네요)
농담이신 건 알지만, 제 생각엔 이건 계속 어려운 문제로 남을 겁니다.
품질과 보안은 소프트웨어의 창발적 속성입니다. 특히 실제 세계에 배포된 상태의 소프트웨어를 생각하면 더 그렇습니다.
그리고 "좋은 취향"과 좋은 아키텍처, 데이터 모델링의 문제 때문에 AI 코드는 아마 숱한 문제에 열려 있을 겁니다(Claude Code CLI의 문제들이 얼마나 심각해질 수 있는지 보여 주는 훌륭한 사례입니다).
훌륭한 아키텍트가 책임을 맡으면 도움이 되지만, 품질과 보안을 유지할 수 있도록 기능 범위를 작게 유지하려면 엄청난 규율이 필요합니다.
정말 멋지다고요. 소프트웨어 엔지니어링 모범 사례를 따르라고 강제하는 사람은 없지만, 결국 모두가 따르게 되잖아요. 그게 삶을 편하게 해 주거나 코드를 낫게 만들어 주니까요.
테스트나 CI 파이프라인 같은 것도 마찬가지 아닌가요? 이제는 파이프라인에 값싼 단계를 하나 추가해서, 어떤 엔지니어가 SQL 인젝션을 허용하는 식의 멍청한 짓을 하지 않았는지 확인할 수 있게 됐어요.
리뷰 단계까지 올라오는 소프트웨어 품질의 바닥이 영구적으로 올라간 거예요.
디스토피아의 나날이 오겠죠. 여러분은 어떤 구문을 억지로 써야 하고, 그걸 AI 테스터에게 넘기게 됩니다. 테스터는 그걸 다듬어서 돌려주고, 이제 코드를 최전선 AI 세 대에게 넘길 준비가 된 겁니다. 코드의 심판관들이죠.
승인하면 금화를 받고, 아니면 다시 코딩 기계로 돌아가서 인간 토큰 1000개가 차감됩니다. 이건 뇌 칩 임플란트로 이루어지겠죠.
잠깐, 뇌 칩은 언제 등장한 거죠?