새롭게 유효하다··· 클래식 IT 원칙의 재해석

기술 환경이 급박하게 변화하고 있지만 수많은 버즈워드 속에서도 여전히 유효한 IT 원칙들이 있다. 여기 현대 IT 환경에 적용될 수 있는 고전 IT 원칙 10가지를 정리했다.

"현상이 더 많이 유지될수록 변화가 더 크다."

사실 이 프랑스 격언의 진짜 의미는 오늘 말하고자 하는 바와 다르다. (역자 주: 원 뜻은 현상이 변할지라도, 실체의 깊은 곳은 변하지 않는다는 의미). 그러나 IT로 연결된 모든 관문에 새겨 넣어야 할 격언이다. '이곳에 들어온 자들이여, 모든 희망을 버려라!'는 말보다는 나을 것이다.

IT가 EDP이고, 프로그래머가 온실의 '제사장'이던 시절 이후 많은 부분이 변했다. 그러나 모든 것이 변하지는 않았다. IT 초창기의 근본적인 지혜들은 지금도 그대로 적용된다. 단지 현대에 맞게 조금 바뀌었을 뿐이다. 다음은 차세대 IT에 방향을 제시하는 10가지 '구 시대' IT 원칙들을 정리한 내용이다.

-> '선무당이 IT 조직을 망친다··· 조심해야 할 베스트 프랙티스 12가지'



◆ '기술 자체가 얼마나 좋은지'는 중요하지 않다

구 버전 : IBM을 구입해 해고 당한 이는 없다
신 버전: 오픈소스가 거대 벤더 이상의 이점을 제공할 수 있다.

기술은 구매자 입장에서 '장기적'이어야 한다. 뿐만 아니라, 공급자 또한 '장기적'이 되도록 만들어야 한다.

IT는 '안전'을 위해, 대형 벤더로부터 기술을 조달했었다. 지금은 어떨까? 오픈소스는 안전할 뿐더러 강력한 지원까지 갖췄다. 심지어는 IBM 같은 대형 벤더로부터도 오픈소스를 조달할 수 있다.

물론 모든 오픈소스 기술이 폭넓게 지원 역량을 갖춘 것은 아니다. 그러나 적어도 상당수는 그렇다. PHP가 필요한 기능을 모두 제공하는 데, 보안 측면에서 평판이 나쁜 자바(Java)를 굳이 쳐다볼 이유가 있을까?

사실 완전히 새로운 이야기는 아니다. 1970년대에 오픈소스를 닮은 SHARE 라이브러리가 등장했었기 때문이다.

◆ 좋은 ‘정보 보안’이란 좋은 '물리적 보안'에서 시작한다

구 버전: 하드웨어를 잠근 다음 멀리 둬라(가까이 가지 못하도록 만든다).
신 버전: 하드웨어를 자신의 방에 넣어 잠근 후, 멀리 두어야 하는 것은 아니다

항상 하드웨어를 잠근 다음 멀리 뒀다. 다시 말해, 소수 직원들만 신분증을 제시하고 데이터센터에 출입할 수 있도록 제약했다. 또 출입한 사람과 시간을 자동으로 기록했다. 그러나 지금은 이렇게 잠근 데이터센터가 자신의 소유가 아닐 수 있다.

특히 SMB를 중심으로 코로케이션 시설과 클라우드를 대안으로 활용하는 행태가 크게 확산됐다.

그러나 독자 데이터센터를 구축하지 않는 것으로 모든 비용 절감 목표를 달성하겠다는 생각은 버려야 한다. 외부 공급업체를 연결하는 낮은 레이턴시와 높은 대역폭의 네트워크에 일정 수준 투자를 해야 한다. 한 걸음 더 나아가는 것도 좋다. '하나만 확보하는 일이 없어야 한다'는 오랜 원칙을 적용하자. 다시 말해, 비즈니스가 중단되는 일이 없도록 서로 다른 2개의 연결을 구현하자.

◆ 위협을 이해하라

구 버전: 보안 위협을 조사해 목록으로 만든 후, 대책을 수립해 이행한다.
과도기 버전: 데스크톱을 잠근다. 그리고 경계선을 방어한다.
신 버전: 자산을 강화한다. 역시 경계선을 방어한다.

과거 보안 위협을 저지하는 방법은 CICS 세션을 '타이밍 아웃'으로 차단, 해커가 접속하지 못하도록 만드는 것이었다. 그러다 PC와 분산형 시스템, 인터넷이 등장하면서 위협이 증가했다. 우리는 갈수록 정교해지는 방화벽으로 경계선을 방어하고, 데스크톱을 잠그는 방법으로 대응을 했다.

아직도 모든 것을 잠그고, 누구도 창의력을 발휘하지 못하도록 만드는 것이 최고의 대응책이라고 생각하는 사람들이 많다. 그러나 혁신이 비즈니스의 흥망성쇠를 좌우한다. 그리고 혁신은 단순한 신제품 이상이다. 창의적인 사고가 필요하다. 이런 사고를 비즈니스 곳곳에 구현해야 한다.

지금은 경계선보다는 자산 강화에 더 많은 시간을 투자해야 하는 시기이다. 또 사용자 지원에는 이보다 많은 시간을 쏟아 부어야 한다. 인적 자원이 혁신을 하지 못하는 것이 가장 큰 위협이기 때문이다.

◆ 소프트웨어 테스트란 생산 현장에 코드를 적용한 후 무슨 일이 일어나는지 보는 것 이상이다

구 버전: 개발, 테스트, 생산이라는 3가지 환경을 유지 관리하다.
신 버전: 테스트의 많은 부분을 클라우드로 이전하라

회귀 테스트, 스트레스 테스트는 '프로'와 '아마추어'를 구분해준다. 과거나 지금이나 회귀 테스트로 새로운 변화가 기존 구성 요소를 파괴하지 않도록 만들었다. 반면 스트레스 테스트는 모든 사람이 시스템을 이용할 때에도 모든 기능이 순조로운지 확인하는 목적이었다.

IT 직종은 개발, 테스트, 생산이라는 3가지 환경을 유지 관리했다. 이 3가지를 구입했다. 그리고 유지 관리했다는 의미이다. 그런데 바뀐 부분이 있다.

독자 데이터센터를 보유하고 있는 경우에도 클라우드에 테스트 환경을 구현하는 것이 합리적이다. 필요한 만큼만 돈을 내면 되기 때문이다. 생산 환경에 따라 차이가 있지만, 회귀 테스트는 꽤 효과가 있다.

스트레스 테스트는 어떨까? 아직은 아니다. 최소한 지금 당장은 변수가 너무 많기 때문이다.

◆ 현장의 변화(변경 사항)를 관리하라

구 버전: 공식적인 변화(변경 사항) 관리 프로세스
신 버전: 공식적인 변화(변경 사항) 관리 프로세스

개발자가 비즈니스 현장에 새 코드를 주입할 수 있는 시절은 아주 오래 전에 지나갔다. 거쳐야 할 여러 프로세스가 존재한다. 이런 프로세스를 좋아하는 사람은 없다. 그러나 ‘좋아하고 말고’의 문제가 아니다. 변화가 생산 환경을 파괴하지 않도록 만들어야 한다. 파괴가 초래될 경우, 이를 대비할 계획을 수립해야 한다.

클라우드가 여기에 변화를 가져왔을까? 가져왔다. 변화(변경 사항) 관리가 더 어려워졌다. 클라우드 공급자 관리에 주의를 기울이지 않는다면, 이런 프로세스를 거치지 않고 생산 환경을 갑자기 변화될 있다. 클라우드 공급자의 인프라이기 때문이다.

◆ '워터폴'은 효과가 있어야 하지만, 애자일은 실제 효과가 있다

구 버전: 비즈니스 부문 관리자와 프로그래머가 비공식적으로 서로 대화하라.
신 버전: '스크럼'을 활용하라. 다시 말해, 비즈니스 부문 관리자와 프로그래머가 지켜야 할 규칙을 바탕으로 서로 비공식적으로 대화하라.

공식적인 개발 기법이 등장해 IT로부터 '재미'를 빼앗아 가기 전, 비즈니스 부문 관리자들은 "컴퓨터에 이런 기능을 구현할 수 있습니까?"라고 묻곤 했었다. 그러면 프로그래머는 시도를 해보고, 이를 비즈니스 사용자에게 보여주고, 제대로 기능할 때까지 이를 반복했었다.

그러나 이를 '애자일'이라고 부르지 않았다. 그냥 '컴퓨터 기능에 대한 대화'였다. 하지만 사실 이는 본질적으로 '애자일 기법'에 해당한다.

이후 폭포수 기법이 등장했다. 논리적이지만 유효하기 위해선 전제 조건이 필요했다. 비즈니스 부문 매니저가 100% 작동하는 시스템을 구상, 이를 정확히 설명해야 한다는 조건이다. 불행히 불가능한 일이다. 그래서 30년의 생산성을 잃었다.

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

◆ 관계는 프로세스를 앞서고, 관계는 거래보다 오래 간다

구 버전: CIO가 해야 할 중요한 일 중 하나는 다른 경영진과 관계를 구축해 관리하는 것이다.
신 버전: 모든 사람이 해야 할 중요한 일 중 하나는 비즈니스 부문 사람들과 관계를 구축해 관리하는 것이다.

비즈니스 부서가 요즘처럼 중요해지기 이전, 이들은 그냥 '관계자'들이었다. 좋은 관계는 모든 것을 순조롭게 만들어 준다. 관계가 좋지 않을 경우, 순탄한 일이 단 하나도 없다.

비즈니스가 엄격한 위계 구조를 갖고 있던 시절에는 CIO가 다른 경영진과 관계를 구축해 관리하는 것만으로 충분했다. 다른 경영진이 CIO를 신뢰하지 않는 경우, IT는 성과를 일궈낼 수 없었다. 아주 단순했다.

그러나 IT 부서 구성원이 비즈니스 부서 구성원과 접촉을 할 때마다 비즈니스/IT 관계에 영향이 초래된다. 이제 CIO와 다른 경영진 사이의 문제만이 아니다. 비즈니스 부서 구성원들이 IT를 신뢰하지 않는 경우, IT는 성과를 일궈낼 수 없다. 그러나 신뢰하는 경우, IT의 모든 업무가 쉬워진다.

◆ 통합하라. '고립되어 있는 자동화 기능'을 서로 연결해 통합하면 비즈니스 프로세스에서 비효율적인 부분을 많이 없앨 수 있다

구 버전: 맞춤 프로그래밍 한 배치 인터페이스를 점진적으로 축적
신 버전: 서비스 버스와 실시간 인터페이스 엔지니어링
최신 버전: IT가 주도하지 않는 SaaS 솔루션을 통합

사람이 컴퓨터가 생성한 보고서를 데이터 입력 화면으로 변환해야 했던 시절의 경우 IT의 가장 중요한 책임 중 하나는 데이터를 계속 동기화하기 위해 이질적인 시스템을 통합하는 것이었다.

이에 인터페이스를 구축했다. 아주 많은 인터페이스를 구축했다. 모두 맞춤형 배치 ETL이다.

너무 많아져 관리가 힘들어졌다. 이런 이유로 '현명한' IT 조직은 서비스 버스 또는 이와 유사한 기술에 투자하고, 인터페이스를 엔지니어링 했다. 다른 기술 위에 축적하는 것만으로 새로운 기술이 기존 기술을 재창조하기 때문이다.

현재 IT 이외의 부서가 운영하는 IT 기술이 많다. 비즈니스 부문 관리자들이 도입한 SaaS가 많다. 다시 말해, 자동화 기능이 분리되어 있는 것이다. 결국에는 이를 관리하는 데 싫증을 내게 될 것이다. 이 문제를 대비해야 한다.

◆ IT는 비즈니스를 지원하기 위해 존재한다

진부하기까지 한 구 버전: 기술 자체를 위한 기술은 존재하지 않는다.
신 버전: 기술 리더십을 제공하라.

'기술 그 자체를 위한 기술'은 좋지 않다. 그렇다고 IT가 자신의 역할을 순서대로 업무를 처리하는 것으로 국한시켜야 된다는 의미는 아니다. 이를 넘어서야 한다. 즉 기술 리더십을 제공해야 한다.

기술 리더십을 제공하지 못하는 IT 부서, 다시 말해 '제안과 토론' 대신 '수용과 전달'만 하는 IT 부서는 실패할 수밖에 없다.

이런 기술 리더십에는 스스로 기술을 조달하거나 구축하려는 사용자와 관리자를 지원하는 것도 포함된다. '셰도우 IT'가 좋다고 인정해야 한다. IT의 '대역폭'을 증가시키는 역할을 하기 때문이다.

물론 위험도 존재한다. 하지만 가치 있는 모든 것에 위험이 존재하는 법이다. IT는 비즈니스 부서가 자신이 도입한 기술로 성과를 일궈내도록 지원해야 한다.

◆ 비즈니스 변화가 중요하다

구 버전: IT는 비즈니스 변화의 주요 '동인(동력)'이다.
과도기 버전: IT는 비즈니스 변화를 가로막는 가장 큰 장애물이다.
신 버전: IT는 비즈니스 변화의 주요 '동인(동력)'이다.

컴퓨터가 등장한 초창기, 비즈니스 부문 중역들은 이를 활용해 비즈니스 프로세스의 속도와 경제성을 높이고, 직접 손으로 처리했을 때의 실수를 줄이면서 변화를 견인했다.

그러다 IT가 서로 연결된 시스템을 너무 많이 지원해야만 하는 시대가 도래했다. 신기술은 시간과 돈 낭비였고, 위험했다. 워터폴 기법에 의지해 봤지만, 도움이 되지 않았다.

마침내 이런 추세가 역전됐다. 애자일과 훨씬 개선된 통합 도구, IT 바깥의 IT에 힘입어, 정보 기술이 다시 한 번 변화를 견인하기 시작한 것이다.

* Bob Lewis는 글로벌 IT 서비스 기업의 IT 컨설턴트이자 선임 관리자다. 그러나 본 칼럼의 아이디어와 의견은 전적으로 그의 개인적인 견해다.