최근 발생한 도요타의 리콜 사태는 기존의 품질과 관련된 사건과는 조금 다른 면이 있다. 품질하면, 오히려 도요타를 떠올렸던, ‘조금 얼마전’의 기억은, 도요타 사태를 지켜보는 우리를 혼란에 빠뜨리고 있기 때문이다.
자동차업계는 크게 두 가지의 회사로 구분된다. ‘완성차를 생산하는 회사’와 완성차에 ‘부품을 공급하는 회사들’이다. 도요타 자동차의 리콜이 발생한 부품은, 실제로는 도요타가 만든 부품이 아니라, ‘협력회사’가 도요타에 ‘공급’한 부품이다.
도요타 자동차의 ‘품질’이라는 것은, 도요타가 완성차를 ‘조립’하는 공정에만 국한된 것이 아닐 것이다. 부품회사에 요구사항을 보내고, 이에 맞는 부품을 검증하는 공정까지가 도요타 자동차 품질의 중요한 축이 될 것이고, 더 나아가서는 모든 협력회사 내부의 품질관리능력까지를 ‘확인하고 검증’하는 공정이 포함되게 된다.
도요타 사태의 원인분석이 한참 진행되고는 있지만, 결국 중요한 시사점 중의 하나는, 협력회사와의 분업과 관련되어 있다고 볼 수 있다.
일반적으로 IT업계에서는 협력회사(supplier)와의 분업을 ‘아웃소싱’이라고 부른다. 그러나, 아웃소싱이라는 용어가 전반적으로 ‘큰’ 단위의 IT업무 위탁을 떠올리는 경향이 있어, 여기서는 그냥 (협력회사와의) 분업이라고 부르겠다.
IT에서의 분업이 활발하게 일어나고 있고, IT조직의 서비스나 제품에 분업의 영향이 점점 커지고 있음에도 불구하고, 일부 IT조직들은 분업을, 귀찮은 일을 값 싸게 해낼 수 있는 방법 정도로만 여기는 태도를 보이고 있으며, 분업을 위한 특별한 방법이 없이 전통적인 업무 위탁 방식을 유지하고 있다.
분업을 둘러싼, IT조직의 문제점에 대해 살펴보도록 하자.
■분업의 약점
분업은 천성적으로 거버넌스(governance)의 문제점을 안고 있다. 당초 스스로 만들거나 생산해 온 ‘제품이나 서비스’의 ‘일부’를 외부 회사에 위임하게 되면서부터는, 요청한 제품이나 서비스의 ‘결과물’만을 전달받게 된다.
그러나, 전달받은 결과물이 요청 내용에 맞지 않거나, 기대치에 미치지 못하는 경우에 곤란한 문제가 발생한다.
분업이 아닌, 내부조직에서 만든 결과물에 대해서는 즉각 진상을 파악할 수 있겠지만, 결과물을 요청받고 생산하는, 다른 회사의 프로세스를 들여다보기란 쉽지 않다. 어떤 경우는 그런 권한 마저 거부되는 경우가 있다.
IT업계에서는, 협력업체가 물리적으로 분업을 의뢰한 조직의 ‘내부’에 위치해 있는 경우가 많다. 분업의 결과물인 신규 또는 수정된 프로그램이나, IT운영활동이 기대에 못 미칠 경우, 이에 대한 원인을 파악하기가 제조업과 같은 다른 업계에 비해 상대적으로 유리한 것으로 보인다.
하지만, IT업계에는 이러한 유리함을 상쇄시키는 장벽이 두 가지 존재한다. 국내IT조직이 따라야 하는 ‘하도급법’과 IT의 특징인 ‘만질 수 없는(intangible) 결과물’이 그 것이다.
■IT 분업의 장벽들
하도급법은 협력회사를 보호하기위해서 만들어진 법이다. ‘갑’의 위치에 있는 회사가 ‘을’의 위치에 있는 협력회사의 경영에 부당하게 간섭하는 것을 막고자 하는 취지에서 도입되었다. 하지만, 하도급법의 ‘과도’한 해석은, 분업을 수행하는 협력회사의 내부 프로세스를 들여다 보는 것 조차, 원천적으로 차단하게 만들고 있다.
프로세스를 들여다 보는 활동(글로벌 기업들은 이것을 심사-Assessment 또는 감사-Audit이라 부른다.)은, 형사 처벌이나 손해배상을 목적으로 하는 것이 아니라, 주고받는 결과물의 품질을 높이는 지극히 ‘이성’적인 활동임에도 불구하고, 국내에서는 이러한 활동을 ‘감정’적인 활동으로 받아들이는 경우가 많다.
이러한 인식과 하도급법의 과도한 해석이 화학적으로 결합하여, IT분업의 약점을 강화시키고 있다.
IT의 결과물은 만질 수가 없다. (뭐, 꼭 만지고자 한다면, CD나 서버 정도를 쓰다듬을 수는 있다.)
만질 수 없는 결과물은 ‘시각’과 ‘촉각’이 배제되어 있으므로, 확신(Assurance)하기가 쉽지 않다. 이러한 IT결과물의 특성은, 분업에 의존하는 IT조직에게 체계적이고 검증가능한 확신 방법을 ‘요구’하고 있다.
분업을 위한 프로토콜이 없다.
프로토콜(protocol)이라는 용어가 있다. 프로토콜은 개체 상호간에 커뮤니케이션하는 ‘약속된 방식 또는 룰’을 의미한다. 컴퓨팅분야에서는 커뮤니케이션의 시작부터 종료까지 서로간에 신호와 정보를 전달하는 기법을 프로토콜이라고 부른다.
분업을 의뢰한 IT조직과 협력회사간에는 협업을 위한 프로토콜이 필요하다. 업무의 시작과 종료 조건을 포함하는 상호 간의 프로세스 인터페이스 방법, 주고 받아야 할 정보, 결과물에 대한 검증 방법 등이 프로토콜에서 정해져야 하는 내용이다.
분업에 의존하고 있는 국내 IT조직 중에는, 전통적인 업무계약서만 존재할 뿐, 위와 같은 프로토콜 또는 유사한 업무 협약서가 없는 경우를 심심찮게 발견한다. 이런 IT조직의 변명은 ‘믿고 맡긴다’ 또는 ‘그런 고민할 바에는 우리가 직접한다.’이다.
■IT 프로세스의 부재
분업을 위한 프로토콜이 존재하지 않는 IT조직의 상당수는, 내부의 IT프로세스가 없거나 견고하지 못하다.
IT의 결과물을 생산하는 전반적인 라이프사이클이 프로세스로 정형화되어 있지 않으면, 그 중 일부를 떼어내서 협력회사에 분업을 의뢰하는 경우에 필요한 세부적인 입력과 출력을 정의하기가 어려울 수 밖에 없다.
견고한 IT프로세스를 가진 IT조직은 어떠한 협력회사와도 분업을 수행할 수 있는 프로세스 접점을 가지고 있다. 이것은 마치 끼우기만 하면 사용할 수 있는 범용 어댑터로 볼 수 있다.
IT조직이 전달하고자 하는 요구사항들은 IT조직의 견고한 프로세스를 통해 자연스럽게 협력회사의 프로세스로 전달 되며, 협력업체에 의해 완료된 IT의 결과물도 다시 협력회사의 프로세스를 타고 IT조직의 프로세스로 넘어올 수 있게 된다.
■부실한 검증 활동
분업의 약점을 제거하는 데 있어 ‘마지막 보루’는, 분업을 의뢰한 IT조직이 협력회사로부터전달받은 결과물을 검증하는 활동이다.
협력회사로부터 전달받은 결과물들에 대해서, 이유여하를 불문하고, 깐깐한 검증 담당자의 검증과정을 반드시 거치도록 만든다면, 어쨋든 불량품이 통과될 가능성이 낮아진다. 이 검증 담당자는 IT조직의 모든 품질 책임을 등에 지고 있는 사람이다.
그러나, 일부 IT조직들의 협업과정을 살펴보면, 검증활동 조차도 부실한 경우가 많이 있다. 협력업체가 스스로 검증했다는 자발적인 선언을, 특별한 정보에 기반하지 않고 순순히 받아들이고 있다. 설령 검증기록을 제시하는 경우도 있지만, 그 기록이라는 것을 살펴보면, ‘확신’을 가지기에는 턱없이 부족한 수준이다.
검증 활동은 검증하는 사람이 결과물에 대해 ‘확신’하는 것을 목표로 한다. ‘확신’하지 못하는 결과물은 불량품의 발생가능성이 높을 수 밖에 없다.
■분업에 대한 위험관리
IT업계에서의 분업은 이미 하나의 조류로 정착되었으며, IT가 복잡해지고 성장해 갈 수록 분업의 사례는 더욱 늘어날 것으로 보인다.
분업의 이득(benefits)을 상회하는 부정적인 사건이 발생할 가능성이 높다면, 분업을 할 이유가 없다. 하지만, 분업에 따른 위험을 잘 알고 있고, 이러한 위험을 줄이기 위한 방법을 갖추고 있다면, 분업의 이득을 극대화할 수 있다.
분업을 담당하는 협력회사의 모든 것을 장악할 수는 없겠지만, 이에 상응하는 ‘확신’을 가질 수 있도록 하는 노력을 지속적으로 기울여야 한다.
IT조직이 분업의 시대에서 살아남는 유일한 방법이다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
