표준 초안 작성 단계의 진입장벽 — 분석 및 처방 후보¶
분류: 사업 방법론 — 운영 분석 (연구진 토론용 1차 정리) 작성: 2026-05-10 상태: 합의 전 초안. 본 문서의 결정에 따라 표준화 지침 개정안(B-10) · 매뉴얼 3종(D-2/D-3/D-4) · 표준 라이프사이클 페이지가 갱신된다. 배경: 본 사업 트랙 A 운영체계 검증 중 발견된 핵심 실행 리스크.
1. 문제 정의¶
표준 제·개정 11단계 절차서는 ⑦ 초안 작성 단계에서 JSON-LD 스키마 + SHACL shapes + 예시 데이터셋 + 참조 구현 코드 산출을 가정한다. 그러나 다음 두 사실이 충돌한다:
- 이상적 가정: 표준을 제안·작성하는 사람(TC 편집자)이 위 산출물을 직접 작성한다
- 실제 현실: TC 편집자는 도메인 전문가(연구·공공·농업·제조 등)이며, RDF·JSON-LD·SHACL은 비전공이다
이 진입장벽을 해소하지 않으면 본 사업 종료 후 PG606이 새 표준을 제정·개정할 때마다 동일한 병목이 반복된다.
2. 현재 가정 vs 현실 — 단계별 작성 가능성¶
| 단계 | 산출물 | 이상적 작성자 | TC 편집자가 작성 가능? |
|---|---|---|---|
| ① 과제 제안 | Issue 본문 | TC 편집자 | ✅ |
| ② 접수 | 자동 라벨링 | 시스템 | ✅ |
| ③ IPR 확인 | Issue 체크박스 | TC 편집자 | ✅ |
| ④ 타당성 검토 | PG606 사무국 평가 | 사무국 | ✅ |
| ⑤ 채택 | 라벨 변경 | 사무국 | ✅ |
| ⑥ IPR 재확인 | Issue 갱신 | TC 편집자 | ✅ |
| ⑦ 초안 작성 | JSON-LD 스키마, SHACL shapes, 예시, 참조 코드 | TC 편집자 | ❌ — 본 갭 해당 단계 |
| ⑧ 의견 수렴 | PR 댓글 검토 | 검토자·외부 전문가 | ✅ |
| ⑨ 의견 검토 | PR Review | CODEOWNERS | ✅ |
| ⑩ 심의 | CI 통과 + 위원회 | 시스템·위원회 | ✅ |
| ⑪ 공고 | Merge + Tag | 시스템 | ✅ |
⑦ 단계의 산출물 4종을 동시에 작성할 수 있는 인재는 시맨틱 웹·도메인 전문성·Python을 모두 갖춰야 한다. 한국 내에서 수십 명 단위로 추정된다 (정량 추정은 별도 조사 필요).
3. 영향 범위¶
| 시기 | 영향 |
|---|---|
| 본 사업 기간 (2026.05~12) | 5종 시범 표준은 본 사업 기술팀(@tta-tech-lead 김장원 교수)이 실질 작성 가능 — 해결됨 |
| 본 사업 종료 직후 (2027~) | PG606이 새 표준 또는 기존 표준 개정을 시도할 때 ⑦ 단계 작성자 부재 → 운영 정체 |
| 장기 (PG606 운영 모델 정착) | 진입장벽이 ⑦ 단계에 고정되어 있는 한 PG606의 표준 생산 능력은 본 사업 기술팀의 가용성에 종속 |
→ 본 사업의 가장 중요한 산출물은 5종 시범 표준 자체가 아니라, 그 5종을 만든 절차·도구·교재가 PG606이 자체적으로 새 표준을 만들 수 있게 하는가 이다.
4. 처방 후보 — 5가지 옵션¶
| 옵션 | 작동 방식 | 구현 비용 | 스케일 | 적용 시점 |
|---|---|---|---|---|
| (가) 역할 분리 | TC 편집자 = 도메인 컨텐츠 (Word/HWP). 본 사업 기술팀 또는 인증 컨버터 = AI Ready 패키징 | 0 (절차 명문화만) | 낮음 (병목 잔존) | 즉시 |
| (나) 스프레드시트 템플릿 + 변환 도구 | 정해진 Excel/CSV 양식에 요소 정의 → 스크립트가 JSON-LD/SHACL 자동 생성 | 중 (Python 스크립트 1개) | 중 (표 형식 표준에 한정) | 단기 (1~2개월) |
| (다) Markdown DSL + 빌드 도구 | 가벼운 markdown 양식에 요소 정의 → 도구가 RDF로 변환 | 중 (DSL 설계 + 변환 도구) | 중 | 단기~중기 |
| (라) 웹 폼 마법사 | 사이트 안에 인터랙티브 폼 → 입력 후 JSON-LD 다운로드 | 높 (frontend + backend) | 중 | 중기 |
| (마) AI 도우미 (LLM 기반) | 자연어 또는 Word 업로드 → LLM이 JSON-LD/SHACL 초안 생성 → 사람 검토 | 매우 높 (또는 외부 API 비용) | 높 | 중장기 (본 사업 후속) |
4.1 옵션별 상세 평가¶
(가) 역할 분리 — 즉시 적용 가능¶
구체 방식: ⑦ 단계를 ⑦-a, ⑦-b, ⑦-c 세 하위 단계로 분리.
- ⑦-a (TC 편집자): 도메인 컨텐츠를 다음 중 하나로 제출
- Word/HWP 본문 + 요소 정의 표
- Markdown 본문
- 정해진 Excel 템플릿
- ⑦-b (사업 기술팀 또는 인증 컨버터): ⑦-a 입력으로부터 JSON-LD/SHACL/예시/코드 산출
- ⑦-c (TC 편집자 + 기술팀 공동): ⑦-b 결과를 의미 보존 관점에서 TC 편집자가 검토·승인
장점: 비용 0. 즉시 적용. TC 편집자의 부담을 도메인 컨텐츠로 한정하므로 진입장벽 해소. 단점: ⑦-b 작업이 본 사업 기술팀(또는 후속 조직)에 집중 → 병목 잔존. 표준 생산 속도가 기술팀의 가용성에 종속. 비고: 이건 사실상 본 사업이 5종 시범 표준에 대해 이미 하고 있는 방식. 본 옵션은 이걸 명문화하자는 것.
(나) 스프레드시트 템플릿 + 변환 도구¶
구체 방식: 정해진 Excel/CSV 양식 (예: element_id, name_en, name_ko, definition, m_r_o, datatype, parent, controlled_vocab, external_mapping, prov_relevant, dqv_relevant) 을 TC 편집자가 작성. tools/csv-to-aird.py 스크립트가 자동으로 JSON-LD context, SHACL shape, 예시 stub 생성.
장점: - TC 편집자는 익숙한 Excel만 작성 (기존 TTA 작업 방식과 동일) - 본 사업 기술팀의 ⑦-b 부담 대폭 경감 (도구가 자동화) - 기존 표준 다수가 이미 표 형식 (TTAK.KO-10.0976 = 93 요소 표) → 자연스럽게 호환 - 버전관리 친화 (CSV는 git diff 가능)
단점: - 모든 메타데이터가 표로 표현 가능한 것은 아님 (계층·조건부 활성·복잡 SHACL 제약 등) - 변환 도구 자체의 유지보수 부담 (외부 어휘 갱신·새 패턴 추가 시) - 첫 변환 결과는 sub-optimal일 가능성 (수동 보정 필요)
비고: 본 사업 C-2 산출물(검증 도구)에 자연스럽게 묶일 수 있음.
(다) Markdown DSL + 빌드 도구¶
구체 방식: 가벼운 markdown 헤더 양식. 예:
## D2 식별자 (Identifier)
- mro: M
- datatype: xsd:string
- definition_ko: 데이터셋의 고유 식별자
- external_mapping: dcterms:identifier
- shape: minCount=1
빌드 시 변환 도구가 markdown → JSON-LD/SHACL.
장점: human-readable, version control 친화, mkdocs 와 자연 호환. 단점: TC 편집자가 markdown 자체를 학습해야 함 (Excel보다 진입장벽 높음). DSL 설계 자체에 시간 소요.
(라) 웹 폼 마법사¶
구체 방식: 사이트 내 단계별 폼. "표준명" → "요소 추가" → "각 요소 정의" → "검증 규칙" → "JSON-LD 다운로드" 흐름.
장점: 가장 낮은 진입장벽. 가이드된 입력으로 오류 최소화. 단점: 구현 비용 매우 큼 (frontend·backend·DB·인증). 표현력 제한 (단순 케이스 위주).
(마) AI 도우미 (LLM 기반)¶
구체 방식: TC 편집자가 자연어로 표준 설명 또는 Word/HWP 업로드 → LLM이 JSON-LD/SHACL 초안 생성 → 사람이 검토·보정.
장점: - 가장 강력한 표현력 - TC 편집자 입력 형식 자유도 최대 - "AI Ready 표준" 이라는 본 사업 비전과 정합 (표준 자체를 AI가 만든다)
단점: - 구현/운영 비용 매우 큼 (LLM API 또는 자체 모델, 검증 인프라) - 환각·오류 가능성 → 모든 출력 사람 검토 필수 - 본 사업 기간 내 구현 어려움
비고: 본 사업 종료 후 후속 사업의 핵심 주제로 적합.
5. 권고 — 단계적 접근¶
1단계 (즉시) — (가) 역할 분리 명문화¶
표준화 지침 개정안 및 매뉴얼 3종에 다음을 명시:
- ⑦ 초안 작성을 ⑦-a/⑦-b/⑦-c 로 분리
- TC 편집자의 책임은 도메인 컨텐츠로 한정
- 사업 기술팀(또는 후속 조직)의 ⑦-b 책임 명시
- ⑦-c 검토 절차 (의미 보존 확인) 표준화
2단계 (1~2개월 내) — (나) 스프레드시트 템플릿 + 변환 도구¶
본 사업 C-2 산출물에 추가:
- tools/csv-to-aird.py 변환 스크립트
- templates/standard-elements.xlsx 표준 요소 정의 템플릿
- 변환 도구 사용법 매뉴얼
5종 시범 표준 중 1종으로 시범 적용 (P-01 연구데이터 = 93 요소 표 형식 → 변환 도구 검증 사례).
3단계 (본 사업 종료 후) — (마) AI 도우미¶
본 사업의 후속 사업 또는 별도 PG606 도구 개발 사업으로 추진: - LLM 기반 자연어 → JSON-LD 변환 도우미 - 검증·보정 워크플로우 - AI Ready 표준이 정말로 "AI가 만드는 표준" 되는 단계
6. 영향·비용 추정¶
| 옵션 | 본 사업 비용 영향 | 인력 영향 | 후속 운영 |
|---|---|---|---|
| (가) | 0 (절차서 텍스트 추가만) | 사업 기술팀 부담 명시화 | ⑦-b 담당 조직 필요 |
| (나) | 중 (Python 개발 1~2 MM) | 본 사업 기술팀 (김장원 교수) | 도구 유지관리자 필요 |
| (다) | 중 (DSL 설계 + 변환 도구 2~3 MM) | 본 사업 기술팀 | 도구 + DSL 진화 관리 |
| (라) | 큼 (웹 개발 + 호스팅 4~6 MM) | 별도 외부 개발 위탁 가능성 | 호스팅·인증 비용 |
| (마) | 매우 큼 (LLM 인프라 + 데이터셋) | 본 사업 범위 초과 | 후속 사업 + LLM API 비용 |
7. 연구진이 결정해야 할 것¶
다음 7가지를 본 문서를 토대로 토론·결정합니다.
7.1 1단계 (가) 역할 분리¶
- [ ] Q1: ⑦-a/⑦-b/⑦-c 세 하위 단계 분리에 동의하는가?
- [ ] Q2: ⑦-b 책임 조직이 본 사업 종료 후 누가 되는가? (PG606 사무국? 별도 도구 개발팀? 외부 위탁?)
7.2 2단계 (나) 변환 도구¶
- [ ] Q3: 본 사업 C-2 산출물에 (나) 변환 도구를 포함할 수 있는가? (수행계획서 범위 검토)
- [ ] Q4: 우선 적용할 시범 표준은? (P-01 추천 — 표 형식 + 가장 성숙)
- [ ] Q5: Excel 템플릿 컬럼 셋의 1차 안을 누가 설계하는가?
7.3 3단계 (마) AI 도우미¶
- [ ] Q6: 본 사업 종료 보고서 (D-9 운영 이관 패키지) 에 (마) AI 도우미 도입을 후속 사업 권고로 명시할 것인가?
- [ ] Q7: 본 사업 진행 중 (마)의 가능성을 사전 검증하는 작은 PoC를 시도할 가치가 있는가? (예: 2개월 0.5 MM 분량)
8. 결정 후 다음 PR 후보¶
본 토론으로 합의된 내용을 다음 PR로 반영:
| PR 후보 | 변경 대상 |
|---|---|
| (β) 매뉴얼 3종 + 라이프사이클 페이지 갱신 | (가) 역할 분리 명문화 |
(γ) tools/csv-to-aird.py + Excel 템플릿 |
(나) 변환 도구 1차 구현 |
| (δ) 표준화 지침 개정안 §X 신설 | (가)+(나)+(마)에 대한 운영 세칙 조항 |
부록: 본 분석의 출처¶
- 본 분석은 트랙 A 운영체계 검증 중 발견된 갭으로, 워크플로우 기록의 [갭 K] (예정) 에 해당
- 본 사업 PR-001 ~ PR-006 시연 중 수집된 운영 경험에 기반
- 직접 출처: 사용자(PM) 의 2026-05-10 토론 ("표준을 제안하는 사람이 JSON-LD 파일을 만들 수 없을 것 같은데. 어떻게 해야 할까?")