Palantir Learn 의 파운드리 기초 과정 을 따라가며 공부하고 정리한 기록입니다.
데이터 플랫폼은 이미 많습니다. 그런데 Palantir 는 자기네 Foundry 를 데이터 플랫폼이라 부르지 않습니다. Operational Decision Platform, 운영 의사결정 플랫폼이라 부릅니다. 이 한 단어의 차이가 결국 모든 것을 가릅니다.
요약하자면 이번 글의 결론은 이렇습니다.
대부분의 데이터 스택은 데이터에서 끝납니다. Foundry 는 데이터가 조직의 결정으로 다시 흘러 들어가는 지점까지를 한 시스템 안에 묶어 둡니다. 그 접착제가 다음 글에서 다룰 온톨로지 입니다.
우리가 진짜 풀고 싶었던 문제
Digital Transformation 이라는 키워드가 한참 회자됐습니다. 다들 데이터 레이크를 깔고, BI 를 도입하고, 데이터 사이언스 팀을 만들었습니다. 대시보드는 늘었고, 모델은 컨테이너에 담겨 엔드포인트로 배포됐습니다.
그런데 솔직히 한번 물어볼만 합니다. 그 투자가 정말 조직의 운영을 바꿨나요?
대부분의 경우 답은 애매합니다. 데이터는 수집되고, 추출되고, 시각화되어 소비자에게 도달합니다. 거기서 누군가 의사결정을 내립니다. 그리고 그 결정은 어딘가 회의록에 남고, 슬랙에서 흩어지고, 다시 데이터 자산으로 돌아오지 않습니다.
투자는 한 방향으로만 흘러가고, 피드백 루프는 끊겨 있는 상태. 이게 대부분의 조직이 처한 데이터 투자의 진짜 문제입니다.
Foundry 가 다르게 잡은 지점
Foundry 의 출발점은 한 가지 가정입니다. 데이터, 분석, 운영팀이 공유하는 공통의 언어가 있어야 한다. 그 언어 위에서 사람과 사람, 사람과 시스템이 실시간으로 연결될 수 있어야 한다는 것.
그 언어는 다음의 세 가지 조건을 만족해야 합니다.
- 데이터, 모델, 의사결정을 한 표현 위에 올릴 수 있어야 한다.
- 시간에 따라 유연하게 변화할 수 있어야 한다.
- 기술자만 쓰는 것이 아니라 현장 작업자, 분석가, 경영자 모두가 다룰 수 있어야 한다.
대부분의 도구는 셋 중 하나만 잡습니다. 데이터 엔지니어용 도구, 데이터 사이언티스트용 도구, 비즈니스 사용자용 BI 가 따로 있고, 그 사이의 간극이 곧 조직의 비효율로 누적됩니다.
Foundry 는 이 세 부류 사용자가 같은 객체를 바라보며 일하도록 설계되어 있습니다. 같은 고객 객체, 같은 제품 객체, 같은 매장 객체. 누가 보든 같은 정의의 같은 데이터입니다.
그래서 무엇이 핵심인가
Foundry 의 진짜 핵심은 데이터 파이프라인도, 모델 학습 환경도, 대시보드도 아닙니다. 그것들은 다른 회사도 합니다. Foundry 가 다른 지점은 데이터에서 시작해 의사결정까지 한 시스템 안에서 닫힌 루프를 그린다 는 점에 있습니다.
- 데이터를 모은다 (Data Integration)
- 조직의 실제 개념으로 변환한다 (Ontology)
- 그 위에서 모델을 돌린다 (Model)
- 그 결과를 사람이 본다 (Analytics, Application)
- 사람의 결정이 다시 데이터로 돌아온다 (write-back)
이 마지막 write-back 이 있어서 시스템은 점진적으로 똑똑해집니다. 사용자가 모델의 예측을 받아들이거나, 거부하거나, 수정하는 모든 행동이 데이터로 흘러들어와 다음 결정의 재료가 됩니다.
다음 글로 넘어가기 전에
여기까지가 Foundry 가 무엇인지에 대한 가장 큰 그림입니다. 그런데 이걸 어떻게 하는지는 아직 한 글자도 말하지 않았습니다.
답은 한 단어로 온톨로지 입니다. Foundry 의 거의 모든 기능은 결국 온톨로지를 만들고, 채우고, 활성화하기 위한 도구입니다. 데이터 통합도, 모델 학습도, 분석 어플리케이션도 그 자체가 목적이 아닙니다.
다음 글에서는 이 온톨로지를 본격적으로 분해해 봅니다. 시맨틱, 키네틱, 다이나믹이라는 세 개의 레이어로요.