ERP·사례2026.07.28읽기 24분

김지명 · SSOD 대표

노션 전사 도입·ERP 구축 완전 가이드: 설계 원리, 한계, 실패 원인

노션 전사 도입(노션 ERP)은 부서마다 따로 돌던 업무를 노션 하나로 모으는 일입니다.

"기업 노션 도입"을 검색하는 대표와 실무자가 정말 묻고 싶은 질문은 대체로 하나입니다. 왜 우리 회사 노션은 늘 메모장에서 멈추는가. 답은 노션을 얼마나 잘 다루느냐가 아니라, 업무를 모듈화·프로세스화해 데이터와 담당자와 자동화가 한 시스템에서 흐르도록 설계했느냐에 달려 있습니다.

이 글은 30개 넘는 기업의 업무 시스템을 노션으로 설계하며 반복해서 확인한 것을 한 편으로 묶은 가이드입니다. 다루는 범위는 다섯 갈래입니다.

노션을 전사 시스템으로 쓴다는 말의 실제 의미와 설계 3동작
노션이 감당하는 영역과 감당하지 못하는 영역의 경계선
권한·데이터 경계 설계, 그리고 기존 시스템과의 연동 방식
규모가 커질 때 드러나는 성능·정합성 문제
도입이 실패하는 구조적 원인과 운영 이관 문제

노션을 만능 도구로 소개하는 글이 아닙니다. 어디까지 밀어붙일 수 있고 어디서부터는 다른 도구가 필요한지를 먼저 그어두는 편이, 도입 후에 되돌리는 비용보다 훨씬 쌉니다.

노션 ERP란 무엇인가

노션을 기업용으로 쓴다는 말은 페이지를 예쁘게 꾸민다는 뜻이 아닙니다. ERP, 곧 전사 업무를 하나의 시스템에서 돌린다는 의미입니다.

개발자가 기업용 ERP를 만들 때는 정해진 절차를 밟습니다. 어떤 데이터가 어떤 플로우와 프로세스로 이동할 것인가를 먼저 설계하는 일입니다. 노션 ERP도 다르지 않습니다. 업무 차원의 설계 동작은 세 가지로 압축됩니다.

모듈화: 하나의 업무를 사람이 실제로 행하는 단위까지 잘게 쪼갭니다.
프로세스화: 쪼갠 모듈을 정해진 순서로 연결하고, 그 안에 담당자·상태값·문서·양식을 함께 넣습니다.
관계화: 데이터베이스끼리 관계형으로 이어 한 곳의 변화가 다른 곳에 자동 반영되게 합니다.

이 설계 과정을 건너뛰면 노션은 개인용이 아니라 '기업용 메모장'이 될 뿐입니다. 업무 시스템과 단순 기록의 차이가 갈리는 지점이 정확히 여기입니다.

한 가지 더 짚을 것이 있습니다. 흔히 말하는 ERP는 회계 원장을 중심에 두고 모든 거래가 그 원장으로 수렴하는 구조입니다. 노션으로 만드는 시스템은 그 구조와 같지 않습니다. 노션이 잘 담는 것은 일이 흘러가는 과정이지, 금액이 확정되어 봉인되는 원장이 아닙니다. 이 차이를 인정하고 시작하면 설계가 훨씬 단순해집니다.

어디까지 노션이고, 어디부터 다른 도구인가

전사 도입에서 가장 먼저 그어야 할 선입니다. 이 선을 긋지 않고 "일단 다 노션으로"를 시도한 조직은 대부분 6개월 안에 일부를 되돌립니다. 되돌리는 과정에서 신뢰가 깎이고, 남은 영역까지 함께 버려지는 일이 흔합니다.

업무 영역	노션 적합도	이유
프로젝트·업무 진행 관리	높음	상태값·담당자·기한이 관계형으로 묶이고, 구조를 바꿔도 수정 비용이 낮습니다
영업 파이프라인·고객 접점 기록	높음	단계 이동과 대화 기록이 한 화면에서 이어집니다
규정·매뉴얼·온보딩 자료	높음	문서와 데이터가 같은 공간에 있어 참조가 끊기지 않습니다
채용·평가 진행 관리	중간	진행 추적은 맞지만 민감 정보 분리 설계가 반드시 따라와야 합니다
재고·자산 현황 파악	중간	대략의 수량 파악은 되지만 실시간 정합성이 걸리는 순간 무너집니다
회계 원장·세무 신고	낮음	복식부기 무결성과 법정 서식 요건을 충족하는 도구가 아닙니다
대량 트랜잭션 처리	낮음	초당 다건 기록과 동시 갱신을 전제로 만들어진 구조가 아닙니다
감사 추적·변경 이력 증빙	낮음	누가 언제 무엇을 바꿨는지 원장 수준으로 남기려면 별도 설계가 필요합니다

노션이 잘 감당하는 것

노션의 강점은 구조를 바꾸는 비용이 낮다는 데 있습니다. 속성 하나를 추가하고 보기를 하나 더 만드는 데 개발 일정이 필요하지 않습니다. 업무 정의가 아직 흔들리는 영역, 부서마다 예외가 많은 영역, 반기마다 프로세스가 바뀌는 영역에서 이 유연성은 대체하기 어려운 값을 합니다.

문서와 데이터가 한 공간에 있다는 점도 큽니다. 일반적인 업무 도구는 진행 상태는 시스템에, 근거 문서는 드라이브에, 논의는 메신저에 흩어집니다. 노션에서는 한 건의 레코드를 열면 그 안에 근거와 논의가 함께 붙어 있습니다. 인수인계와 재확인에 드는 시간이 줄어드는 이유가 여기 있습니다.

노션이 감당하지 못하는 것

반대편도 분명합니다.

회계 원장. 전표가 차변과 대변으로 균형을 이루고, 마감된 기간은 잠기며, 수정하려면 역분개를 남겨야 하는 무결성 규칙을 노션은 강제하지 못합니다. 사람이 지키기로 약속할 수는 있지만, 약속으로 지켜지는 원장은 원장이 아닙니다.

재고의 실시간 정합성. 여러 사람이 동시에 같은 품목의 수량을 조정하는 상황에서 노션은 마지막 저장을 그대로 받아들입니다. 재고가 마이너스로 내려가는 것을 막아 주는 장치도, 차감과 입고가 하나의 단위로 묶여 실패하면 함께 되돌아가는 장치도 없습니다. 일 단위로 실사해 맞추는 수준이면 견디지만, 판매 시점마다 정확한 잔량이 필요한 업무라면 다른 도구가 맞습니다.

감사 추적. 노션에도 페이지 기록과 편집 이력이 남습니다. 다만 "이 금액이 3월 12일에 얼마에서 얼마로, 누구에 의해, 어떤 근거로 바뀌었는가"를 조회 가능한 형태로 남기려면 별도 설계가 필요합니다. 외부 감사나 규제 대응이 걸린 데이터라면 처음부터 노션 밖에 두는 편이 안전합니다.

대량 트랜잭션. 하루 수만 건이 쌓이는 로그성 데이터, 초 단위로 갱신되는 센서 값, 대규모 정산 배치는 노션의 설계 전제 밖입니다. 이런 데이터는 원본을 다른 저장소에 두고, 노션에는 사람이 판단에 쓰는 집계와 예외 건만 올리는 구조가 안정적입니다.

경계선을 긋는 네 가지 질문

영역마다 헷갈릴 때는 아래 네 질문으로 가릅니다. 하나라도 "예"가 나오면 노션 바깥을 먼저 검토합니다.

이 데이터가 틀렸을 때 법적·세무적 책임이 발생합니까.
여러 사람이 같은 값을 동시에 바꿀 가능성이 있습니까.
하루 기록 건수가 사람이 눈으로 확인할 수 있는 범위를 넘습니까.
과거 값이 언제 어떻게 바뀌었는지 증빙해야 합니까.

네 질문이 모두 "아니오"라면 노션에 올려도 무리가 없습니다. 실제로 대부분의 기업 업무는 여기에 해당합니다. 원장과 대량 처리를 걷어내고 나면, 남는 것은 사람이 판단하고 협의하고 넘기는 일이며 그 영역이 노션이 가장 잘하는 자리입니다.

무엇을 올리고 무엇을 남길 것인가

경계선을 그었다면 다음은 배치입니다. 전사 도입은 "노션으로 전부 바꾸기"가 아니라 "업무마다 자리를 정하기"에 가깝습니다.

판단은 네 축으로 합니다.

변경 빈도: 프로세스가 자주 바뀌는 업무일수록 노션이 유리합니다. 개발 일정 없이 구조를 고칠 수 있기 때문입니다.
정합성 요구: 값이 한 순간이라도 어긋나면 안 되는 업무는 노션 바깥에 둡니다.
참여 인원: 부서를 넘나드는 협업이 많을수록 노션이 유리합니다. 한 사람이 닫힌 채로 처리하는 업무는 굳이 옮길 이유가 적습니다.
증빙 요구: 외부에 제출하거나 감사 대상이 되는 기록은 원본을 전용 시스템에 두고 노션에는 참조만 둡니다.

여기서 자주 나오는 실수 하나. 기존 시스템이 이미 있는 영역을 노션으로 덮으려는 시도입니다. 기존 ERP에 매출 데이터가 있는데 노션에도 매출 DB를 만들어 사람이 양쪽에 입력하게 되면, 두 숫자가 달라지는 순간부터 둘 다 신뢰를 잃습니다. 이미 원장이 있는 영역은 노션을 조회와 협업 계층으로만 쓰고, 입력 지점은 하나로 유지해야 합니다.

반대 실수도 있습니다. 엑셀로 잘 굴러가는 소규모 개인 작업을 전부 DB로 올리는 것입니다. 한 사람이 열어 한 사람이 닫는 계산 작업이라면 엑셀이 더 빠릅니다. 옮길 이유는 "여러 사람이 이어받는가"에서 나오지, "노션에 있어야 통일된다"에서 나오지 않습니다.

설계 3동작을 노션 구조로 옮기기

업무 차원의 설계가 모듈화·프로세스화라면, 그것을 노션 DB로 옮기는 차원의 세 동작은 구조화·관계화·프로세스화입니다. 더 깊은 설계 원리는 업무 모듈화·프로세스화와 키맨에서 이어가되, 골격은 다음과 같습니다.

구조화, 틀을 만들고 라벨을 붙입니다. 담당자·날짜·상태·분류·상위 연결을 속성으로 설계합니다. 이때 데이터베이스를 너무 잘게 쪼개지 않습니다. 담당자별로 DB를 따로 만드는 대신, '할 일' DB 하나에 담당자 필터를 거는 편이 옳습니다. DB를 나누는 기준은 사람이나 부서가 아니라 데이터의 성격입니다. 같은 속성 구조를 가진 레코드라면 한 DB에 두고 보기로 나눕니다.

관계화, 이어주고 모아주고 판단합니다. 관계형으로 데이터베이스를 잇고, 롤업으로 하위 데이터를 끌어모으고, 수식으로 위험도나 지연 여부를 계산합니다. 프로젝트와 할 일을 연결해 두면 완료율과 지연 건수가 상위 DB에서 자동으로 집계됩니다. 관계형·롤업·수식의 실무 설계 기준은 노션 데이터베이스 완전 정복에서 따로 다룹니다.

프로세스화, 단계를 줄입니다. 상태를 일일이 바꾸는 대신 버튼 하나로 완료 처리하고, 반복 작업은 노션 자동화나 외부 도구의 웹훅·스케줄 트리거로 시스템에 넘깁니다. 사람이 "다음에 뭘 해야 하지"를 기억하지 않아도 되는 상태가 목표입니다.

세 동작이 결합될 때 비로소 노션은 스스로 움직이는 시스템이 됩니다.

구조 설계에서 반복되는 실수

전사 규모에서 특히 자주 나오는 것들입니다.

DB 과다 분할. 부서별·담당자별·연도별로 DB를 나누면 처음엔 깔끔해 보이지만, 전사 집계가 필요한 순간 모든 DB를 손으로 합치게 됩니다. 나누기 전에 "이걸 나중에 한 화면에서 봐야 하는가"를 묻습니다.
상태를 텍스트로 관리. 상태 값을 자유 입력 텍스트로 두면 '완료', '완료됨', '완료 '가 공존합니다. 선택형 속성으로 값의 집합을 고정합니다.
속성 남용. 한 DB에 속성이 서른 개를 넘어가면 입력하는 사람이 무엇을 채워야 할지 판단하지 못합니다. 채워지지 않는 속성은 없는 속성보다 나쁩니다.
페이지 중첩 깊이. 페이지 안의 페이지 안의 페이지로 내려가는 구조는 검색으로도 찾기 어려워집니다. 깊이 대신 관계형으로 연결합니다.
보기 난립. 개인이 임시로 만든 보기가 공용 DB에 쌓이면 다른 사람이 어떤 화면을 봐야 하는지 알 수 없게 됩니다. 공용 보기와 개인 보기를 구분하는 규칙이 필요합니다.

권한과 데이터 경계 설계

전사 도입에서 기술적으로 가장 예민한 대목입니다. 부서 단위 사용에서는 문제가 되지 않던 것이, 전사로 넓히는 순간 전부 드러납니다.

노션의 권한은 워크스페이스, 팀스페이스, 개별 페이지·DB의 세 층위로 걸리고, 비즈니스 플랜 이상에서는 행 단위 규칙이 하나 더 붙습니다. DB 공유 메뉴의 페이지 수준 액세스에서 사람 속성이나 생성자를 기준으로 지정하면, 그 속성에 자기가 들어간 행만 열립니다. 게스트도 이 속성에 배정되므로, 외부 협력자에게 좌석 비용 없이 자기 건만 열어 주는 구성도 가능합니다.

여기서 설계 원칙 세 가지가 나옵니다.

필터는 보안 경계가 아닙니다. 보기에 필터를 걸어 자기 것만 보이게 만드는 일은 화면 정리에 해당합니다. 보기 설정을 바꾸거나 검색하면 나머지가 그대로 나옵니다. 가려야 하는 데이터는 필터가 아니라 권한 규칙이나 DB 분리로 다룹니다.

행은 가려도 열은 못 가립니다. 규칙으로 행을 가려도 열린 행 안의 속성은 전부 보입니다. 수수료율이나 내부 평가처럼 같은 행에 놓이면 안 되는 항목은 애초에 다른 DB로 빼 둡니다. 실제 공수는 규칙 설정이 아니라 이 필드 감사 쪽에 붙습니다.

규칙은 권한을 올리기만 합니다. 기본을 편집 가능으로 주고 규칙으로 특정 행을 잠그는 설계는 성립하지 않습니다. 기본은 항상 최소로 깔고 필요한 것만 규칙으로 올립니다. 거꾸로 잡으면 데이터가 쌓인 뒤에 되돌리기 어렵습니다.

실무에서 자주 쓰는 배치는 이렇습니다.

전사 공개 영역: 규정, 매뉴얼, 공지, 조직도, 공용 양식. 누구나 읽고 정해진 사람만 편집합니다.
팀 단위 영역: 팀의 업무 DB와 문서. 팀 구성원 편집, 타 팀 읽기 또는 접근 불가.
민감 영역: 급여, 인사 평가, 계약 원본, 법무 이슈. 별도 팀스페이스에 두고 접근자를 명시적으로 관리합니다. 전사 DB와 관계형으로 잇고 싶은 유혹이 생기는데, 관계형으로 이으면 연결된 페이지 제목이 상대편에서 보일 수 있습니다. 민감 영역은 끊어 두고 필요한 값만 별도 속성으로 옮겨 적는 편이 안전합니다.
외부 접점: 고객·협력사와 공유하는 페이지. 게스트로 초대하되, 게스트가 붙은 페이지가 어떤 상위 구조에 속해 있는지 반드시 확인합니다.

웹 공개 설정도 전사 규모에서는 관리 대상입니다. 누군가 편의로 켜 둔 공개 링크가 검색엔진에 걸리는 사고가 실제로 일어납니다. 공개 전환 권한을 제한하고, 공개된 페이지 목록을 주기적으로 점검하는 절차를 운영 규칙에 넣어야 합니다.

권한 설계에서 마지막으로 짚을 것은 퇴사 처리입니다. 사람이 나갈 때 계정만 지우면 그 사람이 만든 페이지의 소유 관계와 자동화가 함께 흔들립니다. 개인 계정으로 연결해 둔 외부 연동은 특히 그렇습니다. 연동과 자동화는 처음부터 개인이 아니라 조직 단위 계정에 붙여 둡니다.

기존 시스템과의 연동, 그리고 각각의 한계

전사 도입이라면 노션 하나만 쓰는 경우는 사실상 없습니다. 회계 시스템, 그룹웨어, 스프레드시트, 사내 개발 시스템이 이미 돌고 있고, 노션은 그 사이에 들어갑니다. 연동 방식마다 감수해야 할 것이 다릅니다.

연동 방식	데이터 흐름	맞는 상황	감수할 것
수기 이중 입력	사람이 양쪽에 입력	건수가 적고 기간이 짧은 과도기	누락과 불일치가 반드시 생기고, 임시 조치가 상시화됩니다
CSV 주기 임포트	기존 시스템에서 노션으로	월·주 단위 집계를 참조만 할 때	시점이 어긋나고, 갱신본이 기존 행을 덮거나 중복을 만듭니다
API 단방향 동기화	기존 시스템에서 노션으로	원장은 기존 시스템, 조회·협업은 노션	노션에서 고친 값은 다음 동기화에 사라집니다
API 양방향 동기화	양쪽이 서로 갱신	두 시스템 모두가 입력 지점일 때	충돌 해소 규칙과 우선순위를 직접 정의해야 합니다
자동화 도구 중계	이벤트 기반 릴레이	연결할 도구가 셋 이상으로 늘 때	중계 계층 자체가 유지보수 대상이 됩니다

표에서 실무적으로 가장 자주 맞는 답은 세 번째 줄, 단방향 동기화입니다. 원장은 원장 자리에 두고 노션은 읽는 쪽에 선다는 원칙이 대부분의 정합성 문제를 미리 없애 줍니다. 이 구조를 잡으면 "어느 쪽 숫자가 맞느냐"는 질문 자체가 사라집니다.

양방향을 택해야 한다면 세 가지를 문서로 먼저 정해야 합니다. 어느 쪽이 우선하는가, 동시에 바뀌었을 때 무엇을 남기는가, 한쪽에서 삭제된 건을 반대쪽에서 어떻게 처리하는가. 이 셋을 정하지 않은 양방향 연동은 예외 상황이 오는 순간 사람이 손으로 맞추게 되고, 결국 첫 번째 줄로 되돌아갑니다.

연동 구현에서 실제로 자주 부딪히는 것은 화려한 문제가 아니라 사소한 것들입니다. 속성 이름을 바꿨더니 자동화가 조용히 멈추고, 선택지 하나를 추가했더니 값 매핑이 어긋나고, 호출 한도에 걸려 야간 배치가 절반만 돕니다. 그래서 연동에는 반드시 실패를 알아차리는 장치가 함께 붙어야 합니다. 실패가 조용하면 며칠 뒤에 틀어진 데이터로 발견됩니다.

규모가 커지면 나타나는 문제

부서 하나에서 잘 돌던 구조가 전사로 넓어지면 성격이 다른 문제가 올라옵니다. 대부분 설계를 조금 바꾸면 풀리지만, 증상과 원인을 연결하지 못하면 "노션이 느리다"는 결론으로 끝나 버립니다.

증상	흔한 원인	대응 방향
목록이 열리기까지 눈에 띄게 느림	한 DB에 행이 계속 쌓이고 기본 보기에 필터가 없음	기간·상태로 보기를 나누고, 종료 건은 보관용 DB로 옮깁니다
화면마다 숫자가 다르게 보임	롤업이 롤업을 참조하는 다단 집계	집계 단계를 줄이고 중간값을 속성으로 고정합니다
자동화가 조용히 멈춤	호출 한도 초과, 속성 이름 변경	실패 알림을 별도 채널로 받고 속성 변경 절차를 정합니다
같은 건이 두 번 기록됨	입력 경로가 여러 개	입력 지점을 하나로 줄이고 고유 키로 중복을 걸러냅니다
지난달 값이 언제 바뀌었는지 알 수 없음	변경 이력이 남지 않는 구조	확정 시점의 스냅샷을 별도 DB에 적재합니다
검색해도 원하는 문서가 안 나옴	제목 규칙 없이 자유롭게 생성	명명 규칙을 정하고 템플릿에 제목 형식을 넣습니다

성능 문제는 대개 한 화면이 너무 많은 것을 계산하려 할 때 생깁니다. 수천 행짜리 DB를 필터 없이 열고, 그 안에서 롤업이 다시 하위 DB를 훑고, 수식이 그 결과로 다시 계산하는 구조라면 느려지는 것이 당연합니다. 화면을 목적별로 쪼개는 것이 가장 빠른 해법입니다. 사람은 어차피 한 번에 수천 건을 보지 않습니다.

정합성 문제는 성격이 다릅니다. 노션은 두 사람이 같은 값을 거의 동시에 바꿀 때 나중 저장을 그대로 받습니다. 대부분의 협업 업무에서는 문제가 되지 않지만, 숫자를 차감하는 종류의 작업에서는 조용히 틀린 값이 남습니다. 차감이 필요한 업무는 사람이 값을 직접 고치게 두지 말고, 기록을 쌓고 합계를 계산하는 구조로 바꾸는 편이 안전합니다.

이력 문제도 미리 설계해야 합니다. 노션 속성은 현재 값만 보여 줍니다. 지난달 마감 시점의 값이 필요하다면, 그 시점에 값을 복제해 남기는 동작을 자동화에 넣어야 합니다. 나중에 필요해졌을 때 과거는 복원되지 않습니다.

실제로 이렇게 흘렀습니다

노무·세무 영역의 한 법인은 기존 정산 프로세스가 불필요한 연락으로 복잡하게 얽혀 있었습니다. 단계의 개수보다 단계와 단계 사이를 메우던 연락이 더 큰 부담이었습니다. 서류가 들어오면 담당자가 확인하고, 누군가에게 알리고, 그 사람이 또 다른 담당자에게 전달하고, "처리됐나요"를 묻는 연락이 반복됐습니다. 일이 일을 부르는 구조였습니다.

재설계의 출발점은 업무의 시작 신호를 사람이 아니라 사건에 맡긴 데 있습니다. 공단에서 팩스가 도착하면 매니저가 사건 DB의 지정된 칸에 서류를 올립니다. 이 업로드 한 번이 이후 흐름 전체를 깨우는 트리거가 됩니다. 누가 누구에게 "이거 왔어요"라고 알릴 필요가 사라집니다.

서류가 올라가는 순간 뒤에서 시스템이 돕니다. 영업 이사와 담당자에게 업무가 자동으로 배정되고, 담당자는 고객에게 연락한 뒤 처리 내역을 노션에 입력하기만 하면 됩니다. 그 입력은 다시 정산 DB에 자동으로 반영되고, 이사는 월말에 그 DB를 보고 인센티브를 지급하면 끝입니다. 전달, 확인, 재전달로 이어지던 연락 사슬이 업로드, 자동 배정, 입력, 자동 반영으로 압축된 셈입니다.

마지막 조각은 고객 응대였습니다. 사건의 상태값과 진행 경과일을 기준으로, 해당 고객에게 맞는 안내가 자동 발송되도록 설정했습니다. "며칠째 어느 단계"라는 정보를 사람이 일일이 챙겨 연락하던 일이 규칙으로 대체됐습니다. 상태값이 바뀌거나 경과일이 기준을 넘으면 시스템이 알아서 움직입니다.

결과를 요약하면, 정산 한 건이 흐르는 데 필요한 단계가 대략 절반으로 줄었고 일정 기간 접수율은 두 배가 됐습니다. 그 이상의 정밀한 숫자를 늘어놓지 않는 이유가 있습니다. 이런 개선의 효과는 "몇 퍼센트 단축" 한 줄로 환원되지 않기 때문입니다. 줄어든 것은 시간만이 아니라 사람의 주의와 연락 피로였습니다.

이 사례에서 가져갈 것은 도구가 아니라 순서입니다. 노션으로 바꿔서 좋아진 것이 아니라, 업무를 행동 단위까지 쪼개고 연락이 끼어 있던 자리를 트리거로 대체한 다음 그것을 노션으로 구현했기 때문에 좋아졌습니다. 순서를 바꾸면 결과도 바뀝니다.

도입이 실패하는 구조적 원인

실패를 진단하려면 '실패'의 정의부터 맞춰야 합니다. 노션이 안 켜지거나 데이터가 날아가는 것이 실패가 아닙니다. 멀쩡히 돌아가는데도 직원들이 다시 엑셀과 메신저로 돌아가는 상태, 그것이 실패입니다. 현장에서 막히는 지점은 거의 같습니다.

1. 업무 모듈화가 없습니다

대부분의 업무는 반복입니다. 정해진 순서와 규칙, 내부적으로 합의된 절차가 이미 있다는 뜻입니다. 견적서 발송 하나만 봐도 요청 접수, 고객 정보 확인, 요구사항 파악, 부서 협의, 초안 작성, 검토·승인, 전달, 피드백 반영의 단계를 거칩니다.

모듈화는 여기서 한 단계 더 들어갑니다. 견적서 한 장을 만들려고 사람이 실제로 하는 행동까지 펼치는 일입니다. 프로그램 실행, 양식 파일 찾기, 템플릿 불러오기, 문의 메일 확인, 수치 기입. 이렇게 풀면 단계는 보통 두 배로 늘어납니다.

이걸 그대로 노션에 옮겨야 합니다. DB와 DB 사이를 넘나드는 내규가 있어야 하고, 그 이동을 일으키는 버튼이 정확히 설계돼 있어야 합니다. 많은 기업이 이 과정을 건너뜁니다. 노션을 그냥 메모장이라 여기기 때문입니다.

2. 프로세스화가 없습니다

모듈을 만들었다면 순서에 맞게 연결해야 합니다. A 업무가 끝나면 B가 어떻게 시작되고 C로 어떻게 넘어가는지, 그 사이의 담당자와 상태값이 노션 안에서 흘러야 합니다. 노션은 레고 블록과 같습니다. 블록을 가졌다는 사실보다, 어떤 모양으로 조립할지 설계하는 능력이 시스템을 만듭니다.

3. 전담 키맨이 없습니다

DB를 설계하고, 프로세스를 관찰하고, 자동화와 연계하는 사람. 이 키맨이 없으면 앞의 둘도 굴러가지 않습니다.

회사가 직원 한 명을 키맨으로 세웠다고 해 보겠습니다. 본업만으로도 바쁜 사람에게 "효율화도 같이 하라"고 얹는 순간 문제가 시작됩니다. 효율화는 누군가의 일이 한동안 늘어야 다른 사람의 일이 주는 작업입니다. 게다가 노션을 전사 시스템으로 만들다 보면 매일 크고 작은 요청이 올라옵니다. "이게 안 돼요." 이 요청을 꾸준히 받아 고치는 사람이 없으면 시스템은 멈춥니다.

4. 조직 차원에서 반복되는 실패 패턴

앞의 셋이 설계와 인력의 문제라면, 아래는 조직 운영의 문제입니다. 기술적으로 잘 만든 시스템도 여기서 무너집니다.

위에서 내려온 도입. 결정은 경영진이 하고 사용은 실무자가 합니다. 실무자가 설계 과정에 한 번도 참여하지 않으면, 완성된 순간부터 "왜 이렇게 만들었냐"는 저항이 시작됩니다. 파일럿 단계에서 실제 사용자를 설계 테이블에 앉히는 비용이 나중에 설득하는 비용보다 훨씬 쌉니다.
병행 운영의 무기한화. 안전을 위해 기존 방식과 노션을 함께 돌리는 기간은 필요합니다. 문제는 그 기간에 끝나는 날짜가 없을 때입니다. 두 곳에 입력하는 부담이 계속되면 사람은 익숙한 쪽만 채우고 노션은 비어 갑니다. 전환일을 미리 못 박고, 그날 이후에는 기존 경로를 실제로 닫아야 합니다.
파일럿 대상 선정 실패. 가장 복잡한 부서를 첫 대상으로 고르면 구축 기간이 늘어지고 성과가 보이지 않습니다. 반대로 너무 단순한 업무를 고르면 "그 정도는 엑셀로도 된다"는 반응이 나옵니다. 적당한 첫 대상은 불편이 명확하고 관계자가 적은 업무입니다.
구축자만 아는 구조. 수식과 자동화가 왜 그렇게 짜였는지 문서가 없으면, 구축한 사람이 자리를 옮기는 순간 아무도 손대지 못하는 구조가 됩니다. 손대지 못하는 시스템은 방치되고, 방치된 시스템은 버려집니다.
성과 측정 부재. 무엇이 나아졌는지 합의된 기준이 없으면, 도입에 든 비용만 남고 효과는 각자의 인상으로 갈립니다. 무엇을 줄이려고 시작했는지를 착수 전에 적어 두는 것이 좋습니다.

기업용 템플릿을 사면 안 되는 이유

시중에 도는 기업용 템플릿은 권하지 않습니다. 매출 수백억 규모 기업의 대표가 50만 원을 주고 산 템플릿을, 정작 열어 보고 끝낸 경우를 여러 번 봤습니다. 시중에는 500만 원짜리 기업용 템플릿도 있습니다. 가격이 열 배라도 결과는 다르지 않습니다.

이유는 단순합니다. 템플릿에는 그 회사의 업무 모듈화도, 구조화도 담겨 있지 않기 때문입니다. 모듈화와 프로세스화는 각 기업의 업무 흐름에서만 나옵니다. 남의 회사 양식으로는 우리 회사 업무가 흐르지 않습니다.

템플릿이 아무 쓸모가 없다는 뜻은 아닙니다. 속성 구성이나 보기 구성을 참고하는 용도로는 값을 합니다. 다만 그것은 참고 자료이지 도입 그 자체가 아닙니다. 착각의 대가가 큰 이유는 돈보다 시간입니다. 템플릿을 산 조직은 대개 몇 달을 "이걸 우리 업무에 맞추는" 데 쓰고, 그 몇 달 동안 정작 필요한 관찰과 설계를 하지 않습니다.

운영 이관과 내부 담당자 역량

구축이 끝나는 시점이 도입이 끝나는 시점은 아닙니다. 전사 시스템은 살아 있는 구조라서, 조직이 바뀌면 구조도 따라 바뀌어야 합니다. 이관이 제대로 안 된 시스템은 6개월쯤 지나 현실과 어긋나기 시작하고, 어긋난 시스템은 빠르게 버려집니다.

이관에서 실제로 필요한 것은 계정 권한 이양이 아니라 다음 사람이 고칠 수 있는 상태입니다. 최소한 아래는 문서로 남아 있어야 합니다.

DB 목록과 각 DB의 역할, 그리고 DB 사이의 관계도
속성 명명 규칙과 선택지 값의 의미
수식이 무엇을 계산하는지에 대한 설명
자동화 목록, 각 자동화의 트리거와 실패 시 증상
외부 연동에 쓰인 계정과 갱신 주기
권한 대장, 누가 어디에 접근하는가
구조 변경 절차, 누가 승인하고 어떻게 공지하는가

내부 담당자에게 필요한 역량은 노션 기능 숙련도가 아닙니다. 기능은 몇 주면 익힙니다. 어려운 것은 업무를 관찰해 구조로 옮기는 감각이고, 이것은 그 회사의 일을 아는 사람이 훨씬 빨리 얻습니다. 그래서 키맨 후보는 노션을 잘 아는 사람이 아니라, 업무 흐름을 잘 알고 남의 불편을 잘 듣는 사람 중에서 고르는 편이 낫습니다.

그리고 그 사람에게는 시간을 실제로 떼어 줘야 합니다. 본업 100퍼센트를 그대로 둔 채 얹으면 어떤 담당자도 버티지 못합니다. 전사 도입을 결정했다면 담당자의 업무 배분을 함께 결정해야 합니다. 이 역할을 내부에서 키울지 외부에 맡길지의 판단 기준은 기업 노션, 직접 구축 vs 컨설팅 외주에서 따로 정리했습니다.

도입 순서를 어떻게 잡을 것인가

마지막으로 순서입니다. 전사 도입을 한 번에 설계해 한 번에 여는 방식은 거의 실패합니다. 실무에서 안정적으로 굴러가는 순서는 대체로 이렇습니다.

관찰. 대상 업무가 실제로 어떻게 흐르는지 사람의 행동 단위까지 펼칩니다. 이 단계에서 설계를 시작하지 않습니다. 보는 것만 합니다.
경계 긋기. 앞의 네 질문으로 노션에 올릴 것과 남길 것을 가릅니다.
파일럿 하나. 불편이 명확하고 관계자가 적은 업무 하나를 골라 끝까지 굴립니다. 여기서 나온 피드백이 전사 설계의 재료가 됩니다.
구조 확정. 파일럿에서 검증된 명명 규칙, 속성 체계, 상태값 정의를 전사 표준으로 고정합니다.
확장. 인접 업무로 넓힙니다. 이때 표준을 지키게 하는 것이 속도보다 중요합니다.
연동. 기존 시스템과 잇습니다. 단방향부터 시작하고, 실패 알림을 반드시 함께 붙입니다.
이관. 문서를 남기고 담당자를 세웁니다. 이 단계를 건너뛰면 앞의 여섯이 유예될 뿐입니다.

자동화를 어느 시점에 넣을지 묻는 경우가 많은데, 4번 이후가 적당합니다. 구조가 흔들리는 동안 만든 자동화는 구조가 바뀔 때마다 다시 짜야 합니다. 자동화로 무엇부터 손댈지 고르는 기준은 노션 자동화 완전 가이드에 정리돼 있습니다.

오늘 할 수 있는 일

노션을 전사 시스템으로 쓰는 방법은 두 가지로 좁혀집니다. 현업을 가장 잘 아는 내부 사람이 부족한 노션 이해를 채워 직접 키맨이 되거나, 그 역할을 외부에 맡기거나. 어느 쪽이든 실제로 필요한 것은 주기적인 관찰과 디버깅입니다. 노션을 전사 시스템으로 만들면 "이게 안 된다"는 피드백이 끊임없이 올라오고, 누군가는 그 문제를 계속 잡아 줘야 합니다. 노션 전문성만으로는 부족하고, 그 업에 대한 이해가 있어야 비효율적인 프로세스를 짚어 덜어낼 수 있습니다.

당장 시작할 수 있는 일은 하나입니다. 내 업무를 세부 단계까지 관찰해 보는 것. 어떤 업무가 어떤 순서로 흐르는지 펼쳐 보면 노션화할 첫 모듈이 보이고, 동시에 노션에 올리면 안 되는 영역도 함께 보입니다. 그 관찰이 메모장을 시스템으로 바꾸는 출발점입니다.

관찰한 업무를 어디까지 노션에 올리고 어디서부터 다른 도구로 넘겨야 할지 판단이 서지 않는다면, 컨설팅 신청에서 업무 경계부터 함께 그어 보세요.