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

고객 요청은 메신저로 접수하고, 진행 현황은 담당자별 엑셀 파일에 기록하고, 최종 승인 내용은 이메일로 전달하는 기업이 적지 않습니다.

업무량이 많지 않고 담당자가 한두 명일 때는 이러한 방식도 충분히 작동합니다. 새로운 도구를 도입하지 않아도 되고, 엑셀 양식을 필요에 따라 바로 수정할 수 있다는 장점도 있습니다.

문제는 업무가 늘어나면서 시작됩니다.

같은 고객 정보를 여러 파일에 반복해서 입력합니다.
최신 파일이 무엇인지 확인하기 어려워집니다.
담당자가 자리를 비우면 진행 상황을 알 수 없습니다.
메신저에서 승인받은 내용을 다시 찾느라 시간이 걸립니다.
누가 언제 데이터를 변경했는지 확인하기 어렵습니다.
월말 보고서를 만들기 위해 여러 엑셀 파일을 다시 합칩니다.

이 단계에서 기업은 시스템개발업체를 찾아보기 시작합니다.

하지만 상담 과정에서 필요한 기능을 설명해달라는 질문을 받으면, 대부분은 현재 사용하고 있는 엑셀 열이나 화면 목록부터 이야기합니다.

“고객 목록 화면이 필요합니다.”

“접수 내용을 등록하고 수정할 수 있어야 합니다.”

“엑셀 다운로드도 가능해야 합니다.”

이러한 정보도 필요하지만, 이것만으로는 실제 개발 범위를 정하기 어렵습니다. 같은 고객 관리 화면이라도 담당자별 조회 범위, 승인 절차, 상태 변경 규칙, 첨부파일 관리, 외부 시스템 연동 여부에 따라 개발 내용이 달라지기 때문입니다.

시스템개발업체의 견적을 현실적으로 비교하려면 화면 수보다 현재 업무가 어떤 순서로 처리되는지, 누가 어떤 데이터를 볼 수 있는지, 업무 상태가 어떻게 변경되는지, 관리자가 무엇을 처리해야 하는지를 먼저 정리해야 합니다.

엑셀과 메신저를 계속 사용해도 되는 업무가 있습니다

엑셀을 사용한다는 이유만으로 반드시 웹 시스템을 개발해야 하는 것은 아닙니다.

업무 빈도가 낮고, 데이터를 다루는 사람이 한 명이며, 승인이나 권한 구분이 거의 없다면 엑셀이 더 효율적일 수 있습니다. 업무 정책이 계속 바뀌는 초기 단계에서도 시스템을 서둘러 만들기보다 엑셀로 운영 방식을 검증하는 편이 나을 수 있습니다.

다음 조건에 해당한다면 현재 도구를 유지하면서 양식과 관리 규칙을 정리하는 것부터 시작할 수 있습니다.

업무 담당자가 한두 명으로 고정되어 있다.
동시에 같은 데이터를 수정할 일이 거의 없다.
처리 건수가 많지 않다.
업무 단계가 등록과 완료 정도로 단순하다.
고객이나 거래처가 직접 시스템을 사용할 필요가 없다.
승인 이력이나 변경 이력이 중요하지 않다.
다른 시스템과 데이터를 연결할 필요가 없다.

반면 업무 자체는 계속 처리되고 있지만, 관리 비용과 오류 가능성이 커지고 있다면 웹 기반 업무 시스템을 검토할 시점일 수 있습니다.

웹 시스템 전환을 검토할 수 있는 신호

1. 같은 정보를 여러 번 입력하고 있습니다

고객이 신청서를 제출하면 담당자가 내용을 엑셀에 옮기고, 업무가 완료되면 다른 정산 파일에 다시 입력하는 방식이 대표적입니다.

한 번의 업무를 처리하기 위해 이름, 연락처, 상품, 금액, 담당자 정보를 여러 문서에 반복 입력한다면 누락과 불일치가 발생할 가능성이 커집니다.

웹 시스템에서는 고객, 신청, 결제, 처리 내역을 서로 연결된 데이터로 관리할 수 있습니다. 고객 정보를 한 번 등록한 뒤 관련 업무에서 참조하는 구조를 만들면 반복 입력을 줄일 수 있습니다.

2. 최신 파일을 찾는 데 시간이 걸립니다

파일명에 날짜나 최종이라는 문구가 반복해서 붙기 시작했다면 버전 관리가 어려워졌다는 의미일 수 있습니다.

고객목록_최종.xlsx
고객목록_최종수정.xlsx
고객목록_최종수정2.xlsx
고객목록_팀장확인.xlsx

웹 시스템은 여러 사람이 같은 데이터를 기준으로 업무를 처리하게 합니다. 다만 단순히 데이터를 한곳에 저장하는 것만으로 충분하지는 않습니다. 동시 수정이 발생했을 때의 처리 방식과 변경 이력, 수정 권한도 함께 설계해야 합니다.

3. 담당자에게 물어봐야만 진행 상황을 알 수 있습니다

메신저 대화와 개인 파일에 업무 정보가 남아 있으면 담당자가 자리를 비웠을 때 다른 사람이 현재 상황을 파악하기 어렵습니다.

시스템에서는 접수, 검토, 승인, 처리, 완료처럼 업무 단계를 상태값으로 관리할 수 있습니다. 각 건의 현재 상태와 담당자, 마지막 처리 시점, 다음에 해야 할 업무를 확인할 수 있어야 합니다.

4. 누락 여부를 사람이 계속 확인하고 있습니다

매일 아침 접수 목록과 처리 목록을 비교하고, 답변하지 않은 메신저가 있는지 사람이 직접 확인하고 있다면 시스템화할 수 있는 규칙이 있는지 살펴볼 필요가 있습니다.

예를 들어 다음과 같은 조건은 자동 조회나 알림으로 전환할 수 있습니다.

접수 후 24시간 이상 담당자가 배정되지 않은 건
검토 완료 후 승인이 진행되지 않은 건
결제는 완료됐지만 업무 처리가 시작되지 않은 건
완료 예정일이 지났지만 미완료 상태인 건
필수 서류가 첨부되지 않은 건

5. 보고서를 만들기 위해 데이터를 다시 가공합니다

운영 데이터는 쌓이고 있지만 월별 건수, 담당자별 처리량, 상태별 현황을 확인하기 위해 매번 엑셀을 합치고 있다면 데이터 구조를 다시 살펴봐야 합니다.

다만 통계 화면을 많이 만드는 것보다 먼저 해야 할 일은 원본 데이터의 기준을 정하는 것입니다. 상태값과 완료일, 담당자, 취소 사유가 일관되게 기록되지 않으면 대시보드를 만들어도 신뢰하기 어렵습니다.

화면 목록보다 사용자 유형을 먼저 정리해야 합니다

시스템개발업체에 전달할 요구사항을 만들 때는 메뉴 목록보다 시스템을 사용하는 사람을 먼저 구분하는 것이 좋습니다.

같은 사내 시스템이라도 다음과 같은 사용자가 있을 수 있습니다.

| 사용자 유형 | 주요 업무 | 필요한 기능 | |---|---|---| | 운영 관리자 | 전체 현황 관리, 담당자 배정, 정책 설정 | 전체 조회, 수정, 배정, 권한 관리 | | 업무 담당자 | 접수 건 검토 및 처리 | 담당 건 조회, 상태 변경, 메모 작성 | | 승인 담당자 | 금액·계약·예외 사항 승인 | 승인 대기 조회, 승인·반려, 사유 작성 | | 정산 담당자 | 결제 및 정산 확인 | 금액 조회, 정산 상태 변경, 자료 다운로드 | | 현장 사용자 | 처리 결과 입력, 사진·서류 등록 | 배정 업무 확인, 첨부파일 업로드 | | 고객·거래처 | 신청 및 진행 상황 확인 | 신청 등록, 내역 조회, 자료 제출 |

사용자 유형을 구분했다면 각 사용자가 어떤 순서로 업무를 처리하는지 연결해야 합니다.

예를 들어 기업의 서비스 신청 업무는 다음과 같이 정리할 수 있습니다.

``text 고객 신청 → 운영 담당자 접수 확인 → 담당자 배정 → 담당자 검토 → 추가 자료 요청 → 고객 자료 제출 → 승인 담당자 확인 → 결제 또는 계약 처리 → 업무 진행 → 완료 결과 등록 → 고객 확인 ``

이 흐름을 정리하면 필요한 화면도 자연스럽게 도출됩니다.

반대로 화면부터 정하면 고객 목록, 신청 목록, 상세 화면은 만들 수 있지만 추가 자료 요청이나 승인 반려, 담당자 재배정과 같은 실제 업무가 빠질 수 있습니다.

개발 상담 전 완성된 기획서를 만들 필요는 없습니다. 종이에 업무 흐름을 적거나 표로 정리하는 것만으로도 충분히 도움이 됩니다.

중요한 것은 정상적인 처리 과정만 적지 않는 것입니다.

신청 내용이 잘못되면 누가 수정하는가?
담당자가 퇴사하거나 휴가를 가면 누가 업무를 넘겨받는가?
승인자가 반려하면 어느 단계로 돌아가는가?
고객이 중간에 취소하면 이미 진행된 업무는 어떻게 처리하는가?
같은 요청이 두 번 접수되면 어떻게 구분하는가?
완료 처리 후 다시 수정할 수 있는가?

이러한 예외 상황이 실제 개발 범위와 운영 편의성에 큰 영향을 줍니다.

권한은 메뉴 접근보다 업무 행동을 기준으로 나눠야 합니다

많은 요구사항 문서에서 권한은 관리자와 일반 사용자 정도로만 구분됩니다.

하지만 실제 업무 시스템에서는 다음 행동을 각각 나누어야 할 수 있습니다.

조회
등록
수정
삭제
담당자 배정
상태 변경
승인
반려
파일 다운로드
개인정보 확인
엑셀 다운로드
통계 조회
설정 변경

예를 들어 상담 담당자와 정산 담당자가 같은 주문 상세 화면을 사용하더라도 볼 수 있는 정보와 처리할 수 있는 행동은 달라야 할 수 있습니다.

상담 담당자는 고객 연락처와 문의 내용을 확인해야 하지만 정산 금액을 변경할 필요는 없을 수 있습니다. 정산 담당자는 금액과 결제 상태를 확인해야 하지만 고객 상담 메모 전체를 볼 필요는 없을 수 있습니다.

권한을 정리할 때는 다음과 같은 표를 만들 수 있습니다.

| 기능 | 운영 관리자 | 담당자 | 승인자 | 정산 담당자 | |---|---:|---:|---:|---:| | 전체 건 조회 | 가능 | 제한 | 가능 | 제한 | | 담당 건 수정 | 가능 | 가능 | 제한 | 제한 | | 담당자 배정 | 가능 | 불가 | 불가 | 불가 | | 승인·반려 | 가능 | 불가 | 가능 | 불가 | | 결제 상태 확인 | 가능 | 제한 | 가능 | 가능 | | 정산 금액 수정 | 가능 | 불가 | 불가 | 가능 | | 전체 엑셀 다운로드 | 가능 | 제한 | 제한 | 가능 | | 사용자 권한 설정 | 가능 | 불가 | 불가 | 불가 |

권한 설계에서는 로그인 여부와 실제 행동 권한을 구분해야 합니다. 로그인에 성공한 사용자라고 해서 모든 데이터와 기능에 접근할 수 있는 것은 아닙니다. NIST의 역할 기반 접근 제어 개념과 OWASP 권한 설계 지침에서도 사용자의 역할과 업무에 필요한 권한을 기준으로 접근 범위를 제한하는 원칙을 다룹니다. (csrc.nist.gov)

특히 개인정보나 계약 자료, 결제·정산 자료를 다루는 시스템이라면 단순히 메뉴를 숨기는 방식으로 권한을 구현해서는 부족합니다.

사용자가 주소를 직접 입력하거나 API를 호출하더라도 권한이 없으면 데이터가 반환되지 않도록 서버에서도 확인해야 합니다.

승인 구조는 ‘승인 버튼’ 하나로 끝나지 않습니다

승인 기능이 필요하다고 하면 흔히 승인과 반려 버튼을 떠올립니다.

하지만 실제 개발에는 다음 기준이 필요합니다.

무엇을 승인하는가?
어느 상태에서 승인할 수 있는가?
누가 승인할 수 있는가?
금액이나 조건에 따라 승인자가 달라지는가?
한 명의 승인으로 끝나는가?
여러 명이 순서대로 승인해야 하는가?
반려하면 어느 단계로 돌아가는가?
반려 사유는 필수인가?
승인 후 내용을 수정할 수 있는가?
승인자가 부재중이면 위임할 수 있는가?
긴급 처리 권한이 필요한가?

예를 들어 일반적인 신청은 팀장 승인만 필요하지만 일정 금액을 초과하면 임원 승인이 추가될 수 있습니다. 이 경우 승인 화면 하나를 만드는 문제가 아니라 금액에 따라 승인 경로가 달라지는 업무 규칙을 구현해야 합니다.

1차 구축에서는 복잡한 전자결재 기능을 모두 만들기보다 승인자 한 명, 승인·반려, 사유 기록 정도로 시작하고 운영 결과에 따라 다단계 승인이나 위임 기능을 추가할 수도 있습니다.

상태값은 실제 업무 단계를 설명할 수 있어야 합니다

업무 시스템을 설계할 때 상태값은 화면 구성만큼 중요합니다.

상태값은 현재 상황을 보여주는 표시가 아니라, 사용자가 할 수 있는 행동과 다음 업무를 결정하는 기준으로 사용되기 때문입니다.

예를 들어 다음과 같은 상태를 생각해볼 수 있습니다.

``text 접수 → 담당자 배정 → 검토 중 → 추가 자료 요청 → 자료 확인 → 승인 대기 → 승인 완료 → 처리 중 → 완료 ``

별도로 다음 상태가 필요할 수도 있습니다.

반려
고객 취소
운영 취소
보류
재처리
오류
기간 만료

상태값을 정할 때는 상태 이름만 나열하지 말고 변경 조건과 변경 주체를 함께 정해야 합니다.

| 현재 상태 | 다음 상태 | 변경 주체 | 조건 | |---|---|---|---| | 접수 | 담당자 배정 | 운영 관리자 | 담당자 선택 | | 담당자 배정 | 검토 중 | 업무 담당자 | 업무 시작 | | 검토 중 | 추가 자료 요청 | 업무 담당자 | 필수 자료 부족 | | 추가 자료 요청 | 자료 확인 | 고객 또는 담당자 | 자료 제출 완료 | | 자료 확인 | 승인 대기 | 업무 담당자 | 검토 완료 | | 승인 대기 | 승인 완료 | 승인 담당자 | 승인 처리 | | 승인 대기 | 반려 | 승인 담당자 | 반려 사유 입력 | | 처리 중 | 완료 | 업무 담당자 | 결과 자료 등록 |

“진행 중”이라는 상태 하나에 검토, 승인 대기, 처리 중이 모두 섞이면 운영자는 각 건의 다음 업무를 알기 어렵습니다.

반대로 상태를 지나치게 세분화하면 사용자가 어떤 상태를 선택해야 하는지 혼란스러워질 수 있습니다. 시스템에서 관리할 상태는 보고서에 보기 좋은 이름이 아니라, 실제 업무 행동을 구분하는 수준으로 정하는 것이 좋습니다.

업무 상태와 결제 상태는 분리할 수 있습니다

결제가 포함된 시스템에서는 업무 상태와 결제 상태를 하나로 합치지 않는 편이 적합할 수 있습니다.

예를 들어 업무는 접수됐지만 결제는 대기 중일 수 있고, 결제는 완료됐지만 내부 승인은 아직 진행되지 않았을 수 있습니다.

``text 업무 상태: 접수 / 검토 / 승인 / 진행 / 완료 / 취소 결제 상태: 결제 대기 / 승인 / 실패 / 부분 취소 / 전체 취소 / 환불 ``

두 상태를 분리해 관리하면 결제는 완료됐지만 업무 처리가 시작되지 않은 건처럼 운영자가 확인해야 할 예외 상황도 찾기 쉬워집니다.

관리자 페이지는 목록 화면보다 운영 행동이 중요합니다

시스템 견적을 받을 때 관리자 페이지가 포함돼 있다는 문구만 확인해서는 실제 범위를 알기 어렵습니다.

관리자 페이지가 단순 조회 화면인지, 실제 업무를 처리할 수 있는 운영 시스템인지 구분해야 합니다.

검색과 필터

데이터가 많아지면 목록이 있다는 사실보다 원하는 데이터를 얼마나 빨리 찾을 수 있는지가 중요해집니다.

다음 조건을 검색할 수 있는지 확인해볼 수 있습니다.

접수 기간
완료 예정일
고객명과 연락처
담당자
업무 상태
승인 상태
결제 상태
거래처
상품 또는 서비스 유형
미처리 여부
지연 여부
첨부파일 유무

운영팀이 자주 확인하는 조건이 있다면 여러 필터를 조합하거나 자주 사용하는 검색 조건을 저장하는 기능도 검토할 수 있습니다.

일괄 처리

운영자가 여러 건을 하나씩 열어 같은 작업을 반복한다면 일괄 처리 기능이 필요할 수 있습니다.

담당자 일괄 배정
상태 일괄 변경
선택 데이터 다운로드
알림 일괄 발송
태그 일괄 등록
자료 일괄 업로드
정산 대상 일괄 확정

다만 모든 항목을 일괄 변경할 수 있게 하면 실수의 영향도 커집니다. 일괄 처리 전에 대상 건수와 변경 내용을 다시 확인하게 하거나, 특정 상태에서만 실행할 수 있도록 제한할 수 있습니다.

내부 메모와 고객 공개 내용을 구분해야 합니다

메모 기능이 필요한 경우에도 누가 볼 수 있는지를 구분해야 합니다.

운영팀 전체가 보는 메모
담당자만 보는 개인 메모
승인자가 확인할 검토 의견
고객에게 전달되는 안내 내용
변경할 수 없는 처리 기록

내부 메모가 고객 화면에 노출되거나, 고객 안내 내용이 내부 기록에만 남는 문제가 발생하지 않도록 작성 목적과 공개 범위를 명확히 해야 합니다.

첨부파일

첨부파일 기능은 업로드 버튼만 추가하는 작업으로 끝나지 않을 수 있습니다.

업로드 가능한 파일 형식
최대 용량
여러 파일 등록 여부
파일 삭제 권한
파일 교체와 버전 관리
사용자별 다운로드 권한
업무 상태별 업로드 가능 여부
보관 기간
미리보기 필요 여부

계약서나 증빙 자료를 관리한다면 단순 삭제 대신 비활성화하거나 교체 이력을 남겨야 할 수도 있습니다.

변경 이력

여러 명이 데이터를 수정하는 시스템에서는 현재 값만 저장하면 문제가 생겼을 때 원인을 확인하기 어렵습니다.

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

변경한 사용자
변경 일시
변경 항목
변경 전 값
변경 후 값
변경 사유
승인 또는 반려 기록
파일 등록·삭제 기록

OWASP는 적절한 애플리케이션 로그가 보안 문제 조사뿐 아니라 접근 제어 문제의 확인과 감사에도 활용될 수 있다고 설명합니다. 다만 모든 개인정보와 내용을 무조건 기록하기보다 업무와 보안 목적에 필요한 범위를 정하고, 민감한 정보가 로그에 불필요하게 남지 않도록 설계해야 합니다. (cheatsheetseries.owasp.org)

기존 엑셀 데이터는 그대로 옮기기 전에 먼저 정리해야 합니다

기존 엑셀 파일을 웹 시스템으로 이전할 때는 단순히 행과 열을 데이터베이스에 넣는 것보다 먼저 데이터의 의미와 품질을 확인해야 합니다.

실제 파일에는 다음과 같은 문제가 섞여 있을 수 있습니다.

같은 고객이 다른 이름으로 여러 번 등록되어 있다.
전화번호 형식이 서로 다르다.
날짜가 문자열과 날짜 형식으로 섞여 있다.
빈칸이 미입력인지 해당 없음인지 구분되지 않는다.
완료, 처리 완료, 종결처럼 같은 상태가 여러 표현으로 존재한다.
퇴사한 담당자 이름이 그대로 남아 있다.
한 셀에 여러 정보가 함께 입력되어 있다.
메모에 중요한 업무 정보가 포함되어 있다.
파일마다 열 이름과 순서가 다르다.

개발 상담 전에는 다음 항목을 정리하는 것이 좋습니다.

현재 사용 중인 엑셀 파일 목록
파일별 관리 담당자
각 열의 의미
반드시 이전해야 하는 데이터
과거 이력으로만 보관할 데이터
중복 판단 기준
상태값 변환 기준
개인정보와 첨부파일의 보관 기준

모든 과거 데이터를 신규 시스템의 운영 데이터로 옮길 필요는 없습니다.

최근 몇 년의 데이터만 신규 시스템으로 이전하고, 이전 데이터는 별도 조회용 파일이나 보관 데이터로 남기는 방법도 있습니다. 데이터 양보다 실제 조회 필요성과 업무 연결성을 기준으로 결정하는 것이 좋습니다.

데이터 이전 후에는 원본과 대상 데이터의 건수만 비교해서는 부족할 수 있습니다. 주요 식별자, 필수값, 상태별 건수, 금액 합계, 중복 여부 등 검증 규칙을 정해야 합니다. AWS의 데이터 이전 지침에서도 원본과 대상 데이터의 비교, 검증 규칙, 백업, 전환 후 확인과 롤백 계획을 이전 과정의 주요 요소로 다룹니다. (docs.aws.amazon.com)

외부 API·ERP 연동은 정상 연결보다 운영 기준을 확인해야 합니다

신규 업무 시스템이 회계, ERP, 그룹웨어, 결제, 배송, 문자, 이메일과 연결되어야 할 수도 있습니다.

이때는 “연동 가능”이라는 답변만으로 범위를 판단하기 어렵습니다.

다음 질문에 답할 수 있어야 합니다.

어느 시스템의 데이터가 원본인가?
어떤 데이터를 주고받는가?
실시간으로 연동해야 하는가?
일정 시간마다 일괄 동기화해도 되는가?
같은 데이터가 두 번 전송되면 어떻게 처리하는가?
외부 시스템이 응답하지 않으면 재시도하는가?
일부 데이터만 성공하면 어떻게 표시하는가?
실패 건을 운영자가 다시 처리할 수 있는가?
연동 이력을 어디에서 확인하는가?
외부 API 사용 계약과 계정은 누가 준비하는가?

예를 들어 신규 시스템에서 고객 정보를 수정했을 때 ERP에도 반영해야 한다면 양쪽 시스템 중 어느 쪽을 최종 기준으로 삼을지 정해야 합니다.

양쪽에서 모두 수정할 수 있도록 만들면 충돌이 발생했을 때 어떤 값을 유지할지 추가 규칙이 필요합니다. 초기에는 한쪽을 기준 시스템으로 정하고 다른 시스템은 조회하거나 전달받는 구조로 제한하는 편이 관리하기 쉬울 수 있습니다.

시스템개발업체 견적서에서 확인할 개발 범위

업체별 총견적을 비교하기 전에 포함 항목을 같은 기준으로 맞춰야 합니다.

기획

현재 업무 분석이 포함되는가?
사용자 유형과 권한을 정리하는가?
업무 흐름과 상태값을 설계하는가?
화면 기획서 또는 기능 정의서가 제공되는가?
예외 상황과 운영 정책을 어디까지 정리하는가?

UX/UI 디자인

사용자용 화면과 관리자 화면이 모두 포함되는가?
모바일과 태블릿 대응 범위는 어디까지인가?
디자인 시안과 수정 횟수는 어떻게 되는가?
기존 디자인 가이드가 있다면 반영 가능한가?

프론트엔드

사용자가 보는 웹 화면이 포함되는가?
관리자 페이지가 별도 개발 범위에 포함되는가?
반응형 웹이 필요한가?
지원 브라우저 범위는 어디까지인가?

백엔드와 데이터베이스

로그인과 인증 방식이 포함되는가?
역할별 권한이 서버에도 적용되는가?
데이터 구조와 상태 변경 규칙이 구현되는가?
변경 이력과 로그 범위는 어디까지인가?
첨부파일 저장과 접근 권한이 포함되는가?

관리자 시스템

목록 조회만 포함되는가?
검색과 복합 필터가 포함되는가?
일괄 처리 기능이 포함되는가?
엑셀 업로드와 다운로드가 포함되는가?
권한 설정, 이력 조회, 통계가 포함되는가?

데이터 이전과 외부 연동

기존 엑셀 분석이 포함되는가?
데이터 정제는 누가 담당하는가?
이전 후 검증 범위는 어디까지인가?
외부 API 연동 개발이 포함되는가?
외부 서비스의 이용료는 별도인가?
연동 실패 이력과 재처리 기능이 포함되는가?

테스트와 배포

기능 테스트 범위는 어디까지인가?
사용자별 권한 테스트가 포함되는가?
데이터 이전 테스트가 진행되는가?
실제 서버 배포가 포함되는가?
운영 전 사용자 검수 기간이 있는가?
기존 업무에서 신규 시스템으로 전환하는 계획이 포함되는가?

인수인계와 유지보수

소스코드와 기술 문서를 전달받을 수 있는가?
서버와 외부 서비스 계정은 누구 명의로 개설하는가?
하자 수정과 유지보수는 어떻게 구분하는가?
운영 중 문의 대응 절차는 어떻게 되는가?
기능 추가가 필요할 때 산정 방식은 무엇인가?

같은 금액처럼 보여도 한 업체는 관리자 시스템과 데이터 이전을 포함하고, 다른 업체는 사용자 화면만 포함할 수 있습니다.

따라서 총액보다 기능별 포함·제외 항목과 완료 기준을 확인해야 합니다.

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

모든 기능을 처음부터 개발하려 하면 일정과 범위가 커질 뿐 아니라, 실제 운영 후 필요하지 않은 기능이 될 수도 있습니다.

1차 구축 범위는 시스템이 실제 업무를 처음부터 끝까지 처리할 수 있는 최소 단위를 기준으로 정하는 것이 좋습니다.

1차 구축에 포함할 수 있는 기능

사용자 로그인
역할별 기본 권한
핵심 업무 등록과 조회
담당자 배정
필수 상태 변경
승인과 반려
내부 메모
필수 첨부파일
검색과 기본 필터
주요 데이터 엑셀 다운로드
핵심 알림
기존 필수 데이터 이전
운영에 필요한 기본 변경 이력

운영 후 확장할 수 있는 기능

복잡한 다단계 승인
고급 통계와 대시보드
사용자별 맞춤 화면
반복 업무 자동 배정
조건별 자동 알림
모바일 앱
여러 외부 시스템과의 양방향 연동
고급 엑셀 업로드
문서 OCR
AI 기반 분류와 요약
세부적인 보고서 자동 생성

다만 관리자 기능을 모두 추후 기능으로 미루는 것은 주의해야 합니다.

사용자 화면에서 신청은 가능하지만 운영자가 신청 내용을 찾고 상태를 변경할 방법이 없다면 실제 서비스는 운영하기 어렵습니다. 초기 시스템이라도 접수 확인, 담당자 배정, 상태 변경, 메모, 검색과 같은 핵심 운영 기능은 포함하는 편이 좋습니다.

실제 업무 흐름을 시스템으로 전환한 사례

원소프트가 개발에 참여한 바토너는 부동산 경매 업무를 하나의 흐름으로 연결한 업무형 플랫폼입니다.

경매 물건을 확인하고 입찰을 신청한 뒤 계약 문서 처리, 결제, 포인트, 정산으로 이어지는 과정을 상태 기반 업무 흐름으로 구성했습니다.

일반 회원, 전문가, 운영자처럼 사용자 유형을 구분하고 역할에 따라 접근할 수 있는 기능과 처리 범위를 나눴습니다. 운영자는 회원, 입찰, 결제, 정산, 문의 데이터를 관리자 기능에서 관리할 수 있도록 구성했습니다.

문서 정보를 반복해서 입력해야 하는 업무에는 OCR을 연동하고, 서비스 진행 상황을 전달할 수 있도록 푸시 알림과 문의 답변 이력도 함께 관리했습니다.

이 사례에서 중요한 부분은 화면을 많이 만드는 것이 아니라 다음 요소를 연결한 것입니다.

사용자 유형과 역할
입찰부터 계약·정산까지 이어지는 업무 상태
결제와 포인트 변동 이력
OCR을 활용한 문서 입력 보조
공지·알림·문의 답변
운영자가 데이터를 확인하고 처리하는 관리자 기능

엑셀과 메신저로 처리하던 업무를 웹 시스템으로 전환할 때도 같은 관점이 필요합니다. 기존 문서를 그대로 화면으로 옮기기보다 업무 단계와 데이터의 관계를 먼저 정리해야 합니다.

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

완성된 요구사항 정의서가 없어도 다음 자료를 준비하면 상담의 정확도를 높일 수 있습니다.

1. 현재 사용하는 자료

엑셀 양식
신청서와 계약서
보고서
업무 매뉴얼
메신저로 전달하는 안내문
이메일 템플릿
현재 사용 중인 프로그램 화면

실제 고객 정보와 개인정보는 제거하거나 예시 데이터로 변경해 전달하는 것이 좋습니다.

2. 사용자 목록

시스템을 사용하는 부서
사용자 유형
사용자 유형별 인원
외부 고객이나 거래처의 사용 여부
각 사용자가 처리하는 업무

3. 핵심 업무 흐름

다음처럼 한 줄로 작성해도 좋습니다.

``text 고객 접수 → 담당자 배정 → 검토 → 승인 → 결제 → 처리 → 완료 ``

각 단계에서 담당자와 입력 정보, 다음 단계로 넘어가는 조건을 함께 적으면 더 구체적인 상담이 가능합니다.

4. 현재 불편한 점

기능 목록보다 현재 발생하는 문제를 전달하는 것이 도움이 됩니다.

담당자가 바뀌면 이전 업무를 찾기 어렵다.
승인 여부를 메신저에서 다시 확인해야 한다.
월말에 여러 파일을 합쳐야 한다.
처리 지연 건을 매일 사람이 확인한다.
같은 고객 정보가 여러 파일에 중복된다.
외부 시스템에 같은 내용을 다시 입력한다.

5. 반드시 필요한 기능과 추후 기능

필수, 검토, 추후 세 단계로 나눌 수 있습니다.

| 구분 | 의미 | |---|---| | 필수 | 없으면 핵심 업무를 처리할 수 없는 기능 | | 검토 | 운영 편의에는 도움이 되지만 대체 방법이 있는 기능 | | 추후 | 실제 운영 데이터를 확인한 뒤 추가해도 되는 기능 |

6. 전환 조건

언제부터 신규 시스템을 사용해야 하는가?
기존 엑셀과 일정 기간 병행해야 하는가?
업무를 중단할 수 있는 시간이 있는가?
기존 데이터를 어느 범위까지 이전해야 하는가?
전환 후 문제가 발생하면 기존 방식으로 돌아갈 수 있는가?

신규 시스템 전환은 개발 완료 버튼을 누르는 순간 끝나는 작업이 아닙니다. 사용자 교육, 기존 데이터 확정, 최종 이전, 권한 등록, 운영 검수와 비상 대응 방안도 함께 준비해야 합니다.

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

상담 과정에서는 다음 질문을 활용할 수 있습니다.

현재 업무 흐름을 어떤 방식으로 분석하고 정리하나요?
사용자 유형과 권한은 어느 단계에서 확정하나요?
승인과 상태 변경 규칙은 산출물에 어떻게 표시되나요?
관리자 페이지에는 어떤 운영 기능이 포함되나요?
변경 이력과 작업 기록은 어느 범위까지 남길 수 있나요?
기존 엑셀 데이터 분석과 이전은 견적에 포함되나요?
데이터 정제와 중복 제거는 누가 담당하나요?
외부 API나 ERP 연동이 실패하면 어떻게 확인하고 재처리하나요?
사용자 검수와 권한 테스트는 어떤 방식으로 진행하나요?
운영 전환과 배포는 누가 담당하나요?
소스코드, 서버, 도메인, 외부 서비스 계정은 어떻게 인계되나요?
하자 수정과 유지보수, 추가 개발의 기준은 어떻게 구분하나요?

좋은 상담은 요청받은 화면 수를 계산하는 데서 끝나지 않습니다.

현재 업무가 왜 불편한지, 어떤 데이터가 반복되고 있는지, 담당자별 책임과 권한은 어떻게 다른지, 예외 상황에서 누가 무엇을 해야 하는지 질문하는 과정이 필요합니다.

웹 시스템 전환의 기준은 화면이 아니라 업무 연결입니다

엑셀과 메신저를 웹 시스템으로 바꾸는 목적은 기존 문서를 온라인 화면으로 옮기는 것이 아닙니다.

업무가 접수된 시점부터 담당자 배정, 검토, 승인, 처리, 완료까지 하나의 흐름으로 연결되고, 각 단계에서 필요한 데이터와 책임자가 명확해져야 합니다.

이를 위해서는 다음 항목을 먼저 정리해야 합니다.

시스템을 사용하는 사람
사용자별 조회·등록·수정·승인 권한
실제 업무 처리 순서
상태값과 변경 조건
관리자 검색·필터·일괄 처리 기능
메모·첨부파일·변경 이력
기존 엑셀 데이터의 이전 범위
ERP와 외부 API 연동 기준
테스트·배포·인수인계·유지보수 범위
1차 구축과 추후 확장 기능

원소프트는 웹·앱·AI 및 관리자 시스템을 개발하며, 사용자 화면뿐 아니라 실제 운영자의 업무 흐름과 데이터 구조를 함께 검토합니다.

현재 사용하는 엑셀이나 업무 양식이 있다면 처음부터 완성된 기획 문서를 준비하지 않아도 됩니다. 현재 처리 순서와 반복 업무, 담당자별 역할을 바탕으로 필요한 시스템 범위와 단계별 구축 방향을 정리할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치하고 있습니다. 동탄·화성뿐 아니라 수원, 용인, 기흥, 오산 등 경기 남부 지역에서 업무 시스템 개발을 검토하고 있다면 현재 운영 방식과 필요한 기능을 기준으로 상담을 진행할 수 있습니다.

제목 후보

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

메인 키워드

시스템개발업체

서브 키워드

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

썸네일 문구

엑셀 업무, 언제 시스템으로 바꿔야 할까?
시스템 견적은 화면 수로 비교하면 안 됩니다
업무 흐름부터 정리하는 시스템 개발

글 요약

엑셀과 메신저 업무를 웹 시스템으로 전환할 때는 기존 화면이나 문서 양식을 그대로 옮기기보다 사용자 유형, 권한, 승인 절차, 상태값과 관리자 운영 기능을 먼저 정리해야 합니다. 기존 데이터 이전과 외부 시스템 연동, 테스트·배포·인수인계 범위까지 같은 기준으로 확인해야 시스템개발업체의 견적을 현실적으로 비교할 수 있습니다.

CTA 후보

현재 사용 중인 엑셀 양식과 실제 업무 처리 순서가 있다면 이를 기준으로 필요한 사용자 기능, 관리자 기능과 1차 구축 범위를 함께 정리해볼 수 있습니다.

사내 업무를 웹 시스템으로 전환해야 할지 고민하고 있다면 반복 입력, 승인 절차, 담당자별 권한과 데이터 이전 범위부터 검토해보시기 바랍니다. 원소프트가 현재 운영 방식에 맞춰 개발 범위를 구체화하는 과정을 도와드릴 수 있습니다.

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

사내 시스템 개발, 전면 구축과 단계적 업무 전환을 결정하는 기준
엑셀 데이터 이전, 신규 웹 시스템 구축 전에 정리해야 할 항목
업무 시스템 권한 설계, 부서·담당자별 조회와 승인 범위를 나누는 방법