.jpg)
.jpg)
신기술로 촉발되는 각종 혁신, 문제 해결 하면 다른 데서 터지고
눈앞에 있는 문제만 해결하다가 더 심각한 것들을 쌓아두는 경우 많아
[보안뉴스 문가용 기자] 새로운 기술로 인한 혁신이 조직에 과연 실제적인 도움이 될지 안 될지 판단하는 건 쉬운 일이 아니다. 특히 혁신을 위해 시스템과 업무 프로세스를 업그레이드 한다는 것에는 돈이 들기 때문에 이 판단은 더 어려워진다. 업그레이드 후에 얻어갈 것도 미래의 구상이지, 직접 경험해본 것은 아니고, 따라서 반드시 이익이 되돌아올 것이라는 보장도 없다.
그러나 빠른 혁신을 추구하다 보면 ‘기술적 부채(technical debt)’가 쌓이게 된다. ‘기술적 부채’란 소프트웨어 개발 분야에서 사용되는 용어로, 소프트웨어 픽스를 통해 당면한 과제를 해결하는 동시에 보이지 않는 부분에서 또 다른 문제의 소지를 누적시킨다는 것을 의미한다. 한 가지 문제를 기술로 해결하는 행위가 반복되면서 상상치 못한 뭔가가 훗날에 터질 수 있다는 것이다.
픽스란, 출시 일을 앞당기고 부족한 예산 안에 일을 완료하느라 생긴 구멍들을 나중에 메운다는 의미로 행해질 때가 많은데, 따라서 여러 IT 팀과 예산 담당자에게 있어 구원자와 같다. 그러나 그건 눈앞에 벌어진 일에만 집중했을 때의 일이다. 예를 들어 새로운 픽스 때문에 소프트웨어의 사용 방식이 바뀔 수 있고, 그에 따라 조직 전체의 생산성이 감소할 수 있다. 그게 바로 기술적 부채다.
지난 수년 동안 기술적 부채는, 웹사이트나 앱, 챗봇 등의 소프트웨어 개발과 관련된 아키텍처를 선택하는 부분에 있어서만 적용되어 온 개념이었다. 이제는 프로그래밍이 가능한 기능이 추가되는 모든 제품과 서비스에도 통용이 되고 있으며, 특히 데이터 및 데이터 분석과 관련된 분야에서도 사용되기 시작했다. 지금은 데이터를 중심으로 이뤄지는 각종 조직 운영과 연계하여 다양한 ‘기술적 부채’를 고려하는 단계에 이르렀다.
간혹 기술적 부채를 ‘낮은 수준의 관리 문제’라고 여기는 사람들이 있다. 위에서 든 예시처럼 ‘픽스로 인한 생산성 감소’가 눈에 금방 띄는 경우라면 틀린 생각이 아니다. 하지만 이 부채라는 것이 반드시 즉각적으로, 눈에 보이게 나타나는 게 아니다. 수년 동안 여러 변수와 또 다른 부채와 맞물려 쌓여가다가 한 번에 폭발적으로 모습을 드러내기도 한다. 그럴 때는 결코 낮은 수준의 문제로 남아있지 않는다.
예를 들어 어떤 코드를 사용하기로 했다고 치자. 요즘의 코드들은 대부분 기능의 올바른 발휘를 위한 디펜던시와 프레임워크를 포함하고 있다. 그런데 그 디펜던시와 프레임워크가 어디서나 올바르게 기능하도록 만들어진 게 아니라 특정 환경에 맞게 조정된 것일 수 있다. 하지만 당장의 기능이 올바르게 발휘되기 때문에 이 부분을 생각지 못하고 그냥 넘어가는 일이 많다. 조직 내에서 사용되는 코드가 점점 늘어나고, 그에 따라 각종 디펜던시와 기능들이 문제를 떠안고 축적된다는 건 시한폭탄을 설치하는 것과 같다.
그렇다면 이 기술적 부채를 줄이기 위해서는 어떻게 해야 할까? 먼저 관리자들이 특정 장비나 소프트웨어 요소를 대체하기로 했을 때, 시일과 계획을 짜면서 ‘복잡성’이라는 개념을 투영시켜야 한다. 기술이라는 건, 그것이 뭐가 됐건 운영 논리에 어느 정도의 복잡성을 가져올 수밖에 없다. 억지로 단순하게 하려고 하는 건, 기술 부채를 쌓아주십쇼, 하고 부탁하는 것과 같다.
이를 위해 스스로 묻고 답을 추구해야 할 질문은 “지금 조직 내 기술적 스택(stack)의 상태가 어떠한가?”이다. 쉽게 말하자면 IT 환경의 관계를 나타낼 수 있는 지도, 즉 마인드맵(mind map)을 그리라는 것이다. 그렇게 하면 어떤 요소를 빼거나 더했을 때 다른 부분에 미치는 영향을 좀 더 빠짐없이 관찰할 수 있다.
모든 ‘기술적 스택’에는 경비 비출 속도(burn rate)와 유틸리티성의 생애주기라는 요소가 존재한다. 또한 모든 ‘유용성’에는 한계라는 게 있다. 마인드맵이 완성되었다면 이러한 점을 염두에 두고 각종 요소가 빠지거나 더해지는 시나리오를 마련해야 한다. 이 시나리오를 검토하다 보면 일을 어떤 식으로 진행해야 하고, 어떤 부분이 가장 시급한 업그레이드를 요하는지 파악할 수 있을 것이다.
기술적 부채는 사람에게서 나오기도 한다. 하지만 기술적 부채에 대한 부담을 줄인다고 모든 사람의 모든 것을 감시할 수는 없다. 이럴 땐 문서화 체제를 마련하는 게 도움이 된다. 올바른 문서 양식을 마련하고, 모든 참여자들이 제대로 기입할 수 있도록 제도를 마련한다면, 문제가 발생했을 때 그 근원을 찾아내는 게 의외로 잘 된다. 물론 이런 체제는 생산성에 영향을 줄 수 있다는 걸 고려해야 한다.
기술적 부채를 줄이기 위해 ‘신기술 도입’을 늦추는 기업들도 있다. 실제 상담 시 필자는 “다른 건 몰라도 데이터 분석과 관련된 기술은 최대한 서둘러 도입하라”고 조언하는 편이다. 그렇지 않으면 시장에서 얻을 수 있는 많은 기회들을 놓치게 되기 때문이다. 그 망설임으로 인한 조직 전체의 휘청거림도, 기술적 부채의 악영향 중 하나로 볼 수 있다.
글 : 피에르 드보아(Pierre Debois), Zimana
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
눈앞에 있는 문제만 해결하다가 더 심각한 것들을 쌓아두는 경우 많아
[보안뉴스 문가용 기자] 새로운 기술로 인한 혁신이 조직에 과연 실제적인 도움이 될지 안 될지 판단하는 건 쉬운 일이 아니다. 특히 혁신을 위해 시스템과 업무 프로세스를 업그레이드 한다는 것에는 돈이 들기 때문에 이 판단은 더 어려워진다. 업그레이드 후에 얻어갈 것도 미래의 구상이지, 직접 경험해본 것은 아니고, 따라서 반드시 이익이 되돌아올 것이라는 보장도 없다.
[이미지 = iclickart]
그러나 빠른 혁신을 추구하다 보면 ‘기술적 부채(technical debt)’가 쌓이게 된다. ‘기술적 부채’란 소프트웨어 개발 분야에서 사용되는 용어로, 소프트웨어 픽스를 통해 당면한 과제를 해결하는 동시에 보이지 않는 부분에서 또 다른 문제의 소지를 누적시킨다는 것을 의미한다. 한 가지 문제를 기술로 해결하는 행위가 반복되면서 상상치 못한 뭔가가 훗날에 터질 수 있다는 것이다.
픽스란, 출시 일을 앞당기고 부족한 예산 안에 일을 완료하느라 생긴 구멍들을 나중에 메운다는 의미로 행해질 때가 많은데, 따라서 여러 IT 팀과 예산 담당자에게 있어 구원자와 같다. 그러나 그건 눈앞에 벌어진 일에만 집중했을 때의 일이다. 예를 들어 새로운 픽스 때문에 소프트웨어의 사용 방식이 바뀔 수 있고, 그에 따라 조직 전체의 생산성이 감소할 수 있다. 그게 바로 기술적 부채다.
지난 수년 동안 기술적 부채는, 웹사이트나 앱, 챗봇 등의 소프트웨어 개발과 관련된 아키텍처를 선택하는 부분에 있어서만 적용되어 온 개념이었다. 이제는 프로그래밍이 가능한 기능이 추가되는 모든 제품과 서비스에도 통용이 되고 있으며, 특히 데이터 및 데이터 분석과 관련된 분야에서도 사용되기 시작했다. 지금은 데이터를 중심으로 이뤄지는 각종 조직 운영과 연계하여 다양한 ‘기술적 부채’를 고려하는 단계에 이르렀다.
간혹 기술적 부채를 ‘낮은 수준의 관리 문제’라고 여기는 사람들이 있다. 위에서 든 예시처럼 ‘픽스로 인한 생산성 감소’가 눈에 금방 띄는 경우라면 틀린 생각이 아니다. 하지만 이 부채라는 것이 반드시 즉각적으로, 눈에 보이게 나타나는 게 아니다. 수년 동안 여러 변수와 또 다른 부채와 맞물려 쌓여가다가 한 번에 폭발적으로 모습을 드러내기도 한다. 그럴 때는 결코 낮은 수준의 문제로 남아있지 않는다.
예를 들어 어떤 코드를 사용하기로 했다고 치자. 요즘의 코드들은 대부분 기능의 올바른 발휘를 위한 디펜던시와 프레임워크를 포함하고 있다. 그런데 그 디펜던시와 프레임워크가 어디서나 올바르게 기능하도록 만들어진 게 아니라 특정 환경에 맞게 조정된 것일 수 있다. 하지만 당장의 기능이 올바르게 발휘되기 때문에 이 부분을 생각지 못하고 그냥 넘어가는 일이 많다. 조직 내에서 사용되는 코드가 점점 늘어나고, 그에 따라 각종 디펜던시와 기능들이 문제를 떠안고 축적된다는 건 시한폭탄을 설치하는 것과 같다.
그렇다면 이 기술적 부채를 줄이기 위해서는 어떻게 해야 할까? 먼저 관리자들이 특정 장비나 소프트웨어 요소를 대체하기로 했을 때, 시일과 계획을 짜면서 ‘복잡성’이라는 개념을 투영시켜야 한다. 기술이라는 건, 그것이 뭐가 됐건 운영 논리에 어느 정도의 복잡성을 가져올 수밖에 없다. 억지로 단순하게 하려고 하는 건, 기술 부채를 쌓아주십쇼, 하고 부탁하는 것과 같다.
이를 위해 스스로 묻고 답을 추구해야 할 질문은 “지금 조직 내 기술적 스택(stack)의 상태가 어떠한가?”이다. 쉽게 말하자면 IT 환경의 관계를 나타낼 수 있는 지도, 즉 마인드맵(mind map)을 그리라는 것이다. 그렇게 하면 어떤 요소를 빼거나 더했을 때 다른 부분에 미치는 영향을 좀 더 빠짐없이 관찰할 수 있다.
모든 ‘기술적 스택’에는 경비 비출 속도(burn rate)와 유틸리티성의 생애주기라는 요소가 존재한다. 또한 모든 ‘유용성’에는 한계라는 게 있다. 마인드맵이 완성되었다면 이러한 점을 염두에 두고 각종 요소가 빠지거나 더해지는 시나리오를 마련해야 한다. 이 시나리오를 검토하다 보면 일을 어떤 식으로 진행해야 하고, 어떤 부분이 가장 시급한 업그레이드를 요하는지 파악할 수 있을 것이다.
기술적 부채는 사람에게서 나오기도 한다. 하지만 기술적 부채에 대한 부담을 줄인다고 모든 사람의 모든 것을 감시할 수는 없다. 이럴 땐 문서화 체제를 마련하는 게 도움이 된다. 올바른 문서 양식을 마련하고, 모든 참여자들이 제대로 기입할 수 있도록 제도를 마련한다면, 문제가 발생했을 때 그 근원을 찾아내는 게 의외로 잘 된다. 물론 이런 체제는 생산성에 영향을 줄 수 있다는 걸 고려해야 한다.
기술적 부채를 줄이기 위해 ‘신기술 도입’을 늦추는 기업들도 있다. 실제 상담 시 필자는 “다른 건 몰라도 데이터 분석과 관련된 기술은 최대한 서둘러 도입하라”고 조언하는 편이다. 그렇지 않으면 시장에서 얻을 수 있는 많은 기회들을 놓치게 되기 때문이다. 그 망설임으로 인한 조직 전체의 휘청거림도, 기술적 부채의 악영향 중 하나로 볼 수 있다.
글 : 피에르 드보아(Pierre Debois), Zimana
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
