GHC는 LLM 기여에 사람의 책임과 사용 공개를 요구한다

Hacker News그저께

하스켈 컴파일러 GHC가 LLM을 활용한 기여를 어떻게 받아들일지에 대한 공식 정책을 확정했다. 위키 문서 자체는 여름 논쟁 이전부터 존재했지만, 10월 중순을 전후로 메인테이너들이 리뷰 대화에서 정책 조항을 직접 근거로 인용하기 시작했다는 점에서 이제 실효성을 갖춘 규칙이 됐다. 리뷰 과정에서 정책 3항이 인용됐고, LLM이 만든 버그 수정을 두고도 정책상 허용된다는 취지의 언급이 나왔다.

정책의 골격은 네 개의 조항과 한 개의 강한 권고다. 1항은 사람과 커뮤니티를 우선한다. LLM으로 코드베이스를 훑거나 번역하고 문제를 조사하는 것은 허용되지만, 리뷰어와의 대화를 생성된 텍스트로 대체해서는 안 된다. 오픈소스 프로젝트가 기여자와 메인테이너를 길러내는 통로가 바로 그 대화이기 때문이다.

2항은 머지 리퀘스트를 리뷰하기 쉽게 만들라는 요구다. 기여자는 리뷰어가 내용을 파악하는 데 드는 시간보다 더 많은 공을 들여야 하며, 목표와 설계 의도, 예제와 테스트가 드러나고 적당한 크기로 쪼개져 있어야 한다. 컴파일만 통과하는 패치를 던지고 추론 과정을 리뷰어가 재구성하게 만드는 방식은 이 기준을 넘지 못한다.

3항은 사람 저자와 전적 책임에 관한 것이다. 제출되는 코드와 문서의 모든 줄을 이해하고 설명할 수 있는 사람이 있어야 한다. 생성된 결과물이라도 충분히 검토해 책임질 수 있으면 제출 가능하다. 반면 버그 티켓은 좀 더 느슨하게 다루는데, 컴파일러 내부 동작을 모르는 사람이 올린 보고서도 유용할 수 있기 때문이다. 초안 상태임을 분명히 표시하고 아직 리뷰를 요청하지 않은 드래프트 MR도 미완성·생성물을 담을 수 있다.

4항은 공개 의무다. LLM이 코드, 문서, 테스트의 일부라도 직접 만들어냈다면 이를 알려야 하며, 보통 이슈나 MR 설명과 커밋 메시지에 Assisted-By: 한 줄을 남긴다. 프롬프트를 전부 공개할 필요는 없고, 탐색이나 디버깅, 설계 아이디어를 위한 사적 활용은 고지 대상에서 빠진다. 5항은 권고다. 최종본은 가급적 직접 작성하는 편이 좋다는 것으로, 강제 조항은 아니며 사람이 모든 글자를 타이핑했는지가 아니라 앞의 조항들로 기여를 평가한다. 다만 몇 년 뒤에도 읽히는 설계 근거를 담는 GHC Note는 특별히 주의 대상으로 꼽았다.

이 문서는 7월 ghc-devs 논의에서 사이먼 페이턴 존스가 발전시킨 초안을 계승한 결과다. 당시 별도로 제안된 '공동 성명'은 기여 정책을 대체할 목적이 아니라고 제안자들 스스로 밝혔고, 이를 정책처럼 취급하는 데 반대하는 목소리도 있었다. 7월 27일 시점에는 세 개 조항과 한 개 권고로 정리돼 있었지만 최종본은 네 개 조항과 한 개 권고가 됐다. 커뮤니티 건강에 관한 논의가 첫 번째 항목으로 승격되면서 기존 운영 규칙들의 번호가 하나씩 밀린 것이 가장 큰 구조 변화다.

정책의 초점은 LLM의 성능이나 도덕성이 아니라 리뷰 비용이다. GHC에는 6,500건이 넘는 열린 티켓이 쌓여 있고, 그중에는 어려운 컴파일러 문제도 있지만 오래된 보고를 재현하거나 테스트 케이스를 줄이고 벤치마크를 보강하는 일상적인 작업도 많다. 패치 생성이 싸진다고 해서 리뷰가 비싸지면 별 소용이 없다. 20분 만에 만들어진 패치가 메인테이너의 두 시간을 잡아먹을 수 있기 때문이다.

LLVM은 이런 상황을 두고 '추출적 기여'라는 표현을 쓴다. 나디아 에그발이 《Working in Public》에서 다룬 개념을 빌려온 것으로, 기여자는 제출에서 이득을 얻고 프로젝트는 기여 가치보다 큰 리뷰·통합 비용을 치르는 구조를 가리킨다. LLM이 없던 시절에도 이해하지 못한 거대한 패치를 올리는 사람은 있었지만, 이제 그런 패치를 만드는 일이 훨씬 쉬워졌다. 상업 개발 현장에서도 유사한 신호가 관측됐다. 파로스(Faros)의 조사에서는 AI 도입 수준이 높은 팀일수록 더 많고 큰 풀 리퀘스트를 만들었지만 리뷰 시간도 함께 늘었다. 관측 연구라 기업 조직과 GHC를 그대로 비교할 수는 없어도, 코드 생산이 개발 과정의 한 부분일 뿐이라는 결론은 같다.

유지보수자 양성이라는 문제도 걸려 있다. 작은 이슈를 처리하는 과정에서 기여자는 시스템의 다른 부분을 배우고, 리뷰어의 설명을 통해 왜 뻔한 해법이 통하지 않는지 익힌다. 지그(Zig) 정책을 설명하며 로리스 크로가 말한 '기여자 포커'가 여기에 해당한다. 메인테이너가 쓰는 시간은 낭비되는 비용이 아니라 다음 세대를 만드는 투자라는 시각이다.

실무적으로 남는 신호는 분명하다. LLM을 쓰되 책임과 공개 의무는 사람에게 남는다. AI로 만든 패치를 오픈소스에 보낼 때는 리뷰어의 시간을 기준으로 패치를 다듬고, 사용 사실을 커밋에 남기고, 자신이 설명할 수 없는 줄은 남기지 않는 것이 기본값이 된다. GHC는 LLM의 비용과 편익에 대해 프로젝트 내부 합의가 없다는 점을 문서에 명시했다. 이 정책은 LLM이 좋은지 나쁜지를 판정하지 않고, 어떤 기여가 리뷰 시간을 쓸 자격이 있는지의 조건만 정의한다.