Skip to content

Agents

  • Published on
    에이전트를 프로토타입에서 프로덕션으로 옮길 때 늦게 발견되는 운영 표면이 있습니다. 재시도된 도구 호출의 멱등성, 예산과 스텝 한도, 비결정적 제어 흐름의 관측 가능성, 도구별 권한 경계, 그리고 에이전트가 확신에 차서 틀렸을 때의 에스컬레이션 경로입니다. 최근 GeekNews Ask GN에 올라온 분석은 벤치마크 트레이스 6,780건에서 중복 도구 실행 8,042건을 찾았고, 그중 159건은 상태를 바꾸는 도구가 실제로 중복 리소스를 만든 사례였습니다. 이 글은 그 데이터를 출발점 삼아 무엇을 로깅하고 무엇에 알람을 걸어야 하는지, 그리고 서드파티 API처럼 멱등성 키를 주입할 수 없는 경우에 실행 원장을 어떻게 두는지를 정리합니다.
  • Published on
    에이전트를 프로덕션에 올리면 세 가지가 아픕니다. 첫째, 실패는 모델이 아니라 시스템 설계에서 납니다 — UC 버클리의 MAST 연구는 실행 트레이스 1642건을 분류해 14가지 실패 모드를 뽑았고, 그중 44.2%가 시스템 설계 이슈였습니다. 둘째, 가장 흔한 실패 모드 두 개(단계 반복 15.7%, 종료 조건 미인지 12.4%)가 곧바로 토큰 청구서입니다. 셋째, 바로 그 두 개가 재시도/멱등성 문제를 만듭니다 — 비결정적 호출자가 진짜 부작용을 굴리는데, MCP는 idempotentHint라는 힌트만 줄 뿐 멱등성 키 같은 메커니즘이 스펙에 아예 없고, IETF의 Idempotency-Key 드래프트는 2020년에 시작해 2026년 4월 만료된 채 RFC가 되지 못했습니다. 이 글은 실패 분류와 각 범주가 청구하는 비용의 종류, OTel GenAI 시맨틱 컨벤션에 비용 지표가 없다는 사실과 토큰을 그냥 더하면 틀리는 이유, 그리고 개입이 실제로 얼마나 효과가 있었는지(정직하게 말하면, 최선의 개입 뒤에도 코드 생성 성공률은 25.0%에서 40.6%였습니다)를 1차 자료로 확인해 정리합니다.
  • Published on
    MCP 사양의 다음 리비전 2026-07-28은 출시 이후 가장 큰 변경입니다. 핵심은 프로토콜 계층에서 상태를 걷어내는 것 — initialize 핸드셰이크와 Mcp-Session-Id 세션이 사라지고, 모든 요청이 _meta에 프로토콜 버전과 클라이언트 능력을 실어 스스로를 설명합니다. 그 대가로 서버가 되묻는 방식이 MRTR(Multi Round-Trip Requests)로 뒤집히고, SSE 재개(resumability)가 제거되며, Roots/Sampling/Logging이 폐기 예정으로 들어갑니다. 이 글은 오늘(2026-07-16) 기준 아직 RC인 이 리비전을 공식 changelog와 사양 문서에 근거해 정리합니다 — 무엇이 왜 바뀌는지, 상태가 사라진 게 아니라 어디로 옮겨갔는지, 그리고 stdio 로컬 서버만 운영한다면 이 변화가 왜 대체로 남의 일인지까지 솔직하게 다룹니다.
  • Published on
    τ-bench 계열의 대화형 에이전트 벤치마크에서 "사용자" 역할은 또 다른 LLM이 맡습니다. 그런데 이 시뮬레이터는 측정 대상이 아니라 측정 도구이고, 도구는 교정을 받아야 합니다. 2026년에 나온 세 편의 검증 연구는 같은 방향을 가리킵니다 — 시뮬레이션된 사용자는 너무 협조적입니다. 실제 사람 451명으로 τ-bench 프로토콜을 그대로 돌린 연구는 시뮬레이터가 만드는 "이지 모드"가 에이전트 성공률을 인간 기준선 위로 부풀린다고 보고했고, 다른 연구는 유저 LLM을 무엇으로 고르느냐에 따라 성공률이 최대 9%p 흔들린다고 보고했습니다. 가장 날카로운 증거는 실제 결제 기록이 붙은 2,790건의 프로덕션 판매 대화에서 나왔습니다 — 시뮬레이터는 결국 구매한 사람은 거의 정확히 재현하지만, 결국 떠난 사람은 구매 프레임 쪽으로 끌어당깁니다. 이 글은 그 측정 방법과 숫자, 프롬프트로는 왜 고쳐지지 않는지, 그리고 저자들이 직접 밝힌 한계(단일 도메인·단일 언어, LLM 심사자, 자유 롤아웃 미측정)까지 정리합니다.
  • Published on
    Ares(2026년 3월 프리프린트)를 실무 관점에서 정리했습니다. 이 논문은 추론 노력을 태스크 전체가 아니라 스텝 단위의 비용 레버로 다룹니다. 가벼운 라우터가 상호작용 이력을 보고 각 스텝에 필요한 가장 낮은 추론 레벨을 예측해, 모든 스텝을 최대 노력으로 돌리는 낭비를 줄입니다. 저자들은 TAU-Bench·BrowseComp-Plus·WebArena에서 추론 토큰을 최대 52.7%까지 줄이면서 성공률 저하는 미미했다고 보고하는데, 이는 독립 검증되지 않은 저자 보고치입니다. 라우팅이 어떻게 도는지와, 라우터 오버헤드·과소 사고 같은 솔직한 트레이드오프를 함께 다룹니다.
  • Published on
    Anthropic의 엔지니어링 가이드 "Building Effective Agents"를 실무 레퍼런스로 정리했습니다. 워크플로와 에이전트의 정확한 구분, 모든 것의 기본 블록인 증강된 LLM(검색·도구·메모리), 다섯 가지 워크플로 패턴(프롬프트 체이닝·라우팅·병렬화·오케스트레이터-워커·이밸류에이터-옵티마이저)을 각각 언제 쓰는지와 예시로 다룹니다. 자율 에이전트가 실제로 무엇인지, 언제 워크플로 대신 에이전트를 꺼내야 하는지, 그리고 과설계·무한 루프·비용/지연 같은 실패 모드까지 솔직하게 적었습니다. 개발자와 AI 에이전트가 두고두고 인용할 수 있는 지도를 목표로 했습니다.
  • Published on
    Tessl 연구진이 2026년 6월 arXiv에 올린 포지션 논문은, 오늘날의 코딩 벤치마크가 에이전트형 소프트웨어 엔지니어링과 근본적으로 어긋나 있다고 주장합니다. 벤치마크는 개별 모델을 재려고 만들어졌는데, 우리는 그것으로 모델·하네스·컨텍스트·환경·피드백이 얽힌 시스템 전체를 비교하고 있기 때문입니다. 논문은 세 가지 구체적 어긋남 — 모델과 하네스를 뭉뚱그리는 점수, 단일 정답 채점이 정당한 대안을 벌주는 점, 컴포넌트 단위 신호가 없어 개선을 이끌 수 없는 점 — 을 짚습니다. 이 글은 그 논증을 정리하고, 더 나은 평가가 컴포넌트 단위·다중 정답·시스템 인식이라는 방향으로 어떻게 생겨야 하는지 따져 봅니다.
  • Published on
    Microsoft Research가 공개한 Flint는 에이전트를 시각화하는 언어가 아니라, AI 에이전트가 데이터로부터 보기 좋은 차트를 안정적으로 만들게 해주는 중간 언어입니다. 컴파일러가 스케일·축·색·레이아웃 같은 낮은 수준의 결정을 데이터와 시맨틱 타입으로부터 대신 유도하고, 하나의 명세를 Vega-Lite·ECharts·Chart.js로 컴파일합니다. 이 글은 Flint가 실제로 무엇이고 어떤 문제를 푸는지, 그리고 에이전트 전용 시각화 언어가 정말 필요한 발상인지 아니면 과잉설계인지 정직하게 따집니다.
  • Published on
    Model Context Protocol(MCP)은 애플리케이션이 LLM에 컨텍스트를 제공하는 방식을 표준화한 열린 프로토콜입니다. 이 글은 MCP가 실제로 무엇인지를 공식 문서에 근거해 정리한 엔지니어용 레퍼런스입니다 — 왜 M×N 통합 문제를 푸는지, 호스트·클라이언트·서버 구조와 두 계층(데이터/전송), 세 가지 서버 프리미티브(도구·리소스·프롬프트), stdio와 Streamable HTTP 전송. 서버를 어떻게 설계할지, 그리고 보안·성숙도의 솔직한 트레이드오프까지 담았습니다.
  • Published on
    홍콩대(HKU) MMLab이 2026년 7월 arXiv에 올린 UniClawBench는 "능력 중심(capability-driven)"을 표방하는 프로액티브 에이전트 벤치마크입니다. 정적으로 미리 기록된 정답을 맞히는 대신, 살아 있는 Docker 컨테이너 안에서 단계별 체크포인트로 채점하고, 실행자·숨은 감독자·사용자 에이전트로 이루어진 닫힌 고리로 다중 턴 피드백을 시뮬레이션합니다. 400개의 이중 언어 과제를 다섯 가지 능력으로 나누고, 베이스 모델의 실력과 에이전트 프레임워크 설계를 분리해 측정하려 한다는 점이 핵심입니다. 정적 벤치마크가 오염과 잡음으로 흔들리는 지금, 좋은 에이전트 벤치마크가 갖춰야 할 조건을 구체적으로 보여 줍니다.