피플웨어라는 블로그를 운영하는 류한석님의 "8Bit 키드의 현재"라는 글을 읽고...

8Bit시절...



애플2, MSX 가 양대산맥으로 있던 그런 시절이 있었습니다. 가끔 금성 패미콤 시리즈나 삼성 SPC시리즈를 갖고 있던 아이들도 있었으나 역시 주류는 애플과 MSX였지요.

제가 처음 컴퓨터를 접한 것은 1984년, 당시 초등학교에 처음 도입된 FC-100이라는 컴퓨터였습니다. 학교에 단 한대의 컴퓨터가 들어왔고 이듬해에 컴퓨터반이 생겼습니다.

아이들 60명에 단 한대의 컴퓨터.

그 컴퓨터가 과학실에 있었고 담임선생님이 관리 담당이라서 방과 후에 혼자 쓸 수 있는 기회를 갖게 되었습니다. 그렇게 컴퓨터와의 인연은 시작되었습니다.

중학교 2학년, 생애 최고의 성적결과로 고무된 부모님은 저에게 MSX2를 사주셨고 그 이후로 그 성적은 역사의 한페이지가 기록되고 말았습니다. ^^; 하여간 저는 중학교 내내 컴퓨터에 푹 빠져서 지냈습니다. 온갖 게임도 다 해보고 Basic으로 게임도 만들고 나중에는 Z80 기계어까지 공부하려고 했으나.. 중학생 수준에서는 무리였던 것 같습니다.

국민PC로 IBM PC가 선정되면서 8Bit는 역사의 뒤안길로 사라지기 시작했습니다. 컴퓨터 잡지 기사는 점점 줄고 친구들 중 하나둘씩 PC를 구입하면서 같이 게임하고 이야기 나누던 친구들도 멀어져갔습니다.
지금 생각해보면 정부에서 참 잘한 일이라는 생각이 듭니다. 계속 8Bit 컴퓨터를 끌고 나갔다면 일본에 컴퓨터 시장이 종속될 것이 뻔했고 빨리 PC를 사용한 덕분에 일본이 PC9801기종으로 삽질하는 동안 우리는 정보통신 강국의 기초를 잘 닦을 수 있었습니다.

고등학교와서 가끔 게임 하는 것 외에는 컴퓨터를 잘 쓰지 않다가 대학에 와서 386 PC와 PC통신으로 새로운 세계에 빠져들게 되었습니다.

중학교 때 MSX Basic을 마스터한 덕분에 Visual Basic으로 처음 윈도 프로그래밍을 하게 되었고 그 인연으로 지금까지 개발자의 길을 걷고 있습니다. 아마도 그 당시 MSX Basic을 공부하지 않았다면 현재의 저의 모습은 찾기 힘들 것입니다. 그 당시에는 잘 몰랐으나 MSX의 'M'이 오늘날의 Microsoft를 의미하는 것이였고 MSX-DOS를 비롯하여 8Bit시절에 많은 것을 선행 학습할 수 있었습니다.

다행스럽게도 8Bit 시절의 추억을 갖고 여전히 이쪽에서 일하는 분들이 많네요. 요즘 아이들은 온라인 게임에 푹 빠져있지만 그 때 우리는 나름대로 게임을 하기 위해 코드를 입력했고 지금도 그렇지만 그 때도 버그와 싸웠었지요. ^^; 지금 우리들의 모습에서 그 때 기억을 떠올리니 재미있습니다.

바캠프라는 행사가 열리는군요.

무척 흥미로운 행사 같아서 참가 신청을 했습니다.

일종의 컨퍼런스인데, 누구나 어떤 주제를 가지고 발표를 할 수 있습니다.

발표 주제를 무엇으로 할까 고민 좀 해봐야겠습니다.

아래 내용은 행사 소개에서 가져왔습니다.

BarCamp의 취지 및 진행

BarCamp는 여러 관심사의 사람들이 만나 서로 의견을 교환하는 강력한 교류의 장입니다. 모두가 참여자가 되며 구경꾼이 있을 수 없습니다. FooCamp 보다 더 자유로운 형식을 지향해서 실리콘밸리에서 시작된 이 행사는 전 세계적으로 주로 인터넷 서비스나 기술에 대한 주제를 기반으로 열리고 있으나, 영화 만들기나 취미 생활 같은 주제를 나누어도 무방합니다. BarCamp는 캠핑장에서 숙박을 같이 하면서 열리기도 하고, 하루 행사로 열리기도 합니다. 국내에서 처음 열리는 BarCampSeoul은 아래와 같은 모임을 제안합니다.

---

일시 및 장소

• 
  
  
  
  • 일시: 2006년 10월 21일(토) 오전 11:00 ~ 17:00
  
  
  • 장소: 다음커뮤니케이션 3F (열린방) 찾아 오시는 길
    
    
    
    • 전체 60석 좌석에 4개의 분할 세션이 가능합니다.
    
    
    
    
  
  
  
  

참가 신청은 아래 URL에서 가능합니다..

http://barcamp.org/BarCampSeoul

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

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

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

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

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

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

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

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

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

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

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

일반원칙

• 품질이 제일이다.


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


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


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


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


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


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


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


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


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


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


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


• 문서표준을 사용한다


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

요구사항 원칙

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


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


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

설계원칙

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


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


• 캡슐화한다.


• 가능하면 재사용한다.


• 단순하게 개발한다.


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


• 변경이 쉽게 설계한다.


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


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


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

코딩원칙

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


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


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


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


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


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


• code 검토를 실시한다.


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

시험원칙

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


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


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


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


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


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


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

관리원칙

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


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


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


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


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


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


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


• 불가능한 것은 피한다.


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


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


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

제품보증 원칙

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


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


• 기준선을 통제한다.


• 모든 것을 보존한다.


• 변경관리를 해야 한다.

진화원칙

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


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


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


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


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

이상입니다~

Google의 검색 페이지와 Apple의 iPod의 공통점과 성공요인은 무엇일까요?

그것은 단순함에 있습니다.



처음 구글 검색 페이지를 봤을 때, "도대체 이 회사는 광고도 없이 무엇을 먹고 사나" 이런 생각이 들었습니다. 하지만 그들은 모두가 포털을 추구할 때, 검색 엔진의 성능에만 집중함으로써 많은 사용자를 끌어들일 수 있었습니다. 그리고 검색 입력창만 있는 단순한 구성을 통해 사용자게는 편리함과 기술력에 대한 신뢰를 줄 수 있었습니다.



Apple의 iPod는 HW적 측면을 볼 때, 저장공간이 큰 것 빼고는 다소 부족해보입니다. 국내 MP3 Player에서 기본적으로 제공하는 녹음과 FM라디오 기능이 없습니다. 하지만 꼭 필요한 음악을 듣고 MP3 파일을 관리하는 기능은 아주 뛰어납니다. 특히 컨텐츠 관리 측면에서 보면 iTunes Music Store와 연동 기능과 넓은 화면 그리고 특유의 브라우징 휠의 편리함은 다른 MP3 플레이어가 넘어서기 힘든 부분입니다.

HW적으로 부족한 부분을 SW적으로 해결했다고 볼 수 있고 FM라디오, 녹음 기능은 악세서리를 이용하면 가능하기 때문에 꼭 그 기능이 필요한 사용자에게는 별 문제가 안됩니다. 게다가 Apple은 이와 같은 악세서리 판매로도 많은 수익을 창출하고 있습니다.

꼭 필요한 기능만으로 사용자가 원하는 핵심에 다가서는 단순함과 집중성!
Apple과 Google의 성공 비결인 듯 싶습니다.

소니 아이보라는 강아지 로봇을 조정할 수 있는 SDK가 인터넷에 공개되어 있다.

http://openr.aibo.com/

두가지 방식으로 사용할 수 있는데, 우선은 무선랜을 이용해서 PC에서 아이보를 조정하는 것이 있으며 직접 아이보에 자신이 개발한 소프트웨어를 실행시킬 수 있다. 이 부분은 마인드스톰과 동일하다.

아이보가 마인드스톰에 비해 훨씬 많은 다양한 기능을 제공한다. 물론 아이보는 가격이 훨씬 비싸 약 2백만원 정도한다. 하지만 일반적인 기능을 수행할 수 있는 좋은 로봇 플랫폼 처럼 보인다.
정교한 이동과 카메라를 통한 비전 기능도 수행 가능하다. 또한 무선랜이 가능하여 아이보끼리 서로 통신도 가능해 보인다.

아이보 SDK는 로봇에서 제공할 수 있는 인터페이스가 구현되어 있어서 앞으로 다른 로봇에도 많은 영향을 미칠 것 같다.

단점은 아이보에 새로운 하드웨어를 붙일 수 없는 부분이다. 겨우 돌아다니는 강아지에 뭘 붙인다는 것이 말이 안되지만 기계적 확장성이 없는 것은 사실이다.

안타까운 것은 이제 아이보가 역사속에 사라진다는 것이다. 로봇 소프트웨어를 하고 싶은데, 하드웨어가 없다면 빨리 아이보를 잡는 것이 좋을 것이다. 비록 아이보는 더 이상 출시되지 않았지만 애플의 뉴톤이 그랬던 것처럼 앞으로 더 나은 로봇이 나올 좋은 발판이 될 것이다.

참고
* 소니 로봇 강아지「아이보」역사 속으로 사라지나, http://www.zdnet.co.kr/news/digital/0,39030978,39143954,00.htm
* 아이보SDK, http://openr.aibo.com

소프트웨어 개발자는 공부를 많이 해야 한다. 새로운 기술이 늘 쏟아지다 보니 지금 유행하는 기술도 어느새 최신 기술에 밀려 찬밥 신세가 되고 만다.

모뎀으로 겨우 통신이 가능하던 시절에는 대부분의 개발자가 단독으로 실행되는 프로그램을 개발했지만 인터넷이 등장하고 웹이 일반화되면서 웹개발이라는 새로운 영역이 생겨나기 했다.

C, C++이 보편적으로 쓰이던 때에 갑자가 Java, C#이 이라는 언어가 나타나서 개발자들에게 배울거리는 던져주기도 했다.

그러고 보면 그 옛날 열심히 공부했던 VB, Win32API, MFC는 최근 2년간 거의 사용하지 않고 C, C++ 기본 라이브러리로만 개발을 해왔었다.

툴과 언어는 계속 진화하고 또 사라진다. 특히 10여년전에 만들어진 언어는 지금도 버전업하면서 더 복잡해지고 있다. 특히 툴이나 특정 프레임웍 또는 API에 의존적으로 개발을 하다 보면 변화에 둔감해 질 수 있다. 당장 MFC는 앞으로 거의 사용되지 않을 전망이고 Win32 API 미래도 그리 밝아보이지 않는다. 새롭게 출시될 롱혼에서는 이 들을 가지고는 롱혼 전용 애플리케이션 개발은 불가능할 것이다.

그래도 우리가 배우고 익힌 소프트웨어 기술 가운데 변하지 않는 핵심은 분명 존재한다. 하지만 바쁘게 개발을 하다보면 이런 것들을 잘 못느끼고 엉뚱한 것들에 가치를 두는 경우가 많다. 대표적인 것이 툴과 언어에 대한 집착이다.

그렇다면 변하지 않는 것은 무엇이 있을까?

"Professional 소프트웨어 개발"이란 책에서는 SWEBOK에서 식별한 전문 소프트웨어 엔지니어가 갖추어야 할 능력을 구성하는 지식 영역을 다음과 같이 소개하였다.

* 소프트웨어 요구사항(Software Requiremenet)
* 소프트웨어 설계(Software Design)
* 소프트웨어 구축(Software Construction)
(상세설계, 코딩, 디버깅, 단위시험, 코드리뷰, 최적화)
* 소프트웨어 시험(Software Testing)
* 소프트웨어 유지보수(Software Maintenance)
* 소프트웨어 형상관리(Software Configuration Management)
* 소프트웨어 품질(Software Quality)
* 소프트웨어공학 관리(Software Engineering Management)
* 소프트웨어공학 툴과 방법론(Software Engineering Tools and Method)
(CASE 도구, 재사용 코드 라이브러리, 정형 방법론 같은 도구와 방법론의 지원, 조직 내에서 도구와 방법론 채택, 전파하는 기법)
* 소프트웨어공학 프로세스(Software Engineering Process)
(소프트웨어 개발 품질, 일정, 생산성 및 프로젝트와 제품의 특성을 향상시키기 위한 활동)

사실 여기서 많은 개발자들이 앞부분의 2-3개 분야가 모든 것인양 알고 공부해왔을 것이다. 오직 코딩이라는 측면만 보면 그 말도 맞긴 하다. 하지만 우리가 생각하는 것외에 더 많은 지식 영역이 존재하고 이는 더 좋은 소프트웨어를 개발하는데 필수적인 지식이다. 그럼에도 불구하고 많은 개발자들이 품질이나 프로세스와 같은 SE측면을 간과하고 있는 것은 안타까운 부분이다.

나만 좋은 소프트웨어를 개발하는데는 많은 지식이 필요하지 않지만 남이 좋아하는 소프트웨어를 개발하기 위해서는 몇배의 지식이 필요하다.

오늘도 나만을 위한 개발을 위해 엷은 지식에 만족하고 있는지 되묻고 싶다.

참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003
* SWEBOK (http://www.swebok.org)

읽을거리
* 프로그래머가 알아야할 것

"Professional 소프트웨어 개발"을 읽고

소프트웨어업계에 몸을 담은지도 거의 10년이 다 되가는 것 같다. 대학 졸업하기전부터 업계에 투신(?)했기 때문에 오랜 경력을 쌓고 있으나 그것이 진정한 경력이라고 말하기는 힘든 것 같다. 적어도 이 책을 읽고 나면 그런 생각이 든다.

Software Engineering의 중요성을 알게 된 것은 그리 오래되지 않았다. 2003년 PDA용 웹브라우저를 개발하면서 마감기간을 지키기 위해 몇날을 밤새웠고 잘못된 아키텍쳐 선정으로 몇주를 그냥 날려버리고 개발보다 테스트에 많은 시간을 들이는 등 총체적인 문제에 직면했었다. 물론 프로젝트는 성공적으로 마무리가 되었다. 하지만 부작용은 심각했다. 크리스마스와 새해를 회사에서 보냈고 결국 무리하게 개발을 진행하다가 핵심 개발자 두 명이 회사를 그만두고 말았다.

무엇이 문제였을까?

* 우선은 너무 짧은 개발기간이 문제였다.
사실 이것이 모든 문제의 원인 같다. 이로 인해 프로젝트에 대한 검토 기간이 적어 잘못된 아키텍쳐를 적용했고 몇가지 요구분석이 제대로 이루어지지 않아(이보다는 요구분석이 공유되지 않아)중요한 기능들을 나중에 적용하느라 많은 부분에서 수정이 이루어졌다.

* 자동화된 테스트를 시도하지 않았다.
브라우저 특성상 여러 웹페이지를 테스트해야 하는데, 이를 모두 사람이 하나하나 테스트를 했다. 기능하나 추가할 때 마다 여러 기종으로 모든 웹페이지를 다 테스트했다.

* 개발초기에 Code Review가 없었다.
각자 모듈을 어느정도 개발하고 통합하려고 보니 심각한 문제가 발생했다. 중요한 통신 모듈 코드가 생각보다 복잡하고 확장하기 힘들게 개발된 것이다. 그 분야에 개발경험이 없는 개발자에게 무턱대고 일을 시킨 결과 원하는 품질의 코드가 나오지 않은 것이다. 미리 미리 코드 리뷰를 거쳤다면 초기에 해결될 문제를 결국 거의 다시 개발할 수 밖에 없었다.

이 책을 보면 위와 같은 문제에 관해 이미 잘 나와있었다. 아마 소규모 개발업체의 많은 개발자가 이런 문제에 직면하고 있을 것이다.

아래와 같이 소프트웨어의 특성을 안다면 위와 같은 실수는 되풀이하지 않을 것이다.

소프트웨어의 특성
1. 프로젝트의 성공은 초기에 얼마나 빨리 코딩하는기에 달려있지 않다.
2. 결함수를 비용과 일정과 맞바꿀 수 없다.
품질에 집중하라. 이를 위해 테스트 & review를 통해초기 버그를 줄여라
3. 은빛 총알은 프로젝트에 유해하다
방법론(CMM, RUP)이나 기술을 너무 믿지 마라. 모든 것을 해결해주지는 않는다.
4. 건성으로 프로세스를 개선하는 것은 유해하다
5. 소프트웨어는 소프트하지 않다. 소프트웨어를 소프트하게 만들기 위해서는 비용이 더 든다.

다음에 계속...

참고문헌
* Professional 소프트웨어 개발, 스티브 맥코넬, 2003