첫 SI 프로젝트에 투입된 두 신입.
A는 "개발만 잘하면 되겠지"라고 생각합니다. 코드는 잘 짭니다. 그런데 분석 단계에서 발주사가 무엇을 승인했는지 모른 채 만들다가, 검수 때 "이건 요구사항에 없던 거고, 이건 빠졌다"는 말을 듣습니다. 일정은 밀리고, 누구 책임인지 다투게 됩니다.
B는 첫날 단계 흐름부터 머릿속에 그립니다. "지금은 분석 단계, 산출물은 요구사항정의서, 이걸 발주사가 검수해야 설계로 넘어간다." 그래서 B는 코딩보다 먼저 "이 단계는 무엇으로 끝나고, 누가 승인하는가"를 묻습니다. 오픈 날 새벽 컷오버 때도 B는 롤백 기준과 비상 연락망을 들고 있습니다.
둘의 차이는 코딩 실력이 아니라 프로젝트가 어떻게 흐르는지에 대한 지도입니다. SI는 단계마다 산출물과 검수라는 관문으로 묶여 있고, 그 지도를 모르면 아무리 코드를 잘 짜도 '관리되지 않는 일'이 됩니다. 이 모듈은 그 지도를 그립니다.
- 1SI 프로젝트의 전체 단계(제안·수주 → 착수 → 분석 → 설계 → 개발 → 테스트 → 검수 → 이행/오픈 → 안정화 → 운영전환)를 순서대로 설명할 수 있다
- 2각 단계의 대표 산출물과 검수 게이트가 무엇인지 짝지을 수 있다
- 3오픈(컷오버)이 왜 위험하고, 컷오버 체크리스트에 무엇이 들어가야 하는지 설명할 수 있다
- 4안정화 기간·하자보수의 의미와, 프로젝트(SI)에서 운영(SM)으로 넘어가는 전환 지점을 짚을 수 있다
- 5산출물과 검수가 책임·대금·일정과 어떻게 연결되는지 직무 관점에서 이해할 수 있다
SI 프로젝트는 '단계의 연속'이다
왜 단계로 쪼개고, 단계마다 문을 다는가
큰 시스템을 한 번에 "만들어 주세요" 하고 통째로 받으면, 중간에 무엇이 틀어졌는지 끝나기 전엔 알 수 없습니다. 그래서 SI 프로젝트는 일을 **단계(phase)**로 쪼개고, 각 단계 끝에 산출물을 두고, 발주사가 그 산출물을 확인·승인하는 검수 게이트를 답니다. 이렇게 하면 "여기까지는 서로 합의했다"는 경계가 단계마다 생깁니다.
이 구조에는 세 가지 효과가 있습니다.
- 합의의 동결: 분석서가 검수되면 "요구사항은 이것"으로 확정됩니다. 나중에 "그건 원래 없던 건데요"라는 다툼의 기준이 생깁니다.
- 대금(기성)의 근거: 한국 SI는 보통 단계별·기성률로 대금을 나눠 받습니다. 검수 승인은 그 단계 비용을 청구할 근거가 됩니다.
- 위험의 조기 발견: 설계 단계에서 발견한 문제는 싸게 고칩니다. 같은 문제를 오픈 직전에 발견하면 비용이 수십 배가 됩니다.
핵심 어휘를 먼저 맞추겠습니다.
| 용어 | 뜻 |
|---|---|
| 발주사(원청) | 시스템을 발주하고 대금을 지급하는 쪽(고객) |
| 수행사(SI사) | 시스템을 구축하는 쪽. 협력사(하도급)에 일부를 재위탁하기도 함 |
| 산출물(Deliverable) | 각 단계가 만들어 내는, 합의 가능한 문서·결과물 |
| 검수(인수, Acceptance) | 발주사가 산출물을 확인해 단계 완료를 승인하는 행위 |
| 게이트(Gate) | 검수로 단계를 통과/반려시키는 관문 |
| 이행(컷오버, Cutover) | 새 시스템을 실제 운영으로 전환하는 작업 |
| 안정화 | 오픈 직후 초기 결함을 집중 대응하는 완충 기간 |
| 하자보수 | 검수 후 일정 기간 결함을 무상 수정하는 계약상 의무 |
단계별로 무엇을 만들고 무엇으로 통과하는가
제안·수주에서 운영전환까지
전형적인 한국 SI 프로젝트의 단계는 다음과 같이 흐릅니다. 조직·방법론에 따라 명칭은 조금씩 다르지만 골격은 같습니다.
- 제안·수주: 발주사가 제안요청서(RFP)를 내고, 수행사가 제안서로 응답해 경쟁·선정됩니다. 계약·과업범위가 확정됩니다.
- 착수(킥오프): 팀 구성, 일정·범위·역할 합의, 수행계획서 작성. "어떻게 진행할지"를 못 박는 단계입니다.
- 분석(요구사항): 발주사의 요구를 캐내 요구사항정의서로 정리합니다. "무엇을 만들 것인가"를 확정합니다.
- 설계: 요구사항을 실제 구조로 옮깁니다. 화면설계·DB설계·인터페이스설계 등. "어떻게 만들 것인가"를 그립니다.
- 개발(구현): 설계대로 코드·DB·화면을 만듭니다. 단위 테스트가 병행됩니다.
- 테스트: 통합 테스트, 시스템 테스트, 그리고 발주사가 참여하는 인수 테스트(UAT)로 결함을 찾아 고칩니다.
- 검수(인수): 발주사가 최종 산출물과 동작을 확인해 시스템을 받아들입니다. 검수확인서가 나옵니다.
- 이행/오픈(컷오버): 데이터 이관, 시스템 전환, 실서비스 개시. 되돌리기 어려운 전환 작업입니다.
- 안정화: 오픈 직후 초기 인시던트를 프로젝트 팀이 집중 대응합니다.
- 운영전환: 시스템을 운영(SM) 조직에 인계하고, 프로젝트는 종료, 하자보수 의무로 이어집니다.
이제 단계와 산출물·게이트를 한눈에 묶습니다. 이 표가 이 모듈의 중심입니다.
| 단계 | 핵심 질문 | 대표 산출물 | 검수 게이트(통과 기준) |
|---|---|---|---|
| 제안·수주 | 우리가 이 일을 맡는가 | 제안서, 계약서, 과업지시서 | 계약 체결·과업범위 확정 |
| 착수 | 어떻게 진행할 것인가 | 사업수행계획서, WBS, 일정표 | 발주사의 수행계획 승인 |
| 분석 | 무엇을 만들 것인가 | 요구사항정의서, 업무흐름도 | 요구사항 검토·승인 |
| 설계 | 어떻게 만들 것인가 | 화면설계서, DB설계서, 인터페이스정의서 | 설계 검토·승인 |
| 개발 | 설계대로 만들었는가 | 소스코드, 단위테스트 결과 | 개발 완료 보고·내부 점검 |
| 테스트 | 요구대로 동작하는가 | 통합·시스템 테스트 결과서, UAT 결과 | UAT 통과·결함 처리 확인 |
| 검수 | 받아들일 수 있는가 | 검수확인서, 사용자 매뉴얼 | 발주사 최종 검수 승인 |
| 이행/오픈 | 안전하게 전환됐는가 | 컷오버 계획서, 이관 검증 결과 | 오픈 판정·롤백 미발동 |
| 안정화 | 운영에서 잘 도는가 | 안정화 일일보고, 결함조치 내역 | 안정화 종료 확인 |
| 운영전환 | 운영이 넘겨받았는가 | 운영인수인계서, 운영 매뉴얼 | SM 조직 인수 완료 |
산출물 ≠ 검수 통과라는 점이 중요합니다. 문서를 제출했다고 통과가 아니라, 발주사가 그 문서를 검토해 "맞다"고 승인해야 게이트를 지납니다. 그래서 SI 관리자는 "언제까지 무엇을, 누구의 승인을 받아 닫는가"로 일정을 봅니다.
확대
그림: 각 단계는 산출물 제출이 아니라 발주사 승인(게이트)으로 닫히며, 이행·오픈이 가장 위험한 구간이다.
오픈(컷오버)이 왜 가장 위험한가
되돌리기 어려운 전환, 그래서 체크리스트로 묶는다
대부분의 단계는 다시 작업할 수 있습니다. 그러나 컷오버는 다릅니다. 옛 시스템을 끄고 새 시스템에 실데이터를 올려 실고객이 쓰기 시작하면, 잘못돼도 "어제로 되돌리기"가 매우 어렵습니다. 이관 도중 데이터가 깨지거나, 오픈 직후 부하로 시스템이 멈추면 손실은 바로 발주사의 매출·신뢰로 갑니다.
그래서 컷오버는 즉흥이 아니라 사전에 합의된 체크리스트와 시나리오로 움직입니다. 핵심은 "성공 절차"만큼 "실패했을 때 어떻게 살아남는가(롤백)"를 미리 정해 두는 것입니다.
오픈(컷오버) 체크리스트 — 최소 항목
- 컷오버 일정·작업 순서가 분 단위 시나리오로 작성되었는가 (작업자·시작/종료 시각 포함)
- 데이터 이관 대상·방법이 확정되고, 이관 후 건수·정합성 검증 기준이 정의되었는가
- 롤백(원복) 절차와 롤백 판단 기준이 명문화되었는가 (예: 특정 시각까지 핵심기능 미정상 시 원복)
- 백업이 컷오버 직전에 완료·검증되었는가
- 비상 연락망과 **장애 대응 책임자(의사결정자)**가 지정되었는가
- 오픈 직후 모니터링 대상 지표(에러율·응답시간·핵심 거래 성공률)와 임계치가 정해졌는가
- 발주사·운영(SM)·협력사 간 오픈 판정 회의 주체와 시점이 합의되었는가
- 사용자 공지·콜센터 대응·점검 안내(필요 시)가 준비되었는가
이 체크리스트가 없으면, 오픈 당일 문제가 터졌을 때 "되돌릴까 말까"를 그 자리에서 즉흥적으로 다투게 됩니다. 그 1분이 손실을 키웁니다.
확대
오픈의 성패는 당일의 순발력이 아니라 오픈 전에 정해 둔 것으로 갈립니다. 위 그림처럼 왼쪽의 사전 합의 항목이 채워져 있어야, 오른쪽의 "롤백할까 말까"를 임계 시각과 책임자라는 미리 정한 기준으로 — 즉흥이 아니라 절차로 — 판단할 수 있습니다.
직접 해보기 — 단계·산출물·게이트 매핑
아래 산출물 6개를 (1) 어느 단계의 산출물인지, (2) 그 단계의 검수 게이트가 무엇인지 짝지어 보세요. 정답은 ObserveBlock에 있습니다.
1. 요구사항정의서
2. 컷오버 계획서(롤백 기준 포함)
3. 사업수행계획서·WBS
4. DB설계서·인터페이스정의서
5. UAT(인수 테스트) 결과서
6. 운영인수인계서·운영 매뉴얼
판단 직관: "이 문서는 무엇을 확정하려고 만든 것인가"를 물으면 단계가 보입니다. '무엇을 만들지'는 분석, '어떻게 만들지'는 설계, '안전하게 전환됐는지'는 이행입니다.
배치: 단계 / 산출물 / 검수 게이트- 1. 요구사항정의서 → 분석 단계 / 게이트: 발주사의 요구사항 검토·승인(이후 요구사항 동결)
- 2. 컷오버 계획서 → 이행/오픈 단계 / 게이트: 오픈 판정·롤백 미발동(데이터 이관·정합성 검증 통과)
- 3. 사업수행계획서·WBS → 착수 단계 / 게이트: 발주사의 수행계획 승인
- 4. DB설계서·인터페이스정의서 → 설계 단계 / 게이트: 설계 검토·승인
- 5. UAT 결과서 → 테스트 단계 / 게이트: UAT 통과·결함 조치 확인(검수의 직전 관문)
- 6. 운영인수인계서·운영 매뉴얼 → 운영전환 단계 / 게이트: SM 조직의 인수 완료 확인
- 핵심 감각: 산출물은 "무엇을 확정/검증하려는가"로 단계가 정해지고, 그 단계는 발주사 또는 SM의 승인(게이트)으로만 닫힌다
현장에서 자주 보는 함정
증상: UAT도 통과했고 검수확인서도 받았습니다. 그런데 오픈하자마자 실사용자·실부하에서 결함이 쏟아지고, 프로젝트 팀은 "검수 끝났으니 우리 일 끝"이라 하고 운영팀은 "우린 인수 못 받았다"며 서로를 가리킵니다.
원인: 두 가지가 빠졌습니다. (1) 안정화 기간과 하자보수 범위를 계약·계획에 명확히 하지 않았습니다. 검수는 '받아들임'이지 '이후 무결'을 뜻하지 않는데, 안정화·하자보수 책임이 흐릿하면 오픈 직후 공백이 생깁니다. (2) **운영전환(인수인계)**이 산출물·일정으로 설계되지 않아, SM 조직이 시스템을 넘겨받을 준비가 안 된 상태에서 프로젝트만 빠져나갔습니다.
해결 방향(이 트랙에서 깊어짐):
- 검수와 별개로 **안정화 기간(예: 오픈 후 N주)**을 계획에 명시하고, 그 기간 동안 프로젝트 팀이 초기 인시던트를 책임진다는 것을 합의합니다.
- 하자보수 의무 기간(검수 후 일정 기간 무상 결함 수정)을 계약 기준으로 확인하고, '하자'와 '신규 요구(변경)'를 구분하는 기준을 정해 둡니다.
- 운영전환을 산출물(운영인수인계서·운영 매뉴얼·장애대응 절차)과 일정으로 설계해, 안정화가 끝나기 전에 SM이 실제로 운영할 수 있게 만듭니다.
- 오픈 전부터 SM 담당자를 안정화에 참여시켜 '넘겨받을 사람'이 미리 시스템을 익히게 합니다.
검수는 끝이 아니라 '운영으로 넘어가는 다리의 입구'입니다. 그 다리(안정화·하자보수·운영전환)를 설계해 두지 않으면, 잘 만든 시스템도 오픈 직후 무방비 상태가 됩니다.
심화 — 오픈일은 뒤로 밀리지 않는다
심화: 단계 압축의 역학 — 지연은 사라지지 않고 테스트가 흡수한다
본문의 생애주기는 각 단계가 제 기간을 가진다고 가정합니다. 그러나 현장의 오픈일은 기술 일정이 아니라 정치 일정인 경우가 많습니다 — 공공은 회계연도와 '연내 오픈' 보고에, 기업은 경영진 발표와 대외 공지에 날짜가 박힙니다. 앞 단계가 밀려도 이 날짜는 움직이지 않기 때문에, 지연은 사라지는 것이 아니라 뒤 단계로 전가됩니다.
- 아코디언 현상: 분석이 한 달 밀리면 설계가, 설계가 밀리면 개발이 줄어들고, 최종적으로 가장 뒤에 있는 테스트·안정화가 모든 지연을 흡수합니다. 계획서에 6주였던 통합테스트가 2주가 되고, UAT가 하루짜리 시연회로 대체됩니다. 역설적으로 결함을 걸러야 할 단계가 지연의 흡수원이 되는 것입니다 — 그래서 오픈 직후 장애 폭증은 운이 아니라 몇 달 전 지연의 예정된 청구서입니다.
- 승인 지연의 비대칭: 게이트는 발주사의 승인으로 닫히는데, 발주사의 검토 기간은 일정표에 없는 경우가 많습니다. 요구사항 검토에 발주사가 3주를 쓰든 승인권자가 휴가를 가든, 전체 기한은 그대로라 그 3주는 고스란히 수행사의 개발 기간에서 빠집니다. 수행계획서에 발주사 검토 기한(예: 산출물 접수 후 10영업일)과 초과 시 일정 순연 조항을 넣는 것이 몇 안 되는 방어선입니다.
- 소급 산출물: 단계가 압축되면 산출물이 뒤로 밀려, 감리·검수 대응용으로 설계서를 개발이 끝난 뒤에 쓰는 일이 생깁니다. 게이트는 서류상 순서대로 통과한 것으로 남지만 문서와 시스템은 다른 물건이 되고, 그 괴리의 청구서는 운영전환 때 SM 조직이 받습니다 — 문서를 믿고 인수한 시스템이 문서대로 동작하지 않는 것입니다.
규모별로 모양이 다릅니다. 공공 대형사업은 감리가 단계 산출물을 확인하므로 압축이 '소급 문서화'라는 형태로 숨고, 민간·중소 사업은 게이트 자체를 건너뛰는 형태로 나타납니다. 어느 쪽이든 관리자가 봐야 할 신호는 같습니다 — 계획 대비 실제 단계 기간의 비율입니다. 앞 단계들이 계획을 초과했는데 오픈일이 그대로라면, 그 차이만큼 테스트 어딘가가 이미 잘려 나가 있습니다.
상황: 그룹 계열사 차세대 프로젝트. 오픈일은 사업 초기에 회장 보고로 확정돼 사보에까지 실렸습니다. 그런데 현업 부서 간 이견으로 요구사항 확정이 두 달 늦어졌고, PM이 일정 조정을 꺼내자 발주사 PM의 답은 "오픈일은 이미 위에 보고된 날짜입니다. 방법을 찾아 주세요"였습니다. 수행사는 설계·개발을 병행하는 것으로 한 달을 줄이고, 나머지 한 달은 통합테스트(6주→2주)와 UAT(2주→반나절 시연회)에서 잘랐습니다. 서류상 테스트결과서는 '통과'로 제출·승인됐습니다. 오픈 첫 주에 정산 배치 오류로 대금 지급이 이틀 멈추는 사고가 났고, 책임 공방에서 발주사는 "테스트 통과라고 보고하지 않았느냐"고 물었습니다. 계획 케이스 1,800건 중 실제 수행된 것은 600건이었지만, 그 숫자는 어느 보고서에도 없었습니다.
원인: 지연을 흡수할 공식 메커니즘이 없었기 때문입니다. 오픈일 변경은 경영 보고를 뒤집는 일이고 계약 변경은 아무도 먼저 꺼내지 않으니, 조직은 침묵 속에서 가장 저항이 적은 곳 — 테스트 — 을 비공식 버퍼로 썼습니다. 그리고 압축된 테스트를 '축소된 테스트'로 보고하는 대신 '통과한 테스트'로 보고하면서, 리스크가 의사결정권자에게 전달될 마지막 기회마저 사라졌습니다.
진단: 단계별 계획 기간과 실제 기간을 나란히 놓으면 지연이 어디서 흡수됐는지 보입니다 — 앞 단계 합계가 두 달 초과인데 오픈일이 그대로라면 그 두 달은 반드시 어딘가에서 잘렸습니다. 확정은 테스트 실적으로 합니다. 계획 케이스 수 대비 수행 케이스 수, 결함 발견 곡선(수행이 줄면 발견도 급감)을 보면 '통과'라는 결론과 무관하게 검증의 실제 규모가 정량화됩니다.
해결: 사고 후에는 미수행 케이스 1,200건을 우선순위화해 안정화 기간에 소급 수행하는 계획부터 세웁니다. 구조적으로는 지연이 발생한 시점에 오픈일 조정과 범위 조정을 공식 안건으로 올리는 것이 유일한 정직한 경로입니다 — 전체 연기가 불가능하면 단계적 오픈(핵심 기능 먼저, 잔여는 2차)으로 범위를 잘라 테스트 기간을 지킵니다. 그리고 수행계획서에 테스트 최소 기간을 '압축 불가 항목'으로 명시하고, 압축이 강행되면 축소된 검증 범위를 리스크로 문서에 남겨 발주사가 알고 결정하게 만듭니다. 오픈일을 지키는 방법이 없었던 것이 아니라, "이 날짜를 지키려면 무엇을 포기하는지"를 아무도 위에 말하지 않은 것 — 그것이 이 사고의 본질입니다.
한국 SI 현장에서 신입·주니어는 보통 개발 단계에 투입되지만, 한 단계 위로 올라가는 사람은 **"지금 우리가 어느 단계에 있고, 무엇으로 이 단계를 닫는가"**를 항상 의식합니다. PM·PL·PMO 자리로 가면 일의 90%가 단계·산출물·검수·일정의 통제입니다 — 코드를 직접 짜기보다, 협력사(하도급)가 만든 산출물이 게이트를 통과할 수준인지 판단하고, 발주사 검수를 끌어내는 일입니다.
이때 단계 흐름을 모르면 흔한 사고가 납니다. 분석 검수 후 들어온 요구를 구두로 받아 주다 범위가 무한정 늘어나거나(범위 증식), 검수확인서에 가볍게 서명했다가 이후 결함을 모두 떠안거나, 컷오버를 롤백 계획 없이 진행했다가 오픈 사고로 신뢰를 잃습니다. 산출물과 검수는 단순 서류 작업이 아니라 책임·대금·일정의 경계선이며, 그 경계를 설계하고 지키는 것이 관리 직무의 본질입니다.
그래서 SI 단계 지도는 개발자에서 관리자로 넘어가는 길목의 공용어입니다. 기술을 아는 관리자는 협력사 산출물의 허술함을 알아보고, 발주사 앞에서 "이 단계는 무엇으로 닫혔다"를 근거로 말할 수 있습니다.
실전 랩으로 손에 익히기: SI 생애주기 실습 — 제안~오픈·안정화 단계별 산출물·게이트·리스크를 설계합니다.
관련 모듈로 더 깊이:
- SI·SM·SaaS·MSP 구조 — 이 생애주기가 굴러가는 SI·SM 산업 구조의 큰 그림
- SM 운영·유지보수·하자보수 — 오픈·검수 이후 운영(SM)으로 넘어가 시스템이 어떻게 유지되는지
- 계약·과업범위·M/M·검수 — 단계별 검수·산출물이 계약·과업범위·정산과 어떻게 맞물리는지
다음 모듈에서는 검수 이후의 세계 — SM(운영)으로 넘어가 유지보수와 하자보수가 어떻게 굴러가는지, 운영 조직이 시스템을 어떤 절차로 인수해 일상 운영과 인시던트·요청·변경을 처리하는지를 다룹니다.