미디어펜 온토위키 제안

SCENE 01 · 삼삼삼

상황 셋 · 해법 셋 · 효과 셋

종래의 상황

지식 DB의 사일로화

기사·취재 자산이 서로 연결되지 못한 채 쌓여만 있다

검색·요약에 머문 AI

통째로 넣으면 토큰만 쓰고 대충 훑는다 — 판단까지 가지 못한다

경험이 녹지 못하는 구조

도구는 좋아졌지만, 시니어의 경험·통찰을 담을 그릇이 없다

해법

5개의 온토위키

사일로를 지식그래프로 — 판단을 구조화한다

질문 루프 엔진(소클, SOQLE)

온토위키가 묻고, 기자가 답하며 기사가 완성된다 — AI는 도구일 뿐

경험과 지식이 쌓이는 허브

기사를 만들 때마다 회사의 경험과 지식이 온토위키에 쌓인다

효과 (지향 — 실증으로 확인)

기자의 통찰이 기사가 된다

구조화된 판단 위에서 기자의 판단·분별·통찰이 그대로 기사화된다

높아지는 기사 품질

문단마다 출처와 검증이 붙는다 — 경험 많은 기자일수록 더 좋은 기사

하나의 정본, 멀티 채널

승인된 정본이 신문·미디어펜 TV·영상·SNS·간행물로 확장된다

이 제안은 미디어펜이 AI 기반 언론사(AX)로 앞서가는 기반을 만드는 한 걸음입니다. 그 걸음을 내딛을지의 판단은 미디어펜의 몫입니다. 본 제안서는 하나의 카테고리를 샘플로 작성되었습니다.

SCENE 02 · 용어 먼저

이 보고서의 언어 — 7개 용어

아키텍처 문서이므로 용어는 등장할 때마다 설명을 병기합니다. 여기 7개가 뼈대입니다 (★ = 제안자가 만든 용어).

온토위키 (OnToWiki) ★

정의 — 온톨로지(개념·관계의 체계) + 위키 = 지식그래프(Knowledge Graph) 위키
노드 — 충분히 설명된 지식 단위 (기사·인물·기관·정책·수치)
엣지 — 연관성의 속성 정보까지 구체화된 관계 (어떤 관계인지 · 언제부터인지 · 근거는 무엇인지)
뎁스 — 노드와 엣지에는 깊이(계층)가 있다 — 큰 개념에서 세부 사실까지 층으로 내려간다
기존 지식그래프와의 차이 — 기존은 노드 위주로 "연결되어 있다"까지만 · 온토위키는 관계(엣지) 자체가 핵심 요인
성격 — 검색 때 즉석 생성되는 답(RAG)이 아니라, 발행할수록 깊어지는 축적 자산
제1목적 — 오늘의 페인 포인트·징후 발견 + 기사를 낼지·어떤 방향으로 쓸지 판단할 수 있는 지식의 구조화

SOQLE (소클) ★

정식 명칭 — Socratic OnToWiki Query Loop Engine
정의 — 소크라테스식 문답으로 쿼리(질문)를 만들어내는 루프 엔진
작동 — 온토위키의 빈 곳·충돌에서 질문 생성 → 기자에게 → 답 → 다시 질문
본질 — AI가 기사를 쓰는 것이 아니라 기자의 취재·생각·통찰력이 발현되게 하는 장치
범위 — 토픽 추천부터 검증·파생·환류까지 순서를 지휘 (의미 판단은 항상 사람)

아티클 원장 (Article Ledger)

정의 — 기사 한 건의 성장 대장 = 살아있는 위키(Live Wiki)
탄생 — 토픽 확정 순간, 주제·이유·방향 3노드로 시작
성장 — 문답마다 주장·출처·관계가 쌓임 · 문단별 팩트체크 상태를 색+텍스트로 표시
완성 — 기자가 "충분하다" 판단할 때
구분 — 원장은 방대한 작업본 · 기사 초안은 톤앤매너 필터 이후에야 생긴다

페인 포인트 · 징후

페인 포인트 — 시장·독자가 지금 겪는 아픈 문제 · 오늘 기사가 다뤄야 할 것
징후 — 데이터·발표·동향 속 변화의 조짐
왜 중요한가 — 온토위키 여러 개를 만드는 가장 큰 이유가 이 둘의 발견

SNLM

정식 명칭 — Structured Network Natural Language Memory
정의 — 에이전트들이 지식을 주고받는 구조화 자연어 메모리 규격
쓰임 — 각 온토위키의 전담 에이전트 ↔ SOQLE 소통
※ 목표 통신계약으로 채택 — 스키마 버전·연동 시험은 후속 수용조건

AEO · GEO

정식 명칭 — Answer / Generative Engine Optimization
정의 — 검색 노출(SEO)을 넘어, 답변 엔진·생성형 검색이 문맥·출처를 해석하기 쉽게 만드는 구조 점검
작동 시점 — 원장이 자라는 동안 상시
※ 노출·인용·학습을 보장하지 않음

OSMD (One Source Multi Domain)

정의 — 데스킹 통과 기사 1건(원 소스) → 신문 기사 · 미디어펜 TV · 롱폼/쇼츠 · SNS 문안·카드뉴스 · 도서·간행물(멀티 도메인) 파생
연결 — 모든 파생물이 원 기사와 연결
정정 — 정정이 나면 어디까지 고칠지 역추적

위키 컴파일 (Wiki Compile)

정의 — 원천 자료(기사·보도자료·법령·데이터)를 AI 추론 엔진(LLM)이 읽어 노드·엣지의 위키로 짜 넣는 공정 · 검색이 아니라 컴파일
방식 — 모든 위키 컴파일은 LLM Wiki 방법으로 수행
계보 ① — 안드레 카파시(Andrej Karpathy — OpenAI 공동창업, 전 테슬라 AI 총괄)가 제안한 LLM Wiki 개념을 확장·발전·실천
계보 ② — 카파시의 추상 개념을 비즈니스 용도로 — 레이어 보강 + 절차의 세분화·구체화 → 온토위키
계보 ③ — 해외 온톨로지 기업(팔란티어 등)의 개념 일부 접목

SCENE 03 · 두 개의 축

이 둘이 전부입니다

두 개의 축 개념도 — 축 1 온토위키의 지식 구조화, 축 2 질문 루프 엔진(소클)의 문답, 중앙 접점 아티클 원장 — 이 둘이 전부입니다 — 기사를 만드는 과정이 곧 온토위키를 쌓는 과정입니다.

축 1 · 온토위키 — 지식의 구조화

회사의 정보는 방대하지만 사일로 DB에 갇혀 있다
통째로 AI에 넣으면 — 토큰만 쓰고, 대충 훑고 지나간다
노드·엣지가 분명한 지식그래프 위키라야 정확히 가져오고 팩트체크가 된다

축 2 · 질문 루프 엔진(소클, SOQLE) — 질문으로 만드는 기사

"기사 써줘"가 아니다 — SOQLE이 계속 질문을 만든다
문답 루프를 통해 기자의 취재·생각·통찰력이 발현되는 기사
토픽 선정부터 완성까지 — 멈추는 것도 사람

제1목적 — 발견과 판단의 구조화

발견 ① — 오늘 이 시점의 시사성 있는 페인 포인트
발견 ② — 이 시장의 지금 징후
팔란티어의 존재 이유 = "판단할 수 있는 지식의 구조화"
우리의 목적 = 기사로 낼 것인가 · 어떤 방향으로 쓸 것인가를 판단하는 구조 (언론 규모)

바라보는 곳 — 미디어펜의 AX(AI 전환)

목적 — 미디어펜이 AI 기반 언론사(AX)로서의 기반을 구축하고 선도적으로 발전해 가는 것
이 제안의 위치 — AI 시대의 미래 방향으로 앞서가는 플랫폼을 향해 한 발을 내딛어 보는 것
기사 기준 — 페인 포인트·징후에 대해 "어떻게"가 분명히 나오는 기사 (신뢰 · 기자의 힘 · 영향력)
판단 — 그 걸음을 내딛을지는 미디어펜이 결정합니다

두 축의 접점 — 아티클 원장

문답이 오갈 때마다 — 주장·출처·관계가 노드와 연결로 쌓인다
기사를 만드는 과정 = 온토위키를 쌓는 과정
승인 발행본·정정 계보 → 권리 게이트 → 미디어펜 온토위키 후보로 환류

세계 동향: 해외 AI 사고는 전부 무검수 노출, 성공 사례는 전부 "기자 보조+사람 승인". Fox News는 팔란티어와 1년간 편집국 도구 3종을 만들었습니다(2025.11, "디지털 트윈"). 뉴스 소비는 전 플랫폼으로 파편화 중(소셜 영상 뉴스 65%). 판단은 귀사의 몫이며, 이 보고서의 지면은 구조 설명에 씁니다. 출처는 부록.

SCENE 05 · 덩어리 A — 축1

온토위키 — 왜, 그리고 어떻게 만드는가

이 장은 두 질문에 답합니다 — 왜 언론사의 기존 데이터베이스(사일로 DB)로는 AI 기사 지원이 어려운가, 그리고 온토위키(지식그래프 위키)는 무엇으로 어떻게 만드는가.

왜 사일로 DB로는 안 되는가

지금 — 사일로 DB

정보는 방대하지만 서로 어떻게 연관되는지 모른다
오늘 쓸 기사에 어떻게 참조될지 모른다
RAG로 통째로 넣으면 토큰 폭증 — 그런데도 대충 훑고 지나간다
출처가 문장 단위로 연결되지 않는다

온토위키 — 지식그래프 위키

노드: 충분히 설명된 지식 단위
엣지: 연관성의 속성 정보까지 실린 관계
필요한 문서만 정밀 인출 → 토큰 절약 + 정독
모든 주장이 원문 위치로 연결 → 팩트체크 가능
차이의 핵심 — 기존 지식그래프는 노드 위주("연결됨"까지) · 온토위키는 엣지의 속성이 구체화되고 노드·엣지에 뎁스(계층)가 있다

사일로 DB와 온토위키의 같은 질문 처리 비교 — 같은 질문의 처리 비교 — 자동 진실판정·절감률을 보장하는 그림이 아닙니다

일상 사례로 말하면 — 오늘 취재원을 만나러 갑니다. 과거 그분과의 대화, 뉘앙스, 스타일, 평판이 미리 준비됩니다. 오늘 기사를 씁니다. 과거 우리 회사가 썼던 기사들이 자동으로 참조됩니다.

독립적으로 운영되는 5개의 온토위키 (사례: 부동산)

① 미디어펜 온토위키

기존 기사 DB + 취재 DB를 사일로에서 그래프로. 구축 1순위이자 가장 방대한 작업. 취재원·인물·기관·사건의 이력이 이어진다.

② 뉴스 에이전시 온토위키

연합뉴스 등 공급사 뉴스. 카테고리별 분할(전체 통짜 금지). 아카이브 층 + Live 층(오늘·최근 뉴스 실시간 반영) 이중 구조로 독립 상시 가동. ※ 전재분의 AI 처리 권리는 계약 확인 후 범위 확정.

③ 자체 부동산 지식그래프

기사와 무관한 검증된 전문지식의 층 — 정부 제도·절차 / 시장 지식 / 가치 평가 / 디벨로퍼의 문제 / 토지이음 정보 / 부동산 기본 이론. "뉴스가 지식 기반으로 작성되게 하는 기반". ※ 실증: 같은 구조의 landwiki(랜드위키)·farmwiki(농업위키)를 실제 운영 중 · 부동산 도메인 스키마·검증 자산 보유 — 실제 데이터 승인 릴리스는 후속 수용조건.

④ 공공정보 온토위키

3층 — 보도자료(국토부·기재부·지자체) / 법령(법률·시행령·시행규칙·조례) / 통계(공공데이터포털). 전 층 공공 원천 = 권리 부담 최소.

⑤ 부동산 시장 위키 (신설)

수시 갱신되는 시장·가격 동향 — KB부동산 / 한국부동산원 / 국토부 실거래가 / 중개 동향. 정적인 ③과 분리해 별도 가동.

공통 규격

각 위키에 전담 에이전트 1기 — SOQLE과 SNLM으로 소통
민감 원천은 로컬 LLM으로 — 취재 DB 등은 외부에 보내지 않고 내부 로컬 모델로 위키 컴파일 (취재원 보호의 기술적 답)
공정 — 인입(출처·시점·권리 라벨) → 결정화 → 위키 컴파일(LLM Wiki 방식) → 검증 게이트
계보 — 카파시의 LLM Wiki를 비즈니스용으로 확장 + 온톨로지 기업 개념 접목 (용어 SCENE 02)

5개 온토위키의 독립 경계와 공통 데이터 계약 — 5계열 — 독립 경계를 유지하며 공통 ID·버전·출처 계약으로 연결

SCENE 06 · 덩어리 B — 축2

질문 루프 엔진(소클) — 질문이 기사를 만든다

SOQLE(소클 — Socratic OnToWiki Query Loop Engine)은 단발 명령("써줘·조사해줘·요약해줘")과 근본적으로 다릅니다. AI가 기사를 쓰는 것이 아니라 기자의 취재·생각·통찰력이 발현되게 하는 장치이며, 이것이 이 제안의 해자입니다. 발견은 온토위키가, 기사화는 SOQLE이 — 발견된 페인 포인트·징후는 언제나 이 엔진을 거쳐 기사로 구축·체화됩니다.

장르별로 루프의 목적이 달라집니다 — 기획·분석 기사: 발견된 페인 포인트·징후에 대해 "어떻게(how)"가 분명히 나오도록 문답 심화 / 스트레이트(사실 보도): 팩트체크 + 이 기사가 어떤 영향력을 미칠 것인가의 관점으로 루프가 돕니다.

토픽 추천 — 하루의 시작

기반 — 페인 포인트·징후의 발견 (온토위키가 존재하는 첫 번째 이유)
신호원 — 시장 동향 · 정부 발표 · 사람들의 관심 · 타 매체 동향
추천 — 시의성 높은 토픽 후보 5개 이상
선정 — 기자가 1~3개 (결정은 언제나 기자 · 선정 과정도 상호 문답)

생성 루프 — 기사가 명확해진다

출발 — 토픽의 목적·이유·방향 + 5개 온토위키에 접지한 작업본
루프 — 엔진이 작업본을 보고 질문 → 기자가 답 → 다시 질문 …
수렴 — 루프를 돌수록 기사가 명확해진다
종료 — 끝은 없다 · 기자가 "충분"할 때 멈춘다

검증 루프 — 병행하는 별도 루프

대상 — 법령 · 제도 · 조례 · 숫자 · 발표 주체 · 공신력 (크로스체크)
미진한 부분 → 질문 생성
질문의 두 수신자 — 위키가 답할 수 있으면 위키에게 · 사람만 답할 수 있으면 기자에게

편향 방지 + 오케스트레이션

편향 방지 — 원장의 전체 상태를 참조하며 질문을 배분
오케스트레이션 — 토픽→문답→검증→파생→환류의 순서 지휘
경계 — 의미 판단(사실·편집)은 항상 사람 · 독자 반응은 질문 참고 신호일 뿐

질문 루프와 검증 루프가 원장을 키우는 구조 — 기자 반영 결정 게이트 — SOQLE은 질문을 제안하고, 기자가 답변·반영·종료를 결정 — 별도 검증 루프 병행

SEO를 넘어 AEO·GEO로 — 기사는 SEO 준수를 넘어, 답변 엔진·생성형 검색이 문맥·출처를 해석하기 쉽게 만드는 구조 점검(AEO·GEO)을 원장이 자라는 동안 상시 받습니다. ※ 노출·인용·학습 보장 아님. AI 개방 수위는 미디어펜의 선택 사항입니다 — 다만 AI 시대에는, AI가 기사를 확인하고 검색했을 때 미디어펜의 기사가 상단에 위치하도록 하는 것이 궁극적으로 필요하지 않겠습니까. (결정은 미디어펜 — 갭 G6)

SCENE 07 · 덩어리 C

아티클 원장 — 문답마다 위키로 자라는 살아있는 기사

아티클 원장(Article Ledger)은 기사 한 건이 자라나는 살아있는 위키이며, 축1(온토위키)과 축2(SOQLE)가 만나는 곳입니다. 기자와의 문답 한 번마다 주장·출처·관계가 쌓이고, 원장이 곧 완성된 기사의 위키가 됩니다.

원장의 일생

단계	원장의 상태
탄생	토픽 선정 순간 — 주제·이유·방향 3노드와 엣지로 시작
성장	문답마다 주장·출처·관계가 늘어남 (Live Wiki). 보충은 SOQLE 경유로 5위키에서 인출
정교화	검증 루프가 문단별 상태를 갱신 · 시각화·도식·그래프 생성 포함
완성	기자의 "이 정도면 충분" 판단 = 사람이 멈춤

문단별 팩트체크 — 미확인을 숨기지 않는다

서울 아파트 매매가격지수는 전주 대비 0.02% 상승했다. 확인됨 출처: 한국부동산원 주간동향 (8/14)

전문가들은 하반기 공급 부족 심화를 전망한다. 확인 중 질문 → 기자: 어느 전문가입니까? 반대 견해는?

해당 지역 인허가 물량은 작년의 절반 수준이다. 근거 없음 질문 → 위키: 국토부 인허가 통계 조회

처음부터 전부 확인된 것만 쓸 수는 없습니다 — 상태를 색과 텍스트로 정직하게 표시하고, 점점 확인되며 완성됩니다.

아티클 원장 LiveWiki 개념 UI — 근거·검증 상태·GraphGap·revision 계보 — 원장은 초안이 아닙니다 — 검증 상태가 보이는 LiveWiki

SCENE 08 · 덩어리 D

원장에서 독자에게 — 톤앤매너, 데스킹, 멀티 도메인

이 장은 완성된 아티클 원장이 어떻게 미디어펜의 문체를 입고(톤앤매너), 데스크의 손을 거쳐(데스킹 — 기존 절차 그대로), 신문·영상·SNS로 퍼져 나가는지(원 소스 멀티 도메인)를 다룹니다.

톤앤매너 이후 첫 초안, 재검증, 사람 데스킹, 5채널 개별 승인과 공통 정정 계보 — Tone 이후 처음 초안 → 원장 대조 재검증 → 기존 데스킹 → 5채널 개별 승인 · 정정은 공통 계보로

왜 필터가 필요한가

원장 = 대화로 만들어진 방대한 작업본 — 말투·이전 스타일이 섞여 있다
기자별 · 매체별 · 장르별 톤앤매너로 거른 뒤에야 기사 초안
초안도 원장과 대조해 다시 팩트체크
스타일 지식은 별도 저장소 (전담 에이전트) — 기존 기사로 학습해 제시하고, 기자가 고치면 그 스타일로

배포와 환류

발행 — 데스킹(기존 절차) 통과분만
파생 5도메인 — ① 신문 기사 · ② 미디어펜 TV(제작 지원 후보 — 구축 단계 별도 범위) · ③ 롱폼/쇼츠 영상 · ④ SNS 문안·카드뉴스 · ⑤ 도서·간행물(책자·월간 간행물 발행 가능)
정정 — 파생물까지 역추적
환류 — 승인 발행본·정정 계보가 권리 게이트를 거쳐 온토위키 후보로

하네스 엔지니어링(Harness Engineering) — 가드레일의 다층 설계

데스킹 가드레일 — 데스킹 지침서(과거 사례 기반 또는 신규 제작)에 따라 사람과 AI가 함께 검증 · 데스킹은 HIL(Human in the Loop)의 가장 중요한 지점 — 사람의 개입이 이 일의 성패를 좌우합니다
취재원 가드레일 — 민감 원천은 로컬 LLM 처리 + 식별정보 반입 금지
원칙 — 가드레일은 하나로 충분하지 않다: 이중·삼중, 그 이상 다층으로 세우는 것이 이 공정 설계의 방식

SCENE 10 · 검증 1

정합성 검증 — 전 항목 해소

아래 표의 조건부 항목들은 1차 문답(2026-08-17)으로 모두 문서에 반영되어, 제안서 차원의 정합성 문제는 해소되었습니다. 남는 것은 정합성 문제가 아니라 실행 단계의 수용조건(연동 시험·계약 문구화·법적 검토)입니다.

검증 항목	판정	내용
작업본 생성 vs "문답 작성" 결정(Q1-3)	정합	루프의 출발점은 위키 접지 작업본이며 "기사 초안"은 톤앤매너 이후에만 존재(명칭 통일). 대외 표현은 "기자의 답변으로만 강해지며, 발행은 사람이 결정"으로 고정
원장 위키화 vs 두 축 프레임	정합	원장 = 축1(위키화)과 축2(문답)의 접점. 원장≠초안 구분 일관
색깔 팩트체크 vs 검증 상태 규격	정합	확인됨/확인 중/근거 없음/미확인이 기존 규격(supported·contradicted·unsupported·unknown)과 1:1 대응. 색+텍스트 병기
오케스트레이션 vs 사람 권한	해소	순서·상태의 지휘로 한정 명시 완료 — 사실·편집 승인은 항상 사람 (계약 문구화는 실행 단계)
반응 평가 환류 vs 편집권 독립	해소	건강검진(Lint) 신호층으로 확정(G12) — 다음 토픽·기사화에 반영되되 사실성·편집 판단을 직접 바꾸지 않음
AEO·GEO vs 데이터 권리 원칙	해소	"AI 친화 구조"는 발행 기사(공개물)의 구조 점검이고, "고객 자료 학습 안 함"은 내부 원자료 보호 — 다른 층으로 분리 서술 (노출·인용 보장 아님)
SNLM	문서 해소	목표 통신계약으로 채택 명시 완료 — 스키마 버전·연동 시험은 실행 단계 수용조건으로 이관
토픽 선정 vs 편집권	정합	"추천 ≥5 → 기자 1~3 선정" — 결정권이 기자에게. "타 매체 동향" 신호는 권리 검토 필요(G7)
데스킹 vs 현행 존중	정합	"기존 데스킹 방법·절차 그대로" — 미디어펜 공개 원칙과 일치. 시스템 지원 범위는 미정의(질문 N-3)
자체 지식그래프 "기보유" 표현	해소	스키마·검증 자산 보유는 사실 — 단 실제 데이터 승인 릴리스는 후속 수용조건으로 표기

SCENE 11 · 검증 2

갭 분석과 해소 전략 — 언론사 입장에서

이 장은 위 구조를 언론사(미디어펜)의 자리에서 점검한 결과입니다 — 스스로에게 먼저 엄격한 것이 이 제안의 방식입니다.

해소된 것 (문답으로 확정)

표현 수위 — "AI는 기자의 에이전트: AI가 묻고, 기자가 답한다"
취재원 보호 — 민감 원천은 로컬 LLM 처리 (외부 전송 없음) + 다층 가드레일
기자 수용성 — 원장 리얼타임 확인·기자의 종료 권한으로 통제
데스킹 — 데스킹 지침서 + 사람·AI 공동 검증 (HIL의 핵심)
기자 스타일 — 학습→제시→기자 수정 반영 루프
시각화·반응 환류 — 기사 내 도표는 AI로 · 반응은 건강검진(Lint)으로

앞으로 해소할 점검 과제 (해소 전략 포함)

정보 보호 — 취재원·개인정보의 처리 경계: 로컬 모델 적용 범위·원장 접근 권한·보존 정책을 지침서와 계약 문구로 확정
운영 설계 — 하이브리드 인프라(민감=로컬 / 일반=클라우드)의 세부 구성: 구축 협의에서 확정

상세 점검표

#	갭	무게	언론사 입장의 문제	전략 추천안
G1	표현 수위 — "기사 작성"	높음	미디어펜은 "기사 자동화 거부"를 공개 원칙으로 선언 — 초안 생성이 부각되면 원칙 충돌로 읽힘	"기사는 기자의 답변으로만 자란다" 프레임 고정 · 작업본/초안 명칭 분리 · 초안 조립은 구축 단계 옵션
G2	통신사 전재 권리	높음	전재 계약이 AI 처리·파생까지 허용하는지 미확인	출처 표시 필요 시 표시 · AI 처리·파생 범위는 별도 법적 검토 — 향후 체크 사항으로 등재 (확인 전 "권리 범위 내 조건부" 표기)
G3	취재 DB·취재원 보호	높음	취재원 신원·비보도 정보의 위키화·외부 AI 처리 = 언론 윤리 최상위 금기와 충돌 위험. 원장의 문답 기록도 민감	로컬 LLM 모델로 위키화 — 민감 원천은 외부 AI에 보내지 않고 내부 자체 AI(로컬 모델)로 처리 (외부 전송 자체가 없음) · 취재원 식별정보 반입 금지 하드스톱 · 원장 접근 권한 설계 ※ 로컬 모델은 계속 발전 중 — 일부 하드웨어 비용은 들지만 기술적으로 충분히 가능
G4	기자 수용성 — 질문 피로	중간	끝없는 루프가 마감 압박과 충돌 가능	적응의 문제 — 기자가 원장을 수시로 리얼타임 확인하며 스스로 종료 (충분 판단 권한이 기자에게 있으므로 피로가 통제됨) · 질문 우선순위 규칙 병행
G5	"실시간"의 성숙도	중간	5위키 상시 가동+실시간 검증은 구축 단계 목표 — 첫날부터 약속하면 과약속	"이렇게 가야 한다"는 지향으로 명시 — 5위키 상시 가동·실시간 검증은 이 플랫폼의 핵심 · 도달 경로만 단계화(배치 → 실시간)
G6	AEO·GEO의 전략 긴장	중간	"AI 친화 개방"은 다수 언론사의 AI 크롤러 차단·사용료 협상 흐름과 긴장	중요 전략 — 방향 제시: "AI가 검색했을 때 미디어펜 기사가 상단에 위치하는 것이 궁극적으로 필요하다 — 앞으로 방향은 이렇게 가야 한다" · 목표 설정은 언론사가
G7	타 매체 동향 신호	중간	타사 기사 수집·저장의 저작권 문제	기사 원문을 수집·저장하지 않는다 — 저작권 범위 내에서 얻는 정보만 위키화해 동향으로 다룸 (예: 특정사를 특정하지 않는 키워드 언급량) · 수집 방법 별도 강구
G8	기자 스타일 데이터	중간	기자별 문체 자료 저장·활용의 동의 문제	학습 → 제시 → 수정 루프: 기존 기사로 AI가 기자별 스타일을 학습해 먼저 제시 → 기자가 고치면 고친 스타일에 맞춰 적용
G9	데스킹 지식 미정의	중간	해소됨 — 데스크 고유 권한을 건드리지 않는 방법 · 데스킹 = HIL(Human in the Loop)의 핵심, 이 일의 성패를 좌우	데스킹 지침서 — 과거 데스킹 사례가 있으면 활용, 없으면 이번 기회에 제작. 지침서에 따라 사람과 AI가 함께 검증 (하네스 엔지니어링 — 다층 가드레일)
G10	시각화 vs AI뷰	낮음	AI뷰 기운영 — 중복 제안으로 보일 수 있음	가볍게 취급 — 기사 안 도표화는 AI로 충분히 생성 · AI뷰 흐름은 그대로 (대체 논쟁 사안 아님)
G11	운영 주체·비용	낮음*	5위키 상시 가동의 인력·비용·책임 미정 (*구축 협의에서는 핵심)	하이브리드 운영이 가장 효율적 — 민감 원천은 자체 서버·로컬 모델, 일반 부하는 AWS·구글 등 클라우드 · 세부는 구축 협의
G12	반응 데이터 접근	낮음	환류는 트래픽·독자 데이터 접근 전제	중요 루프로 격상 — 댓글·조회수 등 반응이 다음 토픽·기사화에 반영되는 환류 = 그래프의 건강검진(Lint) · 익명·집계 신호로

해소 전략 — 세 갈래

전략 1 · 말의 경계 (G1·G9·G12)

정면 논리 — AI는 기자의 에이전트: AI의 방대한 지식으로 질문하고, 대답은 기자가 한다 (AI 의존·AI 판단 위임이 아님)
프레임 문장 고정 — "기사는 기자의 답변으로만 자란다"
"발행은 사람이 결정한다" · "반응은 질문 참고 신호일 뿐"
데스킹 지원 = "데스크를 돕는 체크리스트"로 한정
비용 0 · 즉시 실행

전략 2 · 권리 선(先)확인 (G2·G3·G7·G8)

확인 질문 ① — 통신사 전재분의 AI 처리 권리는 계약상 어디까지?
확인 질문 ② — 취재 DB의 취재원·민감정보 정책은?
확인 질문 ③ — 타 매체 모니터링은 어디까지 허용?
하드스톱 2 — 취재원 식별정보 반입 금지 · 스타일 학습은 동의 후 (계약 문구화)

전략 3 · 단계에 배치 (G5·G6·G10·G11)

구축 협의 의제로 — 실시간 가동 · 환류 · TV 지원 · 운영
진단·실증 — 배치 단위로 시작
AEO 개방 수위 — "AI 인용 원천이 될 것인가, 차단할 것인가" 선택지 제시 · 결정은 미디어펜

SCENE 12 · 구축 여정

작게 시작해서, 전체 그림으로

이 장은 방향만 그립니다 — 진단, 작은 실증, 그리고 확인된 것만의 확장. 오늘의 자리는 이 여정을 함께 갈 의지가 있는지 서로 이야기하는 자리이며, 절차·기간·조건의 구체화는 그다음의 일입니다.

1단계 · 준비도 진단

현재 기사 업무를 한 장의 지도로 함께 그려보기
어디에 먼저 적용하면 좋을지 우선순위 이야기

2단계 · 작은 실증

한 분야 · 한 데스크 · 소수 기자
기존 발행 절차 그대로 — 병행 검토 방식
무엇을 확인할지 함께 정하고 시작

3단계 · 구축·확장

전체 그림 실현 — 5개 온토위키 + Socratic OnToWiki Query Loop Engine(SOQLE) + 멀티 도메인 배포
원칙 — 실증에서 확인된 것만 확장

재원 — 한국언론진흥재단(KPF) 지원사업과 연계

구축 비용은 언론재단의 디지털 미디어 서비스 개발 지원사업(언론사 자부담 약 10% · 매년 3월 공모 · 정기간행물 등록 언론사 대상)과 연계해 설계할 수 있습니다
재단이 여러 언론사에 공동 제공하는 공용 AI 인프라의 범용 기능들도, 온토위키 위에서 미디어펜 전용으로 소화할 수 있습니다 — 공용 도구를 쓰는 언론사와 자기 지식그래프를 가진 언론사의 차이
※ 지원사업 선정은 보장이 아니며, 신청 전 자체 실증으로 증거를 만들어 두는 것이 선정에도 유리합니다

왜 직선이 아니라 나선인가 — AI 시대의 개발(바이브 코딩)은 한 루프 사이클이 짧아, 작은 단위를 빠르게 만들어 검증하고 다시 도는 것이 자연스럽습니다. 그래서 이 여정도 폭포수식 일정표가 아니라 나선형(스파이럴) 구조를 따릅니다 — 진단·실증·구축은 한 번씩 밟는 계단이 아니라, 매 회전마다 검증을 통과한 것만 넓혀 가는 나선의 회전들입니다.

내일은 첫 미팅입니다 — 이 자리의 목표는 구축 프로젝트 협의의 시작이며, 비용·기간 등 조건은 이 문서에서 다루지 않습니다. 첫 실증 기간에 구독·트래픽 증가를 약속하지 않습니다 — 품질과 시간이 먼저, 독자 효과는 그다음이 정직한 순서입니다.