38장. SI 프로젝트의 요구사항

SI·발주 환경에서 계약 범위·인수 기준·변경 절차와 공급자 책임을 명확히 하되 불확실성을 숨기지 않는다.

이번 장에서 해결할 질문

학습 목표

• “계약·검수·다조직 협업이 있는 SI 환경에서 요구사항 책임을 어떻게 분명히 하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

공공·기업 소프트웨어 프로젝트에서는 같은 요구가 여러 종류의 문서와 계약을 거쳐 전달된다. 제안요청서, 제안서, 계약, 요구사항 정의서와 설계·시험 문서가 각자의 목적을 갖는데도 하나가 다른 하나를 대신한다고 보면 책임과 승인 기준이 흐려진다.

이 장에서는 발주부터 개발·검수·변경관리까지 주요 산출물의 역할과 연결을 살펴본다. 각 문서가 어떤 질문에 답하고 누가 책임지는지 구분하며, 요구의 근거와 버전이 문서 경계를 넘어 추적되도록 실무 흐름을 정리한다. 문서 이름보다 계약상 효력과 승인 시점을 먼저 확인하는 관점도 함께 다룬다.

1. 제안요청서

SI 프로젝트에서는 발주자와 수행자의 조직·권한·지식이 분리되고 계약이 책임 경계가 된다. 특히 공공 SW 사업은 조달·계약·과업심의·감리 등 별도 법제와 기관 지침의 영향을 받을 수 있다. 그러나 “SI”라는 이름만으로 모든 사업에 같은 문서·감리·검수 절차가 적용되는 것은 아니다. 공공·민간, 계약 방식, 사업 규모·유형, 적용 법령과 발주기관 규정을 먼저 확인한다.

이 장의 법제 정보는 2026년 8월 22일 확인 기준이며 법률 자문을 대신하지 않는다. 국가법령정보센터의 소프트웨어 진흥법, 소프트웨어사업 계약 및 관리감독에 관한 지침, 행정기관 및 공공기관 정보시스템 구축·운영 지침의 현행 시행일·적용 범위를 사업마다 다시 확인해야 한다.

제안요청서(RFP)는 공급자에게 기능 목록을 전달하는 문서만이 아니다. 사업 목적, 현행 문제, 범위·제외, 사용자·업무, 품질·데이터·연계·보안·전환, 발주자 제공사항, 산출물·일정·검수와 변경 절차를 제안하고 비교할 수 있게 제시한다. 발주 전에 모르는 사항은 가정·질의·상세화 책임과 결정 시점을 명시한다.

수강신청 고도화의 RFP 요구 후보는 다음처럼 묶을 수 있다.

“고성능”, “사용자 친화적”, “기존 시스템과 연계” 같은 문구만으로는 규모 산정과 검수가 어렵다. 반대로 제품명·테이블·화면 좌표까지 미리 고정하면 경쟁 대안과 상세 분석을 막는다. 결과·제약·수용 가능한 증거를 명확히 하고 설계 선택은 필요한 범위에서 제안하게 한다.

공공 SW 사업에서는 요구사항 상세화, 과업내용 확정과 변경, 상용 SW 직접구매, 보안·접근성·상호운용성 등 적용 항목을 체크해야 한다. 체크리스트를 붙이는 것보다 해당 의무가 어느 RFP 절·계약·산출물·검수에 반영되는지 책임자를 둔다. 실제 발주 문서가 없는 이 사례의 모든 RFP 항목은 교육용 후보이며 공고 가능한 문서가 아니다.

2. 제안서

제안서는 RFP 문장을 반복하는 답안이 아니라 공급자가 요구를 어떻게 이해했고 어떤 범위·방법·조직·일정·품질·위험으로 이행할지를 약속하는 입력이다. 평가를 잘 받기 위한 표현과 계약 뒤 실제 의무가 될 내용을 구분해야 한다.

제안자는 요구별로 수용, 조건부 수용, 대안, 제외와 발주자 의존을 표시한다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 p95 2초 후보를 “충족 가능”이라고만 쓰지 않고 부하 모델, 측정 경계, 필요한 인프라·데이터와 발주자 제공 환경을 제시한다. IR-004IR-004 · 인터페이스 요구규칙 결과·사유·버전 제공. 규칙 연계에는 현재 API 문서·SLA·테스트 환경이 없다는 가정을 밝히고, 실패 시 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 보류·재평가를 어떻게 실현할지 대안을 설명한다.

제안서의 우수 기능을 계약 범위에 넣을지 명확히 해야 한다. “AI 기반 추천”, “실시간 대기순번”처럼 RFP에 없던 항목이 평가 약속인지 선택 옵션인지 모호하면 이후 무상 과업 논쟁이 생긴다. 협상·질의응답·제안 발표에서 정정된 내용도 최종 계약 문서 우선순위에 반영한다.

제안 단계의 추적표는 상세 설계표가 아니라 RFP 요구별 대응 위치·수용 상태·가정·비용 항목을 보여 주면 충분하다. 평가위원의 질의와 공급자 답변도 나중의 상세 분석에서 검증할 가정으로 넘긴다. 실현 가능성이 확인되지 않은 홍보 문구를 요구 승인으로 바꾸지 않는다.

3. 계약 요구사항

계약 요구사항은 RFP, 제안서, 협상·질의응답, 과업내용서와 계약 조건 중 실제 의무가 되는 내용을 식별한 집합이다. 문서끼리 표현이 다를 때 적용 우선순위가 없으면 발주자는 RFP를, 수행자는 제안의 가정을 근거로 서로 다른 범위를 주장할 수 있다.

CTR-ENR-001CTR-ENR-001 · 프로젝트 항목수강신청 구축 범위를 계약 요구부터 상세 요구, 기능·화면, API·데이터, 시험·검수까지 추적하는 계약 항목 후보다. 후보를 RFP-FUN-001RFP-FUN-001 · 프로젝트 항목검색·접수·판정·상태·취소 능력.과 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.에 연결한다.

계약상대자는 인증된 학생이 자신의 신청 식별자로 접수와 판정 상태, 공개 가능한 사유, 마지막 갱신 기준과 가능한 다음 행동을 확인할 수 있는 기능을 제공하고, 합의된 접근성·보안·성능 조건과 시험·인수 증거를 충족해야 한다.

이 문장만으로도 공개 사유 정책, 성능 환경, 기존 데이터, 알림 범위는 상세화가 필요하다. 계약에는 상세 분석에서 결정할 항목, 결정 권한·기한, 기준선 통과 조건과 변경 절차를 둔다. 상세화가 계약 목적 안의 구체화인지 새로운 과업인지 판단할 기준도 필요하다.

국가법령정보센터의 현행 소프트웨어 진흥법 제50조 관련 정보는 국가기관 등의 소프트웨어사업 과업심의위원회가 과업내용 확정과 과업내용 변경 및 그에 따른 계약금액·계약기간 조정을 심의하도록 규정한다. 실제 적용 여부와 절차는 사업·기관·시행 시점의 법령·하위 지침을 확인한다. 내부 변경회의를 했다는 사실이 법정·계약 절차를 자동으로 대신하지 않는다.

계약 요구에는 의무 주체와 인수 조건을 붙인다. 인증·학사·규칙 서비스가 발주자 또는 제3자 제공이라면 제공 시점, 품질, 변경 통보와 시험 환경 책임을 정한다. 공급자가 통제할 수 없는 전제 실패를 무조건 납기 책임으로 만들거나, 공급자가 자신의 연계·회복 설계 책임을 외부 탓으로 돌리지 않게 경계를 명시한다.

계약 기준선은 “모든 요구가 완벽히 상세함”을 뜻하지 않는다. 목적·범위·책임·변경 권한이 합의되고 남은 상세화가 일정·대가·위험 안에서 관리 가능한 상태다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.은 승인되지 않은 변경 후보이므로 계약 요구에 포함하지 않는다.

4. 요구사항 정의서

요구사항 정의서는 계약 요구를 사용자·시스템·규칙·품질·데이터·연계·전환 관점에서 분석한 기준 문서다. 화면 목록이나 기능명만 나열하지 않고 ID, 설명, 근거, 우선순위·상태, 전제, 수용 기준, 출처·책임자와 추적을 포함한다.

정의서는 앞선 RFP와 계약 내용을 조용히 확대하거나 축소하는 장소가 아니다. 분석에서 좌석 대기명단이 필요하다는 의견이 나오면 새 요구·변경 후보로 분리한다. 계약 안의 상세화라면 근거를, 범위 변화라면 비용·기간·시험·운영 영향을 기록한다.

요구 검토에는 발주 업무·정책, 수행 분석·설계·시험, 보안·개인정보, 데이터·연계와 운영자가 참여한다. 서명란을 채우기 전에 쟁점이 해결됐는지, 미결이면 누가 언제 결정하는지 본다. 같은 용어가 정의서·화면·인터페이스·시험에서 다른 의미로 쓰이지 않게 용어집과 상태 모델을 연결한다.

실제 프로젝트는 조직 표준 서식을 쓸 수 있지만 모든 상세를 한 파일에 넣을 필요는 없다. 규칙표·데이터 사전·품질 시나리오를 별도 관리하더라도 정의서가 위치·버전을 참조해야 한다. 중복 복사는 검토 범위를 늘리고 불일치를 만든다.

5. 요구사항 관리대장

요구사항 관리대장은 요구의 현재 관리 상태와 변경 이력을 보는 통제 장부다. 정의서가 의미를 설명한다면 관리대장은 소유·상태·버전·승인·적용·변경·미결을 빠르게 찾게 한다. 스프레드시트 파일 이름만 바뀌고 내용이 고정되면 관리가 아니다.

관리대장 후보 필드:

하나의 완료율 열로 분석·구현·시험·검수를 합치지 않는다. FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.이 구현됐지만 접근성 시험이 미실행이면 구현 상태와 검증 상태를 분리한다. 조건부 수용과 미해결 결함도 완료로 숨기지 않는다.

관리대장의 소유자는 문서관리자가 모든 상태를 임의로 바꾸는 사람이 아니다. 각 산출물 책임자의 변경을 수집하고 정합성을 점검하며 승인 근거 없는 상태 전이를 막는다. 자동화할 수 있는 링크·빌드·시험 결과는 자동 수집하되 업무 승인과 위험 수용은 권한 있는 사람이 결정한다.

대장을 정기적으로 검토할 때는 오래된 검토 대기, 설계·시험이 없는 승인 요구, 상위 근거가 없는 기능, 승인되지 않은 범위 구현과 미결 가정의 기한을 찾는다. 행 수가 계약 과업 수와 같다는 것만으로 완전성을 판단하지 않는다.

6. 요구사항 추적표

요구사항 추적표는 RFP부터 검수까지 같은 의미가 어떻게 할당됐는지 양방향으로 보여 준다. 관리대장과 상호 보완 관계지만 목적이 다르다. 추적표는 누락·무근거 산출물과 변경 영향을 찾고, 관리대장은 현재 책임과 진행을 통제한다.

CTR-ENR-001CTR-ENR-001 · 프로젝트 항목수강신청 구축 범위를 계약 요구부터 상세 요구, 기능·화면, API·데이터, 시험·검수까지 추적하는 계약 항목 후보다.의 SI 추적 후보:

추적은 파일 열 번호보다 안정된 ID와 의미 관계를 사용한다. “포함”, “파생”, “충족”, “검증”, “대체”가 다른 관계임을 구분한다. 화면이 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.을 포함한다고 해서 API가 자동 충족되는 것이 아니고, 시험 케이스가 링크됐다고 실행·통과한 것도 아니다.

역추적은 설계·기능에서 계약 근거를 찾고 금도금 기능을 발견한다. 순방향 추적은 승인 요구가 설계·시험·검수에서 빠졌는지 찾는다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. 영향분석에서는 규칙뿐 아니라 계약 범위·대가·기간, 화면 공개, 데이터, 동시성 시험과 감리 증거까지 따라간다.

추적표를 제출 직전에 수작업으로 맞추면 실제 변경 통제가 되지 않는다. 요구·설계·시험 검토와 변경 승인 때 갱신하고, 누락 링크를 품질 게이트에서 검사한다. 도구 간 URL이 바뀌어도 ID와 버전으로 재구성할 수 있게 내보내기·보존을 계획한다.

7. 기능 정의서

기능 정의서는 상세 요구를 사용자·시스템 능력과 처리 책임으로 묶는다. 메뉴 목록이나 프로그램 모듈 목록과 다르다. 기능 ID, 목적, 사용 주체, 진입 조건, 정상·대체·예외 흐름, 규칙, 입력·출력, 상태 변화, 권한, 품질과 관련 요구를 둔다.

FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회. 후보는 학생이 자신의 공식 신청 상태를 조회하도록 하며 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.을 실현한다. 정상 승인뿐 아니라 접수됨, 판정 중, 보류, 거절, 취소와 오래된 응답을 포함한다. 알림 기능 FEAT-NOTIFY-01FEAT-NOTIFY-01 · 기능 묶음상태 변경 보조 통지.은 상태 기능과 분리하고 전달 성공을 업무 성공으로 해석하지 않는다.

기능을 프로그램 수나 화면 수로 바로 환산하지 않는다. 하나의 기능이 여러 화면·API를 통과할 수 있고 같은 규칙을 접수·운영 기능이 재사용한다. RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.는 기능 문장마다 복사하지 않고 공식 규칙과 버전을 참조한다.

기능 정의 검토는 “구현할 수 있는가?”뿐 아니라 상위 요구를 빠짐없이 실현하는지, 둘 이상의 결정 책임이 섞였는지, 실패 의미와 운영 책임이 있는지 본다. 계약에 없는 추천·대기명단 기능을 정의하려면 변경 상태와 근거를 붙인다.

8. 화면 설계서

화면 설계서는 화면의 배치와 전환만 그리는 문서가 아니다. 사용자 목표, 정보·행동 책임, 입력·출력, 업무·표현 상태, 검증·오류·권한·접근성과 API·데이터 연결을 담는다. 와이어프레임은 그중 하나의 표현이다.

SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내.에는 접수·판정 구분, 신청 ID, 현재 상태, 공개 사유, 마지막 갱신 기준과 다음 행동이 필요하다. 로딩·빈 결과·부분 데이터·보류·권한 만료·네트워크 실패·오래된 상태를 함께 설계한다. “대기”라는 한 문구로 처리 보류와 미승인 좌석 대기명단을 합치지 않는다.

화면 설계서 필드는 다음처럼 추적된다.

발주자 검토 의견이 픽셀 수정인지 요구 변경인지 구분한다. 같은 필요를 충족하는 표현 대안은 디자인 결정으로 관리할 수 있지만 새로운 업무 승인, 데이터 공개, 대리 신청은 범위·권한·시험 영향이 있는 요구 변경이다. 화면 승인 도장을 전체 요구 승인으로 사용하지 않는다.

9. 인터페이스 정의서

인터페이스 정의서는 화면 API뿐 아니라 외부 시스템·파일·메시지·배치의 경계 계약을 설명한다. 제공·소비 주체, 목적, 인증·인가, 데이터 의미·스키마·버전, 호출·전달 방식, 시간·용량, 중복·순서, 오류·재시도, 개인정보, 시험·운영 연락을 포함한다.

API-RULE-01API-RULE-01 · API 설계규칙 평가 연계.은 학생·강좌·학적 입력 기준선을 받아 판정 결과·사유·규칙 버전을 제공하는 후보 계약이다. 성공 코드라도 필수 버전이 없거나 알 수 없는 결과면 승인으로 변환하지 않는다. 시간 초과·무효 응답은 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.에 따라 보류·재평가로 이어진다.

인터페이스 양쪽 조직이 정의서를 공동 검토하고 계약 예제와 모의 환경을 제공한다. 수행자가 임의 필드 값을 가정하거나 발주자가 운영 API와 다른 모의 응답을 제공하면 통합 후 재작업이 생긴다. 외부 시스템 변경은 IR 요구와 회귀 시험까지 영향 분석한다.

10. 데이터 설계서

데이터 설계서는 엔터티·테이블·열뿐 아니라 업무 사실, 공식 원천·기준 시점, 무결성, 생명주기, 이관·대사, 보존·파기와 접근 책임을 설명한다. 요구사항 정의서의 데이터 요구와 화면·인터페이스의 필드가 어디에 반영되는지 추적한다.

수강신청 후보의 핵심은 DATA-APPLICATION-01DATA-APPLICATION-01 · 데이터 설계신청 ID, 주체, 대상, 요청 ID, 현재 상태·버전. 신청 생명주기와 DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현. 판정 근거다. 현재 상태만 덮어쓰면 늦은 응답과 운영 조치를 설명하기 어렵고, 모든 개인정보를 무기한 복사하면 QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다을 해친다. 필요한 이력·스냅숏·파생 현재 상태를 구분한다.

설계서에는 다음 무결성 후보를 둔다.

• 같은 요청 ID와 동일 의도는 복수 신청 효과를 만들지 않는다.
• 승인·좌석·결정 기록은 합의한 일관성 경계를 지킨다.
• 규칙·학적 입력의 기준 시점과 버전으로 판정을 설명할 수 있다.
• 늦은 응답이 더 새로운 취소·재평가 결과를 덮지 않는다.
• 운영 변경은 주체·사유·전후 상태와 함께 감사된다.

이관 IR-006IR-006 · 인터페이스 요구합의 형식·전달., DR-006DR-006 · 데이터 요구이관 전후 건수·관계·핵심 값과 이력을 대사할 수 있게 한다은 소스-대상 매핑, 정제·변환 규칙, 중복·누락 처리, 시험 이관, 건수·합계·참조·표본 대사, 전환·롤백과 개인정보 폐기를 포함한다. “DB 이관 완료” 메시지보다 어떤 판정과 신청이 재현되는지 확인한다. 좌석 대기명단 데이터는 범위 미확정이므로 미리 테이블로 굳히지 않는다.

11. 시험

시험 산출물은 요구 기반 전략, 조건·시나리오·케이스, 환경·데이터, 실행 결과, 결함과 증거를 연결한다. 단위·통합·시스템·성능·보안·접근성·이관·복구·UAT가 각기 어떤 요구와 위험을 확인하는지 정한다.

CTR-ENR-001CTR-ENR-001 · 프로젝트 항목수강신청 구축 범위를 계약 요구부터 상세 요구, 기능·화면, API·데이터, 시험·검수까지 추적하는 계약 항목 후보다.→FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.→TC-FR-003-01TC-FR-003-01 · 시험 항목정상·보류·거절·인가 결과 확인.은 상태·사유·다음 행동을 화면·API·데이터 이력에서 확인한다. IR-001IR-001 · 인터페이스 요구자격·운영 흐름.→TC-IR-001-01TC-IR-001-01 · 시험 항목규칙 연계의 실패·무효·시간 초과·늦은 응답에서 자동 승인 없이 원인 있는 보류와 이력이 남는지 확인하는 시험 후보다.은 규칙 시간 초과 때 자동 승인 없음과 보류·재평가를 본다. ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.→TC-CAP-001-01TC-CAP-001-01 · 시험 항목마지막 좌석에 여러 신청이 동시에 들어와도 정원 초과와 복수 승인이 생기지 않는지 확인하는 시험 후보다.은 마지막 좌석 동시 요청에서 초과 승인 없음과 데이터 대사를 확인하지만, 정책 미결인 승자를 임의로 정하지 않는다.

시험 계획에는 발주자·수행자 제공 환경과 데이터, 외부 기관 참여, 장애 주입 권한, 판정자와 재시험·종료 조건을 둔다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.은 합의한 동시 사용자·데이터·네트워크·측정 구간이 없으면 통과 판정을 유보한다. 운영 데이터 무단 복사 대신 합성·마스킹·최소화 절차를 쓴다.

결과 기록은 요구·빌드·설정·환경·데이터 버전, 실제·예상 결과, 통과·실패·차단, 결함·증거 위치를 포함한다. 케이스 수와 통과율만 보고하지 않고 미실행·차단·조건부 통과와 잔여 위험을 보여 준다. 감리용으로 나중에 만든 결과가 아니라 실제 품질·인수 결정에 사용된 증거여야 한다.

12. 검수

검수는 납품 파일 개수 확인이나 시연 참석과 다르다. 계약 요구와 승인 기준선, 품질·전환 조건을 합의된 환경에서 충족했는지 권한 있는 발주자가 증거로 판단하는 행위다. 기능 구현, 시험 통과, 산출물 제출, 운영 준비와 계약상 인수는 서로 다른 상태일 수 있다.

검수 중 발견한 항목을 결함, 미제출, 새 요구, 발주자 의존 미이행으로 분류한다. 새 요구를 무상 하자보수로 넘기거나 명세 불일치를 변경으로 돌리는 일을 막는다. 조건부 검수에는 잔여 항목, 위험·임시 통제, 완료 기한·책임과 미이행 결과를 기록한다.

검수 확인서는 모든 위험이 사라졌다는 선언이 아니다. 알려진 제한·유예와 운영 인계, 보증·하자보수 경계를 명시한다. 실제 인수권자가 없는 이 사례에서는 검수 완료로 표시하지 않고 필요한 증거 틀만 제시한다.

13. 변경관리

변경관리는 요구사항 관리대장의 상태 수정이 아니라 계약·과업·설계·시험·대가·기간·운영 영향을 권한 있게 결정하고 동기화하는 흐름이다. 구두 요청, 회의 의견, 메신저 지시와 공식 변경 승인을 구분한다.

CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. 우선권 후보의 변경 흐름:

현행 소프트웨어사업 계약 및 관리감독 지침의 과업변경 관련 조문은 과업내용 변경 신청과 계약금액·기간 조정 심의 절차를 다룬다. 해당 사업에 적용되는 최신 법령·계약을 확인하고 정해진 양식·기한·위원회 절차를 따른다. 내부 Jira 티켓 승인이 법정 과업심의를 대신한다고 가정하지 않는다.

영향분석에는 변경하지 않을 때의 정책 위반·수동 통제·사용자 피해도 포함한다. 승인 전 선구현은 매몰비용으로 결정을 압박하므로 기능 비활성화 실험이라도 권한과 비용을 확인한다. 승인 뒤에는 계약만 고치고 정의서·설계·시험을 남겨 두지 않도록 산출물별 소유자와 완료 게이트를 둔다.

14. 감리

정보시스템 감리는 사업 관리·품질 활동과 검수를 대신하는 마지막 문서 검사가 아니다. 적용 법령·대상·시점에 따라 독립적 관점에서 사업 관리, 시스템·데이터·보안·품질 등의 계획과 수행이 적정한지 점검하고 개선을 요구하는 활동이다. 모든 SI 프로젝트에 자동 적용된다고 단정하지 않는다.

한국지능정보사회진흥원은 정보시스템 감리 발주·관리 및 수행 가이드를 공식 자료실에 제공한다. 실제 사업은 최신 감리기준, 발주기관 지침, 사업 유형·규모와 감리 계약 범위를 확인한다. 감리인은 발주자의 정책 승인자나 시스템 인수권자와 역할이 다르다.

감리에 제대로 대비한 상태는 요구 정의서와 관리대장 숫자가 같아 보이는 것이 아니다. 표본 요구를 RFP·계약·승인·설계·시험·변경까지 추적했을 때 실제 결정과 증거가 일치하고, 미결 위험과 조치 결과를 재현할 수 있어야 한다.

감리 지적은 근거와 위험을 검토해 요구·설계·시험·관리 절차에 반영한다. 문구만 보완해 지적을 닫지 않고 원인, 영향 범위, 시정 결과와 재발 방지 증거를 남긴다. 반대로 감리 의견이 계약 범위·정책 결정을 새로 요구한다면 권한 있는 변경 절차로 넘긴다.

감리 준비는 수검 직전 별도 복사본을 만드는 행사가 아니다. 요구 검토, 기준선 승인, 설계 할당, 시험 실행과 변경 심의 때 사용한 원본 기록을 통제된 저장소에 버전과 권한으로 축적한다. 제출본을 따로 만들 필요가 있더라도 원본과 기준 시점·추출 방법을 표시한다. 감리 표본에서 불일치가 발견되면 그 행만 고치지 않고 같은 생성 과정과 산출물 집합에 문제가 있는지 범위를 넓혀 확인한다.

발주자도 감리 대응을 수행자에게만 맡길 수 없다. 정책·과업·발주자 제공 데이터와 외부 기관 협의, 검수·위험 수용은 발주 책임의 증거다. 수행자는 분석·설계·구현·시험과 변경 영향의 증거를 제공한다. 감리인은 이행 상태를 독립적으로 점검하지만 누락된 업무 결정을 대신 승인하지 않는다. 세 역할을 구분해야 지적 조치가 실제 책임자에게 연결된다.

이 장에서 정리한 결과는 SI 산출물 매핑표, 계약-요구-설계-시험-검수 추적표, 요구사항 관리대장 필드, 과업 변경 승인 흐름, 감리 증거 점검표다. 산출물 이름이 많아도 공통 사슬은 단순하다.

문서 형식은 기관과 계약에 맞추되 필요·근거·검증·추적·변경 책임은 유지한다. 다음 장에서는 사업 종료 뒤 장애·개선·민원·법제도·외부 시스템 변경이 들어올 때 이 인계 증거를 운영 요구와 회귀 기준으로 바꾸는 방법을 다룬다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로