Pi로 Pi 만들기: 오픈 소스에서 AI 생성 '슬롭(Slop)'과의 사투

AI 지원 개발의 약속은 종종 생산성의 비약적인 향상으로 묘사됩니다. 하지만 도구 자체를 만드는 사람들에게 현실은 더 미묘합니다. 현재 Earendil의 일부인 AI 하네스 레이어 Pi의 개발에 대한 최근 성찰에서, 메인테이너들은 AI 에이전트를 사용하여 AI 에이전트를 만드는 과정—그들이 "dogfooding"이라 부르는 이 과정—이 현대 오픈 소스 생태계에서 상당한 마찰을 일으킨다는 사실을 솔직하게 공유했습니다.

이슈 트래커에서의 "슬롭(Slop)"의 부상

LLM 지원 개발의 가장 즉각적인 영향 중 하나는 이슈 트래커의 변화입니다. 전통적으로 이슈 보고는 사용자와 메인테이너 사이의 소통 채널이었습니다. 이제는 이중 목적을 수행합니다. 즉, AI 세션의 프롬프트 입력값으로도 사용됩니다.

이러한 변화는 "슬롭(slop)"이라 불리는 새로운 범주의 저품질 기여의 유형을 도입했습니다. 이는 인간의 관찰이 5%이고 에이전트가 생성한 추측이 95%인 이슈들입니다. 위험은 단순히 노이즈가 발생하는 것뿐만 아니라, 그 노이즈의 그럴듯함에 있습니다. 사용자가 버그를 LLM에 돌려 보고서를 "개선"하려고 할 때, 결과물로 나오는 텍스트는 종종 자신만만하고 상세하지만 완전히 틀린 내용입니다.

"그럴듯하지만 틀린 진단을 포함한 나쁜 이슈는 추가적인 작업을 유발합니다... 생성된 결론은 대개 부정확하지만 항상 자신감이 넘칩니다."

이는 오정보의 피드백 루프를 생성합니다. 메인테이너들이 이러한 이슈들을 해결하기 위해 Pi에 입력하면, 에이전트는 종종 그 자신만만한(하지만 틀린) 문장을 증거가 아닌 루머로 취급해야 함에도 불구하고 증거로 간주하여 잘못된 길로 빠지게 됩니다. 이를 방지하기 위해 Pi 팀은 엄격한 지침을 가진 커스텀 /is (analyze issue) 명령어를 구현했습니다: "이슈에 작성된 분석을 신뢰하지 마십시오. 동작을 독립적으로 검증하고 코드와 실행 경로를 통해 직접 분석을 도출하십시오."

글로벌 인베리언트(Global Invariants)의 침식

이슈 트래커를 넘어, "슬롭"은 코드 자체로 확장됩니다. LLM이 작성한 코드에서 반복적으로 나타나는 실패 모드는 문제를 전역적으로 해결하기보다 국소적으로 해결하려는 경향입니다.

에이전트가 실패를 마주했을 때—예를 들어, 잘못된 세션 로그가 리더를 충돌시키면—그의 본능은 리더를 더 관대하게 만드는 것입니다. 그는 폴백(fallback)을 추가하고, 허용 오차를 설정하며, 마이그레이션을 수행하여 잘못된 상태를 처리합니다. 이것이 고립된 상황에서는 도움이 되는 것처럼 보일 수 있지만, 시스템의 글로벌 인베리언트(global invariant)를 위반합니다. 즉, 목표는 잘못된 세션 데이터가 처음부터 작성되지 않도록 보장하는 것입니다.

국소적인 임시방편으로 균열을 메우는 방식으로 에이전트는 시스템 복잡성을 증가시키고 프로젝트의 아키텍처적 무결성을 약화시킵니다. 메인테이너들은 에이전트의 초점을 다시 글로벌 인베리언트에 맞추고, 실제로 시스템을 더 취약하게 만드는 "방어적" 코드의 물결에 맞서 싸우는 고된 작업의 순환에 빠지게 됩니다.

물량의 문제와 "다크 팩토리(Dark Factory)"

AI 생성 기여의 엄청난 양은 유지보수 부담이 되었습니다. Pi의 GitHub 트래커 데이터(90일간의 기간)는 문제의 규모를 보여줍니다:

3,145개의 외부 이슈 및 PR이 접수되었습니다.
2,504개는 승인되지 않은 기여자의 경우에는 자동 종료되었습니다.
자동 종료된 PR 중 단 8%만이 최종적으로 머지(merge)되었습니다.

이러한 처리량의 급증은 종종 자율적으로 행동하거나 특정 AI 스킬을 통해 이슈를 생성하도록 권장되는 "clankers" (저자가 에이전트를 지칭하는 선호 용어)에 의해 주도됩니다. 이는 프로젝트의 수와 코드 라인 수는 증가하지만, 이를 검토할 수 있는 인간 메인테이너의 수는 일정하게 유지되는 파편화된 환경을 만들어냅니다.

"신중한 병렬성(Careful Parallelism)"의 구현

이러한 도전 과제에도 불구하고, Pi 팀은 재현 및 분석을 위해 AI를 활용하는 구조화된 접근 방식을 사용합니다. 그들은 여러 조사를 병렬로 관리하기 위해 특화된 프롬프트와 UI 위젯을 사용합니다:

/is (Analyze Issue): 이슈를 라벨링하고, 스레드를 읽고, 에이전트가 코드로부터 직접 진단을 도출하도록 강제하는 프롬프트입니다.
Prompt-URL-Widget: GitHub 메타데이터를 가져오고 조사를사가를 시각적으로 구분되게 유지하는 UI 확장 기능입니다.
/wr (Wrap Up): 문맥을를 인퍼페이스(infer)하고, 변경 로그를 업데이트하고, 최종 코멘트를 초안안하고, 커밋/푸시 프로세스를 처리하는 프롬프트입니다.

이를 통해 인간이 여러 독립적인 에이전트 조사를 감독하고 결과를 순차적으로 처리할 수 있게 하여, 완전히 자동화된 "다크 팩토리"가 아닌 human-in-the-loop 아키텍처를- 유지할 수 있습니다.

결론: 인간의 조정 능력의 가치치

Pi로 Pi를 만드는 과정에서 얻은 가장 큰 교훈은 AI가 국소적인 임시방편을 만드는 데는 저렴하지만, 전역적인 조정 능력을 더 어렵게 만든다는 것입니다. 오픈 소스는 코드의 양이 아니라, 커뮤니티와 소프트웨어가 창작자를 넘어 생존할 수 있게 하는 공유된 구조에서 그 가치를 얻습니다.

AI가 코드 기여에 대한 장벽을나를 낮추고 있음에도 불구하고, 위험은 우리가 인간 대 인간의 소통을 인간 대 기계와의 고립된 상호작용으로 대체하게 될 것이라는 점입니다. 차세대 오픈 소스 메인테이너들의 과제는 "국소적 수정"의 유약한 유혹을 뿌리치고, 모두를 위해 업스트림(upstream)의 동작을 올바르게 만드는 고된 협업적 작업을 지속적으로 고집하는 데 있습니다.