개발자가 팔란티어 파운드리를 직접 사용해 보고 쓴 책!

BI도, 데이터 레이크도 실패했다면, 문제는 데이터가 아니라 판단 구조다

담당자의 ‘감’이 아니라 시스템으로 결정하고 싶다면 설계부터 시작하라.

 

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

 

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

 

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

 

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

 

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

[목 차]
  

감사의 말

PROLOGUE 시스템은 정답을 주지 않는다, 구조를 줄 뿐이다

 

PART 1• 왜 우리는 파운드리를 선택했는가?

CHAPTER 01 데이터 프로젝트가 실패를 반복해 온 이유

CHAPTER 02 왜 팔란티어 파운드리였나?

 

PART 2• 파운드리의 개념과 철학

CHAPTER 03 파운드리는 무엇을 해결하려 했나?

CHAPTER 04 온톨로지 중심 설계 철학

 

PART 3• 파운드리 트라이얼 실습 준비

CHAPTER 05 트라이얼을 시작한 첫 한 달간의 충격

CHAPTER 06 화장품 제조 공장 실습 데이터 소개

CHAPTER 07 데이터 적재와 정제의 현실

CHAPTER 08 온톨로지 설계 실습

 

PART 4• 파운드리 앱별 실전 사용법

CHAPTER 09 데이터 커넥션과 파이프라인 빌더

CHAPTER 10 온톨로지 매니저

CHAPTER 11 컨투어와 워크숍

CHAPTER 12 운영 앱과 케이스 매니지먼트

CHAPTER 13 아폴로와 운영 환경

 

PART 5• 운영의 실패와 한계, 그리고 교훈

CHAPTER 14 파운드리는 만능이 아니다

CHAPTER 15 성공과 실패를 가르는 결정적 포인트

 

PART 6• 파운드리 이후 ‘판단 AI’로 가는 길

CHAPTER 16 생성 AI 시대의 파운드리

CHAPTER 17 우리가 배운 것, 그리고 다음 단계

 

EPILOGUE 파운드리는 결국 ‘판단의 역사’를 만드는 시스템이다

참고 자료

[본 문]
  

파운드리는 데이터를 테이블이나 칼럼으로만 다루지 않는다. 현실의 사물과 개념, 그 사이의 관계와 행동을 컴퓨터가 이해할 수 있는 형태로 정의한다. 온톨로지를 통해 데이터는 의미를 갖고, 단절된 시스템 간 정보는 하나의 판단 구조(logic)로 연결된다. 파운드리는 이 구조를 바탕으로 단순 분석을 넘어 실제 비즈니스 문제 해결까지 이어지도록 설계되었다. (p.6)

 

파운드리는 이미 다양한 산업에서 활용되고 있다. 정부와 국방에서는 국가 안보와 위기 대응을 위한 실시간 의사결정에 사용되고, 금융에서는 거래 데이터와 리스크 데이터를 통합해 연체나 부정 거래를 예측한다. 제조와 공급망에서는 생산, 원가, 물류 데이터를 연결해 운영 효율을 높이고, 헬스케어나 공공 영역에서도 데이터 기반 정책과 캠페인 설계에 적용된다. 이 사례들의 공통점은 ‘데이터 통합 그 자체’보다 ‘의사결정의 속도와 질을 높였다’는 데 있다. (p.24)

 

데이터 플랫폼을 설계할 때 대부분은 데이터를 어디에 저장하고, 얼마나 빠르게 조회하며, 어떻게 시각화할지를 고민한다. 그러나 파운드리는 데이터부터 보지 않고 의미를 먼저 묻는다. 5%의 불량률, 30분의 지연, 10건의 민원 같은 숫자는 그 자체로 아무런 행동을 요구하지 않는다. 데이터가 어떤 객체의 상태를 나타내는지 파악하고, 어떤 액션을 요구하는지 명시하며, 그 책임이 누구에게 있는지 답할 수 있을 때 데이터는 비로소 운영의 언어가 된다. 답하지 못하면 보고용 숫자에 그친다. (p.47)

 

오랫동안 데이터 업계에는 데이터가 객관적이고 중립적이며, 해석은 나중 문제라는 믿음이 암묵적으로 깔려 있었다. 하지만 이 책에서의 실습은 이 믿음을 완전히 무너뜨렸다. 파운드리에서 실패한 데이터 모델은 대부분 기술적으로는 정답에 가깝다. 그래서 더 위험하다. 진짜 실패는 모델이 논리적으로 완벽한 척하며 현장의 실질적인 운영을 방해하는 것이다. (p.112)

 

링크는 단순한 관계가 아니라 ‘판단의 통로’다. ERD의 링크가 ‘연관성’을 설명한다면 온톨로지의 링크는 ‘이 연결이 있어야 판단이 가능하다’를 뜻한다. 그래서 링크 유형을 설계할 때 “이 링크가 없으면 무엇을 판단할 수 없게 되는가?”라는 질문을 가장 먼저 던져야 한다. 여기에 답하지 못하는 링크는 대개 필요 없다. (p.172)

 

팔란티어 파운드리의 워크숍을 처음 접한 사람들은 화려한 대시보드와 복잡한 차트를 기대했다가 화면이 너무 단순하다며 의아해하곤 한다. 워크숍은 정보를 최대한 많이 나열하는 도구가 아니라, 사용자가 지금 당장 내려야 할 ‘판단’만 남기기 위해 불필요한 노이즈를 걷어낸 결과물이다. 즉 워크숍 화면에서는 의도한 설계 목표가 정확히 달성되었음을 보여주기 위해 차트를 일부러 드러내지 않고 철저히 배제한다. (p.194)

 

앞서 말했듯이 파운드리는 기능이나 성능이 부족해서 무너지지 않는다. 성공과 실패를 가르는 결정적 차이는 언제나 기술의 영역 바깥에 있다. 많은 조직이 파운드리를 도입할 때 ‘설치만 하면 자동으로 다음 단계로 갈 수 있다’는 환상을 품는다. 그러나 파운드리는 운영 방식이 근본적으로 바뀔 때 비로소 생명력을 얻는다. 데이터가 파이프라인으로 촘촘히 연결되어 있고, 온톨로지 설계도 그럴듯하며, 워크숍으로 구현한 화면이 매끄럽게 작동해도 운영되지 않는다면 문제는 사람이 기술을 대하는 방식에 있다. (p.260)

 

AI를 처음 도입할 때 많은 조직은 복잡한 문제를 단번에 해결하고, 사람보다 더 정확한 판단으로 최적의 정답을 제시하는 전지전능한 존재를 기대하곤 한다. 그러나 실제 운영의 세계에는 애당초 고립된 ‘정답’이 존재하지 않는다. 정보는 늘 불완전하고 상황은 시시각각 변하며, 한번 내린 결정은 되돌리기 어렵기 때문이다. 이런 조건에서는 정답이라는 개념이 무의미해진다. 대신 우리에게 필요한 것은 ‘허용 가능한 선택의 범위’다. 어디까지가 수용 가능한 수준인지, 어떤 경계선을 넘으면 안 되는지, 그리고 특정 상황에서 누가 결정해야 하는지를 명확히 하는 과정이야말로 운영의 본질이다. (p.290-291)