복잡한 업무시스템의 난도는 화면 수로 판단하기 어렵습니다. 같은 등록 화면이라도 승인 단계, 권한, 기준정보의 유효기간, 외부 시스템 연동, 마감 이후의 보정 방식이 붙으면 완전히 다른 문제가 됩니다. 개발사를 비교할 때도 인원 수와 단가보다 이 복잡성을 어떻게 발견하고 통제하는지를 봐야 합니다.
업무 상태에 대한 이해
좋은 제안은 메뉴 목록을 곧바로 개발 공수로 바꾸지 않습니다. 먼저 한 업무가 어떤 상태를 거치는지, 상태를 바꿀 수 있는 주체는 누구인지, 실패하거나 되돌릴 때 어떤 기록을 남겨야 하는지 묻습니다.
예를 들어 작업지시 기능은 단순한 등록·수정·삭제가 아닙니다. 초안, 승인 요청, 승인, 배정, 진행, 완료, 반려, 취소가 있고 각 상태에서 허용되는 행위가 다릅니다. 완료 후 수정이 가능하다면 원본과 수정 이력을 함께 보존할지도 결정해야 합니다. 후보 개발사가 이런 질문을 하지 않는다면 견적에 핵심 난도가 빠져 있을 가능성이 큽니다.
데이터 경계와 기준 확인
업무시스템에서는 화면보다 데이터의 소유권이 오래 남습니다. 다음 항목을 어떻게 정의할지 확인해야 합니다.
- 고객, 조직, 설비, 품목 같은 기준정보의 원본 시스템
- 코드가 변경되거나 조직이 개편될 때 과거 기록을 해석하는 방법
- 외부 연동 데이터와 내부 확정 데이터의 구분
- 삭제 대신 비활성화하거나 이력을 보존해야 하는 대상
- 동일 데이터가 충돌했을 때 우선하는 기준
개발사가 ERD를 그릴 수 있다는 말만으로는 부족합니다. 왜 하나의 개념을 분리하거나 합쳤는지, 변경 이력을 어디에 둘 것인지 설명할 수 있어야 합니다.
행위 중심의 권한 설계
현장 시스템의 권한은 관리자와 사용자 두 종류로 끝나지 않습니다. 조회 범위, 등록, 승인, 취소, 데이터 보정, 파일 반출처럼 행위별로 나뉘고 소속 조직이나 담당 설비에 따라 대상 범위도 달라집니다.
선정 과정에서는 실제 역할 두세 개를 골라 권한 표를 만들어 보게 하는 것이 좋습니다. 개발사가 화면 숨김만 말하는지, 서버에서 행위와 데이터 범위를 함께 검증하는지 확인할 수 있습니다. 감사 로그에 누가, 언제, 무엇을, 어떤 값에서 어떤 값으로 바꿨는지도 포함되는지 물어야 합니다.
예외 흐름 확인
요구사항 회의에서는 정상적인 사용 순서만 설명하기 쉽습니다. 실제 비용은 예외에서 발생합니다.
- 승인자가 부재하면 누가 대신 처리하는가
- 외부 연동은 성공했지만 내부 저장이 실패하면 어떻게 복구하는가
- 이미 마감된 기간의 오류를 누가 어떤 절차로 보정하는가
- 동일 작업이 두 번 요청되면 중복을 어떻게 막는가
- 첨부파일이 손상되거나 업로드가 중단되면 상태를 어떻게 표시하는가
- 배치 작업이 일부만 처리하고 멈추면 어디서부터 다시 시작하는가
경험 있는 개발사는 모든 답을 처음부터 알고 있지는 않아도, 결정해야 할 예외를 목록으로 만들고 업무 담당자에게 확인합니다.
견적에 포함된 운영·인수 조건
개발 완료는 운영 가능 상태와 같지 않습니다. 저장소 소유권, 개발·검수·운영 환경, 배포 자동화, 비밀정보 관리, 백업과 복구, 로그 조회, 장애 알림, 관리자 기능이 범위에 들어 있는지 확인해야 합니다.
특히 특정 담당자의 로컬 PC에서만 빌드되거나 수동 절차에 의존하면 인수 이후 비용이 급격히 커집니다. 계약 전 최소한 다음 결과물을 명시하는 편이 안전합니다.
- 소스 저장소와 브랜치·리뷰 규칙
- 환경별 설정과 배포 절차
- 데이터베이스 마이그레이션 이력
- API와 외부 연동 명세
- 운영 점검표와 장애 대응 절차
- 테스트 계정, 테스트 데이터와 검수 시나리오
제안서·기술 인터뷰 질문
설명 자료보다 구체적인 상황 질문이 역량을 드러냅니다.
- 요구사항이 서로 충돌하면 어떤 문서와 절차로 결정하는가
- 변경 가능성이 큰 영역과 안정적으로 유지할 영역을 어떻게 나누는가
- 배포 중 데이터 구조가 바뀔 때 이전 버전과의 호환을 어떻게 유지하는가
- 외부 API가 느리거나 중단됐을 때 사용자 업무를 계속할 수 있는가
- 운영 데이터 오류를 직접 수정하지 않고 보정할 방법이 있는가
- 일정이 부족할 때 어떤 기능을 줄이고 어떤 기반은 반드시 지키는가
답변에는 선택의 이유와 포기하는 것이 함께 있어야 합니다. 모든 문제를 특정 프레임워크 하나로 해결하거나, 규모와 무관하게 같은 구조를 제안한다면 주의해야 합니다.
개발사 비교 항목
가격과 일정 외에 아래 항목을 후보별로 평가하면 제안서의 표현보다 실행 가능성을 비교하기 쉽습니다.
- 업무 상태와 예외를 구조화하는 능력
- 데이터 모델과 이력 관리 방안
- 권한, 감사, 보안 설계
- 외부 연동 실패와 재처리 방안
- 테스트와 검수 기준의 구체성
- 배포, 모니터링, 백업과 복구 범위
- 변경 요청의 기록과 비용 산정 방식
- 소스, 계정, 문서의 최종 소유권
복잡한 시스템에 필요한 개발사는 기능 목록을 빨리 받아 적는 곳이 아니라, 아직 정의되지 않은 위험을 초기에 드러내고 검수 가능한 단위로 바꾸는 곳입니다. 관련 구조가 실제 프로젝트에서 어떻게 적용되는지는 고속철도 유지보수 정보시스템 사례에서 확인할 수 있습니다.