작년 한 해 동안 가장 많이 받은 질문 중 하나가 “팔란티어가 도대체 뭐 하는 회사예요”였다.
흥미롭게도 질문하는 사람들의 직군이 완전히 갈렸다. 주식 투자를 하는 분들은 이미 답을 알고 있었다. 시가총액이 천문학적으로 뛰어오른 그 미국 회사. 반면 AI 엔지니어 쪽에서 일하는 분들은 의외로 잘 몰랐다. 알아도 “정부 데이터 분석하는 회사 아니에요?” 정도에서 멈췄다. 이 격차가 흥미로웠다. 시장은 이미 팔란티어를 다음 시대의 핵심 인프라로 평가하고 있는데, 정작 인프라를 만드는 엔지니어들은 그 가치를 잘 모르는 비대칭 상황 말이다.
이 비대칭이 깨지기 시작한 결정적 계기가 작년 말부터 올해 초까지의 한 흐름이었다. 그리드원이 GO;DO 플랫폼을 발표하면서 ‘지식의 선순환’을 강조했고, 포스코DX가 ‘A.WORKS’라는 Agentic Automation 플랫폼을 내놓으면서 ‘과제별 맞춤형 AI 적용 체계’를 이야기했고, 한국수자원공사와 한국지역난방공사 같은 공공기관에서 RAG 기반 생성형 AI 플랫폼이 본격 가동되기 시작했다. 이 모든 발표의 청사진을 거꾸로 따라가다 보면 같은 원형이 떠오른다. 팔란티어가 20년 동안 만들어온 파운드리(Foundry)와 온톨로지(Ontology)다.
오늘 글은 두 가지를 풀어보려 한다. 첫째, 팔란티어 파운드리와 온톨로지가 엔지니어링 관점에서 정확히 무엇이고 왜 중요한가. 둘째, 이 모델이 한국 엔터프라이즈 AI 시장에서 어떻게 변형되어 자리잡고 있는가. RAG 파이프라인을 직접 구축하고 LangGraph로 멀티에이전트를 운영해 본 입장에서, 단순 회사 소개를 넘어 실무적으로 의미 있는 분석을 시도해 보겠다.
파운드리(Foundry)는 단순 데이터 플랫폼이 아니다
팔란티어 파운드리를 처음 마주하는 엔지니어들이 가장 자주 빠지는 함정이 “데이터 통합 플랫폼이군요”라는 단순 분류다. 표면만 보면 그 말이 틀린 건 아니다. 재무, 인사, 물류, 재고처럼 사내 곳곳에 파편화된 데이터를 한곳에 모으고, 그 위에서 분석과 시각화를 가능하게 하는 도구. 여기까지는 일반적인 데이터 레이크 또는 데이터 웨어하우스와 다를 게 없다.
그런데 파운드리의 진짜 가치는 그 위 한 층에 올라간 구조에 있다. 데이터를 모으는 데서 끝나는 게 아니라, 그 데이터를 ‘비즈니스 객체’로 다시 모델링한다는 점이다. 예를 들어 한 항공사가 파운드리를 도입한다고 해보자. 일반적인 데이터 플랫폼이라면 ERP에서 항공편 테이블, 정비 시스템에서 부품 테이블, 인사 시스템에서 승무원 테이블을 가져와 SQL로 조인할 수 있게 만드는 데서 끝난다. 파운드리는 한 발 더 나간다. 이 데이터들로부터 ‘항공편(Flight)’, ‘부품(Part)’, ‘승무원(CrewMember)’이라는 비즈니스 객체를 정의하고, 이 객체들 사이의 관계를 명시적으로 선언한다. “한 항공편은 여러 승무원을 가지며, 여러 부품으로 구성된다.” 이 선언이 곧 온톨로지(Ontology)다.
이 차이가 엔지니어링 관점에서 왜 결정적인가. 데이터를 객체로 모델링한다는 건 데이터에 의미를 부여한다는 뜻이다. SQL 테이블 단계의 데이터는 ‘컬럼들의 집합’에 불과하다. 그러나 온톨로지 단계로 올라간 데이터는 ‘비즈니스 의미를 가진 단위’다. AI나 자동화 도구가 이 데이터를 다룰 때, 단순히 “이 컬럼의 합을 구하라”가 아니라 “이 항공편의 정비 일정을 조회하라”는 명령어로 작업할 수 있다. 의미 단위로 데이터를 다루는 것과 컬럼 단위로 다루는 것의 차이는 자연어 인터페이스 시대가 열리면서 더 결정적이 됐다.
온톨로지(Ontology)가 RAG와 만났을 때 일어나는 일
여기서 RAG 파이프라인을 직접 설계해 본 사람이라면 한 번쯤 했을 고민이 떠오를 것이다. RAG가 검색에서 만나는 가장 큰 한계가 바로 이 ‘의미 단위’의 부재다. 일반적인 RAG는 문서를 청크로 자르고 임베딩한 다음 벡터 유사도로 검색한다. 그런데 기업 데이터에서는 이게 자주 작동하지 않는다. “지난달 인천발 LA행 항공편 중 정비 지연이 있었던 케이스 알려줘”라는 질문이 들어오면, 텍스트 기반 임베딩 검색은 답하기 어렵다. 그 답은 단일 문서에 있는 게 아니라, 여러 시스템의 구조화된 데이터를 조합해야 나오기 때문이다.
온톨로지는 이 문제의 해법을 미리 갖고 있다. ‘항공편’이라는 객체와 ‘정비 이력’이라는 객체 사이의 관계가 미리 선언되어 있으니, AI는 임베딩 검색이 아니라 의미 기반 그래프 탐색으로 답을 찾을 수 있다. “인천발 LA행 항공편 → 해당 기간 필터링 → 연결된 정비 이력 → 지연 사례 추출”이라는 경로가 온톨로지 구조 위에서 자연스럽게 그려진다.
이 발상은 이미 LangGraph 멀티에이전트 RAG 문서 기반 질의응답의 새로운 패러다임 글에서 길게 풀어둔 적 있다. RAG가 단순 검색 엔진을 넘어 추론 가능한 지식 인프라가 되려면, 그 위에 시맨틱 레이어가 필요하다는 결론이었는데, 팔란티어 온톨로지가 바로 그 시맨틱 레이어를 20년 동안 만들어온 결과물이다. 다른 표현으로 하면, 팔란티어는 RAG 시대가 오기 훨씬 전부터 RAG의 한계를 알고 있었고, 그 한계를 푸는 도구를 미리 만들어두고 기다리고 있던 회사다.
‘Human-in-the-Loop’이라는 핵심 철학의 무게
팔란티어 자료에 빠지지 않고 등장하는 표현이 ‘Human-in-the-Loop’이다. 인간의 판단을 강화하는 신뢰할 수 있는 데이터 플랫폼을 만든다는 표현. 이 표현이 마케팅 슬로건처럼 들릴 수 있는데, 엔지니어링 관점에서는 매우 구체적인 설계 철학이다.
이 철학이 왜 중요한지는 LangGraph 1.0이 가장 강조하는 프로덕션 기능을 보면 안다. 시스템이 일시정지하고 사람의 입력을 기다리고, 응답이 오면 그 지점부터 재개하는 구조 말이다. 이게 단순한 UX 패턴이 아니라 멀티에이전트 시스템의 표준 안전장치로 자리잡고 있다. 에이전트가 모든 결정을 자율적으로 내리는 구조는 위험하다. 환각이 누적되고, 잘못된 판단이 다음 판단의 전제가 되며, 한 번의 오작동이 전체 워크플로를 망가뜨린다. 이 위험을 통제하려면 핵심 의사결정 지점마다 사람의 검증이 들어와야 한다. 이걸 시스템 설계 단계에서 미리 고려하느냐 아니냐가 프로덕션 가능 시스템과 데모용 시스템을 가르는 결정적 차이다.
팔란티어의 ‘Human-in-the-Loop’ 철학이 갖는 실질적 의미가 여기에 있다. 데이터를 자동으로 분석해서 답을 던져주는 게 아니라, 분석의 모든 단계를 사람이 추적하고 검증할 수 있도록 시각화하고 기록한다. 군사 작전이나 금융 의사결정처럼 책임 추적이 필수인 영역에서 팔란티어가 압도적인 점유율을 가지는 이유가 바로 이 설계 철학에 있다. AI가 내린 모든 판단의 근거가 그래프 위에 펼쳐지고, 사람이 그 그래프를 따라 검증할 수 있다. 이 추적 가능성이 곧 신뢰성이다.
이 부분은 그리드원 GO;DO로 보는 한국형 에이전틱 자동화 글에서도 짚었던 부분과 정확히 맞물린다. 그리드원이 자율 진화를 표방하면서도 Critic Agent와 휴먼 리뷰를 명시적으로 설계에 포함한 이유, 그리고 이 균형이 깨지면 자동화가 새로운 리스크가 된다는 결론. 팔란티어가 20년 동안 갈고닦은 ‘Human-in-the-Loop’ 철학이 한국 엔터프라이즈 자동화 플랫폼에서도 그대로 재현되고 있다.
파운드리 4계층 구조, 엔터프라이즈 AI의 운영체제
파운드리의 내부를 한 번 들여다보면 네 개 층의 구조가 또렷하게 그려진다. 데이터 통합 계층, 의미 모델링 계층(온톨로지), 로직 계층(시뮬레이션·분석), 운영 계층(애플리케이션·자동화)이다. 이 4계층 구조가 흥미로운 이유는 운영체제와 닮았다는 점이다. 하드웨어 위에 커널이 올라가고, 커널 위에 시스템 라이브러리가 올라가고, 그 위에 애플리케이션이 올라가는 구조 말이다.
비유를 더 밀고 가보자. 파운드리에서 데이터 통합 계층은 하드웨어에 해당한다. 사내 곳곳에서 데이터를 끌어와 표준화된 형태로 만든다. 온톨로지는 커널이다. 데이터에 의미를 부여하고, 객체 간 관계를 정의하며, 모든 상위 계층이 의존하는 공통 어휘를 제공한다. 로직 계층은 시스템 라이브러리다. 시뮬레이션, 분석, 의사결정 모델 같은 재사용 가능한 함수들이 자리한다. 운영 계층은 애플리케이션이다. 사용자가 실제로 보고 만지는 대시보드, 워크플로, 자동화 도구가 여기에 올라간다.
이 운영체제 비유가 단순 비유에 그치지 않는 이유가 있다. 운영체제의 가치는 그 위에 올라가는 애플리케이션의 다양성에 비례한다. 윈도우, 맥OS, 리눅스가 가치를 가지는 건 그 위에서 도는 수많은 앱 때문이다. 마찬가지로 파운드리의 가치는 그 위에서 돌아가는 다양한 비즈니스 워크플로의 수에 비례한다. 한 번 온톨로지가 잘 정의된 기업에서는, 새로운 자동화 시나리오를 추가할 때마다 처음부터 데이터 모델링을 다시 할 필요가 없다. 기존 객체와 관계를 활용해서 새 워크플로를 빠르게 조립할 수 있다.
이게 그동안 한국 기업들이 AI 도입에서 거듭 실패해 온 진짜 이유와 직결된다. 한 번에 한 워크플로씩 따로따로 만든다. 챗봇 PoC 따로, RAG 파이프라인 따로, RPA 시나리오 따로. 각각은 잘 작동하는데, 6개월 지나면 서로 데이터 모델이 충돌하고, 유지보수 비용이 도입 비용을 초과한다. 운영체제 없이 앱만 만들어 쓰는 셈이다. 팔란티어가 강조하는 건 “운영체제 먼저 깔고, 그 위에 앱을 올리자”는 발상의 전환이다.
AIP, 팔란티어가 LLM 시대에 답을 내놓는 방식
팔란티어가 LLM 시대에 내놓은 답이 AIP(Artificial Intelligence Platform)다. 이 발표가 흥미로웠던 이유는 일반적인 AI 회사와 다른 접근을 보였다는 점이다. 대부분의 회사가 LLM을 도구로 가져다가 자기 제품에 끼워 넣는 방식이라면, 팔란티어는 LLM을 자기 온톨로지 위에 올리는 방식을 택했다.
이 차이가 무엇을 만들어내느냐. 사용자가 자연어로 질문을 던지면, LLM이 그 질문을 이해하고 답을 내놓는 게 아니다. LLM이 그 질문을 온톨로지 위에서 실행 가능한 액션 시퀀스로 번역한다. “지난달 인천발 LA행 항공편 중 정비 지연이 있었던 케이스 알려줘”라는 질문이 들어오면, LLM은 답을 만들어내는 게 아니라 “Flight 객체에서 출발지 인천, 도착지 LA, 기간 지난달로 필터링 → 연결된 MaintenanceLog 중 status가 delayed인 항목 추출”이라는 액션을 만들어낸다. 이 액션이 온톨로지 위에서 실행되고, 그 결과를 다시 자연어로 정리해서 사용자에게 돌려준다.
이게 일반 RAG와 결정적으로 다른 지점이다. RAG는 LLM이 검색 결과를 보고 답을 만들어낸다. 환각이 나올 수 있고, 추적이 어렵다. AIP 방식은 LLM이 답을 만드는 게 아니라 데이터 조회 명령을 만들고, 답은 결정론적으로 데이터에서 나온다. 환각이 들어갈 자리가 거의 없고, 모든 결과는 추적 가능한 데이터 경로를 갖는다. 이 구조가 곧 ‘Human-in-the-Loop’을 시스템 차원에서 실현하는 방식이다.
이 발상은 AI 추론 시대 본격화 글에서 다룬 ‘AI 에이전트의 도구 호출 정확도 경쟁’과도 연결된다. GPT-5.5가 에이전트 능력 평가에서 1위를 탈환했다는 발표의 핵심도 결국 도구 호출의 정확도였다. 팔란티어 AIP는 이 도구 호출 시대를 미리 준비해 둔 플랫폼이다. 모든 비즈니스 객체와 액션이 LLM이 호출 가능한 함수 형태로 노출되어 있고, LLM은 그 함수들을 조합해서 작업을 수행한다. 이 구조가 가능하려면 그 위에 온톨로지가 깔려 있어야 한다.
한국 엔터프라이즈에서 이 모델이 어떻게 재현되고 있는가
여기까지 풀어 보면 자연스럽게 한 가지 질문이 떠오른다. 그렇다면 한국 기업들도 팔란티어를 도입하면 되는 것 아니냐. 결론부터 말하면, 그건 단순한 선택이 아니다. 팔란티어는 비싸고, 도입에 긴 시간이 걸리며, 미국 회사라는 점에서 데이터 주권 이슈도 함께 따라온다. 그래서 한국 시장에서 일어나고 있는 일은 ‘팔란티어 도입’이 아니라 ‘팔란티어 모델의 한국형 재현’이다.
그리드원의 GO;DO 플랫폼이 그 가장 또렷한 사례다. 분석 레이어(GO AiSE Analyzer, Task Miner, GO AI OCR), 지식 레이어(GO RAG, UC 저장소, 도메인 지식, 벡터DB, 지식그래프), 실행 레이어(에이전트 빌더, 에이전트 팜, 툴 팜, AutomateOne), 조율 레이어(GO;DO Agent Runtime), 인터페이스 레이어(챗봇 UI, 휴먼 리뷰, 태스크 대시보드)로 이어지는 구조는 사실상 파운드리 4계층 구조의 한국형 변형이다. 특히 ‘지식의 선순환’이라는 개념은 파운드리 위에서 비즈니스 워크플로가 누적되며 가치가 커지는 메커니즘과 정확히 같은 발상이다.
포스코DX의 A.WORKS도 비슷한 결을 가진다. “AX는 하나의 정답이 아니다, 과제별 맞춤형 AI 적용 체계가 필요하다”는 메시지는 곧 “온톨로지를 미리 깔고, 그 위에서 과제별 워크플로를 조립하는 방식이 답이다”라는 말과 같은 의미다. 한 워크플로씩 따로 만드는 단발성 자동화가 아니라, 운영체제를 먼저 깔고 그 위에 앱을 올리는 구조 말이다. 이 흐름은 RPA에서 에이전틱 AI로의 전환 글에서도 짚었던 한국 엔터프라이즈 자동화 시장의 새 표준이 되어 가고 있다.
공공 영역에서도 같은 모델이 보인다. 한국수자원공사가 공공기관 최초로 생성형 AI 서비스를 전사 오픈했고, 한국지역난방공사가 생성형 AI 구축 사업을 발주했다. 이런 도입의 표면은 ‘RAG 기반 챗봇’으로 보이지만, 실제 구축 과정을 들여다보면 결국 기관 내 데이터의 의미 모델링, 즉 한국형 온톨로지 정의 작업이 가장 큰 비중을 차지한다. 챗봇은 결과물이고, 진짜 가치는 그 챗봇 밑에 깔린 데이터 운영체제에 있다.
그래서 엔지니어 입장에서 무엇을 준비해야 하는가
이 글의 마지막 부분에서 실무 엔지니어 관점의 정리를 해두려 한다. 팔란티어 모델, 그리고 그 한국형 재현이 현실이 되어 가는 시점에 무엇을 준비해야 하느냐.
첫째, 데이터 모델링 능력이 다시 중심에 온다. 한동안 AI 엔지니어링의 무게중심이 모델 튜닝과 프롬프트 엔지니어링에 있었다면, 향후 3년의 무게중심은 데이터 모델링과 온톨로지 설계로 옮겨간다. SQL과 ER 다이어그램만 알면 됐던 시대에서, 비즈니스 객체와 관계를 그래프로 모델링하는 능력이 필수가 되는 시대다. 데이터 엔지니어와 AI 엔지니어의 경계가 흐려지고, 그 사이에 ‘시맨틱 엔지니어’라는 직무가 새로 생긴다.
둘째, 단발성 PoC에서 플랫폼 사고로 옮겨가야 한다. 한 워크플로씩 따로 만드는 방식은 단기 ROI는 좋아 보이지만, 1년 뒤에는 유지보수 비용에 짓눌린다. 처음부터 운영체제를 깔고 앱을 올리는 방식이 장기적으로 훨씬 경제적이다. 이 발상의 전환이 PoC 예산을 따는 사람과 시스템 아키텍처를 짜는 사람 사이의 가장 큰 격차다.
셋째, ‘Human-in-the-Loop’을 시스템 설계 단계에서 미리 고려해야 한다. 자율 에이전트가 모든 결정을 내리는 구조는 매력적이지만 위험하다. 핵심 의사결정 지점마다 사람의 검증이 들어올 수 있는 구조를 처음부터 설계해야 한다. LangGraph의 Interrupt 패턴, 팔란티어 AIP의 액션 검증 단계, 그리드원 GO;DO의 Critic Agent. 이름은 다르지만 본질은 같다. AI가 일하는 시스템에 사람의 판단이 들어올 수 있는 자리를 미리 만들어 두는 것.
넷째, 추적 가능성을 1순위 요구사항으로 다뤄야 한다. AI가 내린 결정의 근거를 사후에 재현할 수 없는 시스템은 프로덕션에 들어갈 수 없다. 모든 액션, 모든 데이터 조회, 모든 LLM 호출이 로그로 남고, 그 로그를 따라 의사결정의 경로를 되짚을 수 있어야 한다. 금융, 의료, 공공 영역에서는 이게 규제 요건이고, 일반 엔터프라이즈에서도 곧 표준이 된다.
마무리: 팔란티어가 보여주는 것은 ‘운영체제’라는 시야
팔란티어를 한 줄로 요약하라면 “엔터프라이즈 AI의 운영체제를 만들어 온 회사”라고 말하고 싶다. 시가총액이 천문학적으로 뛴 이유, 정부와 대기업이 비싼 비용을 감수하며 도입하는 이유, 그리고 한국 기업들이 그 모델을 자기 방식으로 재현하기 시작하는 이유. 이 모든 것이 한 점으로 모인다. 데이터를 단순히 저장하고 검색하는 시대가 끝나고, 데이터에 의미를 부여해 그 위에서 에이전트와 자동화가 도는 시대가 시작됐다는 것이다.
이 시야를 가지고 다시 시장을 보면 흩어져 있던 점들이 연결된다. 그리드원의 GO;DO, 포스코DX의 A.WORKS, 공공기관의 RAG 플랫폼, 그리고 글로벌의 LangGraph와 MCP. 이 모두가 같은 좌표를 가리킨다. 운영체제를 먼저 깔고, 그 위에 앱을 올리자. 이 발상의 전환이 향후 3~5년 한국 엔터프라이즈 AI 경쟁의 진짜 분수령이 될 것이다.
엔지니어 입장에서 마지막으로 한 가지를 덧붙이고 싶다. 팔란티어를 직접 도입할 일이 없더라도, 그 모델을 이해하는 것은 의미가 크다. 왜냐하면 다음 세대 엔터프라이즈 AI 플랫폼이 모두 이 방향을 향해 가고 있기 때문이다. 한국에서 그리드원, 포스코DX, 공공 RAG 플랫폼이 만드는 흐름을 따라가다 보면 결국 같은 결론에 닿는다. 데이터, 의미, 실행, 검증이 하나의 운영체제로 통합되는 시대. 그 시대를 준비하는 엔지니어와 그렇지 않은 엔지니어 사이의 격차는 단순 기술 격차가 아니라 시야 격차가 될 것이다.