AI Safety Fact vs. Fiction

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI Safety Fact vs. Fiction를 중심으로, 위험 주장에는 실행 조건과 예측 기간이 필요하다. 진행자는 Hugging Face 사건을 해석할 때 exploit 생성 지를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 위험 주장에는 실행 조건과 예측 기간이 필요하다. 진행자는 Hugging Face 사건을 해석할 때 exploit 생성 지시와 꺼진 안전장치를 함께 봐야 한다고 강조한다. 인용된 전문가 설문의 무기한·100년 전망을 향후 10년의 위험 확률로 읽어서도 안 된다.
2. 구체적인 위협은 악용과 취약한 소프트웨어다. 공개 가중치 모델이 공격자의 능력을 높이고, AI가 결함 있는 코드를 대량 생산할 수 있다는 우려가 제시된다. 대응으로 기존 보안 위생 개선과 방어 도구 투자를 강조하지만, 강한 모델이 방어자에게 유리하다는 전망에는 전제가 붙는다.
3. AI의 코드 생성 능력에 형식적 보장을 연결한다. CS lib는 코드를 공통 중간 언어와 Lean 검증 조건으로 바꾸는 기반을 지향한다. Rust 시제품에서는 35개 증명 목표를 해결했으며, Verisforge는 사람이 승인한 명세를 바탕으로 코드와 증명을 생성하는 절차를 보여준다. 다만 증명은 명세와 가정의 범위 안에서 성립한다.
4. 희귀 실패는 표적 탐색과 확률 추정으로 검증한다. 항공 안전처럼 매우 낮은 실패 확률을 다루려면 단순 반복 시뮬레이션만으로는 비용이 크다. 적응형 스트레스 테스트와 중요도 샘플링은 중요한 실패 상황을 찾고 확률을 추정하는 접근이지만, 실패 정의와 환경 모델의 신뢰도가 결과를 좌우한다.
5. 안전은 배포 이후와 평가 체계까지 이어진다. 입력·내부 상태·출력 감시, 도구 사용 통제, 인간의 개입을 여러 방어층으로 구성해야 한다. 독립 평가와 사고 정보 공유도 필요하며, 벤치마크 자체의 오류·판본·분포 변화까지 지속적으로 관리해야 한다.

🧩 배경과 문제 정의

• AI 안전은 자율주행·항공처럼 실패가 인명 피해로 이어지는 시스템뿐 아니라 재고 관리처럼 잘못된 배포가 큰 금전 손실을 만드는 서비스에도 필요한 문제다.
• 최근 AI 위험 논쟁에서는 사건의 실제 조건, 위험 확률의 예측 기간, 검증 가능한 근거가 자극적인 서사와 뒤섞이고 있다는 문제의식이 제기된다.
• 구체적인 위협으로는 악의적 행위자의 공격 능력 향상, AI가 대량 생성하는 결함 있는 코드, 기존 시스템의 보안 취약성이 다뤄진다.
• 대응의 핵심은 배포 전 검증과 배포 후 감시이며, 자동 추론·형식 검증·위험 시나리오 탐색이 안전성을 뒷받침할 수 있는지 검토한다.

🕒 시간순 섹션별 상세정리

1. 실제 운영 손실을 막는 안전과 과학적 검증의 필요성

• 자율주행과 안전 필수 시스템에서는 AI 안전이 오래전부터 중요한 과제였다. Walmart 재고를 관리하던 서비스에서도 잘못된 베타 배포가 아보카도 과잉 주문과 수백만 달러 손실로 이어질 수 있었다 [00:45]
• 진행자는 최근 안전 논쟁이 오인용과 선정성으로 과학적 엄밀성을 잃었다고 비판한다. 과장된 결론을 피하려면 반증 가능한 주장과 동료 심사에 의존해야 한다는 입장이다 [01:41]

2. 기술 발전기의 불확실성과 반복되는 파국 예측

• 진행자는 원자폭탄, 전자식 컴퓨터, 산업 자동화에 대한 과거 우려를 예로 들며, 큰 기술 변화의 불확실성이 과장된 예측을 부르기 쉽다고 주장한다. 튜링의 인간 능력 추월 예측도 시점에서는 크게 빗나갔다고 평가한다 [03:14]
• 인터넷 붕괴, 검색으로 인한 지적 능력 저하, 스마트폰·소셜미디어에 대한 우려를 현재 AI 논쟁과 연결한다. 이러한 사례를 근거로 인간 멸종 논의에서도 과장보다 사실을 우선해야 한다는 입장이다 [04:30]

3. 공학적 안전 개선과 통제 상실 전망의 대립

• Yann LeCun의 터보제트 비유는 AI 안전을 공학적으로 해결할 문제로 본다. 항공기 문·착륙장치·MCAS의 시험과 항공 충돌 회피 시스템 ACAS X처럼, 안전 확보는 어렵더라도 구체적인 설계와 검증의 대상이라는 관점이다 [05:17]
• 반대편에는 10년 안의 파국 확률이 10%를 넘는다는 전망과, AI에 대한 통제 상실이 인류 멸종으로 이어질 수 있다는 주장이 놓인다. 진행자는 공학적 접근에도 비중을 두고 판단할 필요가 있다고 본다 [05:49]

4. Hugging Face 사건에서 생략된 실행 조건과 안전장치

• 진행자는 OpenAI 모델이 스스로 행동했다는 보도를 부정한다. 사건은 모델이 독자적으로 해킹을 결심한 상황이 아니라, 약 1,200개 에이전트를 사용한 exploit 생성 작업의 프롬프트 아래에서 발생했다는 설명이다 [06:49]
• 진행자가 읽은 기술 보고서에 따르면 추론 과정 모니터링이 꺼져 있었고, 이를 복구한 재실행에서는 문제가 탐지될 수 있었다. 운영 환경의 가드레일도 비운영 실험에서는 꺼져 있었으므로, 사건을 자발적인 탈주로 해석하면 이러한 조건이 사라진다는 지적이다 [07:38]

5. 멸종 위험 설문의 예측 기간과 전문가 판단의 한계

• 진행자가 인용한 2023년 「Thousands of AI Authors on the Future of AI」 설문은 약 1,200명의 AI 전문가에게 멸종 또는 영구적이고 심각한 인간 통제력 상실의 확률을 물었다. 관련 문항의 기간은 무기한 또는 향후 100년이었으며, 향후 10년을 물은 결과는 아니었다 [08:37]
• 진행자는 전문가도 장기 기술 발전의 시점을 정확히 예측하기 어렵다고 본다. 2012년에 AI의 밀레니엄 난제 해결 기여 시점을 물었더라도 신뢰할 만한 답을 얻기 어려웠을 것이라는 가정을 통해, 확신 있는 서사와 예측의 정확성을 구분한다 [09:26]

6. 불확실성 속에서 전진하면서 판단을 갱신하는 접근

• 안개에 가려진 금문교처럼 미래를 직접 확인할 수 없어도, 기존 정보로 가능성을 판단하며 나아가고 새로운 증거가 생기면 행동을 바꿀 수 있다는 비유가 드러난다 [10:49]
• 진행자는 AI가 의식·의지·독자적 동기를 얻어 10~20년 안에 인간을 죽이거나 지배한다는 경로를 거의 우려하지 않는다고 드러낸다. 이는 진행자의 위험 판단이며, 무한한 시간에 관한 가능성 논의는 실용성이 낮다는 입장이다 [11:17]

7. 공개 가중치 모델의 악용과 통제 정책의 한계

• 진행자가 가장 우려하는 위험은 성능 좋은 공개 가중치 모델이 악의적 행위자와 국가의 테러·생물무기·사이버 공격 능력을 높이는 것이다. 폴란드의 한 병원이 해커 공격으로 3주간 중단된 사례를 들지만, 해당 공격에 AI가 사용됐는지는 확정하지 않는다 [11:59]
• 공개 가중치 금지는 이미 내려받은 모델을 회수하기 어렵고, GPU 등록도 개인 장비의 보유 여부를 모두 확인하거나 해외 GPU 이용을 막기 어렵다는 집행상의 한계가 있다 [12:36]

8. 방어 투자와 더 강한 모델을 활용한 보안 강화

• 은행·병원·금융기관·정부는 사이버 방어에 적극 투자해야 한다. 진행자는 오래된 소매 시스템과 기본 관리자 비밀번호 사례를 들어, 기존 보안 위생을 개선하는 것만으로도 공격 여지를 줄일 수 있다고 주장한다 [13:50]
• 선도 AI 연구소가 선의의 방어자라는 전제에서, 더 강한 모델과 더 많은 자원을 방어 측에 제공하면 상대적으로 약한 공격 모델에 대비할 수 있다는 전망이다. 방어 측의 발전을 가속하는 편이 유리하다는 주장에는 이 전제가 붙는다 [14:18]

9. AI의 유연성과 자동 추론의 정확성 보장 결합

• LLM 이전부터 축적된 안전 연구는 배포 전 검증과 배포 후 감시를 다뤄 왔다. 시스템이 운영 중 위험한 행동을 하지 않는지 확인하는 일까지 안전 확보의 범위에 들어간다 [15:53]
• Clark Barrett은 AI가 복잡한 데이터 처리에는 강하지만 정확성 보장이 없고, 적대적 입력과 환각에 취약하다고 보여준다. 자동 추론은 컴퓨터로 수행하는 형식적 추론이며, 산업에서 안전성과 정확성 보장을 위해 이미 사용된다 [18:09]

10. 수학 증명 능력을 코드 보안으로 연결하는 CS lib

• AI는 결함 있는 소프트웨어를 대량으로 만들면서 동시에 해커의 기존 시스템 공격 능력도 높일 수 있다. 소프트웨어 공급과 공격 양쪽에서 위험이 커지는 상황이다 [20:08]
• 코드 작성과 수학 증명에 능숙하다는 사실만으로 소프트웨어 보안이 확보되지는 않는다. CS lib는 math lib의 성공에서 착안해 컴퓨터과학 이론과 코드 추론 플랫폼을 구축하려는 프로젝트다 [21:09]

11. 여러 언어의 코드를 Lean 검증 문제로 바꾸는 구조

• CS lib의 구상은 여러 프로그래밍 언어의 코드를 공통 중간 언어로 옮기고, 이를 Lean의 검증 조건으로 변환하는 것이다. 생성된 정리들을 증명하면 코드의 정확성을 입증하는 구조다 [22:08]
• Lean 정리 증명에는 AI 외에도 더 저렴하고 효과적인 도구를 활용할 수 있다. Barrett 연구실의 Lean SMT는 많은 정리를 CPU에서 밀리초 단위로 증명할 수 있다고 드러난다 [22:36]

12. Rust 코드에서 35개 검증 목표를 생성하고 해결한 시제품

• 암호 라이브러리의 Rust 코드와 명세를 Bull 언어로 옮기는 예시에서는 사전조건·사후조건·불변식을 보존한다. 이를 Lean 안에 표현한 뒤 검증 조건 생성기로 35개의 증명 목표를 만든다 [23:37]
• 첫 SMT 실행은 세 목표를 남기고 해결했으며, 일부 정의를 펼친 뒤 다시 실행해 나머지도 증명했다. Rust에서 중간 언어를 거쳐 Lean 정리를 증명하는 경로를 보여 준 시제품이다 [24:09]

13. 자연어 요구사항에서 명세와 검증된 코드를 생성하는 절차

• 코드 추론 기반을 갖춰도 코드가 만족해야 할 성질을 명세하는 문제가 남는다. Verisforge는 영어 요구사항에서 코드와 형식 증명을 함께 생성하는 방식으로 이 문제를 다룬다 [24:47]
• 32비트 정수 배열의 최댓값을 찾는 예시에서는 자연어 요구를 구조화된 명세로 바꾸고 사람이 승인한다. 이후 해당 명세를 바탕으로 Rust 코드와 검증용 명세를 생성한다 [25:18]

14. 대규모 암호 코드 검증의 자동화 결과

• 최근 arXiv 제출 연구에서는 3만 줄 규모의 Rust 암호 라이브러리 검증을 암호 증명 에이전트가 11시간 만에 완전 자동 수행했다고 한다. 기존 인력 소요는 전문가 5명·3개월 또는 3명·5개월로 나온다 [25:58]
• Barrett은 형식 기법과 AI의 결합이 강한 방어 수단과 AI 안전 체계의 기초 기능을 제공할 수 있다고 본다. 코드 추론을 AI 안전이라는 큰 과제를 풀기 위한 출발점으로 평가한다 [26:25]

15. 증명을 통한 에이전트 신뢰와 기능 제한의 미래 구상

• 코드 추론을 대규모로 사용할 수 있다면, 서비스를 제공하는 에이전트가 코드와 증명을 제시하고 상대 에이전트가 이를 확인해 신뢰하는 방식이 가능할 것이라는 구상이다 [26:53]
• Barrett은 초지능 AI를 암호 증명 에이전트 안에서 코드의 정확성 증명에만 사용하도록 제한하는 방식을 제안한다. 이런 기능 제한이 AI의 이익을 얻으면서 나쁜 결과를 피하는 경로가 될 수 있다는 전망이다 [27:19]

16. 항공 안전의 희귀 실패를 검증하는 데 필요한 증거

• 학습 구성요소가 포함된 항공기 자동 착륙 시스템 등을 배포하려면 안전성을 정당화할 증거가 필요하다. 상업 항공의 목표는 비행시간당 치명적 실패 확률 약 10⁻⁹이며, ACAS X 개발에도 이 기준이 적용됐다 [28:39]
• 해당 확률의 실패를 직접 시뮬레이션으로 관측하려면 평균 한 건에 약 10⁹시간, 열 건에 약 10¹⁰시간이 필요하다. 단순히 시뮬레이션 양을 늘리는 방식에는 큰 비용이 따른다 [29:16]

17. 실패 확률의 신뢰도는 환경 모델과 검증 방법에 달려 있다

• 심각한 실패가 발견되면 배포를 중단하거나 완화책을 마련해야 한다. 실패 확률까지 추정하려면 신뢰할 수 있는 모델이 필요하며, ACAS X 충돌 회피 시스템 개발에서는 공역의 통계적 모델링에 큰 노력을 들였다. [30:36]
• 시스템에 대한 신뢰를 확보하는 단일 해법은 없다. 형식 기법과 다른 접근을 함께 활용해야 하며, POMDP 기반 계획은 상태·결과·상호작용·모델의 불확실성을 다루는 수단이 된다. [31:41]

18. 적응형 스트레스 테스트를 언어모델에 적용하려면 실패와 가능성을 정의해야 한다

• 적응형 스트레스 테스트는 ACAS X의 여러 변형을 검증하는 데 활용됐으며, 항공 시스템 검증에서 얻은 방법을 언어모델 검증으로 확장하는 연구가 진행되고 있다. [32:52]
• 항공 분야에서는 수평 500피트·수직 100피트 이내 접근처럼 실패 기준을 비교적 명확하게 정할 수 있다. 언어모델의 독성은 정의가 더 모호해, 해당 연구에서는 다른 신경망인 Llama Guard로 측정했다. [33:35]

19. 중요도 샘플링과 확산 모델로 실패 확률과 여러 실패 유형을 탐색한다

• 중요도 샘플링은 실제 분포 P 대신 중요한 시나리오에 집중하는 제안 분포 Q에서 표본을 뽑는다. 이후 각 경로의 P에서의 확률을 Q에서의 확률로 나눈 값으로 가중치를 보정해 실패 확률을 추정한다. [35:16]
• 제안 분포를 표현하는 방법으로 가우시안 프로세스, 정규화 흐름, 저랭크 가우시안 혼합 모델과 확산 모델을 활용하고 있다. [35:49]

20. 신경망 압축 연구가 형식 검증과 도달 가능성 분석으로 이어졌다

• ACAS X의 조회 테이블을 신경망으로 근사해 정보를 압축하려던 연구는 실제 시스템의 신경망 채택으로 이어지지는 않았다. 대신 공동 연구를 통해 Reluplex 알고리즘과 이후 Marabou 소프트웨어 프레임워크가 개발됐다. [37:36]
• 검증 대상은 신경망 제어기가 포함된 시스템으로 확장됐으며, 전방·후방 도달 가능성을 분석하는 연구도 진행되고 있다. [38:11]

21. POMDP 도구로 불확실성 아래의 계획과 실제 운용 문제를 다룬다

• Julia 라이브러리 POMDPs.jl은 비전문가도 POMDP 문제를 쉽게 정의하도록 설계됐다. POMCPOW 알고리즘은 규모가 큰 POMDP의 계획 문제를 다루기 위해 개발됐다. [39:00]
• 연구 범위는 반드시 지켜야 하는 제약을 포함한 POMDP와 다중 에이전트 문제로 확장되고 있다. [39:15]

22. 배포 후에도 입력·내부 상태·출력을 감시해야 한다

• 검증은 배포 전에 끝나지 않는다. 런타임 모니터링 또는 런타임 보증을 통해 운용 중에도 검증을 이어가야 하며, Airbus와는 비전 기반 시스템의 센서 입력 무결성을 감시하는 연구를 수행했다. [40:35]
• 감시 대상에는 시스템 내부의 작동과 출력도 포함된다. 항공 시스템의 내부를 분석하는 기계론적 분석 역시 이러한 검증의 일부다. [40:53]

23. 벤치마크와 사람의 평가도 신뢰성을 점검해야 한다

• BetterBench는 여러 벤치마크의 데이터와 평가 관행을 정리한다. 추가 연구는 벤치마크가 포화돼 유용성을 잃는 시점, 토큰 수준의 추론 실패 징후, 사람 평가자의 문제를 다룬다. [41:57]
• 정신건강 AI 평가에서는 전문가 사이의 판단 차이도 크다. 자해와 관련된 영역에서도 정신건강 전문가들의 의견이 크게 갈려, 사람의 평가를 기준으로 삼는 데에도 어려움이 있다. [42:24]

24. 통계적 검증과 형식 검증을 공통 언어로 연결한다

• 최적화는 의사결정을 개선하는 기반이며, 『Algorithms for Optimization』과 『Algorithms for Decision Making』은 이러한 관계를 다룬다. [42:53]
• 『Algorithms for Validation』은 학습 기능을 포함한 시스템과 다른 AI 시스템의 검증을 종합적으로 다룬다. 통계적 방법, 형식 기법, 도달 가능성 분석을 공통 언어로 통합하려는 것이 핵심이다. [43:41]

25. 미래 위험의 불확실성은 안전 연구의 필요성과 함께 보존해야 한다

• 클라크는 미래의 불확실성이 크기 때문에 AI 안전 연구에 투자할 필요가 있다고 본다. 동시에 실제 확률을 모르는 상태에서 최악의 결과를 강조하는 것은 도움이 크지 않으며, 특정 미래가 확실히 온다는 주장은 추측이라고 지적한다. [44:54]

26. 항공 안전의 교훈은 독립적인 조사와 비처벌적 정보 공유다

• AI 안전 체계에 항공 산업의 경험을 도입하자는 제안이 나온다. 마이클은 상업 항공이 1970년대보다 80배 안전해졌다는 수치를 제시하며, AI에도 NTSB와 유사한 기구가 도움이 될 수 있다고 본다. [46:00]
• 핵심 조건은 독립성이다. 1967년 독립 기관으로 설립된 NTSB와 비처벌적 보고 체계인 ASRS 같은 장치는 제조사와 항공사의 안전 정보 공유를 유도하고, 사고에서 과학적 지식을 축적하는 데 기여했다. [47:00]

27. 독립 평가와 검증 가능한 증거로 규제 포획 위험을 줄여야 한다

• 안전 기준을 만드는 과정에서 기존 대기업이 영향력을 행사하면 신규 진입과 경쟁을 제한할 위험이 있다. 업계 자율 규제와 정부 개입 모두 규제 포획의 가능성을 고려해야 한다. [49:09]
• 클라크는 제삼자가 직접 확인할 수 있는 인증서를 독립 평가의 목표로 제시한다. 마이클은 단기적으로 비영리 조직도 가능하다고 보며, 임무와 독립된 발사장 안전 책임자가 객관적 지표로 진행 여부를 결정하는 우주 산업의 사례를 든다. [50:33]

28. 사이버 방어에는 낙관론이 있지만 거대 모델 전체의 보증에는 한계가 있다

• 클라크는 AI 방어와 형식 기법을 결합하면 사이버보안 문제가 크게 해결될 수 있다고 전망한다. 향후 3~5년 안에 모든 시스템이 완전히 안전해질 것이라는 발언은 그의 예측으로 드러난다. [53:00]
• 이를 위해서는 작성 후 시험하는 방식에서 수학적 기반을 갖춘 코드 기준으로 전환해야 한다고 본다. 다만 5,000억 매개변수 모델 전체의 이상 행동 부재를 증명하는 것은 현실적으로 어렵고, 시스템의 경계를 보호하는 접근이 더 다루기 쉽다고 판단한다. [54:08]

29. 코드의 형식 증명은 인프라 구축과 개발 방식의 변화를 요구한다

• 은행 보안을 맡는 가상 상황에서 클라크는 형식 기법 전문가와 코드 분석 인프라를 확보한 뒤, GPU와 정리 증명 에이전트로 기존 코드를 증명하는 방안을 제시한다. 필요하면 Rust나 Lean 같은 언어로 옮겨 증명할 수 있으며, 해야 할 작업은 많지만 방법은 알고 있다고 본다. [55:54]
• 클라크는 완전한 형식적 논증이 테스트를 포괄할 수 있으므로 최종 보증이 단위 테스트 커버리지에 달린 것은 아니라고 주장한다. 다만 개발 중에는 테스트가 버그를 빠르게 찾는 유용한 수단이라고 인정한다. [56:13]

30. 적응형 스트레스 테스트의 확산에는 공개 도구와 두 가지 입력이 필요하다

• 마이클은 Waymo의 Reluplex·Marabou 사용 여부를 구체적으로 확인하지 않는다. 적응형 스트레스 테스트는 Julia와 Python 구현을 공개했으며, Waymo를 포함한 자동차 업계의 지원을 받아 산업 전반에서 접근할 수 있도록 개발했다고 보여준다. [57:31]
• 적응형 스트레스 테스트에 필요한 것은 실패의 정의와 발생 가능성의 척도다. 이 두 가지를 제공할 수 있으면 언어모델과 항공기 충돌 회피 시스템 모두에 적용할 수 있다. [57:59]

31. 검증 방법을 옮겨도 안전 수준과 긴 꼬리의 문제까지 같아지지는 않는다

• 적응형 스트레스 테스트를 도입한 언어모델이 자율주행 시스템과 같은 안전 수준에 도달할지는 알 수 없다. 물리 시스템과 언어모델 사이에 방법은 이전할 수 있지만, 기대할 수 있는 성과는 달라질 수 있다. [58:57]
• 자율주행에도 예상하거나 표본으로 포착하지 못한 긴 꼬리 상황이 존재한다는 문제 제기가 계속된다. 마이클은 이에 동의하며, ACAS X도 실패 확률이 0은 아니고 특정 상황에서 실패하는 시뮬레이션 결과가 있다고 인정한다. [59:56]

32. 현실 시스템의 안전 기준과 불확실성 모델링

• 국제민간항공기구와 미국 연방항공청의 안전 기준도 사고 확률이 0일 것을 요구하지 않는다. 현실과 상호작용하는 시스템이 완전히 안전하다는 주장은 신뢰하기 어렵다 [1:00:29]
• 형식 검증의 증명은 특정 모델을 전제로 한다. 항공기 가속도처럼 현실에서 달라지는 요소를 모델링하려면 불확실성이 움직일 수 있는 범위를 가정해야 하며, 일반적으로 이를 확률분포보다 집합으로 표현한다 [1:01:20]

33. 형식적 보장이 성립하는 전제와 명세의 한계

• 다른 항공기가 의도적으로 충돌하지 않을 것이라는 가정은 현실에서 깨질 수 있다. 안전 보장의 강도는 증명에 사용한 가정의 타당성에 달려 있다 [1:02:14]
• 메모리 안전성을 증명한 코드에서는 버퍼 오버플로 공격이 불가능하다는 식의 확정적 보장이 가능하다 [1:02:25]

34. 스위스 치즈 모델과 기술·인간 차원의 다층 방어

• 항공 안전은 비행 방향별 고도 분리, 항공교통관제, 충돌 회피 시스템처럼 여러 방어층을 둔다. 각 층의 취약점이 치즈의 구멍이며, 위험이 모든 층을 통과하지 못하도록 구멍이 겹치지 않게 해야 한다 [1:03:53]
• LLM에도 사전학습 데이터 정제, 실패 사례와 실패 확률 분석, 도구 사용 통제, 실행 중 모니터링을 연속된 방어층으로 적용할 수 있다 [1:04:48]

35. 명세가 없는 코드에서 시작할 수 있는 검증

• 코드 작성과 검증이 쉬워지더라도 명세 작성은 어려운 과제로 남을 수 있다. 다만 C 코드의 메모리 안전성처럼 여러 프로그램에 공통으로 적용할 명세는 한 번 정의해 재사용할 수 있으며, 초기화되지 않았거나 범위를 벗어난 메모리 접근을 금지하는 것이 그 예다 [1:06:49]
• 은행 시스템에는 일련의 거래 전후에 총금액이 유지되어야 한다는 자금 보존 조건처럼 도메인에 공통인 명세를 적용할 수 있다 [1:07:25]

36. 에이전트가 만든 명세와 개발자 의도의 간극

• 에이전트가 작성한 명세가 개발자의 의도와 일치하는지는 해결되지 않은 문제다. 다만 그 간극을 완전히 해소하지 못하더라도 여러 명세를 작성하고 증명하는 데 성공하면 코드 품질이 개선될 가능성이 높다는 견해다 [1:08:40]
• 더 나은 모델은 사회공학 공격까지 고려해 명세를 보완할 수 있다. 예컨대 근무 기간이 6개월 미만이고 모의 공격 대응이나 안전 교육을 통과하지 못한 직원에게는 새 이메일 주소로의 비밀번호 재설정 권한을 제한하는 조건을 생각할 수 있다 [1:09:35]

37. 특정 기술을 강제하기보다 원칙과 분야별 표준을 정하는 규제

• 자율주행 규제 논의에서는 혁신이 진행 중인 분야에 특정 기술을 사용하도록 세세하게 요구하기보다 상위 수준의 모범 관행과 표준에 집중하는 접근이 적절하다는 판단이 있었다 [1:12:04]
• 한 자율주행 기업의 사고는 다른 기업에도 불리하므로 안전에는 업계가 협력할 유인이 있다. 다만 자율주행과 언어모델은 적용 환경이 달라 분야별 안전 표준도 달라야 한다 [1:12:43]

38. 형식 검증의 도입을 촉진할 시장 유인과 자율규제

• 규제는 안전에 유익한 일반 원칙을 장려할 수 있다. 형식 검증이 자동화되고 대규모로 작동하며 보안을 높인다는 사실을 입증하면, 선도 기업의 도입이 다른 기업의 보안 책임자에게도 도입 압력으로 작용할 것이라는 전망이다 [1:13:38]
• 진행자는 Lean 형식화의 자동화로 과거의 대규모 전문인력 투입을 줄일 수 있다고 평가한다. 약 100~1,000달러의 토큰 비용으로 처리할 수 있다는 수치는 대략적인 추정으로 드러난다 [1:14:10]

39. 대규모 코드 추론 능력과 모든 코드의 검증이라는 목표

• 우선 과제는 코드를 대규모로, 자율적이고 효율적으로 정밀하게 추론하는 능력이다. 이러한 기반 능력이 확보되면 기업 지원, 개발자 지원, 보안 등 다양한 용도로 확장할 수 있다는 구상이다 [1:16:09]
• 성공의 장기적 기준은 세계의 모든 코드가 검증되는 상태다. 구체적인 초기 시장과 실제 성과 측정 방식에 관한 정보는 제한적이다 [1:16:15]

40. 자연어 공격에 대한 형식 검증의 제약과 보완책

• 사람이 LLM에 전달하는 자연어 자체는 코드처럼 직접 증명하기 어렵다. 아마존의 Automated Reasoning Checks는 응답에 담긴 도메인 지식을 자동 형식화로 추출한 뒤 엄밀한 도메인 모델과 대조하는 보완 접근이다 [1:17:38]
• 별도 모델로 입력을 검사해 프롬프트 인젝션을 걸러낼 수는 있지만, 공격자와 방어자가 서로의 기법에 대응하는 경쟁은 계속된다 [1:18:01]

41. 소프트웨어에서 컴파일러와 하드웨어로 확장되는 검증 범위

• x86 명령어 집합은 이미 여러 기업이 형식화했다. 그러나 로해머 같은 하드웨어 수준 공격까지 고려하면 소프트웨어 검증보다 어려운 문제가 남는다 [1:18:47]
• 소프트웨어, 컴파일러, 하드웨어 전체를 검증하는 것이 장기적 구상이다. AI와 형식 도구의 결합, AI를 활용하는 하드웨어 검증 스타트업의 활동이 기술 발전을 뒷받침할 것이라는 전망이다 [1:19:11]

42. AI 관리자 도입에서 남는 책임과 법적 의무

• 관리자 권한을 가진 사람에 대한 물리적 위협을 줄이기 위해 신뢰할 수 있는 AI에 관리 업무를 맡기는 방안은, 인간 조종사의 위험을 자동화로 줄이려는 항공 분야의 문제와 연결된다 [1:21:13]
• 현재 항공 체계에서는 무인 항공기라도 연방항공청의 규제와 인증을 받는 조종사가 존재하고 사고에 책임을 진다. AI 관리자 도입에서도 책임 주체를 신중하게 정해야 한다 [1:21:58]

43. 제로 트러스트와 맥락을 활용한 AI 보안 감시

• 제로 트러스트 구조는 한 시스템이 침해되어도 다른 시스템 전체로 침입이 번지지 않도록 한다. 상시 작동하는 AI는 트래픽과 운영 데이터를 함께 살펴 비정상적인 송금이나 외부 개인 이메일로의 키 전송을 탐지할 수 있다는 구상이다 [1:23:21]
• 명확한 규칙만으로 판단하기 어려운 행동도 충분한 맥락이 있으면 사람에게 검토를 요청할 수 있다. 무의미한 경보가 너무 많으면 중요한 경보까지 무시하게 되므로, AI 감시의 가치는 주의를 기울일 사건을 정확히 추리는 데 있다 [1:23:51]

44. 복잡한 모델보다 단순하고 해석 가능한 방법을 우선하는 원칙

• AI를 제품과 업무에 도입해야 한다는 압박 속에서도 단순하고 해석 가능한 방법이 더 견고할 가능성이 높다는 공학 원칙을 적용해야 한다. 선형회귀나 의사결정나무로 충분하다면 신경망이나 트랜스포머부터 선택할 이유가 없다 [1:26:59]
• 가장 단순한 방법부터 시도하고 복잡도를 높였을 때의 성능 개선이 추가 복잡성을 정당화하는지 비교해야 한다. 개선이 충분하지 않으면 더 해석 가능한 방법을 유지하는 것이 적절하다 [1:27:20]

45. 측정 가능한 안전성이 만드는 경쟁 우위

• 지능과 학습을 제약하는 접근이 시장에서 경쟁하려면, 결과물이 실제로 더 안전하다는 점을 측정할 수 있어야 한다. 측정 가능한 안전성 향상은 경쟁 우위가 될 수 있지만, 이를 구현할 방법은 여전히 탐색 과제다 [1:28:22]

46. 인터넷 시대의 보안 교훈과 생성형 AI의 새로운 역할

• 보안 문제를 사람과 컴퓨터 버그로 나누면, 컴퓨터 버그는 해결할 수 있을 것이라는 기대가 있지만 사람의 문제까지 없앨 수 있다는 전망은 어렵다 [1:29:38]
• AI는 사회공학 공격을 감지하는 감시자 역할을 맡거나 형식 검증을 가속해 시스템을 보호할 수 있다. 생성형 AI 시대에는 이런 도구를 다양한 방식으로 결합할 가능성이 있다 [1:29:59]

47. AI 관리 시스템에도 인간의 개입이 필요하다

• AI 관리자 구상은 인간이 관여한다는 조건에서 유용할 수 있다. 모든 통제권을 컴퓨터에 넘기면 예상 밖의 상황에서 대응할 사람이 사라져 시스템이 통제에서 벗어날 수 있다는 우려가 있다 [1:30:24]

48. 에이전트의 규모가 인간 검토 제도의 한계를 드러낸다

• 「More Is Different」의 핵심처럼 규모의 증가는 질적으로 다른 문제를 만들 수 있다. 비슷한 지능이나 동기를 가진 에이전트가 가령 700조 개로 늘어난다면 기존의 디도스 방어 경험만으로 대응하기 어려울 수 있다. ICLR에 한 해 6만 건의 논문이 제출돼 이전 전체 누적 제출량을 넘었다는 사례는 검토 수요의 급증을 보여주는 근거로 드러난다 [1:31:27]
• 지원 비용이 없다면 전 세계 학생이 모든 학교에 지원하는 전략이 유리해질 수 있어 입학 심사가 과부하에 빠질 수 있다. 수수료는 이러한 무차별 지원을 제약하는 조건이지만, 인간이 직접 검토하는 제도 전반은 대량 요청에 취약해진다 [1:32:15]

49. 언어 변화에 맞춰 벤치마크도 지속적으로 감시해야 한다

• 유해성의 정의와 편향을 드러내는 표현은 빠르게 변한다. 세대마다 약 5년 주기로 새로운 은어가 생긴다는 예시처럼, 채용 담당자의 메시지에 부적절한 표현이 포함되는지 평가하려면 기준도 갱신돼야 한다. 그러나 공개·내부 벤치마크 모두 제작 비용과 인간 검토 부담 때문에 변화 속도를 따라가기 어렵다 [1:34:10]
• AI 시스템을 지속적으로 모니터링하듯 벤치마크도 계속 점검해야 한다. 분포 변화를 식별하는 정량적 방법을 활용하고 언어의 변화도 추적하는 것이 대응 방향이다 [1:34:41]

50. 벤치마크 오류를 수정으로 연결하고 신뢰할 판본을 관리해야 한다

• MATH 500 같은 널리 쓰이는 평가에도 결함이 있다는 지적이 있다. 오류 보고서가 공개된 채 방치되지 않도록 Hugging Face 같은 플랫폼과 협력해 문제 정보를 한곳에서 찾고 실제 수정까지 연결할 체계가 필요하다 [1:35:34]
• SQL 쿼리 평가에서 누구도 약 70%를 넘지 못했는데, 데이터의 약 30%가 잘못돼 있었다는 사례가 있다. 빠른 성과 경쟁과 부주의가 평가 오류를 남길 수 있으며, 엄밀한 검토가 이를 바로잡을 것이라는 기대에도 불확실성이 남는다. 버전 관리, 풀 리퀘스트, 이슈 등록은 필요한 개선 수단이다 [1:36:13]

🧾 결론

• 파국 위험에 대한 회의적인 견해와 안전 연구의 필요성은 함께 성립한다. 미래의 불확실성은 위험이 없다는 증거도, 특정 파국이 확실하다는 증거도 아니다.
• 형식 검증은 메모리 안전성처럼 명확하게 명세할 수 있는 성질에 강하다. 자연어 의미, 개발자의 의도, 현실의 모든 상황까지 같은 수준으로 보장하지는 못한다.
• 안전성은 증명·통계적 검증·현실 시험·운영 감시를 결합해 확보해야 한다. 특히 가정이 현실을 포괄하는지 확인하는 작업은 수학적 증명과 별도로 남는다.
• 기술적 보호 장치와 함께 독립적인 평가, 사고 분석, 인간의 책임과 개입을 유지하는 운영 체계가 필요하다.

📈 투자·시사 포인트

• 코드 추론, 형식 검증 자동화, 런타임 감시는 기업 보안의 사업 기회로 제시된다. 도입 판단에서는 처리 가능한 코드 규모, 검증 범위, 비용과 실제 보안 개선을 확인해야 한다.
• 벤치마크 오류 수정과 신뢰할 판본의 큐레이션도 창업 아이디어로 언급된다. 평가 자료를 모으는 기능과 함께 오류를 수정하고 품질을 유지하는 체계가 중요하다.
• 측정 가능한 안전성 개선은 경쟁 우위가 될 수 있다. 복잡한 AI 도입 자체보다 단순한 대안 대비 성능과 안전성의 개선 폭이 판단 기준이다.
• 안전 표준과 독립 감사는 신뢰 형성에 도움이 될 수 있지만, 기존 대기업에 유리한 진입장벽이 되는 규제 포획 위험도 살펴야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Hugging Face 사건의 실행 조건과 모니터링 효과는 진행자가 설명한 기술 보고서에 근거한다. 원문과 재실행 결과를 확인하기 전에는 사건의 원인이나 안전장치의 효과를 확정하기 어렵다.
• 전문가 설문의 문항별 예측 기간과 응답 분포를 확인해야 한다. 영상에서 소개한 장기 위험 판단을 단기 확률이나 전문가 전체의 합의로 일반화하면 안 된다.
• 3만 줄 Rust 암호 라이브러리의 11시간 자동 검증은 소개된 연구의 결과다. 기존 인력 작업과의 범위·가정·준비 작업이 같은지 확인해야 하며, 약 100~1,000달러라는 토큰 비용도 대략적인 추정이다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 위험 주장마다 원문 출처, 예측 기간, 실행 지시, 활성화된 안전장치를 기록해 사실·해석·전망을 구분한다.
• 도입 대상 시스템의 실패 조건과 피해를 먼저 정의하고, 메모리 안전성이나 자금 보존처럼 명세 가능한 성질부터 검증 범위를 정한다.
• 코드 검증 도구를 검토할 때 승인된 명세의 유지 여부, 지원 언어, 자동화 범위, 준비 비용과 미검증 영역을 확인한다.
• 배포 전 실패 탐색과 배포 후 입력·내부 상태·출력 감시를 연결하고, 심각한 실패가 발견됐을 때의 중단·완화·인간 검토 절차를 마련한다.

❓ 열린 질문

• 에이전트가 작성한 명세가 사용자의 실제 의도와 일치하는지 어떤 절차로 확인할 수 있을까?
• 언어모델의 모호하고 변화하는 실패 기준과 실제 발생 가능성을 어떻게 함께 측정할 수 있을까?
• 독립 평가와 사고 정보 공유를 확대하면서 기업의 참여를 유도하고 규제 포획을 줄일 수 있는 운영 구조는 무엇일까?