노션을 바꾸기 전, 업무 흐름부터 정리하는 AX 전환 기준
“노션 페이지는 계속 늘어나는데, 정작 누가 무엇을 해야 하는지는 더 헷갈립니다.”
“새 업무 툴로 옮기면 반복 작업이 정말 줄어들까요?”
“우리 회사에 필요한 기능과 그냥 익숙해서 쓰는 기능은 어떻게 구분하죠?”
노션을 바꿔야 하는 순간은 페이지가 많아졌을 때가 아니라, 업무가 어디서 시작해 어떤 결정과 데이터 변경을 거쳐 끝나는지 설명하기 어려울 때입니다. AX 전환의 출발점은 도구 선정이 아니라 업무 흐름을 하나의 기준으로 정리하는 일입니다.
AX는 AI를 포함한 기술을 업무 방식에 적용하는 전환을 뜻합니다. 저는 크로플을 운영하며 노션을 대체할 목적의 사내 통합 워크스페이스를 직접 구축했고, 화면 기능을 늘리기 전에 같은 업무 상태를 여러 곳에서 따로 관리하고 있지 않은지부터 확인했습니다. 이 기준이 없으면 새 도구는 기존의 혼란을 더 보기 좋게 옮겨 놓는 결과가 되기 쉽습니다.
왜 노션 교체보다 업무 흐름 정리가 먼저일까요?
도구는 업무 흐름을 기록하거나 실행할 뿐, 서로 충돌하는 업무 기준을 대신 결정하지는 않습니다. 교체 전에 반복 업무 하나의 시작·종료·담당·결정 지점을 먼저 드러내야 합니다.
예를 들어 고객 요청이 메신저로 들어오고, 담당자가 노션에 옮기며, 일정은 캘린더에 적고, 완료 여부는 다시 채팅으로 알리는 구조를 생각해 보겠습니다. 이때 문제는 노션 기능의 부족만이 아닙니다. 어느 채널이 접수 기준인지, 누가 우선순위를 정하는지, 무엇을 완료로 볼지가 분산돼 있습니다.
ISO의 프로세스 접근 자료도 문제와 관련 프로세스의 정보를 수집·분석한 뒤 해결책을 선택·실행하고, 효과를 평가하는 순서를 제시합니다. 이는 업무 시스템을 고르기 전에 현행 흐름을 파악해야 개선 대상과 비교 기준을 세울 수 있다는 뜻으로 볼 수 있습니다. 다만 모든 업무를 같은 깊이로 문서화할 필요는 없습니다. 단순하고 변경이 적은 업무라면 핵심 흐름, 예외, 책임자만 간략히 정리해도 됩니다.
대표나 운영 담당자가 먼저 답할 질문은 세 가지입니다.
- 업무는 어떤 사건으로 시작하는가: 고객 요청, 계약 체결, 내부 계획 승인처럼 시작 신호를 하나로 정합니다.
- 누가 무엇을 결정하는가: 담당자가 처리하는 일과 승인자가 판단하는 일을 구분합니다.
- 무엇이 완료를 증명하는가: 단순히 ‘완료’ 상태를 누르는 것이 아니라 산출물, 확인 기록, 다음 단계 인계 중 무엇이 필요한지 정합니다.
흐름을 적어 보면 “툴을 바꾸자”는 요구가 다른 문제를 가리키는 경우가 많습니다. 알림이 누락된다면 알림 규칙이 필요할 수 있고, 승인 대기가 길다면 권한과 승인 단계가 문제일 수 있습니다. 반대로 업무 흐름은 안정적이고 문서 탐색만 불편하다면 전면적인 시스템 전환보다 기존 도구의 구조를 정리하는 편이 나을 수 있습니다.
업무 흐름은 어디까지 그려야 AX 전환 범위를 정할 수 있을까요?
모든 업무를 한 번에 모델링할 필요는 없습니다. 반복 빈도가 높고 담당자 사이 인계가 있으며, 누락됐을 때 운영 부담이 큰 업무부터 한 흐름씩 정리하면 됩니다.
처음부터 전사 업무를 도식화하면 회의만 길어질 수 있습니다. 대신 매주 또는 매일 되풀이되고 여러 사람이 관여하는 업무 하나를 고르세요. 프로젝트 요청 관리, 견적·계약 후 실행 관리, 휴가 승인, 증명서 발급처럼 시작과 종료가 비교적 분명한 업무가 적합합니다.
제가 사내 시스템을 설계할 때도 업무 화면을 늘리는 방식보다 하나의 데이터 모델을 여러 화면에서 보게 하는 방식을 우선했습니다. 칸반에서 바꾼 업무 상태가 캘린더나 문서 관리에서 따로 수정되지 않도록 하는 식입니다. 이것이 모든 회사에 같은 구현을 권한다는 뜻은 아닙니다. 다만 같은 상태를 여러 사람이 여러 도구에서 수정한다면, 어떤 도구를 쓰든 충돌 가능성을 먼저 점검해야 한다는 실무 기준입니다.
다음 표는 업무 하나를 정리할 때 사용할 수 있는 최소 단위입니다.
| 확인 항목 | 적어 볼 내용 | 정리되지 않았을 때 생기는 문제 |
|---|---|---|
| 시작 조건 | 어떤 요청·승인·일정이 업무를 시작시키는가 | 업무가 구두 지시나 개인 기억에 남음 |
| 담당자 | 실행자와 최종 결정자는 누구인가 | 확인 요청이 여러 사람에게 반복됨 |
| 상태 | 대기·진행·검토·완료를 어떻게 나눌 것인가 | ‘진행 중’의 의미가 사람마다 달라짐 |
| 기준 데이터 | 고객 정보, 일정, 문서 중 어디가 원본인가 | 같은 정보가 서로 다르게 수정됨 |
| 종료 조건 | 어떤 결과물 또는 승인으로 끝나는가 | 완료 뒤 재작업과 책임 공방이 생김 |
같은 업무의 원본 데이터가 둘 이상이라면, 자동화보다 먼저 원본을 하나로 정하는 편이 낫습니다. 자동화는 정리된 규칙을 빠르게 실행하는 수단이지, 충돌하는 기준 가운데 하나를 골라 주는 장치가 아닙니다.
반복 업무는 무엇을 규칙으로 만들고, 무엇을 AI에 맡겨야 할까요?
판정 기준이 명확한 업무는 규칙과 코드로 처리하고, 설명·초안·요약처럼 맥락 판단이 필요한 일은 AI가 보조하도록 나누는 편이 운영 기준을 지키기 쉽습니다.
AX를 AI를 업무 곳곳에 붙이는 일로 이해하면 도입 범위가 불필요하게 커질 수 있습니다. 먼저 사람이 같은 방식으로 반복 판정하는 지점을 찾는 편이 낫습니다. 신청 조건 확인, 권한에 따른 접근 제한, 상태 변경, 정해진 양식의 증명서 발급은 규칙이 명확한 편입니다. 반면 회의 내용을 요약하거나 업무 맥락을 설명하고 문서 초안을 만드는 일은 AI 보조가 어울릴 수 있습니다.
저는 사내 시스템에서 AI가 규칙을 최종 판정하는 구조보다, 정해진 규칙은 시스템이 처리하고 AI는 해설과 생성 역할을 맡는 방향을 선택했습니다. AI의 답변이 유용하더라도 권한, 승인, 상태 변경처럼 결과가 업무 기록에 직접 영향을 주는 영역은 별도의 운영 기준이 필요하기 때문입니다.
역할 기반 접근통제(RBAC)는 개인마다 권한을 하나씩 부여하기보다 역할에 권한을 묶고, 사용자를 필요한 역할에 배정하는 방식입니다. 역할 계층과 제약 조건을 두면 권한 분리나 업무상 충돌을 관리하는 데 활용할 수 있습니다. 다만 RBAC만으로 객체별·데이터별 접근 조건과 모든 예외를 해결할 수 있는 것은 아니므로, 리소스 범위와 예외 승인 절차는 별도로 정해야 합니다.
최소 권한 원칙은 사용자가 맡은 업무에 필요한 범위의 접근만 받도록 하는 기준입니다. NIST는 역할 또는 사용자 집합에 부여된 권한을 조직이 정한 주기에 따라 검토하고, 더는 필요하지 않은 권한은 재배정하거나 제거하도록 제시합니다. 이는 특정 보안 통제 체계를 위한 요구사항이므로 모든 민간 업무 시스템에 같은 방식으로 적용해야 한다는 뜻은 아니지만, 권한 승인·검토·회수 절차를 설계할 때 참고할 기준이 됩니다.
실무에서는 다음처럼 나누면 논의가 선명해집니다.
- 규칙으로 고정할 일: 누가 볼 수 있는지, 어떤 조건에서 상태가 바뀌는지, 어떤 정보가 필수인지
- 자동화할 일: 정해진 시점의 알림, 반복 생성, 정해진 양식의 문서 처리
- AI가 보조할 일: 문서 초안, 업무 요약, 맥락 설명, 다음 확인 항목 제안
- 사람이 최종 결정할 일: 우선순위 변경, 예외 승인, 고객·조직에 영향을 주는 중요한 판단
이 구분은 AI 기능을 줄이자는 주장이 아닙니다. AI가 잘하는 일을 실제 운영 규칙 위에 얹어야 담당자가 바뀌어도 업무가 개인의 사용 감각에만 의존하지 않습니다.
새 시스템으로 옮길 기능은 어떻게 우선순위를 정해야 할까요?
첫 전환 범위에는 업무 흐름을 끊김 없이 잇는 최소 기능만 넣어야 합니다. 불편하지만 업무가 돌아가는 기능과, 없으면 흐름 자체가 멈추는 기능을 구분하는 것이 핵심입니다.
기능 목록은 대개 빠르게 길어집니다. 검색, 대시보드, 각종 통계, 세부 알림, 개인별 보기 설정은 모두 있으면 좋습니다. 하지만 첫 단계에서 더 중요한 것은 접수부터 완료까지 한 업무가 기준 데이터 하나를 따라 처리되는지입니다.
기능 우선순위는 다음 질문으로 정리할 수 있습니다.
- 이 기능이 없으면 업무가 멈추는가, 아니면 불편한가?
- 여러 사람이 같은 데이터를 수정하거나 확인해야 하는가?
- 현재 누락·재입력·확인 대기가 반복되는가?
- 예외 상황이 잦아 처음부터 복잡한 설정이 필요한가?
- 기존 도구를 정리해서 해결할 수 있는가, 별도 시스템이 필요한가?
다섯 번째 질문이 특히 중요합니다. 노션 데이터베이스 구조, 템플릿, 권한, 알림 규칙을 정리하면 해결될 문제라면 교체가 답이 아닐 수 있습니다. 반대로 여러 도구를 넘나들며 같은 상태를 반복 입력하고, 업무 규칙이 도구의 한계 때문에 유지되지 않는다면 통합 시스템을 검토할 근거가 생깁니다.
AX 전환의 첫 목표는 기능 수를 늘리는 것이 아니라, 가장 자주 반복되는 업무 한 가지를 예측 가능하게 끝내는 것입니다.
결론
노션을 바꾸기 전 먼저 해야 할 일은 어떤 도구가 더 좋은지 비교하는 일이 아닙니다. 반복 업무 하나를 골라 시작 조건, 담당자, 상태, 원본 데이터, 종료 조건을 정리해 보세요.
그 과정에서 기존 도구로 해결할 수 있는 문제와 새 시스템이 필요한 문제가 갈립니다. 규칙이 명확한 일은 시스템과 자동화로 고정하고, AI는 문서 작성과 맥락 설명처럼 사람의 판단을 보조하는 역할부터 맡기는 편이 좋습니다. 업무 흐름이 먼저이고, 도구와 AI는 그 흐름을 실행하는 수단입니다.
자주 묻는 질문
노션을 계속 써도 되는 판단 기준은 무엇인가요?
반복 업무의 원본 데이터와 담당·완료 기준을 노션 안에서 일관되게 관리할 수 있다면 계속 사용해도 됩니다. 페이지 수가 많거나 보기 방식이 불편하다는 이유만으로 전면 교체를 결정할 필요는 없습니다.
업무 흐름 정리는 대표가 직접 해야 하나요?
최종 우선순위와 승인 기준은 대표가 정하되, 실제 흐름은 업무를 수행하는 담당자와 함께 확인해야 합니다. 실행자가 겪는 예외와 재작업 지점이 빠지면 문서상 흐름만 남을 수 있습니다.
AI 어시스턴트부터 도입하면 안 되나요?
도입할 수는 있지만, AI가 참조할 업무 상태와 문서 기준을 먼저 정리해야 활용 범위가 명확해집니다. 특히 권한, 승인, 상태 변경처럼 기록에 영향을 주는 업무는 AI 답변과 별개로 운영 규칙을 마련하는 편이 좋습니다.
모든 부서의 업무를 한 번에 시스템화해야 하나요?
아니요. 인계가 많고 누락됐을 때 운영 부담이 큰 반복 업무 하나부터 시작하는 편이 현실적입니다. 첫 흐름에서 상태와 데이터 기준을 확인한 뒤 다음 업무로 넓혀 가면 변경 범위를 관리하기 쉽습니다.
제 도움이 필요하시다면
크로플은 사내 업무 흐름을 바탕으로 웹·앱·업무 시스템을 설계하고 개발합니다. 반복 업무가 여러 도구에 흩어져 원본 데이터와 책임 범위를 다시 잡아야 하는 경우, 현재 방식에서 유지할 부분과 별도 시스템으로 옮길 부분을 함께 정리할 수 있습니다.
특히 다음 상황이라면 논의할 만합니다.
- 업무 요청, 일정, 문서, 완료 보고가 서로 다른 도구에 나뉘어 있는 경우
- 담당자마다 업무 상태를 다르게 기록해 확인 비용이 커지는 경우
- 규칙 기반 자동화와 AI 보조 기능의 경계를 정하지 못한 경우
아래 관리형 연락 카드로 현재 사용 중인 도구와 가장 자주 막히는 업무 흐름을 알려 주세요. 처음부터 기능 목록을 받기보다, 그 업무가 시작해서 끝나는 과정을 기준으로 검토하겠습니다.
