chinese-independent-developer 딥다이브
— 중국 인디 개발자 2,500여 개 제품을 8년째 "날짜순"으로 쌓은 커뮤니티 로그 (게다가 이제 AI가 스스로 관리한다)

1프로젝트 한줄 요약

이 저장소가 대체 무엇인가.

이 저장소는 "실행되는 프로그램"이 아니라 "8년간 쌓인 한 편의 기록물"이다. 중국의 인디 개발자들이 "나는 이런 걸 만들었다"를 제보하면, 관리자가 그것을 추가된 날짜 밑에 제작자 이름과 함께 한 줄로 정리한다. 그 결과 저장소 전체가 "중국 1인 개발자들이 지난 8년간 무엇을 만들어 왔는가"를 시간순으로 훑는 두루마리가 됐다.

구성은 놀랄 만큼 단순하다. 저장소에는 마크다운 파일 4개가 알맹이의 전부이고, 여기에 기여 방법을 적은 문서와 자동화 스크립트가 붙어 있다. 데이터베이스도, 서버도, 프론트엔드도 없다. "GitHub에서 README를 스크롤한다"가 사용법의 전부다.

2왜 주목받는가

마크다운 파일 몇 개짜리 저장소가 어떻게 트렌딩 상위에 올랐나.

① "나도 1인 개발로 먹고살 수 있을까"라는 시대적 질문에 답한다

AI 코딩 도구가 쏟아지면서 "혼자서도 제품을 만들어 파는" 인디 해커 붐이 전 세계적으로 커졌다. 이 저장소는 그 붐의 중국판 살아있는 증거 목록이다. 추상적인 "할 수 있다"가 아니라, 실제로 돈을 벌거나 굴러가는 제품 2,500여 개가 제작자 이름과 함께 나열돼 있어 "이런 것도 1인이 만들었구나"를 눈으로 확인하게 해준다. 롤모델 카탈로그인 셈이다.

② 8년 누적 + 매일 갱신 — "죽지 않은" 데이터의 희소성

Awesome 리스트 대부분은 몇 년 지나면 방치돼 링크가 죽는다. 이 저장소는 2018년 3월 첫 항목부터 오늘까지 하루에도 여러 건씩 새 제품이 올라온다. 게다가 문 닫은 제품엔 :x:를 붙여 "살아있는 것과 죽은 것"까지 표시한다. 그래서 이 목록을 위에서 아래로 읽으면 중국 인디 신(scene)의 유행 변천사(초기 유틸 → 위챗 미니앱 → 최근의 AI SaaS 러시)가 그대로 드러난다.

③ 리스트가 스스로를 관리한다 — AI 셀프 큐레이션 사례

가장 흥미로운 기술 포인트다. 이 저장소는 최근 유지보수를 상당 부분 AI에게 넘겼다. GitHub Actions가 6시간마다 Claude Code 루틴을 깨워, 새로 올라온 이슈·PR을 읽고 → 유효한 제보인지 판별하고 → 정해진 형식으로 다듬어 → 저장소에 직접 커밋한다. "Awesome 리스트를 사람이 손으로 관리한다"는 통념을 깬, AI가 오픈소스 저장소를 자율 운영하는 실전 예제다. (자세한 구조는 4번 섹션에서 해부한다.)

④ 진입장벽이 0이다

읽는 데 아무것도 필요 없다. 계정도, 설치도, 빌드도 없이 GitHub 페이지만 열면 끝이다. 제보도 이슈에 한 줄 쓰면 되고, 형식이 틀려도 AI가 고쳐 넣어준다. "누구나 5초 만에 읽고, 5분 만에 기여할 수 있다"는 낮은 문턱이 8년간 커뮤니티를 유지한 힘이다. 한국 인디 개발자에게도 그대로 벤치마킹거리가 된다.

3기술 스택 전체 지도

코드가 거의 없는 저장소의 "기술"은 무엇인가 — 데이터 포맷·기여 규약·자동화가 곧 스택이다.

데이터 계층 — 전부 마크다운

항목 하나의 "작성 문법" (CONTRIBUTING.md 규약)

제품을 어떻게 적는지는 CONTRIBUTING.md에 못박혀 있다. 제작자를 H4 헤딩으로, 그 아래 제품들을 불릿으로 단다:

# 표준형 (제작자 + 도시 + 링크, 그 아래 제품)
#### 제작자이름(도시명) - [Github](), [博客]()
* :white_check_mark: [제품이름](주소)：짧고 명확한 소개 - [더 보기]()

# 최소형 (링크·도시 생략 가능)
#### 제작자이름
* :white_check_mark: [제품이름](주소)：짧고 명확한 소개

자동화 스택 — 2세대에 걸친 진화

이 저장소의 진짜 "코드"는 .github/와 .claude/ 안에 있다. 제보를 받아 목록에 반영하는 파이프라인이 두 세대로 진화했다.

라이선스 — 없음

주의할 점 하나. 이 저장소에는 LICENSE 파일이 없다(GitHub API도 license: null). 즉 담긴 텍스트를 대량 복제·재배포할 명시적 권리가 부여돼 있지 않다. 읽고 참고하는 건 자유지만, 통째로 퍼가 다른 곳에 재출판하려면 GitHub 기본 약관 외엔 근거가 없다는 점을 기억하자.

4아키텍처 심화 분석

"파일 4개 + 그 안의 3계층 + 자기관리 봇" — 이 세 가지가 전부이자 핵심이다.

설계 패턴 ① — 주제별이 아니라 "시간순 로그"

보통 Awesome 리스트는 "AI 도구 / 생산성 / 게임…" 식 주제 서랍으로 나눈다. 이 저장소는 그러지 않는다. 본편 안에는 오직 "OOOO년 O월 O일 추가"라는 날짜 헤딩 694개만 있고, 제품은 그 아래 시간순으로 쌓인다. 이 선택의 장단점은 뚜렷하다.

설계 패턴 ② — 파일 4개로 나눈 이유가 제각각

4개 파일은 "그냥 크기 때문에" 나눈 게 아니다. 분리 이유가 셋으로 다르다는 게 포인트다.

설계 패턴 ③ — AI 셀프 큐레이션 파이프라인의 안전장치

2세대 자동화(.claude/skills/chinese-indie-dev/SKILL.md)가 이 저장소에서 가장 배울 게 많은 부분이다. AI에게 저장소 쓰기 권한을 주면서도 사고를 막기 위해 규칙(guardrail)을 스킬 문서에 명시해뒀다.

실제 항목 하나의 해부

# H4: 제작자 (도시 + GitHub 링크)
#### dunizb(항저우) - [GitHub](github.com/dunizb), [홈페이지](...)
# 불릿: 상태이모지 ❌(문닫음) + [제품명](링크) + 설명 + 더보기
* :x: [집미미도(集美美图)](apps.apple.com/.../id1592148389)：
      단순하고 순수한 미인 화보 배경화면 앱. 안드로이드판은
      샤오미·화웨이·바이두·쿠안·360 마켓에 출시 - [더 보기](...)

이 한 줄에 제작자·도시·상태·제품명·링크·설명·부가링크가 모두 담긴다. :x: 하나로 "이 앱은 이제 안 굴러간다"가 표시되고, CONTRIBUTING은 문 닫은 제품엔 왜 닫혔는지까지 적어달라고 권한다 — 실패 사례도 데이터로 남기려는 태도다.

5디렉토리 구조 해부

알맹이는 마크다운 4개, 나머지는 전부 "자동화와 규약"이다.

주목할 점: "목록 데이터"보다 "목록을 관리하는 규칙"에 더 많은 파일이 쓰였다. 실제 콘텐츠는 마크다운 4개지만, 그것을 어떻게 받고·검증하고·정리하는가를 정의한 파일(CONTRIBUTING, issue_template, MAINTAINER, 워크플로 2개, 스킬)이 그만큼 많다. "잘 굴러가는 커뮤니티 저장소 = 콘텐츠 + 그만큼의 운영 규약"임을 보여준다.

6학습 포인트

코드가 없어도 배울 게 많다 — 이 저장소는 "커뮤니티 운영"과 "AI 자동화"의 살아있는 교재다.

① 커뮤니티 큐레이션 저장소를 설계·운영하는 법

수천 명이 제각각 기여하는 목록이 8년간 무너지지 않은 비결은 엄격한 형식 규약 + 낮은 진입장벽의 균형이다. 제보 양식을 issue_template로 못박고, CONTRIBUTING에 좋은 작성법까지 예시로 주고, 그런데도 "이슈에 한 줄"이면 기여가 되게 한다. 오픈소스 문서 프로젝트를 운영하고 싶다면 이 저장소의 .github/ 구성이 그대로 참고서가 된다.

② "좋은 한 줄 소개" 쓰는 기술 (제품 카피라이팅)

CONTRIBUTING의 태그라인 가이드는 개발자에게 특히 값지다 — "제품 종류를 먼저, 차별점을 다음에", 그리고 공허한 형용사(강력·간편·빠름)를 빼라. 이건 인디 개발자가 자기 제품을 소개할 때, 나아가 이력서·포트폴리오 한 줄을 쓸 때도 통하는 원칙이다. 2,500개의 실제 한 줄 소개가 "좋은 예 / 나쁜 예"의 방대한 데이터셋이 된다.

③ AI로 오픈소스 저장소를 자율 관리하기

이 저장소의 백미. GitHub Actions cron → AI 에이전트 → 직접 커밋이라는 파이프라인을 실물로 보여준다. 특히 배울 것은 "AI에게 쓰기 권한을 줄 때의 안전장치" — append-only(삭제 금지), URL 멱등성(중복 방지), 반응 API 금지, CLI 사용으로 부작용 최소화. AI 에이전트를 실제 운영 시스템에 붙일 때 반드시 고민해야 할 것들이 이 스킬 문서 하나에 압축돼 있다.

④ 인디 해커 비즈니스 패턴을 데이터로 관찰하기

목록 자체가 시장 조사 자료다. "어떤 종류의 제품이 반복 등장하나", "무엇이 :x:(폐업) 표시가 붙나", "요즘은 뭐가 몰리나(AI SaaS!)"를 읽어내면 1인 개발로 무엇을 만들면 승산이 있는지에 대한 감이 잡힌다. 성공·실패가 함께 기록된 8년치 로그라 생존 편향이 덜하다.

7시스템 요구사항 · 라이선스

읽는 데 필요한 건 없다. 대신 "권리 관계"를 알아야 한다.

기술 요구사항

라이선스 — 명시된 것이 없음 (사용 전 반드시 확인)

8직접 해볼 수 있는 실습 과제

마크다운 하나를 파싱하는 순간부터 놀거리가 쏟아진다. 난이도별 5개.

과제 A — 목록 통계 뽑기 난이도 ★☆☆☆

4개 마크다운을 파싱해 제품 수·상태별 비율(✅/🕗/❌)·연도별 추가량을 집계하라. 정규식으로 헤딩과 불릿을 나누는 마크다운 파싱 입문 연습이다.

# 파이썬: 상태 이모지로 살아있는/죽은 제품 세기
import re
text = open('README.md', encoding='utf-8').read()
live = len(re.findall(r':white_check_mark:', text))
dev  = len(re.findall(r':clock8:', text))
dead = len(re.findall(r':x:', text))
print(f"출시 {live} / 개발중 {dev} / 폐업 {dead}")

과제 B — 죽은 링크 검사기 난이도 ★★☆☆

모든 제품 링크에 HTTP 요청을 보내 응답이 없는(폐업 의심) 링크를 찾아라. 여전히 :white_check_mark:인데 실제로는 죽은 항목을 골라내, ":x:로 바꾸자"는 PR을 만들어보면 실제 기여가 된다. 비동기 HTTP 요청 + 레이트 리밋 연습.

과제 C — 주제별 재분류기 난이도 ★★★☆

이 저장소의 최대 약점(주제 탐색 불가)을 직접 메워라. LLM으로 각 제품 설명을 읽어 카테고리(AI·생산성·게임·유틸…)를 자동 태깅하고, 시간순 로그를 주제별 뷰로 재구성한 정적 사이트를 만들어보라. "구조화 출력(structured output)"으로 일관된 JSON을 뽑는 게 관건.

과제 D — 나만의 자동 큐레이션 봇 난이도 ★★★★

이 저장소의 2세대 파이프라인을 재현하라. GitHub Action(cron) → 이슈 읽기 → LLM으로 형식 정리 → PR 자동 생성. 핵심은 process_item.py가 보여준 멱등성(URL 중복 방지)과 안전장치(append-only)를 직접 구현하는 것. AI 에이전트 운영의 축소판을 손에 넣게 된다.

과제 E — 중국 인디 트렌드 대시보드 난이도 ★★★★

연도별로 어떤 종류의 제품이 몰렸는지를 시각화하라(예: 2020년 위챗 미니앱 → 2026년 AI SaaS의 급증). 과제 C의 태깅 결과를 시계열 스택 차트로 그리면, "중국 인디 신 8년 변천사"가 한눈에 드러나는 인사이트 대시보드가 된다.

9관련 기술 심화 학습 로드맵

이 저장소를 "관찰"에서 "자동화"로 끌어올리려면 익힐 것들 — 4주 코스.

더 깊이 파고 싶다면

인디 해커/부트스트래핑 문화 자체를 공부하면 이 목록이 훨씬 입체적으로 보인다 — indiehackers.com, "Make"(Pieter Levels), MicroConf 같은 자료가 좋은 출발점이다. 기술 쪽으로는 AI 에이전트 오케스트레이션(스케줄된 에이전트, 도구 사용, 가드레일 설계)이 이 저장소의 2세대 파이프라인과 직결된다. "리스트를 만든다"에서 멈추지 말고 "리스트를 스스로 굴러가게 만든다"까지 가보는 것이 이 저장소가 주는 진짜 교훈이다.

10핵심 키워드 사전

이 저장소를 이해하는 데 필요한 용어 총정리.

11참고 링크

더 파고들 곳.