이 글의 핵심
- 외주 시스템이 방치되는 건 개발 품질 문제가 아닙니다. 오픈 이후 수정을 맡을 사람과 권한이 회사 안에 없기 때문입니다.
- 첫 신호는 오픈 두세 달 만에 나타납니다. 수정 요청이 쌓이고, 엑셀이 다시 돌고, 시스템 숫자를 아무도 믿지 않게 됩니다.
- 계약서에서 세 가지만 확보하면 달라집니다. 업무 규칙 문서 소유권, 소스 코드와 수정 권한, 오픈 이후 담당자와 운영 예산입니다.
외주로 시스템을 구축할 때 성공 기준은 대부분 오픈입니다. 오픈식을 치르고 검수를 끝내면 사업은 성공으로 기록됩니다. 그리고 1년 뒤 현장에 가 보면, 시스템은 그대로인데 일은 다시 엑셀로 돌아가 있습니다.
개발 품질 문제를 먼저 의심하기 쉽습니다. 저도 처음에는 그랬습니다. 직접 만든 ERP를 10년 운영하고, 여러 외주 프로젝트를 가까이서 지켜보면서 내린 결론은 다릅니다. 소유권 문제입니다. 수정할 손과 권한이 회사 안에 없으면, 잘 만든 시스템도 방치됩니다.
오픈이 끝인 프로젝트는 오픈 날이 가장 잘 작동합니다
외주 프로젝트의 목표는 오픈입니다. 계약도, 일정도, 검수도 오픈을 기준으로 설계됩니다. 벤더와 의뢰사의 이해가 딱 맞는 순간이기도 합니다.
오픈 이후가 문제입니다. 거래처가 늘고, 정산 기준이 바뀌고, 예외 케이스가 생깁니다. 시스템은 오픈 날 상태로 멈춰 있는데 업무는 계속 움직입니다. 수정 요청을 넣으면 견적이 나오고, 견적은 품의가 되고, 품의는 보류됩니다. 그 사이 현장은 기다릴 수 없으니 엑셀을 다시 엽니다. 시스템은 로그인 화면만 남고, 일은 밖으로 나갑니다.
수정 한 건에 견적을 받고 품의를 올리는 과정이 반복되면, 현장에서는 시스템을 쓰지 않는 쪽이 더 빠른 선택이 됩니다. 구조가 그렇게 설계돼 있어서입니다.
방치의 신호 세 가지는 오픈 두세 달 안에 나타납니다
방치가 1년 뒤에 갑자기 완성되는 것처럼 보이지만, 신호는 훨씬 일찍 옵니다. 오픈 두세 달이 안 됐는데 아래 세 가지가 보이기 시작한다면, 운영 구조를 점검할 시점입니다.
첫째, 수정 요청 목록이 줄지 않습니다. 새 요청이 들어오는 속도보다 처리 속도가 느리면 목록은 쌓이기만 합니다. 두 달이 지나도 첫 달 요청이 그대로라면, 내부에 소유권 구조가 없다는 신호입니다.
둘째, 시스템 밖 파일이 다시 돌기 시작합니다. 정리용 엑셀, 보조 장부, 단체 채팅방 공지가 늘어납니다. 현장이 시스템을 쓰기 불편하거나 믿지 못한다는 뜻입니다.
셋째, 회의에서 시스템 숫자를 꺼내지 않습니다. 시스템 숫자와 현장 숫자가 달라졌는데 고칠 수 없으면, 회의는 숫자 맞추기부터 시작됩니다. 이 단계는 기능 문제가 아니라 신뢰가 무너진 상태입니다.
10년을 버틴 이유는 코드 품질이 아니었습니다
제가 만든 ERP가 10년을 산 이유를 솔직히 말씀드리면, 코드가 좋아서가 아닙니다. 업무가 바뀔 때마다 따라서 고칠 손이 회사 안에 있었습니다. 수정 결재가 별도로 필요 없었고, 담당자가 직접 판단해서 바꿨습니다.
내재화라고 하면 개발자 채용을 먼저 떠올리기 쉽습니다. 저는 사람보다 소유권이 먼저라고 봅니다. 우리 업무 규칙이 시스템에 어떻게 들어가 있는지 아는 사람, 바꿀 수 있는 권한, 바꾸는 데 드는 비용 구조. 이 세 가지가 안에 있을 때 시스템이 업무를 따라갑니다.
지금은 그 문턱이 전보다 낮아졌습니다. AI 코딩 도구 덕분에 개발 경험이 없는 조직도 자기 시스템의 작은 수정은 직접 할 수 있습니다. 저도 그렇게 일합니다. 내재화의 문턱이 낮아진 만큼, 소유권을 포기할 이유는 더 없어졌습니다.
외주를 써도 계약서에서 세 가지는 확보해야 합니다
외주 자체가 나쁜 것은 아닙니다. 저도 씁니다. 다만 계약할 때 아래 세 가지는 협상 항목으로 올려야 합니다.
첫째, 데이터 구조와 업무 규칙 문서는 내부 소유로 계약서에 명시합니다. 벤더가 문서를 갖고 있으면 담당자가 바뀔 때마다 다시 발주하는 구조가 됩니다.
둘째, 소스 코드와 수정 권한을 확보합니다. 소스 공동 소유, 에스크로 예치, 일정 기간 후 이관 같은 조항은 업계에서 낯선 것이 아닙니다. 이 요구를 거부하는 벤더라면, 오픈 이후를 처음부터 추가 견적으로 설계하고 있다는 신호입니다. 좋은 벤더는 이관 조건을 명확히 하는 계약을 오히려 반깁니다.
셋째, 오픈 이후 운영 담당자와 변경 예산을 오픈 전에 정합니다. 이 대화를 오픈 이후로 미루면 수정 건마다 별도 사업이 됩니다.
| 구분 | 납품물을 사는 계약 | 시스템을 사는 계약 |
|---|---|---|
| 업무 규칙 문서 | 벤더 보유 | 내부 소유 명시 |
| 소스와 수정 권한 | 협의 필요 | 계약서에 확보 |
| 오픈 이후 수정 | 건별 견적과 품의 | 담당자와 운영 예산 |
지금 자기 회사 시스템에 던져볼 질문
작년에 구축한 시스템이 올해 몇 번 수정됐는지 바로 말할 수 있습니까. 우리 업무 규칙 문서를 벤더가 갖고 있습니까, 우리가 갖고 있습니까. 수정 요청이 처리되기까지 평균 며칠 걸립니까.
세 질문의 답이 바로 나오지 않는 시스템이 있다면, 지금 방치 과정에 있을 가능성이 높습니다. 소유권 구조를 어떻게 잡는지는 ERP를 직접 만들며 배운 것에서 이어갑니다.