을의 Digital Finance 블로그(5)
기업 내 IT-비지니스 관계 모델 변화 (상)
SW투입요소들의 경쟁력 - "누가 어떻게 구현하고 있는가 ?"
SW를 구현하는데 누가 어떻게 구현하고 있는가에 대한 질문을 해 보려고 한다. 우선은 한 기업 내에서 IT부문과 비지니스 무문간의 관계가 어떻게 변해 왔는지, 새로운 바람직한 IT-비지니스 관계 모델은 어떠해야 하는지에 대해서 살펴보고자 한다. 그리고 나서 기업 간 관계 모델, 구매자-서비스 제공자 모델, 즉 갑을병관계를 포함한 IT서비스 생태계 모델에 대해서 고민해 보고자 한다. 출발점은 역시 기업 자체, 기업 내부로 부터 시작하는 것이 좋겠다고 생각했다.
기업 내 IT-비지니스 관계 모델의 변화
기업에서 디지털 혁신을 위한 가장 큰 장애로 문화, 조직, 프로세스 등 여러 측면을 이야기하지만, 가장 큰 걸림돌은 IT부서와 비지니스가 어떻게 일하고 있는가라고 생각한다. 변화의 시대에 지속가능한 성장을 만들어 가는데 어떤 IT-비지니스 관계가 바람직할 지에 대해 고민해 본다.
필자의 경험으로 보면, 아직도 많은 국내의 많은 기업 내에서 IT를 신뢰할 만한 부문으로 생각하지 못하는 것 같다. IT는 항상 느리고, 장애가 발생하며, 어렵다고 이야기하고, 이해할 수 없는 러시아어를 사용한다. 경쟁사는 항상 비용도 적게 쓰고 더 잘하는 것 같다. IT부문에서는 현업을 고객으로 보고 IT서비스를 제공한다는 시각이 많다. 하지만 디지털 시대에는 IT부문을 외부 서비스 제공자 (IT as a Contractor)로 보는 전통적인 시각에서, IT부문이 비지니스 결과에 책임지는 리더십 팀 구성원 중의 하나로 보는 시각으로 전환해 가야 한다. IT를 Cost Center가 아닌 Profit Center롤 본다는 것은, 해당 기업의 기업가치를 높여서 기업의 Profit을 창출하자는 이야기이지, 기업 내부의 현업부서 또는 외부에 IT서비스를 제공해서 매출과 이익을 내자는 것은 아니다.
시장에 적용할 수 있는 ABCDE 디지털 기술은 날로 발전하고 있고, 신속하게 적용할 수 있는 Agile, DevOps도 준비되어 있다. 문제는 IT부문과 기업 내 다른 부문 간에 일하는 방식이 아직 과거를 벗어나지 못하고 있는 점이 아닐까 한다. 기술과 비지니스를 모두 아는 T자형 인재 중심으로 소규모 팀을 구성하고 Agile하게 DevOps팀을 운영하는 것처럼, IT부문도 Executive DevOps팀의 일원으로 더욱 Agile하게 비지니스 가치를 창출하는 역할로 변해가야 한다고 생각한다.
전통적인 IT와 비지니스 관계는 어떤 모델이었나?
전통적으로 기업은 기업 내 IT부문을 외부 서비스 제공자, Contractor로 간주해 왔었다. 비지니스 부서에서 요건을 정의해 주고 정해진 기간과 비용 내에서 이를 구현해 내는 역할, 즉 외부 IT서비스 제공자 역할을 수행할 것을 요구받았다.
돌이켜 보면 금융기관에서 IT부서가 커지면서, 부서장급이 아닌 기술과 비지니스를 이야기할 수 있는 CIO 제도를 도입한 것이 90년대 후반으로 기억된다. 기업 내 요건을 작성하고 승인하고, 개발, 적용하는 프로세스를 만들었고, 프로젝트 진행도를 체크하고 예산을 통제하면서 IT를 관리해 왔다. 반면 IT는 비지니스 요건이 어떻튼 간에 (코끼리를 냉장고에 넣으라는 요건이더라도, "서비스" 산업에서 "고객"은 항상 옳다), 현업부서가 요건을 작성하고, 확정해 주기를 요청했다. 현업부서는 고객이었고, IT부서는 서비스 제공자였다. 현업부서가 원하는 것을 이야기하면, 소요 시간과 비용을 추산해 주고, 현업이 주문하면 IT는 주문을 수행하는 역할이었다. 이런 관계는 IT와 비지니스를 별개로 보고, IT는 기술에만 관심 있는 전문가로, 현업은 기업가치를 높이는 데 관심 있는 비지니스 맨으로 보는 시각에 기초한다. 나아가서 관리회계를 이용해서 IT비용을 현업부서에 Charge Back하는 모델을 만들기도 했다.
이런 과정을 통해 현업은 점점 더 IT를 외부 서비스 제공자, 외부 Contractor로 간주하게 되었고, 비싸기는 하지만 통제가능하다고 생각했다. 현업 부서로서는 기술적인 상세한 부분을 모르더라도, IT를 통제할 수 있다는 환상을 가지게 되었고, 반면 IT부서 자체는 회사의 비지니스 성과에 대해서는 책임 질 필요를 느끼지 못했다. IT는 요건이 정의될 때까지는, 아무것도 할 수 없다고 하면서, 가치 창출을 위한 의사결정의 부담에서 벗어날 수도 있었다. 오래지 않아, 비용 경쟁력이 있는 외부 아웃소싱 사업자를 활용하려고 생각하게 되었다. 국내 금융기관에서도 2000년대 중반 이후 2010년대 중반까지 가격 경쟁력이 있는 인도 아웃소싱 사업자를 포함하여 IT전체를 아웃소싱하려는 움직임이 많았었다.
전통적인 Contractor 모델에서는 plan-driven Waterfall 모델을 따라서 IT시스템을 구축하게 된다. 경제개발 5개년 계획을 수립하듯이 금융 차세대 시스템을 장시간에 걸쳐 계획하는 것이 대표적인 사례라고 생각한다. Waterfall 모델에서는 기간과 비용 내에서 요구사항을 개발하는 것이 요구되었다. 문제는 불확실한 환경에서 요건은 하나의 가설에 불과할 뿐이라, 협업은 가능한 모든 아이디어를 요건에 담으려 한다. 그 결과로 많은 시간을 들여 개발한 많은 요건들을 거의 사용하지 않게 되기도 한다. 중요한 것은 정의된 요건이 개발되었느냐 보다는, 비지니스 목적을 달성하였는가 이다. 게다가 요건 정의에 너무 과다한 시간이 소요되어 전체 시간이 길어진다는 단점이 있다. 구현 기간의 단축을 위해, 정기적으로 프로젝트 일정을 보고 받지만, 항상 다음과 같은 맥락의 보고만 받게 된다. "현재 일부 타스크는 다소 일정 지연이 있지만, 지연은 일시적인 것이고, Catch Up하기 위해 이런 추가적인 활동을 하면, 계획된 일정을 달성할 수 있다." 요건을 변경해서라도, 비지니스 목적을 달성하는 것이 더 중요하다는 입장보다, 일정을 맞추는 것이 더 중요하다고 보게 된다.
이렇게 IT가 협업부서를 동료가 아닌 고객으로 보고, 현업이 IT를 동료가 아닌 외부 IT서비스 제공자 역할로 보게 되면서, IT를 하나의 별도 비즈니스처럼 운영하자라는 생각도 하게 된다. IT를 하나의 별도 비지니스로 보면서, 얼마 효율적으로 운영하고 있는지 외부 IT서비스 회사와 비교하게 된다. 나아가 IT부서가 수행하고 있는 일은 당연히 주어진 것이 아니며, 잠재적으로 외부 IT서비스 제공자와 경쟁관계로 놓고 생각해서, 언제든지 외부 IT서비스 제공사업자로 교체될 수 있다고 가정한다.
사실, IT가 별도 비지니스 조직이라면 수요에 따라 인력을 자유롭게 충원하고, 또 처우도 경쟁력 있게 해 주어야 한다. IT도 자기 마음대로 고객을 선택할 수 있어야 하며, 가용한 범위 내에서만 일을 맡을 수 있어야 한다.
하지만 기업 내 IT부문은 별도 비즈니스 조직이 아니다. 외부 IT서비스 사업자와 비교할 수 도 없다. 많은 경우 내부 IT부문 대비 외부 IT서비스 사업자는 같은 서비스를 더 비용 효율적으로 제공할 수 없다.
복잡성의 시대에 요구되는 IT와 비지니스의 관계모델은?
불확실성과 복잡성이 지배하는 시대에, 기업은 진화 생물학(evolutionary biology)에서 차용한 용어대로 복잡한 적응 시스템 (CAS (Complex Adaptive System)), 즉 각자가 자신의 목적을 추구하고 상호 관계를 맺는 시스템이라고 할 수 있다. 이런 환경에서는 빠르게 배우고, 의사결정하면서 상황에 적응해 가는 agility가 중요해진다. 사실 우리가 직면한 IT의 복잡성은 사실 기업, 비지니스의 복잡성이다. 종종 IT는 기술적인 측면에서 그 복잡성을 배가하기도 한다. IT는 Layer(계층)와 툴을 만드는 방법으로 복잡성에 대응해 왔다. 즉 이미 해결된 문제는 하나의 Layer(계층)로 정의하면서, 그 복잡성에는 신경 쓸 필요가 없도록 진화해 왔다. 예를 들면 우리가 인터넷으로 커뮤니케이션할 때, 이미 존재하는 인터넷 프로토콜(http)을 신경 쓸 필요가 없다. Layer와 툴이 많아지면서, 보이지 않는 아래 단계의 Layer(계층)와 툴에 문제가 생기면 대응하기 어려워지기도 한다. 우리는 SW시스템을 관리가능한 모듈식 아키텍처, 나아가 마이크로서비스 방식으로 전환하고 있지만, 복잡성과 불확실성을 받아들이고 일하고 있다.
이제는 비지니스 기회와 IT기회를 구분할 수 없고, 비지니스 리스크와 IT리스크를 구분할 수 없게 되었다. 기준을 높여서 IT가 비지니스의 미래를 결정하는 데 기여하고, 비지니스 성과를 내는데 책임을 져야 하는 시기가 도래했다. 시장은 시가총액을 결정할 때, 기존 비지니스의 매출 대비 새로운 비즈니스로 부터의 매출을 훨씬 더 높게 반영해 주고 있고, 어떤 새로운 경쟁우위와 혁신을 만들어 내고 있는지 예의 주시하고 있다. 지속적인 혁신과 경쟁우위를 만드는 방법은 새로운 시도를 하는 데 있어서, 혁신속도를 높혀 이에 수반하는 비용과 리스크를 절감하는 것이다. Agile, DevOps를 통해 실질적인 개발, 운영의 속도를 높일 수 있는 시대가 되었다.
Agile IT는 제조의 Lean 경영과 유사한데, 제조 공정에서는 Waste의 원천으로 재고, 추가적인 처리, 과도한 생산, 이동시간, 대기시간, 불량등이 있다. IT프로세스에서도 동일하게, 재고(개발 중인 프로젝트), 대기시간(개발 후 테스트 시간), 과도한 생산(과도한 요건), 불량(오류)등이 존재한다. 하지만 가장 많은 시간은 IT부문과 기업 내 다른 부문 간의 상호작용, 커뮤니케이션에서 발생한다. Agile, DevOps를 위해서는 개발 프로세스만이 아닌, 투자계획 승인, 구매, 요건 정의, 리스크 관리 등 전 프로세스에서 변화해야 한다.
좋은 소식 중 하나는, 디지털 시대에 점점 더 IT부문에서는 기술을 사랑하지만, 비지니스 문제를 해결하는 데도 능력을 발휘하는 T자형 인재들이 나오기 시작했다. 또한 비지니스 부분에서도 점점 더 IT를 이해하고, 활용까지 잘하는 현업들이 활약하기 시작했다. 이러한 T자형 인재를 모아 소규모 팀을 구성하고, 새로운 Agile, DevOps 방식을 잘 활용하면 정말 많은 변화를 만들어 갈 수 있다. 특히 급변하는 마케팅, Digital Platform영역에서 개발요건은 하나의 가설에 불과하며, 기존의 아웃소싱에 의존하는, Waterfall 개발방식은 매우 비효율적이다.
바람직한 IT-비지니스 관계모델을 논의하기 전에, 몇 가지 간단한 IT법칙을 살펴보고자 한다.
IT가 복잡해 보일지 모르지만, 몇 가지 IT법칙은 아주 간단하지만 상식적이어서 유용하게 사용할 수 있다.
( WAR PEACE IT by Mark Schwartz, side glance : GRAPHS)
그림 1. 투입인원 대비 소요시간
인원을 더 투입한다고 프로젝트 종료 기한을 앞 당길 수 없다. 조산이 아니면 결국 정상 출산에는 10개월이 걸린다. 인원을 더 투입하면, 초기에는 효과가 있지만 일정 수준이상의 인원을 투입하면, 커뮤니케이션 비용의 증가로 결국 기간은 늘어난다. 아마존이 Two Pizza팀을 선호하는 이유이다.
그림 2 개발자 대비 배포(개발적용) 건수
개발방식을 바꾸어 DevOps를 잘 적용하면, 개발자 (High Performers) 투입 대비 생산성은 기하급수적으로 올라갈 수 있다. 그림 1번 법칙은 더 이상 적용되지 않는다.
그림 3. 시간 투입대비 감소하는 테스트 품질
Waterfall개발방법에서 수작업 Test에 시간을 투입할수록, 찾아낼 수 있는 오류 수는 적어진다. 물론 DevOps에서의 자동화된 테스트를 적용하면 이 공식은 적용되지 않는다.
그림 4. 시간 경과 대비 오류수정비용
오류를 발견하는 데 시간이 소요될수록, 오류를 고치기도 힘들고 오류로 인한 비지니스 임팩트도 크다. 새로운 코드가 만들어질 때마다 오류를 찾을 수 있는 DevOps 방식을 통해 오류 수정비용을 낮출 수 있다.
그림 5. 시간 투입 대비 리스크
DevOps를 통해 빠르게 실험함으로써 리스크를 줄이고, 비지니스 가치를 더 빨리 전달할 수 있다. 자동화되지 않은 전통적 Agile(Scrum), Waterfall 방식에서는 최종적으로 오픈할 때 까지 리스크를 알기 어렵다.
그림 6. 불확실성의 깔때기
초기 보다 시간이 경과함에 따라, 불확실성이 제거되고 그 편차가 줄어드는 것을 표현한다. 초기 추산치는 항상 믿을 만하지 않다.
그림 7. 배포 빈도 대비 리스크
개발 규모를 줄이고 자주 배포할수록, 리스크를 줄일 수 있다.
그림 8. 배치 규모 대비 처리량
배치 규모가 커질수록, 처리량은 급속히 감소한다. 대규모 프로젝트가 실패하는 이유 중의 하나이다. 가능하면 요건을 줄여 작은 규모로 여러 번 개발하는 것이 유리하다.
