비개발자가 AI 도구를 못 만드는 진짜 이유

생성형 AI 핸즈온 교육을 기획할 때, HRD 담당자가 가장 많이 받는 질문이 있습니다.

"이번에는 참여자들이 실제 업무에 쓸 수 있는 AI use-case를 만들 수 있나요?"

현장의 요구는 분명합니다. 단순히 AI를 체험하는 것이 아니라, 내 업무에 바로 적용할 수 있는 use-case를 손에 쥐고 돌아가는 것. 실제로 잘 설계된 핸즈온 교육이라면 이 목표는 달성됩니다. 참여자들은 세션 안에서 자신의 업무를 분석하고, 강사의 코칭을 받아 실제로 작동하는 use-case를 만들어냅니다.

문제는 그 다음입니다. 만들어진 use-case가 팀 전체로 퍼지지 않습니다. 업무 방식이 조금 바뀌면 다시 꺼내기가 어렵습니다. 결국 어렵게 만든 결과물이 개인의 경험으로 끝납니다.

이 문제를 두고 HRD 담당자들은 대부분 비슷한 결론에 도달합니다. "참여자들의 역량이 부족한 것 같다." 혹은 "교육 시간이 더 필요하다."

하지만 진짜 이유는 다른 곳에 있습니다. 비개발자가 조직에서 실제로 쓰이는 AI 도구를 만들려면, 한 사람이 혼자 감당할 수 없는 전문 영역들이 동시에 필요합니다. 이것은 참여자의 문제가 아니라, 구조의 문제입니다.

핸즈온이 끝난 자리에 남는 것

생성형 AI 핸즈온 교육에서 반복적으로 관찰되는 세 가지 허들이 있습니다. 무엇을 만들지 결정하는 설계 허들, 실제로 만드는 구현 허들, 그리고 만든 도구가 조직 안에서 살아남는 지속성 허들입니다. 이 부분은 지난 글 '어렵게 만든 AI USE-CASE, 왜 조직 자산이 되지 못하는가'에서 자세히 다뤘습니다.

포텐스닷이 140여 개 고객사에서 핸즈온 교육을 운영하며 확인한 수치가 있습니다. 참여자들의 평균 구현 성공률은 96.5%입니다. 숫자만 보면 교육은 성공입니다.

그런데 이 세 가지 허들에는 공통점이 하나 있습니다. 각각의 허들을 넘으려면 서로 다른 전문 영역이 동시에 필요하다는 것입니다. 설계 허들을 넘으려면 업무의 흐름을 기술 요구사항으로 번역할 수 있어야 합니다. 구현 허들을 넘으려면 데이터를 어떻게 처리하고 저장할지를 판단할 수 있어야 합니다. 지속성 허들을 넘으려면 만든 도구를 동료가 쓸 수 있는 형태로 설계하고, 사내 보안 환경에서 안전하게 배포할 수 있어야 합니다.

96.5%가 세션 안에서 use-case를 만들어냈음에도, 이 허들들이 해결되지 않은 채로는 결과물이 개인의 경험으로 끝납니다. 이것은 참여자의 역량 문제가 아닙니다. 조직에서 실제로 쓰이는 AI 도구를 만들려면, 핸즈온 세션 안에서 해결하기 어려운 전문 영역들이 동시에 필요합니다.

조직에서 쓰이는 AI 도구를 만들려면 필요한 것들

설계·구현·지속성, 세 가지 허들을 넘으려면 다섯 개의 전문 영역이 동시에 필요하다고 했습니다. 그 다섯 개가 실제로 어떻게 맞물리는지, 구체적인 상황을 따라가 보겠습니다.

"매주 월요일 아침, 전국 영업팀의 실적 데이터를 취합해서 임원 보고용 주간 보고서를 만드는 업무를 AI로 자동화하고 싶다."

핸즈온 세션에서 이 주제를 잡은 참여자가 있다고 가정해봅시다. 요구사항은 명확해 보입니다. 그런데 세 가지 허들을 넘는 도구를 만들기 시작하는 순간, 다섯 개의 전문 영역이 동시에 필요해집니다.

서비스 기획은 유지보수 가능한 도구를 만들기 위한 전제 조건입니다. 영업 실적 데이터는 어디서 가져오는가? 각 팀이 별도 양식으로 보내오는가, 아니면 ERP 시스템에서 추출하는가? 데이터가 누락되거나 양식이 맞지 않으면 어떻게 처리하는가? 이 질문들에 명확한 답이 없으면, 만든 사람이 자리를 옮기는 순간 구조를 이해하는 사람이 없어 작은 수정조차 불가능해집니다.

데이터 설계는 동료가 설명 없이 도구를 쓸 수 있게 만드는 핵심 영역입니다. 임원용 요약본이라는 결과물은 눈에 보이지만, 그 결과물을 만들기 위해 AI에게 전달해야 하는 것은 따로 있습니다. "지난주 대비 증감률을 어떻게 해석할 것인가", "어떤 지역의 실적이 특히 주목받아야 하는가"와 같은 판단 기준입니다. 이 판단 기준은 베테랑 영업 관리자의 머릿속에만 있습니다. 이것이 도구 안에 정의되지 않으면, 만든 사람 외에는 원하는 결과물을 얻을 수 없습니다.

아키텍처와 보안은 사내 배포를 가능하게 하는 영역입니다. 영업 실적 데이터는 민감한 정보입니다. 외부 AI 서비스로 이 데이터를 전송해도 되는가? 온프레미스 환경에서만 처리해야 하는가? 처음부터 이 판단 없이 만들어진 도구는 완성 후에도 사내 배포 자체가 불가능해지는 경우가 생깁니다.

나머지 두 영역도 마찬가지입니다. 데이터베이스는 취합된 실적 데이터를 어디에 어떻게 저장할지를 결정해 유지보수 가능한 구조를 만드는 일이고, UX/UI는 매주 보고서를 실제로 생성하는 담당자가 설명 없이도 도구를 쓸 수 있도록 사용성을 설계하는 일입니다.

하나의 보고서 자동화 도구를 만드는 데 다섯 개의 전문 영역이 동시에 맞물립니다. 핸즈온 세션에서 참여자 한 명이 이것을 혼자 해결하는 것은 처음부터 불가능한 조건입니다.

더 좋은 교육으로 해결되지 않는 이유

그렇다면 강사를 더 뛰어난 사람으로 바꾸거나, 핸즈온 시간을 늘리면 해결될까요.

다섯 개 영역을 다시 떠올려보면, 어느 것도 교육 콘텐츠의 문제가 아닙니다. 서비스 기획, 데이터 설계, 데이터베이스, UX/UI, 아키텍처와 보안은 각각 독립적인 전문 영역입니다. 핸즈온 세션 안에서 강사 한 명이 참여자 개인의 업무 맥락을 파악하면서 이 다섯 가지를 동시에 코칭하는 것은 구조적으로 불가능합니다. 시간을 두 배로 늘려도, 강사를 두 명으로 늘려도 본질은 달라지지 않습니다.

결국 문제는 하나로 귀결됩니다. 비개발자가 혼자 감당하기 어려운 다섯 개 영역을, 교육 현장에서 참여자 개인이 해결하도록 설계되어 있다는 것입니다.

해결의 방향은 교육의 질을 높이는 것이 아닙니다. 비개발자가 이 다섯 개 영역을 보완받으면서 도구를 만들 수 있는 환경을 설계하는 것입니다. 그 환경을 설계하려면, 먼저 참여자의 머릿속에 있는 업무 지식이 왜 AI에게 전달되지 않는지를 이해해야 합니다. 그것이 무엇인지는 다음 글에서 이어가겠습니다.

능력의 문제가 아니라, 구조의 문제입니다

생성형 AI 핸즈온 교육에서 use-case는 만들어집니다. 문제는 그 다음입니다. 동료가 쓸 수 있어야 하고, 사내에 배포할 수 있어야 하며, 만든 사람이 없어도 유지보수가 가능해야 합니다. 이 세 가지 조건을 충족하려면 다섯 개의 전문 영역이 뒷받침되어야 합니다.

이것을 참여자의 역량 부족으로 해석하면, HRD 담당자는 계속 같은 자리를 맴돌게 됩니다. 더 좋은 강사를 찾고, 더 긴 교육을 기획하고, 다음 핸즈온에서도 비슷한 결과를 마주합니다.

구조의 문제는 구조로 풀어야 합니다. 그 구조를 설계하려면 먼저 해결해야 할 것이 있습니다. 참여자의 머릿속에 있는 업무 지식이 왜 AI에게 전달되지 않는지, 그리고 그것을 어떻게 꺼낼 수 있는지입니다. 다음 글에서는 그 이야기를 이어가겠습니다.