문서가 곧 도메인 모델이다.
헬스클럽에 가입한다고 상상해보세요.
1990년대, 컴퓨터 이전:
┌──────────────────────────────┐
│ ★ 회원등록카드 ★ │
├──────────────────────────────┤
│ 이름: 홍길동 │
│ 연락처: 010-1234-5678 │
│ 시작일: 1995-03-15 │
│ 기간: 6개월 │
│ 종류: [ ] 일반 [✓] 프리미엄│
│ 담당 트레이너: 김코치 │
├──────────────────────────────┤
│ 서명: ___________ │
└──────────────────────────────┘
이 카드는 관계를 담고 있습니다. "홍길동은 이 클럽의 프리미엄 회원이고, 김코치가 담당한다." 카드를 보면 누구나 즉시 이해합니다.
그리고 IT 전문가가 왔습니다.
[사용자 등록]
아이디: ________
비밀번호: ________
비밀번호 확인: ________
이메일: ________
[등록]
회원이 사용자가 되었습니다. 등록카드가 등록 폼이 되었습니다. 프리미엄 회원, 담당 코치는 어디론가 사라졌습니다. IT 전문가는 "회원"을 User 테이블로, "등록카드"를 CREATE 연산으로, "프리미엄"을 role 컬럼 값으로 환원했습니다.
이것은 어디에서나 일어났습니다:
의사의 처방전 → "약품 주문" 화면
은행의 대출신청서 → "대출 상품 조회" 메뉴
식당의 주문전표 → "장바구니 → 결제"
학교의 성적표 → "학생 정보 시스템 > 성적 조회"
50년간 IT 전문가들은 모든 비즈니스를 Entity와 CRUD로 번역해왔습니다. 그 번역 과정에서 목적, 맥락, 관계, 흐름 — 비즈니스의 본질 — 이 소실되었습니다.
1976년, Entity-Relationship 모델이 등장했습니다. 이후 반세기 동안 현업은 프로그래머의 언어에 적응해야 했습니다. 그것이 첫 번째 물결이었습니다.
지금, 두 번째 물결이 오고 있습니다.
AI 시대가 열리면서 "지식 그래프", "온톨로지", "시맨틱 웹"이 다시 부상합니다. 새로운 플랫폼들이 제안합니다: "먼저 온톨로지를 설계하세요."
이것은 1976년에 "먼저 Entity를 정의하세요"라고 했던 것과 정확히 같은 구조의 실수입니다:
1976년: "먼저 Entity를 정의하세요" → 현업이 이해 못 함 → 개발자가 독단적으로 결정
2020년: "먼저 온톨로지를 설계하세요" → 현업이 이해 못 함 → AI 엔지니어가 독단적으로 결정
추상화의 수준만 한 단계 올라갔을 뿐, 근본적 오류는 동일합니다: 인간에게 인간의 레이어가 아닌 곳에서 일하라고 요구하는 것.
오해를 피하기 위해 미리 적습니다 — 틀린 것은 온톨로지가 아니라 **"먼저"**입니다. 온톨로지를 모두에게 전제 조건으로 요구하는 것. 그 이유는 왜 서식인가에 있습니다.
상향식 온톨로지 방법론이 없다는 말이 아닙니다. 있습니다. 다만 전부 온톨로지 엔지니어를 필수 주체로 전제합니다 — 선행 연구와의 관계.
Formology는 이 문제에 대한 명확한 답을 가지고 있습니다.
┌─────────────────────────────────────────┐
│ 인간의 레이어: 문서 │
│ │
│ 인간은 문서를 쓴다. │
│ 회원등록카드, 검사의뢰서, 처방전. │
│ 수천 년간 해온 일이다. │
│ 여기에 Entity도 Concept도 필요 없다. │
└──────────────────┬──────────────────────┘
│ 시스템이 자동으로 도출
▼
┌─────────────────────────────────────────┐
│ 시스템의 레이어: 데이터 │
│ │
│ 문서의 구조에서 테이블이 도출된다. │
│ 문서의 필드에서 컬럼이 도출된다. │
│ 문서의 참조에서 관계가 도출된다. │
└──────────────────┬──────────────────────┘
│ AI가 백그라운드에서 생성
▼
┌─────────────────────────────────────────┐
│ 지능의 레이어: 온톨로지 │
│ │
│ AI가 스키마와 데이터 패턴을 분석한다. │
│ 이 모든 것에서 온톨로지가 자라난다. │
│ 인간은 이 과정을 볼 필요조차 없다. │
└─────────────────────────────────────────┘
인간은 문서를 쓰라. 시스템은 데이터를 관리하라. AI는 온톨로지를 만들어라.
각자의 레이어에서, 각자가 잘하는 일을.
우리는 온톨로지를 부정하지 않습니다. 도메인 전문가와 온톨로지 전문가가 함께 있는 자리라면 온톨로지부터 시작하십시오. 그게 더 나을 수 있습니다.
문제는 그런 자리가 드물다는 것입니다. 대부분의 프로젝트에서 실제로 벌어지는 일은 온톨로지 설계가 아니라 개발자가 혼자 테이블을 그리는 것입니다.
온톨로지는 클래스, 속성, 액션, 관계, 제약, 공리를 요구합니다. 정당한 요구입니다. 그런데 ERD는 그중 대부분을 감당하지 못합니다. 의뢰·지시·보고·확인이 **전부 INSERT**가 되고, 스냅샷인지 비정규화인지 스키마만으로는 구별되지 않으며, 흐름은 아예 적을 칸이 없습니다.
그 공백은 비어 있지 않습니다. 누군가 사람 손으로 메우고 있습니다 — 온톨로지 설계자가, 없으면 개발자가 주석과 위키와 if문으로.
Formology의 발견은 이것입니다.
그 공백은 이미 채워져 있었다.
클래스는 서식 이름에. 액션은 접미어에. 절차적 관계는 문서 사이의 흐름에. 시간 결합은 기재란과 붙임란의 구분에. 공리는 선행 조건에.
누가 설계한 적 없이, 수백 년 동안 그냥 쓰여 왔습니다.
그래서 Formology는 온톨로지의 대안이 아니라 실천 가능한 방법론입니다. 전문가가 없는 자리에서도 온톨로지에 도달하는 입구입니다.
→ 무엇이 어떻게 뭉개지고 서식의 어디에서 되찾는지: 철학과 원칙 — 온톨로지가 요구하는 것, ERD가 뭉개는 것
우리가 서식에 집중하는 이유는 서식이 온톨로지보다 우월해서가 아닙니다. 온톨로지 전문가가 없는 자리에서도 온톨로지에 도달하는, 실천 가능한 입구이기 때문입니다.
Formology의 주장과 방법을 이해하려면:
| 문서 | 질문 | 내용 |
|---|---|---|
| 철학과 원칙 | 왜? | 문서중심의 철학적 근거, 10대 원칙, 선행 연구, 온톨로지 비판 |
| 방법론 | 무엇? | 서/지/표/록 분류, 문서의 흐름, 구조, 관계 |
| 워크숍 가이드 | 어떻게 진행? | 준비, 9단계 퍼실리테이션, 산출물 |
| 도출 원리 | 무엇으로 옮기나? | 사상 규칙 정본. 기술 중립 |
| 사례 연구 | 실제로 됐나? | 제조 MES — 성과와 실패 |
| 자동 도출 원리 | 기계가 어떻게? | 도출 레이어 설계 원리 |
| 용어 사전 | 용어 | 정본 |
Formology에는 구현체가 없습니다. 기술 스택 추천도, 코드 템플릿도, 스캐폴딩도 이 저장소에 없습니다. 방법론이 답하는 것은 하나입니다 — 서식에서 무엇이 어떻게 도출되는가.
CC BY 4.0. LICENSE 참조.
온톨로지의 문제는 틀렸다는 것이 아니라, 대부분의 경우 과도하다는 것입니다. 문서는 누구나 같게 보는 유일한 실체입니다. 추상화하지 말고, 구체화하라. 말하지 말고, 써라.
Formology — Workflow First, Ontology Follows