AI 도구가 조직 안에서 살아남는 세 가지 조건

지난 글은 형식지화가 왜 필요한지로 마무리됐습니다. 담당자의 머릿속에서만 작동하던 판단 기준이 명문화되어야, 그 위에서 5개 전문 영역을 구조적으로 보완하는 환경이 실제로 작동할 수 있다는 것이었습니다.

그렇다면 그 환경은 구체적으로 어떤 모습일까요.

하나의 단서가 있습니다. 핸즈온 교육이 끝난 이후에도 도구가 조직 안에서 살아남는 경우가 있습니다. 드물지만 분명히 존재합니다. 그리고 그런 곳에는 공통적으로 세 가지 조건이 갖춰져 있었습니다. 반대로, 세 가지 중 하나라도 빠진 경우에는 나머지 두 가지가 아무리 잘 갖춰져 있어도 결과물은 끝내 조직 자산이 되지 못했습니다.

이 글은 그 조건이 무엇인지, 그리고 각각이 없을 때 HRD 현장에서 실제로 어떤 벽이 생기는지를 살펴봅니다.

첫 번째 조건 — 형식지화를 끌어내는 즉시 질문

지난 글에서 확인했습니다. 형식지화는 혼자 책상에 앉아서 완성할 수 있는 작업이 아닙니다. 수년간 몸에 밴 판단을 언어로 꺼내는 일은, 그 업무를 잘 안다고 해서 자동으로 되지 않습니다. 오히려 업무에 익숙할수록 무엇이 암묵적으로 처리되고 있는지를 의식하기가 더 어렵습니다.

그렇기 때문에 첫 번째 조건은 이것입니다. 참여자가 자신의 업무를 AI 관점에서 분해할 수 있도록, 적절한 질문을 즉시 던져줄 수 있는 사람이 있어야 합니다.

핸즈온 현장에서 형식지화가 실제로 일어나는 순간을 보면 패턴이 있습니다. 참여자가 "이 업무를 자동화하고 싶어요"라고 말했을 때, 강사가 곧바로 되묻습니다.

"그 데이터는 어디서 가져오세요?"
"예외 상황이 생기면 어떻게 처리하세요?"
"결과물을 받아보는 사람이 가장 먼저 확인하는 게 뭔가요?"

이 질문들은 참여자가 스스로는 꺼내지 못했던 과정 데이터를 수면 위로 끌어올립니다. 답하는 과정에서 참여자는 비로소 자신의 업무가 어떤 단계와 판단으로 이루어져 있는지를 인식하게 됩니다. 형식지화가 시작되는 지점입니다.

이 조건이 갖춰지지 않으면 어떻게 될까요.

포텐스닷이 국내 게임기업 핸즈온 54건을 분석한 결과가 있습니다. 본세션 전에 주제 선정 양식만 보냈을 때, 참여자가 제출한 주제 중 22%가 12시간 핸즈온 안에서 구현할 수 없는 수준이었습니다. "AI가 알아서 판단해줬으면 좋겠다"는 바람에 가까운 주제들이었습니다.

문제는 그 22%가 핸즈온 당일에야 드러난다는 것입니다. 참여자는 세션 시작 전까지 자신의 주제가 구현 가능한지 알지 못합니다. 강사는 시작과 동시에 주제 자체를 다시 설정해야 하고, 그 시간이 설계 허들로 고스란히 전환됩니다. 어렵게 마련한 12시간이 주제를 바꾸는 데 일부 쓰이는 것입니다.

즉시 질문이 구조적으로 설계되어 있어야 하는 이유입니다. 본세션 전에 강사가 참여자의 업무를 직접 들여다보고 질문을 던지는 시간이 확보되어야, 형식지화가 핸즈온 당일이 아닌 그 이전에 이미 시작됩니다. 참여자가 자신의 업무를 AI 관점에서 분해한 상태로 본세션에 들어올 수 있게 됩니다.

그런데 이것만으로는 충분하지 않습니다.

두 번째 조건 — 5개 전문 영역이 구조적으로 보완되는 도구

형식지화가 이루어졌다고 해서 도구가 완성되는 것은 아닙니다. 2편에서 살펴봤듯이, 조직에서 실제로 쓰이는 AI 도구를 만들려면 서비스 기획, 데이터 설계, 데이터베이스, UX/UI, 아키텍처와 보안, 다섯 개의 전문 영역이 동시에 필요합니다. 형식지화는 이 다섯 개 영역이 실제로 작동하기 위한 전제 조건이지, 영역 자체를 대체하지는 않습니다.

그렇다면 이 다섯 개 영역은 핸즈온 현장에서 어떻게 보완될 수 있을까요.

가장 먼저 떠오르는 답은 강사나 코치를 늘리는 것입니다. 그런데 이 방법은 구조적으로 한계가 있습니다. 강사 한 명이 참여자 개인의 업무 맥락을 파악하면서, 동시에 다섯 개 전문 영역을 실시간으로 코칭하는 것은 불가능합니다. 코치를 다섯 명으로 늘린다고 해도 마찬가지입니다. 각 참여자의 업무가 다르고, 그에 따라 필요한 설계와 판단도 매번 달라지기 때문입니다. 영역별 전문가가 필요한 문제를 인력으로 풀려고 하면, 인원이 늘수록 비용은 커지지만 결과의 편차는 줄어들지 않습니다.

이 조건이 갖춰지지 않으면 어떻게 될까요.

포텐스닷이 170개사 핸즈온을 운영하며 반복적으로 관찰한 장면이 있습니다. 완성도가 높아 보이는 도구도 배포 단계에서 막히는 경우가 생깁니다. 핸즈온 안에서는 작동하는 것처럼 보였지만, 사내 IT·보안 심사에 가져갔을 때 문제가 드러납니다. 외부 AI 서버로 데이터가 나가는 구조였거나, 데이터베이스 설계가 빠진 채 로컬 파일에 의존하는 방식이었거나, 여러 사람이 동시에 쓸 때를 고려하지 않은 화면 구조였거나. 핸즈온 결과물의 완성도가 '중하'에 머무는 이유 중 상당수는 콘텐츠의 문제가 아니라 이 다섯 개 영역이 설계 과정에서 빠졌기 때문입니다.

참여자가 다섯 개 영역을 몰라도, 도구를 만드는 과정에서 그 영역들이 구조적으로 채워질 수 있어야 합니다. 이것이 두 번째 조건이 채워야 할 자리입니다.

세 번째 조건 — 사내 배포가 처음부터 설계된 구조

여기서 또 하나의 벽이 기다리고 있습니다. 도구가 만들어졌다고 해서 조직에서 쓰이는 것은 아닙니다. 1편에서 확인했듯이, 핸즈온 안에서 완성된 도구는 대부분 만든 사람 본인만 사용할 수 있는 형태입니다. 동료가 같은 도구를 쓰려면 별도 설명이 필요하고, 사내에서 배포할 절차와 환경이 갖춰져 있지 않으면 개인 자산에서 조직 자산으로 전환되지 못합니다.

그런데 이 지속성 허들에는 한 가지 구조적 특성이 있습니다. 도구를 다 만든 뒤에 배포를 고려하면, 이미 늦는 경우가 생긴다는 것입니다.

핸즈온 결과물을 사내 IT·보안팀에 가져갔을 때 이런 답변이 돌아오는 경우가 있습니다.

"이건 외부 AI 서버로 데이터가 나가는 구조라 사내 배포가 어렵습니다."

도구 자체에는 문제가 없습니다. 핸즈온 안에서는 작동했습니다. 그러나 설계 단계에서 보안을 고려하지 않은 채 만들어진 도구는, 완성된 이후에도 사내 배포 자체가 불가능해지는 상황이 생깁니다. 처음부터 다시 만들지 않는 이상 구조를 바꾸기 어렵기 때문입니다.

이 조건이 갖춰지지 않으면 결과는 하나입니다. 어렵게 만든 도구가 만든 사람의 개인 PC 안에서 끝납니다. 팀 전체가 쓰는 도구로 자리 잡지 못하고, 담당자가 자리를 옮기는 순간 그 도구가 담고 있던 업무 노하우도 함께 사라집니다.

세 번째 조건이 의미하는 바는 이것입니다. 사내 배포는 도구가 완성된 이후에 고려할 문제가 아닙니다. 도구를 만들기 시작하는 순간부터 배포 가능한 구조로 설계되어야 합니다. 보안, 공유, 유지보수가 처음부터 설계 안에 들어와 있어야 도구가 개인 자산이 아닌 조직 자산으로 살아남을 수 있습니다.

세 조건을 다시 정리하면 이렇습니다. 형식지화를 끌어내는 즉시 질문, 5개 전문 영역이 구조적으로 보완되는 도구, 사내 배포가 처음부터 설계된 구조. 이 세 가지가 동시에 갖춰질 때 비로소 도구가 조직 안에서 살아남는 환경이 만들어집니다.

문제는 이 세 조건이 각각 독립된 전문 영역에 걸쳐 있다는 것입니다. HRD 담당자가 교육 기획 안에서 세 가지를 동시에 설계하는 것은 현실적으로 어렵습니다. 강사 선정과 커리큘럼 구성만으로는 채울 수 없는 영역들이기 때문입니다.

포텐스닷은 이 세 조건을 하나의 구조 안에 담았습니다. 그것이 포텐스닷 Foundry입니다. 그 구조가 실제로 작동할 때 조직에 어떤 변화가 생기는지는 다음 글에서 이어가겠습니다.