Executive Summary
- 현대화의 우선순위는 도입 연도보다 업무 지연, 반복 입력, 데이터 불일치 등 사업에 미치는 영향으로 정해야 합니다.
- AI를 활용한 자체 개발과 SaaS는 구독료뿐 아니라 개발·검증·운영·변경 비용을 같은 기간으로 비교해야 합니다.
- 시스템 통합에는 데이터의 정의와 업무 예외를 맞추는 작업이 필요합니다. 공통으로 쓸 기능과 별도로 남길 기능을 구분해야 합니다.
- 단계적 전환은 업무 중단의 영향을 줄일 수 있지만, 이중 운영 비용과 종료 조건을 함께 관리해야 합니다.
이 글은 IDG의 아티클을 전재하여 제공합니다.
원문보기
AI 시대의 IT 현대화
AI 도입 계획은 새로운 모델과 플랫폼을 찾는 일부터 시작하곤 합니다. 그러나 기존 업무에서 AI가 맡을 일을 살펴보면, 먼저 손볼 곳이 드러납니다. 고객 정보가 여러 시스템에 흩어져 있고, 보고할 때마다 숫자를 맞추며, 담당자가 바뀌면 업무 이력을 찾기 어렵습니다. 이런 업무에 AI 기능을 더하면 자동화할 일과 관리할 시스템이 함께 늘어날 수 있습니다.
IT 현대화는 기존 시스템의 기능과 운영 방식을 현재의 사업 요구에 맞추고, 중복되거나 가치가 낮은 애플리케이션을 정리하는 작업입니다. 바꿀 시스템과 남길 시스템을 함께 정해야 새 투자가 업무 시간과 운영 비용을 줄이는 성과로 이어집니다.
블랙라인은 SaaS의 비용과 업무 가치를 다시 살피고 있으며, UST는 영업 업무에 맞지 않는 CRM을 현대화하고 있습니다. 두 사례는 현대화 계획에 업무 병목, 운영 비용, 데이터의 의미, 전환 후 시스템 종료 기준을 담아야 한다는 점을 보여줍니다.
최근 도입한 시스템도 업무를 늦출 수 있다
UST는 CRM의 도입 연식보다 영업 업무에 필요한 기능과 사용 경험을 살피고 있습니다. 기존 시스템의 사용자 경험이 좋지 않아 영업 담당자는 정보를 제때 갱신하지 않았고, 운영팀은 정보를 대신 입력했습니다. 회사는 영업 부서에 필요한 기능을 갖추기 위해 CRM을 현대화하고 있습니다.
AI가 데이터를 읽고 요약하려면 업무 정보가 제때 입력돼야 합니다. 영업 담당자가 기록하지 않은 내용은 AI도 요약할 수 없습니다. 어떤 입력이 번거로운지, 다른 시스템에 이미 있는 정보를 다시 적는지, 업무 중 언제 정보를 갱신해야 하는지부터 확인해야 합니다.
현대화 후보를 찾을 때는 사용자의 하루를 따라가며 업무 흐름을 살피면 좋습니다. 예를 들어 고객 문의를 처리하는 직원이 여러 시스템을 오가며 같은 내용을 반복 입력한다면, 입력 항목과 시스템 연동을 점검할 수 있습니다. 견적 승인이 늦어질 때는 시스템 처리 시간과 담당자의 판단을 기다리는 시간을 구분해야 합니다. 업무 규칙 때문에 승인이 늦어진다면 애플리케이션을 교체해도 대기 시간은 줄지 않습니다.
확인한 병목은 측정 가능한 목표로 바꿔야 합니다. 업무 한 건을 처리하는 시간, 중복 입력 횟수, 정보 갱신까지 걸리는 시간, 오류로 다시 처리한 비율 등을 지표로 삼을 수 있습니다. 부서와 업무에 맞는 지표를 선택하고 변경 전 상태를 기록해야 전환 후 개선 여부를 확인할 수 있습니다.
AI로 직접 만든 서비스에도 운영 비용은 있다
블랙라인은 특정 기능을 제공하는 SaaS의 업무 가치와 비용을 살피고, AI를 활용해 자체 서비스를 만들 수 있는지 검토하고 있습니다. 자연어로 애플리케이션에 질문하고 답을 얻을 수 있게 되면서, 일부 대시보드와 챗봇 제작 도구의 필요성도 다시 평가하고 있습니다.
SaaS와 자체 개발을 비교할 때는 같은 기간과 서비스 수준을 기준으로 삼아야 합니다. 연간 구독료와 최초 개발비만 비교하면 운영 비용을 놓칩니다. 자체 개발 서비스도 요구사항 변경, 접근 권한 관리, 보안 취약점 수정, 장애 대응, 담당자 교체에 따른 인수인계가 필요합니다. AI 모델을 사용한다면 호출 비용과 결과 검증 비용도 계산해야 합니다.
업무 범위가 명확하고 변경이 적으며 운영 담당자가 있는 서비스는 자체 개발 후보로 검토할 수 있습니다. 예를 들어 소수의 내부 사용자가 이용하는 단순 조회 기능이라면 작은 범위에서 비용과 편의성을 확인하기 좋습니다. 외부 고객이 이용하거나 여러 시스템의 거래를 처리하는 서비스는 장애가 미치는 영향과 필요한 운영 수준을 더 엄격하게 따져야 합니다. 화면이 비슷하게 작동한다는 이유만으로 기존 서비스를 대체할 수는 없습니다.
SaaS 계약을 검토할 때는 실제 사용 기능과 빈도, 계약을 축소할 수 있는 시점, 데이터 반출 조건, 대체 서비스와의 연동을 확인해야 합니다. 기능을 대체해도 계약을 유지하면 실제 지출은 줄지 않을 수 있습니다. 예상 절감액과 계약 해지나 축소로 실제 줄일 수 있는 금액을 구분해야 투자 계획을 정확히 세울 수 있습니다.
대시보드는 업무에 따라 유지 여부를 판단해야 합니다. 일회성 질문에 답하는 도구라면 자연어 조회를 시험할 수 있습니다. 정해진 지표를 같은 조건으로 비교하거나 여러 사람이 같은 수치를 검토한다면 기준 화면을 유지할 수 있습니다. AI 조회 기능을 추가할 때는 지표의 정의와 조회 시점, 같은 질문에 같은 결과를 얻을 수 있는지 확인해야 합니다.
도구를 통합하려면 데이터의 의미도 맞춰라
군용 차량 제조업체 제너럴 다이내믹스 랜드 시스템즈는 CAD 도구를 10개에서 2개로, 보고 도구를 3개에서 1개로 줄였습니다. 회사는 공통 도구를 사용하는 것을 기본 원칙으로 삼고 있습니다.
도구를 통합해도 데이터 정의가 다르면 결과는 일치하지 않습니다. 예를 들어 부서마다 매출 집계 시점이 다르면 보고 도구를 하나로 줄여도 수치가 달라집니다. 고객 코드가 중복되거나 계약 상태를 부서마다 다르게 기록하면, AI가 여러 시스템을 조회해도 일관된 답을 내기 어렵습니다.
통합 계획에는 고객·제품·거래의 식별 기준, 주요 지표의 계산 방식, 정보 갱신 주기, 오류를 수정할 담당자를 정해야 합니다. AI가 어떤 원천 시스템의 정보를 어느 범위까지 조회할지도 정해야 합니다. 정보를 읽기만 하는 업무와 데이터를 변경하는 업무를 구분하면 시스템 연동과 검증 범위를 정하기 쉽습니다.
공통으로 사용할 기능과 별도로 유지할 기능도 업무별로 구분해야 합니다. 여러 부서가 함께 쓰는 조회·보고 기능은 통합하고, 제품 설계나 고객 계약에 필요한 기능은 유지할 수 있습니다. 이때 추가 기능이 주는 편익과 별도의 데이터·연동·지원 체계를 운영하는 비용을 비교해야 합니다. 통합 후에도 예외를 정기적으로 검토하면 불필요한 도구가 다시 늘어나는 일을 줄일 수 있습니다.
바꿀 시스템과 남길 시스템을 정하는 법
현대화 후보를 모두 교체하면 투자 범위가 지나치게 커질 수 있습니다. 시스템별 사업 가치와 기술 위험을 함께 평가해 우선순위를 정하고, 폐기·유지·운영 환경 변경·코드 개선·구조 재설계·대체 가운데 적합한 방식을 선택해야 합니다.
핵심 거래를 처리하는 시스템이 반복적으로 멈춘다면 먼저 안정화해야 합니다. 사용이 적은 도구에 문제가 생겼다면 재구축에 앞서 종료할 수 있는지 검토합니다. 아래 기준으로 시스템별 조치를 정할 수 있습니다.
| 판단 방향 | 우선 검토할 상황 | 투자 전 확인할 조건 |
|---|---|---|
| 유지 | 필요한 업무를 안정적으로 지원 | 지원 종료 시점과 재검토 계기 |
| 연결·부분 개선 | 핵심 기능은 유효하지만 입력·조회·연동에 병목이 있음 | 개선 범위와 기존 시스템의 제약 |
| 교체·재설계 | 반복 장애나 구조적 제약으로 사업 요구를 충족하기 어려움 | 전환 편익과 데이터 이전·운영 역량 |
| 통합·종료 | 다른 도구와 중복되거나 현재 가치가 낮음 | 업무 의존성·기록 보존·계약 종료 조건 |
유지하기로 한 시스템에도 관리 계획을 세워야 합니다. 지원 종료, 사용량 증가, 새로운 업무 요구 등 어떤 변화가 생기면 다시 검토할지 기록합니다. 연결·부분 개선을 선택했다면 새 연동 기능의 담당자와 장애 대응 방법도 정해야 합니다. 선택의 근거를 남겨야 다음 예산 검토에서도 판단을 이어갈 수 있습니다.
클라우드 이전은 현대화 목적에 맞춰 결정해야 합니다. 기존 애플리케이션을 큰 변경 없이 옮기면 업무 구조와 코드의 문제가 남을 수 있습니다. 운영 환경을 바꾸려는지, 애플리케이션 자체를 개선하려는지 구분하면 이전만으로 해결할 범위와 별도 현대화가 필요한 범위를 정할 수 있습니다.
단계적 전환시에는 이중 운영의 종료 시점 지정이 필수
핵심 업무를 지원하는 시스템은 전환 중에도 서비스를 이어가야 합니다. 기능을 나누고 요청을 분기할 수 있다면 일부 업무부터 새 서비스로 옮길 수 있습니다. 스트랭글러 패턴은 새 기능과 기존 기능을 함께 운영하다가 요청을 새 서비스로 옮기고, 기존 기능을 차례로 제거하는 방식입니다.
이 방식은 요청을 제대로 분기할 수 있어야 하며, 문제가 생겼을 때 기존 서비스로 되돌릴 방법도 마련해야 합니다. 분기 계층이 성능 병목이나 단일 장애 지점이 될 수도 있습니다. 기능을 나눠 옮기더라도 전환 위험을 따로 검토하고 실제 복구가 가능한지 확인해야 합니다.
예를 들어 주문 업무를 이전할 때 조회 기능부터 옮길 수 있습니다. 그러나 주문 상태를 변경하는 기능은 재고·결제·취소 처리와 연결됩니다. 새 시스템과 기존 시스템이 서로 다른 상태를 표시하거나 같은 요청을 중복 처리하지 않도록 기준을 세워야 합니다. 단계의 크기는 기능 수뿐 아니라 업무 의존성과 데이터 일관성을 고려해 정해야 합니다.
전환 기간에는 기존 운영비에 새 환경 비용, 데이터 동기화, 사용자 교육, 검증 작업이 더해질 수 있습니다. 이중 운영을 허용할 기간과 다음 단계로 넘어갈 조건을 예산과 계획에 명시해야 합니다. 단계별 범위와 성공 기준을 정하고, 업무 가치와 시스템 의존성을 고려해 전환 순서를 잡아야 합니다.
데이터 이전 범위도 정해야 합니다. 현재 업무에 필요한 데이터와 보관·조회 목적으로 남길 기록을 구분하고, 과거 기록을 찾을 경로를 마련합니다. 보존·접근·삭제에 관한 회사 요건을 확인하고 새 시스템에 옮기지 않는 데이터의 담당자도 정해야 합니다.
성과 측정은 기존 시스템 종료 후에
새 시스템의 오픈일을 정했다면 기존 시스템의 종료 조건과 시점도 함께 정해야 합니다. 사용자가 새 도구를 쓰기 시작해도 예외 업무 때문에 기존 도구를 계속 사용하거나, 계약과 운영 인력을 그대로 유지하면 계획한 절감액을 실제 지출에서 확인하기 어렵습니다.
기존 시스템을 종료하기 전에 기존 기능을 호출하는 연동과 예약 작업을 확인해야 합니다. 아직 시스템에 접속하는 사용자가 어떤 업무를 하는지 살피고, 대체 업무 경로와 과거 기록을 조회할 방법도 마련합니다. 사용 중단을 확인한 뒤 계약·자원·계정을 정리할 순서를 정합니다. 예외 업무가 남는다면 유지 범위와 담당자, 비용, 재검토 시점을 기록해야 합니다.
시스템 수와 비용을 나눠 성과를 측정해야 합니다. 도구 수를 줄였어도 업무 처리 시간이 늘었다면 추가 개선이 필요합니다. 업무 시간이 줄었더라도 계약을 변경하지 않았다면 현금 지출은 아직 감소하지 않았습니다. 처리 시간, 오류와 재작업, 운영 투입 시간, 실제 지출을 각각 확인해야 현대화의 효과를 정확히 판단할 수 있습니다.
새 AI 서비스를 검토할 때도 기존 기능 가운데 무엇을 대체하는지, 누가 실제 사용을 확인하는지, 기대한 편익을 내지 못하면 언제 종료할지 정해야 합니다. 새 서비스를 도입할 때 기존 서비스의 재평가와 종료 계획을 함께 세우면 향후 정리할 대상을 줄일 수 있습니다.
다음 투자 계획에는 종료할 업무도 담아야
AI 투자와 IT 현대화를 함께 추진하려면 업무 단위로 기대 효과와 운영 책임을 정해야 합니다. 어떤 입력과 대기를 줄일지, 기존 시스템의 어떤 기능을 유지할지, 새 서비스 운영 비용을 누가 책임질지, 중복 비용을 언제 정리할지 계획에 담습니다.
대표 업무 한 개를 골라 관련 시스템과 계약, 데이터 흐름을 정리하는 것부터 시작할 수 있습니다. 사용자의 반복 입력과 대기 시간을 확인하고 개선 전 상태를 측정한 다음, 유지·개선·교체·종료 방식을 정합니다. 한 업무에서 편익과 운영 조건을 확인하면 다른 업무로 확대할 근거도 마련됩니다.
새 AI 기능의 도입 계획에는 기존 업무와 시스템의 종료 계획도 나란히 놓아야 합니다. 전환 후 남을 비용과 책임, 실제 절감 시점까지 설명할 수 있어야 다음 IT 투자의 우선순위를 세울 수 있습니다.
FAQ
-
IT 현대화와 애플리케이션 합리화는 어떻게 다릅니까?
IT 현대화는 기존 시스템의 기능·구조·운영 방식을 현재의 사업 요구에 맞게 개선하는 작업입니다. 애플리케이션 합리화는 보유한 시스템의 업무 가치와 중복 여부를 살펴 유지·통합·종료 여부를 정하는 과정입니다. 두 작업을 함께 검토하면 무엇을 개선하고 어떤 시스템을 정리할지 계획할 수 있습니다.
-
AI를 도입하기 전에 모든 레거시 시스템을 교체해야 합니까?
모든 시스템을 교체할 필요는 없습니다. 필요한 업무를 안정적으로 지원하는 시스템은 유지하면서 연동이나 조회 기능을 개선할 수 있습니다. 반복 장애, 지원 종료, 구조적 제약으로 사업 요구를 충족하지 못하는 시스템은 업무 가치와 기술 위험을 기준으로 우선순위를 정해야 합니다.
-
AI를 활용한 자체 개발이 SaaS보다 저렴합니까?
업무 범위와 운영 조건에 따라 달라집니다. 구독료와 최초 개발비뿐 아니라 유지보수, 보안 점검, 장애 대응, AI 호출과 결과 검증에 드는 비용을 같은 기간으로 비교해야 합니다. 자체 개발로 SaaS 기능을 대체한 뒤 계약을 실제로 줄일 수 있는지도 확인해야 합니다.
-
클라우드 이전만으로 IT 현대화가 끝납니까?
기존 애플리케이션을 큰 변경 없이 옮기면 업무 구조와 코드의 제약이 남을 수 있습니다. 클라우드 이전과 애플리케이션 개선의 목적을 구분하고, 운영 환경 변경·코드 개선·구조 재설계 가운데 필요한 방식을 선택해야 합니다. 새 환경의 운영 비용과 기존 시스템의 종료 조건도 함께 정해야 합니다.
-
IT 현대화의 성과는 어떤 지표로 평가합니까?
업무 처리 시간, 중복 입력, 오류와 재작업, 운영 투입 시간, 실제 지출 등을 목표에 맞게 선택할 수 있습니다. 변경 전 상태를 기록하고 전환 후 같은 기준으로 비교해야 합니다. 단계별 성공 기준과 기존 시스템의 종료 조건도 함께 정하면 전환 완료와 실제 편익을 구분해 확인할 수 있습니다.
▶ 본 콘텐츠는 CIO의 원문과 공개 자료를 바탕으로 재구성한 콘텐츠이며, 원문 및 인용 자료의 저작권은 각 권리자에게 있습니다.
▶ 원문과 인용 자료의 2차 가공 및 영리적 이용은 각 권리자의 이용 조건을 따라야 합니다.