IBM®
메인 컨텐츠로 가기
    Korea [국가변경]    이용약관
 
 
   
        제품    서비스 & 솔루션    고객지원 & 다운로드    회원 서비스    
메인 컨텐츠로 가기

한국 developerWorks  >  Architecture  >

전사적 아키텍처의 핵심, Part 3: 전사적 아키텍처 설계와 구현

전사적 아키텍처 프로젝트를 시작하자

developerWorks
문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

토론

영어원문

영어원문


제안 및 의견
피드백

난이도 : 초급

Michael Welsh, 자유기고가, Ronin Writer

옮긴이: 박재호 이해영 dwkorea@kr.ibm.com

2008 년 7 월 22 일

위대한 IT 아키텍처 구현에는 시간과 계획이 필요합니다. 이미 존재하는 시스템을 평가하고, 이뤄져야 하는 목표를 시각화하는 방법으로 위대한 전사적 아키텍처를 현실로 만들 수 있습니다. 꿈에 그리는 아키텍처를 달성하려면, 이 기사에서 설명하듯이 무엇을 만들고 어떻게 만들고 어떤 플랫폼에서 만들지 배워야 합니다.

이 기사에서는 무엇을 만들고 어떻게 만들지를 설명한다.깨끗한 환경에서 IT 아키텍트로 일할만큼 운이 좋지 않다고 가정해보자. 여러분은 처음부터 전사적 IT 아키텍처를 구축해야 하는 조직에 있다. 대다수 IT 아키텍트와 마찬가지로, 여러분은 좋은 측면에서 완벽과 거리를 둔 현재 환경에서 시스템을 구축해야 한다. 아마도 여러분 기업은 작은 IT 인력에서 시작해 옛날 서버로 가득찬 혼잡한 데이터 센터로 발전해왔을 것이다. 아니면, 여러분 조직이 흡수한 여러 작은 회사의 IT 부서를 통합해야 할지도 모른다. 지금이 바로 현재 자원을 파악해 정보 흐름을 원활하게 만들 시점이다.

IT 아키텍트에게는 설계와 구현이 전사적 아키텍처 중에서 가장 쉬운 단계로 보인다. 이런 단순한 시각은 물리적인 결과에서 기인한다. 여기저기 놓인 서버, 웅웅거리며 돌아가는 팬 소리, 점멸하는 LED 불빛. 새로운 장난감이 전산실에 들어오는 순간은 뿌듯할지 모르겠지만, 앞으로 해야 할 일이 많다. IT 아키텍트는 프로그램 관리자, 리더, 외교관, 컨텐트 전문가로 변신하는 만능 선수다. 성공적인 전사적 조직을 구축하는 작업은 회사의 모든 분야에서 협력을 요구하며, 프로젝트 막바지에는 여러 분야에서 경기를 펼쳐야 한다.

구현과 설계: 무엇을 만들어야 하나?

수작업으로 "인쇄해서 선별하는" 방법을 벗어나 RFID나 무선 바코드 시스템으로 바꾸려는 창고를 생각해보자. 주문 시스템은 콜 센터에서 IBM® WebSphere® 응용 프로그램으로 이동한다. 뒷단 시스템은 IBM AS/400® 플랫폼으로 남아있지만, 창고 터미널 상당수는 무선 단말기로 대체될 것이다. 따라서 제품을 고객에게 전달한다는 주요 비즈니스 목표는 바뀌지 않지만, 주문을 수집하고 처리하는 방법은 바뀔 것이다. 이런 프로젝트는 직관적으로 보일지 몰라도, IT 아키텍트 입장에서 전체 그림을 살펴야만 한다. 창고 직원에게 미치는 영향은 명백하며, 비즈니스 운영에도 급격한 변화가 생긴다.

기술과 역량

새로운 계획을 세우기 앞서, 현재 환경을 평가해야만 한다. 대규모 다국적 기업에서 일하든 가족 기업에서 일하든 IT 세상에는 여러분이 반드시 인식해야 하는 여러 가지 함정이 있기 마련이다. 신중하게 평가하지 않는다면 어떤 문제가 존재하는지 어떻게 알 수 있겠는가?

물리적인 환경부터 살펴보자. IBM Information Server와 같은 올바른 도구를 사용해 물리적인 장비 대다수를 찾을 수 있다. 또한 공간과 위치를 고려하자. 여러 사이트에서 특정 위치를 다룰 수 있는가? 네트워크 설정은 어떻게 되어 있는가? 옛날 장비를 다루는가? 확장에 필요한 충분한 공간이 있는가? 새로운 장비가 미칠 영향을 전반적으로 고려하자. 전기, 열, 네트워크 자원은 성장 공식의 일부가 되어야 한다. 특히 여러 사이트를 다루고 있을 때 네트워크 대역폭을 간과하지 말자.

다음으로 현존하는 다양한 플랫폼을 평가하자. 이런 과정에서, 마이크로소프트 윈도우(Microsoft® Windows®), 리눅스(Linux®), AS/400은 물론이고, 심지어 마이크로소프트 윈도우 NT®나 IBM OS2®와 같은 옛날 플랫폼도 섞여 있음을 알게 될지도 모른다. 조직이 보유하는 데이터베이스 유형도 파악하자. 현재 새로운 아키텍처에서 자료를 공유하지 못하는 다양한 데이터베이스를 이전할 필요가 있을지도 모른다.

마지막으로 비즈니스 모델과 자료 흐름을 검토하자. 자료가 어떻게 생기며, 어디서/어떻게 처리되며, 결과는 무엇인지 이해하자. 비즈니스가 어떻게 운영되는지 완벽하게 검토하면 효율성을 높일 수 있으며, 더 중요한 장점으로 작업을 시작할 때 혼란을 방지한다.

서버와 네트워크 활용도 역시 중요하다. 몇몇 서버 관리자는 "서버 하나에 기능 하나"라는 방식을 선호하므로, 단일 서버에서 단일 응용 프로그램을 돌린다. 이런 방법이 논리적인 접근법으로 생각되는 이유는 서버가 실패할 경우에도 단지 응용 프로그램 하나만 장애를 일으키기 때문이다. 반면에 이런 방법을 사용하면 자원이 제대로 쓰이지 못하고 낭비된다는 단점이 있다. 대안으로 여러 응용 프로그램을 단일 서버에 탑재해 조직이 TCO를 완벽하게 활용하도록 만드는 방법도 있다. 하지만 이런 방법은 실패 가능성을 높인다. 네트워크 문제, 메모리 누수는 여러 응용 프로그램 성능에 영향을 미치기 때문이다. 유지보수를 위해 서버를 내리면 서비스 중인 응용 프로그램을 방해하며, 비즈니스에 광범위한 영향을 미치게 된다.

현재 사용 가능한 물리적인 자원에서 벗어나 전사적인 아키텍처 성공을 위해 필요한 인적 자원도 고려해야 한다. 예를 들어, 새로운 응용 프로그램을 개발하려면 프로그래머가 필요하다. 이런 응용 프로그램은 사용자 지원을 요구한다. 기술자는 원격에서 처리하지 못하는 문제를 파악하는 데 투입된다. 인적 요소를 판단하기가 더욱 어려운 이유는 과거에 성공한 경우와 실패한 경우라는 두 가지 원칙에 따라 자료가 만들어지기 때문이다. 이런 판단이 정말로 도움이 되지 않을지도 모르지만, 수정 구슬에서 미래를 보거나 예언자를 고용하지 못하는 상황에서 여러분은 과거에서 끊임없이 배우는 태도를 견지해야 한다. 유연하게 작업하자. 교차 훈련은 혼잡한 상황에서 우리를 구해준다. 새로운 아키텍처를 현장에 투입하더라도 현존하는 시스템과 응용 프로그램을 계속해서 지원해야 한다. 이런 과정은 인적 자원을 최대한 활용하는 과정에서 중요한 역할을 한다.

도구와 기술

표준은 모든 업무의 기준이다. 새로운 IT 아키텍처를 만들기 시작할 때 좋은 표준을 확보하면 진행 중에 벌어지는 격차를 줄이고 변화가 필요할 때마다 처음부터 출발할 필요가 없게 된다. 표준 활용은 기업에서 일관성을 보장하므로, 배포를 단순화하며 지원을 촉진한다.

사용가능한 여러 IT 아키텍처 표준이 존재한다. 가장 인기 있는 프레임워크는 TOGAF(The Open Group Architecture Framework)다. 이 프레임워크 내부에서 사용하는 표준은 경험을 통해 증명되었다.

표준을 선택할 때, 조직이 속한 산업계를 고려해야 한다는 사실을 기억하자. 의료, 재정, 신용카드 회사는 독자적인 표준을 구축해 IT 환경 운영 방법에 영향을 미친다. 좋은 소식은 이런 산업계에 밀접한 대다수 표준은 상식적인 IT 관례를 따르며, TOGAF에 포함되어 있다는 사실이다.

다음 참고 자료 목록은 여러분의 표준 수립을 도와줄 것이다.

중간 목표

계획 전 단계에서 중간 목표를 만들어 놓으면 추가 자원을 투입할 때 명확한 근거를 제시하도록 도와준다.

  • 목표를 정하자. 무엇을 언제 달성할지 계획을 세우고 결과가 어떤 식으로 나타날지 지침을 확립하자. 이렇게 프로젝트에 참여한 모든 사람을 위한 명백한 목표를 세우면 모든 사람은 자신에게 기대하는 바가 무엇인지 알게 된다. 자신의 분야에서 최선을 다하도록 팀을 구축하자.
  • 요구 사항을 결정하자. 하드웨어, 소프트웨어, 네트워크 전문가가 필요하다. 자동화한 도구는 여러 소프트웨어 업체나 오픈 소스 소프트웨어 채널을 통해 확보할 수 있다.
  • 표준을 정립하자. 표준을 이해하고 이를 고수하자! 팀이 따라야 할 표준을 선택해서 IT 부서가 업계 시각에서 무엇을 요구하는지 살펴보자. 자료 보안, 보존, 관리는 프로그래밍 관례는 물론이고 표준 관련 토론의 일부가 될 것이다.
  • 나 자신을 알자. 1980년대 G.I. 조라는 만화 연재에서 끝에 나오는 말이 있다. "그리고 전투에서 나를 알면 절반은 이기고 들어가는 거야!" 지금도 마찬가지다. 이미 무엇이 존재하는지 정확하게 알고 있다면 현존하는 시스템을 최대로 이용해 비용을 줄일 것이다.
  • 외부 서비스가 필요한지 결정하자. 외부 그룹에게 감사를 맡기는 편이 의미가 있을지도 모른다. 전문적인 감사 그룹은 모든 자원을 찾아내어 올바른 질문을 던지는 작업을 통해 감사 작업을 진행할 수 있다. 세부적인 평가를 수행하기 위해 적절한 도구가 현재 갖춰져 있지 않을 경우에 특히 외부 서비스가 유용하다.
  • 역할을 할당하자. 가장 잘 맞는 팀원에게 과업을 위임한 다음 풀어주자.
  • 문서를 유지하자. 이 단계를 시작하기 전에 문서를 만들지 않았다면, 지금이 바로 시작할 시간이다. 운영 절차, 코드 변경, 고객 지원 센터 절차를 수집하자. 팀원이 자리값을 하기 위해 문서화를 해야 할 좋은 시점이다.



위로


구현 기법: 어떻게 만드나?

이제 IT 환경에 대한 완벽한 지도를 확보했으니, 전사적 아키텍처를 만드는 과정에서 이를 활용하자.

기술과 역량

전체 IT 그림을 머리 속에 넣고서 정보가 어디서 시작해 어디서 끝나는지 지도를 그리자. 다이어그램을 그리고 자료 흐름을 기술하는 방법으로 비즈니스 흐름의 약점과 강점을 찾아낼 수 있다. 그림 한 장이 백마디 말보다 좋다는 속담은 사실이며, 다이어그램은 관리자와 문제점을 토론하는 과정에서 단일 실패 지점과 여타 약점을 가장 잘 드러낸다.

비즈니스 모델에서 복잡한 사정을 알고 있다면, 여러분 무기고에서 가장 강력한 무기로 활용할 수 있다. 전기나 냉방 요구와 같은 비 IT 분야를 평가하기 위해 전문가 도움을 요청하자. 서버와 응용 프로그램 전문가는 여러분이 수집한 자료를 바탕으로 건전한 충고를 줄 수 있어야 한다. IT는 조직의 모든 분야에 영향을 미치므로 여러분이 보유한 프로젝트 관리 기술은 날이 서 있어야 한다. 변화를 이루기 위해 부서 관리자는 충고에 귀를 기울어야 하며, 피드백을 제공할 수 있어야 한다.

새로운 아키텍처를 만들어 나가는 과정에서 현재 시점은 중복을 집어넣고 효율성을 높이기 위한 이상적인 기회를 제공한다. 재해 복구 옵션을 모든 단계에서 검토하자. 예를 들어, 자연 재해로 인해 설비가 중단되었을 때, 조직이 생산 라인을 전환할 수 있나? 중복을 위한 외부 자료 센터 활용을 고려하자. 많은 자료 센터가 서비스, 공간 활용을 기반으로 유연성을 제공한다.

자료는 조직에 너무나도 중요하기에, 자료 저장 방법과 접근 권한 부여가 중요하다. 얼마나 많은 자료를 처리하나? 물리적으로 어떻게 저장되나? 하드웨어 자산을 점검해 남은 저장소 공간을 확인해서 추가 방법을 선택하자. 서버 운영진과 함께 전통적인 서버 저장소와 비교해 SAN(Storage Area Network)이 주는 장점을 토론하자. 여러 작은 데이터베이스를 튼튼한 SQL 환경으로 이주할 시점일지도 모른다.

도구와 기술

SAN에서 SQL 데이터베이스를 만들기 위해 도움이 필요하거나 최신 하드웨어 변경 내역을 구현하는 방법을 알아야 할 경우 IBM에서 충분한 지원을 받을 수 있다.

중간 목표

단순한 중간 목표는 설계 계획을 구현하기 시작할 때 궤도에서 벗어나지 않도록 도와준다. 아키텍트로서 각자 아이디어가 있는 반면에, 팀에서 취합한 의견도 필요하다. 다음에 시작 과정에서 도움을 주는 몇 가지 사항을 정리했다.

  • 중간 목표를 확립하자. 비즈니스 세부 사항을 익히자. 부서 운영 방법과 전체 조직에 미치는 영향을 이해하기 위한 목표와 기한을 정하자. 예를 들어, 회계에 문제가 생기면, 고객은 영수증을 받지 못하며, 직원은 월급을 받지 못한다.
  • 표준을 유지하자. 합의가 끝난 표준을 유지하고, 제대로 지켜지는지 확인하자.
  • 예산과 비용을 추적하자. 현존하는 환경에 대한 사실과 계산을 바탕으로 새로운 전사적 아키텍처를 만드는 데 있어 비용을 추정하자. 하드웨어, 소프트웨어, 컨설팅 비용이 중요하다. 하지만 또한 직원 시간도 여기에 포함해야 한다는 사실을 기억하자. 추가 근무와 초과 수당을 고려하고 교육 예산을 포함했는지 확인하자.
  • 소프트웨어와 하드웨어 업쳬 목록을 유지하자. 가격 예측은 물론이고 여러분이 찾고 있는 장비를 어디서 구할지 확인하는 과정에 도움을 준다.
  • 필요하다면 외부에 도움을 청한다. 외부에 도움을 요청할 필요가 있을까? 새로운 응용 프로그램을 구축하기 위해 개발자들을 참여시키거나 개발 단계 중간에 기술자가 호출에 답하는 만큼이나 단순하게 외부에 도움을 요청할 수 있다. 이제 각 개인의 작업과 업무 부하를 이해했기에, 컨설팅 서비스가 부족한 간극을 채워준다.
  • 임무를 할당한다. 전문가를 투입해 업체를 부르고 네트워크 부하를 테스트하는 작업을 진행하게 만든다.
  • 절차를 문서화하자. 심지어 어떻게 돌아가는지 100% 확신하지 못할지라도 생각을 문서화하자. 종이에 꿈을 그리면 여러분과 여러분 팀이 새로운 해법을 생각하도록 분발하게 만들어준다. 구체적인 견적서를 수집하고 예산 초안을 만들자. 모든 견적서를 한 곳에 모으고, 최고로 좋은 가격을 찾기 위해 스프레드시트에 목록을 나열해 비교하자. 동적인 환경에서 작업하고 있기에, 완전히 파악을 끝내기 전에 일어날 변경 내역을 문서화하자.



위로


플랫폼 선택: 어디에서 구축해야 하나?

자료 흐름을 이해하고 표준을 정립했다면 계획을 세울 차례다. 이제 구축할 플랫폼을 결정할 시간이다. 옛날 시스템은 사용할 플랫폼 종류와 자료 전달 방식을 결정하는 데 한 몫할지도 모른다.

기술과 역량

직원들이 익숙한 플랫폼에 머무는 편이 가장 쉽지만 성장은 노력을 필요로 한다. 예를 들어, 윈도우 환경에서 리눅스 환경으로 이전하는 작업은 지원 인력을 교육하는 비용을 고려하기 전까지는 얼핏 보기에 비용을 절약하는 듯이 보일지도 모른다.

여러분과 팀이 운영체제를 결정했다면 응용 프로그램을 결정하자. 공통적인 기성품 소프트웨어나 업계에 밀접한 제품이나 직접 작성한 응용 프로그램이나 상관없이 새로운 전사적 아키텍처에서 어떻게 동작하는지 파악하자. 이런 토론은 플랫폼을 고려할 당시에 진행해야 한다. 몇몇 프로그램은 플랫폼에 밀접하기 때문이다.

도구와 기술

하드웨어와 소프트웨어 표준화는 여러 업체가 관여하는 데이터센터에서 발생하는 많은 문제를 없애는 데 도움을 준다. 드라이브 고장과 같은 문제가 발생하면, 전화 번호 하나만 기억하면 끝이다.

인적 요소를 살펴서, 변경이 불러 일으킬 영향을 고려하자. 프로그래머와 관리자에게 교육 과정을 제공할 필요가 있을까? 예를 들어, 웹 응용 프로그램을 특정 언어에서 다른 언어로 다시 쓸 때 개발자를 위한 재교육 과정이 필요할지도 모른다. 윈도우 왕국을 떠나 리눅스 왕국으로 들어가면 시스템 관리자 사이에서 전문적인 지식이 부족해질지도 모른다. 새로운 인력을 모집할 필요가 있는가?

학습 자원

IBM에서 제공하는 다음 자원을 고려하자.

중간 목표

하드웨어와 운영체제 방향을 결정하는 작업은 팀에서 의견 수렴을 필요로 한다. 현존하는 하드웨어에서 플랫폼을 변경한다면 지원팀이 새로운 설정 환경에 익숙함을 느끼게 만들도록 교육 서비스를 진행할 필요가 있을지도 모른다. 다음 사항을 고려하자.

  • 중간 목표를 확립하자. 꿈을 현실로 바꾸도록 만드는 다른 기술이 제공하는 장점을 익히자. 업체와 날짜를 잡아 팀과 더불어 플랫폼 옵션에 대해 토론하자.
  • 자원을 놓고 의사소통하자. 계속해서 관리자, 참모, 사용자, 업체와 접촉하자.
  • 예산과 비용을 추적하자. 업체와 함께 작업해 하드웨어와 소프트웨어 가격을 파악하고 숫자를 추가하기 시작하자. 추가적인 배송, 설치, 유지보수 비용을 계산하는 절차를 잊지 말자.
  • 외부 서비스가 필요한지 결정하자. 다양한 플랫폼을 통합할지 아니면 익숙하지 않은 환경에 뛰어들지를 놓고 전문가 충고를 요청하는 방법이 아주 바람직하다.
  • 임무를 할당하자. 새로운 하드웨어와 소프트웨어를 적절한 그룹에 분산하도록 준비하면서, 의사소통을 계속한다.
  • 절차를 문서화하자. 지금쯤이면 여러분이 무엇을 보유하고 있고, 무엇을 원하고, 어떻게 함께 일할지 알고 있다. 앞으로 전진하면서 여러분과 여러분 팀이 수행한 작업을 문서화하자. IT 아키텍처 인증을 추구한다면 특히 중요하다.



위로


정리

새로운 기업을 지원할 플랫폼은 견고하고, 튼튼하고, 성장과 변경 가능성에 대응해야 한다. 계획과 의사소통은 IT 기초를 공고히 만들 회반죽이다. 조직이 원하는 바를 알고 필요한 바를 들으면 프로젝트 나머지를 쉽게 진행하도록 도와주는 어려운 작업을 끝낼 수 있다. 각 조각을 어떻게 연결할지 주의깊게 고려하려면 단순히 기술뿐만 아니라 이를 지원하는 조직과 사람에 대한 시간과 지식이 필요하다. 새로운 플랫폼에 대한 윤곽을 그리고, 현존하는 환경에서 넘어갈 다리를 만드는 방법으로 기업에 엄청난 영향을 미치지 않고서도 변화를 이뤄낼 수 있다. IT 기반 구조를 다져서 튼튼한 기반을 구축하는 작업은 성공을 보증한다.



참고자료

교육

제품 및 기술 얻기
  • IBM 제품 평가판을 내려받아서 DB2®, Lotus®, Rational®, Tivoli®, WebSphere® 같은 응용 프로그램 개발 도구와 미들웨어 제품군에 친숙해지자.


토론


필자소개

Michael Welsh는 IT 보안, 재해 복구, 네트워크 분야를 책임지는 IT 전문가로 15년간 일해왔다. 또한 운영체계, 하드웨어, Microsoft Exchange Server 같은 많은 서버사이드 애플리케이션에 지식을 가지고 있다. Michael은 웹 사이트와 비즈니스에 대한 기술 문서를 집필하고 있다.




기사에 대한 평가


보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오.



 


 


 


이 문서 북마킹 하기

mar.gar.in mar.gar.in naver naver eolin eolin del.icio.us del.icio.us





위로


IBM, AS/400, DB2, Lotus, OS2, Rational, Tivoli, and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries, or both. Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. 기타 회사, 제품, 및 서비스명은 다른 상표나 서비스 마크일 수 있습니다.

developerWorks 콘텐트를 다른 사이트에 전재하기:
developerWorks 콘텐트에 대한 저작권은 IBM에 있습니다. IBM의 서면 허가나 원본 저자의 허락이 없이는 전재를 금합니다. 저희 콘텐트를 전재하시려면 IBM developerWorks 담당자 에게 문의하십시오.
    IBM 소개 개인정보 보호정책 문의