[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.30 08:36 // in Associate // by MOOVA 무바㏇
추천을 받아 특정 프로젝트에 들어갔을 때의 일이다. 이곳은 대부분의 사람들이 내가 누구인지 금방 알아차렸다.
블로그 운영때문인가? 나를 알아준다는 것은 참 고마운 일이지만 전혀 나랑 연관도 없는 사람이 나에 대해서 이렇다 저렇다 하고 다니는 것은 정말 깨릭직한 부분이다. (내가 유명인도 아니고 연예인도 아닌데..) .
남에게 추천을 받았거나 주목을 끌거나, 직장내에서 특출나다고 소문이라도 나면 분명 이를 시기하거나 이간질 하는 사람들이 나타난다.


"비방하고 다니는 사람들의 공통점"


남을 쓸데없이 비방하고 다니는 부류의 공통점은
"행동이나 결과는 없고 말만 많은 사람" 이거나
"융화보다는 시기심, 이간질을 밥먹듯이 하는 사람" 또는
"자신에게 없는 능력이 남이 가지고 있을 때, 피해의식을 갖고 사물이나 환경을 바라보는 사람" 들이 이에 속한다. 사실 이들은 어떤 우월성이 먼저 눈을 가리고 있을지도 모른다. 내가 남들보다 잘났다는 그런 심리때문에 나보다 잘난 사람을 보면 두눈뜨고 못 보는 것이다.

2010:08:30 07:50:46

시기심많은 수탉 - 우화중에서

몇 가지 실례를 들어보자.

"피해의식 똘똘뭉친 어떤 무늬만 프리랜서의 이야기"

프로젝트에 추천을 받아 들어가서 진행하고 있는데 , 경력이 2년 미만 채 안된 어떤 자칭 프리랜서가 다가와서 프로젝트내 사람들을 상당히 비방하고 다녔다.

제들은 군대를 안나왔다든지, 그래서 팀웍이 잘 안된다든지, 그래서 일을 잘 못한다든지. 자신보다 잘난 신입들이 들어와서 이쁨을 받고 있는것을 자기 스스로 못 봐준다는 태도가 보였다. 왜 나한테 그런 이간질을 한 것일까?

남이 잘났건 군대를 안나왔던 난 별로 상관하지 않는다. 난 이 프로젝트에 컨설팅을 하러 와 줬고 맡은일을 잘 해주러 들어왔을뿐이다. 정말 듣기도 싫은 이간질이나 하는 행위를 내가 왜 듣고 앉아 있어야 하는가?


 이 사람은 이런 태도를 처음부터 끝까지 보여줬다. 심지어는 남이 컨설팅하는 자질이나 프로젝트의 규격을 정하는 일을 진행하고 있을때도 사사건건 옆에서 비아냥거리는 태도를 보여줬다. 차라리 이런 사람보다 말 없고 꾸준히 일하는 스타일이 오히려 1000배는 실력자일지도 모르겠다.

사실 프리랜서를 아무나 해도 된다는 그런 심리때문에 이런 사람이 판을 치는 것 같다. 예전에 프리했을때는 정말 실력을 쌓아야 했다. 프리는 프로라는 심리때문에 항상 연구해야했으며, 한 프로젝트가 끝나면 다음을 위해 세미나나, 공부를 해야했다. 남들이 못하는 문제해결능력을 높여야 한다는 게 예전 프리랜서들의 마인드이다.
하지만, 요즘은 돈이나 벌어보자고 그냥 프리랜서로 전향하는 이들이 많다. 물론 모두가 그럴리는 없겠지만 발판을 닦지 않고 돈만 바라보는 사람들이 많아지는것 같아 참으로 안타깝다. 이런 부류는 프로젝트에 들어가도 같은 프리랜서 욕만 먹이고 다니는 사람들이다. 그냥 묻어간다는 심리 또는, 자신이 갖고 있지 못한 능력을 남이 갖고 있으면 그것도 못 봐주는 사람이 이런 부류다.
이런 목적의식이 상실된 사람들에겐 프리랜서를 할 생각따윈 접으라고 말해주고 싶다.
정말 돈이 없으면 노력을 충분히 해서 실력을 키우고 프리랜서 선언을 하라고 충고해 주고싶다. 왜냐하면, 그런식의 마인드로는 항상 쓸데없는 일만 벌려놓기 때문이다. 자신의 실력이나 능력을 키울 생각은 없고, 남만 비방을 하고 다니는 사람이 될 것이 뻔하기 때문이다.


"저사람이 주목을 받는 이유는 충분히 그럴만한 이유가 있어서다"

두 번째 예를 들어보자. 어떤 커뮤니티에서 고수분이 나에게 칭찬을 해 주었다. 프로젝트내 사람이 이것을 보고 상당히 비아냥 거렸다.(위와 같은 부류다)  
직장상사가 관심을 보여주거나 잘한다는 칭찬을 하면 그 파장이 고스란히 나에게
돌아왔다. 프로젝트 메니저나 선배들이 나에게 칭찬을 하면, 같이 경쟁하던 동료나 후배들은 자연적으로 시기와 비방을 하고 다녔다. 난 정말 이렇게 쓸데없이 시기심이나 비방을 아무런 이유없이 받은적이 많다. 아니..열심히 사는것도 죄인가??

이 일이 재미있고 내 천직이라 잘하게 보이는 것뿐이지 누군가를 이기기 위해서 한다거나 경쟁을 위해서 이 일을 한다고 생각하면 정말 오해이다. 항상 프로젝트에서 짝 프로그래밍을 요청하는 내 마인드를 아는 사람이 몇 명이나 될까? 본인은 본의아니게 이런 비방을 아무런 필터링 없이 받은 적이 많다. 내가 고수가 아니라는 점도 명확하게 말했고, 항상 모자란다는 태도도 보여줬건만. 내가 나 스스로 잘한다라는 이야기를 떠들고 다닌것도 아닌데 말이다.  이런식의 쓸데없는 감정을 받고 있다면 차라리 "그래 니가 짱먹어라"라고 말하고 싶다. 난 이 일을 경쟁하기 위해 시작하지 않았다. 내 천직이고 정말 이 일이 재미있어서 시작했던 것뿐이다. ( 경쟁은 내가 운동을 할 때나 하는 일이다. )

남이 어떤 사람들에게 주목을 받거나 인지도가 높아지면 충분히 그럴만한 이유가 있어서다. 그사람은 분명히 노력하고 있었을 것이며 남들보다 더 열심히 살기위해 남들이 보지 못하는 영역까지 노력하고 있었을것이라고 본다. 저 사람이 놀고 먹을 것 처럼 보여도 사실은 그렇지 않을때가 많다. 가만히 있으면 점수라도 딸 수 있다. 쓸데없는 피해의식때문에 남이 잘나간다든지 또는 남이 가진떡이 커 보여서 비방만 하고 다닌다면 결국 좌초되는것은 자신뿐이다.

2010:08:30 07:53:56

쓸데없는 경쟁심이나 시기심, 그리고 비방은 자기 자신의 영혼만 갉아먹는다.


"인정하고 본질을 찾자"

쓸데없는 비방이나 되먹지도 않은 경쟁 심리는 그 사람의 생명만 조금씩 앗아갈 뿐이다. 결국은 자기 자신이 화를 자초해서 스스로 몰락하게 되어있다. 직장내 경쟁을 부추기는 전략이나 경쟁식 관리방법도 이제는 통하지 않는다는것을 깨달아야 한다.
본인도 그런 경쟁의 소용돌이 속에서 에이스로 꼽힌적도 있고, 경쟁에서 승리한적도 있었다. 하지만, 그건 언제까지 평생 가지고 다녀야 할 개인의 짐일 뿐이다.
물론 약간의 경쟁심리는 도움이 될 수도 있겠지만 이것은 어디까지나 단기간에 우위에 지나지 않는다.
 자신이 갖지 못한 능력을 남이 갖고 있어서 싫어한다든지, 또는 조직내에서 윗사람에게 칭찬을 받거나 인기를 끌어서 주목받고 있다던지, 그냥 그게 싫어서 뒤에서 비방하고 다닌다든지, 그러한 취미는 결코 자신에게 발전을 가져올 수 없다.

다시한번 말하지만 그런 쓸데없는 심리를 갖고 항상 피해의식에 쌓여 주변을 맴도는 이들은 결코 자신의 진정한 가치를 죽기전까지도 못 깨우친다. 경쟁보다는 융화, 비방보다는 비판을, 시기심보다는 노력을 더 키우자고 말하고 싶다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

    2010.08.31 16:55 신고 [수정/삭제] [답글]

    불만이 있으면 차라리 대놓고 얘기라도 했으면 좋겠는데...

    차암~ 사람 기분나쁘게 뒤에서만 쑥덕거리는 사람들이 있더군요.

    앞에서는 한마디도 못 하고...

    기분나쁘게...

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

      2010.08.31 17:21 신고 [수정/삭제]

      그쵸.. 한귀로 듣고 한귀로 흘려야 하는데,
      내가 모르는 사람들까지 나를 입담에 오르는게 정말 기분이 나쁘죠. 뒤에서 칭찬을 하건, 욕을 하건 앞에서 당당히 나와서 말 좀 했으면 합니다. 저런사람들.
      특히 IT인물들은 다른 직종에 비해서 머리를 쓰려고 하는 취미가 있어놔서 다른 계통보다 저런일이 좀 많다는걸 느꼈습니다. 일종의 돌려말하기, 또는 뒤에서 담화까기등. 그런걸 스킬로 살아가는 사람도 있뜨랬죠.
      요즘은 그냥 개가 짖나보다~~하고 있습니다.

  2. 두목

    2010.09.13 15:56 신고 [수정/삭제] [답글]

    지다가던 길에 잠깐 짧글 남깁니다.

    남을 뒤에서 비방하는자라.....

    어디서 짧글 읽은적이 있는데 뒤에서 남을 욕하거나 비

    방하는 사람은

    그 사람을 무서워 하는 사람이라 더군요,

    그래서 앞에서는 비방에 비자도 못한다지요...흠흠

    근데 곰곰 생각해 보면 참 불쌍하지요.

    뒷말이나 뒷욕 뒷씹 등은 ㅋㅋ

    '' 저는 이 정도로 나약한 사람입네다 ''

    라고 하는 것과 같지요. 참 씁쓸하지요...

댓글을 남겨주세요.

[주말큐티] 빌립보서에서 얻는 지혜

Posted at 2010.08.29 11:45 // in Church art // by MOOVA 무바㏇
메시지신약
카테고리 종교 > 기독교(개신교) > 성경학습 > 신약성서
지은이 유진 피터슨 (복있는사람, 2009년)
상세보기

살아있는신방황하는영혼을위한희망의카운터컬처
카테고리 종교 > 기독교(개신교) > 기독교일반 > 기독교일반
지은이 티머시 켈러 (베가북스, 2010년)
상세보기

만들어진신신은과연인간을창조했는가?
카테고리 인문 > 인문학일반 > 인문학의이해
지은이 리처드 도킨스 (김영사, 2007년)
상세보기



요즘 기독교나 천주교를 바라보는 외부의 시각은 별로 좋지 못하다.
사대강이니, 뭐니 해서 교인들이 뭉쳐서 현 정권에 대해 권력을 휘두르는것 정말 보기 흉할 정도이다. 
북한서 70일간 있었던 한상렬목사를 보자. 그가 믿었던 믿음이라는 잦대는 시대의 이데올로기나 제도적 틀도 무시해버렸던 좋은 사례중에 하나이다. 그의 지나친 맹신이 다른가치들을 무시해 버렸던 것일까?
믿음을 보기좋게 갖으려 했던 나에게도 그런 모습들은 정말 창피하기까지 한데... 처음에 내가 믿음을 갖고자 했던 것은,

주변 어르신들의 권유로 "믿음을 한번 갖어보도록" 이라는 충고를 너무 많이 들었던 탓도 있었고, 주변에 열성적으로 믿음을 갖고 선의를 행하는 분이 있어서였다. 처음엔 꽤나 결심을 한 듯 하다.

그런 결심조차도 얼마안가 그 근본 목적이 사라진 계기가 있었는데, "실망"..바로 그것이었다.

종교단쳬라...맑디 맑을것 같았던 그곳도 결국은 사람이 사는 동네였고 ,  그런 맑고 행복한 기대감은 어디로 갔는지 몇 개월 사이에 나에게 큰 실망감을 안겨 주었다. 교회안에서도 권력 다툼이 있었고, 돈과 사기꾼들이 있었다. 실제로 큰 믿음을 갖고 있었던 전도사님이나 친구 형제들이 있어서 다행이었지만, 역시 그곳도 그늘이 있었다.

이즈음에서 다시한번 살펴봐야 할 것은 사랑에 대한 것이리라.

성경에서 말하는 가식적인 사랑이 아닌 진실한 사랑. 그것은 과연 존재하는가?


1. 오늘은 빌립보서를 20분간 탐독하고자 한다.


빌립보서는 바울이 행복에 가득 차서 보낸 편지다. 그 행복은 전염성이 강하다. 몇 절만 읽어도 금세 그 기쁨이 전해지기 시작한다. 춤을 추는 듯한 단어와 기쁨의 탄성은 곧장 우리 마음속에 와 닿는다.
그러나 행복은 우리가 사전을 뒤적거려 알 수 있는 그런 단어가 아니다. 사실, 그리스도인의 삶의 특성 가운데 책을 보고 익힐 수 있는 것은 하나도 없다. 그 삶의 특성을 익히려면 제도 같은 것이 필요하다. 수년간 충실한 훈련을 통해 몸에 익힌 것을 자신의 모든 행실로 보여주는 사람에게 직접 배워야 한다. 물론 설명을 듣기도 하겠지만, 제자는 주로 스승과 날마다 친밀하게 지내면서, 기능을 배우고 타이밍과 리듬과 터치같음 미묘하지만 절대적으로 필요한 기법을 익힌다.

바울이 빌립보라는 도시의 그리스도인들에게 보낸 편지를 읽다 보면, 위에서 말한 스승을 대하는 것 같은 느낌이 든다. 바울은 우리에게 행복해질 수 있다고 말하거나, 행복해지는 법을 말해 주지 않는다.
다만 분명히 알 수 있는 것은 그가 행복하다는 사실이다.

그 기쁨은 그가 처한 상황과는 무관한것이다. 그는 감옥에서 편지를 썻고, 그의 활동은 경쟁자들의 공격을 받고 있었다. 그는 예수를 섬기며 스무 해가 넘도록 혹독한 여행을 한 끝에 지쳐 있엇고, 어느정도 위안도 필요했을 것이다.
그러나 바울이 내면으로 경험한 메시아 예수의 생명에 견줄 때, 상황을 그다지 중요하지 않았다. 왜냐하면 그 생명은 역사의 특정 시점에 한 번 나타난 것으로 그친 것이 아니라 이후에도 끊임없이 나타나서, 그분을 영접하는 사람들의 삶으로 흘러들고, 계속해서 사방으로 넘쳐흐르기 때문이다. 바울은 그의 편지를 읽는 이들이 그리스도의 생명으로 넘쳐흐르는 모습을 다음과 같이 그려본다.

무슨 일을 하든지 기꺼운 마음으로 흔쾌히 하십시오. 말 다툼하거나 따지지 마십시오!. 흠 없이 세상 속으로 들어가, 이 더럽고 타락한 사회에 맑은 공기를 불어넣으십시오. 사람들에게 선한 생활과 살아 계신 하나님을 볼 수 있게 하십시오. 환하게 빛을 비춰 주는 메시지를 어둠속에 전하십시오 (빌. 2:14~15)


무엇보다도 그리스도는, 어느 누구도 하나님을 제한하거나 독점할 수 없다는 사실을 보여주는 계시다.


적절하게 사랑하는 법을 익히십히오. 여러분의 사랑이 감정의 분출이 아니라 진실하고 지각있는 사랑이 되려면 지혜로워야 하고 자신의 감정을 살필 줄 알아야 합니다. 사랑하는 삶을 살되 신중하고도 모범적인 삶, 예수계서 자랑스러워하실 삶을 사십시오. 그것은 영혼의 열매를 풍성히 맺고, 예수 그리스도를 매력적인 분으로 만들며, 모든 이들로 하여금 하나님께 영광과 찬송을 돌려 드리도록 하는 삶입니다. ( 빌 1:9~11)


그리스도인의 행복을 설명해 주는 것은, 바로 이처럼 넘쳐 흐르는 그리스도의 생명이다. 기쁨은 충만한 생명이며, 어느 한 사람 안에 가두어 둘 수 없는 넘쳐흐르는 것이기 때문이다.

다음은 티모시 캘러의 설교의 일부분이다. 많은 깨달음을 주는 구절이다.

 
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[선택의 기로에 선 정점] 내 경력과 경험점검@

Posted at 2010.08.29 10:49 // in Associate // by MOOVA 무바㏇

워낙 요즘 개발자 뻥튀기 경력들이 난무하다보니 개인적으로 순수하게 하나하나 경력을 쌓은 나로써는 오히려 이런 뻥튀기 현실에 불이익을 당하는 듯.
정리하는 차원에서 경력을 점검해 볼까~~~^^

<병상중에 찍은 몰골사진 한장>

LG CYON | KU9100 | Normal program | Unknown | 2010:08:24 20:30:19

2010:08:29 09:49:25


12   한진***- TSP P**c
 t
2009.★~2009★  (주)아x토링 응용SW엔지니어, AA 확인중 -  
11   삼성 ***요구사항 시스템
  확장 프로젝트
2009.03.★~2009.0★ x위즈 PL 확인중 -  
10   LG 통합 *** 2008.0★~2009.0★  Lxx CNS SW 아키텍쳐 확인중 -  
9   STX** - PI 2008.01.★~2008.08.20  PTC Korea, 솔루션 컨설팅 확인중 -  
8   삼성***** (P
 CMS)
2007.04.02~2007.09.★  (주)엔위즈, JAVA프로그램개... 확인중 -  
7   LS산***래신, PSK* 2006.11.★~2007.03.14  PTC Korea IT서비스>기술지원 확인중 -  
6   삼성 SDS **** 2006.★~2006.11.08  PTC Korea IT서비스>SW구현>JAVA프로그램개... 확인중 -  
5   솔루션 개발팀 - ***소**본부,) 2005.05.★~2006.01.31
 (주)아x에스테크놀로지
패키지 SW>SW구현>솔루션SW엔지니... 확인중 -  
4   21****학 연구소 시스템 증축
 ,전자결재,빌링, 열****의개편
2003.09.★~2004.10.07  21xx경제학연구소 패키지 SW>SW구현>Web Coder(HT... 확인중 -  
3   (주)이****편 사이트 증축 2003.0★~2003.08.2★  xx지샘 패키지 SW>SW구현>Web Coder(HT... 확인중 -  
2   (주) 부지런한 ***** 2003.04.★1~2003.05.★  xx사람들 IT서비스>SW구현>UI 개발 확인중 -  
1   군부대 전산 보안 통신병 (2년
 2개월)
2000.11.★~2003.01.★  xx군수사령부 기타SW관련업무>정보시스템기획... 확인중 -  


번외 2003년~2005년 개인 프리랜서 사이트 및 솔루션 제작 및 대행 15건
(열린우리당, CNE건설, Shop Mall 4건, 한국 순위 Top100 등록, 커뮤니티외 다수 5건)

일단 간략하게 정리해볼까. 아래 간단한 정리에 빠진것도 상당히 되는지라. 모든 이력을 이 한 포스트에 모두 올릴 수는 없는 노릇이고, 애피소드도 상당히 많고 ㅎㅎ. 즐거운 기억과 괴로운 기억도 많다. 모두 올릴 수 없다는것에 아쉬움을 남기고

더보기


군대 전

하드웨어에 심취해 있어서 용산바닥이나 테크노마트에 조립 AS 수리로 일한적이 있다. 이것을 계기로 군부대에서 통신병으로 뽑혔고, 군대에서 컴퓨터증설에 관한 약간의 힘을 보탠듯하다. 소프트웨어보다는 하드웨어에 먼저 매력을 느꼈었지.

나도 초반엔 밑바닥 코더부터 시작했구나~

실제로 컴퓨터를 접한 건 고등학교 시절이지만 한국에서 제대로 경력을 인정받기 시작한 건 군부대 통신병으로 근무했을 때부터다. 저기 나열되지 않은 웹사이트, 시스템 경력은 코더 일이고 지금은 그쪽 업체에 도장이나 직인을 찍을 수 없는 노릇. 대부분 연락이 두절된 상태이고, 연락이 된다하더라도 업체가 이름을 바꿨거나 변경된 상태.
그 후 군부대에서 기획과 보안업무를 주로 담당했고, 전산실 사람들에게 전산보안과 문서작성이라는 업무를 병행했었다. 군부대 전산사람들과 cgi나 웹 프로그래밍 또는 군부대 경계근무 프로그래밍도 했었다. 그렇다고 경계근무나 훈련 작전에 미참가한건 아니고, 오래달리기 500명중에 2등까지 했었으니 체력도 어느정도 받쳐주었었지.
 이때는 정말 건강했는데..이게 뭐람..

군부대 이후 완전 코더일을 했었구나.

군부대 이후 약 1년 반 이상동안 했던 건 CGI랑 리눅스 운영, PHP. HTML, Javascript, 경량디비와 관련된 일이다. 이때는 완전 코더일이라서 내세울 게 못 되지만 어찌됐건 코더도 개발자에 속하니 이때 시기가 나에겐 참으로 값긴 시기였던 것 같다. 직접 고객과 이야기해서 기획도 잡아보고 구성도 해보고 가장 기억에 남는것은 열린우리당의 시스템 개편이였는데, 이때 노무현 대통령이 탄핵을 당해서 개인적으로 매우 시련을 겪었던 때이기도 하다. 아마 VB나 MSND레퍼런스는 저 때 많이 봐 둔듯. 번외로 웹플레이어 제작도 했었는데 그것 어디까지나 번외이므로 패스하고.. ( 번외가 좀 많아서 내 이력에 패키지로 버린 이력들이 상당하다. )

연구소에서 일했구나..

한 회사의 솔루션을 전부 맡아 설계,분석,개발,연구까지 진행했었다. 참 힘든 시절이었다고 생각한다.
회사 경영사정이 워낙 안 좋아 직원들 대부분 월급을 반납하고 일하던 상황이었다. 이 때 만난 동료와 선배들은 아직도 연락하고 지내는중. 지금은 뿔뿔히 흩어졌지만 가장 인간적인 사람들을 만난곳이기도 하다.
개인적으로 회사내 프레임웍을 제작했었고, 일반 SI가 아닌 말 그대로 연구소에 일원으로써 고생했다고 의의를 갖고 있다.
간략정리 -


회사가 망해서 프리랜서로 전향했구나..

그 후 쭈욱 프리를 뛰었군 그래. 처음엔 삼성 SDS에서 간단하게 프리일이나 해보려고 투입했지만, 워낙 이쪽에서 동료들이 추켜세워주는 바람에 이쪽 프로젝트에서 잘한다는 평가가 있었군. 시스템 워크플로우를 담당했으니 모든 개발자들이 내 업무를 통하지 않으면 안 됐었다. 운이 좋은 것인지 나쁜 것인지.. 동시에 솔루션개발도 같이 해서 이클립스 RCP는 이 때 처음 최초로 프로젝트에 도입했었다. 그 후 벤더회사 엔지니어로 여러 프로젝트에 호출당하면서 이래저래 지방을 자주 왕래했었지. 기억에 남는 것도 많았고 추한 기억도 많이 있다. 이 시기엔 개인적으로 가장 값졌다고 생각하는 Windchill도 만나 보았고, 블랙박스 프레임웍과 화이트박스 프레임웍 사이에서 남들이 겪지 않은 괴리감과 이질감을 동시에 느꼈었지? 그 후 좀 머리가 굵어진 탓에 . 최종적으로 임플리먼트 컨설턴트와 애플리케이션 아키텍트라는 롤도 맡아 수행했었구나. 협업에게 교육도 해주고 설계도 해주면서 말이다.




 

Windchill을 나와 또 한번 혼자되었었구나..

PTC 프리랜서를 접고 나와서 개인적으로 또 활동한 무대가 바로 LG CNS. 가장 건강을 헤쳤던 프로젝트였다.
이쪽 사람들은 대부분 나를 알것이니.. 저쪽에 메임프레임웍이나 업무 프로그램들은 모두 내가 만든 소스를 보고 배꼈었고, 코드베이스로써 제대로 활동했었구나. 이쪽 3사통합 시스템에 들어가면 보안,인증,메뉴,정직화면,협력업체화면,공통프레임웍,통계,배치,다수의 업무 프로그램은 대부분 내 손을 거쳤다는 뿌듯함~
실제로 고객과 마찰이 좀 있었던 반면 개인적으로 가장 기억에 남는 프로젝트였다.

'공통/응용, 비즈니스 프로세스 컨설팅, 소프트웨어 아키텍트 패턴 컨설팅 및 설계, 아키텍트의 중반 인수인계,해피콜 주도 업무 설계/개발, 센터, AA 서포트,공통,신입기술지원,배치' 프레임웍 재정립, 공통 표준안 가이드, 개발자 서포트, 통합 개발환경 구축 ,소프트웨어 엔지니어링 (SE)업무

건강이 악화되다...

저 프로젝트를 끝나니 위장이 점점 안좋아진것을 확인했고, 단기 프로젝트를 뛸때마다 응급실에 몇번 실려갔었구나.
중간에 누가 추천해주는 회사는 많았는데 개인적인 건강때문에 눈물을 머금고 프로젝트를 진행한 곳도 있었다.
이 기간에 또 한번 아키텍트 롤을 2차례 수행했고 시니어 디벨로퍼로써 또 한번 활동했었군.
그리고 지금은 수술해서 쾌차를 하고 있는 중이고..


그 외 오픈소스 연구 활동

블로그에서 나를 만난 분들은 잘 알겠지만, 블랙박스 프레임웍과 화이트박스 프레임웍사이의 중간에 껴서 상당한 괴리감을 맛봤었다는것은 아는 사람은 안다. 초반엔 블랙박스에 반추해서 여러개발자들에게 오픈환경을 꾸미자는 취지에서 프로젝트내 오픈소스를 자주 도입했었는데, 어쩌다 보니 이게 취미가 돼서 지금은 공학적인 용도로 활용하고 있다.
한 친구랑 같이 꾸준히 스터디하다가 그 친구는 지금 미국에 있고, 같이 공부하려고 했던 인물들은 죄 다 SI인물들이여서 같이 연구하고자하는 스타일이 아니였고.. 그래서 어떤 스터디에 한번 참여는 했지만.. 그쪽 분위기는 스터디가 아닌 그냥 일방적인 누군가의 강의였어서 그대로 드랍했고(내 스타일이 아니였음).. 그 후 프로젝트에서 만난 몇 명들과 교류하면서 꾸준히 번외로 오픈소스 연구를 했다.
이런 활동들때문에 프로젝트에 활용한 케이스가 점점 많아졌고, 후배와 동료들이 많이 생기기 시작했다.
오픈소스 연구 범위는 그누,누크,PHP,PHP Framework, RoR,Peral,Python,Spring,Struts,Apache,Jakarta, 구루등..

결국 나의 선택은?

건강이 최우선이라서 현재 건강만을 생각해야한다. 어제 그냥 IT를 관둘까도 생각해 봤는데 너무 깊이 판 영역들이 많아서 그대로 좌절할 수도 없는 노릇. 집에 있는 IT서적을 보면 그동안 정말 노력한것도 같고.. 하지만 최근 업체들의 횡포를 보면 그런 노력을 그냥 공짜로 받아먹고 뺏어가려고만 하는 심보가 있어서 여전히 한국에선 괴리감을 많이 느낀다.
아키텍트나 컨설팅을 하면 무엇을 하는가? 나는 한국의 일반단가에 그냥 보통 / 일반 개발자들이 받는 비용을 받아가면서 수행할 뿐인데, PL이나 아키텍트한다고 해서 보상을 더 해주는 것도 아니지 않은가? 여기에서 또 한번의 괴리감이 있다.
최근 프로젝트 3~4개 동시에 연결지어보면 어디서 내 소문을 들었는지 한 부서나 큰 모듈을 그냥 떠넘기는 업체들이 많았었고..
여기서 또 괴리감을 느끼고 있다.
현실적으로 생각해보면 해외진출과 컨설팅업체에 콜을 받아 그쪽 일을 하는것인데.. 왠지 한국에서의 활동은 이제 도무지 할 수 없을 것 같다. 해외에 연줄이 있는 사람이 몇 명 있긴 한데..한번 연락을 닿아볼까. 중간에 스카웃제의를 한 컨설팅 업체들한테는 미안하지만..일단 그쪽은 보류하는 것도 좋을 듯..

"결국은 포기는 아니고, 똥이 더러워서 피하는거지"
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

경력자들은 전문성을 찾아나선다.

Posted at 2010.08.29 10:17 // in Associate // by MOOVA 무바㏇
예로 제로님이나 그누님, CCC님은 나보다 이력과 경험이 상당히 많았지만,
결국 어떤 회사에 단 한 가지 일만을 한다고 계약하고 최근까지 일하고 있는 모습을 본다. 
왜 그들은 모든 이력을 뒤로하고 한 가지 일을 고집한다고 했을까?

"자기 이력을 어떤 인력업체나, 마인드 덜된 사장에게 무방비로 노출하면 그 이력을 가지고 그들은 돈 장난을 하기 일쑤다.
대게 이런곳에 잘 못 걸리면 하나부터 열까지 모두 뽑아먹자는 곳이 많아서 몇번 녹초가 되곤했다."

"프로젝트에 계약을 하더라도 일의 범위를 지정하고, 그 범위안에 일을 수행하는것은 어떻게 보면 지극히 당연한 이야기다.
A부터 Z까지 경험한 개발자가 새로운 F라는 종류의 프로젝트에 들어가서 A부터 Z까지 일을 해주는 일이란 결코없다. "

너무 당연한 이야기지만,
이분들도 이런 선택을 한 이유가, 업체들이 워낙 그 사람의 이력을 보고 하나부터 열까지 모두 뽑아먹자는 곳이 많아서,
단 한가지 일만 할 수 있는 그런 전문성을 선택한 게 아닐까?

실무나 실제프로젝트를 경험해보지 않은 사람은 이런 마인드에 대해서 잘 모르는것 같아서 한자 적는다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

IT를 관둘까

Posted at 2010.08.28 20:50 // in Associate // by MOOVA 무바㏇
내 친구들이나 후배들 동료들이 하는 말로..그들은 편하게 일한적도 많다고 한다. 
누가 와서 일을 시키는 것도 없었으며, 개인시간 활용하면서 회사다닌적도 많다고 한다.
프리랜서인 친구들은 나를 이해할 수 없다며 어떻게 그런 항상 ㅂㅅ 같은 프로젝트에 들어가서 사람 괴롭히는 곳만 들어갔냐며 혀를 
끌끌 찬다.

나도 그렇게 힘들게 일하고 싶지 않았다. 
근데 문제는 이 ㅆㅂㄴ들이 한국바닥에 진을 치고 있는데 어떻하냐?? 실제로 주변 프리랜서와 비교하면 프리랜서 일을 하면서 한부서의 일을 몽땅 맡아서 처리했던 이력을 갖고 있던것은 나뿐이 없었다. 이거 정말 내가 당한건 완전히 당한게 맞는 모양이다.
나만 보면 못잡아먹는 사람들처럼 일거리 심하게 떠 넘기고 주변에서 히히댁댁거리면서 일 빨리 못끝내면 손가락이나 딱딱거리면서
횡포를 주고.. 왜 정작 자신들은 일하지 않고..나 같은 선량하고 열심히 사는 개발자을 못 잡아먹어서 안달인지 모르겠다.
저넘 한명만 갈구면 프로젝트 진행된다는 심리때문일까? 내가 이동만하면 못잡아먹은 놈들처럼 주위에 진을 치고 항상 폭발적인 일만 떠 넘기는데 어떻하라고? 응?

아키텍트롤, 컨설팅롤로 들어가서 수행하면 뭘하냐? 나한테 돌아오는것은 일반 규격단가에 맨날 껍데기고, 중간에서 가로채는게 대부분인데 말이다.


응? 내가 죄를 졌다면 일 열심히 해주고 ROI확 올려준게 죄라면 죄다. 
근데 왜 이런나를 지구끝까지 쫒아다니면서 항상 남들의 3배나 되는 일들을 떠 넘기느냔 말이다.
한두번이면 우연이라고 할만한다. 
하지만..3~4개나 되는 프로젝트에서 계속, 지속적으로 그런 강압을 당해왔었다..

내가 개인적으로 소통하는 개발자들이 없었다면 난 아마 그게 세상의 전부인줄 알고 착각하면서 다녔을 것이다.

더이상 건강을 해칠수는 없다.
그나저나 300권 이상이나 되는 저 IT서적..을 정리해야한다.

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

블로거가 착각하는 것.

Posted at 2010.08.28 12:43 // in 분류없음 // by MOOVA 무바㏇
잘 생각해보면 사람들은 자신이 좋아하는 영역이나 영화이야기만큼 다른사람이 쓴 글을 읽고 싶어하지 않는다.
글을 읽는 사람의 머릿속에는 글의 주제와는 아무런 상관없는 생각들로 가득 차 있는것이 대부분이다.

오히려 그들은 글의 주제보다는 그러한 잡념에 사로잡혀 있을지도 모른다.

특히 글이 흥미로운지 여부가 검증되지 않은 경우 독자가 머릿속에 있는 잡념을 쫒아버리고 글에 집중하기 위해서는 엄청난 노력이 필요하다. 그들은 글 속에 매우 매력적인 요소가 있을 때만 글에 집중하려고 노력한다.

설령 독자가 무엇에 관한 글인지 궁금하게 여기고 흥미를 가지고 있더라도, 잡념을 쫒아버리고 필자가 전달하고자 하는 내용에 집중하려면 역시 많은 노력을 기울여야 한다. 한 두 페이지가량의 글을 읽었는데 실제로 머릿속에 한마디도 남아 있지 않은 경험은 누구에게나 있을 것이다. 이는 머릿속에 있는 잡념을 쫒아버리지 못했기 때문이다.

따라서 독자가 머릿속에 있는 잡념을 쫒아버리고 필자가 전달하고자 하는 내용에 집중할 수 있도록 유인하는 장치를 제공해야 한다.

이것도 저것도 아닌 그냥 자기 생각의 글과 자신만 알아먹을 수 있는 글에선 글을 차분히 읽고 싶지도 더 쫒고 싶지도 않게 된다.

이쯤되면 지루한 글을 전달하는 사람이 문제이고, 읽는 사람은 전혀 문제가 되지 않는다는것을 깨닫는다.

대게 자신이 파워블로거라고 착각하는 블로거가 실수하는것 中 한가지는 만인이 자신의 글을 읽고 있다라는 착각이다.
자신의 글을 독자가 전부 읽어야 하는게 당연한 논리라고 스스로 생각할지 모르겠으나 , 
대 부분은 자신의 글을 전부 읽지는 않는다는 것을 알아두어야 한다. 

정리도 되지 않은 자신의 글을 다른사람이 못 알아보면 다른 사람이 잘못이라는 논리는 
지극히 편협한 생각에서 비롯된 자기 중심적 행동이다.


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

    2010.08.29 01:09 신고 [수정/삭제] [답글]

    음.. 저야 문제해결 블로그(!)라서
    주저리 주저리 늘어놓고 정말 해결에 필요한 몇가지만
    빨간색 굵은 글꼴로 처리해버리죠.

    그럼 읽기 싫은 분은 그 부분만 ctrl-c,v 해서 해결하면 되는거고
    관심있는 분은 나머지도 읽으면 되는거고 그런거죠 ㅋ

  2. Favicon of http://bud1080.tistory.com BlogIcon 정암

    2010.08.29 18:15 신고 [수정/삭제] [답글]

    저도 여러모로 참고해야 겟습니다..

댓글을 남겨주세요.

[재활로그] 8월 28일 끄적질.

Posted at 2010.08.28 09:44 // in Associate // by MOOVA 무바㏇
6차치료中 옆 환자분이 하루종일 말을 걸어 옆에서 떠드는 바람에 이번치료는 평안하게 치료를 받지 못했다. 
언제나 그렇듯 약이 들어가면 2주간 내 컨디션은 괴로움반 평상감반이다.
2~3일가량 치료를 받고 집에 돌아오면 아무것도 먹지 못한다. 심지어는 음료수나 먹는 물 조차 입안에 자극이 강하게 당기어
차가운것도 제대로 잡지 못한다. 이러다 또 7일정도 지나면 컨디션을 되 찾게 되겠지.


6차 전 방영주 박사님께서 검사결과를 알려주었다. 혈액검사 이상없고, 사진판독 이상없다. 너무 좋아서 탈이라고 한다.
이대로만 쭈욱 가면 좋겠지만 들쑥날쑥하는 몸의 변화때문에 영 기분이 깨림직하다.

치료가 빨리 끝날줄 알았건만.. 벌써 6차가 지나가고 있다. 그동안 정말 잘 버텼다.
한가지 되새김하고 새겨 넣어야 할 것은 
"이거 보통 힘든게 아니다. 항암이란 인간이 받을 것이 못 된다."

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

'Associate' 카테고리의 다른 글

경력자들은 전문성을 찾아나선다.  (0) 2010.08.29
IT를 관둘까  (0) 2010.08.28
[재활로그] 8월 28일 끄적질.  (1) 2010.08.28
[번외 이야기] 된장녀의 단상. UPDATE  (20) 2010.08.20
핀란드의 교육정책과 공자왈  (7) 2010.08.18
촌놈이 되고 싶다.  (8) 2010.08.16
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.08.29 01:14 신고 [수정/삭제] [답글]

    음.. 럭키 세븐까지만 하면 나으실꺼 같아요!
    조금만 더 힘내시고 암따위에게 지지마세요! 화이링!!

댓글을 남겨주세요.

[Windchill 10] 분산처리 Form Processor 퀴즈

Posted at 2010.08.27 09:24 // in Bender // by MOOVA 무바㏇
2010:08:27 09:02:24

위의 그림은 Command Processor Pattern으로 작성된 Windchill JCA Form Processor의 트랜젝션 생명주기이다.
내부 트랜젝션은 녹색 사각형으로 표현되어 있고, 외부 트랜젝션은 파란 사각형으로 표현되어 있다.

Windchill에서는 분산환경 제체때문에 메소드서버의 외부 호출과 내부 호출에 대한 용도가 객체 생명주기에 각기 다른 영향을 미친다
(jotm과 같은 간단히 처리할 수 있는 라이브러리를 적용하면 분산환경에서 트랜젝션을 쉽게 분할할 수도 있지만..)

문제1. 전형적인 아키텍쳐 패턴인 CommandProcessor가 예가 될 수 있는 이 생명주기에서 디비와 객체간의 매핑을 시작하고 끝낼 때, 객체가 load되는 시점과 refresh되는 시점, clear되는 시점은 어느 부분인가?

문제2. 위의 Form Processor에서 Delegate를 적용하려면 JCA의 어떤 부분을 조작하여야 하는가?

힌트

<objecttype name="part" class="wt.part.WTPart">
   <action name="createPartWizard">
       <command class="com.ptc.core.components.forms.CreateItemFormProcessor" method="execute" windowType="popup"/>
   </action>
</objecttype>


문제 3. 문제2에서 delegate를 적용할 때 Delegate가 트랜젝션 생명주기에 미치는 영향 범위에 대해서 설명하라.

참고 : Delegate적용시 시퀀스다이어그램


원리를 알자.

JCA 프로젝트를 뛴 그들에게 퀴즈를 낸 것이니 다른 도메인분들은 Pass해도 좋습니다.

( 기술적인 접근은 다르지만 원리는 항상 모두 같다는게 포인트.)



저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

소프트웨어 관리자가 봐야할 필독서와 URL

Posted at 2010.08.21 15:13 // in Project Life // by MOOVA 무바㏇
때로는 관리자들과 실무에 대해 이런저런 이야기를 하면서 소프트웨어 방법론뿐만이 아닌, 도메인 특화된 관리방법을 발굴시키고자 고심을 할 때가 많습니다. 상생을 위해서 더 좋은 방법이 없을까? 그러기 위해서 개발자가 관리자를 바라보는 시각과 관리자가 개발자들을 바라보는 시각에 대해서 많은 개선점이 필요하다는 것을 느꼈고,
그동안 관리자가 갖고 있어야 할 역량이나 개발자의 역량등을 개선하기 위해 지속적으로 관련된 사항을 살펴보고, 조금씩 팀 내에 적용해 보고 싶었습니다. 또한 관리자가 개발자에게 편견이 있는 평가를 하는 곳을 많이 보았습니다. 객관적인 평가가 아닌 상당히 주관적인 평가겠지요, 이것을 방지하기 위해선 관리자도 관리자 역량을 자체적으로 평가할 수 있는 시스템을 도입해서 관리자에게 필요한 역량과 자질, 스킬을 되 묻는 시스템을 마련해야 할 것입니다.

소프트웨어 관리자들에게 그동안 눈여겨 봤었던 사이트와 책자 몇 가지를 소개할까 합니다.


1. 12Manage.com

2010:08:21 11:05:49

자주들어가는 사이트입니다. 12가지 관리자가 갖추어야 할 역량에 대해서 카테고리별로 잘 정리해 놓고 있습니다.
주 정보는 있지만, 세부정보는 없는 게 단점이긴 하지만 팀내에서 활동하고 있는 관리자나 팀장이라면 한번쯤 숙지해야 할 내용이 잔뜩들어 있습니다. 실무 관리자라면 카테고리별로 어떤 역량을 키울지 또는 어떤 서적이나 프로젝트를 참고해야 할지 감을 잡게 해주는 사이트입니다.

2. scrumalliance.org

2010:08:21 11:14:17

Scrum과 관련된 기사가 기재되고 있습니다.  http://www.scrumalliance.org/articles
북마크 해두면 좋을 듯

3. 그밖에 북마크하고 있는 사이트

    http://www.PMPCafe.com 
    http://www.epmforum.com
    http://www.agilealliance.org/
    http://www.agile-online.org/
    http://www.agilemodeling.com/
    http://www.scrum.org/scrumguides/
    http://xprogramming.com/index.php

LG CYON | KU9100 | Normal program | Unknown | 2010:08:21 11:41:30

4. 2007년도에 탐독했던 책입니다.
프로젝트관리의해법
카테고리 경제/경영 > 경영전략 > R&D경영/CFO
지은이 J 데이빗슨 프레임 (한언, 2007년)
상세보기


이 책이 강조하는 것은 새로움입니다. 즉, 복잡한 비즈니스 환경에서 성공적으로 업무를 수행하려면 프로젝트 관리자는 새로운 기술을 습득해야 한다는 것입니다. 과거의 프로젝트 관리자는 일정관리,예산,인적/물적자원의 배분 들의 영역에 관한 기술을 가지면 되었습니다. 따라서 프로젝트 관리자는 간트차트, PERT/CPM 네트워크, 누적비용곡석, 책임 매트릭스들을 이해하고 활용한다면, 프로젝트 수행에 필요한 충분한 지식을 가진 것으로 간주되었습니다. 그러나 그것은 단순한 수행자로서의 역할에 따른 지식이었습니다. 프로젝트관리자들이 새로운 기술들을 배우고 익히는 데 투자한다면, 이러한 능력을 발달 시킬 수 있을 것입니다. 결과지향적인 태도보다 융화지향적인 태도로 변모해야만 합니다. 프로젝트에서는 기법과 기술들을 터득하는 것만으로 성공하는 것이 아니란 것을 잘 아시죠?
이제 관리자도 선의의 관리를 배울 때라는 거~

5. 2004년에 탐독했던 책입니다. 
논리의기술(바바라민토)
카테고리 자기계발 > 자기능력계발 > 창의적문제해결
지은이 바바라 민토 (더난출판사, 2004년)
상세보기

"왜 말을 안 들어?" , "왜 내 말을 안 듣지?" 툴툴거리는 양은냄비같은 관리자를 상당히 많이 봐왔습니다. 왜 사람들이 따라오지 않는지, 또는 왜 말을 듣지 않는지. 당장의 현실만 바라보고 답답해하는 관리자들이 봐야 할 책입니다. 현실을 인정하고 무엇이 잘못되었는지 분석할 수 있는 역량이 갖추어져 있다면 실제로 문제가 무엇인지 그리고 어떻게 해답을 찾을 수 있는지 실마리를 제시하고 정리해 줄 수 있는 책이라고 생각합니다. 일정은 촉박하고 기간은 짧은데 위에서는 닦달하지, 개발자들은 말을 안듣지.. 답답하시죠?
개발자의 시각을 이해하고, 경영자의 시각을 이해하는 길은 현실을 주관적이고 감정적인 태도가 아닌, 객관적이고 논리적으로 판단할 수 있는 역량입니다.

6. 2009년에 탐독한 책입니다. 
소프트웨어공학의사실과오해
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 로버트 L. 글래스 (인사이트, 2004년)
상세보기

100% 공감된 책입니다. 이론적인 방법론이나 규칙보다 실무에서 얻었던 경험으로 공학에 대해서 설명한 책입니다. 상당히 고급스러운 지혜가 들어 있습니다. 소프트웨어 공학의 탈무드라고 해도 과언이 아닙니다. 아직도 많은 관리자가 전통적인 방법에서 사용하던 것을 개발자들을 통제하고 관리하려 합니다. 하지만 이것은 현실에 전혀 맞지 않고 딱딱한 것만을 강조하는 병폐입니다. 이러한 상황이 개선될 조짐은 전혀 보이지 않죠? 프로젝트를 발주하는 회사와 프로젝트를 수주해 시행하는 회사의 입장, 경영진과 팀의 입장,관리자의 입장에 따라 각기 생각하고 주장하는 바가 다릅니다. 프로젝트의 성공이란 스킬과 기술을 익히는 것 이외에도 공통 목표를 가지고 각 이해당사자를 더 포괄적으로 이해시키고 융화시킬 때 정말 잘했다는 칭찬을 들을 수 있지 않을까요?

7. 2006년에 탐독한 책입니다. 
사용자스토리
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 마이크 콘 (인사이트, 2006년)
상세보기

많은 프로젝트에선 일하는 방식에 문제가 있습니다. 공식만을 가지고 팀을 관리하려 합니다. 공식적인 프레임웍이 있으니 그 프레임웍을 팀 내에 도입해서 성과를 달성해보자는 팀들이 꽤 많은 것 같습니다. 하지만 이것은 상당히 잘못된 방식입니다. 공식보단 원리를 깨우쳐 원리를 통해 응용할 수 있을 때 그것이 진정한 지혜라고 할 수 있습니다. 무턱대고 스크럼이니, 애자일이니, 버그트래킹 시스템이 좋아보여 프로세스도 정비되어 있지 않은 곳에 부랴부랴 도입하는 것보다 왜 그러한 방법들이 나왔고, 왜 그런 방법들을 터득해야만 하는지, 또는 그런 방법들이 우리가 사용하면 어떤 이점을 얻을 수 있을지, 딱 맞는 방법론은 없겠지만 우리 조직에 필요한 것은 진짜 무엇인지 과감하게 버려고 시도해야 하는 자세가 필요하다고 생각합니다. 이 책도 공식보단 원리에 초점을 맞추었습니다. 사용자의 시각으로, 또는 고객의 시각으로 보여주는 것이 다가 아닌 진짜 알짜배기 소프트웨어를 건네줄 수 있는 로드맵을 제공해 주는 귀한 책입니다.

8. 2008년에 탐독한 책입니다. 
THEARTOFPROJECTMANAGEMENT마음을움직이는프로젝트관리
카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
지은이 스콧 버쿤 (한빛미디어, 2006년)
상세보기

2006년에 Jolt Award를 수상한 책입니다. 수상한 네임밸류답게 관리자들에게 꼭 필요한 지식과 지혜를 일깨워주는 값진 책입니다.
경험있는 팀 리더와 관리자, 초보 팀 리더와 관리자,프로그래머/테스터, 비즈니스 경영관리 제품 설계, 소프트웨어를 공부하는 학생 모두 참고했으면 합니다. 프로젝트 내 존재하는 모든 상황과 기술적인 문제, 정치적인 문제, 위험요소,변화관리등 프로젝트를 악용하려 하는 분들에게 진짜 마음을 움직이는 프로젝트란 무엇인지 깨닫게 해주는 책입니다.

9. 2007년에 탐독한 책입니다. 
소프트웨어프로젝트생존전략
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 스티브 맥코넬 (인사이트, 2003년)
상세보기

이 책은 소프트웨어 프로젝트와 관련이 있는 모든 사람을 위한 책입니다. 소프트웨어 프로젝트에서 성공하기 위한 첫걸음은 성공이냐 실패냐의 문제가 아닙니다. 그것보다 더 근본적인 생존의 필요성을 인식하는 것이 중요합니다. 개발자들에게 자아의식을 부여해주고, 관리자들에게 활력 있는 팀의 역동성을 부여해주고, 생존 욕구로부터 더 고급단게인 자아실현을 할 수 있게 감을 주는 책입니다. 프로젝트 전 공정에서 나타날 수 있는 이해당사자들의 충돌을 예방하고 더 나은 결과를 내고 싶으신가요? 이 책으로 감을 잡으세요:)

10. 2008년부터 프로젝트를 할 때마다 들고 다녔던 책입니다. 거의 애장일의 바이블이라고 해도 과언이 아니죠^^
불확실성과화해하는프로젝트추정과계획규모추정,우선순위,일정배치
카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
지은이 마이크 콘 (인사이트, 2008년)
상세보기

소프트웨어 관리의 지혜를 얻을 수 있는 제가 가장 강력히 추천하는 책입니다. 소프트웨어 계획부터 추정, 우선순위 결정, 스토리 분할, 일정의 배치와 이터레이션 계획, 의사소통과 커뮤니티의 역할, 애자일에 대한 인식을 고취할 수 있는 지혜가 담겨 있습니다. 항상 변화되고 미래를 예측할 수 없는 프로젝트에서 관리자들이 불확실성을 제어하고 화해할 줄 아는 스킬을 가지고 있다면 경영자나 개발자나 공통의 선의의 목표로 한 걸음 더 나아갈 수 있지 않을까요?(물론 그것이 쉬운일은 아닙니다.)
 애자일 방법론이 궁극적으로 지향하는 바가, 고객에게 최선의 가치를 전달하는 것입니다. 프로젝트의 프로세스도 정리되지 않은 상태에서 무턱대고 스크럼을 배껴와서 시행하고, 무턱대고 애자일 툴하나 사서 도입하고 하는 것보다, 진짜 고객이 원하는 가치(알짜배기 소프트웨어)를 전달해 주어야 하지 않을까요? 우리회사에 스크럼이 좋을지 워터풀이 좋을지 먼저 회사의 문화를 분석하는 자세부터 키워야 할 것입니다. (워터풀도 때로는 좋은 방법론이 될 수도 있기때문입니다.)
 

저는 소프트웨어가 굉장히 광범위한 분야이고 또한 정해진것이 없다고 생각합니다. "일정이 촉박해서", "요구사항이 바뀌니까.." 등등 이러한 이유로 소프트웨어를 못하겠다는 기사를 본 적이 있습니다. 하지만 그들은 진짜 변경되어야 할 것에 대해서는 언급하지 않더군요. 누군가 때문에 소프트웨어가 변경되었다고 툴툴대는 것 이외에 진짜로 변경되어야 할 부분들 까지 비관적인 태도를 고취한다면 별로 좋아보이지 않습니다. 이 책을 읽음으로써 관리자와 개발자 사이의 오해를 줄이고 그 갭을 더 좁혀나갈 수 있으리라 봅니다.

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

    2010.08.21 20:28 신고 [수정/삭제] [답글]

    저는 개발자의 입장에서
    프로젝트가 원활하게 돌아가고, 안정적으로 유지가 되며,
    개발자가 편한 개발환경을 위한 프로젝트 관리에 관심이 있어서 요즘 책을 찾고 있었는데
    위에있는 녀석들을 한번 후다닥 읽어봐야겠어요 ㅎ

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

      2010.08.28 08:15 신고 [수정/삭제]

      모든 사람들이 관점의 차이가 있듯, 저 마다 자신의 관점이 있는것 같군요. 꼭 개발자들에게 좋은 환경을 줄 수 있는 세상이 올 수 있었으면 좋겠습니다. 저 택들이 후다닥 읽을 종류의 것은 아니지만 ㅋㅋㅋㅋ. 저 책들이 구차니님에게 도움되리라 믿습니다.^^

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

    2010.08.26 09:01 신고 [수정/삭제] [답글]

    저희 팀 PD님께서 좀 읽어봐주셨으면 하는 책들이네요.
    첫 PD 직에 그래픽 출신이라서 그러신지 이런거에 너무 문외한...
    버전관리 프로그램 조차 쓰자고 쓰자고 해도 귀찮고/몰라서 안쓴다고 할 정도니...
    (최근에야 기획팀에 버전관리 프로그램 억지로 도입시켰다고 말하면 믿는 사람이 없다는... 게임 어떻게 나왔냐며 놀라더군요)

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

      2010.08.27 08:28 신고 [수정/삭제]

      그 답답함 이해합니다.
      그냥, 현실에 안주하는 스타일의 팀장이 위에 앉아 있을 경우 그 답답함은 이루말할 수 없을 정도지요.. 쩝..
      그런것들은 하지 않는것보다 하는게 더 이득인데 말이예요(일찍퇴근,마찰저하 등등). 전 티스님같이 깨어있는 사람덜이 잔뜩 나왔으면 좋겠다는~

  3. Favicon of http://ecogeo.tistory.com BlogIcon 에코지오

    2010.08.27 15:29 신고 [수정/삭제] [답글]

    헉, "논리의 기술"책 오래전에 사뒀다가 결국 한장도 못읽고 얼마전에 중고로 팔아버렸는뎅... 한번은 읽고 팔걸 그랬네요.. ㅠ.ㅠ
    그외 좋은책 소개 감사합니다. 마지막에 소개하신 "불확실성과..." 요책이 땡기네요. ^^;

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

      2010.08.28 15:36 신고 [수정/삭제]

      안녕하세요.~ 블로그 잘 보고 있구요.서영아빠님께서 제공해주신 서비스 아주 잘 이용하고 있습니다. ㅎ
      진정한 아키텍트의 길이란 진정 어렵고 험난한것 같아요. 쩝..

댓글을 남겨주세요.

[번외 이야기] 된장녀의 단상. UPDATE

Posted at 2010.08.20 13:45 // in Associate // by MOOVA 무바㏇
 ( 사실 그동안 이 이야기는 상당히 쪼잔하게 보일까봐 숨겨왔었던 이야기입니다.)
된장이라는 우리나라의 맛깔스런 토속적인 단어가 민망할 정도로 된장녀의 사회적 논란은 상당히 심각할 정도이다. 먼저 된장녀부터 정의를 내보자.

 "쉽게 말하자면 남자란 밖에 나가서 돈만 벌어오면 되는 존재이고 자신은 그 벌어온 돈을 가지고 자기 쓰고 싶은대로 마구 쓰면 되는 그런것으로 생각하는 사람이다.그러니까 남자를 이용해서 자신의 허영심을 채우기위해 살아가는 그런 사람을 말한다."

ps. 된장녀를 쉽게 오해할 수 있는 소지가 있다. 커피빈이나 비싼 와인을 좋아한다고 해서 된장녀는 아니란 소리이다.

떡밥의 대가 된장녀

창원에 STX프로젝트에 솔루션 엔지니어로 투입을 했을 때의 이야깁니다.
여느때와 다름없이 구현작업에 박차를 가하고 있었던 시점이었습니다.

같이 일을 해야 하는 사람들이 인도인 미국인들이라서, 통역담당이 한 명 필요했었습니다. 다들 IT 엔지니어들이라 영어보다는 시스템쪽으로 경험을 쌓다보니, 몇 명을 제외하고는 실제 비즈니스 영어를 잘하는 사람이 별로 없었던 탓입니다. 그 통역담당은 여자였습니다.
(사실 중간에 알았지만 이 통역인도 문법은 취약했다는거 하나랑 IT관련 지식은 문외한이었던 것으로 알고 있습니다. 무엇을 알고 모르고가 중요한게 아니라 앞으로의 실화속에 그녀의 태도를 한번 감상해보시길.)

어느정도 유유히 일하고 있던 시점 그 통역담당이 커피한잔 하자며 옥상에서 저를 부르더군요. 
뭐 커피 한 잔쯤 어떤가 해서 커피를 뽑아서 옥상으로 올라갔습니다. STX의 옥상은 말 그대로 직원들이 휴식할 수 있는 그런 공간이 있었습니다. 커피를 마시며 이런저런 이야기를 할 때 갑자기 그녀가 말하길 왜 다른 사람들은 자기에게 잘해 주는데 당신은 나한테 별 관심이 없냐? 라는 떡밥을 던지더군요..
사실별 관심이 없었습니다. 
어느 날 6시가 넘어서 약간의 야근을 하려고 할 때였습니다. 
먼저 퇴근한 그녀가 창원에서 저에게 전화를 걸더니 밥한 끼 하자고 하더군요.
사실 그때 당시 분위기로는 밥한끼 할 정도의 여유도 없었습니다. 

새로운 프로젝트를 따고 진행하고 있었고, 새로운 기술에 목이 말라 그것을 연구하지 않으면 도통 잠이 제대로 오지 않았습니다. 저는 한번 일에 몰두하기 시작하면 일이 끝날때까지 상당한 집중을 하는 스타일입니다. 이런 몰입기간에 다른 사람의 방해가 들어오게 되면 말 그대로 그 사람은 바로 아웃!입니다. 개인적으론 나름대로 프로페셔널한 정신이라고 생각하고 있습니다만, 소프트웨어를 질질끌면서 하는 스타일과는 많이 다른 입장을 가지고 있습니다.



점점 도가 지나친 그녀의 행위

하여튼 왈가하고 밥을 한 끼 먹으러 나갔습니다. 물론 계산은 제가 했지요. 
남자가 찌질하게 계산을 먼저 따지냐고 물을 수도 있겠습니다. 하지만, 한두번 제가 계산을 했다면 이해할만 합니다. 그 후 여러차례 밥을 먹으러 가면서도 항상 의아해 했던것은 비용은 항상 제가 내고 있었다는 것입니다. 사귀지도 않았는데 말이죠.. (뭐 나름대로 그녀에게 그런 돈의 지불은 별로 아깝지가 않았지만 지속적으로 물질적인 것을 요구하는 태도를 봐서 이게 날 호구로 보는갠가? 참 의아해 하기까지 했습니다. )

2010:07:31 13:11:48


그리고 그녀는 날이 갈수록 점점 도가 지나쳤습니다. 

그때 제 나이 30살, 그녀는 29살. 먼저 말을 놓자고 한 그녀가 말을 놓자마자 사람을 형편없이 대하더군요. 원래 성격이 그런건지 아니면 편한 사람에게만 막 말을 해대는 것인지 알 수 없었지만, 심각할 정도로 막 대하기 시작했습니다. 뭐..당연히 둘이 있을때만 말이죠. 사귀지도 않는데 그런 태도를 보였다면 모 아니면 도 아니겠습니까? 왜 나한테 항상 저렇게 신경질을 낼까?...상당히 의아했었고, 겉과 속이 다르단 말이 무색할 정도로 겉으론 화려하게 치장했지만 속으론 많이 음산한 분위기가 흘렀던 여자였습니다.

그 후 그녀의 잦은 물건 사달라기가 시작이 되었습니다. 항상 저를 보면 무엇을 사달라고 조르더군요. 생각해 보세요. 사귀지도 않는데 어떤 여자가 싱글인 남자한테 무엇을 항상 사달라고 조르면, 그걸 어떻게 받아들여야 할까요? 처음엔 그런 그녀의 행동이 귀여워서  몇 번 사줬습니다.  그 후 사태는 점점 더 심각해져갔고, 하도 졸라서 사준 종목이 너무 많아서 블로그에 따로 열거하진 않겠습니다. (심각할 정도로 종목이 많습니다.)
주위에서 선배들이 그녀는 된장녀기 때문에 너무 잘해 주지 말라는 충고가 있었습니다. 

이크! 이런 사실을 빨리 알았다면 저도 그런 관대함은 없었을 것입니다. 만약에 잘 된다고 하더라도 집안 말아먹을 것 같은 행동을 봤었고, 경제적인 알뜰함은 전혀 찾아 볼 수도 없었고 말이죠. 이 상황을 접어야 할 듯 했습니다. 

그렇게 연락을 끊을려고 하면 다시한번 연락이 오더군요. 참 신기합니다. 잊혀질만 하면 다시한번 전화와서 불러들이고, 또 잊혀질만하면 문자를 보내서 다시 기억나게 하고, 얼마나 남자들을 그런식으로 이용해 봣으면 그렇게 자연스러운 스킬을 부리는지...

2010:07:31 18:00:06
대체 그런 패턴으로 이용하려 했던 남자들이 몇명이었을까요?

된장녀 머릿속엔 무엇이 들어있을까?

사실 된장녀란게 그때 당시만 해도 생소한 단어였고, 실제로 그런 여자들이 있는지조차 몰랐던 시절이었습니다. 항상 고급커피를 마셔야하고(저도 커피는 좋아했습니다.) 와인에 명품에 항상 목매달고, 남들에게 보여주기 위해 심각할 정도로 다른 남자를 이용해서 물질적인 욕구를 채우려 했던 것이 분명했습니다. 제가 문제를 삼는 건 된장녀마인드에 대한 비판입니다. 

사실 된장녀는 자신이 무엇을 잘못한 지 모르는데 문제가 있다고 봅니다.물질적으로 항상 남에게 의존하면서 살아가는 된장녀가 그것이 잘못된 행동인지 자기 자신은 모른다는 이야기입니다.
한가지 예로, 그녀가 퇴근해서 저를 부르더군요. 프로젝트 마지막날이었습니다. 백화점에서 몇 번 저에게 호출을 했기 때문에 마지막 밥이나 먹을까 해서 또 그녀가 불렀던 백화점에 갔습니다. 식료품점에서 이것저것 사고 있는 그녀를 보게 되었습니다. 초콜렛이니 과자니 미네랄워터니 외국산 과자니 죄다 고르기에 또 내가 계산을 해야하나..하다보니 또 결국 돈이 없다는 그녀말을 들었고. 아뿔싸 또 당했구나 하는 심정으로 그냥 계산해 주었습니다. 고를거 다 고르고 돈이 없다고 하는데 별 수 있겠습니까?

 그래 마지막이니 실컷과자나 배터지게 먹고 가라하는 심리였습니다.

마지막 바이바이 작별인사를 하고.. 다음날 짐을 싸러 STX에 들어가는 순간 깜짝 놀랄 일이 벌어졌습니다. 그녀는 제가 사준 우산을 쓰고 왔더군요. ( 그 우산도 백화점에 저를 불러서 사달라고 졸랐던 명품 우산입니다. ) 우산뒤에 감춰진 것은 바로 어제 지 먹으라고 사줬던 과자를 회사에 들고 온 것입니다. 그러면서 여러 선배나 동료에게 마치 자기가 산 것처럼 유세를 피우더니 뿌리는 것입니다. 사실 그녀는 자신이 굉장한 부자라고 스스로 소문을 내고 다녔었거든요. 해외에 있을때는 스포츠카를 타고 다녔고, 집안도 상당히 부자라 돈 때문에 일을 하는 게 아니라 자신을 위해서 일을 한다는 그녀의 말이었습니다. 뭐 나름대로 일리는 있었지만, 남들에게 그렇게 사달라고 하는 취미는 그녀의 경제력이 그렇게 좋은 여건은 아니었다고 봅니다. 그럼 왜 그런 거짓말을 한것인가?? 가난하건 부자이건 그것을 따지자고 하는 것이 아닙니다. 전 그 됨됨이를 따지는 것입니다.

선배들에게 물어보니 그녀가 한턱낸다는 식으로 과자를 뿌렸다고 하더군요. 헐...완전히 속았구나! 생각했습니다. 

죄의식전혀없이 아직도 잘못을 모르는..

너무 심적으로 쪽팔렸습니다. (사실 이용당했다고 생각하니 너무 분하더군요)

사실 저도 잘못된 게 사달라고 하는 데로 족족 사줬으니 그녀를 나무라진 못하겠습니다. 하지만, 그것을 떠나서 남이 외로운 상황을 이용하려 했던 것, 고스란히 당해야만 했던 나..인정할 수 없었습니다. 물론 심적으로 타격을 입었던 것도 사실입니다.

된장녀..사회적으로 심각하게 대두되고 있는 문제입니다. 

압구정이나 강남역에만 가면 그런 된장녀들이 남자들 앞에서 허위허식에 명품으로 치장하고 있습니다. 명품하나 들고 다니지 못하면 어디에도 낄 수 없는 심리들입니다. 사실 명품이란거 1년에 한번정도만 하면 되지 않습니까? 한달 한달 명품으로 자신을 치장하고 그것도 모자라서 남의 경제력을 이용해서, 그런식의 물질을 습득하는 그녀들을 보면, 대체 이 나라가 어떻게 굴러갈지 참 걱정입니다. 현모양처에 어머니와 같은 인자함을 바라는 것은 아닙니다. 이것은 도가 지나칠 대로 지나쳐버린 사회적인 문제입니다.

그런 행동들을 방송에서 때리고 우스갯소리로 된장녀 된장녀하니 그런 된장녀 모조품들이 득실거리는 것입니다.

사실 그녀는 해외 유학을 해서, 그게 해외의 일반적인 문화라고 우겼을 것입니다. 하지만, 제가 알고 있는 친구나 유학파 동생들은 그런 사람별로 없습니다. 해외에 가서도 자신이 알바해서 자신이 공부하고 있는 사람이 태반이고, 밤 낮 가리지 않고 공부하면서 지내는 사람이 한 두 명이 아닙니다.
부모님이 열심히 유학보내줬으면 공부해서 돌아올 것이지 허위허식과 허영심만 가득 채워서 들어왔다면...글쎄요.. 한국에 들어오지 말고 그냥 외국에서 사는 게 더 낮다라는 충고를 해주고 싶더군요.



된장녀 한명때문에 회사를 관두다.

사실 STX프로젝트에서 나오게 된 것도 그 통역인의 요인이 상당히 컷습니다. 
(이때는 다른 선배들에게 개인적인 이유 또는 다른 영역에 대한 도전심 때문에 관둔다고 말했습니다. 하지만 사실은..그게 아니였죠. 무뇌녀한명 때문에.....)

실제로 둘이 있을때는 심각할 정도로 막말을 쏘아댔던 그녀.. 여자가 무조건 자기가 옳다고 주장하면 질 수밖에 없는 게 남자입니다. 야!야! 회사사람 말 텃다고 반말을 찍찍 싸대는 태도부터 시작해서, 인도사람 무시하는 면에다가 무슨 남의 친구들이나 항상 깍아내는 성격을 가지고 있었는데, 원래 성격이 그런건지 아니면 어릴때 예의 범절도 모르고 지냈는지 상당히 의아했습니다. 됨됨이 문제가 아닐까 합니다. 좋은 학교 좋은 교육을 다니고 좋은 커피에 좋은 명품을 두르고 다니면 뭐합니까. 안 그런가요?. 다짜 고짜 그런행동들을 지적해 봤자 자기 자신이 깨우치지 못하니 어쩔 수 없었지만 참으로 안타깝더군요. 그 실망감이란...

그 후.. 한달정도 지나서 다른 프로젝트를 진행하다가 그녀에게 전화를 한번 한 적이 있었습니다. 잘 지내느냐고 물었더니 잘 지낸다고 하더군요. 한 가지만 물어볼께 하면서 넌지시 그때일을 꺼내봤습니다.
다른사람에게도 사달라는 취미를 가지고 있느냐.. 혹은 물질적으로 해 줬던 그런것들을 왜 이용했느냐?(외제과자사건) 라고 물으니,
"야! 그럼 청구해 청구하면 될 거 아냐?!"
라고 하더군요.
헐....제가 돈이 아까워서 그런이야기를 한 게 아닙니다. 뭔가 찔리는 구석이 있는게 확실합니다.
역시나..찔리는게 있는지 청구하라고 하는 거 보면 확실히 이번통화로 자신의 잘못은 어느정도 알고 있구나..라고 생각하고 있습니다. 그것만 해도 저에겐 큰 수확입니다. 

된장이 되더라도 당당한 된장녀가 되자.

부디 이 사회에 이런 썩어빠진 된장녀들이 없어지길 바라며 글을 접겠습니다.
전 저때 이후로 된장녀만 보면 치를 떱니다. 그리고 다른 여성분들에겐 이런 글이 비판의 대상이 될지도 모르겠습니다. 하지만 된장녀가 되더라도 당당한 된장녀가 되길 바라겠습니다. 남자한테 기대고 바라면서 주체성을 잃는 것 보다는 자기 능력에 맞게 자신을 당당하게 가꾸는 된장녀가 차라리 나을지도 모릅니다. 정말 이해할 수 없는것은 내 주변에 여자친구들은 인생을 정말 값어치 있게 살아가는 사람들입니다. 그녀들과 너무 비교가 되었습니다. 사람알기를 소중히 알고 하나를 쓰더라도 아껴쓰는 , 선물을 주고받더라도 가치를 아는 사람들이 내 주변에 있어서 다행입니다.  부디 저런 된장들이 그런 선의를 배웠으면 하는 바램입니다.


PS: 마지막으로 해주고 싶은 말이있다. 난 청구따윈 하지 않는다. 하지만, 아직도 그렇게 살고 있다는 소식을 접하면 참 쓴 웃음이 나온다. 어떤 카페모임에 나갔던 형님이 니 이야길 하더라. 우연일지 모르겠으나, 거기서 닐 만났데, 또 그런식으로 남자들 이용하려고 카페니 모니 다니는 거 난 다 안다. 부디 정신 차리고 깨끗하게 살길바란다. 불쌍한 남자들 등처먹지 말고.....
저작자 표시 비영리 변경 금지
신고

'Associate' 카테고리의 다른 글

IT를 관둘까  (0) 2010.08.28
[재활로그] 8월 28일 끄적질.  (1) 2010.08.28
[번외 이야기] 된장녀의 단상. UPDATE  (20) 2010.08.20
핀란드의 교육정책과 공자왈  (7) 2010.08.18
촌놈이 되고 싶다.  (8) 2010.08.16
[펌]한국의 IT개발자가 사는 법 @!  (2) 2010.08.16
블로그코리아에 블UP하기
  1. Favicon of http://affirmativ.tistory.com/ BlogIcon 개나리.

    2010.07.31 18:19 신고 [수정/삭제] [답글]

    이런 여자들 정말.... 아무리 뭐 이래서 사줬어요 저래서 사줬어요~해도...
    "그래도 내가 남잔데.."하는 구시대적 발상은 잠시 버리시고
    못했던 말들 지금처럼 다 주절거려놓으면 그 된장도 지럴은 하겠지만 다시 들러붙진 않죠 ㅋㅋㅋㅋ
    물론 뒷구녕에서 남자가 쪼잔하네 치졸하네 소리는 들릴겁니다..
    뭐 그래도 내 주머니서 돈 나가는 소리보다야...!!

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

      2010.08.01 04:39 신고 [수정/삭제]

      실제로 지구상에 된장녀가 있는지 저도 처음 알았습니다. 그냥 떠도는 헛소문인줄 알았는데..
      이미 알고 있었다면 미리 대처를 했었겠죠. 아마 저 여자는 수십번 남자한테 했던 행동을 저한테 했을테고.. 전 처음 당했었으니.. 그때는 게임이 안됐었겠죠. 많이 공감합니다.
      화끈하게 된장녀들을 재교육시켰으면 하는 바램입니다. 사실 쪼잔하다라고 역으로 말하는 것도 된장녀의 스킬중 하나라고 생각됩니다.

      이제 알았으니 앞으론 저런일은 절대로 없다는거. ~:)

  2. Favicon of http://lael.be BlogIcon 라엘

    2010.07.31 19:37 신고 [수정/삭제] [답글]

    이런... 사연이 있으셨군요..

    현실이 이러하니
    정신 똑바로 차리고 살아야 한답니다.

  3. Favicon of http://lawcomp.tistory.com BlogIcon 눠한왕궤

    2010.08.01 14:51 신고 [수정/삭제] [답글]

    @.@ 아. 정말 저런 분이 있기 있군요. 전 아직 한번도 보지를 못해서..@.@ ;;
    흠. 마음고생이 심하셨을 것 같습니다. (_ _)

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

      2010.08.01 23:12 신고 [수정/삭제]

      글쎄요 한쪽의 방향으로만 생각한게 아닌지 조금은 조심스러운 부분이 있습니다. 하지만 제가 겪었던것은 엄연히 당했다는거죠. 어떤 이유를 대더라도 당한건 맞습니다.
      이를 어찌해야할지..

  4. Favicon of http://love-114.tistory.com BlogIcon 좋은인연(^^*)

    2010.08.01 15:57 신고 [수정/삭제] [답글]

    한마디로 형편없는 여자군요.(^^*)
    이런 여자들한테 우리 고유의 정말 몸에 좋은 된장을
    갖다 부치는 것 조차 아까울 지경입니다.
    이 남자 저남자 등 쳐 먹고 다니다가 언젠가는 된통
    당하는 날이 꼭 돌아 올것입니다.
    그것을 한마디로 "자업자득"이라고 하죠.ㅎㅎㅎㅎ
    정말 현명하고 자아가 분명한 여자들은 남자들 앞에서
    약한척 비굴하게 굴지 않고 항상 당당하답니다.
    머리에 똥만 차서 속이 텅빈 껍데기만 가꿀 줄 아는
    그야말로 무늬만 여자인게죠.ㅎㅎㅎ
    같은 여자로써 너무 한심해서 열이 받네요.
    이런 부류의 여자들은 가까이 하지 않는 것이 상책입니다.
    액땜하셨다 생각 하세요.
    그 여자분 분명 뿌린대로 거둘 것입니다.(^^*)

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

      2010.08.01 22:14 신고 [수정/삭제]

      복수심에서 포스팅한건 아니랍니다. 전 다만 된장녀들이 정말 중요한 걸 깨달았으면 하는 마음입니다. 그 따위꺼 치장하지 않고 안 꾸미려해도, 내면이 아름다운 사람은 숨기려해도 숨겨지지 않더라구요. 정말 심각한 문제는 진짜 된장녀는 자신이 잘못한걸 모른다는 겁니다. ㅎㅎ 이야기하신 것처럼 저는 그냥 액땜했다고 생각하렵니다.^^

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

    2010.08.03 13:51 신고 [수정/삭제] [답글]

    아무튼 좀 아니다 싶으면 매몰차게 거절하는 법을 배워야 하는데 후우.. 그게 가장 힘든거 같아요.
    그나저나 고수였군요 ㅋㅋ 적당하게 밀고 당기기 그리고 어장관리와 타이밍이 말이죠 ^^;

    그리고 회사생활을 하면서 느끼는건
    "회사는 회사일뿐 가족이 될수 없다"라는 겁니다. 적정선에서 거리를 유지하는게 나중을 위해서도 좋은거 같아요. 어짜피 남이고 이윤을 위해 모인 사람들이라 사생활 까지 말하다가는 나중에 뒷통수 맞는 경우도 종종 있는거 같더라구요.

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

      2010.08.20 18:59 신고 [수정/삭제]

      그러게여 한두번 했던 솜씨가 아니였다라는 말 밖에...
      저런 애들은 남자가 외로움을 탈때 그 냄새를 직감적으로 빨리 알아채더군요. 저런경우 남자는 어쩔 수 없어요. 넘어가는 수밖에. 정말 웃긴건 저 된장은 내 신상이나 핸드폰문자를 그렇게도 열어보려고 애를 썻습니다. 정작 나는 가만히 있는데, 그렇게 까 보길 좋아했으니.. 참...

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

    2010.08.20 16:39 신고 [수정/삭제] [답글]

    쭈욱~ 읽다가 주먹이 불끈 =ㅅ=m
    헐... 흔히 말하는 어장관리 인가요?? 남자를 무슨 지갑처럼 여기는 여자들...

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

      2010.08.21 15:06 신고 [수정/삭제]

      어장관리라고 하는게 맞을 듯. 어장관리하는 여자나 남자나 자신은 어장관리였는지 아닌지는 그 당시엔 잘 모르는 사람들이 많다는거죠. 생각해보면 저도 몇번은 있었던거 같다는거.ㅋ

  7. bora

    2010.08.24 19:00 신고 [수정/삭제] [답글]

    저건 거의 꽃뱀수준 인데요. 회사에서 저런짓을 뻔히 저질러도 아마 그 된장은 꽤 당당했을것 같네요. 파렴치하게 행동해도 당당한척하는게 댄장녀의 스킬이죠. 나중에 저거 문제삼아서 토를 달면 아주 목에 핏줄을 세우면서 당당하게 나오더군요.
    신경쓰지마세요. 쓰래기니까.. 좋은 인연 곧 있을 것입니다.

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

      2010.08.25 00:03 신고 [수정/삭제]

      저건 연애 쎈스문제가 아니라. 사람이 사람에게 작정하고 저런식으로 나온다는게 문제 아닐까요? 어린애도 아니고 성인인 이상 저런식의 행동을 한게 정말 제정신인가 생각해 봅니다. 사람이 사람에게 얼굴에 탈을 쓰고 저넘을 속이겠다~! 작정하면 달려들면 안 넘어갈 사람 어디있을까요.

  8. Villa

    2010.08.31 16:24 신고 [수정/삭제] [답글]

    그 된장녀도 문제지만 딱 선을 긋지 못하는 글쓴이도 문제가 있어보이네요...
    아무리 연락와도 안나가면 그만 아닌가요??

    답답한 글 잘 봤습니다.

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

      2010.08.31 17:18 신고 [수정/삭제]

      음.. 저때 당시 8개월간 혼자 출장갔었었죠.
      그리고 그 기간동안 혼자 자취하면서 보냈고, 그때 내가 딱 자르지 못한건 아마도 혼자 보내는 나날들을 누구로부터 채워줄 수 있는 뭔가가 필요했나 보네요. 물론 초반에는 관심이 없었는데, 계속 그런식으로 접근을 하니까 나중에 측은감이 좀 많이 들더라구요. 그걸 저애는 이용한거구요..쩝.. 지금 제가 생각해 봐도 내 자신이 답답해지는건 맞습니다. 다시는 저런일 없겠죠. ^^ (누구한테 물어봐도 정말 특이한 여자었다는건 분명하니까.~)
      앞으로 익명말고 본인 블로그나 출처라도 알려주세요.
      원래 익명댓글은 지우거나 답글을 스킵합니다.^^

  9. 가을하늘

    2010.09.01 14:12 신고 [수정/삭제] [답글]

    잘 봤습니다.
    저도 비슷한 경험. 거의 정신병자 수준의 된장녀를 만나서, 한 6개월 고생한 적이 있어서,
    님의 기분 나쁜 감정이 어떤 건지 알 것 같네요.
    생각만 하면 속이 뒤집히는, ...

    뒤에서 모든 사람들이 자신 욕하는 건 모른다는, ...
    결혼해서 잘 살리가 없겠죠. 평생 그렇게 살았는데, 조건 좋고, 마음씨 착한 남편과 결혼했다고 해도, 행복할리 없습니다.
    어짜피 평생 불행하게 살 여자라고 생각하십시오.

    그리고, 적선하듯 불쌍한 인생에 시간, 돈 조금 기부했다 생각하십시오.

    저는 제 평생에 그 여자와 결혼 안 하고, 헤어진 것을 태어나 제일 잘한 일이라고 생각합니다. ㅠㅠ

  10. gasoo

    2010.09.13 05:42 신고 [수정/삭제] [답글]

    그냥 골빈당 중 한명 아님?ㅋㅋㅋ
    골빈당 걍 무시하셈 이런 글에 쓰는 훈민정음이 아깝습니다 ㅋㅋㅋ

  11. 드르륵

    2010.09.16 00:52 신고 [수정/삭제] [답글]

    허허.. 진짜로 당한분의 이야기를 듣고보니... 진짜로 된장녀란 있군요...
    전 그냥 기생충의 한종류의 이름이 된장녀 인줄 알았는데 사람이였군요..
    빠져나오신거 정말 축하 드립니다!

  12. 코주부

    2010.09.22 10:09 신고 [수정/삭제] [답글]

    진짜 상종못할 된장년이네요. 나도 된장녀한테 몇번 당한적이 있어서 지들 명품가방이나 악세사리 구입하는데는 돈을 안 아끼면서, 커피는 꼭 스타벅스가서 꼭 고상한 것 만 찾으면서 계산은 남자한테 전가시키는

    나도 결혼까지 생각한 여자가 있었는데 진짜 된장년이었어요. 결혼하고 애낳으면 좀 나아질까라는 기대를 가졌던 것도 사실이었고, 하지만 그 된장년 등쌀을 못버티겠더군요. 남자를 지 종부리듯 하면서 머리에는 든 것도 없으면서 있는척하는..

    물론 안그런 여자분들도 많습니다.

    여튼 님글을 읽으니 나역시 화가나네요. 나도 당했으니^^

댓글을 남겨주세요.

어설픈 관리와 갑이 되고 싶은 마음.

Posted at 2010.08.20 11:14 // in Project Life // by MOOVA 무바㏇
2010:08:21 06:28:14


사이버XX텍X이라는 피시방이름의 어설픈 솔루션 회사에 투입되었을 때의 일이다.

이곳은 프리랜서나 외부 협력업체에 대한 관리를 처음 해 보는지라 관리적인 방법과 개발자를 다루는 스킬이 다른 대기업에 비해서 매우 부족했다. 관리자가 해야할 역할중에서 꼭 해야 할만한 일은 하지 않고, 이른바 "나도 드디어 갑이 되었다"라고 신이난 탓인지, 외부 프리랜서들과 협력업체들에게 별안간 찾아온 왕의 기쁨을 사방에 뿌리고 있었다.

또 이 관리자들은 어찌나 부패한지 프리랜서들에게 선물을 요구하는 간접적인 행위도 일삼았다.


개발자들이 어떻게 작업을 하는지 감시가 매우 강했던 곳이여서, 개발자 피시까지도 매번 감시를 당하고 있었다. (이 모니터링의 대한 확실한 증거가 있으므로 다른 토는 달지 말도록 하자 )
무늬만 관리자였던 그들은 2~3개월에 끝낼 수 있는 Task를 2주안에 해결하라는 강압적인 요구를 하고 있었으며, 심지어는 Task를 끝낸 직후마다, 실시간으로 모니터링을 해 개발자가 어떻게 작업을 끝냈는지, 또는 어떤 경과로 마무리를 하고 있는지 모니터링을 통해서 모든 것을 몰래 훔치고 있었다. 


"알 수 없는 조직문화, 부패한 조직문화"

2010:08:20 08:54:29

중간에 빨간색 개발자들은 프리랜서 또는 협력업체 직원들이었다.

이 회사는 외부의 엔지니어들과 함께 일하는 방법을 익힌지 1년도 채 안된다고 했다. 프로젝트에 대한 경험이 매우 적어서 대부분의 피시방 개발자들은 그동안 자신이 겪었던 개발자의 증오를 외부의 개발자들에게 마치 한풀이라도 하는 듯, 일거리를 떠넘기고 있었다. 까만색부분의 개발자들은 빨간색부분의 개발자들을 심리적으로 압박하고 있었고,빨간색 개발자들이 Task를 받아 일을 진행하고 마무리할 때마다 사방에서 "손가락을 딱딱 거리는 신경전"을 벌이고 있었다. 매우 보기 흉했던 모습이었다.

하루는 이들의 일일 보고서를 살펴보았다.
빨간색 개발자(외부인력)나 검정색개발자(정직원)들은 각기 맡은 Task가 있었음에도 불구하고 항상 업데이트를 하는 것은 외부 개발자들 뿐이었다.  (아마 간만에 검정개발자가 '을'행세를 하려하다보니 90%가 개발자에서 PM이 되고자 했던 것일까?)
피시방 개발자들의 일일보고서는 바로 어제것을 복사해서 오늘 일일보고서로 붙여넣기한 흔적이 다분했고, 윗선에 보여주기 위해 스토리 카드라는 포스트잇을 벽면에 붙이어 실제로 애자일스럽게 프로젝트를 진행하는 것처럼 위장하기도 했다.  외부개발자들의 일일보고서는 항상 업데이트가 되어 있었던 반면, 검정개발자들은 1달 전이나 2달전이에 항상 똑같은 Task만 채워져있었다.윗선에 보여주기 위한 그런 일일보고서였다. 


"갑이 되고 싶었던 마음"

자신들의 회사가 어떻게 저떻게 갑이되어 프로젝트를 진행했다고 치자!, 결국, 민심을 잃으면 프로젝트는 산으로가기 마련이란것을 왜 깨닫지 못할까?. 매우 불법적이고, 노동법에도 위반되는 사항을 스스럽없이 한 문화..
외부개발자들에게 감시와 모니터링을 통해서 자신의 코딩스킬이나 작업방법을 몰래 훔치면서 스스럼없이 하면서도 아무런 죄의식을 느끼지 않고 있었다.

이 검정 개발자들이 하는 일이라곤 외부개발자들이 신나게 개발을 하는 와중에도 옆에서 히히덕덕거리면서 말만 정말 많았고, 지금 프로젝트를 하고 있는 것인지 아니면 외부개발자들을 사방에서 쪼면서 자신들이 해야 하는 일은 하지 않아도 된다는 심리인지, 정말 하류급의 관리방법과 하류급의 팀웍을 보여줬던 케이스였다.
( 이 프로젝트는 지금 내 이력에도 완전히 없앴다. 너무 창피한 프로젝트였기 때문이다. )
뽑아먹을것은 다 뽑아먹는 전형적인 부패한 소프트웨어 회사라는 점은 확실했다. 

"그래도 컨설팅을 해 주다".

대게 이런 파국 직전의 문화가 있는 소프트웨어기업은 제 아무리 컨설팅을 해 주려해도 바뀌지 않는다는 진리가 있다.
AA나 TA는 큰 숲보다는 여전히 코드만을 볼 줄 아는 사람들로 채워져 있었고, 소프트웨어 목적을 상실한 눈에 보여주기식의 Task들만 3배로 늘어나고 있었다. 공학적인 방법과 경험을 이야기하려해도 이해하는 사람이 없었으며, 항상 말만 많았던 그들의 소프트웨어를 유심히 관찰해 보면 기본적인 CRUD중에 C조차도 제대로 구현하지 못한 사람이 허다했다. 대학원을 나왔다고 하는 어떤 개발자는 POJO에 대해 이야기 하려 했으나 우린 그런 단어 몰라요. 우린 그런 단어 안써요..라고 정색을 했다. (범용과 도메인특화조차 이해하려 하지도, 이해할 수도 없는 벽에 둘러쌓인 대학원생이었다.) 프로젝트 패턴, 방법론을 이야기해도 전혀 먹혀들지 않았다. 갑인 한진해운, 을인 사이X로지X. 갑은 을에게 무엇을 믿고 소프트웨어를 맏겼는지 의아해 할 정도였다. 그러면서 모든 소프트웨어 영역을 프리랜서에게만 의지하니 문제는 심각해도 정말 심각했다.TA가 만든 문서를 보고 실망했던 것은 프로젝트와 관련된 공통 로직이나 API,또한 애플리케이션 아키텍트가 당연히 해야할 기본적인 소양조차 꾸며놓고 있지 않았다. 이들이 얼마나 내실보다는 외실을 따졌는지 이해할만 하겠는가?
결국 난, 이곳에서 확장된 애플리케이션 아키텍쳐를 건설해 주었고, 그에 맞는 문서까지 제작해 줬으며 신입 몇명에게 컨설팅을 해 준 상태였다. 하지만 이 조차도 이해할 수 없었던 2년차 PM은 아직도 물과 불을 구별할 수 없었으리라 본다.




"잊지말자. 프로젝트란 결국 사람을 위한 것이다".

갑이 되고 싶었던 마음은 이해한다. 관리자는 관리적인 방법을 좀 배우고, 개발자들은 상생이란 무엇인지 다시한번 깨달아봤으면 하는 바람이다. 아마 이들은 아직까지 한진해운에 보여주기 위한 스토리카드로 벽을 도배질 하고 있을 것이며, 애자일한다고 외치고 앉아 있을것이다. 이클립스 기술을 쓰고 인젝션을 쓰고, 또는 버그/이슈 트래킹 시스템을 도입했다고 해서 그게 정말 잘 하고 있는 행동들이었을까?

결국, 프로젝트란 사람을 위한것이어야 하고 개발자 한 명마다 자신의 위치를 소중히 느낄 수 있게끔 자아의식을 부여해 주어야 한다.

90%의 개발자가 갑자기 찾아온 을의 기쁨때문에 놀고 먹고 흥청 망청, 나머지 프리랜서나 외부 인력들은 하루하루를 그렇게 열심히 일을 하고 있었던 곳이었으므로, 외부개발자들을 우대해주는 문화도 자리잡혀야 한다. 사방에서 손가락이나 딱딱거리는 행위를 일삼고, 사방의 검정 개발자들이 몇 명 안되는 프리랜서를 닥달하면서, 옆에서 배나 두드리는 행위, 또는 1달에 해야 할 일을 2주만에 끝내라고 하는 강압적인 스타일은 결코 프로젝트를 성공으로 이끌 수 없다. 하나를 보면 열을 안다고, 기에 차지도 않았던 이곳의 관리자는 처음보는 프리랜서들에게도 반말을 찍찍 싸대는 무식한 행동을 일삼았다.

갑이 되고 싶었던 마음은 충분히 이해한다. 하지만, 제발 본질을 보자.


2010:08:20 09:35:10
설령 농담이라도 이따위 사진을 보고 웃지 말자.
요즘 한창뜨는 이슈중에 개발자들의 면역력저하, 건강 약화, 그리고 인권유린에 대해서 기사가 줄줄이 기재되고 있다.
좀 상황 파악좀 하고 살자.


PS1 : 결국 그 피시방 개발자들도 개발자이다. 갑자기 찾앙온 을의 위치때문에 이들 대부분은 개발자에서 PM으로 전향한 듯 보였다. 편히 앉아서 놀고 먹고 일은 프리랜서가 다 해준다. 라는 식이었을까? 갑이 프로젝트를 성실히 하라고 내려줫던 돈을, 을의 인력들은 놀고먹으면서 돈을 갉아 먹고 있었고, 정작 해야할 소프트웨어 보다는 자신의 명줄만 유지하기를 원했다.거짓문서나 포스트잇으로 벽에 떡칠을 하는 이른바 윗선에 보여주기만을 일삼으면 결국 위에서도 욕먹고 외부 개발자들에게도 욕을 먹을 뿐이다. 자신들이 해야 할 일과 외부가 해야 할 일을 정확하게 진단해서 외부개발자나 내부개발자들이 서로 상생할 수 있도록 일의 분량을 공평하게 나누어 주어야 한다.

PS2 : 아직 저곳은 외부 프리랜서나 소수의 협렵업체만을 쪼는 행위를 일삼고 있다고 있다고 한다. 정작 자신들은 배나 두드리고 옆에서 히히덕덕거리면서 아직도 정신을 차리고 있지 못하고 한다. 거의 막장의 말세다. 난 내 후배들이 저런곳에서 똥만 처들은 소프트웨어를 배울까 걱정이다. 그냥 소프트웨어한다고 하지마라. 한국의 아이티를 좀먹고 있는 정말 창피한  프로젝트중에 하나였다.

PS3: 해외에서의 전문성이란? 얼마전 우리나라에서 시행된 비정규직관련법과 달리 호주에선 5년~10년동안 계속 기간을 연장하며 비정규직으로 살아가는 사람들도 많다. 또한, 한국과 가장 다른 점이라하면, 비정규직의 연봉이라 하겠다. 호주에서는 비정규직이 정규직보다 20%~50%정도 더 많은 연봉을 받는다. 이는 정규직만이 가질수 있는 1년중 4주 휴가와 병가 및 각종 혜택을 연봉에 포함시켜주는 것이라 생각하면 된다. 많은 젊은이들이 많은 연봉과 쉽게 옮겨다닐수 있다는 이유로 정규직보다는 비정규직을 선호하는 경우도 쉽게 찾아볼수 있다. 그만큼 더 전문적인 영역을 더 원한다는 이야기다. 한 예로, 호주에 어떤 회사에서는 비용절감을 위해 비정규직 7명에게 정규직 PO를 주었지만, 정규직으로 전환한 사람은 단 한명뿐이었으며 다른 6명은 모두 거부했다.
이것이 본질과 전문성을 더 원하는 해외 IT전문인들의 풍도이다. 이만하면 우리나라 풍토와 많이 다르다는 이야기다.

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

    2010.08.21 20:31 신고 [수정/삭제] [답글]

    쩝.... (무슨 긴 댓글이 필요하려나요 ^^;)

댓글을 남겨주세요.

애플리케이션 아키텍트 - 그의 한계

Posted at 2010.08.19 15:12 // in Principle // by MOOVA 무바㏇
한 프로젝트에서 조직의 포멧과 비즈니스 프로세스를 개정했을 때의 일이다.(Solution Engineer)
해당 프로젝트에서 AA가 작업한 결과물과 문서, 그리고 활동한 이력에 대해서 한번 살펴보았다. 그 문서는 말 그대로 공통된 템플릿 위주의 스타일로 구조를 설계해 놓았다. 보통 설익은 AA가 잘하는 것 중에 하나는 교육기관에서 정리해준 정석 스타일의 시스템 구조를 특수한 프로젝트에서도 그대로 사용하는 행위이다. 범용적인 교육을 이제 막 받은 아키텍트가 그것을 그대로 따라하는 것은 좋은데, 너무 범용적인 교육에만 의존하여 그것이 전부인 것처럼 생각하는 이들이 많아서 본 글을 시작하겠다. 


교육기관의 범용적인 지식을 넘어서.


보통 AA가 하는 롤중에 하나는 시스템 특징에 적합한 설계와 구현의 지침인 아키텍쳐를 작성하고, 이것을 개발팀 전원이 파악할 수 있도록 하는 것이다. AA가 하는 프레임웍 설계와 관련해서 예외관리, 메시지관리, 트랜젠션 관리, 로깅전략, 레거시 시스템과의 연계등은 한때 교육기관에서 한창 신나게 교육을 하고 있었고 아직도 많은 프레임웍 설계자들이 이 규칙을 따라서 프로젝트를 수행하고 있다. 이렇게 교육기관에서 행한 범용적인 지식은 모든 시스템에서 공통되게 사용할 수 있다는 이점이 있고, 규격에 따라 정의해 놓은 스타일로 그 템플릿에 맞게 프로젝트를 운용할 수 있다. 하지만, 이것은 어디까지나 범용적인 일이다. AA는 위와 같이 공통된 애플리케이션 전략을 세우는 것에 덧붙여 프로젝트 특유의 포멧과 가치 사슬을 포함하면서 공통된 구조(Common Spot)[각주:1]를 확장한 핫 스팟(Hot Spot)[각주:2]을 식별할 줄 알아야 한다.


애플리케이션 프레임워크의 영역.


애플리케이션은 크게 애플리케이션 레이어와 프레임워크 레이어로 구분된다.
프레임워크 레이어는 다시 애플리케이션 프레임워크 레이어와 시스템 프레임워크 레이어로 구분된다. 
시스템 프레임워크 레이어는 .net과 java같은 파운데이션 영역의 프레임워크 이고, 애플리케이션 프레임워크는 도메인 프레임워크와 범용 프레임워크 레이어로 다시 분할된다. (그림 1)

2010:08:19 14:19:46
그림 1. 범용 프레임워크와 도메인 프레임워크

바로 여기에서 교육기관에서 가르치는 것은 범용의 영역이란 것을 확인할 수 있다. (교육기관의 이론적 교육은 상당히 범용적인 것이어서 우리는 다시한번 실무에서 활용하고자 하는 응용력을 키워야 한다. 응용력은 교육기관에서 가르쳐주는 것이 아니다.)

범용 프레임워크는 비즈니스 도메인 지식을 포함하지 않는다. 따라서 범용 프레임워크는 비즈니스 도메인에 관계없이 대부분의 애플리케이션에서 공통으로 발견될 수 있는 컴포넌트와 서비스로 구성된다. 범용 프레임워크의 예로는 Struts,Spring Framework, Spring.NET,Seams,WebWork등이 이에 속하고, 동시에 범용적인 오픈소스들로  활용하고 있는 영역이다. 하지만 그것은 어디까지나 범용 프레임워크 레이어에 국한돼서이다.

도메인 프레임워크는 특정한 비즈니스 도메인을 대상으로 하는 프레임워크 컴포넌트로 구성되며, 특정한 비즈니스 도메인의 모든 애플리케이션에 공통된 비즈니스 지식을 구현한다. 프레임워크의 개발은 대상 애플리케이션에서 공통성과 가변성을 분석하는 것에서부터 시작한다. 공통성이 나타나는 위치를 공통 스팟(common spot)이라고 하고 가변적인 위치를 핫스팟(Hot spot)이라고 한다. 핫 스팟은 애플리케이션마다 가변적이어서 프레임워크를 커스터마이징 할 수 있는 위치이다. 이것이 바로 도메인 프레임워크 레이어를 확장할 수 있는 지점이다. 


애플리케이션 아키텍트는 프레임웍만 잡는 사람이 아닌.


그림2는 범용프레임워크가 도메인(특화된) 프레임워크로 점점 발전하는 개발 과정을 나타낸 그림이다.
2010:08:19 13:37:35
그림2, 도메인 프레임워크 레이어로의 발전

설명하자면, 범용 프레임워크로 구축된 시스템1에서 복사해서 붙여 넣기한 시스템2로 진화된다. 시스템2에서 나타난 문제점들을 개선하고 점차 도메인성격에 맞는 프레임워크로 진화된다. 시스템3과 시스템4는 초반에 범용적인 프레임워크에서 시작한 문제점을 제거하고 조직특화된(도메인특화된) 도메인 프레임워크로 점차 진화된다.

따라서 실력 있는 AA가 되고자 하려면 교육기관에서 지정한 행위이상으로 자신에 조직에 맞는 지식을 기반으로 가변성과 공통성을 식별하는 응용력이 아주 중요하다. (실제로 필자와 같은 솔루션 컨설턴트는 AA와 함께 더불어서 이러한 도메인 영역의 특수한 틀을 지속적으로 발전시켜주는 역할을 하기도 했다.)

2010:08:19 14:31:17
그림3. 아키텍트는 범용적인것을 넘어서 도메인(특화된) 영역을 볼 수 있는 자질이 필요하다.

AA는 범용적인 지식과 도메인 지식을 잘 융화시켜야.


조직A,조직B,조직C에서 사용된 프레임워크에서 공통된 레이어를 추출해서 범용적인 패턴으로 만드는 것은 매우 쉬운 일이다.
하지만 공통된 패턴을 넘어서 조직에 맞는 포멧과 가치사슬에 따른 프로세스, 또한 도메인 특화된 프레임워크를 지속적으로 키우는 노력은 오랜 기간이 필요하며 숙성된 경험이 바탕이 되어야 한다.

필자는 초보강사나 설익은 2년 미만된 아키텍트들이 단 한번의 교육을 받고 ( - 로깅전략,트랜젝션전략, 메시지전력등 공통된 전략들에 대해서 왈가 왈부하면서 ) 대형 프로젝트를 수행하는 것을 보고 상당히 의아해하곤 한다. AA가 하는 영역은 그게 전부가 아닌데 그것이 전부인 것처럼 포장하는 행위를 보고 매우 실망한 적도 있었다. 물론 모든 아키텍트들이 도메인에 특화된 영역에 대한 중요성을 모르는 것은 아니지만, 롤만 차지하고 앉아 있는 설익은 AA를 보면 좀 더 노력하라는 말을 전하고 싶다.

우리가 범용적인 교육을 받고 프로젝트를 진행하거나 컨설팅 역할을 단기간에 할 수는 있겠지만 범용적인 교육은 언제까지나 범용적일 수밖에 없다. 우리가 하고자 하는 것은 결국 소프트웨어 공학이며 소프트웨어 공학은 경험과 지속적인 피드백을 통해 발전시켜야만 하는 영역이다. 그리고 그들은 범용적인 것과 함께 또는 그것을 넘어서 수년간 개선된 도메인 프레임워크를 구축할 때 진정한 애플리케이션 아키텍트라고 할 수 있지 않을까 생각해 본다.

참고

1. 공통 라이브러리와 프레임워크는 다른 개념이다. 공통 라이브러리란 애플리케이션에서 공통적으로 사용할 수 있는 함수들의 집합이다. 그러나 프레임워크으 경우에 제어 흐름의 주도권은 프레임워크에 있다. 다시 말해, 프레임워크에서 애플리케이션 코드로 제어 흐름이 이동된다. 이것을 제어의 역흐름(inversion of control)이라고 한다.

2. 시스템 컨설턴트, 솔루션 엔지니어들은 범용적인 교육으로부터 흘러나온 지식을 전달해 주는 사람이 아니다. 수년간 숙성된 연구를 바탕으로 범용 프레임워크 이상의 도메인에 특화된 지식과 경험을 물려주는 행위를 하는 사람이다.

3. 프레임워크를 구지 분류해보고자 한다면, 스프링 프레임워크는 범용적인 프레임워크에 가깝고,(SOA What & How에서), Windchill은 도메인 프레임워크 영역이다. 또한 LafJ나 가우스,AnyFramework,WiseGrid등은 도메인프레임워크에 가깝다. 그리고 Struts나 Strtus2와 같은 경우 범용 프레임워크에서 도메인 프레임워크로 개선시켜줄 공통 패턴들을 많이 준비해 놓고있다. 만약 웹 영역에서 프로젝트 기간이 짧고 단기간에 도메인 프레임워크로 발전하고자 한다면 필자는 오픈소스인 Struts2를 선택할 것이다. 하지만 장기간에 걸쳐 도메인 프레임워크를 발전시키고자 한다면 필자는 여전히 Windchill이나 스프링프레임워크를 선택할 것이다.
 여기서 중요한 것은 이와 같은 기술의 선택은 매우 중요하지만 더욱 더 중요한 것은 지식과 경험을 지속적으로 발전시켜 조직에 맞는 특화된 도메인 프레임워크로 발전시키는 노력이다.



참고 서적 :
SOAWHAT&HOW:AROADTOSOA
카테고리 컴퓨터/IT > 웹사이트 > 웹서비스
지은이 전병선 (와우북스, 2008년)
상세보기
SOA(서비스지향아키텍처)
카테고리 컴퓨터/IT > 웹사이트 > 웹서비스
지은이 토마스 얼 (에이콘출판, 2006년)
상세보기

소프트웨어공학(제8판)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 LAN SOMMERVILLE (홍릉과학출판사, 2008년)
상세보기

시스템분석과요구공학
카테고리 컴퓨터/IT > 컴퓨터공학 > 시스템분석/프로그래밍
지은이 류성열 (한티미디어, 2009년)
상세보기

프로젝트관리의해법
카테고리 경제/경영 > 경영전략 > R&D경영/CFO
지은이 J 데이빗슨 프레임 (한언, 2007년)
상세보기

THEARTOFPROJECTMANAGEMENT마음을움직이는프로젝트관리
카테고리 컴퓨터/IT > OA/사무자동화 > 오피스 > 프로젝트관리
지은이 스콧 버쿤 (한빛미디어, 2006년)
상세보기


  1. 공통성(commonality)에서부터 나온 지점 [본문으로]
  2. 가변성(variability)으로부터 나온 지점 혹은 인터페이스 [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

핀란드의 교육정책과 공자왈

Posted at 2010.08.18 10:00 // in Associate // by MOOVA 무바㏇
구차니님때문에 연상된 http://todayhumor.co.kr/board/member_view.php?table=bestofbest&no=35070&page=8&keyfield=&keyword=&mn=67640&tn=10&nk= 을 보고 한마디~
마지막 문구가 인상 깊다.


"어떻게 평가하는가"에 치중한 한국의 교육과 차별을 두는 핀란드의 교육.
"학생에게 무엇을 교육시킬것인가?" 에 대한 촛점을 맞춘다고 한다. 결국 본질에 대한것을 더 강화시켰던 교육이라 생각한다,

몇 일전 한 후배가 나에게 이런 말을 했다.
"전 대기업 IT개발부서에 있지만, 기회가 된다면 인사과로 이동해서 그냥 편히 살고 싶어요" 라고..
그는 1류대를 나온 이른바 한국식 인재이다. 스팩을 올리고 대기업에 입사해 보니 결국 자신이 원하는 미래는 보이지 않는다고..
차라리 그렇게 할 바엔 인사과로 이동해서 몸편히 살고 싶다는 말이다.

사실 대기업에 다니는 친구들과 후배를 보면 마음이 아프다. 왜냐하면 불철주야 근무하고 노력해도 예전의 창의적인 생각과 깨어있는 생각들은 다들 어디로 사라져버렸는지, 근 3년만 되면 완전히 조직화 되어 있었다. 창의성보다는 조직성에 더 촛점을 맞춘 문화가 그들에게도 상당히 영향을 미친것이다.

왜 이렇게 된걸까? 예전과 같이 이야기 했던 우리만의 창의성과 깨어있는 사고는 다들 어디로 갔단 말인가?


우리 동양철학의 시작을 알리신 공자께서도 교육의 본질에 대한 위대한 이야기를 하셨다.
공자가 말씀하신 이야기중에서 몇가지가 떠 올라 몇 자 적어본다.

"교육이란 학생을 가르치기 위한것이 아니고 훌륭한 선생을 만드는데 있다."
"잘가르친다고 하는 것은 반드시 그 뜻을 따르는 사람이 있다는 것이다."
"불의로서 돈을 벌고 높은 지위를 얻었다한들 저 뜬구름과 같을 뿐"
"나에게 고기포 한다발이라도 가지고 온 사람을 내가 아는 것을 가르치지 않은 적은 없다."
"가르침만 있고 류(사회적 계급)은 없다." - 공자는 당시 이미 보편교육을 실천했던 사상가

인성보단 물질이 앞선 한국식 교육, 보편교육보다 앨리트위주의 이른바 돈 있는 사람만 특혜를 받을 수 있는 교육.
점점 늘어만 가는 사교육과 아직도 고쳐지지 않은 학벌 정치 싸움들. 초등학교를 다니면서 학원을 3개나 다니고 있는 우리 조카, 끊임 없이 들어오는 대학원 생들의 졸업작품 의뢰건들을.. 보면서 과연 한국의 교육. 이대로 괜찮을까 하는 생각이 들었다.


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

    2010.08.18 15:05 신고 [수정/삭제] [답글]

    "배우고자 하는 자세만 있다면, 3살 꼬마도 스승이다"
    누가 한말인지는 모르겠지만, 항상 가슴에 담아두고 있답니다.

  2. Favicon of http://shelly.tistory.com BlogIcon 쉘리월드

    2010.08.18 20:24 신고 [수정/삭제] [답글]

    지식채널 e -(ebs) 방송에서 핀란드의 교육정책 1,2 부를 보고 우리나라 교육현실에 몸담고 있는 분들이 꼭 봤으면 좋겠다 라는 생각을 했었어요~^^글 잘 보고 갑니다!~

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

      2010.08.19 15:15 신고 [수정/삭제]

      선진교육과 우리나라 교육을 비교해 봤을 때 너무 일본식 위주의 스타일을 따라가지 않았나.. 걱정이 많습니다. 이것도 일제강점기부터 뿌리박힌 사상의 씨앗들이 아닐런지..쩝. 소중한 댓글 감사합니다.^^

  3. Favicon of http://revirth.me BlogIcon revirth

    2010.08.27 16:47 신고 [수정/삭제] [답글]

    안괜찮습니다 ㅎㅎ
    사실 교육 쪽에 변화는 수많은 이들의 이해와 동의가 있어야 하는데 ... 글쎄요

댓글을 남겨주세요.

[Windchill Security] Domain ACL 참고.

Posted at 2010.08.18 10:00 // in Bender // by MOOVA 무바㏇

위의 문서에서 Spring Security의 Domain ACL을 학습하는데 좋은 감을 얻을 수 있습니다. 챕터 10 Administering Access Control편을 봐주세요.

Permission

Description

Read

Determines the right to know the existence of the object and view it.

Modify

Determines the right to change the attributes of an object, as well as other characteristics that are part of the object definition. (For example, you have the right to modify the description attribute for a group, as well as remove a user from that group.)

Create

Determines the right to create an object.

Revise

Determines the right to revise an object. Revising creates a new version of the object at the same level as the original in the version tree. For example, you can create Revision B from Revision A.

New View Version

Determines the right to create a version for a specific view.

Delete

Determines the right to delete an object.

Change Permissions

Determines the right to change the ad hoc permissions that others have.

Users, groups, or organizations granted the Change Permissions permission are allowed to change the ad hoc permissions of others to the permissions they themselves have or to a subset of the permissions they have.

Administrative

Determines the right to perform certain administrative tasks. (For example, this gives you the right to break a lock or change an object's owner.)

Full Control (All)

Determines full control. A user, group, or organization with the Full Control (All) permission has all rights currently defined and any defined in the future. Therefore, when new permission types are defined, you do not have to write rules that specifically grant them to principals with full control.

 

2010:08:18 07:29:53

위의 그림은 Windchill의 ACL 편집기중 일부입니다. Type에 각 도메인 클래스들이 목록화되어 있고 이것에 대해 상태나 퍼미션을 지정합니다. 앞장에서 설명한 [Spring Security] Domain ACL 실무판 의 결론은 바로 위와 같은 메니저를 만들기 위한 튜로리얼이라고 해도 무방합니다. 제가 엔지니어들에게 기회가 되면 Wnidchill에 대한 학습을 권하는 것은 오픈소스에 녹아 있는 여러가지 가치 있는 공학 패턴과 사상이 들어 있기 때문에 기술적인 안목을 넓힐 수 있다는데 그 의의를 둘 수 있습니다.

Windchill은 그 외에도 비즈니스 프로세스,워크플로우, MDA기반의 애자일 설계, 기민한 UI조립(OOTB), CBD, UML, 프로젝트 메니지먼트, PLM/PDM, ORM, 신 MVC, 웹 프레임웍, 분산처리 환경, 대용량데이터베이스, 객체지향 설계(OOAD) 등 무수히 많은 사상이 녹아 있는 제품입니다. 또한 개발자에서 컨설턴트로 업그래이드하실 분들에게 강추한번 때리고 싶은 영역입니다.

이 단락은 Windchill을 홍보하는 것이 아닌 Windchill의 학습이 얼마나 많은 가치를 엔지니어에게 줄 수 있는 지 설명하기 위함이고, 또한 좋은 사상은 언제나 오픈소스나 타 벤더회사들이 모방하고 발전시키기 때문에, 자바가 태어났던 시절부터 같이 커온 Windchill이라는 색다른 영역에 대한 사상을 기회가 되면 한번 경험해 보시면 좋겠다는 취지로 작성하였습니다. ( Windchill의 분산처리 환경은 RMI와 EJB가 나오기 이전부터 발전시켜온 영역중에 하나입니다.) 단 기타 오픈소스처럼 한번 학습하고 바로 쉽게 이해할 수 있는 수준의 사상은 아니기 때문에 Windchill에 대한 경험과 학습은 많은 노력이 필요합니다. 하지만 노력뒤엔 언제나 밝은 웃음이 기다리고 있겠죠:)


2010:08:18 07:37:00
PTC 소식지 - http://communities.ptc.com/
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바