위젯을 아무리 예쁘게 배치해도 화면이 안 움직이는 이유

위젯을 아무리 예쁘게 배치해도 화면이 안 움직이는 이유

위젯은 다 배치했는데, 클릭해도 아무 반응이 없다

Palantir UI(화면)를 만드는 도구 Workshop에서 자주 벌어지는 일입니다. Filter List, 테이블, 상세 화면까지 위젯을 예쁘게 배치했는데, 목록에서 항목을 클릭해도 상세 화면에 아무것도 나타나지 않습니다. 원인은 배치가 아니라 바인딩입니다. Workshop은 위젯을 어디에 놓느냐보다, 위젯들을 어떻게 연결하느냐가 실제로 화면을 동작시키는 핵심입니다.

Workshop이란

온톨로지 위에 로우코드로 화면을 구성하는 도구입니다. 코드를 거의 쓰지 않고도 실무자가 쓸 수 있는 화면을 만들 수 있지만, “로우코드”라는 말이 “설계가 필요 없다”는 뜻은 아닙니다.

기본 위젯 3가지

위젯 역할
Filter List 조건에 맞는 객체를 걸러서 목록으로 보여줌
Object Table 객체들을 표 형태로 보여줌
Object View / Property Card 선택된 객체 하나의 상세 정보를 보여줌

화면이 움직이게 만드는 4단계 바인딩

1단계. Object Set 변수를 만든다. Filter List가 걸러낸 객체들의 집합을 담는 변수입니다. 이 변수가 없으면 필터링 결과를 다른 위젯에 넘길 방법이 없습니다.

2단계. 이 변수를 테이블에 바인딩한다. Object Table이 이 변수를 참조하도록 연결하면, 필터 결과가 테이블에 표시됩니다.

3단계. 테이블에서 선택한 항목을 Active Object 변수에 담는다. 사용자가 테이블에서 행 하나를 클릭하면, 그 객체 하나를 담는 별도의 변수가 필요합니다. 앞서 말한 “클릭해도 반응 없음” 문제는 대부분 이 단계가 빠져 있을 때 생깁니다.

4단계. Active Object 변수를 상세 화면에 바인딩한다. 이제서야 상세 화면이 선택된 객체의 정보를 렌더링합니다.

이 네 단계가 순서대로 다 연결되어야 화면이 “움직입니다”. 위젯 배치는 이 흐름이 완성된 다음에 다듬어도 늦지 않습니다.

흔한 실수 3가지

변수 이름을 모호하게 짓는다. var1, selectedItem2 같은 이름은 화면이 복잡해질수록 어떤 변수가 어떤 흐름을 담당하는지 추적하기 어렵게 만듭니다.

데이터 흐름을 스케치하지 않고 위젯부터 배치한다. 4단계 바인딩 흐름을 먼저 종이에든 머릿속에든 그려보지 않고 위젯을 놓기 시작하면, 나중에 바인딩을 끼워 맞추느라 더 오래 걸립니다.

온톨로지의 권한 체계를 화면에서 다시 만든다. “이 사용자는 이 데이터를 못 보게 해야 하는데”라는 요구를 Workshop 화면 로직으로 다시 구현하는 경우가 있습니다. 온톨로지 단에서 이미 RBAC로 처리되고 있다면 중복 작업입니다.

정리하면

Workshop에서 화면이 안 움직이는 문제는 거의 항상 배치가 아니라 바인딩에서 생깁니다. Object Set 변수 → 테이블 바인딩 → Active Object 변수 → 상세 화면 바인딩, 이 네 단계를 먼저 데이터 흐름으로 그려보고 시작하면 훨씬 적은 시행착오로 화면을 완성할 수 있습니다.

화면에 나온 객체를 더 깊이 탐색하고 싶다면 Object Explorer를, 데이터가 만들어지는 파이프라인 단계를 보고 싶다면 Pipeline Builder를 이어서 살펴보는 것을 추천합니다.

자주 묻는 질문

Q. Workshop은 완전 노코드인가요? 대부분의 화면 구성은 노코드로 가능하지만, 복잡한 계산 로직이 필요하면 Functions를 연결해야 합니다.

Q. 위젯은 어떤 단위로 바인딩되나요? Object Type의 Property나 Action Type에 바인딩됩니다. 위젯 자체가 데이터를 갖고 있는 게 아니라, 온톨로지의 정의를 참조하는 방식입니다.

Q. BI 툴로 만든 대시보드와 Workshop 화면의 차이는 뭔가요? BI 툴은 대개 조회 전용입니다. Workshop은 Action Type을 통해 화면에서 실제 업무 실행(승인, 상태 변경 등)까지 연결할 수 있다는 점이 다릅니다.

Q. 화면 설계를 먼저 하고 온톨로지를 나중에 다듬어도 되나요? 권장하지 않습니다. 온톨로지 구조가 바뀌면 바인딩도 다시 해야 하므로, 온톨로지가 어느 정도 안정된 뒤에 화면 설계에 들어가는 게 재작업을 줄입니다.

함께 보면 좋은 글

함께 보면 좋은 글

질문이나 지적할 부분이 있으면 문의로 알려주세요.

Questions or corrections? Let us know via Contact.

AI

AI map Ontology

기업 IT·데이터 조직에서 20년 넘게 실무를 해온 사람이 씁니다. 모든 사례는 익명화·일반화합니다. 소개 보기 →

AI

AI map Ontology

Written by someone with 20+ years in enterprise IT and data. All cases are anonymized and generalized. About us →

다음으로 읽어볼 글

개념을 이해했다면, 실제 설계와 활용 방법을 이어서 살펴보세요.

온톨로지 Foundry AIP 기업 AI 전략

Keep reading

Once you understand the concept, continue on to real design and usage patterns.

Ontology Foundry AIP Enterprise AI Strategy