무슨 일이 있었나
플레이스테이션 5에서 리눅스를 돌리는 프로젝트가 있어요. 소니가 막아놓은 콘솔의 보안 구조를 뚫고, 커널을 올리고, GPU 드라이버까지 맞춰야 하는, 말 그대로 리버스 엔지니어링의 끝판왕 같은 작업이에요. 이 프로젝트를 이끌던 핵심 개발자가 최근 그만두겠다고 선언했는데, 그 이유가 꽤 씁쓸해요. 요약하면 이래요. '오픈소스 프로젝트가 이제 자기가 뭘 하는지도 모르면서 LLM을 돌리는 초보들의 집합이 됐다.'
거친 표현이지만, 이 말이 나온 배경을 보면 단순한 짜증이 아니라 요즘 오픈소스 메인테이너들이 공통적으로 겪는 피로가 담겨 있어요.
정확히 뭐가 문제냐면
콘솔 해킹이나 커널 개발 같은 분야는 깊이가 생명이에요. 하이퍼바이저가 어떻게 메모리를 격리하는지, 특정 익스플로잇이 왜 이 펌웨어 버전에서만 동작하는지 같은 걸 이해하려면 몇 달, 몇 년의 삽질이 필요하거든요. 그런데 LLM이 등장하면서 상황이 바뀌었어요. 코드 한 줄 제대로 못 읽는 사람도 챗GPT나 클로드에게 '이 리포지토리에 이런 기능 추가해줘'라고 하면 그럴듯한 PR(풀 리퀘스트, 코드 변경 제안)을 만들어낼 수 있게 됐어요.
문제는 그 PR이 그럴듯해 보이지만 틀린 경우가 많다는 거예요. 겉으로는 컴파일도 되고 설명도 논리적인데, 실제로는 하드웨어 동작을 잘못 가정했거나, 기존 코드의 미묘한 제약을 깨뜨리거나, 아예 존재하지 않는 API를 호출하기도 해요. 이걸 걸러내는 건 결국 메인테이너의 몫이에요. 그리고 검토에 드는 시간은 PR을 만드는 데 든 시간보다 훨씬 길어요. 제출자는 5분 만에 만들었는데, 검토자는 두 시간을 써야 '이거 왜 안 되는지' 설명할 수 있는 거죠.
더 힘 빠지는 건 피드백을 줘도 대화가 안 된다는 점이에요. '이 부분은 DMA 컨트롤러 동작 때문에 이렇게 하면 안 돼요'라고 설명하면, 제출자가 그 설명을 이해하고 고치는 게 아니라 그 코멘트를 다시 LLM에 붙여넣고 새 버전을 던지는 식이거든요. 메인테이너 입장에서는 사람이 아니라 프록시를 상대하는 느낌이 되는 거예요. 몇 번 이런 일을 겪으면 '내가 왜 무료로 남의 LLM 출력을 디버깅해주고 있지'라는 회의가 오는 게 당연해요.
이건 PS5만의 얘기가 아니에요
비슷한 일이 여기저기서 터지고 있어요. curl의 창시자 다니엘 스텐버그는 AI가 생성한 가짜 보안 취약점 신고가 너무 많아져서 결국 버그 바운티 프로그램을 중단하기로 했다고 밝혔어요. 이게 뭐냐면, 보안 연구자가 '여기 취약점 있어요'라고 신고하면 보상을 주는 제도인데, LLM이 만들어낸 존재하지 않는 취약점 리포트가 쏟아지면서 검토 인력이 갈려나간 거예요. 터미널 에뮬레이터 Ghostty처럼 AI 생성 기여에 대한 정책을 따로 만든 프로젝트도 있고, 아예 'AI로 생성한 코드는 밝혀라'라는 규칙을 기여 가이드에 넣은 프로젝트도 늘고 있어요.
이런 현상을 흔히 AI 슬롭(AI slop)이라고 불러요. 양은 많은데 질은 낮은, 누군가의 시간을 잡아먹기만 하는 콘텐츠를 뜻하는 말인데, 이제 코드에도 이 단어가 붙기 시작한 거예요.
그렇다고 LLM이 나쁜 건 아니에요
여기서 오해하면 안 되는 게, 사퇴한 개발자도 'LLM 쓰지 마'라고 한 건 아니에요. 핵심은 '이해하지 못한 채로'라는 부분이에요. 숙련된 개발자가 LLM으로 보일러플레이트를 빨리 짜고, 낯선 API 문서를 요약하고, 테스트 케이스를 뽑아내는 건 생산성을 확실히 올려줘요. 문제는 LLM의 출력을 자기 판단 없이 그대로 남에게 던지는 행동이에요. 코드를 제출한다는 건 '이 변경이 왜 맞는지 내가 설명할 수 있다'는 책임을 지는 일인데, 그 책임이 사라진 거죠.
한국 개발자에게
한국에서도 오픈소스 기여를 취업 포트폴리오로 활용하려는 분들이 많잖아요. 그런데 이제 메인테이너들은 '이 사람이 진짜 이해하고 보낸 건가'를 예전보다 훨씬 의심스럽게 봐요. 그래서 오히려 기회이기도 해요. PR에 왜 이렇게 바꿨는지, 어떤 대안을 고려했고 왜 버렸는지, 어떻게 테스트했는지를 자기 말로 써서 보내면 그 자체로 차별화가 되거든요. LLM을 써서 초안을 만들었더라도, 한 줄 한 줄 읽고 설명할 수 있을 때까지 다듬은 다음에 보내는 습관이 중요해요.
그리고 회사 안에서 오픈소스를 운영하거나 사내 라이브러리를 관리하는 분이라면, 기여 가이드에 AI 사용 관련 원칙을 지금 넣어두는 게 좋아요. 나중에 문제가 터진 뒤에 만들면 감정 싸움이 되기 쉽거든요. '사용해도 되지만 밝혀야 하고, 제출자가 코드를 설명할 수 있어야 한다' 정도의 원칙만 있어도 리뷰어의 부담이 꽤 줄어요.
정리하면
핵심은 이거예요. LLM은 코드를 만들어주지만, 코드에 대한 책임까지 만들어주지는 않는다.
여러분은 어떻게 생각하세요? 오픈소스 프로젝트가 AI 생성 기여를 아예 금지해야 할까요, 아니면 '밝히기만 하면 OK'가 현실적인 타협일까요? 그리고 여러분 팀의 코드 리뷰는 AI가 만든 PR을 걸러낼 준비가 되어 있나요?
🔗 출처: Hacker News