AI 보안 논쟁에서 HN이 물은 것: 더 많은 tokens가 곧 더 많은 bugs인가

HN에서 AI cybersecurity is not proof of work가 논쟁을 만든 이유는 제목이 도발적이어서만은 아니다. 2026-04-16 10:48:00 UTC에 올라온 이 글은 score 230대와 80개 넘는 comments를 모았고, community는 “more compute wins”라는 직관을 보안 문제에 그대로 적용해도 되는지 따졌다.

Antirez의 주장은 hash collision을 찾는 proof-of-work와 bug discovery가 다르다는 데서 시작한다. Hash search는 충분한 work를 넣으면 조건을 만족하는 input을 찾는 방향으로 보장되지만, code bug는 그런 공간이 아니라는 것이다. LLM이 여러 실행에서 다른 branch를 타더라도, 의미 있는 path가 포화되면 병목은 sampling 횟수 M이 아니라 model intelligence level I가 된다는 논리다.

글은 OpenBSD SACK bug를 예로 든다. 약한 model을 오래 돌린다고 해서 start window validation, integer overflow, NULL이 아니어야 하는 branch 조건을 결합해 exploit-level reasoning까지 도달하는 것은 아니라는 주장이다. 더 작은 model이 문제를 맞힌 것처럼 보일 때도, 실제 이해보다는 bug class pattern matching과 hallucination이 섞일 수 있다고 본다.

HN comments는 이 주장을 그대로 받아들이기보다, 보안의 asymmetry를 더 크게 봤다. Attacker는 exploitable issue 하나만 찾으면 되지만 defender는 발견, patch, deployment까지 해야 한다는 지적이 나왔다. 또 breadth-first search와 depth-first search처럼 search surface에 따라 “더 많은 tokens”와 “더 나은 model”의 가치가 달라진다는 반론도 있었다.

이 thread가 유용한 이유는 AI security 평가가 이제 단순한 benchmark race가 아니라는 점을 보여주기 때문이다. Model이 진짜 vulnerability를 이해했는지, 우연히 suspicious pattern을 찍었는지, exploit을 구성할 수 있는지, patch workflow까지 닿는지는 서로 다른 단계다. HN의 에너지는 여기서 나왔다. AI bug hunting이 강해질수록, 우리는 “찾았다”는 claim보다 어떤 reasoning과 verification chain이 있었는지를 더 세밀하게 봐야 한다.