우리 기업에 AX를 도입하기 전 알아야 할 것

AX의 기준이 달라졌습니다: 답변하는 AI에서 직접 일하는 AI로

최근까지 AX(AI Transformation)는 AI에게 업무 도움을 받는 일을 뜻했습니다. 그때의 도입 순서는 대체로 이랬습니다.

1. 어떤 AI 모델이 가장 좋은지 비교한다
2. API를 연동하거나, 사내 챗봇을 만든다
3. 직원들에게 “이제 AI를 쓰세요”라고 안내한다
4. 아무도 쓰지 않거나, 쓰더라도 엉뚱한 결과가 나온다

2026년 8월의 AI는 질문에 답하는 도구가 아니라 일을 맡아 실행하는 에이전트입니다. 메일 회신 초안을 쓰고, 리포트를 만들고, 광고 계정과 분석 도구에 직접 접속해 작업합니다. 업계의 관심사도 이미 “도입할 것인가”를 지나 “어디까지 맡길 것인가”로 넘어왔습니다. 그런데 도입 순서는 여전히 과거 그대로인 회사가 많습니다. 문제는 예나 지금이나 2번과 3번 사이에 빠진 단계에 있습니다. AI에게 우리 회사의 맥락을 알려주는 작업이 없었던 겁니다. 이 글에서는 에이전트 시대의 AX가 이전과 무엇이 달라졌는지부터, 도입 전에 반드시 정리해야 할 데이터 기준과 조직의 합의를 어떻게 만들어 가야 하는지까지 정리했습니다.

LLM 모델 성능은 더 이상 변별점이 아닙니다. 2026년의 상위 모델은 어느 것을 골라도 범용 능력이 상당한 수준까지 올라와 있고, 업계의 관심도 프롬프트를 잘 쓰는 기술에서 AI에게 어떤 맥락을 공급할지 설계하는 컨텍스트 엔지니어링(Context Engineering)으로 옮겨 왔습니다. 아무리 좋은 모델도 “우리 회사에서 ‘전환’이 정확히 무엇을 의미하는지”는 모르기 때문입니다. 같은 ‘전환(conversion)’ 이벤트라도 회사마다 정의가 완전히 다릅니다.

저희 오픈소스마케팅이 GA4 컨설팅을 할 때 가장 먼저 하는 일은 클라이언트에게 “귀사에서 전환이란 정확히 어떤 행동을 의미하나요?”라고 묻는 것입니다. 이 질문에 바로 답할 수 있는 기업은 생각보다 많지 않습니다.

AI도 마찬가지입니다. 어떤 모델이든 우리 회사의 맥락을 모르는 상태에서는 범용적인 답변밖에 할 수 없습니다. 답만 하던 시절에는 엉뚱한 답을 사람이 걸러냈지만, 에이전트는 잘못 이해한 그대로 실행까지 해 버립니다. “전환이 뭔지” 모르는 에이전트에게 전환 리포트 자동화를 맡기면, 틀린 기준의 리포트가 매주 자동으로 발행됩니다.

핵심 포인트: AX의 첫 번째 과제는 “어떤 모델을 쓸지”가 아니라 “AI에게 우리 회사의 맥락을 어떻게 알려줄지”입니다.

업무를 보조하는 AI와 운영 방식을 바꾸는 AI는 다릅니다

AI를 기업에 들이는 방식은 크게 두 가지로 나뉩니다. 하나는 지금 하고 있는 업무의 속도를 AI로 끌어올리는 것이고, 다른 하나는 그 업무가 돌아가는 방식 자체를 AI가 읽을 수 있는 형태로 다시 세우는 것입니다.

• 업무를 보조하는 AI: 광고 소재 초안을 만들고, 주간 리포트를 정리하고, 문의 응대를 자동화합니다. 지금까지 하던 일을 더 빠르게 처리하는 영역입니다.
• 운영 방식에 개입하는 AI: 어떤 지표를 성과로 볼지, 예산을 어디로 옮길지, 그 판단을 누가 내릴지에 관여합니다. 조직도에 적힌 결재선과 실제로 일이 지나가는 경로가 다를 때 무엇을 기준으로 삼을지까지 여기에 걸려 있습니다.

첫 번째는 담당자 한 명이 오늘부터 시작할 수 있지만, 두 번째는 사정이 다릅니다. 성과 기준을 바꾸려면 부서 간 합의가 필요하고, 예산 판단을 맡기려면 권한 체계까지 손봐야 하기 때문입니다. 직원이 몇 명 안 되는 회사에서 둘의 경계가 흐릿한 이유도 여기에 있습니다. 판단이 한두 사람 안에 모두 들어 있기 때문입니다.

마케팅 조직에서는 이 차이가 이렇게 드러납니다. 소재 제작 시간을 절반으로 줄인 팀이, 정작 그 소재의 성과를 판정하는 자리는 예전 그대로 월말에 엑셀을 붙여 놓고 진행하기도 합니다. 문의 응대를 자동화한 회사가, 거기서 드러난 고객 반응을 다음 캠페인에 반영하는 경로는 여전히 담당자의 기억에 맡겨 두기도 합니다. 도구는 바뀌었는데 판단이 오가는 길은 그대로인 상태입니다.

지금 대부분의 기업이 하는 AI 작업은 첫 번째에 몰려 있습니다. 그런데 에이전트가 실제로 업무를 맡기 시작하면, 두 번째를 손대지 않고는 진도가 나가지 않습니다. 리포트를 자동으로 쓰려면 어떤 지표를 성과로 볼지 정해져 있어야 하고, 광고비 집행을 도우려면 얼마까지 스스로 판단해도 되는지 선이 그어져 있어야 합니다.

쉽게 말해 첫 번째가 도구를 바꾸는 일이라면, 두 번째는 일하는 방식 자체를 바꾸는 일입니다. 이 글에서 다루려는 것도 대부분 두 번째에 해당하는 이야기입니다.

필수 선행 과제: 데이터를 AI가 읽을 수 있는 상태(AI-Ready)로 만들기

AI에게 맥락을 알려주려면, 먼저 우리 스스로가 그 맥락을 정리해야 합니다. 요즘은 MCP(Model Context Protocol) 같은 표준 연결 방식이 업계 전반에 자리를 잡았습니다. 에이전트를 GA4, CRM, 사내 문서에 직접 접속시키는 일 자체는 어렵지 않습니다. 어려운 것은 연결이 아니라 연결된 데이터의 상태입니다.

그런데 정작 AX 논의 현장에서 더 자주 오르내리는 단어는 택소노미가 아니라 온톨로지, RAG, 온프레미스입니다. 온톨로지는 데이터의 의미와 관계까지 정의하자는 이야기이고, RAG는 사내 문서를 검색해 답변의 근거로 쓰자는 이야기이며, 온프레미스는 데이터를 밖으로 내보내지 말자는 이야기입니다. 다루는 층위는 서로 다르지만, 세 가지 모두 같은 전제 위에 서 있습니다. 정의가 뒤죽박죽인 데이터에 온톨로지를 얹으면 뒤죽박죽인 관계도가 나오고, 같은 데이터에 RAG를 붙이면 뒤죽박죽인 근거를 검색해 오며, 그 데이터를 온프레미스로 옮기면 뒤죽박죽인 상태를 사내에 안전하게 보관하게 됩니다.

그래서 연결보다 먼저 해야 할 것은 데이터의 정의, 분류, 라벨링입니다. 이것을 택소노미(Taxonomy)라고 부르고, 요즘 표현으로는 데이터를 AI가 읽을 수 있는 상태(AI-Ready)로 만드는 작업입니다.

택소노미는 거창한 개념이 아닙니다. 쉽게 말해 우리 회사의 데이터를 어떤 기준으로 분류하고 부를지 정한 약속입니다.

마케팅 데이터를 예로 들어보겠습니다. 저희 오픈소스마케팅이 실제로 클라이언트와 작업하는 항목들입니다.

• UTM 파라미터 설계: 광고 유입 경로를 어떤 기준으로 분류할지 (관련 글: GA4 UTM 실전 가이드)
• 채널 그룹핑 정의: “소셜 미디어”라는 묶음에 무엇을 넣을지, Instagram 광고는 Paid Social인지 Organic Social인지 (관련 글: GA4 채널 그룹 활용 방법)
• 이벤트 네이밍 규칙: 버튼 클릭을 click_button, button_click, btn_clk 중 무엇으로 부를지
• 맞춤 측정기준 설계: GA4에서 우리만의 분석 축을 무엇으로 잡을지

이런 약속이 없으면 어떤 일이 벌어지는지 표로 비교해 보겠습니다.

통일할 값을 정할 때는 우리끼리의 약속만이 아니라 분석 도구의 판정 규칙까지 확인해야 합니다. 예를 들어 구글이 배포하는 GA4 소스 카테고리 목록에는 facebook, fb, instagram은 있지만 meta는 없어서, utm_source를 meta로 통일하면 유료 소셜 트래픽이 Paid Social로 분류되지 않습니다. 이런 규칙까지 택소노미 문서에 담아 두면, 담당자가 바뀌어도 같은 실수를 되풀이하지 않습니다.

택소노미는 AI를 위한 것만이 아닙니다. 사람끼리 소통할 때도 필요하고, AI 도입 여부와 관계없이 데이터 기반 의사결정의 기본 인프라입니다. 다만 AI를 도입하면 택소노미가 없다는 사실이 더 뚜렷하게 드러날 뿐입니다.

현실적인 타협: 온톨로지는 사치, 택소노미는 생존

여기서 한 가지 짚고 넘어갈 개념이 있습니다. 요즘 AX 논의에 부쩍 자주 등장하는, 택소노미와 비슷하지만 훨씬 복잡한 온톨로지(Ontology)입니다. 에이전트가 엉뚱한 실행을 하는 이유가 대체로 의미를 이해하지 못한 데 있어서, 이 단어가 자주 나옵니다.

• 택소노미: 데이터를 분류 체계로 정리한 것 (예: 동물 > 포유류 > 고양잇과)
• 온톨로지: 데이터 간의 관계와 규칙까지 정의한 것 (예: 고양이는 포유류다 + 포유류는 항온동물이다 + 항온동물은 체온을 유지한다 → 고양이는 체온을 유지한다)

대표적으로 팔란티어(Palantir)가 하는 일이 바로 기업 데이터의 온톨로지 구축입니다. 흩어진 데이터를 객체와 관계로 묶는 데서 그치지 않고, 그 위에서 실행할 수 있는 작업(action)까지 정의해 조직 전체를 하나의 디지털 트윈으로 만듭니다. 방산이나 금융처럼 데이터를 밖으로 내보낼 수 없는 산업에서 온톨로지와 온프레미스를 한 묶음으로 이야기하는 것도 같은 맥락입니다.

온톨로지는 이상적인 방향이지만, 대부분의 기업에는 사치입니다. 지식 그래프는 도메인 하나만 잡아도 구축에 몇 달이 걸리고, 많은 프로젝트가 설계나 데이터 정합 단계에서 멈춥니다. 그래서 요즘은 전사를 하나의 의미 체계로 묶기보다, 이미 있는 정의들을 이어 붙이는 쪽을 택하는 분위기입니다. 중소기업이라면 처음부터 온톨로지를 목표로 잡을 필요가 없습니다. 부서마다 다른 정의를 맞춰 두는 일이 이미 그 방향의 첫 단계입니다.

중소기업이 현실적으로 시작할 수 있는 수준은 이렇습니다.

1. GA4 맞춤 측정기준 설계: 우리 비즈니스에 필요한 분석 축 3~5개를 정의
2. UTM 파라미터 가이드 문서 1장: 모든 마케팅 채널의 UTM 규칙을 통일
3. 이벤트 네이밍 컨벤션 1장: 모든 이벤트 이름의 규칙을 정의
4. 용어 사전 스프레드시트 1개: 부서별로 다르게 쓰는 용어를 하나로 통일

이것만으로도 AI에게 “우리 회사의 맥락”을 상당 부분 전달할 수 있습니다. 저희 오픈소스마케팅이 GA4 컨설팅에서 맞춤 측정기준을 설계할 때도, 사실상 미니 택소노미를 만드는 셈입니다. 처음에는 단순한 분류 체계로 시작하고, 필요하면 조금씩 넓혀 가면 됩니다.

이렇게 만든 문서를 AI에 연결하는 방법도 간단합니다.

• 에이전트 스킬로 저장: 리포트 작성처럼 반복되는 업무는 규칙 문서를 참조하는 스킬(Agent Skills)로 만들어 두면, 매번 설명하지 않아도 같은 기준으로 일합니다
• 지식 베이스에 등록: 업무용 AI의 프로젝트 지침이나 참고 문서 영역에 용어 사전과 네이밍 규칙을 올려 둡니다
• MCP로 데이터 연결: 에이전트가 GA4나 사내 시스템을 직접 조회하도록 연결하되, “fb와 facebook은 같은 매체”처럼 값을 잇는 매핑 표를 함께 제공해 추측을 없앱니다
• 사내 문서 검색(RAG) 전에 용어부터 통일: 같은 지표를 부서마다 다른 이름으로 적어 둔 문서를 그대로 검색시키면, 에이전트가 서로 어긋나는 근거를 가져옵니다
• 반출 기준 나누기: 어떤 데이터를 외부 모델에 보낼 수 있고 어떤 데이터는 사내에 둘지 먼저 정합니다. 온프레미스 검토는 이 분류를 마친 뒤에 해도 늦지 않습니다

가장 큰 벽: 기술이 아니라 ‘정치’와 ‘거버넌스’

택소노미를 만드는 것 자체는 기술적으로 어렵지 않습니다. 진짜 어려운 것은 조직 내 합의를 이끌어내는 일입니다.

마케팅팀이 말하는 ‘전환’과 영업팀이 말하는 ‘전환’이 다릅니다.

• 마케팅팀의 전환: 웹사이트에서 문의 폼을 제출한 행위
• 영업팀의 전환: 실제 계약이 성사된 행위
• 경영진의 전환: 매출로 잡히는 행위

같은 단어를 쓰면서 서로 다른 것을 이야기하고 있는데, 아무도 이 차이를 알아채지 못합니다. 여기에 AI를 더하면 어떻게 될까요? AI가 “전환율이 5%입니다”라고 보고할 때, 마케팅팀은 “높다”고 해석하고 영업팀은 “말도 안 된다”고 반발합니다. AI의 문제가 아니라, 입력 데이터의 정의가 서로 어긋나 있는 문제입니다.

저희 오픈소스마케팅이 GA4 도입 컨설팅에서 자주 보는 패턴이 있습니다.

1. 마케팅팀이 GA4를 도입하며 이벤트를 설계한다
2. 영업팀은 자체 CRM에서 다른 기준으로 데이터를 관리한다
3. 데이터팀은 양쪽 데이터를 합치려다 기준 불일치를 발견한다
4. 경영진은 “숫자가 왜 다르냐”고 묻는다
5. 아무도 어느 쪽이 맞는지 답하지 못한다

이 상태에서 AX를 하겠다고 AI 도구를 도입하면, 혼란이 자동화될 뿐입니다.

조사 결과도 같은 방향을 가리킵니다. 2025년 MIT 미디어랩 NANDA 프로젝트가 낸 「The GenAI Divide: State of AI in Business 2025」는 기업 생성형 AI 파일럿의 95%가 측정 가능한 손익 개선에 이르지 못했다고 보고했습니다. 이 보고서가 지목한 원인은 모델 성능이 아니라 조직의 업무 흐름에 AI를 통합하지 못한 데 있었습니다. 가트너 역시 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 전망하면서, 비용 급증과 불명확한 비즈니스 가치, 미흡한 리스크 통제를 이유로 꼽았습니다. 모델을 바꿔서 풀리는 문제가 아니라는 뜻입니다.

The GenAI Divide: State of AI in Business 2025 - MIT NANDA

Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027

회사에는 문서로 적힌 절차와 실제로 일이 지나가는 절차가 따로 있습니다. GA4 속성의 편집 권한이 누구에게 있는지는 관리 화면에 적혀 있지만, 이벤트를 하나 추가하려면 개발팀 배포 일정에 먼저 올려야 한다는 사실은 어디에도 없습니다. 캠페인 예산을 옮기는 절차는 사규에 있지만, 그 전에 어느 팀장에게 미리 말해 두어야 뒤탈이 없는지는 겪어 본 사람만 압니다.

사람은 이런 것을 몇 주면 몸으로 익히지만, 에이전트는 그럴 수 없습니다. 적혀 있지 않은 것은 에이전트에게 존재하지 않는 것과 같기 때문입니다. 예산 이동 절차를 사규대로만 밟다가 중간에서 막히거나, 이벤트 추가를 개발 일정과 무관하게 요청해 두고 반영됐다고 보고하는 일이 생깁니다. 결국 조직이 오랫동안 알면서도 적어 두지 않았던 것들을 문서로 만들어야 에이전트가 일을 합니다.

그리고 이 지점에서 기술 문제가 조직 문제로 바뀝니다. 머릿속에 있던 기준을 문서로 옮기는 순간, 그것은 누구나 볼 수 있는 것이 됩니다. 마케팅 조직으로 좁혀 보면 이런 것들입니다. 매체별 성과를 어떤 기준으로 보정하는지, 어떤 캠페인을 성과 집계에서 빼는지, 대행사 리포트와 내부 리포트의 숫자가 다를 때 어느 쪽을 채택하는지가 그렇습니다. 지금까지 담당자의 판단으로만 존재하던 것들이 문서에 적히면, 그 판단이 타당했는지도 함께 드러납니다.

AI 도입에서 마주치는 저항은 기술을 몰라서 생기는 것만이 아닙니다. 기준이 공개되면 지금의 균형이 흔들린다는 것을 사람들이 먼저 알아채기 때문이기도 합니다. 아는 것을 적어 두지 않는 편이 개인에게 유리한 조직이라면, 아무도 먼저 적지 않습니다. 누구의 잘못이라기보다 구조가 그렇게 만들어 놓은 것입니다.

해결책은 기술이 아니라 거버넌스입니다.

• 용어 정의 회의: 부서 대표가 모여 핵심 용어의 정의를 합의
• 데이터 오너십 지정: 각 지표의 정의와 산출 기준을 누가 관리할지 명확하게 지정
• 변경 프로세스: 용어나 기준을 바꿀 때 거쳐야 할 절차를 문서로 정리

이 합의는 실무 협의만으로는 잘 마무리되지 않습니다. 부서 간 이해관계가 걸린 결정이라서, 의견이 좁혀지지 않을 때 최종 판정을 내려 줄 경영진 스폰서를 처음부터 정해 두는 것이 좋습니다.

에이전트 시대에는 여기에 권한 관리가 붙습니다. 실행하는 AI를 들이는 순간, 누가 무엇을 할 수 있는지 정하는 문제가 사람을 넘어 AI에게까지 번지기 때문입니다.

• 위임 범위 문서화: 어떤 판단을 에이전트에게 맡기고, 어떤 판단은 사람이 검토할지 정해 둡니다
• 사람의 확인 지점: 외부 발송, 예산 집행처럼 되돌리기 어려운 실행 앞에는 승인 단계를 둡니다
• 기록 남기기: 에이전트가 무엇을 조회하고 실행했는지 추적할 수 있게 합니다
• 연결 창구 관리: 각 팀이 임의로 붙인 연결이 늘어나면 사내 데이터가 어디로 나가는지 파악하기 어려워집니다. 승인한 경로만 쓰도록 창구를 정해 둡니다

이 과정에서 “교환 가능한 표준”을 선점하는 부서가 AX의 주도권을 갖게 됩니다. 다른 부서도 수용할 수 있는 데이터 정의를 만들어 놓은 쪽이, AI가 사용할 “공통 언어”의 기준을 잡게 되기 때문입니다.

AI 도입을 막기보다 더 빠른 길을 내주는 편이 낫습니다

공식 도구가 현장 속도를 따라가지 못하면, 사람들은 승인 대신 우회로를 씁니다. 사내 리포트 도구로는 원하는 지표가 나오지 않아 담당자가 따로 스프레드시트를 만들어 두거나, 광고 계정 데이터를 내려받아 개인 폴더에서 가공하는 일이 그렇습니다. 관리 화면에서는 공식 도구가 잘 쓰이는 것처럼 보이지만, 실제 판단은 그 밖에서 내려집니다. 이것을 오래전부터 섀도우 IT라고 불러 왔습니다.

AI에서도 같은 일이 벌어집니다. 도구 하나를 정식으로 들이려면 보안 검토와 구매 승인에 몇 달이 걸리는데, 이번 주 안에 분석을 끝내야 하는 담당자는 개인 계정으로 챗봇을 열고 회사 자료를 붙여 넣습니다. 회사의 AI 방침이 보고서 한 장으로 끝나 있으면, 팀장은 승인을 기다리는 대신 혼자 쓸 자동화 도구를 만듭니다.

이것을 규정 위반으로만 다루면 원인이 가려집니다. 사람들이 우회로를 찾았다는 것은 공식 경로가 그 지점에서 느리다는 뜻이고, 단속을 강화하면 우회로는 눈에 안 띄는 곳으로 옮겨 갈 뿐입니다. 단속에 힘을 쓰는 편보다, 공식 경로를 더 빠르게 만드는 편이 훨씬 실효가 있습니다. 승인이 며칠 안에 끝나고, 쓰고 싶은 데이터에 이미 붙어 있어야 사람들이 돌아옵니다.

준비할 것을 정리하면 세 가지입니다.

1. 도구 표준화: 플랫폼을 하나나 둘로 정하고 “우리는 이걸 씁니다, 교육 자료는 여기 있습니다”라고 말할 수 있는 상태를 만듭니다. 사람마다 쓰는 도구가 다른 회사는 사실상 도구가 없는 것과 같습니다
2. 기록과 권한: 에이전트가 언제, 누구의 요청으로, 어떤 데이터를 보고, 무엇을 실행했는지 남겨 둡니다. 어느 자료까지 볼 수 있는지도 사람과 같은 방식으로 정해야 합니다. 지금까지 회사의 권한 체계는 전부 사람을 기준으로 짜여 있었습니다
3. 사고 대응 절차: 에이전트가 잘못 실행했을 때 누가 먼저 보고받고, 이미 나간 메일이나 집행된 예산을 어떻게 되돌릴지 미리 정해 둡니다

기존 조직을 건드리기 어려우니 AI 전담 조직을 따로 세우자는 이야기도 자주 나옵니다. 실제로는 잘 풀리지 않는 경우가 많습니다. 새 팀은 빠르게 움직이지만 고객 데이터와 광고 계정 권한은 여전히 기존 팀이 쥐고 있고, 권한을 넘겨받지 못한 팀은 보고용 시연물밖에 내놓지 못합니다. 예산과 결정 권한을 함께 준 내부 팀이 아니면 조직은 움직이지 않습니다.

에이전트가 한 일은 무엇으로 세어야 할까요?

에이전트가 일을 맡기 시작하면, 지금까지 성과를 재던 단위가 잘 맞지 않습니다.

대행과 컨설팅은 오랫동안 투입 시간으로 값을 매겨 왔습니다. 정작 사려는 것은 결과인데, 결과를 셀 방법이 마땅치 않아 들인 시간을 대신 세어 온 것입니다. 사흘 걸리던 분석이 한 시간에 끝나면 이 셈법이 어긋납니다. 결과의 값은 그대로인데 청구할 근거가 사라지기 때문입니다.

구독형 도구의 요금 체계는 오랫동안 쓰는 사람 수를 기준으로 삼아 왔습니다. 직원 한 명에 계정 하나입니다. 에이전트는 이 셈법에 들어맞지 않습니다. 사람이 아닌 데다, 필요하면 한 사람이 여러 개를 동시에 돌리기 때문입니다.

회사 안쪽의 예산 편성과 성과 평가도 인원수와 투입 시간을 기준으로 짜여 있습니다. 마케팅 조직에서는 이 문제가 좀 더 일찍 드러납니다. 리포트 몇 건, 캠페인 몇 개, 소재 몇 장으로 팀의 일을 세어 왔다면, 그 건수가 몇 배로 늘어나는 순간 무엇이 좋아진 것인지 설명하기 어려워집니다. 그래서 에이전트를 들이기 전에, 우리 팀이 무엇을 성과로 인정할지 먼저 정해 두는 편이 낫습니다.

AX는 ‘도구 교체’가 아니라 ‘체질 개선’입니다

정리하겠습니다.

조직의 AI 성숙도를 여섯 단계로 나눈 정리가 있습니다.

(출처: Turing Post, Ksenia Se, “The Unsexy Truth of AI Adoption” — 단계 이름은 이해를 돕기 위해 옮긴 것입니다)

#2: The Unsexy Truth of AI Adoption - Turing Post

대부분의 기업은 L0과 L1 사이에 있습니다. 개인은 각자 AI를 쓰고 있지만 회사에는 아무것도 쌓이지 않는 상태입니다. 이 글에서 다룬 택소노미와 거버넌스는 L2로 올라가기 위한 작업입니다. 스타트업이 L2까지 비교적 빨리 가는 이유는 능력이 뛰어나서가 아니라, 아직 머릿속에만 정보를 담아 둔 사람이 적기 때문입니다.

AX는 AI 도구를 도입하는 프로젝트가 아닙니다. AI에게 우리 기업의 일을 가르칠 수 있도록 체질을 바꾸는 과정입니다. 그리고 그 체질 개선의 핵심은 세 가지입니다.

1. 맥락(Context) 정리: AI가 이해할 수 있도록 우리 회사의 데이터와 용어를 정의
2. 택소노미(Taxonomy) 구축: 데이터 분류 체계와 명명 규칙을 문서화
3. 거버넌스(Governance) 확립: 부서 간 용어 합의와 데이터 오너십 지정

이 세 가지 없이 AI 모델만 바꿔 봐야, “성능 좋은 AI가 더 빠르게 엉뚱한 답을 내놓는” 결과만 되풀이됩니다.

작게 시작해도 괜찮습니다. 부서마다 다르게 쓰는 용어 몇 개를 골라 정의를 맞추고, 그 정의를 문서 한 장으로 남기는 것부터 하면 됩니다. 에이전트도 실패 비용이 낮은 업무 하나를 골라, 석 달 안에 효과를 측정할 수 있는 파일럿으로 시작하면 충분합니다. 다만 데이터 기준 정리만큼은 타협하지 않아야 합니다.

솔직히 이 과정은 쉽지 않습니다. 기술보다 사람과 조직의 문제라서 그렇습니다. 그래도 이 과정을 건너뛰고 AI만 도입해서 성과를 낸 기업은 아직 보지 못했습니다.

결국 2026년의 AX는 어떤 모델을 고르느냐의 문제가 아니라, 우리 회사가 스스로 일하는 방식을 얼마나 명확하게 설명할 수 있느냐의 문제로 좁혀집니다. 그동안 담당자의 경험과 감각에 기대어 굴러가던 판단을 문장으로 옮겨 둔 기업과 그렇지 않은 기업 사이에서, 에이전트가 내놓는 결과의 차이는 시간이 지날수록 벌어질 수밖에 없습니다. 데이터 기준을 먼저 세우는 일은 AI 도입의 준비 작업이 아니라, 그 자체로 경쟁력이 되는 시기입니다.

도입 전에 아래 일곱 가지 질문에 답해 보면 우리 조직의 현재 위치가 보입니다.

• ‘전환’의 정의를 어느 부서에 물어도 같은 기준으로 대답할 수 있는지
• 데이터를 분류하고 이름 붙이는 규칙이 문서로 남아 있는지, 담당자의 기억에만 있는지
• 최근 진행한 업무가 그 규칙을 실제로 따랐는지
• 지표 정의를 바꿀 때 누구에게 물어야 하는지 정해져 있는지
• 에이전트에게 맡길 일과 사람이 확인할 일의 경계를 정했는지
• 성과를 집계할 때 무엇을 넣고 무엇을 빼는지 기준이 적혀 있는지
• 회사가 공식으로 제공하는 AI 환경이 개인 계정으로 쓰는 것보다 빠른지

마무리

• AX의 무게중심은 답하는 챗봇에서 일하는 에이전트로 옮겨 왔습니다. 업무를 AI로 보조하기는 쉽지만, 회사가 일하는 방식 자체를 바꾸는 일은 그렇지 않습니다.
• 준비의 실체는 데이터를 AI가 읽을 수 있는 상태(AI-Ready)로 만드는 것입니다. 요즘 자주 들리는 온톨로지, RAG, 온프레미스도 데이터 정의가 잡혀 있어야 제구실을 합니다. 거창한 지식 그래프까지 갈 필요 없이, 분류 규칙과 용어 사전을 문서로 남기는 것이 충분한 시작점입니다.
• 가장 큰 장애물은 기술이 아니라 조직입니다. 머릿속에만 있던 기준을 문서로 꺼내는 일은 권한 문제를 건드리고, 공식 환경이 느리면 직원들은 개인 계정으로 먼저 움직입니다. 데이터 기준 정리가 그 출발점입니다.

데이터 기준을 어디서부터 정리해야 할지 막막하신 분들은 저희 오픈소스마케팅에 편하게 문의해 주세요. 용어 정의를 맞추고 분류 규칙을 문서로 남기는 작업부터 함께 진행하고 있습니다.