비효율을 초래하는 오랜 관행들을 청산하고 프로젝트 관리를 간소화 하는 작업은 모든 IT 임원에게 중요하다. 그렇다면 비효율을 초래하는 관행, 이
CIO닷컴은 여러 기술 분야의 리더들에게 시간을 절약하고, 효율성을 증대시킬 수 있는 그들 만의 팁을 공유해 달라고 부탁해 보았다. 고맙게도 많은 이들이 여러 구체적인 조언들을 제공해줬다.
이메일 사용 효율화
절약해주는 시간보다 버리는 시간이 더 많은 기술도 있다. 맥아피의 클라우드 솔루션 수석 부사장 라지브 굽타는 이메일을 대체할 만한 마땅한 메시징 솔루션이 없는 것이 사실이지만, 이메일 고유의 한계로 인해 시간과 집중력을 낭비하게 되는 단점이 있다고 지적한다.
“우선, 이메일은 스트레스를 유발한다. 나와 관계 없는 이메일까지도 전부 눈으로 스캔하며 읽어야 하기 때문에 정작 나와 관련이 있는 내용, 나에게 중요한 내용을 놓치는 일도 있다. 그러나 인공 지능 기술이 발달하면 앞으로 이런 문제는 많이 줄어들 것이라고 생각한다”라고 굽타는 말했다.
신트(Cint)의 CIO인 오스카 칼슨은 이메일 자체가 문제라기 보다는 이메일을 활용하는 방식에 있어서의 비효율성이 시간과 에너지를 낭비하게 만든다고 다음과 같이 지적했다.
“한 팀에 5명의 멤버가 있다고 해 보자. 팀 메일을 보낼 때 항상 5명 모두에게 보내야만 할까? 5명의 직원들이 모두 당신이 보낸 이메일을 읽고, 그 안에 담긴 정보를 이해하기 위해 시간을 소모할 필요가 있을까? 우리가 보내는 이메일의 십중팔구는 그들 중 한두 명의 사람만 읽으면 되는 내용들이다. 즉 기존의 이메일 시스템은 많은 비효율성을 낳고 있다는 얘기다.”
“또한, 이메일 쓰레드에 새로운 멤버를 추가할 때는 기존 대화 내용을 적당히 요약하여 대화의 목적과 맥락을 빠르게 파악할 수 있도록 도와 주어야 한다. 5주 동안 기존 멤버들이 주고 받아 온 이메일을 일일이 다 읽고 상황 파악을 해야 한다면 그것이야말로 시간 낭비가 아닐까?”
워터폴(Waterfall) 방법론 지양하기
eMoney의 CTO 닉 딜라이시는 한 팀이 다른 팀에게 태스크를 넘기는 워터폴 방법론을 지양하고 보다 최신의 방법론을 도입하라고 조언했다.
그는 “소프트웨어 개발에 있어서 전통적인 워터폴 방식은 사실상 도태되었다. 테크놀로지 팀들은 최대한 빠른 개발 사이클을 유지하기 위해 노력해야 한다. 기술이 빠른 속도로 변화하는 만큼 기술 팀도 변화에 빠르고 민첩하게 적응할 수 있는 애자일한 태도가 필요하다”라고 말했다.
선가드 AS의 CIO 크리스 필딩 역시 비슷한 접근을 제안한다.
“애자일 방법론으로의 이전과 같은 조직적 차원에서의 변화는 성공적으로 해내기가 쉽지 않다. 지속적인 노력과 시간, 그리고 리더십 팀으로부터의 지원이 필요하기 때문이다. 애자일로의 여정을 시작하는 기업들이 가장 먼저 버려야 할 것은 워터폴 방법론 및 기획 툴이다”라고 필딩은 말했다.
때로는 인맥이 해답
딜라이시는 동료들의 경험을 바탕으로 전문가 인맥을 확장시키라고 조언했다. 또한, 의사 결정 과정에 이러한 인적 네트워크를 포함시킬 필요가 있다고도 말했다.
“어떤 아이디어가 떠올랐을 때 여러 사람에게 그에 대해 이야기하고 질문을 던짐으로써 엄청나게 많은 시간을 절약할 수 있다. 혼자서 고민할 때는 나만 이런 문제를 겪는 것 같지만, 다른 이들과 소통하다 보면 사실 비슷한 문제를 겪었거나 겪고 있는 사람들이 아주 많다는 것을 알게 된다”고 딜라이시는 말했다.
불필요한 파일럿 프로젝트 제거
비즈니스 문제와 관련 없는 기술 개발을 중단하는 것만으로도 많은 시간을 절약할 수 있다고 딜라이시는 주장했다.
“많은 기업들이 클라우드나 인공 지능, 기계 학습과 같은 테크놀로지에 개념 증명(POC)이라는 단어를 사용하곤 하지만, 사실 이런 기술들은 POC가 필요하지 않다. 물론, 이런 기술들을 이해하고 이를 어떻게 비즈니스에 적용할 것인가를 고민할 필요는 있다. 오늘날 기술은 빠른 속도로 성장해 나가고 있으며 POC는 이렇다 할 비즈니스적 가치는 제공하지 못한 채 비용만 잡아먹는 결과를 낳을 수 있다”라고 그는 말했다.
클라우드 솔루션의 명과 암
클라우드는 분명 훌륭한 콜라보레이션 툴이며, 직원들이 진행 상황을 함께 보고 신속하게 작업할 수 있게 도와 준다고 아이보스(iboss)의 CMO 짐 맥닐은 전제했다. 그러나 클라우드 솔루션들이 제대로 공조하지 않을 경우 오히려 다른 문제들을 낳기도 하며 시간을 지체시키는 경우도 있다고 그는 덧붙였다.
맥닐은 “너무나 많은 포인트 솔루션이 존재하기 때문에 애플리케이션의 홍수에 떠밀려 내려가지 않도록 조심해야 한다. 클라우드 솔루션 간 중요 정보를 공유하는 것도 어려운 문제로 남아 있다. 또한 섀도우 IT의 존재를 항상 고려해야 하며 사용 중인 서비스가 충분히 안전한지, 필요로 하는 기능을 제공하는지 확인할 필요가 있다”라고 말했다.
실패는 신속하게
애자일이나 데브옵스 관행을 도입하고자 하는 기업들은 커스터마이징이 가능한 지원 툴을 찾아 도입 과정에 활용해야 한다고 선가드 AS의 필딩은 말했다.
“그 툴의 어떤 기능이 변화를 주도하고, 변화의 경로를 조정하는 데 필요한 정보를 제공하는지 아는 것이 중요하다. 어떤 기능들이 가치를 창출하는지를 파악해 가치를 창출해 내지 못하는 것들은 미련 없이 버려야 한다. 필요한 정보를 확보하지 못하면 애자일로의 이전이 더욱 느려 질 수 있다”고 필딩은 말했다.
이중 프로세스 방지
비즈니스 또는 고객과 중복 되는 이중 프로세스를 방지하려면 단일 전달 경로를 찾아야 한다고 뉴스타(Neustar)의 CIO 제프 질은 말했다.
“IT팀은 새로운 아이디어와 전략적 목표를 위해 명확한 수용 프로세스를 가지고 있어야 한다. 일단 목표를 설정하고 나면, 우선 순위를 결정하고 IT 프로젝트를 생성하는 것만으로도 기술 팀이 수행해야 할 사항이 무엇인지를 충분히 이해할 수 있게 된다. 그러면 사전에 결정된 일정, 범위 및 예산에 부합하는 이정표를 제시하기가 더욱 수월해진다. 궁극적으로 기술 팀이 재작업을 피할 수 있게 되므로 시간 또한 절약 된다”라고 질은 말했다.
문제를 설명하고 기술 팀이 직접 결정하게
뉴스타의 질은 업무 그룹 간 솔직한 의사소통과 효율적인 프로젝트 작업 라인 형성, 그리고 프로젝트의 원활한 진행을 위한 대시보드 관리의 중요성을 강조했다.
“내가 생각할 때 이것은 기술적 문제라기가 아니다. 오히려 업무 습관과 더욱 관련이 있다. 대부분 IT 전문가들은 문제를 해결하도록 전문적인 트레이닝을 받은 인력들이다. 때문에 이들에게 솔직하게 문제가 무엇인지 털어 놓고, 각 팀에게 어떤 문제를 해결할 것인지 선택하게 해주는 쪽이 단순히 시간 절약을 위해 노력하는 것보다 훨씬 효과적일 것이라 생각한다. 아마도 기술 팀은 문제 해결에 가장 적합한 툴과 테크놀로지를 알아서 선택할 것이다”라고 질은 말했다.
단순 보고에 그치는 스탠드업 미팅을 없앨 것
이지비스타(EasyVista)의 CMO이자 수석 부사장인 존 프레스트리지는 스탠드업 미팅(각자 자리에 서서 짧은 시간 동안 이루어지는 업무 미팅)을 그다지 좋게 생각하지 않는다. 그는 업무 효율화를 위해서는 이와 같은 데일리 미팅이 가장 먼저 사라져야 한다고 주장했다.
“주기적으로 이루어지는 스탠드업 미팅은 본격적인 협업이나 문제 해결 보다는 단순한 현황 보고에 그치는 경우가 많다. 모두가 한 자리에 모이는 미팅 시간은 중요한 문제를 해결하는 데 쓰기에만도 모자라다. 또한 정말 중요한 문제를 해결하는 데 필요한 것 이상의 시간을 빼앗아서는 안 된다”고 프레스트리지는 말했다.
적합한 생산성 소프트웨어 도입
프레스트리지 역시 다른 이들과 마찬가지로 이메일이 그다지 효율적인 업무 수단이라고 생각하지 않으며 집중력을 방해한다고 보고 있다. 그는 이메일보다 오히려 전문 협업 툴을 선호하는 편이다.
“실시간 동시 협업에는 슬랙이 무척 효과적이다. 슬랙은 애자일 방식을 지원하여 프로젝트 진척 상황을 가속화시킨다. 프로젝트 간 전환이 무척 빠르며 각 프로젝트와 관련된 대화 내용이나 관련 문서들을 볼 수 있다. 한편, 트렐로는 업무 우선 순위를 정하고 프로젝트에 가시성을 더하기에 적합하다. 산재해 있는 과제들에 우선 순위를 배분하기에 무척 유용한 도구이다” 라고 그는 말한다.
비효율적인 방식은 과감히 버릴 것
우리가 인터뷰한 전문가들 중 2명 이상이 “항상 이렇게 해 왔으니까” 라는 말이 나오면 경계를 해야 한다고 조언했다. 이런 말은 비효율적이고 비합리적인 기존 관행을 변호할 때 반사적으로 나오는 말이기 때문이다.
“새로운 기술은 새로운 효율성을 창출하며, 그 특성상 기존의 기술을 정면으로 반박하는 부분이 있을 수밖에 없다. 예컨대 레거시 애플리케이션 패칭에서는 효율적이고 훌륭한 관행이라도 이것이 컨테이너화 또는 서버리스 애플리케이션에 적용될 경우 리스크가 큰 모델이 될 수 있다”고 시놉시스 소프트웨어 인테그리티 그룹(Synopsys Software Integrity Group)의 테크놀로지 전문가 팀 맥케이는 말했다.
과거의 경험에 사로잡혀서는 안 된다
위의 이야기와 같은 맥락에서, 확증 편향은 디지털 전환에 브레이크를 걸 수 있다고 아이보스의 맥닐은 말했다. 그는 많은 경영자들이 ‘과거 경험’에 발목 잡혀 일을 그르치는 모습이 놀랍다고 말한다.
“과거의 방식으로 미래의 문제를 해결하려 해서는 안 된다. 내가 원하는 결과가 무엇인지에 집중하고, 거기서부터 역행하여 방법을 찾아야 한다. 내가 필요로 하는 답은 이미 질문 속에 들어 있다. 기업들은 질문을 던지는 사람, 호기심을 갖는 사람을 싫어하고 억누르려는 경향이 있는데 사실은 그 정반대로 행동해야 한다”고 맥닐은 말했다.
법무팀과의 네트워크 형성
늦던 빠르던 언젠가 한 번은 기업 변호사들의 조언이 필요해지는 시점이 오게 된다. 필요할 때 유효한 조언을 빠르게 얻고 싶다면 그 때까지 기다리지 말고 미리 이들과 네트워크를 형성해 두어야 한다.
“통계적으로 볼 때, (예컨대 IT 거버넌스 이슈 같은 것은) 어딘가에서 문제가 생기거나 잘못 될 확률이 낮지 않다. 이 때 문제의 초기 단계에서부터 법무 팀의 도움을 받을 수 있다면 훨씬 더 부드럽게 문제를 풀어 나가고 불필요한 갈등을 줄일 수 있다. 이는 조직 내에서 리스크가 어떤 식으로 배분 되는지를 이해하는 것과도 깊은 관계가 있다”고 맥케이는 말했다.
차일피일 연기되며 규모만 커지는 프로젝트에 주의
그런가 하면, 겉보기에는 시간을 아껴줄 것 같아 도입한 테크놀로지가 오히려 조직에 맞지 않아 시간을 낭비하게 만드는 경우도 있다고 맥케이는 말했다.
“각 팀의 성과를 평가하고, 프로젝트 및 프로젝트 범위에 대해 직접 책임을 지도록 해야 한다. 대규모 예산을 투입한 IT 프로젝트가 시간이 갈수록 예산이나 범위가 넓어져 결국 출시 일자가 지연되는 경우를 심심찮게 볼 수 있다. 성공적인 프로젝트들은 대개 작게 시작해서 점차 가치를 증명해 나가며 성공을 통해 몸집을 불린다. 그 과정에서 조직 고유의 거버넌스 룰 내에서 최선의 관행이 무엇인가를 함께 배워 나가는 것이다. 바꿔 말하자면, 문제를 해결하는 데에는 한 가지 방법만 있는 것이 아니며 때로는 조직의 관성을 역행하는 것이 생산적이지 않을 때도 있다는 것이다”라고 그는 말했다.
1세대 테크놀로지에는 리스크가 따른다
어떤 기술이든 가장 처음 나온 것은 시간을 두고 지켜 볼 필요가 있다고 필딩은 강조했다. 새로운 테크놀로지에는 항상 ‘함정’이 도사리고 있을 가능성이 높으며 인수 후 완전히 새로운 기업을 상대해야 하는 등 비효율적인 요소들이 많다는 설명이다.
“조직적 변화를 지원하는 새로운 테크놀로지들 중 어떤 것이 리스크를 질 만큼의 가치가 있는지, 그리고 어떤 것이 좀 더 기다렸다가 도입할 필요가 있는지 객관적으로 평가해야 한다. 새로운 기술은 언제나 리스크를 동반한다. 새로운 기획 툴이나 스토리지 솔루션들 중에 보유에 들어가는 총 비용은 줄여 주지만 결국 다른 회사에 인수되거나 대체되는 경우를 종종 봐 왔다”고 필딩은 말했다.
멀티 태스킹의 함정
직원들에게 시간을 관리하고 프로젝트를 우선순위화 할 수 있는 툴이 있으면 생산성이 올라 가는 것이 사실이라고 프레스트리지는 말했다. 그는 그러나 이와 함께 팀원들이 지속적으로 업무에 몰두할 수 있도록 하는 방법을 찾아야 한다고 조언했다.
“슬랙이나 마이크로소프트 팀즈 같은 콜라보레이션 소프트웨어의 장점은 업데이트를 통해 팀원들에게 최신 정보를 전달하고, 문제가 생길 경우 다른 팀원들에게 바로 도움을 청할 수 있다는 점이다. 물론 단점도 있다. 이런 협업 소프트웨어는 시시각각 작업을 방해하며, 복잡한 태스크에 집중하고 있을 때에도 깊은 생각에 빠질 수 없게 만든다. 특히 복잡한 문제를 해결하기 위해 집중하고 플로우를 만들어 나가야 하는 IT 프로그래머에게 이러한 방해는 치명적이다”라고 그는 설명했다.
프레스트리지는 이어 “이렇게 계속해서 방해 받는 환경에서는 얕은 일 처리 밖에 할 수 없다. 결국, 이런 툴을 사용할 때에는 내가 도움을 구하는 쪽일 때와, 도움을 주는 쪽일 때 두 가지 시나리오를 모두 상정하고 툴 사용을 익혀야 한다. 양보다 질이 중요한 작업, 집중도 있는 고민과 사고를 요하는 작업을 할 때는 멀티태스킹을 피해야 한다”라고 말했다.
dl-ciokorea@foundryco.com
