SI 프로젝트 관리

“왜 SI 프로젝트는 항상 막판에 터질까?”

현업 PM이 겪은 SI 프로젝트 5대 리스크와 현실적인 대응 전략

SI 프로젝트는 대부분 비슷하게 시작합니다.

제안 단계에서는 일정도 맞아 보이고, 인력도 충분해 보입니다.아키텍처도 그럴듯하고, 고객도 “잘 부탁드립니다”라고 이야기합니다.

그런데 개발이 50%쯤 넘어가는 시점부터 분위기가 바뀝니다.

• 요구사항이 계속 추가되고

• 인터페이스 일정은 미뤄지고

• 고객사는 부서별로 말이 달라지고

• 핵심 개발자는 번아웃 오고

• 테스트 일정은 압축되기 시작합니다.

그리고 오픈 한 달 전부터 프로젝트는 사실상 전쟁터가 됩니다.

현장에서 PM을 해본 사람들은 압니다.SI 프로젝트는 기술보다도 “리스크 관리” 싸움이라는 것을요.

실제 프로젝트가 망가지는 패턴은 대부분 정해져 있습니다.이번 글에서는 현장에서 가장 많이 터지는 SI 프로젝트 리스크 5가지와, PM 입장에서 실제로 효과 있었던 대응 방법들을 정리해보겠습니다.

1. 요구사항(Scope) 리스크

프로젝트를 가장 많이 망가뜨리는 원인

SI 프로젝트에서 가장 위험한 건 기술이 아닙니다.대부분은 요구사항이 프로젝트를 무너뜨립니다.

초기 RFP는 보통 추상적입니다.문제는 그걸 각자 다르게 이해한 상태로 프로젝트가 시작된다는 점입니다.

고객은 “당연히 될 줄 알았다”고 생각하고,개발팀은 “명세에 없었다”고 이야기합니다.

이 간극이 후반부에 폭발합니다.

① Scope Creep — 조금씩 추가되다가 프로젝트가 무너진다

현업에서는 이런 말 정말 많이 나옵니다.

“이건 그냥 간단한 기능인데 같이 넣어주시면 안 되나요?”

문제는 대부분 간단하지 않다는 겁니다.

화면 하나 추가했는데:

• 권한 구조 바뀌고

• 배치 수정 들어가고

• API 영향 생기고

• 통계 로직 다시 맞춰야 하고

• 테스트 케이스 전체 수정되는 경우가 많습니다.

초반에 PM이 관계 유지하려고 구두로 받아주기 시작하면후반에는 감당이 안 됩니다.

현장에서는 이걸 “눈덩이 굴러간다”고 표현합니다.

② 명세가 모호하면 결국 막판에 뒤집힌다

텍스트 중심 요구사항 정의서는 위험합니다.

고객은 머릿속에 이미 완성된 화면을 상상하고 있는데,개발자는 문서 기준으로 최소 구현만 합니다.

결국 UAT 단계에서 반드시 나오는 말이 있습니다.

“제가 원한 건 이런 느낌이 아닌데요?”

이 시점에 UI/UX 방향이 틀어지면프로젝트는 거의 재개발 수준으로 들어갑니다.

PM 대응 포인트

현장에서 요구사항 변경을 막는 건 사실상 불가능합니다.중요한 건 “통제되지 않은 변경”을 막는 겁니다.

실무에서는 아래 3개를 반드시 잡아야 합니다.

• 모든 변경 요청 서면화

• 영향도 분석 후 승인

• 일정/비용 Trade-off 공식화

특히 중요한 건 이겁니다.

“추가 기능은 가능하지만 일정 또는 범위 조정이 필요합니다.”

이 말을 공식적으로 남기지 않으면나중에는 전부 수행사 책임으로 돌아옵니다.

2. 기술 및 인프라 리스크

화면은 나오는데 시스템은 안 돌아간다

제안서 단계 아키텍처는 늘 완벽해 보입니다.

• MSA

• 클라우드 네이티브

• 실시간 연계

• 대용량 처리

• AI 연동

하지만 실제 운영 환경은 다릅니다.

개발 후반부에 가면 기술 부채가 한꺼번에 터집니다.

① 기술 검증 없이 신기술 넣으면 반드시 사고 난다

현장에서 자주 보는 패턴입니다.

• 아무도 안 써본 프레임워크 도입

• 레퍼런스 없는 구조 적용

• 운영 경험 없는 오픈소스 사용

초반에는 다 좋아 보입니다.

문제는 통합 테스트부터입니다.

• 성능 안 나오고

• 메모리 터지고

• 트랜잭션 꼬이고

• 장애 재현도 안 됩니다.

이 상태가 되면 프로젝트는 “개발”이 아니라 “디버깅 조직”으로 변합니다.

② 인터페이스 일정은 거의 항상 밀린다

SI 프로젝트는 결국 연계 프로젝트입니다.

ERP, 그룹웨어, 외부기관, PG, 레거시 시스템 등연동 안 되는 게 더 드뭅니다.

문제는 연계 기관 일정은 대부분 우리 통제가 안 된다는 겁니다.

현장에서 실제 많이 나오는 상황:

• API 명세 계속 변경

• 테스트 서버 안 열림

• 담당자 휴가

• 보안 승인 대기

• 방화벽 미오픈

결국 개발팀은 목(Mock) 데이터로만 개발합니다.

그리고 막판 실제 연동에서 에러가 폭발합니다.

PM 대응 포인트

현업 PM들은 인터페이스를 “별도의 프로젝트”처럼 관리합니다.

실제로 중요한 건:

• 인터페이스 정의 조기 확정

• 연계 담당자 연락망 확보

• 주간 연계 회의 운영

• Sandbox 일정 강제

• 방화벽 일정 선반영

입니다.

특히 인터페이스는 늦게 잡을수록 복구가 안 됩니다.

3. 일정 및 인력 리스크

결국 프로젝트는 사람이 한다

SI는 결국 사람 사업입니다.

아무리 프로세스가 좋아도핵심 인력이 흔들리면 프로젝트도 흔들립니다.

① Key-Man 이탈은 생각보다 치명적이다

프로젝트에서 꼭 있습니다.

• 구조 다 아는 PL

• 배치 혼자 만든 개발자

• 인터페이스 핵심 담당자

이 사람이 빠지는 순간 프로젝트가 멈춥니다.

문제는 대체 인력 투입해도 바로 복구가 안 된다는 점입니다.

보통:

• 업무 파악

• 소스 분석

• 도메인 이해

하는 데만 최소 몇 주가 걸립니다.

현장에서는 이 시기를 “공백기”라고 부릅니다.

② 일정은 대부분 처음부터 무리다

솔직히 말하면 SI 일정은 상당수가 영업 일정입니다.

고객 오픈 일정 기준으로 역산됩니다.

그러다 보니:

• 테스트 압축

• 설계 생략

• 문서 후행

• 야근 상시화

가 반복됩니다.

그리고 일정 밀리면 흔히 하는 대응이 있습니다.

“인력 더 넣죠.”

그런데 실제로는 더 느려집니다.

기존 인력이 신규 인력 교육하느라 생산성이 떨어지기 때문입니다.

브룩스 법칙이 현장에서 계속 반복되는 이유입니다.

PM 대응 포인트

실제 현장에서는 아래를 반드시 관리해야 합니다.

• 특정 인력 의존도 제거

• 코드 리뷰 강제

• 문서 최소 기준 유지

• 주기적 설계 공유

• 업무 백업 체계 확보

특히 “저 사람 없으면 안 된다” 상태는이미 리스크가 발생한 상태라고 봐야 합니다.

4. 커뮤니케이션 리스크

기술보다 어려운 건 사람 조율이다

프로젝트가 기술적으로 성공해도고객 만족 못 얻으면 실패입니다.

특히 대형 SI는 이해관계자가 너무 많습니다.

• 현업 부서

• IT 부서

• 보안팀

• 인프라팀

• 운영팀

• 경영진

각자 원하는 게 다 다릅니다.

① 고객 내부 의견 충돌은 반드시 발생한다

실제 현장에서 흔합니다.

영업팀 요구와 관리팀 요구가 다르고,현업과 IT 기준이 다르고,본사와 지점 요구가 다릅니다.

문제는 고객 내부 이슈인데결국 일정 압박은 수행사가 받는다는 점입니다.

② 하도급 구조에서는 책임 경계가 흐려진다

대형 프로젝트일수록:

• 퍼블리싱

• 프론트

• 백엔드

• 인터페이스

• 인프라

업체가 다 따로 움직입니다.

이 상태에서 R&R 불명확하면프로젝트는 금방 책임 공방으로 갑니다.

현장에서 가장 위험한 말이 있습니다.

“그건 우리 범위 아닌데요?”

이 말 나오기 시작하면 일정이 급격히 밀립니다.

③ 실제 가장 무서운 건 CEO 리스크다

현장에서 PM들이 제일 무서워하는 건사실 기술 문제가 아닙니다.

경영진 변수입니다.

대표적인 사례:

6개월 동안 설계하고 개발했는데임원 보고 자리에서 갑자기:

“요즘은 AI 들어가야 하는 거 아닌가요?”

한마디 나오면 방향이 바뀝니다.

실무진은 이미 늦었다는 걸 압니다.

하지만 프로젝트는 다시 흔들립니다.

반대로 수행사 경영진 리스크도 있습니다.

• 무리한 수주

• 비현실 일정

• 저가 계약

• 무상 기능 약속

현장은 시작부터 적자 구조로 들어갑니다.

PM 대응 포인트

경영진 리스크는 “조기 노출” 말고 답이 없습니다.

그래서 중요한 게:

• 운영위원회(Steering Committee)

• 정기 임원 보고

• 프로토타입 조기 공개

• 중간 시연 리뷰

입니다.

경영진은 마지막에 처음 보면 거의 반드시 방향 수정합니다.

5. 테스트 및 데이터 이관 리스크

프로젝트는 오픈 직전에 진짜 위험해진다

후반부 화면 나오기 시작하면프로젝트가 거의 끝난 것처럼 보입니다.

하지만 실제로 가장 위험한 시점은 그때부터입니다.

① 테스트를 줄이기 시작하면 이미 위험 신호다

일정 밀리면 가장 먼저 줄어드는 게 테스트입니다.

현장에서 자주 발생하는 상황:

• 단위 테스트 생략

• 통합 테스트 압축

• Happy Path만 확인

• 장애 시나리오 미검증

이 상태로 오픈하면 운영 첫날 사고가 납니다.

특히:

• 동시 접속

• 배치 충돌

• 데이터 정합성

• 권한 오류

는 운영에서 처음 터지는 경우가 많습니다.

② 데이터 이관은 거의 항상 예상보다 어렵다

레거시 데이터는 대부분 깨져 있습니다.

• NULL 데이터

• 코드값 불일치

• 중복 데이터

• 날짜 포맷 오류

• 정합성 붕괴

실제 이관 당일에는 예상 못한 에러가 계속 발생합니다.

그래서 현업 PM들은 데이터 이관 리허설을 여러 번 돌립니다.

실제 Cut-Over는 “실전”이 아니라“리허설 반복 결과”여야 합니다.

결론

SI 프로젝트는 결국 리스크 관리 프로젝트다

현장에서 오래 버틴 PM들은 공통적으로 이야기합니다.

프로젝트는 문제가 없는 게 아니라,문제가 터져도 안 무너지게 만드는 게 중요하다고.

SI 프로젝트에서 중요한 건 완벽함이 아닙니다.

• 리스크를 빨리 발견하고

• 숨기지 않고 공유하고

• 조기에 방향 수정하고

• 의사결정을 끌어내는 것

이게 프로젝트 생존력입니다.

현업에서 정말 위험한 프로젝트는문제가 있는 프로젝트가 아니라문제를 아무도 말하지 않는 프로젝트입니다.

그리고 대부분의 프로젝트는망가질 때 갑자기 망가지지 않습니다.

초반부터 계속 신호를 보내고 있었습니다.

결론:승리하는 SI 프로젝트를 위한 'PM 리스크 관리 3대 원칙'

위에서 언급한 5대 영역의 리스크를 완벽하게 차단하는 것은 불가능합니다. 리스크 관리의 본질은 '위험이 안 터지게 막는 것'이 아니라, '위험이 터졌을 때 시스템이 붕괴하지 않도록 충격파를 관리하는 것'입니다. 이를 위해 모든 프로젝트 리더들이 가슴에 새겨야 할 3가지 원칙이 있습니다.

[리스크 관리의 핵심 사이클]

정기적인 위험 식별(WBS 기반)

  ▼

  투명한 시각화(Red / Yellow / Green)

  ▼

  신속한 에스컬레이션(공식 채널 활용)

첫째, 시각화하고 투명하게 공유하라(보여주기식 Green 보고의 종말)

많은 프로젝트에서 주간 보고 시점까지 위험을 숨기다가, 더 이상 손쓸 수 없을 때 'Red' 상태를 터트립니다. 위험 징후가 보이면 즉시 주간 보고서와 대시보드에 반영해야 합니다. 문제가 조기에 공유되어야 본사 차원의 기술 지원을 받거나 고객사와 범위 조정을 협상할 카드를 쥘 수 있습니다.

둘째, 변경 관리는 감정이 아니라 '프로세스'로 하라

고객과의 좋은 관계는 요구사항을 다 들어준다고 유지되지 않습니다. 오히려 부실한 품질로 오픈했을 때 관계가 완전히 파탄 납니다. 모든 요구사항 변경은 서면화하고, 추가 비용과 일정 영향도를 명확히 계산하여 시스템(CCB)을 통해 승인을 받는 문화를 정착시켜야 합니다.

셋째, 완벽한 오픈보다 '안전한 단계적 오픈(Phased Rollout)'을 고려하라

빅뱅(Big-Bang) 방식의 전사 동시 오픈은 리스크가 너무 큽니다. 핵심 모듈이나 특정 지점, 특정 사용자 그룹을 대상으로 먼저 시스템을 개통(Pilot Open)하여 안정성을 검증한 후, 순차적으로 확대 적용하는 아키텍처 및 일정 전략을 수립하는 것이 현명합니다.

SI 프로젝트는 거친 바다를 항해하는 것과 같습니다. 언제 폭풍우가 몰아칠지 모르지만, 신뢰할 수 있는 지도(체크리스트)와 단단한 내성(리스크 관리 프로세스)을 갖추고 있다면 어떤 프로젝트든 무사히 납기라는 목적지에 배를 정박시킬 수 있을 것입니다. 지금 진행 중인 여러분의 프로젝트는 안전합니까?

Daniel(L)