 |
|
난이도 : 초급 S. E Slack, Lifestyle and Technology Writer, 자유기고가
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 8 월 26 일 설계를 끝냈더라도 프로젝트 완료라는 의무가 끝나지는 않습니다. 설계가 실제 돌아가는지 감시하는 방법을 배웁시다. 이 기사는 전사적 아키텍처를 설명하는 연재물 중 일곱 번째입니다.
전사적 아키텍처 설계를 마쳤다면, 다음번 도전에 대비하기 위해 쉬고 싶다는 생각이 들지도 모르겠다. 구현이 끝나고 나서 설계를 내버려두고 싶은 욕구가 들기 마련이다. 오랜 기간 동안에 설계와 씨름해 왔기에 이 시점이면 어느 정도 따분함을 느낄지도 모르겠다. 하지만 이 시점이 프로세스에서 가장 중요한 마무리 과정이다.
이유는? 설계는 성능이 중요하다. 구현을 마친 다음에 모든 조각이 제자리에 자리잡을지도 모르지만, 사용자가 좌절감을 느끼거나 의도한 대로 동작하지 않을 경우 이를 감지해 문제 영역을 손볼 필요가 있다. 이렇게 하는 유일한 방법으로 전사적 아키텍처 성능을 감시하자. 긴장을 풀지 말자. 여전히 해야 할 일이 남아있기 때문이다. 문제와 기회를 파악해 비즈니스 효율성을 측정하고 교정 작업을 벌여야 한다.
기술과 역량
전반적인 설계는 이상적으로 비즈니스 비전과 전략을 정보 기술 도구와 결합해서 하는 방법으로, 전사적인 아키텍처 설계의 감시 단계를 강조해 성능을 높여야 한다. 예를 들어, 어떤 방식으로 기술이 아니라 정보가 비즈니스 프로세스를 이끌고 이바지하나? 사용자가 원하는 바를 달성하는가? 프로세스에 개선이 있었는가? 이 절에서는 성능 문제를 뚫고 나갈 기술과 역량을 살펴본다.
유연하고 융통성 있게 대응하자
변화를 위한 유연성과 융통성에 대해 이야기를 많이 했다. 이 두 가지 기술이 어떤 아키텍트에게도 통용되는 가장 강력한 무기라고 생각하기 때문이다. 물론 회사에 있는 다른 사람들은 다르게 생각할지도 모르지만, 인생에 완벽이란 없다. 전사적인 설계라고 별 수 없다. 다른 사람에게 "호불호와 무관하게, 이게 바로 설계에요."라고 말하고 싶은 충동이 들지도 모르겠다. 유연한 아키텍트는 설계 개선을 위해 언제든지 변화가 필요하리라는 사실을 인식하고 있다.
유연성을 갈고 닦으며 사고하기 위한 한 가지 방식으로 투자 세상에서 교훈을 배우자. 투자 계획가는 유연한 투자에 대해 고객과 상담할 때 유동성, 신용, 기회 비용 관점에서 이야기를 풀어나간다. 똑같은 개념을 전사적인 아키텍처에도 적용하면, 성능 문제가 떠오를 때 좀 더 유연한 방식으로 생각하고 대응하는 과정에서 도움이 된다.
예를 들어 유동성 개념을 생각해 보자. 투자 관점에서, 유동성은 가치 손실 없이 투자나 자산을 현금으로 쉽게 바꾸는 능력을 의미한다. 아키텍처에서, 성능 쟁점이 떠 오르면 큰 가치 손실 없이 "현금"으로 전환할 수 있는가? 실천 쟁점을 없애기 위해 시스템 일부를 변경할 수 있는가? 아마도 문제를 수정하는 동안 가치 있는 자료 입력 시간을 낭비하지 않은 상태에서 다른 응용 프로그램으로 프로세스를 옮길 수 있을지 모른다.
신용과 기회 비용을 따져보자. 신용은 갑작스럽게 합리적인 비용으로 대출을 쉽게 받을 수 있는 능력을 의미한다. 기회 비용은 가장 효율적인 투자에 "현금"을 투입하지 않았을 경우 일어날지도 모르는 손실이다. 여기에 대해 고민해보자. 짧은 시간 내 다른 방법을 사용해 성능 문제를 개선할 수 있는가? 이렇게 번개처럼 변경하는 과정에서 조직에 미치는 영향이 무엇일까? 선택한 방법이 무엇이든 어떤 손실이 발생할까? 심지어 전에 결코 경험하지 못했던 쟁점을 관리하는 방법을 찾아낼지도 모른다. 유연한 자세를 유지해 무대 옆에 숨어 있을지도 모르는 훌륭한 투자 기회를 놓치지 말자.
의사 소통 채널을 유지하자
설계 성능을 감시할 때, 책상이나 사무실로 돌아가서 혼자 문제를 씨름하지 말자. 구현 전에 결코 파악하지 못했던 효율 쟁점에 놀라게 될지도 모른다. 놀라는 편이 정상이다. 하지만 혼자 일하면 효율 쟁점을 거의 해결하지 못한다. 사람들로부터 다양한 이야기를 듣고 쟁점에 대한 잠재적인 모든 세부 사항을 고려해서 해답으로 향하는 가장 적절한 경로를 결정해야 한다.
회의를 열자. 부담스럽더라도 다른 아키텍트를 포함해 비즈니스 핵심 인력을 초대하자. 집단 지성은 개인 혼자서는 고려하기 힘든 해법을 떠오르게 만든다. 문제가 조직 내부 사용자와 관련이 있다면, 내부 사용자 중 몇 명을 회의에 참석하게 만드는 편이 어떨까? 사실상 실제 설계 활용 과정에서 사용자의 삶을 좀 더 쉽게 만들 사람이 사용자 말고 누가 있을까?
팁 한 가지: 해결책을 찾고 있는 동안 관리층에게 계속해서 정보를 제공하자. 관리층이 수많은 불평을 막아내고 있는 상황에서 문제가 어디에 있는지 알고 있다면 상당한 도움이 된다. 이렇게 하려면 매일 관리자에게 갱신된 정보를 보낸다. 간단한 템플릿을 만들어 마지막 의사 소통 이후에 일어난 활동을 알려주도록 빈칸을 채우기만 하면 된다. 꾸준히 할 경우에 관리층에 높은 점수를 얻을 수 있으므로 이런 중요한 단계를 간과하지 말자.
냉정을 유지하자
성능을 감시하면서 분석적인 태도를 유지하는 자세가 중요하다. 설계에서 어떤 부분이 계획대로 동작하는지를 결정하는 과정에서 개인적인 감정이 끼어들도록 내버려두지 말라. 누군가 결국 고려할 가치가 없는 쟁점에 대해 시간을 낭비하게 될지도 모른다. 분석적인 방법을 동원해 성능 쟁점이 정말로 고려 대상인지를 결정할 수 있다. 분석적인 태도를 유지하려면, 기준에서 벗어난 상황을 어디까지 받아들일지 결정하기 위해 결과물, 입력물, 프로세스를 통한 고차원적 결과물을 체계적으로 활용해야 한다.
물론 설계에서 어떤 항목이 가장 중요한지 결정하는 묘수가 있다. 예를 들어 사용자 인터페이스 일부가 상당히 혼란스러운 경우와 같이, 설계에서 작은 부분이 제대로 동작하지 않음을 발견했다면 이런 문제점이 전반적인 사용자 생산성에 미치는 영향을 고려하자. 혼란이 고객 서비스에 지연을 일으키나? 그렇다면 지연이 어느 정도인가? 1초? 30초? 몇 분? 그렇다면 지연에 고객과 고객 서비스 담당자 숫자를 곱해보자. 이제 문제가 어떻게 보이는가?
이런 지연이 시간이 지남에 따라 심각한 문제를 일으킨다는 분석 결과가 나온다면, 눈앞에 진짜 성능 문제가 닥친 셈이다. 지연이 단순히 일주일에 한번 고객에 영향을 미치는 경우라면 그다지 큰 고려 사항이 아니다. 핵심은 성능을 감시하면서 차분하고 분석적인 태도를 유지하는 데 있다.
도구와 기술
이 연재에서 소개한 직전 기사인 "전사적 아키텍처의 핵심, Part 6: 관리성"에서, 응용 아키텍처에 사용될 수 있는 다양한 성능 관리 도구와 기술을 소개했다. 이 기사는 전사적 아키텍처 성능 관리와 맞붙어 싸우는 아키텍트를 위한 훌륭한 지침서이다. 하지만 전사적 관점에서 성능 관리가 필요하다면, 다음에 소개하는 도구와 기법 또한 도움이 된다.
위험과 자산 관리
최우선으로 성능 쟁점이 문제가 될지라도, 비즈니스는 효율적으로 계속해서 돌아가야 한다. 문제를 해결하기 위해 고객 서비스 센터를 폐쇄할 수는 없는 노릇이다. 뒤에서 문제를 해결하는 동안에 고객 서비스 센터를 부드럽게 운영하는 방법을 생각해 내야 한다. 하지만 때때로, 실제 성능 문제를 찾아내는 작업은 어렵다. 고객 지원을 효과적으로 버티기에는 시스템이 너무 느리게 돌아간다는 사실만 알고 있을지도 모른다.
성능 측면에서 병목을 찾아내는 도구는 IBM® Rational® Performance Tester와 IBM Tivoli® Composite Application Manager for WebSphere®(참고자료 참조)가 있다. 이런 도구를 결합하거나 독자적으로 사용해 성능 테스트를 만들고, 시나리오를 생성하고, 병목 원인을 찾아낼 수 있다. 이런 도구를 사용하면 비즈니스 위험과 자산을 효과적으로 관리하는 동시에 문제 원인을 찾아낼 수 있다.
모든 정보를 고려하자
단일 성능 쟁점에 사로잡히지 않으려면, 실시간으로 전반적인 비즈니스 프로세스를 감시해 필요한 성능을 지속적으로 유지해야 한다. 이런 과정에서 IBM WebSphere
Business Monitor(참고자료 참조)가 도움이 된다. 이 제품은 경고와 통지를 사용해 비즈니스 프로세스 상태를 시각적으로 출력하며, 핵심 사용자가 비즈니스 프로세스의 연속적인 개선을 촉진하도록 도와준다.
또한 이 도구를 사용하면 비즈니스 모델링, 시뮬레이션, 통찰력 있는 분석을 제공하는 IBM WebSphere Business Modeler Advanced와 통합이 가능하다. 두 도구를 결합하면 직면한 문제에 대한 모든 정보를 파악하고 고려해 쟁점을 해결하고 다른 항목으로 넘어가는 데 도움을 준다.
전반적인 시각을 유지하자
효율적인 BPM(business process management)은 설계에서 성능을 감시하는 핵심이다. 회사 전체에 대한 전반적인 시각을 유지한다면, 주요 성능 쟁점이 문제가 되기 앞서 예상치 못했던 불씨를 찾아낼 기회가 생길 것이다. 조직적인 이해를 돕고, 회사에 가치를 만들어내는 핵심 비즈니스 프로세스를 정의하고 수행하고 최적화하기 위해, SOA(Service-Oriented Architecture, 참고자료 참조)가 활성화하는 BPM을 살펴본다.
이런 접근 방법을 사용해서 성능 문제가 생기기 전에 전체 조직을 한눈에 바라보자. 이렇게 하면 장기적인 관점에서 상당한 시간을 절약하며, 구현에 따른 두통거리 역시 줄여준다. 이미 성능 관리 문제에 발목이 잡혀있는 경우라면 이런 접근 방법이 솔직히 큰 도움을 주지는 못하겠지만, 다음 번에 도움이 될지 살펴보는 작업으로 생각해보면 나름대로 가치가 있다.
중간 목표
전사적 설계에서 성능 쟁점을 다룰 때, 전형적인 몇 가지 중간 목표를 마음 속에 품고 있어야 한다.
사베인스-옥슬리(Sarbanes-Oxley) 보고서 이해하기
미국에서 연방 법은 설계에서 성능 문제와 관련해 무엇을 해야 하고 무엇을 하지 말아야 할지에 영향을 주는 회사 재정 보고 요구 사항을 규정한다. SOX(Sarbanes-Oxley)로 불리는 이 법은 자동화된 프로세스를 포함해서 재정 보고에 영향을 미치는 다양한 비즈니스 측면을 관장한다. 이런 결과로 인해, 미국 회사와 함께 일한다면 SOX 요구 사항을 인지해야만 한다. 어떤 경우에는 성능 쟁점을 고려하기 위해 특정 보고서가 필요할지도 모른다.
SOX 자체에 대한 내용이나 SOX가 미치는 영향과 반드시 고려해야 하는 중간 일정 생성에 대한 사항을 알고 싶다면, 참고자료 절을 살펴보자. IBM Rational Method Composer와 IBM Rational Portfolio Manager는 이런 규정을 준수하도록 도와준다.
ROI로 객관성을 유지하자
사실을 인정하자. 대다수 프로젝트는 원하고 계획하는 만큼 제대로 되지 않는다. 그래도 성능 쟁점을 관리하려고 시도할 때, 요청받은 ROI에 대한 정보를 제공해야 한다. 제출해서 확정된 ROI에 대해 관리층과 이야기할 때, 다음 사항을 염두에 두자.
IBM Rational 서비스 부사장인 워커 로이스는 ROI 추정은 과학이 아니라고 말한 바 있다. 사실상 ROI 추정은 협력을 이끌기 위한 부지런한 연습이다. 또한 ROI 추정은 조직 변화 측면을 받아들이도록 설계된다.
성능 쟁점 문제를 다룰 때, 문제를 해결하기 위해 제안한 변경에 따라 ROI를 계산하기 위해 "느슨한 정밀도"를 사용하는 경우에 주의를 기울이자. 로이스가 설명한 바에 따르면, 느슨한 정밀도는 몇 개 안 되는 너무 느슨한 자료를 평균하는 개념이다. 로이스는 1-5 사이 점수를 매긴 조사 응답 자료 10개를 평균할 경우 정확한 고객 만족을 기술하지 못한다는 예를 제시한다. 거의 모든 ROI 자료가 주관적임에도 불구하고, 가능하면 주관적이거나 이론적인 자료를 객관적인 표현법으로 유지하는 방식이 중요하다.
최종 사용자를 연결하는 반응 시간 알아내기
이 기사 초반에, 문제가 큰지 작은지를 판단하는 개념을 언급했다. 중간 목표 중 하나로 최종 사용자를 연결하는 E2E(End-to-End) 반응 시간이 등장한다. E2E는 사용자가 키를 누르고 반응이 오기까지 경과한 시간이다. 성능 평가 도중에 언젠가는 이 시간을 반드시 측정해야 한다.
이렇게 할 경우 진짜 중간 목표는 E2E 타이밍이 어떻게 되어야 할지 미리 알아 내어 위태로운 상황인지를 재빠르게 판단하는 데 있다. 구현 전에 시간 기대치를 확정해 놓지 않았다면, 뭔가 문제가 생겼을 때 답을 찾느라 발등에 불이 떨어진다. 이런 타이밍은 문제를 정확하게 이해하려고 이사진과 관리층이 처음 질문할 만한 후보가 된다. 따라서 제발 E2E 반응 시간을 기억해서 여기에 영향을 미칠지도 모르는 성능 쟁점을 살펴볼 수 있도록 준비하자. 환경에 따라, 다양한 IBM 도구가 반응 문제를 빠르고 정확하게 찾아내는 데 도움을 준다.
요약
이 기사 첫부분에서 언급한 바와 같이, 문제와 기회를 인식하려면 비즈니스 성능을 측정하고 교정 작업을 벌일 필요가 있다. 전사적 설계는 성능이 중요하며, 정말 위대한 전사적인 아키텍트는 구현이 매끄럽고 효율적으로 동작하기 전까지 힘든 작업이 끝나지 않았음을 알고 있다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | S. E. Slack은 비즈니스 저술 분야에서 16년이 넘는 경력을 자랑하는 저자이자 프리랜서 기고가다. 또 IBM, Lenovo International, State Farm Insurance 등과 같은 회사에서 경영진과 비즈니스 변혁 커뮤니케이션 자문위원으로 활동하기도 했다. 지금까지 6권에 이르는 책을 출판했으며, 현재는 McGraw-Hill 출판사와 함께 CNET Do-It-Yourself Digital Home Office Projects: 24 Cool
Things You Didn't Know You Could Do를 집필 중이다. 전자편지 주소는 sally@sslack.com이다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
