AI 기반 개발로 인해 CTO와 사내 엔지니어들이 '내부 SI 업체'로 전락하고 있는가?

이전 글에서 저는 AI 요구사항 정의의 현재 상태, 즉 프로세스가 '정리'에서 '결정'으로 변화하고 있으며, 많은 현장에서 이러한 변화를 인지하지 못한 채 무분별하게 사고를 위탁하고 있다는 우려에 대해 이야기했습니다.

이번에는 이와 관련된 또 다른 경고를 울리려고 합니다.

문제는 CTO와 내부 SE가 AI 기반 개발로 인해 코드를 매우 빠르게 작성할 수 있게 되면서, 단순히 사업 부문의 주문을 받는 '내부 SIer'로 전락하고 있다는 점입니다.

AI 기반 개발이 만들어낸 새로운 역학

AI 기반 개발의 확산이 코딩의 장벽을 극적으로 낮춘 것은 부인할 수 없는 사실입니다.

그 결과, '이런 걸 원해요', '이걸 시스템화하고 싶어요'와 같은 사업 부문의 요청이 예전과 비교할 수 없을 정도로 빠른 속도로 들어오고 있습니다. 사업 담당자들이 AI를 이용해 직접 요구사항을 정리하거나, 심지어 프로토타입을 만드는 일도 드물지 않습니다.

언뜻 보면 좋은 현상처럼 보입니다. 사업 부문이 DX를 주도하고 IT와 협력하여 시스템을 신속하게 구축하는 이상적인 시나리오처럼 보입니다.

하지만 여기에는 함정이 있습니다.

점점 더 많은 CTO와 내부 SE가 '사업 부문의 요청을 단순히 구체화하는 사람'이 되고 있다고 느낍니다. 요청을 받아 기술적으로 구현하고 전달합니다. 이것이 바로 내부 SIer가 하는 일입니다.

주문 수령의 끝에 기다리는 것

사업 요청에 응답하는 것 자체가 잘못된 것은 아닙니다. 문제는 각 부서의 요청을 있는 그대로 계속해서 이행할 때 어떤 일이 발생하는지입니다.

저는 이것을 '표류 시스템(stray system)'과 '표류 데이터베이스(stray database)'의 확산이라고 부릅니다.

영업 부서는 자체 CRM을 만들고, 마케팅 부서는 별도의 데이터 분석 플랫폼을 구축하며, 고객 지원 부서는 자체 티켓 관리를 만듭니다. 각 부서는 자신들의 업무에 최적화된 시스템을 빠르게 얻었기 때문에 만족합니다.

하지만 회사 전체로는 어떨까요?

데이터는 여러 곳에 흩어져 있고, 형식은 통일되지 않았습니다. 동일한 고객 정보가 여러 데이터베이스에 다른 형태로 존재합니다. 부서 간 데이터를 연동하려고 할 때마다 수동 작업이나 맞춤 개발이 필요합니다.

이것이 바로 기술 사일로(technical silo) 입니다.

AI 기반 개발이 시스템 구축을 매우 쉽게 만들었기 때문에, 이러한 사일로화는 전례 없는 속도로 진행됩니다. 이전에는 높은 개발 비용이 자연스러운 제동 장치 역할을 했습니다. '만들기 어려우니 정말 필요한 것만 엄격하게 선택하자'는 역학이 있었습니다.

이제 그 제동 장치는 사라졌습니다. 만들 수 있기 때문에 만들어집니다. 그 결과, 표류 시스템과 데이터베이스가 늘어나고 관리해야 할 앱과 인프라의 수가 계속해서 증가합니다.

AI 시대에 이것이 치명적인 이유

'시스템이 조금 흩어져 있어도 작동만 하면 괜찮지 않을까'라고 생각할 수도 있습니다. 그러나 AI 시대에는 이러한 사일로화가 그 어느 때보다 더 치명적인 문제를 야기합니다.

그 이유는 간단합니다. AI의 가치는 데이터 통합의 정도에 비례하기 때문입니다.

AI는 전사적으로 데이터가 통합되어 부서를 아우르는 인사이트를 제공할 때 진정한 힘을 발휘합니다. 영업 데이터, 고객 이력, 마케팅 효과, 재무 데이터가 통합되어야 AI는 경영 의사 결정을 지원하는 인사이트를 제공할 수 있습니다.

표류 시스템으로 가득한 환경에서는 데이터가 처음부터 연결되어 있지 않습니다. 부서 내에서 소규모 AI 최적화를 달성할 수는 있겠지만, 실제로 비즈니스 영향을 미치는 전사적 AI 활용에는 절대 도달할 수 없습니다.

부서별 최적화를 축적함으로써 전체 최적화를 영원히 잃게 됩니다. 이것이 주문을 받는 CTO와 내부 SE가 무의식적으로 만들어내는 위험입니다.

CTO와 내부 SE가 수행해야 할 진정한 역할

그렇다면 CTO와 내부 SE는 어떻게 해야 할까요?

답은 분명합니다. 단순한 '구축자'가 아닌 '설계자이자 결정자'가 되는 것입니다.

여기서 '설계'는 개별 시스템을 설계하는 것을 의미하지 않습니다. 회사 전체를 위한 데이터 및 시스템 아키텍처를 설계하는 것을 의미합니다.

사업 부문에서 요청이 들어오면, 단순히 구축하는 대신 '이 요청이 전사 아키텍처 내에서 어떻게 위치해야 하는지'를 판단해야 합니다. 어떤 경우에는 '이것은 개별적으로 구축해서는 안 된다'고 말할 수 있어야 합니다. 기존 플랫폼을 확장하여 처리할 수 있다면 그쪽으로 안내해야 합니다.

이는 사업 부문에 불편하게 느껴질 수 있습니다. '지금 이걸 만들라고 한 것뿐인데, 왜 회사 전체 이야기를 하느냐'고 물을 수도 있습니다.

하지만 이러한 판단을 내릴 수 있는 것은 오직 CTO와 내부 SE뿐입니다. 사업 부문은 자신의 영역을 최적화할 유인은 있지만, 전사 아키텍처를 보호할 유인은 없습니다. 따라서 기술 전문가가 총체적 최적화의 수호자 역할을 해야 합니다.

'구축하지 않기로 하는 결정'이 최고의 기술이다

역설적이게도, AI 시대에 CTO와 내부 SE에게 요구되는 가장 중요한 능력은 '구축하지 않기로 하는 결정'일지도 모릅니다. 이것이 제가 그들을 '결정자'라고 부르는 이유입니다.

사업 부문에서 요청이 들어옵니다. 기술적으로 가능합니다. AI를 사용하면 며칠 안에 구체화할 수 있습니다. 하지만 이 요청을 구축하는 것이 정말로 회사 전체에 올바른 일인지 의문을 제기할 수 있는 힘을 가져야 합니다.

이 요청을 기존 플랫폼으로 처리할 수 있습니까? 데이터 구조가 회사 규칙에 부합합니까? 유사한 시스템이 다른 부서에서 이미 실행 중입니까? 개별적으로 최적화된 시스템을 추가하면 향후 데이터 통합이 어려워지지 않습니까?

이러한 질문을 할 수 있는 능력이 AI 시대의 진정한 기술력입니다.

AI가 코딩을 처리할 것입니다. 하지만 무엇을 구축하고 무엇을 구축하지 않을지 판단하는 것은 AI가 할 수 없는 일입니다. 앞서 '요구사항 정의는 결정의 과정이 될 것'이라고 말씀드린 것처럼, CTO와 내부 SE의 역할도 정확히 동일한 구조를 따릅니다.

주문을 받는 사람이 되기보다는, 전사 아키텍처의 설계자로서 당신의 역할은 AI 시대이기 때문에 더욱 중요해지고 있습니다.

미래를 예측할 수 없기에 '준비된 상태'를 만든다

'구축하지 않기로 하는 결정'의 중요성을 강조했지만, CTO와 내부 SE가 가져야 할 또 하나의 관점이 있습니다.

AI 시대에는 미래를 예측할 수 없기 때문에, 회사가 언제든지 움직일 수 있는 상태를 유지해야 합니다.

현재 'SaaS는 죽었다'는 담론이 확산되고 있습니다. 마이크로소프트 CEO 사티아 나델라가 2024년 말 이 말을 한 이후, 많은 사람들이 SaaS의 종말을 예측했습니다. 실제로 SaaS 기업의 가치 평가는 압박을 받고 있으며, 투자자의 관심은 AI 네이티브 플랫폼으로 빠르게 이동하고 있습니다.

하지만 SaaS가 정말로 죽어가고 있을까요?

저는 그렇게 단순하다고 생각하지 않습니다. SaaS 기업들은 AI 시대에 최적화된 소프트웨어 형태를 찾기 위해 R&D에 막대한 투자를 하고 있습니다. 에이전틱 AI 통합, 결과 기반 과금, 산업별 AI 플랫폼... 현재 우리가 상상할 수 없는 형태의 제품이 등장할 가능성이 높습니다.

즉, 'SaaS는 죽었다'고 결론짓고 내부 개발에 몰두하는 것과, 'SaaS면 충분하다'고 생각하며 사고를 멈추는 것, 둘 다 위험합니다.

CTO/내부 SE가 취해야 할 자세는 어느 한쪽에 베팅하는 것이 아닙니다. 상황이 어떻게 되든 대응할 수 있는 아키텍처를 설계하는 것입니다.

구체적으로는 데이터 보유 방식을 표준화하고 특정 SaaS나 도구에 종속되지 않는 구조를 만듭니다. 시스템 연결은 API를 통해 느슨하게 결합된 상태로 유지합니다. 표류 시스템이 확산되지 않도록 하고 회사의 데이터 기반을 통일합니다.

이러한 설계 철학을 바탕으로 하면, SaaS가 발전하여 더 나은 제품이 나오면 전환할 수 있습니다. 반대로 특정 영역에서 내부 구축이 더 낫다는 것이 명확해지면 그쪽으로 이전할 수 있습니다.

미래를 예측할 수는 없습니다. 하지만 미래에 대응할 수 있는 구조를 만들 수는 있습니다. 이것이 AI 시대에 CTO와 내부 SE에게 요구되는 아키텍처 설계의 본질입니다. 반대로 말하면, 기술 전문가만이 할 수 있는 일입니다. 여러분이 그 소중한 역량을 내부 SIer로서 소모하지 않길 바랍니다.