BeeKim's log BeeKim's log

Enterprise Architect는 Rational Rose나 Together의 계보를 잇는 CASE 툴인데 개인적으로는 지금까지 써본 Tool 중에 가장 막강하다고 생각한다. 사실, 가성비로만 따지면 따라올 자가 없다. 요즘은 CASE 도구나 UML에 집착하는 분위기 자체가 많이 수그러들었고 실제 분석, 설계를 하기 위한 목적보다는 프로젝트 산출물 작성용으로 많이 사용하지만… ^^;. 개념 정리나, 러프한 수준의 설계 목적 등 적절한 수준에서 사용하면 충분히 양질의 결과를 얻을 수 있다. 그러고 보면 문제는 항상 하는 일에 상관없이 진행되는 과도한 절차 및 문서화가 아닐까 싶다. EA와 SVN 연동을 위해서는 SVN Command Line Client가 필요하다. 다운은 여기서 받을 수 있는데 ht..

얼마 전 시골 본가에 갔다가 우연찮게 청첩장을 하나 보게 됐다. 아버지 앞으로 온 청첩장 이었다. “청첩장이네…” 그냥 무심코 지나치다가 뭔가 좀 이상한 느낌에 다시 보게 됐다. 자세히 보니 이름과 주소를 정성 들여 직접 쓴 것 까지는 좋았는데 주소는 뭔가 좀 부족한(?) 상태였고 아버지 함자는 한자가 틀려 있었다. 하지만 그런 부실한 정보에도 불구하고 청첩장은 아무런 문제 없이 시골집에 잘 도착해 있었다. 재미있어 어머니께 여쭤보니 시골에 있는 우체국에서 오래 근무하신 분들은 어디에 누가 살고 있는지 다 안다고 하신다. 그러니 XX리에 김XX 정도야 번지수 없고 이름 좀 틀렸다고 못 찾을 이유가 없다고 하신다. 그리고 혹시 몰라도 몇 번만 물어보면 결국은 주인을 찾아가게 된다고 한다. 얘기를 듣는 동안..

수렴진화 수렴진화는 계통적으로 관련없는 둘 이상의 생물이 진화의 결과로 유사한 형태를 갖게되는 현상을 말한다. 수렴진화의 대표적인 경우로는 개미와 흰개미를 들 수 있다. 개미와 흰개미 거의 동일한 형태와 습성을 갖고 있지만 기원은 전혀 다르다. 흰 개미는 바퀴벌레와 동일한 조상을 갖으며, 개미는 꿀벌, 말벌등과 유연관계를 갖는다. 그렇다면 흰개미와 개미는 왜 그렇게 비슷하게 보이는 것인가. 그 이유는 그들이 같은 종류의 생활방식으로 수렴했기 때문이다. 다음은 리처드 도킨스의 눈먼 시계공에서 기술된 개미와 흰개미의 수렴진화에 관련된 설명이다. 개미와 흰개미는 커다란 집단을 이루고 살며 이 집단의 대부분은 생식 능력 및 날개가 없는 노동 계급이 차지하고 있다. 이들 노동 계급은 날개가 달린 생식 계급을 효과..

제가 처음으로 회사에 취직해서 개발을 시작할 무렵은 EJB의 시대였습니다. EJB 스펙을 구현한 웹로직, 웹스피어, Jboss같은 웹 애플리케이션 서버가 웹앱 시장을 장악하고 있었고 EJB 코딩이가능한 자바 개발자를 찾는 구인 광고가 넘쳐났습니다. 처음 사회에 나온 어리버리한 신입사원이었던 저는 EJB아니면 엔터프라이즈웹 웨플리케이션을 작성할 수 없는 줄 알았습니다. 그렇게 몇 년을 세션빈, 엔티티 빈에 묻혀 살면서 수많은 EJB 코드를 작성했습니다. 사실 EJB 스펙에 맞게만 코딩을 하면 트랜젹션 관리, 데이터소스 관리 같은 직접 구현하기 어려운 기능을 알아서 해주는 건 상당히 매력적이긴 했습니다. 하지만 그 시절은 저에게 개발하기가 무척 어려웠던 시절로 기억됩니다. 잘 알지도 못하는 DD(Deploy..

스택오버플로우(StackOverflow)라는 사이트가 있습니다. 혹시 알고 계셨나요? 개발자들을 위한 Q&A사이트입니다. 무료에다가 구글에서 검색도 잘됩니다. 엄청난 양이 데이터가 축적되어 있어 프로그래밍 문제를 구글에 질문하면 가장 먼저, 많이 뜨는 사이트입니다. 처음에는 잘 모르고 지나쳤었는데 하도 자주 걸려서 정보를 좀 찾아보니 “조엘온 소프트웨어”로 잘 알려진 조엘 스폴스키(욕이 아닙니다.)님이 만든 사이트더군요. About 페이지에 가보면 스택오버플로우는 Wiki, 포럼, 블로그,Digg/Reddit 중간쯤에 있는 서비스라고 스스로를 소개합니다. 네 가지 서비스의 특징을갖췄다는 이야기인 것 같습니다. 그래서 그런지 아까도 말씀드린 것 같이 Q&A데이터들이 엄청나게 축적되어 있습니다. 그리고 이런..

특수관계 리뷰를 쓸까 말까 고민했습니다. 저자와의 특별한 관계 때문입니다. 특수관계인(?)이 리뷰를 쓰면 팔을 안으로 굽는다고 좋은 얘기만 쓰게 될 것 같아서 말입니다. 괜히 누군가 제가 쓴 글을 읽고 책을 구입했다가 낚였다고 생각하면 오히려 책에 마이너스일 수도 있을 것 같아서요. 그래서 고민을 했는데 그냥 쓰기로 했습니다. 뭐 그냥 좋은 얘기만 쓰려고요. 제가 이런 특별한 관계임을 밝히는 것으로 책임을 회피해 보겠습니다. 저는 글쓴이의 일생에서 5시 42분 부터 7시 30분 까지를 같이한 사이입니다. - 뭔 얘기인지는 책을 보시면 압니다. :) 글쓴이와 같은 대학교, 대학원을 졸업했고 같이 석사과정을 밟았습니다. 또, 같이 벤처를 창업해 게임을 만들기도 했고, 재미난 서비스를 만들기도 했습니다. 하지..

고민 딸아이가 초등학교에 입학한지도 벌써 4개월 넘었습니다. 초등학교에 입학하기 전에는 마냥 귀엽고 사랑스러운 딸이어서 별로 바라는 것이 없었는데 막상 초등학생이 되고 시간이 흐르니 좀 더 나은 사회 생활을 위해 이것 만은 좀 고쳐야겠다고 생각하는 것들이 생겼습니다. 뭐 그렇다고 대단히 문제가 있는 건 아니고 기본적인 생활 습관들에 관한 문제들이 대부분입니다. 가령 아침에 일어나서 학교 가는 준비를 하는 일이라던가, 식사습관 – 너무 오랫동안 식사하는 버릇 이라던가, 시간은 정해져 있는데 마냥 자기 하고 싶은 만큼 하려고 한다던가 하는 문제들입니다. 집 사람과의 꽤 오랫동안 이 문제로 이야기를 했습니다. 그냥 좀 더 지켜보며 자연스레 고쳐지기를 기다릴 것인가 아니면 어떤 식으로든 간에 고치 보려는 노력..

슈퍼 개발자 뛰어나다 못해 출중한 개발자가 한 명 있습니다. 게다가 이 개발자는 성실하고 일 욕심도 많습니다. 그래서 이 사람은 주변에 일을 도맡아 하고 실제로도 많은 일을 훌륭히 처리합니다. 회사에서는 없어서는 안 될 존재이며 회사 구성원들이 모두 이 사실에 동의합니다. 하지만 문제가 좀 있습니다. 일을 너무 잘하고 많이 하다보니 이 슈퍼 개발자의 가동률이 항상 100%를 넘어선다는 것입니다. 잠깐, 항상 100%를 넘게 일하고 있는데 뭐가 문제냐고요? 모든 개발자들이 스스로가 할 수 있는 일보다 더 많은 일을 처리하고 있다면 전체 조직의 생산성도 더 올라갈 거란 생각은 잘못된 생각입니다. 바로 부분최적화의 오류입니다. (이미지출처) 많은 일을 하고 있는 슈퍼 개발자일지라도 한 번에 할 수 있는 일에는..