Yesica Danderfer가 번역한 이 기사의 버전 빚이 얼마나 되는지 모른다면? 비용이 얼마나 들거나 회사가 운영 개선, 시장 변화에 대응, 비즈니스를 완전히 변화시키는 데 방해가 되는 정도를 알지 못하는 것은 불편한 입장이 될 것입니다.
게다가 조직의 누군가가 허락 없이 부채를 지게 된다면 어떻게 될까요? 예를 들어, 부동산 책임자는 1년 차 임대료가 저렴하지만 이후 몇 년 동안 임대료가 크게 상승하는 다년 임대 계약을 신속하게 체결할 수 있습니다.
이 모든 것이 경솔한 거버넌스처럼 들리지만 실제로는 비즈니스에서 매우 일반적입니다. 문제는 이러한 종류의 "부채"가 우리 모두가 잘 알고 있는 전통적인 금융 상품의 형태로 나오지 않는다는 것입니다.
기술 부채에는 이러한 모든 특성이 있습니다.
가장 단순한 형태의 부채는 미래에 상환하겠다는 의도와 약속을 가지고 오늘 빌리는 것입니다. 부채는 오늘의 대출이 더 나은 내일로 이어질 때 의미가 있습니다. 예를 들어 값비싼 저녁 식사를 하러 나가 즉시 갚지 못할 신용 카드에 넣어두는 것과 같이 오늘 빌리면 내일 더 나빠질 때 부채는 일반적으로 좋지 않습니다.
기업의 관점에서 부채는 부채 비용보다 더 큰 수익을 제공할 투자 자금을 조달하기 위해 발생하면 좋을 수 있습니다. 부채가 만기되기 훨씬 전에 사업체를 매각할 계획이라면 의미가 있을 수도 있습니다. 부채의 단점은 현금과 이익을 끌어들이고 유연성을 제한하며 궁극적으로 파산으로 이어질 수 있는 부담이 될 수 있는 매우 실질적인 비용이 있다는 것입니다.
지금까지 우리가 암시하는 은유는 금융 부채에 관한 것이지만 또 다른 형태의 부채인 기술 부채(또는 "기술 부채")에는 유사한 특성이 많이 있으며 신중한 방식으로 측정, 관리 및 입력해야 합니다. . 회사가 경쟁보다 앞서 시장에 진출할 수 있다면 그만한 가치가 있습니다. 마찬가지로, 잠재적으로 심각한 보안 취약성을 완화하기 위해 기술 부채를 떠맡는 것도 가치가 있을 것입니다.
그러나 기술 부채에는 단점이 있어 한 부서에서 다른 부서의 소프트웨어를 사용하고 싶지 않거나 단기 재무 목표를 달성하기 위해 업그레이드를 여러 번 지연하는 경우와 같이 비효율성과 관성을 유발합니다.
기술 부채는 컴퓨터 프로그래머인 Ward Cunningham이 1992년에 이 용어를 만든 이후로 기술 커뮤니티에서 주로 사용된 용어입니다. 이 용어는 최근에 사용되기 시작했으며 애자일 프로그래밍의 확산으로 중심이 되었습니다. 이 기사에서 논의된 기술적 부채는 프로그래밍 방법론에 관한 것이 아니라 그 존재의 전략적 의미에 관한 것입니다.
간단히 말해서 기술 부채는 새로운 시스템을 구현하거나 기존 시스템을 유지 관리할 때 시간이나 비용을 절약하기 위해 내린 사전 결정의 결과로 발생하는 비용 증가와 회사의 민첩성 상실입니다. 시스템이 올바르게 통합되지 않았거나 코드가 지나치게 복잡할 때 발생합니다. 이는 무엇보다도 비효율성, 출시 시간 고려 사항 또는 오래된 버전의 소프트웨어 실행과 같은 다양한 이유 때문입니다.
몇 가지 명확한 예는 다음과 같습니다.
아래 다이어그램은 기술 부채가 회사의 기술 스택 내에서 수행할 수 있는 다른 기술 구현과 어떻게 다른지 설명하는 데 유용한 그래픽입니다. 종종 버그로 오인되는 기술 부채는 그 존재가 노골적으로 분명하지 않을 수 있다는 점에서 크게 다릅니다. 거기에 위험이 도사리고 있습니다. 손대지 않은 상태로 오래 둘수록 미래에 그 효과의 크기가 더 커질 것입니다.
IT 부서에서 일하면서 IT 부서에서 레버리지가 높은 기업에서 저에게 보고한 CFO로서 기술적 부채가 전통적인 부채와 얼마나 유사한지 저는 충격을 받았습니다. 그것은 또한 그것이 얼마나 불투명하고 위험한지 저에게 충격을 주었습니다. 재정적 배경을 가진 사람들은 재정적 부채의 메커니즘에 정통합니다. 유형적이고 계산하기 쉽습니다. 그러나 종종 잘못 이해되거나 다른 사람의 문제로 잘못 간주되는 기술 부채는 그렇지 않습니다.
짧은 대답은 현금 비용이 매우 현실적이라는 것입니다. 또한 식별하고 별도로 측정 및 관리해야 하는 몇 가지 중요한 소프트 비용이 있습니다. 이러한 비용의 몇 가지 예에 대해 아래에서 자세히 설명하겠습니다.
기술 부채는 이자 지급만큼 현실적입니다. 그러나 일반적으로 다음과 같은 단순한 "이자" 라인 비용보다 간접적인 방식으로 손익에 나타납니다.
인원 수
오버헤드
판매
운전 자본
하드 비용에는 실제 달러 금액이 관련되어 있지만, 비용 절감을 수량화하고 실현하기는 더 어렵지만 비즈니스 결과에 절대적인 영향을 미치는 소프트 비용도 있습니다. 여기에는 다음이 포함됩니다.
시장 정보
생산성
기술적 부채와 재정적 부채를 비교하면 주요 차이점 중 하나는 전자가 공식적인 통제권이 없다는 것입니다. 금융 부채에는 일반적으로 신용 위원회, 자산 및 부채 관리 팀, 매파처럼 수준을 모니터링하는 재무 직원이 있습니다. 그러나 기술 부채의 경우 이러한 통제가 기존 비즈니스에 거의 존재하지 않습니다.
전통적인 부채의 경우 이사회는 CEO 및 CFO와 함께 일반적으로 자본 구조, 즉 자기 자본, 부채 및 부채 유형(리볼버, 자산 기반 또는 기본 무담보)을 설정합니다. 한도 표는 심지어 어떤 부채가 언제 상환되는지에 대해서도 명시되어 있습니다. 이 모든 것이 공식적으로 결정되면 부채를 늘리기 위한 구조화된 프로세스가 시작됩니다.
대출 기관은 부채 상환 이력, 신용 등급 및 이를 뒷받침하는 담보물의 품질 평가를 통해 기업의 부채 상환 능력을 살펴봅니다. 그러나 이러한 공식적인 프로세스, 수량화 및 승인 중 어느 것도 기술 부채가 발생할 때 발생하지 않습니다. 기술 부채가 발생하는 과정과 이유를 살펴보겠습니다.
시장 출시 시간은 비즈니스의 모든 것입니다. 새로운 기술을 구현하는 것은 독립 실행형 기반으로 수행할 수 있을 때 훨씬 더 빠릅니다. 불행히도 이것의 의미는 다른 시스템이 구현과 동기화되지 않는다는 것입니다. 단순한 기술 스택이 있는 린 조직의 경우 나쁘지 않은 것처럼 보일 수 있습니다.
그러나 시스템 구성이 복잡해지면 문제가 됩니다. 결국 기술은 프로세스를 자동화하고 정보로 변환되는 데이터를 캡처합니다. 통합되지 않은 기술은 함께 작동하지 않는 비즈니스 프로세스와 여러 버전의 진실을 초래합니다.
속도를 위해 시간이 희생되면 확립된 테스트 프로토콜을 무시하거나 포기할 수 있습니다. 이로 인해 일반적으로 어떤 형태의 시스템 성능 저하와 개발자 시간이 문제를 수정하는 데 방해가 되는 "버그"가 발생합니다.
시간이 지남에 따라 기술 부채의 영향을 살펴보면 문제가 해결되지 않은 상태로 남아 있는 시간이 길수록 영향의 크기가 커집니다. 작은 코드 리팩토링 연습으로 시작하는 것이 전체 현대화 및 교체 노력으로 눈덩이처럼 불어날 수 있습니다.
현실을 직시하세요. 경영진은 수치를 달성해야 한다는 지속적인 압박을 받고 있습니다. 오늘 지출을 미루면 분기를 만드는 데 도움이 될 수 있지만 차입과 마찬가지로 언젠가는 갚아야 합니다. 다음은 기업이 단기적으로 비용을 절감하지만 결국 기술 부채를 초래하는 몇 가지 방법입니다.
때때로 정기적인 소프트웨어 업데이트를 구현하는 데 드는 비용과 문제로 인해 지연될 수 있습니다. 때때로 이것은 몇 년 동안 계속됩니다. 불편한 시간에 Microsoft AutoUpdate가 나타나면 강제 종료하는 것은 우리 모두의 책임입니다.
시스템이 현재 버전보다 훨씬 뒤쳐지면 시스템과 통합해야 하는 최신 소프트웨어는 그렇게 할 수 없습니다. 게다가 한 번에 여러 버전을 업그레이드하는 것은 일반적으로 유지하는 것보다 비용이 많이 들고 거의 항상 시간이 많이 걸립니다.
조직이 복잡해짐에 따라 하드웨어 업데이트 주기를 동기화하는 노력이 너무 많아지고 비용이 많이 들 수 있습니다. 이로 인해 현재 하드웨어가 팀 간의 하드웨어 품질 사이에 존재하는 극단적이고 큰 격차로 확장될 수 있습니다. 일부 팀은 불만을 품고 새 하드웨어를 구입하고 IT 부서에서 업그레이드를 시작하기를 기다리지 않고 책상 예산으로 지출합니다.
이러한 격차는 협업 연습을 위한 생산성 및 하드웨어/파일 호환성에 영향을 미칩니다.
문제에 대해서만 이야기하는 것이 아니라, 기술 부채를 해결하기 위한 몇 가지 선제적 조치를 적용하고 몇 가지 솔루션을 처방해 보겠습니다.
이를 위해 금융 부채를 관리하는 데 사용되는 기술을 요청할 수 있습니다. 부채를 관리하려면 먼저 부채가 무엇인지, 얼마인지, 지불 조건을 알아야 합니다. 이제 기술 부채에 대해 이 문제를 해결해 보겠습니다.
금융 부채는 각 부품(예:시니어, 메자닌 또는 리볼버)의 연공서열로 정의되는 트랜치로 제공되며, 이는 먼저 상환되는 항목을 보여줍니다. 기술 부채는 비슷한 패턴의 연공서열을 가지고 있습니다. 우선 미션 크리티컬 시스템부터 시작해야 합니다. 어떤 기술적 부채가 있습니까? 그런 다음 더 넓은 의미의 생태계를 살펴보십시오. 귀하의 시스템이 비용을 초래하고 있습니까?
이 프로세스를 지나치게 복잡하게 만들지 마십시오. 어느 시점에서 당신은 위에서 아래로 평가를 받고 싶지만 거기에서 시작할 필요는 없습니다. IT 책임자에게 다음 과제와 함께 관리 팀을 구성하도록 하십시오.
<블록 인용>1년 전에 기술 부채를 모두 청산했다면 올해(또는 내년)에 어떻게 더 나은 성과를 거둘 수 있었을까요?
상위 10개 아이디어를 가져와 2x2 매트릭스에 넣습니다. 한 축에서는 지불하기 쉽고 다른 축에서는 혜택 정도를 지불합니다. 비주얼이 어디서부터 시작해야 할지 파악하는 데 도움이 되기를 바랍니다.
기술 부채 해결 브레인스토밍 매트릭스| 해결의 이점 ► | 강함 | ||
|---|---|---|---|
| 약함 | |||
| 하드 | 쉬움 | ||
| ▲ 갚기 위한 노력 | |||
거기에서 드릴인하여 상금 규모와 노력에 대한 가정을 검증하십시오. 여기에서는 중립이 핵심이므로 "무료 평가"를 제공하는 소프트웨어 공급업체를 조심하십시오.
기술 부채가 무엇인지 알고 나면 이제 이를 처리하는 방법을 결정해야 합니다. 선택할 수 있는 옵션이 많이 있습니다.
결국 아무것도 하지 않는 것이 최선일 수 있습니다. "작은" 부채 또는 "저금리"로 평가되는 부채의 경우 조기 상환에 따른 상당한 "선불 벌금"이 있는 경우와 마찬가지로 그냥 두는 것이 가장 좋습니다. 전략적 이점도 있을 수 있습니다. 한 버전 뒤에 있고 거기에 머무르는 것은 일반적으로 괜찮으며 때로는 다른 사람의 돈으로 꼬임을 해결할 수 있다는 이점이 있습니다.
기술 부채를 상환하거나 줄이려면 시스템을 교체하고 비용을 감수해야 합니다. 이는 즉시 수행되거나 점진적인 개선 프로세스를 통해 시간이 지남에 따라 수행될 수 있습니다. 재정 부채와 마찬가지로 기술 부채를 "재융자"할 수 있는 창의적인 방법이 있으며 유지 관리를 아웃소싱하는 것도 그러한 방법 중 하나입니다. 이것은 궁극적으로 해결하는 데 더 많은 비용이 들 수 있지만 즉각적인 비용 타격을 줄이기 위해 분산될 수 있으며 분업 원칙을 통해 작업을 보다 전문화된 단체에 위임할 수 있습니다.
클라우드 기반 소프트웨어 및 하드웨어 서비스의 출현은 또한 임대 기반 금융의 인기를 비교합니다. 클라우드 서비스를 사용하는 것은 CAPEX 요구 사항을 제거하고 개발 초점을 클라우드 제공업체로 전환하는 데 있어 기술 부채를 줄이는 효과적인 도구이기도 합니다.
기술 부채를 줄이는 데 드는 비용에 압도되지 말고 한 번에 갚으려 하지 마십시오. 이것은 규모나 대차 대조표에 관계없이 조직을 압도할 수 있는 야심찬 운동이 될 것입니다.
다시 재정 비교로 돌아가서 가장 높은 이자율을 가진 신용 카드를 먼저 갚는 정신을 가지십시오. 이것은 단순히 높은 가치/낮은 노력 활동을 먼저 공격한다는 것을 의미합니다.
이전 섹션에서 기술 부채를 해결하는 다양한 방법에 대해 논의했습니다. 각각의 비용을 평가할 때 비교 연습을 수행하는 것이 가장 좋습니다. 각 잠재적 결과에 대한 현금 흐름 비용의 순위를 지정하면 이해 관계자가 각 경로의 장단점을 명확하게 파악할 수 있습니다. 이러한 시각적 개체의 예가 아래에 포함되어 있습니다.
이 비교는 이론적 해결과 문제를 해결하는 것과 아무것도 하지 않는 것("기존 기준선") 사이의 극명한 대조 사이에 존재하는 절충안을 보여줍니다. 이 예에서 클라우드로 이동하는 경우 SaaS 기반 솔루션은 기업이 취할 수 있는 가장 경제적인 옵션이 될 것입니다.
공격의 기준선과 계획을 수립하고 나면 해당 가시성을 유지하고 새로운 부채가 유입되는 것을 방지해야 합니다. 이 연습을 새로운 시작이자 문제를 방지하기 위한 모범 사례를 구현할 기회로 생각하십시오. 앞으로 다시 확대될 것입니다.
대부분의 기술 프로젝트에는 임원 후원자, 높은 수준의 목표, 예상 혜택, 일정 및 비용이 포함된 공식 승인 프로세스가 있습니다. 이것은 발생하게 될 새로운 기술 부채와 이에 대한 정당성을 제거하기에 좋은 장소입니다.
새로운 표준을 설정하는 데 너무 열성적이지 마십시오. 한도가 미리 설정된 기업 신용 카드를 발행하는 것처럼 기술 부채를 과도하게 관리하고 싶지 않습니다. 많은 기술 부채는 작으며 빨리 갚을 코드 작성과 관련이 있습니다. 애자일 개발에서는 특히 그렇습니다. 이 임계값을 설정하고 모니터링하는 IT 책임자를 신뢰하십시오.
대기업의 IT에는 "변경 관리"라는 프로세스가 있습니다. 새 소프트웨어가 출시되기 전에 일반적으로 변경 관리를 거칩니다. 간단히 말해서 변경 관리의 임무는 회사의 기술 시스템에 대한 새로운 변경 사항이 다른 시스템에 영향을 미치지 않도록 하는 것입니다. 그들은 새로운 시스템이 표준화된 방법과 절차를 준수하는지 확인함으로써 이를 수행합니다. 이 프로세스를 사용하여 새로운 부채가 유입되는 것을 방지하거나 최소한 식별할 수 있습니다.
기술 부채는 비즈니스 수행의 실제 비용이자 시스템 중단의 실제 원인이며 전반적인 회사 민첩성을 저해합니다. 하지만 지속적인 부담이 될 필요는 없으며 똑똑한 CFO는 조직에 얼마나 많은 기술 부채가 있으며 이를 최적화하는 데 필요한 비용을 알 수 있습니다.