⚡ 3줄 요약
- AI 에이전트를 망치는 건 모델 성능이 아니라 권한 설계다 — 똑똑한 모델일수록 잘못된 권한이 더 위험하다.
- 에이전트는 하나의 프로그램이 아니라 목표·도구·권한·검증 네 축이 맞물린 시스템으로 봐야 한다.
- 자동화의 성숙도는 “얼마나 많이 맡기느냐”가 아니라 “어디서 사람이 멈추느냐”로 갈린다.
AI 에이전트를 도입할 때 다들 모델부터 고른다. 어느 모델이 더 똑똑한지, 벤치마크 점수가 몇 점인지. 그런데 실제 사고는 거의 모델이 멍청해서 나지 않는다. 멀쩡한 모델에 과한 권한을 줬을 때 난다. 프로덕션 DB를 지우고, 고객에게 잘못된 메일을 보내고, 결제를 반복 실행하는 사고는 전부 “모델이 그럴 줄 몰랐다”가 아니라 “그걸 할 권한이 있었다”에서 온다. 에이전트 설계의 본질은 모델 선택이 아니라 권한과 검증의 경계를 어디에 긋느냐다.
이 글은 ‘AI 에이전트·업무 자동화’ 분야 전체의 지도다. 개별 도구나 프레임워크를 소개하는 대신, 어떤 에이전트를 만들든 반드시 통과해야 하는 네 개의 축 — 목표·도구·권한·검증 — 을 어떤 순서로 설계해야 하는지 큰 그림을 그린다.
에이전트는 ‘모델’이 아니라 ‘시스템’이다
가장 흔한 오해는 에이전트를 챗봇의 똑똑한 버전으로 보는 것이다. 챗봇은 말만 한다. 에이전트는 행동한다 — 파일을 쓰고, API를 호출하고, 코드를 실행하고, 외부에 요청을 보낸다. 이 한 줄 차이가 모든 것을 바꾼다. 말은 틀려도 되돌릴 수 있지만, 행동은 되돌릴 수 없는 것들이 섞여 있다.
그래서 에이전트는 모델 하나로 정의되지 않는다. 목표를 잘게 쪼개는 작업 흐름, 실제로 세상에 손대는 도구, 그 도구를 어디까지 쓸 수 있는지 정하는 권한, 그리고 결과가 맞는지 판단하는 검증. 이 네 개가 맞물려 돌아가는 시스템이다. 모델은 그중 한 부품일 뿐이다.
| 축 | 핵심 질문 | 여기서 갈리는 것 |
|---|---|---|
| 목표 | 무엇을, 어디까지 맡기나? | 자동화 범위 · 실패 조건 |
| 도구 | 세상에 어떻게 손대나? | 파일·API·DB·터미널 연결 |
| 권한 | 그 도구를 어디까지 쓰나? | 사고 반경 · 되돌릴 수 없는 행동 |
| 검증 | 결과가 맞는지 누가 보나? | 사람 개입 지점 · 감사 로그 |
먼저 ‘금지 목록’부터 쓴다
자동화를 설계할 때 대부분 “무엇을 맡길까”부터 생각한다. 순서가 틀렸다. 먼저 써야 할 건 “무엇을 절대 맡기지 않을까”다. 환불 승인, 프로덕션 배포, 외부 고객 커뮤니케이션, 데이터 삭제 — 이런 건 에이전트가 아무리 유능해져도 사람의 손을 떠나지 않는 영역으로 먼저 못 박아 둔다.
금지 목록을 먼저 정하면 나머지 설계가 쉬워진다. 남은 작업만 잘게 쪼개고, 각 단계의 입력·출력·실패 조건을 정의하면 된다. 실패 조건이 없는 단계는 에이전트가 “성공했다고 착각한 채” 다음으로 넘어가는 지점이 된다. 자동화에서 가장 위험한 건 실패가 아니라 조용한 실패다.
⚠️ 가장 흔한 함정
“모델이 점점 똑똑해지니 권한도 넓혀도 되겠지”가 사고의 씨앗이다. 실제론 반대다. 모델이 유능해질수록 위임 범위가 넓어지고, 넓어진 만큼 잘못된 한 번의 사고 반경도 커진다. 권한은 모델 성능에 비례해 넓히는 게 아니라, 되돌릴 수 없는 행동을 기준으로 좁혀야 한다.
권한은 ‘최소’가 기본값이다
도구를 붙이는 건 쉽다. 파일 접근, API 키, DB 커넥션, 터미널 — 몇 줄이면 연결된다. 그래서 다들 “일단 다 열어두고 나중에 조인다”고 한다. 그 ‘나중’은 오지 않는다. 권한은 처음부터 최소로 시작해 필요할 때 하나씩 여는 방향이어야 한다. 반대 방향은 사고가 난 뒤에야 조여진다.
실무에서 이 원칙은 세 가지로 구체화된다. 첫째, 읽기와 쓰기를 분리한다 — 조회만 필요한 에이전트에 쓰기 권한을 주지 않는다. 둘째, 개발과 운영 환경을 분리한다 — 에이전트가 프로덕션에 직접 손대지 못하게 막는다. 셋째, 모든 도구 호출을 기록한다 — 누가 봐도 “이 에이전트가 언제 무엇을 했나”를 재현할 수 있어야 한다.
검증: ‘무엇을 했는지’를 재현할 수 있어야 한다
에이전트가 결과를 내놨을 때 던져야 할 질문은 “맞았나?”가 아니라 “어떻게 그 결과에 도달했나?”다. 관측성(observability)이란 이 과정을 사후에 되짚을 수 있는 상태를 말한다. 지연시간, 실패율, 비용, 승인 대기 상태 — 이 네 가지를 실시간으로 볼 수 없다면 그 에이전트는 통제 밖이다.
그리고 사람 검토(human-in-the-loop) 지점을 명확히 둔다. 모든 결과를 사람이 볼 수는 없다. 대신 앞서 정한 ‘금지 목록’에 닿는 행동, 되돌릴 수 없는 행동, 비용이 큰 행동에만 승인 게이트를 건다. 자동화의 성숙도는 얼마나 많이 자동화했느냐가 아니라, 어디서 멈춰 사람을 부르느냐로 판가름 난다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
에이전트 설계는 모델 고르기가 아니라 권한 긋기부터 시작한다. 순서는 늘 같다 — 금지 목록 작성 → 최소 권한으로 도구 연결 → 실패 조건 정의 → 승인 게이트 배치. 모델 선택은 이 네 단계를 다 짠 다음에 붙이는 마지막 부품이다.
“얼마나 많이 자동화할 수 있나”를 자랑거리로 삼지 마라. 잘 만든 자동화일수록 사람이 멈추는 지점이 선명하다. 조용히 다 해치우는 에이전트가 아니라, 위험한 길목마다 손을 드는 에이전트가 오래 간다.
도입 체크리스트
- 금지 목록 먼저 — 되돌릴 수 없는 작업(삭제·배포·결제·외부 발송)을 자동화에서 제외
- 도구별 최소 권한 — 읽기/쓰기 분리, 개발/운영 환경 분리
- 실패·재시도·중단 기준 — 각 단계에 실패 조건을 명시해 ‘조용한 실패’ 차단
- 도구 호출 전량 기록 — 언제 무엇을 했는지 사후 재현 가능하게
- 승인 게이트 배치 — 위험·고비용 행동에만 사람 검토를 건다
- 관측 지표 4종 — 지연시간·실패율·비용·승인 대기를 실시간으로
설계 순서
🧱 이 순서로 설계한다
- 금지 목록을 먼저 쓴다 — 삭제·배포·결제·외부 발송처럼 되돌릴 수 없는 작업은 자동화에서 제외한다.
- 남은 작업만 최소 권한으로 도구를 연결한다 — 읽기와 쓰기를 나누고, 개발과 운영 환경을 분리한다.
- 각 단계에 실패 조건을 명시해 ‘조용한 실패’를 막고, 모든 도구 호출을 사후 재현 가능하게 기록한다.
- 위험·고비용 행동에만 사람 승인 게이트를 걸고, 지연시간·실패율·비용·승인 대기 네 지표를 실시간으로 본다.
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
