[의보 민영화의 위험성]
의료보험 민영화의 위험성을 잘 모르시는 분이 있으시다면,
미국 마이클 무어 감독의 다큐멘터리 영화 "SICKO(식코)" 를 보시길 권합니다.
인터넷으로 대략적인 내용을 보셔도 됩니다. 아주 충격적이죠.

우리나라에서 17만원쯤 하는 맹장수술이, 미국에서는 1500 만원입니다.
우리나라 2~4만원 하는 위내시경은, 미국에서 170만원,
단순 X-ray 사진 찍는데에도 몇십만원을 줘야 합니다.
우리나라에선 감기 치료받는데 3천원~8천원이죠. 미국가면 15만원입니다.
하루 병원입원비가 100만원 쯤 나옵니다. 미국에서 입원했다 도망가는 환자가 널렸죠.
구급 엠뷸란스 요청하는데도 돈이 듭니다. 30만원요.

안믿기시면, 보험없이 미국에서 한번 아파보시면 됩니다.
영화에서는 손가락 하나 잘린거 봉합하는데 1억 2000 만원을 요구하더군요.
보험없다고 말이죠.
그럼 보험이 있으면 될것같죠?
미국 1달 보험료는 4인 가족 120~150만원 수준입니다.
국민들 아프고 병걸린걸 등처먹고 사는 미국이죠.
1970년 닉슨 부통령의 어이없는 민영화 추진으로, 미국의 아픈 국민들은 망국의 길을 걸었고
그 이후 30년이 지나도록 민영화를 공영화로 되돌리지 못했습니다.
왜냐하면 천문학적 액수의 수입을 벌어들이는 의료보험 업계가 정치권에 엄청난 액수의
로비 자금을 대면서 국영화를 철저하게 막고 있기 때문이죠.
힐러리, 오바마의 큰 대선 공약 중 하나가 바로 의료보험 국영화입니다.

우린 거꾸로 가고 있죠.

또하나, 미국 신용불량자의 50% 가 의료비 때문에 생깁니다.
미국 의료보험 회사는 어떠한 핑계를 찾아서라도
(가입자의 문서상의 실수나, 과거 병력, 지불 거부 사례, 정 안되면 소송을 해서라도)
어떻게든 환자에게 보험금을 지급하지 않으면,
보험금 지급을 막은 직원에게 고액의 연봉과 승진을 보장하곤 합니다.
회사로서는 큰 돈이 들어가는 일을 막았거든요.
말그대로 환자야 죽든지 말든지, 사실 회사 입장에선 돈버는게 목적인거죠.
안그렇습니까?

이번에 MBC 에서 보도한 대로 질병정보를 의료업계에 제공하게 되면?
아예 아픈 전력이 있거나, 당뇨가 있거나, 뚱뚱하거나, 홀쭉하거나,
집안 내력에 환자가 있었거나 하는 국민들은 민영화된 의료보험에 가입조차 못하게 되죠.
그냥 아프면 집에서 자가치료하는 세상이 오는 겁니다.
손가락 잘린거 치료하는데 6000 만원 이라면 병원 가실수 있겠습니까?

총선이 코앞인데 국민적 지탄을 받을만한 의료보험 폐지 정책을
MB는 대체 뭘믿고 이런 걸을 추진하는걸까? 라는 생각이 드는 분이 있으시다면
제가 한말씀 더 드리겠습니다.

이명박은 이미 알고 있는 겁니다.
국민들이 워낙에 어리석고 멍청해서
이런 정책을 수행하든 말든, 총선에선 승리하고도 남는다는 사실을요.

왜냐고요?
이미 본인이 겪어봤기 때문입니다.

이명박이 "시장주의" 를 하겠다고 했습니다.
그러자 시장통 상인들이 환호성을 올리고 만세를 불렀죠.
같은 "시장" 이란 글자니까 시장통 상인 위한 정책 아니냐는 거였죠.
참 웃어야할지, 울어야 할지..... 대한민국의 슬픈 코메디 아닙니까?
이명박이 시장주의를 하면 자영업자나 시장통 상인들은 쫄닥 망한다는 걸
그네들은 모르는 거죠.
살아남는 것은 대형 유통업체(이마트) 일 뿐인데.
이명박 본인이나 측근들도 얼마나 콧웃음을 치며 웃었겠습니까.
국민들이 멍청해서 내가 정치 해먹고 산다고 말이죠.

또한 이명박은 친기업을 하겠다고도 했죠.
그런데 생각해 보십시오.
기업 입장에서 제일 좋은게 뭐겠습니까?
월급쟁이들 봉급 깎는게 제일 좋죠.
맘에 안드는놈 마음대로 해고하게 해주면 제일 좋죠.
봉급은 동결하고, 근로시간은 늘여주면 좋죠.
기업이 내는 세금은 최대한 줄여주고, 부족한 세수는 국민들한테 걷는다고 하면 제일 좋아하죠.
안그렇습니까?
그런데 우리나라 월급쟁이들이 이명박을 지지하는 참 웃지못할일이 벌어졌다는 겁니다.

(벌써 부가가치세를 10% 에서 12.5% 로 올리겠다는 이명박 정부의 계획이
MBN 뉴스에서 보도됐었습니다. 법인세 인하, 10억 고가주택 양도세 인하, 종부세 폐지(예정),
골프 등의 특별소득세 삭감등의 감세정책으로 인해 부족해진 세수를 서민에게서 걷겠단 거죠.)

또한 이명박은 보수주의, 신자유주의를 한다고도 했죠. (시장주의와 같은 뜻입니다.)
이는 복지주의 축소를 가장 기본적인 경제 정책으로 내세우죠.
또한 사회양극화를 격차가 벌어지는 것을 너무나도 당연하게 여깁니다.
그런데도 서민들은 이명박을 지지하며 환호성을 올리고 있으니...
우리나라 근로자의 1/3 이 비정규직인데, 비정규직 더 늘리자는 신자유주의 하는 사람을
대통령으로 앉혀주는 국민들이니 얼마나 멍청합니까.

그러니까 이명박은 아는 거죠.
의료보험 민영화 해도 총선에는 전혀 영향이 없다는 걸 말이죠.
그래서 대놓고 이런 정책을 추진하는 겁니다.
이렇게 국민들이 난리 치는 것도 인터넷 뿐입니다.

원래 수많은 이명박의 비리 때문에 이명박이 대통령 되어서는 안되는것이 아니라,
수많은 이명박의 서민 죽이기 정책 때문에 이명박이 대통령이 되어서는 안되는 거였죠.

식코 동영상 보기
http://cafe.naver.com/ftakiller.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=3057

독일은 2차대전 패전 직전,
마지막 궁지에 몰리자 노인들을 징집해서 전쟁에 내보내 죽게 했다고 한다.
그걸 국민돌격대라고 불렀는데, 독일에 그것에 대해 항의하는 양심있는 장교도 있었다고 한다.
이에 대해 히틀러의 선전부장 괴벨스는 이렇게 말했다고 한다.

"우리는 아무 잘못이 없소.
우리는 언제나 우리가 하겠다고 하는 걸 해 왔어.
그리고 단 한번도 그걸 숨긴 적이 없어.
그걸 알면서도 우리를 지지한 것은 바로 저자들(독일 국민들)이야."
(목을 칼로 자르는 시늉을 하며)

"그리고 이제 그들이 그 댓가를 치룰 차례지."




원문출처 ; http://board.knowhow.or.kr/board/view.php?start=80&data_id=33924&mode=&search_target=&search_word=
프로그래머를 위한 성공적인 이력서 쓰기 10계명

Justin James ( TechRepublic )   2007/12/11  

노련한 구직자들이 알고 있는 것처럼 일자리를 찾는 첫 번째 단계는 면접을 할 기회를 만들어 주는 이력서를 쓰는 것이다. 불행하게도 전통적인 이력서 작성 규칙 중에는 소프트웨어 개발 산업계에서 잘 먹히지 않는 것이 다소 있다. 다음은 면접을 할 가능성을 높여주는 프로그래머 이력서를 쓰는 10가지 요령이다.


참고: 이 정보는 PDF 다운로드 파일로도 제공된다. 이 주제에 대한 더 자세한 내용은 "프로그래머 구직 이력서 쓰기(Write a resume that will land you a programming job)"라는 블로그 게시물을 참조하라.

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

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

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

http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39164091,00.htm

1. 정보모음에 소홀히 하지 말고 설명서를 읽음에 게을리 하지 말지어다. 오늘 필요 없는 정보는 내일 필요하리라. 가장 가치 있고도 저렴한 지식은 책 속에 있느니라. 서점과 동료의 책꽂이에 무엇이 꽂혀 있는지 때때로 살피어라. 무심코 흘렸던 종이 한 장이 너의 근심을 풀어 주었으리라. 설명서는 충분히, 꼼꼼히 읽을지어다. 모든 의문은 설명서를 안 보는데서 생기니라. 그렇더라도 모두 다 읽을 필요는 없느니라. 많은 정보가 능사는 아니니라. 정보의 가치를 찾는 법부터 배우라. 세상엔 너무나 많은 자료와 정보가 넘쳐난다.

알알이 모두 끌어 모을 생각을 하기 보단 정보를 하나로 꿰는 법부터 먼저 배우는것이 너의 근심에서 쉽게 벋어나게 하는 방법이 되리라. 일을 시작하기전에 필요한 정보를 꼼꼼히 먼저 챙기는 법부터 배워라. 너희는 먼저 개발 의뢰서를 꼼꼼히 읽을지어다. 만약 개발 의뢰서가 없다면 발주자에게 요구할 지어다. 개발 의뢰서 없는 프로그램은 존재하지 않으니라.


2. 너의 PC가 안전하다고 믿지 말지어다. 5분 후에 정전이 되고 내일 너의 하드가 맛이 가리라. 그러니 너의 소중한 소스코드는 정기적으로 여러 군데에 단계별로 백업해 두어라. PC는 평상시엔 안전하다. 그런 실수를 저지르는것은 네자신이거나 아니면 외부적인 요인에 기인한다. 항상 백업을 철저히 해두며 백업에 백업까지도 챙겨두라.그리고 백업을 했다면 리스트를 작성하라. 쓸데없는 백업은 백해 무익하나니 리스트를 항상 유지할 지어다. 너희는 노트를 옆에 끼고 살 지어다. 노트는 너의 생명이며, 너희가 기억하지 못하는 모든것을 상기시켜 줄지어다.


3. 변하는 수를 다룰 때에는 늘 조심할지어다. 정수가 절대로 그 한계를 넘지 않으리라 가정하는 것은 어리석음이라. 127 ,-128 ,255 ,32767 ,-32768 ,65535, 이 숫자들을 너의 골수에 새기어라. 0.0은 0이 아니니 실수는 원래부터 결코 정밀하지 않느니라. 부호 없는 것과 있는 것을 어울리거나 정수끼리 나눌 때에는 늘 조심하여라. 변수는 프로그램의 근원, 프로그램을 작성할때 가장 유의 할것이 바로 변수의 이름 짓기니라. 이름보고도 성격을 알 수 있게 해두라. 그러나 변수는 성질이 드러우니 변수에 성격을 부여할때는 조심스럽게 할지어다. 너희는 코딩하기 이전에 계획을 할 지어다. 이는 프로그래머가 코더가 아닌 것이니라.


4. 무슨 일을 반복시킬 때에는 처음과 끝에 유의할지어다. 너의 컴퓨터는 1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈 때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라. 프로그램을 작성할땐 계산, 판단, 비교를 그 모든걸 컴에게 되도록 맡기지말라. 네손으로 미리 계산하고 그 결과를 사용하는 방법이 최선이니라. 컴퓨터는 의지가 없나니 네가 잘못하든 잘하든 아무런 상관이 없느라. 너희는 머리가 악세사리가 아님을 기억하고 항상 생각하고 항상 노트에 적을 지어다.


5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다. 절대로 없어 나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너를 괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보고, if를 쓸때에는 else 부터 생각하라. 논리적인 오류는 성급함에서 생기나니 처음엔 항상 원리와 원칙을 지키라. 생각은 네가 하라 그리고 그 결과를 컴에게 시켜라. IF를 쓰기전에 규칙을 세우라. 먼저 IF의 결과에대한 규칙부터 세우고 따져라. 그리고 논리적인 계산을 IF문장안에서 하지 말라. 하나의 IF문장속에 수많은 논리연산은 버그의 원인이니라. 어느 정도의 프로그램에 대한 윤곽이 잡히면 프로토 타입을 만들지어다. 프로토타입은 프로그램에 대한 시뮬레이션이며 발주자의 요구를 빨리 수용 하는 방법이니라.

6. 함수 안에서 매개 변수값은 결코 믿지 말지어다. 지금 그 매개 변수가 결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수 값이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는 경우는 예외이니라. 함수도 하나의 독립적인 프로그램이란것을 잊지말며, 네가 프로그램을 작성할땐 모든 함수가 돼도록이면 독립적으로 돌아가도록 할지어다. 함수의 매계변수는 항상 그옆에 작은 컴맨트와 초기화를 잊지말라. 처음부터 속도문제를 생각하지 말라. 모든 루틴을 최적화 할순 없다. 전체 프로그램중에 단 20%가 전체 실행시간에 80%를 점유한다. 프로토 타입에대한 발주자의 의견을 꼼꼼히 들을 지어다. 이는 발주자에 대한 신뢰도의 척도니라.

7. 오류를 알려 주는 기능은 있는 대로 모두 활용할지어다. 컴파일러의 경고는 모두 켜두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든 메모리 할당은 조만간 실패할 것이라. 컴파일러가 모든 경고기능을 동원해도 알려주지 않는 것은 많다. 중요한 건 오류가 생기기전에 규칙을 지켰는지 생각하라. 파일의 입출력과 메모리의 항당은 항상 쌍으로 생각해서 열었다면 닫아주고 활당받았다면 돌 려주라. 프로그램의 매인턴앤스를 게을리하지 말지어다. 이는 프로그램 만드는 일 보다 중요한 일이니라.

8. 한 번의 수정과 재컴파일만으로 연관된 모든 것이 저절로, 강제로 바뀌도록 할지어다. 어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지 않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트를 완전하게 검사하도록 하고 언젠가 손대야 하거나 따라서 변해야 하는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라. 이미 완벽한 루틴을 손대지 말라. 프로그램이 무너지는 가장 첫번째이유는 도미노 현상 때문이나니 한번의 수정과 재컴파일로 쓸데없는것을 손대게 하지 말라. 컴파일러가 매개변수 리스트를 챙기지 말게 하라. 프로그램에 들어가기 전엔 미리 함수명과 매개변수 리스트를 만들어라. 너희는 프로그램의 도큐멘트를 만드는일에 게으르지말지어다. 이는 사용자가 너의 프로그램에 대해서는 바보이기 때문이니라.


9. 사용자가 알아서 잘 써 주리라고 희망하지 말지어다. 너의 프로그램은 항상 바보만이 쓰느니라. 사용 설명서를 쓸 때에는 결코 빠뜨리지 말아라. 빠뜨린 만큼 사용자는 너를 괴롭힐 것이니라. 사용자는 나쁜놈이다. 쓸데없는짓을 잘한다. 무식하다. 인간성도 더럽다. 대부분이 바보며 가끔 똑똑한 사람도 있는데 그 놈은 더 하다.모든것을 설명하지 말며 온갇기능을 가진 하나의 프로그램을 작성하려 들지 말라. 많은 기능이 필요한 프로그램은 나누어서 작게 따로 만들어주라. 너희는 공부하는데 게으르지 말지어다. 자고나면 새로운 하드웨어와 새로운 소프트 웨어가 나오기 때문이니라.


10. 매사에 겸손하고 항상 남을 생각할지어다. 가장 완벽한 프로그램일수록 가장 완벽하게 숨은 벌레가 있느니라. 네가 이 세상 최고의 프로그래머라고 떠들며 자만할 때, 옆집 곳간에서는 훨씬 더 뛰어난 것을 묵묵히 만들고 있느니라. 아무렴 프로그래밍은 혼자 잘나서 할 게 아니니, 너로 인해 다른 사람들도 더불어 잘 되면 그 얼마나 좋은 것이냐. 프로그래머는 논리적으 로 생각하여야 하지만 프로그램은 비논리적으로 작성하라. 프로그래머가 경지에 들면 누가 누가 잘하는지 알수가 없는 법, 또한 프로그래머로서의 '무지'에 대해서 잊지마라. 프로그래머의 '무지'는 생략하고, 선택하고, 단순화시키고, 명백하게하는 것이니라. 항상 새로운 아이디어와 새로운 생각으로 무장하라. 그리고 나누라 나누는곳에 기쁨있나니 너희는 모든 프로그램에 대해서 위의 프로시줘를 따를 지니라.
내용출처 : [기타] 인터넷 : http://www.beginninglinux.wo.to/

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 라는 이름의 기사가 원본입니다.



사용자 요구사항을 맞추는건 참 어렵다...

[이미지 출처] 인터넷에서 구함.. 저작권에 문제가 되면 알려 주시면 출처 밝히겠습니다.
[개발자의 마음 가짐세]

항상 프로그래밍에 대해서 열린 마음(Open Mind)을 가져라. 새로운 아이디어를 거부하는 것은, 개발 능력 발전에 매우 유해한 행위이다.

자만심을 죽여라. 자만심은 어느 정도 경력이 있는 고참 개발자에게 가장 나쁜 것이다. 자만심은 자기 파괴적이며, 팀 이익을 위배한다. 당신이 어떤 개발 능력을 가지고 있던 간에, 당신보다 우수하지는 못할지라도, 당신만큼 뛰어난 다른 개발자들이 여럿 있다는 사실을 명심하라. 그런 개발자들은 자신만의 특수한 기술을 가지고 있지만, 당신의 개발 실력에 찬사를 표시할 것이다. 만일 당신이 자만심을 고수한다면, 다른 팀원(혹은 다른 개발자)들이 형편없다고 격하시키면서 그 자만심을 유지하려 할 것이다. 특히 당신이 팀장(Team Leader)이라면 더욱 그러할 것이다.

자만심이 강한 팀장은, 대부분, 팀원(혹은 다른 개발자)들을 교육하기를 꺼려하고, 팀원(Member)들을 도우려 하는데에도 인색하다. 단지 팀원들은 모조리 바보다라고 생각한다. 실력이 뛰어난 팀원들을 자신의 경쟁상대로만 간주하고, 거리를 멀리 하려 한다. 모든 팀에는 어느 정도 이런 유형의 행위가 발생한다. 팀장과 팀원간의 이런 특성을 깨닫는 것이, 좋은 팀을 만드는 첫걸음이다.

만일 그러하지 않았다면 다음과 같은 목표를 세워라.

1. 나의 팀을 더 뛰어나게 만들어라. 팀원들이 일을 잘하면, 결국 나도 잘하는 것이다.(팀장으로서의 능력이 뛰어남을 인정받게 되는 것이다)

2. 고참의 정도나 입사 기간이 아니라, 개발자들을 공로(성과)로 경쟁하게 하라.

[동료 코드 리뷰(Peer Review)]

동료들의 코드를 정기적으로 리뷰하라. 다른 팀원들이 당신의 코드를 리뷰하게 하는 것 뿐만 아니라, 당신 또한 다른 팀원의 코드를 리뷰해야 한다.

다른 사람의 코드를 봄(review)으로 해서, 더 나은 코딩 방법을 자주 찾을 수 있을 것이다. 당신이 비록 고참의 위치에 있다해도, 다른 사람들의 코드를 보는 것은, 다른 방법을 찾아내는 것만큼이나 유용하다.

다른 사람의 코드를 보는 것을 필수적으로 행하라. 종종 다른 사람의 시야가 당신이 잊은 무엇을 찾을 수 있으며, 다른 방법을 제시할 수 있고, 실수를 찾을 수도 있다. 때로 당신은 특별한 작업에 시달려서 매우 침체될 수 있으며, 이 때문에 다른 대안을 간과하는 경우가 발생한다.

그 작업과 거리가 먼 사람이 코드를 리뷰함으로써, 문제를 단순화하고 더 빠르고 좋은 방법을 찾을 수 있는 경우가 자주 있다.(이 말은 때로는 다른 사람의 시야가 나보다 더 해결책을 잘 찾아낼수도 있다는 것이다. 바둑이나 장기에서, 실제 대전자보다 관전하는 사람이 훈수를 더 잘 한다는 말과 비슷한 의미이다).

고참 개발자는 다른 사람에게, 심지어 신참 개발자에게라도, 자신의 코드 보여주기를 습관화할 필요가 있다. 다음과 같은 두가지 이유 때문에 그러하다.

1. 진행중인 작업과 다소 거리가 있는 다른 사람을 위해 코드 리뷰를 위해서
2. 코드 리뷰어 교육을 위해서

결국 모든 코드 리뷰어들은 팀원들이기 때문이다. 당신이 팀원들을 더 잘 교육할 수록, 당신 자신의 일에 더 몰두할 수 있으며, 더욱 고차원적인 일을 할 수 있는 여유가 생길 것이다.

[항상 배울게 있다]

매우 경력이 화려하고 뛰어난 개발자라해도, 다른 사람에게서 뭔가 배울 것이 항상 있다. 나는 모든 것을 다 알고 있다 혹은 나는 어떤 다른 개발자보다도 뛰어나다고 스스로 단정을 내려버리는 것 만큼, 당신의 경력과 개인적 발전에 저해되는 행위는 없을 것이다.

+ Recent posts

티스토리 툴바