2012.01.25

인프라 로드맵을 세우고 유지하는 8가지 단계

Matt Prigge | InfoWorld
바깥에서 보는 사람들은 거의 모든 IT 부서가 일종의 기술 로드맵을 두고 있을 것이라고 생각한다. 기술 로드맵이 없다면 새로운 인프라스트럭처 하드웨어를 과도하게 구입하거나 모자라게 구입하는, 결국 많은 비용을 초래하는 실수를 피할 수 없기 때문이다. 
 
그러나 실제로 로드맵 문서가 존재하지 않는 경우가 무척 많다. 그 이유는 단순하다. 즉각적이고도 지속적인 변화의 와중에 어떻게 일관적인 기술 계획을 수립할 수 있단 말인가?
 
문제는 인프라스트럭처의 보강 및 수정을 포함하여 향후 3~5년을 대상으로 수립되는 인프라스트럭처 계획은 제대로 실행에 옮기기에는 너무 많은 시간이 걸리기 때문에, 다 완성될 때쯤에는 이미 시대에 뒤처지게 된다는 점이다. 
 
이 이유만으로 많은 IT 부서는 로드맵을 포기하고 즉각적인 요구에만 대처하는 방식을 택한다. 심적 부담이 큰 이런 방식은 결국 예산 초과, 그리고 수명 주기에 비해 너무 앞서 성장한 탓에 쓸모가 없어진 하드웨어라는 결과를 초래한다.
 
이제 다른 방식으로 접근해 보자. 빠른 변화에 직면한 상황에서도 미래를 대비해 계획할 수 있는 8단계 방법론을 소개한다. 
 
1단계 : 계획에서 다룰 기간 정하기
먼저 기술 로드맵에서 다룰 기간을 정하라. 이 기간은 조직에서 새로운 기술을 도입하는 빈도와 장기적인 예산 조건 등 여러 가지 요소에 따라 달라진다.
 
일반적으로 이 기간은 2년보다 짧아서는 안된다. 이보다 짧은 기간에 중점을 두는 계획은 대부분 별 가치가 없다. 마찬가지 이유로 5년을 훨씬 초과할 정도로 길어서도 안 된다. 5년 이후의 기술 상황이나 조직의 요구 사항을 예상하기는 너무 어렵기 때문이다.
 
2단계 : 일반화된 인프라스트럭처 질문서 작성
다음으로 할 일은 인프라스트럭처에 적용해야 하는 모든 기본적인 요구 사항을 정리하는 질문서를 작성하는 것이다. 이 시점에서 질문에 대한 답을 찾으려 노력할 필요는 없다. 질문만 작성하면 된다. 또한 구체적인 기술로 너무 세분화해 들어가지 않도록 주의해야 한다. 세부 핵심 시항은 나중에 다루게 된다.
 
대신 전체적인 관점의 질문에 집중한다. 아마 질문의 대부분이 본질적으로 기술 외적인 질문임을 발견하게 될 것이며, 사실 그것이 바람직한 것이다. 일반적인 예를 들어보면 다음과 같다.
 
- 연간 데이터 증가율은 어느 정도인가?
- 연간 컴퓨팅 용량 증가율은 어느 정도인가?
- 앞으로 나올 새로운 애플리케이션/구상/기술을 어느 것이든 인지하고 있는가?
- 비즈니스에 장기적인 확장 계획이 있는가(예: 새 사무실)?
- 업타임/안정성을 위한 회사의 요구 사항은 무엇인가?
- RTO/RPO(복구 시간 목표/ 복구 시점 목표) 요구 사항은 무엇인가?
 
이 단계를 마치면 상당히 광범위한 목록이 만들어질 것이다. 여기서 목표로 하는 것은 누군가(외부 업체도 포함)가 이 질문서와 그에 대한 답을 참고해서 비즈니스 당사자들이 요구하는 정책 요건을 짊어지고, 이를 충족할 수 있는 적절한 인프라스트럭처를 설계할 수 있도록 하는 것이다. 이를 위해 필요한 정보를 질문서에서 다 얻을 수 없다면, 아직 질문서가 제대로 완성되지 않았다고 보면 된다.
 
3단계 : 해결책 찾기
이제 재미있는 부분으로, 작성한 질문서에 답을 채우는 단계다. 일부 질문의 경우(예 : 데이터 증가율) 답을 구하려면 모니터링 도구를 설치해야 할 수 있다. 또한 비즈니스 담당자들과 어려운 대화를 통해 이들이 RTO/RPO와 같은 정책에 대한 현질적인 수치를 제시하도록 이끌어야 할 수도 있다.
 
4단계 : 미래에 맞춘 인프라스트럭처 설계
질답이 완성되면 계획 기간의 끝점을 기준으로 도출된 답변에(연간 증가율 수치는 이 기간 전체를 합쳐서 계산할 것) 드러난 요구 사항을 충족하는 인프라스트럭처를 설계할 시간이다. 이 끝점의 요구 사항을 충족하는 데 필요한 모든 요소를 포함해야 한다. 이미 이 중 상당수를 보유하고 있는 경우라도 마찬가지다.
 


2012.01.25

인프라 로드맵을 세우고 유지하는 8가지 단계

Matt Prigge | InfoWorld
바깥에서 보는 사람들은 거의 모든 IT 부서가 일종의 기술 로드맵을 두고 있을 것이라고 생각한다. 기술 로드맵이 없다면 새로운 인프라스트럭처 하드웨어를 과도하게 구입하거나 모자라게 구입하는, 결국 많은 비용을 초래하는 실수를 피할 수 없기 때문이다. 
 
그러나 실제로 로드맵 문서가 존재하지 않는 경우가 무척 많다. 그 이유는 단순하다. 즉각적이고도 지속적인 변화의 와중에 어떻게 일관적인 기술 계획을 수립할 수 있단 말인가?
 
문제는 인프라스트럭처의 보강 및 수정을 포함하여 향후 3~5년을 대상으로 수립되는 인프라스트럭처 계획은 제대로 실행에 옮기기에는 너무 많은 시간이 걸리기 때문에, 다 완성될 때쯤에는 이미 시대에 뒤처지게 된다는 점이다. 
 
이 이유만으로 많은 IT 부서는 로드맵을 포기하고 즉각적인 요구에만 대처하는 방식을 택한다. 심적 부담이 큰 이런 방식은 결국 예산 초과, 그리고 수명 주기에 비해 너무 앞서 성장한 탓에 쓸모가 없어진 하드웨어라는 결과를 초래한다.
 
이제 다른 방식으로 접근해 보자. 빠른 변화에 직면한 상황에서도 미래를 대비해 계획할 수 있는 8단계 방법론을 소개한다. 
 
1단계 : 계획에서 다룰 기간 정하기
먼저 기술 로드맵에서 다룰 기간을 정하라. 이 기간은 조직에서 새로운 기술을 도입하는 빈도와 장기적인 예산 조건 등 여러 가지 요소에 따라 달라진다.
 
일반적으로 이 기간은 2년보다 짧아서는 안된다. 이보다 짧은 기간에 중점을 두는 계획은 대부분 별 가치가 없다. 마찬가지 이유로 5년을 훨씬 초과할 정도로 길어서도 안 된다. 5년 이후의 기술 상황이나 조직의 요구 사항을 예상하기는 너무 어렵기 때문이다.
 
2단계 : 일반화된 인프라스트럭처 질문서 작성
다음으로 할 일은 인프라스트럭처에 적용해야 하는 모든 기본적인 요구 사항을 정리하는 질문서를 작성하는 것이다. 이 시점에서 질문에 대한 답을 찾으려 노력할 필요는 없다. 질문만 작성하면 된다. 또한 구체적인 기술로 너무 세분화해 들어가지 않도록 주의해야 한다. 세부 핵심 시항은 나중에 다루게 된다.
 
대신 전체적인 관점의 질문에 집중한다. 아마 질문의 대부분이 본질적으로 기술 외적인 질문임을 발견하게 될 것이며, 사실 그것이 바람직한 것이다. 일반적인 예를 들어보면 다음과 같다.
 
- 연간 데이터 증가율은 어느 정도인가?
- 연간 컴퓨팅 용량 증가율은 어느 정도인가?
- 앞으로 나올 새로운 애플리케이션/구상/기술을 어느 것이든 인지하고 있는가?
- 비즈니스에 장기적인 확장 계획이 있는가(예: 새 사무실)?
- 업타임/안정성을 위한 회사의 요구 사항은 무엇인가?
- RTO/RPO(복구 시간 목표/ 복구 시점 목표) 요구 사항은 무엇인가?
 
이 단계를 마치면 상당히 광범위한 목록이 만들어질 것이다. 여기서 목표로 하는 것은 누군가(외부 업체도 포함)가 이 질문서와 그에 대한 답을 참고해서 비즈니스 당사자들이 요구하는 정책 요건을 짊어지고, 이를 충족할 수 있는 적절한 인프라스트럭처를 설계할 수 있도록 하는 것이다. 이를 위해 필요한 정보를 질문서에서 다 얻을 수 없다면, 아직 질문서가 제대로 완성되지 않았다고 보면 된다.
 
3단계 : 해결책 찾기
이제 재미있는 부분으로, 작성한 질문서에 답을 채우는 단계다. 일부 질문의 경우(예 : 데이터 증가율) 답을 구하려면 모니터링 도구를 설치해야 할 수 있다. 또한 비즈니스 담당자들과 어려운 대화를 통해 이들이 RTO/RPO와 같은 정책에 대한 현질적인 수치를 제시하도록 이끌어야 할 수도 있다.
 
4단계 : 미래에 맞춘 인프라스트럭처 설계
질답이 완성되면 계획 기간의 끝점을 기준으로 도출된 답변에(연간 증가율 수치는 이 기간 전체를 합쳐서 계산할 것) 드러난 요구 사항을 충족하는 인프라스트럭처를 설계할 시간이다. 이 끝점의 요구 사항을 충족하는 데 필요한 모든 요소를 포함해야 한다. 이미 이 중 상당수를 보유하고 있는 경우라도 마찬가지다.
 


X