1년 전만 해도 나는 낙관적이었음. RL 기반 파인튜닝이 의미 있던 사례도 단 한 번 있었음. 하지만 이를 실제 현업에 적용하려 할 때 기존 업계 기술과의 충돌이 많음. 내 주변의 ML 엔지니어들을 보면, 특히 LLM 등장 이후 입사자들은 진짜 ML 지식이 부족한 경우가 많음. 사실상 AI 개발자 또는 AI 데브옵스 직군임. ML 자체가 데이터 엔지니어링, 분석처럼 점점 플랫폼 툴을 사용하는 직업으로 바뀌는 중임. 실제로 얼핏 보면 클라우드 플랫폼 AI 제품 중에는 평가 지표조차 제공하지 않아 제대로 된 ML 솔루션 개발이 불가능한 곳도 많음. 이 점을 크게 문제 삼는 사람도 거의 없음. RL 파인튜닝은 수많은 세부사항과 모니터링 포인트, 데이터 refinement가 필요함. 단순한 ML 모델 조차 이제는 다들 잘 안 배우는데, RL 파인튜닝 학습 격차는 그보다 훨씬 큼. 실질적으로 좋은 사례가 적으니 실무에서 선배를 통해 배울 일도 없음. 전문가 배정이나 데이터 labeling 비용도 아끼는 추세임. 회사가 이런 기술 지원을 얼마나 오래 지속해줄지, 내가 나간 뒤에도 누가 번갈아 맡아줄지 회의적임. AutoML도 대중화에 실패했고, RL도 아마 플랫폼화가 쉽지 않을 거라 생각함. 현실은 대부분의 회사가 대규모 확장 가능한 열등한 제품에 더 많은 비용을 지불하는 데 거리낌이 없음. 업계 ‘경력’은 결국 독점 플랫폼 경험임. 기술 스택에 간혹 “pytorch”를 요구하지만, 실제 쓸 줄 아는 직원이 거의 없음. 설령 있더라도 운영 부담 때문에 사용할 수 없음
라벨링은 모델을 학습하지 않더라도, 시스템을 빠르고 객관적으로 검증하는 데 정말 필수임. 그런데 라벨 확보는 항상 어려움의 연속임. 가끔 SME 리소스를 확보해도, 일관적인 기준을 엄격하게 적용해 줄 것을 요구하는 커뮤니케이션이 힘들고, 최종 라벨은 쓰기 어렵게 나옴. 결국 나는 혼자 자발적으로 라벨링을 하는 경우가 자주 있었음. 전문 분야 이해는 부족하지만, “신경망이 뭘 좋아하는지”는 대충 알아서 대기 시간은 많이 줄일 수 있었음. 대형 모델을 튜닝하는 건 아직도 정당화가 쉽지 않음. 오히려 6개월만 기다리면 더 좋은 기반 모델이 나오는 경우가 많음. 하지만 큰 모델이 너무 비싸서 효율이 떨어지는 구간이라면, 소형 모델을 목적 맞게 파인튜닝하는 건 확실히 가치가 있음
진짜 엔지니어링, 즉 복잡한 이론을 실제 작동하는 시스템으로 옮기는 기술이 진정한 의미에서 많이 약해졌다고 느낌. 이제는 많은 시간을 투자해 엔지니어링 숙련도를 높이기보다, 이미 갖춰진 엔지니어링 서비스를 타고 가려는 경향이 더 커짐. 해커 정신으로 볼 때, 모호한 GPU에서 직접 모델을 학습해보는 것에 ROI를 요구하지는 않음. 개인 엔지니어가 지식 습득을 갈망하기 때문임
결국 누군가는 실제 성과 측정을 통해 제대로 된 결과를 내고, Michael Lewis가 이걸 주제로 책을 쓰면 새로운 사이클이 다시 시작될 것이라는 생각임
나 역시 파인튜닝으로 큰 효과를 기대했던 팀들이 실제로는 점진적이거나 미미한 개선만 경험한 경우를 많이 봄. 결국 제품화까지 했다가, 최신 SOTA 업데이트 따라가지 못해 후회하는 경우가 많았음. 나는 파인튜닝을 일부러 피하는 중임. 왜냐하면 모델 자체가 너무 빠르게 좋아져서, 대기업의 제품 개발 속도가 이를 못 따라잡기 때문임
최근 트위터에서 LLM 파인튜닝으로 경제적 가치를 만든 사례들을 설문조사했음. 이 질문은 약 6개월마다 하고 있는데, 대부분 늘 실망스러운 결과였음. 이번에는 예전에 비해 조금 더 신뢰할 만한 답변이 모였음. 주요 사례는 내 트위터 스레드에 정리했고, 트위터 미가입자를 위해선 스레드 뷰어 링크도 공유함. 인상적인 사례로 Datadog이 자연어 검색 쿼리 기능에서 500ms 이하의 대기시간을 달성한 것을 들 수 있음관련 트윗, 공식문서 참조. Vercel은 Next.js 자동 생성에 커스텀 파인튜닝 모델을 운영 중이고블로그도 있음. Shopify는 상품 사진 분석용으로 파인튜닝된 Vision LLM을 활용 중임기사 참고
회귀(regression) 작업에서는 파인튜닝이 거의 필수임. 분류(classification)에서도 예/아니오 임계값 조정을 위해 확률 값을 직접 쓸 수 있으니 유용함
대부분의 회사에게는 파인튜닝의 위험 대비 보상이 기대보다 나쁠 거라 봄. 그냥 프롬프트에 데이터를 더 때려넣는 게 가능하다면 오히려 그게 편함
만약 파인튜닝이 큰 변화를 줄 수 있는 사례에 대한 아이디어가 있지만, 직접 실험할 시간이나 자원이 없다면, 이런 아이디어 공유를 환영함. 나는 지금 이런 사례들을 모으고 있는데, 현재로선 실제/확인된 사례가 3개밖에 없음
LLM에 도메인 지식을 파인튜닝하려는 많은 사람들이, 예를 들어 심리학 서적을 잘라서 그냥 텍스트만 넣는 실수를 많이 범함. 그런 방식으로는 ‘심리학을 적용하는 행동’을 가르치는 게 아니라, 단지 그것에 대해 ‘소개글을 쓰는’ 법만 학습시킴. 데이터셋 설계가 잘못된 것이 많은 파인튜닝 실패의 원인임. 반대로 데이터셋 구성이 제대로면, 7B 모델로 180B 모델을 넘는 효율을 낼 수 있음
최근 본 사례 몇 가지를 들어 OP 의견에 동의함. PaddleOCR은 0.9B 파라미터로 텍스트, 표, 수식, 차트, 손글씨까지 SOTA 정확도에 근접함논문. 그리고 3B/8B 모델이 HTML을 JSON으로 뽑아내는 작업에서 GPT-5 수준 정확도, 40~80배 저렴한 비용과 더 빠른 추론 속도를 달성함레딧. 특정 작업의 효율을 높이고 싶으면 파인튜닝이 의미가 있음
PaddleOCR을 직접 써봤는지 궁금함. Amazon Textract나 Azure Document Intelligence(LayoutLM v3 기반)와 비교하지 않고 SOTA라고 주장하는 게 의아함. 내가 문서 인식 실험을 해봤을 때는 이 둘이 최고 수준이었음
이 논의는 SLM과 LLM, 즉 모델 크기에 대한 고민과 다시 이어짐. SLM은 특정 업무에 맞게 최적화할 수 있고, 그 과제에 한해 LLM을 이길 수 있음. 다만, 1. 정밀도가 아주 중요하거나 2. 트래픽이 엄청 많지 않으면, 시간/노력 대비 가치는 떨어짐
Lamini라는 LLM 파인튜닝 스타트업을 창업했던 입장에서, OP 의견에 동의하지 않음. 우리의 가설은, 파인튜닝이 딥러닝을 처음부터 학습하는 것보다 훨씬 쉽게 사용될 거라는 것이었음. 이미 아주 강력한 LLM에서 시작하니 더 쉬울 거라 예상했음. 하지만 20여 건의 실제 프로젝트를 진행해본 결과, 파인튜닝은 딥러닝만큼이나 어렵고 진입장벽이 높았음. 현재 시장 구조상, 딥러닝 기반 파인튜닝에 능한 ML 엔지니어라면 스타트업을 창업하거나 Anthropic, OpenAI 등에 쉽게 합류할 수 있음. 정작 LLM 솔루션을 만드는 팀엔 실력이 좋은 엔지니어가 사랑받지 못함. 결과적으로 Claude, GPT, Qwen 등을 만드는 전문팀이 개별 사용자의 파인튜닝 시도보다 더 경쟁력이 있음. 지금은 RAG, 프롬프트 엔지니어링, 추론, AI 에이전트, 메모리, SLM 등이 훨씬 더 쉽고 강력한 솔루션임
Anthropic나 OpenAI가 LLM 파인튜닝을 할 줄 아는 사람이면 누구든 뽑아가려는 건지 궁금함
당시 파인튜닝했던 모델이 어떤 종류인지, 그 모델이 잘 튜닝될 만큼 발전된 모델이었는지, catastrophic forgetting(기억 소실) 문제가 있었는지 궁금함. 지금은 더 좋은 오픈 소스 모델도 많아졌음. 파인튜닝을 염두에 두고 구조를 설계하면 이전 세대의 단점도 극복할 수 있다고 생각함. 기업들은 남의 모델을 빌리는 것보다 자기 모델을 직접 소유하고 싶어함
파인튜닝은 툴박스에 꼭 있어야 할 좋은 기술임. 하지만 실제로는 적용 가능한 용도가 생각보다 좁음. 한편으로 많은 NLP 과제는 이미 LLM 기본 성능만으로도 정확도가 상당히 높아 파인튜닝이 불필요함. 반대로, 정말 복잡한 과제는 파인튜닝이 매우 어렵고, 데이터 수집도 매우 비쌈. 결국 파인튜닝은 난이도가 딱 적당하고, 데이터 수집도 현실적인, 그 중간쯤 되는 작업에 쓸만한 솔루션임
적합한 사용 사례가 수십만 가지는 된다고 생각함
그런 “중간에 해당하는” 태스크에는 예를 들어 어떤 사례가 있는지 궁금함
이 웹사이트는 유럽에서 접근해도 정말 빠르게 로딩됨. 스크롤에 따라 동적으로 콘텐츠 로딩되고, 이미지도 압축률이 높은데 화질이 좋음. 사이트 구성이 정말 인상적임
CDN의 마법, 그리고 JS 사용을 최소화한 덕분이 아닐까 추측함(아직 소스는 확인 안 함)
최근 비슷한 주제로 블로그 포스팅을 했음블로그. 7B 모델을 파인튜닝하여 GPT-4를 능가한 대규모 실증 연구 “LoRA Land”와, 최근 6개월 동안 파인튜닝 트렌드가 어떻게 변화했는지 논의했음
LoRA 어댑터로 기존 프롬프트에 꼭 넣어야 했던 작업 표준, 네이밍 스타일 선호, 참조자료, MCP 정의 등 각종 컨텍스트 요소를 모델 내부에 넣을 수 있을지 궁금함. 데이터는 일단 기존 컨텍스트를 최대한 많이 넣고, 다양한 프롬프트를 실험해, 응답이 baseline과 어떻게 다른지 보는 방식으로 만들면 편함. 그 결과를 파인튜닝에 input=“refactor {base model output}”, output=“{full-context model output}” 형태로 넣을 수도 있음. LoRA는 원래 조합해서 쓰도록 설계되어 있으니, MCP 역시 어댑터로 배포하고 켜고 끌 수 있을 듯함. 이 방식으로 컨텍스트 오염(context poisoning)까지도 예방할 수 있다고 생각함
inference.net과 schematron 개발자임. 기업들이 LLM을 실제 프로덕트에 적용하며 효율성에 점점 더 신경 씀. 개발자 입장에선 GPT-5-Super-AGI-Thinking-Max 같은 비싼 모델에 과금을 한다 해도, 실제 비즈니스는 효율성도 따짐. 만약 80억 파라미터 Llama 모델을 48시간 안에 GPT-5 데이터를 바탕으로 파인튜닝해서 월 10만 달러를 절감할 수 있다면, 당연히 다들 그 기회를 잡으려 함
이제 기업 대부분이 단순한 프롬프트만으로 달성 가능한 한계점에 도달한 것 같음. 그 기업만의 어휘, 톤, 분류 체계, 준수 규정을 정확히 아는 모델이 필요함. 속도와 비용이 중요한 것도 맞고, 이 점이 파인튜닝의 주된 이유임. 하지만 컨텍스트 관리 기법으로도 협업이 가능해짐. 컨텍스트 사이즈가 커지면서 RAG가 파인튜닝을 대체했고, 최근에는 더 좋은 프롬프트 설계만으로 활용도가 크게 높아짐. FPGA와 CPU/GPU 논쟁처럼, 최고 성능을 위한 개발비와 납기 리스크 때문에 대부분은 하이엔드 파인튜닝의 이득을 누리지 못함
Hacker News 의견
1년 전만 해도 나는 낙관적이었음. RL 기반 파인튜닝이 의미 있던 사례도 단 한 번 있었음. 하지만 이를 실제 현업에 적용하려 할 때 기존 업계 기술과의 충돌이 많음. 내 주변의 ML 엔지니어들을 보면, 특히 LLM 등장 이후 입사자들은 진짜 ML 지식이 부족한 경우가 많음. 사실상 AI 개발자 또는 AI 데브옵스 직군임. ML 자체가 데이터 엔지니어링, 분석처럼 점점 플랫폼 툴을 사용하는 직업으로 바뀌는 중임. 실제로 얼핏 보면 클라우드 플랫폼 AI 제품 중에는 평가 지표조차 제공하지 않아 제대로 된 ML 솔루션 개발이 불가능한 곳도 많음. 이 점을 크게 문제 삼는 사람도 거의 없음. RL 파인튜닝은 수많은 세부사항과 모니터링 포인트, 데이터 refinement가 필요함. 단순한 ML 모델 조차 이제는 다들 잘 안 배우는데, RL 파인튜닝 학습 격차는 그보다 훨씬 큼. 실질적으로 좋은 사례가 적으니 실무에서 선배를 통해 배울 일도 없음. 전문가 배정이나 데이터 labeling 비용도 아끼는 추세임. 회사가 이런 기술 지원을 얼마나 오래 지속해줄지, 내가 나간 뒤에도 누가 번갈아 맡아줄지 회의적임. AutoML도 대중화에 실패했고, RL도 아마 플랫폼화가 쉽지 않을 거라 생각함. 현실은 대부분의 회사가 대규모 확장 가능한 열등한 제품에 더 많은 비용을 지불하는 데 거리낌이 없음. 업계 ‘경력’은 결국 독점 플랫폼 경험임. 기술 스택에 간혹 “pytorch”를 요구하지만, 실제 쓸 줄 아는 직원이 거의 없음. 설령 있더라도 운영 부담 때문에 사용할 수 없음
라벨링은 모델을 학습하지 않더라도, 시스템을 빠르고 객관적으로 검증하는 데 정말 필수임. 그런데 라벨 확보는 항상 어려움의 연속임. 가끔 SME 리소스를 확보해도, 일관적인 기준을 엄격하게 적용해 줄 것을 요구하는 커뮤니케이션이 힘들고, 최종 라벨은 쓰기 어렵게 나옴. 결국 나는 혼자 자발적으로 라벨링을 하는 경우가 자주 있었음. 전문 분야 이해는 부족하지만, “신경망이 뭘 좋아하는지”는 대충 알아서 대기 시간은 많이 줄일 수 있었음. 대형 모델을 튜닝하는 건 아직도 정당화가 쉽지 않음. 오히려 6개월만 기다리면 더 좋은 기반 모델이 나오는 경우가 많음. 하지만 큰 모델이 너무 비싸서 효율이 떨어지는 구간이라면, 소형 모델을 목적 맞게 파인튜닝하는 건 확실히 가치가 있음
진짜 엔지니어링, 즉 복잡한 이론을 실제 작동하는 시스템으로 옮기는 기술이 진정한 의미에서 많이 약해졌다고 느낌. 이제는 많은 시간을 투자해 엔지니어링 숙련도를 높이기보다, 이미 갖춰진 엔지니어링 서비스를 타고 가려는 경향이 더 커짐. 해커 정신으로 볼 때, 모호한 GPU에서 직접 모델을 학습해보는 것에 ROI를 요구하지는 않음. 개인 엔지니어가 지식 습득을 갈망하기 때문임
결국 누군가는 실제 성과 측정을 통해 제대로 된 결과를 내고, Michael Lewis가 이걸 주제로 책을 쓰면 새로운 사이클이 다시 시작될 것이라는 생각임
나 역시 파인튜닝으로 큰 효과를 기대했던 팀들이 실제로는 점진적이거나 미미한 개선만 경험한 경우를 많이 봄. 결국 제품화까지 했다가, 최신 SOTA 업데이트 따라가지 못해 후회하는 경우가 많았음. 나는 파인튜닝을 일부러 피하는 중임. 왜냐하면 모델 자체가 너무 빠르게 좋아져서, 대기업의 제품 개발 속도가 이를 못 따라잡기 때문임
최근 트위터에서 LLM 파인튜닝으로 경제적 가치를 만든 사례들을 설문조사했음. 이 질문은 약 6개월마다 하고 있는데, 대부분 늘 실망스러운 결과였음. 이번에는 예전에 비해 조금 더 신뢰할 만한 답변이 모였음. 주요 사례는 내 트위터 스레드에 정리했고, 트위터 미가입자를 위해선 스레드 뷰어 링크도 공유함. 인상적인 사례로 Datadog이 자연어 검색 쿼리 기능에서 500ms 이하의 대기시간을 달성한 것을 들 수 있음관련 트윗, 공식문서 참조. Vercel은 Next.js 자동 생성에 커스텀 파인튜닝 모델을 운영 중이고블로그도 있음. Shopify는 상품 사진 분석용으로 파인튜닝된 Vision LLM을 활용 중임기사 참고
회귀(regression) 작업에서는 파인튜닝이 거의 필수임. 분류(classification)에서도 예/아니오 임계값 조정을 위해 확률 값을 직접 쓸 수 있으니 유용함
대부분의 회사에게는 파인튜닝의 위험 대비 보상이 기대보다 나쁠 거라 봄. 그냥 프롬프트에 데이터를 더 때려넣는 게 가능하다면 오히려 그게 편함
만약 파인튜닝이 큰 변화를 줄 수 있는 사례에 대한 아이디어가 있지만, 직접 실험할 시간이나 자원이 없다면, 이런 아이디어 공유를 환영함. 나는 지금 이런 사례들을 모으고 있는데, 현재로선 실제/확인된 사례가 3개밖에 없음
LLM에 도메인 지식을 파인튜닝하려는 많은 사람들이, 예를 들어 심리학 서적을 잘라서 그냥 텍스트만 넣는 실수를 많이 범함. 그런 방식으로는 ‘심리학을 적용하는 행동’을 가르치는 게 아니라, 단지 그것에 대해 ‘소개글을 쓰는’ 법만 학습시킴. 데이터셋 설계가 잘못된 것이 많은 파인튜닝 실패의 원인임. 반대로 데이터셋 구성이 제대로면, 7B 모델로 180B 모델을 넘는 효율을 낼 수 있음
최근 본 사례 몇 가지를 들어 OP 의견에 동의함. PaddleOCR은 0.9B 파라미터로 텍스트, 표, 수식, 차트, 손글씨까지 SOTA 정확도에 근접함논문. 그리고 3B/8B 모델이 HTML을 JSON으로 뽑아내는 작업에서 GPT-5 수준 정확도, 40~80배 저렴한 비용과 더 빠른 추론 속도를 달성함레딧. 특정 작업의 효율을 높이고 싶으면 파인튜닝이 의미가 있음
PaddleOCR을 직접 써봤는지 궁금함. Amazon Textract나 Azure Document Intelligence(LayoutLM v3 기반)와 비교하지 않고 SOTA라고 주장하는 게 의아함. 내가 문서 인식 실험을 해봤을 때는 이 둘이 최고 수준이었음
이 논의는 SLM과 LLM, 즉 모델 크기에 대한 고민과 다시 이어짐. SLM은 특정 업무에 맞게 최적화할 수 있고, 그 과제에 한해 LLM을 이길 수 있음. 다만, 1. 정밀도가 아주 중요하거나 2. 트래픽이 엄청 많지 않으면, 시간/노력 대비 가치는 떨어짐
Lamini라는 LLM 파인튜닝 스타트업을 창업했던 입장에서, OP 의견에 동의하지 않음. 우리의 가설은, 파인튜닝이 딥러닝을 처음부터 학습하는 것보다 훨씬 쉽게 사용될 거라는 것이었음. 이미 아주 강력한 LLM에서 시작하니 더 쉬울 거라 예상했음. 하지만 20여 건의 실제 프로젝트를 진행해본 결과, 파인튜닝은 딥러닝만큼이나 어렵고 진입장벽이 높았음. 현재 시장 구조상, 딥러닝 기반 파인튜닝에 능한 ML 엔지니어라면 스타트업을 창업하거나 Anthropic, OpenAI 등에 쉽게 합류할 수 있음. 정작 LLM 솔루션을 만드는 팀엔 실력이 좋은 엔지니어가 사랑받지 못함. 결과적으로 Claude, GPT, Qwen 등을 만드는 전문팀이 개별 사용자의 파인튜닝 시도보다 더 경쟁력이 있음. 지금은 RAG, 프롬프트 엔지니어링, 추론, AI 에이전트, 메모리, SLM 등이 훨씬 더 쉽고 강력한 솔루션임
Anthropic나 OpenAI가 LLM 파인튜닝을 할 줄 아는 사람이면 누구든 뽑아가려는 건지 궁금함
당시 파인튜닝했던 모델이 어떤 종류인지, 그 모델이 잘 튜닝될 만큼 발전된 모델이었는지, catastrophic forgetting(기억 소실) 문제가 있었는지 궁금함. 지금은 더 좋은 오픈 소스 모델도 많아졌음. 파인튜닝을 염두에 두고 구조를 설계하면 이전 세대의 단점도 극복할 수 있다고 생각함. 기업들은 남의 모델을 빌리는 것보다 자기 모델을 직접 소유하고 싶어함
파인튜닝은 툴박스에 꼭 있어야 할 좋은 기술임. 하지만 실제로는 적용 가능한 용도가 생각보다 좁음. 한편으로 많은 NLP 과제는 이미 LLM 기본 성능만으로도 정확도가 상당히 높아 파인튜닝이 불필요함. 반대로, 정말 복잡한 과제는 파인튜닝이 매우 어렵고, 데이터 수집도 매우 비쌈. 결국 파인튜닝은 난이도가 딱 적당하고, 데이터 수집도 현실적인, 그 중간쯤 되는 작업에 쓸만한 솔루션임
적합한 사용 사례가 수십만 가지는 된다고 생각함
그런 “중간에 해당하는” 태스크에는 예를 들어 어떤 사례가 있는지 궁금함
이 웹사이트는 유럽에서 접근해도 정말 빠르게 로딩됨. 스크롤에 따라 동적으로 콘텐츠 로딩되고, 이미지도 압축률이 높은데 화질이 좋음. 사이트 구성이 정말 인상적임
최근 비슷한 주제로 블로그 포스팅을 했음블로그. 7B 모델을 파인튜닝하여 GPT-4를 능가한 대규모 실증 연구 “LoRA Land”와, 최근 6개월 동안 파인튜닝 트렌드가 어떻게 변화했는지 논의했음
LoRA 어댑터로 기존 프롬프트에 꼭 넣어야 했던 작업 표준, 네이밍 스타일 선호, 참조자료, MCP 정의 등 각종 컨텍스트 요소를 모델 내부에 넣을 수 있을지 궁금함. 데이터는 일단 기존 컨텍스트를 최대한 많이 넣고, 다양한 프롬프트를 실험해, 응답이 baseline과 어떻게 다른지 보는 방식으로 만들면 편함. 그 결과를 파인튜닝에 input=“refactor {base model output}”, output=“{full-context model output}” 형태로 넣을 수도 있음. LoRA는 원래 조합해서 쓰도록 설계되어 있으니, MCP 역시 어댑터로 배포하고 켜고 끌 수 있을 듯함. 이 방식으로 컨텍스트 오염(context poisoning)까지도 예방할 수 있다고 생각함
inference.net과 schematron 개발자임. 기업들이 LLM을 실제 프로덕트에 적용하며 효율성에 점점 더 신경 씀. 개발자 입장에선 GPT-5-Super-AGI-Thinking-Max 같은 비싼 모델에 과금을 한다 해도, 실제 비즈니스는 효율성도 따짐. 만약 80억 파라미터 Llama 모델을 48시간 안에 GPT-5 데이터를 바탕으로 파인튜닝해서 월 10만 달러를 절감할 수 있다면, 당연히 다들 그 기회를 잡으려 함
이제 기업 대부분이 단순한 프롬프트만으로 달성 가능한 한계점에 도달한 것 같음. 그 기업만의 어휘, 톤, 분류 체계, 준수 규정을 정확히 아는 모델이 필요함. 속도와 비용이 중요한 것도 맞고, 이 점이 파인튜닝의 주된 이유임. 하지만 컨텍스트 관리 기법으로도 협업이 가능해짐. 컨텍스트 사이즈가 커지면서 RAG가 파인튜닝을 대체했고, 최근에는 더 좋은 프롬프트 설계만으로 활용도가 크게 높아짐. FPGA와 CPU/GPU 논쟁처럼, 최고 성능을 위한 개발비와 납기 리스크 때문에 대부분은 하이엔드 파인튜닝의 이득을 누리지 못함