[Workflow] 왜 이제와서 BPM인가?

Posted at 2010.08.30 09:02 // in Bender // by MOOVA 무바㏇
인원들이 정리 안 된 어떤 한 프로젝트에서 한 부서의 일을 본의아니게 몽땅 떠 넘겨받아서 처리했을 때의 일이다.
 이 업무는 해당 시스템의 청사진으로 모든 업무와 연계된 모듈이 예상되었다. 해당 정직(을)과 담당자들은 이미 이 업무를 맡기 싫어, 책임을 회피하고 요리조리 빠져나가려는 궁리만 하고 앉아 있었다. 해당 PM도 본인 회사의 시스템 담당자들에 대한 회의가 들어서인지 전적으로 프리랜서들에게만 의지를 하고 있던 상황이었다. 

인계받을 모듈의 규모도 작은 규모가 아니어서 싸인을 하는데만 여러 기업의 입심이 참 대단했었다. 보통 이런 상황에서 기업과 기업의 입장차이때문에 싸인을 마지못해 하는 경우가 많은데, 본인은 그런 상황에서 공식적으로 제대로 일을 한번 해 볼 수 있다는 기쁨 때문에 흥쾌히 그 종이에 싸인을 했다. (정말 돌이킬 수 없엇던 실수를 한 것이다.!)
- 아마 이 싸인으로 중간업체는 많은 돈을 챙겼다고 알고 있다. 본인에게는 콩고물 하나 돌아오는게 없었다.

2010:08:30 08:43:36

"전체적인 그림만 완성하면 난 만족할 뿐..."


이 때 맡아서 진행하려했던 모듈을 살펴보니, 코드와 프로세스는 전혀 정립되어 있지 못한 상황이었다. 이 모듈을 모두가 회피했었던 이유를 난 바보같이 늦게나마 깨달은것이다.
개발자들은 개발자 나름대로의 신공을 부려 각 기능을 제대로 개발했을지 모르겠지만, 큰 그림을 돌봐주는 사람이 없어 각 모듈을 조립했을 때 나왔던 큰 그림은 마치 중요한 부분들이 빠진 찢어진 지도와도 같았다. 현 시점에서 가장 중요한것은 이렇게 흩어져 있고 정리 안 된 것들을 "어떻게 보기좋게 정리를 해고 진행해야 하는가?"에 대한 고민이었다. 이 프로젝트를 실천하기 전 솔루션 엔지이너로 활동한 탓인지 프로세스 정비를 하는것이 유일한 첫째 대안이었다.
아무리 복잡한 업무라도 프로세스만 제대로 정립을 해 준다면, 나머지 구차한 작업들은 모두 한결같이 진행되리라!

해당 프로젝트에선 공식적으로 BPMS를 도입하고 있었지만 해당 업체의 컨설턴트들을 좀처럼 만나볼 수 없었다. 아마도 프로젝트 초반 시안만 작성해주고 떠났다고 본다. BPMS를 쓰지 못한다고 해서 아쉬워할껀 없었고 개인적으로 프로세스 정립하는 툴을 이용해서 5일동안 해당 업무의 프로세스를 정리하고자 했다. 시간도 너무 촉박했고 옆에서 닦달하는 PM은 항상 언제 끝나냐는 강압적인 압박만 지속한 상태다. 자신들이 직원들이 미적지근하게 처리 못 한 것들을 이제와서 정리를 해 주겠다는데 일정만 그렇게 외쳐대니 참으로 안타깝기 그지없었다.
이미 엎지러진 물이니 개인적인 시간을 내어서라도 전체적인 데이터가 흘러갈 수 있는 그림만 완성한다면 난 만족할 뿐이었다.

"개발자도 비즈니스 프로세스를 알아야한다"

그렇다면 프로세스의 정립이 첫 우선순위가 된 이유는 무엇인가?

일반적으로 프로세스라는 것을 생소하게 여기는 개발자가 많다. (TDD나 짝프로그램은 다른 범주이다. 개발자들에게 하려는 목표와 방향을 제시해주고, 실제로 그들이 해야 할 일에 대해서 정립을 했을 때 TDD나 짝 프로그래밍도 가능한 일일것이다. TDD와 BP는 범주가 달라서 따로 설명하지 않겠지만 둘 다 중요한 원리와 사상이 있다.)

프로세스란 결과를 발생시키기 위해 어떤 이벤트에 반응하는 한정된 활동들의 집합이다. 프로세스는 아주 단순한 것에서부터 복잡한 것에 이르기까지 다양하지만, 일반적으로 가치 사슬(value chain)이 가장 상위의 프로세스로 한정짓고 있다. 가치 사슬은 여러개의 비즈니스 프로세스로 구성되어 있고 비즈니스 프로세스는 또 각각의 프로세스로 분류된다. 프로세스는 서브 프로세스를 여러 레벨에 걸쳐 하위에 지니고 있을 때도 많다. 반대로 개별의 프로세스를 정립하면 상위의 프로세스로 그룹핑하고, 더 나아가서 최종적으로 가치 사슬을 나타내는 그룹으로 표현될 수 있다. 이때 주의해야할 것은, 상위 개념의 프로세스가 잘못 재정되면 가치 사슬로 묶여 있는 서브 프로세스들은 한꺼번에 무너지기 쉽상이다.

2010:08:29 19:03:52
가치 사슬

아쉽게도 주먹구구식의 프로젝트에선 위와 같이 비즈니스 프로세스의 정립을 할 시간 조차 없을 때가 많다. 만약 운이좋아 문서에 전체적인 윤곽을 그려낼 수 있으면 그나마 다행이다. 하지만, 항상 시간이 없고 일정은 촉박하다. 이런 일들은 BPMS벤더회사의 컨설턴트들이 해 주어야 하는데 그들은 개발자들이 구현할 때 즈음되면 다들 사라지고 없다. 또한 개발자들은 정리 안 된 거미줄위에 항상 반복되는 코드를 그려댈 뿐이다. 부서전체의 업무가 막장으로 가기전에 어서 빨리 프로세스를 재정립해야만 한다.!
 
"BP를 위한 좋은 도구"

이런 상황에서 도입할 수 있는 것 중에 하나는 간단한 WorkFlow시스템이나 프로세스를 그려줄 수 있는 간단한 도구를 사용하는 일이다. 적절한 BP도구를 사용하면 문서도 알아서 작성해주며, 최종적으로는 코드까지 산출해 준다. (물론 나머지는 개발자의 몫이다.) 필자가 주로 애용하는 BP도구는 Visual Paradigm이나 IBM의 RSA, 또는 Windchill의 Workflow엔진등이다. 물론 이것들은 비싼 라이센스를 지불해야 하기 때문에 정 여력이 없을 때는 OSWorkFlow같은 오픈소스를 사용할때도 있다. (벤더나 엔진은 다르더라도 BPML이라는 표기법은 모든 Workflow엔진에 비슷하게 사용된다. 필자가 항상 강조하는 원리와 기초가 중요하다고 하는 게 바로 이런 부분들 때문이다. 원리와 사상을 알면 어떤 도구나 언어를 사용하더라도 문제될게 없다.)

2010:08:29 19:17:27
OSworkflow의 프로세스 편집기

이 도구들은 복잡한 프로세스를 그림으로 표현할 수 있다는 장점이 있고, 또한 호환 가능한 규격이 이미 표준으로 정해져(BPML,BPEL)[각주:1]있다는데 매리트를 더할 수 있다. 위에 그림은 UML의 액티비티다이어그램과 매우 흡사하다는 것을 느낀다. 프로세스 모델링 표기법중에 UML의 액티비티다이어그램은 얼마전까지 BP의 범주에 포함되었다, 하지만 사실상 지금은 BPMN이 표준으로 자리매김하고 있다.

이렇게 작성된 BPML들은 프로세스 실행엔진에 의해 실행된다.
1. 정확하게 말하면 배포하기 전에 시뮬레이션을 돌려 먼저 비즈니스 프로세스의 오류 유무를 판별하는 작업이 이에 속한다(액티비티와 액터를 포함한 인증과정).
2. 프로세스 실행엔진은 프로세스 인스턴스를 실행하고 시작 이벤트에 의해 인스턴스가 흘러, 종료하면 인스턴스가 소멸된다.
3. 이러한 인스턴스들이 각각의 조건(BRM/BRMS)에 의해 제어당하고 다시 반복자와 접근자를 통해서 다른 비즈니스 프로세스를 호출할 수도 있다.

2010:08:29 19:31:44
windchill의 워크플로우 엔진

예를들어 전문적인 워크플로우엔진을 보유하고 있는 Windchill을 살펴보자. Windchill의 workflow메니저는 이러한 복잡함을 단순한 그림으로 표현하는데 성공을 한 케이스이다. 물론 도메인 특화에 맞게 결재시스템으로 활용하는게 대부분이지만, 실제로 workflow와 BPM은 그 적용범위가 상당해서 결재시스템 이외에도 다양한 비즈니스에 활용될 수 있다.

2010:08:29 19:50:24
BPMN의 일반적인 그림

"BPM을 도입하는데 가장 큰 이점"

BPM을 도입하는데 가장 큰 이점은 민첩성(agility), 가시성(visibility),유연성(flexibility),효율성(dfficiency)이다.

민첩성 : 끊없이 변화하는 고객의 요구사항에 민첩하게 대응하며, 플러그인함으로써 애자일스러워 질 수 있다.

가시성 : 업무담당자들에게 현재 진행되고 있는 인스턴스를 모니터링함으로써 데이터를 단일화하고 다양한 뷰를 시각적으로 이해시킬 수 있다.

유연성 : 복잡한 비즈니스 사항에서 예외적이고 변화적인 처리에 대한 즉각적이고 효율적인 대응력을 가질 수 있다.

효율성 : 워크플로우 자동화로 인한 비즈니스 프로세스의 처리 속도가 향상되고, 경고 및 알림 등의 이벤트에 의해 에러 감소와 관리 업무의 부담을 줄여준다.


"컨설턴트의 기본적인 소양. 비즈니스 프로세스"

개발자에서 컨설턴트로 나아가고자 하는 이들에게 비즈니스 프로세스에 대한 원리와 이해는 필수적이다. 프로젝트가 산으로 가고 있는가? 아무도 전체적인 그림을 잡아주지 않는가? 시간이 없어 단순하게 Copy&Paste만 기다리고 있는가?
구현을 수 없이 해 봤던 어떤 개발자는 이런 BP엔진을 사용한 후, 너무나 편리한 그 사용감 때문에 아예 로직을 짤 때도 별로의 Workflow엔진을 돌리는 취미도 새로 생겼다고 한다.
다양한 Workflow엔진을 습득한 후 비즈니스 프로세스의 원리를 파악해보자. 구현에 대한 사상에서 넓은 의미의 설계영역과 큰 그림을 볼 수 있는 눈이 생기리라 확신한다.

 BPM은 개발의 사고방식을 넘어서 컨설턴트나 아키텍트로 지향하고자 하는 이들에게 권유하고 싶은 종목이다.



참고서적 :
Windchill Workflow tutorial,
Workflow Management models,methods and Systems,
OsWorkflow packt
2010:08:29 20:18:57

  1. 비즈니스 프로세스를 모델링할 때 주로 BPMN이란 표기법을 사용한다. BPMN은 OMG가 주도하는 표준 비즈니스 프로세스 모델링 기법이다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

    2010.08.30 16:04 신고 [수정/삭제] [답글]

    전문적인 글이네요~ㅎ
    반 쯤만 읽었습니다.
    좋은 하루 되세요~~^^

  2. Favicon of http://ggons.tistory.com BlogIcon 꼰스

    2011.12.28 16:36 [수정/삭제] [답글]

    관리자의 승인을 기다리고 있는 댓글입니다

댓글을 남겨주세요.

[세탁소 이야기] 아키텍처 패턴 지향 2 (사례)

Posted at 2010.06.14 17:05 // in 분류없음 // by MOOVA 무바㏇

아키텍처 패턴 적용사례.
1. Windchill의 Service Helper Pattern을 보면 PLM 영역안에서 Remote Call과 관련된 일종의 변형된 서비스 패턴이란 것을 알 수 있다. 이는 Core J2EE Patterns의 ServiceLocator Pattern과 Service Activator과 흡사하고 동일한 원류를 가진다.

2. Windchill의 workflow workflow pattern을 따른다.

3. JCA 의 FormProssesor Pattern이나 Eclipse의 GEF EditPart Pattern을 보면 Architect Pattern중 Command Processor에 근본을 두고 있다. (Command Pattern과 Command Processor의 차이점은 차 후 설명할 것이다.)

4. BOM영역에서도 부품과 부품,제품군들을 유기적으로 묶을 수 있게 Architect Pattern중 일부인 Whole-Part Pattern을 응용했음을 알 수 있다.

5. Hivemind와 Eclipse PDEPlug-in pattern을 응용했다.

6. 모 Batch 솔루션은 Partitioning Pattern Parallel Processing을 일부 응용했다.

7. Struts2는 Proxy, Pipe and Filter, Interceptors , Invocation 등 다양한 패턴을 응용했다.

이러한 사례들은 열거하자면 끝이 없다.

이미 검증된 패턴들은, 우리가 그동안 쉽게 접할 수 있는 제품들 속에 중심으로서 자리 잡고 있다. 위와 같이 정리 없이 나열된 패턴들, 이
렇게 따로따로 사용된 패턴들은 모두 공통의 카테고리 범주 내에서 정리될 수 있다. 그리고 모두 연결되어 있다는 것에 다시 한번 놀라지 않을 수 없다. (그림1참조)
"특화된 도메인에서 사용된 변형된 패턴일지라도 원류와 근본(혹은 사상)은 모두 같은 사상에 연결되어 있다"


Notice.

※. 패턴모방 - 세상에 패턴 모방은 수없이 많다. 하지만, 음악계가 사용하는 저작권 침해와 같은 엄격한 제한이 걸려 있는 것은 아니다. 패턴을 모방함으로써 더 좋은 패턴을 발굴해 낼 수 있고, 역으로 그 원류를 찾을 수 있기도 하다.

※. 특정 솔루션만을 다룬 분들 또는 특화 도메인에 오랫동안 일한 엔지니어들은 대게 이러한 사실(연결되어 있다는 사실)을 간과시한다. 변형되었고 특화되었다는 이유때문에? 아니면 국지적인 경험만 고집해서? 
어떤 이유때문인지는 몰라도 특별하다고 생각하여 범용성을 외면하는 것이다. (한 번쯤 자신이 속한 도메인에서 활용한 아키텍처 패턴이 무엇이 있는지 분석해 볼 필요가 있다.) 위에서도 말했듯이 이미 모든 패턴의 범주는 범용적인 패턴 안에 녹아 있다. 각 도메인을 넘나들면서 까지도 범용의 패턴은 여전히 살아있는 것이다. 
- Super Consultant분들은 예외이니 오해 마세요~~

아키텍처 패턴 세부 적용 사례

이해를 돕고자 주변에서 쉽게 찾을 수 있는 제품 안에 아키텍처 패턴을 적용한 사례를 몇 가지 알아보고, 그 패턴을 사용함으로써 얻는 이점에 대해서 살펴보자.


1. Eclipse GEF의 Command (Command Processor)

자신의 회사가 편집기 솔루션을 개발하고 있다고 가정하자. 대게 편집기는 기본적인 기능(copy,paste,cut,undo,redo 등)이 녹아 있어야 하고 사용자 편의성에 중심을 두어야 한다. windows 시스템을 쓰는 사용자라면 Ctrl키와 Y,Z,C,X등의 단축키를 이용해서 편집할 수 있어야 한다. 어떻게 그것을 우리의 편집기안에서 가능하게 만들까? 여기에 쉬운 아이디어 하나가 있다.

그림2와 같이 스택자료구조를 두 개 만들어서 현재 진행한 Task를 Before Stack에 Push를 이용하여 계속 적재를 한다.
사용자가 Undo 버튼을 사용하면 Before Stack에 있는 Task를 Pop하여 After Stack에 Push한다. 그 후 사용자가 Redo 버튼을 사용하면 역으로 After Stack에 있는 Task를 Pop하여 Before Stack에 다시 적재한다.

그림2. 두개의 Stack 자료구조를 이용한 편집기 기본기능 구현


이러한 단순한 아이디어와 자료구조를 이용하여 편집기의 기본기능은 모두 구현할 수 있다. 

하지만 어떻게? 생각나는 데로 구현했다고 가정하자. 물론 기능은 쉽게 돌아갈 것이다. 뛰어난 아이디어를 사용했으니 사용자에게도 더 가까워질 수 있을 것 같다. 하지만, 생각나는데로 구현한 코드를 들여다 보면 재사용에 취약할뿐더러 심한 반복의 냄새를 코드에서 찾을 수 있다. 더욱이 다른 확장 모듈에 공통으로 배포해야 하는 기본기능이 정리되지 않았기 때문에 ( 이 경우 편집기의 기본기능은 프로젝트에서 공통기능과 관련이 있다.) 팀 단위 의사소통에도 분명히 마찰이 생긴다.

이러한 문제점들을 해결하기 위해서 우리는 패턴을 참조할 수 있다. 아키텍트 패턴中 일부인 Command Processor패턴을 잠깐 살펴보자.

Command Processor

context(정황) : 스케쥴링이나 작업취소 등의 사용자 함수의 실행과 관련된 서비스를 제공해야 한다.

problem(문제) : 사용자의 요청을 실행하기 위해 시스템의 핵심 기능 범위를 넘는 서비스를 구현해야 하는 경우. 예를 들어 작업취소(undo), 재작업 (redo),여러 요청을 묶은 매크로, 동적로깅, 요청 스케쥴링, 요청 일시정지 등을 들 수 있다.

solution(해법) :
 Command Processor 패턴은 Command 패턴에 기초를 두고 있다. 사용자가 다른 모드에서 요청한 Command를 Command Processor가 중점적으로 그것을 관리한다. Command Processor는 명령(command)의 실행을 스케쥴링하고 추후에 있을지 모를 작업취소에 대비해 명령을 저장하는 것이 기본적인 기능이다.

※. 이처럼 패턴·랭귀지를 참조하여 응용하는 방법은 "자기의 상황에 따라서 패턴을 선택하고, 거기에 기술되고 있는 추상적인 해결 방법을 나름대로 구체화해서 실천하는 것"이다. Command Processor에서 우리가 원하는 편집기(기본 기능)에 대한 해법을 발견할 수 있다. 

Eclipse GEF의 일부 기능인 Command에 대해서 잠깐 살펴보기로 하자. 
Eclipse의 GEF는 Graphical Editing Framework의 약어로써 말 그대로 비쥬얼하게 편집을 하는 프레임웍이다.
이 프레임웍의 내부를 들여다보면 기본적으로 제공해 주는 기능에 undo , redo, cancel, execute와 같은 기본적인 Command 개체가 숨어 있다. GEF의 모든 커맨드는 Command-Stack에 의해 관리되고 Command-Stack은 Command가 실행되었을 때 execute()메소드를 호출하고 나서 그림2와 같은 자료연산을 해 준다. 이해를 돕기 위해 GEF의 요청 처리를 보자.(그림3,그림4)

그림3, GEF의 요청처리 흐름을 신체기관에 비유한 그림

그림4. GEF의 요청 처리 흐름을 쉽게 표현한 그림

요청이 들어오면 Controller인 EditPart에서 실행할 EditPolicy을 선택한다. EditPolicy가 실행되면 모델을 변경하기 위한 Command 개체를 작성하고 역할과 필요에 따라서, 사용자가 조작한 내용을 시각적으로 표현하기 위한 피드백을 표시하는 역할을 한다. 그림 5는 Command Processor의 요청 흐름을 표현한 시퀀스 다이어 그램이다.


그림 5. Command Processor의 요청 흐름을 표현

2. PDM의 WorkFlow Pattern

PDM 솔루션들에서는 데이터를 처리하는 단위를 프로세스(Process)라고 하는데, PDM 솔루션 환경에서는 다양한 프로세스가 존재한다. 데이터(도면,보고서,부품,설계변경)의 작성, 데이터의 수정, 데이터의 검토나 도면의 검토 및 결재, 승인 거부, 데이터와 복사, 전송, 변화들의 프로세스이다. 이러한 프로세스 단위를 일련의 일의 흐름과 데이터를 처리하는 역할까지 수용한 체제가 WorkFlow란 업무이다. 말 그대로 이 영역에서는 WorkFlow Pattern에 근간을 두고 있다.


그림6. WorkFlow Pattern 시퀀스 다이어그램


WorkFlow Engine : JBoss jBPM, OSWorkflow , Bonita , Open for Business Workflow Engine , XFlow
참고 URL : http://www.workflowpatterns.com/patterns/ (매우 정리가 잘 되어 있다.)


3. PDM의 BOM(Bills of Materials) - Whole-Part

부품에 대한 version과 revision및 체크인/체크아웃기능은 BOM영역의 일부에 해당한다.

BOM관리는 BOM 구조 편집기를 사용하여 간편하게 제품구조를 편집, 비교, 전개 등을 할 수 있으며, BOM
관리 영역에서는 사양관리 대안설계 / 유효성 관리 등의 업무 목적에 맞는 다양한 BOM View (2D,3D,Cad View)를 생성할 수 있는 기능도 포함한다.

제품구조는 제품에 대한 사용자의 추상적인 개념을 시각화 한 것이다.
때에 따라서 사용자의 영역에 따라 다양한 시각을 가지게 된다.
마우스를 예로 들어보자 마우스를 마우스 휠, 그리고 레이저, 몸통에 대한 3개의 개념 개체를 가진다.(Building Block) 개념적으로 하위의 부품은 상위의 부품에 계층화된 관계를 지니고 각 부품의 제품에 변경되었을 때 version이 올라가면서 (인터페이스는 같다.) revision이 된다.
이러한 것들은 모두 사용자의 시각에 기초를 두게 된다. 사용자관점이라는 중요한 성질이 포함되어 있다.

BOMPart List, assembly, product configuration 또는 BOM strucrues를 생성관리하고, 이런 구조에 PDM 시스템에 의해 관리되는 설계정보를 연계시킨다.

Whole-Part Pattern

Whole-Part 디자인 패턴은 의미적 단위로 컴포넌트를 모으는(aggregate)데 도움을 준다. 집한 컴포넌트(aggregate component), 즉 Whole 객체는 그것을 구성하는 컴포넌트(constituent component)들, 즉 Part 객체들을 캡슐화한다.

context(정황) : 집합 객체(aggregate object)를 구현해야 한다.

problem(문제) : 거의 모든 소프트웨어 시스템에서 객체들은 다른 객체들의 조합으로 이루어져 있다.

solution(해법) : 더 작은 객체들을 캡슐화하는 컴포넌트를 도입해서, 클라이언트가 컴포넌트의 구성 부분들에 직접 액세스할 수 없도록 막는다. 이 객체들의 기능에 액세스하기 위해 집합 객체의 인터페이스를 통해야 한다. assembly-parts,container-contents,collection-members 의 관계를 통하여 관계를 정의한다.

※. 이와 같이 패턴·랭귀지를 참조하여 응용하는 방법은 "자기의 상황에 따라서 패턴을 선택하고, 거기에 기술되고 있는 추상적인 해결 방법을 나름대로 구체화해서 실천하는 것"이다.

                                                                          그림7. 자동차 CAD 도면

                                                                     그림8. Large Assembly View



4. Struts2의 Proxy, Action Invocation, Interceptor Pattern, Pipe and Filter


Struts2의 아키텍처 개념을 살펴보면 수많은 Intercepto가 액션 인보케이션과 맞물려 있다.
먼저 ActionProxy(Proxy Pattern)가 Action Invocation(Invocation Pattern)을 호출하면 Action Invocation의 invoke()메소드를 호출하고, invoke 메소드는 인터셉터를 찾고 그것의 interceptor()(Interceptor Pattern)메소드를 호출한다. 이 인터셉터의 interceptor() 메소드는 파라미터로 넘어온 액션 인보케이션의 invoke() 메소드를 다시 호출하며 체인이 형성된다.(Pipe and Filter Pattern) , 또한 Struts2는 수많은 Plug-in을 제공하여 Pluggable Pattern을 학습할 수 있는 좋은 오픈프레임웍이다.

                                                                       그림9. Struts2 Architecture

5. MVC 웹프레임웍의 Client-Dispatcher-Server 디자인 패턴

Client-Dispatcher-Server 디자인 패턴은 클라이언트와 서버 간에 디스패처 컴포넌트를 중간에 도입한다. 디스패처는 네임 서비스를 통해 위치 투명성을 제공하며 클라이언트와 서버 간의 통신을 위한 세부 구현을 숨긴다.
웹 MVC로 유명한 Spring MVC, Struts1,2등은 모두 변형된 Client-Dispatch-Server 패턴을 사용한다. 사용자의 요청을 Dispatcher 클래스에 이관하여 적절한 컨트롤러를 찾는다.


이와 같이 패턴이 녹아 있는 프레임웍을 적절하게 선택하거나 패턴을 직접 응용하면 얻게 되는 가치가 상당하다. 이미 검증된 아키텍처 패턴까지 동시에 사용할 수 있으므로, 차 후 발생하게 될 비용의 문제(유지보수,의사소통,인력이동)까지 해결할 수 있다. 또한, 패턴사용의 경험은 꾸준히 재발견해야 하는 시간적인 노력의 인내도 포함하기 때문에 실무에서 패턴의 경험이란 정말 소중한 연구 재산이 된다.



저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://www.arload.net BlogIcon PatternLoader

    2010.06.16 08:59 신고 [수정/삭제] [답글]

    와우 좋은 글이군요.

    다양한 분야의 패턴을 익히고, 실사례를 찾아보고, 회고하고
    다시 나만의 것으로 다듬고, 만들어 나가는 것이 힘이 된다고 느낀 one of them입니다.

    앞으로 갈길이 정말 먼거 같애요. 휴~~ 그래도 동지를 발견하게 되서 반갑네요!! :)

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.06.17 12:07 신고 [수정/삭제]

      사실 PatternLoader님의 글들을 보고 공감이 되어 매우 반가웠습니다. 실무에 적용하고 다듬고 하는것이 그리 쉽지 않았던것 같아요.

      실무 또는 프로젝트를 진행하면서 이 분야에 관심있어 하는 사람은 별로 없었던 것 같아요.
      그래서 저도 요즘 Eva활동이나 영수님의 활동을 보고 동지애가 많이 느껴집니당.

      랭귀지에 한계를 떠나서 사상의 만남이라고 느껴집니다.ㅎㅎ

      나중에 한국에 Plop같은 학회 하나 만드시면 적극 지원해드리겠습니다.~

  2. Favicon of http://9933.oo.ag BlogIcon 길동무

    2010.10.28 09:51 신고 [수정/삭제] [답글]

    건강㎬정보 <좋은 글 정보 감사합니다.<늘! 건강하시고 행복하시기를 기원합니다. 날마다 좋은날 되세요.

댓글을 남겨주세요.

[세탁소 이야기] 뇌주름 아키텍처 패턴 지향

Posted at 2010.06.14 13:42 // in Architecture // by MOOVA 무바㏇
패턴에 대한 인식을 재정립하고, 패턴 발굴의 확산을 기리며 쉬엄쉬엄 작성해 정리한 글입니다. 

엔지니어들이 쉽게 사용하는 IDE나 벤더 솔루션에서 가끔 
아키텍처 패턴을 응용한 제품을 접하곤 한다.
(필자는 실무에서 객체를 사용한 제품 분석을 통해 패턴감각을 익혔고, 차 후에 아키텍처 패턴을 학습한 경우다. 그 후 특화된 도메인에서 사용된 패턴들이 수없이 많다는 것을 확인했고, 차 후 범용적인 패턴까지도 서로 연결되어 있다고 믿었다. 비 정형화된 패턴과 정형화된 패턴의 만남이었다.- GOF의 디자인패턴과는 다른 이야기.) 이런 것을 발견할 때마다 신기하게 느낀 이유는 대부분 활용한 패턴들이 마치 끈처럼 연결된 듯한 느낌이 들었다. 

한마디로 "연결되어 있다" 였다. 

각 제품에서 활용한 패턴들은 대부분 똑같은데 보이는 결과물은 같은 것도 있었고, 다른 것도 있었고, 비슷한 것도 있었다. 모방은 창조의 어머니라고 하지 않았나?! 그 후 여러 가지 패턴을 조합하여 실무에 적용하려 매우 골머리를 썩힌 기억이 난다.
그 후 계속되는 연쇄작용으로 각 패턴이 연결되기 시작했고 서로 연관을 지을 수 있게 되었다. ( 결국 내 뇌는 뇌 주름만 더해간 고통의 인내과정을 겪었다.)

양보다 질을 따져서 지식적으로 제한되어 있던 패턴을 실무에 접목하고자 노력을 하는 사람들과 연구단체들이 많다. 또한, 실제로 실무에 접목하고 또 발굴해 내려는 분들 또한 많아졌다. ( 매우 반가운 소식이다 ) 그런 노력은 새로운 패턴 발굴에 도움을 줄 것이고 기존 패턴 연구에도 피드백을 줌으로써 패턴의 인식을 변화시킬 것이라 장담한다. 

패턴 대부분은 대부분 업무에 응용할 수 있고 확장할 수 있다. 또한, 정형화된 패턴 이외에 특화된 도메인에서 응용했던 비 정형화된 패턴까지도 한마디로 연결되어 있다는 사실의 발견에 매우 놀라지 않을 수 없다. 나중에 알게 된 사실이지만 이런 패턴의 연결고리를 정리한 것이 Plop에서 제안된 Pattern Map이란 지도였다. 역시 배움의 길은 멀고도 험하다.

- 알고 넘어가기
  1. 무분별한 패턴사용은 사용하지 않음만 못하다.
  2. 패턴의 범주는 이디엄 < 디자인 패턴 < 아키텍처 패턴으로 분류할 수 있다.

    위에 그림은 뇌주름이란 제목의 그림이다. 이처럼 뇌 주름에서도 쉽게 패턴을 찾을 수 있다. 하지만, 본고와는 무관한 그림이다.:)


애피소드. (세탁소 아저씨 이야기)


때문에 자주 지방에 내려갈 때, 전용으로 양복을 맡겼던 세탁소가 하나 있다.
그 세탁소 주인은 30년 동안 HH양복회사에서 일을 했었고 퇴사 후 자신만의 가게를 차렸다고 했다.
그분은 소일거리로 백화점에서 의뢰받은 수공품을 만들고 계셨는데 그 솜씨가 기가 막혔다.
백화점 브랜드이긴 하지만 어디서 설계도면을 가져왔는지
설계도면[각주:1]만 있으면 완전히 똑같은 모조품을 만들 수 있다고 했다. (물론 단순한 그림 쪼가리는 아니다. 3D 캐드 도면이었다.)

이때 그분에게서 들었던 것이
설계패턴이라는 단어였다. 설계패턴은 어딜 가도 동일하니 패턴에 맞게 하면 뛰어난 수공품이 된다는 것이었다. - 난 이것에 놀라지 않을 수 없었다.
의류업계에서도 패턴이 있었다니, 심지어는 패턴을 외워서 모조품까지 만드는 난공불락의 신념도 들어 있었다.( 어찌 됐든 모조 제품은 좋지 않다.:) 


같은 패턴 , 다른 패턴 , 비슷한 패턴.

소프트웨어는 이와 비슷하지만 조금은 대조적이다.

환경이 항상 달라서 똑같은 패턴을 쓰더라도 그 용도와 효용성은 조금씩 차이가 있게 마련이다. 
하지만, 조금씩 차이를 가진 패턴이라도 그 속을 들여다보면 비슷한 카테고리를 찾을 수 있다.  
이것을 정리한 것이 바로 Pattern Map이다.
상황과 환경이 매번 다르지만, Pattern Map을 참고 해서 원류를 찾을 수 있기도 하고, 또 그 속에 포함되어 얽혀 있는 패턴까지도 정리할 수 있다. 더불어 
패턴의 패턴 즉, 패턴의 모태도 찾을 수 있다. 자신과 자신이 속한 기업에 특화된 패턴을 발굴하여 자체 Pattern Map을 개발해 낼 수도 있을 것이다. (현재까지 정리된 Pattern Map의 Pattern들의 개수는 수 없이 많다.)

- 알고 넘어가자! 패턴 랭귀지

패턴·랭귀지는, 건축가의 Alexander가 제창한 지식 기술의 방법이다. Alexander는, 건물이나 거리의 형태에 되풀이되어 드러나는 법칙성을 '패턴'이라고 부르고, 그것을 '언어'로서 공유하는 방법을 고안했다. 그가 목표한 것은, 거리나 건물의 디자인에 관한 공통 언어를 만들고, 누구라도 디자인의 프로세스에 참가할 수 있도록 하는 것이었다.

패턴·랭귀지에서는, 다양한 경험을 패턴이라고 하는 단위에 정리한다. 패턴에는, 디자인에의 '문제'와, 그 '해결'의 발상이 한 벌이 되어서 기술되고, 거기에 이름을 써넣을 수 있다. 패턴·랭귀지를 사용하는 사람에게는, 자기의 상황에 따라서 패턴을 선택하고, 거기에 기술되고 있는 추상적인 해결 방법을, 나름대로 구체화해서 실천하는 것이 요구된다.

이러한 패턴·랭귀지의 사고방식은, 건축의 분야 이외에, 소프트웨어 개발을 넘어서, interaction·디자인이나 조직 디자인, 교육의 디자인 등에 응용되어 사용되고 있다. 패턴·랭귀지의 사고방식은, 실무 경험 지식을 공통 언어로 승화하는 방법으로서, 앞으로도 여러 가지 분야에 응용되면 좋을 것이다.




< 다빈치의 설계 패턴 中 >

보통 엔지니어들에게 확장성이 좋기로 소문이 나 있는 제품에는 고 수준의 패턴이 숨어 있으므로 쉽게 참고 해서 분석해 낼 수 있다. 패턴의 적절한 활용에 대해 어떻게 어디서 참고해야 하는지 당장 궁금하다면 널리 알려진 오픈소스를 한번 분석해 보면 된다. 또한, 정형화된 패턴에 벗어난 범주 즉, 비정형적인 패턴일지라 하더라도 결국 원류와 근본이 있기 마련이고 결국 패턴의 모태와 연결되어 있다. ( 특화된 도메인에서 지역패턴을 만들어서 국지적으로 사용했더라도 이미 원류는 범용적인 패턴범주에 속한다. )

그림1에서 볼 수 있듯이 특화된 도메인에서 개발한 패턴은 범용적인 패턴의 모태에서 파생되어 있다.



  1. PLM영역에서 설계도면이란 그렇게 간단하지가 않다. 단순히 종이 설계도면이나 UML로 만든 2D모양의 그림이 아니다. 대부분 3D툴을 이용해(캐드,마야등) 상위레벨과 하위레벨을 연결지을 수 있으며 평행선상의 구조적 부분도 연쇄 가능하다. 구조적 부분에서도 무척이나 건축분야와 닮아 있다.일반적인 종이설계문서와는 다르니 참고하자. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.06.14 17:52 신고 [수정/삭제] [답글]

    악! 어려워요!
    음.. 디자인 패턴이라는 용어는 잘 모르겠지만 return to source 라고 하면 조금 비슷하려나요?
    핵심을 뚫는 원리를 알고 있으면 좋을텐데 그걸 시원하게 알기가 어려우니 안타까워요

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.06.15 11:00 신고 [수정/삭제]

      흠..글쎄요 '원시로의 복귀'
      그것도 비슷한 감이 오지만 패턴과는 좀 다른 이야기일껍니다. 패턴은 원시의 소스를 중시함에 덧붙여 전체적인 구조를 바라보는 영역에 더 가깝거든요.

      디자인패턴은 'GOF의 디자인 패턴'이 유명합니다. 특정 언어에 국한되지 않고 볼 수 있는 소트프웨어 필독서죠.

      위에 서술된 아키텍트 패턴은 좀 더 상위의 개념입니다. 보통 개발하시는 분들이 GOF의 23가지 패턴이 전부라고 생각하는 분들이 많습니다. 하지만 패턴은 수천 수만가지죠.(비공식적인것 까지 합하면)

      패턴은 학습도 중요하지만 학습만 가지고는 실제로 감이 잘 오지 않습니다. 실무에 적용해보고 감을 찾고 발전해 나갈 때 핵심을 뚫은 자신만의 비법을 발견할 수 있을 것 같군요. 차근 차근 알아나가는 것이 중요한것 같아요

      We have to saw the forest!

  2. Favicon of http://9933.goofy.kr BlogIcon 지극정성

    2010.10.28 09:52 신고 [수정/삭제] [답글]

    건강㎴정보▒ <좋은 글 정보 감사합니다.<늘! 건강하시고 행복하시기를 기원합니다. 날마다 좋은날 되세요.

댓글을 남겨주세요.

티스토리 툴바