DEVOCEAN

MoE(Mixture of Experts, 전문가 혼합) 모델에서 전문가 절반을 비활성화하고도 대화 처리량을 1.6배로 늘렸다는 기록이 나왔습니다. 한편 로컬 개발 환경에서는 Claude Code, OpenAI Codex, Cursor, Antigravity, Gemini CLI를 오갈 때마다 이전 작업 맥락이 끊겨 같은 지시를 다시 타이핑하는 비효율이 반복됩니다.

거대 모델을 실 서비스에 서빙하는 인프라 파이프라인과 로컬 터미널에서 여러 AI 도구를 넘나드는 개발 워크플로우는 규모와 층위가 전혀 다릅니다. 하지만 두 사례는 같은 질문에 닿아 있습니다. 시스템 파이프라인에 누적된 낭비 지점을 어떻게 찾아내어 실제 처리량을 끌어올릴 것인가입니다.

한쪽은 모델 내부에서 고르게 쓰이지 않는 전문가 모듈을 정리해 GPU 서빙 병목을 해결했고, 다른 한쪽은 로컬 에이전트 사이에 끊어진 작업 상태를 CLI 도구로 묶어 개발자의 반복 입력을 줄였습니다.

고르게 쓰이지 않는 전문가: MoE 서빙 인프라의 과감한 정리

대규모 MoE 모델은 모든 토큰이 전체 파라미터를 거치지 않고 라우터를 통해 일부 전문가(Expert) 네트워크만 선택적으로 연산합니다. 이론적으로는 적은 활성 파라미터로 높은 표현력을 얻을 수 있습니다. 그러나 실무 서빙 환경에서는 이야기가 달라집니다. 모든 전문가 가중치를 GPU VRAM(비디오 메모리)에 상주시켜야 하며, 여러 장의 GPU에 전문가를 분산 배치할 경우 통신 오버헤드가 발생합니다.

제타(Zeta)의 머신러닝 엔지니어링 사례에 따르면, 모델 성능을 높이기 위해 더 큰 규모의 MoE 모델을 학습했지만 서빙 비용과 지연 시간 문제가 뒤따랐습니다. 아무리 벤치마크 점수가 높은 모델이라도 실제 서비스에서 유저 요청을 제때 처리하지 못하면 운영이 불가능합니다. 엔지니어링 팀은 실제 서비스 유입 데이터에서 전문가들이 균일하게 호출되지 않는다는 사실에 주목했습니다.

제타 팀은 사용 빈도가 낮은 전문가를 덜어내는 작업을 진행했습니다. 기준은 세 가지였습니다. 전문가가 라우터에 의해 선택되는 빈도, 특정 태스크 성능에 미치는 영향, 그리고 서빙 인프라 관점에서의 처리량입니다. 전문가의 절반을 제거한 뒤 내부 평가와 A/B 테스트를 거친 결과, 대화 처리량을 1.6배로 높이는 성과를 거두었습니다.

그림 1. 제타 팀의 MoE 전문가 정리 과정과 결과

여기부터는 DEVOTEE의 해석입니다. 대규모 MoE 서빙에서 VRAM 할당과 GPU 간 올투올(All-to-All) 통신 비용은 상당한 병목을 유발합니다. 전문가 수가 많아질수록 텐서 병렬화나 전문가 병렬화 과정에서 통신 지연이 늘어나며 메모리 대역폭 한계에 부딪힙니다. 쓰임새가 적은 전문가를 쳐내면 가중치 크기가 줄어들 뿐 아니라, 노드 간 통신 동기화 지점이 감소하여 초당 생성 토큰 수(Throughput)가 늘어납니다.

이 실험은 조건부로 유효합니다. 도메인이 좁고 특정 작업 유형이 반복되는 서비스 환경에서는 활성화 빈도가 낮은 전문가를 덜어내도 정성적 성능 하락이 적습니다. 반면 광범위한 범용 질의를 처리해야 하는 파운데이션 모델 서빙 환경이라면 특정 전문가 제거가 코딩이나 수학 등 특정 하위 도메인의 급격한 성능 저하로 이어질 수 있습니다. 반드시 프로덕션 트래픽 기반의 라우팅 통계와 엄격한 A/B 테스트 환경을 확보한 뒤 적용해야 합니다.

단절된 터미널과 에이전트: 로컬 컨텍스트를 잇는 Vicem

서빙 인프라가 모델 내부의 낭비되는 전문가를 쳐내어 처리량을 회복했다면, 로컬 개발 워크플로우에서는 도구 간 맥락 단절을 이어 붙여 개발자의 작업 효율을 개선하려는 시도가 나왔습니다.

현업 개발자들은 상황에 따라 다양한 AI 도구를 조합해 사용합니다. 터미널 기반의 Claude Code나 Gemini CLI로 빠른 파일 탐색과 변경을 수행하다가, 복잡한 인라인 리팩토링은 Cursor 에디터에서 진행하고, 백그라운드 작업은 OpenAI Codex나 Antigravity에 맡기는 방식입니다. 문제는 이 도구들이 서로 다른 인터페이스와 격리된 세션을 가진다는 점입니다.

터미널에서 디버깅하던 스택 트레이스와 수정된 파일 목록을 에디터 기반 에이전트로 넘기려면, 개발자가 직접 터미널 출력을 복사해 새 프롬프트 입력창에 붙여넣고 현재 상황을 다시 설명해야 합니다. 도구를 바꿀 때마다 맥락이 끊기고 작업 전환 비용이 발생합니다.

오픈소스 CLI/GUI 도구인 Vicem은 이 지점을 해결하기 위해 개발되었습니다. Vicem은 Claude Code, OpenAI Codex, Cursor, Antigravity, Gemini CLI 등 로컬에서 사용하는 다양한 AI 코딩 에이전트 사이에서 작업 컨텍스트를 전달하고 세션을 전환해 줍니다. 직전 도구에서 수행하던 파일 수정 기록, 발생한 에러 로그, 마지막 질의 내용을 다음 도구가 바로 읽을 수 있는 규격화된 상태 파일로 보존하고 넘겨주는 구조입니다.

그림 2. Vicem이 상태 파일로 도구 간 맥락을 넘기는 구조

이 도구는 지금 써볼 만합니다. 로컬에서 복수의 코딩 에이전트를 병행 사용하는 개발자라면 누구나 도구 간 복사-붙여넣기와 상태 설명에 적지 않은 시간을 씁니다. Vicem은 별도의 원격 서버나 복잡한 프레임워크 설정 없이 로컬 파일시스템과 CLI 환경에서 동작하므로 진입 장벽이 낮습니다.

실무에서 달라지는 점: 수작업 동기화를 걷어내는 파이프라인

작업 맥락을 도구 간에 수동으로 전달하지 않고 자동화된 파이프라인으로 처리하면 워크플로우가 단순해집니다.

기존에는 Claude Code에서 테스트 실패를 수정한 뒤 Cursor나 Codex로 넘어가려면 다음과 같은 단계를 거쳤습니다.

[기존 방식: 수동 맥락 복사]
1. Claude Code 터미널에서 git diff 및 테스트 실패 로그 확인
2. 텍스트 터미널에서 필요한 블록을 마우스로 드래그하여 클립보드 복사
3. Cursor 또는 다른 에이전트 실행
4. 프롬프트 창에 "직전 터미널에서 이런 변경을 했고 이런 에러가 났으니 이어서 작업해줘"라고 입력 후 붙여넣기

Vicem과 같은 맥락 전환 도구를 활용하면 에이전트 실행 상태를 표준화된 JSON 또는 마크다운 메타데이터로 캡처하여 전달할 수 있습니다. 로컬 파이프라인에서 직전 에이전트의 작업 맥락을 내보내고 다음 도구의 입력으로 연결하는 자동화 스크립트 예시입니다.

#!/usr/bin/env bash
set -euo pipefail

# 작업 상태 파일 경로 지정
CONTEXT_DIR=".agent_context"
CURRENT_STATE="${CONTEXT_DIR}/latest_state.json"

mkdir -p "${CONTEXT_DIR}"

echo "[1/3] 로컬 작업 트리 변경점 및 최근 커밋 로그 캡처"
git status --short > "${CONTEXT_DIR}/git_status.txt"
git diff > "${CONTEXT_DIR}/git_diff.patch"
git log -1 --stat > "${CONTEXT_DIR}/recent_commit.txt"

echo "[2/3] 도구 전환을 위한 통합 컨텍스트 상태 파일 생성"
cat <<EOF > "${CURRENT_STATE}"
{
  "timestamp": "$(date -u +"%Y-%m-%dT%H:%M:%SZ")",
  "branch": "$(git rev-parse --abbrev-ref HEAD)",
  "head_commit": "$(git rev-parse HEAD)",
  "modified_files": [
$(git diff --name-only | awk '{print "    \"" $0 "\""}' | paste -sd, -)
  ],
  "context_snapshot": "${CONTEXT_DIR}/git_diff.patch"
}
EOF

echo "[3/3] 통합 컨텍스트 준비 완료: ${CURRENT_STATE}"
# Vicem CLI를 호출하여 대상 에이전트로 작업 상태를 전달합니다.
# 실제 호출 방식과 옵션은 Vicem 공식 문서를 확인하세요.
vicem switch --to cursor --context "${CURRENT_STATE}"

이처럼 작업 디렉토리의 변경 사항과 실행 맥락을 정형화된 스냅샷으로 남기면, 개발자가 일일이 이전 작업 내역을 요약해 줄 필요가 없습니다. 다음 도구는 지정된 상태 파일을 읽어 즉각 연속적인 컨텍스트 위에서 코드 작성을 시작할 수 있습니다.

복잡성을 제어하는 실무적 기준

인프라 레벨의 전문가 프루닝(Pruning, 가지치기)과 개발 환경의 에이전트 전환 도구는 모두 시스템이 커지면서 필연적으로 발생하는 지연 요소를 통제하는 기술입니다.

MoE 서빙 최적화가 주는 실무 기준은 명확합니다. 모델 파라미터 수가 크다고 해서 모든 구성 요소가 균등한 부가가치를 창출하지 않습니다. 실제 프로덕션 워크로드에서 어떤 전문가가 유휴 상태에 머무는지 관측하고, 병목을 유발하는 유휴 컴포넌트를 선별적으로 격리할 때 서빙 처리량은 올라갑니다.

로컬 에이전트 생태계 역시 마찬가지입니다. 단일 만능 도구에 의존하기보다 각 태스크에 특화된 경량 도구를 조합해 쓰는 흐름이 강화되고 있습니다. 이때 핵심은 도구 자체가 아니라 도구 사이를 흐르는 컨텍스트의 파이프라인화입니다. 상태 전달이 매끄럽지 못하면 다중 에이전트 도입은 개발자에게 맥락 복사라는 새로운 잡무를 부과할 뿐입니다.

직접 해 볼 수 있는 한 가지

팀의 파이프라인에 누적된 낭비를 점검하기 위해 오늘 바로 적용해 볼 수 있는 구체적인 액션이 있습니다.

현재 팀에서 AI 코딩 도구를 2개 이상 병용하고 있다면, 한 도구에서 다른 도구로 넘어갈 때 전달하는 정보의 형태를 기록해 보세요. 대부분의 경우 git diff 결과물, 최근 실행한 테스트의 표준 출력(stdout/stderr), 그리고 변경 대상 파일 경로입니다. 이 세 가지 정보를 셸 함수 하나로 묶어 특정 디렉토리에 덤프하는 스크립트를 작성해 두는 것만으로도 도구 전환 시 발생하는 입력 지연을 크게 줄일 수 있습니다.

또한 모델을 자체 서빙하고 있는 머신러닝 팀이라면 서빙 게이트웨이 로그에서 각 전문가의 선택 빈도 분포를 집계해 보시기 바랍니다. 상위 20%의 전문가가 전체 요청의 80% 이상을 처리하고 있다면, 하위 전문가 모듈을 분리하거나 서빙 노드에서 제외하는 실험을 설계할 명확한 데이터 근거가 됩니다.

그 밖의 소식

외부 당구(outer billiards) 수학 시스템: 원문
ArchiveWeb.page를 활용한 개인 웹사이트 아카이빙 가이드: 원문
배송 파손 민원 사칭 메일로 유포되는 PureRAT 악성코드 주의: 원문