Hugging Face Seoul Meetup 세션 정리

Table of contents

키노트 세션: Hugging Face 리모트 토크

첫 세션은 Hugging Face 글로벌 팀의 리모트 토크였다. 발표자는 스스로를 오픈소스 개발자라고 소개하면서, Hugging Face 생태계가 지금 어디까지 와 있는지 빠르게 훑었다.

가장 먼저 짚은 것은 오픈소스와 오픈웨이트 모델의 의미였다. 오픈 모델을 쓴다는 것은 단순히 무료 모델을 쓴다는 뜻이 아니다. 모델을 내 손 안에 둘 수 있다는 뜻에 가깝다. 어떤 버전을 쓰는지 고정할 수 있고, 양자화해서 더 작은 환경에 올릴 수 있고, 필요하면 로컬이나 브라우저에서도 돌릴 수 있다.

폐쇄형 API는 편하다. 하지만 서비스 제공자가 내부 모델을 바꾸면 사용자는 그 변화를 그대로 받아들여야 한다. 반대로 오픈 모델은 직접 운영해야 하는 부담이 있지만, 비용과 배포 방식, 개인정보 문제를 스스로 통제할 수 있다. 발표는 이 차이를 꽤 실용적인 관점에서 설명했다.

이어서 Hugging Face의 여러 구성요소가 소개됐다.

• Hub는 모델과 데이터셋을 공유하는 중심 공간이다.
• Model Card와 Dataset Card는 모델과 데이터의 출처, 용도, 한계를 설명하는 문서 역할을 한다.
• Inference Providers는 여러 추론 제공자를 Hugging Face 안에서 비교하고 호출할 수 있게 해준다.
• Jobs는 GPU 위에서 임의의 작업을 실행하는 도구에 가깝다.
• Spaces는 데모와 앱을 공개하는 공간이고, ZeroGPU 같은 방식으로 GPU 접근성을 낮춘다.
• Transformers, TRL, PEFT, Accelerate 같은 라이브러리는 학습과 파인튜닝의 기본 도구가 됐다.

질의응답에서 Hugging Face Jobs가 RunPod, Fireworks 같은 GPU 서비스와 어떻게 다른지에 대한 질문이 나왔다. 답변의 핵심은 Jobs가 특정 파인튜닝 버튼을 제공하는 서비스가 아니라는 점이었다. 사용자가 GPU에서 실행할 코드를 직접 제출하는 구조이기 때문에, 파인튜닝뿐 아니라 OCR, 배치 추론, 데이터 전처리 같은 여러 작업을 올릴 수 있다.

키노트는 일종의 지형도 같았다. Hugging Face가 더 이상 “모델을 내려받는 곳”에 머물지 않는다는 점이 분명했다. 데이터, 학습, 추론, 배포, 커뮤니티까지 하나의 작업 흐름으로 묶어가고 있었다.

발표 세션 1 — 손규진 (서울대학교): 한국 유일 오픈소스 자연어 처리 연구 그룹 해례

첫 번째 현장 발표는 오픈소스 한국어 자연어 처리 연구 그룹 해례(HAE-RAE) 소개였다. 발표자는 처음부터 연구 그룹의 성과를 딱딱하게 늘어놓기보다, 해례가 어떻게 시작됐고 왜 벤치마크를 만들게 됐는지 꽤 솔직하게 풀어냈다.

처음 목표는 한국어 모델을 만드는 것이었다. 한국어 Alpaca 같은 모델을 만들고 싶었지만, 비슷한 시도가 이미 나오고 있었고, 자신들이 만든 모델이 무엇을 더 잘하는지 말하기도 어려웠다. 여기서 문제가 바뀌었다.

모델을 만들었는데, 이 모델이 정말 좋은지 어떻게 증명하지?

그래서 해례는 모델보다 평가셋을 먼저 만들기 시작했다.

초기 작업인 HAE-RAE Bench는 한국어와 한국 문화에 특화된 지식을 평가하려는 시도였다. 예를 들어 신촌에서 비발디파크에 가는 방법처럼, 한국에서 생활해본 사람에게는 맥락이 있는 질문이지만 영어권 웹 지식만으로는 쉽게 풀기 어려운 질문들이 있다. 아이돌, 드라마, 지역 교통, 생활 상식처럼 한국어 모델이라면 알아야 할 것 같은 지식도 평가 대상이 됐다.

이후 나온 것이 KMMLU다. KMMLU는 공무원 시험, 자격증 시험, 수능 등 한국에서 실제로 만들어진 문제를 대규모로 모은 벤치마크다. 약 35,000개 문항 규모로, MMLU나 CMMLU보다도 큰 한국어 평가셋이다. 발표 중에는 HyperCLOVA X, EXAONE, Solar, Kanana, A.X, KORMo 같은 국내 모델들이 KMMLU를 참고한다고 언급했다.

그런데 모델들이 빠르게 좋아지면서 KMMLU도 점점 쉬워졌다. 그래서 해례는 KMMLU Pro를 만들었다. KMMLU Pro는 문제를 무작위로 섞기보다 시험 단위 구조를 살렸다. 단순히 “이 모델은 60점입니다”라고 말하는 대신, “이 모델은 어떤 자격시험 수준의 문제를 어느 정도 풀 수 있습니다”라고 말할 수 있게 하려는 시도다.

멀티모달 평가 이야기도 인상적이었다. 발표자는 네이버 지식인을 자주 본다고 했다. 거기에는 정말 이상한 질문이 많다. “어릴 때 들은 노래인데 나나나나나나 하는 노래가 뭐냐” 같은 질문은 GPT-6, GPT-7이 아니라 GPT-25는 가야 하지 않겠냐고 농담하기도 했다. 하지만 농담처럼 들리는 이 예시는 중요한 문제를 찌른다. 실제 사용자는 모델에게 충분한 정보를 주지 않는다.

좋은 모델이라면 사용자가 모호하게 묻는 상황에서도 적절히 되묻거나, 가능한 추론 범위를 정리해야 한다. 해례의 멀티모달 벤치마크는 이런 실제 사용자의 불완전한 질문을 다루려는 방향으로 가고 있었다.

마지막에는 수학 벤치마크와 에이전트 평가 이야기도 나왔다. 해례 팀은 수학자와 연구자들이 직접 만든 고난도 문제를 통해 모델의 수학적 추론 능력을 보고 있고, 앞으로는 모델이 실제 업무를 대신 수행할 수 있는지 평가하는 쪽에도 관심을 두고 있었다.

이 발표의 핵심은 분명했다. 한국어 AI 생태계에는 모델만 필요한 것이 아니다. 모델이 정말 좋아졌는지 확인할 수 있는 공개 평가 기준이 필요하다. 해례는 그 빈자리를 채우려는 팀이었다.

발표 세션 2 — 이민철 (카카오): LLM 시대에 형태소 분석기가 살아남는 법

두 번째 발표는 오픈소스 한국어 형태소 분석기 Kiwi 개발기였다. 제목부터 좋았다. “LLM 시대에 형태소 분석기가 살아남는 법.” 요즘 거대 언어 모델이 워낙 많은 것을 직접 배워버리니, 형태소 분석기가 아직도 필요한지 묻는 사람들이 많다. 발표는 그 질문을 정면으로 다뤘다.

발표자는 먼저 Kiwi의 시작을 이야기했다. 원래 역사학과 문헌정보학 쪽에서 텍스트 마이닝을 하다가, 한국어를 Python 환경에서 편하게 다룰 수 있는 도구가 부족하다는 문제를 느꼈다고 했다. 당시 한국어 NLP 도구는 Java 기반이 많았고, Python에서 쓰려면 JVM 의존성이 따라왔다. 그래서 C++ 기반 형태소 분석기와 Python 바인딩을 직접 만들게 됐다.

Kiwi라는 이름도 분위기를 풀어줬다. Korean Intelligent Word Identifier라는 이름은 나중에 맞춘 것이고, 사실은 그냥 키위를 좋아해서 지었다고 했다.

그렇다면 LLM 시대에 형태소 분석기는 어디에 남을까?

발표자의 답은 “거대 모델 하나로 모든 NLP 인프라가 사라지는 것은 아니다”에 가까웠다. LLM은 강력하지만, 모든 작업을 LLM으로 처리할 수는 없다. 특히 다음 영역에선 여전히 형태소 분석기가 중요하다.

• 검색과 RAG: 한국어 검색은 조사와 어미를 어떻게 처리하느냐가 검색 품질에 직접 영향을 준다.
• 데이터 정제: 대규모 웹 코퍼스를 만들 때, 가벼운 언어 분석기는 저품질 문서를 걸러내는 1차 필터가 될 수 있다.
• 소형 모델과 온디바이스 모델: 모델이 작을수록 입력을 어떤 단위로 나누는지가 더 중요해진다.
• 기존 산업 시스템: 기업 내부 검색, 로그 분석, 문서 처리 시스템은 여전히 형태소 분석기에 의존하는 경우가 많다.

Kiwi가 중점을 둔 것은 현실의 인터넷 텍스트였다. 실제 한국어에는 오타, 이모지, 줄임말, 방언, 깨진 문장이 많다. 교과서 문장만 잘 분석하는 도구는 실제 환경에서 금방 흔들린다. Kiwi는 이런 지저분한 입력을 다루는 방향으로 꾸준히 개선해 왔다.

오픈소스 유지보수 이야기도 좋았다. 발표자는 오픈소스가 늘 낭만적인 일은 아니라고 했다. 무료 노동처럼 느껴질 때도 있고, 사용자의 요구가 부담이 될 때도 있다. 그런데 사용자가 이상한 문장을 들고 와서 “이거 왜 안 돼요?”라고 물을 때, 그 사례들이 결국 도구를 더 단단하게 만든다.

기여는 꼭 큰 코드 변경일 필요가 없다. 버그 리포트, 문서 수정, 사용 사례 공유, 질문에 답하기 같은 일도 오픈소스 생태계에 의미가 있다. 이 발표는 형태소 분석기 하나의 개발기이면서, 한국어 오픈소스 도구가 오래 살아남는 방식을 보여주는 이야기이기도 했다.

발표 세션 3 — 박찬성 (ETRI): 오픈소스를 통한 도메인 특화 AI 연구 가속화

세 번째 발표는 분위기가 조금 달랐다. 앞선 발표들이 한국어 평가와 도구 이야기였다면, 이 발표는 AI를 실제 산업 시스템에 넣을 때 생기는 문제를 차분하게 짚었다. 발표자는 네트워크 지능화 연구를 예로 들며, 도메인 특화 AI에서 왜 오픈소스가 중요한지 설명했다.

일반적인 챗봇이나 개인 생산성 도구는 모델이 조금 틀려도 사용자가 다시 물어보거나 결과를 고치면 된다. 하지만 네트워크 운영, 금융, 의료, 제조처럼 실패 비용이 큰 영역은 상황이 다르다. AI가 잘못된 명령을 내리면 실제 장애나 손실로 이어질 수 있다. 이런 곳에선 “대체로 똑똑한 모델”만으로 부족하다.

발표의 중요한 문제의식은 모델 의존성이었다. 폐쇄형 API를 쓰면 최신 모델을 쉽게 사용할 수 있다. 하지만 모델 제공자가 내부 모델을 바꾸면, 같은 프롬프트와 같은 시스템도 다르게 동작할 수 있다. 전통적인 소프트웨어는 버전이 바뀌면 변경 사항을 추적하고 테스트할 수 있다. LLM 서비스는 그 변화가 훨씬 불투명하다.

도메인 특화 AI에선 이 문제가 더 커진다. 한 번 구축한 에이전트나 워크플로우가 특정 모델의 응답 습관에 맞춰져 있을 수 있기 때문이다. 모델이 업데이트되면 전체 시스템을 다시 검증해야 한다. 이 검증 비용은 생각보다 크다.

여기서 오픈소스 모델의 의미가 나온다. 오픈 모델은 직접 운영해야 하는 부담이 있지만, 최소한 어떤 버전의 모델을 쓰는지 고정할 수 있다. 도메인 데이터로 반복 평가하고, 필요한 경우 직접 파인튜닝할 수 있다.

발표자는 도메인 특화 AI를 만들려면 먼저 데이터를 확보해야 한다고 강조했다. 하지만 네트워크 운영 데이터처럼 민감한 데이터는 외부로 나오기 어렵다. 그래서 시뮬레이션과 합성 데이터가 중요해진다. 실제 운영 환경을 최대한 닮은 시뮬레이터를 만들고, 그 안에서 AI가 수행할 수 있는 작업과 실패 사례를 만들어야 한다.

이 발표는 AI를 서비스에 넣는 일이 단순히 “모델 API를 붙이는 일”이 아니라는 점을 잘 보여줬다. 도메인 지식, 데이터, 평가, 배포 안정성, 버전 관리가 모두 필요하다. 오픈소스는 그중 모델을 통제 가능한 구성요소로 만드는 데 중요한 역할을 한다.

Break Time

짧은 휴식 시간이었다. 앞선 세 발표가 한국어 평가, 형태소 분석기, 도메인 특화 AI처럼 비교적 깊은 기술과 생태계 이야기를 다뤘다면, 이후 세션은 에이전트, 한국어 오픈소스 모델, 산업 모델 개발기로 이어졌다.

라이트닝 토크 — 최용호 (AWS)

라이트닝 토크는 Hugging Face의 SmolAgents를 활용한 멀티모달 에이전트 전략을 다뤘다.

이 발표는 비교적 실용적 톤이었다. 요즘 모델은 너무 빨리 바뀐다. 어떤 작업에는 가벼운 모델이 맞고, 어떤 작업에는 강한 모델이 필요하다. 회사에선 OpenAI, Anthropic 같은 API 모델과 Hugging Face 오픈 모델, 자체 호스팅 모델을 함께 쓰기도 한다. 이때 모델이 바뀔 때마다 코드를 크게 바꿔야 한다면 운영 부담이 커진다.

SmolAgents는 이런 문제를 줄이기 위한 에이전트 프레임워크를 소개했다. 모델은 추론하고, 필요한 도구를 호출하고, 실행 결과를 보고 다시 판단한다. 프레임워크는 이 과정을 일정한 구조로 잡는다.

발표 중에는 두 가지 에이전트 유형을 소개했다.

• CodeAgent: 모델이 Python 코드를 작성하고 실행한 뒤 결과를 바탕으로 답한다.
• ToolCallingAgent: 모델이 미리 정의된 도구를 호출하면서 작업을 진행한다.

멀티 에이전트 구조도 설명했다. 모든 일을 하나의 거대한 에이전트가 처리하게 만들기보다, 역할별로 작은 에이전트를 나누고, 상위 에이전트가 이들을 조율하는 방식이다. 검색 담당, 계산 담당, 문서 처리 담당 에이전트를 따로 두고 supervisor가 전체 흐름을 관리하는 식이다.

다만 결론은 “멀티 에이전트를 무조건 쓰자”가 아니었다. 발표자는 오히려 단순함을 강조했다. 멀티 에이전트가 정말 필요한지 먼저 따져보고, 가능한 단순한 구조로 시작하는 편이 좋다는 이야기였다. 에이전트가 많아지면 구조도 복잡해지고 디버깅도 어려워진다.

AWS 관점에선 Bedrock, SageMaker, AgentCore 같은 서비스와 연결해 실제 서비스 환경에서 필요한 확장성, 보안, 격리 실행, 메모리 관리까지 고려해야 한다는 이야기도 이어졌다. 실험용 에이전트를 만드는 것과, 회사 서비스 안에서 안전하게 운영하는 것은 다른 문제다.

질의응답에서 MCP와 SmolAgents의 관계에 대한 질문도 나왔다. 답변은 둘의 역할이 다르다는 쪽이었다. MCP가 이미 만들어진 도구를 가져다 쓰는 규격에 가깝다면, SmolAgents는 그 도구들을 활용해 에이전트 시스템을 구성하는 프레임워크에 가깝다.

발표 세션 4 — 임경태 (KAIST): 모두를 위한 한국어 오픈소스 언어모델 KORMo 개발기

네 번째 발표는 한국어 오픈소스 언어 모델 KORMo 개발기였다. 개인적으로 가장 현장감이 강한 발표 중 하나였다. 발표자는 교수로서보다 개발자로서 Hugging Face에서 발표할 수 있어 기쁘다고 말하며 시작했다. 그리고 곧바로 GPU, 데이터, 학생, 레시피, 공개의 현실적 이야기로 들어갔다.

KORMo의 문제의식은 한국어 언어 모델 개발의 병목에서 출발했다. 기업, 학교, 정부출연연구소가 각자 비슷한 데이터를 만들고, 비슷한 실험을 반복하고, 비슷한 실패를 겪고 있었다. 그런데 그 결과와 레시피는 잘 공개되지 않는다. 이유는 단순하다. 그 시행착오가 전부 돈이기 때문이다.

발표자는 이 상황을 정부, 기업, 학교가 서로 다른 기대를 품고 있는 “비운의 삼각형”처럼 설명했다. 기업은 거대 모델을 만들어본 인재를 원하지만, 학교에는 그런 경험을 쌓을 GPU가 부족하다. 정부는 DeepSeek 같은 모델을 왜 못 만드느냐고 묻지만, 현장에선 데이터와 GPU, 경험이 모두 부족하다. 결국 필요한 것은 공개된 기반이다.

KORMo 팀은 그래서 모델 하나만 공개하는 것이 아니라, 한국어 언어 모델을 처음부터 공부하고 재현할 수 있는 기반을 만들고자 했다. 모델, 데이터, 토크나이저, 학습 레시피, 튜토리얼을 함께 공개하는 풀스택 프로젝트에 가까웠다.

가장 큰 문제는 데이터였다. 한국어 특화 모델을 만들려면 대규모 한국어 사전학습 데이터가 필요하다. 그런데 공개된 한국어 데이터는 생각보다 부족했고, 품질도 고르지 않았다. 블로그 데이터에는 광고성 문서가 많고, 공개 데이터라 해도 라이선스가 애매한 경우가 있었다.

그래서 KORMo 팀은 데이터를 직접 만들고, 크롤링하고, 필터링하고, 합성했다. GPU를 사용할 수 있는 기간 중 상당 시간을 데이터 생성에 썼다는 이야기도 나왔다. 단순히 영어 데이터까지 많이 섞어 토큰 수를 늘리는 선택도 가능했지만, 그렇게 하면 “과연 한국어 모델인가?”라는 질문이 남는다. 그래서 더 많은 학습량보다 한국어 데이터와 공개 가능한 파이프라인을 택했다.

토크나이저 이야기도 강했다. 기존 Llama나 GPT 계열 토크나이저는 한국어에 불리한 경우가 많다. 토큰 수가 늘어나면 학습과 추론 비용이 늘고, 같은 컨텍스트 안에 담을 수 있는 정보도 줄어든다. 발표자는 한국어를 더 효율적으로 처리하는 토크나이저를 설계했다고 설명했고, 저품질 블로그 데이터가 토크나이저에 남기는 흔적도 예로 들었다.

학습 레시피도 공개 대상이었다. 레이어 정규화 방식, 어텐션 방식, 데이터 필터링, 러닝레이트 설정처럼 실제로 모델을 학습해보지 않으면 알기 어려운 선택들이 있다. 발표자는 이런 값들이 작은 차이처럼 보이지만, 대규모 학습에선 성능과 비용 차이로 이어진다고 말했다. 러닝레이트 하나를 잘못 고르면 나중에 같은 성능에 도달하기 위해 훨씬 많은 토큰을 더 학습해야 할 수 있다는 설명이 특히 현실적이었다.

KORMo 발표의 핵심은 “우리가 좋은 한국어 모델을 만들었다”보다 더 컸다. 한국어 언어 모델을 만들기 위한 기반을 공개하고, 다음 사람이 같은 실패를 덜 반복하게 만들겠다는 이야기였다.

질의응답에서 한국어 추론 모델의 reasoning trace에 대한 질문이 나왔다. 많은 한국어 추론 모델은 중간 reasoning을 영어로 쓰는 경우가 많다. KORMo는 한국어 질문에 대해 한국어 reasoning trace를 생성하도록 학습했다고 답했다. 다만 영어 reasoning을 쓰면 성능이 더 잘 나오는 경우가 있다는 점도 함께 언급했다. 한국어 모델을 만든다는 일이 단순히 최종 답변만 한국어로 내는 문제가 아니라는 점이 드러난 대목이었다.

발표 세션 5 — 김성훈 (업스테이지): Solar 연대기

마지막 발표는 업스테이지의 Solar 연대기였다. 앞선 KORMo 발표가 연구실과 오픈소스 기반의 분투기였다면, Solar 발표는 스타트업이 LLM 경쟁 한가운데로 뛰어든 이야기였다. 발표는 2023년 ChatGPT 이후 업스테이지가 LLM 개발에 뛰어든 이야기에서 시작했다.

초기에는 GPU가 많지 않았다. 그래서 처음부터 거대한 모델을 학습하기보다 기존 모델을 잘 파인튜닝하는 방식으로 접근했다. Hugging Face 리더보드에서 좋은 성적을 얻으며 가능성을 확인했고, 이후 모델을 더 크게 바꾸는 방법을 고민하게 됐다.

그 과정에서 나온 아이디어 중 하나가 Depth Up-Scaling이었다. 기존 모델을 단순히 파인튜닝하는 데는 한계가 있으니, 모델의 층을 확장하고 그 사이를 학습시키는 방식으로 더 큰 모델을 만드는 접근이었다. 발표자는 이를 건물을 벌리고 중간층을 채워 넣는 비유로 설명했다. 이 방식으로 Solar는 여러 버전을 거치며 성능을 높였고, 오픈웨이트 모델로 공개되며 커뮤니티에서도 많은 파생 모델이 만들어졌다.

발표 중 “GPU 오징어 게임”이라는 표현도 나왔다. 독자 파운데이션 모델 프로젝트를 설명하면서, 다음 라운드로 진출하면 더 많은 GPU와 기회를 받는 구조를 오징어 게임에 비유한 것이다. 분위기는 가벼웠지만, 그 안에는 국내 LLM 개발 경쟁의 현실이 그대로 들어 있었다.

업스테이지는 이후 Solar 100B, Open2, Pro4 같은 모델로 이어지는 흐름을 설명했다. 발표자는 이제 단순히 말을 잘하는 모델보다 실제 작업을 끝까지 수행하는 에이전트형 모델이 중요해졌다고 강조했다. “말만 잘하는 사람”보다 “일을 잘하는 사람”이 필요하다는 식의 비유도 나왔다.

요즘 모델의 경쟁력은 대화 능력만으로 정해지지 않는다. 긴 컨텍스트 안에서 목표를 유지하고, 여러 단계를 거쳐 작업을 수행하고, 실제 환경에서 결과를 내야 한다. 업스테이지도 이 방향에 맞춰 롱컨텍스트와 에이전트 성능을 강화하고 있다고 설명했다.

발표 중에는 Solar Open2를 활용한 에이전트 데모도 소개했다. 웹 검색, 논문 정리, 슬라이드 구성, 코드 작성, 게임 제작 같은 예시가 나왔다. Solar를 단순 챗봇이 아니라 에이전트 실행 환경 안에서 쓰게 하려는 방향이 분명했다.

질의응답에서 한국어 성능 개선 방법에 대한 질문이 나왔다. 답변에선 토크나이저와 한국어 데이터가 중요하게 언급됐다. 앞선 KORMo 발표와 연결되는 지점이었다. 한국어 성능은 단순히 모델 크기만으로 해결되지 않는다. 한국어를 어떻게 토큰화하고, 어떤 데이터를 얼마나 잘 넣느냐가 중요하다.

작은 모델에 대한 질문도 있었다. 한국어를 잘하는 소형 모델이 필요하다는 이야기였고, 업스테이지는 Solar Mini 4 같은 더 작은 모델도 준비하고 있다고 답했다. 에너지 효율에 대해서는 직접적인 환경 지표보다는 GPU를 적게 쓰면서 좋은 성능을 내는 “지표 효율”을 신경 쓰고 있다고 설명했다.

마지막 질문은 큰 모델에서 나타나는 새로운 능력에 관한 것이었다. 김성훈 님은 모델이 커지면서 예상하지 못한 능력이 나타나는 경험이 있었다고 답했다. B2B에선 너무 큰 모델이 부담이 될 수 있지만, 큰 모델에서 나오는 새로운 능력 역시 무시하기 어렵다는 이야기였다.

마무리

이번 밋업은 단순한 기술 세미나라기보다, 한국어 AI 생태계가 어디까지 와 있고 어디가 아직 비어 있는지 확인하는 자리였다.

해례는 한국어 모델을 평가할 기준을 만들고 있었다. Kiwi는 한국어 처리를 위한 오래 가는 오픈소스 도구의 의미를 보여줬다. 박찬성 님의 발표는 도메인 특화 AI에서 모델을 통제할 수 있어야 하는 이유를 설명했다. AWS 세션은 여러 모델과 도구를 엮어 실제 에이전트 시스템을 만드는 방법을 다뤘다. KORMo는 한국어 언어 모델을 처음부터 만들기 위한 데이터와 레시피를 공개하려 했다. Solar 발표는 산업 현장에서 모델을 키우고 에이전트 시대로 옮겨가는 과정을 보여줬다.

발표 주제는 모두 달랐지만, 결국 같은 곳을 가리키고 있었다.

모델 하나만 커진다고 생태계가 만들어지지 않는다. 데이터가 있어야 하고, 평가가 있어야 하고, 토크나이저와 도구가 있어야 한다. 무엇보다 실패와 레시피가 공유되어야 한다. 그래야 다음 사람이 같은 문제를 처음부터 다시 풀지 않아도 된다.

오늘 가장 좋았던 점은 발표자들이 성과만 말하지 않았다는 것이다. 이름을 잘못 지어 사람들이 안 썼던 경험, 데이터가 없어 직접 만들 수밖에 없었던 상황, GPU가 부족해서 택한 우회로, 오픈소스를 유지하며 겪는 피로감, 모델을 키우다가 방향을 잘못 잡았던 순간까지 꽤 솔직하게 나왔다.

그래서 더 좋았다. AI 이야기는 보통 결과만 남는다. 몇 점을 받았는지, 어떤 모델을 이겼는지, 몇 B인지 같은 숫자만 남기 쉽다. 그런데 오늘은 그 숫자 뒤에 있는 사람들의 판단과 시행착오가 보였다.

한국어 AI를 제대로 만들려면 모델만 커져서는 안 된다. 그 모델이 배울 데이터, 이해할 언어 단위, 평가받을 기준, 배포될 도구, 그리고 이 모든 것을 함께 쌓아갈 커뮤니티가 필요하다.

이번 Hugging Face Seoul Meetup은 그 기반이 조금씩 만들어지고 있다는 걸 확인한 자리였다.