RAG와 파인튜닝, 사내 지식과 응답 방식에 맞춰 선택하는 법

모델에 필요한 사내 정보가 없다면 RAG를, 정보는 충분한데도 문체나 판단 기준이 반복해서 어긋난다면 파인튜닝을 검토해야 합니다. RAG와 파인튜닝의 차이는 답변의 근거를 제공하느냐, 응답 방식을 학습시키느냐에 있습니다. 아래의 3가지 업무 사례를 보면 학습 비용이 저렴하다고 해서 전체 시스템 비용까지 저렴한 것은 아니라는 점이 드러납니다.

문서, 모델 제공 여부, 정가는 2026년 10월 16일에 확인했습니다. 아래의 작업량과 비용 계산은 예산 수립을 위한 예시이며, 실제 고객의 측정 결과가 아닙니다.

RAG 파인튜닝 차이: 먼저 해결할 문제를 구분합니다

검색은 필요한 지식에 접근하는 문제를, 파인튜닝은 반복되는 응답 방식의 문제를 다룹니다. 이 구분이 있어야 어떤 서비스를 구매할지에 앞서 어디에 노력을 들일지 결정할 수 있습니다.

검색 증강 생성, 즉 RAG는 모델이 답변하기 전에 관련 자료를 찾아 작업 컨텍스트에 넣어 줍니다. 파인튜닝은 원하는 응답이나 판단의 예시로 사전 학습된 모델을 추가 학습해 모델의 파라미터를 바꿉니다. 고객지원 담당자에 비유하면 검색은 최신 업무 매뉴얼을 건네는 것이고, 파인튜닝은 잘못된 사례를 바로잡으며 업무 방식을 가르치는 것입니다. 어느 쪽도 명확한 지시를 대신하지는 못합니다.

이는 실무에서 유용한 기본 구분이지, 학습으로 사실을 익힐 수 없다는 법칙은 아닙니다. 파인튜닝으로 사실 간의 연관 관계를 학습할 수는 있습니다. 그렇다고 최신 정책, 문서 접근 권한, 출처를 믿고 조회할 수 있는 데이터베이스가 생기는 것은 아닙니다. AWS의 비교 문서도 지식 제공과 모델 맞춤화의 역할을 구분합니다.

올바른 근거를 넣어 확인해 봅니다. 실패한 질문에 정확한 최신 문단을 직접 제공해 보십시오. 답변이 요구 수준에 도달한다면 검색을 고쳐야 합니다. 그래도 실패한다면 지시, 작업 난도, 응답 방식을 살펴야 합니다. 이처럼 더 단순한 기본 구성을 먼저 개선한 뒤에야 파인튜닝을 후보로 올릴 수 있습니다.

개발자에게는 문서 파이프라인과 학습 파이프라인을 구분하는 기준이 됩니다. 운영자에게는 지식 관리 담당자와 학습 예시 승인 담당자 중 누가 문제를 맡아야 하는지 알려 줍니다. 구매 담당자에게는 유용한 인수 기준이 됩니다. 추가 구성 요소가 어떤 실패를 해결하는지 공급업체에 입증하도록 요구할 수 있기 때문입니다.

RAG·파인튜닝·프롬프트 엔지니어링은 어떻게 다를까요?

해당 작업의 통과 기준을 충족하는 가장 작은 변경부터 시작합니다. 프롬프트 엔지니어링은 요청에 담는 지시, 예시, 컨텍스트를 개선하는 작업입니다. 검색 기반 시스템에서도, 파인튜닝 시스템에서도 계속 필요합니다.

RAG와 프롬프트 엔지니어링의 차이

필요한 자료가 이미 요청에 들어 있다면 프롬프트로 해결합니다. 애플리케이션이 사내 자료에서 필요한 내용을 찾아야 한다면 검색을 추가합니다. 모델이 전달받지 못한 해지 조항을 지시문 개선만으로 알아낼 수는 없습니다. 반대로 조항을 어떻게 적용할지에 관한 지시가 서로 모순된다면 검색 인덱스로 해결할 수 없습니다.

프롬프트 엔지니어링과 파인튜닝의 차이

자주 바뀌는 브랜드 규칙과 가끔 수행하는 작업은 프롬프트로 관리합니다. 명확한 지시와 대표 예시를 줘도 일정하게 반복해야 하는 응답 방식에서 계속 실패한다면 파인튜닝을 검토합니다. Google의 튜닝 가이드도 먼저 프롬프트 기반의 기준선을 마련하도록 권고합니다.

파인튜닝과 전이 학습의 관계

파인튜닝은 전이 학습의 한 형태입니다. 이전 학습에서 얻은 능력을 해당 작업에 맞게 조정합니다. 출처를 검색하는 또 다른 기법은 아닙니다. 이 선택에서 중요한 질문은 애초에 모델이 학습한 응답 방식을 바꿀 필요가 있는지입니다.

구축에 앞서 지원되는 모델부터 확인합니다

관리형 파인튜닝 프로젝트를 준비하기 전에 모델 지원 여부와 계정의 이용 자격을 함께 확인해야 합니다. 오래된 튜토리얼에 모델 이름이 나온다는 사실만으로는 부족합니다.

OpenAI의 셀프서비스 파인튜닝 플랫폼은 2026년 5월 7일부터 이용 이력이 없는 조직의 신규 이용을 중단했습니다. 2026년 7월 2일부터는 직전 60일 동안 파인튜닝 모델을 실행하지 않은 조직도 학습 작업을 생성할 수 없게 됐습니다. 현재 공지에 따르면 계속 이용 중인 기존 고객도 2027년 1월 6일부터 새 학습 작업을 생성할 수 없습니다. 기존 파인튜닝 모델의 추론은 기반 모델의 지원이 종료될 때까지만 제공됩니다. 따라서 새로운 사내 프로젝트의 기본 경로로 삼기는 어렵습니다. OpenAI 지원 종료 공지.

Google Gemini 3.1 Flash-Lite는 현재 Google Cloud 문서에서 지도 파인튜닝 지원을 명시한 후보입니다. 지도 파인튜닝은 라벨이 있는 예시로 학습하는 방식입니다. Google의 현재 문서상 플랫폼 명칭은 Gemini Enterprise Agent Platform이며, 기존 Vertex AI 튜닝 문서도 이곳으로 연결됩니다. 아래에서는 이 모델로 구체적인 예산을 계산합니다. 해당 작업에서 가장 좋은 성능을 낸다는 뜻은 아닙니다. 튜닝 지원 모델.

배포 제약도 중요합니다. 이 모델의 튜닝은 us-central1 또는 europe-west4에서 실행되지만, 튜닝된 모델의 서빙은 us 또는 eu 멀티 리전 엔드포인트를 사용합니다. 더 저렴한 기반 모델의 글로벌 요금을 그대로 적용하지 말고, 실제 사용할 엔드포인트 요금으로 예산을 잡아야 합니다. Google은 지도 파인튜닝을 서비스 수준 보장 대상에서도 제외합니다. 튜닝 제한 사항.

예시의 요금 기준: 글로벌 외 엔드포인트의 표준 텍스트 추론 요금은 백만 토큰당 입력 $0.275, 캐시된 입력 $0.0275, 출력 $1.65입니다. 튜닝은 반복 에포크를 포함해 학습 토큰 백만 개당 $3이며, 튜닝된 모델의 추론 요금은 기반 모델의 1.5배인 입력 $0.4125, 출력 $2.475입니다. 이는 Google Cloud 정가이며, Gemini 앱 구독 요금이 아닙니다. Google 요금표.

에포크는 학습 데이터셋 전체를 한 차례 학습하는 단위입니다. 모든 예시는 항목당 모델을 한 번 호출하며, 과금 대상 출력 토큰에 추론 토큰도 포함된다고 가정합니다. 세금, 개발, 라벨링, 평가용 호출, 재시도, 원본 문서 저장, 문서 스캔, 추가 검색 서비스 비용은 제외했습니다. 이 항목들은 별도로 예산을 잡아야 합니다. 학습 청구서는 구축 견적서가 아닙니다.

3가지 업무 사례로 보는 구축 방식과 비용

사내 문서 기반 고객지원: RAG부터 시작합니다

소프트웨어 회사의 고객지원 어시스턴트에는 학습보다 최신 근거가 먼저 필요합니다. 고객이 해지 효력이 즉시 발생하는지 묻는다면 현재 정책과 해당 계약의 예외 조항에 따라 답해야 합니다.

승인된 문서를 읽고 활용하기 좋은 문단으로 나누는 수집 과정을 구축합니다. 이때 원문 URL, 시행일, 제품, 접근 권한을 보존해야 합니다. 요청이 들어오면 고객이 볼 수 있는 자료로 검색 범위를 제한하고 관련 문단을 가져온 뒤, 모델에 그 근거를 인용해 답하도록 지시합니다. 바뀐 문단은 교체하고 삭제된 문단은 제거해야 합니다. 원본이 바뀌었다고 인덱스가 즉시 갱신되는 것은 아닙니다.

OpenAI text-embedding-3-small은 텍스트를 유사도 검색에 사용하는 수치 표현으로 변환합니다. 요금은 입력 토큰 백만 개당 $0.02이며, 기본 출력은 1,536차원입니다. 문서를 임베딩하면 검색할 수 있게 될 뿐, 답변을 작성하는 모델이 학습되는 것은 아닙니다. 모델 요금, 임베딩 차원.

이 예시에서 Cloudflare Vectorize는 수치 표현을 저장하고 유사한 표현을 찾는 벡터 데이터베이스입니다. 한계는 근거의 품질에 있습니다. 유사도가 높은 문단도 오래됐거나 질문과 무관할 수 있습니다. 접근 권한을 적용하고 선택된 문장이 답변을 뒷받침하는지 확인하는 책임은 애플리케이션에 있습니다.

초기 구축 비용: 청킹한 뒤 평균 500토큰인 문단 10,000개가 있다고 가정합니다. 최초 임베딩 비용은 500만 토큰 × $0.02 = $0.10입니다. 여기에는 파싱과 앞서 설명한 개발 작업이 포함되지 않습니다.

이 인덱스가 저장하는 차원 수는 1,536만으로, Vectorize의 무료 제공량인 500만을 넘습니다. 유료 플랜에는 저장 차원 1,000만과 월 쿼리 차원 5,000만이 포함됩니다. 초과 요금은 저장 차원 1억 개당 $0.05, 쿼리 차원 백만 개당 $0.01입니다. Cloudflare가 공개한 산식에 따르면 이 인덱스에 월 10,000회 쿼리를 실행할 때 쿼리 차원 수는 3,072만으로, 포함 제공량 이내입니다. 저장 초과 요금은 월 $0.00268입니다. 계정 내 다른 곳에서 제공량을 사용하지 않았다고 가정합니다. Vectorize 요금.

월 구성 요소별 예산: 문단 1,000개를 교체하고 평균 100토큰인 질문 10,000개를 임베딩하는 데 $0.03이 듭니다. 답변당 총 입력 2,500토큰, 출력 400토큰으로 답변 10,000개를 생성하면 $13.475입니다. 여기에 Workers Paid 계정 최소 요금 $5와 저장 초과 요금을 더하면 약 월 $18.51이며, 최초 임베딩 비용은 별도입니다. Worker 실행량은 포함 제공량 이내라고 가정합니다. Workers 요금.

운영 검증에서는 답변이 현재 유효한 정책을 적용하는지, 답변을 뒷받침하는 문단을 인용하는지, 없는 예외를 지어내지 않는지 확인해야 합니다. 삭제된 문서와 다른 고객의 계약에 접근하려는 시도도 테스트해야 합니다. 정확한 근거를 줘도 응답 방식의 문제가 반복될 때만 나중에 파인튜닝을 검토합니다.

브랜드 문체 맞추기: 학습 전에 예시와 캐싱을 시험합니다

편집 방향이 확고하다면 파인튜닝을 검토할 만하지만, 브랜드의 말투를 아직 논의 중이라면 이릅니다. 과장된 주장을 피하고 핵심을 바로 전달하며, 구체적인 다음 행동으로 마무리하는 제품 안내 이메일을 작성하는 회사를 생각해 보겠습니다.

먼저 프롬프트에 스타일 가이드와 승인된 예시를 넣습니다. 그런데도 세밀한 편집 기준을 반복해서 놓친다면 학습 쌍을 만듭니다. 원래 작성 요청과 사실 정보를 입력으로, 편집자가 승인한 초안을 출력으로 구성합니다. 완성된 이메일만 모은 아카이브로는 어떤 입력에 어떤 응답을 내야 하는지 알 수 없습니다.

예를 들어 토요일 고객지원 개시를 알리는 작성 요청의 승인된 목표 문장은 다음과 같을 수 있습니다. “이제 토요일에도 고객지원을 이용할 수 있습니다. 도움이 필요하면 채팅을 열어 주세요.” 목표 문장은 원하는 문체를 보여 주고, 작성 요청은 사실을 제공합니다.

문체와 사실 정보는 분리합니다. 짧게 시작하는 방식을 학습시키되, 이번 주 제품 정보는 요청 시점에 제공합니다. 학습에 사용하지 않은 작성 요청을 평가용으로 남겨 두고, 편집자에게 근거 없는 주장, 어조, 필수 내용, 수정이 필요한 정도를 판단하도록 합니다. 텍스트 유사도 점수가 높다는 이유로 브랜드에 맞는 좋은 글이라고 단정해서는 안 됩니다.

초기 구축 비용: 총 토큰 수가 평균 1,600개인 학습 쌍 1,000개 × 3에포크 = 학습 토큰 480만 개이며, 한 번의 학습 작업에 $14.40이 듭니다. 이는 예산 계산을 위한 가정입니다. 이 데이터셋 크기나 에포크 수를 평가 통과에 충분한 설정으로 권하는 것은 아닙니다.

월 모델 사용료: 각각 입력 1,200토큰, 출력 400토큰인 초안 10,000개를 튜닝된 모델로 만들면 $14.85입니다. 동일한 기반 모델에서 요청마다 문체 지침과 예시 4,800토큰을 추가하면 캐시 적중이 없을 때 $23.10입니다. 캐시가 안정적으로 작동해 반복 접두부가 매번 암시적 캐시에 적중한다고 가정하면, 이 프롬프트 기반 구성의 비용은 $11.22까지 내려갑니다. 캐시 미스와 워밍업 비용은 별도입니다. 계산에는 앞서 제시한 Google 요금을 적용했습니다.

이렇게 되면 비용 측면의 결론이 뒤집힙니다. 파인튜닝이 편집 수정량을 줄여 도입 가치를 입증할 수는 있습니다. 하지만 긴 스타일 프롬프트 비용을 반복해서 내지 않는 방법 중 언제나 더 저렴한 것은 아닙니다. 학습 파이프라인을 도입하기 전에 실제 캐시 사용량과 편집자의 승인율을 측정해야 합니다.

문의 티켓 분류: 안정된 판단 기준은 학습하고, 바뀌는 규칙은 검색합니다

라벨이 안정돼 있고 반복되는 오류를 측정할 수 있다면 문의 티켓 분류기는 파인튜닝에 적합한 후보입니다. 허용 라벨이 billing, access, bug, review라고 가정해 보겠습니다.

“청구서를 열 수 없습니다”라는 메시지가 어려운 지점을 보여 줍니다. 청구 관련 단어가 들어 있지만 실제 담당 큐는 접근 문제를 처리하는 곳일 수 있습니다. 고객지원 책임자들과 그 경계를 합의한 다음, 모호한 사례까지 포함해 대표적인 메시지에 라벨을 붙입니다. 학습 데이터와 평가 데이터를 나눌 때 같은 대화에 속한 메시지는 함께 묶어야 합니다. 이후에 접수된 티켓도 포함해 표현이나 제품의 변화가 드러나게 해야 합니다.

출력은 허용된 라벨이어야 하지만 형식이 맞는 것만으로 성공은 아닙니다. 긴급 건 누락, 잘못된 큐 배정, 불필요한 검토, 이후 재배정 업무의 부담을 각각 측정해야 합니다. 모델이 스스로 내놓는 확신의 표현을 보정된 라우팅 임계값으로 삼아서는 안 됩니다.

초기 구축 비용: 총 토큰 수가 평균 300개인 라벨링 예시 5,000개 × 3에포크 = 학습 토큰 450만 개이며, 한 번의 학습 작업에 $13.50이 듭니다. 월 모델 사용료: 건당 입력 250토큰, 과금 대상 출력 20토큰인 티켓 100,000개를 처리하면 튜닝된 모델에서는 약 $15.26, 동일한 짧은 프롬프트를 쓰는 기반 모델에서는 $10.18입니다. 튜닝된 모델은 더 나은 판단으로 이 추가 비용을 정당화해야 합니다. Google 요금표.

애플리케이션 코드로 잘못된 라벨을 거부하고 모호한 사례는 검토 대상으로 보내야 합니다. Google의 튜닝 문서는 추론 시 출력을 스키마로 제한하는 제어 생성 기능을 추가하면 학습 때와 불일치가 생길 수 있다고 경고합니다. 따라서 실제 배포할 조합 그대로 평가해야 합니다. 알려진 튜닝 문제.

큐의 담당 범위가 자주 바뀐다면 현재 라우팅 정책을 모델 가중치 밖에서 관리합니다. 검색해서 가져오거나 프롬프트로 제공하면 됩니다. 라벨의 경계 자체가 계속 바뀐다면 운영 기준이 학습시킬 만큼 안정될 때까지 파인튜닝을 미룹니다.

2026년, 긴 컨텍스트와 프롬프트 캐싱은 무엇을 바꿀까요?

문서 모음이 작고 거의 바뀌지 않는다면 검색 서비스를 만들기 전에 문서 전체를 직접 전달하는 방식을 검토할 만합니다. 긴 컨텍스트와 캐싱이 2026년에 처음 등장한 기술은 아닙니다. 다만 이제는 다른 설계와 비교할 기본 구성에 이 기능들을 고려해야 합니다.

컨텍스트 윈도는 모델이 한 요청에서 다룰 수 있는 자료의 양입니다. 2026년 5월 7일 출시된 Gemini 3.1 Flash-Lite는 1,048,576토큰의 컨텍스트 윈도를 제공합니다. 이는 용량을 뜻할 뿐, 방대한 업무 매뉴얼의 모든 예외를 정확하게 적용한다는 보장은 아닙니다. 지시, 질문, 생성에 필요한 공간을 남겨 두고 까다로운 문단으로 테스트해야 합니다. 모델 사양.

RAG와 CAG의 차이

캐시 증강 생성, 즉 CAG는 질문마다 문서를 검색하는 대신 지식을 미리 넣고 캐시된 컨텍스트를 재사용하는 방식입니다. 관련 자료가 컨텍스트에 들어갈 만큼 작고, 변경이 드물며, 자료를 받는 모든 사용자에게 동일한 접근 권한이 있을 때 유용합니다. 프롬프트 캐싱은 반복 입력의 처리 결과를 재사용할 뿐, 그 사실을 모델 가중치에 넣거나 답변의 최신성을 보장하지 않습니다.

80,000토큰의 업무 매뉴얼을 10,000회 요청에서 재사용한다고 가정하면, 매뉴얼 입력 부분의 비용만 캐싱 없이 $220, 모든 요청이 캐시에 적중하는 요율로는 $22입니다. 새 질문, 출력, 캐시 미스, 캐시 생성에는 여전히 비용이 듭니다. 이 매뉴얼을 명시적 캐시로 720시간 보관하면 공개 요율인 백만 토큰·시간당 $1에 따라 저장 비용 $57.60이 추가됩니다. Google 캐시 요금.

암시적 캐싱에는 저장 요금이 없지만 적중이 보장되지는 않습니다. 공통 자료를 앞에 배치하고 접두부를 일정하게 유지하며, 응답의 cachedContentTokenCount를 확인해야 합니다. 이 모델은 캐시 대상 컨텍스트가 최소 4,096토큰이어야 하므로, 짧은 티켓 분류 프롬프트에 캐시 요금을 적용해 예산을 잡아서는 안 됩니다. 캐싱 문서.

선택 기준은 실무 요구사항입니다. 범위가 한정돼 있고 전체를 한꺼번에 갱신하고 접근 권한을 부여할 수 있는 매뉴얼이라면 긴 컨텍스트에 직접 넣습니다. 사내 자료가 더 크거나 일부씩 바뀌거나 문서마다 접근 권한이 다르다면 검색을 사용합니다. 효과가 있다면 RAG 시스템 안에서도 공통 지시 접두부를 캐시할 수 있습니다. 이 방식들은 함께 사용할 수 있습니다.

모든 캐시 기능을 파인튜닝 모델에도 그대로 적용할 수 있다고 가정해서는 안 됩니다. Google의 현재 튜닝된 모델의 캐싱 문서에 따르면 파인튜닝 모델은 명시적 캐싱을 지원하지 않으며, 암시적 캐싱 지원은 모델 버전에 따라 다릅니다.

사실은 계속 바뀌고 응답 문제도 남는다면 함께 사용합니다

검색과 파인튜닝이 각각 별도로 확인된 문제를 해결할 때 두 방식을 결합합니다. 고객지원 어시스턴트가 최신 해지 조항을 검색하고, 튜닝된 모델은 회사가 원하는 구조에 맞춰 답할 수 있습니다. 답변과 근거를 제시한 다음, 허용된 후속 조치를 안내하거나 상위 담당자에게 넘기는 방식입니다.

학습 예시는 모델이 실제 운영에서 받을 근거 자료와 비슷하게 구성해야 합니다. 누락되거나 무관하거나 서로 충돌하는 문단도 포함해, 추가 설명을 요청하거나 답변을 지어내지 않는 행동까지 익히도록 합니다. 실행 시에는 여전히 제한된 자료가 모델에 전달되기 전에 접근 권한을 확인해야 합니다.

검색과 응답 방식은 별도로 평가해야 합니다. 정확한 인용, 접근 권한의 경계, 출처 갱신은 여전히 애플리케이션의 책임입니다. 파인튜닝 모델이 이를 대신 강제해 주지는 않습니다.

근거를 찾으려면 후속 검색이 필요한 경우, 에이전틱 RAG 가이드에서 범위를 제한한 검색 루프가 추가 복잡성을 감수할 만한 때를 설명합니다. 안정적으로 반복되는 응답 문제 때문에 학습이 필요해졌다면 LLM 파인튜닝 방법에서 데이터셋 준비, 체크포인트, 평가를 다룹니다.

어떤 기대가 과장돼 있을까요?

“RAG가 언제나 낫다”거나 “파인튜닝을 하면 모델이 우리 회사를 알게 된다”는 말로는 제대로 된 구축 명세를 만들 수 없습니다. 검색은 오래된 출처, 부적절한 문단 선택, 부족한 맥락 때문에 실패할 수 있습니다. 파인튜닝은 서로 모순된 예시를 학습해 오래된 규칙을 오히려 더 일관되게 재현할 수 있습니다.

저렴한 학습 연산 비용의 가치도 과대평가하기 쉽습니다. 청구서에는 좋은 결과의 기준을 정하고, 라벨에 대한 이견을 조율하고, 테스트셋의 유효성을 유지하는 노력이 포함되지 않습니다. 더 큰 컨텍스트 윈도는 용량 제약을 줄여 줄 뿐, 제공된 모든 사실을 올바르게 추론한다는 근거가 되지 않습니다.

요구해야 할 입증의 범위는 더 구체적입니다. 학습에 쓰지 않고 남겨 둔 실제 업무 사례에서 해당 구성 요소가 다른 요구사항을 지키면서 명확히 규정한 실패를 해결하는지 확인해야 합니다. 기존 프롬프트가 이미 통과한다면 시스템을 그대로 유지합니다.

RAG와 파인튜닝, 언제 도입해야 할까요?

빠진 근거는 바로 보완하되, 학습은 응답 문제를 구체적으로 규정하고 측정할 수 있을 때까지 기다립니다. 정책이 계속 바뀌는 조직의 운영자는 출처 관리 책임과 갱신 절차부터 정비해야 합니다. 승인된 예시가 확립돼 있는데도 반복해서 글을 고치는 편집팀은 프롬프팅과 파인튜닝을 비교해야 합니다. 라벨이 바뀌는 분류기는 기다리는 편이 낫습니다. 새로운 최적화 기법이 있다는 이유만으로 잘 작동하는 프롬프트 기반 워크플로를 바꿀 필요는 없습니다.

월요일에는 다음 순서로 시작해 보십시오.

1. 1

   시스템을 바꾸기 전에 실패 사례를 모읍니다

   대표적인 고객지원 질문, 작성 요청, 문의 티켓을 고릅니다. 승인된 답변이나 판단을 기록하고, 이 평가 사례들은 학습 데이터에서 제외합니다.

2. 2

   빠진 근거를 직접 제공합니다

   정확한 문단과 명확한 지시를 넣고 작업을 다시 수행합니다. 남은 오류가 지식 부족, 불분명한 규칙, 잘못된 응답 방식, 모델이 아직 처리하지 못하는 작업 중 어디에 해당하는지 구분합니다.

3. 3

   가장 작은 후보 구성부터 비용을 계산합니다

   현재 프롬프트, 캐시나 긴 컨텍스트를 활용한 프롬프트, 검색을 차례로 비교한 뒤, 필요한 경우에만 지원되는 파인튜닝 방식을 검토합니다. 실제 과금 토큰, 캐시 적중, 재시도, 사람의 수정 작업까지 계산합니다.

4. 4

   작업의 통과 기준에 맞춰 배포합니다

   기준을 충족하는 가장 단순한 설계를 선택합니다. 문서 갱신이나 학습 예시 검토 담당자를 지정하고, 배포 버전을 기록하며, 이전 상태로 되돌릴 경로를 유지합니다.

자주 묻는 질문

AI 파인튜닝이란 무엇인가요?

파인튜닝은 추가 학습 예시를 사용해 사전 학습된 모델을 조정하는 작업입니다. 사내 업무에서는 일정한 응답 문체나 작업 수행 방식을 반복해서 구현하는 데 주로 활용할 수 있습니다.

모델을 파인튜닝하는 데 비용이 얼마나 드나요?

글쓰기 사례에서 제시한 토큰 수와 에포크 수를 가정하면 Google 학습 작업 한 번에 $14.40이 듭니다. 라벨링, 평가, 서빙, 개발 비용은 별도이며, 실험에 실패하면 추가 학습 작업 비용도 발생합니다.

RAG보다 나은 방법이 있나요?

필요한 근거가 이미 모두 들어 있다면 프롬프트를 직접 사용하는 편이 더 단순할 수 있습니다. 일정하게 반복되는 응답 방식의 문제에는 파인튜닝이 도움이 될 수 있습니다. 하지만 최신 정보 중 접근이 허용된 사실을 찾아야 하는 시스템에서는 어느 쪽도 검색을 대체하지 못합니다.

파인튜닝 모델과 RAG 기반 접근 방식의 핵심 차이는 무엇인가요?

파인튜닝은 학습을 통해 모델의 파라미터를 바꿉니다. RAG는 요청 시점에 제공하는 근거를 바꿉니다. 출처 인덱스를 갱신하는 일, 모델을 재학습하는 일, 답변의 인용이 유효한지 입증하는 일은 서로 다른 작업입니다.

파인튜닝은 효과가 없다고 판명됐나요?

머신러닝 모델을 조정하는 의미라면 그렇지 않습니다. 가치는 작업에 따라 달라지며, 학습에서 제외한 예시로 프롬프트 기반 구성과 비교해 입증해야 합니다.

ChatGPT는 어떻게 파인튜닝됐나요?

2022년 OpenAI의 최초 ChatGPT 발표에서는 대화 예시를 활용한 지도 학습에 이어 인간 피드백을 통한 강화 학습을 적용했다고 설명했습니다. 이 과거의 학습 과정은 오늘날 기업이 API 파인튜닝을 이용할 수 있는 자격과는 별개입니다.

Stephen Hawking은 미세 조정에 대해 뭐라고 했나요?

이는 우주론의 미세 조정에 관한 질문으로, 여기서 다루는 파인튜닝과는 다른 의미입니다. 언어 모델을 조정하는 것과는 관련이 없습니다. 이 글의 업무상 선택은 검색과 학습에 관한 것이며, 우주에 관한 주장이 아닙니다.

파인튜닝은 지금도 사용하나요?

그렇습니다. Google의 현재 문서에는 이 글에서 사용한 Gemini 모델을 포함한 지원 모델이 나와 있습니다. 제공업체의 지원 여부는 바뀌므로 학습 작업을 준비하기 전에 해당 모델과 계정의 이용 자격을 확인해야 합니다.

파인튜닝에는 어떤 모델이 가장 좋나요?

핵심 작업을 이미 수행할 수 있고 배포 제약도 충족하는, 지원 대상 기반 모델을 선택합니다. 이 글의 Gemini 3.1 Flash-Lite는 비용을 계산하기 위한 예시이지, 모든 작업에서 최고라고 검증된 모델은 아닙니다. 학습에서 제외한 평가 사례로 판단해야 합니다.

AI로 제품과 시스템을 구축할 때 필요한 실무 판단을 더 받아 보려면 뉴스레터를 구독하세요.