웹 자유주의를 위해 다 같이 힘써요~

간만에 인문과학책을 읽어봅니다. 평소 책 읽은 시간이 많지 않거니와, 그런 시간을 쪼개서 인문과학 서적을 본다는 것은 더더욱 어려운 것이 현실입니다. 그래서 설날 다소 긴 연휴 기간 동안 이 책을 읽을 수 있었습니다.

저는 "리영희"라는 분에 대해 잘 몰랐지만, 이 책이 몇 년전 상당한 반향을 일으키며 여러 매체에 소개된 터라 언젠가는 읽어야지 다짐만했었습니다. 하지만, 이 분에 제가 아는 바는 별로 없어서 이 책을 읽는데 조금 주저했습니다.

이 분의 일대기 자체가 하나의 역사라는 생각이 들만큼 한국의 현대사의 여러 고비마다 항상 그 중심에 서 있었습니다. 때로는 언론인으로 학자로서 독재에 저항하고 폭력에 저항하였습니다.

저는 비교적 평온한 시기에 대학을 다녀서 사실 정말 치열했던 민주화 항쟁에서도 저 만큼 비껴있었습니다. 그리고 김대중,노무현 정부를 지나면서 우리의 민주주의가 많이 성숙했다고 생각해왔습니다. 다시 한나라당이 정권을 잡더라도 시대의 흐름을 거스를 수 없다고 생각했으나, 이러한 생각은 몇 달도 되지 않아 깨지고 말았지요.

그 원인을 책속에서 찾아보면, 해방 이후 민족 스스로가 과거에 대한 반성 없었고, 친일 세력이 다시 반공과 친미로 무장하여  지배세력으로 굴림하면서 우매한 국민들을 기만해왔다는 점입니다. 리영희 선생께서는 그 틀을 깨기 위해 펜을 들었고 이 정도까지 민주화가 발전되기 까지 그 분이 큰 역할을 했다는 사실을 뒤늦게 알게 되었습니다.

이 분처럼 내 분야에서 정말 치열하게 살아왔는지, 그리고 나름 지식인(?)으로 무엇을 해왔는지 되돌아 보았습니다. 물론 저는 인문학자도 저널리스트도 아닙니다. 하지만 누구나 자신의 위치에서 맡은 역사적 소임은 있는 것 같습니다. 그 역할의 크기는 그 사람의 역량에 따라 조금씩 다르겠지만, 최소한 방관 만은 말아야겠습니다.

Ron Patton저, 소프트웨어테스팅 2판, 정보문화사(SAMS)

이 책은 이론적인 부분 보다는 저자의 실제적인 경험, 특히 Microsoft에서 경험한 국제화, 호환성, 사용성 테스팅에 관해서 잘 소개해 놓았습니다.

몇 가지를 기억나는 내용을 추려보면 다음과 같습니다.

우선, 저자가 경험한 소프트웨어 테스팅의 몇가지 특성이 눈에 띄었습니다.

• 살충제 내성 : 같은 테스터가 여러번 테스트를 진행하다 보면 관성에 빠져 일부 결함은 찾지 못한다는 이야기입니다. 여러 사람이 다양한 방법으로 테스트하면 테스트 범위를 넓혀 살충제 내성 문제를 해결할 수 있습니다.

• 버그가 많을 수록 잠재 버그도 많다.

• 소프트웨어 테스터는 아무나 하는 것이 아니다.

소프트웨어 개발 단계 가운데, 테스트가 가장 어렵다고 합니다. 얼마나 어느 정도 해야할지 가늠하기 힘들며 누구도 결함이 없다고 보장할 수 없기 때문입니다. 그래서 결함에 대한 통계적 자료를 축적하는 것이 중요합니다. 동일 프로세스로 여러 소프트웨어를 개발하다 보면 어느 정도 테스트하고 결함이 어느 정도 일때, 제품을 출시할 수 있을 지 지표를 통해 판단할 수 있기 때문입니다.
그리고 책 앞부분에 소프트웨어 테스팅 때문에 발생한 오류 사례를 소개하는데, 생각보다 심각한 오류가 많았습니다. 1999년에 있었던 화상 탐사선의 추락사건 부터 패트리엇미사일(patriot missile)의 발사 실패로 인한 인명손실 등 작고 많은 사건들이 있었습니다. 펜티엄 부동소수 문제도 빠뜨릴 수 없군요.

저도 그 옛날 설치 프로그램이 잘못만들어서 많은 윈도3.1 시스템을 망가뜨린적이 있습니다. 사실 이 문제는 Visual Basic 4.0에 포함된 인스톨러 버그로 인한 문제였지만, 하필 최종 설치본을 테스트 안해보고 넘긴 저의 책임이기도 합니다. 당시 저는 학생이였고 아르바이트한 것이라서 단지 돈을 못받았을 뿐 큰 책임을 지지는 않았지만 의뢰한 회사는 적지 않은 피해를 입었을 것입니다.

소프트웨어 테스팅, 때로는 사람의 목숨도 좌우할 수 있을 만큼 중요한 것이니 소홀히 하지 맙시다.

단순하게 살아라
로타 J. 자이베르트 외 지음, 유혜자 옮김 / 김영사
나의 점수 : ★★★

이 책은 복잡한 우리의 삶을 다소나마 단순하게 만들어주는 여러가지 정보를 준다. 오래된 습관을 바로 바꾸기는 힘들겠지만 조금씩 개선해 나간다면 내 주의를 감싸고 있는 쓸모없는 모든 것들을 과감하게 정리할 수 있지 않을까 생각해 본다.

책 내용 중 몇가지 기억에 남길만한 문구를 정리해보았다. 이런 자기개발류 서적은 사실 아래와 같은 문구가 바로 핵심이고 실천해야할 지침이기도 하다.

이런것은 모두 버려라

일 잘하는 법, 마이크로소프트에서 배운다
줄리 빅 지음, 김동헌 옮김 / 한언출판사
나의 점수 : ★★★

원제: All I really need to know in business I Learned at Microsoft

마이크로소프트는 세계 최고의 소프트웨어 회사입니다. 한창 오피스 전쟁이 일어나고 있을 때, 이곳에서 일한 저자가 쓴 글인데, 재밌고 유익합니다. 요즘 우리나라에는 삼성관련 책이 많이 나와있는데, 사실 그다지 체험적이지 않고 삼성이라는 이름을 빌린 듯한 책이 많은데, 이 책은 MS에서 일어나는 사소한 일들도 많이 소개되어 있습니다. 아쉬운 것은 출판된지 거의 10년이 다되서 이미 마이크로소프트도 많이 변해 있기 때문에 책에 있는 내용대로 지금의 현실을 이해한다는 것은 다소 무리가 있습니다. 하여간 어떤 회사에서 일하던지 도움이 될만한 이야기들을 제목만 뽑아 봤습니다.

=전문가만이 살길이다=
예상 답변을 미리 준비하자
업무에 관한 한 모든 것을 속속들이 알아두자
경쟁사를 치밀하게 분석하자

= 효과적으로 일하자=
현명하게 일하라 오래 앉아 있는 것이 능사는 아니다
잘 모르겠습니만 곧 알아보겠습니다.
우기지 말고 웃겨라! 그리고 웃어라
휴식으로 뇌를 재부팅하라
새로운 아이디어는 예상치 못한 곳에서 나오기도 한다
약속을 지킬 수 없다면 다른 사람의 도움을 요청하라

칭찬의 마력, 한 마디의 칭찬이 인생을 바꾼다
집요하게 파고들면 신뢰를 얻는다
메모를 잘 활용하자

여러 책이나 기사를 보다보면 MS 직원들도 야근을 많이 하는 것을 확인할 수 있습니다. 이 책에서도 "일주일에 이틀은 칼퇴근 하자"라고 지은이가 제안할 정도이니까요. 세상을 앞서 나간다는 것은 때론 피곤한 것이도 합니다. 물론 성취감이 있으니까 야근을 밥먹는듯이 하겠죠. 하여간 이것이 효율적이지 못하다면 개인의 금같은 시간을 낭비하는 것이니 가능한 야근하지 않도록 근무시간에 좀더 집중해야겠습니다.

조엘 on 소프트웨어라는 책을 보면 조엘 테스트가 나옵니다. 예전에 한번 보기도 했는데, 괜찮은 테스트이므로 한번 여러분의 소프트웨어 개발 환경에 대해 점검해 보기 바랍니다.

1. 소스코드 관리 시스템을 사용합니까?
cvs, MS visual source safe, rational clear case와 같은 형상관리 툴이 있습니다.

저는 위 3가지 툴을 모두 써봤습니다.
source safe -> cvs -> clear case

source safe는 5년전에 쓰던거라 현재 버전에 대해 뭐라 평가하기는 힘들고 한사람이 소스 파일을 check-out하면 다른 사람은 코들를 수정할 수가 없었습니다. 퇴근하기전 check-in은 필수였습니다. VC++이나 VB에서 기본 제공하므로 가장 쓰기 편했습니다.

cvs는 오픈소스프로젝트에서 사용하고 있는 형상관리툴입니다. 모든 플랫폼에서 안정적으로 동작하면 특히 merge기능은 상용툴인 clear case보다 좋은 것 같습니다. 한번도 실망시킨적이 없습니다.

전반적으로는 상용 제품인 clear case가 좋긴 좋더군요. 물론 서버를 관리해주는 사람이 따로 있다고 가정할 때 말이죠. 특히 소스코드를 서로 다른 프로젝트로 이동하거나 다양한 버전을 유지할 때 그리고 폴더, 파일 이름 변경이 쉬워서 좋았습니다. cvs에서도 서버 접근만 되면 가능하면 쉽게 할 수 있긴하죠.

2. 한방에 빌드를 만들어낼 수 있습니까?
한번 빌드에 다양한 버전에 소프트웨어를 컴파일까지 하고 설치버전까지는 만드는 것입니다. 사실 이 부분은 아직까지 시도해보지 못했습니다. 여러 라이브러리를 쓰면, 라이브러리 따로 컴파일하고 실행파일도 따로 컴파일하고 dll도 따로 빌드하고 이 결과를 가지고 설치 프로그램을 만드는 것은 다소 복잡한 일이기도 하지요. 게다가 버전이 여러가지 유지한다면 분명 실수할 수도 있습니다.

3. 일일 빌드를 하고 있습니까?
일일 빌드라고 말할 수 없지만 수시로 전체 프로젝트를 업데이트해서 각자 빌드는 하고 있습니다. 문제는 실제 타겟용으로 자주 빌드를 해야 하는데, 그렇지 못해서 컴파일이 안되곤 합니다. 임베디드 환경에서는 PC에서 작업을 하고 타겟용으로 다시 컴파일을 하는데, 이때 문제가 자주 발생합니다. PC에서 잘 동작한다고 너무 자신만만해서는 안됩니다. 이것은 꼭 임베디드에 해당하는 것은 아니고 여러 플랫폼을 지원하면 자주 접할 수 있는 문제입니다.

4. 버그 추적 시스템을 운영하고 있습니까?
지금 회사에서도 훌륭하게 운영하고 있었지만 전에는 wiki를 이용하기도 했고 zero board에서 운영한적도 있습니다. 잘만 쓰면 모두 훌륭합니다. 못쓰면 아무리 좋은 툴도 소용이 없습니다.

중요한 것은 다음의 항목이 있어야 한다는 군요.

* 버그를 재현하기 위한 완벽한 단계
* 예상 수행 결과
* 실제 수행 결과
* 수정을 맡을 개발자
* 수정했는지 여부

5. 코드를 새로 작성하기전에 버그를 수정합니다.
이건 정말 중요합니다. 그렇지 못하면 소프트웨어의 위기에 빠지고 맙니다.
하지만 내 마음속에만 숨어있는 버그도 있긴합니다. 거의 발생한 일이 없으므로 아무도 못찾으면 그냥 넘어가기도 하지요.

6. 일정을 업데이트하고 있습니까?
조엘이라는 사람은 MS프로젝트에 대해 좋지 않은 평가를 내리고 있습니다. 저도 MS프로젝트를 이용하고 있지만 처음 작성할 때만 보고 그 후에는 거의 쳐다보지 않게 됩니다.

7. 명세서를 작성하고 있습니까?
정말 중요하다는 사실은 알고 있지만 코딩하는 것 보다 더 어렵습니다. 파워포인트로 아이디어를 정리하고 코딩한 후에 정식으로 문서화를 하고 있습니다.

8. 조용한 작업 환경에서 일하고 있습니까?
한 사무실에 몇십명씩 앉아서 일하는 환경이라면 조용하기가 참 힘들죠. 그 때는 해드폰으로 귀를 막고 모니터에 폭 빠져 일하는 것이 좋습니다. 2-3곡을 무한 반복으로 들으면서 일하면 집중이 잘~ 됩니다.

9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
만약 관리부서 사람들이 제일 먼저 업그레이드 한다면? 그 회사는 머지 않아 망합니다.
다지이너가 제일 먼저 업그레이드를 한다면? 프로그램이 화면발은 죽이지만 버그는 엄청날 수도 있습니다...
개발자에게 LCD 모니터를 사주세요. 정말 일 잘할겁니다.

회사에서 집보다 좋은 환경을 쓰면 그만이겠죠?

10. 테스터를 별도로 두고 있습니까?
출시일이 다가오면 사장님빼고 모두 테스터가 된적도 있습니다. 지금 회사와서 놀란 것은 테스트를 전담해주는 팀이 있다는 사실입니다. 역시 큰회사라 다르군요. 전에 웹브라우저 만들 때, 정말 테스트는 힘든 작업이였습니다. 자동화하기도 힘든 부분이라 일일히 주요 웹페이지를 돌아다니면서 테스트를 했습니다. 개발자가 테스트하면 웬진 비용이 덜 드는 것 같지만 사실 엄청난 비용을 들이는 것입니다.

11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
저도 이런 테스트를 받아본 적도 해본적도 없습니다. 프로그램 결과물과 소스코드를 제출한 적은 있습니다. 사실 이런 테스트를 받으면 잘 할 수 있을지 고민이 되기 합니다.

12. 무작위 사용 편의성 테스트(hallway usabiliy test)를 수행하고 있습니까?
해당 소프트웨어에 대해 문외한인 사람에게 테스트를 맡기는 것이라고 하네요. 영업부나 관리부 직원이면 적당할 것 같습니다.