9월에 경쟁사가 새로 판 것은 기능이 아니었다
외부 공식자료. Notion 릴리스 노트 2026년 9월 9일자는 워크스페이스 소유자가 Notion Agent와 Custom Agents에 쓸 모델을 각각 골라 제한하고 기본 모델을 지정하는 기능을 올렸다. 붙인 이유 문구가 정직하다 — "비용을 예측 가능하게 유지하고 컴플라이언스 요구를 지원한다". 8월 19일에는 Workers·연결·개인 액세스 토큰을 한 곳에서 관리하는 개발자 포털을 사이드바로 끌어올렸다.
외부 공식자료. Claude Code 공식 문서의 설정 우선순위 최상단은 조직이 배포하는 managed settings다. 문서의 표현은 "당신이 설정한 어떤 것도 이를 덮지 못한다"다. availableModels 로 모델 선택 자체를 잠그고, 일부 보안 민감 키는 오히려 더 엄격한 하위 값을 우선한다.
| 경쟁 제품 | 9월 시점 관리 층 | 그들이 붙인 명분 |
|---|---|---|
| Notion | 에이전트별 모델 제한·기본값, 토큰/연결 관리 | 비용 예측, 컴플라이언스 |
| Claude Code | MDM·콘솔 관리 설정, 권한 규칙 잠금 | 보안 정책 준수 |
| Glean | AI 사용량·지출 통제, 상호작용 거버넌스 | 엔터프라이즈 통제 |
우리 차별점 문장의 주어가 비어 있다
오늘 받은 brand-context(2026-09-07 기준)의 차별점은 이렇게 적혀 있다. "승인된 실제 업무 수행에서 재사용 가능한 팀 절차를 축적한다." 핵심가치에도 "사용자 통제", "출처 있는 맥락"이 들어 있다.
구현 확인 범위의 사실. 그런데 같은 문서의 제품 제약 15개 줄에 승인·정책·감사에 해당하는 항목은 한 줄도 없다. 있는 것은 "서버는 계정·공유 자료·협업 상태를, 기기는 로컬 업무 실행을 맡는다"뿐이다. 실행이 각자 기기에서 일어나는 구조에서 누가 무엇을 승인했고 그 승인이 어디에 남는지가 설계에 없다.
미검증 가설. 팔 때 이게 걸린다고 본다. 축적을 데모로 보여주는 순간 상대는 "그 절차는 누가 승인한 건가"를 묻게 되고, 답이 화면에 없으면 팀 단위 파일럿은 IT 검토 앞에서 멈춘다. 이건 아직 고객에게 확인한 사실이 아니라 가설이다. 다만 경쟁사 셋이 같은 분기에 같은 층을 만든 것은 가설의 근거가 된다.
반대 의견 — 기획 단계에 거버넌스는 사치다
제안에 대한 정당한 반론. 고객이 한 팀도 없는 제품이 승인 흐름부터 만들면, 검증할 핵심(절감시간·재사용)은 뒤로 밀린다. Notion이 모델 통제를 붙인 건 이미 쓰는 팀이 수만 개라서다. 순서가 다르다.
절반 맞다. 그래서 기능을 앞당기라는 말이 아니다. 지금 필요한 건 세일즈 자료에서 답할 수 있는 한 장이다. 누가 승인하고, 기록이 어디 남고, 못 하는 것은 무엇인지. 문서는 하루면 쓰고, 기능은 첫 파일럿의 요구를 보고 정하면 된다. brand-context가 이미 "직원 감시를 전면 메시지로 삼지 않는다"고 선을 그어놨으니, 통제를 감시로 파는 실수도 피할 수 있다.
이번 주에 할 일
- 승인 한 장 쓰기.
.agents에approval-model.md초안. 승인 주체, 기록 위치, 범위 밖 항목 3개를 명시. 기능 약속이 아니라 현재 설계의 서술로 쓴다. - 데모 시나리오에 승인 화면 한 컷 추가. 절차가 축적되는 장면 다음에 "이 절차를 승인한 사람과 시각"이 보이는 컷. 목업이어도 된다. 없으면 축적 데모는 리스크로 읽힌다.
- 파일럿 질문지에 한 문항 추가. "AI 도구 도입을 지금 막고 있는 검토 절차가 있습니까?" 예/아니오가 아니라 누가 막는지를 받는다. 가설을 여기서 처음 검증한다.