낡은 사내 시스템, 고쳐 쓸 것인가 새로 지을 것인가

지금 기업이 마주한 상황

10년 넘게 써 온 사내 시스템을 가진 기업은 대개 같은 상황에 놓여 있습니다. 시스템은 여전히 돌아갑니다. 큰 장애도 없습니다. 다만 작은 요청 하나에 2주가 걸리고, 그 요청을 처리할 수 있는 사람이 회사에 한 명뿐입니다.

이 상태가 위험한 이유는 문제가 점진적으로 나빠지기 때문입니다. 갑자기 멈추는 시스템은 즉시 예산이 배정됩니다. 그러나 조금씩 느려지고 조금씩 손이 더 가는 시스템은 매년 "올해도 그럭저럭 버텼다"로 넘어갑니다. 그렇게 넘긴 해가 쌓이면 세 가지가 동시에 닥칩니다.

첫째, 시스템을 아는 담당자가 퇴직합니다. 문서화되지 않은 업무 규칙이 그와 함께 사라집니다. 둘째, 기반 기술의 보안 지원이 종료됩니다. 지원이 끊긴 언어나 데이터베이스 버전은 취약점이 발견되어도 패치가 나오지 않습니다. 셋째, 새로운 요구를 붙일 수 없게 됩니다. 모바일 대응, 외부 서비스 연동, 데이터 분석 같은 요구가 "그건 지금 시스템으로는 안 됩니다"로 계속 반려됩니다.

세 가지가 한꺼번에 닥친 시점에는, 선택지가 전면 재구축밖에 남지 않습니다. 그리고 전면 재구축은 가장 비싸고 가장 위험한 선택지입니다.

교체를 검토해야 한다는 다섯 가지 신호

다음 항목 중 셋 이상에 해당한다면, 교체 검토를 시작할 시점입니다.

1. 변경 비용이 비대칭적입니다. 화면에 항목 하나를 추가하는 데 며칠이 걸립니다. 사용자가 보기에 사소한 요구와 큰 요구의 개발 기간이 별로 다르지 않다면, 구조가 이미 변경을 감당하지 못하는 상태입니다.

2. 유지보수 인력이 한 명입니다. 특정 인물만 손댈 수 있는 시스템은 그 사람의 휴가와 퇴직이 곧 사업 위험입니다. 이것은 인사 문제가 아니라 구조 문제입니다.

3. 기반 기술의 지원이 종료되었습니다. 사용 중인 언어 런타임, 프레임워크, 데이터베이스의 공식 지원 종료일을 확인하십시오. 이미 지났다면 보안 사고는 시간 문제입니다.

4. 데이터를 꺼내 쓸 수 없습니다. 경영 판단에 필요한 수치를 뽑는 데 담당자가 직접 쿼리를 짜야 하거나, 여러 화면을 열어 수기로 합산해야 한다면, 시스템이 데이터를 가두고 있는 것입니다.

5. 우회 업무가 늘고 있습니다. 현업이 시스템 대신 엑셀로 관리하는 영역이 넓어지고 있다면, 시스템이 실제 업무를 반영하지 못한다는 뜻입니다. 이 우회 업무는 어디에도 기록되지 않으므로, 시스템만 봐서는 문제가 보이지 않습니다.

유지 비용을 계산해 보십시오

교체 논의가 진전되지 않는 이유는 대개 "지금도 돌아가는데 왜 돈을 쓰느냐"입니다. 이 질문에 답하려면 유지 쪽에도 비용이 발생하고 있다는 사실을 수치로 보여야 합니다. 다음 네 항목을 합산하십시오.

앞의 세 항목은 이미 지출되고 있지만 어느 계정에도 잡히지 않는 비용입니다. 네 번째 항목은 아직 발생하지 않았지만 확률적으로 누적되는 비용입니다.

아래는 계산 방법을 보여주기 위한 가상의 예시이며, 실제 값은 각 기업의 조건에 따라 달라집니다. 연간 변경 요청이 30건이고 건당 평균 대기가 10일, 대기로 인한 일당 기회비용을 15만 원으로 잡으면 지연 비용만 연 4,500만 원입니다. 여기에 부서 두 곳이 각각 주 5시간을 엑셀 이중 관리에 쓴다면, 시간당 총인건비 25,000원 기준으로 연 1,300만 원이 더해집니다.

합계가 연 5,800만 원이라면, 3년이면 1억 7천만 원입니다. 교체 비용과 비교할 수 있는 숫자가 이 시점에 처음 생깁니다. 유지는 무료가 아니라, 청구서가 오지 않는 지출입니다.

전면 재구축이 위험한 이유

교체를 결정하고 나면 가장 먼저 떠오르는 방법이 전면 재구축입니다. 낡은 것을 멈추고, 새것을 만들어, 어느 날 한 번에 바꾸는 방식입니다. 직관적이지만 세 가지 위험을 안고 있습니다.

효익이 프로젝트 종료 시점까지 0입니다. 12개월짜리 재구축이라면, 11개월 동안 조직은 비용만 지불하고 아무 개선도 체감하지 못합니다. 이 기간에 경영 환경이 바뀌면 프로젝트는 중단 압박을 받습니다.

요구사항이 도중에 낡습니다. 착수 시점에 정리한 요구사항은 1년 뒤 현업의 요구와 다릅니다. 그 차이를 반영하면 일정이 밀리고, 반영하지 않으면 낡은 시스템이 완성됩니다.

전환 시점에 위험이 집중됩니다. 모든 기능을 한 번에 바꾸므로, 전환 당일 문제가 생기면 되돌릴 방법이 마땅치 않습니다. 그리고 문제는 거의 항상 생깁니다. 기존 시스템에는 아무도 기억하지 못하는 예외 규칙이 반드시 남아 있기 때문입니다.

단계적 이전이라는 대안

전면 교체 대신, 기존 시스템을 남겨 둔 채 기능 단위로 옮기는 방식이 있습니다. 순서는 다음과 같습니다.

1단계 — 경계 긋기

현재 시스템을 기능 덩어리로 나눕니다. 주문, 재고, 정산, 인사처럼 업무 단위로 나누되, 데이터를 누가 소유하는가를 기준으로 선을 그으십시오. 여러 덩어리가 같은 테이블을 직접 고치고 있다면, 그 지점이 나중에 가장 큰 걸림돌이 됩니다.

경계를 그을 때는 조직도가 아니라 데이터 흐름을 따르십시오. 부서가 나뉘어 있어도 같은 데이터를 함께 고치고 있다면 하나의 덩어리이고, 한 부서 안에서도 데이터가 완전히 분리되어 있다면 나눌 수 있습니다.

2단계 — 읽기부터 분리

가장 안전한 첫 과제는 조회 기능입니다. 대시보드, 통계, 보고서처럼 데이터를 읽기만 하는 기능은 새 시스템에서 만들어도 기존 시스템에 영향을 주지 않습니다. 실패해도 기존 화면이 그대로 남아 있으므로 되돌리기 쉽고, 현업은 곧바로 개선을 체감합니다.

이 단계에서 얻는 부수 효과가 하나 더 있습니다. 조회 기능을 만들다 보면 기존 데이터의 문제가 드러납니다. 중복된 거래처, 형식이 깨진 날짜, 코드값이 비어 있는 행이 여기서 발견됩니다. 쓰기 기능을 옮기기 전에 이 문제를 알게 되는 것이 중요합니다.

3단계 — 쓰기 기능 이전

조회로 검증이 끝나면 입력·수정 기능을 옮깁니다. 이때 한동안 두 시스템이 같은 데이터를 다루게 되므로, 한쪽만 원본으로 정하십시오. 양쪽에서 동시에 고칠 수 있게 두면 불일치가 발생하고, 그 불일치를 찾는 데 이전 자체보다 많은 시간이 듭니다.

이전 순서는 사용 빈도가 낮고 영향 범위가 좁은 기능부터 잡는 것이 안전합니다. 다만 아무도 쓰지 않는 기능부터 옮기면 검증이 되지 않으므로, 실제로 쓰이되 하루쯤 멈춰도 되는 기능이 가장 좋은 출발점입니다.

4단계 — 기존 시스템 축소

옮겨진 기능은 기존 시스템에서 제거하십시오. 남겨 두면 현업 일부가 옛 화면을 계속 쓰고, 결국 두 시스템을 영구히 유지하게 됩니다. 이 단계를 미루는 것이 단계적 이전이 실패하는 가장 흔한 이유입니다.

제거가 어렵다면 최소한 접근을 차단하고 읽기 전용으로 바꾸십시오. 그리고 언제 완전히 내릴지를 날짜로 정해 두십시오. 날짜가 없는 정리 계획은 실행되지 않습니다.

어느 쪽을 택할 것인가

전면 재구축이 항상 틀린 것은 아닙니다. 범위가 작고, 업무 규칙이 문서로 남아 있으며, 몇 시간의 중단이 허용된다면 한 번에 바꾸는 편이 빠르고 저렴합니다. 판단 기준은 시스템의 나이가 아니라 규칙이 어디에 기록되어 있는가입니다.

데이터 이전에서 실제로 문제가 되는 것

일정이 밀리는 원인은 대개 기능 개발이 아니라 데이터입니다. 오래된 시스템에는 다음과 같은 상태가 쌓여 있습니다.

• 같은 거래처가 표기만 다르게 여러 건 등록되어 있음
• 날짜·전화번호·사업자번호의 형식이 시기별로 다름
• 필수 항목인데 비어 있는 행이 존재함
• 이미 없어진 코드값을 참조하는 데이터가 남아 있음
• 삭제 표시만 되어 있고 실제로는 남아 있는 행이 섞여 있음

이 문제들은 이전 단계에서 발견하면 반드시 일정을 밀리게 합니다. 착수 전에 미리 조사하고, 정리할 범위와 버릴 범위를 먼저 정하십시오. 모든 과거 데이터를 완벽히 정리하려 들면 이전 자체가 끝나지 않습니다. 최근 몇 년 치만 정리하고 나머지는 조회 전용으로 보관하는 편이 현실적인 경우가 많습니다.

보안과 접근 권한을 다시 설계할 기회

교체는 보안 체계를 정리할 수 있는 드문 기회이기도 합니다. 오래된 시스템은 대개 권한 구분이 느슨하고, 담당자 대부분이 필요 이상의 데이터를 볼 수 있는 상태로 운영됩니다. 이전 과정에서 다음 항목을 함께 정하십시오.

접근 권한의 최소화. 역할별로 필요한 데이터만 보이도록 구분하십시오. 기존 시스템의 권한 구조를 그대로 옮기면, 낡은 문제도 함께 옮겨집니다.

개인정보의 저장 위치와 보관 기간. 어떤 개인정보가 어디에 저장되고 언제 파기되는지 정리하십시오. 클라우드로 옮기는 경우에는 데이터가 저장되는 국가도 함께 확인해야 합니다.

처리 이력의 보존. 누가 언제 무엇을 변경했는지 남기십시오. 오래된 시스템에 이 기록이 없어서, 문제가 생겼을 때 원인을 추적하지 못하는 경우가 많습니다.

경영진을 설득하는 방법

교체 예산은 대개 기술 논리로 통과되지 않습니다. "구조가 낡았다", "기술 지원이 끝났다"는 설명은 결재권자에게 긴급성으로 전달되지 않습니다. 다음 세 가지로 바꾸어 제시하십시오.

지금 새고 있는 금액. 앞서 계산한 지연·우회·오류 비용의 합계입니다. 교체를 하지 않아도 이미 지출되고 있다는 점이 핵심입니다.

하지 못하고 있는 것. 지난 1년간 "현재 시스템으로는 불가능"을 이유로 반려된 요구를 목록으로 만드십시오. 여기에 매출이나 고객 이탈과 연결되는 항목이 있다면 앞에 배치하십시오. 기회 손실은 유지 비용보다 강한 근거입니다.

최악의 경우. 유일한 담당자가 퇴직하거나 지원 종료된 구성요소에서 사고가 발생했을 때, 복구에 걸리는 기간과 비용을 산정하십시오. 확률이 낮아도 규모가 크면 의사결정을 움직입니다.

세 가지를 제시한 뒤에 단계적 이전의 첫 단계만 승인을 요청하십시오. 전체 예산을 한 번에 요구하면 검토 기간이 길어지고, 그사이 상황은 더 나빠집니다.

일정과 인력을 어떻게 잡을 것인가

단계적 이전에서 자주 어긋나는 것이 일정입니다. 세 가지를 미리 반영하십시오.

현업의 시간을 일정에 넣으십시오. 이전 프로젝트에서 가장 부족한 자원은 개발자가 아니라 업무 규칙을 아는 현업 담당자입니다. 이들은 본업을 하면서 참여하므로, 확보 가능한 시간을 미리 합의하지 않으면 검증 단계마다 일정이 밀립니다.

병행 운영 기간을 계산에 포함하십시오. 기능을 옮긴 뒤에도 한동안 두 시스템을 함께 운영해야 합니다. 이 기간에는 운영 부담이 오히려 늘어납니다. 이를 일정과 예산에 반영하지 않으면 마지막 단계에서 인력이 부족해집니다.

데이터 정리 기간을 별도로 잡으십시오. 뒤에서 다룰 정합성 문제는 개발과 병렬로 진행할 수 있지만, 별도의 시간과 담당자가 필요합니다. 개발 일정 안에 묻어 두면 반드시 밀립니다.

외부 업체와 일할 때 확인할 것

내부 인력만으로 이전을 수행하기 어려운 경우가 많습니다. 외부 업체를 검토한다면 다음을 계약 전에 확인하십시오.

산출물에 문서가 포함되는가. 코드만 넘겨받으면 몇 년 뒤 같은 문제가 반복됩니다. 업무 규칙 정의서, 데이터 구조 설명, 운영 절차서가 산출물에 포함되어야 합니다.

이전 이후 인수인계 방식이 정해져 있는가. 구축이 끝난 뒤 내부 인력이 운영할 수 있어야 합니다. 인수인계 기간과 교육 범위를 계약에 명시하십시오.

단계별로 나누어 계약할 수 있는가. 전체를 한 번에 계약하면 중간에 방향을 바꾸기 어렵습니다. 첫 단계를 수행해 보고 이후를 결정하는 구조가 양쪽 모두에게 안전합니다.

우리 데이터에 대한 권한이 명확한가. 개발 과정에서 실제 데이터를 사용한다면, 어떤 데이터가 어디로 이동하고 종료 후 어떻게 파기되는지 문서로 정하십시오.

착수 전 준비할 것

방식과 무관하게, 착수 전에 다음 세 가지를 확보하십시오.

현행 업무 규칙의 문서화. 코드에만 있는 규칙은 이전 과정에서 반드시 누락됩니다. 완벽한 명세가 아니어도 좋으니, 예외 처리와 승인 조건만은 글로 남기십시오.

데이터 정합성 점검. 앞서 정리한 항목을 기준으로 현재 상태를 조사하고, 정리 범위를 정하십시오.

되돌릴 계획. 각 단계마다 "문제가 생기면 어떻게 되돌리는가"를 정해 두십시오. 되돌릴 수 없는 단계는 그 자체로 너무 큰 단계이므로, 더 잘게 나누어야 한다는 신호입니다.

정리

낡은 시스템의 비용은 장애가 아니라 지연과 의존의 형태로 나타납니다. 그래서 늦게 인식됩니다.

• 변경 비용, 인력 집중, 기술 지원 종료, 데이터 접근성, 우회 업무 다섯 가지를 점검하십시오.
• 유지 비용을 지연·우회·오류·위험 네 항목으로 계산해, 교체 비용과 비교 가능한 숫자로 만드십시오.
• 규칙이 코드에만 남아 있다면 전면 재구축은 위험합니다.
• 조회 기능부터 옮기고, 옮긴 기능은 반드시 기존 시스템에서 제거하십시오.
• 데이터 정합성은 착수 전에 조사하고, 정리 범위를 미리 정하십시오.
• 접근 권한과 개인정보 보관 정책을 이 기회에 함께 재설계하십시오.

교체 여부보다 중요한 것은 판단을 미루지 않는 것입니다. 다섯 가지 신호 중 셋에 해당한다면, 올해 안에 검토를 시작하는 편이 내년에 전면 재구축을 하는 것보다 저렴합니다.