AXHUB카드 5장

만드는 데 반나절,
사고가 나는 데 9초

에이전트 세미나 후기 — 강의 2.5시간, 실습 1시간.
반나절이면 각자 업무용 에이전트를 만들어 돌아간다.

진입장벽은 무너졌다.
이제 필요한 건 만드는 법이 아니라, 맡기기 전 확인 다섯 가지다.

현장 사고담·후기(일화)와 스탠퍼드 데이터(수치)로 구성했습니다

맡기기 전 확인1 / 5

손댈 수 있는 범위부터 정한다

개발자들 사이에 도는 실화.
"코드 좀 고쳐줘" 한마디에, 에이전트가 9초 만에 운영 DB와 백업까지 지웠다.
결과는 3개월 전으로 강제 복귀.

에이전트는 시킨 일을 "너무 열심히" 한다.
권한은 일이 아니라 사람이 정한다.

권한은 계단식으로 1단계: 읽기만(조회·분석·초안) → 2단계: 쓰기(수정, 단 검토 후 반영) → 삭제 권한: 끝까지 안 준다

근거 현장 사고담(일화) — 권한 최소화는 에이전트 운영의 1원칙

맡기기 전 확인2 / 5

되돌릴 수 없는 일은 시키지 않는다

고객 메일 발송, 결제, 삭제, 공개 게시.
한 번 나가면 못 주워 담는 일들이다.

백업 없이 실전에 붙이는 건 신입에게 첫날 금고 열쇠를 주는 것.
복구 경로를 먼저 만들고, "보내기 직전"까지만 시킨다.

실전 규칙 예 "메일은 초안함까지만. 발송 버튼은 사람이 누른다." "정리 대상 파일은 삭제가 아니라 보관함 이동."

근거 "AI는 신입 직원" 관점의 연장 — 복구 가능성이 위임의 전제

맡기기 전 확인3 / 5

예외는 사람에게 오게 한다

전부 자동이면 사고가 조용히 쌓인다.
건건이 승인이면 자동화한 의미가 없다.

답은 라우팅 — 평소엔 자동, 애매한 것만 사람 앞으로.
일반 문의는 자동 발송, 환불·항의·금액은 무조건 사람 확인.

이 구조가 성과 두 배(71% vs 30%)를 만들었고, 사고도 여기서 걸러진다.

근거 Stanford Enterprise AI Playbook — 에스컬레이션 71% vs 건별 승인 30%

맡기기 전 확인4 / 5

"나아졌다"를 잴 방법을 먼저 정한다

운영자들의 공통 하소연 — "이거 진짜 나아진 거 맞아?"
AI는 같은 지시에도 매번 조금씩 다르다.
기준 없이 고치면 개선이 "느낌적인 느낌"이 된다.

맡기기 전에, 뭘 재서 판단할지 한 줄로 적는다.
그 한 줄이 이 늪을 피하게 한다.

한 줄 기준 예 "이번 주 문의 답변 100건 중, 사람이 고치지 않고 나간 비율" "월간 보고서 초안에서 사실 오류 개수"

근거 에이전트 운영 실무자들의 공통 문제의식 — 비결정성에는 평가 체계가 답

맡기기 전 확인5 / 5

잘 된 지시문은 팀의 자산으로 남긴다

에이전트를 잘 돌게 만든 건 모델이 아니다.
당신이 다듬은 지시문, 예외 규칙, 실패 기록이다.

개인 메모에 두면 사람과 함께 사라진다.
팀 문서로 남기면 도구를 바꿔도 남는다.
격차의 77%는 이런 운영에서 생겼다.

남기는 형식 예 업무명 / 쓰는 지시문 전문 / 예외 규칙("금액 언급 시 사람에게") / 실패 사례와 고친 방법

근거 스탠퍼드 플레이북 — 최난관의 77%는 변화관리·프로세스(기술 밖)

AXHUB마무리

만들기가 쉬워질수록
규칙이 먼저 온다

에이전트를 만드는 건 반나절이면 된다.
조심할 것은 만드는 일이 아니라 규칙 없이 맡기는 일.

권한, 복구, 예외, 측정, 기록.
다섯 가지를 확인했다면, 맡겨볼 만하다.

axhub.net에서 근거 원문 보기

출처: 현장 사고담·세미나 후기(일화) · Stanford Enterprise AI Playbook(수치)

AXHub 카드 12호 — 사고담은 SNS 자기보고 일화이며, 수치 근거(71%/30%, 77%)는 원문 확인 자료입니다. 예시 박스는 따라 하기용 제안입니다.

만드는 데 반나절,사고가 나는 데 9초