포텐스닷 파운드리, 세 조건은 이렇게 채워진다

지난 글은 이렇게 끝났습니다. "포텐스닷은 이 세 조건을 하나의 구조 안에 담았습니다. 그것이 Potens. Foundry(포텐스닷 파운드리)입니다."

포텐스닷 Foundry(이하 파운드리)는 포텐스닷이 자체 개발한 도구로, 비개발자가 자기 업무 워크플로우를 AI가 실행할 수 있는 도구로 만들 수 있도록, 다섯 개 전문 영역을 자동으로 보완해줍니다.

그런데 이 문장만으로는 아직 아무것도 증명되지 않았습니다. 형식지화를 끌어내는 즉시 질문, 5개 전문 영역이 구조적으로 보완되는 도구, 사내 배포가 처음부터 설계된 구조. 세 조건은 각각 서로 다른 전문성을 요구합니다. 이 세 가지를 "하나의 구조 안에 담았다"는 말이 실제로 무엇을 의미하는지, HRD 담당자 입장에서는 구체적으로 확인하고 싶은 게 당연합니다.

이 글은 그 확인 과정입니다. 파운드리가 세 조건 각각을 어떤 방식으로 해결하는지, 그리고 그 결과가 핸즈온 현장에서 실제로 어떤 숫자로 나타나는지를 살펴봅니다.

사전 단계로 옮겨진 즉시질문

첫 번째 조건은 참여자가 스스로는 꺼내지 못하는 과정 데이터를, 강사의 즉시 질문으로 끌어내는 것이었습니다. 그런데 이 질문이 핸즈온 당일 처음 던져지면 늦습니다. 지난 글에서 확인했듯, 본세션이 시작되고 나서야 주제 자체를 다시 잡아야 하는 상황이 생기면, 어렵게 마련한 시간이 설계 허들로 그대로 소진됩니다.

파운드리 체계는 이 조건을 본세션 안이 아니라, 본세션이 시작되기 전 단계로 옮깁니다. 형태는 조직 상황에 따라 다릅니다. 라이브 워크숍으로 별도 시간을 잡을 수도 있고, 사전 실습교육 과정 안에 주제도출 과정으로 포함시킬 수도 있습니다. 어떤 방식이든 공통된 원칙은 하나입니다. 참여자가 먼저 자기 업무를 스스로 분해해보고, 그 결과를 놓고 강사가 즉시 질문으로 점검하고 보완하는 단계를 거친다는 것입니다. 지난 글에서 확인한 강사의 질문들, "그 데이터는 어디서 가져오세요?", "예외 상황이 생기면 어떻게 처리하세요?" 같은 것들이 여기서 다시 등장합니다. 여기에 하나가 더 붙습니다. "30분이면 된다고 했는데 90분 걸리면 왜 그런가요?"처럼, 참여자가 스스로 적어낸 시간 추정치와 실제 사이의 간극을 파고드는 질문입니다.

이 구조가 의미하는 것은 이렇습니다. 본세션 당일 강사 한 명이 참여자 개개인의 업무를 처음 듣고 즉석에서 질문하는 방식과, 본세션이 시작되기 전에 이미 스스로 분해해보고 한 차례 점검까지 받은 상태로 들어오는 방식은 다른 결과로 이어질 수밖에 없습니다. 무엇을 만들지에 대한 합의가 어느 정도 마련된 채로 본세션에 들어올 수 있도록, 처음부터 이렇게 설계되어 있는 것입니다.

지난 글에서 언급한 수치를 다시 가져오면, 주제 선정 양식만 보냈을 때는 참여자가 제출한 주제 중 22%가 12시간 안에서 구현할 수 없는 wish-level 수준이었습니다. 이 문제가 반복되는 이유는 명확합니다. 양식은 참여자 혼자 채우는 것이고, 즉시 질문이 빠져 있기 때문입니다. 사전 단계에 강사의 즉시 질문이 구조적으로 포함되면, 문제의 성격 자체가 달라집니다.

첫 번째 조건이 채워지는 방식은 결국 이것입니다. 좋은 질문을 아는 강사를 배치하는 것이 아니라, 그 질문이 던져지는 시점을 본세션 밖으로 명확히 분리하는 것. 형식지화는 그렇게 핸즈온 당일이 아니라, 그 이전부터 시작됩니다.

다섯 개 영역, 형식지화만으로는 채워지지 않는 자리

2편에서 확인했듯, 형식지화가 이루어져도 서비스 기획, 데이터 설계, 데이터베이스, UX/UI, 아키텍처와 보안, 다섯 개 영역은 별도로 채워져야 합니다. 파운드리는 이 다섯 자리를 참여자가 몰라도 AI 도움으로 채웁니다.

서비스 기획에서 걸리던 문제는 이것이었습니다. "이 업무는 왜 발생하는가", "예외 상황은 어떻게 처리하는가" 같은 질문에 명확한 답이 없으면, 만든 사람이 자리를 옮기는 순간 아무도 그 구조를 이해하지 못합니다. 파운드리는 사전 단계에서 이미 정리된 답을 그대로 이어받아, 도구를 만드는 과정에서 이 구조를 문서로 남깁니다. 만든 사람이 없어도 구조를 읽을 수 있는 상태로 남는 이유입니다.

데이터 설계에서 걸리던 문제는 판단 기준이었습니다. 베테랑 담당자의 머릿속에만 있던 판단 기준이 도구 안에 정의되지 않으면, 만든 사람 외에는 원하는 결과물을 얻을 수 없습니다. 이 판단 기준은 이미 사전 단계에서 형식지화를 거친 것이므로, 파운드리는 이걸 새로 끌어내는 대신 그대로 도구 안에 반영합니다.

데이터베이스에서 걸리던 문제는 두 가지였습니다. 저장 방식이 결정되지 않으면 유지보수가 어렵고, 데이터베이스 설계 없이 로컬 파일에만 의존하면 완성된 도구도 사내 배포 단계에서 막힙니다. 파운드리는 어떤 데이터를 임시로 쓰고 버릴지, 어떤 데이터를 계속 저장해야 할지를 모듈 단위로 자동 판단합니다. 참여자가 직접 결정할 필요가 없는 판단입니다.

UX/UI에서 걸리던 문제도 마찬가지입니다. 설명 없이는 동료가 못 쓰고, 여러 사람이 동시에 쓰는 상황을 고려하지 않은 화면은 팀 전체의 도구로 자리 잡지 못합니다. 파운드리는 만든 사람 한 명만 이해하는 화면이 아니라, 동료가 설명 없이도 바로 쓸 수 있는 구조로 화면을 구성합니다.

아키텍처와 보안에서 걸리던 문제가 가장 치명적입니다. 처음부터 이 판단이 없으면 완성된 도구도 사내 배포 자체가 불가능해지고, 외부 AI 서버로 데이터가 나가는 구조라면 더더욱 그렇습니다. 이 부분이 어떻게 해결되는지는 세 번째 조건, 배포 설계와 직접 이어지므로 다음 절에서 자세히 다루겠습니다.

다섯 개 영역이 이렇게 채워진 결과는 숫자로도 나타납니다. 구현 성공률은 93%에서 100%로, 완성도는 중하에서 중상으로 올라갑니다. 참여자의 역량이 좋아진 게 아닙니다. 참여자가 혼자 감당할 수 없던 다섯 개 영역을, 구조가 대신 채워준 결과입니다.

사내 배포가 처음부터 설계된 구조

세 번째 조건이 다루는 문제는 1편에서 이미 확인했습니다. 완성된 도구는 대부분 만든 사람 본인만 쓸 수 있는 형태로 남습니다. 동료가 같은 도구를 쓰려면 별도 설명이 필요하고, 설명 없이는 쓰기 어렵습니다. 공유하려 해도 사내에 배포할 절차와 환경이 갖춰져 있지 않으면, 개인 자산에서 조직 자산으로 넘어가지 못합니다. 그리고 4편에서 짚었듯, 이 문제는 도구가 완성된 뒤에 발견되면 이미 늦습니다. 보안을 나중에 고려한 도구는 핸즈온 결과물을 사내 IT·보안팀에 가져갔을 때 "이건 외부 AI 서버로 데이터가 나가는 구조라 사내 배포가 어렵습니다"라는 답을 듣고 그대로 끝나버립니다.

파운드리는 이 두 가지 문제를 모두 해결합니다.

첫 번째, '동료가 설명 없이 쓸 수 있는가'의 문제입니다. 본 세션이 끝나는 시점에 참여자가 받는 것은 코드 파일이 아니라 Run Package입니다. 라이브러리 설치와 서버 실행이 이미 자동화된 완결형 실행 파일 묶음입니다. 만든 사람이 옆에서 설명하지 않아도, 동료가 공유 폴더에서 이 파일을 받아 바로가기로 실행하면 곧바로 작동합니다.

두 번째, 보안을 나중에 고려해서 배포가 막히는 문제입니다. 파운드리는 도구를 만드는 시작 단계부터 보안 판단을 함께 처리합니다. 외부 AI 서버로 데이터를 보내는 대신 온프레미스 모델을 사용하고, 산출물은 사용자 로컬 폴더에 저장됩니다. "외부 AI 서버로 데이터가 나가서 안 된다"는 답을 마지막에 듣는 대신, 애초에 그런 구조로 만들어지지 않는 것입니다.

이 결과로 산출물의 성격 자체가 달라집니다. 기존에는 핸즈온이 끝나면 코드 파일이 남았고, 그중 대부분은 폐기됐습니다. 파운드리 체계에서는 Run Package가 남고, 그것이 곧바로 사내 자산으로 운영에 들어갑니다.

세 조건이 함께 작동할 때

즉시 질문이 본세션 밖으로 옮겨지고, 다섯 개 영역이 구조로 채워지고, 배포가 처음부터 설계에 포함되는 것, 진짜 변화는 셋이 동시에 작동할 때 나타납니다. 참여자가 무엇을 만들지 이미 정리한 채로 들어오고, 비개발자가 학습으로 채우기 어려운 다섯 영역을 AI가 대신 보완 해 주고, 나온 결과물이 배포 심사에서 막히지 않는 상태. 이 세 조건이 겹치는 지점에서, 기존에는 12시간이 필요했던 본세션이 8시간으로 줄어듭니다. 시간을 줄이려고 애쓴 결과가 아니라, 세 조건이 갖춰지면서 본세션이 설계와 씨름하는 대신 구현에만 집중할 수 있게 된 결과입니다.

포텐스닷은 이 세 조건을 하나의 구조 안에 담았다고 지난 글에서 말씀드렸습니다. 파운드리가 이 조건들을 실제로 채우는 방식을 지금까지 살펴봤습니다.

그런데 여기서 끝나는 이야기가 아닙니다. 본세션이 끝나고 Run Package 하나가 참여자의 손에 들어오는 순간, 그 도구는 아직 아무 일도 하지 않은 상태입니다. 조직 안에서 무슨 일이 시작되는지는 다음 글에서 이어가겠습니다.