NEGABARO AI
AI/ML 핵심 개념을 정리한 기술 백과사전
기초
신경망이란? 층·가중치·역전파로 학습하는 구조
뉴런을 모방한 연결주의 학습 모델
입력 데이터를 여러 계층(layer)의 가중치를 통해 변환하며, 역전파(backpropagation)로 오차를 줄여나가는 학습 방식
Transformer란? Self-Attention 병렬 처리 구조
RNN의 순차 처리 한계를 어떻게 넘었나
"Attention Is All You Need" — RNN의 순차 처리 한계를 Self-Attention 메커니즘으로 해결하여, 입력 시퀀스 전체를 병렬로 처리하는 아키텍처
AI 전처리 난이도 — 텍스트, 이미지, 오디오, 비디오, 3D 순서로 어려워진다
model(input)은 한 줄이지만, input을 만드는 전처리는 분야마다 완전히 다르다
AI는 전부 model(input) → output이지만, input을 만드는 전처리 난이도가 분야마다 다르다. 텍스트(토큰화 = 룩업)가 가장 쉽고, 이미지(리사이즈 + 정규화), 오디오(STFT + 멜), 비디오(프레임 추출 + 시간 축), 3D(점군 + 복셀) 순서로 어려워진다. AI 공부를 시작하려면 텍스트부터가 맞다.
텍스트 AI 사전학습 모델 카탈로그 — 3줄 코드로 할 수 있는 12가지
감정 분석부터 코드 생성까지 — HuggingFace pipeline 한 줄이면 되는 모델 리스트와 난이도
텍스트는 전처리가 토큰화(룩업 테이블)뿐이라 AI 입문에 가장 적합하다. HuggingFace pipeline으로 감정 분석, 번역, 요약, 질의응답, 텍스트 생성, 코드 생성, NER, 유사도 비교 등 12가지를 3줄 코드로 할 수 있다. 각 태스크별 추천 모델, 크기, 난이도를 정리했다.
HuggingFace pipeline() — AI 모델의 npm이 작동하는 방식
Hub에 100만 개 모델이 등록되어 있고, pipeline()이 이름으로 자동 다운로드해서 추론까지 한다
HuggingFace Hub는 AI 모델의 npm이다. 누구나 모델을 올릴 수 있고, pipeline()이 이름만으로 가중치·토크나이저·설정을 자동 다운로드한다. 텍스트, 오디오, 이미지, 비디오 — 태스크명만 바꾸면 동일한 인터페이스로 100만 개 이상의 모델을 사용할 수 있다.
랩 AI 모델 카탈로그 — 가사 생성, 라임 감지, 플로우 분석까지
GPT-2 랩 파인튜닝 모델 + pronouncing 라임 분석 + 실행 가능한 코드 전부
HuggingFace에 랩 가사 생성 모델이 여러 개 있다. GPT-2를 랩 가사로 파인튜닝한 모델을 pipeline()으로 바로 돌릴 수 있고, pronouncing 라이브러리로 라임 감지·음절 분석도 가능하다. 가사 생성 → 라임 체크 → 플로우 분석까지 전부 코드로 된다.
PyTorch · Hugging Face · Ollama 를 같은 선반에 놓지 마라 — AI 프레임워크는 세 층이다
무엇으로 계산하나 · 무엇으로 모델을 불러오나 · 무엇으로 빠르게 돌리나
AI 프레임워크는 기반 프레임워크(PyTorch) · 모델 라이브러리(HF transformers) · 추론 엔진(llama.cpp · Ollama · vLLM) 세 층으로 나뉜다. 비교는 같은 층 안에서만 한다. Rails 에서 로컬 모델을 쓰려면 결국 Python 서버를 따로 두거나 ONNX 로 부르게 된다.
구조는 회로도, 가중치는 노브 위치 — 그리고 Attention 변형은 n² 을 피하려는 개조다
가중치가 공개되면 바로 쓸 수 있나, GQA 는 왜 긴 문맥에서 필수인가
모델 파일은 설계도(config)와 가중치로 나뉜다. 설계도는 대개 공개돼 있고, 모델의 지식은 전부 가중치에 있다. 회사별 차이 중 구조 쪽은 주로 Attention 개조인데, 모든 토큰이 모든 토큰을 보는 n² 비용과 KV cache 메모리를 줄이려는 것이다.
학습
사전학습(Pre-training)이란? LLM이 범용 지식을 익히는 단계
인터넷 규모 텍스트로 다음 토큰 예측을 반복한다
인터넷 규모의 텍스트 데이터에서 다음 토큰 예측(Next Token Prediction)을 반복하여, 언어의 문법·사실·추론 능력 등 범용 지식을 습득하는 과정
파인튜닝이란? 사전학습 모델을 특정 작업용으로 재학습
범용 모델을 전문가 모델로 바꾸는 추가 학습
Pre-trained 모델의 가중치를 특정 도메인이나 태스크의 데이터로 추가 학습하여, 범용 모델을 전문가 모델로 변환하는 과정
RLHF란? 사람의 평가로 LLM 응답을 다듬는 방법
인간 피드백 기반 강화학습
사람이 「이 답이 저 답보다 낫다」 고 고른 기록으로 보상 모델을 만들고, 그 점수가 오르게 PPO 로 LLM 을 고치는 방법. 이 글을 읽으면 세 단계가 각각 뭘 하는지 알고, 내 일에 SFT · DPO · RLHF 중 무엇이 맞는지 고를 수 있다.
DPO란? RLHF의 보상 모델·PPO를 건너뛰는 정렬 기법
보상 모델 없이 직접 선호도 최적화
「고른 답 / 버린 답」 쌍으로 LLM 을 바로 학습시켜, RLHF 의 보상 모델과 PPO 를 건너뛰는 방법. 이 글을 읽으면 DPO 손실이 무엇을 밀고 당기는지, β 와 loss 숫자를 어떻게 읽어야 하는지, RLHF 대신 언제 써도 되는지 알 수 있다.
LoRA란? 적은 파라미터만 학습하는 파인튜닝
원래 가중치는 고정하고 저랭크 행렬 2개만 더한다
원래 가중치는 얼려 두고 작은 행렬 두 개(B · A)만 학습하는 파인튜닝. 7B 모양 모델에 직접 붙여 세 보니 학습 파라미터는 0.06〜0.6% 였다. 읽으면 내 GPU 에 Full FT · LoRA · QLoRA 중 무엇이 맞는지 고를 수 있다
추론 vs 파인튜닝 — 남의 모델 쓰기와 내 모델 만들기의 차이
pipeline()은 배달 시켜먹기, 파인튜닝은 레시피 받아서 내 입맛에 간 조절하기
추론은 남이 훈련한 모델을 가져다 쓰는 것이고, 파인튜닝은 그 모델을 내 데이터로 재훈련해서 내 모델을 만드는 것이다. 파인튜닝은 처음부터 훈련하는 게 아니라, 이미 잘 훈련된 모델을 베이스로 살짝만 조정하는 것이라 노트북 GPU 하나로도 할 수 있다. 감정 분석이 파인튜닝 입문에 가장 적합하다.
세상에서 가장 간단한 파인튜닝 이해하기 — 합치기가 아니라 조정이다
66M개의 숫자를 살짝 바꾸는 것. 데이터를 모델에 넣는 것도, 모델끼리 합치는 것도 아니다
파인튜닝은 데이터를 모델에 합치는 것도, 모델끼리 더하는 것도 아니다. 이미 완성된 모델의 가중치(66M개의 숫자)를 내 데이터를 보면서 살짝 조정하는 것이다. 대학 졸업생에게 OJT를 시키는 것과 같다 — 대학 교재를 다시 읽히는 게 아니라, 이미 있는 지식 위에서 새 업무를 가르치는 것.
LoRA — 66M개를 전부 바꾸지 말고, 1M개짜리 어댑터만 끼우자
파인튜닝의 효율적 대안 — 베이스 모델은 고정하고, 작은 행렬 2개만 훈련한다
파인튜닝은 66M개 숫자를 전부 조정한다. LoRA는 베이스 모델을 얼려놓고(고정), 옆에 작은 어댑터(1M개)만 훈련한다. 결과 품질은 비슷한데 훈련 시간·메모리·저장 공간이 크게 줄어든다. 마치 스마트폰에 케이스를 끼우는 것 — 폰 자체를 바꾸는 게 아니라 케이스만 교체한다.
RAG — 모델을 재훈련하지 않고 "참고자료"를 붙여주는 방법
검색(Retrieval) + 생성(Generation) — 모델의 가중치는 안 바꾸고 외부 지식을 프롬프트에 첨부
RAG(Retrieval-Augmented Generation)는 모델의 가중치를 전혀 바꾸지 않는다. 대신 질문이 들어오면 관련 문서를 검색해서 프롬프트에 첨부한 뒤 모델에게 넘긴다. 시험 볼 때 오픈북 참고자료를 가져가는 것과 같다. 파인튜닝과 달리 데이터가 바뀌면 문서만 업데이트하면 된다.
모델 머징 — 진짜로 두 모델을 "합치는" 유일한 방법
한국어 모델 + 코딩 모델 = 한국어로 코딩하는 모델? 가중치 평균으로 합친다
모델 머징은 AI에서 유일하게 "합치기"에 해당하는 기법이다. 두 모델의 가중치를 평균내서 하나로 만든다. 한국어 모델과 코딩 모델을 합치면 한국어로 코딩하는 모델이 나올 수 있다. 훈련 없이 합치는 거라 GPU도 필요 없다. 다만 실험적이라 결과가 보장되지 않는다.
추론
프롬프트 엔지니어링이란? 입력 설계로 LLM 출력을 이끄는 법
모델 가중치는 그대로, 입력만으로 성능을 올린다
LLM에 최적의 입력(프롬프트)을 설계하여 원하는 출력을 유도하는 기술. 모델의 가중치를 바꾸지 않고 입력만으로 성능을 극대화
RAG란? 검색한 문서를 붙여 LLM이 답하게 하는 방법
학습 데이터에 없는 최신·전문 지식도 쓸 수 있다
LLM이 답변을 생성하기 전에, 관련 문서를 벡터 DB에서 검색(Retrieval)하여 프롬프트에 첨부한 뒤 생성(Generation)하는 방식. 학습 데이터에 없는 최신/전문 지식도 활용 가능
Chain-of-Thought란? 단계별로 생각하게 하는 프롬프트
수학·논리·코딩 문제에서 효과가 큰 프롬프트 기법
LLM에 "단계별로 생각해보자(Let's think step by step)"라고 지시하여, 중간 추론 과정을 명시적으로 생성하게 하는 프롬프팅 기법. 수학, 논리, 코딩 등 복잡한 문제에서 성능 대폭 향상
Function Calling이란? LLM이 외부 도구를 부르는 구조
함수 스키마를 건네고 → 모델이 인자를 고르고 → 실행 결과를 돌려주는 순서
모델은 함수를 실행하지 않는다. 「이 함수를 이 인자로」 라는 JSON 을 낼 뿐이고 실행은 내 코드가 한다. 읽으면 요청 → 호출 → 실행 → 결과 돌려주기 왕복을 직접 짤 수 있고, 구조화 출력 · MCP 와 무엇이 다른지 가를 수 있다
Jev — 글을 안 쓰는 LLM, 판단만 빠르게
입력은 LLM 처럼 받고 출력은 분류기처럼 낸다. LLM 에게 if 문을 시키던 자리를 가져간다
Jev 는 문장 대신 정해진 선택지별 확률만 돌려주는 모델이다. 태스크마다 학습이 필요 없는 분류기처럼 쓸 수 있고, 확률로 「자동 확정 / 사람 확인 / 넘기기」를 가르는 게 핵심이다. 이유를 남겨야 하는 일엔 안 맞는다.
스케일링 & 최적화
양자화(Quantization)란? 가중치 정밀도를 낮춰 모델을 가볍게
FP32·FP16을 INT8·INT4로 바꿔 메모리를 아낀다
FP32(32비트)나 FP16(16비트)으로 저장된 모델 가중치를 INT8(8비트) 또는 INT4(4비트)로 변환하여, 모델 크기와 메모리 사용량을 1/2~1/8로 줄이는 최적화 기법
지식 증류란? 큰 모델의 지식을 작은 모델로 옮기는 방법
Teacher의 출력 분포를 Student가 따라 배운다
큰 모델(Teacher)의 출력 분포(soft label)를 작은 모델(Student)이 따라하도록 학습시켜, 소형 모델이 대형 모델의 성능에 근접하게 만드는 기법
MoE란? 전문가 일부만 켜서 큰 모델을 싸게 돌리는 구조
라우터가 토큰마다 전문가를 고른다 — Mixtral 8x7B 예시
하나의 거대한 모델 대신, 여러 전문가(Expert) 네트워크 중 일부만 활성화하여 처리하는 구조. 전체 파라미터는 크지만 실제 연산은 일부분만 수행
투기적 디코딩이란? 작은 모델의 초안으로 추론을 빠르게
큰 모델은 초안을 한꺼번에 검증만 한다
빠른 소형 모델(Draft Model)이 여러 토큰을 한 번에 생성하고, 느린 대형 모델(Target Model)이 한꺼번에 검증/수정하여 추론 속도를 2~3배 향상시키는 기법
Azure OpenAI Batch 가 어느 날 전부 500 — 입력 파일 500개 한도와 그 400 을 덮은 중간 API
지우기 · 만료 걸기 · 주기 청소 중 무엇을 고를까, 그리고 4xx 를 뭉개지 않는 법
Batch API 의 입력 파일은 쓰고 나도 남는다. 만료를 안 걸면 리소스당 500개에서 업로드가 막히고, 그 400 을 중간 API 가 500 으로 바꾸면 원인은 두 겹으로 숨는다. 이 글을 읽으면 지금 내 리소스가 언제 막힐지 계산하고, 업로드 한 줄로 막을 수 있다.
멀티모달
Vision-Language 모델이란? 이미지를 보고 답하는 AI의 구조
이미지 인코더(ViT)와 LLM의 조합
이미지 인코더(ViT)와 언어 모델(LLM)을 결합하여, 이미지를 보고 설명하거나, 이미지에 대한 질문에 답변하는 멀티모달 AI
확산 모델이란? 노이즈를 조금씩 지워 이미지를 만드는 구조
노이즈를 더하는 과정을 거꾸로 학습한다
이미지에 점진적으로 노이즈를 추가하는 과정을 역으로 학습하여, 순수 노이즈에서 시작해 단계적으로 노이즈를 제거하며 이미지를 생성하는 기법
TTS(텍스트 음성 합성)란? 글자를 자연스러운 음성으로 바꾸는 기술
LLM과 결합해 감정·억양·다국어까지
텍스트 입력을 자연스럽고 표현력 있는 음성으로 변환하는 기술. 최근에는 LLM과 결합하여 감정, 억양, 다국어를 자연스럽게 처리
에이전트 & 도구 활용
AI 에이전트란? LLM이 계획하고 도구를 쓰며 움직이는 구조
계획→도구 호출→관찰→다음 행동의 반복
LLM을 "두뇌"로 하여, 계획 수립 → 도구 호출 → 결과 관찰 → 다음 행동 결정을 반복하며 복잡한 태스크를 자율적으로 수행하는 시스템
MCP란? AI와 도구의 N×M 연결을 하나로 묶는 표준
AI와 외부 도구를 연결하는 표준 프로토콜
Anthropic이 공개한 오픈 프로토콜로, AI 모델과 외부 도구(DB, 파일, API)를 표준화된 방식으로 연결. USB-C처럼 "하나의 규격으로 모든 도구"를 연결
평가 주도 개발이란? Eval 결과로 AI 시스템을 고쳐 가는 방법
프롬프트·모델·RAG 변경을 자동 평가로 잰다
프롬프트, 모델, RAG 파이프라인 등의 변경이 성능에 미치는 영향을 자동화된 평가(Eval)로 측정하고, 데이터 기반으로 개선하는 개발 방법론
리뷰어는 같은데 결과가 다르다 — AI 구현 품질은 리뷰 앞에서 갈린다
「만들어」 한 마디로 PR 까지 가던 방식과 설계 승인 하네스를 나란히 놓고 보니
AI 에게 코드를 맡길 때 품질 차이는 리뷰어 성능이 아니라, 코드를 쓰기 전에 사람이 무엇을 승인했는지와 사람이 처음 보는 PR 이 이미 걸러졌는지에서 난다. 문구 하나면 그냥 「만들어」, 설계 선택지나 DB 변경이 있으면 하네스.
AI 에게 본번 DB 를 보여줄 때 — 쓰기는 프롬프트가 아니라 DB 권한으로 막는다
exec 가 이미 있는데 조사용 리플리카와 발판 서버를 따로 만든 이유, 그리고 PostgreSQL 에서 직접 확인한 것
AI 에이전트에게 「읽기만 해」 는 확률적인 약속이다. 세션의 read-only 설정도 SET 한 줄로 꺼진다. 이 글을 읽으면 무엇이 진짜로 쓰기를 거부하는지 알고, AI 조사용 DB 접속을 어떤 층까지 떼어 놓을지 정할 수 있다.
에이전트에게 부탁하지 말고 훅으로 강제하라 — oh-my-openagent 코드를 읽고 내 하네스에 가져온 것
실패 하나에 훅 하나를 붙여 57개까지 쌓은 하네스, 그리고 훅끼리 부딪혀 결국 문을 하나로 모은 이야기
「편집 전에 다시 읽어」 「TODO 남기고 멈추지 마」 를 프롬프트에 쓰면 대부분 지킨다. 대부분만. OpenCode 플러그인 oh-my-openagent 는 이걸 훅 코드로 막는다. 이 글을 읽으면 어떤 규칙을 훅으로 옮길지 고를 수 있고, Claude Code Stop 훅으로 바로 따라 해 볼 수 있다.
안전성 & 정렬
AI 정렬이란? AI를 사람의 의도대로 움직이게 하는 연구
Helpful·Harmless·Honest라는 세 가지 목표
AI 시스템이 인간이 원하는 대로 행동하도록 보장하는 연구 분야. "도움이 되고(Helpful), 무해하며(Harmless), 정직한(Honest)" 시스템을 목표로 함
Constitutional AI란? 원칙으로 AI가 응답을 스스로 고치게
Anthropic의 기법 — RLHF의 사람 손을 크게 줄인다
Anthropic이 개발한 정렬 기법. 사람이 직접 피드백하는 대신, AI에 "헌법(원칙)"을 주고 스스로 자신의 응답을 비판·수정하게 하여 RLHF의 인간 노동을 대폭 줄인 방법
할루시네이션(환각)이란? AI가 그럴듯한 거짓을 만드는 이유
다음 토큰 예측이라는 학습 방식에서 오는 한계
LLM이 학습 데이터에 없거나 사실이 아닌 정보를 자신감 있게 생성하는 현상. 다음 토큰 예측이라는 학습 방식의 본질적 한계에서 비롯됨
음성 & 오디오 AI
오디오 토큰화란? 코덱이 소리를 토큰으로 바꾸는 원리
EnCodec·SoundStream과 RVQ — 요즘 TTS가 LLM처럼 돌아가는 이유
연속적인 오디오 파형을 VQ-VAE 기반 코덱(EnCodec, SoundStream 등)으로 이산 토큰 시퀀스로 변환하여, 텍스트처럼 Transformer로 생성·이해할 수 있게 하는 기술
음성 모델의 진화
규칙 기반 → 딥러닝 파이프라인 → 토큰 기반 → 통합 멀티모달
음성 합성(TTS) 기술의 발전사: 1세대(규칙/연결 합성) → 2세대(통계적 파라메트릭) → 3세대(딥러닝 멜 스펙트로그램 파이프라인) → 4세대(토큰 기반 LLM 방식) → 미래(통합 멀티모달)
GPT-SoVITS 코드로 보는 사전학습과 파인튜닝
오픈소스 음성 합성 프로젝트를 읽는다
GPT-SoVITS 오픈소스 프로젝트를 통해 Pre-training(사전학습)과 Fine-tuning(미세조정)이 실제 코드에서 어떻게 구현되는지 분석하는 케이스 스터디
Demucs 코드 분석 — 하나의 노래를 보컬·드럼·베이스·기타로 분리하는 방법
Meta/Facebook Research의 Hybrid Transformer 음원 분리 모델 — 아키텍처, 추론 파이프라인, 실전 활용
Demucs는 Meta(Facebook Research)가 만든 오픈소스 음원 분리 모델이다. 하나의 완성된 곡을 보컬, 드럼, 베이스, 기타(other) 4개 스템으로 분리한다. 현재 버전 htdemucs는 시간 도메인 인코더-디코더와 주파수 도메인 Transformer를 결합한 하이브리드 아키텍처다.
Mel-Band RoFormer Karaoke 모델 분석 — 리드 보컬만 골라내는 913MB의 비밀
RoPE + 멜 스케일 주파수 분해 + 계층적 시간·주파수 Transformer — 코드와 설정까지
UVR 커뮤니티의 aufr33+viperx가 훈련한 Mel-Band RoFormer Karaoke 모델은 913MB짜리 PyTorch 체크포인트다. 리드 보컬만 분리하고 백킹 보컬은 반주에 남기는 카라오케 전용 모델. 60개 멜 밴드로 주파수를 분해하고, 시간·주파수 축을 교대로 처리하는 계층적 Transformer가 핵심이다. SDR 10.1956.
UVR Mel-Band RoFormer vs Demucs — 음원 분리 모델 비교 분석
카라오케 전용 2-스템 vs 범용 4-스템 — 아키텍처, 학습 데이터, 성능, 실전 선택 기준
음원 분리에 가장 많이 쓰이는 두 모델의 비교. UVR Mel-Band RoFormer Karaoke는 리드 보컬만 분리하는 913MB 카라오케 전용 모델이고, Demucs htdemucs는 보컬·드럼·베이스·기타 4-스템으로 분리하는 80MB 범용 모델이다. 쓰임새가 다르다.
음원 분리 2분 가이드 — Demucs와 UVR Karaoke를 로컬에서 바로 돌리기
실측 기반 비교 — 설치, 실행, 처리 시간, 출력 파일까지 직접 돌려본 결과
Demucs와 UVR Karaoke를 로컬에서 직접 설치하고 돌려봤다. Demucs는 pip install 한 줄 + 실행 한 줄, 모델 80MB, 10초 오디오를 10초에 처리. UVR Karaoke는 모델 913MB, 같은 오디오를 43초에 처리. 간단한 건 Demucs, 노래방 품질은 UVR.
오디오 AI의 공통 기반 기술 — Demucs, Mel-Band RoFormer, GPT-SoVITS가 공유하는 것들
STFT 스펙트로그램, Transformer 어텐션, 인코더-디코더, PyTorch — 오디오 AI의 공통 DNA
음원 분리(Demucs, Mel-Band RoFormer)와 음성 합성(GPT-SoVITS)은 목적이 다르지만 기반 기술이 같다. STFT로 오디오를 주파수 도메인으로 변환하고, Transformer로 장거리 의존성을 잡고, 인코더-디코더로 분해/복원한다. 이 공통 DNA를 이해하면 오디오 AI 전체가 보인다.
오디오 AI Hello World — 사전 훈련 모델로 5분 만에 해보는 7가지 프로젝트
pip install 한 줄 + 코드 3줄로 음원 분리, 음성 인식, TTS, 피치 감지, 음악 생성까지
훈련 없이, GPU 없이, 코드 3줄로 오디오 AI를 체험할 수 있다. 음원 분리, 음성 인식, TTS, 피치 감지, 음악 태깅, 소리 분류, 음악 생성 — 전부 사전 훈련된 모델을 다운로드해서 바로 돌리는 것만으로 결과가 나온다.
input → 사전학습 모델 → output — AI 추론의 본질은 이 한 줄이다
STFT도 마스킹도 잊어라 — 모델이 하는 일은 딱 하나, 입력을 받아 출력을 내는 것
오디오 AI 파이프라인에서 STFT, 마스킹, ISTFT는 전부 수학이다. 신경망이 하는 일은 딱 한 줄 — model(input)으로 output을 내는 것. 음원 분리, 음성 인식, 음성 합성, 소리 분류 전부 이 구조다. 사전 훈련된 모델을 불러와서 input을 넣으면 output이 나온다.
보이스 클로닝은 학습이 아니라 프롬프트다 — 요즘 TTS 는 소리를 토큰으로 바꾼 LLM
Fish Audio API 필드를 읽다 알게 된 것 — 목소리는 모델 id 가 아니라 참조 음성으로 넘긴다
요즘 TTS 는 오디오를 코덱 토큰으로 바꿔 LLM 처럼 다음 토큰을 맞힌다. 그래서 「내 목소리로 말하기」 는 모델을 새로 학습하는 일이 아니라 참조 음성을 프롬프트 앞에 붙이는 일이다. Fish Audio API 의 필드 이름이 그걸 그대로 보여 준다.
OCR & 문서 AI
OCR 오픈소스 카탈로그 — 이미지에서 텍스트를 뽑는 모든 방법
Tesseract부터 EasyOCR, PaddleOCR, Surya, TrOCR, Qwen2-VL까지 — 난이도·언어·속도 비교
OCR은 완전히 신경망 분야다. 이미지 → model(image) → 텍스트. 가장 쉬운 EasyOCR(3줄, 80개 언어)부터, CJK 최강 PaddleOCR, 최신 고정밀 Surya, Transformer 기반 TrOCR, 멀티모달 LLM(Qwen2-VL)까지 정리했다.
PDF 특화 OCR — 복잡한 레이아웃·표·수식을 Markdown으로 변환하는 도구들
Marker, Docling, MinerU, Nougat, olmOCR — PDF를 LLM이 읽을 수 있는 형태로
일반 OCR은 이미지에서 텍스트를 뽑지만, PDF는 더 복잡하다 — 다단 레이아웃, 표, 수식, 코드 블록, 머리글/바닥글. PDF 특화 도구는 이런 구조를 이해하고 Markdown/JSON으로 변환한다. RAG 파이프라인의 첫 단계로 필수.
계약서·법률 문서 특화 OCR — 조항 추출, 당사자 식별, 구조화
Legal-BERT · CUAD · LayoutLMv3 로 계약서를 구조화하고, API 와 로컬을 어디서 나눌지까지
계약서 OCR 은 글자를 뽑는 것보다 뽑은 글에서 조항 · 당사자 · 기한을 꺼내는 쪽이 본론이다. OCR → 필드 추출 → 조항 분류는 정형 작업이라 작은 모델이나 로컬로 충분하고, 「불리한 조항 찾기」 같은 열린 해석만 대형 LLM API 에 맡긴다. API 냐 로컬이냐는 성능보다 반출 가능 여부 · 정형성 · 건수로 갈린다.
일본어 특화 OCR — 만화, 세로쓰기, 후리가나, 고문서까지
manga-ocr, Sarashina2.2-OCR, PaddleOCR, KuroNet — 일본어 OCR의 모든 선택지
일본어 OCR이 어려운 이유: 세로쓰기(縦書き), 후리가나, 히라가나·카타카나·한자 혼용, 만화 특유의 폰트. manga-ocr(만화 전용), Sarashina2.2-OCR(일본어 문서 최고 정밀도), PaddleOCR(범용 CJK), KuroNet(고문서/くずし字) — 용도별 추천.
OCR 파인튜닝 입문 — 일본어 부동산 계약서를 읽는 내 모델 만들기
TrOCR + Trainer.train() — 감정 분석 파인튜닝과 완전히 같은 패턴이다
OCR 파인튜닝은 감정 분석 파인튜닝과 구조가 같다. input이 텍스트에서 이미지로 바뀌었을 뿐, Trainer.train()으로 모델의 가중치를 조정하는 것은 동일하다. TrOCR(ViT 인코더 + 텍스트 디코더)이 가장 쉽다 — HuggingFace 표준 인터페이스 그대로.
OCR API 카탈로그 — 모델 관리 없이 API 한 줄로 텍스트 추출
Google Vision, Azure Document Intelligence, AWS Textract, Clova OCR — 가격·정확도·코드 비교
모델을 직접 설치·관리하지 않고 API 호출만으로 OCR을 할 수 있다. Google Cloud Vision(정확도 최고), Azure Document Intelligence(계약서·영수증 특화 모델), AWS Textract(표 구조화 강함), Naver Clova OCR(한국어 최강) — 각각의 코드 예제와 가격을 비교했다.
일본어 계약서 OCR 벤치마크 — API vs 오픈소스, 어느 쪽이 나은가
Google Vision, Azure, PaddleOCR, Sarashina2.2 — 일본어 계약서로 정확도·속도·가격 비교
일본어 부동산 계약서를 기준으로 API(Google Vision, Azure)와 오픈소스(PaddleOCR, Sarashina2.2-OCR, manga-ocr)의 성능을 비교한다. 정확도는 Google Vision ≈ Sarashina2.2 > PaddleOCR > Azure > EasyOCR 순. 비용은 오픈소스 0원 vs API 페이지당 과금.
OCR 종합 비교 — API vs 오픈소스 vs 파인튜닝, 뭘 써야 하나
3가지 접근법의 정확도·비용·보안·난이도·유지보수를 한 장으로 비교
OCR을 구현하는 3가지 방법: API 호출(Google Vision 등), 오픈소스 셀프호스팅(EasyOCR, PaddleOCR 등), 파인튜닝(TrOCR, manga-ocr). 정확도·비용·보안·난이도·유지보수 5가지 축으로 비교하면 상황에 따라 최적 선택이 달라진다.
Azure Document Intelligence 전용 모델 전체 정리 — 영수증부터 계약서까지 15개 모델
prebuilt-read, prebuilt-receipt, prebuilt-contract, prebuilt-invoice — 모델명만 바꾸면 구조화된 데이터가 나온다
Azure Document Intelligence는 단순 OCR이 아니다. 문서 타입별 전용 모델이 15개 이상 있다. 영수증을 넣으면 가게명·날짜·금액이, 명함을 넣으면 이름·직함·전화번호가, 계약서를 넣으면 당사자·관할권·조항이 구조화된 JSON으로 나온다. 모델명만 바꾸면 된다.
문서 구조화 추출 API 비교 — Azure, Google, AWS 각각 뭘 제공하나
Azure prebuilt-contract 같은 "문서를 이해하는 API"가 Google과 AWS에도 있나?
Azure의 prebuilt-contract처럼 '문서 타입별로 필드를 구조화 추출하는 API'는 Google(Document AI)과 AWS(Textract)에도 있다. 다만 제공하는 문서 타입, 지원 언어, 가격이 전부 다르다. Azure는 전용 모델이 가장 많고, Google은 커스텀 프로세서가 강하고, AWS는 표 추출에 특화돼 있다.
평가 & 검증
AI 모델 평가 입문 — 내 모델이 잘하는지 어떻게 아나?
정확도, BLEU, CER, SDR — 태스크마다 다른 평가 지표와 "왜 이걸 쓰는지"
모델을 훈련했으면 평가해야 한다. 근데 태스크마다 평가 방법이 다르다. 분류는 정확도(맞았나 틀렸나), 생성은 BLEU(원본과 얼마나 비슷한가), OCR은 CER(글자 오류율), 음원 분리는 SDR(신호 왜곡비). 전부 숫자 하나로 귀결된다 — 높을수록 좋거나, 낮을수록 좋거나.
태스크별 평가 치트시트 — 어떤 지표를 써야 하는지 한눈에
분류→Accuracy/F1, 생성→BLEU/ROUGE, OCR→CER/WER, 분리→SDR — 코드 포함
태스크에 따라 쓰는 평가 지표가 다르다. 이 치트시트를 보고 자기 태스크에 맞는 지표를 골라 3줄 코드로 바로 측정할 수 있다.
AI 평가 도구 카탈로그 — evaluate, lm-eval-harness, RAGAS, DeepEval
단일 지표 측정부터 LLM 벤치마크, RAG 평가, 자동 테스트 파이프라인까지
단순 지표 측정(evaluate)부터 LLM 벤치마크(lm-eval-harness), RAG 파이프라인 평가(RAGAS), AI 앱 테스트(DeepEval)까지 — 평가 도구도 용도별로 다르다.
로컬 실행
로컬 LLM 도구 카탈로그 — 내 Mac/PC에서 돌리는 AI
Ollama, llama.cpp, LM Studio부터 vLLM까지 — 용도별 정리
API 비용 없이, 데이터 유출 걱정 없이, 인터넷 없이도 LLM을 쓸 수 있다. 2026년 기준 로컬 LLM 생태계는 이미 실용 수준이다. 도구가 너무 많아서 뭘 쓸지가 문제인 정도.
크롬 내장 LLM(Prompt API)은 공짜 API 가 아니다
방문자 GPU 에서 도는, 결과를 믿을 수 없는 연산 — 그래서 보조에만 쓴다
크롬의 LanguageModel API 는 키도 서버도 없이 LLM 을 부르지만, 비용은 방문자 기기로 옮겨 갔을 뿐이고 결과는 클라이언트가 얼마든지 바꿀 수 있다. 「속여도 아무도 손해 안 보는 곳」에만 쓴다.
ONNX 는 모델이 아니라 포장 규격이다 — Xenova 는 BERT 를 만든 게 아니다
누가 학습시켰나와 어떤 상자에 담아 배포하나는 따로 논다
Hugging Face 저장소 이름에 섞여 있는 건 모델을 만든 사람과 포장한 사람이다. ONNX 는 계산 순서와 가중치를 한 파일에 담는 규격이고, Xenova 는 이미 학습된 가중치를 브라우저용으로 다시 담았을 뿐이다. ONNX 변환본이 없는 모델은 transformers.js 에서 바로 못 쓴다.
얼굴 · 아바타 · 영상 AI
말하는 AI 아바타는 모델 하나가 아니다 — STT · LLM · TTS 끝에 얼굴을 붙인 파이프라인, 적은 지연의 합
얼굴 품질보다 먼저 볼 것 — 네 단계의 지연과, 겹쳐서 줄이는 스트리밍
말하는 AI 아바타는 STT → LLM → TTS 로 이어지는 음성 에이전트 끝에 얼굴 생성기를 붙인 것이다. 그래서 체감 품질은 얼굴 모델보다 네 단계 지연의 합이 정한다. 단계별로 재고, 스트리밍으로 겹치고, 끼어들기를 처리하는 순서로 줄인다.
AI 아바타 SDK 는 「어디까지 떼어 낼 수 있나」 로 고른다 — Anam 3모드와 떼어 낼수록 늘어나는 책임
full · custom_llm · passthrough 를 붙여 보며 걸린 것 — 400 에러, PCM 형식, 그리고 API 키는 서버에
AI 아바타 서비스는 얼굴 품질보다 「어느 단계부터 우리가 맡을 수 있나」 로 고른다. Anam 은 full · custom_llm · passthrough 세 모드가 있고, 떼어 낼수록 끼어들기 처리 · 오디오 형식 맞추기가 우리 쪽으로 넘어온다. API 키는 서버에 두고 브라우저엔 세션 토큰만 준다.
FaceFusion 은 방법론이 아니라 부품 조립기다 — 얼굴 바꾸는 기술 4계열 지도
얼굴 교체 · 신원 조건 생성 · 얼굴 재연 · 영상 생성 — 계열이 다르면 비교 대상이 아니다
얼굴을 바꾸는 AI 는 얼굴 교체 · 신원 조건 생성 · 얼굴 재연 · 영상 생성 교체의 4계열이고, 계열이 다르면 서로 비교할 대상이 아니다. FaceFusion 은 그중 얼굴 교체 계열의 도구로, 검출 · 교체 · 보정 모델을 갈아 끼우는 껍데기다. 부품 대부분은 InsightFace 에서 왔고, 모델 라이선스는 비상업 연구용이다.
얼굴 교체가 머리카락을 못 바꾸는 건 성능이 아니라 마스크 범위다 — 모델 여러 개가 릴레이하는 파이프라인
FaceFusion 을 뜯어 보니 — 머리는 처음부터 대상이 아니었고, 깜빡임은 「다른 사람」 판정이었다
얼굴 교체는 검출 · 랜드마크 · 정렬 · 신원 추출 · 교체 · 마스크 · 보정을 모델 여러 개가 이어 받는 파이프라인이다. 교체 모델은 정렬된 얼굴 크롭 안쪽만 그리고 마스크도 얼굴만 오려 붙이므로, 머리카락은 어떤 모델을 써도 바뀌지 않는다. 깜빡임은 reference 모드의 「다른 사람」 판정에서 왔고 one 모드로 바꾸니 사라졌다.
MV 장면에 내 얼굴 넣기 — 다들 하는 방법은 셋인데 푸는 문제가 다르다
FaceFusion · Runway Aleph · Nano Banana Pro + Veo 를 직접 돌려 본 기록 — 하나는 결제 단계에서 막혔다
유명 MV 장면에 자기 얼굴을 넣은 영상은 대부분 얼굴만 바꾸는 방식(FaceFusion 등)이다. 원본 연기 · 조명은 그대로지만 머리는 원본 것이 남는다. 사람 전체를 바꾸려면 Runway Aleph 같은 영상 교체를, 원본과 달라도 되면 첫 프레임을 고쳐 영상을 새로 만드는 방식을 쓴다. 생성형 API 는 유명인 필터에 걸릴 수 있다.
AI 태그는 「무엇이 찍혔나」 가 아니라 「편집에서 어떻게 쓰나」 로 나눈다 — 사진 · 영상 4,341개에 12축
가족 영상을 만들다 소재 고르기에서 막혀 태그 체계를 바꿨다 — 그리고 절반은 눈으로 고쳤다
편집할 때 필요한 질문은 「무엇이 찍혔나」 보다 「오프닝에 쓸 넓은 컷이 있나」 「자막 얹을 여백이 있나」 다. 그래서 태그를 구도 · 여백 · 품질 · 용도 같은 12축 `축:값` 으로 나눴고, 전부 macOS 로컬에서 붙였다. 태그마다 14장씩 눈으로 확인해 보니 첫 규칙 그대로 쓸 수 있는 건 많지 않았다.