복잡성 (Complexity)이란 무엇인가
시스템 관점에서...(2)
시스템 관점에서의 복잡성이 갖는 특성에 대해서 몇 가지 살펴보도록 하겠다.
1. 시스템이 가진 복잡성은 보존된다.
아마존, 야후 유저 인터페이스 최고 책임자였던 래리 테슬러는 사용자 인터페이스, 사용자 경험에 있어서 "복잡성 보존의 법칙 (The law of conservation of complexity)"을 주장했다.
The law of conservation of complexity in human-computer interaction states that every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.
앞서 언급한 것처럼 특정 기능을 수행하는 데 필수적으로 필요한 복잡성은 동일한데, 문제는 그것을 누가 부담하는가에 대한 것이다. 예를 들면 특정 제품을 만드는 회사에서 그 복잡성을 부담해주면 고객이 편하고, 만약 부담하지 않는다면, 고객이 불편해지는 것이 복잡성의 특성에서 비롯된다. 애플의 아이폰이 소비자에게 사랑을 받는 것은 소비자를 대신하여 복잡성을 부담하여 소비자는 직관적인 사용자 인터페이스를 갖기 때문이다.
2. 복잡성이 결정되는 시점과 실현되는 시점이 다르다.
시스템의 복잡성은 시스템이 만들어지는 시점에서 결정이 된다. 예를 들어서, 제품 개발 과정이 기획-개발-검증-양산 단계로 이뤄진다면, 제품의 복잡성의 대부분이 기획에서 개발 단계에서 결정이 된다는 이야기이다.
그래서, 만약 제품의 복잡성을 줄이고 싶다면, 최대한 가치사슬 앞 단계에서 보완해줘야 한다.
반면에, 복잡성이 실현되는 단계는 시스템이 만들어지는 시점부터 점차 실현이 된다. 제품의 경우 대부분의 실현은 양산단계에서 이뤄진다. 결론적으로 실현되는 시점만 보고, 양산 단계에서 복잡성을 줄이려고 해도, 벌써 복잡성 요인이 결정된 이후이기 때문에 사실상 복잡성을 줄이는 것은 불가능하다.
3. 복잡성은 시스템 경계를 넘어서면, 증폭되는 특징을 갖는다.
여러 시스템을 거쳐서 가치가 창출되는 활동에 대한 복잡성은 시스템의 경계를 넘어갈수록, 단계가 많아질수록, 증폭이 된다. 이는 꼭 필요한 복잡성뿐만 아니라, 단계별, 레벨별로 불필요한 복잡성이 커지게 된다. 인터페이스, 조직, 정보 교환 상의 문제 등으로 발생하게 된다.
다양한 모델을 양산하는 데 있어서, 총조라인에서 조립되는 하나의 어셈블리를 만약 임가공 협력회사에서 납품을 받는다고 가정하겠다. 이 부분을 표준화하거나, 단순화하지 못하고 다양한 모델만큼 변동이 된 상태로 협력회사에서 납품을 받는다면, 단순히 발생하는 복잡성을 이관하는 모양밖에 되지 않다. 게다가 역량이 보통 협력회사가 일반적으로 떨어진다고 가정한다면, 협력회사 입장에서는 비용, 품질, 일정 상의 문제를 발생시킬 수밖에 없고, 그것은 다시 총조 라인에 영향을 끼치게 된다.
4. 복잡성은 시스템의 고유의 특성으로 발생하는 메커니즘을 사실상 파악하기 어려우며, 그로 인한 비용은 예측하기 어렵다.
복잡성은 앞서 이야기한 것처럼 시스템의 고유의 특성이다. 복잡성 그 자체가 발생하는 이유가 시스템의 구성요소, 구성요소 간의 상호관계, 외부 환경과 시스템 간의 상호관계 때문에 발생하기 때문에 시스템의 고유의 특성일 수밖에 없다. 그렇다면, 그것이 발생하는 메커니즘을 찾아낼 수 있느냐, 굉장히 단순한 구조의 시스템이라면 모르겠지만, 일반적으로는 불가능하다.
그뿐만 아니라, 복잡성으로 인한 비용 또한 예측하기 어렵다.
그래서, 복잡성에 대한 지표와 복잡성의 비용을 측정하는 시스템은 보통은 복잡성을 유발하는 요소를 선정하고, 그로 인한 복잡성과 복잡성 비용을 추측하는 정도이다.
5. 복잡성 자체로는 옳고 그름을 판단할 수 없다. 복잡성이 문제를 일으킨 후의 결과만 볼 수 있을 뿐이다.
복잡성 자체만 가지고 좋다, 나쁘다를 판단할 수 없다. 시스템의 특성이기 때문에, 복잡성 자체를 없애는 것은 불가능하다. 복잡성이 나쁜 것은 복잡성이 시스템이 가진 역량을 넘어서서 시스템의 성과에 약영향을 미칠 때이다. 즉, 복잡성의 좋고 나쁨은 복잡성이 일으키는 결과로 드러난다. 단, 동일한 성과를 낸다면, 복잡성은 낮을수록 좋다.
다음은 복잡성과 복잡도에 대한 개념 차이를 설명하도록 하겠다.
복잡성과 복잡도를 구별하지 않고 사용하는 경우가 많지만, 엄밀히 따지면 구분하는 것이 맞다.
복잡성 (Complexity)는 지금까지 설명했듯이, 시스템 내외부의 조건으로 인하여 시스템의 효율에 영향을 미치는 시스템이 가지는 고유의 특성으로 그 메커니즘이 알기가 어렵기 때문에, 하나의 표현이나 수치로 표현하기 사실상 불가능하다.
복잡도 (Complexity Metric)은 복잡성을 일으키는 다양한 요소나 그 안의 상호관계 등을 단순화하고 선택하여 복잡성을 수치로 표현한 것을 의미한다. 복잡도는 시스템이 가진 복잡성의 일부 메커니즘만 수치화를 했기 때문에, 복잡성을 모두 표현했다고 볼 수 없다.
보통 시도를 하는 것이 복잡성을 측정할 수 있는 복잡도 (Complexity Metric)을 정의하는 것인데, 히든 리스크에서는 기업이 가진 복잡성을 법인수, 제품수, 조직수 등을 곱하기로 나타냈는데 정의하는 것이 문제가 아니라, 그 지표가 의미가 있는가이다.
현상을 있는 그대로 표현하는 완벽한 지표를 만드는 것은 어렵다.
하물며, 모든 정보가 공개된 상황에서도 완벽한 지표를 만드는 것이 어려운 데, 복잡성 그 자체가 완벽하게 이해되지 않은 상태에서 성급하게 만들어진 복잡도는 단순 수치에 그칠 가능성이 있다.
그렇다면, 복잡성을 나타내는 지표, 복잡도 (Complexity Metric)은 필요 없는 걸까?
필요 없다기보다는 그것을 통해서 현상을 어떻게 설명할 것인지, 그것을 통해서 어떤 액션을 이끌어낼 것인가를 고민하여 결정해야 한다.
예를 들어서, 늘어나는 모델의 종류로 복잡성이 늘어나고 있는 것 같다고 생각된다면, 복잡도를 "모델 종류수"로 정할 수도 있을 것이다. 그리고, 모델 수를 최적화하는 방안을, 그리고 그 결과를 다시 "모델 종류수"로 표현된 복잡도로 측정하면 될 것이다.
그런데, 이런 지표는 지양해야 한다. "모델 종류수"와 "부품 수"가 복잡성에 영향을 미치는 요인인 것으로 밝혀내고, 이 둘 간의 관계를 무시한 채 "모델 종류수 X 부품 수", "A X 모델 종류수 + B X 부품 수" 같이 하나의 수식으로 나타내려고 노력하는 것은 피해야 한다.
표면적으로는 단위가 다를 뿐만 아니라, 이렇게 얻어낸 수치는 직관적이지 않아서 복잡하게 설명해야 할 필요가 있고, 실행하는 부서나 인원이 납득하지 못할 수 있다. 복잡성과 복잡성 요인을 구분을 해야 한다고 말한 적이 있다. 오늘은 복잡성 요인 (Complexity Factor)에 대해서 자세히 살펴볼까 한다. 복잡성에 대한 정의 자체가 복잡성은 그 정의나 메커니즘을 파악하기가 어렵다는 전제가 깔려있다.
복잡성을 표현하거나, 파악하는 대신, 우리는 복잡성을 일으키는 요인, 즉 복잡성 요인 (Complexity Factor)를 활용할 것이다.
