PM으로 제품을 볼 때 저는 기능 수보다 사용자가 스스로 반복 루프를 만들게 되는지를 먼저 봅니다. 노션(Notion)은 문서, 데이터베이스, 위키, 협업을 한 화면에 모았다는 설명으로 시작하지만, 실제 포지셔닝의 핵심은 다른 데 있습니다. 노션은 사용자를 “잘 적는 사람”이 아니라 일을 다시 쓸 수 있게 설계하는 사람으로 옮겨 놓습니다.
이 차이는 미묘해 보이지만 리텐션 곡선을 바꿉니다. 기록 앱은 시간이 지나면 과거가 쌓이고, 정리 부담이 커지고, 어느 순간 새 노트의 가치가 떨어집니다. 반대로 시스템은 시간이 지날수록 재사용이 늘고, 매번 같은 일을 덜 하게 되고, 팀에서는 그 구조가 업무 언어가 됩니다. 노션이 팔고 있는 것은 텍스트 편집기가 아니라 구성 가능한 업무 문법입니다.
포지셔닝의 실체는 문서와 DB의 경계 삭제가 아니다
겉으로는 문서와 데이터베이스를 함께 쓰는 올인원처럼 보이지만, 노션의 본질은 “무엇이 문서고 무엇이 데이터인가”를 사용자가 매번 다시 정의하게 만드는 데 있습니다. 여기서 블록 모델이 작동합니다. 문장, 체크리스트, 이미지 같은 요소가 한 덩어리로 고정된 문서가 아니라, 조립 가능한 부품이 됩니다.
블록은 단순히 편집 UX가 아니라 가치 제안의 엔진입니다. 블록 단위 조립이 가능해지면 사용자는 자연스럽게 이런 질문을 하기 시작합니다. “이걸 한 번 더 쓸 수 없나”, “팀원도 같은 형식으로 쓰게 만들 수 없나”, “상태별로 모아볼 수 없나”. 이 순간 기록은 시스템으로 변합니다.
블록 모델의 트레이드오프는 자유도가 아니라 일관성 비용이다
블록 기반 구성 가능성은 강력하지만, 동시에 일관성을 사용자가 직접 지불해야 합니다. 자유도가 높을수록 제품이 대신 보장해주던 표준이 사라집니다. 노션이 만들어내는 리텐션은 “편해서 계속 쓴다”가 아니라 “내가 만든 구조가 있어서 떠나기 어렵다”에 가깝습니다. 이 구조는 자산이지만, 유지비도 생깁니다.
블록은 빠른 조립을 주고, 느린 합의를 요구한다
개인 사용에서는 블록의 자유도가 순수한 장점으로 보입니다. 하지만 팀으로 넘어가면 블록은 곧 합의의 단위가 됩니다. 같은 일을 기록해도 사람마다 블록 구성, 속성 이름, 표기 방식이 달라지고, 그 차이가 축적되면 검색성과 재사용성이 떨어집니다.
- 개인에서는 “내가 알아보면 됨”으로 통과하는 불일치가 많습니다.
- 팀에서는 불일치가 곧 온보딩 비용과 오류 비용으로 돌아옵니다.
블록은 유연하지만 구조의 깨짐을 숨기지 않는다
블록을 복사해서 붙이고, 페이지를 복제하고, 뷰를 조금씩 바꾸는 행동이 쉬운 만큼 “원형이 무엇이었는지”가 빨리 흐려집니다. 사람은 정리를 잘해서가 아니라, 정리가 필요한 형태로 계속 만들기 때문에 정리하게 됩니다. 노션은 그 경로를 아주 짧게 만들어 줍니다. 좋은 점이기도 하고, 관리 포인트이기도 합니다.
데이터베이스는 곧 스키마다. 그리고 스키마는 드리프트한다
노션 DB의 매력은 “DB 같은데 문서처럼 쓴다”는 느낌입니다. 하지만 팀이 DB를 여러 개 운영하기 시작하면 진짜 문제는 편집 UX가 아니라 스키마 드리프트로 이동합니다. 속성은 늘어나고, 타입은 바뀌고, 이름은 조금씩 달라지고, 같은 개념이 여러 DB로 중복됩니다. 결과적으로 뷰, 필터, 관계, 롤업 같은 구조가 조금씩 어긋나면서 신뢰도가 떨어집니다.
스키마 드리프트는 나쁜 설계가 아니라 복제의 자연스러운 부산물이다
노션은 템플릿과 복제 UX가 좋아서 초기 확산이 빠릅니다. 그런데 이 강점은 곧장 드리프트로 이어집니다. 팀원이 좋은 페이지를 발견하면 복제하고, 그 자리에서 조금 고치고, 그게 다시 새로운 표준이 됩니다. 어느 순간 “태스크 DB”가 여러 개가 되고, 상태 값이 다르고, 담당자 속성의 의미가 달라지고, 보고용 뷰가 깨집니다.
- 속성 이름의 흔들림은 검색과 필터의 일관성을 무너뜨립니다.
- 속성 타입의 변경은 기존 데이터 해석을 바꾸고, 뷰의 기대를 깨뜨립니다.
- 관계 구조의 중복은 유지보수 포인트를 늘리고, “진짜 소스”를 흐립니다.
PM 관점에서 DB는 기능이 아니라 계약이다
팀이 DB를 쓰기 시작하면 DB는 단순한 표가 아니라 “업무 상태를 어떻게 정의할지”에 대한 계약이 됩니다. 노션은 이 계약을 제품이 강하게 강제하지 않습니다. 대신 사용자가 만든 계약이 리텐션을 만듭니다. 재미있는 지점은, 바로 그 계약이 잘못되면 리텐션이 아니라 이탈로 이어진다는 점입니다. 사람들은 노션을 떠나기 전에 먼저 “이건 정리 지옥이다”라는 감정을 갖습니다. 그 감정의 원인이 종종 스키마 드리프트입니다.
내부 위키는 시간이 지나면 엔트로피를 먹는다
노션을 위키로 쓰는 팀이 늘어날수록 문서는 늘고, 링크는 늘고, 검색 결과는 과포화가 됩니다. 중요한 것은 문서 수가 아니라 문서가 오래될 수밖에 없는 구조입니다. 노션은 작성 장벽을 낮추고 공유를 쉽게 합니다. 그래서 “쓰는 사람”은 빠르게 늘지만 “유지하는 사람”은 자연스럽게 생기지 않습니다.
위키 엔트로피의 전형적인 징후
- 중복 문서가 늘어나고, 어느 것이 최신인지 모호해집니다.
- 소유자 부재로 업데이트가 멈추고, 문서가 방치됩니다.
- 페이지가 고아가 되고, 탐색은 검색에만 의존하게 됩니다.
- 회의록 스팸처럼 신호 대비 노이즈가 커지면서 신뢰가 떨어집니다.
노션이 문제라기보다, 노션의 강점이 자연스럽게 만드는 결과입니다. “무언가를 남길 수 있음”은 곧 “무언가가 남아버림”이기도 합니다. 위키 엔트로피는 팀 규모가 커질수록 빠르게 가속합니다.
위키가 시스템이 되려면 검토 루프가 필요하다
노션의 리텐션이 지속되려면 페이지 생성 루프만큼이나 검토 루프가 돌아야 합니다. 이건 기능보다 운영에 가깝습니다. 예를 들어 문서에 “마지막 검토일”, “오너”, “유효 범위” 같은 메타를 붙이고, 아카이브 기준을 합의하고, 오래된 문서를 정리하는 리듬을 만들면 위키는 지식의 무덤이 아니라 지식의 시스템이 됩니다.
개인에서 팀으로 넘어갈 때 생기는 도입 절벽
노션은 개인이 먼저 사랑하고, 그다음 팀이 끌려 들어오는 제품입니다. 여기서 가장 큰 리스크는 개인의 최적화가 팀의 최적화로 자동 변환되지 않는다는 점입니다. 개인의 시스템은 자기 머릿속 컨텍스트를 전제로 해도 되지만, 팀의 시스템은 언어가 되어야 합니다.
도입 절벽이 생기는 지점
- 권한과 공유: 개인 문서의 공유는 쉽지만, 팀 구조에서는 접근 범위 정의가 일감이 됩니다.
- 표준화: 각자 템플릿을 가져오면 빠르지만, 합의된 형식이 없으면 금방 파편화됩니다.
- 온보딩: 신규 인원이 “어디에 뭐가 있는지”를 익히는 데 시간이 걸리면 시스템은 부담이 됩니다.
- 운영 주체: 누가 구조를 관리하는지 불명확하면 정리가 밀리고, 신뢰가 떨어집니다.
이 절벽을 넘으면 노션은 강한 락인을 만듭니다. 하지만 넘기 전에는 “다 좋은데 우리 팀엔 안 맞는 것 같다”로 끝나기 쉽습니다. 노션의 PM 관점 과제는 기능 추가보다, 이 절벽을 낮추는 경로를 제공하는 것입니다. 사용자는 ‘올인원’이 필요해서가 아니라, ‘우리 방식’을 만들고 싶어서 들어옵니다. 그 방식이 팀으로 확장될 때 무너지지 않게 하는 장치가 필요합니다.
템플릿은 가속 페달이지만, 그대로 두면 템플릿 부채가 된다
노션 확산의 가장 현실적인 촉매는 템플릿입니다. 템플릿은 “아무것도 없는 공포”를 없애고, 첫 번째 시스템을 빠르게 완성하게 해줍니다. 다만 팀이 템플릿을 복제하고 조금씩 바꾸는 순간부터 템플릿 부채가 시작됩니다.
템플릿 부채가 쌓이는 방식
- 복제된 템플릿의 분기가 늘어나고, 표준이 사라집니다.
- 템플릿이 현실을 따라가지 못해 사람들이 자기식으로 우회하기 시작합니다.
- 페이지 구조가 복잡해져 오히려 작성 시간이 늘고, 결국 템플릿을 버립니다.
템플릿을 “한 번 만드는 문서”로 보면 부채가 빨리 쌓입니다. 템플릿을 “운영되는 제품”으로 보면 접근이 바뀝니다. 예를 들어 핵심 DB의 속성은 최소화하고, 뷰와 입력 폼은 팀의 반복 행동에 맞춰 정리하고, 템플릿은 적은 수의 공식 버전으로 유지하는 쪽이 장기적으로 더 싸게 먹힙니다.
AI 보조 문서는 생산성을 올리지만, 신뢰를 깎을 수 있다
AI가 문서 작성의 마지막 마찰을 줄이면 위키는 더 빨리 커집니다. 문제는 그 문서가 늘수록 지식의 품질이 같이 오르지 않는다는 점입니다. AI 보조는 특히 “그럴듯한 문장”을 매우 쉽게 만들어서, 팀 내부에서 권위의 착시를 일으키기 쉽습니다.
AI 보조 문서에서 자주 생기는 리스크
- 근거 없는 단정: 회의의 뉘앙스가 사라지고, 결정이 확정된 것처럼 정리될 수 있습니다.
- 출처의 증발: 왜 그렇게 결정했는지, 어떤 데이터나 맥락이 있었는지가 빠지기 쉽습니다.
- 문서 과잉: 요약이 늘어나고, 읽는 사람이 줄어들며, 신뢰가 떨어집니다.
- 민감 정보 확산: 프롬프트나 자동 요약 흐름에서 접근 통제가 느슨해질 수 있습니다.
여기서 중요한 것은 “AI를 쓰지 말자”가 아닙니다. AI를 지식의 작성자로 두면 리스크가 커지고, 지식의 편집자로 두면 도움이 됩니다. 예를 들어 AI가 결정문을 써주는 것이 아니라, 사람이 쓴 초안을 더 짧게 만들고, 빠진 질문을 찾아내고, 관련 문서를 연결하는 쪽이 안전합니다. 팀 위키에서 신뢰는 기능이 아니라 습관으로 만들어집니다.
노션의 리텐션은 기능 만족이 아니라 구조 자산에서 나온다
노션을 계속 쓰게 만드는 힘은 UI의 편의보다, 시간이 지나며 쌓이는 구조 자산입니다. 페이지가 쌓이는 것이 아니라, 관계가 쌓이고, 뷰가 쌓이고, 입력 규칙이 쌓이고, 그 위에서 반복 행동이 자동화됩니다. 이때 사용자는 단순 이용자가 아니라 시스템의 유지관리자가 됩니다. 떠나면 잃는 것은 문서가 아니라 “우리 팀이 일하는 방식의 형태”가 됩니다.
다만 이 구조 자산은 양날입니다. 관리가 되면 복리로 이득을 만들고, 관리가 안 되면 정리 비용과 불신 비용으로 돌아옵니다. 노션의 포지셔닝을 올바르게 이해하면, 성공과 실패의 원인이 기능 부족이 아니라 구조 운영의 실패인 경우가 많다는 것도 같이 보입니다.
PM이 노션을 벤치마크할 때 봐야 할 질문
노션을 단순히 “올인원”으로 모방하면 대부분 실패합니다. 노션이 만든 것은 기능 묶음이 아니라 사용자의 정체성을 바꾸는 경로입니다. PM 관점에서 더 유효한 질문은 이런 것들입니다.
- 사용자가 첫 시스템을 만드는 순간은 언제인가, 그때 무엇이 촉발되는가
- 재사용이 발생하는 최소 단위는 무엇인가, 블록인가 템플릿인가 DB인가
- 개인에서 팀으로 넘어갈 때 어떤 절벽이 생기고, 누가 그 비용을 내는가
- 스키마 드리프트를 피할 수 없을 때, 드리프트를 관리 가능한 형태로 바꾸는 장치는 무엇인가
- 위키 엔트로피를 늦추는 루프는 제품이 제공하는가, 운영이 제공하는가
- AI 보조가 문서 품질과 신뢰에 미치는 부작용을 어떻게 통제할 것인가
노션은 사용자를 기록에서 시스템으로 이동시키면서 리텐션을 만듭니다. 그 과정에서 생기는 비용도 같이 사용자에게 건넵니다. 그래서 노션은 편한 노트가 아니라 구성 가능한 일의 플랫폼에 더 가깝습니다. 이 포지셔닝을 제대로 받아들이는 팀만이 노션의 장점을 장기 자산으로 바꿉니다.