진짜로 도움이 되고 싶다면, 자신이 직접 소유하고 유지보수하는 저장소에 그 에너지를 쏟는 게 좋음
사람들도 이런 습관을 배워야 함. 포크를 공개하는 건 쉬워졌지만, 본인이 실제로 쓰지 않는 코드를 남이 써주길 기대하면 안 됨
GitHub에서 하루에 몇 개의 프로젝트에 PR을 보내는지 통계를 보면, 99%는 하나, 1%는 두 개, 0.1%는 세 개임. 5개 이상 PR을 보내는 계정은 거의 전부 봇이나 스크립트였음. 등록되지 않은 봇은 속도 제한을 걸어야 함
이런 상황이라면, 내 포크가 원본 저장소 위에 주기적으로 리베이스되는 영구 패치 모드 같은 기능이 있으면 좋겠음. 예를 들어 한 줄짜리 수정이라도 자동으로 최신화되는 식으로
나는 Ghostty의 AI 정책을 더 선호함
“AI의 도움 없이 변경 사항이 무엇을 하고 시스템 전체에 어떤 영향을 주는지 설명할 수 없다면, 이 프로젝트에 기여하지 말라”는 문장이 특히 마음에 듦
좋은 아이디어이긴 한데, 실행 방법이 문제임. AI에게 설명을 시키고 그걸 자기 말로 다시 쓰면 사실상 우회가 가능함
오픈소스 기여가 일종의 통과의례처럼 되어버린 게 문제라고 생각함
진짜 기여보다 ‘기여했다는 사실’이 중요해지면 이런 얕은 PR이 생김. 예전엔 취약점 제보도 비슷했음 — “null을 넣으면 NullPointerException이 난다” 수준의 제보들
개발 속도 같은 잘못된 지표를 중시하는 것도 문제임. 예전 회사에서 AI로 빠르게 개발한다고 자랑하던 동료의 PR을 봤더니 테스트가 전부 실패했음. 결국 AI 보조의 게임화 현상임
나도 요즘 AI로 작성된 지원서를 많이 받음. 그중 일부는 GitHub 기여를 강조하더라. 아마 이런 식의 PR이 실제로 통과되는 경우가 있는 듯함. 프로젝트의 별 개수를 채용 지표로 삼는 문화가 이런 스팸을 부추김
“수학을 정말 빨리 할 수 있다” → “그럼 137*243은?” → “132,498” → “틀렸어” → “그래도 빨랐잖아” 같은 느낌임
이건 그냥 재미로 쓴 블로그 글임. AI로 저품질 PR을 보내는 사람들은 이런 글을 읽지도 않음
내가 하는 방식은 간단함:
PR 닫기
너무 성의 없으면 사용자 차단
최근엔 문자열 정의에 ‘’ 대신 ''를 써서 CI 전체가 실패한 PR도 있었음. 바로 차단함
PR을 닫을 때 이 페이지 링크를 댓글에 첨부하는 게 좋을 듯함
버그라면 수정이 확인되는 빨간 줄(diff) 이 있어야 하고, 기능이라면 최소한 승인 기준이 필요함
문서라면 읽어서 이해만 되면 됨. 도움을 받는 기준은 꽤 낮음
“오픈소스 유지보수자는 환영하는 커뮤니티를 만들어야 하지 않나?”라는 질문에 대해, 그건 의무가 아님
유지보수자는 프로젝트의 주인이며, 친절할 필요도 없음. 마음에 안 들면 포크하거나 떠나면 됨
이런 주장은 사실 감정적 조종에 가깝다고 봄. “우리의 시간을 감정적으로 낭비하지 말고, 왜 LLM이 생성한 PR이 쓸모없는지 이해하라”고 말하는 게 더 낫다고 생각함. 우리도 LLM을 쓸 줄 알고, 그 이후의 실제 작업량이 얼마나 큰지도 알고 있음
정말 통쾌함. 이런 글이 무성의한 PR 제출자들을 부끄럽게 만드는 데 널리 쓰였으면 좋겠음. FAQ의 직설적이고 무례한 어조가 오히려 시원함
하지만 그런 사람들은 부끄러움을 느끼지 않음. 전화 사기꾼에게 화내는 것과 같음 — 그냥 끊고 다시 시도할 뿐임
회사에서 있었던 일임. AI로 작은 기능 요청을 해결하는 코드를 만들었는데, 코드베이스를 잘 몰라서 정확성을 확신할 수 없었음
1분 프롬프트, 5분 정리, 30분 리뷰로 2일치 엔지니어링 시간을 절약할 수도 있었지만, 결국 신뢰가 문제였음
여러 의견을 들은 결과, 그냥 기능 요청만 올리고 diff는 포함하지 않기로 함.
흥미롭게도 AI 찬성파는 “AI를 더 써서 자신감을 높이라”고 조언했는데, 오히려 계속 수정하다 보니 코드가 꼬여서 완전히 신뢰를 잃음
만약 LLM이 만든 코드를 실제로 쓰고 싶다면, 모든 변경을 이해하고, 그걸 직접 요약해 기능 요청에 첨부하는 게 좋음
나도 LLM이 만든 PR을 여러 번 받았는데, 대화가 안 되고, 기존 패턴을 무시한 코드라 결국 버려야 했음.
사람이라면 자신의 관점에서 문제를 설명해주길 바람. 그게 훨씬 도움이 됨
당신은 좋은 엔지니어링 감각을 가지고 있음. 업계에 이런 사람이 더 많았으면 함
“2일치 엔지니어링 시간 절약”이란 말이 이해가 안 됨. 코드베이스를 아는 사람이 똑같이 AI를 쓸 수도 있잖음. 왜 AI 출력물을 남에게 검증시키려는지 모르겠음. 우리도 LLM을 쓸 줄 앎
관련 글: Prompting에 대한 글
나도 비슷한 접근을 함. Claude가 만든 코드를 완전히 이해하지 못할 때는, “이 부분은 왜 이렇게 했어?” “엣지 케이스는 어떻게 처리돼?” 같은 질문을 던지고, 수정하지 말고 설명만 하라고 요청함. 이렇게 하면 결과를 내 것으로 만들 수 있음
그 라이브러리를 실제로 사용 중이라면, 스테이징 환경에서 테스트해보고 리뷰를 제출하는 게 좋음
Hacker News 의견들
진짜로 도움이 되고 싶다면, 자신이 직접 소유하고 유지보수하는 저장소에 그 에너지를 쏟는 게 좋음
사람들도 이런 습관을 배워야 함. 포크를 공개하는 건 쉬워졌지만, 본인이 실제로 쓰지 않는 코드를 남이 써주길 기대하면 안 됨
GitHub에서 하루에 몇 개의 프로젝트에 PR을 보내는지 통계를 보면, 99%는 하나, 1%는 두 개, 0.1%는 세 개임. 5개 이상 PR을 보내는 계정은 거의 전부 봇이나 스크립트였음. 등록되지 않은 봇은 속도 제한을 걸어야 함
나는 Ghostty의 AI 정책을 더 선호함
“AI의 도움 없이 변경 사항이 무엇을 하고 시스템 전체에 어떤 영향을 주는지 설명할 수 없다면, 이 프로젝트에 기여하지 말라”는 문장이 특히 마음에 듦
오픈소스 기여가 일종의 통과의례처럼 되어버린 게 문제라고 생각함
진짜 기여보다 ‘기여했다는 사실’이 중요해지면 이런 얕은 PR이 생김. 예전엔 취약점 제보도 비슷했음 — “null을 넣으면 NullPointerException이 난다” 수준의 제보들
개발 속도 같은 잘못된 지표를 중시하는 것도 문제임. 예전 회사에서 AI로 빠르게 개발한다고 자랑하던 동료의 PR을 봤더니 테스트가 전부 실패했음. 결국 AI 보조의 게임화 현상임
이건 그냥 재미로 쓴 블로그 글임. AI로 저품질 PR을 보내는 사람들은 이런 글을 읽지도 않음
내가 하는 방식은 간단함:
최근엔 문자열 정의에 ‘’ 대신 ''를 써서 CI 전체가 실패한 PR도 있었음. 바로 차단함
버그라면 수정이 확인되는 빨간 줄(diff) 이 있어야 하고, 기능이라면 최소한 승인 기준이 필요함
문서라면 읽어서 이해만 되면 됨. 도움을 받는 기준은 꽤 낮음
“오픈소스 유지보수자는 환영하는 커뮤니티를 만들어야 하지 않나?”라는 질문에 대해, 그건 의무가 아님
유지보수자는 프로젝트의 주인이며, 친절할 필요도 없음. 마음에 안 들면 포크하거나 떠나면 됨
정말 통쾌함. 이런 글이 무성의한 PR 제출자들을 부끄럽게 만드는 데 널리 쓰였으면 좋겠음. FAQ의 직설적이고 무례한 어조가 오히려 시원함
회사에서 있었던 일임. AI로 작은 기능 요청을 해결하는 코드를 만들었는데, 코드베이스를 잘 몰라서 정확성을 확신할 수 없었음
1분 프롬프트, 5분 정리, 30분 리뷰로 2일치 엔지니어링 시간을 절약할 수도 있었지만, 결국 신뢰가 문제였음
여러 의견을 들은 결과, 그냥 기능 요청만 올리고 diff는 포함하지 않기로 함.
흥미롭게도 AI 찬성파는 “AI를 더 써서 자신감을 높이라”고 조언했는데, 오히려 계속 수정하다 보니 코드가 꼬여서 완전히 신뢰를 잃음
나도 LLM이 만든 PR을 여러 번 받았는데, 대화가 안 되고, 기존 패턴을 무시한 코드라 결국 버려야 했음.
사람이라면 자신의 관점에서 문제를 설명해주길 바람. 그게 훨씬 도움이 됨
관련 글: Prompting에 대한 글
마지막의 plonk 표현이 너무 좋았음
Plonk(Usenet) 참고
“rm -rf로 로컬 브랜치나 헛소리 스크립트를 지워라”는 문장이 너무 웃김
“유기적 뇌를 하드 리부트하라”는 표현도 완벽함