Category
AI 에이전트
AI 에이전트는 목표를 받아 스스로 계획을 세우고 도구를 호출해 작업을 끝까지 수행하는 시스템이다. 단발 응답형 챗봇과 달리 다단계 추론·실행·재시도 루프를 돈다. 코드 작성, 리서치, 운영 자동화에 실제 투입되며 권한과 검증 설계가 성패를 가른다.
Make 시나리오 cron을 정각에 박으면 그날 슬롯을 놓치는 이유 (date:less 경계)
Make에서 19시 정각 cron이 그날 19시 발행을 매번 건너뛰던 원인은 date:less 게이트의 경계 비교였다
OpenClaw: 개명 직후 빠르게 번진 셀프호스팅 메신저 비서
OpenClaw는 자기 기기나 VPS에서 직접 돌리는 셀프호스팅 개인 AI 어시스턴트 게이트웨이(gateway)다. 코딩 특화 도구가 아니라 WhatsApp·Telegram·Slack·Signal·iMessage 등 이미 쓰는 메신저로 응답하는 범용 비서이며, 약 23개 메신저를 지원한다. 오스트리아 개발자 Peter Steinberger가 만들었고 마스코트는 우주 바닷가재 Molty, MIT 라이선스로 공개된다. 전신 어시스턴트에서 여러 차례 개명을 거쳐 2026년 1월 말 OpenClaw(Open=오픈소스, Claw=바닷가재)로 최종 개명했다. 그 직전 단계인 Moltbot 개명(2026-01-27)은 Claude/"Clawd" 유사성과 바닷가재 마스코트를 문제 삼은 Anthropic의 트레이드마크 항의가 원인이었고, 최종 개명 발표 후 매우 빠르게 바이럴을 탔다.
[상록] AI 에이전트 메모리 입문: 프로토타입과 프로덕션을 가르는 한 가지
LLM은 기본적으로 stateless다 — 매 호출이 백지에서 시작하므로, 세션을 넘어 맥락을 잇지 못하면 에이전트는 같은 실수를 반복한다. 2026년 실무에서 프로토타입과 프로덕션을 가르는 건 모델이 아니라 '기억하느냐'다. 핵심은 컨텍스트 엔지니어링 — 프롬프트뿐 아니라 메모리·도구·검색·상태까지 정보 환경 전체를 설계하는 것이다. 메모리는 단일 세션 안에서만 존재하는 in-context 메모리와, 트리거·날짜·주를 넘겨 살아남는 외부 메모리(DB·CRM·데이터 스토어)로 나뉜다. 좋은 메모리 페이로드는 작고, 타입이 명확하며, 비즈니스 키에 묶인다 — 고객 ID·활성 케이스 ID·현재 상태·마지막 의미 있는 이벤트·다음 결정에 필요한 최소 맥락만 저장한다. 검색·아카이브용 벡터 저장소는 pgvector로 시작해 지연이 문제될 때 Qdrant·Pinecone 등으로 갈아타는 식이 현실적이다.
Hermes 4.3 공개, 36B 분산학습 모델이 70B에 근접한다
Nous Research가 2025년 12월 3일 Hermes 4.3을 공개했다. 베이스는 ByteDance의 Seed-OSS-36B-Base이며, 36B 규모로 기존 Hermesundefined70B에 근접하거나 일부 지표를 넘는다. 학습은 Psyche 네트워크의 분산학습으로 이뤄진 프로덕션 분산학습 모델이다. Hermes 4(2025년 8월, 405B·70B·14B 패밀리)와는 별개 라인으로 표기된다.
Hermesundefinedtool-use 포맷, XML 태그로 함수 호출과 추론을 분리한다
Hermesundefined모델은 tool-use를 XML 태그 포맷으로 표현한다. 시스템 프롬프트에서 JSON function 스키마를 <tools>...</tools>로 선언하면, 모델은 <tool_call>{...}</tool_call>로 호출하고 결과는 <tool_response>로 피드백한다. 하이브리드 추론은 <think>...</think> 세그먼트로 사고를 방출하며 챗 템플릿의 thinking=True나 시스템 프롬프트로 토글한다. 서빙 시 vLLM은 --tool-call-parser hermes를, SGLang은 qwen25 파서를 쓴다. 405B와 70B는 Meta-Llama-3.1 기반(라이선스 llama3), 14B는 Qwen3-14B 기반(apache-2.0)이며 권장 샘플링은 temperature 0.6, top_p 0.95, top_k 20이다.
Anthropic, 멀티 에이전트 오케스트레이션 공개 베타에 Agent SDK 크레딧 분리
Anthropic이 Claude Managed Agents에 멀티 에이전트 오케스트레이션을 추가했다. 리드 에이전트가 작업을 쪼개 각 조각을 전담 서브에이전트에게 위임하고, 서브에이전트들은 각자 모델·프롬프트·도구를 갖고 공유 파일시스템 위에서 병렬로 일한다. 리드는 작업 중간에 진척을 점검할 수 있고, 전 과정이 Claude Console에서 감사 가능하다 — 어떤 서브에이전트가 무엇을 어떤 순서로 했는지, 작업 결정의 근거까지 들여다본다. 한편 2026-06-15부터 구독 플랜에서 Claude Agent SDK 사용량이 대화형 한도와 분리된 별도 월간 'Agent SDK 크레딧'에서 빠진다(Pro $20·Max 5x $100·Max 20x $200). Agent SDK는 Claude Code를 떠받치는 동일 하니스 위에 서브에이전트·세션·MCP 지원을 묶은 라이브러리로, Python·TypeScript로 제공된다.
2026 에이전틱 코딩 도구 지형도: 벤치마크는 도구마다 다르게 이긴다
2026년 에이전틱 코딩 도구 비교를 보면, 단일 '최강'은 없고 벤치마크마다 승자가 갈린다. 터미널 작업 중심의 Terminal-Bench 계열에서는 Codex CLI가 선두로, Claude Code와 Gemini CLI가 뒤를 잇는 양상이 보고된다. 반면 실제 저장소 이슈를 푸는 SWE-bench Pro 계열에서는 Claude Code(Opus 4.x)가 앞서는 결과가 나온다. 도구 철학도 다르다 — Claude Code는 터미널·파일시스템·git 히스토리에 직접 붙는 에이전트 중심이고 대용량 컨텍스트로 교차 파일 의존성을 읽는 데 강하다. Cursor는 IDE 우선에 빠른 탭 자동완성·멀티모델 라우팅, 2026년 초 CLI와 클라우드 핸드오프를 추가했다. 결론은 '벤치마크 점수 하나로 고르지 말고, 작업 형태(터미널 자동화 vs 저장소 PR vs 인터랙티브 IDE)에 맞춰 고르라'는 것이다.
컴퓨터·브라우저 에이전트 2026: 픽셀 vs DOM, 세 진영의 설계 차이
2026년 컴퓨터·브라우저 에이전트가 실제 워크로드에 쓸 만해졌고, 세 진영이 서로 다른 아키텍처를 택했다. Anthropic의 Claude는 화면 스크린샷을 받아 마우스·키보드 입력을 돌려주는 범용 computer use 도구를 노출하되, 실제 실행 환경은 고객 책임이다 — 즉 화면을 시각적으로 분석해 클릭·입력을 수행하는 픽셀 기반에 가깝다. OpenAI는 Codex Background Computer Use로 엔지니어의 메인 작업 환경과 병렬로 별도 데스크톱 세션에서 에이전트를 돌린다. Google의 Gemini Computer Use는 Project Mariner 계보로, 원시 픽셀 파싱보다 DOM 인식을 우선한다. 오픈소스 쪽에서는 Browser Use가 Playwright를 감싸 Claude·GPT·Gemini·로컬 모델을 백엔드로 붙이는 가장 인기 있는 프레임워크다. 다만 안티봇 탐지·동적 레이아웃·인증 플로우는 여전히 난제로 남아 있다.
[상록] 1% 오류가 63% 실패로: 에이전트는 왜 관측·평가가 동시에 필요한가
프로덕션 에이전트는 확률적으로 동작하고, 도구를 동적으로 고르며, 비결정적 출력을 다단계로 연쇄한다. 이때 단계당 1% 오류율이 누적되면 전체 실패 확률이 약 63%까지 치솟는다 — 이 '순차 오류 누적'이 에이전트 신뢰성의 정의적 난제다. 그런데 현장에는 간극이 있다. 프로덕션 에이전트를 가진 팀의 약 89%가 어떤 형태로든 관측(observability)을 도입했지만, 제대로 된 평가(evaluation)를 돌리는 곳은 약 52%에 그친다. 대부분의 실패가 바로 이 두 수치의 간극에서 일어난다. 관측은 실행 트레이스·도구 호출 시퀀스·추론 경로·출력 품질 신호를 모아 일반 APM이 놓치는 실패를 드러내고, 평가는 배포 전·후로 그 행동을 측정한다. 프로덕션 레디 에이전트는 구조화 로깅·런타임 거버넌스·드리프트 모니터링·정의된 에스컬레이션 경로를 갖추고, 조용히 망가지는 대신 실패를 우아하게 처리한다.