시스템개발업체 문의 전, 엑셀·메신저 업무를 웹 시스템으로 전환하는 실무 기준

고객 요청은 메신저로 받고, 처리 현황은 담당자별 엑셀 파일에 기록하고, 최종 결과는 다시 이메일로 전달하는 업무가 있습니다.

업무량이 적고 담당자가 고정되어 있을 때는 이런 방식으로도 운영할 수 있습니다. 하지만 고객과 거래처가 늘고 여러 부서가 함께 일하기 시작하면 상황이 달라집니다.

최신 파일이 무엇인지 확인하기 어렵습니다.
담당자가 자리를 비우면 처리 경과를 알 수 없습니다.
같은 내용을 여러 문서에 반복해서 입력합니다.
승인 여부와 최종 처리 상태가 메신저 대화에 남습니다.
지난달 자료를 찾거나 통계를 만들 때마다 데이터를 다시 정리합니다.
특정 직원만 알고 있는 업무 규칙이 늘어납니다.

이때 기업은 엑셀과 메신저로 처리하던 업무를 웹 기반 시스템으로 전환하기 위해 시스템개발업체를 찾게 됩니다.

다만 기존 업무를 그대로 화면에 옮기는 것만으로는 운영 가능한 시스템이 만들어지기 어렵습니다. 현재 사용 중인 엑셀의 열을 입력 항목으로 만들고, 메신저에서 하던 요청을 게시판으로 바꾸는 정도라면 새로운 시스템과 기존 수작업을 함께 사용하는 상황이 생길 수 있습니다.

시스템 개발을 문의하기 전에는 화면보다 먼저 업무의 시작과 종료, 사용자 유형, 권한, 승인 절차, 데이터 구조, 예외 처리 방식을 정리해야 합니다.

시스템개발업체에 문의하기 전, 먼저 업무 문제를 정의해야 합니다

“엑셀을 없애고 싶습니다”라는 목표만으로는 개발 범위를 정하기 어렵습니다.

엑셀은 현재 업무를 처리하는 도구일 뿐입니다. 실제 문제는 엑셀 자체가 아니라 업무 정보가 여러 곳에 흩어져 있거나, 담당자가 같은 데이터를 반복해서 입력하거나, 처리 상태를 공유하기 어렵다는 데 있을 수 있습니다.

따라서 개발 문의 전에는 다음 세 가지를 구분하는 것이 좋습니다.

1. 현재 어떤 문제가 발생하고 있는가

막연하게 “업무가 불편하다”고 설명하기보다 실제로 발생하는 상황을 적어보는 편이 좋습니다.

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

영업팀과 운영팀이 서로 다른 고객 목록을 사용합니다.
주문 변경 내용을 메신저로 전달해 누락이 발생합니다.
최종 승인된 금액이 어느 파일에 있는지 찾기 어렵습니다.
거래처별 가격을 담당자가 직접 확인해 입력합니다.
담당자가 퇴사하거나 휴가를 가면 업무 인계가 어렵습니다.
처리 완료 여부를 확인하기 위해 여러 사람에게 물어봐야 합니다.
월말 보고서를 만들기 위해 여러 엑셀 파일을 합쳐야 합니다.

이런 문제는 시스템에서 필요한 기능을 찾는 출발점이 됩니다.

예를 들어 주문 변경이 자주 누락된다면 단순한 주문 등록 화면보다 변경 요청, 승인, 반려, 확정 이력을 관리하는 구조가 필요할 수 있습니다.

2. 시스템 도입 후 무엇이 달라져야 하는가

목표는 기능명이 아니라 업무 결과로 표현하는 것이 좋습니다.

“고객 관리 기능이 필요합니다”보다는 다음과 같이 정리할 수 있습니다.

영업 담당자와 운영 담당자가 동일한 고객 정보를 확인해야 합니다.
고객별 상담, 견적, 주문 이력을 한 화면에서 확인해야 합니다.
주문이 변경되면 관련 담당자에게 알림이 전달되어야 합니다.
승인되지 않은 주문은 출고 단계로 넘어가지 않아야 합니다.
월별 실적을 별도의 엑셀 취합 없이 확인할 수 있어야 합니다.

이렇게 정리하면 시스템개발업체도 단순히 메뉴를 만드는 것이 아니라 업무가 연결되는 방식을 파악할 수 있습니다.

3. 반드시 시스템에 포함해야 할 범위는 어디까지인가

모든 수작업을 첫 개발에서 자동화하려 하면 범위가 빠르게 커질 수 있습니다.

초기에는 다음 기준으로 기능을 나눠볼 수 있습니다.

| 구분 | 판단 기준 | 예시 | |---|---|---| | 1차 필수 | 없으면 핵심 업무를 처리할 수 없는 기능 | 고객 등록, 주문 접수, 승인, 상태 변경 | | 운영 필수 | 담당자가 실제 운영하기 위해 필요한 기능 | 검색, 필터, 담당자 배정, 이력 확인 | | 효율 개선 | 없어도 운영은 가능하지만 반복 업무를 줄이는 기능 | 일괄 처리, 자동 알림, 통계 | | 추후 확장 | 데이터가 쌓이거나 운영 기준이 정해진 후 필요한 기능 | 고급 분석, 자동 배정, AI 기능 |

처음부터 모든 기능을 넣는 것보다 핵심 업무가 시스템 안에서 처음부터 끝까지 완료되는지를 먼저 확인하는 편이 현실적입니다.

회사 소개형 홈페이지와 업무용 시스템 개발은 다릅니다

회사 소개형 홈페이지는 기업 정보, 서비스, 제품, 문의 방법을 방문자에게 전달하는 것이 주된 목적입니다.

반면 업무용 웹 시스템은 사용자가 로그인한 뒤 데이터를 등록하고, 다른 담당자가 이를 검토하거나 승인하며, 운영자가 전체 처리 상황을 관리하는 구조를 갖습니다.

두 프로젝트는 모두 웹브라우저에서 이용할 수 있지만 개발 범위는 다르게 구성됩니다.

| 구분 | 회사 소개형 홈페이지 | 업무용 웹 시스템 | |---|---|---| | 주된 목적 | 회사와 서비스 정보 전달 | 업무 등록·처리·승인·관리 | | 사용자 | 일반 방문자 중심 | 직원, 거래처, 관리자 등 | | 로그인 | 없거나 단순 회원 기능 | 역할별 로그인과 권한 필요 | | 데이터 | 게시물과 문의 정보 중심 | 고객, 주문, 예약, 계약, 정산 등 | | 상태 관리 | 상대적으로 단순 | 접수·검토·승인·완료 등 단계 필요 | | 관리자 | 콘텐츠 수정 중심 | 검색, 처리, 승인, 통계, 이력 관리 | | 외부 연동 | 지도, 문의 알림 등 | ERP, 결제, 배송, 회계, 사내 시스템 등 | | 테스트 | 화면과 문의 작동 확인 | 권한, 상태 전환, 예외 상황까지 확인 |

예를 들어 “거래처가 주문할 수 있는 홈페이지”를 만든다고 해도 실제로는 거래처 계정, 거래처별 상품과 가격, 주문 승인, 출고 상태, 주문 이력, 관리자 처리 기능이 포함된 B2B 주문 시스템일 수 있습니다.

따라서 시스템개발업체에 문의할 때는 “페이지가 몇 개 필요하다”보다 다음 내용을 먼저 전달하는 편이 좋습니다.

누가 사용하는 시스템인가
사용자는 어떤 업무를 처리하는가
처리 결과를 다음에 누가 확인하는가
승인이나 검토가 필요한 단계가 있는가
처리 과정에서 어떤 데이터가 생성되는가
운영자는 무엇을 검색하고 수정해야 하는가

이 정보가 있어야 홈페이지 제작 범위인지, 업무 시스템 개발 범위인지 구분할 수 있습니다.

사용자 유형과 권한을 먼저 나눠야 합니다

업무 시스템에서는 모든 사용자가 같은 기능을 이용하지 않습니다.

직원과 고객을 구분하는 것만으로도 부족할 수 있습니다. 같은 직원이라도 영업, 운영, 정산, 관리자에 따라 필요한 정보와 수행할 수 있는 작업이 달라집니다.

예를 들어 주문 시스템의 사용자를 다음과 같이 나눌 수 있습니다.

거래처 담당자: 상품 조회, 주문 등록, 본인 회사 주문 확인
영업 담당자: 담당 거래처 확인, 견적 등록, 주문 검토
운영 담당자: 주문 확정, 출고 준비, 상태 변경
정산 담당자: 결제 및 세금계산서 관련 정보 확인
관리자: 사용자, 권한, 기준정보와 전체 데이터 관리

이때 “관리자는 모든 기능을 이용한다”는 정도로만 정의하면 실제 개발 과정에서 권한 관련 질문이 계속 발생합니다.

사용자 유형별로 다음 항목을 정리해야 합니다.

어떤 데이터를 조회할 수 있는가
어떤 데이터를 새로 등록할 수 있는가
본인이 작성한 데이터만 수정할 수 있는가
다른 담당자의 데이터도 수정할 수 있는가
승인과 반려를 할 수 있는가
엑셀 다운로드가 가능한가
고객의 개인정보를 모두 볼 수 있는가
삭제하거나 복구할 수 있는가
다른 사용자에게 업무를 배정할 수 있는가

권한은 메뉴를 보이거나 숨기는 기능에만 머물러서는 안 됩니다. 사용자가 주소나 요청 값을 바꿔 다른 회사 또는 다른 담당자의 데이터에 접근하지 못하도록 서버에서도 요청마다 권한을 확인해야 합니다. OWASP도 필요한 최소 권한만 부여하고, 사용자 유형과 자원별로 조회·등록·수정 같은 작업 권한을 설계하며, 각 요청에서 권한을 검증하는 방식을 권고합니다. (cheatsheetseries.owasp.org)

권한을 표로 정리하면 개발사와 의사소통하기 쉬워집니다.

| 기능 | 거래처 | 영업 | 운영 | 관리자 | |---|---:|---:|---:|---:| | 상품 조회 | 가능 | 가능 | 가능 | 가능 | | 주문 등록 | 가능 | 가능 | 가능 | 가능 | | 전체 주문 조회 | 불가 | 담당 거래처만 | 가능 | 가능 | | 주문 승인 | 불가 | 조건부 | 가능 | 가능 | | 가격 수정 | 불가 | 조건부 | 불가 | 가능 | | 엑셀 다운로드 | 본인 회사만 | 담당 범위 | 가능 | 가능 | | 사용자 권한 변경 | 불가 | 불가 | 불가 | 가능 |

실제 권한은 회사의 업무 방식에 따라 달라져야 합니다. 중요한 것은 직급이나 부서명만 적는 것이 아니라 각 사용자가 어떤 데이터에 어떤 행동을 할 수 있는지까지 정리하는 것입니다.

승인 절차는 정상 흐름과 반려 흐름을 함께 봐야 합니다

기존 업무에서는 담당자가 메신저로 “확인했습니다”, “진행해주세요”라고 전달하는 것이 승인 역할을 할 수 있습니다.

시스템에서는 이 절차를 상태와 권한으로 표현해야 합니다.

예를 들어 견적 업무라면 다음과 같은 흐름이 있을 수 있습니다.

견적 작성 → 내부 검토 요청 → 승인 또는 반려 → 고객 전달 → 수정 요청 → 최종 확정

여기서 확인해야 할 사항은 단순히 승인 버튼의 유무가 아닙니다.

누가 승인 요청을 할 수 있는가
승인자는 한 명인가, 여러 명인가
일정 금액 이상일 때 추가 승인이 필요한가
승인 전에는 고객에게 노출되지 않아야 하는가
반려할 때 사유 입력이 필수인가
반려 후 기존 문서를 수정하는가, 새 버전을 만드는가
이미 승인된 내용을 변경하면 다시 승인받아야 하는가
담당자가 부재 중일 때 대리 승인할 수 있는가

승인 절차를 너무 복잡하게 만들면 시스템 도입 후 오히려 처리 시간이 길어질 수 있습니다. 반대로 실제 승인 규칙을 생략하면 직원들이 시스템 밖의 메신저에서 다시 확인을 받게 됩니다.

현재 업무에 존재하는 승인 절차와 관행상 반복되는 확인 절차를 구분한 뒤, 시스템에 남겨야 하는 것만 반영하는 것이 좋습니다.

회원·주문·예약·문의 데이터는 상태값과 함께 설계해야 합니다

업무 시스템의 핵심은 화면보다 데이터입니다.

엑셀에서는 한 셀에 “입금 확인 후 다음 주 출고 예정, 고객에게 연락 완료”처럼 여러 내용을 적을 수 있습니다. 담당자가 읽으면 의미를 이해할 수 있지만 시스템이 자동으로 검색하거나 통계를 만들기는 어렵습니다.

웹 시스템에서는 이를 구분된 데이터로 관리해야 합니다.

결제 상태: 결제 대기
출고 예정일: 9월 30일
출고 상태: 준비 중
고객 안내 여부: 안내 완료
담당자: 운영팀 A
특이사항: 요청 내용 별도 기록

회원 데이터

회원이나 거래처 정보는 이름과 연락처만 저장하는 것으로 끝나지 않을 수 있습니다.

개인 회원인지 기업 회원인지
기업과 담당자는 어떤 관계인지
한 기업에 여러 담당자가 가입할 수 있는지
담당자가 퇴사하면 계정을 어떻게 처리할지
휴면, 이용 정지, 탈퇴 상태를 구분할지
고객별 계약 조건이나 등급이 있는지
개인정보와 내부 메모의 열람 권한을 구분할지

주문 데이터

주문은 주문번호 하나만으로 관리하기 어렵습니다.

상품, 옵션, 수량, 금액, 할인, 세금, 배송지, 결제 상태, 출고 상태와 취소 여부가 서로 연결됩니다.

특히 주문 상태와 결제 상태를 하나로 합치면 예외 상황을 처리하기 어려울 수 있습니다.

예를 들어 주문은 접수되었지만 결제는 대기 중일 수 있고, 결제는 완료됐지만 재고 부족으로 출고가 보류될 수도 있습니다. 결제가 취소되었지만 환불 처리가 아직 완료되지 않은 상황도 발생할 수 있습니다.

예약 데이터

예약 시스템은 예약 일시만 저장하는 것이 아니라 예약 대상과 가능 조건을 함께 관리해야 합니다.

공간을 예약하는지
담당자를 예약하는지
장비 또는 수량을 예약하는지
예약 신청 즉시 확정되는지
운영자의 승인이 필요한지
결제 완료 후 확정되는지
취소 가능 기한과 수수료 기준이 있는지
일정 변경이 가능한지

문의 데이터

문의 역시 접수된 글을 보는 기능만으로는 운영하기 어렵습니다.

접수, 확인 중, 담당자 배정, 답변 완료, 추가 확인 필요, 종료 등의 상태가 필요할 수 있습니다. 담당자와 처리 기한, 답변 내용, 내부 메모를 구분해야 할 수도 있습니다.

상태값은 많을수록 좋은 것이 아닙니다. 실제 업무 단계와 연결되지 않는 상태가 많으면 담당자가 무엇을 선택해야 하는지 판단하기 어려워집니다.

반대로 상태가 지나치게 단순하면 상세 진행 상황을 다시 메신저나 엑셀에 기록하게 됩니다. 현재 업무에서 다음 담당자에게 전달되는 기준을 중심으로 상태를 설계하는 편이 좋습니다.

관리자 페이지는 조회 화면이 아니라 운영 도구여야 합니다

사용자용 화면이 잘 만들어져도 관리자 페이지가 실제 업무와 맞지 않으면 엑셀 사용은 계속될 수 있습니다.

예를 들어 주문 목록을 볼 수는 있지만 주문번호만 검색할 수 있다면 운영팀은 고객명, 연락처, 상품, 담당자, 기간, 결제 상태별로 찾기 위해 데이터를 내려받게 됩니다.

관리자 기능은 다음과 같은 실제 업무를 기준으로 검토해야 합니다.

검색과 필터

목록이 많아질수록 검색 조건이 중요해집니다.

이름, 회사명, 연락처, 주문번호 통합 검색
등록일, 예약일, 출고일 등 기간 검색
담당자별 필터
처리 상태별 필터
결제 여부별 필터
거래처나 서비스 유형별 필터
여러 조건을 조합한 검색
자주 사용하는 검색 조건 저장

상세 화면

상세 화면에서는 해당 데이터만 보여주는 것이 아니라 관련 이력도 함께 확인할 수 있어야 합니다.

고객 상세 화면이라면 기본 정보뿐 아니라 상담, 주문, 예약, 결제, 문의, 내부 메모를 연결해서 볼 수 있습니다.

다만 모든 정보를 한 화면에 넣으면 오히려 사용하기 어려울 수 있습니다. 업무 빈도와 담당자의 이용 목적에 따라 탭이나 영역을 나눠야 합니다.

일괄 처리

여러 건을 하나씩 수정하도록 만들면 운영자는 다시 엑셀을 찾게 됩니다.

여러 주문의 담당자 일괄 변경
선택한 예약의 상태 변경
특정 대상에게 알림 발송
거래처별 가격 일괄 등록
선택 데이터 다운로드
엑셀을 이용한 대량 등록

일괄 처리는 편리하지만 잘못 실행했을 때 영향도 큽니다. 실행 전 대상 건수와 변경 내용을 보여주고, 권한을 제한하거나 작업 이력을 남기는 방식을 함께 검토해야 합니다.

변경 이력

현재 값만 저장하면 누가 언제 무엇을 바꿨는지 알기 어렵습니다.

고객 정보, 가격, 결제, 승인 상태처럼 운영에 영향을 주는 데이터는 변경자, 변경 일시, 변경 전후 값과 사유를 남길 필요가 있는지 검토해야 합니다.

OWASP는 데이터의 등록·수정·삭제·내보내기와 같은 활동을 감사 추적 대상으로 예시하고 있으며, 애플리케이션 로그가 장애 원인 파악과 보안 사고 조사, 업무 과정 모니터링에도 활용될 수 있다고 설명합니다. (cheatsheetseries.owasp.org)

모든 항목의 이력을 무조건 저장할 필요는 없습니다. 분쟁, 오류 추적, 보안 또는 내부 승인에 영향을 주는 데이터를 우선해야 합니다.

엑셀 데이터 이전은 파일 업로드 기능과 다릅니다

기존 엑셀을 새 시스템에 옮길 때는 파일을 한 번 업로드하면 끝날 것처럼 보일 수 있습니다.

하지만 실제로는 기존 데이터의 품질과 기준을 먼저 확인해야 합니다.

먼저 확인할 데이터

같은 고객이 서로 다른 이름으로 중복 등록되어 있지 않은가
날짜 형식이 파일마다 다르지 않은가
전화번호와 사업자번호 형식이 일정한가
한 셀에 여러 정보가 함께 들어가 있지 않은가
퇴사자나 종료된 거래처를 어떻게 구분할 것인가
빈 값이 실제 미입력인지, 해당 없음인지
담당자 이름이 현재 사용자 계정과 연결되는가
기존 주문과 결제 데이터를 어떤 기준으로 연결할 것인가

예를 들어 거래처명이 원소프트, (주)원소프트, 원소프트 주식회사로 나뉘어 있다면 새 시스템에 그대로 이전하기 전에 같은 거래처인지 확인해야 합니다.

데이터 이전 과정은 일반적으로 다음과 같이 나눌 수 있습니다.

이전 대상 파일과 시트 확인
새 시스템의 항목과 기존 열 연결
날짜, 전화번호, 코드 등 형식 정리
중복·누락·잘못된 값 검토
일부 데이터를 이용한 시험 이전
사용자 검수
전체 이전
이전 건수와 실패 건 확인

운영자가 앞으로도 엑셀을 이용해 대량 등록해야 한다면 업로드 양식, 필수 항목, 오류 표시 방식도 정해야 합니다.

예를 들어 1,000개 행 중 10개에 오류가 있을 때 전체 등록을 취소할지, 정상 데이터만 등록하고 오류 행을 별도로 안내할지에 따라 운영 방식이 달라집니다.

외부에서 입력되는 데이터는 형식과 허용값을 검증해야 합니다. OWASP도 잘못된 데이터가 데이터베이스와 후속 업무에 들어가지 않도록 가능한 한 데이터 흐름의 초기 단계에서 입력값을 검증할 것을 권고합니다. (cheatsheetseries.owasp.org)

외부 API와 ERP 연동은 데이터의 기준 시스템부터 정해야 합니다

업무 시스템은 ERP, 회계 프로그램, 결제 서비스, 배송사, 문자·알림 서비스 또는 기존 사내 시스템과 연결될 수 있습니다.

이때 “API 연동이 가능한가”만 확인해서는 부족합니다.

어느 시스템의 데이터가 기준인가

고객 주소를 업무 시스템과 ERP에서 모두 수정할 수 있다면 서로 다른 값이 저장될 수 있습니다.

따라서 각 데이터의 원본을 정해야 합니다.

상품과 재고의 기준은 ERP
고객 문의와 처리 이력의 기준은 웹 시스템
결제 승인 상태의 기준은 결제사
배송 상태의 기준은 배송사
사용자 계정과 권한의 기준은 사내 계정 시스템

언제 데이터를 주고받는가

연동 시점도 업무에 영향을 줍니다.

사용자가 요청할 때 즉시 조회
주문 확정 시 ERP로 전송
일정 주기로 일괄 동기화
외부 시스템이 변경 사실을 알려주는 방식
운영자가 관리자에서 재전송

실시간 연동이 항상 더 적합한 것은 아닙니다. 외부 서비스가 느려지거나 일시적으로 중단됐을 때 우리 시스템의 업무까지 멈추지 않도록 대기, 재시도 또는 수동 처리 방식을 함께 고려해야 합니다.

실패하면 어떻게 처리하는가

다음 상황도 개발 범위에 포함해야 합니다.

ERP 전송이 실패했을 때 주문 상태
같은 데이터가 두 번 전송됐을 때 중복 방지
여러 항목 중 일부만 성공했을 때 처리 방식
외부 시스템의 응답이 늦을 때 사용자 안내
운영자가 실패 원인을 확인하는 관리자 화면
재전송 횟수와 실행 권한
연동 요청과 결과를 확인할 수 있는 로그

API 문서가 있다는 사실만으로 연동 가능 여부를 확정하기는 어렵습니다. 필요한 기능이 실제 API로 제공되는지, 사용 권한과 호출 제한이 있는지, 테스트 환경을 제공하는지 확인해야 합니다.

테스트·배포·서버·보안도 견적 범위에 포함해야 합니다

시스템개발업체의 견적을 비교할 때 기능 목록과 총금액만 보면 포함 범위를 정확히 알기 어렵습니다.

기획, 디자인, 개발, 테스트, 서버 설정, 배포, 인수인계가 어디까지 포함되는지 확인해야 합니다.

테스트 범위

정상적으로 등록되는지만 확인하는 것은 충분하지 않을 수 있습니다.

필수값을 입력하지 않았을 때
잘못된 형식의 파일을 올렸을 때
승인 권한이 없는 사용자가 요청했을 때
여러 사용자가 같은 데이터를 동시에 수정했을 때
외부 API가 실패하거나 응답하지 않을 때
이미 처리된 요청이 다시 들어왔을 때
대량 데이터를 조회하거나 등록할 때
모바일이나 다른 브라우저에서 사용할 때

테스트 대상에는 기능뿐 아니라 권한, 보안, 성능과 운영 예외가 포함될 수 있습니다. NIST가 제시한 개발 수명주기 역시 요구사항 정의부터 개발, 빌드, 테스트, 릴리스, 배포, 운영을 연결하고, 이후 운영 단계의 피드백을 다시 계획에 반영하는 구조를 설명합니다. (pages.nist.gov)

서버와 운영 환경

견적에서 다음 항목을 확인해보는 것이 좋습니다.

서버와 데이터베이스를 누가 개설하는가
클라우드 계정은 누구 명의로 만드는가
도메인과 인증서는 누가 관리하는가
개발·테스트·운영 환경을 구분하는가
데이터 백업과 복구 범위는 무엇인가
장애나 오류를 확인할 방법이 있는가
서버 비용과 외부 서비스 이용료는 별도인가
운영 이후 배포는 누가 담당하는가

개인정보를 처리하는 시스템이라면 수집 항목과 이용 목적, 접근 권한, 보관 및 파기 방식 등도 서비스 성격에 맞게 검토해야 합니다. 필요한 조치는 처리하는 정보와 시스템 규모, 관련 법령 및 계약 조건에 따라 달라질 수 있으므로 개발 범위를 정할 때 별도로 확인하는 편이 안전합니다. 국내 개인정보 안전성 확보 기준에서도 접근 권한 관리, 접근 통제, 접속기록, 백업·복구 등 여러 조치가 다뤄집니다. (law.go.kr)

소스코드와 계정 인수인계

개발 완료 후 다음 자료를 받을 수 있는지 확인해야 합니다.

소스코드 저장소와 접근 권한
서버와 클라우드 계정
도메인과 인증서 관리 정보
데이터베이스와 백업 관련 정보
외부 API 및 메시지 발송 계정
배포 방법과 환경 변수 안내
주요 기능과 데이터 구조 문서
관리자 사용 방법
알려진 제한사항과 후속 작업 목록

무조건 많은 문서를 요구하는 것보다 운영과 후속 개발에 필요한 항목을 계약 전에 합의하는 것이 좋습니다.

시스템개발업체 견적을 비교하기 전에 물어볼 질문

업체별 견적을 비교하려면 동일한 요구사항을 전달해야 합니다.

한 업체에는 “주문 관리 시스템”이라고만 설명하고, 다른 업체에는 관리자 기능과 ERP 연동까지 전달했다면 금액을 같은 기준으로 비교하기 어렵습니다.

문의 전 다음 내용을 정리해보세요.

현재 업무 자료

사용 중인 엑셀 파일과 각 열의 의미
업무 요청에 사용하는 문서나 양식
현재 이용 중인 프로그램 목록
메신저로 처리하는 대표적인 업무
자주 발생하는 누락과 오류
월평균 처리 건수와 동시 사용자 규모
기존 데이터의 대략적인 양

민감한 정보는 제거한 예시 파일을 전달해도 됩니다.

사용자와 권한

시스템을 이용할 사용자 유형
유형별 조회·등록·수정·승인 범위
내부 직원과 외부 거래처 구분
개인정보와 금액 정보의 열람 범위
다운로드와 삭제 권한

핵심 업무 흐름

다음과 같이 한 줄로 적어도 도움이 됩니다.

거래처가 주문을 등록하면 영업 담당자가 조건을 확인하고, 운영 담당자가 확정한 뒤 ERP로 전달하고 출고 상태를 관리한다.

정상 흐름뿐 아니라 취소, 반려, 변경, 중복 요청과 연동 실패 상황도 함께 전달하는 것이 좋습니다.

견적 비교 질문

요구사항 분석과 화면 기획은 어디까지 포함되나요?
사용자 화면과 관리자 페이지가 모두 포함되나요?
사용자 유형별 권한은 어떤 방식으로 설계하나요?
엑셀 데이터 정리와 이전은 어느 범위까지 포함되나요?
외부 API나 ERP 연동 실패는 어떻게 확인하고 재처리하나요?
기능 테스트와 사용자 검수는 어떻게 진행하나요?
서버 구축과 운영 배포는 누가 담당하나요?
소스코드와 서버·외부 서비스 계정은 어떻게 인계되나요?
개발 완료 후 하자 수정과 유지보수의 기준은 무엇인가요?
추후 기능을 추가할 때 기존 구조를 확장할 수 있나요?

총견적이 낮더라도 관리자 기능, 데이터 이전, 서버 배포 또는 외부 연동 테스트가 빠져 있다면 실제 필요한 전체 비용은 달라질 수 있습니다.

반대로 초기 단계에서 필요하지 않은 고급 통계와 자동화까지 모두 포함하면 첫 구축 범위가 과도하게 커질 수 있습니다. 포함된 기능뿐 아니라 제외된 기능과 추후 확장 항목을 함께 비교해야 합니다.

원소프트가 업무 시스템의 개발 범위를 검토하는 방식

원소프트는 고객이 요청한 화면 목록만 구현하기보다 서비스 목적과 실제 운영 방식을 함께 확인하는 개발 파트너를 지향합니다.

웹 시스템을 검토할 때는 사용자 화면뿐 아니라 다음 구조를 함께 살펴봅니다.

시스템을 사용하는 사용자와 역할
업무가 시작되고 종료되는 과정
승인, 반려, 취소와 변경 흐름
핵심 데이터와 상태값
관리자 검색·필터·일괄 처리 기능
외부 API와 기존 시스템의 연결 관계
오류 발생 시 운영자의 확인 방법
배포 이후 유지보수와 기능 확장 가능성

프로젝트 상황에 따라 기획, UX/UI 디자인, 프론트엔드, 백엔드, 서버·데이터베이스, 배포와 유지보수를 통합해 진행할 수 있습니다.

기술은 특정 구성을 일괄적으로 적용하기보다 기존 시스템, 필요한 기능, 예상 사용자와 운영 환경에 맞춰 검토합니다. 웹 프론트엔드는 Next.js·React·TypeScript·Vue.js, 백엔드는 NestJS·Node.js·Java/Spring 등을 활용할 수 있으며, 데이터베이스와 AWS·Docker 등의 운영 환경도 프로젝트 조건에 따라 조합합니다.

자체 관리자 템플릿과 효율적인 개발 구조를 활용할 수 있지만, 모든 관리자 시스템을 같은 형태로 만드는 것은 아닙니다. 실제 업무 순서와 필요한 데이터, 담당자의 사용 빈도를 확인해 검색 조건과 처리 기능을 구성해야 합니다.

엑셀과 메신저를 웹 시스템으로 전환하는 목적은 단순히 업무 도구를 바꾸는 것이 아닙니다.

누가 어떤 정보를 확인하고, 어떤 기준으로 처리하며, 다음 담당자에게 무엇을 전달하는지를 시스템 안에서 명확하게 만드는 과정입니다.

현재 업무를 완벽하게 문서화한 뒤에만 개발 문의를 할 수 있는 것은 아닙니다. 사용 중인 엑셀과 양식, 대표적인 업무 흐름, 반복되는 불편을 준비하면 초기 범위를 함께 정리할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·관리자 시스템 개발사입니다. 화성·동탄을 비롯해 경기 남부에서 업무 시스템 구축을 검토하고 계시다면 현재 운영 방식과 필요한 기능을 바탕으로 개발 범위를 함께 살펴볼 수 있습니다.

제목 후보

시스템개발업체 문의 전, 엑셀·메신저 업무를 웹 시스템으로 전환하는 기준
시스템개발업체 선정 전에 정리해야 할 업무 흐름과 관리자 기능
엑셀 업무를 웹 시스템으로 바꾸기 전 확인할 개발 범위 8가지
시스템개발업체 견적 비교, 화면보다 운영 구조를 먼저 확인하세요
업무용 웹 시스템 개발 전, 권한·승인·데이터 구조를 정리하는 방법

메인 키워드

시스템개발업체

서브 키워드

업무시스템개발
웹시스템개발
관리자시스템개발
엑셀업무자동화
사내시스템개발

썸네일 문구

엑셀 업무, 웹 시스템으로 바꾸기 전
시스템 개발 범위부터 정리하세요
운영 가능한 업무 시스템의 기준

※ 실제 썸네일 이미지는 원소프트 블로그 운영 규칙에 따라 텍스트 없이 제작합니다.

글 요약

엑셀과 메신저로 처리하던 업무를 웹 시스템으로 전환하려면 기존 화면을 그대로 옮기기보다 사용자 유형, 권한, 승인 절차, 핵심 데이터와 상태값을 먼저 정리해야 합니다. 관리자 검색·필터·일괄 처리, 엑셀 데이터 이전, 외부 API·ERP 연동, 테스트·배포·인수인계까지 동일한 범위로 확인해야 시스템개발업체의 견적을 현실적으로 비교할 수 있습니다.

CTA 후보

사용 중인 엑셀 파일과 대표적인 업무 흐름이 있다면, 이를 기준으로 웹 시스템에 포함할 기능과 단계별 구축 범위를 함께 정리해드릴 수 있습니다.

사내 업무 시스템 개발을 검토하고 있지만 요구사항을 어디서부터 작성해야 할지 어렵다면, 현재 처리 방식과 반복되는 불편을 바탕으로 필요한 사용자·관리자 기능을 살펴보세요.

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

엑셀 업무 자동화, 웹 시스템 개발이 필요한 시점을 판단하는 기준
사내 시스템 개발 견적서에서 관리자·데이터 이전 범위를 확인하는 방법
업무 시스템 요구사항 정의서, 개발사 문의 전에 준비할 항목 10가지