운영 중인 시스템, 유지보수할까 재구축할까 — 무엇을 보고 판단하는가

작은 수정에도 시간이 오래 걸리고, 수정한 부분 주변에서 다른 오류가 발생하고, 처음 만든 사람에게 구조를 물어볼 수도 없는 시스템을 운영하다 보면 「차라리 새로 만드는 편이 낫지 않을까」라는 질문이 나옵니다. 반대로 새로 만드는 데 드는 비용과 기간을 떠올리면 「조금 더 써 보자」로 결론이 미뤄지기도 합니다.

두 결론 모두 근거를 정리하기 전에 나오기 쉽습니다. 이 글은 그 판단을 근거를 갖고 내릴 수 있도록, 어떤 신호가 어느 쪽을 가리키는지와 판단 전에 무엇을 확인해야 하는지를 정리합니다.

빌드업웍스는 운영 중인 소프트웨어의 유지보수와 새 시스템 개발을 모두 수행합니다. 이 글은 결론을 한쪽으로 정하지 않고 양쪽의 근거와 대가를 같은 기준으로 정리했습니다.

다루는 범위를 먼저 구분합니다. 지금 시스템을 다른 팀이 이어받을 수 있는지 — 소스코드, 실행 환경, 데이터, 배포 경로, 계정 명의, 문서를 확보했는지 — 는 기존 시스템, 이어받으려면 무엇이 필요한가에서 다룹니다. 이 글은 그다음 질문, 즉 이어받은 뒤 지금 구조를 유지할지 바꿀지를 다룹니다.

선택지는 둘이 아니라 넷입니다 — 유지 · 부분 개선 · 단계적 전환 · 전면 재구축

「유지할까, 새로 만들까」로 질문을 세우면 비교가 「지금 그대로」와 「전부 새로」의 두 끝으로 좁혀집니다. 실제로 고를 수 있는 길은 그 사이에 둘이 더 있습니다.

네 선택지는 차례로 밟는 단계가 아니라 나란한 대안입니다. 유지하면서 한 영역만 개선할 수도 있고, 단계적 전환을 시작했다가 남은 범위가 작아진 시점에 나머지를 한 번에 옮길 수도 있습니다. 중요한 것은 지금 겪는 문제가 어느 선택지로 해결되는 문제인지를 먼저 구분하는 일입니다.

유지보수와 재구축의 판단 기준 — 일곱 가지 신호

판단에 쓰는 신호는 일곱 가지입니다. 신호마다 유지 쪽 근거가 되는 상태와 재구축 쪽 근거가 되는 상태, 그리고 어느 쪽인지 구분하기 위해 먼저 확인할 것을 함께 정리했습니다.

표의 한 줄이 재구축 쪽에 있다고 해서 재구축이 정해지지는 않습니다. 신호는 하나씩이 아니라 같은 원인을 가리키는지로 함께 봅니다.

무게가 가장 큰 것은 업무 적합성과 데이터 구조입니다. 이 둘은 코드를 고치는 것만으로는 바뀌지 않는 설계의 문제여서, 둘이 함께 재구축 쪽을 가리킬 때 구조를 다시 볼 근거가 가장 분명해집니다. 반대로 기술 지원, 사람, 문서의 문제는 버전 상향, 맡을 곳의 확보, 운영 문서 정리로 해결되는 경우가 있어 그것만으로 재구축을 정하기에는 근거가 약합니다.

그리고 신호가 한 영역에 모여 있으면 그 영역이 부분 개선의 대상이고, 여러 영역에 흩어진 신호가 같은 구조를 가리키면 그때가 단계적 전환이나 전면 재구축을 비교할 시점입니다.

기술의 지원 종료 — 운영 위험이지만, 그것만으로 재구축이 정해지지는 않습니다

언어, 프레임워크, 운영체제, 데이터베이스, 라이브러리는 버전마다 지원 기간이 있습니다. 예를 들어 PHP는 버전별로 정식 지원 기간과 보안 수정만 제공하는 기간을 나눠 공개하고, 지원이 끝난 버전을 쓰는 사용자에게는 수정되지 않은 보안 취약점에 노출될 수 있으니 가능한 한 빨리 올리라고 안내합니다. 지원이 끝난 뒤에도 시스템은 그대로 동작하지만, 그 뒤에 발견되는 취약점은 고쳐지지 않은 채 남습니다.

그래서 지원 종료는 미뤄 둘 수 있는 문제가 아니라 일정이 정해진 운영 위험입니다. 다만 그 위험이 곧 재구축을 뜻하지는 않습니다. 판단 기준은 지원되는 버전으로 올릴 때 바뀌는 범위입니다. 영향이 일부 모듈과 라이브러리에 머물면 유지 안에서 버전을 올리는 작업으로 다룰 수 있고, 시스템 전체가 그 버전의 동작 방식에 묶여 있어 올리는 일이 사실상 다시 만드는 일에 가깝다면 그때 단계적 전환이나 재구축을 함께 비교합니다.

운영체제나 데이터베이스 엔진처럼 시스템 아래층의 지원 종료는 애플리케이션 코드와 따로 대응할 수 있는 경우가 있습니다. AWS 환경에서 운영체제와 데이터베이스의 지원 종료에 대응하는 방법은 AWS 지원 종료 대응에 정리돼 있습니다.

작은 변경에 드는 시간 — 크기가 아니라 추세를 봅니다

「수정이 오래 걸린다」는 말은 서로 다른 두 상태를 가리킵니다. 하나는 변경마다 걸리는 시간이 길지만 일정한 상태이고, 다른 하나는 같은 크기의 변경에 드는 시간이 갈수록 늘어나는 상태입니다. 재구축 쪽 신호는 뒤쪽입니다.

앞쪽은 원인이 코드가 아니라 절차에 있는 경우가 있습니다. 테스트를 매번 수동으로 수행하거나, 배포 절차가 기록돼 있지 않아 반영할 때마다 확인할 것이 많은 경우입니다. 이때는 시스템을 새로 만들어도 같은 절차가 그대로 따라오므로, 테스트와 배포 절차를 정리하는 것이 먼저입니다.

뒤쪽은 변경 한 건의 영향 범위가 넓어졌다는 뜻입니다. 기능이 더해지는 동안 모듈 사이의 의존이 늘어, 한 곳을 고치면 다른 기능까지 함께 확인해야 하는 구조가 된 경우입니다. 오래 운영된 시스템에서는 요구가 생길 때마다 그 시점의 구조 위에 기능이 더해지므로 시간이 지나며 생기는 변화이고, 어느 한 시점의 판단만으로 설명되지 않습니다.

추세는 체감만으로 판단할 수 없습니다. 최근 변경 이력에서 요청부터 반영까지 걸린 시간과 변경 뒤에 생긴 오류를 몇 건만 모아 보아도, 어느 쪽에 가까운지 판단할 수 있습니다.

장애 — 원인이 구조에 있는지, 개별 결함인지를 구분합니다

장애가 잦다는 사실만으로는 구조의 문제라고 단정할 수 없습니다. 장애마다 발생 시각, 로그, 최근 변경을 대조해 원인을 기록해 보면 둘 중 하나로 구분됩니다.

원인이 장애마다 다르고 각각 개별 결함으로 설명된다면 수정과 재발 방지로 다룰 문제입니다. 결함이 많다는 것과 구조가 맞지 않는다는 것은 다른 말입니다. 반대로 겉으로 드러나는 증상은 다른데 원인을 따라가면 같은 데이터 처리 방식이나 같은 모듈 사이의 의존으로 이어진다면, 그 구조가 재구축을 검토할 신호입니다.

이 구분은 원인 기록이 있어야 가능합니다. 임시 조치로 종결된 장애가 많을수록 원인이 기록에 남지 않아, 구조의 문제인지 개별 결함인지 판단할 근거가 없습니다. 그래서 재구축을 검토하기 전에 원인을 정리하는 기간을 두는 것만으로 판단이 달라지는 경우가 있습니다.

단계적 전환 — 운영을 멈추지 않고 구조를 바꾸는 방법

구조를 바꿔야 한다는 결론이 나와도 곧바로 전면 재구축으로 가야 하는 것은 아닙니다. 기존 시스템을 운영하면서 기능을 하나씩 새 구성으로 옮기고, 옮긴 기능부터 사용자가 쓰게 하는 방식이 있습니다. 업계에서는 이 방식을 스트랭글러 피그(strangler fig) 패턴이라는 이름으로 정리해 두고 있습니다.

AWS 권장 가이드(Prescriptive Guidance)는 이 방식을 하나로 묶인 애플리케이션을 작은 서비스 단위로 옮기는 맥락에서 설명합니다. 기존 시스템 앞에 요청을 나누는 계층을 두고, 옮긴 기능의 요청만 새 구성으로 보내며, 모든 기능이 옮겨진 뒤에 기존 시스템을 종료하는 구조입니다. 한 번에 전환하는 방식에는 전환 위험과 업무 중단이 따른다는 점이 이 방식을 쓰는 이유로 제시됩니다. 옮기는 대상이 작은 서비스 단위가 아니어도 기능 단위로 나눠 옮긴다는 원리는 같습니다.

같은 가이드는 대가도 함께 적고 있습니다.

• 기존 시스템의 소스코드에 접근할 수 있어야 합니다. 요청을 나누려면 기존 코드를 일부 고쳐야 하기 때문입니다. 소스를 확보할 수 없다면 이 방식을 쓰기 어렵습니다.
• 업무 영역이 분명하지 않은 상태에서 서둘러 나누면 비용이 커질 수 있습니다. 기능을 나누는 경계를 잘못 정할 수 있기 때문입니다.
• 요청을 나누는 계층이 장애 지점이나 성능 병목이 될 수 있습니다. 모든 요청이 그 계층을 지나기 때문입니다.
• 옮긴 기능과 남은 기능이 같은 데이터를 쓰면 동기화가 필요합니다. 그동안 두 저장소의 데이터가 즉시 일치하지 않는 구간이 생깁니다.
• 규모가 작은 시스템에는 맞지 않을 수 있습니다. 전체를 다시 만드는 복잡도가 낮다면 새로 만드는 편이 효율적일 수 있다고 밝힙니다.

가이드는 전환 기간에도 기존 시스템의 결함 수정을 계속해 안정성을 유지하도록 설명합니다. 빌드업웍스의 정리로는, 단계적 전환은 운영을 멈출 수 없고 시스템이 커서 한 번에 바꾸기 어려울 때 맞는 방식입니다. 단계마다 결과를 확인하고 다음 범위를 조정할 수 있어, 기능을 나누는 경계를 잘 정했다면 판단이 틀렸을 때 되돌릴 지점이 남습니다. 대신 두 시스템을 함께 운영하는 기간이 길어지고, 그 기간 내내 기존 시스템의 유지보수도 계속됩니다.

재구축에서 따로 계산해야 하는 비용과 위험

전면 재구축을 비교할 때 가장 먼저 보게 되는 것은 새로 만드는 비용입니다. 그런데 재구축에는 새 시스템을 만드는 일 외에, 따로 계산하지 않으면 비교에서 빠지는 항목이 있습니다. 이 항목이 빠진 채 비교하면 판단이 재구축 쪽으로 기울어집니다.

이 중 가장 놓치기 쉬운 것이 코드에만 남은 업무 규칙입니다. 오래 운영된 시스템에는 그동안의 업무 변화가 코드에 누적되어 있습니다. 어떤 예외는 특정 시기의 사정 때문에 들어갔고, 어떤 값은 거래처나 외부 기관과의 약속을 반영합니다. 무엇을 하는지는 코드에서 읽히지만 왜 들어갔는지는 대개 기록에 없습니다. 새 시스템을 지금 화면과 담당자의 설명만으로 설계하면 이런 규칙이 빠지고, 빠졌다는 사실은 전환 뒤 그 예외 상황이 처음 발생했을 때 드러납니다.

그래서 재구축을 검토할 때도 기존 코드를 읽는 일이 먼저입니다. 이 작업은 유지를 택하든 재구축을 택하든 필요한 일이고, 어느 쪽으로 결정하든 그 결과가 그대로 쓰입니다.

전면 재구축은 이 항목들이 전환 시점 하나에 집중된다는 점에서 단계적 전환과 성격이 다릅니다. 전환일을 업무가 적은 시기에 두고, 전환 뒤 문제가 생겼을 때 기존 시스템으로 되돌아가는 절차를 미리 정해 두는 것이 이 위험을 줄이는 방법입니다.

유지를 택할 때 함께 관리해야 하는 위험

유지에도 따로 계산하지 않으면 드러나지 않는 비용이 있습니다.

• 지원이 끝난 구성의 위험 — 운영은 계속되지만 새로 발견되는 취약점은 고쳐지지 않습니다. 유지를 택한다면 버전을 올리는 계획이나, 올릴 수 없는 동안의 보완 조치를 함께 정해야 합니다.
• 특정 사람에게 묶인 지식 — 시스템을 아는 사람이 한두 명뿐이면 그 사람이 이동하거나 퇴사하는 시점이 곧 위험 시점입니다. 구조와 운영 절차를 문서로 남기는 일이 유지의 일부가 됩니다.
• 시스템 밖의 비용 — 변경이 늦어지는 동안 업무는 엑셀과 수작업으로 대신 처리됩니다. 이 시간은 유지보수 비용에 나타나지 않아 비교에서 자주 빠집니다.

이 항목들은 유지를 포기할 이유가 아니라 유지를 택할 때 함께 관리할 항목입니다. 관리할 수 있다면 유지가 합리적이고, 관리할 수 없는 수준이라면 그것이 단계적 전환이나 재구축을 비교할 근거가 됩니다.

판단하기 전에 확인할 것 — 현황 · 측정 · 소스

네 선택지를 같은 기준으로 비교하려면 세 가지를 먼저 확보해야 합니다. 세 가지 모두 어느 쪽으로 결정하든 그대로 쓰이는 자료입니다.

1. 현황 파악 — 구성 요소 목록(언어 · 프레임워크 · 운영체제 · 데이터베이스와 각각의 버전, 외부 연동), 기능 목록, 그리고 시스템 밖에서 처리하는 작업의 목록입니다. 일곱 가지 신호 대부분이 이 목록에서 파악됩니다.
2. 측정 — 「느리다」 · 「자주 멈춘다」를 재현 조건과 지표로 바꿉니다. 어떤 화면이 어떤 조건에서 얼마나 걸리는지, 장애가 언제 어떤 원인으로 났는지를 기록합니다. 측정이 있어야 개선 전후를 같은 조건으로 비교할 수 있고, 재구축을 택하더라도 새 시스템이 충족해야 할 기준이 됩니다.
3. 소스 확보 — 운영 중인 버전의 소스와 변경 이력을 확보했는지입니다. 소스가 없으면 유지, 부분 개선, 단계적 전환 모두 할 수 있는 범위가 크게 줄어 선택지 자체가 달라집니다. 무엇이 있어야 하고 어떻게 확인하는지는 기존 시스템, 이어받으려면 무엇이 필요한가에 정리돼 있습니다.

세 가지가 갖춰지지 않은 상태에서는 어느 쪽을 택해도 그 근거를 설명하기 어렵습니다. 특히 측정이 없으면 유지를 택한 뒤에는 개선됐는지를, 재구축을 택한 뒤에는 새 시스템이 나아졌는지를 확인할 방법이 없습니다.

빌드업웍스가 유지와 재구축 판단을 다루는 방식

빌드업웍스는 이 판단을 소프트웨어 관리·개선의 진행 순서 안에서 다룹니다.

• 시작은 30분 무료 상담입니다. 상담 뒤 이어받을 수 있는 상태인지와 먼저 확보할 것을 서면으로 정리해 드립니다. 서면 요약은 상담에서 들은 내용을 기준으로 하며, 계정 비밀번호나 데이터 원본은 요구하지 않습니다.
• 코드와 실행 환경을 직접 확인하는 일은 인수인계 · 안정화 단계에서 진행합니다. 이 단계부터 프로젝트 견적으로 비용이 발생합니다. 코드 · 빌드 · 배포 · 계정 · 백업과 복구 절차를 점검하고 운영 문서와 위험 목록을 만들며, 반복되는 오류가 있으면 원인부터 정리합니다.
• 유지가 적합하면 유지하고, 필요한 부분만 개선합니다. 이후의 오류 수정과 정기 업데이트, 합의한 범위 안의 개선은 월 정액 운영으로 이어집니다.
• 재구축이 더 합리적이라고 판단되면 그 근거를 먼저 설명드립니다. 소스를 확보할 수 없는 경우에는 소스 확보 방법, 일부 기능의 재구축, 전체 재구축을 나란히 놓고 각각의 비용과 위험을 설명드립니다. 결정은 고객사가 합니다.
• 단계적 전환이나 구조 변경은 범위와 비용을 따로 정해 별도 견적으로 진행합니다. 전면 재구축으로 새로 만드는 시스템은 AI · 앱 개발에서 범위와 일정을 정해 진행하고, 출시 뒤의 운영은 선택에 따라 소프트웨어 관리·개선으로 이어갈 수 있습니다.

합의한 범위를 넘는 작업은 착수 전에 범위와 비용을 안내하고 승인을 받은 뒤 진행합니다. AWS가 아닌 Azure · GCP · 자체 서버 · 호스팅에서 운영 중인 소프트웨어도 환경과 접근 방법을 확인한 뒤 같은 순서로 진행합니다.

다음 단계

이어받기에 필요한 소스코드 · 실행 환경 · 데이터 · 배포 경로 · 계정 명의 · 문서를 지금 확보했는지부터 확인해 보고 싶으시면 이어받기 진단을 이용하실 수 있습니다. 연락처 없이 바로 결과를 보여 드리고, AWS를 쓰지 않으셔도 됩니다.

지금 상황이 어느 쪽에 가까운지 먼저 정리하고 싶으시면 기존 시스템을 계속 잘 쓰고 싶습니다에서 상황별로 무엇부터 확인하면 되는지 보실 수 있습니다.

운영 중인 시스템을 두고 네 선택지를 함께 정리하고 싶으시면 상담 신청을 남겨 주십시오. 30분 상담으로 시작합니다. 확인 결과 유지가 적합하다면 그렇게 말씀드리고, 재구축이 적합하다면 그 근거부터 말씀드립니다.

참고 자료

• AWS Prescriptive Guidance — 스트랭글러 피그 패턴(Strangler fig pattern)
• PHP — 지원 버전 안내(Supported Versions)