AI가 비즈니스를 학습하는 곳
평이한 언어의 업무 정의. 스키마 없는 플레이북. 도구 교체에서도 살아남는 관행.
UKB는 에이전트의 전전두엽입니다. 조직이 '활성 고객'을 어떻게 정의하는지, 갱신 점검은 어떻게 진행해야 하는지, 환불은 누가 승인해야 하는지, 그리고 일반 에이전트를 우리 것으로 만드는 비공식 관행을 모두 담습니다. 항상 평이한 언어로 유지되어 사람이 충돌에서 이기고, 인프라 교체에도 지식이 살아남습니다.
UKB에 무엇이 살고 있는가
지식은 스키마 없이 유지되어 공급자 교체, 컬럼 이름 변경, 마이그레이션을 견딥니다.
프롬프트 지시가 지식 베이스가 될 수 없는 이유
'시스템 프롬프트에 넣어라'가 단일 유스케이스를 넘어서면 작동하지 않는 세 가지 이유.
맞춤 지시는 매 턴마다 작동하거나 전혀 작동하지 않습니다. 실제 비즈니스 지식은 특정 개체·역할·순간에 적용됩니다.
'Notion 검색'은 시한 폭탄입니다. 문서 저장소를 바꾸면 조직의 모든 시스템 프롬프트가 한꺼번에 깨집니다.
자동 메모리는 사실을 축적하지만 충돌 해결 구조가 없습니다. 가장 중요한 규칙이 압축 과정에서 흐려집니다.
UKB가 하는 일
비즈니스 지식을 일급 시민으로 만드는 네 가지 속성.
평이한 언어의 업무 정의
'활성 고객', 'Q3 ARR', '지원 에스컬레이션'을 평이한 언어로 정의합니다. 에이전트는 계획 단계에서 이를 읽어 모든 단계에 반영합니다.
도메인 태그 기반 스키마 없는 플레이북
플레이북은 '[문서_저장소] 검색', '[팀_채팅]에 게시'처럼 읽힙니다. 공급자를 바꿔도 플레이북은 계속 작동하며, 바인딩은 SKB에 연결된 계정 기준으로 일어납니다.
충돌 우선순위 — 사람이 항상 우선
관리자가 작성한 지식이 발견·사용 학습 사실과 충돌하면, UKB는 결정적 우선순위(사람 > 관리자 발견 > 사용)를 적용합니다. 조용한 덮어쓰기는 없습니다.
압축 후에도 구조적으로 생존
UKB 항목은 비정형 메모리가 아닌 구조화된 레코드입니다. 오케스트레이터가 계획 시점에 가져오므로 요약에서 잃지 않습니다.
세 가지 출처, 하나의 진실
UKB가 혼란 없이 성장하는 방법.
관리자가 표준 정의 작성
팀이 업무 정의·플레이북·관행을 평이한 언어로 작성합니다. 다른 모든 출처보다 우선합니다.
발견은 새 지식을 제안
에이전트가 해석할 수 없는 반복 패턴을 만나면 UKB 후보를 작성하여 관리자 검토 대기열에 올립니다. 승인 없는 신뢰는 없습니다.
사용이 거친 부분을 다듬음
반복되는 사용자 수정과 확인된 패턴은 낮은 우선순위의 UKB 업데이트로 환류됩니다. 항상 관리자 작성 지식보다 아래입니다.
출처가 충돌하면 사람이 항상 이깁니다.
지식 베이스 정직한 비교
UKB가 제공하는 것과 대안 비교.
| 기능 | Interactor UKB | ChatGPT / Cowork | 자체 구축 |
|---|---|---|---|
| 정의 기반 조직 이해 | 예 — 3계층 프로필 | 프로젝트 컨텍스트만 | 예 — 3개월 이상 |
| 도메인 태그 플레이북 | 예 — 포터블 | 프롬프트 하드코딩 | 예 — 4개월 이상 |
| 인프라 변경에서 생존 | 예 — 스키마 없음 | 이름 변경 시 깨짐 | 6개월 이상 신중 |
| 시간이 지나며 학습, 충돌은 사람이 결정 | 예 — 우선순위 | 구조화된 학습 없음 | 6개월 이상 |
| 실작동 KB까지 시간 | 수일 | 해당 없음 | 6–9개월 |
정의 하나만 가져오세요. UKB 초안을 가지고 돌아갑니다.
AI가 이해해주길 바라는 업무 용어 하나를 선택해 주세요. UKB 항목으로 구조화하고 플랜이 어떻게 바뀌는지 보여드립니다.
