'이전글/2009'에 해당되는 글 15건

  1. 2009.09.07 D-158일 (3)
  2. 2009.05.29 아닌 건, 아닌거죠! (11)
  3. 2009.04.30 의사와 컨설턴트의 4가지 공통점 (3)
  4. 2009.04.28 (배치 고도화) 2. 명확한 목표 설정 (2)
  5. 2009.04.27 여의도 출근 (8)

D-158일

이전글/2009 2009.09.07 15:08
158일 남았습니다. 행운이 함께 하길..
저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

아무리 좋은 약도 용도를 착각해서 오용하거나, 복용해야 할 양을 무시하고 남용하게 되면 오히려 몸을 해롭게 한다는 것이 상식입니다. 하지만 오용/남용을 막아야 하는 것은 약 뿐만이 아닌 듯 합니다.

암호같은 글이지만, 딱.. 여기까지.

저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

몇 가지 실수를 통해 느낀 바가 조금 있어, 그것을 의사란 직업에 빗대어 정리해봅니다.

1. 진단 없이 섣부른 판단이 담긴 내용을 함부로 발설해선 안된다.

예전에 얼굴색이 어두운 환자의 간을 수술해서 그 환자의 병을 고친 경험이 있는 의사가 있다고 치자.  마침 어느날 그 전과 유사한 얼굴색이 어두운 환자가 찾아왔다. 그 의사가 자기를 찾아온 새로운 환자에게 낯빛이 안좋으니 배를 째야 겠다. 예전에도 그런 경험이 있기 때문에 뻔하다. 라고 진단을 내린다면 그게 과연 옳은 행동일까?

설사 그 환자가 빠른 조언을 원한다고 하더라도, 진단을 한 다음 처방을 말씀드리겠다고 전해야 한다. 어쩔 수 없이 빠른 판단을 내려야 하는 경우라면, 진단을 해보지 않아 정확하지 않다는 단서를 달고, 이럴 가능성도 있다는 수준의 정보임을 정확히 주지시켜야 한다.

2. 환자를 이롭게 하기 위해 최선을 다하며, 필요하다면 하기 싫어하는 일도 하도록 설득해야 한다. 단, 요령이 필요하다.

날씬하다는 말을 듣고 싶어하는 뚱뚱한 환자가 찾아왔다고 해서, 환자가 원하는 대로 당신은 날씬하고, 아무 문제가 없다고 말해버리는 사람은 의사가 될 수 없다. 설사 듣기 싫어하는 말이라고 하더라도 당신은 체지방이 초과되었으니, 반드시 체중을 10kg 이상 줄여야 한다고 말할 수 있어야 한다. 

그러나 그 사람이 그런 말을 바로 듣고도 수용할 수 있는 성격인지, 아니면 설득해야 되는 사람인지, 설득한다면 어떤 장소에서 어떤 방법으로 전달하는 것이 효과적인지, 그 일을 하는 방법을 운동으로 하도록 권유해야 하는 상황인지, 지방흡입수술까지 취해야 하는 상황인지 등은 개인의 성향과 상황에 따라 다를 수 밖에 없다. 그런 상황을 신중히 고려해서 결국 그 환자가 건강해도록 만드는는 것이 환자로써 의사를 찾은 사람에 대한 최소한의 책임이다.

3. 고객과의 관계에서 알게 된 모든 내용은 어떤 사소한 것이라도 절대 새어나가도록 해선 안된다.

환자가 SI에 걸렸다. 그 원인을 살펴보니 미국 출장 중에 몰래 멕시코에 잠깐 휴양차 들린 것이 드러났다. 그 환자 왜 SI에 걸린 줄 알아? 세상에 출장가서 놀고 온거 있지?라는 식의 정보를 친구와의 술자리에서 조차 외부에 발설해선 안된다. 고객과의 정보보호서약을 맺은 의사에게는, 술자리에서 내뱉는 사소한 그런 말 실수 조차 범죄가 될 수 있다.

4. 새로운 치료법에 지속적으로 관심을 가지되, 임상실험을 마치지 않은 치료법을 환자에게 함부로 처방해서는 안된다.

임상실험을 마친 더 안전하고 효과적인 치료법이 개발된 상황에서, 단지 내가 아는 방법이 그것 뿐이라고 아는 방법으로만 치료하는 의사가 되어선 안된다. 그런 상황을 방지하기 위해서는 설사 결국 그게 그거라는 결론에 도달하더라도 더 나은 치료법에 대한 조사와 공부, 훈련을 게을리 해서는 안된다.

하지만 그렇게 알게된 새로운 치료법에 논리적으로 타당하고 아주 효과적일 수도 있다고 생각 되더라도, 이제 갓 학회에 보고되어 임상실험 조차 거치지 않은 치료법을 최신 기법이니 더 효과적일거라는 생각만으로 환자에게 함부로 처방내리는 것은 지극히 위험함 행동이다. 검증되지 않은 치료법은, 설사 일견 효과적일 것 같은 판단이 들더라도, 그 환자의 체질과 맞지 않을 수도 있고, 설사 치료된다고 하더라도 또 다른 부작용을 야기할 수 있는 가능성이 얼마든지 있기 때문이다.

저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

주의 : 쓰다보니 너무 길어졌습니다. 정성들여 쓴 글이나 지루하실 수 있는 글이므로 섣불리 관심을 두고 읽지 말아주십시오. 후회해도 모릅니다. ^^

비전 정의란?

일단 가벼운 퀴즈 하나. 인터넷에서 자주 보이는 아래 그림에서 명확한 목표를 설정한다는 것, 다른 말로 비전을 정의하는 것(Visioning)은 어떤 모습을 찾아내기 위한 걸까요?


비전 정의가 고객이 설명한 요건을 그대로 받아 적는 것 또는 영업이 약속한 그 비용과 일정, 인력으로는 도저히 불가능한 휘황찬란한 약속을 최대한 방어적으로 만드는 것 등으로 곡해하기 쉽지만, 제대로 된 비전 정의고객이 정말 필요한 것을 찾아내는 과정과 그 결과물, 그리고 목표한 그것을 고객과 개발팀이 함께 바라보고 추구하도록 만들도록 변화시키는 것이라고 생각합니다.

일반적으로 어플리케이션 개발 LifeCycle은 Metrozen이라는 외국의개발 업체 홈페이지에 떡~하니 올려둔 그림에서 보듯 Definition, 그러니까 해결하고자 하는 Problem에 대한 정의 [What] 에서 부터 출발합니다. 지금껏 교육이나 수 많은 서적들을 통해 이미 확고하게 결정되어 있는 문제들을 어떻게 기술하는지, 그걸 어떻게 분석하고 설계하는지, 또 어떤 기술들을 써서 구현하고, 테스트하는지 등을 훈련해온 (저를 포함한 ㅠㅠ)엔지니어들은 어떻게 하면 그 문제를 잘 풀어낼 것인가 [How]를 두고 경쟁하듯 그 기술의 깊이와 넓이를 확장해 나가는데만 집중하는 경향이 있습니다.  애당초 그 일을 왜 시작하게 된 것인지는 생각조차 하지 않은채, 때론 자존심을 걸고 열띤 토론을 펼치는 그들만의 리그(?)를 개최하기도 하면서요.


흔히들 프로그래밍을 문제 해결(Problem Solving)이라고 표현합니다. 즉 Problem + Solution이 합쳐진 것이죠. 프로그래밍이 소프트웨어 공학의 수준으로 발돋움하기 위해서는 Right Problem + Right Solution이 필요합니다. Any Problem + Same Solution(어떤 문제는 내가 아는 방식으로 풀어주마~)도, Wrong Problem + Right Solution(문제가 무엇이든 최선의 해결책을 찾아주마~)도 모두 답이 아닌 것이죠.

그런 점에서 딜로이트의 EVD(Enterprise Value Delievery) Methodology는 그 구성과 이름이 무척 마음에 듭니다. 보통 방법론은 xxCBD와 같이 반복 개발이니, 컴포넌트 기반 개발 기법을 채용해 트렌드를 따른다느니 하는 기술적인 느낌을 드러내죠. 고객 입장에서는 Enterprise Value를 Delievery하겠다는 EVD란 이름이 더 마음에 들지 않을까요? 그리고 비전 정의와 Planning이 제일 앞에 위치한 점도 바람직합니다. 사실 비전을 명확히 하면, 제안 단계에서 제출했던 계획을 새롭게 뜯어 고쳐야 하는 경우가 많으니까요. 그런 이유로 일정을 뒤틀어버리면 고객이 두고만 보지는 않을거라구요? 그게 정말 필요한 것이라면 방법은 찾기 나름이겠죠. 안되는 이유를 찾아 정리하고 남 핑계대며 뒷다마 깔 시간을 아끼면, 가능한 방법을 찾을 수 있을지도..



배치 개발에 있어서의 경험 사례

쓰다 보니 서두가 길어졌는데요, 시간을 절약하기 위해 실제 경험은 느낌 위주로 간추려 얘기하겠습니다. 고객 정보가 담긴 프로젝트 상황을 공개할 수는 없기 때문에 공감하기 힘드실 수도 있구요.

(1) 니나 내나~ 모르는 건 마찬가지다.
전체 프로젝트의 1/7을 비전을 정의하는데 사용했습니다. 결국, 초반에는 서로가 서로의 입장과 말을 이해하지 못하고 있는 상태인거죠. 안될 줄 뻔한 이상적인 모습으로? NO! 구현 기술만 바뀌었지 이전과 별 차이없는 형태로? NO! 개발팀만 편한대로도 당연히.. NO!

다 옳은 말이고, 또한 다 자신의 시각과 바람대로만 주장하는 것이기도 하죠. 수 많은 이해 관계자들이 공감할 수 있는 비전, 각자의 의견을 받아들이고 검토하는 과정에서 서로의 입장 차이를 좁혀나가는 것. 그리하여 결정된 비전이 설계 과정을 빗대어 말하자면 4+1 View에서 UseCase View 역할을 하도록 만드는 것이 중요했습니다.

(2) 비전은 구체적일 수록 효과적이다.
그런 과정을 통해 도출된 비전은 뜬 구름 잡는 소리가 아니라 보다 구체적이고, 측정가능하며, 확인가능한 형태를 띄게 됩니다. 예를 들면 "월 마감을 기존보다 X일 줄이자"라거나, "기존 배치 프로그램을 최적화 해서, 실제로 운영될 전체 본수를 X0% 없애자"라는 형태가 되겠죠. 그렇게 구체화된 비전은 자연스럽게, 실제로 그렇게 될 수 있는 수준으로 구체화되고 프로젝트의 목표로 자리 잡습니다.

(3) 일정이 문제가 된다면, 병행해서 추진하라.
그 비전을 만드는 시점은 이미 제출했던 프로젝트 수행 계획서 상, 문제를 정의하고 분석하는 단계일 확률이 높습니다. 모두 다 비전을 정의한다고 손 놓고 있으면 고객이 불안해 할 수도 있겠죠. 그러나, 다행스럽게도 비전 정의에 전체 프로젝트 팀이 투입될 필요는 없습니다. 일정은 계획한 대로 진행하면서, 얼마든지 비전 정의를 병행으로 수행할 수 있죠. 폭포수로 짜여진 일정 계획 내에서 UP의 반복 개발을 성공적으로 적용하는 사례가 수 없이 존재하 듯 말이죠. 정말 소중하고 가치가 있다고 믿는다면, 방법은 얼마든지 있습니다.

(4) 조직이 복잡할 수록, 비전은 위력을 발휘한다.
미리 결정된 듯한 문제를 잘~ 푸는 것 만으로도 월화수목 금금금.. 이라고 생각할 수도 있습니다.  그런 생각이 드신다면 자신의 경험을 잘 되살려 보시길 바랍니다. 정말 힘든 것이 야근이였을까요? 저는 사람에 치이고, 서로 협조가 안되고, 이 일을 왜 해야 하는지 모르겠고.. 그런 상황을 만나는 것이 몇 일 야근하는 것보다 훨씬 더 힘들었습니다. 잘 정의되고, 조직에 전파된 비전은 항상 일정하게 가야할 길을 가르키고 있는 나침반과 같은 역할을 합니다. 업무와 기술이 다르고, 개발과 운영의 입장이 다르고, 서로 갑/을/병/정의 복잡한 계약 관계로 얽혀있을 때, 비전은 위력을 발휘했습니다. 기술적인 위험이 높아 자기 회사의 책임으로 떠 맡기 싫어 붕 떠버린 애매한 경계의 일거리가 있을 때, 새로운 것을 익히기 싫어 공격적인 반응을 보일 때.. 그들이 원하는 TO-BE 모습이 골고루 반영된 현실적인 비전은, 그런 장벽을 넘어설 수 있게 해주는 가장 큰 힘이 되어 주었습니다.


가슴아픈 실패담

(아침에 다시 읽고, 내용이 지나치게 상세해서 수정함)
기술적으로는 더 없이 훌륭했으나, 전체 프로젝트 측면에서는 실패했던 경험이 있습니다. 잘 만들었다고 잘난척하며 자부했던 그 시스템은 결국 세상에 빛을 보지 못했습니다. 흔히 얘기하는 정치에 희생된 경우라고 볼 수도 있지만, 돌이켜 생각해보면 제 잘못도 큽니다. 프로젝트 리더로써 고객이 정말 필요한 것을 좀 더 고민하고, 그 비전을 고객과 개발팀에 전파함으로써 같은 목표를 향해 달려가도록 만드는 가장 중요한 비전 정의 과정을 너무나 소홀했고, 구현의 완성도에 개인적인 욕심을 가졌던 그런 시건방짐이 그 시스템을 묻어 버리게 만든 근본적인 원흉 중의 하나일 수 있음을 깨달았기 때문입니다. 

우리가 사는 것도 마찬가지 아닐까요?

때 마침 이웃 블로그들에서 비슷한 주제로 글이 올라왔습니다. 자기 계발을 넘어서란 글이나, 사실을 행동으로 바꿔라는 글은 모두 Why를 깊게 고민함으로써 진정한 What을 찾아내는 전략적 사고와 비전 정의의 중요성을 다루고 있습니다. 아름다운 기부 청년으로 유명한 고영 컨설턴트의 인터뷰는 이런 비전 정의가 삶과 어떻게 이어지는 지를 보다 적나라하게 드러내고 있습니다.

“비전이라는 것을 무엇으로 정의하는가가 중요합니다. 많은 사람들이 who to become으로 비전을 정의해요. 내가 어떤 존재가 되겠다라는 생각을 합니다. 그러면 계속 포지션을 중요하게 생각하게 됩니다. 가령 대통령이 되고 싶다든가, CEO가 되고 싶다는 식이죠. 물론 이런 것도 좋지만, 대통령이 되려고 하는가에 대한 고민이 먼저 이루어져야 합니다. 대통령이라면 만들고 싶은 국가의 모습, 조직의 모습을 그려보는 것이 선행되어야 합니다.”

저는 도전하고 싶은 꿈을 찾는데 오랜 시간동안 많은 고민을 해야 했습니다. 처음 꿈을 찾았을 때, 꿈의 형태는 특정한 포지션이였습니다. 그 꿈을 품에 담고 있는 시간이 길어지면서, 자연스럽게 그 꿈을 이뤄내기 위한 원칙과 확신이 하나씩 늘어났습니다. 지금은 오히려 그 원칙과 확신이 지켜지는 모습을 만들어 낼 수만 있다면 처음 생각했던 그 포지션은 중요하지 않게 느껴집니다. 전 그것을 요즘 유행하는 Buzz를 본 따 물개의 Dream 2.0이라고 부릅니다. 일을 통해 하나씩 깨달음을 얻어 갈 때 마다, 그 만큼 삶도 풍요해지는 것이 느껴집니다. 우린 정말 매트릭스에 갇혀 있는 건 아닐까요? ^^

저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

여의도 출근

이전글/2009 2009.04.27 08:11
오랜만에 여의도로 출근했습니다. 정확히 1년하고도 2개월만이네요. 본사에서 일하는 걸로 알고, 술 한잔하자고 청하는 분들이 있을 것 같아 블로그로 근황을 올립니다.

어제는 미용실에서 머리도 단정하게 하고, 활기차고 단정한 인상을 주기 위해 옷에도 신경을 좀 썼습니다. 첫 인상을 무시하지 못하니까요. 좀 서둘러 출근했더니 시간이 많이 남아 근처 PC 방에 들러 어떤 가치들을 어떻게 전달할 것인지를 고민했는데 그러고도 시간이 남네요. 이번 프로젝트는 규모가 작아 명확한 롤이 정의되지 않았고, 투입 기간도 짧습니다. 짧은 기간 내에 많은 일들을 만족할만한 수준으로 진행하기 위해서는 현재 프로젝트 상황에서 어떤 것들이 정말 가치 있는 일인지를 빨리 파악해야 할텐데, 걱정이네요. 문득 8~9년 전쯤에 대학에서 보따리 장수하던 시절이 떠오릅니다. 새로 맡은 과목에 대한 준비를 하면서, 어떤 학생들을 만나게 될까 궁금하고 설레기도 했던.. 처음 서울에 와서 일한 곳이 여의도여서 그런 걸까요? 왜 이렇게 설레고 빨리 일하고 싶어 몸이 근질거리는지 모르겠네요. 이제 잠깐동안 함께 같은 문제를 고민할 분들을 만나기까지.. 20분 남았습니다.

아침에 보니 날씨가 정말 좋더군요. 이 좋은 봄날에 다른 분들도 힘차게 한 주를 시작하시길 바랍니다.
저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
1 2 3 

글 보관함

카운터

Total : 226,975 / Today : 6 / Yesterday : 44
get rsstistory!

티스토리 툴바