왜 이 도구가 만들어졌는가
Palantir 플랫폼은 처음 접하는 사람에게 압도적입니다. 가능한 유스케이스의 범위가 넓고, 노코드·프로코드 경로가 동시에 존재하며, 온톨로지 같은 익숙하지 않은 설계 모델까지 겹치기 때문입니다. “Foundry에서 이런 걸 만들려면 어떻게 해야 하나요?”라는 질문이 반복적으로 나오는 이유입니다.
문제는 이 질문에 답할 하나의 정해진 결정 트리가 없다는 점입니다. 빌드 빈도, 데이터 유형, 연산이 언제 일어나는지 같은 여러 변수에 따라 정답이 달라지는데, 처음 쓰는 사람은 애초에 뭘 고려해야 하는지조차 모릅니다.
Palantir의 FDE(Forward Deployed Engineer)들은 현장에서 개발자들이 화이트보드에 솔루션을 그리다가 막히는 모습을 반복적으로 목격했습니다. 화이트보드는 자유롭지만 그만큼 모호함을 허용하고, 결과물이 팀원 모두가 똑같이 이해하는 깔끔한 설계로 이어지지 않는 경우가 많았습니다. Solution Designer는 이 문제에 대한 답으로 나왔습니다 — 한마디로 “Foundry에서 뭐가 가능한지 아는 화이트보드”입니다.
Solution Designer가 하는 일
Solution Designer는 Palantir 플랫폼으로 만든 솔루션의 아키텍처를 시각적으로 표현하는 인터랙티브 도구입니다. 1st-party·3rd-party 연동 지점을 표현하고, 플랫폼 리소스로 바로 연결되며, 문서와 베스트 프랙티스를 그 자리에서 확인할 수 있습니다.
컴포넌트 라이브러리와 구현 패턴을 활용해 그래프 인터페이스에서 솔루션 아키텍처를 조합하도록 설계됐다는 점이 핵심입니다. 온톨로지, Action, Function 같은 개념을 미리 알지 못해도 시작할 수 있습니다.
핵심 기능
- 참조 아키텍처 라이브러리: 업계·기술 패턴을 미리 만들어둔 라이브러리에서 시작점을 가져올 수 있습니다.
- 노드 기반 다이어그램: 네 종류의 노드로 구성합니다.
- Component 노드: Pipeline Builder, Workshop 같은 Foundry 플랫폼 도구 자체를 표현합니다.
- Resource 노드: 실제 Dataset, Object Type, Function, Action 같은 Foundry 리소스에 직접 연결됩니다.
- Concept 노드: “데이터 소싱” 같은 추상적인 워크플로우를 표현하며, AIP Architect로 구체적인 구현으로 다듬을 수 있습니다.
- Text 노드: 캔버스 위에 주석과 설명을 남깁니다.
- 그룹핑: 관련 노드를 논리적인 컨테이너로 묶어 큰 다이어그램을 정리합니다.
- AI 기반 검토: AIP Critic을 통해 아키텍처에 대한 AI 분석과 권고를 받을 수 있습니다.
- 문서화·공유: 각 노드·링크에 설명을 남기고, PDF·이미지·JSON으로 내보내 이해관계자와 공유하거나 팀원 온보딩 자료로 씁니다.
- Data Lineage 연동: 기존 데이터 흐름 그래프를 불러와 아키텍처 맥락을 덧붙일 수 있습니다.
AIP Architect — 요구사항을 구현 계획으로
AIP Architect는 Solution Designer 안에 내장된 AI 기능으로, LLM을 활용해 워크플로우 요구사항을 단계별 구현 계획으로 바꿔줍니다.
동작 방식은 이렇습니다. 해결하려는 문제, 제약 조건, 원하는 산출물 같은 요구사항을 입력하면, AIP Architect가 컴포넌트들이 어떻게 맞물리는지 보여주는 시각적 워크플로우 그래프를 만들어줍니다. 이때 왜 이 패턴이 적합한지, 어떤 컴포넌트가 포함되는지, 트레이드오프는 무엇인지까지 AI가 생성한 설명이 함께 붙습니다.
특히 Ontology 노드 기능이 실무적으로 유용합니다. 원하는 데이터 구조를 설명하면, AIP Architect가 그래프 위에 Object Type·Object Type Property·Link Type 세트를 직접 생성해줍니다. 온톨로지를 처음부터 설계하는 대신, AI가 만든 초안을 검토하고 다듬는 방식으로 시작할 수 있는 셈입니다.
또한 노코드·로우코드·프로코드 중 어떤 방식을 선호하는지에 따라 추천 내용도 달라집니다. 여러 LLM을 지원하며, 공식 문서는 GPT-5를 “균형 잡힌 성능과 강력한 아키텍처 추론”에 적합한 모델로 권장하고 있습니다.
Foundry 유스케이스 라이프사이클에서의 위치
Solution Designer가 다루는 “Solution Design”은 Foundry 유스케이스 라이프사이클에서 두 번째 단계입니다.
- 기능 요구사항 도출(Distilling functional requirements): 유스케이스가 뭘 해내야 하는지 파악하는 단계.
- Solution Design (Solution Designer가 다루는 지점): 요구사항에서 구체적인 컴포넌트를 뽑아내는 단계. Object Model, Lifecycle 다이어그램, 데이터 보강, 인터페이스 명세 등을 매핑합니다.
- 개발 순서 정하기(Sequencing development): 아키텍처 결정을 바탕으로 실제 구현 작업을 계획하는 단계.
즉 Solution Designer는 “무엇을 만들어야 하는가(요구사항)”와 “어떻게 만들 것인가(기술 아키텍처)” 사이의 다리 역할을 합니다.
누가, 언제 쓰는가
- 솔루션 아키텍트: 플랫폼 구현 설계를 만들 때
- 기술팀: 새 Palantir 제품·기능을 평가할 때
- PM: 아키텍처 논의를 진행하거나 프로젝트 제안서를 작성할 때
- 개발자: 자신의 아이디어나 구현을 설명할 때
공식 자료에 따르면 매일 수백 명의 사용자가 이 도구를 실제로 쓰고 있으며, 온보딩 자료·진행 상황 공유·이해관계자 커뮤니케이션 용도로도 폭넓게 활용됩니다.
처음 쓸 때 참고할 점
- 온톨로지를 몰라도 시작할 수 있다는 점을 활용하세요: Concept 노드로 먼저 큰 그림을 그리고, AIP Architect로 구체화하는 순서가 자연스럽습니다.
- 화이트보드 대체 용도로만 쓰지 마세요: Resource 노드로 실제 Dataset·Object Type과 연결해두면, 이후 온보딩·감사 자료로도 재사용할 수 있어 화이트보드보다 훨씬 오래 남는 자산이 됩니다.
- AIP Architect의 제안은 출발점이지 정답이 아닙니다: 특히 Ontology 노드가 생성한 Object Type·Link Type은 반드시 검토 후 다듬어야 합니다. 이 블로그에서 다룬 온톨로지 네이밍 전략이 여기서도 그대로 적용됩니다.
자주 묻는 질문
Q. Solution Designer를 쓰려면 온톨로지 지식이 있어야 하나요?
아닙니다. Concept 노드와 AIP Architect를 활용하면 온톨로지·Action·Function 같은 개념을 미리 몰라도 아키텍처를 그려볼 수 있습니다.
Q. AIP Architect가 만든 온톨로지 설계를 그대로 써도 되나요?
출발점으로 삼기엔 좋지만, 실제 적용 전에는 사람이 검토하고 다듬는 과정이 필요합니다. 특히 네이밍과 관계 설계는 나중에 바꾸기 어려우므로 신중하게 확인해야 합니다.
Q. Solution Designer로 만든 다이어그램을 실제 구현에 그대로 쓸 수 있나요?
다이어그램 자체가 실행되는 코드는 아닙니다. 다만 Resource 노드로 실제 Dataset·Object Type·Function에 연결해두면, 설계와 실제 구현 사이의 간극을 줄이는 참고 자료로 쓸 수 있습니다.
Q. Workshop이나 Pipeline Builder와는 어떻게 다른가요?
Workshop, Pipeline Builder는 실제로 화면이나 파이프라인을 만드는 구현 도구입니다. Solution Designer는 그 이전 단계, 즉 이런 도구들을 어떻게 조합해서 쓸지 설계하고 논의하는 기획 도구입니다.
다음으로 읽을 글
Solution Designer로 설계한 아키텍처를 실제로 구현하는 단계로 넘어가려면 Foundry에서 데이터 파이프라인을 구축하고 코드로 관리하는 법을, 설계 단계에서 나온 온톨로지를 실제로 만드는 법은 Ontology Manager 실전 가이드를 참고하세요.