시스템개발업체에 문의하기 전, 업무 흐름과 운영 범위로 견적을 비교하는 방법

“필요한 화면을 정리해서 시스템개발업체 세 곳에 전달했는데, 견적 금액과 개발 범위가 모두 다릅니다.”

업무용 웹 시스템이나 관리자 시스템을 처음 준비할 때 자주 생기는 상황입니다.

A업체는 요청한 화면만 구현하는 범위로 견적을 제안하고, B업체는 관리자 기능과 서버 구축까지 포함합니다. C업체는 데이터 이전과 외부 시스템 연동까지 필요하다고 설명합니다.

같은 자료를 전달했는데 견적이 다른 이유는 업체마다 가격 기준이 달라서만은 아닙니다. 전달한 요구사항에 해석해야 할 부분이 많이 남아 있기 때문입니다.

예를 들어 요구사항 문서에 ‘주문 관리 화면’이라고만 적혀 있다면 다음 내용을 바로 알기 어렵습니다.

누가 주문을 등록하는가
주문을 수정하거나 취소할 수 있는 사람은 누구인가
승인 절차가 필요한가
주문 상태는 몇 단계로 나뉘는가
여러 주문을 한 번에 처리해야 하는가
거래처별로 볼 수 있는 정보가 다른가
기존 ERP와 주문 정보를 주고받아야 하는가
변경 이력을 얼마나 오래 보관해야 하는가

이 조건에 따라 필요한 데이터 구조와 관리자 기능, 테스트 범위가 달라집니다. 화면 모양은 비슷해 보여도 실제 개발 범위에는 큰 차이가 생길 수 있습니다.

따라서 시스템개발업체에 문의할 때는 화면 목록만 전달하기보다 현재 업무가 어떻게 진행되고 있으며, 구축 후 누가 어떤 방식으로 운영할 것인지를 함께 정리하는 편이 좋습니다.

이 자료가 준비되어야 업체가 요구사항을 구체적으로 해석할 수 있고, 발주사도 서로 다른 제안과 견적을 같은 기준으로 비교할 수 있습니다.

시스템 개발의 목적을 한 문장으로 먼저 정리해보세요

시스템 개발을 검토하게 된 계기는 대체로 구체적인 업무 문제에서 시작됩니다.

엑셀 파일이 여러 버전으로 나뉘어 최신 데이터를 찾기 어렵다
주문과 발주 요청이 메일과 메신저로 분산되어 누락이 발생한다
담당자마다 업무 처리 방식이 달라 인수인계가 어렵다
승인 현황을 확인하려면 담당자에게 직접 물어봐야 한다
고객 정보와 주문 이력을 한 번에 조회하기 어렵다
반복 입력과 파일 취합에 많은 시간이 들어간다
기존 시스템에서 필요한 통계나 자료를 뽑기 어렵다

이 문제를 정리하지 않은 채 “통합 업무 시스템을 만들고 싶다”라고 요청하면 개발 범위가 넓고 모호해집니다.

반대로 다음과 같이 목적을 구체적으로 표현하면 시스템개발업체가 제안해야 할 방향도 분명해집니다.

거래처 주문을 엑셀과 메일로 접수하는 현재 방식을 웹 시스템으로 전환하고, 주문 접수부터 내부 승인, 출고 요청, 처리 완료까지의 상태를 담당자가 한곳에서 확인할 수 있도록 만들고 싶습니다.

여기에는 현재 문제와 주요 사용자, 핵심 데이터, 처리 흐름이 함께 담겨 있습니다.

개발 목적을 정리할 때는 다음 세 가지 질문에 답해보는 것이 좋습니다.

현재 가장 자주 발생하는 업무 문제는 무엇인가?
시스템 도입 후 어떤 업무가 달라져야 하는가?
도입 효과를 무엇으로 확인할 것인가?

도입 효과도 막연하게 ‘업무 효율 향상’이라고 작성하기보다 관찰할 수 있는 변화로 정리해야 합니다.

예를 들면 다음과 같습니다.

주문 처리 상태를 담당자에게 묻지 않고 시스템에서 확인한다
거래처별 주문 이력을 한 화면에서 조회한다
승인 대기 건을 별도 엑셀 없이 확인한다
반복되는 상태 변경과 알림 발송을 자동화한다
담당자 변경 시에도 동일한 처리 절차를 유지한다

이렇게 목적을 정리하면 모든 기능을 한 번에 구현해야 하는지, 가장 불편한 업무부터 단계적으로 전환할지도 판단하기 쉬워집니다.

사용자 유형별 업무 흐름을 순서대로 작성해야 합니다

시스템은 여러 사람이 같은 화면을 사용하는 프로그램이 아니라, 서로 다른 역할이 정해진 절차에 따라 업무를 주고받는 구조에 가깝습니다.

따라서 단순히 ‘회원’, ‘관리자’로만 사용자를 구분하면 실제 업무를 충분히 설명하기 어렵습니다.

B2B 주문 시스템을 예로 들면 사용자는 다음처럼 나뉠 수 있습니다.

거래처 주문 담당자
거래처 승인 담당자
본사 영업 담당자
주문 검토 담당자
출고 담당자
정산 담당자
전체 시스템 관리자

같은 주문을 보더라도 역할에 따라 할 수 있는 일이 다릅니다.

| 사용자 유형 | 주요 업무 | 필요한 권한 예시 | |---|---|---| | 거래처 주문 담당자 | 상품 조회, 주문 작성, 제출 | 본인 회사 주문 등록·조회 | | 거래처 승인 담당자 | 제출된 주문 검토 | 회사 주문 승인·반려 | | 영업 담당자 | 담당 거래처 주문 확인 | 담당 거래처 데이터 조회 | | 출고 담당자 | 출고 대상 확인, 처리 결과 등록 | 승인 완료 주문 조회·상태 변경 | | 정산 담당자 | 금액 및 정산 자료 확인 | 주문·결제·세금계산 자료 조회 | | 시스템 관리자 | 계정, 권한, 기준정보 관리 | 전체 데이터 및 설정 관리 |

권한을 설계할 때는 메뉴 접근 여부만 정해서는 부족합니다.

같은 주문 관리 메뉴에 접근하더라도 어떤 사용자는 조회만 가능하고, 다른 사용자는 수정·승인·다운로드까지 가능할 수 있습니다. 특정 담당자는 자신이 담당하는 거래처만 봐야 하고, 책임자는 부서 전체 데이터를 확인해야 할 수도 있습니다.

NIST에서 설명하는 최소 권한 원칙도 사용자나 시스템에 맡은 업무를 수행하는 데 필요한 최소한의 권한만 부여하는 것을 기본으로 합니다. 시스템 기획 단계에서도 직급이나 명칭만으로 권한을 나누기보다 실제 수행 업무를 기준으로 조회·등록·수정·승인·다운로드 범위를 구분할 필요가 있습니다. (csrc.nist.gov)

업무 흐름은 복잡한 기획서가 아니어도 다음처럼 순서대로 작성할 수 있습니다.

거래처 담당자가 주문서를 작성한다.
주문을 임시 저장하거나 내부 승인 요청 상태로 제출한다.
거래처 승인 담당자가 주문 내용을 검토한다.
승인된 주문이 본사 담당자에게 전달된다.
본사 담당자가 재고와 가격 조건을 확인한다.
처리 가능한 주문은 출고 요청으로 전환한다.
출고 담당자가 출고 결과와 송장 정보를 등록한다.
거래처는 처리 상태와 결과를 확인한다.
정산 담당자는 완료된 주문을 기준으로 정산 자료를 확인한다.

이 정도의 흐름만 있어도 시스템개발업체는 필요한 화면뿐 아니라 상태값, 권한, 알림, 데이터 관계를 함께 검토할 수 있습니다.

특히 정상적인 흐름만 작성하지 말고 다음과 같은 예외 상황도 포함해야 합니다.

승인자가 자리를 비운 경우
주문 제출 후 수량을 변경해야 하는 경우
일부 상품만 출고할 수 있는 경우
주문 전체가 아니라 특정 품목만 취소하는 경우
이미 출고된 주문을 수정하려는 경우
거래처 계정이 중지되었지만 과거 기록은 조회해야 하는 경우
담당자가 변경되어 기존 업무를 넘겨받아야 하는 경우

예외 상황은 운영 중 반드시 발생할 수 있기 때문에, 개발 후에 추가하면 데이터 구조나 권한 설계를 다시 수정해야 할 수도 있습니다.

화면 목록보다 데이터와 상태값을 먼저 정의해야 합니다

시스템 개발을 준비할 때 로그인, 대시보드, 목록, 상세, 등록 화면부터 적는 경우가 많습니다.

하지만 화면은 데이터를 보여주고 변경하는 수단입니다. 어떤 데이터를 저장하고 서로 어떻게 연결할 것인지가 정해지지 않으면 화면도 구체적으로 설계하기 어렵습니다.

예를 들어 주문 시스템이라면 다음과 같은 데이터가 필요할 수 있습니다.

거래처 정보
거래처 소속 사용자
상품과 옵션
거래처별 가격
주문 기본 정보
주문 품목
배송지
승인 정보
출고 정보
결제 또는 정산 정보
변경 이력
첨부파일과 메모

여기서 ‘주문’이라는 하나의 데이터 안에 모든 내용을 넣는 것보다 주문 기본 정보와 품목, 승인, 출고 정보를 어떤 기준으로 구분할지가 중요합니다.

주문 품목이 다섯 개일 때 세 개만 먼저 출고할 수 있다면 주문 전체의 상태만으로는 업무를 설명하기 어렵습니다. 주문 상태와 품목별 출고 상태를 분리해야 할 수 있습니다.

상태값도 ‘대기’, ‘완료’ 두 개만으로는 부족한 경우가 많습니다.

예를 들어 다음처럼 나뉠 수 있습니다.

작성 중
승인 요청
승인 완료
반려
접수 완료
처리 중
일부 처리
처리 완료
취소 요청
취소 완료

상태값을 정할 때는 명칭보다 전환 조건을 함께 정의해야 합니다.

| 현재 상태 | 다음 상태 | 변경 주체 | 전환 조건 | |---|---|---|---| | 작성 중 | 승인 요청 | 주문 담당자 | 필수 정보 입력 완료 | | 승인 요청 | 승인 완료 | 승인 담당자 | 주문 내용 검토 완료 | | 승인 요청 | 반려 | 승인 담당자 | 반려 사유 입력 | | 승인 완료 | 처리 중 | 본사 담당자 | 주문 접수 및 담당자 배정 | | 처리 중 | 처리 완료 | 출고 담당자 | 출고 정보 입력 완료 |

이 표가 있으면 시스템개발업체는 상태 변경 버튼을 만드는 데서 끝나지 않고, 어떤 단계에서 수정이 가능한지와 어떤 알림을 보내야 하는지도 제안할 수 있습니다.

예를 들어 승인 완료 후에도 거래처가 주문 수량을 자유롭게 수정할 수 있다면 승인된 내용과 실제 처리 내용이 달라집니다. 이 경우 수정 자체를 제한하거나, 변경 요청과 재승인 절차를 추가하는 방식을 검토해야 합니다.

업체의 제안력을 확인하려면 화면 시안을 얼마나 빠르게 보여주는지만 볼 것이 아니라 다음 질문을 하는지 살펴보는 것이 좋습니다.

이 데이터의 원본은 어느 시스템인가요?
상태는 누가, 어떤 조건에서 변경하나요?
완료된 업무를 다시 되돌릴 수 있나요?
삭제된 데이터는 복구하거나 확인할 필요가 있나요?
여러 건을 동시에 처리하는 업무가 있나요?
수정 전 값과 수정 후 값을 남겨야 하나요?

이러한 질문은 실제 운영 구조와 데이터 일관성을 검토하고 있다는 신호가 될 수 있습니다.

관리자 페이지에는 조회 외의 운영 기능이 필요합니다

관리자 페이지를 단순히 데이터 목록을 보여주는 화면으로 생각하면 시스템을 구축한 뒤에도 엑셀과 수작업이 계속 남을 수 있습니다.

운영자는 데이터를 보는 것뿐 아니라 찾아서 분류하고, 여러 건을 처리하며, 오류의 원인을 확인해야 합니다.

1. 검색과 필터

데이터가 많아지면 한 줄 검색창만으로는 필요한 정보를 찾기 어렵습니다.

업무 특성에 따라 다음 조건이 필요할 수 있습니다.

등록일과 처리일
거래처
담당자
처리 상태
승인 상태
상품 또는 서비스 유형
금액 범위
오류 발생 여부
미처리 건
특정 정보가 누락된 건

자주 사용하는 검색 조건을 저장하거나 기본값으로 지정하는 기능이 필요한지도 확인해야 합니다.

2. 일괄 처리

운영자가 같은 작업을 여러 건에 반복한다면 개별 상세 화면을 열어 하나씩 수정하는 방식은 비효율적일 수 있습니다.

다음과 같은 일괄 기능을 검토할 수 있습니다.

담당자 일괄 배정
상태 일괄 변경
승인 또는 반려
알림 일괄 발송
파일 일괄 등록
선택 항목 엑셀 다운로드
외부 시스템 재전송

다만 일괄 처리는 업무 속도를 높이는 만큼 잘못 처리했을 때의 영향도 큽니다. 처리 전 확인 화면, 대상 건수 표시, 권한 제한, 실행 이력을 함께 고려해야 합니다.

3. 변경 이력

여러 명이 사용하는 시스템에서는 데이터의 현재 값만 확인해서는 문제가 발생한 원인을 찾기 어렵습니다.

변경 이력에는 상황에 따라 다음 정보가 포함될 수 있습니다.

변경 일시
작업자
변경 대상
변경 전 값
변경 후 값
변경 사유
접속 환경
처리 결과

OWASP도 애플리케이션 로그가 보안뿐 아니라 운영상 문제를 파악하고, 사건과 거래의 순서를 재구성하는 데 활용될 수 있다고 안내합니다. 모든 입력값을 무조건 기록하기보다는 중요한 상태 변경, 권한 변경, 개인정보 조회·다운로드, 외부 연동 결과처럼 추적이 필요한 이벤트를 구분하는 편이 좋습니다. (cheatsheetseries.owasp.org)

4. 다운로드와 개인정보 보호

엑셀 다운로드는 관리자 시스템에서 자주 요청되는 기능이지만, 모든 운영자에게 전체 데이터 다운로드 권한을 제공하는 것이 적절한지는 별도로 검토해야 합니다.

개인정보가 포함된다면 다음 기준을 확인할 수 있습니다.

역할별 다운로드 가능 여부
다운로드할 수 있는 항목
개인정보 마스킹 여부
다운로드 사유 입력
다운로드 이력 기록
파일 보관 및 폐기 방식

2026년 7월 1일부터 시행 중인 개인정보의 안전성 확보조치 기준은 개인정보처리시스템의 접근 권한, 접속기록, 출력·복사 시 안전조치 등 운영상 관리 기준을 포함하고 있습니다. 개인정보를 다루는 시스템이라면 개발 막바지에 보안 기능을 추가하기보다 기획 단계에서 데이터 접근과 다운로드 범위를 함께 확인해야 합니다. 다만 실제 적용 의무와 세부 범위는 조직과 처리 정보에 따라 달라질 수 있으므로 관련 법령 및 개인정보 보호 담당자의 검토가 필요합니다. (law.go.kr)

기존 엑셀 데이터 이전 범위를 견적에 포함해야 합니다

새로운 시스템을 만들더라도 기존 데이터가 자동으로 정리되는 것은 아닙니다.

현재 사용 중인 엑셀 파일이나 기존 프로그램 데이터를 옮겨야 한다면 데이터 이전 작업을 별도 범위로 확인해야 합니다.

먼저 다음 자료를 준비해보세요.

현재 사용 중인 엑셀 양식
실제 데이터가 들어 있는 샘플 파일
파일별 작성 담당자
같은 항목을 표현하는 여러 명칭
중복 데이터와 누락 데이터
반드시 이전해야 하는 기간
보관만 하면 되는 과거 데이터
기존 시스템의 데이터 추출 가능 여부

예를 들어 여러 부서가 거래처명을 서로 다르게 작성했다면 하나의 거래처가 중복 등록될 수 있습니다.

원소프트
주식회사 원소프트
㈜원소프트
원소프트 동탄
OneSoft

이 데이터를 그대로 옮길지, 사업자번호 등 식별 기준으로 통합할지 먼저 결정해야 합니다.

데이터 이전 견적을 비교할 때는 ‘엑셀 업로드 기능 포함’이라는 문구만 확인하지 말고 다음 범위를 구분해야 합니다.

한 번만 수행하는 초기 데이터 이전
운영자가 계속 사용할 엑셀 업로드 기능
데이터 정제와 중복 제거
이전 전 검증
이전 후 건수 및 결과 검증
오류 데이터 수정과 재이전
전환 직전 최신 데이터 추가 반영

초기 이전과 반복 업로드는 서로 다른 기능입니다.

초기 이전은 개발사에서 정해진 양식을 기준으로 일괄 처리할 수 있지만, 운영자가 계속 파일을 올려야 한다면 파일 형식 검사와 오류 안내, 중복 처리 기준, 업로드 결과 화면까지 필요할 수 있습니다.

외부 API와 ERP 연동은 정상 연결보다 운영 기준을 확인해야 합니다

업무 시스템은 ERP, 그룹웨어, 쇼핑몰, 결제 서비스, 배송 서비스, 문자·메일 발송 서비스 등과 연결되는 경우가 많습니다.

연동이 있다면 시스템개발업체에 서비스 이름만 전달하기보다 다음 내용을 함께 정리해야 합니다.

어떤 데이터를 가져오거나 보낼 것인가
어느 시스템의 데이터를 원본으로 볼 것인가
실시간 처리가 필요한가
일정 시간마다 모아서 처리해도 되는가
API 사용 권한과 계약 주체는 누구인가
연동 대상의 개발 문서가 준비되어 있는가
테스트 계정을 제공받을 수 있는가
연동 실패 시 운영자가 무엇을 해야 하는가

예를 들어 주문 정보를 ERP로 보내는 경우 우리 시스템에서 ‘전송 완료’로 표시되었다고 해서 ERP에도 정상 등록되었다고 단정할 수 없습니다.

다음과 같은 상황이 발생할 수 있습니다.

외부 시스템이 일시적으로 응답하지 않음
요청은 처리됐지만 응답이 늦게 도착함
같은 주문이 여러 번 전송됨
주문 품목 중 일부만 등록됨
상품 코드가 일치하지 않아 등록이 거절됨
인증 정보가 만료됨
API 호출 한도에 도달함

따라서 관리자 화면에는 연동 성공 여부만이 아니라 실패 사유, 마지막 시도 시각, 재처리 가능 여부가 필요할 수 있습니다.

외부 연동 범위는 다음처럼 나누어 견적을 비교하는 편이 좋습니다.

| 구분 | 확인 내용 | |---|---| | 연동 대상 | 어떤 서비스 또는 시스템과 연결하는가 | | 데이터 방향 | 가져오기, 보내기, 양방향 중 무엇인가 | | 처리 시점 | 실시간, 주기 실행, 관리자 수동 실행 | | 식별 기준 | 어떤 값으로 같은 데이터를 판단하는가 | | 실패 처리 | 자동 재시도, 관리자 확인, 수동 재처리 | | 중복 방지 | 동일 요청이 다시 들어왔을 때 처리 기준 | | 모니터링 | 성공·실패 현황을 어디에서 확인하는가 | | 테스트 | 개발용 환경과 테스트 데이터 제공 여부 |

외부 연동은 개발사만으로 범위를 확정하기 어려운 경우도 있습니다. 상대 시스템의 API 제공 범위, 기술 지원 정책, 테스트 환경, 이용 요금에 따라 일정과 구현 방식이 달라질 수 있기 때문입니다.

따라서 견적서에는 연동 개발비뿐 아니라 외부 기관 확인이 필요한 항목과 발주사가 준비해야 하는 계정·계약·문서를 함께 표시하는 것이 좋습니다.

보안·테스트·배포·서버 운영 범위를 나누어 확인하세요

기능 개발이 완료되었다고 바로 운영 가능한 시스템이 되는 것은 아닙니다.

개발 환경에서 정상적으로 작동하더라도 실제 사용자와 데이터가 들어오는 운영 환경에서는 권한, 성능, 브라우저 환경, 데이터 예외 조건을 추가로 확인해야 합니다.

보안 범위

보안은 ‘보안 적용’이라는 한 줄로 비교하기 어렵습니다.

최소한 다음 항목은 구분해서 확인하는 것이 좋습니다.

사용자 인증 방식
비밀번호 저장 방식
관리자 접근 제한
역할별 권한 검사
개인정보 마스킹
중요 데이터 암호화
접속 및 변경 이력
파일 업로드 제한
취약점 점검 범위
퇴사자 및 미사용 계정 처리

화면에서 버튼을 숨기는 것만으로 권한이 제한되는 것은 아닙니다. 사용자가 요청 주소나 API를 직접 호출하더라도 서버에서 권한을 다시 검사해야 합니다.

테스트 범위

“테스트 포함”이라는 표현도 업체마다 의미가 다를 수 있습니다.

개발자가 기능 단위로 수행하는 테스트
주요 업무 흐름 테스트
브라우저 및 기기별 테스트
외부 API 연동 테스트
권한별 접근 테스트
데이터 이전 검증
사용자 인수 테스트 지원
오류 수정 후 재테스트

발주사도 실제 업무 담당자를 테스트에 참여시키는 편이 좋습니다.

개발자는 요구사항을 기준으로 동작을 확인할 수 있지만, 현업 담당자는 업무 순서와 예외 상황이 현실적으로 반영되었는지를 확인할 수 있기 때문입니다.

배포와 서버

다음 범위도 견적에 포함되어 있는지 확인해야 합니다.

서버와 데이터베이스 구성
도메인 및 보안 인증서
운영 환경 배포
개발·테스트·운영 환경 분리 여부
배포 자동화 범위
모니터링 및 오류 확인 방법
백업 주기
복구 절차
서버 및 외부 서비스 비용
운영 계정의 소유 주체

백업은 설정했다는 사실만으로 충분하지 않을 수 있습니다. 어떤 데이터를 얼마나 자주 백업할지, 장애가 발생했을 때 어느 시점까지 복구해야 하는지, 복구 절차를 실제로 확인할 것인지가 함께 정해져야 합니다. AWS의 운영 지침도 복구 시간 목표와 복구 시점 목표에 맞춘 백업, 자동화, 암호화와 함께 주기적인 복구 검증을 권고합니다. (docs.aws.amazon.com)

장애 대응과 유지보수

유지보수 범위도 계약 전에 구분해야 합니다.

개발된 기능의 오류 수정
운영 중 발견된 예외 상황 수정
브라우저와 운영체제 변경 대응
외부 API 변경 대응
신규 기능 추가
서버 모니터링
장애 발생 시 연락 방법
대응 가능 시간
정기 점검
백업 및 복구 지원

오류 수정과 기능 추가는 일반적으로 다른 업무입니다.

계약 당시 정의한 기능이 동작하지 않는 문제와 운영 중 새롭게 필요한 기능을 같은 유지보수 범위로 해석하면 추후 협의가 어려워질 수 있습니다.

MVP와 추후 확장 기능을 구분하면 견적을 현실적으로 비교할 수 있습니다

시스템 개발을 준비하다 보면 각 부서의 요구사항이 계속 추가됩니다.

처음에는 주문 관리가 목적이었지만 이후 재고, 정산, 통계, 전자결재, ERP 연동, 모바일 앱까지 필요하다는 의견이 나올 수 있습니다.

모든 기능을 처음부터 포함하면 개발 범위와 검토 항목이 커지고 실제 사용 시작 시점도 늦어질 수 있습니다.

이때는 기능을 단순히 ‘필수’와 ‘선택’으로만 나누기보다 다음 기준으로 검토하는 것이 좋습니다.

첫 번째, 핵심 업무 흐름이 끝까지 이어지는가

주문 시스템이라면 최소한 다음 흐름이 끊기지 않아야 합니다.

거래처 주문 등록 → 내부 검토 또는 승인 → 본사 접수 → 처리 상태 변경 → 결과 확인

화려한 통계 화면이 없어도 이 흐름이 완료된다면 실제 운영을 시작할 수 있습니다.

반대로 사용자 화면은 잘 만들어졌지만 관리자가 주문을 처리할 방법이 없다면 운영 가능한 MVP라고 보기 어렵습니다.

두 번째, 초기에는 수동 운영이 가능한가

처음부터 모든 업무를 자동화할 필요는 없습니다.

예를 들어 초기 주문량이 많지 않다면 ERP 자동 연동 대신 관리자가 검토한 뒤 엑셀로 전달하는 방식을 사용할 수 있습니다. 다만 임시 수동 업무를 누가, 어떤 절차로 처리할지는 정해두어야 합니다.

세 번째, 데이터가 쌓인 뒤 만들어도 되는가

고급 통계와 예측 기능은 실제 데이터가 쌓인 뒤 요구사항이 구체화되는 경우가 많습니다.

초기에는 운영에 필요한 기본 현황만 제공하고, 실제 사용 데이터를 확인한 뒤 통계와 자동화 기능을 확장하는 방법을 검토할 수 있습니다.

네 번째, 나중에 추가하기 어려운 구조인가

기능을 나중으로 미루더라도 데이터와 권한 구조에는 미리 반영해야 할 수 있습니다.

현재는 승인 단계가 하나지만 추후 부서별 다단계 승인이 예정되어 있다면 데이터 구조가 확장을 수용할 수 있는지 검토해야 합니다.

| 1차 구축 후보 | 추후 확장 후보 | |---|---| | 계정과 기본 권한 | 세부 역할별 권한 설정 | | 핵심 데이터 등록·조회 | 고급 통계와 대시보드 | | 업무 상태 관리 | 조건별 자동 처리 | | 기본 검색과 필터 | 개인별 검색 조건 저장 | | 운영자 수동 알림 | 조건 기반 자동 알림 | | 기본 엑셀 다운로드 | 정기 보고서 자동 생성 | | 수동 ERP 전달 | 양방향 ERP 자동 연동 |

이렇게 범위를 나누면 업체별로 동일한 1차 구축 범위를 요청할 수 있어 견적 비교가 쉬워집니다.

시스템개발업체의 제안력을 확인하는 질문

개발업체를 비교할 때는 요구사항을 모두 구현할 수 있다고 답하는지만 확인하지 않는 것이 좋습니다.

좋은 제안은 기능을 무조건 추가하는 것이 아니라 현재 업무와 운영 조건에 맞게 필요한 범위를 구분하는 과정에서 드러납니다.

상담 중 다음 질문을 활용해볼 수 있습니다.

현재 요구사항에서 개발 범위가 불명확한 부분은 무엇인가요?
사용자 유형과 권한을 어떤 기준으로 나누는 것이 좋을까요?
상태값과 승인 절차에서 추가로 결정해야 할 내용은 무엇인가요?
관리자 페이지에 필요한 운영 기능은 무엇이라고 보시나요?
현재 엑셀 데이터를 이전하려면 어떤 자료가 필요한가요?
외부 시스템 연동 전에 확인해야 할 조건은 무엇인가요?
연동에 실패하면 운영자가 어디에서 확인하고 재처리하나요?
테스트에는 어떤 업무 시나리오가 포함되나요?
운영 서버와 계정은 누구의 명의로 관리되나요?
1차 구축에서 제외해도 되는 기능은 무엇인가요?
추후 확장을 고려해 미리 설계해야 하는 부분은 무엇인가요?
배포 후 오류 수정과 추가 개발은 어떻게 구분하나요?

업체가 이런 질문에 답하려면 단순한 화면 구현 경험뿐 아니라 백엔드, 데이터베이스, 관리자 시스템, 서버 운영과 업무 흐름에 대한 이해가 필요합니다.

제안서에서도 기능 목록의 개수만 보지 말고 다음 내용을 확인해야 합니다.

요구사항에 대한 업체의 해석
포함 범위와 제외 범위
발주사가 준비해야 할 자료
외부 기관 확인이 필요한 항목
프로젝트 단계별 산출물
테스트 및 검수 방식
운영 전환 방식
계정과 소스코드 인수인계
유지보수와 추가 개발 기준

상담 전에 준비하면 좋은 자료

완성된 기획서를 반드시 만들어야 상담할 수 있는 것은 아닙니다.

다만 다음 자료를 준비하면 시스템개발업체가 현재 상황을 이해하고 현실적인 범위를 제안하는 데 도움이 됩니다.

기본 자료

시스템 개발 목적
현재 업무의 문제
주요 사용자 유형
사용자별 핵심 업무
현재 업무 처리 순서
사용 중인 엑셀 양식
참고 중인 기존 시스템
예상 운영 인원
희망 도입 시점
우선 구축해야 하는 업무

데이터 자료

관리해야 하는 데이터 항목
샘플 데이터
데이터 생성과 수정 주체
보관해야 하는 기간
이전 대상 데이터 범위
개인정보 및 민감정보 포함 여부
파일과 첨부문서의 종류

연동 자료

연동할 시스템 이름
API 문서
담당 기관 연락처
테스트 계정 제공 여부
현재 사용 중인 ERP 또는 그룹웨어 정보
주고받아야 하는 데이터
동기화 주기

운영 자료

관리자 유형
역할별 권한
승인 절차
자주 사용하는 검색 조건
반복되는 일괄 업무
필요한 다운로드 자료
변경 이력이 필요한 업무
장애 발생 시 대응 담당자

자료가 완벽하지 않아도 괜찮습니다.

중요한 것은 정해진 내용과 아직 결정하지 못한 내용을 구분하는 것입니다. 미정 항목을 숨기기보다 업체가 제안해야 할 내용으로 표시하면 상담 과정에서 업체의 문제 해결 방식도 함께 확인할 수 있습니다.

시스템 개발 견적 비교 체크리스트

업체별 견적서를 검토할 때는 총액 옆에 다음 항목을 표로 정리해보세요.

| 비교 항목 | 확인 질문 | |---|---| | 기획 | 업무 흐름과 요구사항 구체화가 포함되어 있는가 | | UX/UI | 사용자·관리자 화면의 설계와 디자인 범위는 어디까지인가 | | 사용자 시스템 | 사용자별 주요 기능이 모두 포함되어 있는가 | | 관리자 시스템 | 검색·필터·일괄 처리·이력 기능이 포함되어 있는가 | | 권한 | 조회·수정·승인·다운로드 권한이 구분되는가 | | 데이터 | 데이터 구조 설계와 기존 데이터 이전이 포함되는가 | | 외부 연동 | API·ERP 연동 대상과 실패 처리가 포함되는가 | | 보안 | 인증·권한·개인정보·접속기록 범위가 명시되어 있는가 | | 테스트 | 기능·권한·연동·데이터 이전 테스트 범위가 있는가 | | 배포 | 서버 구성과 운영 환경 배포가 포함되는가 | | 운영 | 모니터링·백업·장애 대응 범위가 정해져 있는가 | | 인수인계 | 소스코드, 서버, 도메인, 외부 계정의 인계 조건이 있는가 | | 유지보수 | 하자 수정과 추가 개발의 구분이 명확한가 | | 확장 | 1차 개발 이후 기능 확장을 고려한 구조인가 |

총견적이 낮더라도 관리자 기능, 데이터 이전, 외부 연동 테스트, 배포가 제외되어 있다면 실제 운영 시작 전 추가 비용과 일정이 필요할 수 있습니다.

반대로 견적이 높더라도 불필요한 기능이 과도하게 포함되어 있다면 1차 구축 범위를 다시 조정할 필요가 있습니다.

따라서 비교의 기준은 가장 낮은 금액이 아니라 같은 업무 범위가 포함되어 있는지, 빠진 항목과 전제 조건이 명확한지가 되어야 합니다.

운영 가능한 시스템은 화면 뒤의 업무까지 설계해야 합니다

시스템개발업체에 문의하기 전 모든 기술 사양을 결정할 필요는 없습니다.

대신 현재 업무가 어떻게 진행되는지, 누가 어떤 데이터를 다루는지, 어떤 상태와 승인 절차가 있는지, 구축 후 운영자가 무엇을 해야 하는지는 정리해두는 편이 좋습니다.

이 자료가 있으면 업체는 단순히 요청받은 화면을 만드는 데서 그치지 않고 다음 내용을 제안할 수 있습니다.

사용자 유형과 권한 구조
데이터와 상태값
관리자 운영 기능
기존 데이터 이전 방식
API·ERP 연동 구조
보안과 변경 이력
테스트와 배포
MVP와 단계적 확장 범위

원소프트는 웹·앱 개발뿐 아니라 백엔드, 데이터베이스, 관리자 시스템, 외부 API 연동, 서버 배포와 유지보수 범위를 함께 검토합니다.

요구사항이 아직 화면 목록이나 엑셀 파일 형태로만 정리되어 있더라도 현재 업무 흐름과 운영 방식을 기준으로 1차 구축 범위와 추후 확장 범위를 나누어볼 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치하고 있습니다. 화성·동탄을 비롯해 수원, 용인, 기흥, 오산 등 경기 남부에서 업무 시스템 구축을 검토하고 계신다면 현재 사용 중인 자료와 필요한 기능을 바탕으로 개발 범위를 함께 정리해드릴 수 있습니다.

제목 후보

시스템개발업체 문의 전, 업무 흐름과 운영 범위로 견적을 비교하는 방법
시스템개발업체 선정, 화면 목록보다 먼저 준비해야 할 실무 자료
시스템개발업체 견적 비교 전 확인할 업무 흐름·권한·데이터 기준
시스템개발업체에 문의할 때 화면보다 운영 구조를 먼저 설명해야 하는 이유
시스템개발업체 비교, 관리자 기능부터 데이터 이전·유지보수까지 확인하세요

메인 키워드

시스템개발업체

서브 키워드

업무시스템개발
관리자시스템개발
시스템개발견적
웹시스템개발
개발업체선정

썸네일 문구

시스템개발업체 문의 전 체크리스트
화면보다 업무 흐름을 먼저
시스템 견적, 같은 기준으로 비교하기

글 요약

시스템개발업체의 견적을 제대로 비교하려면 화면 목록보다 사용자별 업무 흐름, 권한, 데이터, 상태값과 관리자 운영 범위를 먼저 정리해야 합니다. 엑셀 데이터 이전, 외부 API·ERP 연동, 보안·테스트·배포·유지보수 범위를 구분하고 MVP와 추후 기능을 나누는 실무 기준을 설명했습니다.

CTA 후보

현재 사용 중인 엑셀이나 업무 자료는 있지만 개발 범위를 정하기 어렵다면, 사용자별 업무 흐름을 기준으로 1차 구축 범위부터 함께 정리해볼 수 있습니다.

업체별 견적 범위가 달라 비교하기 어렵다면 관리자 기능, 데이터 이전, 외부 연동과 운영 조건이 동일하게 포함되어 있는지 검토해보세요. 원소프트가 요구사항과 포함 범위를 정리하는 과정을 도와드릴 수 있습니다.

다음에 작성하면 좋은 연관 글

시스템개발 견적서, 포함 기능과 제외 항목을 비교하는 실무 체크리스트
업무 시스템 권한 설계, 조회·수정·승인·다운로드 범위를 나누는 방법
엑셀 데이터 이전, 웹 시스템 구축 전에 중복·누락 데이터를 정리하는 기준