겐도사마의 재림

며칠전에 "여러분야파기"란 글을 쓰고 나서 둘러보다 보니 써니님이 "이어쓰기놀이"에 재미(?)있는 글타래를 모아놓으셨고 "저는 여전히 코더(coder)입니다"에서 언급한 malefic님의 "꼭 그래야만 하는걸까요"에서 특히

그런데 그 책에서 말하는 훌륭한 알고리즘, 제대로된 프로그램, 이런 것들이 과연 현업에서 사용할 수 있는 지침이 될까요?

저는 그렇지 않은 것 같습니다.

제대로된 리스트를 작성하는데 시간을 쓰느니 MFC의 CList를 쓰거나, STL의 List를 쓰는 것이 훨씬 나은 걸요...

과연 진정한 프로그래머의 길은 구글 이나 MS 입사시험(?)에나 나온다는 이상무쌍한 알고리즘 찾기나

수수께끼 풀이에만 있는 걸까요?

라는 부분을 보고 이전에 하고 싶었던 말을 하나 써 볼까 합니다.

우선 "코더로서 적응해 간다는 것"에서 언급했던 TnC 면접 문제이야기를 해야 할 것입니다. 가끔 왜 이런 것을 질문하느냐, 소팅이 뭐가 중요하냐란 질문을 받곤 합니다. 그런경우 저의 답은 이렇습니다.

천만명이 시험을 봤습니다. 0점부터 100점까지 점수를 받았겠죠. 석차를 내야 합니다. 소팅에 대한 이해가 없는 사람은 그냥 DBMS상에서 "ORDER BY 점수" 하고는 차례대로 석차를 붙여 줄껍니다. 이론적으로 nLogn에 할 수 있겠죠. 비싼 써버 사달라고 해서 구현하면 되긴 하죠. 매번 소팅 안하고 필드를 만들어서 기록해 두는 것을 생각해 내는것만으로도 대단하다고 해야 할껍니다. 가끔 점수가 잘못 입력되어 정정해야 할 일이 있을 텐데 뭐 매번 소팅할껍니다. 응시자가 1억명이 안넘은 것에 감사하겠죠.
허나 저는 이것을 n에 풀 수 있어요. 점수가 끽해야 101개 밖에 없자나요. 각 점수별로 몇명있는지 카운팅 하면 점수만으로 몇등인지 알 수 있어요. 수정상황? 어떻게 하면 될지 대충 상상이 되지 않나요? 대단한 생각도 아니죠. 이런 생각은 Data Structure(데이터구조) 수업시간에 제대로 들은 사람이라면 충분히 할 수 있는 거죠.

컴퓨터가 뭐냐고 한다면 그저 계산을 빠르게 하는 기계일 뿐입니다. 사람보다 엄청나게 빠르게 가감승제를 빨리 할 뿐입니다. 반대로 빨리 하는 것이 컴퓨터의 숙명이기도 하구요. 그리고 지시를 내리는 것은 사람입니다. 사람이 어떻게 명령을 내리냐에 따라서도 상당한 차이가 발생하죠. 언어라는 것이, 가령 영어학원에 좀 다니면 영어는 할 수 있지만 소설을 쓸 수 있는 가는 또다른 것이 되듯, 뭐 PHP로 코딩 가능한 사람이야 충분히 구할 수 있고 아무나 데려와도 1년동안 학원 보내주면 할 수 있을 것입니다. 그러나 회사의 제품을 좀더 좋게 만들 수 있는 사람을 찾아야 할 것이고 결국 면접을 제대로 통과한 사람은 없었지만 이런 것들을 중요시 했던 분위기는 제품에 좋은 영향을 주었다고 자신합니다.
자신이 프로그래머 나부랭이라고 한다면 자기가 컴퓨터에게 무슨 일을 시키고 있는가에 대한 이해는 반드시 있어야 한다고 생각합니다. 다시는 어셈블리어를 짤 일이 없다고 해도 메모리가 어떻게 운영되고 하드에선 대체 어떻게 데이터를 들고 오며 락을 걸면 시피유는 어떻게 미쳐버리는 가에 대한 이해는 필요할 것입니다. 이런 지식들이 있어야 꼴딱꼴딱 숨넘어 가는 시스템을 세상에서 구할 수 있습니다.

CS 4년동안 배우는 것이 정말 쓸모없는 것이라면 대학들은 다 문닫는 것이 맞겠죠. 코딩이랑 전혀 상관 없을 것 같은 컴퓨터 구조 같은 과목조차 모두 다 필요한 지식입니다. 모든 지식들을 다 쓰지 못할 수는 있겠습니다만(특히 전공 선택쯤 되면) 적어도 기초필수로 배우는 것은 항상 따라다녀야 할 지식들입니다. 암기식으로 소팅에는 버블, 인서션, 셀렉션, 퀵, 머지가 있다고 외우고 있는 것은 물론 의미 없습니다. 각각들이 뭔지를 정확히 알고 있어야 지금 상황에서 뭘 써야 하는지를 선택할 수 있습니다.

STL의 List나 Hash 관련 라이브러리들은 정말 강력합니다. 많은 프로그래머들이 고심해서 조이고 닦고 해서 만든 거죠. 많은 사람들이 그냥 가져다 쓰면 되는 툴이라고 생각합니다만 라이브러리가 그런 것은 아닙니다. 그저 자주 나오는 문제에 대해 타이핑 또 할 필요없이 가져다 쓸 수 있는 코드일 뿐입니다. 그런 형태의 데이터 구조를 써야 한다고 판단하는 것은 똑같이 해야 한다는 것입니다. 현재 다루어야 하는 데이터의 특성은 어떨까, 그리고 이것을 통해 어떤 특성을 가진 데이터 구조를 사용해야 할까. 더불어 그 라이브러리를 쓸때 어떤 식으로 붙여줘야 가장 잘 동작할까. 이런 것들을 고민해야 합니다. 임의의 데이터 찾는데 Hash가 좋다고 그 템플릿을 무조건 쓰는 사람들이 있습니다. 키가 특수하다면 어레이가 훨씬 좋을 수 있고, 또한 Hash가 뭔지에 대한 이해가 있어야 Hash Function을 디자인 하고 버킷 수를 지정할 수 있습니다.

이미 주어진 툴들이 많은데 왜 밑바닥 부터 고민하느냐고 생각할 수 있습니다. 당장 프로그램을 내일까지 완성해야 하는데 그런 쓰잘데기 없는 고민을 하냐고 말할 수도 있습니다. 허나 이런 상황을 여러번 겪는다고 생각해 봅시다. 단박에 생각한다고 문제가 쉽게 해결되지는 않습니다. 하지만 계속 조금씩 더 생각을 하고 노력하다 보면 언젠가는 좀더 프로그램이 안정해 지고 빨리 퇴근할 수 있게 되거나 더 기능을 추가해서 단가를 올릴 수 있겠죠.
아르바이트를 쓸때는 저조차도 잡생각(?)하고 있으면 경고를 하겠죠. 빨리 완성하라고. 사실 주는 부분도 금방 버릴 부분입니다. 장기간 사용해야 할 부분이고 정직원으로 계속 일할 사람이라면, 반대로 생각없이 들고오면 혼낼껍니다.

신기술, 중요하죠. 새로운 언어를 습득하고 새로운 개념을 배우고 새로운 툴의 사용법을 익히는 것은 중요합니다. 허나 본질의 이해를 놓치고 그것만이 중요하다고 이야기 한다면 문제가 있는 것으로 보입니다. 그것만큼이나 중요하고 "여러분야 파기"글에서도 언급했듯이 본질의 이해를 통해 새로운 것을 좀더 빠르고 정확하게 습득할 수 있습니다.

~~~~~

'G'회사에서 낸다는 이상한 문제들에 대해서도 언급해 봅시다. 몇가지 문제를 보고 이놈의 회사는 수수께끼만 내는거 아닌가란 생각을 할지도 모르겠습니다. 그러나 그 회사의 검색을 통해 문제들을 많이 찾아 보십시오. 단순히 수수께끼 책 몇권 읽는 다고 절대 합격할 수 없습니다. 사실 그 수수께끼들 조차 원래 의도는 다른데 있을 것입니다.

참고로 그 회사의 면접문제들을 보고 대체 의도가 뭔지를 발견하는 것은 합격 확률을 높이는 방법 중 하나랍니다. :)

~~~~~

글들을 보다가 마치 아키텍터는 코딩 안하는 것처럼 언급이 되어 있던데, 뭐 컴퓨터 앞에서 C코드를 작성하지 않을 수 있습니다만, 저는 언어의 차이일 뿐이라고 이야기 합니다. 누군가는 Java로 프로그래밍을 하지만 누군가는 UML로 할 뿐입니다. 뭐 누군가는 술로 하구요.
더불어, 제가 태어나기도 전부터 프로그래밍을 하셨고 정말 아키텍터라 불리실 분들도 C 코딩을 하는 경우도 있습니다. 취미생활 제외하고도, 자신이 생각하기에 정말 중요한 부분이다라고 생각이 들고 직접 손봐야 하는 곳이라고 판단된다면 손을 대죠.
훌륭한 아키텍터는 자신의 산출물이 완성되는 순간 각 부분이 어떻게 통신을 하고 있고 이쯤에선 이런 알고리즘과 데이터 구조를 사용하고 있을 것이라는 모습이 눈에 선할 것이라는 것이 저의 생각입니다. (컨설턴트 말구요 아키텍터요;;;)

~~~~~

알고리즘도 모르면 코더도 아니냐?라고 하신다면 그건 아닙니다. 코더의 정의에 그런게 들어 있을리 없죠. 좀더 잘하는 방법에 관한 것입니다. 뭐 높은 연봉을 받는 방법이라고 할수도 있고 자기만족도를 높이는 방법이라고도 할 수 있습니다. 시간은 세이브 못합니다. 효율적이 되면 일의 양이 늘어서 결국 시간은 같은거 같아요. 또한, 저런 방법만 있는 것도 아닙니다. 높은 연봉을 받는 방법으로 다른 방법도 많으니까요.

(RSS 구독자 분들은 제외하고) 링크를 타고 흘러 흘러 여기까지 오신 분이라면 이런 저의 인생관(?)도 들어 볼만하다란 생각으로 적어봅니다. 그리고 "써니님의 블로그"에 요즘 주옥같은 글들이 올라오고 있는 듯 합니다. 미투로 도배중인 제 블로그보단, 저 블로그 강력 추천합니다.

http://www.zdnet.co.kr/news/enterprise/etc/0,39031164,39169831,00.htm

특히 두번째 세번째에 해당한다.


말단이던 시절에는 개발자 개개인의 자기개발이 중요한 것은 인지하였지만 직급상승 이후에 장기적인 관점에서 보자면 개발팀, 조직의 능력 향상을 위해선 팀내 교육도 상당히 중요하다고 본다.

어떤 조직이 발전해 가는 것은 개개인의 능력이 증가되고 팀내 지식이 쌓이게 되어 조직의 능력 자체가 발전해 가는 것이라 본다. 당장의 프로젝트 수행을 위해선 "닥치고 일" 내지 "쥐어짜기"가 답일 수 있지만 장기적인 관점-특히 내가 속한 조직은 서비스를 계속 잡고 발전시켜나가는 곳이다보니-에서는 당장의 듀 보단 팀의 능력 발전은 매우 중요한 부분이란 생각이 든다. 그래야 다음 사이클에서 좀더 속도가 날 수 있고, 그 다음 사이클엔 좀더 많은 것을 할 수 있고, 그다음엔 획기적인 것도 도전해 볼만해 진다.

단순히 학원 수강료 지원해 주는 차원은 아니다. 선임급 연구원이라면 다른 연구원들의 "Mento" 역할을 할 수 있어야 하고, 누군가 배우거나 연구하거나 발명해 낸 것은 그 조직안에서 쉐어링이 필요하다.

회사의 성장은 아직 CEO질을 안해봐서 모르겠고, 적어도 팀의 지속적인 성장은 다음 프로젝트, 다음 시기가 올 수록 가치는 높아지고 새로운 과실을 열리게 만드는 중요한 거름이라 생각된다.

사람 개개인은 이직도 하고 그럴 수 있지만 팀에 녹아내리는 지식은 중요한 회사의 자산이 될 수 있다고 본다.

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

최근의 팀 구조나 Open Source Project에서 보여주는 방식은 구성원의 공감을 통한 진행이다. 오늘 Textcube 1.7이 발표되었는데 이 프로젝트의 구성원인 TNF의 경우 이 방식의 장단점을 본인이 잘 볼 수 있는 케이스중 하나이다. 가령 포럼에서 누군가 의견을 제시하더라도 그것이 실제 TC에 적용되기 위해선 많은 사람들의 공감을 요구한다. 조직의 수장이라 할 수 있는 정규님도 기능을 다 구현하고도 공감을 얻지 못하면 roll-back을 당한다. 새로운 커밋터(Commiter - 코드를 직접 수정할 수 있는 권한을 가진 사람)을 선출함에도 그 방식에 대해 리딩을 하는 사람은 있어도 최종 방법이 나오기 까진 많은 논의와 공감과 동의을 필요로 한다. 의사 진행은 느릴 수 밖에 없지만, 대신 구성원들의 노력을 최대한 끌어 낼 가능성이 높다던가 한 문제를 두고 다양한 시각을 통한 문제 해결을 도모할 수 있다는 방법이 있다. 물론 집단의 오류에 여전히 빠질 수 있다. 집단의 특성 혹은 대다수를 차지하는 구성원의 특성에 의해 집단의 시각이 고정될 수 있기 때문이다.

후자의 방식은 관리자의 입장에선 매우 곤란해질 가능성이 높은 조직이다. 구성원들의 공감에 얼만큼의 시간이 소모될 지 예측하기 힘들기 때문이다. 또한 열정을 가진채 탄생하였다면 몰라도 그저 소집된 인원이라던가, 혹은 장시간이 가져다 주는 피로감에 열정이 식어버리면 원래 조직의 가져야할 장점들은 다 사라져 버리고 어중간한 전자의 조직 형태를 뛰게 될 수 있기 때문이다. 양쪽의 단점만을 취한채 "죽음의 행진"을 시작할지도 모른다.

공감 기반의 조직에 좀 더 끌리는 것은 개인적인 경험에 따른 것일지도 모른다. 첫 프로젝트부터 3~4인의 팀프로젝트부터 하였고, 대학의 많은 강의들에서도 3명 정도의 팀프로젝트를 많이 하였다. 회사에서는 "1 리더 + 3인방" 체계로 개발을 하였다. 자신의 생각을 끊임없이 구성원들에게 검증받으려는 노력이었겠지만 자연스레 의견이 첨가되고 문제점들이 수정되어 나간다. 더불어 최근 몇년간 이런 형태에 대해 좀더 생각해 보게 된 것은, 현대의 프로젝트는 혼자의 힘으론 할 수 없을 뿐더러 현대의 프로덕트는 한사람의 머리로 완벽한 모습을 그려 내기 보다는 다양한 머리가 동원되어야 확률이 올라갈 것이라는 생각이 들어서이다. 적어도 확실한 것은 나의 지식이나 경험조차 편항되어 있고 모든 케이스를 알고 있고 모든 시야를 볼 수 있는 사람이 존재할 확률은 극히 낮을 것이라는 가정때문이다. 아무리 뛰어난 사업가라도 개발적인 부분에서 나보다 뛰어날 확률은 높지 않을 것이다. 분업이라는 현대사회의 개발시스템 특성상 한 사람이 모든 부분을 잘하긴 힘들기 때문이다. 그리고 분야별 전문가가 존재하는 이유도 그럴 것이다.

공감시스템에 참여하는 단위는 3~4개가 적당하지 않은가 한다. 한번에 고민하는 인원이 저정도가 적당할 것으로 보인다. 전체적인 구조는 상황에 따라 병렬 팀 구조나 수직적 트리구조를 가질 수 있다. 중간 리더급 인력이 3~4개의 단위(팀)에 참여해서 공감된 내용을 위로 들고 가서 논의하거나 위에서의 내용을 아래에서 공감작업을 할 수도 있다. 조직의 25% 정도가 공감작업에만 소모될 가능성도 있지만 파티셔닝을 통하여 해당 조직의 사이즈를 적절히 조정한다면 공감작업의 코스트가 10% 미만까지도 떨어지지 않을 까 하는 생각이 든다.

최근 낙하산 브레인에 쓴맛을 본 모 조직이나, 잘나가는 외국계 그 기업을 볼때(더불어 보아온 케이스 등등등) MS의 "빌 아저씨"의 시대는 가고 공감조직이 분명 성공 확률을 높이는데 좋지 않은가 한다. 물론 "스티브 아저씨"의 기업이 절대적이지는 않음을 보여주고 있긴 하지만 말이다.

일단 내가 슈퍼맨-모든 분야에 전문가가 아니라는 사실, 그리고 많은 공감 모델을 통한 장점을 맛본 나로서는 손이 갈 수 밖에 없지 싶다.

웹디자인 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라는 일반인이 접근하기 힘든 제품을 만들다가 갑자기 웹 서비스를 만들다 보니 어떻게 일이 진행되는지 그리 익숙한 편은 아니다. 더구나 전통적인 웹페이지 만드는 기획은(홈페이지 알바할때 보던 바로 그!) 더이상 서비스 개발 과정을 제대로 담아내지는 못하는 것 같고 대체 이세상 사람들은 어떻게 하고 있나 궁금하던 차에 유사한 내용이 보이는 것 같아 이 책을 구입하였다.

기획 디자이너가 PSD(Photoshop 파일)를 만들어 던지면 HTML 코더가 1px도 안틀리게 만들어야 하는 매우 전통적인 회사 홈페이지를 만드는 방법을 웹서비스를 만드는데 사용중이라면 저책의 2장을 참고할만 할것이다. 사실 힌트는 이번에 출시된 Microsoft Office 2008 for MAC이다. 어디선가 이 제품의 UI 디자인 기획서를 봤었고(어딘지는 기억이 나지 않는다. --;) 비슷한 것을 웹에서도 사용중이라고 알고는 자료를 찾고 있었다. UML 다이어그램 예제라면 하다못해 본인이 직접 그리겠지만 디자인 혹은 UI기획의 경우 워낙 젬병인 분야라 냄새만 겨우 맡고 있다. 아무튼 그 비슷한 컨셉들이 저 책의 2장에 나온다. 바로 Grey box.

자세한 것은 책을 사서 보시라! (출판사에 굽신굽신;; )

아무튼 이것은 단순히 디자인 파트에게만 국한된 내용은 아니다. 코웍해야 하는 모든 관계자는 알고 있어야 할 것이다.

PS1.
사실 이 분야 전문가가 아니라 위의 말을 얼마나 확신해야 할지는 모르겠다. 누군가의 가르침좀 받아야 되는데.

PS2.
내용을 대충 읽어 보면서, Hack을 가능한 쓰지 않거나 IE6, 7을 지원할 때 조건 CSS를 사용해라 등의 내용을 보면서, 사실 Tattertools(현재의 textcube)나 Tistory를 작업할때 심사숙고 후 그렇게 결정했었는데 역시 그게 맞군이란 위안(?)이 든다.

1. Code Review
최종적으로 Service에 Deploy 되기 전에 Review를 하는 것은 몇번 엄한 코드가 나갈뻔한 상황을 제어할 수 있었다. 형상관리툴(이 프로젝트에서는 SVN)을 사용하고 서비스 적용 전에 그 변화들을 확인해 가는 것은 품질 확인에 많은 도움이 된다.
다만 이것이 쌓여버리면 역시 터진다. 리뷰 시간도 줄어들고 작성자도 기억이 가물가물해 진다. 커밋 후 짧은 시간 안에 이루어 지는 것이 필수.

2. Ticket System/Issue Tracking
Trac을 사용하였고 이는 현재의 사안들을 적절히 추적할 수 있게 한다. 과거를 따라 갈 수도 있다. 버그를 보고받고 재현하고 수정한다는 과정을 자연스럽게 확립할 수 있고 다시 이슈가 발생한 경우 많은 정보를 찾을 수 있다.
귀차니즘이 문제라고 큰 이슈임에도 한 이슈로 뭉쳐서 처리해 버리는 경우 정보가 부족해 질 가능성이 높다.

더불어 형상관리시 Ticket과 연관이 있어야만 code의 commit을 가능토록 강제하였다. 트랙킹이 좀더 강력해 진다. Trac은 SVN과 연동이 되므로 평소에 약간만 수고해 주면 트랙킹이 무척이나 편해진다. 허나 가짜 Ticket을 만드는 등의 오용 사례가 있었으니 주의. (나조차도 ㅠ.ㅠ)

3. 땜빵 곱하기 땜빵은 땜빵
실 서비스를 한다는 특성상 땜방의 연속은 어쩔 수 없는 숙명일지도 모른다. 허나 분명 프로젝트 기간동안 보면 정공법이 역시나 뒷탈이 없었다. 일정상 땜빵을 선택한다고 했을 때, 그 이슈가 풀린다고 바로 잊어 버리면 안되는 것이 중요한 것 같다. 실리콘으로 일단 금을 보수 했으면 다시 정석으로 금의 원인을 분석하고 대응 방안을 제대로 고민하는 것이 좋다. 바쁘다고 뒤로 미루면 역시 실리콘 떨어진다.

4. 버그 회귀성
단위테스트 시스템을 아직 도입하지 못하였기에 역시 발생하는 문제인것 같다. 과거의 버그가 재발되는 경우도 종종 있었다. 같은 위치에서 발생하는 것보다도, 비슷한 모듈에서 동종의 버그가 발생되는 것이 사실 크다. 이는 단위테스트에서 충분히 커버할 수 있는 것들이다.
적극 도입을 검토할것.

5. 과감한 리팩토링
일정상의 이유로 전면적인 수정은 주저하게 된다. 그리고 그것은 끊임없는 밤샘의 원동력이 된다. 시간이 나는데로 쓸데없는 상상하지 말고 즉각즉각 유지보수하자.

"거대 용량 시스템에서의 설계 이슈 from kaistizen" 에 대한 저의 대답입니다.

좀더 최적화 할 수 있겠지만, 그 프로젝트는 성공적이었다. 엔지니어가 할 수 있는 것은 "이렇게 하면 좀더 좋았지 않았을까요?"라고 말해보는 것이 전부일 것이다.




DBMS를 파일 시스템 수준으로 사용하는 것은 어떻게 보면 거대한 낭비일 수 있습니다. 하지만 해당 프로젝트를 수행한 집단의 목적성에 비추어 볼 때 실패는 아니겠죠. 아니 성공입니다. 기한내에 해내었고 어쨌든 잘 돌고 있으니까요. 비용적인 측면이야 예산내로 했을테니 (다른 요소 다 가리고) 일단 프로젝트는 성공이 아닐까요?

문제의 관점을 어떻게 놓고 보느냐에 따라 많은 답들이 나올 수 있습니다. 엔지니어링 적 측면에서 최적의 해와는 너무나 거리가 먼 솔루션은 나쁠 수 있습니다. 좀더 고민해 보면 "아름다운 아키텍처"가 있을 것인데 그건 고려치도 않고 대충 얼버무린 것은 끔찍한 코드를 집단적으로 작성한 것으로 여길 수도 있습니다.

순수한 엔지니어는 돈 못버는게 이런 이유가 아닐까요? 만약 이베이와 선이 새로운 DBMS를 만들려고 했다면 아마 아직도 하고 있을지 모릅니다.

반대로, 구글이나 몇 회사들 처럼 직접 구현한 회사들은 아름다운가에 대해 고민해 보면, 물론 최적의 성능을 끌어 낼 수는 있었겠지만 지금의 상황이 아닌 초창기의 상황을 보자면 시중에 좋은 구현들 많은데 돈도 많으면서 그런거좀 사지 왜 구지 만들었냐라고도 할 수 있습니다. 자신이 최적이 코드를 만들 수 있을지 몰라도 프로젝트 전체에서 보면 직접 구현이 항상 최적은 아닐 수 있죠.

항상 프로젝트 단위로 혹은 회사 단위로 생각해 볼때 엔지니어적 아름다움이 전부여서는 안될 것입니다. 반대로 단위 프로젝트의 경제성만이 전부는 아닙니다. 그렇게 놓고 보면 지금의 구글은 없었죠. stakeholder들이 무엇을 얻는가만이 중요할 것입니다.

대형 서비스업체가 SI기업에게 발주를 하였습니다. 그 프로젝트에서 "OO할아버지DBMS"를 직접 구현하여 초당 1조개의 데이터를 처리하게 만들었다~~라고 선전할 수도 있겠지만 두 기업은 무엇을 얻을까요. 그저 초당 1억개 정도만 처리하면 충분했었는데 말이죠.

상용DBMS를 사는 이유는 단순히 그 제품의 Full Functionality를 보고 사는 것은 아닐 것입니다. Feature List중 과연 몇%가 해당 프로젝트에 도움이 될까요. 제품을 구입한 곳은 가격을 지불합니다만 그 가치비교 대상은 Full List가 아니라 Sub List일 것입니다. Stored Procedure로 구현하면 물론 빠르겠지만 비베로 대충 짠 코드로도 충분한 성능이 나오면 구지 SP로 작성할 필요가 없을 것입니다. 오히려 다른 이슈들이 고려되겠죠. 마이그레이션이 예가 될 수도 있습니다. 비싼 상용툴을 산 이유는 업체 관계자랑 술을 마셨을 수도 있겠지만 AS나 기술지원을 봤을 수도 있습니다. 뭐 개인적으로는 순전히 브랜드에 대한 느낌 만으로, 돈과 관련된 내용은 Oracle이 아닌 곳에는 저장하지 않겠다라고 한적도 있습니다. 의사 결정자의 가격대비 효용가치를 판단할때 기존의 구현이 나쁘다고 보이지는 않습니다.

구글 케이스는, 그들은 자신의 시스템을 직접 구축함으로써 기업의 벨류를 쌓았습니다. 그것이 중요하였기 때문이겠죠.



검증되지 않은 기술을 실전에 사용하는 것은 이른바 "SI 프로젝트"에서는 자살행위입니다. 프로젝트의 성공가능성을 매우 낮추는 행위기 때문입니다. 벤처야 프로젝트 몇개 날려도 잃을 것이 없겠지만 대형 발주 하나 펑크 내고 패널티 몇달 들어가면 끝장입니다. 안전빵으로 가는게 최고입니다. 반대로 벤처의 경우 투자대비 아웃풋을 극대화 시켜야 하기 때문에 모험을 해야 할 것이고 그래서 벤처겠죠.

PS1.
어느날 갑자기 NHN이 자사의 모든 서비스를 Ruby로 재작성 하겠다고 발표했다고 칩시다. 이유는 "신규기능 확장이 너무 편해요"라고 하죠. 그렇다면 두가지 추측을 해볼만 합니다. 현재 시스템에 대한 미련을 버리고 과감한 변신을(심지어 회사의 사운을 건) 시도하는 것이거나, 대장이 지독한 변비에 걸렸나 보다 정도.

PS2.
개혁은 소규모 프론티어들에 의해 서서히 진행되는 거겠죠. 혁명을 해 버리면 누군가 피를 봐야 하고 후유증이 남고 결론적으로 좋아진건지 판단하기 더 어려워 질 것입니다. 개혁이 사회에 반영되어 기존의 구성원들도 따라 움직이게 만들어야 겠죠.

한국에서 드디어 날라온 책.

아직 다 못읽어서 리뷰를 쓸 수 있는 단계는 아니지만 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을 배울때도 학원에서 일부러 진도를 느리게 만들려고 했는지는 모르겠습니다만 일단 순서도(Flow Chart)를 그리고 노트에 코드를 적어서 선생님에게 검사를 맞고 나서야 컴퓨터를 켜고 입력해 볼 수 있었습니다. 이런 짓을 오랫동안 하다 보니 한페이지 정도의 프로그램을 화면에 띄워 두고 눈으로 돌려보는 것은 그렇게 어려운 작업은 아닌 것 같습니다.

Tistory의 경우 개발된 코드가 최종적으로 적용되기 위해선, 심지어 스킨들도 QA과정을 거칩니다. 이 과정은 현재 주로 제가 담당하고 있습니다. 업데이트 계획이 수립되고 적용 코드의 검증이 시작되면 적용범위가 저에게 통보되고 저는 형상관리 프로그램(현재 TnC는 SubVersion을 사용중입니다.)의 도움으로 정확히 적용되는 변화를 볼 수 있습니다. 실제로 인풋을 넣어보는 테스트도 하겠지만 그전에 눈으로 변화 코드를 추적하면서 많은 부분을 확인하거나 이후 테스트 대상들을 확인할 수 있습니다. 여러가지 코드 검증방법이 있습니다만 눈으로 코드를 돌려보면서 검증하는 이 테스트는 일종의 White Box 테스트이기에 테스터의 능력에 따라서는 많은 부분을 쉽고 정확히 검증할 수 있습니다.(물론 사람이 하는 작업이기에 이를 보완하기 위한 전통적이고 자동화된 테스팅들이 반드시 보충이 되어야 합니다. 더불어 기존의 테스팅이 찾아내지 못하는 부분을 인간의 지성으로 찾아내는, 보완적인 방법의 특성도 있습니다.)

최근에 이런 작업을 좀더 확장 시키고 있습니다. 우선 Analysis라 불리는 작업들부터 언급해야 할 것입니다. 코딩전에 Requirement 정의나 System Architecturng등의 High Level Design 등 코딩이 없는 작업에서 일종의 디버깅 차원에서 Analysis 작업을 합니다. 그리고 최근의 Prototype을 사용한 개발방법론등을 짬뽕시켜 볼때, 프로토타입 이전부터 시스템의 디버깅이 가능하다고 보고 있으며 가령 Requirement 작업중에도 디버깅은 가능하다는 것입니다. 바로! "머리속으로 시스템 돌리기" 되겠습니다.

디버깅이라는 것이 일단 구현된 시스템이 나와야 할 수 있다고 보기 쉽습니다만 Prototype은 그것을 코딩 전에 구라 시스템(^^)을 만들어서 시도해 봅니다. 더불어 시스템이라 부를 뭔가가 나오기 전에도 인간의 상상력은 대단해서 머리속에서 그 뭔가를 만들어 볼 수 있고 역시 디버깅이 가능합니다. Requirement의 R자만 나와도 바로 확인이 가능하다는 것입니다. 이것이 중요한 것은 역시나 문제점은 빨리 찾을수록 수정 비용이 적기 때문이겠죠. 더구나 처음 시스템의 형태를 잡을때의 실수 하나는 프로젝트 자체를 취소하게 하는 요인도 될 수 있기 때문에 더더욱 중요한 부분일 것입니다.

Prototype은 개발 프로세스와는 거리가 먼 고객을 상대로 할때 쓸만한 방법입니다만 개발과정에서 그정도 단계면 상당히 멀리 왔을 때라고 보입니다. 그 이전에 Requirement 후보 리스트만 나왔을 때 부터 참여자들은 돌려볼 수 있고 현재까지 확정된 것들로 구현하고자 하는 무엇인가를 확인할 수 있습니다. 여기서 중요한 것은 역시 아직 정해지지 않은 부분은 그대로 둔다라는 것입니다. 현재의 상태에서는 그 부분은 중요하지 않거나, 중요하다면 다음에는 그 부분을 좀더 보강해서 디버깅을 해야 하겠다라고 알 수 있습니다. 그리고 현재 나열된 것들에 대해서는 이미 검증(디버깅)을 할 수 있습니다.

위의 링크에 걸린 글 마지막부에 보면 마음속으로 시스템을 돌려본다라는 말이 있지만 요즘의 시스템들은 머리속에 다 우겨넣고 돌리기엔 좀 규모가 큰 것 같습니다. 뭐 대가분들의 메모리와 시피유는 성능이 좋아서 가능하신것 같습니다만 담배와 술로 일부가 맛이간 저로서는 역시 화이트 보드가 최고인 것 같습니다. 전에는 화이트 보드와 보드마커만으로 했습니다만 최근에 본 다른 방법들의 영향을 받아 포스티잇을 통해 디테일한 기술을 하고 있습니다. 당장은 디테일 레벨이 맞지 않지만 나중에 쓸만한 거라던가 흐름의 코멘트에 사용중입니다.

보안상(?) 대부분의 내용은 모자익 처리했습니다만 현재까지 받은 인풋만을 가지고 시뮬레이션&디버깅 해 본것입니다. 저 작업은 혼자 하였습니다만 일이 진행되고 사이즈가 커지면 혼자 할 수도 없고 다들 땀 뻘뻘 흘리면서 타올라봐야 겠죠.

최근에 저도 역시 실제 코딩을 시작하는 것은 매우 느려지고 있습니다. 아니 설계도라던가 상세 설계의 시작도 역시 상위의 것들이 맘에 들어야(?) 시작할 수 있게 되더군요.

PS.
광고는 아닙니다만, 보드마커는 역시 스테XX 제품이 짱!

우선 동기의 글

연휴동안 한 일 - 설계를 문서화 하기... from 써니의 一生牛步行

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


웹 기획자란

구글을 뒤져보니 이런 링크를 찾았다.
웹 기획자가 하는 일 - 김중태문화원 1기 블로그

중간에 기획자가 하는 업무중 4번째

4. 고객이 해당 견적서와 제안서를 수용하면 개발팀과 의논하면서 개발 기획을 작성해 일정을 잡고, 일정이 잡히면 구체적인 스토리보드를 작성한다.

고객과 홈페이지에 들어갈 내용이 확정되면 바로 스토리 보드에 뛰어 드는 것이다. 이것을 기반으로 이후 HTML 코드의 기반이 잡히고 CSS가 적용될테니 나름 상위기획이겠지만 나의 눈에는 이것은 화면디자인이고 아직 요구사항 분석이나 사용자 시나리오 분석도 되지 않았는데 화면 상세 디자인을 붙잡고 있느냐라고 반문하게 된다. 이 반문은 "프로젝트를 콩가루로 만들지 않겠다라는 투철한 의지"에 활활 타올라 말하는 것이겠지만 전통적인 웹 기획자는 "자다가 봉창 두드리는 소리"로 밖에 들릴 수 없는 것이다.

전통적인 웹페이지, 그리고 웹 어플리케이션
내가 최초로 본 웹 페이지라고 한다면 몇시간에 걸쳐 트럼펫 윈속(Trumpet WinSock)과 Mosaic Browser를 끙끙대며 설치하여 접속한 NASA 홈페이지일 것이다. http://www.nasa.gov/
간만에 들어가 보니 플래시에 복잡한 컨텐트를 가지고 있지만 당시엔 그림한장과 장황한 글을 볼 수 있었다. 불과 10년전만 하더라도 대용량의 컨텐츠(그림 등)를 사용하는 것은 거의 죄악에 가까웠지만 지금은 몇백Kbyte쯤은 쉽게 쓰고 있다.
회사의 홈페이지나 기타 정적인(Static or Near-Static) 내용을 보여주는 웹 페이지의 구축에 있어서는 위의 개발 방법론(스토리보드를 통한 상위기획)이 매우 적당할 수 있다. 여기서 Near-라고 표기한 것은 복잡한 비지니스 로직이 있는 것이 아닌 관리자가 차례대로 넣은 데이터를 단순한 조회로 가져와서 보여주는 정도도 포함되기 때문이다. 하지만 이것을 BlahBlah-Market 같은 시스템(홈페이지가 아니다)을 구축하는데 사용했다간 이전에 비행기가 떨어지고 우주선이 행방불명이 되듯 개발 구성원들은 다 암걸리고 회사는 문을 닫아야 할지 모른다. 단순히 동적인(Dynamic) 데이터를 보여주는 페이지가 아니라 웹 브라우저를 Front-End 즉 UI(User Interface)로 사용하는 프로그램으로 봐야 하기 때문일 것이다.

이런 생각에 대해서 개인적은 확증은 없다. 하지만 심증(?)이 가는 것은 갑자기 SOA(Service Oriented Architecture)나 CBD(Component Based Development)등 SPer인 나에게는 당연한 소리가 대두되고 웹 어플리케이션 개발에 BCD(Business Concept Diagram: CBD에서 사용. 여기(PDF)를 참고)가 멋있지 않느냐라고 하는 것을 보았기 때문이다. 정확히 객체들(요구사항이나 기능, 비지니스 로직, 서비스든 컴포넌트든 페이지든)에 대해 정의를 제대로 내리지 않고 어플리케이션을 작성해 나간다면 태초에 소프트웨어라는 것이 생겨날 때 부터 발생한 문제들을 그대로 떠안게 된다. 부정확한 개발, 일정 연기, 개발자 도망, 유지 보수 불가능 등.

소규모 상점 사이트를 만든다고 하였을 때 전통적인 웹 페이지의 개발대로 만드는 것이 지금까지 큰 문제를 일으키진 않았다. 물건의 속성이 명확하고 그것을 바로 스토리보드(Story Board)에 기입할 수 있기 때문이다. 그러나 많은 사이트들이 문제를 일으키는 페이지가 있다. 바로 결제페이지다. 국내법상 특정 정보들은 반드시 HTTPS(HTTP over SSL)이나 기타 암호화 방식을 사용해야 하고, 물건 리스트와 결제 정보, 배송지나 최종 카드의 승인까지 몇단계로 나누어 지는 과정을 가지고 있다. 이 과정이 독립적이고 단방향이길 바라겠지만 웹의 특성상 앞뒤로는 일반 페이지들이 존재하고 중간에 튀어 나올 수도 있고 재전송/중복전송이나 역방향으로 움직일 때도 있다. 마지막으로 해커들도 존재한다. 전통적인 모델링으로 이를 Transaction으로 정의하고 각 페이지를 State로 본 후 State Transition Diagram 그리면 SPer들은 쉽게 해결할 문제지만 단순한 Story Board에서는 이 관계를 명확히 표시하거나 디자인에 대한 검증(Analysis)이 쉬운 편은 아닐 것이다. 그래서 중복 결제나 처음부터 다시라는 메시지가 나오기도 하고 해커들에게 공략 당해도 보완하기 힘들게 된다.

웹 어플리케이션의 개발 방법론
웹 페이지 소리만 나오면 이제 CBD 같은 것을 사용하라는 의미는 아니다. 케이스에 따라서는 스토리 보드를 통한 상위기획이 효율적일 수도 있고 다른 특성들을 가지는 방법들도 있을 것이다. 역시나 만능의 Silver Bullet(은총알. 흡혈귀를 잡을 수 있는 아이템, 어떤 문제를 확실히 해결 할 수 있는 방법이란 의미, 자세한건 구글에게 물어보세요)은 없다는 현재까지의 정설이다. 그렇다면 역시 마늘 엑기스와 십자가중 하나를 선택해야 할 것이다. 능력이 되면 맞짱 떠서 가슴에 말뚝이라도.

프로젝트의 시작부에서 아이디어가 발의된 후 정리되고 전체적인 무엇인가(아직 프로그램인지 웹사이튼지 모름) 윤곽이 잡힐 즘에 계획(Planning) 단계를 거칠 때 그 앞뒤로 해야 할 작업중 하나는 개발 방법론의 계획일 것이다. 아이디어의 창안자의 머리속에 뭉게뭉게 피어나는 생각이 프로젝트화 될 때는 어느정도의 윤곽이 잡힐 것이고 이것의 특성이 파악되고 더불어 상황에 따라 적당한 방법론을 찾는 것이 그 시점의 Manager가 할 일일 것이다.

그러나....

위에서 계속 큰 이야기만 했지만, 상세 설계서에서 "필드는 디비 테이블 직접 보셈"은 나중에 여러모로 문제가 될 소지가 많은 문구일 것이다. 전체 프로젝트에서 중요한 부분이든 아니든 데이터의 처리(Processing)가 일어난다면 해당 모듈은 프로그램이기 때문이다. 뭐 몇개월 후에 관계가 없을 프로젝트라면 상관 없지만 말이다.