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

오픈소스 저장소, 특정인 통제불가, AI코딩 부작용 여과 없이 드러나 “코드가 작동하지 않음을 증명” 대신, “코드의 작동을 입증” 요구 개발단계 ‘검증’, 검토 프로세스 진화, AI 코드 ‘초안’ 취급, 앤지니어가 최종 책임 [애플경제 전윤미 기자] 저질 풀 리퀘스트(PR)로 인한 오픈소스 위기가 실제로 시사하는 바는 무엇일까? 이는 오픈소스 생태계를 훼손하는 주체를 특정할 수 없어, 끊임없이 도발이 이어지고 있다는 점이다. 애초 오픈소스 저장소는 특정인(의 기여)을 지목해 통제할 수 없다. AI로 가속화된 코드 생성에 의한 부작용이 여과 없이 그대로 나타날 수 밖에 없다. 저장소 관리자들은 더욱 엄격한 ‘기여자’ 식별이나 평판 시스템에 의존할 수 밖에 없다. 때론 풀 리퀘스트를 차단하거나 필터링하는 플랫폼 도구, 그리고 경우에 따라서는 프로젝트 폐쇄 등으로 대응하고 있다. ‘바이브 코딩’을 도입한 기업은 특히 그렇다. 누가 코드를 제출하는지에 대해서는 통제할 수 있다. 그러나 과연 제출자가 “코드를 제대로 이해했는지‘에 대해서까진 파악하기 어렵다. 내부 개발자나 미숙련자들이 에이전트를 통해 생성한 풀 리퀘스트도 마찬가지다. ’리뷰‘ 대기열에서 베테랑 엔지니어가 신중하게 작성한 변경 사항과 똑같이 보일 수도 있다. 추가적인 맥락이 없다면, (베테랑과 미숙련자의 것) 두 가지를 구분하거나, 코드가 주장하는 대로 작동하는지 등을 신속하게 검증할 방법이 없다. 저질 PR에 대한 대응 방안 그래서 최근엔 ‘실제 코드의 작동 여부를 입증’하도록 하는 메커니즘을 구사하는 기업들이 늘어나고 있다. 즉, “코드가 작동하지 않는다는 것을 증명”하는 대신, “코드의 작동을 입증”하도록 요구하는 것이다. 또한 코드 생성과 코드 검증 사이의 간극을 좁혀야 한다는 목소리도 높다. 나아가선 모든 풀 리퀘스트는 ‘작동을 입증하는 증거’를 첨부해야 한다는 주문도 따른다. 이에 코딩 전문 사이트 ‘코드 레빗’이 내놓은 몇 가지 대응방안도 나름대로 주목을 받고 있다. 이에 따르면 우선 ‘검증’을 개발 단계에서 필수로 해야 한다. 개발자와 에이전트는 풀 리퀘스트를 제출하기 전에, 변경 사항을 검증할 수 있도록 해야 하는 것이다. 즉 “운영 환경과 유사한 환경에 접근할 수 있도록 하는게 중요하다.”는 얘기다. 그래서 작동하는 코드에 대한 증거를 확보하는 것부터 검토를 시작해야 한다. ‘검토 프로세스’도 진화해야 한다는 주장이다. 즉 에이전트가 시간당 수천 줄의 코드를 생성하는 상황에서, ‘한 줄씩 검토’하는 방식은 더 이상 효율적이지 않다. 그래서 “‘코드 검사’에서 ‘동작 증거 평가’로 전환되고 있는 추세”다. 다시 말해 ‘변경 사항’이 실제 작동 과정의 상호 작용이 제대로 이뤄지는지, 그리고 동작이 명세서와 일치하는지 확인해야 한다는 주문이다. 기업들은 또한 AI가 생성한 코드를 초안 자료로 취급해야 한다는 지적이다. 즉, AI가 작성한 변경 사항에 태그를 지정하고, 결함 발생률을 별도로 추적하며, 제출자가 완전히 이해하지 못할 수 있는 코드를 고려한 ‘검토 워크플로’를 구축하는 것이다. 특히 명심할 바는 AI에 책임을 위임할 수 없다는 사실이다. 대신 에이전트를 안내하는 엔지니어가 최종 결과물에 대한 책임을 져야 한다. 따라서 개발 과정 내에서 에이전트가 생성한 코드를 검증할 수 있는 도구를 제공한다. 그래서 “리뷰어가 문제를 발견할 것”이라는 기대에 의존하지 않고, 자신 있게 PR을 제출할 수 있도록 해야 한다. 코드 생성과 검증 ‘비대칭’ 해소 절실 특히 “오픈 소스 저장소는 일종의 카나리아와 같다”는 기술 사이트 ‘베이시스 테크’의 표현도 눈여겨볼 만하다. 이는 ‘개방성’ 덕분에 저렴한 코드 생성으로 인한 모든 (부정적) 외부 효과를 가장 먼저, 그리고 가장 눈에 띄게 흡수한다. 하지만 근본적인 문제, 즉 ‘코드 생성 속도’와 ‘검증 속도’ 사이의 불균형 내지 ‘비대칭성’은 오픈 소스에만 국한된 것이 아니다. 이는 구조적인 문제라고 할 수 있다. 코딩 에이전트에 막대한 투자를 하면서도, 정작 에이전트가 생성하는 코드를 검증하는 인프라에는 그에 상응하는 투자를 하지 않는 기업들이 많다. 이는 작업을 생성하는 속도는 빨라지지만, 완료하는 속도는 느려지는 파이프라인을 구축하는 셈이란 지적이다. 결국 PR(풀 리퀘스트)은 쌓이고, 리뷰 시간은 길어지며, 결함 발생률은 높아질 수 밖에 없다. 에이전트 출력물을 검토하는 엔지니어들은, 역시 (저질 PR로 인해) 오픈소스 개발자들이 겪는 것과 같은 이유로 탈진할 것이란 지적이다. 전문가들은 그러나 “이런 격차(비대칭, 불균형)를 해소할 수 있는 도구는 아직 단편적으로 존재한다”고 지적한다. 격리된 프리뷰 환경이나, 자동화된 엔드투엔드 검증 기능, 비효율적인 리뷰 워크플로, 에이전트가 생성한 변경 사항에 대한 가시성 등은 모두 해결 가능한 문제다. ‘코드레딧’은 “문제는 오픈소스 개발자들이 실시간으로 우리에게 가르쳐주는 교훈을 배울 것인지, 아니면 직접 고통을 겪을 때까지 기다리면서 유능한 엔지니어를 잃고 경쟁력을 상실할 위험을 감수할 것인지”라고 기업들에게 경고했다. 즉 “백로그가 감당할 수 없을 정도로 커지기 전에 이러한 역량에 투자하는 것”을 권하면서 “그것이 곧 코딩 에이전트를 통해 이점을 얻을 수 있는 길”이라고 강조했다.