🎧 이 글을 팟캐스트로 듣기 브라우저가 오디오 재생을 지원하지 않습니다. “18개월째 실직 상태인데, 저축도 다 떨어졌고, 퇴거 통보를 받았습니다. 어떻게 해야 할지 모르겠어요.” 이런 메시지를 받은 AI 어시스턴트가 “desperate(절박한)” 감정 벡터를 활성화한다면, 그건 진짜 감정일까요? Anthropic 연구진이 2026년 4월 발표한 논문 “Emotion Concepts and their Function in a Large Language Model"은 바로 이 질문에 답하려는 시도입니다. ...
“지난달 서울 지역 매출 상위 10개 제품 보여줘.” 이 한 문장을 SQL로 바꾸는 일, 예전에는 데이터 분석가에게 요청하고 하루를 기다려야 했습니다. 지금은 LLM이 몇 초 만에 해냅니다. Text2SQL(또는 NL2SQL)은 자연어 질문을 실행 가능한 SQL 쿼리로 변환하는 기술입니다. 규칙 기반 파서 시절부터 존재하던 오래된 문제지만, LLM 등장 이후 정확도가 급격히 올라가면서 실제 프로덕션에 투입되기 시작했습니다. 기업 입장에서 Text2SQL은 데이터 민주화의 핵심입니다. SQL을 모르는 마케터, 기획자, 경영진도 자연어로 데이터에 접근할 수 있게 되면, 데이터 팀의 병목이 사라집니다. 2025–2026년 사이에 쏟아진 연구 결과를 바탕으로, 현재 가장 효과적인 접근법들을 정리합니다. ...
1. 여러 모델을 운영하는 비용 프로덕션 환경에서 LLM을 운영하는 팀이라면, 한 가지 모델로 모든 작업을 처리하기 어렵다는 점을 잘 알고 있을 것입니다. 빠른 채팅 응답에는 경량 Instruct 모델을, 복잡한 수학 문제에는 추론 특화 모델을, 이미지 분석에는 멀티모달 모델을, 코드 생성에는 코딩 특화 모델을 각각 배포해야 합니다. 모델마다 별도의 엔드포인트, 라우팅 로직, GPU 할당이 필요하고, 운영 복잡도는 모델 수에 비례해 증가합니다. 2026년 3월 16일, Mistral AI가 공개한 Mistral Small 4는 이 문제에 정면으로 답합니다. 기존에 별도로 존재하던 Instruct(Small 3.2), 추론(Magistral), 비전(Pixtral), 코딩(Devstral) 네 가지 모델 계열을 하나의 MoE 모델로 통합했습니다. 119B 파라미터 규모이지만, 토큰당 실제 연산에 참여하는 파라미터는 6.5B에 불과합니다. Apache 2.0 라이선스로 상업적 사용과 파인튜닝에 제한이 없습니다. ...
Enterprise 환경에서 LLM 기반 시스템을 프로덕션에 배포하려면, 단순히 API를 호출하는 것 이상의 설계가 필요합니다. PoC에서는 잘 동작하던 시스템이 실제 트래픽과 다양한 질의를 만나면 hallucination, 검색 품질 저하, 보안 취약점 같은 문제가 수면 위로 올라옵니다. 이 글에서는 Enterprise LLM 시스템을 설계할 때 반복적으로 등장하는 5가지 핵심 패턴을 정리합니다. 각 패턴은 독립적으로 적용할 수도 있고, 하나의 시스템 안에서 조합할 수도 있습니다. 1. Enterprise RAG: 검색 품질이 답변 품질을 결정합니다 RAG(Retrieval-Augmented Generation)는 LLM이 외부 지식을 참조해서 답변을 생성하는 기법입니다. 원리 자체는 단순하지만, 5만 건 이상의 내부 문서를 다루는 Enterprise 환경에서는 설계 난이도가 급격히 올라갑니다. ...
📌 이 글에서 다루는 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을 선택하는 것이 일반적입니다. ...
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. 추천 시스템, 무엇이 부족한가 추천 시스템(Recommendation System)은 디지털 서비스의 핵심 인프라입니다. Netflix의 콘텐츠 추천, Amazon의 상품 추천, YouTube의 영상 추천까지, 사용자 경험의 상당 부분을 추천 알고리즘이 결정합니다. 이 중 가장 널리 사용되는 방식이 협업 필터링(Collaborative Filtering, CF)입니다. “나와 비슷한 행동을 보인 사용자가 좋아한 아이템을 추천한다"는 단순하지만 강력한 원리입니다. 수십 년간 검증된 이 접근법은 여전히 대규모 프로덕션 시스템의 근간이며, 필자가 이전에 다룬 Amazon Personalize 하이브리드 추천 아키텍처도 이 패러다임 위에 설계된 것입니다. ...
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) 문제가 있습니다. 프로젝트의 디렉터리 구조, 의존성 그래프, 기존 코드 컨벤션 같은 정보가 매 호출마다 사라집니다. 개발자가 매번 수동으로 컨텍스트를 재구성해야 하고, 이는 토큰 낭비이자 품질 저하로 이어집니다. ...
1편 요약과 2편의 문제의식: 왜 LLM은 “무난한 답"만 하는가 1편에서는 LLM의 출력을 구조적으로 제어하는 패턴들을 살펴보았습니다. JSON Schema를 활용한 Output Structuring, 유해 출력을 차단하는 Guardrails, Few-shot Prompting을 통한 포맷 유도까지, 이 패턴들의 공통 목표는 “LLM이 어떤 형태로 답하는가"를 통제하는 것이었습니다. 하지만 실무에서 LLM을 도메인 전문가로 활용하려 할 때, 형태보다 더 근본적인 문제에 부딪힙니다. “무엇을 말하는가” 자체가 지나치게 무난하다는 점입니다. 중립화(Neutralization)는 어디서 오는가 현대 LLM은 RLHF(Reinforcement Learning from Human Feedback)와 안전성 정렬(Safety Alignment) 과정을 거칩니다. 이 과정에서 모델은 논쟁적 주장, 단정적 판단, 한쪽으로 치우친 추천을 체계적으로 회피하도록 학습됩니다. 개인적으로 이 현상을 “Neutralization"이라고 부르는데, 모델이 가진 지식의 문제가 아니라 출력 정책의 문제라는 점이 핵심입니다. ...