CIO / 개발자

"우리 회사 IT가 산으로 가는 신호" 잘못된 IT 의사결정 패턴 12가지

Isaac Sacolick  | InfoWorld 2021.08.11
새로운 기술을 보면 사탕가게에 간 어린아이처럼 바로 시도해보고 싶은가? 조직 리더가 기술을 도박처럼 대하는 사람이라서 충분한 분석을 하거나 상당한 주의를 기울이지 않고 업체를 선택하는 경향이 있는가? 조달 관리자, 프로젝트 관리자, 비즈니스 이해관계자는 조직에 혁신이 필요한 상태이거나 구형 플랫폼에서 벗어나지 못하고 있다는 정확한 조사를 눈으로 봐야만 IT와 관련한 올바른 선택을 할 수 있는 것일까?

이러한 기술 구매 페르소나는 많은 조직에서 발견되며, 현명하고 시기 적절한 기술을 선택할 수 있는 기술 리더의 능력을 저하시킬 수 있다. 우발적 기술 선택으로 인해 노력이 낭비되고 기술 부채가 발생하는 반면, 지나치게 체계적인 접근 방식은 혁신의 속도를 늦추고 실험, 현명한 위험 감수 및 민첩한 문화를 방해한다.
 
ⓒ Kaspars Grinvalds / Shutterstock

이러한 구입 페르소나는 기술 평가 프로세스의 정체부터 기술 투자 시기 및 고려해야 할 제품 또는 서비스에 대한 의사결정을 저해까지 다양한 방식으로 기술 의사결정 프로세스를 방해할 수 있다. 현명한 기술 결정을 내려야 할 때 해서는 안 되는, 잘못된 의사결정 패턴 12가지의 예를 모았다.
 

경영진 판단을 최종 결정으로 받아들이는 실수

CEO나 영향력 있는 경영진이 기술 부서에 특정 기술 솔루션을 구입하고 구현하도록 요구할 경우, 근거를 이해하려면 몇 단계 뒤로 물러나는 것이 중요하다. 이 리더가 해결하고자 하는 문제는 무엇이며, 솔루션이 기대에 얼마나 부합하는가? 기술 리더가 경영진의 목소리를 명령으로 받아들이고 접근 방식을 합리화하거나 대안을 제시하지 않는 경우는 아주 많다. 

한 가지 해결책은 문제, 기회 또는 가치 제안에 초점을 맞춘 1페이지짜리 비전 선언문을 작성하고 제시하는 것이다. 잘 만들어진 비전 선언문은 목표를 정의하지만 솔루션 또는 구현과 관련하여 규범적이지는 않다. 경영진을 대신하여 기술 부서가 이 문건을 작성하더라도 여러 솔루션에 대한 토론과 논의로 이어지는 경우가 많다.
 

고객 의견을 구하거나 고려하지 못하는 실수

엔지니어들은 때때로 경영진들 구현에 뛰어들 때와 동일한 실수를 한다. 기술자들은 문제를 보고 있고 해결책을 알고 있으며, 긴급함을 느껴서 해결책을 구현하고자 한다. 유감스럽게도, 고객의 목소리를 의사결정 과정에 포함하지 않거나 고객에게 제공하는 혜택(또는 불이익)을 이해하면서 동시에 핵심을 벗어나는 기능을 쉽게 제공할 수 있다. 조직에서는 특정 기술 프로젝트에 대해 고객이 누구인지 공식적으로 정의하지 못하는 경우가 많다. 

역할 및 페르소나를 정의해서 최종 사용자 애플리케이션을 개발할 때에는 고객 정의가 훨씬 쉽다. 그러나 인프라, 보안 기능, 미들웨어, 라이브러리 또는 웹 서비스를 비롯한 백엔드 기능을 고려할 때 고객 역할을 찾는 것은 더 어려울 수 있다. 하지만 기술자도 비즈니스의 일부다. 설계자, 비즈니스 분석가 또는 기술 담당자는 백엔드 기술을 구현할 때 고객의 역할을 대신할 수 있다. 이들에게 요구사항을 제공하고, 허용 기준을 식별하고, 상충관계에 대한 결정을 내리고, 구현된 솔루션에 대한 만족도를 평가하도록 요청하라. 
 

기존의 표준과 기술을 무시하는 실수

역사적으로 기술 부서는 문서를 작성하고 유지하며 표준을 전달하고 관리하는 데 어려움을 겪어 왔다. 따라서 긴급한 요청이나 주요 요구사항이 표면화될 경우 기존 기능을 조사하고 재사용하기보다는 새로운 솔루션을 모색할 가능성이 높다.

이러한 접근 방식은 중복 기능, 저개발 솔루션, 증가하는 기술 부채로 이어지는 경우가 많다. 새로운 솔루션을 조사하기 전이나 조사의 일부로 ‘내부 솔루션 연구’ 단계를 추가하는 것은 재사용을 늘릴 수 있는 간단한 방법이다. 사람들이 새로운 기술을 추천할 때, 구형 플랫폼에 대한 업그레이드를 예측하거나 유사한 기능을 가진 기술을 통합하는 프로세스를 만들도록 한다. 
 

단일 업체, 단일 기술 문화 접근법에 의존하는 실수

업체와 선호하는 업체가 있다는 것과 제3자의 역량에 대해 무지하며, 대안에 대한 논의를 방해하는 것은 다른 문제다. 
몇몇 강력한 플랫폼 옹호자의 목소리로 탐사나 실험이 묻혀질 경우 큰 대가를 치러야 할 실수로 이어질 수 있다. 기술 리더는 이러한 문화적 안티패턴을 공개적으로 다루어야 한다. 특히 사람들이 질문을 하지 못하는 분위기를 만들거나 현상 유지를 깨지 못하게 하는 패턴이라면 더욱 그렇다. 
 

구축이나 구매만이 유일한 선택이라고 가정하는 실수

맞춤형 코드를 사용하여 솔루션을 구축하는 것과 SaaS 또는 뛰어난 기능을 제공하는 기타 기술을 구매하는 것 사이에는 광범위한 회색 지대가 있다. 그 공간에 구성이 가능한 로우코드 및 노코드 플랫폼, 상업적 파트너십, 오픈소스 기술 활용 기회 등이 있다. 

따라서 구축 대 구매라는 구도는 지나친 단순화다. 필요한 기능이 비즈니스를 차별화하는 데 도움이 되는지 여부와 장기적으로 더 많은 혁신과 유연성을 제공하는 솔루션 유형이 무엇인가를 묻는 것이 훨씬 더 나은 질문이다.
 

API가 통합 니즈를 충족한다고 가정하는 실수

대부분의 최신 SaaS와 심지어 많은 엔터프라이즈 시스템은 API 및 기타 통합 옵션을 제공한다. 그러나 통합 후크 카탈로그를 작성하는 것은 그것들이 비즈니스 니즈를 충족하는지를 조사하는 시작에 불과하다. API에서 노출되는 데이터는 무엇인가? 바람직한 보기 및 트랜잭션이 지원되는가? 데이터 시각화 툴과 머신 러닝 툴을 쉽게 연결할 수 있는가? API가 충분히 작동하는가? 고려해야 할 기본 사용 비용이 있는가? 

통합 기능 검토를 가속화하는 방법에는 API를 검증하는 3가지 방법과 로우코드 통합 플랫폼을 활용하는 방법이 포함된다.
 

사회적 주의 의무를 다하지 못하는 실수

가능한 해결책이 많이 있을 때, 신뢰할 수 있는 정보 소스가 경쟁의 장을 좁히는 데 도움이 될 수 있다. 블로그, 백서, 리뷰, 연구 보고서를 읽고 웨비나, 키노트, 온라인 튜토리얼을 시청하는 것 등은 전부 핵심 학습 단계다. 그러나 소셜 네트워크를 활용하여 전문가와 상담하는 방법이 종종 간과된다. 처음에는 IDGTechTalk와 #CIOChat 같은 곳에서 많은 전문가의 조언을 참고하고 대안 솔루션을 공유하는 것이 좋다.
 

개념증명을 건너뛰는 실수

기술을 선택하는 기법, 기교 및 과학에는 핵심 전략적 요구사항에 대한 가정을 검증하고 테스트를 수행하는 개념 증명 솔루션(PoCs) 설계 및 실행이 포함된다. PoCs는 새로운 기술을 검증하거나 SaaS 플랫폼을 평가할 때 특히 중요하지만, 신속한 변화를 위한 스파이크를 사용하여 타사 기술 구성요소를 검토하는데 애자일 스파이크를 사용하는 것은 의사결정을 가속화하고 값비싼 실수를 방지할 수 있다. 

가장 큰 실수는 PoC를 건너뛰는 것일 수 있다. 읽은 내용을 믿거나 업체를 신뢰하거나 너무 많은 시간압박에 직면하기 때문이다. PoC가 기술을 승인하는 경우에도 PoC에서 배운 내용은 실현 가능한 구현에 우선순위를 설정하는 데 도움이 된다.
 

너무 정교한 의사결정 매트릭스를 개발하는 실수

새로운 툴과 기술을 검토하고 평가할 때, 데이터 중심적인 의사결정을 이끌어내는 데 도움이 되는 한 가지 일반적인 접근 방식은 의사결정 매트릭스 스프레드시트를 만드는 것이다. 중요도에 따라 특징과 역량에 가중치를 부여한 후 검토 위원회에서 평가한다. 스프레드시트가 집계 점수를 계산한다. 

안타깝게도, 너무 많은 사람이 참여하거나, 너무 많은 기능을 선택하거나, 임의로 가중치를 지정하면 이러한 툴은 관리 범위를 빠르게 벗어날 수 있다. 스프레드시트는 결국 작성자의 선호도를 우선시하게 되고, 모든 보조기능을 검토하다가 전략적으로 평가해야 할 것이 무엇인지 파악하지 못하게 된다.

의사 결정 매트릭스에 착수하기 전에 한 걸음 물러나라. 너무 많은 검토자가 긴 기능 목록을 평가하도록 요구하지 말고 솔루션의 특성을 비즈니스 문제의 본질까지 좁히는 것을 고려해 보도록 한다.
 

장기적인 아키텍처, 라이프사이클 및 지원 고려사항을 무시하는 실수

필자는 사용 편의성 및 가치 실현 시간(TTV)을 기반으로 기술을 평가하는 것을 매우 지지하지만, 그렇다고 장기적인 아키텍처, 유지보수 및 지원 고려사항이 중요하지 않거나 평가가 필요하지 않다는 것은 아니다. 

언제 평가를 할 것인가, 주요 고려사항은 무엇인가, 검토 관계자는 누구인가, 얼마나 평가에 투자해야 하는가 등을 결정하는 것이 관건이다. 이를 위한 좋은 방법은 기술 부서가 평가를 시작할 때 고려해야 하는 게이트 우려, 그리고 의사결정 과정에 투입이 되어야 하는 장기적 요인을 분리하는 것이다.
 

SLA, 데이터 보호 및 보안 검토를 생략하는 실수

선택한 기술에 대한 시간 압박 또는 (맹목적인) 신뢰는 서비스 수준 협약(SLA) 검토와 업체 보안 및 데이터 보호 관행에 대한 평가를 소홀히 하는 변명이 될 수 없다. 이러한 검토를 잘 수행하는 비결은 기술자와 비즈니스 후원자가 검토를 병목 현상으로 인식하지 않도록 필요한 전문 지식, 협상 기술 및 툴과 효율적인 평가 프로세스를 갖추는 것이다.

사내에서 SLA, 데이터 보호 및 보안 검토를 수행하는 대규모 조직은 시간 효율적이어야 하며 평가를 주요 리스크에 맞추는 데 주력해야 한다. 전문지식이 부족한 중소기업은 솔루션 분야에 대한 전문지식을 갖춘 외부인을 찾아야 한다.
 

재무 및 법률 검토를 지연시키는 실수

기사에서 언급한 안티패턴들은 너무 오래 기다리느라 수행에 필요한 전문가를 끌어들이지 못하고 있다.

많은 SaaS 제품, API 서비스 및 클라우드 네이티브 기술이 소비 기반의 가격 모델을 가지고 있으며 운영 비용이 예산 또는 재정적 제약을 충족하지 못할 수 있다는 점을 고려해야 한다. 법률 검토는 규제 대상 산업 또는 글로벌 기업에 특히 중요하며, 두 경우 모두 규정 준수 요소를 검토하는 데 특히 많은 시간이 소요된다. 재무 및 법률 검토의 경우 지연으로 인해 큰 비용을 치러야 할 수 있다.

기술 검토 프로세스가 끝날 때까지 기다리지 말고 먼저 재무 및 법률 전문 지식을 구하라.  기술 선택 결정을 내리기 전, 초기 검토에 대한 의견을 요구하라고 충고하고 싶다. 또한 한 번에 너무 많은 평가를 진행함으로써 재무 및 법률 리소스를 혹사시켜서는 안 된다. 

여러 기술 평가를 최대한 잘 조정하는 것은 현실적으로 어렵다. 경영진들은 먼저 좋은 제품을 알아보고 구입하려는 노력을 우선시해야 한다. 그 후에는 분명 포괄적이며 효율적인 기술 검토가 이루어질 수 있을 것이다. editor@itworld.co.kr 

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

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

Copyright © 2024 International Data Group. All rights reserved.