DevelopmentNote

AI 영화 리뷰 감성 분석 서비스 아키텍처 설계

코딩은 내 여친 — Mon, 29 Jun 2026 02:51:53 +0900

이번에는 가상의 서비스로 AI 영화 리뷰 감성 분석 웹 서비스를 선정해보았다.

이 서비스는 사용자가 영화 리뷰를 입력하면 AI 모델이 해당 리뷰를 분석하여
긍정 리뷰인지, 부정 리뷰인지를 예측해주는 서비스이다.

지금까지 학습한 Docker, 추론 최적화, Streamlit, FastAPI를 활용한다고 가정하면
전체 아키텍처는 다음과 같이 구성할 수 있다.

1. 전체 서비스 구조

서비스는 크게 네 부분으로 나눌 수 있다.

사용자 화면: Streamlit
API 서버: FastAPI
AI 모델 추론 서버: ONNX 또는 TensorRT 기반 모델
배포 환경: Docker와 클라우드 서버

전체 흐름은 다음과 같다.

사용자
  ↓
Streamlit 웹 화면
  ↓
FastAPI 서버
  ↓
AI 모델 추론
  ↓
분석 결과 반환
  ↓
Streamlit 화면에 결과 출력

사용자는 Streamlit 화면에서 영화 리뷰를 입력한다.
입력된 리뷰는 FastAPI 서버로 전달되고, FastAPI는 AI 모델을 이용해 감성 분석을 수행한다.
이후 예측 결과를 다시 Streamlit 화면으로 보내 사용자에게 보여준다.

2. Streamlit 역할

Streamlit은 사용자가 직접 이용하는 웹 화면 역할을 한다.

사용자는 Streamlit 화면에서 영화 리뷰 문장을 입력하고,
분석 버튼을 누르면 결과를 확인할 수 있다.

Streamlit에서 담당하는 기능은 다음과 같다.

리뷰 텍스트 입력
분석 요청 버튼
FastAPI 서버로 요청 전송
예측 결과 출력
긍정/부정 결과 시각화

예를 들어 사용자가
“이 영화는 스토리가 좋고 배우 연기도 훌륭했다.”
라고 입력하면 Streamlit은 이 문장을 FastAPI 서버로 전달한다.

3. FastAPI 역할

FastAPI는 Streamlit과 AI 모델 사이에서 API 서버 역할을 한다.

FastAPI는 사용자의 요청을 받고, 입력 데이터를 검증한 뒤 모델 추론 함수로 전달한다.
그리고 모델이 예측한 결과를 JSON 형태로 다시 반환한다.

FastAPI에서 담당하는 기능은 다음과 같다.

/predict API 제공
입력 데이터 검증
모델 추론 요청 처리
예측 결과 반환
오류 발생 시 예외 처리

예시 응답 형태는 다음과 같다.

{
  "text": "이 영화는 정말 재미있었다.",
  "label": "긍정",
  "score": 0.92
}

이렇게 API 서버를 따로 분리하면 나중에 Streamlit뿐만 아니라 모바일 앱, 다른 웹 서비스에서도 같은 API를 사용할 수 있다.

4. AI 모델 추론 최적화

AI 모델은 학습이 끝난 후 그대로 사용하는 것이 아니라
ONNX 또는 TensorRT 형식으로 변환해 추론 속도를 높일 수 있다.

예를 들어 PyTorch로 학습한 감성 분석 모델을 ONNX로 변환하면
FastAPI 서버에서 더 가볍고 빠르게 실행할 수 있다.

추론 최적화의 목적은 다음과 같다.

응답 속도 향상
서버 자원 사용량 감소
모델 배포 환경 호환성 향상
동시에 여러 요청 처리 가능성 증가

만약 GPU 서버를 사용한다면 TensorRT를 활용해 더 빠른 추론도 가능하다.

5. Docker를 활용한 배포 구조

Docker는 서비스 실행 환경을 컨테이너로 묶어주는 역할을 한다.

Streamlit, FastAPI, 모델 추론 환경을 각각 Docker 이미지로 만들면
다른 컴퓨터나 클라우드 서버에서도 동일한 환경으로 실행할 수 있다.

예시 구조는 다음과 같다.

docker-compose.yml

streamlit-app 컨테이너
  - 사용자 웹 화면 실행

fastapi-server 컨테이너
  - API 서버 실행
  - 모델 로드 및 추론 처리

model 파일
  - ONNX 모델 저장

Docker를 사용하면 Python 버전, 라이브러리 버전, 실행 환경 차이로 생기는 문제를 줄일 수 있다.

6. 보안 요소

실제 서비스에서는 보안 설정도 필요하다.

가장 기본적으로 CORS 설정을 통해 허용된 프론트엔드 주소에서만 API 요청을 받을 수 있도록 제한할 수 있다.

예를 들어 Streamlit 주소만 FastAPI에 접근할 수 있도록 설정한다.

또한 다음과 같은 보안 요소도 고려할 수 있다.

CORS 설정
HTTPS 적용
API 요청 크기 제한
악성 입력 필터링
비정상적인 반복 요청 차단
환경 변수로 API 키 관리

특히 사용자가 입력하는 텍스트 데이터는 서버로 전달되기 때문에
개인정보나 민감한 정보가 저장되지 않도록 주의해야 한다.

7. 멀티유저 요청 처리 방안

실제 서비스에서는 여러 사용자가 동시에 요청을 보낼 수 있다.

요청이 적을 때는 FastAPI가 바로 모델 추론을 처리해도 괜찮다.
하지만 사용자가 많아지면 요청이 밀리거나 서버가 느려질 수 있다.

이를 해결하기 위해 다음과 같은 방식을 사용할 수 있다.

비동기 처리
요청 대기 큐 사용
여러 개의 API 서버 인스턴스 실행
로드밸런서 사용
GPU 추론 서버 분리

예를 들어 사용자의 요청을 바로 처리하기 어렵다면
요청을 대기 큐에 넣고 순서대로 처리할 수 있다.

구조는 다음과 같다.

사용자 요청
  ↓
FastAPI 서버
  ↓
작업 큐
  ↓
모델 추론 Worker
  ↓
결과 반환

이렇게 하면 동시에 많은 요청이 들어와도 서버가 갑자기 멈추는 문제를 줄일 수 있다.

8. 클라우드 배포 구조

서비스를 외부에서 접속 가능하게 하려면 AWS, GCP 같은 클라우드에 배포할 수 있다.

예를 들어 AWS를 사용한다면 다음과 같이 구성할 수 있다.

사용자
  ↓
AWS Load Balancer
  ↓
Streamlit 서버
  ↓
FastAPI 서버
  ↓
AI 모델 추론 서버
  ↓
CloudWatch 로그 저장

GCP를 사용한다면 Cloud Run, Compute Engine, Vertex AI 등을 활용할 수 있다.

간단한 프로젝트라면 Docker 이미지를 만든 뒤
Cloud Run이나 EC2 같은 서버에 배포하는 방식이 적합하다.

서비스 규모가 커지면 다음과 같은 구조를 고려할 수 있다.

Load Balancer로 트래픽 분산
컨테이너 기반 배포
모델 서버 분리
데이터베이스 연결
로그 저장 시스템 구성
자동 확장 설정

9. 모니터링 및 로깅 전략

서비스 배포 후에는 정상적으로 작동하는지 계속 확인해야 한다.

모니터링해야 할 항목은 다음과 같다.

API 응답 시간
요청 성공률
오류 발생률
서버 CPU 사용량
메모리 사용량
모델 추론 시간
사용자 요청 수

로그에는 다음과 같은 정보를 남길 수 있다.

요청 시간
입력 데이터 길이
예측 결과
추론 소요 시간
오류 메시지

단, 사용자의 실제 입력 문장을 그대로 저장하면 개인정보 문제가 생길 수 있다.
따라서 필요한 경우 입력 원문은 저장하지 않고, 길이나 통계 정보만 저장하는 것이 좋다.

10. 전체 아키텍처 정리

AI 영화 리뷰 감성 분석 서비스의 전체 아키텍처는 다음과 같이 정리할 수 있다.

[사용자]
   ↓
[Streamlit 프론트엔드]
   ↓
[FastAPI 백엔드 API]
   ↓
[전처리 로직]
   ↓
[ONNX/TensorRT 모델 추론]
   ↓
[후처리 로직]
   ↓
[JSON 결과 반환]
   ↓
[Streamlit 결과 화면 출력]

배포 환경에서는 각 기능을 Docker 컨테이너로 분리하고,
클라우드 서버에서 실행할 수 있다.

정리

AI 웹/앱 서비스를 구현할 때는 단순히 모델만 만드는 것이 아니라
사용자 화면, API 서버, 모델 추론, 배포, 보안, 모니터링까지 함께 고려해야 한다.

이번 예시에서는 AI 영화 리뷰 감성 분석 서비스를 기준으로 전체 구조를 설계했다.

Streamlit은 사용자 화면을 담당한다.
FastAPI는 API 요청과 응답을 처리한다.
ONNX 또는 TensorRT는 모델 추론 속도를 최적화한다.
Docker는 실행 환경을 컨테이너로 묶어 배포를 쉽게 만든다.
CORS, HTTPS, 요청 제한 등을 통해 보안을 강화한다.
비동기 처리와 대기 큐를 통해 여러 사용자 요청을 안정적으로 처리한다.
AWS 또는 GCP를 활용해 클라우드 환경에 배포할 수 있다.
로그와 모니터링을 통해 서비스 상태를 지속적으로 확인한다.

결국 AI 서비스 아키텍처는 모델 성능뿐만 아니라
사용자가 안정적으로 서비스를 이용할 수 있는 전체 시스템 구조를 설계하는 과정이라고 볼 수 있다.

FastAPI를 활용한 AI 모델 웹 API 서버 코드 구조

코딩은 내 여친 — Mon, 29 Jun 2026 02:50:09 +0900

AI 모델을 실제 서비스에서 사용하려면 단순히 모델을 실행하는 코드만 작성하는 것이 아니라,
사용자 요청을 받고 모델 추론 결과를 응답하는 API 서버 구조를 만들어야 한다.

FastAPI는 Python 기반의 웹 프레임워크로, AI 모델을 API 형태로 제공할 때 많이 사용된다.
특히 기능별로 코드를 나누면 유지보수와 확장이 쉬워진다.

1. 전체 폴더 구조 예시

FastAPI를 활용한 AI 모델 API 서버는 다음과 같이 구성할 수 있다.

project/
│
├── app/
│   ├── main.py
│   ├── api/
│   │   └── predict.py
│   ├── core/
│   │   └── config.py
│   ├── models/
│   │   └── model_loader.py
│   ├── schemas/
│   │   └── request_response.py
│   └── services/
│       └── predict_service.py
│
├── model/
│   └── sentiment_model.onnx
│
├── requirements.txt
└── README.md

이렇게 기능별로 파일을 분리하면 코드가 길어져도 구조를 이해하기 쉽다.

2. main.py

main.py는 FastAPI 서버가 시작되는 중심 파일이다.
FastAPI 앱을 생성하고, API 라우터를 연결하는 역할을 한다.

예를 들어 /predict 같은 예측 API를 등록하고, 서버가 실행될 수 있도록 구성한다.

from fastapi import FastAPI
from app.api.predict import router as predict_router

app = FastAPI(title="AI Model API")

app.include_router(predict_router)

3. api 폴더

api 폴더는 실제 API 주소를 정의하는 부분이다.
예를 들어 사용자가 /predict 주소로 요청을 보내면 어떤 함수가 실행될지 정한다.

이 파일에서는 요청을 받고, 서비스 로직을 호출한 뒤 결과를 반환한다.

from fastapi import APIRouter
from app.schemas.request_response import PredictRequest, PredictResponse
from app.services.predict_service import predict_text

router = APIRouter()

@router.post("/predict", response_model=PredictResponse)
def predict(request: PredictRequest):
    result = predict_text(request.text)
    return PredictResponse(result=result)

4. schemas 폴더

schemas 폴더는 요청과 응답 데이터의 형태를 정의하는 부분이다.
FastAPI에서는 Pydantic을 사용해 데이터 구조를 명확하게 만들 수 있다.

예를 들어 사용자가 입력해야 하는 값과 서버가 반환할 값을 미리 정해둘 수 있다.

from pydantic import BaseModel

class PredictRequest(BaseModel):
    text: str

class PredictResponse(BaseModel):
    result: str

이렇게 작성하면 잘못된 형식의 요청이 들어왔을 때 오류를 쉽게 확인할 수 있다.

5. models 폴더

models 폴더는 학습된 AI 모델을 불러오는 역할을 한다.
PyTorch, TensorFlow, ONNX 등 어떤 모델을 사용하는지에 따라 로드 방식이 달라질 수 있다.

모델은 요청이 들어올 때마다 새로 불러오면 비효율적이다.
따라서 서버가 시작될 때 한 번만 로드하고, 계속 재사용하는 방식이 좋다.

import onnxruntime as ort

def load_model():
    session = ort.InferenceSession("model/sentiment_model.onnx")
    return session

6. services 폴더

services 폴더는 실제 비즈니스 로직이나 모델 추론 로직을 처리하는 부분이다.
입력 데이터를 전처리하고, 모델에 넣어 예측한 뒤, 결과를 후처리한다.

API 파일에는 요청과 응답 처리만 두고,
실제 예측 로직은 service 파일로 분리하는 것이 좋다.

from app.models.model_loader import load_model

model = load_model()

def predict_text(text: str):
    # 1. 입력 데이터 전처리
    # 2. 모델 추론
    # 3. 결과 후처리

    result = "긍정"
    return result

7. core 폴더

core 폴더는 설정값을 관리하는 부분이다.
예를 들어 모델 경로, 서버 환경, API 설정값 등을 따로 관리할 수 있다.

MODEL_PATH = "model/sentiment_model.onnx"

설정값을 한 곳에서 관리하면 나중에 모델 파일 위치나 서버 환경이 바뀌어도 수정하기 쉽다.

8. 전체 흐름

FastAPI 기반 AI 모델 API 서버의 전체 흐름은 다음과 같다.

사용자가 /predict API로 데이터를 보낸다.
API 라우터가 요청 데이터를 받는다.
schema를 통해 입력 데이터 형식을 확인한다.
service에서 입력 데이터를 전처리한다.
model_loader에서 불러온 모델로 추론한다.
예측 결과를 후처리한다.
사용자에게 JSON 형태로 결과를 반환한다.

정리

FastAPI로 AI 모델을 통합한 웹 API를 구현할 때는 기능별로 코드를 나누는 것이 좋다.

main.py: FastAPI 앱 생성 및 라우터 등록
api: API 주소와 요청 처리
schemas: 요청과 응답 데이터 구조 정의
models: AI 모델 로드
services: 전처리, 추론, 후처리 로직 처리
core: 설정값 관리
model: 학습된 모델 파일 저장

결국 좋은 API 서버 구조는 단순히 코드가 실행되는 것에서 끝나는 것이 아니라,
기능별 역할을 명확히 나누어 유지보수와 확장이 쉬운 형태로 만드는 것이다.

Streamlit을 사용해 AI 모델을 웹 애플리케이션에 통합하는 과정

코딩은 내 여친 — Mon, 29 Jun 2026 02:48:47 +0900

AI 모델을 실제 사용자가 사용할 수 있게 하려면 웹 애플리케이션 형태로 만드는 과정이 필요하다.
Streamlit은 Python 코드만으로 간단하게 웹 화면을 만들 수 있어 AI 모델 실습이나 프로토타입 제작에 많이 사용된다.

Streamlit에서 AI 모델을 웹 애플리케이션에 통합할 때는 보통 다음 세 가지 단계를 거친다.

모델 로드
사용자 입력
결과 출력

1. 모델 로드 단계

모델 로드는 학습이 완료된 AI 모델을 웹 애플리케이션에서 사용할 수 있도록 불러오는 단계이다.

예를 들어 PyTorch 모델이라면 .pth 파일을 불러오고,
ONNX 모델이라면 .onnx 파일을 불러와 추론할 수 있는 상태로 준비한다.

이 단계에서는 모델을 한 번만 불러오도록 처리하는 것이 중요하다.
사용자가 입력할 때마다 모델을 다시 불러오면 속도가 느려지고 자원이 낭비될 수 있기 때문이다.

Streamlit에서는 st.cache_resource 같은 기능을 사용해 모델을 캐싱할 수 있다.
이렇게 하면 앱이 실행되는 동안 모델을 효율적으로 재사용할 수 있다.

2. 사용자 입력 단계

사용자 입력 단계는 사용자가 웹 화면에서 데이터를 입력하는 부분이다.

AI 모델의 종류에 따라 입력 방식은 달라질 수 있다.
이미지 분류 모델이라면 이미지 업로드 기능을 사용할 수 있고,
텍스트 감성 분석 모델이라면 문장을 입력하는 텍스트 박스를 사용할 수 있다.

Streamlit에서는 다음과 같은 입력 기능을 사용할 수 있다.

st.file_uploader: 이미지나 파일 업로드
st.text_input: 짧은 텍스트 입력
st.text_area: 긴 문장 입력
st.slider: 숫자 값 선택
st.button: 버튼 클릭

사용자가 입력한 데이터는 모델이 이해할 수 있는 형태로 전처리해야 한다.
예를 들어 이미지는 크기 조정과 정규화를 하고, 텍스트는 토큰화나 인코딩 과정을 거칠 수 있다.

3. 결과 출력 단계

결과 출력 단계는 모델이 예측한 결과를 사용자에게 보여주는 단계이다.

모델은 보통 숫자나 확률값 형태로 결과를 반환한다.
하지만 사용자가 이해하기 쉽게 클래스 이름, 예측 결과, 확률 등으로 변환해서 보여줘야 한다.

예를 들어 숫자 이미지 분류 모델이라면
“예측 결과: 7”처럼 보여줄 수 있다.

감성 분석 모델이라면
“예측 결과: 긍정” 또는 “예측 결과: 부정”처럼 출력할 수 있다.

Streamlit에서는 st.write, st.success, st.image, st.metric 등을 사용해 결과를 보기 좋게 표시할 수 있다.

4. 전체 흐름

Streamlit에서 AI 모델을 웹 애플리케이션에 통합하는 전체 흐름은 다음과 같다.

학습된 모델 파일을 불러온다.
사용자가 웹 화면에서 데이터를 입력한다.
입력 데이터를 모델에 맞게 전처리한다.
모델이 예측을 수행한다.
예측 결과를 사용자가 이해하기 쉽게 출력한다.

즉, 단순히 모델만 불러오는 것이 아니라
사용자 입력부터 전처리, 추론, 결과 출력까지 하나의 흐름으로 연결해야 한다.

정리

Streamlit을 사용해 AI 모델을 웹 애플리케이션에 통합할 때는 다음 단계를 거친다.

모델 로드: 학습된 모델을 불러와 추론할 수 있는 상태로 준비한다.
사용자 입력: 이미지, 텍스트, 숫자 등 사용자의 데이터를 입력받는다.
전처리: 입력 데이터를 모델이 사용할 수 있는 형태로 변환한다.
결과 출력: 모델의 예측 결과를 사용자가 이해하기 쉽게 보여준다.

결국 Streamlit은 AI 모델을 단순한 코드 실행 결과가 아니라,
사용자가 직접 입력하고 결과를 확인할 수 있는 웹 애플리케이션 형태로 만드는 데 도움을 주는 도구이다.

양자화나 모델 경량화 후 필요한 테스트와 확인 절차

코딩은 내 여친 — Mon, 29 Jun 2026 02:45:04 +0900

딥러닝 모델을 실제 서비스에 적용할 때는 모델을 더 빠르고 가볍게 만들기 위해 양자화나 모델 경량화를 진행한다.
하지만 모델을 줄였다고 해서 바로 서비스에 적용하면 안 된다.

모델 크기와 속도는 좋아졌지만, 정확도나 안정성이 떨어질 수 있기 때문이다.
따라서 경량화 후에는 반드시 여러 가지 테스트와 확인 절차가 필요하다.

1. 기존 모델과 성능 비교하기

가장 먼저 해야 할 일은 경량화 전 모델과 경량화 후 모델의 성능을 비교하는 것이다.

예를 들어 이미지 분류 모델이라면 정확도, F1-score, 오차율 등을 비교할 수 있다.
감성 분석 모델이라면 Accuracy, Precision, Recall, F1-score 같은 지표를 확인할 수 있다.

중요한 것은 단순히 모델이 실행되는지 확인하는 것이 아니라,
기존 모델과 비교했을 때 성능이 얼마나 유지되는지 확인하는 것이다.

2. 실제 데이터와 비슷한 데이터로 테스트하기

테스트 데이터는 실제 서비스에서 들어올 데이터와 비슷해야 한다.

학습 데이터나 정리된 테스트 데이터에서는 성능이 좋아 보여도,
실제 사용자가 입력하는 데이터에서는 성능이 떨어질 수 있다.

예를 들어 이미지 모델이라면 어두운 사진, 흔들린 사진, 배경이 복잡한 사진도 확인해야 한다.
텍스트 모델이라면 오타, 짧은 문장, 긴 문장, 은어 등이 포함된 데이터도 테스트해야 한다.

3. 추론 속도 확인하기

경량화의 목적 중 하나는 추론 속도를 높이는 것이다.
따라서 실제 서비스 환경에서 응답 시간이 얼마나 줄었는지 확인해야 한다.

단순히 개발 환경에서 빠른 것만 확인하면 부족하다.
서버, GPU, CPU, 모바일 기기 등 실제 배포 환경에서 테스트하는 것이 중요하다.

확인할 수 있는 항목은 다음과 같다.

한 번 예측하는 데 걸리는 시간
동시에 여러 요청이 들어왔을 때의 처리 속도
평균 응답 시간
가장 느린 응답 시간

4. 메모리와 자원 사용량 확인하기

모델 경량화 후에는 메모리 사용량과 CPU, GPU 사용량도 확인해야 한다.

모델 크기는 줄었지만 실행 중 메모리 사용량이 크게 줄지 않을 수도 있다.
또는 특정 환경에서는 오히려 변환된 모델이 비효율적으로 실행될 수도 있다.

따라서 실제 서비스 환경에서 모델이 안정적으로 실행되는지 확인해야 한다.

5. 예측 결과가 크게 달라지는 경우 확인하기

경량화 전 모델과 후 모델이 같은 입력에 대해 비슷한 결과를 내는지도 확인해야 한다.

예를 들어 기존 모델은 “긍정”으로 예측했는데,
경량화 후 모델은 같은 문장을 “부정”으로 예측한다면 문제가 될 수 있다.

특히 신뢰도가 낮은 예측이나 애매한 입력에서 결과가 크게 바뀌는지 확인해야 한다.

6. 예외 상황 테스트하기

실제 서비스에서는 항상 정상적인 입력만 들어오지 않는다.
잘못된 형식의 파일, 너무 큰 이미지, 빈 문장, 특수문자만 있는 입력 등이 들어올 수 있다.

이런 예외 상황에서도 모델이나 서비스가 멈추지 않는지 확인해야 한다.
오류가 발생하더라도 사용자에게 적절한 안내가 제공되어야 한다.

7. 실제 서비스 환경에서 모니터링하기

테스트를 통과했더라도 실제 서비스에 배포한 뒤에는 계속 모니터링해야 한다.

서비스 환경에서는 예상하지 못한 데이터가 들어올 수 있고,
시간이 지나면서 사용자 입력 패턴이 달라질 수도 있다.

따라서 배포 후에도 정확도, 응답 시간, 오류율, 서버 자원 사용량 등을 지속적으로 확인하는 것이 좋다.

정리

양자화나 모델 경량화 후에는 다음과 같은 확인 절차가 필요하다.

기존 모델과 정확도 비교하기
실제 서비스 데이터와 비슷한 데이터로 테스트하기
추론 속도 확인하기
메모리와 CPU, GPU 사용량 확인하기
경량화 전후의 예측 결과 비교하기
비정상 입력에 대한 예외 상황 테스트하기
배포 후 지속적으로 모니터링하기

결국 모델 경량화는 단순히 모델을 작고 빠르게 만드는 작업이 아니다.
실제 서비스에서 정확도와 안정성을 유지하면서 사용할 수 있는지 확인하는 과정까지 함께 진행되어야 한다.

양자화 기법인 Post-Training Quantization과 Quantization-Aware Training의 차이

코딩은 내 여친 — Mon, 29 Jun 2026 02:43:38 +0900

딥러닝 모델을 실제 서비스에 배포할 때는 모델의 크기와 추론 속도가 중요하다.
이때 사용하는 대표적인 최적화 기법 중 하나가 양자화(Quantization) 이다.

양자화는 모델의 가중치나 연산에 사용되는 숫자의 정밀도를 낮추는 방법이다.
예를 들어 FP32 형식의 값을 INT8처럼 더 가벼운 형식으로 바꾸면 모델 크기와 연산량을 줄일 수 있다.

양자화 방식에는 대표적으로 Post-Training Quantization(PTQ) 과 Quantization-Aware Training(QAT) 이 있다.

1. Post-Training Quantization이란?

Post-Training Quantization은 말 그대로 학습이 끝난 모델을 나중에 양자화하는 방식이다.

이미 학습이 완료된 모델을 가져와서 추가 학습 없이 가중치나 연산 정밀도를 낮춘다.
따라서 적용 과정이 비교적 간단하고 빠르다.

PTQ는 모델을 빠르게 경량화하고 싶을 때 많이 사용된다.
하지만 모델에 따라 양자화 후 정확도가 떨어질 수 있다.

2. Quantization-Aware Training이란?

Quantization-Aware Training은 학습 과정에서 양자화가 적용될 상황을 미리 반영하는 방식이다.

모델을 학습할 때부터 낮은 정밀도로 계산되는 상황을 가정한다.
그래서 실제 양자화 후에도 정확도 손실이 적도록 모델이 적응하게 된다.

QAT는 PTQ보다 과정이 복잡하고 시간이 더 걸린다.
하지만 정확도를 더 잘 유지할 수 있다는 장점이 있다.

3. 두 방식의 차이

PTQ와 QAT의 가장 큰 차이는 양자화를 언제 반영하느냐이다.

PTQ는 학습이 끝난 뒤에 양자화를 적용한다.
반면 QAT는 학습 과정에서부터 양자화를 고려한다.

즉, PTQ는 빠르고 간단하지만 정확도 손실이 생길 수 있고,
QAT는 시간이 더 걸리지만 정확도 유지에 더 유리하다.

4. 언제 어떤 방식을 사용할까?

빠르게 모델을 배포하거나 정확도 손실이 크지 않은 경우에는 PTQ를 사용할 수 있다.
반대로 정확도가 중요한 서비스이거나 PTQ 적용 후 성능 저하가 크다면 QAT를 고려하는 것이 좋다.

예를 들어 간단한 이미지 분류 모델은 PTQ만으로도 충분할 수 있다.
하지만 자율주행, 의료 이미지 분석, 보안 시스템처럼 정확도가 중요한 분야에서는 QAT가 더 적합할 수 있다.

정리

Post-Training Quantization과 Quantization-Aware Training의 차이는 다음과 같다.

PTQ는 학습이 끝난 모델을 나중에 양자화하는 방식이다.
QAT는 학습 과정에서 양자화를 미리 고려하는 방식이다.
PTQ는 적용이 빠르고 간단하다.
QAT는 시간이 더 걸리지만 정확도 유지에 유리하다.
정확도 손실이 작으면 PTQ, 정확도가 중요하면 QAT를 고려할 수 있다.

결국 PTQ와 QAT는 모두 모델을 가볍고 빠르게 만들기 위한 양자화 기법이다.
다만 PTQ는 간단한 배포 최적화에 적합하고, QAT는 정확도까지 안정적으로 유지해야 하는 상황에 더 적합하다.

딥러닝 모델을 ONNX, TensorRT 등의 포맷으로 변환해야 하는 이유

코딩은 내 여친 — Mon, 29 Jun 2026 02:43:00 +0900

딥러닝 모델을 학습할 때는 보통 PyTorch, TensorFlow 같은 프레임워크를 사용한다.
하지만 실제 서비스에 모델을 적용할 때는 학습한 그대로 사용하는 것보다 ONNX, TensorRT 같은 포맷으로 변환하는 경우가 많다.

그 이유는 모델을 더 빠르고 가볍게 실행하기 위해서이다.

1. 다양한 환경에서 모델을 실행하기 위해

PyTorch로 학습한 모델은 기본적으로 PyTorch 환경이 있어야 실행할 수 있다.
하지만 실제 서비스에서는 서버, 웹, 모바일, 임베디드 기기 등 다양한 환경에서 모델을 실행해야 한다.

ONNX는 서로 다른 딥러닝 프레임워크 사이에서 모델을 호환할 수 있게 해주는 중간 포맷이다.
즉, PyTorch에서 만든 모델을 ONNX로 변환하면 다른 실행 환경에서도 비교적 쉽게 사용할 수 있다.

2. 추론 속도를 높이기 위해

모델을 서비스에 적용할 때 중요한 것은 학습이 아니라 추론 속도이다.
사용자가 이미지를 업로드하거나 문장을 입력했을 때 결과가 빠르게 나와야 한다.

TensorRT는 NVIDIA GPU에서 모델이 더 빠르게 실행되도록 최적화해주는 도구이다.
불필요한 연산을 줄이고, GPU에 맞게 계산 과정을 최적화하여 추론 속도를 높일 수 있다.

3. 모델 용량과 연산 비용을 줄이기 위해

딥러닝 모델은 크기가 크고 연산량이 많을 수 있다.
이 경우 서버 비용이 증가하거나, 모바일·엣지 디바이스에서 실행하기 어려울 수 있다.

ONNX나 TensorRT로 변환하는 과정에서 모델 구조를 최적화하거나 정밀도를 낮추는 방식으로 용량과 연산량을 줄일 수 있다.
예를 들어 FP32를 FP16이나 INT8로 바꾸면 더 적은 자원으로 모델을 실행할 수 있다.

4. 실제 서비스 배포에 적합하게 만들기 위해

연구나 실습 단계에서는 모델이 정확히 동작하는 것이 중요하다.
하지만 실제 서비스에서는 속도, 비용, 안정성, 호환성도 중요하다.

모델 포맷 변환은 학습한 모델을 실서비스 환경에 맞게 준비하는 과정이다.
즉, 단순히 모델을 만드는 것에서 끝나는 것이 아니라, 실제 사용자가 빠르고 안정적으로 사용할 수 있도록 배포하기 위한 단계라고 볼 수 있다.

정리

딥러닝 모델을 ONNX, TensorRT 등의 포맷으로 변환하는 이유는 다음과 같다.

다양한 환경에서 실행하기 위해
추론 속도를 높이기 위해
모델 용량과 연산 비용을 줄이기 위해
실제 서비스 배포에 적합하게 만들기 위해

결국 모델 변환은 딥러닝 모델을 단순한 실험 결과가 아니라, 실제 서비스에서 사용할 수 있는 형태로 만드는 중요한 과정이다.

Docker 이미지와 컨테이너, Docker Compose, Kubernetes 개념 정리

코딩은 내 여친 — Fri, 12 Jun 2026 22:38:57 +0900

Docker를 공부하다 보면 가장 먼저 헷갈리는 개념이 있습니다. 바로 이미지(Image)와 컨테이너(Container)입니다. 여기에 조금 더 나아가면 Docker Compose와 Kubernetes라는 개념도 등장합니다.

처음에는 모두 비슷해 보이지만, 실제 역할은 서로 다릅니다. 이번 글에서는 Docker 이미지와 컨테이너의 차이, Docker Compose가 유용한 상황, 그리고 Kubernetes가 Docker와 어떤 관계를 가지는지 정리해보겠습니다.

1. Docker 이미지와 컨테이너의 차이

Docker 이미지는 애플리케이션을 실행하기 위해 필요한 파일, 라이브러리, 실행 환경, 설정 등을 하나로 묶어 놓은 실행 템플릿입니다.

반면 Docker 컨테이너는 이 이미지를 바탕으로 실제 실행된 프로세스 환경입니다.

쉽게 비유하면 다음과 같습니다.

구분	비유	설명
이미지	설계도 또는 실행 파일	컨테이너를 만들기 위한 읽기 전용 템플릿
컨테이너	실제 실행 중인 프로그램	이미지를 기반으로 실행된 독립적인 환경

예를 들어 nginx 이미지는 Nginx 서버를 실행하기 위한 파일과 설정을 포함하고 있습니다. 이 이미지를 docker run 명령어로 실행하면 실제 Nginx 서버가 동작하는 컨테이너가 만들어집니다.

docker pull nginx
docker run -d -p 8080:80 nginx

위 명령어에서 nginx는 이미지이고, docker run을 통해 실행된 결과물이 컨테이너입니다.

이미지는 직접 실행되는 것이 아니라, 컨테이너를 만들기 위한 기반입니다. 하나의 이미지로 여러 개의 컨테이너를 만들 수도 있습니다.

예를 들어 같은 nginx 이미지로 3개의 컨테이너를 실행하면, 모두 같은 기본 환경을 가지지만 각각 독립적으로 동작합니다.

이미지와 컨테이너의 핵심 차이

이미지는 정적인 파일 묶음이고, 컨테이너는 동적으로 실행 중인 환경입니다.

이미지는 읽기 전용에 가깝고, 컨테이너는 실행 중에 로그, 임시 파일, 프로세스 상태 같은 변경 사항을 가질 수 있습니다. 다만 컨테이너 내부의 변경 사항은 기본적으로 컨테이너가 삭제되면 함께 사라질 수 있기 때문에, 데이터를 유지하려면 볼륨을 사용해야 합니다.

2. Docker Compose는 어떤 상황에서 유용할까?

Docker Compose는 여러 개의 컨테이너로 구성된 애플리케이션을 쉽게 정의하고 실행할 수 있게 해주는 도구입니다.

일반적으로 실제 서비스는 컨테이너 하나만으로 구성되지 않습니다. 예를 들어 웹 애플리케이션을 만든다고 하면 다음과 같은 구성 요소가 필요할 수 있습니다.

웹 서버
백엔드 API 서버
데이터베이스
Redis 같은 캐시 서버

이런 구성 요소를 각각 docker run 명령어로 실행할 수도 있지만, 컨테이너가 많아질수록 명령어가 길어지고 관리가 어려워집니다.

이때 Docker Compose를 사용하면 여러 컨테이너의 실행 설정을 compose.yaml 파일 하나에 정리할 수 있습니다.

예를 들어 다음과 같은 구성을 생각해볼 수 있습니다.

services:
  app:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db

  db:
    image: mysql:8.3.0
    environment:
      MYSQL_ROOT_PASSWORD: pw_root
      MYSQL_DATABASE: app_db

이렇게 작성한 뒤 아래 명령어 하나로 여러 컨테이너를 한 번에 실행할 수 있습니다.

docker compose up -d

종료할 때도 다음 명령어 하나면 됩니다.

docker compose down

Docker Compose가 유용한 상황

Docker Compose는 특히 다음과 같은 상황에서 유용합니다.

첫째, 여러 컨테이너를 함께 실행해야 할 때 유용합니다. 예를 들어 FastAPI 서버와 MySQL 데이터베이스를 함께 실행해야 한다면 Compose 파일에 두 서비스를 함께 정의할 수 있습니다.

둘째, 개발 환경을 팀원들과 동일하게 맞추고 싶을 때 유용합니다. compose.yaml 파일을 프로젝트에 포함하면, 다른 팀원도 같은 설정으로 컨테이너를 실행할 수 있습니다.

셋째, 컨테이너 실행 명령어를 반복해서 입력하지 않아도 됩니다. 포트, 볼륨, 환경 변수, 네트워크 설정 등을 파일에 정리해두면 명령어가 훨씬 단순해집니다.

3. Dockerfile과 Docker Compose의 차이

Dockerfile과 Docker Compose는 둘 다 Docker에서 자주 사용되지만, 목적이 다릅니다.

Dockerfile은 이미지를 만드는 파일입니다. 즉, 애플리케이션을 어떤 환경에서 실행할지 정의합니다.

예를 들어 Python 애플리케이션 이미지를 만들기 위한 Dockerfile은 다음과 같이 작성할 수 있습니다.

FROM python:3.11

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["python", "app.py"]

이 Dockerfile은 Python 환경을 준비하고, 필요한 패키지를 설치한 뒤, 애플리케이션을 실행하는 이미지를 만들기 위한 파일입니다.

반면 Docker Compose는 여러 컨테이너를 어떻게 실행할지 정의하는 파일입니다. 이미지를 직접 만들 수도 있고, 이미 만들어진 이미지를 가져와서 실행할 수도 있습니다.

정리하면 다음과 같습니다.

구분	Dockerfile	Docker Compose
목적	Docker 이미지 생성	여러 컨테이너 실행 및 관리
파일명	Dockerfile	compose.yaml 또는 docker-compose.yml
주요 역할	실행 환경 정의	서비스, 네트워크, 볼륨, 환경 변수 관리
사용 명령어	docker build	docker compose up
예시	Python 앱 이미지 만들기	Python 앱 + MySQL 함께 실행하기

즉, Dockerfile은 “이미지를 어떻게 만들 것인가?”에 대한 답이고, Docker Compose는 “여러 컨테이너를 어떻게 함께 실행할 것인가?”에 대한 답입니다.

4. Kubernetes의 기본 개념

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하기 위한 컨테이너 오케스트레이션 플랫폼입니다.

Docker가 컨테이너를 만들고 실행하는 데 초점이 있다면, Kubernetes는 여러 서버에 걸쳐 수많은 컨테이너를 안정적으로 운영하는 데 초점이 있습니다.

예를 들어 서비스 사용자가 많아지면 컨테이너를 여러 개로 늘려야 합니다. 특정 컨테이너가 장애로 종료되면 다시 실행해야 합니다. 여러 서버에 컨테이너를 분산 배치해야 할 수도 있습니다.

이런 작업을 사람이 직접 관리하면 복잡하고 실수하기 쉽습니다. Kubernetes는 이런 작업을 자동화하는 역할을 합니다.

Kubernetes의 주요 개념

Kubernetes에서는 컨테이너를 직접 하나씩 관리하기보다는, 여러 추상화된 리소스를 통해 관리합니다.

가장 기본이 되는 개념은 Pod입니다.

Pod는 Kubernetes에서 배포할 수 있는 가장 작은 실행 단위입니다. 하나의 Pod 안에는 하나 이상의 컨테이너가 들어갈 수 있습니다. 보통은 하나의 Pod에 하나의 애플리케이션 컨테이너를 넣는 방식이 많이 사용됩니다.

Deployment는 Pod를 원하는 개수만큼 유지하고, 업데이트를 관리하는 역할을 합니다. 예를 들어 “내 웹 서버 Pod를 항상 3개 실행해줘”라고 설정하면 Kubernetes는 실제 상태를 계속 확인하면서 Pod 개수를 맞추려고 합니다.

Service는 Pod에 접근할 수 있는 고정된 네트워크 진입점을 제공합니다. Pod는 언제든 새로 생성되거나 삭제될 수 있기 때문에 IP가 바뀔 수 있습니다. Service는 이런 Pod들을 묶어서 안정적으로 접근할 수 있게 해줍니다.

Node는 실제 컨테이너가 실행되는 서버입니다. 여러 Node가 모여 Cluster를 구성합니다.

정리하면 다음과 같습니다.

개념	설명
Cluster	Kubernetes가 관리하는 전체 서버 묶음
Node	컨테이너가 실제로 실행되는 서버
Pod	Kubernetes의 가장 작은 실행 단위
Deployment	Pod의 배포, 복제, 업데이트 관리
Service	Pod에 접근하기 위한 네트워크 진입점

5. Kubernetes와 Docker의 관계

Docker와 Kubernetes는 경쟁 관계라기보다는 역할이 다른 도구입니다.

Docker는 컨테이너 이미지를 만들고 컨테이너를 실행하는 데 사용됩니다. 개발자는 Dockerfile을 작성해서 이미지를 만들고, 이 이미지를 Docker Hub 같은 이미지 저장소에 올릴 수 있습니다.

Kubernetes는 이렇게 만들어진 컨테이너 이미지를 가져와서 여러 서버에 배포하고 운영합니다.

흐름으로 보면 다음과 같습니다.

Dockerfile을 작성한다.
Docker 이미지로 빌드한다.
이미지를 Docker Hub 같은 Registry에 업로드한다.
Kubernetes가 해당 이미지를 가져와 Pod로 실행한다.
Deployment와 Service를 통해 컨테이너를 안정적으로 운영한다.

즉, Docker는 컨테이너 이미지를 만들고 실행하는 개발 및 실행 도구에 가깝고, Kubernetes는 컨테이너를 대규모 환경에서 운영하기 위한 관리 플랫폼에 가깝습니다.

정리

Docker 이미지와 컨테이너, Docker Compose, Kubernetes는 모두 컨테이너 기반 개발과 배포에서 중요한 개념입니다.

Docker 이미지는 컨테이너 실행을 위한 템플릿이고, 컨테이너는 이미지를 기반으로 실제 실행된 환경입니다.

Dockerfile은 이미지를 만들기 위한 파일이고, Docker Compose는 여러 컨테이너를 한 번에 실행하고 관리하기 위한 도구입니다.

Kubernetes는 여러 서버 환경에서 컨테이너를 자동으로 배포하고, 확장하고, 복구하고, 관리하는 오케스트레이션 플랫폼입니다.

개발 단계에서는 Dockerfile과 Docker Compose를 많이 사용하고, 운영 환경이나 대규모 서비스에서는 Kubernetes를 사용하는 경우가 많습니다.

처음에는 개념이 비슷해 보여 헷갈릴 수 있지만, 다음과 같이 기억하면 이해하기 쉽습니다.

도구/개념	한 줄 요약
Docker Image	컨테이너를 만들기 위한 실행 템플릿
Docker Container	이미지를 기반으로 실행된 독립 환경
Dockerfile	이미지를 만드는 방법을 적은 파일
Docker Compose	여러 컨테이너를 한 번에 실행하는 도구
Kubernetes	여러 컨테이너를 자동으로 배포하고 운영하는 플랫폼

결국 Docker는 컨테이너를 만들고 실행하는 기반 기술이고, Docker Compose는 여러 컨테이너를 편리하게 실행하는 도구이며, Kubernetes는 컨테이너를 실제 운영 환경에서 안정적으로 관리하기 위한 플랫폼이라고 볼 수 있습니다.

RAG 시스템 'Agent' 개념 및 구현 방법

코딩은 내 여친 — Sat, 2 May 2026 16:53:43 +0900

최근 RAG 시스템은 단순한 검색 → 생성 구조를 넘어서,
스스로 판단하고 도구를 선택하는 Agent 기반 구조로 발전하고 있습니다.

특히 LangChain, LangGraph, LlamaIndex 같은 프레임워크에서는
Agent가 전체 RAG 흐름을 제어하는 핵심 컴포넌트 역할을 합니다.

Agent 기반 RAG 구조 한눈에 보기

핵심 차이:

기존 RAG → 정해진 순서대로 동작 (Pipeline)
Agent 기반 RAG → 상황에 따라 스스로 행동을 결정

즉,

RAG는 정보를 가져오고, Agent는 어떻게 가져올지 결정한다

RAG에서 Agent란 무엇인가?

정의

Agent는 문제를 해결하기 위해

어떤 작업을 할지 결정하고
어떤 도구를 사용할지 선택하며
필요하면 여러 단계를 반복 수행하는
의사결정 중심 컴포넌트입니다.

예를 들어:

사용자 질문:

"우리 회사 매출 데이터를 분석해서 다음 분기 예측해줘"

Agent는 이렇게 판단합니다.

DB 조회 필요
데이터 분석 필요
결과 요약 필요

그리고 실제로:

SQL 실행
Python 실행
결과 요약

이 과정을 자동으로 수행합니다.

기존 RAG vs Agent 기반 RAG

구분	기존 RAG	Agent 기반 RAG
구조	고정된 흐름	동적 결정
역할	검색 + 생성	계획 + 실행
판단	없음	있음
반복 실행	불가능	가능
도구 사용	제한적	자유롭게 선택

핵심 요약:

Agent는 "생각하고 행동하는 RAG"라고 보면 됩니다

RAG에서 Agent가 필요한 이유

이유 1 — 복잡한 질문 처리

"2023년 매출 감소 원인 분석하고 경쟁사와 비교해줘"

이건 한 번의 검색으로 해결 불가능합니다.

필요한 단계:

내부 데이터 검색
외부 데이터 검색
비교 분석
결과 생성

Agent는 이 과정을 단계적으로 계획할 수 있습니다.

연구에서도 복잡한 multi-step 질의에서는 여러 Agent가 협력하는 구조가 더 높은 정확도를 보였습니다.

이유 2 — Tool 사용 자동화

Agent는 다음과 같은 도구를 자동으로 선택할 수 있습니다.

Vector DB
Web Search
Calculator
Python
API
Database

LLM이 단순히 답변하는 것이 아니라
실제로 작업을 수행하는 시스템이 됩니다.

이유 3 — 반복적 개선 (Loop)

Agent는 필요하면 작업을 다시 수행할 수 있습니다.

검색
결과 확인
부족하면 재검색

이 구조는 정확도 개선에 매우 중요합니다.

실제로 Agent 기반 RAG는 계획, 도구 사용, 검증 반복을 통해 시스템 신뢰성을 높일 수 있습니다.

Agent의 핵심 구성 요소

Agent는 보통 다음 4가지 요소로 구성됩니다.

1) LLM — 판단 엔진

역할:

무엇을 할지 결정
다음 행동 선택

예:

검색할지
계산할지
답변할지

한 줄 요약:

Agent의 두뇌

2) Tools — 실행 도구

Retriever
Web Search
Python
Database
API

Agent는 상황에 따라 도구를 선택합니다.

"현재 환율 알려줘"

Agent 행동:

→ Web Search 호출

3) Memory — 기억

역할:

이전 대화 저장
중간 결과 저장
상태 관리

종류:

Short-term memory
Long-term memory

한 줄 요약:

Agent의 기억

4) Planning — 계획

역할:

작업 순서 결정
단계 분할

"논문 요약하고 주요 키워드 추출해줘"

Plan:

문서 읽기
요약 생성
키워드 추출

한 줄 요약:

Agent의 전략

RAG Agent는 실제로 어떻게 구현하는가?

여기서는 가장 대표적인 방법인
LangChain 기반 구현 흐름을 기준으로 설명합니다.

Step 1 — Tool 정의

def retrieve(query):
return vector_db.search(query)

즉,

검색 기능을 Tool로 등록합니다.

Step 2 — Agent 생성

from langchain.agents import create_agent

agent = create_agent(
model="gpt-4",
tools=[retrieve]
)

이렇게 생성된 Agent는 필요할 때 자동으로 검색 도구를 호출합니다.

LangChain 공식 문서에서도 Agent는 검색 도구를 실행해 RAG 흐름을 제어하는 오케스트레이터 역할을 한다고 설명합니다.

Step 3 — Agent 실행

response = agent.run(
"LangChain의 Agent 구조를 설명해줘"
)

이때 내부에서는:

질문 분석
검색 필요 여부 판단
Tool 실행
답변 생성

이 과정이 자동으로 수행됩니다.

가장 많이 사용되는 Agent 구현 방식

1) Single Agent

구조:

User
→ Agent
→ Tools

특징:

가장 단순
구현 쉬움

2) Multi-Agent

구조:

User
→ Supervisor Agent
→ 여러 Agent

예:

Retrieval Agent
Analysis Agent
Summary Agent

특징:

복잡한 작업에 적합
확장성 높음

3) Agentic RAG (최신 트렌드)

구조:

User
→ Agent
→ 반복 검색 + 검증

특징:

기존 RAG보다 정확도 높음
복잡한 질의 처리 가능

정리

Agent 정의

Agent는 문제 해결을 위해 스스로 계획하고, 도구를 선택하고, 작업을 실행하는 시스템이다

Agent 역할

작업 계획 (Planning)
도구 선택 (Tool selection)
작업 실행 (Action)
결과 검증 (Loop)

Agent 구현 핵심

Tool 정의
Agent 생성
Agent 실행

RAG는 정보를 찾고, Agent는 문제를 해결한다

RAG 시스템 성능 독립 평가 vs 종단간 평가

코딩은 내 여친 — Sat, 2 May 2026 14:18:09 +0900

RAG 시스템은 단순히 정답을 맞추는지만 보는 것이 아니라,
검색이 잘 되었는지와 최종 답변이 적절한지를 각각 평가해야 합니다.

그래서 보통 평가 방법은 크게 두 가지로 나뉩니다.

독립 평가 (Component-level Evaluation)
종단간 평가 (End-to-End Evaluation)

RAG 평가 구조 한눈에 보기

핵심은 간단합니다.

검색 단계와 생성 단계를 나눠서 볼 것인가, 전체 결과만 볼 것인가의 차이

독립 평가 (Independent Evaluation)

의미
RAG의 각 구성 요소를 따로따로 평가하는 방식입니다.

즉,

검색 성능은 검색만 평가
생성 성능은 생성만 평가

이렇게 분리해서 분석합니다.

(1) Retrieval 평가 — 검색이 잘 되었는지 확인

대표 지표:

Precision — 가져온 문서 중 정답 비율
Recall — 필요한 문서를 얼마나 놓치지 않았는지
MRR (Mean Reciprocal Rank) — 정답 문서가 상위에 있는지
Hit Rate — 정답 문서가 포함되었는지

예시 질문:

정답 문서를 Top-5 안에 가져왔는가?

핵심 포인트

검색 품질을 정확히 파악 가능
문제 원인을 찾기 쉬움
RAG 튜닝에 필수

한 줄 정리

검색과 생성 성능을 각각 따로 평가하는 방식

(2) Generation 평가 — 답변 품질 평가

대표 지표:

BLEU
ROUGE
F1 Score
Exact Match

최근 많이 사용하는 방식:

LLM-as-a-Judge
Human Evaluation

예시 평가 항목:

정확성 (Accuracy)
관련성 (Relevance)
자연스러움 (Fluency)
근거 기반 여부 (Groundedness)

한 줄 정리

답변 자체의 품질을 평가하는 방식

종단간 평가 (End-to-End Evaluation)

RAG 시스템을 하나의 시스템으로 보고 전체 결과만 평가하는 방식입니다.

즉,

질문 → 검색 → 생성 → 최종 답변
이 전체 과정을 한 번에 평가

대표 평가 방법

1) 정답 기반 평가 (Ground Truth 기반)

예시:

질문
→ "대한민국 수도는?"

정답
→ "서울"

모델 답변
→ "서울"

이 경우:

Accuracy = 100%

2) 사용자 중심 평가 (User-level Evaluation)

예시 지표:

Answer Accuracy
Helpfulness
User Satisfaction
Task Success Rate

실무 서비스에서는 이 지표가 매우 중요합니다.

종단간 평가 특징

실제 사용자 경험을 가장 잘 반영
서비스 품질 확인에 필수
문제 원인 분석은 어려움

한 줄 정리

전체 시스템 결과만 평가하는 방식

독립 평가 vs 종단간 평가 차이

구분	독립 평가	종단간 평가
평가 대상	개별 구성 요소	전체 시스템
목적	문제 원인 분석	실제 성능 확인
예시	Recall, MRR	Accuracy, User Satisfaction
활용 단계	개발 / 튜닝	서비스 운영
장점	디버깅 쉬움	현실 반영
단점	사용자 경험 반영 어려움	원인 분석 어려움

정리

RAG 평가에서는 두 가지를 반드시 함께 사용합니다.

이유:

독립 평가 → 어디가 문제인지 찾기 위해
종단간 평가 → 전체 서비스 품질을 확인하기 위해

즉,

튜닝할 때는 독립 평가, 서비스 품질 확인은 종단간 평가

LangChain으로 RAG 시스템 구축 시 필요한 주요 구성 요소와 역할

코딩은 내 여친 — Sat, 2 May 2026 11:31:16 +0900

RAG(Retrieval-Augmented Generation)는 외부 지식을 검색(Retrieval)한 뒤,

이를 기반으로 답변을 생성(Generation) 하는 구조입니다.
특히 LangChain을 사용하면 이 과정을 모듈 형태로 쉽게 구성할 수 있어,

챗봇·문서 검색 시스템·사내 지식 시스템 등에 널리 활용됩니다.

RAG 시스템 전체 구조

RAG 시스템은 보통 다음 흐름으로 동작합니다.

문서 → 임베딩 → 벡터DB 저장 → 질문 입력 → 관련 문서 검색 → LLM 답변 생성

이 과정을 구성하는 핵심 요소들을 하나씩 살펴보겠습니다.

Document Loader (문서 로더)

역할:
외부 데이터를 시스템으로 불러오는 단계입니다.

예시 데이터

PDF
Word / Excel
웹페이지
데이터베이스
텍스트 파일

핵심 포인트

다양한 형식의 문서를 통합 처리
RAG의 시작점
데이터 소스 연결 역할

한 줄 정리

데이터를 시스템으로 가져오는 역할

Text Splitter (텍스트 분할기)

역할:
긴 문서를 작은 단위(Chunk)로 나누는 단계입니다.

왜 필요할까요?

LLM은 긴 문서를 한 번에 처리하기 어려움
검색 정확도를 높이기 위해
임베딩 성능 향상을 위해

예시

원본 문서
→ 10,000자

분할 후
→ 500자 × 여러 개

한 줄 정리

문서를 검색하기 좋은 크기로 나누는 역할

Embedding Model (임베딩 모델)

역할:
텍스트를 숫자 벡터(Vector)로 변환합니다.

이 과정이 중요한 이유:

컴퓨터는 의미를 이해하지 못하기 때문에
문장의 의미를 수치로 표현해야 합니다.

예시 모델

OpenAI Embeddings
Sentence Transformers
BGE
E5

한 줄 정리

텍스트를 의미 기반 숫자로 변환하는 역할

Vector Store (벡터 데이터베이스)

역할:
임베딩된 데이터를 저장하고 검색하는 데이터베이스입니다.

일반 DB와 다른 점:

의미 기반 검색 (Semantic Search) 가능
비슷한 문서를 빠르게 찾음

대표적인 벡터 DB

FAISS
Chroma
Pinecone
Weaviate

한 줄 정리

비슷한 문서를 찾기 위해 벡터를 저장하는 곳

Retriever (검색기)

역할:
사용자의 질문과 가장 관련 있는 문서를 찾아오는 단계입니다.

동작 방식:

질문을 임베딩으로 변환
벡터 DB에서 유사한 문서 검색
상위 k개 문서 반환

핵심 포인트

RAG 성능의 핵심 요소
검색 품질이 답변 품질을 결정

한 줄 정리

질문과 가장 관련 있는 문서를 찾는 역할

LLM (Large Language Model)

역할:
검색된 문서를 기반으로 최종 답변을 생성합니다.

여기서 중요한 점:

LLM은 외부 지식을 직접 학습하지 않아도,
검색된 정보를 활용해 정확한 답변을 생성할 수 있습니다.

예시 모델

GPT
Claude
Llama
Gemini

한 줄 정리

검색된 정보를 바탕으로 답변을 만드는 역할

정리

RAG 시스템의 주요 구성 요소는 다음 6가지입니다.

Document Loader — 데이터를 불러옴
Text Splitter — 문서를 작은 단위로 나눔
Embedding Model — 텍스트를 벡터로 변환
Vector Store — 벡터를 저장하고 검색
Retriever — 관련 문서를 찾음
LLM — 답변을 생성