'Awesome repositories are no longer awesome', 우리말로 하면 '어썸 저장소는 이제 어썸하지 않다'는 제목의 글이 올라왔어요. 어썸 리스트가 뭐냐면, 특정 주제의 좋은 라이브러리와 도구, 학습 자료를 사람이 직접 골라 모아둔 GitHub 저장소예요. awesome-python처럼 이름 앞에 awesome이 붙어 있고, 이런 리스트들을 모아둔 sindresorhus/awesome이 대표적이죠. 새로운 분야를 공부할 때 일단 어썸 리스트부터 찾아보던 분들이 많을 거예요.
참고로 이 글은 원문을 요약한 게 아니라, 제목이 던지는 질문을 놓고 따로 풀어본 글이에요. 아래 원인 분석은 원문 저자의 주장이 아니라 업계 흐름을 정리한 것으로 읽어 주시고, 저자의 논지는 링크에서 직접 확인해 주세요.
어썸 리스트의 가치는 사람의 안목이었어요
어썸 리스트는 동네 서점 주인이 손글씨로 써둔 추천 카드 같은 존재였어요. 세상의 모든 책을 늘어놓는 게 아니라, 이 분야를 잘 아는 누군가가 '이건 읽어볼 만해요' 하고 걸러주는 거죠. 그러니 핵심 자산은 링크의 개수가 아니라 걸러내는 판단이에요. 그런데 이 판단을 유지하는 데 드는 비용이 점점 커지고 있어요.
무엇이 달라졌을까요
첫째, 유명한 리스트에 오르는 것 자체가 홍보 수단이 됐어요. 스타가 많은 리스트에 한 줄 실리면 방문자가 늘어나니, 자기 프로젝트를 올려달라는 PR(코드나 문서를 고쳐달라는 제안)이 몰리기 쉬워요. 이런 문제는 새로운 게 아니에요. 2020년 Hacktoberfest 때는 티셔츠를 받으려는 의미 없는 PR이 쏟아져서, 행사 방식이 저장소가 직접 참여를 선택하는 쪽으로 바뀌기도 했어요.
둘째, 생성형 AI가 만드는 비용을 크게 낮췄어요. 이제는 그럴듯한 README와 프로젝트를 몇 시간이면 뚝딱 만들 수 있다 보니, 겉모습만으로 품질을 구분하기가 훨씬 어려워졌거든요. 반면 검토하는 사람의 시간은 그대로예요. curl 프로젝트가 AI로 쓴 듯한 저품질 보안 제보에 시달리다 2026년 초 버그 바운티를 접은 것도 같은 구조의 문제예요. 만드는 쪽은 싸졌는데 확인하는 쪽은 여전히 비싼 거죠.
셋째, 스타라는 신호도 흔들리고 있어요. 카네기멜런대 등의 연구진은 2024년 말 공개한 연구에서 GitHub의 가짜 스타로 의심되는 사례가 약 600만 건에 이른다고 분석했어요. 스타 수를 보고 안심하기 어려워진 거예요.
넷째, 유지보수 피로예요. 리스트 관리는 대개 보상 없는 봉사인데 링크는 계속 낡아가요. 여기에 요즘은 AI에게 바로 추천을 묻는 사람이 늘면서, 리스트를 가꿀 동기도 약해지고 있을 수 있어요. 이건 제 추측이지만요.
단순히 불편한 게 아니라 위험할 수도 있어요
잘못된 추천은 보안 문제로 이어지기도 해요. 슬롭스쿼팅이라는 공격이 있는데, 이게 뭐냐면 AI가 그럴듯하게 지어낸 가짜 패키지 이름을 공격자가 미리 등록해 두는 수법이에요. 철자가 비슷한 이름으로 속이는 타이포스쿼팅의 AI 시대 버전이라고 보면 돼요. 검증 안 된 리스트나 AI 답변의 이름을 그대로 복사해 설치하면, 남의 코드를 내 서버에서 실행하게 될 수 있거든요.
대안들은 어떤가요
스타 수 정렬은 가장 쉽지만 앞서 본 것처럼 조작에 약해요. best-of 계열 리스트처럼 커밋, 다운로드 같은 지표로 자동 순위를 매기는 방식은 신선도가 좋은 대신 안목은 빠져 있어요. OpenSSF Scorecard는 저장소의 보안 관행을 점수로 보여주고, deps.dev는 의존성과 알려진 취약점을 살펴보기 좋아요. 다만 이런 도구는 '안전하게 관리되는가'를 알려줄 뿐 '내 문제에 맞는가'까지 답해주지는 않아요. 결국 실제로 써본 사람의 후기가 여전히 가장 값진 신호예요.
한국 개발자에게 주는 시사점
라이브러리를 고를 때 리스트는 출발점으로만 쓰고, 최소한의 확인을 습관으로 만들어 보세요. GitHub CLI가 있다면 한 줄로 기본 정보를 볼 수 있어요.
gh repo view owner/repo --json pushedAt,stargazerCount,isArchived,licenseInfo,latestRelease
마지막 업데이트와 릴리스가 너무 오래되지 않았는지, 아카이브되지 않았는지, 라이선스가 회사 제품에 써도 되는지를 먼저 보는 거예요. 그다음 이슈 탭에서 메인테이너가 실제로 답하고 있는지 확인하고, 패키지 이름은 공식 레지스트리에서 철자까지 대조해 보세요. 마지막으로 30분짜리 작은 예제를 돌려보면 README에서는 안 보이던 게 보여요.
팀 단위라면 '우리 팀의 어썸 리스트'를 만들어 보는 것도 좋아요. 무엇을 골랐는지만이 아니라 왜 골랐고 무엇을 왜 버렸는지까지 적어두면, 어떤 공개 리스트보다 쓸모 있는 자산이 되거든요.
마무리
한 줄로 정리하면, 링크를 모으는 건 쉬워졌지만 믿을 수 있는 판단은 더 귀해졌어요. 여러분은 새로운 라이브러리를 고를 때 무엇을 가장 먼저 확인하시나요? 아직도 즐겨 찾는 어썸 리스트가 있다면 공유해 주세요.
🔗 출처: Hacker News