Tec-Blog Technology & DevOps

AI Kim, DongKi

LLM API 서비스 선택 가이드

TL;DR

  • OpenAI — 생태계·도구 호출·멀티모달이 넓고, 범용 API로 무난. 비용은 토큰 단가·출력 길이에 민감
  • Anthropic — 긴 맥락·문서·코드 추론에 강한 편. 에이전트형 장작업·정책 준수가 중요할 때 후보
  • 로컬(Ollama 등) — 데이터가 밖으로 안 나감. 초기 비용은 GPU·전기지만 호출당 과금 없음. 속도·품질은 하드웨어·모델에 달림
  • 선택은 “최고 모델” 하나가 아니라 비용·지연·프라이버시 세 축에서 시나리오를 나누는 게 현실적

들어가며

에이전트·봇·자동화를 붙이다 보면 결국 같은 질문에 닿습니다. “GPT 쓸까, Claude 쓸까, 아니면 로컬로 갈까?” 2021년엔 Copilot API 하나만 보면 됐는데, 지금은 cron이 돌고, Discord 봇이 있고, IDE 에이전트까지 겹치면 호출 지점마다 요구사항이 다릅니다.

이 글은 벤더 순위가 아니라, 제가 Hermes·개인 프로젝트에서 provider를 고를 때 쓰는 트레이드오프 프레임을 정리한 겁니다.

비교할 때 보는 네 가지 축

축 질문 대략적인 감
비용 토큰·월 한도·배치 할인? 클라우드 API는 출력 토큰이 특히 비쌈. cron·리포트는 모델 다운그레이드 후보
지연 첫 토큰(TTFT)·전체 응답 시간? 채팅은 체감 지연, 배치는 처리량. 로컬은 GPU VRAM이 병목
프라이버시 데이터가 외부로 나가도 되나? 개인 메모·내부 문서는 로컬 또는 self-host. 공개 문서 요약은 클라우드 OK
능력 맥락 길이·도구 호출·코드? 같은 가격대라도 모델 세대·컨텍스트 윈도우 차이가 큼

“가장 똑똑한 모델” 하나로 통일하면 비용 폭탄이거나, 반대로 로컬 소형 모델만 쓰다가 복잡한 작업에서 맥락을 잃기 쉽습니다.

OpenAI API

강점

  • 문서·SDK·서드파티 연동이 가장 넓음
  • function calling / structured output 등 도구 연동 패턴이 익숙
  • 이미지·음성 등 멀티모달 확장이 수월

약점·주의

  • 인기 모델은 단가·rate limit 경쟁이 있음
  • 긴 에이전트 루프는 출력 토큰 누적이 빠름 — 작업 쪼개기·요약 중간 단계 필요

잘 맞는 시나리오

  • 범용 챗봇·프로토타입
  • 외부 도구(JSON 스키마)와 맞물린 자동화
  • “일단 붙여보고” 빠른 검증
# 환경변수로 키 주입 (코드·레포에 박지 말 것)
export OPENAI_API_KEY="sk-..."

Anthropic API

강점

  • 긴 문서·코드베이스·정책 텍스트를 한 번에 넣는 패턴에 유리한 경우가 많음
  • 안전·지시 따르기 쪽에서 보수적으로 쓰는 팀도 있음
  • Claude 계열은 터미널 에이전트(Claude Code)와 같은 라인업이라 맥락 스타일이 비슷

약점·주의

  • 가격표·모델명이 자주 갱신 — cron 전에 config 재확인
  • OpenAI만큼 주변 생태계가 넓진 않음 — 어댑터 레이어 두는 게 안전

잘 맞는 시나리오

  • ADR·스펙·긴 README 기반 작업
  • “규칙 많은” 에이전트 (스킬·금지어·ponytail 같은 제약)
  • 출력 품질보다 맥락 유지가 중요한 배치
export ANTHROPIC_API_KEY="sk-ant-..."

로컬 LLM — Ollama 등

강점

  • 프롬프트·파일 내용이 외부로 안 나감 (오프라인도 가능)
  • 호출당 과금 없음 — cron을 자주 돌려도 API 청구서는 안 불어남
  • Hermes·Open WebUI·자체 스크립트에서 localhost로 붙기 쉬움

약점·주의

  • VRAM·RAM에 따라 쓸 수 있는 모델 크기가 갈림
  • 최신 플래그십 대비 추론·코드 품질은 모델 선택에 크게 의존
  • 첫 로드·긴 컨텍스트는 지연이 튈 수 있음

잘 맞는 시나리오

  • 개인 메모·로컬 파일만 다루는 봇
  • 이틀에 한 번 도는 블로그 cron처럼 빈도는 높지만 민감도는 낮은 작업 (단, 품질 확인은 필요)
  • API 키를 서버에 두기 싫을 때
ollama pull llama3.2
ollama serve   # 기본 http://localhost:11434

Hermes config.yaml 예시 (개념만):

providers:
  ollama:
    base_url: http://localhost:11434
model: ollama/llama3.2

시나리오별로 나누는 법 (제 기준)

  1. 대화형·빠른 피드백 — 클라우드 중간급 모델. 로컬은 7B~14B급이 체감 속도 나쁘지 않음
  2. 야간 cron·정기 리포트 — 비용 우선이면 작은 모델 + 짧은 프롬프트. 품질 우선이면 하루 1회만 큰 모델
  3. 코드·멀티파일 에이전트 — IDE는 Cursor ACP 등 이미 붙은 백엔드 활용. 서버 cron은 Claude/OpenAI 중 맥락 길이 맞는 쪽
  4. 민감 데이터 — 로컬 또는 self-hosted vLLM. 클라우드는 익명화·요약만 보내는 식으로 레이어 분리

한 provider로 끝낼 필요 없습니다. Hermes는 실행마다 model/provider를 바꿀 수 있고, 프로필을 나누면 work용 API / home용 Ollama처럼 분리도 됩니다.

비용을 줄이는 실전 팁

  • 입력 다이어트 — SSoT·INDEX 요약, 필요한 파일만 컨텍스트에 (이전 글의 맥락 관리와 연결)
  • 출력 상한 — max_tokens, “3문단 이내” 같은 하드 제약
  • 모델 티어 분리 — 분류·라우팅은 소형, 최종 작성만 대형
  • 캐시·반복 — 같은 질문 cron은 watchdog 모드로 상태만 확인 (다음 글에서 cron 자세히)

선택 체크리스트

  • 데이터가 외부로 나가면 안 되나? → 로컬 / self-host
  • 월 예산이 고정인가? → 소형 모델 + 호출 빈도 조절
  • 첫 응답이 1초 안에 와야 하나? → 클라우드 + 작은 모델, 또는 로컬 GPU 업그레이드
  • 도구 호출·JSON이 핵심인가? → OpenAI 계열 먼저 검증
  • 긴 문서 한 방에 넣나? → Anthropic 후보 + 컨텍스트 한도 확인

마무리

LLM API는 “어디가 제일 똑똑하냐”보다 어디에 얼마를 쓰고, 무엇을 밖으로 보낼지가 먼저입니다. 저는 대화·실험은 클라우드, 반복 cron·로컬 파일은 Ollama, IDE 작업은 Cursor ACP 쪽으로 역할을 나눠 씁니다.

다음 글에서는 Hermes cron으로 이런 작업을 어떻게 예약·배달하는지 이어서 정리할 예정입니다.

Comments