스케쥴링 시스템은 왜 실패해 왔는가 ? (1)


스케쥴링 시스템은 왜 실패해 왔는가 ? (1)



    스케쥴링 문제는 매우 어렵고 풀기 힘들다는 이야기를 들어 보신 일이 있으실 것입니다. 그러나, 스케쥴링은 생산 시스템의 효율적인 운영과 제어라는 책임을 지니고, 생산관리시스템의 여러 모듈중 최전선(?)에서 피눈물나는 전투를 치루고 있답니다. 거의 모든 제조 업체들은 나름대로의 스케쥴링 시스템 또는 스케쥴링 로직을 가지고 있지만, 스케쥴링에 관련된 업무를 담당하고 있는 사람들은 종종 불만을 토로하기도 합니다. 심지어는 전산화된 스케쥴링 시스템이 사장되고, 작업자 또는 관리자에 의해서 급한대로 주먹구구식으로 스케쥴링이 이루어지기도 합니다. 이렇게 스케쥴링 시스템의 전산화가 실패하는 이유를 하나씩 분석해보도록 하겠습니다.

    앞에서 스케쥴링 문제를 '자원','작업','목적'이라는 주요 구성 요소를 기반으로 분류하여 보았습니다. 아직 이런 스케쥴링 문제의 복잡도(complexity)에 대해서는 설명드리지 않았지만, 실제 제조 시스템에서 볼 수 있는 대부분의 문제들은 (근사)최적해를 구하기 어려운 매우 어려운 문제들입니다. 따라서, 대부분의 스케쥴링 시스템은 만족할만한 해를 빨리 구하는데 치중하고 있습니다. 그나마, 이런 스케쥴링 시스템들이 만족스럽게 돌아가고 있는 곳은 많지 않습니다. 심지어는 스케쥴링 시스템이 사장된채, 작업자 또는 관리자에 의해서 급한대로 주먹구구식으로 작업을 진행하는 일이 흔합니다. 전산화된 스케쥴링 시스템의 실패 원인은 무엇일까요? 

    전산화된 스케쥴링 시스템이 실패하는 원인은 스케쥴링 문제가 다양한 만큼이나 다양합니다. 이런 실패 원인을 하나씩 정리해보고, 극복할 수 있는 방법도 나름대로 생각해보도록 하겠습니다. 본 절에서는 이런 실패 원인의 하나로 스케쥴링 시스템과 작업자 또는 관리자의 관계를 살펴보도록 하겠습니다. 

    지금도 국내외 유수의 학회지를 보면, 스케쥴링은 중요한 문제로 자주 다루어지고 있습니다. 특히나, 컴퓨터 기술의 발전과 더불어 계산 능력이 증대됨에 따라 스케쥴링 관련 분야가 새롭게 부각되고 있습니다. 그러나, 학계에서 다루는 스케쥴링 문제는 적지 않은 한계를 가지고 있습니다. 그 대표적인 한계가 많은 연구들이 '간단하고 작고 잘 정형화된 문제'를 대상으로 이루어지고 있다는 것입니다. ( 저는 개인적으로 이런 연구들이 정말 많이 필요하다고 생각합니다. 그 이유는 이후에 병목 기계나 병목 공정, OPT나 TOC와 같은 스케쥴링 방법에 관하여 설명드리면서 다루기로 하지요. ) 더욱 더 큰 문제는 스케쥴링 문제를 푸는 과정에서 사람의 개입을 고려하고 있지 않다는 것입니다. 예외적인 부분으로는 Gantt Chart의 디자인이나 기능과 같은 부분이 있지만, 스케쥴링 시스템과 사람간에 feedback이 거의 이루어지지 않고 있다는 것이지요. (물론 feedback이 존재하기 어렵거나, 이를 배제하는 시스템도 있습니다.) 

    스케쥴링 문제를 풀기위해서는 스케쥴링 문제의 정의가 선행되어야 합니다. 스케쥴링의 대상이 되는 자원이나 작업에 대한 파악과 그 관계(constraint), 그리고 스케쥴링 시스템에 대한 요건(requirement) 들이 잘 정의되어야 합니다. 그러나, 상황에 따라서는 스케쥴링 문제를 잘 정의하는 것이 단기적으로 매우 힘든 경우도 있습니다. ( 참고로, ERP의 구현 대상이 되는 기업의 경우에도 조직도 변화하며, 프로세스도 변화하듯이 스케쥴링 시스템의 대상이 되는 생산현장도 단기적으로 장기적으로 항상 변화하는 동적인 환경입니다. ) 이런 상황에서 스케쥴링 시스템만큼이나 중요한 것이 사람의 역할입니다. 컴퓨터를 이용한 해법은 정형화된 문제에 대해서는 적용 가능성도 높고 적용 효과도 크지만, 정형화하기 곤란한 문제에 대해서는 사람이 전산 시스템보다 문제를 잘 풀지요. 뿐만 아니라, 때로는 주어진 알고리즘을 이용해 전산 시스템이 만들어낸 해보다 사람이 보다 좋은 해를 만들 수도 있지요. 똑똑한 사람에게 멍청한 컴퓨터가 만들어낸 해를 강요하면, 어떤 사람이 좋아할 수 있겠습니까? ^_^ 

    산업공학의 큰 연구분야중에 '인간공학(Human Factor)'라는 것이 있습니다. 이런 상황에서 기여할 수 있는 분야는 전문가 시스템보다는 '인간공학'의 적용이 더 큰 효과를 발휘합니다. (전문가 시스템과 스케쥴링에 관해서는 이후에 이야기할 기회가 있으리라 믿습니다.) 이야기가 길어지고 있는데, 결국 '사람'의 역할을 무시한 전산화된 시스템은 실패할 가능성이 매우 크다는 것이지요. '사람의 역할'과 '전산화된 스케쥴링 시스템의 역할'에 관한 학계의 연구 중에서 Vicent C.S. Wiers와 Tjer W. Van Der Schaaf라는 분이 쓴 'A framework for decision support in production scheduling tasks' (Production Planning & Control, Vol. 7, No. 6, 1997) 라는 논문 중에서 일부를 소개드리도록 하지요. 

    저자들은 제조업체들을 대상으로 스케쥴링 시스템이 잘 사용되고 있는지, 그리고 생산현장의 특성에 부합되는 스케쥴링 시스템은 어떤 것인지에 관해 조사하고 분석해 보았다고 합니다. 저자들은 크게 생산현장의 불확실성( Uncertainty )과 자율성을 바탕으로 한 작업자의 문제 해결 능력( Human Recovery )이라는 2가지 요소를 가지고, 제조업체와 스케쥴링 시스템을 분석해보았습니다. 참고로, 기계 고장이 잦다거나, 작업시간이 정확히 예측되지 못하는 경우를 '생산현장이 불확실성하다'라고 표현했습니다. 그리고, 문제가 발생했을 때 사람들이 이 문제를 해결하는 것이 가능한 경우를 Human Recovery라고 했는데, 이 때에는 사람(작업자 또는 Human Scheduler)에게 자율성이 부여되어 있어야 합니다. 

    이들이 발견한 것은 스케쥴링 시스템이 성공적으로 운영되기 위해서는 이 2가지 요소에 의해 나뉘어진 환경에 맞게 스케쥴링 방법이 선택되어야 한다는 것이었습니다. 이를 표로 나타내면 다음과 같습니다. 

    생산현장에 불확실성이 없음.생산현장에 불확실성이 많음.
    Human Recovery 불가능Smooth Shop, 
    컴퓨터에 의한 (근사)최적 스케쥴의 생성이 필요함.
    Stress Shop, 
    빠른 feedback이 보장되는 reactive scheduling 방법이 요구됨.
    Human Recovery 가능Social Shop, 
    가능한 최적화를 하되, 현장에 일부의 자율성을 부여하는 것이 요구됨.
    Sociotechnical Shop, 
    간단한 발견적기법(heuristic)을 이용이 권장됨. 작업장에 많은 자율성을 부여하는 것이 필요.

    저자들이 이런 결론을 내리기에 앞서, 여러 제조업체를 대상으로 분석을 해 보았다고 합니다. 예를 들어, 생산현장에 불확실성도 많고, Human Recovery가 가능한 상황인데, 억지로 힘들여 (근사)최적해를 생성하는 스케쥴링 시스템은 실패했다는 등의 사례가 있습니다. 결국 스케쥴링 시스템에 의해 생성된 결과는 작업자에 의해 수행되게 됩니다. 그런데, 생산현장의 불확실성이나 작업자의 자율성을 무시한채 만들어진 스케쥴은 배척을 받게 된다는 것이지요. 그리고, 작업자의 자율성을 인정한다 하더라도 적절한 feedback관계가 스케쥴링 시스템과 작업자간에 존재하지 않게 되면, 역시 스케쥴링 시스템은 사장된다는 것이지요. 

    어쩌면 아주 간단명료한 주제를 가지고 이야기가 길어진 것도 같지만, '사람의 역할'이란 절대 무시할 수도 없으며, 무시되어서는 안되는 것입니다. 자동화라는 것은 사람을 보조하고, 사람들의 행복을 위해 진행되어야지, 무조건적인 사람의 대체나 배척으로 진행되어서는 결코 성공할 수 없다는 것이지요. 

    광고 ^_^ : 제가 속한 공장자동화연구실(지도교수 : 박진우) 의 표어(motto)는 'Freedom from Labor and Hard Work !! Pastoral-like and Home-like Factory !!' 입니다. 모두가 밝은 표정을 가지고 일할 수 있는 공장을 만들고, 그렇게 운영하는 것이 교수님과 저, 그리고 다른 학생들의 꿈이랍니다. 

    본 페이지는 1998년 4월 4일에 작성되었습니다.