antirez가 말하는 'AI 사이버보안은 작업증명이 아니다'의 진짜 의미

무슨 일이 있었냐면요

Redis를 만든 살바토레 산필리포(antirez)가 블로그에 'AI cybersecurity is not proof of work'라는 글을 올렸어요. 제목이 살짝 아리송한데, 쉽게 말하면 이래요. 요즘 AI 업계에서 '안전한 AI'를 증명한답시고 엄청난 양의 테스트, 레드팀 검증, 벤치마크 점수, 정렬(alignment) 연구 자료를 들이미는 관행이 있는데, 이게 비트코인의 작업증명(Proof of Work)처럼 '에너지를 많이 썼다는 사실' 그 자체가 안전의 증거가 될 수는 없다는 주장이에요.

배경을 조금 더 설명할게요. AI 규제 논의가 본격화되면서, 대형 AI 기업들은 '우리 모델은 안전합니다'를 증명해야 하는 압박을 받고 있어요. 그래서 수천 번의 레드팀 공격, 수백 페이지의 시스템 카드(system card), 수많은 벤치마크 수치를 공개하죠. antirez의 지적은 "이런 게 많다고 해서 실제로 안전하다는 보장이 되는 건 아니다"라는 거예요. 오히려 '열심히 했다는 증거의 양'과 '실제 안전성'을 혼동하는 함정이 있다는 얘기죠.

핵심 주장을 풀어볼게요

antirez가 지적하는 첫 번째 문제는 검증 불가능성이에요. 전통 소프트웨어 보안은 취약점이 재현 가능해요. 같은 입력을 주면 같은 버그가 나오고, 패치하면 재현이 안 되죠. 그런데 LLM은 확률적이에요. 레드팀이 어떤 공격 프롬프트로 문제를 재현했다고 해도, 같은 모델에 같은 프롬프트를 넣어도 다음엔 다르게 나올 수 있어요. "A 공격에 강해졌다"는 증명이 "A 계열 공격 전반에 강하다"로 일반화되지 않는다는 거예요.

두 번째는 평가지표의 구조적 한계예요. MMLU, TruthfulQA, HELM 같은 벤치마크에서 높은 점수가 나와도, 실제 배포 환경의 무수한 엣지 케이스를 커버하지 못해요. 벤치마크는 정적인데 공격자는 동적이거든요. 모델이 벤치마크를 학습 데이터로 본 '데이터 오염(contamination)' 문제까지 있으면 점수의 의미는 더 흐려져요.

세 번째는 비대칭성이에요. 방어자(AI 기업)는 무한한 공격 벡터를 전부 막아야 하는데, 공격자는 하나만 뚫으면 돼요. 이 구조에서 '우리 이만큼 테스트했습니다'는 공격자에게 거의 아무 의미가 없어요. 작업증명이 블록체인에서 의미 있는 건, 계산량 자체가 검증 가능하고 합의의 근거가 되기 때문인데, AI 안전 테스트는 그런 수학적 검증 가능성을 갖지 못해요.

그래서 antirez가 대안으로 제시하는 건 대체로 실질적 제한과 투명한 실패 인정 쪽이에요. 모델이 뭘 못하는지를 명확히 밝히고, 위험한 능력은 아예 못 하게 만드는 설계, 그리고 배포 후에도 지속적인 모니터링과 업데이트로 대응하는 방식이죠. "증거의 양"이 아니라 "실제 능력 제한"이 안전을 만든다는 거예요.

업계 흐름에서 어떤 위치일까

이 주장은 최근 AI 보안 연구의 흐름과 맞닿아 있어요. Anthropic의 '책임있는 스케일링 정책(RSP)'이나 OpenAI의 'Preparedness Framework' 같은 프레임워크들이 정량 평가를 강조하는데, 이에 대한 비판도 꾸준히 나와요. 'AI safety washing'이라는 용어도 등장했는데, 실질 효과 없이 안전 활동의 외양만 갖추는 행위를 꼬집는 말이에요.

한편 전통 보안 쪽에는 이미 비슷한 교훈이 있어요. 'ISO 인증 받았다고 해킹 안 당하는 거 아니다', '펜테스트 리포트 두께가 보안 수준을 의미하지 않는다' 같은 격언이죠. antirez의 글은 이 오래된 진실을 AI 시대에 다시 꺼낸 셈이에요. Bruce Schneier 같은 보안 사상가들의 '보안은 프로세스이지 제품이 아니다'라는 명제와도 닿아 있고요.

흥미로운 비교 대상은 형식 검증(Formal Verification)이에요. 항공·의료·금융 분야에서는 수학적으로 특정 속성을 증명하는 방식을 씁니다. AI 안전에서도 형식 검증을 적용하려는 시도가 있지만, 현재 LLM처럼 수천억 파라미터짜리 모델에는 사실상 불가능해요. 이 간극이 바로 'proof of work'식 정량 쌓기로 대체되는 근본 원인이기도 해요.

한국 개발자에게 주는 시사점

첫째, AI 기반 제품을 만드는 분이라면 '안전성 마케팅'의 유혹을 경계해야 해요. 고객이나 규제 당국에게 '우리는 N번 테스트했다'고 강조하는 건 설득력이 점점 떨어지는 방향이에요. 대신 "우리 모델이 무엇을 할 수 없도록 설계했는가", "실패 시 어떻게 탐지하고 복구하는가" 같은 구체적 방어 구조를 이야기하는 게 신뢰를 얻어요.

둘째, AI를 도입하는 기업 쪽 엔지니어라면 벤더의 안전성 주장에 비판적으로 접근해야 해요. 시스템 카드의 벤치마크 점수만 보지 말고, "이 모델이 우리 도메인의 민감 데이터를 다룰 때 구체적으로 어떤 시나리오에서 실패할 수 있나"를 직접 테스트해보는 게 훨씬 가치있어요. 한국의 개인정보보호법이나 금융 규제는 실질 위해 중심으로 접근하므로, 이런 자세가 규제 대응에도 유리해요.

셋째, 보안 연구자 입장에서는 이 논의가 흥미로운 연구 주제가 될 수 있어요. LLM 안전의 '검증 가능한 지표'를 어떻게 설계할 것인가는 아직 열린 문제예요. 재현성 있는 공격 벡터 분류, 능력 제한의 증명 방법, 배포 후 드리프트 탐지 등, 파고들 지점이 많아요.