메뉴
HN
Hacker News • 29일 전

이력서 채우려고 우리 프로젝트에 AI 쓰레기 쏟아넣지 마세요

IMP
6/10
핵심 요약

오픈소스 유지보수자가 AI로 대량 생성된 PR, 이슈 분석, 보안 취약점 리포트가 GitHub 활동 그래프를 채우려는 목적으로 쏟아져 들어온다고 지적한다. Claude가 오타 수정 PR을 자동 생성하고 공동 저자 표시까지 삽입하는 사례가 늘면서, 유지보수자는 실질적 개선이 없는 PR을 닫고 저심각도 보고에 CVE 발급을 거부하며 대응하고 있다. AI를 활용한 GitHub 신호 게임화(gaming)가 오픈소스 기여 문화를 오염시키는 문제로 부상했다.

번역된 본문

Neil / 홈 / 블로그 / GitHub

이력서 채우려고 우리 프로젝트에 AI 쓰레기 쏟아넣지 마세요 2026년 6월 30일, Neil 작성

오픈소스 프로젝트에 대한 성공적인 기여는 일종의 화폐와 같습니다. GitHub은 특히 여러 방식으로 이를 장려합니다. 저장소 페이지에 기여자 아바타를 표시하고, 활동 피드를 통해 팔로워에게 기여 내역을 보여주며, 프로필의 활동 그래프에 일일 기여 수를 표시합니다. 채용 담당자들은 종종 이를 주목하며, 리크루터들은 이런 방식으로 후보자를 찾고 검증합니다. 개발자(현직이든 지망생이든)로서 일자리를 찾고 있다면 이런 신호를 잘 다듬는 것이 유리하게 작용하기도 합니다.

오픈소스 유지보수자로서 지난 1년간 외부 기여 패턴이 어떻게 변했는지 뚜렷하게 체감됩니다. 이제 이슈 대신 풀 리퀘스트(PR)를 받는 경우가 훨씬 많아졌습니다. 이슈를 받더라도 AI가 생성한 분석이 첨부된 경우가 많습니다. 보안 취약점 리포트도 예전보다 훨씬 많이 받고 있으며, 심지어 AI가 생성한 수정 제안까지 첨부되어 오기도 합니다.

이런 기여의 일부가 우리가 하는 일에 진심으로 관심 있는 사람들에게서 온 것이라고 의심하지 않습니다. 하지만 내 속의 냉소적인 부분은, 상당수가 사람들이 AI를 활용해 자신에게 유리하게 GitHub을 조작할 수 있다는 것을 깨달았기 때문이라고 믿습니다. 이제 Claude에게 흥미로운 오픈소스 프로젝트 목록을 뽑아달라고 하고, 그 안에서 문제를 찾아달라고 하고, 고칠 PR을 올려달라고 부탁하기만 하면 됩니다. 해당 프로젝트를 사용할 필요도, 관심을 가질 필요도 없지만, 외부인에게는 관심을 갖고 있었던 것처럼, 문제를 발견한 것처럼, 고치는 데 시간을 들인 것처럼 쉽게 보이게 만들 수 있습니다. 인터넷에서는 아무도 당신이 개인 줄 모르지만, LLM의 도움으로 GitHub 프로필에서 인간의 능력을 아무런 수고 없이 과장할 수 있게 되었습니다.

최근에 한 기여자가 PR을 올렸습니다. 이 사람은 2018년 말부터 몇 주 전까지 GitHub 전체에서 사실상 기여 이력이 없었고, 우리가 아는 한 우리 프로젝트에 관여한 적도 없었는데, 댓글의 맞춤법과 문법 오류를 고치는 세 개의 개별 PR을 올렸습니다. Claude가 수정을 했고, 아마 PR 설명도 작성했으며, 사용자를 대신해 커밋에 서명까지 하고, 커밋 메시지 트레일러에 자신의 공동 저자 표시를 친절하게 삽입했습니다. 어쩌면 PR 자체를 직접 열었을지도 모릅니다. 프롬프트가 "가서 이슈를 찾아라"였는지, 아니면 어떤 이유로든 특별히 맞춤법과 문법 문제에 집중하라는 것이었는지 궁금합니다.

변경 자체는 무해하고 정확했지만, 그렇다고 받아들이거나 병합하기가 기분이 좋지 않았습니다. 그 대신 스스로에게 묻지 않을 수 없었습니다. 왜 이것을, 왜 지금? 우리 코드베이스의 수많은 이슈와 TODO와 FIXME 중에서 하필 이것을 제출하는 걸까? 그리고 깨달았습니다. 이 기여는 우리 프로젝트에 관한 것이 전혀 아니라는 것을. 저는 세 개의 PR 모두를 아무 코멘트 없이 닫았습니다. 무리한 처사였을지도 모릅니다. 하지만 솔직히, 사람들이 이런 부산물로 우리 시간을 낭비하게 하는 것에 흥미가 없습니다. 실질적으로 아무것도 개선하지 않는 PR을 받아들이는 선례를 만들고 싶지 않고, 기여자 명단이 로봇에게 오타 수정을 시킨 대가로 주어지는 보상이 되는 것도 원하지 않습니다.

보안 취약점 리포트에서도 같은 패턴이 나타났습니다. 전통적으로 CVE는 보고자에게 크레딧이 돌아가지만, 최근 받은 모든 리포트는 명백히 AI가 생성한 것이었습니다. 보안 수정은 언제나 중요하지만, 다시금 자문하게 됩니다. 사람들이 수정에 관심이 있어서인지, 아니면 손쉬운 크레딧을 노려서인지. 우리는 최근 이런 리포트의 심각도를 평가할 때 훨씬 엄격해졌고, 일부 경우 저심각도 항목에 대해서는 CVE 공지 발급을 거부하고 있습니다. 비공개 책임 공개(divulgation) 문화가 어차피 죽어가고 있다는 사실에 대해서도 할 말이 좀 있어서 나중에 따로 글을 쓸 수도 있지만, 비공개 수정과 공지, 릴리스를 조율하는 데 드는 수고는 상당합니다.

원문 보기
원문 보기 (영어)
Neil Home Blog GitHub Please stop flooding our projects with AI slop to furnish your CV 30 June 2026 by Neil Successful contributions to open source projects are a kind of currency. GitHub in particular encourages this in a number of ways: by showing avatars of contributors on repository pages, by showing your contributions to your followers via the activity feed and by signalling contributions per day on the activity graph of your profile. Potential hiring managers often take note of this. Recruiters often find and screen candidates this way. If you are a software developer (either existing or aspiring) looking for work, tuning these signals can often work to your advantage. As an open source maintainer, it’s quite noticeable how the pattern of external contributions has changed in the last year. We’re far more likely to receive pull requests instead of issues. If we do receive issues, they often come with an AI-generated analysis attached. We’re receiving far more security vulnerability reports than ever before and often they even come with AI-generated fix proposals attached too. I don’t doubt that some of these contributions are from people who are genuinely interested in what we do, but the cynical part of me believes that a substantial amount of this is that people are realising that AI can be used to game GitHub to their own benefit. It’s now easy to ask Claude to generate a list of interesting open source projects, then ask Claude to find some problems in them, and then ask Claude to raise some PRs to fix them. You don’t even have to use the projects or care about them, but you can easily create the illusion to outsiders that you care, or that you found a problem, or that you put the time into fixing it. On the internet, nobody knows you’re a dog, but with the help of LLMs, you can effortlessly overstate your human abilities on your GitHub profile. Recently, a contributor with virtually no GitHub-wide contributions from late 2018 up until a couple weeks ago, with no prior engagement with our project that we know of, raised three separate PRs to correct spelling and grammar mistakes in comments. Claude made the fixes, presumably wrote the PR descriptions, even signed off the commits on behalf of the user and then helpfully inserted its co-authorship into the commit message trailers. Maybe it even opened the PRs itself, who knows. I’d be fascinated to know whether the prompt was to “go and find issues” or whether to focus on spelling and grammar issues in particular for whatever reason. The changes were harmless and correct, but that did not make me feel better about accepting or merging them. Instead I couldn’t help but ask myself: why this, why now? Why, out of all of the issues and TODO s and FIXME s in our codebase are they submitting this ? And then it dawned on me that these contributions weren’t about our project at all. I closed all three PRs without comment. Maybe this was unreasonable, but truthfully, I’m just not interested in encouraging people to take up our time with this kind of busywork. I do not want to set a precedent of accepting PRs that materially improve nothing, nor do I want our contributor list to become a reward for asking a robot to fix typos. The same pattern has emerged with security vulnerability reports. CVEs traditionally are credited to their reporters, but all of the reports that we have received recently have been obviously AI-generated. Security fixes are always important of course, but again I find myself wondering if this is happening because people care about the fixes or because they are looking for an easy credit. We have been far more selective lately when evaluating the severity of such reports and, in some cases, declining to issue CVE notices for low-severity items. I have some feelings about the fact that private disclosure is dying anyway, which I may write about another time, but the effort involved in coordinating private fixes and disclosure notices and releases is substantial enough to require us to be selective. Ultimately, open source is built on trust. The metric that matters is not how many pull requests you can persuade an LLM to produce, nor how many CVEs you can accumulate, but whether you can make a project meaningfully better. If you want to contribute to open source projects, contribute because you care. If all you want is another green square or another contributor badge, please go elsewhere.