쓰지 않는 에이전트는 ''굶겨서 내보낸다''는 IBM 사례 (김덕중 퍼브 AI연구소장)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

소개된 IBM 사례에서 쓰지 않는 에이전트를 ‘굶겨서 내보낸다’는 것은 토큰 공급을 끊고 자격·계정을 정리해 은퇴시키는 운영 관리다.

📌 핵심 요점

1. IBM은 에이전트를 자격과 수명이 있는 관리 자산으로 다룬다. 디지털 워커에 사번과 이메일 계정을 부여하고, 채용·온보딩부터 자격 검증, 배치·운영, 은퇴까지 관리한다. 미사용 에이전트는 토큰 공급 중단 대상으로 삼으며, 자격증 회수와 서비스 계정 제거, 필수 로그 백업·보고, 관계자 통지를 거쳐 폐기한다. [25:14, 27:53]
2. 개인의 노하우는 재사용 가능한 스킬로 남겨야 한다. 제작자가 퇴사해도 업무가 이어지려면 실행 조건, 입출력, 절차, 권한, 행동 제한, 예외·복구, 평가 기준을 문서화해야 한다. 업무에 따라 RPA나 기존 대시보드가 더 적합할 수 있으므로 구현 방식도 함께 판단한다. [01:09, 03:00, 04:16]
3. 개발 완료 이후의 평가·변경·비용·폐기까지 설계해야 한다. 정상 업무뿐 아니라 경계 조건과 오남용을 시험하고, 안전성·신뢰성·토큰 비용·운영 편의성을 확인한다. 운영 중에는 병목에 따른 분할, 스킬 추가, 중복 기능 통합과 저사용 에이전트의 폐기를 검토한다. [08:32, 09:38, 10:10, 11:26, 14:01]
4. MCP 연결은 위험 등급과 중앙 통제가 필요하다. 자료에서는 내부 문서, 이메일·CRM·채용 시스템, 재무 시스템 등을 서로 다른 위험 등급으로 구분한다. 연결 정책과 중앙 카탈로그를 관리하고, 사고 시 해당 연결을 긴급 차단하는 킬 스위치를 마련해야 한다. [14:46, 15:36, 16:44]
5. 성과와 책임의 단위가 사람·에이전트 공동 작업으로 넓어진다. 사용 횟수나 토큰 소비량보다 작업량·재작업률 감소, 스킬 공유, 오류 탐지·복구를 평가하는 방향이 제시된다. IBM 사례는 여러 기술을 동일한 관리 체계에 넣는 접근이며, 에이전트 거버넌스에는 HR과 IT의 공동 참여가 강조된다. [18:02, 19:00, 27:18, 29:21]

🧩 배경과 문제 정의

• 에이전트를 만든 직원이 퇴사하면 조직의 업무 방식도 이전 상태로 돌아갈 수 있다. 개인의 노하우를 재사용 가능한 스킬과 운영 지침으로 남겨야 업무 연속성을 확보할 수 있다.
• 기업의 에이전트 도입에는 개발뿐 아니라 평가, 보안, 비용, 변경 관리, 폐기까지 포함하는 관리 체계가 필요하다. 에이전트와 사내 시스템의 연결이 늘수록 권한과 사고 대응도 중요해진다.
• 사람과 에이전트가 함께 일하면 성과 평가와 역할 분담도 달라진다. IBM의 디지털 워커 사례는 기존 인사 관리 체계를 에이전트의 자격 검증과 은퇴 절차에 적용하는 접근이다.

🕒 시간순 섹션별 상세정리

1. 개인의 노하우를 조직에 남기는 스킬

• 에이전트 제작자의 퇴사로 업무 체계가 되돌아가는 문제를 줄이려면 스킬을 다른 구성원에게 이식할 수 있어야 한다. 프롬프트가 휘발성 구두 지시라면, 스킬은 지속적으로 따라야 할 업무 매뉴얼에 가깝다. [01:09]
• 기본 에이전트에 스킬과 페르소나를 더하면 특정 업무의 전문성을 갖춘 에이전트로 발전해진다. 업무 수행 능력과 역할을 구체화하는 과정이 필요하다. [02:16]

2. 스킬 카드에 담아야 할 실행 조건과 통제

• 스킬은 이름과 목적, 실행 조건, 입력 형식, 지식 범위, 업무 절차, 외부 도구, 출력, 행동 제한, 예외·복구, 평가 기준의 열 가지 요소를 갖춰야 한다. 실행 방법뿐 아니라 실패했을 때의 처리까지 설계 대상이다. [03:00]
• 고도화된 에이전트일수록 연결할 시스템과 데이터, 읽기·쓰기 권한을 세밀하게 정해야 한다. 스킬 카드는 이러한 실행 범위와 입출력 조건을 구체화하는 출발점이다. [03:45]

3. 스킬로 만들 업무와 별도 에이전트로 분리할 업무

• 업무를 구체화하면 에이전트보다 RPA나 기존 대시보드가 적합할 수 있다. 구현 방식은 에이전트라는 이름보다 실제 업무 요구에 맞춰 선택해야 한다. [04:16]
• 스킬의 판단 기준은 단일 책임, 명확한 입출력, 적용 가능한 절차·정책, 최소한의 도구, 평가 세트, 이력·버전 관리다. 필요한 스킬이 여러 개로 늘어나면 별도 에이전트로 분리하는 판단도 필요하다. [05:02]

4. 워크플로우와 혼합형 에이전트의 구분

• 정해진 절차를 수행하는 결정형 워크플로우와 조건에 따라 분기하는 에이전트형 워크플로우는 구분해야 한다. 자동화 도구로 만든 흐름이 모두 독립적인 에이전트인 것은 아니다. [06:23]
• 사용자 요구에 따른 분기와 승인, 문제 해결 기능이 함께 필요하면 혼합형이 적합하다. 스킬은 카드로, 에이전트는 포트폴리오로 관리하면서 업무 복잡도에 맞는 구조를 선택해야 한다. [07:00]

5. 배포 이후까지 이어지는 에이전트 수명 관리

• 에이전트 수명 관리는 기회 발굴, 가치·위험 평가, 스킬과 서비스 수준 설계, 시제품 제작, 평가, 파일럿·배포를 거친다. 개발 완료 이후에도 운영·학습·개선과 승격·폐기를 관리해야 한다. [08:32]
• 수요가 몰려 처리 시간이 병목이 되면 에이전트를 분할하고, 기능 확장이 필요하면 스킬을 추가할 수 있다. 반대로 연간 사용이 두세 번에 그치는 에이전트는 폐기 절차를 검토해야 한다. [09:38]

6. 정상 응답을 넘어서는 테스트와 배포 심사

• 평가에는 업무 결과뿐 아니라 해킹·프롬프트 조작에 대한 안전성, 사내 자료에 근거한 신뢰성, 토큰 비용, 사용성, 운영 편의성이 포함돼야 한다. 정상적인 질문에 답했다는 사실만으로 통과를 판단하기 어렵다. [10:10]
• 테스트 세트에는 정상 업무와 함께 경계 조건·오남용 사례를 섞어야 한다. 통계 처리 요청과 회사 대표의 의사결정인 것처럼 결과를 꾸미라는 요청은 서로 다른 대응이 필요하다. [11:26]

7. 전담 조직의 변경·비용·폐기 관리

• 개별 오너의 관리와 별개로 전담 조직은 변경과 릴리즈, 사용자 개선 요구를 전사 관점에서 통합해야 한다. 향후 에이전트 비용이 사람의 인건비 수준까지 커질 가능성에 대비해 예산 최적화도 필요하다. [12:54]
• 부서 간 기능이 중복되면 통폐합이나 폐기를 검토해야 한다. 도구·MCP 연결이 지나치게 많아 위험이 큰 에이전트는 안전장치를 보완한 뒤 활용하도록 통제해야 한다. [14:01]

8. MCP의 위험 등급과 중앙 통제

• MCP는 에이전트를 사내 기존 시스템에 연결하지만, 연결이 늘수록 위험도 커진다. 그린·옐로우·오렌지·레드로 등급을 나누고 돈·개인정보·계약 관련 연결은 최소한으로 관리해야 한다. [14:46]
• 내부 업무 문서는 옐로우, 이메일·메신저·CRM·채용 시스템은 오렌지, 재무 시스템은 레드로 구분하는 방식이다. 무제한 허용과 전면 차단 모두 문제가 있어 연결 정책과 중앙 카탈로그, 업데이트 관리가 필요하다. [15:36]

9. 사용량에서 업무 성과로 이동하는 평가 기준

• 성과 평가의 기본 단위는 개인의 작업에서 사람과 에이전트의 공동 작업으로 바뀔 전망이다. 사용 횟수나 토큰 소비량보다 작업량과 재작업률이 얼마나 줄었는지가 중요해진다. [18:02]
• 개인의 노하우 축적에 더해 스킬 제작과 공유가 중요한 기여로 자리 잡을 전망이다. 오류의 신속한 탐지·복구와 재발 방지까지 반영하도록 품질·위험·학습·판단 등의 지표를 재정의해야 한다. [19:00]

10. 직원과 관리자의 역할 재설계

• 직원의 역할은 직접 과업을 수행하는 데서 여러 에이전트와 스킬을 조합해 고부가가치 업무를 수행하는 방향으로 바뀔 전망이다. 시니어의 지식 전수도 유용한 스킬을 만들고 확산하는 역량과 연결된다. [20:21]
• 관리자는 결과물 검토에 더해 에이전트가 포함된 예외 상황에 대응해야 한다. 사람과 에이전트의 협업 구조를 체계적으로 설계하는 역할에 대한 준비가 필요하다. [20:58]

11. 조직 도입의 출발점인 포트폴리오와 아키텍처

• 도입 초기에는 에이전트를 일정 조건에서 독립적으로 일하는 기술로 이해해야 한다. HR이 참여해 개인·조직·전사 수준의 에이전트 포트폴리오와 역할 구성을 설계하는 것이 다음 단계다. [22:06]
• 포트폴리오를 정한 뒤에는 실행 플랫폼과 기술 아키텍처를 선택해야 한다. 업무 영역과 수준에 따라 서로 다른 도구·플랫폼을 배치하는 기술적 설계가 필요하다. [23:03]

12. 스킬 제작에서 지속 운영과 성과 관리로

• 플랫폼과 아키텍처를 정한 다음에는 임직원이 업무 스킬과 페르소나를 만들고, MCP 연결을 결정해야 한다. 지속 운영을 위한 운영 체계와 개발 주기, 연 1~2회의 사람·에이전트 통합 성과·변화 관리도 필요하다. [23:29]
• 도입 기간은 회사마다 다르며, 바이브 코딩까지 진행한 조직은 대체로 플랫폼·아키텍처 단계에 해당한다. 다음 과제는 자신의 업무를 스킬로 만들어 에이전트에 탑재하는 것이다. [24:22]

13. IBM 디지털 워커의 신원과 자격 관리

• IBM의 디지털 워커는 사번과 이메일 계정을 갖춘 관리 자산이다. 수명 주기는 채용·온보딩, 자격 검증, 배치·운영, 은퇴의 네 단계로 구성된다. [25:14]
• IBM은 피어슨 크레들리와 함께 에이전트에 자격증을 부여하는 정책을 적용했다. 스킬 보유 여부에 더해 검증을 통과한 자격을 디지털 배지로 확인하는 방식이다. [26:26]

14. 기술 중립적 통합 관리와 미사용 에이전트의 은퇴

• IBM의 디지털 워커에는 오픈AI·앤트로픽·왓슨 등 여러 기술이 쓰이지만, 조직 안에서는 동일한 관리 체계가 적용된다. 기술 선택의 다양성과 운영 관리의 통일성을 함께 유지하는 구조다. [27:18]
• 사용하지 않는 에이전트는 토큰 공급 중단 대상으로 삼고, 자격증 회수와 서비스 계정 제거, 필수 로그 백업·보고, 오너·사용자 통지 후 폐기한다. 기존 인사 관리 체계를 변형해 적용하는 방식은 관리 체계 구축 시간을 줄이는 데 도움이 됐다. [27:53]

15. 복잡한 에이전트 도입과 기준별 점검

• AI 에이전트의 복잡성과 난도는 도입을 어렵게 느끼게 하는 초기 장벽이다. [30:04]
• 도입 기준을 하나씩 따라가면 다양한 조직에서도 AI 에이전트 군단을 도입할 수 있겠다는 기대가 생긴다. [30:18]

16. 도입 시도를 위한 점검과 외부 도움

• 기준을 하나하나 점검하며 내용을 검토하는 과정은 에이전트 도입에 도전할 자신감을 얻는 데 도움이 될 수 있다. [30:29]
• 도입이 여전히 어렵다면 전문가에게 도움을 요청하는 선택지가 있으며, 실제 지원을 받을 수 있을지는 기대 수준에 머문다. [30:36]

🧾 결론

• ‘굶겨서 내보내기’의 핵심은 토큰 차단과 함께 자격·계정·로그·통지까지 처리하는 은퇴 절차에 있다.
• 스킬 카드와 에이전트 포트폴리오를 갖춰야 업무 지식의 재사용과 운영 책임을 조직 차원에서 관리할 수 있다.
• 기존 인사 관리 경험을 에이전트 관리에 적용하면 정책 구축 시간을 줄이는 데 도움이 될 수 있다. 기술이 달라도 공통 관리 기준을 적용하는 것이 IBM 사례의 특징이다.

📈 투자·시사 포인트

• 기업의 에이전트 도입 역량을 살필 때 제작 수와 배포 여부에 더해 평가·보안·변경·폐기 체계가 있는지 확인필요가 있다.
• 비용 효율은 토큰 사용량만으로 판단하기 어렵다. 업무 부담과 재작업 감소를 함께 보고, 중복·저사용 에이전트를 정리하는 예산 관리 능력을 점검해야 한다.
• 플랫폼 선택에는 업무 적합성과 함께 권한 통제, 연결 관리, 긴급 차단, 운영 편의성을 반영필요가 있다.
• HR과 IT의 협업, 스킬 공유, 관리자 역할 재설계가 도입의 조직적 과제로 제시된다. 자료에는 특정 기업의 투자 수익률이나 가치평가를 판단할 재무 수치는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• IBM의 디지털 워커 정책은 자료에서 소개된 사례다. 실제 적용 범위, 현재 운영 여부, 자격 검증 기준과 은퇴 절차의 세부 규정은 공식 자료로 확인필요가 있다.
• 연간 두세 번 사용하는 에이전트의 폐기는 일반적인 검토 예시로 제시된다. 이를 IBM의 공식 폐기 기준으로 단정할 근거는 없으며, 사용 빈도 외 업무 중요도를 어떻게 반영하는지도 설명되지 않는다.
• MCP 위험 등급은 자료에서 제시한 분류 방식이다. 조직별 데이터와 권한 차이를 반영한 구체적인 등급 판정·승인 기준은 추가 설계가 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 에이전트별 오너, 담당 업무, 사용 빈도, 비용, 연결 시스템과 권한을 정리해 포트폴리오를 만든다.
• 핵심 업무 하나를 골라 이름·목적, 실행 조건, 입력 형식, 지식 범위, 업무 절차, 외부 도구, 출력, 행동 제한, 예외·복구, 평가 기준을 담은 스킬 카드를 작성한다.
• 정상 업무·경계 조건·오남용을 포함한 평가 세트를 만들고 보안, 신뢰성, 비용, 사용성과 운영 기준을 점검한다.
• MCP 연결을 위험별로 분류하고 중앙 카탈로그, 업데이트 책임, 긴급 차단과 복구 절차를 정한다.

❓ 열린 질문

• 사용 빈도는 낮지만 중요한 업무를 담당하는 에이전트는 어떤 기준으로 유지·통합·폐기를 결정할 것인가?
• 스킬 검증과 디지털 배지는 누가 발급하며, 모델·도구·업무 정책이 바뀌면 언제 재검증할 것인가?
• HR, IT, 개별 업무 오너 사이에서 배포 승인, 비용 책임, 사고 대응과 폐기 결정 권한을 어떻게 나눌 것인가?