담당 부서를 세 번 바꿔도 AX가 시작되지 않는 이유

강의가 끝나고 나온 이야기

최근 직원 1,000명대 중견기업에서 임원·리더를 대상으로 AI 전환(AX) 강의를 진행했습니다. 주목할만한 내용은 오히려 강의가 끝난 뒤 들은 그 조직의 AX 진행 경과였습니다.

이 회사는 이미 AX를 세 번 시도한 상태였습니다.

처음에는 IT 부서에 요청했습니다. 돌아온 답은 진행 중인 과제가 많아 AX에 쓸 시간이 없다는 것이었습니다.

두 번째로는 도메인 전문가들이 직접 해 보기로 결정 했습니다. 이번에는 AI를 몰라서 어디서부터 어떻게 시작해야 할지 모르겠다는 답이 돌아왔습니다.

세 번째로 내부 AX 태스크포스를 꾸렸습니다. 팀은 만들어졌지만, 구성원 모두가 현업을 겸하고 있어 잠깐 진행되었다가 그대로 멈춰 있었습니다.

세 번의 시도 끝에 여전히 파일럿 한 건이 없는 상태 였습니다.

---

담당을 세 번 바꿨다는 것의 의미

이 경과를 단순히 실패했구나 로 읽으면 핵심을 놓치게 됩니다. 오히려 반대입니다.

대부분의 조직은 첫 번째 답에서 멈춥니다. IT 부서가 어렵다고 하면 그대로 다음 해 예산 논의로 넘어갑니다. 그렇게 한 해가 지나갑니다.

이 회사는 그러지 않았습니다. 막힐 때마다 실행 주체를 빠르게 바꿨습니다. 담당을 세 번 바꿨다는 것은 그만큼 강력한 의지가 있었다는 뜻입니다.

그래서 이 사례가 더욱 주목할만 합니다. 의지가 부족해서 못 한 것이 아니라면, 의지만으로는 넘지 못하는 벽이 있다는 뜻이기 때문입니다. 그리고 현장에서 만나는 조직 대부분이 정확히 같은 지점에서 멈춰 있습니다.

---

세 개의 답은 사실 하나였습니다

세 번의 시도에서 돌아온 답은 표면상 서로 다릅니다. 시간이 없다, AI를 모른다, 현업이 바쁘다. 그런데 나란히 놓고 보면 같은 방향 즉, "성과 지표가 없다"를 가리키고 있습니다.

특히 첫 번째 시도는 분류 자체가 문제였습니다. AX를 IT 과제로 분류하는 순간, AX는 매출과 납기가 걸린 과제들과 같은 백로그에 들어갑니다.

그 경쟁에서 AX는 반드시 밀립니다. 중요도가 낮아서가 아니라, 언제 어떤 형태로 성과가 나오는지 아무도 약속하지 않은 유일한 항목이기 때문입니다.

---

"바빠서"는 시간 문제가 아닙니다

바빠서는 원인이 아니라 결과입니다. 조직의 시간은 이미 어딘가에 배분돼 있고, 바쁘다는 말은 그 배분표에 AX가 없다는 뜻입니다.

현장에서 이 말은 대개 완곡한 거절 표현입니다. 이건 내 평가에 잡히지 않는다.

바쁘다는 답은 시간이 없다는 뜻이 아닙니다. AX가 아직 아무의 KPI도 아니라는 뜻입니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart LR
    subgraph SURFACE["표면적인 답변"]
        direction TB
        S1["시간이 없다"]
        S2["AI를 모른다"]
        S3["현업이 바쁘다"]
    end
    SURFACE --> CAUSE["AX가 아직<br/>아무의 KPI도 아니다"]
    CAUSE --> RESULT["담당을 바꿔도<br/>결과가 같다"]
    style S1 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style S2 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style S3 fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style CAUSE fill:#fee2e2,stroke:#ef4444,color:#111827
    style RESULT fill:#f3f4f6,stroke:#6b7280,color:#1f2937

담당을 세 번 바꾸는 동안 바뀌지 않은 것이 있습니다. 세 주체 중 누구도 AX 성과가 자기 평가에 반영되지 않았습니다. 조직도는 세 번 바뀌었고 성과 지표는 한 번도 바뀌지 않았습니다.

같은 조건이라면 네 번째 주체를 지정해도 결과는 같습니다. AX는 리소스 문제가 아니라 지표의 문제입니다.

---

부족한 것은 AI 지식이 아니었습니다

두 번째 시도에서 나온 답도 다시 볼 필요가 있습니다. AI를 몰라서 시작하지 못했다는 진단은 대부분 정확하지 않습니다.

도메인 전문가는 자기 업무를 조직에서 가장 잘 압니다. 다만 그 업무를 다른 주체가 그대로 실행할 수 있는 명세로 써 본 경험이 없습니다. AI 지식이 부족한게 아니라 업무를 문서로 만드는 훈련이 부족한 것입니다.

업무가 담당자 머릿속에만 있으면 자동화할 대상 자체가 존재하지 않습니다. 이 상태에서 AI 활용 교육부터 하면 도구는 배우지만 적용할 업무가 없습니다. 교육 만족도는 높게 나오고, 3개월 뒤 달라진 업무는 없습니다.

---

그래서 첫 시작은 업무 문서화입니다

업무 프로세스를 문서화하고 명문화하는 작업은 세 개의 한계를 모두 극복합니다.

• IT 부서가 필요 없습니다 — 시스템 구축이 아니라 서술 작업입니다.
• AI 지식이 필요 없습니다 — 도구를 고르기 이전 단계입니다.
• 도메인 전문성이 그대로 산출물이 됩니다 — 가장 일을 잘 아는 사람이 가장 잘하는 일입니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart LR
    subgraph WALL["세 개의 한계"]
        direction TB
        W1["IT 부서 리소스"]
        W2["AI 지식 부족"]
        W3["현업 시간 부족"]
    end
    W1 -- "시스템 구축이 아니다" --> DOC["업무 프로세스<br/>문서화 · 명문화"]
    W2 -- "도구 선택 이전 단계" --> DOC
    W3 -- "전문성이 곧 산출물" --> DOC
    style W1 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style W2 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style W3 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style DOC fill:#dcfce7,stroke:#22c55e,color:#111827

그리고 이 작업의 결과는 문서로 끝나지 않습니다. 명문화된 프로세스는 그대로 스킬과 에이전트의 입력이 됩니다. 판단 기준과 예외 처리, 승인 지점이 적혀 있는 문서는 그 자체가 에이전트 명세입니다.

flowchart LR
    A["업무 프로세스 문서<br/>판단 기준 · 예외 처리 · 승인 지점"] --> B["스킬<br/>반복 작업 단위"]
    B --> C["에이전트<br/>업무 실행 주체"]
    C --> D["재사용 자산<br/>다른 팀 · 다른 업무로 확장"]
    style A fill:#dbeafe,stroke:#3b82f6,color:#111827
    style B fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style C fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style D fill:#dcfce7,stroke:#22c55e,color:#111827

문서가 얼마나 상세한지가 곧 에이전트의 품질과 직결됩니다. 여기서 순서가 뒤집히면 실패합니다. 도구를 먼저 도입하고 업무를 나중에 문서화하면, 업무 흐름은 그대로인 채 검수 부담만 늘어납니다.

---

탑다운과 바텀업은 하는 일이 다릅니다

문서화만으로는 부족합니다. 팀마다 각자 방식으로 문서를 쓰고 각자 에이전트를 만들면, 개별 팀의 성과는 나와도 조직에 자산이 남지 않습니다.

그래서 위아래에서 동시에 움직여야 합니다. 다만 두 방향이 맡을 일은 서로 다릅니다.

탑다운이 줄 것은 공통 규칙입니다. 문서 양식, 보안·데이터 취급 정책, 도구와 모델 표준, 그리고 시간에 대한 공식 허가까지 입니다.

바텀업이 줄 것은 대상입니다. 무엇을 바꿀지, 어디에 판단이 개입되는지, 어떤 예외가 실제로 발생하는지는 그 업무를 하는 사람만 압니다.

flowchart TB
    TOP["경영진 · 거버넌스<br/>문서 양식 표준 · 보안 데이터 정책<br/>도구 모델 표준 · 주 10시간 공식 인정"]
    FIELD["현업 팀<br/>대상 업무 선정 · 실제 판단 기준<br/>발생하는 예외 · 실사용 검증"]
    TOP -- "공통 규칙과 시간에 대한 허가" --> FIELD
    FIELD -- "현장 사실과 재사용 자산" --> TOP
    style TOP fill:#dbeafe,stroke:#3b82f6,color:#111827
    style FIELD fill:#dcfce7,stroke:#22c55e,color:#111827

한쪽만 움직이면 결과가 부족합니다. 탑다운만 있으면 정책 문서와 가이드라인이 쌓이고 바뀐 업무는 없습니다. 바텀업만 있으면 팀마다 다른 방식의 에이전트가 흩어져 다음 팀이 재사용할 수 없습니다.

---

시작하기 위해 필요한 세 가지 결정

강의 말미에 정리한 AX 바로 시작하기 위한 결정 세 가지입니다.

주 10시간을 공식 업무 시간으로 인정합니다. 이것은 시간 문제가 아니라 승인 문제입니다. 경영진이 명시적으로 인정하지 않으면 문서화 작업은 야근으로 밀리고, 또다른 담당부서도 마찬가지로 멈추게 됩니다.

첫 대상 업무를 하나로 좁혀야 합니다. 전사 프로세스 문서화는 그 자체로 또 하나의 끝나지 않는 프로젝트입니다. 반복적으로 발생하고, 전문가 판단이 개입되고, 담당자가 평소 답답해하던 업무 하나면 충분합니다.

성공 기준을 처리 시간과 품질 편차로 잡습니다. 만든 에이전트 개수를 세기 시작하면 아무도 쓰지 않는 에이전트가 쌓입니다. 그 업무의 소요 시간이 줄었는지, 담당자별 결과 편차가 줄어들었는지를 봅니다.

---

마치며

이 한계는 제가 다녀온 회사만의 사정이 아닙니다. AX를 시작하려는 조직 대부분이 같은 자리에서 멈춰 서 있습니다.

필요한 것은 더 큰 의지가 아닙니다. 담당 부서를 한 번 더 바꾸기 전에, 업무 하나를 골라 문서로 만드는 일부터 시작하면 됩니다.

이 순서가 그 조직에서 통했는지는 몇 달 뒤에 알게 됩니다. 다만 세 번의 시도에서 배운것은 분명합니다. AX가 시작되지 않는 이유는 자원이 부족한 것이 아니라, 지표와 책임이 제대로 설계되지 않았기 때문입니다.