오래된 SW 엔지니어의 평생 공부

이번 글에서는 “LLM을 실제 서비스로 만들기 위한 설계 방법”을 다룬다.

핵심은 세 가지다:

• LLM 아키텍처 설계
• 데이터 설계 (가장 중요)
• Fine-tuning 전략 (SFT + QLoRA)

1. LLM 시스템은 하나의 모델이 아니다

많은 사람들이 LLM 시스템을 이렇게 생각한다:

“좋은 모델 하나 쓰면 끝”

하지만 실제로는 전혀 다르다.

실무에서는 보통 다음과 같은 구조를 가진다:

[User Request]
      ↓
[Router / Parser]  (작은 모델)
      ↓
[Main LLM]         (중간 모델)
      ↓
[Reasoning LLM]    (필요 시 fallback)
      ↓
[Judge / Evaluator]

핵심은 이것이다:

“큰 모델 하나로 해결하지 말고 역할을 분리하라”

2. 왜 모델을 나눠야 하는가

이 구조는 단순한 기술적 선택이 아니다. 비용 / 성능 / 안정성의 균형 문제다.

역할별 특징

• Router (1B~4B)
  • intent 분류
  • tool 선택
  • JSON 구조 강제
  • → 빠르고 싸야 한다
• Main LLM (7B~13B)
  • 일반 QA
  • RAG 응답
  • 대화 처리
  • → 대부분의 요청 처리
• Reasoning LLM (30B+)
  • 복잡한 추론
  • 멀티 스텝 문제
  • → fallback 전용
• Judge
  • 품질 평가
  • A/B 테스트

이 구조는 결국 이렇게 요약된다: “모든 요청을 비싼 모델로 처리하지 않는다”

3. 데이터가 성능의 80%를 결정한다

모델보다 중요한 것이 있다. 바로 데이터이다. 특히 SFT에서는 더 그렇다.

4. Schema First: 먼저 형식을 고정하라

가장 인상 깊었던 개념이다.

모델은 “의미”보다 “형식”을 먼저 학습한다

예를 들어:

• JSON 구조
• 필드 이름
• 응답 포맷

이게 흔들리면?  downstream 시스템 전체가 깨진다

그래서 필요한 것

• Key 구조 고정 (intent, slots, status 등)
• 값 범위 정의 (ready / need_clarification 등)
• null vs "" 규칙 통일
• 필수 필드 강제

 결론:

학습 전에 schema를 먼저 설계하라

5. 좋은 데이터는 “틀리는 데이터”다

이건 거의 철학에 가깝다. 많은 사람들이 이렇게 데이터 만든다:

쉬운 데이터 위주가 아니다.

결과:

• 과적합
• 실전 성능 붕괴

좋은 데이터의 특징

 모델이 틀리는 케이스 중심

• Ambiguous (모호한 요청)
• 정보 부족
• 조건 충돌
• 비정상 요청 (jailbreak 등)

예:

• “전화해봐” → 누구에게?
• “새벽 3시에 예약해” → 현실적으로 가능한가?

 핵심:

“좋은 데이터는 모델이 틀린 데이터다”

6. 데이터 분포 전략

추천 분포:

• Common: 60~70%
• Edge: 15~25%
• Ambiguous: 10~15%

이 구조는 중요한 의미를 가진다. 즉, 실패 영역을 중심으로 학습한다

7. 데이터는 수집이 아니라 “생성”이다

또 하나 중요한 포인트:

데이터는 모으는 것이 아니라 만들어야 한다

방법:

• 실패 케이스 수집
• 패턴 분석
• 템플릿화
• LLM으로 데이터 증강

특히 edge / ambiguous 케이스는 의도적으로 만들어야 한다

8. SFT의 본질 (오해 깨기)

많은 사람들이 SFT를 이렇게 이해한다:

 “모델을 더 똑똑하게 만든다” 하지만 실제는 다르다.

SFT는 “더 많이 알게 하는 것”이 아니라
“원하는 형태로 출력하게 만드는 것”

SFT가 잘 맞는 경우

• JSON 출력 강제
• Tool calling
• 분류 / 라우팅
• 포맷 제어

즉, 패턴 학습 문제가 잘 맞는다.

9. Tool Calling은 사실 SFT 문제다

예를 보자:

{
  "function_name": "get_weather_info",
  "arguments": {
    "location": "서울 강남구",
    "current_temp": true
  }
}

이걸 잘 만들게 하는 방법은?

RAG가 아니라 SFT. 왜냐하면:

• 지식 문제가 아니라
• 형식 문제이기 때문

10. Fine-tuning 전략: Full vs LoRA vs QLoRA

현실적인 선택은 세 가지다:

핵심 차이

• Full FT → 전체 weight 학습
• LoRA → 변화량만 학습
• QLoRA → 양자화 + LoRA

 QLoRA의 의미:

작은 GPU로 큰 모델을 학습 가능

11. 메모리의 본질

모델은 결국 숫자다.

예:

• 7B 모델
• FP16
• 약 14GB 필요

그래서 등장한 것이 Quantization (4-bit 등) 이다.

12. Unsloth: 실무 최적화 도구

흥미로운 포인트 하나: Unsloth는 알고리즘이 아니다.

👉 엔지니어링 최적화

• VRAM 절감
• 속도 향상 (약 2배)
• Colab에서도 가능

핵심:

“수학은 그대로, 실행만 빠르게”

13. 중요한 디테일: Tokenizer & Special Token

이건 많이 놓치는 부분이다. 같은 문장이라도:

• 모델마다 토큰 분리 다름
• special token 다름
• chat template 다름

 결과:

같은 입력인데 다른 의미로 해석됨

그래서 반드시: apply_chat_template() 사용

14. 결론: LLM 시스템 설계의 본질

이 모든 내용을 한 줄로 요약하면:

LLM 시스템은 “모델”이 아니라
데이터 + 구조 + 전략의 조합이다

핵심 정리

1. 모델 하나로 해결하지 말 것
2. 데이터가 성능을 결정한다
3. SFT는 “형식 제어”다
4. RAG는 “지식 보완”이다
5. 실패 케이스가 가장 중요하다

마무리

이번 교육을 통해 가장 크게 바뀐 생각은 이것이다:

“LLM을 잘 쓰는 사람은 모델을 고르는 사람이 아니라
문제를 구조적으로 설계하는 사람이다”

필요하다면 다음 단계로:

• 실제 서비스 아키텍처 설계 (AdviceGen 적용)
• RAG + SFT 하이브리드 설계
• 비용 최적화 전략

도 이어서 정리해볼 수 있다.

최근 AI 실무 교육을 들으면서, LLM을 단순히 “좋은 모델”로 보는 관점에서 벗어나 “어떤 문제를 어떻게 풀어야 하는가”라는 구조적 이해가 훨씬 중요하다는 것을 다시 느꼈다.

이 글에서는 다음 두 가지를 하나의 흐름으로 정리한다.

• LLM은 무엇이며, 왜 틀리는가
• 그래서 우리는 언제 RAG를 쓰고, 언제 SFT를 써야 하는가

1. LLM은 무엇인가 (생각보다 단순한 본질)

많은 사람들이 LLM을 “지식을 가진 모델”이라고 생각하지만,
본질은 훨씬 단순하다.

LLM은 “다음 토큰을 가장 그럴듯하게 예측하는 모델”이다.

즉,

• 질문을 이해해서 답을 “찾는” 모델이 아니라
• 문맥(context)을 보고 “이어질 문장”을 생성하는 모델이다

2. LLM은 어떻게 학습되는가

LLM의 학습 목표는 명확하다.

👉 정답 토큰에 높은 확률을 주도록 학습

그 과정은 다음과 같다:

1. 입력 (문장)
2. 다음 단어 예측
3. 정답과 비교 (Loss 계산)
4. 오차 줄이기 (Backpropagation)

핵심은 Loss 함수다:

이 식이 의미하는 것은 단 하나다:

👉 정답을 얼마나 확신했는가

예를 들어:

• 정답 확률이 0.9 → 작은 패널티
• 정답 확률이 0.1 → 매우 큰 패널티

3. 그런데 왜 LLM은 틀릴까?

이제 중요한 질문이다. LLM은 꽤 똑똑한데 왜 틀릴까?

1) 정답을 검증하지 않는다

LLM은 “정답 여부”를 판단하지 않는다.
그저 “그럴듯한 다음 문장”을 생성할 뿐이다.

2) 외부 세계를 모른다

• 최신 뉴스
• 실시간 데이터
• 회사 내부 정보

이런 것들은 기본적으로 알 수 없다.

3) “모른다”를 말하지 않는다

학습 목표가 “그럴듯한 문장 생성”이기 때문에
모를 때도 대답하는 것이 더 높은 점수를 받는다.

4. Hallucination은 필연이다

이 세 가지가 합쳐지면 결과는 명확하다.

👉 Hallucination(환각)은 구조적으로 피할 수 없다

그래서 LLM 시스템 설계는 “모델을 더 좋게 만드는 것”이 아니라

👉 “틀릴 수 있는 모델을 어떻게 통제할 것인가”의 문제다

5. 그 해결 전략: RAG vs SFT

이제 본론이다. LLM의 한계를 해결하기 위해 등장한 대표적인 전략이 두 가지다:

• RAG (Retrieval-Augmented Generation)
• SFT (Supervised Fine-Tuning)

6. RAG: “무엇을 말할지” 해결

RAG는 간단하다.

👉 외부 지식을 가져와서 답변하게 만든다

동작 방식:

1. 질문을 받는다
2. 관련 문서를 검색한다 (embedding 기반)
3. 문서를 포함해서 LLM에 입력한다
4. 답변 생성

즉, 지식 부족 문제를 해결한다

언제 쓰는가?

• 최신 정보가 필요한 경우
• 근거 기반 답변이 필요한 경우
• 사내 문서 기반 QA

7. SFT: “어떻게 말할지” 해결

SFT는 완전히 다른 문제를 푼다.

👉 모델의 “출력 방식”을 학습시킨다

예:

• JSON 형식으로 응답
• Tool 호출 구조 맞추기
• 특정 말투 유지

즉, 형식 / 스타일 / 규칙 문제를 해결한다

8. 핵심 정리 (가장 중요한 부분)

이 교육에서 가장 인상 깊었던 한 줄:

“무엇을 말할지 → RAG
어떻게 말할지 → SFT”

이걸 조금 더 구조적으로 보면:

9. 실무에서 자주 하는 실수

많은 팀이 이런 실수를 한다:

 “모델이 이상하게 답한다 → 더 큰 모델 쓰자”

하지만 실제 문제는 대부분:

• 정보가 없음 → RAG 문제
• 형식이 깨짐 → SFT 문제

모델 문제가 아니라 설계 문제다

10. 결론: LLM은 모델이 아니라 시스템이다

LLM을 제대로 쓰기 위해서는 관점이 바뀌어야 한다.

• 모델을 잘 고르는 것보다
• 문제를 어떻게 분해하고 설계하는지가 더 중요하다

정리하면:

• LLM은 “정답 엔진”이 아니라
• “확률 기반 생성기”

그래서 우리는:

• RAG로 “지식”을 보완하고
• SFT로 “출력”을 통제해야 한다

마무리

이번 교육을 통해 느낀 가장 중요한 포인트는 이것이다:

“LLM을 잘 쓰는 것은 모델을 이해하는 것이 아니라,
문제를 구조적으로 설계하는 것이다.”