책도서(3) - 세상을 뒤흔든 프로그래머들의 비밀 - 2015.02.09(월)

- 세상을 뒤흔든 프로그래머들의 비밀 - 2015.02.09(월)

세계 최고의 프로그래머들이 말하는 프로그래머로서의 삶, 생각 그리고 통찰력

개발실에 책장에서 발견하게 된 "대한민국에서 프로그래머로 살아가는 당신을 위한 책"이라는 문구에 호기심이 생기게 되어 읽게 되었습니다. 특히 저의 여러 신념 중 하나인 '과거를 알아야 미래를 대비할 수 있다'라는 점에서 더욱 집중하고 몰입할 수 있었던 책이었고 읽는 내내 저의 가슴을 막 벅 차오르게 하였습니다. 정말 훌륭한 위인전을 읽는 것 같다고 할까요? 이 책은 각 분야에 최고의 자리에 오른 프로그래머들의 사고 방식을 면밀히 살펴 볼 수 있어서 참 좋았던 것 같습니다.
뭐 조금 아쉬움이 있다면 인터뷰 형식이 비슷해서 참 비슷한 말들이 많이 나오네요.

개발실 면접 날짜들이 오가는 가운데 책 속에서 "검은 머리 파뿌리 될 때까지 IT 엔지니어 이길 꿈꾸며"라는 문장. 제가 면접 볼 때 100세 코딩이라는 말을 떠오르게 하는 부분도 있네요.

<스프링 프레임워크의 창시자 - 로드 존슨>
1) 고난을 만났을 때 극복할 수 있는 능력 또한 거기에 있다.
2) 메타인지가 가능한 시간이 얼마나 되는가? 
  a. 중요한 역할을 수행하는 사고 기능이 가능한 시간, 기억, 이해, 주의 집중, 의사소통 및 문제 해결 등에 중요한 역할, 문제 해결과정에 있어 계획하고 적절한 전략을 선택ㆍ사용하며, 과정을 점검ㆍ통제하고, 결과를 반성ㆍ평가하는 사고 기능.
3) 코드 최적화를 하지 않는 데에 대한 두 가지 이유. 
  a. 코드 최적화를 하지 않을 경우의 문제점을 인식하지 못하는 경우
  b. 코드 최적화를 무시하는 경우
4) 비즈니스 안목! 개발 기술이 떨어져서가 아니라 기본적으로 비즈니스를 이해하려 들지 않는 경우, 얼마나 똑똑한가는 중요하지 않다.
5) 체스 실력을 키우기 위한 최고의 선택은 다섯 게임을 하면 네 게임을 이기는 사람과 게임을 하는 것.
6) 스스로가 항상 도전하는 마음가짐을 가져야 한다.
  a. 회사의 비즈니스에 대해 보다 많은 것을 알려고 노력하고, 또 한 걸음 물너나 IT와 자신의 역할의 관점에서 좀 더 잘 할 수 있는, 좀 더 빠른 성과를 낼 수 있는, 그리고 신기술을 배울 수 있는 방법을 고민하는 시간을 가지려는 자세가 필요하다.
7)  성공에 대한 동기 부여, 그것이 개인적인 성공에 대한 동기부여
8) 큰 부자가 되기 보다는 그저 가족이 돈 걱정이 없을 정도의 수준을 유지해야 한다는 신조.
9) 똑똑한 사람들이 더 행복하다는 증거는 어디에도 없다. 직업과 경력에 도움이 되는 것들이 개인생활에서도 필요한 것은 아니라고 생각.

< ASP.NET 및 AJAX 아키텍트 -닉힐 코다리>
1) 질문하는 능력을 가져야 하며 폭넓은 사고력 로드맵을 개발하고 그냥 수용하기보다 더 나아가서 현상을 유지하도록 해야 합니다. ( 자신의 생각으로 질문할 능력과 답을 얻는 능력을 가져야 한다.)
2) 질문하고 배우는 습관이 필요하다. 배우고 질문하는 일을 결코 멈추어서는 안 된다. 이 업계는 기본적을 생각이 모든 것이고, 생각이 창조적이어야 하는 곳
3) 플랫폼은 개발자들이 성장하도록 기회를 제공하고 돈을 벌게 하는 것. 그것이 플랫폼을 성공적으로 만듭니다.
 (플랫폼을 성공적으로 만드는 것은 플랫폼의 상부에 있는 플랫폼 공급자와 개발자들 사이에서 얼마나 상생하느냐 하는 것)
4) 일일 계획표와 같은 형식적인 것들의 사용은 과거 시도에 거의 모두 실패 했습니다. 일기도 쓰지 않는다.
5) 일이 사생활이나 개인적인 시간을 삼키는 것은 아니지만, 제 마음은 거의 항상 기술과 관련한 어떤 것이 다른 모든 것보다 우선 순위가 높은 활동을 차지합니다

<가장 효율적인 자바 프로그래머이자 The Bile Blog 운영자 - 하니 술레이만>
1) 잘못된 문제를 풀고 있다고 한다? 주목 하는 것은 특정한 요소에 집착하는 행동이다. 이것은 올바른 접근 방법이 아니다. 올바른 접근 방법은 "무언가를 하기 위해 필요한 행동이 아니라 왜 이런 방식으로 행동하는지를 한발 물러나서 생각하자"식의 행동. 어떤 시점에서 "아. 이제 큰 그림이 보이는군"하고 생각이 들 때까지 잠시 물러나 있어야 한다. 그 큰 그림은 그 자체를 여러 가지 계층으로 나타낸다. 해결책을 떠 올리기 이전에 그 문제를 이해하는 것이 훨씬 낫다.
2) 기본적을 무슨 일이 일어나고 있는지 살펴보고 그 일에 관해 정말 생각해 보지 않고 보이는 것만 고치기가 더 쉽다? 그것이 또 다른 경험 법칙이라고 생각하는데, 이는 성급한 생각에는 의심을 품고 "망설인다"는 것을 의미한다. 무작정 뛰어들지 마라.
"무작정 뛰어들 때 무슨 일이 일어날까?? 내가 올바른 일을 하고 있는 걸까?라고 물어본다. 시간은 매우 가치 있는 자원을 생각.
3). "나는 자신이 무지하다고 생각한다"? 
X라는 분야에서는 전문가이기 때문에 전혀 경험이 없는 특정 분야에 대해서도 그들이 항상 띄어난 통찰력을 제공할 것이라고 가정하는 것입니다.
그런 사람이 있다면 폴 그레이엄(해커이자 화가)이 아닐까 생각하는데요? 
"...더 큰 그림을 그려보면 바다 속 정말 작은 물고기에 지나지 않습니다.", 
4) 개발자 커뮤니티를 참여시키고 그들의 자원을 끌어내고 그들의 지성을 끌어내는 일 등의 "백치 프로그래머 신드롬"과 싸우는 좋은 해결 방안?
"근무 시간 외에" 해야 한다. 규칙과 규정보다는 기본적 욕구가 이를 지배해야 한다. 물가로 말을 이끌 수는 있지만 물을 마시게 할 수는 없다는 뜻

<가장 인기 있는 자바 팟캐스트 'The Java Posse' 운영자 토 노리브, 조 눅솔, 칼 퀸, 딕 월>
1) 이상적인 상황은 있는 것을 인정하고 그걸 이해하려고 하며, 이해하지 못한 코드가 있을 때 이렇게 물어보는 사람
"이건 왜 이 방법으로 해야 되죠?" 반대로 결코 질문을 하지 않는 사람은 일을 망쳐 놓을 것이다.
2) 버그를 잡는 것, 어렵거나 고치기 힘든 버그를 해결 하는 방법?
a. 한발 물러서서 생각하는 방법과 높은 곳에서 생각할 수 있도록 생각의 범위를 넓혀기 
b. "이건 불가능해. 어떻게 이렇게 되는지 이해할 수 없어" 라고 생각하는 바로 그곳에서 시작하는 것이 정말 훌륭한 방법 중 하나이고 그곳에서 무엇인가를 배운다.
c. 로직을 이해하고, 시스템이 어떻게 작동하는지 이해할 수 있으면 문제를 꼭 짚어 낼 수 있다. 
d. 분할 정복 방법은 문제를 좁히는데 매우 효율적인 방법 중 하나이다.
3) "전 항상 제 일에 갇혀 있었죠. 인정보다는 명성을 갈구하는 스타일", "거의 항상 무언가를 거스르는 경향", "누군가를 위해 하는 일은 결코 편한 적이 없었어요.", "인정은 단지 당신이 해야 할 일을 잘했다. 정도"

<MS 인터넷 익스플로러 리드 아키텍트 - 크리스 윌슨>
1) 프로그램 매너저가 가져야 할 최악의 덕목은 한 발 뒤로 물러나서 듣고 모든 문제들을 받아들인 다음, 진짜 목표를 설정하고 문제를 해결하기 위해 한발 한발 나아가는 프로세스 중심이 되는 것.
2)  "학습 능력이 있는지", "지식을 탐구하고 향상시키는 능력이 있는지", "통찰력이 있는지를 본다."
무엇보다 이런 능력이 있어야 계속해서 성장하면서 업무를 잘할 수 있다고 본다.
3) 정말로 호기심 많고 탐구적이고 재미있는 분야에 과감히 뛰어들어서 문제를 처음부터 끝까지 이해한 다음에 해결책을 내고 다음 단계로 진행하려는 열정이 있는 사람
그러면서도 " 좋아, 모든 문제를 최대한 완벽하게 해결한 다음에 진행해"라고 말하고 싶지는 않다고 한다. 일을 신속하게 끝내지 못하게 된다는데....
4) "무지의 인식"의 중요성 
 어떤 위치든, 어떤 상황이든, 그게 일이든 인생이든 무엇이든지 나 자신의 지식과 경험의 한계를 인식한다는 것은 당연히 중요하다.
5) 소트프웨어 개발자의 역할과 자존심을 갖거나 갖지 않는 것은 어떤  관계?
 a. 흔히 자존심이 센 사람은 자신의 지적 능력의 한계에 대해 잘 알지 못하죠. 내가 제일 똑똑하다고 주장할 수도 없다. 사실은 내가 제일 똑똑하지 않은 때가 더 많겠죠. 특정 분야나 특정 사물에 대해서는 더 잘 아는 사람이 있고 멋진 아이디를 내는 데 선수인 사람도 있다. 그런 상황에 닥쳤을 때는 인지하고 누군가 기여하고 있다는 것을 알아차리면 잘 도와주고 앞으로 더 나아가게 해주는 게 더 좋겠다.
6) 숲을 보고 나무를 찾아내는 스킬을 향상시키는 방법은 어떤 것입니까? 
듣는 것, 먼저 의견을 내지 않고 여러 사람들과 함께 일하며, 특히 여러 똑똑한 사람들과 함께 일하는 방법을 배우는 것. 그러면 다른 아이디어들에 대해 생각해보게 되고 내 앞에 있는 나무 한 그루만 쳐다보지 않게 되죠. 
7) 올바른 방법(정도)와 빠른 방법(사도) 중 선택의 기로에 섰다. 스스로에게 올바른 방법을 선택하도록 동기부여를 하려면 어떻게 해야 할까요?
사도의 방법을 쓰는 것은 대부분 틀린 방법이다. '해볼 만한 가치가 있는 것들은 잘해 볼 가치도 있다.'  빠른 방법은 나중에 곤란에 빠지게 된다. 
8)찾기 어려운 버그는 어떻게 공략하는가?
어떤 분야를 배우고 어떤 분야를 자기 것으로 만들면 머릿속에서 코드와 기능에 대응시키고 버그가 어디 있을지 직관을 동원한다. 느낌이 팍 온다. 
9) 유지보수의 편의성을 유지한 채고 버그가 생기지 않도록 하는 효과적인 방법은 ?
 a. 누군가가 이 코드를 나중에 보게 될 경우를 이해하는 것이 가장 좋은 방법이다. 
 b. 처음부터 주의 깊게 잘해 놓는 것이 나중에 시간을 절약하는 길이라는 것을 알아야 한다.
10) 생산성의 관점에서 개발자의 능력과 대화형 개발환경(IDE)나 컴파일러 옵션, Makefile 같은 소프트웨어 툴의 순련도와의 상관관계에 대해 어떻게 생각합니까.?
모두 각자 필요한 도구를 능숙하게 사용할 수 있어야 하지만 그게 누구나 모든 도구의 전문가가 되어야 한다는 것은 아니다 .

11) 비즈니스적인 감각이나 사업적 통찰력이 소프트웨어 개발자에게도 중요할까요?
 소프트웨어 개발자의 범위를 어디까지로 볼 것인가 하는 것이다. 그리고 사업적 통찰력은 팀을 이끌기 시작하면 더 중요해질 것이다. 
12)오랜 기간 개발을 해왔다고요? 강좌를 듣는다고 어느 순간 짠하고 훌륭한 매니저, 훌륭한 강사, 훌륭한 사업 관리자가 될 수는 없다. 강좌를 듣는다고 특정 업계에 대하여 전략적으로 생각하는 방법을 이해하지도 못한다. 

13) 직원들을 합리적으로 대우 합니까? 미친 듯이 돌아가는 상황과 개인 생활이 없어지는 것을 어떻게 대처해 나가나요?
일주일 45~50시간 정도 이보다 더 많이는 안 하려고 노력한다. 긴장에서 해방되는 시간이고 그 시간이 없다면 월요일 아침에 기력을 회복해서 일하러 나갈 수 없다.

※ 마이크로소프트 아침 6시 출근하는 사람, 8시 30분쯤 출근하는 사람. 다른 사람들이 나타나기 전에 많은 일들을 일찌감치 해놓는다. 그러고 나면 11시쯤 사람들이 옵니다. 이 사람들은 9시, 10시까지 있어요.

<실용주의 프로그래밍의 창시자 - 앤드 헌트>
1) 새로운 것을 향해 나아가는 것과 기존의 것을 오래 붙잡고 있으면서 진정한 숙달의 경지에 이는 것이 충돌을 일으키기도 합니다. 
개인의 지적 능력과 경지에 이르기 전에 흥미를 잃지 않는 능력과의 관계에 대한 평소 생각?
2) 프로그래머의 그러한 특성 중 하나가 호기심이다 . 스킬이 떨어지고 호기심이 덜한 개발자들에게는 그런 문제가 생기기 않습니다. 
그런 사람들은 2년 후에도 기초 원리를 깨달으면서 완벽히 행복할 수 있다고. 하지만 최고로 우수한 전문가들은 1주일이면 슬슬 지겨워지기 시작할 겁니다. 더 이상 새로운 것이 없다고.
3) 소프트웨어 개발자가 자신의 무지를 인식하는 것은 얼마나 중요하나? 
"저는 모르겠습니다. 어떻게 해야 할지 막막합니다. 하지만 꼭 알아낼 겁니다." 라고 말하는 것을 좋아한다.
4) "그래, 지금 하고 있는 것이 이런 것이고 그 이유는 이러이러해"라고 말할 수 있어야 한다.
5) 주도 면밀함이 성공하는 개발자의 특성. 그것 말고도 어떤 것들이 있는가?
a. 언어 미학 스킬. 수학 전공자나 공학 전공자보다 영문학 전공자가 프로그래밍을 배우기에는 더 낫다고 생각하는 역발상.
b.개발자들이 가장 많이 하는 두 가지 일이 커뮤니케이션과 학습이다. 우리 소프트웨어 개발자들은 여러 가지 종류의 사람들과 여러 가지 비즈니스 기술들을 연결하는 진정한 커뮤니케이션 허브가 되어야 하고 그게 우리가 하는 아주 중요한 일이다. 
c.최고의 개발자들은 대부분 호기심도 강하고 지구력도 강합니다. 그래서 문제를 끈질기게 쫓아가죠. 자바, Lisp, C#, 루비 같은 언어 알든 모르든 딱히 상관 없다. 몇가지 언어를 배우고 나면 그런 것들은 금방 익힐 수 있다. 중요한 것은 운영체제 내부의 동작 메커니즘을 아는 것이다.
6) 기초 스킬에 대해? 대부분의 개발자들을 만나 보면 운영체제의 내부를 해킹하여 어셈블리 코드를 짜보면서 자라났거나 학교에서 가르쳐주는 자바만 배워서 그 이하의 낮은 단계는 정말 모른다. 
 기본기를 갖춘 친구들은 확실히 다르다. 뭔가 이상한 현상이 생기거나 프로그램이 죽어버리거나 처음 보는 뭔가가 발생할 때 그 진가가 드러난다.
7) 테스트를 작성하는 것에 대하여?
 "테스트 코드를 작성하는 데 시간이 많이 걸린다."는 것 역시 의심스럽다. 이것은 일종의 투자 전략이며 테스트 코드를 작성하는 데 걸리는 시간이 산술급수로 증가하면 어려운 버그를 찾아내는 데 걸리는 시간은 기하급수로 증가한다.
8) 정석을 따를 것이냐 빨리 하기 위해 변칙적인 방법을 따를 것이냐를 선택하는 기로에 설때,
 더글러스 아담스의 조언. "당황하지 말라" 이 말은 개발자로서 어려움에 봉착하는 상황에서 제일 먼저 떠올려야 한다.
9) 최고의 프로그래머, 생산성 높은 프로그래머는 ?
 많은 코드를 쏟아내는 것? 코드를 빨리 작성하는 것?과는 상관없습니다. "울적해" 지지 않는 것 (:누군가가 한 마디 한 것을 갖고 심난해서 기운 빠져 하는 그런 상황을 말한다.)
 누구나 어려움을 당하게 마련이지만 최고의 프로그래머들은 그런 것들도 정면 돌파한다. 빠르게 시작할 수도 있고, 시작을 느리게 하더라도 잘못된 방향 전환을 할 가능성은 훨씬 적다.
10) 재사용의 반대되는 것이 밑바닥에서부터 새로 만드는 것일 텐데요. 그렇게 하는 것이 적할한 경우는 언제인가.?
 버그가 많고 너무 빠르게 급조된 물건을 가져 쓸 때 생기는 위험성. 같은 코드를 두 번째 짜보면 처음 것보다 100배는 더 빠르고 더 좋을 거다. 먼젓번 경험이 있으니 이젠 어떻게 할지 알기 때문.
 부정적인 생각에서 벗어나지 못해 첫 번째 버전에 매달리는 것보다는 두 번째로 다시 만들어 보는 것이 훨씬 더 낫다. 
11) "다 갈아엎고 새로 만듭시다."라는 유혹을 느낄 때,
 한 두명일때랑 10, 50명일 때랑 다르다. 같은 50명을 모았고 이들은 첫 번째 했을 때보다 더 잘 알고 있다면 첫 번째 2년짜리 결과물을 내버리고 6개월 만에 새로 만들어서 대체하는 것이 훨씬 좋을 수 있다. 하지만 그 중 45명이 팀을 떠났다면 그전처럼 잘 만들지는 못할 것이다.
12) 고객과 일정 협상을 성공적으로 이끌어 내는 방법과 합의된 일정이 현실적이라는 것에 당신과 고객이 모두 동의할 수 있도록 하는 방법에 대해 말씀?
 "고객의 신임을 얻어라", 우리가 어떻게 일하는지 어느 정도 속도로 일하는지, 우리 팀의 업무 처리 속도는 어느 정도 인지 고객으로 하여금 보게 해야 한다. 우리의 능력에 합당한 기대를 가지도록 해야 한다.
13) 협업의 주요 문제가 된다면 개선을 위해서 어떤 접근 방법을 적용 할 수 있을까?
스탠드 업 미팅. 오늘 할 일이 무엇인지, 어제 무엇을 했는지, 내일 무엇을 하려 하는지를 대답하는 것. 
  그래서 문제가 있는 경우 우리가 과거에 했던 경험이나 협의를 경험 삼아 손쉽게 해결할 수 있는 걸들이 생겨나게 되며 이 정도면 당신은 다른 사람들이 무엇을 하고 있는지, 그들이 어제 무엇을 하고 있었는지, 또는 무엇을 하다가 난관에 부딪쳤는지 알 수 있다. 누구에게는 무엇이 필요하고, 우리가 업무를 마무리하기를 기다리는 사람은 누구인지도 알게 된다. 매일 듣게 되기 때문에 다른 사람들의 업무 진행 상황을 파악할 수 있게 되고, 뒤처지게 되면 재빨리 알아차릴 수도 있게 된다 . 모두가 하나가 되어 팀으로 일하게 하는 데 정말 좋은 방법이다.

<자바의 아버지 - 제임스 고슬링>
1) 성공한 특징이 있다면?  일종의 실패...
2) 독서가 많은 도움을 준다. 즐겨야 한다. 네트워킹 프로토콜을 가지고 놀아야 하며, 재미 삼아 자신만의 것을 구현해 보고 버리고도 해야 한다.
3) 성공적인 개발자의 몇 가지 다른 특징(호기심 제외)
a. 끈기 : 어떤 것이 제대로 동작하지 않을 때 고집스런 집중력으로 도대체 문제가 무엇인지 알아내려고 하는 모습
 - 많은 사람들은 쉽게 포기한다. 하지만 하는 일에 정말 몰두하는 사람이 있다.
b. 계속해서 전진할 수 있는 유일한 방법은 쓸데없는 것을 버리는 것.
c. 직접 해보는 것을 아주 신뢰한다. 배우는 과정에서 배우는 것이다.
3) 협업 = 짝프로그래밍
a. "나는 내가 맡은 일을 하고 당신은 당신의 일을 하고 이 일들을 하나로 만드는 것"
b. 두 사람이 동일한 알고리즘을 바라보고 결과를 만들어 내려고 하는 것. 
c. 화이트보드에서 짝으로 일하는 것.
d. 어울림이 필요하며, 성미가 까다로워질수록 이런 모습은 드물어진다. 거의 모든 뛰어난 프로젝트들은 더 많은 사람들이 어울려 작업한다. 
4) 올바르게 일하는 것을 습관으로 만들어야 함을 깨닫는다.

이 책을 읽고 나서 각자 잘 알려진 역할에 따른 분류들이 도움이 되었다고 생각되며 삶과 일에 대한 지혜 또한 얻었다고 생각 됩니다. 중요한 건 나 자신의 영역에 대한 역할이기에 저 스스로도 좋은 대우를 받고 싶고 그러기 위해서는 저 나름대로의 비전과 철학을 점점 쌓아가며 저 자신의 길을 걷고 싶습니다. 

제임스 고슬링 아버님이 현재 60세. 구글 퇴사 후 해양정보수집로봇을 개발하는 벤처기업에 입하게 됐다는데 이것이 3년전. 근황 찾기가 힘드네요. 저는 100살까지 산다 생각하고 70살까지 일해야지........