JoelOnSoftWare 요약 1

들어가기

JoelOnSoftWare책은 개발뿐만 아니라 팀 관리, 회사 운영에 대해 생각해볼 만한 내용이 많다. 처음에 나와을 때는 현실과 동떨어져 보이는 내용도 많았지만, 최근에는 현실화되는 부분도 있다. 이런 부분을 여러분과 공유하고 싶어서 간단하게 정리해보았다. 저의 주관에 의해 축약하고 정리했기 때문에 왜곡될 수도 있습니다. 자세한 내용은 책을 참고하세요. 개인적 의견은 {...}으로 표시했습니다.

작성자: ospace114@empal.com, http://ospace.tistory.com/

뛰어난 개발자 뽑기

뛰어난 개발자를 뽑기 위해서 개발자가 보이는 기술 컨퍼런스나, 좋은 인턴제도로 좋은 신입 개발자를 모이게하거나 커뮤니티를 만들어 뛰어난 개발자를 오게한다.

개발자 대하는 지침

개발자에게 개인 사무실, 좋은 근무환경, 취미를 지원, 독립적이고 정치가 없는 인간관계을 제공한다.

개발자가 임금에 불평한다면 일을 더 이상 좋아하지 않는다는 신호

개발자도 자신 임금에 대해서 이야기 하면 회사 일이 재미 없다는 말이고 돈이라도 줘야 일을한다는 의미이다.
돈이 너무 적게 줘도 문제이지만 회사 일이 재미 없는게 더 문제이다.
{ 반대로 말하면 회사 일이 재미없는 경우 돈이라도 많이 줘야한다.}

세가지 관리 방법

명령과 통제 관리 방법

극단적인 상황에 쓰이는 방식으로 개발자는 싫어하는 방법이다.

ECON 101 관리 방법

돈으로 사람을 평가하는 방법이다. 돈을 보고 일하기 때문에 성과 측정에 대한 꼼수가 등장하고 속임수가 늘어날 수 있다.

일체감 관리방법

직원에게 동기부여를 하고 일체감을 가지며 강하고 끈끈한 조직을 만든다. 회사에 대한 충성심과 헌신적인 동료애가 만들어진다.

팍스디지타 문화

자기 영역을 책임지고 일하고 담당자가 최종결정권을 가진다. 즉, 각 개발자의 영역을 침해할 수 없다.
{보통 상급 관리자나 직책이 높은 개발자에 의해서 결정해서 지시를 내리는 경우가 많다.}

쉐년 엔트로피 비트(통신 수학이론)

동전은 한번, 주사위는 세번만 물어보면 맞힐 수 있다. 전체 표본 공간에서 어떤 사상에 대해 모르는 정도에 대한 정보량이라고 정의하고 이를 엔트로피라고 한다. 발생할 확률P 라고 할때 정보량 S를 나타내는 공식은 다음과 같다.

$$ S = -\log_2 P $$

예를 들어 주사위는 확률P가 1/6이므로 2.5846이 된다. 이를 비트로 표현하면 3이 된다.

{ 통신 수학이론 또는 정보이론으로 요즘 인공지능으로 인해 중요해졌다. 몰라도 개발은 할 수 있다.}

기업 내 부품용 소프트웨어는 "웬만큼 괜찮게 만들면" 더 이상 공들이지 않음.

리팩토링하고 개선을 지속해야 한다.
{맞는 말이다. 그러나 잘동작하는 코드는 손을 대지말라고 한다. 아무도 책임지고 싶지 않기 때문이다.}

전산학과 대학생에게 무료로 드리는 7가지 조언

1. 글쓰기를 배우세요
2. C 언어를 배우세요
3. 미시경제학을 배우세요
4. 지루하다고 전산학이 아닌 과목을 우습게 여기지 마세요
5. 프로그래밍 심화 과정을 수강하세요
6. 모든 일자리가 인도로 가버린다는 걱정은 그만하세요
7. 무엇을 하든 훌륭한 회사에서 인턴을 체험하세요

{ 능력이 뛰어날 수록 좋지요. ㅡ.ㅡ;}

애플과 마이크로소프트 글꼴 방식 중에

심미안을 수련하지 않은 사람은 친숙한 것을 선택한다.
{ 사람들은 익숙한 것을 좋아한다. 그러나 심미안은 가져야한다고 생각한다.}

사람들에게 팔려고 만든 소프트웨어, 상품 소프트웨어는 밀리미터 싸움입니다.

비즈니스는 전쟁이다. 매일매일 조금씩 전진하고 투쟁해야 비로소 승리를 쟁취할 수 있다.
사소한 일을 찾으려면 비판 정신이 필요하고 모든 사물에서 오류를 찾아내는 마음가짐을 가져야 한다.

두 가지 실수를 저질렀습니다.

1. 과도한 자기 확신으로 바로 코딩
2. 여럿이 소프트웨어 설계 회의

{ 1번은 저도 가끔씩했던 실수이다. 2번은 설계다운 회의를 해본적이 거의 없다. 관행적으로 이전에 검증된...}

Barry Schwartz는

선택의 역설: 더 많은 선택을 제공할 수록 선택이 더 어려워한다.
{ 상품의 역설?: 사람은 복잡한 것 싫어하지만, 내 물건은 많은 기능이 있어야 좋아한다. 대부분 쓰지 않지만...}

정말 위대한 일을 해주는 애플리케이션은 사용성이 엉망이라도 계속 잘 사용함.

아무리 사용성이 좋아도 원하는 기능이 없으면 사용 안한다.
{ 맞는 말이다. 그러나 기술적으로 뛰어나지 않으면 기능들은 비슷해서 사용성이 중요할 때가 많다.}

사회 구성원을 회생해서 자기 이익을 얻으려고

비난하는 사람은 있지만 아무런 조치를 취하지 않으면 공유지 비극이 발생한다.

공유지 비극

세금은 내기 싫어하면서 복지 같은 공공재는 최대로 누리고 싶어 합니다. 공공재에 적절한 가치를 부여하지 않으면 공공재가 공유지로 전략하게 된다.

혼자서도 유용하게 쓸수 있어야 다른 사람도 관심을 가지며 같이 쓰기 시작함.

{ 당연하지!}

제 3지대는 잠식 당하고 있다.

다양한 커뮤니티로 제 3지대를 창조하려고 한다. 커뮤니티마다 개성이 있다. 이는 소프트웨어 철학을 반영한다.

유즈넷은 글타래가 몇 달이 이어지면서 길을 잃어버림.

IRC는 대화명이나 대화방에 소유가 없기에 실제 대화보다 대화방 쟁탈전에 시간을 소모한다.

아무리 사소한 소프트웨어 동작 방식이라도 커뮤니티가 발전하고, 행동하고, 느껴지는 방식에 큰 영향을 미친다.

제일 늦게 등록한 토론 주제가 맨 먼저 나오는 방식. 이 방식은 두 가지 장점.

• 첫째, 토론 주제들이 새롭게 바뀌기에 토론방이 좀 더 재미있어진다.
• 둘째, 토론 주제들의 순서가 안정성 있게 유지된다.

경고를 읽은 사람 가운데

99.9%는 잘못된 행동을 하지않을 사람이고, 나머지는 막가는 사람으로 이런 경고는 무시한다.

특정 글을 삭제한 이유를 공개석상에서 논하는 일은 금지되어야 합니다.

{ 자신글이 삭제된 사람은 억울해서 가만히 있을까? }

선호도로 삭제여부를 선택

이 기능을 좋아하지 않는 세가지 이유

• UI가 복잡
• 중요한 결정을 너무 쉽게 결정하는 상황을 조장
• 중간에 누락된 글로 전체 흐름을 놓쳐버릴 수 있음

세상에는 한 짝으로 존재해야 제대로 동작하는 것들이 굉장히 많습니다.

서로 짝을 이루려면 반드시 합의가 필요하고 없으면 한 짝이 될 수 밖에 없다.

각각 하나씩 존재하는 일 대 일 관계

ex. 휴대용 MP3재생기와 헤드폰, 그리고 연결 금속 잭

새로운 헤드폰을 만들고 새로운 연결부를 만들었고 새로운 기능에 반응을 안하면 실패한다.
그렇다고 여러 연결을 고려한 다대다 연결부를 만든다면 테스트는...
그렇기에 표준을 만들고 테스트해야하는데 새로운 표준이 맞는지 테스트할 방법이 없다. 각자 알아서 해야하는데 제대로 동작하는지에 대한 보장은...

진짜 문제는 따로 있습니다.

표준이 하나만 있어도 비교해서 테스트할 방법이 없기에 이 표준은 진짜 표준이 아니다. 이 표준은 이상일 뿐이고, 오역이 난무하는 세계이다. 이 표준이 다대다 환경에서 구세주가 될수는 없다.

Jon Postel 신중하게 내보내고 넉넉하게 받아들여라라는 강건성 원칙을 발표.

강건성 원칙은 명세를 완벽하게 준수하지 않아도 의도만 파악할 수 있다면 받아주어야한다는 주장이다. 이로 인해 숨어있는 오류 가능성이 높아진다. 강건성 원칙은 초기 인터넷에 익숙하지 않은 엔지니어를 위한 원칙으로 너무 엄격했다면 지금의 웹은 없었다.

2004년에 마이크로소프트에서는 이상주의자가 실용주의자에게 승리를 거둔덕분에 비스타는 끔찍한 평가를 받고 팔리지 않았습니다.

이상주의자는 보통 원칙 면에서 옳고, 실용주의자는 보통 실천 면에서 옳습니다.

왜 오피스 파일 형식이 이토록 믿을 수 없을 만큼 복잡해졌나.

• 최적화된 결과로 아주 오래된 컴퓨터에서도 빨리 처리된다
• 기존 윈도우 라이브러리를 이용한다
• OLE 복합 문서를 광범위하게 지원한다
• 상호운영성을 고려해서 설계된 형식이 아니다
• 오피스 프로그램의 복잡성을 모두 반영한다
• 지금까지 진화해 온 오피스의 역사를 반영한다

오피스에게 어려운일 시키세요.

기존 워드 파일을 PDF로 변환하는 웹 어플리케이션이 필요하면, 워드 2007에 내장된 PDF 내보내기 변환기로 PDF로 저장하는 VBA 스크립트 작성해서 IIS에 올라간 ASP나 ASP.NET에서 이를 호출한다. 처음에는 워드 뜰 때까지 몇초 걸리지만, 이후는 COM 서브 시스템이 워드를 메모리에 올려놓기에 속도 문제는 없다.

이번에는 웹 어플리케이션이 리눅스로 돌아가는 경우는 윈도우 서버를 구매하고 워드를 설치하고 ASP.NET과 C#으로 웹 서비스 만들고 수평확장이 필요하다면 워드 설치된 윈도우 서버 여러 대를 사서 앞에 로드밸런서를 붙인다. { 리눅스와 별게로 윈도우 서버를 왜 구매하지?}

직접 오피스 파일을 만든다면 단순한 형식으로 파일 생성한다. 엑셀은 CSV를 사용하고 계산식이 필요하다면 로터스 1-2-3 WK1 형식 사용하고 이진 파일 형식이 필요하다면 엑셀 3.0(오래된)을 구해서 필요한 기능을 담긴 워크시트를 만들어서 저장한다. 그리고, 파일 명세를 분석해서 필요한 레코드 알아내서 조작한다. 워드 문서는 HTML를 사용하고 화려한 장식이 필요하다면 RTF 문서가 최선이다.

{ CSV는 유용하지만 나머지는 거의 사용해보지 않아서 잘 모르겠다.}

싫지만 꼭 해결해야 하는 아픈 문제이고 지속 가능한 경쟁우위를 확보하는 확실한 방법입니다.

싫지만 꼭 해결해야하는 아픈 문제를 더 많이 풀면 풀수록 사업과 시장 점유율이 성장한다.

우주인 아키텍트

상상을 뛰어 넘는 유토피아를 만든다는 호언장담, 자화자찬, 현실 개념 상실, 그런데도 사람들은 환호하고 언론들은 열광한다.

Microsoft Live Mesh

모든 것의 미래, 클라우드로 이동하고 모든 정보를 어느 곳에서도 접근할 수 있다. 이미 웝하드 같은 서비스 제공하고 있고, 고객이 요구하는 기능도 아니다.

개발자는 일정 세우기를 싫어합니다.

어럽게 세운 일정은 현실성은 없다. 이전 작업으로 부터 일정 예측하고 실제 소요시간을 예측하는 수집 증거기반 일정 세우기 Evidence-Based Sched(EBS)로 일정 수립하고 전체 일정 조정한다.

작업 쪼개기

일주일 단위가 아닌 시간 단위로 측정해서 작은 작업 단위(16시간 이내)로 일정 수립한다. 그렇지 않다면 무엇을 할지 생각하지 않다는 의미이며 해야 할 일을 까맣게 잊고 말 것이다.

소요시간 추적

예상하지 못한 상황으로 얼마나 많은 추가 시간이 걸리는지 기록한다. 초기 예측시간을 실제 소요 시간으로 나눠서 속도를 계산한다. 개발 속도를 측정해서 속도 이력을 수집한다.

대부분 일관된 속도를 보이며, 형편없는 개발자는 들쭉날쭉하고, 전설 개발자는 1이다. 이력이 없는 개발자는 제대로 일을 하지 않는다고 가정한다.
{ 대부분은 일정이 정해지고 그에 맞게 속도를 조절(?)해야 한다. 개발속도 이력? 뭐지?}

미래 시뮬레이션

예측 시간을 모두 더해서 출시일을 결정할 수 있지만, EBS는 몬테카를로 방법으로 다양한 가능성을 시뮬레이션 하고 각 시나리오별 출시일 분포도를 그리면 특정일에 제품 출시 확률이 계산된다.

• 속도 이력에서 무작위 추출 속도(V)를 초기 예측 시간(E)로 나눠서 시나리오 얻는다.
• 같은 방식으로 시뮬레이션을 100번 반복해서 시나리오를 100개 만든다.
• 각 시나리오 가능성은 1%로 개발자가 자신 작업을 마칠 가능성을 알아 낼 수 있다.
• 모든 개발자에 대해 이 작업 수행하면 특정일에 제품 출시 가능성을 알 수 있다.

평균 수준 개발자는 편차가 크지 않고 0.6(예) 근방에 수렴하기 떄문에 비슷한 시나리오 얻을 가능성이 크다.

예상치 못한 작업으로 돌발상황이 생긴다면?

방해받은 시간을 포함해서 끝까지 걸린 시간을 그냥 기록한다. 나중에 비슷한 다른 작업 시간과 비교되면서 방해받는 사실이 드러난다. 방해받는 사실을 적든 적지 않든 EBS 결과는 똑같다.

프로젝트 능동 관리

낮은 우선순위 기능을 잘라낸다면 일정이 얼마나 줄어드는지 쉽게 파악할 수 있고, 개발자별 작업 완료 예정일 분포를 살펴볼 수 있으며, 서로 간에 조절도 가능하다.

범위 잘라내기

EBS는 작업 시작시 상세한 수준까지 계획을 수립하면 잘 작동한다. 예상치 못한 기능을 추가하는 경우 정상적이라면 숨겨놓았던 여유를 할당하면 되고 여유가 없다면 출시일은 늦춰진다. 출시일이 하루 이상 늦어진다면 작업을 끝내는 속도보다 작업이 추가되는 속도가 더 빠르다.

그일을 할 개발자만이 제대로 예측할 수 있습니다.

버그를 발견하면 즉시 바로잡고, 디버깅에 걸린 시간을 원래 소요 시간에 반영한다. 초기 예측 시간을 줄이라고 관리자가 집적대지 못하게 하세요. 일정은 장난감 블록 상자로 블럭이 넘치면 더 큰 일정 상자를 준비하거나 블럭을 빼야 합니다.

참고

[1] 조엘 스폴스키 지음/이해일 옮김, JoelOnSoftWare, 2009.10.23