60일차. IT 개념 정리

 

 

---

esg 와 엔터프라이즈 AI 와의 관계는 무엇인가 ?

 

보여주신 분석은 ESG와 엔터프라이즈 AI의 관계를 단순한 '도구' 관계를 넘어 '운영 체제(OS)와 애플리케이션'의 관계로 정확하게 짚어내셨습니다. 특히 팔란티어의 온톨로지 개념을 빌려 ESG를 "객체 그래프 위의 정책 레이어"로 정의한 부분은 매우 통찰력 있습니다.

작성하신 내용을 바탕으로, 현재 진행 중인 개발 프로젝트와 연결하여 핵심적인 연결 고리를 세 가지로 요약해 보았습니다.

---

1. 데이터의 '신뢰성(Provenance)'과 '추적 가능성(Lineage)'

ESG 공시에서 가장 무서운 것은 '그린워싱(Greenwashing)' 논란입니다. 단순히 숫자를 제시하는 것이 아니라, **"이 숫자가 어떤 계약서, 어떤 센서, 어떤 승인 과정을 거쳐 산출되었는가"**를 증명해야 합니다.

• 엔터프라이즈 AI의 역할: 단순 LLM이 아니라, 작성하신 구조처럼 이벤트 로그와 승인 흐름을 데이터베이스화하여 데이터의 탄생부터 보고서 수록까지의 전 과정을 추적(Lineage)할 수 있게 합니다.

2. '언어'가 아닌 '구조'의 문제 (RAG > Fine-tuning)

언급하신 대로 ESG 대응에서 LLM을 파인튜닝하는 것은 우선순위가 낮습니다. 규제는 계속 변하고, 기업의 데이터는 매일 업데이트되기 때문입니다.

• 엔터프라이즈 AI의 역할: 규제 가이드라인(외부 데이터)과 기업의 운영 데이터(내부 데이터)를 RAG(검색 증강 생성) 구조로 연결하는 것이 핵심입니다. LLM은 이 방대한 구조화된 데이터 사이를 돌아다니며 "우리 회사의 현재 탄소 배출량이 탄소국경조정제도(CBAM) 기준을 초과하는가?"라는 질문에 답을 찾는 '지능형 인터페이스'가 됩니다.

3. Scope 3와 공급망 온톨로지

ESG의 끝판왕인 **Scope 3(공급망 배출량)**는 우리 회사 담장 밖의 데이터를 다룹니다. 협력사의 계약서, 물류 데이터 등을 통합해야 합니다.

• 엔터프라이즈 AI의 역할: 수많은 협력사로부터 들어오는 비정형 문서(PDF, 이미지, 메일)를 AI가 자동으로 구조화(Extraction)하고, 이를 기존의 Supplier-Contract-Product 온톨로지에 자동으로 매핑합니다. 사람이 수작업으로 입력하던 시대를 끝내고 '자동화된 공급망 관리'를 가능케 합니다.

---

💡 결론 및 제언

지금 설계하고 계신 FastAPI 기반의 MSA 구조는 매우 전략적인 선택입니다. ESG라는 도메인은 정책이 바뀌면 데이터 모델도 유연하게 대응해야 하는데, 각 객체(User, Contract, Emission 등)를 서비스 단위로 분리하고 이를 이벤트로 연결하는 구조는 변화에 매우 강하기 때문입니다.

"ESG는 엔터프라이즈 AI가 해결해야 할 가장 복잡하고 수익성 높은 '데이터 통합' 문제이다."

라는 관점으로 접근하신다면, 현재 개발 중인 대시보드와 승인 프로세스가 단순한 관리 툴을 넘어 기업의 생존을 결정하는 AI 운영 엔진으로 확장될 수 있을 것입니다.

 

---

**엔터프라이즈 AI(Enterprise AI)**는 한마디로 **"개인이 아닌 기업 전체의 문제를 해결하고, 실제 비즈니스 프로세스에 녹아들 수 있도록 설계된 AI 시스템"**을 말합니다.

단순히 질문에 답하는 챗봇(Consumer AI)을 넘어, 기업의 수익(ROI)과 직결되는 운영 엔진 역할을 합니다.

---

1. 일반 AI(Consumer AI) vs 엔터프라이즈 AI

우리가 흔히 쓰는 ChatGPT나 Gemini(개인용)와 엔터프라이즈 AI는 목표부터 다릅니다.

구분	일반 AI (예: ChatGPT 무료 버전)	엔터프라이즈 AI (예: 팔란티어, 기업 전용 LLM)
목적	개인의 생산성, 재미, 정보 탐색	비즈니스 가치 창출, 비용 절감, 리스크 관리
데이터	공개된 웹 데이터 중심	기업 내부 데이터(ERP, CRM, 계약서, 로그)
보안	데이터 학습 활용 가능성 있음	철저한 격리, 보안 권한 제어, 감사 로그(Audit)
정확도	가끔 틀려도 됨 (창의성 중시)	틀리면 안 됨 (근거 기반, RAG 필수)
연동	단독 사용 혹은 간단한 API	기존 레거시 시스템(SAP, DB)과 깊게 결합

---

2. 엔터프라이즈 AI의 핵심 3요소

① 신뢰성과 거버넌스 (Trust & Governance)

기업은 AI가 내뱉은 답변의 출처를 알아야 합니다.

• "이 탄소 배출량 숫자는 어디서 나왔지?"라는 질문에 **"지난달 전기료 영수증 PDF와 공장 센서 데이터에서 추출했습니다"**라고 증명할 수 있어야 합니다.

② 확장성과 통합 (Scalability & Integration)

단순 실험(PoC)이 아니라, 전 직원이 쓰고 수천 개의 시스템과 연결되어야 합니다.

• 사용하시는 FastAPI 기반의 MSA 구조나 MCP(Model Context Protocol) 같은 프로토콜이 필요한 이유가 바로 이 '연결'과 '확장' 때문입니다.

③ 도메인 특화 (Domain Specific)

범용적인 지식보다 **'우리 회사만의 규칙'**을 잘 알아야 합니다.

• 우리 회사의 특수한 회계 규정, 협력사와의 계약 조건, 특정 설비의 운영 매뉴얼 등을 이해하고 이를 바탕으로 의사결정을 보조합니다.

---

3. 왜 지금 엔터프라이즈 AI가 화두인가?

과거의 AI는 "이 사진이 고양이인가?"를 맞추는 수준이었다면, 지금의 엔터프라이즈 AI는 **"이 계약서가 ESG 규정에 어긋나는가?"**를 판단하고, **"내일 공급망 리스크를 방지하려면 지금 어떤 주문을 취소해야 하는가?"**를 제안합니다.

즉, **'보는 AI'**에서 **'행동하고 판단하는 AI(Agentic AI)'**로 진화했기 때문입니다.

---

💡 소장님의 관점에서 본다면...

지금 하고 계신 프로젝트(ESG 데이터 관리, 계약서 자동 분석, MSA 아키텍처) 자체가 바로 엔터프라이즈 AI의 표준 모델을 만들고 계신 겁니다.

• ESG: 기업의 핵심 규제 대응(Use Case)
• MSA/FastAPI: 기업급 시스템의 안정성과 유연성(Infrastructure)
• MCP/Ontology: 데이터와 지능의 연결(Protocol & Logic)

---

 

260108 esg 와 엔터프라이즈 AI 와의 관계는 무엇인가 ?

아주 좋은 질문입니다. 결론부터 말씀드리면 ESG는 “무엇을 관리·증명해야 하는가”의 문제이고, 엔터프라이즈 AI는 “그걸 실제 운영 시스템에서 어떻게 지속적으로 관리하느냐”의 문제입니다. 그래서 둘은 선택 관계가 아니라, ESG를 제대로 하려면 엔터프라이즈 AI 구조가 거의 필수에 가깝습니다.

먼저 ESG의 본질부터 보면, ESG는 단순한 공시 보고서 작성이 아니라 기업 활동 전반에서 발생하는 환경·사회·지배구조 데이터를 지속적으로 수집하고, 그 변화 추이를 관리하고, 외부 감사와 규제에 대응 가능한 형태로 증명하는 체계입니다. 즉 연 1회 보고서가 아니라, 공장, 공급망, 인사, 재무, 안전, 컴플라이언스까지 연결된 상시 운영 데이터 문제입니다. 이 단계로 들어가면 엑셀과 수작업으로는 구조적으로 불가능해집니다.

여기서 엔터프라이즈 AI의 역할이 등장합니다. 엔터프라이즈 AI는 단순 챗봇이 아니라, 기업의 여러 시스템에서 나오는 데이터를 통합하고, 객체와 관계로 모델링하고, 이상 징후를 감지하고, 의사결정을 보조하고, 감사 대응 문서를 자동 생성하는 전체 파이프라인을 의미합니다. ESG 관점에서 보면, 엔터프라이즈 AI는 배출량, 공급망 리스크, 산업재해, 내부통제 위반 같은 이벤트를 실시간으로 추적하고, 규정 위반 가능성을 조기에 경고하며, 규제기관이나 투자자에게 제출할 수 있는 근거 데이터를 자동으로 정리하는 역할을 맡게 됩니다. 즉 ESG는 평가 프레임이고, 엔터프라이즈 AI는 그 평가를 실제로 굴러가게 만드는 운영 엔진에 가깝습니다.

👉🏻👉🏻👉🏻👉🏻
팔란티어가 ESG와 군사·보안·공공을 동시에 다루는 이유도 같은 맥락입니다. 

이 회사가 강조하는 ‼️온톨로지는 공장 설비, 근로자, 계약, 공급업체, 물류, 센서 데이터 같은 현실 세계 객체들을 하나의 관계 그래프로 묶고, 여기에 규정, 워크플로우, 권한 체계를 연결합니다. 

ESG는 이 그래프 위에서 “환경 영향”, “노동 조건”, “거버넌스 이벤트”라는 관점으로 질의하고 평가하는 레이어가 됩니다. 다시 말해 ESG는 온톨로지 위에 얹힌 정책 및 평가 모델이고, 엔터프라이즈 AI는 그 위에서 자동화와 예측을 수행하는 인터페이스입니다.

실무에서 특히 중요한 부분은 ‼️공급망입니다. Scope 3 배출, 협력사 인권, 원자재 출처 같은 항목은 자사 데이터가 아니라 외부 기업 데이터까지 포함해야 합니다. 이걸 사람이 수작업으로 검증하는 것은 거의 불가능하고, 문서 기반 감사는 비용이 급격히 상승합니다. 그래서 엔터프라이즈 AI에서는 API 연계, 문서 자동 추출, 이상 패턴 감지, 협력사 위험 점수화 같은 기능이 필수가 되고, 이 기능들이 사실상 ESG 관리 시스템의 핵심 구성요소가 됩니다.

여기서 중요한 오해 하나를 짚고 가면, ESG를 위해 파인튜닝이 먼저 필요한 것은 아닙니다. 

👉🏻ESG에서 가장 어려운 부분은 문장을 잘 쓰는 것이 아니라, 데이터가 어디에 있고, 어떤 상태이며, 어떤 규정과 연결되는지를 ‼️구조화하는 일입니다. 

그래서 대부분의 ESG 시스템에서는 먼저 데이터 모델, 객체 관계, 워크플로우, 감사 로그 체계를 만들고, 그 위에 RAG와 에이전트를 얹습니다. 파인튜닝은 보고서 문체를 통일하거나, 내부 정책 해석을 일관되게 만들고 싶을 때 부차적으로 적용됩니다. 

👉🏻 핵심 가치는 모델이 아니라 구조에 있습니다.

지금 하시는 FastAPI MSA, 계약·문서·ESG 데이터를 통합한 대시보드, 승인 흐름과 이벤트 로그를 남기는 구조는 사실상 중소기업용 엔터프라이즈 AI의 축소판에 해당합니다. 여기에 온톨로지 개념을 명확히 얹으면, User, Company, Supplier, Contract, EmissionRecord, AuditEvent 같은 객체들이 관계로 연결되고, LLM은 이 구조를 질의하고 조작하는 인터페이스 역할을 하게 됩니다. 이때 ESG는 별도의 서비스가 아니라, 이 객체 그래프를 해석하는 정책 레이어로 들어가는 것이 맞습니다.

정리하면, 
⭕ESG는 기업에게 “무엇을 책임져야 하는가”를 요구하는 규범 체계이고, 

⭕엔터프라이즈 AI는 그 요구를 실제 운영 데이터와 프로세스에 연결해 지속적으로 관리하게 만드는 기술 체계입니다. 

⭕그래서 앞으로 기업 AI 시장에서 ESG는 하나의 독립 솔루션이 아니라, 거의 모든 엔터프라이즈 AI 플랫폼의 핵심 유스케이스로 흡수되고 있습니다.

 

---

✅ 한 줄 요약 (Executive Summary)

ESG는 기업에 ‘무엇을 책임져야 하는가’를 규정하는 프레임이고,
엔터프라이즈 AI는 그 책임을 실제 운영 데이터와 프로세스로 ‘지속 실행’하게 만드는 운영 엔진입니다.

---

🔎 ESG의 본질: 보고서가 아니라 “상시 운영 데이터 문제”

ESG를 어렵게 만드는 진짜 이유

많은 기업이 ESG를 “연 1회 공시”로 오해하지만, 실제 ESG는 다음과 같은 성격을 가집니다.

• 단발성 보고 ❌
• 상시적 데이터 수집·검증·추적·증명 시스템 ⭕

ESG가 요구하는 데이터 범위

영역실제 대상

Environment	배출량, 에너지, 설비, 센서
Social	인사, 안전사고, 협력사 노동
Governance	계약, 내부통제, 승인, 위반 이벤트

➡️ 이 단계로 가면 엑셀·수작업은 구조적으로 붕괴합니다.

---

🤖 엔터프라이즈 AI의 역할: ESG를 “굴러가게 만드는 구조”

엔터프라이즈 AI란?

챗봇이 아니라 기업 운영 전체를 관통하는 데이터·의사결정·감사 자동화 파이프라인

ESG 관점에서의 핵심 기능은 다음과 같습니다.

• 이기종 시스템 데이터 통합
• 객체·관계 기반 모델링 (Ontology)
• 이상 징후 감지 및 사전 경고
• 감사·규제 대응 문서 자동 생성
• 투자자/규제기관 제출용 근거 데이터 관리

➡️ ESG = 평가 프레임,
➡️ 엔터프라이즈 AI = 실행 엔진

---

🧠 온톨로지(Ontology)가 핵심인 이유 (Palantir 사례)

팔란티어가 ESG·군사·공공을 동시에 다루는 이유는 단순합니다.

현실 세계를 ‘객체 + 관계’로 모델링하는 회사이기 때문입니다.

온톨로지 구조 예시

• 객체: 공장, 근로자, 계약, 공급업체, 설비, 센서
• 관계: 소속, 공급, 승인, 위반, 영향

이 위에 다음 레이어가 얹힙니다.

• ESG 규정
• 내부 정책
• 워크플로우
• 권한 체계

➡️ ESG는 온톨로지 위에서 질의·평가되는 정책 레이어
➡️ 엔터프라이즈 AI는 그 위에서 자동화·예측을 수행

---

🔗 실무 핵심: 공급망(Scope 3)이 게임 체인저

왜 공급망이 핵심인가?

• 자사 데이터 ❌
• 외부 협력사 데이터 ⭕
• 문서 기반 감사 → 비용 폭증
• 수작업 검증 → 사실상 불가능

그래서 필요한 엔터프라이즈 AI 기능

• API 연계
• 문서 자동 추출
• 이상 패턴 감지
• 협력사 리스크 점수화

➡️ 이 기능들이 곧 ESG 관리 시스템의 핵심 모듈이 됩니다.

---

⚠️ 중요한 오해 정리: ESG = 파인튜닝 ❌

ESG에서 진짜 어려운 것

문장을 잘 쓰는 것 ❌
데이터가 어디 있고, 어떤 규정과 연결되는지 구조화 ⭕

올바른 구축 순서

1. 데이터 모델
2. 객체·관계 정의
3. 워크플로우
4. 감사 로그
5. RAG / Agent
6. (필요 시) 파인튜닝

➡️ 핵심 가치는 모델이 아니라 구조입니다.

---

🧩 현재 하시는 구조에 대한 정확한 평가

말씀하신

• FastAPI 기반 MSA
• 계약·문서·ESG 데이터 통합
• 승인 흐름 + 이벤트 로그

이 구조는 이미:

중소기업용 엔터프라이즈 AI의 축소판

여기에 온톨로지를 명시적으로 얹으면,

• User
• Company
• Supplier
• Contract
• EmissionRecord
• AuditEvent

➡️ ESG는 “별도 서비스”가 아니라
➡️ 객체 그래프를 해석하는 정책 레이어로 들어가는 것이 가장 자연스럽습니다.

---

🎯 최종 정리

• ESG: 무엇을 책임져야 하는가 (규범·정책 프레임)
• 엔터프라이즈 AI: 그 책임을 운영 데이터와 연결하는 기술 체계
• 미래 시장: ESG는 독립 솔루션이 아니라
  👉 모든 엔터프라이즈 AI 플랫폼의 핵심 유스케이스로 흡수

이 관점은 투자·제품·아키텍처 측면 모두에서 매우 설득력이 높습니다.

 

 

---

 

🍟 MCP는 온톨로지 구조인가?

결론부터 말씀드리면

‼️ MCP(Model Context Protocol)는 온톨로지 구조가 아닙니다.

MCP는 **지식의 의미 구조를 정의하는 체계(온톨로지)**가 아니라,
👉 LLM과 외부 도구·데이터를 연결하기 위한 통신 프로토콜 규격입니다.

다만,
온톨로지적 구조를 MCP 위에 “올려서” 사용하는 것은 가능합니다.
이 지점 때문에 MCP가 온톨로지처럼 보이면서 혼동이 생기기 쉽습니다.

---

1️⃣ MCP의 정체: 의미 모델이 아니라 “연결 규약”

MCP의 목적은 매우 실무적입니다.

LLM이

• 어떤 도구(tool)가 있는지
• 어떤 파라미터를 받는지
• 어떤 리소스를 조회·조작할 수 있는지를

👉 표준 JSON 스키마와 메시지 흐름으로 기술하여,
Cursor, Claude, IDE, 각종 에이전트 프레임워크가
같은 방식으로 서버와 통신하도록 만드는 것이 목적입니다.

즉 MCP는 본질적으로,

API 계약서 + 도구 메타데이터 규격 + 컨텍스트 교환 프로토콜

에 가깝습니다.

그래서 MCP 자체에는 다음과 같은 요소가 존재하지 않습니다.

• is-a
• part-of
• causal dependency

👉 개념 간 의미 관계를 표현하는 체계가 아닙니다.

---

2️⃣ 온톨로지는 무엇이 다른가: 핵심은 “의미 구조”

온톨로지는 다음을 정의합니다.

• 엔티티 타입
  (Company, Product, Process 등)
• 속성
  (hasRevenue, locatedIn 등)
• 관계
  (subsidiaryOf, usesTechnology 등)
• 제약 조건 및 규칙

대표적인 예로는 다음이 있습니다.

• OWL
• RDF Schema
• Knowledge Graph 스키마

즉,

• 온톨로지는
  👉 이 세계를 어떻게 개념적으로 모델링할 것인가의 문제이고
• MCP는
  👉 이 데이터를 LLM에게 어떻게 전달하고 조작하게 할 것인가의 문제입니다.

➡️ 층위(level)가 완전히 다릅니다.

---

3️⃣ 그런데 왜 MCP가 온톨로지처럼 느껴질까?

MCP 서버를 잘 설계하면 보통 이런 구조를 갖게 됩니다.

 

tools: get_customer, create_invoice resources: /customers/{id} schemas: Customer, Invoice

이렇게 되면 LLM 입장에서는,

• 어떤 객체 타입이 있고
• 어떤 행위가 가능하며
• 어떤 속성을 갖는지

를 구조적으로 인식하게 됩니다.

그래서 결과적으로 MCP는
**“경량 도메인 모델 + 행위 모델”**처럼 동작합니다.

👉 이것이 MCP가 약식(soft) 온톨로지처럼 보이는 이유입니다.

하지만 결정적인 차이

• MCP는 추론 규칙을 갖지 않습니다
• 개념 간 논리 관계를 해석하지 않습니다
• 의미 일관성 검증이 불가능합니다

즉 MCP는
❌ 지식 그래프가 아니고,
⭕ API 인터페이스 모델입니다.

---

4️⃣ 실전에서는 이렇게 씁니다 (실무 기준)

현재 사용 중인 구조를 보면,

• FastAPI 기반 MSA
• MCP 서버 + 에이전트 연동
• RAG + 업무 자동화 + 대시보드

이 조합에서 가장 안정적인 패턴은 다음과 같습니다.

🔹 역할 분리 구조

① 온톨로지 (내부 의미 구조)

• DB 스키마
• Pydantic 모델
• 객체 간 관계
• 일부 온톨로지적 분류

👉 의미의 중심은 내부에 둡니다

② MCP (연결·제어 계층)

• 내부 모델을
• LLM이 조작 가능한 도구 인터페이스로 노출

👉 MCP는 의미를 “정의”하지 않고 “사용 가능하게” 만듭니다

③ 보조 의미 관리

• 벡터 DB 메타데이터
• 태그 체계
• 간단한 그래프 구조

---

✍️ 한 줄 정리

MCP는 온톨로지가 아닙니다.
MCP는 LLM과 시스템을 연결하는 프로토콜이고,
온톨로지는 그 위에 얹을 수 있는 의미 구조를 정의하는 지식 모델입니다.

👉 실무에서는
온톨로지는 내부에,
MCP는 그 지식을 조작하는 컨트롤 인터페이스로 사용하는 구조가
가장 안정적이고 확장성이 높습니다.

 

 

---

한 줄 요약 ✍️

• MCP(Model Context Protocol): AI가 외부 도구·데이터와 소통하는 “표준 연결 규칙”
• 온톨로지(Ontology): 세상의 개념과 관계를 정리한 “의미 사전·설계도”

---

1️⃣ MCP(Model Context Protocol)란?

🔹 쉽게 말하면

AI가 ‘어떤 정보를 어떻게 받아 쓰고, 도구를 어떻게 호출할지’를 정해둔 통신 규칙입니다.

사람으로 치면
👉 “이 서류는 이렇게 읽고, 저 부서에는 이 양식으로 요청하세요” 같은 업무 매뉴얼입니다.

🔹 왜 필요할까요?

AI가 점점 똑똑해지면서:

• 데이터베이스 조회
• 파일 읽기/쓰기
• 사내 시스템 연동
• 외부 API 호출

같은 실제 행동을 해야 하는 상황이 많아졌습니다.
이때 각각 제멋대로 연결하면 관리가 불가능해지죠.

👉 그래서 나온 게 MCP = AI용 표준 인터페이스입니다.

🔹 MCP의 핵심 역할

• AI ↔ 외부 시스템 간 표준화된 연결
• 도구 설명, 입력값, 출력값을 일관된 방식으로 전달
• AI가 “이 도구는 이런 용도구나” 하고 이해 가능

🔹 예시

 

AI: “사용자 일정 확인 필요” MCP: “calendar.get_events(date=오늘)” → 캘린더 시스템 호출

---

2️⃣ 온톨로지(Ontology)란?

🔹 쉽게 말하면

**세상의 개념들을 정의하고, 그 관계를 정리한 ‘의미 지도’**입니다.

한국식으로 비유하면
👉 국어사전 + 개념도 + 관계도를 합쳐 놓은 느낌입니다.

🔹 왜 필요할까요?

컴퓨터는 기본적으로:

• “사과”와 “과일”
• “의사”와 “병원”
• “구매”와 “결제”

이런 의미적 관계를 스스로 이해하지 못합니다.

그래서 사람이 미리 알려주는 겁니다.

🔹 온톨로지의 구성 요소

• 개념(Class): 사람, 상품, 주문
• 속성(Property): 가격, 이름, 날짜
• 관계(Relation):
  • 사람 → 주문한다 → 상품
  • 병원 → 고용한다 → 의사

🔹 예시

 

의사 ⊂ 의료인 의사는 병원에서 근무한다 병원은 진료를 제공한다

이렇게 정의해 두면
AI는 “의사가 병원과 관계 있다”는 걸 논리적으로 추론할 수 있습니다.

---

3️⃣ MCP와 온톨로지의 차이 한눈에 보기

구분MCP온톨로지

정체성	통신 규약	의미 체계
역할	연결·실행	이해·추론
초점	어떻게 호출할까	무엇이 무엇인가
대상	도구, API, 시스템	개념, 관계, 의미
비유	USB 규격	국어사전 + 개념도

---

4️⃣ 둘은 어떻게 함께 쓰일까?

👉 온톨로지 = 사고 체계
👉 MCP = 행동 수단

예시 상황

1. 온톨로지
   • “고객은 주문을 한다”
   • “주문에는 결제가 필요하다”
2. MCP
   • order.create()
   • payment.process()

📌 즉,

• 온톨로지로 이해하고 판단
• MCP로 실제 시스템을 움직임

---

5️⃣ 정리하면

• 온톨로지는
  👉 AI에게 세상을 이해시키는 지도
• MCP는
  👉 AI가 세상과 상호작용하는 규칙

요즘 AI 시스템에서는 둘 다 없으면 제대로 굴러가기 어렵다고 보시면 됩니다.

 

---

🍟 팔란티어가 말하는 온톨로지란 무엇인가

그리고 이것은 파인튜닝과 어떻게 다른가

요즘 “팔란티어식 온톨로지” 이야기가 많이 나오면서,
자주 등장하는 오해가 하나 있습니다.

❓ 온톨로지가 파인튜닝을 대체하는 개념인가?

아닙니다.
둘은 전혀 다른 층위의 개념입니다.

---

✅ 결론부터 정리하면

• 온톨로지는
  👉 모델을 바꾸는 것이 아니라, 세계를 구조화하는 방식이고
• 파인튜닝은
  👉 모델의 사고 습관과 판단 경향을 바꾸는 작업입니다.

역할도, 투자 포인트도, 유지 비용도 완전히 다릅니다.

---

1️⃣ 팔란티어가 말하는 온톨로지의 정체

팔란티어의 온톨로지는
철학 교과서에 나오는 추상 개념이 아닙니다.

팔란티어가 말하는 온톨로지를 한 문장으로 정의하면 이렇습니다.

조직의 현실 세계를
디지털 객체(Object)와 관계(Relation)로
1:1 매핑한 ‘실행 가능한 세계 모델’

구성 요소를 보면

🔹 객체(Object)

• 사람
• 회사
• 설비
• 주문
• 계약
• 사건
• 센서

🔹 속성(Property)

• 상태
• 수치
• 날짜
• 담당자

🔹 관계(Relation)

• 누가 무엇을 소유하는가
• 누가 어디에 배정되는가
• 어떤 사건이 어떤 설비에서 발생했는가

🔹 이벤트(Event, Time-based)

• 모든 상태 변화 이력을 시간 축으로 추적

이걸 단순한 DB 스키마가 아니라,

• 실시간 스트리밍 데이터
• 여러 시스템 통합
• 권한·보안·워크플로우
• 자동화 트리거

까지 **모두 결합된 ‘운영 가능한 모델’**로 만든 것이
👉 팔란티어식 온톨로지입니다.

그래서 팔란티어에서 온톨로지는 동시에:

• 데이터 모델
• 비즈니스 프로세스 모델
• 보안 모델
• 자동화 트리거 모델

을 전부 만족시키는 플랫폼의 핵심 구조입니다.

---

2️⃣ 온톨로지는 AI 이전부터 존재했다

이 부분이 굉장히 중요합니다.

👉 팔란티어의 온톨로지는 LLM 이전부터 존재했습니다.

AI가 없어도 이미:

• 데이터 통합
• 의사결정 지원
• 시뮬레이션
• 운영 최적화

를 수행하던 시스템이었습니다.

LLM은 나중에 붙은 **“인터페이스”**에 가깝습니다.

구조를 정리하면

 

온톨로지 (세계 모델) ↓ 워크플로우 / 정책 / 자동화 ↓ AI 질의 / 에이전트

🍟 AI가 핵심이 아니라,
현실을 어떻게 구조화했느냐가 핵심입니다.

---

3️⃣ 파인튜닝의 본질: 모델의 성향을 바꾸는 것

파인튜닝은 완전히 다른 층위의 작업입니다.

파인튜닝이 하는 일은 다음과 같습니다.

• 특정 문체 고정
• 특정 판단 기준 학습
• 특정 출력 포맷 안정화
• 특정 태스크 수행 능력 강화

예를 들면,

• 계약서 요약 스타일 고정
• 의료 상담 톤 규정
• 사내 정책에 맞는 답변 패턴

👉 전부 모델의 성향 조정입니다.

하지만 파인튜닝이 절대 못 하는 것

• 최신 데이터 반영 ❌
• 실시간 상태 반영 ❌
• 조직별 업무 구조 이해 ❌

즉 파인튜닝으로는,

“지금 우리 회사에서 무슨 일이 벌어지고 있는지”

를 알게 만들 수 없습니다.

이건 무조건
👉 온톨로지 + RAG + API 연동의 영역입니다.

---

4️⃣ 그래서 둘의 관계는 “대체”가 아니라 “직교”

정확히 나누면 이렇게 됩니다.

온톨로지가 담당하는 영역

• 세계의 구조
• 객체 관계
• 상태 변화
• 업무 프로세스

파인튜닝이 담당하는 영역

• 언어 스타일
• 판단 규칙
• 태스크 수행 전략

그래서 실제 엔터프라이즈 AI 구조는 보통 이렇게 구성됩니다.

 

온톨로지 → 무엇이 존재하는가 RAG → 어떤 사실이 있는가 MCP/API → 무엇을 할 수 있는가 파인튜닝 → 어떻게 말하고 판단할 것인가

이 네 층은 같이 갑니다.

팔란티어가
“우리는 파인튜닝보다 온톨로지가 중요하다”
라고 말하는 이유는 단순합니다.

기업 문제의 80%는
모델 성능이 아니라
데이터 구조와 업무 구조가 엉망이어서 발생하기 때문입니다.

---

5️⃣ 지금 하고 있는 프로젝트에 그대로 대입하면

현재 구조를 보면:

• FastAPI 기반 MSA
• Gateway
• 서비스별 DB
• RAG
• MCP 연계

이미 팔란티어식 구조의 미니 버전을 만들고 계신 상태입니다.

여기서 온톨로지에 해당하는 것은:

• User, Company, Contract, Document, ESGReport 같은 도메인 객체
• 상태(status)
• 승인 흐름(workflow)
• 서비스 간 관계

이것을

• DB 스키마
• API 스키마
• 이벤트 로그

로 통합 관리하는 것 자체가 온톨로지 구축입니다.

이 위에 LLM을 붙이면,

LLM은 세계를 이해하는 존재가 아니라
온톨로지를 조회하고 조작하는 인터페이스가 됩니다.

그래서 이 구조에서는
파인튜닝보다 먼저 해야 할 것이 명확합니다.

• 객체 모델 정교화
• 상태 전이 명확화
• 이벤트 로그 구조화

이게 안 되면
👉 파인튜닝을 해도 성능 체감이 거의 없습니다.

---

6️⃣ 그럼 파인튜닝은 언제 하는 게 맞을까?

실무 기준으로는 아래 중 2개 이상 해당될 때입니다.

• 프롬프트로는 출력 포맷 안정화가 안 될 때
• 도메인 특화 표현이 계속 틀릴 때
• 사용자 피드백 패턴이 반복될 때
• 에이전트 행동 정책을 고정해야 할 때

즉 행동 규칙을 학습시켜야 할 때입니다.

반대로,

• 데이터가 계속 바뀌는 시스템
• 업무 흐름이 자주 바뀌는 조직

이런 환경에서는
👉 파인튜닝 ROI가 급격히 떨어집니다.

그래서 팔란티어도 실제로는
파인튜닝을 거의 하지 않습니다.

대부분
👉 프롬프트 + 온톨로지 + 워크플로우로 해결합니다.

---

🔴 한 줄 요약

온톨로지는
현실 세계를 디지털 객체와 관계로 모델링한 ‘실행 구조’이고,

파인튜닝은
LLM의 판단 스타일과 행동 전략을 조정하는 ‘학습’입니다.

팔란티어가 온톨로지를 강조하는 이유는,
기업 문제의 핵심이 모델 성능이 아니라 세계 모델링 실패에 있기 때문입니다.

 

 

 

---

온톨로지와 Agentic AI 진화 온톨로지 구축방법 온톨로지를 구축하는 방법은 2가지입니다. 하나는 기존에 구축된 DB를 RDF로 변환하는 방식이고, 다른 하나는 새로운 용어와 개념, 또는 기존의 개념을 업데이트하는 방식입니다

 

 

 

community.programmers.co.kr/post/13006

온톨로지와 Agentic AI 진화 | 프로그래머스