시스템개발업체 선정 전, 업무 자동화와 관리자 운영 범위를 확인하는 방법

엑셀 파일이 부서마다 따로 있고, 업무 요청은 메신저로 전달하며, 승인 결과는 다시 담당자가 엑셀에 입력하는 상황이 반복되고 있나요?

처음에는 익숙한 도구만으로도 충분합니다. 업무량이 적고 담당자가 고정되어 있다면 엑셀과 메신저가 오히려 빠를 수도 있습니다.

하지만 거래처와 처리 건수가 늘어나면 문제가 달라집니다.

• 어느 파일이 최신 버전인지 알기 어렵습니다.
• 담당자가 자리를 비우면 진행 상황을 확인하기 어렵습니다.
• 승인 결과가 메신저 대화에만 남습니다.
• 같은 정보를 여러 시스템에 반복해서 입력합니다.
• 처리 상태를 확인하려면 담당자에게 직접 물어봐야 합니다.
• 누가 데이터를 수정했는지 추적하기 어렵습니다.
• 월말마다 여러 파일을 합쳐 보고서를 만듭니다.

이런 문제를 해결하기 위해 시스템개발업체를 찾게 되지만, 업체를 비교하는 과정에서도 또 다른 어려움이 생깁니다.

같은 설명을 전달했는데도 어떤 업체는 비교적 단순한 웹 시스템을 제안하고, 다른 업체는 관리자 페이지와 데이터 이전, 외부 연동까지 포함한 견적을 제시합니다. 견적 금액만 보면 차이가 커 보이지만, 실제로는 포함된 개발 범위가 서로 다를 가능성이 큽니다.

따라서 시스템개발업체를 선정할 때는 화면 디자인이나 총견적만 비교하기보다 다음 질문을 먼저 확인해야 합니다.

현재 사람이 처리하는 업무 중 어디까지 자동화할 것인가?

운영자가 시스템 안에서 직접 처리해야 할 업무는 무엇인가?

이 두 가지가 정리되어야 사용자 화면, 관리자 기능, 권한, 데이터 구조, 외부 연동, 테스트와 유지보수 범위도 구체적으로 비교할 수 있습니다.

시스템개발업체를 찾기 전에 해결하려는 업무 문제부터 정리해야 합니다

“사내 업무 시스템을 만들고 싶습니다.”

“엑셀로 관리하는 업무를 웹으로 바꾸고 싶습니다.”

“관리자 페이지가 필요합니다.”

이런 설명만으로도 상담은 시작할 수 있지만, 실제 개발 범위를 산정하기에는 정보가 부족합니다.

기존 업무를 웹 화면으로 옮기는 것과 업무 처리 방식을 바꾸는 것은 서로 다른 프로젝트이기 때문입니다.

예를 들어 현재 주문을 다음과 같이 처리한다고 가정해보겠습니다.

1. 거래처가 메신저로 주문서를 보냅니다.
2. 영업 담당자가 엑셀에 주문 내용을 입력합니다.
3. 재고 담당자가 재고를 확인합니다.
4. 팀장이 가격과 할인 조건을 승인합니다.
5. 출고 담당자가 배송 정보를 입력합니다.
6. 회계 담당자가 ERP에 매출 정보를 등록합니다.
7. 영업 담당자가 거래처에 결과를 안내합니다.

이 업무를 단순히 웹 시스템으로 옮기면 주문 등록 화면과 목록 화면을 만드는 정도로 끝날 수 있습니다.

반면 업무 자동화를 목표로 한다면 범위가 달라집니다.

• 거래처가 직접 주문을 등록할 수 있는가?
• 거래처별로 구매 가능한 상품과 가격이 다른가?
• 재고가 부족하면 자동으로 주문을 제한할 것인가?
• 일정 금액 이상의 할인은 팀장 승인을 거치게 할 것인가?
• 승인 완료 후 출고 담당자에게 알림을 보낼 것인가?
• 출고 완료 데이터를 ERP에 자동으로 전달할 것인가?
• 실패한 ERP 연동은 운영자가 다시 처리할 수 있는가?
• 거래처는 현재 주문 상태를 직접 확인할 수 있는가?

같은 ‘주문 시스템’이라도 이러한 기준에 따라 개발 범위와 데이터 구조가 크게 달라집니다.

시스템개발업체에 문의하기 전에는 만들고 싶은 메뉴보다 해결하려는 문제를 먼저 적는 것이 좋습니다.

| 현재 문제 | 발생 원인 | 시스템에서 기대하는 변화 |<br>|---|---|---|<br>| 최신 엑셀 파일을 찾기 어렵다 | 파일이 담당자별로 분리됨 | 하나의 데이터베이스에서 통합 관리 |<br>| 진행 상태를 담당자에게 물어봐야 한다 | 처리 단계가 기록되지 않음 | 업무별 현재 상태와 담당자 표시 |<br>| 승인 결과가 메신저에만 남는다 | 승인 절차가 시스템 밖에서 진행됨 | 승인 요청·승인·반려 이력 관리 |<br>| 같은 정보를 반복 입력한다 | 시스템 간 데이터가 연결되지 않음 | 외부 API 또는 ERP 연동 |<br>| 수정 원인을 확인하기 어렵다 | 변경 이력이 없음 | 작업자와 변경 전후 값 기록 |<br>| 월말 보고서 작성에 시간이 걸린다 | 데이터 형식과 기준이 다름 | 검색·필터·다운로드 기능 제공 |

이 표만 정리해도 개발사는 단순한 화면 제작이 필요한지, 업무 흐름을 포함한 맞춤형 시스템 개발이 필요한지 판단하기 쉬워집니다.

엑셀·메신저 업무를 사용자 유형과 실제 처리 순서로 나눠보세요

기존 업무를 정리할 때 가장 흔한 방법은 메뉴 목록을 작성하는 것입니다.

• 회원 관리
• 주문 관리
• 정산 관리
• 통계
• 알림
• 게시판

그러나 메뉴 이름만으로는 실제 업무를 파악하기 어렵습니다.

‘주문 관리’라는 메뉴 안에도 주문 등록, 검토, 승인, 출고 요청, 취소, 반품, 정산과 같은 여러 단계가 포함될 수 있습니다.

따라서 시스템개발업체와 상담할 때는 업무를 다음 세 가지 기준으로 나누는 것이 좋습니다.

1. 누가 처리하는 업무인가

먼저 시스템을 사용하는 사람을 구분합니다.

• 일반 고객
• 거래처 담당자
• 내부 직원
• 팀장 또는 승인자
• 물류 담당자
• 정산 담당자
• 운영 관리자
• 최고 관리자

같은 회사 직원이라도 담당 업무에 따라 조회할 수 있는 데이터와 실행할 수 있는 기능이 달라질 수 있습니다.

2. 어떤 순서로 처리하는가

현재 업무가 처리되는 순서를 한 줄로 적어봅니다.

``text<br>거래처 요청 접수<br>→ 담당자 검토<br>→ 조건 확인<br>→ 승인 요청<br>→ 승인 또는 반려<br>→ 처리 담당자 배정<br>→ 업무 완료<br>→ 결과 안내<br>→ 정산<br>``

이 단계가 정리되면 각 과정에서 필요한 화면과 데이터도 구체적으로 확인할 수 있습니다.

3. 각 단계에서 어떤 정보가 필요한가

업무 단계마다 입력하거나 확인해야 하는 정보를 적습니다.

예를 들어 승인 단계에서는 다음 정보가 필요할 수 있습니다.

• 요청한 거래처
• 요청한 담당자
• 상품 또는 서비스
• 수량과 금액
• 할인 조건
• 첨부 문서
• 요청 사유
• 이전 처리 이력
• 승인 또는 반려 의견

이 정보가 정리되어야 데이터베이스 구조와 관리자 화면을 설계할 수 있습니다.

업무를 정리할 때 반드시 완성된 기획서를 만들 필요는 없습니다. 현재 사용하는 엑셀 파일, 업무 매뉴얼, 신청서, 보고서, 메신저에서 자주 주고받는 항목도 좋은 참고 자료가 됩니다.

다만 개인정보나 영업상 민감한 자료를 전달할 때는 샘플 데이터로 가공하거나 필요한 범위만 공유하는 것이 좋습니다.

회원·직원·거래처·관리자별 권한과 데이터 접근 범위를 정해야 합니다

업무 시스템의 권한을 ‘일반 사용자’와 ‘관리자’ 두 종류로만 나누면 실제 운영에서 불편이 생길 수 있습니다.

예를 들어 고객 정보를 관리하는 시스템이라면 다음과 같은 차이가 필요할 수 있습니다.

| 사용자 유형 | 조회 | 등록 | 수정 | 승인 | 삭제 | 다운로드 |<br>|---|---:|---:|---:|---:|---:|---:|<br>| 상담 담당자 | 담당 고객 | 가능 | 일부 가능 | 불가 | 불가 | 불가 |<br>| 팀장 | 팀 고객 | 가능 | 가능 | 가능 | 불가 | 조건부 |<br>| 정산 담당자 | 결제·정산 정보 | 가능 | 일부 가능 | 정산 승인 | 불가 | 가능 |<br>| 운영 관리자 | 전체 데이터 | 가능 | 가능 | 가능 | 조건부 | 가능 |<br>| 최고 관리자 | 전체 데이터 | 가능 | 가능 | 가능 | 가능 | 가능 |

여기에서 중요한 점은 메뉴 접근 권한과 데이터 접근 권한을 구분하는 것입니다.

상담 담당자와 팀장이 모두 고객 관리 메뉴에 접근할 수 있더라도 상담 담당자는 자신이 담당하는 고객만 보고, 팀장은 소속 팀의 고객 전체를 확인하도록 설계할 수 있습니다.

다운로드 권한도 별도로 봐야 합니다. 화면에서 일부 정보를 조회하는 것과 수천 건의 개인정보를 엑셀로 내려받는 것은 위험 수준이 다르기 때문입니다.

개인정보보호위원회의 현행 기준에서도 개인정보처리시스템 접근 권한은 업무 수행에 필요한 범위로 차등 부여하는 것이 요구됩니다. 개인정보 포털의 안내 역시 개인·그룹·조직·역할에 따라 조회, 입력, 변경, 삭제, 출력, 다운로드 등의 권한을 세분화할 수 있어야 한다고 설명합니다. (privacy.go.kr)

시스템개발업체와 권한 범위를 협의할 때는 다음 항목을 확인해보는 것이 좋습니다.

• 사용자를 어떤 유형으로 구분하는가?
• 한 사용자가 여러 역할을 가질 수 있는가?
• 소속 회사나 부서에 따라 조회 범위가 달라지는가?
• 조회와 수정 권한을 분리할 수 있는가?
• 승인 권한은 금액이나 업무 종류에 따라 달라지는가?
• 개인정보 일부를 마스킹해야 하는가?
• 엑셀 다운로드 권한을 별도로 제한해야 하는가?
• 퇴사자나 계약 종료 거래처의 계정은 어떻게 처리하는가?
• 관리자 권한 변경 이력을 남겨야 하는가?

이 항목을 처음부터 정리하면 개발사는 인증과 권한 구조를 보다 현실적으로 설계할 수 있습니다.

업무 상태값과 승인 절차는 실제 처리 과정을 기준으로 설계해야 합니다

업무 시스템을 개발할 때 상태값은 단순한 표시 문구가 아닙니다.

상태값에 따라 사용자가 할 수 있는 행동, 운영자가 처리해야 하는 업무, 발송할 알림과 외부 시스템 연동 여부가 달라질 수 있습니다.

예를 들어 신청 업무를 다음 세 가지 상태로만 관리한다고 가정해보겠습니다.

• 대기
• 진행
• 완료

화면은 단순하지만 실제 운영에서는 부족할 가능성이 큽니다.

• 서류가 부족한 신청은 어떤 상태인가?
• 담당자가 검토한 신청과 아직 열어보지 않은 신청을 구분할 수 있는가?
• 승인자가 반려한 신청은 어디에서 확인하는가?
• 고객이 취소를 요청한 경우는 어떻게 처리하는가?
• 외부 시스템 전송에 실패한 건은 완료인가, 진행 중인가?
• 완료 후 수정이 필요하면 이전 상태로 되돌릴 수 있는가?

실제 업무를 반영하면 다음과 같이 세분화될 수 있습니다.

``text<br>임시 저장<br>→ 신청 완료<br>→ 담당자 검토 중<br>→ 보완 요청<br>→ 보완 완료<br>→ 승인 대기<br>→ 승인 완료 또는 반려<br>→ 처리 중<br>→ 외부 시스템 전송 대기<br>→ 처리 완료<br>``

상태를 무조건 많이 만드는 것이 좋은 것은 아닙니다.

각 상태는 다음 세 가지 중 하나 이상의 역할이 있을 때 추가하는 것이 좋습니다.

1. 사용자가 현재 진행 상황을 이해하는 데 필요하다.
2. 운영자가 다음 처리 업무를 구분하는 데 필요하다.
3. 알림·승인·외부 연동 등 시스템 동작의 기준이 된다.

승인 절차도 구체적으로 확인해야 합니다.

예를 들어 ‘팀장 승인’이라는 요구사항만으로는 다음 내용을 알 수 없습니다.

• 모든 요청을 승인하는가?
• 일정 금액 이상만 승인하는가?
• 요청자의 소속 팀장이 승인하는가?
• 승인자가 부재중이면 대리 승인이 가능한가?
• 한 명의 승인으로 끝나는가?
• 순차 승인인지 병렬 승인인지?
• 승인 후 내용을 수정하면 다시 승인을 받아야 하는가?
• 반려할 때 사유 입력이 필수인가?
• 승인 기한을 넘기면 알림을 보낼 것인가?

시스템개발업체가 업무 상태와 승인 조건을 구체적으로 질문하는지 살펴보는 것도 업체의 업무 이해 방식을 판단하는 기준이 될 수 있습니다.

기존 엑셀 데이터 이전은 파일 업로드 기능 하나로 끝나지 않습니다

기존 엑셀 데이터를 새로운 시스템으로 옮겨야 한다면 데이터 이전 범위를 견적에 명확하게 포함해야 합니다.

엑셀 파일을 업로드하는 기능과 기존 데이터를 정제해 새로운 데이터베이스로 이전하는 작업은 다릅니다.

먼저 다음 내용을 확인해야 합니다.

• 이전할 엑셀 파일은 몇 종류인가?
• 파일마다 열 이름과 형식이 동일한가?
• 고객, 거래처, 상품 등의 고유한 식별 기준이 있는가?
• 같은 고객이나 거래처가 중복으로 등록되어 있지 않은가?
• 날짜, 전화번호, 주소 등의 형식이 일관적인가?
• 비어 있거나 잘못 입력된 필드는 어떻게 처리할 것인가?
• 과거 처리 이력도 모두 이전할 것인가?
• 첨부파일과 이미지도 이전해야 하는가?
• 이전하지 않고 보관만 할 데이터가 있는가?
• 이전 완료 후 기존 파일은 어떻게 관리할 것인가?

예를 들어 거래처명이 다음과 같이 입력되어 있다면 시스템에서는 서로 다른 거래처로 인식할 수 있습니다.

• 원소프트
• 원소프트(주)
• 주식회사 원소프트
• ONE SOFT

따라서 데이터 이전 전에는 중복 제거, 형식 통일, 누락값 확인과 같은 정제 작업이 필요할 수 있습니다.

개발사에 샘플 파일을 전달하면 다음과 같은 구분으로 견적을 요청할 수 있습니다.

| 구분 | 확인 내용 |<br>|---|---|<br>| 데이터 분석 | 파일 종류, 열 구성, 중복과 누락 상태 확인 |<br>| 데이터 정제 | 형식 통일, 중복 병합, 잘못된 값 보정 |<br>| 매핑 | 기존 열과 신규 시스템 필드 연결 |<br>| 시험 이전 | 일부 데이터를 먼저 이전해 결과 검증 |<br>| 본 이전 | 확정된 기준으로 전체 데이터 이전 |<br>| 검수 | 건수, 합계, 표본 데이터 비교 |<br>| 전환 | 기존 파일 사용 중단 시점과 신규 시스템 적용 |

데이터 이전 기간 중에도 업무가 계속된다면 전환 시점도 중요합니다.

시험 이전을 진행한 뒤 실제 적용일까지 기존 엑셀에 추가된 데이터를 다시 반영해야 할 수 있기 때문입니다. 이런 경우에는 최종 증분 데이터의 이전 방식과 업무 중단 가능 시간을 함께 정해야 합니다.

외부 API·ERP 연동은 연결 대상과 오류 처리 범위를 함께 확인해야 합니다

새로운 시스템이 기존 ERP, 회계 프로그램, 쇼핑몰, 결제 서비스, 배송 서비스 또는 사내 시스템과 연결되어야 한다면 연동 범위를 별도로 정리하는 것이 좋습니다.

외부 시스템의 이름만 전달해서는 정확한 견적을 산정하기 어렵습니다.

다음 내용을 함께 확인해야 합니다.

• 어떤 데이터를 가져오거나 보낼 것인가?
• 어느 시스템의 데이터를 원본으로 볼 것인가?
• 실시간으로 연동해야 하는가?
• 하루 또는 일정 시간마다 연동해도 되는가?
• 신규 데이터만 연동하는가?
• 수정과 삭제도 반영해야 하는가?
• 양방향 연동이 필요한가?
• 외부 시스템에서 API를 제공하는가?
• API 사용 계약과 계정 발급은 누가 담당하는가?
• 연동 실패 시 자동으로 다시 시도할 것인가?
• 운영자가 실패 원인을 보고 재처리할 수 있는가?

예를 들어 ERP로 주문 정보를 보내는 기능에서 정상 처리만 고려하면 실제 운영 중 다음과 같은 문제가 생길 수 있습니다.

• ERP가 일시적으로 응답하지 않습니다.
• 주문은 생성됐지만 일부 품목만 반영됩니다.
• 응답 지연으로 같은 주문이 두 번 전송됩니다.
• ERP의 거래처 코드와 신규 시스템의 거래처가 연결되지 않습니다.
• 시스템에는 완료로 표시됐지만 ERP에는 데이터가 없습니다.

따라서 연동 기능의 견적에는 연결 개발뿐 아니라 로그, 실패 상태, 재시도, 중복 방지, 운영자 확인과 재처리 기능이 포함되어 있는지 확인해야 합니다.

외부 연동은 상대 시스템의 문서, 테스트 환경, 호출 제한과 제공 기능에 영향을 받습니다. 개발 계약 전에 API 문서와 테스트 계정의 제공 가능 여부를 확인하면 일정과 범위를 보다 현실적으로 협의할 수 있습니다.

관리자 페이지는 목록 화면보다 검색·필터·일괄 처리 범위가 중요합니다

관리자 페이지가 있다고 해서 운영 업무가 자동으로 줄어드는 것은 아닙니다.

운영자가 필요한 데이터를 찾지 못하거나 여러 건을 하나씩 수정해야 한다면 결국 엑셀을 다시 사용하게 됩니다.

관리자 페이지를 설계할 때는 메뉴 수보다 운영자가 하루에 반복하는 행동을 확인하는 것이 좋습니다.

검색과 필터

운영자가 자주 찾는 조건을 기준으로 설계합니다.

• 접수일과 처리일
• 현재 상태
• 담당자
• 거래처
• 상품 또는 서비스
• 승인 여부
• 결제 상태
• 정산 상태
• 외부 연동 성공 여부
• 보완 요청 여부

필터가 여러 개라면 조합 검색이 가능한지, 자주 쓰는 검색 조건을 저장할 필요가 있는지도 검토할 수 있습니다.

일괄 처리

같은 작업을 여러 건에 반복한다면 일괄 처리 기능이 필요할 수 있습니다.

• 담당자 일괄 배정
• 상태 일괄 변경
• 승인 요청 일괄 발송
• 알림 일괄 발송
• 선택 데이터 다운로드
• 외부 시스템 일괄 재전송

다만 일괄 처리는 실수의 영향도 크기 때문에 처리 전 확인, 권한 제한, 처리 결과 표시와 변경 이력을 함께 설계해야 합니다.

변경 이력

여러 명이 사용하는 시스템이라면 현재 값만 저장해서는 문제의 원인을 찾기 어렵습니다.

최소한 중요한 업무 데이터에는 다음 내용이 필요할 수 있습니다.

• 작업자
• 작업 시간
• 변경한 항목
• 변경 전 값
• 변경 후 값
• 변경 사유
• 처리한 화면 또는 기능

특히 개인정보를 처리하는 시스템은 접속기록의 보관과 점검 범위도 함께 검토해야 합니다. 2026년 7월 1일부터 시행된 개인정보의 안전성 확보조치 기준은 개인정보처리시스템 접속기록을 원칙적으로 1년 이상 보관하도록 하고, 일정 조건에 해당하면 2년 이상 보관하도록 규정하고 있습니다. 개인정보 다운로드 상황의 점검 절차와 접속기록의 안전한 보관도 요구됩니다. 실제 적용 범위는 사업의 데이터와 운영 조건에 따라 확인해야 합니다. (law.go.kr)

다운로드와 보고서

엑셀 다운로드 기능도 단순히 ‘전체 다운로드’로 정의하면 부족할 수 있습니다.

• 검색 결과만 다운로드할 것인가?
• 선택한 항목만 내려받을 수 있는가?
• 어떤 열을 포함할 것인가?
• 개인정보는 마스킹할 것인가?
• 대량 다운로드는 별도 승인이 필요한가?
• 누가 언제 어떤 데이터를 내려받았는지 기록할 것인가?

관리자 페이지는 사용자 화면보다 디자인이 단순해 보일 수 있지만, 실제로는 권한, 데이터 조회, 상태 변경, 일괄 처리와 이력 관리가 집중되는 업무 시스템입니다. 따라서 견적을 비교할 때도 ‘관리자 페이지 포함’이라는 한 줄보다 세부 기능을 확인해야 합니다.

1차 구축 기능과 추후 확장 기능을 나눠 견적을 비교하세요

현재 업무를 모두 분석하면 필요한 기능이 빠르게 늘어날 수 있습니다.

• 거래처 관리
• 직원 관리
• 권한 설정
• 신청과 승인
• 알림
• 전자문서
• 결제
• 정산
• ERP 연동
• 통계
• 대시보드
• 모바일 앱
• AI 자동 분류

모든 기능을 한 번에 개발하려 하면 초기 비용과 일정이 커질 뿐 아니라 실제 사용 전에 복잡한 정책을 확정해야 할 수 있습니다.

따라서 시스템개발업체에 견적을 요청할 때는 기능을 다음과 같이 나누는 것이 좋습니다.

1차 구축에 포함할 기능

없으면 핵심 업무가 시스템 안에서 완료되지 않는 기능입니다.

• 사용자 로그인과 기본 권한
• 핵심 기준정보 관리
• 업무 등록과 조회
• 필수 상태값
• 담당자 배정
• 핵심 승인 절차
• 관리자 검색과 필터
• 주요 변경 이력
• 기본 알림
• 운영에 필요한 데이터 이전

추후 확장을 검토할 기능

1차 운영 데이터를 확인한 뒤 추가해도 되는 기능입니다.

• 고급 통계와 대시보드
• 복잡한 자동 배정
• 다양한 보고서 서식
• 모든 외부 시스템의 동시 연동
• 세부 알림 설정
• 모바일 앱
• AI 기반 분류와 추천
• 예외적인 승인 절차의 완전 자동화

기능을 나눌 때는 개발이 쉬운 순서보다 업무가 실제로 이어지는지를 기준으로 판단해야 합니다.

예를 들어 주문 등록 기능만 만들고 승인과 출고 처리를 제외하면 사용자는 시스템에 주문을 입력하더라도 운영자는 다시 엑셀로 업무를 이어가야 합니다. 이 경우 사용자 화면은 완성되어도 자동화 효과는 제한적입니다.

견적서에서는 다음 항목을 구분해 비교할 수 있습니다.

| 비교 항목 | 확인할 내용 |<br>|---|---|<br>| 기획 | 업무 분석, 요구사항 정의, 화면 설계 포함 여부 |<br>| 디자인 | 사용자 화면과 관리자 화면 범위 |<br>| 사용자 기능 | 직원·고객·거래처별 제공 기능 |<br>| 백엔드 | 업무 규칙, 상태값, 승인, 알림 처리 |<br>| 관리자 | 검색, 필터, 일괄 처리, 권한, 이력 |<br>| 데이터 이전 | 분석·정제·시험 이전·본 이전 포함 여부 |<br>| 외부 연동 | 정상 처리뿐 아니라 실패 대응 포함 여부 |<br>| 테스트 | 기능·권한·데이터·연동 테스트 범위 |<br>| 배포 | 서버 설정, 도메인, 인증서, 운영 반영 |<br>| 인수인계 | 소스코드, 계정, 문서, 운영 안내 |<br>| 유지보수 | 하자 수정과 기능 변경의 구분 |

요구사항과 포함 범위가 다르면 총견적만으로 업체를 비교하기 어렵습니다. 먼저 동일한 기준표를 전달한 뒤 업체별 포함·제외 항목과 전제 조건을 비교하는 편이 좋습니다.

테스트·배포·소스코드 인수인계·유지보수 조건도 계약 전에 확인해야 합니다

시스템 개발은 화면 구현이 끝났다고 완료되는 것이 아닙니다.

실제 데이터와 사용자 권한을 적용하고 운영 환경에 배포한 뒤에도 정상적으로 업무가 이어져야 합니다.

KISA의 소프트웨어 개발보안 가이드는 개발 초기부터 보안 요구사항을 반영할 수 있도록 안내하고 있으며, 관련 공식 인증 안내에서도 요구사항 분석, 설계, 구현, 테스트와 유지보수로 이어지는 단계별 관리의 필요성을 제시하고 있습니다. (kisa.or.kr)

테스트 범위

다음 항목이 테스트에 포함되는지 확인합니다.

• 사용자 유형별 로그인
• 조회·수정·승인·다운로드 권한
• 정상적인 업무 처리 흐름
• 반려·취소·보완 요청과 같은 예외 흐름
• 중복 등록 방지
• 잘못된 입력값 처리
• 대량 데이터 검색과 다운로드
• 데이터 이전 결과
• 외부 API 정상·실패·지연 상황
• 알림 발송과 링크 이동
• 주요 브라우저와 모바일 화면
• 운영자 일괄 처리

검수 기준도 “정상 작동”처럼 포괄적으로 적기보다 주요 시나리오와 기대 결과를 정리하는 것이 좋습니다.

배포 범위

• 운영 서버는 누가 준비하는가?
• 클라우드 계정은 누구 명의로 생성하는가?
• 도메인과 보안 인증서는 누가 관리하는가?
• 개발·검수·운영 환경을 분리하는가?
• 배포 중 기존 업무를 중단해야 하는가?
• 문제 발생 시 이전 버전으로 되돌릴 수 있는가?
• 백업은 어떤 주기와 방식으로 수행하는가?

인수인계 범위

• 전체 소스코드를 전달받는가?
• 소스코드 저장소의 소유권과 접근 권한은 누구에게 있는가?
• 서버와 데이터베이스 계정을 인계받는가?
• 도메인·클라우드·외부 서비스 계정을 확인할 수 있는가?
• 데이터베이스 구조나 API 문서가 제공되는가?
• 배포 방법과 환경 설정이 문서화되는가?
• 관리자 사용 방법을 안내받는가?
• 제3의 개발사가 유지보수를 이어갈 수 있는가?

계정과 소스코드 소유권은 계약 방식과 협의 조건에 따라 달라질 수 있으므로 계약 전에 명확히 적어두는 것이 좋습니다.

유지보수 범위

하자 수정과 추가 개발을 구분해야 합니다.

• 계약된 기능이 동작하지 않는 경우
• 특정 브라우저나 기기에서 발생한 오류
• 외부 API 정책 변경으로 필요한 수정
• 운영 정책 변경에 따른 기능 수정
• 새로운 승인 단계 추가
• 화면과 보고서 항목 추가
• 서버와 데이터베이스 점검
• 보안 업데이트
• 장애 대응 시간과 연락 방법

모든 변경을 무상 수정으로 보거나, 반대로 모든 문제를 추가 개발로 처리하면 분쟁이 생기기 쉽습니다. 하자 보증 기간, 유지보수 계약 범위, 월별 지원 시간, 긴급 장애 대응과 추가 개발의 산정 방식을 미리 확인하는 편이 좋습니다.

시스템개발업체에 상담할 때 준비하면 좋은 자료

완성된 기획서가 없어도 다음 자료를 준비하면 상담의 정확도를 높일 수 있습니다.

현재 업무 자료

• 현재 사용하는 엑셀 파일의 샘플
• 신청서, 주문서, 계약서, 정산서 양식
• 업무 매뉴얼
• 자주 사용하는 보고서
• 담당자별 업무 목록
• 기존 시스템 화면
• 외부 시스템 또는 ERP 정보

사용자와 권한

• 시스템 사용자 유형
• 사용자별 주요 업무
• 조회할 수 있는 데이터 범위
• 등록·수정·승인·다운로드 권한
• 소속 회사·부서별 데이터 분리 여부

업무 흐름

• 업무 시작 조건
• 담당자 처리 순서
• 승인과 반려 기준
• 완료 조건
• 취소와 수정 절차
• 예외 상황과 현재 대응 방식

데이터와 연동

• 이전해야 할 파일과 데이터 양
• 중복·누락 데이터 여부
• 연동 대상 시스템
• API 문서와 테스트 계정 제공 여부
• 실시간 또는 주기적 연동 여부
• 실패 시 운영 방식

구축과 운영 조건

• 희망 공개 시점
• 1차 적용 부서
• 내부 담당자
• 기존 업무와 병행할 기간
• 서버 운영 방식
• 유지보수 필요 범위
• 장기적으로 추가할 기능

이 자료가 모두 준비되지 않았더라도 괜찮습니다. 다만 현재 정해진 내용과 아직 결정하지 못한 내용을 구분해 전달하는 것이 중요합니다.

시스템개발업체가 불확실한 항목을 질문하고, 대안별 차이를 설명하며, 1차 구축과 추후 확장을 구분해 제안하는지도 함께 살펴볼 수 있습니다.

원소프트가 시스템 개발에서 확인하는 기준

원소프트는 웹·앱·AI 및 관리자 시스템 개발을 진행할 때 고객의 요구사항을 화면 목록으로만 해석하지 않습니다.

사용자가 어떤 정보를 입력하고, 운영자가 이를 어떻게 검토하며, 승인·결제·정산·알림과 같은 후속 업무가 어떤 순서로 이어지는지를 함께 확인합니다.

부동산 경매 업무 통합 플랫폼인 바토너 프로젝트에서는 경매 물건 조회부터 입찰 신청, 계약 문서 처리, 결제, 포인트, 정산, 알림과 고객 문의까지 이어지는 백엔드와 API를 개발했습니다.

이 과정에서 일반 회원, 전문가, 운영자 등 사용자 유형별 인증과 권한을 구분하고, 입찰·계약·결제·정산의 상태를 하나의 업무 흐름으로 연결했습니다. 또한 운영자가 회원, 입찰, 결제, 정산과 문의 데이터를 관리할 수 있는 기능을 구성하고 OCR, 결제, 푸시 알림 같은 외부 서비스도 업무 과정에 맞게 연동했습니다.

이처럼 업무형 시스템은 사용자 화면 하나만으로 완성되지 않습니다.

• 사용자가 신청한 뒤 누가 처리하는가?
• 현재 업무 상태는 어떻게 구분하는가?
• 역할에 따라 어떤 데이터까지 볼 수 있는가?
• 결제와 정산 내역을 어떻게 연결하는가?
• 문서 입력과 알림을 어디까지 자동화하는가?
• 운영자는 오류나 예외 상황을 어떻게 확인하는가?

이 질문이 함께 정리되어야 실제 운영 가능한 범위를 설계할 수 있습니다.

시스템개발업체 비교 체크리스트

마지막으로 업체 상담과 견적 비교에 활용할 수 있는 항목을 정리해보겠습니다.

업무 자동화

• [ ] 현재 수작업과 반복 입력 업무를 확인했는가?
• [ ] 자동화할 단계와 사람이 확인할 단계를 구분했는가?
• [ ] 정상 처리뿐 아니라 반려·취소·수정 절차를 정했는가?
• [ ] 자동화 실패 시 운영자가 처리할 방법이 있는가?

사용자와 권한

• [ ] 고객·거래처·직원·관리자 유형을 구분했는가?
• [ ] 역할별 조회·등록·수정·승인 권한을 정했는가?
• [ ] 회사·부서·담당자별 데이터 접근 범위를 확인했는가?
• [ ] 개인정보 마스킹과 다운로드 권한을 검토했는가?

업무 상태와 승인

• [ ] 현재 업무 단계를 상태값으로 구분했는가?
• [ ] 각 상태에서 가능한 행동을 정의했는가?
• [ ] 승인 조건과 승인자를 정했는가?
• [ ] 보완·반려·재승인 절차를 포함했는가?

데이터와 연동

• [ ] 기존 엑셀과 파일의 종류를 확인했는가?
• [ ] 데이터 중복·누락·형식 차이를 점검했는가?
• [ ] 시험 이전과 본 이전 범위를 구분했는가?
• [ ] 외부 API·ERP 연동 데이터를 정했는가?
• [ ] 연동 실패·중복·지연 대응이 포함되어 있는가?

관리자 운영

• [ ] 운영자가 자주 사용하는 검색 조건이 반영되었는가?
• [ ] 일괄 처리할 업무를 확인했는가?
• [ ] 중요 데이터의 변경 이력을 남기는가?
• [ ] 오류와 연동 실패를 확인할 수 있는가?
• [ ] 다운로드 범위와 이력을 관리하는가?

계약과 운영

• [ ] 1차 구축과 추후 확장 기능을 구분했는가?
• [ ] 테스트 시나리오와 검수 기준이 있는가?
• [ ] 서버·도메인·외부 서비스 계정 주체를 정했는가?
• [ ] 소스코드와 문서 인수인계 범위를 확인했는가?
• [ ] 하자 수정과 추가 개발의 기준을 구분했는가?
• [ ] 유지보수와 장애 대응 조건을 확인했는가?

시스템개발업체를 선정하는 기준은 기능을 많이 제안하는지, 가장 낮은 견적을 제시하는지에만 있지 않습니다.

현재 업무의 문제를 이해하고, 사용자와 운영자의 흐름을 구분하며, 필요한 자동화와 예외 대응 범위를 현실적으로 설명할 수 있는지를 함께 살펴봐야 합니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·AI·관리자 시스템 개발사입니다.

엑셀과 메신저로 처리하던 업무를 웹 시스템으로 전환하거나 기존 사내 시스템을 개선하려는 경우, 현재 업무 자료와 사용자 유형을 바탕으로 1차 구축 범위와 추후 확장 범위를 함께 정리해드릴 수 있습니다.

제목 후보

1. 시스템개발업체 선정 전, 업무 자동화와 관리자 운영 범위를 확인하는 방법
2. 시스템개발업체 비교, 엑셀 업무를 어디까지 자동화할지 먼저 정하세요
3. 시스템개발업체 견적 비교 전 확인할 권한·데이터·관리자 기능
4. 시스템개발업체 선택, 화면보다 실제 업무 처리 범위를 확인하세요
5. 시스템개발업체 문의 전, 업무 흐름과 관리자 운영을 정리하는 기준

추천 제목

시스템개발업체 선정 전, 업무 자동화와 관리자 운영 범위를 확인하는 방법

메인 키워드

시스템개발업체

서브 키워드

1. 업무자동화시스템
2. 관리자시스템개발
3. 사내시스템개발
4. 웹시스템개발
5. 업무관리시스템

추천 해시태그

#시스템개발업체 <br>#업무자동화시스템 <br>#관리자시스템개발 <br>#사내시스템개발 <br>#웹시스템개발 <br>#업무관리시스템 <br>#맞춤형웹개발 <br>#동탄개발업체 <br>#화성웹개발 <br>#경기남부웹개발

썸네일 문구

1. 시스템개발업체, 무엇을 비교해야 할까?
2. 업무 자동화 범위부터 확인하세요
3. 관리자 운영까지 포함된 견적인가요?

글 요약

시스템개발업체를 비교할 때는 화면 디자인과 총견적보다 현재 엑셀·메신저 업무 중 어디까지 자동화할지 먼저 정해야 합니다. 사용자별 권한, 상태값과 승인 절차, 데이터 이전, API·ERP 연동, 관리자 검색·일괄 처리·변경 이력과 테스트·인수인계·유지보수 범위를 동일한 기준으로 확인하는 방법을 정리했습니다.

CTA 후보

1. 현재 사용 중인 엑셀 파일과 업무 처리 순서가 있다면 이를 기준으로 사용자 기능, 관리자 기능, 데이터 이전과 연동 범위를 함께 구분해볼 수 있습니다.

1. 사내 업무를 웹 시스템으로 전환하려 하지만 1차 구축 범위가 정리되지 않았다면, 현재 운영 방식에서 반복 작업과 핵심 승인 절차부터 확인해보시기 바랍니다. 원소프트가 요구사항과 단계별 구축 범위를 정리하는 과정을 도와드릴 수 있습니다.

관련 포트폴리오

• 바토너(Batoner) – 부동산 경매 업무 통합 플랫폼
• 참고한 부분: 일반 회원·전문가·운영자별 인증 및 권한 처리, 입찰 신청부터 계약·결제·정산까지 이어지는 상태 기반 업무 흐름, OCR·결제·푸시 알림 연동, 회원·입찰·결제·정산·문의 데이터를 관리하는 관리자 기능

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

1. 업무자동화시스템 개발, 자동 처리와 담당자 검수를 나누는 기준
2. 데이터 이전 개발, 엑셀 중복·누락 데이터를 정리하고 검수하는 방법
3. 관리자시스템개발 견적, 검색·일괄 처리·변경 이력에서 범위가 달라지는 이유