기고 | 비용과 혁신의 역설, 해결법은?

다국적 금융 서비스 기업 NYSE 유로넥스트(NYSE Euronext)의 미국 운영 사업부 CIO 폴 카셀의 사례와 조언

다른 CIO들과 대화를 나눌 기회가 있을 때면 필자는 “2년 전을 기점으로 시작되었다고 이야기되는, 이른바 ‘테크놀로지 르네상스(technology renaissance)’가 업무를 더 편하게 했습니까, 아니면 더 어렵게 만들었습니까?”라는 질문을 던지곤 한다.

이 질문에 대답을 주저하는 CIO는 없었다. 그들의 대답은 한결같이 ‘힘들어졌다’였다.

기술이 기업의 수익 창출에 직접적으로 영향을 미치게 됨에 따라 오늘날 혁신에 대한 기대는 그 어느 때보다 커지고 있다. 경영진과 사용자들은 매일 새로움을 요구하고 있다.

하지만 여기에는 한 가지 중요한 문제가 있다. 경기가 아직 침체기를 벗어나지 못하고 있고, 그로 인해 비용 지출에 한계가 있다는 점이다.

물론 혁신과 비용 문제 사이의 패러독스는 어느 때나 있어온 것이지만, 오늘날만큼 그 고민이 컸던 시기는 없었을 것이다. 이러한 모순은 IT를 더욱 예민하게 만들고 있고, 이를 관리해야 할 CIO의 역할은 더욱 어려워지고 있다.

지금 이 순간에도 많은 이들이 이 패러독스 속에서 고뇌하고 있을지 모른다. 어떤 이는 문제를 여러 조각으로 분해해 해결해보려 시도하다 그 규모에 압도당해 주저앉아있을 수도 있다.

CIO로써 당신은, 비용 억제의 책임자인 동시에 혁신을 이끌어야 하는 역할을 부여 받고 있다. 그 말인 즉, ‘절대 안돼!’라는 말과 ‘좋아, 한 번 해보지’라는 말을 동시에 할 수 있는 인물이어야 한다는 것이다. 필요한 것은 상황의 전, 후, 좌, 우, 그리고 내, 외부를 동시에 바라볼 수 있는 눈이다.

마지막으로 실패하거나 지출 상한을 넘긴 프로젝트에 추가 예산을 지원 받은 것이 언제인가? 마지막으로 돈 걱정 없이 혁신에만 집중해본 것은 언제인가? 한 제약 업체의 CIO 모리지오 로디자는 “창의력에 얼마가 들어갈지를 예측하는 것은 복잡하며 오류가 많을 수밖에 없는 과정이다. 두 마리 토끼를 잡으려다간 한 마리도 잡을 수 없다는 사실을 기억하라”라고 상황을 비유했다.

비용 대 혁신의 패러독스는 산업 부문과 기업 규모, 예산 규모에 관계 없이 CIO들을 괴롭히는 문제이다. 때문에 필자는 본 블로그를 통해 이 패러독스 해결을 위한 선진적 CIO들의 기술적 조언을 종종 소개하고자 한다.

금주의 인물은 뉴욕 증권거래소를 비롯한 여러 증권 거래소를 운영하는 미국, 유럽의 다국적 금융 서비스 기업 NYSE 유로넥스트(NYSE Euronext)의 미국 운영 사업부 CIO 폴 카셀이다. 먼저 카셀의 말을 들어보자.

“난 NYSE 유로넥스트가 신생 기업이던, 그러니까 기업이 아키페라고 홀딩스(Archipelago Holdings)와 합병하던 시절 이 곳에 입사했다. 이 곳에 오기 전까지는 이토록 많은 레거시 시스템(legacy system)을 지원해본 적이 없었다. 이 낡은 환경과 비즈니스의 비용 절감 필요성은 내게 기술적, 재정적 어려움뿐 아니라 정치적 어려움까지 안겨주었다. 우리의 일부 거래소에는 10년 전의 시스템이 아직 남아있는 경우도 있었고, 반대로 레거시 시스템이 전혀 없는 거래소도 있었다.”

“이런 모습에서 볼 수 있듯 내가 지원해야 할 내부 고객들은 혁신을 기꺼이 받아들이는 쪽과 이를 외면하는 쪽으로 나뉘어 있었다. 이러한 비즈니스 커뮤니티 내부의 불협화음은 당신의 기업에서도 발생할 수 있다. 만일 당신이 특정 비즈니스 라인에 무언가를 새로이 지원했다면, 일각에서는 ‘저들에겐 새로운 상품이 제공됐는데 우리는 새로운 기능 하나도 지원 받지 못했어’라고 말할 수 있는 것이다.”

그렇다면, CIO는 어떻게 주어진 운영 예산을 잘 활용해 모두가 만족할만한 혁신을 전달할 수 있을까? 핵심은 커뮤니케이션과 관계에 있다. 당연한 말이다. 물론 이것만으론 충분치 않다. 카셀은 다음과 같이 설명했다.

“우리는 비즈니스 문제를 이해하는 이들, 그리고 ‘관’이 필요하다는 요청에 타지마할을 건설할 필요는 없음을 이해하는' 이들이 한데 모인 절충적 그룹을 구성했다. 이 그룹에는 C++ 코더들과 자바 개발자, 데이터베이스 관리자(DBA), 이전의 QA 테스터(QA tester), 그리고 마켓 데이터 애널리틱스 전문가들이 참여했다. 그들의 역할은 기름을 들이붓지 않고도 혁신의 불길을 꺼뜨리지 않을 방법을 연구하는 것이었다.”

카셀은 지난 5년 간 그의 소프트웨어 자동화 그룹이 6,000만 달러의 운용 비용을 절감하는 성과를 올렸다고 평가했다. 카셀의 팀이 큰 성공을 거둔 프로젝트 중 하나로는 2006년 완료된 매니지먼트 자동화 툴 배포를 꼽을 수 있다. 이를 통해 그들은 IT 전달 속도를 큰 폭으로 향상 시킬 수 있었다.

카셀은 “우리는 지금까지 개발 팀과 프로젝트 관리 조직(PMO), 품질 보증(QA) 팀, 운영 조직 그리고 생산 조직 사이에서 굼뜨게 수동으로 이뤄지던 전달 프로세스를 자동화시켰다. 우리는 우리의 코드 데이터베이스(code database)를 결점 추적 데이터베이스와 QA 요구 데이터베이스와 연결시켰다”라고 말했다.

카셀은 이 과정이 계획과 소통에만 수백 시간이 소요된 작업이었다고 말했다. 그는 “이제, 개발자들은 자신의 원래 영역으로 돌아가 구축 작업을 진행하고 있다. 그들의 개발물은 자체 테스트를 거친 뒤 우리의 중간 준비 지역으로 보내진다. 이곳에 모여진 개발물들은 QA 단계로 넘어가고, 그들의 테스트를 한 번 더 거친 뒤 운영 그룹에게 전달된다. 최종 지시를 내리는 것은 운영 그룹으로, 이들의 승인이 내려지면 소프트웨어는 모든 주 서버와 백업 서버에 설치되게 된다”라고 설명했다.

소프트웨어 자동화 그룹 가동을 위한 카셀의 조언?
고민은 다시 정치적 문제로 넘어간다. 카셀은 다음과 같이 말했다.

“기업의 주요 비즈니스 라인들로부터 전문가를 보아 통합 그룹을 구성하는 것은 직접적으로 비즈니스를 위해 일하는 IT 관계자들의 반발을 살 수도 있는 일이다. 서로 다른 비즈니스들이 각자 대립되는 테크놀로지를 이용하는 상황이라면, 이 테크놀로지들을 지원하는 IT 전문가의 입장에선 자신들의 것을 보호하길 원하기 때문이다.”

“최악의 시나리오는 IT 간의 싸움이 각자의 비즈니스 라인 간의 오해로 번져 비즈니스 리더들이 통합 그룹을 자신들의 비즈니스에 손해를 줄 수 있는 좋지 않은 아이디어로 인식하게 되는 것이다”라고 말했다.

카셀은 이러한 위험의 가능성을 해소할 가장 좋은 방법은 소프트웨어 자동화 그룹의 콘셉트를 비즈니스 리더들에게 우선적으로 소개한 뒤 IT 에 도입하는 것이라고 조언했다.

그는 “먼저 당신의 할 일을 끝낸 뒤 비즈니스에 어떻게 새로운 그룹이 그들에게 새로운 테크놀로지를 더욱 빨리 전달해줄 수 있는지를 보여줘라. 그들의 지원이 있다면 IT에의 도입 역시 어려움 없이 진행될 수 있을 것이다. 이는 모두를 만족 시킬 수 있는 방법이라 할 수 있다”라고 말했다.

소프트웨어 자동화 그룹 구성을 통해 카셀은 비용 대 혁신 패러독스의 해결 방안을 발견할 수 있었다. 이를 통해 그는 IT 운영 비용을 절감하면서도 혁신적 테크놀로지를 보다 빠르게 전달할 수 있게 된 것이다.

* Martha Heller는 CIO 전문 리크루팅 기업 헬러 서치 어쏘시에이츠의 대표다. ciokr@idg.co.kr