작성자: 디지털 생명 카즈크
어젯밤은 아마도 네트워크 보안의 악몽이었을 것이다.
그리고 많은 엔지니어에게는 잠 못 이루는 밤이기도 했다.
다만 이렇게 말할 수밖에 없다. 우리의 시대와 사회 전체가 AI의 가속 속에서 모두 진땀을 흘리게 될 것이라고.
일의 경위는 이렇다.
먼저 그저께, 즉 10월 20일 밤 11시가 조금 넘어서 Hacker News에 갑자기 글이 하나 올라왔다.
제목이 엄청나게 무서웠다. CVSS 10.0짜리 PHP 원격 코드 실행 취약점 두 개가 곧 공개된다는 내용이었다.
글을 올린 사람은 스스로 "출처: 나만 믿어라(trust me, bro)" 외에는 아무런 증거가 없다고 적었고, 심지어 취약점 번호까지 덧붙였다.
하지만 이런 글은 인터넷에서 하루에도 백 개씩 볼 수 있어서 아무도 진지하게 받아들이지 않았다.
그런데 이 글은 몇 시간 뒤 watchTowr라는 보안 회사에 의해 확인됐다. 그들의 원래 말은 이랬다. "우리는 원래 목요일까지 기다려야 했는데."
이러니 난처해졌다. 이 취약점은 엄청난 규모였고 이미 유출 상태에 있었기 때문에, 정말 마음먹은 사람이라면 벌써 악용을 시작할 수 있었다. 하지만 PHP 공식 보안 업데이트는 아직 패키징 중이었고, 원래 22일 밤에 업데이트될 예정이었다. 그런데 순식간에 이틀의 공백이 생겨버렸다. 만약 이 이틀 사이에 취약점이 악용되어 뚫리기라도 한다면, 그 결과는 상상조차 하기 어려웠다.
한 시간여가 더 지나자 PHP 공식 측이 급히 예고를 내놨다. 원래 10월 22일로 예정됐던 보안 업데이트를 부득이하게 21일 밤 10시(베이징 시간)로 앞당겨, 가능한 한 시간을 줄이겠다는 것이었다.
그런데 공식 예고가 막 나가자마자 더 황당한 일이 벌어졌다.
이 두 취약점을 발견하는 데 참여한 Calif라는 보안 회사가 실수로 공격 시연 영상을 인터넷에 올려버린 것이다. 이 세상이 거대한 임시방편 집단이라는 사실을 충분히 보여주는 일이었다.
영상에서 그들은 이 취약점을 어떻게 활용해 여러 표적에서 공격 검증 프로그램을 성공적으로 실행하는지 보여줬다. 영상은 곧바로 삭제됐지만 어쩔 수 없었다. 손 빠른 누군가가 이미 저장해 두었고, 커뮤니티에서 대대적으로 퍼지기 시작했다.
이제 완전히 일이 커졌다.
원래 사람들은 심각한 취약점 두 개가 있다는 것만 알았지, 구체적으로 어떻게 공격하는지조차 몰랐다. 그런데 이제는 공격 시연 영상까지 생겼으니, 손잡고 하나하나 가르쳐 주는 것만 남은 셈이었다.
그리고 온갖 터무니없는 AI 가속 아래에서 보안 연구자들은 재현을 가속하기 시작했고, 인터넷에는 이 취약점을 악용할 수 있다고 주장하는 코드들이 속속 등장하기 시작했다.
그리고 이때, 보안 취약점을 고칠 수 있는 패치가 모든 사람이 정식으로 내려받을 수 있게 배포되기까지는 아직 16시간이 남아 있었다.
생사를 가르는 16시간이었다. 예전 같으면 악의를 가진 사람이 이렇게 짧은 시간 안에 대규모 공격을 감행하기 어려웠을지도 모른다. 하지만 지금은 AI 시대다. 16시간은 AI로 가속된 사람들에게는 어쩐지 너무 긴 시간처럼 느껴졌다.
더 황당한 것은, 21일 오후 3시 41분에 컨테이너 이미지를 만드는 한 회사가 약속된 시간보다 6시간여나 일찍, 이미 패치가 적용된 이미지를 배포해 버렸다는 점이다. PHP 재단은 곧바로 욕을 퍼부었다. "여러 주에 걸친 다자간 조율 작업을 무시했다."
왜냐하면 요즘 세상에, 아는 사람이라면 새 버전과 옛 버전의 코드를 AI에게 그냥 무차별 대입으로 비교시키기만 해도 취약점이 어디 있는지 바로 알 수 있기 때문이다. AI로 패치를 연구하고, AI로 취약점을 역분석하고, 다시 AI로 공격 프로그램을 개발한다.
하지만 수많은 정상적인 웹사이트의 관리자는 아직 직접 설치할 수 있는 업데이트 패키지를 받지 못했다. 이는 공격자가 사실상 천리안을 얻어 먼저 치고 나간 것과 다름없었다.
그리하여 붕괴가 일어났다.
21일 하루 동안 네덜란드의 디지털 신원 시스템, 의회 웹사이트, 심지어 국가사이버보안센터의 자체 웹사이트까지 차례로 다운됐다.
핀란드 정부의 IT 서비스 업체도 일부 서비스를 중단했고, 미국의 인사 소프트웨어 회사 BambooHR는 서비스를 곧바로 중단하며 고객에게 급여 지급 관련 업무가 영향을 받을 수 있다고 알렸다. 일본의 niconico와 pixiv는 긴급 점검에 들어갔다.
일본에는 PHP 웹사이트가 정말 너무 많아서, 다카이치 사나에까지 X에 글을 올려 밤 10시 PHP 업데이트가 배포될 때까지 예방적으로 서비스를 내릴 것을 권고했다.
프로그래밍 언어 하나의 취약점 때문에 다카이치 사나에가 한밤중에 트윗을 올리고, 여러 나라 정부가 스스로 인터넷 선을 뽑아버리는 광경. 솔직히 말해서, 나는 이런 장면을 본 적이 없다.
그렇게 세상은 비틀거리며 이 십수 시간을 버텨냈다.
이 십수 시간 동안 수면 아래의 어두운 면에서 무엇을 얻었는지는 아무도 모른다.
밤 10시, PHP 보안 업데이트가 올라왔다. 이 두 가지 심각한 취약점에 대해서는 완전한 완화 조치가 전혀 없었고, 업데이트가 유일하게 안전한 선택이었다.
동시에 OpenAI가 나서서 인정했다. PHP의 이 두 가지 초대형 보안 취약점은 GPT의 도움으로 발견됐다는 것이다.
게다가 이 취약점은 무슨 새 모델이 해낸 것도 아니고, 몇 달 전에 GPT-5.6 Sol로 발견한 것이었다. 그러니 상상해 보라. 만약 이런 대형 모델 회사들의 아직 공개되지 않은 내부의 더 강력한 모델로 훑어본다면, 전 세계의 온갖 네트워크 인프라가 정말로 전부 문제가 있을지도 모른다...
동시에 OpenAI는 이번에 긴급히 스킬(skill) 하나를 공개해, 당신의 웹사이트가 영향을 받을지 여부를 파악하는 데 도움을 주도록 했다.
여기서 모두가 반드시 유의해야 할 점이 있다. 만약 당신의 웹사이트에서 PHP를 사용하고 있고, 아직 이 소식을 모른다면, 이 글을 보는 즉시, 즉시 버전을 업데이트하기 바란다. 그리고 친구들에게도 널리 알려주길 바란다.
알고 있다. 많은 사람이 "그냥 취약점 하나 아니냐, 뭘 그리 호들갑이냐"라고 말할 것이다.
그렇다면 내 생각에는, 이번 일이 왜 이렇게 커졌고 전 세계의 반응이 왜 이렇게 과했는지 이해하려면 먼저 PHP가 무엇인지 알아야 한다.
나도 무슨 전문가가 아니니, 내가 아는 언어로 최대한 설명해 보겠다.
먼저, 우리 모두 알다시피 브라우저에서 웹페이지를 열면, 서버 쪽에서 그 페이지에 무엇을 표시할지 그 자리에서 계산해 내야 한다. 예를 들어 당신이 누구인지, 장바구니에 무엇이 있는지, 이 글 아래에 댓글이 몇 개 달렸는지 등등. 그런 일을 하는 프로그램을 백엔드라고 부른다.
그리고 PHP는 백엔드를 작성하는 데 가장 흔히 쓰이는 언어 중 하나다.
다만 너무 오래되어서, 지금은 많은 회사의 신제품이나 새로운 기술 스택에서는 잘 쓰이지 않는다. 그리고 흥미롭게도 PHP는 프로그래머들 사이에서 줄곧 조롱의 대상이었다. "PHP는 세계 최고의 언어다"라는 말은 십수 년째 이어져 온 밈으로, 많은 사람이 PHP를 지난 세기의 유물이라고 여긴다.
하지만 전 세계에서 PHP로 만들어진 웹사이트는 여전히 70%를 차지한다. 조금 더 새로운 국내(중국)만 보더라도 Java가 극도로 많긴 하지만, 2026년 10월 기준 데이터로 보면 여전히 절반이 넘는 웹사이트가 PHP로 만들어져 있다.
모두가 그것을 비웃지만, 솔직히 말해서 모두가 그것 없이는 살 수 없다.
당신이 가입했던 포럼, 작은 가게의 결제 페이지, 많은 지방정부의 민원 처리 웹사이트, 회사 내부의 비용 정산 시스템, 그리고 공유기와 NAS의 관리 백엔드까지, 그중 상당수가 PHP 위에서 돌아가고 있을 가능성이 크다.
그것은 마치 도시 지하의 낡은 수도관과 같다. 평소에는 정말 아무도 떠올리지 않지만, 한번 터지면 거리 전체가 온통 똥으로 뒤덮일 수 있다.
그리고 이번에는 PHP 그 자체가 터져버린 것이다.
이번 취약점에는 PHP2Shell이라는 이름이 붙었다. Shell은 서버의 명령줄이다. 그것을 손에 넣으면, 이 서버의 제어권을 사실상 손에 넣은 것과 같다고 봐도 된다. 그래서 이 이름의 뜻은 아주 직설적이다. PHP에서 곧장 당신의 서버로 통한다는 것이다.
여기에는 두 개의 번호가 포함된다. CVE-2026-109618과 CVE-2026-109619다.
CVE는 취약점의 주민등록번호라고 이해하면 된다. 전 세계적으로 통일되어 있다.
심각도는 CVSS로 점수를 매기는데 만점이 10점이다. 처음 유출된 버전은 만점이었지만, 결국 실제로 부여된 것은 9.2점이었다.
이 두 취약점을 제대로 설명하려면, 먼저 최근 모두가 아파하는 개념 하나를 짚고 넘어가야 한다.
메모리.
프로그램이 실행될 때는 시스템에 끊임없이 메모리를 "빌려서" 임시 데이터를 저장하고, 다 쓰면 다시 "돌려줘야" 한다. PHP의 인터프리터는 C 언어로 작성되어 있는데, C 언어는 빠르지만 빌리고 돌려주는 일은 여전히 전적으로 프로그래머가 스스로 장부를 기록해야 한다. 시스템은 당신을 봐주지 않는다.
그래서 이 장부가 한 번이라도 잘못 기록되면 사고가 난다.
첫 번째 취약점, CVE-2026-109619. 전문 용어로는 "해제 후 사용(use-after-free)"이라고 한다.
예를 들어 보자. 당신이 호텔을 운영한다고 치자. 첫 번째 손님이 짐을 맡기러 왔고, 직원은 그의 물건을 18번 사물함에 넣고 장부에 기록해 두었다.
나중에 손님이 떠나자 사물함을 비우고 두 번째 사람에게 다시 내줬다.
그런데 문제가 생겼다. 직원이 장부에 있던 원래 기록을 지우는 것을 잊어버린 것이다.
두 번째 사람이 막 자기 물건을 넣자마자, 직원은 옛 기록을 들고 18번 사물함을 열러 가서, 안에 아직 첫 번째 사람의 짐이 있다고 생각했다.
이제 곤란해졌다. 그는 두 번째 사람의 물건을 볼 수도 있고, 심지어 그 안의 물건을 망가뜨릴 수도 있다.
PHP의 이번 문제도 비슷한 곳에서 발생했다. 원래 이미 반환된 메모리가 다시 새로운 데이터를 저장하는 데 쓰였는데, PHP는 여전히 원래 위치를 가리키는 옛 기록을 남겨두고 있었다.
그래서 PHP는 자신이 이전 데이터를 처리하고 있다고 생각하지만, 실제로 마주친 것은 이미 전혀 다른 데이터가 되어버린 것이다. 따라서 공격자가 이 과정을 정교하게 조작할 수 있다면, 원래 건드려서는 안 될 데이터를 읽거나 변조할 기회를 얻고, 나아가 서버를 제어할 수도 있다.
이것을 해제 후 사용, 영어로는 Use-After-Free라고 부른다.
가벼우면 서버 메모리 안에 있는 다른 사용자의 비밀번호, 토큰, API 키를 읽을 수 있고, 심각해지면 메모리를 정교하게 배치한 뒤 이 서버를 이용해 곧바로 자신의 코드를 실행할 수 있다. 그 결과는 상상하기 어려울 정도다.
두 번째 구멍: 메모리가 부족할 때의 긴급 대피. 이것이 CVE-2026-109618이다.
이 취약점은 더 흥미롭다. 다시 호텔을 예로 들어 보자.
호텔에 짐 보관소가 하나 있다고 가정하자. 손님이 짐을 맡기러 올 때마다 직원은 먼저 장부에 수량을 1 더하고, 그다음 짐을 사물함에 넣어야 한다.
앞의 9개까지는 순조로웠다. 10번째에 이르러, 직원이 막 수량을 9에서 10으로 바꾸고 짐을 넣으려던 순간.
갑자기 정전이 났다. 그래서 짐은 아직 넣지도 못했는데 시스템 전체가 강제로 중단되고 말았다.
그런데 더 황당한 일이 벌어졌다. 호텔이 긴급 정리 프로그램을 가동했고, 정리 담당자는 장부를 보고 이렇게 확인했다. "오늘 총 10개의 짐을 맡았다."
그래서 장부에 적힌 수량대로 하나하나 점검했다.
하지만 문제는 10번째 짐은 아예 넣지도 않았다는 것이다. 그 자리에는 아마도 온갖 엉망인 옛 물건들이 들어 있을 것이다.
그런데 정리 담당자가 그걸 알 리가 있나. 그런 것도 신경 쓰지 않고, 장부에 적힌 대로 그것을 정상적인 짐으로 취급해 버렸다.
이러면 시스템 전체에 문제가 생길 수 있다.
PHP의 이번 두 번째 취약점도 비슷한 원리다.
PHP는 데이터를 정리할 때 먼저 수량을 1 더하고, 그다음 실제 데이터를 저장한다. 만약 정확히 이 두 단계 사이에서 메모리가 고갈되면, PHP는 긴급히 작업을 중단한다.
하지만 뒤에서 정리를 담당하는 프로그램은 여전히 이미 1이 더해진 그 수량대로 데이터를 처리한다.
결과적으로, 전혀 제대로 초기화되지 않은 메모리를 정상적인 데이터인 것처럼 사용하게 될 수 있다.
공격자가 이런 상황을 정교하게 만들어 낼 수 있다면, 서버를 더 제어할 기회를 얻는다.
그리고 가장 무서운 것은, 특정 서버 설정에서는 이 과정이 웹사이트 자신의 비즈니스 코드가 실행되기 전에 발생할 수도 있다는 점이다.
당신이 아무리 신중하게 웹사이트를 작성했더라도, 손을 쓸 기회조차 없을 수 있다.
일반인과 관계가 있냐고? 물론 있다. 당신의 컴퓨터와 휴대폰은 영향을 받지 않지만, 영향을 받는 것은 당신이 사용했던 그 웹사이트들이다. 만약 아무도 관리하지 않는 작은 사이트가 해킹당하면, 당신이 거기에 남겨둔 계정, 비밀번호, 휴대폰 번호, 그리고 모든 정보가 함께 유출될 수 있다.
이것이 바로 많은 엔지니어가 이틀 동안 다시 말하고 있는 이유이기도 하다. C 언어처럼 메모리를 전적으로 사람이 관리하는 것은 언젠가 이런 사고를 낼 수밖에 없고, Rust 같은 메모리 안전 언어는 컴파일 단계에서 이런 실수를 저지르지 못하게 막아준다는 것이다. 그래서 OpenAI가 이번에 Rust 재단을 특별히 후원한 것도 이유가 없는 일이 아니다.
이 두 취약점으로 돌아가서, 사실 역사를 거슬러 올라가 보면 이 두 취약점은 결코 새로운 것이 아니라는 걸 알게 된다.
2004년, 독일 보안 연구원 Stefan Esser가 PHP에서 메모리 상한과 관련된 최초의 원격 취약점을 발견했다. 당시 이런 공격의 활용 방법은 공개되지 않았고, 소수의 보안 회사들 사이에서만 비밀리에 유통됐다.
이 문제는 확실히 고쳐졌지만, 그 형제자매들은 모두 그대로 남아 있었다.
2024년, PHP 재단은 독일 Sovereign Tech Agency의 자금 지원을 받아 OSTIF의 조율을 통해 프랑스 보안 회사 Quarkslab에 PHP에 대한 수년 만의 외부 보안 감사를 의뢰했다.
그중 한 문제를 고치던 중, 재단이 고용한 한 핵심 개발자가 유사한 취약점을 발견했다. 그는 이론적으로 악용될 수 있다고 생각했지만, 솔직히 말해서 구체적인 공격 경로를 찾아내지는 못했다.
그리고 수정 방안은 그렇게 미뤄졌다. 보안 팀은 몇 가지 방안 사이를 오가며 줄다리기를 했고, 멈췄다가 다시 시작하고, 시작했다가 다시 멈추기를 반복했다. 나중에 PHP 재단은 회고에서 스스로 인정했다. 이것은 보안 팀의 의사 결정 프로세스와 인력 부족이 초래한 이른바 "구조적 실패"라고.
그리고 2026년이 됐다.
올해 5월, 서두에 나온 Calif라는 보안 회사가 "AI 취약점 발견의 달"이라는 시리즈를 만들었다. 그중 한 편에서는 Claude를 이용해 PHP에서 21년 전의 메모리 취약점을 파헤쳐 냈다.
그리고 AI는 계속 가속했고, 그 기세를 막을 수 없었다.
7월 30일, Calif는 OpenAI의 보안 계획 "Patch the Planet"에서 PHP 감사를 시작했다.
불과 이틀 만인 8월 1일, 그들은 "메모리 고갈"을 유발할 수 있는 첫 번째 진입점을 찾아냈다.
8월 11일, Calif는 취약점을 PHP에 보고했고, 같은 날 OpenAI의 자체 연구원들도 독립적으로 같은 문제를 보고했다.
8월 15일, PHP는 Calif가 제출한 공격 시연이 실제로 작동함을 확인했다.
8월 24일과 9월 18일, 보안 회사 Wiz와 OpenAI가 잇달아 더 많은 공격 경로를 보고했다.
이 두 취약점은 영향이 너무 커서 PHP 하부까지 연관되기 때문에, 전 세계의 파트너들을 조직해 함께 협력하여 수정하기 시작했다. 클라우드 업체, 시스템 배포판, 보안 회사 모두 사전에 준비해야 했다. 그렇지 않으면 취약점을 공개하는 것이 오히려 공격자에게 기회를 만들어 줄 수 있었기 때문이다.
이것이 바로 피비린내 나는 대비다. 2024년에는 한 핵심 개발자가 오랫동안 찾아도 이 취약점을 어떻게 활용할지 찾지 못했지만, 2026년에는 감사를 시작해서 첫 진입점을 찾기까지 불과 이틀이 걸렸다.
그리고 더 황당한 일은 따로 있다.
인터넷 전체는 아무도 돈을 내지 않고, 제대로 들여다보는 사람도 거의 없는 코드 위에 서 있다.
이번에도 마찬가지다. PHP 재단 스스로 인정했듯이, 이 메모리 문제는 2024년부터 조짐이 있었는데 오늘까지 끌려온 중요한 이유 하나가 인력 부족이다. 회고의 마지막에서 그들은 거의 도움을 구하는 수준으로, 회사와 호스팅 업체, 정부가 후원해 주기를 바란다고 했다.
Hacker News에서는 누군가가 Debian에서 PHP 패키징을 담당하는 관리자의 후원 페이지를 찾아내고는 한마디 툴툴거렸다. 한 달에 700달러도 안 된다고?
그런데 전 세계의 서버는 정말로, 이 사람들이 한밤중에 일어나 버전을 배포해 주기를 기다리고 있다.
그런데 이 기반 소프트웨어가 이렇게 취약한데, 왜 수년 동안 인터넷은 대체로 멀쩡했을까?
이유는 아주 간단하다. 얼마 전 폭발적으로 화제가 된 REA 리버스 엔지니어링과 같다.
취약점을 찾는 것이 너무 비싸기 때문이다.
많은 상용 소프트웨어를 사람들이 리버스 엔지니어링하려 하지 않는 것과 마찬가지로, 많은 상용 소프트웨어의 보호는 다른 사람이 알아보지 못하고, 그걸 연구할 시간을 들이기도 귀찮아한다는 데서 나온다.
취약점 찾기도 마찬가지다. PHP 커널이나 OpenSSL 같은 곳에서 메모리 취약점을 찾아내고 악용할 수 있는 사람은 전 세계에 아마 몇백 명뿐일 것이다.
그들의 시간은 매우 비싸고, 취약점 하나를 파는 데 몇 달이 걸린다. 그래서 많은 지뢰가 20년 동안 조용히 묻혀 있을 수 있었던 것은, 정말로 아무도 그것들을 건드리려 하지 않았기 때문이다. 비용이 너무 높았으니까.
하지만 AI는 과거 세상의 모든 "비쌈"을 산산조각내 버렸다.
Anthropic은 이번 달에 막 발표했다. 지난해 11월부터 올해 10월 초까지 자사 모델이 오픈소스 프로젝트에서 총 29,439개의 후보 취약점 단서를 찾아냈다고.
OpenAI도 오늘 밤 장문의 글에서 말했다. PHP의 이 두 구멍은 그들이 이미 발견했고 수정 중인 여러 중대한 취약점 중 하나일 뿐이며, 앞으로 몇 달 동안 "유사한 발견이 급격히 늘어날 것"이라고.
PHP2Shell은 끝이 아니라 시작일 뿐이다. 이런 일은 앞으로 반드시 점점 더 많아질 것이고, 반드시 그럴 것이다.
하지만 이때 가장 핵심적인 버그가 드러난다. 수학과 마찬가지로, 수학의 증명과 발견은 점점 더 빨라지고 있지만 핵심 병목은 검증으로 옮겨갔다. 얼마 전 OpenAI가 내놓은 700여 편의 논문을 전 세계 수학자들이 맞는지 검증하게 한다면, 최소 몇 달에서 심지어 1년이 걸릴 것이다.
네트워크 보안도 마찬가지다. PHP의 이 취약점 발견에는 불과 이틀이 걸렸다.
하지만 수정에는 꼬박 두 달이 걸렸다.
취약점 발견은 점점 더 많아지겠지만, 이런 하부 취약점을 고칠 수 있는 사람은 그렇게 많지 않다.
이것은 우리 옛말과 같다.
"천 일 도둑질하는 자는 있어도, 천 일 도둑을 막는 자는 없다."
나는 문득 어떤 이야기가 떠올랐다.
1871년, 《이상한 나라의 앨리스》를 쓴 캐럴이 속편 《거울 나라의 앨리스》를 냈다. 책에는 붉은 여왕이 나와 앨리스의 손을 잡고 죽어라 달린다. 한참을 달린 뒤 앨리스는 주변 풍경이 하나도 변하지 않았다는 것을 발견한다.
붉은 여왕이 그녀에게 말한다. "여기서는 제자리에 머물기 위해서도 있는 힘껏 달려야 한단다."
이것이 바로 AI가 지금 사회에 안겨주는 곤경인 듯하다.
보안만이 아니다. 과학적 발견이 가속하고, 코드 작성이 가속하고, 소프트웨어 복제가 가속하고, 공격이 가속하고, 방어도 가속한다. 좋은 것과 나쁜 것이 함께 모두 미친 듯이 가속하고 있다.
그리고 우리 각자는 모두 이 붉은 여왕의 달리기 속에 있다.
멈추는 대가는 바로 그것이다. 아무도 기억하지 않는 낡은 웹사이트, 15년 전에 만들어 놓고 다시는 로그인하지 않은 백엔드, 아직 PHP 5를 돌리고 있는 회사 시스템. 그것들은 느린 세상에서는 여러 해 동안 평온하게 머물 수 있지만, 빠른 세상에서는 살아 있는 과녁이다.
나를 믿어라. 이 세상에는 더 이상 관리되지 않는 PHP 옛 프로젝트가 분명히 무수히 많고, 그것들은 지금 전부 과녁이다.
사람은 AI를 이길 수 없다. 이건 더 이상 논쟁할 필요가 없다.
하지만 이 이야기 전체에서, 모든 중요한 결정의 순간마다 서 있는 것은 여전히 사람이다.
선의를 가진 사람도 있고, 악의를 가진 사람도 있다.
이제 이 못 하는 게 없는 도구가 모든 사람의 손에 쥐어졌다.
정의가 악을 이길까?
AI는 인류가 하룻밤 사이에 과거에는 상상조차 할 수 없던 힘을 갖게 해줄 수 있지만, 인류가 하룻밤 사이에 그 힘에 걸맞은 절제를 배우게 할 수는 없다.
기술이 진보하는 속도가.
인성이 성숙하는 속도를 훨씬 앞질러 갈 때.
우리는 과연 더 나은 세상을 향해 달려가고 있는 것인가, 아니면 자신의 심연을 향해 가속하며 달려가고 있는 것인가?
솔직히 말해서, 나는 이제 모르겠다.
