김지명 · SSOD 대표
업무 모듈화·프로세스화와 키맨: 노션 ERP의 진짜 설계
노션이 메모장을 넘어 업무 시스템이 되려면 세 가지 설계가 필요합니다. 업무를 행동 단위까지 쪼개는 업무 모듈화, 그 모듈을 순서대로 잇는 프로세스화, 그리고 이 설계를 운영할 키맨. 이 중 하나라도 빠지면 노션은 기업용 메모장에 머뭅니다. 업무를 시스템으로 옮기려는 사람이 가장 먼저 이해해야 할 노션 ERP 설계의 뼈대를 정리합니다.
업무 모듈화란 무엇인가
쏘드가 컨설팅한 기업마다, 업무의 8할은 반복이었습니다. 정해진 순서와 내부적으로 합의된 규칙이 이미 존재한다는 뜻이기도 합니다. 업무 모듈화는 이 반복 업무를 사람이 실제로 행하는 행동 단위까지 잘게 쪼개는 작업을 말합니다.
견적서 발송을 예로 들어 보겠습니다. 업무 차원에서 보면 요청 접수 → 고객 정보 확인 → 내부 협의 → 초안 작성 → 검토·승인 → 전달 → 피드백 처리로, 일고여덟 단계입니다. 그런데 모듈화는 여기서 한 겹 더 들어갑니다. 견적서 하나를 쓰려고 사람이 실제로 하는 행동은 무엇인가? 컴퓨터를 켜고, 업무 프로그램과 엑셀을 실행하고, 양식 파일을 찾고, 템플릿을 불러오고, 고객 문의 메일을 확인하고, 필요한 수치를 직접 기입합니다. 행동 단위로 내려가면 단계 수가 두 배가량 늘어납니다.
핵심은 이렇게 쪼갠 행동을 그대로 노션에 옮기는 일. 많은 기업이 이 과정을 건너뜁니다. 노션을 그저 메모장으로 보기 때문입니다. 행동 단위 설계 없이는 체계적인 DB 구성도, A DB에서 B DB로 넘어가는 내규와 버튼 설계도 나올 수 없습니다. 기업용 ERP를 만드는 개발자가 "어떤 플로우로 데이터가 이전될 것인가"를 먼저 설계하듯, 노션 ERP 설계도 이 단계에서 출발합니다.
업무 프로세스화: 모듈을 순서로 잇는다
모듈로 쪼갰다면 다음은 연결입니다. 업무 프로세스화는 A 업무가 끝나면 B가, B 다음엔 C가 어떻게 이어질지를 담당자·상태값·필요 문서·양식과 함께 노션 안에 짜 넣는 일입니다. 노션을 레고 블록이라 할 때, 모듈이 블록이라면 프로세스화는 그 블록을 어떤 모양으로 쌓을지에 대한 설계에 해당합니다.
노무·세무 전문 법인의 정산 프로세스가 좋은 사례입니다. 기존 정산은 불필요한 연락이 얽혀 복잡했습니다. 모듈화 후 프로세스화하자 흐름이 이렇게 바뀌었습니다. 공단에서 팩스가 오면 매니저가 사건 DB의 지정 칸에 서류를 올립니다 → 시스템이 자동으로 영업 이사와 담당자에게 업무를 배정합니다 → 담당자가 고객에게 연락하고 노션에 내역을 작성하면 정산 DB에 자동 반영됩니다 → 이사는 정산 DB를 보고 월말에 인센티브를 지급합니다. 단계가 절반으로 줄었고, 사람이 들인 노력과 시간도 함께 줄었습니다.
시중의 기업용 템플릿을 사도 이 일이 되지 않는 이유가 여기 있습니다. 50만 원짜리를 열어봐도 막상 쓸 수 없는 건, 우리 회사의 업무 모듈과 프로세스가 그 안에 들어 있지 않아서입니다. 노션에 무엇이 들어갈지 세부적으로 구조화하고 설계하지 못하면, 노션은 결코 업무용 툴이 될 수 없습니다.
키맨: 설계를 운영할 사람
세 번째 요소가 가장 자주 빠집니다. DB를 설계하고, 프로세스를 관찰하고, 자동화로 연계하는 일을 전담하는 사람, 곧 노션 키맨입니다. 노션을 어느 정도 다룬다는 것과 기업용으로 운영한다는 것은 전혀 다른 차원의 일입니다.
여기에 정면으로 마주해야 할 역설이 있습니다. 효율화란 결국 누군가의 일이 줄어드는 것. 그런데 그 줄어듦을 만들어내려면 누군가의 일은 반드시 늘어야 합니다. 회사는 보통 이 시간을 기다려주지 않습니다. "본업 하면서 이것도 같이 해"라고 떠넘기는 순간, 그 직원은 지치고, 시스템은 그 한 명과 함께 멈출 위험을 안게 됩니다. 노션을 ERP로 만드는 작업은 사실상 개발자의 일에 가깝고, 만드는 과정에서 끊임없이 애로사항이 발생합니다. 지속적으로 피드백하고 디버깅을 잡아줄 사람이 없으면 시스템은 멈춥니다.
쏘드가 주 1회 고객사에 직접 나가는 이유도 직접 키맨이 되기 위해서입니다. 노션 전문성만으로는 부족합니다. 그 회사의 업(業)을 이해해야 비효율적인 프로세스를 짚어내고 덜어낼 수 있기 때문입니다. 현업을 아는 사람이 노션을 배워 스스로 키맨이 되거나, 아예 맡기거나. 결국 어느 쪽이 우리 회사에 맞는지의 문제입니다. 어느 쪽을 고를지는 직접 구축과 컨설팅 외주의 판단 기준에서 더 따져볼 수 있습니다.
오늘 시작할 수 있는 것
설계는 거창한 도구가 아니라 관찰에서 출발합니다. 본인 업무가 실제로 어떤 행동들로 이뤄지는지 행동 단위로 적어 보세요. 거기서 모듈이 보이고, 모듈을 잇는 순서에서 프로세스가 드러나며, 그 흐름을 운영할 사람이 곧 키맨입니다. 이 세 가지가 갖춰질 때 노션은 비로소 메모장을 벗어나 스스로 돌아가는 업무 시스템이 됩니다.
혼자 관찰하는 데 한계가 있다면, 컨설팅 신청으로 지금 하는 업무를 적어 보내 주세요. 모듈화의 첫 단추부터 같이 짚어 드립니다.
관련 인사이트
노션 전사 도입·ERP 구축 완전 가이드: 설계 원리, 한계, 실패 원인
노션을 전사 업무 시스템으로 쓸 때 무엇을 올리고 무엇을 남길지, 권한과 데이터 경계를 어떻게 긋고 기존 시스템과 어떻게 잇는지, 규모가 커지면 어떤 성능·정합성 문제가 나오는지, 도입이 실패하는 구조적 원인은 무엇인지를 한 편에 정리했습니다. 노션이 감당하는 영역과 감당하지 못하는 영역의 경계선도 함께 다룹니다.
노션 컨설팅 비용과 업체 선택 기준: 견적을 읽는 법부터 계약 전 확인할 것까지
노션 컨설팅 비용이 무엇으로 결정되는지, 견적서에서 어떤 항목을 확인해야 하는지, 그리고 그 견적을 낸 업체를 어떤 기준으로 골라야 하는지를 한 편에 정리했습니다. 컨설팅 범위를 이루는 작업 항목, 견적 비교 체크리스트, 계약에서 자주 밟는 함정, 프로젝트가 실패하는 구조적 원인, 발주 측이 준비해야 할 것까지 다룹니다.
기업 노션, 직접 구축 vs 컨설팅 외주: 의사결정 기준
직접 구축과 컨설팅 외주의 갈림길은 비용이 아닙니다. 현업 이해와 노션 전문성 중 어느 칸이 비어 있고 그 칸을 누가 메울지의 문제입니다. 두 길이 각각 맞는 조건과 키맨 떠넘기기 함정, 제3의 길인 동반 구축까지 정리했습니다.

