많은 관심과 참석 바랍니다~~

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

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

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

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

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

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

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

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

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

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

KLDP 권순선님 글을 읽고

특정 회사에 사용자의 컨텐츠가 소속되는 것이 아니라 순전히 사용자 중심으로 컨텐츠가 관리되고 이용되는 것을 말하는 것 같습니다.

여전히 많은 회사들이 사용자가 만든 컨텐츠에 대해 독점적인 입장을 취하고 있으나 언젠가 사용자에 의해 그런 컨텐츠가 쉽게 공유되는 때가 올 것 같네요.

컨텐츠는 그대로 있고 서비스를 넘나들 수 있수 있겠죠.

그리고 사용자 뿐만 아니라 업체들도 자신들이 고유하게 구축해 놓은 컨텐츠를 어떤 표준하에 서로 공유하는 때가 올 것이라 예상합니다.

기술적으로 모든게 갖춰져있지만 아직 문화나 개념들이 생소하긴 합니다.

뭔가 오픈하기 싫어하는 우리나라에서는 참 힘들겠죠..

원본 글

많은 참여와 관심 바랍니다~~
--------------

2006년은 KLDP가 시작된지 정확하게 10년째 되는 해입니다. 그래서 10주년을 기념하는 오프라인 행사를 다음과 같이 가지고자 준비 중이며, 이번 10주년 기념 컨퍼런스에서는 F/OSS 개발자와 사용자들이 한자리에 모여 즐길 수 있는 축제의 장이 될 수 있도록 하는 것이 목적입니다.

행사 장소는 크게 4개의 홀과 로비로 구성되어 있습니다. 각 홀은 300명 정도를 수용할 수 있으며 4개 중 3개를 강연에 사용하고 1개는 상시 전시 공간으로 활용할 예정입니다. 전체 참석 정원은 총 1000명입니다.

행사는 다음 3가지의 세부 행사로 구성될 예정이며 강연/전시를 제외한 부분은 아직 어떻게 할지 정확히 확정되지 않았습니다.

• 강연: F/OSS 개발자와 사용자를 위한 내용으로 총 3개의 트랙으로 진행될 예정입니다.


• 전시: 본 행사에 참여하는 커뮤니티와 개발자들, 그리고 행사를 후원해 주시는 스폰서를 위한 공간입니다.


• BoF: Birds of a Feather의 약자로서 특정 내용에 관심이 있는 사람들의 모임을 의미합니다.

행사 정보는 다음과 같습니다.

• 날짜: 2006년 9월 17일 일요일


• 장소: 서울 지하철 3/7호선 고속터미널역 센트럴시티(신세계 백화점 5층으로 올라오시면 됩니다.)

현재 논의중인 강의 세션은 다음과 같습니다.

• 박재호: 고급 디버깅 기법


• 장혜식(perky): 오픈소스 프로젝트에 참여하기


• 권순선: 제품개발시 고려해야 할 오픈소스 이슈


• 최호진(pynoos): 오픈소스와 회사 개발 프로세스 연관시키기


• 윤석찬(channy): 모질라 프로젝트의 현재와 미래


• 이창신(이아스): 오픈소스의 PMC와 커미터, Google Summer of Code 멘토링 경험


• Greg Stein: Google의 오픈소스 활용 사례


• 조성재(jachin): KDE 프로젝트 소개

행사에 참여하시고자 하는 분은 왼쪽 네비게이션 바의 내 계정-편집-KLDP 탭에서 체크박스를 클릭해 주시면 됩니다. 이곳 KLDP에 아이디가 없는 분들은 KLDP10YearAnniversary/registration에서 참가신청을 하시면 됩니다.

자세한 내용은 KLDP10YearAnniversary를 참고하시기 바랍니다. 아직 세부 내용은 논의 중입니다. 행사 참여뿐만 아니라 행사 진행시에도 많은 분들의 도움이 필요한 관계로 자원봉사자 모집 등 진행 관련해서 많은 공지가 나갈 예정입니다. :-)

해커와 화가 폴 그레이엄 지음, 임백준 옮김/한빛미디어

야후 스토어를 만든 폴 그레이엄이라는 사람이 쓴 책이다. 창업한 회사를 야후에 팔고 그림 공부를 하면서 느낀 점을 책으로 엮은 것이다. 전체 내용이 해커와 화가에 대한 것은 아니고 여러 essay가운데 하나가 바로 "해커와 화가"에 대한 이야기이다.

프로그래머지만 인문학적 지식이 많이 담겨있고 SW개발에 대하여 남다른 관점을 제시하여 색다른 느낌으로 책을 읽을 수 있었다. 특히 그림 그리기를 좋아하는 나로서는 프로그래밍과 그림 그리기는 작업 방식이 같다는 저자의 주장이 참 신선했고 충분히 동감이 갔다.

사실 SW개발과 그림 그리기는 그 결과가 어떻게 나올지 대충 예상은 가능하지만 정확하게 미리 보기는 힘들다. 초기 스켓치는 그냥 버려지고 (SW에서는 프로토타입) 점진적으로 작품이 완성되어 간다. 그리고 가장 좋은 디자인일 때 완성이라고 말할 수 있으며, 단순한 디자인일수록 아름답다는 저자의 말에도 공감이 간다.

해커란?

해커에 대한 저자의 정의 또한 뭔가 내게 숙제꺼리를 남겨주었다.

"해킹을 정말로 좋아한다면 뭔가 자기 자신만의 프로젝트를 수행하지 않고는 견딜 수가 없는 것이다"

여기서 해킹은 우리가 흔히 아는 그런 의미(남의 시스템을 몰래 망가뜨리는)는 아니다. 저자는 해킹에 대한 구체적으로 정의하지 않았으나 내 생각에, 해킹이라는 지적 호기심의 탐구이며 그런 호기심을 구체적 실행에 옮기는 행위를 뜻하는 듯 보였다. 여기서 실행이란 Open Source Project의 참여라고 저자는 말하고 있다.
나도 전에 Open Source Project를 수행한 적이 있으나 지금은 개점휴업 상태이다. 물론 지금도 새로운 일거리에 관해 계획을 세워보기도 하지만 실천에 옮기지 못하고 있다.

"우리는 좋은 생각이 떠오르면, 계획을 세우는 것이 아니라 그것을 구현했다"
나도 대학원 시절에는 그랬던 것 같다. 뭔가 좋은 생각이 떠오르면 내가 원하는 것을 뚝딱뚝딱 만들어냈다. 홈페이지 게시판도 그냥 만들었고 공부하면서 필요한 프로그램도 직접 개발했었다.

좋은 소프트웨에 대한 그의 생각

해커가 되려면 다른 사람이 개발한 좋은 프로그램을 살펴봐야 한다고 했다. 이는 마치 옛 예술가들이 다른 작품을 분석하면서 좋은 화가가 된 것 처럼 말이다. 그리고 Oil Paint의 발명이 그림을 좀 더 고치기 쉽게 만들었던 것 처럼 우리도 가능하면 변경이 쉽도록 코딩을 해야된다고 했다.
"좋은 소프트웨어 안을 들여다 본다면, 누구도 볼 수 있을 것이라 생각지도 못했던 부분들 역시
아름답다는 것을 알게 된다"

이 말은 정말 잘 설계되고 잘 짜여진 코드를 볼 때, 예술작품 처럼 그 안에서 아름다움을 느낄수 있다는 것을 의미하는데, 과연 내가 이런 아름다움을 느껴본 적이 있는지.. 이런 아름다움이 뭔지는 알고 있었는지 기억만 희미할 뿐이다. 그래도 예전에 코딩을 끝낸 후, "완벽해! 더 이상 수정할 곳이 없고 아주 직관적으로 잘 짜여져 있어"라고 외쳤던 적은 있다.

사용자 입장에서 SW를 바라보기

"SW는 그 자체로 설명이 가능해야 하며, 좋은 SW를 개발하기 위해 소수의 사용자가 어떻게 이해하는지 헤아리고 있어야 한다"

SW를 개발할 때, 많은 개발자가 착각하는 것은 자신들의 입장에서 SW를 개발하는 부분이다. 설명서 없이는 사용하기 힘들고, 개발자가 알고 있는 용어를 무심코 사용자에게 강요하기도 한다. 이런 부분은 모든 엔지니어가 꼭 고쳐야할 분 부분이다.

"소스코드는 그 차제로 설명되어야 한다"

"프로그램은 오직 사람이 읽기 위해서 작성되야 한다. 컴퓨터가 그것을 실행하는 것은 부차적인 일이다"

SW개발 프로세스에서 산출물은 참 중요하다. 어떠한 산출물을 포기하더라고 기본 설계서, 상세 설계서는 빠뜨리기 힘들다. 이렇게 산출물을 작성하는 이유는 코드만 봐서는 SW를 이해할 수 없기 때문이다. 이것은 개발자 수준의 문제인 것 같다. 정말 훌륭한 아키텍트가 설계하고 좋은 개발자가 개발을 진행했다면 코드만으로도 SW를 이해할 수 있어야 한다.

마이크로소프트는 공식적으로 설계서를 작성하지 않는다고 한다. 워낙 SW가 자주 변경되다 보니 그 내용을 설계서에 반영할 만큼 여유가 있지 않으며 설계서를 통해 SW를 이해하기 보다 코드를 통해 선임자가 설명해주는 방식으로 후임자들은 SW를 이해하게 된다고 한다. 그 만큼 SW가 일관성있게 잘 짜여져 있다는 것을 보여주는 대목이다.

우리가 지금 짜고 있는 코드가 예술 수준은 아니더라 일정 수준의 개발자라면 누구나 이해하기 쉽도록 짜여져 있는지는 고민해 볼 문제다.

레오나르도 다빈치도 해커다

우리는 레오나르도 다빈치의 작품에서 아름다움과 예술성을 느낀다. 하지만 과거에도 지금 우리가 느끼는 만큼 평가를 받았을까? 아마도 오늘날의 SW개발자 처럼 그들도 당시의 개발자(?) 중 하나였을 것이다. 단지 SW가 아닌 초상화와 벽화를 그리며 자신만의 세계에서 해킹에 열중했을 것이다. 사실 SW가 어찌 개발되던간에 일반 사용자는 코드 내부를 볼 수 없으므로 SW설계나 코딩이 정말 예술의 경지처럼 잘 되어 있는지 확인할 방법이 없다. 다빈치의 그림이나 벽화도 그 당시 대중이 인식할 수 없는 부분에서 작가만의 미를 추구했는지 모른다. 저자는 그림 배경에 있는 나무 덤불의 세밀한 묘사를 그 예로 들고 있다.

예술성은 당대에 평가받지 못한다

저자는 많은 개발자에게 우리의 작업이 현재는 제대로 평가받고 있지 못하지만 그 옛날 예술가가 그래왔듯이 우리만의 미학을 추구하다보면 일반 사람들도 해킹에 열광하는 그런 시대가 올 것이라고 희망을 주고 있다.

뭐, 이정도는 바라고 있지 않지만, 우리 마음속에 잠자고 있는 해커적 기질을 깨워서 예술에 못미칠지라도 편리하고 좋은 소프트웨어 개발에 힘을 쓰고, 우리의 작업에 좀 더 많은 의미를 부여해야하지 않을까 생각해본다.

참고문헌

Paul Graham, Hackers & Painters (Big Ideas From The Comptuer Ages), O'REILLY, 2004

ps. 한글판으로 보다가 대여기간이 끝나 다시 영문판으로 봤습니다. 영문판은 좀 어렵습니다. 한글 번역도 훌륭하므로 한글판으로 보세요.

안타깝게도 우리나라는 16강에 오르지 못했다. 하지만 우리는 원정 첫승을 거두었고 프랑스와 대등한 경기를 펼쳤다. 무엇보다 지칠줄 모르는 우리의 투지를  확인할 수 있어서 좋았다.

월드컵은 분명 상업적이다. 많은 사람들의 이해 관계가 얽혀있고 때론 그것이 승부에 영향을 미치기도 한다. 좀 더 민주적인 시스템이 도입되어 진정한 스포츠 정신을 느끼고 싶다.
하지만 그런 모든 것을 떠나 잠시나마 많은 사람들이 하나가 된 것, 지구에 사는 많은 사람들이 함께 평화롭게 웃고 즐기고 때론 안타까워하는 모습을 통해 월드컵에서 좋은면을 찾고 싶다.

누군가는 월드컵이 국가주의, 민족주의를 불러일으킨다고 하지만 그래도 우리가 토고, 세네갈 이런 나라를 기억하게 되는 것은 순전히 월드컵을 통해서 가능한 것이다.

그렇다 월드컵은 지구촌 최대의 축제다. 그리고 모두에게 희망은 있다. 우리도 강팀이 될 수 있다는...

이 가운데 쓸만한 몇가지 원칙을 뽑아 본다면..

일반원칙

• 품질이 제일이다.


• 사후에 품질을 만들어 넣으려하지 마라.


• 성능보다 신뢰성이 더 중요하다.


• 시제품을 고객에게 빨리 보여준다.


• 처음 시도하는 것은 폐기할 작정으로 개발한다.


• 보면 볼수록 더 많은 것을 원한다. (변경에 대비하자)


• 개발중의 변경은 피할 수 없다.


• 가능하면 개발하기 보다는 구매한다.


• 사용자 메뉴얼이 간단하게 되도록 소프트웨어를 개발한다.


• 아무리 복잡한 문제라도 해결책은 있다.


• 소프트웨어 도구는 우수한 개발자에게 제공한다.


• 대세를 따를 때는 주의해야 한다. (신기술대한 맹목적 수용은 위험)


• 문서표준을 사용한다


• 모든 문서에 용어정의를 한다.

요구사항 원칙

• 요구사항이 불명확할수록 비용예측이 어렵다.


• 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.


• 요구사항의 우선순위를 정한다.

설계원칙

• 설계산출물에서 요구사항을 추척한다.


• 문서가 없는 설계는 설계가 아니다.


• 캡슐화한다.


• 가능하면 재사용한다.


• 단순하게 개발한다.


• 특수한 경우를 많이 만들지 않는다.


• 변경이 쉽게 설계한다.


• 효율적인 알고리즘을 사용한다.


• 뛰어난 설계는 뛰어난 설계자가 한다.


• 무모한 값을 입력하면 적절한 오류 메시지를 출력하도록 한다.

코딩원칙

• 글로벌 변수를 사용하지 않는다.


• 의미있는 명칭을 사용한다.


• 사람을 위한 프로그램을 작성한다.


• 최적의 자료구조를 사용한다.


• 코드를 완성하기 전에 주석을 작성한다.


• 코딩을 시작하기 전에 문서화한다.


• code 검토를 실시한다.


• 너무 깊이 중첩시키지 않는다.

시험원칙

• 시험에서 요구사항을 추척한다.


• 시험하기 훨씬 이전에 시험을 계획한다.


• 자신이 개발한 소프트웨어는 자신이 시험하지 않는다.


• 블랙박스 시험과 화이트박스 시험을 실시한다.


• 항상 스트레스 시험을 한다.


• 단위시험이 끝나기 전에 통합하지 않는다.


• 소프트웨어에 특정한 시험용 코드를 내장시킨다.

관리원칙

• 뛰어난 관리는 뛰어난 기술보다 중요하다.


• 고객의 우선순위를 알아야한다.


• 많은 사람보다는 소수정예요원이 낫다.


• 항상 기대치를 높이 가진다.


• 능숙한 의사소통 기술은 필수적이다.


• 인력과 시간은 대체할 수 없다.


• 소프트웨어 개발자의 능력차이는 크다.


• 불가능한 것은 피한다.


• 적절한 프로세스 모델을 사용한다.


• 직면한 위험을 이해한다.


• 방법론이 당신을 구제해 주지는 못한다.

제품보증 원칙

• 형상관리 절차를 조기에 확립한다.


• 모든 중간산출물에 명칭과 버전 번호를 부여한다.


• 기준선을 통제한다.


• 모든 것을 보존한다.


• 변경관리를 해야 한다.

진화원칙

• 소프트웨어는 계속 변화한다.


• 증상이 아닌 근본적인 문제를 수정한다.


• 최악의 구성요소는 처음부터 다시 개발한다.


• 변경한 후에는 반드시 회귀시험을 실시한다.


• 비구조적인 코드는 구조화해도 개선되지 않는다.

이상입니다~

지난 5월 31일 Flickr Pro 유료 계정을 구입했습니다.

놀라운 거금 24.95$을 썼습니다. ^^;
웹서비스를 돈을 주고 사용하게 된 것은 이번이 두번째입니다. 지금은 사라졌지만 스트리밍 뮤직 서비스를 유료로 사용했던 적이 있습니다. 이 회사(neoviz)는 너무 빨리 서비스를 시작했고 서비스가 궤도에 오르기 전에 성급히 유료화를 시도하는 바람에 문을 닫은 듯 보입니다.

하여간 결국 돈을 쓰게 만드는 Flickr의 사진 앨범 서비스는 정말 강력합니다. 그 동안 많은 온라인 사진 앨범 서비스가 있었지만 용량의 제한, 웹에서만의 업로드 방식, 폐쇄적인 구조 등으로 그다지 큰 환영을 받지 못해습니다.

Flickr는 Open API를 제공하여 자신의 블로그에 앨범을 추가할 수 있고 사진 앨범 관리 소프트웨어인 iPhoto나 Picasa에서도 손 쉽게 사진을 업로드할 수 있습니다.

무엇보다도 Flickr는 열린 Community를 지향하여 가능하여 회원 뿐만 아니라 누구와도 사진을 공유할 수 있도록 하고 있습니다. 게다가 원본 크기 이외에도 여러 크기로 사진을 제공하고 있어서 자신의 홈페이지나 블로그에 연결하기 좋습니다.

안타까운 것은 아직 한글 서비스가 안된다는 부분과 인화나 DVD로 구워주는 서비스는 국내에서 안되는 부분입니다. 야후에서 flickr을 인수하였으니 언젠가 국내에서 지역화된 flickr서비스를 맛볼 수 있을 것 입니다.
하여간 인터넷이 발전한 우리나라에 이런 사진 앨범 서비스가 없다는 것이 아쉽습니다. 특정 서비스 보다 포털을 지향하다 보니 이런 서비스가 발전하기 힘들고 자기들만의 닫힌 공간을 지향하다 보니 다른 웹서비스나 애플리케이션과 연동하는 부분이 약하기 때문에 발전의 폭도 적었던 것 같습니다.

이외에도 zooomr와 같은 사진 앨범 서비스도 있습니다. flickr와 비슷한데, Google Maps과 연동하여 사진 찍은 위치를 표시할 수 있습니다.