Bottom line
스프레드시트와 수작업을 내부 시스템으로 바꾸는 일의 본질은 개발이 아닙니다. 사람 머릿속에만 있던 업무의 실체를 끄집어내 규칙으로 만드는 일입니다. 저는 상용 ERP를 버리고 자체 ERP를 만들어 10년 넘게 운영하면서 이걸 배웠습니다.
시스템 개발의 진짜 산출물은 코드가 아니라 처음으로 글로 적힌 업무 규칙입니다.
왜 직접 만들었나
모빌리티 운영은 표준 제조업 프로세스와 다릅니다. 차량과 기사 배정, 운행 기록, 거래처별 정산 규칙이 회사마다 다르고, 예외가 일상입니다. 상용 패키지에 업무를 맞추려니 현장이 이중 장부를 쓰기 시작했습니다. 시스템 따로, 실제 업무 따로. 그때 결심했습니다. 회사 심장 같은 업무는 직접 만들어야겠다고요.
만들면서 드러난 것들
개발을 시작하자 예상 못 한 일이 벌어졌습니다. 화면을 설계하려면 규칙이 필요한데, 물어보면 담당자마다 답이 달랐습니다. "이 경우엔 어떻게 처리하세요?"라는 질문에 "그건 김 과장이 알아서..."라는 답이 돌아왔습니다.
시스템을 만든다는 건 이 머릿속 방식들을 전부 말로 꺼내 규칙으로 정리하는 일이었습니다. 화면 열 개를 만들면서 뒤에서는 업무 규칙 백 개가 처음으로 글로 적혔습니다. 코드보다 이 규칙들이 더 값진 자산이 됐습니다. 담당자가 바뀌어도 업무가 흔들리지 않게 된 겁니다.
작게 시작해서 옆으로
처음부터 전체를 만들지 않았습니다. 정산 하나부터 시작했습니다. 현장이 매일 쓰면서 검증하고, 되는 걸 확인한 다음에 옆 업무로 넓혔습니다. 이 순서가 10년을 버텨낸 이유라고 봅니다. 반대로 전체 설계를 먼저 그리고 빅뱅으로 오픈하는 프로젝트는 주변에서 성공하는 걸 거의 못 봤습니다.
10년을 버티게 한 운영 습관
오래 산 시스템에는 개발보다 운영의 습관이 쌓여 있습니다. 저희 경우 세 가지였습니다.
첫째, 현장의 수정 요청을 쌓아 두지 않았습니다. 작은 요청은 그 주 안에 반영했습니다. 요청이 반영되는 경험이 쌓이면 현장은 시스템을 자기 것으로 여기고, 엑셀로 돌아가지 않습니다.
둘째, 업무 규칙이 바뀌면 코드보다 규칙 문서를 먼저 고쳤습니다. 문서와 시스템이 어긋나는 순간부터 시스템은 믿을 수 없는 물건이 됩니다.
셋째, 화면을 늘리는 요청은 일단 의심했습니다. 화면이 느는 속도가 규칙이 정리되는 속도보다 빠르면 관리가 무너집니다.
방법론이 거창할 필요는 없었습니다. 이 세 가지 습관이 10년을 버티게 했습니다.
살 것인가 만들 것인가
모든 걸 직접 만들라는 이야기가 아닙니다. 제 기준은 하나입니다. 그 업무가 우리 회사의 경쟁력 그 자체인가. 회계처럼 표준화된 업무는 사는 게 맞습니다. 하지만 우리만의 방식이 곧 경쟁력인 업무를 패키지에 맞추면, 그 경쟁력을 표준에 깎아 맞추는 셈입니다.
| 구분 | 표준 업무 | 경쟁력 업무 |
|---|---|---|
| 판단 | 패키지를 산다 | 직접 만든다 |
| 이유 | 검증된 표준이 더 낫다 | 표준에 맞추면 경쟁력이 깎인다 |
| 예 | 회계, 급여 | 배차, 정산, 운행 관리 |
개발 인력이 없는데 가능하냐고 물으신다면
자체 개발 이야기를 하면 개발자가 없다는 답이 돌아옵니다. 두 가지만 말씀드리겠습니다.
먼저, 시스템화 작업의 8할은 개발이 아니라 규칙 정리입니다. 담당자마다 다른 기준을 하나로 모으고, 예외를 규칙으로 승격하는 일은 현업이 해야 하고 현업만 할 수 있습니다.
나머지 2할은 문턱이 많이 낮아졌습니다. AI 코딩 도구가 나온 뒤로는 비개발 조직도 정산 한 조각 정도의 도구는 직접 만들 수 있게 됐습니다. 저부터 그렇게 일하고 있습니다. 개발자 채용이 아니라 규칙 정리에서 시작하면 됩니다.
체크 질문
- 지금 스프레드시트로 버티는 업무 중 규칙을 물으면 답이 갈리는 업무는 무엇인가요.
- 그 업무는 표준 업무인가요, 우리 경쟁력인가요.
- 시스템화한다면 어느 한 조각부터 시작하겠습니까.