무슨 약자가 그리 많은지….

UCM = Unified Change Management. 범용 변화 관리. 기능을 말한다.
ClearCase를 설치 한뒤, VOB를 만들 때 마법사 창에 묻는 내용 중 하나가 project의 VOB에 대한 UCM도 생성할지 여부를 결정하는 부분이 있다. 즉 이 작업이 바로 ClearQuest와의 연동을 말하는 것 같다.

설치할 때 잘못 설치했는지 현재 ClearQuest에 대해 라이센스가 없다고 에러가 나는 바람에 정확한 테스트는 못했지만, Create as a UCM project VOB를 선택하고 설치를 진행하면 연동할 ClearQuest에 대한 정보를 묻는다. 여기에 현재 구성해서 만들어진 ClearQuest Storage에 대한 연결을 구축하면 된다.

그러나 아직 실행은 못해보았고, 지금도 Created as UCM project VOB 옵션은 끈 채로 진행하고 있다.

728x90

아래 글은 ClearCase에 대한 소개를 적은 글이다.
사실 아래의 글을 만든 이유는 바로 ClearCase에서 제공하는 기능 중 View라는 것이 헷갈려서 쓰기 시작했다.
특히, 그 View를 만들때  Dynamic View와 Snapshot View 중 하나를 선택하게 끔 나오고 있다.
일단 지금까지 생각한 것을 정리하자면 아래와 같다.

Snapshot View는 서버의 데이터(VOB)와 똑같은 한 벌의 데이터를 각 개발자(혹은 사용자)들이 갖는 것이다. 즉 서버의 데이터의 내용을 복제해서 사용자의 개인 PC 내의 특정 폴더에 복사해 놓고, 그 안에서 작업하고 Check Out / Check In 할 때만 서버와 통신하는 방식인 것이다. 현재 Visual Source Safe에서 하는 방식이라고 보면 된다.

Dynamic View는 서버 내 특정 공간을 주고 사용자는 서버에 직접 데이터를 얹어 놓고 작업하는 것이다. 이 때 Dynamic View의 내용은 VOB를 그대로 보여주는 것은 아니다. 별도의 공간을 할당하기 때문에, 사용자가 아무리 변경해도 VOB에 바로 적용되는 것은 아니다. 최종적으로 Check In이 되어야 Mixing되어 적용되는 것이다.

아무래도 지금 필자는 Source Safe에 익숙하기 때문에, 이 ClearCase를 Snapshot의 개념으로 맞추어 이해하고 있어 Snapshot과 Dynamic의 차이를 바라보지 못한 것 같다.

일단 ClearCase는 특수한 상황이 아니면 Dynamic View의 형태로 구성하고 개발을 하는 것이 좋을 것 같다.

728x90

IBM의 Version Control  Solution 중 Rational 에서 만든 ClearCase라는 제품이 있다.
자세한 역사는 잘은 모르겠지만, 분산 환경과 복잡한 버전 관리에 있어 우수하다고 한다.

해야 할 일도 형상관리인지라, 이 ClearCase라는 것에 대한 파악이 필요하고,
마침 잘 설명되어 있는 PPT를 구해, 그 내용을 번역 하면서 정리해보도록 하겠다.
이 내용은  ftp.ccs.neu.edu/pub/people/laf/Talks-2000-nonames/ClearCase.ppt에서 원본을 다운로드 받을 수 있다.

소스 제어

소스 제어란, 간단하게 말하면, 변경사항이 발생하는 경우 새로운 버전을 매겨 등록 관리하는 것을 말한다. 그래서 변경 때 마다 버전이 매겨 지기 때문에, 어디서 무엇이 어느 시점에 추가/수정/삭제되었는지 판단되기 때문에, 문제가 발생할 때 어느 부분의 변경으로 발생되어 있는지 정확하게 추적할 수 있게 된다.

다음 그림에서 보듯 특정 사람이 특정 내용을 변경할 때, 먼저 버전 관리되는 항목 중 변경할 항목을 Check Out을 한다. 이는 무척 중요한 행위인데, Check Out을 하는 순간 그 시점의 코드는 그 사람의 소유가 되게 된다. 그리고 필요한 내용에 따라 변경한 다음 Check In을 하게 되면 버전 관리 도구는 자동으로 버전을 증가 시키고 서버에 등록하게 된다. 아래의 그림에 따르면 0번 버전의 내용을 Check Out 한 뒤 수정하고 다시 Check In을 통해 버전을 1 증가 시켜 1번 버전이 되는 것이다. 이처럼 변화를 준 뒤 Check Out-Check In을 함으로써 해당 버전 관리 내용의 버전은 증가되게 된다. 여기서 버전 관리를 하게 되는 주축, 최종 배포 버전이 되는 코드 내용이 바로 Main Line이라고 한다.

기존 버전 관리 소프트웨어 종류

사실 버전 관리 작업은 늘 필요로 했던 요청 사항이였고, 예전부터 이미 다양한 도구들이 만들어졌고 사용되고 있었다. 그 중 대표적인 것이 아래와 같다.

* ClearCase - Windows and UNIX
    - 지금 부터 살펴볼 도구.
* Visual SourceSafe – Windows
    - MS에서 주로 사용되는 버전 관리도구로 Visual Studio랑 가장 궁합이 잘 맞는 도구
* CVS – UNIX
    - Unix 계열의 제품으로 Client는 여러 플랫폼을 지원하지만, 서버는 Unix만 제공. linux용인 제품도 많다.
* CMVision - Unix and Windows
   - 모름
* Control CS - Unix and Windows
   - 모름

각 도구들은 현재 버전 관리 뿐만 아니라 파일 관리까지 제공하며 Text Diffrencing에서 부터 Binary Diffrencing까지 다양한 형태로 제공된다. 이 중 살펴볼 버전 관리도구가 바로 ClearCase이다.

ClearCase
ClearCase에는 무척 다양한 기능이 탑재 되어 있다. 모든 기능을 세세히 살펴보는 것은 어렵고 대표적인 기능들을 설명하도록 하겠다.

Overview
ClearCase의 개괄적인 대표적인 장점들은 아래와 같다.

  • 모든 종류의 파일과 디렉터리에 대한 버전 관리 기능을 제공한다.
  • 각 버전 이력에 대한 정보를 항상 기록하며 필요하면 버전 이력에 대한 보고서를 제시한다.
  • 매 Release 때 마다 정확한 코드 복제를 보장한다.
  • 최신 버전 코드 복제 및 추적 기능을 제공한다.
  • 강력한 코드 버전 분할(Branch) 및 통합(Merge) 기능을 제공한다.
  • 모든 소프트웨어 구성요소의 통합을 보장한다.

각 장점들을 기준으로 하나씩 설명하도록 하겠다.

ClearCase의 중요 기능 요소.
버전 관리를 위한 기능을 기본적인 기능은 다음과 같다.

  • 버전 분할(Branching)
  • 버전 통합(Merging)
  • 버전 라벨 처리(Labeling)

사실 각 상황이나 구성에 따라 복잡한 기능들이 많지만, 버전 관리 작업을 단순화 하면, 위의 3가지 매커니즘을 통해 버전을 관리하게 된다.  위의 기능들을 적용한 결과물을 트리형태로 표시하면 아래의 그림과 같다.


/Main 이 바로 버전 관리의 중요 지점이라고 보면 된다. 그 중 0, 1, 2, 3, … 이 버전을 의미한다. /Main을 계승하는 버전이 실제적으로 배포될 버전이며 그 버전들 중 최신 버전(그림에서는 5번이 된다.)을 컴파일 하여 제공하면 되는 것이다.  각 요소들의 파일, 디렉토리에 관계 없이 모든 요소들이 버전관리를 받게 된다. 또한 버전 관리를 받는 요소에 Check Out되는 순간 Read Only가 되어 다른 이들이 수정하지 못하게 끔 한다. 

BRANCH라는 부분은 특정 버전에서 다른이가 Check-Out된 내용에 대한 수정작업을 하거나, 기능적인 테스트를 위해 임시적인 버전을 설정하여 구성할 때 사용된다. 위의 그림에서 보면 3번에서 /Rls2_bugfix라는 하위에 다시 0, 1, 2 식으로 새롭게 버전이 만들어지는데 이 처럼 /Rls2_bugfix 라는 형태로 구성되는 것을 Branch라고 한다. /Rls2_bugfix는 /Main의 3번 소스를 그대로 가져와 새롭게 변경하고 적용하는 것이다. 보통 이런 작업은 버그 수정 작업을 하거나, 검증되지 않은 새로운 기능 추가할 때 사용된다. /Main의 3번 소스를 기준으로 새로운 기능을 추가하여 자체적으로 컴파일 하고 실행해보고 이상이 없다면 /Main에 돌려주고, 문제가 있다면 폐기하는 일종의 임시 버전 같은 것이다. 이 Branch 작업은 무한대로 할 수 있으며 Branch된 버전에 새롭게 더 Branch 처리를 할 수 있다.

MERGE란, BRACH된 하위 버전을 상위 버전에 포함시키는 작업이 된다. 통합 결과 이상이 없다면 이런 단계를 통해 버전에 합쳐지게 된다. 이 작업은 하위의 작업이 상위로 올라가는 형태로 추가되게 된다. 물론 통합될 필요가 없는 경우에는 하위 버전을 그냥 버릴 수 있다.

LABELS는 각 버전에 이름을 붙이는 작업이다. 단순히 번호로 나열된 버전에 특정한 이름이나 버전을 붙여 해당 버전의 의미를 정확히 나타내는 것이다. 위의 예제에서는 Beta, Rls 1.0, Rls 2.0 …. 이런 식으로 붙여 해당 버전이 베타 버전 소스이다, 새로 Relase된 버전이다 이런 식으로 이정표를 새기는 작업을 하게 된다. Code Complete나 특정 개발 마일스톤 때 매겨지게 된다.

위의 기본 기능을 편리하게 할 수 있도록 ClearCase에서는 다음과 같은 기능들을 제공한다.

  • Check Out –> 편집 –> Check In 이라는 단순한 모델로 버전 관리를 한다.
  • 특별히 충돌하는 내용이 없는 변경사항에 대해 지능적인 Merging 기능을 제공하여 자동적으로 버전 통합(Merge) 해준다.
  • 그래픽 기반의 비교 및 통합(Merge) 도구를 제공한다.
  • Dynamic(동적) View, Snapshot(순간보존 형) View라는 모델을 제공해 상황에 맞는 형태로 작업할 수 있도록 제공한다.

View와 VOB

View
View란 ClearCase에서 제공하는 모델 중 하나로, 작업 공간 관리를 위한 기초 단위이다. 각각 개별적인 개발자 혹은 밀접한 작업자 그룹에서 독자적으로 작업하는 공간으로 VOB(Versioned Object Base)에서 필요한 사항들만 나타내는 부분이다. 프로젝트 전반적인 소스 코드가 있을 때, 각 개발자 혹은 독자 그룹 마다 주로 보는 파일 이나 디렉터리들이 다를 것이다. 그래서 전체 소스 코드 중 주로 보게 되는 항목들을 선택하여 볼 수 있도록 제공하는 부분이다. 그래서 프로젝트에 해당하는 파일이나 디렉터리를 모두 공유해서 사용하지만, 마치 개별적인 특정 폴더 및 파일을 보여주게 된다.

VOB(Versioned Object Base)
ClearCase에 각 요소들을 저장하는 저장장소로 모두 읽기 전용으로 제공된다. 네트워크 기반의 저장장소로써, 모든 이들의 소스를 저장하고 관리받는 기준 소스 정보들이다. 각 사용자들은 이 VOB를 공유하게 되며 수정할 때는 View에서 수정하게되며 최종적으로 변경 사항 적용될 때 View에서 VOB로 적용된다. Windows에서는 네트워크 드라이브로 UNIX에서는 Mount된 디렉터리로 제공된다.

View와 VOB의 관계
위에서는 단순히 텍스트로 나열하기만 해 조금 난해할 수 있는데, VOB와 View의 관계를 굳이 표현하면 아래와 같다.

즉 사용자의 환경에 따라 공통의 VOB 자료를 View의 설정만 다르게 해서 필요한 내용을 중심으로 표시하는 내용이다. 만일 개발자 1이 특정 소스를 변경했을 때 Check-In 하지 않는 이상 VOB에 반영되지 않기 때문에, 다른 이들은 간섭되지 않는다. 즉 최종 변경 후 Check In이 되어야 VOB에 반영되며 반영되어야 다른 이들에게도 전파가 되게 된다.

Configuration Specification
위에서 언급했을 때 사용자 별로, 버전 별로 보여주는 내용이 틀려지도록 할 수 있다고 했다. 이 때 이런식으로 보여질 수 있도록 View내에 값을 설정할 수 있는데, 그 설정을 Configuration Specification(구성 정의?)라고 한다. 이 안에 마치 SQL의 쿼리 처럼 규칙에 필요한 사항들에 해당하는 값을 넣으면 전체 VOB 내용 중 Filter되어 해당 View에 전달되게 된다. 이 값은 Create View 할 때 기본값이 설정되며 필요시 수정하여 변경할 수 있다.

기본 값은 아래와 같다.

element * CHECKEDOUT
element * \main\LATEST

위의 내용을 의미하는 바는 Check Out된 항목 들과, Main 의 LASTEST 항목들을 모두 가져오게 된다.

View의 종류
지금까지 View가 무엇인지를 언급했다면 이번에는 View의 종류를 언급하려 한다.
개발 환경에 따라 다르게 설정하여 진행하게 되는데, 여기에는 2가지 종류가 있다.

  • Snapshot View
  • Dynamic View

Snapshot View
Snapshot이라는 뜻 때로 특정 시점의 그대로의 내용을 표시하는 View이다. 즉 한번에 모든 설정과 값들을 사용자의 환경에 그대로 붑고, VOB와의 통신은 끊은 채 독자적으로 관리하는 View이다. 보통 네트워크로 ClearCase와 항상 연결되기 어려운 환경이거나, 공동작업이 거의 없는 부분에 대한 수정하는 경우 많이 사용된다.

Dynamic View
각 요소들을 투명하게 연결하여, 항상 최신 버전을 유지하고, 변경된 사용만 업데이트 하기 때문에 적은 양만 업데이트 하며, 빌드에 대한 감사등을 지원한다. 보통 네트워크 드라이브와 같이 상시 연결된 채널을 구성하게 된다.

Snapshot – Dynamic View 의 유사점

  • Configuration Specification 을 통해 버전 요소들을 선택할 수 있다.
  • Check Out – 편집 – Check In 의 기본 행위로 동작한다.
  • Check Out한 대상을 Reserved(예약)/(Unreserved)비 예약 상태로 설정할 수 있다.

Snapshot – Dynamic View의 차이점

  • Snapshot은 버전 자체가 만료될 수 있기 때문에 주기적인 서버 동기화 작업이 필요하다.
  • Dynamic의 경우 Check Out 하는 경우 서버와의 항상 동기화 작업을 수행하기 때문에, VOB에서 굳이 최신 버전을 일일이 받아 올 필요가 없다.
728x90
UML로 Use Case나 Class Diagram 조금 깔짝거리던 실력이라,
무지에 가까운 지식 속에서 끊임없이 도전해오듯 나오는 속성이
바로 스테레오 타입(Stereo Type)

모른체 지나가기엔 너무 먼 길을 걸은 느낌에 잠깐 검색하니
아래의 글을 찾았다.


다 읽고 난 소감은....

이놈의 스테레오 타입이라는게 결국 Domain (경계?) 이나 Category (분류?)의 의미가
가깝다는 생각이다. 일단, 정확함을 떠나서 그렇게 생각하면서
UML로 된 그림들을 하나씩 하나씩 봐야 겠다.
728x90

원문 : http://www.codeproject.com/KB/tips/autovssbackup.aspx

Visual Source Safe의 기능은 최소한 MS Visual Tool을 사용하고 있다면 모두 반 불가항력으로 사용하고 있다. ( 물론 돈 많은 회사에서는 IBM Rational의 Clear Case 같은 도구를 사용할 수 있을지도 모르겠다 ). 그런데 관리도구를 보면, MS의 전형적인 귀차니즘이 묻어 나서 백업 도구의 부실함을 확인할 수 있다. 물론 Release 서버를 별도 구축하여, Release만 담당하는 사람이 있다면, 관리도구를 그 사람이 스스로 일정 시간마다 할 수 있을지 모르겠지만,
조그만한 회사에 조그만한 팀에서 운영한다면, 이런 작업은 또하나의 작업으로 환생하여, 누군지 모를 프로그래머 한명 또는 다수가 묘한 프레샤를 받게 된다. ( 만에 하나 VSS DB가 날라가서 백업을 원복하는데, 백업 과정을 제대로 수행하지 않음이 밝혀지면, 온 지탄의 눈길을 한눈에 받을 지도 모른다. )

그래서 자동으로 백업해줄 만한 솔루션을 찾다가, 코드 프로젝트 쪽에서 백업 기능을 일정 케쥴에 맞추어 수행할 수 있도록 하는 기능을 구성한 분이 있어, 그 내용을 적어보도록 한다.
( 해외 사이트의 글이지만, 엄연한 불펌이므로, 이 글을 재가공은 가급적 자제해주시기 바랍니다. -_-;;;;; 원문을 최대한 활용해 주세요.  [ I'm too sorry about capturing the documents by illegally. I'm very very sorry )

1. 백업용 배치 파일 만들기.

다음 텍스트를 .BAT 또는 .CMD 파일로 만든다.

1: @ECHO OFF
2: @TITLE Backing up source safe databases
3: FOR /F "tokens=2-4 delims=/ " %%i IN ('date /t') DO SET DATE=%%i-%%j-%%k e:\source_safe-code\win32\ssarc -d- e:\backups\%DATE% General backup.ssa $/General
4: @ECHO Finished backups

* 위의 항목 중 "숫자:" 부분은 줄 수를 가르키기 위한 부분이다. 실제 코드는 1:, 2:, 3:, 4: 는 빼고 나머지 부분을 넣는다. 각 줄 끝은 ENTER 키를 꼭꼭 넣는다. 일단 위와 같이 만들어 준다.

위와 같은 내용을 .BAT 혹은 .CMD 파일을 만들었으면, 자신의 Source Safe가 설치된 내용에 맞게 수정하는 작업을 한다. 그 핵은 3번째 줄에 있다.

먼저 해당 문장을 살펴보면 아래와 같이 진하게 표시된 부분을 수정해야 한다.

FOR /F "tokens=2-4 delims=/ " %%i IN ('date /t') DO SET DATE=%%i-%%j-%%k e:\source_safe-code\win32\ssarc -d- e:\backups\%DATE% General backup.ssa $/General

진하게 칠해진 부분에 Souce Safe 데이터 베이스가 위치한 경로를 넣어주도록 한다. 보통 ssafe.ini 파일이 있는 위치를 가르키면 된다.

그리고 난 뒤에 아래와 같이 진하게 표시된 부분도 수정한다.

FOR /F "tokens=2-4 delims=/ " %%i IN ('date /t') DO SET DATE=%%i-%%j-%%k e:\source_safe-code\win32\ssarc -d- e:\backups\%DATE% General backup.ssa $/General

진하게 칠해진 부분이 백업 결과물을 저장할 위치를 의미한다. 적당한 경로를 설정해서 수정한다.

2. 스케쥴 만들기.

시작 -> 제어판 -> 예약된 작업 -> 예약 작업 추가 를 한다.

예약 추가 마법사가 시작되면 "다음" 버튼을 클릭한다.

작업을 실행할 프로그램 선택화면에서 "탐색" 버튼을 클릭한다.

탐색 창에서 자신이 만든 .BAT 혹은 .CMD 파일을 선택한다.

일정을 어느 스타일로 할 것인지 결정한다. ( 매일, 매주, 매월 등등 다양한 스타일이 있다. - 예제 화면으로는 "매일" 스케쥴을 선택한 것으로 보여준다. )

세부 스케쥴을 설정한다. 시간이나, 요일 등을 설정하게 된다.

이 프로그램을 실행할 계정을 선택한다. Source Safe 데이터베이스의 모든 파일을 쉽게 접근할 수 있는 계정으로 설정한다. 암호도 올바르게 넣어준다.

완료가 되었으면 "마침"을 클릭하면 자동으로 저장되며 스케쥴 설정대로 실행되게 된다.

728x90

참조 추가 대화 상자에 어셈블리를 표시하는 방법

 
기술 자료 ID : 306149
마지막 검토 : 2006년 9월 1일 금요일
수정 : 4.0

요약

Visual Studio .NET에서 클래스 라이브러리를 개발할 때 라이브러리를 직접 찾지 않고도 .NET 탭의 참조 추가 대화 상자에 자동으로 표시할 수 있습니다.

그러나 GAC(전역 어셈블리 캐시)에 어셈블리를 추가할 경우 참조 추가 대화 상자가 경로를 기반으로 하고 GAC의 구성 요소를 열거하지 않으므로 이렇게 할 수 없습니다.

참조 추가 대화 상자에 어셈블리를 표시하려면 어셈블리 위치를 가리키는 다음과 같은 레지스트리 키를 추가하면 됩니다.
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]@="C:\\MyAssemblies"
여기서 MyAssemblies는 어셈블리가 들어 있는 폴더의 이름입니다.

참고: HKEY_LOCAL_MACHINE 하이브 아래에 이 레지스트리 항목을 만들 수 있습니다. 이렇게 하면 시스템에 있는 모든 사용자에 대한 설정이 변경됩니다. HKEY_CURRENT_USER 아래에 이 레지스트리 항목을 만들면 현재 사용자에 대한 설정만 변경됩니다.

이 키를 추가한 후에는 Visual Studio .NET을 다시 시작하십시오.

추가 정보

시스템에서 실행 중인 다른 응용 프로그램과 어셈블리를 공유하지 않으려면 GAC에 어셈블리를 추가하지 않는 것이 좋습니다. 또한 프로젝트에서 GAC의 어셈블리를 직접 참조할 수도 없습니다. GAC의 어셈블리를 사용하려면 로컬 폴더로 어셈블리를 가져온 다음 이 폴더에서 어셈블리에 대한 참조를 추가해야 합니다. 로컬 시스템에 있는 프로젝트 폴더로 어셈블리를 복사하지 않으려는 경우에는 해당 어셈블리의 로컬 복사 속성을 False로 설정할 수 있습니다. 런타임에 응용 프로그램은 GAC의 어셈블리를 사용합니다.
728x90

네, 단 SMS 2003 with SP2에서만 SQL 2005를 지원합니다. SMS 2003 with SP2 이전 버전에서는 SQL 2005를 지원하지 않습니다. 만일 이전 버전에 대한 설치 후 업그레이드를 하려면 다음과 같은 업그레이드 순서를 거쳐 진행하셔야 합니다.

업그레이드 순서

1.

SQL 2000 SP3 또는 4를 설치합니다.

2.

SMS 2003 with SP1을 설치합니다.

3.

SMS 2003 사이트 서버를 SP2로 업그레이드 합니다.

4.

SQL 2000 서버를 SQL 2005 서버로 업그레이드 합니다.

지원되는 플랫폼과 시스템 요구사항과 같은 자세한 정보는 Microsoft Download center 에 있는 Supported Configurations Guide SMS 2003 SP2  라는 문서의 "Server Software Requirement"를 보시기 바랍니다.

From : http://www.microsoft.com/technet/prodtechnol/sms/sms2003/techfaq/tfaq02.mspx

728x90


"대부분의 조직에서는 자신들의 IT 인프라스트럭처가 최고의 전략적 요소가 되어 업무에 적용될 수 있고, 되리라고 생각합니다. 여기서 IT와 업무간에 효율적인 구성이 되려면, 인프라의 성숙도가 어느정도 받쳐 주어야 하며 사람, 프로세스 그리고 기술간의 균형이 잘 이루어져야 합니다."

분석한 내용에 따르면 IT 예산의 70%이상이 인프라스트럭처 - 서버, 운영체제, 저장장치, 네트워크 -에 소요된다고 합니다. 여기에 추가적으로 데스톱이나 모바일 장비로 전환하거나 관리하고자 할 때 이 비용이 더해지고, IT 인프라스트럭처는 새로운 부분에 대해 문제에 직면하게 될 것입니다.

IT 인프라스트럭처는 업무에서 효율적이고 성공적으로 운영하기 위해 필요한 서비스 및 사용자 응용 프로그램들을 제공할 수 있는 소프트웨어 같은 것으로 전략적 자산이자 가장 중요한 기간 서비스 입니다.  많은 조직에서는 데이터 센터 및 데스크톱 인프라스트럭처 상에서 발생하고 있는 각종 신 기술에 맞추어 빠르게 발전하고 개발되어 가고 있습니다. 이에 따라 인프라스트럭처는 점점 복잡하고 경직되어가며, 초기 구축 비용으로는 더 이상 관리할 수 하기 어려워져 가고 있습니다. 그로 인해 변화되어가는 업무 요구에 맞추어 나갈 수 없게 되었습니다.
이에 따라 대부분의 조직에서는 최적화와 IT 인프라의 비용 효과의 중요성을 깨닫고, 보다 합리적인 인프라스트럭처를 구축하며, 데이터 센터 정리, 데스크톱 표준화, IT 운영 메뉴얼 등과 같은 초기 작업을 통해 운영을 보다 효율적으로 할 수 있도록 다양한 작업을 시도하고 있습니다. 또한  인프라스트럭처 전체 운영에 대한 모든 것을 특정 IT 부서에게 모두 전임 시키게 되면 자신들이 원했던 사항들을 만족하기 어렵게 되고,  업무에 지장을 줄 만큼 긴 시간을 수정작업에 소요하게 될 수 있습니다. IT 인프라스트럭처 조직화에 대해 일관된 발전을 하기 위해서는 IT 인프라스트럭처 성숙도의 장기적인 전략적 관점을 가지고, 자신의 업무상에 필요한 사항과 전체 업무전략에 맞는 IT 성숙도 발전 방법 및 전체 수용량에 대한 고려가 필요합니다.

인프라스트럭처 최적화 모델
마이크로소프트에서 제시해 드리는 인프라스트럭처 최적화 모델은 고객에 대한 이해와 그에 따른 IT 인프라스트럭처의 현재 상태에서 어떻게 개선, 발전해야 하는지 도와드리기 위한 것입니다. 예를 들면 비용에 관한 용어의 의미나 보안적인 위험이나 운영에 관한 실례들을 제시해 드립니다. 이를 위해서는 관리되지 않는 환경에서 동적 관리 환경으로 전환해야 실질적인 최고의 비용 절약을 하실 수 있습니다. Basic 인프라스트럭처 상에서 가장 취약한 부분인 보안이라는 부분을 인프라스트럭처의 성숙도를 높여 보다 혁신적인 보안 강화를 이끌어 낼 수 있습니다. IT 인프라스트럭처 관리는 높은 성숙도와 최적의 자동화 및 혁신적인 기술을 통해 변화시킬 수 있습니다. 마이크로소프트와 파트너에서는 인프라스트럭처 최적화 순방(Infrastructure Optimization Journey)을 통해 고객들이 인프라스트럭처의 성숙도를 높이기 위하여 필요한 기술, 방법 및 지원등을 제공하고 있습니다. 방법으로는 분산되고, 불필요한 것들을 보다 최적화 되고 반복적인 형태로 전환하는 것입니다. 고객 분들에게 현재까지 계속 유지해오던 기본적인(Basic) 상태에서 정보 근로자, 관리자들에게 힘을 실어주고, 새로운 비지니스 기회를 지원해드릴 수 있는 동적(Dynamic) 상태로 이전 시켜드림으로써 고객 분들의 업무적 가치 증대와 업무 능력 향상을 위한 기술들을 제시해 드립니다.

마이크로소프트와 함께 프레임워크로 구성된 이 모델을 이용하여 작업해보시면, 기업 내에 "기본(Basic)"단계의 성숙도(IT 인프라스트럭처에서는 보통 "가장 큰 비용이 드는 부분"으로 생각하고 있는 곳)에서 IT 인프라스트럭처에 대한 업무적 가치가 더욱 명확히 알게 되고, IT 인프라스트럭처가 업무적 전략 중요 요소로써, 업무에 제대로 적용되었다고 생각할 수 있는 "동적(Dynamic)"으로 전환된 조직으로 변화되면서 전략적 가치와 업무적 이해를 보다 빠르게 이해할 수 있으실 수 있습니다.  

인프라스트럭처 최적화 모델 - 활동 내역
마이크로소프트의 인프라스트럭처 최적화 모델은 기업내 최적의 실례들, 마이크로소프트 자체적으로 가지고 있던 기업 고객들에 대한 경험들과, Gatner의 인프라스트럭처 최적화 모델(Gartner's Infrastructure Optimization Model)과 MIT 아키텍처 성숙도 모델(MIT's Architecture Maturity Model)을 기반으로 개발되어왔습니다. 이 인프라스트럭처 최적화 모델을 만든 가장 중요한 목적은  기술적 허용량 및 업무 가치에 대한 벤치마크를 쉽게 이용할 수 있고 보다 유연하게 구성된 성숙도 프레임워크를 이용하는 간단한 방법을 개발하는 것입니다.

맨 처음 해야하는 것은 모델을 이용해 모델을 기준으로 여러분의 인프라스트럭처의 성숙도 단계가 어디에 있는지 확인하는 것입니다. 일단 현재 성숙도 단계를 확정지었다면, 다음 단계로는 업무의 이익을 최대화 할 수 있는 목표 성숙도 단계까지 어떻게 가야 될지에 대한 단계에 대한 개발 계획을 모델을 이용해 구성하는 것입니다.

Level 1. 기본 단계(Basic)
기본 IT 인프라스트럭처는 일반적으로 수동적이며, 자체적인 방법을 가지고, 중앙관리가 없거나 최소화되었으며 IT 정책이 없거나 제한되지 않은 것이 특징입니다. 그래서  보안, 백업, 이미지 관리 및 배포, 결제, 및 기타 외부 IT 표준을 기반으로한 각각의 표준을 갖추고 있는 있습니다. 여기에서는 각 표준간에 서로 상충되는 다양한 문제들이 발생할 수 있으며, 전략 수립에 있어 다양한 제한 요건을 가질 수 있습니다. 전체 응용 프로그램 및 서비스의 상태를 판단하기 위한 도구나 자원들의 부족이 어느정도인지 파악할 수 없습니다. 더욱이 IT 간의 정보 공유 구축을 위한 별도의 수단도 없습니다. 기본 인프라스트럭처로 구성한 고객들은 자신의 환경을 제어하는데 상당한 어려움을 겪고, 높은 데스크톱과 서버의 비용을 치루게 되며, 보안 사항에 대한 대응이 늦어지고, IT를 통해 업무적 효율을 받는 것이 아주 적을 것입니다. 보통 모든 패치, 소프트웨어 배포, 및 서비스들 제공하려면 손도 많이 가며 비용도 많이 들 것입니다.
정리하자면 고객들이 이런 기본 인프라스트럭처 유형에서 표준(Standard) 인프라스트럭처로 이전하게 되면 환상적인 비용 감소를 확인하실 수 있을 것입니다. 이런 이전을 위해서는 다음과 같은 사항들을 수행해야 합니다.
·  강제성 전략을 가진 표준, 정책, 및 제어를 개발
· 환경, 서버, 데스크톱 및 응용 프로그램 레벨단에 적합한 "심도 있는 방어" 방식을 개발하여 보안적인 위험 부담을 감소
· 다양한 수작업 및 시간 소모성 작업을 자동화
· "최적의 실례(best practices)"(ITIL, SANS, 등등)에 입각하여 구성
· IT 자체가 가진 전략적 가치 커지도록 만들 수 있도록 도전



Level 2. 표준화 단계(Standardized)
표준화 된 인프라스트럭처는 표준화된 사용과 데스크톱과 서버를 관리하는 정책, 컴퓨터들을 네트워크에 어떻게 참여시킬 것인지, 보안 정책, 접근 제어 및 자원 관리에 Active Directory를 이용함으로써 제어를 시작할 수 있습니다. 표준화 단계의 고객들은 기초적인 표준의 가치 오와, 몇가지 정책들은 여전히 문제를 야기하게 될 것이라는 것을 알게 됩니다. 일반적으로 모든 패치, 소프트웨어 배포 및 데스크톱 서비스들을 하는데 있어 중간 정도의 수작업과 중상의 비용이 드는 것을 알 수 있습니다. 하지만, 확실한 하드웨어 및 소프트웨어 목록과 라이센스 관리가 제대로 되는 것을 아실 수 있을 것입니다. 그러나, 보안에서는 다운되는 문제들에 대해 어느정도 해소되는 것을 알 수 있지만, 내부적인 보안 문제는 여전히 있다는 것입니다.
고객들이 이 표준화 단계에서 전체 인프라 스트럭처를 효과적으로 제어하고, 혁신적인 정책과 처리 방법을 갖춘 합리적 단계로 이전함으로써 각종 재난에서 부터 업무 기회 획득까지 모든 환경적 영역에 대한 준비를 갖출 수 있게 됩니다.
서비스 관리(Service Management)란 서비스는 하나의 개념으로써, 조직에서 이 부분을 구체화 할 방법을 이야기하게 됩니다. 그리고 기술(Technology)는 가중되는 짐을 보다 업무적인 자산과 기타 기회로서 발전할 수 있도록 해주는 합리적 단계 인프라 스트럭처로 전환 될 수 있도록 해주는 하나의 중요한 시발점이 됩니다.

Level 3. 합리적 단계(Rationalized)
합리적 단계 인프라스트럭처란 최저 비용으로 데스크톱 및 서버들 관리를 하는 것을 포함해 처리 방법 및 정책이 보다 업무에 적극적으로 지원하고 확장할 수 있도록 해주는 중요한 역항를 수행할 수 있을 만큼 성숙된 형태를 의미합니다. 보안에서는 매우 혁신적이며 악의적인 공격에 대한 반응이 매우 빠르고 철저하게 제어된 상태에서 동작하게 됩니다.
또한 Zero Touch 배포 방법을 사용하여 최소의 비용, 시간으로 배포와 기술적 대응을 수행하게 됩니다. 또한 표준 이미지 수가 최소화가 되며, 데스크톱 관리에 대한 처리 방법이 최소의 수작업으로 처리할 수 있게 됩니다. 또한 H/W 및 S/W의 자원에 대한 목록이 명확하게 나와, 현재 또는 이후에 필요한 각 라이센스 및 자원들의 양을 파악 할 수 있어 비용적인 낭비를 최소화 할 수 있게 됩니다.
보안에서는 데스크톱에서 서버로, 그리고 방화벽으로, 외부 망으로 진행되는 전체 사항을 제어하고, 강제적인 정책으로 최적 효율을 가져올 수 있습니다.
또한 고객들은 이 합리적인 단계 상태에서 동적(Dynamic) 단계 상태로 그 수준을 높여 업무적 단계에서 새로운 이익을 얻으실 수 있습니다. 새로운 가치를 대략적으로 설명드리면, 새롭거나 관련된 기술을 통해 새로운 영역의 업무를 도전하거나 기회 획득을 하기 위한 기타 추가 비용에 따른 부담을 확실하게 덜어 드린다는 것입니다. 서비스 관리(Service Management)에서는 IT를 통해 보다 넓은 범위의 구체화 시킬 수 있는 조직의 진행 단계를 최소화된 서비스만으로 구성할 수 있게 됩니다. 고객들이 동적 단계 상태의 가치에서 원하는 사항은 업무에 보다 도움을 주는 IT 인프라스트럭처를 찾는 것입니다.

Level 4. 동적 단계(Dynamic)
동적 단계 인프라 스트럭처를 갖춘 고객들은 IT를 이용해 업무적 효율 강화 및 경쟁사의 앞에서 진행될 수 있는 완벽한 전략적 가치를 제공 받으실 수 있습니다. 비용은 완벽하게 제어되고, 사용자와 데이터, 데스크톱, 서버들이 통합되며, 사용자와 부서간의 협업 작업이 원할하게 진행되고, 원격 사용자(모바일 사용자)들은 위치와 관계 없이 모든 서비스와 역량들 한자리에서 발휘 할 수 있게 됩니다.
업무들은 완전 자동화가 되어, 업무의 필요성에 따른 관리 및 재정리를 하여, 현재 IT에 맞추어 기술 자체가 스스로 통합되는 형태를 갖추게 됩니다.  기술적인 추가 투자가 보다 자세히, 빠르게, 구체적으로 업무의 이익으로써 돌아오게 됩니다.
셀프 프로비저닝 소프트웨어 및 패치 관리를 위한 자체 차단 시스템, 보안 정책을 확실하게 정착시키는 기능들을 활용하여, 서비스 단계를 향상시키고, 비용을 절감하며, 활용도를 증대시키고 업무를 완전 자동화 하여,  조직을 보다 능동적으로 만들어 드립니다.  고객은 이 동적 인프라스트럭처의 범위를 넓혀 감으로써, 점차 높은 단계의 서비스를 제공받게 되며, 보다 큰 규모의 업무에 집중할 수 있게 됩니다. 서비스 관리(Service Management)는 서비스 단계 규약서 및 구축된 서비스 운영에 관한 지침을 갖춘 모든 핵심 서비스들이 구축되게되게 됩니다.

728x90

+ Recent posts

728x90

티스토리툴바