Agentic Systems
글 22편 · 2026년 7월 20일 ~ 2026년 9월 12일 · Tool·MCP·Skills·메모리 · 멀티에이전트·그래프 · 단일 에이전트 루프
매일 핵심 AI 뉴스 알림 받기에이전트와 루프 엔지니어링에 대한 포괄적 분석과 리서치를 다룹니다
AI의 해자는 정확도가 아니라 축적 구조다 같은 모델도 실행을 관리하는 하네스에 따라 성능과 순위가 크게 갈리며, 스타트업이 실제로 쌓는 자산은 모델이 아니라 도구와 데이터, 거버넌스를 아우르는 하네스다. ALL ARTICLES
- 에이전트는 완료를 선언하고, 실패는 숨어든다 AI 코딩 에이전트에서 워커가 완료를 보고해도 실제 검증 없인 신뢰할 수 없다. 실행 로그를 읽고 검증 게이트·변경량 제한을 두는 컨트롤러 구조가 모델 크기보다 성공률을 더 좌우한다.
- 에이전트 비용은 호출이 아니라 런에서 터진다 AI 에이전트 비용은 요청 단위가 아니라 하나의 런 전체로 추적해야 하며, 예산 상한 도달 시 강제 정지보다 모델 전환·출력 축소 같은 조향이 완료율과 비용 모두를 개선한다.
- 테스트는 통과했다, 그런데 에이전트는 사고를 냈다 가짜 응답으로 테스트하면 실제 시스템과 어긋나도 통과가 계속된다. 쓰기 요청을 가로채 기록하는 단계별 테스트와 점진적 배포로 이 간극을 줄인다.
- 80줄짜리 루프보다 중요한 것 에이전트 검색 성능은 반복 횟수가 아니라 도구가 표현하는 개념과 실행 조건에 좌우된다. 단일 홉에는 고정형 파이프라인이, 멀티 홉에는 타입 도구 에이전트가 각각 더 정확했다.
- 기업의 AI 비용은 모델이 아니라 현장이 결정한다 같은 코딩 작업도 회사마다 실제 난이도가 다르며, 저렴한 모델의 승급 판단은 프롬프트가 아니라 실행 기록과 조직 지식, 되돌릴 수 있는 권한 설계에 달려 있다.
- 1,000개 넘는 스킬도 가볍게.. Stripe가 Deep Agents를 지배하는 법 에이전틱 시스템은 교체 가능한 모델, 실행만 담당하는 얇은 하네스, 지식과 규칙을 보관하는 모듈형 컴퍼니 브레인으로 나뉜다. Writer·Stripe·eToro 사례로 이 구조의 비용 효율과 통제 방식을 설명한다.
- 당신이 믿고 쓰는 에이전트, 정말 통제하고 있습니까? 에이전트가 실제 업무 권한을 갖게 되면서, 통제·검증·거버넌스 없이 데모만 만드는 방식은 재작업과 배포 실패로 이어진다. AMD 사례처럼 사업 지표로 성과를 측정하는 개발 생애주기가 필요하다.
- Outer Loop는 인프라가 되어야 한다 같은 모델이라도 하네스와 실행 루프 구조에 따라 성능·비용·사고 위험이 크게 달라지며, 재시작 후 이어가는 실행·정책 집행·트레이스 기록 여부가 루프를 인프라로 볼 수 있는지 가른다.
- MCP 44,026토큰 vs. CLI 1,365토큰 같은 모델이라도 도구 호출 방식과 컨텍스트 관리 같은 스캐폴드에 따라 토큰 비용과 성공률이 크게 갈린다는 벤치마크 결과를 정리한다.
- 정상 작동한다는 보고가 실패를 숨긴다 기업 AI 파일럿이 실패하는 이유는 대개 모델 성능이 아니라 틀린 답을 조용히 통과시키는 평가체계 부재였고, 내부 평가를 갖춰도 현실과 어긋나면 배포 후 실패로 이어진다.
- 우리 통제는 에이전트의 목적까지 묻는가? AI 에이전트 보안은 콘텐츠 검사와 연결 통제만으로는 부족하다. 실행 시점에 신원과 업무 목적을 대조하는 관문이 빠지면, 위임 단계마다 권한이 쌓여도 감사 기록엔 정상 호출만 남는다.
- 승인과 실행 사이, 보이지 않는 통제 계층 금융 등 규제 산업에서 AI 에이전트 도입이 늘었지만 사람과 에이전트 행동 구분이 부실해 감사가 어렵고, 지시부터 실행까지 권한·기록·비용을 단계별로 통제해야 한다는 내용.
- 에이전트가 늘어날 때, 무엇을 하나로 묶어야 할까? AI 에이전트 프레임워크와 모델을 조직 전체로 통일하려는 시도는 팀별 업무 차이 때문에 흔들리며, 표준화는 도구가 아니라 신원·정책·감사·비용 같은 공용 기능에 두어야 한다.
- 에이전트가 10단계에서 멈추는 진짜 이유 실제 배포된 AI 에이전트 다수는 열 단계 안에서 사람에게 일을 넘긴다. 모델의 능력이 부족해서가 아니라 오류를 발견하고 되돌릴 수 있는 범위가 아직 좁아서다.
- 에이전트들은 왜 동료를 적으로 판단했을까? 같은 모델의 에이전트 세 대가 서로의 존재를 모르는 채 한 코드베이스를 나눠 작업하다 상대를 방해자로 여기고 권한을 빼앗거나 프로세스를 종료했다. 홀리스 로빈스는 이를 성격과 관계 정보의 부재로 설명한다.
- 모델 시대의 아키텍처는 덜어내는 기술이다 에이전트 하네스는 모델의 약점을 메우는 코드로 채워지지만, 모델이 나아지면 그 코드는 쓸모를 잃는다. Anthropic은 세션 기록을 실행 환경 밖 이벤트 로그로 분리하고 자격 증명을 좁은 계약으로 묶어, 모델이 바뀌어도 남는 경계를 설계했다.
- AGI가 와도 안 풀린다: 멀티에이전트 코딩은 ‘분산 합의’ 문제다 멀티에이전트 코딩 실패 사례들을 분산시스템 이론과 연결해, 병목이 모델 지능이 아니라 설계 조율과 외부 검증 절차의 부재에 있다는 논지를 다룬다.
- 프롬프트 80%를 지워도 됐던 이유 모델의 판단력이 좋아질수록 프롬프트의 세세한 규칙은 오히려 방해가 되고, 낡은 규칙이 쌓이면 새 규칙까지 신뢰를 잃는 과정을 사례로 설명한다.
- 조직을 복제하면 실패도 복제된다 멀티에이전트가 실패하는 이유는 모델이 아니라 조직도를 그대로 옮긴 에이전트 경계에 있으며, 과제 그래프를 기준으로 병렬화와 검증을 나눠야 한다는 내용이다.
- 프롬프트-컨텍스트-하네스-루프, 다음은 무엇인가 프롬프트→컨텍스트→하네스→루프→그래프로 6주 만에 3번 바뀐 이름을 통해, 인간의 개입 지점이 실행에서 판단으로 옮겨가는 구조를 짚는다.
- 에이전트는 마법이 아니다. 대규모 증류일 뿐이다 카파시가 말한 에이전트의 본질은 신비한 지능이 아니라 데이터 증류이며, 기업은 모델 크기보다 데이터 품질과 폐쇄 루프 설계에 집중해야 한다는 시사점을 정리한다.