어렵게 만든 AI USE-CASE, 왜 조직 자산이 되지 못하는가

생성형 AI 핸즈온 교육이 끝나고 나면, HRD 담당자들은 한 가지 불편한 질문을 마주합니다.

"참여자들이 직접 만든 USE-CASE, 지금도 쓰고 있을까?"

현장에 확인해보면 대부분 비슷한 답이 돌아옵니다. 참여자 본인은 간간이 활용하지만, 팀 내 다른 동료는 쓰지 않습니다. 업무 방식이나 데이터가 조금이라도 바뀌면, 어렵게 만든 USE-CASE를 다시 꺼내기가 어렵습니다.

교육 자체에 문제가 있었던 것은 아닙니다. 참여자들은 핸즈온 세션에서 실제로 도구를 만들었고, 강사의 코칭을 받아 의미 있는 결과물을 완성했습니다. 그러나 교육이 끝난 순간, 그 결과물은 조직 안에서 더 이상 자라지 못했습니다.

왜 어렵게 만든 USE-CASE가 한 사람의 경험으로 끝나는 걸까요? 이 글은 그 이유를 짚고, HRD 담당자가 다음 AI 교육을 기획할 때 무엇을 다르게 설계해야 하는지를 이야기합니다.

포텐스닷은 지금까지 140여개 고객사에서 800여개의 use-case를 도출하는 AI 핸즈온 교육을 운영했습니다. 참여자 대부분은 세션 안에서 실제로 작동하는 결과물을 만들어냈고, 평균 구현 성공률은 96.5%에 달했습니다.

그런데 현장에서 일관되게 관찰되는 패턴이 있었습니다.

참여자의 역량에 따라 결과물의 편차가 큽니다. 누군가는 복잡한 업무 흐름을 정교하게 자동화한 도구를 만들지만, 누군가는 데이터를 단순히 합치고 가공하는 수준에 머뭅니다. 이 편차 때문에 한 세션에 참여할 수 있는 인원도 제한적입니다.

더 근본적인 문제는 교육 이후에 드러납니다.

결과물의 수준과 상관없이, 교육이 끝나면 대부분의 결과물은 조용히 사라집니다. 팀 전체가 함께 쓰는 도구로 자리 잡은 경우는 드물고, 업무 방식이 조금이라도 바뀌면 다시 꺼내기가 어렵습니다. 어렵게 만든 use-case가 결국 '그 당시의 경험'으로만 남는 것입니다.

이 패턴이 반복되는 이유는 세 가지 허들로 설명됩니다.

첫 번째는 설계 허들입니다.

자신의 업무에서 풀고 싶은 문제를 정의하는 것만으로는 충분하지 않습니다. 문제가 정해진 이후에도 그것을 해결하는 방법은 무한합니다. 마치 부산을 가는 방법이 무수히 많듯이, 하나의 업무 문제를 AI로 해결하는 방식도 셀 수 없이 많습니다. 어떤 방법이 자신의 업무 환경에 맞는지 선택하려면 다음과 같은 결정들이 필요합니다. 어떤 단계와 시나리오로 문제를 해결할지, 각 단계에서 어떤 기술을 쓸지, 어떤 데이터가 입력되고 어떤 결과물이 출력될지, 그리고 그 데이터를 저장해야 하는지 아니면 사용 후 버려도 되는지. 이런 결정들은 IT 개발 경험 없이는 감을 잡기조차 어렵습니다. 결국 참여자의 업무 역량이 아무리 뛰어나도, 설계 경험이 없으면 이 단계에서 멘토 의존도가 높아지고 편차가 벌어집니다.

두 번째는 구현 허들입니다.

설계가 끝나도 만드는 과정은 험난합니다. 최근에는 바이브코딩 도구들이 등장하면서 구현 속도가 빨라졌지만, 기업 보안 환경에서는 외부 AI 도구 접근이 제한되는 경우가 많아 이러한 속도 향상을 그대로 활용하기 어렵습니다. 결국 참여자 스스로 구현하는 속도에 의존할 수밖에 없고, 설계가 정교하지 않으면 시행착오가 반복됩니다. 설계를 잘못 잡으면 구현 도중 처음부터 다시 설계해야 하는 상황이 발생하고, 핸즈온 시간 안에서 이 루프가 반복되다 시간이 끝납니다. 여기에 멘토가 1:10 구조로 운영되다 보니, 즉각적인 1:1 코칭이 필요한 순간에 대기가 생깁니다. 대기하는 동안 집중이 끊기고, 흐름을 되찾는 데도 시간이 소요됩니다.

세 번째는 지속성 허들입니다.

교육 안에서 도구가 만들어졌다고 해서 조직 안에서 살아남는 것은 아닙니다. 완성된 도구는 대부분 만든 사람 본인만 사용할 수 있는 형태입니다. 동료가 같은 도구를 쓰려면 별도 설명이 필요하고, 설명 없이는 쓰기 어렵습니다. 설령 공유하려 해도, 사내에서 도구를 배포할 절차와 환경이 갖춰져 있지 않으면 개인 자산에서 조직 자산으로 전환되지 못합니다. 보안을 고려한 개발이 처음부터 이루어지지 않은 도구는 사내 배포 자체가 불가한 경우도 생깁니다. 유지보수도 문제입니다. 도구를 만든 사람이 담당 업무가 바뀌거나 조직을 떠나면, 그 구조를 이해하는 사람이 없어 작은 수정조차 불가능해집니다. 어렵게 만든 도구가 결국 개인 PC 안에 머물다 잊혀지는 이유입니다.

그렇다면 강사를 바꾸거나 커리큘럼을 개선하면 해결될까요?

세 가지 허들을 다시 살펴보면, 어느 것도 교육 콘텐츠의 문제가 아닙니다. 설계 허들은 참여자가 자신의 업무를 AI 관점에서 분해하고 판단하는 경험이 없어서 생깁니다. 구현 허들은 기업 보안 환경이라는 구조적 제약과 제한된 시간 안에서 설계와 구현을 동시에 해결해야 하는 조건에서 비롯됩니다. 지속성 허들은 교육이 끝난 이후의 배포, 확산, 유지보수를 누가 어떻게 책임지는지가 설계되어 있지 않아서 발생합니다.

이 세 허들의 공통점은 하나입니다. 교육 안에 실제 업무 도구를 만들고, 조직 안에서 살아남게 하는 과정이 설계되어 있지 않다는 것입니다.

지금까지의 AI 핸즈온 교육은 "어떻게 만드는가"를 가르치는 데 집중했습니다. 그러나 조직에서 실제로 쓰이는 도구가 되려면 "무엇을 어떻게 설계할 것인가"부터 "만든 도구를 어떻게 조직 안에 안착시킬 것인가"까지를 교육 체계 안에 담아야 합니다. 콘텐츠의 문제가 아니라, 설계의 문제입니다.

use-case를 만드는 것과 조직에서 쓰이는 도구를 만드는 것은 다른 문제입니다.

지금까지 많은 기업이 AI 핸즈온 교육에 시간과 비용을 투자해왔습니다. 그러나 설계 허들, 구현 허들, 지속성 허들이 해결되지 않은 채로는, 교육의 품질과 무관하게 결과물은 개인의 경험으로 끝납니다. 조직 자산이 되지 못하는 도구는 아무리 정교해도 의미가 없습니다.

다음 AI 핸즈온 교육을 기획할 때, 한 가지 질문을 먼저 던져보시길 권합니다. "우리 교육은 도구를 만드는 것까지 설계되어 있는가, 아니면 조직 안에서 살아남는 것까지 설계되어 있는가."

이 세 가지 허들은 사실 하나의 구조적 문제에서 비롯됩니다. 비개발자가 조직에서 실제로 쓰이는 AI 도구를 만들려면, 한 사람이 감당하기 어려운 여러 전문 영역이 동시에 필요합니다. 그것이 무엇인지는 다음 글에서 이어가겠습니다.