원문
72시간 동안 공개 오픈소스 레포 100개 이상에 커밋 500건을 넘게 올렸습니다. 그리고 GitHub으로부터 계정을 정지당했습니다.
4월 16일부터 18일까지 몇 달 동안 설계해 오던 harness engineering 파이프라인을 끝까지 돌려봤습니다. 대상은 google/adk-python, kubernetes/kubernetes, huggingface/transformers, ollama/ollama, vllm, awslabs/gluonts 같은 프로젝트들이었고, 그중 일부는 실제 maintainer들이 검토 후 merge해 주셨습니다.
파이프라인은 13단계로 구성했습니다:
- 각 레포의 최근 merge 20건과 release tag 5개 diff에서 fix/security 후보만 추출
- 최근 merge, CONTRIBUTING 등 문서를 읽고 프로젝트 방향성과 충돌하는 후보 탈락
- 남은 후보마다 Ouroboros 인터뷰 — 분기 여부는 에이전트가 판단하고 알아서 선택
- 이미 열려있거나 해결된 이슈/PR과 교차 확인해 중복 제거
- 로컬 포크에서 실제로 재현이 되는지 검증. 재현되지 않으면 즉각 탈락
- 프로젝트 철학상 의도된 동작(load-bearing)은 재검토해서 제외
- 이슈/PR 범위와 적정성을 최근 merge 패턴을 분석해 논의
- 해당 레포의 최근 merge 패턴을 매칭해 작성 전략 분석
- 이슈/PR 초안 작성
- 과거 PR을 few-shot으로 써서 글 다듬기
- 타당성 재검토 — 여기서부터 사람이 개입
- CLA 서명이 필요한 경우, 자동화는 체크 창 지점까지. 실제 서명은 직접 클릭
- 봇/리뷰 결과 확인 후 후속 PR·코멘트·close 중 액션 결정
가장 결정적이었던 건 5번 — 로컬 재현 gate였습니다. AI가 만든 PR이 왜 대부분 noise 취급을 받는지 생각해보면 답이 여기 있습니다. 재현을 안 해서입니다. 포크 테스트에서 실제로 살아남은 후보만 올리니 merge 비율이 압도적으로 올라갔습니다.
두 번째는 8번. 해당 레포의 최근 merge된 PR 10개를 읽는 게 CONTRIBUTING을 정독하는 것보다 훨씬 정확했습니다. 받아들여지는 PR의 사회적 형태는 거기에 더 또렷하게 박혀 있습니다.
정지 사유는 짐작이 갑니다. 72시간에 레포 100개는 개별 PR의 품질과 무관하게 abuse 탐지 입장에서는 spam과 구별하기 어렵습니다. 속도 자체가 의미론적 신호입니다.
이번 결과의 진짜 흥미로운 지점은 이 파이프라인의 존재가 “유지보수 노동에 대해 무엇을 시사하는가”입니다.
버그 픽스, 리팩토링, 초안 패치는 이제 스케일됩니다. 한 명의 운영자가 한 주말에 서로 다른 코드베이스에서 실재하는 문제를 찾아냅니다. 공급 곡선이 예전과는 확실히 다릅니다.
남는 희소 자원은 “인증(attestation)“입니다. CLA 서명, merge 권한, 리뷰 승인 — 이 지점들이 병목처럼 보이지만, 사실은 나머지 시스템을 신뢰 가능하게 만들어주는 장치입니다.
사람은 feat 설계 쪽으로 올라갑니다. fix/security를 하네스가 처리할 수 있다면, 인간이 남는 자리는 설계와 방향입니다.
3개 레포에서 똑똑했던 파이프라인이 100개에서는 abusive가 됩니다. 개별 출력이 동일해도 말입니다. 플랫폼은 평균 품질이 아니라 속도에 반응합니다.
진짜로 돌아가는 하네스 엔지니어링은 시스템이 태도를 정하지 않을 수 없는 출력물을 만들어냅니다. 그래야 뭔가 실제로 만들어지고 있다는 뜻이니까요.
내 생각
여기에 쓰면 됩니다.