.jpg)
신기술을 통해 회사를 혁신적으로 바꿔야 한다는 부담감이 모든 CIO들의 어깨를 짓누르고 있다. 하지만 이 혁신이라는 게 말처럼 쉽지 않다. 급진적인 변화가 성향에 맞지 않는 CIO들도 있다. 이처럼 혁신을 어렵게 하고, 성향에 어울리지 않는 것처럼 보이게 하는 것이 따로 있다.
[보안뉴스 문정후 기자] 수년 전 필자는 한 반도체 회사에서 제조와 IT 부문을 감독한 적이 있었다. 엔지니어링 부서는 새로운 제품의 프로토타입을 만들었고, 우리는 그것을 기준으로 제조 현장의 공간을 기획할 수 있었다. 첫 번째 프로토타입부터 착착 들어맞는 경우는 거의 없었고, 그래서 우리는 항상 공간을 이리 저리 자주 바꿔야만 했다. 그렇게 하고도 날아가는 프로젝트가 부지기수였다.
시행착오가 필요하다고는 하지만 이런 식으로 낭비되는 시간이 너무나 많았다. 그래서 어디서부터 잘못된 것인지 파악하기 위해 역으로 추적하기 시작했다. 최초로 제품이 기획되는 사무실의 칠판까지도 조사했다. 누군가를 추궁하려는 건 아니었다. R&D에서 실패는 늘 있는 일이고, 실패를 두려워해서는 아무 것도 이룰 수 없다는 것도 잘 이해하고 있었다. 어떤 실패는 막을 수 없다는 것도 충분히 알고 있었다. 다만 그 필요한 실패에도 정도가 있지 않을까 하는 것이 나의 의심이었고, 그 적정선이라는 것을 알아내고 싶었다.
조사를 하면서 여러 CIO들과도 ‘혁신’에 대해 이야기를 나눌 수 있었다. 안전한 기술과 투자를 선호하느냐, 아니면 색다른 것을 시도하는 걸 좋아하느냐,를 주로 물었고, 그에 대한 다양한 답을 들었다. 안전한 것을 선호하는 CIO들은 IT 시장에서 공인되다시피 하고, 널리 사용되어 충분한 검증을 받은 것들에만 예산을 쓰려는 경향을 보였다. 안정적인 결정을 내릴 수 있긴 하지만 단점이 없는 것은 아니었다.
예를 들어 기업이 경쟁력을 확보하기 위해 남들과 차별되는 뭔가를 만들어내고 싶어할 때, 안전한 성향의 CIO들은 힘을 잃는 경우가 많은 것처럼 보였다. 전자상거래나 사물인터넷, 원격 의료, 클라우드 등 화제가 되고 있는 기술을 제일 먼저 도입하려는 얼리어답터 성향의 CIO들은 리스크를 짊어지기도 하지만 그 위험천만한 초반 시기를 통해 후발주자들이 가지고 있지 않은 체험적 경험과 노하우를 이른 시간에 얻을 수 있다. 혁신이 필요할 때 이런 노하우는 실질적인 도움이 된다.
어느 쪽이 더 낫다고 말하는 게 아니다. 밝은 면이 있고, 그에 따른 어두운 면이 있다고 서술하는 것 뿐이다. 전자상거래를 먼저 시도했던 기업들이 초기에 어땠나 기억을 떠올려보라. 결제 과정이 너무 복잡하기도 했고, 물품 배달이 엉키기도 했다. 보안 사고가 일어나기도 했었다. 그러면서 사라지는 곳들도 있었지만 더 탄탄해지는 기업들도 많았다. 클라우드도 빠르게 도입해 오히려 손해를 보는 회사도 있고, 그 손해를 통해 노하우를 얻고 이제는 120% 클라우드를 활용할 줄 아는 기업들도 있다. 그냥 그런 차원에서의 말을 하는 것 뿐이다.
또 다른 사례도 있다. 대출 부서는 예나 지금이나 신청서들로 가득하다. 이를 하나하나 심사해 처리하는 과정은 지난하고 시간이 많이 걸리며, 여러 사람의 승인이 있어야 하기에 복잡했다. 그러다가 어떤 한 조직에서 대출 신청 승인을 자동화 기술로 처리하기 시작했다. 소프트웨어를 통해 승인 규정을 기계적으로 적용시키니 신청서를 보다 빠르게 처리하고 심사할 수 있게 됐다. 초반 금융 업계의 우려와 달리 대출을 자동으로 처리하는 기술은 매우 성공적이었고, 이제는 거의 모든 은행에서 이런 기능을 도입하고 있다. 고객들의 반응도 좋다. 안전한 노선만 밟는 사람이 CIO였을 때 얻어내기 힘든 결과라고 할 수 있다.
혁신의 동반자, ‘위험 관리’
혁신은 두 가지 얼굴을 가졌다. 성공하기만 하면 고객의 경험도 향상시키고 업무의 처리도 빨라지게 하며 심지어 새로운 시대를 가져올 수도 있다. 하지만 그 전에 시도만 하다가 망하고 소리소문 없이 사라지기도 한다. 그러니 다들 ‘누군가 리스크만 제어해준다면, 그래서 시도만 하다가 사라지는 일이 없을 수 있도록 돕는다면, 혁신을 선뜻 선택할 수 있을 것 같다’고 생각한다.
CIO들도 비슷한 생각이다. 안전하고 싶은 사람들이 겁쟁이어서 그런 게 아니라, 조직에 불필요한 위험을 가져다주기 싫어서 그런 것이다. 혁신을 하는 사람들이 대범해서 그럴 수 있는 게 아니라, 리스크를 어느 정도 제어할 수 있다는 자신감이 있어서 그런 것이다. 그러므로 시도하고 싶은 혁신이 있다면 그에 따른 리스크를 적극 관리할 방안을 찾아야 한다. 혁신과 리스크 관리는 동시에 일어나야 하는 일인 것이다.
그렇다면 먼저 IT 분야에서 추구할 수 있는 혁신의 범위를 구체적으로 좁혀 보자. 아마 다음과 같은 것들이 가장 보편적이지 않을까 한다.
1) 새로운 업무 프로세스의 정착 : 새로운 IT 기술을 활용해 업무 시간을 줄이고 효율을 높이면서 더 나은 성과를 마련하는 방법을 찾아낸다.
2) 애플리케이션 개발 : 현장에서 각 담당자마다 필요한 것들을 그때 그때 만들어 제공한다. 노코드 및 로우코드 개발 방법론을 도입하는 방안이 이 맥락에서 최근 논의되고 있다.
3) 사물인터넷 : 각종 데이터를 수집하기 위해 필요한 센서들을 적절한 곳에 설치해 운영하고, 수집된 데이터를 분석하여 사업적으로 도움이 되는 결정을 최대한 빨리 내릴 수 있도록 한다.
이 세 가지 범주 안에서의 혁신은 여기 저기서 시도되고 있지만 아직까지 이렇다 할 표준이나 방법론이 나오지는 않고 있다. 대표적인 사례 역시 아직은 없다고 보는 게 맞다. 이러한 혁신들에는 분명 리스크들이 동반될 것이 분명하다. 새로운 업무 프로세스를 도입하려다 옛 업무 프로세스보다 못한 결과를 낼 수도 있고, 노코드 도입하다가 생산성이 오히려 떨어질 수도 있다. 이를 예상하고 일을 진행하는 것이 혁신을 꾀하는 진정한 자세라 할 수 있다.
어떻게 해야 하는가?
그렇다면 실제 현장에서 우리는 혁신과 위기 관리를 어디서부터 어떻게 시작해야 할까? 먼저는 조직의 분위기를 다시 한 번 냉정하게 평가하는 것이 중요하다. 리스크에 대한 부담이 얼마 없는 조직이 있을 수 있고, 리스크 하나하나에 큰 의미를 부여하는 조직이 있을 수 있다. 그리고 그 중간 어딘가에도 수많은 기업들이 존재한다. 하지만 단 하나의 리스크도 용납할 수 없다는 식의 기업인이나 조직은 찾기 힘들다. 즉 어느 기업이나 앞으로 전진하겠다는 본능을 엷게라도 간직하고 있다는 것이다.
그 다음은 시도하려는 혁신에 동반되는 리스크가 무엇인지 정확히 파악해야 한다. 기업들마다 성향이 다르기도 하지만, 어떤 리스크를 감수해야 하느냐에 따라 기업의 반응이 달라지기도 한다. 100달러의 손해를 볼 수 있는 것과, 100만 달러의 손해를 볼 수 있는 것은 매우 다른 사안이다. 그러니 리스크라는 모호한 말을 구체적이고 명료하게 표현해 설명할 정도로 리스크의 정체를 알아내는 게 급선무다.
사실 위의 두 가지는 아무리 책상 앞에 앉아서 상상한다고 해도 정확히 알아내는 데에 한계가 있다. 뭐라도 실제로 시도해봤을 때 나오는 결과들을 보는 게 더 정확할 수 있다. 즉 실험의 차원에서, 파일럿 프로젝트의 개념으로, 작은 덩치의 혁신을 실제로 감행하는 게 필요할 수 있다는 뜻이다. 다만 이왕이면 성공 가능성이 높고, 장점을 많은 이들이 체감할 수 있을 만한 것으로 선정하는 게 도움이 된다. 그리고 다음 혁신의 주제를 놓고 경영진을 설득할 때 더 편해진다.
가장 중요할 수 있는 것 중 하나는 절대로 100% 성공을 장담하지 말아야 한다는 것이다. 어떤 프로젝트라도 실패라는 결과로 끝맺음 할 수 있다. IT 혁신은 아직 정답도 없고, 표준이 될만한 결과나 성공 사례가 드물기 때문에 아무 거나 시도해볼 수 있지만, 실패도 당연히 할 수 있다. 누군가를 설득하기 위해 성공의 경우만을 강조한다는 건 매우 위험하고 정직하지 못한 일이다. 예산을 쥐고 있는 중요한 인물을 설득하는 자리에서라도 실패할 수 있다는 걸 알리는 게 좋다.
글 : 메리 셰클릿(Mary E. Shacklett), 회장, Transworld Data
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 수년 전 필자는 한 반도체 회사에서 제조와 IT 부문을 감독한 적이 있었다. 엔지니어링 부서는 새로운 제품의 프로토타입을 만들었고, 우리는 그것을 기준으로 제조 현장의 공간을 기획할 수 있었다. 첫 번째 프로토타입부터 착착 들어맞는 경우는 거의 없었고, 그래서 우리는 항상 공간을 이리 저리 자주 바꿔야만 했다. 그렇게 하고도 날아가는 프로젝트가 부지기수였다.
[이미지 = utoimage]
시행착오가 필요하다고는 하지만 이런 식으로 낭비되는 시간이 너무나 많았다. 그래서 어디서부터 잘못된 것인지 파악하기 위해 역으로 추적하기 시작했다. 최초로 제품이 기획되는 사무실의 칠판까지도 조사했다. 누군가를 추궁하려는 건 아니었다. R&D에서 실패는 늘 있는 일이고, 실패를 두려워해서는 아무 것도 이룰 수 없다는 것도 잘 이해하고 있었다. 어떤 실패는 막을 수 없다는 것도 충분히 알고 있었다. 다만 그 필요한 실패에도 정도가 있지 않을까 하는 것이 나의 의심이었고, 그 적정선이라는 것을 알아내고 싶었다.
조사를 하면서 여러 CIO들과도 ‘혁신’에 대해 이야기를 나눌 수 있었다. 안전한 기술과 투자를 선호하느냐, 아니면 색다른 것을 시도하는 걸 좋아하느냐,를 주로 물었고, 그에 대한 다양한 답을 들었다. 안전한 것을 선호하는 CIO들은 IT 시장에서 공인되다시피 하고, 널리 사용되어 충분한 검증을 받은 것들에만 예산을 쓰려는 경향을 보였다. 안정적인 결정을 내릴 수 있긴 하지만 단점이 없는 것은 아니었다.
예를 들어 기업이 경쟁력을 확보하기 위해 남들과 차별되는 뭔가를 만들어내고 싶어할 때, 안전한 성향의 CIO들은 힘을 잃는 경우가 많은 것처럼 보였다. 전자상거래나 사물인터넷, 원격 의료, 클라우드 등 화제가 되고 있는 기술을 제일 먼저 도입하려는 얼리어답터 성향의 CIO들은 리스크를 짊어지기도 하지만 그 위험천만한 초반 시기를 통해 후발주자들이 가지고 있지 않은 체험적 경험과 노하우를 이른 시간에 얻을 수 있다. 혁신이 필요할 때 이런 노하우는 실질적인 도움이 된다.
어느 쪽이 더 낫다고 말하는 게 아니다. 밝은 면이 있고, 그에 따른 어두운 면이 있다고 서술하는 것 뿐이다. 전자상거래를 먼저 시도했던 기업들이 초기에 어땠나 기억을 떠올려보라. 결제 과정이 너무 복잡하기도 했고, 물품 배달이 엉키기도 했다. 보안 사고가 일어나기도 했었다. 그러면서 사라지는 곳들도 있었지만 더 탄탄해지는 기업들도 많았다. 클라우드도 빠르게 도입해 오히려 손해를 보는 회사도 있고, 그 손해를 통해 노하우를 얻고 이제는 120% 클라우드를 활용할 줄 아는 기업들도 있다. 그냥 그런 차원에서의 말을 하는 것 뿐이다.
또 다른 사례도 있다. 대출 부서는 예나 지금이나 신청서들로 가득하다. 이를 하나하나 심사해 처리하는 과정은 지난하고 시간이 많이 걸리며, 여러 사람의 승인이 있어야 하기에 복잡했다. 그러다가 어떤 한 조직에서 대출 신청 승인을 자동화 기술로 처리하기 시작했다. 소프트웨어를 통해 승인 규정을 기계적으로 적용시키니 신청서를 보다 빠르게 처리하고 심사할 수 있게 됐다. 초반 금융 업계의 우려와 달리 대출을 자동으로 처리하는 기술은 매우 성공적이었고, 이제는 거의 모든 은행에서 이런 기능을 도입하고 있다. 고객들의 반응도 좋다. 안전한 노선만 밟는 사람이 CIO였을 때 얻어내기 힘든 결과라고 할 수 있다.
혁신의 동반자, ‘위험 관리’
혁신은 두 가지 얼굴을 가졌다. 성공하기만 하면 고객의 경험도 향상시키고 업무의 처리도 빨라지게 하며 심지어 새로운 시대를 가져올 수도 있다. 하지만 그 전에 시도만 하다가 망하고 소리소문 없이 사라지기도 한다. 그러니 다들 ‘누군가 리스크만 제어해준다면, 그래서 시도만 하다가 사라지는 일이 없을 수 있도록 돕는다면, 혁신을 선뜻 선택할 수 있을 것 같다’고 생각한다.
CIO들도 비슷한 생각이다. 안전하고 싶은 사람들이 겁쟁이어서 그런 게 아니라, 조직에 불필요한 위험을 가져다주기 싫어서 그런 것이다. 혁신을 하는 사람들이 대범해서 그럴 수 있는 게 아니라, 리스크를 어느 정도 제어할 수 있다는 자신감이 있어서 그런 것이다. 그러므로 시도하고 싶은 혁신이 있다면 그에 따른 리스크를 적극 관리할 방안을 찾아야 한다. 혁신과 리스크 관리는 동시에 일어나야 하는 일인 것이다.
그렇다면 먼저 IT 분야에서 추구할 수 있는 혁신의 범위를 구체적으로 좁혀 보자. 아마 다음과 같은 것들이 가장 보편적이지 않을까 한다.
1) 새로운 업무 프로세스의 정착 : 새로운 IT 기술을 활용해 업무 시간을 줄이고 효율을 높이면서 더 나은 성과를 마련하는 방법을 찾아낸다.
2) 애플리케이션 개발 : 현장에서 각 담당자마다 필요한 것들을 그때 그때 만들어 제공한다. 노코드 및 로우코드 개발 방법론을 도입하는 방안이 이 맥락에서 최근 논의되고 있다.
3) 사물인터넷 : 각종 데이터를 수집하기 위해 필요한 센서들을 적절한 곳에 설치해 운영하고, 수집된 데이터를 분석하여 사업적으로 도움이 되는 결정을 최대한 빨리 내릴 수 있도록 한다.
이 세 가지 범주 안에서의 혁신은 여기 저기서 시도되고 있지만 아직까지 이렇다 할 표준이나 방법론이 나오지는 않고 있다. 대표적인 사례 역시 아직은 없다고 보는 게 맞다. 이러한 혁신들에는 분명 리스크들이 동반될 것이 분명하다. 새로운 업무 프로세스를 도입하려다 옛 업무 프로세스보다 못한 결과를 낼 수도 있고, 노코드 도입하다가 생산성이 오히려 떨어질 수도 있다. 이를 예상하고 일을 진행하는 것이 혁신을 꾀하는 진정한 자세라 할 수 있다.
어떻게 해야 하는가?
그렇다면 실제 현장에서 우리는 혁신과 위기 관리를 어디서부터 어떻게 시작해야 할까? 먼저는 조직의 분위기를 다시 한 번 냉정하게 평가하는 것이 중요하다. 리스크에 대한 부담이 얼마 없는 조직이 있을 수 있고, 리스크 하나하나에 큰 의미를 부여하는 조직이 있을 수 있다. 그리고 그 중간 어딘가에도 수많은 기업들이 존재한다. 하지만 단 하나의 리스크도 용납할 수 없다는 식의 기업인이나 조직은 찾기 힘들다. 즉 어느 기업이나 앞으로 전진하겠다는 본능을 엷게라도 간직하고 있다는 것이다.
그 다음은 시도하려는 혁신에 동반되는 리스크가 무엇인지 정확히 파악해야 한다. 기업들마다 성향이 다르기도 하지만, 어떤 리스크를 감수해야 하느냐에 따라 기업의 반응이 달라지기도 한다. 100달러의 손해를 볼 수 있는 것과, 100만 달러의 손해를 볼 수 있는 것은 매우 다른 사안이다. 그러니 리스크라는 모호한 말을 구체적이고 명료하게 표현해 설명할 정도로 리스크의 정체를 알아내는 게 급선무다.
사실 위의 두 가지는 아무리 책상 앞에 앉아서 상상한다고 해도 정확히 알아내는 데에 한계가 있다. 뭐라도 실제로 시도해봤을 때 나오는 결과들을 보는 게 더 정확할 수 있다. 즉 실험의 차원에서, 파일럿 프로젝트의 개념으로, 작은 덩치의 혁신을 실제로 감행하는 게 필요할 수 있다는 뜻이다. 다만 이왕이면 성공 가능성이 높고, 장점을 많은 이들이 체감할 수 있을 만한 것으로 선정하는 게 도움이 된다. 그리고 다음 혁신의 주제를 놓고 경영진을 설득할 때 더 편해진다.
가장 중요할 수 있는 것 중 하나는 절대로 100% 성공을 장담하지 말아야 한다는 것이다. 어떤 프로젝트라도 실패라는 결과로 끝맺음 할 수 있다. IT 혁신은 아직 정답도 없고, 표준이 될만한 결과나 성공 사례가 드물기 때문에 아무 거나 시도해볼 수 있지만, 실패도 당연히 할 수 있다. 누군가를 설득하기 위해 성공의 경우만을 강조한다는 건 매우 위험하고 정직하지 못한 일이다. 예산을 쥐고 있는 중요한 인물을 설득하는 자리에서라도 실패할 수 있다는 걸 알리는 게 좋다.
글 : 메리 셰클릿(Mary E. Shacklett), 회장, Transworld Data
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
