Jev로 AI 글 냄새 잡기 - 판정 모델을 교정 파이프라인 세 곳에 붙인 기록
요즘 AI와 함께 글을 쓰는 일이 부쩍 늘었습니다. 그러다 최근 DEVOCEAN에 올린 개발기(벡터DB를 걷어내고 유사글 추천을 되살린 이야기)가 ＂AI 느낌이 많이 난다＂는 이야기를 들었고, 마침 책 원고 교정 도...
devBlog
MLOps 글 모음
기업 기술블로그의 MLOps 관련 글 158개
[클로바시선 #58] 속도와 비용의 열쇠: 멀티모달 AI 학습을 갉아먹는 ‘이미지 토큰 불균형’ 이야기
소버린 AI를 개발하는 일은 막대한 비용을 감당해야 하는 승부입니다. ⚔️ 2025년 Meta가 공개한 자료에 따르면, Llama 4의 사전학습에는 H100 GPU 누적 738만 시간이 투입되었는데요. 이를 2026년 현재 클라우드 H100 임대 시세(시간당 약 2.5~3달러)로 단순히 환산하면 GPU 비용만 한화로 약 250억~300억 원 규모인 셈입니다. 이렇게 GPU를 수백만 시간 가동하는 데만 수백억 원이 소요되는 시대에, 학습 속도를
Amazon EKS와 NVIDIA FLARE로 구현하는 연합학습 (Federated Learning)
머신러닝의 학습 과정에서 고품질 모델을 훈련시키려면 대규모의 고품질 데이터가 필수적이며, 이를 준비하는 과정은 보통 여러 출처의 데이터를 한곳에 모으는 작업을 동반합니다. 이 방식은 효과적이지만 의료 기관, 금융 기관, 정부 기관과 같이 데이터 프라이버시, 규제 준수, 데이터 주권에 민감한 환경에서는 조직 밖으로 반출할 수 없는 소중한 데이터를 보유하고 있는 경우가 많습니다. 연합 학습(Federated Learning, FL)은 이에 […]
Strands Agents와 Amazon Bedrock AgentCore을 이용한 발전설비진단 구현하기
발전소에는 목적이 다른 시스템과 문서가 함께 존재합니다. 원격 진동 고장진단 시스템(Remote Vibration Monitoring System, RVMS)은 회전설비의 베어링 진동을 상시 감시하고 임계치 초과를 알려 줍니다. 운전 매뉴얼과 로직 도면에는 조치 절차와 설비 관계가 기록되어 있습니다. 하지만 경보가 발생한 뒤 원인 후보를 좁히고, 여러 지표를 비교하고, 필요한 근거를 찾아 조치 순서를 정하는 일은 여전히 전문가의 경험에 의존합니
측정할 수 없으면 개선할 수 없다 - AI Pick 추천 카드를 위한 sLLM 정렬 학습기
안녕하세요! 😆 'ItemLM: 상품 정보 기반의 임베딩 생성기', 'T4 GPU 1장으로 일궈낸 올리브영의 Gemma 3 기반 sLLM…
LLM에게 어디까지 맡길 것인가: AI 에이전트 기반 광고 분석 리포트 자동화
들어가며안녕하세요. LINE Ads에서 데이터 분석 플랫폼을 개발하고 있는 이종우, 이운열입니다.광고 매출은 상품, 광고주, 캠페인 집행 변화에 따라 매일 움직입니다. 광고 KPI...
몇 달 전에 풀었던 문제를 오늘 또 풀고 있었습니다 — AI와의 대화를 팀의 지식으로 자동 축적한 이야기
몇 달 전에 똑같은 문제를 풀었는데 원인이 무엇이었는지 기억나지 않아, 오전을 통째로 써서 처음부터 다시 찾아야 했습니다. AI에게 묻는 비용이 사실상 0에 가까워지면서 하루에도 수십 번씩 묻게 되었지만, 그 답변과 "그래서 어떻게 하기로 했는지"라는 판단은 대화창을 닫는 순간 함께 사라졌기 때문입니다. 이 글은 AI 도구의 실행 생명주기 훅(Hook)에 기록 스크립트를 연결해, 사용자가 별도의 조작을 하지 않아도 매번의 질문과 판단 근거가 개
AI-DLC 기반 GS SHOP 검색·추천 개발 프로세스 고도화 사례
본 블로그는 GS리테일과 AWS가 공동 작성하였습니다. 검색과 추천, 서로 다른 두 과제를 하나의 개발 방법론으로 풀다 온라인 커머스에서 검색과 추천은 고객 경험을 결정하는 핵심 서비스입니다. 고객이 원하는 상품을 빠르게 찾고, 적절한 상품을 제안하기 위해서는 검색 방식과 추천 모델을 지속적으로 개선해야 합니다. 하지만 실제 운영 환경에서는 새로운 기능을 개발하는 것보다 빠르게 검증하고 반복적으로 개선할 수 있는 […]
[AI 트렌드] 오늘의 AI는 당신이 쓸 가장 뒤떨어진 AI입니다
AI는 우리가 체감하는 것보다 더 빠르게 발전하고, 그 충격은 고용 구조와 SaaS 시장까지 흔듭니다. 하지만 기술이 좋아도 도입이 성공하진 않습니다. 지금 필요한 것은 낙관의 반대편에서 경계선을 확인하고, ‘업의 맥락’에 맞게 쓰는 관점입니다. The post [AI 트렌드] 오늘의 AI는 당신이 쓸 가장 뒤떨어진 AI입니다 appeared first on BESPIN Tech Blog.
[AI 트렌드] 배관 전화를 받는 AI가 1조 회사가 됐습니다
산업혁명에서 승자는 ‘엔진’이 아니라 ‘일하는 방식’을 바꾼 기업이었다. AI 시대에도 이미 해외·국내에서 버티컬 워크플로우를 깊게 파고든 팀들이 성과를 내고 있으며, 성과는 대체가 아닌 재배치와 단위경제에 달려 있다. The post [AI 트렌드] 배관 전화를 받는 AI가 1조 회사가 됐습니다 appeared first on BESPIN Tech Blog.
AI Agent를 위한 OpenSearch 검색 품질 개선하기 (Part 2)
Rerank와 Weight 튜닝, 그리고 예상과 다른 결과들 1부에서는 Amazon OpenSearch Service와 Amazon Bedrock으로 검색 품질을 측정하는 시스템을 만들었습니다. 이제 측정할 수 있게 됐으니, 고객들은 자연스럽게 “그래서 어떻게 개선하지?” 를 묻게 됩니다. 이번 글에서는 측정 결과를 바탕으로 검색 품질을 실제로 끌어올리는 방법을 다룹니다. 사실 저는 이 테스트를 시작할 때 “검색 성능은 Rerank를 붙이면 당
Claude Code 토큰 비용 최적화하기 – 2부: 캐시 경제학과 Amazon Bedrock 조직 비용 관리
Claude Code를 조직에 도입하면 개인의 습관만으로는 답할 수 없는 질문이 남습니다. 자리를 비웠다 돌아오면 첫 응답이 왜 유난히 느리고 비싼지, Amazon Bedrock으로 사용하는 조직에서는 누가 얼마나 쓰는지를 어디서 확인할 수 있는지 같은 질문입니다. 이 글은 Claude Code 토큰 비용 최적화 시리즈의 2부입니다. 1부(비용 구조와 세션 습관)에서는 비용이 컨텍스트 크기에 비례하고 실제 지불 단가는 프롬프트 캐싱(prompt
Amazon Bedrock AgentCore로 멀티 데이터소스 자연어 질의 에이전트를 프로덕션에 배포하기
본 글은 AWS Summit Seoul 세션 “200개국 삼성 스마트 TV 앱 데이터를 자연어로 묻다: 에이전틱 AI on AWS”의 내용을 기반으로 작성되었습니다. 개요 생성형 AI는 실험적 프로토타입에서 벗어나, 이제 프로덕션 환경에서 대규모로, 실제 성능 제약 속에서 안정적으로 동작할 것을 요구받고 있습니다. Strands Agents SDK, LangGraph, CrewAI, LlamaIndex 같은 오픈소스 프레임워크의 등장으로 누구나
케클s피드 8월호｜개발부터 운영까지, 일하는 방식을 재설계하다
AI를 실제 업무에 적용하기 시작하면 새로운 질문들이 생깁니다.운영 데이터는 AI가 이해할 수 있는 형태로 어떻게 연결할지, 반복되는 개발 업무는 어디까지 자동화할지, 복잡해진 인프라의 이상 징후는 어떻게 더 빨리 찾아낼지 고민해야 합니다.이번 케클s피드는 이런 질문에 답을 찾아가는 kt cloud의 기술과 경험을 담았습니다. AIDC와 Cloud Platform부터 Observability, 개발환경 자동화, AI 코드 리뷰까지 개발과 운영
자가 발전하는 유저 인터뷰 에이전트 개발기
똑닥 AI 모더레이터는 사람 대신 유저 인터뷰를 진행하는 AI 에이전트입니다. 이 글에서는 AI 모더레이터가 어떤 배경에서 시작되었고, 검수자의 피드백이 다음 인터뷰의 전략을 자동으로 다시 만들어내는 "자가 발전" 구조를 어떻게 설계하였는지 공유합니다.
수요 패턴이 수요 모델을 고른다: Amazon Connect Decisions로 살펴보는 Agentic Demand Forecasting
들어가며 수요 예측 시스템을 도입해 본 기업이라면 익숙한 패턴이 있습니다. 도입 첫해, 컨설턴트와 함께 수개월에 걸쳐 데이터를 정비하고 모델과 파라미터를 최적화합니다. 시스템은 그 시점의 비즈니스를 잘 반영하여 정확하게 예측합니다. 문제는 신규 채널에 진출하고, 프로모션 전략이 바뀌고, 신제품이 출시되고, 주력 상품의 라이프사이클이 끝날 때에 발생합니다. 비즈니스는 계속 변화하는데, 시스템은 구축 시점의 스냅샷에 멈춰 있습니다. 시스템의 예측을
Claude Code로 만든 데이터 분석 에이전트, Amazon Bedrock AgentCore로 프로덕션 배포하기
많은 팀이 Claude Code로 자체 에이전트를 만들어 사용하고 있습니다. 예를 들어 데이터 분석 팀에서는 Skill로 리포트 형식을 표준화하고, MCP(Model Context Protocol) 서버로 사내 데이터베이스를 연결하고, 웹 검색으로 시장 동향까지 반영해 매출 리포트 작성을 자동화합니다. 이렇게 만든 에이전트는 개인 도구를 넘어 팀 전체가 활용할 수 있는 자산이 됩니다. 그러나 로컬에서 검증한 에이전트를 조직의 서비스로 확장하는
같은 LLM인데 왜 결과가 다를까? 답은 하네스에 있다.
이 글은 같은 모델을 써도 에이전트 성능이 갈리는 이유가 모델이 아닌 하네스(모델을 둘러싼 환경 전체)에 있다는 관점에서, 프롬프트·컨텍스트·하네스 엔지니어링의 층위 차이를 구분하고 하네스를 구성하는 핵심 요소들을 다룹니다. 지시 문서(AGENTS.md)와 자동 검사 장치의 결합, 에이전트 바깥의 결정론적 검증, 컴팩션·하위 에이전트·진행파일을 통한 컨텍스트 관리 기법을 설명하며, 작게 시작해 실수할 때마다 한 겹씩 보강해 나가는 5단계 실천
페이지 1 / 9 (총 158개)