파인튜닝의 귀환

• 파인튜닝이 AI 개발 방법론의 중심으로 다시 부상하고 있으며, 이는 Thinking Machines Labs의 Tinker 발표와 자체 관리형 오픈소스 LLM 배포로의 패러다임 전환을 통해 촉발됨
• 한때 AI 추론 워크로드의 10% 미만으로 감소했던 파인튜닝이 GPU-as-a-service 플랫폼, 안정화된 모델 생태계, 오픈웨이트 모델의 확산으로 다시 주목받고 있음
• LoRA(Low-Rank Adaptation) 기술은 수십억 개의 파라미터를 재학습하는 대신 작은 저랭크 행렬만 추가하여 비용을 대폭 절감하면서도 성능을 유지하거나 개선함
• Tinker는 온라인 강화학습을 통한 지속적 학습 아키텍처를 제공하며, 사전 작성된 응답을 모방하는 대신 모델 자체의 응답을 평가하고 개선하는 방식으로 파인튜닝의 미래를 제시함
• 파인튜닝은 단순한 기술적 단계를 넘어 소유권, 정렬성, 지속적 개선을 위한 전략적 레이어로 진화하고 있으며, 개인용 AI 컴퓨터와 특화된 에이전트 운영의 핵심 동력이 될 전망

---

파인튜닝의 역사적 배경

• Thinking Machines Labs가 Tinker를 발표하며 파인튜닝-as-a-platform 논의가 재점화
  • OpenAI의 전 CTO Mira Murati가 설립한 이 스타트업은 설립 6개월 만에 120억 달러 가치 평가를 받음
  • 대학과의 연구 협력을 위한 기반으로 파인튜닝 플랫폼을 포지셔닝함
• Hugging Face의 Clément Delangue는 자체 관리형, 오픈소스, 특화된 LLM 배포로의 패러다임 전환을 감지함
  • NVIDIA의 DGX Spark와 같은 전용 하드웨어가 이를 뒷받침함
  • a16z의 Personal AI Workstation은 이러한 트렌드를 보여주는 마케팅 사례
• 파인튜닝은 대규모 언어모델의 첫 번째 물결 이후 잠시 주목받았으나, 현재 AI 추론 워크로드의 10% 미만을 차지하며 급격히 사라짐

Transformer 이전 시대

• Transformer 혁신 이전 NLP는 특화된 모델에 의존함
  • RNN과 LSTM과 같은 순환 아키텍처가 초기 진전을 이룸
  • 처음으로 수작업 언어 특징 대신 단어 시퀀스에서 직접 학습함
  • 각 애플리케이션은 작업별 데이터로 처음부터 시작해야 했음

Transformer의 등장과 파인튜닝 방법론 확립

• 2017년 Google의 Attention Is All You Need 논문이 Transformer 아키텍처를 소개함
  • 순환과 컨볼루션을 셀프 어텐션만으로 대체함
• 7개월 후 ULMFiT는 사전학습된 언어모델(당시 여전히 LSTM 기반)을 다양한 작업에 파인튜닝할 수 있음을 입증함
  • Transformer를 실용적으로 만드는 방법론적 기반을 확립함
• 1년 후 BERT와 GPT-1이 이 설계를 실제로 적용함
  • BERT는 이해를 위해 양방향 어텐션을 가진 인코더 측면을 활용함
  • GPT는 생성을 위해 단방향 어텐션을 가진 디코더 측면을 사용함
• BERT는 특히 NLP 문화를 재편함
  • 모든 모델을 처음부터 구축하는 대신, 연구자들은 사전학습된 Transformer를 파인튜닝하여 수개월의 수작업 특징 엔지니어링이 필요했던 결과를 달성함

Full Fine-Tuning의 한계와 LoRA의 등장

• 파라미터가 수백만에서 수천억 개로 폭증하면서 파인튜닝이 더 이상 현명한 선택이 아니게 됨
  • Full Fine-Tuning(FFT)은 모든 레이어와 가중치를 재학습하는 것을 의미함
  • 정밀도를 제공했지만 막대한 비용이 들었음
  • 한때 몇 시간의 GPU 작업이었던 것이 대규모 산업 작업으로 변모함
• 2021년 Microsoft Research가 LoRA(Low-Rank Adaptation of Large Language Models) 를 소개함
  • 수십억 개의 파라미터를 재학습하는 대신, LoRA는 원본 가중치를 동결하고 선택된 레이어에 작은 저랭크 행렬을 추가함
  • 이것들만 학습되어 비용을 한 자릿수 줄이면서 FFT 성능을 유지하거나 개선함
  • LoRA는 기본 방식이 되었음
  • 2024년까지 Hugging Face의 PEFT 라이브러리 덕분에 한 줄의 명령으로 구현 가능함

하이퍼파라미터 튜닝의 복잡성

• 파인튜닝은 배포하고 유지할 패키지 이상의 것임
  • 튜닝 자체가 진짜 마법이 일어나는 곳이며, 결코 모든 것에 맞는 단일 구성이 아님
• 하이퍼파라미터 튜닝 자체가 모델의 성패를 좌우함
  • 랭크, 학습률, 알파 비율의 균형을 맞추는 과정은 과학보다 연금술에 가까움
  • 어댑터가 과적합되거나 모델이 이미 알고 있는 것을 잊는 현상(catastrophic forgetting)을 피해야 함
• 작동하는 것을 얻었을 때 평가는 검증보다 점술에 가깝게 느껴짐
• 한편 LLM은 거의 모든 작업에서 계속 개선되어 전지전능에 가까워짐
  • 2023년까지 대부분의 팀은 더 큰 컨텍스트 윈도우 덕분에 프롬프트 엔지니어링을 통해 파인튜닝 성능의 약 90%를 달성할 수 있음을 깨달음
  • RAG(Retrieval-Augmented Generation)도 모델에 외부 지식 베이스 접근을 제공함
  • 두 접근법 모두 재학습이 필요 없고 훨씬 적은 운영 부담으로 괜찮은 결과를 제공함

파인튜닝이 다시 주목받는 이유

• 한때 파인튜닝을 무관하거나 비효율적으로 만들었던 요인들이 이제 하나씩 해결되고 있음
  • Together.ai와 같은 GPU-as-a-service 플랫폼은 최소한의 마찰로 LoRA 파인튜닝 파이프라인을 시작할 수 있게 함
  • 새 모델이 여전히 빠르게 나오지만, 변화는 이제 혁명적이기보다 진화적임
  • Mistral, Llama, Falcon, Yi, Gemma와 같은 오픈웨이트 생태계는 조직이 벤더 종속 없이 파인튜닝된 변형을 소유하고 검사하고 유지할 수 있는 많은 대안을 제공함
  • 기업들은 프롬프팅만으로 달성할 수 있는 것의 한계에 도달했을 수 있음
• 파인튜닝은 트렌디한 기능이 아니라 제어, 차별화, 내장 인텔리전스를 위한 전략적 레버로서 천천히 다시 조명을 받고 있음

Thinking Machines Lab의 Tinker와 LoRA 개선 사항

• Thinking Machines Lab의 Tinker는 정리 증명, 화학 추론, 멀티에이전트 강화학습, AI 안전성에 초점을 맞춤
• 그들의 블로그 게시물 LoRA Without Regret에서 더 효과적으로 파인튜닝하는 방법을 공유함
  • 원본 논문처럼 어텐션 레이어만이 아닌 모든 선형 모듈에 LoRA를 적용할 것을 권장함
  • 종종 간과되는 하이퍼파라미터인 LoRA 랭크의 중요성을 강조함
  • 더 높은 학습률(최소 10배), 더 작은 배치 크기(일반적인 관행의 반대) 설정을 권장함
  • 수학적 또는 논리적 검증으로 보상 함수를 명시적으로 정의할 것을 조언함
  • 모든 권장 사항은 Hugging Face의 TRL에서 명확하게 설명되고 재현 가능함

현대 파인튜닝 파이프라인의 모듈성

• 현대 파인튜닝 파이프라인은 5년 전과 완전히 다름
  • 모듈식, 서버리스, 오케스트레이션됨
• 단일 배포는 기본 모델과 함께 수십 개의 LoRA 어댑터를 실행할 수 있음
  • 각각은 특정 톤, 기능 또는 도메인을 나타냄
• 추론 중에 시스템은 정적 모델 파일에 의존하는 대신 올바른 어댑터 조합으로 쿼리를 라우팅함
• 이러한 모듈성은 자체적인 과제를 야기함
  • Together.ai와 같은 올인원 플랫폼은 대부분의 무거운 작업을 처리하지만, 많은 팀이 필요로 하는 세밀한 구성과 관찰 가능성이 부족함
  • 대규모 비용이 빠르게 확대될 수 있음

Tinker의 독특한 접근 방식

• Tinker는 두 가지 장점을 모두 제공하는 것으로 보임
  • 현대적이고 완전히 관리되는 파인튜닝 스택의 편안함과 연구자를 위한 세밀한 제어를 결합함
  • 사용자가 가장 깊은 수준에서 학습 워크플로와 커스텀 알고리듬을 오케스트레이션할 수 있도록 저수준 학습 프리미티브에 대한 직접 API 접근을 제공함
  • 동시에 힘든 작업을 처리함
• 현재 Tinker는 연구 목적으로만 예약되어 있지만, 다른 플랫폼에 영감을 줄 것으로 기대됨
• 인프라 문제는 점차 과거의 문제가 되고 있지만, 평가라는 주요 난제가 남아 있음

모델 평가의 어려움과 온라인 강화학습

• 모델은 평가하기가 매우 어려움
  • 인간 평가는 일관성이 없고, 느리며, 무엇보다 비용이 많이 듦
  • 벤치마크는 빠르게 노화되고 데이터 오염으로 관련성을 잃음
  • G-Eval이나 Chatbot Arena와 같은 자동화된 접근법조차 자체적인 문제를 야기하며, 종종 편향을 증폭하고 불안정한 점수를 생성함
• Benjamin Anderson은 Tinker가 솔루션의 일부를 가지고 있을 수 있다고 제안함
  • Tinker는 사용자에게 온라인 강화학습을 수행할 수 있는 권한을 제공함
  • 현재 모델 가중치에서 완성본을 가져와 그 완성본을 점수화하고, 완성본이 좋았는지 나빴는지에 따라 모델을 업데이트함
  • 지도 파인튜닝은 모델에게 미리 작성된 응답을 모방하도록 가르치는 반면, 온라인 RL은 자체 응답을 점수화하여 개선함
• 이러한 아키텍처로 파인튜닝의 미래는 파인튜닝처럼 보이지 않을 수 있음
  • 지속적 학습을 닮기 시작함

파인튜닝의 전략적 진화

• Moyai.ai의 Robert Hommes는 다음과 같이 말함
  • "이론적으로 파인튜닝은 항상 합리적이었음. 그러나 클로즈드소스 랩이 모델 인텔리전스를 확장하는 속도가 실질적으로 나쁜 선택으로 만들었음"
  • "이제 컴퓨팅, 데이터, 더 나은 프레임워크로 특화로 다시 기울고 있음"
• 자체 호스팅으로의 전환은 예상보다 더 가까이 올 수 있음
  • Exxa의 Constant Razel은 "개인용 AI 컴퓨터는 더 이상 먼 아이디어가 아님"이라고 말함
  • 기술이 개선되고 더 접근하기 쉬워지고 있음
  • 보안과 비용이 초기 채택을 주도할 가능성이 있음
  • 파인튜닝은 특화된 고성능 에이전트가 그 위에서 실행되도록 할 것임
• 파인튜닝은 한계 정확도를 위한 무차별 대입 추구에서 근접성과 제어에 뿌리를 둔 소유권, 정렬성, 지속적 개선을 위한 프레임워크로 변화함
• 더 이상 단순한 기술적 단계가 아니라 인텔리전스가 구축되고 소유되는 방식의 전략적 레이어일 수 있음

[m00nlygreat]

인간이 오히려 AI 발전의 방해물이 되는군요. 이거 재미있는 딜레마인데요. ㅋㅋ

[GN⁺]

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 기본 성능만으로도 정확도가 상당히 높아 파인튜닝이 불필요함. 반대로, 정말 복잡한 과제는 파인튜닝이 매우 어렵고, 데이터 수집도 매우 비쌈. 결국 파인튜닝은 난이도가 딱 적당하고, 데이터 수집도 현실적인, 그 중간쯤 되는 작업에 쓸만한 솔루션임

  • 적합한 사용 사례가 수십만 가지는 된다고 생각함

  • 그런 “중간에 해당하는” 태스크에는 예를 들어 어떤 사례가 있는지 궁금함

• 이 웹사이트는 유럽에서 접근해도 정말 빠르게 로딩됨. 스크롤에 따라 동적으로 콘텐츠 로딩되고, 이미지도 압축률이 높은데 화질이 좋음. 사이트 구성이 정말 인상적임

  • 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 논쟁처럼, 최고 성능을 위한 개발비와 납기 리스크 때문에 대부분은 하이엔드 파인튜닝의 이득을 누리지 못함