AI 도구를 배포하는 것과 AI 방식을 내재화하는 것은 다르다
Anthropic이 직원에게 엔지니어·마케팅·법무 전용 Claude Skills를 따로 만든 이유가 있다. AI 도입의 다음 단계는 툴 배포가 아니라 직무별 플레이북 내재화다. PM이 설계해야 할 것은 구독 라이선스가 아니다.
Anthropic이 직원들에게 Claude Skills를 직무별로 만들어 배포했다.
엔지니어팀에는 코드 리뷰와 디버깅 워크플로우가 미리 구성된 스킬이. 마케팅팀에는 캠페인 브리핑과 카피 초안 생성 플로우가. 법무팀에는 계약서 검토와 리스크 식별 프로세스가 패키징된 형태로.
같은 AI 모델을 쓰면서, 왜 직무마다 다르게 패키징했을까.
이 질문의 답이 2026년 AI 도입의 핵심 격차를 설명한다.
88%가 도입했지만 33%만 스케일한다는 격차의 정체
AI 에이전트 도입률 88%. 실제 운영 규모로 확장된 비율은 33%. 이 숫자가 1년 가까이 업계 리포트에 반복해서 등장한다.
초기에는 기술 성숙도 문제라고 분석했다. 모델이 충분히 좋지 않아서, 또는 통합 인프라가 아직 준비가 안 되어서. 그러나 모델 성능은 매 분기 크게 오르고 있고, 인프라 도구도 넘쳐난다.
삼성SDS AX센터가 내부적으로 확인한 수치는 더 구체적이었다. 에이전트를 실제 업무에 사용하는 비율이 5%. 도입한다는 것과, 실제 쓴다는 것은 전혀 다른 이야기였다.
격차의 정체는 기술이 아니다. 사용 방식의 설계가 없는 것이다.
도구를 쓰는 것과, 방식을 내재화하는 것
대부분의 기업이 AI “도입”이라고 부르는 것은 사실 이런 상황이다.
전사 이메일로 ChatGPT Plus 계정 안내. 부서별 Copilot 라이선스 배포. “AI 써보세요” 사내 공지. 이런 배포 이후 실제 무슨 일이 일어나는가. 몇몇 얼리어답터가 개인 생산성에 활용한다. 회의록 요약, 이메일 초안, 코드 자동완성. 각자 자기 방식대로.
반면 Anthropic이 Claude Skills를 직무별로 만들었을 때의 의도는 다르다. 이는 개인이 “AI를 잘 쓸 수 있게” 하는 게 아니다. 팀의 업무 방식 자체를 AI 중심으로 재설계하는 것이다.
차이를 정리하면 이렇다.
도구 배포는 접근권을 준다. 개인이 알아서 쓴다. 사용 여부는 선택이다. 측정하기 어렵다.
플레이북 내재화는 일하는 방식을 바꾼다. 직무 단위로 설계된다. 업무 프로세스에 내재된다. 성과와 직접 연결된다.
OpenAI의 내부 연구도 같은 패턴을 확인했다. 에이전트를 활용한 생산성 향상은 “도구를 쓴 사람”보다 “업무 흐름 단위로 에이전트를 설계한 팀”에서 현저히 높았다. 짧은 프롬프트 사용이 아니라, 긴 업무 흐름 전체를 에이전트 중심으로 재구성한 팀이 먼저 실질적 결과를 얻었다. AI가 단일 요청에 응답하는 것과, 복수의 업무 단계를 연결된 흐름으로 처리하는 것은 완전히 다른 설계 문제다.
직무별 플레이북이 만드는 차이
Claude Skills가 단순한 기능 추가가 아닌 이유는 구체적이다.
엔지니어와 마케터는 AI에게 원하는 것이 근본적으로 다르다. 엔지니어는 코드베이스 컨텍스트, 테스트 커버리지 기준, 보안 가이드라인이 사전 내재된 워크플로우가 필요하다. 마케터는 브랜드 보이스, 타겟 세그먼트, 채널별 톤앤매너가 반영된 생성 환경이 필요하다. 법무팀은 관할 법령, 판례 기반 판단 기준, 리스크 등급 체계가 내장된 검토 프로세스가 필요하다.
이 차이를 무시하고 “모두에게 같은 AI를 준다”는 접근이 스케일 실패의 핵심 원인이다.
더 중요한 점은 플레이북이 조직 지식을 외부화한다는 것이다.
지금까지 베테랑 마케터의 카피 작성 방식은 암묵지였다. 시니어 엔지니어의 코드 리뷰 기준은 개인 경험이었다. 법무팀의 리스크 판단 프레임은 수년간 쌓인 노하우였다. Claude Skills를 직무별로 설계한다는 것은, 이 암묵지를 AI가 실행 가능한 형태로 명시적으로 만드는 과정이다. 한 번 만들어지면, 신입도 베테랑과 같은 기준점에서 시작할 수 있다.
AX(AI Transformation)라는 개념이 DX(디지털 전환)와 다른 점이 여기 있다. DX는 프로세스를 디지털화했다. AX는 업무 방식 자체의 재정의를 요구한다. 그리고 그 재정의의 핵심 산출물이 직무별 플레이북이다.
PM이 설계해야 할 것은 구독 라이선스가 아니다
여기서 PM의 역할이 달라진다.
과거 소프트웨어 도입에서 PM이 했던 일: 도구를 평가하고, 예산을 확보하고, 배포하고, 교육 세션을 진행하는 것. AI 도입에서도 같은 패턴을 반복하는 PM이 많다. 그게 스케일 실패의 또 다른 이유다.
AI 시대 PM이 해야 할 일은 팀별 업무 플레이북을 설계하는 것이다.
이 설계는 세 가지 질문으로 시작된다.
첫째, 어떤 업무가 AI에 적합한가. 반복적이고, 컨텍스트가 명확하고, 결과를 측정할 수 있는 업무. 고객 문의 1차 분류, 코드 리뷰 체크리스트 검증, 계약서 초안 비교, 성과 데이터 요약.
둘째, 어떤 컨텍스트를 사전 내재화해야 하는가. 브랜드 가이드라인, 코딩 컨벤션, 법적 판단 기준, 도메인 용어 정의. 이것들이 플레이북의 내용물이다. 이 컨텍스트가 없으면 AI는 매번 처음부터 시작하고, 사용자는 매번 같은 배경 설명을 반복한다.
셋째, 어디서 사람이 개입해야 하는가. AI가 처리하는 영역과 인간이 최종 판단해야 하는 영역의 경계. 이 경계 설계가 가장 어렵고 가장 중요하다.
Anthropic이 법무팀에 Claude Skills를 만들 때, 계약서 초안 생성은 AI에게, 최종 법적 판단은 법무팀에게라는 경계를 명확히 설계했을 것이다. 이 경계 없이 “AI를 쓰세요”라고 하면, 팀원은 어디서 AI를 믿어야 하는지, 어디서 직접 검토해야 하는지 모른다. 그래서 결국 아무도 쓰지 않거나, 잘못된 방식으로 쓴다.
내재화의 첫 단계: 가장 반복적인 업무 하나를 플레이북으로
플레이북 내재화를 거창하게 시작할 필요는 없다.
팀에서 가장 반복적으로 하는 업무 하나를 골라라. 매주 작성하는 주간 리포트, 매달 반복되는 성과 분석, 날마다 처리하는 인입 문의 분류.
그 업무의 입력과 출력을 명확히 정의한다. 어떤 정보가 들어오고, 어떤 형태로 나와야 하는가. 어떤 판단 기준이 적용되는가. 어떤 예외 케이스가 있는가.
이것을 Claude Skills나 시스템 프롬프트 형태로 구성한다. 팀원 전체가 같은 출발점에서 시작하게 한다. 결과를 측정하고, 플레이북을 개선한다.
이게 내재화다. 도구를 배포하는 게 아니라, 일하는 방식을 재설계하는 것.
AI 도입의 다음 전선은 모델 성능 비교가 아니다.
누가 더 좋은 직무별 플레이북을 먼저 설계하는가의 경쟁이다.
Anthropic이 직원들에게 직무별 Claude Skills를 만든 것은 내부 생산성 실험이기도 하지만, 동시에 이 방향에 대한 가장 강력한 신호이기도 하다. 세계에서 AI를 가장 깊이 이해하는 팀이 선택한 방식이 “직무별 플레이북 내재화”라면, 그것이 답이다.
당신 팀의 AI 사용은 지금 어느 단계에 있나요? 도구를 배포했나요, 아니면 업무 방식을 바꿨나요?