챗봇에 버튼 하나 붙였다고 에이전트가 되지는 않습니다. 에이전트는 목표를 받고 여러 단계에서 도구를 고르며, 결과를 관찰하고 다음 행동을 결정합니다. 이 자율성이 가치를 만들지만, 잘못된 메일 발송이나 데이터 변경처럼 현실의 피해도 키웁니다.
첫 에이전트는 가장 똑똑한 모델보다 가장 좁은 권한에서 시작해야 합니다. 읽기 전용으로 제안만 만들고, 사람이 승인한 뒤 한 번의 가역적 행동을 실행하게 해 보세요.
에이전트, 챗봇, 워크플로를 구분한다
챗봇은 대화를 통해 답을 줍니다. 고정 워크플로는 사람이 정한 단계와 조건을 따릅니다. 에이전트는 모델이 현재 상태를 보고 다음 단계와 도구를 선택합니다. OpenAI의 공식 가이드는 단순한 단일 턴 모델이나 감성 분류처럼 모델이 실행 흐름을 통제하지 않는 앱은 에이전트로 보지 않습니다.
불확실성이 정말 필요한 업무인가
규칙이 명확한 계산, 필드 복사, 상태 전환은 일반 코드가 더 싸고 예측 가능합니다. 예외가 많고 비정형 문서를 읽어 판단해야 하며 기존 규칙이 지나치게 복잡한 흐름에서 에이전트의 장점이 커집니다. 이름을 멋지게 붙이기 위해 에이전트를 선택하지 마세요.
첫 업무는 실패 반경이 작은 곳에서 고른다
좋은 후보는 읽기 위주이며 결과를 사람이 빨리 확인할 수 있습니다. 예를 들어 여러 문서에서 검토 항목을 모으거나, 지원 티켓의 답변과 다음 행동을 제안하는 일입니다. 결제 승인, 계약 체결, 계정 삭제처럼 돈·권리·데이터를 직접 바꾸는 일은 첫 실험에 맞지 않습니다.
“업무를 자동화했다”만으로는 성공을 판단하기 어렵습니다. 완료율, 사람의 수정량, 잘못된 도구 선택, 중단·승인 횟수, 한 건당 비용으로 나눠 기록하세요.
권한은 읽기와 쓰기를 분리한다
도구마다 읽기, 생성, 수정, 삭제 권한을 따로 줍니다. 캘린더를 읽는 권한과 초대를 보내는 권한은 다릅니다. 에이전트가 필요할지 모른다는 이유로 관리자 토큰을 건네지 마세요. 작업별 단기 자격 증명과 최소 범위가 좋습니다.
도구 설명도 보안 경계입니다. 입력 스키마, 허용 대상, 최대 금액, 호출 전 조건을 코드로 제한하세요. 프롬프트의 “절대 하지 마”만으로는 부족합니다.
승인은 위험한 행동 바로 앞에 둔다
매 단계마다 승인시키면 사람은 알림을 무시하게 됩니다. 반대로 마지막 결과만 보여주면 중간에 어떤 데이터를 읽고 바꿨는지 알기 어렵습니다. 외부 발송, 결제, 삭제, 권한 변경, 공개 게시처럼 돌이키기 어렵거나 제3자에게 영향을 주는 행동 앞에 승인을 둡니다.
승인 화면에는 행동 이름만이 아니라 대상, 변경 전후, 근거, 예상 영향이 보여야 합니다. 사람이 실제로 판단할 정보가 없는 확인 버튼은 통제가 아닙니다.
되돌리기와 중단은 기능의 일부다
초안을 만드는 에이전트는 결과를 버리면 되지만, CRM을 수정하는 에이전트는 이전 값을 저장해야 합니다. 가능한 작업은 먼저 초안이나 트랜잭션으로 만들고, 삭제보다 보관, 덮어쓰기보다 새 버전을 택하세요. 최대 반복 횟수, 최대 비용, 시간 제한, 같은 도구의 연속 호출 제한도 둡니다.
Anthropic의 신뢰 가능한 에이전트 연구는 자율성이 커질수록 사람의 통제와 보안 위험도 함께 커진다고 설명합니다. 특히 외부 문서나 웹페이지의 숨은 지시가 에이전트를 속이는 프롬프트 인젝션을 실제 위협으로 봐야 합니다.
경로 전체를 평가한다
최종 답만 채점하면 잘못된 도구를 여러 번 호출하고 우연히 맞힌 경우를 놓칩니다. 어떤 정보를 읽었는지, 어느 도구를 어떤 인자로 썼는지, 중간 오류에서 멈췄는지, 승인 없이 쓴 적은 없는지를 단계별로 기록하세요.
정상 사례와 함께 모호한 목표, 권한 없는 대상, 도구 오류, 느린 응답, 악성 문서, 반복 루프를 시험해야 합니다. 실험 환경과 운영 환경의 권한 차이도 테스트에 포함합니다.
AI 에이전트 도입 체크리스트
- 고정 코드보다 에이전트가 나은 이유를 설명할 수 있는가?
- 첫 업무가 읽기 위주이고 실패해도 복구 가능한가?
- 도구별 읽기·쓰기·삭제 권한을 최소화했는가?
- 외부 발송·결제·삭제·공개 전에 사람이 승인하는가?
- 변경 전 상태와 도구 호출을 감사할 수 있는가?
- 시간·비용·반복 상한과 즉시 중단 장치가 있는가?
- 정상 결과뿐 아니라 경로와 실패 복구를 평가하는가?
한계와 주의점
가드레일 하나로 에이전트를 안전하게 만들 수는 없습니다. 인증과 권한, 입력 검증, 격리, 모니터링, 사람의 승인, 사후 감사를 겹쳐야 합니다. 공식 가이드도 점진적인 설계를 권합니다. 처음부터 여러 에이전트를 묶으면 오류 위치와 비용을 찾기 어려워집니다.
외부 AI 서비스까지 포함한 비용과 계약은 AI SaaS 선택 체크리스트에서 이어서 점검할 수 있습니다.
자주 묻는 질문
도구를 호출하면 모두 AI 에이전트인가요?
아닙니다. 정해진 순서대로 한 번 호출하는 기능은 워크플로에 가깝습니다. 모델이 상태를 보고 다음 행동을 선택하고 반복한다면 에이전트 성격이 강합니다.
처음부터 멀티 에이전트가 더 좋은가요?
대개 그렇지 않습니다. 한 에이전트와 적은 도구로 기준선을 만든 뒤 복잡성이 실제로 필요할 때 나누는 편이 평가와 유지보수에 유리합니다.
사람의 승인을 두면 완전 자동화가 아닌가요?
맞습니다. 그러나 위험한 행동의 승인까지 없애는 것이 항상 목표일 필요는 없습니다. 안전한 반자동화가 더 큰 업무 가치를 줄 수 있습니다.
프롬프트에 금지 사항을 쓰면 충분한가요?
충분하지 않습니다. 권한과 입력을 코드로 제한하고, 승인·중단·감사 장치를 함께 둬야 합니다.
공식 자료와 확인 날짜
- OpenAI: A practical guide to building AI agents — 정의와 설계, 2026-09-01 확인
- Anthropic: Building effective agents — 단순한 패턴과 워크플로 구분, 2026-09-01 확인
- Anthropic: Trustworthy agents in practice — 사람의 통제와 보안, 2026-09-01 확인