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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

두 번째 층은 AI가 참고하는 지식이에요. 사람이 읽으려고 쓴 문서와 AI가 참조하려고 정제한 문서는 형태가 달라야 하거든요.

매번 수백 페이지를 읽게 할 수는 없으니, 반복되는 기준과 매뉴얼만 작은 문서로 정리해 옵시디언과 LLM Wiki에 나눠 두고 실험 중이에요.

세 번째 층은 운영 데이터예요. 회원과 인증, 점수, 결제, 출결, 권한처럼 틀리면 안 되는 값이죠.

이 층은 Supabase가 맡아요. 잘못된 값이 처음부터 들어오지 못하게 막고, 누가 어떤 행을 읽고 쓸지도 데이터베이스 수준에서 제한할 수 있거든요.

네 번째 층은 사람이 쓰는 화면과 업무 로직이에요. Codex와 Claude Code를 이용한 바이브 코딩으로 직접 만듭니다.

회원에게는 인증 제출만, 운영자에게는 현황판만 보이도록 역할별 화면을 따로 만드는 식이죠.

8할은 태생이고 2할은 우선순위 문제라고 봅니다.

노션은 데이터베이스가 아니라 페이지에서 출발한 프로그램이에요.

문서들을 표처럼 묶어 보고 싶어서 데이터베이스가 생긴 구조라, 노션의 한 줄은 레코드가 아니라 페이지입니다.

사람이 데이터를 직접 들여다보던 시대에는 이게 압도적인 장점이었어요.

그런데 지금은 데이터를 읽는 주체가 바뀌었어요.

AI에게는 색깔도 레이아웃도 필요 없고, 초당 몇 건을 정확한 순서로 읽고 쓰느냐가 중요하거든요.

노션은 한 번에 조회할 수 있는 양도 최대 300개 행 정도고, 데이터에는 아예 초가 없습니다.

분 단위까지만 기록되니 1분 0초에 만든 데이터와 1분 40초에 수정한 데이터가 같은 시각으로 남아요.

자동화가 가져갈 때 수정 여부를 판별할 방법이 없죠.

4년 전부터 이야기해왔는데 여전히 그대로인 걸 보면, 우선순위에서 높게 치지 않은 거라고 봅니다.

저는 노션의 역할을 이제 세 가지로 정리해 뒀어요.

첫 번째는 교보재입니다. 데이터베이스를 처음 배우기엔 노션만 한 게 없어요.

필터와 정렬, 관계형, 롤업이 전부 눈에 보이거든요. 전문 데이터베이스는 구조가 화면 뒤에 숨어 있는데, 노션은 내가 만든 구조와 그 결과가 동시에 보입니다.

AI가 데이터베이스를 대신 만들어주는 시대일수록, 그게 맞는지 볼 줄 아는 눈이 필요하고요.

두 번째는 파일럿이에요. 처음부터 전문 데이터베이스로 화면까지 개발하면 잘못 설계했을 때 수정 비용이 큽니다.

노션에서는 속성과 관계를 바꿔가며 업무 구조를 빠르게 시험해볼 수 있어요.

저는 노션을 최종 도착지가 아니라 실제 시스템을 만들기 전에 실패해보는 공간으로 씁니다.

세 번째가 아카이브입니다. 조금 과격하게는 데이터 배터리라고 불러요.

《매트릭스》에서 기계가 캡슐 속 사람들의 에너지를 꺼내 쓰잖아요.

사람은 노션에 회의록과 전사본, 상담 기록과 판단의 맥락을 계속 쌓고, AI와 외부 시스템은 필요할 때 그걸 꺼내 새 문서나 실행으로 바꾸는 겁니다.

한 줄이 레코드이면서 그 안에 문서가 통째로 들어가는 도구는 지금도 노션뿐이라, 이 자리는 대체가 안 돼요.

그러니까 제가 놓아준 건 노션이 아니에요.

노션이 데이터베이스이자 화면이고, 권한 시스템이자 자동화 엔진이며, 모든 업무의 최종 목적지여야 한다는 기대를 놓아준 겁니다.

제가 계속 이런 이야기를 하는 건 노션을 떠나려는 게 아니라, 이 이야기가 들려야 바뀐다고 믿기 때문이에요.

데이터는 노션에 두고 화면만 만드는 게 사실 가장 좋은 그림이거든요.

그래서 저는 여전히 노션을 기다리고 있습니다. 속도가 열 배, 스무 배만 올라와도 다른 도구로 넘어가지 않아요.

노션과 AI를 배우러 오지 마시고, 내 문제 하나를 들고 오세요

네, 그게 핵심이에요. 강의는 정답을 전달하는 자리가 아니라 판단 기준을 넘기는 자리라고 봅니다.

제가 만든 템플릿을 그대로 쓰게 하면 다음 도구가 나왔을 때 다시 배워야 해요.

그런데 왜 이 구조를 택했는지가 넘어가면 도구가 바뀌어도 같은 판단을 하실 수 있거든요.

그래서 도반(멤버십 호칭)들이 저보다 멀리 가는 편이 좋고요.

사실 같은 질문을 저에게 세 번 반복했어요. 노션과 자동화 도구를 알려주는 게 맞는가.

2025년, 작년 봄에 처음 물었을 때 답은 맞다였고, 그해 11월에도 같았어요.

근데 2026년 5월에 진행한 부트캠프에서 하루 동안 자기 시스템을 만든 걸 인증해야 하는데, 한 참가자가 이렇게 남기셨습니다.

그 문장을 보는 순간 제가 학습자의 문제보다 기존 커리큘럼의 형식을 먼저 지키고 있다는 걸 알았어요.

그래서 올해 3번째로 같은 질문을 던졌고, 처음으로 ‘아니다’라는 답이 나왔습니다.

체감상 30~40% 정도가 바뀌었어요. 내려놓은 건 기능 중심 교육이고, 그 자리에 채운 건 세 가지입니다.

필터와 관계형, 수식은 여전히 다루지만, 목표가 아니라 교보재로 위치를 옮겼어요.

먼저 데이터 구조를 보는 눈이에요.

개체(Entity), 사건(Event), 기간(Period)라는 3축으로 DB 구조를 짜는 기준을 만들었는데,

앞글자를 따서 EEP라고 설명드리고 있어요.

도구가 바뀌어도 업무는 개체와 사건, 기간으로 나뉩니다. 이 축이 잡히면 어떤 도구를 써도 같은 구조가 보여요. (나노바나나 생성/ 편집: 넛쥐)

두 번째는 문제 정의와 업무 관찰이에요. CRM을 만들어 달라는 요청은 기능의 이름일 뿐이거든요.

무엇이 반복되고 어디서 끊기고 그때 누가 무엇을 다시 입력하는지를 관찰해야 합니다.

세 번째는 실제 운영되는 시스템을 직접 만들어 보는 경험이에요.

학원 운영자와 조경회사, 성교육 강사, 병원 운영자처럼 업무가 전부 다르니 같은 결과물이 나올 수 없습니다.

총 2가지인데요, 하나는 문제를 충분히 좁히지 못하는 경우입니다.

시스템을 만들겠다고 하면 처음부터 전사 운영 시스템을 떠올리십니다.

고객 관리도 넣고 프로젝트와 매출, 일정, 직원까지 하나로 연결하려고 하죠.

그러면 시스템을 만드는 일 자체가 새로운 업무가 되니, 크게 생각하되 작게 만들라고 말씀드려요.

내 시간을 1분 줄이거나 지금의 고통을 5% 덜어주는 작은 시스템 하나가 먼저입니다.

다른 하나는 완벽하게 따라잡으려는 경우예요.

밀린 강의를 다 끝낸 뒤 돌아오려고 하면 그 사이에 새 수업이 또 진행되거든요.

이해가 안 되더라도 지금 진행되는 수업부터 들어와 용어에 익숙해지는 편이 낫습니다.

자동화했는데 왜 더 바빠질까요?

지금까지 병목은 늘 제 바깥에 있었어요. 손과 발이, 정보와 장소가, 흩어진 도구가 병목이었죠.

그래서 새 도구 중에 괜찮은 걸로 해결하고 있었는데, AI가 실행의 병목을 없앤 거예요.

실행 속도는 열 배가 돼서 결과물이 계속 오는데, 제 판단 속도는 열 배가 되지 않았어요.

저는 이 변화를 세 단계로 설명해요.

처음에는 사람이 루프 그 자체였어요. 확인하고 찾고 작성하고 전송하는 모든 과정을 직접 했죠.

다음이 Human in the Loop입니다. 반복 실행은 시스템이 맡고, 중요한 단계마다 사람이 승인해요.

여기서 문제가 생겨요. AI가 몇 분마다 결과물을 가져오면 검수 업무도 함께 늘어나거든요.

자동화했는데 더 바빠지는 이유가 여기 있습니다.

그래서 다음이 Human on the Loop예요.

사람이 루프 안에서 모든 일을 붙잡고 있는 게 아니라 루프 위에서 전체 시스템을 감독한다는 뜻이에요.

기준 안에 있고 위험도가 낮은 일은 승인 없이 흘러가고, 기준을 벗어난 예외와 손실이 큰 결정만 올라와요.

모든 결과물을 검수하는 게 아니라, 어떤 결과물을 검수해야 하는지까지 설계하는 것입니다.

저는 지금을 in the Loop와 on the Loop 사이의 과도기라고 봐요.

AI는 이미 실행자 역할을 충분히 하는데, 우리의 판단 기준과 암묵지가 아직 시스템으로 옮겨지지 않았거든요.

당연히 사람이 계속 루프 안에 있을 수 밖에 없는거죠.

결국 남은 병목은 AI의 실행 능력이 아니라 제 머릿속에만 있는 판단이에요.

병목이 옮겨갈 때마다 일 잘한다는 말의 기준도 함께 옮겨갔습니다. 마지막 자리에 남은 병목은 사람의 판단이에요. (나노바나나 생성/ 편집: 넛쥐)

그보다는 나누고 보니 그것이 병목의 역사가 되더라고요.

기준은 하나예요. 그 시대의 생산성을 가로막던 가장 큰 병목을 어떤 기술이 해결했는가.

1.0부터 1.5까지는 전부 어떻게 더 빠르고 정확하게 할 것인가를 풀어온 역사였어요.

그러다 생성형 AI가 등장하면서 실행하는 방법의 가치가 평준화됐어요. 여기가 2.0입니다.

예전에는 글을 쓰거나 코드를 구현하는 능력 자체가 경쟁력이었지만, 지금은 일정 수준의 결과물을 누구나 만들 수 있잖아요.

병목이 실행에서 방향으로 옮겨간 겁니다.

다만 2.0에도 한계가 있었어요. 모든 중요한 판단에 제가 필요했습니다.

그래서 지금을 2.1로 따로 뒀습니다. 앞에서 말씀드린 Human on the Loop가 그 자리예요.

1.5까지는 도구가 병목을 풀었는데, 여기서는 풀어야 할 게 도구가 아니라 제 머릿속이라는 점이 다릅니다.

그럼요. 강은영님은 컨설팅을 하는 분이었어요. 클라이언트 한 명당 24시간을 직접 투입해야 했습니다.

지금은 그중 약 22시간을 시스템이 대신하고, 본인은 마지막 검수와 고차원적인 판단에 집중합니다.

연간 최소 500시간이 들어가던 공고 리서치도 사라졌죠.

더 인상적인 건 시간이 아니라, 이 일을 사업으로 키울 수 있게 됐다는 점이에요.

본인의 감각으로 제공하는 컨설팅이라 고객 수에 한계가 있었고, 본인이 멈추면 서비스도 멈췄거든요.

지금은 전문성이 시스템으로 분리되면서 다시 꿈꿀 여유가 생기셨습니다.

그래서인지 미래의 도반들에게 이렇게 말하고 싶다시더라고요. “노션 배우러 오지 마시고, 내 문제 하나를 들고 오세요.”

그래서 저는 내가 없어도 돌아가는 시스템이라는 말보다 나처럼 일하는 시스템이라는 말을 씁니다.

사람을 빼내는 게 목적이 아니라, 내 기준을 옮겨 심는 게 목적이거든요.

실제로 오픈 특강 운영은 이제 제 손을 거의 거치지 않아요.

예전에는 신청을 받고 안내를 보내고 입장을 확인하고 리마인드를 돌리는 일을 사람이 순서대로 했는데, 지금은 신청부터 참석률과 이탈 구간을 정리한 보고서까지 한 흐름으로 돌아갑니다.

제가 하는 일은 보고서를 읽고 다음 특강을 어떻게 바꿀지 정하는 것이에요.

한마디로 결정의 근거입니다.

대부분의 회사에 데이터가 없는 게 아니에요. 계약서와 견적서, 보고서, 매출 자료가 다 있습니다.

그런데 그건 전부 결정의 결과물이에요.

왜 그 가격을 냈고, 왜 그 고객은 받고 다른 고객은 정중히 거절했는지는 어디에도 없거든요.

필요한 건 네 가지예요.

특히 금기는 대부분 실패에서 나와요. 성공만 쌓으면 해야 할 것만 학습됩니다.

실행 엔진은 평준화된 만큼, 차이는 이런 연료에서 갈릴 거예요.

어떤 병목은 일부러 남겨둡니다

자료 출처 : youtube

한동안 에이전트를 여러 개 띄워 병렬로 돌렸어요.

하나가 작업하는 동안 다른 에이전트에게 또 일을 주고, 빈 시간이 보이지 않게 계속 채웠습니다.

그런데 어느 순간 보니 제가 쉬는 시간이 하나도 없더라고요.

AI가 쉬는 시간을 만들어준 게 아니라, 예전에는 기다림이 만들어주던 자연스러운 병목까지 없애버린 겁니다.

AI 토큰은 돈을 내면 늘릴 수 있지만, 사람이 하루에 읽고 이해하고 책임질 수 있는 양은 유한해요.

피곤한 상태에서 다섯 개를 대충 승인하면 산출량은 늘어도 판단의 품질은 떨어지고요.

그래서 저는 일부러 휴먼 병목을 만듭니다.

일을 느리게 하려는 장치가 아니라 판단의 품질을 지키는 속도 제한이에요.

도로의 과속방지턱과 비슷합니다. 빨리 달릴 수 있으니까 일부러 만든 장치잖아요.

그렇게 확보한 시간은 세 곳에 써요.

저만 할 수 있는 판단이 필요한 일, 사람을 만나는 일, 그리고 아무것도 하지 않는 일이에요.

마지막이 가장 어려웠지만, 비워둔 시간이 다음 판단을 만들기도 하거든요.

대화 중에 흘려들은 말이 나중에 인사이트로 정리되는 경우가 많은데, 빈 시간은 이런 경험이 관점으로 바뀌는 시간이라고 생각합니다.

저는 돈이 아주 많아져도 강의는 계속할 것 같아요. 돈이 강의하는 이유는 아니거든요.가르칠 생각을 하면 일하는 방식이 달라져요. 혼자라면 그냥 해버리면 됩니다.

하지만 나중에 알려줘야 하니까 어디서 막혔고 무엇을 몰랐는지를 일부러 남겨둡니다.

강의가 해야 할 일은 정답을 대신 알려주는 것이 아니라, 이런 ‘실패의 지도’를 알려주는 일이라 생각합니다.

다만 이렇게만 말하면 근사한 척하는 것 같으니 더 정직한 이유를 말씀드릴게요.

저한테 필요하기 때문입니다. 가르치면서 생각이 정리되거든요.

사실 앞에서 말했던 EEP가 가장 좋은 사례예요.

컨설팅에서 이미 쓰면서도 왜 그렇게 하는지 설명하지 못하던 암묵지였어요.

혼자 정립해보려다 매번 실패했어요. 안에 있는 사람은 그 구조가 안 보이거든요.

결국 그걸 꺼낸 사람은 노다의 방주 1기 도반이었어요.

도반은 멤버십에 참여하는 분을 칭하는 말인데요, 밖에 있는 사람의 시선으로 계속 질문을 던져주셨거든요.

제가 가르친 것이 그대로 저에게 돌아와 커리큘럼의 첫 자리에 놓인 셈이에요.

세 가지가 남아요.

먼저 문제의식입니다. 내 업무에서 무엇이 반복되고 어디서 끊기는지를 묻는 질문이 몸에 남아요.

시스템을 완성하지 못했더라도 이 질문은 다른 일에서 계속 쓰입니다.

두 번째는 계속 따라갈 수 있는 환경이에요.

녹화본과 강의노트, 항해일지가 그대로 남아 있으니 지금 멈춰도 다음 항해에서 이어갈 수 있어요.

세 번째는 도반입니다.

같은 구간에서 막혔던 사람이 옆에 있다는 사실만으로 다시 시작하는 문턱이 낮아지거든요.

이걸 실감한 장면이 하나 있어요. 3기 승선식 때 첫 시간이 끝나고 10분 쉬는 동안 다들 너무 친해지셔서, 제가 수업을 다시 시작하지 못할 정도였거든요.

그때 그분들이 느낀 건 기술이 아니라 나 혼자가 아니구나였을 거예요.

디지털 대홍수, 노다의 방주 4기가 승선자를 찾습니다

기술이 바뀌어도 어떤 문제를 해결하고 어떤 가치를 만들지를 붙잡자는 것,

시행착오까지 나누는 집단지성, 평범한 사람을 받쳐주는 시스템까지.

현석님께서는 도구가 쏟아지는 디지털 AI시대에 대해 적응할 수 있도록

노다의 방주라는 멤버십을 만들어서 운영 중이세요.

이렇게 운영됩니다

오늘의 크리에이터, 노션다움님이셨습니다!
노션다움님이 궁금하시다면 이미지를 클릭해주세요!