칼럼 | ‘할수록 손해’ 프로세스 최적화의 역설

CIO는 회사 최고의 프로세스 최적화 전문가지만 종종 한 가지 중요한 원칙을 빼먹곤 한다. “전체를 최적화하려면 특정 단계는 부분 최적화(suboptimize)해야 한다”라는 원칙이다.
 
CIO의 역할은 주로 설계다. 그 외에는 실무자를 지도하거나 각 팀의 방향성이 사업 전략과 일치하는지 확인하는 일을 한다.

그 어떤 것을 만들든 훌륭한 설계(혹은 디자인)에는 몇 가지 원칙이 있다. 아마 가장 유명한 원칙은 건축가 루이스 설리반의 “형태는 기능을 따른다”라는 말일 것이다.

많이 알려지지는 않았지만 중요한 말이 하나 더 있다. 미국의 경영 컨설턴트이자 통계학자였던 에드워즈 데밍은 이렇게 말했다:

“전체를 최적화하려면 특정 단계는 부분 최적화(suboptimize)해야 한다.”

많은 CIO가 이 원칙을 종종 간과하곤 한다. 말 그대로 직관적이지 않기 때문이다.
 

숨겨진 프로세스 병목현상

CIO의 핵심 역량은 프로세스 최적화다. 곧 IT 팀의 역할이다. 이러한 프로세스 최적화 전문가들은 무수한 프레임워크와 방법론을 알고 있을 터다. 린 접근 방식이 가장 유명하니 이를 예시로 프로세스 최적화에 대해 알아보자.

린 접근 방식이 퍼뜨린 중요한 교훈 중 하나는 바로 프로세스의 각 단계에 관한 것이다. 기업의 프로세스는 단지 개별적 요소가 한 단계에서 다음 단계로 흘러가는 식으로 작동하지 않는다. 린 접근 방식에서 각 단계는 단일 작업이 아니라 일련의 작업이다.

이는 사소해 보일지 몰라도 매우 중요한 차이다. 프로세스 전체를 최적화하는 것과 개별 단계를 최적화하는 것이 눈에 띄게 다른 결과를 만들어내는 이유이기도 하다.

이렇게 생각해보자.

새로운 서버를 구축하는 프로젝트가 있다. IT 부서는 아직 클라우드로 완전히 이전하지 못해 데이터센터를 쓰고 있다. 따라서 다음과 같은 프로세스를 따라 IT 팀에 요청해야 한다.
 
이렇게 보면 참 간단명료하다. 각 단계를 담당하는 팀은 이미 최적화를 끝낸 지 오래다. 총작업량이 곧 프로세스 생명 주기다. 가령 이 프로젝트의 작업 시간은 8시간이며 프로젝트 스케줄에는 하루로 표기될 것이다.

문제는 단일 박스 형식의 프로세스 시각도가 현실을 반영하지 못한다는 점이다. 실제 프로세스는 아래와 더 가깝다.

 
프로세스의 각 단계는 선입선출(FIFO, First In First Out) 방식으로 진행된다. 따라서 각 단계는 이전 단계가 완료될 때까지 기다려야 한다. 그 결과 총작업량은 박스형 프로세스와 같지만, 프로세스 생명 주기는 다르다. 작업량에 대기 시간이 더해지기 때문이다.

제대로 분석하면 훨씬 더 복잡하지만, 일반적으로 이 대기 시간이 병목 현상을 일으킨다. 실제로 필자가 만난 한 고객사는 서버 작업의 지연으로 대규모 프로젝트의 작업 시간이 몇 달이나 늘어나 곤란해했다.

문제의 원인은 역설적이었다. 서버 구축에 필요한 각 단계, 즉 서버 확보, 네트워크 구성, 소프트웨어 설치, 품질 관리, 그리고 배치를 담당한 팀이 오로지 최적화에만 몰두했기 때문이었다.

즉 다들 자신의 업무만 최적화하는 데 정신이 팔려 전체 프로세스의 발목을 잡은 셈이 됐다.
 

최고는 항상 최선이 아니다

데브옵스 개발자라면 이미 해결책을 알 것이다. 핵심 프로젝트 팀에 IT 인프라 애널리스트를 포함하는 게 프로세스 병목 현상을 해결하는 방법의 하나다. 그럼 전체 프로젝트 일정을 기획할 때 실제로 서버가 필요한 시기에 완성되도록 소요 기간을 정할 수 있다.

즉, 서버 구축 작업이 전체 프로젝트에 조화롭게 통합된다. 더 이상 프로젝트 관리자가 신경 쓰지 않아도 되는 별도의 작업이 아니다.

CIO도 사고방식을 바꿔야 한다. 꼭 모든 팀이 역량을 최고치로 활용해야 한다는 강박을 버려야 한다. 프로젝트가 기획된 비용을 초과하지 않고 제시간 안에 완료되기만 한다면 어떤 작업 단계에서는 가동률이 꼭 100%가 아니어도 된다는 여유를 가질 필요가 있다.
 

목표 중심 관리(MBO, Management By Objectives)의 허점

이런 최적화의 역설은 프로세스 설계를 넘어 회사의 다른 영역까지 영향을 끼친다. 보상 관리가 대표적인 예다. 각 단계만 최적화하면 당연히 전체 프로세스도 최적화될 것이라는 통념에 따라 보상도 최적화의 성과에 따라 책정됐다. 위에 설명한 대로 각 단계를 지나치게 최적화한 탓에 전체 프로세스가 더 지연되더라도 말이다.

가령 이런 식이었다. 임원진은 관리자에게 명확한 최적화 목표를 부여했다. 관리자는 뚜렷한 목표와 동기부여를 가지고 성과를 내기 위해 눈에 불을 켜며 최적화에 목맸다. 같은 프로젝트의 다른 부분을 맡은 관리자의 목표에 신경 쓸 이유가 없었다.

이런 기업은 ‘사일로식 사고방식(silo thinking)’에 빠지는 것을 피하기 어렵다.
 

헬프데스크(help desk)가 전화교환원으로 전락하는 이유

물론 그 어떤 기업의 구조도 완벽할 수 없다. 그런데도 데밍의 최적화 및 비최적화 이론은 결점을 어느 정도 메꿀 방법의 하나다.

최적화 및 비최적화 이론이 빛을 발휘하는 대표적인 문제 중 하나는 바로 헬프데스크의 역설이다. 헬프데스크의 최적화 목표는 서비스 레벨이라고 불리는데, 주로 요청이 들어오기부터 응답하는 데까지 걸린 시간과 평균 문제 해결 시간이 주요 측정 기준이다. 또한 각 문제 해결 건마다 드는 비용도 포함된다.

헬프데스크는 크게 3가지 업무에 시간을 쓴다. 문제 요청을 기록하는 것과 헬프데스크에서 바로 문제를 해결하거나 IT 팀으로 문제를 넘기는 일이다.

이 모든 것을 고려했을 때 헬프데스크가 서비스 레벨을 충족하는 가장 효과적인 방법은 문제를 직접 해결하려 하는 대신 IT 팀에 넘기는 것이다. 그럼 다음 요청에 더 빠르게 응답할 수 있으며, IT 팀보다 해결 가능성이 낮은 문제를 가지고 씨름할 필요가 없어진다. 따라서 사건 별 평균 문제 해결 시간도 줄어든다.

하지만 그 결과 헬프데스크는 무능해진다. 직접 해결할 수 있는 문제도 해결하지 못하게 된다. 게다가 업무를 최적화하는 최선의 방법을 택했을 뿐이지만 사실 전체 비용은 늘린 셈이다. 헬프데스크의 비용은 낮아질 테지만, 더 높은 비용이 드는 인력(IT 팀)이 굳이 하지 않아도 될 일을 맡기 때문이다.

즉 헬프데스크 최적화는 지나친 비용 및 책임 이전으로 이어진다. 헬프데스크의 비용이 낮아질수록 총해결 비용은 올라간다는 점이 고려되지 않았다.

이게 바로 전체를 최적화하려면 특정 단계를 부분 최적화해야 하는 이유다. 직관적이지 않더라도 직원 모두가 이 원칙을 이해하고 서로 협력해 성과를 낸다면 아무도 뭐라고 하지 못할 것이다.

*Bob Lewis는 IT 비즈니스 전략 및 통합 분야를 전문으로 하는 IT 컨설턴트다. ciokr@idg.co.kr