제조-인프라 산업의 생산공정 최적화, 운영업무 개선, 사업 시스템 개발 및 테스트 업무개선 및 사업위험 경감 방안으로서 서비스가상화 기술 활용사례
2014-02-27
제조/인프라산업의 서비스가상화 적용사례
제조-인프라 산업의 생산공정 최적화, 운영업무 개선, 사업 시스템 개발 및 테스트 업무개선 및 사업위험 경감 방안으로서 서비스가상화 기술 활용사례
2013-10-02
IT 트랜스포메이션 목표와 엔터프라이즈 데브옵스
최근 2-3 년간 사업 환경에는 큰 변화가 있었습니다. 스마트폰, 소셜 네트웍 서비스가 크게 유행 하고 있고, 커뮤니케이션과 정보 전달의 속도가 빨라지면서고객의 요구는 더욱 빠른 속도로 증가하고 시장의 변화는 점차 가속화되고 있습니다. 이에 따라서 과거보다 제품과 서비스의 상용화를 더욱 서두르는 추세고, 동시에 서비스 차별화를 요구 받고 있습니다. 글로벌에서는 구조조정과 부채비율 감축 노력이 계속 진행되고 있고, 새로운 금융정보와 개인정보 보호 관련 규제들과 IT 컴플라이언스가 점차 강화 되어가고 있습니다.
그러나 IT 조직은 이러한 사업 환경의 변화와는 다소 동떨어지게 전통적인 IT 부서 관행에 따라서 운영 되어 왔고, 사업과의 단절이 심화되서 실효성이 떨어진다는 지적을 받고 있습니다. 사업환경이 변화 함에 따라서 IT 도 발 맞춰 갈 것을 요구 받고 있는데, 바로 조직내에서 CIO/IT 의 위상이 변화되어 가는 것을 그 결과라고 할 수 있겠습니다.
과거에는 단순히 사업 지원 역할 정도를 바랬다면, 지금은 IT 기술에 대한 통찰력과 전략적인 리더쉽을 발휘하고 균형적으로 조율하는 역할을 바라고 있습니다. 즉, 모바일, 소셜 서비스와 같은 새로운 비즈니스 오퍼링을 내놓을 때에는 보다 혁신적이고 Risk Taking 에 과감한 벤쳐 투자자로서의 면모와 동시에 기 구축된 애플리케이션과 인프라 운영 통합을 추진하여 비용 절감에 주력해야하는 두개의 서로 상반된 역할을 기대 받고 있습니다. 동시에 IT 는 기본적으로 조직내에서 관계 관리자로서 LOB 전반에 협업을 이끌어 나가야 합니다.
이러한 현실 인식을 바탕으로 최근 글로벌 리서치들이 성공적인 IT 트랜스포메이션 전략을 제시한 바 있습니다. 즉, 사업성과에 지향하여 조직과 역할을 개편하는 것, LOB (Line of Business) 단위의 조직 모델에서 수평적 역할 모델로 확장해 가는 것 그리고 새로운 IT 직무를 통해서 사업에 더욱 밀착된 관계를 형성하는 것 등을 전략으로 제시하였습니다.
IT 트랜스포메이션의 궁극적인 목표는 신속한 IT 혁신을 통한 사업혁신 지원과 신속한 딜리버리를 통한 IT 비용의 절감입니다. 이러한 전략으로부터 트랜스포메이션 목표에 성공적으로 도달하기 위해서는 새로운 IT 서비스 딜리버리 체계의 도입이 필요합니다. 새로운 패러다임의 시대적 요구에 대응하는 IT 서비스 딜리버리 체계가 바로 엔터프라이즈 데브옵스 입니다
성공적인 IT 트랜스포메이션 목표 실현을 위한 실행 과제를 다음과 같이 정리할 수 있습니다.
<계속>
그러나 IT 조직은 이러한 사업 환경의 변화와는 다소 동떨어지게 전통적인 IT 부서 관행에 따라서 운영 되어 왔고, 사업과의 단절이 심화되서 실효성이 떨어진다는 지적을 받고 있습니다. 사업환경이 변화 함에 따라서 IT 도 발 맞춰 갈 것을 요구 받고 있는데, 바로 조직내에서 CIO/IT 의 위상이 변화되어 가는 것을 그 결과라고 할 수 있겠습니다.
과거에는 단순히 사업 지원 역할 정도를 바랬다면, 지금은 IT 기술에 대한 통찰력과 전략적인 리더쉽을 발휘하고 균형적으로 조율하는 역할을 바라고 있습니다. 즉, 모바일, 소셜 서비스와 같은 새로운 비즈니스 오퍼링을 내놓을 때에는 보다 혁신적이고 Risk Taking 에 과감한 벤쳐 투자자로서의 면모와 동시에 기 구축된 애플리케이션과 인프라 운영 통합을 추진하여 비용 절감에 주력해야하는 두개의 서로 상반된 역할을 기대 받고 있습니다. 동시에 IT 는 기본적으로 조직내에서 관계 관리자로서 LOB 전반에 협업을 이끌어 나가야 합니다.
이러한 현실 인식을 바탕으로 최근 글로벌 리서치들이 성공적인 IT 트랜스포메이션 전략을 제시한 바 있습니다. 즉, 사업성과에 지향하여 조직과 역할을 개편하는 것, LOB (Line of Business) 단위의 조직 모델에서 수평적 역할 모델로 확장해 가는 것 그리고 새로운 IT 직무를 통해서 사업에 더욱 밀착된 관계를 형성하는 것 등을 전략으로 제시하였습니다.
IT 트랜스포메이션의 궁극적인 목표는 신속한 IT 혁신을 통한 사업혁신 지원과 신속한 딜리버리를 통한 IT 비용의 절감입니다. 이러한 전략으로부터 트랜스포메이션 목표에 성공적으로 도달하기 위해서는 새로운 IT 서비스 딜리버리 체계의 도입이 필요합니다. 새로운 패러다임의 시대적 요구에 대응하는 IT 서비스 딜리버리 체계가 바로 엔터프라이즈 데브옵스 입니다
성공적인 IT 트랜스포메이션 목표 실현을 위한 실행 과제를 다음과 같이 정리할 수 있습니다.
- 성과 중심의 IT 트랜스포메이션을 위한 새로운 IT 서비스 딜리버리 체계 도입
- Application Delivery Lifecycle 관리 역량 수준 제고
- Application Delivery Lifecycle 최적화 및 Time-to-market 가속화
<계속>
2013-09-17
애플리케이션 Time-to-market 가속화의 도전과제
기업의 IT 환경은 복잡합니다.
예전과는 달리 어느 한두가지 표준과 아키텍쳐를 정의하여 모든 부분에 강제 할 수 없고, 아웃소싱 회사들이 권유하는 다양한 표준과 방법론, 아키텍쳐가 공존 합니다. 패키지 솔루션과 Business-in-a-Box, 서비스로서 완결된 사업 솔루션의 도입과 최근 유행하는 SaaS 기반 솔루션 도입으로 인해서 복잡성은 예측하기 어려운 수준으로 증가하고 있습니다. 표준화를 통해서 생산성을 제고하는 방안은 이제는 진부한 느낌이고 다양성을 IT 운영의 뉴노멀로 인식하여 관리와 품질 수준을 유지,개선 시켜나갈 방안을 모색해야 합니다.
사업혁신과 사업환경 변화에 발맞춰가려면 개발과 운영 조직간의 소통과 협업이 더욱 강조되어야 하지만 기존의 프로세스와 관행으로는 이 또한 쉽지 않습니다
기업의 IT 아키텍쳐는 다양해지고 복잡해지고 있습니다.
과거 메인프레임에서 Client-Server, 웹, 인트라넷에서 2000 년 이후 SOA, SaaS 와 같은 콤포짓 애플리케이션과 국내에서는 차세대 프레임워크의 도입, Web2.0 으로 발전해가고 있고
복잡성은 더욱 심화 되어 갑니다. 복잡도의 증가는 비용, 제약조건의 증가와 조직 측면에서 아웃소싱 비율의 증가, 공정 분리, 비즈니스 요구의 증가를 동반 하는 양상을 보입니다. 그럼에도 불구하고 레거시웹 출현이후로 소프트웨어 딜리버리 주기를 관리하는 역량과 이를 지원하는 관리도구에는 눈에 띄는 변화가 없었다는 점에 주목할 필요가 있습니다
기업에서 운영이관 또는 릴리즈 절차는 과거나 지금이나 여전히 수십명이 철야로 대기하는 작업이고 개발과 운영서버를 가급적 동일하게 맞춘다 해도 완전히 같지는 않아서 예측하기 어려운 오류와 로직의 결함이 발생되기도 합니다. 결함이 발생되면 루트 CAUSE 를 찾기 위해 다 같이 밤을 지새고, 이러한 모습은 10 년전이나 지금이나 크게 다르지 않습니다
아키텍쳐는 멀티티어 애플리케이션에서 분산-컴포짓 애플리케이션 (Composite Application) 으로 분화되어갑니다.컴포짓 애플리케이션이란 데이터 소스가 서로 다른
Ready-made 컴포넌트들을 조합하여 비즈니스 스위트를 구성하는 사례들이 이에 해당합니다. 불과 수년전만 해도 레이어드 아키텍쳐 도입에 따른 트랜잭션 관리, 워크로드 분산이 IT 이슈였다면 최근에는 내외부의 다양한 시스템들과의 연동, 매쉬업, OpeAPI, SaaS/PaaS 연동 등 IT 운영 주체로서는 완전히 통제-제어하기 어려운 엔티티들과의 통합 요구가 증가하고 있습니다 이에 따라서 개발생산성의 저하, 서비스 품질의 저하 위험이 증가되고 나아가서는 사업환경 변화에 동태적 대응 취약성 우려가 점차 커지고 있습니다.
최근 유행하는 애자일 방법론 도입으로 인해서 IT 운영은 더욱 어려워지고 있습니다.
기존의 CBD, IE, RUP, RAD 와 같은 워터폴 방식에 비해서 애자일 개발은 반복적, 점진적 개발-테스트가 수행된다는 점, 소규모 배포가 여러차례 반복된다는 점을 들 수 있습니다. 애자일 개발을 하다보면 프로젝트 중반 이후로는 이터레이션간의 통합테스트, 도메인 오브젝트 간의 통합테스트가 반복되고 소규모 배포가 반복적으로 진행되서 역동성과 다변성이 일정 내내 상존한다고 볼 수 있습니다. 최근의 IT 동향이 Lean & Agile 로 가고 있어서 많은 사업에서 애자일 도입을 검토하고 있지만 기존 방법론의 성숙도를 따라잡으려면 아직 상당한 시간이 필요할 것으로 예상됩니다
예를들어 계획 수립당시 이터레이션의 규모와 일의 양을 잘못 산정해서 또는 크리티컬 패스의 오류로 인해서 중요 이터레이션에 지연이 발생하면 이를 참조하는 모든 이터레이션의 순연이 불가피하게 되고 계획 수립 단계에서 버퍼를 고려하지 않았다면 프로젝트 종반에는 순연으로 인해 적체된 일의 볼륨이 기하 급수적으로 증가하게 되는 현상을 겪게 됩니다.
전반적인 일정지연과 관리 위험이 증가되고 이에 따라서 관리비용도 함께 늘어납니다. 결과적으로 적시 사업지원이 어렵게 되는 위험을 예상할 수 있습니다
개발 프로세스 중에는 그림에서 보시는 바와 같이 Idle Time 이 많습니다 (Gray Box)
옆자리 개발자 작업이 완료되어야 해서 기다리는 경우도 있고 때로는 연동하는 백엔드 시스템의 장애로 인한 문제도 있고 3RD 파티 솔루션의 설치가 늦어지는 경우, 외부 연계 서비스의 구매가 늦어지는 경우 등 이유는 다양합니다. Idle Time 최소화하고 실제 작업시간을 최대화 하는 것이 Time-to-market 을 가속화 하는 방안이 될텐데요, 여기에는 네가지 도전과제 (4C) 가 있습니다
1. 종속성 제약조건으로서 Constraints
2. 아키텍쳐 복잡성에 따른 문제 Complexity
3. 개발-운영간 소통과 협업의 단절로 인한 문제 Collaboration
4. 개발-운영중 지속적인 모니터링 방안 확보 문제 Complete Visibility
이상의 4C 는 사업으로 부터의 지속적인 피드백과 이에 대응하는 지속적인 딜리버리 체계를 수립하기 위한 선결요건 입니다
예전과는 달리 어느 한두가지 표준과 아키텍쳐를 정의하여 모든 부분에 강제 할 수 없고, 아웃소싱 회사들이 권유하는 다양한 표준과 방법론, 아키텍쳐가 공존 합니다. 패키지 솔루션과 Business-in-a-Box, 서비스로서 완결된 사업 솔루션의 도입과 최근 유행하는 SaaS 기반 솔루션 도입으로 인해서 복잡성은 예측하기 어려운 수준으로 증가하고 있습니다. 표준화를 통해서 생산성을 제고하는 방안은 이제는 진부한 느낌이고 다양성을 IT 운영의 뉴노멀로 인식하여 관리와 품질 수준을 유지,개선 시켜나갈 방안을 모색해야 합니다.
사업혁신과 사업환경 변화에 발맞춰가려면 개발과 운영 조직간의 소통과 협업이 더욱 강조되어야 하지만 기존의 프로세스와 관행으로는 이 또한 쉽지 않습니다
기업의 IT 아키텍쳐는 다양해지고 복잡해지고 있습니다.
과거 메인프레임에서 Client-Server, 웹, 인트라넷에서 2000 년 이후 SOA, SaaS 와 같은 콤포짓 애플리케이션과 국내에서는 차세대 프레임워크의 도입, Web2.0 으로 발전해가고 있고
복잡성은 더욱 심화 되어 갑니다. 복잡도의 증가는 비용, 제약조건의 증가와 조직 측면에서 아웃소싱 비율의 증가, 공정 분리, 비즈니스 요구의 증가를 동반 하는 양상을 보입니다. 그럼에도 불구하고 레거시웹 출현이후로 소프트웨어 딜리버리 주기를 관리하는 역량과 이를 지원하는 관리도구에는 눈에 띄는 변화가 없었다는 점에 주목할 필요가 있습니다
기업에서 운영이관 또는 릴리즈 절차는 과거나 지금이나 여전히 수십명이 철야로 대기하는 작업이고 개발과 운영서버를 가급적 동일하게 맞춘다 해도 완전히 같지는 않아서 예측하기 어려운 오류와 로직의 결함이 발생되기도 합니다. 결함이 발생되면 루트 CAUSE 를 찾기 위해 다 같이 밤을 지새고, 이러한 모습은 10 년전이나 지금이나 크게 다르지 않습니다
아키텍쳐는 멀티티어 애플리케이션에서 분산-컴포짓 애플리케이션 (Composite Application) 으로 분화되어갑니다.컴포짓 애플리케이션이란 데이터 소스가 서로 다른
Ready-made 컴포넌트들을 조합하여 비즈니스 스위트를 구성하는 사례들이 이에 해당합니다. 불과 수년전만 해도 레이어드 아키텍쳐 도입에 따른 트랜잭션 관리, 워크로드 분산이 IT 이슈였다면 최근에는 내외부의 다양한 시스템들과의 연동, 매쉬업, OpeAPI, SaaS/PaaS 연동 등 IT 운영 주체로서는 완전히 통제-제어하기 어려운 엔티티들과의 통합 요구가 증가하고 있습니다 이에 따라서 개발생산성의 저하, 서비스 품질의 저하 위험이 증가되고 나아가서는 사업환경 변화에 동태적 대응 취약성 우려가 점차 커지고 있습니다.
최근 유행하는 애자일 방법론 도입으로 인해서 IT 운영은 더욱 어려워지고 있습니다.
기존의 CBD, IE, RUP, RAD 와 같은 워터폴 방식에 비해서 애자일 개발은 반복적, 점진적 개발-테스트가 수행된다는 점, 소규모 배포가 여러차례 반복된다는 점을 들 수 있습니다. 애자일 개발을 하다보면 프로젝트 중반 이후로는 이터레이션간의 통합테스트, 도메인 오브젝트 간의 통합테스트가 반복되고 소규모 배포가 반복적으로 진행되서 역동성과 다변성이 일정 내내 상존한다고 볼 수 있습니다. 최근의 IT 동향이 Lean & Agile 로 가고 있어서 많은 사업에서 애자일 도입을 검토하고 있지만 기존 방법론의 성숙도를 따라잡으려면 아직 상당한 시간이 필요할 것으로 예상됩니다
예를들어 계획 수립당시 이터레이션의 규모와 일의 양을 잘못 산정해서 또는 크리티컬 패스의 오류로 인해서 중요 이터레이션에 지연이 발생하면 이를 참조하는 모든 이터레이션의 순연이 불가피하게 되고 계획 수립 단계에서 버퍼를 고려하지 않았다면 프로젝트 종반에는 순연으로 인해 적체된 일의 볼륨이 기하 급수적으로 증가하게 되는 현상을 겪게 됩니다.
전반적인 일정지연과 관리 위험이 증가되고 이에 따라서 관리비용도 함께 늘어납니다. 결과적으로 적시 사업지원이 어렵게 되는 위험을 예상할 수 있습니다
개발 프로세스 중에는 그림에서 보시는 바와 같이 Idle Time 이 많습니다 (Gray Box)
옆자리 개발자 작업이 완료되어야 해서 기다리는 경우도 있고 때로는 연동하는 백엔드 시스템의 장애로 인한 문제도 있고 3RD 파티 솔루션의 설치가 늦어지는 경우, 외부 연계 서비스의 구매가 늦어지는 경우 등 이유는 다양합니다. Idle Time 최소화하고 실제 작업시간을 최대화 하는 것이 Time-to-market 을 가속화 하는 방안이 될텐데요, 여기에는 네가지 도전과제 (4C) 가 있습니다
1. 종속성 제약조건으로서 Constraints
2. 아키텍쳐 복잡성에 따른 문제 Complexity
3. 개발-운영간 소통과 협업의 단절로 인한 문제 Collaboration
4. 개발-운영중 지속적인 모니터링 방안 확보 문제 Complete Visibility
이상의 4C 는 사업으로 부터의 지속적인 피드백과 이에 대응하는 지속적인 딜리버리 체계를 수립하기 위한 선결요건 입니다
데브옵스 (DevOps) 란
데브옵스란 본래 스타트업 벤쳐들의 일하는 방식으로서, Development, 개발과 Operations, 운영의 소통과 협업을 촉진시켜 혁신의 속도를 빠르게 하는 점을 전통적인 IT 조직에 적용하여 스타트업의 혁신을 재현하고자 하는데서 출발합니다.
2009-10 년 즈음에 스타트업과 오픈소스 커뮤니티를 중심으로 시작되어 2012 년을 기점으로 엔터프라이즈 IT 영역에 확산되기 시작했습니다. IT 의 혁신이 사업의 혁신 속도에 지대한 영향을 끼치는 최근의 트렌드를 반영한 ‘IT 의 일하는 방식’으로 정의 할 수 있습니다
고객 서비스 제공에 있어서 IT 의존도가 높은 기업들은 고객 수요 증가에 대응하는 서비스 개발을 더욱 효과적으로 개발-관리해야 한다는 압박을 끊임없이 받습니다. 실제로 모든 조직은 IT 비용 증가 없이 좀 더 빠르게 그리고 더욱 뛰어난 성능과 품질로 애플리케이션을 개발하기 원합니다. 그러나 운영 환경으로 변경사항을 전달을 위해서 작업 결과가 수주 또는 수개월 동안 개발과 운영간 조율되어야 하기 때문에 운영이관 또는 릴리즈라는 “거대한 벽”으로 격리되어 존재합니다.
또한 결함으로 인한 장애 또는 성능 저하, 비즈니스 로직상의 오류 발생시 운영 조직에서는 루트 Cause 를 제대로 파악하기가 어려울 수 있습니다. 이는 서비스 다운타임, 추가적인 인프라 구매, 개발 팀의 방대한 재작업을 초래합니다. 오랜기간, IT 의 당연한 관행이라고 생각해왔지만 느린 IT 라는 오명과 함께 고비용, 저품질의 위험이 상존하는 구조라고 볼 수 있습니다.
이에 반해 데브옵스는 개발 팀과 운영 팀 간의 협력적이고 생산적인 관계를 촉진합니다. 데브옵스란 간단히 말해서 애플리케이션 개발과 IT 운영 기능을 통합하고 보다 효율적으로 소프트웨어를 릴리스하여 사업에 적시 대응하고 나아서 비즈니스 성과를 지원하는 것입니다.
데브옵스가 제대로 기능하기 위해서는 특정 벤더 제품을 위한 시장이 아닌 하나의 동향으로 인식되어야 한다는 점에 반드시 유의해야 합니다. 데브옵스 환경에 배치되는 개발도구와 빌드도구, 이슈트랙커, 형상관리 도구 등은 국내 시장에서도 정착되어 일반화된지 오래이므로, 이들 간의 간극을 효과적으로 보완하여 보다 자동화된 방법으로, 유기적인 연계를 지원하도록 하여야 합니다. 그리하여 지속적인 피드백에 대응하여 지속적인 딜리버리가 가능하게되는 데브옵스 목표에 도달하게 하는 것입니다. 즉, 저비용, 고품질을 유지하면서도 사업요구에 적시대응하는 선순환 구조에 이르게 하는 것입니다
피드 구독하기:
글 (Atom)