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

> Clean Markdown view of GeekNews topic #28594. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28594](https://news.hada.io/topic?id=28594)
- GeekNews Markdown: [https://news.hada.io/topic/28594.md](https://news.hada.io/topic/28594.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-16T19:32:40+09:00
- Updated: 2026-04-16T19:32:40+09:00
- Original source: [dbreunig.com](https://www.dbreunig.com/2026/04/14/cybersecurity-is-proof-of-work-now.html)
- Points: 2
- Comments: 1

## Topic Body

- **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. **하드닝:** 예산이 허락하는 한도 내에서 **자동 취약점 탐색** 수행
  - 첫 단계는 인간의 시간, 마지막 단계는 **비용이 한계 요인**으로 작용

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

## Comments



### Comment 55610

- Author: neo
- Created: 2026-04-16T19:32:41+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47769089) 
- 코드베이스 접근권이 핵심임. 지금의 **LLM 기반 보안 스캐닝**은 사실상 단순한 bash 스크립트 수준으로, 모든 파일을 순회하며 “취약점 찾아줘” 프롬프트를 던지는 식임  
  하지만 방어자가 소스 전체를 통제한다면 훨씬 효율적으로 작동할 수 있음. 예를 들어 PR 단위로 변경된 파일만 스캔하거나, 보안 관련 코드에는 더 많은 토큰을 투입할 수 있음. 공격자는 매번 새로 스캔해야 하지만, 방어자는 한 번의 스캔으로 모든 잠재 취약점을 선제적으로 찾을 수 있음  
  결국 **비용 비대칭성**이 존재하며, 방어 측이 효율 면에서 유리해짐. 공격자는 여러 단계의 익스플로잇 체인을 완성해야 하지만, 방어자는 그중 가장 약한 고리 하나만 차단하면 됨  
  - 공격자는 많고 방어자는 하나인데, 규모의 경제가 방어자에게 유리하다는 주장은 납득하기 어려움. 코드 접근이 불가능하다고 가정하는 건 보안상 좋지 않음. 모든 **보안 리뷰**는 소스 접근을 전제로 함  
  - 그래도 이런 접근은 소프트웨어 개발 비용을 높임. “누가 우리만 노리겠어” 같은 안일한 태도는 통하지 않음  
  - 최근 팟캐스트 [Security Cryptography Whatever](https://securitycryptographywhatever.com/2026/03/25/ai-bug-f...)에서 언급된 것처럼, 지금은 하니스 개선보다 “다음 모델을 기다리는 전략”이 더 효율적이라는 점이 흥미로웠음  
  - 문제는 이런 접근이 “한 개발자의 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년 전 [이 글](https://knightcolumbia.org/content/ai-as-normal-technology)이 지금 상황을 거의 예언처럼 설명하고 있음  

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

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

- 이 연구가 **Proof of Work**처럼 보이는 이유는, AISI가 “토큰을 더 쓸수록 성과가 계속 증가한다”고 언급했기 때문임. 즉, 공격 성공률이 토큰 소비량에 비례한다는 가정임. 하지만 실험은 32단계 네트워크 침투 시나리오였고, 그걸 완수한 모델은 Mythos 하나뿐이었음. 단순한 코드 라이브러리에서는 **수익 체감점**이 훨씬 빨리 올 수도 있음  
  오픈소스 프로젝트는 방어자와 공격자 모두의 토큰 소비가 많아져서 이 한계점에 더 빨리 도달할 가능성이 있음  
  - Mythos가 모든 시도에서 성공한 건 아니며, 실험 네트워크도 실제 방어 체계를 갖추지 않았음. 그래도 AI를 과소평가할 이유는 없음. 3개월 후의 모델은 또 다른 수준일 것임  
  - 사이버보안에 대해 잘 모르지만, 32단계에서 33단계로 가는 데 드는 **토큰 비용의 증가율**이 핵심일 듯함. 방어가 단계별로 독립적이라면 공격 성공 확률은 p^N으로 급감함  

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

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