🎙NiN터뷰: 노션의 한계와 대안은? 노션다움이 노션을 덜 쓰는 이유

📌 이번 뉴스레터는 이런 분들을 위해 준비했습니다.

노션을 가장 깊게 파고든 사람이 노션에서 일을 덜어내고 있다면, 그 사이에는 어떤 판단이 있었을까요?

3년 넘게 노션과 자동화를 가르쳐 온 노션다움님은 최근 회원 정보와 결제, 출결 데이터를 노션 밖으로 옮기기 시작했어요.

사용자가 데이터베이스를 볼 필요가 없도록 필요한 화면만 따로 만드는 식으로요.

노션을 떠난 것처럼 보이지만, 오히려 노션 안에 한꺼번에 들어가 있던 여러 책임을 제자리로 돌려놓는 과정이라고 말하시더라고요.

판단의 배경에는 생산성의 정의가 바뀌었다는 진단과 이제 남은 병목은 사람의 판단이라는 결론이 있어요.

도구를 갈아타는 기준부터,

실행을 전부 넘긴 사람이 왜 휴먼 병목을 다시 만들었는지까지 담았습니다.

노션을 가르치는 사람이 노션을 덜 쓰기 시작했습니다

안녕하세요. ‘대표 없이도 회사가 굴러가게 만드는’ 비전허브의 이현석입니다.

기업의 업무와 운영 방식을 AI 중심으로 다시 재단해 실제로 작동하는 시스템까지 만들고, ‘노션다움’이라는 브랜드로 노션과 자동화, AI를 3년 넘게 가르치고 있어요.

지난 인터뷰를 하고, 1년 반 사이에 가장 크게 달라진 건 제 역할이에요.

자동화를 잘 만드는 사람에서, 무엇을 AI에게 맡기고 무엇을 사람에게 남길지 판단하는 사람으로 바뀌었습니다.

예전에는 노션에 데이터를 쌓고 Make로 시나리오를 짜는 능력이 곧 실력이었는데, 지금 그 영역은 거의 평준화됐거든요.

무엇을 왜 만들지 정의하는 힘, 만든 뒤에 실제 업무에서 작동하는지 검증하는 힘으로 무게가 옮겨갔어요.

제가 푸는 문제의 크기와 성격이 달라졌기 때문이에요.

예전에는 저 혼자, 또는 작은 팀이 반복 처리하는 일을 줄이는 게 목적이었어요.

그때는 비개발자가 데이터를 구조화하고 자동화까지 붙일 수 있는 조합으로 노션과 Make만 한 게 없었습니다.

그런데 규모가 커지자 노코드라서 쉬웠던 그 구조가, 만든 사람만 고칠 수 있는 또 다른 코드가 되더라고요.

Make도 연결이 늘수록 인증과 분기, 오류 추적에 드는 비용이 커졌고요.

결정적인 계기는 바이브 코딩이었어요. 여기에도 허들이 있었는데 Codex가 나오면서 무너졌습니다.

수식과 모듈 연결, 오류 추적에 며칠씩 걸리던 시스템을, 지금은 자연어 대화로 몇 시간 만에 만들어요.

예전에는 도구가 제공하는 기능 안에서 업무를 바꿔야 했다면,

이제는 업무에 맞춰 도구를 만들 수 있게 됐다는 점이 속도보다도 큰 변화예요.

솔직히 부담스러웠어요. 노션은 제가 잘 다루는 프로그램에 그치지 않았거든요.

사람들이 저를 알아보는 이름이었고, 강의와 콘텐츠를 만들게 해준 언어였고, 지금의 사업과 커뮤니티를 만들어준 기반이었어요.

노션 글로벌 앰배서더이고 브랜드 이름도 ‘노션다움’이니까요.

강의에서도, 제가 운영하는 멤버십인 노다의 방주에서도 늘 이렇게 말해왔어요.

그때가 온 것뿐인데, 판단이 선 뒤에도 입 밖에 내기까지 몇 달이 걸렸습니다.

몇 달이나 걸린 건 결국 관성 때문이었어요.

방주에서 이야기하는 다섯 가지 해방이 노동, 시간, 공간, 관계, 그리고 마지막이 관성입니다.

저는 실패보다 성공에서 생기는 관성이 더 무섭다고 생각해요.

관성은 남이 시켜서 생기지 않아요. 내가 가장 잘해서 생기거든요.

실패한 방식은 버리기 쉬운데, 성공한 방식은 계속 보상을 주거든요.

스스로를 들여다보니 제가 붙잡고 있던 건 노션이 아니라, 도구 뒤에 숨는 안전함이었습니다.

노션을 놓는다는 건 그 안전함을 내려놓고 제 이야기로 서야 한다는 뜻이었습니다.

사실 노션으로 안 되는 일을 꾸역꾸역 노션으로 하려는 태도를 저는 노션병이라고 불러요.

남 이야기인 줄 알았는데 어느 순간 제가 걸려 있더라고요. 그것도 노션암이요.

전문가는 한 도구로 모든 문제를 해결하는 사람이 아니라, 그 도구를 쓰지 말아야 할 순간까지 아는 사람이라고 생각합니다. 그래서 놓았습니다.

관성만으로는 판단이 안 돼요. 놓아야 할 때와 그냥 싫증 난 때가 잘 구분되지 않거든요.

그래서 저는 먼저 다섯 가지를 봅니다.

새 도구가 나왔다고 무조건 옮기지도, 익숙하다고 끝까지 붙잡지도 않아요.

기준 없이 익숙함으로 판단하면, 어느 순간 문제를 해결하는 대신 도구를 지키려고 문제를 왜곡하게 되거든요.

노션 하나로 다 하지 않습니다, 일을 넷으로 나눈 이유

어느 날 갑자기는 아니었어요. 여러 경험이 겹쳤는데, 가장 컸던 건 커뮤니티 인증 시스템을 만들 때였습니다.

슬랙에서 인증이 들어오면 대시보드에 반영하는 시스템인데, 겉으로는 인증 한 번이지만 실제로는 한 건에 노션을 6~8번 호출해요.

그런데 노션 API는 연결 하나당 초당 평균 3건 수준이라, 세 명만 동시에 인증해도 순간적으로 20건이 넘습니다.

그래서 재시도와 지연, 캐싱, 대기열을 계속 덧붙였는데, 어느 순간 이상하다는 생각이 들었어요.

저는 인증을 편하게 만드는 시스템을 만들고 있었는데, 사용자 경험보다 노션이 버티게 만드는 방법을 더 오래 고민하고 있더라고요.

기업 시스템에서도 신호는 있었어요. 근태와 결재, HR을 노션으로 설계하면 요구사항의 90%는 만들어집니다.

그런데 운영에서는 남은 10%가 더 중요했어요. 권한 분기, 잘못된 입력을 막는 검증, 중복 입력 방지, 감사 기록 같은 것들이죠.

자기 출근 시간을 스스로 고치거나 결재를 올린 사람이 스스로 승인할 수 있다면 운영을 맡기기 어렵잖아요.

결정적인 건 바이브 코딩으로 만든 뒤 다시 노션 기반 시스템을 고쳤을 때였어요.

한쪽은 화면과 데이터 구조, 로직을 함께 보며 고치는데,

노션에서는 페이지를 열고, 연결된 데이터베이스를 찾고, 수식과 관계를 하나씩 거슬러 올라가야 했습니다.

주먹도끼를 쓰던 때로 돌아간 것 같은 역체감이었죠.

같은 시스템 안에서도 사람이 볼 것, AI가 읽을 것, 프로그램이 실행할 것 이 서로 다른 자리에 놓입니다. (나노바나나 생성/ 편집: 넛쥐)

첫 번째 층은 사람의 맥락이에요. 회의록과 상담 기록, 강의 전사본, 어떤 결정을 왜 내렸는지가 쌓입니다.

이 자리는 노션이 그대로 맡고 있어요. 저에게 노션은 OO을 OO하는 OO입니다.

.......