다음은 이러한 질문들에 대한 답변이다.

2.2.1. Rule Engine 사용의 장점

Declarative Programming선언적 프로그래밍 방식

Rule engines은 ‘어떻게 해야 하는가’(How to do it) 아닌 무엇을 해야 하는가’What to do’에 집중할 수 있게 해 준다.

이것의 핵심적인 장점은, 룰을 사용하는 것이 복잡한 문제점들의 해법을 좀더 쉽게 표현할 수 있게 만들어 준다는 것이다. 결론적으로 이 솔루션들이 검증될 수 있도록 해준다. (룰은 코드보다 읽기가 훨씬 쉽다)
룰 시스템은 엄청나게 복잡한 문제들을 푸는것이 가능하다, 그 해법이 어떤 과정을 거쳐서 결론지어졌는지, 각각의, 해당 결론이 내려지는 각각의 단계에서 어떻게 ‘결정(decision)’이 이루어졌는지에 대한 설명을 제공함으로써.(이것은 Neural Network이나 Human Brain 같은, 다른 Ai시스템에서는 쉽지 않은 일이다. 

• Logic and Data Separation 로직과 데이터의 분리
  

  여러분의 데이터는 여러 분의 도메인 객체 내에 있고, 로직은 룰들 내에 존재합니다. 이것은 기본적으로 객체 지향 시스템의 데이터와 로직의 결합이라는 원칙을 깨뜨립니다. 이것은 보는 관점에 따라서 장점이 될수도 있고, 단점이 될 수도 있습니다. 장점은 로직이 보다 관리하기 쉬워지고, 나중에 보다 쉽게 변경할 수 있다는 것 입니다. 로직이 룰 안에 내재되어 있기 때문입니다. 이것은 로직이 크로스 도메인이거나 멀티 도메인인 경우 보다 부각됩니다. 로직을 매우 많은 숫자의 도메인 객체와 컨트롤러들에 분산시키기 보다는, 그것을 하나, 혹은 그 이상의 독자적인 룰 파일들에 조직화할 수 있습니다.

  
  
• 속도와 확장성
  

  Rete 알고리즘, Leaps 알고리즘과, Drools의 ReteOO(그리고 leaps)같은 그것의 파생 알고리즘들은 룰 패턴을 도메인 객체 데이터에 매칭시키는 매우 효과적인 방법을 제공합니다. 이것은 여러분이 전체적으로 변경되지 않는 데이터집합을 가지고 있을때 특히 유용합니다.(이러면 룰 엔진이 과거의 매칭 결과들을 기억할 수 있도록 해 줍니다.) 이러한 알고리즘들은 경쟁을 통해서 증명되었습니다.

  
  
• 지식의 중앙 집중화
  

  룰을 사용함으로써, 여러분은 지식의 저장소를 생성할 수 있습니다 (지식베이스스) 이것은 실행 가능합니다. 이것은 여러분이 비즈니스 정책을 구축하기 위한 사실 관계들만 모아놓은 단일 저장소를 의미합니다. (예를 들자면) 이상적으로, 룰은 매우 읽기 쉽기때문에 바로 문서로써 제공될수도 있습니다.
  도구 통합
  Eclise 같은 도구들은,(차후에는 웹 기반의 Ui를 제공 예정) 룰을 수정하고 관리할 수 있는 방법을 제공하며, 즉각적인 피드백, 유효성 검증, 그리고 컨텐츠 지원들을 제공합니다. 감사 및 디버깅 도구들도 역시 사용가능합니다.

  
  
• 설명 Explanation Facility
  

  룰 시스템은 효과직으로 설명 기구를 제공한다. 이것은 결론이 추론되기까지 왜 이런 결정들이 이루어졌고 최종 결론들이 만들어졌는지를 로깅할 수 있는 기능을 제공함으로써 이해하기 쉬운 룰을 여러분의 문제 도메인을 표현하기 위한 객체 모델들과 부가적인 도메인 특화 언어들을 생성함으로써, 여러분은 마치 자연어처럼 보이도록 룰들을 기술할 수 있습니다. 이것들은 실제 로직을 표현하지만, 보다 이해하기 쉽고, 가능한한 기술적인 내용들을 배제하여, 도메인 전문가가 그들 자신의 언어로써 룰을 표현할 수 있도록 합니다. 모든 프로그램 기법들이 사용 가능하지만, 실제 코드에서 그것들이 어떻게 이루어지는지는 사용자로부터 숨겨집니다.

2.2.2. 언제 룰 엔진을 사용해야 합니까
이 질문에대한 가장 짧은 대답은, “전통적인 프로그래밍 접근방식으로는 문제를 해결하기 위한 만족스러운 방법을 찾을수 없을때”입니다. 이 짧은 대답을 하면, 보다 자세한 설명이 요구됩니다. 이것은 “전통적인”접근방식이라는것은 아마도 다음중 하나일 것이기 때문입니다.

• 문제가 전통적인 코드 방식으로 풀기에는 지나치게 간단한 경우
  

  문제점은 복잡하지 않을수도 있습니다. 그렇지만 여러분은 해법을 구축하기 위한 견고하고 확실한 방법을 찾을수 없을수 없습니다.
  문제를 풀기 위한 명확한 알고리즘에 기반한 솔루션이 없는 경우.
  복잡한 문제이지만, 명확하고 전적인 솔루션이 없거나, 기본적으로 문제가 전체적으로 이해할수 없는 경우.

• 로직이 자주 변경되는 경우.
  

  로직 그 자체는 매우 단순할수도 있지만 (꼭 단순할 필요는 없다) 그러나 룰들이 매우 자주 변경될 경우. 많은 조직들에서 소프트웨어 릴리즈를은 자주 변경되지 않지만, 룰들을 변경하므로써 요구되는 기민성을 제공하고, 합리적이면서 안정적인 방법을 기대할 수 있다.

• 도메인 전문가(혹은 비즈니서 전문가)가 준비되어 있지만, 기술적인 내용에 대해 잘 모르는 경우.

도메인 전문가는 종종 비즈니스 룰과 프로세스들에 관한 풍부한 지식을 가지고 있지만, 전형적으로 기술적인 부분에 취약하다. 그렇지만 그들은 매우 논리적이다. Rules는 그들이 로직을 그들 자신이 이해할 수 있는 용어들을 사용하여 표현할 수 있도록 해 준다. 물론, 그들은 여전히 핵심적인 사항들에 대해 고민해야 하고, 논리적으로 생각할 수 있어야 한다. 약간 기술적인 야치에 있는 많은 사람들이 정규 논리에 대한 교육을 받지 않았기때문에, 그들과 함께 일할때는 매우 주의해야 한다. 룰 내의 코드화된 비즈니스 규칙으로 인해, 여러분은 종종 현재 이해되어지고 있는 비즈니스 로직과 프로세스들 내에 취약점을 노출시킨다. 버그..)

만약 룰이 여러분의 프로젝트 팀에 새로운 기술이라면, 이론적인 내용을 배우는데 많은 시간을 할애야야 할 것이다. 이것은 쉬운 기술은 아니지만, 이 문서에서는 그것을 보다 쉽게 표현하려고 노력하였다.
현대의 객체 지향 어플리케이션 내에서 전형적으로 여러분은 비즈니스 로직의 핵심 부분을 저장하기 위해서 룰 엔진을 사용하려고 할 것이다 (비즈니스 로직이 무엇을 의미하는지는 물론 어플리케이션에 따라 달라질것이다) ? 이것이 특히 정말로 너저분한 부분이다. 이것은 모든 로직을 여러분의 객체에 캡슐화한다는 객체 지향 개념을 뒤집는 것이다. 이것은 여러분이 객체 지향 실 예들을 던져 치워버리라는것을 의미하는것이 아니고, 반대로, 실 세계의 어플리케이션내에서 비즈니스 로직은 단지 어플리케이션의 한 부분이는라 것이다.

만약 여러분이 엄청나게 많은 if, else, switch 문이나, 엄청나게 많은 strategy 패턴, 그리고 다른 적절해 보이지 않는 너저분한 로직을 여러분의 코드 내에서 발견했다면(여러분은 그것을 계속해서 반복해서 고쳤을 것이다. 여러분이 잘못했기때문이거나, 로직이나, 여러분의 로직에 대한 이해도가 변경되었기 때문에) 이런 경우 룰을 사용하는 것을 고려해보라. 만약 여러분이 기존의 알고리즘이나 패턴을 사용하여 풀기 어려운 난해한 문제에 부딛혔을때 룰을 사용하는것을 고려하라.

Rules는 어려분의 어플리케이션에 내장된 형태로 사용되거나 또는 서비스로써 사용될 수 있다. 종종 룰즈는 ‘유상태’ 컴포넌트로써 가장 잘 동작한다 ? 그래서 그들은 종종 어플리케이션의 통합 파트가 된다. 그러나 ‘무상태’ 컴포넌트를 사용하여 재사용 가능한 룰 서비스를 생성한 성공적인 케이스들이 있었다.

여러분의 조직 내에서 여러분이 시스템 내의 룰을 프로덕션중인 시스템 내의 룰을 업데이트하는 프로세스에 관해 생각하는것이 중요하다면, (옵션들은 많지만, 서로 다른 조직들은 서로 다른 요구사항들이 있다. 종종 그것들은 어플리케이션 벤더나 프로젝트 팀들의 제어권에서 벗어나 있다.)


2.2.3. 언제 룰 엔진을 사용해서는 안되는가
Drools 메일링 리스트의 정규원 Dave Hamu의 말을 인용하면.

 룰 엔진들이 동적이므로 (룰이 데이터처럼 저장되고, 관리되고, 업데이트될 수 있다는 의미다), 그것들은 종종 소프트웨어를 배포하는 문제를 해결하기 위한 솔루션처럼 보인다.(대부분의 IT 부선는 소프트웨어가 rolled out되는것을 금지하기 위한 의도로 존재하는것처럼 보인다) 만약 이것이 여러분이 룰 엔진을 사용하고 싶어하는 이유라면, 룰 엔진이 여러분이 선언적 룰을 사용할 수 있을 경우에만 최선으로 동작한다는 것에 유의하라. 대체품으로써, 여러분은 데이터 드리븐 디자인을 고려할 수 있다(룩업 테이블 같은), 혹은 스크립트 프로세스 엔진을 고려할 수도 있다. 스크립트들이 데이터 베이스 안에 저장되고 관리되기 때문에, 동적으로 업데이트 할 수 있는 것들 말이다.

2.2.4. 스크립팅, 또는 프로세스 엔진.

기쁘게도, 이전 섹션은 여러분에 언제 룰 엔진을 사용하기를 원할 수 있을까에 대해 설명하였다.

대체 방안은, 스크립트 기반의 엔진이다, 이것은 운영중 변경을 위한 역동성을 제공한다. (여기에는 매우 많은 솔루션들이 있다)

대체 Process Engines (또한 워크플로우 엔진)같은 것들, 예를들어 jBPM은 여러분이 시각적으로 (또는 프로그램적으로)프로세스 내의 단계를 기술할 수 있도록 만들어준다.
- 이러한 단계들은 또한 결정 시점(decision point)를 포함할 수 있으며, 결정시점은  그 내부에 간단한 룰을 가지고 있다. 프로세스 엔진들과 룰은들 종종 매우 함께 잘 동작한다. 그래서 둘중 하나만 취할 수 있는것이 아니다.

룰 엔진을 기술하기 위한 한가지 핵심 포인트는, 몇몇 룰 엔진들이 실제로는 스크립팅 엔진이라는 것이다. 스크림팅 엔진들의 downside는 여러분이 당신의 어플리케이션을 스크림팅 엔진과 강하게 결합시켜야 한다는 것이다. (만약 그것들이 룰들이라면, 여러분은 룰들을 직접적인 방식으로 효과점으로 호출해야 한다) 그리고 이것은 차후의 유지보수를 더욱 어렵게 만들수도 있다. 그것들이 시간이 지남에 따라 복잡도가 증가하는 경향이 있기 때문에다. 스크립팅 엔진의 장점은 그것들이 초기에 구현하기가 훨씬 쉽다는 것이다. 그리고 여러분이 빠른 결과를 받아볼수 있다는 것이다. (그리고 imperative 프로그래머들에게 개념적으로 훨씬 쉽다)

많은 사람들이 데이터 드리븐 시스템을 성공적으로 구현해왔다. (여러분의 어플리케이션의 행동양식을 변경하는 메타데이터를 저장하고 있는 컨트롤 테이블들이 있는)
이것들은 컨트롤이 매우 제한적인 상태로 남아있을때 매우 잘 동작할 수 있다. 그러나 컨트롤이 지나치게 많아지는 경우, 빠르게 제어권을 상실할 수 있다. (이런 경후 최초 개발자만이 어플리케이션의 행동양식을 변경할 수 있다.) 혹은 그것이 어플리케이션이  지나치게 유연하지 못하게되어 정체되도록 만들수도 있다.

2.2.5. Strong and Loose Coupling
여러분은 아마도 ‘tight coupling’이라는 용어와 ‘loose coupling’ 이라는 용어를 시스템 디자인 관련해서 들어보았을 것이다. 일반적으로 사람들은 디자인적인 측면에서 loose나 weak coupling 이라고 주장하기를 더 좋아한다, 왜냐하면 이것이 유연성을 제공하기 때문이다. 유사하게, 여러분은 ‘strongly coupled’, ‘weakly coupled’ 룰이라는 용어를 사용할 수 있다.

강하게 결합되었다는 것은, 하나의 룰이 실행되면, 반드시 관련된 또다른 룰이 실행된다는것을 의미한다. 달리 말하면, 룰간에 연결고리가 있다는 것이다. 만약 여러분의 룰들이 강하게 결합되어 있다면, 나중에 룰을 변경하는데 있어 유연함이 떨어질것이고, 더움 중요하게, 이것은 아마도 룰 엔진이 overkill이고 (로직이 룰들의 명확한 집합으로써, 하드코딩될 수 있다 [결정 트리가 특정 순서를 가질 수 있다.] 이것은 강한 결합, 또는 약한 결합이 태생적으로 나쁘다는 것을 말하는 것이 아니며, 룰 엔진을 고려하고 어떻게 룰들을 capture할 것인지를 명심하는 것이 포인트라는 것이다. 약하게 결합된 룰들은 시스템내에서, 관계 없는 다른 룰들을 변경할 필요 없이 룰들을 쉽게 제거하고 추가하고 변경될 수 있도록 만들어준다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.