블록 하나로 세계를 사로잡은 Notion의 프리미티브
신대리의 비즈니스 프롬프트 뉴스레터
6/18자 [신대리의 비즈니스 프롬프트 뉴스레터]에서 발행된 아티클입니다.
글로벌 혁신 기업가의 경영 인사이트와 함께 실무에 바로 적용할 수 있는 생성형 AI 프롬프트를 매주 엄선해 들려 드립니다
[구독하러 가기]
귀로 듣고 싶다면 팟캐스트 링크를 클릭해보세요.
그래서, 이걸 사람들이 정말 쓰긴 하나요?
당신은 창업을 꿈꾼다.
밤새 깎은 기획서, 수십 번 반복한 발표, 정교한 Figma 화면.
하지만 미팅룸에 앉은 투자자는 딱 한마디를 던진다.
“그래서, 이걸 사람들이 정말 쓰긴 하나요?”
이 질문 앞에서 침묵하는 사람은 많다.
그리고 바로 그 침묵이 많은 창업을 무너뜨린다.
그 누구보다 집요하게 물었던 사람들,
매일 ‘왜 이 기능을 만들고 있는지’ 다시 확인했던 사람들.
Notion은 그렇게 시작됐다.
아름다운 서사가 아니라, 의심과 집착의 기록으로 말이다.
1. 사람을 늘리기보다, 움직임이 술술 흐르는 ‘시스템’을 짰다
Notion의 초창기 인원은 세 명뿐이었다.
그런데도 엔지니어가 디자인을 다듬고, 디자이너가 고객 지원에 뛰어들며,
COO는 코드 리뷰까지 챙겼다.
직함보다 ‘지금 당장 필요한 일’을 먼저 집어 드는 문화가 자연스레 자리 잡은 셈이다.
경계가 희미해지자 회의도 줄었다.
팀을 움직인 규칙은 단 하나였다.
“우리가 하루 종일 써도 답답하지 않은가?”
답답함을 줄이려면 인원이 아니라 작업 흐름을 매끄럽게 해야 했다.
그래서 이들은 첫날부터 다음 두 가지 레일을 까는 데 집중했다.
<NapkinAI>1. 버튼 한 번으로 코드 작성 → 리뷰 → 배포가 끝나는 파이프라인
2. 고객 피드백이 즉시 개발 보드에 자동 등록되는 데이터 흐름
이 ‘시스템 우선’ 설계는 조직 구조와 제품 철학에 동시에 새겨졌다.
블록이라는 단일 요소가 문서·데이터베이스·캘린더를 모두 품듯,
세 사람만으로도 큰 문제를 풀어내는 시스템이 완성된 것이다.
2. 도구를 만들지 않았다, 프리미티브를 만들었다
사람들은 묻는다.
“Notion은 왜 그렇게 다양한 쓰임새가 가능한가요?”
답은 간단하다.
이들은 ‘문서’, ‘표’, ‘캘린더’라는 고정된 기능을 만든 게 아니라,
블록(block)이라는 프리미티브를 만든 것이다.
<출처: notion>블록은 단순하다.
텍스트든, 체크리스트든, 데이터베이스든
모든 건 ‘하나의 블록’으로부터 시작된다.
프리미티브가 단순할수록
유저는 복잡한 문제를 자유롭게 해결할 수 있다.
결국 Notion은 기능이 아니라,
사용자가 스스로 구조를 짤 수 있는 도구의 문법을 만든 것이다.
3. 관찰은 기술보다 강하다
Notion은 사용자 경험을 바꾸기 위해 코드를 먼저 짜지 않았다.
관찰하고, 기록하고, 분석했다.
수백 개의 고객 피드백을 읽고 정리하고 태그를 달았다.
지원팀은 개발자에게 걸어가 “이거 지금 고쳐줘요”라고 말했고,
개발자는 직접 코드를 고치고 다시 채팅창을 열었다.
“지금 다시 새로고침 해보세요.”
기능은 이렇게 수정됐다.
릴리즈 노트도, 버전 관리도 없던 시절.
유저와 직접 소통하며 고쳤다.
이 방식은 단순히 ‘유저 중심 설계’라는 말로는 부족하다.
Notion은 기능을 얹기 전에, 사용자 반응 위에서 먼저 돌아가는 시스템부터 짜 놓은 것이었다.
4. 출시일은 우리가 정하지 않았다—사용자가 먼저 신호를 보냈다
대부분의 스타트업은 ‘D-데이’를 정하고 역산해 달린다.
Notion은 달랐다. 내·외부 일정표보다 사용자의 움직임을 더 믿었다.
* 첫 번째 물결은 Product Hunt였다. 1.0을 올리자 예상치 못한 ‘업보트’ 폭주가 시작됐고, 팀은 그 반응을 따라가며 서버를 증설했다.
<Product Hunt>* 두 번째 물결은 한 줄짜리 트윗. “싱가포르에 와 있습니다. Notion 쓰는 분, 커피 어떠세요?”—비 오는 토요일 아침, 30명이 카페로 몰려들었다.
* 세 번째 물결은 커뮤니티 번역본. 공식 로컬라이징이 나오기도 전에 유저들이 자발적으로 한·일·독어 인터페이스 파일을 만들어 배포했다.
출시 시점이란 결국 “지금 써 보고 싶다”는 외침이 가장 클 때라는 사실을, Notion은 몸으로 배웠다.
팀이 할 일은 그 신호를 즉시 포착해 장벽(서버·언어·가격)을 최소화하는 것뿐이었다.
덕분에 로드맵을 단 한 번도 앞당기지 않았지만, 글로벌 확장은 누구보다 빨랐다.
5. 기술을 쫓지 않고, 타이밍을 읽다
2022년 가을, Simon은 우연히 GPT-4 초기 버전을 접했다.
몇 줄 대화를 나눈 뒤 그는 곧장 Slack에 글을 남겼다.
<출처: Notion Tour>“검색의 시대가 끝날 수도 있어.”
그 직후, 회사 리트릿이 열리던 카리브 해 호텔 방 한쪽에서 두 공동 창업자는 직원들과의 저녁 식사를 미루고 노트북을 펼쳤다. 몇 시간 만에 ‘AI 어시스턴트’ 첫 번째 프로토타입이 화면 위에 떠올랐다.
중요했던 건 최신 모델을 얼마나 빠르게 붙이느냐가 아니었다.
그들은 AI를 ‘새로운 버튼’이 아니라,
사람들이 정보를 생각하고 재구성하는 ‘두 번째 뇌’로 정의했다.
그래서 기능을 더하는 대신, 사용자의 사고 흐름부터 다시 설계했다.
결국 Notion이 선택한 AI는 의미 없는 단순한 기술 경쟁의 수단이 아닌
고객 경험의 확장이었다.
<출처: Notion>Notion은 시장의 파동보다 사용자의 다음 움직임을 먼저 보았기 때문에,
그들은 누구보다 빠르면서도 과열되지 않은 속도로 미래를 선점할 수 있었다.
6. 실패 앞에서 멈추지 않았다
창업 첫 3년 동안 Notion의 코드는 세 번 완전히 갈아엎어졌다.
어제 만든 기능을 오늘 지우고, 다음 주에 다시 쓰는 일이 일상이었다.
그리고 그 과정에서 ‘실패’라는 단어는 한 번도 쓰이지 않았다.
대신 매 사이클을 이렇게 정의했다.
<NapkinAI>* 거슬리면 삭제: 작동이 매끄럽지 않으면 즉시 지운다.
* 가설이면 실험: 새 버전은 곧바로 사용자 손에 올려둔다.
* 효용이면 증폭: 만족감이 확인되면 전사(全社)가 힘을 실어 확장한다.
이 간단한 루프 덕분에 팀은 속도를 잃지 않았다.
“완벽은 체크리스트가 아니라, 다음 릴리스의 재료다.”
Notion이 믿은 것은 ‘완벽’이 아니라 지속 가능한 반복이었다.
멈추지 않는 개선만이 제품을 성장시킨다는 사실을,
이 작은 팀이 몸으로 증명해 보였다.
7. 신대리의 인사이트 리포트
Notion의 이야기는 “좋은 코드가 곧 좋은 제품”이라는 통념을 깨뜨린다.
성공을 만든 건 코드의 양이 아니라 질문의 밀도였다.
지금 우리 팀이 점검해야 할 포인트는 네 가지다.
1. 관찰 vs. 추측
* 고객 행동을 실제로 기록하고 있는가, 아니면 회의실 추측에 머무르고 있는가?
2. 프리미티브 사고
* 새로운 기능을 더하기 전에 ‘모두가 재조립할 수 있는 최소 단위’부터 설계했는가?
3. 시스템 설계
* 업무가 특정 인력에게 묶여 있지 않은가? 작업 흐름을 ‘사람’이 아닌 ‘구조’에 의존하도록 설계했는가?
4. 반복 가능한 속도
* 릴리스 → 피드백 → 개선이 주 단위로 도는가, 아니면 승인 절차 때문에 월 단위로 지연되는가?
정리하면
Notion은 더 많은 자원이 아니라, 더 나은 질문으로 성장했다.
기술·예산·인력이 부족해도 질문의 깊이만 확보한다면 같은 궤적을 그릴 수 있다.
우리 팀이 오늘 던져야 할 마지막 질문은 이것이다.
“내일도 같은 속도로 다시 만들 수 있는가?”
결론 ― 완벽한 계획보다 ‘멈추지 않는 반복’
Notion이 남긴 교훈은 거창하지 않다.
탄탄한 로드맵보다, 매일 한 번 더 시도해 보는 용기가 회사를 키웠다는 사실이다.
아이디어는 거칠었고 기능은 자주 깨졌지만,
팀은 멈추지 않았다.
“오늘 만든 걸 내일 버릴 수 있는가?”를 스스로에게 묻고
또다시 빌드·테스트·수정을 반복했다.
그 과정에서 ‘실패’는 기록이 되었고
‘다음 단계’는 오히려 더 선명해졌다.
계획은 시장이 바뀌면 종잇장이 되지만,
반복은 변화 속에서 속도를 붙인다.
작게 만들고, 바로 써 보고, 곧바로 고치는 리듬—
바로 그 리듬이 제품을 성장시켰다.
- 지금 당신의 팀은 어떤 리듬으로 움직이는가?
- 더 완벽한 설계도를 기다리며 머뭇거리는가,
- 아니면 작은 실험을 굴려 내일을 앞당기는가?
완벽은 목적지가 아니다.
‘계속 만든다’는 행위 자체가
제품과 팀을 전진시키는 유일한 엔진임을
Notion이 몸소 증명했다.
*프리미티브 (Primitive)
: 가장 기본적인 단위 요소. Notion에서는 문서나 데이터베이스도 결국 ‘블록’이라는 단일 단위로 구성된다. 이처럼 최소 단위의 요소를 조합해 다양한 기능을 만들 수 있도록 하는 전략.
*리팩터링 (Refactoring)
: 기존 기능의 외형은 유지하되, 내부 구조나 코드를 개선하는 작업. Notion은 전체 시스템을 3\~4회 전면 리팩터링하며 제품을 재정비했다.
*PMF (Product–Market Fit)
: 제품이 특정 시장의 요구에 정확히 맞아떨어지며 강력한 사용자 반응을 얻는 상태. 스타트업이 생존하고 성장하는 데 필수적인 조건으로 여겨진다.
*릴리즈 노트 (Release Note)
: 제품 업데이트 내용을 사용자에게 알리는 문서. Notion 초창기에는 이런 공식 발표 없이 직접 고객에게 수정 사항을 실시간 전달했다.
*로컬라이징 (Localizing)
: 제품이나 콘텐츠를 특정 국가·언어·문화에 맞게 최적화하는 작업. Notion은 이를 본격화하기 전부터 유저 커뮤니티의 자발적 확산을 통해 글로벌 진출이 이뤄졌다.
