기술 부채 이해하기

Wikipedia에 따르면: “기술 부채(설계 부채 또는 코드 부채라고도 함)는 “최선의 전체적인 솔루션을 적용하는 대신 단기적으로 구현하기 쉬운 코드를 사용할 때 발생하는 추가 개발 작업을 반영하는 프로그래밍 개념”입니다.

기술 부채는 금전적 부채에 비유할 수 있습니다. 기술 부채를 상환하지 않으면 ‘이자’가 쌓여 나중에 변경 사항을 구현하기가 더 어려워집니다. 해결되지 않은 기술 부채는 소프트웨어 엔트로피를 증가시킵니다. 기술 부채가 반드시 나쁜 것은 아니며, 때로는(예: 개념 증명으로) 프로젝트를 진전시키기 위해 기술 부채가 필요하기도 합니다. 반면, 일부 전문가들은 “기술 부채” 비유가 그 영향을 최소화하는 경향이 있어 이를 수정하는 데 필요한 작업의 우선순위가 충분히 설정되지 않는다고 주장합니다.”

기술 부채의 개념은 소프트웨어 엔지니어링 분야에서 비롯되었지만, IT와 비즈니스 인프라 세계에도 똑같이 적용됩니다. 소프트웨어 엔지니어링과 마찬가지로 우리는 시스템과 네트워크를 설계하며, 이상적이지 않은 설계로 작업하거나 기존 하드웨어를 통합하는 등의 설계상 지름길을 택하는 것은 기술 부채를 만들어냅니다. 가장 중요한 형태 중 하나는 “미래”가 아닌 “과거”에 투자하는 것으로, 이는 매몰 비용 오류(즉, 밑 빠진 독에 물 붓기)를 통해 촉발되는 경우가 매우 많습니다.

이런 상황은 매일 기업에서 쉽게 볼 수 있습니다. 미래를 위한 새로운 계획이 수립되지만, 구현되기 전에 오래된 시스템 설계가 계속 작동하고, 더 잘 작동하거나 확장될 수 있도록 투자가 이루어집니다. 이 투자는 그 후 거의 즉각적인 재정 손실로 이어지거나, 더 흔하게는, 미래 설계에 신속하게, 충분히, 또는 아예 투자하지 않는 유인이 됩니다. 최악의 경우 과거에 대한 투자가 치명적으로 작용할 수 있습니다.

이런 일은 다양한 방식으로 발생하며 대체로 의도치 않게 일어납니다. 기존 시스템을 제대로 운영하기 위해 투자가 필요한 경우가 많으며, 정상적인 상황에서는 단순히 실행될 것입니다. 하지만 미래에 필요하거나 계획될 변경이 있는 상황에서는 이 투자가 문제가 될 수 있습니다. 하지만 많은 경우, 더 나은 비용 분석과 우선순위 계획으로 이를 해결할 수 있습니다.

비기술적인 예를 들면, 잘 사용해 왔지만 3개월 후 은퇴시킬 예정인 오래된 자동차를 소유하고 있다고 상상해 보세요. 3개월 후에는 지속적인 유지 보수 필요, 낮은 효율성 등으로 인해 비용 효율적이지 않기 때문에 새 자동차에 투자할 계획입니다. 그런데 3개월 안에 새 자동차를 구매하려는 계획을 세우기 전에, 오래된 자동차가 경미한 고장을 일으켜 계속 운행하기 위해 상당한 투자가 필요하게 됩니다. 오래된 자동차에 돈을 쓰는 것은 기술 부채에 새로운 투자를 하는 것입니다. 몇 달 더 오래된 자동차를 운행하기 위해 큰 돈을 쓰는 대신, 새 자동차 구매 일정을 앞당기는 것이 재정적으로 훨씬 현명하다는 것은 분명합니다. 자동차의 경우에는 대부분 이것을 쉽게 알 수 있습니다. 새 자동차를 빨리 구매함으로써 돈을, 경우에 따라서는 많은 돈을 절약합니다. 오래된 자동차에 크게 투자하면, 몇 달 안에 그 투자를 잃거나, 이미 이루어진 새 자동차 구매를 위한 탄탄한 재정 계획을 바꿀 위험이 있습니다. 두 경우 모두 재정적으로 좋지 않습니다.

IT도 마찬가지입니다. 호스팅 이메일 시스템으로의 마이그레이션이 계획된 6개월 전에 오래된 이메일 시스템 유지에 큰 비용을 쓰는 것은 매우 어리석은 일일 것입니다. 그 투자는 오래된 시스템이 폐기될 때 거의 즉시 손실로 이어지거나, 우리의 좋은 계획 프로세스를 약화시켜 계획된 대로 마이그레이션을 진행하지 않고 기술 부채가 올바른 계획 대신 의사결정을 주도하도록 내버려 두어 비즈니스에 부실한 결과를 초래합니다.

종종 잘못된 우선순위 운영이나 우선순위 결정권자에 대한 부적절한 권한이 미래를 내다보는 신속한 투자 대신 긴급한 기술 부채 투자를 유발하는 요인이 될 수 있습니다. 이것은 주요 개선이 문제를 해결할 수 있는 하나의 영역에 불과하지만 중요한 영역입니다. 이는 또한 경우에 따라 성장으로 인한 용량 확장 필요처럼 시스템 계획이 시작되기 전에 발생할 수 있는 일반적이거나 예상되는 긴급 상황에 대비한 투자 계획을 갖추기 위한 “만약” 계획을 통해 완화될 수 있습니다.

일반적인 기술 부채의 또 다른 좋은 예는 서버 스토리지 용량 확장입니다. 이것은 제가 어느 정도 빈번하게 보는 시나리오이며 기술 부채를 잘 보여줍니다. 기업이 내부 스토리지 용량이 부족한 서버를 구매하는 것은 흔한 일입니다. 즉시 또는 언젠가 더 많은 용량이 필요하게 됩니다. 즉시 이런 상황이 발생하면 구매한 서버가 잘못된 설계의 기술 부채 형태였으며 계획 및 구매 프로세스의 결함을 명백히 나타낸다는 것을 알 수 있습니다.

하지만 더 일반적인 예는 서버 구매 후 2~3년 후에 스토리지를 확장해야 하는 경우입니다. 일반적인 확장 방법으로는 외부 스토리지 어레이를 서버에 연결하거나 서버를 수정하여 더 많은 로컬 스토리지를 수용하는 것이 있습니다. 이 두 접근 방식은 모두 이미 오래된 서버, 즉 유용한 수명의 40% 이상을 쉽게 지난 서버에 대한 대규모 투자가 되는 경향이 있습니다. 많은 경우 같거나 약간 더 높은 투자로 완전히 새로운 서버를 구매하면 새 하드웨어, 더 빠른 CPU, 더 많은 RAM, 필요한 스토리지, 목적에 맞게 설계되고 구축된 시스템, 갱신된 지원 수명 주기, 더 작은 데이터센터 풋프린트, 낮은 전력 소비, 새로운 기술 및 기능, 더 나은 벤더 관계 등을 얻을 수 있으며, 원래 서버는 재사용, 폐기 또는 재판매할 수 있습니다. 한 가지 방법은 과거를 지원하는 데 돈을 쓰는 것이고, 다른 방법은 종종 비슷한 비용으로 미래에 투자할 수 있습니다.

기술 부채는 많은 기업에 치명적인 요소입니다. IT 비용을 경우에 따라 크게 증가시키고, 계획의 부족과 대부분의 지출이 긴급 기반이 됨으로써 높은 수준의 위험으로 이어질 수 있습니다.