AX의 딜레마: AI 도구는 다 있는데, 왜 변화는 어디에도 없는가
어제 티로 블로그 담당자는 광화문 마이크로소프트 오피스에서 열린 Claude Bloom 행사에 다녀왔습니다. 유튜브 크리에이터이자 AX 컨설팅사 조슈아의 대표인 빌더 조쉬님의 강연이 메인 세션이었는데, 들으면서 평소 머릿속에 있던 그림이 한 방향으로 정리되는 느낌이 있었습니다. 강연을 그대로 옮기기보다, 그 자리에서 얻은 인사이트를 제 언어로 다시 짚어보려 합니다.
56%의 CEO가 마주한 병목
ChatGPT 라이선스도 도입했고, Copilot도 깔았고, 슬랙에 에이전트도 넣어 봤습니다. 그런데 조직 단위에서 뭐가 바뀌었느냐고 물으면, 답이 잘 안 나옵니다.
이 풍경은 어느 한두 기업의 이야기가 아닙니다. PwC의 2026 글로벌 CEO 서베이에 따르면, 95개국 4,454명의 CEO 중 56%가 AI 투자에서 "아무것도 얻지 못했다"고 답했습니다. NBER의 2026년 연구도 비슷한 그림을 보여 줍니다. 미국·영국·독일·호주의 6,000명 CEO·CFO 중 80% 이상이 AI가 고용이나 생산성에 아무런 영향을 미치지 못했다고 응답했습니다.
기술은 분명히 진보했는데, 그 진보가 어디로 갔는지 아무도 설명하지 못하고 있는 셈입니다. 이 구조적 정체 현상은 왜 우리의 AX 전환은 10%에서 멈추는가 글에서 한 번 자세히 다룬 적이 있습니다.
AX의 5개 레이어
이 현상의 구조를 보려면 AX 시스템을 한 번 분해해 봐야 합니다. AX(AI Transformation)는 다섯 개의 레이어로 나누어 볼 수 있습니다.
컨텍스트 레이어. 회사가 가진 모든 원본 자산입니다. 회의록, 문서, 슬랙 메시지, 캘린더, 코드.
온톨로지 레이어. 그 자산들 사이의 관계와 의미를 정의한 구조입니다. "고객"이 우리 회사에서 무엇을 의미하는지, "계약"과 "회의"가 어떻게 연결되는지를 정한 약속. 이 레이어의 앞단인 Pre-Ontology 개념은 별도 글에서 자세히 다뤘습니다.
언어 모델 레이어. 추론 엔진. LLM 그 자체입니다.
에이전트 레이어. LLM이 도구·메모리·검증 루프를 갖고 실제로 일을 처리하는 단위입니다.
인터페이스 레이어. 사람이 시스템에 명령을 내리는 창구입니다. 슬랙, Claude 앱, CLI가 예시입니다.
대부분 기업은 3~5번에만 투자합니다
여기서 56%의 사례가 설명됩니다. 대부분의 기업이 3~5번 레이어에만 시간과 돈을 쓰고 있습니다. 어떤 모델을 쓸지, 어떤 에이전트 프레임워크가 좋은지, 어떤 인터페이스가 편한지.
그런데 1번과 2번 레이어, 즉 데이터와 분류 체계는 비어 있습니다. 사서의 뇌가 아무리 좋아도, 도서관에 책이 절반밖에 없으면 절반짜리 답만 나옵니다. AI에게 좋은 두뇌와 좋은 손발을 달아 줬지만, 정작 읽을 거리는 주지 않은 셈입니다.
McKinsey의 2025 AI 서베이가 이것을 숫자로 확인해 줍니다. AI에서 "유의미한 재무적 성과"를 보고한 조직은, 도구를 고르기 전에 워크플로우와 데이터 흐름을 먼저 재설계한 기업이었습니다. 모델이 아니라 그 앞단이 결과를 만들었다는 뜻입니다.
AX 성공 사례는 무엇이 달랐는가
반대로 AX의 성공 사례를 들여다보면, 의외로 비슷한 패턴이 보입니다. 강연에서 소개된 사례 몇 가지를 정리해 봤습니다.
온라인 스터디·강의 운영 회사 한 곳. 캐릭터와 말투까지 부여한 AI 에이전트가 수만 명에게 문자를 보내고, 스터디 참가자 상태를 분류하고, 줌 링크를 발송하고, 회의록을 요약합니다. 30~40개 스터디를 동시에 운영하면서 모든 대화가 맥락으로 쌓이고 있습니다.
소규모 컨설팅 조직. 깃헙과 클로드 코드로 전 직원이 협업합니다. 비개발자도 깃헙으로 업무를 처리하고, SOP(업무 표준)는 매일 갱신됩니다.
AX 컨설팅 회사 한 곳. 45분짜리 고객 미팅 중간에 AI에게 구현을 지시해 15분 만에 프로토타입을 제시합니다.
세 곳의 사업 영역도, 규모도, 운영 방식도 다 다릅니다. 그런데 한 가지는 똑같습니다. 모두 1번 레이어, 즉 데이터가 한 곳에 쌓이는 구조부터 먼저 만들었다는 점입니다. 자동화가 먼저가 아니라, 축적이 먼저입니다.
도구 스택은 거창하지 않습니다
이런 회사들이 실제로 쓰는 도구 스택을 모아 보면 의외로 단출합니다.
도구 | 역할 |
|---|---|
클로드 코드 / 코덱스 | 오퍼레이션 시스템 |
헤르메스(Hermes) 에이전트 | 일일 태스크 자동 제안 |
깃헙(GitHub) | SSOT |
슬랙(Slack) | 사람과 에이전트가 함께 일하는 공간 |
옵시디언(Obsidian) | 회의록·공용 파일 저장소 |
Tiro | 회의록 자동 전사·요약, MCP로 LLM에 직접 노출 |
맥 미니 | 24시간 켜져 있는 공용 에이전트 머신 |
신기술 모음이 아닙니다. 맥락 데이터를 잘 쌓이게 하는 도구의 조합입니다. 클로드 맥스 플랜, 회의록을 자동으로 받아 적고 LLM이 곧바로 가져갈 수 있게 해 주는 도구 하나, 그 데이터를 받아갈 깃헙과 옵시디언. 이 조합 위에서 슬랙의 에이전트가 견적서를 발급하고, 매일 오전 9시에 그날 해야 할 태스크를 사람마다 제안하고, SOP가 매일 한 차례 업데이트됩니다.
거꾸로 말하면, 도구를 아무리 좋은 걸로 깔아도 1번 레이어가 채워지지 않는 한 작동하지 않습니다.
가장 많이 누락되는 데이터는 회의에 있습니다
여기서 자연스럽게 떠오르는 질문은 이것입니다. 1번 레이어의 가장 큰 공백은 어디에 있는가.
Notion에 정리된 문서, Slack에 남은 메시지, Jira의 티켓. 이것들은 회사 맥락의 10% 정도밖에 안 됩니다. 나머지 90%는 회의에서 나온 결정, "왜 그렇게 정했는지"의 이유, 누군가가 한마디 던졌던 우려. 구두로 오갔던 모든 것입니다. 그리고 이 90%는 회의가 끝나는 순간 사라집니다.
이게 1번 레이어의 가장 큰 결손입니다. AI 에이전트가 아무리 좋은 RAG로 사내 위키를 뒤져도, 이 자리엔 들어갈 수가 없습니다. 이 결손이 컨텍스트 엔지니어링 자체에 어떻게 영향을 주는지는 챗봇이 어제 한 말을 또 잊어버리는 이유 글에서 별도로 다뤘습니다.
복잡한 내부 시스템 연동도, 멋진 에이전트 설계도 아닙니다. 회의록을 녹음하고, 쌓고, 다른 도구가 가져갈 수 있게 만들어 두는 일. AX의 출발선은 거의 늘 이 자리에 있습니다.
AX를 향한 첫 걸음
앞 표에서 잠깐 등장한 Tiro가 채우려는 자리가 정확히 그곳입니다. 회의를 녹음하거나 화면을 공유하면 자동으로 받아 적고, 요약과 액션 아이템까지 뽑아 줍니다.
회의록 AI는 이제 흔한 카테고리입니다. 하지만 Tiro의 차이점은 둘입니다.
하나는 한국어 정확도입니다. 한국어로 진행되는 회의에서 다른 도구보다 더 정확한 결과를 냅니다. 한국어로 회의하는 팀에는 의외로 큰 차이를 만듭니다.
다른 하나는 MCP를 제공한다는 점입니다. Tiro MCP는 회의록·요약·화자 분리 결과를 LLM이 직접 가져갈 수 있게 노출한 통로입니다. 회의가 끝나는 순간 클로드 코드든, 옵시디언이든, 어떤 에이전트든 곧바로 그 회의록을 꺼내 쓸 수 있습니다. 1번 레이어와 4번 레이어 사이의 거리가 짧아지는 셈입니다. Tiro MCP의 설계 디테일은 티로가 비즈니스 맥락을 기억하는 법에서, MCP라는 표준 자체에 대해서는 API, MCP, CLI, Claude Skill에서 더 자세히 다뤘습니다.
AX의 시작은 거창한 시스템이 아니라, 어제 한 회의를 내일도 꺼내 볼 수 있게 만드는 일에서 출발합니다.
정리
AX(AI Transformation)는 5개 레이어로 분해할 수 있습니다. 컨텍스트, 온톨로지, 언어 모델, 에이전트, 인터페이스. AI 투자에서 성과를 얻지 못하는 56%의 기업이 공통적으로 마주한 병목은, 1, 2번은 비워 두는 풍경입니다.
반대로 AX가 실제로 굴러가는 회사들의 공통점은 단순합니다. 데이터가 한 곳에 쌓이는 구조를 먼저 만들었다는 것. 그리고 그 구조에서 가장 큰 결손은 회의에서 발생합니다. 회의는 회사 맥락의 90%를 담지만, 끝나는 순간 사라집니다.
AX의 출발선은 거의 늘 회의록을 쌓는 자리에 있습니다. 모델·에이전트·인터페이스보다 한 단계 앞입니다.