F-Droid 업데이트 102개를 뜯어본 개발자, LLM 흔적을 3단계로 나눠봤다

오픈소스 안드로이드 앱 저장소인 F-Droid를 둘러보던 한 FOSS 앱 유지보수자가 특정 앱의 아이콘이 노골적으로 AI 생성물처럼 보이는 장면을 계기로, F-Droid에 올라오는 앱 가운데 얼마나 많은 코드가 LLM으로 작성됐는지 직접 확인해보기로 했다. 결과물은 통계가 아니라 한 사람이 저장소를 눈으로 훑은 정성적 인상 조사다.

조사 대상은 2026년 9월 12일 F-Droid에 푸시된 업데이트 묶음으로, 총 102개 앱이었다. 작성자는 '슬롭 탐지기' 같은 자동화 도구를 만든 것이 아니라 최근 커밋과 그 내용, 그리고 README를 비롯한 프로젝트 브랜딩을 보고 판단했다고 밝혔다.

분류는 세 단계다. 첫째는 'Mostly AI'로, LLM 흔적이 뚜렷해 코드의 50% 이상이 LLM 작성이라고 추정되는 경우다. 코딩 하네스 같은 에이전트 인프라가 저장소에 들어 있으면 자동으로 이 등급에 배정된다. 둘째는 'Hard to say / Mostly human / Other'로, 유지보수자나 기여자가 간헐적으로 LLM 커밋을 섞었지만 전체적으로는 사람이 쓴 것으로 보이는 경우다. 특정 용도만 허용하는 LLM 정책을 둔 프로젝트도 여기에 들어가며, LLM 작성 비중은 50% 미만으로 추정된다. 셋째는 'No signs of AI'로, 의심스러운 정황이 없거나 엄격한 LLM 정책을 운영하는 경우다.

판단 근거로 쓰인 신호는 여러 가지다. 커밋 메시지와 커밋 구조, README에 과도하게 들어간 이모지, 저장소에 명시된 AI 사용 고지, Claude Code나 Codex 같은 에이전트 도구의 흔적, 커밋의 Claude 공동저자 표기 등이 모두 단서로 언급됐다.

구체적인 사례도 함께 공개됐다. Nostr 이벤트 서명 앱인 Amber는 최근 커밋 전부가 LLM으로 작성됐고 에이전트가 올린 PR이 그대로 수용됐으며 Claude Code와 Codex 인프라가 저장소에 존재해 'Mostly AI'로 분류됐다. 도이체반 열차 도착 시간 분포를 다루는 BayesianBahn은 모든 커밋에 Claude가 공동저자로 표기돼 있다. 운동을 퀘스트와 보스전으로 바꾸는 앱 bati는 README에 AI 사용 사실을 스스로 밝혀 분류가 쉬웠다. 잔고 대시보드 balance와 장보기 추적 앱 baly_groceries_tracker는 코드와 커밋에서 AI 냄새가 났고, BeatBridge와 BlockDrop은 Claude Code 기여분과 LLM 인프라가 확인됐다. 반대로 갤러리·메타데이터 탐색기 aves와 바코드 스캐너 BinaryEye는 의심스러운 점이 없었다. 마이크로블로깅 앱 aria는 커밋 명명과 구조가 다소 수상했지만 다른 근거를 찾지 못해 보수적으로 판단했고, 애니메이션 배경화면 앱 nosatmosphereeffect는 README의 이모지 사용이 많다는 정도가 지적됐다.

작성자는 LLM의 매력이 개발자를 게으르게 만들어준다는 데 있다고 본다. README를 처음부터 쓰지 않고 LLM에 맡기고, 코드 리뷰도 LLM이 자기 변경을 검토하게 하며, 저장소 접근 권한까지 줘서 커밋 버튼을 누를 필요조차 없게 만든다는 것이다. 이런 태도가 저장소 곳곳에 흔적으로 남기 때문에 판별이 아예 불가능하지는 않다는 논리다.

작성자는 자신의 입장도 분명히 밝힌다. LLM은 유용하고 성능도 뛰어나며, 중간 규모 게임이나 소프트웨어를 30분 만에 한 번에 만들어내는 사례는 인상적이다. 리눅스 커널 개발 사례처럼 LLM이 코드 문제를 찾아내고 일부는 해결하는 데 기여한다는 점도 긍정적으로 평가한다. 그럼에도 프로그래밍을 배우고 사이드 프로젝트를 하는 과정의 보람을 떨어뜨리고, 그럴듯하게 들리는 오정보를 양산하며, 인지 능력 저하와 환경 비용 문제를 낳는다는 점에서 LLM과 그것이 프로그래밍 생태계에 남긴 영향을 좋게 보지 않는다고 적었다.

개발자 입장에서 실무적으로 쓸모가 있는 부분은 판별 신호 자체다. F-Droid에서 앱을 고르거나 오픈소스 의존성을 검토할 때, 최근 커밋 로그와 README의 AI 사용 고지, 저장소에 포함된 에이전트 설정 파일 존재 여부가 실질적인 단서가 된다. 특히 에이전트 하네스가 저장소에 들어와 있으면 사람의 검토 없이 커밋이 쌓일 가능성을 염두에 두고 코드를 읽어야 한다. 반대로 유지보수자라면 LLM 사용 범위를 README에 명시해 두는 것이 신뢰와 심사 측면에서 유리하다.

한계도 분명하다. 텍스트만으로 LLM 작성 여부를 정확히 가려낼 방법은 없으며, 작성자 스스로 등급이 느슨하고 판단이 표면적이라고 인정했다. 앱의 과거 이력은 보지 않았기 때문에 2014년부터 존재한 앱이라도 최근 커밋이 LLM 작성이면 'Mostly AI'로 분류된다. 오류 가능성도 열어둔 상태다. 따라서 이 결과는 F-Droid 전체의 LLM 비중을 나타내는 수치가 아니라, 특정 시점의 업데이트 묶음을 한 사람이 들여다본 인상 기록으로 읽어야 한다.