회사에 AI 에이전트가 100개라면 권한, 비용, 실수는 누가 통제할까?

핵심 요약

자동화 시스템은 아무도 세지 않는 사이에 회사 곳곳에서 조금씩 생겨납니다. 그러다 어느 날 지금 무엇이 돌아가고 있는지 아무도 답하지 못하게 됩니다.
다음 자동화를 더하기 전에 관리 대장부터 있어야 합니다. 무엇이 있는지, 누가 관리하는지, 어떤 데이터를 쓰는지, 돈이 얼마나 드는지 적어 둔 목록입니다.
자동화마다 정지 버튼이 있어야 하고, 시스템을 쓸 수 없을 때 대신 일하는 방법도 마련해 두어야 합니다.

1. 에이전트 스프롤(Agent Sprawl): 사람 대신 직접 움직이는 새로운 섀도 IT

이런 일은 예전에도 있었습니다. 부서마다 몰래 소프트웨어에 가입해 쓰다가, 회사가 데이터가 어디에 있는지조차 모르게 되었던 때입니다. 이번에는 더 빨리 벌어질 것입니다. 자동화 하나를 만드는 데 한 시간도 걸리지 않기 때문입니다.

기존 SaaS 도구는 데이터를 저장하는 정도였지만, 에이전트는 API를 호출하고, 메시지를 보내고, 레코드를 바꾸고, 쉬지 않고 일을 이어 갈 수 있습니다. 관리 대장이 없으면 회사는 누가 만들었는지, 어떤 데이터를 쓰는지, 아직 필요한지 알 수 없습니다. 담당 스폰서(Sponsor)가 퇴사한 뒤에도 에이전트가 인증 정보와 실행 일정을 그대로 둔 채 계속 돌아갈 수 있습니다.

에이전트가 다른 에이전트를 호출하면 위험은 더 커집니다. 한 곳의 실수가 워크플로를 타고 번질 수 있습니다. 데이터를 잘못 요약하면 그 때문에 가격이 틀리고 고객에게 가는 메시지도 틀리는 식입니다. 그래서 통제는 연결된 흐름(Chain) 전체를 처음부터 끝까지 보아야 합니다. 최종 결과만 검사해서는 이런 오류를 잡지 못합니다.

첫 번째 에이전트부터 지킬 규칙 ID, 스폰서, 목적, 데이터·도구 범위, 위험 등급, 예산, 검토일이 정해지지 않은 에이전트는 운영 환경에 올리지 않습니다.

2. 에이전트 관리 대장과 수명 주기 만들기

지금 바로 답할 수 있는지 스스로 물어보십시오. 회사에 자동화 시스템이 몇 개 있고, 각각 누가 주인이며, 어느 것이 아직 쓰이고 있습니까? 답하지 못한다면 그 답을 찾는 일이 첫 번째 과제입니다.

개발팀 참고 · 기술 지표

Catalog는 검색할 수 있어야 하고 Identity와 연결되어야 합니다. Owner, Sponsor, Version, Model, Knowledge, Tools, Environment, KPI, Cost, Dependencies를 기록합니다. 상태값은 Draft, Testing, Approved, Suspended, Retired로 두고, 승인 근거도 함께 남깁니다.

개발팀 참고 · 기술 세부 사항

팀이 Use Case를 제안하는 Intake Process를 만들고, 새 에이전트를 허용하기 전에 기존 에이전트부터 확인합니다. 공용 Template과 Connector를 써서 중복을 줄입니다. Expiry를 정해 두고, 사용 실적이 없거나 Sponsor가 확인해 주지 않으면 시스템이 자동으로 권한을 줄이거나 에이전트를 끕니다.

수명 주기	통제 항목	근거
생성(Create)	목적, 스폰서, 위험도	관리 대장 등록과 설계
테스트(Test)	평가, 레드팀	테스트 보고서
운영(Run)	고유 계정, 로그, 예산	대시보드
변경(Change)	버전 관리 + 재평가	릴리스 기록
폐기(Retire)	권한 회수, 데이터 반출, 삭제	종료 증빙

3. 에이전트에게도 직원처럼 고유 계정이 필요하고, 가드레일은 더 촘촘해야 합니다

개발팀 참고 · 기술 세부 사항

공용 계정은 쓰지 마십시오. 에이전트마다 전용 Identity를 만들어 어떤 Action이 어느 에이전트에서 나왔는지 추적할 수 있게 합니다. 책임지는 Sponsor를 지정하고, 권한은 Least Privilege 원칙에 따라 줍니다. 사용자를 대신해 행동하는(Acting-on-behalf-of) 에이전트와, Session에 사람이 없는 상태로 움직이는 Autonomous Agent를 구분합니다.

개발팀 참고 · 기술 세부 사항

Time-bound Access, Approval, Conditional Policy를 씁니다. 에이전트는 Task에 필요한 만큼만 데이터를 읽고, 연동하기 쉽다는 이유만으로 Admin 권한을 받아서는 안 됩니다. Secret은 Vault에 두고 교체할 수 있어야 합니다. Sponsor가 다른 업무로 옮기면 소유권을 넘기거나 에이전트를 자동으로 정지해야 합니다.

스폰서는 서류에 이름만 올리는 자리가 아닙니다 스폰서는 비용, 위험, 접근 권한 검토(Access Review) 결과와 사고를 보고받아야 합니다. 에이전트를 끌 권한도 있어야 하고, 수명 주기 내내 에이전트의 목적이 여전히 맞는지 검토할 책임을 집니다.

4. 통제가 지나치거나 모자라지 않도록 위험 등급(Risk Tier) 나누기

1등급 보조(Assist): 기밀이 아닌 데이터를 읽고 초안을 만듭니다. 사람이 매번 검토합니다.
2등급 내부 실행(Internal Action): 되돌릴 수 있는 범위에서 내부 시스템에 기록합니다. 표본 검사와 로그를 둡니다.
3등급 외부·중대 영향(External/Material): 사람에게 연락하거나, 중요한 데이터를 바꾸거나, 재무에 영향을 줍니다. 승인 절차와 SLA가 있어야 합니다.
4등급 고영향(High Impact): 채용, 신용, 건강, 법률, 안전에 관한 일입니다. 정식 영향 평가와 전문가의 전면적인 참여가 필요합니다.

개발팀 참고 · 기술 세부 사항

Risk Tier에 따라 Evaluation, Monitoring, Approval, Access Review 주기가 정해집니다. 회의 요약 업무가 대출 승인만큼 많은 절차를 거칠 필요는 없습니다. 그래도 어느 Tier든 Owner와 허용된 데이터 범위는 있어야 합니다.

5. 에이전트가 무엇을 판단하고 무엇을 했는지 보여 주는 관측 기능(Observability)

개발팀 참고 · 기술 세부 사항

Log는 Request, Plan, Tool Call, Data Source, Policy Decision, Human Approval, Outcome을 서로 연결합니다. Trace ID로 여러 에이전트에 걸친 작업을 따라갑니다. 기밀 데이터는 필요 이상으로 보관하지 말고, Retention 기간은 위험도에 맞춰 정합니다.

개발팀 참고 · 기술 세부 사항

Dashboard에는 Success, Exception, Latency, Cost, Policy Violation, Outcome을 보여 줍니다. 에이전트가 이상한 Pattern을 보이거나, Tool을 비정상적으로 많이 쓰거나, 품질이 Drift하면 Alert를 띄웁니다. Release마다 표본을 Replay하고 Golden Cases를 테스트합니다.

중요한 작업에는 설명 가능한 실행 기록(Explainable Receipt)을 남기십시오. 무엇을, 언제, 누구의 이름으로 했는지, 어떤 데이터와 정책을 썼는지, 어떻게 되돌리는지 적은 기록입니다. 고객 지원과 감사에 쓸 수 있고, 사용자의 신뢰도 높여 줍니다.

6. 에이전트를 위한 FinOps로 비용 관리하기

개발팀 참고 · 기술 세부 사항

여러 단계로 일하는 에이전트는 모델과 도구를 반복해서 호출할 수 있습니다. Task, Agent, Team, 월 단위로 Budget을 걸어 두십시오. Classification/Extraction에는 작은 모델을 쓰고, 비싼 모델은 꼭 필요한 Reasoning에만 씁니다. 데이터를 Cache하고 Loop 횟수를 제한합니다.

Cost/Outcome 프롬프트당 비용 대신 성과당 비용

Budget Guard 한도를 넘기 전에 정지

Value Owner 예산은 현업 팀이 책임

차지백(Chargeback)이나 쇼백(Showback) 방식으로 팀마다 자기 비용을 직접 보게 하십시오. 성과가 없거나 사용량이 적은 에이전트는 합치거나 꺼야 합니다. 비용을 줄이더라도 품질과 안전이 가드레일 아래로 떨어져서는 안 됩니다.

7. 사고와 업무 연속성 대비하기

개발팀 참고 · 기술 세부 사항

Playbook을 정하십시오: Detect, Contain, Revoke, Rollback, Notify, Learn. 에이전트와 도구마다 Kill Switch를 두고, 전사 차원의 Global Emergency Mode도 마련합니다. 에이전트가 잘못된 데이터를 대량으로 보내거나 Credential이 유출되는 상황을 가정해 Tabletop 훈련을 합니다.

개발팀 참고 · 기술 세부 사항

중요한 워크플로에는 Manual Fallback과 최소 처리 Capacity를 유지합니다. Configuration, Prompt, Policy, Data Lineage를 백업합니다. Vendor Outage가 나더라도 회사가 업무 상태를 모르는 일은 없어야 합니다. RTO/RPO는 영향도에 맞춰 정합니다.

8. 에이전트가 수백 개로 늘어날 때의 운영 모델

개발팀 참고 · 기술 세부 사항

Federated Model을 씁니다: Central Platform/Security 팀은 Identity, Policy, Observability, Catalog를 맡고, Domain Team은 Workflow, Knowledge, Outcome을 책임집니다. 표준과 고위험 사안을 다루는 AI/Agent Council을 두되, 일상적인 Task를 하나하나 승인하게 하지는 않습니다.

개발팀 참고 · 기술 지표

Portfolio를 분기마다 검토해 Scale, Improve, Merge, Retire 가운데 하나로 결정합니다. 관리 대장의 Coverage, Access Review, Incident를 Business Value와 함께 측정합니다. 중요한 에이전트는 만든 사람과 독립된 Red/Quality 팀이 테스트하게 합니다.

요약: 에이전트 100개는 고유 계정, 스폰서, 수명 주기, 위험 등급, 비용 관리, 사고 통제를 갖춘 하나의 인력(Workforce)으로 관리해야 합니다. 중앙 통제 체계(컨트롤 플레인)는 숫자가 적을 때 시작하십시오. 에이전트가 무질서하게 퍼진 뒤에 인증 정보와 책임자를 거꾸로 바로잡으려면 비용이 많이 듭니다. 거버넌스를 잘 갖춰도 개발은 느려지지 않습니다. 팀은 감사할 수 있는 궤도 위에서 계속 빠르게 만들 수 있습니다.

참고 자료Microsoft Learn: Governing Agent Identities

DNA MAKER · SOLUTION BLUEPRINT

에이전트 수가 통제 범위를 넘기 전에 관리 대장과 통제 체계를 갖춥니다

조직이 어느 수준의 위험까지 감수할 수 있는지, 어떤 데이터가 시스템 밖으로 나가면 안 되는지는 회사의 IT 팀과 보안 팀이 압니다. 어떤 업무가 잘못되면 피해가 큰지는 각 부서의 팀장이 압니다. DNA Maker는 이 두 관점을 모아, 정책 문서에 적힌 내용을 시스템이 실제로 강제하는 규칙으로 옮깁니다. 에이전트마다 누가 주인인지, 어떤 데이터를 쓰는지, 어떤 권한이 있는지, 비용이 얼마인지, 어느 위험 등급에 속하는지 기록하는 관리 대장을 함께 만들고, 승인 요청부터 폐기까지의 수명 주기도 정합니다.

다음 에이전트를 더하기 전에 갖춰야 할 것

그다음에 만드는 시스템은 컨트롤 플레인입니다. 관리 대장, 권한, 에이전트별 예산 설정, 로그 수집을 한데 모으고, 지금 무엇이 돌아가는지, 누가 주인인지, 돈을 얼마나 썼는지 바로 보여 주는 화면을 갖춘 시스템입니다. 비용이나 오류율이 기준을 넘으면 알림이 가도록 하고, 멈출 수 없는 업무를 위해 킬 스위치와 대체 계획도 마련합니다. 잘 통하는 시작 방법은 아직 빠진 것이 있더라도 오늘 이미 돌아가고 있는 것부터 대장에 올리는 것입니다. 회사에 에이전트나 자동화가 지금 몇 개 있고 누가 관리하는지 답할 수 없다면, 이제 시작할 때라는 신호입니다.

SOFTWARE ENGINEERING GLOSSARY

소프트웨어 엔지니어링 용어집

자동화 시스템이 많아져도 안전하게 관리하는 데 필요한 용어입니다.

용어	의미	쉬운 예시	개발팀에 물어봐야 할 질문
Service Account	시스템이나 에이전트가 일할 때 쓰는, 직원 계정과 분리된 계정	에이전트가 직원 계정을 빌리지 않고 자기 계정으로 시스템에 접속합니다.	각 시스템은 누구의 계정을 쓰고, 그 권한을 즉시 회수할 수 있습니까?
Observability	시스템이 지금 무엇을 하고 있고 왜 그런 결과가 나왔는지 알 수 있는 능력	이 에이전트가 틀린 답을 내기 전에 어떤 데이터를 불러왔는지 되짚어 볼 수 있습니다.	문제가 생기면 원인을 찾기까지 얼마나 걸립니까?
FinOps	시스템 비용을 부서별, 업무별로 보이게 하고 통제하는 관리 방식	에이전트마다 월 예산을 정하고 한도에 가까워지면 알림을 보냅니다.	작업 1회당 비용은 얼마이고, 누가 책임집니까?
Risk Tier	업무에 필요한 통제 수준을 정하려고 위험도를 등급으로 나누는 것	고객에게 나가는 업무는 내부 요약 업무보다 높은 등급을 받습니다.	어떤 기준으로 등급을 매기고, 최고 등급은 누가 승인합니까?
Decommission	더 이상 쓰지 않는 시스템을 데이터 보관과 권한 회수까지 포함해 절차대로 폐기하는 일	아무도 쓰지 않는 에이전트를 끄고, 로그는 정책에 따라 보관합니다.	폐기는 누가 결정하고, 남은 데이터는 어떻게 처리합니까?