IT 시스템 구축 프로젝트에서 시스템을 만드는 것보다 프로세스가 먼저다

IT 시스템 구축 프로젝트에서 가장 큰 실수는 “먼저 시스템을 만들고, 나중에 프로세스를 맞추자”는 생각이다. 원문의 핵심 메시지인 “It’s always the process, stupid!”을 IT 시스템 구축 관점에서 확장하면, 다음과 같은 실무 인사이트를 얻을 수 있다.

1. “AI/자동화”는 가속페달, 지능이 아니다

원문이 강조하는 핵심은, AI나 자동화는 “지능”이 아니라 “속도”라는 점이다. IT 시스템 관점에서 보면:

• 기존 프로세스가 비효율하면, 자동화는 그 비효율을 빠르게 반복한다.
  예를 들어, 수동으로 10개의 승인 단계를 거치는 결재 프로세스를 그대로 워크플로 시스템에 옮기면, “빠르게” 10단계를 돌게 되는 것이다.

• AI는 “구조화되지 않은 데이터”를 다루는 데 강점이 있다.
  이메일, PDF, 채팅, 음성 등 비정형 데이터를 처리할 수 있으므로, 기존에 “사람이 알아서 판단하던” 영역을 시스템화할 수 있다.

• 그러나 AI가 “무엇을 해야 하는지”는 여전히 사람이 정해야 한다.
  AI가 계약서에서 리스크를 추출하려면, “어떤 조항이 리스크인지”, “어떤 출력 형식으로 내보낼지”를 명확히 정의해야 한다.

IT 인사이트:

• AI/자동화 도입 전에, “이 프로세스를 그대로 빠르게 돌려도 괜찮은가?”를 꼭 검토해야 한다.
• AI는 “무엇을 할지”를 정의하는 데 도움이 되지만, “왜 그렇게 해야 하는지”는 비즈니스 로직과 프로세스 설계가 답해야 한다.

2. 시스템 구축의 시작은 “프로세스 재설계”다

IT 시스템은 비즈니스 프로세스의 디지털 표현이므로, 프로세스가 엉망이면 시스템도 엉망이 된다.

2.1. 프로세스 최적화 없이 시스템을 만들면 생기는 문제

• 중복/불필요한 단계가 시스템에 고정된다.
  예: ERP 구축 시, “이미 ERP에 있는 정보를 수동으로 또 입력하는” 단계를 그대로 둔다.

• 병목 지점이 시스템화되면서 더 심각해진다.
  예: 승인자가 5명인 결재 루트를 워크플로로 옮기면, “빠르게” 5명을 기다리는 구조가 된다.

• 데이터 품질이 낮아져, AI/분석 결과도 신뢰할 수 없다.
  프로세스가 불명확하면, 누가 언제 어떤 데이터를 입력하는지가 모호해지고, 데이터가 불완전하거나 중복된다.

2.2. 시스템 구축 전에 해야 할 프로세스 작업

1. 현재 프로세스 매핑 (As-Is)
   • 흐름도, 스텝, 담당자, 입력/출력, KPI를 문서화한다.
   • “이 작업은 왜 필요한가?”, “이 정보는 어디서 오는가?”를 반복해서 묻는다.
2. 병목/낭비 식별
   • 대기 시간, 승인 단계, 중복 입력, 재작업, 커뮤니케이션 오류를 찾아낸다.
3. 미래 프로세스 설계 (To-Be)
   • 불필요한 스텝을 제거하고, 승인 단계를 줄이며, 자동화 가능한 부분을 분리한다.
   • “이 프로세스를 완전히 없애도 되는가?”, “이 단계를 병렬로 돌릴 수 있는가?”를 고민한다.
4. 프로세스를 시스템 설계에 반영
   • To-Be 프로세스를 기반으로, 시스템의 모듈, 워크플로, 데이터 모델을 설계한다.

IT 인사이트:

• IT 프로젝트의 초기 단계에서 “프로세스 리엔지니어링”이나 “BPM” 활동을 별도로 계획해야 한다.
• “시스템 구축”과 “프로세스 최적화”를 별개의 프로젝트로 나누고, 프로세스 최적화가 완료된 후에 시스템 설계를 시작하는 것이 안전하다.

3. 비정형 데이터 프로세스를 시스템화하는 방법

원문이 강조하는 “unstructured data trap”은 IT 시스템 구축에서 매우 중요한 포인트다.

3.1. “사람이 알아서 하던” 프로세스의 문제점

• 문서화되지 않아, 시스템화가 어렵다.
  예: “고객 불만 처리”가 “경험 많은 직원이 이메일을 보고 판단해서 처리”하는 방식이면, 시스템에 어떻게 옮길지 모호하다.

• 판단 기준이 명확하지 않아, AI/자동화가 실패한다.
  예: “이 이메일이 긴급한가?”를 AI가 판단하려면, “긴급”의 정의(예: “고객이 3번 이상 연락한 경우”, “계약 해지 언급”)가 필요하다.

3.2. 비정형 데이터 프로세스를 시스템화하는 단계

1. Trigger (트리거) 정의
   • 언제 이 프로세스가 시작되는가?
     예: “고객 이메일 수신”, “고객센터 채팅 시작”, “계약서 PDF 업로드” 등.
2. Transformation (변환) 정의
   • AI/시스템이 “무엇을 추출/판단해야 하는가?”
     예:
     • 계약서 → “리스크 조항”, “계약 기간”, “위약금 조건” 추출
     • 고객 이메일 → “문의 유형”, “긴급도”, “요청 사항” 분류
3. Structured Output (구조화된 출력) 정의
   • 추출/판단한 결과를 어떤 형식으로 내보낼지 결정한다.
     예:
     • JSON 스키마: { type: "contract", risk_clauses: [...], duration: "12 months", ... }
     • ERP/CRM 필드: “계약 유형”, “리스크 등급”, “담당자” 등
4. Human-in-the-loop (사람 개입) 설계
   • AI가 확신이 낮은 경우, 사람에게 검토를 요청하는 워크플로를 설계한다.
   • 예: “AI 신뢰도 < 80%면, 담당자에게 검토 요청” → “검토 후 결과 반영”

IT 인사이트:

• 비정형 데이터 프로세스를 시스템화할 때는, “AI가 뭘 해야 하는지”를 명확히 정의하는 것이 가장 중요한 설계 단계다.
• AI는 “무엇을 할지”를 정의하는 데 도움이 되지만, “왜 그렇게 해야 하는지”는 비즈니스 로직과 프로세스 설계가 답해야 한다.

4. IT 시스템 구축 프로젝트의 실무 프레임워크

원문의 메시지를 IT 시스템 구축 프로젝트에 맞게 재구성하면, 다음과 같은 프레임워크를 사용할 수 있다.

4.1. 프로젝트 단계별 접근

4.2. 시스템 설계 시 고려할 포인트

• 프로세스 변경을 시스템 설계에 반영
  • 승인 단계를 줄였으면, 워크플로에서 승인자 수를 줄이고, 조건 기반 룰을 적용한다.
  • 중복 입력을 제거했으면, 시스템 간 통합을 통해 데이터를 자동으로 동기화한다.
• AI/자동화는 “To-Be 프로세스”에 맞춰 설계
  • AI는 “To-Be 프로세스”에서 자동화할 부분을 빠르게 처리하는 도구로 사용한다.
  • AI가 실패했을 때, 사람에게 넘기는 fallback 경로를 설계한다.
• 데이터 모델은 프로세스의 흐름을 반영
  • 프로세스의 각 스텝에서 필요한 데이터를 명확히 하고, 시스템의 테이블/컬럼으로 매핑한다.
  • 프로세스가 변경되면, 데이터 모델도 함께 변경될 수 있도록 유연한 설계를 고려한다.

IT 인사이트:

• IT 시스템 구축 프로젝트는 “프로세스 최적화 → 시스템 설계 → 구현” 순서로 진행하는 것이 가장 안정적이다.
• 프로세스 설계와 시스템 설계를 병렬로 진행하되, 시스템 설계는 To-Be 프로세스를 기반으로 해야 한다.