회사 대표를 위한 90일 AI-First 전환 계획

1. 수익을 내는 AI-First의 출발점은 운영 모델(Operating Model)

AI-First라는 말은 너무 흔하게 쓰여서, 대개 모든 직원에게 도구를 사 주고 알아서 나아지기를 기다리는 것으로 끝납니다. 결과를 가르는 것은 돈이 새고 있다는 것을 아는 프로세스 하나를 골라, 개선 효과를 숫자로 잴 수 있을 때까지 고치는 일입니다.

직원에게 도구를 나눠 주면 개인의 생산성은 오를 수 있습니다. 하지만 회사에는 같은 절차, 같은 인계 과정, 같은 인원이 그대로 남습니다. 조직 차원의 AI-First는 데이터가 자동으로 흐르고, 표준 업무는 시스템이 처리하며, 사람은 예외와 결과를 책임지도록 업무 프로세스를 설계하는 일입니다.

90일 안에 모든 부서를 바꾸겠다고 약속해서는 안 됩니다. 현실적인 목표는 워크플로 한두 개를 운영 환경에서 검증하고, 데이터, 보안, 성과 측정의 기준을 세우고, 다음 프로젝트 후보를 줄 세워 두는 것입니다. 그래야 교육 한 번 하고 끝나는 대신 회사가 계속 변화할 수 있는 역량을 갖게 됩니다.

2. 날짜를 세기 전에 정할 다섯 가지 관리 원칙

첫날을 시작하기 전에 두 가지를 합의하십시오. 성공 여부를 판단할 숫자가 무엇인지, 그리고 그 숫자가 나오지 않을 때 프로젝트를 멈출 권한이 누구에게 있는지입니다. 이 두 가지가 분명하지 않으면 90일은 논쟁으로 끝납니다.

1. 비즈니스 성과 우선: 모든 활용 사례(Use Case)는 매출, 비용, 속도, 위험 중 하나와 연결되어야 합니다. 데모가 흥미롭다는 이유로 승인하지 않습니다.
2. 한 번에 프로세스 하나: 업무 흐름 하나를 처음부터 끝까지 고릅니다. 작은 도구를 여기저기 흩어 놓아 효과를 잴 수 없게 만들지 않습니다.
3. 책임은 사람에게: AI는 책임을 질 수 있는 자리에 있지 않습니다. KPI와 사고(Incident)에 대한 책임은 여전히 프로세스 책임자에게 있습니다.
4. 설계 단계부터 보안: 권한, 데이터, 로그, 시스템이 할 수 있는 행동의 범위는 운영 환경에 올리기 전에 정해야 합니다.
5. 근거에 따른 확대: 사용자, 권한, 예산은 품질과 ROI가 기준을 통과했을 때 늘립니다. 압박 때문에 확대하지 않습니다.

작은 추진팀(Steering Team)을 꾸리십시오. 대표나 후원 임원, 프로세스 책임자, 그리고 데이터, 기술, 보안 담당자가 들어갑니다. 정해진 주기로 모여 결정합니다. 모두가 거부권을 쥐고 있지만 아무도 결과를 책임지지 않는 큰 위원회는 만들지 마십시오.

3. 1~15일 차: 기준선(Baseline) 측정과 첫 대상 선정

1~5일 차: 비즈니스 목표를 발표합니다. 예를 들어 사람을 더 뽑지 않고 50% 늘어난 업무량을 감당하겠다거나, 고객 응답 시간을 네 시간에서 20분으로 줄이겠다는 식입니다. 임시로 허용할 데이터와 도구의 범위를 정하고, 안전하게 시험해 볼 수 있는 통로를 마련해 섀도 AI(Shadow AI), 즉 승인받지 않은 AI 도구 사용을 막습니다.

6~10일 차: 부서마다 프로세스를 세 개까지 제안하게 하고, 업무량, 소요 시간, 비용, 책임자를 함께 적게 합니다. 업무량, 데이터 준비 상태, 결과를 검증하기 쉬운 정도, 위험도를 기준으로 점수를 매겨 주력 프로젝트 하나와 예비 프로젝트 하나를 고릅니다.

11~15일 차: 업무 흐름도(프로세스 맵)를 그리고 실제 작업 시간을 잽니다. 사례 50~100건을 모아 낮음, 중간, 높음 세 가지 비즈니스 케이스(투자 타당성 근거)를 만듭니다. 목표는 품질과 비용의 가드레일까지 포함해 측정할 수 있게 쓰고, 시스템이 할 일과 사람이 확인할 일, 멈춰야 할 시점을 정해 둡니다.

4. 16~30일 차: 가설을 검증하는 시범 운영 만들기

섀도 모드(Shadow Mode)로 시작하십시오. 시스템이 실제 업무를 받아 직원과 나란히 결과를 만들되, 외부로 보내거나 실제로 실행하지는 않습니다. 답변, 소요 시간, 오류 유형을 비교합니다. 과거 데이터로만 테스트해서는 부족합니다. 실시간 데이터의 상태나 사용자의 실제 행동이 드러나지 않기 때문입니다.

표준 사례, 정보가 빠진 사례, 격식 없는 말투, 서로 모순되는 정보, 위험한 사례를 담은 평가 세트(Evaluation)를 만드십시오. "답이 괜찮아 보인다"는 느낌으로 판단하지 말고 업무 기준의 정확도를 재야 합니다. 다섯 개 항목이 모두 채워졌는지, 가격을 올바른 시스템에서 가져왔는지, 승인 경로를 제대로 골랐는지 같은 것들입니다.

이 기간에는 요청이 들어올 때마다 기능을 추가하지 마십시오. 요청은 KPI에 꼭 필요한 것, 안전에 꼭 필요한 것, 나중에 해도 되는 편의 기능으로 나눕니다. 핵심 접근 방식이 해 볼 가치가 있는지 답을 얻으려면 프로덕트 오너(Product Owner)가 범위를 지켜야 합니다.

5. 31~60일 차: 시범 운영을 책임 소재가 분명한 실제 서비스로 전환하기

41~50일 차: 작은 사용자 그룹에 시스템을 엽니다. 시스템이 초안을 만들고 사람이 매번 승인합니다. Feedback은 잘못된 데이터, 잘못된 규칙, 부적절한 표현, 원천 시스템 준비 미흡처럼 유형별로 모읍니다. 모든 문제를 Prompt 수정으로 때우지 말고 원인을 고칩니다.

51~60일 차: 몇 주 동안 근거가 쌓인 표준 사례에만 Straight-through 처리를 켭니다. 자동 처리된 작업을 무작위로 점검하고, Incident Drill로 팀이 시스템을 멈추고, 무슨 일이 있었는지 거슬러 확인하고, 수작업으로 일을 이어 갈 수 있는지 시험합니다.

SOP(표준 운영 절차)와 직무기술서도 그에 맞게 고치십시오. 직원이 "혹시 모르니까" 매번 예전 절차를 되풀이하면 절감 효과는 생기지 않습니다. 새 점검 지점을 합의하고, 시스템이 안정되면 병행하던 파일과 보고서를 없애야 합니다.

6. 61~90일 차: 가치를 실제로 거둬들이고 규율 있게 확대하기

71~80일 차: 권한 시스템, Connector, Template, Evaluation, Monitoring, 승인 가이드라인 같은 Reusable Components를 만듭니다. 데이터와 Change Management에서 얻은 교훈을 기록해 다음 프로젝트가 처음부터 다시 시작하지 않게 합니다.

81~90일 차: 다음 Use Case는 데이터를 보고 고릅니다. 기존 프로세스의 적용 범위를 넓힐 수도 있고, Playbook을 다른 부서로 옮길 수도 있습니다. Portfolio를 Now, Next, Later로 정리하고, 책임자나 ROI가 없는 프로젝트는 거절합니다.

7. 중간 규모 회사에 필요한 팀과 거버넌스(Governance)

큰 AI 부서를 따로 만들 필요는 없습니다. 다만 모든 시스템에는 업무 책임자(Business Owner), 기술 책임자(Technical Owner), 데이터 책임자(Data Owner)가 있어야 하고, 위험을 승인할 사람과 사고 보고를 받을 사람도 정해 두어야 합니다. 외부 개발사를 쓰더라도 업무와 데이터에 대한 책임은 회사 안에 있어야 합니다.

AI 시스템 대장을 만들어 시스템마다 책임자, 목적, 데이터, 모델, 권한, 공급업체, 비용, 검토일을 적어 두십시오. 관리하는 사람 없이 도구만 퍼지는 일을 막을 수 있고, 직원이 퇴사하거나 공급업체가 바뀌어도 어느 시스템이 무슨 일을 하는지 회사가 계속 알 수 있습니다.

8. 대표가 매달 봐야 할 대시보드

AI 시스템마다 확대(Scale), 개선(Improve), 종료(Retire) 중 무엇을 할지 검토하십시오. 모든 시스템에는 수명 주기가 있어야 하며, 월 사용료가 적어 보인다고 켜 둔 채 내버려 두어서는 안 됩니다. 사용자도 성과도 없는 시스템은 끄십시오. 위험에 노출되는 범위와 숨은 비용이 함께 줄어듭니다.

요약: 회사가 프로세스 하나에 집중해 기준선을 재고, 섀도 모드로 시험하고, 운영 환경에 올리기 전에 통제 장치를 갖추고, 가동 후 실제 가치를 거둬들인다면, 90일 안에 AI-First 역량을 충분히 만들 수 있습니다. 목표는 표준 업무는 시스템이 처리하고 사람은 예외, 판단, 혁신을 맡는 운영 모델이며, 도구를 몇 개 갖췄는지는 중요하지 않습니다.