10월 15일, 경쟁사가 자기 제품의 약점을 먼저 말했다
[외부 공식자료] Glean 은 10월 15일 블로그에서 Skill reflection 을 공개했다. 새 기능 소개인데 글의 두 번째 문단이 이렇게 시작한다. 스킬의 문제는 그것이 업무 수행 방법의 얼어붙은 스냅샷(a frozen snapshot)이라는 점이다. 전문성이 바뀌고 절차가 바뀌고 데이터가 바뀌면, 아무도 관리하지 않는 사내 문서가 그러하듯 스킬도 낡는다.
자랑이 아니라 고백으로 여는 글이다. 일주일 전 10월 8일 글에서는 같은 회사가 스킬의 생애주기를 세 토막으로 잘라놓았다. 반입 전 스캔, 실행 시점의 자격증명 브로커, 규모를 위한 접근 통제.
두 글을 붙여놓고 보면 그쪽의 관심사가 어디로 옮겨갔는지 보인다. 더 이상 어떻게 쌓을 것인가가 아니다. 쌓인 것을 누가 고치고, 언제 버리고, 고치는 순간 누가 승인하는가다.
우리 정본에는 낡음을 세는 칸이 없다
[제품 정본] brand-context 의 차별점 한 줄은 승인된 실제 업무 수행에서 재사용 가능한 팀 절차를 축적한다이고, Key Metrics 여섯 줄 중 하나가 승인된 스킬 재사용이다. 세는 것은 재사용 횟수다. 그 절차가 틀린 절차가 되는 사건을 세는 칸은 없다.
더 아픈 건 일정이다. [산수] 절차가 낡으려면 시간이 필요하다. 양식이 바뀌거나 담당자가 바뀌거나 단계가 하나 늘어야 낡는다. 그런데 우리가 설계해둔 검증 창은 4주다. 4주 안에서 모든 절차는 새것이다. 우리가 가장 세게 파는 주장의 값도 비용도 측정 창 바깥에 있다.
축적은 자산이면서 부채다
[미검증 가설] 팀 절차 50개가 쌓인 워크스페이스를 상상해 보자. 그중 몇 개가 지금도 맞는 절차인지 아무도 모른다면, 그 50개는 자산이 아니라 매달 조금씩 틀려지는 재고다. 기존 도구를 쓰던 팀이 우리에게 오는 이유가 축적이라면, 우리를 떠나는 이유도 축적이 될 수 있다 — 틀린 절차가 자동으로 실행된 날.
[반론] 기획 단계 제품이 낡음 관리까지 설계하는 건 과잉이라는 반박이 가능하다. 쌓인 적도 없는데 관리부터 만드느냐. 타당하다. 열 개 미만일 때는 사람 눈으로 충분하다.
[반론에 대한 답] 다만 이건 기능 얘기가 아니라 팔 때 하는 말 얘기다. 지금 데모에서 우리가 보여주는 장면은 한 번 시켜서 절차가 생기는 장면이다. 구매 결정권자가 다음에 묻는 질문은 정해져 있다. 그거 틀리면 어떻게 되나요. 그 질문에 기능으로 답할 필요는 없다. 하지만 답은 있어야 한다.
여기서 우리가 가진 유리함 하나
[제품 정본] Glean 의 해법은 서버가 사용 기록을 모아 개선안을 제안하고 사용자가 확인하면 반영하는 구조다. 그러려면 서버가 그 팀의 대화를 본다.
[제품 제약] 우리 설계는 서버는 계정·공유 자료·협업 상태를, 기기는 로컬 업무 실행을 맡는다로 갈라져 있다. [제안] 그렇다면 절차가 낡았는지 판정하는 일은 기기에서 일어나고, 판정 결과만 팀에 올라가는 구성이 가능하다. 이건 로컬이라 안전하다는 포장이 아니다 — 같은 기능을 켜는 데 필요한 자료 범위가 다르다는 사실 한 줄이고, 그 한 줄은 질의서에서 체크박스 하나 차이로 나타난다.
이번 주에 할 일
- 정본에 지표 한 줄을 추가한다. 승인된 스킬 재사용 옆에 폐기·수정된 절차 비율. 안 쌓여도 0 으로 적는다. 0 도 데이터다.
- 데모 시나리오에 두 번째 장면을 붙인다. 1장은 절차가 생기는 장면, 2장은 그 절차가 틀렸다고 사람이 말하는 장면. 2장이 없으면 우리 데모는 경쟁사 10월 15일 글보다 뒤에 있다.
- 파일럿 설계의 4주를 손본다. 기간을 늘리는 게 아니라, 마지막 주에 지금도 맞는 절차인지 묻는 점검 한 번을 끼운다. 축적의 값을 재는 유일한 방법은 유효기간을 재는 것이다.