Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 05. 21:42

Claude Code를 계속 사용하며 한 가지를 추가했습니다. AI 엔지니어링 비용을 62% 절감했습니다.

요약

Claude Code와 AI 에이전트(Neo)를 결합하여 AI 엔지니어링 비용을 62% 절감한 사례를 소개합니다. 에이전트가 작업을 사전에 분석하고 최적화된 접근 방식을 결정함으로써 동일한 작업에서 비용 효율성을 극대화할 수 있음을 보여줍니다.

핵심 포인트

  • Claude Code와 AI 에이전트 결합 시 비용 62% 절감
  • 단순 프롬프트 엔지니어링보다 에이전트의 작업 할당이 핵심
  • CPU 환경에 최적화된 모델 실행 전략의 중요성
  • 에이전트를 통한 워크플로우 최적화로 운영 비용 효율화

동일한 작업. 동일한 머신. 동일한 모델. 두 번의 실행. $1.96 대 $0.74.

그 차이는 프롬프트 엔지니어링 (Prompt Engineering) 때문이 아니었습니다. 더 저렴한 모델 때문도 아니었습니다. 더 좋은 GPU 때문도 아니었습니다. 그것은 Claude Code가 단독으로 작동했는지, 아니면 단 하나의 파일에 손을 대기 전에 AI 에이전트 (AI Agent, Neo)에게 작업을 넘겼는지의 차이였습니다.

실제로 어떤 일이 일어났는지 설명하겠습니다.

작업 (The Task)

CPU 전용 Azure VM (2 vCPUs, 7.7GB RAM, GPU 없음)에서 두 가지 Parakeet 음성-텍스트 변환 (Speech-to-Text) 변형 모델을 벤치마크합니다:

프레임워크: build-ai-applications/Eval-STT. 두 모델 모두 기본적으로 지원되지 않으므로, 두 실행 모두 커스텀 코드로 평가기 (Evaluator)를 확장해야 했습니다.

지표 (Metrics): WER, RTF, 지연 시간 (Latency), CPU 사용률 (CPU%), 피크 메모리 (Peak Memory).

실행 1: Claude Code, 대화형 (Interactive)

표준 워크플로우. 작업을 설명하고, 차례대로 반복하며, 오류가 나타나면 수정하고, 완료합니다.

Claude Code가 선택한 방식:

# HuggingFace Transformers — 명확한 경로
from transformers import pipeline

...

HF Transformers를 통한 bfloat16. 합리적입니다. 작동합니다. 하지만 CPU 전용 환경을 위한 최선의 선택은 아닙니다.

테스트 오디오용: espeak-ng. 오프라인, 빠름, 의존성 없음.

결과:

모델WERRTF지연 시간 (Latency)
HF bfloat1620.9%0.5198.60s
GGUF Q4_K20.9%0.79713.21s

두 모델 모두 동일한 세 가지 오류를 범했습니다: "zest" → "mest", "tacos al pastor" → "taco mel pastor", "zestful" → "nestful". 두 모델 모두 동일한 오류를 냈다는 것은, 모델의 실패가 아니라 espeak-ng가 엣지 케이스 (Edge Case)를 잘못 발음했음을 의미합니다.

총 비용: $1.96

How each workflow actually happened — step by step

실행 2: Claude Code + Neo

단 하나의 프롬프트. Claude Code는 MCP를 통해 Neo에게 작업을 제출하고 물러났습니다.

Neo의 첫 번째 행동은 코드를 작성하는 것이 아니었습니다. Neo는 다음 항목들을 읽는 데 2분을 소비했습니다:

  • Eval-STT 노트북 구조
  • 두 모델 모두에 대한 HuggingFace 모델 카드 (Model Cards)
  • NeMo/Parakeet의 CPU 추론 벤치마크 (Benchmarks)
  • x86 환경에서의 ONNX Runtime 대 PyTorch 처리량 (Throughput)
  • parakeet.cpp 빌드 요구 사항 및 GGUF 양자화 단계 (Quantization Tiers)

그 후 Neo는 계획을 작성하고 한 가지 질문을 던졌습니다: "오디오용으로 gTTS를 사용할까요, 아니면 LibriSpeech 샘플을 사용할까요? GGUF의 경우 Q4_K를 사용할까요, Q6_K를 사용할까요?"

답변: "당신이 결정하세요."

Neo가 선택한 것:

# onnx-asr을 통한 ONNX Runtime — 조사 결과 도출됨, 명확하지 않았던 부분
from onnx_asr import load_model

...

연산자 융합 (Operator Fusion) 및 AVX2 최적화 커널 (Kernels)이 적용된 ONNX Runtime을 선택했습니다. 벤치마크 결과에 따라 CPU 환경에서는 PyTorch 경로보다 더 빠르기 때문입니다.

GGUF의 경우: Q4_K 대신 Q6_K (776MB)를 선택했습니다. 품질의 여유(Headroom)가 더 좋으면서도 사용 가능한 RAM에 여전히 들어맞습니다.

테스트 오디오의 경우: gTTS를 선택했습니다. 자연스러운 음성으로, 학습 분포 (Training Distribution)에 더 가깝습니다.

결과:

모델WERRTF지연 시간 (Latency)피크 메모리 (Peak Memory)
ONNX FP324.65%0.3285.50s2,667MB
GGUF Q6_K4.65%0.70811.88s928MB

총 비용: $0.7448

숫자가 실제로 의미하는 것

Cost comparison — $1.96 vs $0.74

WER 격차는 모델이 아니라 오디오에 관한 것입니다

두 모델 모두 각 실행(Run) 내에서 동일한 WER을 기록했습니다: 실행 1에서는 20.9%, 실행 2에서는 4.65%였습니다. 만약 양자화 (Quantization)나 모델 선택이 변수였다면, 동일한 실행 내에서 모델 간에 서로 다른 WER이 나타났을 것입니다. 하지만 그렇지 않았습니다.

변수는 TTS 엔진이었습니다. espeak-ng는 세 단어에서 오류를 일으키는 로봇 같은 오디오를 생성했습니다. 반면 gTTS는 모델이 올바르게 처리할 수 있는 자연스러운 오디오를 생성했습니다. NVIDIA는 이 모델에 대해 LibriSpeech 기준 1.93%의 WER을 보고합니다. 실제 수치는 대화형 실행(Interactive Run)에서 보여준 수치가 아니라, Neo의 실행에서 보여준 수치에 가깝습니다.

RTF comparison by model and approach

RTF 격차는 실행 시점의 선택에 관한 것입니다

RTF 0.519 대 0.328. 동일한 모델 가중치(Model weights). 동일한 하드웨어. 서로 다른 추론 백엔드(Inference backend).

이 37%의 처리량(Throughput) 향상은 CPU 전용 배포 시 기본값인 HF Transformers 대신 ONNX Runtime을 선택했을 때 얻을 수 있는 결과입니다. Neo는 작업을 시작하기 전 벤치마크를 읽음으로써 이를 발견했습니다. 대화형 실행(Interactive run)은 당연한 경로를 기본값으로 선택했기에 더 깊이 살펴볼 이유가 없었습니다.

운영(Production) 관점에서 말하자면, 이는 서버 2대와 3대의 차이와 같습니다.

비용 격차는 반복(Iteration)에 관한 것입니다

$1.96 대 $0.74. 대화형 모드(Interactive mode)는 매번 다시 읽고, 수정하고, 대화를 주고받을 때마다 토큰을 소모합니다. Neo는 한 번 계획을 세운 뒤 선형적으로 실행했습니다 — 10개의 하위 작업(Subtasks)을 수행하고, 각 작업이 끝날 때마다 스스로 검증했으며, 불필요한 대화(Back-and-forth)를 하지 않았습니다.

구조화된 계획(Structured plan)은 대규모 AI 엔지니어링을 비싸게 만드는 반복 오버헤드(Iteration overhead)를 제거했습니다.

코드 비교

Claude Code 단독 사용 — 단일 통합 평가기(Single unified evaluator):

class ParakeetEvaluator:
    models_cfg = {
        "parakeet-tdt-0.6b-v3-hf": (
...

Claude Code + Neo — 모델별 개별 스크립트:

python evaluate_onnx.py   # ONNX Runtime 경로
python evaluate_gguf.py   # parakeet.cpp 경로

Neo는 더 깔끔한 디버깅과 검증을 위해 이들을 분리해 두었습니다. 각 스크립트는 자체적인 JSON을 출력하며, 결합된 results.json이 이를 병합합니다. 또한 Neo는 각 결과물(Artifact)을 만든 후, 단계를 완료로 표시하기 전에 내부 검증 체크(파일 재읽기, 크기 확인, 종료 코드 확인 등)를 수행했습니다.

전체 코드, 결과, 그리고 Neo의 실행 전 계획은 GitHub 리포지토리에서 확인할 수 있습니다.

Final scorecard across 8 dimensions

언제 무엇을 사용할 것인가

다음과 같은 경우에는 대화형 Claude Code를 계속 사용하세요:

  • 탐색 중이며 아직 정확히 무엇을 원하는지 모를 때
  • 단순히 결과물만 얻는 것이 아니라, 무엇이 구축되고 있는지 이해해야 할 때
  • 작업이 충분히 짧아서 계획 수립에 드는 오버헤드(Overhead)가 가치가 없을 때
  • 실시간 판단이 필요한 무언가를 디버깅(Debugging)할 때

다음과 같은 경우에는 Neo를 추가하세요:

  • 평가(Evaluation), 미세 조정(Fine-tuning), RAG, 추론 벤치마킹(Inference benchmarking)과 같이 정의된 AI/ML 파이프라인(Pipeline)이 있을 때
  • 시작하기 전에 명확하지 않은 결정 지점(런타임, 양자화(Quantization), 데이터셋 등)이 있을 때
  • 과정이 아닌 결과물을 원할 때
  • 반복되거나 확장된 실행 시 토큰(Token) 비용이 중요할 때

패턴은 다음과 같습니다. 작업이 "올바른 접근 방식을 파악한 다음 실행하라"는 형태에 가까울수록, 연구 우선형 에이전트(Research-first agent)가 대화형 반복(Interactive iteration)보다 더 우세합니다.

설정

Neo는 Claude Code 내부에서 MCP를 통해 로컬에서 실행됩니다. claude_desktop_config.json에 다음을 추가하세요:

{
  "mcpServers": {
    "neo": {
...

여러분의 코드, 모델, 데이터는 여러분의 머신에 그대로 유지됩니다. 원격으로 전송되는 것은 아무것도 없습니다.

그런 다음 Claude Code에서 AI 엔지니어링 작업을 설명하기만 하면 Neo가 실행을 처리합니다.

모든 코드, 결과 및 차트가 포함된 리포지토리(Repo): github.com/gauravvij/parakeet-stt-eval

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0