AI VIDEO BRIEFING
AI 코드 보안 연구 — 동작하면서 안전한 코드는 30~40%, 위협 모델링으로 두 배까지
구글 출신 연구자가 AI가 작성한 파이썬 코드를 벤치마크로 측정했다. 동작하면서 안전한 비율은 30~40%대였고, 위협 모델링과 보안 리뷰 단계를 더하면 두 배로 오르지만 토큰 비용은 5배가 된다.
핵심 메시지
- 코드의 기능성은 세대를 거치며 급격히 올랐지만, '동작하면서 동시에 안전한' 과제 비율은 30~40% 수준에 머물렀다.
- 보안만 측정하는 벤치마크는 의미가 없다. 동작하지 않는 코드는 안전하게 만들기가 지나치게 쉽기 때문이다.
- '보안을 잘 지켜서 짜라'는 프롬프트 한 줄의 효과는 최신 세대 모델에서 크지 않았지만, 코딩 전에 위협 모델링을 한 번 시키는 것은 토큰 대비 효과가 가장 좋았다.
- 위협 모델링과 보안 리뷰를 함께 적용하면 안전한 코드 비율을 두 배 가까이 올릴 수 있지만, 토큰 비용은 약 5배가 된다.
- '사람이 검토한다'는 대책은 실제로는 책임 전가에 가깝다. 물량이 많으면 사람은 읽지 않고 승인만 누르게 된다.
쉽게 이해하기
이 대담은 인포마 테크타겟의 IT 운영 팟캐스트 'IT Ops Query'에서 진행됐다. 초대 손님은 MIT 슬론의 연구 제휴 연구원이자 독립 AI 안전·보안 연구소를 세운 일리야 카바노프로, 이전에는 구글에서 클라우드 AI 안전·보안 부문 시니어 매니저로 일했다. 해당 연구는 애플리케이션 보안 검사 업체 체크막스의 자금 지원을 받았다는 사실이 대담 첫머리에 공개됐다.
연구를 시작한 이유는 두 가지였다. 하나는 물량이다. 구글이 1년도 안 되는 사이에 AI가 작성하는 코드 비중을 절반 미만에서 75% 이상으로 끌어올렸다는 발표를 보고, 그렇다면 그 코드의 보안은 어떤가라는 질문이 남았다는 것이다. 다른 하나는 측정 방식으로, 지난 3~4년간 30여 편의 논문이 14개나 되는 서로 다른 벤치마크를 만들어 결과를 비교할 수 없게 만들어 놓았다는 문제였다.
그래서 15번째 벤치마크를 새로 만드는 대신 기존 벤치마크 하나를 골랐다. 약 200개의 파이썬 사례로 구성되고, 과거에 사람이 특정 취약점을 집어넣었던 것과 비슷한 과제를 AI에게 주었을 때 AI도 같은 실수를 하는지 저장소 단위로 확인하는 방식이다. 함수나 코드 조각 단위만 보는 벤치마크는 최신 모델이 이미 잘 푸는 데다 오탐이 많아 제외했다.
결과의 핵심은 두 곡선의 차이다. 기능성은 세대를 거치며 사실상 90퍼센타일 수준까지 올라온 반면, 보안은 증가율 자체는 인상적이었지만 출발점이 워낙 낮아 '동작하면서 안전한' 과제 비율이 30~40%대에 그쳤다. 발표자는 이 숫자가 자신의 예상보다 훨씬 낮았다고 말했다.
그다음 물음은 그래서 무엇을 하면 되느냐였다. 세 가지 가설을 시험했는데, 프롬프트로 '좋은 엔지니어처럼 보안 모범 사례를 따르라'고 지시하는 방법은 최신 모델에서는 효과가 크지 않았고, 코딩 전에 위협 모델링을 한 턴 넣는 방법이 토큰 대비 효과가 가장 좋았으며, 마지막에 보안 리뷰를 한 번 더 돌리는 방법도 기능을 깨뜨리지 않고 보안을 끌어올렸다.
주요 인사이트
- 보안 지표는 반드시 기능성과 묶어서 봐야 한다는 지적이 이 연구의 방법론적 핵심이다. 동작하지 않는 코드를 안전하게 만드는 것은 너무 쉬워서, 보안만 재는 벤치마크는 손쉽게 좋아 보이게 만들 수 있다.
- 개선책에는 정직한 가격표가 붙는다. 위협 모델링과 보안 리뷰를 모두 넣으면 안전한 코드 비율이 30~40%에서 60~70%까지 올라가지만, 단순 코딩 대비 토큰이 약 5배 든다. 하루에 수천 건씩 검사를 돌리는 조직이라면 이 배수가 곧 청구서가 된다.
- 그래서 다음 단계는 '무엇을 모델이 하고 무엇을 하네스가 할 것인가'의 분업이라는 진단이 나온다. 코드베이스 전체를 최고 성능 모델의 최대 추론 설정으로 훑을 이유가 없고, 결정론적으로 처리할 수 있는 단계는 값싼 방법에 맡기자는 것이다.
- '사람이 최종 검토한다'는 안전장치는 사람에게 무한한 처리량과 100% 정확도를 가정할 때만 성립한다. 발표자는 이것이 실제로는 승인 옆에 이름을 남기는 책임 전가이며, 사람은 불확실성 속에서 조직의 맥락을 아는 판단에 배치돼야지 대량 검토의 길목에 세워서는 안 된다고 말했다.
- 취약점의 허용 기준 자체가 내려갔다는 관찰도 중요하다. 예전이라면 넘어갔을 저심각도 취약점도 공격 측 모델이 여러 개를 엮어 실제 피해로 만들 수 있게 되면서, '심각도가 낮으니 무시한다'는 판단이 더는 안전하지 않다는 것이다.
자주 묻는 질문
'동작하면서 안전한 코드'가 30~40%라는 건 무슨 뜻인가요?
벤치마크 과제 가운데 기능이 제대로 동작하면서 동시에 알려진 취약점을 만들지 않은 비율입니다. 보안만 따로 재면 동작하지 않는 코드도 안전한 것으로 집계되기 때문에 두 조건을 함께 걸었습니다.
어떤 방법이 가장 효과가 좋았나요?
코딩을 시작하기 전에 위협 모델링을 한 턴 시키는 방법이 토큰 대비 효과가 가장 좋았다고 밝혔습니다. 다만 한 모델은 위협 모델링 뒤 과도하게 방어적으로 짜다가 기능성이 떨어지는 현상도 관찰됐습니다.
보안을 지키라고 프롬프트에 쓰는 건 소용없나요?
최신 세대 모델에서는 그 한 줄로 얻는 개선폭이 크지 않았습니다. 다만 비용이 거의 들지 않고 해가 되지도 않으므로 넣어 두는 편이 낫다는 것이 결론이었습니다.
LLM이 다른 LLM의 결과를 심사하게 하면 되지 않나요?
하나의 만능 해법으로 보기는 어렵다는 답이 나왔습니다. 판정 사슬의 한 층으로서 결과를 분석하고 추론하는 역할은 유용하지만, 모델은 그럴듯하게 들리지만 사실이 아닌 출력을 내놓는 성질이 있어 결정론적 검사와 사람의 판단을 함께 배치해야 한다는 설명입니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗