국내 SI 프로젝트 실패 패턴 7가지: 현장에서 직접 목격한 것들

Executive Summary - Topic: 국내 SI 프로젝트 반복 실패 메커니즘 - Target: CTO, IT 구매 담당자, 프로젝트 관리자, 발주처 임원 - TL;DR 1: 실패의 80%는 착수 단계에서 예측 가능하다 - TL;DR 2: 레거시 연동 공수 과소평가가 단일 최대 원인 - TL;DR 3: 납기 압박보다 범위 통제 실패가 더 치명적이다

이 글은 불편한 이야기부터 시작합니다.

국내 SI 프로젝트 실패율은 공개된 통계만으로도 40~60%를 웃돕니다. 납기를 지키지 못하거나, 기능이 반만 구현되거나, 시스템이 오픈 후 3개월 안에 장애를 일으키거나. 어떤 형태로든 "이렇게 되면 안 됐는데"라는 결말을 맞이하는 프로젝트가 절반에 가깝습니다.

우리가 직접 참여하거나 사후에 들여다본 프로젝트들을 돌아보면, 원인이 다양한 것 같지만 결국 같은 패턴이 반복됩니다. 오늘은 그 패턴을 정리합니다. 업계 내부에서는 다 알고 있지만, 왜 반복되는지까지 솔직하게 이야기해보려 합니다.

1. 요구사항이 "확정"됐지만 실제로는 확정되지 않았다

계약서에 사인이 끝나고 착수 미팅을 했는데, 현업 담당자가 처음 보는 요건을 꺼내는 상황. 저희가 경험한 것만 해도 손에 꼽기 힘들 정도입니다.

"저희 팀에서 이 기능도 꼭 들어가야 한다고 했는데요?" 라는 말이 착수 2주 만에 나올 때, 이미 그 프로젝트의 예산과 일정은 흔들리기 시작합니다.

왜 이게 반복되나: 구매 결정권자(임원, 구매팀)와 실제 사용자(현업 팀장, 담당자) 사이에 요구사항 검증 루프가 없습니다. 임원은 큰 그림을 그리고 승인하지만, 현업은 자신의 일상 업무를 기준으로 요건을 생각합니다. 이 두 집합이 계약 전에 교차 검증되지 않으면, 착수 후에 반드시 충돌이 발생합니다.

계약 전 워크숍 1회가 착수 후 3개월 분쟁을 막습니다. 구체적으로:

1[잘못된 흐름]
2임원 결정 → RFP 배포 → 제안서 제출 → 계약 → 착수 → 현업 인터뷰 → "이게 아닌데요?"
3 
4[권장 흐름]
5임원 결정 → 현업 워크숍(2회, 각 3시간) → 요건 목록 작성 → 현업 확인 서명
6→ RFP 배포 → 제안서 제출 → 계약 → 착수

계약 전 워크숍이 낯설게 느껴지는 발주처도 있습니다. 하지만 저희는 이 단계 없이는 착수를 진행하지 않습니다. 그 이유는 단순합니다. 나중에 수습하는 비용이 훨씬 크기 때문입니다.

2. 레거시 연동 공수를 항상 과소평가한다

"API가 있으니까 빨리 될 거야." 이 말이 가장 위험한 말입니다.

현장에서 실제로 마주치는 상황:

• 내부 시스템에 API가 있긴 한데, 문서가 3년 전 기준이다.
• 테스트 환경이 없어서 프로덕션에서 직접 테스트해야 한다.
• 담당자가 퇴사해서 API 스펙을 아는 사람이 팀 내에 없다.
• API가 있다고 했는데 알고 보니 내부 전용 SOAP 서비스다.
• 응답 형식이 케이스마다 달라서 파싱 로직이 분기 처리로 가득해진다.

이런 상황이 프로젝트 3건 중 2건에서 발생합니다. 예외가 아니라 기본값입니다.

권장 공수 기준:

Timeware 접근: 계약 전 1주일 연동 PoC를 선행합니다. 실제로 연결해보고 발생하는 이슈를 파악한 다음 공수를 산정합니다. 이 1주일이 프로젝트 전체를 구합니다.

3. 중간 검수 없는 폭포수 개발

3개월 개발 → UAT → 오픈. 이 구조에서 3개월치 오해가 한 번에 터집니다.

UAT에서 "이건 우리가 요청한 게 아닌데요"라는 말을 들으면, 이미 모든 게 늦었습니다. 재개발 비용은 원래 개발 비용보다 훨씬 비쌉니다. 맥락이 끊겼고, 코드가 얽혔고, 일정이 고정돼 있기 때문입니다.

대안은 단순합니다: 2~3주 단위 데모 + 현업 확인 서명.

데모는 완성도가 낮아도 됩니다. 흐름이 보이면 됩니다. 현업이 직접 보고 "이거 맞아요" 또는 "이건 아닌데요"를 말할 수 있는 기회를 주기적으로 만드는 것이 핵심입니다.

이 방식의 실제 효과: UAT에서 발견되는 주요 이슈가 70% 이상 감소합니다. 납기는 같아도 리스크가 분산됩니다.

4. 인수인계 문서를 "나중에" 쓴다

납기 압박 속에서 인수인계 문서는 항상 뒤로 밀립니다. "코딩 다 끝나고 쓸게요." 그리고 코딩이 끝날 즈음에는 오픈 준비로 바쁘고, 오픈이 끝나면 팀이 해체됩니다.

결과: 6개월 후 첫 장애가 발생했을 때, 아무도 이 시스템이 왜 이렇게 설계됐는지 모릅니다.

Timeware 정책:

1. 코드 커밋마다 변경 이유를 기록합니다 (커밋 메시지가 fix(login): null pointer 수준이면 안 됩니다)
2. 매 스프린트 종료 시 운영 노트를 작성합니다 (주요 설계 결정, 알려진 제약사항)
3. 특이 케이스 처리 로직에는 반드시 인라인 주석을 추가합니다
4. 환경 구성 정보는 README가 아닌 운영 위키에 실시간 업데이트합니다

문서화는 개발의 마지막 단계가 아니라 중간 과정입니다. 이를 습관으로 만들면 추가 비용이 거의 없습니다.

5. 성능 테스트를 오픈 1주일 전에 한다

부하 테스트를 오픈 직전에 하면, 문제를 발견해도 고칠 시간이 없습니다.

실제로 이런 일이 있었습니다. 금융 계열 고객사의 시스템이 오픈 3일 전 부하 테스트에서 300 동시 사용자에서 응답이 15초를 넘었습니다. 원인은 N+1 쿼리와 인덱스 미적용. 수정하는 데 이틀이 걸렸고, 오픈은 일주일 연기됐습니다.

권장 타임라인:

1오픈 -8주: 스테이징 환경 구성 완료
2오픈 -6주: 초기 부하 테스트 (프로덕션 트래픽의 50%)
3오픈 -4주: 풀 부하 테스트 (프로덕션 트래픽의 150%)
4오픈 -2주: 최종 안정성 테스트 + 장애 복구 시나리오 검증
5오픈 -1주: 동결 기간 (기능 변경 금지)

6. 보안 검토를 체크리스트로만 한다

"SQL Injection 방어했나요? 네." "XSS 막았나요? 네." 체크박스에 체크했습니다. 이 수준의 보안 검토는 실제로 취약합니다.

OWASP Top 10 기반 자동화 스캔은 기본이고, 침투 테스트는 별도 일정으로 두어야 합니다. 특히 금융, 의료, 통신 도메인은 실제 외부 보안 전문가의 화이트박스 테스트가 필요합니다.

체크리스트는 빠진 게 없는지 확인하는 도구지, 실제 취약점을 찾는 도구가 아닙니다.

7. 오픈 이후 운영 인수 계획이 없다

개발팀이 오픈 후 3개월간 운영 문의를 받는 구조. 개발팀도, 고객사도, 모두 불행합니다.

개발팀은 다음 프로젝트를 병행하면서 이 시스템의 장애 알림을 받습니다. 고객사는 개발팀이 언제 빠질지 몰라 불안합니다. 명확한 종료선이 없으면 양쪽 다 소진됩니다.

명확한 기준:

1오픈 후 D+1: 실시간 모니터링 공동 운영 시작
2D+7: 1차 안정화 리포트 제출
3D+14: 운영 매뉴얼 + 장애 대응 플로우 전달
4D+21: 담당자 2인 이상 교육 완료 확인
5D+30: 공식 인수인계 서명
6이후: 유지보수 계약 또는 SLA 기반 운영으로 전환

이 단계를 계약서에 명시하면, 나중에 생기는 분쟁의 80%가 사라집니다.

종합 대응 테이블

마치며

실패 패턴은 사실 공개된 비밀입니다. 업계에서 10년 이상 일한 분들이라면 이 중 절반은 이미 알고 있을 겁니다. 그런데 왜 반복될까요?

납기 압박과 비용 압박 속에서, 원칙을 지키는 게 어렵기 때문입니다. "이번엔 시간이 없으니까 PoC는 생략하자." "문서는 나중에 써도 되지." 이런 결정들이 쌓여서 실패가 됩니다.

저희가 이 글을 쓰는 이유는, 그 압박 속에서 반복적으로 확인한 것들을 기록으로 남기기 위해서입니다. 이 글을 읽고 발주 계획을 세우시는 분이라면, 적어도 1번과 2번은 꼭 체크해보시길 권합니다.

관련 글

• B2B 운영 자동화 경계 설정 가이드
• Timeware 프로젝트 접근 방식

FAQ

Q. SI 프로젝트에서 가장 많이 발생하는 실패 원인은 무엇인가요? A. 레거시 시스템 연동 공수 과소평가와 요구사항 미확정이 전체 실패의 60% 이상을 차지합니다. 두 원인 모두 착수 전 단계에서 예방 가능합니다.

Q. SI 프로젝트 실패를 방지하는 핵심 방법은 무엇인가요? A. 계약 전 현업 워크숍, 착수 전 연동 PoC, 2주 단위 데모를 실행하는 것만으로 주요 실패 리스크의 80%를 제거할 수 있습니다.

Q. 레거시 연동 공수는 어떻게 계산해야 하나요? A. 문서화 수준과 담당자 유무에 따라 다르지만, 최신 API 기준의 1.5배에서 최대 4배까지 잡는 것이 현실적입니다. 계약 전 1주일 PoC로 실제 공수를 확인하는 것이 가장 정확합니다.