Fine-tuning·RAG·Prompt 중 뭘 먼저 해야 하나

이 글은 「AI 공부 지도 20부작」의 10편(B3) 입니다.
앞 편: B2 — Embedding이 뭐길래 RAG의 심장이라고 부르나
다음 편: M1 — Retrieval Layer: 회사 문서를 AI가 찾아 읽게 만드는 층

0. 들어가기 전에

여기까지 오셨으면 F1~F6 기초 여섯 편과 B1, B2 두 편을 지나온 분들일 거예요. LLM이 그럴듯함을 만드는 기계라는 감각, Attention의 Q·K·V, embedding이 고차원 공간의 좌표라는 감각까지. 그 감각 위에 오늘 편을 얹습니다.

이번 편은 질문 하나로 끝납니다.

“우리 회사에 AI를 붙이려고 하는데, fine-tuning을 해야 하나요, RAG를 만들어야 하나요, 아니면 프롬프트만 잘 쓰면 되나요?”

실무자 자리에서 10번 중 9번은 이 질문을 받아요. 그리고 제가 지켜본 바로는, 이 질문에 바로 답할 수 있는 사람이 생각보다 적습니다. 왜냐하면 세 가지가 전혀 다른 층위에 있는 도구인데도, 마케팅 자료에서는 다 비슷비슷하게 “AI 맞춤화” 라는 이름으로 묶여 팔리거든요.

오늘은 이 셋을 한 줄로 정의하고, 언제 뭘 골라야 할지 5가지 질문으로 갈라놓고, 비용 감각까지 잡아볼게요. 읽고 나면 회사 회의에서 “우리는 지금 단계에서 RAG부터” 라고 말할 수 있게 될 겁니다.

1. 실무에서 가장 많이 받는 질문 — “우리 회사 데이터로 AI 써야 하는데 뭐부터?”

지난 달에 한 중소 법인 대표분과 이야기를 나눴어요. 이 회사는 내부 규정 문서가 수백 페이지쯤 있고, 직원 50명 정도고, 개발자는 두 명이에요. 대표분이 이렇게 물었어요.

“우리 규정을 전부 학습시킨 AI를 만들고 싶어요. Fine-tuning이라고 하던데, 얼마나 들어요? 1억이면 돼요?”

저는 세 가지를 되묻고 싶었어요. 규정이 자주 바뀌나요. 답변 말투가 고정되어 있어야 하나요. 개발자 둘이서 GPU 인프라를 관리할 수 있나요.

대답은 이랬습니다. “규정은 분기마다 조금씩 바뀌어요. 답변 말투는 그냥 친절하면 돼요. GPU는 뭐가 뭔지 모르겠어요.”

그럼 fine-tuning은 답이 아닙니다. RAG가 맞고, 실제로는 RAG도 당장 필요 없고 Prompt만 잘 써도 70%는 해결되는 상황이에요. 그런데 대표분은 “AI 붙인다 = fine-tuning 한다” 라고 생각하고 계셨던 거죠.

이 오해가 전국적으로 퍼져 있습니다. 그래서 세 도구를 한 줄로 정리하는 데서 시작할게요.

2. 세 가지 도구의 한 줄 정의 — 요리사에게 레시피를 알려주는 3가지 방법

LLM을 요리사 한 명이라고 해봅시다. 이 요리사는 이미 세계 요리 대부분을 만들 줄 알아요. 그런데 지금 당신이 원하는 건 “이 집에서만 쓰는 특제 김치찌개” 예요. 어떻게 가르칠까요. 방법이 딱 셋 있습니다.

방법 1: 요리하면서 옆에서 레시피 읽어주기.
주문 들어올 때마다 당신이 레시피를 불러줍니다. “돼지고기 150g, 묵은지 한 컵, 두부는 세 번째 순서로.” 요리사는 듣고 만듭니다. 다음 주문이 오면? 또 불러줘야 해요. 매번.
→ 이게 Prompt입니다. 쓸 때마다 정보를 끌고 들어가는 방식.

방법 2: 부엌에 요리책을 비치해 두기.
부엌 한쪽에 회사 레시피북 을 꽂아둡니다. 요리사는 필요할 때 “특제 김치찌개” 항목을 펼쳐서 읽고, 그대로 만들어요. 당신이 매번 읽어줄 필요가 없고, 요리책만 업데이트하면 내일부터 새 레시피가 적용돼요.
→ 이게 RAG(Retrieval-Augmented Generation) 입니다. 필요할 때 외부에서 가져와서 프롬프트에 얹는 방식.

방법 3: 요리사를 한국요리 전문가로 다시 교육시키기.
반년 동안 한국 요리 학교에 보냅니다. 수백 개 레시피를 몸에 배게 해요. 돌아온 요리사는 레시피북을 보지 않아도 자동으로 한국식 간을 잡고, 한국식 플레이팅을 합니다. 대신 교육비가 들고, 한번 졸업하면 새 레시피를 추가하려면 또 교육을 보내야 해요.
→ 이게 Fine-tuning입니다. 모델 자체의 가중치를 업데이트해서 지식·말투·포맷을 몸에 배게 하는 방식.

정리하면 이렇습니다.

방식	정보가 어디 있나	언제 주입되나	지속성
Prompt	프롬프트 안 (임시 텍스트)	호출할 때마다	한 번 쓰고 증발
RAG	외부 벡터 DB	호출 시점에 검색해서 붙임	검색 결과만큼 유지
Fine-tuning	모델 가중치 (영구)	학습 시점에 한 번	다음 학습 전까지 영구

이 표 하나만 머리에 넣어도 오늘 글의 절반은 끝난 거예요. 나머지 절반은 “언제 뭘 쓰느냐” 입니다.

3. Prompt — 제일 빠르고 제일 싸다, 대신 휘발된다

Prompt는 요리사 옆에서 매번 레시피를 불러주는 방식이라고 했죠. 이게 제일 단순합니다. 구현이 제일 쉽고, 돈도 제일 적게 들어요.

장점

• 즉시 시작 가능. 오늘 오후에 시작해서 오늘 저녁에 MVP를 만들 수 있어요. 개발자 한 명만 있어도 돼요.
• 비용이 낮음. API 호출 한 번당 토큰 비용만 냅니다. 평균적으로 한 호출에 $0.001~0.05 사이. 하루에 1,000번 호출해도 월 수만 원 수준.
• 실험이 자유로움. 프롬프트만 바꿔 가면서 A/B 테스트가 됩니다. “이번엔 이 말투, 다음엔 저 말투.” 배포가 필요 없어요.
• 투명성. 모델이 왜 그렇게 답했는지 프롬프트를 보면 거의 다 보입니다.

단점

• 휘발된다. 대화가 끝나면 싹 사라져요. 다음 호출은 백지에서 시작. 회사 규정 300페이지를 매번 프롬프트에 우겨넣을 수는 없습니다.
• 컨텍스트 창 한계. Claude 3.5 Sonnet이나 GPT-4 Turbo 기준으로 수만에서 20만 토큰 정도가 한계예요. 회사 문서 전체가 들어가기 어려운 규모가 많습니다.
• 토큰 비용이 호출량과 비례. 호출이 많아지면 “매번 같은 긴 지시문을 보내는 낭비” 가 누적돼요. prompt caching으로 완화되긴 하지만 근본 해결은 아닙니다.
• 민감한 데이터를 매번 외부 API로 보낸다. 프롬프트 안에 사내 정보를 붙여서 호출한다는 건, 그 정보가 매번 OpenAI/Anthropic 서버를 다녀온다는 뜻이에요. 계약서 클로즈와 데이터 처리 위치를 반드시 확인해야 합니다.
• 일관성 없음. 같은 프롬프트를 써도 모델은 매번 조금씩 다른 답을 해요. Temperature를 0으로 낮춰도 완전히 같진 않습니다.

현실 사용처

• MVP 단계 대부분. 챗봇, 요약기, 분류기 초기 버전.
• 규모가 작은 지식 참조. 규정이 A4 10~20장쯤으로 끝나는 경우.
• 하루 호출량이 수백 번 이하. 비용이 의미 있는 병목이 되기 전.
• 프로토타이핑. “AI 붙이면 되나?” 를 확인하는 단계.

제가 매번 드리는 조언은 이거예요. “Prompt로 먼저 해보세요. 안 되면 그때 다음 단계.” 아무도 이 조언을 좋아하지 않지만 실제로 맞아요.

4. RAG — 회사 문서 수천 개를 AI에게 “언제든 꺼낼 수 있는 상태”로

B2에서 embedding을 다뤘죠. 문장을 1,536차원쯤 되는 벡터로 바꿔서 “비슷한 의미끼리 뭉치게” 만드는 기술. 이 embedding이 RAG의 심장입니다.

RAG의 흐름을 한 번 훑을게요.

1. 인덱싱(사전 작업). 회사 문서 수천 개를 각각 작은 청크(보통 500~1,000자)로 자릅니다. 각 청크를 embedding으로 바꿔서 벡터 DB(Pinecone, Weaviate, pgvector 등)에 저장해요. 이건 한 번만 해두면 돼요.
2. 질의(매 호출마다). 유저가 “지난 달 광고비 규정 어떻게 돼?” 라고 물으면, 이 질문도 embedding으로 바꿔요.
3. 검색. 질문 embedding과 가장 가까운 청크 상위 5~10개를 벡터 DB에서 뽑아요. 코사인 유사도 기준.
4. 프롬프트 조립. 뽑은 청크들을 프롬프트 맨 위에 붙여넣고, 그 아래에 원래 질문을 얹어요. “다음 문서들을 참고해서 답해주세요. [청크 1] [청크 2]… 질문: 지난 달 광고비 규정 어떻게 돼?”
5. LLM 호출. 이렇게 조립된 프롬프트를 LLM에 보냅니다. 모델은 청크를 참고해서 답해요.

이 흐름을 부엌 비유로 바꾸면, 요리사가 “특제 김치찌개” 주문을 받으면 요리책 목차에서 “김치찌개” 를 찾아 해당 페이지를 펼치고, 그 페이지를 보면서 요리하는 거예요. 당신은 요리책만 관리하면 되고, 요리사는 책을 보고 조리합니다.

장점

• 최신성. 요리책(문서)을 오늘 수정하면 내일부터 반영돼요. Fine-tuning처럼 재학습이 필요 없습니다.
• 대량 문서 처리. 수만 페이지도 벡터 DB에 들어가요. Prompt처럼 한 호출에 다 넣을 필요가 없으니까.
• 근거 추적. 어떤 청크가 답변에 사용됐는지 로그에 남길 수 있어요. “이 답변은 규정집 17페이지 참조” 같은 인용이 가능합니다.
• 민감 데이터 관리 가능. 벡터 DB를 온프레미스나 VPC 안에 둘 수 있어요. 원본 문서가 외부로 유출될 위험을 줄일 수 있습니다(다만 LLM에 청크를 보낼 때는 외부로 나가니까, 이것도 사내 LLM을 쓰거나 BAA 계약을 확인해야 해요).

단점

• 검색 품질이 전부. 청크 쪼개는 방식, embedding 모델 선택, 검색 개수 설정에 따라 답변 품질이 극단적으로 갈려요. 엔지니어링 품이 많이 듭니다.
• 인프라 필요. 벡터 DB, 인덱싱 파이프라인, 문서 업데이트 트리거, 평가 루프. 혼자 돌리기 빡센 스택이에요.
• 초기 셋업 비용. 문서 500개 벡터화하는 건 싸지만, 운영 중인 RAG 시스템을 안정적으로 유지하는 건 다른 이야기입니다. 최소 $500부터 시작해서, 본격 운영은 수천 달러~수만 달러 수준.
• 지연(latency). 검색 한 번 더 하니까 prompt만 보낼 때보다 한 박자 늦어요. 보통 0.3~1초 추가.

현실 사용처

• 사내 지식 챗봇. FAQ, 내부 위키, 규정집, 매뉴얼.
• 고객 지원 자동 응답. 제품 매뉴얼·약관 기반 답변.
• 리서치 어시스턴트. 논문, 법률 문서, 뉴스 아카이브.
• 코드 검색 기반 IDE 어시스턴트. Cursor 같은 도구가 코드베이스를 인덱싱해서 RAG로 답하는 구조.

포인트는 이거예요. “정보가 자주 바뀌고, 원본 추적이 필요하면 RAG.” 이 조건에 걸리면 fine-tuning이 아니라 RAG입니다.

5. Fine-tuning — 모델의 말투·도메인·포맷을 “몸에 배게”

Fine-tuning은 가장 무겁고, 가장 많이 오해받는 도구예요. F6에서 다룬 gradient descent를 떠올려 주세요. 모델은 수많은 파라미터(가중치)를 가지고 있고, 이 숫자들이 입력을 출력으로 변환하는 회로를 이뤄요. Fine-tuning은 이 가중치를 당신이 준 데이터로 한 번 더 업데이트 하는 작업이에요.

기술적으로는 두 종류가 있어요.

• Full fine-tuning: 모든 파라미터를 업데이트. 가장 효과 강하지만 비용·시간이 크고, 모델 크기만큼의 저장 공간이 필요.
• PEFT/LoRA 등: 원래 가중치는 얼려두고, 작은 adapter 층만 학습. 훨씬 싸고 빠르고 저장 공간도 수십 MB 수준. 2026년 기준 실무에서 돌리는 fine-tuning은 대부분 이 계열이에요.

요리사 비유에서, 이건 요리사를 학교에 보내는 일이에요. 학교에서 수천 개 예시를 반복해서 본 결과, 요리사의 손맛이 바뀌어요. 학교를 졸업하고 온 요리사는 특별한 지시가 없어도 자연스럽게 “우리 집 스타일” 로 요리합니다.

장점

• 일관된 출력. 말투·포맷·길이·톤이 학습 데이터를 따라가요. “항상 3문장 이내로, 존댓말로, 기술 용어는 풀어서 설명” 같은 규칙이 프롬프트에 안 써도 자동으로 나옵니다.
• 토큰 비용 절감. 긴 시스템 프롬프트가 필요 없어지니까 호출당 입력 토큰이 줄어요. 호출량이 많을수록 이 절약이 커집니다.
• 도메인 지식 내재화. 법률·의료·금융 같이 용어가 까다로운 도메인에서, 도메인 말투를 몸에 배게 할 수 있어요. 정확한 용어 선택, 문체, 구조까지.
• 지연 단축. 프롬프트가 짧아지니까 응답이 빨라져요. 같은 모델이라면 fine-tuned 버전이 미세하게 빠릅니다.

단점

• 고비용. OpenAI의 GPT-4 계열 fine-tuning은 학습 비용만 $100~수천 달러. 본격 규모는 수십만 달러 갈 수 있어요. 자체 호스팅 오픈소스 모델이면 GPU 시간·스토리지·엔지니어 인건비까지 포함.
• 업데이트 어려움. 새 지식을 추가하려면 재학습이 필요해요. RAG처럼 문서만 수정하면 끝나는 게 아니에요. 이게 결정적입니다.
• 데이터 품질 의존. 쓰레기를 넣으면 쓰레기가 나와요. 수백~수천 쌍의 고품질 학습 쌍(input·output)을 만드는 것 자체가 큰 프로젝트예요.
• 기밀 데이터 관리. 학습 데이터가 모델 가중치에 “스며들어요.” 이론적으로는 추출 공격으로 원본이 나올 수 있습니다. 민감 데이터로 학습시킬 땐 모델 접근 권한과 출력 필터링을 따로 설계해야 해요.
• 환각은 그대로. 뒤에서 다시 다루겠지만, fine-tuning이 환각을 없애주진 않아요.

현실 사용처

• 말투·포맷 고정. 고객 지원 답변을 회사 브랜드 톤으로 통일.
• 구조화 출력. JSON·XML·특정 마크업으로 정확히 출력.
• 전문 도메인 분류기·요약기. 의료 기록 분류, 법률 문서 요약 같은 고정 작업.
• 호출량이 아주 많을 때. 매일 수십만 회 호출하는 서비스라면, fine-tuning으로 프롬프트를 줄여서 비용 절감 효과가 누적돼요.

한 줄 정리. “말투·포맷·일관성을 얻고 싶고, 지식이 자주 안 바뀌고, 호출량이 충분히 많을 때” fine-tuning이 맞습니다. 그 외엔 거의 다른 답이 있어요.

6. 의사결정 트리 — 어느 걸 고를지 5가지 질문

자, 이제 실제 판단입니다. 다섯 질문을 순서대로 던져 보세요. 각 질문에 답을 적어가면 자연스럽게 방향이 나와요.

Q1. 정보가 자주 바뀌나?

• 매일/매주 바뀐다 → RAG 우선. 재학습 없이 문서만 교체하면 되니까.
• 분기/반기에 한 번 바뀐다 → RAG가 편하긴 한데, 다른 요건에 따라 fine-tuning도 가능.
• 거의 안 바뀐다(고정 커리큘럼, 고정 매뉴얼) → Fine-tuning 후보가 될 수 있음.

회사 규정, 상품 가격, 뉴스 기사, 실시간 재고 같은 건 RAG가 맞습니다. 회사 브랜드 가이드, 오래된 법전처럼 연 단위로만 갱신되는 건 fine-tuning도 가능해요.

Q2. 같은 말투·포맷을 반복해서 원하나?

• 예, 톤/구조/길이가 고정되어야 함 → Fine-tuning 후보.
• 아뇨, 매번 유연하게 다르게 → Prompt나 RAG로 충분.

예를 들어 “모든 답변은 ‘안녕하세요, [회사명] 고객 지원입니다’ 로 시작하고, 3단 구조로, 마지막에 문의 번호” 같은 엄격한 포맷이 필요하면 fine-tuning이 코드 훨씬 깔끔해져요. 프롬프트에 매번 길게 쓰는 것보다.

다만 같은 목적을 prompt caching + 시스템 프롬프트로 해결할 수도 있어요. 규모가 작으면 이쪽이 싸요.

Q3. 예산과 엔지니어링 팀 규모는?

• 개발자 1~2명, 월 예산 수십만 원 → Prompt 우선. RAG는 무리.
• 개발자 3~5명, 월 예산 수백만 원 → RAG 가능. 벡터 DB 운영 역량 있으면.
• 개발자 5명 이상 + ML 엔지니어, 연 예산 수천만 원~억대 → Fine-tuning도 선택지.

이 구간은 생각보다 자주 잊혀요. 많은 중소기업이 “AI 도입” 을 하겠다면서 실제로는 엔지니어 1명이 파트타임으로 붙어 있어요. 그 상황에서 RAG 시스템을 안정적으로 운영하긴 어렵습니다. Prompt로 최대한 당겨쓰다가 한계를 느낄 때 RAG로 올라가는 게 맞아요.

Q4. 데이터가 민감한가?

• 개인정보·계약·의료 기록 → Prompt로 매번 외부 API로 보내는 건 위험. RAG로 온프레미스 벡터 DB에 저장해도 청크가 LLM에 보내질 때 유출 경로가 있음. 사내 LLM 또는 Enterprise 계약(BAA 등) 이 전제.
• Fine-tuning도 민감 데이터면 주의. 학습된 가중치에서 원본이 나올 수 있는 추출 공격이 현실적.

이 카테고리는 “뭘 쓰느냐” 보다 “어디서 돌리느냐” 가 더 중요해요. 클라우드 API는 입출력 로깅 정책을 꼭 확인하고, 가능하면 해당 LLM 벤더의 zero data retention 옵션을 쓰세요.

Q5. 지연(latency)이 중요한가?

• 실시간 대화·음성 응답 등 < 500ms 필요 → Fine-tuning + 짧은 프롬프트가 유리. RAG는 검색 시간이 한 박자 추가됨.
• 챗봇·요약 등 1~3초 허용 → RAG도 문제없음.
• 배치 처리(밤새 돌림) → 뭐든 상관없음.

의사결정 요약 표예요.

조건	우선 추천
정보가 자주 바뀜	RAG
말투·포맷 고정 필요	Fine-tuning (호출량 많을 때)
예산·팀 작음	Prompt
민감 데이터	온프레미스/VPC + RAG 또는 사내 LLM
지연 중요	Fine-tuning + 짧은 프롬프트
대량 문서 참조	RAG
MVP·실험 단계	Prompt

7. 세 가지를 “섞어 쓰는” 현실 패턴

여기까지 읽으시면 “아, 셋 중 하나를 골라야 하는구나” 라고 생각하실 수 있어요. 그런데 프로덕션 현실은 그렇지 않습니다. 대부분의 진지한 AI 제품은 셋을 조합 해서 씁니다.

가장 흔한 조합을 몇 개 소개할게요.

패턴 A: Prompt + RAG

가장 많이 보는 조합이에요. 시스템 프롬프트로 톤·역할·포맷을 잡고, RAG로 회사 문서를 끌어오고, 마지막에 유저 질문을 붙입니다.

[시스템 프롬프트: 고객 지원 역할, 3단 구조, 존댓말]
[RAG로 검색된 규정 청크 3개]
[유저 질문]

장점은 fine-tuning 없이도 말투와 지식 둘 다 잡을 수 있다는 거예요. 중소·중견 회사의 70%는 이 조합으로 충분합니다.

패턴 B: Fine-tuning + Prompt

호출량이 많아서 비용이 병목이 되면, 긴 시스템 프롬프트를 fine-tuning으로 모델에 넣어버립니다. 그 다음엔 호출할 때마다 짧은 사용자 메시지만 보내요. 톤과 포맷은 모델이 알아서 처리합니다.

패턴 C: Fine-tuning + RAG + Prompt (풀스택)

진짜 규모 있는 서비스는 셋 다 씁니다.

• Fine-tuning: 도메인 말투·포맷·안전 가드레일을 몸에 배게.
• RAG: 최신 문서·상품·가격·재고를 실시간으로 주입.
• Prompt: 이번 호출에서만 필요한 구체 지시(“이번 답변은 영어로” 같은).

Cursor, Perplexity, Harvey AI, Jasper 같은 AI 제품들 뒤에는 거의 이 구조가 깔려 있어요.

조합 고를 때의 순서

경험상 이 순서가 좋아요.

1. Prompt만으로 시작. 어디까지 되는지 본다.
2. 문서량·최신성이 벽이 되면 Prompt + RAG로 확장.
3. 호출량·비용·일관성이 벽이 되면 Fine-tuning을 추가.

거꾸로 가지 마세요. “처음부터 fine-tuning” 은 90%의 경우 낭비예요.

8. 실무 착시 한 가지 — “fine-tuning 하면 환각 없어진다”는 오해

이게 제가 현장에서 제일 자주 부수는 오해예요. 대표님, 임원분, 개발자분 할 것 없이 이렇게 믿는 분이 많아요.

“회사 데이터로 fine-tuning 하면, 이제 이 모델은 거짓말 안 하겠죠?”

아뇨. 절대 아닙니다.

F1에서 다뤘죠. LLM은 “그럴듯함 생성기” 예요. 다음 토큰이 뭐일지 확률적으로 예측해서 문장을 이어붙입니다. 사실 검증 회로 같은 건 없어요. Fine-tuning을 해도 이 기본 구조는 안 바뀝니다.

오히려 fine-tuning은 때로 환각을 더 자신 있게 만들어요. 왜냐면 학습 데이터의 말투가 “자신감 있는 단언형” 이면, 모델은 사실 여부와 무관하게 그 말투로 답하거든요. “우리 회사 규정에 따르면 XXX” 라고 당당하게 말하지만, 실제 규정에는 그런 조항이 없는 답변. 이게 fine-tuning이 가장 잘 만드는 실수입니다.

환각을 줄이는 건 다른 층위의 작업이에요.

• RAG: 답변에 참조 근거를 붙여서 “이 근거가 없으면 모른다고 답해” 라는 지시가 먹히게 만들어요. 이게 가장 효과 강한 반-환각 장치입니다.
• Retrieval 기반 평가: 답변을 생성한 뒤, 근거 청크와 대조해서 일치하는지 다시 LLM으로 검증.
• 출력 구조화: JSON 스키마 강제, 빈 필드 허용으로 “모름”을 명시적으로 받게.
• 사람 검수 루프: 최종적으로 의사결정을 사람이 확인.

Fine-tuning이 환각 처리에 기여하는 부분은 “단언형 말투를 덜 쓰도록 조정” 하는 정도예요. 지식 검증은 RAG와 체인에 맡겨야 합니다.

한 줄로. “모르면 모른다고 말하게 하려면 fine-tuning이 아니라 RAG + 프롬프트 규칙 + 평가 루프가 필요.”

9. 비용 숫자로 보는 감 — 대략 범위

숫자 없이 “싸다/비싸다” 말하는 건 의미가 없죠. 2025~2026년 기준으로 대략적인 범위를 드릴게요. 실제 숫자는 벤더·모델·규모에 따라 크게 달라지니까 “감” 으로만 받아주세요.

Prompt 기반 시스템

• 호출당: $0.001 ~ $0.05 (모델과 길이에 따라)
• 월 호출 5,000회, 중간 길이 기준: 월 $5 ~ $50
• 월 호출 50,000회 기준: 월 $50 ~ $500
• 엔지니어링 셋업: 개발자 1명·며칠 정도
• 초기 투자: 거의 0원 ~ 수십만 원

RAG 시스템

• 인덱싱: 문서 10,000페이지 기준 일회성 $100 ~ $500 (embedding 비용)
• 벡터 DB 운영비: Pinecone·Weaviate·pgvector 기준 월 $50 ~ $500 (규모에 따라)
• LLM 호출비: Prompt 시스템과 비슷하거나 조금 더 (청크가 추가되니까)
• 엔지니어링 셋업: 개발자 1~2명·2~4주
• 초기 투자: $500 ~ 수만 달러 (본격 시스템은 수만 달러 수준)

Fine-tuning 시스템

• OpenAI 계열 fine-tuning 학습 비용(LoRA급): $100 ~ $5,000 (데이터량에 따라)
• Full fine-tuning 상용 규모: $10,000 ~ $500,000+
• 자체 호스팅 오픈소스(Llama·Qwen·Mistral 등): GPU 대여비 $500 ~ $수만 + 엔지니어 인건비가 더 큼
• 데이터 준비: 보통 엔지니어링 비용의 최대 부분. 수백만 원 ~ 수천만 원
• 엔지니어링 팀: ML 엔지니어 1명 이상 필수
• 초기 투자: 최소 $1,000 ~ 수억 원

운영 중 지속 비용 감각

하루 1,000 호출 기준, 거친 감각:

• Prompt 중심: 월 수만 원
• RAG 중심: 월 수십만 원 ~ 수백만 원
• Fine-tuning 중심 + 자체 호스팅: 월 수백만 원 ~ 수천만 원

한 자릿수 차이가 나요. 그래서 “필요해지기 전에 안 올라가는 게 맞다.”

10. 작은 회사의 현실적 시작 — 3단계 순서

대표님 입장, 개발 리드 입장, 혼자 하는 창업가 입장에서 제일 많이 묻는 게 “그럼 어디서 시작해요?” 예요. 제가 추천하는 3단계는 이거예요.

1단계. Prompt만으로 MVP (1~4주)

• 제일 쓰기 편한 LLM API 하나 고르세요. OpenAI, Anthropic, Google Gemini 중 하나.
• 목표 사용 시나리오 하나만 정하세요. 예: “사내 규정 챗봇”, “고객 지원 초안 생성기”, “회의록 요약”.
• 시스템 프롬프트에 역할·톤·포맷·금지사항을 적어 넣으세요.
• 프론트엔드는 가장 단순한 걸로. Slack 봇, 내부 웹 툴, 심지어 구글 시트 함수도 좋아요.
• 일주일 써보고 “쓸만한가?” 를 솔직히 평가하세요. 쓸만하면 다음 단계로.

이 단계에서 90%는 RAG나 fine-tuning이 필요 없다는 걸 깨닫게 돼요. 나머지 10%만 진행합니다.

2단계. 데이터 쌓이면 RAG 붙이기 (4~12주)

• 회사 문서를 한곳에 모으세요(Notion, Confluence, 구글 드라이브 등).
• 청크 전략을 정하세요. 500자, 1,000자, 2,000자 중 무엇으로 자를지. 보통 700~1,000자가 무난해요.
• embedding 모델 하나 고르세요. OpenAI text-embedding-3-small이 가성비 좋고, Cohere, Voyage도 선택지.
• 벡터 DB 고르세요. 소규모면 PostgreSQL + pgvector가 제일 단순. 중규모 이상이면 Pinecone·Weaviate.
• 문서 업데이트 파이프라인을 만드세요. 원본이 바뀌면 재인덱싱하는 자동화.
• 검색 품질 평가 루프를 돌리세요. “질문 50개 + 정답 청크 50개” 데이터셋을 만들어서, 시스템이 정답 청크를 상위에 올리는지 주기적으로 확인.
• 프롬프트 엔지니어링을 새로 하세요. 청크를 어떤 포맷으로 붙일지, “근거 없으면 모른다고 답해” 를 어떻게 강제할지.

3단계. 규모 커지면 fine-tuning 고려 (6개월~1년 이상)

• 정말 필요한지 다시 확인. Prompt + RAG로 해결 안 되는 구체적 병목이 있는가.
• 병목 후보: 일관된 포맷이 안 나온다, 호출 비용이 프롬프트 길이 때문에 비싸다, 도메인 말투가 엉터리다.
• LoRA·QLoRA 같은 경량 fine-tuning부터 시작. Full fine-tuning은 최후.
• 학습 데이터를 진지하게 만들어요. 최소 1,000~5,000쌍의 고품질 입출력. 이게 가장 비쌉니다(엔지니어링 시간).
• 평가 데이터셋을 별도로 준비해서, fine-tuned 모델이 원본 모델보다 측정 가능하게 나은지 확인.
• 배포 후에도 Prompt와 RAG는 병행. Fine-tuning이 전부를 대체하는 게 아니라 “말투·포맷·안전 가드” 층을 담당한다고 생각하세요.

이 순서가 정답은 아니에요. 다만 이 순서로 가면 돈·시간·노력의 낭비가 제일 적습니다. 반대 순서로 간 팀들을 여럿 봤는데, 대부분 fine-tuning에 큰돈을 쓰고도 결국 RAG를 붙이게 되더라고요.

11. 실무자 체크리스트

오늘 글을 덮기 전에, 5개 bullet로 정리할게요. 회사 회의에 가져가시면 돼요.

• “AI 붙이자” 는 말이 나오면 먼저 “정보가 얼마나 자주 바뀌나” 와 “일관된 말투·포맷이 필요한가” 두 질문을 던진다. 여기서 이미 80%는 방향이 갈린다.
• 기본은 Prompt부터 시작한다. MVP로 안 되는 부분이 명확해질 때까지 RAG·Fine-tuning은 미룬다. “필요해져서 올라간다” 와 “있어 보이려고 올라간다” 는 다르다.
• 정보가 많고 자주 바뀌면 RAG. 말투·포맷이 고정되어야 하고 호출량이 크면 Fine-tuning. 이 구분만 명확하면 벤더·도구 선택은 뒤에 붙는다.
• 환각 문제는 Fine-tuning으로 해결 안 된다. RAG + 근거 인용 + 평가 루프 + 사람 검수로 가야 한다. “학습시키면 거짓말 안 할 거야” 는 틀린 가정이다.
• 프로덕션 규모로 가면 셋 다 섞어 쓴다. “하나만 골라야 한다” 가 아니라 “단계적으로 쌓아 올린다” 로 생각하자. 오늘 Prompt, 6개월 뒤 RAG, 1년 뒤 Fine-tuning은 건강한 경로다.

닫는 한 문장

LLM은 이미 전 세계 요리를 다 아는 요리사다. 당신이 할 일은 “우리 집 김치찌개 레시피” 를 어떻게 전할지 고르는 것뿐이다. 매번 불러줄지, 부엌에 비치할지, 학교에 보낼지. 조급해하지 말고 제일 쉬운 방법부터 쓰자.

다음 편은 M1 — Retrieval Layer: 회사 문서를 AI가 찾아 읽게 만드는 층 입니다. 오늘 RAG의 흐름을 훑었다면, 다음 편은 그 흐름 안에서 “검색” 부분만 파고 들어가요. 청크 전략, hybrid search(vector + keyword), reranking, 평가 지표(MRR·Recall@K) 같은 걸 차근차근 볼 거예요. RAG 시스템을 실제로 돌리고 싶으신 분은 꼭 읽어주세요.

FAQ

Q1. Fine-tuning과 RAG 중 하나만 골라야 한다면?

거의 대부분의 경우 RAG입니다. Fine-tuning이 빛나는 상황은 “말투·포맷이 매우 엄격하고 호출량이 하루 수만 건 이상인 서비스” 로 좁혀져요. 그 외엔 RAG + 좋은 프롬프트가 비용·시간 대비 답입니다.

Q2. OpenAI API만으로 RAG를 만들 수 있나요?

임베딩(text-embedding-3-small)과 Chat Completions는 OpenAI가 제공하는데, 벡터 DB는 직접 붙여야 해요. 가장 단순한 조합은 OpenAI embedding + PostgreSQL + pgvector 입니다. 개발자 한 명이 주말에 POC 만들 수 있는 규모예요. 본격 운영은 Pinecone이나 Weaviate 같은 전용 DB로 가는 게 편합니다.

Q3. Claude로도 Fine-tuning이 되나요?

2026년 4월 기준, Anthropic은 엔터프라이즈 고객 대상으로 Claude fine-tuning을 제한적으로 제공합니다(AWS Bedrock·Google Vertex 경유가 대표적). 개인 개발자가 바로 쓸 수 있는 옵션은 OpenAI가 훨씬 열려 있고, 오픈소스 모델(Llama 3, Qwen 2.5, Mistral 등)을 자체 호스팅하는 방식도 많이 쓰여요.

---

소스 리스트 (Sources)

• OpenAI, “Fine-tuning” (platform.openai.com/docs) — fine-tuning API·비용·LoRA 지원 범위
• Anthropic, “Prompt Engineering” (docs.anthropic.com) — 시스템 프롬프트·prompt caching
• Anthropic, “Contextual Retrieval” (anthropic.com/research) — RAG의 retrieval 품질을 높이는 기법
• OpenAI, “Embeddings” (platform.openai.com/docs/guides/embeddings) — text-embedding-3 계열 스펙
• Pinecone, “Vector Database Concepts” (pinecone.io/learn) — 벡터 DB 아키텍처·비용 구조
• Meta AI, “LLaMA 3 Technical Report” — 오픈소스 모델 fine-tuning 실무 레퍼런스
• Microsoft, “LoRA: Low-Rank Adaptation of Large Language Models” (arxiv.org/abs/2106.09685) — PEFT/LoRA의 원리
• mathbullet YouTube 채널 — gradient descent 시각화 해설 (F6 연계)

---

회원 가입(무료)하면 매주 월요일 AI·LLM 실무 뉴스레터를 받아보실 수 있습니다 →

소스 리스트

• 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
• AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 공식 docs
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스

---

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.