> 참고: 이 글은 원문 전문을 직접 읽지 못한 채, 제목과 주소에서 드러나는 주제에 공개된 배경 지식을 더해 정리했어요. 주소에 등장하는 PHP2Shell 취약점 사례는 확인하지 못해 다루지 않았으니, 구체적인 내용은 IEEE Spectrum 원문에서 꼭 확인해 주세요.
이자만 내던 시대가 끝나가요
기술 부채라는 말, 한 번쯤 들어보셨을 거예요. 이게 뭐냐면, 지금 빨리 가려고 대충 처리해 둔 코드가 나중에 이자를 붙여 돌아온다는 비유예요. 급할 때 카드로 긁어둔 돈이랑 비슷하거든요. IEEE Spectrum에 실린 글의 제목은 꽤 강렬해요. AI 때문에 우리가 40년 동안 미뤄온 기술 부채를 이제 갚아야 한다는 거예요.
왜 하필 지금일까요? 오래된 코드에 구멍이 있다는 건 다들 짐작하고 있었어요. 다만 그 구멍을 찾는 일이 비쌌거든요. 숙련된 보안 연구자가 몇 주씩 코드를 읽어야 했으니까, 아무도 안 들여다보는 구석의 코드는 사실상 안전한 것처럼 취급됐어요. 쉽게 말해 들키지 않았으니 괜찮다는 논리였죠. AI는 바로 이 전제를 흔들고 있어요.
달라진 건 구멍이 아니라 찾는 비용이에요
오래된 코드가 얼마나 위험할 수 있는지는 역사가 보여줘요. 2014년에 터진 셸쇼크(Shellshock)는 Bash에 1989년 무렵부터 숨어 있던 버그였어요. 25년 동안 아무도 몰랐던 거죠. 같은 해 하트블리드(Heartbleed)는 인터넷 암호화의 기반인 OpenSSL에서 나왔고, 2021년 로그4셸(Log4Shell)은 자바 로깅 라이브러리 하나로 전 세계 서버를 흔들었어요. 공통점이 있어요. 널리 쓰이지만 제대로 들여다보는 사람은 적은 코드였다는 거예요.
그런데 이제 기계가 그 코드를 읽어요. 2024년 11월에 구글의 Big Sleep 프로젝트는 AI 에이전트로 SQLite에서 실제로 악용 가능한 메모리 버그를 찾아냈다고 발표했어요. 2025년 DARPA의 AI 사이버 챌린지(AIxCC) 결승에서는 AI 시스템들이 취약점을 찾는 데서 그치지 않고 패치까지 자동으로 만들어냈고요. 사람이 몇 주 걸리던 일이 컴퓨팅 비용 문제로 바뀌기 시작한 거예요.
패치 이후도 걱정이에요. 패치가 공개되면 공격자는 수정 전후 코드를 비교해서 어떤 구멍이 막혔는지 거꾸로 알아낼 수 있거든요. 이걸 패치 디핑이라고 해요. 예전엔 이 분석에 시간이 걸려서 업데이트할 여유가 조금은 있었는데, AI가 이 과정을 앞당기면 그 여유가 줄어들어요. 오래된 시스템을 다음 분기에 패치하자고 미루는 습관이 훨씬 위험해지는 거죠.
공격과 방어가 같은 도구를 들고 있어요
꼭 나쁜 소식만은 아니에요. 같은 도구를 방어하는 쪽도 쓸 수 있으니까요. AIxCC 결승에서 우승한 Team Atlanta에는 삼성리서치, KAIST, 포스텍 연구자들도 참여했어요. 한국 연구진이 이 분야의 최전선에 있다는 뜻이기도 해요.
부작용도 분명해요. curl 프로젝트는 AI가 만든 저품질 버그 리포트에 시달리다 버그 바운티 프로그램을 접었어요. 찾는 비용은 내려가는데 검증하는 비용은 그대로라, 소수의 오픈소스 메인테이너에게 부담이 몰리는 구조예요. 병목이 찾기에서 고치기로 옮겨가고 있는 셈이에요.
근본적인 해법으로는 메모리 안전 언어로의 전환이 꼽혀요. C나 C++은 메모리를 개발자가 직접 관리하다 보니 작은 실수가 곧 취약점이 되기 쉬운데, Rust 같은 언어는 이런 실수를 컴파일 단계에서 막아주거든요. 안드로이드는 새 코드를 메모리 안전 언어로 쓰는 전략으로 메모리 안전 취약점 비중을 2019년 76%에서 2024년 24%까지 낮췄어요. 오래된 코드를 전부 다시 쓰지 않고 새 코드부터 바꿔도 효과가 난다는 점이 흥미로워요.
한국 개발자라면 지금 뭘 해볼까요
한국에서도 남 일이 아니에요. 오래된 PHP 게시판과 쇼핑몰, 지원이 끝난 프레임워크 위에서 돌아가는 사내 시스템, 담당자가 퇴사한 배치 서버가 곳곳에 남아 있잖아요. 당장 해볼 만한 일을 꼽아봤어요.
- 자산 목록부터 만들기: 뭘 돌리고 있는지 모르면 패치도 못 해요. SBOM(소프트웨어 구성 요소 명세서)은 쉽게 말해 소프트웨어의 성분표예요.
- 지원 종료 버전 걷어내기: PHP 7.x처럼 보안 업데이트가 끊긴 런타임이 우선순위 1번이에요.
- 의존성 업데이트 자동화하기: Dependabot이나 Renovate를 붙이고, 패치가 나오면 바로 배포할 수 있는 파이프라인을 갖춰두세요.
- 우리 코드에 먼저 AI 돌려보기: 공격자보다 먼저 살펴보자는 거예요. 다만 결과는 사람이 꼭 검증해야 해요.
마무리
한 줄로 정리하면, AI가 바꾼 건 구멍의 개수가 아니라 구멍을 찾는 가격표예요. 들키지 않아서 안전했던 코드는 이제 안전하지 않아요.
여러분 회사에서 가장 오래됐는데 아무도 손대고 싶어 하지 않는 시스템은 뭔가요? 그 시스템을 지금 고치자고 설득한다면 어떤 근거를 들겠어요?
🔗 출처: Hacker News