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 같은 라이브러리는 단순 문서에서는 잘 동작하지만, 복잡한 레이아웃 앞에서는 금세 무너집니다. ...
왜 하이브리드 추천인가 — 단일 추천 엔진의 한계 개인화 추천 시스템을 설계할 때 가장 먼저 부딪히는 질문은 “어떤 엔진 하나로 충분하지 않을까?“입니다. 결론부터 말씀드리면, 단일 엔진만으로는 실서비스 수준의 추천 품질을 달성하기 어렵습니다. 각 접근법의 한계를 짚어 보겠습니다. 협업 필터링(Collaborative Filtering) — Amazon Personalize Amazon Personalize는 사용자-아이템 상호작용 데이터를 기반으로 개인화 추천을 제공합니다. 그러나 신규 사용자나 신규 아이템처럼 상호작용 이력이 부족한 콜드스타트(Cold Start) 상황에서는 추천 품질이 눈에 띄게 떨어집니다. “왜 이 아이템을 추천했는지"에 대한 콘텐츠 맥락(Content Context)도 부족해서, 사용자가 지금 검색하거나 관심을 보이는 주제와 동떨어진 결과가 나올 수 있습니다. ...