Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 취약점 발견 속도가 빨라지고 대응 시간이 짧아지는 현상을 지적하며, 기존의 패치 및 보안 공개 방식의 한계를 비판합니다. 공격 에이전트가 자동화되면서 방어 역시 상시 감시와 자동화된 필터링으로 진화해야 하며, 개발 과정에서의 근본적인 보안 투자가 필요함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기보안 부채는 시간이 지나면 줄어들 것임. 오래된 소프트웨어는 패치되거나 폐기되고, 새 소프트웨어는 보안 검사와 테스트를 거치게 됨.
이 변화를 매우 긍정적으로 봄. 랜섬웨어 조직과 러시아·이스라엘·미국 정보기관은 이미 이런 취약점 일부를 알고 있었고, 이는 우리가 실제로 얼마나 취약했는지 보여줌. 누군가에게는 사소한 버그가 다른 누군가에게는 생사가 걸린 사안일 수 있음. 이제 기업도 보안 평가, 샌드박싱과 시스템 수준 격리, 정형 검증에 투자해야 하는 환경이 됨.
장기적으로는 작은 나라와 개인의 주권을 첩보 활동으로부터 지키는 데 도움이 될 것임. 전환기에 유지보수자들이 고생하는 것은 안타깝지만, 결국 누구나 자기 컴퓨터를 신뢰할 수 있는 더 나은 세상이 될 것으로 봄.
치명적 취약점과 공격 기법의 발견 속도가 빨라지는 것과, 발견부터 대규모 악용까지의 시간이 짧아지는 것은 별개의 문제임. LLM이 모든 버그를 찾아 고치면 속도가 잦아들 것이라는 낙관론을 받아들여도, 짧아진 대응 시간은 당분간 그대로임.
공격하는 쪽에는 흥미진진하겠지만 방어가 업무인 쪽에는 정말 고역임. 어제도 대형 업체들이 취약점을 발견해 자기들끼리 알린 뒤, 다른 이들도 눈치챌 만큼 정보를 흘리고는 대응에 필요한 정보는 거의 주지 않아 하루를 통째로 날렸음.
올해만 이런 일이 여러 번 반복됨. 소수의 대형 호스팅 업체는 사전 통지와 패치를 받고, 나머지는 그날 계획을 포기해야 함. 내게는 LLM이 실생활을 악화시키는 또 하나의 경로임.
조율된 취약점 공개도 머지않아 중단해야 할 것임. 선의의 방어자에게만 알릴 수 없으니, 비밀을 지킬 가능성이 큰 주요 업체 몇 곳에 먼저 알려 공개 전 피해를 줄이는 절충안을 써왔음.
하지만 이제는 특정 소프트웨어에 악용 가능한 메모리 문제가 있다는 단서만으로도 공격자가 LLM을 돌려 몇 시간 안에 취약점을 찾을 수 있음. 결국 자동화된 대응 속도 경쟁이 될 것임. 발견 즉시 모두에게 공개하고, 인터넷에 노출된 서비스를 운영하는 쪽도 상시 감시 에이전트로 업데이트, 방어 필터 강화, 필요하면 서비스 중단까지 자동 처리해야 공격 에이전트를 따라갈 수 있음.
LLM이 모든 버그를 찾아 고칠 것이라는 전망은 나도 믿지 않음. 지금 GitHub에는 자신이 무엇을 만드는지도 모른 채 바이브 코딩으로 쏟아낸 프로젝트가 넘쳐나며, 새로운 공격 경로가 가득한 코드도 계속 생길 것임. 상황이 진정된 뒤 LLM 기여를 허용하는 프로젝트와 제한하는 프로젝트의 취약점 발견 빈도를 비교하면 흥미로울 것임.
공격자는 위험을 더 쉽게 감수하지만 방어자는 신중하게 판단해야 하니, 취약점 발견·악용 속도가 수정 속도를 추월하는 시점이 오지 않을까? 그 결과 인터넷과 디지털 경제가 사실상 마비될 수도 있을까? 편의성이 후퇴하고 사회생활에 대면 접촉이 더 많이 필요해질 수도 있음. 고등교육에서는 이미 그런 흐름이 보이는데, 더 깊은 차원에서는 인류에 도움이 될 가능성도 있지 않을까?
발견 속도가 잦아든다는 전망은 유지보수 단계의 프로젝트에만 해당함. 매 릴리스를 최상급 에이전트로 검사하거나 코드 검토에 더 투자하지 않는 한, 새 기능은 새 버그를 만들어냄. 과거의 찾기 쉬운 취약점이 소진되면 속도는 줄겠지만 경계 수준은 예전보다 높아야 함.
패치 배포부터 설치까지 걸리는 시간도 더 엄격하게 관리해야 함. 가용성 요구가 높은 곳은 패치 테스트 시간을 줄이거나 유지보수 시간을 유연하게 잡아야 할 수 있음. 매달 Patch Tuesday 이후 한두 시간만 확보하는 방식으로는 부족함.
더 큰 문제는 발견부터 패치 출시까지의 시간 압박임. 소문만 돌아도 공격자들이 탐색에 나서므로, 서두르다 새 결함을 만드는 패치를 낼 수 있음. 보안 업데이트와 중대한 버그 수정만 받는 명시적 LTS 릴리스가 늘어나면, 대다수 사용자의 공격 표면과 오류 가능성을 줄일 수 있을 것임.
업계에는 오래전부터 보안 투자가 부족했고, 이제는 개발 과정에서 손을 떼는 사람들도 늘어나고 있음. AI 도구로 소프트웨어를 개선할 수 있다고 보지만, 현재의 유인 구조가 그 방향으로 이끌지는 회의적임.
언제부터 사이버 보안을 그냥 ‘cyber’라고 줄여 부르게 된 것인지 궁금함. 요즘 자주 보이는데, 의미도 맞지 않고 어리석은 표현이라고 느낌.
미군의 영향이 컸음. ‘nuclear’를 ‘noo-kew-la’로 발음하는 이들이 만든 용어이기도 함.
내가 읽은 자료들은 모두 이것이 새로운 일상이 됐음을 가리킴. Mythos가 처음 발표됐을 때 내가 대화하는 보안 전문가들은 거의 모두 크게 놀랐고, 이제 내 업무 상당 부분도 AI가 만든 공격 기법의 영향을 줄이는 데 쓰임. AI 생성 코드의 보안 품질도 악명 높게 나쁜 편이라, 코드 생산 속도가 빨라질수록 상황이 더 악화될 것임.
AI 생성 코드가 정말 보안에 취약한가? 내 경험으로는 상당히 방어적으로 작성하고 명백한 실수도 잘 피함. 예전 모델을 말하는 것인지, Mythos급 모델을 말하는 것인지 궁금함.
AI가 만든 코드를 AI로 테스트하면 되는 셈임. 참 멋진 신세계임.
취약점 탐지와 안전한 코드 작성 사이의 비대칭이 왜 생기는지 설명해 줄 수 있을까? 결함을 잘 찾아내고 공격 도구까지 작성하는 모델이, 정작 시스템을 만들 때 같은 결함을 피하지 못한다는 이유가 궁금함. 막고 싶은 공격 유형을 지시하면 그에 견디는 시스템을 만들 수 있어야 하지 않을까?
과거에는 그랬겠지만, 지금 AI는 사람이 작성해 수년간 남아 있던 취약점을 찾는 데 도움을 주고 있음. 우리 쪽은 고객이 신고하는 문제가 줄고, 훨씬 엄격해진 침투 테스트도 모두 통과하고 있음. 하나의 관측에 불과하지만 보안·운영 분야 지인들에게도 비슷한 이야기를 듣고 있음.
내가 아는 보안 실무자 대부분은 Mythos를 크게 걱정하지 않았음. 보안 제품을 파는 쪽이 수익을 위해 공포를 퍼뜨렸다고 봄. 숨어 있는 취약점은 예전에도 있었고 앞으로도 있을 것임.
실무자들이 정말 우려한 것은 LLM이 공개정보 수집과 맞춤형 이메일 작성, 음성·영상 모방을 할 수 있게 됐을 때임. 실제 손실 대부분이 여기서 발생하는데도 관심은 드문 고급 공격에 쏠림. 특이한 공격이 더 잘 팔리기 때문임.
내가 보기에 진짜 위험은 모든 엔지니어를 저품질 코드의 상시 생산자로 만드는 것임. 이로 인해 세상은 계속 더 공격하기 쉬워질 것임.
요즘 소프트웨어 품질을 자주 비판했지만 나 역시 우쭐할 처지는 아님. 직접 작성하고 완벽하다고 확신하던 성숙한 패키지들에 LLM을 돌렸더니, 다행히 심각하지는 않아도 결함이 발견됨. LLM은 판도를 바꾸는 도구라고 봄. 어젯밤 대화한 친구는 PHP2Shell을 사람이 혼자 찾기는 어려웠을 것이며, 공식 발견 전부터 일부가 알고 있었던 정황상 여러 LLM이 찾았을 가능성이 있다고 봤음.
코드 작성에 LLM을 쓰는 데 어떤 입장이든, 자기 코드의 보안 점검에는 활용하고 최대한 방어를 강화해야 함.
오래된 소프트웨어에도 LLM을 돌려보면 품질이 나빴다는 걸 알 수 있음. 소프트웨어 품질 문제는 늘 존재했고, 정형 검증을 거친 소프트웨어는 극히 드묾. 학교에서 우연히 Netware의 버퍼 오버플로를 발견했지만, 당시에는 그게 무엇인지도 몰랐음.
LLM에 비교적 반대하는 나도 자기 코드의 버그 검사에는 써야 한다는 데 동의함. 피할 만한 상황은 윤리적으로 반대하면서 재미로만 배포하는 경우, 또는 미출시 제품의 데이터가 학습에 쓰여 지식재산 문제가 생길까 우려하는 경우 정도임. 나도 후자에 해당하는 프로젝트가 있어 출시 직전에 LLM으로 검사할 계획임.
겉보기에는 멀쩡하고 살기 편한 집도 검사관이 들여다보면 부실한 배선이나 시공 같은 결함이 드러남. 잠재된 결함은 임계점에 도달해야 체감하는 경우가 많음. 지금 집에도 고칠 곳이 여럿 있겠지만 누수·화재·붕괴가 생기기 전까지 모를 수 있음. 몸속 건강 문제도 비슷하니, 이번 기회에 검진을 받아볼 만함.
나도 같은 경험을 했고 Linus Torvalds도 그런 듯함. LLM 보조를 바이브 코딩과 동일시하는 사람이 너무 많지만, 품질이 중요할 때 진가를 발휘하는 분야는 분석이라고 봄. 정적 분석기, 새니타이저, 퍼저에 이어 LLM도 개발 도구 목록에 넣을 수 있음.
여기서 AI는 생각을 대신하는 게 아니라 놓친 부분을 돌아보게 하고, 다음 결정은 개발자가 내리게 함. 이해 부족이나 코드에 대한 책임 상실과는 정반대임. 오히려 개발이 느려질 수 있지만, 꼼꼼하게 전진하기 위한 좋은 느림임.
사람이 발견하기 어려운 버그였다는 데는 반대함. 요즘 C를 많이 쓰지는 않지만 longjmp가 위험 신호라는 것은 수십 년 전부터 알고 있었음. 그 이유는 Dijkstra가 1968년 CACM에 쓴 유명한 편지에서도 폭넓게 다뤄졌으며, 특정 키워드 하나에만 국한된 논점이 아님. 이번 PHP 코드는 살펴보라고 경보를 울리는 수준이었음.
20년 전에는 다른 메모리 부족 처리 방식의 성능 손실이 컸고 메모리 안전성 문화도 약했으니 이해할 여지가 있음. 하지만 2026년에는 공격 빈도와 피해 규모를 고려해 비행 제어 소프트웨어 같은 기준을 적용할 이유가 충분함. 의도대로 동작해도 추론하기 너무 어려운 방식은 사용 자체를 결함으로 취급해야 함.
새로운 경쟁 환경이지만 이 상황이 영원히 이어지지는 않을 것임. 대부분의 소프트웨어는 끝없이 패치와 릴리스를 쏟아내지 않으며, 성숙하면 대체로 완성 단계에 들어감.
방대한 소프트웨어를 취약한 채로 방치할 수는 없으니 대형 코드 호스팅 플랫폼에서 넉넉하게 제공하는 Dependabot 2.0 같은 도구가 등장할 것으로 봄. 변경하지 않는 코드에 새 종류의 버그가 저절로 생기지는 않음. 매일 밤 최신 보안 모델로 침투 테스트를 돌리고, 최선을 다했다는 확신을 갖고 아침을 맞을 수 있을 것임.
아쉽게도 LLM은 일주일에 셀 수 없이 많은 릴리스를 내는 일도 너무 쉽게 만들어줌.
반면 취약점 수정도 훨씬 쉬워짐. 오늘은 DeepSeek 토큰 비용 몇십 센트와 약 15분만으로, 복잡하고 취약한 PHP 7.x 코드를 보안 패치가 모두 적용된 최신 8.3 버전으로 올렸음. LLM이 없었다면 앱 자체를 폐기할지 진지하게 논의했을 것임.
AI가 있는 환경에서 소프트웨어가 성숙하면 완성된다는 관점은 낡았다고 봄. 대규모 재작성과 기존 코드베이스 수정이 쉬워지고 비개발자의 기여 장벽도 낮아짐. 많은 소프트웨어가 정체된 것은 확장 수요가 없어서가 아니라 변경의 마찰과 비용이 한계에 이르렀기 때문임. 아직 새 시대의 초입이므로 오늘의 전제가 내일도 유효할지는 알기 어려움.
단, 대부분의 소프트웨어는 성숙 단계에 도달하지 못함. 내가 자주 쓰는 소프트웨어는 거의 모두 한 달에 한 번 이상 업데이트됨. 지금도 Chrome에는 재실행 버튼이, Ollama에는 업데이트 표시가 떠 있고 Visual Studio Code 확장 두 개도 재시작을 기다림. 그래도 누군가 유지보수하고 있다는 점은 다행임.
반면 일반적인 기업 앱 개발팀은 치명적 취약점 수정 SLA가 30일 정도이며, 그 기간을 넘겨야 기한 초과로 처리됨. 안타깝게도 애플리케이션 보안 업무에서 직접 겪은 현실임.