첫 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 담당자를 안정화에 참여시켜 '넘겨받을 사람'이 미리 시스템을 익히게 합니다.
검수는 끝이 아니라 '운영으로 넘어가는 다리의 입구'입니다. 그 다리(안정화·하자보수·운영전환)를 설계해 두지 않으면, 잘 만든 시스템도 오픈 직후 무방비 상태가 됩니다.
한국 SI 현장에서 신입·주니어는 보통 개발 단계에 투입되지만, 한 단계 위로 올라가는 사람은 **"지금 우리가 어느 단계에 있고, 무엇으로 이 단계를 닫는가"**를 항상 의식합니다. PM·PL·PMO 자리로 가면 일의 90%가 단계·산출물·검수·일정의 통제입니다 — 코드를 직접 짜기보다, 협력사(하도급)가 만든 산출물이 게이트를 통과할 수준인지 판단하고, 발주사 검수를 끌어내는 일입니다.
이때 단계 흐름을 모르면 흔한 사고가 납니다. 분석 검수 후 들어온 요구를 구두로 받아 주다 범위가 무한정 늘어나거나(범위 증식), 검수확인서에 가볍게 서명했다가 이후 결함을 모두 떠안거나, 컷오버를 롤백 계획 없이 진행했다가 오픈 사고로 신뢰를 잃습니다. 산출물과 검수는 단순 서류 작업이 아니라 책임·대금·일정의 경계선이며, 그 경계를 설계하고 지키는 것이 관리 직무의 본질입니다.
그래서 SI 단계 지도는 개발자에서 관리자로 넘어가는 길목의 공용어입니다. 기술을 아는 관리자는 협력사 산출물의 허술함을 알아보고, 발주사 앞에서 "이 단계는 무엇으로 닫혔다"를 근거로 말할 수 있습니다.
관련 모듈로 더 깊이:
- SI·SM·SaaS·MSP 구조 — 이 생애주기가 굴러가는 SI·SM 산업 구조의 큰 그림
- SM 운영·유지보수·하자보수 — 오픈·검수 이후 운영(SM)으로 넘어가 시스템이 어떻게 유지되는지
- 계약·과업범위·M/M·검수 — 단계별 검수·산출물이 계약·과업범위·정산과 어떻게 맞물리는지
다음 모듈에서는 검수 이후의 세계 — SM(운영)으로 넘어가 유지보수와 하자보수가 어떻게 굴러가는지, 운영 조직이 시스템을 어떤 절차로 인수해 일상 운영과 인시던트·요청·변경을 처리하는지를 다룹니다.