SI 프로젝트의 구조적 문제와 현실적인 해결책

SI 프로젝트에서 발주사 담당자와 개발사 실무자, 양쪽 입장을 모두 경험해봤습니다. 발주사에서는 현업 요구사항을 받아 프로젝트를 기획하고 관리하는 업무를, 개발사에서는 실제로 시스템을 구현하는 업무를 수행했습니다.

두 입장에서 일하며 느낀 점은, 양측 모두 각자의 제약 속에서 최선을 다하지만 구조적인 문제로 인해 어려움을 겪는다는 것이었습니다. 이 글에서는 SI 업계의 고질적인 문제들과, 현실적으로 적용 가능한 개선 방안들을 정리해보려 합니다.

고객사나 프로젝트를 특정할 수 있는 내용은 제외하고, 읽는 분들께 가치 있는 인사이트만 담고자 합니다.

문제의 본질

여러 사람이 모여 일을 하다 보면 문제는 끊임없이 발생합니다. 이는 당연한 일입니다. 오히려 문제가 발생하지 않는다면, 풀고 있는 주제가 큰 가치가 있는 것이 아닐 수도 있습니다.

진짜 어려운 것은 풀기 어려운 문제를 풀어야 하는 상황입니다.

여기서 말하는 **'풀기 어려운 문제'**란 무엇일까요? 이는 단순히 기술적으로 복잡한 문제를 의미하는 것이 아닙니다.

• 내가 혼자서는 해결할 수 없는 문제
• 다른 사람이나 조직이 만들어낸 문제
• 조직과 조직 사이의 그레이존에서 발생하는 구조적 문제

예를 들어, 발주사 담당자가 예산 부서로부터 예산을 삭감당하는 것, 현업의 업무를 100% 이해할 수 없는 상황, 개발사가 숨겨진 요구사항을 나중에 발견하는 것 등이 여기 해당합니다. 이런 문제들은 개인의 능력이나 노력만으로는 해결이 불가능합니다.

그런데 SI 업계에서는 이러한 '풀기 어려운 문제'가 구조적으로 만들어질 수밖에 없습니다. 대부분의 프로젝트는 발주사 담당자가 현업의 요구사항을 받아, 경영진과 예산 담당 부서를 설득하는 과정을 거칩니다.

여기서 발생하는 구조적 문제:

1. 정보 비대칭: 담당자는 현업 업무를 100% 파악할 수 없는 상태입니다.
2. 과도한 약속: 프로젝트를 승인받기 위해 어느 정도 과장이 들어갑니다.
3. 예산 압박: 실제로 제품을 만들어줄 개발사에는 최대한 적은 예산을 배정해야 합니다.

이러한 상황은 발주사 담당자 개인의 문제가 아닙니다. 조직 구조와 평가 체계가 이러한 행동을 유도합니다.

하지만 이 지점에서 치명적인 문제들이 발생합니다:

• 무엇을 만들어야 하는지 제대로 모르는 상태에서
• 이 예산이면 만들 수 있다고 주장하고
• 실제 만들 사람들에게는 최대한 적은 돈을 줘야 합니다

발주사의 딜레마

발주사 담당자들도 이런 근본적 문제를 타개하기 위해 노력합니다. 현업 업무를 최대한 이해하려 하고, 예산도 최대한 많이 확보하려 하며, 개발사와도 적극적으로 소통하려 합니다.

하지만 보통은 현업, 상사, 고과의 압박으로 인해 문제를 만들 수밖에 없습니다:

전형적인 문제 패턴

패턴 1: 요구사항 분석 실패

현업 요구사항을 제대로 분석하지 못함
→ 요구사항을 그대로 수용
→ 시스템 복잡성 증가
→ 사용하기 어려운 소프트웨어 구현

패턴 2: 예산 축소의 부작용

예산 줄이기
→ 일부 요구사항을 개발사에 숨기거나 모호하게 전달
→ 나중에 요구사항 변경 (Scope Creep)
→ 소프트웨어 완성도 저하

발주사 담당자가 실제로 해야 할 일

1. 요구사항 복잡도 낮추기

   • 업무를 시스템으로 이전(Digital Transformation)한다는 것은 업무를 재정의해야 한다는 의미입니다.
   • 이전 방식을 단순히 폼에 넣어 DB에 저장하는 것이 아닙니다.

2. 요구사항 사전 구체화

   • 개발사에 적정 예산을 주지 못한다면, 최소한 프로젝트에 대해 동일한 관점으로 정렬해야 합니다.
   • 커뮤니케이션 오버헤드를 최소화해야 합니다.

3. 공통 요구사항 명확화

   • UI, Permission, Common Components 등의 사전 요구사항을 미리 공유해야 합니다.

4. 통합 창구 역할

   • 레거시 인터페이스 작업이 있다면 미리 알려야 합니다.
   • 모든 커뮤니케이션의 원포인트 창구가 되어야 합니다.

발주사 담당자가 솔직해지기 어려운 이유

담당자 개인의 문제라기보다는, 환경 자체가 솔직해지기 어렵게 만듭니다:

1. 평가 기준의 왜곡: "예산을 얼마나 깎았으며 요구사항을 얼마나 더 늘렸는지"로 평가받는 상황
2. 역할의 제한: 요구사항 분석이나 기술적 이해보다는 발주 과정과 일정 관리만 요구받는 상황
3. 상하 관계의 압박: 상사와 경영진, 예산 부서의 상반된 압박
4. 현업과의 갈등: "이 일을 해보셨나요? 이대로 해주세요" 하는 현업의 저항

이런 압박 속에서 담당자는 예산을 낮추려 요구사항을 숨기게 되고, 요구사항이 구체화되지 않은 채로 프로젝트를 시작합니다.

개발사도 자유롭지 않다

개발사 역시 문제를 만드는 경우가 있습니다:

패턴 1: 커뮤니케이션 부족

요구사항을 제대로 이해하지 못함
→ 커뮤니케이션 부족
→ Rework 반복 발생
→ 소프트웨어 완성도 저하

패턴 2: 단순화의 함정

소프트웨어 복잡도를 낮추려 함
→ 복잡한 요구사항을 단순화하려는 시도 없이 뭉갬
→ 소프트웨어 완성도 저하

현실적인 해결책

하지만 현실적으로 발주사 담당자들은 구조적으로 솔직해지기 어렵습니다. 그들이 나쁜 것이 아니라, 환경이 그렇게 만듭니다.

구조 변경은 개발사가 건드리기 어려운 문제이니, RFP(Request for Proposal) 단계부터 적용할 수 있는 현실적인 방안들을 제시합니다.

1. 요구사항의 분석과 개선, 구체화

흐릿한 요구사항 정의를 보고, 각 업무를 어떻게 시스템으로 이전할지, 어떻게 단순화할지 이해도를 높여야 합니다.

쉽지 않은 일이지만, 시스템은 대부분 비슷하기 때문에 시나리오별 UI/UX 모범 사례를 분석한 경험이 있다면 가능합니다. 이 과정에서 도출되는 대안들로 담당자와 현업을 친절하게 설득해야 합니다.

2. 적정 버퍼 확보

미래에 발생할 요구사항 추가 및 변경에 대해 적정 버퍼를 두어야 합니다. 아무리 노력해도 숨겨진 요구사항이 있을 것이고, 복잡도 해결에 실패한 요구사항이 생길 수밖에 없습니다. 용역 형태의 매출을 주로 갖는 회사의 경우, 현금흐름 압박 속에서 저가 수주를 할 수 밖에 없는 구조적 문제를 안고 있습니다.

3. 사전 작업에 대한 명확한 요구

다음 항목들을 구체적으로 파악하고 견적이나 최소한 일정에라도 반영해야 합니다:

• 공통 기능: 유저 관리(Permission, Role 등) 같은 기능의 상세 요구사항
• 인터페이스: 구현 시작 전 처리해야 할 I/F 목록
• UI/UX 요구사항: 사용하길 원하는 라이브러리, Grid 등 자주 사용되는 기능에 대한 요구사항
• 플랫폼 범위: 웹/앱에 대한 요구사항

4. 업무 관련 정보 확보

계약 전 제공이 불가능한 경우도 있겠지만, 요구사항 단순화를 위해 필요한 정보를 최대한 받아야 합니다:

• 업무 프로세스
• 핵심 니즈 (Nice-to-have vs Must-have)
• 현재 업무 방식의 Pain Points

마치며

SI 프로젝트의 문제는 누구 한 사람의 잘못이 아닙니다. 구조적인 문제이며, 발주사와 개발사 모두가 각자의 제약 속에서 최선을 다하고 있습니다.

하지만 이러한 구조를 이해하고, 가능한 범위 내에서라도 개선을 시도한다면 조금씩 나아질 수 있습니다. 완벽한 해결책은 없지만, 작은 개선들이 모여 프로젝트의 성공 확률을 높일 수 있습니다.

이 글이 SI 프로젝트를 진행하는 분들께 도움이 되길 바랍니다.