Google Artemis 코드 분쟁: Minitap, 모바일 사용 크레딧이 삭제됐다고 주장

Google은 Minitap이 Google의 새로 공개된 Android 자동화 프로젝트 Artemis 내부에서 복제된 것으로 추정되는 코드와 프롬프트를 발견한 뒤 오픈소스 출처 표기 분쟁에 직면했다.

Google Artemis 코드 분쟁은 두 모바일 에이전트 간의 유사한 아이디어를 넘어선 문제다. Minitap은 Artemis에 동일한 구현 세부 사항이 눈에 띄는 출처 표기 없이 등장했다고 주장한다. 또한 개발자들이 저자로 표시됐다가 해당 이름들이 사라진 것으로 보이는 저장소 이력도 제시했다.

이 이력이 분쟁의 핵심을 이룬다. Minitap은 Apache License 2.0에 따라 mobile-use를 공개했으며, 정해진 조건 아래 수정과 상업적 재사용을 허용한다. 이 스타트업은 Google이 경쟁 도구를 만든 것 자체가 아니라, 명확한 출처 정보 없이 이뤄진 것으로 보이는 재사용에 이의를 제기한다.

공개 기록은 이미 바뀌었다. 9월 13일 기준 Artemis README에는 이 프로젝트가 Minitap이 개발한 소스 코드를 포함한다고 명시돼 있다. 이 인정 문구는 Minitap이 9월 11일 게시물에서 설명한 버전에는 없었다.

Google의 현재 크레딧은 가장 눈에 띄는 불만을 해소하지만, 모든 의문에 답하지는 않는다. 남은 쟁점은 어떤 구성 요소가 업스트림에서 비롯됐는지, 출처 표기가 언제 사라졌는지, 적용되는 모든 라이선스 조건이 준수됐는지에 관한 것이다.

Minitap이 Google Artemis 내부에서 발견한 내용

Minitap의 가장 강력한 증거는 단일한 공통 아키텍처 아이디어가 아니라, 일치하는 코드와 프롬프트, 그리고 이전 저자 목록의 조합이다.

Artemis와 mobile-use는 모두 AI 에이전트가 자연어 지시를 통해 휴대폰을 조작하도록 한다. 많은 모바일 에이전트가 스크린샷, 접근성 데이터, 계획 루프, 기기 제어 도구를 사용하므로 이러한 광범위한 유사성만으로는 큰 의미를 갖기 어렵다.

Minitap의 주장은 구현 수준에서 더 구체적이 된다. Minitap의 공개 설명은 mobile-use에서 이전에 공개된 코드와 일치한다고 주장하는 Android 연결 로직을 지목한다.

이 회사는 Hopper라는 에이전트도 강조한다. Minitap 시스템에서 Hopper는 현재 작업과 관련된 정보를 찾기 위해 대량의 화면 및 상호작용 이력을 검색한다.

Minitap은 Artemis에 동일한 Hopper 프롬프트가 포함됐으며, 문구와 예시도 일치한다고 주장한다. 상세한 지시문은 에이전트 시스템 안에서 소스 코드처럼 기능할 수 있으므로 프롬프트의 동일성은 중요하다.

“이력을 검색하라”와 같은 일반적인 지시는 독립적으로도 나올 수 있다. 그러나 구조, 예시, 이름, 주석, 정리 동작이 동일한 확장 프롬프트는 우연의 일치라고 보기 더 어렵다.

이 회사는 메시징 예시도 지적한다. 두 프로젝트가 동일한 예시 이름, 주석, 작업 순서를 사용했다고 말한다.

예시는 기능상 요구되지 않는 임의의 선택을 보존할 때 출처를 드러낼 수 있다. 두 구현이 Android Debug Bridge, 흔히 ADB로 알려진 도구에 독립적으로 연결할 수는 있다. 그러나 더 긴 예시 전반에서 동일한 가상 세부 사항을 독립적으로 선택할 가능성은 낮다.

Minitap은 두 프로젝트가 파일 처리 버그도 공유했다고 추가로 주장한다. 게시물에 따르면 Artemis는 이후 해당 동작을 수정했다.

공유된 결함은 개발자가 의도한 동작이 아니라 우발적인 실패 모드를 복제하는 경우는 대체로 없기 때문에 의미 있는 증거가 될 수 있다. 다만 완전하고 버전별로 구분된 비교 없이는 독자가 이 단서를 최종적인 기술적 판단으로 받아들일 수는 없다.

가장 중요한 증거는 패키지 메타데이터와 관련된다. Minitap은 이전 Artemis 패키지 파일에 Pierre-Louis Favreau, Jean-Pierre Lo, Nicolas Dehandschoewercker가 저자로 기재돼 있었다고 주장한다.

이 이름들은 Minitap의 mobile-use 작업과 관련된 기여자들에 해당한다. Minitap은 이후 개정본이 관련 파일을 그 외에는 변경하지 않은 채 이들을 다른 저자로 교체했다고 말한다.

이 회사는 이 교체를 8월의 강제 푸시와 연결한다. 강제 푸시는 Git 브랜치의 보이는 이력을 다시 작성해, 모든 기본 객체나 외부 사본을 즉시 지우지 않고도 브랜치에서 커밋을 제거할 수 있다.

이 구분은 중요하다. 저장소 정리 과정에서 강제 푸시는 일상적인 작업이지만, 다시 작성된 커밋에 이후 분쟁과 관련된 출처 정보가 포함돼 있었다면 중요한 의미를 갖는다.

Minitap은 해당 커밋이 기본 브랜치에 더 이상 연결돼 있지 않았음에도 Git 이력을 통해 이전 개정본을 복구했다고 말한다. 따라서 이 주장은 현재 파일뿐 아니라 과거 저장소 증거에도 일부 기반한다.

법원, 규제기관, 독립 코드 감사 기관 중 어느 곳도 이러한 주장에 대해 판결하거나 판단을 내리지 않았다. 현재 이용 가능한 증거는 면밀한 검토를 뒷받침하지만, 이 고발은 여전히 Minitap이 문서화한 주장이다.

Google은 이 기사를 위해 검토된 자료에서 저자 정보 교체에 관해 공개적으로 설명하지 않았다. 또한 mobile-use에서 파생된 Artemis 구성 요소를 파일별로 설명하는 자료도 제공하지 않았다.

이 설명의 부재는 완전한 재구성을 어렵게 한다. 그렇다고 Minitap이 설명한 가시적인 유사성 주장이나 이전 메타데이터가 사라지는 것은 아니다.

그럼에도 즉각적인 변화는 분명하다. 작은 오픈소스 팀이 Google 저장소에 공개적으로 이의를 제기했고, 현재 Google의 README는 이제 Minitap이 개발한 코드를 인정한다.

Google Artemis 코드 분쟁이 중요한 이유

Google에 압력이 가해지는 이유는 이 회사의 제도적 신뢰성이 깨끗한 출처 관리를 덜 중요하게 만드는 것이 아니라 더욱 중요하게 만들기 때문이다.

오픈소스 개발은 허가와 출처 표기가 서로 다른 기능을 수행하는 데 기반한다. 관대한 라이선스는 다운스트림 개발자에게 폭넓은 자유를 부여하는 반면, 출처 기록은 기반 작업을 누가 만들었는지 보여 준다.

Minitap은 재사용을 환영한다고 명시적으로 말한다. 이 회사의 이의는 개발자가 일부 코드가 mobile-use에서 왔다는 사실을 알지 못한 채, 겉보기에는 독립적인 Google 프로젝트를 마주해서는 안 된다는 것이다.

이 우려는 인정 문제를 넘어선다. 출처 정보는 유지관리자가 보안 결함, 아키텍처 결정, 업스트림 수정, 호환되지 않는 변경 사항을 추적하는 데 도움을 준다.

다운스트림 사용자가 구성 요소의 출처를 식별하지 못하면 잘못된 팀에 버그를 보고할 수 있다. 업스트림 프로젝트에서 이미 제공되는 수정 사항을 놓칠 수도 있다.

Artemis를 평가하는 개발자는 어떤 부분을 Google이 독립적으로 유지관리하는지 알아야 한다. 또한 상속된 동작이 어디에서 시작되고 Google의 수정이 어디서 갈라지는지도 알아야 한다.

이 정보는 기술적 실사에 영향을 미친다. 기기 테스트용 에이전트를 도입하는 팀은 유지관리 책임, 종속성, 라이선스, 벤치마크 주장의 신뢰성을 평가해야 한다.

Google이라는 이름은 이 회사가 광범위한 오픈소스 가이드를 공개하기 때문에 기대치를 높인다. Google 문서는 코드가 공개되기 전에 배포 검토에서 라이선스 헤더와 기타 필수 자료를 확인해야 한다고 설명한다.

Google은 Android, Chromium, TensorFlow, Kubernetes 등 널리 쓰이는 여러 프로젝트도 유지한다. 이 회사의 팀은 외부 기여자와 기업에 체계적인 라이선스 절차를 따를 것을 일상적으로 요청한다.

따라서 Google 조직 안에서의 출처 관리 누락은 상징적 무게를 지닌다. 독립 유지관리자들은 가장 큰 소프트웨어 기업이 다른 곳에서 요구하는 행동을 스스로 보여 주기를 기대한다.

당사자 간 불균형은 이러한 압력을 더 키운다. 스타트업은 유용한 연구와 코드를 공개할 수 있지만, 더 큰 조직은 유사한 시스템을 공개한 뒤 더 많은 관심을 끌 수 있다.

검색 결과, 소셜 배포, 브랜드 인지도는 접근 방식을 빠르게 더 큰 발행자와 연결할 수 있다. 코드가 계속 제공되더라도 출처 표기가 빠지면 작은 팀의 기여가 가려질 수 있다.

이것이 이 이야기의 핵심적인 역전이다. 오픈소스는 Google이 공유 작업을 바탕으로 구축할 수 있도록 허가했지만, 같은 개방성은 Minitap의 불만을 뒷받침하는 증거도 드러냈다.

공개 Git 저장소는 diff, 포크, 캐시된 페이지, 패키지 파일, 분리된 커밋을 보존한다. 브랜치를 다시 작성한다고 해서 이전 저자 기록이 모든 사본에서 사라진다고 보장할 수는 없다.

이 논란은 Minitap을 넘어 다른 기여자들에게도 영향을 미친다. 개발자는 다운스트림 조직이 출처와 크레딧을 어떻게 대하는지 관찰하며 가치 있는 작업을 공개할지 결정한다.

관대한 라이선스는 상업적 제한을 덜 부과하므로 채택을 장려한다. 이 모델은 사용자가 남아 있는 제한적 조건을 존중하고 출처를 정직하게 전달할 때 지속 가능하다.

작은 팀이 관대한 라이선스로 공개한 결과물이 인정 없이 흡수될 것이라 믿게 된다면, 공개를 미룰 수 있다. 다른 팀은 더 강한 카피레프트 조건을 선택하거나 전략적으로 중요한 구성 요소를 비공개로 유지할 수도 있다.

어느 대응도 자동으로 사용자에게 이롭지는 않다. 모바일 자동화는 연구자가 에이전트를 검토하고, 결과를 재현하며, 전략을 비교하고, 조직 경계를 넘어 수정 사항에 기여할 수 있을 때 발전한다.

교훈은 기업이 오픈소스 코드 사용을 피해야 한다는 것이 아니다. 코드가 정제된 기업 저장소에 들어가기 전에 내부 배포 절차가 업스트림 이력을 보존해야 한다는 점이다.

이 절차에는 소스 목록, 자동화된 유사성 검사, 종속성 기록, 라이선스 검토, 사람에 의한 검증이 포함돼야 한다. 검색 가능한 엔지니어링 지식 베이스도 출처 정보를 설계 결정과 연결해 둘 수 있다.

저장소 유지관리자는 출시 전에 복사한 파일과 실질적인 개작 내용을 문서화해야 한다. 분쟁 후 출처를 추가하는 것은 계속 누락된 채로 두는 것보다 낫지만, 명확한 개발 기록을 대체할 수는 없다.

따라서 Google은 새 문구를 단지 유지하는 데 그치지 않고 그 순서를 설명해야 한다는 압박을 받는다. 이 조직은 누락이 고립된 배포 오류였는지, 아니면 더 취약한 출처 관리 절차의 증거였는지 보여줘야 한다.

현재의 크레딧은 이야기를 바꾸지만, 이력을 바꾸지는 않는다

Google의 현재 README는 Minitap을 인정하며, 논란을 미해결된 누락 문제에서 출처 표기가 어떻게, 왜 사라졌는지에 관한 분쟁으로 전환한다.

현재 Artemis 저장소는 Google의 Pixel Test Engineering Fusion 팀이 구축한 Android 자동화 시스템을 설명한다. AI 코딩 어시스턴트를 위한 두 가지 실행 프로필과 통합 기능을 제시한다.

Flash 모드는 반응형 관찰-실행 루프를 사용한다. Artemis는 이전 상호작용 이력을 압축하면서 단계당 일반적으로 3~5초가 걸린다고 설명한다.

Pro 모드는 계획 및 검증 구성 요소를 사용한다. 실행 전에 제안된 작업을 현재 인터페이스 데이터와 대조하며, 더 긴 테스트 워크플로를 지원한다.

저장소는 Model Context Protocol 통합도 설명한다. MCP는 호환되는 AI 어시스턴트가 외부 도구를 호출하고 구조화된 결과를 받을 수 있도록 하는 표준 인터페이스다.

이 기능들은 Artemis가 반드시 mobile-use의 변경 없는 복사본은 아니라는 점을 보여 준다. 다운스트림 프로젝트는 상속된 구성 요소를 실질적인 독자 엔지니어링과 결합할 수 있다.

이 점은 Minitap의 불만과 모순되지 않는다. 파생 시스템이 새로운 인터페이스, 안전 검사, 실행 모드, 진단 기능을 추가하더라도 복사된 부분에는 출처 표기 문제가 적용된다.

현재 README에는 이제 라이선스 섹션 아래에 이 프로젝트가 Minitap이 개발한 소스 코드를 포함한다는 직접적인 문구가 들어 있다. 해당 문구는 mobile-use 저장소로 연결된다.

이는 의미 있는 수정이다. 오늘 이 프로젝트를 접하는 개발자는 포렌식 검색을 하지 않고도 Minitap을 업스트림 소스로 식별할 수 있다.

하지만 이 문구는 여전히 포괄적이다. mobile-use에서 비롯된 파일, 프롬프트, 에이전트 또는 아키텍처 구성 요소를 식별하지는 않는다.

이전 저자 메타데이터에 대해서도 설명하지 않는다. Minitap의 복원이 정확하다면, 세 명의 실명 기여자가 패키지 구성에 표시됐다가 이후 교체됐다.

프로젝트 차원의 공로 표기와 개인 저자성은 관련돼 있지만 서로 다르다. 회사 차원의 인정은 원본 조직을 식별할 수 있지만, 특정 개발자들의 기여 이력은 불분명하게 남길 수 있다.

상세한 답변은 불확실성의 상당 부분을 해소할 수 있다. Google은 관련 커밋 순서를 공개하고, force push를 설명하며, 상속된 구성 요소를 원래 리비전에 매핑할 수 있다.

또한 저자 변경이 실수였는지, 리포지터리 마이그레이션의 일부였는지, 혹은 의도적인 메타데이터 정규화였는지도 밝힐 수 있다. 그런 설명이 없다면 외부인은 불완전한 이력으로 의도를 추론해야 한다.

의도는 대중의 신뢰에 중요하지만, 라이선스 준수 여부는 대체로 구체적인 배포 관행에 달려 있다. 부주의한 누락과 의도적인 삭제는 유사한 파일을 만들어낼 수 있지만, 서로 다른 조직적 실패를 의미한다.

이번 정정은 Google이 현재 아무런 공로도 표기하지 않는다는 단순한 헤드라인도 복잡하게 만든다. 그런 설명은 9월 13일 기준으로 이미 최신 정보가 아닌 것으로 보인다.

정확한 틀은 시간 순서다. Minitap은 유사성을 문서화했을 당시 Artemis에 인정 표기가 없었다고 말하며, 현재 라이브 리포지터리는 이제 Minitap이 개발한 소스 코드에 공로를 표기하고 있다.

독자는 Google과 Google이 호스팅하는 리포지터리의 모든 기여자를 구분해서 봐야 한다. 공개 리포지터리에는 서로 다른 검토 절차를 거치는 팀, 계약자, 이전된 프로젝트, 개인 유지관리자가 포함될 수 있다.

리포지터리는 Google 팀을 식별하고 있으므로, 해당 기업을 검토 대상으로 삼는 것은 적절하다. 다만 여기서 검토한 증거만으로는 이전 이름의 표기나 삭제를 누가 승인했는지 확정할 수 없다.

이 불확실성 때문에 Google Artemis 코드 분쟁은 기록과 절차에 초점을 맞춰야 한다. 개인적 동기에 대한 추측은 검증을 개선하지 못한 채 논란만 키운다.

현재의 인정 표기는 Minitap의 주장 중 한 부분을 강화한다. Google의 리포지터리는 이제 Minitap 코드가 존재한다는 점을 명시적으로 인정한다.

하지만 이는 원래 게시물에서 설명된 모든 일치 사례를 독립적으로 검증하지는 않는다. 이전 README가 특정 라이선스 조항을 위반했다는 점도 입증하지 않는다.

그것이 입증하는 것은 출처 관계다. Artemis는 오늘날 Minitap 소스 없이 전적으로 개발된 코드베이스로 제시되지 않는다.

이 변경은 신규 사용자들의 즉각적인 혼란을 줄인다. 또한 유지관리자에게 두 시스템을 비교하고 향후 수정 사항을 업스트림에서 추적할 출발점을 제공한다.

Apache 2.0은 재사용을 허용하지만, 조건은 여전히 적용된다

Apache 2.0은 요청되는 모든 형태의 인정을 요구하지 않으면서도 광범위한 재사용을 허용하므로, 법적 쟁점은 윤리적 분쟁보다 더 좁다.

두 프로젝트 모두 Apache License 2.0에 따라 코드를 공개한다. 이 라이선스는 사용자가 적용 대상 저작물을 복제, 수정, 배포, 재라이선스하고 상업적으로 사용할 수 있도록 허용한다.

이러한 권한은 경쟁사 간에도 오픈소스 협업을 가능하게 한다. Minitap은 mobile-use를 공개한 것이 Google의 이를 바탕으로 한 개발을 막았다고 합리적으로 주장할 수 없다.

Minitap도 그런 주장을 하지는 않는다. 해당 게시물은 팀이 프로젝트와 기여자에 대한 인정을 기대했다고 말한다.

Apache 2.0 terms은 당사자가 저작물이나 2차 저작물을 배포할 때 여러 조건을 부과한다. 수령자는 라이선스 사본을 받아야 한다.

수정된 파일에는 변경이 이뤄졌음을 설명하는 눈에 띄는 고지가 포함돼야 한다. 소스 배포물은 원본 소스의 관련 저작권, 특허, 상표 및 공로 표기 고지를 유지해야 한다.

원본 배포물에 NOTICE 파일이 포함됐다면, 그 안의 해당 고지는 적절한 위치에서 읽을 수 있도록 남아 있어야 한다. 라이선스는 다운스트림 저자가 자체 고지를 추가하는 것도 허용한다.

이 규칙이 특정 README 문구를 보편적으로 요구하는 것은 아니다. 이전 Artemis 리포지터리가 라이선스를 위반했는지는 정확한 업스트림 고지, 복사된 파일, 수정 사항 및 배포 방식에 달려 있다.

예를 들어 패키지 메타데이터의 저자 목록은 출처를 보여주는 관련 증거가 될 수 있다. 그 법적 지위는 라이선스가 2차 소스 배포물에 유지를 요구하는 고지에 해당하는지에 달려 있다.

마찬가지로 이름을 삭제했다고 해서 모든 맥락에서 자동으로 불법이 되는 것은 아니다. 유지관리자는 때때로 “authors” 필드가 모든 업스트림 기여자가 아니라 현재 패키지 소유권을 설명한다는 이유로 패키지 메타데이터를 변경한다.

주변 사실이 그러한 설명과 부합하는지를 결정한다. Minitap은 비교한 리비전에서 저자 목록이 유일한 실질적 변경 사항이었다고 전해진다는 점을 강조한다.

Apache 지침은 업스트림 NOTICE 파일에 포함된 공로 표기 고지가 다운스트림 배포물에서 특별히 취급된다고 설명한다. 현재 공개된 mobile-use 리포지터리의 루트 목록에는 최상위 NOTICE 파일이 눈에 띄게 표시되지 않는다.

그 부재만으로 분쟁이 해결되지는 않는다. 관련 고지는 소스 파일이나 기타 적용 대상 자료 안에도 있을 수 있으며, 수정 파일 공개 의무는 별도의 요건으로 남는다.

라이선스 준수와 커뮤니티 규범의 차이는 중요하다. 행위가 최소한의 법적 문구를 충족하면서도 유지관리자에게 오해를 유발하거나 무례하게 보일 수 있다.

반대로 프로젝트 차원의 감사 표기가 없다는 사실만으로 라이선스 위반이 입증되지는 않는다. 법적 결론을 내리려면 관련된 정확한 버전에 대한 적격 검토가 필요하다.

현재 확보된 기록은 이 상황을 공로 표기 논란으로 설명하는 것을 뒷받침한다. Google이 저작권 침해를 저질렀거나 코드를 훔쳤다는 점을 확정된 사실로 선언하는 것은 뒷받침하지 않는다.

업스트림 프로젝트가 광범위한 재사용 권리를 부여한 상황에서 “훔쳤다”는 표현은 특히 부정확하다. 실제 주장은 Google이 충분한 공로와 출처를 보존하지 않은 채 그 권리를 사용했다는 것이다.

그 주장은 여전히 심각하다. 관대한 라이선스는 제약을 줄이지만, 저자성을 지우거나 원래의 엔지니어링 작업을 주인 없는 것으로 만들지는 않는다.

Artemis를 채택하는 개발자는 프로젝트의 현재 라이선스와 Minitap 인정 표기를 보존해야 한다. 수정 버전을 재배포하기 전에는 포함된 고지도 검토해야 한다.

조직은 프롬프트와 예시를 출처 정보가 담긴 자산으로 취급해 유사한 분쟁을 피할 수 있다. 에이전트 프롬프트에는 기존 코드만큼 직접적으로 시스템의 동작을 형성하는 상세한 절차가 점점 더 많이 담긴다.

따라서 릴리스 감사는 의존성 매니페스트 이상을 비교해야 한다. 구성, 테스트 픽스처, 프롬프트 템플릿, 문서 예시, 벤치마크 스크립트 및 패키지 메타데이터를 살펴봐야 한다.

법무팀만 그 부담을 져서는 안 된다. 구현에 가장 가까운 엔지니어는 어떤 구성 요소가 실험, 내부 프로토타입 또는 외부 리포지터리에서 왔는지 아는 경우가 많다.

가장 좋은 절차는 코드가 프로젝트에 들어올 때 출처를 기록하는 것이다. 공개 전에 이를 재구성하는 일은 더 어렵고, 공개적인 비난 이후에 재구성하는 일은 더욱 어렵다.

벤치마크 주장은 별도의 마찰 요인을 더한다

벤치마크 관련 이견은 복제를 입증하지도, 누락된 출처 표기를 정당화하지도 않으므로 공로 표기 증거는 그 자체로 평가받아야 한다.

Artemis는 AndroidWorld에서 99%를 넘는 작업 완료율을 달성했다고 말한다. benchmark project는 여러 애플리케이션을 포함하는 100개 이상의 Android 작업에서 에이전트를 평가한다.

AndroidWorld는 에이전트가 현실적인 기기 작업을 완료할 수 있는지 시험할 수 있는 재현 가능한 환경을 제공한다. 작업에는 설정 변경, 앱 콘텐츠 관리, 여러 단계의 인터페이스 탐색 등이 포함될 수 있다.

벤치마크 점수는 사용자를 끌어들이고 기술적 신뢰성을 확립할 수 있다. 두 관련 시스템이 근접하게 경쟁하는 결과를 보고할 때는 공로 표기 분쟁을 증폭시킬 수도 있다.

Minitap은 공개 리더보드에 이전에 mobile-use 91.4%, Artemis 99.1%가 표시됐다고 말한다. 이후 mobile-use 제출 결과가 94.8%, 그리고 100%로 보고됐다고도 말한다.

이 수치는 Minitap의 설명에서 나온 것이며, 벤치마크 유지관리자가 독립적으로 검증하지 않는 한 자체 보고된 수치로 취급해야 한다. Minitap도 그 한계를 인정한다.

회사는 mobile-use 결과 업데이트와 관련해 리더보드 유지관리자에게 연락했다고 말한다. 또한 논란이 일기 전까지 그러한 시도로는 요청한 업데이트가 이뤄지지 않았다고 말한다.

리더보드 업데이트 지연을 리포지터리 공로 표기 문제와 연결하는 검증된 증거는 없다. 관련 조직과 기술이 연관돼 있지만, 시간적 근접성이 공조를 입증하지는 않는다.

이 구분은 필수적이다. 코드 증거는 파일과 이력을 통해 비교할 수 있는 반면, 벤치마크 문제에는 평가 버전, 제출 시점, 작업 구성 및 검토 절차가 관련된다.

서로 다른 점수는 정당한 이유로 발생할 수 있다. 에이전트가 다른 모델, 다른 프롬프트, 업데이트된 도구, 변경된 재시도 규칙 또는 더 새로운 벤치마크 환경을 사용할 수 있다.

보고된 백분율도 방법론 없이는 거의 알려주는 것이 없다. 독자에게는 테스트한 커밋, 모델 구성, 작업 하위 집합, 시행 횟수, 실패 정책 및 평가 날짜가 필요하다.

Artemis는 현재 자신의 결과를 99% 이상으로 요약한다. README는 헤드라인 주장만으로 해당 수치를 독립적으로 재현하는 데 필요한 모든 세부 사항을 제공하지 않는다.

Mobile-use 역시 강력한 성능 주장을 내세운다. 해당 open-source repository는 AndroidWorld를 100% 완료한 최초의 에이전트 프레임워크가 됐다고 말한다.

어느 쪽의 주장도 독립적으로 검토된 결과를 대체해서는 안 된다. 이 주의는 Google과 Minitap 모두에게 똑같이 적용된다.

프로젝트가 구성 요소를 공유할수록 벤치마크 투명성은 더 중요하다. 한 시스템이 다른 시스템의 상당한 코드를 상속했다면, 평가자는 보고된 차이를 만든 개선 사항이 무엇인지 알아야 한다.

더 높은 점수는 새로운 안전성 검사나 실행 스케줄링에서 비롯될 수 있다. 수정된 프롬프트, 다른 모델, 반복 시도 또는 업스트림에서 상속된 변경 사항을 반영한 결과일 수도 있다.

정확한 구성이 없다면 관찰자는 성능 격차의 원인을 귀속할 수 없다. 리더보드 순위를 누가 더 나은 기반 시스템을 만들었는지에 대한 판결로 바꾸는 일은 피해야 한다.

이 분쟁은 여전히 Google의 기술적 서사에 압박을 가한다. Artemis는 신뢰성을 핵심 특징으로 제시하므로, 투명한 계보는 사용자가 상속된 기반과 Google의 추가 사항을 구분하는 데 도움이 될 것이다.

Minitap에도 관련된 부담이 있다. 복제 주장은 스크린샷이나 서술적 요약보다 지속 가능한 diff, 해시 및 재현 가능한 비교로 뒷받침될 때 가장 강력하다.

구조화된 비교를 공개하면 독립 개발자가 주장된 모든 일치 항목을 검토할 수 있다. 또한 Artemis 팀에 공로를 돌려야 할 의미 있는 차이도 드러날 것이다.

균형 잡힌 감사는 두 프로젝트 모두를 개선할 수 있다. 업스트림 유지관리자는 유용한 변경 사항을 파악할 수 있고, Artemis 사용자는 중요한 구성 요소의 출처를 추적할 수 있다.

기업 구매자에게 실질적인 교훈은 간단하다. 벤치마크 점수와 기업 브랜딩은 리포지터리 실사를 대체하지 못한다.

팀은 테스트된 커밋을 고정하고, 라이선스 자료를 보관하며, 모델 설정을 기록하고, 자체 기기에서 중요한 워크플로를 재현해야 한다. 모바일 에이전트는 변화하는 인터페이스와 상호작용하므로 어제의 백분율이 내일의 신뢰성을 보장할 수는 없다.

개발자가 다음으로 주시해야 할 사항

Google Artemis 코드 분쟁이 정정된 실수로 끝날지, 더 깊은 거버넌스 문제로 번질지는 세 가지 신호가 결정할 것이다.

첫 번째 신호는 Google 또는 Artemis 유지관리자의 상세한 답변이다. 현재의 Minitap 인정 표기는 유용하지만, 타임라인이 있어야 핵심적인 역사적 질문에 답할 수 있다.

그 답변은 어떤 파일 또는 구성 요소가 mobile-use에서 비롯되었는지 밝혀야 한다. 또한 Minitap이 설명한 작성자 필드 교체와 8월의 이력 재작성도 해명해야 한다.

명확한 설명은 감독 필요성에 대한 해석을 뒷받침할 것이다. 계속된 침묵은 저장소에서 발견된 가장 이례적인 증거를 설명하지 못한 채 남길 것이다.

두 번째 신호는 지속적인 출처 정보 업데이트다. NOTICE 파일, 파일별 헤더, 커밋 복원, 서드파티 코드 인벤토리 또는 개별 기여자에 대한 확대된 인정 여부를 지켜봐야 한다.

모든 조치가 모든 저장소에서 법적으로 요구되는 것은 아니다. 그러나 정확한 소스 맵은 하위 사용자들이 각자의 재배포 의무를 준수하는 데 도움이 될 것이다.

이는 향후 유지보수도 더 쉽게 만들 것이다. 개발자는 업스트림 패치를 비교하고 결함이 mobile-use, Artemis 또는 양쪽 모두에 속하는지 판단할 수 있다.

세 번째 신호는 재현 가능한 벤치마크 문서화다. 양측 팀은 정확한 커밋, 작업 구성, 모델 설정, 재시도 정책 및 평가 로그를 공개해 긴장을 낮출 수 있다.

독립적인 재현은 Artemis가 보고한 성능이 새로운 엔지니어링, 공유된 기반, 구성 선택 또는 이들의 조합에서 비롯된 것인지 보여줄 것이다.

이러한 신호는 하나의 저장소를 넘어 중요하다. AI 에이전트 개발은 점점 소스 코드, 자연어 프롬프트, 예시, 트레이스 및 벤치마크 하니스를 혼합하고 있다.

기존 의존성 스캐너는 가져온 패키지는 인식할 수 있지만, 복사된 프롬프트 파일이나 수동으로 이전된 코드는 놓칠 수 있다. 이 공백은 사람에 의한 출처 검토를 더욱 중요하게 만든다.

기업은 모든 외부 구성 요소에 대해 도입 기록을 마련해야 한다. 이 기록에는 소스 URL, 커밋 해시, 라이선스, 고지 사항, 수정 내역 및 책임 검토자가 포함되어야 한다.

프롬프트에도 같은 시스템을 적용해야 한다. 긴 에이전트 지침은 일반 텍스트로 저장되더라도 고유한 계획 수립 방식, 도구 규칙 및 복구 동작을 담을 수 있다.

유지관리자는 가능하면 공개 릴리스 직전에 파괴적인 이력 변경을 피해야 한다. 강제 푸시가 필요하다면 이유를 문서화하고 대체 커밋에 출처 정보를 보존해야 한다.

이러한 관행은 경쟁을 막지 않는다. 조직이 허용적 소프트웨어를 기반으로 빠르게 구축하면서도 그 기원을 명확히 유지할 수 있게 한다.

Artemis와 mobile-use 중 하나를 선택하는 개발자에게 이 분쟁이 자동으로 기술적 승자를 정해주지는 않는다. 각 프로젝트는 필요한 플랫폼, 워크플로, 모델 및 검증 통제를 기준으로 평가해야 한다.

Artemis는 현재 Android 자동화, 개발자 도구, 진단 및 여러 실행 프로필에 초점을 맞추고 있다. Mobile-use는 에이전트 프레임워크와 함께 더 폭넓은 Android 및 iOS 지원 경로를 제시한다.

사용자는 공개된 수치에만 의존하지 말고 실제 애플리케이션에서 두 프로젝트를 모두 테스트해야 한다. 또한 각 프로젝트가 이슈, 업스트림 수정 및 보안에 민감한 기기 권한을 어떻게 처리하는지도 주시해야 한다.

현재의 인정은 Google이 이미 대외적인 출처 정보를 바꿨음을 뜻한다. 해결되지 않은 질문은 저장소 이력이 요구하는 더 깊은 설명을 제공할지 여부다.

Minitap은 계속해서 증거를 독립적으로 검토할 수 있게 해야 한다. Google은 오픈소스 프로세스가 훨씬 작은 팀의 기여를 식별하고 보존할 수 있음을 보여줘야 한다.

그것이 지속적인 시험대다. 새 크레딧은 이 사안의 끝이 될 것인가, 아니면 Artemis가 어떻게 구성되었는지에 대한 완전한 공개 설명의 시작이 될 것인가?