Palantir Learn 의 파운드리 기초 과정 을 따라가며 공부하고 정리한 기록입니다.
분석까지 봤으니 이제 분석가가 만든 결론이 현장의 손으로 넘어가는 다리, 어플리케이션을 봅니다.
분석이 결정을 지원한다면, 어플리케이션은 결정을 수행합니다. 그리고 그 수행이 다시 온톨로지로 돌아와야 시스템이 진짜로 닫힙니다.
Workshop: 운영자가 매일 쓰는 앱을 빠르게
Foundry 는 단순히 온톨로지의 객체와 요소를 표시/분석하는 것에서 멈추지 않습니다. 앱 개발자가 운영 담당자가 일상적인 업무에서 사용할 맞춤형 앱을 구축할 수 있게 지원합니다.
대표 도구는 Workshop 입니다. 온톨로지 읽기/쓰기 기능을 그대로 활용하는 low-code 앱 빌더로, 이미 통합되어 있는 객체, 액션, write-back 루틴을 연결만 해서 앱을 빠르게 만듭니다.

분석 사용자가 Quiver 에서 객체를 시작점으로 분석을 시작했던 것과 같은 방식으로, 앱 개발자는 Foundry 의 빌딩 블록을 조립해 화면을 만듭니다. 모든 부분을 직접 지정할 필요가 없습니다. 이미 온톨로지에 있는 정보가 채워진 채로 시작됩니다.


이 점이 가장 큰 차이입니다. 일반적인 low-code 도구는 데이터를 어디서 가져올지부터 짜야 합니다. Workshop 은 그 단계 자체가 사라져 있습니다. 객체를 고르면 데이터가 그 안에 이미 있습니다.
Pro-code: 커스텀이 필요한 자리
물론 low-code 만으로 충분하지 않은 경우가 있습니다. 2D, 3D 차트, 정교한 인터랙션, 복잡한 시각화 같은 영역은 결국 코드를 직접 써야 합니다.
Foundry 는 이걸 위해 pro-code 앱 빌더도 별도로 제공합니다.

여기서 짚어둘 점은 low-code 와 pro-code 가 같은 온톨로지 위에서 돌아간다는 것입니다. low-code 로 시작했다가 한 화면만 pro-code 로 만들어 끼워 넣는 식의 혼합 구성이 자연스럽게 가능합니다. (3)편 Data 에서 본 low-code/pro-code 변환 도구와 동일한 설계 철학입니다.
Write-back: 결정을 시스템으로 되돌리기
어플리케이션의 핵심은 결국 사용자의 행동을 캡처해서 온톨로지로 되돌려 보내는 데 있습니다. 이게 앞선 글들에서 계속 등장한 write-back 입니다.


위 화면은 데이터, 모델, 분석, 의사결정이 한 어플리케이션 안에서 어떻게 만나는지 보여주는 예시입니다.
- 왼쪽 입력 필드로 사용자가 시나리오를 파라미터화한다.
- 모델이 실행되어 그 파라미터 변경이 오른쪽의 생산 등급 데이터에 미치는 영향을 즉각 보여준다.
- 사용자가 올바른 파라미터를 찾으면, 어떤 값을 적용할지 결정한다 (예: 공장 간 이전 제품 수량).
- 이 결정은 다시 온톨로지에 기록되고, 필요한 경우 SAP 같은 외부 운영 시스템에도 반영된다.
이게 시리즈 내내 강조해 온 닫힌 루프의 마지막 조각입니다. 분석에서 끝나지 않고, 어플리케이션을 거쳐 결정이 외부 운영계까지 전파됩니다.
Carbon: 앱을 카탈로그로 묶기
단일 사용자를 위한 앱 하나가 아니라, 여러 사용자 그룹을 위한 앱 제품군을 구축하는 단계가 마지막에 옵니다.
이때 필요한 건 단순히 앱을 만드는 게 아니라, 그 앱들을 사용자가 알아보기 쉬운 방식으로 정리해서 보여주는 자리입니다. 어떤 질문에 대해 어디로 가야 하는지, 어떤 워크플로우를 어디서 처리해야 하는지에 대한 사용 사례 카탈로그.

Foundry 가 이걸 위해 제공하는 도구가 Carbon 입니다. 각 사용자 그룹에 커스텀이 가능한 작업공간 디자인 앱으로, 그 그룹이 실제로 온톨로지를 효과적으로 쓰는 데 필요한 앱, 기능, 파일을 모아 쉽게 진입할 수 있는 페이지를 만듭니다.
회사 인트라넷의 부서별 포털을 떠올리면 비슷하지만, 결정적인 차이가 있습니다. Carbon 의 페이지는 온톨로지에 직접 연결된 라이브 앱들로 채워집니다. 정적인 링크 모음이 아니라, 그 페이지에서 바로 결정을 내릴 수 있는 작업대입니다.
정리
어플리케이션 단계에서 Foundry 가 잡고 있는 것은 결국 다음 네 가지입니다.
- 운영자가 매일 쓸 앱을 빠르게 만들기 (Workshop, low-code)
- 정교한 커스텀이 필요한 자리에는 pro-code 도구
- 사용자의 결정을 온톨로지와 외부 시스템으로 되돌리는 write-back
- 여러 앱을 사용자 그룹별로 묶어 카탈로그화 (Carbon)
다음 글로
지금까지는 모든 화면을 Foundry 안에서 다루는 것처럼 이야기해왔습니다. 그런데 실제 조직은 SAP, Salesforce 같은 기존 시스템 위에서 매일 돌아가고, Foundry 가 그 모든 화면을 대체할 수도 대체할 필요도 없습니다. 다음 글에서는 Foundry 가 외부 시스템과 어떻게 살아가는지 봅니다.