GIZ SYSTEMS / PUBLICATION OPERATIONS
구축 견적에 운영의 끝까지 담는 법
오픈 이후의 책임, 검수, 복구와 이관까지 비교해야 제안서의 실제 범위가 보입니다.

아키텍처 개념도
“구축 완료 후 운영 지원.” 제안서에 이 문장이 있어도 누가 어떤 시간대에 무엇을 처리하는지는 알 수 없습니다. 홈페이지와 업무 앱의 가격을 비교할 때는 화면 수와 개발 공수 외에 오픈 이후의 책임을 같은 항목으로 비교해야 합니다.
구축 결과와 운영 서비스를 구분합니다
구축 결과는 화면, 데이터 연결, 업무 동작과 인수 자료입니다. 운영 서비스는 그 결과를 유지하기 위한 모니터링, 문의 처리, 변경, 장애 대응과 복구 업무입니다. 같은 공급자가 맡더라도 범위와 종료 조건을 각각 적습니다.
| 제안서 항목 | 비교할 내용 |
|---|---|
| 업무 범위 | 실제 완료할 사용자 업무, 대상 조직, 제외 범위 |
| 데이터·연계 | 원천 소유자, 연결 방식, 갱신 주기, 오류 처리 담당 |
| 인수 조건 | 대표 업무와 예외, 권한, 동시 사용, 합의한 데이터 규모 |
| 운영 지원 | 지원 시간, 접수 경로, 심각도, 응답과 복구의 구분 |
| 변경·비용 | 포함된 변경의 기준, 외부 사용료, 추가 견적의 발생 조건 |
| 이관·종료 | 데이터·설정·소스의 제공 범위, 문서, 계정 이전과 지원 기간 |
“연동 포함”이라면 조회만 포함하는지, 승인된 변경 반영까지 포함하는지 확인합니다. “백업 포함”이라면 무엇을 복원해 보았는지와 복구 후 업무 확인 범위를 물어보세요.
검수는 대표 업무를 직접 완료하는 방식으로
콘텐츠 사이트라면 초안 작성, 검토, 발행, 첨부 교체와 철회를 실제 담당자가 수행합니다. 업무 앱이라면 요청 접수에서 승인·조치·완료 확인까지 진행합니다. 제출 버튼이 눌렸다는 사실보다 대상 시스템의 상태와 담당자의 업무 완료를 확인합니다.
성능 조건은 사용자 수, 데이터량과 실행할 동작을 함께 적어야 비교할 수 있습니다. 권한 검수에는 다른 조직의 자료, 오래된 승인, 접근이 회수된 사용자처럼 현장에서 발생할 조건을 포함합니다.
운영의 인계점에는 이름이 있어야 합니다
장애를 발견하는 사람, 기술적으로 처리하는 사람, 고객에게 알리는 사람을 정합니다. 외부 시스템 장애라면 누가 공급자와 연락하고 누가 업무 대안을 결정할지도 필요합니다. 동일한 역할을 한 사람이 맡더라도 책임 자체는 기록합니다.
좋은 비교표는 빈칸을 보여 줍니다
모든 제안서가 같은 항목에 답하도록 요청하세요. 아직 확인하지 못한 데이터 품질이나 연결 조건은 가정으로 남기고, 확인 시점과 비용·일정에 미치는 영향을 적습니다. 이 빈칸을 착수 전에 줄이는 작업이 이후의 추가 비용과 책임 논쟁을 줄이는 데 도움이 됩니다.
다음 아티클 →
엑셀을 옮기기 전에, 예외부터 읽습니다
다음 단계
가장 복잡한 업무 하나를 가져오세요.
현재 쓰는 파일과 시스템, 바꾸고 싶은 일을 함께 살펴보겠습니다.