스타 446개, 어제 증가는 집계 없음—channy/korea-devculture가 개발 문화를 진짜 바꿀까?

① 스타 446개인데, 어제 얼마나 늘었는지는 모릅니다

PR 리뷰 때마다 “우리 팀은 왜 이렇게 승인 절차가 길죠?”, “이 레거시 코드는 누가, 어떤 기준으로 만든 건가요?”라는 질문에 다시 답하고 계신가요? 문서가 흩어져 있으면 리뷰어는 코드보다 맥락을 먼저 추적해야 합니다. 국내 IT 기업의 공개 활동까지 비교하려면 회사별 GitHub 조직과 레포지터리를 일일이 찾아야 하니 피로가 쌓입니다. 그렇다면 스타 446개의 `channy/korea-devculture`가 이 문제의 실무 대안일까요?

먼저 어제 스타가 얼마나 늘었는지는 집계되지 않았습니다. 검색 API 후보는 있지만, 현재 확인된 값은 ‘집계 없음’입니다. 스타 수만 보고 사내 개발 문화 개선 도구라고 착각해서는 곤란합니다. 스타 446개와 포크 27개는 관심의 신호일 뿐, 팀의 PR 규칙이나 레거시 분석을 대신해주는 운영 지표는 아닙니다.

이 저장소의 본질은 국내 IT 기업의 소프트웨어 개발 문화 자료와 GitHub 조직 데이터를 정리하는 저장소에 가깝습니다. README는 기업별 레포지터리 수와 팔로워 수를 보여주고, `github.md`에서 전체 목록을 제공합니다. 코드를 열어보니 `github.json`의 기업·조직 정보를 바탕으로 데이터를 갱신하고 마크다운을 생성하는 Python 스크립트가 있으며, GitHub Actions에는 매일 오후 1시 갱신 작업이 정의돼 있습니다. `main` 브랜치 변경을 감지해 업데이트를 시도하는 흐름도 확인됩니다.

즉, 이 레포지터리는 개발 문화를 직접 바꾸는 제품이 아니라 공개 데이터를 꾸준히 모아 비교 가능한 형태로 만드는 자동화 레포지터리입니다. 팀의 의사결정을 위한 출발점은 될 수 있습니다. 다만 사내 규칙을 설계하거나 PR 리뷰를 자동화하는 기능까지 있다고 보면 안 됩니다. 테스트와 릴리즈는 없고 라이선스도 명시돼 있지 않습니다. 스타가 늘었다는 이유만으로 회사 레포지터리에 바로 들여놓기보다는, 공개 현황 조사와 문화 논의를 위한 참고 자료로 선을 긋는 편이 정확합니다.

📌 먼저 보는 핵심 답변 (30초 요약)

• **총점 3.2/5, 등급은 '지켜보자'입니다.**: 총점 3.2/5, 등급은 '지켜보자'입니다.
• **README의 자동 업데이트·목록 생성·JSON 관리 주장은 관련 코드에서 모두 확인됐고, requirements.txt와 CI도 갖췄습니다.**: README의 자동 업데이트·목록 생성·JSON 관리 주장은 관련 코드에서 모두 확인됐고, requirements.txt와 CI도 갖췄습니다.
• **테스트와 릴리즈가 없고 라이선스도 없어, 사내 핵심 시스템에 바로 넣기보다 공개 GitHub 데이터 정리용으로 제한하는 편이 안전합니다.**: 테스트와 릴리즈가 없고 라이선스도 없어, 사내 핵심 시스템에 바로 넣기보다 공개 GitHub 데이터 정리용으로 제한하는 편이 안전합니다.

② 파일은 단출한데, 운영 조건은 어디까지 준비됐나

클론은 성공했습니다. 파일은 8개로 단출하지만, 구조는 수집과 문서 생성의 2단계로 나뉩니다. `.github/workflows/update.yaml`이 매일 오후 1시와 `main` 브랜치 변경을 진입점으로 삼고, `src/update-json.py`가 GitHub API 데이터를 받아 `github.json`을 갱신합니다. 이어 `src/update-markdown.py`가 `github.json`을 읽어 `github.md`의 목록을 생성합니다. `2022-survey.md`는 별도 자료이며, README는 결과를 보여주는 안내판에 가깝습니다.

여기서 설치 문서가 친절하다고 착각해서는 곤란합니다. 제공된 README 앞부분에는 Python 설치나 패키지 설치를 위한 명령 3줄이 보이지 않습니다. 인용할 실제 설치 명령도 없습니다.

text

README 앞부분에 설치 명령 3줄은 없습니다.

사전 준비물은 명확합니다. Python 런타임과 `requirements.txt`에 선언된 의존성을 먼저 맞춰야 합니다. 다만 제공된 README 앞부분에는 Python 버전이나 의존성 설치 방법이 적혀 있지 않습니다. `requirements.txt`가 패키지 진입점이므로, 현업에서는 CI와 로컬 환경의 Python 버전을 고정하고 의존성 설치 단계를 워크플로에 명시해야 합니다.

GitHub API 접근 조건도 빠지면 곧바로 운영 리스크가 됩니다. 공개 저장소만 읽는다면 인증 없이 접근할 여지가 있지만 API 호출량 제한에 걸릴 수 있습니다. CI에서는 기본 `GITHUB_TOKEN` 또는 별도 토큰을 시크릿으로 주입하고, 조직·저장소 메타데이터 조회에 필요한 최소 권한을 확인해야 합니다. 토큰을 코드나 `github.json`에 넣는 방식은 금지입니다.

테스트 파일은 없습니다. CI가 있다는 사실과 코드 검증이 갖춰졌다는 말은 전혀 다릅니다. 현재 CI는 정기 갱신과 산출물 생성을 자동화하는 장치이지, 변경된 Python 코드의 회귀를 보장하는 테스트 체계는 아닙니다. 릴리즈도 없고 라이선스도 없어, 사내 도입 전에는 의존성 고정과 토큰 권한, 실패 시 알림까지 직접 보강해야 합니다.

③ README의 약속은 코드에 실제로 박혀 있나

README의 핵심 약속 네 가지를 코드와 정적으로 대조했습니다. 결론부터 말하면 네 항목 모두 ✅입니다. 다만 “자동화된다”는 말만 보고 운영 부담이 사라진다고 생각해서는 곤란합니다.

✅ 매일 오후 1시 기업·레포지터리 데이터를 갱신한다는 주장은 `.github/workflows/update.yaml`의 `cron` 설정으로 확인됩니다.

✅ `main` 브랜치에 새 커밋이 생기면 업데이트를 시도한다는 흐름은 `src/update-json.py`의 `main` 문자열에서 확인됩니다.

✅ 기업 목록을 생성해 제공한다는 약속은 `src/update-markdown.py`의 `github.md` 처리 문자열에 박혀 있습니다.

✅ 기업·조직 정보는 `github.json`을 수정하고 갱신하는 구조이며, 이 경로 역시 `src/update-json.py`에서 확인됩니다.

| 구분 | 이 저장소 | 기존/대안 방식 | 실무 권장 |

|---|---|---|---|

| 갱신 주기 | cron 기반 매일 오후 1시, main 변경 시도 | 수동 조사는 필요할 때만, 스프레드시트는 담당자 갱신, API 스크립트는 예약 실행 필요 | 정기 갱신이 필요하면 이 저장소 구조가 유리합니다 |

| 변경 방식 | `github.json` → Python 스크립트 → `github.md` 생성 | 기업별 수동 조사, 스프레드시트 직접 수정, API 결과를 코드가 직접 저장 | 원천 데이터와 표시 문서를 분리하세요 |

| 유지보수 부담 | 조직 정보는 JSON 수정, 생성 로직은 스크립트 관리 | 수동·스프레드시트는 사람 의존, API 스크립트는 예외·인증 대응 필요 | 소수 담당자가 관리하면 JSON 방식이 낫습니다 |

| 감사 가능성 | 입력 JSON과 생성 스크립트, 커밋 이력 추적 가능 | 수동 기록은 누락되기 쉽고, 스프레드시트는 변경 맥락이 흐려짐 | PR 검토와 커밋 기록을 운영 규칙으로 묶어야 합니다 |

구조는 단순하고 읽기 쉽습니다. `github.json`을 원천 데이터로 두고 Python이 GitHub 정보를 갱신한 뒤 `github.md`를 만드는 흐름이라, 수동 복사보다 재현성이 낫습니다. 그렇다고 완성품은 아닙니다. 테스트가 없고 릴리즈도 없습니다. 라이선스 역시 없어 회사 레포지터리에 편입할 때 사용 범위와 배포 책임을 별도로 확인해야 합니다. 마지막 커밋은 2026-09-23으로 최신이지만, 최신 커밋 하나가 품질 보증서는 아닙니다. stars 446개에 기대어 덥석 도입하기보다, 이 저장소를 데이터 수집 자동화의 작은 기반으로 보고 내부 검증 절차를 붙이는 편이 맞습니다.

④ 별 다섯 개가 아니라, 약한 고리부터 봐야 합니다

가장 먼저 걸리는 부분은 라이선스·지속성입니다. 라이선스·지속성 ★1 — 저장소에 라이선스가 없고 릴리즈도 없습니다. 사내 서비스나 문서에 편입할 때 사용·배포 조건을 확인하기 어렵고, 프로젝트가 어떤 방식으로 유지될지 계약할 근거도 약합니다. 마지막 커밋이 2026-09-23 기준 0일 전이라는 점은 변경이 계속될 가능성을 보여줄 뿐, 품질 보증이나 장기 유지보수 약속은 아닙니다.

완성도 ★2 — 파일 구성은 단순하지만 테스트가 없고 릴리즈도 없습니다. CI는 있으나, 자동화 파이프라인이 있다는 사실만으로 데이터 갱신 로직의 회귀나 예외 처리가 안전하다고 볼 수는 없습니다. README의 설명을 믿고 바로 운영 자산으로 취급하기에는 검증 장치가 빈약합니다.

문서·커뮤니티 ★3 — README와 `github.md`가 있어 무엇을 정리한 저장소인지는 빠르게 파악됩니다. 스타 446개, 포크 27개, 기여자 11명이라는 외부 관심도 확인됩니다. 다만 열린 이슈는 0개이고, 활발한 논의나 릴리즈 흐름까지 확인되는 수준은 아닙니다. 숫자만 보고 커뮤니티 리스크가 사라졌다고 판단해서는 곤란합니다.

설치 난이도 ★5 — `requirements.txt`가 있고 클론이 성공했으며 CI도 구성돼 있어 진입 장벽은 낮습니다. 소스 구조도 `src/` 아래 갱신 스크립트 중심이라 처음 보는 사람이 훑기 어렵지 않습니다. 단, 쉬운 설치와 운영 안정성은 같은 말이 아닙니다.

설명 일치도 ★5 — README가 말한 네 가지 핵심 주장, 매일 오후 1시 자동 갱신, `main` 커밋 기반 갱신 시도, `github.md` 생성·제공, `github.json` 기반 기업 정보 관리를 모두 코드에서 확인했습니다.

총점은 3.2점, 등급은 ‘지켜보자’입니다. 기능 설명은 정직하지만, 라이선스와 유지보수의 약한 고리를 해결하기 전에는 사내 표준 도구로 올리기보다 관찰 대상에 두는 편이 맞습니다.

⑤ 현업에서 터지는 3대 함정, 도입 전에 막아야 합니다

첫 번째 함정은 보안 경계입니다. 이 저장소는 GitHub 기업·레포지터리 공개 데이터를 다루지만, 사내 코드나 내부 조직 정보까지 수집 대상으로 넓히면 이야기가 달라집니다. 향후 요약 기능을 붙일 때 원문이 외부 LLM이나 외부 API로 전송되는지 먼저 확인해야 합니다. 허용된 공개 데이터만 수집하고, 사내 소스는 기본 차단하세요. API 토큰은 코드와 분리해 시크릿으로 관리하고, 프록시와 네트워크 egress 정책도 LLM 호출 경로와 GitHub 호출 경로를 나눠야 합니다. 로그에 원문과 토큰이 남지 않는지도 도입 체크리스트에 넣어야 합니다.

두 번째는 토큰 비용 폭탄입니다. GitHub 데이터가 갱신될 때마다 전체 목록을 LLM에 넘기면 작은 자동화도 금방 비싸집니다. 마지막 커밋, 변경 파일, 해시를 기준으로 변경분만 처리하고, 결과는 캐시해야 합니다. 호출은 배치 단위로 묶되 최대 호출량과 문서 크기 상한을 둡니다. 일일 예산 알림, 서비스별 토큰 한도, 실패 재시도 횟수 제한도 필수입니다. 타임아웃 뒤 무제한 재시도하는 구현은 장애를 비용 청구서로 바꾸는 지름길입니다.

세 번째는 런타임 충돌입니다. 저장소에는 `requirements.txt`가 있지만 테스트는 없습니다. 로컬 Python 버전과 GitHub Actions 러너의 Python 버전이 다르거나, 의존성이 최신 버전으로 풀리면 같은 코드가 전혀 다른 결과를 낼 수 있습니다. Python과 패키지 버전을 고정하고, 가상환경 또는 컨테이너를 사용하세요. 로컬과 CI가 같은 설치 명령과 실행 조건을 쓰는지도 확인해야 합니다. 의존성 취약점 점검과 잠금 파일 검토도 빠지면 안 됩니다. CI가 통과했다는 이유만으로 자동화 결과를 믿어서는 곤란합니다. 테스트 없는 저장소인 만큼, 샘플 입력 검증과 출력 diff 확인을 사람 승인 단계로 남겨야 합니다.

⑥ 나라면 공개 데이터 탐색용으로만 쓰고, 이런 팀에는 권하지 않습니다

나라면 `channy/korea-devculture`를 공개 데이터 탐색용으로만 씁니다. 사내 핵심 시스템에 넣을 도구로 보기는 어렵습니다. 스타는 446개지만 라이선스가 없고, 릴리즈와 테스트도 없습니다. 숫자가 많다고 데이터 품질과 운영 책임까지 따라오는 건 아닙니다.

첫 번째 워크플로우는 공개 기업 목록을 작게 유지하는 방식입니다. 새로 살펴볼 기업이나 조직이 생기면 `github.json`에 대상을 추가해 Pull Request를 올립니다. 검토가 끝나면 GitHub Actions가 매일 오후 1시에 갱신하고, `main`에 새 커밋이 생긴 시점에도 업데이트를 시도합니다. 생성된 `github.md`에서 기업명, 레포지터리 수, 팔로워 수, 주소를 사람이 확인합니다. 숫자가 이상하거나 조직명이 바뀌었다면 원본 GitHub 페이지와 변경 이력을 다시 대조해야 합니다.

두 번째는 분기별 채용·기술 조사 자료의 초안으로 쓰는 흐름입니다. 공개 조직 목록을 기준으로 조사 대상을 추리고, 분기마다 레포지터리 구성과 공개 활동 변화를 비교합니다. 다만 이것을 기업의 실제 개발 문화나 채용 규모로 단정해서는 곤란합니다. 공개 GitHub는 공개된 일부일 뿐입니다. 보고서에는 원자료 링크와 조사일을 남기고, 사람이 변경 내역을 검수한 뒤 사용해야 합니다.

세 번째는 소규모 공개 목록을 빠르게 관리하는 용도입니다. 대상이 몇 개 안 되고 표 형식 결과면 충분할 때, 직접 GitHub API 수집 스크립트를 처음부터 관리하는 것보다 이 레포지터리의 JSON-마크다운 갱신 흐름이 가볍습니다.

반대로 라이선스 검토가 필수인 사내 제품, 내부 소스나 개인정보를 외부 서비스로 보내야 하는 팀, 테스트·릴리즈·운영 보장이 필요한 핵심 시스템에는 권하지 않습니다. 대안은 GitHub API를 직접 사용하는 사내 수집 스크립트, GitHub Actions 기반 자체 파이프라인, 공개 조직 탐색 목적의 GitHub 검색 기능입니다. 어느 쪽이든 라이선스와 API 정책은 도입 전에 별도로 확인해야 합니다. 2026-09-23 기준.

첨부 이미지

• 이미지 1: 01_repo.png (channy/korea-devculture 저장소 첫 화면 (2026-09-23))
• 이미지 2: 03_tree.png (받아서 열어본 폴더 구조)
• 이미지 3: 04_score.png (별점 3.2 / 5 — 지켜보자)

❓ 자주 묻는 질문

Q. channy/korea-devculture는 어떤 저장소인가요?

A. 국내 IT 기업의 소프트웨어 개발 문화와 기업별 GitHub 조직·레포지터리 정보를 정리하는 저장소입니다. github.json을 바탕으로 데이터를 관리하고 github.md에 목록을 제공합니다.

Q. channy/korea-devculture는 데이터를 자동으로 업데이트하나요?

A. 검증표 기준으로 .github/workflows/update.yaml에 cron이 있어 매일 오후 1시 업데이트를 예약하고, src/update-json.py에는 main 브랜치의 새 커밋을 감지해 업데이트를 시도하는 흐름이 확인됩니다.

Q. channy/korea-devculture를 사내 시스템에 바로 도입해도 되나요?

A. 권하기 어렵습니다. 라이선스가 없고 테스트와 릴리즈도 없으므로, 사용 범위와 수정·배포 조건을 먼저 검토해야 합니다. 내부 소스나 개인정보를 다루는 시스템이라면 외부 API 전송 정책도 별도로 확인해야 합니다.

Q. channy/korea-devculture의 설치 난이도는 어느 정도인가요?

A. 저장소에 requirements.txt와 CI가 있고 클론도 성공해 설치 부담은 낮은 편으로 평가할 수 있습니다. 다만 실제 도입 전에는 Python 버전과 의존성 조건, GitHub API 인증 요구사항을 확인해야 합니다.

이 글은 2026-09-23 기준으로 저장소를 내려받아 README와 코드를 대조한 결과이며, 프로그램을 직접 실행한 결과는 아닙니다. 오픈소스는 빠르게 바뀌므로 최신 상태는 저장소에서 확인해 주세요. 참고·인용 시 이 글의 URL을 출처로 남겨주시고, 써보신 경험은 댓글로 나눠주세요.