비행기 모드를 위해 만들기

규칙

우리가 출시하는 모든 기능에 대해 우리는 묻는다: 비행기 모드에서 동작하는가?

답이 아니오라면 그 기능은 출시하지 않는다. 저하된 형태로도 아니고, "인터넷 연결이 필요해요" 토스트와 함께도 아니고, 슬픈 placeholder와 함께도 아니다. 네트워크 없이 동작하든가, 제품 안에 존재하지 않든가 둘 중 하나다.

이것은 우리가 적어둔 가장 유용한 한 줄짜리 설계 규칙이다.

그것이 강제하는 것

• 모델은 기기에 산다. 클라우드에서 데워지는 캐시가 아니고, "오프라인용 fallback"도 아니다. 첫날부터 기기 위에.
• 상태는 기기에 산다. 노트, 전사, 설정, 히스토리 — 모두 로컬 SQLite 안, 파일 포맷은 공개.
• 업데이트는 신중하다. 모델 업그레이드는 당신이 옵트인. 푸시하지 않고 슬쩍 바꾸지도 않는다. 어제 동작한 버전은 내일도 동작.
• 에러는 진실을 말한다. "서버에 닿지 못했어요"는 불가능 — 닿을 서버가 없다. 에러는 로컬: 메모리 부족, 모델 파일 누락, 마이크 권한 거부. 정직하고, 당신이 직접 할 수 있는 해법이 있다.

그 대가

• 기기 간 기능은 페어링 댄스가 필요하다, 단순 로그인이 아니라. 다른 글에서 썼다.
• "새 기기에 로그인해서 내 것에 접근"은 없다. 새 기기는 새 기기, 페어링 전엔 신선한 모델 파일만.
• 리더보드, 커뮤니티 피드, 실시간 멀티유저는 없다. 모두 네트워크 필요. 모두 우리가 만들고 싶은 제품의 일부가 아니다.

왜 오늘 이 규칙인가

세 가지 이유:

1. 마침내 가능해졌다. 5년 전 이 규칙은 "훨씬 약한 앱을 출시"를 뜻했다. 오늘 양자화된 1~7B 모델은 "약간 더 초점 있는 앱을 출시"를 뜻한다. 능력 격차가 거래할 가치가 있을 만큼 작다.
2. 의사결정이 명료해진다. 규칙이 "모든 기능 오프라인에서 동작"이면 제품 로드맵은 시류 클라우드 벤더가 부채질하는 걸 쫓지 않는 방식으로 자연스럽게 써진다.
3. 이 카테고리에서 사용자가 실제로 원하는 것이다. 사람들은 클라우드 전략이 멋져서 노트북을 사지 않는다. 회의에서, 통근길에서, 새벽 1시 침실에서 동작해서 산다.

우리는 회사 전체를 걸고 있다: 이것이 개인 AI 다음 10년의 올바른 규칙이라고. 결과는 알려드리겠다.