Claude Code × Codex CLI 에이전트로 “터미널에서 끝내는” 자동화 워크플로
· AI / Coding
2026년 5월 시점의 CLI 기반 AI 코딩 에이전트는 더 이상 “코드 몇 줄 생성”이 아니라, 리포지토리 안에서 계획→실행→검증(테스트/린트/빌드)→PR용 산출물 생성까지 묶어서 처리하는 자동화 장치에 가깝습니다.
Default
LLM 시대의 OCR Document AI: “레이아웃 + 스키마 + 검증”으로 표·PDF를 구조화 추출하는 법
· AI / Multimodal
문서 OCR/이해 파이프라인에서 진짜 어려운 문제는 “텍스트를 읽는 것”이 아니라, 표/레이아웃을 깨뜨리지 않고 업무 스키마(JSON) 로 일관되게 뽑아내는 겁니다.
LLM Structured Output에서 “JSON mode + JSON Schema 강제”를 제대로 쓰려면 알아야 할 제약들
· AI / LLM
LLM을 서비스에 붙일 때 JSON은 “있으면 좋은 출력 형식”이 아니라 시스템 경계(contract) 입니다. 한 번이라도 " 하나 빠진 출력, enum 오타, 필드 누락이 발생하면 파이프라인 전체가 연쇄적으로 깨지죠. 그래서 2026년에는 대부분의 팀이 아래 중 하나로 수렴합니다.
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 규제”가 선언 수준을 넘어 가이드라인·집행·주(州) 단위 입법으로 구체화된 달이었습니다.