2026년 AI 업계에서 가장 큰 변화는 더 똑똑한 챗봇이 아니라 일을 위임받아 도구를 사용하고 결과를 완성하는 에이전트의 확산입니다. 질문에 답하는 AI와 달리 에이전트는 파일을 읽고, 시스템을 오가고, 작업 순서를 결정하고, 때로는 실제 변경까지 수행합니다.
기회는 분명합니다. OpenAI가 2026년 7월 공개한 NTT DATA 사례에 따르면 복잡한 장애 분석 작업이 기존 5명의 엔지니어가 3일 동안 수행하던 방식에서 Codex를 활용해 30분으로 단축됐습니다. 다만 이는 공급사가 공개한 특정 기업 사례이며 모든 조직에서 같은 결과를 보장하지 않습니다. 더 중요한 대목은 NTT DATA가 도구만 배포하지 않고 CoE, 보안 지침, 교육, 사용 모니터링과 사람 검토 기준을 함께 만들었다는 점입니다.
결론부터 말하면 AI 에이전트는 디지털 직원이 아닙니다. 권한을 가진 확률적 소프트웨어 운영자에 더 가깝습니다. 성과를 내려면 좋은 프롬프트보다 먼저 운영 체계를 설계해야 합니다.
왜 지금 에이전트 운영 설계가 중요한가
OpenAI의 2026년 업무 사용 연구는 AI 활용의 단위가 짧은 대화에서 장시간 위임 작업으로 이동하고 있다고 설명합니다. Anthropic의 실제 사용 분석에서도 가장 긴 Claude Code 세션의 자율 작업 시간이 3개월 사이 25분 미만에서 45분 이상으로 늘었습니다. 에이전트가 오래 일할수록 생산성의 상한은 높아지지만, 잘못된 가정이 여러 단계에 걸쳐 증폭될 가능성도 커집니다.
NIST가 2026년 발표한 AI 에이전트 보안 의견 분석에서도 기존 사이버보안 원칙은 여전히 유효하지만 에이전트의 새로운 위협에 맞게 조정해야 한다는 공감대가 확인됐습니다. 이제 핵심 질문은 “어떤 모델이 가장 똑똑한가”가 아니라 “어떤 일을, 어떤 권한으로, 어떤 검증 아래 맡길 것인가”입니다.
1. 범용 비서가 아니라 하나의 명확한 직무부터 시작한다
첫 도입 과제로 “우리 회사의 모든 업무를 돕는 에이전트”를 선택하면 성공 여부를 측정할 수 없습니다. 입력, 완료 조건, 예외 상황과 담당자가 분명한 하나의 직무를 고르세요.
- 좋은 시작: 매일 들어오는 지원 티켓을 분류하고 답변 초안을 만든다.
- 나쁜 시작: 고객 지원을 모두 자동화한다.
- 좋은 시작: 장애 로그와 변경 이력을 모아 원인 후보 보고서를 만든다.
- 나쁜 시작: IT 운영을 알아서 처리한다.
OpenAI Presence도 프로덕션 도입의 출발점을 청구 문제, 보험 청구, 사내 IT 요청처럼 구체적인 직무로 설명합니다. 범위를 좁히는 것은 에이전트의 능력을 제한하는 일이 아니라, 성과를 반복 가능하게 만드는 일입니다.
2. 성공 조건과 실패 조건을 함께 작성한다
에이전트에게 목표만 주면 가장 그럴듯한 완료 상태를 스스로 해석합니다. 운영 명세에는 최소한 다음 네 가지가 있어야 합니다.
- 어떤 입력을 받을 수 있는가
- 어떤 산출물을 만들어야 하는가
- 무엇을 절대 변경하면 안 되는가
- 어떤 상황에서 중단하고 사람에게 넘겨야 하는가
예를 들어 송장 검토 에이전트의 성공은 “검토 완료”가 아니라 필수 필드 추출률, 정책 위반 탐지율, 근거 링크 포함률과 오탐 허용치로 정의할 수 있습니다. 반대로 금액 불일치, 신규 공급자, 개인정보 노출 또는 불확실한 정책 해석은 명시적인 중단 조건이 되어야 합니다.
3. 최소 권한을 기본값으로 둔다
에이전트는 연결된 도구가 많을수록 유능해 보이지만 위험 면적도 함께 커집니다. NIST의 AI Agent Standards Initiative가 에이전트의 신원과 권한 부여를 별도 연구 영역으로 다루는 이유입니다.
- 읽기 권한과 쓰기 권한을 분리합니다.
- 전체 데이터 대신 업무에 필요한 폴더, 테이블과 계정만 허용합니다.
- 개인 계정을 공유하지 않고 에이전트별 서비스 신원을 사용합니다.
- 장기 토큰보다 짧은 수명과 좁은 범위의 자격 증명을 우선합니다.
- 외부 콘텐츠는 신뢰할 수 없는 입력으로 취급합니다.
처음에는 “읽고 분석하고 초안을 만드는” 수준으로 시작하고, 충분한 평가 데이터가 쌓인 뒤 제한된 쓰기 권한을 추가하는 편이 안전합니다.
4. 되돌릴 수 있는 행동과 되돌리기 어려운 행동을 나눈다
모든 도구 호출을 같은 위험도로 취급하면 승인 피로가 생기거나, 반대로 중요한 변경이 자동 통과합니다. 행동을 영향도에 따라 구분하세요.
- 낮은 위험: 검색, 읽기, 요약, 임시 파일 생성
- 중간 위험: 초안 저장, 내부 티켓 생성, 테스트 환경 변경
- 높은 위험: 고객 메시지 발송, 결제, 계약 변경, 운영 배포, 데이터 삭제
낮은 위험 작업은 로그를 남기며 자동 실행할 수 있습니다. 중간 위험은 사후 검토나 표본 검사를 붙이고, 높은 위험은 실행 직전 사람이 내용과 영향을 확인해야 합니다. 사람 승인은 단순한 확인 버튼이 아니라 무엇이 바뀌는지 비교할 수 있는 승인 화면이어야 합니다.
5. 출시 전에 시뮬레이션과 회귀 평가를 만든다
데모가 한 번 성공했다고 운영 준비가 끝난 것은 아닙니다. OpenAI Presence는 일반 요청, 엣지 케이스와 고위험 상황을 시뮬레이션하고 결과, 정책 준수, 도구 사용과 에스컬레이션을 평가하는 방식을 제시합니다.
실전 평가 세트에는 다음이 포함되어야 합니다.
- 정상적으로 완료해야 하는 대표 업무
- 정보가 부족해 질문해야 하는 업무
- 정책 때문에 거절하거나 중단해야 하는 업무
- 악의적인 지시나 프롬프트 인젝션이 섞인 입력
- 외부 시스템 장애, 시간 초과와 중복 실행
- 이전 버전에서는 성공했지만 변경 후 깨질 수 있는 회귀 사례
정확도 하나만 보지 말고 완료율, 근거 정확성, 잘못된 도구 호출, 불필요한 권한 요청, 사람 개입률과 복구 시간을 함께 측정하세요.
6. 결과가 아니라 과정까지 관찰한다
에이전트가 좋은 보고서를 냈더라도 잘못된 데이터에 접근했거나 우연히 맞았을 수 있습니다. 운영 로그에는 입력과 최종 출력뿐 아니라 사용한 도구, 접근한 데이터 범위, 중요한 판단, 승인과 중단 이유를 남겨야 합니다.
다만 모든 내부 추론을 무조건 저장하는 방식은 개인정보와 보안 위험을 키울 수 있습니다. 재현과 감사에 필요한 행동 중심 기록을 설계하고, 민감 정보 마스킹, 보존 기간과 접근 권한을 함께 정하세요.
출시 이후에는 실패 세션, 사람의 수정, 에스컬레이션과 사용자 피드백을 새 평가 항목으로 되돌려야 합니다. 에이전트 운영은 한 번의 구축이 아니라 관찰과 개선의 반복입니다.
7. 사람에게 넘기는 기준과 최종 책임자를 정한다
“필요하면 사람에게 물어봐”는 운영 규칙이 아닙니다. 어떤 조건에서 누구에게, 어떤 맥락과 함께 넘길지 구체화해야 합니다.
- 금액이나 법적 효력이 기준을 넘는 경우
- 정책 문서끼리 충돌하는 경우
- 개인정보 또는 보안 사고 가능성이 있는 경우
- 신뢰도 기준 아래이거나 근거 출처를 확보하지 못한 경우
- 동일 작업이 반복 실패하거나 외부 시스템 상태가 불안정한 경우
에스컬레이션에는 원래 요청, 이미 수행한 단계, 사용한 근거, 변경 예정 항목과 추천 선택지가 포함되어야 합니다. 그리고 에이전트의 업무 품질, 권한과 사고 대응을 책임지는 사람이 반드시 지정되어야 합니다.
30일 도입 로드맵
1주차: 업무를 한 문장으로 정의한다
빈도는 높고 실패 영향은 낮으며 현재 소요 시간을 측정할 수 있는 업무 하나를 선택합니다. 과거 사례 30~50개를 모으고 완료 조건과 중단 조건을 문서화합니다.
2주차: 읽기 전용 파일럿을 만든다
에이전트가 실제 변경 대신 분석과 초안만 만들게 합니다. 모든 실행을 검토하고 실패 유형을 분류합니다. 이 단계에서 프롬프트보다 데이터 접근 범위와 도구 인터페이스를 먼저 다듬습니다.
3주차: 평가와 승인 단계를 자동화한다
대표·예외·공격 입력을 회귀 평가에 넣습니다. 위험도별 승인 규칙을 적용하고 중복 실행 방지, 시간 초과와 복구 절차를 시험합니다.
4주차: 제한된 사용자에게 배포한다
소수 팀에 배포해 업무 시간, 수정률, 에스컬레이션, 사고와 만족도를 함께 측정합니다. 성과가 확인된 작업만 범위를 넓히고, 새로운 권한은 한 번에 하나씩 추가합니다.
모델 순위보다 운영 체계가 오래간다
모델과 제품의 순위는 몇 달 안에도 바뀝니다. 하지만 명확한 직무, 최소 권한, 평가 세트, 승인 경계, 행동 로그와 책임자는 어떤 에이전트를 선택해도 남습니다.
최고의 에이전트 프로젝트는 사람을 완전히 없애는 프로젝트가 아닙니다. 반복적 탐색과 실행은 에이전트가 맡고, 목표 설정·예외 판단·책임은 사람이 맡는 구조를 만드는 프로젝트입니다. 먼저 작은 직무 하나에서 이 구조를 증명한 뒤 다음 직무로 확장하세요.
참고한 공식 자료
- OpenAI Presence: 프로덕션 에이전트의 평가·가드레일·에스컬레이션
- OpenAI: 에이전트가 업무를 바꾸는 방식
- NTT DATA Group의 Codex 도입 사례
- Anthropic: 실제 환경의 에이전트 자율성 측정
- Anthropic: 신뢰할 수 있는 에이전트의 운영 원칙
- NIST: AI 에이전트 보안 의견 분석
- NIST AI Agent Standards Initiative
사례의 성과 수치는 각 기관과 공급사가 공개한 자료에 기반하며 조직의 데이터, 업무와 통제 수준에 따라 달라질 수 있습니다. 실제 도입 전 최신 제품 정책, 보안 요구와 관련 법규를 확인하세요.