기술 부채를 요약하는 세 가지 문제

기술 부채를 요약하는 세 가지 문제

작성자: 딘 포크너, 마틴 로빈슨, 제임스 우서

 

기술 부채는 소프트웨어 개발 과정에서 발생하는 부정적인 요소로 여겨져 왔다. 그러나 최근에는 기술 부채를 기회의 창으로 바라보는 시각이 늘어나고 있다. 기술 부채를 적극적으로 관리하고 개선함으로써, 소프트웨어의 품질과 성능을 향상시키고, 비용을 절감하며, 새로운 기회를 창출할 수 있다는 것이다. 기술 부채는 소프트웨어 개발자가 기술적 완벽성을 추구하기보다는, 비용과 시간의 제약을 고려하여 최소한의 기능을 구현하기 위해 발생하는 부정적인 요소로 여겨져 왔다. 기술 부채가 발생하면, 소프트웨어의 품질과 성능이 저하되고, 유지 보수와 확장에 어려움을 겪게 된다. 또한, 기술 부채는 비용 증가로 이어질 수 있다. 그러나 최근에는 기술 부채를 기회의 창으로 바라보는 시각이 늘어나고 있다. 기술 부채를 적극적으로 관리하고 개선함으로써, 소프트웨어의 품질과 성능을 향상시키고, 비용을 절감하며, 새로운 기회를 창출할 수 있다는 것이다.   기술 부채를 기회의 창으로 활용하기 위해서는, 다음과 같은 노력이 필요하다. -       기술 부채를 정확히 파악한다. 기술 부채를 파악하기 위해서는, 코드 분석, 테스트, 성능 측정 등의 방법을 활용할 수 있다. -       기술 부채의 우선순위를 정한다. 기술 부채는 발생 원인, 영향도, 해결 난이도 등을 고려하여 우선순위를 정해야 한다. -       기술 부채를 점진적으로 해결한다. 기술 부채를 한꺼번에 해결하기보다는, 점진적으로 해결하는 것이 효과적이다.   기술 부채를 적극적으로 관리하고 개선함으로써, 다음과 같은 효과를 얻을 수 있다. -       소프트웨어의 품질과 성능 향상 -       유지 보수 및 확장의 용이성 -       비용 절감 -       새로운 기회의 창출   기술 부채는 소프트웨어 개발에서 피할 수 없는 요소이다. 그러나 이를 적극적으로 관리하고 개선함으로써, 소프트웨어의 가치를 높이고, 비즈니스의 성공을 도모할 수 있다. 기술 부채는 부정적인 요소로만 인식되어 왔지만, 최근에는 기회의 창으로 바라보는 시각이 늘어나고 있다. 기술 부채를 적극적으로 관리하고 개선함으로써, 소프트웨어의 품질과 성능을 향상시키고, 비용을 절감하며, 새로운 기회를 창출할 수 있다.

기술 부채라는 용어를 사용하여 소프트웨어 개발 결정에 있어 속도와 품질 사이의 균형을 잡는 방법에 대해 조언을 제공하고 있다. 그러나 이 기사는 기술 부채의 복잡성과 심각성을 충분히 인식하지 못하고 있다. 기술 부채는 단순히 빠른 해결책을 선택하는 것과 관련된 것이 아니라, 외부 변화와 시장 요구에 따라 발생하고 증가하는 것이다. 기술 부채를 해결하기 위한 세 가지를 제시하지만, 이들은 모두 현실적이지 않거나 비현실적인 가정에 기반하고 있다.   다음은 이 기사의 주장을 반박하는 몇 가지 포인트다.   첫 번째는 기술 부채를 물이 새는 파이프에 비유했다. 이 비유는 기술 부채의 원인과 위치를 정확히 파악하고 수리할 수 있다는 가정이다. 그러나 실제로는 기술 부채는 복잡하고 상호 연관된 시스템에서 발생하므로, 단순히 구멍을 막는 것으로 해결할 수 있는 것이 아니다. 기술 부채는 시스템의 구조와 설계에 근본적인 문제가 있음을 반영하므로, 새로운 파이프를 설치하는 것이 아니라, 새로운 방식으로 물을 공급하는 것을 고려해야 한다.   두 번째는 기술 부채를 정원에 비유했다. 이 비유는 기술 부채가 불필요하고 제거해야 하는 것이라고 간주한다. 그러나 실제로는 기술 부채가 가치를 생성하는 데 필요한 것일 수도 있다. 예를 들어, 새로운 기능을 빠르게 출시하여 고객의 만족도와 수익을 높이는 것은 기술 부채를 감수할 만한 가치가 있을 수 있다. 기술 부채는 잡가 아니라, 투자의 결과물이라고 볼 수 있다. 따라서 기술 부채를 제거하는 것이 아니라, 관리하고 감독하는 것이 중요하다.   세 번째는 기술 부채를 클래식 자동차에 비유했다. 이 비유는 기술 부채가 불가피하고 예측할 수 없는 것이라고 가정한다. 그러나 실제로는 기술 부채는 조직의 문화와 프로세스에 의해 영향을 받는다. 예를 들어, 팀이 명확하고 일관된 목표와 우선 순위를 가지고, 품질과 테스트에 충분한 시간과 자원을 투자하고, 지속적인 피드백과 학습을 수행한다면, 기술 부채의 발생과 증가를 줄일 수 있다. 기술 부채는 클래식 자동차가 아니라, 조직의 선택에 따라 제어할 수 있는 것이다.   이 기사는 기술 부채에 대한 단순화된 시각을 제시하고 있다. 기술 부채는 소프트웨어 개발의 필연적이고 복잡한 측면이므로, 단순한 비유나 해결책으로는 충분하지 않다. 기술 부채를 이해하고 관리하기 위해서는, 다양한 요인과 영향을 고려하고, 적절한 도구와 방법론을 적용하고, 지속적인 개선과 혁신을 추구해야 한다.

 [본문]

디지털 혁신은 종종 혁신을 지원하고 고객 만족을 유지하는 확장 가능하고 유연하며 탄력적인 엔터프라이즈 IT 시스템을 고안하기 위한 치열한 경쟁처럼 느껴진다. 그러나 소프트웨어 개발 결정을 내릴 때 순간적으로 반응하고 응답해야 하는 끊임없는 요구는 단기적인 사고로 이어질 수 있다. 우리가 보는 가장 일반적인 함정은 조직이 "기술적 부채"로 어려움을 겪고 있다는 것이다.

 

수십 년 동안 사용되어 온 기술 부채는 소프트웨어를 충분히 높은 품질과 비용 효율성으로 유지하는 데 필요한 지속적인 노력과 관련이 있다. 이는 일반적으로 나중에 수정할 수 있다는 의도로 더 긴 전략적 시간 프레임에 부합하는 것보다 더 빠르고 전술적인 솔루션을 선택하는 것과 관련된 절충안이다.

 

소액이더라도 기술 부채에는 이자가 발생한다. 부채가 처리되지 않은 상태로 놔두면 거의 모든 자원을 부채 상환에 전념하게 되며 부채를 빨리 갚을 수 있다는 희망은 거의 없다. 하지만 다른 형태의 신용과 마찬가지로 기술 부채는 때때로 팀을 위한 유일한 접근 방식인 경우도 있다. 새로운 기능을 시장에 출시하는 것은 고객에게 유익하고 생산성과 수익을 높일 수 있으며, 때로는 기다림의 결과가 빚을 지는 것보다 더 나쁠 수도 있다.

 

“기술 부채는 금융 부채와 많은 유사점을 가지고 있지만, 모든 것을 말하는 것은 아니다.”

 

아무리 잘 관리된 시스템이라도 외부의 변화와 시장의 요구에 따라 기술 부채가 나타나고 누적될 가능성은 여전히 ​​있다. 이는 우리가 내린 의식적인 결정이나 절충안과 항상 쉽게 연결되는 것은 아니며 때로는 정확히 파악하기 어려운 팀의 기생적 소진처럼 느껴질 수도 있다.

 

고객과의 대화를 바탕으로 기술 부채의 현실과 이를 억제할 수 있는 몇 가지 아이디어를 종합적으로 표현할 수 있는 세 가지 이미지를 만들었다.

 

1. 취약점(균열)이 어디에 있는지 파악

 

오늘날 대부분의 플랫폼과 시스템은 규모가 큰 모든 것이 그렇듯이 작은 부분으로 구성된 복잡한 오케스트레이션으로 이루어져 있다. 이러한 이유로 기술 부채는 팀의 생산량이 매우 느리게 감소하는 것으로 나타나기 시작할 수 있다. 자세히 살펴보면 문제를 정확히 파악하기는 어렵지만 전반적인 영향을 살펴보면 무언가 정상적이지 않다는 것을 알 수 있다. 기술 부채는 '쌓이고' 기하급수적으로 증가한다. 세부적인 지표와 변동에 대한 대응은 문제가 어디에 있는지 정확히 파악하고 해결 방법의 우선순위를 정하는 데 핵심적인 역할을 한다.

 

이를 설명하기 위해 기술 부채를 수도관이 새는 수도 시설에 비유할 수 있다. 자원(이 경우 물)은 복잡한 지하 네트워크로 펌핑된다. 다른 쪽 끝의 수도꼭지를 통해 물이 흐르지만, 얼마나 많은 균열이 있는지, 구멍이 어디에 있는지, 얼마나 많은 양이 낭비되고 있는지 알 수 없다. 문제를 조기에 해결하지 않으면 파이프를 뜯어내고 다시 시작해야 할 수도 있다. 더 많은 물을 부어 넣는 것이 정답은 아니다. 마찬가지로 기업 세계에서도 혁신에 투자할 수 있는 자금을 문제 해결에 점점 더 많은 리소스를 투입하는 것은 바람직하지 않다. 대신, 시급한 단기 비효율 문제를 해결한 다음 시스템의 장기적인 건강 상태를 관리하기 위한 계획을 수립해야 한다.

 

 

2. 소프트웨어를 가꾸고 키우기

 

소프트웨어 엔지니어링을 설명하는 데 사용되는 건축학적 용어는 많지만, 이를 정원 관리와 같은 보다 유기적인 비유로 보면 프로젝트의 봄철에는 정원을 가꾸기 위해 많은 돈을 들여 정원 센터에 가서 토양을 경작한다. 그러나 정기적으로 관리하지 않으면 식물이 죽고 풀과 가시가 무성한 숲이 생기고 정원 센터를 방문하는 데 더 많은 비용이 들게 된다. 반대로 부지런한 이웃은 정기적으로 도시 정원을 가꾸고 돌보며 잡초를 뽑아내고 궁극적으로 훨씬 더 즐거운 여름을 보낼 수 있다.

 

소프트웨어 비용이 너무 비싸거나 유지 관리에 많은 시간과 노력이 필요하다는 말을 자주 듣는다. 이러한 생각은 닷컴 시대에 소프트웨어가 저렴하고 구축하기 쉽다는 평판을 얻었던 것에서 비롯된 것이지만, 사실 당시의 소프트웨어는 품질이 좋지 않은 경향이 있었다.

 

“정원을 가꾸는 것과 마찬가지로 소프트웨어도 지속 가능한 상태를 유지하고 장기적인 비용을 피하려면 시간과 리소스가 필요하다.”

 

따라서 기업은 개발자가 요청하는 유지 관리 및 개선에 소요되는 시간을 일정 비율로 고려해야 한다. 어떤 경우에는 특정 시간 예산이 될 수도 있고, 어떤 경우에는 개발자가 진행하면서 '잡초'를 제거해야 한다는 것을 이해해야 할 수도 있다.

 

 

 

3. 장기적인 재무적 감각 평가

 

소프트웨어는 다른 기술과 마찬가지로 빠르게 구식이 되고 쓸모 없어질 수 있으므로 레거시 기술을 보유하는 것은 성공적인 비즈니스 운영의 당연한 부분이다. 문제는 소프트웨어를 변경하지 않고 방치하여 더 이상 적합하지 않고 작동을 멈추는 경향이 있을 때 발생한다. 이는 작은 결함 하나가 아키텍처의 다른 많은 영역에 영향을 미칠 수 있는 오늘날의 복잡한 소프트웨어 생태계에 심각한 영향을 미칠 수 있다.

 

소프트웨어 유지보수는 지속적인 투자이며 클래식 자동차를 소유하는 것에 비유할 수 있다. 볼트를 조이거나 오일을 정기적으로 교체하는 것부터 정기적인 사전 예방적 유지 관리가 필요하다. 한 가지 일반적인 문제는 부품이 더 이상 구할 수 없거나 전문 공급업체를 통해서만 비싼 가격으로 조달할 수 있다는 것이다. 부품과 패치를 직접 제작할 수도 있지만, 어느 시점에서는 장기적인 경제성을 따져봐야 한다. 다행히도 소프트웨어 아키텍처 교체는 클래식 자동차를 폐기하는 것과 같은 향수를 불러일으키는 고통은 없다. 그러나 일단 재정적으로 더 나은 선택이라고 결정한 후에는 직원에 대한 고려를 통해 프로세스를 시작해야 하는 등 다른 많은 요소가 작용한다.

 

 

최종 생각

 

실제 부채와 마찬가지로 유지 관리와 계획을 통해 초기에 기술 부채를 갚으면 문제가 커지는 것을 방지할 수 있다. 다행히 최신 소프트웨어 개발 프로세스는 기술 부채가 얼마나 발생하고 있는지, 상황을 되돌리기 위해 어떻게 투자해야 하는지 파악할 수 있는 충분한 정보를 수집하므로 관리 가능한 리스크를 유지하면서 효율적이고 안전하게 변경을 계속할 수 있다. 이제 소프트웨어의 일부가 누출되기 시작하거나 잡초가 자라기 시작하거나 볼트를 조여야 하는 시기를 확인할 수 있다.

 

가장 중요한 것은 기술 부채라는 개념을 통해 기업이 얼마나 빠르게 변화할 수 있는지 측정할 수 있지만, 성장 속도가 예상치 못한 비용을 초래하지 않는다는 점이다. 또한 어떤 시스템과 애플리케이션이 조직에 가장 큰 가치를 가져다 주는지 어떤 시스템과 애플리케이션이 가장 많은 시간과 리소스를 투입하고 혁신을 지원할 수 있는지 지속적으로 평가하도록 상기시켜주는 역할을 할 수 있다.