외주로 만든 시스템이 1년 뒤 방치되는 이유

Bottom line

시스템 구축의 성패는 개발 품질보다 소유권에서 갈립니다. 회사 안에 주인이 없는 시스템은 아무리 잘 만들어도 1년 뒤 방치됩니다. 자체 ERP를 10년 운영하면서, 그리고 여러 외주 프로젝트를 옆에서 지켜보면서 확인한 차이입니다.

주인 없는 시스템을 사는 건 시스템이 아니라 한 번 쓰는 납품물을 사는 것입니다.

오픈 날이 정점인 시스템

외주 프로젝트의 목표는 대부분 오픈입니다. 오픈식을 하고, 보고서를 쓰고, 검수를 끝내면 프로젝트는 성공으로 기록됩니다.

문제는 그다음입니다. 업무는 계속 바뀝니다. 거래처가 늘고, 정산 기준이 바뀌고, 새 예외가 생깁니다. 그런데 시스템은 오픈 날에 멈춰 있습니다. 수정 요청은 견적이 되고, 견적은 품의가 되고, 품의는 보류됩니다. 그 사이 현장은 답답하니까 엑셀을 다시 엽니다. 시스템은 남아 있는데 업무는 이미 밖으로 나간 거죠. 방치가 그렇게 시작됩니다.

방치의 신호는 일찍 옵니다

방치는 1년 뒤에 갑자기 오지 않습니다. 신호는 오픈 두세 달 안에 옵니다.

첫 신호는 수정 요청 목록이 늘기만 하고 줄지 않는 것입니다. 두 번째 신호는 현장에서 시스템 밖 파일이 다시 도는 것입니다. 정리용 엑셀, 보조 장부, 단톡방 공지 같은 것들요. 세 번째 신호는 아무도 시스템 숫자를 믿지 않게 되는 것입니다. 시스템 숫자와 현장 숫자가 다른데 고칠 사람이 없으면, 회의는 숫자 맞추기부터 시작됩니다.

이 세 신호가 나타나면, 시스템 기능의 문제보다 소유권 문제가 있는 건 아닌지 먼저 따져봐야 합니다.

살아남는 시스템의 조건

제가 만든 ERP가 10년을 산 이유는 코드가 훌륭해서가 아닙니다. 업무가 바뀔 때마다 시스템을 따라 고칠 손과 권한이 회사 안에 있었기 때문입니다.

내재화라고 하면 개발자 채용부터 떠올리는데, 사람보다 소유권이 먼저입니다. 우리 업무 규칙이 어떻게 시스템에 들어가 있는지 아는 사람, 바꿀 수 있는 권한, 바꾸는 데 드는 비용 구조. 셋이 안에 있어야 시스템이 업무를 따라갑니다.

외주를 쓰더라도 지킬 것

외주 자체가 나쁜 게 아닙니다. 저도 씁니다. 다만 계약할 때 이것들은 내부에 남겨야 합니다.

• 데이터 구조와 업무 규칙 문서는 내부 소유로 명시합니다.
• 소스와 수정 권한을 확보합니다.
• 오픈 이후의 운영 담당자와 변경 예산을 오픈 전에 정합니다.

이게 없으면 시스템이 아니라 한 번 쓰는 납품물을 사는 것입니다.

지금은 문턱이 낮아졌습니다

예전에는 고칠 손을 안에 두는 게 비쌌습니다. 지금은 AI 코딩 도구 덕분에 그 문턱이 크게 낮아졌습니다. 비개발 조직도 자기 시스템의 작은 수정은 직접 할 수 있는 환경이 됐습니다. 실제로 제가 그렇게 일하고 있고요.

벤더가 소스를 안 준다고 하면

소스와 수정 권한을 요구하면 벤더가 거절하지 않느냐는 질문을 받습니다. 협상 항목입니다. 소스 공동 소유, 에스크로 예치, 일정 기간 후 이관 같은 조항은 업계에서 낯선 것이 아닙니다. 비용이 조금 붙을 수는 있습니다.

그런데 이 요구를 아예 받아 주지 않는 벤더라면, 그게 걸러야 할 신호라고 봅니다. 오픈 이후의 관계를 처음부터 견적 장사로 설계하고 있다는 뜻이니까요. 좋은 벤더는 이관 조건을 명확히 하는 계약을 오히려 반깁니다.

체크 질문

• 작년에 구축한 시스템, 올해 몇 번 수정됐나요.
• 우리 업무 규칙 문서를 벤더가 아니라 우리가 갖고 있나요.
• 시스템 수정 요청이 처리되기까지 평균 며칠 걸리나요.