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

고객 요청은 메신저로 접수하고, 담당자는 엑셀에 내용을 옮겨 적습니다.

처리할 업무가 생기면 단체 채팅방에서 담당자를 찾고, 진행 상황은 각 담당자가 엑셀의 상태 칸에 직접 입력합니다. 관련 서류는 이메일이나 공유 폴더에 보관하고, 월말에는 여러 파일의 데이터를 다시 모아 보고서를 만듭니다.

업무량이 적을 때는 이런 방식도 충분히 작동합니다. 담당자가 전체 상황을 기억할 수 있고, 문제가 생겨도 대화 내용을 찾아보면 되기 때문입니다.

하지만 고객과 처리 건수가 늘어나면 상황이 달라집니다.

어느 요청이 아직 처리되지 않았는지 바로 확인하기 어렵습니다.
같은 정보를 엑셀과 메신저에 반복 입력합니다.
최신 파일이 무엇인지 담당자마다 다르게 알고 있습니다.
승인받지 않은 내용이 고객에게 전달되기도 합니다.
담당자가 자리를 비우면 진행 상황을 알기 어렵습니다.
누가 언제 데이터를 수정했는지 확인할 수 없습니다.
월말마다 데이터를 다시 정리해야 합니다.

이때 많은 기업이 시스템개발업체를 찾습니다. 문제는 상담을 시작하면서 현재 사용 중인 엑셀 화면을 그대로 웹으로 만들어 달라고 요청하는 경우가 많다는 점입니다.

그러나 엑셀을 웹 화면으로 옮기는 것만으로는 업무 방식이 크게 달라지지 않을 수 있습니다. 기존 수작업과 중복 입력이 그대로 남은 채 사용 도구만 바뀔 가능성이 있기 때문입니다.

웹 기반 업무 시스템을 구축하려면 화면 수나 총견적보다 실제 업무가 어떤 순서로 진행되는지, 누가 어떤 데이터를 다루는지, 어떤 조건에서 다음 단계로 넘어가는지를 먼저 정리해야 합니다.

1. 시스템개발업체에 문의하기 전, 먼저 해결할 업무를 정리해야 하는 이유

“엑셀로 관리하는 업무를 시스템으로 바꾸고 싶습니다”라는 요청만으로는 개발 범위를 구체적으로 산정하기 어렵습니다.

같은 고객 관리 엑셀이라도 실제 운영 방식은 회사마다 다릅니다.

한 회사는 고객의 기본 정보와 상담 내용만 관리할 수 있습니다. 다른 회사는 상담 이후 견적 작성, 내부 승인, 계약, 작업 배정, 정산까지 연결해서 관리할 수 있습니다.

두 시스템에 모두 고객 목록 화면이 들어가더라도 필요한 기능과 데이터 구조는 상당히 달라집니다.

먼저 현재 업무에서 발생하는 문제를 다음과 같이 구체적으로 적어보는 것이 좋습니다.

| 현재 문제 | 시스템에서 필요한 방향 | |---|---| | 요청이 메신저와 이메일에 흩어져 있음 | 요청 접수 데이터를 한곳에서 관리 | | 담당자를 단체 채팅방에서 찾음 | 담당자 배정 및 담당 업무 목록 제공 | | 처리 상태를 매번 물어봐야 함 | 단계별 상태와 처리 현황 표시 | | 승인 여부가 대화 내용에만 남음 | 승인 요청·승인·반려 이력 관리 | | 서류가 공유 폴더에 따로 있음 | 업무 건별 파일 연결 | | 월말 보고서를 수작업으로 작성함 | 기간·담당자·상태별 조회와 다운로드 | | 담당자 변경 시 인수인계가 어려움 | 처리 이력과 메모를 업무 건에 기록 |

이렇게 정리하면 시스템의 목적이 단순히 “엑셀을 없애는 것”이 아니라는 점이 보입니다.

예를 들어 핵심 문제가 담당자 누락이라면 담당자 배정과 미처리 업무 알림이 우선입니다. 승인 과정이 문제라면 권한과 승인 상태 설계가 먼저 필요합니다. 월말 집계 시간이 오래 걸린다면 검색, 필터, 통계, 다운로드 기능의 우선순위가 높아집니다.

따라서 시스템개발업체에 전달할 첫 번째 자료는 화면 목록보다 다음 문장에 가깝습니다.

고객 요청이 접수되면 운영 담당자가 내용을 확인하고 담당자를 배정합니다. 담당자가 자료를 검토한 뒤 승인 요청을 등록하고, 팀장이 승인하면 고객에게 결과를 전달합니다. 이후 완료 건은 정산 담당자가 확인합니다.

이 문장에는 사용자, 업무 단계, 승인 조건과 다음 담당자가 함께 나타납니다. 개발사는 이를 바탕으로 필요한 기능과 데이터 구조를 구체적으로 검토할 수 있습니다.

2. 엑셀·메신저 업무를 사용자 유형과 업무 단계별로 나누기

업무 시스템을 설계할 때는 먼저 사용자를 구분해야 합니다.

단순히 관리자와 일반 사용자 두 종류로만 나누면 실제 업무를 충분히 표현하기 어려운 경우가 많습니다.

예를 들어 기업 내부의 요청 처리 시스템이라면 다음과 같은 사용자가 있을 수 있습니다.

요청을 등록하는 고객 또는 내부 직원
접수 내용을 확인하는 운영 담당자
실제 업무를 처리하는 실무 담당자
결과를 검토하고 승인하는 팀장
계약이나 비용을 확인하는 정산 담당자
전체 사용자와 기준정보를 관리하는 시스템 관리자

사용자 유형을 구분했다면 각 사용자가 어떤 행동을 하는지 정리합니다.

| 사용자 | 주요 업무 | |---|---| | 요청자 | 요청 등록, 자료 첨부, 진행 상태 확인 | | 운영 담당자 | 요청 검토, 담당자 배정, 보완 요청 | | 실무 담당자 | 업무 처리, 결과 입력, 승인 요청 | | 승인 담당자 | 처리 결과 검토, 승인 또는 반려 | | 정산 담당자 | 비용·결제·정산 상태 확인 | | 시스템 관리자 | 사용자, 권한, 기준정보, 공지 관리 |

다음으로 업무가 어떤 단계를 거치는지 적습니다.

``text 요청 접수 → 내용 확인 → 담당자 배정 → 업무 처리 → 검토 요청 → 승인 또는 반려 → 고객 전달 → 완료 → 정산 ``

현재 업무가 이 순서대로만 진행되지 않을 수도 있습니다.

내용이 부족하면 요청자에게 보완을 요청할 수 있고, 담당자가 처리한 결과가 반려되면 다시 수정 단계로 돌아갈 수 있습니다. 업무가 취소되거나 다른 담당자에게 재배정될 수도 있습니다.

따라서 정상적인 진행 순서뿐 아니라 다음과 같은 예외 상황도 함께 정리해야 합니다.

요청 내용이 부족한 경우
담당자가 변경되는 경우
승인자가 부재중인 경우
처리 결과가 반려되는 경우
고객이 진행 도중 요청을 취소하는 경우
첨부 서류가 잘못 등록된 경우
이미 완료한 업무를 다시 열어야 하는 경우
외부 시스템 전송에 실패한 경우

개발 범위는 정상적인 화면보다 이런 예외 처리에서 더 크게 달라지기도 합니다.

시스템개발업체를 비교할 때도 기능의 존재 여부만 보기보다, 실제 업무와 예외 상황을 어디까지 이해하고 견적에 반영했는지 확인할 필요가 있습니다.

3. 단순 조회와 등록을 넘어 필요한 권한·승인·상태값 설계

웹 시스템의 권한은 메뉴를 보여주거나 숨기는 기능만을 의미하지 않습니다.

같은 업무 화면에 접속하더라도 사용자마다 조회할 수 있는 데이터와 실행할 수 있는 작업이 달라야 할 수 있습니다.

예를 들어 실무 담당자는 자신에게 배정된 업무만 조회할 수 있고, 팀장은 소속 팀 전체의 업무를 확인할 수 있습니다. 정산 담당자는 완료된 건의 금액과 정산 정보는 확인할 수 있지만 고객의 민감한 상담 내용은 볼 필요가 없을 수 있습니다.

권한은 다음처럼 나누어 검토할 수 있습니다.

목록 조회 권한
상세 조회 권한
신규 등록 권한
수정 권한
삭제 권한
승인·반려 권한
담당자 배정 권한
파일 다운로드 권한
개인정보 조회 권한
엑셀 다운로드 권한
통계 조회 권한
기준정보 관리 권한

보안 설계에서는 사용자가 업무 수행에 필요한 최소한의 권한만 갖도록 구성하는 최소 권한 원칙이 기본적인 판단 기준으로 활용됩니다. OWASP도 사용자 유형, 보호할 자원, 조회·수정과 같은 작업을 설계 단계에서 구체적으로 나누고 권한이 실제 요청마다 적용되는지 검증할 것을 권고합니다. (cheatsheetseries.owasp.org)

승인 기능도 단순한 승인 버튼 하나로 끝나지 않습니다.

다음 항목을 함께 정해야 합니다.

누가 승인을 요청할 수 있는가?
승인자는 사용자마다 고정되는가, 조직에 따라 달라지는가?
금액이나 업무 유형에 따라 승인 단계가 달라지는가?
승인 요청 후 원본 데이터를 수정할 수 있는가?
수정했다면 다시 승인을 받아야 하는가?
반려할 때 사유 입력이 필수인가?
승인자가 자리를 비우면 대리 승인이 가능한가?
최종 승인 이후 취소하려면 별도 권한이 필요한가?

상태값도 실제 업무 단계를 기준으로 설계해야 합니다.

대기, 진행, 완료 세 가지 상태만으로는 부족할 수 있습니다.

예를 들어 다음처럼 더 구체적인 상태가 필요할 수 있습니다.

접수 대기
내용 확인 중
자료 보완 요청
담당자 배정 대기
처리 중
내부 검토 중
승인 대기
반려
고객 확인 대기
완료
취소
정산 대기
정산 완료

상태가 많을수록 좋은 것은 아닙니다. 업무 담당자가 현재 단계와 다음 행동을 구분하는 데 필요한 수준으로 정리해야 합니다.

상태 이름만 만드는 것도 부족합니다. 각 상태에서 누가 무엇을 할 수 있는지 함께 정의해야 합니다.

| 현재 상태 | 가능한 작업 | 작업 가능한 사용자 | 다음 상태 | |---|---|---|---| | 접수 대기 | 접수 확인 | 운영 담당자 | 내용 확인 중 | | 내용 확인 중 | 보완 요청 | 운영 담당자 | 자료 보완 요청 | | 처리 중 | 승인 요청 | 실무 담당자 | 승인 대기 | | 승인 대기 | 승인 | 승인 담당자 | 고객 확인 대기 | | 승인 대기 | 반려 | 승인 담당자 | 반려 | | 반려 | 내용 수정 | 실무 담당자 | 처리 중 | | 고객 확인 대기 | 완료 처리 | 운영 담당자 | 완료 |

이런 표를 준비하면 개발사가 업무 규칙을 더 정확하게 이해할 수 있고, 테스트 시나리오도 구체적으로 만들 수 있습니다.

4. 사용자 화면과 관리자 페이지의 역할을 구분하는 방법

사용자 화면은 요청 등록과 진행 상황 확인을 편리하게 만드는 데 초점이 있습니다.

반면 관리자 페이지는 서비스 운영 과정에서 발생하는 예외와 반복 업무를 처리하는 도구입니다.

예를 들어 사용자 화면에 요청 등록 기능이 있다면 관리자 페이지에는 다음 기능이 필요할 수 있습니다.

신규 요청 목록 확인
요청 내용 검토
담당자 배정 및 재배정
우선순위 설정
자료 보완 요청
처리 상태 변경
내부 메모 작성
첨부 파일 확인
승인 요청 및 승인 결과 확인
고객 안내 발송
처리 이력 조회
완료·취소 처리

사용자 화면만 구체적으로 기획하고 관리자 페이지를 “관리 기능 일체”와 같이 간단하게 정의하면 견적 단계에서 해석 차이가 발생할 수 있습니다.

어떤 시스템개발업체는 목록 조회와 상세 화면만 관리자 기능으로 산정할 수 있습니다. 다른 업체는 검색, 필터, 일괄 처리, 권한, 변경 이력, 통계까지 포함할 수 있습니다.

따라서 사용자 기능과 관리자 기능을 연결해서 적는 것이 좋습니다.

| 사용자 행동 | 뒤따르는 관리자 업무 | |---|---| | 회원가입 | 가입 정보 확인, 상태 변경, 이용 제한 | | 요청 등록 | 요청 검토, 담당자 배정, 보완 요청 | | 파일 첨부 | 파일 확인, 교체 요청, 보관 | | 결제 | 결제 내역 조회, 취소·환불 확인 | | 문의 등록 | 담당자 배정, 답변, 처리 상태 관리 | | 취소 요청 | 취소 가능 여부 확인, 승인, 후속 처리 | | 정보 수정 | 변경 내용 검토, 이력 확인 |

운영자가 실제로 어떤 순서로 업무를 처리하는지도 확인해야 합니다.

관리자 페이지에 모든 기능이 있더라도 메뉴를 여러 번 이동해야 하거나 한 건씩 반복 처리해야 한다면 운영팀은 다시 엑셀을 사용할 가능성이 있습니다.

관리자 시스템은 기능의 개수보다 한 화면에서 어떤 정보를 함께 확인해야 하는지, 다음 작업으로 얼마나 자연스럽게 이어지는지가 중요합니다.

5. 기존 엑셀 데이터 이전과 외부 API·ERP 연동 범위 확인하기

새 시스템을 구축해도 기존 데이터를 활용하지 못하면 운영 전환이 어려울 수 있습니다.

다만 “엑셀 데이터를 이전한다”는 문장만으로는 범위가 충분히 정해지지 않습니다.

먼저 이전할 파일을 모아 다음 항목을 확인해야 합니다.

엑셀 파일은 몇 종류인가?
파일마다 열 이름과 형식이 같은가?
동일한 고객이나 거래처가 중복 등록되어 있는가?
담당자 이름이 일정한 형식으로 관리되고 있는가?
날짜와 금액 데이터의 형식이 통일되어 있는가?
비어 있거나 잘못 입력된 값은 어떻게 처리할 것인가?
기존 첨부 파일도 함께 이전해야 하는가?
메신저와 이메일에만 남아 있는 이력도 필요한가?
전체 데이터를 이전할 것인가, 최근 데이터만 이전할 것인가?

예를 들어 거래처명이 원소프트, 원 소프트, OneSoft처럼 서로 다르게 입력되어 있다면 같은 거래처인지 구분하는 정리 작업이 필요합니다.

담당자가 퇴사했거나 현재 조직 정보와 맞지 않는 경우도 있습니다. 기존 상태값이 진행, 작업 중, 처리 중처럼 혼용되어 있다면 새 시스템의 상태값으로 변환하는 기준도 정해야 합니다.

데이터 이전은 보통 다음 순서로 검토합니다.

원본 파일 수집
열과 데이터 형식 분석
중복·누락·오류 확인
새 시스템 항목과 매핑
변환 규칙 정의
일부 데이터로 시험 이전
결과 검수
최종 데이터 이전
기존 파일의 보관·폐기 정책 확인

외부 API나 ERP 연동도 “연동 여부”만 확인해서는 부족합니다.

다음 내용을 구체적으로 정해야 합니다.

어떤 데이터를 주고받는가?
어느 시스템의 데이터를 원본으로 보는가?
실시간으로 연동하는가, 일정 시간마다 처리하는가?
신규 등록만 연동하는가, 수정·취소도 반영하는가?
양쪽 시스템의 식별자는 어떻게 연결하는가?
전송에 실패하면 자동으로 재시도하는가?
일부 데이터만 성공한 경우 어떻게 처리하는가?
운영자가 실패 원인을 확인할 수 있는가?
운영자가 직접 재전송할 수 있는가?
API 계정과 이용 계약은 누가 준비하는가?

외부 시스템은 우리 시스템과 별개로 점검되거나 응답이 지연될 수 있습니다. 따라서 정상적인 연동뿐 아니라 실패 상태, 재시도, 중복 방지, 로그와 관리자 재처리 기능도 범위에 포함할지 확인해야 합니다.

6. 검색·필터·일괄 처리·변경 이력 등 운영 효율을 높이는 기능

관리자 시스템에서 목록 화면은 단순히 데이터를 보여주는 공간이 아닙니다.

운영자가 처리할 업무를 찾고, 우선순위를 판단하며, 여러 건을 빠르게 처리하는 작업 공간입니다.

예를 들어 요청 목록에 다음 검색 조건이 필요할 수 있습니다.

접수 기간
고객명 또는 거래처명
담당자
담당 부서
업무 유형
처리 상태
승인 상태
정산 상태
우선순위
지연 여부
특정 자료의 제출 여부

검색 조건은 많다고 무조건 편리한 것이 아닙니다. 운영팀이 매일 반복해서 사용하는 조건을 먼저 제공해야 합니다.

자주 사용하는 조회 조건을 저장하거나, 로그인한 담당자의 미처리 업무를 기본 화면으로 보여주는 방식도 검토할 수 있습니다.

여러 건을 반복 처리하는 업무라면 일괄 기능이 필요할 수 있습니다.

여러 건 담당자 일괄 배정
상태 일괄 변경
안내 메시지 일괄 발송
선택한 데이터 다운로드
파일 일괄 업로드
승인 대상 일괄 선택
정산 대상 일괄 확정

다만 일괄 처리는 실수를 크게 만들 수도 있습니다.

따라서 처리 전 대상 건수와 변경 내용을 확인하게 하고, 일부 건이 실패했을 때 성공한 건과 실패한 건을 구분해서 보여주는 것이 좋습니다. 중요한 상태 변경은 취소 가능 여부나 별도 승인 절차도 검토해야 합니다.

변경 이력은 운영 과정에서 발생한 문제를 확인하는 데 사용됩니다.

예를 들어 고객에게 잘못된 안내가 발송되었다면 다음 내용을 확인할 수 있어야 합니다.

누가 작업했는가?
언제 작업했는가?
어떤 데이터를 변경했는가?
변경 전 값은 무엇이었는가?
변경 후 값은 무엇인가?
어떤 화면이나 기능을 통해 변경했는가?
승인 또는 반려 사유가 무엇인가?

OWASP의 애플리케이션 로그 지침도 데이터의 등록·수정·삭제와 다운로드, 사용자, 대상, 처리 결과 등을 감사 추적과 운영 문제 분석에 활용할 수 있다고 설명합니다. 다만 민감한 정보를 지나치게 기록하지 않도록 로그의 목적과 범위를 함께 정해야 합니다. (cheatsheetseries.owasp.org)

개인정보를 처리하는 시스템이라면 관련 법령과 고시도 확인해야 합니다. 2026년 7월 1일부터 시행 중인 「개인정보의 안전성 확보조치 기준」은 개인정보처리시스템의 접속기록을 식별자, 접속일시, 접속지, 처리한 정보주체, 수행 업무 등을 전자적으로 기록한 것으로 정의하고 있습니다. 시스템의 업종, 개인정보 규모와 처리 방식에 따라 적용 범위가 달라질 수 있으므로 실제 구축 시에는 관련 요건을 별도로 검토해야 합니다. (law.go.kr)

7. 보안·테스트·배포·소스코드 인수인계와 유지보수 조건 점검하기

시스템개발업체의 견적을 비교할 때 기능 개발만 확인하면 운영 준비에 필요한 항목이 빠질 수 있습니다.

보안 범위

보안은 로그인 화면을 만드는 것으로 끝나지 않습니다.

다음 항목을 확인해야 합니다.

비밀번호 저장과 재설정 방식
사용자별 접근 권한
개인정보 조회 및 다운로드 권한
민감 정보 마스킹
관리자 접속 제한
로그인 실패와 이상 접근 대응
접속 및 변경 이력
파일 접근 권한
데이터 전송 구간 보호
사용하지 않는 계정의 비활성화
퇴사자와 역할 변경자의 권한 회수
백업 데이터 접근 관리

개인정보의 안전성 확보조치 기준은 개인정보의 분실·도난·유출·위조·변조 또는 훼손 방지를 위한 관리적·기술적·물리적 안전조치의 최소 기준을 정하고 있습니다. 개인정보처리시스템을 구축한다면 화면 기능과 별도로 접근권한, 접속기록, 다운로드 점검 등 필요한 조치의 적용 여부를 확인해야 합니다. (law.go.kr)

테스트 범위

“개발 완료 후 테스트”라는 표현만으로는 누가 무엇을 확인하는지 알기 어렵습니다.

견적서나 계약 범위에서 다음 사항을 확인하는 것이 좋습니다.

개발사의 내부 기능 테스트가 포함되는가?
고객사의 사용자 검수 기간은 얼마나 되는가?
테스트 계정과 테스트 데이터는 누가 준비하는가?
권한별 테스트를 진행하는가?
데이터 이전 결과를 어떻게 검수하는가?
외부 API의 성공·실패 상황을 모두 확인하는가?
모바일·태블릿·브라우저 범위는 어디까지인가?
오류 수정과 요구사항 변경을 어떻게 구분하는가?
오픈 전 최종 점검 기준은 무엇인가?

특히 권한 기능은 관리자 계정 하나로만 테스트해서는 부족합니다.

운영 담당자, 실무 담당자, 승인자, 정산 담당자 계정을 각각 만들어 조회·등록·수정·승인·다운로드 권한이 설계대로 작동하는지 확인해야 합니다.

배포와 운영 환경

시스템을 어느 서버에 배포할지도 미리 정해야 합니다.

클라우드 또는 서버 계정의 소유자는 누구인가?
도메인과 인증서 관리 주체는 누구인가?
개발·테스트·운영 환경을 분리하는가?
데이터베이스 백업 주기와 보관 방식은 무엇인가?
장애 알림은 누가 받는가?
서버 비용과 외부 서비스 비용은 누가 결제하는가?
운영 배포 권한은 누구에게 있는가?
긴급 수정이 필요할 때 절차는 무엇인가?

NIST의 보안 소프트웨어 개발 지침은 보안을 별도 최종 단계로만 보지 않고 계획, 개발, 빌드, 테스트, 배포와 운영 전반에 통합할 것을 권고합니다. 따라서 업체 비교 시에도 보안을 특정 기능 하나가 아니라 개발과 운영 과정 전체의 범위로 확인하는 편이 적절합니다. (nist.gov)

소스코드와 계정 인수인계

프로젝트가 종료된 후 무엇을 전달받는지도 확인해야 합니다.

프론트엔드와 백엔드 소스코드
데이터베이스 구조와 주요 데이터 정의
배포 방법과 환경 설정 안내
관리자 계정
서버·클라우드 계정
도메인과 인증서 관리 정보
외부 API 계정
소셜 로그인·결제·알림 서비스 계정
API 문서
운영자 사용 안내
백업 및 복구 방법
주요 변경 이력
오픈소스 또는 외부 라이브러리 정보

모든 프로젝트에 동일한 문서가 필요한 것은 아니지만, 향후 유지보수에 필요한 자료와 계정의 소유권은 계약 전에 정리하는 것이 좋습니다.

NIST 지침에서도 각 소프트웨어 릴리스의 소스코드, 빌드 자료와 관련 산출물을 보존하는 것이 이후 취약점 분석과 유지보수에 도움이 된다고 설명합니다. (pages.nist.gov)

유지보수 조건

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

기존 요구사항대로 작동하지 않는 오류
운영 환경이나 외부 서비스 변경에 따른 수정
새로운 화면이나 기능 추가
업무 정책 변경에 따른 로직 수정
데이터 직접 보정
관리자 문의 대응
서버와 배포 관리
보안 업데이트
긴급 장애 대응

유지보수 기간만 비교하지 말고 대응 범위와 방식도 확인해야 합니다.

예를 들어 월 유지보수 계약에 서버 모니터링이 포함되는지, 기능 변경은 별도 견적인지, 긴급 장애의 연락 방법과 대응 시간이 정해져 있는지를 살펴봐야 합니다.

8. 1차 구축 기능과 이후 확장 기능을 나눠 시스템개발업체 견적 비교하기

업무를 정리하다 보면 필요한 기능이 계속 늘어날 수 있습니다.

처음에는 고객 요청과 담당자 배정만 필요했지만 논의를 진행하면서 통계, 알림, 모바일 화면, ERP 연동, 자동 보고서, 전자서명 기능까지 추가될 수 있습니다.

모든 기능을 첫 구축에 포함하면 개발 기간과 검수 범위가 커지고, 아직 정해지지 않은 업무 정책까지 함께 구현해야 할 수 있습니다.

따라서 기능을 다음 세 단계로 나누는 방법이 실무적입니다.

1차 구축에 포함할 기능

핵심 업무가 처음부터 끝까지 처리되기 위해 필요한 기능입니다.

사용자 로그인
사용자와 역할 관리
요청 등록
담당자 배정
상태 변경
승인·반려
첨부 파일
검색과 필터
처리 이력
기본 관리자 기능
필수 데이터 이전
운영 배포

운영 후 추가할 기능

시스템 사용 데이터가 쌓인 뒤 구체화해도 되는 기능입니다.

상세 통계와 대시보드
반복 업무 자동 배정
고급 보고서
다양한 알림 채널
모바일 전용 화면
복잡한 일괄 처리
추가 외부 시스템 연동

별도 검증이 필요한 기능

외부 환경이나 정책이 확정되어야 범위를 정할 수 있는 기능입니다.

ERP 양방향 연동
대규모 과거 데이터 이전
AI 기반 문서 인식과 분류
전자계약·전자서명
복잡한 정산 자동화
여러 법인이나 지점의 데이터 분리
외부 파트너용 별도 서비스

업체별 견적을 비교할 때는 총금액보다 같은 기능이 같은 범위로 산정되었는지 확인해야 합니다.

| 비교 항목 | 업체 A | 업체 B | 업체 C | |---|---|---|---| | 요구사항 정리·기획 | 포함 | 일부 포함 | 별도 | | 사용자 화면 | 포함 | 포함 | 포함 | | 관리자 페이지 | 기본 조회 | 권한·검색 포함 | 별도 | | 데이터 이전 | 1회 포함 | 샘플 이전만 | 별도 | | 외부 API 연동 | 1종 포함 | 미포함 | 별도 산정 | | 권한 설계 | 역할별 포함 | 관리자·사용자만 | 협의 필요 | | 테스트 | 내부 테스트 | 사용자 검수 포함 | 기간 확인 필요 | | 서버 배포 | 포함 | 별도 | 포함 | | 소스코드 전달 | 포함 | 계약 확인 | 포함 | | 하자 수정 | 기간 명시 | 범위 명시 | 별도 확인 | | 유지보수 | 선택 계약 | 월 계약 | 건별 계약 |

이 표를 작성하면 가장 저렴한 업체를 찾기보다, 현재 업무에 필요한 범위를 구체적으로 제안한 업체를 구분하기 쉬워집니다.

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

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

다만 다음 자료를 준비하면 개발사가 현재 업무와 예상 범위를 이해하는 데 도움이 됩니다.

현재 사용하는 엑셀 파일
업무에 사용하는 문서 양식
사용자와 담당 부서 목록
실제 업무 처리 순서
승인·반려가 발생하는 조건
메신저로 반복해서 주고받는 내용
월간 보고서나 집계 자료
기존 ERP·회계·고객 관리 시스템 정보
필요한 외부 API 문서
개인정보와 민감 정보의 종류
반드시 1차에 필요한 기능
이후 추가해도 되는 기능
목표 오픈 시점
예상 사용자와 운영자 범위

엑셀 파일에는 회사의 업무 규칙이 많이 담겨 있습니다.

열 이름, 수식, 색상, 시트 구분, 담당자의 메모를 살펴보면 어떤 데이터가 중요한지 알 수 있습니다. 다만 엑셀 화면을 그대로 웹으로 옮기기보다, 왜 그 열과 수식이 필요한지 확인한 뒤 시스템의 데이터와 업무 흐름으로 다시 설계해야 합니다.

복잡한 업무형 시스템은 데이터와 상태를 함께 봐야 합니다

원소프트가 개발에 참여한 부동산 경매 업무 통합 플랫폼 바토너는 경매 물건 조회만 제공하는 단순 정보 서비스가 아니었습니다.

입찰 신청 이후 계약 문서 처리, 결제, 포인트, 정산, 알림과 문의가 연결되는 업무형 플랫폼이었습니다. 일반 회원, 전문가, 운영자의 역할을 구분하고, 입찰·계약·결제·정산의 진행 상태를 하나의 업무 흐름으로 관리할 수 있도록 백엔드와 API를 구성했습니다.

이런 시스템에서는 화면 하나를 만드는 것보다 다음 구조를 정하는 일이 중요합니다.

사용자 유형별 접근 범위
단계별 업무 상태
상태가 바뀌는 조건
계약과 결제 데이터의 연결
운영자가 확인할 관리자 데이터
문서 인식 결과를 업무에 반영하는 과정
알림과 문의 처리 이력

엑셀과 메신저로 관리하던 사내 업무를 웹 시스템으로 전환할 때도 같은 관점이 필요합니다.

먼저 화면을 나열하기보다 데이터가 어디에서 생성되고, 누가 확인하며, 어떤 조건에서 수정되고, 다음 담당자에게 어떻게 전달되는지를 살펴봐야 합니다.

시스템개발업체 문의 전 최종 체크리스트

아래 항목에 답할 수 있다면 업체별 제안과 견적을 비교하기가 한결 쉬워집니다.

[ ] 시스템으로 해결하려는 문제가 구체적인가?
[ ] 현재 업무의 시작과 종료 조건을 설명할 수 있는가?
[ ] 시스템을 사용할 사용자 유형을 나누었는가?
[ ] 사용자별 조회·등록·수정·승인 권한이 다른가?
[ ] 정상적인 처리 순서와 예외 상황을 정리했는가?
[ ] 실제 업무에 맞는 상태값을 정의했는가?
[ ] 사용자 행동 이후 필요한 관리자 업무를 확인했는가?
[ ] 자주 사용하는 검색과 필터 조건을 정리했는가?
[ ] 여러 건을 반복 처리하는 업무가 있는가?
[ ] 누가 무엇을 변경했는지 기록할 필요가 있는가?
[ ] 이전할 엑셀 파일과 데이터 범위를 확인했는가?
[ ] ERP·회계·결제 등 외부 연동 대상이 있는가?
[ ] 외부 연동 실패 시 대응 방법이 필요한가?
[ ] 개인정보와 민감 정보의 접근 범위를 정했는가?
[ ] 테스트와 사용자 검수의 담당자를 정했는가?
[ ] 서버·도메인·외부 서비스 계정의 소유자를 확인했는가?
[ ] 소스코드와 운영 자료의 인수인계 범위를 확인했는가?
[ ] 하자 수정과 추가 개발을 구분했는가?
[ ] 1차 구축과 이후 확장 기능을 나누었는가?
[ ] 업체별 견적의 포함·제외 항목을 같은 표로 비교했는가?

웹 기반 업무 시스템은 엑셀을 보기 좋은 화면으로 바꾸는 프로젝트가 아닙니다.

흩어진 데이터와 대화를 하나의 업무 흐름으로 연결하고, 담당자와 권한을 구분하며, 진행 상태와 변경 이력을 운영자가 확인할 수 있도록 만드는 과정입니다.

시스템개발업체를 비교할 때도 화면 디자인과 총견적만 보기보다 현재 업무를 얼마나 구체적으로 이해했는지, 사용자 화면과 관리자 운영을 함께 설계하는지, 데이터 이전과 연동·테스트·인수인계까지 설명하는지를 확인하는 것이 좋습니다.

원소프트는 웹·앱·AI와 관리자 시스템을 개발하며, 사용자 기능뿐 아니라 운영자의 처리 흐름과 데이터 구조를 함께 검토합니다. 현재 사용 중인 엑셀과 업무 순서가 있다면 이를 바탕으로 1차 구축 범위와 이후 확장 기능을 나누어 볼 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치하고 있습니다. 화성·동탄을 비롯해 수원, 용인, 기흥, 오산 등 경기 남부에서 업무 시스템 구축을 검토하고 계신 경우에도 온라인 미팅을 통해 현재 운영 방식과 필요한 기능을 함께 정리할 수 있습니다.

제목 후보

시스템개발업체 문의 전, 엑셀·메신저 업무를 웹 시스템으로 전환하는 기준
시스템개발업체 비교, 화면과 총견적보다 업무 흐름을 먼저 확인하세요
엑셀 업무를 웹 시스템으로 바꾸기 전 정리해야 할 8가지
시스템개발업체 견적 비교, 권한·데이터·관리자 범위를 확인하는 방법
사내 업무 시스템 개발, 엑셀과 메신저를 그대로 옮기면 안 되는 이유

메인 키워드

시스템개발업체

서브 키워드

업무시스템개발
웹시스템개발
관리자시스템개발
사내시스템구축
업무자동화개발

썸네일 문구

엑셀 업무, 시스템으로 바꾸는 기준
시스템개발업체 문의 전 체크할 것
화면보다 업무 흐름이 먼저입니다

글 요약

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

CTA 후보

현재 사용 중인 엑셀과 실제 업무 순서를 정리해 주시면, 웹 시스템으로 전환할 범위와 1차 구축에서 우선할 기능을 함께 검토해드릴 수 있습니다.

업체별 견적의 범위가 달라 비교하기 어렵다면 사용자, 관리자, 데이터 이전과 외부 연동 항목을 기준으로 요구사항을 나누어 볼 수 있습니다.

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

사내 업무시스템 개발, 엑셀 데이터 이전 전에 정리해야 할 기준
관리자 시스템 권한 설계, 조회·수정·승인·다운로드 범위를 나누는 방법
업무 자동화 개발, 반복 작업과 예외 처리를 구분해 우선순위 정하는 방법