대기업 AX일수록 작은 문제부터 풀어야 한다

AX의 진짜 병목: 가장 어려운 문제부터 맡기려 한다

Q. 기업들이 AX를 시작하는 단계에서 가장 많이 겪는 어려움부터 묻겠습니다. 현장에서 보시기에 진짜 병목은 무엇인가요?

어떤 것이 AX가 되는 문제인지를 스스로 판단하는 게 제일 어려운 것 같아요. AX가 되는 업무를 보면 세 유형이 있습니다. 흩어져 있는 데이터와 지식을 온톨로지로 구조화하는 것, 반복되는 업무를 자동화하는 것, 사람의 굉장히 어려운 판단과 의사결정을 도와주는 것. 세 가지 다 AX가 가능하긴 하지만 간단한 것부터 시작해 복잡한 것으로 나아가야 한다고 생각합니다.

그런데 많은 분들이 AI로 가장 어렵고 복잡한 문제를 가장 먼저 해결하려고 하십니다. 당연히 AI가 어려운 문제를 풀어주면 좋겠지만, 복잡한 수학적 최적화, 머신러닝 같은 복잡한 모델이 들어가는 문제는 AI가 바로 대체할 수 있는 영역이 아니에요. AX는 데이터를 모으고 반복 업무를 자동화해서 리소스를 줄이는 것부터 시작해야 하고, 사람의 어려운 판단을 돕는 건 그다음이라고 생각합니다.

Q. 그 가장 어렵고 복잡한 문제라는 것은 실제로 어떤 모습인가요? 예를 들어주실 수 있나요?

예를 들어, 합병한 두 회사의 레거시 코드를 코딩 에이전트로 병합해서 통합 코드를 만들어 달라는 과제가 오기도 합니다. 그런데 이 일은 사람이 계속 들여다봐도 쉽게 할 수 없는 일이에요. 저희는 그건 AX 과제가 아니라고 봤어요. 대신 두 회사가 합병하면서 생긴 문제 중 저희가 풀 수 있는 걸 역으로 제안했죠. 서로 다른 양식과 포맷으로 정리되어 있는 계약·서류 데이터를 하나의 포맷으로 구조화하는 과제 같은 거죠. 이런 문제부터 AI로 푸는 것이 좋습니다.

Q. 그럼 혹시 앞서 온톨로지나 자동화 이후에 해야 한다고 언급하셨던, 사람의 어려운 판단을 돕는 AX를 실제로 하고 계신 사례도 있나요?

제조업에는 ‘올해 이만큼 생산해서 매출을 내겠다’는 생산 계획이 있고 실제 실적이 있어요. 두 데이터를 놓고 ‘이 상품을 더 많이 생산하고 저 상품을 덜 생산했다면 실적이 얼마나 달라졌을까’ 하는 What-if 시뮬레이션을 돌려서, “이 비용이 핵심 요인이었구나, 내년에는 이 비용을 최대한 줄여보자”는 식의 판단을 지원하는 수준으로 진행했습니다.

FDE의 문제 해결법: 말하지 않고 보여주기

그렇다면 고객이 당장은 풀기가 어려운 문제를 들고 왔을 때, FDE는 그 상황을 어떻게 해결할까요. 그가 최근 맡은 프로젝트가 그런 경우였습니다. 앞서 말한 그 공장의 공정 개선 과제인데요. 이 회사는 3단계 로드맵을 세워두고 있었습니다.

1단계는 공정을 다루는 AI를 만드는 것, 2단계는 그 AI가 스스로 판단하고 실행하는 에이전트가 되는 것, 3단계는 여러 에이전트를 묶어 함께 돌리는 것. 그중 요청받은 과제는 마지막 3단계였고, 앞의 두 단계는 이미 준비되어 있다는 설명이 따라왔습니다. 하지만 현실은 막상 그렇지 않았죠.

Q. 들어가 보니 앞의 두 단계는 어떤 상태였나요?

막상 깊게 살펴보니 1, 2단계가 아직 3단계로 넘어갈 만큼 충분하지는 않았어요. 저희와 고객사의 기준이 좀 달랐던 것이죠. 그래서 에이전트 오케스트레이션을 바로 실행하기엔 어렵다고 판단했어요.

이런 경우가 드물지 않습니다. 잘 정의된 PoC(개념 증명)도 있지만, 어떤 PoC는 “공정을 최적화하고 싶다, 생산성을 높이고 싶다”는 식으로 문제가 흐릿한 형태로 오거든요. 들어가서 실제로 보면 완전히 다른 문제거나, 데이터가 준비된 게 너무 없거나, 프로세스가 아예 없는 케이스가 있었습니다.

Q. 그래서 어떻게 해결하셨나요? 1·2단계가 먼저 필요하다고 설득하셨나요?

일단 1·2단계 없이 3단계를 시도해 보다가 도저히 안 돼서,1·2단계를 최대한 간략화해 만들어서 3단계가 동작하는 걸 보여드렸습니다. 각각의 에이전트가 있어야 오케스트레이션이 된다는 건 말이 아니라 고객이 스스로 보고 느껴야 하거든요.

다만 고객 입장에서도 1단계를 확실히 검증하는 게 목표인지, 1·2단계를 임시로 만들어서라도 3단계를 보는 게 목표인지 스스로 정하지 못하셨던 것 같아요. 그래서 저희는 이건 이것대로 보여드리는 동시에, 1단계부터 잘 만들어야 한다고 말씀드렸습니다.

Q. 말로 하기보다 일단 보여주시는군요. 애초에 3단계 로드맵을 세웠으면 1·2단계도 시도를 했을 텐데, 왜 산출물이 없었을까요?

그건 잘 모르겠습니다. AX 현장에서는 다양한 케이스가 발생해요. 고객도 여러 가지 고민과 상황이 있고, 어떤 것들은 조직의 헤게모니 때문에 벌어지기도 하기 때문에 모든 배경을 전부 알 수는 없습니다. 다만 이번 사례로 저희도 배운 게 있어요. PoC 자체를 문제를 정의하기 위한 목적으로 진행하는 것도 좋다는 것입니다. 문제가 정의되어 있어야 고객과 함께 풀 수 있는데, 그렇지 않은 경우는 아예 저희가 문제정의부터 해서 방향을 잡는 것이 더 좋은 결과를 낼 수 있다고 생각해요.

온톨로지의 진짜 과제: 데이터에 없는 것을 찾아내기

그가 앞선 사례를 해결하기 위해 가장 먼저 만들어야 했던 1단계 AI는 공정을 다루는 AI였습니다. 어떤 설비를 언제 돌리고 무엇을 먼저 처리할지 판단하려면, 이 공장의 공정이 어떤 순서로 얼마나 걸리며 어떤 제약 아래 돌아가는지를 AI가 알고 있어야 합니다.

결국 실제 업무 흐름을 반영한 데이터가 있어야 하고, 그 데이터가 각각 어느 공정에 속하고 어떤 개념과 이어지는지를 정의한 온톨로지가 필요합니다. 인핸스의 AgentOS는 온톨로지를 기반으로 기업 데이터를 구조화하고, 그 위에서 AI 에이전트가 업무를 수행하도록 돕는 플랫폼이죠. 회사 곳곳에 흩어져 있던 것들을 필요할 때 한 번의 쿼리로 꺼낼 수 있게 만들어두는 겁니다.

문제는 그 지식이 자료로만 오지 않는다는 데 있습니다. 그래서 FDE는 현업을 만납니다. 팔란티어도 FDE를 고객사에 직접 들어가 붙는 엔지니어로 정의하는데, 한 FDE는 “해당 분야를 가장 잘 아는 사람은 결국 고객이기 때문에 그들과 이야기하는 데 많은 시간을 썼다”고 회사 블로그에서 밝힌 바 있습니다.

그가 마주한 것도 그 지점이었습니다. 자료로 받은 것과 현장이 아는 것이 달랐고, 그 차이는 공장에 가서야 드러났습니다.

Q. 온톨로지를 만들려면 현업을 만나야 할 텐데, 인터뷰가 정식 절차로 있는 건가요? 인터뷰를 반기지 않는 경우도 있을 텐데요.

고객 문제를 발견하기 위한 정식 인터뷰 절차가 있지만, 고객사 상황에 따라 유연하게 진행합니다. 다만 현업 입장에서는 무엇을 얼마나 말해야 하는지 모르는 채로 시간을 내는 게 부담일 수 있기 때문에 저희가 가진 데이터와 제약 안에서 질문 리스트를 최대한 만들어서 갑니다. “어떻게 업무하시는지 볼게요”가 아니라 “저희가 유추해 보니 A는 이런 것 같고 B는 이런 것 같은데 맞느냐”고 묻는 거죠. 틀린 것도 많을 겁니다. 그러면 하나하나 대답하시다가 “이럴 바에는 날 잡고 다 설명해 드리겠다”가 됩니다.

Q. 그렇게 준비해 간 계획이 현장에서는 다르게 읽힌 적도 있나요?

앞서 말한 공정 과제에서, 고객에게 받은 데이터를 분석해 계획을 만들었는데, 막상 그 계획을 들고 지방 생산 현장에 가보니, 현쟁의 예외 규칙까지 충분히 반영된 데이터가 아니란 걸 알게 됐어요.

예를 들면 “이 공정은 데이터에는 12시간으로 되어 있지만 급할 땐 6시간으로 당겨서 해요”라든지, “생산량 제약은 보통 200까지 제한하지만, 급할 때는 250까지 늘리기도 하고요” 같은 현장 운영 노하우는 현장에서만 들을 수 있었습니다. 데이터에 반영되지 않은 것들이죠. 결국 키맨은 공장에 있는 현업이구나 싶어서, 그때부터 실제로 공장에 가서 현업 인터뷰를 했어요. 거의 일주일에 두 번씩 갔던 것 같습니다.

Q. 그렇게 파악한 현장의 노하우는 시스템에 어떤 식으로 들어가나요?

현장에서 나온 말들을 저희가 온톨로지에 반영합니다. 가장 이상적인 건, 미팅을 녹음하고 그 녹음을 음성 인식으로 정리해서 필요한 암묵지와 지식을 AgentOS에 넣는 겁니다. 다만 보안 등 여러 이유로 그런 기능을 제품 안에 넣기 어렵거나, 넣더라도 고객사 PC에서 쓰기 어려울 수 있어요. 그래서 지금은 FDE들이 한 번 가공해서 필요한 정보만 넣습니다. 이 가공 과정도 추후 AgentOS에 탑재되면 더 좋은 거고요.

AI 도입 프로젝트로 할 수 없는 일: 조직과 KPI

현장을 파악하고 구조로 옮기는 일에는 사람의 시간과 노력이 필요합니다. 그래서 무엇을 할지 정하는 게 먼저입니다. 그가 현장에 들어가 가장 먼저 확인하는 것도 작업의 범위고요. 이를 위해 과제 목표, 요구사항, 고객이 정확히 무엇을 풀려는지, 그리고 범위와 검증 지표를 확인하고 정합니다. 이 네 가지 중 시간이 가장 많이 드는 게 마지막입니다. 파견 전부터 논의를 시작하는데도, 들어가고 나서 짧으면 2주 길면 한 달을 범위를 정하는 데 씁니다.

그런데 이 정의가 잘 되어도 프로젝트가 굴러가지 않을 때가 있습니다. 그는 AX가 막히는 지점이 기술이었던 적은 오히려 드물다고 했습니다.

Q. 처음 2주에서 한 달 동안 무슨 일이 벌어지나요?

정해진 기간 안에 가장 큰 임팩트를 내는 게 중요하기 때문에, 고객사의 요청을 바탕으로 스코프를 정하는 게 중요해요. 챗봇 프로젝트를 예로 들면, 고객사가 제안하는 100개의 시나리오 목록이 있다면, 그중에서 비즈니스 임팩트가 있는 것들을 우선적으로 고려합니다. 그래서 중요한 것 20~30개를 어떻게든 해내면서, 남은 70개를 다 하는 것보다 다른 조직의 데이터를 가져와서 푸는 게 더 임팩트 있다고 설득하죠.

또 프로젝트를 진행하는 메인 조직과 관련 부서의 담당자를 만나 현황을 파악하고 병목이 무엇인지, 과제의 키맨은 누구인지를 파악하는 것도 중요합니다. 이렇게 프로젝트 성공을 위해 필요한 기술 이외의 모든 요소를 빠르게 파악하고 대응하는 것이 전체 프로젝트의 성공을 좌우하기도 하죠.

Q. 그런데 그 다른 조직의 협조는 잘 얻어지나요?

그게 제일 어렵습니다. 한 사람이 담당하는 작은 업무의 AX는 그 사람의 일을 덜어주는 거라 접근이 쉬워요. 그런데 범위가 넓어지면 A 조직 역할 일부와 B 조직 역할 일부를 떼어 두 조직이 협업해야 합니다. 어떤 데이터를 준비할지, 컬럼을 어떻게 통일할지, 어느 업무까지 자동화할지를 두 조직이 합의해야 하는 거죠. 그런데 옆 조직은 이 과제에 참여하고 있지 않으니까 리소스를 내주기 어려운 상황들이 발생합니다.

이보다 더 어려운 건 각 조직의 KPI가 다른 경우예요. A조직의 KPI는 AX인데 B조직은 다르면, 조직별 KPI와 우선순위가 다르니 협조를 얻기 어려우질 수도 있죠. 결국 문제 정의보다 그 문제를 풀기로 하는 이해관계자들의 합의가 훨씬 어렵고, 대기업일수록 더 어렵습니다.

Q. 그럼 FDE는 그 상황에서 무엇을 하나요?

FDE가 조직의 문제 자체를 해결하긴 어렵죠. 다만 저희가 할 수 있는 건 빠른 판단으로 일을 진행시키는 것입니다. 어느 조직의 협력이 필요한지를 빠르게 확인하고, 예를 들어 “B팀의 협력이 있어야 이 AX가 가능하다”는 게 확인되면 담당 과제의 리더에게 바로 에스컬레이션하죠. 막힌 곳을 알리고 조직 차원에서 문제를 풀어주십사 요청하는 것입니다.

Q. 그런데 AX를 지시받은 담당자 입장에서는 조직 문제라고 손을 놓을 수가 없잖아요. 어디서부터 움직여야 할까요?

맞습니다. 결국 과제에 필요한 연관 조직, 이해관계자들과 함께 과제를 정리하고 설계하는 것. 그건 AX를 하고 싶어 하는 현업이 리더와 같이 풀어야 하는 부분이라고 생각합니다.

Q. 그럼 어떤 회사가 AX에 성공한다고 보시나요?

지금 많은 임원 분들이 AX에 대한 의지가 있습니다. AX로 리소스를 줄이고 생산성을 늘리겠다는 것이죠. 다만 그 의지가 단순 의지로 끝나지 않으려면, 더 구체적인 스코프(scope)와 뾰족한 문제로 정의되어 해결되는 경험을 회사가 계속 쌓아야 해요. 그렇게 작은 것부터 쌓아가다 보면, 우리 회사에서 어떤 문제는 AX가 잘 되고 어떤 문제는 나중에 해야 한다는 판단이 섭니다. 그 판단이 서는 회사들이 결국 AX에 성공하지 않을까 싶습니다.

이준원 FDE의 이야기는 큰 목표를 버리라는 쪽으로 가지 않습니다. 목표는 크게 두되 검증은 1단계부터 하라는 것에 가깝죠. 그리고 그 1단계를 만들어내는 방식은 인터뷰 내내 같았습니다. 필요하다고 주장하는 대신 만들어서 보여주고, 시간을 내달라고 요청하는 대신 틀린 유추를 들고 가서 상대가 먼저 설명하게 합니다. 그렇게 얻은 것들이 온톨로지가 되고, 그 위에서 에이전트가 판단을 시작합니다.

다만 그도 인정하듯 이 방법으로 풀리지 않는 영역이 있습니다. 조직과 조직 사이, 서로 다른 KPI 사이에 놓인 문제들이죠. 그건 외부에서 들어온 엔지니어가 대신 풀어줄 수 없고, AX를 하겠다고 결정한 쪽이 안에서 풀어야 합니다.

마지막으로 그는 FDE로 일하며 배운 것을 이야기했습니다. 처음 FDE가 됐을 때는 고객의 임팩트 있는 문제를 주도적으로 해결하겠다는 꿈이 있었다고 합니다. 그런데 현실은 스코프를 잘 줄이고 단계별로 나아가야 하는 일이었죠. 모든 PoC가 예상한 방식으로 본 사업까지 이어지는 것은 아니기도 하고, 이상과 현실의 차이에 좌절할 때도 있지만, 그 사이클을 돌면서도 큰 임팩트를 내겠다는 이상만은 포기하지 않는 게 중요하다고 했습니다.

회사도 다르지 않을 겁니다. AX가 가져다줄 그림은 크게 그리되, 지금 발을 디딜 곳은 어려운 문제가 아니라 매일 반복되는 일 쪽입니다. 그 일에 쓰이는 데이터가 어디에 어떤 형태로 있는지, 그 판단을 실제로 내리는 사람이 누구인지부터 확인하는 거죠. AI로 무엇을 할지는 그다음에 정해도 늦지 않을지도 모릅니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.