AI-first라는 말은 너무 약하게 쓰이고 있다

AI-first라는 말이 너무 쉽게 쓰인다.

전 직원에게 ChatGPT 계정을 줬다. Copilot을 깔았다. 사내 프롬프트 교육을 했다. 회의록 요약 봇을 붙였다. 그러고 나면 회사는 스스로를 AI-first에 가까워졌다고 말한다.

나는 그 표현이 거의 틀렸다고 본다.

그건 AI 도입이지 AI-first가 아니다. 더 정확히는, 예전 조직 위에 AI 도구를 얹은 것이다. 일이 흐르는 방식은 그대로 두고, 각자 쓰는 문구 생성기와 검색 보조 도구만 바꾼 상태다.

HubSpot이 쓴 How we Operate as an AI-first Company는 그 차이를 꽤 정확하게 짚는다. AI-first를 도구 보급의 문제가 아니라 조직이 작동하는 방식의 문제로 다룬다.

AI가 개인의 보조 도구에 머무는가, 아니면 회사의 판단과 권한과 맥락을 다루는 실행 레이어가 되는가.

이 차이를 모르면 AI 전환은 대부분 직원 교육에서 멈춘다.

사용률은 출발선이지 성과가 아니다

HubSpot은 2025년까지 전사 AI 사용률 목표를 세우고, 팀별·도구별·사용례별 데이터를 공개했다고 한다. 결과적으로 직원의 94%가 매주 AI를 쓰고, 직원들이 만든 AI agent가 3,900개를 넘었다.

숫자는 인상적이다. 하지만 그 숫자만으로는 아직 회사가 바뀌었다고 말할 수 없다.

초기 단계에서 사용률을 보는 이유는 AI가 대단해서가 아니라, 안 쓰는 도구는 조직을 바꿀 수 없기 때문이다. 사람들이 실제 업무에서 AI를 만져봐야 감이 생긴다. 어떤 일은 바로 빨라지고, 어떤 일은 위험하고, 어떤 일은 겉보기와 달리 자동화 가치가 없다는 것도 그때 드러난다.

그래서 사용률은 필요하다.

다만 여기서 멈추면 망한다.

사용률은 체온계 같은 것이다. 체온을 잰다고 병이 낫지 않는다. 프롬프트 횟수가 늘었다고 회사가 똑똑해지는 것도 아니다. 직원들이 매일 AI를 쓴다는 사실만으로는 고객 대응 속도, 채용 cycle time, 영업 전환율, 제품 개발 속도가 구조적으로 좋아지지 않는다.

많은 조직은 이 지점에서 착각한다. AI 사용률을 성과로 착각한다. 교육 수료율을 변화로 착각한다. 사내 활용 사례 발표회를 운영 혁신으로 착각한다.

HubSpot 글이 괜찮은 이유는 사용률을 목적지로 두지 않는다는 점이다. 사용률은 Stage 1의 leading indicator일 뿐이고, 진짜 싸움은 그 다음 단계에서 시작된다.

개인 생산성은 조직 성과로 자동 변환되지 않는다

AI 도입의 가장 흔한 실패는 개인 생산성과 조직 생산성을 같은 것으로 보는 데서 나온다.

개인은 빨라질 수 있다. 글 초안을 빨리 쓴다. SQL을 빨리 만든다. 리서치 시간을 줄인다. 회의록을 정리한다. 코드 보조를 받는다.

그런데 회사의 일은 개인의 작업 속도만으로 결정되지 않는다.

대부분의 병목은 사람 하나의 손이 느려서 생기지 않는다. handoff가 많아서 생긴다. 권한이 불분명해서 생긴다. 데이터가 흩어져서 생긴다. 승인자가 늦게 봐서 생긴다. “이건 누구한테 물어봐야 하지?“라는 질문이 계속 반복돼서 생긴다.

이런 병목은 개인이 AI를 잘 써도 그대로 남는다.

HubSpot이 Stage 2에서 팀 단위 transformation을 말하는 이유가 여기에 있다. 각 직원이 AI를 쓰는 것만으로는 business outcome이 생기지 않는다. 팀의 workflow 자체를 다시 봐야 한다.

그래서 HubSpot은 팀을 두 축으로 본다.

• AI maturity: 이미 얼마나 잘 쓰고 있고, 결과가 있는가
• AI readiness: 그 팀의 일이 자동화되기 좋은가, 데이터와 시스템이 받쳐주는가

이 분류는 사소해 보이지만 중요하다. 모든 팀에 같은 교육과 같은 도구를 뿌리는 방식은 편하지만, 조직을 바꾸지는 못한다.

이미 빠른 팀은 더 밀어주면 된다. 자동화 기회가 뻔한데 안 움직이는 팀은 리더가 현장으로 들어가 병목을 찾아야 한다. 잠재력은 큰데 데이터와 시스템이 엉켜 있는 팀은 별도 pod와 change management가 필요하다.

AI 전환은 복지 포인트처럼 도구를 나눠주는 일이 아니다.

업무의 병목 지도를 다시 그리는 일이다.

진짜 AI-first는 institutional context에서 갈린다

Stage 3부터 무게가 달라진다.

HubSpot은 Stage 3를 institutional AI라고 부른다. 개인이 AI를 잘 쓰는 단계도 아니고, 팀이 일부 workflow를 개선하는 단계도 아니다. 회사 자체가 AI와 함께 작동하도록 바뀌는 단계다.

그 아래 놓인 것은 institutional context다.

회사의 맥락은 원래 사람 사이에 흩어져 있다. 어떤 고객은 왜 중요한지, 어떤 deal은 왜 막혔는지, 어떤 제품 결정은 왜 그렇게 내려졌는지, 어떤 코드는 건드리면 안 되는지, 어떤 일은 누가 승인해야 하는지.

이 맥락이 사람 머릿속, Slack 스레드, 오래된 문서, 회의 기억, 몇몇 senior의 감각에만 있으면 AI는 계속 보조 도구에 머문다.

반대로 이 맥락이 agent가 읽고, 물어보고, 초안을 만들고, 실행 전 검토를 올릴 수 있는 형태가 되면 이야기가 달라진다.

그때 AI는 문서 작성기가 아니라 조직 인터페이스가 된다.

신입은 회사가 어떻게 의사결정하는지 사람을 붙잡고 묻지 않아도 된다. 영업 매니저는 deal이 막힌 이유를 리포트 몇 개를 뒤져가며 맞추지 않아도 된다. 엔지니어는 코드베이스의 암묵지를 옆 사람에게만 의존하지 않아도 된다.

이건 챗봇을 잘 만든다는 이야기가 아니다.

회사의 기억과 권한과 실행 경로를 agent가 접근 가능한 substrate로 만드는 이야기다.

그래서 Stage 3부터는 governance가 중심이 된다. 누가 무엇을 볼 수 있는가. 어떤 결정은 사람이 승인해야 하는가. 어떤 action은 dry-run까지만 허용되는가. 실행 기록은 어디에 남는가. 잘못된 출력은 어떻게 감지하고 멈추는가.

이 질문을 피하면서 AI-first를 말하면 거의 다 가짜다.

AI-first라는 말의 무게는 모델 성능이 아니라 권한 설계에서 드러난다.

한국 회사들이 놓칠 가능성이 높은 지점

한국 회사들은 이런 사례를 보면 아마 쉬운 쪽부터 따라 할 가능성이 높다.

전사 AI 교육. 활용 사례 공모전. 임원용 대시보드. 사내 챗봇. 프롬프트 템플릿. 생산성 향상 캠페인.

다 할 수 있다. 해도 된다. 하지만 그것만으로는 구조가 안 바뀐다.

하지만 성패를 가르는 질문은 따로 있다.

우리 회사의 반복 업무는 어디서 막히는가. 그 업무에 필요한 context는 어디에 있는가. 그 context는 최신인가. agent가 읽을 수 있는가. agent가 초안을 만들었을 때 누가 승인하는가. 승인 기록은 어디에 남는가. 실패한 실행은 다음번에 반영되는가.

이 질문에 답하지 못하면 AI는 계속 개인기다.

개인기는 반짝인다. 하지만 compound되지 않는다. 조직에 남지 않는다. 잘하는 직원이 떠나면 같이 사라진다.

반대로 context와 permission과 audit trail이 남으면, 한 번의 실험이 다음 실행의 바닥이 된다. agent가 실패해도 흔적이 남고, 사람이 고친 판단이 다음번에 재사용된다. 그때부터 AI 활용은 이벤트가 아니라 운영 자산이 된다.

이게 AI-first의 실제 갈림길이다.

작은 팀은 오히려 더 빨리 갈 수 있다

HubSpot은 큰 회사다. 그래서 대기업 사례로만 읽으면 놓치는 게 많다.

작은 팀이나 1인 회사는 더 빨리 움직일 수 있다. 부서 정치가 적고, legacy process가 얇고, 의사결정자가 가까이 있기 때문이다.

다만 작은 팀일수록 더 조심해야 할 것도 있다. 작은 팀은 사람 한 명의 머릿속에 너무 많은 맥락이 들어간다. 고객 문의, 결제, 배포, 글 발행, 영업, 채용, 회계, 제품 판단이 한 사람의 inbox와 메신저에 섞인다.

이 상태에서 AI를 붙이면 처음에는 빨라 보인다. 하지만 context가 정리돼 있지 않으면 곧 더 시끄러워진다. agent가 초안을 많이 만들수록 review burden이 늘고, 자동화가 많아질수록 어디서 무슨 일이 벌어지는지 놓치기 쉽다.

그래서 작은 팀의 시작점은 “AI로 무엇을 자동화할까”가 아니다.

작은 팀의 시작점은 “어떤 반복 업무를 운영 자산으로 바꿀까”여야 한다.

좋은 시작은 단순하다.

반복되는 업무 하나를 고른다. 그 업무에 필요한 자료와 판단 기준을 한곳에 모은다. agent는 실행이 아니라 초안과 dry-run을 맡는다. 사람은 review queue에서 승인한다. 승인·수정·거절의 이유를 기록한다. 그 기록을 다음 실행의 context로 되돌린다.

이 루프가 돌기 시작하면 작은 팀도 institutional AI의 작은 버전을 갖게 된다.

완전 자동화가 중요한 게 아니다.

누적되는 운영 기억이 중요하다.

AI-enabled와 AI-first 사이

HubSpot 글의 가치는 수치에 있지 않다.

94% weekly AI usage도, 3,900개 agent도, 20번의 AI learning day도 흥미롭지만 본질은 아니다. 그 숫자는 방향을 설명하는 재료다.

당신의 회사에서 AI는 개인의 보조 도구인가, 아니면 조직의 운영체제를 바꾸는 힘인가.

개인의 보조 도구라면 AI-first라는 말은 과하다. 그냥 AI-enabled 정도면 된다.

AI-first라고 부르려면 회사의 일이 바뀌어야 한다. 정보가 놓이는 방식이 바뀌어야 한다. 권한이 표현되는 방식이 바뀌어야 한다. 승인과 실행과 감사의 경로가 바뀌어야 한다. 사람이 아는 것을 agent가 접근 가능한 context로 바꾸고, agent가 한 일을 사람이 검토 가능한 기록으로 남겨야 한다.

이건 도구 도입이 아니다.

운영 모델의 재설계다.

그래서 AI-first라는 말은 지금보다 훨씬 무겁게 써야 한다.

AI를 많이 쓰는 회사가 아니라, 회사의 맥락과 권한과 실행 기록이 AI와 함께 움직이도록 다시 설계된 회사.

그 정도는 되어야 AI-first라는 말을 붙일 수 있다.