- AI를 전사로 확장하려면 좋은 모델 하나로는 부족하다. 데이터, 엔지니어링, 플랫폼, 운영 모델, 거버넌스 다섯 요소가 한 몸처럼 맞물려야 한다.
- 금융처럼 규제가 강한 산업에서는 책임 있고 믿을 수 있게 구현하는 것부터가 확장의 출발점이다.
- 에이전트형 AI를 붙이기 전에 다섯 요소 중 가장 약한 곳부터 진단하는 게 순서다.
AI와 머신러닝, 생성형 AI, 여기에 행동과학까지. 투자 회사 뱅가드(Vanguard)는 이 네 분야를 ‘AI·인사이트 센터(Center for AI & Insights, CAI)’라는 한 조직 안에 두고 있다. 행동과학은 사람이 어떻게 의사결정을 내리는지 연구하는 학문이다. 이런 분야가 기술 조직 안에 함께 들어가 있는 건 꽤 의외다. 이 센터를 이끄는 징 왕(Jing Wang)은 MIT 테크놀로지 리뷰가 연 EmTech Future 컨퍼런스 세션에서 모델 성능 이야기를 꺼내지 않았다. 대신 확장 가능한 AI에는 튼튼한 기반이 필요하다고 짚었다. 세션의 요지는 이렇다. 그 기반은 데이터·엔지니어링·플랫폼·운영 모델·거버넌스가 하나로 모여 함께 움직일 때 생긴다.
이 글은 세션 내용을 순서대로 옮기지 않는다. 먼저 다섯 요소가 각각 어떤 역할을 하는지 본다. 왜 하나만 빠져도 AI가 시범 사업 단계에서 멈추는지도 함께 짚는다. 규제가 까다로운 업종과 에이전트형 AI를 준비하는 조직이 어디부터 점검하면 되는지는 그다음에 다룬다. 미리 밝혀 둘 것이 있다. 세션 소개글에는 다섯 요소의 이름과 방향이 담겨 있다. 하지만 뱅가드가 각 요소를 실제로 어떻게 구현했는지는 나오지 않는다. 그래서 아래 해설에서는 원문으로 확인되는 내용과 이 글의 해석을 되도록 문장 단위로 나눠 적었다.
AI 시범 사업이 전사로 못 퍼지는 원인은 대개 모델 밖에 있다
사내 AI 프로젝트는 대개 작게 시작한다. 한 팀이 직접 골라낸 데이터로 모델을 만들고, 몇 명이 써 본다. 데모 반응이 좋으면 성공 사례로 기록된다. 탈이 나는 건 이걸 다른 부서와 더 많은 고객, 더 많은 업무로 넓히려는 순간이다.
부서마다 같은 항목을 다르게 정의한 데이터가 뒤섞인다. 사람이 손으로 하던 배포와 점검은 늘어난 물량을 감당하지 못한다. 만든 팀, 쓰는 팀, 책임지는 팀이 제각각 갈라지는 것도 대개 이 무렵이다. 법무·리스크 검토가 출시 직전에야 붙으면 프로젝트가 그 자리에서 멈추기도 한다. 어느 경우든 모델을 더 좋은 것으로 바꾼다고 풀리는 병목은 아니다. 원문은 모델 대신 기반 요소 다섯 가지를 꼽았다. 이 글은 그 선택을 이런 맥락에서 읽는다.
원문에서 눈여겨볼 단어는 ‘수렴(converge)’이다. 다섯 요소가 각자 성숙하는 것만으로는 모자라고, 하나의 시스템처럼 맞물려야 한다는 뜻이다. 데이터 팀은 훌륭한데 플랫폼이 부서별로 쪼개진 조직이 있을 수 있다. 거버넌스 규정은 문서로 있는데 실제 개발 도구에는 반영되지 않은 조직도 있다. 두 조직 모두 확장 단계에서 결국 같은 벽에 부딪힌다. 다섯 가운데 넷을 잘 갖춰도 하나가 비면 확장이 막힌다.
데이터에서 거버넌스까지, 다섯 요소가 각각 맡는 일
다섯 요소를 하나씩 풀면 아래와 같다. 뱅가드 CAI의 역할을 다룬 대목만 소개글 내용이다. 나머지는 각 요소가 일반적으로 맡는 역할을 이 글이 풀어 쓴 설명이다.
데이터는 AI가 무엇을 근거로 판단하느냐의 문제다. 품질만 따져서는 안 된다. 누가 어떤 권한으로 데이터에 접근하는지가 걸려 있다. 부서마다 같은 지표를 같은 정의로 쓰는지, 데이터가 어디서 와서 어떻게 가공됐는지 추적할 수 있는지도 함께 따져야 한다.
엔지니어링은 실험실의 모델을 실제 서비스로 옮기는 작업이다. 테스트, 배포, 성능 감시, 업데이트를 사람 손에 맡기지 않고 반복 가능한 절차로 만든다. 흔히 MLOps라 부르고, 생성형 AI 쪽에서는 LLMOps라는 말도 쓴다.
플랫폼은 팀마다 같은 것을 처음부터 다시 만들지 않게 해 주는 공용 바닥이다. 모델 접근, 검색 같은 공통 기능, 평가 도구, 권한 관리를 한곳에서 제공할 수 있다. 그러면 두 번째, 세 번째 프로젝트는 훨씬 빨리 출발할 수 있다.
운영 모델은 결국 조직도의 문제다. 중앙 AI 조직이 전부 만들 수도 있다. 사업 부서에 전문가를 두고 중앙은 표준과 플랫폼만 맡는 방식도 있다. 다 만든 뒤 유지보수를 누가 하느냐도 여기서 정해진다. 소개글에 적힌 바로는 뱅가드 CAI가 전사 차원의 혁신과 연구에 더해 실제 결과물 전달(delivery)까지 맡는다. 연구로 끝내지 않고 결과물을 현업에 넘기는 책임까지 한 조직이 진다. 운영 모델을 고민하는 조직이라면 참고할 만한 대목이다.
거버넌스는 무엇은 해도 되고 무엇은 안 되는지, 누가 승인하는지, 문제가 생기면 누가 책임지는지를 정하는 규칙이다. 사용 사례를 위험도별로 나누는 일이 여기에 속한다. 결정 근거를 기록으로 남기는 일, 사람이 개입해야 할 지점을 미리 정해 두는 일도 마찬가지다.
| 요소 | 답해야 할 질문 | 비어 있을 때 흔한 증상 |
|---|---|---|
| 데이터 | 필요한 데이터를 누가, 어떤 정의와 권한으로 쓰는가 | 부서마다 같은 지표 값이 달라 AI 결과를 믿지 못함 |
| 엔지니어링 | 시범 모델을 운영 서비스로 옮기고 계속 감시할 수 있는가 | 데모는 되는데 배포·업데이트가 매번 수작업 |
| 플랫폼 | 공용 도구를 재사용하는가, 팀마다 새로 만드는가 | 비슷한 챗봇·파이프라인이 부서마다 중복 |
| 운영 모델 | 기획·개발·운영·책임 역할이 누구에게 있는가 | 만든 팀이 빠지면 유지보수할 사람이 없음 |
| 거버넌스 | 위험을 어떤 기준으로 나누고 누가 승인하는가 | 출시 직전 리스크 검토에서 프로젝트가 멈춤 |
표의 증상 칸은 원문에 나온 사례가 아니다. 각 요소가 비었을 때 흔히 나타나는 모습을 설명하려고 덧붙인 내용이다.
표에서 가장 심각한 건 거버넌스 줄이다. 다른 칸의 증상은 비용이 늘거나, 결과를 믿기 어렵거나, 유지보수가 끊기는 문제다. 거버넌스가 빈 조직은 출시 직전에 아예 멈춰 선다. 다음 절에서 거버넌스를 따로 다루는 이유다.
규제 업종의 거버넌스, 속도를 늦추는 절차에서 다시 쓰는 틀로
이 세션은 ‘고도로 규제된 환경’을 전제로 한다. 연사가 금융 회사 소속이니 자연스러운 설정이다. 금융은 고객 자산과 바로 이어지는 판단이 많은 업종이다. 그 판단을 설명하고 기록할 의무도 있다. AI를 들이는 방식이 다른 산업과 같을 수 없다.
거버넌스를 속도를 늦추는 절차로만 보는 시각이 흔하다. 프로젝트마다 위험 검토를 처음부터 다시 받는다면 실제로 느려진다. 반대로 거버넌스를 기반의 일부로 미리 깔아 두는 방식도 있다. 위험도별 기준, 미리 승인된 사용 패턴, 공용 플랫폼에 넣어 둔 기록·권한 기능이 그 예다. 이렇게 하면 두 번째 프로젝트부터는 이미 통과한 틀을 다시 쓸 수 있다. 원문은 ‘책임 있고 믿을 수 있는 구현’을 투자자에게 돌아갈 ‘지속적인 가치’와 연결했다. 여기까지가 원문 내용이다. 그 연결이 이런 구조에서 나온다고 보는 건 이 글의 해석이다. 신뢰가 쌓여야 더 중요한 업무를 AI에 맡길 수 있고, 그래야 확장이 일회성 성과로 끝나지 않는다.
연사의 이력도 이 관점과 맞닿아 있다. 징 왕은 중국과학기술대에서 물리학 학사를, 펜실베이니아대에서 박사 학위와 와튼스쿨 MBA를 받았다. 보스턴컨설팅그룹(BCG)에서는 프린시펄로 일했다. 뱅가드에서는 금융 서비스, 워크플레이스 솔루션, 인터내셔널, 코퍼레이트 서비스 부문을 두루 이끌었다. 미국 증권업 자격인 Series 7·24·65도 갖고 있다. AI 조직을 이끄는 사람이 사업 부문 경험과 증권업 규제 자격을 모두 갖췄다는 점은 눈여겨볼 만하다. 이 글은 이를 규제 산업의 AI 확장이 기술만의 과제가 아니라는 신호로 읽는다.
에이전트형 AI가 틀리면 남는 건 잘못된 행동이다
원문은 확장할 새 역량으로 에이전트형 시스템(agentic systems)을 직접 꼽는다. 에이전트형 AI는 질문에 답하는 데서 멈추지 않는다. 목표를 받으면 스스로 단계를 계획하고, 다른 시스템을 호출해 실제 작업까지 해낸다. 답변형 AI가 틀리면 잘못된 문장이 남는다. 에이전트가 틀리면 잘못된 행동이 남는다. 이것이 결정적인 차이다.
에이전트 단계에서는 다섯 요소가 더 구체적인 질문으로 바뀐다.
- 데이터·권한: 에이전트가 읽고 쓸 수 있는 데이터와 시스템이 업무에 필요한 최소한으로 제한돼 있는가?
- 엔지니어링: 에이전트가 단계마다 한 행동이 로그로 남고, 이상이 생기면 멈추거나 되돌릴 수 있는가?
- 플랫폼: 에이전트가 호출하는 도구를 부서마다 따로 붙이지 않고 공용으로 관리하는가?
- 운영 모델: 에이전트가 처리한 업무 결과를 책임질 사람이 정해져 있는가?
- 거버넌스: 어떤 행동 앞에서 사람 승인을 받아야 하는지 기준이 있는가?
이 질문에 답하지 못한 채 에이전트부터 들이는 조직도 있을 것이다. 이 글은 그런 경우 시범 운영은 화려해도 실제 업무로 넓히는 단계에서 다시 멈출 가능성이 크다고 본다. 질문 하나하나가 앞서 본 다섯 요소에서 나왔다. 답변형 AI에서는 미뤄 둘 수 있던 빈칸이 에이전트 단계에서는 바로 사고로 이어질 수 있다. 기반이 먼저라는 원문의 메시지가 에이전트형 AI에서 특히 무겁게 다가오는 이유다.
국내 은행·증권 앱과 AI 도입 제안서에 대입해 보면
뱅가드는 해외 투자 회사다. 하지만 한국에서도 금융은 대표적인 규제 산업이어서 비슷한 고민이 생길 수 있다. 아래는 원문에 직접 나온 내용이 아니다. 같은 구조를 국내 상황에 대입해 본 해석이다.
- 이용자 입장(추측): 은행·증권 앱의 AI 상담이나 투자 도우미는 다른 업종보다 늦게 나오거나 좁은 기능으로 시작하는 경우가 있다. 규제 환경에서 기반과 검증을 먼저 갖추느라 생긴 차이라면 자연스러운 흐름일 수 있다. 기능이 적다는 것만으로 기술력이 낮다고 단정하기는 어렵다.
- 실무자 입장: AI 도입 제안서를 모델 성능 비교로만 채우지 않는 편이 낫다. 데이터 접근 방식, 운영 주체, 승인 절차까지 다섯 요소별 계획을 함께 담으면 리스크·컴플라이언스 부서를 설득하기가 한결 쉬워 보인다. 확장을 막는 병목이 모델 밖에 있다는 원문의 진단을 실무 문서에 그대로 옮긴 셈이다.
- 조직 설계 측면(추측): 뱅가드는 AI 조직에 행동과학을 함께 뒀다. 고객 경험을 다루는 AI라면 기술 인력만으로 팀을 꾸릴 필요는 없다. 고객 행동을 이해하는 인력을 같은 팀에 두는 방식도 검토해 볼 만하다.
국내 규제 기준은 업권과 서비스마다 다르다. 실제로 어디까지 적용되는지는 각 조직의 컴플라이언스 부서와 확인하는 게 안전하다.
확인된 것과 아직 불확실한 것
확인된 것
- EmTech Future 컨퍼런스 세션은 고도로 규제된 환경에서 확장 가능한 AI의 기반을 만드는 방법을 다룬다.
- 세션이 꼽은 기반 요소는 데이터, 엔지니어링, 플랫폼, 운영 모델, 거버넌스다. 이 다섯 가지가 하나로 맞물려 작동해야 한다는 게 요지다.
- 책임 있고 믿을 수 있는 구현이 에이전트형 시스템을 비롯한 새 역량을 투자자를 위한 지속적 가치로 바꾼다는 관점을 담고 있다.
- 연사 징 왕은 뱅가드 CAI를 이끈다. 이 조직은 AI·머신러닝·생성형 AI·행동과학 역량을 맡아 전사 차원의 혁신·연구·딜리버리를 추진한다.
아직 불확실한 것
- 뱅가드가 실제로 어떤 데이터 플랫폼, 모델, 개발 도구를 쓰는지는 세션 소개글에 나오지 않는다.
- 에이전트형 시스템을 어떤 업무에 어느 정도의 자율성으로 적용했는지는 확인되지 않는다.
- 거버넌스 절차가 구체적으로 어떻게 짜여 있는지, 기반을 갖춘 뒤 어떤 성과가 났는지는 소개글로는 알 수 없다.
- 규제 체계가 다른 국내 금융사에도 이 방식이 그대로 통할지는 판단하기 어렵다.
다섯 문항으로 AI 기반의 가장 약한 고리 찾기
다섯 요소를 한꺼번에 완벽하게 갖추려 하면 오히려 아무것도 시작하지 못하기 쉽다. 현실적인 순서는 따로 있다. 지금 상태를 솔직하게 진단하고 가장 약한 고리부터 보강하는 것이다.
- 데이터: 다음 AI 프로젝트에 필요한 데이터를 정해진 승인만 거치면 바로 꺼내 쓸 수 있는가?
- 엔지니어링: 운영 중인 AI 기능의 성능이 떨어지면 누군가 알아챌 장치가 있는가?
- 플랫폼: 새 프로젝트를 시작할 때 다시 쓸 수 있는 공용 도구가 있는가?
- 운영 모델: AI 기능 하나를 골라 ‘이건 누구 책임인가?’라고 물으면 바로 답이 나오는가?
- 거버넌스: 새 AI 사용 사례가 생겼을 때 위험도를 판단할 기준표가 있는가?
문항마다 ‘있다 / 일부 있다 / 없다’만 표시해도 어디가 비었는지 꽤 선명하게 보인다. ‘없다’가 나온 항목을 별도의 대형 과제로 떼어 낼 필요는 없다. 다음 프로젝트에서 함께 풀 과제로 묶는 편이 현실적이다. 새 사용 사례 하나를 진행하면서 만든 권한 관리나 평가 도구를 공용 플랫폼에 남기는 식이다. 규제가 강한 업종이라면 거버넌스 문항부터 채워야 이후 속도를 지킬 수 있다고 본다. 확장 가능한 AI인지는 화려한 첫 데모에서 드러나지 않는다. 두 번째, 세 번째 프로젝트가 첫 번째보다 빨라지는지를 봐야 한다. 방향을 가늠하는 잣대로는 이쪽이 더 정확하다.
