2020.12.07

‘변화했을 뿐 여전히 유효한 이야기’··· 고전 IT 원칙 11가지

Bob Lewis | CIO
기술은 빠르게 변화하고 있다. 하지만 그 유행 아래에는 여전히 원초적이고 근본적인 IT 원칙이 남아있다. 오래됐지만 그럼에도 현대화해 적용할 수 있는 IT 원칙들을 소개한다. 

 

“많은 것이 같을수록, 더욱더 많은 것이 변한다(The more things stay the same, the more they change).”


원래 격언과 앞뒤가 바뀌긴 했지만 이는 ‘IT’라면 새겨들어야 할 대목이다. 이를테면 IT가 전자정보처리(EDP)였고, 프로그래머가 데이터센터를 지키는 문지기에 불과했던 초기 시절로부터 변한 것은 그리 많지 않다. 하지만 그러면서도 모든 것이 변했다. 

다행스럽게도, IT의 초창기 시절에 나온 기본적인 원칙은 여전히 유효하다. 다만 현대화됐을 뿐이다. 여기서는 차세대 IT를 구현하는 데 있어 길잡이가 될 11가지 고전적인 원칙과 이들이 변한 부분들을 살펴본다. 
 
ⓒGetty Images

1. 기술이 얼마나 좋은지는 결코 중요하지 않다 
- 낡은 원칙: “IBM을 사서 해고당한 사람은 없었다.”
- 새로운 변화: 오픈소스가 똑같은 이점을 제공할 수 있다  


기업 입장에서 기술 구매는 장기적인 차원의 투자다. 따라서 이에 부합해 공급업체도 장기적인 지원을 약속해주길 바란다. 이러한 맥락에서 IT는 안전을 위해 ‘대형 업체’에서 기술을 구매하곤 했다. 지금은 어떠한가? 오픈소스가 그만큼이나 안전할 뿐만 아니라, 심지어는 IBM이나 다른 대형 업체에서 오픈소스를 얻을 수도 있다. 

물론 모든 오픈소스가 충분한 지원 기반을 갖추고 있는 것은 아니다. 예를 들면 만약 PHP(Hypertext Preprocessor)로 필요한 기능을 모두 제공하는데, 보안 취약점이 많은 자바를 거들떠보겠는가? 물론 자바는 세계 최대의 소프트웨어 기업 가운데 하나인 오라클이 지원한다(아마도 ‘제공한다’라는 말이 더 정확한 듯하다). 

2. 강력한 정보 보안은 강력한 물리적 보안에서 시작된다 
- 낡은 원칙: 하드웨어를 안전한 공간에 보관하라
- 새로운 변화: 안전한 공간을 자체적으로 확보할 필요는 없다  


하드웨어는 언제나 안전한 공간에서 관리됐다. 이를테면 소수의 직원만 데이터센터에 접근할 수 있었고, 출입자와 출입 시간은 자동으로 기록됐다. 하지만 현재는? 이 안전한 공간을 모두 자체적으로 운영하지 않는다. 특히 중소기업이라면 코로케이션 설비, 풀 클라우드 등의 여러 대안이 있다. 

그러나 자체적으로 데이터센터를 구축하지 않는다고 해서 이 모든 비용을 아낄 수 있다고 생각해선 안 된다. 그중 일부를 외부 공급업체를 연결하는 저지연 및 고대역폭 네트워크에 투자해야 하기 때문이다. 

여기에 또 다른 오래된 원칙을 적용한다면 더 좋다. 즉 계란을 한 바구니에 담지 말라는 것이다. 네트워크 연결을 이중으로 유지한다. 그래야 물리적 재난이 발생해도 비즈니스를 중단하지 않을 수 있다. 

3. 위협을 파악하라 
- 낡은 원칙: 보안 위협 목록을 작성하고 대책을 수립하라
- 중간 단계: 데스크톱을 봉쇄하고 경계를 보호하라 
- 새로운 변화: 자산을 강화하고 경계를 보호하라 


과거에는 고객정보관리시스템(CICS) 세션을 차단시켜 해커가 접속하지 못하도록 해 보안 위협을 막았다. 그 이후 PC, 분산 시스템, 인터넷이 등장했고 위협도 더 많아졌다. 이에 따라 사람들은 데스크톱을 봉쇄하고 더 정교한 방화벽으로 경계를 지키며 대응하기 시작했다. 

아직도 모든 부분을 걸어 잠그고 자유를 허용하지 않는 것이 최선이라고 생각하는 경우가 많다. 그러나 기업들은 끊임없이 변화하고 혁신해야 생존할 수 있다. 그리고 혁신은 신제품 그 이상의 것을 의미한다. 다시 말해, 이는 창의적인 생각, 그리고 기업 내 모든 곳에서 이를 가능하게 하는 것들을 말한다. 

가장 큰 위협은 혁신할 수 없는 인력이다. 따라서 오늘날 기업들은 경계보다는 자산을 강화하고, 사용자를 더 적극적으로 지원하는 데 더 많은 시간을 투자해야 한다. 

4. 소프트웨어 테스트는 코드를 프로덕션 환경에 투입하고 결과를 보는 것이 아니다 
- 낡은 원칙: 개발, 테스트, 프로덕션이라는 3가지 환경을 유지하라
- 새로운 변화: 테스트를 클라우드로 이전하라 


회귀와 스트레스 테스트는 프로와 아마추어를 구분하는 척도다. 이는 과거에도 그랬고, 지금도 그러하다. 회귀 테스트는 새로운 변경사항이 기존 기능에 영향을 미치지 않는지를 확인한다. 스트레스 테스트는 비합리적인 부하를 가할 때 모든 부분이 적절한 방식으로 동작하는지 확인한다. 

이를 위해 IT는 개발, 테스트, 프로덕션이라는 3가지 환경을 유지했다. 이는 이들을 모두 구매하고 더불어 유지관리한다는 의미였다. 

이제 자체 데이터센터를 운영하더라도 클라우드에서 테스트 환경을 가동하는 게 더 합리적이다. 필요한 만큼만 사용하고 비용을 지불하면 되기 때문이다. 프로덕션 환경에 따라 다를 수도 있지만, 이는 회귀 테스트도 거뜬히 수행할 수 있다. 단 스트레스 테스트는 변수가 너무 많기 때문에 적어도 당분간은 기다려야 한다. 

5. 프로덕션 환경에 따른 변경 관리 
- 낡은 원칙: 공식적인 변경 관리 프로세스
- 새로운 변화: 공식적인 변경 관리 프로세스 


개발자가 프로덕션 환경에 새 코드를 그냥 던져 넣던 시절은 지났다. 여기에는 거쳐야 할 프로세스가 있다. 사실 이 프로세스를 좋아하는 사람은 아무도 없지만, 이는 좋고 싫음의 문제가 아니다. 이는 변경으로 인해 생산이 중단되지 않는지 확인하고, 만약 중단되는 경우 복원 계획을 준비하도록 하는 것이기 때문이다. 

여기서 클라우드는 변경 관리를 더 어렵게 한다. 클라우드 업체를 관리하는 데 유의하지 않는다면, 이들은 기업의 프로세스를 거치지 않고 운영 환경에 변경 사항을 적용할 수 있기 때문이다. 결국, 이는 클라우드 업체의 인프라다. 

6. 워터폴 모델이 효과적이어야 하지만 실제로는 애자일이 효과적이다 
- 낡은 원칙: 현업 관리자와 프로그래머 사이의 비공식적인 밀고 당기기 
- 새로운 변화: 현업 관리자와 프로그래머 사이의 비공식적인 밀고 당기기나 준수해야 할 규칙이 있는 스크럼 


공식적인 개발 방법론이 등장하기 전에, 현업 관리자는 여기저기 돌아다니며 ‘컴퓨터가 이렇게 하도록 할 수 있을까?’라고 묻곤 했다. 프로그래머는 뭔가를 시도해 현업 부문 사용자에게 보여주고, 제대로 될 때까지 이를 반복했다. 

이들은 당시 이 방법을 ‘애자일’이라고 부르지 않았다. ‘컴퓨터가 해야 할 일에 관해 대화를 나누는 것’이라고 불렀다. 하지만 이게 바로 애자일이다. 

그런 다음, 워터폴 모델이 출현했다. 워터폴 모델도 효과적이긴 하다. 다만 현업 관리자가 시스템을 완벽하게 구상하고 정확하게 설명할 수 있어야 했다. 하지만 이는 불가능했고, 꽤 긴 시간 동안 생산성을 낭비했다. 

그러다 반복과 상호작용에 기반을 둔 '스크럼'이 등장했고, 지금과는 다른 형태의 애자일 기법들이 추가됐다.

7. 관계는 프로세스에 우선하고, 관계는 거래보다 오래 지속된다 
- 낡은 원칙: 다른 최고 경영진과의 관계 관리는 CIO의 핵심 업무다
- 새로운 변화: 현업과의 관계 관리는 모든 사람의 핵심 업무다 


기업은 관계의 집합이다. 관계가 원활하면 모든 것이 잘 돌아간다. 그렇지 않다면 잘 돌아가지 않을 것이다. 기업이 엄격한 계층 구조였을 때, CIO는 다른 최고 경영진과의 관계를 관리했고 그 정도면 충분했다. 다른 최고 경영진이 CIO를 신뢰하지 않으면 IT는 성공할 수 없었다. 그렇게 단순했다.  

이제는 IT 부서 구성원이 현업 부문 구성원과 상호작용할 때마다 이는 IT와 현업 사이의 관계에 영향을 준다. 이는 단순히 CIO와 다른 경영진과의 관계가 아니다. 현업 부문이 IT를 신뢰하지 않으면 IT는 성공할 수 없다. IT를 신뢰한다면 IT는 한결 더 수월해질 것이다. 

8. 통합하라. ‘자동화 섬’을 연결하면 비효율적 비즈니스 프로세스를 크게 줄일 수 있다
- 낡은 원칙: 맞춤 프로그래밍된 배치 인터페이스의 점진적 축적
- 새로운 변화: 실시간 인터페이스가 있는 서비스 버스 
- 최신 변화: 비-IT 기반 SaaS 솔루션과의 통합 


사람 직원이 컴퓨터로 생성된 보고서 정보를 데이터 입력 화면에 다시 입력하던 시절, IT는 개별 시스템을 통합해 데이터 동기화를 유지하는 게 중요하단 것을 깨달았다. 그래서 IT는 인터페이스를 구축했다. 이들 중 대다수는 맞춤형으로 만든 배치 ETL(추출-변환-로드)이었다. 

현재는 이런 인터페이스가 너무 많아 유지하기 힘든 상황이다. 그래서 현명한 IT는 서비스 버스(service bus) 또는 이와 유사한 기술에 투자하고, 인터페이스도 만들고 있다. 단순히 기술을 적층하는 것은 기존과 같은 관리의 어려움으로 이어질 것이기 때문이다. 

오늘날 IT의 많은 부분이 IT 부서 밖에서 일어난다. 대부분 현업 관리자에 의해 SaaS 형태로 유입되며, 일부만 자동화돼 오히려 고립되는 ‘자동화 섬(islands of automation)’이 만들어진다. 이들은 결국 데이터를 재입력하는 데 지칠 가능성이 높다. 이에 대비해야 한다. 

9. IT는 현업을 지원하는 존재다 
- 너무 오래되다 못해 진부한 원칙: 기술을 위한 기술은 무의미하다
- 새로운 변화: 기술 리더십을 제공하라 


기술을 위한 기술은 좋지 않다. 그렇다고 IT가 업무 지시를 처리하는 것으로 역할을 제한해야 한다는 의미는 아니다. 이를 훨씬 뛰어넘어 기술 리더십을 제공해야 한다. IT 부서가 기술 리더십을 제공하지 못한다면, 즉 '제안과 토론' 대신 '수용과 전달'만 한다면 근본적 수준에서 실패할 수밖에 없다.

또한 기술 리더십은 스스로 기술을 구매하거나 개발하려는 현업 관리자와 사용자를 지원하는 것을 포함한다. 이제 ‘섀도우 IT’가 좋은 것임을 인정할 때가 됐다. IT의 범위를 넓히기 때문이다. 

물론 위험이 있지만, 가치 있는 일은 위험이 따르기 마련이다. IT는 현업 부문이 자신들의 기술로 성공할 수 있도록 지원해야 하고, 이때 외부 기술을 배척해선 안 된다. 

10. 프로젝트는 계획을 필요로 한다 
- 낡은 원칙: 워터폴 모델은 분명한 단계, 시한, 이정표를 의미한다
- 새로운 변화: 애자일에서조차 프로젝트는 마감시한과 이정표를 필요로 한다 


워터폴 프로젝트는 체계적인 계획을 세워서 실패하는 게 아니다. 현실 세계의 프로젝트는 언제나 지속적인 학습이 이뤄지는 연습이지 높은 수준의 요구사항에서 상세한 계획으로의 체계적인 진전이 아니기 때문에 실패한다. 

애자일은 ‘지속적 학습’이라는 현실을 수용한다. 그렇다고 해서 비즈니스 리더가 범위, 인력, 예산에 관한 추정치를 제공하지 않는 프로젝트 제안을 승인한다는 것은 아니다. 

따라서 지속적 학습은 계획이 고정될 수도 없고, 고정되어서도 안 된다는 것이란 점을 이해해야 한다. 즉 상황에 따라 계획도 변화하거나 변화해야 한다는 의미다. 이는 성공적인 워터폴 프로젝트에서도 일어난다. 다만 극적이지 않을 뿐이다. 

11. 결국 비즈니스 변화가 중요하다 
- 낡은 원칙: IT는 비즈니스 전반에 걸쳐 변화를 견인하는 원동력이다. 
- 중간 단계: IT는 비즈니스 변화의 가장 큰 걸림돌이다. 
- 새로운 변화: IT는 비즈니스 전반에 걸쳐 변화를 견인하는 원동력이다. 


컴퓨터가 새롭고 반짝였던 시절, 현업 부문 경영진은 컴퓨터가 수작업에 의한 오류를 크게 줄이는 동시에 비즈니스 프로세스를 더 빠르고 저렴하게 해 모든 곳에서 변화를 주도할 것이라 기대했다. 

이러한 기대는 IT가 수많은 상호 연결된 시스템을 지원하기 전까지 유효했다. 새로운 일을 하려면 시간과 비용이 많이 들었고 위험하기까지 했다. 워터폴 방법론도 도움이 되지 않았다. 

마침내 IT는 다시 느슨하게 흩어지고 있다. 애자일, 훨씬 더 개선된 통합 도구, 비-IT 지원 등에 힘입어, IT는 변화를 뒤쫓는 게 아니라 다시금 변화를 주도하기 시작했다. ciokr@idg.co.kr
 



2020.12.07

‘변화했을 뿐 여전히 유효한 이야기’··· 고전 IT 원칙 11가지

Bob Lewis | CIO
기술은 빠르게 변화하고 있다. 하지만 그 유행 아래에는 여전히 원초적이고 근본적인 IT 원칙이 남아있다. 오래됐지만 그럼에도 현대화해 적용할 수 있는 IT 원칙들을 소개한다. 

 

“많은 것이 같을수록, 더욱더 많은 것이 변한다(The more things stay the same, the more they change).”


원래 격언과 앞뒤가 바뀌긴 했지만 이는 ‘IT’라면 새겨들어야 할 대목이다. 이를테면 IT가 전자정보처리(EDP)였고, 프로그래머가 데이터센터를 지키는 문지기에 불과했던 초기 시절로부터 변한 것은 그리 많지 않다. 하지만 그러면서도 모든 것이 변했다. 

다행스럽게도, IT의 초창기 시절에 나온 기본적인 원칙은 여전히 유효하다. 다만 현대화됐을 뿐이다. 여기서는 차세대 IT를 구현하는 데 있어 길잡이가 될 11가지 고전적인 원칙과 이들이 변한 부분들을 살펴본다. 
 
ⓒGetty Images

1. 기술이 얼마나 좋은지는 결코 중요하지 않다 
- 낡은 원칙: “IBM을 사서 해고당한 사람은 없었다.”
- 새로운 변화: 오픈소스가 똑같은 이점을 제공할 수 있다  


기업 입장에서 기술 구매는 장기적인 차원의 투자다. 따라서 이에 부합해 공급업체도 장기적인 지원을 약속해주길 바란다. 이러한 맥락에서 IT는 안전을 위해 ‘대형 업체’에서 기술을 구매하곤 했다. 지금은 어떠한가? 오픈소스가 그만큼이나 안전할 뿐만 아니라, 심지어는 IBM이나 다른 대형 업체에서 오픈소스를 얻을 수도 있다. 

물론 모든 오픈소스가 충분한 지원 기반을 갖추고 있는 것은 아니다. 예를 들면 만약 PHP(Hypertext Preprocessor)로 필요한 기능을 모두 제공하는데, 보안 취약점이 많은 자바를 거들떠보겠는가? 물론 자바는 세계 최대의 소프트웨어 기업 가운데 하나인 오라클이 지원한다(아마도 ‘제공한다’라는 말이 더 정확한 듯하다). 

2. 강력한 정보 보안은 강력한 물리적 보안에서 시작된다 
- 낡은 원칙: 하드웨어를 안전한 공간에 보관하라
- 새로운 변화: 안전한 공간을 자체적으로 확보할 필요는 없다  


하드웨어는 언제나 안전한 공간에서 관리됐다. 이를테면 소수의 직원만 데이터센터에 접근할 수 있었고, 출입자와 출입 시간은 자동으로 기록됐다. 하지만 현재는? 이 안전한 공간을 모두 자체적으로 운영하지 않는다. 특히 중소기업이라면 코로케이션 설비, 풀 클라우드 등의 여러 대안이 있다. 

그러나 자체적으로 데이터센터를 구축하지 않는다고 해서 이 모든 비용을 아낄 수 있다고 생각해선 안 된다. 그중 일부를 외부 공급업체를 연결하는 저지연 및 고대역폭 네트워크에 투자해야 하기 때문이다. 

여기에 또 다른 오래된 원칙을 적용한다면 더 좋다. 즉 계란을 한 바구니에 담지 말라는 것이다. 네트워크 연결을 이중으로 유지한다. 그래야 물리적 재난이 발생해도 비즈니스를 중단하지 않을 수 있다. 

3. 위협을 파악하라 
- 낡은 원칙: 보안 위협 목록을 작성하고 대책을 수립하라
- 중간 단계: 데스크톱을 봉쇄하고 경계를 보호하라 
- 새로운 변화: 자산을 강화하고 경계를 보호하라 


과거에는 고객정보관리시스템(CICS) 세션을 차단시켜 해커가 접속하지 못하도록 해 보안 위협을 막았다. 그 이후 PC, 분산 시스템, 인터넷이 등장했고 위협도 더 많아졌다. 이에 따라 사람들은 데스크톱을 봉쇄하고 더 정교한 방화벽으로 경계를 지키며 대응하기 시작했다. 

아직도 모든 부분을 걸어 잠그고 자유를 허용하지 않는 것이 최선이라고 생각하는 경우가 많다. 그러나 기업들은 끊임없이 변화하고 혁신해야 생존할 수 있다. 그리고 혁신은 신제품 그 이상의 것을 의미한다. 다시 말해, 이는 창의적인 생각, 그리고 기업 내 모든 곳에서 이를 가능하게 하는 것들을 말한다. 

가장 큰 위협은 혁신할 수 없는 인력이다. 따라서 오늘날 기업들은 경계보다는 자산을 강화하고, 사용자를 더 적극적으로 지원하는 데 더 많은 시간을 투자해야 한다. 

4. 소프트웨어 테스트는 코드를 프로덕션 환경에 투입하고 결과를 보는 것이 아니다 
- 낡은 원칙: 개발, 테스트, 프로덕션이라는 3가지 환경을 유지하라
- 새로운 변화: 테스트를 클라우드로 이전하라 


회귀와 스트레스 테스트는 프로와 아마추어를 구분하는 척도다. 이는 과거에도 그랬고, 지금도 그러하다. 회귀 테스트는 새로운 변경사항이 기존 기능에 영향을 미치지 않는지를 확인한다. 스트레스 테스트는 비합리적인 부하를 가할 때 모든 부분이 적절한 방식으로 동작하는지 확인한다. 

이를 위해 IT는 개발, 테스트, 프로덕션이라는 3가지 환경을 유지했다. 이는 이들을 모두 구매하고 더불어 유지관리한다는 의미였다. 

이제 자체 데이터센터를 운영하더라도 클라우드에서 테스트 환경을 가동하는 게 더 합리적이다. 필요한 만큼만 사용하고 비용을 지불하면 되기 때문이다. 프로덕션 환경에 따라 다를 수도 있지만, 이는 회귀 테스트도 거뜬히 수행할 수 있다. 단 스트레스 테스트는 변수가 너무 많기 때문에 적어도 당분간은 기다려야 한다. 

5. 프로덕션 환경에 따른 변경 관리 
- 낡은 원칙: 공식적인 변경 관리 프로세스
- 새로운 변화: 공식적인 변경 관리 프로세스 


개발자가 프로덕션 환경에 새 코드를 그냥 던져 넣던 시절은 지났다. 여기에는 거쳐야 할 프로세스가 있다. 사실 이 프로세스를 좋아하는 사람은 아무도 없지만, 이는 좋고 싫음의 문제가 아니다. 이는 변경으로 인해 생산이 중단되지 않는지 확인하고, 만약 중단되는 경우 복원 계획을 준비하도록 하는 것이기 때문이다. 

여기서 클라우드는 변경 관리를 더 어렵게 한다. 클라우드 업체를 관리하는 데 유의하지 않는다면, 이들은 기업의 프로세스를 거치지 않고 운영 환경에 변경 사항을 적용할 수 있기 때문이다. 결국, 이는 클라우드 업체의 인프라다. 

6. 워터폴 모델이 효과적이어야 하지만 실제로는 애자일이 효과적이다 
- 낡은 원칙: 현업 관리자와 프로그래머 사이의 비공식적인 밀고 당기기 
- 새로운 변화: 현업 관리자와 프로그래머 사이의 비공식적인 밀고 당기기나 준수해야 할 규칙이 있는 스크럼 


공식적인 개발 방법론이 등장하기 전에, 현업 관리자는 여기저기 돌아다니며 ‘컴퓨터가 이렇게 하도록 할 수 있을까?’라고 묻곤 했다. 프로그래머는 뭔가를 시도해 현업 부문 사용자에게 보여주고, 제대로 될 때까지 이를 반복했다. 

이들은 당시 이 방법을 ‘애자일’이라고 부르지 않았다. ‘컴퓨터가 해야 할 일에 관해 대화를 나누는 것’이라고 불렀다. 하지만 이게 바로 애자일이다. 

그런 다음, 워터폴 모델이 출현했다. 워터폴 모델도 효과적이긴 하다. 다만 현업 관리자가 시스템을 완벽하게 구상하고 정확하게 설명할 수 있어야 했다. 하지만 이는 불가능했고, 꽤 긴 시간 동안 생산성을 낭비했다. 

그러다 반복과 상호작용에 기반을 둔 '스크럼'이 등장했고, 지금과는 다른 형태의 애자일 기법들이 추가됐다.

7. 관계는 프로세스에 우선하고, 관계는 거래보다 오래 지속된다 
- 낡은 원칙: 다른 최고 경영진과의 관계 관리는 CIO의 핵심 업무다
- 새로운 변화: 현업과의 관계 관리는 모든 사람의 핵심 업무다 


기업은 관계의 집합이다. 관계가 원활하면 모든 것이 잘 돌아간다. 그렇지 않다면 잘 돌아가지 않을 것이다. 기업이 엄격한 계층 구조였을 때, CIO는 다른 최고 경영진과의 관계를 관리했고 그 정도면 충분했다. 다른 최고 경영진이 CIO를 신뢰하지 않으면 IT는 성공할 수 없었다. 그렇게 단순했다.  

이제는 IT 부서 구성원이 현업 부문 구성원과 상호작용할 때마다 이는 IT와 현업 사이의 관계에 영향을 준다. 이는 단순히 CIO와 다른 경영진과의 관계가 아니다. 현업 부문이 IT를 신뢰하지 않으면 IT는 성공할 수 없다. IT를 신뢰한다면 IT는 한결 더 수월해질 것이다. 

8. 통합하라. ‘자동화 섬’을 연결하면 비효율적 비즈니스 프로세스를 크게 줄일 수 있다
- 낡은 원칙: 맞춤 프로그래밍된 배치 인터페이스의 점진적 축적
- 새로운 변화: 실시간 인터페이스가 있는 서비스 버스 
- 최신 변화: 비-IT 기반 SaaS 솔루션과의 통합 


사람 직원이 컴퓨터로 생성된 보고서 정보를 데이터 입력 화면에 다시 입력하던 시절, IT는 개별 시스템을 통합해 데이터 동기화를 유지하는 게 중요하단 것을 깨달았다. 그래서 IT는 인터페이스를 구축했다. 이들 중 대다수는 맞춤형으로 만든 배치 ETL(추출-변환-로드)이었다. 

현재는 이런 인터페이스가 너무 많아 유지하기 힘든 상황이다. 그래서 현명한 IT는 서비스 버스(service bus) 또는 이와 유사한 기술에 투자하고, 인터페이스도 만들고 있다. 단순히 기술을 적층하는 것은 기존과 같은 관리의 어려움으로 이어질 것이기 때문이다. 

오늘날 IT의 많은 부분이 IT 부서 밖에서 일어난다. 대부분 현업 관리자에 의해 SaaS 형태로 유입되며, 일부만 자동화돼 오히려 고립되는 ‘자동화 섬(islands of automation)’이 만들어진다. 이들은 결국 데이터를 재입력하는 데 지칠 가능성이 높다. 이에 대비해야 한다. 

9. IT는 현업을 지원하는 존재다 
- 너무 오래되다 못해 진부한 원칙: 기술을 위한 기술은 무의미하다
- 새로운 변화: 기술 리더십을 제공하라 


기술을 위한 기술은 좋지 않다. 그렇다고 IT가 업무 지시를 처리하는 것으로 역할을 제한해야 한다는 의미는 아니다. 이를 훨씬 뛰어넘어 기술 리더십을 제공해야 한다. IT 부서가 기술 리더십을 제공하지 못한다면, 즉 '제안과 토론' 대신 '수용과 전달'만 한다면 근본적 수준에서 실패할 수밖에 없다.

또한 기술 리더십은 스스로 기술을 구매하거나 개발하려는 현업 관리자와 사용자를 지원하는 것을 포함한다. 이제 ‘섀도우 IT’가 좋은 것임을 인정할 때가 됐다. IT의 범위를 넓히기 때문이다. 

물론 위험이 있지만, 가치 있는 일은 위험이 따르기 마련이다. IT는 현업 부문이 자신들의 기술로 성공할 수 있도록 지원해야 하고, 이때 외부 기술을 배척해선 안 된다. 

10. 프로젝트는 계획을 필요로 한다 
- 낡은 원칙: 워터폴 모델은 분명한 단계, 시한, 이정표를 의미한다
- 새로운 변화: 애자일에서조차 프로젝트는 마감시한과 이정표를 필요로 한다 


워터폴 프로젝트는 체계적인 계획을 세워서 실패하는 게 아니다. 현실 세계의 프로젝트는 언제나 지속적인 학습이 이뤄지는 연습이지 높은 수준의 요구사항에서 상세한 계획으로의 체계적인 진전이 아니기 때문에 실패한다. 

애자일은 ‘지속적 학습’이라는 현실을 수용한다. 그렇다고 해서 비즈니스 리더가 범위, 인력, 예산에 관한 추정치를 제공하지 않는 프로젝트 제안을 승인한다는 것은 아니다. 

따라서 지속적 학습은 계획이 고정될 수도 없고, 고정되어서도 안 된다는 것이란 점을 이해해야 한다. 즉 상황에 따라 계획도 변화하거나 변화해야 한다는 의미다. 이는 성공적인 워터폴 프로젝트에서도 일어난다. 다만 극적이지 않을 뿐이다. 

11. 결국 비즈니스 변화가 중요하다 
- 낡은 원칙: IT는 비즈니스 전반에 걸쳐 변화를 견인하는 원동력이다. 
- 중간 단계: IT는 비즈니스 변화의 가장 큰 걸림돌이다. 
- 새로운 변화: IT는 비즈니스 전반에 걸쳐 변화를 견인하는 원동력이다. 


컴퓨터가 새롭고 반짝였던 시절, 현업 부문 경영진은 컴퓨터가 수작업에 의한 오류를 크게 줄이는 동시에 비즈니스 프로세스를 더 빠르고 저렴하게 해 모든 곳에서 변화를 주도할 것이라 기대했다. 

이러한 기대는 IT가 수많은 상호 연결된 시스템을 지원하기 전까지 유효했다. 새로운 일을 하려면 시간과 비용이 많이 들었고 위험하기까지 했다. 워터폴 방법론도 도움이 되지 않았다. 

마침내 IT는 다시 느슨하게 흩어지고 있다. 애자일, 훨씬 더 개선된 통합 도구, 비-IT 지원 등에 힘입어, IT는 변화를 뒤쫓는 게 아니라 다시금 변화를 주도하기 시작했다. ciokr@idg.co.kr
 

X