길은 확정이 났는데, 몸이 문제로고..

Posted at 2010.10.01 02:43 // in Major // by MOOVA 무바㏇
항암이 끝나면 수빈형이 대표로 있는 컨설팅 기업으로 가서 경험을 쌓기로 맘먹었다.
내 앞날의 전문적인 장래에 대해서 요청받은 세 갈래 길과는 전혀 다른 차원의 길을 선택한 것이다. 나이가 서른이 넘어버렸으니 개발일보다는 보다 전문적으로 일을 할 수 있는 방향으로 나아가야 한다.

1. 청훈형님이 DBA와 데이터기반의 회사를 소개해준 곳이 1순위였는데 아무래도 건강과 스트레스 대비를 생각해야 하기 때문에 눈물을 머금고 DBA의 길은 접는다.

2. 또 CCC형과 계획하고 진행하고 있는 어플인 모바일 기술지원은 나름대로 취미활동으로 하려고 했다. 어플 시장이 이미 기승을 부리어 주업으로 선택하기엔 무리가 있는 듯 보였다.

3. 그리고 삼성에서 만난 수석님이 자신의 회사에 와서 기술수석을 하라는 이야기도 있는데, 나와 삼성은 별로 궁합이 맞지 않으므로 이 부분도 아쉬움이 남지만 넘어가려 한다.(물론 다른 부서는 궁합이 맞을지도 모르겠다. 개발자를 노예화 시키는 그런곳만 아니라면..)

난 초등학교 시절부터 누군가를 가르치고 그것에서 보람을 얻는 일이 가장 행복했었는데, 아마도 그 기질이 현재의 선택을 하게 만든 것 같다. 그동안 프로젝트를 하면서 컨설팅 롤을 수행했던 것은 두 번뿐이다. 한번은 STX에서 IC로 일했던 적이 있었고(한 벤더회사의 기술 컨설팅-실제 하는 일은 소프트웨어 엔지니어였음.), 한번은 LG에서 AA의 일을 지원해주며 SE급으로 활동한 적이 있었다. 아쉬웠던 점은 일반 개발자들과 같은 별 차이 없는 단가를 받으면서 컨설팅롤이나 AA롤을 수행했다. 중간업체에서 많이도 먹은 듯^^.

수빈형님의 회사로 가게 된 결심을 한 이유가 바로 이것이다. "제대로, 역량대로, 열정대로 일하고 일한 만큼 가치 만큼 받자!!" 수빈형님의 회사에 들어가게 되더라도 난 아직 책임컨설턴트급은 아니다. 시니어 컨설턴트로 시작하게 될 텐데 그동안 학습하고 연구해온 지식을 제대로 써먹었으면 하는 바램이 크다. 물론 개발일도 아직도 내 취미에 속하긴 하지만.

그 전에 이 지옥같은 항암만 무사히 끝냈으면 하는 바램이다.

1.다른 장기에 전이되어 항암을 받는 케이스와 나와 같이 2.예방차원에서 항암을 하는 것은 분명히 차이가 있다. 보통 함암을 하는 분들은 여러 장기에 전이가 되어 항암으로 암세포의 발생을 막는 것을 목표로 삼는데, 나같이 운이 좋은(전이가 되지 않은..) 사람은 예방차원에서 항암을 하게 된다. 이미 몸속의 암세포는 없는데 말 그대로 예방차원에서 항암을 하는 것이다.
 


 

저작자 표시 비영리 변경 금지
신고

'Major' 카테고리의 다른 글

길은 확정이 났는데, 몸이 문제로고..  (0) 2010.10.01
스터디 관련해서  (2) 2010.10.01
크롬OS의 오해와 과제  (3) 2010.02.16
[PDF] Microsoft의 2010트랜드  (0) 2010.01.27
[Info] 빌게이츠가 블로그를?  (0) 2010.01.26
전환.  (0) 2010.01.25
블로그코리아에 블UP하기

댓글을 남겨주세요.

[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 [수정/삭제] [답글]

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

댓글을 남겨주세요.

어느 컨설턴트의 벽

Posted at 2010.08.04 17:58 // in Associate // by MOOVA 무바㏇
대부분의 사람은 지독하게 자기중심적이여서 오로지 자기 자신에게만 관심이 있다. 그들은 누가 어떤말을 해도 항상 자기 상황만 생각한다. 그리고 아무리 멀리 떨어진 곳에 말이라도 자신에게 영향을 주는 이야기가 조금이라도 나오면 온 신경과 관심을 집중한다.

-- 쇼펜하우어

어떤 고객사의 부탁을 받고 이어폰을 만드는 공정에 필요한 소프트웨어를 구축하러 투입을 했을 때의 일이다. 고객사의 기존 프로그램은 몇 년간 제조쪽의 컨설턴트들이 동종업계의 일을 하면서 하나씩 쌓아온 라이브러리로 구축된 일반적인 복사 붙여넣기(템플릿)위주의 고전틱한 시스템이었다. 누구하나 이 고전적인 명물을 바꿀 의사도 없었으며, 신경조차 쓰지 않았고 이곳에 투입한 컨설턴트들은 자신의 PC에 쌓고 있는 거적떼기들을 일주 단위로 고객들에게 보여줌으로써 일을 하는 명목을 세운 티를 내고 있었다. 물론 지난 시스템을 무조건 반목하는 태도는 여전히 반대 의견과 충돌될 수 있기 때문에, 조심스럽게 고객에게 웹2.0으로 제작했을 때 가져다줄 수 있는 편의성에 대해서 설명을 해주었고, 개개인에게 돌아갈 수 있는 유연함과 확장성에 대해서 설명을 했다. 고객은 새로운 영역에 대한 지대한 관심이 있었던 깨어 있던 인물이어서, 내가 제안했던 그것을 허용하고 서포트를 해 주었다.



이때 당시 지난 과거의 시스템을 구축한 컨설턴트 한 명이 들어왔다. 직급은 이사급이였고 현 프로젝트에 워크플로우 수정이라는 명목으로 15일 가량의 계약을 잡고 들어와서 일을 시작했다. 이 컨설턴트가 15일 가량 한 일은 말로 황금탑을 쌓아 올리는 수준의 꿀이 잔뜩 들어 있는 듯한 이야기들이었다. 현 시스템의 워크플로우는 고객의 의도와는 상관없이 구축되어 있었고 이 컨설턴트는 그것을 수정하러 들어온 것 뿐이었는데, 말은 어찌나 많은지 처음부터 끝까지 모래로 성을 쌓고, 자갈로 푸짐한 음식을 만들고, 동철로 황금탑을 쌓아올리는 수준의 자기중심적인 이야기들을 뿜어댔다. 고객과 나는 그 이야기를 듣자하니 달콤한 사탕과도 같았다. 그런 행복한 말들을 그가 이 프로젝트를 위해 제공하기를 바랬다. 하지만, 시간이 지나자 그의 그런 말빨은 더이상 먹혀들어가지 않았다. 그가 15일 동안 한 일은 수없이 뿜어댔던 말 그리고 자기의 말들이 마치 진리인양 무조건 옳다는 투의 태도가 전부였다. 15일이 지났고 그 컨설턴트는 철수를 했다.

그러자 고객왈.
"도대체 저 사람이 여기 들어와서 한일이 무엇이지?"
라고 말한다. 엔지니어 왈.
"별로 없는 것 같은데요. 한가지 배울점은 있었네요. 말로 황금탑을 쌓아올리는거..."
고객왈..
"우린 큰 비용을 지불했는데.. 대체 이 컨설턴트를 보낸 회사는 어떤 회사인가?"

라는 질문을 했다.


위의 실화에서 우리는 한가지 배울점이 있다. 컨설턴트란 직책이 한 사람을 권위의식의 벽을 세워놓을 수 있다는 것이다. 이 컨설턴트는 서비스 쪽의 인터넷 기술들에 대해서도 굉장한 무시를 한 상태였고, 자신이 쌓아올린 경력과 울타리안에 경험들만 말로만 빛을 발휘하는 그런 스타일이었다. (편견이란 참으로 무서운 것이다.)  권위적인 직책은 행동없는 말 뿐인 사람으로 만들기 쉽다. 이런 경우, 시스템을 욕해야 할까? 사람을 욕해야 할까? 그가 비방했던 프로그래머 출신의 컨설턴트들은 내가 아는 사람만 해도 실력이 출중한 사람들이 참 많다. 그들은 짐짓 자신을 꾸미고 꾸준히 사탕발림의 소리로 황금탑을 쌓지 않아도 낮출 땐 낮추고 피력할 땐 피력한다. 필자도 지금은 컨설턴트란 직책으로 활동하고 있지만, 말보다 행동을 우선시하는 컨설턴트가 되고자 부단히 노력하고 있다. 말만 많은 컨설턴트는 항상 고객사들의 불평의 대상이 되곤 한다.

컨설턴트들이여~~ 우리 제발 저런 소리는 듣지 말자!!
고객 : "저 사람이 도대체 이 프로젝트에 들어와서 한 일이 무엇이지?"



번외 이야기

때 당시도 해당 기업(외국계 컨설팅 업체)에서 면접제의와 좋은 요구를 해 왔지만, 난 그때 이 말뿐인 컨설턴트가 나에게 한 사탕발림 소리를 초반에 그대로 믿고 있었다. "그 회사는 있을 회사가 아니니, 당신은 다른 일을 해야한다. 그냥 들어가서 연봉을 두배로 내 달라고 해라. 그렇지 않으면 하지 않는다고 말을 하는게 좋을 것이다. 나도 지금 이 회사를 퇴사하기로 했다. 쓰잘데기 없는 회사이니..당신은 내 말에 따라라" 어린 마음 그의 말을 고지곳대로 들었던 나는 그것을 그대로 실행했는데.. 오히려 역효과를 불러일으켰다. ( 나중에 알았지만 그는 그 회사에서 짤린 상태였고, 그의 공백때문에 그 컨설팅 회사는 본인에게 입사제의를 했던 것이다. 그 회사안에서 나는 평판이 매우 좋았기 때문에 짤릴 것을 염려한 그는 매우 본인을 시기했던 것으로 알고 있다. 그것을 알았던 이 말뿐인 컨설턴트는 홧김에 자신을 짜른 회사에 대한 보복감으로 사람들에게 좋지 않은 소문을 내고 있었고, 실제로 그곳에 관심있던 나에게 그렇게 실언을 뿜어댔던 것으로 알고 있다. )
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://woorinews.tistory.com BlogIcon 황우

    2010.08.04 18:32 신고 [수정/삭제] [답글]

    잘 보고 갑니다. 수고하세요.

  2. Favicon of http://blog.daum.net/parkah99 BlogIcon 주리니

    2010.08.04 22:56 신고 [수정/삭제] [답글]

    아주 색다른 느낌의 정돈된 글이네요.
    그래서 한참을 읽고 또 읽었답니당...

  3. Favicon of http://minimonk.net BlogIcon 구차니

    2010.08.05 13:46 신고 [수정/삭제] [답글]

    아 크레신 좋아하는데 이런 슬픈 이야기가 있었군요 ㅠ.ㅠ

    이런 이유로 엔지니어들이 영업이나 이렇게 '말로 하는'직업을 무지 싫어하죠.
    무언가 권위를 내세우지면 실질적으로 맞딱트리는 필드유저로서는 변화된게 없을뿐이니까요

    그나저나 마지막 이야기는 정말 막장 스토리네요..
    다시는 마주치지 않는게 좋을꺼 같아요

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

      2010.08.08 18:44 신고 [수정/삭제]

      이런 저런 수 많은 일들중에서 저런 모습들은 정말 흔히 볼 수 있는 모습들입니다. 저런 경우 그냥 가만히 있었더라면 중간이라도 갔을텐데..하는 생각이 듭니다.
      마지막 스토리는 정말 막장 스토리라서 생각조차 하기도 싫네요.

  4. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

    2010.08.06 15:17 신고 [수정/삭제] [답글]

    주변에 말로 작업하는 사람 은근 많더라는...
    진짜 말만 들으면 혼자서 게임 다 만들은 사람도 있어요. ㅋㅋㅋ

댓글을 남겨주세요.

티스토리 툴바