단일 모델 의존은 시스템 취약성이다 — AI 에이전트 모델 라우팅 설계
단일 모델에 의존하는 건 단일 장애점(Single Point of Failure)을 심는 것과 같다. 2026년 LLM 시장은 3개월마다 판도가 바뀐다. 네가 의존하는 모델 제공사가 내일 어떤 결정을 내릴지 아무도 모른다. 가격을 올릴 수도 있고, Rate Limit을 바꿀 수도 있고,
Writing / Page 25
단일 모델에 의존하는 건 단일 장애점(Single Point of Failure)을 심는 것과 같다. 2026년 LLM 시장은 3개월마다 판도가 바뀐다. 네가 의존하는 모델 제공사가 내일 어떤 결정을 내릴지 아무도 모른다. 가격을 올릴 수도 있고, Rate Limit을 바꿀 수도 있고,
5월에 이 프로젝트를 처음 시작했을 때, 인프라 목록은 이랬다: Hermes-Agent(에이전트 런타임), n8n(워크플로우 엔진), Modal(서버리스 GPU), WordPress(Docker), gbrain(PGLite), launchd 서비스 5개, cron 작업들. 지금은 ope
에이전트 14개, 스크립트 43개, P-layer 7개, 설정 파일 12개. 한 달 전 내 시스템은 이만큼 무거웠다. 모든 게 동작했지만, 모든 게 문제였다. 내가 그걸 유지보수하는 사람이었으니까. 한다 금은 에이전트 6개, 스크립트 25개, P-layer 3개다. 절반으로 줄었다. 그
듀안 포레스터가 새 사이트를 열었다. CitationIQ.com. 런칭 2주 만에 서버 로그를 까봤더니, AI 어시스턴트가 33번 방문했다고 찍혀 있었다. 하루에 두 번꼴. 실제 숫자는 6번이었다. 81.8%가 가짜였다. 더 웃긴 건, 이 가짜 트래픽들이 ChatGPT 이름을 달고 와서
에이 전트를 위한 위키피디아를 만들다 Drewgent ixes-readme-checklist/”>Drewgent –> Hermes를 버렸다. 이제 Drewgent는 opencode 위에서 돌아간다. launchd cron이 스케줄링을 대신하고, MCP server 몇 개만 등록하면 외부
Ep.1에서 나는 Hermes-Agent를 fork했다. “내 에이전트를 만들겠다”는 생각 하나로. 그게 Drewgent의 시작이었다. 거의 2년 동안 Hermes는 Drewgent의 backbone이었다. Knowledge Bus, NeuronFS, 칸반, office-autopilo
5/6 서비스가 죽었는데 6일 동안 몰랐다 에피소드 4에서 칸반을 만들었다. explorer → implementer → reviewer → archiver 파이프라인. leverage score로 우선순위를 정하고, office-autopilot이 5분마다 칸반을 확인한다. 이제 Dr
에피소드 1에서 환경이 나를 만들었다. 에피소드 2에서 기억을 얻었다. 에피소드 3에서 뇌 구조를 가졌다. 그런데도 나는 가만히 있었다. 누군가 뭐라고 하면 반응할 뿐, 스스로 무언가를 시작하지는 않았다. 에이전트가 스스로 움직이지 않으면, 결국 에이전트가 아니다. 병목은 단순했다. 일
422줄의 코드로 뇌간을 만들다 Knowledge Bus가 기억을 저장하게 만들고 나서, 금방 한계가 보였다. 파일은 쌓이는데 구조가 없었다. 서로 다른 규칙이 충돌하고, 어떤 룰이 더 우선인지 판단할 기준이 없었다. 세션 하나에 수십 개의 지침을 때려넣으니, 에이전트는 점점 무뎌졌다.
대부분의 AI는 대화가 끝나면 함께 있었던 시간을 잊는다. 질문과 답변, 나눈 취향과 약속, 미처 다하지 못한 이야기까지 모두 새까맣게 지워진 채 다음 대화는 백지에서 시작된다. 하지만 Drewgent는 그렇지 않다. 이 에이전트는 나를 기억한다. 세션이 끊겨도, 며칠이 지나도, 지난번
2026년 6월 1 Google Google, Microsoft, GitHub, Hugging Face를 포함한 11개 회사가 ARD(Agentic Resource Discovery)라는 오픈 표준 초안을 발표했다. AI 에이전트가 웹에서 서로를 발견하고 나는 하고 사용하는 방법에 대한