[AI] 오픈소스 모델 파인튜닝 vs 유료 모델 프롬프트 엔지니어링, 승자는?

서비스에 LLM이 붙기 시작하면 제일 먼저 부딪히는 문제가 정확도보다 운영비와 응답 편차입니다. 어느 날은 잘 맞고 어느 날은 말투가 흔들리고, 어느 날은 토큰 비용이 예상보다 훨씬 더 나옵니다. 그 시점부터 팀 안에서 꼭 나오는 질문이 있습니다. 오픈소스모델을 직접 파인튜닝할지, 아니면 유료 모델에 프롬프트 엔지니어링을 더 밀어붙일지 알려드리겠습니다.

오픈소스모델과 파인튜닝, 프롬프트 엔지니어링이 동시에 문제로 떠오른 순간

오픈소스모델, 파인튜닝, 프롬프트 엔지니어링 이야기는 보통 연구 단계에서 시작되지 않습니다. 운영에서 RPS가 80~300 정도로 올라가고, 요청당 입력 프롬프트가 길어지면서 latency가 1초를 넘기기 시작할 때 진짜 고민이 시작됩니다. 제가 봤던 케이스도 비슷했습니다. FAQ성 응답은 괜찮았는데, JSON 포맷 강제와 사내 용어 통일이 붙는 순간 재시도율이 올라가고, 토큰 비용이 월 예상치보다 30~50% 더 튀더군요. 

이때 흔히 나오는 주장이 두 개입니다. 하나는 “그냥 우리 도메인 데이터로 오픈소스모델 파인튜닝하면 끝나는 것 아닌가”이고, 다른 하나는 “아직은 유료 모델에 프롬프트 엔지니어링과 캐싱부터 정리하는 게 맞다”입니다. 실제로 OpenAI와 Anthropic 공식 문서도 프롬프트 엔지니어링을 먼저 다듬고 평가 체계를 붙이는 흐름을 강조하고 있고, 프롬프트 캐싱 같은 기능은 비용과 지연 시간을 줄이는 직접적인 수단으로 안내하고 있습니다.

 

운영에서 처음 보이는 이상 신호

처음에는 모델 자체 성능 문제처럼 보이지만, 뜯어보면 프롬프트 구조 문제인 경우가 생각보다 자주 발생합니다. system prompt가 길고, few-shot 예제가 중복되고, 응답 포맷 요구가 여러 군데 흩어져 있으면 같은 모델도 결과 편차가 커집니다. 특히 멀티턴 대화나 긴 컨텍스트 서비스에서는 고정 프롬프트가 길어질수록 캐시 전략 유무에 따라 비용 차이가 벌어집니다. Anthropic은 프롬프트 캐싱으로 latency를 최대 80%, 비용을 최대 90% 줄일 수 있다고 안내하고 있고, OpenAI도 cached input token 단가를 별도로 두고 있습니다.

 

오픈소스모델 파인튜닝 vs 프롬프트 엔지니어링, Pain Point는 어디서 갈리는가

오픈소스모델을 직접 가져와 파인튜닝하는 쪽은 자유도가 큽니다. 데이터 통제권도 좋고, 특정 용어와 출력 포맷을 강하게 고정하기에도 유리합니다. 다만 운영팀 입장에서는 여기서부터 일이 커집니다. 학습 데이터 정제, 버전 관리, GPU 수급, 추론 엔진 튜닝, 롤백 전략까지 다 직접 가져가야 합니다.

반대로 유료 모델 프롬프트 엔지니어링은 시작이 빠릅니다. 이미 높은 기본 성능이 있는 모델에 시스템 프롬프트, few-shot, structured output, eval 세트를 붙이면 꽤 많은 문제가 해결됩니다. OpenAI와 Anthropic 모두 프롬프트 품질 개선, 예시 추가, 출력 제약, 평가 루프를 먼저 돌려보라고 권장합니다. 즉, 아직 문제의 본질이 “모델 능력 부족”인지 “명세 전달 실패”인지 구분도 안 된 상태라면, 파인튜닝부터 들어가는 건 비용 대비 실패 확률이 높습니다.

 

방법 A: 유료 모델 + 프롬프트 엔지니어링

장점은 빠른 실험 속도입니다. 보통 1~2주 안에 system prompt 정리, few-shot 보강, 응답 스키마 강제, 캐시 적용, 실패 케이스 eval만 붙여도 품질이 꽤 안정됩니다. 캐시가 잘 먹는 구조면 같은 긴 지시문을 반복하는 서비스에서 비용도 꽤 줄어듭니다. OpenAI는 API 가격표에서 cached input token을 별도 단가로 제공하고 있고, Anthropic도 자동 캐싱과 명시적 캐시 포인트를 지원합니다.

단점도 분명합니다. 특정 도메인 용어를 아주 강하게 학습시키거나, 회사 고유 포맷을 매우 일관되게 강제해야 하는 경우에는 프롬프트만으로 한계가 옵니다. 그리고 트래픽이 커질수록 호출 비용이 누적됩니다. 요청당 5천~1만 토큰 수준의 긴 컨텍스트가 반복되면, 캐시를 써도 절대 금액 자체가 부담스러워질 수 있습니다. 특히 기능이 늘수록 prompt sprawl이 생겨서 시스템 프롬프트가 비대해지는 문제도 생깁니다. 체감상 이 지점에서 팀이 다시 파인튜닝을 꺼내 들더군요.

 

방법 B: 오픈소스모델 + 파인튜닝

장점은 통제권입니다. Hugging Face PEFT 문서가 설명하듯 LoRA 같은 방식은 전체 파라미터를 다 다시 학습하지 않고 일부만 효율적으로 조정하므로, 완전 재학습보다 계산량과 저장 비용을 줄일 수 있습니다. SageMaker JumpStart도 사전학습된 오픈소스 모델을 가져와 점진적으로 튜닝하는 흐름을 제공합니다. 즉, 데이터가 충분하고 목표가 명확하면 특정 태스크에 맞춘 모델을 만드는 데 유리합니다. 

하지만 단점은 운영 복잡도입니다. 추론 서버를 직접 띄워야 하고, vLLM 같은 서빙 계층도 이해해야 하며, Linux 환경과 GPU 메모리, 배포 방식, 모델 파일 관리, 어댑터 버전까지 챙겨야 합니다. vLLM은 OpenAI 호환 서버를 제공해서 붙이기 편하긴 하지만, 편하다는 말과 운영 난이도가 낮다는 말은 다릅니다. 생각보다 자주 발생합니다. 처음에는 모델 추론비를 아꼈다고 좋아하다가, 나중에는 GPU 유휴 시간과 장애 대응 비용이 더 크게 보이는 경우도 있습니다.

 

오픈소스모델과 파인튜닝, 프롬프트 엔지니어링 의사결정은 이렇게 했습니다

저라면 대부분의 서비스에서 1차 선택은 유료 모델 프롬프트 엔지니어링입니다. 이유는 간단합니다. 문제 분해가 먼저이기 때문입니다. 출력 포맷 불안정, 용어 흔들림, 장문 컨텍스트 비용, 응답 속도 문제 중에서 무엇이 진짜 병목인지 먼저 확인해야 합니다. 그 작업 없이 오픈소스모델 파인튜닝으로 가면, 잘못된 데이터셋과 잘못된 목표를 더 비싸게 고착화할 수 있습니다.

반대로 아래 조건이 겹치면 오픈소스모델 파인튜닝 쪽으로 기울 수 있습니다. 첫째, 하루 수십만 콜 이상으로 장기 호출 비용이 명확히 부담되는 경우입니다. 둘째, 사내 전문 용어와 출력 형식이 매우 고정적이라 데이터셋으로 학습시키는 편이 유지보수에 낫다고 판단되는 경우입니다. 셋째, 데이터 반출이나 보안 통제 때문에 자체 인프라 선호가 강한 경우입니다. 이 세 가지가 동시에 맞물릴 때는 파인튜닝이 의미 있어집니다.

결론만 말씀드리면 승자는 한쪽이 아닙니다. 하지만 운영 관점의 기본 승자는 프롬프트 엔지니어링입니다. 먼저 프롬프트 엔지니어링으로 문제를 줄이고, 평가셋으로 병목을 확인한 뒤, 그다음에도 남는 반복 오차가 분명할 때 오픈소스모델 파인튜닝으로 넘어가는 순서가 실패 비용이 가장 낮았습니다. 공식 문서들도 프롬프트 개선과 평가를 먼저 강조하고, 파인튜닝은 구조와 도메인 특화가 필요한 경우의 최적화 수단으로 배치하고 있습니다. 

 

오픈소스모델과 프롬프트 엔지니어링을 같이 쓰는 Practical Implementation

실전에서는 둘 중 하나만 쓰는 경우보다 혼합 구성이 더 많습니다. 예를 들어 1차 서비스는 유료 모델로 빠르게 붙이고, 반복 호출이 많은 배치성 태스크나 특정 분류 태스크만 오픈소스모델로 분리합니다. 또는 유료 모델로 gold dataset을 만들고, 나중에 그걸 기반으로 오픈소스모델 어댑터를 학습시키는 식으로 갑니다. 

 

Spring Boot에서 모델 라우팅 분리 예시

아래처럼 요청 성격에 따라 프롬프트 엔지니어링 경로와 오픈소스모델 경로를 분리해두면, A/B 테스트와 롤백이 훨씬 수월합니다. 운영에서 한번 겪어보면 알겠지만 모델 전략을 코드 한 군데에 박아두면 나중에 손댈 때 정말 불편합니다.

llm:
  routing:
    default-strategy: prompt-engineering
    heavy-domain-tasks:
      - refund-policy-classification
      - compliance-tagging

providers:
  paid-model:
    base-url: https://api.openai.com/v1
    model: gpt-5.4
    prompt-cache-enabled: true
    timeout-ms: 8000
    # 긴 system prompt 반복되는 서비스는 캐시 안 켜면 비용 차이 큽니다
  open-source:
    base-url: http://vllm:8000/v1
    model: my-domain-lora
    timeout-ms: 12000
    # GPU 여유 없으면 tail latency 바로 튑니다

vLLM 서빙 구성 예시

오픈소스모델을 직접 운영한다면 추론 서버가 제일 먼저 병목이 됩니다. vLLM은 OpenAI 호환 서버를 제공해서 애플리케이션 연결은 편하지만, 메모리와 배포는 따로 챙겨야 합니다. 공식 문서도 Linux 기반 quickstart와 OpenAI-compatible server 사용법을 안내하고 있습니다.

services:
  vllm:
    image: vllm/vllm-openai:latest
    command: >
      --model /models/my-domain-base
      --served-model-name my-domain-lora
      --max-model-len 8192
    ports:
      - "8000:8000"
    volumes:
      - /data/models:/models
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
    # 배포는 쉬워 보여도 GPU 메모리 부족 나면 응답 시간 급격히 흔들립니다
    # 운영에서 모니터링 없으면 장애 원인 찾기 어렵습니다

프롬프트 엔지니어링 템플릿 예시

프롬프트 엔지니어링은 감으로 하면 안 됩니다. 출력 포맷, 금지 규칙, 예외 처리 기준을 최대한 한 곳에 모아야 합니다. OpenAI와 Anthropic 문서가 공통으로 강조하는 것도 명확한 지시, 예시 제공, 구조화된 출력, 평가 루프입니다. 

{
  "system": [
    "너는 환불정책 분류기다.",
    "반드시 JSON만 반환한다.",
    "label은 REFUNDABLE, NON_REFUNDABLE, NEED_REVIEW 중 하나다.",
    "근거가 불충분하면 NEED_REVIEW를 반환한다."
  ],
  "few_shots": [
    {
      "input": "결제 후 7일 이내, 미사용 상태",
      "output": {"label":"REFUNDABLE","reason":"정책상 환불 가능"}
    },
    {
      "input": "구독 시작 후 사용 이력 있음",
      "output": {"label":"NEED_REVIEW","reason":"예외 정책 검토 필요"}
    }
  ]
}

오픈소스모델 파인튜닝이 이기는 순간, 프롬프트 엔지니어링이 이기는 순간

프롬프트 엔지니어링이 이기는 순간은 분명합니다. 제품 초기, 요구사항이 자주 바뀌는 시기, 데이터셋이 아직 더러운 시기, 운영팀이 GPU와 모델 서빙까지 맡기 어려운 시기입니다. 이때는 유료 모델에 프롬프트 엔지니어링, 캐시, eval, 라우팅 최적화를 붙이는 게 가장 빠릅니다. 기능 출시 속도도 좋고, 실패했을 때 원인도 비교적 빨리 찾을 수 있습니다.

오픈소스모델 파인튜닝이 이기는 순간도 있습니다. 업무 도메인이 매우 좁고 반복적일 때, 레이블링된 예제가 충분할 때, 호출량이 커서 장기 비용 절감이 중요한 때, 또는 데이터 통제권이 절대적으로 필요할 때입니다. 특히 PEFT나 LoRA처럼 효율적 파인튜닝 기법을 쓰면 완전 재학습보다 부담을 줄일 수 있습니다. 다만 여기서도 승부는 모델이 아니라 운영 체계가 냅니다. 데이터셋 버전, 어댑터 버전, 평가셋, 롤백 경로가 없으면 오래 못 갑니다.

 

오픈소스모델 파인튜닝 vs 유료 모델 프롬프트 엔지니어링, Cold Truth

대부분의 팀에게 첫 승자는 프롬프트 엔지니어링입니다. 빠르게 붙이고, 비용 구조를 보고, 실패 케이스를 모으고, 캐시와 평가를 넣는 것만으로도 꽤 많은 문제가 풀립니다. 여기서 안 풀리는 문제가 명확해졌을 때만 파인튜닝이 의미를 가집니다.

반대로 오픈소스모델 파인튜닝은 멋있어 보이지만, 모델보다 운영이 더 어렵습니다. GPU, 서빙, 데이터셋, 모니터링, 장애 대응, 버전 롤백까지 다 챙겨야 합니다. 이거 하나 도입한다고 모든 문제가 해결되지는 않습니다. 결국 운영 환경에 맞는 튜닝이 필요합니다.

 

시작은 유료 모델 프롬프트 엔지니어링, 확장은 혼합 전략, 고정 도메인과 대규모 반복 트래픽에서는 오픈소스모델 파인튜닝. 승자는 상황에 따라 바뀌지만, 운영 리스크까지 포함한 초반 승부에서는 프롬프트 엔지니어링 쪽에 한 표를 줍니다.