티스토리 뷰

그간 페어아이작,ILOG에 이어 오늘(24일)CA의 AION에대한 PT가 끝남으로써 BRE 도입에 관한 제안이 모두 끝났다. 남은건 결정뿐이긴 하지만 칼자루를 쥐고 투자를 마음대로 할수없는 우리같은 '을'로써는
IT 투자비용이라면 의심의 눈초리부터 흘기는 사용자들을 움직이기가 꽤나 어려운일이다.

사실 사용자들이야 룰베이스를 적용해 시스템 일부를 직접 관리를 하던
 IT직원을 아바타(?)로 관리해서 쓰던 별차이는 없으니까 말이다.

하지만 IT 입장에서 보면 날로 복잡해지는 시스템과 날로 복잡해지는 요구사항들 ,날로 급해지는 사용자들의 성격(ㅠㅠ) 그리고 더불어 식탁(시스템)위에서 정정 풍성해지는 스파게티(소스들)를 보고있노라면
이걸 어찌 해결해야 할것인지 한숨부터 나온다.

이미 우리나라에서 일부제조업과 금융(주로 보험사)사에서 도입되어 쓰여지고 있는 BRE는 우리에게
항상 "오늘 저녁요청 내일부터 적용" 이라는 개발폭탄과 끊이없이 우리를 빨아들이는 "운영의 늪" 에서 우리를 구원해줄 돌파구가 될것으로 기대가 되어오던 터였다.

당췌 차이점이 뭐야?

시스템에서도 나름대로의 룰을 적용해 개발된 컴포넌트들이 있긴하지만 실제 본격적인 BRE를 쓰게되면 어떻게 될까?
정말 사용자들이 IT부서의 도움없이 맘대로 룰을 조정해서 새로운 상품을 출시한다던가 혹은 CSS전략을 원하는대로 바꿀수 있는걸까?

페어아이작과 ILOG의 제품은 우리가 일반적으로 생각하는 룰엔진의 모습을 그대로 따르고있다.
룰을 데이터베이스에 등록해서 레포지터리 형태로 관리하고 그나름대로 룰을 찾아가는 엔진을 가지고 있다.
예전엔 파라미터-드리븐 방식이라고도 했지만 룰을 데이터베이스에서 관리하므로 실시간으로 변경이 가능하고 대부분 아름답게 구성된(?)직관적인 UI를 지원하고 있다.
두업체마다 각기 자기들만의 특장점을 내세우곤 있지만 구조나 형태는 크게 다르지는 않다

반면 오늘본 CA의 형태는 좀 특이하다.프레임웍 형태라고 거창하게 설명은 하던데 룰을 작성하고 이것을 컴파일(각 언어로)해서 시스템에 클래스나 오브젝트 형태로 배포해버리는것.
즉 내부에 간단한 규칙의 랭귀지가 있고 문법을 지켜서 룰을 만들고 이를 어플리케이션처럼 컴파일 해서 배포하면 해당하는 룰을 어플리케이션에서 클래스를 호출하듯이 호출한다는 것이다.

속도야 조금 나을것 같긴한데 왠지 우리가하던 하드코딩을 단순히 룰엔진이 대신해주는것 같아서 나는 글쎄 좀 우습기도 하고 별로 애정이 생기지 않는다.
게다가 CA의 전통적인 그 딱딱하고 어설픈 UI를 보면 더더욱 정이 생기질 않게 되버리는건 뭐.....
(UI가 전부는 아니지만 아무래도 이쁘고 잘생긴 넘이 좋지않은가?)

제안된 각사의 룰엔진의 형태야 어떻든 목표는 동일하다.룰을 이용함으로써 사용자에게 더많은 권한을 주고 불필요한 운영에 들어가는 로스를 줄이자는것
더불어 하드코딩이 되어있거나 복잡한 로직이 얽히고 섥혀있는 스파게티를 일자로(?) 쭉 풀어서 관리할만하게 하자는것이 아닐까 싶다.

과연 이 룰엔진이 우리가 희망하던대로  우리에게 구세주가 될것인가?



PS.
  • 룰엔진도입으로 라인당 100여명에 달하던 관리자를 4명으로 줄이는 효과를 봤다고 하더라.그럼 이거 도입하면 우리도 막 짤리는거 아닐까?.ㅋㅋ
  • 하지만 그러기엔 할것이 너무너무 많다는것.룰엔진으로 빠른의사결정과 함께 쓸데없는데 들어가는 일도 쉽게 바뀌면 거기에 쏟을 힘을 다른데 쓸수 있다는거

'IT노동자로 살아가기' 카테고리의 다른 글

딜레마  (2) 2007.05.16
벌써 10년…  (4) 2007.05.10
PMP시험 합격수기 - 4월17일 공덕  (10) 2007.04.17
금융노조 - 꼴지를 벤치마킹하라  (4) 2007.04.09
PMP시험 D-8일  (2) 2007.04.09
댓글