1. 왜 LLM 서빙이 어려운가 최근 몇 년간 Claude, GPT-4, Llama 같은 대형 언어 모델을 프로덕션 환경에서 서빙하는 요구가 폭발적으로 증가했습니다. 하지만 실제로 모델을 서버에 올려 운영해보면, GPU 메모리 부족 문제에 빠르게 직면하게 됩니다. 일반적인 이미지 분류 모델이나 음성 인식 모델은 고정된 크기의 입력을 받아 한 번에 추론합니다. 하지만 LLM은 근본적으로 다릅니다. 텍스트를 생성할 때 토큰을 하나씩 순차적으로 출력하는 자기회귀(Autoregressive) 방식을 사용하기 때문에, 매 토큰 생성마다 이전에 나온 모든 토큰의 정보를 다시 참조해야 합니다. ...
1. 왜 비디오 RAG인가: 텍스트 RAG를 넘어서 텍스트 RAG(Retrieval-Augmented Generation)는 이미 성숙한 기술입니다. 문서를 청크로 나누고, 임베딩하고, 벡터 데이터베이스에 저장한 뒤, 쿼리와 유사한 청크를 검색해 LLM의 응답을 보강하는 패턴이 확립되어 있습니다. 하지만 기업 데이터의 상당 부분은 텍스트가 아닌 비디오입니다. CCTV 녹화, 회의 녹화, 교육 콘텐츠, 마케팅 영상 등 비디오 형태로 축적된 정보는 방대합니다. Statista 조사에 따르면 2025년 기준 전 세계 인터넷 사용자의 94.6%가 매월 온라인 비디오를 시청하고 있습니다. 이러한 배경에서 VideoRAG 논문(Jeong et al., 2025, ACL Findings)이 비디오 RAG 프레임워크를 제안했습니다. 기존 접근법은 비디오를 텍스트로 변환할 때 멀티모달 정보가 손실되거나, 쿼리 기반 검색 없이 사전에 정의된 비디오만 사용하는 한계가 있었습니다. ...
1. 왜 VLM 파인튜닝인가 Vision Language Model(VLM)은 이미지를 보고 텍스트로 대답하는 멀티모달 AI입니다. GPT-4o, Claude Sonnet 4.6 Vision, Gemini Pro Vision 같은 범용 모델들이 일반적인 질문에는 잘 답하지만, 특정 도메인에서는 한계가 있습니다. 범용 VLM의 한계 건설 현장 안전 관리 시스템을 설계한다고 가정해봅시다. 범용 VLM에게 현장 사진을 보여주고 “안전모를 착용하지 않은 작업자가 있나요?“라고 물으면 일반적인 안전모는 감지하지만, 해당 건설사의 특정 안전 규정(색상별 직급 구분, 반사띠 부착 여부, 턱끈 체결 상태)까지는 판단하지 못합니다. ...
📌 이 글에서 다루는 Nova Forge SFT 실험의 전체 코드와 데이터셋은 GitHub 레포에서 확인할 수 있습니다. 1. 왜 Fine-tuning인가: RAG vs Fine-tuning 판단 기준 대규모 언어 모델을 특정 도메인이나 태스크에 맞추려 할 때, 두 가지 주요 접근법이 있습니다. Retrieval-Augmented Generation(RAG)과 Fine-tuning입니다. RAG가 적합한 경우 최신 정보나 사실 지식이 필요한 경우 (예: 제품 카탈로그, 법률 문서) 지식이 자주 변경되는 경우 출처 추적이 중요한 경우 (환각 방지) 프롬프트만으로 해결 가능한 경우 Fine-tuning이 적합한 경우 일관된 스타일이나 포맷을 학습해야 하는 경우 (예: 브랜드 톤, 응답 구조) 복잡한 추론 패턴을 학습해야 하는 경우 새로운 행동 양식을 학습해야 하는 경우 (예: 코드 생성 스타일) 레이턴시가 중요한 경우 (RAG의 검색 오버헤드 제거) 간단히 말하면, 무엇을 아는가(knowledge)의 문제라면 RAG를, 어떻게 행동하는가(behavior)의 문제라면 Fine-tuning을 선택하는 것이 일반적입니다. ...
음성 AI를 처음 만났을 때 새 학기가 시작되고 음성 인터페이스 수업 첫 강의를 들었습니다. ChatGPT Voice를 쓰면서 “이거 신기하네” 정도로만 생각했는데, 막상 원리를 배우려니 생각보다 깊은 세계더군요. 첫 수업에서 교수님이 이런 질문을 던졌습니다. “텍스트에서 음성 파형을 바로 만들면 되지, 왜 굳이 여러 단계를 거칠까?" 생각해보면, 같은 “안녕하세요"도 누가 말하느냐에 따라 톤이 다르고, 감정에 따라 속도와 억양이 달라집니다. 텍스트에는 이런 정보가 없죠. 그래서 TTS는 텍스트 → 음성 특징(Mel-spectrogram) → 최종 파형이라는 중간 단계를 거칩니다. ...
1. 왜 분산해야 하나? 2012년 구글의 DistBelief 논문 이후, 딥러닝 모델과 데이터셋은 빠르게 커졌습니다. GPT-3는 1750억 개의 파라미터를 가지고 있고, 최신 멀티모달 모델은 수조 개의 토큰으로 학습됩니다. 단일 GPU 메모리로는 감당할 수 없습니다. 그런데 “여러 노드에서 학습한다"는 전제는 같지만, 목적은 다릅니다. 분산 학습(Distributed Training)은 속도가 목적입니다. 중앙 데이터센터에서 데이터를 여러 GPU로 분할하여 학습 시간을 단축합니다. Facebook은 2017년 논문에서 ImageNet을 1시간 만에 학습했다고 보고했습니다. 연합 학습(Federated Learning)은 프라이버시가 목적입니다. 데이터를 중앙으로 모을 수 없을 때, 모델을 각 클라이언트로 보내서 로컬 학습 후 결과만 집계합니다. 구글 키보드는 사용자의 타이핑 데이터를 서버로 보내지 않고도 예측 모델을 개선합니다. ...
1. 1M 시대의 도래 Anthropic은 2025년 Claude Sonnet 4.5에서 처음 1M 토큰 컨텍스트 윈도우를 도입했고, 이후 Opus 4.6(2025), Sonnet 4.6(2026년 2월)까지 이어지며 1M 컨텍스트가 표준으로 자리 잡았습니다. 단일 요청으로 약 750페이지 분량의 문서를 처리할 수 있습니다. Amazon Bedrock에서도 context-1m 베타 기능이 활성화되면서, 기업 환경에서도 대규모 문서 처리가 가능해졌습니다. 200K 토큰으로도 충분히 넓다고 생각했던 시절이 불과 1년 전입니다. 그런데 1M 토큰이 주어진 지금, 과연 모든 작업에 긴 컨텍스트를 사용하는 것이 최선일까요? 많은 개발자들이 “길면 길수록 좋다"는 직관을 따르지만, 실제로는 컨텍스트 길이가 늘어날수록 성능이 떨어지는 현상이 연구를 통해 확인되었습니다. ...
들어가며 - LLM은 아는 것을 말하는 게 아니라 확률적으로 생성한다 ChatGPT나 Claude에 같은 질문을 두 번 던져 보신 적 있으신가요? 분명 동일한 프롬프트인데, 돌아오는 답변의 문장 구조나 단어 선택이 미묘하게 달라집니다. 처음에는 버그처럼 느껴질 수 있지만, 이것은 LLM의 근본적인 작동 원리에서 비롯된 의도된 설계입니다. LLM은 질문에 대한 정답을 데이터베이스에서 꺼내오는 시스템이 아닙니다. 주어진 문맥을 바탕으로 다음에 올 토큰의 확률 분포를 계산하고, 그 분포에서 하나를 샘플링하는 과정을 반복합니다. 면이 수만 개인 주사위를 매 토큰마다 새로 깎아서 굴리는 셈입니다. ...
1. 코딩 에이전트 시대, 왜 비교가 필요한가 2025년 하반기부터 AI 코딩 에이전트 시장이 급격히 달라졌습니다. 단순 코드 자동완성을 넘어, 프로젝트 구조를 설계하고 테스트를 작성하며 배포까지 수행하는 에이전틱(agentic) 코딩 도구가 본격적으로 등장했습니다. 문제는 선택지가 너무 많다는 것입니다. Cursor, Windsurf, Claude Code, Kiro, Copilot, Devin, Google Antigravity 등 수십 개의 도구가 저마다 “최고의 코딩 에이전트"를 표방하고 있습니다. 벤치마크 숫자만 보면 어떤 도구가 좋은지 판단하기 어렵습니다. SWE-bench에서 80%를 달성한 모델이 실제 프로젝트에서도 80%의 문제를 해결해 주는 것은 아니기 때문입니다. ...
1. 들어가며: LLM API 호출만으로는 부족한 이유 최근 개발 워크플로우에 LLM을 도입하는 팀이 빠르게 늘고 있습니다. 대부분의 첫 시도는 Anthropic API를 직접 호출하는 아래와 같은 형태일 것입니다. import anthropic client = anthropic.Anthropic() response = client.messages.create( model="global.anthropic.claude-sonnet-4-6", max_tokens=1024, messages=[{"role": "user", "content": "Fix the bug in my auth module"}], ) print(response.content.text) 코드 한 줄의 버그를 잡거나 간단한 유틸 함수를 생성할 때는 이 단순 프롬프트-응답 루프(Single-turn Prompt-Response Loop)만으로도 충분합니다. 하지만 실제로 써보면, 프로덕션 수준의 코딩 작업에서는 금세 벽에 부딪힙니다. 먼저 컨텍스트 유실(Context Loss) 문제가 있습니다. 프로젝트의 디렉터리 구조, 의존성 그래프, 기존 코드 컨벤션 같은 정보가 매 호출마다 사라집니다. 개발자가 매번 수동으로 컨텍스트를 재구성해야 하고, 이는 토큰 낭비이자 품질 저하로 이어집니다. ...