최신 AI 모델들이 코드 작성에서는 뛰어난 능력을 보이지만, 실제 소프트웨어를 만들고 운영하는 전 과정에서는 심각한 한계를 드러냈다. 해당 논문에 따르면, 미국과 싱가포르 대학 연구진이 개발한 새로운 평가 도구로 클로드-4, GPT-4o 같은 AI를 테스트한 결과, 프로그램 제작부터 시스템 감시, 버그 수정, 테스트 작성까지 실무 작업에서 20~50%대의 낮은 성공률을 기록했다.
700개 실제 작업으로 AI의 진짜 실력을 측정했다
연구진이 만든 ‘데브옵스-짐(DevOps-Gym)’은 기존 평가 도구들과 다르다. 기존 도구들이 ‘코드 한 줄 잘 쓰는지’만 봤다면, 이번 도구는 ‘실제로 돌아가는 프로그램을 처음부터 끝까지 만들 수 있는지’를 평가한다. 자바(Java)와 고(Go)라는 프로그래밍 언어로 작성된 30개 이상의 실제 프로젝트에서 700개가 넘는 작업을 모았다. 이 작업들은 깃허브(GitHub)에서 실제로 발생한 문제들이거나, 전문가들이 현장에서 흔히 겪는 문제 패턴을 재현한 것들이다.
연구진은 특히 ‘AI가 이미 답을 알고 있는 문제’를 걸러내는 데 심혈을 기울였다. 각 프로젝트마다 20개의 코드 조각을 뽑아 AI 모델에게 이어서 작성하게 한 뒤, 원본과 얼마나 비슷한지 측정했다. 20개 코드 조각 중 4개 이상(20% 이상)에서 의심스러운 재현이 발견된 프로젝트는 ‘이미 학습했을 가능성이 높다’고 판단해 제외했다. 또한 AI가 과거 버전 기록을 뒤져서 정답을 찾는 것을 막기 위해, 모든 버전 기록 데이터를 삭제했다.
프로그램 제작 51%, 시스템 감시 20%… 단계별로 드러난 약점
연구진은 소프트웨어 개발과 운영 과정을 4개 단계로 나눠 평가했다.
첫 번째는 ‘프로그램 제작과 설정’ 단계다. 프로그램을 실행 파일로 만들고, 필요한 외부 프로그램들을 연결하며, 제작 과정에서 생기는 오류를 고치는 작업이다. Maven이라는 도구에서 Gradle이라는 다른 도구로 바꾸는 것처럼, 제작 방식 자체를 변경하는 작업도 포함된다. 두 번째는 ‘시스템 감시’ 단계다. 프로그램이 돌아갈 때 메모리가 계속 쌓이는 문제, 프로세서가 갑자기 과부하되는 문제, 데이터 입출력이 느려지는 문제 같은 이상 징후를 찾아내야 한다. 세 번째는 ‘버그 수정’ 단계로, 문제 설명을 읽고 코드를 고치는 작업이다. 네 번째는 ‘테스트 작성’ 단계로, 같은 버그가 다시 생기지 않도록 검증 프로그램을 만드는 작업이다.
평가 결과는 충격적이었다. 가장 성적이 좋았던 클로드 코드와 클로드-4 조합도 프로그램 제작에서 51.85%, 시스템 감시에서 20.56%, 버그 수정에서 23.87%, 테스트 작성에서 13.87%만 성공했다. 특히 일부 최신 모델은 시스템 감시 작업에서 단 한 건도 성공하지 못해 0%를 기록했다. 이는 AI가 코드를 잘 다루는 능력은 늘었지만, 프로그램을 만들고 운영하는 환경 자체를 관리하는 능력은 여전히 부족하다는 뜻이다.
파이썬만 잘하는 AI… 자바와 고에서는 성적 급락
프로그래밍 언어에 따른 성능 차이도 눈에 띄었다. 기존 평가 도구인 ‘SWE-Bench’에서 파이썬으로 작성된 프로젝트를 대상으로 70.4%의 성공률을 기록했던 오픈핸즈(OpenHands)와 클로드-4 조합이, 자바와 고 프로젝트에서는 23.87%로 급락했다. 이는 AI 모델들이 학습할 때 파이썬 코드를 압도적으로 많이 봤기 때문이다. 또한 자바와 고는 사람이 쓴 코드를 컴퓨터가 실행할 수 있는 형태로 번역하는 복잡한 과정이 필요하고, 외부 프로그램 연결과 제작 환경 설정이 까다로워서 파이썬 중심으로 학습한 AI가 넘기 어려운 벽이 존재한다.
연구진은 AI가 실행한 기록을 분석해 3가지 주요 실패 원인을 찾아냈다. 첫째, 필요한 도구를 쓰지 못한 경우가 33%였다. AI가 프로그램 설정 파일의 문법 오류나 빠진 부분을 확인할 수 있는 도구에 접근하지 못해 문제를 해결하지 못했다. 둘째, 여러 단계를 연결해서 생각하지 못한 경우가 23%였다. AI가 첫 번째 오류는 고쳤지만 남은 문제를 추적하지 못하거나, 작업 흐름의 일부만 처리한 후 일찍 멈췄다. 셋째, 전문 지식 부족이 37%로 가장 많았다. 메이븐에서 그래들로 바꾸는 것처럼 제작 시스템의 작동 원리와 세부 설정을 이해해야 하는 작업에서 AI의 능력이 근본적으로 부족했다.
시스템 감시에서 드러난 치명적 결함
시스템 감시 작업에서 AI의 성능이 특히 나쁜 이유는 시간에 따라 변하는 상황을 계속 지켜봐야 하기 때문이다. 메모리가 계속 쌓이는 문제는 몇 시간에 걸쳐 서서히 나타난다. 그래서 AI는 시스템 상태를 계속 관찰하고 변화를 추적해야 한다. 하지만 현재 AI 프로그램들은 이런 연속적이고 시간에 따른 정보를 처리하는 데 실패했다.
연구진은 시스템 감시 실패의 4가지 패턴을 확인했다.
첫째, 잘못된 감시 방법을 쓴 경우가 37%였다. AI가 ‘1초마다 계속 확인하라’는 명령 대신 ‘한 번만 확인하라’는 명령을 써서 일시적인 문제를 놓쳤다. 둘째, 성급하게 결론을 내린 경우가 26%였다. AI가 감시를 하지 않거나 진단을 끝내지 않은 채 답을 제출했다. 셋째, 확인 간격이 너무 긴 경우가 11%였다. 10~60초마다 확인해서 프로세서가 갑자기 과부하되는 순간을 놓쳤다. 넷째, 데이터 해석 실패가 26%였다. 필요한 정보는 모았지만 이를 제대로 분석하지 못했다.
실제 사례 연구에서도 AI가 감시 작업 중 집중력을 유지하지 못하는 문제가 드러났다. 한 AI는 처음 본 결과를 과도하게 분석하는 데 집중하다가 실시간 시스템 상태 확인을 멈췄다. 다른 AI는 한 번에 처리할 수 있는 정보량 제한에 걸려 기록 파일의 일부만 읽은 후 잘못된 결론을 냈다.
전체 과정 연결… 모든 AI가 한 건도 완료 못 해
연구진은 4개 단계를 순서대로 이어서 해야 하는 작업도 평가했다. 프로그램 제작 오류를 고치고, 시스템을 감시해 문제를 찾고, 근본 원인을 해결하는 코드를 작성하고, 재발 방지 테스트를 만드는 전체 흐름이다.
결과는 모든 AI가 단 한 건의 전체 작업도 끝내지 못해 0%를 기록했다. AI들은 1단계(프로그램 제작)를 성공하는 경우가 있었지만, 2단계(시스템 감시)에서 대부분 실패했다. 흥미롭게도 일부 AI는 잘못된 감시 결론에도 불구하고 3단계(버그 수정)나 4단계(테스트 작성)에서 우연히 성공하기도 했다. 서로 다른 성능 문제가 비슷한 코드 상의 징후를 보이기 때문이다. 하지만 전체 흐름 관점에서는 완전한 실패였다.
이 결과는 현재 AI들이 개별 작업을 연결해서 일관된 흐름으로 실행하는 능력이 부족함을 보여준다. 실제 프로그램 배포 현장에서는 절반만 해결한 것이 아무 소용없기 때문에, 이는 실무 적용에 있어 치명적인 한계다.
FAQ (※ 이 FAQ는 본지가 리포트를 참고해 자체 작성한 내용입니다.)
Q1. 이번 평가 도구는 기존과 어떻게 다른가요?
A. 기존 평가 도구들은 주로 ‘코드를 얼마나 잘 쓰는지’만 봤습니다. 이번에 만든 도구는 ‘실제로 돌아가는 프로그램을 처음부터 끝까지 만들 수 있는지’를 평가합니다. 프로그램 제작, 시스템 감시, 버그 수정, 테스트 작성의 4단계를 모두 포함하며, 실제 도커(Docker) 환경에서 명령어를 입력해 작업을 수행해야 합니다. 또한 AI 모델이 학습 중에 본 적 없는 작업들로만 구성하기 위해 체계적인 검증 과정을 거쳤습니다.
Q2. AI가 파이썬에서는 잘하는데 자바와 고에서 못하는 이유는 무엇인가요?
A. AI 모델들이 학습할 때 본 코드 중에서 파이썬이 압도적으로 많았기 때문입니다. 또한 자바와 고는 사람이 쓴 코드를 컴퓨터가 실행할 수 있는 형태로 번역하는 복잡한 과정이 필요합니다. 필요한 외부 프로그램들을 연결하고, 제작 방식을 설정하는 것도 파이썬보다 훨씬 까다롭습니다. 예를 들어 자바의 메이븐이나 그래들 같은 제작 도구가 어떻게 작동하는지 이해하고 설정 파일을 올바르게 작성하는 것은, 단순히 오류 메시지를 해석하는 것보다 훨씬 어려운 작업입니다.
Q3. 시스템 감시 작업에서 AI의 성공률이 가장 낮은 이유는 무엇인가요?
A. 시스템 감시는 시간에 따라 변하는 상태를 계속 지켜봐야 하는데, 현재 AI들은 이런 연속적인 정보를 처리하는 데 한계가 있습니다. 메모리가 계속 쌓이는 문제는 몇 시간에 걸쳐 서서히 나타나고, 프로세서 과부하는 특정 상황에서만 가끔 발생합니다. AI는 실시간으로 들어오는 새로운 정보를 계속 처리해야 하지만, 한 번에 처리할 수 있는 정보량에 빨리 도달하고, 처음 본 결과를 과도하게 분석하다가 실시간 감시를 멈추는 경향이 있습니다.
기사에 인용된 논문 원문은 arXiv에서 확인 가능하다.
논문명: DevOps-Gym: Benchmarking AI Agents in Software DevOps Cycle
이미지 출처: 이디오그램 생성
해당 기사는 챗GPT와 클로드를 활용해 작성되었습니다.
