역 센타우르가 아니다

한 줄 요약

미겔 그린버그(Flask, Flask-SocketIO 등 유명 오픈소스 프로젝트의 메인테이너)는 AI가 생성한 코드를 사람이 검토하는 역할을 거절한다고 선언했다. 그는 자신이 "역 센타우르"(AI가 생성한 결과를 사람이 수검하는 역할)가 되기를 거부하며, AI 없이 직접 코딩하는 방식을 고수하고 있다.

핵심 내용

"역 센타우르"란 무엇인가

"역 센타우르"는 코리 닥터로우가 만든 표현이다. 체스 세계 챔피언 가리 카스파로프가 AI와 팀을 이루어 "센타우르" 팀을 만들었다는 데서 온 개념이다. 원래 센타우르는 사람이 주도하고 AI가 보조하는 조합을 의미하는데, "역 센타우르"는 그 반대 — AI가 코드를 생성하고 사람이 그냥 검토만 하는 역할을 뜻한다.

그린버그는 자신이 이런 역할이 되기를 거부한다. 그는 블로그와 오픈소스 작업에서 LLM, 에이전트, 생성형 AI를 전혀 사용하지 않는다고 명시했다.

오픈소스 기여 정책의 변화

그린버그는 LLM이 생성한 PR(코드 변경 요청)이 그의 프로젝트로 쏟아져 들어오면서, 다음과 같은 엄격한 기여 가이드라인을 도입했다.

1. 이슈(Issue) 사전 승인 필수

코드 변경을 제안하려면 먼저 이슈에서 인간 대 인간의 대화를 통해 변경 사항을 승인받아야 한다. 사전 논의 없이 제출된 PR은 작성자의 재량으로 즉시 닫힐 수 있다.

"이 프로젝트에 변경 사항을 기여하고 싶다면, 먼저 이슈를 통해 변경 사항을 메인테이너에게 소개해주세요. 이슈에서 사전 논의 없이 제출된 풀 리퀘스트는 메인테이너의 재량으로 닫힐 수 있습니다."

2. 요청하지 않은 PR의 즉각 거부

예상치 못한 PR이 들어오면 몇 초 안에 그 뒤에 인간이 있는지 확인한다. LLM 스타일의eneric한 설명만 있고 인간 참여의 증거가 없으면 검토 없이 즉시 닫는다. 그는 AI가 만들어낸 "쓰레기(slop)"를 검토하는 것은 자신이 거부하는 "역 센타우르 작업"이라고 말한다.

3. LLM에만 의존하는 사용자를 위한 대안

LLM 없이 독립적으로 코딩할 수 없는 사용자에게는 PR을 제출하지 말고, 자신의 목소리로 이슈에 문제만 설명하라고 권고한다. 장황한 LLM 스타일의 글(장, 불릿 포인트, 이모티콘이 포함된)이 아니라 간단하게 자신의 말로 써달라고 한다. 수정을 우선 처리받고 싶다면 기부도 고려해볼 수 있다고 제안한다.

오픈소스의 미래에 대한 우려

그린버그는 오픈소스와 코딩에 대한 일반적인 관심이 줄어든다고 느낀다. 많은 개발자들이 코딩의 "도전"을 원하지 않고, AI 레브에게 돈을 주어서 코드를 만들어주는 것을 선호한다고 생각한다. 그는 기존 프로젝트의 유지보수는 계속하지만, 새로운 개인 프로젝트를 공개적으로 발표하는 데는 덜 적극적이 되었다고 말한다.

HN 커뮤니티 반응 (261점, 208개 댓글)

저자의 입장을 지지하는 측 (약 40개 댓글)

대부분의 지지는 "PR 품질 문제가 실제 문제다"라는 공감에서 나왔다.

dllu는 유지보수자의 관점을 완전히 이해한다고 말했다. 저품질 AI 생성 PR로 인한 "리뷰 피로"는 합법적인 문제라고 봤다. 특히 완전히 자율적인 AI 에이전트가 오픈소스 프로젝트를 찾아다니며 무작위 PR을 추가하는 경우가 최악이라고 지적했다. 하지만 동시에 그는 AI를 사용해 진짜 버그를 찾은 경우(예: Wine/FEX에서 aarch64 호환성 문제, Darktable의 12초 일시정지 버그)에도 PR을 제출하기 어려워진 상황에 대해 죄책감을 표현했다.

thomasahle는 실제 사례를 들었다. 그는 System Verilog용 대규모 테스트 벤치를 구축한 뒤, 여러 오픈소스 컴파일러에서 실패한 테스트를 Claude로 원인 분석했다. 그런데 결과적으로 메인테이너에게 제출할 수 없는 패치들이 쌓인 상황에 처했다.

eranation은 "이슈 먼저" 접근법은 LLM 사용 여부와 무관하게 좋은 아이디어라고 평가했다.

저자의 입장에 반대하는 측 (약 16개 댓글)

JCattheATM은 코드의 질로 판단해야지, AI를 썼는지 여부로 거부하는 것은 어리석음이라고 말했다.

zeroonetwothree는 역으로, 자신이 직접 손으로 쓴 이슈를 오픈소스 프로젝트에 제출했는데, 프로젝트의 봇이 AI가 생성해낸 의미 없는 댓글로 자동으로 닫는 경우가 더 짜증난다고 말했다. 이런 "독한 게이트키퍼링" 행위는 이제 포크하기가 쉬워진 덕분에 예전만큼 중요하지 않아졌다고 봤다.

newAccount2025는 "빌드 vs 프롬프트"는 가이진(인위적인 이분법)이라고 비판했다. LLM을 "페이스북 클론 만들어줘"처럼 무조건적으로 쓰는 것 말고, 테스트 개발 보조, 설계 검토, 디버깅, 최적화 제안 등 훨씬 뉘앙스 있는 사용법들이 많다고 지적했다.

WhitneyLand는 PR 품질 문제는 진짜지만, 그린버그가 "LLM이 내 속도를 높여주지 않는다"는 일 년 전의 주장을 여전히 고수하는 것은 이상하다고 말했다. 에이전트와 모델이 급격히 개선되었는데 전혀 사용하지 않는 개발자는 사라져가는 종이라고 평했다.

AI 감지/공개 논쟁 (약 16개 댓글)

devrundown은 그린버그의 "저는 생성형 AI를 사용하지 않습니다"라는 선언을 옛날 웹사이트에 하던 "Website written in Notepad" 배너에 비유했다.

stantaylor는 그린버그가 "예상치 못한 PR이 오면 몇 초 안에 그 뒤에 인간이 있는지 확인한다"고 했는데, 구체적으로 어떻게 구분하는지 설명해줬으면 좋았을 것이라고 말했다.

tehjoker는 LLM으로 생성된 라이브러리와 품질 좋은 라이브러리를 구분하는 방법은 "평판"이라고 말했다. 사용 기간, 안정성, 테스트 커버리지로 판단해야 한다는 것이다.

eranation은 AGENTS.md 파일에 AI 공개 규칙을 넣으면, Claude Code나 Codex 같은 에이전트가 자동으로 에이전트 이름과 모델을 PR 설명에 표시한다는 실험 결과를 공유했다.

"비개발자의 자부심" 논쟁 (약 35개 댓글)

원문에서 그린버그가 "프로그래밍을 할 줄 모르는 친구들이 드디어 소프트웨어를 만들 수 있게 되어 자부심을 느낀다"는 부분을 둘러싼 논쟁이 가장 활발했다.

bigstrat2003은 레고 세트를 조립하는 것에 비유했다. 조립하는 것은 재미있지만, 완성된 모델에 대해 "자부심을 느꼈다"라고는 절대 말하지 않을 것이라고 했다. 도전 없이 만든 것에 대한 자부심은"pathetic"(불쌍한) 것이라고 평가했다.

mostlysimilar는 기계어보다 어셈블리, 어셈블리보다 C, C보다 Python에서 프로그램을 작성하는 것이 더 자랑스럽겠냐고 반문했다. 각 단계마다 더 많은 노력이 필요하고, 그 노력으로 얻은 기술이 진정한 성취감이라고 말했다.

반대로 unacorner는 프로그래밍 언어가 영어이고 LLM이 만들어낸 것이라 해도, 이전에 없던 것을 창조했다는 점이 중요하다고 argued.

Trasmatta는 사람들이 프롬프트를 자랑하는 것을 AI slop 아트를 자랑하는 것과 같다고 비유했다.

IggleSniggle은 붓을 쓰는 화가도 있고, 끌을 쓰는 조각가도 있지만, "bullshit artists"(속임수 화가)도 있다고 구분했다. 끌이라는 도구가 처음 등장했다고 해서 모든 끌 사용자를 속임수 화가로 보는 것은 잘못이라고 지적했다.

오픈소스의 미래 (약 37개 댓글)

emodendroket은 "오픈소스가 여전히 의미 있는가?"라는 질문에 "의미가 무엇인지에 달렸다. 의미 있는 기준으로 성공한 오픈소스 프로젝트는 극히 적었다"고 답했다.

stephenlf는 ghostty 프로젝트가 GitHub Issues보다 더 한 단계 나아가 GitHub Discussions를 사용하며, 오직 메인테이너만 이슈를 만들 수 있게 했다고 소개했다.

layer8은 기술적으로 관심 있는 사람들이 AI 없이 코드를 배우고 싶어하는 사람들이 여전히 많기를 희망한다고 말했다.

fantasizr는 그린버그의 Flask 메가 가이드를 통해 Flask를 배웠다고 하며, "코딩할 줄 아는" dilettantes(아마추어)들이 그의 시간과 집중력을 오염시키는 것을 보는 것이 안타깝다고 말했다. 미치 헤드버그의 농담을 인용했다: "누군가 전단지 건네면, '이거 버려'라고 말하는 것과 같다."

powera는 "사제들이 농민들이 이제 스스로 성경을 읽을 수 있게 된 것을 싫어하는 것과 같다"고 비판했다.

새로운 시각

"리뷰 피로"는 AI 시대 이전에도 존재했지만, AI가 가속화했다

HN 댓글에서 드러난 핵심 통찰은 "리뷰 피로"라는 개념이다. 오픈소스 메인테이너들이 낮은 품질의 기여로 인해 피로감을 느꼈던 문제는 AI 이전에도 존재했지만, AI 에이전트가 분당 수십 개의 PR을 자동 생성하면서 이 문제가 기하급수적으로 악화되었다. 그린버그의 접근법은 AI를 금지하는 것이 아니라, "이슈 먼저"라는 마찰(friction)을 추가함으로써 인간 참여를 확인하는 메커니즘을 만드는 것이다. 이는 AI 시대의 오픈소스 거버넌스에 새로운 패턴을 제시한다.

"프롬프트 엔지니어링"과 "코딩"의 경계가 흐려진 자부심 문제

비개발자가 LLM으로 소프트웨어를 만들고 느끼는 "자부심"에 대한 논쟁은 더 넓은 질문을 던진다. 도구의 추상화 수준이 높아질수록(기계어 → 어셈블리 → C → Python → 자연어 프롬프트), "실제 작업"과 "도구 사용"의 경계가 어디인가? 그린버그는 이 경계를 "코드를 직접 작성하는 것"으로 설정했지만, 많은 댓글 작성자들은 이 선이 점점 무의미해지고 있다고 본다. 핵심은 "도구를 어떻게 사용하는가"보다 "무엇을 만들고 왜 만드는가"가 될 수 있다.

오픈소스 생태계의 양극화

댓글들에서 두 가지 미래가 대비된다. 하나는 AI 에이전트가 대량의 저품질 PR을 생성하며 오픈소스를 오염시키는 시나리오이고, 다른 하나는 AI가 오픈소스 유지보수 자체를 도와주는 시나리오다. doginasuit는 "LLM으로 PR을 검토하고 필터링하게 하라"고 제안했는데, 이는 아이러니하게도 AI를 AI로 인한 문제의 해결책으로 사용하는 접근이다. 이 양극화는 오픈소스 생태계가 어떻게 진화할지에 대한 근본적인 질문을 던진다.

자녀/미래 영향

아인, 석현, 은한이 성장할 때 프로그래밍은 지금과 완전히 다른 형태가 될 가능성이 높다. LLM이 코딩의 진입 장벽을 낮추는 것은 분명하지만, 동시에 "코딩한다는 것"의 의미가 변화하고 있다.

실용적 조언:

• 아이들이 프로그래밍을 배울 때 "코드 작성이 빠르다"가 아니라 "문제를 정의하고 해결책을 설계하는 능력"에 초점을 맞추자
• LLM을 도구로 사용하는 것은 당연해지겠지만, 그 도구의 출력이 올바른지 판단하는 비판적 사고가 더 중요해질 것이다
• 오픈소스 기여에 관심이 생기면, "이슈 먼저" 원칙을 알려주자 — 코드를 먼저 제출하는 것이 아니라, 문제를 먼저 논의하는 것이 좋은 기여자다운 태도다
• "자부심"의 기준을 결과물이 아니라 과정에 두도록 가르치자. 레고를 조립하는 것과 레고로 새로운 것을 발명하는 것은 다르다

관련 노트

• [[2026-06-09_mimo-local-llm]] — 로컬 LLM과 AI 도구 사용에 대한 논의
• [[2026-06-07_flux-klein]] — AI 이미지 생성과 오픈소스