팔란티어 파운드리, 판단을 설계하라

개발자가 팔란티어 파운드리를 직접 사용해 보고 쓴 책!
BI도, 데이터 레이크도 실패했다면, 문제는 데이터가 아니라 판단 구조다
담당자의 '감'이 아니라 시스템으로 결정하고 싶다면 설계부터 시작하라.

팔란티어(Palantir)라는 이름은 많이 들었다. CIA, 미 국방부, 글로벌 대형 금융기관이 쓴다는 데이터 플랫폼. 그런데 막상 직접 써봤다는 사람은 국내에 거의 없다. 이 책은 그 거의 없는 사람이 쓴 기록이다.

저자는 팔란티어의 핵심 제품인 파운드리(Foundry) 트라이얼(Trial) 환경에 가상의 국내 화장품 제조 공정 데이터를 직접 올렸다. 파이프라인을 연결하고, 온톨로지를 설계하고, 워크숍 화면을 구현했다. 그 과정은 순탄하지 않았다. 기존 ETL(추출·변환·적재) 관성으로 접근했다가 온톨로지 설계에서 처참히 무너졌고, 현업의 업무 언어를 시스템 구조로 치환하지 못해 며칠 밤을 지새우기도 했다.

파운드리가 요구하는 것은 전혀 다른 질문이었다. 기존 데이터 플랫폼이 "어떻게 데이터를 예쁘게 보여줄까?"를 고민할 때, 파운드리는 냉정하게 묻는다. "이 데이터는 누구의 관점이며, 값이 바뀌면 누가 책임지고 어떤 행동을 취하는가?" 예를 들어 운영진이 '불량률 5%'라는 데이터를 얻었다고 가정해 보자, 숫자는 그 자체로 아무 행동도 요구하지 않는다. 그것이 어떤 설비의, 어떤 작업자 조합의, 어떤 원자재 배치의 상태인지 명시하고, 무슨 액션으로 이어지며, 책임이 누구에게 있는지 시스템 안에 정의되었을 때 비로소 '운영의 언어'가 된다. 이 정의 작업이 온톨로지(Ontology)고, 이게 파운드리의 전부다.

많은 조직이 BI(비즈니스 인텔리전스), 데이터 웨어하우스, 데이터 레이크를 차례로 도입하며 같은 약속을 반복해 왔다. 그러나 기술이 진화해도 실패 패턴은 달라지지 않았다. 현업은 업무 언어로 말하고, IT팀은 시스템 언어로 번역하고, 모델 개발자는 수학 언어로 재정의한다. 이 과정에서 판단의 맥락은 사라지고, 결정은 결국 경험 많은 담당자의 직관에 맡겨진다. 누구도 틀리지 않았지만, 아무도 성공시키지 못하는 구조다.

이 책은 파운드리를 예찬하지 않는다. "파운드리는 만능이 아니다"를 챕터 제목으로 달 만큼 솔직하다. 데이터가 파이프라인으로 촘촘히 연결되고, 온톨로지 설계도 그럴듯하고, 워크숍 화면이 매끄럽게 작동해도, 운영 방식이 바뀌지 않으면 시스템은 작동하지 않는다. 직접 부딪혀본 사람만이 할 수 있는 이야기다.