운영 모델
ONESHIM의 공개 문서는 확정 성과보다 검증 순서를 먼저 설명합니다. PoC는 실제 고객 데이터를 바로 연결하는 절차가 아니라, 합성 조직과 승인된 범위의 소스로 기준선을 잡는 절차입니다.
PoC의 목적은 "AI가 알아서 처리한다"를 증명하는 것이 아니라, 보고 재가공, 부서 간 조율, 반복 검색/승인 같은 병목을 어떤 기준선으로 측정할지 정하고, 승인 가능한 후보가 실제로 만들어지는지 확인하는 것입니다.
단계
| 단계 | 목적 | 산출물 |
|---|---|---|
| 1. 범위 합의 | 어떤 업무 흐름을 볼지 결정 | 소스 목록, 제외 규칙, 성공 지표 |
| 2. 합성 시뮬레이션 | FuturePac 기준으로 흐름을 먼저 재현 | 이벤트 샘플, 용어 후보, 검토 큐 |
| 3. Maekon 소스 감사 | 독립 local-first 실행과 선택 연결 범위 확인 | 파일/저장소/도구 권한 표 |
| 4. 온톨로지 시드 | 조직 용어와 관계 후보 생성 | 엔티티, 관계, 근거 링크 |
| 5. 검토 큐 운영 | 사람이 후보를 확인하고 승인 | 승인/반려 기록, 감사 로그 |
| 6. 측정 보정 | 세 가지 기준선과 개선 가설 비교 | PoC 리포트 |
PoC에서 먼저 정해야 하는 것
- 사용 중이거나 검토 중인 LLM 범위
- LLM 활용률 기준선과 실제 업무 적용률
- 반복 설명 비용: 용어, 승인, 히스토리를 다시 설명하는 시간
- 업무 맥락 적용 범위: 승인 소스, 근거 링크, 검토 큐 경계
- 연결 가능한 데이터 소스와 제외해야 할 소스
- 개인정보, 영업비밀, 고객 정보 처리 경계
- 승인자가 누구인지와 승인 없이 반영하면 안 되는 항목
도입 퍼널
ONESHIM은 Maekon의 독립 local-first 검토에서 시작해, 조직 요구가 생길 때 별도 PoC로 확장되는 흐름을 전제로 합니다. Maekon은 ONESHIM 없이도 사용할 수 있는 Apache-2.0 제품이며 로컬 후보와 정책 기반 자동화 경로를 제공합니다. 엔터프라이즈 가치는 ONESHIM 서버, 조직 콘솔, 권한/감사, 조직 온톨로지, 통제 실행 운영에서 검증합니다.
| 단계 | 사용자 행동 | 검증 질문 |
|---|---|---|
| 발견 | GitHub, 문서, 랜딩, 플랫폼 투어 확인 | 로컬 실행과 공개 소스를 검토할 수 있는가? |
| 개인/팀 검토 | Maekon 소스와 독립 실행 경계 확인 | 어떤 데이터를 후보로 만들 수 있는가? |
| 조직 PoC | 서버와 Organization Console을 제한 범위에 연결 | 권한, 감사, 검토 큐가 운영 요구에 맞는가? |
| 운영 전환 | 배포 모델과 커넥터 범위 결정 | SaaS, On-prem, 내부망 요구를 어떻게 맞출 것인가? |
지표 표현 방식
문서와 랜딩에서는 성과를 확정 수치로 말하지 않습니다.
| 측정 영역 | 질문 | 예시 지표 |
|---|---|---|
| LLM 활용률 기준선 | 현재/예정 LLM 워크플로우가 실제 업무 흐름에서 어디까지 쓰이는가? | 사용률, 반복 질문, 업무 적용률 |
| 반복 설명 비용 | 용어, 승인, 히스토리를 다시 설명하는 비용이 얼마나 큰가? | 소요 시간, 재질문 횟수, 재작업률 |
| 업무 맥락 적용 범위 | 승인된 소스와 근거 링크를 어느 업무 흐름까지 연결할 수 있는가? | 후보 수, 검토율, 승인율 |
| 피해야 할 표현 | 권장 표현 |
|---|---|
| 업무 시간이 절반으로 줄어듭니다 | PoC에서 반복 보고/검색 기준선을 측정합니다 |
| 검토 없이 처리합니다 | 후보를 생성하고 검토 큐로 보냅니다 |
| 모든 부서를 연결합니다 | 승인된 소스 범위에서 관계 후보를 만듭니다 |
| 보안 인증을 충족합니다 | 감사 로그와 권한 경계를 설계합니다 |
FuturePac 합성 조직
FuturePac은 실제 고객사가 아니라 제품 범위 설명을 위한 가상 제조 조직입니다.
- 7개 부서와 역할 기반 페르소나
- 30일 활동 이벤트 샘플
- 제조, 품질, 구매, 영업, 재무 흐름
- 온톨로지 시드와 검토 큐 시나리오