229개 파일 중 228개가 같았다: Google이 남의 오픈소스에서 저자 이름을 지웠다

Minitap 대표 Nicolas Dehandschoewercker가 9월 11일 글을 올렸다. Google이 낸 Android 자동화 프로젝트 Artemis를 열어 봤더니 자기 팀이 2월까지 만든 오픈소스 mobile-use 코드였다. Android 기기 연결 부분의 구현이 그대로 일치했고 Hopper 에이전트의 지시문은 단어 단위로 같았다. WhatsApp 예제는 Alice·Bob·Charlie에게 새해 인사를 보내는 같은 과제에 같은 주석과 정리 단계까지 붙어 있었다. 옛 버전에는 버그도 함께 있었다. 결과 파일을 쓰고 다음 실행에서 자기 출력을 읽다가 실패하는 동작이 양쪽에서 똑같이 재현됐다.

Hopper라는 이름의 유래가 이 대조를 가장 잘 보여 준다. 엔지니어 한 명이 마인크래프트를 좋아해서 골랐다. 그 이름이 같은 지시문과 함께 Google 리포에 있었다.

한 줄 정리

Apache 2.0은 재배포를 허락하면서 저작권·귀속 표시를 남기라고 요구하는데 Google은 공개로 지적받은 뒤에야 그 줄을 넣었다.

한눈에 보기

항목	확인된 내용
일치한 파일	229개 중 228개
초기 `pyproject.toml`	mobile-use 버전 3.6.3 + 원저자 3명, Google LLC 저작권 헤더 아래
교체 커밋	저자 3명을 다른 저자 1명으로 치환. 다른 변경 없음
시점	8월 force push, Minitap 조사는 9월
수정 규모	커밋 371aa6d, 23개 파일 69줄 추가

라이선스는 허락과 조건을 같이 준다

mobile-use는 Apache 2.0이다. 재배포와 파생 작업을 넓게 허락한다. 4조에 조건이 붙는다. 적용되는 저작권·귀속 표시를 남기고, 변경한 사실을 표시하고, 배포물에 NOTICE 파일이 포함되면 그 안의 귀속을 유지한다.

Minitap이 요구한 것도 그 수준이다. README에 mobile-use를 출처로 적고, 원저자와 기여자를 표시하고, 코드가 들어간 자리에 상류 저작권 표시를 복원하는 것. GitHub 이슈 #40에 체크박스 세 개로 올렸다.

이런 일을 하는 통상 경로는 이미 다 있다. 포크는 원본으로 링크가 걸린다. 가져온 사본은 출처를 문서에 적을 수 있다. README 한 단락으로 어디까지가 남의 것이고 어디부터가 내 작업인지 구분할 수 있다. Google은 이 절차에 관한 사내 공개 가이드를 자체 사이트에 두고 있다. Chrome을 낼 때는 WebKit과 Firefox를 명시하며 "많은 오픈소스 프로젝트에 큰 빚을 졌다"고 썼다.

결말은 커밋 하나다. 제목이 fix: complete README and relevant file headers per Apache 2.0 requirements. 23개 파일에 69줄이 추가됐다. README 맨 끝에 Minitap이 개발한 소스 코드를 포함한다는 한 줄, 코드 파일마다 파생 사실과 저작권을 적는 세 줄. 처음부터 넣을 수 있었던 분량이다.

흔적이 남는 자리와 안 남는 자리

이 사건이 확인 가능한 형태로 남은 이유는 Git 때문이다. 저자 목록을 바꾼 커밋은 main 브랜치에서 밀려났지만 GitHub 활동 기록의 force push 항목에 남았고, 옛 커밋 해시로 파일을 여전히 열 수 있다. Minitap은 코드 대조와 타임라인을 별도 공개 문서로 정리해 붙였다.

반대로 흔적이 약한 쪽도 있다. 모델 프롬프트와 문서는 파일 단위 비교가 되지만 학습 데이터나 내부 참고 자료로 흘러간 경우에는 같은 방식으로 확인할 수 없다. 이번에 비교가 성립한 건 지시문이 마크다운 파일로 리포에 있었기 때문이다. 에이전트 시대의 자산 상당수가 프롬프트와 워크플로 문서 형태라는 점을 생각하면, 그게 코드로 저장돼 버전 관리 안에 있는 편이 유리하다.

한편 리포 자체는 빠르게 커지고 있다. 이슈가 올라온 9월 11일 시점에 별 2.3천 개, 포크 202개였고 이틀 만에 별 3.3천 개, 포크 284개가 됐다. 귀속 한 줄이 늦어지는 동안 배포량은 계속 늘어난다.

벤치마크 쪽도 같이 막혀 있었다

코드 문제와 별개로 Minitap은 AndroidWorld 리더보드에 몇 달째 매달려 있었다. 관리자가 반영해 준 마지막 수치는 91.4%이고 확인 시점은 2025년 12월이다. 이후 94.8%를 냈고 1월 자체 평가에서 100%를 냈다. 후속 메일 두 통까지 합쳐 네 통이 답을 받지 못했다.

9월 11일 기준 시트에는 mobile-use가 여전히 91.4%로, Artemis가 99.1%로 올라 있었다. 둘 다 자기 신고 수치이고 리더보드는 독립 검증을 하지 않는다고 명시한다. Artemis가 문서에 넣은 비교 차트는 mobile-use를 빼고, 같은 91.4%로 적힌 DroidRun과 이름만 비슷한 다른 프로젝트를 넣었다.

귀속 누락과 메일 무응답이 연결됐다는 증거는 없다. Minitap도 그렇게 적었다. 다만 두 일이 같은 곳을 가리킨다. 공개 기록에 자기 작업이 남는 일이 어렵다.

위시클레이 관점

Minitap의 마지막 문장이 이 사건의 성격을 정한다. 지금 제품을 돌리는 버전은 클로즈드 소스이고 2월 코드와 다른 물건이다. Google이 가져간 건 7개월 전에 멈춰 둔 실험이다. 그래서 뺏긴 것은 코드가 아니라 이름이다.

작은 팀이 코드를 공개하는 이유는 대개 배포다. 별 3.3천 개가 붙은 리포에 누가 만들었는지 안 적혀 있으면 그 배포는 남의 것이 된다. 69줄을 받아 내는 데 대표가 직접 쓴 7분짜리 글과 공개 이슈와 매체 보도가 필요했다. 같은 상황에서 그만큼 목소리를 낼 수 없는 팀이 훨씬 많다.

리더보드 쪽이 더 실용적인 교훈이다. 100%를 측정해 제출했는데 공개 기록은 91.4%로 남았다. 만드는 일과 만든 것이 기록에 남게 하는 일은 다른 작업이고 후자를 아무도 대신 해 주지 않는다. 무료 공개 자료를 배포 수단으로 쓰는 팀이라면 README의 출처 표기, 배포물의 NOTICE 파일, 벤치마크 제출 이력의 스크린샷이 마케팅 자산과 같은 급이다. 분쟁이 생긴 날 근거가 되는 건 그 파일들이다.

별 3.3천 개 중 우리 이름은 69줄.