이미 많은 분들이 Joel Spolsky가 운영하는 http://www.joelonsoftware.com/에 한번쯤은 방문을 하셨을 것이라고 생각합니다.

제가 알고 있는 수 많은 블로거(Blogger) 중에서 가장 소프트웨어에 대한 사상과 깊은 경험을 바탕으로 우리에게 많은 시사점을 던저주는 아주 좋은 포스트를 작성하시는 블로거입니다.

영어에 익숙하시지 않으신 분들은 아마도 안철수연구소에서 Joel의 포스트를 번역해 놓은 http://korean.joelonsoftware.com에 가보시면 그의 좋은 글들을 확인할 수 있습니다.

- Joel의 블로그: http://www.joelonsoftware.com/
- Joel의 한글 블로그: http://korean.joelonsoftware.com (안철수연구소에서 번역함)

아마 제가 Joel의 블로그를 접한 것은 4년여가 넘어가는 것 같습니다. 한 지인이 메신져로 알려준 Joel의 블로그에서 소프트웨어에 대한 새로운 생각들을 접할 수 있었습니다.

특히 풍부한 경험과 깊은 통찰을 통하여 작성된 하나 하나의 포스트들이 참 제 마음을 흔들어 놓았습니다.
가끔 Microsoft의 Windows에 신랄한 비판과 함께 조금 더 사용자를 위한 소프트웨어를 좋은 인터페이스와 효과적인 개발을 할 수 있는 방안에 대한 글들은 소프트웨어를 개발하는 저와 같은 사람의 마음을 흔들어 놓습니다.

간단하게 제가 재미있게 살펴본 Joel on Software의 내용중 일부를 소개할까 합니다.

조엘 테스트(Joel Test)라는 아주 흥미롭고도 간단한 테스트가 있습니다.
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(무작위 사용성 테스팅)을 하십니까?

출처: http://korean.joelonsoftware.com/Articles/TheJoelTest.html

본 질문에 대하여 간단하게 Yes or No로 답하시면 됩니다.

이 Joel Test의 목적은 어느 회사나 조직에서 얼마나 효과적으로 소프트웨어를 만들어 낼 수 있는지를 측정하는 것입니다. 대략 Yes가 10개 정도 나오시면 제 생각에는 아주 훌륭한 소프트웨어 개발 환경이 구축되어 있다고 생각됩니다. Microsoft와 같은 회사는 Joel의 말에 의하면 12개 만점을 받는다고 하네요.

저희 회사의 경우 현재 5점정도 받는 것 같습니다. 10점 이하면 심각한 수준이라고 Joel은 이야기하는데 문제입니다.  :-(

저와 같이 개발도 하면서 일정 부분은 관리도 하는 중간 레벨의 개발자에게는 의미있는 테스트인 것 같습니다. 물론 Joel도 소개하는 Software Engineering Measurement and Analysis (SEMA)와 같은 훌륭한 측정방법이 있지만 너무 어렵다는 단점이 있습니다. 하지만 Joel Test는 매우 간단하게 회사나 조직의 장단점을 측정할 수 있습니다.

Joel on Software 책을 사신 분들은 더 정확하고 풍부하게 Joel Test에 대한 글을 읽어보셨겠지만, 현재 책이 없으신 분들의 경우 http://korean.joelonsoftware.com/Articles/TheJoelTest.html 에 가시면 Joel Test의 대한 한글 문서를 보실 수 있습니다. Joel이 작성한 영문 원문은 http://www.joelonsoftware.com/articles/fog0000000043.html 에서 확인하실 수 있습니다.


제가 Joel on Software 책을 읽으면서 통쾌하고 정말 하고 싶었던 이야기가 있었던 장이 "화성인 아키텍트를 조심하세요"라는 장입니다.

최근 아키텍처(Architecture)가 매우 중요해짐에 따라 아키텍트(Architect)의 역활이 매우 중요해지고 있습니다. 특히 SOA(Service Oriented Architecture)와 같이 이해하기 난해한 아키텍쳐들이 나옴에 따라 아키텍처 구성이 매우 어려워지고 있습니다.

이러한 시대에 가끔 아키텍트란 분들이 뜬 구름을 잡을 때가 있습니다. 알 수 없는 최신 기술을 바탕으로 얼기 설기 아키텍처를 구성하여 개발자들과 설계자들 뿐만 아니라 사용자들도 쓰기 힘든 아키텍처가 구성되는 경우를 종종 봅니다. 저의 경우에도 최근 Web 2.0의 중요성에 따라 OpenAJAX나 OpenSAM이라는 조금은 이해하기 힘든 기술을 바탕으로 아키텍처를 구성하시려는 분 때문에 조금 고생을 하고 있습니다. 물론 의미는 있을 수 있지만, 덜 익은 사과를 덥썩 먹어치우려고 한다는 생각이 듭니다. 잘못하면 배탈이 날 수 있거든요.

제 생각에는 아키텍처는 명확하여야하고 각 구성 요소의 역활을 분명하여야하며 간결한 코드로 표현되어 효과적으로 수행될 수 있어야 좋은 아키텍처라고 생각합니다.

무조건 최신기술이나 사상도 분명하지 않은 기술을 짬뽕한다고 하여 어플리케이션이 훌륭하게 구축되지는 않는다고 생각합니다. 그런 면에서 저는 거의 모든 기술을 도입할때 PoC(Prove of Concept)를 수행합니다.
간단하게 개념을 검증하자는 의미인데요, 결국 비즈니스나 어떠한 기능을 수행하기 위하여 어플리케이션은 존재합니다.

저는 새로운 Open Source를 도입하거나 기존의 기술이라고 하더라도 제가 하는 프로젝트에서 원하는 기능을 효과적으로 수행할 수 있는 최적의 솔루션(Solution)인지 검증을 합니다. 비교할 수 있는 대안의 기술이 있는지도 확인해보고 필요하다면 BMT(Bench Mark Test)를 수행합니다.

이렇게 검증을 마친 기술들은 실제 프로젝트를 수행할때나 어플리케이션을 구축할때 분명한 목적을 가지고 도입하였기 때문에 대부분 훌륭하게 제 역활을 수행합니다.

하지만 화성인 아키텍트는 이러한 부분을 무시하는 경향이 있습니다. 최신 기술이라고해서 최신 트랜드라고 해서 무조건 도입하여 개발자들을 도탄에 빠뜨리죠 :-(

결국 개발자들의 경우 죽음의 행진(Death March)을 할 수 밖에 없고, 어플리케이션은 알 수 없는 문제를 지속적으로 야기시키면서 프로젝트는 망가집니다.

예전에 제가 참여했던 EJB(Enterprise Java Bean) 관련 프로젝트들이 화성인 아키텍트들이 만든 아키텍쳐 때문에 개발자들은 죽음의 행진을 할 수 밖에 없었다고 생각합니다.

이런 화성인 아키텍트들에게 Joel은 따끔하게 한마디 합니다.

위대한 화성인 여러분, 앞으로 화성에서 그냥 조용히 지내시면서 더이상 황금같은 제 시간을 낭비하지 말아주세요!

출처: 조엘 온 소프트웨어 번역판의 155페이지

어떠신가요? 전 점 통쾌하고 시원했습니다. ;-)

물론 모든 아키텍트들이 화성인 아키텍트는 아닙니다만 조금 더 실제적인 아키텍처를 구성하여야 한다는 Joel의 충고는 매우 의미있다고 생각합니다.


이 밖에도 Joel on Software에는 좋은 글들이 많이 있습니다. 블로그에서 확인하실 수 도 있고 번역된 책으로도 확인하실 수 있습니다.



한국어 번역판이 나온지도 좀 오래된 일이죠. 지하철이나 버스에서 시간나실때 한번쯤 읽어보시면 참 좋습니다.




아울러 More Joel on Software라는 Joel의 또 다른 책이 번역되고 있습니다. 현재 베타 리더를 모집하고 있습니다.

손영수님의 arload 블로그에서 모집중인데 Joel의 좋은 책을 조금 먼저 읽어보시고자 하시는 분들은 http://arload.wordpress.com/2008/11/03/more-joel-on-software/에서 베타리더를 신청하시기 바랍니다.

저도 신청했는데, 근사한 식사 대접도 있다네요 :-)

WRITTEN BY
jangsunjin
전세계 사람들의 삶의 질을 높일 수 있는 소프트웨어를 만들어 함께 나누는 것이 꿈입니다. 이 세상 그 무엇보다 사람이 가장 소중합니다.

받은 트랙백이 없고 , 댓글  2개가 달렸습니다.
  1. 저는 소프트웨어 개발 컨설턴트라서 많은 소프트웨어 회사의 개발자들을 만납니다. 그 때 조엘테스트를 종종 하곤 하죠. 그런데, 문제는 대부분의 개발자가 질문의 내용도 이해하지 못한다는 겁니다. 그냥 알아서 테스트 하라고 하면 꽤 높은 점수가 나오는데, 하나하나 내용을 물어 보면 문제를 전혀 이해하지 못하고 있고, 제대로 평가를 해보면, 0점, 1점, 2점이 수두룩합니다. 그이상은 거의 본적도 없습니다.

    소스코드는 CVS에 단순히 백업만 받으면서 어떻게 제대로 사용하는 줄도 모릅니다.

    한번에 빌드를 만들어낸다는 의미도 대부분 모르더군요. IDE에서 빌드를 하면서 메뉴에서 빌드를 선택하면 빌드가 한번에 되니 그것이 Yes인 줄압니다. 자동화된 빌드 스크립트에서 소스코드관리시스템과 연동하여 한번의 명령어 입력으로 소스코드를 태깅하고 가져와 빌드하고 팩킹까지 완료해야한다는 것을 모릅니다. 조엘의 의도는 이거거든요. 미국에서는 다 그렇게 하죠. 당연한거고.

    Daily Build빌드의 목적이 Broken Tree를 방지하기 위함인 것도 대부분 모르고, 자동의 해야 한다는 것도 모르는 것이 대부분입니다. 왜 해야 하는지도요...

    스펙서라는 것도 대부분 있다고 하는데, 실제 작성한 문서를 보면 전혀 스펙서가 아닙니다. 간단한 기능 목록이나 명세를 적어 놓고 스펙서라는 것이지요. Requirement와 Specification을 구분하지 못해서 발생하는 해프닝이기도 합니다. 대부분의 소프트웨어 회사에는 스펙서가 없습니다. 어떻게 쓰는 지는 거의 모르죠. 조엘의 의미는 적어도 제대로 작성된 SRS 정도의 문서를 말하는 거이죠.

    이렇듯 조엘 테스트는 상식을 가지고 있는 미국의 개발자를 대상으로 하고 있어서 우리나라 대부분의 개발자는 이해를 못하더군요. 미국의 개발문화와 우리의 개발문화는 엄청나게 다르거든요.

    그래서 제가 쓴 "소프트웨어개발의 모든것"이라는 책에서는 좀더 자세하게 한국의 실정에 맞게 좀더 풀어서 개발역량 테스트를 만든 적이 있습니다. 궁금하시면 여기를 참조하세요. http://softwaredev.tistory.com/3

    감사합니다.
    • 레이님 :-)
      좋은 댓글 감사드립니다.

      우리나라 소프트웨어 개발자에 대한 문제에 대한 댓글은 잘 읽어보았습니다. 저 역시 우리나라에서 일하는 개발자이기 때문에 여러모로 공감가는 부분이 많았습니다.

      특히 스펙 부분의 경우 매우 동감이 갑니다.
      저도 현재 저희 회사에서 아키텍트 역활을 하고 있는데 다행이도 스펙서를 잘 따르고 있습니다.

      우리 나라 개발자에 관한 개인적인 의견을 작성하고 있습니다. 특히 인도 개발자와 비교한 글인데 아직 작성을 완료하지 못하였지만, 추후 글을 모두 작성하면 알려드리겠습니다.

      그리고 좋은 글 잘 보았습니다. 좋은 책을 쓰신것 같은데 한번 읽어보고 싶습니다. :)

      나중에 읽게되면 블로그에 글 남기겠습니다.

      그럼 행복한 하루 보내시고, 자주 자주 들려주세요 ;-)
secret