시스템개발업체 선정 전, 우리 업무에 맞는 개발 범위와 운영 구조를 확인하는 방법

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

“회원과 관리자가 사용하는 웹 시스템이 필요한데, 어느 정도까지 개발해야 할지 모르겠습니다.”

“여러 시스템개발업체에서 견적을 받았지만 금액과 기간이 달라 비교하기 어렵습니다.”

시스템 개발을 검토하는 기업에서 자주 겪는 상황입니다.

겉으로 보기에는 동일한 업무 시스템처럼 보여도 견적서에 포함된 범위는 업체마다 다를 수 있습니다. 한 업체는 사용자 화면만 기준으로 산정하고, 다른 업체는 관리자 페이지와 서버, 데이터베이스, 배포까지 포함할 수 있습니다.

기획과 화면 디자인은 포함되어 있지만 기존 데이터 이전은 제외되어 있을 수도 있습니다. 외부 API 연결은 포함되지만 연동 실패를 확인하고 재처리하는 관리자 기능은 별도일 수도 있습니다.

따라서 시스템개발업체를 비교할 때는 총견적이나 화면 디자인만 보는 것으로 부족합니다.

우리 회사의 업무가 시스템 안에서 어떤 순서로 처리되는지, 누가 어떤 데이터를 볼 수 있는지, 운영자가 어떤 상황을 직접 처리해야 하는지까지 확인해야 실제로 사용할 수 있는 개발 범위를 판단할 수 있습니다.

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

시스템 개발의 출발점은 “어떤 기능이 필요한가”보다 “현재 어떤 업무 문제가 반복되고 있는가”에 가깝습니다.

예를 들어 다음과 같은 상황이 있을 수 있습니다.

고객 신청 내용을 담당자가 엑셀에 다시 입력하고 있다.
주문, 예약, 계약, 결제 정보가 서로 다른 파일에 저장되어 있다.
업무 담당자마다 사용하는 엑셀 양식이 다르다.
현재 처리 단계가 메신저와 전화로만 공유된다.
거래처별 가격이나 계약 조건을 담당자가 기억해서 적용한다.
승인받아야 할 업무가 구두로 처리되고 있다.
고객 문의가 들어오면 여러 시스템을 열어 이력을 확인해야 한다.
담당자가 바뀌면 기존 업무 내역을 파악하기 어렵다.
관리자 화면이 있지만 검색과 일괄 처리가 부족해 다시 엑셀을 사용한다.

이런 문제를 정리하지 않고 “고객관리 시스템이 필요합니다”, “주문 시스템을 만들고 싶습니다”라고만 전달하면 개발 범위가 서로 다르게 해석될 수 있습니다.

먼저 현재 업무를 시작부터 종료까지 한 줄로 적어보는 것이 좋습니다.

``text 고객 문의 접수 → 담당자 배정 → 상담 진행 → 견적서 전달 → 고객 승인 → 계약 체결 → 결제 확인 → 서비스 제공 → 정산 → 사후 문의 처리 ``

그다음 각 단계에서 다음 질문을 붙여봅니다.

누가 이 업무를 처리하는가?
어떤 정보를 입력하는가?
이전 단계의 어떤 정보가 필요한가?
다음 단계로 넘어가는 조건은 무엇인가?
승인이나 검토가 필요한가?
고객에게 알림을 보내야 하는가?
예외 상황이 발생하면 누가 처리하는가?
현재 어떤 부분을 엑셀이나 메신저로 보완하고 있는가?

이 내용을 정리하면 필요한 시스템의 범위가 조금씩 드러납니다.

단순 입력 화면이 필요한 것이 아니라 담당자 배정, 업무 상태 변경, 승인, 알림, 문서 관리, 결제 확인, 정산과 변경 이력이 필요하다는 사실을 확인할 수 있습니다.

이처럼 시스템 개발은 기존 업무를 화면으로 옮기는 작업이 아닙니다. 업무 규칙을 데이터와 처리 흐름으로 전환하는 작업입니다.

홈페이지·단순 기능 추가와 업무 시스템 개발은 다릅니다

시스템개발업체를 찾을 때 먼저 확인해야 할 부분은 만들려는 결과물이 일반적인 홈페이지인지, 업무 처리를 위한 시스템인지입니다.

회사 소개형 홈페이지는 주로 정보를 전달하는 역할을 합니다.

회사 소개
서비스 안내
제품 소개
포트폴리오
게시판
문의 접수
오시는 길

반면 업무 시스템은 사용자가 입력한 데이터가 여러 업무 단계를 거쳐 처리됩니다.

예를 들어 고객이 서비스를 신청하면 다음과 같은 과정이 이어질 수 있습니다.

``text 신청 접수 → 운영자 확인 → 담당자 배정 → 서류 검토 → 결제 요청 → 결제 확인 → 처리 완료 → 결과 안내 ``

이 경우 개발 범위에는 신청 화면만 포함되는 것이 아닙니다.

회원과 사용자 인증
신청 데이터 저장
담당자 배정
단계별 상태 관리
운영자 권한
알림 발송
첨부파일 관리
결제 연동
처리 이력
검색과 필터
통계와 다운로드
오류 확인 및 재처리

이러한 기능이 함께 검토되어야 합니다.

단순한 홈페이지 제작 경험과 복잡한 업무 시스템 개발 경험은 필요한 설계 관점이 다를 수 있습니다.

시스템개발업체를 비교할 때는 비슷한 디자인의 포트폴리오가 있는지만 보기보다, 여러 사용자와 운영자가 하나의 데이터를 기준으로 업무를 처리하는 구조를 설계해 본 경험이 있는지 확인하는 편이 좋습니다.

사용자 유형과 권한부터 구분해야 합니다

업무 시스템에서는 “누가 사용하는가”가 기능 범위를 결정합니다.

사용자를 단순히 일반 회원과 관리자로만 나누면 실제 운영 단계에서 문제가 생길 수 있습니다.

예를 들어 중개 플랫폼이라면 다음과 같이 사용자가 나뉠 수 있습니다.

서비스를 신청하는 고객
업무를 수행하는 파트너
고객 문의를 처리하는 상담 담당자
신청 내용을 검토하는 운영 담당자
결제와 정산을 확인하는 회계 담당자
전체 권한을 관리하는 최고 관리자

사용자마다 필요한 데이터와 처리 권한이 다릅니다.

| 사용자 유형 | 주요 조회 범위 | 주요 처리 업무 | |---|---|---| | 고객 | 본인의 신청·결제·진행 내역 | 신청, 수정, 결제, 문의 | | 파트너 | 배정된 업무와 고객 제공 정보 | 수락, 진행 상태 변경, 결과 등록 | | 상담 담당자 | 고객 정보와 상담 이력 | 상담 기록, 담당자 전달 | | 운영 담당자 | 전체 신청과 처리 상태 | 검토, 배정, 승인, 반려 | | 정산 담당자 | 결제·환불·정산 데이터 | 확인, 정산 처리, 내역 다운로드 | | 최고 관리자 | 전체 데이터와 설정 | 권한 관리, 정책 설정 |

여기에서 권한은 메뉴를 보여주거나 숨기는 것만을 의미하지 않습니다.

다음 항목을 구분해야 합니다.

조회할 수 있는 데이터
등록할 수 있는 데이터
수정할 수 있는 항목
삭제할 수 있는 범위
승인하거나 반려할 수 있는 업무
파일을 다운로드할 수 있는 권한
개인정보를 전체 또는 일부만 볼 수 있는 권한
일괄 처리할 수 있는 권한
다른 담당자가 처리한 내역을 수정할 수 있는 권한

예를 들어 상담 담당자는 고객의 연락처를 확인해야 할 수 있지만 결제 정보를 수정할 필요는 없습니다. 정산 담당자는 결제 금액과 환불 내역을 확인해야 하지만 상담 내용 전체를 볼 필요는 없을 수 있습니다.

개인정보를 처리하는 시스템은 업무 수행에 필요한 범위를 기준으로 접근권한을 차등 부여하고, 접속기록과 주요 처리 내역을 관리할 수 있는 구조를 함께 검토해야 합니다. 개인정보보호위원회의 2025년 개정 안내에서도 개인정보처리시스템의 접근권한 차등 부여와 접속기록 보관 대상이 확대되었습니다. (pipc.go.kr)

따라서 시스템개발업체에 문의할 때는 “관리자 페이지가 필요합니다”라고만 전달하기보다 관리자 유형과 역할별 권한을 함께 설명하는 것이 좋습니다.

업무 상태값과 처리 흐름이 개발 범위를 결정합니다

화면 목록만으로 시스템 개발 범위를 정리하면 빠지기 쉬운 부분이 상태값입니다.

상태값은 현재 업무가 어느 단계에 있는지를 나타내는 데이터입니다.

예를 들어 신청 업무를 다음과 같이 나눌 수 있습니다.

``text 임시 저장 → 신청 접수 → 검토 중 → 추가 자료 요청 → 승인 → 결제 대기 → 결제 완료 → 업무 진행 → 처리 완료 ``

취소와 반려도 하나의 상태로 끝나지 않을 수 있습니다.

신청 취소 요청
취소 검토 중
취소 완료
환불 대기
부분 환불
환불 완료
반려
재신청 가능
재신청 불가

상태가 바뀔 때 함께 처리해야 하는 업무도 정해야 합니다.

예를 들어 운영자가 신청을 승인하면 다음과 같은 동작이 이어질 수 있습니다.

승인 일시 기록
승인 담당자 기록
고객에게 알림 발송
결제 가능한 상태로 변경
결제 기한 설정
관련 부서에 업무 전달
변경 이력 저장

이런 내용이 빠진 상태에서 화면만 개발하면 운영자는 시스템 밖에서 다시 업무를 처리하게 됩니다.

시스템개발업체와 상담할 때는 다음 질문을 해보는 것이 좋습니다.

각 상태는 누가 변경할 수 있는가?
상태가 바뀌기 위한 조건은 무엇인가?
이전 상태로 되돌릴 수 있는가?
되돌린다면 기존 처리 내역은 어떻게 남는가?
상태 변경 시 고객이나 담당자에게 알림을 보내는가?
자동으로 바뀌는 상태와 운영자가 직접 바꾸는 상태는 무엇인가?
외부 시스템 처리 결과와 내부 상태가 다르면 어떻게 확인하는가?
취소, 반려, 재처리와 같은 예외 흐름이 정의되어 있는가?

이 질문에 대한 답이 구체적일수록 개발업체도 업무를 정확하게 이해하고 견적 범위를 산정할 수 있습니다.

관리자 페이지는 메뉴 수보다 실제 처리 업무를 기준으로 봐야 합니다

관리자 페이지가 있다는 것과 운영하기 편한 시스템이라는 것은 다릅니다.

회원 목록, 주문 목록, 예약 목록처럼 데이터가 표시되는 화면만 있어도 형식상 관리자 페이지라고 할 수 있습니다. 하지만 실무에서는 데이터를 빠르게 찾고 여러 건을 처리하며 문제 상황을 추적할 수 있어야 합니다.

검색과 필터

운영자가 자주 찾는 조건을 먼저 확인해야 합니다.

고객명, 연락처, 이메일
신청 번호, 주문 번호, 계약 번호
담당자
거래처
신청일과 처리일
결제 여부
업무 상태
미처리 또는 지연 건
취소·환불 건
특정 상품이나 서비스
외부 시스템 연동 성공·실패 여부

데이터가 적을 때는 목록을 위에서부터 찾아도 되지만, 운영 건수가 늘어나면 검색 조건의 차이가 업무 시간에 직접 영향을 줍니다.

일괄 처리

운영자가 같은 작업을 여러 건 반복한다면 일괄 처리 기능을 검토해야 합니다.

담당자 일괄 배정
상태 일괄 변경
선택 고객에게 알림 발송
파일 일괄 다운로드
엑셀 업로드
엑셀 다운로드
거래처별 데이터 추출
정산 대상 일괄 확정

일괄 처리는 편리하지만 실수의 영향도 커질 수 있습니다. 따라서 처리 전 확인, 처리 가능한 권한, 실패 건 표시, 결과 이력 등의 기준을 함께 정해야 합니다.

변경 이력

현재 값만 저장하면 문제가 발생했을 때 원인을 찾기 어렵습니다.

다음과 같은 정보가 필요할 수 있습니다.

누가 변경했는가?
언제 변경했는가?
어떤 값을 바꾸었는가?
변경 전 값은 무엇이었는가?
변경 후 값은 무엇인가?
변경 사유를 입력해야 하는가?
관리자 화면에서 변경했는가, 외부 연동으로 변경되었는가?
일괄 처리 중 일부만 실패했는가?

특히 승인, 결제, 환불, 정산, 개인정보 수정처럼 업무 영향이 큰 항목은 변경 이력의 필요성이 높습니다.

관리자 기능을 견적에서 확인할 때는 단순히 “관리자 페이지 포함”이라는 문구만 보지 말고 검색, 필터, 일괄 처리, 권한, 변경 이력, 다운로드와 예외 처리 범위까지 확인하는 것이 좋습니다.

기존 엑셀을 그대로 화면으로 옮기면 불편도 함께 옮겨질 수 있습니다

엑셀로 업무를 관리하고 있다면 기존 파일은 시스템 개발에 유용한 자료가 됩니다.

어떤 항목을 관리하고 있는지, 담당자가 어떤 기준으로 분류하는지, 어떤 데이터를 자주 검색하는지 확인할 수 있기 때문입니다.

다만 엑셀의 열을 그대로 데이터베이스 항목으로 옮기는 것이 항상 적절한 것은 아닙니다.

예를 들어 하나의 셀에 다음 정보가 함께 입력되어 있을 수 있습니다.

``text 김담당 / 9월 18일 통화 / 서류 재요청 / 다음 주 확인 예정 ``

사람은 내용을 읽고 이해할 수 있지만 시스템에서 검색하거나 자동화하기는 어렵습니다.

이를 시스템으로 전환하려면 다음처럼 구조화할 수 있습니다.

담당자
상담 일시
상담 내용
요청한 서류
다음 확인 예정일
현재 처리 상태
후속 조치 담당자

또한 엑셀 파일마다 동일한 거래처 이름이 다르게 입력되어 있을 수 있습니다.

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

사람은 같은 회사라고 판단할 수 있지만 시스템에서는 서로 다른 데이터로 인식될 수 있습니다.

따라서 데이터 이전 전에는 다음 내용을 확인해야 합니다.

중복 데이터 기준
필수값 누락 여부
날짜와 금액 형식
고객 및 거래처 식별 기준
사용하지 않는 오래된 데이터
개인정보 보유 필요성
첨부파일의 저장 위치
기존 코드값과 신규 상태값의 연결 기준

기존 데이터의 양만으로 이전 난이도를 판단하기는 어렵습니다. 데이터 형식이 일정한지, 서로 연결할 수 있는 식별자가 있는지, 수작업 정제가 필요한지가 더 큰 영향을 줄 수 있습니다.

시스템개발업체에 기존 엑셀을 전달할 때는 실제 개인정보가 포함된 원본을 바로 보내기보다, 민감한 내용을 제거한 샘플 파일과 각 열의 의미를 설명하는 자료부터 공유하는 것이 안전합니다.

외부 API·ERP 연동은 연결 대상과 책임 범위를 정해야 합니다

업무 시스템은 내부 기능만으로 끝나지 않을 수 있습니다.

다음과 같은 외부 시스템과 연결할 수 있습니다.

ERP
회계 프로그램
결제 서비스
문자·알림톡·이메일 발송 서비스
배송 및 물류 시스템
전자계약
본인인증
소셜 로그인
OCR
지도 및 주소 검색
AI API
기존 웹사이트나 앱

연동이 필요하다면 먼저 어느 시스템이 기준 데이터를 보유하는지 정해야 합니다.

예를 들어 거래처 정보는 ERP가 기준일 수 있고, 고객의 서비스 신청 정보는 신규 업무 시스템이 기준일 수 있습니다.

다음 항목을 구분해 정리해보는 것이 좋습니다.

| 확인 항목 | 검토할 내용 | |---|---| | 연동 대상 | 어떤 시스템과 연결하는가? | | 데이터 방향 | 가져오기, 보내기, 양방향 중 무엇인가? | | 기준 시스템 | 충돌하면 어느 데이터를 우선하는가? | | 연동 시점 | 실시간, 일정 주기, 운영자 실행 중 어떤 방식인가? | | 식별자 | 고객·상품·주문을 어떤 값으로 연결하는가? | | 실패 처리 | 오류가 발생하면 자동 재시도하는가? | | 중복 방지 | 같은 요청이 여러 번 들어와도 한 번만 처리되는가? | | 운영 기능 | 실패 내역을 누가 확인하고 재처리하는가? | | 테스트 환경 | 실제 운영 전 시험할 환경과 계정이 있는가? |

“ERP 연동 포함”이라는 문구만으로는 구체적인 범위를 알기 어렵습니다.

일부 데이터 조회만 포함하는지, 양방향 동기화까지 포함하는지, 오류 로그와 재처리 관리자 기능이 포함되는지에 따라 개발 범위가 달라질 수 있습니다.

또한 외부 시스템의 API 문서, 사용 권한, 테스트 계정, 호출 제한과 비용 정책도 확인해야 합니다. 필요한 기능이 API로 제공되지 않는다면 다른 방식이나 수작업 보완 절차를 검토해야 할 수 있습니다.

데이터 구조는 화면 뒤에서 업무를 연결하는 기준입니다

사용자는 화면을 보지만 시스템은 데이터 관계를 기준으로 동작합니다.

예를 들어 주문 시스템을 만든다면 주문 화면만 정의해서는 부족합니다.

고객
고객이 소속된 회사
거래처별 계약 조건
상품과 옵션
거래처별 가격
주문
주문별 품목
결제
배송
취소와 환불
세금계산서
담당자
변경 이력

이 데이터가 어떻게 연결되는지 정해야 합니다.

특히 하나의 고객이 여러 회사에 소속될 수 있는지, 한 주문을 여러 번 나누어 배송할 수 있는지, 부분 취소가 가능한지에 따라 구조가 달라집니다.

개발 초기에 데이터 관계를 단순하게 가정하면 이후 기능 확장이 어려워질 수 있습니다.

예를 들어 처음에는 주문 한 건당 배송 한 건으로 만들었지만, 실제 운영에서 분할 배송이 필요하다면 주문과 배송의 관계를 다시 수정해야 합니다. 거래처별 가격을 상품 가격 필드에 직접 저장했다면 계약별 가격과 기간별 가격을 추가할 때 구조 변경이 필요할 수 있습니다.

모든 미래 기능을 처음부터 개발할 필요는 없습니다.

다만 향후 예상되는 운영 방식이 있다면 시스템개발업체에 알려 구조적으로 확장 가능한지 검토하는 것이 좋습니다.

견적서에서는 총액보다 포함·제외 범위를 비교해야 합니다

업체별 견적을 공정하게 비교하려면 같은 범위를 기준으로 봐야 합니다.

다음 항목을 나누어 확인해보세요.

1. 기획

현재 업무 분석
사용자 유형 정리
업무 흐름 정의
기능 목록 작성
화면 구조 작성
상태값과 예외 상황 정의
정책 및 요구사항 문서화

2. UX/UI 디자인

사용자 화면 디자인
관리자 화면 디자인
모바일·태블릿·PC 대응 범위
디자인 수정 횟수
디자인 원본 파일 제공 여부
기존 브랜드 가이드 반영 여부

3. 사용자 화면 개발

회원가입과 로그인
신청·예약·주문
결제
알림
마이페이지
파일 업로드
반응형 웹 또는 앱

4. 백엔드와 데이터베이스

서버 기능
데이터베이스 설계
인증과 권한
상태 관리
외부 API
파일 저장
알림 발송
로그와 변경 이력

5. 관리자 시스템

회원·고객 관리
신청·주문·예약 관리
검색과 필터
상태 변경
담당자 배정
승인과 반려
일괄 처리
엑셀 업로드·다운로드
통계
변경 이력
권한 관리

6. 테스트

기능 테스트
권한별 테스트
주요 업무 흐름 테스트
모바일·브라우저 테스트
외부 연동 테스트
데이터 이전 검증
오류 수정 범위
고객 검수 기간

7. 배포와 운영 환경

서버 구성
도메인과 SSL 인증서
데이터베이스
파일 저장소
개발·검수·운영 환경 구분
로그와 모니터링
백업
배포 자동화 여부

8. 인수인계와 유지보수

소스코드 제공
서버와 클라우드 계정 소유권
도메인 계정
외부 서비스 계정
데이터베이스 인계
관리자 사용 방법
운영 문서
하자 수정 기간
유지보수 포함·제외 범위
기능 추가 요청의 처리 방식

공식 ISMS-P 인증기준 안내서에서도 시스템 도입과 인수 과정에서 요구사항정의서, 화면설계서, 보안 아키텍처 설계서, 시험계획서 같은 개발 산출물을 확인 자료의 예시로 제시합니다. 모든 민간 프로젝트에 동일한 문서 세트가 필요한 것은 아니지만, 요구사항과 시험·인수 기준이 문서로 정리되어야 개발 결과를 확인하기 쉬워진다는 점은 참고할 만합니다. (pims.kisa.or.kr)

견적 금액이 낮더라도 기획, 관리자 기능, 테스트, 배포, 인수인계가 빠져 있다면 실제 운영까지 필요한 총범위는 더 커질 수 있습니다.

반대로 견적이 높아 보여도 업무 분석부터 운영 환경 구성까지 포함되어 있다면 단순히 총액만으로 비싸다고 판단하기 어렵습니다.

배포 완료보다 중요한 것은 인수 기준입니다

개발된 화면이 열리고 주요 버튼이 작동한다고 해서 인수가 완료되는 것은 아닙니다.

업무 시스템은 실제 업무 시나리오를 기준으로 검수해야 합니다.

예를 들어 다음과 같은 시나리오를 만들 수 있습니다.

``text 신규 고객이 가입한다. → 서비스를 신청한다. → 운영자가 신청 내용을 검토한다. → 추가 서류를 요청한다. → 고객이 서류를 제출한다. → 운영자가 승인한다. → 고객이 결제한다. → 담당자가 업무를 처리한다. → 운영자가 완료 상태로 변경한다. → 고객에게 결과 알림이 발송된다. ``

정상 흐름뿐 아니라 예외 상황도 확인해야 합니다.

필수 정보가 누락된 경우
동일한 신청이 중복 접수된 경우
권한이 없는 관리자가 접근한 경우
결제는 승인됐지만 내부 상태 반영에 실패한 경우
외부 API가 일시적으로 응답하지 않는 경우
알림 발송에 실패한 경우
잘못된 데이터 파일을 업로드한 경우
여러 관리자가 같은 데이터를 동시에 수정한 경우
취소 후 다시 진행해야 하는 경우

검수 기준이 없다면 개발사와 고객이 서로 다른 기준으로 완료 여부를 판단할 수 있습니다.

계약이나 착수 단계에서 다음 내용을 정해두는 것이 좋습니다.

검수할 주요 업무 시나리오
테스트 데이터 준비 주체
고객 검수 기간
오류와 기능 변경의 구분 기준
수정 요청 전달 방식
최종 배포 조건
운영 데이터 이전 시점
인수인계 자료
하자 수정 범위와 기간

보안도 마지막 배포 단계에서 한 번 확인하는 항목으로만 보기보다, 요구사항과 설계·구현·시험 단계에서 함께 검토하는 편이 좋습니다. KISA 자료에서도 소프트웨어 개발 단계에서 보안약점이 포함되지 않도록 개발보안을 적용하는 방향을 안내하고 있습니다. (kisa.or.kr)

유지보수는 오류 수정과 기능 추가를 구분해야 합니다

“유지보수 포함”이라는 표현도 범위를 구체적으로 확인해야 합니다.

일반적으로 운영 이후 요청은 다음과 같이 나뉠 수 있습니다.

하자 또는 오류 수정

합의된 기능이 정상적으로 동작하지 않는 경우입니다.

특정 조건에서 저장이 되지 않음
권한이 없는 사용자가 데이터를 조회할 수 있음
합의된 계산식과 결과가 다름
외부 연동 결과가 잘못 저장됨
특정 브라우저에서 주요 기능을 사용할 수 없음

운영 지원

서비스를 계속 운영하기 위해 필요한 대응입니다.

서버와 로그 확인
장애 원인 분석
외부 API 정책 변경 대응
인증서 갱신
배포 지원
백업 상태 확인
관리자 사용 문의

기능 변경과 추가 개발

기존 합의 범위를 바꾸거나 새로운 요구사항을 추가하는 경우입니다.

새로운 관리자 유형 추가
승인 단계 추가
신규 결제수단 연동
통계 화면 추가
앱 개발
새로운 ERP 연결
업무 정책 변경에 따른 상태 흐름 수정

계약 전에 하자 수정 기간, 운영 지원 방식, 기능 추가 산정 방식과 대응 가능 시간을 확인하면 운영 후의 혼선을 줄일 수 있습니다.

실제 업무형 플랫폼 개발에서 확인한 범위

원소프트가 개발한 바토너는 부동산 경매 물건 확인부터 입찰 신청, 계약 문서 처리, 결제, 포인트, 정산, 알림과 고객 문의까지 이어지는 업무형 플랫폼입니다.

이 프로젝트에서는 단순히 고객이 입찰을 신청하는 화면만 구현한 것이 아니라, 회원·전문가·운영자 등 사용자 역할을 구분하고 각 역할에 필요한 인증과 권한을 구성했습니다.

입찰 신청 이후에는 계약과 정산까지 여러 업무 단계가 이어지기 때문에 상태 기반으로 진행 흐름을 관리하고, 고객용 기능과 관리자 기능이 동일한 데이터를 기준으로 동작하도록 백엔드와 API를 설계했습니다.

또한 결제와 포인트 내역, OCR을 활용한 문서 정보 인식, 푸시 알림, 문의 답변, 회원·입찰·결제·정산 관리 기능을 전체 업무 흐름 안에서 연결했습니다.

이처럼 중개 플랫폼이나 업무 시스템에서는 특정 기능 하나를 개발하는 것보다 다음 항목의 관계를 함께 설계하는 것이 중요합니다.

사용자와 운영자의 역할
신청부터 완료까지의 상태
문서와 업무 데이터
결제와 정산
알림과 고객 문의
관리자 권한과 처리 범위

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

완성된 요구사항 정의서가 없어도 문의할 수 있습니다.

다음 자료 중 준비할 수 있는 것부터 정리하면 상담과 견적 검토에 도움이 됩니다.

기본 자료

개발하려는 시스템의 목적
현재 해결하려는 업무 문제
주요 사용자 유형
핵심 업무 흐름
필요한 사용자 화면
필요한 관리자 기능
목표 공개 또는 도입 시점

기존 업무 자료

현재 사용하는 엑셀 양식
수기로 작성하는 신청서
업무 매뉴얼
실제 처리 순서
자주 발생하는 예외 상황
담당자별 업무와 권한
기존 시스템 화면

연동 및 데이터 자료

연동할 ERP나 외부 서비스
보유한 API 문서
기존 데이터의 형식과 대략적인 규모
이전이 필요한 첨부파일
운영 중인 서버나 클라우드 환경
기존 소스코드와 데이터베이스 확인 가능 여부

범위와 일정 자료

첫 번째 버전에 반드시 필요한 기능
추후 추가해도 되는 기능
내부 검수 담당자
콘텐츠와 데이터 준비 주체
예산 범위가 정해져 있다면 우선순위를 조정할 기준

기능을 완벽하게 정리하는 것보다 현재 아는 부분과 결정되지 않은 부분을 구분해 전달하는 것이 좋습니다.

개발업체가 결정되지 않은 항목을 질문하고, 여러 대안을 비교해 개발 범위로 구체화할 수 있어야 합니다.

시스템개발업체에 물어볼 질문 체크리스트

업체 상담과 견적 비교 시 다음 질문을 활용할 수 있습니다.

현재 업무 흐름을 어떤 방식으로 분석하나요?
사용자 유형과 권한은 어느 단계에서 정의하나요?
상태값과 예외 처리도 기획 범위에 포함되나요?
사용자 화면과 관리자 페이지가 하나의 데이터 구조로 연결되나요?
관리자 검색·필터·일괄 처리 범위는 어떻게 산정하나요?
기존 엑셀이나 데이터베이스 이전이 가능한가요?
데이터 정제와 검증은 어느 쪽에서 담당하나요?
외부 API와 ERP 연동 실패를 확인할 수 있나요?
연동 실패 건을 운영자가 재처리할 수 있나요?
개인정보와 주요 변경 이력은 어떻게 관리하나요?
테스트와 고객 검수 기간이 견적에 포함되나요?
서버와 클라우드 계정은 누구 명의로 생성하나요?
소스코드와 데이터베이스는 어떻게 인계되나요?
운영 매뉴얼이나 API 문서가 제공되나요?
배포 후 오류 수정과 추가 개발의 기준은 무엇인가요?
향후 다른 업체가 유지보수를 맡을 수 있도록 인수인계가 가능한가요?

모든 질문에 복잡한 기술 설명이 필요한 것은 아닙니다.

개발업체가 고객의 업무를 어떤 방식으로 이해하고, 결정되지 않은 내용을 어떻게 구체화하며, 개발 이후 운영까지 어느 범위로 책임지는지 확인하는 것이 핵심입니다.

원소프트의 시스템 개발 범위

원소프트는 웹·앱·AI와 관리자 시스템을 개발하며 프로젝트 상황에 따라 다음 범위를 통합적으로 검토합니다.

요구사항과 업무 흐름 정리
UX/UI 디자인
웹 프론트엔드
Flutter 기반 iOS·Android 앱
백엔드와 API
서버와 데이터베이스
관리자 페이지와 백오피스
결제·소셜 로그인·OCR·푸시·외부 API 연동
AWS와 Docker 기반 배포 환경
기존 서비스 리뉴얼
운영과 유지보수

요청받은 기능을 화면으로 구현하는 데서 끝내기보다 서비스 목적, 사용자 경험, 운영 방식과 향후 확장 가능성을 함께 검토하는 방향으로 프로젝트를 진행합니다.

시스템 개발을 검토하고 있지만 기능 범위가 아직 명확하지 않다면 현재 사용하는 엑셀, 업무 처리 순서, 사용자 유형과 반복되는 수작업부터 정리해보셔도 좋습니다.

모든 기능을 한 번에 개발하기 어렵다면 핵심 업무 흐름을 먼저 구축하고, 통계·자동화·추가 연동은 운영 데이터를 확인한 뒤 단계적으로 확장하는 방법도 검토할 수 있습니다.

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

시스템개발업체에 문의하기 전 모든 요구사항을 완성할 필요는 없습니다.

현재 어떤 업무가 반복되고 있는지, 누가 어떤 데이터를 다루는지, 시스템 도입 후 무엇이 달라져야 하는지를 설명할 수 있다면 개발 범위를 구체화하는 출발점으로 충분합니다.

제목 후보

시스템개발업체 선정 전, 우리 업무에 맞는 개발 범위와 운영 구조를 확인하는 방법
시스템개발업체 비교, 화면과 총견적보다 먼저 확인할 업무 설계 기준
시스템개발업체 문의 전 정리해야 할 권한·상태값·관리자 기능
업무 시스템 개발, 엑셀을 옮기기 전에 운영 구조부터 확인하세요
시스템개발업체 선택 시 견적서에서 확인해야 할 개발·배포·인수인계 범위

메인 키워드

시스템개발업체

서브 키워드

업무시스템개발
관리자시스템개발
시스템개발외주
맞춤형시스템개발
업무자동화개발

썸네일 문구

시스템개발업체 선정 전 확인할 것
화면보다 업무 구조가 먼저입니다
운영 가능한 시스템의 기준

글 요약

시스템개발업체를 선택할 때는 사용자 화면과 총견적만 비교하지 않고, 실제 업무 흐름과 역할별 권한, 상태값, 관리자 기능 및 데이터 구조를 함께 확인해야 합니다. 기존 엑셀과 데이터 이전, 외부 API·ERP 연동, 테스트·배포·인수인계·유지보수까지 동일한 범위로 맞춰야 실제 운영 가능한 시스템과 견적을 비교할 수 있습니다.

CTA 후보

현재 사용 중인 엑셀이나 업무 처리 순서가 있다면 이를 바탕으로 사용자 기능, 관리자 기능과 외부 연동 범위를 함께 정리해드릴 수 있습니다.

시스템 개발이 필요한지, 기존 솔루션이나 단계적 개선으로 해결할 수 있는지 판단하기 어렵다면 현재 업무 방식과 반복되는 수작업부터 공유해 주세요. 초기 구축 범위와 추후 확장 기능을 나누어 검토할 수 있습니다.

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

업무 시스템 요구사항 정의서, 화면 목록보다 먼저 작성해야 할 항목
엑셀 업무를 웹 시스템으로 전환할 때 데이터 구조를 정리하는 방법
시스템 개발 인수인계, 소스코드·서버·데이터베이스·운영 문서 체크리스트