LLM

2026년 상반기 AI reasoning 담론에는 한 가지 방향 전환이 있었습니다. o1과 DeepSeek-R1이 연 “긴 사고 사슬(long chain-of-thought)“의 시대에서, 사고 자체를 행동의 도구로 재정의하는 흐름으로의 이동입니다. 이 전환을 비교적 명료하게 정리한 사람이 Alibaba Qwen 프로젝트의 前 테크리드 Junyang Lin입니다. 그는 2026년 3월 3일 Qwen 테크리드에서 사임했고, 현재는 독립연구자로서 “training models에서 training agents로"라는 명제를 이야기하고 있습니다. Lin의 자리 이동 자체가 담론의 방향을 보여주는 신호이기도 합니다. 프론티어 모델 하나를 여러 해 이끌던 사람이 조직을 떠나 에이전트 학습을 이야기한다는 것은, 모델 가중치를 키우는 경쟁의 한 사이클이 일단락됐다는 인식과 무관하지 않습니다. 당시 보도도 이 사임을 큰 AI 드라이브가 지나간 뒤의 매듭으로 읽었습니다. ...

작성 모델이 서명한 diff에서, 다른 모델이 뚫어낸 것 먼저 겪은 일부터 적습니다. 제가 운영하는 자동화 워크플로우에서 코드를 짜는 쪽은 Claude Code(현재 Fable 5 계열)입니다. 이 코딩 에이전트가 코드를 고쳤고, 그 코드를 같은 계열 모델이 스스로 리뷰했습니다. 판정은 “안전함”. 그런데 습관대로 작성자와 다른 패밀리의 모델(GPT-5.5 계열 codex)로 한 번 더 교차 리뷰를 돌렸더니, 자기리뷰가 통과시킨 silent bypass 2건과 잘못된 안전성 주장 1건이 걸렸습니다. 조건 하나를 우회하는 분기와, “상위에서 이미 검증하니 여기선 안전하다"는 근거가 부실한 주석이었습니다. ...

코딩 에이전트가 코드를 쓰는 일은 이제 일상이 됐습니다. 문제는 그다음입니다. 그 코드를 누가 검토하는가. 가장 흔한 답은 “같은 에이전트에게 다시 시킨다"입니다. 방금 코드를 작성한 모델에게 “이거 리뷰해줘"라고 한 번 더 부탁하는 식입니다. 편하지만, 여기에는 구조적인 함정이 있습니다. 자기 리뷰의 맹점 같은 세션의 같은 모델이 자기가 쓴 코드를 검토하면, 작성할 때 놓친 가정을 리뷰할 때도 똑같이 놓칩니다. 모델이 어떤 엣지 케이스를 “이건 일어날 리 없지"라고 판단해서 코드에 반영하지 않았다면, 같은 모델은 리뷰 단계에서도 같은 판단을 반복할 가능성이 높습니다. 작성과 리뷰가 동일한 학습 분포에서 나오기 때문입니다. 같은 분포는 같은 사각지대를 만듭니다. ...

2026년 4월 16일, Anthropic이 Claude Opus 4.7을 공개했습니다. 같은 날 GitHub Copilot, Cursor, Claude Code가 일제히 지원을 시작했습니다. 가격은 Opus 4.6과 동일한 입력 $5 / MTok, 출력 $25 / MTok이고 모델 ID는 claude-opus-4-7입니다. 1M 컨텍스트와 128k max output은 유지됐습니다. 가격이 그대로면 보통은 숫자만 바뀐 업데이트로 흘려보내기 쉽습니다. 그런데 이번 릴리즈는 숫자보다 파라미터의 문법 자체가 바뀐 편입니다. thinking 인터페이스가 바뀌었고, 새 파라미터 두 개가 추가됐고, 비전 해상도가 3.3배가 됐습니다. 프로덕션에서 Opus 4.6을 쓰고 있었다면 코드 몇 군데는 반드시 손봐야 합니다. ...

🎧 이 글을 팟캐스트로 듣기 브라우저가 오디오 재생을 지원하지 않습니다. “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 토큰이 주어진 지금, 과연 모든 작업에 긴 컨텍스트를 사용하는 것이 최선일까요? 많은 개발자들이 “길면 길수록 좋다"는 직관을 따르지만, 실제로는 컨텍스트 길이가 늘어날수록 성능이 떨어지는 현상이 연구를 통해 확인되었습니다. ...