Palantir Learn 의 파운드리 기초 과정 을 따라가며 공부하고 정리한 기록입니다.
데이터와 모델까지 깔았으니 이제 사람 차례입니다. 이번 글의 결론은 다음 한 줄로 둡니다.
분석 도구를 잘 만드는 것은 비교적 풀린 문제입니다. 진짜 어려운 건 분석을 모두에게 열어주면서도 잘못된 데이터로 잘못된 결정을 못 하게 막는 것. 이걸 Foundry 는 온톨로지를 중앙에서 통제한다는 한 가지 원칙으로 풉니다.
Quiver: 분석의 시작점이 데이터가 아닌 객체
분석 도구의 대표는 Quiver 입니다. 즉석 분석, 시각화, 대시보드 생성을 위한 no-code 어플리케이션입니다.
여기서 가장 중요한 변화는 이겁니다. 분석 사용자가 데이터를 처음부터 쿼리/정리/통합할 필요가 없습니다.
기존 BI 도구의 흐름은 보통 이렇습니다.
- 어떤 DB 에 어떤 테이블이 있는지 찾는다
- JOIN 조건과 필터를 짜본다
- 결과가 이상해서 데이터 엔지니어를 찾는다
- 한참 후에야 분석을 시작한다
Quiver 의 흐름은 다릅니다. 온톨로지가 이미 있기 때문에 사용자는 관심 있는 객체를 찾으면 됩니다.
유지관리 점검 로그를 분석하고 싶다 -> 유지관리 점검 로그 객체를 연다 -> 끝.
필터, 조작, 시각화는 그 위에서 직관적으로 일어납니다. 분석가가 분석에 집중할 수 있게 됩니다.
한 화면 위에서 데이터 / 모델 / 분석이 만나는 순간
Quiver 의 진짜 매력은 서로 다른 종류의 정보를 한 화면에 겹쳐 볼 수 있다는 데 있습니다.
가령 유지관리 이벤트 로그를 분석하다 보면, 기계 센서의 시계열 데이터를 그 위에 겹쳐 보고 싶어집니다. Quiver 에서는 이걸 그냥 합니다. 객체끼리 이미 온톨로지로 연결되어 있기 때문에 따로 JOIN 을 쓸 일도 없습니다.
겹쳐 보다가 각 유지관리 이벤트 직전에 제품 품질이 현저히 저하된다는 패턴이 보이면, 분석가는 유지관리 주기를 단축해야 한다는 결정을 끌어낼 수 있습니다.
여기서 한 걸음 더 나갑니다. 데이터 사이언스 팀이 만든 예측 모델도 같은 화면에 띄울 수 있습니다. 모델의 예측과 분석가의 결론을 나란히 두고 비교합니다.
이게 가능한 이유는 단순합니다. 모델과 데이터가 같은 통합 기반 (온톨로지) 위에 있기 때문에. 그 기반이 없다면 비교 자체가 서로 다른 정의의 숫자를 늘어놓는 일이 됩니다. 통합되지 않은 시스템에서 흔히 벌어지는 일이기도 합니다.
Write-back
분석가가 모델과 다른 결론에 도달했다고 가정해 봅시다.
이전의 세계에서는 이 상황이 보통 Slack 메시지 한 줄과 회의 한 번으로 끝납니다. 어쩌면 운 좋게 데이터 사이언스 팀이 다음 분기에 모델을 업데이트할지도 모릅니다.
Foundry 에서는 다릅니다. 그 피드백 자체가 시스템의 입력이 됩니다. 분석가가 최신 분석 결과를 모델 담당 데이터 사이언티스트에게 직접 전달하고, 그 결과는 모델 재학습의 재료가 됩니다. 이게 write-back 의 한 형태입니다.
write-back 은 분석가만의 도구가 아닙니다. 더 결정적인 사례는 현장 결정권자입니다.
자동 가격 변동이 일어났고, 모델이 인식하지 못한 외부 요인 때문에 수요가 급격히 떨어졌다.
이때 그 시장에 대한 전문 지식을 가진 결정권자가 상황을 평가해 어플리케이션 위에서 조정 결정을 내립니다. 그 결정은 어플리케이션을 거쳐 온톨로지로 다시 흘러 들어가고, 다음 의사결정 사이클에 영향을 줍니다.
이 사이클이 닫혀 있어야 시스템이 점진적으로 지능화됩니다.
시나리오: 가정 위에서 결정을 굴려보기
분석 어플리케이션은 대시보드만이 아닙니다. 시나리오 비교가 핵심 패턴 중 하나입니다.
공급망의 예를 들면, 운영 사용자가 몇 가지 매개변수를 바꿔가며 시나리오의 결과를 비교할 수 있는 어플리케이션을 분석가가 미리 준비해 둡니다. 운영자는 지식이 깊지 않아도 그 어플리케이션 안에서 what-if 를 굴려보고 결정을 내립니다.
이때 굴려지는 what-if 는 (2편) 다이나믹 레이어의 시뮬레이션과 같은 메커니즘 위에 있습니다. 분석가가 만든 도구가 운영자의 의사결정에 직접 연결되고, 운영자의 결정은 다시 데이터로 돌아옵니다.
안전하게 대중화한다는 것
여기서 자연스럽게 따라오는 질문이 있습니다. 그렇게 모두에게 열어주면 위험하지 않은가?
여기에 대한 Foundry 의 답은 단순하면서도 본질적입니다.
온톨로지에 대한 권한, 접근 제어, 액세스 유형 (write-back 가능 여부 포함), 상태 같은 모든 것은 중앙에서 구성/관리된다.
분석을 대중화한다는 것은 모두에게 모든 데이터에 접근시켜 준다는 뜻이 아닙니다. 각자가 자기 권한 안에서, 정해진 객체에 대해, 정해진 방식으로 분석할 수 있게 한다는 뜻입니다.
이 차이가 민주화된 분석과 통제되지 않은 카오스를 가릅니다.
그리고 사용자 입장에서는, 매번 탐색을 위한 경계를 직접 설정/재설정할 필요 없이 자기 일에 집중할 수 있게 됩니다. 가드레일이 시스템에 내장되어 있다는 것은 결국 사용자에게 더 많은 자유를 준다는 뜻과 같습니다.
다음 글로
분석가가 결론에 도달하는 자리까지를 봤습니다. 그런데 그 결론이 현장에서 실제 행동 으로 이어지려면, 매일 일하는 사람의 손에 맞는 인터페이스가 필요합니다. 다음 글에서는 그 마지막 다리, 어플리케이션을 봅니다.