F-Droid 앱 102개 중 얼마나 AI가 썼을까? 한 개발자의 직접 조사

한 FOSS 앱 관리자가 F-Droid에 올라온 최신 업데이트 102개를 직접 열어봤다. 2026년 9월 12일자 배치다. 그가 본 것은 예상보다 많았다. 커밋 메시지부터 README, 아이콘까지 LLM(대형 언어 모델) 특유의 문체가 곳곳에 남아 있었다.

조사는 어떻게 이뤄졌나

작성자 tintotint는 학생이자 취미 프로그래머다. F-Droid를 애용하며 직접 앱도 올린다. 어느 날 브라우징 중 명백히 AI가 그린 아이콘을 발견하고 "대체 얼마나 많을까" 싶었다.

그가 만든 분류 기준은 세 단계다. ▲전체 수작업 ▲일부 AI 도움 ▲대부분 AI 작성. 판단 근거는 최근 커밋 내역, PR 수락 패턴, 저장소에 남은 클로드 코드(Claude Code)나 코드엑스(Codex) 같은 AI 에이전트 인프라 흔적이다.

중요한 전제가 있다. 앱 이력은 보지 않았다. 2014년부터 이어진 앱이라도 최근 커밋이 AI 주도로 바뀌면 '대부분 AI'로 넣었다. 작성자 스스로 "표면적일 수 있고 오류 가능성도 있다"고 밝혔다.

결과: 102개 중 어디까지가 AI인가

구체적 수치는 원문에 전체 합계로 나와 있지 않다. 다만 몇 가지 사례가 언급된다.

'Aria for Misskey'는 미스키(Misskey) 클라이언트다. 최근 커밋 전체가 LLM 작성이고, 에이전트가 보낸 PR을 그대로 합쳤으며, 클로드 코드와 코드엑스 설정 파일이 저장소에 남아 있었다.

또 다른 사례 둘. 'DuressKeyboard'와 'UnlicenseLauncher'는 노란색 '가드스덴 플래그'를 내건 앱들이다. 특이하게 git 명령어가 아닌 깃허브 웹 에디터로만 개발됐다. 수년간 개발됐지만 커밋 이력이 웹 편집 기록뿐이다.

커뮤니티는 무엇에 반응했나

해커뉴스 댓글은 세 갈래로 갈렸다.

첫째, 제목 지적. "F-Droid 자체가 아니라 F-Droid '에 있는 앱들'이 대상"이라는 지적이 가장 많은 추천을 받았다. 저장소 운영 주체와 개별 앱 개발자를 혼동하지 말라는 뜻이다.

둘째, 도구 사용 방식 비판. 웹 에디터로만 개발하는 행태를 두고 "누가 저 사람한테 git 좀 가르쳐줘라"는 조롱 섞인 댓글이 달렸다. AI 사용 여부와 별개로 개발 기초가 의심된다는 반응이다.

셋째, 본질적 질문. "바이브 코딩(vibe coding, AI에게 맡겨 뚝딱 만드는 방식)으로 오후 만에 만든 앱이 FOSS 저장소에 올라오는 게 맞나"라는 근본적 의문이 반복됐다.

양측이 동의하는 지점과 갈리는 지점

동의하는 사실

LLM 도구는 코드 작성을 확실히 빠르게 한다.
탐지 기술이 현재로선 완벽하지 않다. 작성자도 "텍스트만으론 메타 정보가 부족해 정확한 판별이 불가능"하다고 인정했다.
F-Droid 측은 별도 필터링 정책을 공개하지 않았다.

가치관 차이

입장	핵심 주장
허용파	도구는 도구다. 결과물 품질과 라이선스만 맞으면 출처는 상관없다. AI가 보안 취약점 찾기에 기여한 사례도 있다.
경계파	'저노력 전부'가 쌓이면 저장소 신뢰도가 떨어진다. 읽는 사람 없는 코드, 리뷰 없는 머지가 쌓이면 FOSS 본연의 검증 문화가 무너진다.

작성자는 후자에 가깝다. "LLM 존재 자체가 자기 학습 보상을 줄이고, 뇌 위축과 허위 정보, 기후 비용을 외면하게 만든다"고 썼다. 하지만 "한 번 프롬프트로 중형 게임을 30분에 만드는 건 인정한다"며 기술 자체를 부정하진 않았다.

쉽게 풀어보면

한 개발자가 F-Droid 최신 앱 102개를 직접 열어보고 AI 작성 흔적을 분류했습니다. 뷔페에 비유하면 이렇습니다. 음식을 직접 요리해 온 사람, 반조리 식품을 데워 온 사람, 배달 앱으로 시켜 와서 그릇만 옮긴 사람이 뒤섞여 있습니다. 겉보기엔 다 '앱'인데, 주방에서 무슨 일이 있었는지는 접시만 봐선 모릅니다.

작성자는 '그릇 모양(커밋 로그, README 문체, AI 도구 설정 파일)'을 보고 세 그룹으로 나눴습니다. 수작업, 일부 AI 도움, 대부분 AI 작성. 단, 과거 이력은 안 봤습니다. 10년 된 앱이라도 요즘 커밋이 AI 투성이면 '대부분 AI'로 넣었습니다.

결과 수치는 공개되지 않았습니다. 다만 미스키 클라이언트 'Aria'처럼 커밋 전체가 LLM이고 AI 에이전트 PR을 그대로 합친 사례, 깃허브 웹 에디터로만 수년째 개발 중인 앱 두 개가 구체적 예시로 나왔습니다.

해커뉴스 댓글은 세 가지로 모였습니다. ① 제목이 F-Droid '자체'인 줄 알기 쉽다 ② 웹 에디터만 쓰는 건 개발 기초가 안 됐다 ③ 오후 만에 AI로 찍어낸 앱이 FOSS 저장소에 올라와도 되나.

핵심은 기술 찬반이 아닙니다. '검증 가능한 과정'을 중시하는 FOSS 문화에, '결과만 내면 그만'인 AI 워크플로가 어디까지 스며들게 할 것인가 하는 선 긋기 싸움입니다.

나에게 미치는 영향

일반 사용자가 F-Droid에서 앱을 고를 때 당장 확인할 수 있는 것 세 가지.

최근 업데이트 날짜와 커밋 메시지 보기 — 앱 페이지에서 '소스 코드' 링크를 누르면 깃허브/깃랩 저장소로 갑니다. 최근 커밋 메시지가 "Update README", "Fix bug", "Refactor code" 같은 기계적 한 줄로만 채워져 있으면 주의하세요.
이슈·PR 탭 확인 — 사람 개발자가 있으면 버그 리포트나 기능 요청에 답글이 달립니다. 봇만 오가거나 PR이 즉시 머지되면 검증 과정이 생략됐을 수 있습니다.
아이콘·스크린샷 퀄리티 — 명백히 AI 생성 이미지(손가락 6개, 어색한 비율, 의미 불명 그래픽)라면 최소한 '보여주기'에 신경 쓰지 않았단 신호입니다.

개발자가 아니라면 코드 품질까지 판단하긴 어렵습니다. 하지만 **'최근 활동이 사람 냄새 나는지'**는 위 세 가지만으로도 대략 가늠됩니다. 오늘 F-Droid에서 앱 하나 받아볼 일이 있다면, 설치 전 30초만 저장소 링크 눌러보세요.

남은 쟁점: 탐지 도구도, 정책도 없다

작성자가 인정한 한계는 명확하다. 텍스트만으론 AI 작성 여부를 확신할 수 없다. 별도 탐지기도 없다. F-Droid 측도 "AI 작성 코드 금지" 같은 명시적 정책을 내놓은 적 없다.

반면 리눅스 커널 사례처럼 LLM이 보안 취약점을 찾는 데 쓰인 긍정 사례도 존재한다. 본지가 21일 전 다룬 애플 M5 울트라 맥 스튜디오, 512GB 메모리로 거대 모델 로컬 실행 기사에서도 로컬 LLM 실행 환경이 확산 중임을 다뤘다. 하드웨어 장벽이 낮아질수록 'AI 도움 없는 코드'를 찾는 건 더 어려워질 전망이다.

관전 포인트는 세 가지다.

F-Droid가 공식 가이드라인을 낼 것인가
커뮤니티 차원에서 '사람 리뷰 필수' 같은 자율 규범이 생길 것인가
AI 탐지 도구가 실용화돼 저장소 차원 필터링이 가능해질 것인가

지금으로선 사용자가 직접 '최근 커밋 한 번 보기'가 유일한 방어선이다.