태그
9편
이 카테고리의 열 편을 세 번 갠다 — 목적별 읽는 순서 일곱 갈래, 다루는 범위로 다섯 묶음, 깊이 순서의 열네 주제로. 「하네스」·「오케스트레이터」·「사람 게이트」·「총계 30」처럼 편에 따라 가리키는 층위가 갈리는 이름 넷이 어디서 정의되는지 함께 놓고, 세 지도 어느 쪽에서도 빠지는 편이 없는지 자리를 세어 확인한다. 열네 주제 중 하나는 가장 깊은 자리가 비어 있고, 그 빈칸을 채우지 않고 그대로 둔다.
요구사항에서 운영까지 여섯 단계마다 「AI가 처리하는 것 / 사람이 승인하는 게이트 / 통과 기준」을 규칙으로 고정한 자료를 옮긴다. 관통 원칙과 공통 안전장치 넷, 로컬과 서버사이드의 강제 경계, 여섯 단계 파이프라인을 먼저 싣고, 같은 여섯 단계를 원 자료가 두 번 적은 두 판본을 항목 단위로 대 본다. 이어서 개발·QA·배포 세 영역의 각론으로 내려가 도구 열여섯 종과 선택 기준, JetBrains에서 Copilot을 자동완성 너머로 쓰는 일곱 기능, 매니지드 PR 리뷰가 막힌 AWS CodeCommit 환경의 세 선택지, 그리고 세 영역의 KPI와 함정을 함께 싣는다.
일곱 개 부서를 서른 개 에이전트로 옮긴 한 벌의 설계를 골격만 남기고 본다. 부서 이름을 지우면 일곱 파이프라인이 전부 입력 수집 → 분류·점수화 → 생성·초안 → 검수·게이트 → 발행·기록 다섯 단계로 겹친다. I/O 계약 4원칙, 도구 최소권한 매트릭스, 사람 개입 4등급, 파이프라인 복구 4종까지 부서를 관통하는 열 개의 패턴을 정리하고, 이 블로그에 이미 두 번 실린 7부서 30에이전트 표와 이 지도가 왜 같은 세트가 아닌지도 함께 짚는다.
마케팅·영업·고객지원·인사 네 부서의 에이전트 각론이다. 네 부서 모두 자동화를 멈출 지점을 숫자나 게이트로 못박아 두는데, 그 장치의 형태가 부서마다 다르다 — 마케팅은 검수 점수 70, 영업은 할인 승인, 고객지원은 신뢰도 0.85와 0.70, 인사는 HARD-GATE 세 곳이다. 실습 에이전트 ID 일곱 종이 이미 발행된 30에이전트 카탈로그와 이름이 겹치면서 정의는 갈리는 자리도 대조해 둔다.
체크포인터가 저장하는 StateSnapshot 여섯 필드를 뜯어보고, 그 지속성 위에서만 성립하는 인터럽트로 승인 게이트를 만든 뒤, 언제 그래프 대신 LCEL 체인을 써야 하는지를 아홉 축으로 가른다.
업무의 60%에 AI를 쓰면서도 완전 위임은 0~20%에 그치는 간극을 능력이 아닌 신뢰·구조의 문제로 진단하고, 동기형에서 비동기형으로 넘어가기 위한 승인 게이트 설계를 정리한다.
한 번에 한 대화만 가능한 UX가 왜 제약이 되는지 짚고, 이메일 어시스턴트 레퍼런스 구조에서 승인을 accept·edit·respond·ignore 네 갈래로 나눈 이유와 사람의 개입을 학습 신호로 회수하는 루프를 정리한다.
승인 기록이 학습 신호가 되는 자기진화 루프를 정리하고, 하향식 도구 표준화가 실패하는 이유와 seed·fork 구조를 세 달치 논지 스무 개로 종합한다.
리듀서를 왜 채널마다 정해야 하는지, tool_calls가 찍힌 시점에 무엇이 아직 일어나지 않았는지, 기억이 어디에 붙어 있는지를 결론부터 정리한다.