Kraken.: 사내 데이터로 업무 온톨로지를 자동 생성해 AI 답의 근거를 잇는 일본 플랫폼
일본 에프티의 Kraken.은 사내 정형·비정형 데이터를 문맥째 반구조화하고 사람·제품·공정·불량·문서를 잇는 온톨로지를 자동으로 만들어, AI가 답의 근거를 거꾸로 찾아가게 합니다. 관계·의미 부여 정확도는 약 85%에서 98% 이상으로 올랐다고 밝혔습니다. Mesodata 필드, 표본 검수 기준, 8주 파일럿안을 붙였습니다.
제조업에서 AI가 헛도는 이유는 데이터가 없어서가 아니라, AI가 데이터의 업무상 뜻과 배경을 모르기 때문이라는 진단입니다. 일본 에프티는 사람 손으로 하던 의미 부여를 자동화해 이 문제를 풀려 합니다. 옮기려면 리드타임처럼 여러 부서를 가로지르는 업무 하나를 고르고 자동으로 만든 관계를 현업이 표본으로 검수하는 절차를 먼저 정해야 합니다.
요약
MONOist의 미시마 기자는 2026년 10월 21일 일본 에프티(エフティー)의 가토 히로오(加藤大雄) 대표를 인터뷰했습니다. 에프티는 Kraken.이라는 지식형 데이터 메시 플랫폼을 만듭니다. 데이터 메시(data mesh)는 데이터를 한곳에 모으지 않고 부서가 각자 소유하게 두는 구조입니다. Kraken.은 회사 곳곳에 흩어진 정형·비정형 데이터를 읽어 업무 개념과 그 관계를 담은 온톨로지(ontology, 개념과 관계의 체계)를 자동으로 만듭니다. 처리는 두 단계입니다. 먼저 어떤 형식의 데이터든 문맥을 살린 채 반구조화합니다. 그다음 사람·조직·제품·공정·불량·문서를 다차원 그래프로 엮는 Dynamic Ontology(동적 온톨로지)를 만듭니다. 이렇게 만든 것을 회사는 의미 공간(意味空間)이라 부르고 AI는 여기서 답의 근거를 거꾸로 찾아갈 수 있습니다.
에프티가 내세우는 효과는 재현성입니다. 업무상 뜻이 구조화돼 있으면 AI가 같은 질문에 같은 답을 내고 사람이 결과를 다시 검산하는 비용이 줄어든다는 설명입니다. 회사는 관계와 의미 부여의 정확도가 몇 달 전 약 85%에서 지금 98% 이상으로 올랐다고 밝혔습니다. 구조화에 쓰는 AI 모델이 좋아진 덕분이라고 합니다. 많은 대형 제조사가 시험 도입을 시작했고 에프티는 제조업과 건설업에 먼저 집중하면서 PLM(제품 수명주기 관리) 벤더 Aras와 공동 제안을 하고 있습니다. 아래에서는 다섯 가지 작동 원리를 풀고 우리 공장에서 같은 구조를 시험할 때 필요한 필드·검수 기준·일정을 덧붙입니다.
핵심 메커니즘
반구조화(半構造化): 문맥을 살린 채 태그를 붙이는 첫 단계
무엇인가. 원천 데이터를 표로 완전히 바꾸지 않고 원래 문맥을 유지한 채 업무 태그와 관계 태그를 달아 두는 단계입니다.
어떻게 작동하나. 원문이 밝힌 순서는 네 단계입니다. 모든 데이터에서 텍스트를 뽑고 문맥을 이해해 요약하고 업무 태그를 붙이고 관계 태그를 붙입니다. Kraken.은 이 네 단계를 자동으로 처리합니다. 출력은 사람이 설계한 스키마에 끼워 맞춘 행이 아니라, 원본과 연결된 태그 묶음입니다.
언제 쓰나. 설계 데이터, 업무 문서, 종이, Excel처럼 형식이 제각각인 자료에 노하우가 묻혀 있을 때 맞습니다. 이미 잘 정의된 ERP 테이블만 다룬다면 이 단계의 이득은 작습니다.
작은 예시(가상). 품질 회의록 한 쪽에서 “하우징 균열”을 불량 태그로, “사출 온도 변경”을 공정 태그로 달고 둘 사이에 “원인 후보” 관계를 붙입니다. 회의록 파일과 쪽 번호는 그대로 남깁니다.
Dynamic Ontology: 업무 대상을 다차원 그래프로 엮는 둘째 단계
무엇인가. 반구조화한 데이터를 바탕으로 사람·조직·제품·공정·불량·문서를 그래프로 동적으로 연결해 데이터의 의미, 관계, 근거를 구조화한 것입니다.
어떻게 작동하나. 새 데이터가 들어오면 태그를 보고 그래프의 알맞은 자리에 자동으로 배치합니다. 가토 대표는 그래서 복잡한 전처리나 재설계 없이 바로 활용 단계로 들어갈 수 있다고 말합니다. 추출한 지식은 6개 층으로 나뉜 온톨로지에 놓입니다. 층의 이름은 원문에서 밝히지 않았습니다.
언제 쓰나. “이 불량이 어느 공정, 어느 설계 변경, 어느 협력사와 이어지나”처럼 여러 부서의 데이터를 건너야 답이 나오는 질문에 맞습니다.
원문의 예. 원문이 든 연결 대상은 사람, 조직, 제품, 공정, 불량, 문서 여섯 가지입니다.
Mesodata(メゾデータ): 문맥·관계·출처를 함께 담는 데이터 표현
무엇인가. 기업 데이터의 문맥, 관계, 출처를 한 단위로 묶어 구조화하는 에프티의 데이터 표현 방식입니다. 원본 데이터와 그 위의 메타데이터 사이에 있는 중간층이라고 보면 이해가 쉽습니다.
어떻게 작동하나. 추출한 지식 조각마다 어디서 왔는지와 무엇과 이어지는지를 함께 저장합니다. AI가 답을 내면 그 답이 기댄 Mesodata를 따라 원본 위치까지 거꾸로 찾아갈 수 있습니다. 원문은 이를 AI가 답의 근거로 역추적할 수 있는 의미 공간이라고 설명합니다.
언제 쓰나. 답의 출처를 사람이 확인해야 하는 품질·설계·안전 업무에서 특히 쓸모가 큽니다.
지식형 데이터 메시: 소유는 부서에, 의미는 전사 공통으로
무엇인가. 각 사업 도메인이 자기 데이터를 소유·관리하되, 의미 공간은 회사 전체가 함께 쓰는 구조입니다.
어떻게 작동하나. 데이터를 중앙으로 옮기지 않습니다. 설계 부서는 설계 데이터를, 생산기술은 공정 데이터를 그대로 관리합니다. 대신 각 데이터가 업무상 무슨 뜻이고 무엇과 이어지는지는 공통 의미 공간에 올라갑니다. 그래서 다른 부서의 데이터도 뜻과 가치를 알고 골라 쓸 수 있습니다.
왜 이렇게 했나. 가토 대표는 데이터 레이크와 온톨로지 구축이 주목받지만 사람 손이 많이 들어 잘 진척되지 않는다고 봅니다. 데이터 정비 솔루션은 많아도 사람 손을 거의 빼는 것은 드물다는 판단입니다.
의미 공간: 노하우를 구조화해 답의 재현성을 높인다
무엇인가. 회사의 노하우, 업무 규칙, 판단 기준을 구조화해 AI가 기업 데이터를 업무상 뜻으로 다루게 하는 토대입니다.
어떻게 작동하나. 의미 공간이 없으면 AI는 데이터의 배경을 모르고 상황에 따라 다른 답을 냅니다. 회사 고유의 뜻이 구조화돼 있으면 답이 일정해집니다. 답이 일정하면 사람이 매번 검산하지 않아도 되고 정리한 지식은 회사의 자산으로 남습니다.
앞으로의 쓰임. 에프티는 이 의미 공간을 AI 에이전트와 피지컬 AI 실행으로 잇겠다고 밝혔습니다. 디지털 트윈과 연결해 상황 파악, 판단, 실행, 결과에 따른 수정이 한 바퀴로 돌게 하는 구상입니다.
통념과 다른 주장
흔히 이렇게 봅니다제조업에서 AI가 잘 안 되는 것은 쓸 만한 데이터가 없기 때문이다.
저자는 이렇게 봅니다데이터는 이미 많습니다. AI가 쓸 수 있는 상태로 정리돼 있지 않은 것이 진짜 문제입니다.
근거일본 제조업에는 설계 데이터, 업무 문서, 종이, Excel에 지식과 노하우가 쌓여 있고 이것을 읽어 내면 새 가치를 만들 여지가 있다는 것이 가토 대표의 설명입니다.
흔히 이렇게 봅니다온톨로지는 도메인 전문가가 개념과 관계를 손으로 설계해야 믿을 수 있다.
저자는 이렇게 봅니다사람 손이 바로 병목입니다. 그래서 Kraken.은 처음부터 「基本的に自動化する」는 생각으로 만들었습니다.
근거데이터를 넣으면 자동으로 온톨로지에 배치되고 관계·의미 부여 정확도는 몇 달 사이 약 85%에서 98% 이상으로 올랐습니다. 회사는 구조화에 쓰는 AI 모델의 진화를 이유로 듭니다.
저자가 든 사례
에프티: 데이터 정제소 구상에서 Kraken.까지
| 구분 | 내용 |
|---|---|
| 상황 | Palantir 같은 회사가 주목받을 무렵, 흩어진 데이터를 쓸 수 있게 만드는 데이터 정제소(data refinery) 역할이 중요해진다고 판단. 데이터 주권 문제로 일본에도 이 역할을 맡을 회사가 필요하다고 봄 |
| 한 일 | 2019년 온톨로지 모델 개발 착수. 미국 IT 선도 기업에서 개발 경험을 쌓은 기타구치(北口) CTO의 기술로 약 3년에 걸쳐 의미 공간을 반자동으로 구축하는 체계 구현. 2022년 Kraken. 제공 시작 |
| 결과 | 많은 대형 제조사가 시험 도입 시작. 일본판 Palantir로 주목받는 회사 중 하나로 소개됨. 도입 기업 이름과 효과 수치는 원문에서 밝히지 않음 |
| 연결 | 반구조화, Dynamic Ontology, Mesodata를 자동화한 배경 |
제조업의 리드타임 단축 수요와 Aras 공동 제안
| 구분 | 내용 |
|---|---|
| 상황 | 중국 기업과의 경쟁에 대한 위기감으로 리드타임 단축 요구가 강함. 개별 작업 자동화만으로는 부족하고 부서 간 데이터 분단과 재작업 같은 긴 프로세스를 다시 봐야 함 |
| 한 일 | AI 중심 체계로 가기 위해 데이터 정비부터 시작하는 흐름. 제조업과 건설업에 집중하고 PLM 벤더 Aras와 공동 제안 진행 |
| 결과 | DX 부서뿐 아니라 공장, 생산기술, 설계 부서에서 문의가 오고 기업 규모와 무관하게 수요가 있다고 밝힘. 정량 성과는 원문에서 밝히지 않음 |
| 연결 | 지식형 데이터 메시(부서별 소유, 공통 의미), 의미 공간의 재현성 |
기술 디테일: 자동 온톨로지를 우리 데이터로 시험하려면
반구조화를 직접 돌리려면 문서를 페이지가 아니라 의미 단위로 끊고 단위마다 원본 좌표를 남겨야 합니다. PDF는 절과 표 단위로, Excel은 시트·행 단위로, 스캔 문서는 OCR 신뢰도와 함께 저장합니다. 요약과 태그는 LLM에 구조화 출력(JSON 스키마 강제)으로 받고 temperature는 0으로 둡니다. 업무 태그는 자유 생성을 막고 미리 정한 통제 어휘(제품군, 공정명, 불량 코드)에서만 고르게 해야 같은 개념이 여러 이름으로 쪼개지지 않습니다. 모델은 처음에 문서 이해력이 높은 상위 모델로 돌려 기준 결과를 만들고 표본 검수를 통과한 뒤 더 가벼운 모델로 바꿔 같은 표본에서 정밀도와 처리 비용을 비교합니다. 관계마다 confidence를 받아 0.7 미만은 그래프에 바로 올리지 않고 도메인 오너의 검수 대기열로 보냅니다.
Mesodata 레코드는 이런 필드로 시작합니다. 원문은 내부 형식을 밝히지 않았으므로 아래는 같은 목적을 위한 가상 예시입니다.
{
"meso_id": "MD-2026-004812",
"domain_owner": "품질보증팀",
"source": {"system": "문서관리", "file": "품질회의록_2026-09.pdf", "page": 3, "version": "r2", "updated_at": "2026-09-14"},
"text_span": "사출 온도 변경 이후 하우징 균열 증가",
"summary": "9월 사출 조건 변경과 균열 불량의 연관성 논의",
"business_tags": ["공정:사출", "불량:균열", "제품:하우징"],
"relations": [
{"subject": "공정변경:사출온도", "predicate": "원인후보", "object": "불량:균열", "evidence": "MD-2026-004812", "confidence": 0.82}
],
"review": {"status": "미검수", "reviewer": null}
}정확도를 재려면 원문의 98%처럼 숫자 하나만 보지 말고 도메인마다 관계 200건을 무작위로 뽑아 도메인 오너가 맞음·틀림을 표시합니다. 관계 유형별(원인후보, 구성부품, 근거문서) 정밀도를 따로 보고 같은 입력을 3회 돌려 태그가 달라지는 비율도 함께 기록합니다. 벤더 제품을 시험할 때도 같은 표본으로 잽니다.
근거 추적을 보장하려면 AI 답변에 쓰인 Mesodata ID를 반드시 함께 출력하게 하고 ID가 없는 문장은 답에서 빼도록 후처리합니다. 재현성은 현업 질문 30개를 하루 간격으로 5회 물어 답과 인용 근거가 같은지 비교합니다.
자주 틀리는 경우와 대응.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 스폰서 | 생산본부장 또는 개발본부장 | 리드타임 과제 선정, 8주차 확대 결정 |
| AX 추진 | AX·DX 조직 PM | 범위와 데이터 목록 확정, 일정·판정 관리 |
| 도메인 오너 | 설계·생산기술·품질 팀장 각 1명 | 업무 태그 어휘 확정, 관계 표본 검수, 정의 충돌 결정 |
| 데이터 엔지니어 | IT 또는 벤더 | 원천 연결, 자동 구조화, 근거 출력 설정 |
| 현업 사용자 | 각 부서 실무자 5~10명 | 실제 질문 작성, 답과 근거 확인 |
시작 전 준비물. 부서를 가로지르는 리드타임 과제 하나(예: 설계 변경이 생산에 반영되기까지), 그 과제에 걸린 데이터 목록(설계 BOM, 변경 이력, 불량 보고서, 작업표준서, 관리 대장 Excel), 부서별 업무 용어 초안, 현업이 실제로 묻는 질문 30개입니다.
현업에 물을 것.
- 이 과제의 답을 찾으려면 지금 어느 부서의 어떤 파일을 열어야 하나요?
- 같은 대상을 부서마다 다르게 부르는 이름은 무엇인가요?
- AI 답의 근거로 받아들일 수 없는 자료(옛 버전, 비공식 메모)는 무엇인가요?
- 답이 틀렸을 때 가장 큰 손해가 나는 질문은 무엇인가요?
진행 판정 기준(예시). 세 조건을 모두 채우면 다음 과제로 넓힙니다. 관계 표본 200건의 정밀도 95% 이상, 답변 문장의 근거 ID 첨부율 100%, 같은 질문 5회 반복 시 답 일치 90% 이상입니다. 부서를 건너는 질문 하나에 답을 얻는 시간이 지금의 절반 이하로 줄었는지도 함께 봅니다.
AX 적용 제언. 국내 제조사라면 전사 온톨로지부터 그리지 말고 설계 변경, 불량 원인 추적, 신제품 이관처럼 부서 사이에서 기다림이 생기는 흐름 하나에서 시작하는 편이 좋습니다. 데이터는 각 부서에 두고 용어 정의와 검수 권한도 소유 부서에 줍니다. 그래야 데이터 메시의 장점이 살아납니다. 자동 온톨로지 제품을 고를 때는 정확도의 정의와 표본, 구조화에 쓰는 모델, 데이터가 어디에 저장되는지(데이터 주권), 사람이 고친 관계가 다음 자동 배치에 반영되는지, 온톨로지를 밖으로 내보낼 수 있는지를 확인합니다. PLM을 쓰는 회사라면 에프티와 Aras의 공동 제안처럼 PLM의 제품 구조를 그래프의 뼈대로 삼는 방법을 검토할 만합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 보도 | MONOist 「製造マネジメント インタビュー」, 三島一孝, 2026.10.21 |
| 회사·인물 | 에프티(エフティー), 대표 가토 히로오(加藤大雄), CTO 기타구치(北口) |
| 제품 | Kraken., 지식형 데이터 메시 플랫폼 |
| 처리 | 반구조화(텍스트 추출 → 문맥 이해·요약 → 업무 태그 → 관계 태그) → Dynamic Ontology(사람·조직·제품·공정·불량·문서 다차원 그래프), Mesodata로 6층 온톨로지에 배치 |
| 구조 | 데이터 메시: 도메인별 소유·관리, 의미 공간은 공통. AI가 답의 근거로 역추적 가능 |
| 효과(회사 설명) | 답의 재현성 향상, 검산 비용 감소, 지식 자산화 |
| 정확도 | 관계·의미 부여 98% 이상, 수개월 전 약 85% (구조화용 AI 모델 진화) |
| 개발 | 약 3년, 반자동 의미 공간 구축 체계 |
| 연혁 | 2007 설립(마케팅 지원), 2019 온톨로지 개발 착수, 2022 Kraken. 제공, 2026 신설분할로 재출발 |
| 시장 | 다수 대형 제조사 시험 도입, 제조업·건설업 우선, Aras와 공동 제안, 2027년부터 대만·태국·인도네시아 등 해외 검토 |
| 구상 | 의미 공간을 AI 에이전트·피지컬 AI 실행과 디지털 트윈 순환으로 연결 |
핵심 개념
- 데이터 정제소(data refinery)
- 흩어진 원자료를 업무에 바로 쓸 수 있는 형태로 가공하는 역할. 가토 대표가 Kraken.의 출발점으로 든 개념입니다.
- 데이터 주권
- 데이터를 어느 나라, 어느 회사의 통제 아래 두는지의 문제. 에프티가 국산 기반을 만든 이유로 들었습니다.
- PLM
- Product Lifecycle Management. 설계부터 단종까지 제품 정보와 변경 이력을 관리하는 시스템입니다.
- 통제 어휘
- 태그로 쓸 수 있는 단어를 미리 정해 둔 목록. 같은 개념이 여러 이름으로 쪼개지는 것을 막습니다.
- 신설분할
- 회사의 일부 사업을 떼어 새 회사로 세우는 분할 방식. 에프티는 2026년 이 방식으로 체제를 바꿨습니다.
내 메모
TODO: 내 생각 추가
원문은 MONOist의 「「AIが使えない」のは背景が分からないから、意味付けを自動化する国産基盤の真価」(三島一孝, 2026.10.21, 2쪽)입니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 정확도 수치와 효과는 에프티의 설명입니다. 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 원문 전체와 Kraken. 구성도는 MONOist 기사에서 볼 수 있습니다.