개발 블로그

클로드 텐엑스: 10배 더 스마트한 직장인을 위한 <클로드로 AI 에이전트 만들기> 수강 후기

goodella — Sun, 12 Jul 2026 21:24:05 +0900

본 포스팅은 10x 체험단 활동의 일환으로 강의 수강권을 제공받아 작성한 후기입니다.

안녕하세요! 코드잇 10x(코드잇 텐엑스) 체험단으로 참여해서 클로드(Claude) 웹으로 나만의 AI 에이전트를 만들어보는 강의를 듣고 있는 체험단원입니다. 어느새 2주차 성장 기록을 남길 때가 되었네요. 이번 주에 배운 내용과 직접 실습하면서 느낀 점들을 솔직하게 정리해보려고 합니다.

이번주, 내가 배운 핵심

이번 주의 가장 큰 수확은 클로드의 스킬(Skill)과 커넥터(Connector) 기능이었습니다. 그동안은 클로드를 그냥질문하면 답해주는 챗봇정도로만 생각했는데, 구글 드라이브 커넥터를 연결하니 클로드가 제 드라이브 안의 실제 문서를 직접 읽어와서 업무에 활용할 수 있다는 걸 알게 됐어요.

1.실습 미션으로 customer-email-reply라는 이름의 개인 스킬을 직접 만들어봤습니다. 이 스킬은고객 문의 이메일에 답장을 작성해줘 같은 트리거가 들어오면, 자동으로 아래와 같은 흐름으로 동작하도록 설계했어요.

고객 이메일 내용을 파악해서 문의 유형(불량/교환/환불/A/S 등)과 고객 정보를 정리
구글 드라이브에 있는 주문 내역 시트를 read_file_content로 조회해서 주문번호, 제품명, 구매일, 배송 상태 확인
동일 고객의 주문이 여러 건이면 전부 확인하고, 이메일에 이름이 없으면 이름으로 매칭 시도
제품 정보, 환불/교환 정책, 고객 상황을 종합해 전략이 다른 2가지 답장 초안을 생성

실제로 미니 공기청정기 소음 문의와 스마트 텀블러 환불 요청 두 케이스로 테스트해봤는데, 클로드가 정말 담당자처럼 각 상황에 맞는 톤으로 정중한 답장 두 버전을 뽑아주는 걸 보고 신기했습니다. 단순 변심 환불 기한이 지난 경우와 하자 가능성이 있는 경우를 구분해서 답장 뉘앙스를 다르게 잡아주는 걸 보면서, 이 정도면 실무에 바로 써도 되겠다 싶었어요.

이 외에도 여행 일정을 짜는 실습을 하면서 클로드가 제 취향을 반영한 일정표를 만들어주는 것도 과제를 통해 해봤는데, 확실히 단순 텍스트 답변을 넘어서 실제 결과물(스킬, 문서, 일정)을 만들어내는 방향으로 클로드를 다루는 법을 배운 2주였습니다.

2. 아래는 제가 직접 만들어본 SKILL.md파일 실습 메시지 내역입니다. 팀원에게 계속 물어보는 수고를 덜기 위해 skill로 만들어봤어요.

SKILL name: dvc-gcs description: 팀원이 디스코드(Discord)에 올린 데이터셋 공유 메시지를 분석하여 manifest.json 스펙과 DVC CLI 명령어를 자동 생성하는 스킬. 누락된 정보가 있을 경우 디스코드 답장용 멘션 메시지를 즉시 생성하고 프로세스를 중단(Early Return)한다. 반드시 이 스킬을 사용할 것: 디스코드 메시지를 붙여넣으며 "데이터셋", "GCS", "버킷", "DVC", "올려뒀습니다", "업로드", "manifest" 등의 키워드가 포함된 경우, 혹은 팀원 메시지를 검증하거나 manifest를 만들어달라는 요청.

DVC × GCS 데이터셋 검증 및 Manifest 생성 스킬

디스코드에 올라온 거친(비정형) 데이터셋 공유 메시지를 파싱하여,
정보가 완전하면 manifest.json + DVC CLI를 생성하고,
불완전하면 즉시 디스코드 답장 템플릿을 출력하고 멈춥니다.

1. 엔티티 추출 (Parsing)

입력된 디스코드 메시지에서 아래 3가지 핵심 엔티티를 추출합니다.

필드 설명 유효 예시 모호/누락 예시

dataset_name	데이터셋 식별 이름	알약-v2, pill_classifier	"저번에 말한 거", "그 데이터"
version	SemVer 형식 버전	v2.0.0, v1.3.1	"v2", "최신", "업데이트"
gcs_path	전체 GCS URI	gs://my-bucket/datasets/pill/v2/images/	"gcs 버킷 이미지 폴더", "버킷에 있음"

파싱 규칙:

v2 → 모호 (마이너/패치 불명확) → 누락 처리
v2.0.0 → 유효
"이미지 폴더" 같은 경로 표현 → 모호 → 누락 처리
메시지에서 작성자 이름(A님: 앞부분)도 추출해 멘션에 사용

2. 누락 검사 및 Early Return

추출된 엔티티 중 하나라도 누락·모호하면 즉시 아래 템플릿을 출력하고 프로세스를 종료합니다.
(manifest.json 생성으로 넘어가지 않습니다.)

디스코드 답장 템플릿

@{팀원 이름}님, DVC 버전 관리를 위해 아래 정보가 추가로 필요합니다! 확인 부탁드려요  

{누락된 항목만 기재 — 예시:}
•   버전: SemVer 형식으로 알려주세요 (예: v2.0.0)
•  ️ GCS 경로: 전체 URI를 공유해 주세요 (예: gs://bucket-name/path/to/dataset/)

항목별 누락 메시지 문구:

dataset_name 누락/모호 → • 데이터셋 이름: 어떤 데이터셋인지 정확한 이름을 알려주세요 (예: pill-classifier)
version 누락/모호 → • 버전: SemVer 형식으로 알려주세요 (예: v2.0.0)
gcs_path 누락/모호 → • ️ GCS 경로: 전체 URI를 공유해 주세요 (예: gs://bucket-name/path/to/dataset/)

3. manifest.json 및 DVC CLI 생성

모든 엔티티가 유효한 경우에만 아래를 출력합니다.

3-1. manifest.json

{
  "dataset_name": "{dataset_name}",
  "version": "{version}",
  "gcs_path": "{gcs_path}",
  "created_at": "{오늘 날짜 ISO 8601}",
  "registered_by": "{팀원 이름}"
}

3-2. DVC CLI 명령어 세트

# 1. DVC로 GCS 데이터 추적 등록
dvc import-url {gcs_path} data/{dataset_name}/

# 2. 변경사항 커밋
git add data/{dataset_name}.dvc .gitignore
git commit -m "feat(data): add {dataset_name} {version}"

# 3. DVC 메타데이터 푸시
dvc push

3-3. 완료 확인 메시지 (선택)

팀원에게 복사해서 보낼 수 있는 디스코드 메시지도 함께 제공합니다.

@{팀원 이름}님, 확인했습니다 ✅
{dataset_name} {version} 데이터셋이 DVC에 등록되었습니다.
GCS 경로: {gcs_path}

4. 엣지 케이스 처리 규칙

케이스 처리 방식

"v2" 만 기재	모호 → 누락 처리, 버전 항목 피드백
"저번에 올린 거"	dataset_name 모호 → 누락 처리
"버킷에 있음"	gcs_path 누락 → 피드백
"gs://bucket/path" (트레일링 슬래시 없음)	유효로 처리, 그대로 사용
작성자 이름 없음	멘션 없이 @담당자님 으로 대체
복수 데이터셋 언급	각각 별도로 파싱, 누락 검사 수행

지금까지 달라진 나의 변화

예전에는 AI를 그냥 질문하고 답을 받는 용도정도로 쓰고, 하나의 md파일에 모든 내용을 넣는 편이었는데, 이제는 skill 관련 파일을 쪼개서 AI에게 맥락을 알려주게 되었어요. 또한 CLAUDE의 경우 구글 드라이브 문서와 GMAIL하고 손쉽게 연결지을 수 있어서, 업무자동화하기 더 편리하다고 느껴서 자주 사용하게 되었어요. 막연했던 "AI 에이전트"라는 개념이 이제는 제 손으로 직접 설계하고 테스트할 수 있는 대상으로 느껴지기 시작했어요.

솔직한 아쉬움, 그리고 바라는 점

좋은 점도 있었지만 한 가지 아쉬운 점도 있었는데요. 저는 이 강의를 신청하기 전, 요즘 유튜브나 다른 특강에서 자주 보이는 클로드 코드(Claude Code) CLI를 활용해서 실제 개발 업무나 코드베이스를 자동화하는 실습을 기대하고 있었습니다. 터미널에서 클로드에게 리포지토리를 넘기고, 커밋하고, 테스트까지 돌리는 그런 "개발자를 위한 AI 에이전트" 강의를 상상했거든요.

그런데 실제로 들어보니 이번 커리큘럼은 코딩을 전혀 몰라도 클로드 웹(claude.ai)에서 실습해볼 수 있는 역량을 키우는 데 초점이 맞춰져 있었습니다. 스킬 만들기, 커넥터 연결하기, 이메일·문서 자동화 같은 내용은 분명 유용하고 잘 만들어진 커리큘럼이지만, 개발자 관점에서는 인사이트를 얻는 수준이었지, 처음 기대했던 CLI 기반 개발 자동화와는 결이 조금 달랐어요.

만약 이 강의를 수강하실 분들이시라면 비개발자, 코딩을 아예 모르시는 분들, gpt나 claude를 단순히 채팅을 통해 물어보는 수준으로만 쓰고계신 분들, ai랄 아예 모르는 지인, 가족들이라면 좋을 거 같아요. 실제로 쉽게 설명이 잘 되어있어서 저희 부모님, 동생들한테 추천하고싶더라고요.

그리고 만약 코드잇 10x 팀에서 보고 계신다면, 비개발자용 클로드 웹 실습 강의와는 별도로 클로드 코드 CLI를 활용한 개발자 대상 에이전트 강의도 꼭 만들어주셨으면 좋겠습니다. 실제 레포지토리를 다루고, 터미널에서 에이전트를 붙여 코드 리뷰·리팩터링·테스트 자동화까지 다루는 내용이라면 개발자 지망생이나 현직 개발자들에게 훨씬 더 실무적인 도움이 될 것 같아요.

앞으로 나의 목표

다음에는 이번에 만든 SKILL을 통해 반복적으로 처리하던 문의 유형들을 자동으로 분류하는 단계까지 확장해보고 싶습니다. 그리고 개인적으로는 이번에 배운 내용들을 클로드 코드 CLI 에서는 어떻게 적용하는지 찾아보며 공부를 할 예정입니다. 체험단 기회를 주신 코드잇측에 감사드리며 끝까지 완주해보겠습니다. 파이팅 !!

#코드잇10x #코드잇텐엑스 #클로드 #재피어 #AI에이전트 #AI강의후기 #클로드강의후기

위클리 페이퍼 #17

goodella — Mon, 6 Jul 2026 03:45:42 +0900

1. 모델 서빙(Model Serving)의 본질과 필요성

모델 서빙이란 무엇인가?

학습이 완료된 머신러닝/딥러닝 모델을 파일 형태(e.g., .pth, .onnx, .saved_model)로 방치하지 않고, 외부 애플리케이션이 네트워크(HTTP, gRPC)를 통해 실시간 혹은 배치로 추론(Inference) 결과를 요청하고 받아갈 수 있도록 API 형태로 패키징하여 운영 환경에 노출하는 과정을 말합니다.

왜 필요한가? (기존 소프트웨어와의 차이점)

전통적인 백엔드 애플리케이션은 데이터의 연산 처리가 CPU와 메모리 바운드(Memory-bound) 성격을 띠며 예측 가능한 선형적 흐름을 갖습니다. 반면 ML 추론은 다음과 같은 독특한 제약 조건을 가집니다.

무거운 리소스 집약성 (Heavy Compute-bound): 수천만~수십억 개의 파라미터를 가진 행렬 연산은 CPU만으로 처리가 불가능하거나 극도로 느립니다. GPU 자원의 효율적 배분이 필수적입니다.
컴퓨팅 예측 불가능성: 입력 데이터(이미지 크기, 텍스트 길이)에 따라 연산 병목과 메모리 스파이크(OOM: Out Of Memory)가 빈번히 발생합니다.
동적 가용성 요구: 주기적인 모델 재학습 및 배포가 서비스 중단(Zero-downtime) 없이 이루어져야 합니다.

실제 서비스 환경에서 서빙 프레임워크의 역할

FastAPI나 Flask 같은 범용 웹 프레임워크로도 추론 API를 만들 수는 있습니다. 하지만 트래픽이 몰리는 프로덕션 환경에서 Triton Inference Server, TorchServe, TF Serving 같은 전문 서빙 프레임워크를 도입하는 이유는 명확합니다.

동적 배치 처리 (Dynamic Batching): 개별적으로 들어오는 여러 클라이언트의 요청을 마이크로초 단위로 모아서 하나의 거대한 행렬(Batch)로 묶어 GPU에 전달합니다. GPU는 1개의 요청을 처리할 때와 10개의 요청을 동시에 처리할 때의 속도 차이가 크지 않으므로, 이 기능 하나만으로 처리량(Throughput)이 수배 이상 향상됩니다.
동시 모델 실행 (Concurrent Model Execution): GPU 메모리가 허용하는 한, 동일한 모델의 인스턴스를 여러 개 띄우거나(Multi-instance) 여러 종류의 모델을 동시에 로드하여 내부적으로 요청을 롸우팅 및 병렬 처리합니다.
모델 관리 및 동적 로딩 (Model Repository Control): 서버를 재시작하지 않고도 새로운 버전의 모델 파일만 스토리지에 업로드하면 실시간으로 추론 엔진이 갱신(Hot-reload)됩니다.

2. Streamlit + FastAPI + Triton 아키텍처 설계

프로덕션 MLOps 관점에서 세 가지 기술 스택을 결합할 때, 각 컴포넌트의 책임(Single Responsibility)을 엄격히 분리하는 3-Tier 아키텍처가 가장 바람직합니다.

각 레이어별 역할 분담

Streamlit (Presentation Layer):
- 역할: 사용자 인터페이스(UI) 렌더링, 파일 업로드 컴포넌트 제공, 최종 결과 시각화.
- 금기 사항: 절대 Streamlit 내부에서 비즈니스 로직을 처리하거나 Triton과 직접 통신해서는 안 됩니다. Streamlit은 단일 세션 지향적이며, 무거운 연산이나 복잡한 에러 핸들링을 내포하기에 적합하지 않습니다.
FastAPI (Business Logic & Gateway Layer):
- 역할: 인증/인가, 입력 데이터 유효성 검증(Pydantic), 요청 파싱, DB CRUD 비즈니스 로직 처리, 그리고 Triton으로의 추론 위임 및 결과 가공.
- 통신 프로토콜: 외부(Streamlit)와는 HTTP JSON으로 통신하고, 내부(Triton)와는 고속 효율을 위해 gRPC로 통신합니다.
Triton Inference Server (Inference Layer):
- 역할: 순수 모델 추론 연산 가속화, Dynamic Batching 제어. 다른 어떤 백엔드 로직도 관여하지 않고 오직 오퍼레이션(Tensor in, Tensor out)에만 집중합니다.

디자인 인텐트 (Design Intent) & MLOps 고려사항

엔지니어링 철학: 백엔드와 AI 추론 레이어의 분리는 단순히 '깔끔한 코드'를 위함이 아닙니다. 이것은 컴퓨팅 자원의 격리(Resource Isolation)를 의미합니다. CPU 집약적인 비즈니스 로직(FastAPI)과 GPU 집약적인 모델 연산(Triton)을 물리적/논리적으로 분리해야만, 급격한 트래픽 증가 시 어느 구간에서 병목이 생겼는지 모니터링할 수 있고 독립적인 스케일 아웃(Scale-out)이 가능해집니다.

1. 왜 FastAPI와 Triton 사이에 gRPC를 쓰는가?

Trade-off: HTTP/REST는 JSON 기반이라 가독성이 좋고 디버깅이 쉽지만, 대용량 이미지나 고차원 텐서(Tensor) 데이터를 문자열(Base64 등)로 직렬화/역직렬화하는 과정에서 엄청난 CPU 오버헤드가 발생합니다.
해결책: Triton과는 HTTP 대신 gRPC(Protocol Buffers)를 사용합니다. 데이터가 바이너리 형태로 압축되어 네트워크 패킷 크기가 극적으로 줄어들고, HTTP/2 기반의 멀티플렉싱을 통해 네트워크 지연 시간(Latency)을 최소화할 수 있습니다.

2. 전처리(Preprocessing)와 후처리(Postprocessing)는 어디서 해야 하는가?

Lazy Design (안 좋은 예시): 클라이언트(Streamlit) 단에서 이미지 크기를 (224, 224)로 리사이즈하고 정규화까지 마친 뒤 API 서버로 보내는 방식.
- 비판: 프론트엔드가 모델의 세부 명세(입력 셰이프, 정규화 파라미터 등)를 알게 되므로 강한 결합(Tight Coupling)이 발생합니다. 모델이 업데이트되어 입력 형태가 바뀌면 프론트엔드 코드도 배포해야 하는 재앙이 옵니다.
Best Practice: 전/후처리는 크게 두 가지 방법이 권장됩니다.
1. FastAPI 레이어에서 처리: CPU 바운드 연산(이미지 디코딩, 리사이즈)을 FastAPI가 수행하고 퓨어 텐서 데이터만 Triton에 토스합니다.
2. Triton Ensemble / BLS (Business Logic Scripting) 활용: Triton 내부에 전처리 모델(Python Backend)과 메인 추론 모델(TensorRT/Onnx Runtime)을 파이프라인으로 묶는 방식입니다. 네트워크 구간에는 순수 로우 데이터(e.g., JPEG 바이너리)만 오고 가므로 아키텍처가 가장 깔끔해지며, 대규모 서빙에서 가장 선호되는 방식입니다.

3. 동시성 관리와 서킷 브레이커 (Circuit Breaker)

Race Conditions 및 Bottleneck 예방: Triton이 수용할 수 있는 최대 큐(Queue) 크기를 넘어서는 요청이 들어오면 가용성이 무너집니다.
해결책: FastAPI 게이트웨이 단에 서킷 브레이커를 배치하거나 레디스(Redis) 기반의 메시지 큐를 두어, Triton 시스템 전체가 연쇄적으로 다운(Cascading Failure)되는 현상을 방지해야 합니다.

위클리 페이퍼 #16

goodella — Mon, 29 Jun 2026 01:15:28 +0900

오늘이 마지막 위클리 페이퍼 작성일이라서 기분이 이상하네요. 마지막까지 최선을 다해보도록 하겠습니다.

1. Streamlit을 활용한 AI 모델 통합: Load, Input, Output

Streamlit은 데이터 및 AI 애플리케이션을 빠르게 프로토타이핑할 수 있는 강력한 도구입니다. 하지만 머신러닝 모델을 얹을 때는 상태 관리와 메모리 최적화를 반드시 고려해야 합니다.

import streamlit as st
import torch
from PIL import Image

# 1. 모델 로드 (Model Load)
@st.cache_resource
def load_model():
    # 예시: PyTorch 모델 로드
    model = torch.hub.load('ultralytics/yolov5', 'yolov5s', pretrained=True)
    model.eval()
    return model

model = load_model()

st.title("AI 객체 탐지 애플리케이션")

# 2. 사용자 입력 (User Input)
uploaded_file = st.file_uploader("이미지를 업로드하세요", type=["jpg", "jpeg", "png"])

if uploaded_file is not None:
    image = Image.open(uploaded_file)
    st.image(image, caption="업로드된 이미지", use_column_width=True)
    
    # 3. 결과 출력 (Output)
    if st.button("분석 시작"):
        with st.spinner('AI가 이미지를 분석 중입니다...'):
            results = model(image)
            st.image(results.render()[0], caption="탐지 결과", use_column_width=True)

설계 의도 (Design Intent): @st.cache_resource의 필수성 :

Streamlit은 사용자가 버튼을 누르거나 입력을 변경할 때마다 스크립트를 위에서부터 다시 실행합니다.

만약 @st.cache_resource 데코레이터를 사용하지 않는다면, 매 인터랙션마다 수백 MB에 달하는 모델을 메모리에 다시 올리게 됩니다. 이는 극심한 메모리 누수와 처리 속도 저하를 유발합니다. 따라서 리소스를 캐싱하는 방법을 사용함으로 불필요한 I/O를 줄이고 애플리케이션의 응답성을 보장할 수 있습니다.

2. FastAPI 기반 AI 웹 API 서버 아키텍처

FastAPI를 사용할 때 모든 로직을 main.py에 몰아넣는 것은 지양해야 합니다. 기능별로 계층을 분리해야 유지보수가 쉬워지고, 프론트엔드 개발자에게 일관된 에러 응답과 상태 관리를 제공할 수 있습니다.

fastapi-ai-backend
┣ api
┃ ┣ v1 # API 버전 관리
┃ ┃ ┣ endpoints.py # 라우터(Controller 역할)
┣ core
┃ ┣ config.py      # 환경 변수 및 설정 관리
┃ ┣ security.py    # 인증, CORS 설정
┣ models           # DB 엔티티 (SQLAlchemy 등)
┣ schemas          # Pydantic 모델 (입출력 검증)
┣ repositories     # DB 접근 로직 (Repository Pattern)
┣ services         # 핵심 비즈니스 및 AI 추론 호출 로직
┣ utils            # 로깅, 공통 헬퍼 함수
┗ main.py          # FastAPI 애플리케이션 엔트리포인트

설계 의도 (Design Intent): 계층 분리 및 Repository 패턴 도입

- 백엔드 설계에서 '게으른 구조'란 DB 모델을 API 응답으로 그대로 반환하여 프론트엔드에서 데이터를 파싱하게 만드는 것입니다. 이를 방지하기 위해 Repository 패턴을 도입하여 데이터 접근 로직(repositories/)과 비즈니스 로직(services/)을 분리합니다.

- AI 모델 추론 역시 services/ 계층에서 처리하며, 라우터(api/)는 오직 HTTP 요청/응답의 형태와 상태 코드(Status Code) 관리만 책임집니다. 이 구조는 훗날 N+1 쿼리 문제를 해결하거나 데이터베이스를 교체할 때 다른 계층에 미치는 영향을 최소화합니다.

3. 종합 AI 웹 서비스 아키텍처: 원격 시험 감독 시스템

AI 원격 시험 감독 솔루션을 예시로, 대규모 트래픽을 처리할 수 있는 프로덕션 레벨의 아키텍처를 설계해 보았습니다.

기술 스택 및 아키텍처 상세

AI 추론 및 전처리 파이프라인 (MediaPipe & YOLO)
- 단순 객체 탐지(YOLO) 이전에, MediaPipe를 활용하여 수험자의 얼굴, 코, 눈 랜드마크를 인식하고 영상의 각도를 가로 모드로 강제 보정하는 전처리 단계를 거칩니다. 이를 통해 모델에 입력되는 데이터의 정규화를 보장하여 추론 정확도를 극대화했습니다.
- 응시자가 이탈한 시간(블랙아웃)은 물리적 영상 합성 대신 메타데이터 기반의 스킵(Skip) 로직으로 처리하여 GPU 자원 낭비를 차단했습니다.
비동기 분산 큐와 자원 관리 (FastAPI + Redis + Celery)
- API 요청을 처리하는 동기 작업(FastAPI)과 AI 모델을 돌리는 CPU Bound 비동기 작업(Celery)을 분리하여 Event Loop 블로킹을 방지했습니다.
- 파이썬의 GIL(Global Interpreter Lock) 한계를 극복하기 위해 Celery 워커 내부에서 멀티프로세싱(Multi-processing)을 적용했습니다. 이때, LPT (Longest Processing Time First) 스케줄링 알고리즘을 도입하여 파일 크기가 가장 큰 영상 청크부터 워커에 먼저 할당함으로써 병렬 처리의 병목 현상을 해결했습니다.
스토리지 최적화 (S3 Pre-signed URL & 비디오 청킹)
- 대용량 비디오 파일이 백엔드 서버를 직접 거치지 않도록, FastAPI는 인증된 사용자에게만 S3 Pre-signed URL을 발급합니다.
- 클라이언트는 영상을 청크(Chunk) 단위로 분할하여 S3에 직접 업로드(Direct Upload)함으로써 백엔드 서버의 메모리 오버플로우(OOM)와 네트워크 병목을 완벽히 회피했습니다.
엔터프라이즈급 보안 전략 (AWS Secrets Manager)
- 데이터베이스 접속 정보나 AWS 환경 변수를 코드 저장소나 인스턴스에 하드코딩하지 않고, AWS Secrets Manager를 통해 런타임에 동적으로 주입받아 보안을 유지했습니다.
통합 모니터링 및 로깅 (AWS CloudWatch)
- 분산된 FastAPI 백엔드와 다수의 Celery 워커 노드에서 발생하는 모든 로그는 AWS CloudWatch로 중앙 집중화하여 수집합니다.
- API 에러 추적뿐만 아니라, 멀티프로세싱 환경에서 치명적인 OOM(Out of Memory) 발생 여부 및 메모리 사용량 지표를 실시간으로 모니터링하여 인프라 안정성을 확보했습니다.

설계 의도 (Design Intent):
서드파티 모니터링 툴 대신 CloudWatch를 선택한 이유

외부 툴(Prometheus, Grafana)은 강력한 시각화 기능을 제공하지만, 별도의 인스턴스를 띄우고 지표(Metric) 수집 서버를 유지보수해야 하는 운영 부담이 발생합니다. 시스템 인프라가 AWS 위에서 동작하고 있다면, AWS Native 서비스인 CloudWatch로 로깅 생태계를 통일하는 것이 권한 관리(IAM)와 알람 연동 측면에서 훨씬 효율적이고 안전한 아키텍처 설계라고 생각했습니다.

위클리 페이퍼 #15

goodella — Sun, 21 Jun 2026 23:50:13 +0900

1. 딥러닝 모델을 ONNX, TensorRT 포맷으로 변환하는 이유

PyTorch나 TensorFlow 같은 프레임워크는 '학습(Training)'에 최적화된 무거운 환경입니다. 이를 그대로 프로덕션환경에 올리는 것은 비효율적입니다.

ONNX (Open Neural Network Exchange): * 목적: 프레임워크 종속성 탈피.
- PyTorch에서 학습한 모델을 C++, Go, Java 등 다양한 백엔드 환경에서 쉽게 서빙할 수 있도록 표준화된 포맷으로 변환합니다.
TensorRT: * 목적: NVIDIA GPU 환경에서의 극단적인 추론(Inference) 속도 최적화.
- 네트워크의 레이어를 병합(Layer Fusion)하고, 하드웨어에 맞는 정밀도로 연산을 재구성하여 레이턴시를 최소화합니다.

설계 의도 (Design Intent): 지연 시간(Latency) 최소화와 프론트엔드 UX 개선 백엔드에서 AI 추론에 500ms가 걸린다면, 네트워크 왕복 시간까지 더해져 사용자는 최소 1초 이상의 지연을 겪습니다. 이는 프론트엔드 개발자가 복잡한 로딩 상태나 스켈레톤 UI를 강제로 구현하게 만드는 원인이 됩니다. 모델 경량화와 최적화 포맷 변환은 단순히 서버 리소스를 아끼는 것을 넘어, 즉각적인 반응성(Responsiveness)을 보장하여 전체적인 UX와 코드 복잡도를 개선하는 핵심 아키텍처 결정입니다.

2. 양자화(Quantization) 기법: PTQ vs QAT

양자화는 모델의 가중치(Weight)와 활성화 함수(Activation)의 데이터 타입(예: FP32)을 더 작은 크기(예: INT8)로 줄여 메모리 사용량과 연산 속도를 개선하는 기법입니다.

PTQ (Post-Training Quantization, 학습 후 양자화):
- 개념: 이미 학습이 완료된 모델의 가중치를 변환합니다.
- 장단점: 추가적인 학습 과정이 없어 도입이 매우 빠르고 리소스가 적게 듭니다. 하지만 데이터의 분포가 극단적일 경우 정확도손실이 발생할 위험이 큽니다.
QAT (Quantization-Aware Training, 양자화 인지 학습):
- 개념: 모델을 학습(또는 파인튜닝)할 때부터 양자화로 인한 오차를 시뮬레이션(Fake Quantization)하여 학습시킵니다.
- 장단점: 양자화 이후에도 원본 모델에 가까운 높은 정확도를 유지할 수 있습니다. 하지만 학습 시간이 오래 걸리고 구현이 상대적으로 복잡합니다.

설계 의도 (Design Intent): 엔지니어링 트레이드오프 여기서는 **'개발 속도 vs 시스템 정확도'**의 트레이드오프가 발생합니다. 초기 PoC단계나 오차가 UX에 치명적이지 않은 도메인이라면 PTQ를 선택하여 빠르게 배포하는 것이 맞습니다. 하지만 금융, 의료 등 1%의 정확도 하락이 치명적인 비즈니스 로직이라면 기술 부채를 감수하더라도 QAT를 파이프라인에 구축해야 합니다.

3. 모델 경량화 후 실제 서비스 투입 전 검증 절차

모델이 가벼워지고 빨라졌다고 해서 끝이 아닙니다. '빠르게 틀린 답'을 내놓는 모델은 서비스에 큰 위험을 줄 수 있습니다.

정확도(Accuracy) 및 엣지 케이스 검증:
- 단순히 전체 Validation Set의 평균 정확도만 보지 마세요. 양자화 과정에서 특정 클래스나 희소한 입력값(Edge cases)에 대해 모델이 붕괴하지 않았는지 클래스별 재현율(Recall)과 정밀도(Precision)를 확인해야 합니다.
프로덕션 환경 부하 테스트 (Load Testing & p99 Latency):
- 1건의 요청이 빠르다고 안심하면 안 됩니다. 초당 수백 건의 동시 요청(Concurrency)이 들어올 때의 병목 현상을 확인해야 합니다. 특히 평균 속도보다 p99 레이턴시(상위 1%의 가장 느린 응답 시간)가 프론트엔드 타임아웃(Timeout) 설정 기준을 넘지 않는지 검증하세요.
Shadow Testing (섀도우 배포):
- 실제 프로덕션 트래픽을 기존 무거운 모델과 경량화된 모델 양쪽으로 동시에 흘려보냅니다. 사용자에게는 기존 모델의 결과를 반환하되, 백엔드에서는 두 모델의 결과값과 응답 속도를 비동기적으로 비교하여 모니터링합니다.

위클리페이퍼 #14

goodella — Mon, 15 Jun 2026 04:03:42 +0900

Docker 이미지, Docker Compose, Kubernetes 개념 정리

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

Docker를 처음 접하면 이미지와 컨테이너의 차이가 헷갈릴 수 있다. 두 개념을 간단히 설명하면, Docker 이미지는 컨테이너를 만들기 위한 설계도이고, 컨테이너는 이미지를 바탕으로 실제 실행된 인스턴스이다.

Docker 이미지란?

Docker 이미지는 애플리케이션을 실행하는 데 필요한 파일들을 하나로 묶어놓은 패키지이다. 이미지에는 다음과 같은 내용이 포함될 수 있다.

운영체제의 기본 환경
애플리케이션 실행 파일
라이브러리와 패키지
환경 설정
애플리케이션 실행 명령어

예를 들어 Python으로 만든 웹 애플리케이션을 실행하려면 Python 실행 환경, 필요한 라이브러리, 소스 코드 등이 필요하다. Docker 이미지는 이러한 요소를 하나의 패키지로 저장한다.

이미지는 일반적으로 Dockerfile을 이용해 생성한다.

FROM python:3.12

WORKDIR /app

COPY . /app

RUN pip install -r requirements.txt

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

위 Dockerfile을 빌드하면 애플리케이션 실행에 필요한 환경이 포함된 Docker 이미지가 만들어진다.

docker build -t my-python-app .

Docker 컨테이너란?

Docker 컨테이너는 Docker 이미지를 실제로 실행한 상태이다.

docker run my-python-app

위 명령어를 실행하면 my-python-app 이미지를 기반으로 컨테이너가 생성되고, 컨테이너 내부에서 애플리케이션이 실행된다.

하나의 이미지로 여러 개의 컨테이너를 만들 수도 있다.

Docker 이미지
   ├── 컨테이너 1
   ├── 컨테이너 2
   └── 컨테이너 3

각 컨테이너는 동일한 이미지로 생성되더라도 서로 독립적으로 실행된다.

이미지와 컨테이너의 관계

이미지와 컨테이너의 관계는 프로그램 설치 파일과 실행 중인 프로그램의 관계로 생각할 수 있다.

구분Docker 이미지Docker 컨테이너

의미	컨테이너를 만들기 위한 설계도	이미지를 기반으로 실행된 환경
상태	정적인 파일	실행 가능한 프로세스
역할	실행 환경과 애플리케이션 저장	실제 애플리케이션 실행
비유	프로그램 설치 파일	실행 중인 프로그램
주요 명령어	docker build, docker pull	docker run, docker stop

즉, 이미지만 가지고 있다고 해서 애플리케이션이 실행되는 것은 아니다. 이미지를 바탕으로 컨테이너를 생성하고 실행해야 실제 서비스가 동작한다.

2. Docker Compose는 어떤 상황에서 유용한가?

Docker Compose는 여러 개의 Docker 컨테이너를 하나의 설정 파일로 정의하고 함께 실행할 수 있도록 도와주는 도구이다.

간단한 애플리케이션은 컨테이너 하나만으로 실행할 수 있지만, 실제 서비스에서는 여러 컨테이너가 함께 필요한 경우가 많다.

예를 들어 웹 서비스를 구성할 때 다음과 같은 요소가 필요할 수 있다.

웹 애플리케이션 컨테이너
        ↓
데이터베이스 컨테이너
        ↓
Redis 컨테이너

각 컨테이너를 docker run 명령어로 하나씩 실행하려면 포트, 네트워크, 환경변수, 볼륨 등을 매번 직접 설정해야 한다.

docker run -d --name mysql \
  -e MYSQL_ROOT_PASSWORD=1234 \
  -p 3306:3306 \
  mysql:8

docker run -d --name redis \
  -p 6379:6379 \
  redis

docker run -d --name backend \
  -p 8080:8080 \
  my-backend

컨테이너가 많아질수록 명령어가 길어지고 관리하기 어려워진다. Docker Compose를 사용하면 이러한 설정을 compose.yaml 파일 하나에 작성할 수 있다.

services:
  backend:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - database
      - redis

  database:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: "1234"
    ports:
      - "3306:3306"

  redis:
    image: redis
    ports:
      - "6379:6379"

설정 파일을 작성한 후 다음 명령어를 실행하면 여러 컨테이너를 한 번에 실행할 수 있다.

docker compose up -d

실행 중인 컨테이너들을 한 번에 종료하려면 다음 명령어를 사용한다.

docker compose down

Docker Compose가 유용한 상황

Docker Compose는 다음과 같은 상황에서 유용하다.

첫째, 웹 서버, 데이터베이스, 캐시 서버처럼 여러 컨테이너를 함께 실행해야 할 때 유용하다.

둘째, 개발자마다 동일한 개발 환경을 구성해야 할 때 유용하다. 프로젝트의 Compose 파일을 공유하면 팀원들이 동일한 컨테이너 구성으로 개발 환경을 실행할 수 있다.

셋째, 복잡한 docker run 명령어를 반복해서 입력하지 않아도 된다. 포트, 볼륨, 네트워크, 환경변수 등의 설정을 파일로 관리할 수 있다.

넷째, 로컬 개발 및 테스트 환경을 빠르게 구성하고 제거할 수 있다.

Dockerfile과 Docker Compose의 차이

Dockerfile과 Docker Compose는 경쟁 관계가 아니라 서로 다른 역할을 담당한다.

Dockerfile은 하나의 Docker 이미지를 어떻게 만들 것인지 정의하는 파일이다. 반면, Docker Compose는 여러 컨테이너를 어떤 구성으로 실행할 것인지 정의하는 파일이다.

구분DockerfileDocker Compose

목적	Docker 이미지 생성	여러 컨테이너 실행 및 관리
주요 내용	파일 복사, 패키지 설치, 실행 명령어	서비스, 포트, 환경변수, 볼륨, 네트워크
주요 명령어	docker build	docker compose up
관리 대상	이미지	컨테이너 구성
대표 파일명	Dockerfile	compose.yaml

일반적으로 Dockerfile과 Docker Compose는 함께 사용된다.

Dockerfile
   ↓
애플리케이션 이미지 생성
   ↓
Docker Compose
   ↓
애플리케이션, DB, Redis 컨테이너 함께 실행

Compose 파일의 build: . 설정은 현재 위치의 Dockerfile을 이용해 이미지를 생성하라는 의미이다.

3. Kubernetes의 기본 개념

Kubernetes는 여러 서버에서 실행되는 수많은 컨테이너를 자동으로 배포하고 관리하기 위한 컨테이너 오케스트레이션 플랫폼이다. 줄여서 K8s라고 부르기도 한다.

컨테이너 오케스트레이션은 여러 컨테이너의 배포, 확장, 복구, 네트워크 연결 등을 자동으로 관리하는 것을 의미한다.

Docker만 사용해도 컨테이너를 실행할 수 있지만, 운영 환경에서 컨테이너가 많아지면 다음과 같은 문제가 발생할 수 있다.

컨테이너가 종료되었을 때 누가 다시 실행할 것인가?
사용자가 증가하면 컨테이너 수를 어떻게 늘릴 것인가?
여러 서버 중 어느 서버에 컨테이너를 배치할 것인가?
업데이트할 때 서비스를 중단하지 않고 배포할 수 있는가?
여러 컨테이너에 사용자의 요청을 어떻게 분산할 것인가?

Kubernetes는 이러한 문제를 자동으로 처리한다.

Kubernetes의 주요 기능

1. 자동 배포

Kubernetes는 사용자가 작성한 설정에 따라 컨테이너를 여러 서버에 자동으로 배치한다.

2. 자동 복구

실행 중인 컨테이너에 문제가 발생하면 해당 컨테이너를 종료하고 새로운 컨테이너를 자동으로 생성한다. 서버에 장애가 발생한 경우에도 정상 서버에서 컨테이너를 다시 실행할 수 있다.

3. 자동 확장

사용자 요청이나 CPU 사용량이 증가하면 컨테이너 수를 늘리고, 사용량이 줄어들면 컨테이너 수를 줄일 수 있다.

사용량이 적을 때
컨테이너 1개

사용량이 많을 때
컨테이너 1
컨테이너 2
컨테이너 3

4. 로드 밸런싱

여러 컨테이너가 실행 중일 때 사용자의 요청이 특정 컨테이너에만 집중되지 않도록 요청을 분산한다.

5. 무중단 배포

기존 컨테이너를 한 번에 종료하지 않고 새로운 버전의 컨테이너를 순차적으로 실행한다. 이를 통해 서비스 중단을 최소화하면서 새로운 버전을 배포할 수 있다.

Kubernetes의 기본 구성요소

Kubernetes를 이해할 때 자주 등장하는 기본 개념은 다음과 같다.

Cluster

Kubernetes가 관리하는 전체 서버 집합이다.

Node

클러스터에 포함된 개별 서버 또는 가상머신이다. 실제 컨테이너가 실행되는 작업 공간이라고 볼 수 있다.

Pod

Kubernetes에서 컨테이너를 실행하는 가장 작은 배포 단위이다. 일반적으로 하나의 Pod 안에는 하나의 주요 컨테이너가 들어간다.

Kubernetes Cluster
   ├── Node 1
   │     ├── Pod 1
   │     └── Pod 2
   │
   └── Node 2
         ├── Pod 3
         └── Pod 4

Deployment

Pod를 몇 개 실행할지, 어떤 컨테이너 이미지를 사용할지 등을 정의한다.

예를 들어 다음과 같이 설정할 수 있다.

웹 애플리케이션 Pod를 항상 3개 유지한다.

Pod 하나가 비정상 종료되어 2개만 남으면 Kubernetes가 새로운 Pod를 생성하여 다시 3개를 유지한다.

Service

Pod에 접근할 수 있는 고정된 네트워크 주소를 제공하고, 여러 Pod로 요청을 분산한다.

Pod는 삭제되고 다시 생성될 때 주소가 바뀔 수 있다. Service는 변경되는 Pod를 대신하여 안정적인 접근 지점을 제공한다.

4. Kubernetes와 Docker의 관계

Docker와 Kubernetes는 서로 대체하는 기술이라기보다 담당하는 범위가 다르다.

Docker는 애플리케이션을 이미지로 만들고 컨테이너 형태로 실행하는 데 사용된다. Kubernetes는 이렇게 만들어진 컨테이너를 여러 서버에서 배포하고 관리하는 데 사용된다.

Dockerfile 작성
      ↓
Docker 이미지 생성
      ↓
컨테이너 실행 가능
      ↓
Kubernetes가 여러 컨테이너를 배포하고 관리

역할을 비교하면 다음과 같다.

구분DockerKubernetes

주요 목적	이미지 생성 및 컨테이너 실행	컨테이너 배포 및 운영 자동화
관리 범위	주로 개별 서버의 컨테이너	여러 서버와 다수의 컨테이너
장애 복구	사용자가 직접 처리할 수 있음	컨테이너를 자동으로 재생성
확장	사용자가 직접 컨테이너 추가	설정이나 사용량에 따라 자동 확장 가능
로드 밸런싱	별도 설정 필요	Service 등을 통해 지원
적합한 환경	개발, 테스트, 소규모 서비스	대규모 운영 및 분산 환경

참고로 Kubernetes가 Docker 자체를 반드시 요구하는 것은 아니다. Kubernetes는 컨테이너 실행을 위해 컨테이너 런타임을 사용하며, 대표적으로 containerd나 CRI-O 등이 사용된다. 다만 Docker로 만든 이미지는 표준 컨테이너 이미지 형식을 사용하기 때문에 Kubernetes 환경에서도 사용할 수 있다.

5. Docker Compose와 Kubernetes의 차이

Docker Compose와 Kubernetes 모두 여러 컨테이너를 관리할 수 있지만 사용 목적과 규모에 차이가 있다.

Docker Compose는 주로 하나의 컴퓨터에서 여러 컨테이너를 실행하는 개발 및 테스트 환경에 적합하다. 반면 Kubernetes는 여러 서버에서 다수의 컨테이너를 안정적으로 운영해야 하는 환경에 적합하다.

구분Docker ComposeKubernetes

주요 용도	로컬 개발 및 테스트	실제 서비스 운영
관리 범위	주로 하나의 서버	여러 서버로 구성된 클러스터
설정 난이도	비교적 간단함	상대적으로 복잡함
자동 복구	제한적	지원
자동 확장	기본적으로 제공하지 않음	지원
무중단 배포	제한적	지원
적합한 규모	소규모 구성	중대규모 분산 환경

예를 들어 개인 프로젝트에서 백엔드, MySQL, Redis를 함께 실행한다면 Docker Compose만으로도 충분할 수 있다.

반면 사용자가 많은 실제 서비스를 여러 서버에서 운영하고, 장애 복구와 자동 확장이 필요하다면 Kubernetes를 사용하는 것이 적합하다.

정리

Docker 이미지는 애플리케이션 실행 환경을 저장한 설계도이고, Docker 컨테이너는 이미지를 바탕으로 실제 실행된 환경이다.

Dockerfile은 Docker 이미지를 만드는 방법을 정의하며, Docker Compose는 여러 컨테이너의 실행 구성을 정의한다.

Kubernetes는 다수의 컨테이너를 여러 서버에 배포하고, 장애 복구, 확장, 로드 밸런싱, 무중단 배포 등을 자동으로 수행하는 플랫폼이다.

전체적인 관계를 정리하면 다음과 같다.

Dockerfile
   ↓
Docker 이미지 생성
   ↓
Docker 컨테이너 실행
   ↓
Docker Compose
여러 컨테이너를 간편하게 구성

또는

Docker 이미지
   ↓
Kubernetes
여러 서버에서 컨테이너를 자동 배포·확장·복구

따라서 Docker는 컨테이너를 만들고 실행하기 위한 기술이고, Kubernetes는 만들어진 컨테이너를 대규모 환경에서 효율적으로 운영하기 위한 기술이라고 정리할 수 있다.

위클리 페이퍼 #12

goodella — Mon, 27 Apr 2026 02:31:21 +0900

Q1. LLM이 생성한 텍스트에서 할루시네이션이란 무엇이고, 왜 문제가 되나요?

1. LLM 할루시네이션
(1) 정의
할루시네이션은 LLM이 사실과 다르거나 근거가 불확실한 내용을 그럴듯하게 생성하는 현상입니다. LLM은 기본적으로 다음에 올 가능성이 높은 단어를 예측해 문장을 생성하기 때문에, 문장이 자연스럽다고 해서 그 내용이 반드시 사실이라는 뜻은 아닙니다.

(2) 왜 발생하는가?
첫째, LLM은 기본적으로 확률 기반 생성 모델입니다. 모델은 “진실”을 직접 판단한다기보다, 학습 데이터에서 본 패턴을 바탕으로 가장 자연스러운 답변을 생성합니다.

둘째, 훈련 데이터의 한계가 있습니다. 훈련 데이터가 오래되었거나, 부정확하거나, 편향되어 있으면 모델도 잘못된 내용을 생성할 수 있습니다.

셋째, 지식 공백이 있습니다. 모델이 모르는 질문을 받았을 때 “모른다”고 말하기보다 그럴듯한 답을 만들어내는 경우가 있습니다.

넷째, 출처와 근거를 직접 검증하지 못하는 한계가 있습니다. 특히 기본 LLM은 외부 문서를 실시간으로 확인하지 않으면 최신 사실이나 구체적 수치를 검증하기 어렵습니다.

(3) 왜 문제가 되는가?
할루시네이션은 단순한 오류를 넘어 실제 피해로 이어질 수 있습니다. 의료, 법률, 금융처럼 정확성이 중요한 분야에서는 잘못된 답변이 의사결정에 영향을 줄 수 있습니다. 기업 서비스에서는 고객에게 잘못된 정보를 제공해 신뢰도와 법적 책임 문제가 생길 수 있습니다. 교육, 언론, 공공 영역에서는 잘못된 정보가 확산되는 문제도 발생합니다.

(4) 실제 예시
- 질문:
삼성전자의 2030년 매출은?

- LLM의 잘못된 응답 예시:
삼성전자는 2030년에 500조 원의 매출을 기록했다.

문제는 2030년은 아직 확정된 과거 데이터가 아니므로, 이런 답변은 미래 예측을 사실처럼 말한 할루시네이션에 가깝습니다.

2. 여러 LLM 서비스들은 할루시네이션을 어떻게 줄이려 하나?
(1) RAG
RAG는 Retrieval-Augmented Generation의 약자입니다. LLM이 자체 기억만으로 답하지 않고, 외부 문서나 데이터베이스를 검색한 뒤 그 근거를 바탕으로 답변하는 방식입니다.

구조:
질문 → 관련 문서 검색 → 문서 내용 참고 → LLM 답변 생성

이 그림은 RAG의 기본 구조를 보여줍니다.

먼저 사용자가 1) Prompt + Query를 입력하면, 시스템은 그 질문을 바탕으로 2) 관련 정보를 검색합니다. 그다음 검색된 결과는 3) 관련 컨텍스트 정보로 정리되어 LLM에 전달되고, 최종적으로 4) Prompt + Query + Enhanced Context가 된 입력을 바탕으로 LLM이 5) Generated Text Response를 생성합니다. 즉, LLM이 내부 기억만으로 답하는 것이 아니라 외부 지식 소스에서 찾은 근거를 함께 활용하므로, 더 정확하고 근거 있는 응답을 만들 수 있습니다.

(2) Grounding
Grounding은 모델의 답변을 특정 문서, 검색 결과, 데이터베이스, 기업 내부 자료 등에 연결하는 방식입니다. 즉, “모델이 그냥 말하는 것”이 아니라 “어떤 근거를 바탕으로 말하는지”를 명확히 하려는 접근입니다.

예를 들어 기업용 챗봇은 사내 매뉴얼, 제품 문서, FAQ를 기반으로만 답하도록 설계할 수 있습니다.

(3) Tool use
최근 LLM 서비스들은 검색, 계산기, 코드 실행기, 데이터베이스 조회 같은 도구를 함께 사용합니다. 예를 들어 계산 문제는 모델이 암산으로 답하지 않고 계산 도구를 사용하게 만들 수 있습니다. 최신 정보가 필요한 질문은 검색 도구를 사용해 확인할 수 있습니다.

(4) RLHF와 안전 학습
RLHF는 Reinforcement Learning from Human Feedback의 약자입니다. 사람이 좋은 답변과 나쁜 답변을 평가하고, 그 피드백을 바탕으로 모델이 더 유용하고 안전한 답변을 하도록 학습시키는 방식입니다.

다만 RLHF만으로 할루시네이션을 완전히 없앨 수는 없습니다. 그래서 RAG, 검색, 출처 인용, 검증 모델 등을 함께 사용합니다.

(5) 답변 검증과 출처 인용
일부 서비스는 답변 뒤에 참고 문서나 링크를 함께 제공합니다. 또는 모델이 생성한 답변을 별도의 검증 단계에서 다시 확인하는 방식도 사용합니다.

하지만 출처가 표시된다고 해서 항상 완벽한 것은 아닙니다. 모델이 출처를 잘못 해석하거나, 출처와 맞지 않는 결론을 낼 수도 있기 때문입니다.

Q2. 모델 크기를 키우는 것만으로는 성능이 일정 시점 이후 둔화되는 이유는?
1. 모델 크기와 성능은 비례하지 않음
LLM은 일반적으로 모델 크기, 데이터 양, 연산량이 증가하면 성능이 좋아지는 경향이 있습니다. 이를 scaling law라고 합니다.

하지만 어느 시점부터는 모델을 더 크게 만들어도 성능 향상 폭이 줄어듭니다. 즉, 비용은 크게 증가하지만 성능 개선은 점점 작아지는 수확 체감이 발생합니다.

2. 주요 이유
(1) 고품질 데이터의 한계
모델이 커질수록 더 많은 고품질 데이터가 필요합니다. 하지만 인터넷에 있는 모든 데이터가 좋은 학습 데이터는 아닙니다. 중복, 오류, 편향, 저품질 텍스트가 많기 때문에 단순히 데이터를 많이 넣는다고 성능이 계속 좋아지지는 않습니다.

(2) 연산 비용의 급증
모델이 커지면 학습과 추론 비용이 크게 증가합니다. 더 많은 GPU, 전력, 메모리, 시간이 필요합니다. 따라서 실무에서는 성능이 조금 더 좋아지는 것보다 비용 대비 효율이 더 중요해집니다.

(3) 데이터와 모델 크기의 균형 문제
Chinchilla 연구에서는 모델을 무조건 크게 만드는 것보다, 모델 크기와 학습 토큰 수의 균형이 중요하다고 설명했습니다. 즉, 큰 모델을 적은 데이터로 학습시키는 것보다, 적절한 크기의 모델을 충분한 데이터로 학습시키는 것이 더 효율적일 수 있습니다.

(4) 특정 능력은 크기만으로 해결되지 않음
논리 추론, 최신 정보 반영, 사실 검증, 긴 문맥 유지, 도메인 전문성은 모델 크기만으로 완전히 해결되지 않습니다. 그래서 최근에는 단순히 모델을 키우는 것보다 다음 접근이 함께 사용됩니다.

- 모델 구조 개선.
- 고품질 데이터 정제.
- RAG.
- Tool use(검색, 계산기, 코드 실행기 같은 외부 도구를 모델이 함께 사용하는 방식).
- Instruction tuning(자연어 지시를 잘 따르도록 예시 기반으로 추가 학습하는 방식).
- PEFT(Parameter-Efficient Fine-Tuning, 전체 모델이 아니라 일부 파라미터만 효율적으로 미세조정하는 방법).
- MoE(Mixture of Experts, 입력에 따라 일부 전문가 네트워크만 선택적으로 활성화하는 구조).
- 긴 컨텍스트 처리 개선.
- 추론 시 계산량을 늘리는 test-time compute 계열 접근( AI가 단순히 패턴을 매칭하는 것을 넘어, 문제의 난이도에 따라 스스로 더 많은 연산을 수행하며 깊게 사고하게 만드는 기술)

모델 크기는 중요하지만, 성능을 결정하는 유일한 요소는 아닙니다.
LLM 성능은 모델 크기, 데이터 품질, 학습 방식, 추론 전략, 외부 도구 활용의 조합으로 결정됩니다.

Q3. PEFT가 필요한 이유는 무엇이며, 어떤 상황에서 특히 효과적인가?
1. PEFT의 정의
PEFT는 Parameter-Efficient Fine-Tuning의 약자입니다. 대규모 모델 전체를 다시 학습하지 않고, 일부 파라미터만 조정해 특정 작업에 맞게 모델을 튜닝하는 방법입니다.

2. 왜 필요한가?
LLM 전체를 fine-tuning하려면 막대한 GPU 메모리와 학습 시간이 필요합니다. 또한 태스크마다 모델 전체를 따로 저장하면 저장 비용도 커집니다. PEFT는 이런 문제를 줄이기 위해 등장했습니다.

3. PEFT의 장점
-적은 GPU 메모리 사용.
-빠른 학습.
-낮은 비용.
-여러 태스크에 쉽게 적용.
-기존 모델의 일반 능력을 비교적 잘 유지할 수 있음.

예를 들어 7B, 13B 이상의 모델을 개인이나 소규모 팀이 전체 fine-tuning하기는 어렵습니다. 하지만 LoRA나 QLoRA를 사용하면 훨씬 적은 자원으로 도메인 튜닝이 가능합니다.

4. 대표 기법
(1) LoRA
LoRA는 기존 가중치를 직접 크게 수정하지 않고, 작은 저랭크 행렬을 추가로 학습하는 방식입니다.

참고)

행렬의 랭크(Rank): 행렬에서 서로 독립적인 행이나 열의 최대 개수를 의미합니다.
저랭크(Low-rank): 원래 행렬이 가진 차원(가로/세로 길이)에 비해, 실질적으로 정보를 담고 있는 핵심 차원(Rank)이 현저히 낮은 상태를 말합니다

(2) QLoRA
QLoRA는 모델을 4-bit로 양자화한 상태에서 LoRA 방식으로 튜닝하는 기법입니다. 메모리 사용량을 크게 줄이면서도 비교적 좋은 성능을 유지할 수 있어 많이 사용됩니다.

(3) Adapter
Adapter는 모델 내부에 작은 추가 모듈을 삽입하고, 그 모듈만 학습하는 방식입니다.

(4) Prompt Tuning / Prefix Tuning
모델 가중치는 고정하고, 입력 앞에 붙는 학습 가능한 프롬프트나 prefix만 조정하는 방식입니다.

5. PEFT가 특히 효과적인 상황
PEFT는 다음 상황에서 특히 효과적입니다.

-GPU 자원이 부족한 개인 연구자나 소규모 팀.
-법률, 의료, 금융 등 특정 도메인에 맞게 모델을 조정할 때.
-여러 고객사나 여러 태스크별 모델을 운영해야 할 때.
-빠른 실험과 프로토타이핑이 필요할 때.
-기존 대형 모델의 일반 능력을 유지하면서 특정 업무 능력만 보강하고 싶을 때.

6. 예시
목표: 의료 상담과, 의료 용어에 익숙한 LLM 만들기.

Full fine-tuning을 하면 모델 전체를 다시 학습해야 하므로 비용이 큽니다. PEFT를 사용하면 기존 LLM은 대부분 그대로 두고, 의료 상담 데이터에 맞는 작은 추가 파라미터만 학습할 수 있습니다. 따라서 적은 비용으로 특정 도메인에 맞춘 모델을 만들 수 있습니다.

7.비교

Full Fine-tuning PEFT

학습 범위	전체 파라미터 (All)	일부 파라미터 (Small)
자원 소모	매우 큼 (GPU/시간)	매우 적음
저장 비용	태스크마다 전체 모델 복사	베이스 모델 + 작은 어댑터
핵심 장점	최대 성능 잠재력	효율성, 빠른 배포, 가벼움

위클리 페이퍼 #11

goodella — Mon, 20 Apr 2026 09:06:51 +0900

안녕하세요 이번에는 위클리페이퍼 11 주제에 대해 정리해보려고 합니다 ~!

1.BERT와 GPT의 주요 차이점은 무엇인가요? 각각의 기본 구조와 작동 방식, 적합한 NLP 응용 분야를 위주로 설명해주세요.

BERT와 GPT는 모두 Transformer 기반의 대표적인 사전학습 언어모델로, 현대 NLP 발전의 핵심적인 출발점이 되었습니다. 다만 두 모델은 구조, 학습 방식, 강점이 드러나는 응용 분야에서 뚜렷한 차이를 보입니다.BERT와 GPT는 모두 Transformer 기반 언어모델이지만, 무엇을 더 잘하게 설계됐는지가 다릅니다.

1. BERT와 GPT의 주요 차이점

(1)BERT: 문맥을 양쪽에서 보고 이해하는 모델

BERT는 Transformer의 Encoder-only 구조를 사용합니다.
가장 큰 특징은 양방향(bidirectional) 으로 문맥을 본다는 점입니다.
즉, 어떤 단어의 의미를 파악할 때 앞 단어와 뒤 단어를 함께 참고합니다.

예를 들어 “나는 은행에 가서 돈을 찾았다.”라는 문장을 살펴보겠습니다. BERT는 “은행”이 강가(river bank)가 아니라 금융기관이라는 점을 앞뒤 문맥을 함께 보고 이해할 수 있습니다.

BERT의 대표적인 사전학습 방식은 MLM(Masked Language Modeling) 입니다.문장 속 일부 단어를 가려 놓고, 그 빈칸에 들어갈 단어를 맞히게 합니다.

예를 들면, “나는 오늘 [MASK]를 마셨다.” 라는 문장을 보고, 앞뒤 문맥을 바탕으로 “커피”, “물”, “차” 같은 단어를 예측합니다. 초기 BERT에는 NSP(Next Sentence Prediction) 도 함께 쓰였습니다.이것은 두 문장이 실제로 이어지는 문장인지 맞히는 방식입니다.

BERT가 잘하는 일

BERT는 텍스트를 이해하고 분류하는 작업에 적합합니다.

예:

감성 분석
“이 영화는 정말 재미있었다” → 긍정
문장 분류
메일이 스팸인지 아닌지 분류
개체명 인식(NER)
“이순신은 조선의 장군이다”에서 “이순신”은 인물, “조선”은 국가로 인식
질의응답(QA)
지문을 읽고 그 안에서 답을 찾기

즉, BERT는 “이 문장이 무슨 뜻인지 잘 파악하는 모델” 입니다.

(2)GPT: 다음 단어를 이어 쓰며 생성하는 모델

GPT는 Transformer의 Decoder-only 구조를 사용합니다.이 모델은 왼쪽에서 오른쪽으로 순서대로 읽으면서 다음 단어를 예측합니다.예를 들어,“오늘 날씨가 좋아서” 까지 주어지면, 그다음에 “산책을”, “밖에”, “기분이” 같은 말을 이어서 만들어냅니다.이 방식을 자기회귀(autoregressive) 방식이라고 합니다. 즉, 지금까지 나온 단어들을 바탕으로 다음 토큰 하나씩 생성해 나가는 구조입니다.

GPT가 잘하는 일

GPT는 텍스트 생성 작업에 강합니다.

예:

대화형 AI
질문에 자연스럽게 답변
글쓰기 보조
이메일, 보고서, 에세이 초안 생성
요약
긴 문서를 짧게 정리
번역
한국어 ↔ 영어 변환
코드 생성
“파이썬으로 정렬 코드 짜줘” 같은 요청 처리

예를 들어 사용자가 “봄에 어울리는 짧은 광고 문구를 써줘”라고 하면, GPT는 맥락에 맞는 새로운 문장을 만들어냅니다.즉, GPT는“자연스럽게 다음 말을 이어서 만들어내는 모델” 입니다.

BERT와 GPT는 모두 Transformer 기반 언어모델이지만, 무엇을 더 잘하게 설계됐는지가 다릅니다.
쉽게 말하면, 다음과 같이 정리할 수 있습니다.
정리하면, BERT는 문장을 이해하는 모델, GPT는 문장을 생성하는 모델이라고 볼 수 있습니다.

BERT vs GPT

구조	Encoder-only (양방향)	Decoder-only (단방향)
사전학습	MLM + NSP	Next Token Prediction
강점	이해/분석 (분류, QA, NER)	생성 (번역, 요약, 대화)

2.Hugging Face Transformers 라이브러리는 무엇이며, 어떤 기능을 제공하나요?

Hugging Face Transformers는 BERT, GPT, RoBERTa, T5, BART 등 다양한 사전학습 모델을 쉽게 불러오고 활용할 수 있도록 만든 오픈소스 라이브러리입니다. PyTorch, TensorFlow, JAX 등 여러 딥러닝 프레임워크와 호환되며, 연구와 실무 모두에서 널리 사용됩니다.

왜 많이 쓰일까?

가장 큰 이유는 사용이 매우 간단하기 때문입니다. 예를 들어 감성 분석을 직접 구현하려면,

토크나이저 만들기
모델 구조 설계
학습 코드 작성
추론 함수 작성

같은 작업이 필요합니다.

하지만 Hugging Face에서는 pipeline만 써도 기본 작업을 바로 실행할 수 있습니다.

예:

감성 분석
텍스트 생성
요약
번역
질의응답

즉, 연구자나 개발자가 모델 구조를 하나하나 다시 짤 필요 없이 바로 실험하고 적용할 수 있는 환경을 제공합니다.

(1)주요 기능

1) 토크나이저 제공

모델은 문장을 바로 이해하지 못하므로, 문장을 잘게 쪼개 토큰(token) 으로 바꿔야 합니다.
Transformers 라이브러리는 모델마다 맞는 토크나이저를 함께 제공합니다.

예:

“I love NLP”

→ ["I", "love", "NL", "##P"] 처럼 나뉠 수 있음

2) 사전학습 모델 불러오기

이미 학습된 BERT, GPT, T5 등을 바로 로드할 수 있습니다.

예:

bert-base-uncased
gpt2
roberta-base
t5-small

즉, 대규모 학습을 직접 하지 않아도
이미 학습된 모델을 바로 활용할 수 있습니다.

3) 파인튜닝(fine-tuning)

사전학습된 모델을 내 데이터에 맞게 다시 조금 학습시켜
특정 업무에 최적화할 수 있습니다.

예:

병원 리뷰 데이터로 감성 분석 모델 만들기
법률 문서 분류 모델 만들기
고객 상담 문서 요약 모델 만들기

4) Pipeline API

복잡한 코드 없이 한 줄 수준으로 작업을 실행할 수 있게 해줍니다.

예를 들어:

“이 문장이 긍정인지 부정인지”
“이 기사 내용을 3줄로 요약”
“영어를 한국어로 번역”

같은 작업을 빠르게 수행할 수 있습니다.

5) 멀티모달 확장

원래는 NLP 중심이었지만, 이후에는 텍스트뿐 아니라
이미지, 음성, 멀티모달 모델까지 다루는 방향으로 크게 확장되었습니다.

예:

이미지 설명 생성
음성 인식
이미지+텍스트 결합 모델 활용

토크나이저, 데이터셋 처리, 파인튜닝(Trainer API), 멀티모달(NLP/CV/오디오) 지원이 있으며, 2026년 4월 기준 v5.5+ 버전에서 양자화와 비동기 추론이 강화되었습니다.

3.BERT와 GPT 이후 등장한 주요 사전학습 모델에는 어떤 것들이 있으며, 특징은 무엇인가요? 구글링 등을 통해 자유롭게 리서치해서 정리해보세요.

BERT/GPT 이후

- RoBERTa(동적 마스킹, 더 큰 데이터)

- ALBERT(경량화, 파라미터 공유)

- DistilBERT(지식 증류)

- DeBERTa(분해 어텐션)

- ELECTRA(디스크리미네이터 효율 학습)

- T5(텍스트-투-텍스트 통합)

- BART(노이즈 복원)가 등장했습니다.

2026년 4월 기준으로는 GPT-5.4(컴퓨터 사용 API, 1M 컨텍스트, 범용 생성), Claude 4.6 Opus(코딩 최강, 14.5시간 에이전트), Gemini 3.1 Pro(추론/멀티모달 1위), Llama 4(오픈소스 대형), Grok 4.1(xAI 고차원 추론)이 주목받으며, 에이전트 오케스트레이션과 강화 추론이 트렌드입니다.

위클리 페이퍼 #10

goodella — Mon, 13 Apr 2026 03:51:47 +0900

1. 텍스트 데이터를 모델에 적용하기 전에 어떤 전처리 과정을 거치나요?

텍스트 데이터는 이미지처럼 바로 숫자로 입력할 수 없기 때문에, 모델이 이해할 수 있는 형태로 바꾸는 전처리 과정이 필요하다.
전처리의 목적은 불필요한 노이즈를 줄이고, 텍스트를 일정한 형식으로 정리한 뒤, 수치화하여 모델 입력으로 변환하는 것이다.

1) 정제(Cleaning)

가장 먼저 수행하는 것은 텍스트 정제이다.
예를 들어 HTML 태그, 특수문자, 이모지, 중복 공백, 불필요한 기호 등을 제거하거나 정리한다.
또한 대소문자를 통일하고, 오탈자 교정이나 정규화 작업을 하기도 한다.

예시:

"Hello!!! NLP " → "hello nlp"

이 단계는 데이터의 일관성을 높여 모델이 의미 없는 패턴을 학습하지 않도록 돕는다.

2) 토큰화(Tokenization)

정제된 문장을 단어, 형태소, 혹은 서브워드 단위로 나누는 과정이다.
이를 토큰화라고 한다.

예시:

"I love natural language processing"
→ ["I", "love", "natural", "language", "processing"]

한국어에서는 조사와 어미 변화가 많기 때문에 단순 띄어쓰기 기준보다 형태소 분석 기반 토큰화가 더 중요하게 쓰이기도 한다.

3) 불용어 제거(Stopword Removal)

문장 안에는 의미 전달에 큰 기여를 하지 않는 단어들이 있다.
예를 들어 영어의 the, is, a 같은 단어들이 대표적이다.
이런 단어를 제거하면 핵심 정보가 더 잘 드러날 수 있다.

다만 최근 딥러닝 모델에서는 문맥 자체가 중요하기 때문에, 무조건 제거하기보다는 모델과 목적에 따라 선택적으로 적용하는 편이다.

4) 정규화 및 어간 추출 / 표제어 추출

동일한 의미를 가지는 다양한 형태를 통일하는 과정이다.

어간 추출(Stemming): 단어의 어간만 남기는 방식
- playing, played, plays → play
표제어 추출(Lemmatization): 문법적 형태를 고려해 기본형으로 변환
- am, are, is → be

이 작업은 단어 수를 줄이고, 비슷한 의미의 표현을 하나로 묶는 데 도움이 된다.

5) 벡터화(Vectorization)

전처리된 텍스트를 모델이 입력할 수 있도록 숫자 벡터로 바꾸는 단계이다.
대표적인 방법은 다음과 같다.

One-Hot Encoding
Bag of Words
TF-IDF
Word2Vec / FastText / GloVe 같은 임베딩
최근에는 BERT 같은 문맥 기반 임베딩

즉, 전처리의 최종 목표는 텍스트를 의미를 어느 정도 보존한 숫자 표현으로 바꾸는 것이다.

6) 패딩(Padding)과 길이 맞추기

딥러닝 모델은 보통 입력 길이가 일정해야 하므로, 문장 길이가 다를 경우 짧은 문장은 패딩을 추가하고 긴 문장은 잘라낸다.

예시:

["I", "love", "NLP"]
["Transformer", "is", "powerful"]

이 둘의 길이를 맞추기 위해 [PAD] 같은 토큰을 추가한다.

정리

텍스트 전처리는 보통 다음 흐름으로 이해할 수 있다.

텍스트 정제 → 토큰화 → 불용어 제거/정규화 → 벡터화 → 길이 맞추기

다만 최근의 Transformer 계열 모델은 자체 토크나이저와 임베딩 구조를 가지므로, 과거보다 수작업 전처리가 줄어든 편이다.
그럼에도 데이터 정제와 토큰화는 여전히 매우 중요한 기본 단계이다.

2. FastText가 Word2Vec과 다른 점은 무엇이며, 어떤 장점이 있나요?

FastText는 Word2Vec을 확장한 단어 임베딩 기법이다.
둘 다 단어를 밀집 벡터(Dense Vector)로 표현한다는 점은 같지만, 단어를 바라보는 방식에서 중요한 차이가 있다.

1) Word2Vec의 특징

Word2Vec은 단어를 하나의 독립된 토큰으로 본다.
즉, "apple"이라는 단어가 있으면 이를 하나의 단위로만 임베딩한다.

장점은 구조가 단순하고 학습이 빠르다는 점이다.
하지만 문제가 있다.
학습 데이터에 없던 단어(OOV, Out-Of-Vocabulary)는 벡터를 만들기 어렵고, 단어 내부 구조를 반영하지 못한다.

예를 들어:

run
running
runner

이 단어들은 형태적으로 관련이 있지만, Word2Vec은 각각을 별도의 단어로 취급한다.

2) FastText의 핵심 아이디어

FastText는 단어를 문자 n-gram의 집합으로 본다.
즉, 단어 하나를 통째로만 보는 것이 아니라, 내부의 부분 문자열(subword)까지 활용한다.

예를 들어 "where"라는 단어를 3-gram으로 나누면 다음처럼 볼 수 있다.

이런 식으로 단어 벡터를 부분 문자열 벡터들의 합 또는 평균으로 구성한다.

3) FastText의 장점

(1) OOV 문제 완화

학습 시 한 번도 보지 못한 단어라도, 그 단어를 구성하는 문자 조각들은 기존에 학습했을 가능성이 있다.
그래서 완전히 새로운 단어에 대해서도 어느 정도 의미 있는 벡터를 만들 수 있다.

예를 들어 "playful"이 학습 데이터에 없더라도
play, ayf, yfu, ful 같은 조각을 활용해 임베딩을 추정할 수 있다.

(2) 형태 정보 반영

접두사, 접미사, 어근 같은 정보가 벡터에 반영된다.
따라서 굴절이 많거나 파생어가 많은 언어에서 유리하다.

예:

teach, teacher, teaching
happy, unhappy

이런 단어들의 관계를 Word2Vec보다 더 잘 반영할 수 있다.

(3) 희귀 단어에 강함

등장 빈도가 낮은 단어는 Word2Vec에서 좋은 벡터를 학습하기 어렵다.
반면 FastText는 서브워드 정보를 활용하므로 희귀 단어에 대해서도 상대적으로 안정적인 표현을 만들 수 있다.

4) 한계

물론 FastText가 항상 Word2Vec보다 절대적으로 좋은 것은 아니다.
문자 단위 정보를 활용하기 때문에 계산량이 조금 더 늘 수 있고, 문맥 자체를 깊게 반영하는 모델은 아니다.
즉, FastText는 형태 정보에는 강하지만 문맥 기반 표현은 아니다.

정리

Word2Vec은 단어를 하나의 단위로 임베딩하고, FastText는 단어 내부의 문자 조각(subword)까지 활용한다.
그래서 FastText는 특히 희귀 단어, 형태 변화가 많은 언어, OOV 문제에서 강점을 가진다.

3. Attention 메커니즘이 Seq2Seq 모델의 어떤 문제를 해결하는 데 도움이 되나요?

Attention은 Seq2Seq 모델의 가장 큰 약점 중 하나였던 고정 길이 문맥 벡터의 한계를 해결하기 위해 등장했다.

1) Seq2Seq의 기본 구조

기본적인 Seq2Seq는 다음과 같은 흐름을 가진다.

Encoder가 입력 문장을 읽어 하나의 고정 길이 벡터로 압축
Decoder가 그 벡터를 바탕으로 출력 문장을 생성

예를 들어 번역 모델에서는,
입력 문장 전체를 Encoder가 하나의 벡터로 요약하고, Decoder는 그 정보만 보고 번역 문장을 생성한다.

2) 기존 Seq2Seq의 문제점

문장이 짧을 때는 괜찮지만, 문장이 길어질수록 문제가 생긴다.
입력 문장의 모든 정보를 하나의 벡터에 담아야 하기 때문이다.

즉,

긴 문장에서 앞부분 정보가 희석될 수 있고
중요한 단어가 충분히 반영되지 않을 수 있으며
Decoder는 출력 시점마다 어떤 입력 부분을 참고해야 하는지 알기 어렵다.

결국 정보 병목(information bottleneck) 문제가 발생한다.

3) Attention의 해결 방식

Attention은 Decoder가 매 시점마다 입력 전체를 다시 참고할 수 있게 만든다.
즉, 입력 문장을 하나의 벡터로만 압축하지 않고, Encoder의 모든 hidden state를 보관해 둔 뒤, Decoder가 현재 필요한 부분에 더 집중하도록 한다.

예를 들어 번역 중에 "사과를 먹는다"를 영어로 바꾸는 경우,
eat를 생성할 때는 "먹는다" 쪽에,
apple을 생성할 때는 "사과" 쪽에 더 높은 가중치를 둘 수 있다.

이렇게 출력 단어마다 관련 있는 입력 단어에 가중치를 다르게 부여하는 것이 Attention의 핵심이다.

4) Attention이 해결하는 문제

Attention은 특히 다음 문제를 완화한다.

(1) 고정 길이 벡터 병목 문제

입력 전체를 하나의 벡터에 억지로 담지 않아도 된다.

(2) 긴 문장 처리 성능 저하

문장이 길어져도 필요한 입력 위치를 직접 참조할 수 있다.

(3) 입력-출력 정렬(alignment) 문제

출력 단어가 입력의 어느 부분과 관련되는지 더 잘 학습할 수 있다.

5) 효과

Attention의 도입으로 번역, 요약, 질의응답 같은 다양한 시퀀스 생성 태스크의 성능이 크게 향상되었다.
또한 모델이 어떤 입력 부분에 주목했는지 시각화할 수 있어 해석 가능성 측면에서도 의미가 있었다.

정리

Attention은 Seq2Seq가 입력 전체를 하나의 벡터에 압축하면서 생기는 정보 손실과 긴 문장 처리 문제를 해결하는 데 큰 도움을 주었다.
즉, Decoder가 매 시점마다 입력의 중요한 부분을 선택적으로 참고할 수 있도록 만든 메커니즘이다.

4. Transformer 모델은 Seq2Seq 구조와 어떤 점에서 근본적으로 다른가요?

Transformer는 Seq2Seq와 마찬가지로 입력 시퀀스를 받아 출력 시퀀스를 생성할 수 있는 구조이지만, 내부 동작 원리는 매우 다르다.
가장 큰 차이는 순환 구조(RNN)에 의존하지 않고, Self-Attention을 중심으로 동작한다는 점이다.

1) 기존 Seq2Seq의 기반: RNN/LSTM/GRU

전통적인 Seq2Seq는 보통 RNN, LSTM, GRU를 기반으로 구성된다.
이 구조는 입력을 순서대로 한 단어씩 처리한다.

즉,

앞 단어를 읽고
그다음 단어를 읽고
이전 hidden state를 다음 시점으로 넘기는 방식이다.

이 방식은 순서를 자연스럽게 반영할 수 있지만, 다음과 같은 한계가 있다.

병렬 처리가 어렵다
긴 거리 의존성 학습이 어렵다
학습 속도가 느릴 수 있다

2) Transformer의 기반: Self-Attention

Transformer는 RNN을 사용하지 않는다.
대신 문장 전체를 한 번에 보고, 각 단어가 다른 모든 단어와 얼마나 관련 있는지를 계산한다.
이 핵심 메커니즘이 Self-Attention이다.

예를 들어 "The animal didn't cross the street because it was tired"라는 문장에서
it이 무엇을 가리키는지 이해하려면 문장 전체를 봐야 한다.
Transformer는 이런 관계를 문장 전체 단위에서 직접 계산한다.

3) 근본적인 차이점

(1) 순차 처리 vs 병렬 처리

Seq2Seq(RNN 기반): 단어를 순서대로 처리
Transformer: 전체 시퀀스를 한 번에 처리 가능

이 차이 때문에 Transformer는 학습 속도와 효율 면에서 큰 장점을 가진다.

(2) 고정된 순환 상태 vs 직접적인 관계 계산

RNN 기반 모델은 이전 hidden state를 통해 정보를 전달
Transformer는 Self-Attention으로 모든 단어 쌍의 관계를 직접 계산

즉, 멀리 떨어진 단어 관계도 더 쉽게 포착할 수 있다.

(3) 위치 정보 처리 방식

RNN은 순서대로 읽기 때문에 위치 정보가 구조 자체에 내장되어 있다.
반면 Transformer는 병렬 처리하므로 단어 순서를 별도로 알려줘야 한다.
이를 위해 Positional Encoding을 사용한다.

4) Transformer의 장점

(1) 병렬화에 유리

GPU를 활용한 대규모 학습에 적합하다.

(2) 긴 문맥 의존성 처리에 강함

멀리 떨어진 단어 간 관계를 잘 포착한다.

(3) 확장성이 좋음

대규모 데이터와 파라미터로 확장하기 쉽기 때문에 현대 LLM의 기반이 되었다.

5) Transformer와 Seq2Seq의 관계

엄밀히 말하면 Transformer도 Encoder-Decoder 구조를 가질 수 있으므로 넓은 의미에서는 Seq2Seq 작업을 수행한다.
하지만 전통적인 Seq2Seq와 비교했을 때, 핵심 차이는 순환 기반 처리에서 Attention 기반 처리로 패러다임이 바뀌었다는 점이다.

즉,

전통적 Seq2Seq: 순서대로 읽고 기억을 전달
Transformer: 전체를 한 번에 보고 관계를 계산

이 차이가 가장 본질적이다.

정리

Transformer는 Seq2Seq와 같은 시퀀스 변환 문제를 다루지만,
RNN 기반의 순차 처리 대신 Self-Attention 기반의 병렬 처리를 사용한다.
이로 인해 긴 문맥 처리, 학습 효율, 확장성에서 큰 발전을 이루었고, 오늘날의 BERT, GPT 같은 모델로 이어지게 되었다.

마무리

이번 내용을 정리하면서 느낀 점은 자연어처리 모델의 발전 흐름이 꽤 분명하다는 것이다.
초기에는 텍스트를 정제하고 단어를 벡터화하는 것이 중요했다면, 이후에는 단어 내부 구조를 반영하는 FastText가 등장했고, Seq2Seq의 한계를 보완하는 Attention이 나왔으며, 결국 Transformer가 등장하면서 현재의 대규모 언어모델 시대로 이어졌다.

즉,
전처리 → 임베딩 → Attention → Transformer
이 흐름을 이해하면 현대 NLP와 LLM의 기본 구조를 훨씬 쉽게 받아들일 수 있다.

위클리페이퍼 #9

goodella — Mon, 16 Mar 2026 09:03:54 +0900

1. Semantic Segmentation vs. Classification

이미지 분석의 가장 기초적인 두 작업은 데이터를 바라보는 **해상도(Granularity)**에서 차이가 발생합니다.

Image Classification (분류): 이미지 전체를 하나의 라벨로 정의합니다. "이 사진 안에 강아지가 있는가?"를 묻습니다. 공간 정보는 소실되고 특징(Feature)의 존재 여부에 집중합니다.
Semantic Segmentation (의미론적 분할): 이미지 내의 모든 픽셀에 대해 클래스를 할당합니다. "이 픽셀이 강아지의 일부인가, 배경인가?"를 묻습니다. 객체의 위치와 경계선을 정확히 파악해야 하므로 공간 정보 보존이 필수적입니다.

[Design Intent]

Classification은 정보를 압축하여 추상화하는 것이 목적이지만, Segmentation은 압축된 정보를 다시 원래의 해상도로 복원(Up-sampling)하는 고도의 연산 설계가 필요합니다. 이는 백엔드에서 대용량 데이터를 집계(Aggregate)만 할 것인지, 다시 상세 이력으로 풀어서 제공할 것인지의 설계 차이와 맥락을 같이 합니다.

2. Fully Convolutional Networks (FCN)

FCN은 현대 Segmentation 모델의 조상 격으로, 기존 CNN 분류 모델의 한계를 '구조적 전환'으로 해결했습니다.

핵심 특징: 기존 CNN 끝단에 붙던 Fully Connected Layer(FC Layer)를 제거하고, 이를 $1 \times 1$ Convolution으로 대체했습니다.
차이점:
1. 입력 사이즈의 자유: FC Layer가 없으므로 입력 이미지 크기에 제한을 받지 않습니다.
2. 공간 정보 유지: 1차원 벡터로 펼치지 않고 2차원 특징 맵(Feature Map)을 유지하므로, 픽셀 위치 정보를 끝까지 보존할 수 있습니다.
3. Transposed Convolution: 줄어든 특징 맵을 다시 키우는 과정을 통해 최종적으로 입력과 같은 크기의 Segmentation Map을 생성합니다.

3. GAN (Generative Adversarial Networks)

GAN은 두 모델이 서로 경쟁하며 성장하는 게임 이론(Game Theory) 기반의 아키텍처입니다.

생성자 (Generator): 무작위 노이즈로부터 가짜 데이터를 생성합니다. 판별자를 속이는 것이 목표입니다.
판별자 (Discriminator): 들어온 데이터가 실제 데이터(Real)인지 생성자가 만든 가짜(Fake)인지 구분합니다.
학습 원리: 생성자는 판별자를 속이려 하고, 판별자는 더 정교하게 가짜를 잡아내려 합니다. 이 과정에서 생성자는 실제 데이터의 분포를 학습하게 됩니다.

4. Diffusion Model의 활용과 장점

최근 생성 AI의 대세인 Diffusion 모델은 GAN과는 완전히 다른 확률적 접근을 취합니다.

활용 방식: 데이터에 점진적으로 노이즈를 추가하여 완전한 노이즈 상태로 만든 뒤(Forward Process), 이를 다시 역으로 계산하여 노이즈를 제거하며 데이터를 복원(Reverse Process)하는 과정을 학습합니다.
주요 장점:
1. 학습 안정성: GAN은 생성자와 판별자의 균형이 깨지면 학습이 무너지는 'Mode Collapse' 문제가 빈번하지만, Diffusion은 목적 함수가 명확하여 학습이 훨씬 안정적입니다.
2. 고품질 생성: 데이터의 전체적인 분포를 더 세밀하게 학습하므로, GAN보다 훨씬 정교하고 다양한 결과물을 만들어냅니다.

위클리 페이퍼 8

goodella — Mon, 9 Mar 2026 01:36:36 +0900

1. YOLO(You Only Look Once) 모델의 주요 특징과 장점

YOLO는 객체 인식(Object Detection) 분야에서 한 획을 그은 모델로, 이름처럼 이미지를 단 한 번만 보고 그 안에 무엇이 어디에 있는지 즉시 찾아내는 방식입니다.

주요 특징

One-Stage Detector: 기존 모델들이 물체가 있을 법한 위치를 먼저 찾고(Region Proposal) 나중에 분류(Classification)를 하던 것과 달리, YOLO는 이 과정을 하나의 네트워크에서 동시에 수행합니다.
Grid 기반 검출: 이미지를 일정 크기의 그리드(Grid)로 나누고, 각 그리드 셀에서 물체의 중심점과 크기(Bounding Box), 그리고 해당 물체가 무엇일 확률을 직접 예측합니다.
Global Context 활용: 이미지 전체를 한꺼번에 학습하기 때문에 물체뿐만 아니라 주변 배경의 정보까지 함께 파악하여, 배경을 물체로 오인하는 오류가 상대적으로 적습니다.

주요 장점

압도적인 실시간성: 연산 과정이 매우 단순하고 효율적이어서 초당 프레임 수(FPS)가 매우 높습니다. 이는 자율주행이나 실시간 보안 관제 시스템에 가장 적합한 이유가 됩니다.
높은 범용성: 일반적인 사진 데이터뿐만 아니라 예술 작품이나 자연 경관 등 새로운 도메인의 이미지에서도 특징을 아주 잘 잡아내어 일반화 성능이 뛰어납니다.

2. mAP(mean Average Precision)의 개념과 활용

객체 인식 모델의 성능을 단순히 '정확도'로만 평가하기에는 한계가 있습니다. 이를 보완하기 위해 mAP라는 정교한 평가지표를 사용합니다.

mAP의 핵심 개념

Precision(정밀도) & Recall(재현율): 모델이 '정답'이라고 한 것 중 실제 정답 비율(Precision)과, 실제 정답들 중 모델이 찾아낸 비율(Recall)을 먼저 계산합니다.
AP(Average Precision): 정밀도와 재현율 사이의 관계를 나타낸 PR 곡선(Precision-Recall Curve) 하단의 면적을 의미하며, 특정 클래스에 대한 모델의 성능을 수치화한 것입니다.
mAP(mean AP): 각 클래스별로 계산된 AP 값들의 산술 평균을 낸 최종 점수입니다. 이 수치가 높을수록 모델이 여러 사물을 골고루 잘 맞춘다는 뜻입니다.

객체 인식에서의 활용

모델 간 성능 비교: 서로 다른 알고리즘(예: YOLO v8 vs v10)의 우열을 가릴 때 객관적인 벤치마크 지표로 활용됩니다.
임계값(Threshold) 최적화: 예측한 박스가 정답과 얼마나 겹쳐야 맞춘 것으로 인정할지(IoU) 기준을 정하고, 그에 따른 mAP 변화를 분석하여 최적의 모델 설정을 찾습니다.
학습 조기 종료 지표: 에폭(Epoch)이 진행됨에 따라 mAP가 더 이상 상승하지 않는 지점을 포착하여 과적합(Overfitting)을 방지하는 기준으로 삼습니다.

딥러닝 시스템 설계 시 가장 중요한 것은 성능(mAP)과 속도(Latency) 사이의 Trade-off
를 이해하는 것입니다.YOLO는 약간의 정확도를 희생하더라도 실시간성을 확보하여 '현장에서 쓸 수 있는 AI'를 만드는 데 초점을 맞추었습니다. 따라서 단순히 높은 mAP 수치에만 집착하기보다, 실제 서비스가 돌아갈 하드웨어 환경과 실시간 요구사항을 고려하여 가장 적합한 모델 파라미터를 결정할 수 있는 안목이 중요합니다.