개인적으로 제가 기업에서 성공하지 못하는 이유중 하나가 이거 인 것 같습니다. 저는 솔직히 회사에서 신규 서비스 런칭보다 불필요한 시스템 폐기가 눈에 먼저 들어옵니다. 사실 성과위주의 회사에서 이건 위험한 행동에 가깝습니다. 왜냐면 치적성 시스템들이 많고 이런 작업은 높은 분들 눈밖에 나는 행동이니까요. 실제로 이런 운영방식으로 국내 대기업에서 하위 평가를 받기도 했고요. (그때 위에 임원분이 저를 너무 싫어하셨죠.)

하지만 저는 아직도 이 생각이 틀리지 않았다고 생각합니다. 그리고 오히려 이런 생각은 회사의 오너나 높은 분들이 더 잘 알아야 된다고 생각합니다. 하지만 매출에 신경쓰느라 이런 활동을 못하는 경우가 많죠. 이 포스트를 높은 분들이 볼일을 없겠지만 그래도 적어봅니다.

쓰레기통을 비우지 않는 회사: 새로운 시스템 구축보다 ‘폐기’가 중요한 이유

많은 기업이 새로운 시스템을 구축하고 도입하는 데 막대한 예산과 인력을 투자합니다. 최신 클라우드 아키텍처를 도입하고, AI 기반의 자동화 툴을 붙이며, 트렌디한 기술 스택을 쌓아 올리는 작업은 엔지니어와 경영진 모두에게 가시적인 성과로 보이기 때문입니다.

하지만 정반대의 작업, 즉 수명을 다한 레거시 시스템을 안전하게 제거하는 ‘폐기(Decommissioning)’에 대해서는 놀라울 정도로 무관심합니다. 쓰레기통이 가득 차면 비워야 공간이 생기고 악취가 나지 않듯, IT 인프라도 사용하지 않는 시스템을 제때 비워내야 조직이 건강해집니다.

과거에 실제로 경험했던 ‘1년에 단 1명만 사용하는 시스템’의 운영 및 셧다운 사례를 바탕으로, 기술 부채와 보안 리스크 측면에서 왜 시스템을 ‘지우는 것’이 새로운 것을 ‘만드는 것’보다 중요한지 엔지니어링 관점에서 분석합니다.

1. 1년에 단 1명이 사용하는 보안 시스템의 역설

과거 모 대기업에서 운영을 맡았던 특정 시스템이 있었습니다. 이 시스템은 조직 내에서 매우 기형적인 형태로 잔존해 있었습니다.

• 실제 이용 현황: 1년에 단 1명의 사용자만 실수로 로그인 하였음
• 유지보수 비용: 고정적인 인프라 비용, 라이선스 비용, 모니터링 공수가 지속적으로 발생함.
• 내부 데이터: 시스템 규모나 이용률에 비해, 내부에는 기업의 핵심 자산에 준하는 상당히 중요한 시스템 정보와 민감 데이터가 대량으로 저장되어 있음.

이러한 불균형은 심각한 운영 패러독스를 낳습니다. 이용자가 거의 없기 때문에 대대적인 예산을 투입하여 최신 보안 패치를 적용하거나 아키텍처를 고도화하기는 어렵습니다. 반대로 내부에 탑재된 정보의 중요도가 높기 때문에, 취약점이 발견되더라도 선뜻 손을 대지 못하고 방치하는 악순환이 발생합니다.

2. 왜 사용하지 않는 시스템의 셧다운은 반려되는가?

사용자가 없고 비용만 축내는 시스템이라면 즉시 격리하거나 폐기하는 것이 상식적인 엔지니어링 판단입니다. 그러나 실제 기업 환경에서는 다음과 같은 비기술적 요인으로 인해 셧다운이 지속적으로 반려되곤 합니다. 당사의 사례에서도 셧다운 기안이 승인되기까지 무려 2년이라는 세월이 걸렸고, 저는 2년간 하위고과를 받았습니다.

2.1. 거버넌스와 사내 정치적 이해관계

해당 시스템은 과거 보안 팀장이 주도하여 구축한 이른바 ‘치적성 프로젝트’였습니다. 조직 내에서 특정 임원이나 팀장의 주도로 만들어진 시스템은, 해당 인물이 영향력을 유지하고 있는 한 ‘실패한 시스템’ 혹은 ‘불필요한 시스템’으로 분류되기 어렵습니다. 시스템을 종료하는 행위 자체가 과거의 의사결정이 잘못되었음을 시인하는 꼴이 되기 때문입니다.

2.2. 모호한 데이터 소유권과 리스크 회피 성향

시스템 내부에 중요한 정보가 포함되어 있을수록 의사결정권자들은 방어적인 태도를 취합니다. “만약 이 시스템을 껐다가 3년 뒤에 가끔 쓰던 데이터가 필요해지면 누가 책임질 것인가?”라는 질문에 누구도 선뜻 책임지려 하지 않습니다. 결과적으로 ‘아무것도 하지 않는 것이 가장 안전하다’는 관료제적 마인드가 작동하여, 매달 비용이 차감되는 상황을 묵인하게 됩니다.

3. 방치된 레거시 시스템이 유발하는 기술적·보안적 리스크

엔지니어링 관점에서 사용되지 않는 레거시 시스템을 방치하는 것은 단순한 비용 낭비를 넘어 조직 전체의 보안 인프라를 무너뜨리는 트리거가 됩니다.

3.1. 보안 취약점의 사각지대화 (Shadow IT 및 좀비 시스템)

최신 시스템은 지속적인 데브옵스(DevOps) 파이프라인과 모니터링 체계 하에 관리되므로 취약점 점검(CVE) 및 패치가 실시간으로 이루어집니다. 반면, 담당자가 명확하지 않고 이용률이 낮은 좀비 시스템은 OS 업데이트, 오픈소스 라이선스 패치, SSL/TLS 인증서 갱신 등 기본적인 관리 주기에서 소외됩니다.

실제로 수많은 기업 침해 사고의 시발점은 메인 서비스가 아닌, 인프라 구석에 방치되어 있던 테스트 서버나 과거의 레거시 관리자 페이지였습니다. 중요 정보가 들어있음에도 보안 투자를 받지 못하는 시스템은 공격자에게 가장 매력적인 타깃이 됩니다.

3.2. 인프라 복잡도 증가 및 모니터링 노이즈

클라우드 및 온프레미스 환경에서 연결된 레거시 시스템은 전체 아키텍처의 복잡도를 불필요하게 높입니다. 레거시 시스템이 사용하는 오래된 프로토콜이나 방화벽 정책을 유지하기 위해 네트워크 보안 규칙을 느슨하게 열어두어야 하는 경우가 발생합니다. 또한, 주기적인 헬스 체크나 보안 솔루션에서 발생하는 오탐(False Positive) 알람은 운영 엔지니어의 피로도를 가중시켜 정작 중요한 보안 이벤트를 놓치게 만드는 요인이 됩니다.

4. ‘비가시적 업무’의 한계: 폐기는 왜 성과로 인정받지 못하는가

기업 환경에서 폐기 작업이 지연되는 근본적인 원인 중 하나는 성과 측정 시스템(KPI)의 한계에 있습니다. 새로운 인프라를 구축하거나 신규 보안 솔루션을 도입하는 것은 눈에 보이는 ‘개발 성과’나 ‘도입 실적’으로 쉽게 포장됩니다. 정량적인 지표로 상부에 보고하기가 매우 용이합니다.

반면, 기존에 작동하던 시스템을 중단하고 안전하게 삭제하는 작업은 ‘문제없이 잘 가동되던 것을 정지시키는 리스크’로 인식될 뿐, 그 자체로 인사고과나 팀의 핵심 성과로 인정받기 어렵습니다. 인프라 비용을 줄였다 하더라도, 이는 ‘상수’로 지출되던 예산의 절감일 뿐 신규 매출이나 비즈니스 혁신처럼 화려한 지표로 드러나지 않습니다. 결국 개발 팀이나 인프라 운영 팀 모두 리스크를 짊어지면서까지 폐기 작업을 주도할 동인이 부족해집니다.

5. 제언: 시스템 폐기는 ‘보안 조직’이 전담 거버넌스를 가져야 한다

시스템을 생성할 때 보안성 심의와 인프라 검토를 필수적으로 거치듯이, 시스템의 수명이 다했을 때 안전하게 문을 닫는 프로세스 역시 별도의 전문 검토 단계가 필요합니다. 성과 배분에서 자유롭고, 기업 전체의 자산 보호를 최우선으로 하는 보안 조직이 폐기 거버넌스를 주도해야 하는 이유는 다음과 같습니다.

5.1. 라이프사이클의 완성: 생성(Review)부터 폐기(Sunset)까지

대다수 기업의 보안 프로세스는 초기 아키텍처 검토와 규제 준수(Compliance) 확인 등 ‘시작’ 단계에만 집중되어 있습니다. 하지만 진정한 데이터 거버넌스는 시스템이 소멸하는 순간까지 안전하게 관리되는 것을 의미합니다. 보안 조직이 ‘시스템 폐기 심의 절차’를 수립하고, 정기적으로 조직 내 유휴 자산을 실사하여 강제로 셧다운 시킬 수 있는 권한을 가져야 합니다.

5.2. 공격 표면(Attack Surface) 최소화 관점의 접근

앞서 언급했듯 유휴 시스템은 기업 보안의 가장 약한 고리입니다. 인프라나 개발 팀은 기능적 요구사항이나 데이터 미련 때문에 셧다운을 주저하지만, 보안 조직은 ‘공격 표면 축소’라는 명확한 목표를 가집니다. 성과 측면에서도 보안 조직은 ‘보안 사고 예방 및 자산 건전성 확보’를 지표로 삼기 때문에, 유휴 시스템 폐기를 적극적인 리스크 제거 성과로 환산할 수 있습니다.

6. 안전한 시스템 폐기(Decommissioning)를 위한 프레임워크

2년간의 지리한 설득 끝에 해당 시스템을 최종적으로 셧다운 시키면서 체득한 안전한 폐기 프로세스는 다음과 같습니다. 무작정 서버 전원을 내리는 것은 엔지니어링이 아닙니다.

[시스템 식별] -> [보안/법적 데이터 백업 심의] -> [네트워크 격리] -> [최종 로그 분석] -> [자원 완전 소멸]

단계 1: 데이터 아카이빙 및 암호화 이관

시스템 내부에 존재하던 중요한 정보는 원본 데이터베이스에서 추출하여 cold storage(예: AWS S3 Glacier 등)로 이관해야 합니다. 이 과정에서 데이터 유실을 방지하기 위한 무결성 검증(Checksum 작업)을 수행하고, 법적 규제 준수 기간을 고려하여 암호화된 상태로 보관 라이프사이클을 지정합니다.

단계 2: 단계적 네트워크 격리 (Soft Shutdown)

서버를 바로 삭제하지 않고 외부 혹은 내부 타 시스템과의 네트워크 연결을 먼저 차단합니다. 방화벽 규칙을 통해 인바운드 트래픽을 원천 차단하고 약 1~3개월간 추이를 살핍니다. 이 기간 동안 정말로 시스템을 찾는 사용자나 타 시스템의 API 호출이 없는지 로그 분석을 통해 최종 확인합니다.

단계 3: 자원 회수 및 자산 대장 현행화

트래픽이 전혀 없음을 확인한 후 가상머신(VM) 및 컨테이너를 가동 중지하고, 할당되어 있던 인프라 자원(컴퓨트, 스토리지, 고정 IP 등)을 회수합니다. 마지막으로 기업 내부의 IT 자산 관리 대장(CMDB)에서 해당 시스템의 상태를 ‘폐기’로 변경하여 관리의 연속성을 확보합니다.

7. 결론: 비우는 것이 곧 고도화다

소프트웨어 엔지니어링의 미덕은 흔히 코드를 더 많이 작성하고, 더 큰 시스템을 빌드하는 것으로 오해받곤 합니다. 그러나 진정한 시니어 엔지니어와 성숙한 IT 조직은 ‘지워야 할 때를 알고 깔끔하게 지우는 역량’을 가집니다.

1년에 한 명이 쓰는 시스템을 위해 보안 취약점을 방치하고 비용을 지출하는 것은 기술적 태만입니다. 새로운 솔루션을 도입하기 전에, 현재 우리 인프라의 쓰레기통이 가득 차 있지는 않은지, 과거의 정치적 유산이라는 이유로 방치된 좀비 시스템은 없는지 점검해야 합니다. 폐기 업무를 개별 엔지니어의 고과에 맡겨두지 말고, 보안 조직의 핵심 거버넌스로 편입시켜 프로세스화해야 합니다. 불필요한 시스템을 안전하게 셧다운 하는 것이야말로 기업의 공격 표면을 줄이고 인프라 비용을 최적화하는 가장 확실한 보안 고도화 전략이라고 저는 생각합니다.