회사에서 사내 문서 검색 시스템을 만들고 있었습니다. Claude API를 쓰고 있었는데, 월 비용이 슬슬 부담되기 시작하더군요. "오픈소스 모델로 바꾸면 비용을 반 이하로 줄일 수 있지 않을까?" 하는 생각이 들었을 때, 마침 Meta가 Llama 4를 공개했습니다.

AI 모델의 핵심인 반도체 칩. Llama 4는 MoE 아키텍처로 효율적인 추론을 실현합니다. (Photo by Igor Omilaev on Unsplash)

솔직히 Llama 3까지는 "오픈소스치고 괜찮네" 수준이었습니다. 상용 모델과 직접 비교하면 아쉬운 부분이 분명히 있었거든요. 그런데 Llama 4는 처음부터 이야기가 달랐습니다. MoE(Mixture of Experts) 아키텍처를 도입하고, 네이티브 멀티모달을 지원하고, Scout은 무려 1,000만 토큰 컨텍스트 윈도우를 제공한다고요. 이건 한번 제대로 살펴봐야겠다 싶었습니다.

Scout과 Maverick, 뭐가 다른 건가

이름만 봐서는 Scout이 가벼운 버전이고 Maverick이 무거운 버전인가 싶지만, 실제로는 그렇게 단순하지 않습니다. 둘 다 활성 파라미터는 17B로 동일하지만, 전문가(expert) 수와 총 파라미터에서 큰 차이가 납니다.

항목 Llama 4 Scout Llama 4 Maverick 활성 파라미터 17B 17B 전문가(Expert) 수 16개 128개 총 파라미터 ~109B ~400B 컨텍스트 윈도우 10M 토큰 1M 토큰 MMLU Pro 74.3% 80.5% GPQA Diamond 57.2% 69.8% GPU 요구사항 H100 1대 H100 여러 대 멀티모달 텍스트 + 이미지 텍스트 + 이미지 핵심을 한 줄로 요약하면: Scout은 효율성과 긴 컨텍스트에 특화, Maverick은 순수 성능에 특화입니다.

MoE 아키텍처는 여러 전문가 네트워크 중 적합한 것만 활성화하여 효율성을 극대화합니다. (Photo by Google DeepMind on Unsplash)

MoE 아키텍처가 뭔지 간단히 설명하면, 레스토랑에 비유할 수 있습니다. 일반 모델이 한 명의 만능 셰프라면, MoE는 16명(Scout) 또는 128명(Maverick)의 전문 셰프가 있는 주방인 셈입니다. 주문이 들어오면 가장 적합한 셰프가 요리를 맡습니다. 전체 셰프가 동시에 일하지 않아도 되니까, 파라미터 대비 훨씬 효율적으로 동작합니다.

설치와 실행: 생각보다 문턱이 낮다

Scout은 H100 한 대면 로컬에서 돌릴 수 있다는 점이 매력적이지만, 현실적으로 개인 개발자가 H100을 갖고 있진 않죠. 그래서 저는 Together.ai와 HuggingFace Inference API 두 가지 경로로 테스트했습니다.

Together.ai를 통한 빠른 시작:

Together.ai API를 통한 Llama 4 Maverick 호출 import together client = together.Together(api_key="your-api-key") response = client.chat.completions.create( model="meta-llama/Llama-4-Maverick-17B-128E-Instruct-FP8", messages=[ {"role": "system", "content": "You are a helpful coding assistant."}, {"role": "user", "content": "Python으로 간단한 REST API 서버를 만들어줘. FastAPI를 사용하고, /health 엔드포인트를 포함해줘."} ], max_tokens=1024, temperature=0.7 ) print(response.choices[0].message.content) 설정 자체는 5분이면 끝납니다. Together.ai 가입하고 API 키 발급받으면 바로 사용할 수 있습니다. 요금도 Maverick 기준으로 입력 $0.27/1M 토큰, 출력 $0.85/1M 토큰 수준이라 Claude나 GPT 대비 상당히 저렴합니다.

HuggingFace Transformers로 Scout 실행:

HuggingFace Transformers를 통한 Scout 로컬 실행 (GPU 필요) from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_id = "meta-llama/Llama-4-Scout-17B-16E-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype=torch.bfloat16, device_map="auto" ) messages = [ {"role": "user", "content": "이 코드의 시간복잡도를 분석해줘:\ndef two_sum(nums, target):\n seen = {}\n for i, n in enumerate(nums):\n if target - n in seen:\n return [seen[target-n], i]\n seen[n] = i"} ] input_ids = tokenizer.apply_chat_template(messages, return_tensors="pt").to(model.device) output = model.generate(input_ids, max_new_tokens=512) print(tokenizer.decode(output[0][input_ids.shape[-1]:], skip_special_tokens=True)) Scout을 로컬에서 돌리려면 최소 VRAM 80GB가 필요합니다. A100이나 H100 환경이 아니라면 API 경로가 현실적입니다.

실제 써보니: 벤치마크와 체감은 다르다

벤치마크부터 확인해보겠습니다. Meta 공식 발표에 따르면, Maverick은 LMArena에서 1400점을 넘기며 GPT-4o와 Gemini 2.0 Flash를 앞질렀다고 합니다. Scout 역시 같은 클래스에서 Gemma 3, Mistral 3.1을 이겼다고 하고요.

Maverick은 MMLU Pro 80.5%, GPQA Diamond 69.8%로 같은 클래스 최고 성적을 기록했습니다. 다만 독립 검증 결과는 엇갈립니다. (Photo by Luke Chesser on Unsplash)

그런데 여기서 솔직히 말해야 할 부분이 있습니다. 독립적인 재현 테스트에서는 Meta의 공식 벤치마크 수치를 재현하지 못했다는 보고가 여럿 나왔습니다. IT Pro 등 외신에서는 Meta 임원이 벤치마크 과장 의혹을 부인했다는 기사까지 나왔고요. 이건 오픈소스 모델이라 누구나 검증할 수 있다는 게 오히려 장점인 셈인데, 결과적으로 "공식 수치를 100% 믿긴 어렵다"는 게 커뮤니티 분위기입니다.

제가 직접 사내 문서 요약 태스크로 테스트해본 체감으로는, Maverick은 코딩과 추론에서 Claude 3.5 Sonnet의 80-85% 수준, Scout은 70-75% 수준이었습니다. 물론 이건 제 특정 유스케이스 기준이고, 단순 QA나 번역 같은 태스크에서는 격차가 더 줄어들 수도 있습니다.

Scout은 H100 한 대에서 실행 가능하지만, 개인 개발자에게 H100은 여전히 먼 이야기입니다. (Photo by imgix on Unsplash)

특히 Scout의 10M 토큰 컨텍스트 윈도우는 실감이 잘 안 올 수 있는데, 이게 대략 코드 파일 수천 개, 혹은 책 10권 분량을 한 번에 넣을 수 있는 크기입니다. 사내 문서 전체를 RAG 없이 통째로 집어넣는 게 가능해지는 거죠. 물론 10M 토큰을 실제로 다 채우면 추론 속도가 상당히 느려지긴 합니다. 제 테스트에서는 약 50만 토큰 정도가 속도와 품질의 균형점이었습니다.

장점 3가지

1. 비용 효율이 압도적이다

API 기준으로 Maverick은 Claude 3.5 Sonnet 대비 약 1/3 가격에 사용할 수 있습니다. 셀프 호스팅하면 더 떨어지고요. 월 API 비용이 $500 이상인 프로젝트라면 진지하게 마이그레이션을 고려할 만합니다.

2. Scout의 10M 컨텍스트는 게임 체인저다

긴 문서 처리에서 Scout의 10M 컨텍스트 윈도우는 진짜 경쟁력입니다. RAG 파이프라인을 구축하는 대신 문서를 통째로 넣을 수 있으니, 아키텍처가 훨씬 단순해집니다. 청킹(chunking) 전략 잘못 잡아서 컨텍스트가 날아가는 문제도 없고요.

3. 네이티브 멀티모달이 오픈소스에서 가능해졌다

텍스트와 이미지를 동시에 처리하는 멀티모달 기능이 오픈소스 모델에 들어온 건 의미가 큽니다. 제품 이미지 분석, 스크린샷 기반 코드 생성 같은 유스케이스를 상용 API 없이도 구현할 수 있게 되었습니다.

단점 3가지

1. 벤치마크 논란이 신뢰를 깎는다

앞서 언급했듯이, 독립 평가에서 공식 벤치마크를 재현하지 못한 사례가 있습니다. 이건 모델 자체의 문제라기보다 발표 방식의 문제이지만, 결과적으로 "이 수치를 믿어도 되나?"라는 의문이 생깁니다. 실제 프로덕션 적용 전에 본인 데이터로 직접 평가하는 과정이 필수입니다.

2. 로컬 실행 하드웨어 문턱이 여전히 높다

Scout이 "H100 한 대면 된다"고 하지만, H100 한 대가 약 3만 달러입니다. Maverick은 여러 대가 필요하고요. 클라우드 GPU를 빌리는 것도 방법이지만, 그러면 비용 이점이 줄어들죠. 개인 개발자나 소규모 팀에게는 API 경로가 사실상 유일한 선택지입니다.

3. 코딩 특화 태스크에서 Claude/GPT 대비 뚜렷한 격차

일반적인 QA에서는 괜찮지만, 복잡한 코드 생성이나 디버깅에서는 체감 차이가 있습니다. 특히 한국어 프롬프트를 영어로 바꿔서 넣었을 때 오히려 품질이 올라가는 현상이 있었는데, 한국어 학습 데이터가 상용 모델만큼 충분하지 않은 것으로 보입니다.

코딩 특화 태스크에서는 아직 상용 모델 대비 체감 격차가 있습니다. 특히 한국어 프롬프트에서 더 두드러집니다. (Photo by Andrew on Unsplash)

누구에게 추천하나

추천하는 경우:

API 비용이 월 $300 이상이라 비용 최적화가 필요한 팀 긴 문서(계약서, 논문, 코드베이스)를 통째로 분석해야 하는 유스케이스 → Scout 셀프 호스팅으로 데이터를 외부에 보내지 않아야 하는 보안 요구사항이 있는 조직 멀티모달 기능을 오픈소스 환경에서 실험하고 싶은 개발자 비추천하는 경우:

코딩 어시스턴트가 주 용도라면 아직은 Claude Code나 GPT-5.3이 낫습니다 한국어 자연어 처리 품질이 핵심이라면 아직 상용 모델이 우위 GPU 인프라 없이 로컬 실행을 원하는 개인 개발자 (API는 가능하지만 로컬은 현실적으로 어려움)

마무리: 오픈소스 LLM, 어디까지 왔나

Llama 4를 2주 정도 써보면서 느낀 건, 오픈소스 LLM이 "상용 모델을 완전히 대체"하는 단계는 아직 아니지만, "특정 유스케이스에서는 충분히 실전 투입할 수 있는" 단계까지 왔다는 점입니다. 특히 비용 민감한 프로젝트나 데이터 주권이 중요한 환경에서 Llama 4의 가치는 명확합니다.

벤치마크 논란은 아쉽지만, 오픈소스이기 때문에 커뮤니티가 직접 검증하고 개선할 수 있다는 점은 확실한 장점입니다. DeepSeek도 그렇고, 이제 오픈소스 LLM 생태계는 무시할 수 없는 수준으로 성장했습니다. 2026년 하반기에 공개 예정인 Llama 4 Behemoth(2T 파라미터)가 나오면 또 판도가 바뀔 수 있겠죠.

혹시 Llama 4를 이미 프로젝트에 적용해보신 분 계신가요? 특히 한국어 태스크에서의 경험이 궁금합니다.

내부 링크:

• DeepSeek은 정말 OpenAI를 베꼈을까? — AI 모델 디스틸레이션 논란 총정리 (오픈소스 LLM 논란 비교)
• Claude Opus 4.6 vs GPT-5.3 Codex — 같은 날 출시된 두 AI (상용 LLM과의 비교 관점)