일정표에는 날짜뿐 아니라 통과 조건이 필요합니다
전체 일정은 기능 규모, 외부 연동, 자료 준비와 확인 과정에 따라 달라집니다. 먼저 종료 날짜만 정하기보다 각 단계에서 어떤 자료와 승인이 있어야 다음 단계로 넘어갈 수 있는지 합의하세요. 외부 계정이나 시험 환경이 늦게 준비되는 경우의 영향도 일정에 반영해야 합니다.
- 범위 확인: 사용자, 화면, 연동과 운영 환경을 정리하고 미정 항목의 확인 담당자를 정합니다.
- 동작 설계: 주요 화면과 상태 변화, 권한, 오류 안내를 검토합니다.
- 구현과 연결: 기능을 만들고 허가된 환경에서 외부 인터페이스를 확인합니다.
- 검수와 수정: 합의한 사례를 실행하고 결과·결함·재확인 내용을 기록합니다.
- 이전과 인수: 자료와 계정을 확인하고 운영 담당자가 필요한 절차를 수행합니다.
- 운영 전환: 변경 이력, 문의 경로와 남은 제한을 전달받아 운영에 반영합니다.
이 순서는 계약마다 조정할 수 있는 검토 틀입니다. 모든 작업이 순차적으로 끝난다는 뜻은 아니며, 연동 결과에 따라 설계나 시험을 다시 확인해야 할 수도 있습니다.
요구사항을 확인 가능한 문장으로 바꿉니다
“쉽게 검색된다”보다 “조회 권한이 있는 담당자가 지정한 기간과 상태로 목록을 찾고, 선택한 결과를 내려받는다”가 검수하기 쉽습니다. 대상 사용자, 시작 조건, 입력, 정상 결과와 허용하지 않는 행동을 나누어 적으면 구현할 범위를 더 정확히 공유할 수 있습니다.
관리자 내보내기 기능을 예로 들면
- 조회 가능한 기간과 항목, 담당자의 권한을 정합니다.
- 조회 결과가 없거나 데이터가 많은 경우의 안내를 정합니다.
- 화면과 파일의 항목명, 시간대, 정렬 기준을 맞춥니다.
- 작업 중 화면을 닫거나 다시 요청했을 때의 동작을 확인합니다.
- 내려받기 권한이 없는 사용자와 접근 권한이 회수된 계정으로도 시험합니다.
요구사항에 없던 동작을 나중에 발견할 수는 있습니다. 이때 기존 합의와 다른 결함인지, 새로운 필요가 생긴 변경 요청인지 구분하고 추가 작업의 영향부터 확인해야 합니다.
검수 결과는 화면과 기록으로 남깁니다
검수표에는 실행 환경과 버전, 시험 데이터, 기대 결과, 실제 결과와 재확인 상태를 적습니다. 정상 사례만 확인하면 연결 종료나 권한 변경처럼 실제 운영에서 중요한 상황이 빠질 수 있습니다. 실제 고객 정보 대신 승인된 시험 자료를 사용하세요.
| 사례 | 확인할 결과 | 남길 근거 |
|---|---|---|
| 정상 입력 | 요청·대기·결과 화면이 정한 순서로 표현되는지 | 입력값과 결과 화면, 관련 식별값 |
| 중복 조작 | 반복 입력의 식별과 안내가 적절한지 | 요청과 응답의 연결 관계 |
| 연결 종료 | 알 수 없는 상태를 임의로 완료 처리하지 않는지 | 종료 시점과 복구 후 조회 결과 |
| 권한 회수 | 허용하지 않은 조회·변경이 제한되는지 | 역할 설정과 제한 확인 결과 |
| 화면과 파일 대조 | 항목·시간·건수가 정한 기준과 일치하는지 | 같은 조건의 조회 결과와 출력 파일 |
| 복구 시험 | 준비한 자료로 필요한 범위를 복원할 수 있는지 | 복원 절차와 확인한 누락·제한 |
시험 실패를 발견하면 재현 조건과 영향을 먼저 남깁니다. 수정한 버전으로 해당 사례를 다시 실행하고, 인접한 기능에 영향이 없는지도 확인해야 합니다. 인수를 진행할 때는 남은 결함과 제한, 후속 확인 책임을 서로 같은 내용으로 이해하고 있어야 합니다.
자료 이전은 작은 시험부터 시작합니다
기존 자료가 있다면 원본 항목과 새 시스템의 항목이 어떻게 연결되는지 먼저 표로 정리하세요. 날짜·시간대, 숫자 단위, 중복 식별과 누락 값의 처리 기준을 확인합니다. 파일을 읽을 수 있다는 사실과 업무에 맞게 옮겨졌다는 사실은 다릅니다.
처음에는 비식별 표본으로 변환과 검증을 시험하고, 결과가 맞는지 원본과 대조합니다. 실제 이전 시점에 새로 생기는 자료를 어떻게 반영할지, 작업 중 변경을 제한할 필요가 있는지, 문제가 생기면 어느 시점으로 돌아갈 수 있는지 정해야 합니다.
백업은 생성 여부만 보지 말고 복원 결과를 확인하세요. 복원 대상과 기준 시점을 정한 뒤 별도 환경에서 절차를 시험하고, 누락이나 의존성이 있으면 인수 자료에 남깁니다. 데이터 구조가 바뀌는 작업은 이전 프로그램으로 되돌리는 것만으로 원상 복구되지 않을 수 있습니다.
장애가 생겼을 때 역할을 나누어 둡니다
프로그램, 서버, 네트워크와 외부 데이터 서비스가 연결되어 있다면 한 곳에서 원인을 바로 확정하지 못할 수 있습니다. 문의를 받는 사람과 실제 변경 권한을 가진 담당자가 누구인지, 외부 업체와의 연락은 누가 맡는지 운영 전에 정하세요.
| 업무 | 정해 둘 사항 |
|---|---|
| 접수·분류 | 문의 경로, 영향 범위와 긴급도 판단 담당자 |
| 원인 확인 | 조회 가능한 기록, 접근 권한과 외부 확인 경로 |
| 조치 승인 | 설정 변경·재시작·우회 처리의 승인과 실행 담당자 |
| 사용자 안내 | 확인된 영향과 다음 안내 시점을 전달하는 담당자 |
| 정상화 확인 | 대표 업무의 재시험, 결과 확인과 후속 작업 기록 |
문의 접수 가능 시간, 초기 응답과 실제 복구는 서로 다른 조건입니다. 계약에 없는 상시 지원이나 복구 시간을 가정하지 마세요. 오류를 전달할 때는 발생 시간, 사용 환경, 화면과 재현 절차를 적되 비밀번호·비밀키·고객 정보는 제거해야 합니다.
인수 이후의 변경도 하나의 작업으로 관리합니다
작은 설정 변경이라도 적용 대상과 영향을 확인해야 합니다. 변경 이유, 수정 내용, 검토한 버전, 적용 담당자와 확인 절차를 기록하세요. 배포 전에 되돌릴 수 있는 조건을 확인하고, 되돌릴 수 없는 데이터 변경이 있다면 별도 대응 계획이 필요합니다.
인수 자료에는 설치·설정 안내, 계정과 권한 목록, 외부 의존성, 알려진 제한과 운영 확인 항목을 포함할지 검토합니다. 소스 자료나 별도 교육의 제공 여부는 도입 방식과 인수 조건에서 확인해야 합니다.
현재 시스템이 있다면 가장 자주 처리하는 업무와 이전에 어려웠던 사례를 정리해 주세요. 구축 상담에서 필요한 변경과 확인 절차를 설명하는 데 도움이 됩니다.