금지 조항보다 그 옆 문장이 기준이다

GNOME 메인테이너 한 명이 LLM 정책 초안을 냈다. 금지 조항이 먼저 눈에 들어오지만, 실제 기준은 그 옆 문장이다.

You must be able to personally reason and explain your changes

이 조건은 AI를 썼는지와 무관하게 원래부터 좋은 기여의 조건이었다. 그러니 이 정책이 실제로 걸러내려는 건 LLM이 아니라 설명하지 못하는 기여다.

출처: The GNOME LLM policy that I want

먼저 분명히 해둔다. 이건 GNOME의 공식 정책이 아니다. 제목 그대로 한 메인테이너가 "내가 바라는" 정책을 적은 블로그 글이고, 채택 여부는 확인하지 못했다.

확인된 것

제안된 금지는 범위가 넓다.

LLMs ("AI") can not be used to create or modify anything submitted to GNOME, or hosted on GNOME infrastructure.
기여자에게 요구하는 것: 자기 변경을 스스로 설명할 수 있을 것, 다루는 문제 영역에 대한 지식을 보일 것, 증상이 아니라 근본 원인을 고칠 것, 다른 기여자의 시간을 존중할 것.
이유로 든 것은 기술이 아니라 공동체다. 프로젝트가 "챗봇 출력을 리뷰해주는, 소수 기업을 위한 무료 노동" 으로 전락하는 것을 막겠다는 것.
강제할 수 없다는 점을 스스로 인정한다. 탐지 수단을 만들자고 하지 않고, 행동 강령과 같은 종류 — 우리의 가치가 무엇인지 알리는 문서 — 로 위치시킨다. 첨부된 가이드라인은 메인테이너가 "합리적 의심을 넘어" 판단하도록 돕는 용도라고 쓴다.
토론에서는 전면 금지가 오히려 단순하다는 쪽, 무급 노동에 추가 조건을 다는 게 맞느냐는 쪽, 자동 코드 변환 도구 쪽이 나을 거라는 쪽이 갈렸다.

판단

1. 채택 여부보다 이런 글이 나왔다는 사실이 신호다

아직 정책이 아니다. 그런데 규범은 문서보다 먼저 사람들 머릿속에 자리잡는다. 에이전트로 PR을 만드는 사람이 늘면 받는 쪽에서 반드시 이런 논의가 생기고, 논의가 정책이 되기 전에 리뷰어의 태도부터 바뀐다.

→ 실행 항목: 내가 기여하는(또는 기여할) 프로젝트의 CONTRIBUTING과 최근 이슈·메일링 리스트에서 LLM 관련 논의를 한 번 검색해봐라. 명문 규정이 없어도 분위기는 이미 형성돼 있을 수 있고, 그걸 모르고 에이전트로 만든 PR을 올리면 코드가 아니라 태도로 거절당한다.

2. 도구가 아니라 설명 능력이 기준이다

금지 조항은 경계가 흐리다. 자동완성은? 커밋 메시지 정리는? 번역은? 반면 "자기 변경을 스스로 설명할 수 있어야 한다"는 명확하고, 리뷰어가 실제로 확인할 수 있다.

그래서 에이전트를 쓰는 사람에게 남는 실무 규칙은 단순하다. PR을 올리기 전에 리뷰어가 던질 질문 세 개에 스스로 답해본다.

왜 이 방식인가 (다른 방식은 왜 아닌가)
이 변경이 깨뜨릴 수 있는 건 무엇인가
근본 원인은 무엇이었나 (지금 고친 게 증상은 아닌가)

세 개에 답할 수 있으면 도구가 무엇이었든 좋은 PR이고, 못 하면 도구와 무관하게 나쁜 PR이다. 에이전트가 늘린 건 나쁜 PR의 공급량이지 종류가 아니다.

3. 검사할 수 없는 것을 검사하는 척하지 않았다

이번 주에 반복한 기준이 있다 — 문서에 적힌 규칙은 깨지고 실행되는 검사만 남는다. 이 글은 겉보기에 그 반대다. 강제할 수 없는 규칙을 문서로만 두겠다고 한다.

그런데 같은 정직함의 다른 면이라고 본다. LLM 사용 여부는 신뢰성 있게 탐지할 수 없다. 탐지기를 붙이면 오탐으로 멀쩡한 기여자를 쫓아내고, 그러면 규칙도 잃고 사람도 잃는다. 저자는 그걸 알고 탐지를 시도하지 않는다.

→ 정리하면 규칙이 하나 더 나온다. 기계가 못 잡는 것은 규범으로 두고, 기계가 잡을 수 있는 것만 게이트로 만든다. 둘을 섞으면 게이트는 오탐으로 헐거워지고 규범은 "어차피 안 걸리는데"로 무력해진다. 내 프로젝트의 규칙 목록을 이 기준으로 두 칸에 나눠보면 대부분은 자리를 잘못 잡고 있다.

4. 비용이 보내는 쪽에서 받는 쪽으로 넘어갔다

"챗봇 출력을 리뷰하는 무료 노동"이 이 글의 진짜 주장이다. 이번 주에 네 번 도달한 결론과 같은 자리인데, 오픈소스에는 비대칭이 하나 더 있다.

PR을 보내는 쪽의 비용은 크게 줄었고 받는 쪽의 비용은 그대로다. 그리고 받는 쪽은 대개 무급이다. 예전에는 PR을 만드는 데 든 시간 자체가 필터였다. 그 필터가 사라졌는데 리뷰 용량은 안 늘었다.

→ 남의 프로젝트에 에이전트로 기여할 생각이라면 한 번 계산해볼 만하다. 내가 아낀 시간과 메인테이너가 쓸 시간 중 어느 쪽이 큰가. 후자가 크면 그건 기여가 아니라 청구서다. 이 계산은 사내 저장소에서도 똑같이 성립하고, 거기서는 청구서를 받는 사람이 동료다.

모르는 것

GNOME의 공식 정책이 아니다. 한 메인테이너의 제안이고, 프로젝트 내 지지 정도나 채택 여부를 확인하지 못했다.
첨부됐다는 가이드라인의 내용을 보지 못했다. "합리적 의심을 넘어" 판단하도록 돕는다는 서술만 확인했다.
GNOME에 실제로 LLM 생성 PR이 얼마나 들어오는지 수치가 없다. 체감인지 측정인지 알 수 없고, 이 글은 수치를 제시하지 않는다.
다른 대형 오픈소스 프로젝트들의 현재 정책을 조사하지 않았다. 이 제안이 예외인지 흐름의 일부인지 나는 판단할 근거가 없다.
"LLM으로 수정한 것"의 경계가 글에서 명확하지 않다. 에디터 자동완성, 커밋 메시지 다듬기, 문서 번역이 어디까지 포함되는지 확인하지 못했다. 2번에서 설명 능력 쪽을 기준으로 삼자고 한 이유이기도 하다.