팔란티어 온톨로지가 모델링하는 것과 모델링하지 않는 것

AI 시대, 관리한다는 것 - 5편

지난 몇 년 사이 기업 시스템 이야기에서 가장 자주 나오는 이름이 팔란티어입니다. 주가 이야기로도 나오고, 인공지능 이야기로도 나오고, 국방과 정보기관 이야기로도 나옵니다. 그리고 이런 질문을 받는 일이 부쩍 늘었습니다.
"우리도 저런 걸 해야 하는 것 아닙니까."

그런데 이 질문에는 순서가 하나 빠져 있습니다. 우리에게 무엇이 왜 필요한지가 먼저 정리되어 있어야 합니다. 그것이 없으면 "저것이 좋다더라"가 판단의 근거가 됩니다.

시스템을 검토할 때 우리는 대체로 무엇을 할 수 있는지부터 봅니다. 화면이 몇 개이고, 어떤 분석이 되고, 어디까지 연동되는지요. 그런데 정작 먼저 봐야 할 것은 그 기술이 애초에 어떤 문제를 풀려고 만들어졌는가이고, 그보다 더 먼저 봐야 할 것은 우리가 풀려는 문제가 무엇인가입니다. 설계 목적이 우리 문제와 다르면, 기능이 아무리 많아도 우리 문제는 풀리지 않습니다.

지난 편에서 정상 범위를 유지하는 관리 방식과 기준 자체를 바꾸는 관리 방식을 대비했습니다. 오늘은 그 이야기를 실제 기술 두 가지에 대입해서, 각각이 우리 회사 업무의 어느 층까지를 다루는지 살펴보려 합니다.

미리 말씀드리면 이 글은 특정 제품을 비판하는 글이 아닙니다. 두 기술 모두 각자의 영역에서 매우 강력하며, 성능을 평가하려는 것도 아닙니다. 다루려는 것은 적용 범위입니다. 그리고 아래 내용은 제가 이해하고 있는 범위 안에서의 해석입니다.

팔란티어가 실제로 하는 일

먼저 오해를 하나 풀고 가겠습니다. 팔란티어를 "데이터를 모아 이상한 걸 찾아내는 기술" 정도로 이해하는 경우가 많은데, 그보다 훨씬 정교합니다.

핵심은 온톨로지입니다. 예전에 지식 관리를 다룬 글에서 한 번 소개한 적이 있는데, 세상의 것들을 종류와 관계로 정리해 놓은 지도라고 보시면 됩니다.

팔란티어의 방식은 이렇습니다. 회사 여기저기에 흩어진 데이터를 모아서, 그것을 현실의 대상과 연결합니다. 고객, 주문, 설비, 부품, 재고, 배송 같은 것들이 각각 하나의 대상이 됩니다. 그리고 그 대상들 사이의 관계를 정의합니다. 이 고객이 이 주문을 냈고, 이 주문은 이 부품을 필요로 하고, 이 부품은 이 설비에서 만들어진다는 식으로요.

여기에 하나가 더 붙습니다. 행동입니다. 주문을 승인한다, 재고를 옮긴다, 생산 순서를 바꾼다 같은 것들이 시스템 안에 정의되어 있어서, 화면에서 보는 데 그치지 않고 실제로 실행됩니다.

대단한 기술입니다. 데이터가 여기저기 흩어져서 무슨 일이 벌어지는지 아무도 전체를 못 보는 조직에게, 이건 정말 큰 가치가 있습니다.

그런데 무엇을 모델링하고 있습니까

여기서 한 걸음만 더 들어가 보겠습니다. 그 디지털 트윈이 담고 있는 것이 무엇입니까.

지금 실제로 돌아가고 있는 것들입니다. 존재하는 고객, 진행 중인 주문, 가동 중인 설비, 창고에 있는 재고. 전부 실체가 있고, 지금 이 순간 상태를 확인할 수 있는 것들입니다.

그래서 이 구조는 이런 질문에 아주 강합니다. 지금 어디에 문제가 있는가. 이 부품이 늦어지면 어느 주문이 영향을 받는가. 이 설비가 서면 무엇이 멈추는가. 어제와 오늘 사이에 무엇이 달라졌는가.

정상 상태가 정의되어 있고, 거기서 벗어난 것을 찾아내고, 조치를 실행합니다. 지난 편에서 이야기한 항상성 방식입니다. 기준이 있고, 그 기준으로 되돌리는 구조입니다.

이 방식이 압도적으로 잘 맞는 조건이 있습니다.

• 다뤄야 할 데이터가 사람이 감당할 수 없을 만큼 많을 것
• 정상이 무엇인지 정의할 수 있을 것
• 이상 하나가 치명적일 것

국방, 정보 분야, 대규모 제조와 물류에서 이 기술이 강력한 이유가 여기 있습니다. 세 조건을 전부 만족하니까요.

세일즈포스는 한 층 위입니다

세일즈포스는 성격이 조금 다릅니다.

제가 이해하기로 이 기술의 뿌리는, 영업이라는 활동에서 발생하는 정보를 전부 모아서 그 활동 자체를 관리하는 것입니다. 누구를 언제 만났고, 어떤 이야기가 오갔고, 지금 어느 단계에 있고, 다음에 무엇을 해야 하는지가 개인의 수첩이 아니라 시스템에 있습니다.

이건 거래 처리보다 한 층 위입니다. 계약서와 매출은 거래이지만, 그 계약에 이르기까지의 활동은 거래가 아니니까요. 사람 안에만 있던 것을 시스템으로 끌어냈다는 점에서 의미 있는 진전입니다.

다만 한 가지 조건 위에서 작동합니다. 영업은 반복되는 활동입니다. 만나고, 제안하고, 협상하고, 계약합니다. 고객이 달라도 흐름은 비슷합니다. 그래서 단계로 나눌 수 있고, 단계별 전환율을 계산할 수 있고, 예측이 됩니다.

R&D도 마찬가지입니다. 시료를 분석하고 결과를 기록하는 것은 반복됩니다. 그러나 어떤 물질을 다음 후보로 올릴지는 반복되지 않습니다. 이번 과제와 다음 과제의 흐름이 다르고, 어제 나온 결과가 다음 단계를 통째로 바꿉니다. 반복되지 않는 일에는 단계별 전환율이라는 개념이 성립하지 않습니다.

우리 회사에 대입해 보면

이제 우리 이야기입니다.

연구원 서른 명, 진행 중인 과제 스무 건. 이런 조직에 방금 이야기한 수준의 감시 체계를 도입하면 어떻게 됩니까.

먼저 앞의 세 조건이 맞지 않습니다. 데이터가 사람이 감당 못 할 만큼 많지 않습니다. 정상이 무엇인지 정의하기도 어렵습니다. 탐색 과제에서 3개월째 결과가 안 나오는 것은 이상입니까, 정상입니까. 답이 없습니다.

그리고 더 중요한 문제가 있습니다. 이 정도 촘촘한 관리 체계는 그 자체로 족쇄가 됩니다.

지난 편들에서 이야기했듯이, 관리 항목에는 비용이 있고 그 비용은 연구원의 시간으로 지불됩니다. 모든 것이 감시되고 모든 이탈이 표시되는 환경에서 연구원이 무엇을 하겠습니까. 표시되지 않을 계획을 세웁니다. 안전한 목표를 잡고, 지킬 수 있는 일정을 그립니다.

의도가 있고, 계획이 있고, 그 다음에 거래가 있습니다

여기서 이 시리즈의 첫 번째 글로 잠깐 돌아가겠습니다.

그때 이런 이야기를 했습니다. 원료를 구매하는 일은 연구를 하기 때문에 생기고, 광고비가 나가는 일은 마케팅을 하기 때문에 생긴다고요. 거래는 기업 활동 자체가 아니라 활동의 부산물이라는 이야기였습니다.

앞의 것이 뒤의 것을 낳습니다. 반대 방향은 아닙니다.

그런데 팔란티어가 다루는 데이터는 거의 전부 세 번째 칸에서 나옵니다. 주문, 재고, 설비 가동, 배송, 거래 내역. 이것들은 이미 정해진 계획이 돌아가면서 만들어내는 결과물입니다.

그래서 그 결과물을 아무리 정교하게 연결하고 아무리 빠르게 감시해도, 첫 번째 칸으로 거슬러 올라갈 수는 없습니다. 왜 그 계획을 세웠는지는 거래 데이터 어디에도 남아 있지 않기 때문입니다. 배송 지연 기록을 몇 년 치 모아도, 애초에 그 제품을 왜 만들기로 했는지는 나오지 않습니다.

그리고 층이 다릅니다

그래서 이렇게 정리됩니다.

두 기술 모두 아주 잘하는 일이 있습니다. 이미 정해진 것이 잘 되고 있는지를 보는 일입니다. 어느 주문이 늦는지, 어느 영업 건이 멈춰 있는지, 어느 설비가 이상한지.

그런데 이 시리즈가 계속 이야기해 온 질문은 다릅니다.

• 무엇을 할지는 어떻게 정했습니까
• 왜 그것을 골랐습니까
• 무엇을 검토하다 접었습니까
• 그 판단은 어떤 전제 위에 서 있었습니까
• 그 전제가 지금도 유효합니까

그래서 이건 그 기술의 결함이 아닙니다. 다루려는 층이 다른 것입니다. 첫 번째 글에서 나눈 네 개 층으로 말하자면, 이 기술들은 아래 두 층인 실행과 거래 처리를 매우 정교하게 다룹니다. 위의 두 층인 정보 수집과 계획은 대상이 아닙니다.

그런데 그 판단은 누가 합니까

여기서 실무에서 자주 보는 문제를 하나 짚고 가겠습니다.

시스템 도입을 주도하는 주체는 회사마다 다릅니다. IT 부서일 때도 있고 현업일 때도 있습니다. 그런데 두 주체가 생각하는 성공이 서로 다릅니다.

문제는 이 두 기준이 도입이 끝나는 시점 이후로 갈라진다는 점입니다. 오픈하고 안정화까지가 앞의 기준이고, 뒤의 기준은 그때부터 시작됩니다. 그래서 프로젝트가 성공으로 종료되고 나서 1년쯤 지나면 이런 상황이 생깁니다. 도입은 성공했는데 아무도 안 씁니다.

여기에 앞의 이야기를 겹쳐 보면 이유가 보입니다. 우리에게 무엇이 왜 필요한지에 대한 분석은 현업만 할 수 있는 일입니다. 우리 프로젝트가 어떤 성격인지, 어느 판단이 어디서 일어나는지는 그 일을 하는 사람만 압니다.

그런데 그 분석이 없는 상태로 도입이 시작되면, 프로젝트는 자연스럽게 앞의 기준으로 굴러갑니다. 판단할 근거가 그것밖에 없으니까요.

이건 IT 부서의 잘못이 아닙니다. 오히려 그 반대에 가깝습니다. 현업이 해야 할 분석이 없는 상태에서 프로젝트를 성립시키려면, IT 부서는 검증된 제품과 검증된 방법론에 기대는 수밖에 없습니다.

그러니까 이 글에서 던진 질문 — 이 기술은 어느 층을 다루는가 — 은 IT 부서가 아니라 현업이 답해야 하는 질문입니다.

그럼 우리는 무엇이 필요합니까

정리하면 이렇습니다.

두 기술 모두 이미 정해진 것을 잘 굴러가게 하는 층에 있습니다. 무엇을 할지 정하는 층은 여전히 비어 있습니다.

그리고 이 판단은 현업이 해야 합니다. 우리에게 무엇이 왜 필요한지에 대한 분석은 사 올 수 없습니다.

그리고 우리가 앞의 글들에서 확인한 것은, 사람이 나갈 때 함께 사라지는 것이 정확히 그 비어 있는 층에 있다는 사실이었습니다.

그렇다면 그 층을 어떻게 다뤄야 하는가. 다음 편부터는 그 이야기를 시작하겠습니다.
첫 번째 질문은 이것입니다. 일을 사람에게 줄 것인가, 기능에 줄 것인가.