에이전트에게 코드를 작성하게 하고 검색을 시키는 건 이제 익숙한 이야기입니다. 그런데 에이전트가 자기 자신을 개선하는 메커니즘 자체를 수정한다면? 2026년 3월, Meta FAIR가 HyperAgents 논문(arXiv:2603.19461)을 발표했습니다. 에이전트의 system prompt, tool 구성, 자기개선 전략(meta_rules)까지 에이전트 스스로 진화시키는 프레임워크입니다. 한 가지 흥미로운 관찰이 있습니다. 에이전트에게 자기개선의 여지를 주면, 개발자가 손으로 만들던 것들, 즉 영속 메모리, 성능 추적, 다단계 평가, 도메인 도구를 스스로 만들어냅니다. 이 글에서는 논문의 개념을 정리하고, Amazon Bedrock에서 재현한 실험 결과를 함께 살펴봅니다. ...
Enterprise 환경에서 LLM 기반 시스템을 프로덕션에 배포하려면, 단순히 API를 호출하는 것 이상의 설계가 필요합니다. PoC에서는 잘 동작하던 시스템이 실제 트래픽과 다양한 질의를 만나면 hallucination, 검색 품질 저하, 보안 취약점 같은 문제가 수면 위로 올라옵니다. 이 글에서는 Enterprise LLM 시스템을 설계할 때 반복적으로 등장하는 5가지 핵심 패턴을 정리합니다. 각 패턴은 독립적으로 적용할 수도 있고, 하나의 시스템 안에서 조합할 수도 있습니다. 1. Enterprise RAG: 검색 품질이 답변 품질을 결정합니다 RAG(Retrieval-Augmented Generation)는 LLM이 외부 지식을 참조해서 답변을 생성하는 기법입니다. 원리 자체는 단순하지만, 5만 건 이상의 내부 문서를 다루는 Enterprise 환경에서는 설계 난이도가 급격히 올라갑니다. ...
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에게 현장 사진을 보여주고 “안전모를 착용하지 않은 작업자가 있나요?“라고 물으면 일반적인 안전모는 감지하지만, 해당 건설사의 특정 안전 규정(색상별 직급 구분, 반사띠 부착 여부, 턱끈 체결 상태)까지는 판단하지 못합니다. ...
2026년, AI 에이전트가 도구를 쓰기 시작했다 AI가 질문에 답하는 걸 넘어 실제 업무 도구를 사용하기 시작했습니다. 이메일을 보내고, 문서를 편집하고, 캘린더를 관리합니다. Anthropic의 Claude Cowork는 Gmail, Google Drive, DocuSign 같은 서비스를 플러그인으로 연결해서 반복 작업을 자동화합니다. Spotify는 고객 지원 티켓을 AI 에이전트로 처리하고 있고, Novo Nordisk는 내부 문서 검색과 요약에 활용합니다. AWS가 2026년 3월 발표한 OpenClaw on Lightsail도 비슷한 방향입니다. 터미널 명령을 실행하고, Git 커밋을 만들고, 코드 리뷰를 진행하는 자율 AI 에이전트를 Lightsail 인스턴스 하나로 띄울 수 있습니다. 한 달에 몇 달러면 팀 전용 AI 개발자를 둘 수 있는 셈입니다. ...
1. 왜 Bedrock 비용 추적이 어려운가 Claude 같은 Foundation Model을 프로덕션에서 쓰면 비용이 얼마나 나올지 궁금해집니다. 특히 Prompt Caching을 켜면 캐시 히트율에 따라 비용 구조가 복잡해지는데, AWS Cost Explorer는 이 정도 세분화를 지원하지 않습니다. AWS Cost Explorer의 한계 Cost Explorer는 서비스 레벨만 보여줍니다. “Amazon Bedrock"으로 필터링하면 전체 합계는 나오지만, 어떤 모델에 얼마를 썼는지, 일별 트렌드가 어떤지, 캐시 히트율은 몇 퍼센트인지 알 수 없습니다. Cost Explorer 조회 결과: - Amazon Bedrock: $5,724.02 (지난 7일) ... 그래서 어떤 모델에 얼마 썼나요? Bedrock은 토큰 단위로 과금합니다. Opus 4.6과 Sonnet 4.6의 Input 토큰 가격은 5배 차이($15 vs $3)입니다. 모델별로 얼마나 썼는지 모르면 최적화할 수 없습니다. ...
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. 왜 지금 동물 AI인가 테마파크와 동물원, 야생 보전 현장에서 동물 개체 단위의 행동 모니터링 수요가 빠르게 늘고 있습니다. 동물 복지 규제가 강화되고 멸종위기종 보전 프로젝트가 확대되면서, “지금 이 개체가 어디서 무엇을 하고 있는가"를 실시간으로 파악해야 하는 상황이 일상이 되었습니다. 하지만 사육사와 현장 연구자의 수작업 관찰(Manual Observation)에는 분명한 병목이 있습니다. 야행성 동물의 심야 행동이나 넓은 사파리 구역의 동시 모니터링은 인력만으로 물리적으로 불가능합니다. 같은 행동을 두고도 관찰자마다 기록이 달라지는 관찰자 간 변이(Inter-observer Variability) 문제도 있고, 개체 수가 수십에서 수백으로 늘어나면 개체 식별과 행동 분류를 동시에 수행하는 것 자체가 비현실적입니다. Nature Communications에 게재된 동물 행동 자동 분석 서베이 논문에서도 이러한 수작업 한계를 지적하며 딥러닝 기반 자동화의 필요성을 강조한 바 있습니다. ...
1. 설비 예방정비(Predictive Maintenance)의 핵심 과제 제조·플랜트·테마파크 할 것 없이, 설비가 멈추는 순간 비용은 기하급수적으로 늘어납니다. 예방정비(Predictive Maintenance, PM)는 이 다운타임을 줄이기 위한 핵심 전략이며, 기술적으로는 크게 두 가지 축으로 나뉩니다. PM의 두 축: 이상탐지와 잔여수명 예측 과제 핵심 질문 비즈니스 임팩트 시계열 이상탐지 (Anomaly Detection) “지금 설비가 정상인가?” 돌발 고장 방지, 즉각 대응 잔여수명 예측 (Remaining Useful Life, RUL) “이 부품이 언제 교체 시점에 도달하는가?” 정비 일정 최적화, 부품 재고 관리 이상탐지는 실시간성이 생명이고, RUL 예측은 장기 트렌드를 읽어야 하므로 모델 설계 철학 자체가 다릅니다. 개인적으로 현장에서 느끼는 건, 이상탐지는 비교적 빠르게 도입할 수 있지만 RUL은 충분한 고장 이력 데이터가 확보되지 않으면 정확도를 담보하기 어렵다는 점입니다. ...
비정형 문서 파싱이 어려운 이유 엔터프라이즈 환경에서 RAG(Retrieval-Augmented Generation) 파이프라인을 구축해 보신 분이라면, 가장 먼저 부딪히는 벽이 “원본 문서에서 의미 있는 구조를 살려 텍스트를 뽑아내는 것"이라는 데 공감하실 겁니다. 전통적 접근법이 왜 한계에 부딪히는지, 그리고 구조 보존이 왜 중요한지 정리해 보겠습니다. PDF 내부 구조의 복잡성 PDF는 본질적으로 화면 렌더링을 위한 포맷이지, 시맨틱 구조를 전달하기 위한 포맷이 아닙니다. 스캔된 PDF는 텍스트 레이어 자체가 존재하지 않습니다. 디지털 네이티브 PDF조차 다단(multi-column) 레이아웃이나 표·차트·이미지가 혼재된 페이지에서는 텍스트 추출 순서가 뒤엉키기 일쑤입니다. 실제로 써보면 PyPDF2나 pdfplumber 같은 라이브러리는 단순 문서에서는 잘 동작하지만, 복잡한 레이아웃 앞에서는 금세 무너집니다. ...