AI 파일럿은 성공했는데 추가로 AI를 확장한 곳은 13%뿐…병목은 AI모델이 아니라 '레가시 SW아키텍처'였다.
- 베어링포인트 조사: AI 도입 기업 74%가 성과 확인, 그러나 사업계획대로 확장한 곳은 13% - 확장 장벽 1·2위는 '복잡한 규제'와 '레거시 시스템 통합'…출시 전 확장성 평가하는 기업은 3분의 1 미만…
기업이 AI를 시험해 성과를 내는 일과 그 성과를 회사 전체로 넓히는 일은 전혀 다른 문제라는 점이 수치로 드러났다. IT 전문매체 테크타깃은 지난 7일(현지시간) 리즈 휴즈 기자의 기사 '확장하는 AI가 엔터프라이즈 아키텍처를 시험대에 올린다'에서, AI 파일럿은 한 팀이나 한 업무에서는 가치를 입증하지만 이를 넓히려는 순간 데이터, 레거시 연동, 신원·권한 관리, 인프라 같은 기업의 기반 기술이 받쳐주지 못하는 경우가 많다고 보도했다. 이 기사를 토대로 AI 도입의 다음 단계가 어디서 막히는지 짚어 본다.
"성과는 있는데, 계획대로 넓힌 곳은 열에 한 곳"
테크타깃이 인용한 베어링포인트(BearingPoint)의 조사가 문제의 크기를 보여준다. 경영·기술 컨설팅 업체인 베어링포인트가 지난 1일 공개한 이 조사는 지난 8월 임원급(C레벨)과 고위 리더 1,050명을 대상으로 한 설문에 기반한다. 테크타깃에 따르면 AI를 구현한 조직의 74%가 매출 또는 비용 측면에서 측정 가능한 성과가 있다고 답했다. 그러나 애초 사업계획에 맞게 AI 이니셔티브를 완전히 확장한 조직은 13%에 그쳤다.
성과를 낸 기업은 4분의 3에 가까운데 계획대로 넓힌 기업은 10%대 초반이라는 간극이 이번 기사의 핵심이다. 확장을 가로막는 장애물로는 복잡한 규제 체계와 레거시 시스템 통합이 가장 많이 꼽혔다. 또한 AI 이니셔티브를 시작하기 전에 확장성을 공식적으로 평가하는 조직은 3분의 1에도 못 미쳤다. 많은 기업이 일단 돌려 보고, 확장은 나중에 생각하는 순서로 움직이고 있다는 뜻이다.
어디서 금이 가는가…옴디아 "사일로, 업무별 맞춤 구축, 레거시·운영기술과의 약한 연결"
그렇다면 확장 단계에서 무엇이 깨지는가. 테크타깃은 옴디아(Omdia)의 리안 지에 쑤(Lian Jye Su) 수석 애널리스트의 설명을 전했다. 옴디아는 인포마 테크타깃의 한 부문이다. 쑤 애널리스트가 꼽은 대표적인 균열 지점은 사일로로 갈라진 데이터, 특정 업무에 맞춰 따로 만든 구축 방식, 레거시 IT와 운영기술(OT)과의 약한 연동, 그리고 거버넌스·관측성·비용 통제의 불일치다. 파일럿에서는 한 팀이 특정 데이터를 손으로 모아 맞춰 주면 돌아가던 것이, 회사 전체로 넓히면 데이터 출처가 제각각이고 권한 체계가 다르고 비용은 누가 감당하는지가 불분명해지는 상황으로 이어진다는 이야기다.
"AI 구현은 결국 소프트웨어 구현"
이 대목에서 가장 눈에 띄는 발언은 카네기멜런대 소프트웨어공학연구소(SEI)에서 인텔리전트 소프트웨어 시스템 공학 그룹의 기술 책임자를 맡고 있는 이펙 오즈카야(Ipek Ozkaya)의 말이다. 테크타깃에 따르면 오즈카야는 "결국 AI 구현은 소프트웨어 구현"이라고 말했다. 그는 소규모 배포에서는 감내할 수 있었던 레거시 문제와 기술부채가 규모가 커지면 더는 피할 수 없게 된다고 설명했다.
오즈카야는 의존성 관리가 부실할 때 나타나는 운영상의 위험도 짚었다. 테크타깃 기사에 따르면 그는 이런 문제가 "연쇄 장애, 예상치 못한 지연 급증, 조용히 숨어 있는 정확성 버그"로 나타날 수 있다고 경고했다. 모델이 아무리 뛰어나도, 그것을 둘러싼 시스템의 의존 관계가 엉켜 있으면 확장할수록 사고 위험이 커진다는 뜻이다.
사례: 리버티뮤추얼 "추상화는 레가시현대화(Modernization)의 대체재가 아니다"
기사는 구체적 사례로 미국 보험사 리버티뮤추얼(Liberty Mutual)을 소개했다. 이 회사의 글로벌 엔지니어링 역량 책임자이자 리버티 IT 상무인 토니 마론(Tony Marron)은 핵심 시스템의 기능을 새로운 기술에 열어 주기 위해 추상화 계층과 API를 활용한다고 설명했다. 테크타깃에 따르면 이 회사의 자동차보험 견적은 챗GPT 앱을 통해서도 받을 수 있는데, 이 앱은 이미 API로 노출해 둔 견적 기능에 연결되는 방식이었다. 레거시를 통째로 뜯어고치지 않고 AI 서비스와 이어 붙인 사례다.
그러나 마론은 한계도 분명히 했다. 그는 추상화가 유연성을 주지만 "추상화가 레거시 재구축을 대신할 수는 없으며, 둘은 함께 가야 한다"고 말했다. 리버티뮤추얼은 신원 관리, 보안, 평가, 관측성, 데이터 접근 같은 공통 역량을 구축하고 있으며, 그렇게 하면 한 구현에서 얻은 교훈이 다음 구현으로 이어진다고 테크타깃은 전했다.
언제 API로 충분하고, 언제 뜯어고쳐야 하나?
기사는 현대화 결정이 용도에 달려 있다고 정리했다. 오즈카야는 판단 요소로 버그와 보안 이슈의 빈도, 유지보수 부담, API 노출 여부, 데이터 의존성, 비용을 제시했다. 쑤 애널리스트는 데이터를 읽거나 의사결정을 지원하는 용도라면 API로 충분할 수 있지만, 1초 미만의 응답 속도가 필요하거나 트랜잭션을 되쓰는(write-back) 작업, 대용량 데이터 이동이 필요한 경우에는 현대화가 필요할 수 있다고 설명했다.
테크타깃은 확장 전에 점검할 다섯 가지 영역으로 데이터와 맥락, 통합, 신원과 권한, 성능, 운영을 꼽으며, 확장성을 성공 뒤에 발견하는 현대화 문제가 아니라 처음부터 아키텍처의 질문으로 다뤄야 한다고 결론지었다.
AI의 병목은 모델에서 구조로 옮겨갔다
이상은 테크타깃 보도의 요약이다. 아래는 크리스미디어의 해석이다.
첫째, 이번 조사는 AI 경쟁의 무게중심이 모델 성능에서 기업 소프트웨어 아키텍처로 옮겨가고 있다는 흐름을 수치로 뒷받침한다. 크리스미디어는 앞서 모델 자체의 경쟁 의미가 옅어지고 그 지능으로 무엇을 설계하느냐가 승부처라는 흐름을 보도했다. 성과를 내는 기업이 74%인데 계획대로 확장한 곳이 13%라는 간극은, 모델은 이미 충분하지만 그것을 받쳐줄 아키텍처는 아직 준비되지 않았다는 방증으로 읽힌다.
둘째, 오즈카야의 "AI 구현은 소프트웨어 구현"이라는 말은 이 지면의 '크리스의 SW아키텍처' 연재가 줄곧 강조해온 문제의식과 같은 방향이다. 레거시와 기술부채는 AI를 얹는다고 사라지지 않고, 확장 단계에서 청구서로 돌아온다. 앞서 크리스미디어가 보도한 'AI 예산이 오히려 낡은 시스템 유지에 쓰이는 역설'과도 같은 맥락이다.
셋째, 리버티뮤추얼 사례는 현실적인 절충을 보여준다. 이미 현대화해 API로 열어둔 기능은 AI 앱과 곧바로 연결되지만, 그렇지 못한 기능은 같은 속도로 붙일 수 없다. 추상화로 시간을 벌되 현대화를 병행하라는 마론의 말은, 레거시 재구축 비용이 큰 기업에 '전면 교체 아니면 방치'가 아닌 단계적 경로가 있음을 시사한다. 다만 이 사례는 한 보험사의 경험이므로, 모든 산업에 그대로 일반화하기는 어렵다.
넷째, 확장성을 사전에 평가하는 기업이 3분의 1 미만이라는 대목은 의미심장하다. 파일럿의 성공이 곧 전사 확장의 준비 상태를 뜻하지 않는다는 점을 이 수치가 보여준다. 확장을 고려해 신원·권한, 관측성, 비용 통제 같은 공통 기반을 먼저 설계하는 조직과 그렇지 않은 조직 사이의 격차가 앞으로 벌어질 가능성이 있다. 이는 전망일 뿐 조사가 직접 밝힌 결론은 아니다.
출처
Liz Hughes, "Scaling AI puts enterprise architecture to the test", TechTarget IT Strategy, 2026년 10월 7일 ( https://www.techtarget.com/it-strategy/news/366651832/Scaling-AI-puts-enterprise-architecture-to-the-test )
베어링포인트 조사(2026년 10월 1일 공개, 8월 설문): 테크타깃 보도를 통해 인용
크리스미디어 기존 보도(모델 경쟁 의미 약화, 레거시 지출 역설)
본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)