제조업에서 새로운 소프트웨어를 도입할 때 SI 방식은 익숙합니다. 필요한 기능을 정하고, 업체가 고객 환경에 맞춰 개발하고, 프로젝트가 끝나면 인수합니다. 고객마다 공장 시스템이 다르니 자연스러운 선택인 경우도 많습니다.
다만 매일 양산에서 쓰고 여러 공정과 장비로 계속 확장해야 하는 소프트웨어라면 이야기가 달라집니다. 고객별로 하나씩 새로 만들기 시작하면 시간이 갈수록 코드와 운영 방식이 갈라지고, 업데이트와 지원도 프로젝트 단위로 쪼개집니다.
SI가 안전해 보여도
프로젝트가 끝난 뒤부터
차이가 커집니다
대기업 입장에서 작은 소프트웨어 회사를 선택하는 일은 부담스럽습니다. 공급사가 몇 년 뒤에도 남아 있을지, 장애가 생겼을 때 누가 대응할지, 담당자가 바뀌어도 계속 지원받을 수 있을지 확인해야 합니다. 규모가 큰 SI 업체가 상대적으로 편하게 느껴지는 이유입니다.
이 우려는 합리적입니다. 다만 회사 규모만으로 장기 운영 안정성을 판단하기도 어렵습니다. 오래 써야 하는 시스템이라면 같은 제품이 계속 유지되고 업데이트되는 구조인지도 함께 봐야 합니다.
SI 프로젝트는 계약한 범위의 시스템을 완성하는 데 최적화되어 있습니다. 반면 제품 회사는 하나의 소프트웨어를 여러 고객이 계속 쓰도록 만들어야 합니다. 버그 수정, 기능 개선, 버전 관리, 문서화, 호환성 유지가 다음 계약이 아니라 제품 자체의 일입니다.
제품형이어도
도입과 운영 체계는 필요합니다
공장마다 데이터 구조, 보안 정책, MES·
제품형 소프트웨어의 도입 작업은 이미 있는 제품을 고객 환경에 배포하고 필요한 연결과 설정을 맞추는 데 집중합니다. 고객마다 핵심 소프트웨어를 새로 만들기 시작하면 다음 공정이나 사이트에서도 비슷한 개발을 다시 해야 합니다.
스타트업이라는 이유만으로 공급 리스크가 사라지지는 않습니다. 오히려 작은 회사일수록 고객이 특정 개발자나 프로젝트 팀에 의존하지 않도록 제품과 지원 체계를 만들어야 합니다.
그래서 on-premise 운영 방식과 버전 관리, 문서화된 설정·
SI가 필요한 일과
제품이 필요한 일을 구분합니다
Amfibian은 같은 제품을 고객 환경에 배포합니다. 필요한 도입과 연동 작업을 진행한 뒤에도 제품 업데이트와 운영 지원을 계속 이어갑니다.
요금 구조도 Software Subscription, Deployment & Integration, Enterprise Support로 나눕니다. 구축 서비스는 제품을 실제 생산 환경에서 쓰는 데 필요한 범위에 집중합니다.
일회성 시스템 구축이나 고객 고유 업무를 그대로 구현하는 일이 목적이라면 SI가 더 적합할 수 있습니다. 반대로 공정 제어처럼 같은 기능을 오랫동안 운영하고 여러 장비와 라인으로 넓혀야 한다면 제품의 지속적인 유지보수와 반복 배포 능력이 중요합니다.
Amously는 공정 제어 소프트웨어를 이런 방식으로 운영합니다. 고객 환경에 맞춘 도입 작업은 하되, 핵심 소프트웨어는 하나의 제품으로 계속 발전시킵니다.