- 파인튜닝은 이미 학습된 모델에 내 데이터를 더 먹여 특정 방식으로 답하게 길들이는 일입니다
- 프롬프트는 매번 실어 보내야 하지만 파인튜닝은 모델 자체에 배어들어 다시 안 보내도 됩니다
- 말투·형식처럼 패턴이 일정한 일에는 잘 듣고, 최신 정보를 넣는 데는 잘 안 듣습니다
AI 이야기를 조금만 깊게 들어가면 파인튜닝이라는 말이 나옵니다. “우리 데이터로 파인튜닝했다” 같은 문장이 붙는데, 대개 뭔가 대단한 기술처럼 들립니다. 그런데 정작 그게 무엇을 바꾸는 작업인지는 잘 설명되지 않습니다.
결론부터 말하면 파인튜닝은 지식을 넣는 일이 아니라 습관을 들이는 일에 가깝습니다. 모델이 원래 할 줄 알던 것 위에, 내가 원하는 답하는 방식을 덧입히는 작업입니다. 이 한 문장을 잡고 있으면 뒤에 나오는 이야기가 대부분 정리됩니다.
이 구분이 안 되면 돈과 시간을 엉뚱한 데 씁니다. 최신 자료를 알려주려고 파인튜닝을 했는데 모델이 여전히 모르는 소리를 하는 경우가 대표적입니다. 이 글은 파인튜닝이 정확히 무엇을 바꾸는지, 언제 고르고 언제 피하는지를 정리합니다.
파인튜닝이 정확히 무엇인가요?
언어 모델은 이미 엄청난 양의 글을 읽고 나온 상태로 배포됩니다. 파인튜닝은 그 완성된 모델을 출발점으로 삼아, 내가 준비한 예시를 조금 더 학습시키는 것입니다. 처음부터 다시 만드는 게 아니라 이미 있는 것을 손보는 쪽이라서 미세 조정이라는 이름이 붙었습니다.
여기서 먹이는 데이터는 문서 더미가 아니라 질문과 정답의 짝입니다. “이렇게 물으면 이렇게 답해라”를 수백 수천 개 보여주는 식입니다. 모델은 그 짝들을 반복해 보면서 답의 모양을 그쪽으로 조금씩 기울입니다.
기술적으로 바뀌는 건 모델 내부의 가중치라는 숫자들입니다. 아주 조금씩 움직여서, 같은 질문에도 이전과는 다른 형태의 답이 먼저 튀어나오게 만듭니다. 요즘은 전체를 다 건드리지 않고 일부만 얹어서 조정하는 가벼운 방식이 많이 쓰입니다.
결과물은 나만 쓰는 별도의 모델이 됩니다. 원래 모델은 그대로 있고, 그 위에 내 취향이 반영된 판본이 하나 더 생기는 셈입니다. 이후로는 그 판본을 불러 쓰면 됩니다.
그래서 파인튜닝을 한 문장으로 줄이면 모델에게 우리 집 방식을 가르치는 일입니다. 새 직원에게 매번 규칙을 읊어주는 대신, 몸에 배도록 한동안 같이 일해보는 것과 비슷합니다.
프롬프트로 시키는 것과 무엇이 다른가요?
프롬프트로도 같은 걸 시킬 수 있습니다. “이런 말투로, 이런 형식으로 답하세요”라고 앞에 붙이면 됩니다. 다만 그 지침은 요청할 때마다 매번 같이 실려 갑니다. 모델이 기억해 두는 게 아니라, 그때그때 읽고 따르는 구조이기 때문입니다.
길이가 길어질수록 부담도 같이 커집니다. 규칙 스무 줄에 예시 다섯 개를 붙이면 질문 한 줄을 보내면서 매번 그 뭉치를 함께 보내는 셈입니다. 요금은 토큰 단위로 매겨지니, 실제로 물어본 건 짧아도 값은 뭉치 크기만큼 나갑니다.
파인튜닝은 그 뭉치를 앞으로 옮겨 모델 안에 새겨 두는 방식입니다. 한 번 학습해 두면 이후 요청에는 지침을 다시 안 보내도 됩니다. 요청이 짧아지니 토큰이 줄고, 읽을 게 적으니 응답도 조금 가벼워집니다.
안정성도 다릅니다. 프롬프트는 사람이 조금만 다르게 쓰면 결과가 흔들립니다. 여러 명이 같은 도구를 쓸 때 누가 쓰느냐에 따라 품질이 달라지는 문제가 여기서 나옵니다. 파인튜닝은 그 규칙이 모델 쪽에 있어서, 누가 부르든 같은 형태로 답이 나옵니다.
그렇다고 프롬프트가 필요 없어지지는 않습니다. 파인튜닝 뒤에도 이번 요청에만 해당하는 조건은 여전히 말로 붙여야 합니다. 매번 똑같은 것은 모델에, 매번 달라지는 것은 프롬프트에 두는 게 기본 배분입니다.
바꾸는 비용도 정반대입니다. 프롬프트는 문장 한 줄만 고치면 그날부터 바로 적용되지만, 파인튜닝은 바꾸려면 데이터를 손보고 다시 학습시켜야 합니다. 아직 규칙이 자주 흔들리는 단계라면 굳이 모델에 새겨 둘 이유가 없습니다.
지침을 문장에 둘지, 모델에 둘지의 선택입니다.매번 설명하며 부릴 것인가, 한 번 가르쳐 두고 짧게 부릴 것인가의 차이입니다.
어떤 일에 효과가 크고, 어떤 일에는 작나요?
효과가 확실한 쪽은 패턴이 일정하게 반복되는 일입니다. 정해진 말투로 답하기, 정해진 형식의 문서를 뽑기, 들어온 문의를 정해진 항목으로 분류하기 같은 것들입니다. 정답의 모양이 늘 비슷해서 예시로 보여주기 쉽다는 공통점이 있습니다.
분류가 특히 잘 맞습니다. 라벨이 정해져 있고 판단 기준이 은근히 까다로운 일은 말로 설명하는 것보다 사례를 보여주는 편이 훨씬 빠릅니다. 애매한 경계선일수록 규칙 문장으로는 잡히지 않고, 예시 수백 개로는 잡힙니다.
반대로 효과가 작은 쪽은 최신 정보나 사실 지식을 집어넣는 일입니다. 이번 달 가격표, 어제 바뀐 규정, 우리 회사 내부 문서 내용 같은 것들입니다. 이런 건 자주 바뀌는데, 바뀔 때마다 다시 학습시키는 건 현실적이지 않습니다.
그 자리에는 검색해서 붙이는 방식이 맞습니다. 질문이 들어오면 관련 문서를 찾아 그 부분만 요청에 붙여 보내는 구조입니다. 자료가 바뀌면 문서만 갈아 끼우면 되니, 모델은 손댈 필요가 없습니다.
둘은 경쟁 관계가 아니라 역할이 다른 도구입니다. 어떻게 답할지는 파인튜닝이, 무엇을 근거로 답할지는 검색이 맡습니다. 실무에서는 둘을 같이 쓰는 조합이 가장 흔합니다.
판단이 애매하면 질문을 하나 던져 보면 됩니다. 내가 바꾸고 싶은 게 답의 모양인가, 답의 내용인가. 모양이면 파인튜닝, 내용이면 검색 쪽이 먼저입니다.
한 가지 더 보면 좋은 기준은 정답을 예시로 적어 보일 수 있는가입니다. “이 요청에는 이렇게 답하는 게 맞다”를 백 개쯤 써낼 수 있으면 학습이 가능한 일입니다. 반대로 정답이 그때그때 자료에 따라 달라진다면, 아무리 예시를 모아도 배울 게 형식밖에 남지 않습니다.
파인튜닝하면 모델이 새 지식을 알게 되나요?
가장 자주 하는 오해가 이겁니다. 자료를 학습시켰으니 이제 안다고 생각하는 것입니다. 실제로는 아는 상태가 되기보다 그렇게 말하는 버릇이 드는 쪽에 가깝습니다.
차이가 잘 드러나는 예가 있습니다. 사내 제품 설명을 잔뜩 학습시키면 모델은 제품 설명처럼 들리는 문장을 아주 잘 만들어 냅니다. 문제는 정확히 그 문장이 사실인지까지 보장되지는 않는다는 점입니다.
오히려 위험해지는 구간도 있습니다. 형식은 그럴듯한데 내용이 틀린 답이 나올 때, 모르는 티가 안 나서 거르기가 더 어려워집니다. 말투가 자신 있어질수록 사람이 검증을 덜 하게 되는 것도 겹칩니다.
없는 사실을 그럴듯하게 지어내는 문제가 줄기는커녕 늘 수도 있다는 보고가 나오는 이유가 여기 있습니다. “모르면 모른다고 하라”까지 예시에 넣어두지 않으면, 모델은 배운 말투로 끝까지 답하려 듭니다.
그래서 지식 문제는 지식 쪽 해법으로 푸는 게 맞습니다. 근거 문서를 찾아 붙이고, 출처를 같이 내놓게 하는 구조입니다. 파인튜닝은 그 위에서 어떤 형태로 정리해 보여줄지를 담당하게 두면 됩니다.
비용은 얼마나 들고, 언제 고르면 되나요?
비용은 두 덩어리로 나뉩니다. 학습할 때 한 번 드는 값과, 그 뒤로 계속 쓰는 값입니다. 학습 자체는 생각보다 비싸지 않은 경우가 많고, 진짜 부담은 다른 데 있습니다.
실제 일의 대부분은 데이터 준비입니다. 예시를 모으고, 형식을 맞추고, 틀린 답을 골라내고, 애매한 경우를 어떻게 처리할지 정하는 과정입니다. 여기서 대충 넘어가면 모델은 그 대충을 그대로 배웁니다.
대신 학습이 끝나면 요청 하나하나가 가벼워집니다. 앞에 붙이던 긴 지침이 빠지니 매 호출의 토큰이 줄고, 호출이 많을수록 그 차이가 쌓입니다. 앞에서 한 번 쓰고 뒤에서 계속 아끼는 구조라고 보면 맞습니다.
그래서 요청 건수가 많을수록 유리해집니다. 하루에 몇 번 쓰는 일이라면 굳이 할 이유가 없고, 하루 수만 건이 도는 일이라면 계산이 금방 뒤집힙니다.
고르는 시점은 대체로 셋이 겹칠 때입니다. 프롬프트로 아무리 다듬어도 원하는 형태가 안 나오고, 예시를 늘려도 일관성이 안 잡히고, 같은 모양의 요청이 대량으로 반복될 때입니다. 셋 중 하나만 해당한다면 프롬프트를 더 손보는 쪽이 대개 빠릅니다.
시작할 때는 규모를 크게 잡지 않아도 됩니다. 잘 고른 예시 수백 개가 대충 모은 수만 개보다 나은 경우가 흔합니다. 작게 한 번 만들어 보고, 프롬프트만 쓸 때와 실제로 비교해 본 뒤에 늘리는 순서가 안전합니다.
비교할 기준을 미리 정해 두는 것도 중요합니다. 형식을 얼마나 지키는지, 사람이 손볼 일이 얼마나 줄었는지처럼 숫자로 볼 수 있는 항목을 두세 개 정해 두면 됩니다. 기준 없이 좋아진 것 같다로 판단하면, 들인 비용이 값을 했는지 끝까지 알 수 없습니다.
- 파인튜닝은 지식을 넣는 게 아니라 답하는 방식을 길들이는 작업입니다
- 매번 보내던 지침을 모델 쪽으로 옮겨 두는 것이라 요청이 짧아집니다
- 최신 정보가 필요하면 학습이 아니라 검색해서 붙이는 쪽이 맞습니다
같이 보면 좋은 글
- 토큰이란? — 지침이 매번 비용이 되는 이유
- 컨텍스트 윈도우란? — 한 번에 실을 수 있는 분량
- 프롬프트 캐싱이란? — 같은 앞부분을 다시 안 보내는 다른 방법
- AI·테크 용어사전 전체 목록
다음 용어는 RAG를 정리하겠습니다. 이 글에서 계속 나온 검색해서 붙이는 쪽이 바로 그것인데, 파인튜닝과 짝으로 이해해 두면 어떤 문제를 어느 쪽으로 보낼지가 훨씬 분명해집니다.