로컬 AI 워크스페이스가 주목받고 있는 한편, 그에 반대되는 논거도 힘을 얻고 있습니다. 호스팅된 모델들이 계속해서 저렴해지거나 무료로 제공되는데, 굳이 하드웨어를 유지 관리할 필요가 있을까요? 두 입장 모두 대개 막연한 느낌(vibes)에 근거합니다. 이 글은 이러한 느낌을 오후 한나절이면 실행할 수 있는 작고 반복 가능한 하네스(harness)로 대체하여, 여러분의 코딩 워크플로우에 대한 "로컬 vs 무료 호스팅" 결정이 직접 생성한 수치에 기반하도록 하는 것에 관한 것입니다.

아래의 하네스는 일상적인 코딩 보조에 실제로 중요한 세 가지 요소, 즉 첫 번째 토큰 생성 시간(time to first token), 전체 작업 지연 시간(total task latency), 그리고 출력이 기계적 검사(컴파일 여부, 실행 여부 또는 패턴 일치 여부)를 통과하는지 여부를 측정합니다. 이 하네스는 대부분의 로컬 서버(llama.cpp, Ollama, vLLM)와 대부분의 호스팅 제공업체를 아우르는 모든 OpenAI 호환 채팅 엔드포인트(chat endpoint)에서 작동합니다.

작업 스위트: 작고, 고정되어 있으며, 정직함

작업이 모호할 때 벤치마크(Benchmarks)는 실패합니다. 실제 업무를 반영하는 6~10개의 작업을 선택하고 이를 고정하십시오. 예시 스위트:

프롬프트(prompts)를 토씨 하나 틀리지 않고 그대로 고정하십시오. 실행 사이에 프롬프트를 수정한다면, 여러분은 모델이 아니라 프롬프트 드리프트(prompt drift)를 벤치마킹하는 것입니다.

러너(The runner)

이것이 핵심 결과물입니다. bench.mjs로 저장하십시오 (Node 18+, 의존성 없음):

// bench.mjs — 고정된 작업 스위트에서 OpenAI 호환 엔드포인트 비교
// 사용법: ENDPOINT=http://localhost:11434/v1 MODEL=qwen2.5-coder node bench.mjs
import { execFileSync } from 'node:child_process';
...
```
{% endraw %}
(?:js|javascript)?
{% raw %}
```/); 
  return m ? m[1] : text;
}

그리고 tasks.json:

[
  {
    "id": "T1",
...

온도(Temperature)는 0으로 고정되며, 프롬프트는 고정되어 있고, 각 실행은 나중에 차이점(diff)을 비교할 수 있는 모델별 결과 파일을 작성합니다. 엔드포인트당 스위트를 최소 3회 실행하고 중앙값(medians)을 취하십시오. 단일 실행 결과는 거짓말을 할 수 있습니다.

무료 호스팅 티어가 비교에서 차지하는 위치

로컬 추론 (Local inference)에는 실제 비용이 발생합니다: GPU 전력 소모, IDE가 열려 있는 동안의 RAM 압박 (RAM pressure), 그리고 모델 빌드를 최신 상태로 유지하기 위한 유지보수 비용 (maintenance tax) 등이 그것입니다. 무료 호스팅 옵션은 정확히 동일한 스위트 (suite)를 사용하여 벤치마킹할 가치가 있는데, 왜냐하면 간헐적인 개인 사용의 경우 경제성이 사람들이 가정하는 것과 정반대인 경우가 많기 때문입니다.

MonkeyCode는 결과 테이블의 한 행으로 포함할 가치가 있는 그러한 옵션 중 하나입니다. 현재 무료 모델 액세스와 무료 서버 옵션을 제공하므로, 하드웨어를 구축하지 않고도 동일한 러너 (runner)를 해당 서비스의 OpenAI 호환 엔드포인트 (endpoint)로 지정할 수 있습니다. 이 하네스 (harness)는 엔드포인트 불가지론적 (endpoint-agnostic)이므로, 환경 변수 하나만 변경하면 추가할 수 있습니다:

ENDPOINT=<monkeycode-endpoint> MODEL=<model-name> API_KEY=<key> node bench.mjs

고지 사항: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다. 아래의 벤치마크 코드, 방법론 및 결론은 해당 관계와 독립적입니다. 원하는 모든 엔드포인트를 대상으로 하네스를 실행해 보시고, 여기에 작성된 내용보다 귀하의 출력 파일을 더 신뢰하십시오. 무료 티어의 가용성과 가격은 변경될 수 있으므로, 이를 의존하기 전에 현재 약관을 확인하십시오. 또한, 손실을 감당할 수 없는 자동화 프로세스에 어떠한 무료 티어도 포함시키지 마십시오.

결과 읽기: 결정 매트릭스 (decision matrix)

중앙값 (medians)을 수집한 후, 각 엔드포인트를 귀하의 제약 조건에 따라 평가하십시오:

통과율 (pass-rate) 행은 사람들이 건너뛰기 쉽지만 건너뛰어서는 안 되는 부분입니다. 200ms 만에 응답하지만 node --check를 절반의 확률로 실패하는 모델은, 귀하의 디버깅 시간을 포함하면 실제 경과 시간 (wall-clock terms) 측면에서 더 느립니다.

한계점, 그리고 이 과정을 건너뛰어야 할 대상

• 6개의 태스크는 학술적 의미의 벤치마크가 아닙니다. 이는 오직 사용자 워크플로우의 적합성을 측정할 뿐입니다. 이 수치를 모델 순위로 발표하지 마세요.
• 기계적 점검은 품질을 과소평가합니다. node --check는 구문(syntax)을 증명할 뿐, 정확성(correctness)을 증명하지 않습니다. 강력한 결론을 내리기 전에 실제 단위 테스트(unit tests)를 통해 스위트(suite)를 확장하세요.
• 무료 티어(Free tiers)는 변동됩니다. 속도 제한(Rate limits), 모델 가용성, 이용 약관은 예고 없이 변경됩니다. 분기별로 다시 실행하고, 폴백 엔드포인트(fallback endpoint)를 구성해 두세요.
• 다음의 경우 이 과정을 완전히 건너뛰십시오. 추론(inference)이 발생하는 위치를 규정하는 컴플라이언스(compliance) 체제 하에 있다면 — 그 결정은 이미 내려져 있습니다 — 또는 이미 유료 API를 사용 중이며 좋은 결과로 워크로드가 포화 상태라면 말입니다. 이 하네스(harness)는 결정을 내리지 못한 중간 단계의 사용자들을 위해 존재합니다.

결론

로컬 대 호스팅 논쟁은 보통 더 강력한 일화를 가진 쪽이 승리하며 끝납니다. 60줄짜리 러너(runner)와 고정된 태스크 스위트(task suite)는 하드웨어, 모델, 또는 무료 티어 약관이 변할 때마다 언제든 다시 답할 수 있는 질문으로 이 논쟁을 바꿔 놓습니다. 만약 이 하네스를 시도한다면, 댓글로 공유할 수 있는 가장 유용한 것은 당신의 승자가 아니라, 당신이 추가한 태스크들입니다. 그것이야말로 이 스위트를 전이 가능하게(transferable) 만드는 요소이기 때문입니다.