AX 하기 전에 DX부터: 리더가 지금 점검해야 할 세 가지

에이전트, 자동화, AX 같은 키워드가 쏟아지지만, 막상 현장에서 "우리 조직은 AI를 제대로 쓰고 있는가"라는 질문에 자신 있게 답하는 리더는 많지 않습니다. 툴은 도입했는데 데이터는 꺼낼 수 없고, 보고서는 여전히 데이터 팀에 요청해야 하며, 조직이 커질수록 사일로는 깊어집니다. 최근 열린 한 발표에서, B2B SaaS 채널톡을 만드는 채널코퍼레이션의 사업개발 리드 문희철 님이 이 문제를 '극단적 경영 가시성'이라는 개념으로 풀어냈습니다. 

특정 툴에 종속되지 않는 데이터 주권, 데이터가 흐르는 IT 인프라, 그리고 AI의 역할 범위를 설계하는 사람과 조직. 이 세 가지 관점을 중심으로, 빅쿼리 기반 데이터 웨어하우스 구축부터 MCP로 연결한 엔터프라이즈 영업 에이전트 설계까지 실제 실험 사례를 함께 공유했는데요. AX 이전에 무엇을 먼저 점검해야 하는지 고민하는분들께 참고가 되실 겁니다.

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

안녕하세요, 채널톡을 만드는 채널코퍼레이션의 사업개발 리드 문희철입니다. 오늘 말씀드리고 싶은 주제는 "극단적 경영 가시성"입니다. 하나하나 단어의 의미를 정의하면서 쌓아가는 방식으로 이야기하겠습니다.

예를 하나 들겠습니다. 리테일 기업에 물류 창고가 있습니다. 창고에 과일이 있는데, 그 과일이 썩었습니다. 그런데 이미 박스 단위, 트럭 단위로 팔려 나갔습니다. 오너는 이 일을 모릅니다. 리테일과 F&B를 다루는 곳에서 이런 케이스는 실제로 빈번했고, 이것은 곧 큰 경영 리스크가 됩니다.

우리의 고객이 지금 어떤 상태인지, 우리 조직은 어떻게 움직이고 있는지, 매출과 비용은 어떻게 쓰이고 있는지. 세일즈든 파이낸스든 비용이든, 조직의 모든 디비전과 모든 하이어라키에서 목적에 부합하게 즉시, 충분히 알 수 있는 상태. 저는 이것을 극단적 경영 가시성이라고 정의하겠습니다.

그런데 왜 이게 어려웠을까요. 경영에 필요한 매출, 비용, 고객 행동, 그리고 이를 가공해 만든 보고서. 이런 데이터의 축적 자체가 어려웠습니다. 파편화돼 있었고요. IT 인프라와 소프트웨어, ERP를 포함해서 데이터를 입력하는 것도 어려웠고, 출력은 더 어려웠습니다. 출력할 때마다 우리는 데이터 팀에 물어봅니다. "이번 달 매출 데이터 좀 뽑을 수 없을까요?" "인천 지역에 이상징후가 있을까요?" 현지 창고 관계자한테 물어보거나, 데이터 담당자들한테 일일이 확인해야 합니다. 이 과정에서 하루가 일주일이 되고, 한 달이 금방 갑니다.

그리고 이걸 활용하는 사람들은 툴 기반 사고에 갇혀 있습니다. "세일즈포스가 최고야", "SAP이 너무 좋아." 물론 좋겠죠. 하지만 모든 문제를 해결할 수는 없습니다. 조직이 커질수록 사일로는 심화되고, 탑과 바텀의 지식·정보 차이도 커집니다.

이 문제를 풀기 위해서는 세 가지 축에 대한 관점이 필요합니다. 

• AI를 바라보는 관점
• 데이터가 흐를 수 있는 IT 인프라
• 그리고 이것을 실행하는 사람과 조직

 이 세 가지를 하나씩 말씀드리겠습니다.

AI 도입 전, 데이터 주권과 일의 정의가 먼저다

툴이 아니라 데이터가 먼저다

첫 번째 관점, AI에 대한 이야기를 하겠습니다. 먼저 특정 솔루션에 갇히지 말아야 합니다. 채널톡에 갇히지 마시고, 세일즈포스에 갇히지도 마세요. 특정 소프트웨어를 도입하면 그 안에 데이터가 축적되고, 결국 해당 소프트웨어에 대한 데이터 디펜던시(의존성)가 형성됩니다. 저희 같은 B2B SaaS 회사 입장에서는 그것이 오히려 유리한 구조이기도 합니다. 하지만 기업 경영의 관점에서 진정으로 중요한 것은 자사가 직접 통제할 수 있는 데이터를 확보하고 있느냐입니다.

데이터를 통제한다는 것은 이 세 가지 조건을 충족하는 것입니다. 첫째, 비즈니스에 관련된 모든 데이터를 자사가 보유하고 있을 것. 둘째, 그 데이터를 통해 어떤 의사결정을 내려야 하는지 알고 있을 것. 셋째, 데이터 간의 연결이 가능할 것. 이 세 가지가 AI 활용의 출발점입니다.

AI를 못 쓰는 진짜 이유: 일의 과정이 정의되지 않았다 

그런데 데이터를 보유하고 연결할 수 있다 해도, 그것으로 무슨 일을 해야 하는지 정의되지 않으면 의미가 없습니다. 여기서 저한테 큰 영감을 주신 분의 인사이트를 하나 공유하겠습니다. 그 분은 이렇게 말씀하셨어요. "딸깍에 이르는 과정은 딸깍이 아니다." 그리고 "모든 일의 과정에는 인풋(투입), 트랜스폼(변환), 아웃풋(산출물)이 있다." 단순하지만 핵심을 찌르는 정의였습니다.

모든 일은 투입과 변환과 산출의 과정입니다. 리소스와 시간과 사람과 데이터를 투입하고, 모종의 과정을 거쳐 변환하고, 산출물이 나옵니다. 데스크 리서치를 수행하든, 사람을 직접 만나 휴민트를 확보하든, 구조는 동일합니다.

문제는 이 구조가 대부분의 조직에서 정의되어 있지 않다는 점입니다. AI에게 일을 위임하기 전에, 자기 조직이 무슨 일을 하고 있는지, 어떤 목적을 추구하는지 파악하지 못하고 있습니다. 자기가 어떻게 효과적으로 일하고 있는지 모르면, 그 일을 다른 주체에게 시킬 수가 없습니다. 일이란 어떤 목적을 이루기 위해 전방 업무, 중간 업무, 후처리 업무가 연결된 것인데, 그 연결 구조 자체를 파악하지 못하고 있는 겁니다. AI를 잘 활용하지 못하는 근본적인 이유가 여기에 있습니다.

그래서 우리는 잘 작동하고 있는 일들을 리버스 엔지니어링해야 합니다. 카페24 사례를 들겠습니다. 카페24 pro라는 ‘자사몰 생성 - 판매 - 운영 모두 자동화’하는 인상적인 기획이 있습니다. 쉽게 말하면 "제품만 있으면 알아서 팔아줄게"라는 것인데요. 주목할 점은 자사몰 하나를 구축하기 위해 900개가 넘는 세부 태스크가 존재한다는 것을 정의해냈다는 겁니다. 기획자들은 그 태스크들을 하나하나 정의하고, 사람이 반드시 수행하지 않아도 되는 항목을 분리한 뒤, 최대한 AI를 통해 자동화했습니다. 하지만 딸깍은 없었습니다. 900개의 태스크를 정의하는 과정 자체가 딸깍이 아니었던 겁니다.

AI가 유효한 데이터에 접근하여 생성, 조회, 수정, 삭제를 수행할 수 있다면, 사람이 담당했던 단순 반복 업무는 대부분 대체될 것입니다. 물론 이상적인 상태입니다. 하지만 그 이상에 도달하려면 변환과 가공의 과정에 매몰되지 말고, 지금 우리가 무엇을 원하는지 목적을 명확히 해야 합니다. 목적을 해석하고 변환하는 것은 AI의 영역입니다. 우리는 어떤 데이터로 어떤 목적을 추구할 것인지만 정의하면 됩니다.

데이터 파이프라인이 먼저다

두 번째 관점, IT 인프라에 대한 이야기입니다. 앞서 데이터 주권의 중요성을 말씀드렸는데, 현실에서는 그 주권이 확보되지 않은 상태에서 솔루션부터 도입하는 경우가 많습니다.

IT를 담당하시는 분들이라면 익숙한 장면일 겁니다. 어떤 팀에서 이런 이야기를 합니다. "이 솔루션 도입하면 잘 될 것 같은데요. 성공 사례가 이렇다는데요." 물론 좋을 수 있습니다. 하지만 앞에서 말씀드린 문제가 여기서 구체적으로 발생합니다. 솔루션 안에 데이터가 쌓이기 시작하면, 그 데이터를 꺼내 쓰는 것 자체가 어려워집니다.

실제 사례를 들겠습니다. 어떤 CX 솔루션을 사용하고 있는데, 데이터를 요청하니 API가 없습니다. 요청을 넣으면 2~3주 후에 전달되거나, 데이터 로우가 깨진 상태로 넘어옵니다. 또 다른 경우, 고객의 구독 정보와 렌탈 정보가 특정 ERP에 있는데 자사에서 직접 접근하거나 유지보수할 수가 없습니다. 해당 ERP 업체에 요청하면 CSV나 엑셀 파일로 월 1회 전달해줍니다. 담당자가 부재하면 그마저도 지연됩니다. 이런 상태에서는 AI가 접근할 수 있는 데이터 자체가 존재하지 않는 셈입니다.

그렇기 때문에 툴 중심으로 흩어져 있는 데이터 사일로를 해체해야 합니다. 핵심은 데이터가 흐르는 구조를 만드는 것입니다.

이를 위해서는 하나의 원천, 소스 오브 트루스(Source of Truth)가 필요합니다. 데이터레이크라고도 합니다. 채널톡에 쌓인 데이터, 세일즈포스의 데이터, SAP의 데이터, 오라클의 데이터를 한곳으로 가져와 가공할 수 있어야 합니다. 중심은 소프트웨어가 아니라 데이터 그 자체입니다.

저희 채널코퍼레이션에서는 이 원칙에 따라 데이터 웨어하우스를 구축하기 시작했습니다. 회사 내 경영 관련 데이터를 하나로 통합하자는 것이 출발점이었습니다. 시장에는 데이터브릭스, 스노플레이크, 구글 빅쿼리 등 여러 선택지가 있었는데, 저희는 비용이 가장 낮고 수작업이 많이 수반되는 빅쿼리를 선택했습니다. 그리고 LLM이 데이터를 효과적으로 읽을 수 있도록, 각 데이터 필드의 의미와 맥락을 주석으로 기록했습니다. 이 작업을 반복한 결과, 단순 쿼리 요청을 데이터 팀에 의뢰하지 않아도 되는 환경이 만들어졌습니다. LLM이 데이터 웨어하우스를 직접 읽을 수 있게 된 겁니다.

데이터 소스는 세일즈, 매출, 비용, 고객 등 다양하며, 웨어하우스에 적재된 데이터를 AI 어시스턴트가 호출하는 방식입니다. 비용 분석, 매출 분석, 고객 분석은 물론이고, 내부 이슈에 대한 정성적 분석까지 수행합니다. 

예를 들어 "특정 고객사의 MRR(월간 반복 매출) 추이를 알려달라"고 요청하면, AI 어시스턴트가 데이터를 기반으로 차트를 생성해 제시합니다. "이 고객사에 헨리라는 분이 기여한 매출이 얼마나 되는지 알려달라"고 이어서 질문하면, 로우 데이터까지 참조해 구체적인 숫자를 찾아줍니다. "채널톡 상위 100개 고객사를 차트로 만들어달라"는 요청에도, "원형으로 만들어달라", "3D로 바꿔줄 수 있느냐"는 후속 요청까지 자연어 대화만으로 모두 처리됩니다.

생성된 결과물은 팀 메신저로 자동 전달되고, 구성원들은 링크를 따라 들어가 확인한 뒤 논의를 이어갑니다. 자연어로 질문하면 되기 때문에 별도의 학습 비용이 거의 들지 않습니다. 저도 이 데모를 세미나 직전 오후 4시쯤에 가볍게 요청해본 것이었는데, 그 수준의 결과물이 즉시 나올 만큼 일상적인 도구가 되어 있습니다.

한 가지 강조하겠습니다. 저희가 어떤 애플리케이션을 사용했는지는 중요하지 않습니다. 데이터 원장에 접근할 수 있다면, MCP와 같은 연결 표준이 이미 존재하기 때문에 어떤 앱이든 연결하여 활용할 수 있습니다. 앱은 상황에 맞는 것을 선택하면 됩니다. 진짜 중요한 것은 앱이 아니라 데이터 파이프라인입니다. 목적이 정의되고 데이터에 접근할 수 있으면, 산출물 도출은 빠릅니다.

AI 에이전트의 역할 범위 설계: 감지, 실행, 연결

세 번째는 사람에 대한 관점입니다. 앞에서 일의 정의 이야기를 했는데, 결국 같은 맥락입니다. AI를 활용하는 우리 조직이, 오너가, 나 자신이 어떤 데이터를 활용해서 어떤 결과물을 만들어내는지 알아야 합니다. 그 위에서 AI의 역할을 어디까지 부여할 것인지를 설계해야 합니다.

가장 수동적인 단계는 감지입니다. 이상 데이터를 감지하는 것, 예를 들어 특정 패턴에서 이상징후가 발견됐다는 것을 알려주는 수준입니다. 여기까지만 돼도 의미가 있습니다. 

두 번째는 위임된 범위 안에서의 실행입니다. 이메일을 보내는 등 사람 대신 특정 액션을 수행하는 것. 사람이 판단한 범위 안에서 AI가 직접 움직이는 겁니다.

세 번째는 적절한 의사결정권자에게 연결하는 것입니다. 지금 문제 상황이 이렇고, 이슈는 이런데, 제안은 이렇습니다. A, B, C 선택지 중 어떻게 하시겠습니까. AI가 여기까지 해줄 수 있다면, 조직의 의사결정 속도는 근본적으로 달라집니다.

실제로 저희 CX팀은 이 원칙에 따라 움직이고 있습니다. 채널톡의 오픈 API를 통해 고객 응대 데이터가 축적돼 있고, 거기서 데이터를 가져와 후처리하거나, 반복되는 형태의 업무는 자체적으로 버티컬 앱을 만들어 처리합니다. 단순 반복 업무는 거의 사라졌습니다. 보안도 고려했습니다. 해당 앱에는 사내 VPN에서만 접근이 가능하도록 설계해두었습니다. 별도의 대규모 개발 프로젝트가 아니라, 목적 조직이 자기 업무의 범위와 권한을 정의하고, 그 안에서 AI의 역할을 직접 설계한 결과입니다.

이 세 단계를 조직 안에서 설계하는 게 핵심입니다. 데이터를 얼마나 열어줄 것인지, CRUD(Create 생성, Read 조회, Update 수정, Delete 삭제)의 어디까지 허용할 것인지를 용도와 권한에 따라 나눠야 합니다.

앞서 말씀드린 세 가지 전제를 다시 정리하겠습니다. AI에 대한 관점, 데이터가 흐르는 IT 인프라에 대한 관점, 그리고 이것을 활용하는 사람에 대한 관점. 이 세 가지가 갖춰졌을 때 비로소 구체적인 것을 만들 수 있습니다.

채널 코퍼레이션의 엔터프라이즈 영업 AI 구축 사례

저희 채널코퍼레이션에서 실제로 했던 이야기를 하겠습니다. 채널톡이 아니라, 채널톡을 제공하는 채널코퍼레이션의 이야기입니다.

저희 사업개발 팀은 목적 조직입니다. 전사적으로 세일즈 관점에서 엔터프라이즈 시장을 제대로 파고들자는 목적이 있었습니다. 그런데 우리 원장 데이터에 유의미한 것이 없었습니다. '딸깍'하고 싶어도 AI가 참조할 데이터 자체가 없었던 것이죠.

데이터가 없다면, AI에게 학습시킬 판단 로직부터 확보해야 했습니다. 그래서 먼저 사람에게 물어보기로 했습니다. 대기업과 외국계에서 영업 기획을 담당하시는 분들 중에서도 정말 탑이라 불리는 분들을 찾아가, "몇천억, 몇백억 규모의 매출을 어떻게 만드십니까"를 직접 여쭤봤습니다.

답변은 이랬습니다. 과거에 수주했거나 실주했던 히스토리, 갱신 여부 등을 종합해서 가중치를 매긴 뒤 일정 기준 이상의 건을 선별한다. 영업사원 한 명의 연봉 대비 몇 배수 이상의 ROI가 나와야 하는데, 모든 건을 다룰 수는 없기 때문에 우선순위를 정한다. 본질은 그게 전부라는 것이었습니다.

여기서 중요한 깨달음이 있었습니다. 이 접근을 AI 에이전트가 수행할 수 있도록 설계하면 되겠다는 것이었습니다.

그 다음으로 한 일은 유토피아를 정의하는 것이었습니다. 실현 가능성과 무관하게, 구현된다면 이상적일 방향을 먼저 그려보는 작업입니다. 크게 보면 필요한 데이터 소스는 세 가지였습니다. 첫째, 데스크 리서치로 확보할 수 있는 공개 정보. 둘째, 휴민트. 사람을 통해서만 얻을 수 있는 정보로, 비용이 가장 큰 영역입니다. 셋째, 우리 내부 데이터 웨어하우스에 축적된 데이터. 이 세 가지를 모아 정제하고 에이전트에 연결할 수 있다면, 앞서 영업 기획 임원이 말씀해주신 기준에 따라 우선순위와 전략을 도출할 수 있겠다는 큰 로직을 설계했습니다. 여기까지의 과정에 기술적인 이야기는 하나도 포함되지 않았습니다.

이후에는 본격적인 노가다 단계로 들어갑니다. 결국 가장 효과적인 방법은 ‘트라이얼 앤 에러(trial and error)’입니다. 산업공학이나 경영을 공부하신 분들은 아시겠지만, 최적해를 찾는 방법 중 가장 상위에 있는 것이 시행착오법입니다. 쉽게 말해 직접 부딪히며 패턴을 찾는 접근입니다.

저희는 고객사 중 가장 성공적이었던 탑 케이스를 전부 분해해봤습니다. 피터 드러커의 "뜻밖의 성공에 집중하라"는 원칙에 따라, 그 성공을 복제하고 재연하기 위해 원장 데이터를 분석하기 시작했습니다. 이 과정에서 데이터가 어떤 방식으로 축적되어야 하는지, 성공의 이면에 어떤 요인이 작동했는지를 체득하게 됐습니다.

그런데 데이터베이스에서 찾을 수 없는 정보도 있었습니다. 형지패션그룹을 예로 들어보겠습니다. 큰 지주사 형태의 그룹으로, 산하에 여러 계열사와 브랜드가 있고, 일부는 채널톡을 사용하고 일부는 사용하지 않습니다. 우리가 여기서 그룹 산하의 작은 브랜드 하나만 바라보면, 그룹 전체에 대한 매핑 지도를 그릴 수 없습니다. 영업 CRM에 길들여진 사고방식은 "저기 웹사이트가 있네, 저 브랜드를 공략해야겠다"는 방향으로 접근합니다. "형지패션그룹이라는 법인 단위로 전체 영업 계획을 설계하자"는 관점으로는 잘 넘어가지 못합니다. 이것이 툴을 잘못 도입했을 때의 위험입니다. 툴을 익힌다는 건 그 툴이 강요하는 사고방식을 내면화하는 일이기 때문입니다.

그래서 법인 단위 전체로 영업을 전개에 유용한 설계와 실험을 시작했습니다. 우리 팀원들의 리멤버 데이터를 CSV로 다운로드하고, 전사적으로 쓰는 세일즈포스 원장 데이터에 영향을 주지 않도록 (또 다른 영업 CRM 툴인) 에어테이블을 팀용으로 별도 구독한 뒤 그곳에 전부 넣어봤습니다. 솔직히 저는 에어테이블을 다룰 줄 모릅니다. 그런데 팀원이 초안을 만들고, 클로드에 MCP 접근 권한을 부여하니 테이블 구조를 알아서 설계해주더라고요.

한 가지 실험을 더 진행했습니다. 영업 CRM에 일일이 수기로 입력하는 방식이 비효율적이었기 때문에, 고객을 만나고 돌아온 뒤 그날의 대화 내용을 자연어로 클로드에 전달해봤습니다. 그러자 해당 내용에 맞는 필드를 스스로 구성해 입력해두는 모습을 확인했습니다. 혹시 음성으로도 가능할까 싶어 직접 말로 전달해보았고, 동일하게 작동했습니다. 데이터의 축적과 출력이 자동화되는 시대가 이미 현실이 되고 있다는 것을 체감한 순간이었습니다.

그렇다면 각 팀, 각 기능 조직이 자기 목적에 맞는 도구를 직접 만들어 쓸 수 있겠다는 생각이 들었습니다. 실제로 저희 사업개발 팀원이 앱을 하나 만들었는데, 솔직히 말씀드리면 그 앱 자체는 반드시 필요하지 않습니다. 클로드에 직접 물어봐도 동일한 결과를 얻을 수 있기 때문입니다. 앱이라는 도구적 프레임에 갇힐 필요가 없다는 점을, 이 실험을 통해 다시 한번 확인하게 됐습니다.

AX를 위한 DX, 리더가 지금 해야 할 일

지금까지 AI로 극단적 경영 가시성을 만들기 위한 세 가지 관점을 말씀드렸습니다. AI에 대한 관점, IT 인프라에 대한 관점, 그리고 이것을 활용하는 사람에 대한 관점. 이 관점들이 통합됐을 때, 리더는 AI를 통한 변화 관리와 혁신을 만들어낼 수 있습니다.

그런데 채널 팀이 앞선 AX 실험을 빠르게 실행할 수 있었던 배경이 있습니다. 저희의 환경은 중견이나 대기업 환경과는 다릅니다.  저희는 원래부터 SI를 하지 않았고, 온프레미스를 쓰지 않았습니다. 처음부터 AWS 퍼블릭 클라우드 기반으로 채널톡을 만들었고, 오픈 API를 운영해왔습니다. 그 환경이 있었기 때문에 빠르게 움직일 수 있었던 겁니다.

달리 말하면, 지금 해야 하는 건 AX일 수도 있지만, AX를 위한 DX가 먼저입니다. 예를 들어 저는 먼저 기존 온프레미스에 구축했던 데이터는 지금 어디에 있고, 어떻게 활용되고 있는지 묻고 싶습니다. 보통 이렇게 답하십니다. "데이터 많이 갖고 있어요." 다시 여쭤보겠습니다. “그 데이터를 극단적 경영 가시성을 위해, AI를 통해 지금 활용이 가능하십니까.” 대부분 안 될 겁니다.

30년치 데이터가 있다면, 좋은 겁니다. 하지만 그 데이터가 그 자체로 가치를 갖지는 않습니다. 사금을 캐고, 흔들고, 녹여야 금이 됩니다.

투입과 변환과 산출이라는 일의 전체 과정에서 봤을 때, 기획과 산출물 가공에 들어가는 시간은 체감상 30% 수준으로 줄었습니다. 그리고 그 시간에 저는 고객을 더 만나게 됐습니다. AI가 하지 못하는 일, 사람을 만나는 일에 집중할 수 있게 된 겁니다.

결국 돌아오는 건 같은 이야기입니다. AI에 대한 관점, IT 인프라에 대한 관점, 그리고 목적 조직의 사람에 대한 관점. 이 세 가지가 정립돼야 합니다. 감사합니다.

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