레거시 코드는 얼마나 나빠질 수 있는가보다, 사업이 어디까지 감당할 수 있는가를 정해야 한다

새 기능 하나를 추가하는 데 여러 팀의 승인과 수작업 검증이 필요하고, 작은 변경도 장애를 걱정해 배포를 미루는 상황이 반복될 수 있습니다. 이때 CTO와 개발 리더가 마주하는 질문은 “코드가 너무 나빠졌는가”가 아닙니다. 더 중요한 질문은 “이 상태의 운영 비용과 변경 위험을 사업이 앞으로도 감당할 수 있는가”입니다.

레거시 코드는 물리적 구조물처럼 어느 날 한계에 도달해 자동으로 붕괴하지 않습니다. 기능은 계속 붙일 수 있고, 예외 처리 위에 예외 처리를 더할 수도 있으며, 느린 흐름을 사람의 확인 절차로 보완할 수도 있습니다. 시스템이 돌아간다는 사실만으로는 유지 전략이 옳다는 근거가 되지 않습니다.

보수, 부분 리팩터링, 재작성 중 무엇을 택할지는 코드의 미관이나 개발자의 피로만으로 결정하기 어렵습니다. 사업이 잃는 시간, 고객과 운영자가 떠안는 위험, 앞으로 바꿔야 할 업무 규칙을 함께 봐야 합니다.

오해: 코드가 충분히 나빠지면 재작성 시점이 저절로 온다

현실: 시스템보다 사업의 인내 한계가 먼저 드러난다

코드는 불편하고 복잡한 상태로도 오래 작동할 수 있습니다. 장애가 나면 담당자가 수동으로 데이터를 고치고, 배포가 불안하면 변경 횟수를 줄이고, 성능이 떨어지면 더 많은 인프라나 운영 인력을 투입하는 식입니다. 이런 대응은 당장의 중단을 막지만, 비용을 보이지 않는 곳으로 옮깁니다.

따라서 재작성 논의를 시작하는 신호는 “코드가 지저분하다”보다 다음과 같은 사업·운영 변화에 가깝습니다.

• 중요한 기능의 출시 시점을 기술 검증이나 회귀 테스트 때문에 반복해서 맞추지 못한다.
• 장애 자체보다 원인 확인, 영향 범위 파악, 데이터 정합성 복구에 더 많은 시간이 든다.
• 특정 인력의 기억이나 수동 작업 없이는 정상 운영을 보장하기 어렵다.
• 고객 계약, 보안 요구, 감사 대응, 정산 정확성 같은 조건을 현재 구조에서 입증하기 어렵다.
• 트래픽 증가나 제품 확장에 따라 인프라 비용, 외부 연동 비용, 운영 인력이 매출이나 서비스 가치보다 빠르게 늘어난다.
• 새 시스템을 만드는 팀과 기존 시스템을 유지하는 팀 사이의 의존성이 늘어, 어느 쪽도 독립적으로 일정과 품질을 관리하지 못한다.

이 신호들은 모두 재작성을 뜻하지는 않습니다. 다만 기술 부채를 “나중에 갚으면 되는 개발 과제”로 두기 어려워졌다는 뜻은 될 수 있습니다.

오해: 유지보수와 재작성 사이에는 리팩터링이라는 안전한 중간 선택지가 있다

현실: 변경 경계가 분명할 때만 부분 리팩터링이 효과를 낸다

부분 리팩터링은 대개 가장 현실적인 선택으로 보입니다. 그러나 경계를 잘못 잡으면 기존 복잡성 위에 새 구조를 덧붙이는 결과가 됩니다. 새 서비스, 새 데이터 저장소, 새 메시지 처리 계층을 추가했지만 업무 규칙과 운영 절차는 이전 시스템에 계속 묶이는 경우가 여기에 해당합니다.

부분 리팩터링을 검토할 때는 모듈 이름이나 기술 스택보다 업무 흐름의 경계를 먼저 확인해야 합니다. 예를 들어 주문, 결제, 정산, 고객 알림처럼 하나의 흐름이 여러 시스템을 통과한다면, 화면이나 API 하나만 떼어내는 작업은 의존성을 줄이지 못할 수 있습니다.

다음 조건이 갖춰질수록 부분 리팩터링의 성공 가능성은 높아집니다.

1. 입력과 결과를 명확히 정의할 수 있다. 새 모듈이 어떤 데이터를 받고 어떤 상태를 반환하는지 합의돼 있어야 합니다.
2. 기존 기능과 병행 검증할 수 있다. 같은 입력에 대해 기존 처리와 새 처리를 비교하거나, 일부 사용자·업무만 새 경로로 전환할 수 있어야 합니다.
3. 데이터 소유권을 나눌 수 있다. 두 시스템이 같은 데이터를 서로 수정해야 한다면, 분리는 운영 복잡성을 키울 가능성이 큽니다.
4. 운영 책임도 함께 옮길 수 있다. 코드만 새로 만들고 장애 대응, 모니터링, 권한 관리, 정산 확인은 예전 절차에 남기면 이중 운영이 시작됩니다.

반대로 업무 규칙이 문서화돼 있지 않고, 여러 팀이 같은 데이터와 기능을 비공식적으로 공유하며, 현재 동작 자체를 재현하기 어렵다면 리팩터링의 첫 산출물은 코드가 아닐 수 있습니다. 어떤 주문이 어떤 상태를 거쳐 누구의 책임으로 완료되는지부터 확인해야 합니다.

유지보수, 리팩터링, 재작성을 가르는 네 가지 운영 지표

의사결정 회의에서는 “기술 부채가 크다”는 평가를 측정 가능한 운영 질문으로 바꾸는 편이 낫습니다. 아래 네 축은 업종과 시스템 규모가 달라도 비교 기준으로 활용할 수 있습니다.

판단 축	유지보수를 우선할 조건	부분 리팩터링을 검토할 조건	재작성을 검토할 조건
변경 비용	특정 영역의 수정이 예측 가능하고 회귀 범위가 제한적이다	반복 변경이 한두 업무 흐름에 집중된다	거의 모든 변경이 광범위한 영향 분석과 긴 검증을 요구한다
운영 복구	장애 원인과 복구 절차가 알려져 있으며 담당자가 교대 가능하다	취약한 구성 요소가 분명하고 격리할 수 있다	장애 시 영향 범위와 데이터 상태를 신뢰성 있게 파악하기 어렵다
사업 확장	현재 제품·시장 전략이 크게 바뀌지 않는다	새 기능이 기존 기능과 구분되는 경계를 가진다	앞으로의 제품 모델, 고객 유형, 거래 방식이 기존 가정과 충돌한다
통제 가능성	보안, 권한, 감사, 데이터 보존 요구를 현 구조에서 충족할 수 있다	통제가 필요한 영역을 우선 분리할 수 있다	필요한 통제를 추가할수록 예외와 수작업이 누적된다

여기서 중요한 것은 지표의 절대값이 아니라 추세입니다. 예를 들어 배포 횟수가 적어도 사업이 안정적이고 변경 요구가 제한적이라면 유지보수가 합리적일 수 있습니다. 반면 경쟁 환경 때문에 빠른 실험이 필요하거나, 오류 한 건의 손실이 큰 금융·정산·공급망 업무라면 같은 수준의 지연도 더 빨리 한계로 이어질 수 있습니다.

오해: 재작성은 기술적으로 더 좋은 시스템을 만들면 성공한다

현실: 기존 시스템이 품고 있던 운영 규칙을 옮기지 못하면 새 시스템도 위험해진다

재작성의 가장 큰 위험은 기존 코드에 숨어 있는 업무 규칙을 과소평가하는 데 있습니다. 오래된 조건문, 수동 승인 절차, 특정 시점의 데이터 보정 로직은 보기에는 불합리해도 과거의 고객 약속, 예외 거래, 외부 기관 연동 조건을 반영했을 수 있습니다.

그래서 재작성 프로젝트는 “새 아키텍처 설계 완료”를 중간 목표로 삼기보다, 다음 순서로 위험을 줄이는 편이 좋습니다.

• 먼저 현재 시스템의 핵심 업무 결과를 정의합니다. 어떤 거래가 성공으로 간주되는지, 실패하면 누가 무엇을 확인하는지 적습니다.
• 운영 로그, 장애 기록, 고객 문의, 정산 차이, 수동 처리 목록을 함께 검토합니다. 코드에 없는 규칙은 이런 흔적에서 발견될 수 있습니다.
• 새 시스템이 대체할 범위를 작게 고정합니다. 모든 기능을 한 번에 옮기는 계획은 기존 시스템을 이해하는 동안 요구사항이 바뀔 위험이 큽니다.
• 병행 운영의 종료 조건을 정합니다. 새 시스템을 만들기 전에 언제 기존 경로를 끌지, 어떤 데이터 검증과 운영 승인 후 전환할지를 합의해야 합니다.
• 기존 시스템에 새 기능을 계속 붙일지에 대한 원칙도 세웁니다. 이 원칙이 없으면 전환 중인 시스템과 기존 시스템이 함께 커집니다.

재작성은 과거를 깨끗이 지우는 일이 아니라, 사업에 필요한 동작과 통제 방식을 더 관리 가능한 형태로 다시 소유하는 작업에 가깝습니다.

기술 부채의 한계를 코드가 아니라 운영 예산으로 정의하라

기술 부채 관리에는 “더 나빠지기 전에 고치자”는 말만으로 부족합니다. 그 대신 조직이 감당하지 않기로 한 운영 상태를 명시해야 합니다. 예를 들면 핵심 기능의 변경 리드타임이 사업 일정에 영향을 주는 상태, 장애 후 데이터 복구를 담당자 개인의 판단에 맡기는 상태, 보안·감사 요구를 수작업 증빙으로 버티는 상태처럼 말입니다.

이 한계는 개발팀만 정할 수 없습니다. 제품 책임자는 출시 지연이 잃게 하는 기회를, 운영 책임자는 수동 절차와 장애 대응 부담을, 보안·재무·사업 부서는 오류와 통제 실패의 비용을 함께 밝혀야 합니다. 개발 리더는 그 조건을 시스템 구조와 이행 계획으로 연결해야 합니다.

다음 분기 계획을 세울 때 “무엇을 다시 만들 것인가”부터 정하지 않아도 됩니다. 먼저 현재 시스템에서 사업이 더는 허용하지 않을 운영 상태 세 가지를 적어 보십시오. 그 상태를 가장 먼저 줄일 수 있는 선택이 유지보수인지, 경계가 분명한 리팩터링인지, 제한된 범위의 재작성인지 판단하는 출발점이 됩니다.