(클로즈업 2-①)오픈소스, 저질 AI 풀 리퀘스트에 ‘몸살’ - 애플경제

‘장황한 설명, 의미 없는 변경 사항, 검토 과정에서 문제 투성이’ 개발자들, “함량 미달 코드 평가에 과도한 시간 소비, 비효율 초래” 초고속 AI코드 생성 vs 검토, 검증 및 통합 간의 속도 ‘비대칭’ 심각 [애플경제 전윤미 기자] AI가 오픈소스에 저품질 PR(풀 리퀘스트)을 쏟아붓고 있다는 불만의 목소리가 날로 높다. 오픈소스 관리자들이 AI가 생성한 풀 리퀘스트(PR)에 파묻히고 있다. 그럼에도 많은 기업들에게 이런 현상이 널리 퍼져나가고 있다. 애초 AI가 생성한 PR은 개발 속도는 높일 수 있으나, 경로 누락, 보안 허점, 포맷팅·명명 규칙 불일치 등 결함이 더 많아질 수 있다는 지적이다. 그렇다보니 코드 검증에 병목 현상이 일어나고, 비효율을 야기한다. 이는 나아가선 코딩 에이전트를 도입하려는 기업이나 조직에게 큰 짐이 되고 있다. 저질 PR홍수에 오픈소스 프로젝트 폐쇄 잇따라 날이 갈수록 오픈소스 관리자들은 AI가 생성한 저품질 PR이 쏟아져 들어오는 상황에 압도당하고 있다. 장황한 설명과 의미 없는 변경 사항, 질문에 대해 제대로 설명도 못하는 상황, 그리고 겉보기에는 그럴듯해 보이지만 검토 과정에서 번번이 문제가 발생하는 코드 등이 그 런 것들이다. 이는 국내뿐 아니라 글로벌 개발업계 차원에서 골칫거리가 되고 있다. 해외 사례이긴 하지만, 유명한 파이썬 프로젝트 생태계인 ‘재즈밴드’(Jazzband)는 지난달 말 결국 운영을 중단해야 했다. 여러 파이썬 프로젝트를 공동으로 유지·보수하는 오픈소스 커뮤니티로서 제 기능을 할 수 없다는 판단에서다. 무엇보다 “감당할 수 없을 정도로 AI가 생성한 스팸 PR과 이슈가 쏟아진 탓”이라는 얘기다. ‘코드 레빗’에 의하면 다른 유사한 오픈소스 프로젝트들도 같은 압박을 느끼고 있다. 고도(Godot) 게임 엔진을 관리하는 ‘레미 베르셸데’(Remi Verschelde)도 “AI가 제출한 형편없는 코드를 검토하는 것이 매우 힘들고 의욕을 꺾는 일”이라고 말했다. ‘컬’(curl) 개발자인 ‘다니엘 스텐버그’도 AI가 제출한 엉성한 코드들이 너무 많아지자 버그 바운티 프로그램을 폐지한 것으로 알려졌다. 이런 현상은 이제 보편화되고 있다. 유지보수 담당자들은 제출되어서는 안 될 코드를 평가하는 데 과도한 시간을 소비하며, 진을 빼기도 한다. 이는 단지 오픈 소스만의 문제가 아니다. “모든 기업 엔지니어링 팀이 직면하게 될 미래의 모습이며, 대부분의 기업은 아직 대비가 되어 있지 않다.”고 했다. 처리량의 ‘비대칭성’ 날로 증가 그 근본적 원인은 뭘까. 다양한 의견이 있을 수 있지만, 전문가들의 의견을 종합해보면, 핵심은 처리량의 ‘비대칭성’이다. AI 코딩 에이전트는 코드 생성을 훨씬 저렴하고 빠르게 할 수 있다. 에이전트를 사용하는 개발자는 하루에 5개, 6개, 또는 그 이상의 풀 리퀘스트를 생성할 수 있다. 코딩 에이전트를 처음 사용하는 미숙련자도 불과 몇 분 만에 코드를 생성할 수 있다. 하지만 해당 코드의 검토나, 검증 및 통합은 별개 문제다. 이는 결코 빨라지거나 정밀한 자동화가 된 적이 없다. 그래서 대부분의 유지보수 과정에서 이미 (빠르게 생성되는 코드의) 처리량에 어려움을 겪고 있으며, 갈수록 기하급수적으로 그 숫자가 늘어나고 있다. 즉 “AI 코딩 에이전트 덕분에 코드 생성은 훨씬 저렴하고 빨라졌다. 그러나 코드 검토나, 검증, 통합은 전혀 빨라지지 않았다.”는 것이다. 특히 오픈소스 유지보수 과정은 더욱 심각하다. 저장소가 전 세계에 공개되어 있기 때문에 저질 PR이 엄청나게 쏟아지며, 이런 현상을 더욱 심화시킨다. 지구촌 어떤 나라의 누구든 에이전트를 깃허브의 공개 이슈에 연결, 몇 초 만에 (에이전트로 생성한) 그럴듯해 보이는 풀 리퀘스트를 생성할 수 있다. 애초 코딩의 가치는 단순히 코드 자체에 있는 것이 아니다. 코드에 담긴 이해와 맥락, 코드를 검증하는 시험 내지 실험, 그리고 코드를 다듬는 인간만의 판단, 사고 등이 정작 코딩의 핵심이다. 예를 들어 같은 기업 내부에서 코딩 에이전트를 도입하면 업무 공정의 ‘한쪽 부문’만 속도가 가속화되고, 다른 쪽 부문은 예전 그대로인 경우도 많다. 이에 코드 리뷰어는 해당 코드가 실제로 작동하는지, 올바르게 통합되는지, 예외 상황을 처리하는지, 회귀 오류를 발생시키지 않는지 등을 판단해야 하는 모든 책임을 떠맡게 된다. 한 연구에 따르면, 숙련된 개발자조차 AI 도구를 사용할 때 실제로 더 느려지는 것으로 나타나기도 했다. 연구원들이 소위 ‘이해 부채’라고 부르는 현상 때문이다. 즉, AI가 생성한 코드가 누적됨에 따라, 개발자가 자신의 코드베이스를 이해하는 수준이 떨어지는 현상이다. 실제로 ‘코드 레빗’이 470개의 오픈소스 풀 리퀘스트를 분석한 결과, AI가 공동 작성한 풀 리퀘스트은 사람이 직접 작성한 풀 리퀘스트보다 약 1.7배나 더 많은 문제가 발견되었다. 그럴수록 코드 리뷰어로선 더욱 힘들어진다. 복잡성이 증가할수록 상황은 더욱 악화된다. AI 지원 코드 리뷰만으로도 불충분 AI가 생성한 코드가 급증함에 따라 코드 리뷰를 위해 또 다시 AI 에이전트를 도입하는 경우도 늘어나고 있다. AI가 풀 리퀘스트를 요약하고, 문제를 표시하고, 품질을 평가하는 것이다. 간단한 변경 사항의 경우 이런 AI도구만으로도 충분하다. AI 리뷰어가 ‘사람’이 한 줄씩 검토하는 것보다, 스타일 위반이나, 안티 패턴, 명백한 버그를 훨씬 빠르게 찾아낼 수 있다. 하지만 12개 이상의 상호 의존적인 서비스로 구성된 ‘클라우드 네이티브 분산 시스템’의 경우, AI 리뷰는 한계에 부딪힌다. 즉, 변경 사항이 실제 컨텍스트에서 제대로 작동하는지 여부를 판단할 수 없다. 한 서비스에 대한 수정 사항이 개별적으로는 올바르게 보일 수 있다. 하지만 하위 종속 서비스와의 조화로운 규칙이나 어울림이 잘못될 수도 있다. 에이전트가 생성한 리팩토링은 실제 트래픽 패턴에서만 나타나는 경쟁 조건을 유발할 수도 있다. 이런 점들을 AI리뷰로는 잡아낼 수가 없다. 이런 한계를 극복하려면 프로덕션 환경과 유사한 환경에서 코드를 실행해야 한다. 사람이든 AI가 됐든 어떤 정적 분석도 이를 대체할 수 없다. 즉 “검증의 병목 현상은 ‘코드가 작성된 시점’과 ‘리뷰어가 코드를 확실하게 평가할 수 있는 시점’ 사이에 발생한다.”는 것이다.