기능 연결 구조
핵심 플로우
ONESHIM의 9가지 기능은 각각 따로 노는 것이 아닙니다. 하나의 연결된 시스템으로 작동하며, 한 기능이 만든 결과가 다른 기능의 입력이 됩니다. 이 연결이 ONESHIM의 진짜 가치입니다.
단계별 상세 설명
Layer 1: 데이터 수집
| 소스 | 수집 데이터 | 목적 |
|---|---|---|
| 업무 행동 | 클릭, 선택, 작업 순서 | 암묵적 선호 파악 |
| 문서/이메일 | 텍스트, 용어, 표현 방식 | 언어/맥락 파악 |
| 시스템 로그 | 실행 기록, 오류, 성능 | 패턴 분석 |
중요: "누가 뭘 했는지"가 아닌 "이런 상황에서 보통 이렇게 한다"만 수집합니다.
"김철수가 10시에 A를 클릭" ❌ ← 이건 감시
"이 상황에서 A 선택 빈도 80%" ✅ ← 이건 지식
Layer 2: 암묵지 추출
개인 vs 팀 암묵지:
| 구분 | 개인 암묵지 | 팀 암묵지 |
|---|---|---|
| 범위 | 한 사람의 노하우 | 팀 전체의 공유 패턴 |
| 예시 | "나는 이렇게 처리" | "우리 팀은 이렇게 처리" |
| 활용 | 개인 PKM | 부서 표준 |
Layer 3: PKM 구축
PKM에 저장되는 것들:
| 카테고리 | 예시 |
|---|---|
| 용어 선호 | "ROI" vs "투자수익률" vs "가성비" |
| 표현 방식 | 수치 중심 vs 서술 중심 |
| 상세 수준 | 요약 선호 vs 상세 선호 |
| 맥락 정보 | "이 용어는 우리 부서에서 X를 의미" |
Layer 4: 온톨로지 연결
온톨로지가 하는 일:
| 기능 | 설명 |
|---|---|
| 용어 구조화 | 각 부서의 용어를 체계적으로 정리 |
| 관계 매핑 | "재무팀의 ROI = 마케팅팀의 ROAS와 유사" |
| 충돌 감지 | "두 부서가 같은 용어를 다르게 사용" 경고 |
| 공통 레이어 | 부서 독립적인 개념 정의 |
Layer 5: 자동 번역/해석
번역의 3가지 유형:
| 유형 | 설명 | 예시 |
|---|---|---|
| 용어 번역 | A 용어 → B 용어 | ROI → ROAS |
| 맥락 번역 | A 관점 → B 관점 | 비용 관점 → 성과 관점 |
| 상세도 조정 | 상세 → 요약 (또는 반대) | 10페이지 → 3줄 요약 |
Layer 6: 실행 & 피드백
기능별 연결 맵
| 연결 | 설명 |
|---|---|
| 6→9 | 개인 암묵지가 팀 수준으로 확장 |
| 9→2 | 팀 언어/맥락이 온톨로지로 구조화 |
| 2→3,4 | 온톨로지 기반으로 번역/분석 |
| 3,4→5 | 해석 결과를 예측적으로 제공 |
| 5→7 | 제공된 정보로 자동 실행 |
| 7→1 | 실행 결과로 워크플로우 개선 |
| 8→1 | 프로세스 발견으로 개선 가속 |
| 1→6 | 개선된 프로세스에서 새 암묵지 추출 |
핵심 포인트
개별 기능이 아닌, 연결된 시스템이 핵심입니다
- 암묵지 추출 "만" 하면? → 기록은 쌓이지만 아무도 찾지 않습니다
- 온톨로지 "만" 만들면? → 그럴듯한 구조만 있고 알맹이가 없습니다
- 번역 "만" 하면? → 맥락 없는 기계적 번역, 오히려 혼란만 가중
9가지 기능이 연결되어 돌아갈 때, 비로소 "이거 없이는 업무가 안 돼"라는 가치가 만들어집니다.