사이버보안은 이제 작업증명(Proof of Work)처럼 작동한다

• Anthropic의 LLM ‘Mythos’ 가 복잡한 네트워크 공격 시뮬레이션에서 인간보다 빠르고 정밀하게 수행하며, 제한된 핵심 개발자에게만 접근이 허용됨
• AI Security Institute의 테스트에서 Mythos는 32단계 기업 네트워크 공격 시뮬레이션을 10회 중 3회 완전 성공하며, 토큰 예산을 늘릴수록 성능이 향상됨
• 이 결과는 보안이 공격자보다 더 많은 토큰을 투입해야 방어할 수 있는 구조, 즉 작업증명형 경쟁으로 변하고 있음을 보여줌
• LiteLLM·Axios 공급망 공격 이후, 오픈소스 의존성을 LLM으로 대체하거나 토큰을 투입해 보안을 강화하려는 시도가 확산 중
• 보안은 기술적 창의성보다 자원 투입량이 결정 요인이 되어, 개발 프로세스에 ‘하드닝’ 단계를 추가하는 흐름으로 이어지고 있음

---

보안이 ‘작업증명(Proof of Work)’처럼 작동하는 구조

• Anthropic의 LLM ‘Mythos’ 가 컴퓨터 보안 과제에서 뛰어난 성능을 보여, 일반 공개 없이 핵심 소프트웨어 제작자에게만 접근이 허용됨
  • Mythos는 복잡한 네트워크 공격 시뮬레이션을 인간보다 훨씬 빠르게 수행
  • AI Security Institute(AISI)의 평가에서도 이전 모델보다 한 단계 높은 사이버 공격 수행 능력을 입증
• ‘The Last Ones’ 라는 32단계 기업 네트워크 공격 시뮬레이션에서 Mythos는 10회 중 3회 완전 성공
  • AISI는 각 시도에 1억 토큰(약 12,500달러) 을 사용
  • 테스트된 모델 중 Mythos만이 전체 공격을 완수했으며, 토큰 예산을 늘릴수록 성능이 계속 향상됨
• 이 결과는 보안의 경제학이 “공격자가 쓰는 토큰보다 더 많은 토큰을 써야 방어할 수 있다” 는 단순한 수식으로 귀결됨
  • 보안 강화는 창의성보다 자원 투입량에 의해 결정
  • 이는 암호화폐의 작업증명(Proof of Work) 메커니즘과 유사한 구조로, 더 많은 계산 자원을 투입한 쪽이 승리

새로운 보안 경제의 시사점

• 오픈소스 소프트웨어의 중요성 강화

  • 최근 LiteLLM과 Axios 공급망 공격 이후, 일부에서는 의존성 코드를 AI 에이전트로 재구현하자는 제안이 등장
  • Andrej Karpathy는 “의존성은 재평가되어야 하며, 단순한 기능은 LLM으로 직접 구현하는 것이 낫다”고 언급
  • 보안이 토큰 투입량에 비례한다면, 기업이 오픈소스 라이브러리에 토큰을 투입해 보안을 강화할수록 더 안전해질 가능성
  • 그러나 널리 사용되는 OSS는 공격 가치가 높아 공격자 또한 더 많은 자원을 투입할 유인이 존재

• 개발 프로세스에 ‘하드닝(Hardening)’ 단계 추가

  • 현재 개발자들은 개발 → 코드 리뷰의 2단계 프로세스를 따르며, 각 단계에 다른 모델을 사용
  • Anthropic은 코드 리뷰 전용 서비스(Code Review)를 제공하며, 리뷰당 15~20달러 수준
  • 향후에는 개발 → 리뷰 → 하드닝의 3단계 주기가 일반화될 가능성
    1. 개발: 기능 구현 및 사용자 피드백 기반 반복
    2. 리뷰: 문서화, 리팩터링, 품질 개선
    3. 하드닝: 예산이 허락하는 한도 내에서 자동 취약점 탐색 수행
  • 첫 단계는 인간의 시간, 마지막 단계는 비용이 한계 요인으로 작용

비용 구조와 보안의 한계

• 코드 작성 자체는 여전히 저렴하지만, 보안을 확보하려면 공격자보다 더 많은 토큰을 구매해야 함
• 모델의 추론 효율이 개선되더라도, 보안 강화 비용은 공격 가치에 의해 결정되므로 완전한 비용 절감은 어려움
• 결과적으로, 보안은 기술적 창의성보다 시장 기반의 자원 경쟁으로 전환되는 양상

[GN⁺]

Hacker News 의견들

• 코드베이스 접근권이 핵심임. 지금의 LLM 기반 보안 스캐닝은 사실상 단순한 bash 스크립트 수준으로, 모든 파일을 순회하며 “취약점 찾아줘” 프롬프트를 던지는 식임
  하지만 방어자가 소스 전체를 통제한다면 훨씬 효율적으로 작동할 수 있음. 예를 들어 PR 단위로 변경된 파일만 스캔하거나, 보안 관련 코드에는 더 많은 토큰을 투입할 수 있음. 공격자는 매번 새로 스캔해야 하지만, 방어자는 한 번의 스캔으로 모든 잠재 취약점을 선제적으로 찾을 수 있음
  결국 비용 비대칭성이 존재하며, 방어 측이 효율 면에서 유리해짐. 공격자는 여러 단계의 익스플로잇 체인을 완성해야 하지만, 방어자는 그중 가장 약한 고리 하나만 차단하면 됨

  • 공격자는 많고 방어자는 하나인데, 규모의 경제가 방어자에게 유리하다는 주장은 납득하기 어려움. 코드 접근이 불가능하다고 가정하는 건 보안상 좋지 않음. 모든 보안 리뷰는 소스 접근을 전제로 함
  • 그래도 이런 접근은 소프트웨어 개발 비용을 높임. “누가 우리만 노리겠어” 같은 안일한 태도는 통하지 않음
  • 최근 팟캐스트 Security Cryptography Whatever에서 언급된 것처럼, 지금은 하니스 개선보다 “다음 모델을 기다리는 전략”이 더 효율적이라는 점이 흥미로웠음
  • 문제는 이런 접근이 “한 개발자의 PC가 감염된 공급망 공격” 수준의 사건을 “전체 소스코드 유출 및 자동 감사”로 확대시킬 수 있다는 점임. 이런 세상은 스타트업에게 어두운 숲 같은 환경을 만들 것 같음
  • 방어자는 모든 부분을 강화해야 하지만, 공격자는 단 하나의 취약점만 찾으면 됨

• 기사에서 언급된 AI Security Institute(AISI) 가 흥미로워서 찾아봤는데, DeepMind나 OpenAI 출신 인물들이 주로 참여한 조직이었음. 보안 업계 인사는 거의 없음. 그래서 “시스템을 강화하려면 더 많은 토큰을 써야 한다”는 결론이 다소 AI 업계 중심의 논리처럼 들림. 왜 형식 검증(formal verification) 같은 대안은 언급되지 않았는지도 의문임. NVIDIA가 이런 논리를 GPU 판매에 활용할 수도 있겠다는 생각이 듦

  • 반대 입장을 취할 만한 유명 보안 연구자가 누가 있을지 궁금함. 실제로는 많은 연구자들이 이 주장에 동의하는 듯함. 지금 논의의 초점은 LLM이 fuzzing 수준의 혁신인지, 아니면 그 이상인지에 있음
  • 참고로 AISI는 영국 정부 산하 기관으로, 과학·혁신·기술부(DSTI)에 속해 있음. 다만 그래프를 단순 선형으로 그리는 등 분석 방식은 다소 아쉬움

• Tony Hoare의 말처럼 “소프트웨어 설계에는 두 가지 접근이 있다. 너무 단순해서 결함이 없거나, 너무 복잡해서 결함이 보이지 않거나”라는 인용이 인상적임

  • 완전히 단순하게 만든다고 모든 공격을 막을 수는 없지만, 공격 표면을 줄이는 효과는 큼. 예를 들어 네트워크 메시지를 처리하기 전에 반드시 서명 검증을 하도록 설계하면, 서명되지 않은 메시지를 받아들이기 어렵게 됨. 지금의 많은 시스템은 필요 이상으로 위협 모델이 넓음
  • 하지만 “복잡함”의 기준은 인간과 LLM에게 다름. 인간에게 복잡해 보여도 LLM에게는 단순할 수 있음. 그래서 이 접근이 얼마나 유효할지는 의문임

• 보안은 언제나 상대가 얼마나 돈을 쓰느냐의 게임이었음. LLM이 등장했다고 해서 원리가 달라진 건 아님. Karpathy가 말한 “의존성보다 복사” 철학도 이미 Go 언어의 격언으로 존재함. “보안은 은폐로 얻을 수 없다”는 원칙 역시 오래된 사실임

  • 하지만 은폐(obscurity) 가 완전히 무의미한 건 아님. 방어의 여러 층 중 하나로서 도움이 될 수 있음. 시스템을 완전히 투명하다고 가정해 강화한 뒤, 그 위에 약간의 불투명성을 더하는 게 이상적임
  • “공격자가 쓰는 토큰보다 더 많은 토큰을 써야 방어할 수 있다”는 말은 새롭지 않음. 물리적 보안에서도 마찬가지였음. 결국 AI 시대에도 AI로 AI를 방어해야 함. 우선 개발자들이 쓰는 코드 생성 모델의 프롬프트부터 점검해야 함

• 기사 내용에 대체로 동의함. “영리함으로 점수를 따지 않는다”는 문구는 다소 위험함. 여전히 사이버보안의 본질은 인간 시스템에 있음. GPU 시간을 많이 쓰는 것도 필요하지만, 궁극적으로는 조직의 보안 문화와 규율이 승패를 좌우함. 원자력이나 항공 산업처럼 사고 이후에야 생기는 수준의 규율이 필요함.
  관련 맥락으로 1년 전 이 글이 지금 상황을 거의 예언처럼 설명하고 있음

• “시스템을 강화하려면 공격자보다 더 많은 토큰을 써야 한다”는 주장에 대해, 나는 과거 Ticketmaster API 자동화를 위해 직접 스크립트를 만든 경험이 있음. 그들은 PerimeterX로 방어를 강화했지만, 3일 만에 우회했음. 최근에는 ChatGPT의 Cloudflare Turnstile을 우회하는 방법도 비슷하게 구현했음.
  수천만 달러를 들여 만든 보안 제품들이 실제로는 무용지물임을 보여주는 사례였음
  관련 HN 글

• LLM이 찾아낸 보안 사고들이 정말 새로운 취약점인지, 아니면 기존 보안 지식의 연장선인지 궁금함. 후자라면 왜 우리가 스스로 체계적으로 찾아내지 못하는지 의문임

• 이 연구가 Proof of Work처럼 보이는 이유는, AISI가 “토큰을 더 쓸수록 성과가 계속 증가한다”고 언급했기 때문임. 즉, 공격 성공률이 토큰 소비량에 비례한다는 가정임. 하지만 실험은 32단계 네트워크 침투 시나리오였고, 그걸 완수한 모델은 Mythos 하나뿐이었음. 단순한 코드 라이브러리에서는 수익 체감점이 훨씬 빨리 올 수도 있음
  오픈소스 프로젝트는 방어자와 공격자 모두의 토큰 소비가 많아져서 이 한계점에 더 빨리 도달할 가능성이 있음

  • Mythos가 모든 시도에서 성공한 건 아니며, 실험 네트워크도 실제 방어 체계를 갖추지 않았음. 그래도 AI를 과소평가할 이유는 없음. 3개월 후의 모델은 또 다른 수준일 것임
  • 사이버보안에 대해 잘 모르지만, 32단계에서 33단계로 가는 데 드는 토큰 비용의 증가율이 핵심일 듯함. 방어가 단계별로 독립적이라면 공격 성공 확률은 p^N으로 급감함

• 결국 질문은 이것임 — 인간이 작성한 코드베이스를 보호하는 게 더 저렴한가, 아니면 에이전트 군단이 생성한 코드를 보호하는 게 더 저렴한가

• 지금처럼 모델을 코드베이스 전체에 무작정 던지는 건 비효율적임. 내가 실험해본 결과, 소스에서 싱크까지의 경로 추적(source-to-sink trace) 을 구조적으로 탐색하도록 모델을 조정하면 비용이 크게 줄었음.
  이제는 시스템이 코드 전체의 맥락을 시각화하고 균열 지점을 정확히 짚어내는 시대가 되었음. 이는 소프트웨어 품질 향상에 큰 전환점이 될 것임