에이전트 뉴스

ARTICLE

LLM은 아직 숙련된 HW 엔지니어처럼 PCB를 설계하지 못합니다. Fable 5까지 사용해봤지만, 결론은 크게 달라지지 않았습니다. 개인 프로젝트로 PCB부터 기구, 펌웨어, 모바일 앱, 백엔드(+LLM)까지 직접 만들어보고 있습니다. 그 과정에서 21mm 원형 4층 PCB(nRF54L15 + ICM-42688-P)의 배선도 LLM 에이전트에게 맡겨봤습니다. 처음에는 나름 그럴듯한 결과가 나왔다고 생각했지만, HW 엔지니어 동료에게 리뷰를 받자 바로 여러 문제를 지적받았습니다. 결국 외부 HW 엔지니어에게 설계를 의뢰했습니다. LLM이 만든 PCB를 시작점으로 전달했고, 두 차례의 피드백과 수정 작업을 거쳐 최종 설계를 완성했습니다. 여기서 끝내지 않고, LLM이 만든 기판과 숙련된 엔지니어가 수정한 기판을 Net 단위로 비교해봤습니다. 어떤 배선을 어떻게 바꿨는지, 왜 그렇게 변경했는지 정리하고, 외주 엔지니어의 피드백까지 합쳐 PCB Routing Rule/Skill 형태로 만들었습니다. 그리고 그 Skill을 다시 LLM에 적용해 동일한 PCB 설계를 재시도했습니다. 결과는 이전보다 분명 나아졌지만, 여전히 숙련된 HW 엔지니어의 결과물에는 미치지 못했습니다. 대신 이번 과정에서 얻은 것은 단순히 “PCB 한 장을 완성했다”는 것보다, LLM이 PCB 설계에서 구체적으로 어디까지 할 수 있고 어디서부터 실패하는지에 대한 목록이었습니다. 외주 엔지니어와 두 라운드를 돌며 산 것은 어쩌면 배선 작업 자체가 아니라, 그 실패 패턴과 판단 기준이었고, 이 목록은 이번 기판보다 더 오래 활용할 수 있을 것 같습니다. LLM이 만든 PCB → 숙련자의 수정 → Net 단위 비교 → Rule/Skill 추출 → LLM 재시도 과정을 정리해봤습니다. 자세한 내용은 아래 글에 적었습니다. https://edgelog.dev/ko/blog/llm-pcb-routing-human-taught/ 감사합니다.

에이전트LLMSK

2026.08.11

새 소식

좌석 기반 요금제 버리고 사용량 기반 메터링 구축한 이유

월말 결산 회의실의 공기는 차갑게 식어 있었습니다. 재무 이사가 모니터 화면을 가리키며 던진 한마디가 아직도 귓가에 맴붑니다. "신규 B2B 고객사 5곳을 유치해서 월 매출(ARR)이 15퍼센트 늘었는데, 왜 LLM(대형 언어 모델) API 호출 비용은 400퍼센트가 폭증한 겁니까?" 순간 식은땀이 흘렀습니다. 우리가 제공하던 서비스는 여타 전통적인 SaaS(클라우드 기반 소프트웨어 서비스)처럼 '1인당 월 3만 원'이라는 전형적인 좌석 기반(Seat-based) 요금제를 채택하고 있었습니다. 하지만 일부 파워 유저들이 하루에도 수만 건의 복잡한 추론 프롬프트(Prompt - AI에게 전달하는 명령어)를 날리기 시작하면서, 해당 유저 한 명이 발생시키는 토큰 비용이 한 달 구독료의 몇 배를 뛰어넘었던 것입니다. 손님이 많이 올수록 손해가 커지는 기괴한 구조였습니다. AI 기능을 많이 쓰면 쓸수록 제품의 가치는 올라가는데, 역설적이게도 회사의 수익성은 밑바닥으로 추락하고 있었습니다. 기존 백엔드 인프라는 단순 요청 횟수만 기록할 뿐, 유저가 소모한 입력·출력 토큰의 양이나 가중치를 전혀 추적하지 못하고 있었습니다. 이 문제를 해결하지 않고서는 서비스의 생존 자체가 불가능했습니다. 우리는 기존의 고정 좌석 요금제 단말을 완전히 철거하고, 유저의 모든 AI 행위를 실시간으로 측정하여 가치와 비용을 연동하는 사용량 기반(Usage-based) 메터링 아키텍처로 완전한 체질 개선을 감행해야 했습니다. 오늘 글을 한 줄로 요약하면 이겁니다. AI 제품에서 전통적인 좌석 기반 요금제를 고집하면 사용자 가치가 증가할수록 회사의 마진이 파괴되는 역설에 직면하므로 사용량 기반 아키텍처로 조속히 전환해야 합니다. 1. 무한 리필 뷔페에서 전력계량기 기반 전기 요금제로의 전환 전통적인 SaaS 인프라를 '무한 리필 뷔페'에 비유할 수 있습니다. 손님이 음식을 한 접시 먹든 열 접시 먹든, 매장이 부담하는 한계 비용(Marginal Cost - 손님 한 명을 더 받을 때 드는 추가 비용)은 극히 미미합니다. 서버 인프라를 일단 구축해 두면 추가 유저가 들어와도 CPU와 메모리 사용량의 증가폭이 완만하기 때문입니다. 그래서 전통 SaaS 기업들은 매출 대비 총마진율(Gross Margin - 매출에서 원가를 뺀 비율)을 80~90% 수준으로 유지할 수 있었습니다. 반면 AI 우선(AI-first) 기업의 사정은 완전히 다릅니다. AI 서비스는 무한 리필 뷔페가 아니라 '주문할 때마다 고급 한우가 제공되는 고급 레스토랑'과 같습니다. 유저가 AI에게 질문을 던질 때마다 백엔드에서는 LLM 공급업체(OpenAI, Anthropic 등)나 자체 GPU(그래픽 처리 장치) 서버로 원가가 즉시 발생하는 토큰(Token - AI가 글자를 인식하고 생성하는 최소 단위)을 전송합니다. 실제로 최근 업계 데이터에 따르면 AI 우선 기업들의 평균 총마진율은 50~60% 수준에 불과합니다. 전통 SaaS의 80~90%에 비하면 턱없이 낮은 수치입니다. 유저가 행동할 때마다 원가가 직접적으로 비례해서 늘어나는 구조이기 때문입니다. 입력 토큰 문맥이 길어질수록, AI가 답변하는 출력 길이가 길어질수록 비용은 직전 요청 대비 제곱으로 늘어나기도 합니다. 결국 AI 백엔드 아키텍처는 유저의 모든 행동을 전력계량기처럼 정밀하게 측정하는 '토큰 메터링 엔진'을 내장해야만 합니다. 유저가 창의적인 작업을 수행해 높은 비즈니스 가치를 얻었다면, 그에 비례하는 크레딧을 차감하거나 실시간 사용량으로 청구하는 아키텍처가 필수적입니다. 이를 위해 가장 먼저 구축해야 하는 것은 API Gateway(API 가이트웨이 - 모든 클라이언트 요청의 관문) 단에서 작동하는 실시간 토큰 추적 및 차감 시스템입니다. 아래는 Envoy 또는 커스텀 게이트웨이에서 라우팅 시 LLM 요청 및 응답의 토큰을 비동기로 측정하는 백엔드 메터링 이벤트의 기본 데이터 구조예시입니다. { "event_id": "evt_98742a12-882f", "timestamp": "2026-08-11T09:30:00Z", "organization_id": "org_enterprise_01", "user_id": "usr_tech_lead", "model_name": "claude-3-5-sonnet", "metric": { "prompt_tokens": 1420, "completion_tokens": 350, "total_tokens": 1770, "raw_cost_usd": 0.00951 }, "business_context": { "feature_name": "auto_code_review", "credit_cost": 12 } } 메트릭 분리(Prompt vs Completion) : LLM 공급업체마다 입력(Prompt)과 출력(Completion) 토큰의 단가가 다르므로 이를 엄격히 분리해서 파싱합니다. 비동기 이벤팅 : 메터링 로직이 메인 추론 API의 응답 지연 시간(Latency)에 영향을 주지 않도록 이벤트 버스로 즉시 이탈시킵니다. 가치 기반 크레딧 마핑 : 단순 Raw 비용 외에 서비스가 제공한 비즈니스 기능(Code Review, Summary 등)의 가치에 따라 내부 크레딧 차감 수치를 동적으로 계산합니다. 2. 무제한 요금제 선언 후 마주치는 3가지 아키텍처 비극 많은 팀들이 초기 출시 속도를 높이기 위해 "일단 월 $20에 무제한 AI 제공!"이라는 슬로건을 내걸고 시장에 진입합니다. 하지만 서비스가 성장하면서 백엔드 엔지니어링 관점에서 3가지 결정적인 결함과 직면하게 됩니다. 첫 번째는 '헤비 유저의 체리피킹(Cherry-picking)으로 인한 마진 파고' 현상입니다. 전체 유저의 5%에 불과한 자동화 스크립트 이용자나 기업 헤비 유저들이 전체 LLM API 비용의 70% 이상을 소모하는 기현상이 발생합니다. 고정 가격을 내는 일부 유저가 회사의 전체 수익을 갈아먹는데, 백엔드에 메터링이 없으면 어떤 유저가 시스템을 오용하고 있는지조차 실시간으로 찾아내지 못합니다. 두 번째는 '동기식 트랜잭션 DB의 병목 및 동사' 패턴입니다. AI 요청이 들어올 때마다 유저의 잔여 토큰이나 월간 사용량을 일반 RDBMS(관계형 데이터베이스)의 ACID(트랜잭션 안전성) 테이블에 직접 UPDATE 쿼리로 때리는 경우입니다. 트랜잭션 Lock 병목 : 동일 유저나 팀이 동시에 여러 AI 에이전트를 돌릴 경우, DB Row Lock(행 잠금)이 걸리면서 AI 추론 응답보다 잔여 크레딧 차감 DB 대기 시간이 더 길어지는 기형적인 현상이 벌어집니다. DB Connection枯渴 : 동시 요청이 폭증할 때 메터링 쓰기 작업이 DB 커넥션 풀을 가득 채워, 정작 중요한 유저 로그인이나 메인 서비스 DB 조회까지 함께 마비됩니다. 세 번째는 '정산 투명성 부재로 인한 CS(고객 지원) 대란'입니다. 월말에 사용량 기반 요금을 청구하거나 정해진 크레딧이 차감되었을 때, 유저들은 "내가 도대체 왜 이 만큼의 비용을 써야 하느냐"고 반발합니다. 각 요청별로 어떤 프롬프트가 나갔고, 몇 토큰이 소모되었으며, 어떤 모델이 사용되었는지에 대한 '추적성(Traceability)' 로그가 백엔드에 쌓여있지 않으면 정산 분쟁을 해결할 방법이 없습니다. 실제로 한 B2B AI 에디터 서비스는 메터링 시스템 없이 무제한 구독제를 운용하다가, 한 유저가 로컬 개발 환경에서 루프문으로 AI 코딩 대화 API를 연속 호출하는 바람에 단 하룻밤 사이에 1,200만 원의 API 비용이 청구되어 서비스를 일시 중단하는 참사를 겪기도 했습니다. 3. 마진 60퍼센트 장벽을 넘어서는 사용량 기반 시스템 3단계 개편안 그렇다면 마진율 붕괴를 막고, 유저에게는 합리적인 가치를 제공하면서 안정적인 수익을 확보하려면 백엔드 아키텍처를 어떻게 개편해야 할까요? 현장에서 즉시 적용 가능한 3단계 핵심 아키텍처 가이드라인을 제시합니다. Step 1: 비동기 이벤트 스트리밍 기반의 Zero-Latency 메터링 파이프라인 메인 API 서버가 LLM 공급업체로부터 스트리밍 응답(Server-Sent Events)을 받는 즉시, 토큰 카운트를 포함한 메터링 이벤트를 발행합니다. 이때 메인 DB에 직접 쓰지 않고 Kafka(카프카)나 NATS 같은 고성능 메세지 브로커로 이벤트를 던집니다. 인메모리 버퍼링 : Redis(레디스)의 Atomic Increment( INCRBYFLOAT ) 명령을 사용해 유저의 실시간 사용량을 메모리상에서 즉시 갱신합니다. 시계열 시퀀스 저장 : 비동기 워커(Worker)가 메세지 큐에서 이벤트를 가져와 ClickHouse(클릭하우스)나 TimescaleDB 같은 시계열 분석 전용 DB에 일괄(Batch) 저장합니다. 이로써 메인 서비스 지연 시간은 0ms에 가깝게 유지됩니다. Step 2: 동적 시맨틱 캐싱 및 모델 라우팅 레이어 구축 모든 질문을 최고 성능의 비싼 모델(예: GPT-4o, Claude Sonnet)로 보낼 필요는 없습니다. 사용량 기반 요금제로 전환하더라도 유저의 원가를 절감해 주는 장치를 백엔드에 배치해야 서비스 경쟁력이 생깁니다. 시맨틱 캐싱(Semantic Caching) : Qdrant나 Milvus 같은 Vector DB(벡터 데이터베이스)를 활용해 기존 답변과 유사도가 95% 이상인 요청은 LLM을 다시 호출하지 않고 캐시된 답변을 반환합니다. 원가는 0원에 수렴하게 됩니다. 지능형 모델 라우팅 : 요청의 난이도를 분류하는 가벼운 SLM(소형 언어 모델)을 프론트에 배치합니다. 단순 번역이나 키워드 추출은 단가가 1/20 수준인 저렴한 모델로 라우트하고, 고난도 로직 설계만 고성능 모델로 라우팅합니다. Step 3: 하이브리드 크레딧 메커니즘과 서킷 브레이커 적용 원천 토큰 단가를 유저에게 직접 노출하면 사용자 경험이 극도로 복잡해집니다. "1,000 입력 토큰당 $0.003"이라는 문구는 일반 사용자에게 공포감을 줍니다. 따라서 유저에게는 단순한 '크레딧(Credit)' 개념을 제공하고, 백엔드 내부에서 토큰 비용을 크레딧으로 환산하는 하이브리드 엔진을 구축해야 합니다. 실시간 서킷 브레이커(Circuit Breaker) : 유저가 설정한 일일 한도(Daily Soft Cap)나 월간 예산을 초과하면, API Gateway 수준에서 요청을 즉시 차단하거나 하위 단가 모델로 자동으로 Fallback(대체 작동)시킵니다. 성과 기반(Outcome-based) 과금 마핑 : 단순 토큰 수가 아니라 "생성된 리포트 1건당 10 크레딧", "코드 리팩토링 1건당 5 크레딧"처럼 비즈니스 성과와 크레딧을 매핑하여 유저가 비용 납부를 납득할 수 있게 만듭니다. 4. 지속 가능한 AI 제품을 만든 3가지 아키텍처 원칙 AI 시대로 접어들면서 소프트웨어의 단위 경제학(Unit Economics - 유저 1명당 발생하는 수익과 비용 관계)은 과거와 완전히 다른 규칙으로 움직입니다. 더 이상 서버를 띄워두고 유저가 오기만을 기다리던 유토피아는 존재하지 않습니다. 오늘부터 여러분의 인프라팀, 그리고 제품팀과 함께 당장 실행에 옮겨야 할 3가지 원칙은 다음과 같습니다. 첫째, 모든 AI 호출의 토큰 로그를 단 1건도 빠짐없이 비동기 추적 하세요. 추적할 수 없는 비용은 제어할 수 없습니다. 둘째, 좌석당 고정 요금제에서 탈피하여, 사용량과 성과가 비례하는 하이브리드 크레딧 요금제로 아키텍처를 전환 하세요. 유저가 가치를 느낄 때 회사의 매출과 마진도 함께 올라가는 선순환 구조를 만들어야 합니다. 셋째, 시맨틱 캐시와 모델 라우팅을 인프라 레이어에 내장하여 자체적인 원가 절감 태세를 확립 하세요. LLM 공급업체의 가격 인하만을 기다리는 것은 능동적인 엔지니어링이 아닙니다. 아래는 사용량 기반 AI 백엔드로 전환하기 전, 여러분의 아키텍처가 준비되었는지 즉시 검증할 수 있는 점검 체크리스트와 토큰 메터링 미들웨어 설정 가이드입니다. 복사해서 팀 내 인프라 검토에 곧바로 활용해 보세요. =================================================================== [AI 사용량 메터링 및 단위 경제성 점검 체크리스트 & Config] =================================================================== [1. 백엔드 아키텍처 점검 체크리스트] [ ] 모든 AI API 요청에서 Input/Output 토큰 수가 파싱되고 있는가? [ ] 메터링 로직이 메인 추론 트랜잭션과 분리된 비동기 이벤트인가? [ ] 특정 유저의 한도 초과 시 10ms 이내에 차단할 인메모리 Cache가 있는가? [ ] 동일 프롬프트 재요청 시 비용을 절감할 시맨틱 캐시가 구축되었는가? [ ] 유저별/조직별 일간 및 월간 토큰 소모량을 시각화하는 대시보드가 있는가? [2. Envoy/FastAPI 메터링 미들웨어 설정 예시 (Python/FastAPI Concept)] from fastapi import FastAPI, Request, Response import redis.asyncio as redis import json import time app = FastAPI() redis_client = redis.Redis(host='localhost', port=6379, db=0) @app.middleware("http") async def ai_token_metering_middleware(request: Request, call_next): if not request.url.path.startswith("/v1/ai/generate"): return await call_next(request) user_id = request.headers.get("X-User-ID", "anonymous") # 1. 예산 초과 여부 즉시 검증 (Redis 읽기) current_usage = await redis_client.get(f"usage:{user_id}:daily_cost") if current_usage and float(current_usage) > 50.0: # $50 일간 한도 return Response( content=json.dumps({"error": "Daily AI cost limit exceeded."}), status_code=429, media_type="application/json" ) start_time = time.time() response = await call_next(request) # 2. 비동기 메터링 이벤트 발행 (응답 헤더 기반 토큰 추출) prompt_tokens = int(response.headers.get("X-Prompt-Tokens", 0)) completion_tokens = int(response.headers.get("X-Completion-Tokens", 0)) # 가상 단가 계산 ($0.0015 / 1k prompt, $0.002 / 1k completion) estimated_cost = (prompt_tokens * 0.0000015) + (completion_tokens * 0.000002) # Redis 사용량 아토믹 업데이트 await redis_client.incrbyfloat(f"usage:{user_id}:daily_cost", estimated_cost) # Kafka/Message Queue로 분석 이벤트 발행 (파이프라인 비동기 전송) metering_event = { "user_id": user_id, "prompt_tokens": prompt_tokens, "completion_tokens": completion_tokens, "cost": estimated_cost, "latency_ms": int((time.time() - start_time) * 1000) } await redis_client.lpush("stream:metering_events", json.dumps(metering_event)) return response =================================================================== 단순히 멋진 AI 기능을 붙이는 것만으로는 비즈니스가 지속될 수 없습니다. 원가 파악과 정밀한 메터링 메커니즘이야말로 AI 피처를 진짜 수익성 있는 '소프트웨어 제품'으로 완성하는 백엔드 엔지니어의 핵심 무기입니다. 지금 여러분 서비스의 메터링 계량기가 제대로 돌아가고 있는지 모니터링 화면을 다시 한번 점검해 보시길 권합니다.

AnthropicAI 에이전트서킷 브레이커체질 개선에이전트

2026.08.11

새 소식

기술 블로그 69편을 AI 에이전트가 검색하도록 읽기 전용 MCP 서버로 공개한 과정

기술 블로그에는 현재 78편의 공개 글이 있고, 이 중 URL·메타데이터·배포 아티팩트 검증을 통과한 69편을 읽기 전용 MCP 서버 v0.1.1로 패키징했습니다. 임베딩 없이 결정적 키워드 검색으로 시작 목록·검색·본문 응답에 정식 원문 URL을 구조적으로 포함 미게시 글과 비정상 URL은 fail-closed로 제외 인덱스와 본문을 self-contained wheel로 묶어 PyPI에 배포 uvx aiarchitect-blog-mcp 한 줄로 stdio 실행 서버 코드와 번들 콘텐츠의 라이선스를 분리 구현과 배포 과정뿐 아니라 출처 링크를 강제할 수 없다는 한계, 실제 유입은 별도로 측정해야 한다는 점까지 정리했습니다. 직접 만든 프로젝트와 작성한 글입니다.

AI 에이전트에이전트AI구조메타

2026.08.11

새 소식

Solar Pro 4 - 에이전트 작업 특화 LLM

Upstage가 공개한 에이전트향 LLM으로, 문서 읽기·도구 호출·코드 실행을 거쳐 Excel 분석 자료, Word 보고서, PPT 슬라이드 같은 실제 파일을 만들어내는 업무 흐름에 맞춰 설계 Artificial Analysis 측정 기준 Terminal-Bench v2.1 57점, GDPval-AA v2 39점, τ³-Banking 23점, AA-LCR 71점 Hy3, MiMo-V2.5, GLM-5.1, Qwen 3.6 Mini 등 에이전트 용도로 널리 쓰이는 모델들과 비교하면 실무 산출물 평가(GDPval-AA)에서 가장 높고, 멀티턴 도구 사용(τ³-Banking)은 Hy3와 공동 최고 수준 가격은 1M 토큰당 입력 $0.30, 캐시 입력 $0.06, 출력 $1.20으로, 문서 읽기·도구 호출·재시도로 호출이 쌓이는 에이전트 워크로드의 상시 운영을 겨냥한 구성 512K 컨텍스트와 최대 128K 출력 토큰을 지원하며, 영어·한국어·일본어를 입출력 모두 처리함 기본으로 추론(reasoning)을 수행하고 응답에 reasoning trace가 포함됨. reasoning effort 파라미터로 추론 깊이와 응답 속도를 조절 가능 OpenAI 호환 API로 base_url과 모델명(solar-pro4)만 바꾸면 기존 코드에서 동작함 현재 Hermes Agent에서 8월 18일까지 무료로 쓸 수 있고, Upstage Console과 OpenRouter에서는 9월 10일까지 90% 할인 중

에이전트CIAAPILLMAI

2026.08.11

사회

메시 아버지 별세…아들 '축구의 신' 만든 평생의 조력자

투병 끝에 향년 68세로 별세 리오넬 메시. 2026.07.19 ⓒ 로이터=뉴스1 (런던=뉴스1) 이지예 객원기자 = '축구의 신'으로 불리는 아르헨티나 축구선수 리오넬 메시(39)의 평생의 조력자인 아버지 호르헤 메시가 별세했다. 향년 68세. 8일(현지시간) AFP·로이터통신에 따르면 메시의 가족은 호르헤가 오랜 투병 끝에 간밤 아르헨티나 로사리오의 한 병원에서 사망했다고 밝혔다. 호르헤는 메시가 아르헨티나 시절부터 스페인 바르셀로나 유소년팀을 거쳐 세계 최정상의 축구 선수가 되기까지 아들의 여정을 함께 한 최대 조력자이자 에이전트(대리인)였다. 메시는 2022년 한 인터뷰에서 "힘든 시기 아버지가 계속 축구를 하고 싶은지 집에 돌아가고 싶은지 물었다. 난 계속하고 싶었고 아버지도 내 곁에 남아주셨다"고 회고했다. 아르헨티나 축구협회, 스페인축구협회(RFEF) 및 메시가 몸담은 구단들은 잇따라 애도 성명을 발표했다. 아르헨티나 뉴웰스 올드 보이스는 "호르헤의 변함없는 동행과 보이지 않는 리더십이 메시의 모든 발걸음을 뒷받침했다"고 애도했다. 메시는 2026 북중미 월드컵 기간 아버지의 건강 악화로 마음고생하면서도 아르헨티나의 준우승을 이끌며 맹활약했다. 그는 월드컵 이후 지난주 소속팀인 미국 인터 마이애미에 복귀하기 전 아버지와 시간을 보낸 것으로 알려졌다.

아르헨티나바르셀로나에이전트월드컵스페인

2026.08.09

세계

‘축구의 신’ 아르헨티나 축구 선수 메시의 부친 지병 별세

화학 기술자·제철소 노동자 출신, 유소년 축구선수로 활동 메시의 초상권 사용·부동산·호텔·레스토랑 등 투자 관리 [이스트 러더퍼드=AP/뉴시스] 스페인 라민 야말(왼쪽)이 지난달 19일 미 뉴저지주 이스트 러더퍼드의 뉴저지 스타디움에서 열린 2026 북중미 월드컵 결승에서 아르헨티나를 꺾은 후 리오넬 메시와 포옹하고 있다. 스페인이 연장 끝에 1-0으로 승리하고 16년 만에 통산 두 번째 월드컵 우승을 차지했다. 2026.08.09. [서울=뉴시스] 구자룡 기자 = ‘축구의 신’으로 불리는 아르헨티나의 축구 선수 리오넬 메시의 부친 호르헤 메시가 8일 아르헨티나 중부 도시 로사리오의 한 병원에서 별세했다. 향년 68세. 로사리오를 연고로 하는 클럽 아틀레티코 뉴웰스 올드 보이스는 소셜미디어 게시물을 통해 그가 최근 몇 달 동안 알려지지 않은 질병으로 치료를 받아왔다며 사망 소식을 알렸다. 게시물은 그를 “비전과 엄격함, 애정으로 역대 최고의 선수 경력을 뒷받침한 기둥이자 인물”이라고 묘사했습니다. 남미축구연맹(CONMEBOL)도 애도 성명을 통해 “메시에 대한 존경과 애정을 담아 애도를 표한다”고 밝혔다고 AP 통신은 전했다. FC 바르셀로나는 “호르헤 메시가 우리 클럽에 보여준 헌신, 그리고 그의 아들 레오의 축구 인생 시작과 가장 영광스러운 시절을 우리에게 맡겨준 것에 감사드린다. 고인의 명복을 빈다”고 밝혔다. 레알 마드리드 구단은 성명을 통해 “레알 마드리드와 그의 가족, 그리고 그를 사랑했던 모든 분들께 깊은 애도를 표한다. 고인의 명복을 빈다”고 밝혔다. 메시 가족은 올여름 월드컵 기간 동안 호르헤의 건강 상태가 알려지기 전까지는 그의 병세를 비밀에 부쳐왔다고 ESPN은 전했다. 리오넬 메시는 6월 알제리와의 월드컵 개막전에서 득점을 기록한 후 경기 중과 경기 후 자신의 감정은 “축구와는 아무런 관련이 없었다”고 부친의 병세로 마음 고생한 것을 드러내기도 했다. 1주일 후 가족들은 “메시 가족은 호르헤 메시가 현재 건강상의 문제로 어려움을 겪고 있음을 알린다”고 밝혔다. 호르헤는 아내 셀리아와 네 자녀, 즉 아들 리오넬과 그의 두 형 로드리고와 마티아스, 그리고 리오넬의 여동생 마리아 솔을 남기고 세상을 떠났다. 호르헤 메시는 화학 기술자이자 제철소 노동자였다. 그는 미드필더로 축구를 했고 뉴웰스 올드 보이스 유소년팀까지 진출했지만 의무 군복무를 하기 위해 축구를 그만둬야 했다. 그는 셋째 아들인 리오넬 메시의 경력에 있어 핵심적인 역할을 했는데 에이전트로서 그의 사업을 관리했다고 AP 통신은 전했다. 2000년대 초 어린 메시가 바르셀로나 유소년 아카데미인 라 마시아에 입단하기 위한 테스트를 받을 당시 그를 동행한 사람도 바로 부친이었다. 리오넬 메시는 2005년 프로 데뷔를 했고 이후 발롱도르를 8번이나 수상했으며 아르헨티나 주장으로 2022년 월드컵에서 우승을 차지했다. 리오넬 메시는 2007년 라디오 델 플라타와의 인터뷰에서 “아버지는 항상 제 곁에 계셨다. 바르셀로나에 도착했을 때 가끔 방에 틀어박혀 울곤 했는데, 아버지도 제가 보지 못하는 사이에, 혹은 제가 못 봤다고 생각하는 사이에 똑같이 하셨다”고 에피소드를 소개했다. 메시의 부친은 바르셀로나와의 계약은 물론 이후 파리 생제르맹과 인터 마이애미로의 이적 계약을 협상했을 뿐만 아니라, 아들의 초상권 사용과 부동산, 호텔, 레스토랑에 대한 수많은 투자도 관리했다. 2016년 아버지와 아들은 스페인 법원에서 탈세 혐의로 유죄 판결을 받았지만 형량이 2년 미만이었기 때문에 징역형을 면하기도 했다고 AP 통신은 전했다. 리오넬 메시가 이끄는 아르헨티나는 올해 북중미 월드컵에서 준우승을 차지했다．

소셜미디어아르헨티나바르셀로나에이전트부동산

2026.08.09

사회

‘축구의 신’ 메시 키워낸 조력자 부친 별세…20여년 간 스타 뒷받침

‘축구의 신 ’ 메시를 20여년 간 뒷받침한 조용한 조력자인 부친 호르헤 메시(오른쪽). [EPA=연합뉴스] ‘축구의 신’으로 불리는 리오넬 메시(39)의 선수 생활과 사업을 20여년 간 조용하게 뒷받침해온 부친 호르헤 메시가 68세를 일기로 세상을 떠났다. 8일(현지시간) 현지 일간 클라린, 인포바에, 올레 등의 보도에 따르면 지병으로 투병해온 호르헤는 이날 새벽 2시쯤 아르헨티나 로사리오의 한 병원에서 별세했다. 메시가 세계 최고의 선수로서 재능을 발휘할 수 있었던 배경을 얘기하자면 ‘에이전트’이자 ‘아버지’로서의 호르헤를 빼놓을 수 없다. 전문 경영인도, 스포츠 비즈니스 전문가도 아니었지만 아들의 재능에 대한 강한 확신과 뛰어난 직관, 자신을 외부에 드러내지 않는 신중함이 중요한 역할을 해냈다. 메시가 13세였던 2000년. 당시 그에게는 성장호르몬 치료가 필요했지만, 아르헨티나에서 치료비를 계속 감당하기 어려웠다. 이에 아버지 호르헤는 아들의 유럽 진출을 추진했고, FC바르셀로나와의 협상을 통해 메시의 치료와 주거 등에다 가족의 생활 지원하는 계약을 이끌어냈다. 가족 일부가 로사리오로 돌아간 뒤에도 호르헤는 바르셀로나에 남아 어린 메시가 낯선 스페인 생활에 힘들어할 때 아들의 곁을 지켰다. 메시는 훗날 “아버지는 항상 나와 함께 계셨다. 우리는 참 힘든 일을 많이 겪었다”고 당시를 추억했다. 호르헤는 전문 경영인은 아니었지만 바르셀로나에서 계약을 둘러싼 중개인들의 역할에 의문을 품은 뒤 직접 협상에 뛰어들었다. 이후 메시의 계약과 이적, 광고 및 사업 활동을 관리했다. 호르헤는 조용하고 신중하게 자신의 역할을 해냈으며, 메시가 세계 최고의 선수가 된 뒤에도 언론 앞에 나서는 것을 극도로 자제했다. 중요한 계약이나 이적을 앞두고 필요한 경우에만 입장을 밝혔다. 메시 역시 부친처럼 사생활을 철저히 지키며, 불필요한 언론 노출을 피하는 성향으로 알려져 있다. 특히, 호르헤는 메시가 경기장 밖의 복잡한 문제보다 축구와 가족에게 집중할 수 있도록 주변을 잘 정리하는 방패 역할을 해냈다. 바르셀로나를 떠나 파리 생제르맹(PSG)으로 이적할 때, 2023년 미국 인터 마이애미행을 선택할 때도 그는 협상 과정에서 중요한 역할을 했다. 현지 언론들은 “메시가 세계 최고의 선수가 된 것은 자신의 재능과 노력 덕분이지만, 그를 보호하고 성장시킨 환영을 만든 아버지의 역할이 컸다”고 전했다.

아르헨티나성장호르몬바르셀로나연합뉴스에이전트

2026.08.09

새 소식

LobeHub - AI 팀 전체를 고용/스케줄링/보고하는 Chief Agent Operator

여러 AI 에이전트를 한 곳에서 고용/스케줄링/보고 하며 7×24 운영 체제로 조직화, 사용자가 상시 접속하지 않아도 AI 팀 관리 가능 작업 단위로서의 에이전트 개념 채택, 인간과 에이전트가 공진화(co-evolve)하는 인프라 제공 기존 에이전트가 일회성/작업 중심 도구로 컨텍스트 부재 와 고립 상태에서 창 간 수동 인계를 요구하던 문제 해결 에이전트 빌더를 통해 필요한 것을 설명하면 개인화된 AI팀을 자동 구성. 1만개의 이상의 스킬과 연동하고, 어떤 모델이든 이용 가능 Agent Groups 로 에이전트를 실제 협업하는 팀원처럼 다루며 병렬 협업 및 반복 개선 지원 Pages (공유 맥락 콘텐츠 작성), Schedule (부재 중 예약 실행), Project (프로젝트 단위 조직화), Workspace (팀 공유 공간) Evolve : Personal Memory 로 사용자 요구를 이해, 작업 방식에서 학습하는 Continual Learning 과 편집 가능한 White-Box Memory 제공 Vercel, Alibaba Cloud, Docker 기반 Self-Hosted 버전 지원 LobeHub Community License

AI 에이전트에이전트PERICEAI

2026.08.04

새 소식

Retrieval as Reasoning - LLM Wiki가 RAG보다 나은 이유에 대한 실증 벤치마크

문서를 청크 단위로 잘라 벡터로 검색하는 RAG 방식이 아닌, 서로 링크된 마크다운 위키로 만들고 에이전트가 네비게이션하는 LLM Wiki 방식이 나은 이유에 대해 실증한 논문입니다. 논문이 풀어본 문제 청크 검색은 문서를 잘게 잘라 비슷한 조각 몇 개만 꺼내 붙임. 여러 문서를 이어야 답이 나오는 멀티홉 질문에서 약함 조각으로 자르는 순간 조각들 사이의 관계가 사라짐 . 이것이 근본적인 한계 논문은 검색을 '조각 꺼내기'가 아니라 '추론' 으로 접근. 위키를 미리 구성해 두고, 읽고 → 링크 따라가고 → 모자라면 다시 검색하며 여러 번 되짚어 답을 맞춰 감 핵심 요약 컴파일 : 원문서를 양방향 링크가 걸린 위키 페이지로 변환 (검색하는 단위가 청크가 아니라 링크된 페이지) 세 가지 도구 : 검색(search)·읽기(read)·링크 따라가기(link)를 표준 도구로 정의 Error Book : 위키의 구조·의미 오류를 계속 스스로 고침 자가 진화 : 쓸수록 위키 자체가 나아짐 벤치마크 결과 멀티홉 QA 세 종류에서 기준 모델들보다 2.0~8.1 F1 앞섬 별도 벤치마크 AuthTrace에서도 정확도 1위. 특히 여러 문서를 엮는 질문에서 강함 가장 주목할 대목 — Ablation (F1 손실, HotpotQA / MuSiQue / 2Wiki) 순회를 뺐을 때 : −11.7 / −13.8 / −12.2 (가장 치명적) 위키 구조를 뺐을 때 : −6.1 / −7.0 / −6.7 Error Book을 뺐을 때 : −3.8 / −4.0 / −3.4 순서로 보면 순회 > 구조 > 교정. 순회가 구조보다 두 배쯤 중요함 관련 오픈소스 프로젝트 출발은 Karpathy가 제시한 'LLM Wiki' 개념을 구현하되 마크다운 위키 형태로 지식을 축적하고 관리하는 지식 팩토리를 Claude Code 기반으로 운영 중 : https://news.hada.io/topic?id=31691 본 논문을 구현한 것은 아님 . 논문은 나중에 알게 됨 논문에 비춰보니 위키 '구조'엔 오랜 시간 공들였는데, 정작 ablation이 제일 중요하다는 '순회'(에이전트가 쓰기 전에 뭘 얼마나 읽느냐)는 지침 딱 한 줄 이었음 추가한 것 — 읽기 사다리(GROUND Ladder) 에이전트가 위키 페이지를 쓰기 전에 얼마나 읽을지를 다섯 단계로 나눔: ① 페이지가 적어둔 의존성 → ② 인덱스 → ③ 빌드가 미리 계산해둔 링크 → ④ 콘텐츠 검색 → ⑤ 위키 전체 위 단계로 올라가는 건 순서대로가 아님. '지금 근거가 모자란다'는 신호가 있을 때만 그 신호가 가리키는 칸으로 바로 감 논문은 순회를 '답 만들 때' 썼지만, 오픈소스 프로젝트에서는 '읽어 들일 때' 지키는 규칙으로 가져옴 자세한 설명: https://github.com/alfadur7/llm-wiki-newsroom/… 아직 부족한 점 읽기 사다리는 이제 막 구현하였고 효과를 아직 측정하기 전 . 읽기 단계를 올라가다 멈추는 기준도 잠정 수치고 두세 번 돌려 데이터가 쌓이면 기준을 다듬을 예정 링크 논문 (arXiv:2605.25480): https://arxiv.org/abs/2605.25480 오픈소스 레포: https://github.com/alfadur7/llm-wiki-newsroom 규칙 원문(SoT): https://github.com/alfadur7/llm-wiki-newsroom/…

에이전트LLM구조IT가지

2026.08.05

새 소식

송재경, AI와 게임

게임 개발자 송재경은 인간과 AI가 동일한 프로토콜로 접속하는 실험적 MMORPG 'Open MMO' 프로젝트를 공개했습니다. 그는 AI가 구현을 담당하고 인간은 설계와 지시를 맡는 방식으로 개발 패러다임이 변화하고 있으며, 현재를 산업혁명급의 AI 특이점 시대로 평가했습니다.

AI 에이전트에이전트API기억력생산성

2026.07.29