이 글은 누구를 위한 것인가
Foundry 애플리케이션은 이름만 세어도 15개가 넘습니다. Foundry를 처음 접해서 애플리케이션 이름이 너무 많아 어디부터 봐야 할지 모르겠는 분, ERP나 전통적인 BI 아키텍처에 익숙해서 Foundry가 그것과 뭐가 다른지 궁금한 분, 혹은 이미 몇 가지 도구는 써봤지만 전체 그림이 잘 안 그려지는 분을 위한 글입니다.
이 블로그에는 Ontology Manager, Workshop, Pipeline Builder 같은 Foundry 애플리케이션별 글이 하나씩 올라가고 있습니다. 그런데 각 글을 따로 읽으면 “이게 전체 그림에서 어디쯤 위치한 도구인지”를 놓치기 쉽습니다. 이 글은 그 전체 그림을 한 번에 보여주는 지도 역할을 합니다 — 데이터가 조직 밖에서 들어와 실제 화면으로 나오기까지, Foundry 안에서 어떤 순서로 어떤 도구를 거치는지를 정리했습니다.
전체 흐름: 연동 → 파이프라인 → 온톨로지 → 애플리케이션 → AI
Foundry는 레고처럼 여러 애플리케이션이 나열된 게 아니라, 아래 순서로 쌓이는 구조입니다. 앞 단계가 없으면 뒤 단계가 의미를 갖지 못합니다.
| 단계 | 하는 일 | 관련 애플리케이션 |
|---|---|---|
| 1. 연동 (Connect) | ERP·DB·파일 등 원천 시스템의 데이터를 Foundry로 가져온다 | Data Connections |
| 2. 파이프라인 (Transform) | 가져온 원본 데이터를 정제·가공해서 쓸 수 있는 형태로 만든다 | Pipeline Builder, Code Repository |
| 3. 온톨로지 (Model) | 정제된 데이터를 업무 용어(Object/Link/Action Type)로 매핑한다 | Ontology Manager |
| 4. 애플리케이션 (Use) | 온톨로지를 화면·분석·대시보드로 사람이 쓸 수 있게 만든다 | Workshop, Contour, Quiver, Object Explorer, Insights |
| 5. AI (Automate) | 온톨로지를 기반으로 AI가 읽고, 판단하고, 행동하게 한다 | AIP (Logic, Assist, Chatbot Studio, Analyst, AI FDE), OMCP |
전통적인 BI/ETL 아키텍처와 무엇이 다른가
전통적인 데이터 웨어하우스 아키텍처는 보통 “ETL → 웨어하우스 → BI 대시보드”라는 3단 구조입니다. 데이터를 미리 정제해서(Transform) 적재하고, 그 위에 대시보드를 붙이는 방식이죠. Foundry의 5단계 구조와 비교하면 다음과 같은 차이가 있습니다.
| 구분 | 전통적 ETL/BI | Foundry |
|---|---|---|
| 정제 시점 | 적재 전에 미리 정제(ETL) | 원본을 먼저 적재하고 이후 정제(ELT에 가까움) |
| 데이터 모델 | 테이블·조인 중심 | 객체·관계·행동 중심(온톨로지) |
| 최종 산출물 | 대시보드(읽기 전용) | 대시보드 + 실행 가능한 애플리케이션(Action) |
| AI와의 결합 | 별도 데이터 파이프라인을 다시 구축해야 함 | 온톨로지가 이미 AI가 참고할 수 있는 구조로 존재 |
가장 큰 차이는 “4. 애플리케이션” 단계와 “5. AI” 단계입니다. 전통적 아키텍처는 대시보드를 보여주는 데서 끝나지만, Foundry는 온톨로지를 매개로 화면에서 바로 데이터를 변경(Action)하거나, AI가 같은 온톨로지를 읽고 행동하게 만들 수 있습니다.
각 단계, 실무에서 느낀 포인트
연동·파이프라인 단계에서 가장 흔한 실수는 “일단 다 연결하고 나중에 정리하자”는 접근입니다. 온톨로지로 넘어가기 전에 데이터를 깨끗하게 만들어두지 않으면, 그 지저분함이 온톨로지 설계에 그대로 전이됩니다. Data Lineage로 어떤 원본에서 왔는지 추적 가능하게 해두는 것도 이 단계의 몫입니다.
온톨로지 단계는 이 블로그에서 이미 여러 번 강조했듯, 기술 용어가 아니라 비즈니스 용어로 모델링해야 하는 지점입니다. 여기서 잘못 설계하면 4단계(애플리케이션)와 5단계(AI) 전부가 흔들립니다. 온톨로지는 파이프라인과 애플리케이션 사이에서 “번역기” 역할을 하기 때문에, 이 번역이 부정확하면 그 위에 아무리 좋은 화면과 AI를 올려도 실제 업무 의미와 어긋난 결과가 나옵니다.
애플리케이션 단계는 목적에 따라 도구가 갈립니다. Workshop은 사람이 직접 조작하는 화면이 필요할 때, Contour와 Quiver는 점 찍고 클릭하는 분석·대시보드가 필요할 때, Object Explorer는 데이터를 탐색만 하면 될 때 씁니다. 셋 다 비슷해 보이지만 “무엇에 쓸 것인가”가 도구를 결정한다는 원칙이 여기서 그대로 적용됩니다.
AI 단계는 온톨로지가 이미 잘 잡혀 있어야 제대로 동작합니다. AIP의 여러 도구(Logic, Assist, Chatbot Studio, Analyst)는 결국 3단계에서 만든 온톨로지를 읽고 쓰는 방식만 다를 뿐입니다. 최근에는 OMCP(Ontology MCP)로 Claude 같은 외부 AI 에이전트도 이 온톨로지에 직접 연결할 수 있게 되면서, “AI 단계”의 경계가 Foundry 안쪽에서 바깥쪽으로도 넓어지고 있습니다.
어디서부터 시작해야 하는가
Foundry를 처음 도입하는 조직이라면, 5단계를 한 번에 다 갖추려 하지 않는 것이 중요합니다. 실무에서 권장하는 순서는 다음과 같습니다.
- 가장 자주 쓰이는 데이터 하나만 우선 연동·정제한다. 전체 시스템을 다 연결하려 하면 온톨로지 설계 전에 지쳐버립니다.
- 그 데이터로 작은 온톨로지 하나를 먼저 만들어봅니다. Object Type 한두 개, Link 한두 개 정도로 시작해도 충분합니다.
- 화면(Workshop)이나 분석(Contour) 하나를 붙여서 실제로 써봅니다. 이 단계에서 온톨로지 설계의 문제가 드러나는 경우가 많습니다.
- 문제를 반영해 온톨로지를 다시 다듬은 뒤에야 AI 단계로 넘어갑니다. 온톨로지가 불안정한 상태에서 AI를 먼저 붙이면, AI의 오답 원인이 모델 문제인지 데이터 문제인지 구분하기 어려워집니다.
자주 반복되는 실무 실패 패턴
- 5단계를 동시에 다 갖추려 하기: 연동부터 AI까지 한 번에 프로젝트 범위를 잡으면, 어느 단계에서 문제가 생겨도 원인을 좁히기 어렵습니다. 단계별로 작게 검증하며 넓혀가는 편이 안전합니다.
- 온톨로지 단계를 파이프라인의 연장으로 취급하기: 온톨로지 설계를 “데이터 정제의 마지막 단계”처럼 다루면, 기술 용어가 그대로 온톨로지에 남는 경우가 많습니다. 온톨로지는 파이프라인과는 다른 관점(업무 용어, 관계, 행동)으로 접근해야 하는 별도의 설계 작업입니다.
- AI 단계의 문제를 온톨로지 문제로 착각하지 못하기: AI가 이상한 답을 낼 때, 실제로는 온톨로지의 Property 설명이 부실하거나 관계가 잘못 정의된 경우가 많습니다. AI 단계에서 문제가 보이면 먼저 3단계(온톨로지)로 돌아가 점검하는 습관이 필요합니다.
마무리
Foundry를 처음 접하면 애플리케이션 이름이 너무 많아서 어디부터 봐야 할지 헷갈립니다. 하지만 결국은 “연동 → 파이프라인 → 온톨로지 → 애플리케이션 → AI”라는 한 줄의 흐름 안에 전부 들어갑니다.
다음으로 읽을 글
데이터가 실제로 어떻게 연동·저장되는지는 Foundry 데이터 통합 가이드와 Foundry는 데이터를 어떻게 저장하는가에서, 온톨로지 매핑은 Ontology Manager 실전 가이드에서, AI 단계는 AIP란 무엇인가에서 이어서 다룹니다.
자주 묻는 질문
Q. Foundry는 기존 BI·ETL 도구와 뭐가 다른가요?
전통적 BI/ETL 스택은 연동·변환·시각화 도구가 각각 분리되어 있어 데이터가 여러 시스템을 거치며 의미를 잃기 쉽습니다. Foundry는 연동부터 온톨로지, 애플리케이션, AI까지 하나의 플랫폼 안에서 계보(Lineage)를 유지한 채 연결됩니다.
Q. 다섯 단계 중 가장 먼저 손대야 하는 건 어디인가요?
연동(원천 데이터 확보)과 파이프라인(정제) 단계가 선행되어야 하며, 이 위에 온톨로지를 올리는 순서가 일반적입니다. 여러 애플리케이션·AI가 데이터를 재사용하려면 온톨로지 단계가 필요합니다.
Q. 온톨로지 단계를 건너뛰고 바로 애플리케이션을 만들 수 있나요?
가능하지만 권장되지 않습니다. 온톨로지 없이 애플리케이션을 만들면 각 앱이 파이프라인 산출물을 개별적으로 다시 해석해야 해서 일관성이 깨지기 쉽습니다.
Q. AI(AIP) 단계는 어디에 연결되나요?
AIP는 온톨로지 위에서 동작합니다. 온톨로지가 정의한 객체·관계·행동을 컨텍스트로 활용해 AIP Assist, Logic, Chatbot Studio 같은 기능이 정확한 답을 만들 수 있습니다.
Q. 이 아키텍처를 도입하는 데 얼마나 걸리나요?
조직 규모와 기존 데이터 정비 상태에 따라 다르지만, 좁은 범위의 파일럿(하나의 프로세스)은 몇 주 안에도 5단계를 모두 경험해볼 수 있습니다. 전사 확장은 별도의 로드맵이 필요합니다.