AI 에이전트 많이 만든다고 AX가 아니다

에이전트에 대한 관심이 갈수록 높아지고 있지만, 막상 현장에서 AX를 추진하는 분들의 이야기를 들어보면 트렌드와 현실 사이에 적잖은 간극이 있습니다. 에이전트를 만들었다고는 하지만 "살림살이가 나아졌나?"라는 질문에 명확한 답을 내놓는 곳은 많지 않고, 성공 사례도 1인 사업가나 소규모 스타트업에 집중되어 있죠. 엔터프라이즈에서는 더욱 쉽지 않은 과제인데요. 직접 조직에 AI를 도입하고, AX 사업을 통해 다른 기업의 AI 전환을 도우며 체감한 엔터프라이즈 AX의 구조적 딜레마를 짚은 발표가 있어 소개합니다. 현장에서도 많은 공감을 얻은 발표인 만큼, 조직의 AX를 고민하는 분들께 참고가 되실 겁니다.

*이 발표는 2026년 4월 8일 채널톡이 후원한 <AX 리얼 비즈 케이스 스터디 라운드 테이블 1회>에서 진행됐습니다.

컨설팅 15년, 현업 7년, AX 사업 3년차 전문가가 본 엔터프라이즈 AX의 현실과 딜레마
by 주형민 원티드랩 AX 사업 총괄 

안녕하세요, 원티드랩에서 AX 사업을 총괄하고 있는 주형민입니다. 액센추어, EY 등에서 약 15년간 엔터프라이즈 컨설팅을 했고, 산업 현장에서 7년간 혁신을 리딩했습니다. 원티드랩은 ‘원티드’라고 하는 약 385만 유저를 보유한 채용 플랫폼을 운영하고 있는데, 저는 HR이 아니라 AX 사업을 새로 만들기 위해 합류했습니다. 원티드 AX 사업은 현재 3년째 진행되며, AI 에이전트 운영 플랫폼 엔노이아(Ennoia), 교육, 에이전트 개발 생태계의 세 축으로 기업의 AI 전환을 지원하고 있고, 4곳에서 AX 자문위원을 맡고 있습니다.

엔터프라이즈 현장에 오래 있었기 때문에, 오늘은 그 관점에서 AX를 어떻게 받아들여야 하는지에 대해 이야기해 보려 합니다.

다만 본격적으로 들어가기 전에, 하나 질문을 던지고 싶습니다. 성공적인 AX란 어떤 모습일까요? 우리 기업이 AX를 통해 변화한 모습을 구체적으로 그려보신 적 있으신가요?

성공적인 AX의 모습을 상상할 수 있는가

아마 그런 경험이 있는 분은 많지 않을 겁니다. 현재 AX에 대한 논의는 대부분 추상적인 수준에 머물러 있습니다.

기술 트렌드라는 것이 원래 그렇습니다. 빅테크 중심으로 형성되거든요. 클라우드도 그랬고, 빅데이터도 그랬고, RPA도 그랬습니다. "이렇게 변해야 합니다"라는 메시지와 함께 트렌드가 만들어지고, 기업들이 따라가는 구조죠. 지금의 AI 역시 마찬가지입니다.

그런데 생성형 AI가 제공하는 가치의 본질을 잘 봐야 합니다. 기존의 분석형 AI는 과거 데이터를 기반으로 미래를 예측하고, 이상 패턴을 탐지하고, 클러스터링을 통해 새로운 정보 집단을 찾아내는 것이었습니다. 반면 생성형 AI의 본질은 '증강'입니다. 변환하고, 증강하고, 더 빠르게 만들어내는 것. 기존의 분석형 AI가 풀던 예측 문제에 획기적인 기여를 하고 있느냐 하면, 저는 그렇지 않다고 봅니다.

결국 지금 AI 시대가 기업에 주는 것은 "결과물을 빠르게 만들어서 서비스를 출시할 수 있는 능력"입니다. 그런데 대부분의 기업이 그 능력을 갖추게 된다면, AX를 성공적으로 했다는 것은 무엇을 의미할까요. 뒤처지지 않는 정도의 수준에 도달했다는 뜻에 가깝습니다. 차별화라기보다는 기본값이 되는 셈이죠.

여기서 아직 아무도 하지 못하는 이야기가 있습니다. "AX 잘했더니 돈을 엄청 벌었다." 이 말을 할 수 있는 기업이 지금 시장에 잘 보이지는 않는 것 같습니다.

현재 수익을 올리고 있는 쪽은 누구입니까. Claude를 만드는 Anthropic이나 OpenAI 같은 플랫폼 사업자들입니다. 적자라고는 하지만, 결국 카지노의 주인장과 같은 위치에 있어요. 지금은 치킨게임이지만, 나중에 독점이 형성되면 토큰 비용 구조가 바뀌면서 그들이 최종 승자가 될 수도 있습니다.

AX는 해야 합니다. 성공적으로 잘 해야 한다는 데 동의합니다. 다만 AX를 잘했을 때 우리 기업의 모습은, 물론 비즈니스 경쟁력이긴 하지만 그 차별화의 강도가 비교적 약합니다. 이 화두를 먼저 던져놓고, 하나씩 들어가 보겠습니다.

AI 도입 속도는 빨라졌지만, 검증은? 

가트너의 Top 10 Strategic Technology Trend를 보면 흐름이 읽힙니다. 2025년에는 Agentic AI가 등장했고, 거버넌스 플랫폼에 대한 논의가 시작됐습니다. 그리고 주목할 것은 '디지털 프로비넌스(Digital Provenance)', 즉 데이터 신뢰성에 대한 본격화되기 시작했다는 점입니다.

그런데 지금 현장의 분위기는 그 방향이 아닙니다. 신규 기술에 대한 소개의 기세가 너무 강해서, 완전히 공격적으로 앞으로 달려나가는 것에 몰두해 있는 분위기입니다.  

하이프사이클을 떠올려 보면 감이 올 겁니다. 관심도가 급격히 올라갔다가 환멸의 골짜기로 내려가는 구간은 반드시 찾아옵니다. 그때가 되면 생성형 AI가 만들어 낸 결과물의 신뢰성 확인에 대한 요구가 급증할 거예요. 에이전트가 잘못 판단한 것 하나가 큰 사고로 이어지고, 그 사고가 언론에 보도되는 순간 지금의 기세는 상당히 꺾일 수 있습니다.

문제는 그때 돌아보면, 우리가 쓰고 있는 AI가 내놓은 결과물을 실제로 꼼꼼하게 검증하려 해도, 이미 양이 너무 많아서 체크가 어려운 상황이 벌어진다는 점입니다. 지금도 이미 그렇고, 폭주가 시작되면 더 어려워집니다.

엔터프라이즈 입장에서 가장 큰 고민은 따로 있습니다. 기업 내부에서는 보안이 중요하고, 내부 코드가 밖으로 유출되면 안 됩니다. 그런데 외부에 있는 신기술을 내부에서 어떻게 활용할 수 있느냐, 이것이 가장 큰 과제입니다. 폐쇄된 환경에서 최신 기술을 얼마나 효과적으로 쓸 수 있는가. 그 기술 도입을 교육부터 트레이닝, 문화 형성, 그리고 에이전트가 기존 워크플로우를 대체하는 단계까지 끊김 없이 이어갈 수 있는가. 이것이 대부분의 AX 담당자가 직면하는 고민입니다.

그런데 경영진의 관점은 다릅니다. "그래서 살림살이 나아졌냐?" "그거 해서 돈 벌었나?" 하는 것이 중요하죠. 대부분의 기업이 가장 먼저 하는 것이 챗봇 도입이고, 그것을 근거로 비용을 줄였다고 이야기합니다. 그런데 실제로 인건비가 줄었느냐 하면, 그것도 아닌 것 같습니다. 사람은 그대로 있거든요.

결국 엔터프라이즈가 챙겨야 할 것은 세 가지입니다. 보안, 지속적인 혁신, 그리고 기업 최적화. 이 세 가지를 현재의 기술 환경에서 어떻게 이식해 갈 것인지가 핵심인데, 지금은 혁신 쪽으로만 기세가 쏠려 있고 나머지 두 가지는 뒤로 밀리고 있는 상황입니다.

바이브 코딩, 엔터프라이즈에서 조심해야 하는 이유

바이브 코딩 이야기를 좀 해보겠습니다. 솔직히 저는 '딸깍'이라는 표현을 별로 좋아하지 않습니다. 

바이브 코딩과 관련해 납득하기 어려운 주장이 몇 가지 있습니다. 그중 하나가 "나중에는 코드를 안 봐도 된다"는 것입니다. 대기업에서는 감사나 코드 검수가 들어올 수 있습니다. 사고가 발생했을 때 코드의 근거를 추적할 수 없다면, 그 영향 범위는 상당히 커질 수밖에 없어요.

핵심적인 문제는 이것입니다. 외부에서 바이브 코딩으로 만들어진 코드를 기업 내부 IT 유지보수 담당자가 인수할 수 있느냐는 거예요. 문제가 생겨서 보완을 요청했을 때 제대로 대응이 가능할 것인지, 제도적 관점에서 아직 정비가 안 된 부분이 많습니다.

과거에는 정확도(Accuracy) 100%를 기반으로 서비스를 제공했습니다. 소비자들은 그 신뢰성 위에서 서비스를 이용하고 있었어요. 그런데 지금은 "AI는 대부분 잘 해낼 것이고, 약간의 실수는 있을 수 있지만 소비자들도 결국 따라올 것이다"라는 논리가 나옵니다. 저는 이 논리에 동의하기 어렵습니다. 100%의 신뢰성을 기반으로 서비스를 제공해 오다가, AI 때문에 다소 부족하더라도 받아들이라는 것이 현재 시장에 맞는 접근인지 의문입니다.

한편으로 AI 네이티브 컴퍼니의 실체에 대한 질문도 있습니다. 약 1년 전에 알게 된 한 회사 대표님의 고민은 "우리 회사 직원이 아무도 없다고 가정하고, 에이전트로 전부 로직을 설계 한 후에, 그것을 통제할 수 있는 최소 인력이 몇 명인지 컨설팅해 달라." 몇백 명 규모의 회사에서, 최소 인원으로 이것이 동작할 수 있는지를 검토하는 것입니다. 실제 현장에서 지금 이런 일이 벌어지고 있어요.

그런데 대기업에서는 상황이 다릅니다. AI로 효율화가 된다고 해서 "중요한 일에만 집중하겠다"고 하지만, 중요한 일이란 대부분 인지적 부하가 높은 업무입니다. 단순 업무가 빠진 자리에 고강도 의사결정만 남으면, 오히려 번아웃이 찾아옵니다. 이론적으로는 이해가 되지만, 실제 현장에서 그대로 작동하지 않는 부분이 분명히 있어요.

이에 대해 1인 기업의 성공 사례를 보여주시는 분들도 많습니다. 하지만 실제로 그 방식으로 사업을 지속하고 있는 경우는 많지 않아요. 사례로서는 인상적이지만, 그것을 엔터프라이즈에 그대로 적용하기에는 구조적으로 다른 문제가 있습니다.

결국 저는 기존의 책임 체계가 유지될 수밖에 없다고 봅니다. 에이전트가 잘못 판단하면 누군가 책임져야 하니까요. 그 구조는 바뀌지 않습니다.

AI 교육만으로는 부족하다: 실행 환경이 필요한 이유

그렇다면 이런 현실 속에서 기업은 AX를 어떻게 풀어가야 할까요. 저희도 같은 고민을 하면서 직접 부딪혀 봤습니다. 그 과정에서 가장 먼저 마주한 문제가 교육이었습니다.

대부분의 기업이 비슷한 고민을 하고 있을 것 같은데요, 교육 자체에 너무 많이 투자하는 경향이 있습니다. 교육에 투자하고, 환경을 잘 만들어 주는 것까지는 신경을 쓰지만, 정작 배운 것을 현장에 적용하지 못합니다. 부문 교육하고, 임원 교육하고, 결과적으로 개인 생산성만 좋아지는 거예요. 퇴근만 빨라지는 셈이죠.

토큰 이코노미라고 하면 토큰을 많이 쓸수록 수익으로 연결돼야 하는데, 이 연결고리가 끊어져 있습니다. 교육을 받고 나서 혼자 적용해 보다가 중간에 막히면 해결하지 못하는 경우가 너무 많았고, 뭔가 만들긴 했지만 실무와 동떨어진 결과물만 쌓이는 상황도 빈번했습니다.

그래서 저희가 초반에 잡은 방향은 이것입니다. ‘가르치는 것보다 직접 찾고 실행할 수 있는 환경을 만드는 데 집중하자’. 강의 자체보다 자기 업무에서 문제를 정의하고 해결해 나가는 것이 중요하다고 봤습니다. 수료했다고 AX 전문가가 되는 것은 아니잖아요. 수료하고 돌아왔는데 현장에 변화가 없으면 의미가 없습니다.

이런 생각으로 저희는 세 단계의 체계를 만들었습니다.

1단계: AI를 많이 쓸 수 있는 환경 조성 

우선 AI를 적극적으로 쓸 수 있도록 환경을 열어줬습니다. 저희도 교육비가 1인당 연간 약 100만 원 정도 되는데, 기존에는 외부 교육에 다녀와서 전달 교육하는 방식이었거든요. 그런데 그 방식은 활용으로 잘 이어지지 않더라고요. 그래서 어떤 도구든 자유롭게 쓰라고 개방했더니 다들 쓰기 시작했습니다. 도구에 대한 접근성이 좋아진 겁니다.

내부에 'AI줍줍'이라는 사례 공유 채널도 운영하고 있는데, 3월 한 달에만 약 75건의 게시물이 올라왔습니다. 하루 평균 3~4건입니다. 새로운 사례, 직접 해본 경험을 계속 공유하는 것이죠. 직원이 약 160명 정도 되는데 상당히 활발하게 돌아가고 있고, 우수 사례에 대한 시상도 진행합니다. 대표부터 채용사업팀, 후보자 경험팀, PR팀까지 다양한 부서에서 자기가 만든 것을 올리는 문화가 자리 잡혔어요.

2단계: AI 챔피언 양성

챔피언 제도를 만들어서 20명씩 두 달 동안 집중 트레이닝을 진행합니다. 한 곳에 모여 팀을 구성하고, 내부의 실제 업무 문제를 함께 해결하는 방식입니다. 특정 업무 시간을 확보해 결과물을 만들고, 공유하고, 바로 업무 시스템에 반영합니다. 격주 오프라인 모임에서는 참여자들이 직접 발표도 합니다. 재무 부서에서 카드 전표 처리를 자동화한 사례 같은 것들을 공유하는 거죠.

핵심 운영 원칙은 이렇습니다. 본인이 직접 문제를 해결하고, 서포터즈가 옆에서 바로 지원하고, 직무나 연차에 관계없이 누구나 참여할 수 있도록 열어두는 것. 3기까지 운영하면 전체 직원의 약 3분의 1이 이수하게 됩니다. 6개월 만에요. 1기 때 추천 의향이 5점 만점에 4.8이 나올 정도로 만족도가 높았고, 비개발자분들이 빠른 속도로 자동화를 만들어내면서 개발자가 긴장하는 현상도 나타났습니다. 개인이 만든 도구가 팀 전체의 워크플로우를 바꾼 경우도 있었어요.

재미있었던 것은 경영진의 반응이었습니다. 저희 대표가 새벽 2~3시까지 클로드 코드로 이것저것 만들다가 클로드 사용량 제한에 걸려 "2시간만 참자, 굿나잇 클로드"라고 슬랙에 올린 적도 있을 정도로 적극적으로 활용했습니다. 바이브코딩으로 만든 결과물을 적극적으로 공유하고, 만들면서 느낀 점도 기록했죠. 경영진이 그 정도로 직접 쓰고 있으면, 주변 임원급의 수준도 자연스럽게 올라갑니다. 자연스럽게 임원들을 비롯한 리더들도 AI 활용을 더욱 적극적으로 하게 되면서 조직이 움직이는 모습을 보게 됐습니다. 

3단계: 실행 생태계 조성

깃허브에 '백야드(Backyard)'라는 내부 배포 공간을 별도로 마련했습니다. 외부에 배포하기 어려운 도구들을 올릴 수 있는 곳이에요. 스킬 허브도 구축해서 필요한 기능을 선택해 바로 사용할 수 있게 하고, 보안 점검용 코드 스캐닝 스킬도 포함시켰습니다. 자체 디자인 시스템도 MCP(Model Context Protocol, AI 모델이 외부 도구나 데이터와 연결되는 표준 프로토콜)로 연결해서, 클로드 코드에 "우리 디자인 시스템에 맞춰 줘"라고 하면 바로 적용되는 환경을 갖추고 있습니다.

현장에서 나온 사례도 인상적이었습니다. 총무 담당자가 2만 원짜리 바코드 리더기를 구입해서, 프롬프트 편집과 API 연결만으로 도서 반납 자동화 시스템을 구축한 거예요. 바코드를 스캔하면 구글 시트에 자동 등록되고, 슬랙으로 알림이 오는 구조입니다. HR에서는 '피플이'이라는 에이전트를 만들어 업무 환경에 자연스럽게 통합해 놓았고, 사업 부서에서는 모니터링과 기사 수집을 멀티 에이전트로 자동화해서 슬랙으로 수신하고 있습니다.

여기서 중요한 전환점이 있었습니다. 이렇게 여러 에이전트를 만들다 보니, 생성형 AI는 전통적인 IT와 개발·운영 방식이 근본적으로 다르다는 것을 체감하게 됐어요. 할루시네이션(AI가 사실이 아닌 정보를 생성하는 현상) 문제가 있고, CI/CD(지속적 통합·배포) 관점에서 빠르게 통합하고 반영해야 하는데 기존의 배포 절차로는 대응이 어려운 부분이 많았습니다. 여러 LLM을 유연하게 전환하며 사용하고, 모든 로그를 기록하고, 튜닝할 수 있는 기반이 필요했어요. 

그래서 자체 플랫폼을 만들기 시작했고, 그것이 엔노이아(Ennoia)로 고도화됐습니다. 엔노이아는 기업이 원하는 업무를 AI 에이전트로 구현하고 운영할 수 있게 지원하는 플랫폼입니다. 저희가 지향한 것은 현업의 모든 임직원이 직접 활용할 수 있어야 한다는 것이었습니다. 

다만 실행 환경을 구축했다고 해서 모든 것이 해결되는 것은 아닙니다. 저희도 제품 개발 프로세스를 압축하려는 시도를 하고 있어요. 기존에는 PO(Product Owner, 제품 기획자)가 기획하고, PD(Product Designer, 제품 디자이너)가 피그마로 디자인하고, 프론트엔드 개발자가 구현하고, 백엔드로 넘기고, QA를 거쳐 배포하는 구조였는데, 이것을 일주일 단위로 줄여보려 하고 있습니다. 기존에는 2주 단위로 누적 배포하던 체계였거든요.

그런데 이것이 실제로는 매우 어려운 일입니다. 기차를 떠올려 보시면 됩니다. 앞부분이 시속 100km로 가는데 중간 칸이 30km로 가면 어떻게 될까요. 어느 한 구간만 빨라진다고 전체 실행 속도가 빨라지지 않습니다. 100km로 가는 바퀴 옆에 30km짜리 바퀴가 달려 있으면 마찰이 생기는 겁니다. 조직 전반이 빠른 속도로 나아가기 위해서는 관성의 속도가 맞아야 합니다. 이것이 가장 어려운 부분이에요.

그래서 지금은 각 구간을 분리해서 테스트하고, 그 경험을 공유하면서 어떤 부분을 보완할지 찾아가고 있는 단계입니다.

AI 에이전트를 많이 만들면 AX 성공인가

엔터프라이즈 AX를 잘하기 위한 방향 자체는 단순합니다. 잘 체험하고, 교육받고, 활용하고, 지원하고, 통제하는 것. 이것이 자연스럽게 순환하는 구조를 만드는 것이라고 저는 생각합니다. 그런데 지금은 너무 공격적으로 치고 나가고 있다 보니, 통제에 필요한 정보를 제대로 관리하고 있는지에 대한 고민은 뒤로 밀리고 있습니다.

저도 이런 딜레마를 하나씩 풀어야 해결의 실마리가 보이겠다 싶어서, 약 16가지 정도를 정리해 놓고 있습니다. 나중에 아티클로 하나씩 다루든, 묶어서 책으로 내든 할 생각인데요. 오늘은 그중에서 현장에서 자주 부딪히는 것들을 몇 가지 짚어보겠습니다.

혁신에는 레이어가 있다

대기업으로 갈수록 혁신은 특정 부서에 위임되어 있습니다. DX 부서, AX 부서가 별도로 존재하고, 거기서는 워크플로우 기반의 변화를 만들어낼 수 있습니다. 그런데 일반 업무를 수행하는 직원들은 그런 변화를 원해도 직접 바꿀 수가 없어요. 권한이 없으니까요.

리더의 성향에 따라서도 속도가 완전히 달라집니다. AI 친화적인 리더는 리스크를 일정 부분 감내하면서 공격적으로 추진하고, AX/DX 담당 리더는 양쪽을 바라보면서 리스크를 관리하려 하고, 현업은 99.9%의 정확도를 요구합니다. 이 세 가지 레이어가 같은 조직 안에 공존하고 있는 것입니다.

그래서 전사, 부서, 개인이 동일한 교육을 받는 것이 아니라, 각 단위에 맞는 교육과 환경이 필요합니다. 교육뿐 아니라, 외부 기술 환경과 내부 기술 환경을 어떻게 통합해서 활용할 것인지까지 설계가 돼야 합니다.

알고리즘 전문가가 하루 아침에 PM이 되지는 않는다

기존에 데이터 사이언티스트로 일하시던 분들이 AI 엔지니어 영역으로 전환되는 경우가 늘고 있습니다. 그런데 이분들은 알고리즘 스페셜리스트로서 깊이 있는 기술 역량을 갖고 계신 반면, 대외 프로젝트를 직접 리딩해 본 경험은 많지 않은 편입니다.

그런데 지금 이분들에게 요구되는 역할은 프로젝트 관리자이자 중재자입니다. 각 부서의 과제 담당자와 요건을 조율하고, 외부 전문 기업과 협력해 에이전트를 구축해야 하는 거예요. 알고리즘 전문가가 PM이자 부서 간 조율자 역할로 전환되고 있는 셈입니다.

데이터 엔지니어도 마찬가지입니다. 기존에는 DW(Data Warehouse)에 데이터 마트를 잘 구성해 놓는 것까지가 역할이었는데, AI 데이터 엔지니어링은 벡터DB를 구축하고, 임베딩과 청킹(데이터를 AI가 처리할 수 있는 단위로 분할하는 작업)을 다루는 전혀 다른 영역입니다. 기존 데이터 인프라에서 AI 쪽으로 데이터를 보내줄 것인지, AI 데이터 엔지니어링 측에서 반대로 가져올 것인지, 그리고 DW 컬럼 값이 변경됐을 때 데이터 파이프라인이 깨지면 누가 책임질 것인지. 이런 것들이 정리되지 않은 채로 진행되는 경우가 많습니다.

기준 없이 시작하면 성과도 보이지 않는다

개인 성과와 팀 성과가 연결되지 않는 경우가 많은데, 근본적으로는 베이스라인(기준선) 설정이 안 돼서 그렇습니다. 이니셔티브를 정해놓고 시작은 하지만, 어느 시점을 기준으로 어떤 지표로 효과를 측정할 것인지에 대한 합의가 없어요.

그러다 보니 매번 같은 질문이 돌아옵니다. "그래서 우리가 좋아진 게 뭐야? 돈 벌었어?" 이것에 명쾌하게 답하지 못하는 거죠. 결국 FTE(Full-Time Equivalent, 상근 인력 환산) 관점에서 업무를 분해하고, 주기와 빈도를 감안해서 측정 기준을 먼저 세운 다음 시작해야 하는데, 그 과정 없이 진행하는 곳이 대부분입니다.

자동화했다고 끝이 아니다

자동화가 확산되고 있지만, QC(Quality Control, 품질 관리)를 간과하는 경우가 상당히 많습니다. 저도 과거에 금융사에서 자동화 프로젝트를 다수 수행했는데, 자동화에 대한 핵심 판단 기준은 명확합니다. 리스크 발생 확률이 낮을 경우, 혹은 문제를 조사해서 얻을 수 있는 총효용 보다 사람의 개입 비용이 클 경우 자동화로 처리하는 방향으로 진행됩니다.

처리 결과에 대한 QC도 체계가 필요합니다. 일정 비율, 예를 들어 5%씩 샘플링해서 정기적으로 검토하거나, 처리 이력 전체를 주기적으로 검수하는 CFR(Close File Review) 방식이 있어요. 로그를 빠짐없이 남기고, 팩트체크를 수행할 수 있는 조직적 기반이 갖춰져야 합니다. 이 작업을 AI에게 위임하면 안 됩니다. AI는 책임을 지지 못하니까요.

"자동화됐으니까 끝"이 아닙니다. 문제가 발생했을 때 "이 건의 담당자가 누구인가?"라는 질문에 답할 수 있어야 합니다.

에이전트 오너십이 필요하다

결국 AI의 결과를 최종적으로 보증하는 것은 사람입니다. 설명 가능한 AI(XAI, Explainable AI)를 넘어서, 이제는 '책임질 수 있는 AI'의 영역으로 진입하고 있습니다.

그렇다면 에이전트의 오너십에 대한 기준이 필요합니다. 이 에이전트의 소유자가 누구인지, 품질 관리와 운영에 대한 책임은 누가 지는지를 명확하게 정해야 합니다. 여러 에이전트가 부서 간에 연결돼 크로스 펑셔널 (Cross-Functional, 부서 횡단적)하게 동작할 수도 있는데, 그 통합을 누가 위임하고, 누가 승인하는지도 정리돼야 합니다.

AI를 쓰면 역할이 확장됩니다. 기존에 할 수 없었던 것들을 더 많이 수행할 수 있게 되니까요. 그런데 역할이 커지면 책임도 커집니다. 이 부분을 간과했다가는 나중에 상당히 큰 비용을 치르게 될 것이라고 생각합니다.

저희도 이런 고민 속에서 외부 도구와 내부 환경을 분리해 운영하고 있습니다. 클로드 코드 같은 외부 도구는 프로토타입을 빠르게 만들어 시장 반응을 확인하는 용도로, 보안이 필요한 업무 자동화는 엔노이아 내 워크플로우 빌더를 통해 처리하는 방식입니다. 모든 에이전트를 외부 환경에 전부 맡길 수는 없으니까요.

이런 딜레마들은 결국 하나의 질문으로 수렴합니다. AX를 통해 우리가 진짜 얻고자 하는 것이 무엇인가, 하는 것이죠. 

AX를 하고도 남는 질문: 그래서, 살림살이 나아졌나

마지막으로 드리고 싶은 이야기입니다.

우리가 AX를 추진하는 이유는 무엇일까요. 가장 중요한 이유는 고객이 필요로 하는 것을 정확히 파악해서, PMF(Product-Market Fit, 제품과 시장의 적합성)를 찾는 것이라고 봅니다. 빨리 많이 만드는 것이 핵심이 아니라, 만든 것을 고객에게 어떻게 전달하고 안착시킬 것인지에 대한 전략이 먼저입니다. 그 전략을 갖추고 나서 실행하면 문제가 없어요. 그런데 우리가 지향하는 것이 에이전트를 많이 만들어 놓고 "AX 했다"고 선언하는 것인가요?

지금 AI가 주는 효율은 분명합니다. 짧은 시간 안에 다양한 서비스를 양산할 수 있게 됐습니다. 그런데 고객이 그것을 원하는지는 별개의 문제입니다. "빨리 많은 서비스를 출시하면 수익이 따라올 것이다"라는 공식이 정말 성립하는지, 고객의 수요가 그 속도를 따라갈 수 있는지, 저는 의문을 갖고 있습니다.

AI를 활용하면 기존보다 결과물의 신뢰 수준이 낮아질 수 있다는 문제도 있습니다. 지금도 ChatGPT가 "부정확할 수 있습니다"라고 표시하잖아요. 과거에는 높은 수준의 신뢰도를 가진 정보성 상품을 제공하고 있었는데, 현재는 양은 많아졌지만 신뢰 수준은 떨어질 수 있는 구조가 된 겁니다. 그러면 고객이 그것을 구매할까요?

실제로 요즘 현장에서 감지되는 변화가 있습니다. "AI로 만든 장표로 발표하지 않았으면 좋겠다"는 요청이 조금씩 나오고 있어요. 의외로 적지 않습니다. 결국 고객의 마음을 움직이는 것은 사람의 손길이 들어간 부분일 거라고 생각합니다. 그래서 우리가 기대하는 만큼 드라마틱하게 인력이 줄어드는 자동화는 일어나지 않을 수 있습니다.

처음에 이런 화두를 던졌습니다. "성공적인 AX의 모습을 상상할 수 있는가?" 그리고 "AX 잘했더니 돈 벌었다"고 말할 수 있는 기업이 아직 많이 없다고 했습니다.

AX는 해야 합니다. 잘 체험하고, 잘 활용하고, 잘 통제하는 구조를 만들어야 합니다. 다만 에이전트를 많이 만드는 것 자체가 목적이 되어서는 안 됩니다. 속도만 빨라졌을 뿐 구조적으로 고민하지 않으면, 결국 같은 질문으로 돌아오게 됩니다.

"그래서, 살림살이 나아졌나?"

이 질문에 명쾌하게 답할 수 있으려면, 지금보다 조금 더 구조적으로 고민할 필요가 있지 않나 싶습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.