겐도사마의 재림

며칠전에 "여러분야파기"란 글을 쓰고 나서 둘러보다 보니 써니님이 "이어쓰기놀이"에 재미(?)있는 글타래를 모아놓으셨고 "저는 여전히 코더(coder)입니다"에서 언급한 malefic님의 "꼭 그래야만 하는걸까요"에서 특히 그런데 그 책에서 말하는 훌륭한 알고리즘, 제대로된 프로그램, 이런 것들이 과연 현업에서 사용할 수 있는 지침이 될까요? 저는 그렇지 않은 것 같습니다. 제대로된 리스트를 작성하는데 시간을 쓰느니 MFC의 CList를 쓰거나, STL의 List를 쓰는 것이 훨씬 나은 걸요... 과연 진정한 프로그래머의 길은 구글 이나 MS 입사시험(?)에나 나온다는 이상무쌍한 알고리즘 찾기나 수수께끼 풀이에만 있는 걸까요?라는 부분을 보고 이전에 하고 싶었던 말을 하나 써 볼까 합니다. 우선 "코더로..

http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39169831,00.htm 특히 두번째 세번째에 해당한다. 말단이던 시절에는 개발자 개개인의 자기개발이 중요한 것은 인지하였지만 직급상승 이후에 장기적인 관점에서 보자면 개발팀, 조직의 능력 향상을 위해선 팀내 교육도 상당히 중요하다고 본다. 어떤 조직이 발전해 가는 것은 개개인의 능력이 증가되고 팀내 지식이 쌓이게 되어 조직의 능력 자체가 발전해 가는 것이라 본다. 당장의 프로젝트 수행을 위해선 "닥치고 일" 내지 "쥐어짜기"가 답일 수 있지만 장기적인 관점-특히 내가 속한 조직은 서비스를 계속 잡고 발전시켜나가는 곳이다보니-에서는 당장의 듀 보단 팀의 능력 발전은 매우 중요한 부분이란 생각이 든다. 그래..

전통적인 상하적인 조직에서는 비젼의 공유가 중요하였다. 총대를 맨 한사람 아래에 그사람의 의지를 공유한 사람들이 동일의 비전하에 일을 수행한다. 각 구성원의 공유가 잘 될 수록 일은 잘 진행될 가능성이 높다. 장점으론 공유의 코스트만 들인다면 이후 일사천리로 일이 진행될 수 있다. 단점은 집단이 동일한 시각을 가짐으로써 집단의 오류를 일으킬 가능성이 높다거나 정점의 사람의 판단에 의존성이 높다. 고전 게임중 하나인 "레밍즈" 처럼 잘 가이드된 쥐들은 무사히 목적지에 도착할 수 있지만 집단의 오류에 빠져 버리면 불구덩이속으로 집단은 달려가게 된다. 소위 "효율적인 도박"을 하는데 적절한 방법이라 볼 수 있다. 최근의 팀 구조나 Open Source Project에서 보여주는 방식은 구성원의 공감을 통한 진..

웹디자인 2.0 고급 CSS : 감각적인 웹디자인 예술 미학 앤더클락 지음, 정유한 옮김 에이콘 출판사 ISBN : 9788960770300 http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200801080001 http://www.acornpub.co.kr/blog/195 : ACORN 출판사의 글 갑자기 겐도가 웹디를 하겠다는 것은 아니고 저책을 예약 뜬거 보고 바로 주문한 것은 저 책의 2장 때문이다. 기존에 골수 시스템 프로그래밍만 했고 Network-IDS라는 일반인이 접근하기 힘든 제품을 만들다가 갑자기 웹 서비스를 만들다 보니 어떻게 일이 진행되는지 그리 익숙한 편은 아니다. 더구나 전통적인 웹페이지 만드는 기획은(홈페이지 알바할때 보던 바로 그!..

1. Code Review 최종적으로 Service에 Deploy 되기 전에 Review를 하는 것은 몇번 엄한 코드가 나갈뻔한 상황을 제어할 수 있었다. 형상관리툴(이 프로젝트에서는 SVN)을 사용하고 서비스 적용 전에 그 변화들을 확인해 가는 것은 품질 확인에 많은 도움이 된다. 다만 이것이 쌓여버리면 역시 터진다. 리뷰 시간도 줄어들고 작성자도 기억이 가물가물해 진다. 커밋 후 짧은 시간 안에 이루어 지는 것이 필수. 2. Ticket System/Issue Tracking Trac을 사용하였고 이는 현재의 사안들을 적절히 추적할 수 있게 한다. 과거를 따라 갈 수도 있다. 버그를 보고받고 재현하고 수정한다는 과정을 자연스럽게 확립할 수 있고 다시 이슈가 발생한 경우 많은 정보를 찾을 수 있다. 귀..

"거대 용량 시스템에서의 설계 이슈 from kaistizen" 에 대한 저의 대답입니다. 좀더 최적화 할 수 있겠지만, 그 프로젝트는 성공적이었다. 엔지니어가 할 수 있는 것은 "이렇게 하면 좀더 좋았지 않았을까요?"라고 말해보는 것이 전부일 것이다. DBMS를 파일 시스템 수준으로 사용하는 것은 어떻게 보면 거대한 낭비일 수 있습니다. 하지만 해당 프로젝트를 수행한 집단의 목적성에 비추어 볼 때 실패는 아니겠죠. 아니 성공입니다. 기한내에 해내었고 어쨌든 잘 돌고 있으니까요. 비용적인 측면이야 예산내로 했을테니 (다른 요소 다 가리고) 일단 프로젝트는 성공이 아닐까요? 문제의 관점을 어떻게 놓고 보느냐에 따라 많은 답들이 나올 수 있습니다. 엔지니어링 적 측면에서 최적의 해와는 너무나 거리가 먼 솔루..

한국에서 드디어 날라온 책. 아직 다 못읽어서 리뷰를 쓸 수 있는 단계는 아니지만 1장 대충 보면서 기억에 딱 남는 생각. 개발 일정은 zip이나 rar로 압축한다고 압축되는 것이 아님. 기능을 줄이는 것이 능사는 아님. 애시당초 그 기능이 필요 없었거나, 프로젝트 1차 마일스톤 이후 계속 해야 한다는 것. 총 시간은 늘어날 뿐이다. (1차 마일스톤 만드느라..) PS. 오늘 아침에 든 생각 프로젝트의 성공은 비단 제 기간에 뭔가 제품이 나오는 것 뿐만이 아니라 구성원 모두의 만족까지 포함해야 한다. 몇명 암걸리고, 이혼하고 등등 불행해지는 구성원이 있다면 그 프로젝트는 실패한 것이다. 고객만 행복하면 되는 것은 아니다. 어차피 제대로 수행되지 못한 프로젝트는 고객도 행복하지 못하다. 관계자 모두가 만족..

전통적인 그네 이야기가 있지만.. (갑자기 링크를 못찾겠음다;;;) http://www.loliparty.net/542 이버전이 더 가슴에 와닿는 당신은 오타쿠! PS. 추가. 아빠는 회사에서 무슨 일을 하세요

참고글 http://tapm.blogspot.com/2007/03/2-1.html : 인지적 견해: 소프트웨어 설계를 보는 다른 시각 제가 처음 컴퓨터를 배울때 바로 BASIC을 배웠습니다만 컴퓨터는 없이 문법을 설명하는 책 한권과 노트가 주어졌을 뿐입니다. BASIC이 어떻게 수행되는지 책은 저에게 설명해 주고 있었지만 그것을 돌려볼 수 있는 컴퓨터는 없었습니다. 그래서 전 제 스스로가 컴퓨터가 되기로 하였죠. 86년도에는 다행이 요즘처럼 그렇게 복잡한 개발환경을 요구하지도 않았고 초등학교 2학년생이 그런 프로그램을 작성할리도 없었기에 노트에 적혀진 BASIC 코드를 따라가는 것은 그리 어려운 작업은 아니었습니다. 89년도에 GW-BASIC을 배울때도 학원에서 일부러 진도를 느리게 만들려고 했는지는 모..

우선 동기의 글 연휴동안 한 일 - 설계를 문서화 하기... from 써니의 一生牛步行 태생이 시스템 프로그래머(System Programmer : 이후 SPer)요 웹쪽을 한지 이제 만 1년이 된 상황에서 저 글을 본 후 뭔가 부자연스러움을 느꼈다. UI화면에서 어떻게 상세기획서급의 문서가 나오는가에 대해서다. 이말에 동감을 하는 쪽이라면 SPer이요 당연하다고 느낀다면 웹 개발쪽을 많이 한 사람일 가능성이 높다고 본다. 최근에 웹 기획자랑 서로 외계어(!)로 대화를 했고 서로가 서로를 이해 못했었는데 현재의 가정이 맞다면 당연히 서로 100만 광년을 떨어져서 이야기 한 셈이라고 본다. 틀리면 다시 머리 싸메고 분석해야 하는 것이고. 웹 기획자란 구글을 뒤져보니 이런 링크를 찾았다. 웹 기획자가 하는 ..