왜 MoE 아키텍처가 등장했나? - Trinity 모델 툴콜링 이슈에서 출발한 탐구

도입: Trinity 모델의 툴콜링 한계

최근 OpenRouter에서 무료로 제공되는 Trinity 모델을 사용하면서 흥미로운 현상을 발견했습니다. 이 모델은 복잡한 추론에는 꽤 강한데, 툴콜링(API나 스크립트 호출)이 제대로 동작하지 않는 경우가 종종 발생합니다. 원인을 찾아보니 이 모델은 Mixture of Experts(MoE) 아키텍처를 사용하며, 추론 시 전체 파라미터 중 일부 전문가(Expert)만 활성화된다는 사실을 알게 되었습니다.

그렇다면 왜 MoE 같은 아키텍처가 등장하게 되었을까요? 그리고 이 설계 선택은 어떤 trade-off를 내포하고 있을까요?

MoE 아키텍처의 핵심 아이디어

MoE는 "전문가들의 혼합"입니다. 하나의 거대한 모델 안에 여러 전문가 서브네트워크(Expert)를 두고, 각 입력에 대해 라우터(Router)가 "어떤 전문가를 얼마나 활성화할지"를 결정합니다.

핵심 특징:

• Sparse Activation: 매번 모든 전문가를 쓰지 않고, 필요한 일부만 활성화.
• 계산 효율: 활성화된 전문가만 FLOPs를 소비하므로, 전체 파라미터 수는 많지만 추론 비용은 상대적으로 적음.
• 품질 유지: 각 전문가는 특정 영역(예: 코딩, 수학, 일반 지식)에 특화되어 있어, 적절한 라우팅으로 전체 모델과 비슷한 품질 달성 가능.

대표적인 사례가 Google이 2021년에 발표한 Switch Transformer입니다. 당시 언어 모델의 규모가 수천억 파라미터로 커지면서 학습 비용이 천문학적으로 치솟는 것이 업계 공통의 고민이었습니다. Switch Transformer는 이 문제를 정면으로 해결하기 위해 등장했습니다. 기존 MoE가 입력마다 2개 이상의 전문가를 활성화하던 것과 달리, 단 하나의 전문가만 활성화하는 극단적인 방식을 택했습니다. 그 결과 같은 연산량(FLOPs) 대비 학습 속도가 기존 대비 최대 7배까지 빨라졌고, 1.6조(trillion) 파라미터 규모의 모델을 실용적으로 학습할 수 있음을 증명했습니다. 이 연구가 MoE를 "이론적으로 흥미로운 아이디어"에서 "실제로 쓸 수 있는 아키텍처"로 전환시킨 결정적 계기가 되었습니다.

라우터는 어떻게 동작하는가?

라우터의 역할을 이해하기 위해, 대형 병원의 접수 창구를 떠올려봅시다. 환자(입력 데이터)가 병원에 오면, 접수 담당자(라우터)가 증상을 보고 어떤 전문의(Expert)에게 보낼지 결정합니다. 골절이면 정형외과, 두통이면 신경과로 보내는 식이죠. MoE의 라우터도 정확히 이런 역할을 합니다.

일반적인 Transformer 모델에서는 모든 입력이 하나의 처리 경로를 거칩니다. 하나의 "만능 의사"가 모든 환자를 진료하는 셈이죠. 반면 MoE에서는 여러 명의 전문의가 대기하고 있고, 라우터가 각 입력을 적합한 전문가에게 배정합니다.

구체적으로 라우터는 이렇게 동작합니다:

• 먼저 입력 데이터를 받아서, 각 전문가에 대한 "적합도 점수"를 매깁니다. "이 입력은 1번 전문가에게 80점, 3번 전문가에게 65점, 나머지는 낮음" 같은 식입니다.
• 이 점수를 확률로 변환한 뒤, 가장 점수가 높은 상위 K명의 전문가만 선택합니다. 예를 들어 Mixtral 8x7B 모델은 8명의 전문가 중 매번 2명만 골라서 일을 시킵니다.
• 선택된 전문가들이 각자 답을 내놓으면, 적합도 점수에 비례해서 답을 합칩니다. 80점짜리 전문가의 의견에 더 큰 비중을 두는 것이죠.

여기서 중요한 문제가 하나 있습니다. 학습 과정에서 라우터가 "이 전문가가 잘하네?" 하고 특정 전문가에게만 일을 몰아주는 현상이 발생할 수 있습니다. 마치 병원에서 실력 좋은 의사 한 명에게만 환자가 몰려 나머지 의사들은 경험을 쌓지 못하는 것과 같습니다. 이를 "전문가 붕괴(expert collapse)"라고 합니다. 이를 막기 위해 "모든 전문가에게 골고루 일을 분배하라"는 규칙을 학습에 추가합니다. 하지만 이 균등 분배 압력이 너무 강하면, 정작 특정 작업에 꼭 필요한 전문가가 제때 활성화되지 않는 부작용이 생길 수 있습니다.

왜 MoE가 필요했나? - Scale의 저주와 효율 문제

초거대 언어 모델(100B+ 파라미터)은 추론 시 모든 파라미터를 사용해야 하기 때문에:

• GPU 메모리 요구량이 막대함
• 배치 처리 및 동시 요청 수 제한
• API 비용 증가 → 서비스 제공자 부담

MoE는 "필요한 부분만 켜서 쓴다"는 아이디어로 이 문제를 해결합니다. 전체 모델 용량은 유지하되, 실제 추론 비용은 훨씬 줄일 수 있죠.

하지만 Trinity 모델의 툴콜링 실패는 여기서 함정을 보여줍니다. 툴 사용은 특정 전문가 영역에 속할 수 있지만, 라우터가 해당 전문가를 선택하지 않으면 실패로 이어집니다. 앞서 설명한 보조 손실에 의한 균등 분배 압력이 오히려 툴콜링 전문가의 집중 활성화를 방해했을 가능성이 있습니다. 즉, 효율 추구가 품질 희생으로 이어진 사례입니다.

프로세스 경영 관점에서 바라보기

이 문제를 경영학 수업에서 배운 프로세스 경영의 관점으로 바라보면 흥미로운 시사점이 있습니다. 프로세스 경영의 핵심 공식은 다음과 같습니다:

프로세스 가치 = 총 고객 가치 - 프로세스 운영 비용

이 공식을 MoE에 적용해보면:

• 총 고객 가치: 모델이 생성하는 답변의 정확도, 유용성, 신뢰도.
• 프로세스 운영 비용: 추론 시 사용하는 연산량(GPU 시간, 전력, 지연 시간).
• 프로세스 가치 최대화: MoE는 적은 비용(적은 전문가 활성화)으로 높은 가치(정확한 답변)를 얻으려 함.

하지만 Trinity 모델은 품질 임계치에 미치지 못한 채로 비용만 절감한 셈입니다. 그래서 툴콜링 같은 특정 작업에서 실패가 잦아집니다.

프로세스 경영 원칙이 MoE에 시사하는 점

1. 변동성 흡수 설계 (Volatility Absorption)

프로세스 경영에서는 예측 불확실성에 대응하기 위해 버퍼(buffer)를 설계합니다. 예를 들어 제조 공정에서 수요 변동에 대비해 안전 재고를 두거나, 병목 구간 앞에 대기열을 배치하는 것입니다. MoE 아키텍처에서도 같은 원리가 적용됩니다. 라우터가 처리하는 입력은 일상 대화부터 코드 생성, 툴 호출까지 매우 다양하고 예측하기 어렵습니다. 이 변동성을 흡수하려면 라우터에 "여유분"이 필요합니다. 예를 들어 Top-K 라우팅에서 K 값을 작업 복잡도에 따라 동적으로 조절하거나, 특정 유형의 입력(예: 함수 호출 패턴)이 감지되면 관련 전문가를 우선 활성화하는 조건부 라우팅을 도입할 수 있습니다. Trinity 모델은 아마도 일반적인 지식 질의에 최적화되어 이런 변동성 흡수 장치 없이 운영되고 있어, 툴 호출 같은 드물지만 중요한 입력 패턴에 취약한 것으로 보입니다.

2. 트레이드오프 인식과 균형

프로세스 개선에서 시간·비용·품질은 트레이드오프 관계입니다. MoE도 품질 vs 계산 비용의 트레이드오프를 안고 있습니다. Trinity 모델은 비용 절감을 지나치게 강조한 나머지 품질(특히 툴 정확도)을 희생시켰습니다. 적절한 균형점을 찾기 위해:

• Task별 최소 활성화 전문가 수 제한
• 품질이 중요한 작업에서는 더 많은 전문가 할당
• 라우터에 "품질 보장 모드" 도입

결론: MoE는 효율의 정치학, 그러나 조율이 필요하다

MoE 아키텍처는 대규모 AI 서비스의 계산 비용 문제를 해결하기 위한 실용적 선택입니다. 이는 프로세스 경영에서 말하는 "프로세스 가치 최대화" 원리와 정확히 일치하죠.

하지만 Trinity 모델의 툴콜링 실패는 경고합니다: 효율만 좇다가 핵심 가치(정확성)를 놓칠 수 있다는 점을. 따라서 설계 시:

• Task 특성별 전문가 할당 전략을 수립하고,
• 품질 임계치를 설정하여 필요 시 자동으로 더 많은 experts를 활성화하며,
• 변동성 흡수를 위해 라우터를 강건하게 학습시켜야 합니다.

AI 아키텍처도 결국 프로세스 경영입니다. 효율과 품질 사이의 균형을 잡고, 전략과 실행을 일관성 있게 맞추는 것이 성공의 핵심입니다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.