OSRS 위키·RuneLite, AI가 쏟아낸 저품질 코드로 운영 한계에 몰려

게임 '올드스쿨 룬스케이프(OSRS)'의 팬 위키 운영진과 오픈소스 클라이언트 RuneLite 개발진이 AI로 대량 생성된 저품질 코드 때문에 프로젝트 운영이 한계에 몰리고 있다고 공개적으로 문제를 제기했다. OSRS 위키 디렉터인 Cook Me Plox와 RuneLite 제작자 Adam이 함께 작성한 글에서 이들은 코드 제출량과 인프라 부담이 올해 들어 비정상적인 곡선을 그리기 시작했다고 설명한다.

가장 눈에 띄는 수치는 RuneLite 플러그인 허브에 들어오는 Java 코드량이다. 올해 초와 비교해 제출된 코드 총량이 약 100배로 늘었는데, 제출 건수 자체가 20배가량 증가한 데다 건당 평균 규모도 5배 커진 결과다. 예전에는 1만 줄짜리 플러그인이 개발자와 유지보수 담당자 사이에 몇 달간 주고받는 대형 프로젝트였지만, 지금은 ChatGPT에 15분쯤 요청해 뽑아낸 코드를 그대로 자원봉사 리뷰어에게 넘기는 일이 가능해졌다. 정작 품질은 따라오지 않아서, 신규 플러그인의 중위 설치 수는 과거 수천 건 수준에서 28건으로 떨어졌다. 사용자가 거의 없는 코드까지 전부 동일한 리뷰 절차를 통과해야 한다.

AI가 만들어낸 환각도 그대로 배포된다. 활성 설치 2,500건을 기록한 플러그인은 게임에 존재하지도 않는 'Sailing' 선박 목록을 지어냈고, 최근 퀘스트용으로 인기를 끈 플러그인은 위키 퀘스트 가이드를 Claude에 넣어 단계별 도우미를 만들었지만 정작 보스전 구간은 완전히 엉터리였다.

리뷰 단계에서 AI를 쓰면 되지 않느냐는 반문에 대해, 이들은 리뷰어들이 이미 부분적으로 AI를 활용하고 있으며 효과도 조금은 있다고 인정한다. 그러나 보안에 민감한 코드가 섞이는 상황에서 무엇을 봐야 하는지 아는 숙련된 사람을 대체할 수는 없다고 선을 긋는다. AI가 쓴 코드를 자동으로 걸러내는 분류기를 만들자는 발상도 회의적이다. 그런 분류기가 존재하면 모델이 이를 회피하도록 최적화될 뿐이라, 애초에 이길 수 없는 싸움이라는 것이다.

더 심각한 문제는 위키가 사실상 외부 도구들의 백엔드로 쓰인다는 점이다. 한 인기 AI 개발 플러그인은 위키 이미지를 직접 링크해 불러오면서 클라이언트 프레임마다 이미지를 다시 요청했고, 이미지 한 장당 초당 약 50회에 달하는 호출이 발생했다. 응답이 200이 아니면 무한 재시도까지 걸렸다. 개발자에게 의도가 있었던 것도, 위키 가용성이 떨어진 것도 아니었지만 이 과정에서 소모된 위키 대역폭은 약 70만 GB에 이른다. 정상적인 하루 사용량이 약 4,000GB라는 점을 감안하면 규모가 짐작된다. 한 개발자의 가정용 인터넷 회선에서만 500GB가 빠져나갔다.

위키가 감당하는 것은 문서 페이지뿐만이 아니다. 이미지, 실시간 시세, WikiSync, 드롭 데이터, 그리고 거의 모든 룬스케이프 도구가 조용히 의존하는 각종 API와 공개 데이터가 같은 시스템에서 나온다. 잘못 짜인 플러그인과 사이트 때문에 발생하는 위키 인프라 사고는 이제 주당 2~3건꼴이다. 몬스터가 화면에 들어올 때마다 드롭률 API를 호출하는 플러그인, 이미지를 비효율적으로 가져오는 방식으로 생성된 사이트 등 패턴도 다양하다. 문제가 터지면 팀이 호출자를 추적해 개발자를 찾아내야 하는데, 코드를 한 번도 들여다보지 않은 사람이 만든 도구라면 연락할 방법조차 없는 경우가 많다.

공개 API나 이미지 엔드포인트를 활용하는 도구를 만드는 개발자라면 이 사례에서 몇 가지를 확인해야 한다. 캐싱 없이 매 프레임 또는 매 이벤트마다 외부 요청을 보내고 있지 않은지, 실패 응답에 대한 재시도에 상한과 백오프가 걸려 있는지, 특정 사용자 한 명 기준으로는 합리적이지만 사용자가 1만 명으로 늘면 감당할 수 없는 호출 패턴은 아닌지가 핵심이다. AI가 생성한 코드를 그대로 배포하는 경우에는 이런 부분이 검토되지 않은 채 넘어가기 쉽다.

글쓴이는 이것이 한 문장짜리 해법으로 풀릴 문제가 아니라고 강조한다. API 키 요구, CAPTCHA 도입, 플러그인 허브 제출 제한 같은 방어 조치는 모두 프로젝트의 낮은 진입 장벽과 개방성을 깎아먹는다. 리뷰어를 더 뽑으면 된다는 식의 해법이나, 문제를 일으킨 개발자 개인의 어리석음으로 돌리는 반응도 구조적 문제를 놓치고 있다고 지적한다. 위키는 지난 20년간 50만 명이 편집에 참여한 프로젝트이며, 월 4억 페이지뷰를 조용하게 처리하는 것은 소수의 기술팀이 감당하고 있는 몫이다.