천객만래 [千客萬來] (It has an interminable succession of visitors)

'프로그래머'에 해당되는 글 19건

  1. 2018.03.15 SW 개발자의 길, 아니다 싶으면 포기하라!
  2. 2014.09.23 [자기경영/컬럼] 순진한 개발자가 사내정치에서 살아남는 법
  3. 2014.09.23 [개발/자기경영] "개발자에 필요한건 문제해결 능력"
  4. 2014.09.23 [경영] [컬럼] 대한민국 개발자의 우울, 자기책임론에서 구조개혁론으로
  5. 2014.04.10 [개발] 프로그래머로 살아남는 법
  6. 2013.07.12 [유머] 개발자 이력서 10계명
  7. 2011.07.19 [개발/설계] 프로그래머를 위한 사용자 인터페이스 설계론 - Joel on software
  8. 2011.01.04 [개발/컬럼] 소프트웨어는 누가 개발해야 하는가?
  9. 2011.01.04 [IT/컬럼] 이런 IT 회사 가지마라
  10. 2010.10.21 [개발] SW 개발자의 길, 아니다 싶으면 포기하라
  11. 2010.10.20 [개발] 대한민국 IT에는 미래가 없다. 그런데 난 즐겁다
  12. 2010.10.20 [개발] 프로그래머가 되는 방법: 짧고 폭넓고 개인적인 요약
  13. 2010.10.20 [개발] 오랫동안? 프로그래머로 남으려면...?
  14. 2010.10.20 [개발] The Joel Test: 나은 코딩을 위한 12단계
  15. 2010.10.14 [개발/델파이] 델파이 객체지향프로그래밍을 위한 20가지 규칙
  16. 2010.10.14 [개발] 프로그래머의 길에 대하여
  17. 2010.10.14 [개발] 프로그래머들 속담
  18. 2010.10.14 [개발] easter egg-이스트에그 : 프로그래머의 재치와 익살
  19. 2010.10.13 [IT/개발] 개발자 Coder < Programmer < Engineer < Architect < Consultant 로 성장

SW 개발자의 길, 아니다 싶으면 포기하라!




20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다.
Posted by SB패밀리

순진한 개발자가 사내정치에서 살아남는 법




류한석 (IT 컬럼니스트) ( ZDNet Korea )   2008/03/17

 

개발자 K씨를 재회한 것은 8년만의 일이다. 그는 나와 함께 일했던 직장에서 이직한 이후에 4번이나 더 이직을 했는데, 현재는 실직 상태에서 직장을 구하고 있었다. 

 

솔루션을 개발하는 회사에서는 비전이 없어 그만 두었고, 대기업 계열 SI업체를 들어갔으나 개발이 아닌 관리를 시켜서 그만두었고, 포털에 들어갔는데 할 일이 별로 없고 회사 상황이 정치적이어서 그만두었다고 했다. 그리고 마지막 회사는 소위 벤처기업이었는데, 6개월이나 임금을 받지 못한 상태에서 사장이 사실상 야반도주를 해서 회사가 망했다고 했다. 

K씨는 자바를 정말 잘 다루던 개발자였는데, 일반적인 기준에서 볼 때 성격이 좋다고 얘기하기는 힘든 사람이었지만 그 정도면 무난하다고 할 수 있었다. 다만 여느 개발자와 마찬가지로, 타인의 욕구에 관심을 가지거나 커뮤니케이션 스킬이 뛰어난 사람은 아니었다. 다음은 그가 한 얘기이다.

“회사 경영은 나하고 상관이 없다고 생각했어요. 제가 경영이나 관리 같은 것은 잘 모르고요. 회사에서 벌어지는 정치 게임은 질색이에요. 저는 그저 개발만 하고 싶었어요. 그런데 개발에 집중할 수 있는 조직이 참 없더라고요. 이제 저는 어떻게 해야 할까요?”

필자는 그날 K씨와 새벽까지 술을 마실 수 밖에 없었다. 개발자가 개발자답게 일하고 성장할 수 없는 것이 바로 한국의 현실이다. 성장을 하는 것이 아니라 사라져 가고 있다.

개발자는 어떤 사람인가? 문제를 발견하고 문제를 해결하고, 스펙에 따라(또는 창조적으로) 무언가를 만들어 내고, 오랜 시간 동안 한 자리에 앉아서 화면만을 째려보며 몰입할 수 있기에 개발자다. 그것이 그들의 특징이며 그렇기 때문에 개발을 할 수 있는 것이다. 

개발자에 대해 IT업계의 다른 직종들은 어떻게 생각하고 있을까? 단편적이지만 그들의 생각을 살펴보자. 어떤 영업맨은 “저한테 저렇게 열 시간 동안 앉아 있으라고 하면 절대 그러지 못할 거 같네요. 어떻게 저럴 수 있나요?”라고 필자에게 반문하기도 했다.

어떤 마케터는 “그들은 쿠폰에 항상 도장을 찍더군요. 작은 것에 민감한 거 같아요. 시야가 좁고 자신들의 분야 외에는 거의 관심이 없는 거 같더군요. 게임이나 애니, 미드 같은 것을 좋아하고. 업계나 시장 돌아가는 상황에 대해서는 관심도 없고...”라고 얘기했다. 실제로 마케터들은 개발자와 함께 일하는 경우가 별로 없어서 그들을 잘 모른다. 원거리에서 그들을 바라볼 뿐이다.

반면에 개발자와 함께 협업하는 경우가 많은 요구분석가, 웹기획자들 중 상당수는 다음과 같은 얘기를 했다. “그들은 커뮤니케이션 스킬이 없어요. 중요한 대화에는 제대로 응하지 않다가 자신들과 상관이 있는 이슈가 나오면 발끈해요. 무조건 안 된다고만 하죠. 도무지 협상이라고는 할 줄 모르는 사람들이에요.”

혼자서 일하는 1인 개발자가 아닌 이상, 대부분의 개발자는 조직에서 협업을 해야 한다. 프로젝트 매니저와 대화해야 하고, 기획자/디자이너/동료 개발자와 협업을 해야 한다. 프로젝트에 따라서는 고객과 직접적인 커뮤니케이션을 해야 하는 경우도 있다. 그리고 사내정치를 피해갈 수 있는 개발자는 거의 없다. 직간접적으로 영향을 받을 수 밖에 없다.

그런데 한국에서 사내정치는 중소기업에서 대기업, 인터넷기업까지 만연되어 있다. 많은 개발자들이 정치를 싫어한다. 정확히 표현하면 정치가 미치는 부정적인 영향을 싫어한다고 할 수 있을 것이다. 하지만 조직이라는 것은 그 안에 있는 수많은 조직구성원들이 지위 고하에 따라 자신의 목표와 이익을 추구하는 곳이다. 그리고 그들간의 이해관계는 상충될 수 밖에 없다. 그래서 누군가는 희생자가 된다. 안타깝게도 그 대상은 대부분 개발자이다.

개발자는 현실적인 일정 하에서 보다 나은 기술을 이용하여 높은 품질의 소프트웨어를 만들고 싶어하지만, 어떤 사람들은 기술 자체나 품질은 전혀 상관없이 일자 또는 비용만이 그들의 관심사이다. 그렇다면 그것은 잘못된 것인가? 그럴 수도 있고 아닐 수도 있다. 상황에 따라 답이 다르다. 현실은 단순한 흑백논리로 설명되지는 않는다.



패배하지 않기 위해 이것만은 기억하자

사내정치에서 살아남기 위해서 개발자가 알고 있으면 유용할 세 가지 지침을 제시한다. 다음의 세가지 지침은 서로 연동된다.


1. 나의 목표와 주변의 이해관계를 파악하고 있어야 한다. 


자신이 원하는 것이 돈인지 명예인지 지위인지, 아니면 개발을 통한 자아실현인지, 개인생활의 추구인지 명확히 알고 있어야 한다. 또한 나의 목표를 실현하는데 있어 가장 큰 장애물이 무엇인지 알고서 그것을 관리해야 한다. 자신의 목표와 상충되는 목표를 가진 이해관계자의 욕구를 파악하고 그것과의 타협점을 찾아야 한다. 

하지만 사실, 대부분의 경우 목표를 실현하는데 있어서 가장 큰 장애물은 자기자신의 성격이다. 그렇지만 성격을 수양하는 개발자가 과연 몇 %나 될까? 아는 것과 실천은 완전히 별개의 단계이다.

2. “너와 나의 진실은 다르다”는 사실을 이해하고 있어야 한다. 


자신이 믿는 것만이 정의이고 진실이라는 생각이 들 때, 숨을 세 번 크게 내쉬면서 상대편의 입장에서도 과연 그럴까 다시 한번 생각해 보기 바란다. 내가 알거나 느끼는 것을 쉽게 드러내서는 곤란하다. 대부분의 경우 그것은 설익은 판단이고 타이밍이 적절치 않은 경우가 많다. 하지만 자신의 감정을 주체하지 못하고 ‘욱’한 나머지, 준비도 안된 상태에서 회사를 그만 두어 버리고 경력을 망치는 개발자들이 많다. 퇴사 후 놀고 있는 당신을 사내정치인들은 비웃고 있다.


3. “군자에게는 실수를 해도 소인배에게는 실수를 하지 말라”는 격언을 기억하기 바란다. 


이 말은 필자가 회사 생활에서 곤란을 겪는 후배들에게 숱하게 해주었던 말이다. 이 말을 처음 들었을 때의 임팩트는 상당히 크다. 군자(君子)는 점잖고 덕이 있는 사람이다. 그래서 군자는 누가 실수를 해도 그 이유를 스스로 파악하여 너그럽게 이해해준다. 하지만 소인배는 조금만 불이익을 당하거나 무시를 당했다고 느끼면 바로 삐지며, 심할 경우 끝까지 따라다니며 괴롭힌다.

그런데 사람이란 군자에게는 존경심을 갖고서 공손히 대하고 소인배는 무시한 나머지 함부로 대한다. 그것이 인지상정이다. 하지만 만일 그 소인배가 당신의 직장상사라면?

사내정치는 어느 나라에나 존재한다. 한국뿐만 아니라 미국에도 일본에도 있다. 하지만 한국에서 더욱 사내정치가 심할 수 밖에 없는 이유가 있다. 한국은 아직까지 IT업계뿐만 아니라 사회의 여러 분야에서 전문가의 개념이 불분명한 나라이다. 제대로 된 전문가가 출현하고 그 가치를 인정받는 지식사회가 되기까지 앞으로도 꽤 많은 시간이 걸릴 것이다. 

한국은 아직은 선진 지식사회가 아니다. 그러므로 고급지식을 가진 사람들이 별로 없을 뿐만 아니라, 설사 있다고 하더라도 그것을 인정하지 못하며, 설사 인정한다고 할 지라도 필요로 하지 않는다. 실력을 인정하는 기준이 없으니, 사내정치가 판을 친다.


전문가를 필요로 하지 않는 사회, 자기계발이 살길 


궤변으로 들릴 지 모르지만, 우리 업계에 전문가가 없는 것은 전문가를 필요로 하지 않기 때문이다. 조직 내에 사내정치인이 승진하고 인정받는 것은 조직의 상층부가 몰라서 그런 것이 아니라 그런 사람을 선호하기 때문이다. 

성장은 커녕 생존을 이야기해야 하는 현실이 안타깝지만, 일단 생존해야 자기계발을 하고 경력관리를 하면서 기회를 노릴 것이 아닌가? 사내정치를 잘 할 필요는 없지만(그리고 개발자의 특성상 잘 하지도 못 할 것이다), 희생자가 되어서는 곤란하다. 이것이 바로 필자가 개발자 K씨에게 한 말이다.

개발자는 자신의 개발력과 장점을 해치지 않는 선에서, 이해관계자를 파악하고 그들의 욕구를 다루는 능력을 갖추어야 한다. 자신의 목표를 분명히 해야 하며, 감정에 치우쳐서 일을 그르치지 말아야 한다. 그러지 못한다면 결국 희생자가 될 뿐이다.

그러한 희생을 몇 번 당하다 보면, 개발업에 대한 애정이 식어버려 자기계발을 등한시하게 될 뿐만 아니라 성격까지 나빠져서 더욱 더 안 좋은 상태에 처하게 된다. 그렇게 사라져간 개발자들이 참 많다.

이런 조언을 하는 것에 대해 한편으로는 미안하게 생각한다. 언젠가 개발력만으로도 인정받을 수 있는 사회가 오면(너무 낭만적인 표현이다), 사내정치 대신 좀 더 아름다운 세상에 대해 이야기하겠지만 지금은 아니다. 정신을 똑바로 차리고 이 난세에서 생존하기 바란다. 환경을 바꿀 수 없으면 자신을 바꾸어야 하며, 자신을 진화시킨 개발자에게는 반드시 기회가 올 것이다. 세상은 장기적으로 볼 때 스스로 혁신하는 사람의 편이니까 말이다. @

 

출처 : http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39166851,00.htm

Posted by SB패밀리



'SW 마에스트로' 연수생 구글 본사 방문… 선배들과 간담회

2011년 01월 07일

"좋은 소프트웨어(SW) 개발자의 조건은 명문대 졸업여부가 아니라 창의력과 문제에 접근하고 해결하는 능력이다.", "초가집을 수 백 채 지어봤다고 63빌딩을 건설할 수 없다. SW 개발도 우선 역량을 크게 키워야 한다."

실리콘밸리를 방문한 한국의 SW 꿈나무들에게 미국 구글 본사에서 근무하고 있는 한국인 SW 엔지니어들은 창의력을 바탕으로 더 높은 곳으로 비상해야한다고 조언했다.

5일(현지시간) 지식경제부, 정보통신산업진흥원, 한국정보산업연합회 등이 주관하는 SW 마에스트로 미국 연수의 일환으로 구글을 방문한 학생들은 직원들의 언제든 즐길 수 있는 게임기와 카페테리아 등 자유로운 업무환경을 돌아봤다. 이어진 구글 본사에서 근무하고 있는 한국인 SW엔지니어들과의 간담회에서는 선배들의 조언이 쏟아졌다.

SW엔지니어인 전지운 씨는 "코딩과 프로그래밍 능력은 물론 창의력과 문제에 접근하고 해결하는 능력이 중요하기 때문에 미국에서는 SW 개발자를 뽑는데 창의력과 문제 해결 능력 등에 중점을 두고 평가한다"며 "알고리즘과 자료구조 등이 중요한데 책만 본다고 이런 능력이 생기는 것이 아니므로 프로젝트를 하면서 문제 해결 능력을 배양해야 한다"고 말했다.

김용성씨는 "초가집을 수 백 채 지어봤다고 63빌딩을 지을 수 있는 것이 아닌 것처럼 SW 도 SW를 잘 개발하는 역량이 있는 기업에서 배워야 한다"며 "SW 마에스트로 과정을 통해 큰 프로젝트들을 진행해 보는 것도 도움이 될 것"이라고 조언했다.

SW 마에스트로 연수단 학생들은 구글의 SW 개발 여건에 많은 관심을 나타냈다.

이에 대해 김용성 구글 SW엔지니어는 "미국과 한국의 SW 개발 환경의 차이는 관리 대상이 다르다는 것"이라고 설명하고 "한국에서는 SW를 개발할 때 사람을 대상으로 관리하는데 구글 등 미국에서는 일의 성과를 중심으로 관리한다는 점이 다르다"고 말했다. 또 "구글 등 미국 기업들의 자율적인 SW 개발 환경에 대해 동경하는 이야기가 많은데 실제 일의 강도와 업무는 한국보다 더 높다"며 "이는 업무를 믿고 맡겨서 밀어주는 환경이 업무 집중도를 높여주기 때문"이라고 설명했다.

한국인 구글 SW엔지니어들은 후배 개발자들에게 문제 해결 능력을 배양하는 것이 중요하다고 입을 모아 말하고 시야를 넓게 갖고 큰 꿈을 가지라고 충고했다

출처 : http://www.dt.co.kr/contents.html?article_no=2011010702010660739004




실제로 사회에서 개발자로 직장을 다닌다는건 .. 학생 때와는 다르게 프로다운 마음가짐이 필요합니다.
신입일 때는 내가 못하면 위에서 봐주면서 대신 처리해주지만 갈수록 책임감이 늘어갑니다.
즉, 문제가 주어졌을 때 해결해야한다는 것이죠. 차선책이라도 꼭 만들어야 한다는 겁니다.
가정의 가장일 경우도... 책임감은 날로 늘어가면서 가정을 지키기 위해서는 문제가 있을 때마다 해결해야한다는
압박감이 큽니다. 개발자이건 아니건 문제해결능력이라는건 그사람의 역량과도 직결되는 문제이니 간과해서는 안됩니다.


Posted by SB패밀리



대한민국 개발자의 우울, 자기책임론에서 구조개혁론으로




김국현(IT평론가)   2007/10/01

 

2007년 우리네 개발자의 자화상은 유난히 수척하고 우울하다. 연이어 터져 나오는 개발자 처우에 대한 보도와 칼럼들은 IT를 이공계 기피의 공식 상징으로 만들어 버렸다. 이런…… 별로 낭만적이지 않다. 

어느덧 개발자의 후생(厚生)은 나의 최우선 관심사가 되어 버렸다. 

우리는 누구나 자기가 좋아하는 일을 하는 삶을 꿈꾸고, 또 그 일이 사회에 가져다 주는 가치에 걸맞은 대가를 받기를 바란다. 낭만적 인생의 얼개란 의외로 단순하다. 그렇다면 개발자들은 적어도 자기가 좋아하는 일이 무언지 안다는 면에서는 행복한 이들이다. '알고리즘의 오르가즘', 즉 내 논리가 증명될 때의 기쁨에 끌려 이 바닥에 들어 왔기 때문이다. 허나 이 '손맛' 누구나 맛볼 수는 있지만, 그 대가는 천차만별이다. 스톡옵션과 인센티브 덕에 벤츠를 모는 프로그래머도 있지만, 그 동갑내기는 소위 말하는 SI 막장의 트러블 프로젝트 속에서 요구분석조차 제대로 되지 않은 시스템을 무한 반복적으로 수정하고 있기도 하다. 전자는 한 사람의 개발자가 세상을 흔들 가치의 원천임을 증명한 셈이지만, 동시에 후자는 정부가 정한 단가표로 조달 가능한 부품에 불과함을 증명하고 있다. 

이 차이의 원인은 어디에 있을까? 운이라고 말하면 성의 없는 대답이지만, 노력 탓이라고 말하는 것도 잔인한 기만이다. 지금 개발자들이 겪는 우울은 이 격차에 대한 울분이라기보다, 후자에서 전자로 이어지는 연속된 흐름이 발견되지 않는 구조적 모순에 있다. 닮고 싶은 롤모델도 없고, 괴로운 나날을 지킬 비전도 없다. 그도 그럴 만 하다. 안타깝게도 우리 주위에는 기술의 힘에 의해 기업의 지속 가능성(Sustainability)를 확보한 곳은 찾기 힘들다. 대신 기묘한 다단계의 착취 구조의 잉여 축적으로 지속 가능성을 근근이 유지하는 곳만 즐비하다. 가치를 발휘할 대상을 찾지 못하는 이들이 가치를 발휘할 리 없다. 악순환이다. 그렇기에 대부분의 경우 자기책임론은 무책임한 말이다.

어떻게 하면 좋을까? 가치를 둘러싼 사회의 문제란 결국 경제적 문제다. 그리고 경제적 부조리의 대부분은 수요와 공급의 구조 변화에서 온다. 우리는 이 구조를 간과해 왔다. 이를 알아차린 혹자는 의사나 변호사처럼 이익을 대변할 길드를 형성해야 한다고 말하고, 또 다른 이는 구조적 문제를 해소할 '당'을 만들어야 한다고 농담 같은 진담을 해 오기도 한다. 공급자의 입장에서 공급을 조절하는 구조를 꿈꾸는 기초적 반항심이다. 

그러나 이는 더 본질적 문제를 간과하고 있다. 그 것은 '업', 즉 프랙티스(practice)라는 개념이 완성되는 과정이다. 의사도 변호사도 모두 구조적 절차, 예컨대 선별 과정과 자성 절차를 통해 자신들의 업을 정의하게끔 하고 그 정의에 맞는 수행을 하도록 스스로를 단련하고 있다. 이 것이 구조의 힘이다. 

우리는 스스로를 개발자라고 말하지만, 이는 그냥 운동선수라고 말해 버리는 것과 마찬가지의 뭉툭한 묶음이다. IT라는 산업 역시 산업으로서의 스포츠 전체와 같아서, 어떠한 종목을 선택할지에 따라 이 산업에 참여한 신인의 미래는 크게 달라진다. 인기, 비인기 여부, 그리고 프로 리그의 존재 여부, 여기에 자신의 적성 및 특기, 비전이 더해져서 스포츠인으로서의 인생은 구조 안에서 만들어 지는 것이다. 

이 적응과 선택이 합리적이고 타당한 분기점과 분배구조를 통해 거쳐 가면서 누구는 맨유의 일원으로 또 누구는 마포구 조기축구회의 일원으로 각각 나름의 땀을 흘리게 된다. 이 것이 성숙된 구조를 지닌 산업의 일원에게 주어진 낭만성이다. 가장 인간적이며 원초적인 파이팅 정신을 스포츠에서 찾게 되는 이유는 어쩌면 이 절차적 투명성 덕일지 모른다. 스포츠는 이를 가능하게 하는 구조를 완성했다. 고대 그리스 시절부터. 

우리네 IT에게 결여된 것은 이러한 구조다. 우리는 왜 훌륭한 선수가 되지 못하냐는 질책은 있었지만, 어떠한 종목을 선택하는 것이 바람직한지 귀띔을 듣지 못했다. 그런 일을 태릉선수촌을 만든 정부에 기대해 보면 좋겠지만, IT에게 주어진 정책은 축구가 인기니까 6개월 과정으로 축구 선수를 배출하자는 근시안적인 방책뿐이었다. 그 덕에 98년에 엔터프라이즈 자바를 처음 하던 시절에 받던 '선생님' 대우가, 불과 10년도 안돼 단순 노무직의 신세가 되어 버린다. 더 아이러니한 것은 10년 동안 아무리 훌륭한 축구 스킬을 쌓았어도 이를 알아 주는 이는 없고, 넘치는 축구 선수 지망생 속에 스트라이커는 묻혀 버린다. 오늘 아침 조기축구회에 처음 나온 이도 박지성도 모두 똑같은 과기처 단가표를 받아 든다. 그나마 다행히 박지성은 특급일 것이다. 

더 큰 문제는 야구 선수마저 축구를 해야 하는 상황이다. 유난히 획일적인 사회 덕인지 모르지만, 어느 한 기술이 선택되면 업계 전체에 그 쏠림 현상은 무지막지하고, 여기에는 일종의 종교적 교조주의까지 가세한다. 눈치 보듯 동종 업계의 흐름을 뛰어 넘지 않는 RFP로 발주가 나고, 어느 누구도 새로운 것을 시도하지 않은 채 그저 그런 시스템이 계속 완성된다. 그리고 IT는 점점 새로운 것을 기피하며 혁신과 거리가 멀어진다. 

개발자의 생산성을 비약적으로 향상시킬 방안이 있어도, 그 기술을 쓰는 개발자의 단가가 비싸다는 이유로 기각되곤 한다. 이는 혁신의 상실일뿐더러 기회의 상실이다. ‘보이지 않는 손’의 위업이라 해버리면 그만이지만, 정책이란 이러한 상실을 지키기 위한 것 아니었던가. 

어쩌면 국가나 정부의 정책이 밸런스를 맞추는 일은 애초에 무리일지 모른다. IT에서 일어나는 대부분의 변화는 정책 수행이나 입안 주체가 지닌 능력이나 태도의 문제나 차원을 넘어 초국가적 IT 트렌드의 결과이기 때문이니까. 그러나 아무리 글로벌화로 평평한 세계가 되어도 여전히 국가의 경계가 주는 문화적 경제적 사회적 기회의 차이는 지대하기에, 지렛대가 되어야 할 정책의 몫은 여전하다. 한 국가의 스포츠 정책이 생활 체육보다 엘리트 체육에 치중하는 이유도 이 차이의 가시적 해소를 위함이다. 왜 오프쇼어가 존재하는지, 왜 전세계의 IT 시스템이 여전히 미국발 플랫폼에 의존하고 있는지를 기억해 보자. 아무리 세계가 평평해져도 물리적 IT강국과 그 가치의 흐름은 존재한다. 

한국 내에도 IT에 특화된 수많은 공공 단체들이 있지만 이에 대한 심도 깊은 고찰이 어디에서 이루어지고 있는 지 궁금하다. 예컨대 국가가 나서서 오픈소스를 이야기하지만, 오픈소스가 국내 개발자의 전체적 후생에 어떠한 영향을 미치는지 설명책임이 없다. 정책자 들은 오픈소스가 우리의 미래라고는 하지만, 우리에게는 아직 북구나 북미에서처럼 오픈소스 커미터로 활동하는 일에 대한 직업적 환경이 형성되지 못했다. 글로벌 벤더가 북구나 북미에서처럼 이들을 한국에서 고용하지도 않고, 또 그렇지 않더라도 돈을 받지 않고 연구에 몰두할 수 있는 사회적 안전망을 국가나 학계가 갖추어 주지 않는다. ‘스캔디나비안 객체 지향 학풍’, '핀란드의 기나긴 겨울'과 같은 은유적 여유조차 없는 우리에게 오픈소스는 '소프트웨어는 거저'라는 잘못된 인식의 획득뿐이고, 그 결과 세계에 기여는 안 하면서 가져다 쓰기만 하는 기형적 오픈소스 문화만 남게 되었다. 구조적 문제의 일례다. 

도대체 무엇이 우리의 미래인가? IT 강국이라고 공염불은 하지만 그 실체는 없고, 참여자는 좌절하고 있다. 좋아서 시작은 했지만, 어떻게 하면 가치를 발휘할 수 있는지 알려 주지 않는다. 축구 선수는 늘어났지만 클럽이 없다. 운이 좋아 프로 축구단에 소속되면 다행이지만, 일부 개인에게 돌아간 이 요행을 산업 전체에 바랄 수는 없다. 그렇다면 야구가 있음을 알려야 한다. 올림픽을 열어야 한다. 세계 선수권에 나가야 한다. 새로운 종목에 도전해야 한다. 여자 양궁을 찾아야 한다. 쇼트 트랙을 찾아내야만 한다. 

업계에 참여하는 개개인 모두가 IT의 미래를 날카롭게 읽어 내어 그 길을 내달리고 또 시장까지 열어 줄 수 있는 성과물을 만들어 주기를 바란다면 이는 욕심이다. 우리는 지금껏 그 욕심 속에서 자책해 왔다. 개인이 내달릴 수 있는 구조가 없는 곳에서, 개인이 움직여 주지 않는다 해봐야 아무 일도 일어나지 않는다. 

다행히 구조의 왜곡을 먼저 읽어 내는 이들은 분명 존재한다. 그들은 기업인일수도, 마케터일수도, 에반젤리스트일수도, 블로거일수도, 정책가일수도, 혹은 이 글을 읽는 여러분 일수도 있다. 이 업계의 이 사회의 구조를 바꾸는 일, 우리의 몫이다. 구조 개혁은 어쩌면 길을 먼저 읽어 낸 이들의 책임이다. 미래란 그들이 뜯어 고칠 이 구조의 결과인 것이다. 개인은 구조의 영향을 받지만, 그 구조를 만드는 것은 개인이라는 사실. 이 것이 우리가 지닌 가장 큰 희망이기도 하다. @
 


Posted by SB패밀리

프로그래머로 살아남는 법 / 이만용

출처 : http://maso.zdnet.co.kr/20010407/specplan/article.html?id=128&page=1%C2%A0%C2%A0


이 글은 컴퓨터 프로그래밍을 이미 자기 삶의 중요한 일부분으로 받아들였지만 잠시 주춤하고 있는 사람들과 프로그래머의 길 앞에서그렇게 될 것인가 말 것인가 고민하고 있는 사람들에게 '삶의 과정으로서의 프로그래밍'이라는 관점을 갖고 작성했다. 이를 통해프로그래밍하는 인간의 모습을 돌아보고 프로그래머로서의 인간 에너지를 충전시키는 시간을 제공하고 싶다.  


이만용 (리눅스코리아 CTO ) 2001/04/13  


필자는 이 글을 통해 지난 3-4 년간 프로그래머가 되고 싶어했던 사람들, 이미 직업으로서 프로그래밍을 하고 있다. 현재보다 더나은 프로그래머가 되길 원했던 사람들이 필자에게 보낸 메일에 대한 답장 속에서 했던 이야기. 그리고 하고는 싶었지만 답장 메일로적기에는 너무 길어 적지 못했던 마음속의 말들을 꺼내어 정리하는 시간을 갖게 되었다. 종종 일상의 지겨운 반복 속에서 좌표를잃지 않기 위해 컴퓨터 앞을 떠나 편안하게 사색에 잠길 수 있기를 바라며 이야기를 시작한다.  

원래 창조적인 지적 유희이며 그러해야 한다  
필자에게 왜 프로그래밍을 하고 있냐고 묻는다면, 주저없이 '재미(fun)'라고 답할 것이다. 한 가지 덧붙이자면, 만약프로그래밍보다 더 재미있는 일이 있다고 생각한다면, 역시 주저함 없이 프로그래밍 대신 그 일에 몰두할 것이다. 재미없는 일을억지로 하면서 보내기에는 인생은 너무 짧지 않은가. 여러분이 이미 생계의 족쇄 속에 또는 사회적 위치 속에 결박당해 탈출할 수없는 경우가 아니라면, 그리고 충분히 새로운 선택을 하여 재시도할 수 있는 사람이라면, 다시 한 번 진정으로 자신이 프로그래밍을즐기고 있는지 생각해 보는 시간을 갖기 바란다. 꼭 프로그래밍을 해야 하는 절대절명의 이유란 없다. 앞으로 전개될 글을 읽기전에 마음의 고리를 풀고 편안한 마음으로 자신의 사고가 흐르는 대로 방치하기 바란다.  

꼭 프로그래밍만이 재미있다고 말할 수는 없지 않겠는가. 당연히 재미라고 하는 것이 인간의 다른 모든 행위로부터 프로그래밍을구별해 주는 유일한 요소일 수는 없다. 이 세상에는 프로그래밍 이외에도 이미 사람이 재미를 느낄 수 있도록 해 주는 일이 헤아릴수 없을 정도로 많듯이 말이다. 예전에도 그리고 지금도 수억의 인구가 회화, 악기 연주, 운동 등에서 즐거움을 느끼고 있다. 이활동들은 새로울 것도 없지만, 여전히 재미있는 활동이다. 프로그래밍도 시간이 지남에 따라 훨씬 더 대중화하고 똑 같은 취급을받을 것이다. 하지만 프로그래밍이 똑같이 재미있는 수많은 일 중 그냥 하나라고 말하기에는 너무 극단적이다. 어떤 점에서프로그래밍이 주는 재미가 다른 재미와 같고 또한 다른 것일까.  

프로그래밍은 이미 오랜 시간 동안 인간의 역사 속에서 사람들에게 재미를 제공했던 기존 활동과는 도구적 관점에서 다르다. 여기서컴퓨터라고 하는 20 세기의 놀라운 발명품을 이야기하지 않을 수 없을 것이다. 책, 기관차, 전화와 같은 출판 기술, 증기기관, 통신 기술이 인간 세상을 변화시킨 것처럼 컴퓨터가 현재의 인간 생활을 변화시켰다는 점을 부인할 사람은 없다.  

인간은 그 동안 자신이 발견하거나 발명한 것을 즐기며, 도구를 통해 자신을 다시 변화시켜 왔다. 프로그래밍은 컴퓨터라고 하는도구를 통해 그 안에서 인간의 상상력과 논리적 사고력을 실현해 내는 고급 유희다. 그러나 바로 이전 문장에서 표현했듯이, 인간이지적 노력을 쏟아 지적인 재미를 만들어 내려고 하는 지적 유희라는 점에서는 그 이전의 모든 창조적 지적 유희와 하나도 다르지않다. 여기서 필자는 다르다는 점보다 같다는 점을 강조하고 싶다.  

채 다 배우기도 전에 쏟아져 나오는 프로그래밍 언어, 선택해 보지 못한 메뉴가 아직도 많은데 버전업돼 나오는 통합 개발 환경에치여 살다 보니, 프로그래머인 우리 자신이 인간이 최근 만든 가장 놀라운 발명품을 사용해 가장 재미있는 창조적 지적 활동을 하고있다는 사실을 너무도 쉽게 잊어버리는 모습을 목격할 수 있다. 그리고 현실 속에서는 이러저러한 언어, 도구에 지배받으며 지쳐있는 불쌍한 자신을 쉽게 발견한다.  

하지만 그 어떤 컴퓨터를 사용하든, 그 어떤 프로그래밍 언어나 도구를 사용하든 우리 프로그래머들이 본질적으로는 참 재미있는 일을 하고 있다는 사실을 망각하지 말아야 한다고 말하고 싶다. 그것도 매우 지적인 재미 말이다.  

그러한 자기 만족감이 없이 버틸 수 있는 프로그래머가 있을까. 프로그래밍 언어책을 보다 며칠씩 이해되지 않던 부분이 갑자기 슬슬풀려 나갈 때, 작지만 자기가 예상한 대로 모든 일이 척척 진행돼 나갈 때, 하루 종일 찾지 못했던 버그를 커피 마시다 갑자기찾아냈을 때 느끼는 자신에 대한 대견스러움, 만족감을 느껴보지 않고 어떻게 프로그래머라고 말할 수 있을까. 이런 즐거움은 이성친구, 애인, 가장 가까운 친구에게도 어떤 말로도 전달할 수 없는 매우 개인적인 차원인 것이다. 때로는 자신의 소스 코드와프로그램을 이해하는 지구 반대편의 프로그래머와 더 진한 동질감을 느끼기도 하는 것 또한 프로그래머다.  

자신에 대해 대견스러워하는 마음, 무엇보다 자신이 설계한 대로 컴퓨터가 작동하는 것을 보는 즐거움, 컴퓨터를 통해 자기만의세계가 창조되는 즐거움을 느끼지 못한다면 앞으로 하는 모든 이야기는 별 의미가 없다. 취미로든 직업으로든 왜 프로그래밍을선택했는지 그리고 왜 수많은 책과 읽을거리와 투쟁하고 있는지 자기 확신을 갖자. 아무리 생각해 봐도 프로그래밍은(유일하지는않아도) 꽤 매력적인 고급 활동이다. 재미있는 일을 재미있게 하지 못한다면 그것은 큰 문제가 아닐 수 없다.  


프로그래밍의 본래 의미를 찾는다  
대학생 친구들을 위한 언어 교재를 만들면서 자주 등장하는 외래어 표현을 정리하고 있었다. 그런데 바로프로그램(program)이라는 말 그 자체가 우리에게 시사하는 바가 많다는 사실을 발견했을 때 마치 보물을 발견한 양 즐거워 한적이 있다.  

'program'이라는 단어는 'pro'와 'gram'의 합성어다. 여기서 'pro' 는 '어떤 일을 하기 전에...' 라는'before' 의 의미를 갖고 있으며 'gram'은 '무엇인가를 쓰다' 즉 'write'의 의미를 갖고 있다. 따라서program은 쓰거나 만드는 행위라기보다 '쓰기 전에 하는 일' 즉 계획적인 사고 행위를 가리킨다.  

현실적으로 우리가 우리 자신을 설계자나 기획자라고 생각할 수 있는 여유는 거의 없는 것 같다. 우리가 매일 확인할 수 있는자신의 모습은 특정 언어나 특정 제품, 특정 프로젝트의 노예로 전락해 있는 초라한 모습이지 않은가. 프로그래밍은 어느 새 밤을세며 코딩하는 중노동과 동일시돼 버렸다. 그래서인지 요즘 미국이나 한국 젊은이를 대상으로 한 설문조사를 보면 그래픽 디자이너가되고 싶다는 답변이 프로그래머가 되고 싶다는 답변보다 월등히 많다고 한다. 이미 프로그래머란 컴퓨터 분야 중 가장 선호하는직업이 아닌 것이다.  

프로그래밍 작업의 특성이 무엇을 이뤄내기 전에 먼저 머리 속에서 설계하는 정신적 유희라는 본질적인 의미를 자꾸만 잊게 하는 그무엇을 갖고 있다고도 볼 수 있다. 프로그래머를 계속해서 괴롭힐 동전의 양면적 특성이 존재하는 것이다. 계획과 함께 실천이있어야만 완성되는 것이 프로그래밍의 중요한 특성이다.  

설계한다는 점에서 프로그래머는 건축가와 유사한 점이 많다. 아무리 작은 프로그램을 만들지라도 프로그래머의 머리 속에는 이미 어느정도의 프로그램 진행 과정에 대한 설계가 먼저 이뤄진다. 그러나 건축가가 실제 건물을 만들지는 않는다. 건물을 직접 만드는 일은건축 노동자들의 몫이다. 이렇게 건축이라는 영역에서 건물을 설계하는 일과 짓는 일은 완벽히 분리돼 있다. 그러나 프로그래머는결국 자기 손으로 건물까지 지어야 한다는 점에서 크게 다르다. 상상만 하고 코드를 입력해 실행 프로그램을 만들어내지 않으면 아무것도 하지 않은 것과 같다. 그런 점에서 프로그래머는 어떻게 보면 화가나 조각가에 더 가깝다. 자기 내면에 비춰진 이미지에서그치는 것이 아니라 캔버스나 대리석에 실체를 구현해야 하며, 생각하는 주체와 그것을 실현해 내는 주체가 같다.  

프로그래머인 우리가 결국 C, C++, 자바 등 특정 언어를 배워 우리의 아이디어를 실행 가능한 소프트웨어로 만들어내야 한다는사실은 분명하다. 그러나 그렇다고 해서 프로그래밍이 언어를 잘 구사하는 것만으로 끝날 일은 아니다. 그림만 잘 그린다고 해서화가라고 말하지 않는 것과 같다.  

시작은 언어 대신 사고력 부터  
그렇다 해도 여전히 훌륭한 프로그래머가 되기 위한 시작은 언어가 아니라 사고 능력이라는 점을 지겹도록 강조하고 싶다. 프로그래밍언어책을 붙들고 공부한다고 해서 자연스럽게 프로그래밍을 잘 하게 되는 경우는 없다. 만약 그랬다면 이 글을 쓰고 있어야 할이유조차 없었을 것이다. 언어 공부가 자연스럽게 자신을 프로그래머로 만들어 주지는 않는다. 이 사실은 독자 여러분이나 필자나말하지 않아도 알고 있다.  

또한 그렇다고 해서 무조건 명상에 잠긴다거나 순서도 그리는 일을 다 마치고 나서 언어를 배우고 프로그래밍하는 것도 아니다. 원래생각하는 과정과 도구를 사용해 실현하는 과정이 떨어져 있는 것도 아니다. 인간은 자유로운 상태에서 생각하며 도구를 사용하고,도구를 사용하며 생각한다.  

인간의 놀라운 점 중 하나는 도구를 사용함으로써 자신의 사고 능력을 발전시키고 그 발전된 사고 능력으로 도구를 개선하거나 새로운도구를 만들어 가는 무한 사이클을 이어간다는 것이다. 여러 가지 관점에서 설명할 수 있겠지만 필자가 강조하고자 하는 면은 다음과같다. 생각하지 않으면서 언어를 사용하고 코딩하는 것은 계속 제자리를 맴도는 것과 같다. 생각없는 코딩은 생각하는 사람의 사고능력에 아무런 영향도 미치지 않는다. 아니, 오히려 악영향을 미치기도 한다. 생각없는 반복적 행동은 오히려 생각을 굳게 만들어반복적 행동을 또 다시 만들어 낼 가능성이 높다. 극단적으로 말해서 생각없이 코딩하느니 너무 지겨워서 다시 생각을 하고 싶을정도로 빈둥대거나 잠을 푹 자두는 것이 현명한 일이다(필자는 실제로 그렇게 하고 있다).  

인간의 다른 지적 노동과 마찬가지로 현명한 반복만이 현명함을 낳는다. 학문이라는 것이 마치 강을 거슬러 올라가는 것과 같다는옛말이 있는데, 사실 이보다 더 끔찍하다고 생각한다. 아무 생각없는 반복은 또 다른 생각없는 반복만을 낳을 뿐이며, 현명하게반복할 수 있다는 사실을 잊게 만든다. 자연스럽게 어떻게 프로그래밍을 배워나가야 하는지 얘기를 이어나가고자 한다.  


프로그래밍, 어떻게 배워나가야 하나  
'닭이 먼저냐 달걀이 먼저냐' 하는 전통적인 질문이 여기서도 그대로 적용된다. 똑똑해지려면 똑똑하게 배워야 한다. 현명해지려면 현명하게 배워야 한다.  

어떻게 똑똑하게 배울 수 있는가  
반대로 설명하는 것이 좋겠다. 프로그래밍은 매우 지적인 유희라고 앞서 몇 번이고 반복한 바 있다. 현재 대부분의 프로그래머지망생이 학습하는 방법은 크게 다르지 않다. 학습이 매우 단순 반복적이다. 단순 반복에 의해 지적인 성장이 이뤄진다고생각하는가. 게다가 학습 과정이 지겹기 때문에 유희적인 측면도 이미 상실한 지 오래다. 무엇보다도 몇 번의 반복 속에 자기자신을 지치게 만들면 이미 게임은 끝난 것이다(물론 꾹 참고 꾸준히 하면 언젠가 길이 보일 것이라고 얘기할 수도 있다. 그러나이렇게 말해 버리면 역시 이 글의 의미가 완전히 사라진다).  

똑같은 책, 똑같은 도구를 갖고 배우는데 서로 다른 결과물이 나온다면, 조금만 논리적으로 생각해 봐도 차이를 결정짓는 것은 책이나 도구가 아니라 다른 곳에 있다는 결론을 내리게 된다.  

여기서 프로그래밍 학습에 있어 가장 중요한 부분이라고 말할 수 있는 언어 선택 및 학습 과정에 대하여 짚고 넘어가겠다. 먼저거의 대부분 첫 번째 언어를 잘못 선택함으로써 프로그래밍의 본격적인 재미를 느끼기도 전에 탈락한다. C/C++/자바는 원래부터만만한 언어가 아니다. 현실적으로 많이 사용하고 있는 이 언어를 많은 사람들이 배우기 어렵다고 말하는데 그 대답은 당연하다. 이전문언어는 매우 다양한 일을 해낼 수 있는 다목적 언어이며 전문 프로그래머의 경험 속에서 진화해 온 언어이기 때문에 어렵다.그냥 열렬한 컴퓨터 사용자였다가 갑자기 자기 손으로 프로그램을 만들고 싶다고 해서 제일 먼저 덤빈 언어가 C, C++, 자바와같은 전문 언어라면 여러분은 열 명 중 여덞, 아홉은 탈락할 것이다.  

필자 나이의 다른 프로그래머와 마찬가지로 필자의 첫 번째 언어는 베이직이었다. 필자는 아직도 이 언어에 대한 향수를 갖고 있을정도로 좋아한다. 이제 생각해 보니 행 번호 개념과 GOTO 문이 유치하게 느껴질 정도로 까마득하지만, 사용자에서 프로그래머가되기 위한 첫 번째 단계에서는 매우 유용한 중간 단계라고 생각한다. 베이직은 필자에게 인간의 논리가 아니라 컴퓨터의 논리입장(물론 이것도 창조한 사람이 만들어낸 것이지만)에 서서 자연스럽게 프로그래밍하는 것을 가르쳐 주었다. 지금은 전혀 사용하지않지만 매우 중요한 언어임에 틀림없다.  


단순 조급증에서 벗어나야 한다  
프로그래머가 되고 싶어하는 수많은 사람을 처음부터 확실하게 걸러내 준 악습 중 하나는 프로그래머가 되려면 마치 C, C++,자바 중 하나로 꼭 시작해야 한다는 강박 관념이다. 사람들의 책꽂이에는 최소 2~3 권의 C/C++/자바 책이 꽂혀 있다. 모두1/3도 보지 않은 채 방치되고 있을 것이다. 바이블에 해당하는 몇 개의 책을 구입했다가 포기하고 결국에는 '며칠 내에완성하기', '그냥 따라하기'라는 유혹적인 제목의 책을 마지막에 구입한다. 하지만 '21 일 완성하기'를 21일 안에 끝내는사람은 거의 보지 못했다. 원래 어려운 것을 쉽게 설명하는 일은 더 어렵다.  

현실에서 가장 널리 사용하고 있는 매우 현실적인 언어가 C, C++, 자바이기 때문에 처음에 언어를 배울 때부터 이 언어로시작하면 뭔가 큰 이득이 될 것이라고 생각하는 것이 바로 앞서 표현한 단순 조급증이다. 물론 뭔가에 빨리 도달하고 싶겠지만생각처럼 되지 않는다. 오히려 꽃도 피워보지 못하고 초반전에서 프로그래머의 세계로부터 탈락하는 지름길을 선택하게 된다.  

꿋꿋하게 버텨 살아남은 한두 명도 결국에는 잘못된 믿음의 피해자가 된다. 그들은 어렵게 어렵게 배운 C, C++, 자바로부터벗어나려고 하지 않는다. 마치 이 세상에 그 세 가지 언어만 있는 것처럼 살아가는데, 사실 살아남기는 했어도 어처구니없게도언어라는 도구의 노예가 되어 버리고 만다. 이들의 프로그래머적 성장은 이미 끝나버렸다.  

상처받은 사람들을 위한 언어, 파이썬  
물론 사회적으로 준비가 잘 되어 있는 것은 아니다. 서점에 가봐도 C와 C 유사 언어 외에 다른 언어에 대한 훌륭한 책이 많지도않다. 여러 가지 언어를 잘 구사하는 훌륭한 프로그래머도 많지 않고 강사는 거의 없다고 봐도 무방하다. 현재 훌륭한 정보의대부분은 인터넷에 뿔뿔이 흩어져 있고 대부분 영어로 작성돼 있는 것이 현실이다.  

이런 상황 속에서도 지금 막 프로그래머가 되고 싶어하는 사람들을 위한 첫 번째 언어로서, 그리고 기존 언어를 모두 맛보고,패배감을 가진 사람들이 자신을 재정비하고 다시 프로그래밍의 즐거움 속으로 빠져들기 위한 재충전용 언어로 '파이썬'이라는 언어를권하고 있다.  

아직 첫 번째 교육 언어로 채택하기에는 훌륭한 서적과 과정이 나와 있지 않은 상황이어서 필자가 처음 시작했던 베이직보다는 어려울것이다. 그러나 다른 언어에 의해 상처받은 사람들을 치유하는 치료용 언어로서는 상당한 효과를 볼 수 있다. 이 언어를 통해언어가 중요한 것이 아니라 인간의 사고력을 풍부하게 발휘하는 것이 중요하다는 사실을 배울 수 있다.  

여러분이 오히려 컴퓨터 언어를 단계적으로 여러 가지 배워감에 따라 자신이 진정 원했던 결과를 더 빠르게 그리고 더 견고하게 세워나갈 수 있다는 사실을 느끼길 바란다. 언어는 결국 교체 가능한 도구라는 사실을 알게 되고, 여러분의 필요에 따라 새롭게 배우고구사할 수 있다는 자세를 갖추는 것이 중요하다. 또한 2~3 가지 언어를 구사할 수 있어야 한 가지 언어만 알았을 때보다 훨씬더 심도깊게 언어를 사용할 수 있다는 사실도 깨닫게 될 것이다.  


다양한 오픈소스의 세계  
컴퓨터 언어를 배우는 플랫폼도 중요하다. 필자로 하여금 C, C++, 자바 이외에도 이 세상에는 수많은 언어가 있으며 수많은새로운 아이디어가 있다는 사실을 일깨워 준 것이 바로 리눅스와 오픈소스 세계다. 오픈소스는 필자에게 프로그래머로서의 새로운의지를 수혈해 준 주역이다. 여기서 파이썬을 포함해 LISP, 펄, Ada 등등 많은 언어를 접할 수 있었으며, 여러 번의외도(?)를 통해 오히려 이미 알고 있던 C 언어를 훨씬 더 잘 이해하고 어디에 어떻게 적절하게 사용해야 할 지 알게 되었다.무엇보다 각 언어마다 나름의 이유가 있으며 그 창조자의 생각을 어느 정도 이해할 수 있다는 즐거움도 만끽할 수 있었다. 다양한욕구를 가지고 있는 독자라면 리눅스에서 다양한 오픈 소스 언어를 만나 보기 바란다. 그리고 여러분이 눈길을 주기를 기다리는어마어마한 분량의 소스 코드가 널려 있다. 또한 멋진 것은 매우 초보적인 소스 코드부터 매우 전문적인 소스 코드까지 선택의 폭이넓다는 것이다.  

한편, 윈도우 플랫폼에서는 좋으나 싫으나 마이크로소프트의 제품 정책에 따를 수밖에 없으며(그나마 예외는 자바 정도) 따라서제품의 노예가 되어버리기 쉽다. 예를 들어 현재 프로그래머 사이에 논란이 되고 있는 C# 이라는 언어는 새롭게 출현해야 할정당한 논리적 이유없이 자바와의 전쟁 속에서 나온 사생아라는 지적이 나오고 있다. 직업적 프로그래머라면 새로운 언어와 규칙을배워야 하는 수고를 마다해서는 안되겠지만, 프로그래머가 되어 볼까 생각하는 사람들에게는 짜증나는 현실이다.  

조금이나마 다행스러운 것은 오픈소스 진영이 매우 성숙해 훌륭한 소프트웨어의 대부분이 윈도우와 매킨토시 등 리눅스/유닉스가 아닌플랫폼에서도 동작한다는 사실이다. 여러 플랫폼에서 동작하는 멀티 플랫폼 언어나 도구를 사용하는 것도 현명한 선택 중 하나다.  

웹 프로그래밍 언어에만 집착하지 말자  
마지막으로 언어 선택에 있어 웹 프로그래밍과 관련한 PHP, ASP, JSP에 대한 의견을 개진하고자 한다. 결과를 즉시 확인할수 있으며, 현재 유행하는 개발 영역의 언어이기 때문에 많은 사람들이 쉽게 시작하고 있지만, 이 언어들은 모두 실용 언어로서인간에게 프로그래밍하는 더 좋은 방법을 알려주지는 못한다. 따라서 전문 프로그래머가 되려면 이 언어에만 집착해선 안된다. 또한프로그래밍 본연의 지적 유희를 즐기려는 취미 프로그래머도 역시 이 언어에만 집착해선 안된다. 실전의 전문 프로그래머는 이들의한계를 분명히 인식하면서 사용한다. 실용 언어와 함께 일반 언어도 동시에 익혀 나감으로써 프로그래밍 사고력과 실용성을 모두성취할 수 있기를 바란다.  


직업적 프로그래머가 되고 나면  
프로그래밍이란 생계와 결부되는 매우 실용적인 영역임에도 불구하고 의도적으로 이 이야기를 지금까지 피해 왔다. 직업으로프로그래밍을 하고 있는 사람은 이 글을 읽으며 무슨 지적 유희냐고 화를 내고 있을 지 모른다. 실전에 들어가면 프로그래머의생활이란 다음과 크게 다르지 않다.  

* 자바 프로그래머로 입사했는데(사실 이 말 자체가 우습다. 프로그래밍 언어 중 자바도 구사할 수 있는 프로그래머라고 표현해야한다) 실제 프로젝트는 별로 사용해 본 적 없는 C++로 해야 한다고 팀장이 전달한다. 자기가 잘 모르는 언어로 프로그래밍을해야 한다는 부담감 때문에 매일 짜증내면서 어쩔 수 없이 새롭게 책을 구입해 쫓기듯 학습한다.  

* 쉬엄쉬엄 컴퓨터 앞에 앉아 이런 생각 저런 생각을 하면서 코드만 작성하고 만들어내기만 하면 되는 줄 알았는데, 거의 대부분의시간을 보고서와 설명서를 쓰는 데 허비하고 있다. 과연 내가 프로그래밍을 하고 있는지 문서 작성을 하고 있는지 한탄스러울 때가많다.  

* 열심히 만들었더니 주문한 고객의 마음이 또 바뀌어 모든 부분을 일일이 다 고쳐야 하는 일이 다반사다. 창조적이라기 보다는 코딩 막노동(?)이라는 느낌이 들면서 자신이 한심하게 느껴지기 시작한다.  

* 거의 대부분의 시간을 버그 잡느라고 머리털 빠지고 있다. 재미없는 디버거와 함께 하는 시간이 코드 짜는 시간보다 월등히 많다.  

이런 현실적인 문제들을 하나씩 짚어 가기 전에 필자는 독자 여러분에게 이 세상에 재미를 느끼게 해 주는 수많은 일들이 있는데프로그래밍을 자기 직업으로 삼은 이유가 무엇이냐고 우선 반문하고 싶다. 마음속으로 자기만의 답을 생각해 보고 앞서 나열한 네가지 문제를 하나씩 다뤄보자.  


새로운 언어를 적극 받아들이자  
번 문제를 살펴보자. 회사나 팀장의 요구가 부당하다고 생각할 지 모르지만, 자신이 모르는 다른 언어로 프로그래밍해야 한다는요구가 무조건적으로 틀린 것은 아니다. 사실 여러분이 직업적 프로그래머로서 직장 상사나 팀장에게 '나는 이 언어밖에못합니다'라고 말하는 것은 프로그래머로서의 자신의 진짜 가치를 고백하는 것이나 다름없다. 굳이 사회적으로 통용되는 표현을쓰자면, 한 가지 언어만을 전문으로 구사할 수 있다고 말하는 사람은 그 언어만 다룰 수 있는 기능사일 뿐이다. 기술자라면, 아니진짜로 프로그래머라면 새로운 언어를 배워야 한다는 것이 짜증나는 일이라고 단언해서는 안된다. 새로운 언어를 배워 나가는 것은전문 프로그래머의 일상 업무이다.  

물론 지금 당장은 답답할 지 모른다. 그러나 필자의 논지에 수긍한다면 어떤 언어든 자기가 구사할 줄 아는 언어의 전부가 아니라그 중 하나일 뿐이어야 한다. 팀장의 요구가 없다 하더라도 사실 유행에 따라 어쩔 수 없이 또 다시 끌려가야 하는 경우도 있지않은가. 원래부터 피할 수 없는 일이므로 적극적으로 받아들이자.  

문서화는 결코 어려운 일이 아니다  
번 문제를 살펴보겠다. 필자도 보고서를 쓰거나 설명서를 쓰는 작업은 태생적으로 싫어한다. 그러나 보고서나 설명서를 쓰는 작업자체가 프로그래머의 몫이 아니거나 또는 무가치한 일로 보는 입장에는 동의할 수 없다. 물론 형식화한 보고서, 설명서를 쓰는 것은매우 지겹고 화나는 일이다.  

보고서와 설명서를 쓰는데 많은 시간이 걸리는 이유는 두 가지를 들 수 있다. 원래 문서화 작업이라고 하는 것이 생각보다 시간이많이 걸리는 작업이다. 우리의 머리 속에 있는 것을 글로 표현한다는 것이 쉽지 않다는 사실은 어렸을 때부터 독후감 쓰는 일이쉽지 않다는 경험으로부터 잘 알고 있을 것이다. 글로 표현한다는 것은 자유롭게 흘러가는 생각을 그대로 반영하는 것이 아니라 한번 더 숙고해 체계화하는 과정이기 때문이다(필자 또한 지금 이 원고 쓰는 일을 흔쾌히 승낙해 놓고서는 얼마나 후회하는지모른다).  

그러나 무엇보다도 자신이 글을 쓰는 일에 익숙하지 않다고 스스로를 묶어 버림으로써 문서 작업을 싫어하고 집중할 수 없게 되는수도 있다. 자기 최면을 통해 집중하지 않음으로써 여러분은 자기가 싫어하는 일에 더 많은 시간을 할애할 수밖에 없고 그 만큼여러분이 원하는 작업에 필요한 시간을 허비하고 있다.  
리눅스나 오픈소스라고 해서 마냥 코딩만 하고 문서화는 전혀 안한다고 생각하면 오산이다. 최소한의 README, 잘 만들어진문서가 없는 오픈소스 소프트웨어는 초보 프로그래머의 작품일 뿐이다. 이미 수준 높은 품질의 아파치, 삼바, 리눅스 커널을 보면상당히 친절한, 하지만 작성한 사람 입장에서는 많은 노력을 들인 문서들이 포함돼 있다는 사실을 알게 될 것이다.  

문서화 또한 현명한 대처가 필요하다. 막무가내로 불필요한 분량의 문서를 요구하는 팀조직이 있다면 매우 고루한 조직임에 분명할것이다. 이러한 조직에 대해 말할 수 있는 해결책은 없다. 그 조직은 여러분이 선택한 것이다. 너무 불합리한 경우가 아니라면,문서화 작업을 소프트웨어 디자인의 일부로 여기는 능동적인 자세가 필요하다.  
코딩을 할 때 소스 코드에 주석(comment)을 넣지 않는 것은 전문 프로그래머로서의 자질이 없음을 단적으로 보여 주는것이므로 주의하자. 직업적 프로그래머라면 어떤 일이 있어도 소스 코드는 주석으로 시작해서 주석으로 끝나야 한다.  

문서화란 어떻게 보면 그렇게 어려운 것도 아니며 프로그래밍의 필수 과정이기도 하다. 기본적으로 소스 코드의 주석, README,INSTALL, 그리고 TODO(앞으로 할 일), 각 버전간의 변경 사항을 적는 Changes 문서는 모든 문서화의 기초가된다. 아직 직업 프로그래머로 취업하지 않는 예비 프로그래머는 지금부터라도 이를 습관화하기 바란다.  
많은 사람들이 오해하고 있는 것을 하나 지적하고자 한다. 대부분 프로그래밍을 코딩에 쏟은 시간만 갖고 평가하려는 경향이 있다.그러나 앞서 'program'의 어원을 알아보면서 확인한 것처럼, 프로그래밍에서 가장 중요한 것은 계획이다. 계획하고 기획한것을 좀 더 구체적인 방법으로 설계하고 언어를 통해 구현하고 중간 과정을 기술하는 모든 행위가 프로그래밍이다.  


'간략한' 프로그램을 위해 노력하자  
번 문제로 넘어가겠다. 일단 계획이 서면 거침없이 코드를 작성하고 고치지 않을 것 같지만 몇 명의 천재적인 프로그래머를제외하고(실제로 그런 사람이 있는지 궁금하다. 자기가 수없이 반복하면서 얻은 경험에 의지해 거침없이 하는 것은 아닐까?) 거의모든 프로그래머는 그런 식으로 프로그래밍하지 않으며 할 수도 없다. 열심히 프로그래밍했다고 생각했는데 일 년이 지나 소스 코드개수와 줄 수를 세 보고나면 자괴감에 빠질지도 모른다.. 실제로 우리는 끝없이 고치고 고치고 또 고친다. 그러면서 소프트웨어가견고해 지는 것이다.  

그리고 현실 세계에서 고객의 요구는 첫 번째로 중요하다. 그들의 요구가 변화하는 것은 당연하다. 훌륭한 프로그래머는 고객이처음부터 정확한 요구 사항을 제시하도록 유도하고 변화의 폭이 제어할 수 있는 범위 안에 들 수 있도록 잘 안내한다.  
소프트웨어의 기능을 잘 구분하고 반복적인 패턴을 함수/라이브러리/모듈화하지 못하는 초보 프로그래머는 똑같은 소스 코드를 여기 저기 복사해서 쓰게 되는데, 이 때는 소프트웨어를 고치는 일이 곤역스러울 수밖에 없다.  

전문 프로그래머라면 반복적인 패턴을 훨씬 더 많이 찾아내고 압축하는 기술을 가꿔 나가야 한다. 다시 한 번 말하지만 반복적인경험에서는 얻을 것이 별로 없다. 그 수많은 경험 중에서 문제 해결을 위해 고민한 시간만이 소중한 경험이다.  
고객의 변덕에 따라 짜증이 날 정도로 많이 고쳐야 한다면, 그것은 오히려 여러분에게 더 많은 경험과 사고가 필요하다는 증거이다. 같은 일을 하더라도 지난번보다는 더욱 더 간략하게 프로그램을 작성할 수 있도록 노력하라.  

디버깅은 불필요한 일이 아니다  
번 문제를 생각해 보자. 우리의 예상과 달리 프로그래밍 중에서, 특히 프로그래밍의 일부분인 코딩 중에 새로운 코드를 만들어 내는시간보다는 기존의 코드를 개선하거나 잘못된 코드를 찾아내는 일에 절대적으로 많은 시간을 쏟는다고 한다.  

필자의 경우도 예외는 아니었다. 그러나 경험을 토대로 스타일을 바꿔나가기 시작했다. 필자가 제일 많은 시간을 쏟는 부분은 자료수집과 연습 코드 부분이다. 필자의 경우에는 무조건 책이나 웹을 통해 관련 자료를 수집하고 재빨리 훑어 내려간다. 다 이해하지못해도 상관없다는 듯이 읽어 내려간다. 특히 요즘은 노하우보다 노웨어가더 중요하다고 말하지 않는가. 이미 많은 문제의 일부분을다른 사람이 해결했을 가능성이 높다. 이를 반복할 필요는 없다. 현 시대에서 요구하고 있는 프로그래머의 자질 중 하나는 처음부터다시 만드는 것이 아니라, 기존의 것을 취사 선택해 창의적으로 결합시키는 능력이다.  

그 다음에는 짧은 연습 코드를 많이 작성한다. 핵심적인 부분에 대한 연습 코드를 몇 번 작성하다 보면 프로그램의 절반이 끝났다고해도 과언이 아니다. 개인적으로 자료 수집과 연습 코드, 특히 연습 코드에 신경을 많이 쓰는데 이렇게 함으로써 프로그래밍과정에서 절대 빠질 수 없는 디버깅(debugging)을 최대한 피할 수 있다고 생각하기 때문이다.  

하지만 어떤 식으로든 디버깅 과정을 피할 수 있다고 생각하지 말라. 사실 버그를 얼마나 빨리 잡는가, 그 짜증나는 시간을 어떻게빨리 마칠 수 있는가는 그가 얼마나 유능한 프로그래머인지 판단할 수 있도록 해 주는 잣대이다. 디버깅이 마치 불필요한 과정이라고생각하지 말았으면 한다. 여러분이 만든 버그야 어떻게 잘 피할 수 있을 지 몰라도 실전에서는 남이 만들어낸 버그를 찾아야 할때가 많다. 그런데 남이 만들어낸 버그를 잘 찾는 사람이란 결국 알고 보면 자기 자신도 똑같은 버그를 만들어 보았고 고통스러운시간을 통해 버그를 찾아낸 경험이 많은 사람이다.  

디버깅에서 중요한 자세는 절대 짜증내지 말고, 적군을 무찌르겠다는 식의 투지를 갖고 단시간 안에 돌파하는 것이다. 만약 한 가지방법이 실패했다면, 잠시 먼 발치에서 새로운 구상을 한 뒤, 다시 전투적으로 임한다. 지루하게 디버깅을 하면 시간도 많이 걸리고정신도 피폐해진다.  

결론적으로 정도의 차이가 있을 뿐, 여러분이 현실 세계에서 당면하고 있는 모든 문제는 피해야 할 어떤 일이 아니라 사실프로그래밍이라고 하는 전체 과정에 원래부터 속해 있던 일부라는 사실을 인식하고 이에 대해 짜증을 내는 수동적인 방식이 아니라 좀더 현명하게 그리고 적극적으로 자기만의 해결책을 찾아나가길 기대하겠다.  


몇 가지 실천안  
다음 실천안은 여러분이 좀 더 프로그래밍을 즐길 수 있고 직업적으로도 유능함을 발휘할 수 있게 되길 바라며 마음속에 떠도는 생각을 아주 간략하게 정리해 본 것이다.  

◆ 프로그래밍이란 절대 코딩이 아니다. 먼저 생각하고 만든 것을 정리하고 문제점을 해결해 나가는 모든 과정이 프로그래밍이다. 이 점을 자기 자신에게 충분히 납득시켜야 한다. 코딩은 프로그래밍의 일부이다.  
◆ 각 언어는 모두 나름의 탄생 이유가 있으며 그 언어를 만든 사람의 아이디어가 담겨 있다. 언어를 먼저 선택하려 하지 말라. 유능한 프로그래머는 절대 한 가지 언어에 집착하지 않는다.  
◆ 언어를 처음 배울 때에는 그에 걸맞게 쉬운 언어부터 시작하라. 실전에서 사용하는 언어를 먼저 배워두면 더 이득이 될 것이라고생각하지 말라. 전문 프로그래머가 되려면 최소한 세 개 이상의 언어를 익혀야 한다. 물론 세 가지 언어를 똑같이 잘 할 필요는없다. 자기 주 종목 언어를 갖지 말라는 말이 아니다.  
◆ 책을 다 읽고 나서야 프로그래밍할 수 있다고 생각하지 말고 배운 만큼만 갖고도 연습 코드를 작성할 수 있어야 한다.  
◆ 언어 그 자체는 여러분의 상상력을 키워주지 않는다. 상상력은 여러분 스스로 인생의 모든 영역에서 듣고 배우면서 채워야 한다.언어는 상상력을 실현할 도구만 제공할 뿐이다. 과학과 수학에 관심을 가져 보라(그렇다고 해서 A 등급을 맞을 만큼 잘 할 필요는없다).  
◆ 주석 및 문서화 버릇을 들이자. 프로그래밍의 귀찮은 일부가 아니라 매우 중요한 핵심 부분이다.  
◆ 언어책이 줄 수 있는 지식의 양은 딱 그 만큼이다. 여러분의 상상력과 프로그래밍 능력을 살찌워주는 것은 다른 사람, 다른프로그래머다. 적극적으로 프로그래밍 사용자 모임 또는 뉴스그룹에 참여해 남을 돕고 남으로부터 도움을 받는 것이 자기 계발의원천이다.  
◆ 자기가 습득한 지식은 자신만이 볼 수 있는 형태든 아니면 홈페이지를 통해 누구나 볼 수 있는 형태든 상관없이 정리하는 습관을갖자. 무엇이든 막상 글로 적으면 자신이 얼마나 피상적으로 알고 있는지 각성하게 되고 지식을 좀 더 견고하게 만들게 된다.  
◆ 현실은 현실이다. 영어를 잘 못하고 두려워하는 사람이 최고의 프로그래머가 되기는 거의 불가능하다. 여러분이 한국어만 하면한국 프로그래머의 지식만 습득할 수 있을 뿐이다. 영어를 두려워하지 않는다면, 그 대가는 전세계 프로그래머의 지식 습득이된다(영어를 잘 하는 방법은 영어를 잘 하는 사람에게 물어보라).  

아무튼 여러분이 프로그래밍의 본질을 재확인하고 프로그래밍하는 그 과정을 즐길 수 있는 사람이 될 수 있기를 바라며 글을 마친다. 

출처 : Tong - I제로I님의 알아두면 좋은 자료통

Posted by SB패밀리

개발자 이력서 10계명




#1: 보유 기능 목록을 제일 앞에 올리라
고용 담당자는 회사가 찾고 있는 기능을 보유하고 있는지 알고 싶어 한다. 물론 "경력" 란에 구직자의 보유 경력이 잘 나오겠지만, 이력서 상단에 "보유 기능" 란을 넣으면 자연스럽게 그 부분을 제일 먼저 보게 된다. 

당연히 그런 이력서를 고르기가 더 쉽다. 동시에 그렇게 하지 않았다면 고용 담당자들이 놓쳐버렸을 수 있는 기능에 관심을 가지게 한다는 장점도 있다. 최소한 고용 담당자는 그 보유 기능 목록을 보게는 된다.

#2: 눈길을 끄는 방식으로 경력을 소개하라
일자리를 구하는 대부분의 개발자들은 데이터 중심형 웹 사이트나 데스크톱 애플리케이션을 만든 적이 있다. 따라서 이력서에 그런 일반적인 예를 잔뜩 써 넣는 것은 별로 눈길을 끌지 못한다. 장래의 고용주가 관심을 가지는 것은 독특한 무언가가 있는 경력, 즉 단순히 기본적인 수준의 프로그래밍 작업을 한 것이 아님을 보여주는 경력이다. 

독특한 제약 조건이 적용되는 작업을 했거나 트랜잭션이 많이 발생하거나 무장애 실행을 요구하는 환경에서 일한 경력은 이력서를 보는 사람에게 아주 좋은 인상을 준다. 즉, 자신의 경력이 남과 다르다는 것을 보여주어야 다른 사람이 그를 남다른 사람으로 보게 된다.

#3: 문법, 철자 및 기타 일반적인 실수를 샅샅이 찾아내어 고치라
고용 업무를 담당하는 동안 필자는 이력서에서 온갖 종류의 문법 오류나 철자 오류를 보았다. 가장 황당했던 경우 중 하나는 자기가 졸업한 대학교의 철자를 잘못 쓴 경우였다.

이력서에는 몇 가지 독특한 문법적인 규칙이 관련되며, 특히 소프트웨어 개발 작업에는 약어나 철자가 특이한 단어들이 관련되는 경우가 많다. 하지만 어떤 경우에도 변명의 여지가 없다. 철자나 문법상으로 실수가 없는지 확인해야 한다. 이 점은 필자가 읽어 본 모든 이력서 관련 지침에 빠지지 않고 나오며, 분명히 강조할 가치가 있다.

#4: 학력은 고려 대상이지만 중요하지는 않다
프로그래밍 구직 시장에 이제 막 발을 들여 놓은 사람이나 아주 전문적인 자리를 얻기 위해 이력서를 쓰는 것이 아닌 한 학력은 별로 중요하지 않다. 물론, 이력서에 학력이 빠질 수는 없지만 제일 마지막에 넣는 것이 좋다. 

학력에 대해 알아야 하거나 알 필요가 있는 고용 담당자라면 학력 부분까지 읽을 것이고, 그 외의 사람들은 학력을 보느라 시간을 허비할 필요가 없다. 프로그래밍 계통은 변화가 너무 심하기 때문에 7년쯤 뒤에는 (수학이나 "순수" 컴퓨터 공학과 같은 "원론적인" 과목 이외에는) 대부분의 학과목과 자격증은 현재의 실제 업무와 거의 관계가 없다.

#5: 빨리 본론으로 들어가라
전통적인 이력서 형식에는 개발 담당자가 볼 때 필요하지 않은 정보가 많이 포함되어 있다. 예를 들면 요약 부분이 그런 정보이며 아마도 목표 부분도 그렇게 볼 수 있을 것이다. 

사실 이력서보다 더 간단한 내용으로 프로그래밍 경력을 표현하는 요약을 쓸 수 있는 방법은 없다. 대부분의 요약 항목이 아무 쓸모없는 정보로 보이는 이유가 바로 그것이다. 예를 들어 주요 기능을 기록한 부분 앞에 붙어 있는 "10년 개발 경력의 노련한 프로그래머"라는 표현이 무슨 의미가 있겠는가? 고맙지만, 없으면 더 고맙겠다.

목표는 (항상은 아니지만) 쓸모 없는 경우가 많다. 전직하려는 경우라면 목표는 고용 담당자가 당신의 보유 기능과 경력을 기준으로 당신을 분류하지 못하게 하는 좋은 방법이 될 수 있다. 

하지만 선임 개발자 자리로 옮기려고 하는 중급 프로그래머는 목표를 생략해도 무방하다. 소프트웨어 아키텍트나 DBA가 되려고 하는 선임 프로그래머는 목표를 밝혀야 한다. 따라서 요약 부분은 어떻게든 빼고 쓸모 있는 목표만 포함시켜 이력서를 보는 사람이 당신의 보유 기능을 가능한 한 빨리 볼 수 있게 하라.

#6: 서식을 주의 깊게 고려하라
이력서 서식은 중요하다. 고급 용지에 이력서를 인쇄하여 발송하던 시절은 오래 전에 지나갔지만 컴퓨터 화면으로 보든 종이로 된 문서이든 간에 이력서는 서식이 있어야 한다. 어쨌든 이력서를 쓰려면 상당한 균형 감각을 가져야 한다. 지금은 자신의 피카소 같은 감각을 과시하는 시대가 아니다. 

원하는 자리가 시각적인 예술 감각과 관련이 있는 것이 아닌 한 그렇다. 지금은 가독성을 높여야 하는 시대이다. 가독성을 높이려면 더 큰 글꼴(10~12포인트)를 사용해야 하며 (문서 포맷에 글꼴이 내장되지 않는 한) 모든 컴퓨터에서 사용하는 글꼴이어야 함을 의미한다. 한 마디로 화면으로 보든 인쇄해서 보든 간에 보기 좋아야 한다. 

추천할 만한 영문 글꼴은 Verdana, Arial, Tahoma, Calibri, Helvetica 등이다.

문서가 너무 빽빽해 보이지 않도록 여백을 충분히 두어야 한다. 그래야 보는 사람이 질리지 않는다. 반대로, 겨우 200단어를 여덟 페이지로 만들 정도로 공간을 낭비하지 말라. 

물론, 파일 자체의 포맷은 중요하다. 필자의 경험으로는 사원 모집 담당자들의 99.9%는 접수된 이력서가 다른 포맷으로 되어 있으면 MS 워드 포맷의 이력서를 요구한다. 따라서 표준 .doc 포맷으로 문서를 만들어야 한다.

이력서가 자신을 상품으로 소개하는 주요 도구라는 사실을 항상 염두에 두어야 한다. 이력서를 보는 사람이 이력서에 담긴 정보를 이해하는 데 어려움이 있다면 그것이 기술적인 문제이든 가독성 문제이든 간에 그들은 즉시 다음 이력서로 넘어간다.

#7: 길이에 주의하라
문서 포맷에 관계 없이 아주 특별한 상황이 아닌 한 분량을 2~4페이지 정도로 제한하라. 단기 계약직으로 일하는 데 많은 시간을 보내는 사람들이라면 이력서가 비교적 길 것이며 막 구직 시장에 뛰어든 사람이라면 이력서가 짧을 것이다.

전반적으로 기존의 1페이지 분량의 이력서 서식 안에 자신의 기술적인 보유 기능과 하나 이상의 직장 경력을 적절하게 부각시키기는 어렵다. 2페이지는 중급 개발자나 선임 개발자를 기준으로 한 것이다. 

하지만 4페이지 이상이면 이력서를 보는 사람의 눈이 침침해진다. 학력과 마찬가지로 7~8년 전에 가졌던 경력은 별 관계가 없지만, 고용 담당자는 담당한 책임이나 프로젝트 수준이 점점 높아지는 과정을 보고 싶어한다.

#8: 경력을 적절하게 정리하라
프로그래밍은 취업 경력 면에서 대부분의 분야와 차이가 있다. 우선, 많은 프로그래머들은 계약직이기 때문에 취업 경력은 줄줄이 이어지는 형태가 되기 마련이다. 뿐만 아니라 닷컴 불황이 지난 지 그렇게 오래 되지 않았으며, IT는 항상 파산, 인수, 합병이 많이 이루어지는 산업계였다.

문제는 고용 담당자는 단기직 경력이 길게 나열된 이력서를 좋아하지 않는다는 점이다. 이력서에 직책이 점점 높아지는 취업 경력이 쭉 이어지고 있다면 충성심이 없는 사람으로 보일 수 있다. 반면에 직무가 기본적으로 동일(하거나 점점 낮아)지는 것처럼 보인다면 실직자라는 느낌을 준다. 

계속 단기직으로 일한 정당한 이유가 있다면 반드시 그 이유를 명확하게 밝히라. 예를 들어 계약직/컨설팅 직은 명확하게 표시하라.

#9: 이력서를 보는 사람에게 법적인 부담을 주지 마라
어떤 고용 담당자도 고용 과정에서 편파적이거나 차별 대우를 했다고 고발 당하는 것을 좋아하지 않는다. 그런 행동은 비윤리적일 뿐만 아니라 불법이다. 따라서 직무를 올바르게 수행하려고 애쓰고 있는 고용 담당자는 신청인에게 해서는 안되는 질문을 잘 알고 있다. 

바꿔 말하면, 이력서를 내는 사람은 그런 내용을 이력서에 포함시켜서는 안된다. 고용 담당자가 알 필요가 없는 그 외의 개인적인 정보도 많다. 관련이 없는 내용을 이력서에 자세히 밝히면 고용 담당자는 겁을 먹고 수동적이 된다. 그런 구체적인 내용은 밝히지 말기 바란다.

#10: "튀는 사람이군!"
고등학교에서 튀는 행동으로 왕따를 당하는 것을 좋아하는 사람은 없다. 하지만 지금은 프로그래머로 일자리를 찾고 있는 중이다. 고용 담당자들은 "튀는 사람"을 "돈덩어리"로 본다. 따라서 그들에게 자신이 총명하며 프로그래밍을 사랑하고 끊임없이 성장하면서 새로운 아이디어를 배우고 탐구하는 사람임을 보여줄 수 있는 방법을 찾으라. 

오픈소스 프로젝트에 참여하고 있거나 동네 아이들에게 프로그램을 가르치는 자원 봉사 활동을 하고 있다면 그런 취미 활동에 대해 이야기하라. 그런 정보를 통해 고용 담당자들은 당신이 퇴근 후에도 프로그래밍이나 컴퓨터를 다룰 만큼 그런 것을 좋아한다는 것을 알게 된다.

고용 담당자들이 이 문제를 보는 논리는 정말 단순하다. 현재 두 명의 후보자들이 거의 비슷한 수준이라면 내일은 열정이 있는 후보자가 업무를 "단순한 직업"으로 취급하는 후보자보다 훨씬 더 발전해 있기 마련이라는 것이다.

출처 : 인터넷

Posted by SB패밀리

프로그래머를 위한 사용자 인터페이스 설계론
홈페이지: http://korean.joelonsoftware.com/index.html



제 1 부
제 2 부
제 3 부
제 4 부
제 5 부
제 6 부
제 7 부
제 8 부
제 9 부

일별 빌드(Daily Builds)가 당신 곁에 있습니다
2001년 1월 27일 토요일

일별 빌드란 전체 소스 트리를 자동화하여 전체를 일일 주기로 구축하는 작업이다. 일별 빌드(Daily Builds)가 당신 곁에 있습니다 

손쉬운 버그 추적법
2000년 11월 8일 수요일

프로그래머 혼자서 단독으로 코드를 개발하는 경우라도, 체계적인 버그 관리 없이는 좋은 코드를 만들어낼 수 없다. 손쉬운 버그 추적법

손쉬운 기능 스펙 작성법
2000년 10월 2일 월요일

제 2부 : 스펙이란 무엇인가?
제 4부 : 효과적인 스펙 작성 요령
제 1부 : 왜 스펙이 필요한가?
제 3부 : 그렇다면, 어떻게 작성할 것인가?

The Joel Test: 나은 코딩을 위한 12단계
2000년 8월 9일 수요일

SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다. The Joel Test

손쉬운 소프트웨어 스케줄 관리법
2000년 3월 29일 수요일

그렇다면, 왜 아무도 스케줄을 만들려 하지 않을까? 주된 이유는 두 가지다. 첫째는 스케줄을 짜고 관리하는 것이 매우 골치 아픈 일이기 때문이고, 두 번째 이유는 아무도 그것이 그만한 수고의 가치가 있는 일이라고 믿지 않기 때문이다. 스케줄이 지켜지지도 않을 거라면 도대체 왜 그런 수고를 해야 한단 말인가?

제대로 된 소프트웨어 개발을 위한 자본 투자 노하우
2000년 3월 21일 화요일

소프트웨어 회사의 목표가 특정한 문제를 해결하는 것이 아니라 프로그래머를 동원하여 자본을 코드로 변환하는 것이라고 생각해보자.



Joel Spolsky는 뉴욕에 위치한 작은 소프트웨어 회사인 Fog Creek Software의 창업자입니다. 예일 대학교를 졸업하고 Microsoft, Viacom, Juno등에서 프로그래머와 매니저로 일했습니다.
Posted by SB패밀리

소프트웨어는 누가 개발해야 하는가?

김국현(IT평론가)   2006/07/27  
    



소프트웨어는 누가 개발해야 하는가? 세상에 이런 우문이 어디 있느냐 생각할지도 모르겠다. 그리고 '개발자'라 짧게 대답할 것이다. 개발자라는 세 글자에는 외부에서 고용된, 그마저도 몇 단계의 하청을 거쳐, SI 업의 하류 공정을 묵묵히 맡고 있는 젊은이의 초상이 투영된다.

정말 소프트웨어는 그들만의 몫일까? 일견 당연해 보이는 이 상식을 이제는 벗어 버려야 할 때다. 소프트웨어란 '갑'이, 그 중에서도 '현업'이 개발해야 하는 것이다. '을'이 개발하고 ‘갑’은 검수를 하는 현재의 안이한 세태로는 기업이 지녀야 할 속도와 유연성은 참 갖추기 힘든 일이다.

요즈음, 기업의 IT 시스템을 짓는 일을 기업의 사옥을 짓는 일에 섣불리 비유하는 일이 위험해지고 있다 생각하게 되었다. 오늘날의 세태를 생각해 보면 사옥을 지으라 시켜 놓고, 팔짱 끼고 있는 발주자의 모습만이 떠오르기 때문이다. 무언가를 만드는 일의 설렘을 총체적으로 잊어 가는 사회 속에서 주인님이 함께 손에 흙을 묻힐 리가 없는 일이다.

건축이란 적어도 100년, 길게는 세기를 넘긴 미래를 만드는 일이다. 그렇기에 장인의 정성, 즉 고용된 프로페셔널 만으로도 가능한 일이다. 한번 타오른 열정, 100년은 갈 수 있으니 아깝지 않다. 그렇지만 기업의 IT는 오늘을 만드는 일이다. 내일의 비즈니스를 위한 오늘을 매일 매일 만들어야 하는 일인 것이다. 이 사실을 잊을 때 시스템에 우환이 찾아 든다. 기업이 맞닥뜨리게 될 변화의 힘과 속도는 팔짱 낀 방관자적 IT를 두고 볼 정도의 여유가 없다.

시스템을 1년에 걸쳐 치밀히 구축해 봤자, 남는 것은 그 시간 동안 변해 버린 환경과 이를 고려하지 않은 시스템뿐이다. 우리는 이러한 풍경을 수도 없이 목격한다. 새 집을 지어 줬다고 생각했지만, 정작 사용자는 낡고 쓸모 없다 구박한다. 현장의 사용자, 즉 현업이 원하는 그들 마음에 쏙 드는 시스템은 영원히 만들어지지 않는다. 이를 회피하기라도 하듯 현업의 요구는 억제되고, 비즈니스의 혁신은 프로젝트 일정에 의해 묵살된다. 누구를 위한 것인지 알 수 없는 개발 프로젝트는 종료를 향해 앞으로만 내달려 간다.

SI에서 일어나는 관습적 악순환이다. 파견직 개발자들은 자신이 쓸 프로그램이 아니므로, 자신이 유지 보수할 프로그램이 아니므로 정성껏 만들지 않는다. '남'을 위해 짜주는 코드와 '나'를 위해 짠 코드의 질이 같을 리가 없다. 개인이나 집단의 태도나 자질의 문제가 아니다. 인간 본성이다. 훌륭한 프로그램은 남의 집에서 만들어지지 않는 것이다.

미래를 살아 남을 기업은 지금과 같은 태평한 시스템 구축을 견디지 못할 것이다. 그들은 혁신을 위해 더 많은 요구를 할 것이고 그 요구가 받아들이지 못하면 다른 길을 찾을 것이다.

미래 기업은 ① 이상계, 즉 인터넷 서비스 기업이 정성껏 만들어 준 온라인 소프트웨어를 사용하거나, ② 현실계에서 현업 사용자 스스로 직접 소프트웨어를 개발할 것이다.

①은 현재 진행형이다. 온라인 너머로 기업 시스템을 옮기는 SaaS(Software as a Service)라는 행위가 벌어지고 있다. 세일즈포스닷컴(salesforce.com)은 대표적 사례다. 어설프게 개발한 시스템, 어설프게 운영되는 전산실보다 아예 경험 많은 이상계 기업에게 자신의 정보를 업로드해도 괜찮을 것 같다는 정서가 본격적으로 도래할지 모른다. 마치 개인들이 자신의 이메일을 포털에 맡기는 것처럼.

②는 허황된 소리로 들릴지 모르겠다. 비즈니스 수행에 바쁜 기업의 직원들이 언제 프로그래밍 공부하겠냐 할 것이다. 그러나 미래 기업에게는 많은 옵션이 생길 것이다. BPMN(Business Process Modeling Notation)이라는 비전문가도 알 수 있는 단순 조작으로 모듈화된 서비스를 재조합하여 늘 새로운 시스템을 만들자는 SOA의 철학은 엔드 유저 컴퓨팅(EUC)이라는 이루지 못한 꿈을 다시 꾼다. 마치 위키를 쓰듯, 기업 시스템을 현업이 스스로 '매시업(mash-up)'해 주무르는 IBM의 QEDWiki는 ‘사용자가 직접 개발’하는 웹 2.0적 '참여의 아키텍처'를 꿈꾼다. 마이크로소프트 오피스 차기 버전에 새롭게 등장한 Excel Services는 엑셀로 서버 프로그래밍을 가능하게 한다. 회계사 겸 서버 프로그래머, 서버 프로그래밍을 할 줄 아는 보험 업무 담당자가 대거 등장할 것이다.

일을 하다가 필요한 부분은 현업이 직접 만들어 쓰는, 그 정도까지는 아니라도 혁신을 위한 변경은 스스로 수행하는 회사에 어떤 기업이 당할 수 있을까? 전산실에 의뢰하고, 전산실은 외부 발주하여 6개월 뒤에나 오픈할 수 있는 기업과, 오늘 판단하여 내일 바뀔 수 있는 기업 중 누가 승리에 가까이 있을까?

처음에만 외주 개발을 하고 유지 보수를 포함한 2차 개발을 스스로 해결하려는 기업이 생겨나고 있다. 이미 실력 있는 개발자를 '전문 위원'이라고 계약 고용을 하고 있는 기업들이 생기고 있다. 그들은 적극적으로 양질의 개발 인력을 직접 확보하려고 애쓰고 있다. 그들은 그들의 변화 속도, 그들의 혁신을 스스로 제어하고 싶은 것이다.

IT를 관리 대상이나 설비로 본다면 이러한 행태는 착오라 해야 할 것이다. 핵심 역량이 아닌 것은 아웃소싱해야 하니까. 그러나 IT를 비즈니스의 거울, 비즈니스 수행의 주체라 생각한다면 ②의 용기를 내는 기업은 내일의 서바이벌이 두렵지 않다.

IT 시스템을 MVC, 즉 모델, 뷰, 컨트롤의 큰 덩어리로 나뉠 때 적어도 모델 정도는 충분히 현업이 만들어 낼 수 있음을 이제는 인지해야 한다. 그러나 현실계의 기업들이 이 가능성을 인지하지 못하고 하도급 공정에 안주한 채 변화에 둔감해 있다면, 그나마 있던 현실의 기회와 가치들은 모두 현실계를 떠나 이상계로 넘어 가 버릴지 모르는 일이다. 적어도 이상계나 환상계는 남을 시키지 않고 자기 스스로 직접 개발하고 있다. 남을 위한 노동은 나를 위한 작품을 보통은 이길 수 없는 법이다.

1970년대에 알란 케이는 그의 꿈 다이나북을 위해, 프로그래밍 언어이자 동시에 사용자 인터페이스인 스몰토크를 구상했다. 짜는 것과 쓰는 것을 떼어 생각하지 않았던 것이다. 그가 꿈꿨던 하드웨어의 미래는 오늘 우리 무릎 위에 있지만, 그가 꿈꿨던 소프트웨어의 미래는, 그리고 그가 꿈꿨던 '소프트웨어를 만드는 사용자'들은 아직 우리 곁에 보이지 않는다. "사용자는 공동 개발자로 여겨져야 한다"는 웹 2.0적 참여의 이상이 익어 갈 무렵에는 '소프트웨어를 만드는 사용자'들을 우리 곁에서 찾아 볼 수 있을까?@

 

출처 : 인터넷

Posted by SB패밀리
쌈꼬쪼려소백촌닭
출처 : 인터넷

[IT/컬럼] 이런 IT 회사 가지마라

그냥 주관적인 글입니다.
이런 생각도 있으니 참고 하세요.

1. 직원들 얼굴이 어두운 회사

더이상 말이 필요없다.
직원들 얼굴이 현재진행상황을 알려준다.


2. 우수인재 확보 X

쓸만한 인재인데도 기존의 임금수준과 직급을 들먹이며 빈둥빈둥 시간을 끈다.
결국엔 갓 대학 졸업한 싸구려 인력만 뽑는 회사다.

좋은 인재를 찾으려는 노력자체를 하지않는 회사다.
이런 회사는 인재을 코딩하는 소모품으로 정도밖에 생각하지 않는다.
본인도 소모품으로 취급될 것이다. 빨리 나와라.


3. 테스트 기간 없는 회사

겁나게 큰 프로젝트인데도 테스트 기간을 전혀 잡지 않는 회사
이론상 제작 기간의 2배를 테스트 기간으로 잡아야 정상이다.

하지만 우리나라 특성상 -_-;
대부분 열악한 기업들이 그리 길게 잡지 못한다.
3명이상 플젝이면 최소 최소 최소 아주 작게 잡아도 1주이상 잡아야 한다.
1주일이면 정말 미니멈이다.
설계자가 1주일도 테스트 기간을 잡지 않는다면
내일부터 출근하지 마라.
각종 버그에 고객 요구사항에 뒤처리만 하느라 두배로 기간이 늘어난 프로젝트에 빠져 허우적 댈것이다.


4. 월급이 안나오는 회사

IT기업은 지금도 수많은 회사들이 창업하고 망한다.
인권비는 IT계열에서 수익을 얻기위한 가장 기본적인 유지비용이다.
직원들 월급도 못줄 정도라면 정말 회사 사정이 어려워 진거다.
월급이 한달이라도 밀린다면 사정없이 그만둬라.
프로젝트 진행중이라도 상관 없다!!! 무조건 나와라!!

그리고 그만둘때는 다른일을 핑계대고
그일만 아니라면 무보수로 몇개월씩 있을수 있다고 강조하며
회사가 어려우니 한달 보수 정도는 포기하면서
도의적 책임을 다하고
(플젝 진행중일테니 한달동안은 무보수로 반드시 도의적 책임을 다해라~! 꼭 명심해라!! 법정에서 유리하다. -_-;; )
사장과 기분좋게 끝내라.

직원들 월급도 못주는 IT기업이 회생할 가능성은 정말 낮다.
차라리 로또를 사라. 그게 확률이 높다.
괜히 인간관계 생각해서 몇개월 무보수로 더 일하면 좋은 꼴 절대 못본다.
사람은 돈이 관계되면 정말 치사해 진다.
특히 장사를 하는 사람은 정말 그렇다.
간이고 쓸개고 다 빼줄듯 하다가 회사 망해서 돈이 없으면 싹 돌아설 것이다.
밀린월급 받으려고 소송들이대고 합의보고 하다보면
잘 해봐야 몇개월 밀린 금액의 반정도로 합의 볼 것이다.
그동안 사장이랑 싸우고 맘고생하고..... 손해가 막심하다.


ps. 참고로 회사 이전은 왠만하면 재직중에 알아봐라
백수로 있으면 마음이 다급해져서 아무회사나 들어가는 경우가 많다.
또한, 보통 회사는 백수로 있는 인재보다는 재직중에 있는 인재를 좋아한다.

어디에선가 '쓸모'있는 인재라는 보장이 있기 때문이다.
(다른 회사에서 일 잘한 인재는 여기서도 일 잘할거야~~)


5. PM이 의사결정을 하지 않는 회사

의사결정을 다른이에게 맡기는 사람은 차라리 낫다.

그런 결정 조차도 하지 않는 PM이다.(지가 못하면 갑한테 물어보든가~ -_-; )

원인은 육안으로 잘 보이지 않지만
증상으로 쉽게 진단할수 있다.

여러분이 똑같은 프로그램을 대여섯번 새로 만든다면
확실이 이런 타입의 PM이다.
PM이 의사결정을 확실히 하지 않아 이렇게 짯다가 뒤엎고 저렇게 짯다가 뒤엎는다.
일하는건 문제가 아니다.
의사결정을 하지 않는 PM은
나중에 플젝이 아작 났을때 책임이 없다.
심지어는 책임을 회피하려고 의사결정을 하지 않는 케이스도 있다.
IT쪽에서 일 존내 마니 하다 보면
플젝이 진흙탕에서 허우적 대다가 정말로 아작 나는 경우도 있다.


근데 이런 PM은 아작나도 책임이 별로 없다.

지가 책임질 부분이 적기 때문이다.

아작 났을때 PM을 제외한 하위 직원들이 아~주 난해하다.

조만간 직원들이 임무 %별로 PM보다 많이 프로젝트 보상금을 물고있는 자신을 보게 될것이다.
(돈 벌러 회사 들어가서 꼴아박고 나오는 케이스.)


6. 유지보수는 10분이면 된다는 회사

아마 만줄 코딩하고 허리한번 피게 될거다.

'고생'외에는 별 단점은 없지만
개인적으로 싫어한다.
나도 인간이다.
어떻게 주7일동안 일만할수 있는가.

여자친구랑 놀시간도 필요하고
주말에 인라인도 타야되고 사진도 찍어야 한다.
특별히 프로젝트 마무리단계도 아닌데 평상시에도
주말보장 안해주는 회사는 개인적으로 '즐'이다.


지금도 수많은 열악한 IT회사들이 있습니다.
이상하게도 이바닥은 소프트웨어산업이
'무'에서 '유'를 창조하는 줄 알고있는 무식한 사람들이 세운
열악한 회사가 엄청 많습니다.
IT도 분명히 투자금액이 있습니다.
인권비며 사무실 비용이며 엄청나게 돈이 들어갑니다.
그래도 아직 사회적 인식은 소프트웨어는 공짠줄 알죠 -_-;


그래 그런 멍청한 자들이 지돈 존내 꼴아박고 남의 월급도 못주고
남의 경력 걸레로 만드는 겁니다.

물론 좋은 회사면 오래 있어야 합니다.
그래야 근무년수도 늘고 연봉에도 이익이 많쵸.

그래서 글을 끄적여서 올려봅니다.
이곳 저곳 옮기면서 6개월짜리 경력 5개 가지고 3년 채우면
여러분 IT 경력은 정말 걸레가 되는 겁니다.

그걸 막기 위해
어떤 회사가 좋은건지
어떤 회사가 나쁜건지
어떤 회사에 오래 있어야 되는지


여러분 판단에 조금이라도 도움이 될까 개인적인 생각을 끄적여 봤습니다.

위 글은 저자의 동의 없이 함부로 퍼가셔도 됩니다. -_-)v
Posted by SB패밀리

SW 개발자의 길, 아니다 싶으면 포기하라


20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다

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패밀리

단지 프로그래머에게만 해당되는 것이 아닌것 같군요.^_^
 
쫌더 세밀하게 읽어봐야겠습니다.
 

How to be a Programmer: A Short, Comprehensive, and Personal Summary

프로그래머가 되는 방법: 짧고 폭넓고 개인적인 요약.



Copyright © 2002, 2003 Robert L. Read

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with one Invariant Section being 'History (As of May, 2003)', no Front-Cover Texts, and one Back-Cover Text: 'The original version of this document was written by Robert L. Read without renumeration and dedicated to the programmers of Hire.com.' A copy of the license is included in the section entitled 'GNU Free Documentation License'.

목차

Contents

[-]
1 도입
2 초보자
2.1 개인적 기능들
2.1.1 디버그 배우기
2.1.2 문제 공간을 나눠서 디버그 하는 방법
2.1.3 오류를 제거하는 방법
2.1.4 로그를 이용해서 디버그 하는 방법
2.1.5 성능 문제를 이해하는 방법
2.1.6 성능 문제를 해결하는 방법
2.1.7 반복문을 최적화하는 방법
2.1.8 I/O 비용을 다루는 방법
2.1.9 메모리를 관리하는 방법
2.1.10 가끔씩 생기는 버그를 다루는 방법
2.1.11 설계 기능을 익히는 방법
2.1.12 실험을 수행하는 방법
2.2 팀의 기능들
2.2.1 시간 추정이 중요한 이유
2.2.2 프로그래밍 시간을 추정하는 방법
2.2.3 정보를 찾는 방법
2.2.4 사람들을 정보의 원천으로 활용하는 방법
2.2.5 현명하게 문서화하는 방법
2.2.6 형편없는 코드를 가지고 작업하기
2.2.7 소스 코드 제어 시스템을 이용하는 방법
2.2.8 단위별 검사를 하는 방법
2.2.9 막힐 때는 잠깐 쉬어라
2.2.10 집에 갈 시간을 인지하는 방법
2.2.11 까다로운 사람들과 상대하는 방법
3 중급자
3.1 개인적 기능들
3.1.1 의욕을 계속 유지하는 방법
3.1.2 널리 신뢰받는 방법
3.1.3 시간과 공간 사이에서 균형을 잡는 방법
3.1.4 압박 검사를 하는 방법
3.1.5 간결성과 추상성의 균형을 잡는 방법
3.1.6 새로운 기능을 배우는 방법
3.1.7 타자 연습
3.1.8 통합 검사를 하는 방법
3.1.9 의사소통을 위한 용어들
3.2 팀의 기능들
3.2.1 개발 시간을 관리하는 방법
3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법
3.2.3 컨설턴트를 관리하는 방법
3.2.4 딱 적당하게 회의하는 방법
3.2.5 무리 없이 정직하게 반대 의견을 내는 방법
3.3 판단 능력
3.3.1 개발 시간에 맞춰 품질을 조절하는 방법
3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법
3.3.3 소프트웨어의 완성도를 판단하는 방법
3.3.4 구입과 개발 사이에서 결정하는 방법
3.3.5 전문가로 성장하는 방법
3.3.6 면접 대상자를 평가하는 방법
3.3.7 화려한 전산 과학을 적용할 때를 아는 방법
3.3.8 비기술자들과 이야기하는 방법
4 상급자
4.1 기술적 판단 능력
4.1.1 어려운 것과 불가능한 것을 구분하는 방법
4.1.2 내장 언어를 활용하는 방법
4.1.3 언어의 선택
4.2 현명하게 타협하기
4.2.1 작업 일정의 압박과 싸우는 방법
4.2.2 사용자를 이해하는 방법
4.2.3 진급하는 방법
4.3 팀을 위해 일하기
4.3.1 재능을 개발하는 방법
4.3.2 일할 과제를 선택하는 방법
4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법
4.3.4 문제를 나누는 방법
4.3.5 따분한 과제를 다루는 방법
4.3.6 프로젝트를 위한 지원을 얻는 방법
4.3.7 시스템이 자라게 하는 방법
4.3.8 대화를 잘 하는 방법
4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법
4.3.10 관리상의 신화들을 다루는 방법
4.3.11 조직의 일시적 혼돈 상태를 다루는 방법
5 참고 문헌
5.1 책
5.2 웹 사이트
6 역사 (2003년 5월 현재) / History (As Of May, 2003)
6.1 피드백 및 확장 요청 / Request for Feedback or Extension
6.2 원본 / Original Version
6.3 원저자의 경력 / Original Author's Bio

1 도입

좋은 프로그래머가 되는 것은 어렵고도 고상한 일이다. 소프트웨어 프로젝트의 공동 비전을 현실화하려고 할 때 가장 어려운 부분은 함께 일하는 개발자들과 고객들을 상대하는 일이다. 컴퓨터 프로그램을 짜는 것은 중요한 일이고 지식과 기능이 많이 드는 일이다. 하지만 그것은 좋은 프로그래머가 고객 및 자기가 크고 작게 책임을 지고 있는 수많은 동료들을 만족시키는 소프트웨어 시스템을 만들기 위해 해야 하는 다른 모든 일들에 비교해 볼 때 정말 어린아이 장난과 같다. 나는 내가 스물 한 살이었을 때 누군가가 나에게 설명해 주길 바랐던 것들을 가능한 한 간결하게 요약하려고 했다.

이것은 매우 주관적이며, 따라서 이 글은 개인적이고 다소 고집스럽게 보일 수밖에 없다. 이 글은 프로그래머가 일하면서 맞부딪치기 아주 쉬운 문제들에 한정되어 있다. 이런 문제들과 이에 대한 해결책은 사람 사는 데서 흔히 볼 수 있기 때문에 이 글이 설교처럼 보일 수도 있다. 그럼에도 불구하고 이 글이 유용하게 쓰이길 바란다.

컴퓨터 프로그래밍은 여러 강좌를 통해 배울 수 있다. The Pragmatic Programmer <Prag99>, Code Complete <CodeC93>, Rapid Development <RDev96>, Extreme Programming Explained <XP99> 등의 훌륭한 책을 통해 컴퓨터 프로그래밍에 대해 배우고, 좋은 프로그래머란 무엇인가에 대한 다양한 논점들을 알게 된다. 폴 그레이엄(Paul Graham) <PGSite>과 에릭 레이먼드(Eric Raymond) <Hacker>의 글은 이 글을 읽기 전이나 읽는 도중에 꼭 읽어 보아야 한다. 이 글은 이상의 훌륭한 글들과 달리 사회 활동의 문제를 강조하고 있으며 내가 보기에 꼭 필요하다고 생각하는 모든 기능들을 폭넓게 요약하고 있다.

이 글에서 "상사"는 나에게 프로젝트를 배정해 주는 사람을 의미한다. 사업, 회사, 부족(tribe)이라고 할 때, 사업이 돈을 버는 것, 회사가 현시대의 일터, 부족이 충성심을 공유하는 사람들이라는 뜻을 내포하는 것 외에는 모두 같은 뜻으로 사용했다.

우리 부족에 온 것을 환영한다.

2 초보자

2.1 개인적 기능들

2.1.1 디버그 배우기

디버깅은 프로그래머의 기본이다. 디버그란 말의 처음 뜻은 오류를 제거하는 것이지만, 더 중요한 것은 프로그램이 실행될 때 그것을 상세히 검사하는 일이다. 효과적으로 디버그 할 줄 모르는 프로그래머는 앞을 못 보는 것과 같다.

이상주의자라면 설계, 분석, 복잡도 이론 등등이 더 기본적인 것이라고 생각할 것이다. 하지만 이들은 현업의 프로그래머가 아니다. 현업의 프로그래머는 이상적인 세계에서 살고 있지 않다. 완벽한 프로그래머라 해도, 그는 대형 소프트웨어 회사, GNU 등의 조직, 자기 동료들이 만든 코드들에 둘러싸여 있고 그것을 가지고 작업해야 한다. 이 코드들은 대부분 불완전하며 불완전하게 문서화되어 있다. 어떤 코드가 실행될 때 그것을 꿰뚫어 볼 수 있는 능력이 없다면 사소한 문제에도 대책 없이 나가떨어질 수밖에 없다. 이러한 투시력은 실험해 보는 것을 통해 얻어지며, 그것이 바로 디버깅이다.

디버깅은 프로그램의 실행에 대한 것이지 프로그램 자체에 대한 것이 아니다. 대형 소프트웨어 회사에서 프로그램을 구입했다면 보통은 프로그램을 들여다볼 수 없다. 하지만 그 코드가 문서대로 동작하지 않거나 (컴퓨터가 멈춰 버리는 것은 아주 흔하고 극적인 예이다) 문서에 원하는 내용이 없는 일은 항상 일어난다. 더 흔한 것은, 오류가 생겨서 자기가 짠 코드를 검사하는데 어떻게 그런 오류가 생길 수 있는지 전혀 실마리를 잡을 수 없는 경우이다. 당연히 이것은 그 프로그래머가 짐작하고 있는 것 중 어떤 것이 잘못됐거나, 예상하지 못했던 상황이 발생하기 때문이다. 가끔은 소스 코드 응시하기 마법으로 문제를 해결할 수 있다. 하지만 그 마법이 통하지 않을 때는 디버그를 해야 한다.

프로그램의 실행에 대한 투시력을 얻기 위해서는 코드를 실행하면서 무엇인가를 관찰해야 한다. 어떤 경우에는 그것이 화면에 나타나서 눈으로 볼 수도 있지만, 다른 많은 경우에는 코드 내의 변수의 상태, 현재 실행되고 있는 코드의 줄 수, 복잡한 자료 구조에서 어떤 검증 조건(assertion)이 계속 유지되는가의 여부 등과 같이 눈에 보이지 않는다. 이런 숨겨진 것들은 드러나야 한다. 실행되고 있는 프로그램의 내부를 들여다보기 위해 널리 쓰이는 방법을 다음과 같이 분류할 수 있다.
  • 디버깅 도구 이용
  • 프린트 줄 넣기(printlining) -- 프로그램을 임시로 고치는 것, 특히 필요한 정보를 프린트하는 줄을 추가하는 것
  • 로그 기록 -- 로그 파일의 형태로 프로그램을 들여다볼 수 있는 영구적인 창을 만드는 것

디버깅 도구는 제대로 동작한다면 훌륭한 것이지만, 그 다음의 두 가지 방법이 더욱 더 중요하다. 디버깅 도구는 종종 언어의 발달을 따라가지 못하기 때문에 어떤 시점이 되면 쓸모 없게 될 수 있다. 그리고 디버깅 도구 자체가 프로그램의 수행 방식을 미묘하게 변화시킬 수도 있기 때문에 모든 경우에 유효한 것이 아니다. 끝으로, 대규모 자료 구조에 대한 검증 조건을 검사하는 것과 같은 디버깅의 경우에는 어떻든 간에 코드를 새로 짜야 한다. 디버깅 도구가 안정적이라면 그것의 사용 방법을 아는 것이 좋은 일이겠지만, 그 다음의 두 가지 방법을 쓸 줄 아는 것은 필수불가결한 일이다.

어떤 초보자는 코드를 고치고 실행하는 일을 반복해야 하는 디버깅에 대한 두려움이 잠재의식 속에 있는 것 같다. 이해할 만한 일이다. 이것은 처음 외과 수술을 하는 것과 비슷해 보인다. 하지만 초보자들은 코드가 쌩쌩 돌아가게 하기 위해 여기저기 찔러 보는 것에 익숙해져야 한다. 그들은 코드를 가지고 실험해 보는 것에 익숙해져야 하고, 자기가 코드를 가지고 무엇을 하더라도 그것이 문제를 악화시키지 않는다는 것을 배워야 한다. 이 소심한 사람들의 교사나 사수라면, 어떻게 해야 하는지 친절하게 알려 주고 손이라도 잡아 이끌면서 그 두려움을 극복할 수 있도록 도와 주라. 그 두려움 때문에 좋은 프로그래머가 될 수 있는 사람들도 아슬아슬하게 시작했다가 포기하는 경우가 많다.

2.1.2 문제 공간을 나눠서 디버그 하는 방법

디버깅은 수수께끼에서 출발하기 때문에 재미있다. 이렇게 디버그 하면 저렇게 될 것이라고 생각하지만 실제로는 다른 결과가 생긴다. 디버깅은 만만한 일이 아니다. 여기에서 무슨 사례를 제시하든 그것은 실제 상황에 비하면 상당히 부자연스운 것이 될 것이다. 디버깅은 창의력과 독창성이 필요하다. 디버깅에 한 가지 열쇠가 있다면 그것은 수수께끼에 대한 분할 정복 기법(divide and conquer technique)을 사용하는 것이다.

예를 들어 열 가지 일을 차례로 하는 프로그램을 만들었다고 하자. 그런데 실행해 보니 멈춰 버렸다. 멈추도록 프로그램하지 않았는데 말이다. 이제 "프로그램이 멈춘다"는 수수께끼가 생긴 것이다. 출력된 결과를 보면 처음 7번까지는 제대로 실행된 것을 알 수 있다. 나머지 세 가지가 출력 결과에서 안 보인다. 이제 우리의 수수께끼는 "프로그램이 8번이나 9번이나 10번에서 멈췄다"로 줄어들었다.

그럼 프로그램이 어디에서 멈췄는지 알아볼 수 있는 실험을 설계할 수 있을까? 물론이다. 디버거를 쓸 수도 있고 8번과 9번 다음에 프린트 줄을 넣을 수도 있다. (물론 사용하는 언어에 적합한 다른 방법을 쓸 수도 있다.) 그리고 다시 실행해 보면 우리의 수수께끼는 "프로그램이 9번에서 멈췄다"와 같이 더 줄어든다. 어느 순간에든 수수께끼가 정확히 무엇인지 기억하는 것은 집중하는 데 도움이 된다. 여러 사람이 급하게 어떤 문제에 매달려 있을 때는 그 일이 무척 혼란스러워질 수 있다.

분할 정복이라는 열쇠는 디버깅 기법일 뿐만 아니라 알고리듬 설계 기법이기도 하다. 수수께끼의 중간을 둘로 나누는 것만으로 일 처리를 잘 할 수 있다면, 더 이상 많이 나눌 필요는 없을 것이고 디버깅도 더 빨리 끝날 것이다. 그런데 수수께끼의 중간이란 어디쯤을 말하는 것인가? 여기가 바로 창의력과 경험이 필요한 지점이다.

아직 초보인 사람에게는, 모든 오류가 존재하는 공간이 소스 코드의 모든 몇 줄뿐인 것처럼 보일 것이다. 그는 아직 프로그램의 다른 차원, 즉, 줄들이 실행되는 공간, 자료 구조, 메모리 관리, 외부 코드와 상호작용, 문제가 생길 만한 코드와 간단한 코드 등을 볼 수 있는 감각이 없다. 이런 다른 차원들은 경험이 쌓인 프로그래머에게 문제를 일으킬 수 있는 모든 것들에 대해 완벽하지는 않지만 매우 유용한 머리 속의 모형(mental model)을 형성하게 해 준다. 이런 모형을 머리 속에 갖고 있으면 수수께끼의 중간이 어디인지 효과적으로 찾는 데 도움이 된다.

문제를 일으킬 수 있는 모든 것들의 공간을 둘로 균등하게 나눴다면, 이제는 그 둘 중 어느 쪽에서 오류가 생겼을지 결정해야 한다. 수수께끼가 "프로그램을 멈추게 하는 그 줄은 이 줄이 실행되기 전에 실행됐을까, 후에 실행됐을까?"와 같이 단순한 경우에는 어느 줄이 실행되는지 관찰하기만 하면 된다. 다른 경우에는 수수께끼가 이런 식으로 분할될 것이다. "저 그래프에 잘못된 노드를 가리키는 포인터가 있거나, 그 그래프에 변수들을 추가하는 알고리듬에 문제가 있다." 이런 경우에는 분할된 수수께끼 중 어느 쪽을 버릴 것인지 결정하기 위해 그 그래프의 포인터들이 모두 정확한지 알아보는 작은 프로그램을 작성해야 할 수도 있다.

2.1.3 오류를 제거하는 방법

나는 의도적으로 프로그램의 실행을 점검하는 행위와 오류를 고치는 행위를 구분하고 있다. 물론 디버깅은 버그를 제거하는 것을 뜻한다. 이상적으로는 코드를 완벽하게 이해하여 오류의 정체와 그것을 고칠 방법을 완벽하게 알게 되면서 "아하!" 하고 외치는 순간에 이를 수도 있다. 하지만 문서화가 잘 되어 있지 않아 그 속을 들여다 볼 수 없는 시스템들을 가지고 프로그램을 만드는 경우도 종종 있으므로 이런 일이 항상 가능한 것은 아니다. 또한 코드가 너무 복잡해서 그것을 완벽하게 이해할 수 없는 경우도 있다.

버그를 고칠 때에는 가능한 한 조금만 수정하여 버그를 고치고 싶을 것이다. 그러면서 성능 개선이 필요한 다른 것들을 보게 될 수도 있다. 하지만 이것들을 동시에 고치지는 말라. 한 번에 단 한 가지만 변경하는 과학 실험 방법을 사용하도록 하라. 이를 위한 최선의 과정은, 그 버그를 쉽게 다시 확인할 수 있게 되면, 고친 내용을 바꿔 넣고 나서, 프로그램에서 버그가 더 이상 없다는 것을 확인하는 것이다. 물론 때때로 한 줄 이상을 고쳐야 하겠지만 그렇다 해도 개념적으로는 더 이상 나눌 수 없는(atomic) 한 부분만 변경해서 버그를 고쳐야 한다.

실제로 버그가 여러 개인데 그것들이 하나인 것처럼 보이는 경우도 있다. 버그를 어떻게 정의하여 그것들을 하나씩 고쳐 갈 것인지 결정하는 것은 결국 프로그래머의 몫이다. 프로그램이 무엇을 해야 하는지, 또는 원래 개발자가 의도했던 것이 무엇인지 불분명할 경우도 있다. 그런 경우에는 경험을 근거로 판단을 내리고 그 코드에 자기 나름대로 의미를 부여해야 할 것이다. 그 프로그램이 무엇을 해야 할지 결정하고, 그것에 대해 주석을 달거나 어떤 식으로든 명료화하고, 그 코드가 그 의미에 부합하도록 만든다. 이것은 중급에서 고급의 기능으로서 처음부터 새로운 함수를 작성하는 것보다 더 어려울 경우도 있지만, 현업에서는 이런 귀찮은 일이 종종 생긴다. 어쩌면 자신에게 수정 권한이 없는 시스템을 고쳐야 하게 될지도 모른다.

2.1.4 로그를 이용해서 디버그 하는 방법

로그 기록(logging)이란 정보를 제공하는 일련의 기록인 로그(log)를 생성하도록 시스템을 작성하는 활동을 말한다. 프린트 줄 넣기(printlining)는 간단한, 보통은 일시적인, 로그를 생성하기만 한다. 완전한 초보자들은 프로그래밍에 대해 아는 것에 한계가 있기 때문에 로그를 이해하고 사용해야 한다. 시스템 설계자들은 시스템의 복잡성 때문에 로그를 이해하고 사용해야 한다. 로그가 제공하는 정보의 양은, 이상적으로는 프로그램이 실행되는 중에도, 설정 가능해야 한다. 일반적으로 로그 기록은 다음의 이점이 있다.
  • 로그는 재현하기 힘든 (예를 들어, 개발 완료된 환경에서는 발생하지만 테스트 환경에서는 재현할 수 없는) 버그에 대한 유용한 정보를 제공할 수 있다.
  • 로그는, 예를 들어, 구문(statement)들 사이에 걸리는 시간과 같이, 성능에 관한 통계와 정보를 제공할 수 있다.
  • 설정이 가능할 때, 로그는 예기치 못한 특정 문제들을 디버그하기 위해, 그 문제들을 처리하도록 코드를 수정하여 다시 적용하지(redeploy) 않아도, 일반적인 정보를 갈무리할 수 있게 한다.

로그에 남기는 정보의 양은 항상 정보성과 간결성 사이의 타협으로 결정된다. 정보를 너무 많이 남긴다면 로그가 낭비적이 되고 스크롤에 가려지게(scroll blindness) 되어, 필요한 정보를 찾기 어려워질 것이다. 너무 조금 남긴다면 필요한 정보가 남지 않을 것이다. 이런 점에서, 무엇이 출력될지 설정할 수 있게 하는 것은 매우 유용하다. 일반적으로 로그에 남는 기록을 통해, 그 기록을 남긴 소스 코드의 위치, (적용 가능하다면) 문제가 되는 작업을 실행한 쓰레드, 정확한 실행 시각, 그리고 일반적으로, 어떤 변수의 값, 여유 메모리의 양, 데이터 객체의 개수 등 그 밖의 유용한 정보를 알 수 있다. 이러한 로그 생성 구문들은 소스 코드 전체에 흩어져 있는데, 특히 주요 기능이 있는 지점과 위험 부담이 있는 코드 근처에 있다. 구문마다 수준이 정해질 수 있으면 시스템의 현재 설정에 따라 그 수준에 해당하는 기록만 남기게 될 것이다. 로그 생성 구문을 설계할 때에는 어디에서 문제가 생길지 예상해서 그것을 기록으로 남길 수 있게 해야 한다. 성능을 측정할 필요성도 예상하고 있어야 한다.

영구적인 로그를 남긴다면, 로그 기록이 프린트 줄 넣기(printlining)를 대신 할 수 있을 것이고, 디버그 구문들 중에도 로그 기록 시스템에 영구적으로 추가할 것들이 있을 것이다.

2.1.5 성능 문제를 이해하는 방법

실행중인 시스템의 성능을 알아내는 방법을 이해하는 일은 디버깅과 마찬가지로 피할 수 없는 일이다. 자기가 작성한 코드의 실행에 드는 비용을 완벽하고 정확하게 이해하고 있다 해도, 그 코드는 통제할 수 없거나 들여다볼 수 없는 다른 소프트웨어 시스템들을 호출할 때도 있다. 하지만 실제로 성능의 문제는 일반적으로 디버깅과는 조금 다르고 또 조금은 쉬운 문제이다.

어떤 시스템이나 하위 시스템이 너무 느린 것 같다고 가정해 보자. 그것을 빠르게 하기 전에 우선 왜 그것이 느린지에 대해 머리 속으로 모형을 만들어야 한다. 그렇게 할 수 있도록 시간과 그 밖의 자원들이 어디에 실제로 쓰이고 있는지 알기 위해 성능 기록 도구(profiling tool)나 좋은 로그 기록을 쓸 수 있다. 유명한 격언 중에 90%의 시간은 10%의 코드에 쓰인다는 말이 있다. 나는 그 격언에 성능 문제에서 입출력 시간(I/O)의 중요성을 추가하고 싶다. 종종 대부분의 시간은 이러저러한 방식으로 I/O에 쓰인다. 낭비가 심한 I/O와 그러한 10%의 코드를 찾아냈다면 한 발짝 잘 내딛은 것이다.

컴퓨터 시스템의 성능에는 여러 차원이 있고 여러 자원들이 사용된다. 측정해야 할 첫 번째 자원은 벽시계 시간(wall-clock time), 즉 계산에 걸리는 총 시간이다. 벽시계 시간을 로그에 기록으로 남기는 것은, 다른 성능 기록 방법이 통하지 않는 예상치 못한 상황에 대한 정보를 줄 수 있으므로 특히 가치가 있다. 하지만 이것으로 모든 것을 알 수는 없다. 때로는 시간이 좀 더 걸리기는 하지만 프로세서의 처리 시간을 많이 잡아먹지 않는 코드가 실제로 작업해야 하는 전산 환경에서는 훨씬 더 좋을 수 있다. 마찬가지로, 메모리, 네트웍 대역폭, 데이터베이스, 그 밖의 서버 접속들이 결국에는 프로세서 처리 시간보다 더 낭비가 클 수 있다.

동시에 사용해야 하는 공유 자원 쟁탈(contention)로 교착 상태(deadlock)나 기아 상태(starvation)가 생길 수도 있다. 교착 상태란 동기화나 자원 요청이 부적절하여 더 이상 진행할 수 없는 상태를 말한다. 기아 상태란 구성요소에 시간을 적절히 배분하는 데에 실패한 것이다. 이런 상황을 예상할 수 있다면 프로젝트를 시작할 때부터 이런 쟁탈을 측정할 방법을 마련하는 것이 최선이다. 이러한 쟁탈이 일어나지 않는다 해도 그것을 확실히 검증할 수 있게 해 놓는 것은 매우 도움이 된다.

2.1.6 성능 문제를 해결하는 방법

대부분의 소프트웨어 프로젝트는 첫 배포판을 냈을 때보다 비교적 적은 노력으로도 10배에서 100배나 더 빠르게 진행될 수 있다. 출시일의 압박 하에서는, 일을 간단하고 신속하게 끝낼 수 있는, 하지만 다른 해결책보다는 효율이 떨어지는, 해결책을 선택하는 것이 어쩌면 현명하고도 효과적인 방법일 수 있다. 하지만 성능은 사용 편이성(usability)의 일부이며, 결국에 가서는 더욱 세심하게 고려해야 할 경우가 많다.

매우 복잡한 시스템의 성능을 향상시키는 열쇠는 병목(bottleneck), 즉 대부분의 자원들이 사용되는 지점을 찾기 위해 충분히 잘 분석하는 것이다. 계산 시간의 1% 밖에 차지하지 않는 함수를 최적화하는 것은 별 의미가 없다. 실제로 시간이 어디에 쓰이는지 알아내기 위해 성능 분석을 먼저 해야 하며, 그로부터 무엇을 향상시킬 것인지 결정할 수 있다. 경험상으로 볼 때, 어떤 작업이 시스템이나 시스템의 중요한 부분을 최소한 두 배 빠르게 할 것이라고 생각되지 않는다면, 그것을 실행에 옮기기 전에 신중하게 생각해야 한다. 보통 이것을 위해 쓰는 방법이 있다. 그 변화에 따라 필요하게 되는 검사와 품질 확인의 수고를 고려하라. 모든 변화에는 검사라는 짐이 따르므로 큰 변화가 적을수록 더 좋은 것이다.

어디에선가 두 배의 향상을 달성한 후에는, 최소한 다시 생각하고 또 다시 분석하여 그 다음으로 낭비가 심한 병목이 어디인지 발견해 내고, 또 다른 두 배의 성능 향상을 이루기 위해 그 지점을 공략해야 할 것이다.

성능 상 병목은 소를 셀 때 머리를 세는 대신 다리를 센 다음 4로 나누는 것에 비유할 수 있을 것이다. 예를 들어, 나는 어떤 관계형 데이터베이스 시스템에서 자주 검색하는 열에 적절한 인덱스를 달지 않아서, 검색이 최소한 스무 배는 느려지는 오류를 일으킨 적이 있다. 그 외에도, 내부 반복문에서 불필요한 I/O를 하는 것, 더 이상 필요 없는 디버그 구문을 남겨 놓는 것, 불필요한 메모리 할당, 성능에 대해 제대로 문서화되어 있지 않은 라이브러리나 그 밖의 하위 시스템들을 전문적인 안목 없이 사용하는 것 등을 예로 들 수 있을 것이다. 이런 식의 성능 향상을, 쉽게 따서 성과를 낼 수 있다는 의미에서, 낮게 달린 과일(low-hanging fruit)이라고 부르기도 한다.

낮게 달린 과일들을 거의 다 따 버렸다면 어떻게 할 것인가? 아마도 더 높이 손을 뻗거나 나무를 베어 내릴 것이다. 즉, 조그만 성능 향상을 계속해 갈 수도 있고, 시스템이나 하위 시스템을 진지하게 재설계할 수도 있을 것이다. (이것은, 새로운 설계라는 측면뿐만 아니라 자기 상사에게 이것이 좋은 생각이라는 것을 설득한다는 측면에서도 좋은 프로그래머로서 자신의 능력을 발휘할 수 있는 훌륭한 기회이다.) 하지만, 재설계를 주장하기 전에는 이것이 하위 시스템을 다섯 배에서 열 배는 더 낫게 할 수 있는지 스스로 질문해 봐야 한다.

2.1.7 반복문을 최적화하는 방법

때때로 제품에서 실행하는 데 시간이 오래 걸리거나 병목(bottleneck)이 되는 반복문이나 재귀함수를 보게 될 것이다. 그 반복문을 조금 빠르게 고치려고 하기 전에, 혹시 그것을 완전히 제거할 방법은 없는지 잠시 생각해 보라. 다른 알고리듬으로 그 일을 할 수 없을까? 다른 계산을 하면서 동시에 그 계산을 할 수는 없을까? 그런 식의 방법을 찾을 수 없다면 반복문 최적화 작업을 해도 된다. 이 일은 단순하다. 잡동사니를 없애 버려라. 결국 이 일은 독창성뿐만 아니라 그런 종류의 구문이나 식에 드는 비용에 대한 이해가 요구된다. 여기 몇 가지를 제안해 보겠다.
  • 실수 연산(floating point operation)을 제거하라
  • 필요 없이 메모리 블록을 새로 할당하지 말라
  • 상수들을 미리 계산하라(fold together)
  • I/O는 버퍼로 옮겨라
  • 나눗셈을 피하라
  • 쓸데없는 형변환(cast)을 피하라
  • 첨자(index)를 반복 계산하는 것보다는 포인터를 옮기는 것이 낫다

이러한 연산에 드는 비용은 사용하는 시스템에 따라 다르다. 어떤 시스템의 컴파일러와 하드웨어는 알아서 이런 일들을 해 준다. 그래도 분명하고 효율적인 코드가 특정 시스템에 대한 이해가 필요한 코드보다 더 낫다.

2.1.8 I/O 비용을 다루는 방법

많은 문제에서 프로세서는 하드웨어 장치들과 통신하는 데 드는 시간에 비해 빠르게 동작한다. 이런 시간 비용을 보통 줄여서 I/O라고 하고, 여기에는 네트웍 시간, 디스크 I/O, 데이터베이스 질의, 파일 I/O, 그리고 프로세서에 가깝지 않은 어떤 하드웨어가 뭔가를 하게 하는 작업들이 포함된다. 따라서 빠른 시스템을 만든다는 것은, 어떤 빽빽한 반복문 속에 있는 코드를 개선하거나 더 나아가 알고리듬을 개선하는 것보다 I/O를 개선하는 일이 될 경우가 많다.

I/O를 개선하는 두 가지 매우 기초적인 방법, 즉 캐쉬와 효율적 데이터 표현(representation)이 있다. 캐쉬는 (일반적으로 어떤 추상적인 값을 읽어 오는) I/O를 피하기 위해 그 값을 가깝게 복사해 놓아서 그 값을 가져오기 위해 I/O를 다시 발생시키지 않는 것을 말한다. 캐쉬의 핵심은 어떤 데이터가 원본(master)이고 어떤 데이터가 복사본인지 분명하게 구분하는 것이다. 원본은 단 하나만 있다! 캐쉬는 복사본이 원본의 변화를 즉시 반영하지 못하는 경우가 있다는 위험 부담이 있다.

효율적 데이터 표현이란 데이터를 더욱 효율적으로 표현하여 I/O의 비용을 줄이는 방식이다. 이 방법은 종종 가독성과 호환성 등의 다른 요구 조건과 대립되기도 한다.

효율적 데이터 표현은 처음의 표현 방식보다 두세 배의 개선 효과가 있기도 하다. 이를 위한 방법들로는 사람이 읽을 수 있는 표현 방식 대신 2진 표현 방식을 사용하는 것, 데이터와 함께 심벌 사전을 전송하여 긴 심벌들을 인코딩할 필요가 없게 하는 것, 그리고 극단적으로는 허프만(Huffman) 인코딩 같은 것 등이 포함된다.

때때로 가능한 세 번째 방법은 계산 부분을 데이터에 밀착시켜 더 가까운 곳에서 참조할 수 있게 하는 것이다. 예를 들어, 데이터베이스에서 어떤 데이터를 읽어 와서 합계와 같은 간단한 계산을 한다고 할 때 데이터베이스 서버가 직접 그 작업을 하게 하는 것이다. 이 방법은 작업하는 시스템의 특성에 매우 많이 의존하기는 하지만, 시험해 볼 필요는 있다.

2.1.9 메모리를 관리하는 방법

메모리는 절대로 다 써 버리면 안 되는 소중한 자원이다. 잠시 동안은 그것을 무시할 수 있겠지만 결국에는 메모리를 어떻게 관리할 것인지 결정해야 할 것이다.

단일 서브루틴이 차지하는 범위 이상으로 유지될 필요가 있는 공간을 종종 할당된 힙(heap)이라고 한다. 아무도 참조하지 않는 메모리 영역은 쓸모없는 쓰레기(가비지, garbage)일 뿐이다. 사용하는 시스템에 따라 메모리가 가비지가 될 것 같으면 명시적으로 메모리 할당을 해제해야 한다. 가비지 수집기를 제공하는 시스템을 사용할 수 있을 경우도 많다. 가비지 수집기는 가비지를 발견하면 프로그래머의 어떤 조작도 필요 없이 그것이 차지하는 공간을 풀어준다. 가비지 수집은 훌륭한 방법이다. 이를 통해 오류를 줄이고, 적은 노력으로도 코드를 더욱 간결하게 할 수 있다. 할 수 있다면 이 방법을 사용하라.

하지만 가비지 수집을 한다 해도 모든 메모리를 가비지로 채우게 될 수 있다. 고전적인 실수 중의 하나는 해쉬 테이블(hash table)을 캐쉬로 사용하고는 해쉬 테이블에 있는 참조 주소들을 제거하는 것을 잊어버리는 것이다. 참조 주소가 남아 있으므로 그 주소에 해당하는 메모리 영역은 가비지 수집이 될 수 없는 상태로 못 쓰게 된다. 이것을 메모리 누수(leak)라고 한다. 메모리 누수는 일찍부터 찾아서 고쳐야 한다. 장시간 실행되는 시스템이 있다면 검사할 때는 메모리가 고갈되는 일이 없다가 실제로 사용될 때가 돼서야 고갈되기도 한다.

새로운 객체의 생성은 어떠한 시스템에서도 어느 정도 시간 비용이 드는 작업이다. 하지만 서브루틴의 지역 변수들(local variables)에 직접 할당된 메모리는 할당 해제 방식이 매우 간단해질 수 있으므로 그렇게 시간 비용이 들지는 않는다. 어떻든 불필요한 객체 생성은 피해야 한다.

한 번에 필요한 객체 수의 상한을 정할 때 생기는 중요한 경우가 있다. 이 객체들이 모두 같은 양의 메모리를 필요로 한다면 그것들을 모두 수용하기 위해 단일 블록의 메모리, 즉 버퍼를 할당할 수 있을 것이다. 그 객체들은 이 버퍼 안에서 정해진 순환 방식에 따라 할당되고 해제될 수 있으므로 이 버퍼를 링 버퍼(ring buffer)라고 부르기도 한다. 이것은 보통 힙 할당보다 더 빠르다.

때로는 할당된 공간이 다시 할당될 수 있도록, 가비지 수집에 의존하는 대신, 그것을 명시적으로 풀어줘야 한다. 그래서 할당된 각 영역을 잘 알아내어 그것을 적절한 때에 해제하는 방법을 설계해야 한다. 그 방법은 생성된 객체의 종류에 따라 달라질 수 있다. 메모리 할당 작업이 수행될 때마다 그것이 결국에는 메모리 할당 해제 작업과 짝을 이뤄야 한다는 사실을 명심해야 한다. 이것은 매우 어렵기 때문에 프로그래머들은 이를 위해 단순하게 참조 회수 세기와 같은 기초적인 형태의 가비지 수집 방법을 구현하는 경우도 있다.

2.1.10 가끔씩 생기는 버그를 다루는 방법

가끔씩 생기는 버그는 "외계에서 온 20미터짜리 투명 전갈"의 사촌 같은 종류의 버그이다. 이 끔찍한 악몽은 관찰하기 어려울 만큼 가끔씩 나타나지만, 또한 무시할 수 없을 만큼 자주 일어난다. 이런 버그는 발견하기도 어렵게 때문에 고치기도 어렵다.

그 버그를 찾기 위해 여덟 시간을 매달린 뒤에 그것이 정말 있는 것인지 의심하기 시작한다 해도, 가끔씩 생기는 버그는 다른 모든 것들이 따르는 동일한 논리 법칙을 따를 수밖에 없다. 이 버그를 상대하기 힘든 것은 알지 못하는 어떤 조건들에서만 생기기 때문이다. 그 버그가 생기는 바로 그 때의 상황들을 기록하여 정말로 어떤 변이가 생긴 것인지 추측할 수 있도록 해 보라. 그 조건은, 예를 들어, '이 버그는 '와이오밍(Wyoming)'이라는 값을 입력했을 때만 생긴다"는 것과 같이, 데이터 값에 관련되어 있을 수도 있다. 만약 이것이 변이의 원인이 아니라면 다음으로는 동시에 수행되어야 하는 작업이 실제로는 그렇게 되지 못했을 경우를 의심해 볼 수 있다.

어떤 통제된 방식으로 그 버그가 다시 나타나도록 계속, 계속, 계속 시험해 보라. 다시 나타나게 할 수 없다면, 버그가 실제로 발생할 때 그것을 분석하기 위해 필요하다고 생각되는 정보들을 기록으로 남길 수 있는 (필요하다면 특별한) 로그 기록 시스템을 만들어 그 버그 앞에 덫을 놓아 보라. 버그가 개발 환경에서는 나타나지 않고 완성 제품에서만 나타난다면 그것은 오래 걸리는 프로세스 때문일 것이라고 믿어 보라. 로그 기록에서 얻는 실마리들은 해결책을 제공해 주지는 못하더라도 로그 기록 방법을 개선하기 위한 정보는 충분히 줄 수 있을 것이다. 개선된 로그 기록 시스템을 완성하는 데에는 오랜 시간이 걸릴 수도 있다. 그리고는 더 많은 정보를 얻기 위해 그 버그가 다시 나타날 때까지 기다려야 한다. 이 일은 어느 시간 동안 계속 반복해야 할 수도 있다.

가끔씩 생기는 버그들 중에서 내가 저지른 가장 어리석었던 것은, 어떤 수업의 프로젝트에서 함수형 프로그래밍 언어(functional programming language)를 다중 쓰레드로 구현하는 것이었다. 나는 그 함수형 프로그램이 모든 (이 수업에서는 여덟 개의) CPU들을 잘 활용하여 수치 계산을 동시에 정확하게 해 내도록 매우 주의를 기울였다. 그런데 가비지 수집기를 동기화하는 것을 깜빡 잊었다. 이 시스템은 오랜 시간 동안 잘 돌아갔고, 뭔가 이상하다는 것을 눈치 채기 전까지는, 어떤 작업을 시작하든 잘 마무리되는 것 같았다. 부끄럽게도 나는 내 실수가 드러나기 전까지는 하드웨어에 문제가 있다고 생각했었다.

최근에 일하면서는, 발견하기까지 몇 주나 걸렸던 가끔씩 생기는 버그를 만난 적이 있다. 우리에게는 아파치(Apache) 웹 서버 뒤에 자바(Java)로 구현된 다중 쓰레드 어플리케이션 서버들이 있다. 페이지 전환을 빠르게 유지하기 위해 우리는 모든 I/O가 페이지 전환 쓰레드들과는 다른 네 개의 독립된 쓰레드에서 일어나게 하고 있다. 그런데 이것들이 (우리 로그 기록에 따르면) 가끔 한 번씩 몇 시간 동안 멈춘 것처럼 되면서 아무 일도 하지 않았다. 쓰레드가 네 개가 있기 때문에 네 개 모두 멈추지 않는 한 그 자체로는 큰 문제는 아니었다. 그렇게 된다면 이 쓰레드들이 비워내는 큐(queue)가 남아 있는 모든 메모리를 순식간에 다 채워서 서버가 멈춰버렸을 것이다. 이것을 알게 되기까지 한 주 정도 걸렸지만 무엇 때문에 이런 일이 생기는지, 언제 생길지, 또는 멈출 때 어느 쓰레드가 어디쯤 작업을 하고 있는지조차 여전히 몰랐다.

이것은 타사 소프트웨어와 연관된 위험성을 보여준다. 우리는 텍스트에서 HTML 태그를 제거하는 코드의 사용권을 받아서 쓰고 있었다. 우리는 그 코드가 나온 나라 이름을 따서 그것을 '프랑스 스트리퍼'라는 애칭으로 불렀다. 우리는 소스 코드를 가지고 있었지만 (감사하나이다!) 우리 서버의 로그 기록을 살펴보다가 이메일 쓰레드들이 프랑스 스트리퍼에서 멈춘다는 것을 알게 되기까지 그 소스를 주의깊게 연구하지 않았다.

이 스트리퍼는 제대로 동작했지만 길이가 길고 특이한 텍스트에 대해서는 그렇지 못했다. 이런 텍스트를 처리하는 데에는 텍스트 길이의 제곱에 비례하거나 더 많은 시간이 걸렸다. 이런 텍스트들이 자주 나타나는 것이었다면 우리는 그 버그를 금방 발견했을 것이다. 그것이 전혀 나타나지 않았다면 우리는 전혀 문제가 없었을 것이다. 하지만 그것은 나타났고, 우리는 문제를 이해하고 해결하는 데 몇 주나 걸렸던 것이다.

2.1.11 설계 기능을 익히는 방법

소프트웨어를 설계하는 방법을 배우기 위해서는 사수(mentor)가 설계를 할 때 그들과 한 자리에 있으면서 그들의 행동을 연구하라. 그리고 잘 작성된 소프트웨어를 연구하라. 그 후에는 최근에 나온 설계 기법에 대한 책을 읽으라.

그리고 그것들을 직접 실천해야 한다. 소규모 프로젝트부터 시작하라. 최종 작업을 마쳤으면 그 설계가 어떻게 실패하거나 성공했는지, 처음 생각했던 개념에서 어떻게 달라졌는지 숙고하라. 이런 식으로 다른 사람들과 더 큰 프로젝트를 수행하게 된다. 설계 기능은 판단 능력의 문제이며, 그것을 얻기까지 몇 년은 걸린다. 현명한 프로그래머는 두 달이면 적당한 수준에서 기본 기능을 익힐 수 있을 것이며 그것을 기반으로 발전해 갈 것이다.

자기 자신의 스타일을 개발하는 것은 자연스러운 일이며 자신에게 도움이 될 것이다. 설계는 예술이지 과학이 아니라는 것을 명심하라. 이런 주제로 책을 쓰는 사람들은 흔히 그것이 과학적으로 보이게 하는 데에 관심을 갖는다. 하지만 특정한 설계 스타일을 고집하지는 않도록 하라.

2.1.12 실험을 수행하는 방법

이제는 고인이 된 위대한 에처 다익스트라(Edsger Dijkstra)는 전산 과학은 실험 과학이 아니며<ExpCS> 전자적인 컴퓨터에 의존하지 않는다고 설득력 있게 설명했다. 그가 1960년대의 전산 과학에 대해 다음과 같이 말했다. <Knife>

해로운 일이 일어났다. 이 주제는 '전산 과학'으로 알려지기 시작했다. - 이것은 꼭 외과 수술을 '칼 과학'이라고 부르는 것과 같다. - 그리고 전산 과학은 기계와 그 주변 장치들에 대한 학문이라고 사람들의 생각 속에 단단히 자리를 잡게 되었다.


프로그래밍이 실험 과학이 되어서는 안 되겠지만, 대부분의 실무 프로그래머들은 다익스트라가 전산 과학에 대해 내린 정의에 동감할 만큼 여유롭지는 못하다. 우리는, 전부는 아니더라도 일부 물리학자들이 그러하듯이, 실험의 영역 속에서 일해야 한다. 지금부터 30년 동안 프로그래밍이 실험 없이 이뤄질 수 있다면, 그것은 전산 과학의 위대한 승리라고 할 수 있을 것이다.

앞으로 해 보게 될 몇 가지 실험들은 다음과 같다.
  • 문서 내용에 부합하는지 검증하거나 (문서가 없다면) 시스템의 반응을 이해하기 위해 몇몇 표본들로 시스템을 검사하기
  • 실제로 버그가 고쳐졌는지 알아보기 위해 코드의 바뀐 부분을 검사하기
  • 시스템의 성능 특성을 완벽하게 알기 위해 두 가지 다른 조건에서 시스템의 성능을 측정하기
  • 데이터의 무결성을 점검하기
  • 어려운, 혹은 반복하기 힘든 버그 해결의 실마리를 얻기 위해 통계 자료를 수집하기

내가 이 글에서 실험 설계를 설명할 수 있으리라고는 생각하지 않는다. 독자 스스로 연구하고 연습해 보아야 할 것이지만, 두 가지 짧은 조언을 해 줄 수는 있겠다.

첫째, 자신의 가설이나 점검하려고 하는 검증 조건(assertion)이 무엇인지 명쾌해야 한다. 혼돈스럽거나 다른 사람들과 함께 작업할 때는 가설을 적어 보는 것이 도움이 되기도 한다.

각 실험이 지난 실험에서 얻은 지식에 기반을 두는 일련의 실험들을 설계해야 하는 상황에 처할 때가 종종 있을 것이다. 그러므로 가능한 한 많은 정보를 얻어낼 수 있도록 실험을 설계해야 한다. 불행히도 이것은 각 실험이 단순명료해야 한다는 조건과 대립된다. 이런 상황에 대한 판단은 경험을 통해 개발해야 할 것이다.

2.2 팀의 기능들

2.2.1 시간 추정이 중요한 이유

소프트웨어 시스템이 최대한 빨리 적극적으로 활용되게 하기 위해서는 개발 계획을 세우는 것뿐만 아니라 문서화, 시스템 배치, 마케팅 등의 계획도 세워야 한다. 상업적인 프로젝트에서는 영업과 재무도 포함한다. 개발 시간을 예측할 수 없다면 이러한 것들을 효과적으로 계획하는 것은 불가능하다.

정확한 시간 추정은 예측 가능성을 높인다. 관리책임자들은 그렇게 되는 것을 매우 좋아하며, 또 당연히 그래야 한다. 관리책임자들은 소프트웨어를 개발하는 데 얼마나 시간이 걸릴지 정확하게 예측하는 것이 이론적으로나 실제적으로 불가능하다는 사실을 전혀 이해하지 못하는 경우가 있다. 우리는 이런 불가능한 일을 하도록 항상 요구받으므로 그 사실을 정직하게 대면해야 한다. 어쨌든 이 과제가 불가능하다는 것을 인정하지 않는 것은 부정직한 일이 될 것이므로 필요하다면 그것을 설명하라. 사람들은,

그 문제를 제대로 이해한 것이라면, (아무도 그 동안 우리를 방해하지 않는다고 할 때) 5주 안에 마칠 가능성이 50% 정도 있다고 추정됩니다.


위의 문장이 실제로는,

그 일을 모두 5주 안에 틀림없이 마치겠습니다.


위의 문장을 뜻한다고 부풀려 생각하는 놀라운 경향이 있으므로, 시간 추정에 대해 의사소통의 문제가 생길 가능성이 많다.

이러한 일상적인 해석의 문제가 있으므로 상사나 고객이 아무 것도 모른다 생각하고 그 시간 추정이 무엇을 의미하는 것인지 분명하게 논의해야 한다. 그리고 예상 시간이 아무리 틀림없어 보여도 다시 한 번 더 그것을 추정해 보아야 한다.

2.2.2 프로그래밍 시간을 추정하는 방법

시간 추정은 연습이 필요하다. 또한 노력해야 한다. 시간 추정은 노력이 많이 드는 일이기 때문에, 특히 대규모 작업 시간을 추정해야 할 경우에는 시간 추정 자체에 드는 시간을 추정할 필요도 있다.

대규모 작업 시간을 추정해야 할 때에는 천천히 하는 것이 가장 정직한 것이다. 대부분의 기술자들은 열심이 있으며 사람들을 기쁘게 하고 싶어 하기 때문에 천천히 하는 것을 분명히 좋아하지 않을 것이다. 하지만 즉석으로 추정한 것은 대개 정확하지도 정직하지도 않다.

천천히 하는 동안 그 과제를 수행하거나 과제의 모형을 만드는 것에 대해 숙고할 수 있을 것이다. 정책의 압력을 피할 수 있다면 이것이 시간 추정을 도출할 수 있는 가장 정확한 방법이며, 실제로도 그대로 작업이 진행될 수 있을 것이다.

조사할 시간을 충분히 갖는 것이 불가능할 때에는, 우선 그 추정이 무엇을 뜻하는지 아주 분명하게 확정해야 한다. 추정 내용 기록의 첫 부분과 마지막 부분에 그 의미를 다시 써 놓으라. 과제를 점진적인 소규모 하위 과제들로 분해하되 각 소규모 과제가 하루 이상이 되지 않을 때까지, 이상적으로는 그 이하의 길이로 추정 내용 기록을 준비하라. 가장 중요한 것은 하나라도 빠뜨리는 일이 없도록 하는 것이다. 예를 들어, 문서화, 검사, 계획 시간, 다른 그룹과 회의 시간, 휴가 시간 등이 모두 매우 중요하다. 매일 바보들을 상대하며 보내는 시간이 있다면 그것도 추정 내용에 한 항목으로 적어 넣으라. 이렇게 하면 최소한 무엇 때문에 시간을 써 버리게 되는지 상사가 알아볼 수 있게는 될 것이며, 자신의 시간을 지킬 수 있게 될 것이다.

추정 시간을 은연중에 불려서 쓰는 기술자들도 있지만, 나는 그렇게 하지 말라고 권하고 싶다. 불려서 쓰는 것이 낳는 결과들 중 하나는 다른 사람의 신뢰를 잃게 된다는 것이다. 예를 들어, 어떤 기술자가 사실은 하루가 걸릴 것이라고 생각되는 어떤 과제를 3일로 추정했다고 하자. 그 기술자가 나머지 이틀은 문서 작업을 하거나 어떤 다른 유용한 프로젝트를 하겠다고 계획했을 수 있다. 하지만 그 과제가 단 하루 만에 끝났다는 것은 (그 사실이 알려졌다면) 추적할 수 있을 것이며, 일을 늦추거나 과대 추정했다는 기색이 보일 것이다. 자신이 실제로 하고 있는 것을 적절히 볼 수 있게 하는 것이 더욱 좋다. 문서 작업하는 데 드는 시간이 코딩 시간의 두 배가 된다는 사실을 시간 추정 내용에서 확인할 수 있다면, 이것을 관리책임자가 볼 수 있게 하는 것이 더욱 큰 이득이 될 것이다.

추정 시간은 숨김없이 불려서 쓰라. 어떤 과제가 하루가 걸릴 것 같은데, 현재 접근 방법이 들어맞지 않을 경우 열흘이 걸릴 수도 있다면, 이 사실을 어떻게든 추정 내용에 적으라. 그렇지 않으면 적어도 추정한 확률을 가중치로 한 평균값을 계산하라. 알 수 있고 추정할 수 있는 위험 부담 요소는 모두 일정에 들어가야 한다. 한 사람이라면 주어진 기간 동안 아프지 않을 수 있다. 하지만 여러 기술자들이 함께 하는 큰 프로젝트에서는 환자가 생기는 시간도 있고 휴가 기간도 있다. 필수로 참석해야 하는 회사의 연수 세미나가 일어날 확률은 얼마나 될까? 추정할 수 있다면 꼭 끼워 넣으라. 물론 알려지지 않은 미지수의 일, 즉 예측불허의 일들도 있다. 예측불허란 개별적으로는 추정할 수 없다는 말이다. 모든 예측불허의 일에 대해 공통적으로 쓰이는 한 항목을 만들거나, 상사와 의사소통하는 그 밖의 방식으로 그것들을 처리할 수 있을 것이다. 하지만 상사가 그것들의 존재를 잊어버리게 하지는 말라. 예측불허의 일을 생각하지 않고 시간을 추정한 그대로 일정이 잡히기는 지독하게도 쉽다.

팀 환경에서는, 그 일을 하는 사람이 그 시간을 추정하도록 해야 하며, 전체 추정 시간에 대해 팀 전체가 합의하도록 해야 한다. 사람들은 능력, 경험, 준비도, 자신감에 큰 차이가 있다. 능력 있는 프로그래머가 자기에게 맞게 추정한 것을 능력이 부족한 프로그래머들도 따라 하다가는 큰 문제가 생긴다. 팀 전체가 추정 내용에 대해 한 줄, 한 줄씩 동의하게 함으로써 팀 전체의 이해를 분명히 하고, 자원을 전술적으로 재분배할 수 있는 (예를 들어, 능력이 부족한 팀원에게서 능력 있는 팀원에게 짐을 넘기는) 기회도 생긴다.

수치로 나타낼 수 없는 큰 위험 부담이 있다면, 프로그래머는 관리책임자가 함부로 거기에 뛰어들었다가 그 위험이 발생했을 때 당황하지 않도록 강력하게 말해 줄 의무가 있다. 바라기에는 그 경우에 그 위험 부담을 줄이기 위해 필요한 모든 일을 하게 될 것이다.

익스트림 프로그래밍(Extreme Programming) 기법을 사용하도록 회사를 설득할 수 있다면 비교적 적은 것들만 추정해도 될 것이며, 더 재미있으면서 더 생산적으로 일할 수 있을 것이다.

2.2.3 정보를 찾는 방법

알아야 하는 정보의 성격에 따라 그것을 찾는 방법이 결정된다.

어떤 소프트웨어의 최근 패치 단계와 같이 객관적이고 검증하기 쉬운 구체적인 것들에 대한 정보가 필요하다면, 그 정보에 대해 인터넷을 검색하거나 토론 그룹에 글을 올려 많은 사람들에게 공손히 물어 보라. 의견이나 주관적인 해석의 낌새가 있는 것은 절대 인터넷에서 검색하지 말라. 허튼 소리가 진실로 취급되는 비율이 매우 놓다.

어떤 것에 대한 생각이 변화해 온 역사와 같이 주관적인 것에 대한 일반적인 지식을 원한다면, (실제 건물이 있는) 도서관으로 가라. 예를 들어, 수학이나 버섯이나 신비주의에 대해 알고 싶다면 도서관으로 가면 된다.

사소하지 않은 어떤 일을 하는 방법을 알고 싶다면 그 주제에 대한 책을 두세 권 사서 읽으라. 소프트웨어 패키지를 설치하는 방법 같은 사소한 일을 하는 방법은 인터넷에서 배울 수 있다. 좋은 프로그래밍 기법 같은 중요한 것들을 인터넷에서 배울 수도 있지만, 그 결과를 검색하고 분류하거나 그 결과가 믿을 만한 것인지 파악하느라, 손으로 잡을 수 있는 책의 적당한 부분을 찾아 읽는 데 드는 시간보다 더 많은 시간을 낭비할 가능성이 크다.

"이 신제품 소프트웨어는 대규모의 데이터를 처리할 수 있는가?"와 같이 아무도 알 것 같지 않은 정보가 필요하다면, 어쨌든 인터넷이나 도서관을 검색해 봐야 할 것이다. 열심히 찾아도 찾을 수 없다면 그것을 확인하기 위한 실험을 설계해야 할 것이다.

어떤 특정한 상황에 대한 의견이나 가치 판단을 원한다면, 전문가에게 이야기하라. 예를 들어, 최신 데이터베이스 관리 시스템(DBMS)을 LISP로 만드는 것이 좋은 생각인지 알고 싶다면 LISP 전문가와 데이터베이스 전문가와 이야기해야 한다.

어떤 응용프로그램을 위한, 아직 발표되지 않은 더 빠른 알고리듬이 있는지 알고 싶다면 그 분야에서 일하는 사람과 이야기해야 할 것이다.

사업을 시작할 것인지 말 것인지에 대한 결정과 같이 자신만이 내릴 수 있는 개인적인 결정을 하려고 한다면, 그 생각에 대한 긍정적인 조건과 부정적인 조건을 나열해서 적어 보라. 그래도 결정을 못하겠다면 점(divination)을 쳐 보라. 어떤 생각에 대해 다각도로 연구해 봤고, 해야 할 일을 다 했고, 모든 결과와 긍정적, 부정적 조건들을 다 따져 봤다 해도, 아직은 결정하지 마라. 이제 머리는 잠시 쉬고 마음의 움직임을 따라 보라. 잘 의식하지 못하는 자신의 욕망을 파악하는 데에는 다양한 점 기법들이 유용하게 쓰일 수 있다. 이 기법들이 보여 주는 모호하고 무작위적인 패턴에 대해 자신의 잠재의식이 의미를 부여하게 될 것이기 때문이다.

2.2.4 사람들을 정보의 원천으로 활용하는 방법

각 사람의 시간을 존중하고 자신의 시간과 균형을 맞추라. 어떤 사람에게 질문하는 것은 답을 얻는다는 것 이상의 것을 이루게 한다. 그 사람은 나의 존재를 인정하고 특정 질문에 귀를 기울이면서 나에 대해 알게 된다. 나도 마찬가지로 그 사람을 알게 되며, 찾던 답도 알 수 있게 된다. 대개의 경우 이것이 질문 자체보다 더욱 중요하다.

하지만 그것을 반복하게 되면 그 가치는 줄어든다. 질문을 한다는 것은 결국 어떤 사람이 갖고 있는 소중한 필수품, 즉 그들의 시간을 사용하는 것이다. 의사소통의 소득은 그 비용과 비교하여 저울질해 보아야 한다. 게다가 그 비용과 소득은 사람마다 다르다. 나는 100명의 부하 직원이 있는 사람은 그 조직의 모든 사람들에게 한 달에 5분씩은 이야기할 시간이 있어야 한다고 확신한다. 이것은 자기 시간의 약 5%를 할애하는 것이 될 것이다. 하지만 10분은 너무 많은 것 같고, 같은 5분이라 해도 직원이 1,000명이라면 그것도 너무 많다. 자신의 조직에 속한 사람들에게 이야기하는 시간의 양은 그 사람들의 (직위보다는) 역할에 따라 다르다. 상사에게 이야기하는 시간이 상사의 상사에게 이야기하는 시간보다는 더 많아야 한다. 불편할 수도 있겠지만, 무엇에 대해서든 자신의 모든 상급자들에게 매달 조금씩 이야기를 할 의무가 있다고 생각한다.

여기에서 기본 법칙은, 우리에게 잠깐 이야기를 하는 사람은 모두 이득을 얻지만, 이야기가 길어질수록 그 이득은 적어진다는 것이다. 우리는 그들에게 이 이득을 나눠주고 그들과 대화하면서 이득을 받아와야 하며, 들인 시간과 이득 사이에 균형을 맞춰야 한다.

자신의 시간을 존중하는 것도 중요하다. 누군가에게 이야기하는 것을 통해, 그들의 시간을 쓰게 한다 해도, 자신의 시간을 많이 아낄 수 있다면, 그 사람의 시간이 나의 시간보다 더 소중하다고 생각하지 않는 한, 그것을 해야 한다. 우리 부족(tribe)에 대해서도 마찬가지이다.

특이한 사례로서 여름방학 인턴의 경우를 들 수 있다. 고급 기술직에 들어온 여름방학 인턴이 무슨 큰 일을 해 낼 것이라고 기대하기는 힘들다. 그들은 단지 거기 있는 모든 사람들을 괴롭게 할 것이라고 기대할 수 있을 것이다. 그렇다면 왜 이걸 참아야 하는가? 괴롭힘을 받는 사람은 그 인턴에게서 중요한 것을 얻게 될 것이기 때문이다. 그들은 살짝 자랑할 수 있는 기회가 생긴다. 새로운 아이디어를 들을 기회가 생길지도 모른다. 다른 시각에서 관찰해 볼 기회가 생긴다. 그 인턴을 채용하려는 의도가 있을 수도 있지만, 그렇지 않다 하더라도 얻는 것이 많다.

솔직히 누군가가 도움이 되는 말을 해 줄 수 있겠다는 생각이 들면, 그들에게 지혜와 판단력을 나눠 달라고 부탁해야 한다. 그러면 그 사람들은 뿌듯해 할 것이며, 나는 그들에게 무엇인가를 배우고 또 무엇인가를 가르쳐 주게 될 것이다. 좋은 프로그래머에게 영업 부사장의 조언은 별로 필요가 없겠지만, 만약 필요하게 된다면 반드시 조언을 구해야 한다. 나는 우리 영업부 직원들이 하는 일을 더 잘 이해하기 위해서 영업 관련 전화 통화 내용 몇 건을 같이 듣게 해 달라고 요청한 적도 있다. 30분도 채 안 걸린 일이었지만 그런 작은 노력이 영업부에 좋은 인상을 주었다고 생각한다.

2.2.5 현명하게 문서화하는 방법

아무도 읽지 않을 쓰레기 같은 글을 쓰기에는 인생은 너무 짧다. 쓰레기 같은 글은 아무도 읽지 않을 것이다. 따라서 문서화를 조금이라도 잘 하는 것이 최선이다. 관리책임자들은 이것을 이해하지 못하는 경우가 많다. 질이 떨어지는 문서를 보면서도 그들이 프로그래머들에게 의존하지 않고 있다는 헛된 안도감을 갖게 하기 때문이다. 누가 나에게 내가 작성한 문서가 정말 쓸모없다고 단호하게 말한다면, 그 말을 인정하고 조용히 다른 직업을 찾아보는 게 좋을 것이다.

문서를 잘 만들어내는 데 걸리는 시간의 양을 정확히 추정하여 문서화에 대한 요구를 완화시키는 데 드는 시간을 추정하는 데 이용하는 것만큼 효과적인 일은 없을 것이다. 진실은 냉혹하다. 문서화는 제품 검사처럼 코드 개발보다 더 긴 시간이 걸릴 수 있다.

문서화를 잘 하기 위해서는 우선 작문 실력이 있어야 한다. 작문에 대한 책을 찾아서 공부하고 실습해 보기를 권한다. 글이 깔끔하지 못하고 문서에 써야 하는 언어를 잘 모른다 해도, 다음의 황금률을 따르면 된다. "무엇이든지 남에게 대접을 받고자 하는 대로 너희도 남을 대접하라." 시간 여유를 가지고서 이 문서를 읽을 사람이 누구이며, 그 사람이 무엇을 얻고 싶어 할지, 그리고 그것을 어떻게 가르쳐 줄 수 있을지 진지하게 생각해 보라. 그렇게만 해도 평균 수준 이상의 문서는 만들어낼 수 있을 것이며 프로그래머로서도 훌륭하게 될 것이다.

코드 자체에 대해 문서화를 하게 될 때에는, 프로그래머가 아닌 사람들이 주로 읽을 문서를 작성할 때와는 반대로, 내가 아는 최고의 프로그래머들이 모두 공감하고 있는 바와 같이, 보면 바로 알 수 있게 코드를 작성하고, 코드만으로 그 의미가 분명하지 않은 곳에만 코드에 대해 문서화하라. 이렇게 하는 것이 좋은 두 가지 이유가 있다. 첫째로, 코드 수준의 문서를 봐야 하는 사람이라면 대부분의 경우에 어떻게든 그 코드를 읽을 수 있으며 그것을 선호하기 때문이다. 물론, 이것은 초보보다는 경력 있는 프로그래머에게 더 적당한 말이다. 하지만 더 중요한 것은, 따로 문서화하지 않을 경우, 코드와 문서가 불일치할 리가 없을 것이라는 사실이다. 소스 코드는 아무리 잘못되어 봐야 틀리거나 혼돈스러울 뿐이다. 하지만 문서는 정확하게 쓰지 않는다면 거짓말을 할 수 있고 이것은 천 배나 더 나쁜 일이다.

책임감 있는 프로그래머는 이 사실을 가볍게 받아들이지 않을 것이다. 보면 바로 알 수 있는 코드를 어떻게 작성할 것인가? 그것이 과연 무슨 뜻인가? 바로 이런 뜻이다.
  • 누군가 읽을 것이라는 사실을 염두에 두고 코드를 작성하기
  • (앞에서 말한) 황금률을 적용하기
  • 복잡하지 않은 해법을 선택하기 (다른 해법이 용케 더 빠르다 해도)
  • 코드를 어지럽게 하는 사소한 최적화 시도는 포기하기
  • 코드를 읽을 사람을 생각하면서 그 사람이 쉽게 이해할 수 있게 하기 위해 시간을 할애하기
  • "foo", "bar", "doIt" 같은 함수명은 절대 쓰지 않기!

2.2.6 형편없는 코드를 가지고 작업하기

다른 사람이 작성한 질이 떨어지는 코드를 가지고 작업해야 하는 경우가 많다. 하지만, 신발을 신고 걸어 보기까지는 그 신발이 아주 형편없다고 생각하지는 말라. 그 사람이 일정의 압박에 맞추기 위해 어떤 일을 빨리 끝내도록 독촉을 받았을 수 있다. 어떻든 간에, 불분명한 코드를 가지고 작업을 하려면 그것을 이해해야 한다. 그 코드를 이해하자면 시간이 걸릴 것이고, 그 시간은 정해진 일정의 어디에선가 빼 와야 할 것이므로, 이 사실을 분명히 해야 한다. 소스 코드를 이해하기 위해서는 그것을 읽어 볼 수밖에 없다. 아마도 그것을 가지고 실험을 해 봐야 할 것이다.

비록 자기 자신만을 위한 것이라 해도, 코드에 대한 문서화 노력을 통해 생각해 보지 못했던 각도에서 그 코드를 생각해 볼 수 있으므로, 지금이 문서화하기 좋은 시간이며, 그 결과로 나온 문서는 유용할 것이다. 이렇게 하는 동안 그 코드의 일부나 전체를 재작성하려면 무엇이 필요할 것인지에 대해 생각해 보라. 그것을 재작성하는 것이 실제로 시간을 아끼는 일이 될 것인가? 코드를 재작성한다면 더 믿을 만하게 될 것인가? 이 때에는 자만심을 주의하도록 하라. 코드를 재작성한다면, 그것을 검사해야 하는 부담은 얼마나 될 것인가? 얻을 수 있는 이득과 비교해 볼 때 정말로 재검사할 필요가 있는 것인가?

자기가 작성하지 않은 코드에 대한 작업 시간을 추정할 때, 그 코드의 품질에 따라 문제나 예측불허의 것이 생길 위험 가능성에 대한 인식이 달라진다.

깔끔하지 못한 코드에는 프로그래머의 최고의 도구 두 가지, 즉 추상화와 캡슐화가 특히 잘 적용된다는 사실을 잘 기억해 두라. 코드의 큰 부분을 재설계할 수는 없겠지만, 어느 정도 추상화를 해 줄 수 있다면, 전체를 재작업하지 않고서도 좋은 설계가 주는 이득을 어느 정도는 얻을 수 있을 것이다. 특히 안 좋은 부분은 다른 부분에서 떼어 놓아 독립적으로 재설계할 수 있도록 해 볼 수도 있다.

2.2.7 소스 코드 제어 시스템을 이용하는 방법

소스 코드 제어 시스템은 프로젝트를 효과적으로 관리할 수 있게 해 준다. 이 시스템은 개인에게도 유용하고 그룹에게는 필수적이다. 이 시스템은 여러 버전의 모든 변경 사항을 추적하므로 어떤 코드도 없어지지 않으며 변경 사항들의 의미를 기록해 놓을 수 있다. 소스 코드 제어 시스템이 있으면 소스 코드의 일부를 버리거나 디버그 코드를 넣는 일을 자신 있게 할 수 있다. 변경한 코드는 팀과 공유하거나 배포할 공식 코드와 잘 분리되어 보존되기 때문이다.

나는 뒤늦게야 소스 코드 제어 시스템의 이득을 알게 되었지만, 이제는 혼자 하는 프로젝트라 해도 그것 없이는 살 수 없을 것 같다. 일반적으로 이 시스템은 동일한 코드를 놓고 팀으로 작업할 때 필요하다. 하지만 이 시스템은 또 다른 큰 장점이 있다. 즉 이것을 통해 소스 코드를 성장하는 유기체로 인식하게 해 준다는 점이다. 변경된 것마다 새 이름이나 번호를 붙여 새로운 개정판으로 표시하기 때문에, 소프트웨어가 눈에 보이게 점진적으로 향상되어 간다고 생각하게 되는 것이다. 이것은 특히 초보자들에게 유용하다고 생각된다.

소스 코드 관리 시스템을 잘 이용하는 방법 중 하나는, 항상 최신의 상태를 유지하면서 며칠 동안 가만히 있는 것이다. 며칠 안에 마무리할 수 없는 코드는 체크인 상태로 있지만, 그것은 활성화되지 않고 호출되지 않을 상태로 있거나, 그 자신에서 갈라져 나온 분기(branch) 위치에 있을 것이므로, 다른 누구에게 어떠한 문제도 일으키지 않을 것이다. 실수가 있는 코드를 올려서 팀 동료들의 작업을 더디게 하는 것은 심각한 오류이다. 이것은 언제나 금기 사항이다.

2.2.8 단위별 검사를 하는 방법

단위별 검사, 즉 코드로 만든 기능의 각 부분을 그것을 작성한 팀에서 검사하는 것은 코딩의 일부이지, 코딩과 다른 무엇이 아니다. 코드를 어떻게 검사할지 설계하는 것도 코드 설계의 한 부분이다. 비록 한 줄이라 해도 검사 계획을 기록해 놓아야 한다. 때때로 그 검사는 다음과 같이 단순할 것이다. "이 버튼이 좋아 보이는가?" 때로는 다음과 같이 복잡할 수도 있다. "이 정합(matching) 알고리듬은 틀림없이 정확한 짝을 찾아낼 것인가?"

할 수 있다면 검증 조건(assertion) 확인 방법이나 검사 자동화 도구(test driver)를 사용하라. 이 방법은 버그를 일찍 잡을 수 있게 해 줄 뿐만 아니라, 나중에도 유용하게 쓰일 수 있으며, 이렇게 하지 않았더라면 한참 고민하게 되었을 애매한 문제들을 줄일 수도 있을 것이다.

익스트림 프로그래밍(Extreme Programming) 기법을 사용하는 개발자들은 단위별 검사를 최대한 효과적으로 활용하여 코드를 작성한다. 이 작성 방법을 추천하는 것만큼 좋은 일도 없을 것이다.

2.2.9 막힐 때는 잠깐 쉬어라

막힐 때는 잠깐 쉬어라. 나는 막힐 때는 15분 정도 명상을 하곤 한다. 그러면 다시 문제로 돌아왔을 때 그것이 마술같이 해결되곤 한다. 규모가 클 경우에는 하룻밤 잘 자는 것이 같은 효과를 내기도 한다. 잠시 다른 활동을 하는 것이 효과적일 수도 있다.

2.2.10 집에 갈 시간을 인지하는 방법

컴퓨터 프로그래밍은 문화라고 할 만한 활동이다. 불행한 것은, 이것이 정신적, 신체적 건강을 그렇게 중요하게 생각하지 않는 문화라는 사실이다. 문화적이고 역사적인 이유 (예를 들어, 컴퓨터가 쉬는 밤중에 작업할 필요) 때문에, 그리고 저항할 수 없는 출시 일정의 압박과 프로그래머의 부족 때문에 컴퓨터 프로그래머는 전통적으로 초과 근무를 해 왔다. 소문으로 듣는 모든 이야기를 믿을 것이라고 생각하지는 않지만, 주당 60시간 근무는 일상적이며, 50시간은 상당히 적은 편에 속한다. 즉, 이보다 더 많은 시간이 요구되는 경우가 있다는 말이다. 이것은 좋은 프로그래머에게는 심각한 문제이다. 그는 자기 자신만 아니라 자기 팀 동료들도 책임지고 있기 때문이다. 자기가 집에 갈 시간, 때로는 다른 사람을 집에 보낼 시간도 인지하고 있어야 한다. 아이를 키우는 불변의 법칙이 없듯이, 이 문제를 해결할 불변의 법칙은 없다. 모든 사람은 서로 다르기 때문이다.

주당 60시간 이상 일하는 것은, 짧은 기간 (한 주 정도) 동안이나 해 볼 수 있을 정도로, 내게는 엄청난 노력이 필요하지만, 때로는 그렇게 해야 할 때가 있다. 한 사람에게 60시간 동안 일을 하게 하는 것이 공정한 것인지는 잘 모르겠다. 사실 40시간이 공정한 것인지도 잘 모르겠다. 하지만 분명한 것은, 초과 근무하는 시간 동안 별로 얻는 것 없이 오래 일하기만 하는 것은 어리석은 일이라는 사실이다. 나에 대해 말하자면, 주당 60시간 이상 일하는 것이 그렇다. 개인적으로는, 프로그래머는 고귀한 의무(noblesse oblige)를 다해야 하고 무거운 짐을 져야 한다고 생각한다. 하지만 봉이 되는 것은 프로그래머의 의무가 아니다. 그런데 슬프게도 프로그래머들은, 경영진의 눈에 들기 위해 애쓰는 관리책임자 같은 이들을 위해 재주를 부리는 곰이 되는 경우가 있다. 프로그래머들은, 다른 사람들을 기쁘게 하고 싶고, 싫다는 말을 잘 못하기 때문에, 종종 이런 요구에 굴복한다. 이를 대처하기 위한 네 가지 방어법이 있다.
  • 회사의 모든 사람들과 최대한 많이 대화하여 아무도 무슨 일이 일어나고 있는지에 대해 경영진을 현혹하지 못하게 하라.
  • 시간을 추정하고 일정을 잡을 때 방어적이고 명백하게 하여, 모든 사람들이 일정이 어떻게 되고 현재 어디쯤 가고 있는지 잘 볼 수 있게 하라.
  • 요구를 거부하는 법을 배우고, 필요하다면 팀이 함께 거부하도록 하라.
  • 어쩔 수 없다면 회사를 그만두라.

많은 프로그래머들이 좋은 프로그래머이고, 좋은 프로그래머는 많은 것을 이루길 원한다. 이를 위해 그들은 시간을 효과적으로 관리해야 한다. 어떤 문제에 대해 생각을 가다듬고 거기에 깊이 몰두하게 될 때까지는 상당한 수고가 필요하다. 많은 프로그래머들은 생각을 가다듬고 몰두할 수 있는, 방해받지 않는 긴 시간이 있을 때 가장 잘 일할 수 있다고 한다. 하지만 사람들은 잠도 자고 다른 의무들도 이행해야 한다. 모든 사람들은 자신의 인간적 리듬과 업무적 리듬을 모두 만족시키는 방법을 찾아야 한다. 모든 프로그래머는, 아주 중요한 회의에만 참석하고 나머지는 일에 집중하는 날들을 확보하는 것과 같이, 효율적인 업무 기간을 획득하기 위해 최선을 다해야 한다.

나는 아이들이 있기 때문에 가끔이라도 아이들과 저녁 시간을 보내기 위해 노력한다. 나에게 가장 잘 맞는 리듬은, 하루 날 잡아 오래 일하고, 사무실이나 사무실 부근에서 잠을 잔 다음 (나는 집에서 직장까지 통근 시간이 길다), 일찍 집에 가서 아이들이 잠자리에 들기 전까지 시간을 보내는 것이다. 이것이 편안하지는 않지만, 여태껏 시험해 본 최선의 타협점이었다. 전염성 있는 병에 걸렸다면 집에 가라. 죽고 싶다는 생각이 든다면 집에 가야 한다. 몇 초 이상 누군가를 죽이고 싶다는 생각이 든다면 집에 가서 쉬어야 한다. 누군가가 가벼운 우울증을 넘어서 심각한 정신 이상이나 정신병의 증세를 보인다면 집에 가게 해야 한다. 피로 때문에 평소와 달리 부정직하거나 남을 속이고 싶다는 유혹이 든다면 쉬어야 한다. 피로와 싸우기 위해 마약이나 각성제를 쓰지 말라. 카페인을 남용하지도 말라.

2.2.11 까다로운 사람들과 상대하는 방법

까다로운 사람들과 상대해야 하는 일이 있을 것이다. 자기 자신이 까다로운 사람일 수도 있다. 나 자신이 같이 일하는 사람들이나 권위 있는 인물들과 수시로 충돌하는 유형의 사람이라면, 여기에서 볼 수 있는 독립심은 소중하게 여겨야 할 것이나, 자신의 지성이나 원칙들을 희생하지 않는 범위 내에서 인간관계의 기능도 길러야 할 것이다.

이런 종류의 일을 겪어 보지 않았거나, 지금까지 살면서 직장 생활에는 별로 쓸모없는 행동 양식만 익혀 온 프로그래머들에게는 이것이 짜증스러운 일이 될 수 있다. 까다로운 사람들은 대개 반대 의견에 단련되어 있고 다른 사람들과 타협해야 한다는 사회적 압력에 별로 영향을 받지 않는다. 이 때 열쇠는 그 사람들을 적당히 존중해 주는 것이다. 이것은 내가 하고 싶은 것 이상으로 해 주는 것이지만, 그 사람들이 원하는 만큼은 안 될 것이다.

프로그래머들은 팀으로 함께 일해야 한다. 의견 불일치가 생기면, 어떻게든 해결해야 한다. 무작정 피할 수는 없는 노릇이다. 까다로운 사람들은 종종 매우 똑똑하고 쓸 만한 이야기를 하기도 한다. 까다로운 사람에게 편견 없이 귀를 기울이고 이해해 주는 것은 매우 중요하다. 대화 단절은 의견 불일치의 기반이 되지만, 강한 인내심으로 극복할 수 있는 경우도 있다. 대화가 산뜻하고 정감 있게 이뤄지도록 노력하고, 의견 충돌을 일으킬 만한 논쟁에 말려들지 말라. 이해하려고 노력할 만큼 한 뒤에는 결단을 내리라.

으스대는 사람의 강요 때문에 동의하지도 않는 일을 하지는 말라. 자신이 팀장이라면 최선이라고 생각하는 일을 하라. 개인적 이유로 결정을 내리지 말고, 자기가 결정한 근거를 설명할 준비를 해 두라. 까다로운 사람이 팀장이라면, 그의 결정이 개인적으로 영향을 미치지 않도록 하라. 일이 자기 방식대로 진행되지 않아도, 그 다른 방식에 따라 마음을 다해 일하라.

까다로운 사람들도 변하며 나아지기도 한다. 내 눈으로 직접 본 적도 있지만, 그렇게 흔하지는 않다. 어쨌든 모든 사람은 수시로 오르락내리락하기 마련이다.

모든 프로그래머, 특히 팀장들이 대면해야 하는 도전들 중 하나는 까다로운 사람을 전적으로 몰두하게 하는 것이다. 그런 사람들은 다른 사람에 비해서 일의 책임을 피하거나 수동적으로 저항하는 경향이 크다.

3 중급자

3.1 개인적 기능들

3.1.1 의욕을 계속 유지하는 방법

프로그래머들이 아름답고 유용하고 멋진 것을 만들고 싶어 하는 의욕이 매우 크다는 사실은 훌륭하고도 놀라운 일이다. 이러한 욕구는 프로그래머에게만 있는 것도 아니고 보편적인 것도 아니지만, 이것은 프로그래머들 사이에 매우 강하고 일반적이어서 다른 일을 하는 사람들과 구분이 된다.

이것은 실제로 중요한 결과를 낳는다. 프로그래머에게 아름답지도 유용하지도 멋지지도 않은 일을 시키면 그들은 사기가 떨어진다. 너저분하고 멍청하고 지루한 일을 해서 돈을 많이 벌기도 한다. 하지만 결국에는 재미있게 하는 일이 회사에 큰 돈을 벌어다 준다.

분명히 의욕을 불러일으키는 기법들을 중심으로 조직된 모든 산업 분야에서 여기에 적용되는 것들이 있다. 프로그래밍에 해당한다고 인정할 만한 것들은 다음과 같다.
  • 그 일을 자랑스럽게 이야기한다.
  • 새로운 기법, 언어, 기술을 적용할 기회를 찾는다.
  • 각 프로젝트에서 아무리 작더라도 무엇인가를 배우거나 가르치려고 노력한다.

끝으로, 할 수 있다면, 개인적으로 의욕을 얼마나 고취시키는가에 따라 자신의 일의 영향력을 가늠해 보라. 예를 들어, 버그를 고칠 때, 내가 버그를 몇 개나 고쳤는지 세는 것으로 의욕이 생기지는 않는다. 지금까지 고친 버그의 개수가 아직 남아 있는 버그의 개수와 무관하며, 그 개수는 회사의 고객들에게 기여하는 전체 가치에서 아주 사소한 부분을 차지할 뿐이기 때문이다. 하지만, 버그 하나마다 고객 한 사람이 기뻐한다고 생각하면 그것은 개인적으로 의욕이 생기게 한다.

3.1.2 널리 신뢰받는 방법

신뢰받기 위해서는 신뢰받을 만해야 한다. 또한 활동이 두드러져야 한다. 자신에 대해 아무도 알지 못한다면, 아무런 신뢰도 받을 수 없을 것이다. 팀 동료처럼 자신과 가까운 사람들과 같이 있을 때는 이것이 큰 문제가 아닐 것이다. 신뢰는 자기 부서나 팀이 아닌 사람들에게 응답하고 지식을 줌으로써 쌓아간다. 때로는 이러한 신뢰를 악용하여 불합리한 부탁을 하는 사람도 있다. 이럴 때에는 걱정하지 말고, 그 부탁을 들어주자면 자신이 무슨 일을 포기해야 하는지 설명하면 된다.

모르는 것을 아는 체하지 말라. 팀 동료가 아닌 사람들에게는 "머리에서 맴돌면서 기억나지 않는 것"과 "전혀 알 수 없는 것"을 명확히 구분해야 할 것이다.

3.1.3 시간과 공간 사이에서 균형을 잡는 방법

대학에 가지 않아도 좋은 프로그래머는 될 수 있지만, 기초적인 계산 복잡도 이론을 모른다면 좋은 중급 프로그래머는 될 수 없다. O("big O") 표기법을 알 필요는 없지만, "상수 시간", "n log n", "n 제곱"의 차이는 이해할 수 있어야 한다. 이런 지식이 없어도 시간과 공간 사이에서 균형을 잡는 방법을 직관으로 알고 있을 수 있지만, 그런 지식이 없다는 것은 동료들과 대화할 때 필요한 튼튼한 기초가 없는 것과 같다.

알고리듬을 설계하거나 이해할 때, 그것을 실행하는 데 걸리는 시간은 입력 값의 크기의 함수인 경우가 있다. 이 때, 알고리듬의 실행 시간이 (변수 n으로 표현되는) 그 크기와 그 크기의 로그값의 곱에 비례하면, 그 최악(또는 기대되는, 또는 최선)의 실행 시간이 "n log n"이라고 말할 수 있다. 이 표기법과 말하는 방식은 자료 구조가 차지하는 공간에도 마찬가지로 적용될 수 있다.

내게는, 계산 복잡도 이론이 물리학만큼이나 아름답고 심오하게 보인다. (조금 딴 길로 샌 것 같다!)

시간(프로세서 속도)과 공간(메모리)은 서로 균형을 맞출 수 있다. 공학이란 타협에 대한 것이며, 이것은 아주 좋은 예가 된다. 이것은 항상 체계적인 것은 아니다. 일반적으로 꽉 조이는 인코딩을 통해 공간을 절약할 수 있지만, 그것을 디코딩해야 할 때는 계산 시간이 더 많이 걸릴 것이다. 캐쉬를 사용함으로써, 즉 가까이에 복사본을 저장할 공간을 사용함으로써 시간을 절약할 수 있지만, 캐쉬의 내용을 일관되게 유지하고 있어야 할 것이다. 자료 구조에 더 많은 정보를 담음으로써 시간을 절약할 수 있는 경우가 있다. 이것은 대개 적은 공간을 차지하지만 알고리듬이 복잡해질 수 있다.

공간이나 시간의 균형 관계를 개선하는 것은 종종 다른 쪽이 극적으로 변하게 할 수 있다. 하지만 이 작업을 하기 전에 지금 개선하려고 하는 것이 정말로 그런 개선이 필요한 것인지 스스로 물어야 한다. 알고리듬을 가지고 작업하는 것은 재미있는 일이지만, 아무 문제가 없는 것을 개선하려는 것은 눈에 띌 만한 차이는 못 내면서 검사할 짐만 늘어나게 할 것이라는 냉엄한 사실에 대해 눈이 가려지지 않도록 조심해야 한다.

최신 컴퓨터의 메모리는, 프로세서 시간과 달리 벽에 부딪히기 전까지는 그것이 어떻게 쓰이는지 볼 수 없기 때문에, 값싼 것처럼 보인다. 하지만 문제가 생기기라도 하면 그것은 재앙이 된다. 메모리를 사용하는 데에는, 메모리에 상주해야 하는 다른 프로그램에 미치는 영향이나, 메모리를 할당하고 해제하는 데 드는 시간 등의 숨어 있는 비용이 있다. 속도를 얻으려고 공간을 써 버리기 전에 이 사실을 주의 깊게 생각하라.

3.1.4 압박 검사를 하는 방법

압박 검사(stress test)는 재미있다. 처음에는 압박 검사의 목적이 시스템에 부하가 걸려도 잘 동작하는지 알아보는 것으로 보인다. 실제로는 시스템에 부하가 걸려도 잘 동작하지만 부하가 아주 클 때는 어떤 방식으로든 동작이 멈추는 경우가 대부분이다. 나는 이것을 벽에 부딪침 또는 탈진이라고 부른다. 예외가 있기도 하지만, 거의 항상 '벽'은 있다. 압박 검사의 목적은 그 벽이 어디에 있는지 알아보는 것이며, 그 벽을 얼마나 더 밀어낼 수 있을지 알아보는 것이다.

압박 검사 계획은, 그것을 통해 프로젝트에서 기대하는 바가 무엇인지 명확해지기 때문에, 프로젝트 초기에 세워야 한다. 웹 페이지 요청에 2초가 걸리는 것은 비참한 실패일까, 대단한 성공일까? 동시 사용자 500명은 충분한가? 이것은 물론 상황에 따라 다르지만, 그 요구에 부응하는 시스템을 설계할 때 그 답을 알고 있어야 한다. 압박 검사는 실제 상황을 충분히 쓸 만하게 본떠서 해야 한다. 동시에 시스템을 사용하면서 오류를 일으키거나 무엇을 할지 예측할 수 없는 500명의 사람들을 쉽게 흉내 내는 일이 실제로는 불가능하지만, 500개의 모의실험을 만들어 사람들이 어떻게 행동할지 본뜨게 해 보는 정도는 할 수 있을 것이다.

압박 검사를 할 때는 가벼운 부하에서 시작해서, 입력 비율이나 입력 크기와 같은 어떤 범위에 따라 벽에 부딪칠 때까지 부하를 늘려간다. 벽이 요구 조건을 만족하기에 너무 가깝다면, 어떤 자원이 병목이 되어 있는지 알아내라. (대개 주된 원인이 있기 마련이다.) 그것이 무엇 때문인가? 메모리? 프로세서? I/O? 네트워크 대역폭? 데이터 쟁탈? 그 후에는 그 벽을 어떻게 움직일 수 있을지 알아내라. 벽을 움직이는 것, 즉 시스템이 견딜 수 있는 최대 부하를 증가시키는 것이 부하가 적은 시스템의 성능에 도움이 되지 않거나 오히려 해가 될 수도 있다는 사실은 기억하라. 보통은 큰 부하가 걸렸을 때의 성능이 적은 부하가 걸렸을 때의 성능보다 중요하다.

머리 속으로 모형을 그릴 수 있도록 여러 가지 다른 차원들도 살필 수 있어야 한다. 한 가지 기법만으로는 충분하지 않다. 예를 들어, 로그 기록은 시스템에서 일어난 두 사건 사이의 벽시계 시간에 대해 잘 알 수 있게 해 주지만, 그것이 잘 구성되어 있지 않은 한, 메모리 사용이나 자료 구조의 크기에 대해서는 살펴볼 수 없다. 같은 원리로, 현대적인 시스템에서는 많은 컴퓨터와 많은 소프트웨어 시스템들이 서로 협력하여 동작하는데, 특히 벽에 부딪쳤을 때 (즉, 성능이 입력 크기에 비례하지 않게 될 때) 이 다른 소프트웨어 시스템들이 병목이 될 수 있다. 이 시스템들을 살펴볼 수 있는 것은, 모든 관련 장비들의 프로세서 부하만 측정할 수 있다 해도, 큰 도움이 될 수 있을 것이다.

벽이 어디에 있는지 아는 것은, 벽을 옮기는 것뿐만 아니라 사업을 효과적으로 관리할 수 있도록 예측 가능성을 마련해 주는 데에도 필수적이다.

3.1.5 간결성과 추상성의 균형을 잡는 방법

추상성은 프로그래밍의 열쇠이다. 얼마나 추상화해야 할지는 주의해서 선택해야 한다. 초보 프로그래머들은 열심이 지나쳐서 실제로 필요 이상으로 추상화하는 경우가 있다. 이것의 징조 중 하나는 아무 코드도 들어 있지 않으면서, 다른 것을 추상화하는 것 외에 아무 일도 하지 않는 클래스를 만드는 것이다. 이런 것의 매력은 이해할 만하지만 코드 간결성의 가치도 추상성의 가치에 비교하여 재 봐야 한다. 때때로 열정적인 이상주의자들이 저지르는 실수를 보게 된다. 즉 프로젝트 초기에 수많은 클래스들을 정의하면서 그것을 통해 추상성을 멋지게 달성하고, 발생할 수 있는 모든 사태를 다룰 수 있을 것으로 기대한다. 그런데 프로젝트가 진행되고 피로가 쌓임에 따라 코드 자체가 너저분해진다. 함수의 몸체는 되어야 할 것 이상으로 길어진다. 비어 있는 클래스들은 문서화하는 데 짐이 되고 압박이 오면 결국 잊혀진다. 추상화에 쏟은 에너지가 프로그램을 간결하고 단순하게 하는 데에 쓰였다면 최종 결과가 더 좋아졌을지도 모른다. 이것은 사색적인(speculative) 프로그래밍의 전형이다. 나는 폴 그레이엄(Paul Graham)의 "간결함이 힘이다(Succinctness is Power)"라는 글을 강력 추천한다. <PGSite>

정보 은닉이나 객체 지향 프로그래밍과 같은 유용한 기법들을 지나치게 사용하면서 독단적 견해가 생기기도 한다. 이 기법들은 코드를 추상화하게 하고 변화를 예측하게 한다. 하지만 개인적인 생각으로는 너무 사색적인 코드를 작성하지 않는 것이 좋다. 예를 들어, 어떤 객체의 정수 변수를 변경자(mutator)와 접근자(accessor) 뒤에 숨겨서 변수 자체는 드러나지 않고 작은 접점(interface)만 드러나게 하는 것은 받아들일 만한 스타일이다. 이를 통해서, 호출하는 코드에 영향을 주지 않으면서 그 변수의 구현 방식을 바꿀 수 있으며, 이것은 매우 안정된 API를 내놓아야 하는 라이브러리 제작자에게 적합할 것이다. 하지만 나는, 호출하는 코드를 우리 팀이 소유하고 있어서 호출되는 쪽만큼 호출하는 쪽도 다시 코딩할 수 있다면, 코드가 장황해지는 것을 감수할 만큼 이것이 이득이 된다고 생각하지는 않는다. 이런 사색적 프로그래밍으로 얻는 이득을 따져 보면 코드 너덧 줄 늘어나는 것도 아깝다.

이식성(portability)에 대해서도 비슷한 문제를 볼 수 있다. 모든 코드는 다른 컴퓨터, 컴파일러, 소프트웨어 시스템, 플랫폼에 바로 혹은 아주 쉽게 이식될 수 있어야 하는가? 나는 이식성은 없지만 간결하면서 쉽게 이식할 수 있는 코드가, 장황하면서 이식성 있는 것보다 낫다고 생각한다. 특정 DBMS에 맞는 데이터베이스 질의를 하는 클래스와 같이 이식성 없는 코드를 정해진 영역에 한정해 놓는 것도 비교적 쉬우면서 분명히 좋은 생각이다.

3.1.6 새로운 기능을 배우는 방법

새로운 기능, 특히 기술과 무관한 것을 배우는 것은 무엇보다 재미있는 일이다. 이것이 프로그래머들의 의욕을 얼마나 많이 불러일으키는지 이해하는 회사들은 사기가 더욱 높아질 수 있을 것이다.

인간은 행함으로 배운다. 책 읽기와 수업 듣기가 유용한 것은 틀림없지만, 아무 프로그램도 작성해 보지 않은 프로그래머를 인정할 수 있겠는가? 어떤 기능이든 배우기 위해서는 그 기능을 스스럼없이 연습해 볼 수 있어야 할 것이다. 새로운 프로그래밍 언어를 배울 때에는, 큰 프로젝트를 해야 하게 되기 전에 그 언어를 사용하는 작은 프로젝트를 해 보라. 소프트웨어 프로젝트 관리를 배울 때에는, 작은 프로젝트를 먼저 관리해 보도록 하라.

좋은 사수(mentor)가 있다고 해서 스스로 하는 것을 소홀히 해서는 안 되겠지만, 사실 책 한 권보다는 훨씬 낫다. 사수의 지식을 전수받는 대신 그들에게 무엇을 해 줄 수 있을까? 최소한 그들의 시간이 낭비가 되지 않도록 열심히 공부해 줄 수는 있을 것이다.

상사에게 공식 연수를 받게 해 달라고 요청해 보라. 하지만 이것이 그 시간 동안 배우고 싶은 새로운 기술을 가지고 놀아 보는 것보다 별로 나을 것이 없는 경우도 있다는 것을 알아 두라. 그렇다 해도, 우리의 불완전한 세상에서는 공식 연수에서 저녁 식사 파티를 기다리며 강의 내내 잠만 자는 경우가 많음에도 불구하고 노는 시간보다는 연수를 요청하기가 쉬울 것이다.

팀장이라면, 팀원들이 어떻게 배우는지 이해하고 그들에게 관심 있는 기능을 연습할 수 있는 적절한 규모의 프로젝트를 할당함으로써 그들을 도와주라. 프로그래머에게 가장 중요한 기능은 기술에 관한 것이 아니라는 사실을 잊지 말라. 팀원들에게 용기와 정직성과 의사소통 능력을 시험하고 실행할 수 있는 기회를 주라.

3.1.7 타자 연습

자판을 보지 않고 타자할 수 있도록 연습하라. 이것은 중급 기능이다. 왜냐하면, 코드 작성은 어려운 일이므로, 아무리 타자를 잘 한다 해도, 거기에는 타자 속도가 별 의미가 없고, 코드 작성에 걸리는 시간에 별 영향을 주지도 않기 때문이다. 하지만, 중급 프로그래머가 되면 동료나 다른 사람들에게 일반 언어로 글을 쓰는 데 많은 시간을 보내게 될 것이다. 이것은 자신의 헌신성에 대한 재미있는 시험이다. 그런 것을 배우는 일이 그렇게 즐겁지는 않지만 어쨌든 시간을 바쳐야 한다. 마이클 티먼(Michael Tiemann)이 MCC에 있을 때 사람들이 그의 방문 밖에 서서, 엄청나게 빠른 타자 속도 때문에 자판이 윙윙거리는 소리를 듣곤 했다는 전설이 있다. 주: 지금 현재 그는 레드햇(RedHat)의 최고 기술 책임자(CTO)이다.

3.1.8 통합 검사를 하는 방법

통합 검사(integration testing)는 단위별 검사를 마친 여러 구성요소들을 통합하는 검사이다. 통합은 비싼 대가를 치르고 얻게 되며, 그것은 이 검사를 통과함으로써 얻게 된다. 시간 추정과 일정 계획에 이 검사를 포함시켜야 한다.

이상적으로는 마지막 단계에서 별도로 통합을 실시하지 않아도 되도록 프로젝트를 조직해야 할 것이다. 프로젝트가 진행되는 과정에서 각 요소들이 완성되어 가면서 점진적으로 그것들을 통합하는 것이 훨씬 낫다. 별도의 통합 과정을 피할 수 없다면 주의해서 시간을 추정하라.

3.1.9 의사소통을 위한 용어들

프로그래밍 언어는 아니지만 의사소통을 위해 공식적으로 정의된 문법 체계에 따른 용어들이 있다. 이 용어들은 특별히 표준화를 통해 의사소통을 돕기 위해 만들어진 것이다. 2003년 현재, 이런 용어들 중 가장 중요한 것으로 UML, XML, SQL이 있다. 이것 모두에 대해서는, 제대로 의사소통하고 언제 그 용어를 사용할지 결정할 수 있기 위해, 어느 정도 친숙해질 필요가 있다.

UML은 설계에 대해 설명하는 도형을 그리기 위해 풍부하게 갖춰진 형식 체계이다. 시각적이고 형식적이라는 점에서 일종의 미학(beauty lines)이라고 할 수 있다. 저자와 독자가 모두 UML을 안다면 많은 양의 정보를 쉽게 전달할 수 있다. 설계 내용에 대해 의사소통할 때 UML을 사용하는 경우가 있으므로 그것을 알 필요가 있다. UML 도형을 전문적으로 그려 주는 유용한 도구들이 있다. 많은 경우에 UML는 너무 형식적이어서, 나는 설계 내용을 도형으로 나타내기 위해 단순한 상자와 화살표 형식을 사용하곤 한다. 하지만 나도 UML이 최소한 라틴어를 공부하는 것만큼 도움이 된다는 사실은 어느 정도 확신한다.

XML은 새로운 표준을 정의하기 위한 표준이다. 간혹 XML이 데이터의 상호교환 문제에 대한 해결책인 것처럼 소개되기도 하지만 사실 그런 것은 아니다. 그것보다는, 데이터의 상호교환에서 가장 따분한 부분, 즉 특정 방식으로 표현된 데이터를 선형의 구조로 나열하고, 그것을 다시 원래의 구조로 파싱하는 작업을 기특하게도 자동화하는 것이다. XML은, 비록 아직 필요한 것들의 일부만 구현되긴 했어도, 훌륭하게 자료형 검사와 정확성 검사를 한다.

SQL은, 완전한 프로그래밍 언어는 아니지만, 매우 강력하고 풍부한 데이터 질의와 처리 언어이다. 이것은 다양한 종류가 있으며, 특히 제품에 크게 의존하지만 표준화된 핵심 부분보다는 덜 중요하다. SQL은 관계형 데이터베이스의 공통 언어이다. 관계형 데이터베이스를 이해하는 것이 득이 되는 분야에서 일할 수도 있고 그렇지 않을 수도 있지만, SQL과 그 문법에 대해 기초적인 것은 알아둘 필요가 있다.

3.2 팀의 기능들

3.2.1 개발 시간을 관리하는 방법

개발 시간을 관리하기 위해서는, 프로젝트 계획서가 간결하고 신선(up-to-date)하도록 하라. 프로젝트 계획서에는 시간 추정, 작업 일정, 진척 상황을 표시하기 위한 진도표(milestones), 시간 추정된 각 과제에 대한 팀이나 자기 자신의 시간 할당 등이 들어 있다. 여기에는 품질보증팀 사람들과 회의, 문서 준비, 장비 주문과 같이 잊지 말고 해야 할 다른 일들도 포함된다. 팀으로 일하는 것이라면, 프로젝트 계획서는 프로젝트 시작부터 진행 과정 내내 팀 전체의 동의에 의한 것이어야 한다.

프로젝트 계획서는 의사결정을 돕기 위해 존재하는 것이지, 자신이 얼마나 조직적인 사람인지 보여 주기 위한 것이 아니다. 프로젝트 계획서가 너무 길고 오래되었다면 의사결정에 아무 소용이 없을 것이다. 실제로 이러한 의사결정은 개개인에 관한 것이다. 계획서와 판단력에 의해 과제를 이 사람에게서 저 사람에게로 넘길 것인지 결정해야 한다. 진도표는 진척 상황을 표시한다. 화려한 프로젝트 기획 도구를 사용한다면 그것으로 프로젝트에서 '개발 초기 대형 설계(Big Design Up Front)'를 하려는 유혹에 빠지지 말고, 간결함과 신선함을 위해 사용하도록 하라.

진도를 못 맞췄다면, 그 진도만큼 프로젝트 일정 완료가 늦어진다고 상사에게 알리는 등의 즉각적인 행동을 취해야 한다. 시간 추정과 작업 일정은 처음부터 완벽할 수는 없을 것이다. 이것은 진도를 못 맞춘 날들을 프로젝트 후반에 만회할 수 있을지도 모른다는 환상을 낳는다. 물론 그럴 수 있을지도 모른다. 하지만 이것은 그 부분을, 과대 추정할 수도 있었겠지만, 과소 추정했기 때문이다. 그러므로 좋듯 싫든 간에 프로젝트의 일정 완료는 이미 늦어진 것이다.

계획서에 다음의 시간들도 포함되도록 명심하라. 팀 내부 회의, 시연, 문서화, 일정에 따라 반복되는 활동들, 통합 검사, 외부인들 상대하기, 질병, 휴가, 기존 제품들의 유지, 개발 환경의 유지 등. 프로젝트 계획서는 외부인이나 상사에게 자신이나 자신의 팀이 무엇을 하고 있는지 보여 줄 수 있는 '중간' 다리가 될 수 있다. 이런 이유 때문에 계획서는 짧고 신선해야 한다.

3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법

프로젝트 내에서 통제할 수 없는 다른 조직이 만든 소프트웨어에 의존해야 하는 경우가 있다. 타사 소프트웨어와 연관된 큰 위험 부담들은 관련된 모든 사람이 인식하고 있어야 한다.

절대, 절대로 거품(vapor)에 희망을 두지 말라. 거품이란, 나올 것이라고 광고는 하면서 아직 나오지 않은 소프트웨어를 말한다. 이것은 업계를 떠나게 될 가장 확실한 방법이다. 어떤 특징이 있는 어떤 제품이 어느 날에 출시될 것이라는 소프트웨어 회사의 약속을 의심스러워하기만 하는 것은 현명하지 않다. 그것을 완전히 무시하고 그 소식을 들었다는 것조차 잊어버리는 것이 더욱 현명하다. 회사에서 쓰이는 어떤 문서에도 그 소프트웨어에 대해 쓰지 않도록 하라.

타사 소프트웨어가 거품이 아니라면, 위험 부담은 여전히 있지만 그래도 최소한 손을 써 볼 수는 있을 것이다. 타사 소프트웨어의 사용을 고려하고 있다면, 일찍 에너지를 들여서 그것을 평가해야 한다. 사람들은 세 가지 제품이 적합한지 평가하는 데에 2주에서 2개월이 걸린다는 말을 듣고 싶어 하지 않겠지만, 최대한 일찍 그 일을 마쳐야 한다. 적절한 평가 없이는 통합(integration)에 드는 비용을 정확하게 추정할 수 없다.

특정한 목적에 기존의 타사 소프트웨어가 적합한지는 극소수의 사람들만 알고 있다. 그것은 매우 주관적이며 일반적으로 전문가들의 영역이다. 이런 전문가들을 찾을 수 있다면 많은 시간을 아낄 수 있다. 프로젝트가 타사 소프트웨어 시스템에 너무 완전히 의존해서 통합에 실패하면 프로젝트 자체가 실패하는 경우도 있을 수 있다. 그러한 위험 부담들을 작업 일정에 분명히 밝혀 두라. 쓸 수 있는 다른 시스템을 확보하는 등 만약의 사태에 대비한 계획도 세워 두고, 위험 부담을 일찍 제거할 수 없을 때 스스로 그 기능을 구현할 수 있는 능력도 키워 두라. 절대로 일정이 거품에 의존하지 않도록 하라.

3.2.3 컨설턴트를 관리하는 방법

컨설턴트를 활용하되 그들에게 의지하지는 말라. 그들은 훌륭하고 많이 존중받을 만하다. 그들은 수많은 다양한 프로젝트들을 보아 왔기 때문에 특정한 기술들이나 프로그래밍 기법들에 대해 많이 알고 있는 경우가 있다. 그들을 활용하는 최선의 방법은, 사례를 중심으로 강의하는 사내 강사로서 활용하는 것이다.

하지만, 그들의 강점과 약점을 알 만한 충분한 시간이 없다고 해서 그들을 일반 직원들처럼 팀의 일원이 되게 할 수는 없다. 그들이 금전적 손실을 감수하는(financial commitment) 경우는 거의 없다. 그들은 아주 쉽게 떠난다. 회사가 잘 운영된다면 그들이 얻을 것은 별로 없을 것이다. 어떤 사람은 좋고, 어떤 사람은 그저 그렇고, 어떤 사람은 안 좋을 것이다. 컨설턴트를 선정할 때도 직원을 채용할 때처럼 주의를 기울이지 않는다면 좋은 사람을 만나기는 힘들 것이다.

컨설턴트가 코드를 작성해야 한다면, 계속해서 그 코드를 주의를 기울여 검토해야 한다. 검토해 보지 않은 코드가 뭉텅이로 있는 위험 부담을 안고서 프로젝트를 잘 마칠 수는 없을 것이다. 이것은 사실 모든 팀원들에게도 적용되는 사실이지만, 가까이에 있는 팀원들이야 잘 아는 사람들 아닌가.

3.2.4 딱 적당하게 회의하는 방법

회의에 드는 비용을 잘 고려하라. 그 비용은 회의 시간에 참석 인원수를 곱한 값이다. 회의가 필요할 때도 있지만 규모가 작을수록 좋다. 의사소통의 질은 소규모 회의 때 더 좋고, 낭비되는 총 시간도 적다. 누가 회의 때 지루해하는 것 같으면, 이것은 회의 참석 인원을 줄여야 한다는 신호이다.

비공식적인 의사소통을 장려하기 위해서는 할 수 있는 일은 모두 해야 한다. 다른 시간들보다 동료들과 함께 하는 점심시간 동안 쓸만한 일들이 더 많이 이뤄진다. 그런데 이것을 인식하지도 않고 이 사실을 지지하지도 않는 회사가 더 많다는 것은 부끄러운 일이다.

3.2.5 무리 없이 정직하게 반대 의견을 내는 방법

반대 의견은 의사 결정을 잘 하기 위해 꼭 필요한 것이지만, 조심스럽게 다뤄야 한다. 자기 생각을 적절히 표현했고 결정이 내려지기 전에 사람들이 그 생각에 귀를 기울였다고 스스로 느낀다면 좋겠다. 그 경우 더 이상 할 말은 없는 것이고, 이제는 결정된 일에 대해 반대했더라도 그것을 후원할 것인지 결정하면 된다. 반대했더라도 이제 그 결정을 따를 수 있다면 그렇게 하겠다고 말하라. 이것은 내가 생각이 있으며 무조건 찬성하는 사람이 아니지만, 결정된 것은 존중하며 팀의 일원으로 일한다는 자신의 가치를 보여 준다.

어떤 때는 결정 사안에 대해 반대했음에도, 의사결정권자들이 그 의견을 충분히 고려하지도 않고 결정을 내리기도 할 것이다. 이 때에는 문제 제기를 할 것인지 회사나 부족(tribe)의 차원에서 잘 따져 봐야 한다. 그 결정에 사소한 실수가 있는 것 같다면, 재고할 가치는 없을 것이다. 만약 그 실수가 크다면, 당연히 논쟁을 벌여야 한다.

보통은, 이것은 별 문제가 되지 않지만, 스트레스가 많은 상황이나 특별한 성격의 사람들에게는 이것이 개인적인 문제를 일으키기도 한다. 예를 들어, 일 잘 하는 어떤 프로그래머는 결정이 잘못되었다고 믿을 만한 충분한 이유가 있어도 그것에 도전할 자신감이 없다. 더 나쁜 상황이라면, 의사결정권자도 자신감이 없어서 그것을 자기 권위에 대한 개인적인 도전으로 받아들이기도 한다. 이런 경우에 사람들은 비열하게 머리를 써서 반응한다는 것을 꼭 기억할 필요가 있다. 논쟁은 남들이 없을 때 벌여야 하고, 새로운 사실을 알게 됨으로써 전에 내린 결정의 근거가 어떻게 달라지는지 잘 보여주도록 노력해야 한다.

그 결정이 번복되든 그렇지 않든, 그 대안은 충분히 검토되지 않았을 것이므로 나중에라도 '내 그럴 줄 알았어!' 하고 우쭐대지 않도록 하라.

3.3 판단 능력

3.3.1 개발 시간에 맞춰 품질을 조절하는 방법

소프트웨어 개발은 항상 프로젝트의 목적과 프로젝트의 마무리 사이에서 타협하는 일이다. 프로젝트 결과의 배치를 신속하게 하기 위해 공학적 혹은 사업적 감수성을 거스르면서까지 품질을 조절하라는 요구를 받을 수 있다. 예를 들어, 소프트웨어 공학적으로 형편없고 수많은 유지 보수 문제를 일으킬 것이 뻔한 일을 하도록 요구받을 수 있다.

이런 일이 일어난다면 우선 책임 있게 할 일은, 그 사실을 팀에 알리고 품질 저하에 따른 비용을 분명히 설명하는 것이다. 어쨌든, 상사보다는 그 사실에 대해 더 잘 이해하고 있어야 한다. 무엇을 잃을 것이고 무엇을 얻을 것인지, 또 이번에 잃은 것을 다음 단계에 만회하기 위해서는 어떤 비용을 감수해야 하는지 분명히 하라. 이 때, 잘 짜여진 프로젝트 계획서의 선명함이 도움이 될 것이다. 품질을 조절하는 것이 품질 보증의 노력에 영향을 준다면 (상사와 품질보증팀 사람들 모두에게) 그 사실도 지적하라. 품질 조절 때문에 품질 확인 과정을 거치면서 많은 버그가 발견될 것 같다면 그것도 지적하라.

그래도 요구가 계속된다면, 조잡해지는 것이 특정 부분에만 머물게 하여 다음 단계에 재작성이나 개선 계획을 세울 수 있도록 해야 한다. 이 사실을 팀에 알려서 그 계획을 세울 수 있게 하라.

슬래쉬닷(Slashdot)의 닌자프로그래머(NinjaProgrammer)는 이런 보석 같은 글을 보내 왔다.

설계가 좋으면 코드 구현이 나빠도 회복 가능성이 있다는 사실을 기억하라. 코드 전체에 인터페이스와 추상화가 잘 되어 있으면, 언젠가 있을 수 있는 코드 재작성의 고통도 훨씬 덜할 것이다. 코드를 명쾌하게 작성하기도 힘들고 고치기도 힘들다면, 이런 문제를 야기하는 핵심 설계에 무슨 문제가 없는지 생각해 보라.

3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법

최신의 소프트웨어 시스템은 직접 통제할 수 없는 수많은 구성요소(component)들에 의존하는 경향이 있다. 이것은 상승효과(synergy)와 재사용을 통해 생산성을 높인다. 하지만, 각 요소들은 다음의 문제들을 수반한다.
  • 그 구성요소에 있는 버그는 어떻게 고칠 것인가?
  • 그 구성요소 때문에 특정 하드웨어나 소프트웨어 시스템만 사용해야 하는가?
  • 그 구성요소가 기능을 완전히 상실한다면 어떻게 할 것인가?

그 구성요소를 어떻게든 캡슐화 하여 주변과 격리시키고 언제든 다른 것으로 교체할 수 있게 하는 것이 항상 최선이다. 그 요소가 전혀 동작하지 않는 것으로 판명된다면 다른 것으로 대체할 수도 있지만, 직접 작성해야 할 수도 있다. 캡슐화가 이식성(portability)과 같은 말은 아니지만, 쉽게 이식될 수 있게 하기 때문에 거의 그와 같다고 할 수 있다.

구성요소들의 소스 코드를 갖고 있다면 위험 부담이 네 배 정도는 줄어든다. 소스 코드가 있다면 그것을 평가하기도 쉽고, 디버그 하기도 쉽고, 임시방편을 찾기도 쉽고, 수정판을 만들기도 쉽다. 수정판을 만든다면, 그것을 그 구성요소의 소유자에게도 보내 줘서 공식 배포판에 반영하게 해야 한다. 그렇지 않으면 비공식판을 유지하는 불편을 감수해야 할 것이다.

3.3.3 소프트웨어의 완성도를 판단하는 방법

다른 사람들이 작성한 소프트웨어를 사용하는 것은 견고한 시스템을 신속하게 완성하는 가장 효과적인 방법 중 하나이다. 그런 일을 망설일 필요는 없지만, 그에 연관된 위험 요소들을 검사해야 한다. 가장 큰 위험 부담 중 하나는 사용할 제품에 포함되어 사용되는 동안, 완성도를 갖추기 전의 소프트웨어에서 흔히 볼 수 있는 것처럼, 버그가 나타나거나 거의 작동 불능인 상태가 되는 것이다. 어떤 소프트웨어 시스템을 통합할 것인지 고려하기 전에, 그것이 사내에서 만들었든 타사에서 만들었든, 그것이 정말로 사용할 수 있을 만큼 충분한 완성도를 갖췄는지 고려하는 것은 매우 중요하다. 스스로 물어봐야 하는 열 가지 질문이 있다.
  1. 거품(vapor)은 아닌가? (약속만 있는 것은 완성도가 아주 떨어지는 것이다.)
  2. 그 소프트웨어에 대한 평판(lore)이 어떤지 알 수 있는가?
  3. 내가 첫 사용자인가?
  4. 개정판이 계속 나올 만한 충분한 동기(incentive)가 있는가?
  5. 유지 보수 노력이 계속되고 있는가?
  6. 현재 유지 보수 담당자가 없어도 사장되지 않을 것인가?
  7. 절반밖에 안 좋더라도 익숙한 다른 대안(seasoned alternatives)이 있는가?
  8. 부족(tribe)이나 회사에서 그것에 대해 알고 있는가?
  9. 부족이나 회사에서 추천할 만한가?
  10. 문제가 있어도 그것을 해결할 만한 사람을 채용할 수 있는가?

이 항목들을 조금만 생각해 봐도 잘 만들어진 자유 소프트웨어나 공개 소프트웨어가 기업의 위험 부담을 줄이는 데에 얼마나 큰 가치가 있는지 알 수 있을 것이다.

3.3.4 구입과 개발 사이에서 결정하는 방법

사업을 목적으로 한 회사나 프로젝트에서는 소프트웨어로 무엇인가를 달성하기 위해 노력하면서 빈번히 구입과 개발 사이에서 결정을 해야 한다. 이 단계에 왔다는 것은 두 가지 측면에서 불행한 일이다. 즉, 구입하지 않아도 되는 공개 소프트웨어, 자유 소프트웨어를 제쳐놓았기 때문일 것이고, 더 중요한 것은, 통합에 드는 비용도 고려해야 하기 때문에, 구입해서 통합하는 것과 직접 개발해서 통합하는 것 사이에서 결정하는 것을 의미하게 될 것이기 때문이다. 이것은 영업과 경영과 공학적 이해를 전체적으로 결합할 필요가 있다.
  • 자신의 필요와 그 소프트웨어가 설계된 목적이 얼마나 잘 맞는가?
  • 구입한 것 중 얼마만큼이 필요할 것인가?
  • 통합의 가치를 검토하는 데 드는 비용은 얼마나 되는가?
  • 통합하는 데 드는 비용은 얼마나 되는가?
  • 구입하게 되면 장기적 유지 보수 비용은 증가할 것인가, 감소할 것인가?
  • 그것을 구입함으로써 사업상 원치 않는 처지에 있게 되지는 않을 것인가?

다른 사업 전체의 기반이 될 만큼 큰 과제를 직접 개발하는 일은 다시 한 번 생각해 봐야 한다. 그런 생각은 대개 팀에 공헌을 많이 하게 될 똑똑하고 낙관적인 사람들이 제안하기 마련이다. 그들의 생각을 꼭 채택하고 싶다면, 사업 계획을 수정할 각오도 해야 할 것이다. 그러나 뚜렷한 생각 없이 원래 프로젝트보다 더 큰 솔루션(solution) 개발에 투자하는 일은 하지 말라.

이 질문들을 고려한 후에 개발에 대한 것과 구입에 대한 것, 이렇게 두 가지 프로젝트 시안을 준비해야 할 것이다. 통합 비용도 반드시 고려해야 할 것이다. 두 솔루션 모두에 대해 장기적 유지 보수 비용도 고려해야 한다. 통합 비용을 추정하기 위해서는 그 소프트웨어를 구입하기 전에 철저하게 평가해야 할 것이다. 그것을 평가할 수 없다면, 그것을 구입함으로써 생기는 예상 밖의 위험 부담까지 가정하여 그 제품을 구입하는 것에 대해 결정해야 한다. 고려할 구입 결정 대상이 여럿이라면, 각각을 평가하기 위해 상당한 노력을 들여야 할 것이다.

3.3.5 전문가로 성장하는 방법

자신의 권위보다 책임을 더 중하게 생각하라. 바라는 역할에 최선을 다하라. 자신을 개인적으로 도와준 사람들은 물론 조직 전체의 성공에 기여한 사람들에게 감사하라.

팀장이 되고 싶다면, 팀의 합의를 이루기 위해 애쓰라. 관리책임자가 되고 싶다면, 작업 일정에 책임을 지라. 팀장이나 관리책임자 대신 이 일을 맡는다면, 그들이 자유롭게 더 큰 일에 전념할 수 있을 것이므로, 그 일을 편하게 해 낼 수 있을 것이다. 그 일이 시험 삼아 해 보기에 너무 크다면, 한 번에 조금씩 하도록 하라.

자기 자신을 평가하라. 더 나은 프로그래머가 되고 싶다면, 존경하는 사람에게 어떻게 하면 그들과 같이 될 수 있는지 물어보라. 상사에게 물어볼 수도 있다. 그가 아는 것은 적어도 나의 경력에는 큰 영향을 미칠 것이다.

자기 일에 활용할 수 있는 새로운 기능을 배울 방법을 계획하라. 이것은, 새로운 소프트웨어 시스템에 대해 배우는 것과 같이 사소한 기술적 기능일 수도 있고, 글을 잘 쓰는 것과 같이 어려운 사회적 기능일 수도 있다.

3.3.6 면접 대상자를 평가하는 방법

사원이 될 사람들을 평가하는 일은, 그 가치에 비해 큰 노력을 들이지 않고 있다. 잘못된 채용은, 잘못된 결혼과 마찬가지로, 끔찍한 일이다. 모든 사람들은 자기 에너지의 상당 부분을 인재 발굴에 바쳐야 하지만, 실제로 그런 경우는 드물다.

다양한 면접 유형이 있다. 어떤 것은 고문과 같아서, 지원자가 심한 스트레스를 받게 되어 있다. 이것은 스트레스를 받는 상황에서 인격적인 결점과 약점이 드러날 수 있게 하는 매우 중요한 목적이 있다. 지원자들은 자기 자신에 대해 정직한 만큼 면접관에게 정직할 것이다. 그런데 인간의 자기기만(self-deception) 능력은 대단하다.

최소한 두 시간 동안은 지원자에게 기술적 기능에 대해 묻는 구두시험을 실시해야 한다. 여러 번 하다 보면, 그들이 아는 것이 무엇인지 즉시 파악하고, 경계를 명확히 하기 위해 그들이 모르는 것에 대해 즉시 반응할 수 있게 될 것이다. 면접 대상자들은 이것을 순순히 받아들일 것이다. 나는 면접 대상자들에게서 회사를 선택하는 동기 중 하나가 면접의 질적 수준이라는 말을 몇 번 들은 적이 있다. 좋은 사람들은, 전에 일하던 곳이 어디인지, 어느 학교를 나왔는지, 그 밖의 다른 사소한 특성들보다는 자기 실력 때문에 채용되기를 원한다.

면접을 하면서 그들의 학습 능력에 대해서도 평가해야 한다. 이것은 그들이 현재 알고 있는 것이 무엇인가보다 더욱 더 중요하다. 까다로운 사람이라는 낌새도 알아차려야 한다. 면접 후에 기록해 둔 것들을 비교하면서 이런 것을 알아차릴 수 있을 것이다. 하지만 한참 면접이 진행되는 동안에 그것을 알아차리기는 어렵다. 다른 사람과 의사소통하고 같이 일하는 것을 얼마나 잘 하는가는 최신 프로그래밍 언어에 능통한 것보다 중요하다.

한 독자는 면접 대상자들에게 집에서 풀어오는 시험을 실시하여 결과가 좋았다고 한다. 이 방법은 면접 때 말은 잘 하지만 정작 코딩은 못 하는 사람들을 추려낼 수 있다는 장점이 있다. (사실 그런 사람들이 많다.) 개인적으로 이 기법을 써 보지는 않았지만, 괜찮아 보인다.

끝으로, 면접은 판매의 과정이기도 하다. 지원자들에게 회사나 프로젝트를 잘 팔아야 한다. 하지만, 프로그래머에게 이야기하는 것이므로, 진실을 윤색하려고 하지는 말라. 나쁜 점에서 시작하여 좋은 점에 대해 강한 인상을 주면서 마무리 하라.

3.3.7 화려한 전산 과학을 적용할 때를 아는 방법

많은 프로그래머들이 알기는 하지만 거의 사용하지 않는 알고리듬, 자료 구조, 수학, 그 밖의 거창한 내용에 대한 지식들이 있다. 실제로 이런 훌륭한 지식들은 너무 복잡하여 일반적으로는 필요가 없다. 예를 들어, 대부분의 시간을 비효율적인 데이터베이스 질의를 만들고 있으면서 알고리듬을 개선한다는 것은 아무 의미가 없다. 프로그래밍을 하면서 시스템들이 서로 통신하게 한다거나 멋있는 사용자 환경(user interface)을 만들기 위해 매우 단순한 자료 구조를 사용해야 한다면 불행이 시작되는 것이다.

고급 기술을 사용하는 것이 적절한 때는 언제인가? 흔하지 않은 다른 알고리듬을 찾기 위해 책을 펼쳐야 하는 때는 언제인가? 그런 것을 사용하는 것이 유용할 경우가 있지만, 그 전에 주의해서 평가해야 한다.

사용하게 될지 모르는 전산 과학 기법에 대해 고려해야 하는 매우 중요한 세 가지 측면이 있다.
  • 캡슐화가 잘 되어 있어서, 다른 시스템에 미칠 위험 부담이 적고, 복잡도나 유지 보수 비용의 증가가 적은가?
  • 그 이득이 대단한가? (예를 들어, 기존의 것과 유사한 시스템이라면 두 배, 새로운 시스템이라면 열 배 정도의 이득)
  • 그것을 효과적으로 검사하고 평가할 수 있을 것인가?

다소 화려해도 주변과 격리가 잘 되어 있는 알고리듬은 전체 시스템에 대해 두 배 정도로 하드웨어 비용을 줄이거나 그 만큼 성능을 향상시킬 수 있을 것이므로 그것을 고려하지 않는 것은 어리석은 일이 될 것이다. 이런 해결 방법을 주장하기 위한 한 가지 열쇠는, 그 기술에 대한 연구는 이미 잘 되어 있을 것이고 남은 문제는 통합의 위험 부담일 것이므로, 그 위험 부담이 실제로 매우 적다는 것을 보여 주는 것이다. 이렇게 될 때 프로그래머의 경험과 판단 능력이 그 화려한 기술과 어울려 진정한 상승효과를 낼 수 있을 것이며 통합도 쉽게 이뤄질 것이다.

3.3.8 비기술자들과 이야기하는 방법

대중문화에서 기술자, 특히 프로그래머는 일반적으로 보통 사람들과는 다른 사람이라고 인식된다. 이것은 보통 사람들이 우리와 다르다는 뜻이다. 비기술자들과 대화할 때 이 사실을 염두에 두고 있는 것이 중요하다. 항상 듣는 사람을 이해해야 한다.

비기술자들은 똑똑하더라도 우리처럼 기술적인 것들을 만드는 일에 기초가 있지는 않다. 우리는 무엇인가를 만든다. 그들은 무엇인가를 팔거나 다루거나 세거나 관리하지만, 만드는 일에는 전문가가 아니다. 그들은 기술자들처럼 (물론 예외는 있지만) 팀으로 같이 일하는 것에도 익숙하지 않다. 주: 많은 독자들이 이 절의 내용이 오만하거나 자기 경험과는 거리가 멀다고 느낄 수 있다. 나는 비기술자도 매우 존중한다. 겸손한 척하려고 하는 말이 아니다. 나의 이런 신념들로 기분이 상했다면 용서를 구한다. 하지만 솔직하게 말해서 반대 사례를 경험하게 될 때까지는 그 신념을 거둘 수 없을 것 같다. 내가 이례적으로 운이 좋아서 그 동안 좋은 프로그래머들과 같이 일해 왔을 수도 있고, 다른 사람들이 프로그래머는 대화하기 부담스럽다는 고정관념(stereotype)을 일반적인 표준으로 생각하는 것일 수도 있다. 그들의 사회적 기능은 일반적으로, 팀이 아닌 환경에서 일하는 기술자들과 같거나 더 낫지만, 그들이 하는 일은 우리처럼 깊고 정확하게 의사소통을 해야 하거나 세부 과제를 조심스럽게 나눠야 하는 등의 일이 항상 요구되지는 않는다.

비기술자들은 간절히 다른 사람을 만족시키고 싶어 할 수도 있고, 기술자들에게 위협을 느낄 수도 있다. 우리와 똑같이, 그들도 기술자들을 만족시키기 위해서, 혹은 기술자들에게 다소 겁을 먹어서, 별 뜻 없이 '예'라고 말해 놓고는 나중에는 그 말에 책임지지 않을 수 있다.

비프로그래머들이 기술적인 것들을 이해할 수는 있지만 우리에게도 어려운 그것, 즉 기술적 판단 능력은 없다. 그들은 기술이 어떻게 적용되는지는 이해하지만, 왜 어떤 접근 방식은 석 달이나 걸리고, 다른 방식은 사흘이면 되는지 이해하지 못한다. (어쨌든, 프로그래머들이 이런 종류의 추정에 너무 냉정하다는 것도 맞는 말이다.) 이것은 그들과 함께 상승효과를 낼 수 있는 기회가 있다는 뜻도 된다.

팀에서 이야기할 때에는, 별 생각 없이, 일종의 줄임말을 사용할 것이다. 일반 기술이나 특히 함께 작업하는 제품에 대해 많은 경험을 공유하고 있기 때문에 그것이 효과적이다. 그런 경험의 공유가 없는 사람들에게 이야기할 때, 특별히 자기 팀원들도 같이 있다면, 줄임말을 사용하지 않는 데에 노력을 좀 들여야 한다. 이런 어휘는 우리와 그것을 공유하지 않는 사람들 사이에 벽을 만들고, 더 나쁘게는, 그들의 시간을 낭비하게 한다.

팀원들과 있을 때는 기본 가정이나 목표를 수시로 다시 말할 필요는 없으며, 대부분의 대화가 세부적인 것들에 초점이 맞춰진다. 외부인들과 함께 있을 때는 다른 방식으로 해야 한다. 그들은 우리가 당연하게 여기는 것을 이해하지 못할 수 있다. 어떤 것을 당연하게 여기고 다시 설명하지 않기 때문에, 실제로는 커다란 오해가 있는데도 서로를 잘 이해했다고 생각하면서 외부인들과 대화를 마칠 수도 있다. 자기 생각을 잘못 전달할 수 있다는 것을 항상 가정하고 실제로 그런 일이 없는지 잘 살펴봐야 한다. 그들이 잘 이해했는지 알아보기 위해, 요약을 하게 하거나 다른 말로 표현하게 해 보라. 그들을 자주 만날 기회가 있다면, 내가 효과적으로 대화하고 있는지, 어떻게 하면 더 잘 할 수 있을지 잠깐 물어보는 것도 좋다. 의사소통에 문제가 있다면, 그들에게 실망하기 전에 자신의 습관을 고칠 방법을 찾으라.

나는 비기술자들과 같이 일하는 것을 좋아한다. 가르치고 배울 기회가 많기 때문이다. 명확한 용어로 대화하면서, 예를 들어 가며 안내할 수도 있을 것이다. 기술자들은 무질서에서 질서를, 혼동됨에서 명확함을 찾아내도록 훈련받으며, 비기술자들은 우리의 이런 점을 좋아한다. 우리는 기술적 판단 능력이 있고 사업상의 문제들도 대개 이해할 수 있기 때문에, 종종 문제에 대한 간단명료한 해결책을 찾아내기도 한다.

비기술자들은 좋은 뜻으로, 그리고 잘 해 보려는 마음으로 우리가 일을 더 쉽게 해 낼 수 있을 것이라고 생각하는 해결책들을 제안하기도 한다. 사실은 훨씬 더 좋은 종합적 해결책이 존재하는데, 그것은 외부인들의 관점과 우리의 기술적 판단력이 함께 상승효과를 낼 때에만 보인다. 나는 개인적으로 익스트림 프로그래밍(Extreme Programming)을 좋아한다. 그것이 이런 비효율성을 중점적으로 다루고 있으며, 아이디어와 그에 대한 비용 추정을 신속하게 짝지음으로써, 비용과 이득이 최상으로 결합되는 아이디어를 쉽게 찾을 수 있게 해 주기 때문이다.

4 상급자

4.1 기술적 판단 능력

4.1.1 어려운 것과 불가능한 것을 구분하는 방법

어려운 일은 해 내고, 불가능한 일은 골라내는 것이 우리가 할 일이다. 대부분의 현직 프로그래머들의 관점에서 보면, 단순한 시스템에서 나올 수 없거나 비용을 추정할 수 없는 일은 불가능한 것이다. 이 정의에 따르면 연구라고 불리는 것은 모두 불가능한 일이다. 일거리들의 많은 부분이 어렵기는 하지만, 반드시 불가능한 것은 아니다.

이 구분은 전혀 우스운 것이 아니다. 과학적 관점에서든 소프트웨어 공학적 관점에서든, 실제로 불가능한 일을 하라는 요구를 받는 경우가 많을 것이기 때문이다. 어렵기는 해도 사업주가 원하는 것을 최대한 끌어낼 수 있는 합리적인 해결책을 찾도록 돕는 것이 우리가 할 일이다. 자신 있게 일정을 잡을 수 있고 위험 부담을 잘 이해하고 있다면, 그 해결책은 어려운 것일 뿐이다.

예를 들어, '각 사람에게 가장 매력적인 머리 모양과 색깔을 계산할 수 있는 시스템을 개발하라'와 같은 막연한 요구 사항을 만족시키는 것은 불가능한 일이다. 요구 사항이 좀 더 뚜렷해질 수 있다면, 그 일이 어려울 뿐인 일로 바뀌기도 한다. 예를 들어 다음과 같은 식이다. '어떤 사람에게 매력적인 머리 모양과 색깔을 계산할 수 있는 시스템을 개발하되, 그들이 그것을 미리 보고 수정할 수 있게 하여, 처음 제안한 스타일에 대한 고객 만족을 극대화함으로써 많은 수입을 얻을 수 있게 하라.' 성공에 대한 뚜렷한 정의가 없다면 성공할 수 없을 것이다.

4.1.2 내장 언어를 활용하는 방법

시스템에 프로그래밍 언어를 내장하는(embedding) 것은 프로그래머에게는 에로틱하다고 할 만한 황홀함을 느끼게 한다. 이것은 해 볼 수 있는 가장 창의적인 활동들 중 하나이다. 이것은 시스템을 굉장히 강력하게 만들어 준다. 이것을 통해 자신의 창의적이고 프로메테우스적인 능력을 최대한 발휘할 수 있다. 이것은 시스템을 친구로 만들어 준다.

세계적으로 가장 우수한 텍스트 편집기들은 모두 내장 언어를 갖추고 있다. 사용자가 그 언어에 완전히 통달하는 경지에까지 이를 수도 있다. 물론, 그것이 텍스트 편집기 안에 들어 있으므로, 써 보고 싶은 사람들은 쓸 수 있고 그렇지 않은 사람들은 그럴 필요 없도록, 그 언어의 사용을 선택 사항으로 둘 수도 있다.

나를 비롯하여 다른 많은 프로그래머들이 특수한 목적의 내장 언어를 만들고 싶다는 유혹에 빠지곤 한다. 나는 두 번 그런 적이 있다. 내장 언어로 특별히 설계된 언어들이 이미 많이 나와 있다. 새로운 것을 또 만들기 전에 한 번 더 생각해 볼 필요가 있다.

언어를 내장하기 전에 스스로 물어봐야 하는 진짜 질문은 이것이다. 이것이 사용자의 문화와 잘 맞을 것인가, 그렇지 않을 것인가? 사용자가 모두 비프로그래머라면 그것이 무슨 도움이 될 것인가? 사용자가 모두 프로그래머라면 오히려 API를 선호하지 않을 것인가? 무슨 언어로 할 것인가? 프로그래머들은 사용 범위가 좁은 새 언어는 배우고 싶어 하지 않는다. 하지만 그것이 그들의 문화와 잘 맞물린다면 많은 시간을 들이지 않고서도 배울 수 있을 것이다. 새로운 언어를 만든다는 것은 즐거운 일이다. 하지만 그렇다고 해서 사용자들의 필요에 대해 눈이 가려져서는 안 된다. 정말로 근본적인 필요와 아이디어가 있는 것이 아니라면, 사용자들이 이미 친숙한 기존의 언어를 사용해서 부담을 줄여 주는 것이 어떤가?

4.1.3 언어의 선택

자신의 일을 사랑하는 고독한 프로그래머(즉, 해커)는 과제에 가장 잘 맞는 언어를 선택할 수 있다. 대부분의 현직 프로그래머들은 자기가 사용할 언어를 마음대로 고를 수 있는 경우가 드물다. 일반적으로, 이 문제는 잘난 체하는(pointy-haired) 상사들이 마음대로 결정한다. 이들은 기술적으로 결정하기보다는 정략적으로 결정하고, 아직 일반화되지 않은 어떤 도구가 가장 좋다는 것을 (대개 실무 경험에 의해) 알면서도 재래식이 아닌 도구를 사용하자고 나설 만한 용기는 없다. 어떤 경우에는 팀 전체, 더 넓게는 공동체 전체의 통일이 매우 실제적인 이득이 있기 때문에 개인적인 입장에서 선택하는 것을 배제하기도 한다. 관리책임자들은 정해진 언어에 대한 경험이 있는 프로그래머들을 채용해야 하는 필요에 따라 움직이기도 한다. 그들이 프로젝트나 회사에 가장 큰 이익이 된다고 생각하는 것을 위해 일한다는 것은 분명하며, 그것에 대해 존중받을 만하다. 하지만 나는 개인적으로 이것이 흔히 마주치게 되는 가장 낭비적이고 잘못된 일이라고 생각한다.

물론, 모든 일이 1차원적인 경우는 없다. 한 가지 중심 언어가 필수로 정해지고 그것을 내가 어떻게 할 수 없다 해도, 도구나 다른 프로그램을 다른 언어로 작성할 수 있거나 그렇게 해야 하는 경우가 종종 있다. 언어를 내장해야 한다면 (이것은 항상 생각해야 한다!) 언어를 선택할 때 사용자들의 문화를 많이 고려해야 할 것이다. 회사나 프로젝트에 기여하기 위해 그 일에 가장 적합한 언어를 사용하는 것의 장점을 잘 활용해야 하며, 이것을 통해 일이 더욱 흥미로워질 것이다.

프로그래밍 언어는, 그것을 배우는 것이 자연 언어를 배우는 것만큼 어려운 일이 전혀 아니라는 점에서, 표기법들(notations)이라고 부르는 것이 실제에 가깝다. 초보자들이나 외부인들에게는 "새로운 언어 배우기"가 멈칫하게 될 과제로 보인다. 하지만 세 가지 정도 언어를 체험해 보면, 그 일은 주어진 라이브러리들에 익숙해지는 문제일 뿐이다. 구성요소들이 서너 가지 언어로 되어 있는 큰 시스템이 있을 때 그것을 지저분하게 뒤범벅이 되어 있다고 생각할 수 있지만, 나는 그런 시스템이 한 가지 언어만으로 되어 있는 시스템보다 여러 면에서 더 튼튼한 경우가 많다고 하겠다.
  • 서로 다른 표기법으로 작성된 구성요소들은 필연적으로 결합도(coupling)가 낮아진다. (깔끔한 인터페이스는 없겠지만)
  • 각 요소들을 개별적으로 재작성함으로써 새로운 언어/플랫폼으로 발전시키기 쉽다.
  • 실제로는 어떤 모듈들이 최신의 것으로 갱신되었기 때문일 수도 있다.

심리적인 효과일 뿐인 것도 있지만, 심리적인 것도 중요하다. 결국 언어에 대한 독재는 그것이 주는 유익보다 거기에 드는 비용이 더 크다.

4.2 현명하게 타협하기

4.2.1 작업 일정의 압박과 싸우는 방법

출시 시간(time-to-market)의 압박은 좋은 제품을 신속하게 내놓기 위한 압박이다. 이것은 재정적 현실을 반영하는 것이기 때문에 나쁠 것도 없고, 어떤 점에서는 건전한 것이다. 작업 일정의 압박은 내놓을 수 있는 시간보다 더 빨리 내놓기 위한 압박이며, 이것은 낭비적이고 건전하지도 않지만, 너무도 흔하다.

작업 일정의 압박은 몇 가지 이유로 존재한다. 프로그래머들에게 과제를 맡기는 사람들은 우리가 얼마나 강한 직업윤리를 갖고 있으며 프로그래머가 된다는 것이 얼마나 재미있는 일인지 충분히 인식하지 못한다. 아마도 그들은 자신의 행동 방식을 우리에게 그대로 비춰 보기 때문에, 더 빨리 하라고 요구하면 더 열심히 일하게 될 것이라고 믿는다. 이것은 어쩌면 실제로 사실일 수도 있지만, 그 효과는 매우 작으며 손해는 매우 크다. 게다가 그들은 소프트웨어를 만들기 위해 실제로 무엇이 필요한지 볼 수 있는 눈이 없다. 볼 수도 없고 스스로 만들 수도 없기 때문에, 그들이 할 수 있는 단 한 가지는 출시 시간의 압박을 보면서 프로그래머들에게 그것에 대해 떠들어대는 일이다.

작업 일정의 압박과 싸우는 열쇠는 그것을 출시 시간의 압박으로 바꿔 놓는 것이다. 이렇게 하는 방법은 가용 인력과 제품 사이의 관계를 잘 볼 수 있게 하는 것이다. 개입된 모든 인력에 대해 정직하고 상세하고 무엇보다도 이해할 만한 추정치를 내놓는 것이 이것을 위한 가장 좋은 방법이다. 이것은 직무의 조정 가능성에 대한 관리상의 의사결정을 잘 할 수 있게 해 준다는 추가적인 장점이 있다.

이런 추정을 통해 명백해지는 중요한 통찰은, 인력이 비압축성 유체(incompressible fluid)와 같다는 것이다. 그릇의 부피보다 더 많이 물을 눌러넣을 수 없듯이, 일정 시간 안에 더 많은 것을 우겨넣을 수 없다. 어떤 점에서 프로그래머는 '못 합니다.'라고 하기보다는, '원하는 그 일을 위해 무엇을 포기하겠습니까?'라고 해야 할 것이다. 추정을 명확하게 함으로써 프로그래머가 더욱 존중받게 되는 효과가 있을 것이다. 다른 직종의 전문가들은 바로 이렇게 행동한다. 이로써 프로그래머들의 고된 일이 눈에 보이게 될 것이다. 비현실적인 작업 일정을 잡았다는 사실도 고통스럽겠지만 모든 사람에게 분명히 드러날 것이다. 프로그래머들은 함부로 현혹할 수 있는 사람들이 아니다. 그들에게 비현실적인 것을 요구하는 일은 예의 없고 비도덕적인 일이다. 익스트림 프로그래밍(Extreme Programming)은 이것을 상세히 설명하고 있으며 그 과정을 확립해 놓고 있다. 나는 모든 독자들이 이 기법을 활용할 수 있을 만큼 운이 좋기를 바란다.

4.2.2 사용자를 이해하는 방법

우리에게는 사용자를 이해하고, 또한 상사가 그 사용자를 이해할 수 있게 도와 줄 의무가 있다. 사용자는 우리처럼 제품 생산에 깊이 개입되어 있지 않기 때문에 다음과 같이 조금 특이하게 행동한다.
  • 사용자는 일반적으로 짧게 말하고 끝낸다.
  • 사용자는 자기 일이 따로 있다. 그들은 대개 제품이 크게도 아니고 약간 개선되었으면 좋겠다고 생각한다.
  • 사용자는 그 제품 사용자들 전체를 볼 수 있는 눈이 없다.

우리는 그들이 원한다고 말한 것이 아니라, 정말로 그들이 원하는 것을 제공할 의무가 있다. 그래서 일에 착수하기 전에 이쪽에서 먼저 제안을 하고, 그것이 정말로 그들이 원하는 것이라는 동의를 얻는 것이 더 나을 수 있다. 하지만 그들은 이렇게 하는 것이 바람직하다는 것을 모를 수도 있다. 그것을 위한 자신의 아이디어에 대한 자신감의 정도는 경우에 따라 달라져야 한다. 고객이 정말로 무엇을 원하는지 아는 것에 대해, 자만심과 거짓 겸손, 둘 다 경계해야 한다. 프로그래머들은 설계하고 만들어내도록 훈련된다. 시장 연구자들은 사람들이 무엇을 원하는지 알아내도록 훈련된다. 이 두 종류의 사람들, 아니 한 사람 안에 있는 두 가지 사고방식은 함께 조화를 이룰 때 정확하게 통찰할 수 있는 최상의 조건이 된다.

사용자들과 시간을 많이 보낼수록 무엇이 실제로 성공적일지 더 잘 이해하게 될 수 있을 것이다. 가능한 한 많이 자신의 생각을 사용자들의 생각과 비교하여 검사해 봐야 한다. 할 수 있다면 그들과 함께 먹고 마시기도 해 봐야 한다.

가이 카와사키(Guy Kawasaki)는 사용자들의 말을 듣는 것에 더하여 그들이 무엇을 하는지 관찰하는 것의 중요성을 강조한 바 있다. <Rules>

내가 알기로, 의뢰인들이 진정으로 원하는 것이 무엇인지 그들 자신의 마음에 분명해지게 하는 일에 계약직 프로그래머나 컨설턴트들이 엄청난 어려움을 겪는 경우가 종종 있다. 컨설턴트가 될 생각이 있는 사람은 의뢰인을 선택할 때 그들의 수표책뿐만 아니라 그들의 머리 속이 얼마나 명료한지도 확인하라고 권하고 싶다.

4.2.3 진급하는 방법

어떤 역할로 진급하고 싶다면, 그 역할을 먼저 실행하라.

어떤 직위로 진급하고 싶다면, 그 직위에 기대되는 것이 무엇인지 파악하여 그것을 행하라.

임금 인상을 원한다면, 정확한 정보로 무장하고 협상하라.

진급을 할 때가 지났다고 느껴지면, 상사에게 그것에 대해 이야기하라. 진급을 하기 위해 무엇을 해야 하는지 숨기지 말고 그들에게 질문하라. 진부한 이야기로 들리겠지만, 스스로 무엇이 필요하다고 인식하는 것과 상사가 인식하는 것이 상당히 다른 경우가 종종 있다. 또한 이것은 어떤 식으로든 상사에게 그 일을 확실히 못 박아 두는 것도 된다.

대부분의 프로그래머들이 자신의 상대적 능력에 대해 어떤 면에서는 과장되게 생각하는 것 같다. 하지만, 우리가 모두 상위 10%가 될 수는 없는 노릇이다! 그러나, 심각하게 진가를 인정받지 못하는 사람들도 많이 봐 왔다. 모든 사람의 평가가 항상 정확하게 실체와 일치할 것이라고 기대할 수는 없지만, 한 가지 단서가 있다면 사람들은 일반적으로 적당히 공정할 것이라고 생각한다. 자신의 일을 드러내 보여주지 않는다면 제대로 평가받을 수도 없다. 때로는 우연한 실수나 개인적인 버릇 때문에, 충분히 주목받지 못하기도 한다. 집에서 주로 일하거나 팀이나 상사와 지리적으로 떨어져 있는 것 때문에 이것이 특히 어려워지기도 한다.

4.3 팀을 위해 일하기

4.3.1 재능을 개발하는 방법

니체(Nietzsche)는 이렇게 과시하며 말했다. <Stronger>

나를 파괴하지 않는 것은 나를 강하게 하는 것이다.


우리가 가장 많이 책임져야 할 대상은 우리 팀이다. 팀원들을 모두 잘 알아야 한다. 팀에게 도전적으로 요구하더라도, 지나치게 무거운 짐을 지워서는 안 된다. 그들이 긴장을 유지하는 방법에 대해 그들과 이야기해 봐야 할 것이다. 그들이 그것을 기꺼이 받아들인다면(buy in), 더욱 동기가 높아질 것이다. 모든 프로젝트, 또는 하나 건너 하나의 프로젝트마다 그들이 제안한 방법과 그들에게 좋을 것 같다고 생각되는 방법으로 긴장을 유지하게 해 줘야 한다. 그들에게 일을 더 많이 맡기는 것보다는, 새로운 기능을 알려주거나 더 좋게는 팀에서 능력을 발휘할 새로운 역할을 부여하여 긴장을 유지하게 하라.

다른 사람들은 물론 자기 자신도 간혹 일이 안 풀릴 수 있다는 것을 인정해야 하며, 일정대로 일이 진행되지 않을 경우를 대비한 계획을 세워 놓아야 한다. 항상 일이 잘 된다면, 모험은 아무 의미가 없을 것이다. 일이 안 풀리는 경우가 없다는 것은, 위험 부담 없이 편하게만 일을 하고 있다는 뜻이다. 누군가 일이 잘 안 됐다면, 그들이 성공한 것처럼 대우할 필요는 없겠지만, 최대한 부드럽게 대해야 한다.

모든 팀원들이 기꺼이 받아들이고 동기를 높일 수 있도록 노력하라. 팀원 각자에게 그들이 동기가 높지 않을 때 어떻게 해 주면 좋은지 터놓고 물어 보라. 그들을 불만족스러운 채로 내버려둬야 할 경우도 있지만, 각자가 바라는 것이 무엇인지는 알고 있어야 한다.

낮은 의욕이나 불만족 때문에 자기 몫의 짐을 일부러 지지 않는 사람을 무시해 버리거나 되는 대로 내버려 둘 수는 없다. 그들의 동기와 생산성을 높이도록 노력해야 한다. 참을 수 있는 한 계속 노력하라. 인내의 한계를 넘어섰다면 그들을 해고하라. 일부러 자기 능력 이하로 일하는 사람들을 팀에 계속 있게 할 수는 없다. 그렇게 하는 것은 팀에 공정한 일이 아니다.

능력 있는 팀원들에게는 그들이 능력 있다고 생각한다는 사실을 공개적으로 이야기함으로써 그 사실을 확인시켜 주라. 칭찬은 공개적으로, 비판은 사적으로 해야 한다.

능력 있는 팀원들은 자연적으로 능력이 모자라는 팀원들보다 더 어려운 과제를 맡는다. 이것은 아주 자연스러운 일이며, 모두가 다 열심히 일하는 한 아무도 이것 때문에 귀찮아하지 않을 것이다.

좋은 프로그래머 한 사람이 안 좋은 프로그래머 열 사람보다 생산성이 높은데도 그것이 봉급에 반영되지 않는 것은 이상한 일이다. 이것 때문에 미묘한 상황이 생긴다. 능력이 모자란 프로그래머가 길을 비켜 주면 일을 더 빨리 진행할 수 있는 경우가 사실 종종 있다. 그렇게 하면 실제로 단기간에는 더 많은 성과를 낼 수도 있다. 하지만, 부족(tribe) 전체로서는 여러 중요한 이득을 잃게 된다. 능력이 모자라는 팀원의 훈련, 팀 내 지식의 확산, 능력 있는 팀원이 없을 때 대신할 능력 등이 그것이다. 능력 있는 사람들은 이 점에 관해서는 너그러울 필요가 있고 그 문제를 다각도로 고려해야 한다.

능력 있는 팀원에게는 도전할 만하면서 범위가 잘 정의된 과제를 맡겨 보는 것도 좋다.

4.3.2 일할 과제를 선택하는 방법

프로젝트의 어느 부분을 맡아 할 것인지 선택할 때에는 자신의 개인적 필요와 팀 전체의 필요 사이에서 균형을 잡아야 한다. 물론 가장 잘 하는 일을 선택해야겠지만, 일을 더 많이 하는 것보다는 새로운 기능을 발휘할 수 있는 것을 통해 스스로 긴장을 유지할 수 있는 길을 찾아보도록 하라. 지도력과 의사소통 기능은 기술적 기능보다 더 중요하다. 자신의 능력이 뛰어나다면, 더 어렵고 위험부담이 큰 과제를 맡고, 위험부담을 줄이기 위해 프로젝트에서 그 일을 최대한 빨리 처리하라.

4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법

팀 동료들이 최대한 능력을 발휘하게 하기 위해서는, 단체정신을 키우고 팀원 모두가 개별적으로 도전을 느끼고 개별적으로 일에 몰두하도록 격려하라.

단체정신을 키우기 위해서는, 로고가 새겨진 옷이나 파티처럼 다소 진부한 것도 좋지만, 개인적으로 존중하는 것만큼 좋지는 않다. 모두가 모두를 존중하면 아무도 다른 사람을 깎아내리고 싶지 않을 것이다. 단체정신은 사람들이 팀을 위해 희생하고 자신의 이익보다 팀의 이익을 먼저 생각할 때 만들어진다. 팀장으로서 이 점에 대해 솔선해서 한 것 이상으로 다른 사람에게 요구할 수는 없을 것이다.

팀에 대한 지도력의 한 가지 열쇠는 모든 사람이 기꺼이 받아들일 수 있는 합의를 이뤄내는 것이다. 이것은 팀 동료들이 잘못된 일을 하는 것을 인정한다는 말이기도 하다. 즉, 그것이 프로젝트에 너무 큰 피해를 주지만 않는다면, 비록 나는 그렇게 하는 것이 잘못된 것이라는 분명한 확신이 있다 해도, 팀원 중 누가 자기 방식대로 일하는 것을, 합의에 따라 그렇게 하게 두어야 한다. 이런 일이 생길 때는, 찬성하지 말고 공개적으로 반대하되, 합의된 것은 받아들이라. 마음이 상했다거나 어쩔 수 없이 그렇게 한다는 식으로 말하지 말고, 그것에 반대하지만 팀의 합의를 더 중요하게 생각한다고 꾸밈없이 말하라. 이렇게 할 때 그들이 돌이키기도 한다. 그들이 돌이켰다면 그들에게 원래 계획대로 밀고 나가라고 고집하지는 말라.

그 문제에 대해 적절한 모든 관점에서 논의한 후에도 동의하지 않는 사람이 있다면, 이제 결정을 내려야 하며 이것이 나의 결정이라고 꾸밈없이 단언하라. 자신의 결정이 잘못되었는지 판단할 방법이 있거나 나중에 잘못된 것으로 밝혀진다면 할 수 있는 대로 빨리 돌이키고 옳았던 사람을 인정하라.

단체정신을 키우고 팀을 효과적으로 만들기 위해 어떻게 하는 것이 좋을지 팀 전체와 팀원 각자에게 물어보라.

자주 칭찬하되 분별없이 하지는 말라. 특별히 나와 의견이 다른 사람도 칭찬할 만할 때에는 바로 칭찬하라. 공개적으로 칭찬하고 사적으로 비판하라. 한 가지 예외는 있다. 과실을 바로잡아 가치가 증대된 것(growth)을 공개적으로 칭찬할 때에는 원래의 과실이 눈길을 끄는 난처한 상황이 될 수도 있으므로, 가치 증대에 대해서는 사적으로 칭찬하는 것이 좋다.

4.3.4 문제를 나누는 방법

소프트웨어 프로젝트를 맡아서 각 사람이 수행할 과제들로 나누는 것은 재미있는 일이다. 이것은 초반에 해야 한다. 관리책임자들이 그 일을 수행할 각 사람들에 대해 고려하지 않아도 시간을 추정할 수 있다고 생각하는 경우가 있는 것 같다. 이것은 불가능한 일이다. 각자의 생산성은 아주 크게 차이가 나기 때문이다. 어떤 구성요소(component)에 대한 특정 지식이 있는 사람도 계속 변화해 가므로, 수행 능력에서 여러 배의 차이가 날 수도 있다.

지휘자가 연주할 악기의 음색을 고려하고 운동 경기 코치가 각 선수의 능력을 고려하는 것처럼, 경험 많은 팀장이라면 프로젝트를 과제들로 나누는 일을, 그 과제가 할당될 팀원들과 분리해서 생각하지는 않을 것이다. 이것은 수행 능력이 뛰어난 팀이 해체되어서는 안 되는 이유이기도 하다.

여기에도 위험이 다소 따르는데, 사람들이 능력을 쌓아가는 과정에서 따분해져서 약점을 개선하거나 새로운 기능을 배우려고 하지 않는 경우가 그것이다. 하지만, 전문화는 남용되지만 않는다면 생산성 향상에 매우 유용한 도구가 된다.

4.3.5 따분한 과제를 다루는 방법

간혹 회사나 프로젝트의 성공에 결정적이기 때문에 과제가 따분해도 피할 수 없는 경우가 있다. 이런 과제들은 그것을 해야 하는 사람들의 사기를 실제로 떨어뜨릴 수 있다. 이것을 다루는 가장 좋은 기법은 래리 월(Larry Wall)이 말한 '프로그래머의 게으름의 미덕(virtue of Laziness)'을 불러일으키고 북돋아 주는 것이다. 자신이나 동료 대신 컴퓨터가 그 과제를 처리하게 하는 방법이 없는지 찾아보라. 수작업으로 한 주에 할 과제를 해결할 프로그램을 짜는 데 한 주가 걸린다 해도 이것이 더욱 교육적이고 필요하면 반복해서 쓸 수도 있으므로 더 큰 이득이 있는 것이다.

모든 방법이 수포로 돌아간다면, 따분한 일을 해야 하는 사람들에게 양해를 구해야겠지만 어떤 경우에도 그들이 혼자 하게 내버려 두지는 말라. 최소한 두 사람으로 팀을 짜서 그 일을 맡기고 그 일을 완수하기 위해 성실히 협력할 수 있도록 격려하라.

4.3.6 프로젝트를 위한 지원을 얻는 방법

프로젝트를 위한 지원을 얻기 위해서는, 조직 전체가 추구할 실제적인 가치를 잘 드러내는 이상(vision)을 만들고 알려야 한다. 이상을 만드는 일에 다른 사람들도 동참하도록 노력하라. 이것을 통해 그들에게는 우리를 지원할 이유가 생기며 우리에게는 그들의 아이디어를 얻는 혜택이 생긴다. 프로젝트를 위한 핵심적인 지원 인사들을 개별적으로 모집하라. 갈 수 있는 곳이면 어디든 가서, 말만 하지 말고 보여주라. 할 수 있다면, 자신의 아이디어를 시연할 수 있는 시제품(prototype)이나 실물모형(mockup)을 만들라. 시제품은 어느 분야에서든 효력이 있지만 소프트웨어 분야에서는 글로 쓴 어떤 설명보다 훨씬 더 우세하다.

4.3.7 시스템이 자라게 하는 방법

나무의 씨앗에는 어른 나무의 밑그림(idea)이 들어있지만 아직 그 형태나 능력이 완전히 발현되지는 않았다. 싹이 자라고 커진다. 점점 어른 나무를 닮아 가며 점점 더 쓸모 있게 되어 간다. 마침내 열매를 맺고, 그 후에는 죽어서 다른 생물을 위한 거름이 된다.

과장된 표현일 수도 있지만 소프트웨어도 그렇게 취급된다. 다리(bridge)는 그렇지 않다. 미완성 다리는 있어도 '아기 다리'는 없다. 다리는 소프트웨어에 비해 아주 단순하다.

소프트웨어가 자란다고 생각하는 것이 좋다. 그렇게 생각하면 머리 속에 완벽한 그림이 그려지기 전에도 훌륭히 전진해 갈 수 있기 때문이다. 사용자들의 반응을 듣고 소프트웨어의 성장을 바로잡아 줄 수 있다. 약한 가지를 쳐 주는 것도 건강에 좋다.

프로그래머는 전달받아 사용할 수 있는 완성된 시스템을 설계해야 한다. 그런데 고급 프로그래머는 그 이상을 할 수 있어야 한다. 완성된 시스템으로 귀결되는 성장 경로를 설계할 수 있어야 한다. 아이디어의 싹을 가지고 가능한 한 평탄한 경로를 따라 유용한 완성품이 만들어질 수 있게 하는 것이 우리가 할 일이다.

이를 위해서는, 최종 결과를 시각화하고 그것에 대해 기술팀이 흥미를 가질 수 있도록 전달해야 한다. 또한 현재 그들의 위치에서 그들이 원하는 위치까지 가는 경로를 비약 없이 잘 전달해야 한다. 나무는 그 기간 내내 살아 있어야 한다. 어느 순간에 죽었다가 나중에 부활할 수는 없다.

이런 접근 방법은 나선형 개발(spiral development)에 그대로 반영되어 있다. 그 경로에 따라 진도를 표시하기 위해 간격이 너무 멀지 않은 진도표(milestones)를 사용한다. 사업이라는 무한 경쟁의 환경에서는, 비록 잘 설계된 최종 목표와는 거리가 멀다 해도 진도별 배포판(milestone release)을 계속 내면서 최대한 빨리 돈을 버는 것이 상책이다. 프로그래머의 임무 중 하나는, 일정표에 명시되는 성장 경로를 현명하게 선택함으로써 즉각적인 이득과 미래의 이득 사이에 균형을 잡는 일이다.

고급 프로그래머는 소프트웨어와 팀과 개개인의 성장에 대한 3중의 책임이 있다.

독자인 롭 하퍼닉(Rob Hafernik)이 이 절에 대해 다음의 의견을 보내 왔는데, 전문을 인용하는 것이 가장 좋을 것 같다.

여기에서는 그 중요성이 덜 강조된 것 같습니다. 이것은 시스템만의 문제가 아니며, 알고리듬, 사용자 환경(user interface), 데이터 모형(data model) 등의 문제이기도 합니다. 이것은 대형 시스템의 작업을 할 때 중간 목표들을 향해 진도를 맞춰 가기 위해서는 정말로 대단히 중요합니다. 끝까지 다 가서야 전체가 전혀 작동하지 않는다는 사실을 알게 되는 공포 상황만큼 나쁜 것은 없을 것입니다. (보우터 뉴스 서비스(Voter News Service)가 최근 해체된 것을 보십시오. 역자 주: 보우터 뉴스 서비스는 미국 언론사들이 출구 조사를 위해 공동 설립한 기관으로, 2002년 11월 미국 중간 선거를 대비하여 1,000만 달러 이상을 투자하여 시스템을 새롭게 갖추었으나, 선거 당일에 총체적인 문제가 생겨 출구 조사 결과 발표를 포기하고 말았다. 이 기관은 2003년 1월 해체되었다.) 한 걸음 더 나아가 이것은 자연 법칙이라고까지 말하고 싶습니다. 대형의 복잡한 시스템은 무에서 시작하여 구현할 수 없습니다. 의도한 단계를 거쳐 가면서 단순한 시스템에서 복잡한 시스템으로 진화하는 것만 가능합니다.


이 인용글에 대해서는 "빛이 있으라(Fiat lux)!" 하고 응답할 수밖에 없을 것이다.

4.3.8 대화를 잘 하는 방법

대화를 잘 하기 위해서는 우선 그것이 얼마나 어려운 것인지 인식해야 한다. 이것은 기능 자체에 대한 기능이다. 대화할 대상자들이 결점이 있는 사람들이라는 사실 때문에 이 일은 더욱 어려운 일이 된다. 그들은 나를 이해하는 일에 별로 노력을 들이지 않는다. 그들은 말도 잘 못 하고 글도 잘 못 쓴다. 그들은 대개 과로하고 있거나 따분해하고 있으며, 지금 말하고자 하는 큰 문제들보다는 자기 자신의 일에만 초점을 맞추고 있는 것 같다. 개설되어 있는 강좌를 통해 글쓰기, 연설, 듣기 기능을 연습하면, 이것들을 잘 하게 될 때 문제가 어디에 있는지, 그것을 어떻게 고칠 수 있는지 더 쉽게 볼 수 있다는 장점이 있다.

프로그래머는 자기 팀과 대화하는 일에 생존이 달려 있는 사회적 동물이다. 고급 프로그래머는 팀 밖의 사람들과 대화하는 일에 만족이 달려 있는 사회적 동물이다.

프로그래머는 무질서에서 질서를 끌어낸다. 이것을 하는 한 가지 흥미로운 방법은 팀 밖에서 어떤 제안을 시작하게 하는 것이다. 이것은 뼈대(strawman)나 백지 형식으로, 혹은 단지 구두로 시작될 수 있다. 이렇게 이끌어 가는 것은 토론의 조건을 설정한다는 점에서 굉장히 큰 장점이 있다. 이를 통해 나 자신이 비판, 더 나쁘게는 거부와 무시에 내놓인다. 고급 프로그래머는 고유한 권한과 그에 따른 고유한 책임이 있으므로, 이것을 받아들일 각오를 해야 한다. 프로그래머가 아닌 사업가들은 여러 가지 점에서 지도력을 발휘하기 위해 프로그래머가 필요하다. 프로그래머들은 현실에 기초하여 아이디어와 현실을 이어주는 다리의 한 부분이다.

나도 대화를 잘 하는 일에 정통하지는 않지만, 현재 노력하고 있는 것은 네 갈래의 접근 방식이다. 이것은, 아이디어를 정돈하고 충분히 준비를 갖춘 다음, 구두로 이야기를 하고, 사람들에게 백지를 (실제 종이로든, 전자적으로든) 나눠주고, 시연을 하고, 인내심을 가지고 이 과정을 반복하는 것이다. 이런 어려운 대화 과정에서 충분히 인내심을 갖지 않는 때가 많다고 생각한다. 자기 아이디어가 즉각 받아들여지지 않는다고 해서 낙담해서는 안 된다. 그것을 준비하는 데에 노력을 들였다면, 그것 때문에 나를 하찮게 생각하는 사람은 없을 것이다.

4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법

사람들에게 그들을 불편하게 할 말을 해야 할 때가 있다. 이 일은 어떤 이유가 있기 때문에 하는 것이라는 사실을 기억하라. 그 문제에 대해 아무 것도 할 수 없다 해도, 그들에게 할 수 있는 한 빨리 말해서 그들이 그 사실을 숙지하고 있게 해야 한다.

누군가에게 문제점에 대해 말하는 가장 좋은 방법은 해결책을 동시에 제시하는 것이다. 두 번째로 좋은 방법은 그 문제점에 대해 도움을 요청하는 것이다. 그 사람이 믿지 않을 위험이 있다면, 그 말을 지지해 줄 사람을 모아 봐야 할 것이다.

해야 하는 가장 불쾌하면서 일상적인 말들 중 하나는 ‘예정일을 넘길 것 같군요.’라고 말하는 것이다. 양심적인 프로그래머라면 이런 말을 하기가 싫을 테지만, 그래도 최대한 빨리 해야 한다. 진도 날짜를 지나쳤을 때, 할 수 있는 것이 모든 사람들에게 그 사실을 알리는 일밖에 없다 해도, 대응이 지연되는 것보다 안 좋은 일은 없다. 이런 일을 할 때에는, 물리적으로 같이 하지는 못하더라도, 정신적으로라도 팀으로 같이 하는 것이 더 좋다. 지금의 위치와 그것을 해결하기 위한 일에 대해 팀원들의 의견이 필요할 것이며, 팀원들도 그 결과를 함께 직시해야 할 것이다.

4.3.10 관리상의 신화들을 다루는 방법

신화라는 단어는 허구를 뜻하기도 한다. 하지만 좀 더 깊은 함축이 있다. 이것은 우주에 대해, 그리고 인류와 우주의 관계에 대해 설명하는 종교적으로 중요한 이야기를 뜻하기도 한다. 관리책임자들은 프로그래머로서 배운 것은 잊어버리고, 어떤 신화들을 믿곤 한다. 그 신화들이 거짓이라고 그들에게 설득하려고 하는 것은, 독실한 종교인에게 그들의 믿음에 대한 환상을 깨뜨리려고 하는 것처럼 귀에 거슬리고 성공 가능성이 없는 일이다. 그렇기 때문에 이런 신념들을 신화라고 인식해야 한다.
  • 문서는 많이 만들수록 좋다. (그들은 문서를 원하지만, 그들은 문서를 작성하는 데 시간을 쓰는 것을 원하지 않는다.)
  • 프로그래머들은 다 같다. (프로그래머들도 천차만별로 다르다.)
  • 지연되는 프로젝트에 새로운 자원을 투입해서 진척 속도를 높일 수 있다. (새로 들어온 사람들과 대화하는 데 드는 비용은 거의 항상 도움이 되기보다는 부담이 된다.)
  • 소프트웨어 개발 시간을 확실히 추정하는 것이 가능하다. (이론적으로도 불가능하다.)
  • 프로그래머의 생산성은 코드의 줄 수와 같은 간단한 척도로 측정될 수 있다. (간결한 것을 중시한다면 코드의 줄 수가 늘어나는 것은 좋은 것이 아니라 나쁜 것이다.)

기회가 된다면 이러한 것들을 설명해 볼 수는 있을 것이다. 하지만 실패하더라고 기분나빠 하지 말고, 이런 신화들에 호전적으로 맞서다가 자신의 평판이 나빠지게 하지도 말라. 이러한 신화들 때문에 관리책임자들은 현재 진행되는 프로젝트에 대해서 실제로 통제력을 가지고 있다는 생각을 더욱 굳힌다. 결국 관리책임자가 좋은 사람이라면 도움이 될 것이고, 안 좋은 사람이라면 방해가 될 것이라는 것이 진리이다.

4.3.11 조직의 일시적 혼돈 상태를 다루는 방법

조직이 짧은 시기 동안 큰 혼돈을 겪는 때가 종종 있다. 예를 들어, 근신(layoff), 기업 인수(buyout), 회사 공개(IPO, Initial Public Offering), 해고, 신규 채용 등이 그것이다. 이것은 모든 사람의 마음을 어지럽게 하지만, 자기의 지위가 아닌 능력에 근거하여 개인적 자부심을 가지고 있는 프로그래머는 어지러움이 조금 덜할 것이다. 조직의 혼돈은 프로그래머들이 자신의 마법의 능력을 시험해 볼 수 있는 좋은 기회이다. 나는 이 이야기를 끝까지 아껴 두었다. 이것은 우리 부족(tribe)의 은밀한 비밀이기 때문이다. 프로그래머가 아닌 사람은 이제 그만 읽기를 바란다.

기술자들은 만들고 유지하는 능력이 있다.


전형적인 소프트웨어 회사의 경우, 비기술자들이 주변 사람들에게 지시할 수는 있지만, 기술자 없이는 아무것도 만들거나 유지할 수 없다. 이는 기술자가 일반적으로 제품을 팔거나 사업을 효과적으로 운영할 수 없는 것과 같다. 기술자들의 이 능력은 일시적인 조직의 혼란(mayhem)에 관한 거의 모든 문제들에 대해 버틸 수 있는 힘이 된다. 이런 능력을 가졌다면 이 혼돈을 완전히 무시하고 마치 아무것도 일어나지 않은 것처럼 행동하면 된다. 물론 자신이 해고되는 경우도 있겠지만 이 마법의 능력 때문에 곧 새로운 직장을 찾게 될 것이다. 더욱 흔하게는, 마법의 능력도 없이 스트레스를 받고 있는 사람이 내 자리에 와서 어떤 어리석은 일을 하라고 할 수도 있다. 그 일이 정말로 어리석다고 확신한다면 그 사람 앞에서 그냥 웃으면서 고개를 끄덕이고 회사를 위해서 가장 좋다고 생각되는 다른 일을 하는게 최선이다.

만약 팀장이라면, 팀원들에게도 같은 식으로 하라고 말해 주고, 다른 누가 무슨 말을 해도 무시하라고 말해 주라. 이런 행동 방식이 나 개인에게도 최선이고, 회사와 프로젝트에도 최선이다.

5 참고 문헌

5.1

<Rules00> Guy Kawasaki, Michelle Moreno, and Gary Kawasaki. 2000. HarperBusiness. Rules for Revolutionaries: The Capitalist Manifesto for Creating and Marketing New Products and Services.

<RDev96> Steve McConnell. 1996. Microsoft Press. Redmond, Wash. Rapid Development: Taming Wild Software Schedules.

<CodeC93> Steve McConnell. 1993. Microsoft Press. Redmond, Wash. Code Complete.

<XP99> Kent Beck. 1999. 0201616416. Addison-Wesley. Extreme Programming Explained: Embrace Change.

<PlanXP00> Kent Beck and Martin Fowler. 2000. 0201710919. Addison-Wesley. Planning Extreme Programming.

<Prag99> Andrew Hunt, David Thomas, and Ward Cunningham. 1999. 020161622X. Addison-Wesley. The Pragmatic Programmer: From Journeyman to Master.

<Stronger> Friedrich Nietzsche. 1889. Twilight of the Idols, "Maxims and Arrows", section 8.

5.2 웹 사이트

<PGSite> Paul Graham. 2002. 그의 사이트에 있는 논설(article)들: http://www.paulgraham.com/articles.html 모두 읽을 만하지만, 특히 "Beating the Averages".

<Hacker> Eric S. Raymond. 2003. How to Become a Hacker. http://www.catb.org/~esr/faqs/hacker-howto.html.

<HackDict> Eric S. Raymond. 2003. The New Hacker Dictionary. http://catb.org/esr/jargon/jargon.html

<ExpCS> Edsger W. Dijkstra. 1986. How Experimental is Computing Science? http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD988a.PDF

<Knife> Edsger W. Dijkstra. 1984. On a Cultural Gap. http://www.cs.utexas.edu/users/EWD/ewd09xx/EWD913.PDF

6 역사 (2003년 5월 현재) / History (As Of May, 2003)

6.1 피드백 및 확장 요청 / Request for Feedback or Extension

이 에세이에 대한 의견이 있다면 나에게 보내주십시오. 나는 모든 의견을 반영하려고 노력하고 있으며 많은 수의 의견들이 이 에세이를 발전시켰습니다.

이 에세이는 GNU Free Documentation License를 따릅니다. 이 라이센스는 에세이에만 적용되는 것이 아닙니다. 에세이는 보통 한 사람의 하나의 관점에 바탕을 두고 쓰여져서 특정한 주장에 집착하고 그것을 확신시키려는 경향이 있습니다. 나는 이 에세이가 쉽고 즐겁게 읽힐 수 있었으면 합니다.

또한 나는 이것이 교육적이었으면 합니다. 비록 교과서는 아닐지라도 이것은 많은 단락으로 나뉘어 있어서 쉽게 새로운 단락이 추가될 수 있습니다. 너무 한쪽 시각으로 편중되었다고 생각한다면 올바르다고 생각되는 쪽으로 이 에세이에 추가하십시오. 이것은 이 라이센스의 목적이기도 합니다.

이 문서가 확장될 가치가 있다고 생각하는 것이 너무 잘난 척 하는 것 같기도 하지만, 이것이 영원히 진화됐으면 합니다. 이것이 다음과 같은 방식으로 확장된다면 기쁘겠습니다.
  • 쉽게 읽을 수 있는 목록이 각 단락에 추가됨.
  • 더 많은, 더 좋은 단락이 추가됨.
  • 비록 단락 단위로 번역되는 한이 있더라도 다른 언어로 번역됨.
  • 틀린 점이나 보충할 것이 추가됨.
  • 팜(PDA의 한 종류) 문서나 더 나은 HTML 같이 다른 문서 형식으로 변환될 수 있게 됨.

만약 이러한 일을 나에게 알려 준다면 이 라이센스(GFDL)의 목적에 따라서 다음 버전에 추가하겠습니다. 물론 이 라이센스에 나와 있는 대로, 나에게 알리지 않아도 이 문서에 대한 자기만의 버전을 만들 수 있습니다.

감사합니다.

로버트 L. 리드(Robert L. Read)

6.2 원본 / Original Version

이 문서의 원본은 로버트 L. 리드(Robert L. Read)에 의해 2000년부터 시작되었고 2002년에 사미즈다트(Samizdat) 출판사에서 최초로 전자 문서로 출판되었다.(http://Samizdat.mines.edu) Hire.com의 프로그래머들에게 이 문서를 바친다.

2003년 슬래쉬닷(Slashdot)에서 이 기사가 언급되었고 약 75명의 사람들이 제안과 수정할 것들을 이메일로 나에게 보내왔다. 그것에 감사한다. 비록 많은 중복이 있지만 다음에 열거된 사람들은 커다란 제안을 했거나 문제점을 고치도록 도움을 준 사람들이다. 모건 맥과이어(Morgan McGuire), 데이빗 메이슨(David Mason), 톰 뫼르텔(Tom Moertel), 슬래쉬닷의 닌자 프로그래머(Ninja Programmer) (145252), 벤 비어크(Ben Vierck), 롭 하퍼닉(Rob Hafernik), 마크 하우(Mark Howe), 피터 파라이트(Pieter Pareit), 브라이언 그레이슨(Brian Grayson), 제드 A. 쇼어(Zed A. Shaw), 스티브 벤즈(Steve Benz), 막심 이오프(Maksim Ioffe), 앤드류 우(Andrew Wu), 데이빗 제쉬키(David Jeschke), 톰 코코런(Tom Corcoran).

마지막으로 크리스티나 밸러리(Christina Vallery)에게 감사를 드린다. 그의 수정과 사려깊은 읽기를 통해서 두번째 원고가 크게 발전했다. 그리고 웨인 알렌(Wayne Allen)에게 이 일을 시작하도록 격려해 준 것에 대해서도 감사 드린다.

6.3 원저자의 경력 / Original Author's Bio

로버트 L. 리드(Robert L. Read)는 미국 텍사스주 오스틴에서 부인과 두 아이와 함께 살고 있다. 현재 Hire.com에서 4년 동안 총수석 엔지니어로 일하고 있다. 그전에는 제지 산업 분야에서 스캐너로부터 이미지를 읽어 그것의 품질을 조절해주는 도구를 생산하는 4R Technology를 설립하기도 했다.

그는 1995년 텍사스 주립 대학에서 데이터베이스 이론에 관한 연구로 전산 과학 박사 학위를 받았다. 1987년에는 라이스(Rice) 대학에서 전산 과학 학사 학위를 받았다. 그는 16세 때부터 직업 프로그래머로 일하고 있다.


원저자가 보내온 편지
Subject: RE: Your essay translated into Korean!
Date: Wed, 7 Jan 2004 09:28:48 -0600
From: <Read@hire.com>
To: <*******>

	Thank you!  I am thrilled and honored that this would be done.
I hope it benefits some Korean speakers who do not read English well
enough to enjoy the original.
	Unfortunately, I do not speak Korean---yet.  I do plan to study
it before I reach old age, but there are several other languages that 
I would like to master first.
	It is my understand that the Korean writing sysem (Han Gul?) is
a great acheivement of human invention and the Korean people.


-----Original Message-----
From: *******
Sent: Wednesday, January 07, 2004 7:49 AM
To: Rob Read
Subject: Your essay translated into Korean!


Thank you for your insightful essay, "How to be a Programmer."

Finally it's been translated into Korean on a Wiki site. You can read
it, if you can read Korean ;-), on
http://wiki.kldp.org/wiki.php/HowToBeAProgrammer
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패밀리

The Joel Test: 나은 코딩을 위한 12단계


글 : Joel Spolsky
번역 : B.K. Chung 정봉겸
감수 : Jang Han Goo 구장한
2000년 8월 9일

SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다.

The Joel Test

  1. Source Control(소스 컨트롤)을 사용하십니까?
  2. 한번에 빌드를 만들어낼 수 있습니까?
  3. daily build(일별 빌드)를 만드십니까?
  4. 버그 데이타베이스를 가지고 있습니까?
  5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
  6. up-to-date(최신) 스케줄을 가지고 있습니까?
  7. spec(설계서)를 가지고 있습니까?
  8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
  9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
  10. 테스터들을 고용하고 있습니까?
  11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
  12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?

Joel Test이 특별한 점은 각 직문에 예/아니오로 바로 대답할 수 있다는 것이다. lines-of-code-per-day(하루동안 산출되는 코드의 줄수)나 average-bugs-per-inflection-point(산출 시점의 평균 버그수) 같은 것은 알 필요가 없습니다. "예"에 해당 하는 질문에 1점씬 가산됩니다. 하지만 이 테스트는 핵 원자로에 사용하는 소프트웨어가 안전한지를 검사하는등 에는 사용하지 말아주십시오.

12점은 완벽, 11은 충분한 점수이지만 10점이나 그 이하는 심각한 문제가 있다는 신호입니다. 사실은 대개의 소프트웨어 회사 들이 2~3점을 받고 있고, 심각한 도움을 필요로 하고 있습니다. Microsoft같은 회사는 12점 만점을 받고 있습니다.

당연한 이야기지만 이것들만으로 성공과 실패를 가를 수는 없습니다. 특히, 아무도 필요없는 제품을 굉장히 훌륭한 소프트웨어 팀이 만들고 있다면, 역시나 아무도 원하지 않을 것입니다. 반대로 이런 방식을 따르지 않는 명인들이 세상을 바꾸는 소프트웨어 를 만드는 경우로 생각할 수 있겠습니다. 그러나, 이 12가지 이외의 요소를 모두 동등하게 놓고 본다면, 이들만 제대로 한다면 지속적으로 좋은 결과를 내는 잘 훈련된 팀이 될 것입니다.

1. Source Control(소스 컨트롤)을 사용하십니까?

상용 소스 컨트롤 패키지들도 사용해보았고, 무료로 사용할 수 있는 CVS도 사용해보았습니다. CVS는 무료이기는 하지만 충분합니다. 그렇지만 소스 컨트롤이 없다면 프로그래머들을 조율하는 일이 상당히 피곤할 것입니다. 프로그래머들은 다른 사람들이 어떤 것을 했는지 알 수 있는 방법이 없습니다. 이를 사용하면 실수를 쉽게 롤백할 수 있습니다. 소스 컨트롤의 다른 장점은 소스코드 자체가 모든 프로그래머의 하드디스크에 체크아웃(check out)되어 있다는 것입니다. 소스 컨트롤을 사용하는 프로젝트에서 코드를 날렸다는 이야기를 들어본 적이 없습니다.

2. 한번에 빌드를 만들어낼 수 있습니까?

"최신의 소스로부터 몇단계를 거쳐서 완제품(shipping build)을 만들 수 있습니까?"라는 의미의 질문입니다. 잘 되어있는 팀인 경우라면 하나의 스크립트로 checkout부터 시작하여 각 소스를 리빌드(rebuild)하고 각 버젼, 언어, #ifdef같은 조건별로 실행파일을 만들어내어 마지막 CDROM 레이아웃, 다운로드할 수 있는 웹사이트를 만들어 내는 정도까지 되어 있을 수 있겠습니다.

만일 이 과정이 하나의 단계 이상을 거친다면, 여기서부터 에러가 발생할 확률이 생깁니다. 정해진 기일이 가까워질수록 "마지막" 버그를 수정하고 실행파일을 만드는 등을 위해 빠른 사이클을 필요로 할 것입니다. 코드를 컴파일하고 설치파일을 구성하는데에 20단계가 필요하다면 급박한 시간때문에 사소한 실수를 저지르게 될 것입니다.

필자가 마지막으로 근무했던 회사에서는 이런 이유로 WISE를 InstallShield(역자주 : 두 제품 모두 설치본을 만들기위한 도구 입니다.)로 교체하였습니다. 설치 과정을 스크립트를 통해서 NT 스케줄러로 밤새에 자동으로 실행하도록 하고자 하였는데, WISE는 스케줄러로 실행할 수 없던 이유입니다. (WISE의 친절한 분들이 최신 버젼에는 이것이 가능하다고 알려왔습니다.)

3. daily build(일별 빌드)를 만드십니까?

소스 컨트롤을 사용하다 보면 누군가가 빌드를 실패하게 만드는 코드를 체크인 할 수 있습니다. 예를 들면, 새로운 소스파일을 추가해서 그 사람의 컴퓨터에서는 잘 컴파일되지만, 이를 코드 레파지토리(repository)에는 추가를 하지 않았을 수 있습니다. 이 사람은 이를 잊고 만족한 상태에서 컴퓨터를 잠그고 집에 돌아갑니다. 그렇지만 이로 인해 다른사람들은 작업을 할 수 없게 되고 결국 찝찝하지만 결과없이 집으로 돌아갈 수 밖에 없습니다.

모르는 사이에 빌드를 실패하는 이런 컴파일 오류가 나지 않도록 daily build를 만들게 됩니다. 큰 팀에서는 이런 경우를 위해서 daily build를 매일 오후 - 점심시간등 - 에 합니다. 사람들은 점심시간 이전에 될 수 있는 한 많이 체크인을 합니다. 점심을 먹으로 갔다가 다시 돌아오면 빌드는 이루어져 있습니다. 빌드가 실패하면, 사람들은 빌드가 성공한 이전 소스로 작업을 하면 됩니다.

엑셀팀에서는 누군가 빌드를 깨면 벌칙으로 다른 사람이 다시 깰때까지 빌드를 관리하도록 벌칙을 주었습니다. 이는 빌드를 깨면 받는 벌칙으로써 뿐만 아니라 모든 이들이 돌아가면서 빌드를 관리할 수 있게하여, 어떻게 돌아가는 지를 익히게 하는 방법으로써도 좋았습니다.

daily build에 관해 더 자세히 아시려면 저의 기사 daily builds are your friend를 읽으십시오.

4. 버그 데이타베이스를 가지고 있습니까?

뭐라고 반박하셔도 확신합니다. 코드를 짜고 있다면 설령 혼자 짜더라도 정리된 버그 명세 데이타베이스를 가지고 있지 않다면 낮은 질의 코드로 제품을 출시할 것입니다. 많은 프로그래머들이 머리로 버그들을 모두 기억할 것이라고 생각합니다. 말도 안되는 이야기입니다. 제 경우에는 한번에 2~3개의 버그밖에 기억을 못하고, 다음날이 되거나 출시를 위해 급해지면 전부 잊어버리게 됩니다. 버그를 제대로 트래킹해야합니다.

버그 데이타베이스는 복잡할 수도 있고, 간단할 수도 있습니다. 최소한으로 갖추어야할 요소는 다음과 같습니다:

  • 버그를 완벽하게 재현할 수 있는 과정
  • 버그가 없었다면 이루어졌어야할 결과(동작)
  • 버그로 인하여 생긴 결과(동작)
  • 누가 이 버그에 할당되어 있는지
  • 고쳐진 버그인지 아닌지

버그 데이타베이스를 사용하지 않는 이유가 제품들이 너무 복잡해서라면, 이것들을 포함한 5컬럼의 테이블을 만들어서 사용하기 시작하세요.

버그 트래킹에 관해 더 읽으려면, Painless Bug Tracking을 읽으세요.

5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?

마이크로소프트 Windows용 Word의 첫 버젼은 죽음의 프로젝트였습니다. 끝이 없었습니다. 계속해서 스케줄을 펑크냈습니다. 팀 전체는 말도 안되는 시간동안 일했고, 계속해서 연기되고 또 연기되었습니다. 그 스트레스는 엄청났습니다. 빌어먹을 제품이 몇년 후에 출시되었을때, 마이크로소프트는 팀 전원을 Cancun으로 휴가보내고, 이 원인을 분석하기 시작했습니다.

그들이 깨닫게 된 것은 프로젝트 매니저들이 스케줄을 너무 강요하였기 때문에 프로그래머들은 코딩을 빨리 할 수 밖에 없었습니다. 게다가 버그를 고치는 단계는 스케줄에 아예 존재하지 않았습니다. 결과적으로 질이 아주 나쁜 코드를 만들게 되었습니다. 버그 갯수를 줄이려는 노력은 전혀 하지 않았습니다. 한 프로그래머는 텍스트의 높이를 계산하는 루틴 대신에 "return 12;"로 대체하여 버그 리포트로부터 이 값이 어떤 영향을 주었는지를 알고자 했습니다. 스케줄은 단지 버그일 수 밖에 없는 기능들을 모아 놓은 체크리스트였습니다. 나중에 이 상황을 "무한 결함 방식(infinite defects methodology)"이라고 이름지었습니다.

문제를 해결하기 위해서 마이크로소프트는 반대의 "무결함 방식(zero defects methodology)"라는 방식을 체택했습니다. 많은 프로그래머들은 경영진들의 명령에 의해서 버그 갯수를 줄일 수 있다고 생각했음직한 이 방식의 이름 탓에 이를 비웃었습니다. 하지만 실제로는 "무결함(zero defects)"이라는 이름은 주어진 시간에 가장 우선순위가 높은 것은 코딩하기전에 버그를 잡는 것이란 사실을 지칭하는 말이었습니다. 이유는 다음과 같습니다.

일반적으로 버그를 고치지 않고 방치하는 시간이 길어지면 길어질수록 고치는데 더 많은 시간과 금전이 요구된다는 것입니다.

예를 들면, 오타나 문법오류등은 컴파일러가 쉽게 잡아서 고치는데도 별로 문제가 되지 않습니다.

만일 버그가 처음 실행시에 발생하여 보이게 되면, 모든 코드가 머릿속게 생생하게 존재하기에 바로 고칠 수 있을 것입니다.

며칠전에 작성한 코드에서 버그를 찾게 되면 이를 고치기 위해 조금 시간이 더 걸릴 것입니다. 아마도 코드를 다시 보게 되면 대부분의 내용이 기억나고 적정한 시간내에 버그를 고칠 수 있을 것입니다.

하지만 몇달전에 작성한 코드에서 버그가 발견된다면 이미 그 코드에 관해서 많은 것이 이미 생각나지 않을 것이고, 고치기도 상대적으로 힘들 것입니다. 그때쯤 되면 다른 사람의 코드를 수정하고 있는 와중일지도 모르고, 그사람은 Aruba로 휴가를 떠나있을지도 모릅니다. 이렇게 된다면 버그를 고치는 것은 기술을 익히는 것같이 되어버릴 것입니다. 천천히 꼼꼼하게 그리고 주의 깊게 코드를 살펴봐야 하고, 물론 문제를 해결하는데에 얼마나 걸릴지 정확하게 판단하기 힘든 상황이 될 것입니다.

게다가 이미 출하된 코드에서 버그를 발견한다면, 이를 고치는데에 큰 대가를 치뤄야할지도 모를 것입니다.

이렇게 시간이 적게 들기 때문이라는 이유가 하나의 이유가 됩니다. 또다른 이유는 버그를 수정하는데 걸리는 시간을 예상하는 것보다는 새로운 코드를 작성하는데 걸리는 시간을 예상하기가 훨씬 쉽기 때문입니다. 예를 들면, 내가 당신에게 리스트를 소트하는 코드를 만드는데 얼마나 걸리냐고 물어본다면, 꽤 정확한 대답을 할 수 있을 것입니다. 그렇지만, 질문을 바꿔서 당신의 코드가 Internet Explorer 5.5만 설치되어있으면 동작하지 않는 버그를 고치는데 걸리는 시간을 묻는다면, 문제가 무엇인지도 모르는 상황이기 때문에 얼마나 걸릴지 추측하지도 못할 것입니다. 3일이 걸릴 수도 있을 것이고, 운좋으면 2분이 걸릴 수도 있을 것입니다.

이것이 의미하는 바는 고쳐야할 버그가 많이 존재하는 상태의 스케줄이라면 그 스케줄은 정확할 수가 없다는 것입니다. 그렇지만 이미 알고있는 버그들은 모두 고친 상태라면 그 스케줄은 상대적으로 상당히 정확하게 지킬 수 있는 스케줄일 것입니다.

버그 갯수를 0에 가깝게 하는 또하나의 좋은 점은 경쟁에서 훨씬 빠르게 대응할 수 있다는 것입니다. 어떤 프로그래머들은 이를 두고 제품을 바로 출하할 수 있는 항상 유지하는 것이라고 이야기합니다. 경쟁자가 고객들을 가로채갈만한 굉장히 좋은 기능을 새로 만들었다면 축척된 많은 버그를 수정할 필요없이 바로 이 기능을 추가할 수 있을 것입니다.

6. up-to-date(최신) 스케줄을 가지고 있습니까?

비즈니스에 당신의 코드가 조금이라도 중요한 부분이라면, 코드가 언제쯤 완성될 수 있는지를 아는 것 또한 중요하다는 것은 당연할 것입니다. 프로그래머들은 엉터리 스케줄을 만드는데 악명이 높습니다. "언젠가는 될꺼야!"하고 외칩니다.

불행하게도 그런 식으로는 해결할 수 있는것은 없습니다. 비즈니스에는 코드를 출하하기 전에 데모, 전시회, 광고등등 미리 많은 것들을 판단하여 결정해야합니다. 이를 할 수 있는 단 한가지 방법은 스케줄을 가지고 이를 계속해서 현실적으로 최신내용으로 유지하는 것입니다.

스케줄을 가져야하는 또다른 중요한 이유는 이를 통해서 어떤 기능이 필요한지를 결정하게끔 만들어준다는 것입니다. 때문에 어떤 기능이 덜 중요한지 결정해야하고 featuris 가 되기 전에 이들을 포기하도록 합니다.

스케줄을 관리하는 것이 어려울 필요는 없습니다. 제 글Painless Software Schedules 에 좋은 스케줄을 만드는 간단한 방법을 설명하였습니다.

7. spec(설계서)를 가지고 있습니까?

스펙을 만드는 것은 이빨을 쑤시는것과 같습니다: 모든 사람들이 좋다고 인정하지만, 아무도 하지 않습니다.

왜 그런 현상이 일어나는지는 정확히 모르겠습니다만, 아마도 프로그래머들이 문서를 만드는 것을 굉장히 싫어하는데에 기인하는 것 같습니다. 그 결과로, 프로그래머밖에 없는 집단에서 한가지 문제를 해결하고자 하면, 이들은 문서를 만들기 보다는 코드로 자신들의 의견을 표명하려 합니다. 스펙을 먼저 만들기보다는 차라리 코드를 짜서 보여주는 것을 택한다는 것입니다.

설계 단계에서 문제를 발견하면 몇줄을 고쳐서 이를 수정할 수 있습니다. 그렇지만 코드가 짜여진 상황이라면 이 문제를 수정하는 댓가는 감정적으로나(코드를 그냥 버리는 것을 좋아하는 사람은 없습니다) 시간적으로나 훨씬 높게 되고 더 힘든 작업이 되어버립니다. 스펙을 통해서 만들어지지 않은 소프트웨어는 대개 설계가 잘못되어 스케줄을 엉망으로 만들어놓습니다. Netscape에서도 이런 문제로 인해 브라우저의 초기 네개의 버젼이 너무 엉망이 되어 결국 관리자들이 멍청하게도 코드를 전부 버리고 다시 짜도록한 결정을 내려버리게 되는 상황이 벌어졌습니다. 거기다 한술 더 떠서 Mozilla에서 이런 실수를 다시 반복하여 겨우 Alpha 단계에 가는데 몇년이라는 시간이 걸리게 되었습니다.

필자의 지론은 이 문제는 프로그래머들이 문서를 작성하는데 거부감이 없도록 작문 강의를 듣도록 보내는 것으로 해결할 수 있다는 것입니다. 다른 해결책이라면 스펙같은 문서 작성에 능숙한 관리자를 두는 것입니다. 두 경우 모두 "스펙없는 코드는 금물"이라는 간단한 규칙을 따라야 할 것입니다.

저의 4부짜리 글에 스펙 작성하는 요령에 대해 이야기했습니다.

8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?

지식 근로자에게 공간, 조용함, 프라이버시를 줌으로해서 많은 생산성 향상을 얻는다는 것은 이미 증명된 사실입니다. 소프트웨어 관리의 고전인 Peopleware에서는 이 생산성 향상에 대해 자세히 기술합니다.

문제는 여기에 있습니다. 지식 근로자는 "in the zone"상태라고도 하는 "flow"상태에 들어섬으로써 가장 최상의 상태가 되어 일에 완벽히 집중하고 외부에 개의치 않게 됩니다. 완벽한 집중으로 시간 가는 것을 잊고 좋은 결과를 내게 됩니다. 이때에 바로 대부분의 생산적인 일들을 처리하게 됩니다. 작가, 프로그래머, 과학자 그리고 심지어 농구선수들까지도 "in the zone"상태가 있음을 이야기할 것입니다.

문제는 "zone"으로 들어가는 것이 쉽지 않다는 것입니다. 측정해보면, 최상의 생산성으로 일을 하기 위해서는 평균 15분이 걸립니다. 하지만 어떤 경우에는 피곤하고 이미 많은 일을 한 상태에서 "zone"상태에 들어가지 못하고 다른 일을 하거나 웹서핑이나 테트리스로 시간을 허비하게 될 수도 있습니다.

또다른 문제는 "zone"상태에서 빠져나가는 것이 매우 쉽다는 것입니다. 잡음, 전화소리, 점심식사, 잠시 스타벅스에 5분간 갔다오는 것 그리고 특히 동료에 의한 방해등에 의해 바로 "zone"에서 빠져나가게 됩니다. 동료가 1분이라는 짧은 시간 동안이라도 질문을 하여 "zone"상태에서 빠져나간다면 다시 되돌아가기 위해서 30분이 넘는 시간이 걸려 전체 효율에 치명적인 영향을 미칠 수 있습니다. 카페인 가득한 닷컴 회사들이 좋아하는 합숙소같은 곳에 옆의 마케팅 부서에서 계속해서 오는 전화에 대고 소리지르는 그런 시끄러운 환경이라면 계속된 방해로 지식 근로자들의 생산성은 추락하여 "zone"상태에 절대 이르지 못할 수도 있습니다.

프로그래머들에게 있어서 특히 어렵습니다. 생산성은 단기적인 기억력으로 한번에 얼마나 많은 작은 세부사항들을 다루느냐에 달려있습니다. 어떠한 방해도 이런 세부사항들을 잊어버리게 할 수 있습니다. 일을 다시 재개하면 그것들을 다시 기억하지 못하여 (사용하던 지역변수나 검색 알고리즘을 만들던 중에 어디에서 멈줬었는지등) 다시 찾아보게 되고, 이로 인해 다시 속도가 붙을때까지 느려지게 됩니다.

직관적으로 계산해보면 다음과 같습니다. 만일 프로그래머가 단 1분이라도 방해를 받아서(명백한 근거에 의해) 15분의 생산성을 날려버린다고 합시다. 철수와 영희 두 프로그래머가 낮은 칸막이로 주욱 늘어선(a standard Dilbert veal-fattening farm) 열린 사각 파티션 옆자리에 앉아 있다고 합시다. 영희가 strcpy함수의 유니코드 버젼 이름을 잊었습니다. 30초면 찾아볼 수 있겠지만, 철수한테 물어보면 15초가 걸립니다. 그래서 바로 옆에 앉아 있는 철수에게 묻습니다. 철수는 산만해지고 - 영희의 15초를 아끼기 위해 - 15분을 낭비하게 됩니다.

이번에는 벽과 문으로 나뉘어진 별도의 사무실로 가정을 합시다. 여전히 영희는 함수를 기억하지 못합니다. 다시 찾아보는 것으로 30초를 보낼 수 있을 것이고 옆 방에 있는 철수에게 물어보기 위해서 (일반적인 프로그래머의 평균 물리적인 건강상태를 봐서는 쉽지 않은) 일어나서 걷는 것을 포함한 45초를 보낼 수 있을 것입니다. 결국 찾아보는 것을 선택하여 30초를 보내게 되지만 철수의 15분을 벌어주게 됩니다. 대단하죠!

9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?

컴파일 되는 언어로 코드를 작성하는 것은 여전히 아무 PC에서 할 수 없는 것 중의 하나입니다. 컴파일을 하는데 몇초 이상 걸린다면 최상의 기종을 사용함으로써 시간을 절약할 수 있을 것입니다. 15초 이상 걸린다면 지루해서 그 시간동안 The Onion을 읽게 될 것이고 너무 재미있는 관계로 거기에 빠져 수시간의 생산성을 날려버릴 것입니다.

모니터 하나로 GUI코드를 디버깅한 것은 불가능하지는 않지만 고통스러운 작업입니다. GUI코드를 작성하고 있다면, 2대의 모니터로 훨씬 쉬운 작업을 할 수 있을 것입니다.

대개의 프로그래머들은 아이콘이나 툴바를 위해 비트맵을 수정해야하고 대부분의 프로그래머 역시 좋은 비트맵 에디터를 가지고 있지 않습니다. 마이크로소프트에서 기본적으로 제공하는 Paint 프로그램으로 비트맵을 수정하는 것은 웃긴 일이지만 대부분 이렇게 하고 있습니다.

필자의 가장 최근 직장에서 시스템 관리자가 계속해서 자동적으로 스팸을 보냈습니다. 이유인 즉슨 220MB이상의 하드드라이브를 사용하고 있다는 것이었습니다. 필자는 요즘 HD가격을 본다면 이 공간의 환산된 가격은 내가 이용하는 화장실 휴지보다 싸다는 것을 지적했습니다. 디렉토리를 정리하기 위해 10분을 허비하는 정도로도 큰 생산성 저하일 것입니다.

"최고의 개발팀은 절대 그들의 프로그래머들을 고문하지 않습니다!" 후진 제품으로 인한 작은 불편함이 쌓여서 프로그래머들이 불만에 찰 수도 있습니다. 그리고 그로 인한 불만에 찬 프로그래머는 비생산적인 프로그래머이기 쉬울 것입니다.

이런 것들을 모두 종합하면 프로그래머들은 최고/최신의 것들로 쉽게 매수된다는 뜻이 됩니다. 이는 높은 연봉을 주는 것보다는 훨씬 싼 방법일 것입니다!

10. 테스터들을 고용하고 있습니까?

팀이 최소한 2~3명의 프로그래머에게 테스팅만 전담하는 테스터가 할당되어 있지 않다면, 버그가 많은 제품을 출하하고 있거나 시간당 $100짜리 프로그래머에게 시간당 $30의 일을 시키는 낭비를 하고 있는 것입니다. 테스터를 고용하는 것이 낭비로 생각하는 것은 정말 잘못된 계산을 하고 있는 것이며, 많은 사람들이 이를 깨닫지 못하고 있는데에 놀랍니다.

이에 관해 더 자세히 알고자 한다면 Top Five (Wrong) Reasons You Don't Have Testers 를 읽으십시오.

11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?

마법사를 고용하는데 그의 마법을 보지 않고 고용하시겠습니까? 당연히 그렇지 않겠죠.

결혼식에 요리사를 고용하는데 요리사가 만든 요리의 맛도 모르고 고용하시겠습니까? 그렇지 않을것입니다.(역자주: 실제로 결혼식장 요리사의 맛을 보는 비유는 우리나라에 맞지 않을 것 같네요. 이 문구의 뜻만 이해하세요)

하지만 현실에서는 매일 인상적인 이력서나 면접에서 맘에 든 이유로 고용하는 일들이 일어납니다. 혹은 ("CreateDialog()와 DialogBox()의 차이점은 무엇입니까")등의 문서만 보면 알 수 있는 사소한 질문으로 채용하기도 합니다. 프로그래머를 채용하는데 있어서 중요한 것은 그런 사소한 것들을 얼마나 많이 외웠느냐가 아니고 코드를 잘 작성할 수 있느냐입니다. 혹은 "아하!"류의 질문으로 채용하기도 합니다. "아하!"류의 질문이란 답을 알면 간단하지만 모르는 경우에는 절대 맞출 수 없는 질문을 이야기합니다.

제발 이런 방식을 그만 두십시오. 면접때 무얼해도 상관없지만 반드시 코드를 작성하도록 해야합니다.(더 많은 것을 알고 싶다면 Guerrilla Guide to Interviewing를 읽으십시오)

12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?

무작위 사용성 테스트(hallway usability test)는 복도를 지나가는 다음 사람을 붙잡고 방금 짠 코드를 사용하게 하는 방식입니다. 5명에게 이 테스트를 한다면 95%의 사용성 문제에 대해 배울 수 있을 것입니다.

좋은 사용자 인터페이스 설계는 생각처럼 어려운 것이 아니고 사용자들이 당신의 제품을 구입하고 사용하게 하는데 있어서 절대적으로 중요합니다. 짧은 프로그래머 입문서로 UI 설계에 관해 필자가 쓴 무료 온라인 책을 읽어보실 수 있습니다.

하지만 사용자 인터페이스에서 제일 중요한 것은 많은 사람들에게 당신의 프로그램을 보여주면(5~6명이면 충분합니다) 제일 큰 문제점을 빠른 시간에 발견할 수 있다는 것입니다. Jakob Nielsen의 글에서 그 이유에 대한 설명을 찾을 수 있습니다. UI 설계 경험이 별로 없다고 하더라도 - 비용이 전혀 들지 않는 - 무작위 사용성 테스트를 한다면 당신의 UI는 훨씬 좋아질 것입니다.

Joel Test를 사용하는 4가지 방식

  1. 자신이 속한 소프트웨어 팀의 점수를 매기고 그것에 대해 언급할 수 있도록 결과에 대한 이유를 필자에게 알려주십시오.
  2. 프로그래머 팀의 관리자라면, 당신의 팀이 최대한 잘 운영될 수 있는지 확인할 수 있는 지표로 사용하십시오. 12점을 받기 시작하면 프로그래머들을 간섭없이 그냥 두고 비즈니스쪽 사람들이 그들을 간섭하지 못하게 하는데에 모든 시간을 할 수 있습니다.
  3. 프로그래머 일을 맡을지를 결정해야하는 상황이라면 그 팀의 친한 사람에게 이 테스트 결과가 어떤지를 물어보십시오. 결과 점수가 너무 낮다면 이를 고칠 수 있는 권한을 받을 것인지를 확인하십시오. 그렇지 않으면 불만과 스트레스에 빠질 것입니다.
  4. 프로그래밍 팀을 평가하여야 하는 투자자이거나 당신의 회사가 다른 소프트웨어 회사와 합병을 한다면 이 평가가 급한대로 괜찮은 지표가 될 것입니다.


이 기사는 영어로 The Joel Test: 12 Steps to Better Code 라는 이름의 기사가 원본입니다.
Posted by SB패밀리
델파이 객체지향프로그래밍을 위한 20가지 규칙
한의원 아저씨로부터 부탁이 있어서 번역을 하게 되었습니다. 번역이 자연스럽게 되면 좋겠는데 어떨지 모르겠네요.
저도 공부하는 거라 생각하고 시작하게 되었습니다.
읽어주셔서 감사합니다.


부분의 델파이 프로그래머들은 그들의 직접 작업을 하지 않고도 Visual Basic[Editor는 간단히 두려움을 떨쳐버려주지요...]처럼 개발환경을 사용하지요.
델파이는 강력한 VCL 구조와 제각기 델파이 어플리케이션에 객체지향 아키텍쳐의 근본을 두고 있습니다.
이 글에서 필자는 OOP 이론을 주장하려는 것이 아니라 여러분이 프로그램의 구조를 개선하도록 도움될 만한 몇가지 간단한 제안을 할까 합니다.
나열되는 규칙들은 여러분이 작성하는 어플리케이션의 실제 형태에 적용될 수도 안될 수도 있습니다. 그냥 필자가 하는 제안하는 규칙들을 기억해주시면 고맙지요. ^^
제가 제일 강조하는 원칙은 캡슐화인데요. 우리는 프로그램의 다른 부분에 영향을 주지 않고 차후에 코드를 변경할 수 있는 유연성과 내구성이 있는 클래스를 생성하길 바라고 있습니다.
단지 좋은 OOP의 유일한 척도는 아니라도, OOP의 기초라고 할 수 있습니다. 그래서 필자가 이 글에서 정말 OOP를 지나치게 강조하는데에는 몇가지 그럴싸한 이유가 있습니다.
마지막으로, 이러한 원칙들이 델파이 프로그래머에 의해 일상 생활에서 사용된다는 사실을 강조하기 위해서, 필자는 여러가지 규칙들이 컴포넌트의 개발에 똑같이 적용되고 있더라도 주로 폼 개발에 초점을 맞출려고 합니다.
컴포넌트를 작성하는 프로그래머는 특히 OOP와 클래스를 생각해야합니다. 때때로 컴포넌트를 사용하는 프로그래머는 OOP에 관해 잊고 있는데 이 기사가 회상시켜줄 수도 있겠죠.

Part 1: 폼은 곧 클래스다
프로그래머는 오브젝트로서 폼을 취급하죠. 사실, 폼은 클래스인데 말이죠. 여기서 차이점은 동일한 폼 클래스를 바탕으로 다중 폼 오브젝트를 가질 수 있다는 것이죠.
햇갈리는 것은 델파이는 여러분이 정의한 모든 폼 클래스를 기본적으로 글로벌 오브젝트를 생성한다는 것입니다.
이는 프로그래머를 아주 초보적인 것이고 나쁜 습관으로 빠뜨릴 수 있습니다.

Rule 1: 유닛 하나에 클래스 하나!
항상 기억하세요, 클래스의 private과 protected 부분은 단지, 다른 유닛에서 클래스와 프로시저에서는 숨겨진다는 것을 말입니다.
따라서 효과적인 캡슐화를 하려 한다면, 모든 클래스에 대해 각자 다른 유닛을 사용해야 한다는 것입니다.
다른 클래스에서 클래스를 상속하는 간단한 클래스에 대해서는, 실제로 공유 유닛을 사용할 수 있지만, 단지 클래스의 수를 제한한다면: 하나의 유닛에서 20개의 클래스의 복합적인 계층을 위치시키지 말았으면 하는 것이지요.
볼랜드에서 VCL소스 코드에 대량으로 공유 유닛을 작성했을지라도...
폼에 대해 생각하자면, 델파이는 단순히 '한 클래스에 한 유닛' 원칙을 고수하고 프로젝트에 폼이 아닌 클래스를 추가할 때는 새 유닛을 생성하고 있습니다.

Rule 2: 컴포넌트 명
폼이나 유닛에 의미있는 명명을 하는 것은 아주 중요한데요. 안타깝게도, 이 두 명칭은 AboutForm과 About.pas와 같이 이 두가지에 대해 유사한 이름을 주려해도 반드시 달라야 합니다.
또한 컴포넌트에 대한 적당한 명칭 사용도 중요한데요. 가장 일반적인 표기는 btnAdd 나 editName 과 같은 컴포넌트의 역할에 따라, 클래스 타입에 대해 소문자로 머리글자를 사용하는 것입니다.
이 스타일에 따라 실제로 많은 유사한 표기방법이 있는데요. 이 방법을 가장 좋은 방법이라고 할 수는 없겠지만 개인적인 취향이 있는거 아니겠습니까!

Rule 3: 이벤트 명
이벤트 핸들링 메소드에 적당한 명칭을 부여하는 것 또한 쉽게 생각할 일은 아니죠.
예를들어, Button1Click 이라는 컴포넌트명이 있다고 하구요. 메소드명이 버튼명에서 생성되는 것이라고 추측하겠지만, 컴포넌트명에 추가된 메소드명 보다는 메소드의 기능을 잘 설명하는 명칭이 더 나는 방법이라는 생각을 하게 됩니다.
예를들자면, btnAdd 버튼의 OnClick 이벤트는 AddToList라고 할 수도 있겠지요.
이 방법은 특히 클래스의 다른 메소드로부터 이벤트 핸들러를 호출할 때 판독성이 좋아지구요.
필자가 Actions를 사용하는 것이 더 좋다고 말하고 싶지만 같은 메소드를 다양한 이벤트나 다른 컴포넌트에 추가하는데 있어 개발자에게 도움이 됩니다.

Rule 4: 폼 메소드를 사용하자
폼이 클래스라면 그 코드는 메소드로 이루어집니다. 게다가 특별한 역할도 하고 다른 메소드로서도 호출가능한 이벤트 핸들러는 사용자 메소드를 폼 클래스에 추가하는게 종종 유용할게 먹힐 때가 있습니다.
여러분은 폼의 액션을 수행하고 상태를 액세스하는 메소드를 추가할 수도 있습니다. 말하자면, 폼의 컴포넌트를 다른 폼에서 직접 조작하는 것보다는 폼의 public 메소드를 사용하는 것이 더 낫다는 것이지요.

Rule 5: 폼 생성자를 추가하자
실시간에 생성된 두번째 폼은 디폴트로 있는 거 외에 특정 생성자를 작성할 수 있습니다( 상속된 폼 TComponent 클래스).
델파이 이전 버전과 호환이 필요없다면, 필자의 제안은 초기화 파라메터와 함께 Create 메소드를 오버로드(overload)하는 것입니다. 예제 1을 봅니다.



public constructor Create (Text: string); reintroduce; overload;

constructor TFormDialog.Create(Text: string);
begin
inherited Create (Application);

Edit1.Text := Text;
end;


예제 1


Rule 6: 전역 변수를 피하자
(유닛의 Interface 부분에 선언된) 전역 변수는 되도록 피하도록 합니다. 여기에 괜찮은 제안을 보여주겠습니다.
여러분들 폼에 여분의 데이터 저장공간이 필요하다면, private 필드들을 사용해 보세요.
이 경우에 각 폼 인스턴스는 데이터의 복사본을 가지게 되고, 폼 클래스의 여러 인스턴스들 중에서 공유된 데이터에 대한 유닛 변수들(유닛의 implementation 부분에 선언된)을 여러분이 사용하게 되는 겁니다.
여러분이 다른 타입의 폼들 사이에서 공유된 데이터가 필요하다면, 메인 폼이나 전역 개체에서 데이터를 놓고 데이터를 공유할수도 있고 데이터를 액세스하기 위해 메소드나 프로퍼티를 사용할 수도 있습니다.

Rule 7: TFrom1 에서는 Form1를 사용하지 말자
특정 오브젝트의 클래스의 메소드에서 특정 오브젝트를 참조하지 말아야 합니다. 바꾸어 말하면, TForm1 클래스의 메소드에서 Form1 을 참조하지 마라는 겁니다.
현재 오브젝트에 대한 참조가 필요하다면, Self 키워드를 사용하시면 됩니다. 직접 현재 오브젝트의 메소드와 데이터를 참조할 수 있기 때문에, 대부분의 경우 필요치 않다는 것을 십분 인지 하시기 바랍니다.
여러분이 이 규칙에 따르지 않는다고 봤을 때에는 폼의 여러 인스턴스를 생성할 때 문제 발생의 여지가 많습니다.

Rule 8: 다른 폼에서 Form1을 사용하지 말자
심지어는 다른 폼의 코드에서도 Form1 과 같은 전역 오브젝트에 대한 직접적인 참조를 피하는 것이 좋습니다.
다른 폼에 대한 참조를 로컬 변수나 private 필드로 선언하는게 바람직합니다.
예를들어, 프로그램의 메인폼이 다이얼로그 박스를 참조하는 private 필드를 가질 수 있습니다.
확실히, 이 규칙은 두번째 폼의 여러 이스턴스를 생성하는 것으로 계획한다면 필수적인 것입니다.
이것은 메인 폼의 한 필드에서 리스트를 갖고 있을 수 있고, 그렇지 않으면 전역적인 Screen 오브젝트의 Forms 배열를 사용할 수도 있는 것입니다.

Rule 9: Form1을 제거하자
실제로, 필자의 생각은 델파이에 의해 프로그램에 자동으로 추가된 전역 폼 오브젝트를 제거하는 것입니다.
이것은 단지(델파이에 의해 다시 추가된) 폼의 자동 생성을 불허한다면 가능합니다.
필자의 생각에 전역 폼 오브젝트를 제거한다는 것은 델파이 초보에게도 매우 유용합니다. 클래스와 전역 오브젝트 사이를 혼동하지 않는 초보에게 말이죠.
사실, 전역 오브젝트가 제거된 후, 어떤 참조가 있다면 에러를 초래하게 되겠죠.

Rule 10: 폼 프로퍼티를 추가하자
필자가 이미 언급한 것처럼 폼에 데이터가 필요하면 private 필드를 추가하면 됩니다. 다른 클래스에 대한 액세스가 필요하다면, 그 때는 프로퍼티를 폼에 추가하면 됩니다.
이러한 접근에 따라 여러분은 다른 폼이나 클래스의 코드를 변경하지 않고 그 폼과 데이터(사용자 인터페이스를 포함해서)의 코드를 변경하게 될 것입니다.

두번째 폼이나 다이알로그 박스 초기화를 위해서나 마지막 값을 얻기 위해 프로퍼티나 메소드를 사용할 수 있습니다.
초기화라는 것은 위에서 언급했듯이 생성자를 사용해서 수행할 수 있습니다.

Rule 11: 컴포넌트 프로퍼티를 보이자
여러분이 다른 폼의 상태를 액세스하기를 원할 때, 여러분은 그 컴포넌트를 직접 참조하지 않도록 해야합니다.
이 방법은 대부분의 변경에 대한 어플리케이션의 주요 부분중에 하나인 사용자 인터페이스에 다른 폼이나 클래스의 코드를 설정하는 것입니다.
더블어, 컴포넌트 프로퍼티로 맵된 프로퍼티를 선언합니다.  만약 사용자 인터페이스를 변경하고자 한다면, 다른 컴포넌트로 해당 컴포넌트를 대체하세요.
여러분들이 해야할 것은 프로퍼티와 관련된 Get, Set 메소드를 수정하구요. 컴포넌트를 참조할 모든 폼과 클래스의 소스코드를 체크나 수정하지 않아야 합니다. 예제 2를 볼까요.



private
function GetText: String;

procedure SetText(const Value: String);
public
property Text: String read GetText write SetText;

function TFormDialog.GetText: String;
begin
Result := Edit1.Text;
end;

procedure TFormDialog.SetText(const Value: String);
begin
Edit1.Text := Value;
end;


예제 2: 컴포넌트의 프로퍼티가 공개되도록 폼에 프로퍼티를 추가.


Rule 12: 프로퍼티 배열
폼안에 연속된 값을 처리할 필요가 있다면, 프로퍼티 배열을 선언하면 됩니다.
이런 경우에는 SpecialForm[3]을 작성해서 직접 값을 액세스 할 수 있도록 폼의 기본 프로퍼티 배열을 만들수 있다는 것은 폼에는 대단히 중요한 정보입니다.
예제 3에서는 프로퍼티 배열을 다루는 폼의 기본 배열 프로퍼티로서 listbox의 아이템을 어떻게 나타내는지 보여주고 있습니다.



type
TFormDialog = class(TForm)
private
ListItems: TListBox;

function GetItems(Index: Integer): string;
procedure SetItems(Index: Integer; const Value: string);

public
property
Items[Index: Integer]: string read GetItems write SetItems; default;
end;

function TFormDialog.GetItems(Index: Integer): string;
begin
if Index >= ListItems.Items.Count then
raise Exception.Create('TFormDialog: Out of Range');

Result := ListItems.Items [Index];
end;

procedure TFormDialog.SetItems(Index: Integer; const Value: string);
begin
if Index >= ListItems.Items.Count then
raise Exception.Create('TFormDialog: Out of Range');

ListItems.Items [Index] := Value;
end;


예제 3: 폼에 기본 프로퍼티 배열의 정의


Rule 13: 프로퍼티의 부과효과를 사용하자
전역 변수를 사용하는 대신, 프로퍼티의 장점중에 하나가 프로퍼티의 값을 읽거나 쓸 때 부과효과가 나타날 수 있다는 것을 알아두세요.
예를들면, 여러분이 폼에 직접 그리고, 다양한 프로퍼티의 값을 설정하고, 특별한 메소드를 호출하며, 한번에 여러 컴포넌트의 상태를 변경할 수 있다는 것인데 가능하다면 이벤트를 발생하는 것이죠.

Rule 14: 컴포넌트를 숨기자
필자는 캡슐화의 원칙을 따르지 않는 방식인 published 섹션에서 컴포넌트의 리스트를 포함하는 델파이 폼 때문에 OOP 추종자들이 불평하는 소리를 너무나 자주 들어왔습니다.
그들은 실제로 중요한 문제를 지적하고 있지만 그들의 대부분은 델파이를 재작성하지 않거나 언어를 변경하지 않고 해결책이 가까이에 있다는 것을 인지하지 못하는 것 같습니다.
델파이는 폼에 추가할 수 있는 컴포넌트 레퍼런스가 private 부분으로 이동할 수 있다는 것 입니다. 다른폼에서 액세스하지 못하도록 말이죠.
컴포넌트의 상태를 액세스 하도록 (규칙 11)컴포넌트 맵된 프로퍼티를 의무적으로 사용을 하게 하는 방법입니다.
델파이가 published 섹션에 컴포넌트를 위치하는건 이러한 필드가 *.DFM 파일로부터 생성된 컴포넌트를 설정하는 방법 때문이죠.
컴포넌트 명을 설정할 때 VCL은 자동으로 폼에 컴포넌트의 오브젝트를 그 레퍼런스에 추가합니다.
델파이가 이를 수행하기 위해 RTTI와 TObject 메소드를 사용하기 때문에 레퍼런스가 published 되는 이유이죠.
더욱 자세하게 살펴보고 싶다면 InsertComponent, RemoveComponent, 그리고 SetName에 의해 호출된 TComponent 클래스의 SetReference 메소드의 코드를 가진 예제 4를 참조하세요.
여러분이 이해를 했다면, published에서 private 섹션으로 컴포넌트 레퍼런스를 이동해서 이런 자동적인 작업을 벗어나게 됩니다.
이런한 문제를 해결하기 위해서 단순히 폼 OnCreate 이벤트 핸들러에 각 컴포넌트에 대해 아래와 같은 코드를 추가를 합니다.Edit1 := FindComponent(.Edit1.)As TEdit;
다음으로 해야할 일은 시스템에서 컴포넌트 클래스를 등록하는 것 입니다. RTTI 정보가 컴파일된 프로그램에 포함되고 시스템에서 이용될 수 있도록 말이죠.
모든 컴포넌트 클래스에 대해서 단지 한번이면 됩니다. private 섹션에 컴포넌트 레퍼런스 타입을 이동한다면 말이죠.
여러분은 이 작업이 필요하지 않더라도 RegisterClasses 메소드에 대한 추가적인 호출이 무해하기 때문에 이러한 호출을 추가할 수 있습니다.
RegisterCalsses 메소드는 흔히 폼을 다루는 유닛의 initialization 섹션에 추가되고 있습니다.
RegisterClasses([TEdit]);



procedure TComponent.SetReference(Enable: Boolean);
var
Field: ^TComponent;
begin
if FOwner <> nil then begin
Field := FOwner.FieldAddress(FName);

if Field <> nil then
if Enable then
Field^ := Self
else
Field^ := nil;
end;
end;


예제 4: owner 폼에서 컴포넌트가 그 참조를 가로채는 VCL 코드


Rule 15: OOP Form Wiard 
모든 폼의 모든 컴포넌트에 대해 위의 두가지 방법을 반복한다면 아주 지루하고 시간낭비가 아닐 수 없습니다.
이런 과중한(?) 부담을 피하기 위해서 필자는 작은 윈도우에서 프로그램에 추가할 수 있는 코드의 라인을 생성하는 간단한 wizard를 작성했습니다.
각 폼에 대해 두번의 Copy & Paste 작업을 할 필요가 있습니다.
 
Wizard는 적당한 위치에 자동으로 소스코드를 배치하지는 않습니다:
필자는 update 버전을 만들면서 필자의 웹사이트 (http://www.marcocantu.com)에 올려놓고 있습니다.

 

Part 2: 상속  
위의 규칙들이 클래스, 특별히 폼 클래스에 집중되어 있지만 이제부터는 상속과 비주얼 폼 상속에 관련된 간단한 제안과 팁들을 볼 수 있습니다.
 

Rule 16: 비주얼 폼 상속 
상속성이란 적당히 사용하면, 강력한 메카니즘입니다. 필자의 경험으로 비추어 볼 때, 이 가치는 프로젝트의 단위가 커질수록 상승합니다.
복잡한 프로그램에서 다형성과 함께 폼 그룹상에 작용하는 폼들 사이에 계층관계를 사용할 수 있습니다.
 
비주얼 폼 상속은 다양한 폼의 일반적인 작업의 공유가 가능하게 합니다: 메소드, 프로퍼티, 이벤트 핸들러, 컴포넌트 이벤트 핸들러 등.
 

Rule 17: Protected 데이터의 제한 
클래스 계층을 작성할 때, 어떤 프로그래머들은 private 필드들이 서브클래스에서 액세스 되지 않기 때문에 주로 protected 필드를 사용하는 경향이 있습니다.
필자는 이것이 나쁘다고 말하고 싶지는 않지만 캡슐화의 개념과는 상반되는 것입니다. protected 데이터의 구현은 모든 상속된 폼들에서 공유됩니다.
데이터의 오리지날 정의에서의 변경 같은 경우에도 모든 것을 업데이트 해야할지도 모르죠.
 
규칙 14의 컴포넌트 숨기기를 따른다면, 상속된 폼은 상위 클래스의 private 컴포넌트를 액세스 할 수 없다는 것을 명심하세요.
상속된 폼에서는 "Edit1.Text := ..;"와 같은 코드가 더이상 컴파일 되지 않습니다. 필자는 이러한 것이 매울 불편하지만, 적어도 이론상으로는 나쁘지 않다고 봅니다.
캡슐화에 대한 특권이 과하다면, 상위 폼에 protected 섹션에서 컴포넌트 레퍼런스를 선언하세요.
 

Rule 18: Protected 액세스 메소드 
private섹션에서 컴포넌트 레퍼런스를 배치하는게 더 좋고, 상위 클래스에 컴포넌트 프로퍼티를 액세스 함수를 추가하는 것도 좋지요.
이러한 액세스 함수는 단지 내부적으로 사용되고 클래스 인터페이스 부분이 아니면, protected로서 이들을 선언해야 하지요.
예를 들자면, 규칙 11에 서술된 GetText, SetText 폼 메소드는 protected되고 호출에 의해 edit text를 액세스할 수 있게 됩니다:SetText(..); 
실제로, 메소드가 프로퍼티로 맵되기 때문에, 우리는 단순히 아래와 같이 작성합니다:
Text := ..; 

Rule 19: Protected 가상 메소드 
유연한 계층을 위한 또 다른 키 포인트는 다형성을 갖는 외부 클래스로부터 호출할 수 있는 가상 메소드를 선언하는 것입니다.
이를 일반적인 접근법이라고 한다면, 다른 public 메소드로 호출된 protected 가상 메소드를 자주 볼 수는 없습니다.
이는 오브젝트의 작업을 수정하면서 상속된 클래스에서 가상 메소드를 조작할 수 있기에 중요한 테크닉이 됩니다. 

Rule 20: 프로퍼티를 위한 가상 메소드 
프로퍼티 액세스 메소드는 상속된 클래스가 프로퍼티를 재정의하지 않고 프로퍼티의 작업을 변경할 수 있도록 가상으로 선언될 수 있습니다.
이러한 접근법은 VCL에서는 거의 사용되지 않지만 매우 유연하고 강력합니다. 이를 구현하기 위해, 단순히 규칙 11의 Get, Set 메소드를 가상으로 선언하면 됩니다.
상위 폼은 예제 5 코드를 갖게 될 겁니다.  상속된 폼에서 여러분은 몇가지 기능추가로 가상 메소드 SetText를 override할 수 있습니다:

procedure TFromInherit.SetTetx(Const Value: String);
begin
inherited SetText (Value);

if Value = .. then
Button1.Enabled := False;
end;




type
TFormDialog = class(TForm)
procedure FormCreate(Sender: TObject);
private
Edit1: TEdit;
protected
function GetText:
String; virtual;
procedure SetText(const Value: String); virtual;
public
constructor Create (Text: string);
reintroduce; overload;
property Text: String read GetText write SetText;
end;

예제 5: 가상메소드로 구현된 프로퍼티의 폼 클래스.

 
The Code  
이 강좌에서 모든 코드는 이달의 디스크에 포함된 OOPDemo 예제 프로젝트에 있습니다. 두번째 폼(frm2 유닛)을 체크하고 상속된 폼(inherited unit)도 체크해보세요.
initialization 코드와 private 컴포넌트 레퍼런스로 동시에 조작된 생성자를 사용하기 위해 폼의 OldCreateOrder 프로퍼티를 설정해야 한다는 것을 명심하세요.
그렇지 않으면 폼 생성자(컴포넌트를 사용하는)에서 initialization 코드는 실제 컴포넌트에 레퍼런스로 연결하는 폼의 OnCreate 메소드 이전에 실행될 것입니다. 
디스크상에서 OOP Form Wizard라는 첫 작품의 컴파일된 팩키지를 볼 수 있습니다만 필자의 홈페이지에서 업데이트된 버전을 찾는게 훨씬 나을 것입니다.
 
Conclusion  
훌륭한 OOP 원칙에 따라 델파이로 프로그래밍은 필지가 강조한 규칙들의 명확함과는 동떨어져 있습니다.
규칙은 적당한 내용으로 적용되어야 하고 규칙에 따라 작업하는 다수의 프로그래머 사이에 어플리케이션의 크기가 성장하는 만큼 더 중요합니다.
작은 프로그램을 개발하는데 있어도 필자가 주장하는 규칙의 OOP의 원칙(무엇보다 캡슐화)을 기억한다는 것은 실제로 도움이 될 것 입니다. 
특정 기사가 될만큼 아주 복잡한 RTTI 이슈와 메모리 핸들링에 익숙하지 않았기 때문에 여러분이 배울 수 있는 다양한 규칙들이 있겠지요. 
필자의 결론은 필자가 강조했던 규칙들이 추가적 코드에 의하여 대가를 필요로 하는 것이죠: 더 유연하고 내구성있는 프로그램을 얻고자 지불해야하는 값어치 말입니다.
미래의 델파이 버전은 우리가 고생을 덜 하도록 도움을 주리라 믿습니다.


Marco Cantu는 Mastering Delphi Series, Delphi Developer's Handbook, 그리고 무료 온라인 북 Essential Pascal의 작가입니다. 그는 델파이 기초와 고급과정을 가르치고 있습니다.
더 자세한 사항은 그의 홈페이지 http://www.marcocantu.com 에서 확인하시길 바랍니다. 여러분은 그의 공개 뉴스그룹에서 그를 볼 수 있습니다: 상세한 정보는 그의 홈페이지를 보세요.

번역: 소백촌닭, 원문: Marco Cantu, Issue 47, Delphi Magazine

Posted by SB패밀리

그린컴퓨터 최중구님의 글입니다. http://greenpc.co.kr/programmer.htm
-----------------------------------------------------------------
프로그래머의 글
1) 글을 시작하면서

오늘 이 글을 통해 혼란한 국내 소프트웨어 개발(프로그래머) 직종을 이해할 수 있는 설명을 하고자 합니다. 더 나아가 프로그래머라는 직종을 이해하는 것을 시작으로 프로그래머의 길을 걷고자 하시는 많은 분들이 밟아 올라가야할 방향을 제시할 수 있기를 바라는 마음에서 이 글을 적어봅니다.

2) 프로그래머에 대한 아마추어적인 발상

최근들어 인터넷이 사회적인 이슈로 떠오르면서 자연히 소프트웨어 개발에 대한 관심이 증대되고, 자연히 프로그래머라는 직업을 갖고싶어 하는 사람들이 늘고 있습니다. 하지만 소프트웨어 개발에 대한 잘못된 시각때문에 전문 직종으로 분류되어야할 프로그래머가 일반 직종으로 분류되고 있는 기현상을 보이고 있는 점은 프로그래머가 되고자 노력하고 있는 한 사람으로서 가장 걱정되는 부분입니다.

프로그래머라는 직업을 의사라는 직종을 예로들어 비교를 해본다면, 의사가 되기 위해서는 의대의 정규과정을 이수한 후 국가공인 자격시험을 통해 인턴/레지던트/전문의 순서를 밟아야 합니다. 이 처럼 의사라는 직종은 분야도 확실하게 나뉘어져 있을뿐만 아니라 의사로서의 자질을 평가하는 제도적인 체계가 정확하게 잡혀있습니다. 하지만, 프로그래머라는 직종은 그렇지 못합니다. 전산과를 나온다고해서 프로그래머가 되는 것도 아니고, 대학을 나오지 않았다고 해서 프로그래머가 되지말라는 법도 없습니다. 정보처리 관련 국가공인 자격증을 갖고있다고 해서 프로그래머가 되는 것은 더더욱 아니고 분야 또한 정확하게 구분할 수 없는 것이 프로그래머라는 직종입니다.

이처럼 프로그래머에 관한 정확한 정의가 내려지지 못하고 있는 상황에서 사회적 분위기는 소프트웨어 인력시장에 있어 큰 혼란을 초래하고 있는 것이 사실입니다. 때문에 프로그램 공부를 시작하려는 많은 사람들에게 혼란을 주고 있는 것이라 생각되는군요. 분야와 개인의 노력여부에 따라 틀리겠지만, 단순히 학원에서 몇 개월 과정을 이수한 것이나 프로그램 몇가지를 개발해본 경력으로 자신을 프로그래머라 칭하고 또 인정하는 사회적인 분위기에는 문제가 있습니다. 저도 올해로 프로그램을 시작한지 15년째고 실무경력은 15년 이지만, 지금도 저 자신을 프로그래머라 부르기에는 부끄러운 점이 많습니다. 사실 프로그래머라는 직종은 전문직에 속하는 것입니다. 의사보다는 훨씬 못하겠지만 그에 못지 않게 오랜 기간동안 공부하고 경험을 쌓아야만 비로소 프로그래머가 될 수 있는 것인데, 프로그래머라는 직종을 보는 일반적인 시각은 너무 쉽게 생각하는 경향이 있지 않는가 하는 생각이 들 때가 많습니다.

3) 풍요속의 빈곤

이러한 잘못된 사회적 통념이 굳어져 가고 있는 우리나라의 프로그래머 인력시장의 구조를 살펴보면 그 문제점을 가장 단적으로 알 수 있습니다. 우리나라 소프트 업계의 인력시장의 구조는 초보자로 부터 시작해 고급자로 균형이 있게 올라가는 정상 피라미드와는 많은 차이가 있습니다. 초급에 해당하는 아래부분은 비정상적 포화상태를 띠고있는 반면에 중급자 및 고급자들은 거의 찾아보기 힘든 구조를 나타내고 있습니다.

이러한 현상은 프로그래머라는 직종에 단순한 흥미와 사회적 분위기에 휩쓸려 뛰어드는 사람들은 많지만, 체계적인 교육과 평가 방법의 부재 및 영세한 국내 소트웨어 업계의 투자부족으로 인하여 중급이상으로 발전하는 프로그래머 지망생이 없기 때문에 나타나는 현상으로 볼 수 있습니다.

이와는 별도로 외국기술과 객관적으로 비교해 봤을때 훨씬 뒤진 기술조차 공유하는 것을 꺼려하고 있다는 점 또한 국내 소프트웨어 업계의 발전을 저해하는 요소로 지적할 수 있습니다. 하루가 다르게 변모하고 있는 세계적인 소프트웨어 업계와 경쟁하려는 생각은 하지 않고 오히려 지금 갖고 있는 지금까지 해왔던 일들만 편하게 하려는 안일한 생각들은 물론이고 그 보잘것 없는 기술을 통해 기득권을 유지하려는 잘못된 생각이 가장 큰 문제점이라 할 수 있습니다.

이러한 비정상적 인력시장 구조 속에서 정말 필요로 하는 프로그래머를 찾기란 하늘의 별따기와도 같으리라는 점은 누가 봐도 자명한 사실입니다. 풍요속의 빈곤이라는 용어가 어울릴정도로 프로그래머로 일하려는 사람은 많은 반면 정말 실력있는 프로그래머는 손에 꼽는 현상이 나타나는 것입니다.

4) 프로그래머가 갖추어야할 자질

프로그래머가 되기 위해 갖추어야할 자질에는 여러가지가 있습니다. 그 모두가 천재적인 재능을 필요로 한다기 보다는 끊임없는 노력을 통해 얻어질 수 있는 것이라 할 수 있는 것들입니다.

첫째, 집요하고 꼼꼼해야 합니다.

프로그래머의 직업병이라고도 할 수 있는 집요함이 있어야 합니다. 문제점을 찾아내고 해결하기 위해서 집요하게 들러 붙어 있을 수 있는 근성이 필요합니다. 차분하고 꼼꼼하면서 끈질긴 성격을 가진 분들은 어디가나 성공하시겠지만 프로그래머에게는 필수조건이라고 할 수 있습니다. 차분한 성격은 타고나는 것도 있겠지만 훈련을 통해 개발될 수도 있는 것입니다. 예를 들면, 마인스위퍼를 한다던가~ ^^퍼즐등을 통해서 키워질 수 있겠죠.

둘째, 논리력이 뛰어나야 합니다.

프로그램의 거의 대부분을 차지하는 것은 조건판단, 분기, Loop문을 작성하는 것입니다. 논리력이 없이는 할 수 없는 일들입니다. 일반적으로 남성에 비해 여성이 논리력이 뒤진다는 속설이 있어서 그런지는 모르지만 이 점 때문에 여성 프로그래머가 많지 않다고들 합니다. 집요하면서도 꼼꼼하게 논리를 구축해야 Bug 없는 프로그램을 작성할 수 있다고 봐도 과언이 아닙니다. 논리력 또한 훈련을 통해서 개발될 수 있는 것이죠. 역시 마인스위퍼를 한다던가~ ^^ 논리학등을 공부하고 일상생활에서 논리적인 사고를 하기위해 노력을 함으로써 개발할 수 있겠죠. 전 세가지 다 했습니다.

셋째, 세상을 보는 관찰력과 추상력이 뛰어나야 합니다.

프로그램은 추상화를 기본으로 하고 있습니다. 실세계를 축소해 놓은 것이 프로그램이라고 말해도 과언이 아닐 정도록 현실과 밀접한 관계를 갖고 있는 것이 프로그램입니다. 때문에 관찰력과 추상력이 필요합니다. 실세계의 특징을 찾아내고 단순화 하고 추상화하는 과정은 프로그램의 설계부분에 들어가기 때문에 전체적인 성능을 좌우하는 중요한 요소로 작용하기 때문입니다. 관찰력과 추상력은 경험을 통해서 개발될 수 있을 겁니다. 꼼꼼한 성격도 한몫을 할 수 있겠죠.

이러한 기본 자질들은 상호보완적인 관계속에서 프로그래머의 능력 개발에 도움을 줄 수 있는 것들입니다. 이러한 자질만을 갖고 있다고 해서 프로그래머가 될 수 있는 것은 아닙니다. 기본적인 전산이론은 물론 기타 관련 이론에 대한 공부가 필수적입니다.


첫째, 전산개론

일종의 상식공부라고 할 수 있습니다. 전산의 변천사는 물론 전산의 폭넓은 분야를 아는 것이 지금의 자신의 위치를 알 수 있는 가장 중요한 방법이 되기 때문입니다.

둘째, Hardware의 구조 및 동작원리

프로그래머는 Hardware는 몰라도 된다는 식의 발상은 정확하게 틀린 말입니다.Software는 Hardware상에서 구동되는 것이기 때문에 Hardware의 구조가 어떻고 어떤 원리와 절차에 의해서 구동되는지에 관한 특성을 알지 못하면 Hardware에 맞는 최적화된 Program을 개발할 수 없기 때문입니다. Pentium 계열의 CPU 에서 Pipeline Optimize의 개념을 알지 못한다면 Speed 최적화를 할 수 없는 것과 마찬가지입니다. 고급 프로그래머가 되기 위해서는 결코 등한시 해서는 안되는 점임을 잊지 마시기 바랍니다.

셋째, OS 이론

모든 프로그램은 OS 환경가 제공하는 환경에서 구동되도록 되어 있습니다. HW와의 복잡한 일들을 모두 맞아서 처리해주는 것은 물론 기타 유용한 Service를 제공해주는 OS를 몰라서는 그 OS에서 구동되는 프로그램을 개발할 수가 없습니다. 보다 넓은 시야를 갖고 전체적인 그림을 그리기 위해서는 OS를 어떻게 만들 것인가에 관한 이론들을 아는 것이 중요합니다. OS도 만드는데 다른 프로그램을 왜 못 만들겠습니까?

넷째, 자료구조/알고리즘 이론

프로그램의 꽃이라 할 수 있는 기본 이론들입니다. 프로그램에서 가장 중요한 부분인 자료의 저장과 처리에 관한 방법론들을 정리해 놓은 이론들로서 반드시 거쳐야하는 난코스라고도 할 수 있습니다. 자료구조/알고리즘을 모른다면 단순 Coder도 못된다는 결론이 날정도로 프로그래머가 되기위한 가장 기본적인 조건입니다.

다섯째, 전산언어론

C/Pascal/Fortran 등의 언어가 없을때는 어떻게 프로그램을 했을까? 라는 질문에 대한 답을 던져줄 수 있는 이론들입니다. Assembler로 부터 4GL까지의 발전사를 알 수 있을 뿐 아니라 C/C++와 같은 언어를 어떻게 만들 것인가를 정리하는 이론들입니다. Compiler 를 어떻게 만들 것인가에 대해 고민해보신적 있습니까? Compiler를 만든다면 그 Compiler가 번역하는 언어는 자유자제를 넘어 신의 경지에 오를 수 있지 않겠습니까?

여섯째, 개발방법론

전산언어론과는 또 다른 개념의 이론들을 모아놓은 것으로써 소프트웨어를 생산에 공학개념을 도입하고자 하는 이론들입니다. 체계화된 방법론을 통해 소프트웨어 개발의 생산성을 높이고자 하는 목적을 갖는 이론들입니다. 생산성을 생각하지 못한다면 경쟁력을 갖지 못하는 것은 당연한 것 아니겠습니까?

일곱째, 전산언어

C/C++과 같은 언어의 문법을 배우는 단계입니다. 가장 처음 프로그래머가 되겠다고 마음 먹은 사람들이 가장 많이 만나는 첫번째 적수이지요. 하지만 전체적인 그림속에서 전산언어가 차지하는 비중은 제일 마지막에 속하고 있다는 점을 유념하시기 바랍니다. 어떤 언어를 사용하는가는 중요하지 않다는 점입니다. 언어는 도구일 뿐이지 목적이 아니라는 점을 다시한번 강조하고 싶군요.

위에 나열된 주제들은 대부분의 전산과 교과목에 포함되어 있는 내용들입니다. 모두 한학기 분량이지만 결코 한학기 안에 끝낼 수 있는 내용들이 아닙니다. 1년 동안 세가지를 끝낸다고 해도 2년이 넘는 시간이 필요하다는 단순계산이 나옵니다. 결코 만만한 일은 아니죠.

여덟째, 실무경험

위의 조건들을 갖춘 대부분의 사람들은 일반적으로 실무경험이 부존한 것이 현실입니다. 단순히 이론적인 것으로만 접근해서는 좋은 프로그램이 나올 수 없습니다. 프로그램의 최종 사용자는 고객입니다. 고객의 입장에서 만들어야 가장 좋은 프로그램이 될 수 있습니다. 고객이 되어 본 사람은 좋은 프로그램을 만들 수 있습니다. 왜냐하면 고객은 그 업무를 가장 잘 알기 때문입니다.

5) 기본위에 쌓여진 경험

2년 안에 위에서 나열한 기본들을 모두 마스터 한다고 해도 Coder로 인정받기란 쉬운 일이 아닙니다. 원론을 그대로 적용해 해결할 수 있는 문제는 하나도 없다는 것은 너무나도 당연한 사실입니다. 책 속의 이론이 내안의 경험으로 쌓일때 비로소 내것이 될 수 있는 것입니다.

지금의 저 또한 그 기본위에 경험을 쌓기 위해 노력중인 사람이라고 말씀드리고 싶습니다. 항상 따라가도 먼저 뛴 사람들은 저만큼 앞서 가고 있다는 걸 느낄때마다 프로그래머라는 직업이 얼마나 피곤한 직업인가를 새삼 깨닫고 있으니까 말입니다.

6) 글을 맺으며... 세상 밖으로...

장황하게 나마 프로그래머라는 직종에 대해 설명을 해보았습니다. 글을 읽다 짜증이나시지나 않았나 모르겠군요. 하지만 이것이 지금의 제가 보고 있는 국내 업계의 현실입니다. 물론 상황에 따라 부분적으로 틀릴 수도 있겠지만 큰틀에서 본다면 제 글에서 벗어나는 것이 없습니다.

그 것은 바로 얼마전까지 워드프로세서를 만들던 한 소프트웨어 업체가 국내 소프트웨어 업계를 대표했었다는 사실만 봐도 알 수 있습니다. 그 폐단은 지금에 와서 더더욱 커지고 있죠. 외국과의 자료교환이 불가능 하다는 결정적인 문제점을 남겨놓고 무책임하게도 사라져버리지 않았습니까? 한국의 빌게이츠라는 말이 창피할 정도로 몰락하고만 기업에서 한동안 일을 했던 경험이 이렇게 더 큰 분노를 만들고 있습니다.

기본을 무시하고 사상누각을 쌓았던 한국병이 이 소프트웨어 업계에도 어김없이 자리잡고 있다는 것을 왜 아무도 지적하지 않는지 모르겠습니다. 밴쳐라는 이름아래 개혁의 면죄부를 받고 있는 기업들이 지금도 많다는 것에 안타까울 뿐입니다.

눈을 한번 돌려보시죠. 어느 나라가 워드프로세서 업체를 자국의 소프트웨어 대표기업이라고 떠들어대는지를...

우리는 아직 멀었습니다
Posted by SB패밀리

출처 : http://kldp.org/node/71785

 

가는 소스가 고와야 오는 파일에 바이러스 없다.
잦은 Warning 에 Error 날줄 모른다.
영업은 상사 편이다.
디자이너는 프로그래머 편이다.
프린터 밑에 누워 소스 떨어지기만을 기다린다.
printf 도 디버깅에 쓸려면 에러난다.
에러 무서워서 코딩 못 할까
소스가 한 박스라도 코딩을 해야 프로그램이다.
코더도 타이핑하는 재주는 있다!!
길고 짧은 것은 strlen을 써봐야 안다.
소스도 먼저 코딩하는 놈이 낫다.
믿는 팀장에 발등 찍힌다.
개발실 청소 아줌마 삼 년에 디버깅 한다.
보기 좋은 코드가 디버깅 하기 좋다.
소스 잃고 백업장치 구입한다.
아니 코딩한 소스에 버그 날까?
안 되는 코더는 엔터를 쳐도 PC가 다운된다.
잘되면 프로그래머 탓, 못되면 시스템 탓.
야한 화일도 위아래가 있다.
하룻 프로그래머 정품단속반 무서울줄 모른다.
백업을 안하면 삼대가 내리 흉하다.

잘 키운 개발자 한명 열 코더 안부럽다...
멀쩡한 프로그램에 날 세그먼트폴트...
바늘 버그가 치명적 버그된다..
안에서 새는 메모리 밖에서도 샌다...
프로그램은 개발자가 짜고, 보너스는 영업이 받는다...
늦게 배운 코딩 날새는줄 모른다...
디버깅한번 으로 천버그 잡는다...
돌(완벽한) 코드도 생각해보고 컴파일하자...
경영다툼에 개발자등 터진다...
제 코드가 석자...
KLDP서 윈도우 찾기....
개발일정 시계는 거꾸로 매달아도 간다...등등...

다 된 코드에 기획 바꾸기

버그보고 놀란가슴 오타보고 놀란다.
코딩 전 마음 다르고, 코딩 후 마음 다르다.
제 코드 구린줄 모른다..
코드가 죽끓듯 하다..
환경이 좋아야 개발자가 모인다..
소스 놓고 main도 모른다..
악습코드 구제는 팀장도 못한다..
goto에 소스꼬인줄 모른다..
프로그래머 많으면 프로젝트 완성될날 없다.
개 같이 코딩해서 정승처럼 사표쓴다.
숙제밭에 굴러도 학교가 좋다.
코딩도 전에 컴파일한다..
컴파일 하자 컴 다운된다..
VC 대신 Vi..
개발자 간 빼먹기..
리펙토링도 단숨에 하랬다..
아는 코드도 다시봐라..
개발자 망신은 Copy&Paste가 시킨다..
짧은 코드가 더 아름답다..
천줄코드도 #include부터...
한 프로그램에 개발자 되랴..
사장도 버그날땐 온다..

선옵티마이징이 개발자 잡는다.
개발자 키워서 대기업 준다.
버그잡자고 빌드다 뽀갠다.
될성부른 코드는 들여쓰기부터 안다.
빌드 뽀갠 넘이 성낸다.
다된 프로젝트에 코 빠트리기.
개발자살이는 코딩 3년, 프로그래밍 3년, 파워포인트 3년
사표쓴다 사표쓴다 하면서 프로젝트 세개 한다.
같은 값이면 대기업 파견살이.
고와도 내 코드 미워도 내 코드.
코드 주고 뺨 맞는다.
코드 가는 데 버그 간다.
코드를 봐야 디버깅을 하지...
빌드 뽀갠 날 데모 하랜다.

발 없는 소스가 천리간다.
손은 삐뚤어 졌어도 코딩은 바로 해야한다.
소스 한줄로 천냥빚도 생긴다.
개발자 목에 usb 메모리 목걸이.
스파게티 코드 소스가 주석 안달린 소스 나무란다.
기능 많은 프로그램 버그잘날 없다.
3일에 짠 코드 80개월 간다.


저항 도둑이 오실로스코프 도둑 된다

"사표쓴다 사표쓴다 하면서 프로젝트 세개 한다.

스파게티 코드짜는 버릇 여든까지 간다..

크랙을 주라. 그러면 그는 내일 배고파 할것이다.
어떻게 크랙하지는 알려주라. 그러면 그는 다시는 배고파 하지 않을 것이다.

#if 0에 소스 걸레되는 줄 모른다.
hardcode로 눈가리고 출시한다.
먼저 커밋한 놈이 임자다.
무능한 팀장 구제는 사장도 못한다....

잘된 소스 하나 열 영업 사원 안부럽다

코드를 개발새발 쓰니 팀원들 실망하더라~ ( from Dynamic Duo 2nd [Double Dynamite] - 서커스 )

패턴모르고 오용말고,
패턴좋다고 남용말자.

설계 문서가 3G라도 코딩해야 프로그램이다.


잘되면 프로그래머 탓, 못되면 시스템 탓.
관리자 입니다.
후...
열 납니다.

잘 되면 영업 덕, 못 되면 프로그래머 탓...
(갑 과 을 입장차이와 영업 하시는 분으로부터 치이는.. 한 프로그래머가...)
후... 씁쓸한
후...
(갑 과 을.. 역시 치이는 한 관리자가...)

버그도 제말하면 뜬다.
소스를 열어야 버그를 잡는다.
작은 버그가 (찾기) 더 어렵다.

모든 회의는 퇴근 직전에 시작된다.
모든 시스템 트러블 역시 퇴근 직전에 벌어진다.

근무 10일, 야근 11일.

버그버그버그

아빠가 퇴근할때 버그버그버그~
엄마가 실행하면 버그버그버그~
만나면 속쓰려서 버그버그버그~
다시써도 또만나요 버그버그버그~
우리는 좌절둥이 버그버그버그칭구~
버그버그버그~
버그버그버그~~
버그버그버그~~~ 칭구~

...
....... 너 누구냐 .......
...


모니터 오른쪽 스크롤바 따라 2백줄~
외로운 점(*)하나 잘못된 포인터의 사용
그 어떤 사수가 아무리 괜찮다고 우겨도
이 버그는 결국 우리의 땀~~ ^^;;

첫 줄에 배부르랴?
너는 내 버그 (너는 내 운명)

코딩할 사람은 생각도 않는데 컴파일부터 한다.
빌드 깨먹고 스크린샷 내민다.
키보드는 두드려야 맛이다.
누워서 코딩하기.
잘 된 설계 무너지랴.
코딩도 식후경이다.
패드 위에 놓인 쥐
바쁜 컴퓨터에 클릭질 한다.
코더 나고 코드 났지 코드나고 코더났어!!!
스테이블 버전에도 버그 있다.
원수는 메신저에서도 만난다.
모니터도 때리면 꿈틀거린다.
비트 모아 테라.

내일 정전이 된다해도 나는 오늘 한 줄의 코드를 쓰겠다. - 스피노자
스스로 돌아봐서 에러가 없다면 천만인이 가로막아도 나는 컴파일하리라. - 맹자
나는 하루라도 코드를 쓰지 않으면 입안에 가시가 돋는다. - 안중근 의사
가장 커다란 에러는 컴파일의 순간에 도사린다. - 나폴레옹
나는 코딩한다, 고로 나는 존재한다. - 데카르트
대박 프로그램은 1%의 영감과 99%의 노가다로 이루어진다. - 에디슨

네 코드를 알라. - 소크라테스

디버거의 버그.

컴파일은 이미 시작되었다

켰노라 코딩했노라 팔았도다

저 프로젝트를 따면 내가 불쌍해지고
따지 않으면 회사가 불행해진다

- 시저 -


다 끝난 컴파일에 정전시키기 (다된 밥에 재 뿌리기)
개발은 못해줄망정 스펙은 늘리지 마라 (동냥은 못해줄 망정 쪽박은 깨지마라)

Posted by SB패밀리

이제부터는 프로그램을 다루다 만나게 되는 엉뚱한 대화상자와 낯선 이미지 화면들을 몽땅 '버그'로 치부하지 말자! 겉보기에 버그인 듯 싶지만 프로그래머들에 의해 고의적인 준비된 깜짝 파티, '이스터 에그'가 프로그램 이곳저곳 숨어 사용자와의 만남을 기다리고 있기 때문이다. 지루한 PC 작업에서 벗어나 프로그래머의 재치와 익살을 만끽할 수 있는 이스터 에그, 이제 몸소 찾아 즐기기로 하자.

본래 '이스터 에그(Easter egg)'는 크리스천들이 부활절에 나눠주는 삶은 달걀을 뜻한다. 그런데 가끔 장난기가 발동한 크리스천들은 삶은 달걀 대신 생달걀을 선물로 나눠주곤 했다. 삶은 달걀인 줄 알고 톡톡 깨 먹으려던 상대방에게 놀람 반, 웃음 반의 색다른 재미를 주기 위해서였다. 컴퓨터 프로그래머들도 같은 생각에서 이스터 에그를 제작하기 시작했다. 개발진의 이름을 담은 대화상자나 본인의 목소리를 심어놓거나, 지루한 프로그램 작업에서 해방될 작은 게임 프로그램을 넣어두는 식으로 말이다. 물론 사용자 중 열에 아홉은 이스터 에그의 작동법을 알아내지 못해 그 재미를 누리지 못한다. 하지만 프로그래머들은 마치 보물찾기 놀이처럼 이스터 에그들을 프로그램 곳곳에 숨겨두기 시작했고,아타리 2600 게임기에서 최초의 이스터 에그가 발견된 지난 1977년부터 사용자들의 '달걀' 사냥이 이어져 왔다.

그러나 프로그램 속에서 이스터 에그를 골라내기란 여간힘든 일이 아니다. 이스터 에그에도 조건이 있기 때문인데, 그 첫번째가 정상적인 기능이 아닌 숨겨진 기능이어야 한다는 점이다. 즉, 프로그램 설명서에 기재된 기능이면 안된다는 얘기다. 둘째, 이스터 에그를 꺼내는 과정이 동일하면 다른 PC에서도 같은 결과가 나와야 한다. 또한 프로그램의 버그가 아닌 프로그래머의 고의로 심어진 기능이어야 하고, PC 사용자의 작업과 프로그램의 기본 기능에 영향을 끼쳐서는 안 된다. 마지막으로 발견된 이스터 에그는 PC 사용자에게 입이 딱 벌어지는 즐거움을 선사해야한다.

그렇다면 이 모든 조건에 딱 들어맞는 이스터 에그들은 어떤 모습일까? 이제부터 내 PC에 다양한 형태로 숨어 있는 이스터 에그들의 비밀을 꺼내보기로 한다.

 

개발자 PR용 이스터 에그들

짧게는 6개월, 길게는 3년도 넘는 개발 기간 동안 온 힘을 쏟아부은 개발자들. 이들은 본인들을 소개하거나 간단한 메시지를 보내는 수단으로 이스터 에그를 적극 활용한다. 역으로 사용자들은 자신들이 사용하는 프로그램을 누가 개발했는지 궁금해하며 개발자들이 남겨놓은 이스터 에그를 애써 찾는다. 여기 개발자와 사용자의 만남의 장소가

Posted by SB패밀리
당신이 개발자라면 한 번 이상 생각해보자.
가능한 결론이 날 때까지...
나는 개발자로서 어떤 위치에 있고 사회는 어떤 위치를 원하고 있는지!



SI/SM 의 세계에서 개발자는 Coder < Programmer < Engineer < Architect < Consultant 로 성장하게 된다.

    물론 반드시 그렇지는 않지만, 의미적인 부분을 말하고자 하는 것이니 그것을 이해해주었으면 한다. 분류가 칼로 무 자르듯이 딱 떨어지지 않는 것은 당연한 것이다. 어떤 경우는 Engineer, Architect, Consultant 역할을 동시에 수행해야 하는 경우도 있다.

 

    1. Coder 란 코딩된 소스를 잘 이해하지 못하고 오려붙이기 하면서 단순히 소스를 만드는 사람을 의미한다. 어떠한 요구사항에 의해 프로그램을 만드는 것인지 알지 못하면 Coder 에 해당한다고 보면 된다.

   단순 작업에 해당하며, 고급 개발자도 때로는 이런 단순작업을 하기도 한다.

   Coder 는 고객을 만나지 않으며, PL 로부터 요청된 개발로직에 대해 Coding 업무를 수행한다.

 

    2. Programmer 란 기술적인 요구사항에 대해 스스로 그것을 처리할 수 있는 로직을 만들 수 있는 사람을 의미한다.

    프로그래머는 다양한 언어스킬을 가지고 있어야 하며, 때로는 소스 및 어플리케이션의 효율성을 높이기 위해 몇 개의 언어를 조합하여 사용할 수도 있어야 한다.

    또한, 프로그래머는 라이브러리 등 소스 수준의 것들을 조합하여 원하는 기능을 만들어내기도 한다. 프로그래머는 고객을 만나지 않으며, 기술적이지 않은 용어를 사용한 대화에 대해 익숙하지 않기 때문에 만난다고 하더라도 고객의 요구사항을 이해하지 못한다.

    또한, 자신의 의견을 고객에게 잘 인식시키지 못한다.

    단지, Coder 보다는 좀 더 쉽게 일을 줄 수 있고, 더 좋은 품질의 일은 하지만, 때때로 사람의 특성에 따라 반드시 Output 을 챙겨줘야 하는 경우가 있다.

 

    3. Engineer 는 프로그래밍에 대한 경험 뿐 아니라, 어플리케이션에 관계된 제반 제품(Product)에 대한 해박한 지식이 있어, 보다 완벽한 시스템을 구축하기 위해 이를 활용할 수 있는 사람을 의미한다.

    이 단계의 사람은 "Trouble Shooting"을 할 수 있다. 즉, 어플리케이션이 오작동하거나 에러를 낼 때, 오라클을 튜닝해야 할 지, 서버(H/W)를 튜닝해야 할 지, 웹로직을 튜닝해야 할 지를 알고 대처할 수 있는 사람들이다.

    엔지니어는 시스템의 전체적인 퍼포먼스와 조합을 위하여 부분적인 기능과 성능을 어떻게 해야할 지를 잘 아는 사람이다. 이는 프로그램에 대한 경험과 이해가 없으면 잘 해낼 수 없다.

   통상적으로 엔지니어란 전체적인 조화를 위해 시스템의 필수기능 이 외의 것을 튜닝하는 일을 한다.

   이 직능군의 사람이 없으면, 시스템 개발이 완료가 되더라도 부조화에 의해 시스템이 기존 Legacy 로부터 배척되는 현상이 발생된다.

   엔지니어는 고객 수준의 용어로 쉽게 대화할 수 있으며, 고객의 막연한 불만이 기술적으로는 어떻게 매칭될 수 있는지에 대한 경험을 가지고 있다.

   즉, 그들은 고객이 "웹이 이상해요." 라고 말하면, 어떻게 이상한지 잘 유도해서 묻고, DB나 소스, 아파치 등을 뒤져서 그 이상한 현상이 해결되도록 한다.

 

    4. Architect 란 하드웨어 제품군, 소프트웨어 제품군, 미들웨어 제품군, 데이터베이스 제품군까지에 대한 전반적인 이해를 바탕으로 업무특성에 맞게 어플리케이션을 중심으로 제품군을 배열할 수 있는 그림을 그릴 수 있는 사람을 말한다.

   이 사람들은 인터넷뱅킹처럼 실시간 트랜잭션 처리형(OLTP) 업무를 구현하는데 서버 한 두대를 넣는 구성을 절대 그리지 않는다.

   아키텍트는 고객과 잘 대화하는 수준을 넘어 고객의 사업 및 실무를 잘 이해한다. 즉, 업무가 월말에 한꺼번에 처리되는지, 일정산이 반드시 필요한지 등에 대한 이해를 바탕으로 시스템을 구축한다.

   고객의 업무를 듣고 트래픽 패턴을 분석하고, 소프트웨어 아키텍쳐,어플리케이션 아키텍쳐, 하드웨어 아키텍쳐를 결정하고 구현한다.

   이 직능군의 사람이 없으면, 시스템이 월초마다 이유없이 다운되기도 하거나, HW 증설을 해도 트래픽이 소화되지 않은 현상들이 일어난다. 또한, 용량확장 시 쉽게 이를 구현할 수 없다.

 

    5. Consultant 란 고객이 상상하는 비즈니스 모델을 현실화하기 위해 업무프로세스에서부터 시스템까지 모든 그림을 그려주고 이를 실행시켜주는 사람을 말한다.

    IT 와 함께 고려된 업무프로세스는 전통적인 산업기반에서는 존재하지 않는 것이어서, 언제나 새로 만들어지거나 업그레이드 되어야 하는데, 그들은 고객의 사업을 잘 이해하여 그 사업의 틀에서 서비스를 구현해주는 사람이다.

 만일 당신이 소규모의 온라인 쇼핑몰을 운영하고 싶다면, 컨설턴트는 회계관리에서부터 납품관리 및 홈페이지관리 등 모든 것을 상담하고 거기에 필요한 시스템을 납품하며, 잘 운영하고 있는지 사후관리도 해준다.

   컨설턴트는 "돈이 있는 사람들"을 위해 꿈을 현실로 만들어주는 사람들이다.

   비록 사업 결과에 대해서 책임지지는 않지만, 사업가가 성공할 수 있도록 파트너로서의 역할을 충실히 수행해 낸다. 컨설턴트가 없으면 고객은 처음부터 끝까지 스스로 알아서 해야 하며, 위험한 시기에도 쉽게 외부의 도움을 얻을 수 없다.

Posted by SB패밀리