비즈니스 관점의 프로세스와 IT 관점의 프로세스

분석 설계를 진행하다 보면 프로세스라는 단어가 많이 등장하고, 이는 어떤 관점에서 이를 바라보는가에 따라서 그 의미와 해석의 차이를 느끼게 된다. IT에 대한 지식이 전혀 없는 사람이 프로세스라는 단어를 언급하는 것을 보면 시스템에서 제공하는 기능과 사람이 처리하는 기능이 한데 섞여져 있어서 마치 사람의 행위를 시스템이 처리하는 것과 같은 인상을 받을 때도 있다. 반면에 IT를 수행하는 사람의 관점에서 프로세스라는 단어를 들을 때에는 사용자의 행위와 화면과의 연계, 내부 모듈 및 시스템 간의 연계되는 관계를 상세하게 생각하여 오프라인에서 수행되는 프로세스를 마치 시스템 내부에서 진행하는 형태로 착각하기도 한다.

모든 프로세스가 시스템화되는 것이 가장 바람직하다고도 볼 수 없으며, 시스템화되지 못한 프로세스를 전혀 무시하도록 시스템을 만드는 것 역시 바람직하지 않다고 볼 수 있다. 우선은 기술과 자원의 한계로 인해 시스템화되지 못하거나 시스템화시키기에는 너무나도 다양하고 복잡한 경우의 수가 시스템으로 제어할 수 있는 범위를 초과하여 사람의 판단 능력으로만 수행할 수 밖에 없는 프로세스는 오프라인으로 처리가 된다. 이러한 프로세스들은 현재 시스템에서 처리할 수 없다고 하더라도 앞으로 어느 시점에서는 시스템화하여 처리할 수 있는 가능성이 있기 때문에 (실제로도 이러한 시점들이 점점 더 빨라지고 있는 상태이다) 지금 만들고 있는 시스템에서 이러한 가능성에 대한 부분을 어느 정도는 고려할 필요는 있다.

Hypnosis by Thomas Hawk

IT 관점에서의 프로세스는 비즈니스의 상황을 고스란히 반영하고는 있다고 볼 수 있지만, 위와 같은 차이로 인해서 현실 세계에서는 시스템의 프로세스와 현장에서 수행되는 프로세스에는 분명 차이가 발생하게 된다. 이러한 차이는 기존에 예상치 못한 또 다른 프로세스를 만들어내며 이러한 프로세스로 인해서 문제를 만들어내기도 한다. 특히, 중요한 프로세스(예를 들어, 결재나 승인과 같은 프로세스)가 시스템을 통해서 처리될 때에는 다양한 현실 세계를 반영하지 못한 시스템의 프로세스는 사용자의 불편과 상위 권한자의 영향력으로 인해서 기존 분석 설계시 반영되었던 프로세스가 예상치 못한 상태로 프로세스가 어그러지기 시작한다.

프로세스 감시와 통제

프로세스는 업무의 흐름이며, 이러한 업무 흐름은 조직의 특성상 감시와 통제를 받게 된다. 시스템에서 구현된 프로세스는 이러한 감시와 통제의 영역을 비즈니스 로직이나 별도의 시스템과의 연계를 통해서 프로세스를 제어하게 되는데, 이 경우 특정 권한을 가진 자나 특정 사용자에 대한 예외 처리로 인해서 정상적인 흐름과는 전혀 다른 흐름을 만들어내기도 한다. 혹은 채널 특화된 프로세스를 만들어내는 경우에도 정상이라고 보아왔던 흐름에 대한 변이가 발생하고 그러한 처리는 별도의 비즈니스 로직 구멍을 만들어낸다. 이러한 구멍들이 하나 둘씩 생기다보면 전반적인 비즈니스 흐름은 통상 현장의 사용자들이 인식하는 정상적인 흐름을 처리하는 시스템이 아닌 비정상적이면서 아주 복잡 미묘한 업무 흐름을 형성하게 된다.

이러한 상태에서의 시스템은 최초에 인식했던 정상적인 감시나 통제에서 벗어난 또 다른 비즈니스 흐름의 패턴을 형성하게 되며 여기에 사용자의 기만이나 허위가 들어가게 되면 프로세스의 감시나 통제를 시스템화해서 가시화시키겠다라는 목적을 잃어버리게 된다. 통합 로깅이나 이벤트 로그 역시 프로세스를 어느 정도 가시화시키는 장치이지만, 이를 체계적으로 분석하고 시스템에서 구현된 프로세스와 매핑을 시켜야지만 제대로 모니터링이 가능하다.

특히, 다양하고 이질적인 시스템과의 연계를 통해서 이루어지는 업무 프로세스의 경우에는 이러한 현상이 더 심화될 수도 있다. 시스템 간에 단순히 데이터만 주고 받는 형태이며 이전과 이후의 프로세스는 아무런 연관이 없는 것처럼 처리될 수 있으며, 이는 현실 세계에서의 업무 형태와는 사뭇 다른 형태로 구현되기 쉽상이다. 예를 들어, 주요 업무에 대한 처리를 수행하는 시스템과 결재 시스템이 별도로 운영된다고 보면, 결국 주요 업무를 처리하는 비즈니스 로직에는 결재 시스템의 결과에 따라서 제어되어야 하지만, 결재 시스템이 제대로 운영되지 않거나 인사 시스템과의 연계가 복잡해지는 경우에는 주요 업무에 대한 처리 흐름과 결재의 흐름이 전혀 연관성이 없이 운영되는 경우도 있다. 즉, A에서 B로의 업무 흐름이 중간에 결재권자에 의해서 처리되어서 넘어가야 하지만, 여러가지 이유로 인해서 결재 시스템과의 연계를 무시하거나 제대로 운영되지 못해서 업무 흐름은 진행되고 결재는 별도로 형식적으로 처리되는 경우가 발생할 수 있다.

이러한 시스템에서의 허점은 그대로 현실 업무에도 영향을 미쳐서 감시를 아무리 철저하게 하더라도 서로 관련이 없는 형태로 모니터링이 되기 때문에 아무런 관련을 찾기 못하게 되며, 이는 내부 비리로까지도 발전할 수 있는 형태가 된다. 아무리 시스템에서 허점을 보완한다고 하더라도 전반적인 비즈니스 흐름의 연계와 모델링이 되지 않거나 운영 중에도 이러한 모델을 재설계하여 반영하지 못하면 이러한 구멍은 점점 더 커지거나 복잡한 흐름을 낳게 된다.

프로세스 통합과 변이

현실 세계의 업무가 시스템화되면서 불필요한 프로세스를 없애거나 기존 프로세스를 표준화시키려는 작업이 발생되어 통합시키려는 일들이 발생한다. 통합된 프로세스는 세부적인 업무들에 있어서 다양한 변이들을 수용해야 하기 때문에 내부적으로는 예외처리들이 그 안에 내재되어 있게 된다. 이러한 예외처리들은 운영 시스템에서 더 극대화되어서 최초 설계한 의도와는 다르게 변이들을 더 다양한 형태로 만들고, 통합과는 다른 복잡한 프로세스들을 양산하게 된다.

통합의 또 다른 측면은 인터페이스의 크기를 더 크게(wide) 만든다는 것이다. 하나의 인터페이스로 (거의) 모든 경우의 수를 처리하려다 보니 처음에는 한두개의 변이 데이터들이 들어갔던 signature가 점점 더 거대하게 변해가면서 초대형(ultra-wide) 인터페이스를 만들게 된다. 통합의 또 다른 단점이지만, 이러한 상태의 시스템은 모든 진입점이 하나로 모아지면서 전반적으로 유연하거나 경량의 시스템으로 구축하는데 어려움을 겪게 된다.

또한, 변이에 대한 처리에 있어서 기존 정상적인 처리와 유사한 기능을 추가할 때 추가되는 기능의 특성에 따라서 통합 영역에 속하게 되는지를 고려해야 한다. 예를 들어, 결재권자의 정보를 위해서 이를 추가하는 경우에 해당 프로세스는 바로 결재 시스템과의 연계가 필요하게 되며, 내부적으로는 결재 결과에 대한 유효성 로직으 추가되어야 한다. 이는 현실 세계에서 유사하게 보이는 업무이지만 시스템 입장에서는 전혀 다른 별개의 프로세스를 어거지로 통합하는 형태가 되어서 시스템의 전반적인 구조가 점점 더 복잡하게 형성되는 결과를 초래한다.

이러한 형태를 구성하게 되는 가장 대표적인 영역이 배치나 화면 링크의 요구이다. 주요 기능에 대해서 배치에서 동일하게 구성하려면 시간이 걸려서 배치에서 요청하는 기능을 주요 기능의 구현체를 호출하도록 구성하게 되면 점차 배치에서의 예외 처리들이 점점 주요 기능 속으로 들어오게 되며, 화면 링크의 경우, 동일한 화면과 기능이라고 하더라도 서로 다른 사용자의 권한이나 처리 요구로 인해서 그러한 기능들이 점차 주요 기능으로 포함되면서 통합된 기능은 이것 저것 모든 것을 끌어안은 초통합(ultra-integrated) 비즈니스 로직을 구성하게 된다. 

프로세스의 변화 

통상 업무 프로세스는 휘발성이 강하다. 업무 프로세스는 고객의 요구, 업무 환경의 변화 등으로 인해서 잦은 수정이 발생될 수 밖에 없으며, 분석 설계시에 고려된 사항들이 운영시점에 나타나는 다양한 문제들을 해결하기 위해 프로세스 영역의 변화를 주게 되면 점차로 휘발성의 성격이 찐득하게 변해서 휘발되지 못하는 성질을 가지고 있다.

프로세스가 휘발성이 되도록 처리하려는 노력은 늘 필요하며, 이는 시간의 흐름을 따라 변화되는 고객의 요구와 환경의 변화를 수용할 수 있도록 구성되어야 한다. 특히, 운영 시점에서의 프로세스에 대한 변화는 발생될 수 밖에 없는 상황이며 이를 수용하지 못하는 구조에서는 아무리 데이터 구조를 유연하게 설계했다고 하더라도 시스템의 유연성을 크게 손상시키게 된다. 이와 같은 상태로 시스템이 구성된 형태에서 로깅을 통해 프로세스를 분석하고자 하면 엄청나게 복잡하고 경우의 수가 많은 업무 흐름들이 나타나게 되고, 이를 재구조화시키거나 재설계를 하려는 목적으로 사용하기에는 너무나도 많은 노력을 들일 수 밖에 없다. 프로세스에 대한 로직을 변경하고자 할 때에는 반드시 전체적인 업무 흐름의 상황을 고려할 필요가 있는데, 해당 변화로 인해서 영향을 미치는 범위까지도 고려해야 한다.

현실 세계에서의 프로세스 변화에 대한 요청은 점차적으로 그 주기와 개발 기간의 단축의 강도가 심해지고 있다. 프로세스를 변화하지 못하면 버티지 못하는 업종들의 대부분은 거의 모든 주요 업무들이 시스템화되어 있는 상황이며, 이러한 변화 요청에 따라서 시스템은 반응의 정도에 따라서 현실 세계의 업무는 또 한번의 변동이 발생된다. 다시 말해서, 이상적이라면 현실의 요구를 시스템이 그대로 받아들여야 되지만, 시스템이 그러한 요구를 받아들이는 한계는 분명 존재하기 때문에 프로세스에 대한 변화의 요청은 결국 현실 세계의 업무와 시스템의 업무가 어느 정도 양보하는 형태로 변화될 수 밖에 없다.

이러한 프로세스의 변화가 비정상적이라는 용어로 사용하기도 하지만, 원래의 프로세스에 대한 성격으로 보아야 하며, 비정상적인 프로세스의 변화는 없다고 봐야 한다. 절대 권한자의 요구사항 역시 시스템을 운용하는 측면의 관점이기 때문에 프로세스의 흐름의 어디에도 이러한 요구가 수용되도록 구조화를 시킬 필요가 있으며, (최소한 그러한 요구를 프로세스가 처리할 수 없다고 하더라도 다른 형태로 요구를 수용할 수 있도록 우회하려는 노력이 필요하다)  이러한 요구가 절대 기존의 정상적인 처리 흐름에 영향을 미쳐서는 안된다.