"우리 팀도 노션 씁니다." 이렇게 답하는 리더들을 꽤 많이 만났습니다. 그런데 그 뒤에 이어지는 고민은 이상할 정도로 비슷합니다.
"쓰긴 쓰는데, 솔직히 잘 안 써요."
"처음엔 다들 열심히 하더니, 한 달 지나니까 다시 카톡이랑 엑셀로 돌아가더라고요."
"페이지는 500개쯤 있는데, 정작 필요한 정보는 슬랙에서 검색하는 게 더 빨라요."
이런 대화를 반복해서 듣다 보면 한 가지가 분명해집니다. 노션을 '도입한' 팀은 많아도, 노션으로 '일하는' 팀은 생각보다 훨씬 적다는 사실이죠. 흥미로운 건 이 실패 패턴이 팀 규모와 거의 상관없이 닮아 있다는 점입니다. 3인 스타트업이든 50인 조직이든 노션이 무너지는 방식은 비슷합니다. 도구의 문제가 아니라 '설계'의 문제이기 때문입니다.
수많은 팀의 워크스페이스를 들여다보면서 발견한 사실이 있습니다. 노션이 망하는 데에는 몇 가지 정해진 경로가 있다는 것입니다.
구조 부재 - "일단 페이지부터 만들고 보자"
가장 흔한 실패 유형입니다. 팀장이 어느 날 "우리도 노션 쓰자"라고 선언하면 각자 알아서 페이지를 만들기 시작하죠. 처음 2주는 신기하고 재미있습니다. 회의록도 생기고, 프로젝트 페이지도 생기고, 개인 메모도 올라옵니다.
문제는 한 달 뒤부터 발생합니다. "그 회의록 어디 있었지?", "저번 주에 OO님이 올린 것 같은데…", "검색해도 안 나오던데요." 같은 대화가 오갑니다. 구조 없이 '페이지만' 쌓이면 노션은 정보를 저장하는 도구가 아니라 정보를 잃어버리는 도구가 됩니다. 방치된 페이지, 중복된 페이지, 이름이 비슷해서 헷갈리는 이른바 '유령 페이지'가 기하급수적으로 늘어나기 때문입니다.
입력 맥락의 오류 - "어디에 뭘 써야 할지 모르겠어요"
두 번째 실패는 좀 더 교묘합니다. 구조는 일단 잡혀 있습니다. 프로젝트 DB도 있고, 회의록 DB도 있고, 위키도 있습니다. 그런데 팀원이 막상 무엇을 적으려고 하면 손이 멈춥니다.
새 회의록을 만들려니 템플릿이 10개나 되고, 프로젝트 트래커에 작업을 추가하려니 채워야 할 속성이 20개입니다. 담당자, 상태, 우선순위부터 에픽, 의존성, 공수까지… 다 채우자니 귀찮고 빈칸으로 두자니 찜찜하죠. 결국 팀원은 이렇게 생각하게 됩니다. "그냥 슬랙에 쓰자."
이처럼 입력 시점의 인지 부담이 크면 아무리 좋은 시스템도 실패할 수밖에 없습니다. 팀원은 '완벽한 DB'가 아니라 '5초 안에 적을 수 있는 곳'을 원한다는 사실을 기억해야 합니다.
설계자의 착각 - "나한테 편한 구조 = 팀에게 편한 구조"
세 번째 실패가 가장 뼈아픕니다. 많은 리더가 본인이 노션을 잘 쓰기 때문에 자기 머릿속 구조를 그대로 팀에 이식하곤 합니다. 하지만 전체 맥락을 꿰고 있는 리더와 달리, 팀원에게 그 구조는 미로와 같습니다.
리더에게는 '3뎁스 들어가면 나오는 그 페이지'가 당연한 위치지만, 팀원에게는 길을 잃기 딱 좋은 깊이입니다. 리더는 링크드 뷰로 필터를 걸어놓고 만족해하나, 팀원은 왜 같은 DB가 여기저기서 다르게 보이는지 혼란스러워합니다.
노션에서 일해본 수많은 팀을 관찰하며 내린 결론은 하나였습니다. '설계자의 편의'와 '사용자의 편의'는 거의 항상 어긋난다는 것입니다. 리더는 늘 설계자의 입장에 서 있기 때문에 이 착각에서 가장 자유롭지 못합니다. 노션은 '도구'보다 '설계'가 먼저여야 하며, 구조 없이 시작하면 팀 규모에 상관없이 실패하게 됩니다.
도입 전, 리더가 먼저 설계해야 할 3가지
노션을 팀에 도입하기 전, 리더가 반드시 결정해야 하는 세 가지가 있습니다. 이 기본 설계가 명확하지 않으면 아무리 예쁜 템플릿을 가져다 써도 한 달 안에 무너집니다.
