태그
44편
7개 부서 30에이전트 세트에서 개발기술 4종을 뺀 여섯 부서 26종을 부서별로 펼친다. 각 부서의 위임 흐름 도식은 인계 화살표 35개마다 라벨을 달고 있고, 그중 여덟 개가 부서 밖으로 나간다. 절마다 정리된 프롬프트 설계 기법 39가지를 모델의 재량을 어디서 좁히는지에 따라 여섯 갈래로 전수 배정하고, 이미 발행된 카탈로그·품질 편과 겹치는 자리를 자리별로 표시한다.
7개 부서 30개 에이전트 정의서를 한 장의 표로 펼친다. 모델은 opus 10 : sonnet 20으로 갈리고 도구 변형은 세 가지뿐인데, 정작 외부 시스템 연동은 프론트매터에 드러나지 않는다. 사람 검수 필요도의 요약값과 카탈로그를 세어 본 값이 어긋나는 자리, 그리고 같은 카테고리의 다른 글에 있는 30에이전트 표와 이 표가 같은 세트가 아니라는 근거도 함께 짚는다.
7개 부서 30에이전트 세트에서 개발기술 4종을 자세히 보고, 나머지 26종 중 개발조직 실무로 옮길 수 있는 것과 참고만 할 것을 가른다. 재사용 후보 10종이 실제로 옮기는 것은 에이전트가 아니라 그 에이전트가 강제하던 형식이며, 도입 순서를 개수로 끊는 근거는 트리거 키워드 충돌이다. 마지막으로 이 세트에 아예 자리가 없는 여섯 영역을 짚는다.
에이전트 하나를 5필드 JD로 정의하고, 여럿을 키워드 교집합이 공집합이 되게 묶고, Hook·Cron·수동 세 트리거가 같은 커맨드 하나를 호출하게 만든다. 그 위에 체크인/체크아웃 사이클과 로컬→운영 전환 시 붙여야 할 관측·통제 수단, 자리에 없을 때 지시하는 세 경로까지 잇는다.
에이전트 정의서 한 개의 구조를 프론트매터 4필드와 본문 7섹션으로 분해하고, 같은 스키마로 쓰인 30종에서 관찰된 품질 편차를 대조표로 본다. 형식 항목은 30/30으로 균질한데 권한 축소·승인 게이트·면책은 5/30, 3/30, 1/30으로 떨어진다. 그리고 경계 섹션이 실재하지 않는 이름을 지목한 건수가 원 자료의 산문과 표에서 갈린다는 점도 짚는다.
파이프라인·분업·팀장-팀원 세 패턴을 실패 모드 네 개씩 붙여 나란히 세우고, 그것을 실제로 구현하는 Subagents·Agent Teams·Worktree가 상하 관계가 아니라 논리·세션·물리라는 서로 다른 격리 축이라는 점을 판단 흐름도까지 내려가 정리한다.
스킬과 에이전트를 가르는 것이 기능이 아니라 자율성이라는 데서 출발해, 정의서 한 장을 frontmatter 핵심 5·확장 5와 역할·절차·제약 3섹션으로 분해하고, 문서대로 동작하지 않는다고 보고된 항목 세 건까지 버전 표기 없음을 명기한 채로 옮긴다.
구조를 다 그려 놓고도 팀이 첫 턴에 멈추는 곳 — spawn 순서, 비동기 메시지, 파일 소유권, 종료 프로토콜 — 을 증상별로 짚고, 비용 3원칙과 실습 2건, 에이전트·훅·MCP를 한 벌로 묶은 오픈소스 환경 사례까지 잇는다.
에이전트 루프가 무너지는 열 가지 방식을 증상·원인·해결로 정리하고, 모델을 바꾸기 전에 좁혀야 할 6단계 진단과 도입 자체를 루프로 다루는 조직 절차, 근거 강도 구분법까지 다룬다.
대용량 데이터를 LLM 컨텍스트에 넣지 않는 인터페이스 규약, 툴 안에 또 에이전트가 들어가는 4층 구조, 그리고 분기 하나가 실패했을 때 결과물을 어떻게 마감할 것인가를 정리한다.
체크포인터가 저장하는 StateSnapshot 여섯 필드를 뜯어보고, 그 지속성 위에서만 성립하는 인터럽트로 승인 게이트를 만든 뒤, 언제 그래프 대신 LCEL 체인을 써야 하는지를 아홉 축으로 가른다.
화면에 고를 컨트롤이 없는 제품에서 라우팅이 어디로 가는지 추적하고, chatbot ↔ tools 되돌림 엣지 하나로 도구 반복 호출을 만든 뒤 라우팅 규칙이 코드가 아니라 프롬프트에 있음을 확인한다.
Fan-out/Fan-in의 전제 조건과 평가가 나쁠 때 어느 모듈로 되돌아갈지의 문제, 그리고 서브그래프가 그대로 멀티에이전트로 확장되는 구조를 정리한다.
그래프를 노드로 꽂는 서브그래프 합성과 스키마가 다를 때의 변환 래퍼, 그리고 이미 돌아가는 파이프라인 중간에 신규 단계를 끼워 넣는 7단계 절차를 정리한다.
생성한 코드를 돌려 보고 고치는 순환을 상태 설계부터 세우고, 임의 코드 실행의 위협 일곱 가지를 격리 등급에 매핑한 뒤 사이클이 있는 그래프를 어떻게 끝낼 것인가를 정리한다.
업무의 60%에 AI를 쓰면서도 완전 위임은 0~20%에 그치는 간극을 능력이 아닌 신뢰·구조의 문제로 진단하고, 동기형에서 비동기형으로 넘어가기 위한 승인 게이트 설계를 정리한다.
도구 개수가 아니라 책임의 충돌이 분할 기준이라는 관점에서 단일 에이전트 두 사례를 뜯어보고, Network·Supervisor·Hierarchical 세 토폴로지를 중앙 통제와 종료 판정 주체로 가른다.
검증 노드가 실제로 보장하는 범위, 비용이 늘어나는 세 경로와 종료 조건 4겹, 실행 권한을 줄 때의 최소 요건, 그리고 에이전트가 개발조직에 요구하는 것을 정리한다.
단방향 파이프라인이 무너지는 지점을 짚고, 모듈 경계를 정하는 일곱 가지 기준과 앞 단계를 다시 돌리지 않고 이어서 개발하는 기법을 정리한다.
에이전트를 모델·도구·메모리·플래너·실행 루프 다섯 층으로 분해한 뒤, 프롬프트 체이닝부터 컴퓨터 유즈까지 열한 개 패턴을 자율성 수준과 무너지는 지점으로 나란히 세운다.
내장 툴과 @tool 커스텀 툴의 설계 지점을 정리하고, 원본 데이터를 그대로 넘기지 않는 것이 왜 컨텍스트 예산 관리인지를 주식분석 4역할 파이프라인으로 확인한다.
에이전트 하나를 무엇으로 규정하고, 여럿을 어떤 구조로 묶고, 사람이 최종 결정하는 자리를 어디에 두는지를 결론부터 정리한다. 협업 구조 3종의 트레이드오프와 격리 3계층, 개수가 늘 때 가장 먼저 깨지는 것까지 열 문항.
금융권 도입 사례의 정량 지표를 확인한 뒤, 에이전트 시대의 역할을 오케스트레이터·메이커·빌더 세 층으로 나눈 모델과 그것을 6주 사이클로 옮긴 실행 프레임워크를 정리한다.
플랫폼 시프트마다 절반이 된 채택 기간과 15년째 정체된 1인당 생산성을 나란히 놓고, 에이전트의 진짜 병목이 모델이 아니라 도구 개발이었으며 표준화가 그것을 푼 인센티브 구조를 정리한다.
자율 에이전트 여럿을 감사 가능하게 굴리는 아키텍처를 단일 디스패처·워커 격리·결정 로그로 분해하고, 알림 정책과 시크릿 처리까지 운영 규약 수준으로 정리한다.
에이전트의 정의가 '도구를 쓰는 LLM'에서 '경로와 종료를 모델이 정하는 시스템'으로 이동한 과정을 따라가고, 오류 비용과 가역성으로 자율성의 상한을 긋는 판단 프레임을 정리한다.
리포트 자동화가 수렴하는 5단계를 세우고, 서브테마 5개를 노드 5개로 미리 펼친 그래프가 왜 데이터 개수에 결합되는지, 그리고 병렬화 지점이 왜 두 층으로 나뉘는지를 코드로 따라간다.
조작할 수 있는 컨트롤은 State 필드로, 화면에 나타나는 순서는 노드 실행 순서로 번역하는 5단계 절차를 세우고, Focus 값 하나가 분기 키가 되는 단일 에이전트 그래프까지 그린다.
에이전트 스택의 세 선택지를 초기 속도·통제·락인 등 아홉 축으로 가르고, 프로덕션 도입률과 규모별 우려 지표로 실제 산업이 어느 쪽을 골랐는지 확인한다.
한 번에 한 대화만 가능한 UX가 왜 제약이 되는지 짚고, 이메일 어시스턴트 레퍼런스 구조에서 승인을 accept·edit·respond·ignore 네 갈래로 나눈 이유와 사람의 개입을 학습 신호로 회수하는 루프를 정리한다.
루프의 관리 단위를 런타임 계약으로 정의하고 목표·상태·정책·도구·관찰·검증기·종료·격리 여덟 표면으로 분해한 뒤, 언제 루프가 과설계가 되는지를 검증 가능성 기준으로 가른다.
승인 기록이 학습 신호가 되는 자기진화 루프를 정리하고, 하향식 도구 표준화가 실패하는 이유와 seed·fork 구조를 세 달치 논지 스무 개로 종합한다.
장기 실행을 관리하는 하네스가 실제로 어떤 부품으로 조립되는지 다섯 구성물로 나누고, 세션 시작 비용을 만드는 고정 지식 일곱 종과 컨텍스트 상한의 벤치마크 근거를 토큰 단위로 분해한다.
제어 표면이 프롬프트에서 컨텍스트로, 다시 루프로 넓어진 역사를 정리하고 도구 호출·추론연구·런타임 제품화·벤치마크 이동이라는 네 촉발 요인과 세 패러다임의 차이를 비교한다.
모델 상향 평준화와 제품 성능이 비례하지 않는 원인을 동작 방식의 고정성 네 가지로 진단하고, 오차 누적과 하네스 4계층, 실패를 규칙으로 승격시키는 복리 원리를 정리한다.
하네스가 Supervisor 패턴과 무엇이 다른지를 상태의 소재지로 가르고, 컨텍스트 38%가 0%로 떨어지는 실측과 그 구조가 RAG의 정의까지 바꾸는 과정을 정리한다.
에이전트가 무엇이고 언제 쓰지 않아야 하는지, 네 프레임워크가 무엇으로 갈리는지를 결론부터 정리하고, 자주 굳어지는 오해를 함께 교정한다.
LLM 단독에서 코딩 에이전트까지의 개념 계보를 한 장으로 놓고, 각 단계가 앞 단계의 무엇을 풀고 대신 무엇을 새로 만드는지를 정리한다.
챗봇과 에이전트를 가르는 것은 도구가 아니라 반복의 주체라는 관점에서 출발해, LLM 단독의 세 한계와 Naive RAG가 검색 실패를 스스로 모르는 구조까지 짚는다.
세 에이전트 프레임워크를 12개 축으로 비교하고, 추상화 수준과 제어권이 반비례한다는 트레이드오프를 의사결정 트리로 정리한다.
리듀서를 왜 채널마다 정해야 하는지, tool_calls가 찍힌 시점에 무엇이 아직 일어나지 않았는지, 기억이 어디에 붙어 있는지를 결론부터 정리한다.
대화 이력이 매 턴 1개로 초기화되는 증상에서 출발해, 노드가 낸 값을 기존 값에 어떻게 합칠지 정하는 채널별 병합 규칙이 리듀서임을 3회차 실행 출력 대조로 확인하고 슈퍼스텝 병합 모델까지 내려간다.
에이전트 확산의 병목이 왜 연동 개수였는지 짚고 MCP와 A2A가 서로 다른 층에 놓이는 이유를 정리한 뒤, 2025년의 벤치마크·도입 수치·회의론을 출처 조건과 함께 나란히 놓는다.
결정과 실행을 두 곳에 나눠 두는 LangGraph의 2단 구조를 코드로 확인하고, 되돌아오는 엣지 하나로 DAG가 순환 에이전트가 되는 지점까지 배선 세 줄로 따라간다.