MoE 모델 이해하기: 전체·활성 파라미터와 운영 비용

MoE(전문가 혼합) 모델은 토큰당 연산량을 줄이면서도 직접 호스팅하기에는 여전히 거대한 규모일 수 있습니다. Moonshot AI의 Kimi K3.1 Pro 언어 모델은 공식 출시 게시물에 따르면 전체 파라미터가 2.8T이지만 토큰당 활성 파라미터는 104B입니다. 작은 쪽 수치는 연산량을 이해하는 데 도움이 됩니다. 하지만 가중치를 모두 저장해야 한다면 큰 쪽 수치도 여전히 중요합니다.

파라미터 수와 출처의 주장은 2026년 10월 24일에 확인했습니다. 아래 활성 비율은 직접 계산한 값이며, 실측한 속도 향상률이나 메모리 절감률, 품질 점수가 아닙니다.

MoE란 무엇인가요?

전문가 혼합(mixture of experts), 줄여서 MoE는 모델 내부에 여러 처리 네트워크를 두고 입력마다 그중 일부만 선택하는 구조입니다. 파라미터는 모델이 학습한 수치이며, 저장된 파라미터를 보통 가중치라고 부릅니다. 토큰은 입력이나 출력을 나누는 작은 단위로, 단어의 일부인 경우가 많습니다.

상담실이 여러 개 있는 건물을 떠올리면 이해하기 쉽습니다. 접수 담당자는 방문 목적에 맞는 상담실로 방문자를 안내합니다. 한 방문자를 위해 일하는 방은 일부지만, 건물에는 모든 방이 그대로 있습니다. MoE 계층에서는 라우터가 접수 담당자 역할을 하고, 엑스퍼트가 각 상담실에 해당합니다.

다만 이 비유를 사람의 전문 분야까지 확대해서는 안 됩니다. 엑스퍼트는 학습된 수치 연산 네트워크이지, 직함을 가진 사람들의 명단이 아닙니다. 법률 전문가, 코딩 전문가, 회계 전문가가 각각 대기하다가 선택되는 구조라고 단정할 수는 없습니다.

MoE 아키텍처는 어떻게 작동하나요?

라우터가 모델 내부의 처리 경로를 선택한 뒤, 각 경로의 결과를 결합합니다. 트랜스포머는 토큰 사이의 문맥적 관계를 처리합니다. 일반적인 MoE 트랜스포머에서는 피드포워드 블록을 여러 엑스퍼트 네트워크로 대체합니다. 피드포워드 블록은 토큰의 내부 수치 표현을 변환하고, 이와 별개인 어텐션은 주변 문맥을 활용하도록 해 줍니다.

처리는 다음 순서로 진행됩니다.

1. 토큰의 현재 표현이 MoE 계층에 도달합니다.
2. 게이트라고도 부르는, 학습된 라우터가 각 엑스퍼트에 점수를 매깁니다.
3. 엑스퍼트 중 일부를 선택하며, 보통 점수가 가장 높은 엑스퍼트를 고릅니다. 이를 top-k 라우팅이라고 하며, k는 선택하는 엑스퍼트 수입니다.
4. 선택된 엑스퍼트가 해당 표현을 처리합니다. 각 출력에 가중치를 적용해 결합한 다음, 후속 처리를 이어 갑니다.

이 과정은 모델의 MoE 계층마다 일어나므로, 토큰이나 계층이 달라지면 선택되는 엑스퍼트도 달라질 수 있습니다. PyTorch의 아키텍처 설명은 출력을 가중 결합하는 방식을 다루고, Mistral의 모델 논문은 계층에 따라 선택이 어떻게 달라지는지 보여 줍니다.

희소 MoE는 무엇을 뜻하나요?

희소하다는 것은 특정 토큰을 처리할 때 엑스퍼트 중 일부만 실행된다는 뜻입니다. 최신 모델 카드에서 전체 파라미터와 활성 파라미터를 구분할 때는 이 구조를 가리킵니다. 나머지 엑스퍼트는 다른 토큰을 처리할 때 실행될 수 있으며, 같은 배치에서 처리 중인 토큰도 여기에 포함됩니다.

밀집형 피드포워드 블록은 토큰마다 네트워크 전체를 적용합니다. 반면 희소 엑스퍼트 계층은 저장된 모델 용량을 늘리면서도 모든 토큰이 모든 엑스퍼트를 거치지 않도록 합니다. 여기서 다루는 사례의 어텐션처럼 공유되는 구성 요소는 여전히 연산을 수행합니다.

MoE도 결국 하나의 모델입니다

MoE 라우팅은 여러 API 모델 중 하나를 고르거나 여러 챗봇에 답을 받아 투표하는 방식과 다릅니다. 라우터와 엑스퍼트는 하나의 네트워크를 이루는 구성 요소로 학습됩니다. 애플리케이션은 보통 그 네트워크에 요청을 보냅니다. 메뉴에서 상품을 고르듯 엑스퍼트를 직접 선택하는 것이 아닙니다.

개발자가 이 차이를 이해하면 잘못된 설계 전제를 피할 수 있습니다. MoE 모델을 선택했다고 해서 애플리케이션이 직접 제어할 수 있는 전문 에이전트 팀이 생기는 것은 아닙니다.

MoE 모델은 전체·활성 파라미터를 함께 봐야 합니다

전체 파라미터는 저장해야 하는 모델 크기로, 활성 파라미터는 공개된 토큰당 연산 경로의 규모로 읽어야 합니다. 어느 쪽도 그 자체로 완전한 하드웨어 사양은 아닙니다. B는 billion(십억), T는 trillion(조)을 뜻합니다.

마지막 열은 활성 파라미터를 전체 파라미터로 나눈 뒤 반올림한 값입니다. 각 개발사가 공개한 수치의 관계를 보여 줄 뿐, 모델 간 효율 순위가 아닙니다. 아키텍처와 파라미터 집계 방식은 모델마다 다를 수 있습니다.

Kimi K3.1 Pro: 거대한 모델에서 일부만 활성화됩니다

Kimi K3.1 Pro는 직접 호스팅할 모델의 크기를 활성 파라미터만으로 판단해서는 안 되는 이유를 보여 줍니다. Moonshot이 공개한 전체 파라미터를 같은 단위로 바꾸면 2,800B입니다. 이를 계산하면 **104 ÷ 2,800 × 100 = 3.7%**가 됩니다. 반올림한 값입니다.

공개된 활성 파라미터가 전체의 작은 일부라는 의미입니다. 그렇다고 서빙 환경에서 나머지 가중치를 버려도 된다거나, API의 지연 시간이 밀집 모델의 지연 시간 대비 그 비율만큼으로 줄어든다는 뜻은 아닙니다. 토큰과 계층이 바뀌면 처리 경로도 바뀝니다.

Moonshot의 출시 블로그는 Pro를 후학습한 K3로 설명하며, 규모를 반올림해 “3T급”이라고 표현합니다. 공식 출시 게시물에 명시된 정확한 수치는 2.8T / 104B입니다. 모델의 크기를 해석할 때는 이 구체적인 사양을 기준으로 삼아야 합니다.

API로 서비스를 만드는 개발자에게는 평가해 볼 후보입니다. 직접 호스팅하는 운영자에게는 가중치를 실제로 구할 수 있는지도 별도의 조건입니다. 확인일 기준으로 Moonshot은 2026년 11월 4일까지 전체 가중치를 공개하겠다고 예고했습니다. 공개 약속만으로는 아직 배포에 필요한 파일이 갖춰진 것이 아닙니다. 이 출시에 따른 구체적인 판단은 Kimi K3.1 Pro 해설에서 다룹니다.

Qwen3-235B-A22B: 활성 파라미터로 전체 크기를 대신할 수 없습니다

Qwen3-235B-A22B는 이름에서부터 두 수치의 차이를 드러냅니다. Qwen의 원본 모델 카드에는 전체 235B, 활성 22B이며, 엑스퍼트 128개 중 8개가 활성화된다고 명시되어 있습니다.

파라미터 기준으로 계산하면 **22 ÷ 235 × 100 = 9.4%**입니다. 반올림한 값입니다. 사내 문서 어시스턴트를 만든다면, 이 수치는 모델이 토큰당 연산량을 어떻게 제한하는지 알려 주는 단서가 됩니다. 메모리 계획에는 여전히 선택한 체크포인트 전체와 처리 중인 요청의 상태를 수용할 공간이 필요합니다.

“활성 22B”를 “밀집형 22B 모델과 같은 메모리에 들어간다”로 받아들여서는 안 됩니다. 수치를 기록할 때는 어떤 체크포인트의 값인지도 함께 남겨야 합니다. 가중치 파일, 정밀도, 서빙 구성을 선택할 때 모델 계열 이름만으로는 충분하지 않습니다.

Mixtral 8x7B: 이름 속 숫자를 곱하면 왜 틀리나요?

Mixtral 8x7B에는 공유 구성 요소가 있으므로, 이름 속 숫자를 그대로 곱해서는 안 됩니다. Mistral의 출시 블로그는 전체 46.7B, 토큰당 사용 12.9B라고 명시합니다. 이름 속 숫자를 곱하면 공유 구성 요소까지 각각 별개의 완전한 모델에 속한 것처럼 계산하게 됩니다.

Mistral의 논문은 공유 어텐션과 함께 동작하는 엑스퍼트 피드포워드 네트워크를 설명합니다. 각 계층에서 라우터는 엑스퍼트 8개 중 2개를 선택합니다. 각각 독립적이고 완전한 모델 여덟 개가 있는 것이 아닙니다.

공개된 파라미터 수로 계산하면 **12.9 ÷ 46.7 × 100 = 27.6%**입니다. 반올림한 값입니다. 엑스퍼트 8개 중 2개를 선택하는 것은 **엑스퍼트의 25%**이며, 이 계산은 분모가 다릅니다. 공유 구성 요소는 엑스퍼트 비율과 파라미터 비율이 달라지는 이유 중 하나입니다.

배포 계획을 세울 때는 모델 카드의 전체 파라미터 수와 실제 체크포인트 파일을 기준으로 삼아야 합니다. 제품 이름이나 선택되는 엑스퍼트 수만으로는 전체 가중치가 차지하는 공간을 알 수 없습니다.

연산량이 줄어도 지연 시간이 짧아진다고 보장할 수는 없습니다

희소 라우팅은 비슷한 규모의 밀집 네트워크 전체를 실행할 때보다 엑스퍼트 연산량을 줄입니다. 하지만 더 작은 밀집 모델과 같은 응답 시간을 보장하지는 않습니다. MoE가 큰 용량의 모델을 토큰당 더 낮은 비용으로 서빙할 수 있는 이유도 여기에 있습니다. 다만 메모리 사용과 통신 부담은 여전히 상당할 수 있습니다.

학습된 모델을 실행하는 과정인 추론에서 산술 연산은 일부에 불과합니다. 서버는 가중치를 읽고, 공유 구성 요소를 실행하고, 토큰 표현의 경로를 정하며, 때로는 이를 장치 사이에서 전송합니다. 활성 파라미터가 적다고 해서 이런 작업이 사라지는 것은 아닙니다. Shazeer와 동료들은 초기 희소 MoE 논문에서 엑스퍼트별로 작은 배치를 처리하는 문제와 네트워크 대역폭을 성능 제약으로 지적했습니다.

처리량과 지연 시간은 서로 다른 비즈니스 질문에 답합니다. 처리량은 서비스가 일정 시간 동안 처리하는 작업량이고, 지연 시간은 개별 요청이 기다리는 시간입니다. 야간에 문서를 처리하는 대기열에는 큰 배치를 효율적으로 처리하는 구성이 유리할 수 있습니다. 반면 대화형 고객 지원 어시스턴트는 첫 번째 유용한 답을 빠르게 내놓아야 합니다.

여러 토큰이나 요청을 묶어 처리하는 배칭은 하드웨어 활용률을 높일 수 있습니다. 그러나 토큰마다 선택하는 엑스퍼트가 다를 수 있으므로, 배치 하나가 사용하는 모델 범위는 토큰 하나가 사용하는 범위보다 훨씬 클 수 있습니다. 활성 파라미터 수는 서버가 배치 전체를 처리하면서 접근하는 가중치 수가 아닙니다.

프롬프트 처리와 토큰 생성도 시스템에 서로 다른 부담을 줍니다. **프리필(prefill)**은 입력을 처리하고, **디코드(decode)**는 이후 토큰을 생성합니다. 언어 모델 서빙 소프트웨어인 vLLM은 처리량을 높이는 프리필과 지연 시간을 줄이는 디코드에 맞춰 별도의 엑스퍼트 통신 옵션을 문서화하고 있습니다. LLM 추론 가이드에서는 이 단계들과 구분해서 측정해야 할 항목을 설명합니다.

API를 선택할 때는 실제 요청에서 관찰한 동작을 비교해야 합니다. 전체·활성 파라미터 수만으로는 제공업체가 트래픽을 얼마나 많이 묶어 처리하는지, 대기열이 얼마나 긴지, 하드웨어가 모델에 얼마나 잘 맞는지 알 수 없습니다.

실제 운영에서 마주하는 절충점

MoE는 인프라 부담의 일부를 반복적인 연산에서 더 큰 모델을 저장하고 조율하는 작업으로 옮깁니다. 운영 관점에서 중요한 것은 이 교환이 실제 워크로드에 유리한지입니다.

메모리: 모든 엑스퍼트에 저장 공간이 필요합니다

이번 토큰에서 비활성 상태라고 해서 배포 환경에서 제거해도 된다는 뜻은 아닙니다. 일반적으로 가중치를 메모리에 상주시켜 서빙할 때는 토큰마다 일부만 사용하더라도 전체 가중치가 서빙 시스템에 로드된 상태로 유지됩니다. PyTorch의 설명도 이 메모리 요구 사항을 명확히 짚습니다.

출발점으로 유용한 계산식은 가중치 저장 용량 ≈ 전체 파라미터 수 × 저장된 파라미터당 바이트 수입니다. 다만 이것은 시작점일 뿐입니다. 텐서마다 정밀도가 다를 수 있고, 파일 메타데이터, 패딩, 복제본, 런타임 메모리 할당도 차지하는 공간을 늘립니다.

전체 메모리 예산에는 가중치 외의 항목도 있습니다. KV 캐시는 이전 토큰의 어텐션 키와 값을 저장해 재사용할 수 있도록 합니다. 문서 어시스턴트의 대화가 길어지거나 동시 요청이 늘어나면, 요청 상태를 보관하는 데 필요한 메모리도 추가로 확보해야 합니다. 이 별도의 제약은 KV 캐시 해설에서 다룹니다.

양자화는 가중치를 더 낮은 수치 정밀도로 저장해 가중치가 차지하는 공간을 줄이는 방법입니다. 그렇다고 전체 파라미터가 활성 파라미터로 바뀌거나 출력 품질을 검증할 필요가 없어지는 것은 아닙니다. LLM 양자화 가이드는 형식과 정밀도 선택을 다루며, 작동 원리는 Hugging Face의 양자화 개요에 설명되어 있습니다.

처리량: 모델을 메모리에 올리는 것은 첫 관문일 뿐입니다

모델을 정상적으로 로드했더라도 서비스 목표를 달성하지 못할 수 있습니다. 엑스퍼트 병렬화는 엑스퍼트를 여러 장치에 분산해, 장치 하나의 메모리보다 큰 모델을 배포 환경에 수용할 수 있게 합니다. 동시에 토큰 표현을 선택된 엑스퍼트가 있는 장치로 보내고, 그 결과를 다시 결합해야 합니다.

이 전송 때문에 장치 사이를 잇는 인터커넥트도 서빙 설계의 일부가 됩니다. 연결 성능이 좋지 않은 여러 머신에 용량을 분산한 환경은, 같은 용량이라도 연결 성능이 좋은 시스템과 동등하지 않습니다. 이는 PyTorch의 엑스퍼트 병렬화 구현에서 설명하는 통신 패턴이 직접적으로 시사하는 바입니다.

트래픽이 적은 사내 어시스턴트에서는 확보해 둔 용량이 충분히 활용되지 않는 문제가 중요할 수 있습니다. 바쁜 배치 서비스에서는 엑스퍼트가 계속 연산할 수 있도록 작업을 공급하는 것이 과제일 수 있습니다. 어느 쪽이든 활성 파라미터 수만으로 결과가 정해지지는 않습니다.

라우팅의 특성: 특정 엑스퍼트에 요청이 몰리면 병목이 생깁니다

학습된 라우터가 하드웨어 사용량을 완벽하게 고르게 나눠 주는 것은 아닙니다. NVIDIA의 Mixtral 라우팅 분석에서는 특정 주제에 트래픽이 집중될 경우 엑스퍼트별 부하가 불균형해질 수 있음을 확인했습니다. 일부 워커는 일찍 작업을 끝내지만 다른 워커는 계속 바쁠 수 있습니다.

주로 계약서나 코드를 처리하는 서비스에 여러 주제를 섞은 시연용 워크로드만으로는 부족한 이유입니다. 평균값에만 의존하지 말고, 해당 주제에 요청이 몰리는 상황과 그중 느린 요청까지 평가해야 합니다.

서빙 소프트웨어가 이를 보완할 수 있지만, 보완책에도 자원이 듭니다. vLLM은 여분의 엑스퍼트를 활용한 부하 분산을 문서화하면서, 추가 복제본이 원래 KV 캐시에 쓸 수 있었던 GPU 메모리를 소비한다고 경고합니다. 모델 가중치가 메모리에 겨우 들어맞는다면, 효율적인 서빙 구성에 필요한 여유 공간이 부족할 수 있습니다.

MoE LLM 선택 기준: API와 직접 호스팅

API를 사용하는 개발자는 제공받는 서비스의 결과를 평가해야 합니다. 직접 호스팅하는 운영자는 전체 배포 환경까지 평가해야 합니다. 둘 다 요구 수준을 충족하는 출력이 필요하지만, 엑스퍼트를 어디에 배치할지 직접 관리하는 쪽은 후자입니다.

API를 사용하는 개발자에게 아키텍처는 유용한 배경 정보이지, 모델을 바꿔야 할 이유 자체는 아닙니다. 대표 작업, 지시 이행 능력, 필요한 경우 툴 사용 능력, 예상 동시 요청 수에서 첫 토큰이 나올 때까지의 시간과 완료 시간을 평가해야 합니다. 실패한 시도와 재시도도 기록해야 합니다. 제공업체의 서빙 효율이 청구 금액이나 요구 수준을 충족하는 결과를 얻기까지의 작업량을 결정해 주지는 않습니다.

직접 호스팅하는 운영자는 실제로 다운로드할 정확한 체크포인트, 라이선스, 지원되는 서빙 구현부터 확인해야 합니다. 그다음 가중치 정밀도, 전체 모델의 메모리 요구량, 캐시용 여유 공간, 장치 간 연결, 부하가 걸린 상태의 성능을 평가합니다. 오픈 웨이트 모델 가이드는 파일에 접근할 수 있다는 것과 운영에 따르는 권리·책임을 구분해 설명합니다.

약속한 서비스 수준에 책임을 지는 구매 담당자는 계획한 인프라에서 후보 모델이 요구 수준을 충족하는 작업을 목표 응답 시간 안에 마치는지 확인해야 합니다. “전체는 조 단위, 활성은 십억 단위”라는 말은 아키텍처 설명이지, 서비스 수준을 보장하는 약속이 아닙니다.

1. 1

   모델을 비교하기 전에 워크로드를 정의합니다

   명확한 합격 기준을 세우고 대표 요청을 사용합니다. 대화형 작업과 대기열에서 처리하는 작업을 구분하고, 애플리케이션이 실제로 다루는 긴 입력과 특정 주제에 집중된 요청을 포함합니다.

2. 2

   실제로 운영할 제공 경로를 평가합니다

   API라면 사용할 제공업체와 엔드포인트를 테스트합니다. 직접 호스팅한다면 정확한 체크포인트, 정밀도, 런타임, 하드웨어를 기록합니다. 서빙 경로가 달라지면 운영 결과도 달라집니다.

3. 3

   처리 용량과 품질을 함께 테스트합니다

   동시 작업량을 늘리면서 메모리 사용량, 대기 시간, 출력 품질, 실패를 확인합니다. 단독 요청 하나가 빠르다고 해서 실용적인 처리량이 입증되는 것은 아니며, 처리량이 높다고 해서 대화형 서비스의 지연 시간이 허용 범위에 든다는 뜻도 아닙니다.

4. 4

   실제 워크로드에서 이점이 확인될 때 전환합니다

   요구 수준을 충족한 작업 성과와 운영 요건이 함께 개선될 때 후보 모델을 도입합니다. 그런 개선이 없다면 현재 모델을 유지합니다. 필요한 가중치 파일이나 지원되는 배포 경로가 아직 없다면 직접 호스팅은 기다려야 합니다.

현재 API가 품질과 응답 시간 요구 사항을 충족한다면, 개발자의 선택은 아키텍처 이름만으로 달라지지 않습니다. 반면 활성 파라미터를 기준으로 배포 규모를 산정한 운영자는 지금 계획을 수정해야 합니다.

MoE를 둘러싼 과장은 무엇인가요?

희소 구조만으로 거대 모델의 장점을 모두 누리면서 작은 모델처럼 운영할 수 있다는 주장은 과장입니다. MoE는 모델 용량과 연산량을 유용하게 분리하지만, 여기에는 조건이 따릅니다.

엑스퍼트가 특정 분야의 전문가라는 보장은 없습니다. Mistral의 Mixtral 분석은 라우팅 패턴이 학문 분야별로 깔끔하게 나뉘지 않는다는 점을 보여 줍니다. 학습된 엑스퍼트는 자격을 갖춘 전문가가 아니며, 라우터가 어떤 엑스퍼트를 골랐는지도 답이 옳은 이유를 설명해 주지는 않습니다.

전체 파라미터가 많다고 더 나은 답을 한다는 증거가 되지는 않습니다. 활성 비율이 낮다고 더 좋은 모델인 것도 아닙니다. 학습, 아키텍처, 수행할 작업이 모두 중요합니다. 앞의 표는 공개된 크기를 설명하기 위한 것이며, 품질 순위표로 만든 것이 아닙니다.

활성 비율이 낮다고 그만큼 요금이 할인되거나 속도가 빨라지는 것은 아닙니다. 그 비율만으로는 제공업체의 요금, 대기열, 네트워크 전송, 작업에 필요한 생성 토큰 수를 알 수 없습니다.

MoE의 핵심 아이디어를 정립한 논문

Shazeer 등의 2017년 논문은 연산량을 비례해서 늘리지 않고도 모델 용량을 키우는, 영향력 있는 희소 게이트 MoE 계층을 정식화했습니다. 거대 신경망: 희소 게이트 전문가 혼합 계층은 이 작동 원리의 핵심 원전입니다. 논문에서 부하 분산과 분산 환경의 성능을 다룬다는 점은 운영상의 절충점이 처음부터 이 아이디어의 일부였음을 보여 줍니다.

개발자가 자주 묻는 MoE 질문

LLM에서 MoE란 무엇인가요?

여러 내부 엑스퍼트 네트워크와 학습된 라우터로 대규모 언어 모델을 구성하는 방식입니다. 희소 MoE에서는 각 토큰이 MoE 계층마다 선택된 엑스퍼트만 사용합니다. 애플리케이션이 호출하는 대상은 여전히 하나의 모델입니다.

GPT-4는 MoE 모델인가요?

GPT-4 기술 보고서는 모델 크기를 비롯한 추가 아키텍처 세부 정보를 공개하지 않습니다. 따라서 이 보고서로는 개발사가 확인한 MoE 파라미터 구성을 알 수 없으며, 소문으로 알려진 수치를 배포 계획의 근거로 사용해서는 안 됩니다.

MoE 모델을 파인튜닝할 때는 무엇을 확인해야 하나요?

파인튜닝은 모델이 학습한 동작을 조정합니다. 전체 가중치를 호스팅하는 데 필요한 자원까지 없애 주지는 않습니다. 조정한 모델의 작업 품질과 라우팅 동작을 대표적인 트래픽 조건에서 평가해야 합니다. Hugging Face의 MoE 가이드는 이때 나타나는 과적합과 부하 균형 문제의 차이를 다룹니다.

다음 배포 결정에 앞서 할 일

월요일에는 최종 후보 모델마다 서빙 검토 메모를 작성하십시오. 개발사가 공개한 전체·활성 파라미터 수, 출처, 정확한 체크포인트나 API 엔드포인트를 기록합니다. 호스팅된 서비스를 이용한다면 작업 결과와 지연 시간 측정값을 추가합니다. 직접 호스팅한다면 전체 가중치 용량, 캐시에 할당할 공간, 예상 트래픽에서의 성능을 추가합니다. 이런 메모가 광고에 나온 가장 큰 숫자로 후보의 순위를 매기는 것보다 유용합니다.

AI 제품을 뒷받침하는 인프라에 대한 실용적인 설명은 뉴스레터를 구독해 받아보실 수 있습니다.