자동화 상담에서는 거의 언제나 같은 두 가지 질문이 나옵니다. 첫째는 데이터가 어디로 가는지, 둘째는 이것입니다. "언제 결과를 볼 수 있습니까?"
정직한 대답은 하나의 숫자가 아니며, 숫자를 제시하는 쪽은 조심해서 보는 편이 좋습니다. 같은 일이라도 두 회사에서 걸리는 시간은 크게 다를 수 있습니다. 차이는 기술이 아니라 회사가 얼마나 준비되어 있는지에 있습니다.
이 글은 기간을 결정하는 요인, 구축이 거치는 단계, 그리고 진행 여부를 어떻게 판단하는지를 다룹니다. 목표는 일정표를 주는 것이 아니라 어디를 봐야 하는지 보여주는 것입니다.
⏱️ 기억할 점: 자동화의 기간은 기술적 난이도보다 업무 절차가 얼마나 분명하게 정의되어 있는지에 더 좌우됩니다. 단계가 문서로 정리되고 예외가 파악된 절차는 빠르게 만들어집니다. 사람마다 방식이 다른 절차에서는 시간의 대부분이 구축이 아니라 절차를 분명히 하는 데 들어갑니다.
왜 아무도 확정된 기간을 말하지 못하는가
구축에서 눈에 보이는 부분은 시스템 자체입니다. 트리거, 단계, 연결. 이 부분은 대체로 예측할 수 있습니다. 예상 밖의 일은 보이지 않는 부분에서 나옵니다.
보이지 않는 부분은 절차가 실제로 어떻게 돌아가는가입니다. 종이 위에서 다섯 단계로 보이는 일이 현장에서는 열다섯 개의 예외를 품고 있을 수 있습니다. 이 예외들은 구축 도중 하나씩 드러나고, 각각 판단을 요구합니다.
그래서 진지한 제안은 기간을 하나의 숫자가 아니라 단계로 설명합니다. 각 단계가 언제 끝나는지는 앞 단계의 결과물에 달려 있습니다.
기간을 결정하는 다섯 가지 요인
절차가 얼마나 자리 잡았는가
매달 형태가 바뀌는 일을 자동화하는 것은 매달 다시 만드는 일입니다. 절차가 안정되기 전에 시작하면 시간은 구축이 아니라 수정에 들어갑니다. 기간을 가장 크게 늘리는 요인입니다.
무엇을 해야 하나: 구축 전에 절차를 단계별로 적어 두십시오. 그 자체가 가장 큰 가속 요인입니다. 어디서 시작할지는 다섯 단계 디지털 전환 글이 안내해 줄 수 있습니다.
예외의 수
"보통은 이렇게 하는데 그 경우에는 다릅니다"라는 말이 몇 번 나오는지가 기간에 그대로 반영됩니다. 예외 하나하나가 시스템 안의 별도 경로입니다. 예외가 적은 절차는 빠르게 만들어지고, 많은 절차는 먼저 단순하게 다듬는 편이 좋습니다.
무엇을 해야 하나: 하나의 절차로 시작하십시오. 다섯 개를 동시에 만드는 것은 하나를 끝내고 다음으로 넘어가는 것보다 느립니다. 절차 정리를 실습으로 익히고 싶다면 교육 시리즈가 단계별로 이어집니다.
데이터의 상태
데이터가 한곳에 정리되어 있으면 구축이 빨라집니다. 절반은 표에, 절반은 수첩에, 일부는 누군가의 휴대전화에 있다면 먼저 모으는 일이 필요합니다. 이 일은 자동화보다 앞서고 기간에 더해집니다.
무엇을 해야 하나: 구축을 기다리지 말고 모으는 일부터 시작하십시오. 길어지는 것은 구축이 아니라 그 앞의 준비입니다.
몇 개의 시스템이 연결되는가
한곳에서 시작해 한곳에서 끝나는 흐름은 빠르게 만들어집니다. 웹 양식, 메신저, 표, 일정, 회계 프로그램을 서로 연결해야 한다면 각 연결이 별개의 일이고 저마다 예상 밖의 문제를 품을 수 있습니다.
무엇을 해야 하나: 첫 회차에는 연결 수를 제한하십시오. 시스템이 돌아가기 시작하면 더 붙일 수 있습니다.
누가 맡을 것인가
회사 쪽에서 이 일을 맡는 사람이 없으면 구축은 계속 기다립니다. 질문에 답하고, 결정하고, 시험해야 합니다. 이를 할 사람이 없으면 기술 쪽이 준비되어도 일은 나아가지 않습니다.
무엇을 해야 하나: 시작 전에 담당자를 정하십시오. 질문에 답하고 결정을 내릴 한 사람이면 됩니다.
구축이 거치는 단계
기간 대신 단계를 보는 편이 더 건강한 기준입니다. 각 단계에는 고유한 결과물이 있고, 그것이 보이기 전에는 다음으로 넘어가지 않습니다.
첫째 단계: 절차 정리
누가 언제 무엇을 하는지, 어떤 정보가 어디로 가는지, 어떤 경우에 다르게 처리하는지. 이 단계의 결과물은 문서로 된 절차 지도입니다. 지도 없이 시작한 구축은 나중에 다시 하게 됩니다.
둘째 단계: 구축
여기서 시스템 자체가 만들어집니다. 트리거를 정하고, 단계를 잇고, 조건을 쓰고, 예외 경로를 엽니다. 기술적으로 가장 밀도가 높은 단계지만 대체로 가장 예측 가능한 단계이기도 합니다.
셋째 단계: 병행 운영
시스템이 돌아가지만 기존 방식도 함께 유지됩니다. 둘이 한동안 나란히 갑니다. 목적은 실제 데이터에서 시스템이 어떻게 움직이는지 보는 것입니다. 이 단계에서 예상하지 못한 입력이 드러나고 바로잡힙니다.
이 단계는 건너뛰고 싶어집니다. 일을 두 번 하는 것처럼 보이기 때문입니다. 그러나 건너뛰면 첫 오류가 실제 운영에서 일어나고 신뢰를 잃게 됩니다.
넷째 단계: 인계
기존 방식을 놓습니다. 팀이 시스템을 쓰기 시작합니다. 이 단계에서 교육, 권한 설정, 그리고 문제가 생겼을 때 무엇을 할지에 대한 안내가 전달됩니다.
다섯째 단계: 안정화
시스템이 돌아가는 동안 새로운 상황이 생깁니다. 고객이 양식을 다르게 채우고, 거래처가 형식을 바꿉니다. 이런 수정은 정상이며 한동안 이어집니다. 그 뒤 시스템이 자리를 잡습니다.
첫 효과는 언제 보이는가
눈에 보이는 첫 효과는 대개 셋째 단계, 병행 운영 중에 나타납니다. 시스템은 아직 인계되지 않았지만 이미 일의 일부를 맡기 시작합니다.
여기서 짚어둘 오해가 있습니다. 첫 효과가 시간 절약이 아닐 수 있습니다. 병행 운영 중에는 팀이 여전히 두 가지 일을 함께 하고 있습니다. 첫 차이는 대개 다른 곳에서 보입니다.
- 잊히는 일이 줄어듭니다. 알림이 돌고 있어 후속 조치가 빠지지 않습니다.
- 찾는 데 드는 시간이 짧아집니다. 정보가 한곳에 있습니다.
- 응답 지연이 줄어듭니다. 들어온 메시지가 알아서 담당자에게 갑니다.
- 같은 정보를 두 번 입력할 필요가 사라집니다.
실제 시간 절약은 인계 이후에 느껴집니다. 그 시점에 기존 방식을 놓기 때문입니다.
잘 되고 있는가, 살펴볼 신호
구축이 진행되는 동안 진척이 측정 가능해야 합니다. 다음은 잘 가고 있다는 신호일 수 있습니다.
- 각 단계에 손에 잡히는 결과물이 있고 그것이 보인다.
- 드러난 예외가 기록되고 결정된다. 쌓이지 않는다.
- 팀에서 최소 한 사람이 혼자서도 시스템을 쓸 수 있다.
- 질문이 줄어든다. 초기에 질문이 많은 것은 정상이며, 줄지 않으면 무언가 이해되지 않은 것이다.
- 구축 도중 절차 자체도 나아진다. 불필요한 단계가 드러난다.
정체 신호
다음이 보인다면 일이 막혀 있을 수 있습니다.
- 같은 결정을 여러 번 이야기하지만 내리지 않는다.
- "이것도 넣자"는 요청이 쌓이고 범위가 커진다.
- 시험할 것이 있는데 아무도 시험하지 않는다.
- 팀은 시스템을 본 적이 없고 경영진만 알고 있다.
- 예외가 나오지만 기록되지 않는다.
이 신호들은 대부분 기술이 아니라 조직의 문제이고 해법도 마찬가지입니다. 자동화 프로젝트가 막히는 이유는 자동화 프로젝트는 왜 실패하는가에서 자세히 다뤘습니다.
도구 선택이 기간에 미치는 영향
기성 패키지를 설치하는 편이 처음부터 개발하는 것보다 빠릅니다. 그러나 절차와 맞지 않으면 절차를 도구에 맞추려 하게 되고 시간은 거기서 사라집니다. 맞춤 구축은 더 오래 걸리지만 절차를 있는 그대로 받아들입니다.
올바른 선택은 작업을 줄일 수 있고, 잘못된 선택은 전체 기간을 늘릴 수 있습니다. 이 판단에는 맞춤 개발인가 기성 패키지인가의 기준이 도움이 될 수 있습니다.
저희가 일하는 방식
구축에 앞서 절차를 함께 정리하고 단계를 처음에 합의합니다. 각 단계의 결과물이 무엇인지, 누가 무엇을 결정하는지, 병행 운영은 언제 시작하는지.
기간을 하나의 숫자로 제시하지 않습니다. 대신 단계별로 나아가고 각 단계 끝에서 지금 어디에 있는지 함께 확인합니다. 어떤 단계가 예상보다 길어지면 그 이유를 말씀드립니다.
자주 묻는 질문
구축 중에 일상 업무가 지장을 받나요?
구축 자체가 일상 업무를 멈추지는 않습니다. 기존 방식이 계속 돌아가기 때문입니다. 팀의 시간이 필요한 부분은 절차 정리와 시험 단계입니다. 질문에 답하고, 사례를 보여주고, 만들어진 것을 시험해 보는 일입니다. 이 시기가 바쁜 날과 겹치면 구축이 기다리게 되므로 일정은 처음에 함께 정해 두는 편이 좋습니다.
인수인계 후에도 유지보수가 필요합니까?
네, 어떤 성격인지 알아두면 좋습니다. 연결된 서비스는 이따금 바뀌고, 들어오는 데이터 형식이 달라지며, 회사의 절차도 발전합니다. 이는 고장이 아니라 일상적인 관리입니다. 누가 관리하고 문제가 생겼을 때 어디에 연락할지는 구축 단계에서 문서로 남겨두어야 합니다.
두 번째 업무는 언제 자동화해야 합니까?
첫 시스템이 인계되고 팀이 스스로 사용하기 시작한 뒤입니다. 기준은 달력이 아니라 행동입니다. 팀이 예전 방식으로 돌아가지 않고 질문이 줄었다면 다음 업무로 넘어갈 수 있습니다. 두 구축을 겹쳐 진행하면 양쪽 모두 느려질 수 있습니다.
구축이 중간에 멈추면 무엇이 남습니까?
어느 단계에서 멈췄는지에 따라 다릅니다. 절차 지도가 만들어졌다면 그 문서는 회사에 남고 그 자체로 가치가 있습니다. 이후 어떤 도구를 쓰든 활용할 수 있습니다. 시스템 쪽에서는 만들어진 흐름과 데이터가 인계되는지 여부가 계약서에 적혀 있어야 합니다.
팀에서 누가, 얼마나 시간을 내야 합니까?
그 일을 매일 하는 사람과 결정을 내릴 수 있는 사람입니다. 앞사람은 절차를 가장 잘 알고, 뒷사람은 예외가 생겼을 때 방향을 정합니다. 두 역할이 한 사람일 수도 있습니다. 필요한 시간은 일정하지 않습니다. 절차 정리와 시험 단계에 몰리고 구축 단계에서는 줄어듭니다.
맺음말
"얼마나 걸리나"라는 물음의 답은 회사마다 다르고, 그것을 결정하는 것은 기술이 아닙니다. 절차가 얼마나 분명한지, 예외를 몇 개 안고 있는지, 데이터가 어디에 있는지, 누가 그 일을 맡는지가 함께 전체 기간을 정합니다.
그래서 일정표보다 단계를 보는 편이 낫습니다. 각 단계에 손에 잡히는 결과물을 두고, 그것이 보이기 전에는 다음으로 넘어가지 마십시오. 그러면 지금 어디에 있는지 알 수 있고 정체도 일찍 드러납니다.