천객만래 [千客萬來] (It has an interminable succession of visitors)
팀원의 길, 리더의 길

(예병일의 경제노트, 2004.4.16)

하바드대 힐 교수의 연구에 의하면 많은 루키(신참) 매니저들이 승진을 한 직후에 자신들이 기대했던 것과는 너무나 다른 현실적인 문제에 직면하고 혼란을 겪는다고 한다.

힐 교수가 루키 매니저들을 대상으로 인터뷰를 실시한 결과, "관리자의 일이라는 것이 옆에서 바라볼 때는 그리 어려워보이지 않았고, 내가 상사가 되면 더 잘 할 것으로 생각했다. 하지만 막상 그 자리에 오르니 모든 것이 엉망이 되어 버린 듯한 느낌을 받았다"는 응답이 과반수를 넘었다고 한다.

루키 매니저들이 가장 많이 범하는 실수는 매니저들이 일하는 방식, 즉, '팀원들을 통한 업무 수행'이라는 것에 적응하지 못하는 것이다.

승진이 되기 전까지 루키 매니저들은 모두 일반 사원들로서 주로 개인으로서 조직에 공헌하던 사람들이었다. 그러나, 매니저는 직접 업무를 수행하기보다는 남들을 리드하여 업무를 수행하도록 하는 것이 1차적이고 가장 중요한 공헌 방식이 된다.

한상엽의 '루키 매니저를 성공으로 이끄는 길' 중에서 (LG경제연구원, 2004.4.2)



뛰어난 스포츠 선수가 현역에서 물러난 뒤 지도자 수업을 받고, '훌륭한 감독'으로 활약하는 경우를 우린 종종 봅니다.
현역 시절에는 별 두각을 나타내지 못했지만, 감독이라는 리더의 자리에 서서는 선수들을 잘 이끌며 팀을 승리로 이끄는 사람도 있습니다.

프로야구에서 현대의 김재박 감독은 전자의 경우이고, SK의 조범현 감독 후자의 경우라고 볼 수 있습니다.

하지만 현역시절 뛰어났던 스타 플레이어가 '실패한 감독'이 되거나, 아예 감독 자리에 가보지도 못하는 경우도 제법 있습니다.
이는 선수로서 필요한 능력과 감독으로서 필요한 능력이 완전히 다르기 때문입니다.

선수 때야 재능이 어느 정도 뒷받침되어주면 내가 열심히 연습할 경우 좋은 성적을 낼 수도 있습니다. 하지만 감독은 선수들이 따라주지 않으면 제 아무리 혼자 노력을 해도 성과를 낼 수 없습니다.

이는 직장에서도, 학교에서도, 모임에서도 마찬가지입니다.
어느 조직에서건 '신참리더'가 되면, 가장 먼저 부딪치는 벽이 '나 혼자 잘해서는 성과를 낼 수 없다'는 사실입니다. 지금까지와는 너무도 다른 환경인 셈이지요.

내가 노력하는 건 내 스스로 독하게 결심하면 어느정도 가능한 문제지만, 팀원들이 안따라주는 건 도무지 어찌해야할지 막막해 답답하게만 느껴지기도 합니다.

리더로서의 성공 여부는 팀원들의 성과를 어떻게 이끌어 내느냐에 달려있습니다.
그리고 여기에 필요한 자질은 소위 EQ(감성지수)에 속하는 요소들인, 팀원들을 한 방향으로 이끄는 능력, 타인과 협조해서 일을 추진해나가는 능력, 어려움에 처했을 때 스스로의 감정을 제어할 수 있는 능력입니다.

이런 능력은 어느날 갑자기 생길 수 있는 건 아닙니다.
평소에 동료나 선후배들과 부대끼면서 몸으로 배우고, 주변의 '좋은 선배'를 '스승'으로 삼아 따라해보며 노력하는 길 밖에 없을 듯 합니다.


제공 : 코리아인터넷닷컴, a 2004년 04월 16일
저자 : 예병일  
필자 예병일은 미국 주피터 미디어와의 합작법인인 코리아인터넷닷컴 대표와 모바일 분야 기업인 키위소프트 대표를 맡고 있음.

- 서울대 정치학과, 동 대학원을 졸업했으며, 한국과학기술원(KAIST) 테크노경영대학원 최고경영자과정(AIM) 14기를 수료

- SBS(공채 2기) 사회부 기자를 거쳐, 조선일보(공채 32기)에 입사, 경제부 기자로 줄 곳 활동

- 조선일보 경제부에서 정보통신부, 재정경제부, 금융감독위원회, 공정거래위원회, 산업자원부, 농림부 등 경제부처와 한국은행, 증권거래소, 코스닥증권시장, 증권업계 등 금융계, 그리고 정보통신업계, 인터넷업계 등 산업계 전반에 대해 폭 넓게 취재하면서 한국경제를 분석했음


Posted by SB패밀리

[경영/리더십] 팀장과 매니저


팀장과 매니저... 무슨차이가 있을까?



매니저는 "무엇을 행야하는지를 찾는다"


팀장은 "무엇을 할지를 찾는다"






쉽게 구분 짓기가 어렵다.


회사에서 사업 방향이 정해졌다고 할 때


매니저는 사업의 전략을 다각도로 분석하고 구체화하고 마케팅을 한다고 하면


팀장은 사업의 전략에 따른 각 팀별로 맡은 임무에 따라 직접적인 전술을 수행한다고 봐야한다.



즉 조직의 체계에서 부터 매니저 아래에 팀장들이 존재한다.


예를 들어, 프로젝트 매니저가 있다면 거기에는 기획팀장, 설계팀장, 개발팀장, 영업팀장 등으로 구성할 수 있다.

Posted by SB패밀리

내가 알고있는 리더와 관리자의 차이이다.


리더


- 팀원들을 올바른 길로 이끌어 과제를 성공하게 만든다.

- 팀원들이 겪고 있는 난제를 파악하여 해결해준다.

- 모든 일에 솔선수범하여 팀원들이 자신을 보고 배울수 있게 한다.

- 일하는 방식, 일 분배 등에 있어 항시 팀원의 역량 향상을 고려한다.

- 가능한 일정과 그 이유를 개발자에게 묻고, 더 빨리/효율적으로 끝낼 수 있는 방법이 있을지 함께 상의한다.



관리자


- 과제를 성공시키기 위해 팀원들을 조직/관리한다.

- 팀원들에게 일을 분배하고 해결토록 한다.

- 관리자가 하는 일과 팀원이 하는 일을 구분짓는다.

- 필요한 일에 가장 적합한 역량을 보유한 팀원에게 해당 일을 맡긴다.

  (개인의 역량 향상은 개인의 몫이다.)

- 촉박한 일정을 주고 기간내에 끝내라고 압박한다.




알고는 있지만.. 난 아직 멀었다고 생각한다. 리더가 되기에는 ...

Posted by SB패밀리
팀장과 매니저... 무슨차이가 있을까?

매니저는 "무엇을 행야하는지를 찾는다"
팀장은 "무엇을 할지를 찾는다"

쉽게 구분 짓기가 어렵다.
회사에서 사업 방향이 정해졌다고 할 때
매니저는 사업의 전략을 다각도로 분석하고 구체화하고 마케팅을 한다고 하면
팀장은 사업의 전략에 따른 각 팀별로 맡은 임무에 따라 직접적인 전술을 수행한다고 봐야한다.

즉 조직의 체계에서 부터 매니저 아래에 팀장들이 존재한다.
예를 들어, 프로젝트 매니저가 있다면 거기에는 기획팀장, 설계팀장, 개발팀장, 영업팀장 등으로 구성할 수 있다.
Posted by SB패밀리

인터넷에서 퍼온글 출처 미상

[펌]대한민국 IT에는 미래가 없다. 그런데 난 즐겁다.

 

사회에 존재하는 이런저런 산업를 크게 둘로 나누어보면 이렇게 나뉜다.

 

1. 제로섬 산업.

2. 논제로섬 산업.

 

제로섬 사업은 간단히 증권시장을 연상하면 된다. 누군가 웃는다면 누군가는 우는 체제이다. 새로운 부가가치를 생산해 판매하는 산업이 아니라 기존의 부가가치를 운용해 더 많은 부가가치를 자신에게 이동시키는 산업이다. 때문에 이 산업의 종사자는 아무리 돈을 많이 벌어도 국가의 부에는 영향을 주지 않는다. 상자안의 빵이 옮겨다닐뿐 빵 자체를 만들어내지는 못하는 것이다.

 

논제로섬 산업은 반대이다. 이 산업의 목표는 새로운 부가가치를 창출하거나 생산해 그것을 판매하여 이익을 보는 것이다. 이 업계 종사자의 부는 곧 국가의 부다. 논제로섬 산업이 발달하면 그것은 곧 국가의 부로 연결된다. 흔히 말하는 IT업계가 바로 이쪽이다. 언론에서 툭하면 '대한민국의 미래는 IT에 있다'라고 하는 것도 다 이런 이유에서이다.

 

그런데 생각해 보자. 대한민국에서 우대받는 직업에는 어떤 것이 있을까? 주로 끝에 '사'가 붙는 의사, 약사, 변호사, 판사, 회계사, 변리사 등등은 물론 딜러, 펀드매니저 등의 금융이나 대기업의 간부, 전문직 정도일 것이다. 여기서 찾아보자. 이중에 제로섬 직업은 몇이고 논제로섬 직업은 몇일까?

 

대한민국의 일그러진 엘리트 주의에서는 논제로섬 직업은 대우받지 못한다.

 

관념적인 말이 아니다. 내 주위의 일이다. 흔히 말하는 그 잘난 일류대의 공학, 과학인들이 과연 얼마나 논제로섬 직업에 종사하고 있을것 같은가? 명색이 대한민국에서 제일 우수한 IT교육을 받은 인재들이 죄다 제로섬 게임에 미쳐(혹은 떠밀려) 아무생각없이 달려가고 있다.

 

서울대 공대 나와 대기업에 입사하면 실무로 뭘하는지 아나? 전화받는다. AS부서에서. 대기업 기술개발 관련은 해외파가 아니면 명함도 못내밀고 실무생산은 눈높은 신입사원들이 기피한다. 지금 대한민국 IT가 대단하다 떠들고 있지만 실제 업계 종사자들은 다 안다. 현재의 강세는 대한민국의 지식적 힘이 아닌 해외의 힘이며 대한민국의 자본이 아닌 해외 자본의 이익이다. 그나마도 위험하다는 사실을 말이다.

 

알기쉽게 예를 들어보자. 가장 IT스러운 프로그래머의 세계를 까발려본다.

 

대한민국 프로그래머중 40 넘어서까지 현역(코딩활동)을 유지하는 사람이 얼마나 될 것 같은가? 거의 제로라 보면 된다. 일반적인 업계에서는 보통 40을 업무의 전성기라고 한다. 경험과 패기와 능력이 조화를 이룬 시기라는 말이다. 그런데 대한민국의 프로그래머들은 모두 40 이전에 어떻게 해서는 발을 빼려 아우성친다. 아니면 해외로 나가든가. 도대체 왜그럴까.

 

프로그래머는 전문직이다. 그런데 대우는 단순노무직 대우를 받는다. 하루 10시간 근무, 주 6일출근하는 2년차 프로그래머 연봉이 얼마일것 같나? 업계에 따라 조금씩 다른데 가장 열악하다는 게임업계를 들자면 보통 연봉 2000이 안된다. 1800~2000사이를 넘나든다. 세칭 대기업 생산직 근로자들의 딱 반이다.

 

문제는 인센티브다. 실리콘밸리에서는 뛰어난 아이디어와 실력으로 좋은 소프트웨어를 개발해 부자가 된 프로그래머들이 널리고 널렸다. 거기가면 50대 프로그래머들도 발에 채인다. 왜냐고? 부자가 될 기회가 많으니까.

 

그런대 한국은 웃기게도 대박이 나오면 그 열매는 경영진들이 다 가져간다. 개발직 중에서는 기획자만이 그 단맛을 볼 뿐, 그래픽이나 프로그래밍 파트는 손가락만 빨고 있어야 한다. 인센티브? 허황된 꿈이다. 한국에서는.

 

해외 프로그래머들과 이야기를 해보면 그쪽에서는 이런 한국의 IT문화를 신기하게 여기는 분위기다. 어느 업계에서건, 어느 분야에서건 스타는 있다. 그 스타의 모습을 통해 신입들은 의욕을 다지게 되는데... 생각해보라. 한국에 스타 프로그래머가 있는가? 유일(말 그대로 유일)한 이름이 안철수다. 그러나 그분도 얼마전 부패청산 어쩌고 협의에 맞아 쓴소리를 남기셨다. 얼마나 한스러우시면 그럴까. 명색이 IT강국이라는 대한민국, 그중에서도 가장 IT스러운 프로그램 분야에서 한국은 스타가 없다. 즉 새로 업계에 발을 붙히는 사람들이 꿈을 둘 곳이 없는 것이다. 전문지식과 실력과 막중한 근무는 요구하면서도 그 결과를 돌려주는데는 인색하다. 이것이 바로 현실이다.

 

대한민국에서 실제 기술개발하고 코딩하는 사람들중 과연 세칭 일류대 출신이라 하는 사람들은 거의 없다. 대기업 연구소라면 모를까. 그 외는 전멸에 가깝다. 엘리트라 자부하는 사람들은 대부분 '사'자가 붙는 직업이나 대기업으로 가 실무와 관계없는 관리쪽에 들어간다. 물론 학력이 실력과 정비례하는 것은 아니지만 일반적인 기준에 맞추어 생각한다면 참으로 암울한 현실이 아닐 수 없다. 이는 모든 IT 산업의 전반적인 특징이다. 실무진은 업계의 허리다. 그런데 그 허리가 너무나 부실하다는 점이 문제다. 대한민국은 모래위에 남의 돈 빌려 대궐같은 IT집을 지어놓고 '나좀봐라' 떵떵거리는 모습이다. 웃음이 절로 나온다.

 

지금이야 몇몇 대기업의 약진이라는 화려한 포장지가 있지만 이것이 과연 얼마나 갈까. 그 대기업의 약진도 따지고 보면 해외의 기술력과 자본에 반이상 종속된 상태이다. 눈가리고 아웅하는 꼴이다. 그런데 어떻게든 경영진과 정치인들은 이것을 자신의 치적으로 삼고자 취약점은 외면한채 과대포장시켜 홍보하기에만 들떠 있다.

더불어 대기업의 횡포도 끝이 없다. 이미 대기업 노조의 밥벌이를 하청업체가 책임진다는 사실은 공공연한 사실이다. 더불어 하청업체의 영업이익이 조금이라도 우수하면 바로 대기업의 감찰단이 들이닥친다는 사실도 안철수님의 인터뷰로 까발려졌다. 중소업체가 대기업에 제안서 하나 넣어볼라치면 전 사원의 학력, 경력등은 기본적으로 첨부해야 한다. 해외에서는 웃기는 비상식이 대한민국에선 상식으로 통한다. 가장 국제화되었다는 IT업계에서 말이다.

 

얼마안가 망할 것이다. 거품이 빠지고 그나마 버텨주던 기술개발인들이 못보티고 은퇴하는 순간이 대한민국의 IT가 끝장나는 순간이다. 정부와 기업들도 한몫하기로 했다. 그나마 경쟁력의 근원중 하나이던 인터넷을 종량제로 바꾼다고 하니 않는가. 정보와 이익의 독점이 미덕이라는 제로섬 산업의 마인드가 이제 논제로섬 산업을 뒤흔들고 있다.

 

솔직히, 나는 즐겁다. 업계의 인력부족이 심각해지고 질적, 양적인 공백이 심화될수록 나는 즐겁다. 세칭 일류대 공대 나와 동기들과는 달리 돈키호테처럼 벤처로 뛰어들때만 해도 상황이 이럴줄은 상상도 못했으니까. 물론 일하기 시작한 몇개월간은 그 암울함에 어려워했지만 지금 생각해보면 오히려 좋은 기회라고 느껴진다. 의욕이 현실앞에 무너지나 걱정도 했지만 점점 늘어나는 스카웃 제의에 근심은 사라졌다. 어디든 그렇지만 희소성은 늘 각광받기 마련이니까.

 

대한민국의 영재들이여, 부디 나를 위해 계속 IT를 기피하고 경영이나 '사'자로 가주시길

Posted by SB패밀리

출처 : http://www.phpschool.com/bbs2/inc_view.html?id=13732&code=phorum2&start=&mode=&s_que=&field=&operator=&period=

리사아빠입니다.

 프로그램이란것은 컴퓨터가 알아 먹는 말로 일을 하게끔 하는 것에 불과 하다는 생각이 듭니다. 그러기 위해서 알고리즘이나 자료구조나 언어라든지 한는 부수적인 지식들이 필요한 것이구요.

저는 인문계열 출신인데도 요즈음에는 프로그램을 할때 인문계열에서 공부를 한 것이 더 도움을 줄때가 많이 있습니다. 거의가 응용이지만 프로그램 언어를 공부할때도 알고리즘도 인문교양지식이 많은 도움을 줍니다. 대부분 사람들이 하면 할 수록 프로그램이 어렵다고 하는 것은 자신의 기본지식을 응용하는데에 한계점에 다달해서뚜렸한 실마리를 찿지 못해서 그렇다고 생각을 합니다. 저의 경우 인간의 언어에 대해서는 어느 정도 자신이 있는데 이 언어를 가지고 설명을 해 보겠습니다.


저는 스페인어 프랑스어 둑일어 그리고 중국어는 보면 대충 이해를 하고 영어와 일본어는 모국어 가깝게 구사를 하는 편입니다. 그런데 이렇게 할 수 있었던 배경이 일본어를 모국어처럼 사용을 하게 되면서 자연스럽게 다른 언어를 쉽게 쉽득하는 습관이나 사고가 몸에 베어서 다른 언어를 쉽게 습득한 것에 불과 하다고 생각을 합니다.

그런데 일본어를 배울때 제가 가장 어렵게 느껴젔던 것이 일본어가 아니라 모국어인 한국어가 어려웠던 사실입니다. 모든 언어의 기본이 되는 국어 실력이 없었던 것이지요. 한국에서는 고등학교밖에 나오지 못해서 언어라는 기본 개념도 없었던 것입니다.

그리고 언어라는 것은 한 언어의 단어를 많이 안다고 잘하는 것도 아니고 정치 경제 사회 문화등 각분야별로 어느 정도의 지식도 필요하기 때문에 단지 한국말이 모국어라고 해서 다들 한국말을 잘한다는 것도 아니라는 사실을 알게 되었지요.

그래서 제가 일본어를 배우는데 가장 먼저 착수한 것이 어떠한 언어라도 각분야의 지식이 필요하다는 생각에서 일본의 정치 경제 사회등 각분야의 책과 논문이나 사설등을 읽기 시작했습니다. 이해가 되지 않으면 그에 관련된 서적을 읽으면서 참고도 하였습니다.

그러면서 언어에는 각 단어마다 뚜렸한 개념이 라는 것이 있고 그 개념에는 학문일 경우에는 그 학설을 주장하는 학자가 각 용어에 대한 정의를 뚜렸하게 제시하고 있다는 것을 깨닫게 되고 사전을 보는 습관이 생기게 되었습니다. 이러한 언어를 정확하게 개념적인 측면에서 일반 생활과 밀접한 부분을 가장 잘 정리해놓은 것이 육법전서라는 것도 알게 되었지요.

한치의 불필요한 말도 없고 더 보탤 말도 없을 정도로 완벽하리 만큼 논리적이면서 정확한 언어로 구사되어 있음을 알았습니다. 그래서 대학에서는 법에 관한 과목과 신학 철학 심리학등 학문의 기본이 되는 과목을 많이 선택해서 들었습니다. 그리고 제일 외국어를 프랑스어를 선택하고 영어는 영어로 강의하는 과목만을 수강을 했습니다.

이러면서 어느 순간에 일본어나 영어로 습득된 지식이 한국어로 습득된 지식의 양을 초월하게 되었지요. 그러나 역으로 이러한 지식들로 인해 언어에 대한 뚜렸한 개념이 몸에 베어 한국어로 된 전문서적이나 소설을 대할때에 한층더 모국어인 한국어에 대한 이해력과 국어 실력이 늘었다는 것을 경험을 하게 되었습니다. 그리고 고등학교때에 미분과 적분 그리고 백터에 대한 개념과 왜 그러한 이론이 필요한것인가에 대해서 수학 선생님한테 물었다가 되지게 욕만 먹고 건방지다면서 가르쳐준 대로 하면 문제를 풀 수 있는데 말이 많다고 많은 친구들 앞에서 꾸지람을 당한 적이 있었습니다.

그 이후로  수학이라는 과목은 쳐다 보기도 싫었고 항상 꼴지에서 뱅뱅돌아 선생님한테 넌 가르쳐주는 것도 모르면서 말이 많다고 줄업할때까지 욕을 먹었던 기억이 있습니다. 한 마디로 교육의 폭행을 당한 것이죠. 그러나 대학에서 심리학이란 과목을 들었을때 거의가 확율과 수학의 이론에의해 가설을 입증하고 하나의 이론으로 정립되 가는 것을 보고 너무 어려워서 그 담당 교수에게 부탁을 해서 따로 필요한 수학 지도를 받았는데 너무나도 이론과 개념에 대해서 상세하게 가르쳐 주어서 2시간 만에 미분과 적분 확율 그리고 백터까지 정확하게 개념적으로 이해를 할 수 있었던 경험도 있습니다. 경제 경영 마케팅이란 과목도 거의 수학이었는데 심리학과 그 교수 덕분에 쉽게 점수를 딸 수 있었습니다.

위의 과목에서 제가 한국어로라도 수학적인 기본지식이 있었다면 따로 교수에게 부탁을 하지 않고도 수월하게 그 과목을 이해를 할 수 있었을 겁니다.
이러하듯이 언어란 것은 일반적인 사회생활이나 전문적인 분야에서도 관련지식이 따라 주어야 진정한 언어로서의 실력이 느는 것입니다. 영어나 일어를 대학에서 전공한다고 해서그 사람이 그 언어를 아주 잘 한다고 할 수 없는 것도 이러한 이유때문입니다. 한국에서 대학을 다녀 보지 못해서 모르지만 영어를 전공하면 문학을 하는 사람도 있을테고 영어의 문법을 학문적으로 하는 사람도 있을 겁니다. 그러나 이런 전공을 하는 사람들도 학문적으로 연구를 하기 위해서는 자신이 연구하는 분야에서 자신의 가설을 증명하기 위해서는 영어라고 하더라도 모든 학문에서처럼 그 검증 방법이 대부분이 같다는 것입니다.
예를 들어 자연 인류학에서 여기 저기에서 발굴되는 뼈와 유적들을 가지고 체계있게 정리를 하고 그것에서 얻어진 자료들을 바탕으로 이러이러했을 것이라는 것을 가설을 세우고 그것을 과학적으로 입증한 것이 학설입니다. 그리고 그 학설이 많은 학자들로부터 인정을 받고 의심의 여지가 없고 권위가 있으면 우리들은 역사책에서 그것을 줄쳐 가면서 외우고 입시에도 시험문제로 나오고 하는 것입니다. 자료를 정리하는 예를 하나 설명하자면 여러 유물들이 출토 되었을 때 그 자료들을 하나의 자료에 대해서 하나의 카드에다 기록을 합니다. 그리고 카드를 섞어서 자료들이 완전히 무의미하고 아무 관련성이 없는 상태로 합니다. 이것은 자신의 선입관이나 몸에 베어있는 지식에 영향을 받지 않게 하기 위해서입니다. 그리고 여러 사람들이 모여서 카드 한장 한장을 책상위에 같은 부류라고 생각되는 것을 직감적으로 같은 곳으로 모아 둡니다. 그러면 자료들이 정리가 되고 그자료들의 연관성이 보이고 다시 분류를 하고 하는 과정을 되풀이하다 보면 일관된 규칙들이 발견됩니다. 그리고 이 규칙들을 기본으로 재 정리하고 과학적인 방법으로 입증해 사람들이 알아 보게 언어로 설명을 하면 그것이 학설입니다. 학문이라고 어려운 것은 아닙니다.
이러한 기본적인 과학적인 입증방법으로 정리해서 글을 쓰면 그것이 학문이 되는 것이지요. 언어도 마찬가지로 하나의 언어를 아주 잘 구사할 수 있으면 언어의 공통적인 개념들이--과학적인 입증방법이 모든 학문에서 거의 동일 하듯이--비슷하기 때문에 다른 언어도 쉽게 익힐 수 있는 것입니다. 제 경험으로 6개월이면 하나의 언어를 어느정도 마스터할 수 있으리라는 생각을 합니다.
가끔 영어는 어떻게 공부하면 되요 라는 글을 대하는데 가장 좋은 방법은 그냥 소설책 하나 사다가 다 외워 버리면 됩니다. 그리고 그것을 바탕으로 다른 책들을 계속 읽어 나가다 보면 저절로 실력이 늡니다. 영어를 하기 위해서 공부하지 말고 필요한 지식을 영어로 습득하기 위해서 책을 보아야지 항상 줄쳐 가며 이놈 영어 배워야지 정복해야지 하다보면 죽을 때까지 영어만 공부하다가 끝입다. 회화를 하고 싶으면 어느정도 이러한 실력을 키우고 현지에 가서 더도 말고 6개월 정도만 살다 오면 귀가 트이고 왠만한 것은 다하게 됩니다. 이것은 언에에 대해서 저의 경험담을 쓴 것입니다. 그럼 프로그램의 경우는 어떠할까요?


프로그램을 하기 위해서는 적어도 하나의 컴퓨터 언어를 습득해야합니다. 많은 사람들이 컴퓨터 언어를 배우다가 프로그래머의 일을 마치거나 어느 정도 하다가 관리자가 되어 프로그래머의 길을 떠나는 사람들도 있습니다. 또는 중도하차하는 사람들도 많구요.
프로그램 언어도 인간의 언어와 마찬가지로 국어 하나만 잘하고 언어의 개념만 확실히 정립해 놓으면 새로운 다른 언어를 쉽게 배우고 새 문화에 대해서 바로 익숙해 질 수 있는 것처럼 새 언어와 기술이 나오더라도 별 큰 의미는 없는 것입니다. 0과1의 세계는 다름이 없기 때문입니다.

언어는 타인과 의사소통을 위한 수단이고 컴퓨터 언어는 컴퓨터가 알아 먹고 일을 하게끔하는 수단에 불과합니다. 만약 양자 컴퓨터가 실용화되어 0과1의 중간의 개념도 배워야 하는 시대가 온다면 지금까지 배워온 모든 것을 버리고 개념부터 다시 배워야 하겠지만요.

가끔 이 포럼란에 그러한 언어에 대한 글이 올 때마다 왜 그러한 언어에다가 목적을 두고 살아가야 하는 것인가에 대한 의문을 가지게 됩니다. 그것은 회사에서 채용을 할때 이러 이러한 언어가 할 수 있어야 하고 경험은 몇년이고 하는 채용 풍토나 기준으로 인해 학원이나 전문대등에서 언어 습득에 목적을 두는 교육을 받은 사람들이 많았기 때문이라고 제 나름대로 분석을 하고 있습니다. 그리고 2,3년에 모든 컴퓨터 이론을 가르친다는 것도 불가능하구요.

사실 하나의 소프트 엔지니어다운 엔지니어를 한명을 배출해 내려면 미국이나 일본의 커리쿨럼으로 7년이라는 과정이 필요합니다. 동경대의 한 교수가 소프트 공학 커리쿨럼에 대한 연구 논문이 책으로 나와서 한번 읽어본 기억이 있습니다. 이 논문에서는 경영과 일반 인문교양도 많이 포함되어 있고 실질적으로 인턴과정을 포함하면 10년이 필요하다고 주장합니다.
2년 3년으로 한가닥 한다는 것은 택도 없는 소리입니다. 저역시 프로그램은 오래하고 있지만 많이 부족하고 아직도 공부를 계속하고 있습니다. 저는 공부를 할때에 주로 일반 미국의 공과대학에서 커리큘럼 과목으로 지정되어 있는 것들을 10년 계획으로 조금씩 공부를 하고 있습니다. 지금은 컴파일 이론을 실질적인 프로그램 소스와 서적으로 공부하고 있습니다. 제가 머리가 나빠서 아마 2년 정도 걸리리라고 생각을 합니다. 자료구조나 이러한 것은 도서관학에 관한 서적을 주로 많이 봅니다. 현재 프로그래머로 일하는 대부분의 사람들이 회사에 다니면서 일을 하기 때문에 일하는데 바빠서 다른 공부를 할 기회도 없을 것이라는 생각을 합니다.
그리고 현재에 알고 있는 몇개의 언어 지식을 최대한 우려먹고 우려먹고 해서 더짜도 궁물도 제대로 안나오는 상황에 처한 분들도 많이 있을 겁니다. 응용이니 하는 것들은 상상도 할 수 없는 상황도 많을 거구요. 그러다 새로운 무슨 NET니 뭐니 하는 것이 나오면 저것도 해야지 밥줄 끊기지 않겠구나 하는 위기감에 처해 지거나 불안해 하고 힘들어서 더이상 프로그램일 못해 먹겠다 하고 생각하는 사람도 많이 있을 겁니다.
하나의 컴퓨터언어에 대해서 정확하게 프로그램소스를 이해하고 진정한 프로라고 말을 할 수 있을 정도의 실력이 되려면 PHP와 같은 스크립 언어라고 해도 제 생각으로는 주변 지식들을 포함하면 적어도 4년은 걸릴거라는 생각이 듭니다. 제가 머리가 나빠서 그렇게 걸리고 머리 좋은 천재는 1년 이내에도 해 내겠죠. 일본어의 경우는 제가 어느정도 실력을 가추었다고 생각을 한것이 항상 사용하면서도10년째가 되었을 때입니다.
영어도 그랬구요. 그래도 부족하다고 생각이 들어 지금도 시간이 있으면 서점에 가서 책을 사다가 분야를 가리지 않고 읽고 있습니다.
다른 언어를 6개월만에 어느정도 할 수 있다고 말한 것은 이러한 한 언어의 기본이 있기 때문에 필요성이 느껴진다면 6개월 정도 집중적으로 한다면 어느 정도는 할 수 있다고 말한 것에 불과합니다. 그리고 어느 정도 프로그래머로 일해서 팀장이나 해서 프로그램일을 때려 치우고 싶다는 생각을 가진 사람도 많으리라고 생각을 합니다. 그러면 컴퓨터 소프트 공학의 입문도 마치지 않은 영원한 초보로 남을 것이고 그러한 초보 밑에서 일하는 사람 역시 똑같은 초보의 길로 유도를 하리라고 생각을 합니다.
요즈음 서울 대학이나 여러 대학의 전삭학과 연구실 사이트를 들락 거리고 있습니다. 그러면서 전산학 계열의 대학을 나온 다고하더라도 연구 분야의 내용이나 커리큘럼의 과목이나 수준을 보면 역시 대학을 나와도 소프트 엔지니어 차원에서는 아주 초보라는 생각이 많이 들게 됩니다. 그런 고급 인재들은 회사에 취직하면 대부분이 어느정도 하다 실력이 막 늘고 어느 정도 실력자가 되려고 할때 그들은 전부 관리직으로 가게 되고 또 다시 그들 밑에는 초보자들이 들끊는 회사로 전락을 하게 되는 것을 되풀이 하는 것이 아닌가하는 마음이 듭니다. 이러한 것은 일본의 미즈호 은행과 같은 참사를 낼 소재들을 만들어 가는 것이라고 생각을 합니다. 일본도 어느 프로그램 일을 하면 관리직으로 일을 하는 것은 마찬가지 입니다. 제가 일본에서 취업 활동을 하면 거의 대부분의 회사가 관리직으로 와달라고 합니다. 연봉은 800만엔 이상 주겠다고들 합니다. 저는 연봉이 그 반 값이라도 프로그래머로 일하고 싶다고 해도 그런 자리는 제가 만 35살이라는 이유로 프로그래머로서는 회사측에서 고용을 할 수 없다고 합니다. 저는 그러면서 일본도 이제는 맛이 갔구만, 이대로 10년 정도만 흐르면 일본의 시스템도 빵꾸가 나겠구만, 미즈호 은행사건이 있었으면서도 회사들이 아직도 정신을 차리지 못했구나 하는 생각으로 프리랜서로서의 길을 고집하고 있습니다. 프로그래머로 오래 남으려면...? 이 아니라 저는 오래 해야만 된다는 생각을 하는 사람입니다. 그렇지 않으면 언제까지나 한국은 미국 소프트의 최대 소비국으로 남을 것이고 매번 새로운 언어나 개발툴이 나올때마다 테스트 시장으로 전락을 하게 되리라고 생각을 합니다. 그리고 PHP는 훌륭한 언어입니다. 펄도 그렇구요. 다들 쓸모가 있기에 있는 언어이고 하나라도 잘 하면 다른 것들도 다 잘 하게 되고 어렵지 않습니다. 만약에 다른 언어가 필요하다면 구현하기 위한 필요한 부분만 하면 되는 것입니다. 많은 프로그래머들이 먼저 현시점에서 자신이 가장 자신이 있는 하나의 언어를 정말로 프로라고 자신할 만큼 해놓고서 다른 언어에 대해서도 이야기를 해주었으면 하는 바램입니다. PHP 2,3년 하고 게시판떼기 일주일만에 만들었다고 하는 것은 소프트 엔지니어 세계에서는 의미가 없는 일입니다.

게시판도 제대로 만들면 저는 3년은 걸리리라고 생각하고 있고 실제로 제가 하나 만들고 있는 게시판은 펄로 5년째 작업을 하고 있는 것도 있습니다. 처음 이곳에 와서 그러한 이야기들을 읽고 다들 대단하구나. 정말로 나라는 인간은 돌대가리구나 하는 생각도 가져도 보고 얼마나 잘 만들었나하고 다운로드해서 설치해도 제법 잘 돌아가고 해서 다들 천재들만 이곳에 오는 구나하고 한때에 감탄도 하고 그랬습니다. 몇개의 개시판 소스를 면밀히 분석해 보고 타이핑 속도까지 계산을 해서 일주일 만에 가능 한가를 조사해 보기도 했지요. 설계부터 완전하게 새롭게 만든다면 대부분이 뻥이고 만들어 놓은 것 같다 붙이면 하루 라도 만들 수도 있고 그렇다는 생각을 하게 되었습니다. 일주일 만에 만들었다고 해서 저는 모두 새롭게 만들었을 때를 기준으로 생각을 했었지요. 저야 회사다니면서 일을 하는 것이 아니라 완전히 개인 플레이라서 다른 사람이 어떻게 프로그램을 하고 회사에서는 어떻게 일을 하는 지도 모릅니다. 제가 이렇게 혼자서 일을 하는 것은 회사에서 나와같은 사람을 유용하게 활용할 수 있는 그런 회사가 거의 없기 때문입니다. 그리고 저는 죽는 그날까지도 프로그램을 할 생각입니다. 그렇게 해도 모자라고 모르는 것이 많이 남아 있으리라고 생각을 하고 있습니다.

 

정말로 프로그래머 다운 프로그램을 하고 싶으면 배워야 하는 것이 끝이 없습니다. 저는 프로그램때문에 대학에서 졸업한 사회인에게 공개하는 강좌 중에 증권 투자분석 과목을 들은 적도 있습니다. 그 밖에도 많이 있습니다. 언어 하나만 달랑 배워서 프로그램을 한다는 자체가 문제가 있는 것이라고 생각을 합니다. 한때 데이터 베이스와 파일 시스템을 연구 할때에 일본 국회 도서관에 가서 어떻게 책이 대출되고 어떠한 방법으로 그많은 책들을 관리 하는가 하느 것들을 조사한 적도 있습니다. 이러한 경험들은 운영시스템의 파일 시스템을 설계하는 데에 많은 도움을 준 부분입니다. 알고리즘과 같은 것은 이러한 여러 경험과 지식에서 힌트를 얻습니다. 어느정도 하나의 컴퓨터 언어를 하게되면 응용력과 여러 지식들이 결합되어 하나의 소프트를 창출해 내는 것이라고 생각을 합니다. 많은 사람들이 C언어를 해야 됩니까라고 질문을 하는데 그이전에 어떠한 것을 만들고 싶다라는 것이 선제 되어야 합니다. 저의 경우 스피드가 빠르고 사이즈가 작은 운영체계를 하나 만들고 싶다라고 하여 어셈블러를 선택한 것입니다. 사실 C언어로 해도 상관은 없습니다.

그러나  C언어로는 링커로 링크를 할때 불필요한 데이터들이 많이 들어 가고 아무리 사이즈를 최적화 해도 어셈블러의 스피드와 사이즈에서 따라 잡을 수가 없습니다. 언어는 하다보면 언젠가는 자연스럽게 수준이 높아지고 잘 할 수 있습니다. 그러나 그언어로 구사하는 프로그램은 언어를 잘하는 것만으로는 잘 할 수 없는 것이라고 생각을 합니다. 위에서 말한 인간의 언어에서와 마찬가지로 다방면의 지식과 경험이 훌륭한 프로그램을 만들 수 있는  것이라고 생각을 합니다. 하나의 소설을 쓰자면 언어는 물론 그 소설에 등장한는 모든 인물의 직업에 관해서도 그인물이 회사에서 어떠한 일을 하는지도 일반 회사에서의 인간관계 하다 못해 점심시간에는 어떤 메뉴를 잘먹는다라는 사소한것도 잘 알아야 하니까요.
프로그램도 이와 마찬가지라고 생각을 합니다. 제가 현재 OS를 같이 개발을 하고 있는 핵심 멤버들의 프로그래머 경력이 최소 10년 이상입니다. 물론 이들 모두 자신들은 초보라고 합니다. 저 역시 프로그램을 처음 맛 본 것이 10여년 전입니다. 저도 아직 초보입니다. 

Posted by SB패밀리

1. 자신의 기술(cratf)에 관심과 애정을 가져라.
 : 소프트웨어 개발을 잘 해보려는 생각이 없다면 왜 인생을 그 일을 하면서 보내는가?

2. 자신의 일에 대해 생각하면서 일하라!
 : 자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라.

3. 어설픈 변명을 만들지 말고 대안을 제시하라.
 : 변병하는 대신 대안을 제시하라. 그 일은 할 수 없다고 말하지 말고, 무엇을 할 수 있는지
   에 대해 설명하라.

 4. 깨진 창문을 내버려두지 말라.
 : 눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.

 5. 변화의 촉매가 되라.
 : 사람들에게 변화를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라.

 6. 큰 그림을 기억하라.
 : 주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.

 7. 품질을 요구사항으로 만들어라.
 : 프로젝트의 진짜 품질 요구사항을 결정하는 자리에 사용자를 참여시켜라.

 8. 지식 포트폴리오에 주기적으로 투자하라.
 : 학습을 습관으로 만들어라.

 9. 읽고 듣는 것을 비판적으로 분석하라.
 : 벤더, 매체들의 야단법석, 도그마에 흔들리지 말라.

   여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.

 10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
 : 효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.

 11. DRY - 반복하지 마라(Don't Repeat Yourself)
 : 어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 귄위 있고, 단 하나뿐인 표현을 가져야 한다.

 12. 재사용하기 쉽게 만들라.
 : 재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.

 13. 관련 없는 것들 간에 서로 영향이 없도록 하라.
 : 컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.

 14. 최종 결정이란 없다.
 : 돌에 새겨진 것처럼 불변하는 결정은 없다.
   그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.

 15. 목표물을 찾기 위해 예광탄을 써라.
 : 예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다.

 16. 프로토타입을 통해 학습하라.
 : 프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고,
   여러분이 배운 교훈에 있다.

 17. 문제 도메인에 가깝게 프로그래밍하라.
 : 사용자의 언어를 사용해서 설계와 코딩을 하라.


18. 추정을 통해 놀람을 피하라.
 : 시작하기 전에 추정부터 하라. 잠재적인 문 제점들을 미리 찾아내게 될 것이다.

 19. 코드와 함께 일정도 반복하며 조정하라.
 : 구현하면서 얻는 경험을 이용해서 프로젝트의 시간 척도를 세밀히 조정하라.

 20. 지식을 일반 텍스트로 저장하라.

 : 일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다.

   일반 텍스트 형식은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는 데 도움이 된다.

 21. 명령어 셸의 힘을 사용하라.
 : 그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.

 22. 하나의 에디터를 잘 사용하라.
 : 에디터를 마치 손의 연장으로 자유자재로 다루어야 한다.

   여러분이 사용하는 에디터는 설정를 바꿀 수 있고, 확장가능하고, 프로그램 가능해야 한다.

 23. 언제나 소스코드 관리 시스템을 사용하라.
 : 소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.

 24. 비난 대신 문제를 해결하라.
 : 버그가 여려분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다.

   그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.

 25. 디버깅을 할 때 당황하지 마라.
 : 숨을 깊게 들이 쉬고, 무엇이 버그를 일으키는지 '생각하라!'

 26. 'select'는 망가지지 않았다.
 : OS나 컴파일어의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리 일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장  크다.

 27. 가정하지 마라. 증명하라.
 : 진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.

 28. 텍스트 처리 언어를 하나 익혀라.
 : 여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터
   가 그 일의 일부를 하게끔 만들지 않는가?

 29. 코드를 작성하는 코드를 작성하라.
 : 코드 생성기는 생산성을 증가시키며 중복을 막는 일에도 도움이 된다.  

 30. 완벽한 소프트웨어는 만들 수 없다.
 : 소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자
   들을 보호하라.

 31. 계약에 따른 설계를 하라.
 : 코드가 실제로 하기로 한 것을 문서화하고 검증하기 위해 계약을 사용해라.

 32. 일찍 작동을 멈추게 하라.
 : 보통은 죽은 프로그램이 절름발이 프로그램 보다 해를 훨씬 덜 끼친다.

 33. 단정문을 사용해서 불가능한 상황을 예방하라.
 :  단정은 여러분이 세운 가정을 검증해준다.
    확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라.

 34. 예외는 예외적인 문제에 사용하라.
 : 예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.

 35. 시작한 것은 끝내라.
 : 가능하다면, 리소스를 할당한 루틴이나 객 체가 해제도 책임져야 한다.

 36. 모듈간의 결합도를 최소화하라.
 : 디미터 법칙을 적용하고 '부끄럼 타는(shy)' 코드를 작성해서 결함이 생기는 일을 피하라.

 37. 통합하지 말고 설정하라.
 : 애플리케이션에서 기술 선택을 설정 옵션으로 구현하고, 통합하거나 만들어 넣지 말라.

 38. 코드에는 추상화를, 메타데이터에는 세부 내용을.
 : 프로그램은 최대한 일반화해서 만들고, 세부사항들을 가능하면 컴파일된 코드 기반 바깥으로 빼라.

 39. 작업흐름 분석을 통해 동시성을 개선하라.
 : 사용자의 작업흐름이 허용하는 동시성을 최대한 활용하라.

 40. 서비스를 사용해서 설계하라.
 : 서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.

 41. 언제나 동시성을 고려해 설계하라.
 : 동시성이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.

 42. 모델에서 뷰를 분리하라.
 : 애플리케이션을 모델과 뷰의 관점으로 설계 해서 적은 비용만 들이고도 유연함을 얻어 내라.

 43. 칠판을 사용해 작업흐름을 조율하라.
 : 참여하는 요소들의 독립성(independence)과 고립성(isolation)을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.

 44. 우연에 맡기는 프로그래밍을 하지 말라.
 : 정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적 의식을 가지고 만든 계획과 착각하지 말라.

 45. 여러분의 알고리즘의 차수를 추정하라.
 : 코드를 작성하기 전에, 실행 시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.

 46. 여러분의 추정을 테스트하라.
 : 알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다.

   실제 대상 환경에서 코드의 수행 시간을 측정해보라.

 47. 일찍 리팩터링하고, 자주 리팩터링하라.
 : 정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.

 48. 테스트를 염두에 두고 설계하라.
 : 코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.

 49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스하게 될 것이다.
 : 가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.

 50. 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
 : 마법사는 엄청난 양의 코드를 만들 수 있다.
   그것들을 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라.

 51. 요구사항을 수집하지 말고 채굴하라.
 : 요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀 있다.

 52. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
 : 시스템이 정말로 어떻게 사용될 지 통찰력을 얻을 수 있는 가장 좋은 방법이다.

 53. 구체적인 것보다 추상적인 것이 더 오래간다.
 : 구현 말고 추상에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을 수 있다.

 54. 프로젝트 용어사전을 사용하라.
 : 프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.

 55. 생각의 틀을 벗어나지 말고, 틀을 찾아라.
 : 해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라.

   스스로에게 이렇게 물어보라. '정말로 반드시 이런 방식으로 해야 하는 일인가?

   꼭 해야만 하는 일이긴 한 건가?

 56. 준비가 되었을 때 시작하라.
 : 여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.

 57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
 : 명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.

 58. 형식적 방법의 노예가 되지 마라.
 : 여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.

 59. 비싼 도구가 더 좋은 설계를 낳지는 않는다.
 : 벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라.

   도구 자체의 장점만 갖고 판단하라.

 60. 팀을 기능 중심으로 조직하라.
 : 설계자와 코더를, 테스트 담장자와 데이터 모델 담장자를 분리시키지 말라.

   코드를 만드는 방식에 맞춰 팀을 만들어라.

 61. 수작업 절차를 사용하지 말라.
 : 셸 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행 해준다.

 62. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
 : 매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.

 63. 모든 테스트가 통과하기 전에 코딩이 다 된 게 아니다.
 : 뭐 더 할 말 있나?

 64. 파괴자를 써서 테스트를 테스트하라.
 : 코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.

 65. 코드 커버리지보다 상태 커버리지를 테스트하라.
 : 중요한 프로그램 상태들을 파악해서 테스트하라.

   단지 많은 코드 줄 수를 테스트 범위 안에 넣는 것만으로는 충분하지 않다.

 66. 버그는 한 번만 잡아라.
 : 인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만들라.

 67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.
 : 코드를 작성하는 것처럼 문서도 작성하라.
   DRY 원칙을 존중하고, 메타데이터를 사용 하고, MVC 모델을 쓰고, 자동 생성을 이용 하고 등등.

 68. 문서(document)가 애초부터 전체의 일부가 되게하고, 나중에 집어넣으려고 하지 말라.
 : 코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.

 69. 사용자의 기대를 부드럽게 넘어서라.
 : 사용자들이 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.

 70. 자신의 작품에 서명하라.
 : 옛날 장인들은 자신의 작업 결과물에 서명 하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.

 

<출처 : 실용주의 프로그래머>

Posted by SB패밀리

프로그래머를 위한 잠언(aphorism)
 
 
다음은 세상의 지혜, 발라사르 그라시안 지음, 이동진 옮김을 참고하여 프로그래머에 맞추어 재구성한 것입니다. 필자가 추가한 것도 있고 패러프래이즈 한 것도 있습니다. 세상의 지혜 책에는 300가지의 지혜가 있고 해설도 잘 되어 있으므로 프로그래머 여러분들께서 구입해서 한 번쯤 꼭 읽어보시기 바랍니다. 책 가격을 하는 좀처럼 드문 책임에 틀림없다고 생각합니다. 존칭은 편의상 생략합니다. 너그러운 양해를 구합니다.

1. 컴퓨터 프로그래머는 최고의 직업임을 알라.
2. 컴퓨터 프로그래머는 노가다 직업임을 인정하라.
3. 프로그래밍의 성공 열쇠는 자신감이다.
4. 산은 넘어봐야 안다.
5. 산을 넘지 않고 넘어봐야 안다는 말하는 사람들을 가까이 하지 마라.
6. 언제나 진실되게 행동하라.
7. 프로그래밍은 진실의 반영이다.
8. 프로그래밍은 고도의 논리적 사유를 요구한다.
9. 개발툴은 기술적이기보다는 기능적이다.
10. 완전한 프로그램을 만드는 것만큼 자신을 완전하게 만들어라.
11. 컴퓨터를 이해하고 프로그램 구조를 이해하는 것만큼 자신을 알고 이해하라.
12. 팀웍을 위해서 일하라.
13. 팀웍의 활성화를 위해서는 스터디 모임이 효과적이다.
14. 팀 내에서 나서는 사람이 되기보다는 없어서는 안될 사람이 되어라.
15. 프로그래밍 지식이 실체화되려면 용기가 있어야 한다.
16. 소프트웨어 기술과 소질을 잘 살려서 최대한 도로 자신의 능력을 완숙한 경지로 향상시켜라.
17. 팀원들이 당신을 존중하고 신뢰하도록 만들라.
18. 팀장에게 반항하거나 그를 능가하려고 하지 말라.
19. 팀 내에서의 불만을 자기 것으로만 생각하지도 말고 퍼뜨리지 말라.
20. 프로그램 개발 시 발생하는 고통은 누구에게나 있는 것이다.
21. 가능한 한 자신의 결점을 노출시키지 말라.
22. 항상 배우도록 하고 자신에게 멘토가 되어줄 사람을 찾아라.
23. 동료 팀원들을 스승으로 삼아라.
24. 재능은 누구에게나 주어지지만 그 재능이 숙련적인 기술로 발전하기 위해서는 노력이 필요하다.
25. 프로그램 완성을 위해서는 WHY 보다는 HOW가 더 중요하다.
26. 버그를 한 번에 잡으려고 하지마라. 긴장을 갖고 있으되 한편으로는 여유로움을 간직하라.
27. 프로그래밍이란 지성과 감성 그리고 용기와 박력의 결합이다.
28. 자신의 주변에 우수한 인재들이 모이도록 자신을 향상시켜라.
29. 프로그램 개발은 풍부한 기술지식과 풍요로운 마음가짐을 요구한다.
30. 팀 내에서 그리고 회사 내에서 그리고 어디에서든 적을 만들지 말라.
31. 적을 만들지 않기 위해서는 항상 자신을 새롭게 하라.
32. 근면은 프로그래머가 프로그래밍을 하는데 있어서 근간을 이룬다.
33. 자신이 작성한 프로그램에 자부심을 갖되 대단한 기대는 갖지 말라.
34. 직장에서 퇴출될 수 없는 자신만의 노하우를 가져라.
35. 운이 안 좋아도 배움을 늦추지 말라. 운이 안 좋을때 배우는 것이 더 많을 수 있다.
36. 장황한 지식이 아닌 실질적인 지식을 갖추어라.
37. 소프트웨어 기술 지식을 적시 적소에 사용하는 방법을 배워라.
38. 프로그래머는 소프트웨어 개발을 위한 마법사임을 깨달아라.
39. 자신의 결점을 숨기려고 하지 말고 결점을 고치려 하되 안 되면 무시하라. 가능한 한 떳떳하고 당당하게 살아가라.
40. 팀 내에서 다른 팀원의 결함을 찾아내려고 하지 마라.
41. 프로그램 개발에서부터 팀웍에 이르기까지 매사에 긍정적으로 생각하고 행동하라.
42. 사유와 상상은 다르다. 상상할 때와 사유할 때를 구별하라.
43. 팀 내의 전체적인 분위기를 읽을 줄 알아라. 회사가 돌아가는 분위기를 인식하라.
44. 경쟁 프로그래머가 있을 경우 그를 존중하고 그로부터 배우려고 노력하라.
45. 교만하고 자만해 있는 사람이 팀원으로 있다면 자신의 마음에 그러한 요인이나 인자가 없는지 잘 내면을 살펴라.
46. 소프트웨어 프로그래머의 실력은 소프트웨어가 얼마나 성능이 좋은가에 판가름난다.
47. 누구나 할 수 있는 프로그래밍 기술도 갖추되 자신만의 프로그래밍 기술도 갖추어라.
48. 프로그래밍에 대한 자신의 주관을 져버리지 말라. 자신의 철학을 지켜라.
49. 팀원으로부터 인기를 얻으려고 하지 말라.
50. 프로그램 상에 존재할 수 있는 미심쩍은 오류나 버그에 대해서는 즉각 조치를 취하라.
51. 운이 좋은 프로그래머와 실력이 좋은 프로그래머들을 주변에 많이 두어라.
52. 위기에 처했을 때는 마음으로 자신이 선망하는 고수들에게 기도하라.
53. 자신의 기술지식을 팀원에게 베풀거나 그들과 공유하라.
54. 자신의 능력을 20%~30%는 숨겨라.
55. 팀원이나 팀장의 요청을 무조건 받아들이려고 하지 말라. 거절할 줄도 알라.
56. 자신의 기술지식이나 기술소질에 있어서 가장 뛰어난 부분을 더욱 발전시켜라. 자신의 장점을 최대한 발전시켜라.
57. 프로그램의 구조와 설계 전반에 관하여 조용하고 맑은 정신으로 깊이 사유하는 시간을 가져라.
58. 구루나 마스터가 되기 전까지는 프로그래밍을 짜기 전에 3번 생각하고 한 줄의 코드를 작성하는 습관을 가져라.
59. 짠 코드를 다시 고치거나 지우는 것을 아깝게 생각하지 말라.
60. 프로그램이 완전히 완성되기에는 시간이 필요함을 알라. 모든 사사물물은 완성하는 데에는 시간이 요구된다.
61. 자신을 비난하는 자가 3번을 비난하면 두 번은 침묵으로 무시하나 한 번쯤은 진실한 말로 그렇지 않음을 이야기하라.
62. 운이 좋다고 느껴질 때 열심히 일하고 많은 것을 배워라.
63. 팀원들이 자신을 좋아하도록 해라. 팀원에게 친절하고 베풀어라.
64. 모자란 실력에 대해 자신이 실력 있다고 뻥 튀겨 부풀리지 말라.
65. 자신의 능력을 지나치게 믿지 말라.
66. 팀의 흐름을 따르라.
67. 행운이 자신에게 언제 찾아오는지 명리학자에게 자문을 구하라. 그러나 행운보다 노력과 배움이 더 중요함을 인지하라.
68. 원대한 포부와 야망 그리고 비전을 가진 사람이 어떻게 그것을 현실화시키는지를 알라.
69. 프로그래밍 기술지식이 풍부한 사람을 사귀라.
70. 교묘한 프로그래밍 기술 노하우(TIP)를 많이 습득하라.
71. 프로그램의 제어 흐름과 데이터 흐름을 잘 관찰하라.
72. 자신이 작성한 프로그램은 자신의 분신임을 깨달아라.
73. 프로그래밍을 통해서 일상생활에 대한 자신의 논리적 판단력을 증진시켜라.
74. 팀원을 미워하지 말고 자신을 사랑할 줄 알라. 애증을 버려라.
75. 팀 내에서 나서서 무엇을 하려고 하지 말라. 시키지 않은 일을 하지 말라.
76. 팀 내에서 알 수 없는 신비감과 심오함으로 자신을 포장하라.
77. 팀 내에서 자신과 타인의 자존심에 상처를 주지 않도록 주의하라.
78. 논쟁을 삼가되 논쟁을 하게 되면 서로를 존중하는 기반 하에서 논쟁을 하라.
79. 인생은 선택의 연속이다. 올바른 선택을 하라. 그러나 틀린 선택을 해도 후회하지는 마라.
80. 팀 내에서 누군가 자신을 비난해도 당황하거나 화를 내지 마라. 너그러운 마음으로 사태를 분석하고 진지하고 진솔하게 사실을 이야기 하라.
81. 프로그래밍은 빨리 한다고 능사가 아니다. 시간이 해결해 줄 수 있음도 인정할 줄 알라.
82. 진지함과 즐거움을 동시에 갖고 프로그래밍을 하라.
83. 팀 내에서 싸움은 가급적 피해 되 싸움에서 이기되 패배를 통해서 배우는 자세도 길러라.
84. 싸움은 배짱으로 하는 것이지 머리로 하는 것이 아니다. 머리를 텅비우고 배에 힘을 주어라.
85. 팀 내에서 자신을 나약하게 생각하거나 무시하는 사람에게는 자신이 힘이 있고 위엄이 있음을 보여주라.
86. 싸워서 질 경우 참고 견디는 인내의 마음을 길러라.
87. 프로그래밍할때는 항상 주의를 기울여서 실수와 오류가 프로그램 상에 들어가지 않도록 노력하라.
88. 항상 깨어있는 의식 상태로 프로그래밍을 하라.
89. 항상 버그가 언제 어디서든지 발생할 수 있음을 인식하고 있으라.
90. 팀웍을 원활하게 유지하려면 주변의 사람들의 수준과 자신의 수준을 일치시키도록 하라. 나서지도 말고 주눅들지도 말라.
91. 프로그램의 완성도는 바둑처럼 끝내기를 잘하는데 있다.
92. 프로그래밍을 통해서 지식과 지혜를 길러라.
93. 어려운 문제를 해결해 낼 수 있는 실력을 길러라. 소프트웨어 업계에서 장인이라고 호칭되려면 남들이 해결하지 못하는 프로그램 문제를 고칠 수 있어야 한다.
94. 어려운 문제가 발생할 경우 자신이 해결해야만 한다면 그 문제를 우회할 수 있는 길을 모색하라.
95. 자신의 능력을 100%활용해도 안 되면 휴먼 네트워크를 활용하라.
96. 팀 내의 팀원들에게 좋지 못한 소식은 전하지도 말고 들으려고 하지도 말라.
97. 프로그래밍은 판단력을 기르는데 매우 요긴한 도구이다.
98. 소프트웨어 개발은 결과로서 평가 받는다. 결과가 좋으면 과정도 좋은 것이다.
99. 자신만 잘하려고 하지 말고 팀 내의 팀원들이 판단을 잘하도록 도와주라.
100. 프로그램 개발 시에 모든 것을 혼자 다하려고 하지마라. 팀원들과 함께 일하라. 물론 부당한 요구는 거절할 줄 알아라.
Posted by SB패밀리