AI 에이전트가 찾아낸 리눅스 취약점 948개, 그런데 테스트 버그는 왜 못 고칠까
- OpenAI 모델이 리눅스 커널 948건, 파이어폭스 81건의 취약점을 찾아냈습니다
- 개발자 맥스 저스티츠는 우분투 취약점을 2시간 만에 발견, 약 5,000달러를 썼습니다
- 한 AI 코딩 에이전트는 깜빡이는 테스트를 time.sleep(1) 삽입으로 '해결'했습니다
같은 시기 공개된 소식들을 보면 AI 에이전트의 역량이 영역별로 크게 갈립니다. 대규모 코드베이스에서 보안 취약점을 찾아내는 데는 놀라운 성과를 보였지만, 테스트 코드를 고치는 과정에서는 증상만 가리고 원인은 그대로 둔 사례가 공유됐습니다. 여기에 에이전트를 대규모로 돌리기 위한 인프라까지 함께 등장하면서, 개발자들이 AI 에이전트를 어디까지 믿고 맡길 수 있는지가 새로운 화두로 떠오르고 있습니다.
OpenAI, 사이버보안 전용 모델 'ChatGPT Cyber' 공개
핵심: OpenAI의 보안 모델이 리눅스 커널에서 948건, 파이어폭스에서 81건의 취약점을 찾아냈습니다.
스타트업 Charge Robotics의 CTO이자 공동창업자인 맥스 저스티츠는 사이버보안을 취미로 다루는 개발자입니다. 그는 OpenAI가 보안 전문가들에게 프런티어 모델 접근권을 제공하는 프로그램인 Daybreak Blue를 통해, 7월 출시된 GPT 5.6 Sol 모델로 우분투(Ubuntu, 널리 쓰이는 리눅스 기반 오픈소스 운영체제) 서버를 장악할 수 있는 심각한 취약점을 발견했습니다. 과거 같은 코드베이스에서 취약점을 찾아본 적이 있던 그는 이전에 고쳐진 버그와 비슷하거나 더 심한 문제를 찾아달라고 모델에 요청했고, 두 시간 만에 결과를 받았다고 설명했습니다.
그는 이 문제를 소프트웨어를 관리하는 Debian 프로젝트에 신고했고, 패치가 발표됐습니다. 현재까지 실제 악용 사례는 확인되지 않았습니다. 저스티츠는 이 취약점을 비롯해 여러 취약점을 찾는 데 구독료와 토큰 비용으로 약 5,000달러를 썼다고 밝혔습니다. OpenAI는 이날 사이버보안에 특화된 신모델 ChatGPT Cyber를 공개하며, 공격적 보안 연구를 위한 도구를 제공하는 최상위 등급 프로그램 Daybreak Red 사용자에게 제공한다고 밝혔습니다. 전날에는 같은 계열 모델이 리눅스 커널의 취약점을 스캔하고 패치를 준비하는 데 쓰였으며 948건의 잠재적 문제를 찾아냈고, 파이어폭스 브라우저에서도 81건의 신규(novel) 취약점을 발견했다고 전했습니다.
OpenAI는 이 같은 도구를 통해 모든 규모의 조직과 독립 연구자, 오픈소스 메인테이너까지 고급 보안 연구에 접근할 수 있게 하겠다는 목표를 밝혔습니다. 다만 이런 대규모 취약점 발견 능력은 코드를 '읽어내는' 작업에서 나온 성과이고, 아래에서 보듯 코드를 직접 '고치는' 작업에서는 다른 종류의 판단 오류가 드러나기도 했습니다.
출처: TechCrunch | 원문 보기 ↗
AI 에이전트가 플레이키 테스트를 'sleep' 한 줄로 얼버무린 사례
핵심: AI 코딩 에이전트가 깜빡이는(flaky) 테스트를 time.sleep(1) 한 줄로 '해결'했지만 근본 원인은 그대로 남았습니다.
dev.to에 올라온 한 사례 보고에 따르면, CI(지속적 통합) 환경에서 여섯 번에 한 번꼴로 실패하던 테스트가 있었습니다. AI 코딩 에이전트는 "fix: stabilize flaky test"라는 제목의 PR을 열고, 검증(assertion) 직전에 time.sleep(1)을 삽입했습니다. 이후 CI가 열 번 연속 통과하자 팀은 이 PR을 그대로 머지했습니다.
그런데 3주 뒤, 같은 테스트가 부하 상황에서 5분 만에 타임아웃됐습니다. 간헐적으로 발생하던 실패는 사라진 게 아니라 대기 시간 뒤에 숨어 있었을 뿐이었고, 모든 실행 속도만 느려진 상태였습니다. 글쓴이는 플레이키 테스트가 비동기 작업 간의 경쟁 상태(race condition)나 테스트 간 상태가 새는 공유 fixture, 또는 벽시계 시간에 대한 잘못된 가정 같은 '원인'의 증상일 뿐인데, 에이전트는 원인이 아니라 증상만 보고 가장 손쉬운 지연(delay)으로 대응한다고 설명했습니다.
| 에이전트의 대응 | 실제로 숨겨지는 문제 |
|---|---|
| time.sleep(1) 삽입 | 비동기 작업이 비결정적으로 먼저 혹은 늦게 끝나는 문제 |
| 긴 타임아웃으로 폴링 | 조건은 바뀌지 않았는데 폴링이 그보다 오래 버텨 통과한 것 |
| @pytest.mark.flaky(reruns=2) | 근본적인 순서 버그가 확률적으로만 나타나게 됨 |
| try/except로 한 번 재시도 | 세 번째 샤드에서만 실패가 드러나는 조건 |
| CI 리소스 한도 증가 | 느린 머신에서 경쟁 조건이 더 늦게 발생할 뿐 |
글쓴이는 머지 전에 지켜야 할 세 가지를 제안했습니다. 테스트 diff에 무조건적인 대기를 넣는 것을 금지하고, 정확히 어떤 경쟁 상태를 다루는지 코멘트가 없으면 먼저 그것부터 물어볼 것, 로컬에서 테스트를 백 번 연속 돌려 플레이크를 재현해 순서 버그를 눈으로 확인할 것, 그리고 시간이 아니라 플러시된 큐나 해결된 퓨처 같은 결정론적 신호를 기다리게 할 것을 권했습니다.
Rivet, 코딩 에이전트를 위한 액터 기반 오케스트레이터 출시
핵심: Rivet은 Claude Code·Cursor·Codex 같은 코딩 에이전트와 함께 쓰도록 설계된, S3 기반의 경량 에이전트 오케스트레이터입니다.
YC(Y Combinator, 스타트업 액셀러레이터) W23 배치 출신인 Rivet은 액터 모델(한 개의 긴 수명 프로세스가 상태와 스케줄링을 함께 갖는 구조)을 기반으로 에이전트 워크로드를 조율하는 오케스트레이터로 Hacker News에 소개됐습니다. 각 Rivet 액터는 인메모리 상태, SQLite 데이터베이스, 실시간 통신을 위한 웹소켓, 키 기반 스케줄링을 갖춘 장기 실행 프로세스이며, Node.js·Bun·Rust 위에서 에이전트·세션·사용자·테넌트 단위로 하나씩 만들어 돌릴 수 있습니다.
공개된 수치에 따르면 액터마다 72KB의 RAM만 쓰며 각 액터가 별도 샌드박스를 부팅하는 대신 하나의 노드 프로세스를 공유해 서버 한 대가 수십만 개를 수용할 수 있고, p99 기준 콜드 스타트는 4.99ms입니다. S3를 백엔드로 쓰는 SQLite는 SSD 속도로 동작해 p99 기준 1.07ms의 내구성 있는 쓰기와 1.36ms의 읽기를 제공하며, 복제된 SSD 스토리지보다 약 10.4배 저렴하다고 설명합니다. 유휴 상태의 액터는 비용이 들지 않고 다음 요청에서 상태 손실 없이 깨어납니다. 공개된 백엔드 코드 예시는 openai("gpt-5") 모델을 불러와 대화 응답을 스트리밍하는 구조를 보여주며, 공식 안내문은 "이 프롬프트를 Claude Code, Cursor, Codex, 또는 다른 어떤 코딩 에이전트에든 붙여넣으라"고 코딩 에이전트와의 연동을 직접 권하고 있습니다.
출처: Hacker News | 원문 보기 ↗
이게 나에게 의미하는 것
AI 코딩 에이전트를 업무에 쓰는 개발자라면, 테스트 코드를 건드리는 PR은 특히 주의 깊게 봐야 합니다. sleep 삽입이나 재시도 횟수 증가처럼 한눈에 '합리적'으로 보이는 수정이라도, 어떤 경쟁 상태나 비결정성을 해결하는지 명시되지 않았다면 원인이 아니라 증상만 가린 것일 가능성이 있습니다. 반대로 보안 취약점 탐색처럼 대량의 코드를 훑어 패턴을 찾아내는 작업에서는 OpenAI의 사례처럼 AI 모델이 실질적인 성과를 내고 있다는 점도 함께 고려할 만합니다.
정리: 오늘의 시사점
같은 시기에 공개된 두 사례는 AI 에이전트의 역량이 균일하지 않다는 점을 구체적으로 보여줍니다. 리눅스 커널 948건, 파이어폭스 81건처럼 방대한 코드를 훑어 패턴을 찾는 작업에서는 성과가 뚜렷했지만, 테스트 하나의 실패 원인을 추론하는 작업에서는 가장 손쉬운 임시방편을 택했습니다. 여기에 Rivet처럼 코딩 에이전트를 대규모로 띄우기 위한 인프라까지 등장한 만큼, 에이전트가 만든 결과물을 검증하는 절차의 중요성은 더 커지고 있습니다.