대한민국 대표 개발자 [짱가™] 2ed

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'강점혁명' 의  strength finder 를 통해서 조사했던 나의 강점
몇년 지났지만, 여전히 유효하다. 
자신을 잘 알아야 한다. 



나의 대표 테마들:

Focus/초점: 초점 테마에 강한 사람들은 방향을 정하고, 끝까지 노력을 기울이고 목표를 위한 진로에서 벗어나지 않도록 필요한 수정을 가합니다. 이 사람들은 우선순위를 정한 다음 행동합니다.

Learner/학습자: 학습자 테마에 강한 사람들은 배우고 계속 진보하려는 열망이 강합니다. 특히 이 사람들은 결과보다는 학습 과정에 흥미를 느낍니다.

Significance/중요성: 중요성 테마에 강한 사람들은 다른 사람들에게 매우 중요한 존재가 되고 싶어 합니다. 이 사람들은 독립적이며 인정 받기를 원합니다.

Self-assurance/자기 확신: 자기 확신 테마에 강한 사람들은 자신의 생활을 관리하는 자신의 능력에 자신감을 느낍니다. 이 사람들은 자신이 결정이 옳다는 자신감을 갖게 해주는 내적인 척도가 있습니다.

Woo/매력: 카리스마 테마에 강한 사람들은 새로운 사람들을 만나 그 사람들의 마음을 얻는 일에 도전하기를 무척 즐깁니다. 이 사람들은 어색한 분위기를 깨고 다른 사람과 관계를 맺는 것에서 만족감을 얻습니다.
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

(하루의 풍광)
오늘도 회사에 출근해서 먼저 에버노트를 펼쳐 봅니다. 
간밤에 내가 노트했던 것, 어제 노트했던 todo list , 업무 기록 등을 보면서 오늘 할일을 체크를 하죠
그리고 Things 를 통해서 애플기기간 연동을 통해서 업무들의 우선순위를 보게 됩니다. ( 그러고 싶습니다만, 아직 애플기기는 맥북뿐이라. ㅋㅋ ) 
오늘은 온통 회의군요. 
회의를 통해서 Action Item 이 도출되고 하루 하루 진척되어가는 것이 쌓여만 간다면, 
각 구성원의 R&R 이 명확해지고 회의를 통해서 도출하고자 하는 결과만 명확하다면 더할 나위 없습니다. 
회의를 할때는 항상 '회의주제'를 정하고 회의에서 의사결정되어야 할 기준이 되는 자료에 대해서 정리해서 들어가는 것은 필수입니다. 
그렇게 각자 할일이 할당되고 자신의 일을 하고 다시 다른 회의를 합니다. 
Action Item 에 대해서 정리 하고 
이해관계자들과의 전화/메일 등의 커뮤니케이션을 진행하고 
뭔가 작성할 것이 있으면 작성을 합니다. 
그래도 이정도로 정리되면 깔끔하죠... 
코디네이터 역할이나 관리 역할을 한다면 일방적인 지시나 앞에서 달려가는 것 보다는 위의 협력적인 방법이 조금 더 피곤하더라도 장기적으로 볼 때 구성원의 에너지 낭비를 없애고 서로 만족할 수 있는 길이 될 수 있을 것 같습니다. 



연차가 되면서 ... 관리로 가는 사람들은 기술에 관심 없어서 그런줄 알았습니다. 
머 그런데.. 기술 관심 가지고 계속 그 길로 가려고 해도... 
성향차, 
스타일, 
분야에 대한 전문성, 
매니저의 인력 관리 스타일, 
적응력, 
프로젝트에서의 빈 공간의 발생, 
보충할 수 있는 인력의 성격 등.... 
내부/외부 요소 에 의해서 자신의 역할이 결정이 되게 되더라구요. 
알게 모르게 관리적인 요소가 몸에 배어 있고 그런 역할이 나도 모르게 나에게 와 있는 것이... 
'을' 에 있던 영향인건지...
아니면 위에 기술한 내/외부 요소에 의한 것인지는 아직 모르겠습니다. 

어허.... 지금 그렇게 모른다는 거슨???  머 까놓고 이야기 하면 부끄러운 거죠... 

항상 ... 모자람을 느끼고 내가 진정으로 원하는 것을 하기 위해서 노력합니다. 
그리고 여러가지 다른 관심들은 진정으로 원하는 것을 하기 위한 보충적인 요소들이기에... 시간 분산이 많은 것도 사실이고... 

하고 싶은 일 중에 '기술 컨설팅' 을 하고 싶어요. 
말 그대로 '기술' 에 관한 컨설팅. 
제가 모르는 것이 더 많지만, 
기술에 어떻게 접근해야 할지
해당 기술을 적용함에 있어서 어떤 절차를 지켜야 할지 
그리고 조직 구성을 어떻게 해야 할지.. 

네 아키텍트가 해야 할 역할입니다. 근래에는 아키텍트라는 역할에 대해서 참 많은 부분에 아키텍트라는 정의를 하죠... 
저는 그것보다는 더 상위 단계에서 조언 혹은 고문 역할을 하고 싶은 거죠.. 

희한하게 엔지니어 세상은 그게 쉽지 않아요. 
잘못하면... 자존심이 이슈가 되거든요.
또한, 위에서 얘기한 기술을 기반으로 하는 그런 컨설팅 조직은 거의 없어요

우리 나라에 컨설팅 조직들은
벤더의 프리세일즈 컨설팅, PMO 컨설팅, 2000년대 초반의 CBD 에서 출발해서 변형된 컨설팅, 경영 컨설팅, 그리고 근래의 여러 업체에서 하고 있는 공학 컨설팅... 
이런 성격인것 같습니다. 

컨설팅은 문서화 인것 처럼 변질 되어 가고 있는 것도 없쟎아 있는 듯 하고 
제랄드 와인버그의 '컨설팅의 비밀' 에서 이야기 한 것처럼 그렇게 깊숙하게 고객의 가려운데를 긁어줘야 하나 싶고..
그래서... 저는 제가 하고 싶은 일을 'IT coach' 라고 이름을 붙여 봤습니다. 

실제 그런 일을 해보고 싶네요. 
지금은 좀 그럴지 몰라도.. 
나이 지긋해 져서... 상대방을 존중하고 올려줄 수 있는 나이가 되면... 

그래서 '코칭' 기법에도 관심이 많고 '프레젠테이션' 기법에도 관심이 많고 김창준님의 AC 과정에도 관심이 많고 글쓰기에도 관심이 많고 강의 기법에도 관심이 많습니다. 
그러면서 실제 본업인 소프트웨어 개발분야는 꼭 봐야 하니 얼마나 관심이 분산되겠어요? 그 분야만 해도 참 많은 분야가 생기고 있고 발전이 되고 있어서 하나를 따라가기에도 쉽지 않은 시대인데요~~ 
그래서 선배들에게서는 항상... '넌 너무 욕심이 많아!!' 라는 말을 듣곤 합니다. 

'집중과 선택'
'T자형 인재' 
이런 좋은 말들이 있지만, 
항상 결론은 지금의 관심사, 지금 앞에 있는 좋은 기회 였던 것 같습니다. 
여기서 조건은 '지속가능해야 하고 일정 수준까지.... ' 이게 키 포인트더라구요. 
왜냐면 어느 순간에 멈춰버리고 시간이 지나면 다시 refresh 되거든요. ^^
항상 무언가를 하고 있고 무언가에 관심을 가지게 되는 이유였습니다. 

역시 글을 쓰다 보니 제 얘기로 귀결. 
담엔 '봉도사' 님의 기를 좀 받아서 '깔떼기'를 좀 대 봐야겠어요.. 
희한하게.. 자꾸 '반성모드'야... 




 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

파이썬의 클래스 정의 

hdfirstpy.ch6.Athlete.py 파일에 Athlete 클래스를 class Athlete: 처럼 만들었다면

다른 파일에서 호출 할때는 

from hfpython.ch6.Athlete import Athlete

이렇게 써주고 사용을 한다 

타입을 프린트 해 보면 

<class 'hfpython.ch6.Athlete.Athlete'>

이렇게 나온다. 

즉, 어떤 파일에 이런 클래스가 정의되어 있다.. 그런 거다

자바에서는 public class 명과 파일명이 같아야 하고 생성자 명이 같아야 하지만… 파이썬은 인터프리터 방식의 스크립의 언어라서 그런지 인식하는 방법이 다르다. 

클래스 정의가 자바나 C#과는 달라서 좀 헷갈리긴 하는 구나 

그리고 메서드 정의는 self를 파라미터 맨 앞에 써줘야 한다. 

즉, 자신의 객체가 넘어간다는 것이고 그 객체에 뭐가를 해 준다는 거다. 

자바로 따져보면 자바는 묵시적으로 넘어가지만, 요놈은 명시적으로 self 처리를 한다는 것이 다르다. 

클래스로 만들때 메서드의 정의가 달라지는 것은 요놈이 클래스로 정의 되니 그렇다. 

그렇다면… 왜 그랬을까가 있을 것이다… 

나중에 연구해보자. 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

(  병곤 형님의 나에게 프로젝트 성공에 대한 책을 제안을 하셨다.. 지나가는 말로라도... 그래서 문득... ) 

내가 열정이 있는 것이든
맨파워가 대단한 프로젝트든
고객의 지원이 전폭적이든
여기 있다가 나가면 정말 내게 좋은 기술이 쌓일 만한 일이든
돈을 많이 받든
내 승진이 보장되든 

.....
하여튼 프로젝트 자체는 쉬운게 없다.

프로젝트 성공이라는 용어가 갑자기 생각이 났다.
프로젝트를 성공해야 한다.. 이런 것은 어디서 비롯 되었을까?
실패하면 쪽팔리니까?
아니면 돈을 못받으니까?
짤릴 수도 있으니까?
내가 속한 조직이 보여지는 게  문제가 생기니까? 

그렇지..
모두 공감이 간다..
그리고 이유가 있는 거지.

그런데 문제는 그 프로젝트의 성공을 대하는 구성원에 있는 것 같다.
구성원이 '프로젝트가 성공한다' 라는 생각을 하는 프로젝트는 정말 성공한다.
일정에 지연이 있고 비용이 많이 들었어도 타당한 근거가 있고 그에 따라서 성공이 된다고 생각이 든다.

문제는 구성원간 다른 뷰를 가지고 일을 하면
정말 서로 맨파워 뛰어나고
다들 열심히 뛰어 다니고
의지가 굉장한데 ...
실제 진척이 없거나 뺑돌이 돌거나 더 복잡해 지기만 한다.

그 시점에서 가장 좋은 것은 '멈추고 3자의 입장에서 바라보는 것' 
그러나 10여년의 경험으로 볼때 현실을 그렇게 되지 않는다.  
그렇다면 어떻게 해야 할까?
모든 구성원들이 같은 공감대를 가지기 위해서 항상 노력해야 한다.
커뮤니케이션의 룰이 있어야 하고
서로간의 공유하는 채널이 통일되어 있어야 한다.
그리고 책임에 못지 않게 권리도 함께 있어서 자신의 책임을 달성할 때 자신이 할 수 있는 것이 있어야 한다.
그런게 없으면
구성원은 자괴감 + 상실감 + 허탈감이 지속되다가 자신감을 잃어가게 되고 냉소만 날리거나 맘속으로 포기하게 된다.
그리고 우리는 '잘 될지도.. 성공할지도...모르지만...' 닥치고 일만 하게 된다.
왜? 어차피 욕얻어 먹을 거  닥치고 일이라도 열심히 하면... 내 스스로의 양심에 거리낌 없고 욕은 덜 얻어 먹고 할말은 있게 된다. 
라고 생각을 하지.

그런데 ... 그게 정말 비 양심적인 거야.
'이런게 아니다' 라는 생각을 하고 있는데 말도 안하고 그냥 따라간다. 
그리고 그냥 포기하고.. '원래 그런거야' 라고 생각을 해버린다.
우리가 어떻게 할 수 없는 조직구조에서 우리는 길들여져 버린거다. 

아니면... 정치를 하게 된다.
즉, 연막을 치거나 빠져나갈 구멍을 찾게 된다. 
그러면? 그런 정치나 관리를 모르는 엔지니어들은 그 덕에... 선장을 신뢰하지 못하게 되고 ... 
그 배는 선장이 칼을 휘두르며 가고는 있지만 그냥 하는 척만 하거나
선장을 믿지 못하고 무시하게 되는 상황이 되어간다. 

난 협업을 좋아한다. 고 생각을 해왔지만 돌아보니 나도 역시 모니터와 대화를 하는 편이다만 , 
그래도 믿음에 변함이 없는 것은 협업을 통해서 공감을 통해서 구성원이 서로의 빈곳을 채워나갈 때 시너지가 일어 난다고 생각한다. 
그리고 항상 역할간의 빈곳을 메워주는 공기 같은 구성원은 있게 마련이고 이 구성원이 누구보다도 더 대우를 받을 수 있는 팀이 되어야 한다고 생각한다. 
실질적인 눈에 보이는 성과 보다 눈에 보이지 않는 곳을 채워주는 이가 있기에...
프로젝트가 진정으로 잘 돌아가게 되는 거다. 

물론 kpi 가 중시되는 현실을 완전히 무시할 순 없지만, 
적어도 그런 부분을 인지하고 서로가 신뢰하고 칭찬하며 일해야 한다는 것이다. 

지금 하고 있는 프로젝트에서 여러가지 난관이 있고 방향의 변화가 많아서 힘든 가운데서도 
많은 이들이 의지를 가지고 있고 
어떻게 하면 성공시킬 수 있을 지에 대해서 많은 토론을 하고 고민을 한다. 
그리고 그들의 고민들이 쌓여가면서 방향이 잡혀간다. 
구성원들의 맨파워가 좋기에 충분히 쉽게 갈수 있는 데도 불구하고 
어쩔 수 없는 방향의 뼈대가 흔들리거나 
조직 외부와의 의사소통으로 인한 지원이 힘들거나 
방향 변경들로 인해서 일보 후퇴할 때가 있다.
또한, 사업이 만들어져 가는 과정이어서 역할 또는 자신의 knowledge base 가 쌓여 가면서 시너지가 일어날 수준까지 가기를 시간이 기다려 주지 않는다. 
이럴때 구성원들은 여러가지로 자신의 열정을 깎아 먹을 수 있는 계기가 된다. 

만약에 ... 이런 비슷한 상황에서... 정말 힘든 상황이 되었다고 가정을 하자. 
누군가 스스로 극복해야 한다고 이야기 하면 나는 그것은 김어준이 말한 '유인원의 논리' 라고 말하고 싶다. 
팀이고 서로 같은 방향을 바라보고 서로간의 공감대를 가지려 노력하고
상대방이 나를 이해 못한다면 포기하거나 '그래 너대로 가라' 라고 생각하는 것 보다는
'상대방을 이해시키거나 내가 상대방쪽으로 기울어지거나' 를 선택해야 한다. 
그래야! '팀' 으로 일하는 의미가 있지!

다시 현실로 돌아와 보면...
이제 실제 보여줘야 하는 때가 얼마 남지 않은 만큼 각자의 피로도가 높아 질 것이다. 
이럴 때 더 잘해야 한다. 
더 많이 이야기 하고 더 많은 공유를 하고 더 정리를 잘 하려 노력해야 한다. 
엔지니어링 하러 들어가서 또 코디네이터 비슷한 일을 하고 있는데.... 휴... 
내가 처음에 쌓아나가는 것이 시간이 걸리는 것을 기다려 줄 수 있는 상황이었으면 될텐데... 
자꾸만 변경되는 컨텍스트에서 스스로 스트레스 좀 받았었다. 
내게 잣대를 들이대는 분위기도... 
뭐 하여튼 지금 코디네이터 관련 일은 원래 내가 잘하던 일이고 충분히 정리 잘 할거라 믿는다.
다만, 내가 더 하고 싶은 일을 못하니.. 그건 스스로 하자.
( 문제는 이것도 삽질이 경험이 되어야 하는데. 그 경험을 할 시간과 들판이 없어서.. ㅋㅋㅋ ) 


프로젝트의 성공을 이야기 하다가 옆으로 빠져서 프로젝트 구성원간의 관계와 내 요즘 얘기에 대해서 이야기 하고 있네.... 

근데 요즘 느끼는 것은... 칭찬도 스킬이 있는 것같다.. 가장 중요한 것은 '진실성!' 
이 부분은 다음 기회에... 
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

IT 종사자들이 맥에 열광을 하는 사람이... 일명, 애플빠 가 많다는 것은 익히알고 있어서 
1년 전부터 맥을 사용하고 싶었으나 경제적 여건상 사용하지 못한 터에

프리랜서로 돌아서면서 맥북 프로를  중고로 구입하여 사용하고 있다. 
맥에 개발도구 셋팅해보고
키노트 깔아서 사용해보고
맥에서 기본으로 제공해주는 유틸들 사용하면서...

'아 정말 아름답다!' 라는 생각만 든다.
여러가지 잡짓거리, 꼼수 를 부리지 않아도 이쁘게 , 있어보이게 나오는 게
정말 반하게 만든다.

윈도우에서 내 손에 길들여진 여러가지 단축키
home 키 , end 키 , page up, page down 이 없어서 약간 손이 더 갈 때도 있지만,
맥의 단축키에 익숙해지려 노력중이다. 
그리고 업무상은 윈도우와 섞어서 사용해야 하므로
이게 정말 헷갈리기 시작한다.


일이든 개인 생활이든 주 사용을 맥으로 하고 윈도우를 서브로 돌리려 의식적으로 노력해야 한다. 
그래야 생산성의 저해가 없겠다. 싶다. 

올해가 가기전에 맥북과 키노트, 페이지, iPhoto, iMovie 의 능숙한 사용자가 되길 바라는 것은
내가 사용하는 도구에 대한 재미와 내 개인 생산성을 위함이다. 

더불어 리눅스 커널을 사용하는 것이 근래의 내 전공을 바꿈에 있어서 또한, 도움이 되고 있다. 

사용한지 보름 되어가지만, 아직까지는 만족도가 높아지고 있다. 

초보 사용기 1탄 끝. ㅋㅋ





 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

맥용 STS 에 pydev 설치해서 사용중이다. 
어제까지 IDLE 에서 잘 돌아갔던 소스가 갑자기 컴파일이 안되고 x 표시
그리고 pydev 화면은 다음과 같았다.

그리고 메시지는 mixed indentation:Tab found
찾아보니 스페이스와 탭이 섞인 문제 
이런 것도 문제가 생기나? 거참.. 
소스 정리로도 해결이 안되는.. 
파이썬은 탭과 스페이스로 문법 구분을 하다보니 그런 부분에 민감한듯. 

에디터를 옮기다 보니 나도 모르게 space 가 들어간 것 같다.
하여튼 스무줄 정도 되는 펑션 소스를 모두 재 편집하니 된다. 
어이없는 삽질 삼십분.  

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

내 지나온 과정에서 익혀 온 과정을 돌이켜보면

내가 학습하는 스타일은
1. 이론 학습
2. 삽질
3. 이론 학습
4. 체득

이런 류의 과정을 겪으면서 몸으로 체득해오고 이해해 온 것 같다.
하지만 요즘 기술의 변화의 속도와 환경 변화의 속도를 생각해보면
핵심을 빨리 캐치하고 필요에 의한 선별 능력, 핵심의 이해에 의한 응용이 무척이나 필요한 시대인듯 싶다.

그래서 지금까지 익혀온 내 학습 방법의 변화 필요성을 느낀다.

먼저 혼자서라도 삽질을 해 봐야 하고 output 은 초반엔 늦을 지 몰라도 초반기가 지나고 나면 핵심을 이해하여 적용하고 리드하던 예전 스타일은 지금 내 입장에서는 맞지 않다는 생각이 든다.
문제는 예전에 익혀 온 것도 그 동안 많이 변했고, 도메인 역시도 익숙하지 않고 ... 몇년간의 외도로 인해서 익숙해지려면 시간이 걸릴거라는 거다.
또한, 위에서 기술한 내 스타일도 크게 작용할것이고....

오히려 예전에 싫어하던 겉만 얼른 훑고 뭔가 아는 듯이 썰을 푸는 그런 것을 연습해야 하지 않나 싶다.
왜?
스스로 그렇게 진행하다보면 핵심은 알게 되어 있을 거라고 생각이 된다.
또한, 필요한 시기가 되어서 깊게 들어가야 한다면 그 때 깊게 들어가면 된다.

모든 일하는 방식에 있어서
각 분야의 전문가가 있어야 하지만, 지금 저럼 격변하는 시기에 하나만 꾸준히 파서 결과물을 내기에는 물리적인 시간이 너무 부족하다.
그런 것은 집에서 혼자 연습하고 체득해 나가야 한다.
혼자 연습하고 체득한 부분을 일에 이용할 수 있으면 베스트 이겠지만,
실제 일에서는 보지도 못했던 것들이 튀어 나오기 일쑤이고 이제는 그런 변화에 대응해야 하는 입장이다.

( 오랜 세월 몸에 굳어져 왔고 잘 알지 못하면 아무 말도 안하거나 못하는 )
내 성향을 생각해 보면 장인형태/공방형태  의 일을 하는 것이 맞으나
현재 내가 있는 업은 SI 성이 강하고 배포가 바쁘게 진행되는 성격이 강하다.

스스로 변해야 한다.
변해야 산다.