 |
|
난이도 : 중급 Michael Welsh, 자유기고가, Ronin Writer
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 8 월 05 일 새로운 전사적인 IT 아키텍처를 성공리에 구축한 다음에는 테스트를 해야 합니다. 테스트는 여러분과 여러분 팀이 실제로 아키텍처가 동작하도록 쏟아부은 노력을 검증하는 작업입니다. 새로운 아키텍처에 부하를 주는 방법으로 약점이 어디에 있는지 찾아내고 회사에 어떤 식으로 도움을 줄지 살펴봅시다.
이제 전사적 아키텍처를 구축했으므로 테스트를 해야 한다. 새로운 기술, 특히 최첨단 기술이라면 동작을 하기 위해 묘안이 필요하다. IT 아키텍처 테스트는 포괄적인 작업이다. 테스트는 하드웨어, 응용 프로그램은 물론이고 시스템을 책임진 사람도 포함해야 한다.
테스트는 시스템을 망가뜨린 다음에 보수를 받는 훌륭한 방법이다. 어느 누구도 IT 시스템이 망가지기를 원하지 않지만, 이렇게 될 확률은 존재한다. 일반적인 실패를 테스트함으로써, 시스템 중복에 들어가는 추가 비용을 정당화할 수 있다. 테스트 과정을 거치는 동안 의사 소통은 필수다. 테스트는 사용자에게 가능한 문제에 대해 주의를 주며, 문제가 일어났을 때 무엇을 해야 할지 알려줌으로써 프로젝트와 팀원이 확신을 품도록 돕는다.
준비
아키텍처 테스트를 준비할 때, 먼저 무엇을 테스트해야 할지 결정해야 한다. CRT 모니터를 평판 화면으로 교체하는 작업은 확실히 엄격한 테스트를 요구하지 않는다. 하지만 새로운 광통신 백본에 물린 새로운 응용 프로그램과 하드웨어라면 부하를 걸어 테스트해야만 한다. IT 팀과 회의를 통해 테스트에 들어갈 최적 기간이 어느 정도인지 결정하자.
테스트에는 세 가지 기능이 있다. 새로운 응용 프로그램이 운영 환경에서 동작할지를 확인해주고, 중복 기능이 실패 상태에서 제대로 돌지를 검증해주며, 팀원이 문제에 얼마나 잘 대응하는지 확인해준다. 응용 프로그램 테스트는 다소 직관적이지만 혹독한 과정이다. 응용 프로그램은 반드시 테스트해야 하는 자그마한 기능을 수백 개 넘게 포함한다. 예를 들어, 회계 프로그램은 몇몇 세금 관련 작업을 월말에 수행해야 하며, 또 다른 몇몇 세금 관련 작업은 연말에만 수행하면 된다. 세무서에서 사람이 나오기 전에 이런 기능이 제대로 동작하는지 확인해야 한다.
기술과 역량
테스트 전에 전체 기업을 앞뒤, 모든 각도에서 살펴보자. 강점과 약점을 파악하자. 전체 회사 평가를 확실하게 진행해 어떤 시스템이 가장 포괄적인 테스트를 필요로 하는지 확인한다. 가능하다면, 운영 환경이 아닌 다른 환경에서 테스트해야 한다. 테스트 과정에 운영 환경이 개입되어야 한다면, 관리자에게 테스트 필요성과 살아있는 시스템에 영향을 미치는 이유, 적절한 작업 중단 일정을 설명한다. 또한 테스트를 위해 동작 중인 시스템을 백업하는 시스템이 있는지 확인한다. 가상 서버를 복구해서 살아있는 시스템과 자료 집합을 비교하는 방법으로 백업 시스템을 확인한다.
가상 환경
가상 시스템을 활용해 테스트 환경 구축을 단순화하자. 가상 시스템은 쉽게 설정하고, 쉽게 망가뜨리고, 쉽게 복구할 수 있다. 표준 서버를 하나 만들어 이를 다른 서버로 복제하자. 새로운 응용 프로그램을 설치하면, 여러 가상 PC 프로그램이 현재 상태를 스냅샷으로 잡도록 허용하므로 실패 다음에 수행할 복구 작업을 쉽게 만든다. 가상 환경의 장점은 몇 시간이 아니라 몇 분 안에 새로운 서버를 생성해내는 편의성에 있다.
VMware는 전용 가상 환경을 구축하기 위해 다양한 제품군을 제공한다. 기본 운영체제를 필요로 하지 않는 전용 가상 기계(VM)를 선택할 수 있으며, 여러 서버를 한번에 돌릴 수도 있다. VMware를 사용할 경우에 여러 운영체제를 동시에 돌릴 수 있으며, 환경 설정이 쉬우며, 테스트 도구가 따라온다는 큰 이익을 얻는다.
새로운 환경을 테스트하고 시스템 대체 시나리오를 검증하기 위해 몇몇 네트워크 시뮬레이터도 시중에 나와 있다. 대부분 인증 테스트를 준비하기 위해 설계되었지만, 이런 장비는 실제 하드웨어를 구입하기 위해 들이는 비용보다 상대적으로 저렴한 비용에 가상 서버 환경을 구축해주는 장점을 제공한다.
점검 항목과 작업 인원 준비
새로운 전사적 아키텍처 출시 준비가 끝나면, 핵심 시스템 점검 목록, 테스트가 필요한 백업 시스템 목록을 만들자. 핵심 시스템은 팀이 유지할 문서에서 명확하게 드러나야 한다. 핵심 시스템은 조직 존재 유무가 걸린 하드웨어와 소프트웨어다. 종종 이런 시스템은 중요 업무 서버, 네트워크 백본, 전자편지와 통화 시스템과 같은 메시징 시스템을 포함한다. 그림 1을 살펴보자.
그림 1. 핵심 시스템
이 그림은 완벽한 네트워크 구성도에 나오는 세부 내역이 빠져 있다. 그 대신 비즈니스 운영에 가장 중요한 전사적 구성 요소에 초점을 맞춘다.
새로운 시스템에서 발생할지도 모르는 질문과 쟁점을 다룰 지원 인력과 사용자를 준비해 놓으면 상담 창구 호출을 줄일 수 있다. 팀원은 응용 프로그램의 비정상 중지처럼 이미 인지하고 있는 문제 목록을 취합하며, 알려진 버그 수정 목록을 만들어야 한다.
테스트를 언제 수행할지 결정하는 작업이 가장 어렵다. 하루 중 모든 사람이 작업하는 시간을 찾기란 어려우므로 일과 후 몇 시간이 가장 적합하다. 하지만, 팀원이 자기 작업 이외에 초과 작업을 원하지 않거나 상사가 연장 근무 수당을 지급하지 않으려는 저항에 부딪힐 가능성도 있다. 사람들이 언제 테스트가 필요하며, 이런 작업을 하는 시간이 언제가 좋을지를 결정하는 과정에서 균형을 잘 잡아야 한다. 다른 팀원에게 "호출하면 뛰어오도록" 부탁해 놓고 필요할 때마다 요청하는 방법도 있다.
이 시점에서, 이미 새로운 아키텍처를 위한 표준 준수 항목을 선별했을 것이다. 실패에 대한 몇 가지 구체적인 항목은 운영 환경에서 동작하기 앞서 반드시 테스트를 마쳐야 한다. 방화벽이나 보안 응용 프로그램 구성 요소는 살아있는 시스템에 투입하기에 앞서 검증이 필요하다.
무엇을 테스트해야 하며, 어떻게 테스트를 진행할지 구체적인 점검 목록을 만들자. 추가 점검 목록은 다음 내용을 포함한다.
- 테스트 전후에 보여야 할 자료 화면 캡처
- 구체적인 과업 목록 분리
- 과업을 수행하기 위해 그룹으로 나뉜 점검 목록. 몇몇 하드웨어는 응용 프로그램을 올려서 설정하는 사람들이 다른 그룹에 속할지도 모른다.
문서 절차
테스트는 문서화 작업을 이끈다. 새로운 IT 아키텍처를 도입할 때 날마다 부딪히는 일이다.
최소한 역사 관점, 절차 관점, 재난 복구 관점이라는 세 가지 문서 유형을 확보해야 한다. 역사 문서인 첫 유형은 아키텍처에서 모든 구성 요소 세부 내역을 어떻게 만들었는지를 포함해야 한다. 이 문서는 작업 흐름을 나타내는 도표와 어떻게 각 구성 요소가 조각조각 연결되어 있는지를 알려주는 노트를 포함해야 한다. 아키텍처가 발전함에 따라 세부 사항은 잊혀진다. 예를 들어, 월급 소프트웨어가 물품 창고 데이터베이스에 연결되는 사실을 설명하는 문서가 필요한 이유는 주문을 제 때 처리한 사람에게 정확도에 따라 상여금을 주기 때문이다(그림 2 참조). 이런 설정은 물품 창고 데이터베이스에는 드러나지 않으므로, 변경을 가하기 앞서 물품 창고 데이터베이스 관리자(DBA)는 이런 연결 관계를 인식하고 있어야 한다.
그림 2. 물품 창고 무선 그림
절차 문서는 일간, 주간, 월간 과업에 대한 점검 목록을 포함한다. 예는 일별 테이프 백업 변경 절차, 로그 점검, 문제 보고를 포함한다. 몇몇 시스템은 효율적인 운영을 계속 진행하기 위해 정기 유지보수를 요구한다. 일일 절차는 특정 사람이나 그룹에게 해당 분야에 책임을 주는 방법으로 수행한다. 과업 수행에 따른 세부 단계는 과업을 올바르게 정시에 수행했는지를 확인할 뿐만 아니라 다른 사람을 대신할 인력을 도와준다. 절차는 일반적인 오류와 수정 방법은 물론이고 새로운 하드웨어나 응용 프로그램을 전사적인 환경에 도입할 경우 필요한 표준 설정 절차를 포함해야 한다. 이런 과업은 여러 그룹이 수행하므로 각 그룹마다 해당 문서를 제공해야 한다. 그림 3과 같은 문서 흐름도는 각 그룹이 책임진 사항과 필수 요건을 나열하는 데 도움을 준다.
그림 3. 서버 설정 문서 흐름
흔하지 않는 오류에 대해서는 재난 복구 문서를 만들어야 한다. 재난 복구라는 특수한 문서는 역사적인 문서와 일일 절차를 조합한 형태다. 재난마다 별도로 계획을 세우지는 못하지만, 재난 절차마다 중복되는 내용이 많다. 서버 시작과 같은 간단한 작업 절차를 문서로 적어 놓으면 처음에는 별 것 아닌 듯이 보이지만, 재난 복구 시나리오를 테스트할 때 확신을 심어준다. 예상하지 못했던 일이 벌어지면, 지원 팀 사이에 겁에 질린 분위기가 퍼지는 경우를 흔히 볼 수 있다. 반응하지 않는 서버 기반 응용 프로그램과 관련해서 물밀듯 들어오는 상담 창구 전화에 긴장이 감돈다. 상식선에서 세부 사항을 포함한 훌륭한 문서가 도움이 되는 이유는 문제 해결에 투입된 작업 인력이 서버를 재시작하면 다른 시스템에 영향을 미치리라는 사실을 잊어버리고 있을지도 모르기 때문이다.
재난 복구를 위한 문서 절차는 또한 재난이 언제 시작하고 언제 해결되었는지, 누구에게 알려줘야 하는지를 포함해야 한다. 운영진은 팀장, 부서장, 심지어 회사 대표를 포함할지도 모른다.
재난 복구 준비를 위해 필요한 문서는 상당히 많다. 더 자세한 정보가 필요하면 참고자료 절을 살펴보자.
감사
문서는 전사적 환경에서 살아 움직이며 발전하는 개체다. IT 조직이 자라나고 바뀜에 따라 문서와 테스트 절차도 똑같이 성장을 거듭해야 한다. 문서가 바뀔 때 테스트를 진행해서 정확하게 현 상황을 반영하는지 확인해야 한다.
지금부터 1년이 지났다고 가정하자. 여러분 회사는 전자편지 소프트웨어를 판올림한다. 이 새로운 소프트웨어는 직전 버전과는 달리 편지함을 복구하는 데 조금 다른 방법을 사용한다. 이런 변경은 재난 복구 문서에 갱신되지 않았기에, 복구 과정에서 담당자 발목을 잡는다. 담당자가 열받을 뿐만 아니라, 오랫동안 전자편지 서버가 복구되기를 기다리는 사람들도 함께 열받게 된다.
해마다 아키텍처 컴포넌트를 주기적으로 테스트하도록 일정을 잡아 이미 생성한 문서를 갱신하고 다듬자. 이런 주기적인 테스트는 또한 지원 조직에 확신을 심어준다. 그래서 심지어 책에 나오지 않는 사고가 발생하더라도(실제로 대부분 그렇다), 압박 하에서 팀원들은 좀더 나은 결정을 내리기 위해 과거 경험을 활용한다.
테스트 결과를 감사 조직에 넘기면 전반적으로 비즈니스를 확신하기 위한 강력한 영향력을 얻는다. 대다수 테스트 결과는 선임 관리자만 살펴보는데, 돈을 통제하는 동일 인물일 가능성이 높다. 종종 이런 관리자는 기술직이 아니므로 테스트와 결과에 대한 설명이 유용하다.
IBM® Rational® 소프트웨어 같은 변경 관리 시스템을 사용하면 응용 프로그램에서 일어난 변화를 추적하기 위해 응용 프로그램 테스트를 관리할 수 있다. Numara Track-It과 같은 상담 창구 응용 프로그램을 사용하면 새로운 문제가 어디서 발생했는지 평가하는 보고서를 생성한다. 이런 정보는 전사적으로 필요한 좀 더 정확한 테스트를 만들어내는 데 쓰인다. 문제 수정 결과 확실하게 해결되었는지, 같은 문제가 반복되지 않는지를 비교하기 위해 테스트 결과를 만들어낼 수 있다.
부정적인 결과를 내놓는 테스트에 대해 걱정하지 말자. 실패는 테스트 도중에 일어나는 좋은 일이다. 실패는 통제된 환경에서 일어났을 뿐, 실제 운영 도중에 생기지 않았기 때문이다. 실패를 배움의 기회로 삼자. 시스템이 실패하는 이유가 무엇일까? 어떻게 실패를 피할 수 있을까? 실제 운영 도중에 막을 방법이 있는가? 또한 감사 보고서에서 실패를 감추려고 시도하지 말자. 실패를 통해 얻어진 성공 사레를 강조하자. 개발 도중에 문제를 예측하지 못했으며, 문제가 표면에 드러나자 개발팀이 대응한 방법을 지적하자.
표준 준수
테스트와 테스트 결과는 SOX(Sarbanes-Oxley), PCI(Payment Card Industry), HIPPA(Health Insurance Portability and Accountability Act)와 같은 특정 표준을 준수하기 위해 필요한 경우가 있다. 몇몇 표준은 테스트 결과를 보관하는 기간까지 지정해 놓았다. 고객과 맺은 관계에 따라 이런 테스트는 공유해야 할 필요가 있다.
이 단계에서 표준 준수에 신경을 쓰는 이유가 무엇일까? 테스트할 때 표준 준수도 테스트한다. 표준 준수 목표는 요구 사항을 최소로 충족하는 데 있지 않으며 요구 사항을 확실히 충족하는 데 있다.
외부에서 수행하는 표준 준수 테스트와 감사는 내부에서 수행하는 경우보다 좀 더 이익이 클지도 모른다. 외부 사람들은 감사와 표준 준수를 바라보는 시각에 왜곡이 덜하다. 감사는 외부나 내부적으로 수행한다. 외부 테스트는 일반적으로 가장 손쉬운데, 대다수 회사가 사내에서 테스트를 수행하므로 설정할 필요가 별로 없다. 특정 기능이나 이벤트를 수행하는 내부 표준 준수 감사는 조직에 영향을 미칠 가능성이 있다. 외부 조직은 전반적인 IT 기술을 배워 어떤 컴포넌트를 반드시 테스트할지 알고 있어야 한다.
믿을만한 감사 전문 회사를 활용하면 결과를 공유할 때 좀 더 유리하다. Solutionary나 Ambiron Trustwave 같은 회사는 특정 업계에 전문화되어 있으며, 표준 준수 감사와 테스트를 수행한다. 이런 회사는 특정 업계에 필요한 표준과 테스트를 찾는 과정에서 믿을만한 훌륭한 조력자다.
도구와 기술
똑같이 만든 아키텍처는 존재하지 않으며 마찬가지로 테스트 기법도 아키텍처마다 다르다. 핵심 컴포넌트를 위한 테스트 척도 생성 작업에는 시간이 들어가므로 팀과 논의하자. 오픈 그룹이 출간한 IT 아키텍처 지침은 좋은 출발점이다. 비슷하게 Tetworks는 응용 프로그램 테스트를 위한 오픈 소스 툴킷을 제공한다.
몇몇 테스트는 특별한 고려 사항이 필요할지도 모른다. 전원이 나가버리면 UPS가 동작할 것이다. 하지만 정확한 테스트를 위해 무엇을 해야 하나? 종종 대답은 제조사가 제공하는 절차에 들어 있다. 이 경우 많은 UPS는 자체 점검 기능을 보유하고 있기에 연결된 장비를 위험에 빠트리지 않고서도 테스트가 가능하다.
몇몇 테스트는 개별 컴포넌트를 살펴보는 수준으로는 진행이 어렵다. 실제로 작업을 방해하지 않고서 어떻게 백업 자료 센터로 운영 트래픽을 넘길까? 주의 깊은 계획과 명확한 의사 소통을 통해, 이런 테스트를 수행할 수 있다. 물론 테스트에 여러 시간이 걸릴 것이다.
테스트에 들어가는 전체 시간을 고려하자. 각 테스트를 수행하는 데 시간이 어느 정도 걸리는가? 살아 있는 시스템에서 테스트를 하는가? 아니면 가상 시스템에 있는 자료 저장소에서 진행하는가? 살아 있는 시스템이라면 라우터나 하드 디스크 고장처럼 테스트가 초래할지도 모르는 손상을 복구하기 위한 시간을 고려하자. 여러 도구가 테스트 과정에서 여러분을 도와준다. 세부 정보는 참고자료 절을 살펴보자.
중간 목표
목표를 확립하고 전사적인 IT 프로젝트를 진행하는 과정에서 다음 중간 목표를 활용하자.
- 목표 확립: 어떤 테스트가 필요하고 얼마나 자주 수행해야 하는지 정리하자. 문서 완료 시점을 정하자. 그렇지 않으면 문서 작성은 끝이 안 보인다. 특히 절차에 따라 테스트한 결과 오류를 찾은 다음에는 문서를 수정했는지 확인하자.
- 관리: 전반적인 과정을 통틀어 테스트 작업을 관리하자. 확립된 표준을 따라 진행하는지 확인하고 팀원과 함께 결과를 검토하자.
- 의사 소통: 테스트가 중요한 이유에 대해 팀원과 관리자와 함께 토론하자. 테스트 작업이 종종 우선 순위가 낮아지는 이유는 다른 프로젝트 때문이거나 양산에 들어가도록 압박을 당하기 때문이다.
- 자원 관리: 팀원이 보유하고 있는 기술 집합을 평가하고 전문 분야를 시험하도록 만들자. 일반적인 운영 이외의 테스트 기간 중에 다른 사람을 교차 훈련한다는 생각은 훌륭하다. 이렇게 함으로써 팀원에게 통제된 상황에서 실패 상황에 대응할 기회를 제공한다. 테스트를 예산 항목에 집어넣어야 한다. 이는 시뮬레이터 소프트웨어, 테스트 장비, 운영 장비를 일과 후 테스트할 때 필요한 초과 수당을 의미한다. 친숙하지 않은 운영체제나 응용 프로그램을 처음 시작할 필요가 있다면 예산에 직원을 위한 전문 훈련 비용을 포함해야 한다.
- 외부 서비스가 필요한지를 결정: 외부 그룹이 감사 작업을 수행한다면 의미가 있다. 전문 감사 그룹은 모든 자원을 찾아내어 올바른 질문을 던지는 어려운 작업을 수행할 수 있다. 세부 평가를 수행하기 위해 적절한 도구를 갖추지 못했을 때 외부 서비스가 특히 유용하다.
- 역할 할당: 이제 본격적인 시작이다. 개별 팀원에게 가장 잘 맞는 과업을 나눠주고 진행하도록 풀어놓자.
- 문서 관리: 이 단계를 시작하기 앞서 문서를 작성하지 않았다면 시작할 시간이다. 운영 절차, 코드 변경, 상담 창구 절차 등을 수집하자. 팀원이 자리값을 하도록 문서를 만들게 할 좋은 시점이다.
요약
새로운 아키텍처 절차 중에서 테스트 작업을 중요한 기능으로 만들자. 테스트 기반이 좋으면 새로운 시스템 기능과 이 뒤에 숨어 있는 중복성을 함께 묶어 활용할 수 있다. 새로운 전사적 아키텍처를 테스트하는 작업은 전사적인 IT 팀원이 테스트를 구축하기 위해 아주 힘들게 헌신하고 있음을 의미한다.
기억하자. 테스트에서 나온 결과가 실패라면 성공이다. 팀 기술을 날카롭게 다듬기 위해 실패에서 배우고, 새로운 테스트를 만들어 오류가 다시 발생하는지 확인하자. 테스트는 전사적인 팀을 위한 모의 전투 훈련이다. 테스트 단계 전반에 걸쳐 의사 소통이 중요하다. 테스트가 벌어질 때 그룹 외부 팀원에 이를 알리자. 모든 테스트를 일과 중에 수행하지 못하기에, 테스트 시간과 심지어 전용 테스트 장비에 들어가는 비용을 앞서 계획하고 확보하자. 아키텍처에 변경 기록을 최신으로 유지해 변경 추적을 위한 테스트 절차를 구성하자.
참고자료 교육
제품 및 기술 얻기
- IBM 제품 평가판을 구해 DB2®, Lotus®, Rational, Tivoli®,
WebSphere®와 같은 응용 프로그램 개발 도구와 미들웨어 제품에 익숙해지자.®.
- 테스트 작업을 지원하기 위해 여러 참고자료를 활용하자.
토론
필자소개 | | | Michael Welsh는 IT 보안, 재해 복구, 네트워크 분야를 책임지는 IT 전문가로 15년간 일해왔다. 또한 운영체계, 하드웨어, Microsoft Exchange Server 같은 많은 서버사이드 애플리케이션에 지식을 가지고 있다. Michael은 웹 사이트와 비즈니스에 대한 기술 문서를 집필하고 있다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
