맞춤형 소프트웨어를 처음 하는 기업은 "시스템을 만들어 달라"는 것 자체를 전부로 여기는 경우가 많습니다. 성패를 가르는 것은 앞단에서 업무가 명확해졌는지, 뒤단에서 검수가 정의됐는지입니다. XYN은 지난에서 제조·유통·정부 고객에 서비스하며, 맞춤 개발을 네 단계로 나눕니다. 현황 파악, 방안 합의, 마일스톤 납품, 배포 후 안정화입니다.
먼저 구분: 도구가 필요한가, 프로세스를 고정화하려는가
Excel을 웹 표로 바꾸는 수준이면 기간이 짧고 위험도 낮으며, 성숙한 재고·OA로 충분한 경우가 많습니다. 승인 규칙, 다중 창고, 다중 역할, 재무/ERP 대사가 들어가면 범용 소프트웨어는 "조금 부족"해집니다. 그 차이가 경쟁력이거나 역사적 부담이며, 맞춤으로만 메울 수 있습니다.
착수 시 세 문장을 쓰세요. 누가 매일 쓰는지, 해결하지 않으면 무엇을 잃는지, 배포 후 성공 기준이 무엇인지. 이 세 줄이 기능 목록보다 범위를 잘 묶습니다. "창고 책임자의 일일 재고 시간을 반나절에서 한 시간으로"는 "창고 시스템 구축"보다 검수하기 쉽습니다.
요구사항 조사는 회의록이 아니라 그릴 수 있어야 한다
조사 단계에서 가장 피해야 할 것은 소망만 모으는 것입니다. 효과적인 조사는 업무를 한 경로로 그립니다. 누가 시작하고, 어떤 노드를 거치며, 어떤 전표가 생기고, 어느 테이블에 데이터가 들어가며, 예외 시 어떻게 되돌리는지. XYN은 보통 착수 전에 세 가지를 산출합니다.
- 역할과 권한: 누가 보기·수정·내보내기만 할 수 있는지.
- 주 흐름과 예외 흐름: 정상 전표, 반품, 취소, 보전표 각각의 경로.
- 외부 시스템 연동 목록: 재무, 결제, 배송, WeCom/DingTalk—마스터 데이터와 동기 방향을 먼저 표시.
이 세 가지가 있으면 프로토타입은 "예쁜 화면"이 아니라 개발 가능한 사양이 됩니다. 프로토타입 단계에서 필드명이 여전히 쟁점이면 조사가 끝나지 않은 것—인일로 개발자를 쌓지 마세요.
개발은 마일스톤으로, "다 만들고 보여드리겠습니다"가 아니다
맞춤 프로젝트 지연의 흔한 원인은 범위 확장입니다. 데모 때 보고서 추가, 배포 전 승인 추가. 계약은 마일스톤 단위로 자르는 것이 좋습니다. 예: 마스터 데이터와 권한 → 핵심 전표 폐루프 → 보고서와 연동 → 시운전. 각 구간에 시연 가능한 결과가 있어 이해 차이를 일찍 발견합니다.
기술적으로 기업 시스템은 이후 모듈 추가 여지가 필요합니다. 통합 사용자 센터, 통합 승인 흐름, 통합 알림. 화면은 단계적으로 올릴 수 있지만, 기반을 처음부터 따로 만들면 이후 수정이 혼란스러워집니다.
배포는 종점이 아니다: 데이터 이전, 교육, 품질보증
구 데이터가 이전되지 않으면 새 시스템은 공회전합니다. 이전 전 합의: 이력 전표를 언제까지 남길지, 코드 규칙을 재작성할지, 잔액 데이터의 기준이 어느 쪽인지. 구 시스템과 짧게 병행 운영하고, 대사가 통과한 뒤 주 흐름을 전환합니다.
교육은 역할별로. 전원에게 백엔드를 한 번 보여주는 방식이 아닙니다. 창고, 재무, 경영진은 같은 메뉴를 보지 않습니다. 품질보증 기간에는 결함을 치명·중대·일반으로 분류하고 대응 SLA를 명시—"1년 무상 유지보수"보다 실행 가능합니다.
착수 전 최단 체크리스트
- 성공 기준을 "더 쓰기 쉽다"가 아니라 업무 지표로 말할 수 있는가.
- 연동처가 합의됐는가—개발 중간에 필드가 없어 막히지 않는가.
- 범위를 확정할 내부 책임자가 있는가—누구나 요구사항을 추가하지 않는가.
- 검수에 백업 복구, 권한 spot check, 핵심 경로 부하 테스트가 포함되는가—데모만이 아닌가.
맞춤 개발에 비밀 방법은 없습니다. 핵심은 불확실한 업무를 단계적으로 검증 가능한 사양으로 바꾸는 것입니다. XYN은 코드보다 먼저 합의를 고집합니다. 기업 시스템을 검토 중이면 현행 프로세스와 pain point를 보내주세요—제품 구매, MVP, 전체 맞춤 중 무엇이 맞는지 먼저 판단합니다.