Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

기술부채

우리가 알던 '기술 부채' 통념은 모두 틀렸다

“빚은 여느 덫과 다르지 않다. 들어가기는 쉽고, 빠져나오기는 어렵다.” (조시 빌링스, 미국의 유머 작가) IT 분야에서도 마찬가지다. 삶에서와 똑같이 말 자체만으로도 스트레스를 받고 짐스러운 느낌이 든다. 소프트웨어 엔지니어링에서 '기술 부채(Technical Debt)'는 일반적으로 노화하면서 엔지니어의 귀중한 시간을 잡아먹는 시스템을 가리킨다. 기술 부채는 관리되고 바람직하게 유지되고 최소화돼야 한다. 이것은 남은 업무의 가장 아래에 위치하며, 궁극적으로 시스템을 실패로 이끌기도 한다.   그러나 꼭 이런 식일 필요가 있을까? 진보적인 엔지니어링 기업은 오히려 기술 부채가 모든 소프트웨어 개발자의 핵심 업무여야 하고 기술 부채를 선제적으로 관리해 실패를 피할 수 있을 뿐 아니라,실제로 경쟁에서 우위를 점할 수 있다고 말한다. 어떻게 해서 가능한 것일까? 지금부터 차근차근 살펴보자.   기술 부채의 정의 '기술 부채'라는 용어는 1992년 컴퓨터 과학자 와드 커닝험이 처음 만들었다. 단기적 솔루션을 기술 시스템에 구축하는 업무에는 일련의 취사선택이 필요한데 선택받지 못한 업무가 결국 미래 엔지니어링 작업 형태로 남아 마치 갚아야 할 부채처럼 된다는 생각이다. 2003년 소프트웨어 개발자인 마틴 파울러는 기술 부채를 다음과 같이 설명했다.   "일을 성급하고 지저분하게 처리하면 기술 부채가 쌓이는데, 이는 금융 부채와 비슷하다. 금융 부채처럼 이자를 지불해야 하고, 결국은 나중에 개발해야만 하는 추가적인 업무의 형태로 남는다. 2018년 스트라이프(Stripe)의 개발자 계수(Developer Coefficient) 보고서에 따르면, 평균적인 소프트웨어 개발자는 기술 부채를 처리하는 데 일주일에 13시간 이상을 쓴다. 애플리케이션이 갈수록 복잡해지면서 부채를 관리하는 일이 매우 중요해졌다. 스텝사이즈(Stepsize)의 CEO인 알렉산더 오메여는 “개발자가 처리하리라 결정한 코드는 무엇이든 기술 부채다”라고 말했다...

기술부채 TechnicalDebt 2022.06.03

글로벌 칼럼 | 코드 개선과 적절한 계획 및 측정이 기술 부채를 줄이는 지름길

기술 부채는 성능 및 코드 가독성, 기타 지원 요소 개선에 드는 비용처럼 규모가 작을 수도 있지만, 곧 사용이 중단될 API나 CI/CD가 부족한 애플리케이션, 자동화된 테스트가 거의 없는 서비스, 혹은 운영에 영향을 주는 구형 시스템은 대규모 기술 부채를 낳을 수 있다.   소스와 크기, 영향에 관계없이 IT팀은 기술 부채를 측정하고 관리하며, 줄여야 한다. 또한, 추가 기술 부채 방지 및 제한 조치를 취하며 베스트 프랙티스를 시행하는 것도 중요하다. 액스웨이(Axway)의 부사장 루비 레일리는 오늘날 기술 부족과 심각한 재정 상태 때문에 무엇보다도 기술 부채를 줄이고 해결하는 것이 더 중요하다고 강조했다. 레일리는 “기술 부채를 줄이는 것이 CIO에게 가장 우선시될 것이다. 현재 인플레이션과 대퇴직, 직원 퇴사에 따른 인력난에 직면한 CIO는 새로운 프로젝트에 자금을 댈 운영 효율성을 찾아야 한다. 유지보수에 드는 지출을 줄이기 위한 기술 통합이 한 가지 방법이 될 수 있다”라고 말했다. 필자는 레일리에 동의한다. 항상 어려운 작업이지만, 개발팀은 기술 부채를 줄이기 위해 충분한 시간을 할애하고 새로운 소스 도입을 최소화하는 조치를 취해야 한다. 민첩한 개발팀 및 데브옵스(DevOps)를 따르는 기업은 이런 관행을 검토하고 고려해야 한다.   개발팀의 기술 부채 예방 관행 런치다클리(LaunchDarkly)의 CTO인 존 코두멀은 “소프트웨어 개발에서는 어쩔 수 없이 기술 부채가 발생하지만, 시간이 지나면서 기술 부채 감소 비용을 상환하는 정책과 관행, 프로세스를 수립함으로써 기술 부채를 방지할 수 있다. 다른 작업을 멈추고 산더미처럼 쌓인 빚에서 벗어나려고 애쓰는 것보다 훨씬 더 나은 방법이다”라고 말했다. 코두멀은 타사 종속성에 대한 업데이트 정책 및 주기 수립, 워크플로우 및 자동화를 사용해 기능 플래그의 라이프사이클 관리, 서비스 수준 목표 설정과 같은 몇 가지 관행을 추천했다. 새로운 기술 부채의 발생 가능성을 줄이려면...

기술부채 CICD 로우코드 2022.04.20

글로벌 칼럼 | 제로 트러스트로 네트워크 기술 부채에 맞서는 방법

제로 트러스트(Zero Trust)는 기술이 아닌 사고방식이자 방법의 일종이다. 오늘날 제로 트러스트 채택이 추진력을 얻는 이유는 기업 네트워크에서 위험 관리 및 공격 방어 개선의 필요성이 빠르게 증가했기 때문이다. 지속적인 랜섬웨어 공격으로 인한 변화다. IT팀은 제로 트러스트 채택의 시급성을 활용해 기업의 기술 부채를 일부 찾아낼 수 있다. 특히 네트워크 및 네트워크 보안 표준에서 제외된 영역을 찾아 제로 트러스트라는 새로운 패러다임을 촉진할 수 있다.   제어 대상에서 제외되지 않는 네트워크 컴포넌트 제로 트러스트 환경에서 네트워크는 새로운 노드를 신뢰하지 않을 뿐 아니라 네트워크를 통해 이미 통신하는 노드도 신뢰하지 않는다. 제로 트러스트 네트워크는 처음 발견한 노드에 인증 및 인가 확인 절차를 거칠 것을 요구한다. 신원을 증명하는 유효 인증서가 있는지, 해당 ID를 사용한 연결이 허용되는지, 유효한 소프트웨어 버전과 방어 도구를 실행하고 있는지 등을 확인한다. 통신이 허용되기 전에 노드는 이런 장애물을 제거해야 한다. 또한 제로 트러스트 네트워크는 신뢰 관계가 영구적이거나 맥락에서 자유롭다고 가정하지 않는다. 즉, 네트워크상의 노드는 모든 네트워크 작업을 시도할 때마다 인증 및 권한 부여 절차를 거쳐야 한다. 한 작업과 다음 작업 사이에 신뢰 관계가 손상되었을 수도 있고 노드가 비정상적으로 행동해 권한이 박탈됐거나, 혹은 해당 시스템의 사용자가 해고되었을 수 있기 때문이다. 제로 트러스트를 도입하기 위해서 네트워크 전문가는 그동안 생각하던 네트워크 서비스 방식을 근본적으로 바꾸어야 한다. 실제로 802.1x 기반의 기본적인 승인 제어에 익숙해진 네트워크팀이 많아지기 시작한 것도 최근부터였으며, 여전히 네트워크에는 기본 수준의 승인 제어를 적용하지 않는 포트, 스위치, 세그먼트 및 서브넷이 만연하다. 대부분의 경우 포트/세그먼트/서브넷 등은 제어 대상이 되지 않는다. 이를 통해 연결된 시스템이 (심지어 밑단의 하드웨어 자체도) 보안 프...

제로트러스트 네트워크 기술부채 2022.03.31

“100% 해결책은 없다” 기술 부채의 과제와 해법

기술 부채는 소프트웨어가 제대로 완성되지 않았거나 기술적으로 부실하게 구현된 경우, 기업이 금전 또는 노동으로 지불해야 하는 비용이다. 이상적인 경우 기술 부채는 간단한 계산과 가능한 장단점 평가 이후 우선순위화의 형태로 수락된다. 그러나 부정적인 변형도 있는데, 이른바 ‘안티 패턴’이다. 이 경우 기술 부채는 개발 프로세스에서 전문성의 부재로 인한 결과이며, 따라서 확실하게 부정적이다.    소프트웨어 AG(Software AG)는 이 주제를 좀 더 집중적으로 파고들었다. 소프트웨어 AG는 기술 부채를 소프트웨어가 이미 운영에 돌입한 이후 소프트웨어팀이 디지털 시스템에서 시급하게 수행해야 하는 부가적인 작업으로 정의한다. 이는 기술 부채가 긍정적이거나 부정적인 것이 아니라 단순히 민첩한 작업을 위한 조건임을 의미한다. 기술 부채가 발생하는 경로는 그 부채가 좋은 부채인지 나쁜 부채인지 여부에 큰 영향을 미친다.    긍정적 기술 부채, 부정적 기술 부채 예를 들어, 80%만 완성된 최소 기능 제품(Minimum Viable Product, MVP)에서 비롯되는 기술 부채는 긍정적일 수 있다. 다만 기업은 누락된 20%를 의식하고 이를 어떻게 처리할지를 결정해야 한다. 반면 예를 들어 개발 과정의 실패로 인해 발생하는 의도하지 않은 기술 부채는 대체로 부정적이다. 따라서 지나치게 자주 발생해서는 안 된다.  변화하는 환경 또는 주변 조건의 결과로 장기간에 걸쳐 축적되는 기술 부채도 있다. 예를 들어, 바뀐 규정 조항이나 기술 표준을 충족해야 하는 경우 또는 기업이 인수합병, 새로운 기업 형식 등으로 인해 구조를 바꿔야 하는 경우가 여기에 해당된다. 비즈니스의 변화 속도가 빠를수록 이 부채 문제도 커져서 IT 운영에 지장을 초래할 수 있다.  좋은 부채와 나쁜 부채는 디지털 우선 기업에서 일반적인 현상이다. 소프트웨어 AG의 조사에 따르면, 기업 4곳 중 3곳에서 작년 한 해 동안 누적된 기술 부채가...

기술부채 데이터마이닝 디지털트랜스포메이션 2022.02.09

이점이 훨씬 많은 마이크로서비스 아키텍처 "관건은 복잡성 관리"

개발자 생산성과 삶의 질을 떨어뜨리는 요인으로 애플리케이션 복잡성을 꼽은 주장이 최근 눈에 띈다. Infoworld 기사에서도 표준화된 서드파티 서비스와 기타 방법을 사용해 복잡성을 억제하는 여러 좋은 아이디어를 제안했다. 필자는 이 전략이 많은 조직에 가치를 제공한다는 데 동의한다. 그런데 이 기사는 동일한 애플리케이션을 상정할 때 마이크로서비스 아키텍처가 모놀리식 아키텍처로 된 함수형 애플리케이션보다 복잡하다고 언급하면서“죽음에 비할 만한 복잡성”의 이유로 들었다. 필자는 그 주장에 동의하지 않는다.   필자가 생각하기에 이 시각에 내포된 메시지는 마이크로서비스 아키텍처가 개발자 효율성을 떨어트리는 복잡성을 유발한다는 것이다. 이 주장은 사실이 아니다. 마이크로서비스 아키텍처를 사용할 경우 모놀리식으로 구축되는 동급 애플리케이션에 비해 전체적으로 더 복잡한 애플리케이션이 만들어진다는 것은 사실이다. 다만 그 결과로 개발자 또는 설계자의 일이 더 복잡해지는 것은 아니다.   마이크로서비스 아키텍처의 복잡성 대규모 모놀리식 애플리케이션을 구축한 결과로 복잡성에 짓눌리는 상황에 처한 기업이 많다. 하나의 코드 베이스를 붙잡고 작업하면 독립적으로 기능을 추가하거나 결함을 수정하기가 어려워 고민하는 개발자가 너무 많다. 개발자가 한 애플리케이션에서 동시에 작업할 수 있는 프로젝트의 수가 제한된다. 또한 개별 프로젝트에서 수행한 변경이 코드 베이스에 광범위한 영향을 미치는데, 애플리케이션 규모가 커지고 복잡성이 높아지면 이 영향을 파악하기가 어려워진다. 이렇듯 다양한 문제가 결합할수록 복잡성은 계속 높아지고, 결함이 늘어나며 품질은 낮아지고 기술 부채는 증가할 수밖에 없다. 애플리케이션을 개별적인 모듈 또는 부분으로 쪼개면 이 복잡성도 분할할 수 있고, 단일 코드 베이스에서 작업하는 개발자의 수도 줄어들 수 있다. 또한, 변경의 영향 범위도 축소된다. 이는 대체로 더 안정적인 코드, 더 지원하기 용이한 코드, 더 적은 기술 부채, 전...

애플리케이션복잡성 마이크로서비스아키텍처 기술부채 2021.12.08

애자일 부서 설득하기 "기술 부채 인식이 최우선"

지난 몇 년 동안 클라우드 네이티브 마이크로서비스 아키텍처를 다룬 전도유망한 신생업체가 아니라면, 나머지 애자일 개발 부서는 아마 기술 부채 해결에 끙끙 앓고 있을 것이다. 기술 부채는 애플리케이션 및 서비스, 데이터베이스, 인프라 등에 골고루 엮여 있고 규모와 위험, 복잡성, 그리고 비즈니스에 미치는 영향도 다양하다. 기술 부채는 신기능 개발, 고객 경험 향상, 보안 문제 해결, 신뢰성 개선, 성과 증진, 워크플로 자동화, 기타 비즈니스 우선순위 해결 등 다양한 부서의 과업을 가로막는 과제로 작용하고 있다.     기술 부채란 무엇인가? 기술 부채의 정의와 의미는 다양하다. 간단하게 보면 리팩터링이 필요한 코드의 일부분이나 업그레이드가 필요한 라이브러리, 수정이 필요한 유닛 테스트 등이다. 더욱 고차원적인 기술 부채에는 복잡한 일체형 애플리케이션 재설계, 구식 웹 서비스 프로토콜 복사, 단일 표준에 통합된 복수의 플랫폼, 데이터 부채 문제 정리, 인프라 현대화, 관찰 가능성 방식 도입, 밀려 있는 수동 테스트 사례 자동화 등이 속한다. 이중 최악의 유형은 회사에 영향을 미치는 사건과 가동 중단이 반복되는 플랫폼이다. 필자가 간단히 정의하는 기술 부채란 전략적 비즈니스 요건을 구현하기 전이나 구현 단계 중에 프로덕션 단계에서 실행되는 기술에 수정, 리팩터링, 현대화, 업그레이드, 재설계, 또는 교체가 필요한 것을 말한다.   기술 부채가 애자일 개발 부서에 영향을 미치는 방식 기술 부채를 해결해야 하는 애자일 부서와 스크럼 부서가 직면한 난제는 다음과 같다. 조직마다 애자일 채택 방식이 많지만, 대부분의 애자일 방법론에서는 고객과 이해관계자의 필요에 따라 밀린 일의 우선순위를 설정할 책임을 제품 소유자에게 부여한다. 최상의 경우라면 제품 소유자가 경청하고 학습하고 질문하면서 기술 부서와 협력하여 기술 부채를 해결할 것이다. 기술 부채를 우선시하려면 제품 관리 그룹(제품 관리자 및 소유자 포함)은 밀린 일의 우선순위를 확립할 ...

기술부채 클라우드네이티브 마이크로서비스아키텍처 2021.10.18

팬데믹 장기화에 따라온 기술 부채 "지름길은 정답이 아니다"

팬데믹은 대규모 디지털 트랜스포메이션을 가속화하고 많은 기술 기업의 성장을 이끌었다. 인스타카트(Instacart)의 2020년 매출은 2019년 대비 230% 증가했고 팬데믹 초창기 줌의 매출은 169% 늘었다. 많은 기업이 지난 18개월 동안 의지에 관계없이 디지털 트랜스포메이션에 박차를 가할 수밖에 없었다.   이 성장에는 대가가 따랐는데, 특히 줌의 경우가 그랬다. 예상치 못한 큰 관심을 끌게 되자 “줌바밍(Zoombombing: 줌 회의에 침입해 음란물을 보여주거나 부적절한 메시지를 전달하는 행위)”을 포함한 수많은 사이버 공격이 줌을 향했다.    또 다른 대가는 디지털 애플리케이션 성장을 지원하기 위한 기술 부채다. 총소유비용(TCO)은 애플리케이션을 개발하는 비용과 지속적인 유지보수, 업그레이드 및 지원 비용의 합이다. 애플리케이션에서 기술 부채가 발생하면 어느 시점에서는 이 부채를 상환해야 한다. 기술 부채는 애플리케이션을 수정하거나 업그레이드해서 그 부채를 제거하는 방식으로 한 번에 상환할 수도 있지만 오랜 기간에 걸쳐 유지보수, 지원, 기회 손실 비용 증가의 형태로 상환하게 될 수도 있다.   기술 부채가 있으면 리더는 기술을 통해 혁신하고 새롭고 더 개선된 고객 경험을 이끌어내기가 어렵다. 혁신 저해는 장기적인 매출 저하를 의미하기 때문이다.   기술 부채란? 기술 부채는 어렵거나 장기적 비용이 크다는 이유로 더 나은 솔루션이 아니라 더 쉬운 솔루션을 선택한 결과 미결 작업이 증가하는 현상을 의미한다.   어떤 작업을 해야 할 때 선택지는 보통 두 가지다. 완벽하게 하는 방법, 또는 나중에 재작업이 필요하더라도 제한적으로 해서 일단 단기적 요구에 대응하는 방법이다. 후자를 선택하는 경우 기술 부채가 증가한다. 나중에 필요한 재작업이 백로그에 추가되기 때문이다.   기술 부채는 쉽게 시각화할 수 있다. 그림 1은 완전히 실행된 이상적인 프로젝트를 보여준다.   이...

기술부채 2021.10.13

기술 부채가 보안 위험으로 이어지는 7가지 경로

2021년 CISO의 목소리(Voice of CISO) 보고서에 따르면, CISO 3명 가운데 1명은 기술 부채(Technical Debt), 즉 프로젝트에서 필요로 했던 것과 최종적으로 제공된 결과물 간의 차이가 보안 취약점의 큰 원인이 되는 것으로 생각한다.   애플리케이션 보안 플랫폼 제공업체 콘트라스트 시큐리티(Contrast Security) CTO인 제프 윌리엄스는 대부분의 기술 부채는 지름길로 가기 위해 아키텍처, 코드 품질, 성능, 사용성, 궁극적으로 보안과 같은 중요한 측면을 뒤로 미루는 데서 발생한다면서 “많은 대기업이 취약점 관리 시스템에서 수만, 수십만 가지의 위험을 파악하고도 별다른 조치를 취하지 않고 방치한다. 보안에 많이 투자하지 않고도 위험 관리와 함께 사용하면 필요한 보안 수단을 실제로 갖추는 것과 거의 대등한 수준이 된다는 인식이 퍼지고 있다. 이는 위험한 착각으로, 기업과 그 파트너를 심각한 피해에 노출시키는 접근 방식”이라고 설명했다. 기술 부채의 보안 영향을 최소화하려면 먼저 부실하게 관리되는 프로젝트가 침입자와 공격자에게 어떻게 문을 열어주는지, 그리고 발견된 취약점을 어떻게 신속하게 안전하게 교정해야 하는지를 이해해야 한다. 기술 부채가 CISO의 문제가 될 수 있는 7가지 경로를 살펴보자.   1. 부실한 소프트웨어 카네기 멜론 대학교의 하인즈 정보시스템 및 공공정책 대학의 정보시스템 교수인 라훌 텔랑은 기술 부채는 남용되는 용어라면서 “기본적으로 기술 부채란 제품을 만들기 위해 무언가를 빌렸는데 이제 그 빚을 갚아야 한다는 것을 의미한다. 부채를 신속하게 상환하지 않으면 보안 위험이 커진다는 것을 어렵지 않게 상상할 수 있다”라고 말했다.   텔랑은 모든 소프트웨어 개발 프로젝트는 잠재적인 보안 간극 문제를 해결하기 위해 코드를 리팩터링해야 하는 단계를 거친다는 점을 CISO가 인지해야 한다고 강조했다. 제품이 이미 사용되는 상태에서는 문제를 놓치기 쉬우므로 CISO가 배포에 앞서 가...

기술부채 거버넌스 2021.06.24

SAP 클라우드 마이그레이션, 엔터프라이즈 백본 트랜스포메이션을 통한 경쟁우위 구축

  넷플릭스와 리프트처럼 크리티컬 IT 운영을 클라우드에 100% 맡기고 신속하고 자유로운 혁신과 비용 절감 효과를 모두 거둔 기업 사례가 주목 받고 있습니다. 이 두 회사를 포함한 많은 기업이 클라우드가 타당성이 있을 뿐 아니라, 신속하게 경쟁우위를 확보하는 현실적 수단이라는 점을 깨닫고 있습니다.  AWS로 SAP를 운영한 후에는 SAP 데이터를 활용하여 혁신을 가속화 할 가장 다양하고 깊이 있는 네이티브 클라우드 서비스를 이용할 수 있으며, 이런 서비스를 SAP 워크로드와 통합하면 머신러닝, IoT 같은 최첨단 기술을 더욱 쉽게 활용해 새로운 가치 창출에까지 도달할 수 있습니다. <16p>   주요 내용 - 소개 - 클라우드에 대한 잘못된 오해 - 왜 크리티컬 SAP 워크로드를 마이그레이션 해야 하는가 - 효율적인 SAP 마이그레이션을 위해서는 무엇이 필요한가 - 왜 AWS에서 SAP을 운영해야 하는가 - 참고자료 해당 콘텐츠를 받으신 분들 중 추첨을 통하여 [크리스피크림 오리지널 하프더즌]을 드립니다. (12명)

AWS SAP워크로드 마이그레이션 2020.11.11

통합 플랫폼과 역량 내재화를 통한 클라우드 네이티브 애플리케이션 구현 전략 - IDG Summary

클라우드를 필두로 한 IT 인프라의 현대화가 빠르게 진행되고 있다. 하지만 정작 인프라의 가치를 실현하는 애플리케이션은 여전히 과거에 묶여 있는 경우가 많다. 리팩터링이나 아키텍처 변경 등 애플리케이션 현대화의 난이도가 훨씬 높고, 그만큼 비용과 시간도 많이 들기 때문이다. 특히 기업이 자체적으로 관련 역량을 갖추고 있는 경우도 드물어 장기적인 디지털 트랜스포메이션에 대한 불안감도 적지 않다. 클라우드 네이티브 환경을 지향하는 애플리케이션 현대화의 당면 과제를 자세히 살펴보고, 구축과 운영부터 조직 역량의 트랜스포메이션까지 엔드 투 엔드 현대화를 구현할 수 있는 올인원 접근 전략을 소개한다. 주요 내용 - 복잡성과 기술적 부채에 발목 잡힌 IT 현대화 - 클라우드 네이티브 환경의 주요 기술 요소 - 검증된 기술로 구현하는 완성형 플랫폼 - 문화와 프로세스까지 현대화하는 역량 내재화 서비스 - 애플리케이션 현대화로 가는 가장 실용적인 길 인텔® 기반 델 테크놀로지스 클라우드 솔루션  

클라우드네이티브 기술부채 현대화 2020.07.21

글로벌 칼럼 | 로우코드가 지향해야 하는 "품질과 속도의 균형"

개발자들의 부담감은 역대 최고 수준에 달해 있다. 오늘날 24시간 항시 열려 있는 시장 환경으로 인해 늘어나는 수요를 감당하려면 기업은 새로운 기능과 애플리케이션을 거의 하룻밤 만에 내놓을 수 있는 기민함을 갖춰야 한다.    여기에 보조를 맞추려면 개발 팀은 개발 속도를 높이고 코드를 최대한 빨리 작성해야 하는 부담이 있다. 이와 동시에, 고객들의 기대치가 높아지면서 적시에 적절한 기기로 전달될 수 있는 훌륭한 사용자 경험을 창출해야 할 부담도 더해지고 있다.  문제는 앱 개발 속도를 빠르게 하면서 동시에 오류없는 소프트웨어를 만들어낸다는 것이 어렵다는 점이다. 2가지 작업을 벤 다이어그램으로 그린다면 서로 겹쳐지는 부분은 거의 눈에 띄지 않을 것이다. 강력하고 탄탄한 소프트웨어를 빨리 개발하는 일은 그만큼 어렵다. 품질과 속도의 균형을 이루지 못하면 감당할 수 없는 양의 기술 부채(technical debt)가 업무 애플리케이션 내부에 쌓이게 된다. 기술 부채란 새로운 소프트웨어 작업에 투자할 때 감수하는 위험이다. 계속되는 업데이트, 패치 적용, 보안 기능 수정, 기타 유지보수 관련 활동을 통해 기술 부채를 상환해 나간다. 기술 부채는 많은 부분이 계획과 자원 조달에 들어가 있지만 통제 불가 상태가 되는 경우도 있다. 코드를 최대한 빨리 생산하라는 압력이 더해질 때 특히 그렇다. 로우코드의 어제와 오늘 로우코드(low-code) 개발 도구들은 신속한 애플리케이션 생산을 가능하게 해 주는 만병통치약이라고 홍보한다. 그런데 이런 말은 예전에도 들은 적이 있다. 과거에는 코딩 경험이 적거나 전무한 사람들도 마이크로소프트 액세스 또는 파워빌더와 같은 도구들로 소프트웨어 솔루션을 신속하게 구축할 수 있었는데 선견지명이나 계획은 거의 없는 경우가 많았다.  결국 이런 로우코드 도구들은 개발 과정을 단순화하기는 커녕, 오히려 계속되는 유지보수, 보안, 확장성 문제를 일으켜 감당할 수 없는 기술 부채만 늘리고 말았다. 이...

품질 로우코드 기술부채 2019.10.01

글로벌 칼럼 | 기술 부채를 청산하는 핵심 "가장 부채가 큰 영역을 노려라"

비즈니스 책임자는 매일 일정 수준의 기술 부채를 유발할 가능성이 있는 의사 결정을 내린다. HR 프로세스의 능률을 높여주지만 잦은 패치가 필요한 새로운 비즈니스 애플리케이션을 배치하는 경우, 또는 관리 오버헤드가 증가할 것임을 알면서도 새 제품 기능의 제공 속도를 높이도록 선택하는 경우도 있다. 일정한 수준의 기술 부채는 불가피하지만 부채가 장기간에 걸쳐 누적되면 비즈니스 속도를 제약하고 조직의 혁신 역량을 저해하게 된다. 많은 기업에서 기술 부채의 상당 부분은 레거시 애플리케이션, 이질적인 플랫폼과 프로세스, 노후 기술 등으로 발생하는데, 이와 같은 기술 부채는 현대화 이니셔티브의 진행을 더디게 한다. 조직은 디지털 경제에서 경쟁하기 위해 IT 스택을 현대화해야 하지만, 개인 금융 원칙과 마찬가지로 진정한 투자를 시작하기 위해서는 현재의 부채를 먼저 청산해야 한다. 포레스터 리서치에 따르면 노후 애플리케이션과 기술을 유지 보수하는 데 기술 예산의 70% 정도가 소비된다. 이 부채는 개발 속도를 떨어트리고 조직에 위험과 부담이 되지만, 부채를 갚기는 쉽지 않다. 비용을 정량화하고 팀의 관심이 필요한 핵심 기술을 파악하고 비즈니스 중단 없는 현대화를 위한 명확한 계획을 수립할 수 있는 역량이 필수적이다. 기술 부채를 조금씩 해소하려는 시도는 그만 성공적인 조직은 막대한 기술 부채를 장기간에 걸쳐 조금씩 없애려고 하지 않는다. 오래된 전술적인 기술 하나를 더 새롭고 따끈한 버전으로 교체해봤자 이질적인 플랫폼과 미래의 부채를 낳게 될 가능성이 높다. 열쇠는 가속화된 장기적 혁신이 가능한 길로 조직을 이끄는 현명한 투자를 하는 것이다. 가장 먼저 핵심 교차점과 기반 인프라 기술의 기술 부채를 상환하는 것이 최선이다. 다음은 일반적으로 현대화 프로젝트로 얻는 보상이 가장 큰 영역이다. 클라우드 기술 최근 연구에 따르면 대기업의 81%는 멀티 클라우드 전략을 채택하고 있으며, 38%는 올해 퍼블릭 클라우드를 최우선 순위로 여기고 있다...

인프라 디지털트랜스포메이션 기술부채 2018.06.21

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.