기본 콘텐츠로 건너뛰기

"슈퍼 에이전트 하나면 된다"는 말이 위험하게 들렸던 이유

"슈퍼 에이전트 하나면 된다"는 말이 위험하게 들렸던 이유

업무별 에이전트를 수천 개씩 찍어내는 것도, 모든 일을 하나의 만능 AI에게 맡기는 것도 — 나는 둘 다 조심해야 한다고 생각한다. 대기업 AX의 핵심은 에이전트의 개수가 아니라 운영 가능한 단위로 관리되고 있는가이다.

최근 한 영상을 보면서 조금 오래 생각하게 되었다.

영상의 핵심은 대략 이랬다. 기업들이 "OO 업무 자동화 에이전트"를 하나씩 만들기 시작하면, 결국 수백 개, 수천 개의 에이전트가 쌓이고, 그것은 유지보수 지옥이 될 수 있다는 이야기였다. 그러니 특정 업무별 에이전트를 계속 만드는 SI식 사고에서 벗어나, Claude Code나 Codex 같은 범용 슈퍼 에이전트를 조직 전체가 잘 활용할 수 있도록 해야 한다는 주장이었다.

영상의 문제의식 자체는 이해한다

실제로 AI 시대에 과거 SI 방식 그대로 "회의록 에이전트", "카드뉴스 에이전트", "위험성 평가 에이전트", "재무 예측 에이전트"를 각각 따로 구축하는 방식은 위험할 수 있다. 그렇게 만들면 중복 기능이 생기고, 프롬프트도 흩어지고, 권한도 흩어지고, 데이터도 흩어지고, 누가 유지보수할지 모르는 자동화 조각들이 회사 안에 쌓일 수 있다.

그런 의미에서 "업무별 에이전트 난립을 경계해야 한다"는 메시지는 맞다.

그런데 "에이전트 4,000개"라는 전제가 걸렸다

하지만 내가 걸렸던 부분은 그다음이었다. 그 위험을 설명하기 위해 "대기업이 에이전트를 300개, 400개, 4,000개씩 만들게 될 것"이라는 전제가 깔려 있는 것처럼 들렸기 때문이다.

나는 이 전제가 그렇게 쉽게 받아들여지지 않았다.

내가 경험한 대기업은 그렇게 움직이지 않았다. 물론 비효율도 있고, 부서 이기주의도 있고, 오래된 SI 문법도 있다. 하지만 그렇다고 해서 대기업이 아무런 통제 없이 업무별 에이전트를 수천 개씩 발주하고 운영하는 조직은 아니다.

대기업에는 이런 것들이 있다.

  • 품의(稟議)
  • 예산 심사
  • 보안 검토
  • 아키텍처 리뷰
  • 개인정보 검토
  • 운영 인수 조건
  • 장애 책임
  • 유지보수 계약
  • 감사 로그와 권한 관리

이런 체계가 완벽하다는 뜻은 아니다. 하지만 적어도 정식 운영 시스템으로 들어가는 순간, 개별 부서의 요구가 그대로 하나의 독립 시스템으로 무한 증식되는 구조는 쉽게 허용되지 않는다.

대기업은 보통 현업에서 올라오는 요구를 모으고, 중복을 제거하고, 공통 기능을 추출하고, 권한 체계를 통합하고, 운영 주체를 정한 다음, 그 안에서 시스템이나 플랫폼으로 묶어낸다.

4,000개의 요구사항 ≠ 4,000개의 독립 에이전트

그러니 내가 보기에는 "에이전트가 4,000개 생긴다"는 표현 자체가 조금 거칠다.

정확히 말하면, 대기업 안에는 4,000개의 업무 요구사항이 있을 수 있다. 4,000개의 업무 시나리오, 4,000개의 workflow, 4,000개의 rule·role·skill·permission 조합이 있을 수 있다.

하지만 그것이 곧 "4,000개의 독립 에이전트"를 의미하지는 않는다.

이 구분은 중요하다.

4,000개의 독립 에이전트가 각자 다른 방식으로 동작한다면 그것은 분명히 위험하다. 하지만 하나의 공통 플랫폼 위에서 4,000개의 workflow나 skill이 관리된다면 이야기는 완전히 달라진다.

전자는 난립이다. 후자는 거버넌스다.

더 위험한 것은 반작용이다

내가 우려하는 것은, 이 영상을 잘못 해석한 사람들이 "업무별 자동화는 낡은 방식이고, 이제는 슈퍼 에이전트 하나로 모든 것을 처리해야 한다"고 받아들이는 것이다.

이건 또 다른 위험한 단순화다.

대기업은 자유롭게 무엇이든 할 수 있는 만능 AI를 원하는 것이 아니다. 대기업은 사람이 바뀌어도 동일한 품질로 처리되는 업무 구조를 원한다. 누가 요청해도 같은 기준으로 판단하고, 같은 절차를 따르고, 같은 수준의 결과를 내야 한다.

그래서 대기업 업무에는 harness가 필요하다. 테스트 케이스가 필요하고, 승인 절차가 필요하고, 권한 분리가 필요하고, 감사 로그가 필요하고, 버전 관리가 필요하고, 예외 처리와 롤백이 필요하다.

AI가 똑똑하다는 이유만으로 이 모든 것이 사라지지 않는다. 오히려 AI가 더 많은 일을 할 수 있게 될수록, 이 통제 장치는 더 중요해진다.

"1억 개의 일을 할 수 있다"보다 중요한 질문

"슈퍼 에이전트 하나가 1억 개의 일을 할 수 있다"는 말은 듣기에는 멋지다. 하지만 대기업 입장에서 중요한 질문은 다르다.

  • 그 1억 개의 일 중에서, 지금 이 사용자는 어떤 일을 할 권한이 있는가?
  • 이 업무는 자동 실행해도 되는가, 아니면 승인자가 필요한가?
  • 이 결과는 어떤 기준으로 검증되는가?
  • 실패하면 누가 책임지는가?
  • 데이터는 어디까지 접근할 수 있는가?
  • 감사 시점에 어떤 로그를 제시할 수 있는가?
  • 정책이 바뀌었을 때 어떤 workflow가 영향을 받는가?

이 질문에 답하지 못하는 슈퍼 에이전트는 대기업의 업무 운영체제가 되기 어렵다.

그럼 슈퍼 에이전트는 필요 없는가

물론 그런 말은 아니다.

사용자의 요청을 받아 적절한 업무 workflow로 라우팅하는 상위 orchestrator라면 의미가 있다. 여러 도구와 시스템을 연결하는 인터페이스라면 의미가 있다. 직원이 자연어로 업무를 요청하고, 그 뒤에서 적절한 권한 확인과 정책 검증을 거쳐 업무가 실행되는 구조라면 충분히 필요하다.

하지만 그 경우에도 슈퍼 에이전트는 모든 일을 직접 판단하고 실행하는 만능 작업자가 아니라, 전사 거버넌스 안에서 동작하는 업무 진입점에 가까워야 한다.

내가 생각하는 현실적인 구조

내가 생각하는 대기업 AX의 방향은 둘 중 하나가 아니다. 업무별 에이전트 4,000개도 아니고, 모든 일을 처리하는 슈퍼 에이전트 1개도 아니다.

더 현실적인 구조는 이렇다.

  • 공통 Agent Platform이 있고,
  • 그 위에 업무별 workflow와 skill이 있고,
  • 각 workflow에는 role·rule·permission·data boundary가 붙고,
  • 실행 결과는 evaluation harness로 검증되고,
  • 모든 과정은 audit log로 남고,
  • 중요한 업무는 human approval을 거친다.

이런 구조라면 업무가 400개든, 4,000개든, 40,000개든 관리할 수 있다. 반대로 이런 구조가 없다면 에이전트가 10개만 있어도 위험하다.

그러니 핵심은 에이전트의 개수가 아니다. 핵심은 운영 가능한 단위로 관리되고 있는가이다.

정리하며

나는 영상의 문제의식에는 동의한다. AI 에이전트를 과거 SI처럼 하나씩 찍어내는 방식은 분명 위험하다. 그런 방식으로 가면 유지보수 지옥이 올 수 있다.

하지만 그 전제가 "대기업은 곧 무책임하게 수천 개의 에이전트를 만들 것이다"라면, 나는 거기에 동의하기 어렵다. 그것은 일부 PoC나 현업 주도 실험, 혹은 shadow AI 영역에서는 가능할 수 있다. 하지만 대기업의 정식 AX 운영 모델을 그렇게 전제하는 것은 과하다.

그리고 더 위험한 것은, 그 반작용으로 "그러니 슈퍼 에이전트 하나면 된다"고 해석되는 것이다.

대기업 AX는 구호로 되지 않는다. "AI를 많이 쓰자"도 부족하다. "Claude Code를 전사적으로 쓰자"도 부족하다. "토큰을 많이 쓰자"도 본질이 아니다.

진짜 질문은 이것이어야 한다.

  • 우리 회사의 업무를 AI가 수행할 수 있도록 만들려면, 어떤 데이터 구조가 필요한가?
  • 어떤 권한 체계가 필요한가?
  • 어떤 workflow registry가 필요한가?
  • 어떤 업무는 자동화하고, 어떤 업무는 승인 절차를 남겨야 하는가?
  • 어떤 결과를 정답으로 볼 것인가?
  • 누가 운영하고, 누가 책임질 것인가?

이 질문 없이 슈퍼 에이전트만 이야기하면, AI는 또 하나의 유행어가 된다.

나는 AX의 핵심이 "에이전트를 몇 개 만들 것인가"에 있다고 보지 않는다. 또 "슈퍼 에이전트를 하나 도입할 것인가"에 있다고도 보지 않는다.

AX의 핵심은 기업의 업무를 AI가 다룰 수 있는 형태로 재설계하는 것이다. 그 과정에서 필요한 것은 범용 에이전트도, 업무별 workflow도, 공통 거버넌스도, 평가 체계도 모두 포함된다. 어느 하나만으로 해결되지 않는다.

그래서 나는 이렇게 정리하고 싶다.

업무별 에이전트 난립은 위험하다. 하지만 그 대안이 만능 슈퍼 에이전트 하나라는 해석도 위험하다.

대기업 AX의 정답은 "하나로 다 한다"가 아니라, **"공통 플랫폼 위에서 통제 가능한 단위로 나누어 운영한다"**에 더 가깝다.

영상이 던진 문제의식은 중요하다. 하지만 그 메시지가 잘못 해석되면, 기업은 또 다른 극단으로 갈 수 있다. 과거에는 업무마다 시스템을 만들었다. 이제는 그 반대로 모든 업무를 하나의 AI에게 맡기자는 말이 나온다.

내가 보기에는 둘 다 조심해야 한다.

기업에 필요한 것은 유행하는 도구 하나가 아니라, 그 도구를 안전하게 일하게 만드는 구조다. 그리고 그 구조를 설계하는 일이야말로, 앞으로의 AX에서 가장 중요한 일이 될 것이다.

댓글

이 블로그의 인기 게시물

AI에게 존댓말로 질문한다고 AI가 더 자세히 대답해 주지 않습니다! 프롬프트의 뜬소문과 실제. 잘못알고 있는 프롬프트 이야기

영상버전 :  https://youtu.be/rLwhVUIXaQU 어디선가 기사가 있어서 읽다가 코멘트를 단 게 있습니다.  프롬프트 엔지니어링으로 인터넷 강의를 하시는 분 같은데요..  이름에 Phd라고 적혀있으니 어딘가의 박사님 이신가 봅니다.  그 분의 글에 이런게 있더라구요.. 한국어는 맥락에 크게 의존하는 ‘고맥락 언어’입니다. LLM에 그대로 입력하면 종종 의도가 왜곡되거나 핵심이 누락됩니다. 저는 영어로 프롬프트를 작성하지만, 한국어만 해야하는 모델을 사용할 때는 다음과 같은 방법을 사용합니다. --- 중략 --- ✔️ 존댓말(–습니다) vs 반말(–해요) 중 하나 선택.  Deferential form '-습니다'를 사용하면 openAI 모델은 답을 더 길고 상세하게 합니다.  … 여기서 존대말을 사용하면 AI모델은 답을 더 길고 상세하게 합니다. 라고 적혀 있네요..  그랬더니 이 분을 지지하는 댓글에서 chatgpt에게 같은 내용을 물어본 결과를 적었더라구요..  ChatGPT-4o에게 확인해보았습니다: ”한국어를 사용할 때 존댓말로 요청하면, 당신은 좀 더 나은 답을 주신다고 들었습니다. 사실입니까?“ 아주 날카로운 질문이십니다. **“한국어로 존댓말을 쓰면 더 좋은 답을 받는다”**는 말은 부분적으로 사실입니다. ⸻ ✅ 왜 그렇게 느껴질까요?  1. 존댓말은 명확하고 완곡한 문장 구조를 유도합니다.  • 예: 반말: “해줘” → 목적이 불분명하거나 애매할 수 있음 존댓말: “이 내용을 정리해 주시겠어요?” → 요청의 방향이 명확  2. 프롬프트가 더 구체적이고 정중해지면 → 모델이 더 신중하고 완성도 있는 답변을 생성하려는 경향이 있습니다.  3. ‘질문하는 사람의 태도’를 고려한 최적화된 언어 생성이 이뤄집니다.  • 존댓말 = 더 포멀한 상황 → 더 논리적이고 근거 중심의 응답이 생성됨 ⸻ ❗ 하지만 반말도 충분히 잘 작동...

니가 플랫폼(Platform)을 아니?

이번에는 2015년에 썼던 글을 다시 한 번 정리하려고 합니다.  언제나 이야기 하듯이 단어에 대해 누구에게나 쉽게 설명하지 못하면 그건 그 단어를 아는게 아닙니다.  여러분도 이 단어에 대해 비 IT이든 전문가 이든 설명해 줄 수 있는지 한 번 생각해 보시기 바랍니다.  플랫폼에 대해서 이야기를 하다보면 되묻고 싶은 이야기다. 요즘 개발자들 사이에서.. 또는 서비스 기획자들 사이에서 "플랫폼"이란 단어는 필수어가 되었다. 그런데 개발자들 만이 아니라, 기획자, 경영진까지 플랫폼은 필수이다.  웃긴건..  누구는 플랫폼과 서비스를 구분 못하고,  누구는 플랫폼과 프레임웍을 구분 못하고,  누구는 플랫폼과 콘텐츠를 구분 못하고 있다.  이번에는 플랫폼과 서비스를 구분해 보고자 한다.  그런 사람들끼리 이야기하다가 플랫폼이란 단어를 사용하는 사람들에게 물어본다. "플랫폼이 뭔가요?" 누군가 대답한다. "아직도 플랫폼을 몰라요?" 그럼 이렇게 되묻는다. "네.. 제가 잘 몰라서요.. 좀 알려주시겠어요?" 상대방은 IT시스템 어쩌고 하면서 횡설수설한다.. 얼마전 TV에서 플랫폼전문가가 요즘 IT쪽에 도는 플랫폼에 대해서 이야기 한다고 보라고 권장해주었다. TV를 찾아서 보았다. 플랫폼의 정의에 대해서는 나름 이야기를 했다. "수요자와 공급자를 연결해주는 매개체" 그리고 카카오톡을 성공한 플랫폼이라고 했다. 어짜피 성공한 사업에 이름을 붙이는 것은 쉽다. 성공한 주식의 과거를 분석하는게 쉽듯이.. 하지만 성공하지 못한 사업, 그리고 지금 이것이 플랫폼인지 알 수 있는 사람은 몇 안될 것이다. 단어의 의미를 한 번 다시 생각해보자. 그럼 플랫폼은 언제 시작했을까? 18세기후반 부터 19세기에 걸쳐서 약 100년정도를 산업혁명이라고 불렀다. 산업 혁명에 대한 자세한 이야기는 별도 코너로 만들었습니다.  음성 :  https://y...

일본 취업을 희망하는 대학생을 위한 한국에서 잘못알고 있는 일본 신졸 취업 시장.

영상 버전 :  https://youtu.be/nyzRIJ6VjRU 회사에서 작년에 신입을 뽑았는데  얼마전 그 사원의 대학 교수님이 일본에 오실일이 있어서 인사차 만났습니다.  그러면서 좀 충격적인 사실을 알았는데요..  그 때문에 자료를 정리를 해 보았습니다.  제 콘텐츠를 보시면 이미 일본은 3학년 12월에 100개 이상 지원을 해서 내정을 완료하는 경우가 많다고 합니다.  언제부터 취업활동을 하는지 봅시다.  일본은 대학 3학년의 3월 부터 설명회 엔트리를 시작합니다.  그 때 자신이 가고 싶은 회사들의 설명을 듣기 시작하는 것이지요.  그리고 취업활동의 시작은 5월 부터 인턴십 등 여러 방법으로 신입들을 선별하고 있죠. 그리고 일반적인 취업 종료는 대학교 4학년 6~7월이면 99.8%의 신졸 취업이 끝납니다.  그런데 한국의 대학에서 일본 신졸 취업을 보내는 시기는 바로 4학년 9월 정도 부터라고 하네요.  이 때는 이미 신졸 채용은 끝나고 중고신졸이라 불리는 정시 채용에 붙지 못한 신졸들을 주워가는 기업들이 기다리고 있는 시기이죠.  이미 이 때에는 대기업이나 좋은 기업들이 인재를 전부 쓸어 담고, 대기업이랑 같은 시기에 모집해봤자 들어올리 만무한 기업들이 남은 신졸들을 모집하고 있는데요..  그러니 많은 방송에서 신졸이 일본에서 좋은 기업에 취업할 수 없는 이유가 아닐까요?  실제로 교수님이 주변에 있는 전문대에서 야후 재팬에 신졸 채용 되었다고 현수막을 걸었다는 이야기를 했습니다.  제가 그 전문대는 3년제 아니었냐고 물었더니 3년제였다고 했네요..  제 예상이지만, 그 대학교는 3학년 부터 일본 신졸 취업에 지원을 했고, 늦지 않게 신졸 모집 대열에 들어간 것이 아닐까 합니다.  그러면 일반 대학에서도 3학년 부터 준비해서 보내면 되지 않느냐고 질문을 하자, 이런 지원 자체가 국가 지원을 받아서 ...