AI가 암호를 깨기 시작했다 — Claude의 암호 취약점 발견이 남긴 진짜 질문

암호학은 오랫동안 AI의 마지막 성역처럼 여겨졌습니다. 코드 리뷰나 버그 헌팅은 몰라도, 수학적 증명으로 무장한 암호 알고리즘만큼은 통계적 패턴 학습으로 뚫릴 리 없다는 믿음이 있었거든요. 그런데 최근 Anthropic이 Claude를 활용한 암호 분석 연구 결과를 내놓으면서, 이 믿음의 전제부터 다시 따져봐야 하는 상황이 됐습니다.

먼저 솔직하게 말씀드리면, 이 주제는 지금 커뮤니티에서 뜨겁게 논의되는 화제는 아닙니다. 최근 한 달간 레딧에서 관련 스레드를 찾아봤지만 유의미한 토론은 거의 없었습니다. 그만큼 대중적 화제가 되기엔 진입 장벽이 높은 영역이라는 뜻이기도 하고, 동시에 업계가 아직 이 변화의 무게를 제대로 계산하지 못하고 있다는 신호이기도 합니다.

암호가 “안전하다"는 말의 진짜 의미

여기서 짚고 갈 구분이 하나 있습니다. AI가 AES나 RSA 같은 알고리즘 자체를 수학적으로 깨는 것과, 그 알고리즘을 구현한 코드에서 허점을 찾는 것은 완전히 다른 이야기입니다.

전자는 여전히 요원합니다. AES-256을 무차별 대입으로 뚫으려면 우주의 나이보다 긴 시간이 필요하고, 이건 LLM이 아무리 똑똑해져도 바뀌지 않습니다. 수학은 수학이니까요.

문제는 후자입니다. 현실에서 암호가 깨지는 대부분의 사례는 알고리즘이 아니라 구현에서 나옵니다. 난수 생성기가 예측 가능하거나, 상수 시간 비교를 하지 않아 타이밍 공격에 노출되거나, nonce를 재사용하거나, 패딩 검증을 잘못 처리하는 식입니다. 하트블리드도, ROCA 취약점도, 소니 PS3의 ECDSA 참사도 전부 이 범주였습니다.

그리고 이 영역이야말로 LLM이 가장 잘하는 일에 가깝습니다. 코드를 읽고, 패턴을 알아보고, “여기 이상하다"고 짚어내는 것 말이죠.

AI가 암호 코드에서 잘 잡아내는 것들

실무자들이 관찰한 바를 정리하면, LLM이 유독 강한 지점이 있습니다.

사이드채널 후보 탐지가 대표적입니다. 비밀 값에 따라 분기하는 조건문, 조기 반환하는 비교 함수처럼 타이밍 정보를 흘리는 패턴은 사람 눈에는 지루하고 놓치기 쉽지만 AI에게는 명확한 신호입니다.

프로토콜 상태 기계의 빈틈도 그렇습니다. 핸드셰이크 과정에서 특정 순서로 메시지를 보내면 인증 단계를 건너뛸 수 있는 경로 같은 것들인데요. 사람이 손으로 모든 경우의 수를 따라가려면 며칠이 걸리는 작업을 AI는 훨씬 빠르게 훑습니다.

API 오용 패턴은 더 흔합니다. 암호 라이브러리는 대부분 안전하게 만들어져 있지만, 쓰는 사람이 잘못 씁니다. ECB 모드를 쓴다든지, IV를 하드코딩한다든지 하는 식이죠. 이런 건 AI가 거의 실수 없이 잡아냅니다.

반대로 AI가 약한 지점도 분명합니다. 새로운 수학적 공격 기법을 창안하는 일, 그러니까 차분 공격이나 격자 기반 공격 같은 걸 처음부터 설계하는 작업은 여전히 인간 연구자의 몫입니다. 하지만 기존 기법을 새로운 대상에 적용하는 일은 이미 AI가 상당 부분 감당합니다. 그리고 실전 취약점의 대부분은 여기서 나옵니다.

비대칭은 어느 쪽으로 기우는가

이 지점에서 논쟁이 갈립니다.

공격자 쪽에 유리하다는 관점은 이렇습니다. 방어자는 모든 구멍을 막아야 하지만 공격자는 하나만 찾으면 됩니다. AI가 탐색 비용을 낮추면 그 한 개를 찾을 확률이 올라갑니다. 게다가 공격자는 오탐을 감수할 수 있습니다. AI가 100개를 지목했는데 99개가 헛다리여도, 나머지 1개가 진짜면 성공이니까요.

방어자 쪽에 유리하다는 반론도 만만치 않습니다. 암호 코드는 세상에 그렇게 많지 않습니다. OpenSSL, BoringSSL, libsodium 같은 핵심 라이브러리는 손에 꼽고, 이미 감사팀과 퍼저가 붙어 있습니다. AI 감사를 CI 파이프라인에 넣으면 취약점이 배포되기 전에 잡히죠. 코드가 릴리스되기 전에 방어자가 먼저 훑는다는 건 구조적 우위입니다.

제 판단은 이렇습니다. 장기적으로는 방어 우위, 단기적으로는 공격 우위입니다. 방어자가 AI 감사를 파이프라인에 붙이는 데는 시간이 걸립니다. 조직의 승인 절차, 오탐 처리 비용, 도구 도입 예산 같은 게 다 걸림돌이죠. 공격자에게는 그런 마찰이 없습니다. API 키 하나면 오늘부터 시작할 수 있습니다.

그리고 진짜 위험은 잘 관리되는 OpenSSL이 아닙니다. 아무도 감사하지 않는 수십만 개의 사내 암호 코드, 10년 전에 짜여진 IoT 펌웨어, 유지보수가 끊긴 오픈소스 라이브러리들입니다. 이런 코드에 AI를 풀어놓으면 뭐가 나올지 아무도 모릅니다.

그래서 뭘 해야 하나

당장 실무에서 할 수 있는 일이 있습니다.

자체 암호 구현이 있다면 지금 AI 감사를 돌려보세요. 어차피 공격자도 곧 돌립니다. 먼저 보는 쪽이 유리합니다.

암호 관련 코드를 별도로 태깅해서 관리하는 것도 방법입니다. 어디에 암호가 쓰이는지조차 모르는 조직이 생각보다 많습니다. 목록이 없으면 감사도 없습니다.

그리고 AI가 지목한 것을 그대로 믿지 마세요. LLM은 그럴듯한 오탐을 자신 있게 내놓는 데 아주 능합니다. 암호 영역에서는 잘못된 “수정"이 원래 코드보다 위험할 수 있습니다. 검증 없는 패치는 패치가 아닙니다.

마무리

암호학이 특별했던 이유는 수학이 어려워서가 아니라, 그걸 제대로 다룰 줄 아는 사람이 극소수였기 때문입니다. AI는 그 희소성을 무너뜨리고 있습니다. 수학적 난이도의 벽은 그대로지만, 그 벽 앞에 설 수 있는 사람의 수는 폭발적으로 늘어난 셈이죠.

여기서 던져볼 질문이 있습니다. 여러분 조직의 코드베이스에 암호 관련 코드가 몇 줄이나 있는지, 마지막으로 감사받은 게 언제인지 알고 계신가요. 대부분은 모릅니다. 그리고 그 무지가 지금까지는 별문제가 아니었습니다. 뚫으려면 전문가가 필요했으니까요.

이제 그 전제가 흔들리고 있습니다.