에이전트로 Hugging Face의 커뮤니티 과학 업무 자동화하기

URL: https://www.youtube.com/watch?v=FLUoowDJg4I
날짜: 2026-08-21
채널: aiDotEngineer
발표자: Niels Rogge, Hugging Face 머신러닝 엔지니어

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==매일 쏟아지는 연구 논문과 모델·데이터 세트를 사람이 일일이 찾아 Hugging Face Hub로 옮기고, 문서화하고, 연구자에게 연락하는 일을 에이전트(Agent)로 얼마나 확장할 수 있는가?==

• 연구자들은 Google Drive, GitHub Releases, Dropbox, Zenodo 같은 제3자 서비스에 모델 가중치와 데이터 세트를 올리는 경우가 많아 발견 가능성(discoverability)이 떨어진다.
• Hugging Face의 커뮤니티 과학 팀은 논문과 연결된 모델·데이터 세트를 Hub에 모으고, 모델 카드·데이터 세트 카드와 메타데이터 태그로 재현성과 검색성을 높인다.
• Niels는 처음에는 2024년의 권고대로 단순한 LLM API 기반 결정적 워크플로를 만들었고, 후속 대응에는 Claude Agent SDK와 Modal 기반의 자율 에이전트를 도입했다.
• 자동화는 매일 밤 수백 건의 논문을 처리하고 수백 건의 GitHub 이슈를 만들지만, 평가(evaluation)와 샌드박스(sandbox)가 없으면 인터넷을 슬롭(slop)으로 오염시킬 위험이 있다.

핵심 주장은 업무의 성격에 따라 워크플로와 자율 에이전트를 섞어 쓰되, 모델이 충분히 좋아진 현재에는 작은 도구 하나와 스킬 하나를 가진 에이전트가 과거의 수천 줄짜리 맞춤 코드를 대체할 수 있다는 것이다. 이 사례에서 자동화는 연구자를 압박해 무언가를 팔기 위한 것이 아니라, 이미 공개된 연구 산출물을 더 찾기 쉽고 재사용하기 쉬운 곳으로 옮기도록 안내하는 반복 업무를 대규모로 실행한다.

1. 커뮤니티 과학 팀이 해결하는 문제

커뮤니티 과학(Community Science) 팀은 연구자가 만든 머신러닝 산출물을 Hugging Face Hub에서 발견·재현·재사용할 수 있게 연결하는 조직이다. Niels는 이 팀을 농담처럼 “Google Drive에서 Hub로 옮기는 팀”이라고 부른다.

1.1. 출발점: GitHub를 지나가는 흥미로운 연구

1. 트렌딩 연구와 분산된 가중치

   1. Niels는 GitHub에서 트렌딩 연구가 지나가는 것을 보다가 새롭고 흥미로운 논문을 자주 발견했다.
   2. 그러나 논문에 사용된 가중치(weights)가 Hugging Face에 없는 일이 많았다.
   3. 연구자들은 가중치나 기타 산출물을 Google Drive, GitHub Releases, Dropbox, Zenodo 또는 별도의 서버에 올렸다.
   4. 여러 서비스에 흩어진 산출물은 사람들이 연구를 발견하고 접근하는 일을 어렵게 만든다. 논문 자체가 존재해도 어떤 모델과 데이터 세트를 어디서 내려받아야 하는지 한눈에 보이지 않는다.

2. 반복되는 제안과 연구자의 긍정적 반응

   1. Niels는 해당 GitHub 저장소에 이슈를 열어 “가중치를 Hugging Face에 무료로 공개할 수 있다”고 제안했다.
   2. 대부분의 연구자는 “Google Drive에서 Hugging Face로 옮기는 것이 정말 말이 된다”고 답했다.
   3. 즉, 이 업무의 초기 장애물은 연구자의 의지가 아니라 이동·정리·문서화에 드는 반복적인 노력이다.

1.2. Hub가 제공하는 발견 가능성과 재현성

1. 논문 페이지와 연결된 산출물

   1. Hugging Face에는 arXiv에서 가져온 각 논문의 논문 페이지(paper page)가 있다.
   2. 페이지 오른쪽에 논문과 연결된 모델 또는 데이터 세트를 나열할 수 있다.
   3. 사용자는 논문을 읽은 뒤 연결된 산출물을 바로 찾아 연구를 재현하거나 그 위에서 새 작업을 만들 수 있다.

2. 메타데이터 태그와 필터

   1. Hub의 모델과 데이터 세트에는 메타데이터 태그(metadata tags)를 붙일 수 있다.
   2. 사용자는 깊이 추정(depth estimation) 모델, 대규모 언어 모델(LLM), 특정 언어용 모델처럼 관심 분야를 필터링할 수 있다.
   3. 모델이 호환되는 라이브러리(library)도 태그로 표시할 수 있다.
   4. 이런 태그는 단순한 장식이 아니라 검색·비교·재사용의 진입점을 제공한다.

3. 중앙화가 만드는 실질적 이익

   1. 여러 제3자 서비스 대신 Hugging Face를 머신러닝 산출물의 중앙화된 장소로 사용하면 연구자가 만든 결과를 찾기 쉬워진다.
   2. 모델 카드(model card)와 데이터 세트 카드(dataset card)를 추가해 무엇을 학습했는지, 어떻게 사용해야 하는지, 어떤 한계가 있는지 기록할 수 있다.
   3. 업로드·다운로드 도구가 있어 산출물 이동과 사용의 마찰이 줄어든다.
   4. 연구자는 자신의 작업을 홍보하고 더 많은 사용자에게 도달할 수 있고, 사용자는 문서화된 모델·데이터 세트를 재사용할 수 있다. 따라서 양쪽 모두에게 이익인(win-win) 구조가 된다.

1.3. 사람 손으로는 확장되지 않는 운영량

1. 수작업 템플릿

   1. Niels가 처음 열던 GitHub 이슈는 거의 같은 템플릿을 반복했다.
   2. 대표적인 요청은 “이 체크포인트를 Hugging Face에 공개해 줄 수 있나요?” 또는 “이 데이터 세트를 Hugging Face에 공개해 줄 수 있나요?”였다.
   3. 이미 산출물이 Hub에 올라와 있는 경우에는 문서화를 개선하기 위해 모델 카드나 데이터 세트 카드를 추가하는 Pull Request(PR)를 열었다.

2. 논문 폭증

   1. 매일 arXiv에 새로운 연구 논문이 수백 편씩 나온다.
   2. AI 붐이 커지면서 처리해야 할 양도 더 늘었다.
   3. NeurIPS 같은 주요 AI 학회도 엄청난 양의 논문을 배출한다.
   4. 사람이 논문을 찾고, 저장소를 읽고, 이슈와 PR을 만들고, 저자에게 후속 연락하는 방식은 좋은 의도와 별개로 확장되지 않는다.

2. 첫 번째 자동화: 결정적 워크플로로 outreach 확장하기

Niels의 첫 해결책은 자신의 수작업 절차를 단계별로 복제한 결정적(deterministic) 워크플로였다.

2.1. 사람이 하던 조사와 연락의 순서

1. 논문에서 코드 저장소로 이동

   1. 새 연구 논문을 발견하면 먼저 그 논문의 GitHub URL이 있는지 찾는다.
   2. GitHub URL이 있으면 저장소의 README를 읽는다.
   3. README와 논문 내용을 바탕으로 Hugging Face에서 새롭게 공유할 만한 모델이나 데이터 세트가 있는지 확인한다.

2. 기존 Hub 산출물의 품질 확인

   1. 모델이나 데이터 세트가 이미 Hub에 있으면 작업이 끝났다고 가정하지 않는다.
   2. 모델 카드 또는 데이터 세트 카드가 제대로 작성되어 있는지 확인한다.
   3. 예를 들어 메타데이터 태그가 붙어 있는지, 사용자가 검색하고 재현할 수 있을 만큼 문서가 갖춰져 있는지 살핀다.
   4. 문서나 태그가 부족하면 Hugging Face에 Pull Request를 연다.

3. 없는 산출물의 공개 요청과 후속 대응

   1. 산출물이 아직 Hub에 없다면 연구자에게 공개를 요청하는 GitHub 이슈를 연다.
   2. 이슈를 연 뒤에는 저자에게 후속 연락(follow-up)을 해야 한다.
   3. 따라서 자동화해야 할 전체 사슬은 논문 탐색, README 분석, Hub 상태 확인, PR 또는 이슈 작성, 저자 대응까지 이어진다.

2.2. 워크플로와 완전 자율 에이전트의 선택

1. 결정적 워크플로(workflow)

   1. Anthropic의 블로그 글 「Building effective agents」에 나온 그림을 참고했다.
   2. 워크플로는 미리 정한 파이프라인의 각 단계에서 LLM API를 호출한다.
   3. 경로가 고정되어 예측 가능하고, 제어하기 쉽고, 어떤 입력이 어떤 단계를 거치는지 확인하기 쉽다.
   4. 대신 정해진 경로 밖의 상황에 대응하는 유연성은 낮다.

2. 자율 에이전트(autonomous agent)

   1. 자율 에이전트는 LLM이 루프 안에서 도구를 호출하고, 일이 끝날 때까지 다음 행동을 결정한다.
   2. 다양한 상황에 맞게 경로를 바꿀 수 있어 유연하다.
   3. 그만큼 행동이 덜 예측 가능하고 통제하기 어려울 수 있다.
   4. 둘은 이분법이 아니다. 워크플로와 자율 에이전트 사이에 여러 중간 형태가 있고, 한 시스템 안에서 두 방식을 섞어도 된다.

3. 2024년의 단순성 원칙

   1. Niels가 이 자동화를 만들던 시점은 2024년이었다.
   2. 당시 Anthropic의 조언은 “정말 필요하지 않다면 에이전트를 만들지 말고, 단일 LLM API로 단순하게 시작하며, 프레임워크를 피하라”는 것이었다.
   3. Niels는 이 조언이 훌륭하다고 판단했고, 자신의 수작업 outreach와 똑같은 순서를 따르는 워크플로부터 시작했다.
   4. 업무가 본질적으로 순차적인 만큼, 초기에는 유연성보다 예측 가능성과 통제가 더 중요했다.

2.3. 파이프라인 구현과 야간 실행

1. 코드와 시각화

   1. 전체 파이프라인 그림은 Cursor에서 Excalidraw MCP 서버를 사용해 만들었다.
   2. Niels는 이 조합이 코드의 흐름을 시각화하기에 꽤 좋다고 평가했지만, 발표에서는 세부 구현을 모두 파고들지는 않았다.
   3. 핵심은 에이전트 프레임워크 없이 각 단계에 LLM API를 배치해 사람이 하던 절차를 복제했다는 점이다.

2. cron과 GitHub Actions

   1. 배포는 정기 실행을 뜻하는 cron job으로 단순하게 구성했다.
   2. 매일 밤 한 번 실행되므로 Niels가 자는 동안 Python 스크립트와 LLM API가 수백 편의 arXiv 논문을 읽는다.
   3. 실행 결과에 따라 GitHub 이슈를 만들거나 Hugging Face에 Pull Request를 연다.
   4. GitHub Actions를 사용했고, “Free cron jobs with GitHub Actions”라는 글을 유용한 입문 자료로 추천했다.
   5. GitHub는 간단한 cron job을 시작하기에 꽤 넉넉한 무료 티어를 제공하며, 웹 UI에서 cron job을 관리하기 쉽다는 점도 장점이다.

3. 관측 가능성(observability)

   1. 매일 밤 수백 건의 GitHub 이슈가 생기므로, 무엇이 실행됐는지 추적하는 장치가 필요하다.
   2. Niels는 Langfuse를 tracing과 observability에 사용한다.
   3. 입력과 출력, 프롬프트, LLM이 무엇을 했는지, 비용, 지연 시간(latency)을 확인할 수 있다.
   4. Langfuse가 이 용도에 꽤 좋으며 추천할 만하다고 평가한다.

3. 두 번째 자동화: 후속 GitHub 대응을 자율 에이전트로 전환하기

이슈 생성만 자동화하면 새로운 병목이 생긴다. 연구자들이 이슈에 답하기 시작하면서 Niels의 GitHub 알림함이 거대한 우편함처럼 변했기 때문이다.

3.1. 이슈 생성 이후의 새로운 병목

1. 알림의 폭증

   1. 초기에는 에이전트가 GitHub 이슈를 만들고, Niels가 그 이슈에 대한 후속 대응을 직접 했다.
   2. 수백 건의 이슈에 연구자들이 답하면 읽지 않은 GitHub 알림이 대량으로 쌓인다.
   3. 이슈 하나하나에 답하고 다음 단계를 안내하는 일은 이메일 우편함을 처리하는 것과 비슷한 반복 노동이 된다.

2. 후속 대응의 성격 변화

   1. 후속 메시지는 논문마다 상황이 다르다.
   2. 저자가 이미 올렸는지, 가중치만 옮기면 되는지, 문서화 오류를 고쳐야 하는지, 대용량 데이터 세트를 어떤 방식으로 올릴지에 따라 다음 행동이 달라진다.
   3. 그래서 Niels는 두 번째 자동화에서는 고정 파이프라인보다 도구를 사용하며 판단하는 자율 에이전트를 선택했다.

3.2. 자율 에이전트를 택하게 한 계기

1. Anthropic Claude Agent SDK 워크숍

   1. 지난해 11월 뉴욕에서 열린 AI Engineer 행사에서 Anthropic의 Claude Agent SDK 워크숍을 들었다.
   2. 워크숍의 메시지는 모델이 매우 좋아졌기 때문에 이제는 워크플로보다 완전 자율 에이전트를 써볼 수 있다는 것이었다.
   3. Anthropic이 과거에는 에이전트를 피하고 단순하게 시작하라고 했던 것과 겉으로는 모순되어 보이지만, 모델의 발전에 따라 권장점이 바뀐 셈이다.
   4. Niels는 이 변화가 자신의 후속 대응 문제에 잘 맞는다고 보고 Claude Agent SDK를 사용했다.

2. Cursor의 코드 축소 사례

   1. 몇 달 뒤 런던에서 열린 유럽 AI Engineer 행사에서 Cursor의 발표도 참고했다.
   2. Cursor는 정교한 맞춤 워크플로 12,000줄을 매우 단순한 200줄짜리 스킬(skill)로 대체했다고 소개했다.
   3. Niels는 자신의 경험도 비슷하다고 말한다. 과거에는 수천 줄의 맞춤 코드가 필요했던 일을 이제 CLI 하나와 스킬 하나를 가진 에이전트로 처리할 수 있다.
   4. 모델이 충분히 좋아지면 코드 양 자체보다 에이전트가 쓸 수 있는 명확한 도구와 스킬의 설계가 중요해진다.

3.3. 후속 대응 에이전트의 구성

1. SDK와 모델

   1. 기반은 Python용 Claude Agent SDK다.
   2. 처음에는 Claude 모델을 사용했다.
   3. 발표 시점의 이번 주부터는 Hugging Face Inference Providers를 통해 GLM 5.2 모델을 사용한다고 밝혔다.
   4. Hugging Face Inference Providers는 Together AI, Fireworks, Cerebras 등 여러 추론 제공업체(inference provider)를 감싸서 통합된 방식으로 사용할 수 있게 한다.
   5. 서비스는 오픈 모델을 한곳에서 사용할 수 있게 하고, OpenAI 호환 또는 Anthropic 호환 인터페이스를 제공한다.

2. 도구와 스킬

   1. 에이전트의 주된 도구는 Bash, 즉 터미널이다.
   2. 터미널에서 Hugging Face CLI 명령을 실행해 모델·데이터 세트 상태를 확인하고 작업을 수행한다.
   3. Niels가 붙인 핵심 스킬은 Hugging Face CLI skill이며, 실제로 에이전트가 필요한 것은 이 CLI와 스킬 정도다.
   4. 에이전트는 GitHub에 후속 댓글을 달고 Hugging Face 내부 결과를 Slack에도 게시한다.

3. GLM 5.2를 선택한 이유

   1. 당시 GLM 5.2에 대한 관심이 높았다.
   2. Cursor의 CursorBench와 Post-training Bench 같은 평가에서 GLM 5.2가 Opus 4.8을 앞서는 결과가 소개됐고, 비용도 더 저렴하다고 했다.
   3. Niels는 Hugging Face에서 일한다는 점까지 고려하면 GLM 5.2를 쓰지 않을 이유가 없다고 농담 섞어 말한다.
   4. 다만 이 선택의 근거는 유행 자체가 아니라 실제 벤치마크 성능, 비용, Hugging Face의 오픈 모델 생태계라는 세 요소다.

3.4. Modal의 병렬 배치 실행

1. 컨테이너와 에이전트 루프

   1. 배포에는 Modal을 사용한다.
   2. Modal의 batch processing 기능은 대량의 컨테이너를 병렬로 띄울 수 있다.
   3. 컨테이너 하나가 GitHub 이슈 하나를 처리하는 에이전트 루프 하나에 해당한다.
   4. 따라서 수많은 후속 이슈를 서로 독립적으로 처리하면서도 전체 작업을 병렬화할 수 있다.

2. 백그라운드 작업에 맞는 운영 특성

   1. 사용법이 매우 쉽고 컨테이너 시작 속도도 빠르다고 Niels는 평가한다.
   2. 밤새 실행되는 백그라운드 에이전트처럼 대량의 독립 작업을 처리하는 용도에 적합하다.
   3. Modal 자체의 cron 기능으로 완전히 정기 배포할 수도 있지만, Niels는 현재 후속 처리를 수동으로 호출한다.

3. Cursor 스킬을 통한 수동 호출 루프

   1. Cursor에서 process under Modal이라는 스킬을 만들었다.
   2. Niels가 이 스킬을 호출하면 Composer 2.5가 상위 에이전트 역할을 한다.
   3. Composer 2.5가 Modal 위의 다른 에이전트들을 차례로 호출해 GitHub 이슈들을 처리한다.
   4. 이 상위 에이전트가 다시 에이전트들을 부르는 구조가 사람들이 말하는 에이전트 루프(agent loop)의 한 형태다.
   5. 모든 결과는 마지막에 Hugging Face Slack 채널에 게시된다.

4. 자동화가 만들어 낸 결과와 사람-에이전트 상호작용

4.1. Slack 결과와 Hub 색인

1. 논문과 산출물의 연결

   1. 자동화는 Hugging Face에서 공개할 만한 논문을 Slack에 대량으로 게시한다.
   2. 누군가 모델 카드나 데이터 세트 카드에서 논문을 언급하면 Hugging Face가 그 논문을 Hub에 색인한다.
   3. 에이전트가 GitHub outreach로 공개를 도운 모델·데이터 세트가 다시 논문과 연결되면서 연구의 발견 경로가 넓어진다.

2. 아직 남아 있는 수동 단계

   1. Niels는 현재 Cursor에서 스킬을 직접 호출한다.
   2. 호출 후 몇 분이 지나면 결과 메시지가 Hugging Face Slack 채널에 나타난다.
   3. 즉, 내부 결과 확인과 실행 시점 결정은 아직 사람에게 남아 있고, 대량 처리·댓글·업로드 안내가 에이전트의 몫이다.

4.2. 봇을 공개하지 않는 운영 판단

1. 정체를 밝히지 않는 이유

   1. Niels는 GitHub 이슈를 작성하는 주체가 에이전트라는 사실을 따로 밝히지 않는다.
   2. 사람들이 봇이라는 사실을 알면 이슈를 빠르게 닫아버릴 수 있다고 보기 때문이다.
   3. 에이전트가 올리는 내용은 Niels가 예전에 직접 작성하던 것과 정확히 같은 종류의 제안이므로, 내용 측면에서 숨길 이유가 없다고 판단한다.

2. 에이전트가 에이전트에게 답하는 인터넷

   1. 연구자들은 “제안과 명확한 안내에 감사한다”고 답한다.
   2. Niels는 때때로 상대방도 자신의 에이전트에게 답하기 위해 다른 에이전트를 사용하는 것을 본다.
   3. 사람의 outreach를 에이전트가 수행하고, 상대 연구자의 에이전트가 다시 답하는 모습은 “요즘 인터넷”이라는 웃긴 장면으로 제시된다.

4.3. 긍정적 반응과 부정적 반응의 비율

1. 수천 건 중 두 번의 부정적 반응

   1. 지금까지 Hugging Face에 만들어진 수천 건의 이슈 가운데 부정적인 댓글은 단 두 건뿐이었다.
   2. 한 사람은 “이 슬롭(slop)을 닫아 달라”고 말하고 이슈를 닫았다.
   3. 다른 사람을 포함한 대다수는 가중치나 데이터 세트를 Hugging Face에 공개하는 것이 합리적이라고 답했다.
   4. “왜 이런 생각을 진작 하지 못했을까?”라는 반응도 많았다.

2. 윈윈이 확인되는 조건

   1. 연구자는 저장소를 새로 설계하지 않고도 자신의 결과를 더 넓은 사용자에게 공개할 수 있다.
   2. 사용자는 문서화되고 검색 가능한 모델·데이터 세트를 얻는다.
   3. 이슈 자체가 목적이 아니라 산출물의 공개·문서화·발견 가능성 개선으로 이어질 때 자동 outreach가 유용해진다.

4.4. 실제로 관찰한 사례들

1. Apple·Google DeepMind와 대용량 데이터 세트

   1. 한 Apple 연구자가 Niels에게 직접 메시지를 보내 “연락을 받은 것을 보았다”고 알렸다.
   2. 실제로는 Niels가 직접 이슈를 쓴 것이 아니라 에이전트가 Apple 논문의 산출물을 Hugging Face에 공개하자고 제안한 것이었다.
   3. 에이전트는 Google DeepMind에도 연락해 수학 데이터 세트를 공개하도록 제안했다.
   4. Niels가 받은 이메일 중에는 Hugging Face에 400GB 데이터 세트를 공개하고 싶다는 내용도 있었는데, 이 역시 그가 직접 시작한 대화가 아니라 에이전트가 연 GitHub 이슈에서 출발했다.

2. PaddleOCR의 이전

   1. PaddleOCR은 중국 기업의 OCR 프로젝트다.
   2. 에이전트가 생성한 이슈를 통한 outreach를 계기로 PaddleOCR 팀은 OCR 모델을 모두 Hugging Face로 옮겼다.
   3. 한 번의 자동화된 제안이 특정 모델 하나가 아니라 프로젝트 전체의 공개 경로를 바꿀 수 있음을 보여준다.

3. 모델 카드 템플릿 자동 완성

   1. Hugging Face에는 모델을 올릴 때 사용할 수 있는 기본 모델 카드 템플릿이 있다.
   2. Hugging Face의 Mac Mitchell은 모델을 제대로 기록해야 한다는 「Model Cards for Model Reporting」 논문으로 잘 알려져 있다.
   3. 에이전트는 논문, GitHub README, PDF 등에서 내용을 찾아 기본 템플릿의 빈칸을 채운다.
   4. 어떤 모델 카드에는 “모델 카드 작성자: Hugging Face 커뮤니티 과학 팀의 Niels”라는 문구까지 스스로 넣었다.
   5. Niels가 그렇게 쓰라고 프롬프트한 적은 없었고, 그 결과를 재미있게 받아들인다.
   6. 연구자가 “실수를 고치도록 도와줘서 고맙다”고 답한 사례도 있다.

4. Tiny Recursive Models의 반응

   1. 가장 인기 있었던 GitHub 이슈 중 하나는 당시 Hugging Face와 Twitter에서 모두 화제가 된 「Tiny Recursive Models」 논문이었다.
   2. 그 이슈에는 60명이 넘는 사람이 추천(upvote)했다.
   3. 추천의 의미는 모델이 Hugging Face에 공개되기를 바란다는 것이었다.
   4. 연구자는 자신의 연구를 더 쉽게 발견하게 되고, 다른 사람은 그 연구 위에 새로운 작업을 만들 수 있으므로 다시 한 번 양쪽의 이익이 맞물린다.

4.5. 슬롭을 피하기 위한 평가

1. 자동화의 위험 질문

   1. 수백 건의 이슈를 만들고 인터넷 곳곳에 게시하는 에이전트는 유용한 outreach와 스팸의 경계에 설 수 있다.
   2. “에이전트가 인터넷 전체에 GitHub 이슈를 뿌리는 것이 정말 괜찮은가?”라는 질문이 생긴다.
   3. Niels는 자신의 사례가 실제 산출물 공개로 이어지는 윈윈이라는 점을 강조하지만, 결과가 좋다는 주장만으로 자동화의 품질이 보장되지는 않는다.

2. 추천 자료와 평가의 필요성

   1. Niels는 Hamel Husain의 「LLM Evils FAQ」 블로그 글을 강하게 추천한다.
   2. Hamel Husain은 LLM 평가 분야의 핵심 전문가로 소개된다.
   3. 유료 강의도 운영하지만 무료로 공개하는 자료도 많으며, 해당 글을 통해 에이전트를 어떻게 평가할지 배울 수 있다.
   4. 자동화 규모가 커질수록 성공한 사례를 모으는 것뿐 아니라 잘못된 이슈, 불필요한 댓글, 부정적 반응을 측정하고 줄이는 평가 체계가 필수다.

5. 발표자가 제시한 결론: 오픈 모델과 에이전트의 실용성

5.1. 오픈 모델의 성능 상승

1. 폐쇄형 모델 대체 가능성

   1. GLM 5.2와 DeepSeek V4 같은 오픈 모델의 성능이 크게 좋아지고 있다.
   2. 특정 업무에서는 폐쇄형 모델을 오픈 모델로 대체할 수 있는 수준에 도달했다.
   3. 제공업체를 통합하는 Hugging Face Inference Providers 덕분에 여러 모델과 인프라를 한 인터페이스로 실험할 수 있다.

2. 비용과 생태계의 결합

   1. GLM 5.2는 발표자가 언급한 벤치마크에서 Opus 4.8보다 좋은 성능을 보이면서 더 저렴하다고 제시됐다.
   2. 대량의 야간 작업에서는 모델 비용과 병렬 실행 비용이 운영 규모에 직접 영향을 준다.
   3. 따라서 오픈 모델의 성능 향상은 단순한 모델 선택 문제가 아니라, 대규모 에이전트 운영의 경제성을 바꾸는 요인이다.

5.2. 이 사용 사례에서 에이전트가 워크플로보다 나은 이유

1. 후속 대화의 변동성

   1. 논문 저자의 답변은 공개 완료, 문서 수정, 대용량 업로드, 추가 질문처럼 매번 다르게 전개된다.
   2. 도구를 호출하고 현재 상태를 확인하며 다음 행동을 고르는 루프가 고정된 단계보다 이 변동성에 잘 맞는다.
   3. 반대로 논문을 정해진 순서로 스캔하고 Hub 상태를 확인하는 초기 단계에는 결정적 워크플로가 적합했다.

2. 최소 구성

   1. Niels의 결론에서 후속 에이전트에 필요한 것은 Hugging Face CLI 하나, 그 CLI를 쓰는 스킬 하나, 샌드박스(sandbox) 하나다.
   2. 복잡한 에이전트 프레임워크나 수천 줄의 맞춤 코드를 반드시 깔아야 하는 것은 아니다.
   3. 단, 단순한 구성은 평가를 생략해도 된다는 뜻이 아니다. 발표의 마지막 경고는 “평가를 잊지 말라”는 것이다.

6. 커뮤니티 과학 팀의 다른 자동화 노력

6.1. Daily Papers 계정

1. 동일한 워크플로의 소셜 배포

   1. Niels는 X(당시 Twitter)에 Daily Papers라는 계정을 만들었다.
   2. 이 계정은 GitHub outreach 자동화와 똑같은 워크플로를 내부적으로 사용한다.
   3. 흥미로운 연구 논문과 Hugging Face 산출물을 X에 자동으로 게시한다.

2. 운영 규모와 성장

   1. Daily Papers는 발표 시점에 팔로워 90,000명을 넘었다.
   2. Niels가 직접 운영에 개입하지 않아도 자동으로 게시된다.
   3. 4시간마다 또는 Hugging Face에서 흥미로운 산출물이 공개될 때마다 게시한다.

3. 이미지 선택과 반응

   1. Gemini가 게시물에 넣을 가장 좋은 시각 자료를 고른다.
   2. 예시로 Nvidia가 GLM 5.2의 최적화 버전을 공개했다는 최근 게시물이 소개됐다.
   3. 해당 게시물은 2,000개가 넘는 좋아요를 받았고, 자동화된 연구 큐레이션이 큰 반응을 만들 수 있음을 보여줬다.

6.2. Papers With Code의 부활

1. 서비스의 역사와 재건

   1. Papers With Code는 한때 존재했던 연구 검색·벤치마크 사이트다.
   2. Meta에 인수된 뒤 안타깝게도 서비스가 사실상 사라졌다.
   3. Niels는 연구와 최신 상태(state of the art)를 더 쉽게 접근할 수 있도록 서비스를 되살리려 하고 있다.
   4. 새 사이트는 현재 paperswithcode.co에 있다.

2. 벤치마크와 교육 자료

   1. 사이트에서 OCR 모델 같은 분야의 벤치마크를 확인할 수 있다.
   2. OCR에 관한 인기 벤치마크들을 모아 모델 간 성능을 비교할 수 있게 한다.
   3. 단순한 순위표를 넘어 mixed training, on-policy distillation 같은 기술 용어를 배울 수 있는 교육 자원으로도 만들고 있다.
   4. 연구 결과를 저장하는 것뿐 아니라 연구를 이해하는 데 필요한 개념과 상태를 함께 제공하려는 방향이다.

주요 발언 모음

“오늘은 에이전트를 사용해 Hugging Face에서 내 업무를 어떻게 자동화하는지 이야기하겠습니다.”

“커뮤니티 과학 팀은 Google Drive에서 Hub로 옮기는 팀이라고도 설명할 수 있습니다.”

“정말 필요하지 않다면 에이전트를 만들지 말고, 단일 LLM API로 단순하게 시작하며, 프레임워크를 피하세요.”

“모델이 아주 좋아졌기 때문에 이제는 워크플로 대신 완전 자율 에이전트와 함께 일하기 시작할 수 있습니다.”

“요즘은 수천 줄의 맞춤 코드를 간단한 에이전트, CLI 하나, 스킬 하나로 대체할 수 있습니다.”

“사람들이 봇이라는 사실을 알면 이슈를 빨리 닫을 수도 있습니다.”

“사람들이 내 에이전트에게 답하기 위해 에이전트를 사용하는 것도 자주 봅니다. 요즘 인터넷이란 그런 것입니다.”

“에이전트가 슬롭을 게시하지 않게 하려면 평가를 배워야 합니다.”

“오픈 모델은 특히 지금 아주 좋아지고 있습니다. GLM 5.2와 DeepSeek V4 같은 모델이 있습니다.”

“에이전트에는 Hugging Face CLI 하나, Hugging Face CLI 스킬 하나, 그리고 샌드박스만 있으면 됩니다.”

“평가를 잊지 마세요.”

핵심 데이터 & 수치

• Hugging Face 근무 기간: Niels는 머신러닝 엔지니어로 5년째 근무 중이라고 소개했다.
• 자동화 시작 시점: 초기 결정적 워크플로는 2024년에 만들었다.
• 실행 주기: 첫 번째 Python cron job은 매일 밤 한 번 실행된다.
• 처리량: 매일 수백 편의 arXiv 논문을 읽고 수백 건의 GitHub 이슈를 생성한다.
• 맞춤 코드 축소 사례: Cursor는 12,000줄의 정교한 워크플로를 200줄짜리 스킬로 바꾼 사례를 소개했다.
• 병렬 단위: Modal 컨테이너 하나가 GitHub 이슈 하나를 처리하는 에이전트 루프 하나에 대응한다.
• 부정적 반응: 수천 건의 자동 생성 이슈 가운데 부정적인 댓글은 지금까지 두 건이었다.
• 대용량 산출물: 한 연구자는 400GB 데이터 세트를 Hugging Face에 공개하고 싶다고 연락했다.
• Tiny Recursive Models: 관련 GitHub 이슈에 60명이 넘는 사용자가 upvote했다.
• Daily Papers: 자동 X 계정이 팔로워 90,000명을 넘었다.
• Daily Papers 게시 빈도: 4시간마다 또는 새로운 흥미로운 Hub 산출물이 공개될 때 게시한다.
• 소셜 반응: Nvidia의 최적화된 GLM 5.2 관련 게시물은 2,000개가 넘는 좋아요를 받았다.
• 모델 비교: 발표자는 CursorBench와 Post-training Bench에서 GLM 5.2가 Opus 4.8을 앞서고 비용도 더 낮다고 언급했다.
• 연구 공개 경로: 예시로 PaddleOCR의 OCR 모델 전체가 에이전트 outreach 이후 Hugging Face로 이전됐다.

결론 및 시사점

1. 반복적인 오픈소스 outreach는 연구자의 의사결정이 아니라 탐색·상태 확인·템플릿 작성·알림 처리의 문제이므로 자동화하기 좋은 업무다.
2. 논문 탐색과 Hub 상태 확인처럼 경로가 안정적인 부분에는 결정적 워크플로를 사용하고, 저자 답변에 따라 행동이 달라지는 후속 대응에는 자율 에이전트를 사용하는 조합이 현실적이다.
3. 2024년의 “단일 LLM API로 시작하고 프레임워크를 피하라”는 원칙과 최신의 “에이전트가 워크플로보다 낫다”는 주장은 경쟁하지 않는다. 모델 능력과 업무의 변동성이 달라지면 적합한 추상화도 달라진다.
4. 에이전트의 능력은 거대한 도구 목록보다 Hugging Face CLI처럼 실제 업무를 수행하는 하나의 강력한 인터페이스와 이를 사용하도록 설명한 스킬의 품질에 좌우될 수 있다.
5. Modal의 빠른 병렬 컨테이너는 야간 대량 처리에 적합하지만, 각 컨테이너가 독립적으로 외부에 글을 남기므로 실행 권한과 샌드박스를 제한해야 한다.
6. Langfuse 같은 tracing 도구로 프롬프트·입출력·비용·지연 시간을 기록하면 “자동화가 됐다”는 느낌을 측정 가능한 운영 데이터로 바꿀 수 있다.
7. 사람에게 같은 안내를 반복하는 일을 에이전트가 대신하더라도, 상대방의 선택권과 이슈의 맥락을 존중해야 하며 자동 게시량만 성공 지표로 삼으면 안 된다.
8. 수천 건 중 두 건의 부정적 반응, PaddleOCR 전체 이전, Tiny Recursive Models의 60건 이상 upvote는 이 사례가 단순한 메시지 발송을 넘어 실제 공개 행동을 유도했음을 보여준다.
9. 반대로 봇임을 공개하지 않는 판단은 투명성·신뢰·플랫폼 규범과 충돌할 수 있으므로, 다른 조직에 적용할 때는 고지 정책과 사람 검토 기준을 별도로 설계해야 한다.
10. 오픈 모델 성능과 추론 제공업체의 통합이 개선되면 비용이 큰 반복 업무를 폐쇄형 모델에만 의존할 필요가 줄어든다.
11. 에이전트 배포의 최소 단위는 모델, CLI, 스킬, 샌드박스, 평가 세트이며, 이 중 평가를 빼면 확장된 자동화가 확장된 스팸이 될 수 있다.
12. Daily Papers와 Papers With Code 부활 사례는 같은 파이프라인을 GitHub outreach, 소셜 큐레이션, 연구 지식 인프라로 재사용할 수 있음을 보여준다.
13. 최종적으로 자동화의 가치는 사람의 이름을 흉내 내는 데 있지 않고, 흩어진 연구 산출물을 더 발견 가능하고 문서화되고 재사용 가능한 형태로 연결하는 데 있다.

핵심 요약 (20줄)

• Niels Rogge는 Hugging Face의 커뮤니티 과학 팀에서 연구 산출물의 공개와 발견 가능성을 높이는 일을 맡고 있다.
• 연구자들은 모델 가중치와 데이터 세트를 Google Drive, GitHub Releases, Dropbox, Zenodo 등에 흩어 놓는 경우가 많다.
• Hugging Face Hub의 논문 페이지는 논문과 연결된 모델·데이터 세트를 한 화면에서 찾게 한다.
• 메타데이터 태그와 필터는 작업 유형, 언어, 호환 라이브러리에 따라 산출물을 검색하게 한다.
• 모델 카드와 데이터 세트 카드는 산출물의 사용법과 한계를 기록해 재현성을 높인다.
• Niels는 연구자에게 공개를 요청하는 GitHub 이슈와 문서화를 개선하는 Pull Request를 반복해서 작성했다.
• 매일 수백 편의 arXiv 논문이 나오므로 사람이 모든 outreach를 처리하는 방식은 확장되지 않는다.
• 초기 자동화는 논문 탐색부터 GitHub README 분석과 Hub 상태 확인까지 수작업 순서를 복제한 결정적 워크플로였다.
• 2024년 워크플로는 단일 LLM API로 시작하고 불필요한 에이전트 프레임워크를 피하라는 Anthropic의 조언을 따랐다.
• GitHub Actions의 매일 밤 cron job은 수백 편의 논문을 읽고 이슈나 Pull Request를 만들었다.
• Langfuse는 자동화의 입력, 출력, 프롬프트, 비용, 지연 시간을 추적하는 관측 도구로 사용됐다.
• 이슈 생성 뒤 쌓인 대량의 답변과 알림을 처리하기 위해 후속 대응은 자율 에이전트로 전환됐다.
• Claude Agent SDK와 Modal은 GitHub 이슈별 에이전트 루프를 병렬 실행하는 기반이 됐다.
• 후속 에이전트는 Hugging Face CLI와 전용 스킬을 사용해 GitHub 댓글과 Slack 결과를 처리한다.
• 발표 시점에는 Hugging Face Inference Providers를 통해 GLM 5.2를 사용했고 여러 추론 제공업체를 통합할 수 있었다.
• GLM 5.2는 발표자가 언급한 벤치마크에서 Opus 4.8보다 좋은 성능과 낮은 비용을 보였다.
• 수천 건의 이슈 가운데 부정적 반응은 두 건뿐이었고 PaddleOCR 모델 전체 이전 같은 결과가 나왔다.
• Tiny Recursive Models 관련 이슈는 60명이 넘는 upvote를 얻어 연구 공개 수요를 드러냈다.
• Daily Papers 계정은 90,000명 넘는 팔로워에게 4시간마다 연구와 Hub 산출물을 자동 공유했다.
• 에이전트의 규모 있는 자동화에는 최소 도구보다 평가, 샌드박스, 투명한 운영 기준이 더 중요하다.