짧은 토요일 요약입니다. 이번 주는 오픈 웨이트 (open weights) 리더보드가 다시 한번 변동되었고, 한 저명한 연구자의 행보가 HN 댓글 220개를 끌어냈으며, 보안 관련 이야기가 제 ETL의 일부를 재고하게 만들었고, 개발 인프라 배경에서 일어난 서로 관련 없는 두 가지 사건이 주목할 만한 가치가 있었던 한 주였습니다.

GLM-5.2가 이제 선두 오픈 웨이트 모델이 되었습니다

6월 17일, Artificial Analysis는 리더보드를 업데이트했으며 Zhipu AI의 GLM-5.2가 오픈 웨이트 (open weights) 모델 중 1위를 차지했습니다. HN 스레드는 734 포인트와 369개의 댓글에 도달했는데, 이는 단순히 추천(upvotes)만 받은 것이 아니라 실질적인 검토를 거쳤음을 의미합니다.

저는 aiappdex.com을 위해 파이프라인 태그와 좋아요 수에 따라 모델을 가져오는 HuggingFace ETL을 운영하고 있습니다. GLM-5.2는 모델 카드에 명확한 "chat" 또는 "instruction-tuned" 표시 없이 text-generation 태그에 속해 있기 때문에 지난번 새로고침 때는 나타나지 않았습니다. 제가 같은 이유로 순위가 높은 모델을 놓친 것은 이번이 두 번째입니다.

계획 중인 해결책: 파이프라인 태그와 상관없이 HuggingFace 좋아요가 2000개 이상인 모델에 대해 2차 패스를 추가한 다음, 매달 Artificial Analysis 및 LMSYS 순위와 교차 참조하겠습니다. 중국의 오픈 모델들은 벤치마크 위치에 비해 영어권 커버리지에서 지속적으로 과소평가되는 경향이 있는 것 같습니다. 추적할 가치가 있습니다.

Noam Shazeer가 OpenAI에 합류했습니다

이 소식은 6월 18일에 올라와 251 HN 포인트와 220개의 댓글을 기록했습니다. Noam Shazeer는 Google Brain에서 Transformer 아키텍처를 공동 발명했으며, Character.AI를 공동 창업하기 위해 떠났고, 이후 Google은 사실상 해당 팀을 재영입하기 위해 약 27억 달러를 지출했습니다. 이제 그는 OpenAI에 있습니다.

이것이 전략적으로 무엇을 의미하는지에 대해 확신할 수는 없습니다. 제가 주목하는 점은 다음과 같습니다: OpenAI는 연구 계층에서의 인재 경쟁에서 계속 승리하고 있다는 것입니다. 만약 당신이 특정 모델 제공업체의 API를 기반으로 구축하고 있으며 장기적인 아키텍처 방향을 중요하게 생각한다면, 이것은 주목해야 할 신호입니다. 이번 달에 무언가를 바꾸기 때문이 아니라, 12~18개월 후에 무엇이 만들어질지에 영향을 미치기 때문입니다.

제 개인 프로젝트의 경우 콘텐츠 생성을 위해 Claude Haiku 4.5를 사용하고 있으며, 이를 바꿀 생각은 없습니다. 하지만 저는 이러한 움직임들을 추적합니다. 왜냐하면 이러한 변화가 다음번 근본적인 연구(fundamental research)가 어디에서 일어날지를 변화시키기 때문입니다.

트로이 목마 악성코드를 배포하는 10,000개의 GitHub 저장소

orchidfiles.com의 게시물은 HN(Hacker News) 포인트 620점을 기록했습니다. 발견된 내용은 다음과 같습니다: 약 10,000개의 저장소가 트로이 목마(Trojan) 악성코드를 활발히 배포하고 있었으며, 이는 주로 게임 크랙, 생산성 도구, 비디오 변환기로 위장되어 있었습니다.

이는 저에게 직접적인 영향을 미칩니다. ossfind.com은 OSS(Open Source Software) 대안 디렉토리를 채우기 위해 GitHub에서 저장소 데이터를 가져옵니다. 저의 ETL(Extract, Transform, Load) 과정은 라이선스 필드와 스타(star) 수를 확인합니다. 악성 저장소는 수천 개의 실제 스타를 쌓지 못할 것이라는 가정하에, 스타 수를 정당성의 대리 지표(proxy)로 사용합니다.

그 가정이 틀렸을 수도 있습니다. orchidfiles의 게시물은 영향을 받은 저장소들의 스타 수를 상세히 기술하지 않았지만, 규모(10,000개 저장소)를 볼 때 일부는 적어도 명목상의 외견상 인기를 얻었음을 시사합니다. 아직 좋은 해결책을 가지고 있지는 않습니다. 최소 임계값을 강화하고 저장소 소유자에게 활동 이력이 있는지 확인하고 있지만, 이는 휴리스틱(heuristic)일 뿐 필터는 아닙니다. 제가 실제로 구현한 내용은 30일 이내에 공개하겠습니다.

RFC 10008: HTTP에 QUERY 메서드 도입

HTTP QUERY 메서드를 표준화하는 새로운 RFC가 HN 포인트 301점을 기록했습니다. QUERY는 의미론적으로 GET과 동일하며(안전함, 멱등성(idempotent), 캐싱 가능), 요청 본문(request body)을 허용합니다. 이는 URL에 담기에는 너무 크거나 복잡한 구조화된 쿼리 매개변수(query parameters)가 필요한 읽기 작업에 POST를 사용하던 오래된 어색한 패턴을 해결해 줍니다.

저의 세 개 사이트는 현재 모두 완전한 정적 Astro SSG(Static Site Generator)로 운영되고 있으므로, 제가 실행 중인 것에는 아무런 영향을 미치지 않습니다. 하지만 디렉토리에 필터나 검색 엔드포인트를 추가하는 것을 고민해 왔습니다. 만약 그렇게 한다면, QUERY가 올바른 메서드입니다. 브라우저와 CDN 지원이 전파되는 데는 시간이 걸리겠지만, RFC 발행이 그 시계가 돌아가기 시작하는 지점입니다. 지금 주목할 가치가 있습니다.

Lore: 새로운 버전 관리 시스템

6월 17일 Hacker News (HN)의 최상위 스토리는 Lore였습니다 — 880 포인트, 491개의 댓글 — 이는 대규모 모노레포 (monorepo)를 위해 설계된 오픈 소스 버전 관리 시스템 (VCS)입니다. README에서는 수십억 개의 파일과 수십만 명의 기여자를 대상으로 한다고 설명합니다.

저는 세 개의 사이트를 아우르는 5개의 워크플로우를 가진 GitHub Actions 모노레포를 운영하고 있습니다. 현재 방식도 작동은 합니다. 이 정도 규모에서 Git은 제가 원하지 않는 대용량 히스토리 아티팩트 (history artifacts)를 생성하고, 콘텐츠 파일에 대한 blame 연산이 느려지긴 하지만, 관리 가능한 수준입니다.

저는 Git을 교체하지 않을 것입니다. Lore는 초기 단계이며 생태계가 없고, Git의 가치는 대부분 그 생태계에서 나오기 때문입니다 — 모든 CI 제공업체, 모든 배포 플랫폼, 그리고 지구상의 모든 개발자가 여기에 해당합니다. 새로운 VCS는 그러한 관성을 극복할 만큼 충분히 심각한 문제를 해결해야 합니다. "Google 규모의 모노레포"는 실제 존재하는 문제이지만, 저의 문제는 아닙니다.

주목할 가치가 있는 점: Lore의 아키텍처 아이디어가 Git 도구들에 흡수될지 여부입니다 (Mercurial이 여러 Git 기능에 영향을 주었던 방식처럼 말이죠). 보통 이러한 경쟁 프로젝트들이 시간이 흐르며 중요해지는 방식은 바로 이렇습니다.

빽빽했던 한 주 동안 있었던 다섯 가지 소식입니다. 오픈 모델 순위가 다시 변동되었고, 주요 연구자가 팀을 옮겼으며, GitHub ETL에는 제가 아직 완전히 해결하지 못한 보안 문제가 있고, 새로운 HTTP 메서드가 표준화되었으며, 하나의 Git 대안이 생태계의 장벽을 완전히 넘지는 못했지만 소란을 일으켰습니다.

세 개의 AI 큐레이션 디렉토리 사이트를 운영하는 6개월간의 지속적인 실험의 일부입니다. 여기에 언급된 기술적 주장들은 사실이며, 이 기사는 AI의 도움을 받았습니다.