시스템구축, 화면보다 업무 흐름·권한·데이터·관리자 운영 범위를 먼저 정하세요

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

“직원마다 사용하는 파일이 달라서 최신 데이터를 찾기 어렵습니다.”

“기존 솔루션을 사용하고 있지만 우리 회사의 승인 절차와 맞지 않습니다.”

시스템구축을 검토하는 기업에서 자주 나오는 이야기입니다.

처음에는 필요한 화면을 몇 개 만들고 데이터를 등록하면 해결될 것처럼 보일 수 있습니다. 하지만 실제 업무에서는 한 사람이 정보를 입력한 뒤 다른 담당자가 확인하고, 책임자가 승인하며, 운영자가 결과를 수정하거나 외부 시스템으로 전달하는 과정이 이어집니다.

따라서 시스템구축 범위는 화면 목록만으로 정하기 어렵습니다.

누가 시스템을 사용하는지, 업무가 어떤 순서로 진행되는지, 단계별로 어떤 데이터가 생성되는지, 누가 조회·수정·승인할 수 있는지, 예외 상황은 어떻게 처리할지를 함께 정리해야 합니다.

이 기준이 빠진 상태에서 디자인이나 총견적만 비교하면 개발이 시작된 뒤 요구사항이 계속 추가될 수 있습니다. 반대로 업무 구조를 먼저 정리하면 필요한 기능과 나중에 추가할 기능을 구분하기 쉬워지고, 여러 개발업체의 제안도 같은 기준으로 비교할 수 있습니다.

시스템구축이 필요한 시점은 언제일까요?

모든 업무를 별도 시스템으로 만들 필요는 없습니다.

사용자가 적고 업무 규칙이 단순하다면 엑셀, 공유 문서, 협업 도구나 기존 SaaS 솔루션으로도 충분히 운영할 수 있습니다. 이미 시중에 적합한 솔루션이 있다면 처음부터 맞춤 개발을 선택하는 것보다 해당 솔루션을 먼저 활용하는 편이 현실적일 수 있습니다.

다만 다음과 같은 상황이 반복된다면 시스템구축을 검토할 시점일 수 있습니다.

같은 정보를 여러 엑셀 파일에 반복해서 입력한다.
담당자마다 서로 다른 양식과 파일을 사용한다.
최신 파일이 무엇인지 확인하기 어렵다.
업무 진행 상태를 메신저로 물어봐야 알 수 있다.
승인 여부와 승인자를 별도로 기록하고 있다.
담당자 변경 시 업무 이력과 기준을 인계하기 어렵다.
거래처별 가격이나 처리 절차가 다르다.
관리자마다 조회하거나 수정할 수 있는 정보가 달라야 한다.
예약, 주문, 결제, 정산 데이터를 각각 다른 곳에서 관리한다.
기존 ERP나 외부 서비스에 동일한 데이터를 다시 입력한다.
직원이 늘어나면서 누가 어떤 정보를 수정했는지 추적하기 어렵다.

핵심은 현재 사용하는 도구가 엑셀이냐 솔루션이냐가 아닙니다.

업무량과 사용자 수가 늘어날수록 정보가 분산되고, 담당자의 기억과 수작업에 의존하는 구간이 많아지는지가 판단 기준입니다.

시스템구축의 목적도 단순히 종이 문서나 엑셀을 화면으로 옮기는 것이어서는 부족합니다. 반복 입력을 줄이고, 진행 상태를 공유하며, 권한에 따라 필요한 데이터만 제공하고, 운영 과정에서 발생한 이력을 남기는 구조를 만드는 것이 중요합니다.

홈페이지 제작, 솔루션 도입, 맞춤형 시스템구축은 무엇이 다를까요?

시스템구축 상담을 진행하다 보면 서로 다른 유형의 프로젝트가 하나의 표현으로 묶이는 경우가 있습니다.

1. 정보 제공 중심의 홈페이지

회사 소개, 사업 영역, 제품 안내, 문의 접수처럼 정보를 전달하는 것이 중심이라면 일반적인 기업 홈페이지 제작 범위에 가까울 수 있습니다.

콘텐츠를 수정할 수 있는 관리자 기능이 필요할 수 있지만, 복잡한 업무 처리나 데이터 상태 관리가 핵심은 아닙니다.

2. 기존 솔루션 도입

전자결재, 고객 관리, 프로젝트 관리, 쇼핑몰, 예약처럼 이미 표준화된 업무라면 기존 솔루션을 검토할 수 있습니다.

초기 도입이 비교적 빠르고 검증된 기능을 활용할 수 있다는 장점이 있습니다. 다만 회사 고유의 승인 절차나 거래처별 정책, 기존 ERP와의 특수한 연동이 필요하면 설정 범위를 넘어서는 별도 개발이 필요할 수 있습니다.

3. 맞춤형 시스템구축

다음과 같은 고유한 업무 규칙이 있다면 맞춤 개발 또는 기존 솔루션과 맞춤 개발을 결합하는 방식을 검토할 수 있습니다.

사용자 유형별로 이용 절차가 다르다.
거래처마다 상품, 가격, 결제 조건이 다르다.
여러 단계의 검토와 승인이 필요하다.
특정 상태에서만 수정하거나 취소할 수 있다.
기존 데이터 구조와 업무 규칙을 유지해야 한다.
여러 외부 서비스나 ERP와 데이터를 주고받아야 한다.
운영자가 처리해야 하는 예외 업무가 많다.

맞춤형 시스템이 항상 더 좋은 것은 아닙니다.

표준적인 기능은 기존 솔루션을 활용하고, 회사의 경쟁력이나 운영 방식과 직접 연결되는 구간만 맞춤 개발하는 혼합형 방식도 가능합니다. 중요한 것은 처음부터 구축 방식을 결정하는 것이 아니라, 현재 업무에서 표준화할 부분과 별도 설계가 필요한 부분을 나누는 것입니다.

시스템구축 전 가장 먼저 정리할 것은 사용자 유형입니다

화면 목록보다 먼저 정리해야 할 항목은 시스템을 사용하는 사람입니다.

같은 시스템이라도 영업 담당자, 운영 담당자, 승인 책임자, 외부 거래처와 최고관리자가 필요로 하는 기능은 서로 다릅니다.

예를 들어 B2B 주문 시스템이라면 다음과 같이 사용자가 나뉠 수 있습니다.

| 사용자 유형 | 주요 업무 | 필요한 기능 예시 | |---|---|---| | 거래처 담당자 | 상품 조회, 견적 요청, 주문 등록 | 거래처별 상품·가격 조회, 주문 내역 | | 영업 담당자 | 요청 검토, 조건 협의 | 담당 거래처 조회, 견적 수정, 메모 | | 승인 담당자 | 가격·주문 승인 | 승인, 반려, 사유 입력 | | 출고 담당자 | 출고 준비와 완료 처리 | 출고 대상 조회, 송장 등록 | | 정산 담당자 | 결제·정산 확인 | 결제 상태, 세금계산 관련 정보 | | 운영 관리자 | 전체 업무 관리 | 사용자·상품·권한·정책 관리 | | 최고관리자 | 설정과 권한 관리 | 관리자 계정, 역할, 접근 범위 설정 |

사용자 유형을 정리할 때는 이름만 나누지 말고 다음 질문까지 함께 확인해야 합니다.

이 사용자는 어떤 데이터를 볼 수 있는가?
새로 등록할 수 있는 정보는 무엇인가?
다른 사람이 등록한 정보를 수정할 수 있는가?
삭제가 가능한가, 아니면 취소 상태로 변경해야 하는가?
승인이나 반려 권한이 있는가?
엑셀 다운로드가 필요한가?
개인정보나 정산 정보를 볼 수 있는가?
본인 담당 데이터만 조회하는가?
같은 회사에 소속된 다른 사용자의 정보도 볼 수 있는가?

역할 기반 접근 제어는 사용자를 개별적으로 관리하기보다 역할에 권한을 연결하는 방식입니다. NIST의 RBAC 설명에서도 사용자는 할당된 역할을 통해 권한을 받으며, 역할을 기준으로 접근을 관리하면 사용자와 권한이 많아질 때 관리 구조를 단순화할 수 있다고 설명합니다. (csrc.nist.gov)

다만 실제 기업 시스템에서는 역할 이름만으로 모든 권한이 결정되지 않을 수도 있습니다.

같은 영업 담당자라도 자신이 담당하는 거래처만 조회해야 할 수 있고, 특정 금액 이상의 주문은 상위 책임자만 승인해야 할 수 있습니다. 따라서 역할, 소속 조직, 담당 거래처, 데이터 상태와 같은 조건을 함께 고려해야 합니다.

현재 업무 흐름을 먼저 그린 뒤 시스템 흐름으로 바꿔야 합니다

시스템구축을 시작할 때 바로 새로운 화면을 구상하는 경우가 많습니다.

하지만 현재 업무가 왜 복잡한지 확인하지 않고 기존 양식을 그대로 화면으로 옮기면, 수작업의 불편함까지 시스템 안으로 복사될 수 있습니다.

먼저 현재 업무 흐름을 다음과 같이 적어보는 것이 좋습니다.

거래처가 메일로 주문서를 보낸다.
영업 담당자가 주문 내용을 엑셀에 입력한다.
재고를 확인하기 위해 물류 담당자에게 메신저를 보낸다.
할인율이 높은 주문은 팀장에게 승인을 요청한다.
승인 결과를 받은 뒤 ERP에 다시 입력한다.
출고가 완료되면 송장번호를 엑셀에 기록한다.
거래처에 메일로 결과를 안내한다.

이 흐름을 시스템으로 전환할 때는 단순히 각 단계에 화면을 하나씩 만드는 것이 아니라, 반복 입력과 대기 구간을 찾아야 합니다.

예를 들면 다음과 같이 바꿀 수 있습니다.

거래처가 시스템에서 직접 주문을 등록한다.
거래처별 가격과 구매 가능 상품을 자동으로 적용한다.
재고 또는 판매 가능 여부를 시스템에서 확인한다.
승인 조건에 해당하면 담당 승인자에게 알림을 보낸다.
승인된 주문만 출고 대상에 표시한다.
ERP 연동이 가능하면 주문 정보를 전달한다.
출고 상태와 송장번호를 거래처 화면에 제공한다.

이 과정에서 반드시 모든 단계를 자동화할 필요는 없습니다.

예외가 많거나 업무 기준이 아직 정리되지 않은 구간은 초기에는 관리자가 직접 확인하고 처리하도록 구성할 수 있습니다. 운영 데이터가 쌓이고 기준이 명확해진 뒤 자동화하는 편이 안전한 업무도 있습니다.

화면 목록보다 상태값을 먼저 정해야 합니다

업무 시스템에서 화면은 현재 데이터를 보여주는 수단입니다. 실제 업무 진행을 결정하는 것은 상태값인 경우가 많습니다.

주문 업무를 예로 들면 단순히 ‘진행 중’과 ‘완료’만으로는 부족할 수 있습니다.

임시 저장
주문 접수
검토 중
승인 대기
승인 완료
반려
출고 준비
출고 완료
취소 요청
취소 완료

각 상태에는 다음과 같은 규칙이 연결됩니다.

누가 해당 상태로 변경할 수 있는가?
어떤 상태에서 내용을 수정할 수 있는가?
승인 후에도 수량이나 가격을 변경할 수 있는가?
반려할 때 사유 입력이 필수인가?
출고 준비 이후 주문을 취소할 수 있는가?
취소하면 재고나 결제 상태는 어떻게 처리되는가?
이전 상태로 되돌릴 수 있는가?
상태가 변경되면 누구에게 알림을 보내는가?

상태값이 실제 업무 단계와 맞지 않으면 시스템을 구축한 뒤에도 별도 엑셀과 메신저가 생길 가능성이 큽니다.

예를 들어 시스템에는 ‘처리 중’이라는 상태만 있지만 운영팀은 실제로 ‘서류 확인 중’, ‘고객 회신 대기’, ‘승인 대기’를 구분해야 한다면, 담당자는 다시 엑셀에 별도 메모를 남기게 됩니다.

따라서 상태값은 개발사가 임의로 정하기보다 실제 업무 담당자와 함께 확인해야 합니다. 정상적인 흐름뿐 아니라 반려, 취소, 수정, 재처리처럼 자주 발생하는 예외도 함께 정리해야 합니다.

권한은 메뉴 노출이 아니라 데이터와 행동 범위까지 설계해야 합니다

관리자 메뉴를 숨겼다고 권한 설계가 완료되는 것은 아닙니다.

권한은 최소한 다음 세 단계로 나누어 확인하는 것이 좋습니다.

메뉴 접근 권한

어떤 메뉴에 들어갈 수 있는지를 결정합니다.

예를 들어 상담 담당자에게 정산 메뉴를 노출하지 않도록 설정할 수 있습니다.

기능 실행 권한

같은 화면에 접근하더라도 할 수 있는 행동은 다를 수 있습니다.

조회
등록
수정
삭제
승인
반려
다운로드
일괄 처리

운영 담당자는 주문을 수정할 수 있지만 승인할 수 없고, 승인 담당자는 금액과 내용을 확인한 뒤 승인만 할 수 있도록 구성할 수 있습니다.

데이터 접근 권한

같은 메뉴와 기능을 사용하더라도 조회할 수 있는 데이터가 달라질 수 있습니다.

본인이 등록한 데이터
본인 담당 거래처 데이터
소속 부서 데이터
특정 지역 데이터
전체 데이터

OWASP의 권한 설계 지침은 사용자 유형, 보호할 자원, 조회·등록·수정 같은 작업을 설계 단계에서 구분하고, 업무 수행에 필요한 최소 권한만 부여할 것을 권고합니다. 또한 화면에서 버튼을 숨기는 클라이언트 측 처리만으로 접근을 통제하지 말고 서버에서도 요청별 권한을 확인해야 한다고 안내합니다. (cheatsheetseries.owasp.org)

시스템구축 범위를 정리할 때는 다음과 같은 권한표를 만들어볼 수 있습니다.

| 기능 | 일반 담당자 | 팀장 | 운영 관리자 | 최고관리자 | |---|---:|---:|---:|---:| | 본인 담당 건 조회 | 가능 | 가능 | 가능 | 가능 | | 부서 전체 조회 | 불가 | 가능 | 가능 | 가능 | | 전체 데이터 조회 | 불가 | 불가 | 가능 | 가능 | | 신규 등록 | 가능 | 가능 | 가능 | 가능 | | 승인 | 불가 | 가능 | 가능 | 가능 | | 삭제 | 불가 | 불가 | 제한적 가능 | 가능 | | 엑셀 다운로드 | 제한 | 가능 | 가능 | 가능 | | 관리자 계정 설정 | 불가 | 불가 | 불가 | 가능 |

이 표는 정답이 아니라 논의를 위한 시작점입니다.

실제 권한은 조직 구조, 개인정보 처리 범위, 내부 통제 기준과 업무 책임에 맞춰 조정해야 합니다.

승인 절차는 단계 수보다 조건과 예외가 중요합니다

“승인 기능이 필요합니다”라는 한 문장만으로는 개발 범위를 정하기 어렵습니다.

다음과 같은 조건에 따라 승인 구조가 달라질 수 있기 때문입니다.

모든 요청을 승인받아야 하는가?
특정 금액 이상일 때만 승인이 필요한가?
할인율이나 상품 유형에 따라 승인자가 달라지는가?
1차 승인과 최종 승인이 필요한가?
승인자가 부재중이면 대체 승인자가 있는가?
요청자가 자신의 요청을 승인할 수 있는가?
승인 후 정보가 변경되면 재승인이 필요한가?
반려된 요청을 수정해 다시 제출할 수 있는가?
긴급 상황에서 관리자가 강제 처리할 수 있는가?

승인 단계만 화면에 표시하고 예외 규칙을 정하지 않으면 실제 운영에서 담당자가 시스템 밖으로 나가게 됩니다.

초기 시스템구축에서는 복잡한 자동 승인 규칙을 모두 구현하기보다, 필수 승인 단계와 기록 기능을 먼저 구축하는 방법도 있습니다. 이후 실제 승인 데이터를 확인하면서 조건별 자동 배정이나 대체 승인 기능을 확장할 수 있습니다.

사용자 화면과 관리자 페이지를 하나의 범위로 봐야 합니다

사용자가 신청, 주문, 예약 또는 문의를 등록하면 그 뒤에는 운영자의 업무가 이어집니다.

사용자 화면만 설계하고 관리자 페이지를 단순한 데이터 목록으로 구성하면 운영팀은 다시 엑셀과 메신저를 사용하게 될 수 있습니다.

관리자 페이지에는 다음 기능이 필요할 수 있습니다.

검색과 필터

운영자는 전체 목록보다 특정 조건에 해당하는 데이터를 빠르게 찾는 일이 많습니다.

기간
상태
담당자
거래처
상품
결제 여부
승인 여부
처리 지연 여부

자주 사용하는 검색 조건이 있다면 저장하거나 기본값으로 제공하는 것도 검토할 수 있습니다.

상세 조회와 관련 데이터 연결

회원 정보만 따로 보는 것보다 해당 회원의 주문, 예약, 결제, 문의 이력을 함께 확인하는 것이 운영에 도움이 될 수 있습니다.

각 데이터를 별도 메뉴에서 다시 검색해야 한다면 고객 응대 시간이 길어지고 정보 누락 가능성도 커집니다.

상태 변경과 일괄 처리

운영자가 여러 건을 반복해서 처리한다면 하나씩 상세 화면에 들어가 수정하는 방식은 비효율적일 수 있습니다.

담당자 일괄 배정
상태 일괄 변경
엑셀 업로드
선택 데이터 다운로드
일괄 알림 발송
처리 대상 묶음 생성

다만 일괄 처리는 영향 범위가 크기 때문에 실행 권한, 확인 단계와 취소 가능 여부를 함께 검토해야 합니다.

변경 이력

여러 관리자가 같은 데이터를 다룬다면 현재 값만 저장해서는 문제 발생 원인을 찾기 어렵습니다.

업무 특성에 따라 다음 내용을 기록할 수 있습니다.

변경한 사용자
변경 일시
변경 전 값
변경 후 값
상태 변경 사유
승인 또는 반려 의견
데이터 다운로드 이력

OWASP는 애플리케이션 로그가 보안뿐 아니라 운영과 장애 조사에도 활용될 수 있다고 설명하며, 로그의 목적에 맞춰 어떤 사건을 어느 수준까지 기록할지 정하고 무단 조회·수정·삭제로부터 보호해야 한다고 안내합니다. (cheatsheetseries.owasp.org)

모든 입력값의 변경 이력을 무조건 남겨야 하는 것은 아닙니다. 개인정보, 금액, 권한, 승인 상태처럼 업무상 추적이 필요한 항목을 우선 선정하고 보관 기간과 접근 권한을 함께 정하는 것이 좋습니다.

기존 엑셀 데이터는 그대로 옮기기 전에 구조를 확인해야 합니다

기존 엑셀을 시스템 데이터베이스로 이전할 때는 파일을 업로드하는 기능만 생각하기 쉽습니다.

하지만 실제로는 다음과 같은 문제가 자주 발견됩니다.

같은 거래처가 여러 이름으로 등록되어 있다.
전화번호와 날짜 형식이 파일마다 다르다.
필수값이 비어 있다.
하나의 셀에 여러 정보가 함께 입력되어 있다.
삭제된 거래처와 운영 중인 거래처가 구분되지 않는다.
사용자 이름만 있고 고유한 사용자 번호가 없다.
상품 코드 없이 상품명으로만 관리하고 있다.
수식으로 계산된 값과 직접 입력한 값이 섞여 있다.

이 상태에서 데이터를 그대로 이전하면 기존 오류까지 새 시스템으로 이동합니다.

데이터 이전 전에는 다음 항목을 확인하는 것이 좋습니다.

이전 대상 파일과 시점을 정합니다.
중복 데이터 판단 기준을 정합니다.
거래처·상품·사용자처럼 기준이 되는 데이터를 구분합니다.
날짜, 전화번호, 코드 등 형식을 통일합니다.
필수값이 없는 데이터의 처리 방식을 정합니다.
이전 전후 건수와 주요 값을 검증합니다.
원본 파일의 보관 여부와 접근 권한을 정합니다.
최종 전환 직전에 발생한 신규 데이터를 어떻게 반영할지 정합니다.

모든 과거 데이터를 새 시스템에 넣어야 하는지도 검토해야 합니다.

운영에 필요한 최근 데이터와 기준정보만 이전하고, 오래된 자료는 별도로 조회 가능하게 보관하는 방식이 적합할 수도 있습니다. 데이터의 양보다 앞으로 어떤 업무에 사용할지를 기준으로 이전 범위를 정해야 합니다.

외부 API와 ERP 연동은 연결 대상보다 데이터 책임을 먼저 정해야 합니다

시스템구축 과정에서 결제, 배송, 본인인증, 문자, 이메일, 회계, ERP 등의 외부 연동이 필요할 수 있습니다.

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

먼저 어느 시스템의 데이터를 기준으로 삼을지를 정해야 합니다.

예를 들어 새 업무 시스템과 ERP 양쪽에서 거래처 정보를 수정할 수 있다면 서로 다른 값이 저장될 수 있습니다. 이런 상황을 줄이려면 다음을 정해야 합니다.

거래처 정보의 원본 시스템은 어디인가?
상품과 가격은 어느 시스템에서 관리하는가?
신규 등록과 수정은 어느 방향으로 전달하는가?
실시간 연동이 필요한가?
일정 시간마다 묶어서 동기화해도 되는가?
연동에 실패하면 자동으로 다시 시도하는가?
같은 데이터가 중복 전송되면 어떻게 처리하는가?
일부 데이터만 성공하면 전체를 취소하는가?
운영자가 실패 내역을 확인하고 재처리할 수 있는가?

연동 범위에는 API 호출 코드만 포함되는 것이 아닙니다.

인증 방식, 호출 제한, 데이터 매핑, 오류 처리, 재시도, 로그, 관리자 확인 기능과 테스트 환경 제공 여부까지 함께 확인해야 합니다.

외부 서비스에서 제공하지 않는 기능은 개발사가 임의로 구현할 수 없습니다. 따라서 상담 단계에서 API 문서, 계약 상태, 테스트 계정과 필요한 데이터 항목을 확인하면 구축 가능성과 범위를 보다 구체적으로 검토할 수 있습니다.

웹·앱·백엔드·데이터베이스를 포함한 전체 범위를 확인해야 합니다

시스템구축 견적을 비교할 때 사용자에게 보이는 화면만 보면 포함 범위를 정확히 파악하기 어렵습니다.

일반적인 업무 시스템은 다음 요소로 구성될 수 있습니다.

사용자용 웹 또는 앱

직원, 고객, 거래처, 파트너가 실제 업무를 처리하는 화면입니다.

모바일 사용이 많은지, 사내 PC에서만 사용하는지, 앱의 카메라·알림 같은 기능이 필요한지에 따라 적합한 방식이 달라집니다.

백엔드 서버

로그인, 권한 확인, 업무 규칙, 상태 변경, 알림, 외부 연동과 데이터 처리를 담당합니다.

사용자 화면에 보이지 않지만 시스템의 주요 업무 규칙이 구현되는 영역입니다.

데이터베이스

사용자, 거래처, 상품, 주문, 승인, 결제와 변경 이력 등의 관계를 저장합니다.

화면을 먼저 만들고 데이터 구조를 나중에 맞추면 중복 저장이나 확장 문제가 생길 수 있으므로, 주요 데이터 간 관계를 초기부터 함께 설계해야 합니다.

관리자 페이지와 백오피스

운영자가 사용자, 콘텐츠, 주문, 예약, 승인, 정산과 설정을 관리하는 영역입니다.

관리자 화면도 실제 업무량과 권한 구조에 따라 별도 설계가 필요합니다.

인프라와 배포 환경

서버, 데이터베이스, 파일 저장소, 도메인, 보안 인증서, 백업과 모니터링이 포함될 수 있습니다.

개발용, 테스트용, 운영용 환경을 어떻게 구분할지도 확인해야 합니다.

원소프트는 프로젝트의 요구사항과 기존 운영 환경에 따라 Next.js, React, TypeScript, Vue.js 등의 웹 기술과 Flutter 기반 모바일 앱, NestJS·Node.js·Java/Spring 기반 백엔드, PostgreSQL·MySQL·MariaDB·Oracle·Firestore 등의 데이터 환경을 조합해 검토합니다.

특정 기술을 먼저 정하기보다 기존 시스템, 필요한 기능, 운영 방식, 확장 계획과 유지보수 조건을 확인한 뒤 적합한 구조를 선택하는 것이 중요합니다.

1차 구축 기능과 이후 확장 기능을 나누는 방법

요구사항을 정리하다 보면 모든 기능이 필요해 보입니다.

하지만 실제 공개 시점에 필요한 기능과 운영 데이터가 쌓인 뒤 필요한 기능은 다를 수 있습니다.

기능을 다음 네 가지 질문으로 구분해볼 수 있습니다.

이 기능이 없으면 핵심 업무가 멈추는가?

사용자 등록, 주문 접수, 승인, 처리 결과 확인처럼 핵심 흐름을 완료하기 위한 기능은 1차 범위에 포함될 가능성이 높습니다.

시스템 밖에서 임시로 처리할 수 있는가?

사용 빈도가 낮고 초기 운영자가 직접 처리할 수 있는 업무라면 첫 구축에서 제외하거나 단순한 관리자 처리 기능으로 시작할 수 있습니다.

실제 데이터가 있어야 기준을 정할 수 있는가?

고급 통계, 자동 추천, 정교한 대시보드는 운영 데이터가 쌓인 뒤 만드는 편이 적합할 수 있습니다.

초기에는 원본 데이터를 정확히 저장하고 필요한 조건으로 조회·다운로드할 수 있도록 구성하는 것이 우선일 수 있습니다.

나중에 추가해도 전체 구조를 크게 바꾸지 않는가?

알림 채널 추가나 일부 보고서 기능은 추후 확장이 가능할 수 있습니다.

반면 사용자와 회사의 관계, 권한 구조, 주문 상태와 핵심 데이터 모델은 나중에 변경할 경우 영향 범위가 커질 수 있으므로 초기 설계에서 충분히 검토해야 합니다.

기능 우선순위는 단순히 ‘필수’와 ‘선택’으로만 나누기보다 다음처럼 정리할 수 있습니다.

| 구분 | 판단 기준 | |---|---| | 1차 필수 | 핵심 업무를 시작하고 완료하는 데 필요 | | 운영 필수 | 사용자 화면에는 보이지 않지만 운영자가 처리하는 데 필요 | | 2차 확장 | 초기에는 수작업으로 대체할 수 있음 | | 데이터 축적 후 | 실제 사용 패턴과 데이터가 있어야 기준을 정할 수 있음 | | 제외 | 현재 목적과 관련이 적거나 기존 도구로 충분히 처리 가능 |

시스템구축 견적서에서 확인할 범위

같은 이름의 시스템이라도 견적에 포함된 범위는 개발업체마다 다를 수 있습니다.

공공 소프트웨어 사업 관련 지침에서도 요구사항의 상세 작성 여부를 검토 항목으로 두고 있으며, 과업 변경을 분석·설계·구현·시험 단계와 연결해 관리하도록 서식을 두고 있습니다. 기업의 맞춤형 시스템구축에서도 계약 전 요구사항과 변경 절차를 구체적으로 정리하는 것은 범위 오해를 줄이는 데 도움이 됩니다. (law.go.kr)

견적을 비교할 때는 다음 항목을 확인해보는 것이 좋습니다.

기획

현재 업무 분석이 포함되는가?
사용자 유형과 권한을 함께 정의하는가?
업무 흐름과 예외 상황을 정리하는가?
화면 정의서나 기능 명세서를 제공하는가?
요구사항 변경 절차는 어떻게 되는가?

UX/UI 디자인

사용자 화면과 관리자 화면 디자인이 모두 포함되는가?
PC와 모바일 대응 범위는 어디까지인가?
디자인 수정 횟수와 확정 절차는 어떻게 되는가?
기존 디자인 시스템이나 브랜드 자료는 누가 제공하는가?

개발

프론트엔드와 백엔드가 모두 포함되는가?
데이터베이스 설계가 포함되는가?
관리자 페이지의 구체적인 기능은 무엇인가?
권한과 승인 기능은 어느 수준까지 포함되는가?
알림과 외부 API 연동 범위는 어디까지인가?

데이터 이전

기존 엑셀 데이터 분석과 정제가 포함되는가?
이전 가능한 데이터 형식이 정해져 있는가?
테스트 이전과 최종 이전을 구분하는가?
이전 결과를 어떤 기준으로 검증하는가?

테스트

기능 테스트의 담당자는 누구인가?
권한별 테스트가 포함되는가?
외부 연동 실패 상황을 확인하는가?
모바일 기기와 브라우저 범위는 어디까지인가?
발주사의 검수 기간과 수정 절차는 어떻게 되는가?

배포

서버 구축과 배포가 포함되는가?
클라우드 계정은 누구 명의로 개설하는가?
도메인과 인증서는 누가 관리하는가?
데이터 백업과 모니터링은 포함되는가?
실제 운영 전환 작업은 누가 담당하는가?

인수인계

소스코드를 제공하는가?
서버, 도메인, 외부 서비스 계정의 소유자는 누구인가?
데이터베이스 구조와 배포 방법을 문서로 제공하는가?
관리자 사용 방법을 안내하는가?
운영에 필요한 환경 변수와 설정 정보는 어떻게 전달하는가?

유지보수

하자 수정과 기능 추가를 어떻게 구분하는가?
무상 지원 범위와 기간은 어떻게 되는가?
장애 접수와 대응 방식은 무엇인가?
서버와 외부 서비스 이용료는 별도인가?
운영 중 기능 변경 요청은 어떤 방식으로 산정하는가?

총견적만 비교하면 한 업체에는 포함된 항목이 다른 업체에는 제외되어 있을 수 있습니다.

비용 차이가 개발 단가 때문인지, 기획·관리자·데이터 이전·배포·인수인계 범위의 차이 때문인지 구분해야 현실적인 비교가 가능합니다.

시스템구축 과정에서 자주 발생하는 실수

기존 엑셀 양식을 그대로 화면으로 옮기는 것

엑셀은 한 화면에서 자유롭게 수정할 수 있지만 시스템은 데이터 관계와 권한, 상태를 명확히 정해야 합니다.

현재 양식을 참고하되 각 항목이 왜 필요한지, 누가 입력하고 어디에서 사용하는지를 다시 확인해야 합니다.

정상적인 업무 흐름만 설계하는 것

실제 운영에서는 취소, 반려, 중복 등록, 담당자 부재와 외부 연동 실패가 발생합니다.

예외 상황을 개발 후반에 발견하면 상태와 데이터 구조를 다시 수정해야 할 수 있습니다.

관리자 기능을 단순 목록으로 생각하는 것

관리자는 데이터를 보기만 하는 사람이 아닙니다.

검색하고, 담당자를 배정하고, 상태를 바꾸고, 오류를 재처리하며, 고객 문의에 대응합니다. 실제 운영 순서를 반영하지 않으면 별도 엑셀 사용이 계속될 수 있습니다.

모든 자동화를 첫 구축에 포함하는 것

업무 기준이 정리되지 않은 상태에서 자동화하면 잘못된 규칙이 빠르게 반복될 수 있습니다.

초기에는 기록과 조회, 승인 구조를 먼저 만들고 실제 운영 데이터를 바탕으로 자동화 범위를 넓히는 방법도 검토할 수 있습니다.

개발 완료와 운영 준비 완료를 같은 것으로 보는 것

기능이 작동하더라도 계정, 초기 데이터, 권한 설정, 운영 매뉴얼, 장애 대응 방식이 준비되지 않으면 실제 전환이 어렵습니다.

개발 일정 안에 테스트와 데이터 이전, 운영 교육과 배포 준비 기간을 함께 고려해야 합니다.

개발업체에 문의하기 전 준비하면 좋은 자료

완성된 기획서가 없어도 상담은 가능합니다.

다만 다음 자료가 있다면 현재 문제와 필요한 범위를 더 빠르게 파악할 수 있습니다.

현재 사용 중인 엑셀 양식
업무에 사용하는 문서와 신청서
현재 업무 순서를 적은 간단한 메모
사용자와 담당 부서 목록
승인 절차와 예외 상황
기존 시스템 화면
연동하려는 ERP나 외부 서비스 정보
반드시 필요한 기능과 있으면 좋은 기능
시스템 도입을 검토하게 된 이유
희망하는 공개 시점과 내부 검수 담당자

화면을 직접 그릴 필요는 없습니다.

“거래처가 주문을 등록하면 영업 담당자가 확인하고, 일정 금액 이상이면 팀장이 승인한 뒤 출고 담당자가 처리한다”처럼 업무 흐름을 문장으로 적는 것만으로도 구축 범위를 정리하는 데 도움이 됩니다.

운영 가능한 시스템을 만들려면 업무 구조부터 확인해야 합니다

시스템구축은 화면을 많이 만드는 프로젝트가 아닙니다.

현재 업무를 사용자, 데이터, 상태, 권한과 승인 절차로 정리하고, 사용자 화면과 관리자 운영을 하나의 흐름으로 연결하는 작업에 가깝습니다.

구축 전에는 다음 항목을 우선 확인해보는 것이 좋습니다.

시스템을 사용하는 사람은 누구인가?
사용자별 핵심 업무는 무엇인가?
업무가 시작되고 완료되는 기준은 무엇인가?
진행 중 상태와 예외 상태는 어떻게 구분하는가?
누가 어떤 데이터를 조회·수정·승인할 수 있는가?
관리자가 반복해서 처리하는 업무는 무엇인가?
기존 데이터 중 무엇을 이전해야 하는가?
외부 시스템과 어떤 데이터를 주고받아야 하는가?
첫 구축에 반드시 필요한 기능은 무엇인가?
테스트·배포·인수인계·유지보수는 어디까지 포함되는가?

원소프트는 웹·앱·AI와 관리자 시스템 개발을 기획, UX/UI 디자인, 프론트엔드, 백엔드, 서버·데이터베이스, 배포와 유지보수 범위까지 함께 검토합니다.

요청받은 화면을 그대로 구현하기보다 서비스 목적과 실제 운영 방식, 데이터 구조와 이후 확장 가능성을 확인해 필요한 개발 범위를 정리하는 방향을 지향합니다.

아직 상세한 기능 정의서가 없더라도 현재 사용하는 엑셀이나 업무 흐름을 바탕으로 사용자 기능, 관리자 기능, 외부 연동과 단계별 구축 범위를 나눠볼 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치하고 있습니다. 화성·동탄을 비롯해 수원, 용인, 기흥, 오산 등 경기 남부에서 시스템구축을 검토하고 계시다면 현재 운영 방식과 필요한 기능을 기준으로 개발 범위를 함께 살펴드릴 수 있습니다.

제목 후보

시스템구축, 화면보다 업무 흐름·권한·데이터를 먼저 정해야 하는 이유
시스템구축 전 확인할 8가지, 관리자 운영까지 범위에 포함하세요
시스템구축 견적, 사용자 화면보다 권한·승인·데이터 범위를 확인하세요
맞춤형 시스템구축, 엑셀 업무를 웹 시스템으로 전환하는 실무 기준
기업 시스템구축, 솔루션 도입과 맞춤 개발을 구분하는 방법

메인 키워드

시스템구축

서브 키워드

맞춤형 시스템 구축
업무 시스템 개발
관리자 시스템 구축
기업 시스템 개발
시스템 구축 업체

썸네일 문구

시스템구축 범위, 화면보다 먼저 볼 것
업무 흐름부터 정리해야 하는 이유
권한·데이터·관리자 운영 체크리스트

글 요약

시스템구축은 사용자 화면이나 솔루션 도입 비용만 비교해서 결정하기보다 실제 업무 흐름, 사용자 권한, 상태값, 승인 절차와 관리자 운영 범위를 함께 정리해야 합니다. 기존 엑셀 데이터 이전과 외부 API·ERP 연동, 웹·앱·백엔드·데이터베이스 범위, 테스트·배포·인수인계·유지보수까지 확인하는 실무 기준을 설명했습니다.

CTA 후보

현재 사용 중인 엑셀과 업무 순서만 정리되어 있어도 사용자 기능, 관리자 기능과 단계별 구축 범위를 함께 검토할 수 있습니다.
솔루션 도입과 맞춤 개발 사이에서 고민하고 계시다면 표준화할 업무와 별도 개발이 필요한 업무부터 나누어보시기 바랍니다. 원소프트가 현재 운영 방식을 기준으로 필요한 시스템 범위를 정리해드릴 수 있습니다.

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

시스템 구축 비용, 견적 차이를 만드는 기획·관리자·데이터 이전 범위
업무 시스템 개발, 엑셀 데이터를 이전하기 전 확인해야 할 항목
시스템 구축 업체 선정 전 요구사항 정의서와 견적서를 비교하는 방법