오늘 네이버에서 독자 파운데이션 모델로 HyperCLOVA X SEED Think 32B, HyperCLOVA X Omni 8B 두가지 모델을 오픈소스로 공개했네요. 이 중 32B 모델은 dense 모델이라고 합니다. 그런데, 어떤 분이 MoE와 같은 sparse 구조가 아니라 왜 dense 로 한거지? 라고 하시는데.. deepseek 때문에 sparse 구조가 트랜드처럼 되버렸지만, dense 모델은 여전히 중요합니다.
그래서 생각난 김에 정리해봤습니다.
“이제 dense 모델은 한계에 다다른 것 아닌가?”,
“MoE와 같은 sparse 구조가 결국 표준이 되지 않겠는가?”
이렇게 보면, 무언가 모델 아키텍쳐 선택의 문제처럼 보입니다. 그러나 이건 모델 구조의 우열이라기보다는 AI 스케일링 문제가 직면한 구조적 한계에 대한 대응입니다. 연산 자원의 물리적 제약, 전력과 냉각 비용, HBM과 인터커넥트, 그리고 이를 감당해야 하는 데이터센터와 국가 인프라 전략까지 모두 얽혀 있죠. 그러니까, Dense와 Sparse는 경쟁 관계라기보다, AI가 다음 단계로 진화하는 과정에서 필연적으로 분화된 두 축이라고 봐야 합니다.
– Dense 모델은 원래는 기본값
Dense 모델이라는 용어는 사실 비교적 최근에야 널리 쓰이기 시작했습니다. 이유는 단순합니다. 오랫동안 모든 모델이 dense였기 때문입니다. 입력 토큰이 들어오면, 모든 레이어의 모든 파라미터가 항상 계산에 참여하는 구조는 너무도 당연한 전제였기 때문에, 굳이 이름을 붙일 이유조차 없었습니다.
GPU는 본질적으로 대규모 병렬 연산과 연속적인 메모리 접근에 최적화된 장치입니다. 트랜스포머 기반 dense 모델은 이 특성과 자연스럽게 맞아떨어졌고, CUDA 커널, 컴파일러, HBM, NVLink로 이어지는 생태계 전체가 dense 를 중심으로 성숙해왔습니다. 모델 구조와 하드웨어 구조가 서로를 강화하며 성장해온 셈입니다.
Dense 모델의 강점은 지금도 유효합니다. 학습은 안정적이며, gradient 흐름은 균일하고, 수렴 경로는 비교적 예측 가능합니다. 추론 시에도 latency 변동성이 작고, 작은 배치에서도 성능 저하가 크지 않습니다. 무엇보다 서비스 관점에서 신뢰할 수 있다는 점이 결정적입니다. 공공, 금융, 의료처럼 실패 비용이 큰 영역에서 dense 모델이 여전히 기본입니다.
그런데 문제는 결국 스케일링입니다. 파라미터 수를 늘릴수록 성능은 개선되지만, 그 개선 폭은 점점 완만해집니다. 반면 FLOPs, 전력 소비, 메모리 요구량, 비용은 여전히 크게 증가하며, 대규모 구간에서는 성능 대비 비용 효율이 급격히 악화됩니다. GPU 성능 향상이 이를 어느 정도 상쇄해주던 시기는 지났구요.
결국, Dense 모델의 한계는 기술적 실패가 아니라, 물리적·경제적 제약의 문제입니다. 더 이상 “그냥 키우면 된다”는 전략이 한계치에 다다른겁니다.
– Sparse 모델은 연산의 선택
Sparse 모델, 특히 Deepseek 때문에 유명해진 MoE(Mixture of Experts)는 바로 이 지점에서 등장했습니다. 핵심 아이디어는 모델의 전체 파라미터 수와 실제 연산에 참여하는 파라미터 수를 분리하자는 발상입니다.
Sparse 모델에서는 토큰이 들어올 때마다 전체 파라미터가 아니라, 라우터가 선택한 일부 expert만 연산에 참여합니다. 그래서, 모델 전체의 파라미터 수가 크게 증가하더라도, 토큰당 실제 연산량은 제한할 수 있습니다. 전체를 돌릴 필요가 없다는거죠. 이론적으로는 동일한 연산 비용으로 더 큰 지식 용량을 갖는 모델을 구성할 수 있으며, dense 모델에서 둔화되던 파라미터 증가에 따른 성능 개선 효과를 다시 한 번 기대할 수 있는 것입니다.
그러다보니, 대규모 학습, 연구 환경에서 빠르게 확산됐고, sparse가 dense 다음의 미래인것처럼 알려지기도 했습니다.
그런데, sparse가 그리 단순하지는 않다고 합니다. 라우팅은 불안정할 수 있고, 특정 expert로 토큰이 쏠리는 현상이 반복적으로 발생합니다. 이를 막기 위해 expert들이 골고루 사용되도록 강제하는 load balancing loss 같은 추가적인 장치가 필요해집니다. 그 자체로 학습 난이도는 상승할수 밖에 없죠.
무엇보다 시스템 비용이 만만치 않습니다. sparse 는 연산비용을 줄이려고 한건데, 그러다보니 시스템 비용이 늘어납니다. expert가 분산되어 있을수록 통신 오버헤드는 커지고, 메모리 접근은 불규칙해집니다. 이론적으로 줄어든 FLOPs가 실제 실행 시간 단축으로 이어지지 않는 경우가 적지 않습니다. 특히 소배치, 실시간 추론 환경에서는 sparse의 장점이 쉽게 상쇄됩니다. 이 때문에 sparse는 “이론적으로는 매력적이지만, 운영하기는 까다로운 구조”라는 평가를 동시에 받습니다. 그래서, 싸냐, 비싸냐 문제보다는 이 복잡성을 감당할수 있냐 하는 문제라고 합니다.
– Dense와 Sparse의 관계
그래서, Dense와 Sparse는 대체 관계가 아니라, 역할 분화 관계에 가깝습니다.
실제 대형 모델 아키텍처를 보면, 점점 하이브리드 구조가 늘어나고 있습니다. 하위 레이어는 dense로 유지해 안정적인 표현 학습과 추론 경로를 확보하고, 상위 레이어나 특정 블록만 sparse로 구성해 용량을 확장합니다. 핵심 추론 경로는 고정하고, 지식 저장이나 확장 영역만 선택적으로 풀어주는 방식입니다.
dense 모델은 계산 경로가 고정되어 있고 성능과 자원 사용이 예측 가능하다는 점에서 여전히 기준선 역할을 합니다. Sparse 모델은 이러한 dense 구조 위에 선택적 계산과 분업을 얹는 확장 메커니즘에 가깝습니다. 실제로 sparse 모델의 라우터와 공통 표현 공간은 대부분 dense로 구성되며, dense 기반의 안정성이 없으면 sparse 구조는 학습과 운영 모두에서 불안정해지기 쉽습니다.
– 학습과 추론의 분리와 Dense vs Sparse
Dense vs Sparse 논쟁을 복잡하게 만드는 또 하나의 축은 학습과 추론의 분리입니다. 학습 단계에서는 대규모 배치와 장시간 연산이 가능하고, 전용 인프라를 구성할 수 있습니다. 이 환경에서는 통신 비용이나 일시적인 불균형이 일정 수준까지는 허용되며, 전체 파라미터 용량을 확장하는 데 유리한 sparse 구조의 장점이 비교적 잘 드러납니다. 다시 말해, 학습 단계에서는 시스템 복잡성을 감수하더라도 연산 효율과 모델 용량을 실험해볼 여지가 있습니다.
반면 추론 환경은 전혀 다른 제약을 가집니다. 실시간성, 소배치 처리, 그리고 무엇보다 안정적인 latency가 핵심 요구사항입니다. 이 조건에서는 계산 경로가 고정되어 있고 자원 사용이 예측 가능한 dense 구조의 장점이 여전히 압도적입니다. 라우팅에 따른 분기, 통신 오버헤드, 자원 활용률 변동이 발생하는 sparse 구조는 이러한 요구사항과 쉽게 충돌할 수 있습니다.
그래서, 실제 현장에서는 학습은 sparse를 통해 확장 가능성을 탐색하고, 서비스 추론은 dense를 기준으로 운영하는 이중 구조가 나타납니다.
– 해석가능 AI를 위한 Sparse
Dense vs Sparse 에 대하여 효율과 스케일링 문제를 얘기했는데, 최근 OpenAI의 연구는 또 다른 관점입니다. Sparse는 연산 효율을 넘어서, 해석가능한 AI를 만들기 위한 구조적 수단이 될 수 있다는 점입니다. 쉽게 말해 dense 는 복잡해서 들여다보기 힘든데, sparse 는 상대적으로 간단해서 추적할수 있다는 말입니다. 얼마전에 제가 페이스북에 OpenAI 연구를 포스팅한 적 있으니 참고…. https://www.facebook.com/share/p/18ALDM15SJ/
OpenAI 연구의 핵심은… 간단히 말하면, 중요하다고 판단된 소수의 가중치만 남기고 나머지는 모두 제거해 연결 구조를 극도로 단순화함으로써, 각 뉴런의 역할이 명확하고 회로가 몇 개에서 수십 개 노드 수준으로 해부 가능한 Sparse LLM을 만들고, 이렇게 찾은 구조를 Bridges를 통해 Dense LLM과 대응시켜 Dense 모델의 작동 원리를 간접적으로 추적하는 방식입니다.
물론, 기존 MoE 중심의 sparse 논의와는 다릅니다. 지금까지의 sparse 논의가 “어떤 파라미터를 계산에서 제외할 것인가”에 초점을 맞췄다면, OpenAI의 접근은 “어떤 연결이 실제로 의미 있는 계산을 담당하고 있는가”를 구조적으로 드러내는 데 초점을 둡니다.
지금까지 해석가능성 연구는 대부분 dense 모델을 전제로, 그 내부를 사후적으로 분석하는 방식이었습니다. 그러나 dense 모델은 구조적으로 너무 많은 계산 경로가 동시에 활성화되기 때문에, 해석은 언제나 부분적일 수밖에 없습니다. OpenAI의 sparse 접근은 이 문제를 정면으로 뒤집습니다. 해석하기 어려운 구조를 분석하는 대신, 애초에 해석 가능한 구조를 설계하자는 접근입니다.
OpenAI도 sparse 모델을 dense 모델의 대체재로 보지 않았죠, sparse 모델에서 발견된 해석 가능한 회로를 dense 모델의 활성화와 연결하는 ‘브리지’ 개념을 통해, sparse를 해석을 위한 도구, dense를 실행을 위한 구조로 분리합니다.
– dense 와 GPU
Dense vs Sparse는 결국 모델 단독의 문제가 아니라 시스템 전체의 문제입니다. 모델은 혼자 존재하지 않으며, 컴파일러, 런타임, 네트워크, 메모리 계층, 스케줄러까지 포함된 하나의 실행 시스템 위에 놓입니다.
Sparse 모델의 성패는 아키텍처 설계 자체보다 시스템 설계 역량에 더 크게 좌우됩니다. 고속 인터커넥트 없이는 sparse의 이점이 쉽게 사라지고, 런타임 최적화가 부족하면 routing 비용이 곧바로 병목으로 전환됩니다. 이로 인해 sparse는 모델 구조보다도 시스템 성숙도가 성능을 결정하는 구조라고 볼 수 있습니다.
지금까지 GPU는 일관되게 dense 연산에 최적화된 방향으로 진화해왔습니다. 대규모 병렬 연산, 연속적인 메모리 접근, 높은 연산 밀도는 dense 모델과 매우 잘 맞습니다. 반면 sparse 구조는 더 정교한 메모리 관리, 더 빠른 통신, 그리고 훨씬 복잡한 스케줄링을 요구합니다. 이 과정에서 설계 복잡성이 급격히 증가하고, 반복적인 재설계와 튜닝 비용이 발생하는 경우도 적지 않습니다.
이런 맥락에서 중국이 DeepSeek를 비롯한 일부 모델에서 sparse 기반을 적극적으로 탐색하고 있는 흐름은, 단순한 모델 선택을 넘어 장기적으로는 NVIDIA GPU와 CUDA 중심 생태계에 대한 의존도를 낮추기 위한 전략적 여지를 넓히려는 시도로도 해석할 수 있습니다. Sparse 구조는 하드웨어와 소프트웨어의 공동 설계 여지가 크기 때문에, 기존 생태계에 덜 종속적인 선택지를 제공할 수 있기 때문입니다
– 공공에서는? Dense or Sparse ?
공공 AI나 소버린 AI를 논할 때, sparse는 해답이 아닐수 있습니다. 공공 AI가 요구하는 핵심 가치는 단순한 성능 경쟁이 아니라 안정성, 예측 가능성, 그리고 통제 가능성입니다. 이 관점에서 보면, 인프라 통제력이 충분히 확보되지 않은 상태에서의 sparse 구조는 오히려 시스템 불확실성을 키울 수 있습니다. 라우팅에 따른 성능 변동, 통신 병목, 운영 복잡성은 공공 서비스가 감내하기 어려운 위험 요소입니다.
그래서 dense 기반의 안정적인 추론 경로가 알맞습니다. 연산 경로가 고정되어 있고, 지연 시간과 자원 사용이 예측 가능하며, 장애 상황에서도 원인 분석과 복구가 상대적으로 용이하기 때문입니다. (장애 트라우마….) 공공 서비스에서 중요한 것은 최고 성능이 아니라, 항상 같은 수준의 성능을 보장할 수 있는 신뢰성입니다.
이런 맥락에서 보면, 네이버가 이번 독자파운데이션 모델에서 dense 기반 모델을 내놓은 선택은 기술적으로나 전략적으로 자연스러운 결과에 가깝습니다. sparse를 부정한 선택이 아니라, 공공·국가 단위에서 요구되는 안정성과 책임성을 우선한 판단으로 해석할 수 있는것 같습니다. 특히 국내 공공 환경과 서비스 요구를 고려할 때, dense는 여전히 기준선으로 삼기 가장 합리적인 구조입니다.
물론 연구들을 보면 흐름 자체는 분명 sparse입니다. 대규모 학습과 용량 확장의 관점에서 sparse가 제공하는 가능성은 명확합니다. 하지만, 기반은 여전히 dense이며, 실제 운영 환경에서는 dense와 sparse를 상황에 따라 결합하는 hybrid 구조가 가장 현실적인 선택으로 자리 잡고 있습니다.
