MoE(Mixture of Experts, 전문가 혼합)는 하나의 거대한 신경망을 여러 개의 전문가(expert) 네트워크로 쪼개고, 라우터가 토큰마다 그중 일부만 골라 켜는 희소(sparse) 활성화 구조입니다. 모델의 지식 용량은 전체 파라미터로 키우면서 토큰당 연산은 활성 파라미터만큼만 쓰기 때문에, 같은 성능을 더 낮은 추론 비용으로 냅니다. 2026년 현재 DeepSeek·Qwen·Llama 4·Mistral·GPT 계열까지 사실상 모든 프런티어 오픈웨이트 모델이 이 구조를 채택했습니다. 이 글은 라우팅과 희소 활성화의 원리, 추론 비용 절감의 실제 수치, 그리고 기업이 도입할 때의 판단 기준을 한 번에 정리합니다.
목차
- 실무에서 MoE를 처음 만졌던 순간
- MoE란 무엇인가요
- 라우팅과 희소 활성화는 어떻게 동작하나요
- 왜 추론 비용이 줄어드나요
- 2026 대형 LLM은 왜 전부 MoE인가요
- 기업 도입 관점: 언제 쓰고 무엇을 조심해야 하나요
- FAQ
- 같이 읽으면 좋은 것들
실무에서 MoE를 처음 만졌던 순간
작년 겨울, 사내 문서 질의응답 시스템을 새로 얹는 프로젝트에서 모델 후보를 저울질하던 때가 있었습니다. 처음엔 단순하게 생각했어요. 파라미터가 크면 똑똑하고, 크면 비싸다. 그러니 예산에 맞춰 적당히 중간 크기 모델을 고르면 되겠지, 하고요.
그런데 후보 목록에 671B라는 숫자가 붙은 DeepSeek-V3가 올라왔을 때 팀 전체가 잠깐 멈칫했습니다. 671B면 우리가 감당할 수 있는 규모가 아닌데, 라고 다들 반사적으로 생각한 거죠. 그런데 벤치마크 표를 보니 토큰당 추론 속도가 우리가 쓰던 훨씬 작은 모델과 크게 다르지 않았습니다. 뭔가 숫자가 안 맞았어요.
원인은 활성 파라미터였습니다. 671B는 모델이 가지고 있는 파라미터 총합이고, 한 토큰을 처리할 때 실제로 켜지는 건 37B뿐이었던 겁니다. 전체의 5.5% 정도만 일하고 나머지는 그냥 대기 상태로 메모리에 얹혀 있는 구조였죠. 그때 처음으로 "모델 크기"라는 단어를 총 파라미터와 활성 파라미터로 나눠서 봐야 한다는 걸 몸으로 이해했습니다.
이 구분을 놓치면 도입 견적 자체가 틀어집니다. GPU 메모리는 671B 전체를 얹어야 하니 넉넉히 잡아야 하는데, 추론 연산량과 응답 속도는 37B급으로 잡히거든요. 메모리 예산과 연산 예산을 하나로 뭉뚱그려 계산하다가 서버 대수를 잘못 산정할 뻔했던 그 회의가, 저에게는 MoE를 제대로 공부하게 된 계기였습니다.
MoE란 무엇인가요
MoE를 이해하려면 먼저 기존 방식, 즉 밀집(dense) 모델의 비효율부터 봐야 합니다. 트랜스포머 계열 LLM은 각 층에 피드포워드 네트워크(FFN)를 두는데, 밀집 모델은 어떤 토큰이 들어오든 이 FFN 전체를 통과시킵니다. "은행 대출 금리"라는 토큰이든 "바로크 음악"이라는 토큰이든, 매번 똑같이 수천억 개 파라미터를 전부 계산하는 거죠. 직관적으로도 낭비입니다. 금리 얘기를 하는데 음악 지식을 담당하는 뉴런까지 굳이 다 켜야 할 이유는 없으니까요.
MoE는 이 FFN 한 덩어리를 여러 개의 작은 FFN, 즉 전문가(expert)로 쪼갭니다. 그리고 그 앞에 라우터(router) 또는 게이트(gate)라 부르는 작은 신경망을 하나 둡니다. 라우터는 토큰이 들어오면 "이 토큰은 어느 전문가한테 보내는 게 좋을까"를 판단해서, 전체 전문가 중 극히 일부만 골라 활성화합니다. 나머지 전문가는 이번 토큰 계산에서 아예 빠집니다.
정리하면 MoE는 세 가지 부품으로 구성됩니다.
| 구성 요소 | 역할 |
|---|---|
| 전문가(Experts) | 각각 특정 패턴·도메인에 특화되도록 학습된 작은 FFN들 |
| 라우터(Router/Gate) | 토큰마다 어떤 전문가를 켤지 정하는 선택 네트워크 |
| 희소 활성화(Sparse activation) | 전체 전문가 풀 중 소수(Top-K)만 켜는 실행 방식 |
여기서 오해하기 쉬운 부분이 하나 있습니다. 전문가가 "법률 전문가", "코딩 전문가"처럼 사람이 알아볼 만한 주제로 딱 나뉘는 건 아닙니다. 학습 과정에서 자연스럽게 형성되는 통계적 분업에 가까워서, 특정 전문가가 어떤 토큰 패턴을 처리하는지는 사람이 라벨을 붙여준 게 아니라 데이터가 스스로 만든 경계입니다. NVIDIA는 이를 "좁은 행동 영역에 최적화된 특화 서브네트워크"라고 설명합니다.
라우팅과 희소 활성화는 어떻게 동작하나요
한 줄로 요약하면, 라우터가 토큰마다 전문가들에게 점수를 매기고 상위 몇 명만 뽑아 그 결과를 가중합하는 과정입니다.
조금 더 뜯어보겠습니다. 토큰 하나가 MoE 층에 도착하면 라우터는 모든 전문가에 대해 로짓(logit) 점수를 계산하고, 소프트맥스로 확률을 뽑습니다. 그다음 확률이 가장 높은 Top-K개의 전문가만 선택해서 그 전문가들에게만 토큰을 통과시킵니다. 각 전문가의 출력은 라우터가 준 가중치대로 섞여 최종 결과가 됩니다.
숫자를 넣으면 감이 옵니다. DeepSeek-V3는 층마다 256개의 라우팅 전문가를 두고 토큰당 8개를 켭니다. 8/256, 즉 약 3.1%의 전문가만 일하는 셈이죠. 나머지 96.9%는 이번 토큰에서는 계산에 참여하지 않습니다. 이렇게 "가지고 있지만 대부분 꺼두는" 방식이 희소 활성화입니다.
최근 구조에서 자주 보이는 변형이 공유 전문가(shared expert)입니다. DeepSeek-MoE 계열은 전문가를 두 종류로 나눕니다. 라우터가 골라서 켜는 라우팅 전문가와, 라우팅과 무관하게 항상 켜지는 공유 전문가입니다. 공유 전문가는 문법이나 일반 상식처럼 어떤 토큰에나 공통으로 필요한 지식을 담당하고, 라우팅 전문가는 그 위에서 세밀한 특화를 맡습니다. 이렇게 나누면 흔한 지식을 매번 여러 전문가가 중복 학습하는 낭비를 줄일 수 있습니다.
라우팅에는 고질적인 문제가 하나 있는데요. 바로 전문가 붕괴(expert collapse) 또는 부하 불균형입니다. 학습을 하다 보면 라우터가 특정 인기 전문가에게만 토큰을 몰아주고 나머지는 거의 안 쓰는 쏠림이 생깁니다. 그러면 안 쓰이는 전문가는 학습이 안 되고, 결국 모델의 실효 용량이 줄어듭니다. 이를 막으려고 부하 분산 손실(load balancing loss)이나 전문가별 처리량 상한(capacity)을 걸어 토큰을 골고루 흩뿌립니다. 다만 이 보정이 과하면 라우팅 품질이 떨어지는 부작용이 있어서, DeepSeek는 보조 손실을 최소화한 이른바 auxiliary-loss-free 방식으로, Qwen 3.5는 GDN(Global Dense Normalization)이라는 기법으로 이 균형을 다시 손보고 있습니다. 라우터를 어떻게 안정적으로 학습시키느냐가 사실상 MoE 품질의 절반입니다.
왜 추론 비용이 줄어드나요
기업 입장에서 MoE가 매력적인 진짜 이유는 성능보다도 비용 구조입니다. 이 부분은 조금 자세히 봐야 오해가 없습니다.
밀집 모델에서 추론 연산량은 대략 파라미터 수에 비례합니다. 671B 밀집 모델이라면 토큰마다 671B를 전부 곱하고 더해야 하죠. 반면 MoE는 활성 파라미터만 계산하므로, 671B를 가지고도 실제 연산은 37B급입니다. DeepSeek-V3 기준으로 보면 동일 규모 밀집 모델 대비 토큰당 연산이 약 5배 적습니다. 추론 비용과 응답 속도는 총 파라미터가 아니라 활성 파라미터가 결정한다는 게 핵심입니다.
비유하자면 이렇습니다. 671B 전체는 여러분이 고용한 전문가 명단이고, 37B는 이번 질문에 실제로 회의에 들어온 몇 명입니다. 명단이 아무리 길어도 회의비는 참석자 수만큼만 나가는 셈이죠. 그래서 한 자료는 671B MoE 모델을 두고 "실질적으로는 671B어치 전문 지식을 필요할 때 꺼내 쓸 수 있는 37B 모델"이라고 표현하기도 합니다.
다만 여기엔 반드시 짚어야 할 함정이 있습니다. 메모리는 총 파라미터를 따라간다는 점입니다.
| 구분 | 무엇을 따라가나 |
|---|---|
| 연산량·추론 속도 | 활성 파라미터 (예: 37B) |
| GPU 메모리 사용량 | 총 파라미터 (예: 671B) |
전문가 대부분이 이번 토큰에 안 켜지더라도, 언제 호출될지 모르니 671B 전체를 메모리에 다 올려둬야 합니다. 즉 MoE는 연산은 싸지만 메모리는 비싼 구조입니다. 이 특성 때문에 MoE 서빙은 여러 GPU에 전문가를 나눠 배치하는 전문가 병렬화(expert parallelism)와 통신 스케줄링이 중요해지고, 결국 AI 반도체와 메모리 대역폭이 실제 서빙 비용을 좌우하게 됩니다. 이 대목을 놓치면 "활성 37B니까 작은 GPU 하나면 되겠지" 하고 견적을 잡았다가 메모리 부족으로 낭패를 봅니다. 제가 앞에서 회의 때 겪을 뻔한 실수가 정확히 이거였습니다.
2026 대형 LLM은 왜 전부 MoE인가요
2026년 현재, 진지한 오픈웨이트 모델치고 MoE가 아닌 것을 찾기가 오히려 어렵습니다. 2026 현황 정리를 보면 DeepSeek-V3/R1과 V4, Qwen3-235B-A22B, Llama 4 패밀리, Mistral Large 3, Kimi K2, Grok 계열, GPT-5/GPT-OSS까지 사실상 모든 프런티어 모델이 희소 전문가 라우팅을 씁니다.
이렇게 표준이 된 이유는 스케일링의 경제학이 바뀌었기 때문입니다. 밀집 모델은 똑똑해지려면 파라미터를 키워야 하고, 파라미터를 키우면 학습·추론 비용이 그대로 같이 뜁니다. 성능과 비용이 한 몸으로 묶여 있죠. MoE는 이 둘을 분리합니다. 용량은 전문가를 늘려 키우고, 연산은 Top-K를 낮게 유지해 억제합니다. 덕분에 "더 큰 지식, 비슷한 비용"이라는, 밀집 모델로는 불가능하던 조합이 열렸습니다.
대표 모델 몇 개를 활성/총 파라미터로 비교하면 흐름이 보입니다.
| 모델 | 총 파라미터 | 활성 파라미터 | 전문가 구성 |
|---|---|---|---|
| DeepSeek-V3/R1 | 약 671B | 약 37B | 라우팅 256 + 공유 1, Top-8 |
| Qwen3-235B-A22B | 약 235B | 약 22B | 128 전문가 중 8개 활성 |
| Llama 4 Maverick | 약 400B | 약 17B | 라우팅 128 + 공유 1, 밀집/MoE 층 교차 |
또 하나 눈에 띄는 흐름은 세밀한 전문가(fine-grained experts)로의 이동입니다. 예전엔 Mixtral 8x7B처럼 큼직한 전문가 8개를 두는 식이었다면, 요즘은 전문가를 잘게 쪼개 128개, 256개, 그 이상으로 늘리고 각각을 더 작게 만듭니다. 전문가가 많고 작을수록 특화가 세밀해지고, 소수 전문가에 부하가 몰려 붕괴하는 위험도 분산됩니다. 초기 MoE의 대명사였던 Mixtral 8x7B가 훨씬 큰 밀집 모델급 품질을 5분의 1 수준 추론 연산으로 냈던 사례가 이 접근의 출발점이었고, 지금은 그 방향이 더 극단으로 간 셈입니다.
기업 도입 관점: 언제 쓰고 무엇을 조심해야 하나요
기존 방식에서는 모델을 고를 때 "몇 B짜리냐" 한 줄이면 대충 견적이 나왔습니다. MoE 시대에는 그 한 줄로는 부족합니다. 총 파라미터·활성 파라미터·전문가 구성 세 가지를 같이 봐야 실제 인프라 비용이 잡힙니다. 아래는 초보자도 순서대로 따라갈 수 있는 4단계 점검 흐름입니다.
1단계, 워크로드 성격을 먼저 정합니다. 대량의 요청을 빠르고 저렴하게 처리하는 게 목표라면 활성 파라미터가 작은 MoE가 유리합니다. 반대로 GPU 메모리가 빠듯한 환경이라면 총 파라미터가 큰 MoE는 오히려 부담이니, 이럴 땐 작고 특화된 소형 언어 모델(SLM)이 더 맞을 수 있습니다.
2단계, 메모리와 연산 예산을 따로 산정합니다. 앞서 말한 대로 메모리는 총 파라미터, 속도·연산은 활성 파라미터 기준입니다. 이 둘을 분리해 계산하지 않으면 서버 대수 산정이 어긋납니다.
3단계, 서빙 방식을 정합니다. MoE는 전문가를 여러 GPU에 나눠 얹는 전문가 병렬화가 기본이라, 노드 간 통신이 병목이 되기 쉽습니다. 자체 서빙이 부담되면 활성 파라미터 기준으로 과금하는 API·매니지드 서빙을 먼저 써보고 트래픽 패턴을 확인한 뒤 내재화를 검토하는 편이 안전합니다.
4단계, 지식 최신화 전략을 붙입니다. MoE든 밀집이든 모델 내부 지식은 학습 시점에 고정됩니다. 자주 바뀌는 사내 지식은 모델 구조와 별개로 RAG나 파인튜닝으로 보강해야 합니다. MoE는 "어떤 그릇을 쓸까"의 문제고, RAG·파인튜닝은 "그 그릇에 무엇을 담을까"의 문제라 서로 대체재가 아니라 보완재입니다.
조심할 점도 분명히 있습니다. MoE는 라우팅이라는 추가 부품이 있어 학습과 서빙 모두 밀집 모델보다 운영 복잡도가 높습니다. 부하 불균형, 전문가 병렬화 통신 오버헤드, 메모리 상주 비용 같은 요소가 실제 청구서에 그대로 반영됩니다. 그래서 "MoE라서 무조건 싸다"는 건 절반만 맞는 말입니다. 활성 파라미터 기준 연산은 확실히 싸지만, 메모리와 운영은 오히려 손이 더 갈 수 있다는 점을 함께 봐야 도입 판단이 흔들리지 않습니다.
FAQ
MoE 모델은 밀집 모델보다 항상 성능이 좋은가요?
아닙니다. 같은 활성 파라미터끼리 비교하면 MoE가 더 많은 총 지식을 담아 유리한 경우가 많지만, 라우팅 품질이나 학습 안정성에 따라 결과는 달라집니다. MoE의 강점은 "성능"보다 같은 성능을 더 낮은 추론 연산으로 낸다는 비용 효율에 있습니다. 성능만 놓고 무조건 우위라고 단정하긴 어렵습니다.활성 파라미터가 37B면 37B GPU 한 장으로 돌릴 수 있나요?
아니요. 연산량은 활성 파라미터를 따라가지만 메모리는 총 파라미터를 따라갑니다. 671B 모델이라면 전문가 전체를 메모리에 올려야 하므로, 활성이 37B라도 실제로는 여러 GPU에 나눠 얹어야 합니다. 이 구분을 놓치면 인프라 견적이 크게 어긋납니다.전문가 하나하나가 특정 주제를 담당하나요?
사람이 알아볼 만한 주제로 깔끔하게 나뉘지는 않습니다. 학습 과정에서 데이터가 스스로 만든 통계적 분업에 가까워서, 어떤 전문가가 어떤 패턴을 맡는지는 미리 정해준 라벨이 아닙니다. "법률 전문가", "코딩 전문가" 같은 직관적 분류로 이해하면 오해가 생깁니다.MoE와 RAG·파인튜닝은 경쟁 관계인가요?
아닙니다. MoE는 모델 구조에 관한 이야기이고, RAG와 파인튜닝은 그 모델에 어떤 지식을 어떻게 담고 최신화할지에 관한 이야기입니다. 층위가 달라서 MoE 모델 위에 RAG를 얹고 파인튜닝까지 하는 조합이 얼마든지 가능합니다. 대체재가 아니라 보완재로 보는 게 맞습니다.MoE 도입이 기존 밀집 모델 도입보다 얼마나 더 복잡한가요?
라우팅과 전문가 병렬화라는 부품이 추가되므로 서빙 난이도는 밀집 모델보다 높습니다. 부하 불균형 관리, 노드 간 통신 최적화, 큰 메모리 상주가 대표적 부담입니다. 다만 대부분의 기업은 직접 서빙보다 매니지드 API로 시작하므로, 초기 도입 체감 난이도는 밀집 모델과 크게 다르지 않습니다.같이 읽으면 좋은 것들
출처
- What Is Mixture of Experts (MoE) and How It Works? — NVIDIA Glossary
- What is mixture of experts? — IBM Think
- DeepSeek-V3 Technical Report (2024)(ScholarlyArticle)
- LLM Mixture of Experts Explained — A 2026 Field Guide (TensorOps)(BlogPosting)
- The MoE-ification of the Open Model Ecosystem, and What It Means for Your Inference Bill (DigitalOcean)(BlogPosting)