.

보통 경제/경영서 또는 인문서를 읽을 때 우리는 절로 고개가 끄덕여지는 것을 느낄 수 있다.

책 속에서 필자가 얘기하는 다양한 사례 또는 한 번쯤 접해봤을 법한 또는 접하게 될 수 있는 여러 가지 상황에 대한 얘기를 눈으로 접하게 될 때 그런 공감의 반응이 자연스레 몸에서 나오는 것인데 개인적으로 최근에 읽었던 컴퓨터/IT 서적 '코딩호러의 이펙티브 프로그래밍'에서도 비슷한 경험을 할 수 있었다.


'코딩호러의 이펙티브 프로그래밍'은 개발자라면 또는 개발자를 향해 전진하고 있는 수많은 사람들이 한 번쯤 방문했을 '스택 오버플로우(http://stackoverflow.com/)' 사이트의 공동 창업자인 제프 앳우드(Jeff Atwood)가 소프트웨어 개발과 관련된 지혜와 조언을 전해주는 내용으로 구성되어 있다.


어쩌면 책에서 얘기하는 여러 가지 사례들이 지금까지 개발자 생활을 해 오면서 몸으로 부딪혀 겪어봤던 입장이기에 더욱 공감하며 고개를 끄덕였는지도 모른다.

과연 나는 책 속의 어떤 사례에서 그 어떤 사례보다 더욱 고개를 끄덕이며 수긍을 했던 것일까?

프로그래머는 여덟개의 단계가 있다.

"1. 죽은 프로그래머
- 최고의 단계이다. 당신이 작성한 코드가 끝까지 살아남아서 당신이 죽고 난 후에도 사용된다.
예: 다익스트라, 도널드 커누스, 앨런 케이

2. 성공적인 프로그래머
- 널리 알려져 있으며 자신의 코드를 이용해 하나의 비지니스를 새롭게 창조한 프로그래머이다.
예:빌 게이츠, 존 카맥, DHH

3. 유명한 프로그래머
- 이것도 상당히 휼륭한 단계이긴 한데, 프로그래밍과 관련된 직업을 가지고 있는 경우에 한해서이다. 당신은 자신의 분야에서 긍정적인 영향을 미치는 존재이다.

4. 일하는 프로그래머
- 당신은 소프트웨어 개발자로서 성공적인 경력을 보유하고 있다. 당신의 기술을 필요로 하는 곳은 늘 있으며, 어떤 좋은 직장을 구하기 위해 그다지 오래 기다릴 필요가 없다.

5. 평균적인 프로그래머
- 이 단계의 프로그래머는 자신이 결코 위대한 프로그래머가 아니라는 사실을 깨닫긴 하지만 충분히 좋은 실력을 갖추고 있는 프로그래머다.

6. 아마추어 프로그래머
- 아마추어 프로그래머들은 코딩을 좋아하는 사람들이다. 장래가 촉망되는 학생이나 인턴일 수 있고, 오픈소스로 프로젝트에 기여한 사람들일 수 있다.

7. 알려지지 않은 프로그래머
- 전형적인 프로그래머의 단계다. 보통 유능하긴 하지만 별다른 특징이 없는 사람들이다.

8. 나쁜 프로그래머
- 프로그래밍에 어울리는 기술이나 능력이 없는 상태에서 프로그래밍을 수행하는 직업을 갖게 된 사람들이다. 그들이 건드리는 것은 무엇이든 다른 동료 프로그래머들에게 고통을 안겨준다."

흔히 남자들이 군대 얘기를 할 때 중간에 속하라 말하곤 한다. 사회생활에서도 그럴까?

절대 아니라 생각된다. 평균적인 프로그래머 이상으로 향해야 하며 적어도 일하는 프로그래머에는 속해야 할 것이다. 과연 나는 어떤 프로그래머에 속하는 것일까?

쓰지 않으면서 쓰기

"진정으로 위대한 프로그래머가 최기 위해서는 기술적 능력과 강한 끈기 같은 것이 필요할 것이다. 하지만 다른 무엇보다 중요한 것은 바로 의사소통 능력이다.

누군가에게 '블로그를 시작해야 해!'라고 말하는 것은 아무 효과가 없다. 누구나 블로그를 할 수 있는 것은 아니다. 평균적인 수준의 프로그래머들에게는 블로그에 아주 작은 글을 올리는 것조차도 도저히 생각할 수 없고, 시도조차 할 수 없는 일인 것처럼 느껴진다."

적극 공감되는 내용이다. 지금까지 사회생활을 하며 관련 직종에서 만난 수많은 사람들 중 단 몇 명 아니 2~3명 만이 블로그를 운영했고 그나마도 중간에 포기하고 블로그를 방치해둔 경우도 있었으니 말이다.

왜, 글을 써야 하는지 묻는다면 난 주저없이 아래의 내용을 얘기해 주고 싶다.

"모두가 아주 많이 글을 써야 한다. 블로그이든, 책이든, 스택 오버플로우의 답글이든, 이메일이든 상관없다. 글을 쓰고, 그 글에 대해 잠시 생각을 하는 것이다. 내 경험에 의하면 글을 명확하게 하는 것은 자신의 내면적 사고의 흐름을 명확하게 하는 데 도움을 준다. 어떤 것을 다른 사람에게 정확하게 설명하고자 노력해 보면, 자기가 얼마나 많은 부분을 제대로 모르고 있었나 하는 것을 깨달으며 놀라게 된다. 바로 그 지점에서 완전히 새로운 발견이 시작되는 것이다."

위 얘기는 이미 수년 전 부터 블로그를 운영해 오며 나 자신도 모르게 깨닫게 된 부분이다. 그로 인해 다른 사람들에게 나누어준 것 보다 내가 득한 것이 더 많다는 사실 또한 절대 부정할 수 없는 점이기도 하다.

멀티태스킹이라는 미신

"제럴드 와인버그의 계산에 의하면 당신이 해야 하는 일에 단 한 개의 프로젝트를 더하기만 해도 상황은 현격하게 악화된다. 20% 정도의 시간이 쓸모없이 소모되는 것이다. 여기에 한 개의 프로젝트를 더 추가하면 50% 정도의 시간이 업무 사이를 오가는데 소모된다."


적극 공감된다. 하지만 우리는 이미 태어날 때 부터 멀티태스킹 삶을 살고 있지 않은가?

누군가의 아들로, 누군가의 손자로... 성인이 되어서는 누군가의 남편, 아내로 또 누군가의 아빠, 엄마로써 말이다. 물론 유형이 아닌 무형의 멀티태스킹이긴 하지만...

아이디어가 아니라 팀을 가꿔라

"그저 그런 그룹에게 좋은 아이디어를 제공하면 그들은 아이디어를 망쳐버릴 것이다. 하지만 훌륭한 그룹에게 그저 그런 아이디어를 제공하면 그들은 아이디어를 멋진 무엇으로 구현할 것이다. 혹은 그저 그런 아이디어를 밖으로 내던지고 뭔가 다른 것을 만들어 낼 것이다."

개발자로 일하기 시작한지 얼마 안되었을 때 그러니까 약 4~5년차 때까지만 해도 '나만 잘하면 되지' 라는 생각을 가지고 있었다. 정말 위험한 생각임을 스스로 깨달았지만 오랜 시간이 걸린듯 하다.

팀이 존재하므로써 내가 존재할 수 있음을 절대 잊어서는 안 될 것이다.

성능은 기능이다.

"구글이 발견한 바에 의하면 10개의 결과를 담은 페이지가 만들어지는데 0.4초가 걸린다. 30개의 결과를 담은 페이지는 0.9초가 걸린다. 0.5초가 더 느려질 때마다 20%의 방문이 줄어든다. 0.5초의 지연이 사용자의 만족도를 끝장내는 것이다."

사용자의 만족을 위해 아래의 방법을 이 책에서는 제시해 준다.

1. 야후의 가이드라인을 경건한 마음으로 따르라.
2. 익명 사용자와 등록된 사용자들을 사랑하라. 그리고 그들을 위한 최적화를 수행하라.
3. 성능을 자랑거리로 삼아라.

프로그래머를 제대로 채용하는 방법

고용주는 아니지만 고용주의 입장에서 이해한 내용으로 프로그래머를 채용하기 위한 몇 가지 방법을 제시하고 있다.

1. 우선 몇 가지 간단한 "헬로 월드" 온라인 테스트를 수행한다.
2. 포트폴리오를 보여 달라고 한다.
3. 문화적으로 어울리는 사람을 고용하라.
4. 자세하고 구조적인 전화 인터뷰를 통해 걸러내는 과정을 밟아라.
5. 오디션 프로젝트를 제공하라.
6. 한 방에 들어간 다음 말하는 것을 들어보라
7. 하지만 보장된 것은 아무것도 없다. (앞선 목록은 참고사항을 뿐이며, 이러한 조언들이 실제로 도움이 되는 경우를 많이 봤지만 경우에 따라서는 도움이 되지 않는 경우도 있었다.)

나는 위 항목 중 몇 가지에서 만족감을 전해줄 수 있을까?

그들이 어떤 말을 하든 그것은 결국 사람과 관련된 문제다.

"당신의 프로젝트가 성공할지 여부를 판단해야 한다고 해보자. 다음 질문에 대한 답변이 존재하면 나는 프로젝트가 성공할지 여부를 거의 확실하게 말할 수 있다.

1. 당신의 팀이 얼마나 많은 줄의 코드를 작성할 것인가?
2. 어떤 종류의 소프트웨어를 만드는가?
3. 동료 프로그래머들을 좋아하는가?"

이 중에서 마지막 질문이 제일 중요하다고 제프 앳우드는 얘기하다.

"행복하고, 건강하고, 손발이 척척 맞고, 사회적 기능이 원활하게 돌아가는 소프트웨어 개발팀이 실패하는 경우를 나는 본 적이 없다. 하지만 그런 팀이 많지 않다는 사실은 아쉬운 일이다."

짝 프로그래밍 대 코드리뷰

"규모가 큰 팀에서는 매 주마다 짝을 바꿔서 다른 사람과 짝을 이루게 하는 것이 가능하다. 이런 과정은 개발자들이 서로의 생각을 공통의 언어인 코드를 통해 논의하게 만들기 때문에 엄청난 장점이 있다.

우리는 이런 식으로 일하는 것이 혼자서 개별적으로 코딩하는 것보다 느리지 않다는 사실도 발견했다. 짝 프로그래밍을 통해 코드는 빠르게 작성되고 일단 작성된 다음에는 누가 다시 살펴보지 않아도 된다. 그리고 설령 코드에 변경이 필요한 순간이 오더라도 코드를 변경할 수 있는 사람이 두 명이나 있다.
...

이에 비해 코드리뷰는 두 사람이 물리적으로 같은 공간에 있어야 하는 짝 프로그래밍보다 훨씬 도입하기가 수월하다.
...

이 두 기법은 모두 실질적인 장점을 가지고 있다. 하지만 각각 저마다의 장점과 단점이 있다. 어느것이 더 효과적일까? 아니면 그냥 둘 다 수행하는 것이 좋을까?

결국 당신이 작성한 코드를 또 다른 한 쌍의 눈이 어떤 식으로든 보도록 만들기만 하면 두 기법 중에서 어느 것을 선택하는가는 그다지 중요하지 않다. 다른 사람이 작성한 코드를 검토한다는 원칙만 지켜지면 그 사람이 옆에 앉아있는가 아니면 1000마일 정도 떨어져 있는가와 상관없이 당신은 더 좋은 소프트웨어를 만들 수 있다"

회의 : 일이 죽으러 가는 장소

개인적으로 어떤 회의이든 서로 눈을 마주보고 커뮤티케이션 한다는 그 자체로 의미가 있다고 생각된다. 설령 업무와 상관없는 얘기가 오간다 할지라도 말이다. 하지만 분명한 것은 목적없는 회의란 있을 수 없고 업무와 상관없는 얘기도 그리 길지 않을 것이라는 것이다.

제프 앳우드는 회의를 '일이 죽으로 가는 장소'라 표현했지만 그 이면에는 회의 또한 일의 연장선으로 만들어야 함을 아래와 같이 강조하고 있다.

"1. 어떤 회의라도 한 시간을 넘기면 안 된다. 넘기면 사형이다.
2. 모든 회의에는 명확하게 정의된 목표가 있어야 한다.
3. 회의에 참석하기 전에 회의에서 필요한 일을 하라.
4. 회의에 참석하는 것을 선택사항으로 만들어라.
5. 회의를 마무리 할 때 해야 할 일을 정리하라."


썩은 사과를 다루는 방법

문제가 있는 사람 즉, 책에서 썩은 사과가 있음을 나태내는 징후를 몇 가지 알려주고 있는데 다음과 같다.

"1. 그들은 동료로부터 배우려고 노력하기보다 자신의 무지를 감추기 위해 노력한다.
2. 그들은 지나치게 프라이버시에 집착한다.
3. 그들은 팀에서 내린 결정에 대해 투덜거리고, 오랜 시간이 지난 뒤에도 낡은 논의를 다시 꺼낸다.
4. 팀원들이 동일한 한 사람에 대해 정기적으로 독설이나 불만을 토로한다.
5. 팀의 활동에 참여하지 않는다.
...

누군가를 제거하는 것은 고통스러운 일이다. 그런 일은 어느 누구에게도 즐거운 일이 될 수 없다. 하지만 그를 6개월 전에 제거했어야 한다는 사실을 뒤늦게 깨닫는 것은 그보다 더 큰 고통을 안겨줄 것이다."


처음부터 썩은 사과라는 게 존재할 수 있을까? 물론 그럴 수도 있겠지만 대부분 어떤 과정을 통해 그렇게 변해가는 것으로 생각된다. 썩는 것은 어떤 상처에 의해 즉, 그 부분이 곪기 시작해 결국 썩어버리는 경우가 많을 것으로 생각된다.

서로 상처내지 않기, 정말 중요할 것 같다.

썩은 사과 : 그룹 전체의 독

"썩은 사과를 포함하고 있음에도 매우 좋은 성적을 거둔 그룹도 있었다. 그 그룹에는 특별히 훌륭한 리더가 존재했던 것이다. 그는 팀원들에게 질문을 던지고, 모든 사람들을 참여시키고, 충동을 완화시킨다"


지금까지의 내용 모두 이 책의 중간 이전에서 나온 얘기들이며, 그 뒤에도 고개가 끄덕여지는 내용들이 많지만 여기에서 정리를 마친다. 서두에 얘기했던 더욱 고개가 끄덕여지는 내용을 이미 전했기 때문이다.

바로 "아이디어가 아니라 팀을 가꿔라"가 그것이다.

나 혼자만으로 국가를 이룰 수 없다. 국가는 국민 모두이기 때문이다. 똑같이 나 혼자 팀을 이룰 수 없다, 그리고 회사는 팀원을 담고 있는 팀 단위 조직으로 이루어져 있다.

끝으로 제프 앳우드는 프로그래머의 권리 장전 몇 가지를 제안하고 있는데 그 내용 또한 수긍될 수 밖에 없는 것들이다.

1. 모든 프로그래머는 두 대의 모니터를 가져야 한다.
2. 모든 프로그래머는 빠른 PC를 가져야 한다.
3. 모든 프로그래머는 마우스와 키보드를 자기가 원하는 것으로 선택할 권리가 있다.
4. 모든 프로그래머는 편안한 의자를 가져야 한다.
5. 모든 프로그래머는 인터넷에 연결 할 수 있어야 한다.
6. 모든 프로그래머는 조용한 작업 환경을 가져야 한다.


참고로 책 속에서 편안한 의자가 어떤 것인지에 대해서까지 자세히 설명을 해주고 있다. 꼼꼼한 제프 앳우드...


* 이 책을 꼭 읽어봐야 된다고 추천하기는 힘들다. 왜냐하면 대부분의 내용들이 수긍할 수 밖에 없는 이미 알고 있는 내용들이기 때문이다. 하지만 그럼에도 읽어봐야 하는 이유에 대해 한 가지만 얘기한다면 이렇게 말할 수 있을 것 같다.

"인간은 망각의 동물이다. 알고 있지만 기억 속에서 꺼내고 싶지 않은 경우도 있고 또 어떤 경우에는 정말 기억이 안나는 경우도 있다. 후자의 경우라면 이 책이 다시 기억을 살려줄 것이고 전자의 경우라면 잊는 것 만으로 답이 나올 수 없으니 해결을 위해 읽어봐야 할 것이다. (그렇다고 어떤 답을 전해주는 내용은 결코 아니다.)"


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

댓글을 달아 주세요

1 ··· 38 39 40 41 42 43 44 45 46 ··· 997 
 CATEGORY
분류 전체보기 (997)
개발자 이야기 (1)
제품 이야기 (544)
세상 이야기 (365)
책 이야기 (1)
사진 이야기 (81)
뜬금없는 이야기 (5)
 RECENT POST
 RECENT COMMENT