요즘 메일함에 이러한 내용이 없는 회사는 없을겁니다.
"AI가 이만큼 좋아졌습니다. 모두 AI를 업무에 적용하고 만들어 보세요. 안 그러면 뒤처집니다."
전 직원 공지에, 외부 강사 초빙에, 사내 AI 해커톤에, 좀 심한 데는 누가 토큰을 제일 많이 썼는지 줄 세우는 'AI 사용 순위표'까지 만들더라구요. [ 관련 내용 링크 ]
AI 에이전트가 화두가 된 지난 몇 달 사이, 비슷한 일이 여러 회사에서 거의 동시에 벌어지고 있거든요.
대표님이 직접 AI 코딩 도구를 한번 써보고, 간단한 시제품 하나를 30분 만에 뚝딱 만들어낸 다음, 이런 생각이 드는 겁니다.
"이거 나 혼자서도 되네? 그럼 사람이 왜 이렇게 많이 필요하지?"
요즘 기업뿐만 아니라 기획과 마케팅 사업기획 등에 관심이 많은 개인창업자, 심지어 소상공인들까지 한번쯤 이러한 질문을 하게됩니다. SNS에서도 후킹 멘트로 “혼자 10명의 (AI Agent)직원을 고용했다.”라는 영상들이 판을 치고 있으니까요. 저는 바로 이 질문이 문제의 출발점이라고 봅니다. 그리고 이 질문에 어떻게 답하느냐가, 사실 AI 에이전트를 회사에 들일 때 확실히 따져봐야 할 부분을 명백히 짚어주고 있습니다.
만드는 일과 제대로 돌리는 일은 완전히 다릅니다
Box 의 대표 아론 레비(Aaron Levie)가 이 현상을 한마디로 정리한 적이 있는데, 저는 이게 정곡을 찔렀다고 생각합니다. 경영진은 실제로 일이 굴러가는 마지막 단계와 너무 멀리 떨어져 있어서, (쉽게 만든)AI를 보면 쉽게 들뜨게 된다는 거예요.
그가 든 예가 꽤 날카롭습니다.
"이거 봐바, 괜찮은 프로토타입을 만들었어." 맞는 말이죠. 그런데 그 코드를 실제 서비스에 올리기 전에 직접 들여다보고, 줄줄이 터지는 버그를 잡을 일은 없었을 겁니다.
"이렇게 계약서도 만들어봤어." 이것도 맞습니다. 다만 상대방한테 보내기 전에 조항 하나하나 확인하고, 지금까지 쌓인 기존 계약들과 어긋나는 데는 없는지 맞춰보는 일까지는 안 했겠죠.
시제품을 만드는 데까지는 30분이면 됩니다. 진짜 일은 그다음에 줄줄이 따라오는 열 단계, 스무 단계예요. 보안, 법무 검토, 규정 준수, 접근성, 장애 대응, 권한 관리, 기록 남기기 같은 것들요. 대표님 눈에는 잘 안 보이지만, 회사가 굳이 사람을 두는 이유가 바로 이 자잘하면서도 중요한 일들을 누군가는 해야 하기 때문입니다.
만드는 일과 제대로 돌리는 일은 다릅니다. 게다가 사용자가 확 늘어난 상황에서, 그것도 규제가 빡빡한 환경 안에서 안전하게 돌리는 건 또 한 번 다른 이야기고 결과론에 취한 위험한 결정일 수 있는거죠.
결과물만 보고 내리는 판단의 함정
레비의 진단을 이해하다보면, 이건 결과물만 보고 과정을 통째로 건너뛰는 착각에 가깝습니다.
대표는 회사 어딘가에서 핵심 직원들이 컴퓨터 앞에 앉아 뭔가 분주하게 하는 것을 보면 일이 진행된다는 것으로 알고 있습니다. 그래서 본인도 AI 앞에서 두드려보고 결과물이 나오니까, 그와 같은 일이라고 결론을 내려버립니다. 그치만 현실은 다르기 마련이죠. 직원들이 안 보이는 데서 처리하던 일들은, AI가 코드를 뱉어낸 뒤에도 여전히 누군가는 해야 하거든요.
"내가 만들었으니 이제 누구나 만들 수 있다." 이 한마디가, 애초에 우리가 왜 경력 있는 사람을 뽑았는지를 까맣게 잊게 만듭니다.
여기서 하나 더 짚고 싶은건 현재 AI를 핑계로 대규모 감원을 발표하는 회사들 중에 꽤 많은 곳 특징은 사실 그 전에 사람을 너무 많이 뽑았던 것. "우리가 채용을 잘못했습니다"라고 말하는 것보다 "AI로 효율을 높였습니다"가 시장에, 특히 투자자들한테 훨씬 듣기 좋은 이야기니까요. AI는 도구지, 잘못된 결정을 덮는 핑계가 아닙니다. 더 이상 이러한 사실들은 숨기지 말아야 합니다.
그래서 AI 에이전트 도입은 어디서 막힐까
이 얘기를 회사의 AI 에이전트 프로젝트에 대입해보면, 어디서 어긋나는지가 꽤 또렷하게 보입니다. 저의 주관적인 내용으로 경험상, 거의 모든 시범 프로젝트가 시연 단계까지는 놀라울 만큼 잘 굴러갑니다. 보여주기용으로 돌리면 다들 박수도 칩니다. 문제는 꼭 그 시연을 실제 서비스에 올리려는 순간 터집니다.
서비스로 넘어가려면, 최소한 이 정도 질문에는 답할 수 있어야 하거든요.
이 에이전트가 어떤 데이터를 볼 수 있고, 그 권한은 누가 언제 줬는가
엉뚱한 답이 나왔을 때, 누가 어느 단계에서 그걸 걸러내는가
외부망과 끊긴 환경이나 규제가 엄격한 곳에서 모델과 데이터를 어떻게 따로 떼어 관리하는가
모델을 바꾸거나 장애가 났을 때, 서비스가 안 멈추고 버티는가
이 모든 과정이 나중에 점검받을 수 있게 기록으로 남는가
시연에서는 아무도 안 묻는 질문들이죠. (QA팀 또는 정밀한 검수를 진행할 수 있는 팀이 있는 조직 제외) 그런데 실제 서비스에서는 이게 전부 질문이 됩니다. 그리고 이 질문들에 대한 답을 모아놓은 게 바로 'AI 에이전트 인프라'이자 '관리 체계'예요. 그럴듯한 시연과 믿고 맡길 수 있는 시스템 사이의 거리는, 딱 이 답들을 하나씩 채워 넣는 만큼입니다. 두 달짜리 구축 프로젝트를 직접 해보면, 막상 모델 붙이고 작업 흐름 짜는 건 생각보다 금방 끝나는데, 이 마지막 단계를 메우는 데 시간 대부분이 들어가더라고요.
대표가 정작 해야 할 일
그렇다고 레비가 "대표는 AI를 멀리하라"고 한 건 아닙니다. 오히려 반대죠. 처방은 간단합니다. 대표일수록 AI를 아주 많이 써봐야 한다는 겁니다.
단, 목적이 달라야 해요. "사람을 줄일 수 있겠는데?"라는 결론에 도달하려고 쓰는 게 아니라, 에이전트를 실제 업무에 붙이면 뭐가 필요해지는지 몸으로 겪어보려고 써야 합니다. 좋은 점만 보는 게 아니라, 그걸 굴러가게 만드는 데 들어가는 진짜 손이 얼마나 가는지를 같이 보고 나오는 게 핵심이고요.
시제품이 바로 서비스에 올릴 만한 수준이라고 믿는다면, 한번 그대로 올려보면 됩니다. 변호사가 검토한 계약서만큼 단단하다고 믿는다면, 그게 어긋났을 때 법무 비용이 얼마나 나오는지 직접 겪어보면 되고요. 대부분은 그쯤에서 생각이 바뀝니다.
AI가 강력한 도구인 건 맞습니다. 다만 그 힘은 사람이 제대로, 그리고 스스로 원해서 쓸 때 나옵니다. 억지로 떠밀려 쓰는 사람은 끝까지 잘 쓰는 법을 못 배우더라고요. 그래서 AI를 잘 들인 회사일수록 사람이 줄지 않습니다. 오히려 일을 잘하는 사람이 더 필요해지고, 그 사람들이 만든 결과물을 안전하게 서비스에 올릴 인프라와 관리 체계가 같이 필요해집니다. [관련 내용 링크]
진짜 프로젝트는 질문에서 시작됩니다
AI 에이전트의 진짜 어려움은 '만드는 데' 있지 않습니다. 모두가 알다시피 만드는 건 점점 쉬워지고 있습니다. 어쩌면 정말 30분이면 되는 쪽으로 가고 있죠. 어려운 건 그 뒤에 숨어 있는 마지막 단계, 권한이며 검증이며 격리며 장애 대응이며 기록 같은 일들입니다. 시연을 실제 서비스로 바꾸는 이 구간을 어떻게 짜느냐가 도입의 성공을 가른다고 AI를 환호하는 관중들 속 소수의 전문가들이 외치고 있지만 아쉽게도 메아리 치지 않는 말입니다.
그러니 다음에 누가 "이거 AI로 30분 만에 만들었어요"라고 자랑하면, 일단 칭찬해주고 이렇게 한번 물어보세요.
"오 좋네요. 그럼 이걸 실제 서비스에 안전하게 올리려면 뭐가 더 필요할까요?"
그 질문에서부터, 진짜 프로젝트가 시작됩니다.
그래서 저희는 이 마지막 단계를 이렇게 풉니다
글 내내 "데모는 쉽고 운영이 어렵다"는 이야기를 했는데, 그러면 그 어려운 부분을 실제로 어떻게 메우느냐가 궁금하실 겁니다. 제가 Dify를 기반으로 일하는 이유 그리고, 앞에서 던진 다섯 가지 질문에 하나씩 답을 맞춰보면 이렇습니다.
누가 어떤 데이터에 접근하는가 — 팀과 역할별로 권한을 나눠 두니까, 에이전트가 손댈 수 있는 범위가 처음부터 정해져 있더라고요.
잘못된 답을 어디서 거르는가 — 작업 흐름 중간에 사람이 한 번 확인하고 넘기는 단계를 끼워 둡니다. 엉뚱한 결과물이 그대로 나가는 일을 여기서 막아요.
외부망 끊긴 환경에서 어떻게 쓰는가 — 인터넷에 연결하지 않는 폐쇄망에 통째로 설치해 돌릴 수 있습니다. 데이터가 회사 밖으로 나갈 일이 없죠.
장애가 나도 버티는가 — 여러 대로 나눠 돌리다가 한쪽이 멈춰도 서비스는 그대로 이어집니다.
나중에 점검할 수 있게 남는가 — 누가 언제 무엇을 했는지 기록이 차곡차곡 쌓여서, 감사가 필요할 때 바로 꺼내 볼 수 있습니다.
핵심은, 이걸 매번 A부터Z까지 만들지 않아도 된다는 점입니다. 멋있는 데모를 하나 더 찍어내는 게 아니라, 그 데모가 진짜 서비스로 넘어가는 구간을 짧게 줄이고 실패 사례를 줄여 나아가는 것.
금융이나 공공처럼 규제가 강한 산업군 일수록 거듭 확인한 건, 결국 서비스 가능 수준까지 얼마나 빠르게 배포하느냐에서 승부가 여기서 난다는 사실이었습니다. 어떤 도구를 고르든, 회사에 에이전트를 들일 생각이라면 "이걸 운영까지 끌고 갈 기반이 있나"부터 보시면 좋을 것 같습니다.
오픈네트웍시스템 ㅣ 권태규