이 글의 핵심
- 패키지 ERP가 현장을 못 따라갈 때는 신호가 먼저 옵니다. 담당자 책상에 시스템 외에 엑셀이 열려 있으면, 그 업무는 패키지가 감당 못 하고 있다는 뜻입니다.
- 자체 개발의 진짜 산출물은 코드가 아니었습니다. 화면 열 개를 만드는 동안 처음으로 글로 쓰인 업무 규칙 백 개가 코드보다 오래가는 자산이 됐습니다.
- 살 것인가 만들 것인가의 기준은 하나입니다. 그 업무가 우리 회사의 경쟁력 그 자체라면 패키지에 맞출 수 없습니다. 표준 업무는 사고, 경쟁력 업무는 직접 만듭니다.
우리 회사가 경쟁하는 방식 그 자체인 업무. 배차, 정산, 운행 관리처럼 거래처마다 규칙이 다르고 예외가 일상인 영역이 해당합니다. 표준 패키지에 이 업무를 맞추면 경쟁 방식이 표준에 깎입니다. 표준 업무(회계, 급여 등)와 구분하는 것이 살 것인가 만들 것인가를 정하는 첫 단계입니다.
패키지 ERP를 쓰면서 현장이 이중 장부를 쓰기 시작했을 때, 저는 그걸 현장의 나쁜 습관으로 보지 않았습니다. 시스템이 실무를 못 따라간다는 신호였습니다. 모빌리티 운영은 차량 배정, 기사 스케줄, 거래처별 정산 규칙이 회사마다 다르고 예외가 일상입니다. 상용 패키지에 그 업무를 맞추면 예외 처리가 시스템 밖으로 밀려납니다. 결국 시스템 따로, 실제 운영 따로가 됩니다.
결론부터 말씀드립니다. 자체 시스템을 만드는 일의 본질은 개발이 아니었습니다. 사람 머릿속에만 있던 업무 규칙을 끄집어내 글로 적는 일이었습니다. 화면 열 개를 만드는 동안 처음으로 글로 쓰인 업무 규칙 백 개가 코드보다 오래가는 자산이 됐습니다.
패키지를 버린 건 기술 결정이 아니라 업무 결정이었습니다
모빌리티 운영에는 표준이 없습니다. 거래처 A는 운행 건수로 정산하고, 거래처 B는 운행 시간으로 정산합니다. 배차 규칙은 기사별 계약 조건과 차량 등급이 얽혀 있습니다. 상용 패키지는 이런 예외를 흡수하지 못합니다. 흡수하려면 커스터마이징 비용이 패키지 도입 비용을 넘습니다.
그때 현장은 두 가지 중 하나를 선택합니다. 업무를 패키지에 맞게 바꾸거나, 시스템 밖에서 엑셀로 처리하거나. 첫 번째 길은 경쟁 방식을 표준에 깎아 맞추는 일이 됩니다. 두 번째 길이 이중 장부입니다.
저희 현장은 두 번째 길을 택했습니다. 몇 달이 지나자 시스템 데이터와 실제 운영 데이터가 달라졌습니다. 보고서를 믿기 어려워졌습니다. 패키지를 버린 건 그 시점이었습니다.
처음에는 커스터마이징으로 해결하려 했습니다. 두 달 넘게 벤더와 협의한 뒤에야 기본 아키텍처 자체가 우리 정산 구조와 맞지 않는다는 걸 알았습니다. 그 시간을 낭비로 보지는 않습니다. 우리 업무 구조를 처음으로 정확히 들여다보게 된 계기였습니다. 다만 그 질문을 착수 전에 먼저 던졌다면 두 달을 아꼈을 겁니다.
화면 열 개를 만드는 동안 업무 규칙 백 개가 처음으로 글로 쓰였습니다
개발을 시작하자 문제의 진짜 크기를 알았습니다. 화면 하나를 설계하려면 그 화면에서 처리할 규칙이 필요했습니다. "이 경우에는 어떻게 처리하세요?"라고 물으면 "그건 김 과장이 알아서 합니다", "원래 그냥 그렇게 해 왔어요"라는 답이 돌아왔습니다. 담당자마다 기준이 달랐고, 글로 쓰인 것이 없었습니다.
시스템을 만든다는 건 이 머릿속 방식들을 전부 말로 꺼내 하나의 기준으로 모으는 일이었습니다. 현업 담당자들이 회의실에 모여 "우리가 실제로 어떻게 하고 있는가"를 토론했습니다. 화면 열 개를 만드는 동안 뒤에서는 업무 규칙 백 개가 처음으로 글로 쓰였습니다. 개발자가 쓴 것이 아니라 현업이 합의하면서 정리한 것들이었습니다.
이 규칙 문서가 코드보다 오래가는 자산이 됐습니다. 담당자가 바뀌어도 업무가 흔들리지 않았습니다. 새 담당자 온보딩에 걸리는 시간이 눈에 띄게 줄었습니다. 코드는 시스템이 교체될 때 같이 사라지지만, 규칙 문서는 다음 시스템으로도 넘어갑니다.
반면 규칙이 정리되기 전에 화면을 만들면 구멍이 생깁니다. 운영하다 발견한 예외가 코드 수정이 아니라 별도 엑셀로 처리됩니다. 시스템은 점점 현실과 멀어집니다. 업무 병목 지도를 시스템화 전에 먼저 보는 것도 같은 맥락입니다. 예외 흐름을 사전에 파악하면 나중에 코드 밖으로 밀려나는 업무가 줄어듭니다.
10년을 버티게 한 것은 세 가지 운영 습관이었습니다
처음부터 전체를 설계하지 않았습니다. 정산 하나부터 시작했습니다. 현장이 매일 쓰면서 검증하고, 잘 된다는 걸 확인한 다음에 옆 업무로 넓혔습니다. 전체 설계를 먼저 그리고 한 번에 오픈하는 방식은 주변에서 성공하는 걸 거의 못 봤습니다. 오픈 당일 현장 저항이 생겨도 돌아갈 시간이 없기 때문입니다.
10년을 버텨낸 데는 세 가지 운영 습관이 있었습니다.
첫 번째는 현장 수정 요청을 쌓아 두지 않는 것이었습니다. 작은 요청은 그 주 안에 반영했습니다. 요청이 반영되는 경험이 쌓이면 현장은 시스템을 자기 것으로 여기고, 엑셀로 돌아가지 않습니다.
두 번째는 업무 규칙이 바뀌면 코드보다 규칙 문서를 먼저 고치는 것이었습니다. 문서와 시스템이 어긋나기 시작하면 어느 것이 맞는지 묻는 일이 늘어납니다. 그 시점부터 시스템을 믿기 어려워집니다.
세 번째는 화면 추가 요청을 일단 의심하는 것이었습니다. 화면이 느는 속도가 규칙이 정리되는 속도보다 빠르면 관리가 무너집니다. 새 기능 논의의 첫 마디는 "그 업무의 규칙을 먼저 써 오세요"였습니다.
방법론이 거창하지 않았습니다. 이 세 가지가 전부였습니다.
살 것인가 만들 것인가의 기준은 하나입니다
모든 업무를 직접 만들라는 이야기가 아닙니다. 기준은 하나입니다. 그 업무가 우리 회사의 경쟁력 그 자체인가.
회계처럼 표준화된 업무는 검증된 패키지를 사는 것이 맞습니다. 그 업무에서 우리만의 방식을 만들 이유가 없습니다. 배차, 정산, 운행 관리는 달랐습니다. 거래처마다 규칙이 다르고 그 규칙이 곧 우리의 서비스 방식이었습니다. 패키지에 맞추면 그 방식이 표준에 깎입니다. 경쟁력 업무를 통째로 외주에 맡기면 반대쪽 함정에 빠집니다. 외주로 만든 시스템이 1년 뒤 방치되는 과정은 따로 정리했습니다.
| 구분 | 표준 업무 | 경쟁력 업무 |
|---|---|---|
| 판단 | 패키지를 산다 | 직접 만든다 |
| 이유 | 검증된 표준이 더 낫다 | 표준에 맞추면 경쟁 방식이 깎인다 |
| 예시 | 회계, 급여 | 배차, 정산, 운행 관리 |
자체 개발 이야기를 하면 개발자가 없다는 반응이 먼저 나옵니다.
시스템화 작업의 8할은 규칙 정리입니다. 담당자마다 다른 기준을 하나로 모으고, 예외를 규칙으로 확정하는 일은 현업이 해야 하고 현업만 할 수 있습니다. 개발자가 대신할 수 없습니다.
나머지 2할인 개발은 문턱이 많이 낮아졌습니다. AI 코딩 도구가 나온 뒤로 비개발 조직도 정산 한 조각 정도의 도구는 직접 만들 수 있게 됐습니다. 저도 그렇게 하고 있습니다. 개발자 채용이 먼저가 아니라 규칙 정리가 먼저입니다. 대시보드에서 결정이 나오지 않는 이유도 출발점이 같습니다. 데이터를 보여주기 전에 어떤 결정을 할지부터 정해야 합니다.
담당자 책상 위에 답이 있습니다
운영 중인 시스템이 현장에 살아 있는지 확인하는 방법은 간단합니다. 담당자 책상에 시스템 외에 엑셀이 열려 있는지 보는 것입니다. 열려 있으면 그 엑셀이 담당하는 업무는 시스템이 아직 못 따라가고 있다는 신호입니다. 저는 이 방법으로 자체 ERP가 실제로 작동하고 있는지를 매번 확인했습니다.
지금 귀사의 핵심 업무 담당자 옆에는 어떤 스프레드시트가 열려 있습니까.
낡은 시스템을 언제 바꿀지 판단하는 이야기는 낡은 것과 위험한 것은 다릅니다에서 이어집니다.
시스템 도입 후 현장 정착률을 높이는 방법은 도입 비용은 계약서에 있고, 정착 비용은 어디에도 없습니다에서 이어집니다.