LLM Structured Output에서 “JSON mode + JSON Schema 강제”를 제대로 쓰려면 알아야 할 제약들
· AI / LLM
LLM을 서비스에 붙일 때 JSON은 “있으면 좋은 출력 형식”이 아니라 시스템 경계(contract) 입니다. 한 번이라도 " 하나 빠진 출력, enum 오타, 필드 누락이 발생하면 파이프라인 전체가 연쇄적으로 깨지죠. 그래서 2026년에는 대부분의 팀이 아래 중 하나로 수렴합니다.
Default
arXiv가 말해준 현실: “모델 성능”보다 “평가·검색·커널”이 더 중요해졌다
· News / AI
2026년 5월 arXiv에는 “더 큰 LLM” 자체보다, 실무에서 병목이 되는 평가(evaluation)·retrieval·성능 최적화(GPU kernel)를 정면으로 다룬 논문들이 눈에 띄었습니다.
컨텍스트가 1M 토큰이어도 망한다: 2026년식 LLM Long Context Compaction으로 “Lost in the Middle” 잡는 법
· AI / LLM
LLM long context window가 커질수록 “이제 RAG 없이 문서/대화/에이전트 히스토리를 통째로 넣어도 되겠지?”라는 유혹이 생깁니다. 그런데 2026년 5월 기준 실무 결론은 정반대입니다.
GPU 오토스케일링 2026: Kubernetes에서 LLM 서빙을 “GPU 기준”으로 제대로 스케일하는 법 (HPA/KEDA/DCGM/DRA/MIG 실전 조합)
· Infrastructure / Kubernetes
LLM inference를 Kubernetes에 올리면, 첫 번째로 부딪히는 벽이 “CPU는 놀고 있는데 GPU는 이미 포화인데도 HPA가 안 늘어난다”입니다.
BM25+Vector 하이브리드 검색, 2026년 RAG의 “마지막 20%”를 채우는 랭킹 병합 전략 (RRF vs Weighted)
· AI / RAG
RAG에서 “답이 틀린” 이유의 상당수는 LLM이 아니라 retrieval이 후보 문서를 잘못 뽑았기 때문입니다. 특히 실무 문서(사내 위키/티켓/로그/정책/기술 문서)는 다음 두 종류의 질의가 섞입니다.
Agentic RAG 자율 에이전트 구현, “프로덕션”에 올리는 법 (LangGraph 중심)
· AI / Agent
전통적인 RAG는 “질문 → (고정된) 검색 → 답변”으로 끝납니다. 문제는 현실의 질의가 (1) 검색이 필요 없는 질문과 (2) 한 번의 검색으로는 부족한 질문(멀티홉/용어 불명확/정책-기반 답변)이 섞여 있다는 점입니다.
RAG 성능의 천장을 결정하는 2026년식 Chunking/Document Splitting 전략 (Overlap vs Semantic Chunking 실전 가이드)
· AI / RAG
RAG에서 “검색이 헛돌고 답이 근거 없이 흔들리는” 문제의 상당수는 embedding/LLM이 아니라 문서가 어떻게 쪼개졌는지(chunking) 에서 시작합니다.
EU·미국·주(州)정부까지… 2026년 5월, “AI 규제”가 개발 프로세스를 바꾸기 시작했다
· News / AI
2026년 5월은 “AI 규제”가 선언 수준을 넘어 가이드라인·집행·주(州) 단위 입법으로 구체화된 달이었습니다.
Chain of Thought를 “드러내지 않고” 성능만 끌어올리기: 고급 프롬프트 최적화 실전 패턴
· AI / LLM
Chain of Thought(CoT)는 복잡한 추론/계산/의사결정 문제에서 정답률을 올리기 위해 모델이 중간 추론 단계를 활용하도록 유도하는 프롬프팅 계열입니다.
Vibe Coding으로 2주짜리 MVP를 2일로 줄이는 법: AI 프로토타이핑 “진짜” 빠른 개발 루프
· AI / Coding
2026년의 “Vibe Coding”은 코드를 대신 써주는 마법이 아니라, 프로토타입→피드백→폐기/강화 사이클을 극단적으로 압축하는 개발 방식입니다.