모 사이트에서 성능저하가 발생하여 각 파트별 엔지니어 미팅이 소집되었다. 하드웨어 엔지니어, 네트워크 엔지니어, 애플리케이션 개발 업체 담당자, 미들웨어 엔지니어, 데이터베이스 엔지니어 등등 각 사의 핵심 엔지니어가 소집되고 성능저하 원인 분석을 위한 회의가 개최된다.

물론 지루한 회의가 장시간 계속되지만 성능저하를 일으킨 근본 원인(Root Cause)을 쉽사리 찾아 내지 못하고 회의가 연기 되는 게 다반사였다. 그런데 만약 데이터베이스 엔지니어가 다른 일정으로 회의에 불참했다면 이 성능저하 관련 회의는 시작부터 화기애애한 분위기에서 가볍게 시작하여 가볍게 원인을 찾아내고 다음을 기약하며 회의가 마쳐지기 다반사였다.

왜냐하면 성능저하 원인은 별다른 이견 없이 데이터베이스에서 뭔가 문제가 있어서였다는 결론이 거의 만장일치로 도출됐기 때문이다.

그 만큼 성능저하의 근본원인은 찾아내기가 힘들다는 이야기일 것이다. 다만 성능저하에 대한 책임질 누군가는 확실히 할 필요만 있었을 뿐이다. 오직 0 과 1, 참과 거짓 만 존재하는 IT 환경에서 위와 같은 회의는 마치 무슨 코미디 소재같이 보이지만 현실이 그리 하였으니 아이러니가 아닐 수 없다.

10년도 한참 지난 과거의 경험이지만 오늘날의 IT 현실 또한 크게 다르지 않은 것 같다. IT 환경과 비즈니스 환경이 과거에 비해 더 복잡해짐에 따라 이런 현상은 더욱 더 심화되어 가는 추세이다. 이런 IT 환경 변화의 중심에는 Open System으로의 Down Sizing과 TP 기반의 미들웨어 환경에서 WAS 기반의 미들웨어 환경으로 변화가 있었을 것이다.

그런데 이런 변화가 일시에 IT 환경을 바꿀 수 있는 것이 아니고 이런 환경들이 혼재되어 있음으로 해서 관리자 입장에서는 더욱더 머리 아픈 환경이 된 것 이다.

즉, 모든 업무가 WAS 환경에서 처리가 된다면 APM 툴을 이용하여 관리가 용이해 지겠지만 현실은 TP, WAS, 각종 Demon들이 혼재 되어있기 때문에 WAS를 모니터링 하는 APM 툴만으로는 관리가 안 되고 또한 거래 단위의 모니터링을 하고자 할 경우에도 한계에 부딪히게 된다.

일반적으로 IT 부서에서는 많은 비용을 투자하여 업무 팀에 업무 효율을 높여주고 업무 혁신의 중심에 있다고 생각하지만, 현실은 IT 투자에 대한 효과는 상대적으로 경영진에 어필하지 못하고 있는 실정이고 오히려 과투자 혹은 IT부서는 대표적인 비용부서라는 인식이 많은 상황이다. 오랜 시간 동안 IT 부서의 대표적인 고민 중의 하나가 바로 이런 부분일 것이다.

최근 IT 솔루션 중에서 관심을 받고 있는 솔루션이 거래추적 혹은 End to End 솔루션이다.
거래추적 솔루션은 WAS 뿐만 아니라 TP 구간까지 IT 시스템 전 구간의 거래단위 모니터링을 가능하게 해 줄 수 있을 뿐만 아니라 장애 이력, 경보 이력 등 과거 거래 정보를 이용하여 다양한 통계 자료 생성 및 성능개선을 위한 지표로 삼을 수도 있기 때문이다.

그렇다면 ROI 측면에서 IT 부서에서 거래추적 솔루션을 활용 할 수 있을까?

과거 외국 자료에서 IT 부서의 ROI 분석을 본 기억이 있다. 오래전 일이라 정확히 기억은 나지 않지만 장애로 1시간 서비스가 안 됐을 경우 해당 시간대의 거래건수를 집계하고 하나의 거래당 비용을 계산하여 손실비용을 추정 했던 자료인데 어마어마한 손실을 산정했던 것으로 기억한다. 물론 외국 기업이고 글로벌 기업인 탓에 거래량이나 거래당 비용계산 방식이 우리의 환경과는 다소 차이가 있을 수 있겠지만 그런 억지스러움을 빌어서라도 IT 부서의 비용에 대한 오해를 벗어 보려는 노력쯤으로 이해했던 것 같다.

쇼핑몰을 예를 든다면 1시간 동안의 접속 자 통계를 구하고 또 한 사람이 구매하는 평균 금액을 산정하여 1시간동안의 접속자와 구매금액의 합산으로 손실 비용을 계산 할 수도 있을 것이고 은행이나 증권사라고 하면 접속 자 대비 거래 수수료를 감안하여 손실 비용을 계산 할 수도 있을 것이다.

그러나 손실이란 장애 상태에서만 발생하는 것은 아니다. 손실비용과는 반대 개념이겠지만 개선을 통하여 접속자 수가 늘어난 경우의 계산방식은 어떨까?

100명을 처리 할 수 있던 시스템을 하드웨어 증설을 하지 않은 상태에서 애플리케이션의 성능을 개선시킴으로써 동일 시간대에 150명의 서비스를 처리 할 수 있다고 가정해 보자. 이로 인한 매출 중가 율을 계산 해 보는 것은 장애를 가정하고 장애로 인한 손실을 계산 하는 것 보다 훨씬 생산적인 계산법이 아닐까?

또한 위와 같은 손실율, 증가율과 같은 눈에 보이는 효과뿐만 아니라 IT 시스템이 불안정해 사용자가 느끼는 불편함과 이로 인한 회사의 이미지 감소는 돈으로 계산 할 수 없는 무형의 가치에 대한 부분이다.

한창 인터넷 쇼핑몰이 붐을 일으키던 시절에, 너도 나도 SOHO 창업이 붐을 일으키던 시절에 인터넷을 이용한 웹 비즈니스에는 3.3.3 법칙이라는 게 있다고 했다. 사용자가 인터넷을 이용 하면서 서비스 응답이 제대로 없을 때 사용자는 3번 재시도를 하고 최장 3분 까지는 기다려 주지만 그 이후에는 최소한 3사람에 대하여 해당 사이트에 대한 험담을 전한다는 말이다.

이 원리를 기준으로 1 시간 동안 100명의 접속자가 장애를 경험한 쇼핑몰이라 하면 직접 사용자 100명을 포함하여 기본적으로 400명의 잠재 고객을 잃을 수 있을 것이고 이 사람들이 두 번, 세 번만 가지치기를 한다면 잠재 고객 10,000명을 잃는 것은 그리 상상하기 어려운 일은 아닐 것이다. 나아가서 이런 장애로 인해 단순 접속자가 아닌 충성도 높은 고객을 잃는 다고 하면 그 피해는 산술 적인 계산으로 예상 할 수 없는 막대한 피해로 이어 질 수도 있다.

과거 APM 솔루션을 도입하여 애플리케이션을 관리하고자 하였다면 최근에는 금융권을 중심으로 거래추적 솔루션을 도입하여 거래 자체를 모니터링 함으로써 최종사용자의 IT 활용편의를 극대화 하고자 하는 노력이 확산되고 있고 이는 금융권뿐만 아니라 각 공공기관 및 대부분의 웹 비즈니스를 하는 일반 기업으로 까지 확산되고 있는 추세이다.

이러한 노력은 단순한 애플리케이션 관리에서 벗어나 비즈니스 Transaction 관리(BTM), IT 시스템 운영의 효율을 이루는 것을 넘어 ROI 개선에 대한 정량적인 자료를 획득하기 위한 일환이기도 하다.

최종 사용자가 이용에 불편을 느껴 콜센터에 연락하기 이전에 선재적인 관리를 통하여 현재 어느 부분에서 서비스가 정상적으로 이루어지고 있는지를 파악함으로써 장애를 사전에 예방 하고 장애가 발생 한 경우에도 그 정확한 원인과 위치를 파악함으로써 장애시간(Down Time)을 최소화 할 수 있다.

이러한 노력과 운영관리의 적절한 통계를 바탕으로 IT 부서에 투자된 막대한 예산이 효율적으로 집행되어 고객 서비스가 향상되고 어느 정도의 효과를 거둘 수 있었는지에 대한 정량적인 자료를 확보 할 수 있다면 앞에서 언급한 IT 부서에 대한 오해를 조금이나마 씻을 수 있을 것이다.

효율적으로 거래를 모니터링 하고 관리함으로써 웹 서버에서부터 데이터베이스에 이르기 까지 애플리케이션 전구간의 운영가시성을 확보 하고 업무별 처리 현황에 대한 즉시적인 통계자료를 획득 할 수 있는 솔루션이 바로 거래추적 혹은 BTM(Business Transaction Management) 솔루션인 것이다.

우리 IT 환경에 적합한 BTM 솔루션을 선택하고 이를 적용하면, 과거와 같이 장애를 예방하고자 하는 방어적인 운영에서 벗어나 IT자원과 비즈니스 효율을 극대화하기 위한 적극적이고 선제적인 운영방식으로의 전환이 될 수 있을 것이다.

즉, 전체 거래현황을 감시하여 비즈니스 비중이 높은 거래에 대한 관리를 높이고 과거 거래 이력을 참조 하여 Peak Day에 집중되는 서비스와 관련 시스템 자원 등을 매칭하여 필요한 부분을 보완함으로써 Peak Day에도 보다 더 많은 사용자를 수용 할 수 있는 시스템운영 환경을 유지 하는 등의 개선을 기대 할 수 있을 것이다.

뿐만 아니라 주요 업무별 다양한 통계자료와 SLA를 초과 하는 거래에 대한 통계 그리고 전월과 대비한 거래 현황 통계 등은 IT 자원의 효율을 증명하는 효과적이고 정량적인 데이터로 활용이 가능할 것이다.

과거 오랜 기간 비용부서의 대명사처럼 되어 버린 IT 관련 부서에서 BTM 솔루션을 도입하여 적극적인 운영 개선과 비즈니스에 효율을 기할 수 있는 각종 거래 데이터를 제공 하고 이런 노력이 실제 비즈니스에 반영되는 것을 증명할 정량적인 데이터를 생성 해낼 수 있다면 비용부서라는 오랜 오명에서 벗어나 필요부서로 거듭날 수 있는 계기가 되지 않을까?