| 구분 | 내용 |
|---|---|
| 문서 목적 | 웹 데모 URL에서 바로 내려받아 발주자와 범위·일정·검증 기준을 합의하기 위한 상세 기획서 |
| 대상 시스템 | Windows XP ~ Windows 11, 32/64bit 운용을 고려한 중요 폴더 자동 백업 프로그램 |
| 데모 전제 | 현재 URL은 실제 업무 폴더나 Windows 설정을 수정하지 않는 수주용 UI/운영 흐름 시연 |
| 계약 전 원칙 | 실제 registry, Task Scheduler, 시작 프로그램, 업무 폴더 삭제·백업은 수행하지 않고 fixture 기반 POC만 진행 |
| 이번 통합본 | 기존 본문 1~16은 유지하고, 검수 기준·제외 범위·위험 대응·발주자 준비자료·유지보수 범위를 부록으로 추가 |
아래 표는 검수·미팅 때 자주 확인되는 기술 항목의 역할과 적용 이유입니다. 기능 범위는 본문과 동일합니다.
| 항목 | 설명 | 왜 필요한가 |
|---|---|---|
| fixture POC | 실제 업무 파일이 아닌 샘플 폴더·샘플 파일로 먼저 해보는 안전 테스트 | 계약 전 실데이터 손상 위험 없이 기능 가능성을 확인하기 위해 필요 |
| Registry | Windows 내부 설정 저장소 | 시작 실행, 프로그램 설정 위치 등을 다룰 때 영향 범위를 통제해야 함 |
| Task Scheduler | Windows 예약 실행 도구 | 정해진 날짜·시간에 백업이 자동으로 실행되게 하는 후보 수단 |
| System Tray / Tray | Windows 오른쪽 아래 시계 근처에 떠 있는 작은 프로그램 아이콘 | 백업 프로그램이 계속 대기 중임을 보여주고 빠른 실행을 제공 |
| Mutex | 같은 프로그램이 두 번 켜지는 것을 막는 잠금 장치 | 동시에 두 번 백업되어 파일 충돌이 나는 상황을 방지 |
| KeepCount | 남겨둘 백업 개수 | 예: 3이면 최근 3회 백업만 보관하고 오래된 것은 정리 후보가 됨 |
| chunk / 청크 | 큰 파일을 작은 조각으로 나눠 복사하는 방식 | 대용량 파일 복사 중 멈춤·재시도·진행률 표시를 안정화 |
| checksum | 복사 전후 파일이 같은지 확인하는 검산값 | 복사된 파일이 깨지지 않았는지 확인하는 근거 |
| skip/retry | 문제 파일은 건너뛰거나 다시 시도하는 처리 | 일부 파일 오류 때문에 전체 백업이 망가지지 않게 함 |
| dry-run | 실제 변경 없이 “이렇게 처리될 예정”만 미리 확인하는 실행 | Registry, 삭제, 예약 등록 같은 위험 작업을 안전하게 검토 |
| rollback | 문제가 생겼을 때 이전 상태로 되돌리는 절차 | 삭제·설정 변경 전 복구 가능성을 확보 |
| EXE / 인스톨러 | EXE는 실행 파일, 인스톨러는 설치 프로그램 | 배포 방식과 시작 실행, 삭제, 업데이트 방식에 영향 |
성공 기준은 “정상 백업 1회”가 아니라, 정상·누락·부분 실패·중지·보관정책·로그 확인까지 반복 가능한 운영 흐름이 증거로 남는 것입니다.
| 요구 항목 | 기획 반영 | 검증 방식 |
|---|---|---|
| 최대 5개 폴더 | 폴더별 이름, 원본 경로, 대상 드라이브, 스케줄, KeepCount, 활성 상태를 분리 관리 | fixture 폴더 5개 등록 후 스케줄·결과 로그 비교 |
| 연간 고정 스케줄 | 월/일/시간 기준 연간 캘린더를 설정하고 다음 실행 예정 시간을 계산 | 샘플 연간 스케줄 12개월 케이스로 missed 여부 검증 |
| 놓친 백업 재시도 | 마지막 성공 시간과 현재 시각을 비교해 누락 건을 pending 상태로 표시 | PC 미실행 기간 fixture를 입력해 재시도 큐 생성 확인 |
| 수동·전체 백업 | 개별 폴더 수동 백업과 전체 폴더 일괄 백업 버튼 분리 | 작업 큐 순서와 취소 가능 상태 확인 |
| 백업 중 정지 | 현재 파일 복사 완료 후 안전 중지 또는 즉시 중지 정책 선택 | 중지 요청 시 로그와 상태가 남는지 확인 |
| KeepCount 1~5 | 원본폴더명/yyyyMMdd 단위로 보관 개수를 초과한 백업을 정리 후보로 계산 | 삭제 전 후보 목록·rollback 근거 생성 |
| 청크 복사 | 대용량 파일은 chunk index, checksum, skip/retry 상태를 남김 | 대용량 fixture로 진행률·재시도 로그 확인 |
| 부분 실패 경고 | 잠긴 파일, 권한 오류, 경로 금지문자, 용량 부족을 분리 표시 | 오류 fixture로 backup.log와 화면 경고 비교 |
| Windows 연동 | Tray, Mutex, 시작 실행, registry, Task Scheduler를 계약 후 통제 적용 | 계약 전에는 dry-run/fixture 증거만 생성 |
| 순서 | 사용자 행동 | 프로그램 반응 | 증거 |
|---|---|---|---|
| 1 | 중요 폴더 등록 | 원본 경로·대상 드라이브·보관 개수·스케줄을 검증하고 저장 | config.ini, 설정 백업 |
| 2 | 연간 백업 스케줄 설정 | 다음 실행 예정일과 missed 기준을 계산 | schedule preview |
| 3 | PC 재실행 또는 장시간 미사용 | 놓친 백업을 pending으로 표시하고 재시도 대기 | missed queue |
| 4 | 수동 백업 실행 | 폴더별 작업 큐를 만들고 진행률·현재 파일·남은 용량을 표시 | backup.log |
| 5 | 부분 실패 발생 | 전체 백업은 종료하지 않고 실패 파일과 원인을 분리 표시 | warning summary |
| 6 | KeepCount 정리 | 삭제 후보를 계산하고 기준 초과분을 정리 | retention log |
| 7 | 오류 또는 크래시 | crash.log와 재현 가능한 작업 상태를 남김 | crash.log |
기본 백업 경로는 드라이브:\ABM_Backup\장치명\원본폴더명\yyyyMMdd\ 구조를 기준으로 합니다. 동일 날짜에 중복 실행될 수 있으므로 실제 구현 단계에서는 동일 날짜 재실행 정책을 덮어쓰기 금지, 회차 suffix, 변경분만 복사 중 하나로 합의해야 합니다.
| 정책 | 권장값 | 이유 |
|---|---|---|
| 날짜 폴더 | yyyyMMdd | 연간 스케줄과 보관 개수 계산이 단순하고 사용자 확인이 쉽습니다. |
| 중복 실행 | yyyyMMdd_HHmm 회차 suffix 후보 | 같은 날짜 수동 재실행 시 이전 백업을 덮지 않습니다. |
| KeepCount | 1~5 | 공고 요구와 일치하며 저장 공간 예측이 쉽습니다. |
| 삭제 방식 | 후보 계산 -> 로그 기록 -> 삭제 | rollback 없는 삭제를 방지하고 사용자 확인 근거를 남깁니다. |
| 상황 | 처리 정책 | 사용자 표시 |
|---|---|---|
| 대용량 파일 | 청크 단위 복사, checksum, skip/retry 기록 | 현재 파일명, 청크 진행률, 남은 예상 시간 |
| 잠긴 파일 | 해당 파일 실패로 기록하고 다음 파일 진행 | 부분 실패 경고와 파일 목록 |
| 권한 오류 | 관리자 권한 필요 여부 안내 | 권한 오류 코드와 조치 안내 |
| 용량 부족 | 대상 드라이브 여유 공간 사전검사 | 부족 용량과 대상 경로 표시 |
| 금지 특수문자 | 등록 단계에서 차단 | 입력 필드 즉시 경고 |
| 연동 항목 | 역할 | 계약 전 처리 |
|---|---|---|
| System Tray | 상주 상태, 빠른 실행, 종료, 로그 열기 | 웹 데모에서는 화면 흐름만 표시 |
| Mutex | 중복 실행 방지 | fixture에서 중복 실행 감지 시나리오만 검증 |
| Registry | 시작 실행, 설정 위치 후보 | 실제 수정 금지, dry-run 산출물만 생성 |
| Task Scheduler | 스케줄 실행 안정성 보강 | 실제 등록 금지, 명령 생성 검증만 수행 |
| 관리자 권한 | 권한 필요한 작업 분리 | 권한 요구 화면만 시연 |
| 후보 | 장점 | 주의점 |
|---|---|---|
| C# .NET Framework 4.0 / WinForms | Windows UI 생산성, 유지보수성, 로그·설정 처리 용이 | XP 호환성 검증과 배포 환경 확인 필요 |
| Delphi 6.0 | 레거시 Windows 호환성에 강점, 단일 EXE 구성 가능 | 개발·유지보수 인력과 라이브러리 제약 확인 필요 |
| 인스톨러 포함 | 시작 실행·권한·바로가기 구성에 유리 | 계약 전 실제 설치·등록은 금지하고 테스트 VM에서 검증 필요 |
| 구분 | 검증 항목 | PASS 기준 |
|---|---|---|
| 기능 | 5개 폴더 등록, 수동 백업, 전체 백업, 중지 | 각 기능별 로그와 상태가 일관됨 |
| 스케줄 | 연간 스케줄, 누락 감지, 재시도 큐 | 예정·누락·완료 상태가 정확히 계산됨 |
| 보관 | KeepCount 1~5, 오래된 백업 후보 | 삭제 후보가 기준과 일치하고 로그가 남음 |
| 대용량 | 청크 복사, checksum, skip/retry | 부분 실패에도 전체 작업 상태가 보존됨 |
| Windows | Tray, Mutex, 시작 실행, Task Scheduler | 테스트 VM에서 실제 동작 검증 증거 확보 |
| 배포 | 단일 EXE 또는 인스톨러, 실행 권한 | 대상 OS별 실행 및 제거 확인 |
| 기간 | 목표 | 주요 산출물 |
|---|---|---|
| 1~2주 | 요구사항 확정, fixture POC 설계 | 요구사항 확정표, 테스트 fixture, 화면 흐름 |
| 3~4주 | 백업 엔진 기본 구현 | 폴더 등록, 수동/전체 백업, config.ini, backup.log |
| 5~6주 | 스케줄·재시도·보관 정책 구현 | 연간 스케줄, missed retry, KeepCount 정리 |
| 7~8주 | Windows 연동 구현 | Tray, Mutex, 시작 실행, Task Scheduler/Registry 정책 |
| 9~10주 | 대용량·부분 실패·예외 처리 | 청크 복사, checksum, crash.log, 권한 오류 처리 |
| 11~12주 | 통합 테스트·패키징·납품 준비 | 테스트 리포트, 단일 EXE/인스톨러, 운영 가이드 |
| 13주 | 검수 대응·보정 | 검수 이슈 반영, 최종 evidence, 인수인계 |
| 질문 | 확인이 필요한 이유 |
|---|---|
| 동일 날짜에 여러 번 백업하면 덮어쓸지, 회차 폴더를 만들지? | 데이터 보존 정책과 저장 공간 계산에 영향 |
| 놓친 백업이 여러 건이면 모두 실행할지, 최신 1건만 실행할지? | 실행 시간과 사용자 체감에 영향 |
| 대상 드라이브가 없거나 용량이 부족할 때 자동으로 대기할지? | 오류 처리와 재시도 정책에 영향 |
| XP 호환성이 필수인지, 일부 구형 OS는 별도 빌드로 둘지? | 기술 스택과 테스트 범위에 영향 |
| 관리자 권한 실행을 기본으로 할지, 필요 시에만 요청할지? | 보안 정책과 사용자 경험에 영향 |
| 설치형 인스톨러가 필요한지, 단일 EXE만 필요한지? | 배포·업데이트·시작 실행 방식에 영향 |
계약 전 POC는 안전한 샘플 폴더와 테스트 파일만 사용합니다. 실제 업무 폴더, registry, Task Scheduler, Windows 시작 프로그램을 직접 수정하지 않습니다. POC의 목적은 기능 구현 완료가 아니라 위험한 운영 조건을 미리 식별하고 본 개발 범위를 확정하는 것입니다.
본 기획서는 데모 URL과 함께 발주자에게 “무엇을 실제로 만들 것인지, 어떤 항목은 계약 전 안전 검증에 머물러야 하는지, 최종 납품 기준을 무엇으로 볼 것인지”를 명확히 전달하기 위한 문서입니다. 다음 단계는 PDF 다운로드 버튼이 포함된 URL 재배포 후 readback evidence를 확보하고, 이후 엔진 데모자동화루프에 JSON finalize guard와 PDF 산출물 검사를 흡수하는 것입니다.
이 부록은 발주자가 “무엇을 완료로 볼지”와 “계약 전에는 무엇을 하지 않는지”를 빠르게 확인하기 위한 기준표입니다.
본 프로젝트의 검수는 “백업 기능이 실제 Windows 환경에서 안정적으로 반복 동작하는지”를 기준으로 진행합니다. 단순 화면 구현이 아니라, 지정된 폴더·스케줄·보관 정책·로그·오류 대응이 실제로 확인되어야 합니다.
계약 전에는 실제 업무 폴더, 실제 고객 데이터, 실제 Registry, 실제 Task Scheduler, 실제 Windows 시작 프로그램을 직접 수정하지 않습니다.
계약 전 검증은 샘플 폴더와 테스트 파일을 사용하는 fixture 기반 POC로 제한합니다. 이 단계에서는 실제 백업 프로그램 납품 완료로 보지 않으며, 기능 가능성과 구현 방향을 확인하는 범위로 진행합니다.
계약 전에는 다음 작업을 진행하지 않습니다.
해당 작업은 계약 후 테스트 환경, 백업 정책, 복구 기준, 권한 범위가 확정된 뒤 단계적으로 진행합니다.
| 위험요소 | 영향 | 대응 방향 |
|---|---|---|
| OS 호환성 | Windows 버전마다 동작 방식이 달라질 수 있음 | XP~Win11 범위를 실제 테스트 가능한 환경 기준으로 나누어 확인 |
| 권한 문제 | 일부 폴더는 관리자 권한 없이는 접근 불가 | 관리자 권한 필요 여부와 일반 권한 범위를 분리 |
| 대용량 파일 | 큰 파일은 복사 중 멈춤·지연·부분 실패 가능 | 청크 복사, 재시도, 진행률, 실패 파일 기록 적용 |
| 저장 공간 부족 | 백업 드라이브 용량이 부족하면 작업 실패 | 시작 전 예상 용량과 남은 용량을 확인 |
| 부분 실패 | 일부 파일만 실패해도 사용자가 원인을 알아야 함 | 성공/실패 파일 분리 기록과 재시도 안내 제공 |
| 로그 추적성 | 문제 발생 원인을 나중에 확인해야 함 | backup.log, crash.log, 설정 백업을 분리 관리 |
정확한 개발 범위 산정을 위해 발주자는 다음 자료를 제공해야 합니다.
또한 실제 운영 PC에서 테스트하기 전, 샘플 폴더와 샘플 파일을 기반으로 한 검증 환경을 먼저 구성하는 것이 안전합니다.
납품 후 유지보수는 오류 수정, 로그 분석, 백업 실패 원인 확인, OS 업데이트에 따른 경미한 호환성 조정, 설정값 변경 지원을 중심으로 진행할 수 있습니다.
단, 새로운 백업 정책 추가, 네트워크 백업 확장, 클라우드 연동, 중앙 관리 서버, 다중 사용자 권한 관리, 암호화 백업, 원격 모니터링 기능은 별도 범위로 분리하는 것이 적절합니다.
유지보수 범위는 계약 단계에서 기간, 응답 시간, 수정 범위, 추가 개발 기준을 명확히 정하는 것을 권장합니다.
| 구분 | 요약 |
|---|---|
| 검수 기준 | 5개 폴더, 스케줄, 재시도, 중지, KeepCount, 로그, Windows 연동을 실제 테스트 증거로 확인 |
| 계약 전 제외 | 실데이터, Registry, Task Scheduler, 시작 프로그램, 운영 환경 배포는 직접 수정하지 않음 |
| 위험 대응 | OS 호환성, 권한, 대용량, 용량 부족, 부분 실패를 각각 분리해 검증 |
| 발주자 준비 | 샘플 폴더, 스케줄 규칙, 테스트 OS, 권한 정책, 설치 방식, 로그 보관 기준 필요 |
| 유지보수 | 오류 수정과 로그 분석 중심. 기능 확장은 별도 범위 |