에이전트로 Hugging Face 업무를 자동화한 방법

URL: https://www.youtube.com/watch?v=E3eh0GQLH0Q 날짜: 2026-08-21 (실제 업로드 날짜) 처리일: 2026-08-22 채널: Tech Bridge 발표자: Niels 원문 제목: [한영자막] 에이전트로 Hugging Face 업무를 자동화한 방법 영상 길이: 20분 5초

---

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

Hugging Face의 커뮤니티 사이언스(Community Science) 업무처럼 매일 쏟아지는 연구 논문을 살펴보고, 연구자에게 모델·데이터셋 공개를 제안하고, 문서화를 돕고, 답변까지 이어 가는 일을 어떻게 에이전트로 확장할 수 있을까? ==정답은 한 가지 형태의 에이전트가 아니라, 업무의 예측 가능성과 유연성에 맞춰 결정론적 워크플로와 자율 에이전트를 조합하는 것이다.==

• Niels는 먼저 자신이 하던 수작업을 그대로 복제한 결정론적 워크플로로 논문 탐색·GitHub 이슈·Hugging Face PR 생성을 자동화했다.
• 밤마다 수백 편의 arXiv 논문을 처리하고, 수백 건의 GitHub 이슈를 만들 수 있게 되면서 후속 답변 업무도 병목이 되었다.
• 후속 업무에는 Claude Agents SDK 기반의 자율 에이전트를 적용하고, Hugging Face CLI 하나와 CLI 스킬 하나를 중심으로 Modal에서 병렬 실행했다.
• 연구자들은 외부 저장소에 흩어져 있던 모델과 데이터셋을 Hugging Face Hub로 옮겨 발견 가능성과 재현성을 높이고, 다른 개발자는 더 쉽게 연구 결과를 활용하게 되었다.
• 자동화가 스팸(sl​​op)이 되지 않으려면 실제로 유용한 상호 이익을 만들고, LLM 평가를 통해 에이전트의 결과를 점검해야 한다.

커뮤니티 사이언스 팀은 Google Drive, GitHub Releases, Dropbox, Zenodo 같은 곳에 흩어진 연구 산출물을 중앙화된 Hugging Face Hub로 가져오도록 돕는다. 논문과 연결된 모델·데이터셋, 모델 카드와 데이터셋 카드, 메타데이터 태그가 한곳에 모이면 연구자는 작업을 더 잘 알릴 수 있고, 다른 사람은 논문을 재현하거나 그 결과 위에 새로운 제품과 연구를 만들 수 있다. 수작업으로는 AI 붐과 대형 학회가 만들어 내는 논문량을 감당할 수 없으므로, Niels는 결정론적 파이프라인과 자율 후속 에이전트를 단계적으로 도입했다.

1. 발표자와 커뮤니티 사이언스 팀의 출발점

커뮤니티 사이언스 팀의 자동화는 연구자들이 만든 모델과 데이터셋이 여러 외부 서비스에 묻혀 발견되지 않는 문제에서 출발했다.

1.1. Niels의 배경과 발표 범위

1. Niels의 경력
   1. Niels는 벨기에 출신이며, 벨기에는 맥주·감자튀김·초콜릿의 나라라고 짧게 자신을 소개했다.
   2. KU Leuven에서 공부했고, Hugging Face에서 5년째 머신러닝 엔지니어(Machine Learning Engineer)로 일하고 있다.
2. 이야기의 세 부분
   1. 자신이 속한 Hugging Face 커뮤니티 사이언스 팀이 무엇을 하는지 소개한다.
   2. 커뮤니티 사이언스 팀 업무의 큰 부분을 어떻게 자동화했는지 보여 준다.
   3. 같은 팀에서 진행하는 다른 자동화·연구 발견 프로젝트도 간단히 공유한다.

1.2. 외부 저장소에 흩어진 연구 산출물

1. GitHub에서 발견한 문제
   1. Niels는 GitHub를 보다가 트렌드가 되는 새로운 연구를 자주 발견했다.
   2. 흥미로운 연구를 찾았을 때 정작 모델 가중치(weights)가 Hugging Face에 없는 경우가 많았다.
   3. 연구자들은 가중치와 데이터셋을 Google Drive, GitHub Releases, Dropbox, Zenodo 또는 다른 서버에 올리고 있었다.
2. 발견 가능성의 손실
   1. 외부 서비스에 산출물이 흩어지면 연구 결과를 찾기가 어려워진다.
   2. 논문을 읽은 사람이 모델이나 데이터셋까지 자연스럽게 발견하기 어렵고, 연구 작업의 가시성(discoverability)이 떨어진다.
   3. Niels가 GitHub 이슈를 열어 “가중치를 Hugging Face에 무료로 공개할 수 있다”고 제안하면, 많은 연구자가 “Google Drive에서 Hugging Face로 옮기는 것이 실제로 말이 된다”고 답했다.

1.3. “Google Drive to the Hub” 팀

1. 팀의 별칭
   1. 커뮤니티 사이언스 팀은 농담 섞어 “Google Drive to the Hub 팀”이라고도 설명할 수 있다.
   2. 여기서 Hub는 모델·데이터셋·논문 산출물을 모으는 Hugging Face Hub다.
2. 논문 페이지와 연결된 산출물
   1. Hugging Face에는 arXiv에서 가져온 논문 페이지가 있다.
   2. 논문 페이지 오른쪽에는 논문과 연결된 모델이나 데이터셋 같은 아티팩트(artifact)를 나열할 수 있다.
   3. 사용자는 논문에서 관련 모델과 데이터셋으로 이동해 연구를 재현하거나, 실제 결과물을 찾아볼 수 있다.
3. 메타데이터를 통한 검색
   1. Hugging Face 앱에는 메타데이터 태그와 필터가 있다.
   2. 사용자는 깊이 추정(depth estimation) 모델처럼 특정 작업의 모델을 찾을 수 있다.
   3. 관심 있는 대규모 언어 모델(LLM)을 찾거나, 언어와 호환 라이브러리로 필터링할 수도 있다.
   4. 모델과 데이터셋에 정확한 태그를 붙일수록 연구 산출물의 발견 가능성이 높아진다.

1.4. 연구자와 사용자 모두에게 돌아가는 이익

1. 중앙화된 머신러닝 아티팩트
   1. Hugging Face는 연구자가 외부 서비스마다 따로 올리던 머신러닝 아티팩트를 찾을 수 있는 중앙 플랫폼이다.
   2. 한곳에 모이면 다른 사람이 연구 결과를 찾고 활용하기가 쉬워진다.
2. 문서화 지원
   1. 모델 카드(model card)나 데이터셋 카드(dataset card)를 추가해 산출물의 사용법과 맥락을 문서화할 수 있다.
   2. 커뮤니티 사이언스 팀은 이미 존재하는 산출물에 카드와 메타데이터를 보완하는 PR(p​​ull request)도 만든다.
3. 도구와 홍보
   1. Hugging Face의 도구를 이용하면 파일을 업로드하거나 다운로드하기가 쉽다.
   2. 연구자는 자신의 연구를 더 널리 알릴 수 있고, 연구를 사용하는 사람은 문서화된 모델과 데이터셋을 더 쉽게 활용할 수 있다.
   3. 따라서 연구자와 연구 사용자 모두에게 이익이 되는 윈윈(win-win) 구조가 된다.

2. 수작업 아웃리치의 한계와 자동화 대상

Niels는 매번 비슷한 GitHub 이슈와 PR을 직접 만들고 있었지만, 논문 수가 급증하면서 같은 패턴의 일을 수작업으로 반복할 수 없게 되었다.

2.1. 반복하던 GitHub 이슈와 PR

1. 고정된 이슈 템플릿
   1. Niels는 보통 “이 체크포인트(checkpoint)를 Hugging Face에 공개해 주실 수 있나요?”라고 물었다.
   2. 데이터셋일 때는 “이 데이터셋을 Hugging Face에 공개해 주실 수 있나요?”라고 요청했다.
   3. 매번 거의 같은 템플릿으로 연구자에게 산출물 공개를 제안했다.
2. 문서화를 위한 PR
   1. 산출물이 이미 Hugging Face에 있더라도 모델 카드나 데이터셋 카드가 부실할 수 있었다.
   2. Niels는 Hugging Face에 PR을 열어 카드와 문서를 보완했다.
   3. 이슈 작성과 PR 생성 모두 연구자에게 실제로 유용하지만, 건별로 사람이 처리해야 한다는 문제가 있었다.

2.2. AI 붐이 만든 규모의 문제

1. 매일 늘어나는 논문
   1. AI 붐으로 arXiv에는 매일 수백 편의 연구 논문이 나온다.
   2. NeurIPS 같은 주요 AI 학회도 엄청난 양의 논문을 만들어 낸다.
2. 수작업의 비확장성
   1. 논문마다 GitHub 저장소를 찾고 README를 읽고 산출물을 확인하는 일은 반복적이다.
   2. 논문 수가 수백 편으로 늘면 Niels 혼자 모든 연구자에게 GitHub 이슈를 열거나 PR을 만들 수 없다.
   3. “커뮤니티 사이언스 팀을 에이전트로 확장할 수 있을까?”라는 질문이 자동화의 출발점이 되었다.

2.3. 자동화해야 할 원래의 업무 흐름

1. 논문과 코드 저장소 확인
   1. 연구 논문을 발견하면 먼저 해당 논문의 GitHub URL이 있는지 찾는다.
   2. GitHub URL이 있으면 README 파일을 읽어 연구자가 무엇을 공개했는지 파악한다.
2. Hugging Face 상태 점검
   1. README와 논문을 바탕으로 Hugging Face에서 새롭게 공유할 만한 모델이나 데이터셋이 있는지 확인한다.
   2. 산출물이 이미 Hugging Face에 있다면 모델 카드와 데이터셋 카드가 제대로 작성되어 있는지 살핀다.
   3. 메타데이터 태그가 붙어 있는지, 모델이나 데이터셋을 찾을 때 필요한 정보가 들어 있는지도 확인한다.
3. 상황별 조치
   1. 이미 산출물이 있고 카드·메타데이터가 부족하면 PR을 연다.
   2. 산출물이 아직 Hugging Face에 없으면 연구자의 GitHub 저장소에 이슈를 연다.
   3. 마지막으로 연구자에게 후속 연락(follow-up)을 한다.
   4. 이 탐색·검증·이슈·PR·후속 연락의 전체 흐름이 에이전트로 옮겨야 할 업무였다.

3. 워크플로와 자율 에이전트 사이의 설계 선택

업무 자동화에는 정해진 순서의 워크플로와 도구를 반복 호출하는 자율 에이전트가 모두 가능하다. Niels는 시점과 업무 성격에 따라 두 방식을 다르게 선택했다.

3.1. 결정론적 워크플로

1. 구조
   1. Anthropic의 “Building effective agents” 블로그 글에 나온 도식처럼, 워크플로는 미리 정해진 경로 또는 파이프라인의 각 단계에서 LLM API를 호출한다.
   2. 논문 탐색, README 읽기, Hugging Face 상태 점검, 이슈·PR 생성처럼 단계가 명확한 업무를 순서대로 처리한다.
2. 장점과 한계
   1. 미리 정의한 경로를 따르기 때문에 동작이 예측 가능하다.
   2. 실행을 세밀하게 통제할 수 있다.
   3. 대신 정해진 경로 밖의 상황에 대응하는 유연성은 떨어진다.

3.2. 완전 자율 에이전트

1. 구조
   1. 자율 에이전트는 LLM이 루프 안에서 도구를 호출한다.
   2. 작업이 끝날 때까지 파일을 읽거나 명령을 실행하거나 외부 서비스에 요청하는 과정을 스스로 이어 간다.
2. 장점과 한계
   1. 미리 모든 경로를 코드로 작성하지 않아도 되므로 유연하다.
   2. 반대로 LLM이 매번 어떤 도구를 어떤 순서로 호출할지 완전히 예측하기 어렵다.
   3. 따라서 워크플로보다 통제력이 낮고, 잘못된 행동을 평가·제한하는 장치가 필요하다.
3. 이분법이 아닌 스펙트럼
   1. 워크플로와 완전 자율 에이전트 중 하나만 골라야 하는 것은 아니다.
   2. 업무의 일부는 결정론적 단계로 고정하고, 다른 일부는 자율 에이전트로 처리하는 식으로 두 방식을 섞을 수 있다.

3.3. 2024년의 첫 선택: 단순한 워크플로

1. Anthropic의 당시 조언
   1. Niels가 처음 시스템을 만들던 시점은 2024년이었다.
   2. 당시 Anthropic은 “정말 필요하지 않다면 에이전트를 만들지 말라”고 조언했다.
   3. 단일 LLM API로 단순하게 시작하고, 에이전트 프레임워크를 피하라고 권했다.
2. 수작업 복제
   1. Niels는 이 조언을 좋은 팁으로 받아들였다.
   2. 자신이 수작업으로 하던 아웃리치 절차를 그대로 복제하는 워크플로부터 만들었다.
   3. 각 단계에서 LLM API를 호출하되 에이전트 프레임워크는 사용하지 않았다.
3. 시각화와 통제
   1. 파이프라인 그림은 Excalidraw MCP 서버와 Cursor로 만들었다.
   2. 코드가 수행하는 일을 시각화하기에 편리했고, 발표에서는 그림의 세부 구현까지 들어가지는 않았다.
   3. 프레임워크 없이 각 단계의 입력·출력과 순서를 정해 두었기 때문에 시스템이 결정론적이고 통제하기 쉬웠다.

4. 첫 번째 자동화 파이프라인의 운영

결정론적 파이프라인은 밤새 논문을 처리하는 Python 스크립트와 GitHub Actions, 그리고 LLM 동작을 관찰하는 LangFuse로 운영되었다.

4.1. 밤마다 실행되는 크론 작업

1. 운영 방식
   1. 배포는 단순한 크론 작업(cron job)이다.
   2. 크론은 정기적으로 명령을 실행하는 기능이며, Niels는 이 작업을 매일 밤 한 번 실행했다.
   3. Niels가 잠든 동안 Python 스크립트가 LLM API를 호출한다.
2. 처리 대상과 결과
   1. 스크립트는 arXiv에서 나온 수백 편의 논문을 읽고 앞서 정한 파이프라인을 실행한다.
   2. 필요할 때 연구자의 GitHub 저장소에 이슈를 연다.
   3. Hugging Face에 모델·데이터셋 카드와 메타데이터를 보완하는 PR도 연다.

4.2. GitHub Actions 배포

1. 선택 이유
   1. Niels는 이 크론 작업에 GitHub Actions를 사용했다.
   2. GitHub Actions는 주기적으로 실행하는 간단한 작업을 올리기 좋은 환경이다.
2. 추천 자료와 운영 편의성
   1. “Free cron jobs with GitHub Actions”라는 블로그 글을 시작점으로 추천했다.
   2. GitHub는 시작할 때 사용할 수 있는 무료 사용량이 꽤 넉넉하다.
   3. 여러 크론 작업을 웹 UI에서 관리하기도 쉽다.
3. 규모
   1. 결과적으로 매일 밤 수백 건의 GitHub 이슈가 자동으로 만들어진다.
   2. 생성 단계는 자동화되었지만, 연구자가 이슈에 답한 뒤의 후속 대응은 새 병목으로 남았다.

4.3. LangFuse 기반 추적과 관측성

1. 무엇을 관찰하는가
   1. Niels는 추적(tracing)에 LangFuse를 사용한다.
   2. LangChain도 좋지만, 이 용도에서는 주로 LLM 동작의 관측성(observability)을 확인하는 데 LangFuse를 활용한다.
   3. 어떤 입력이 들어갔는지, 어떤 출력이 나왔는지, 어떤 프롬프트가 사용됐는지 확인할 수 있다.
2. 운영 지표
   1. 호출 비용(cost)을 확인한다.
   2. 지연 시간(latency)을 확인한다.
   3. 호출 흐름과 프롬프트를 함께 살펴보며 자동화가 의도대로 동작하는지 점검한다.
   4. Niels는 에이전트나 LLM 시스템을 운영한다면 이런 추적 도구를 권장했다.

5. GitHub 후속 대응을 자율 에이전트로 전환

밤마다 수백 건의 이슈가 생성되자, 연구자의 답변으로 쌓이는 GitHub 알림을 읽고 대응하는 작업이 새로운 우선순위가 되었다.

5.1. 수백 건의 답변이 만든 두 번째 병목

1. 알림의 폭증
   1. 자동화된 에이전트가 매일 많은 GitHub 이슈를 열면 연구자들이 이슈에 답한다.
   2. Niels의 GitHub 알림함에는 읽지 않은 알림이 대량으로 쌓였다.
   3. 이슈마다 답변을 확인하고 필요한 조치를 하는 일은 이메일함을 처리하는 것과 비슷한 부담이 되었다.
2. 단계별 자동화
   1. 처음에는 이슈 생성만 에이전트가 하고 후속 대응은 Niels가 직접 했다.
   2. 몇 달 전부터 후속 대응까지 자동화했다.
   3. 이 단계에서는 고정 워크플로 대신 좀 더 자율적인 에이전트를 선택했다.

5.2. Claude Agents SDK를 선택한 이유

1. 새로운 Anthropic의 메시지
   1. 전년도 11월 뉴욕에서 열린 AI Engineer 행사에서 Anthropic의 Claude Agents SDK 워크숍이 있었다.
   2. 그 자리에서는 에이전트가 워크플로보다 나을 수 있다는 취지의 설명이 나왔다.
   3. 예전에 “에이전트를 피하라”고 하던 조언과는 다소 모순되지만, 모델이 충분히 좋아졌으므로 완전 자율 에이전트를 사용할 시점이 되었다는 판단이었다.
2. 구현
   1. Niels는 후속 대응에 Claude Agents SDK를 사용했다.
   2. 이 SDK는 Python으로 에이전트를 만들기 위한 도구다.
   3. 에이전트는 GitHub 이슈를 읽고, 필요한 Hugging Face CLI 명령을 실행하고, 후속 댓글을 달고, 결과를 정리한다.

5.3. 12,000줄에서 200줄로 줄어든 에이전트 구현

1. Cursor의 사례
   1. 런던에서 열린 유럽판 AI Engineer 행사에서 Cursor가 발표한 사례도 영향을 주었다.
   2. Cursor는 정교한 커스텀 워크플로를 약 12,000줄의 코드로 운영하고 있었다.
   3. 이를 단순한 200줄짜리 스킬(skill)로 교체했다고 설명했다.
2. Niels의 유사한 경험
   1. Niels도 수천 줄의 커스텀 코드를 오늘날에는 단순한 에이전트로 대체할 수 있다고 보았다.
   2. 에이전트에 CLI를 도구로 제공하고 스킬을 붙이는 정도면 같은 일을 수행할 수 있었다.
   3. 모델 성능이 좋아졌기 때문에 과거에 직접 구현하던 분기와 로직이 크게 줄었다.

6. 후속 에이전트의 아키텍처와 모델 선택

후속 대응 에이전트는 Claude Agents SDK, Hugging Face 추론 제공자, Modal, Bash 기반 Hugging Face CLI, CLI 스킬, GitHub와 Slack을 연결한다.

6.1. Hugging Face 추론 제공자를 통한 모델 교체

1. 사용 모델의 변화
   1. 처음에는 Claude 모델을 사용했다.
   2. 발표 시점의 바로 이번 주부터는 Hugging Face Inference Providers를 통해 GLM 5.2를 사용하고 있다고 말했다.
2. 통합 서비스
   1. Hugging Face의 추론 서비스는 Together.ai, Fireworks, Cerebras 등 여러 추론 제공자를 하나의 방식으로 감싼다.
   2. 여러 오픈 모델을 통일된 인터페이스로 사용할 수 있다.
   3. 인터페이스는 OpenAI 호환 또는 Anthropic 호환 방식으로 제공된다.
3. GLM 5.2를 고른 근거
   1. GLM 5.2는 당시 큰 관심을 받고 있었다.
   2. Cursor의 Cursor Bench에서 좋은 성능을 보였고, Post-training Bench에서는 Opus 4.8을 앞선다고 언급했다.
   3. 비용도 더 저렴하므로, Hugging Face에서 일하는 Niels의 상황에서는 GLM 5.2를 사용하지 않을 이유가 없다고 판단했다.
   4. 발표에서 언급한 모델명과 벤치마크 결과는 당시 Niels가 공유한 최신 관찰이다.

6.2. CLI와 스킬 중심의 최소 도구 구성

1. Bash를 통한 실행
   1. 에이전트는 터미널에서 Bash를 도구로 사용한다.
   2. 주된 작업은 Hugging Face 명령을 실행하는 것이므로 Hugging Face CLI를 자주 호출한다.
2. 필요한 스킬
   1. 에이전트에게 Hugging Face CLI 스킬을 제공한다.
   2. 복잡한 별도 도구 묶음보다 CLI와 스킬이 핵심이다.
3. 외부 시스템 연결
   1. 에이전트는 GitHub 이슈에 후속 댓글을 단다.
   2. 처리 결과를 Hugging Face 내부 Slack 채널에 게시한다.
   3. Niels는 최종 결과를 Slack에서 확인할 수 있다.

6.3. Modal 배포와 병렬 배치 처리

1. Modal의 역할
   1. Niels는 에이전트를 Modal에 배포한다.
   2. Modal의 배치 처리(batch processing) 기능은 매우 많은 컨테이너를 동시에 띄울 수 있다.
2. 컨테이너와 에이전트 루프의 대응
   1. 각 컨테이너는 GitHub 이슈 하나를 처리하는 에이전트 루프 하나가 된다.
   2. 여러 이슈가 독립적으로 병렬 처리되므로 대량의 후속 대응을 빠르게 끝낼 수 있다.
3. 운영 경험
   1. Modal은 사용하기 쉽고 컨테이너 시작 속도도 빠르다고 평가했다.
   2. 밤새 실행하는 백그라운드 에이전트처럼 컨테이너를 짧은 시간 대량으로 띄워야 하는 경우에 특히 추천했다.

6.4. Cursor 스킬로 수동 실행하는 호출 루프

1. 크론 대신 수동 호출
   1. Modal 자체의 크론 기능으로 후속 대응을 자동 실행할 수도 있다.
   2. 하지만 Niels는 보통 Cursor에서 스킬을 직접 호출해 후속 처리를 시작한다.
   3. 그 스킬의 이름은 “process unread Modal”이다.
2. 중첩된 에이전트 호출
   1. Cursor에서 주로 사용하는 에이전트인 Composer 2.5가 호출된다.
   2. Composer 2.5는 다시 다른 에이전트들을 호출한다.
   3. 상위 에이전트가 여러 하위 에이전트를 실행하고 결과를 모으는 구조가 사람들이 말하는 에이전트 루프다.
3. 최종 결과
   1. 하위 에이전트들이 GitHub 이슈를 처리한다.
   2. 몇 분 뒤 처리 결과가 Hugging Face Slack 채널에 게시된다.
   3. Niels는 이 과정을 현재는 수동 스킬 호출로 시작하지만, 개별 이슈 처리는 Modal의 병렬 컨테이너에 맡긴다.

7. 에이전트가 만든 결과와 실제 연구자 반응

자동 아웃리치는 모델·데이터셋 공개와 문서화를 실제로 촉진했고, 연구자들이 에이전트의 제안에 답하거나 자신들의 산출물을 Hub로 옮기는 사례가 나왔다.

7.1. Slack에 집계되는 논문과 아티팩트

1. 연구 논문 게시
   1. 에이전트는 Hugging Face에 올릴 수 있는 논문과 연구 산출물을 대량으로 처리한다.
   2. 누군가 모델 카드나 데이터셋 카드에서 논문을 언급하면 Hugging Face는 그 논문을 Hub에서 색인한다.
   3. Slack에는 아웃리치 결과로 사람들이 업로드한 모델과 데이터셋 아티팩트가 모인다.
2. 수동 확인
   1. Niels는 Cursor의 스킬을 직접 실행한다.
   2. 몇 분 후 Slack 채널에 결과 메시지가 나타난다.
   3. 그는 이 흐름에서 나온 흥미로운 결과를 Slack에 다시 공유하기도 한다.

7.2. 봇임을 공개하지 않는 운영 방식

1. 공개하지 않는 이유
   1. Niels는 연구자에게 이슈를 쓰는 주체가 에이전트라는 사실을 굳이 밝히지 않는다.
   2. 상대가 봇이라는 사실을 알면 이슈를 빠르게 닫을 수도 있다고 보기 때문이다.
2. 수작업과 동일한 메시지
   1. 에이전트가 올리는 내용은 Niels가 과거에 직접 작성하던 것과 정확히 같은 종류의 제안이다.
   2. 연구자에게 유용한 제안이고 내용상 차이가 없다면, 에이전트라는 사실을 따로 강조할 이유가 없다고 판단했다.
3. 에이전트 대 에이전트
   1. 연구자들이 답변을 작성할 때 자신들의 에이전트를 사용하기도 한다.
   2. 한 에이전트가 만든 GitHub 이슈에 다른 에이전트가 답하는 상황이 생겼고, Niels는 이를 “요즘 인터넷의 모습”이라고 농담처럼 말했다.

7.3. 긍정·부정 반응

1. 일반적인 긍정 답변
   1. 한 연구자는 “제안과 명확한 안내에 정말 감사한다”는 식으로 Niels에게 답했다.
   2. 많은 연구자는 모델 가중치나 데이터셋을 Hugging Face에 공개하는 것이 말이 된다고 받아들였다.
   3. “왜 이 생각을 진작 못 했을까?”라고 반응하는 사람도 있었다.
2. 부정적 반응의 규모
   1. 수천 건의 이슈가 만들어지는 동안 부정적인 댓글은 지금까지 단 두 건뿐이었다.
   2. 그중 한 사람은 “Please close this slop.”이라고 썼고 이슈를 닫았다.
   3. 다른 한 건도 부정적이었지만, 발표에서 구체적인 문구나 상황까지 소개되지는 않았다.
3. 전체 평가
   1. 소수의 거절은 있었지만 대부분은 산출물 공개의 이점을 이해했다.
   2. 연구자는 연구를 더 잘 발견되게 만들고, 사용자와 개발자는 그 결과물을 쉽게 가져다 쓸 수 있어 전체적으로 윈윈이었다.

7.4. Apple·Google DeepMind·대용량 데이터셋 사례

1. Apple 연구자의 DM
   1. Apple의 한 연구자가 “당신이 연락한 것을 봤다”는 내용으로 Niels에게 직접 메시지를 보냈다.
   2. 실제로는 Niels가 직접 GitHub 이슈를 작성한 것이 아니라, 그의 에이전트가 Apple 논문의 새로운 아티팩트를 Hugging Face에 공개해 달라고 제안한 것이었다.
2. Google DeepMind의 수학 데이터셋
   1. 에이전트는 Google DeepMind에도 연락해 수학 데이터셋을 Hugging Face에 공개하도록 제안했다.
   2. 이런 대형 연구 조직까지 자동 아웃리치의 대상이 되었다.
3. 400GB 데이터셋
   1. Niels는 연구자가 Hugging Face에 400GB 데이터셋을 공개하고 싶다는 이메일도 받았다.
   2. 이 이메일을 시작하게 만든 것은 Niels가 아니라 자동 에이전트가 만든 GitHub 이슈였다.
   3. 대규모 데이터셋도 아웃리치가 적절하면 Hub로 유입될 수 있음을 보여 준다.

7.5. PaddleOCR 모델 이전

1. 프로젝트
   1. PaddleOCR는 중국의 회사·프로젝트로 소개되었다.
   2. PaddleOCR는 에이전트가 만든 이슈를 통한 아웃리치를 계기로 OCR 모델 전체를 Hugging Face로 옮겼다.
2. 의미
   1. 단일 모델이나 데이터셋 한 건이 아니라 한 프로젝트의 모델 묶음 전체가 이전되었다.
   2. 자동화된 요청이 실제 플랫폼 채택으로 이어진 대표적인 성공 사례다.

7.6. 모델 카드 자동 완성

1. Model Cards for Model Reporting
   1. Hugging Face에서 일하는 Mac Mitchell은 “Model Cards for Model Reporting”이라는 유명한 논문을 썼다.
   2. 이 논문의 취지는 누구나 자신의 모델을 적절한 방식으로 문서화하도록 하는 것이다.
   3. Hugging Face는 그 목적에 맞는 모델 카드 기본 템플릿을 제공한다.
2. 에이전트의 문서화 과정
   1. 에이전트는 Git diff에서 보이는 기본 모델 카드 템플릿을 확인한다.
   2. 논문, GitHub README, PDF 등의 내용을 읽고 템플릿의 빈 부분을 채운다.
   3. 사람이 처음부터 모델 카드 내용을 작성하지 않아도 연구에 맞는 설명이 자동으로 추가된다.
3. 예상 밖의 내용
   1. 어떤 모델 카드에는 모델 카드 작성자로 “Niels, Hugging Face 커뮤니티 사이언스 팀 소속”이라는 내용이 들어갔다.
   2. Niels는 그렇게 쓰라고 프롬프트한 적이 없었지만, 에이전트가 아웃리치 맥락을 바탕으로 넣은 내용이라 재미있게 받아들였다.
   3. 연구자는 “실수를 고칠 수 있게 도와줘서 고맙다”고 답하기도 했다.

7.7. Tiny Recursive Models 이슈

1. 가장 인기 있는 이슈
   1. 가장 많은 관심을 받은 GitHub 이슈는 Tiny Recursive Models 논문 관련 이슈였다.
   2. 이 논문은 Hugging Face뿐 아니라 Twitter에서도 상당히 화제가 되었다.
2. 커뮤니티의 신호
   1. 60명 넘는 사람이 해당 모델을 Hugging Face에 공개해 달라는 이슈에 추천(upvote)을 눌렀다.
   2. 단순한 자동 메시지가 아니라 커뮤니티가 실제 공개를 원한다는 신호가 연구자에게 전달되었다.
3. 윈윈 구조
   1. 연구자는 Hugging Face에서 연구를 더 쉽게 발견하게 만들 수 있다.
   2. 다른 사람은 그 연구 모델을 내려받아 위에 새로운 작업을 만들 수 있다.
   3. 연구자와 연구 활용자 모두에게 가치가 생긴다.

8. 스팸을 줄이고 에이전트를 평가하는 방법

대량 아웃리치는 효율적이지만, 아무 근거 없이 인터넷에 이슈를 뿌리는 슬롭이 되지 않도록 품질을 평가해야 한다.

8.1. 자동화와 슬롭의 경계

1. 제기되는 우려
   1. 수백 건의 GitHub 이슈를 자동으로 만들면 인터넷 전체에 봇이 스팸을 뿌리는 것처럼 보일 수 있다.
   2. 연구자에게 해당 모델·데이터셋 공개가 실제로 도움이 되는지 검토하지 않으면 자동화가 오히려 커뮤니티를 피로하게 만든다.
2. Niels의 판단 기준
   1. Hugging Face의 중앙화·문서화·검색 기능이 연구자와 사용자 모두에게 이득을 주는지 먼저 봐야 한다.
   2. 이슈 내용이 과거 Niels가 직접 보내던 유용한 제안과 같다면 자동화 자체가 문제는 아니라고 본다.
   3. 하지만 이익이 불분명하거나 품질이 낮은 메시지를 무작정 보내서는 안 되며, 평가가 필요하다.

8.2. Hamel Husain의 LLM Evals FAQ

1. 추천 자료
   1. Niels는 Hamel Husain의 “LLM Evals FAQ” 블로그 글을 강하게 추천했다.
   2. Hamel Husain은 LLM 평가 분야의 핵심 전문가로 소개되었다.
2. 평가를 시작하는 방법
   1. Hamel Husain은 유료 강의도 운영하지만, 온라인에 무료로 읽을 수 있는 자료도 많이 공개한다.
   2. 에이전트가 유용한 결과를 내는지, 불필요한 이슈를 만들지, 요구한 작업을 정확히 수행하는지 평가하려면 해당 자료를 참고할 수 있다.
3. 운영 원칙
   1. 자동화의 처리량만 보고 성공으로 판단하지 않는다.
   2. 이슈 품질, 연구자의 반응, 실제 모델·데이터셋 공개 여부, 문서화 품질을 함께 측정해야 한다.
   3. 에이전트가 더 많은 일을 할수록 관측성과 평가 체계를 같이 강화해야 한다.

9. 결론: 오픈 모델과 최소 도구로 확장하는 에이전트

Niels의 사례는 최신 모델을 복잡한 프레임워크로 감싸는 것보다, 명확한 CLI와 스킬·샌드박스에 실제 업무를 연결하는 편이 더 강력할 수 있음을 보여 준다.

9.1. 오픈 모델의 성능 향상

1. 언급된 모델
   1. GLM 5.2와 DeepSeek V4 같은 오픈 모델이 매우 좋아지고 있다고 평가했다.
   2. 최신 오픈 모델의 성능이 충분히 올라오면서 폐쇄형 모델을 대체할 수 있는 상황이 되었다고 보았다.
2. 선택의 기준
   1. 자신이 맡은 업무에서 모델이 GitHub와 CLI를 통해 정확한 후속 대응을 수행하면 된다.
   2. 비용과 성능을 함께 고려하면 Hugging Face Inference Providers를 통한 오픈 모델 사용이 합리적이다.

9.2. 이 업무에서 에이전트가 워크플로보다 나은 이유

1. 유연한 후속 처리
   1. GitHub 이슈마다 연구자의 답변과 상황이 다르기 때문에 후속 단계는 미리 고정한 분기만으로 처리하기 어렵다.
   2. 자율 에이전트는 답변을 읽고 필요한 CLI 명령을 고른 뒤, 상황에 맞춰 댓글과 Slack 결과를 만든다.
2. 최소한의 구성
   1. 이 사용 사례에는 Hugging Face CLI 하나가 필요하다.
   2. Hugging Face CLI 스킬 하나가 필요하다.
   3. 에이전트가 안전하게 작업할 수 있는 샌드박스(sandbox)가 필요하다.
   4. Niels는 이것만 있으면 업무를 수행할 수 있다고 결론 내렸다.
3. 반드시 필요한 평가
   1. 단순함이 무검증을 뜻하지는 않는다.
   2. 에이전트를 쓰더라도 평가를 잊지 말아야 한다는 말을 결론에서 다시 강조했다.

10. 커뮤니티 사이언스 팀의 다른 자동화 프로젝트

Niels는 GitHub 아웃리치 외에도 같은 연구 발견 워크플로를 X 게시와 Papers with Code 부활에 활용하고 있다.

10.1. Daily Papers X 계정

1. 계정과 작동 방식
   1. Niels는 “Daily Papers”라는 Twitter/X 계정을 만들었다.
   2. 계정 뒤에서는 GitHub 아웃리치에 사용한 것과 정확히 같은 워크플로가 작동한다.
   3. 흥미로운 연구 논문과 Hugging Face 아티팩트를 X에 자동으로 게시한다.
2. 성장
   1. 계정은 Niels가 별도로 운영에 참여하지 않았는데도 팔로워 90,000명을 넘었다.
   2. 한 번 배포한 뒤 Hugging Face에서 흥미로운 산출물이 공개될 때마다 게시하도록 두었다.
3. 게시 빈도
   1. 일반적으로 4시간마다 새 연구 논문과 아티팩트를 게시한다.
   2. 누군가 Hugging Face에서 특별히 흥미로운 것을 공개하면 정기 주기와 별도로 게시하기도 한다.
4. 이미지 선택과 반응
   1. Gemini가 트윗에 포함할 가장 적절한 시각 자료를 결정한다.
   2. Nvidia가 GLM 5.2 최적화 버전을 출시했다는 최근 트윗은 2,000개 이상의 좋아요를 받았다.
   3. 연구 발견과 시각 자료 선택까지 자동화해도 많은 사람에게 도달할 수 있다는 사례다.

10.2. Papers with Code의 부활

1. 서비스의 역사
   1. Papers with Code는 한때 존재하던 연구·벤치마크 웹사이트였다.
   2. Meta가 서비스를 인수한 뒤 결국 사라졌고, Niels는 그 서비스가 아쉽게 종료됐다고 말했다.
2. 현재 프로젝트
   1. Niels는 Papers with Code를 되살리는 작업을 진행 중이다.
   2. 목적은 연구와 최신 성능(state of the art)을 더 쉽게 접근할 수 있게 만드는 것이다.
   3. 현재 서비스는 paperswithcode.co에서 운영된다.
3. 벤치마크
   1. 사이트에는 OCR 모델 벤치마크 같은 자료가 있다.
   2. OCR 분야에서 널리 쓰이는 벤치마크와 모델 성능을 찾아볼 수 있다.
4. 교육 리소스
   1. 단순한 순위표가 아니라 기술 용어를 배울 수 있는 교육 자료로도 만들고 있다.
   2. 예로 mid-training과 on-policy distillation 같은 용어를 설명하고 있다.
   3. 연구자뿐 아니라 기술 개념을 배우려는 사람도 연구 동향을 이해할 수 있도록 하려는 방향이다.

주요 발언 모음

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

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

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

“워크플로는 더 예측 가능하고 통제할 수 있지만, 덜 유연합니다. 자율 에이전트는 더 유연하지만 덜 예측 가능합니다.”

“모델이 아주 좋아졌기 때문에 수천 줄의 커스텀 코드를 단순한 에이전트, CLI 도구, 스킬로 바꿀 수 있습니다.”

“사람들이 제 에이전트에게 답할 때 자기 에이전트를 쓰는 경우도 있습니다. 요즘 인터넷이 그런 모습입니다.”

“Please close this slop.”

“왜 이 생각을 진작 못 했을까요?”

“에이전트에는 Hugging Face CLI 하나, Hugging Face CLI 스킬 하나, 그리고 샌드박스가 필요합니다. 그게 전부입니다.”

“평가를 잊지 마세요.”

핵심 데이터 & 수치

• 영상 길이: 20분 5초.
• 발표자 경력: Niels는 Hugging Face에서 5년째 머신러닝 엔지니어로 일하고 있다.
• 논문 처리 규모: AI 붐으로 arXiv에 매일 수백 편의 논문이 나오며, 밤마다 자동화 파이프라인이 수백 편을 읽는다.
• 이슈 생성 규모: 자동화 후 매일 밤 수백 건의 GitHub 이슈가 생성된다.
• 자동화 주기: 첫 번째 결정론적 파이프라인은 매일 밤 한 번 실행된다.
• 코드 감소 사례: Cursor는 약 12,000줄의 커스텀 워크플로를 약 200줄의 스킬로 교체했다고 소개했다.
• 부정적 댓글: 수천 건의 자동 생성 이슈 가운데 지금까지 부정적인 댓글은 단 두 건이었다.
• 대용량 데이터셋: 연구자가 Hugging Face에 공개하려 한 데이터셋 중 400GB 규모가 있었다.
• Tiny Recursive Models: 관련 GitHub 이슈에 60명 넘는 사람이 추천을 눌렀다.
• Daily Papers 팔로워: Niels가 만든 X 계정이 별도 운영 개입 없이 90,000명 이상의 팔로워를 확보했다.
• Daily Papers 게시 주기: 보통 4시간마다, 또는 Hugging Face에서 특별히 흥미로운 산출물이 공개될 때 게시한다.
• X 게시 반응: Nvidia의 GLM 5.2 최적화 버전 관련 트윗이 2,000개 이상의 좋아요를 받았다.
• 실행 컨테이너: Modal은 여러 컨테이너를 병렬로 띄우며, 컨테이너 하나가 GitHub 이슈 하나를 처리하는 에이전트 루프가 된다.
• 모델 비교 언급: Niels는 GLM 5.2가 Cursor Bench에서 좋은 성능을 보였고 Post-training Bench에서 Opus 4.8을 앞선다고 말했다.
• 주요 모델·도구: Claude Agents SDK, GLM 5.2, DeepSeek V4, Hugging Face Inference Providers, Together.ai, Fireworks, Cerebras, Modal, Hugging Face CLI, LangFuse, Gemini, Composer 2.5가 언급되었다.

결론 및 시사점

1. 발견 가능성을 자동화 목표로 삼는다: 연구 산출물이 Google Drive나 GitHub Releases에만 머무르면 논문과 모델·데이터셋 사이의 연결이 끊긴다. Hub와 메타데이터를 통해 연구자와 사용자를 연결하면 단순 저장을 넘어 재현성과 활용성을 높일 수 있다.
2. 수작업을 먼저 복제한다: 처음부터 자율 에이전트를 만들지 않고, 사람이 하던 논문 확인·README 읽기·상태 점검·이슈·PR 흐름을 결정론적 워크플로로 옮기면 통제 가능한 기반을 확보할 수 있다.
3. 업무 성격에 맞춰 자율성을 나눈다: 논문별 초기 검토처럼 반복 순서가 명확한 부분은 워크플로에 맡기고, 연구자 답변에 따라 달라지는 후속 처리는 자율 에이전트로 넘기는 조합이 효과적이다.
4. 도구 표면을 작게 유지한다: Hugging Face CLI, CLI 스킬, 샌드박스처럼 에이전트가 실제 업무를 수행하는 데 필요한 최소 도구만 제공하면 구현과 운영을 단순화할 수 있다.
5. 병렬 실행으로 처리량을 확장한다: Modal의 컨테이너 병렬 처리는 이슈 하나당 에이전트 루프를 배정해 대량의 후속 대응을 빠르게 끝내게 한다.
6. 관측성을 기본 기능으로 둔다: LangFuse로 입력·출력·프롬프트·비용·지연 시간을 추적해야 처리량이 늘어도 잘못된 행동을 발견할 수 있다.
7. 유용한 자동화와 스팸을 구분한다: 메시지가 사람 대신 생성됐다는 사실보다, 실제로 연구자의 발견 가능성과 사용자의 접근성을 높이는지, 내용이 과거 수작업과 같은 품질인지가 중요하다.
8. 평가 없는 에이전트는 운영하지 않는다: LLM Evals FAQ 같은 자료를 참고해 이슈의 적절성, 연구자 반응, 실제 공개와 문서화 결과를 측정해야 한다.
9. 오픈 모델의 성능을 실무에 반영한다: GLM 5.2와 DeepSeek V4처럼 성능이 좋아진 오픈 모델은 비용과 유연성 측면에서 폐쇄형 모델의 실용적인 대안이 될 수 있다.
10. 연구 발견 파이프라인은 여러 채널로 확장된다: 동일한 워크플로가 GitHub 아웃리치, Slack 결과 보고, Daily Papers X 계정, Papers with Code의 벤치마크·교육 자료로 이어진다.

핵심 요약 (20줄)

1. Niels는 벨기에 출신으로 KU Leuven에서 공부했고 Hugging Face에서 5년째 머신러닝 엔지니어로 일한다.

2. Hugging Face 커뮤니티 사이언스 팀은 외부 저장소에 흩어진 연구 모델과 데이터셋을 Hub로 연결한다.

3. 연구자들은 Google Drive, GitHub Releases, Dropbox, Zenodo 등에 가중치와 데이터셋을 올려 발견 가능성을 낮추고 있었다.

4. Hugging Face 논문 페이지는 arXiv 논문과 연결된 모델·데이터셋을 보여 줘 연구 재현과 검색을 돕는다.

5. 모델 카드와 데이터셋 카드, 메타데이터 태그는 산출물의 사용법과 검색 조건을 명확하게 만든다.

6. Niels는 연구자의 GitHub 저장소를 찾아 README를 읽고 Hugging Face에 공유할 산출물을 확인했다.

7. 산출물이 없으면 GitHub 이슈를 열고, 카드나 태그가 부족하면 Hugging Face PR을 만드는 흐름이 반복됐다.

8. AI 붐과 NeurIPS 같은 학회 때문에 매일 수백 편의 논문이 나와 수작업은 확장되지 않았다.

9. 2024년 첫 자동화는 수작업을 그대로 복제한 결정론적 워크플로와 단계별 LLM API로 시작했다.

10. GitHub Actions 크론 작업은 매일 밤 수백 편의 arXiv 논문을 읽고 수백 건의 이슈를 생성했다.

11. LangFuse는 LLM의 입력·출력·프롬프트·비용·지연 시간을 추적해 운영 관측성을 제공했다.

12. 이슈 답변이 쌓이자 Niels는 GitHub 알림함을 이메일함처럼 처리해야 하는 후속 업무를 자동화했다.

13. 후속 에이전트는 Claude Agents SDK를 사용해 도구를 호출하는 자율 루프로 동작했다.

14. Hugging Face Inference Providers를 통해 GLM 5.2 같은 오픈 모델과 여러 추론 제공자를 통합했다.

15. Bash 기반 Hugging Face CLI와 CLI 스킬, 샌드박스만으로도 후속 이슈 처리에 필요한 도구가 충분했다.

16. Modal은 컨테이너 하나당 GitHub 이슈 하나를 배정해 대량의 에이전트를 병렬 실행했다.

17. Apple·Google DeepMind·PaddleOCR와 400GB 데이터셋 사례는 자동 아웃리치가 실제 이전을 이끈 예다.

18. Tiny Recursive Models 이슈에는 60명 넘는 사람이 추천을 눌렀고, 모델 카드 자동 작성도 이뤄졌다.

19. Daily Papers X 계정은 90,000명 이상의 팔로워를 모았고, Papers with Code 부활 프로젝트도 진행 중이다.

20. 에이전트 자동화는 유용한 상호 이익과 평가 체계를 전제로 하며, 단순한 CLI·스킬·샌드박스 조합으로도 확장될 수 있다.