투이컨설팅 신창섭 이사
3. Two Speed IT 운영 방안
Two Speed IT가 효과적으로 운영되기 위해서는 적정 인원의 배치가 무엇보다 중요하다. 이미 안정성과 절차를 중시하는 인력들이 대부분인 IT부서라면, 내부에서 'Fast Speed IT'에 어울리는 인재를 고르기는 쉽지 않을 것이다. Fast Speed IT 조직은 구성원의 기술적, 문화적 성향 (새로운 것 선호, 위험과 불확실성 인내 등)을 고려 하여야 한다. 내부에 적정인력이 없다면 외부로부터의 영입이 필요하며 Fast Speed IT 영역은 소규모로 시작하여 점진적으로 확대하는 것이 바람직하다.
또 하나 고려할 것은 Fast Speed IT와 Slow Speed IT 모두가 중요하고, 신나게 일할 수 있는 곳으로 인식될 수 있도록 커뮤니케이션을 관리해야 한다. 자칫하면 Fast Speed IT가 부각되는 만큼 Slow Speed IT가 소외됨으로 인해 내부적인 반목과 견제가 발생할 수도 있다.
Fast Speed IT에 적합한 인재들의 배치가 완료되었다면 그 다음 갖추어야 할 것은 Fast Speed IT에 적합한 아키텍처 구조이다. Fast Speed IT가 중요하게 생각하는 개발 및 출시 속도를 맞추기 위해서는 기존의 시스템과의 얽힘을 최소화하면서도 이미 만들어진 모듈에 대한 재사용은 극대화해야 한다. 이 말은 상호 모순적인 것 같지만 우리는 이미 유사한 사례를 모바일 APP에서 많이 보아왔다. 서울버스나 네이버 부동산 등과 같이 OPEN API를 활용한 APP들이 바로 그것이다.
Two Speed IT의 아키텍처 바람직한 구조는 [그림 3]과 같이 Slow Speed IT에 해당하는 시스템의 연계 영역을 Open-API형태로 내부에 오픈하여 Fast Speed IT 시스템들로 하여금 사용할 수 있도록 만들어 두는 것이다.
[그림3: Slow Speed IT와 Fast Speed IT 공존 개념도]
이러한 구조를 위한 좋은 아키텍처 트렌드가 '마이크로 서비스'이다. 마이크로 서비스 아키텍처 스타일(Microservice architecture style)은 독립적으로 배포 가능한 서비스들의 묶음으로 소프트웨어 애플리케이션을 설계하는 방법이다. 서비스들은 각각이 프로세스이고, 서로 HTTP, JMX, JMS, AMQP, STOMP 및 REST API 등과 같은 가벼운 통신 메커니즘을 사용한다. 비즈니스를 구현하고, 완전히 자동화된 방법으로 독립적으로 배포될 수 있다. 서비스들을 위해 최소한의 중앙 관리(ex. API gateway)를 사용한다. 다른 프로그래밍 언어로 개발될 수 있고, 다른 데이터 저장 기술을 사용할 수도 있다.
과거의 SOA에 비해 마이크로 서비스 아키텍처가 더 설득력이 높아지고 확산되고 있는 이유는 과거 ESB보다 훨씬 경량화되고, 적은 책임을 지도록 한 'API Gateway'의 이용과 Docker와 같은 컨테이너 기술의 발전에 기인한다. 또한 클라우드 서비스의 확산으로 이를 이용하는 과정에서 마이크로서비스 아키텍처를 활용한 베스트 프랙티스가 많이 소개된 덕분이다.
'마이크로 서비스 아키텍처'를 기업에 도입하기 위해서는 소위 내공이 필요하다. 서비스 간의 연계성 및 다양한 기술 사용으로 인한 운영 및 테스트 복잡도가 증가하고 서비스의 세분화됨에 따라, 서비스 간의 코디네이션(Chief Architect)이 중요하다. 결정적으로 배포와 운영에 자동화를 사용하지 않으면, 오히려 기존 방식보다 더 어려워진다. (개별 서비스이기 때문에 수량이 많아짐)
하지만 이러한 어려움은 많은 마이크로 서비스들이 생겨난 이후의 문제를 이야기 하므로 이제 막 Two-Speed IT를 시작하는 기업이라면 소규모 Fast Speed IT를 위해 마이크로서비스 아키텍처를 도입하고, 위에서 언급한 내공을 키워나가는 것을 추천한다.
마지막으로 Two Speed IT의 운영관점에서 고민할 사항은 방법론이다.
Fast Speed IT 프로젝트들은 탐색적인 성격을 가지기 때문에 착수단계에서부터 성공을 정의하는 기능적 측면의 리스트가 부재한 경우가 많다. 따라서 초기에 요구사항을 확정하는 등 범위를 상수로 보고 일정과 자원을 변수로 관리하는 고전적인 프로젝트 방법론 보다는, 일정과 자원을 상수로 하고 범위를 변수로 관리하는 애자일 방법론이 효과적이다. 혁신적인 시스템은 본질적으로 실험적인 성격을 가진다. 애자일 방법론이 필요한 주된 이유는 무엇이 수행될 수 있는지에 관한 세부적인 계획이 수립되어 있지 않고, 새로운 측면의 아이디어를 적용하는 프로젝트를 효과적으로 다루는데 적합하기 때문이다.
이를 다시 Two Speed IT관점, 즉, Slow Speed IT와 Fast Speed IT를 모두 다루는 거버넌스 관점에서는 확장된 애자일 방법론(Scaled Agile)이 도움이 된다. 1세대 Agile방법론들이 작은 프로젝트에 사용하는 것에 초점이 맞춰져 있었다면 2세대 Agile 방법론들은 기업 전체에 적용하는 부분에 대해 진전이 있었다. 특히 프로젝트가 시작되기 전 단계인 포트폴리오 관리 영역을 효과적으로 다루는 부분에 대해 많은 발전이 있었다.
Two Speed IT 거버넌스에 애자일 방법론 (Scaled Agile Methodology)을 이용하여, 프로젝트 포트폴리오 관리는 Scaled Agile 방법론을 적용하고, Fast Speed IT 프로젝트 관리는 Agile 방법론을, Slow Speed IT 관리는 'Waterfall 방법론'주1)을 적용함으로써 전체 구조를 체계화 할 수 있다.
결언
Two Speed IT는 IT진화의 최종 모습은 아니다. 하지만, 엄청난 속도로 다가오는 디지털 혁신 트렌드에 발맞춰야 하는 기업의 입장에서, 또한 이를 뒷받침해야 하는 IT부서 입장에서 볼 때 기존 IT자산을 유지하면서 새로운 외부 환경의 변화에 빠르게 대응하기 위한 묘책으로 이보다 나은 대안은 아직까지 없어 보인다.
인터넷 은행의 출범으로 은행권은 물론이고 본격적인 투자은행으로의 변모를 시도하고 있는 증권업계에도 어떠한 식으로 파장이 미칠지 예측할 수 없는 상황이다. Two Speed IT는 이러한 변화에 빠르게 적응하고 새로운 혁신시도를 위해 IT부서가 취할 수 있는 적절한 전술이다.
가트너의 "CIO의 45%가 현재 신속한 운영 모드(Fast Mode of Operation)를 확보하고 있다고 밝혔으며, IT 조직의 75%가 2017년까지 어떤 식으로든 바이모달(Two Speed IT)을 도입할 것으로 보인다”는 말을 빌리지 않더라도 Two Speed IT는 IT부서에게 지금 눈에 보이는 것보다 훨씬 더 가까이 온 당면 과제이다.
주1) 기존의 내부적으로 성숙된 방법론을 Agile과 구별하기 위해 Waterfall 방법론이라 칭함
<끝>
