1. Graph Mode란 무엇인가?
개념XBRL → Graph검증 + AI + 규제
Graph Mode는 각 기업이 제출한 XBRL 재무보고서(Instance 문서)를 노드(Node)와 엣지(Edge)로 구성된 그래프 데이터 모델로 재구조화하는 MirrorMere의 내부 표현 방식입니다. XML 구조로 흩어져 있는 팩트, 컨텍스트, 단위, 디멘션, 규칙 등을 "연결된 지식 그래프(Knowledge Graph)" 형태로 변환하여, 검증엔진·에이전트·규제기관이 직관적으로 활용할 수 있게 만듭니다.
1.1 기존 XML 기반 처리의 한계
- Fact, Context, Unit, Dimension이 서로 분리된 리스트로 존재
- 복잡한 Formula/Calculation 검증 시 매번 전체 탐색 필요
- "이 값은 어디서 왔는가?"에 대한 계산 경로(라인리지) 추적이 어려움
- LLM/에이전트 입장에서 직접 이해하기 어려운 구조
1.2 Graph Mode의 핵심 아이디어
- XBRL 보고서의 모든 구성요소를 노드로 모델링
- 요소 간 관계(계산, 포함, 컨텍스트, 디멘션 등)를 엣지로 표현
- 그래프 DB 또는 RDF/Triple Store 형태로 저장 (예: Neo4j, Jena 등)
- 검증/라인리지/설명/AI 활용을 위한 표준화된 질의·탐색 제공
2. XBRL → Graph Mode 변환 구조
2.1 예시 시나리오 (기업 재무제표)
한 기업이 다음과 같은 재무 정보를 XBRL로 제출한다고 가정합니다.
| 개념(Concept) | 값(Value) | Context | Unit | 기타 |
|---|---|---|---|---|
| ifrs-full:Assets | 300,000,000 | ctx_2024_01 | KRW | - |
| ifrs-full:AssetsCurrent | 200,000,000 | ctx_2024_01 | KRW | Parent = Assets |
| ifrs-full:AssetsNoncurrent | 100,000,000 | ctx_2024_01 | KRW | Parent = Assets |
XML 구조에서는 위 데이터가 서로 다른 위치에 흩어져 있지만, Graph Mode에서는 아래와 같이 연결된 노드/엣지로 표현됩니다.
※ 위 그림은 개념을 설명하기 위한 간단한 구조 예시입니다. 실제 Graph Mode에서는 수천~수만 개 Fact와 복잡한 Dimension/Formula/Calculation 관계가 동시에 표현됩니다.
2.2 Graph Mode에서의 대표 노드/엣지 유형
| 분류 | 노드/엣지 타입 | 설명 |
|---|---|---|
| 노드(Node) | Fact 노드 | 개별 수치값/텍스트 값 (예: ifrs-full:Assets = 300,000,000) |
| Concept 노드 | Taxonomy 상의 개념 정의 (label, type, balance 등) | |
| Context 노드 | 기간, 엔티티, 시나리오, 세그먼트 등의 컨텍스트 정보 | |
| Dimension/Member 노드 | 지역, 사업부, 상품군 등 멀티 디멘션 구성 | |
| 엣지(Edge) | hasContext | Fact → Context 연결 |
| hasUnit | Fact → Unit 연결 (KRW, USD, shares 등) | |
| hasParent / calcChildOf | 상위 개념과의 관계 (Calculation/Presentation 구조) | |
| hasDimension / memberOf | Fact에 부착된 Dimension/Member 구조 표현 |
3. 기업별 XBRL 보고서와 Graph Mode의 관계
3.1 "각 기업마다 구조화 해 놓는 것인가?"에 대한 답
네, 맞습니다.
각 기업이 사업보고서/분기보고서/연차보고서 등 XBRL 재무보고서를 제출할 때마다, MirrorMere는 그 보고서를 파싱하여 Graph Mode 형태로 "구조화된 그래프"를 생성·저장합니다.
- 기업 A, 2024년 사업보고서 → Graph A-2024
- 기업 B, 2024년 반기보고서 → Graph B-2024H1
- 기업 A, 2023년 사업보고서 → Graph A-2023
이렇게 기업·기간·보고서 종류 별로 그래프가 쌓여가며, 이는 곧 "재무 보고 지식 그래프 풀(Pool)"이 됩니다.
3.2 금융사/규제기관 입장에서의 활용
| 주체 | Graph Mode 활용 관점 |
|---|---|
| 개별 금융사 (은행, 증권 등) |
|
| 감독·규제기관 |
|
| 회계법인/컨설팅사 |
|
4. Graph Mode의 주요 효과
4.1 검증 측면
- Fact ↔ Context ↔ Dimension 연결이 이미 그래프로 구성되어 있어 Formula/Calculation 검증 속도 극대화
- Required fact, Consistency check, Cross-period 비교 등을 그래프 탐색 쿼리로 구현 가능
- 복잡한 규칙을
"특정 패턴을 갖는 서브그래프 존재 여부"로 표현 가능
4.2 AI/에이전트 측면
- LLM 입장에서는, 그래프 구조가 RAG에 쓰기 훨씬 적합
- "이 값의 근거를 설명해줘" → Graph Mode에서 계산 경로(Path)를 그대로 읽어 설명
- "이 회사의 유동성 리스크가 높은 이유?" → 관련 Fact/Ratio/트렌드 노드를 탐색하여 근거 기반 답변 생성
4.3 규제/감사 측면
- "왜 이 검증 에러가 났는가?"에 대한 설명 가능한 근거 제공
- 규제 변경 시, 기존 그래프 구조 위에 새로운 규칙 레이어만 추가하면 됨
- 시장 전체 수준에서의 패턴 분석, 이상치 탐지, 시계열 트렌드 분석에 활용 가능
5. Graph Mode와 PAG의 연계 (요약)
Bridge Layer
Graph Mode는 "데이터를 어떻게 표현·연결할 것인가"에 대한 답이고,
PAG(Pattern-Augmented Guidance)는 "그래프/검증 결과를 어떻게 LLM이 쓰기 좋은 JSON 패턴으로 변환할 것인가"에 대한 답입니다.
5.1 흐름 요약
- 기업이 XBRL 재무보고서를 제출
- MirrorMere Core가 XBRL 검증 및 Graph Mode로 변환
- Graph Mode 위에서 각종 검증·분석 수행
- 검증 결과/라인리지 정보를 PAG가 Pattern JSON으로 정규화
- LLM/에이전트가 Pattern JSON을 입력받아 설명·가이드·리포트 생성
# 아주 단순화한 개념 흐름 예시 (의사코드/JSON)
{
"factId": "Fact_Assets_2024",
"errorType": "CalculationMismatch",
"expected": 300000000,
"actual": 310000000,
"graphPath": [
"Fact_AssetsCurrent_2024",
"Fact_AssetsNoncurrent_2024",
"Fact_Assets_2024"
],
"explanationPatternId": "CALC_SUM_MISMATCH_001"
}Graph Mode가 "데이터/관계 그래프", PAG가 "패턴 기반 설명 JSON", LLM이 "자연어/에이전트 레이어"라고 보면, 전체 스택이 깔끔하게 분리되면서도 서로 강하게 연결된 구조가 됩니다.
6. 핵심 정리
- Graph Mode는 각 기업의 XBRL 재무보고서를 그래프 데이터 모델로 변환하는 기능이다.
- Fact, Context, Unit, Dimension, Concept, Calculation, Formula 관계를 모두 노드/엣지로 표현한다.
- 기업마다 제출할 때마다 Graph Mode로 구조화된 그래프가 쌓이게 된다.
- 이 그래프는 검증 속도, 라인리지 추적, 설명 가능성, AI/RAG 활용 측면에서 기존 XML 기반 접근을 압도한다.
- Graph Mode 위에 PAG를 얹으면, 검증/그래프 결과를 LLM이 바로 사용할 수 있는 패턴 JSON으로 변환할 수 있다.