시스템개발업체 선정 전, 운영 가능한 웹·관리자 시스템 범위를 정하는 방법

시스템개발업체를 알아보는 기업 담당자는 보통 화면 자료와 기능 목록부터 준비합니다.

“회원가입이 필요합니다.” “예약과 결제를 넣어야 합니다.” “관리자 페이지도 만들어주세요.” “기존 ERP와 연동할 수 있으면 좋겠습니다.”

이 정도 내용을 여러 개발사에 전달한 뒤 총견적과 개발 기간을 비교하기도 합니다. 하지만 같은 기능명을 전달했는데도 업체마다 견적과 제안 범위가 크게 달라지는 경우가 많습니다.

이유는 단순합니다.

‘회원가입’, ‘예약’, ‘결제’, ‘관리자 페이지’라는 기능명이 실제 업무 범위를 충분히 설명하지 못하기 때문입니다.

예를 들어 회원가입 하나만 보더라도 일반 사용자만 가입하는지, 기업 계정과 직원 계정을 구분하는지, 운영자의 승인 후 사용할 수 있는지에 따라 필요한 데이터와 권한 구조가 달라집니다.

예약 기능도 마찬가지입니다. 사용자가 날짜를 선택하는 화면만 필요한 것이 아니라 예약 가능 여부, 담당자 배정, 결제 상태, 취소 규칙, 관리자 처리 방식까지 정해야 실제 운영이 가능합니다.

따라서 시스템개발업체를 선정할 때는 화면의 완성도나 총견적만 비교하기보다 다음 범위를 함께 살펴봐야 합니다.

시스템이 해결해야 할 업무 문제
사용자 유형과 역할별 권한
업무의 시작부터 완료까지 이어지는 상태값
운영자가 사용하는 관리자 기능
ERP·결제·외부 API 연동 방식
기존 데이터 이전 범위
보안·테스트·배포 책임
소스코드와 서버 계정의 인수인계
출시 이후 유지보수 범위

이 항목들이 정리되어야 개발사도 비슷한 기준으로 범위를 해석할 수 있고, 기업 담당자 역시 견적의 차이가 어디에서 발생했는지 판단할 수 있습니다.

시스템개발업체를 찾기 전에 해결할 업무 문제를 한 문장으로 정리하기

개발 상담을 시작할 때 가장 먼저 정할 것은 화면이나 기술이 아니라 시스템을 통해 해결하려는 업무 문제입니다.

다음과 같은 요청은 방향은 알 수 있지만 개발 범위를 결정하기에는 부족합니다.

거래처 주문 시스템이 필요합니다.
예약 플랫폼을 만들고 싶습니다.
기존 사내 시스템을 바꾸고 싶습니다.
관리자 페이지를 새로 만들고 싶습니다.
고객과 파트너를 연결하는 서비스를 개발하려고 합니다.

여기에 현재의 문제와 원하는 변화가 포함되어야 합니다.

예를 들면 다음과 같이 정리할 수 있습니다.

거래처 주문을 전화·메신저·엑셀로 접수하고 있어 주문 누락과 재고 확인 지연이 발생한다. 거래처가 직접 주문하고 담당자가 승인·출고 상태를 관리할 수 있는 웹 시스템이 필요하다.

또는 다음과 같이 쓸 수 있습니다.

고객 예약은 홈페이지에서 받고 있지만 담당자 배정과 결제 확인은 별도 문서로 관리하고 있다. 예약 접수부터 담당자 배정, 결제 확인, 이용 완료까지 하나의 시스템에서 처리하고 싶다.

이 한 문장이 있으면 시스템개발업체도 무엇을 먼저 확인해야 하는지 판단하기 쉬워집니다.

첫 번째 예시라면 거래처별 상품과 가격, 주문 승인, 재고 확인, 출고 상태, ERP 연동을 검토해야 합니다. 두 번째 예시라면 예약 가능 기준, 담당자 일정, 결제 상태, 취소 규칙과 관리자 운영 흐름을 확인해야 합니다.

반대로 “예약 시스템이 필요하다”는 설명만 전달하면 업체마다 서로 다른 범위를 상상하게 됩니다.

한 업체는 달력과 신청서만 포함할 수 있고, 다른 업체는 회원·결제·알림·관리자 페이지까지 포함할 수 있습니다. 이 두 견적은 금액만 놓고 비교하기 어렵습니다.

문제 정의에 포함하면 좋은 네 가지

개발사에 문의하기 전 다음 내용을 한 문단으로 정리해보는 것이 좋습니다.

현재 업무는 어떤 방식으로 처리하고 있는가?
현재 방식에서 반복되는 문제는 무엇인가?
시스템 도입 후 어떤 업무가 달라져야 하는가?
가장 먼저 개선해야 할 사용자는 누구인가?

시스템의 목적이 분명하면 기능 우선순위도 정하기 쉬워집니다.

모든 업무를 한 번에 바꾸기보다 주문 접수와 승인부터 시스템화할지, 회원·결제·정산까지 처음부터 연결할지를 목적에 맞춰 결정할 수 있기 때문입니다.

사용자 유형과 역할별 권한을 먼저 구분하기

웹 시스템의 개발 범위를 정할 때 자주 빠지는 항목이 사용자 구분입니다.

기획서에 ‘회원’과 ‘관리자’만 적혀 있어도 실제 운영을 확인해보면 더 다양한 역할이 나올 수 있습니다.

예를 들어 중개형 서비스에는 다음과 같은 사용자가 있을 수 있습니다.

서비스를 신청하는 일반 사용자
업무를 수행하는 파트너 또는 전문가
신청 내용을 확인하는 상담 담당자
파트너를 배정하는 운영 담당자
결제와 정산을 확인하는 회계 담당자
전체 설정과 권한을 관리하는 최고 관리자

각 역할은 로그인 후 보이는 메뉴만 다른 것이 아닙니다. 조회할 수 있는 데이터와 실행할 수 있는 업무가 달라야 합니다.

| 역할 | 조회 범위 | 처리 가능한 업무 | |---|---|---| | 일반 사용자 | 본인의 신청·결제 내역 | 신청, 취소 요청, 문의 | | 파트너 | 자신에게 배정된 업무 | 수락, 진행 상태 변경, 결과 등록 | | 상담 담당자 | 담당 고객과 신청 정보 | 상담 기록, 보완 요청 | | 정산 담당자 | 결제·환불·정산 정보 | 정산 확인, 내역 다운로드 | | 최고 관리자 | 전체 운영 데이터 | 계정·권한·정책 관리 |

여기서 확인해야 할 것은 단순한 메뉴 접근 권한만이 아닙니다.

고객 개인정보를 어디까지 보여줄 것인가?
전화번호와 계좌번호를 일부 마스킹할 것인가?
담당자에게 배정된 고객만 조회할 수 있는가?
다른 부서의 처리 내역을 볼 수 있는가?
조회는 가능하지만 수정은 제한해야 하는가?
다운로드 권한을 별도로 분리해야 하는가?
승인과 실행을 같은 사람이 처리해도 되는가?
퇴사자나 부서 이동자의 권한은 어떻게 회수하는가?

로그인에 성공했다고 모든 기능을 사용할 수 있는 것은 아닙니다. 인증이 사용자의 신원을 확인하는 절차라면, 권한은 해당 사용자가 어떤 데이터와 기능에 접근할 수 있는지를 결정하는 절차입니다.

OWASP도 권한 설계에서 업무 수행에 필요한 최소한의 권한만 부여하고, 명시적으로 허용되지 않은 접근은 기본적으로 차단하는 방식을 권고합니다. 권한 요구사항은 개발 후반에 추가하기보다 설계 단계부터 정의하는 편이 적절합니다. (cheatsheetseries.owasp.org)

시스템개발업체에 확인할 질문

사용자 유형을 몇 가지로 분석했는가?
역할별 조회·등록·수정·삭제·승인 권한을 구분하는가?
화면에서 메뉴만 숨기는 것이 아니라 서버에서도 권한을 검사하는가?
개인정보 마스킹과 다운로드 권한을 별도로 적용할 수 있는가?
관리자 권한을 운영 중 추가하거나 변경할 수 있는가?
권한 변경 이력을 확인할 수 있는가?

권한을 단순하게 만들면 초기 개발 범위는 줄어들 수 있습니다. 하지만 실제 운영 조직이 여러 역할로 나뉘어 있다면 지나치게 단순한 권한 구조가 오히려 수작업과 정보 노출 위험을 만들 수 있습니다.

업무의 시작부터 완료까지 상태값과 처리 절차 설계하기

시스템은 데이터를 저장하는 공간인 동시에 업무가 진행되는 과정을 관리하는 도구입니다.

따라서 어떤 정보가 입력되는지만큼 업무가 어떤 상태를 거쳐 완료되는지를 정해야 합니다.

예를 들어 서비스 신청 업무를 다음처럼 표현할 수 있습니다.

``text 신청서 작성 → 신청 접수 → 운영자 검토 → 보완 요청 또는 승인 → 담당자 배정 → 업무 진행 → 결과 등록 → 고객 확인 → 완료 ``

실제 업무에서는 정상 흐름만 발생하지 않습니다.

신청자가 중간에 취소할 수 있습니다.
정보가 부족해 보완 요청이 필요할 수 있습니다.
배정된 담당자가 업무를 거절할 수 있습니다.
결제는 승인됐지만 신청 데이터 저장에 실패할 수 있습니다.
운영자가 잘못 처리해 이전 상태로 되돌려야 할 수 있습니다.
완료 후 환불이나 이의 제기가 발생할 수 있습니다.

이런 상황을 반영하려면 ‘대기·진행·완료’ 정도의 단순한 상태만으로 부족할 수 있습니다.

상태값을 정할 때 확인할 항목

각 업무 단계마다 다음 질문에 답해보면 좋습니다.

이 상태는 어떤 사건으로 시작되는가?
누가 상태를 변경할 수 있는가?
상태가 변경될 때 필요한 입력값은 무엇인가?
사용자와 운영자에게 어떤 알림을 보내야 하는가?
다음 상태로 이동할 수 있는 조건은 무엇인가?
취소하거나 이전 상태로 되돌릴 수 있는가?
잘못 처리했을 때 복구 방법은 무엇인가?
변경 이력을 얼마나 남겨야 하는가?

예를 들어 ‘승인 완료’ 상태로 바꾸기 위해 승인 담당자, 승인 시각, 승인 의견이 필요할 수 있습니다.

‘취소 완료’라면 취소 요청자, 취소 사유, 환불 여부, 재고나 예약 가능 수량의 복구 여부까지 연결될 수 있습니다.

상태값은 관리자 화면의 필터에도 사용되고, 고객에게 보여주는 진행 현황과 알림 발송 기준에도 사용됩니다. 결제·배송·ERP와 같은 외부 시스템을 연동한다면 어떤 데이터를 언제 전송할지를 결정하는 기준도 됩니다.

따라서 시스템개발업체가 화면 목록만 받고 바로 견적을 내기보다 실제 업무 흐름과 예외 상황을 질문하는지 확인해야 합니다.

사용자 화면과 함께 필요한 관리자 페이지 범위 확인하기

서비스를 검토할 때는 일반적으로 고객이 보는 화면부터 떠올립니다.

회원가입
상품 또는 서비스 조회
신청과 주문
예약
결제
이용 내역
문의

하지만 사용자의 행동 뒤에는 운영자의 후속 업무가 이어집니다.

사용자가 회원가입을 하면 운영자는 계정 상태를 확인하거나 기업 회원을 승인해야 할 수 있습니다. 사용자가 예약하면 담당자를 배정하고 일정을 조정해야 할 수 있습니다. 결제가 완료되면 취소와 환불 문의에 대응할 수 있어야 합니다.

관리자 페이지도 단순히 데이터 목록을 보여주는 화면으로 정의하면 부족할 수 있습니다.

회원 관리

회원 검색과 상세 조회
회원 상태 변경
기업 회원 승인
이용 정지와 탈퇴 처리
역할 및 권한 설정
신청·주문·결제·문의 이력 연결 조회
개인정보 마스킹
관리자 메모

신청·예약·주문 관리

상태별 목록과 검색
담당자 배정
접수·승인·거절·취소 처리
일괄 상태 변경
보완 자료 요청
첨부 문서 확인
처리 이력 조회
조건별 엑셀 다운로드

결제·환불·정산 관리

결제 상태 조회
주문 또는 예약 데이터와 결제 내역 연결
취소·부분 취소·환불 상태 확인
포인트나 쿠폰 내역 조회
파트너별 정산 대상 확인
지급 상태 관리
오류 거래 확인

운영 설정

상품과 서비스 관리
가격과 수수료 정책
예약 가능 시간
공지와 알림 템플릿
약관과 운영 정책
관리자 계정과 권한
외부 연동 설정

관리자 기능은 많을수록 좋은 것이 아닙니다.

초기에는 운영 빈도가 높은 업무를 중심으로 구성하고, 실제 데이터가 쌓여야 의미가 있는 고급 통계나 복잡한 자동화는 이후 단계로 나눌 수 있습니다.

다만 운영자가 매일 처리해야 하는 업무를 개발 범위에서 제외하면 서비스 공개 후 엑셀과 메신저가 다시 등장합니다. 관리자 페이지가 있는데도 운영팀이 별도 문서를 사용하는 이유는 실제 업무 순서, 검색 조건, 일괄 처리와 예외 대응이 충분히 반영되지 않았기 때문인 경우가 많습니다.

ERP·결제·외부 API 연동 시 기준 데이터와 오류 처리 정하기

ERP, 결제, 배송, 문자, 소셜 로그인, OCR, 푸시 알림 등 외부 서비스를 연결하면 시스템 범위가 넓어집니다.

이때 “API 연동 가능”이라는 설명만으로는 운영 가능 여부를 판단하기 어렵습니다.

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

예를 들어 웹 시스템과 ERP를 연결한다면 다음을 확인해야 합니다.

거래처 정보의 원본은 웹 시스템인가, ERP인가?
상품 코드와 가격은 어디에서 등록하는가?
ERP에서 상품을 수정하면 웹 시스템에 언제 반영되는가?
웹 주문은 ERP로 실시간 전송하는가?
ERP 전송이 실패하면 주문 접수는 유지되는가?
담당자가 실패 건을 다시 전송할 수 있는가?
양쪽 데이터가 다르면 어느 값을 우선하는가?

결제 연동도 비슷합니다.

사용자가 결제 완료 화면을 보았다고 주문이나 예약 상태까지 정상 반영됐다고 단정할 수는 없습니다. 사용자가 결과 화면에 도착하기 전에 브라우저를 닫을 수도 있고, 결제 승인 이후 내부 데이터 저장 과정에서 오류가 발생할 수도 있기 때문입니다.

따라서 외부 연동에는 정상 처리 외에도 다음 기준이 필요합니다.

응답 지연
일시적인 서비스 중단
중복 요청과 중복 응답
부분 성공
인증키 만료
호출 제한 초과
잘못된 데이터 형식
내부 데이터 저장 실패
재시도 횟수와 간격
운영자 수동 재처리
요청·응답 로그 확인

연동 범위를 정리하는 표

| 확인 항목 | 정리할 내용 | |---|---| | 기준 시스템 | 어떤 시스템의 데이터를 원본으로 볼 것인가 | | 식별자 | 양쪽 데이터를 어떤 코드로 연결할 것인가 | | 동기화 시점 | 실시간, 일정 주기, 운영자 실행 중 어떤 방식인가 | | 성공 기준 | 어떤 응답과 내부 처리가 완료돼야 성공인가 | | 실패 처리 | 자동 재시도, 수동 처리, 고객 안내 방식 | | 중복 방지 | 같은 주문이나 결제가 여러 번 처리되지 않게 하는 기준 | | 운영 화면 | 실패 내역과 재처리 결과를 어디에서 확인할 것인가 | | 책임 범위 | 외부 서비스 변경과 장애 발생 시 누가 대응하는가 |

연동 개발은 연결 코드를 작성하는 작업만이 아닙니다. 시스템 사이에서 데이터가 이동할 때 업무가 중단되지 않도록 상태와 오류를 관리하는 일까지 포함합니다.

기존 데이터 이전·보안·테스트·배포 범위를 견적서에서 확인하기

기존 시스템을 교체하거나 여러 문서에 흩어진 데이터를 통합한다면 데이터 이전 범위를 별도로 확인해야 합니다.

“기존 회원 데이터를 옮겨주세요”라는 요청에는 다음과 같은 세부 작업이 포함될 수 있습니다.

기존 데이터 구조 분석
신규 시스템 항목과의 매핑
잘못된 형식과 중복 데이터 정리
필수값이 없는 데이터 처리
파일과 이미지 경로 이전
개인정보 이전 방식 검토
테스트 이전
최종 이전
이전 결과 검증
이전 실패 데이터의 재처리

데이터가 엑셀 파일 하나에 정리되어 있다고 해도 바로 입력할 수 있는 것은 아닙니다.

같은 거래처가 서로 다른 이름으로 등록되어 있거나, 전화번호와 날짜의 형식이 일정하지 않을 수 있습니다. 이전 시스템에서 사용하던 상태값과 신규 시스템의 업무 단계가 다를 수도 있습니다.

따라서 데이터 이전은 단순한 파일 업로드가 아니라 기존 데이터의 의미를 신규 업무 구조에 맞춰 다시 연결하는 작업으로 봐야 합니다.

보안 범위

보안도 개발 완료 직전에 확인할 항목이 아닙니다.

NIST의 Secure Software Development Framework는 보안 요구사항과 개발 절차를 소프트웨어 개발 생명주기에 통합하는 방식을 제시하며, 소프트웨어를 구매하거나 발주하는 조직도 공급사와 범위를 협의하는 공통 기준으로 활용할 수 있다고 설명합니다. (csrc.nist.gov)

시스템 기획과 견적 단계에서 다음 항목을 확인할 필요가 있습니다.

비밀번호 저장과 로그인 보안
관리자 접근 제한
사용자·관리자 권한 검사
개인정보 마스킹
파일 업로드 제한
중요 데이터의 전송·저장 방식
관리자 작업 및 오류 기록
운영 환경의 디버그 정보 노출 방지
백업과 복구 방식
보안 업데이트 책임

CISA 역시 소프트웨어 조달 과정에서 구매자가 보안을 별도 요구사항으로 확인하고, 계약과 운영 단계에도 제품 보안 기준을 반영할 것을 안내합니다. (cisa.gov)

테스트 범위

견적서의 ‘테스트 포함’이라는 문구도 구체적으로 확인해야 합니다.

개발사가 내부 기능 테스트를 수행하는가?
주요 사용자 흐름을 기준으로 통합 테스트를 하는가?
모바일·브라우저 환경은 어디까지 확인하는가?
사용자 유형별 권한 테스트가 포함되는가?
결제와 외부 API의 실패 상황을 테스트하는가?
발주사의 사용자 인수 테스트 기간이 있는가?
발견된 오류의 수정 기준은 무엇인가?
수정 후 재검증은 누가 수행하는가?

로그도 장애 대응과 테스트에서 중요한 범위입니다. 단순한 서버 접속 기록만으로는 누가 어떤 업무를 처리했고 어느 단계에서 오류가 발생했는지 확인하기 어렵습니다. OWASP는 애플리케이션 로그가 보안과 운영 상황을 파악하는 데 활용되며, 로그 저장 실패와 권한 문제 같은 상황도 테스트할 필요가 있다고 안내합니다. (cheatsheetseries.owasp.org)

배포 범위

시스템이 개발됐다고 자동으로 운영 환경에 공개되는 것은 아닙니다.

서버와 데이터베이스 구성
도메인과 인증서 연결
운영 환경 변수 설정
파일 저장소 구성
백업 정책 설정
배포 자동화 여부
오류 모니터링
배포 후 기본 점검
기존 시스템과의 전환 일정
장애 발생 시 원복 방법

이 항목들이 누구의 책임인지 견적과 계약 단계에서 구분해야 합니다.

소스코드·서버·계정 인수인계와 유지보수 책임 범위 점검하기

시스템은 공개 이후에도 수정과 운영이 이어집니다.

따라서 개발사를 선정할 때는 제작 과정뿐 아니라 프로젝트 종료 후 기업이 무엇을 전달받는지도 확인해야 합니다.

인수인계 항목

전체 소스코드
소스코드 저장소 접근 권한
운영 서버와 데이터베이스 계정
클라우드 서비스 계정
도메인과 인증서 관리 정보
파일 저장소 접근 권한
외부 API 계정
결제 서비스 계약과 관리자 계정
문자·메일·푸시 발송 계정
배포 방법과 환경 설정 문서
데이터베이스 구조 또는 주요 데이터 설명
API 문서
관리자 사용 방법
백업과 복구 방법

모든 계정을 개발사 명의로 개설하면 개발사 변경이나 내부 담당자 변경 시 문제가 생길 수 있습니다.

서비스 소유 기업이 직접 보유해야 하는 계정과 개발사가 작업을 위해 접근할 계정을 구분하는 것이 좋습니다. 특히 도메인, 클라우드, 결제, 앱스토어와 같은 핵심 계정은 계약 주체와 소유권을 사전에 확인해야 합니다.

유지보수 범위

‘유지보수 가능’이라는 설명도 다음과 같이 나누어 확인해야 합니다.

개발 범위와 다르게 작동하는 오류 수정
운영 환경 또는 외부 서비스 변경에 따른 대응
보안 업데이트
서버와 데이터베이스 모니터링
데이터 확인과 운영 지원
기존 기능 변경
신규 기능 추가
긴급 장애 대응
정기 백업 확인
담당자 문의와 응답 시간

기능 오류 수정과 신규 기능 개발은 같은 업무가 아닙니다.

예를 들어 계약된 규칙대로 계산되지 않는 문제는 오류 수정에 해당할 수 있지만, 운영 정책이 바뀌어 새로운 계산 규칙을 추가하는 것은 기능 변경에 가깝습니다.

외부 API가 변경돼 연동 방식을 수정해야 하는 경우도 최초 개발 오류인지, 외부 환경 변화에 따른 추가 작업인지 구분할 필요가 있습니다.

유지보수 비용의 크기만 비교하기보다 어떤 요청이 포함되고, 어떤 요청이 별도 견적으로 처리되는지 확인하는 편이 좋습니다.

시스템개발업체의 견적을 비교할 때 봐야 할 기준

개발사 견적을 비교할 때는 총액을 보기 전에 동일한 범위를 기준으로 산정했는지 확인해야 합니다.

다음 표처럼 비교 항목을 정리하면 차이를 파악하기 쉽습니다.

| 구분 | 업체 A | 업체 B | 확인할 내용 | |---|---|---|---| | 요구사항 분석 | 포함 | 일부 포함 | 업무 흐름과 예외 상황 분석 여부 | | UX/UI 디자인 | 포함 | 별도 | 화면 설계와 시안 범위 | | 사용자 웹 | 포함 | 포함 | 반응형과 지원 환경 | | 백엔드·DB | 포함 | 포함 | API와 데이터 구조 | | 관리자 페이지 | 기본 기능 | 상세 기능 | 권한·검색·일괄 처리 범위 | | 외부 연동 | 2종 포함 | 별도 | 실제 제공 기능과 오류 처리 | | 데이터 이전 | 별도 | 일부 포함 | 정리·검증·재처리 범위 | | 테스트 | 내부 테스트 | 통합 테스트 | 권한·실패 상황 포함 여부 | | 서버 배포 | 포함 | 별도 | 운영 환경 구성 범위 | | 인수인계 | 소스코드 | 문서 포함 | 계정·배포·API 문서 | | 유지보수 | 1개월 | 3개월 | 오류 수정과 변경 개발 구분 |

견적이 낮은 이유가 개발 효율성 때문일 수도 있지만, 관리자 기능·배포·데이터 이전·테스트가 제외되어 있기 때문일 수도 있습니다.

반대로 견적이 높다고 해서 반드시 필요한 범위를 잘 이해한 것도 아닙니다. 현재 단계에서 사용하지 않을 고급 기능이나 과도한 인프라가 포함됐는지 확인해야 합니다.

좋은 비교 기준은 가장 많은 기능을 포함한 업체가 아니라, 현재 업무와 1차 구축 목적에 맞게 포함·제외 범위를 설명할 수 있는 업체인지입니다.

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

완성된 기획서가 없어도 시스템개발업체에 문의할 수 있습니다.

다만 다음 자료가 있으면 업무 범위를 파악하고 견적 차이를 줄이는 데 도움이 됩니다.

1. 현재 업무 흐름

담당자가 실제로 처리하는 순서를 적어봅니다.

``text 고객 문의 → 담당자 상담 → 견적 작성 → 고객 승인 → 계약 → 결제 → 업무 진행 → 결과 전달 → 정산 ``

2. 사용자와 담당자 목록

일반 고객
기업 고객
파트너
상담 담당자
운영 관리자
정산 담당자
최고 관리자

사용자마다 어떤 정보를 보고 어떤 업무를 처리하는지 함께 적습니다.

3. 현재 사용하는 문서

신청서
주문서
견적서
계약서
정산 문서
엑셀 관리표
업무 매뉴얼
고객 안내 메시지

기존 문서에는 실제 데이터 항목과 업무 규칙이 담겨 있는 경우가 많습니다.

4. 필요한 외부 연동

ERP
그룹웨어
결제
배송
문자와 이메일
소셜 로그인
OCR
지도
회계 시스템
기타 외부 API

서비스 이름만 적기보다 어떤 데이터를 주고받고 싶은지 함께 정리하면 좋습니다.

5. 우선순위

기능을 다음 세 단계로 구분해볼 수 있습니다.

공개 시 반드시 필요한 기능
운영하면서 빠르게 추가할 기능
데이터와 사용량을 확인한 후 검토할 기능

6. 일정과 운영 조건

목표 공개 시점
기존 시스템 종료 일정
업무를 중단할 수 있는 시간
내부 검토 담당자
콘텐츠와 데이터 준비 담당자
출시 후 운영 담당자

완성된 요구사항 정의서가 없더라도 현재 사용하는 엑셀, 업무 문서, 참고 서비스와 핵심 흐름을 전달하면 개발사가 분석을 시작할 수 있습니다.

원소프트가 검토하는 시스템 개발 범위

원소프트는 웹·앱·AI와 관리자 시스템 개발을 수행하며, 기획과 UX/UI 디자인, 프론트엔드, 백엔드, 서버·데이터베이스, 외부 연동, 배포와 유지보수를 프로젝트 상황에 맞춰 검토합니다.

요구사항을 화면 목록으로만 해석하기보다 다음 내용을 함께 확인하는 방향을 지향합니다.

서비스가 해결해야 하는 업무 문제
고객·파트너·운영자 등 사용자 구분
역할별 데이터 접근과 처리 권한
신청·승인·계약·결제·정산의 상태 흐름
운영자용 관리자 기능
결제·OCR·푸시·외부 API 연동
기존 서비스와 데이터 구조
공개 이후 기능 확장과 운영 방식

관련 경험으로는 부동산 경매 업무 통합 플랫폼인 바토너 프로젝트가 있습니다.

이 프로젝트에서는 경매 물건 조회부터 입찰 신청, 계약 문서 처리, 결제·포인트, 정산, 알림, 고객 문의와 관리자 운영까지 이어지는 백엔드/API를 개발했습니다.

일반 회원, 전문가, 운영자 등 사용자 유형에 따라 접근 범위와 처리 업무를 구분했으며, 입찰·계약·결제·정산이 여러 단계로 이어지는 업무를 상태 기반으로 구성했습니다. 또한 OCR을 활용한 문서 정보 인식, 결제, 푸시 알림과 관리자 기능을 실제 업무 흐름에 맞춰 연결했습니다.

이러한 업무형 시스템에서는 사용자 화면 하나보다 그 뒤에서 움직이는 권한, 상태, 데이터와 운영 절차가 전체 개발 범위를 결정합니다.

시스템개발업체 선정 체크리스트

상담이나 견적 비교 전에 다음 항목을 점검해보시기 바랍니다.

[ ] 시스템이 해결해야 할 현재 업무 문제를 설명할 수 있는가?
[ ] 일반 사용자, 파트너, 운영자 등 사용자 유형을 구분했는가?
[ ] 역할별 조회·수정·승인·다운로드 권한을 정했는가?
[ ] 업무의 시작부터 완료까지 상태를 정리했는가?
[ ] 취소·반려·오류·재처리 같은 예외 상황을 고려했는가?
[ ] 사용자 행동 뒤에 이어지는 운영자 업무를 확인했는가?
[ ] 관리자 페이지의 검색·필터·일괄 처리 범위를 정했는가?
[ ] 외부 연동의 기준 시스템과 동기화 시점을 정했는가?
[ ] 연동 실패와 중복 요청의 처리 방법을 확인했는가?
[ ] 기존 데이터의 정리·이전·검증 범위를 확인했는가?
[ ] 사용자 및 관리자 권한 테스트가 포함되어 있는가?
[ ] 서버·DB·도메인·외부 서비스 계정의 소유자를 정했는가?
[ ] 소스코드와 운영 문서를 전달받을 수 있는가?
[ ] 오류 수정과 기능 변경의 기준을 구분했는가?
[ ] 출시 이후 유지보수 책임과 대응 방식을 확인했는가?

모든 항목을 처음부터 완벽하게 확정할 필요는 없습니다.

중요한 것은 확정된 내용, 개발사와 함께 정해야 할 내용, 추후 결정할 내용을 구분하는 것입니다. 불확실한 항목을 숨기기보다 견적의 전제 조건으로 표시하면 개발 과정에서 발생할 수 있는 범위 변경을 줄이는 데 도움이 됩니다.

운영 가능한 시스템은 화면 밖의 범위에서 결정됩니다

시스템개발업체를 선정할 때 화면 디자인과 포트폴리오는 필요한 비교 요소입니다. 하지만 실제 운영 가능한 시스템을 만들려면 화면 밖의 구조도 함께 확인해야 합니다.

사용자가 버튼을 누른 뒤 어떤 데이터가 저장되는지, 운영자가 어떤 절차로 처리하는지, 누가 어떤 정보를 볼 수 있는지, 외부 연동이 실패하면 어떻게 복구하는지까지 정리되어야 합니다.

견적도 같은 기준으로 봐야 합니다.

낮은 금액인지 높은 금액인지를 먼저 판단하기보다 기획·디자인·백엔드·관리자 페이지·외부 연동·데이터 이전·테스트·배포·인수인계 중 무엇이 포함되어 있는지 확인해야 합니다.

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

사내 업무 시스템, 예약·주문·결제 서비스, B2B 플랫폼, 기존 시스템 리뉴얼이나 외부 API·ERP 연동을 검토하고 있다면 현재 업무 자료를 바탕으로 사용자 흐름과 관리자 운영 범위를 함께 정리할 수 있습니다. 완성된 기획서가 없더라도 현재 사용 중인 엑셀, 업무 문서와 핵심 기능을 기준으로 1차 구축 범위를 검토할 수 있습니다.

제목 후보

시스템개발업체 선정 전, 운영 가능한 웹·관리자 시스템 범위를 정하는 방법
시스템개발업체 비교, 화면과 견적보다 업무 흐름을 먼저 확인하세요
시스템개발업체 선택 전 확인할 8가지, 권한부터 유지보수까지
시스템개발업체 견적 비교, 관리자 기능과 운영 범위가 중요한 이유
시스템개발업체에 문의하기 전 정리해야 할 업무·권한·연동 범위

메인 키워드

시스템개발업체

서브 키워드

웹시스템개발
관리자시스템개발
업무시스템개발
시스템개발견적
개발외주업체

썸네일 문구

운영 관리용 문구 후보이며, 실제 썸네일 이미지에는 텍스트를 삽입하지 않습니다.

시스템 개발 범위, 어디까지 정해야 할까?
화면보다 먼저 확인할 운영 구조
시스템개발업체 선정 체크리스트

글 요약

시스템개발업체를 선정할 때는 화면 디자인과 총견적만 비교하지 않고, 해결할 업무 문제와 사용자 권한, 상태값, 관리자 기능을 함께 확인해야 합니다. ERP·결제·외부 API의 오류 처리부터 데이터 이전, 보안, 테스트, 배포, 계정 인수인계와 유지보수까지 범위를 구체화해야 실제 운영 가능한 시스템을 구축할 수 있습니다.

CTA 후보

현재 사용 중인 엑셀이나 업무 문서가 있다면 이를 기준으로 사용자 흐름, 관리자 기능과 1차 개발 범위를 함께 정리해드릴 수 있습니다.

여러 시스템개발업체의 견적을 비교하고 있지만 포함 범위가 달라 판단하기 어렵다면, 필요한 기능과 운영·연동·인수인계 항목부터 구분해보시기 바랍니다. 원소프트도 현재 업무 방식을 바탕으로 검토 범위를 정리할 수 있습니다.

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

업무시스템개발 견적, 기능 목록보다 업무 예외 상황을 먼저 정해야 하는 이유
시스템 유지보수 계약 전 확인할 소스코드·서버·장애 대응 범위
기존 시스템 데이터 이전, 엑셀 업로드 전에 정해야 할 검증 기준