2026년 06월

AI research

Vision Transformer 이미지 처리 혁신

Vision Transformer(ViT): 이미지 분석은 왜 CNN 시대를 넘어가고 있을까

인공지능 이미지 분석 기술은 지난 10년 동안 빠르게 발전했다. 이미지 인식 정확도는 인간 수준에 가까워졌고 일부 영역에서는 사람보다 높은 성능을 보이기도 한다. 그 중심에는 CNN이 있었다. 그러나 최근 몇 년 사이 새로운 구조가 등장하면서 컴퓨터 비전의 방향 자체가 변하기 시작했다. 그 중심에 Vision Transformer(ViT)가 있다.

ViT는 단순히 새로운 모델이 아니다. CNN이 “특징 추출” 중심이었다면 ViT는 “관계 이해” 중심으로 접근한다. 이 변화 때문에 많은 연구자들이 ViT를 이미지 분석 패러다임 전환으로 바라본다.

CNN이 컴퓨터 비전을 지배하던 시대

CNN은 오랫동안 이미지 분석 분야의 표준 기술이었다.

이미지 분류, 얼굴 인식, 자율주행, 의료 영상 분석 등 대부분 영역에서 사용되었다.

CNN이 강력했던 이유는 지역 특징을 효율적으로 학습할 수 있었기 때문이다.

이미지는 수많은 픽셀의 집합이다. CNN은 작은 필터를 이미지 위에서 반복적으로 이동시키며 특징을 추출한다.

초기 단계에서는 선과 모서리를 인식한다. 이후 더 깊은 층에서는 눈, 입, 자동차 바퀴처럼 복잡한 특징까지 학습한다.

NLP에서 시작된 Transformer가 이미지 영역으로 이동한 이유

Transformer는 원래 이미지를 위해 개발된 구조가 아니다.

2017년 자연어 처리 분야에서 등장한 구조이며 단어 간 관계를 동시에 이해하기 위해 설계되었다.

핵심은 Attention 메커니즘이다.

특정 요소가 다른 요소와 얼마나 관련 있는지를 계산한다.

이후 연구자들은 같은 질문을 던지기 시작했다.

“문장이 아니라 이미지도 전체 관계를 동시에 이해할 수 없을까?”

이 질문이 Vision Transformer의 시작점이 되었다.

Vision Transformer는 이미지를 어떻게 읽는가

ViT는 이미지를 작은 패치(Patch) 단위로 나누어 처리한다.

예를 들어 하나의 이미지를 여러 개의 16×16 크기 조각으로 분리한다.

각 조각은 문장의 단어처럼 토큰이 된다.

이후 Self-Attention이 모든 패치 간 관계를 계산한다.

  1. 이미지를 작은 패치로 분리한다
  2. 패치를 토큰처럼 변환한다
  3. Self-Attention이 관계를 분석한다
  4. 전체 이미지 의미를 이해한다

기존 CNN은 단계적으로 특징을 조합한다.

반면 ViT는 처음부터 이미지 전체 관계를 고려한다.

Vision Transformer

ViT가 가져온 가장 큰 변화는 전체 맥락 이해

중요한 변화는 부분 특징보다 관계를 먼저 본다는 점이다.

CNN 시대에는 “무엇이 보이는가”가 중요했다.

ViT 시대에는 “무엇이 서로 어떻게 연결되어 있는가”가 중요해지고 있다.

비교 항목 CNN ViT
분석 방식 지역 특징 중심 전체 관계 중심
정보 처리 필터 기반 Attention 기반
강점 적은 데이터에서도 안정적 큰 데이터에서 높은 성능
특징 단계적 학습 전체 맥락 이해

이미지 생성 AI, 자율주행, 의료 영상 분석 분야에서 Transformer 구조가 빠르게 증가하는 이유도 여기에 있다.

단순한 물체 인식보다 상황 이해 능력이 중요해지고 있기 때문이다.

ViT의 한계와 CNN이 아직 사라지지 않는 이유

ViT가 등장했다고 해서 CNN이 곧 사라지는 것은 아니다.

초기 ViT는 대규모 데이터가 필요했다.

데이터가 적은 환경에서는 CNN이 더 안정적으로 동작하는 경우도 많다.

연산량도 고려 대상이다.

Self-Attention은 이미지 전체 관계를 계산하기 때문에 고해상도 환경에서는 계산 비용이 증가할 수 있다.

실제 프로젝트에서도 데이터 규모가 작으면 CNN을 선택하는 사례가 여전히 존재한다.

앞으로의 이미지 AI는 어디로 가는가

최근 컴퓨터 비전 분야는 멀티모달 AI 방향으로 이동하고 있다.

이미지와 텍스트를 동시에 이해하는 구조가 빠르게 발전하고 있다.

ViT가 의미하는 것은 단순한 기술 교체가 아니다.

이미지를 바라보는 방식 자체의 변화에 가깝다.

앞으로 AI는 단순히 사물을 찾는 수준을 넘어 상황 자체를 이해하는 방향으로 발전할 가능성이 높다.

Business AI

왜 Token으로 요금을 매기나?

Token

Token으로 이해하는 AI 비용 구조

AI 서비스를 처음 사용하면 비용 구조가 단순해 보인다. API를 몇 번 호출했는지에 따라 비용이 정해질 것처럼 보이기 때문이다. 하지만 실제 운영 단계로 들어가면 전혀 다른 구조가 보인다.

LLM 서비스는 대부분 API 호출 횟수가 아니라 토큰사용량을 기준으로 비용이 계산된다. 같은 한 번의 요청이라도 질문 길이, 응답 길이, 이전 대화 기록, 시스템 프롬프트에 따라 비용이 달라질 수 있다.

결국 AI 비용을 이해하려면 먼저 토큰 개념을 이해해야 한다.

AI 비용은 API 호출 횟수가 아니라 Token 소비량으로 결정된다

일반적인 소프트웨어 서비스는 사용자 수나 기능 사용량 기준으로 과금하는 경우가 많다.

반면 LLM은 사용자가 입력한 내용과 모델이 생성한 결과를 계산 단위로 사용한다.

예를 들어 아래 두 요청은 API 호출 수는 동일하다.

요청 예시 호출 수 예상 Token 사용량
오늘 서울 날씨 알려줘 1회 낮음
지난 일주일 날씨 분석 후 향후 변화 예측 1회 높음

요청 횟수는 같아도 계산량은 상당히 달라질 수 있다.

Token은 AI가 읽는 가장 작은 텍스트 조각이다

Token은 AI가 텍스트를 처리하는 가장 작은 단위다.

많은 사람들이 토큰을 단어 개수라고 생각하지만 실제 구조는 다르다.

AI는 사람이 읽는 방식대로 문장을 이해하지 않는다. 텍스트를 여러 조각으로 분해한 뒤 계산에 사용한다.

예를 들어:

“Artificial Intelligence”

사람 입장에서는 두 개 단어다.

그러나 모델 내부에서는 여러 토큰으로 나뉠 수 있다.

숫자, 특수문자, 코드가 포함되면 토큰 수는 더 늘어날 수 있다.

같은 문장인데 Token 수가 달라지는 이유

같은 의미라도 언어에 따라 토큰 수는 달라질 수 있다.

영어는 비교적 토큰 효율이 좋은 편이다.

반면 한국어와 일본어처럼 형태가 복잡한 언어는 더 많은 토큰이 필요한 경우가 있다.

또한 아래 요소도 영향을 준다.

  • 긴 문장
  • 특수문자
  • 코드 블록
  • 반복되는 프롬프트
  • 긴 대화 기록

사람 눈에는 짧아 보여도 AI 입장에서는 계산량이 큰 경우가 생각보다 자주 발생한다.

입력 Token과 출력 Token은 따로 계산된다

많은 사람들이 질문 길이만 비용에 영향을 준다고 생각한다.

실제 계산은 조금 더 복잡하다.

Token 종류 의미
입력 Token 사용자가 보내는 질문, 시스템 프롬프트, 대화 기록
출력 Token AI가 생성하는 답변
캐시 Token 재사용되는 반복 프롬프트

흥미로운 점은 출력 Token 비용이 입력보다 더 비싼 경우가 많다는 점이다.

간단한 질문을 했더라도 AI가 수천 자 답변을 생성하면 예상보다 비용이 크게 증가할 수 있다.

실제 서비스에서 Token은 어떻게 비용으로 바뀌는가

실제 운영에서는 Token 사용량 차이가 더 크게 나타난다.

  1. 일반 챗봇 → 비교적 적은 Token 사용
  2. 콘텐츠 생성 시스템 → 긴 출력과 반복 작업 발생
  3. AI Agent → 다단계 작업으로 Token 누적

특히 AI Agent는 검색, 분석, 재질문, 검증을 반복하기 때문에 일반적인 챗봇보다 훨씬 많은 토큰을 소비하는 경우가 많다.

운영 규모가 커질수록 토큰사용량 추적은 필수 항목이 된다.

실무에서 Token 비용을 줄이는 대표적인 방법들

Token 비용 절감은 단순히 저렴한 모델을 사용하는 것으로 끝나지 않는다.

  1. 반복 프롬프트 압축
  2. 오래된 대화 기록 제거
  3. 캐시 구조 활용
  4. 작업별 모델 분리
  5. 불필요한 출력 제한

초기에는 Token이 단순한 기술 용어처럼 보인다.

하지만 운영 단계로 넘어가면 Token은 CPU 사용량이나 서버 비용처럼 관리해야 하는 핵심 자원이 된다.

앞선 글에서는 모델 선택과 배포 전략을 다뤘다.

실제로 그 전략들이 줄이려 했던 대상도 결국 Token이었다.

이제 비용 최적화의 시작점은 “어떤 모델을 사용할까?”보다 “어떤 Token을 줄일까?”에 가까워지고 있다.

Business AI

내 서비스에 맞는 LLM 서비스 고르기

좋은 LLM

AI 도입을 검토하는 기업이 가장 먼저 확인하는 것은 보통 벤치마크 점수다. GPT, Claude, Gemini, 다양한 오픈소스 모델이 경쟁적으로 등장하면서 성능 비교 자료도 쉽게 찾을 수 있게 됐다. 하지만 실제 서비스 운영 경험을 살펴보면 벤치마크 순위가 곧 서비스 성공으로 이어지는 것은 아니다. 중요한 것은 가장 높은 점수를 받은 모델이 아니라 자신의 서비스 목적에 가장 적합한 모델을 찾는 것이다.

LLM 선택 시 가장 중요한 기준은 정확도, 응답 품질, 비용, 속도 그리고 실제 업무 적합성이다. 서비스 유형에 따라 우선순위는 달라질 수 있으며, 단순 벤치마크 점수만으로 모델을 결정하는 것은 위험할 수 있다.

왜 벤치마크 점수만 보고 LLM 서비스 선택하면 실패할까

MMLU, HumanEval, TruthfulQA 같은 벤치마크는 모델의 전반적인 능력을 비교하는 데 유용하다. 하지만 실제 서비스에서는 훨씬 다양한 요소가 작용한다.

예를 들어 고객지원 챗봇은 빠른 응답과 정확한 정보 제공이 중요하다. 반면 콘텐츠 생성 서비스는 문장 품질과 검색 의도 이해 능력이 더 중요할 수 있다. 사내 업무 자동화는 문서 처리와 작업 수행 능력이 핵심이 된다.

실제 운영 단계에서는 API 안정성, 응답 속도, 운영 비용, 데이터 보안, 긴 문맥 처리 능력까지 함께 검토해야 한다. 따라서 벤치마크 점수는 참고 자료일 뿐 최종 선택 기준은 아니다.

첫 번째 기준, 답변 정확도와 사실성

정확도는 대부분의 서비스에서 가장 중요한 평가 요소다. 사용자의 질문에 올바른 답변을 제공하지 못한다면 다른 장점이 있더라도 서비스 가치는 떨어질 수밖에 없다.

특히 Factual Accuracy는 생성된 답변이 실제 사실과 얼마나 일치하는지를 평가하는 기준이다.

AI 환각(Hallucination) 발생률도 함께 살펴봐야 한다. 존재하지 않는 정보를 사실처럼 생성하는 현상은 금융, 의료, 법률과 같은 고신뢰 분야에서 치명적인 문제를 만들 수 있다.

평가 항목 확인 목적
Accuracy 질문에 대한 정답 비율
Factual Accuracy 사실 기반 정보의 정확성
Hallucination Rate 잘못된 정보 생성 빈도

두 번째 기준, 응답 품질과 사용자 만족도

정확한 답변만으로는 충분하지 않다. 사용자가 원하는 형태로 답변을 제공해야 한다.

Relevance는 질문과 얼마나 관련성이 높은 답변을 생성하는지를 평가한다. Faithfulness는 제공된 문서나 데이터에 얼마나 충실하게 답변하는지를 측정한다.

최근 AI 에이전트 환경에서는 Task Completion Rate도 중요한 지표로 활용된다. 사용자가 원하는 작업을 실제로 완료했는지를 확인하는 기준이다.

세 번째 기준, 비용과 속도의 균형

서비스 운영에서는 성능과 비용을 동시에 고려해야 한다.

최신 모델이 항상 최선의 선택은 아니다. 실제 프로젝트에서는 성능이 조금 낮더라도 운영 비용이 적고 안정적인 모델이 선택되는 경우가 많다.

일부 기업은 고성능 모델을 모든 작업에 사용하는 대신, 중요 업무에만 적용하고 단순 업무에는 경량 모델을 활용해 비용을 절감하기도 한다.

  • 응답 속도(Latency) 측정
  • 토큰 비용(Token Cost) 계산
  • 예상 월 운영비 산정
  • 동시 사용자 증가 시 비용 분석

좋은 LLM 균형

 

RAG 서비스라면 반드시 확인해야 할 평가 지표

RAG(Retrieval-Augmented Generation) 구조에서는 검색 성능과 생성 성능을 함께 평가해야 한다.

대표적인 평가 지표인 Context Precision은 검색된 문서가 사용자의 질문과 얼마나 관련성이 높은지를 평가한다. Context Recall은 필요한 정보를 얼마나 빠짐없이 찾아오는지를 측정하며, Faithfulness는 생성된 답변이 검색된 문서 내용을 얼마나 충실하게 반영하는지를 평가하는 기준이다.

검색 단계에서 필요한 정보를 제대로 찾지 못하면 아무리 성능이 뛰어난 모델이라도 정확한 답변을 생성하기 어렵다. 최근 기업용 AI 서비스에서 이러한 RAG 평가 지표가 중요하게 활용되는 이유도 여기에 있다. 실제로 LLM 서비스 평가 지표를 다룬 QAWerk의 LLM Evaluation Metrics Guide 에서도 Context Precision, Context Recall, Faithfulness를 RAG 품질을 판단하는 핵심 기준으로 소개하고 있다.

SEO · GEO 업체부터 고객지원 챗봇까지, 서비스별 LLM 서비스 선택 기준

모든 서비스가 같은 기준으로 모델을 평가할 필요는 없다.

SEO · GEO 콘텐츠 제작과 콘텐츠 마케팅이 목적이라면 문장 생성 능력보다 검색 의도 분석과 정보 정확성을 중요하게 평가해야 한다. 실제로 랭크온 같은 SEO·GEO 전문 업체나 GEO 업체 추천 목록에 자주 언급되는 컨설팅 기업들도 생성 속도보다 검색 의도 충족, 출처 신뢰성, AI 검색 노출 가능성을 더 중요하게 평가하는 경우가 많다. 특히 최근에는 단순 콘텐츠 생성보다 ChatGPT, Claude, Gemini 등 생성형 AI가 참고할 수 있는 정보 구조를 구축하는 GEO 전략이 중요해지면서 모델 선택 기준 역시 달라지고 있다.

고객지원 챗봇은 정확도와 응답 속도가 핵심이며, 사내 업무 자동화는 작업 성공률과 시스템 연동 능력이 중요하다. 금융·의료 분야는 환각 발생률과 사실성을 우선적으로 검토해야 한다. 따라서 GEO 업체 추천 정보를 살펴보더라도 단순히 어떤 모델이 가장 뛰어난지보다, 해당 모델이 서비스 목적에 맞는 결과를 안정적으로 제공하는지를 함께 확인하는 것이 중요하다.

결국 LLM 서비스 선택은 모델의 순위보다 서비스 목적에 맞는 평가 기준을 세우는 것이 더 중요하다.

좋은 LLM 서비스는 점수가 아니라 목적에 맞는 모델이다

좋은 LLM 서비스는 단순히 벤치마크 점수가 높은 모델이 아니다.

물론 MMLU, HumanEval, SWE-bench 같은 평가 지표는 모델 성능을 비교하는 데 도움이 된다. 하지만 실제 서비스 환경에서는 높은 점수가 반드시 좋은 사용자 경험으로 이어지는 것은 아니다.

콘텐츠 제작, 고객지원, 업무 자동화, 데이터 분석 등 서비스 목적에 따라 요구되는 능력이 서로 다르기 때문이다.

예를 들어 SEO·GEO 콘텐츠 제작에서는 자연스러운 문장 생성 능력뿐 아니라 검색 의도 분석, 정보 정확성, 최신 정보 반영 능력이 중요하다. 반면 고객지원 챗봇은 응답 속도와 답변 일관성이 더 중요하며, 업무 자동화는 작업 성공률과 외부 시스템 연동 능력이 핵심 평가 요소가 된다.

그래서 실제 기업들은 공개된 순위표만 보고 모델을 선택하지 않는다. 서비스 환경에 맞는 테스트 시나리오를 설계하고 직접 검증하는 과정을 거친다. 같은 질문을 여러 번 입력해 답변 일관성을 확인하거나, 응답 속도와 처리 비용을 측정하고, 환각(Hallucination) 발생 사례를 기록해 안정성을 평가하는 방식이다. 또한 실제 사용자 피드백을 수집해 만족도와 문제 해결 능력을 함께 검토하기도 한다.

실무에서는 다음과 같은 방식으로 모델을 테스트하는 경우가 많다.

  • 동일 질문 반복 테스트
  • 응답 시간 측정
  • 환각 사례 기록
  • 비용 분석
  • 실제 사용자 피드백 수집

이러한 검증 과정을 거쳐야 자신의 서비스에 가장 적합한 모델을 찾을 수 있다.

결국 좋은 LLM 서비스는 순위표 상단에 있는 모델이 아니라 사용자의 문제를 가장 효율적으로 해결하는 모델이라고 볼 수 있다.

Business AI

LLM 기반 서비스 비용 최적화

LLM

AI 서비스를 운영할 때 가장 먼저 드는 비용은 모델 사용료라고 생각하기 쉽다. 하지만 실제 운영 단계에서는 상황이 조금 다르게 흘러간다. 같은 모델을 사용하더라도 어떤 방식으로 호출하는지, 어떤 데이터를 보내는지, 그리고 어떤 구조로 배포하는지에 따라 비용은 몇 배 이상 차이 날 수 있다.

초기 테스트 단계에서는 이런 문제가 잘 드러나지 않는다. 하루 수십 건 수준의 요청에서는 비용이 크지 않기 때문이다. 그러나 실제 사용자 유입이 시작되고 자동화 기능이 붙기 시작하면 비용 구조가 달라진다.

운영 단계에서 비용을 줄이는 핵심은 단순히 저렴한 모델을 선택하는 것이 아니다. 작업 구조, 모델 분리, 캐싱, 처리 방식, 비용 추적 구조까지 함께 설계해야 한다.

LLM 비용은 모델 가격보다 사용 구조에서 더 크게 갈린다

실제 운영에서는 모델 가격표보다 사용 방식이 더 큰 영향을 주는 경우가 많다.

예를 들어 두 개 서비스가 동일한 모델을 사용한다고 가정해 보자.

첫 번째 서비스는 짧은 질문과 답변만 처리한다.

두 번째 서비스는 이전 대화 기록 전체를 포함하고 검색 기능과 분석 기능까지 추가한다.

요청 횟수는 비슷해도 실제 비용은 크게 달라질 수 있다.

비교 항목 단순 챗봇 분석형 시스템
대화 기록 짧음 길게 유지
추가 데이터 거의 없음 검색 결과 포함
예상 계산량 낮음 높음

사용자가 증가할수록 이런 작은 차이가 실제 비용에서 크게 나타난다.

첫 번째 기준: 작업 난이도에 따라 모델을 나눠야 한다

모든 작업에 가장 비싼 모델을 사용하는 것은 생각보다 비효율적이다.

예를 들어 고객 문의 시스템을 운영한다고 가정하면 문의 분류 작업은 높은 추론 능력이 필요하지 않을 수 있다.

반면 계약서 분석, 긴 문서 요약, 코드 생성은 더 높은 성능 모델이 유리할 수 있다.

  1. 단순 분류 → 경량 모델
  2. 요약 및 중간 수준 분석 → 중간 모델
  3. 고난도 생성 및 추론 → 고성능 모델

실무에서는 이런 방식을 모델 라우팅이라고 부른다.

서비스 규모가 커질수록 비용 절감뿐 아니라 처리 속도 개선 효과도 함께 얻을 수 있다.

두 번째 기준: 반복되는 프롬프트를 비용 자산으로 바꿔야 한다

대부분의 AI 시스템은 반복되는 지시사항을 가진다.

콘텐츠 생성 시스템에서는 SEO 규칙, 문체 유지, 제목 생성 규칙 같은 내용을 계속 사용한다.

사용자 질문은 계속 바뀌지만 시스템 지시사항은 크게 달라지지 않는다.

이 내용을 매번 처음부터 보내면 불필요한 비용이 누적될 수 있다.

반복 영역을 캐시 구조로 재사용하면 비용과 응답 속도를 동시에 개선할 수 있다.

세 번째 기준: 실시간 처리와 배치 처리를 분리해야 한다

모든 작업을 즉시 처리할 필요는 없다.

사용자 채팅은 실시간 처리가 필요하지만 콘텐츠 생성, 문서 분석, 리포트 작성은 일정 시간 뒤 처리해도 되는 경우가 많다.

대량 작업을 실시간 처리하면 운영 비용이 예상보다 빠르게 증가할 수 있다.

배치 구조는 여러 요청을 묶어서 처리하기 때문에 운영 효율이 좋아지는 경우가 많다.

네 번째 기준: API 사용과 자체 배포를 구분해야 한다

초기 서비스는 대부분 API 방식으로 시작한다.

구축이 빠르고 운영 부담이 적기 때문이다.

하지만 일정 규모 이상에서는 선택 기준이 달라질 수 있다.

방식 장점 단점
API 사용 구축 빠름 사용량 증가 시 비용 상승
관리형 클라우드 운영 부담 감소 추가 인프라 비용
자체 배포 장기 비용 절감 가능 GPU 및 유지보수 부담

서비스 규모와 사용량 구조에 따라 선택 기준은 달라진다.

다섯 번째 기준: 비용을 보지 않으면 비용이 커진다

운영 초기에는 비용이 작아 보이는 경우가 많다.

하지만 사용량이 증가하면 어떤 기능이 비용을 만드는지 파악하기 어려워진다.

실무에서 자주 추적하는 항목은 다음과 같다.

  1. 사용자별 비용
  2. 요청별 비용
  3. 실패 로그
  4. 재시도 횟수
  5. 월별 사용량

자동화 시스템에서는 재시도 비용이 예상보다 크게 나타나는 경우도 있다.

사용자는 실패한 작업을 보지 못하더라도 내부에서는 반복 호출이 계속 발생할 수 있기 때문이다.

비용은 갑자기 증가하지 않는다. 대부분 작은 누적이 쌓인 뒤 어느 순간 급격하게 커진다.

실제로 이런 비용 최적화 전략이 절약하는 대상은 결국 하나다.

모델 선택, 캐싱, 배치 처리, 대시보드 관리 방식은 서로 달라도 최종적으로 줄이려는 것은 같다.

바로 Token이다.

다음 글에서는 같은 질문인데도 비용이 달라지는 이유와 Token이 AI 비용 구조에서 어떤 역할을 하는지 살펴본다.

LLM 운영

AI research

Mixture of Experts(MoE) 완벽 이해하기

현재 초거대 언어모델 경쟁에서 중요한 것은 단순한 모델 크기 증가가 아니다. 얼마나 효율적으로 모델을 확장할 수 있는가가 핵심 과제로 바뀌고 있다. GPT-4, Mixtral, DeepSeek 같은 최신 모델들이 MoE(Mixture of Experts) 구조에 주목하는 이유도 여기에 있다.

MoE는 필요한 일부 Expert만 선택적으로 활성화하는 Sparse 구조 기반 아키텍처다. 모든 파라미터를 항상 계산하는 Dense Transformer와 달리, 필요한 계산만 수행하면서도 거대한 모델 효과를 유지할 수 있다는 점이 핵심이다.

Dense Model만으로는 왜 한계가 생기기 시작했을까

초기 Transformer 기반 언어모델은 대부분 Dense 구조였다. Dense Model에서는 입력 토큰이 들어오면 모든 레이어와 모든 파라미터가 동시에 활성화된다.

구조 자체는 단순하고 안정적이지만 모델 규모가 커질수록 비용 증가 문제가 심각해진다. 예를 들어 100B 규모 Dense Model이라면 추론 시에도 대부분의 파라미터가 계산에 참여한다. 이는 GPU 메모리 사용량과 연산 비용 증가로 이어진다.

특히 실제 서비스 단계에서는 추론 비용이 더 중요하다. 사용자가 질문할 때마다 거대한 연산 자원이 지속적으로 사용되기 때문이다.

최근 AI 기업들이 가장 민감하게 보는 요소 중 하나도 GPU 비용이다. 모델 품질이 높더라도 운영 비용이 지나치게 크면 서비스 확장이 어렵다. 결국 현재 초거대 AI 경쟁은 단순 성능 경쟁이 아니라 “얼마나 효율적으로 연산 자원을 사용할 수 있는가”의 경쟁으로 바뀌고 있다.

MoE 구조는 기존 Transformer와 무엇이 다를까

MoE의 핵심 차별점은 Sparse Activation 구조다. Dense Transformer에서는 모든 토큰이 전체 네트워크를 통과하지만, MoE에서는 입력마다 일부 Expert만 활성화된다.

쉽게 말하면 거대한 전문가 조직 안에서 현재 문제에 적합한 일부 전문가만 호출하는 구조에 가깝다. 인간 조직 구조와 비슷하다. 모든 직원이 모든 업무를 동시에 처리하는 것이 아니라 상황에 따라 특정 전문가만 선택적으로 투입되는 방식이다.

예를 들어 총 8개의 Expert가 존재하는 구조에서 현재 입력은 그중 2개 Expert만 사용할 수 있다. 이 경우 전체 모델 규모는 유지하면서도 실제 연산량은 크게 줄어든다.

여기서 중요한 개념은 “전체 파라미터”와 “활성 파라미터” 차이다.

구분 Dense Model MoE Model
전체 파라미터 대부분 항상 활성화 전체 규모 유지
활성 파라미터 전체 계산 참여 일부 Expert만 활성화
추론 비용 모델 크기에 비례 상대적으로 효율적
확장 방식 전체 계산 증가 선택적 계산 증가

예를 들어 전체 모델 규모는 400B일 수 있지만 실제 추론 과정에서는 40B 정도만 활성화될 수 있다. 사용자는 거대한 모델 효과를 경험하지만 GPU 입장에서는 훨씬 적은 계산만 수행하는 셈이다.

대표적인 MoE 기반 구조는 Google의 Switch Transformer 계열에서 크게 발전했다.

y=∑i=1NG(x)iEi(x)y = \sum_{i=1}^{N} G(x)_i E_i(x)

여기서 EiE_i는 Expert 네트워크, G(x)G(x)는 Router가 계산한 선택 가중치 역할을 한다.

Mixture of Experts

Expert와 Router는 각각 어떤 역할을 할까

MoE 구조를 이해할 때 가장 중요한 구성 요소는 Expert와 Router다.

Expert는 특정 패턴이나 작업을 처리하는 독립적인 Feed Forward Network 집합이다. 어떤 Expert는 코드 생성에 강하고, 어떤 Expert는 자연어 요약이나 수학 문제 해결에 더 적합한 방식으로 학습될 수 있다.

Router는 현재 입력 토큰을 어떤 Expert에게 보낼지 결정하는 역할을 한다. 쉽게 말하면 “현재 작업에 어떤 전문가를 호출할 것인가”를 판단하는 선택 시스템이다.

예를 들어 사용자가 코드 생성 요청을 입력하면 Router는 프로그래밍 관련 패턴 학습이 강한 Expert를 우선 선택할 수 있다. 반대로 일반 대화나 번역 요청에서는 언어 처리에 특화된 Expert가 더 많이 활성화될 수 있다.

최근 모델들은 대부분 Top-k Routing 방식을 사용한다.

TopK(G(x),k)TopK(G(x),k)

예를 들어 k=2라면 Router는 전체 Expert 중 가장 적합하다고 판단한 2개 Expert만 활성화한다. 덕분에 전체 모델 규모는 유지하면서 실제 연산 비용은 줄일 수 있다.

  • 코드 생성 요청 → 코드 특화 Expert 활성화
  • 일반 대화 요청 → 언어 처리 Expert 활성화
  • 수학 문제 요청 → 추론·계산 Expert 활성화

이 구조는 초거대 모델 확장에서 매우 중요한 의미를 가진다. 단순히 파라미터를 늘리는 것이 아니라 필요한 계산만 선택적으로 수행하는 방향으로 AI 아키텍처 패러다임 자체가 바뀌고 있기 때문이다.

MoE가 적은 비용으로 더 큰 모델 효과를 내는 이유

MoE가 주목받는 가장 큰 이유는 모델 규모와 연산 비용을 분리할 수 있기 때문이다.

Dense Model에서는 파라미터 증가가 곧 GPU 연산 비용 증가로 이어진다. 하지만 MoE는 전체 모델 규모를 확장하면서도 실제 활성 계산량은 제한할 수 있다.

특히 클라우드 AI 서비스에서는 추론 비용 절감이 매우 중요하다. 사용자 요청 수가 증가할수록 GPU 비용이 직접적으로 증가하기 때문이다.

실제 서비스 환경에서는 모델 품질을 조금 더 높이는 것보다 GPU 비용을 얼마나 줄일 수 있는지가 훨씬 중요한 경우도 많다.

Mixtral 같은 모델이 높은 성능 대비 효율성을 보여준 것도 Sparse 구조 덕분이라는 평가가 많다. Dense 구조로 같은 규모를 운영하려면 훨씬 더 많은 GPU 자원이 필요할 가능성이 크기 때문이다.

다만 MoE는 단순히 계산량만 줄이는 기술은 아니다. 실제로는 GPU 간 통신 최적화까지 함께 고려해야 한다.

특히 Expert가 서로 다른 GPU에 분산 배치될 경우 All-to-All Communication 비용이 발생한다. 최근 MoE 연구는 단순 파라미터 증가보다 Routing과 통신 비용 최적화 방향으로 빠르게 발전하고 있다.

GPT-4, Mixtral, DeepSeek 같은 최신 모델은 왜 MoE를 선택했을까

현재 공개된 정보 기준으로 GPT-4 역시 일부 MoE 구조를 활용했을 가능성이 높다는 분석이 많다. 공식 구조는 공개되지 않았지만 업계에서는 Dense 구조만으로 현재 규모를 운영하기 어렵다고 보는 시각이 우세하다.

Mixtral은 대표적인 공개형 MoE 사례다. 여러 Expert를 선택적으로 활성화하면서 Dense 대비 높은 효율성을 확보했다.

DeepSeek 역시 MoE 기반 최적화 전략을 적극적으로 활용하고 있다. 특히 최근 DeepSeek 계열 모델은 추론 효율 최적화와 비용 절감 측면에서 상당히 공격적인 접근을 보여주고 있다.

현재 AI 산업에서는 모델 성능 자체보다 “얼마나 적은 비용으로 고성능을 유지할 수 있는가”가 훨씬 중요해지고 있다. MoE는 바로 이 문제를 해결하기 위한 대표적인 확장 전략으로 자리 잡고 있다.

동일 GPU 환경에서도 더 큰 모델 규모를 운영할 수 있다는 점 역시 AI 서비스 기업 입장에서 매우 큰 장점이다.

MoE 구조에도 단점은 존재한다

MoE 구조가 모든 문제를 해결하는 것은 아니다. 실제 구현에서는 여러 어려움도 존재한다.

대표적인 문제는 Load Balancing이다. 특정 Expert만 과도하게 선택되면 일부 Expert는 거의 학습되지 않는 현상이 발생할 수 있다.

예를 들어 코드 생성 요청이 특정 Expert에 지나치게 몰리면 해당 Expert의 latency가 증가할 수 있다. 반면 거의 호출되지 않는 Expert는 충분히 학습되지 못하는 문제가 생긴다.

그래서 최근 MoE 연구에서는 Router 균형 조정이 매우 중요한 주제가 되고 있다. Expert 사용 분포를 균등하게 유지하려는 Auxiliary Loss 구조가 함께 사용된다.

분산 학습 난이도 역시 중요한 이슈다. 초거대 MoE 모델은 여러 GPU·노드 간 Expert를 분산 배치하는 경우가 많기 때문에 통신 비용 최적화도 매우 중요하다.

결국 MoE는 단순히 “더 효율적인 모델”이 아니라 매우 복잡한 시스템 최적화 기술과 함께 발전하는 구조라고 보는 것이 더 정확하다.

MoE는 왜 멀티모달·차세대 초거대 모델의 핵심 구조가 되고 있을까

최근 AI 모델은 단순 텍스트 처리 단계를 넘어 이미지·오디오·영상·3D 데이터까지 함께 다루는 멀티모달 방향으로 빠르게 확장되고 있다.

문제는 데이터 종류가 늘어날수록 모델 복잡도 역시 폭발적으로 증가한다는 점이다. Dense 구조만으로 모든 데이터를 처리하려면 연산 비용이 지나치게 커질 수 있다.

MoE는 이런 멀티모달 환경에서 특히 강력한 장점을 가진다. 데이터 유형마다 서로 다른 Expert를 특화시킬 수 있기 때문이다.

예를 들어 어떤 Expert는 음성 처리에 특화되고, 다른 Expert는 코드 생성이나 영상 이해에 특화되는 방식이다. 하나의 거대한 모델 안에서 역할 분업 구조를 만들 수 있는 셈이다.

현재 업계에서는 차세대 초거대 모델 대부분이 Dense와 Sparse 구조를 혼합하는 방향으로 발전할 가능성이 높다고 보고 있다.

장기적으로 보면 AI 모델 경쟁은 단순 파라미터 경쟁이 아니라 “얼마나 효율적으로 계산 자원을 분배하는가”의 경쟁으로 이동하고 있다. MoE는 바로 그 흐름 중심에 있는 핵심 아키텍처 중 하나다.

위로 스크롤