왜 기업은 프롬프트와 외적 튜닝에 집중할까?

AI 기술이 급격하게 발전하면서 이제는 단순히 오픈AI의 ChatGPT나 구글의 제미나이를 사용하는 단계를 넘어, 기업이나 개인의 목적에 맞게 인공지능을 수정하고 발전시키려는 시도가 많아지고 있습니다.
이것을 LLM 튜닝이라고 부릅니다.

오늘부터 총 3회에 걸쳐 LLM 심화 표현과 핵심 전략인 레그를 다룰 예정입니다.
전체적인 여정은 다음과 같이 진행됩니다.

• 1회차: LLM 증강 질의와 튜닝 전략의 기초, 그리고 모델 외적 튜닝의 핵심 개념 이해
• 2회차: RAG 시스템이 실제로 잘 동작하는지 검증하고 평가하는 방법
• 3회차: 종합 예제를 바탕으로 전체적인 시스템 구성을 조율하고 구현하는 실습

오늘은 그 첫 번째 시간으로, 왜 우리가 LLM을 그대로 쓰지 않고 튜닝을 하려 하는지, 그리고 흔히 생각하는 파인 튜닝에 대해 포스팅 하게되었습니다.

---

1. 우리는 왜 LLM을 튜닝하려고 할까?

오픈AI의 API나 제미나이를 유료로 결제해서 사용할 때는 '튜닝'이라는 개념을 쓸 일이 거의 없습니다.
이미 완성된 거대 모델을 그대로 가져다 쓰기 때문입니다.
하지만 다음과 같은 상황에서는 모델을 우리 입맛에 맞게 바꾸어야 하는 니즈가 강력하게 발생합니다.

셀프 호스팅과 비용의 현실

기업 내부 데이터의 보안이 중요하거나 비용을 완전히 통제하고 싶을 때, 오픈 소스 LLM을 다운로드하여 자체 서버에 올리는 '셀프 호스팅'을 선택하게 됩니다.
이때 서비스 운영을 위한 인프라 비용, 특히 GPU 비용이 상상을 초월할 정도로 비쌉니다.
따라서 대기업이 아닌 이상 700억 개, 4000억 개의 파라미터를 가진 거대한 모델을 돌릴 수 없기 때문에, 상대적으로 크기가 작은 모델을 선택해야 합니다.

작은 모델이 가지는 한계점

작은 모델은 컴퓨터 요구 사양이 낮아 비용을 아낄 수 있지만, 치명적인 단점이 있습니다.

• 지식의 양이 적습니다: 학습한 데이터 자체가 적기 때문에 기본적으로 알고 있는 상식이나 정보의 깊이가 얕습니다.

• 기업 내부 사정을 알지 못합니다: 이것은 GPT 같은 아무리 비싸고 큰 모델도 마찬가지입니다.
  우리 회사의 내부 문서, 어제 바뀐 규정, 특정 고객사와의 거래 히스토리는 학습 데이터에 없으므로 대답할 수 없습니다.

특수 목적에 맞는 최적화

인공지능이 모든 것을 잘하는 범용 비서가 아니라, 우리 서비스 안에서 특정한 역할만 완벽하게 수행하기를 바랄 때 튜닝이 필요합니다.

• 자연어로 질문하면 데이터베이스 조회용 SQL 문으로 완벽하게 변환하는 모델
• 사용자의 요구사항을 듣고 파ython 코드를 정밀하게 짜주는 모델

---

2. 에이전틱 AI와 외부 도구 연동의 중요성

최근 인공지능 트렌드에서 가장 뜨거운 화두는 에이전틱 AI입니다.
이는 AI가 단순한 답변 기계를 넘어, 스스로 판단하고 외부 시스템과 유기적으로 상호작용하며 업무를 수행하는 형태를 말합니다.

왜 외부 시스템 연동이 필요한가?

"오늘 서울 날씨 어때?"라는 아주 간단한 질문을 예로 들어보겠습니다.
LLM은 과거의 데이터로 사전 학습된 모델이기 때문에, 오늘이 몇 월 며칠인지도 모르고 실시간 날씨 정보도 가지고 있지 않습니다.

이 문제를 해결하려면 AI가 가만히 서 있는 것이 아니라 외부 시스템과 연결되어야 합니다.

1. 사용자의 IP를 추적하거나 계정 정보를 바탕으로 위치를 파악하는 툴을 실행합니다.
2. 오늘 날짜와 위치 정보를 가지고 기상청 날씨 조회 API를 호출합니다.
3. 가져온 날씨 데이터를 해석해서 사용자에게 친절하게 답변합니다.

외부 연동을 잘하는 오픈소스와 유료 모델

모든 LLM이 이러한 외부 도구를 잘 다루는 것은 아닙니다.
사용자의 질문을 분석해서 "아, 이 타이밍에는 내가 가진 지식 대신 외부 날씨 API라는 도구를 꺼내 써야겠구나" 하고 정확하게 판단하는 능력이 필요합니다.

• 유료 모델 진영: 클로드 모델을 만드는 앤트로픽은 추론 능력이 매우 뛰어날 뿐만 아니라, MCP 같은 규격을 활용해 외부 도구와 연동하고 사용자의 질의에서 필요한 도구를 선택하는 능력이 대단히 독보적입니다.

• 오픈소스 진영: 오픈소스 중에서는 알리바바가 공개한 Qwen 모델이 이 분야에서 엄청난 성능을 보여줍니다.
  Qwen 3.5 같은 모델들은 처음부터 외부 시스템과 유기적으로 연동하는 것을 목표로 튜닝되었기 때문에, 질의문 속에서 어떤 도구 세트를 뽑아내야 하는지 정확하게 찾아냅니다.

이처럼 외부 시스템과의 연동을 매끄럽게 만들기 위해서도 모델을 특수하게 튜닝하려는 니즈가 생겨납니다.

---

3. 모델 내부 튜닝의 실체와 걸림돌

LLM을 수정하는 방법은 크게 두 가지, 모델 내부를 직접 고치는 방법과 모델 외적인 요소를 제어하는 방법으로 나뉩니다.
먼저 모델 내부를 직접 학습시키는 파인 튜닝의 작동 원리와 왜 이것이 현실적으로 어려운지 상세히 파헤쳐 보겠습니다.

파라미터와 신경망의 정체

인공지능을 이해할 때 '신경망'이라는 단어에 겁먹을 필요가 전혀 없습니다.
신경망은 쉽게 말해 '거대한 행렬 연산을 수행하는 함수'일 뿐입니다.
프로그래밍에서 함수를 만들고 그 내부에 여러 로직을 구성하는 것처럼, 수학적인 행렬 계산 구조를 복잡하게 쌓아 올린 것이 신경망입니다.

우리가 흔히 1.5B, 4B, 7B 모델이라고 부를 때의 'B'는 Billion을 의미합니다.
즉, 7B 모델은 70억 개의 파라미터를 가지고 있다는 뜻입니다.
이 파라미터는 행렬 연산 함수 내부에 들어있는 하나하나의 숫자들을 말합니다.
결국 7B 모델을 학습시킨다는 것은 70억 개의 숫자를 정교하게 조정하여 원하는 출력이 나오도록 만드는 과정입니다.

대규모 학습 데이터 구축의 한계

70억 개나 되는 엄청난 숫자들이 그물망처럼 얽혀 있습니다.
여기에 학습 데이터를 한 개 입력한다고 해서 숫자들이 크게 변할까요? 역전파알고리즘을 통해 계산된 오차가 70억 개의 숫자에 분산되어 반영되면, 숫자 하나가 움직이는 크기는 $0.0000003$ 수준으로 극히 미미합니다.

따라서 이 파라미터들이 유의미하게 움직여서 "우리 회사의 도메인 질문에는 행렬이 이렇게 반응해야 한다"라는 문맥적 변화를 만들어내려면 엄청난 양의 데이터가 필요합니다.

• 거대 파운데이션 모델을 만들 때는 보통 200만 개 이상의 데이터셋이 필요합니다.
• 작은 모델을 특정 도메인용으로 파인 튜닝하려고 해도 최소 30만 ~ 150만 개의 고품질 데이터가 누적되어야 합니다.

하지만 현실은 어떨까요? 일반적인 기업에서 기존에 가지고 있던 데이터나 매뉴얼을 긁어모아 학습용 질문-답변 세트로 정제해 보면 대략 4만 개 정도밖에 나오지 않습니다.
대기업이 아닌 이상 40만 개, 100만 개의 정제된 데이터를 확보하는 것은 불가능에 가깝습니다. 결국 7B 모델조차 파라미터를 움직이기에는 데이터가 턱없이 부족하여, 학습을 시켜봤자 기존 모델의 상태와 비교했을 때 아무런 티가 나지 않는 결과로 이어집니다.

편향과 파괴적 망각

데이터가 부족한 상태에서 특정 데이터만 억지로 반복 학습시키면, 인공지능의 밸런스가 완전히 깨져버립니다.

• 치우침 발생: 우리 회사 도메인에 대한 질문은 그럴싸하게 답변하지만, 아주 기초적인 일반 상식이나 컴퓨터 문맥을 물어보면 완전히 엉뚱하고 이상한 소리를 하기 시작합니다.
  기존에 정교하게 맞춰져 있던 70억 개 행렬의 균형이 무너지면서 원래 잘하던 것들을 잊어버리는 '파괴적 망각' 현상이 일어나는 것입니다.

이 때문에 모델 내부를 튜닝할 때는 전체 파라미터를 건드리지 않고 일부만 조절하려는 기술적 꼼수들이 동원됩니다.
LLM 내부에는 문맥의 관계를 파악하는 어텐션 레이어와 실제 연산을 처리하는 FFeed-Forward Neural Network, MLP 층 이 존재하는데, 위험성을 줄이기 위해 가볍게 FNN 층만 골라서 학습을 시키곤 합니다.

데이터의 의미를 벡터로 바꿔주는 인베딩 모델을 학습시킬 때도 모델 본체는 아예 건드리지 않고, 그 밑단에 로지스틱 회귀 층이나 작은 MLP 층을 하나 더 깔아서 모델 외적인 신경망만 튜닝하려고 노력합니다.
효율적인 기법으로 알려진 LoRA나 QLoRA를 사용할 때도 치명적인 위험을 피하기 위해 어텐션 레이어의 핵심 파라미터는 건드리지 않고 피드포워딩 층이나 추가적인 강화 층만 살짝 조절하는 방식을 취합니다.

결론적으로 시중에 나와 있는 수많은 LLM 파인 튜닝 지침서나 책들을 보고 실제로 따라 해보면 기업 환경에서는 데이터 부족으로 인해 제대로 성공하기가 매우 어렵습니다.

천문학적인 하드웨어 비용

비용 문제 또한 무시할 수 없습니다.
이미 완성된 인공지능 모델을 실행하여 답변을 얻어내는 과정을 추론이라고 부릅니다.
추론 단계에서는 200만 원 안팎의 일반적인 소비자용 그래픽카드 한 장만 있어도 7B 모델을 부드럽게 구동할 수 있습니다.
운영 비용이 상대적으로 저렴한 편입니다.

하지만 모델을 직접 가르치는 학습 단계는 추론에 비해 최소 10배 이상의 하드웨어 리소스가 소모됩니다.
효율적이라는 QLoRA 기법을 동원하더라도 7B 모델을 유의미하게 학습시키려면 대당 수천만 원을 호가하는 엔터프라이즈용 GPU가 여러 대 장착된 서버 인프라가 필수적입니다.
수천만 원에서 수억 원의 장비 비용을 감당하면서까지 성공 확률이 낮은 파인 튜닝을 고집하는 것은 대단히 비효율적인 선택입니다.

---

4. 가장 확실하고 경제적인 '모델 외적 튜닝'

내부 파라미터를 고치는 파인 튜닝이 비용과 데이터의 한계로 인해 가로막히기 때문에, 대부분의 엔지니어와 기업들은 모델 외적 튜닝으로 선회하고 있습니다.
그리고 이 모델 외적 튜닝의 중심에 바로 프롬프트 튜닝과 다음 시간에 상세히 다룰 RAG가 있습니다.

프롬프트 튜닝이 가지는 압도적인 장점

모델 외적 튜닝은 AI 모델의 내부 행렬 숫자를 단 하나도 바꾸지 않습니다.
인공지능 모델은 그대로 둔 채, 인공지능에게 입력하는 질문에 추가적인 지침이나 참고 지식을 동적으로 덧붙여서 모델의 답변을 통제하는 방식입니다.

• 가장 낮고 정직한 비용: 수천만 원짜리 GPU 장비가 필요 없으며, 프롬프트를 정교하게 가다듬는 설계 비용만 발생하므로 리스크가 매우 낮습니다.

• 유지보수의 편리함: 만약 회사의 규정이나 내부 사정이 바뀌었다면, 모델을 수일에 걸쳐 다시 재학습시킬 필요가 전혀 없습니다.
  프롬프트에 포함되는 가이드라인 텍스트나 데이터베이스에서 긁어오는 참고 문서 내용만 실시간으로 바꿔주면 즉시 수정된 결과가 반영됩니다.

따라서 모델 외적 튜닝은 인공지능이 엉뚱한 대답을 하는 현상을 방지하면서도, 기업이 원하는 정밀한 답변을 유도해 낼 수 있는 가장 손쉽고 강력한 기법으로 자리 잡았습니다.

---

5. 핵심 요약 및 다음 예고

오늘 내용을 바탕으로 모델 내부를 수정하는 것과 외적인 프롬프트를 제어하는 방식의 차이를 한눈에 이해할 수 있도록 정리해 드리겠습니다.

구분	모델 내부 튜닝	모델 외적 튜닝
작동 방식	신경망 함수 내부의 행렬 파라미터 숫자를 직접 변경	모델은 그대로 두고 입력되는 질문과 문맥을 변경
필요 데이터	최소 30만 ~ 150만 개의 정제된 대규모 데이터셋 필요	동적으로 제공할 내부 문서 및 명확한 프롬프트 지침 필요
인프라 비용	고성능 엔터프라이즈 GPU 인프라 필수	일반 추론용 환경으로 충분
위험 요인	일반 상식을 망각하거나 편향이 생길 위험 높음	위험성이 없으며 프롬프트 규칙 내에서 안정적으로 동작
유지보수	데이터 변경 시 처음부터 다시 학습 프로세스를 돌려야 함	텍스트 지침이나 외부 지식 소스만 바꾸면 즉시 반영

인공지능의 내부 행렬을 억지로 뜯어고치기보다는, 똑똑한 지침과 실시간 데이터를 프롬프트로 밀어 넣어주는 외적 튜닝이 현업에서 훨씬 더 각광받는 이유를 명확히 이해하셨을 것입니다.

이러한 모델 외적 튜닝의 꽃이 바로 레그입니다. 사용자의 질문을 받으면 내부 데이터베이스에서 관련된 문서를 똑똑하게 검색해 낸 뒤, 그 내용을 프롬프트에 얹어서 LLM에게 전달하는 기술입니다.