칠레 PORTA 와인

생초보의 와인 투어 2007. 2. 17. 14:35 posted by 엔트웍스
우리집 가까이 사는 동기 녀석을 불러서 집에서 칠레산 PORTA Pinot Noir 와인을 땄다.
예전에 피노누아 - 피노누아Pino Noir 품종은 전통적으로 프랑스 부르고뉴 지방에서만 잘 자라는 까탈스러운 특성이 있어서, 그 이외의 지역이나 국가에서는 잘 만들지 못한다 그러나 최근에는 칠레나 미국 캘리포니아에서도 훌륭한 피노누아 와인이 만들어 진다고 한다. - 레드와인을 경험해 보고자 코스트코에서 구입한 와인이다.
칠레산이라 그런지 가격대가 2만원대로 저렴해서, 피노누아 첫 시음 대상으로 냉큼 사들고 왔다(부르고뉴의 피노누아 와인은 아무리 싸도 보통 3만원을 넘으며, 약간만 등급이 있어도 5만원을 훌쩍 넘는다).

피노누아 레드와인은 보통 향기롭고 부드러운 맛이 특징이라 하던데 과연 어떨지... 궁금해 하며 코르크를 빼낸다. 코르크 무지하게 빡빡하네 거. 좋은 오프너를 하나 사야겠다.

처음으로 피노누아를 경험해 본 소감은...

방금 샴푸하고 나온 소녀의 머릿결에 얼굴을 대고 있는 기분이 든다. (신의 물방울 풍)

우선 부드러운 꽃내음이 비강(나도 어려운 말 좀 써보자...)을 간지럽힌다. 입에 머금으면 실크감촉이 이런 것이구나 라는 생각이 든다. 입을 오무리고 약간의 공기를 마시면 약간 상큼하지만 카베네 소비뇽Cabernet Sauvignon 보다 훨씬 부드러운 향기의 아지랑이가 피어오른다. 목에서 부드럽게 넘기고 나면, 나도 모르게 와인잔에 다시 한번 손이 간다.

생초보답게 나는 무슨 꽃향기의 아로마라던가 이런 건 잘 모르겠다. 다만 정말 부드럽게 넘어가는 감촉과 향기는 분명히 느낄 수 있다. 그리고 마신지 몇 시간이 지나도 비강에 남아 있는 이 와인의 향기는 와인의 매력이 무엇인지 분명히 보여준다.

다음에 코스트코 가면 두 병 사와야지... ^^

사용자 삽입 이미지

(이미지 발췌 - http://www.portawinery.cl/)

멋있게 넥타이 매는 방법 13 가지

일상다반사 2007. 2. 16. 12:41 posted by 엔트웍스
내가 매는 방법은 하프 윈저 노트였군...

멋있게 넥타이 매는 방법 13가지

  1. Commented by Favicon of http://blog.naver.com/kyeongwook94 BlogIcon 경욱 at 2007.02.16 12:49

    난 윈저와 하프윈저 번갈아 가면서 쓰징.. 딤플(매듭부분 주름)만들때는 하프윈저노트쓰고 일반적으로는 윈저노트쓴다 ㅋ

    • Commented by Favicon of http://crosscutter.info BlogIcon EntWorks at 2007.02.16 13:51

      첨에 배운건 윈저였는데 귀찮아서 하프만 하게 되더라구.
      그런데 블라인드폴드노트 하면 어떤 소리 들을까?

(1)편은 여기에.

검증형 예외를 잡아라! 왜? 컴파일러가 잡으라니까...

자바를 처음 배우던 시절, 제가 봤던 책 중에 예외에 대해 진지하게 다뤘던 책은 없었습니다. 모두 try-catch-finally(TCF)와 throws, throw 키워드의 의미와, 이것 들이 예외와 어우러져 어떻게 코드를 작성해야 컴파일이 되는지에 초점을 맞추고 있었습니다. 물론 비검증형에 대한 설명도 나오지만, 이런 것도 있으며 클래스 계층도는 이렇다 정도였습니다. 지금도 책들이 이런지는 모르겠습니다만...

그러다보니, 대부분의 개발자들은 예외에 대해서 진지하게 생각하지 않았습니다. 당연히 저도 마찬가지이구요. 컴파일만 되면 되지 무슨... 그러다보니 아래 같은 코드가 양산되기 시작했습니다.

try {
   doDangerousThing();
} catch (DangerousException ex) {
   ex.printStackTrace(System.err);
}

doSafeThing();

심지어는 Exception으로 catch하는 경우도 있고, 예외를 잡아서 아무것도 안 하는 코드도 있습니다.

많은 개발자가 실제로 이런 식으로 대응을 하기는 하지만, 속으로는 누구나 찜찜해 합니다. 왜냐하면 이런 코드가 의미하는 바는, 예외가 발생하면 다른 사람은 어떻게 했든 상관없이 일단 출력하겠다. 위의 코드에서 DangerousException의 발생에 대해 나는 코드로 대응이 불가능하다. 실행 중에 문제가 생기면 나 혹은 누군가를 부를 것이고, 그때 로그를 보면 대처할 수 있을 것이다 라는 의미이기 때문입니다.

더욱 나쁜 것은 예외가 발생했으므로, 시스템은 더 이상 해당 처리에 대해 유효한 상태가 아닐 가능성이 높습니다. 그럼에도 불구하고 catch로 이미 예외를 잡은 후에 코드는 더욱 진행됩니다. 그럼 과연 doSafeThing()이 제대로 실행될까요? 많은 경우 또 다른 예외가 발생하거나 기대와는 다른 행동을 할 가능성이 높습니다. 게다가 예외를 출력한 후 또 예외가 발생한다면, (제대로 로그가 남는다 하더라도) 예외가 뒤죽박죽 되어 뭐가 원래 문제인지 더욱 알 수 없게 만들게 됩니다.


그럼 잡지 말고 던져라!!

이러한 문제를 회피하는 방법은 예외를 catch 하지 않고 throws에 선언하는 것입니다. 코드는 다음과 같습니다.

public void doCompositeThing() throws DangerousException
{
    doDangerousThing();
    doSafeThing();
}

더 이상 해당 메소드 내에서 DangerousException을 catch 함으로써 발생하는 문제는 없습니다. 그런데 또 다른 문제가 생깁니다. 메소드 호출 단계가 깊어지면, throws 해야 하는 예외가 점점 증가하게 됩니다. doCompositeThing()을 호출한 메소드 자체에서 예외를 발생시켜야 한다면, 아마 이 메소드는 이렇게 될 겁니다.

public void doCompositeThing()
throws DangerousException, MoreDangerousException
{
   doCompositeThing();
    if (someCondition()) {
        throw new MoreDangerousException("Hahaha");
    }
}

계속 증가합니다. 쭈욱~
경우에 따라서는 수십가지(!) 예외를 던지는 메소드를 정의할 수도 있습니다.

이를 검증형 예외의 확장 문제scalability problem of checked exceptions 라고 합니다. 여기에 대한 좋은 인터뷰가 하나 더 있으니 읽어 보시기 바랍니다.


검증형 예외의 확장 문제를 해결하라.

간단히 요약하면, 검증형예외는 얼핏 훌륭한 특성이라 생각할 수 있습니다만, 현실 세계에서 제대로 다루기에는 매우 어려워서 오히려 다른 문제를 양산한다고 할 수 있겠습니다. 특히 시스템이 커질 수록 호출의 깊이가 길어지기 마련인데, 확장성 문제의 심각성은 더욱 커질 수 밖에 없습니다.

따라서 아래 처럼 해결하거나...

public void doCompositeThing() throws Exception
{
    .......
}

좀 더 나은 방법으로는 애플리케이션 공통의 수퍼타입super type을 정의하는 것이 있습니다.

public void doCompositeThing() throws MyAppException
{
   .......
}

물론 위의 DangerousException이나 MoreDangerousException은 MyAppException의 하위타입으로 바뀌어야 합니다.

이렇게까지 설계했다면 검증형 예외의 확장 문제는 더 이상 문제가 아닙니다. 다만 애플리케이션 내의 메소드가 Exception이나 MyAppException을 던지도록 선언만 하면 되죠. 필요한 경우에는 메소드 내에서 catch 할 수도 있습니다.

그런데 저는 다음과 같은 생각이 듭니다.

이러한 아키텍처라면, 검증형 예외를 쓰는 것에 무슨 의미가 있나요?


  1. Commented by Favicon of http://toby.epril.com BlogIcon 토비 at 2007.02.16 22:32

    프로그램 라인수를 늘려서 개발실적을 과장할 수 있는 의미가 있습니다.
    또 메소드 시그니처가 폼나기 때문에 초보자들이 볼때 뭔가 대단한 것을 하는 코드로 보이는 효과가 있습니다.

    • Commented by Favicon of https://entworks.tistory.com BlogIcon 엔트웍스 at 2007.02.17 14:44 신고

      모모 Best Practices 라는 책에도, 인터넷에 떠도는 꽤 많은 J2EE Best Practices 에도 저런 식으로 나와 있으니, 우리는 전문가의 Best Practices를 따르고 있다! 라고 자랑할 수도 있습니다.

공자의 명언과 디자인 패턴

엔터프라이즈 자바 2007. 2. 12. 19:25 posted by 엔트웍스
최근 읽은 책에서 다음과 같은 공자의 명언이 등장합니다.

五十而知天命하고 六十而耳順하고 七十而從心所欲하야 不踰矩니라
오십이지천명 육십이이순 칠십이 종심소욕 불유구

쉰에는 천명을 깨달아 알게 되었고, 예순에는 어떠한 말을 들어도 그 이치를
깨달아 저절로 이해를 할 수 있었고, 일흔에는 내 마음 가는 대로 행동을 하여도 법도에 어긋나는 일이 없었다.


이는 디자인 패턴을 대하는 태도에도 딱 들어 맞습니다.

쉰에는 패턴을 깨달아 알게 되었고, 예순에는 어떠한 패턴을 들어도 그 이치를 깨달아 저절로 이해를 할 수 있었고, 일흔에는 내 마음 가는 대로 설계를 하여도 패턴에 어긋나는 일이 없었다.

지천명, 이순을 넘어 종심소욕 불유구가 목적이어야 하지 않을까요?
일흔에 이룬다면 좀 문제가 있겠지만... ^^

  1. Commented by Favicon of http://px.tistory.com BlogIcon 민재 at 2007.02.12 23:02

    10년내지 15년씩 당기면 될거 같습니다.
    그시대랑 이시대랑 비교하면 업그레이드가 많이 되었으니.. ^^;;

  2. Commented by Favicon of http://younghoe.info/ BlogIcon 영회 at 2007.02.13 01:02

    절필했나 했슴다.
    올만에 감칠만 나는 글이네요.

  3. Commented by Favicon of http://cbiscuit.info BlogIcon cbiscuit at 2007.02.13 02:23

    서른에 기반을 닦아 마흔에 가는 길에 모든 의혹이 없어야 하고.. 그제서야 하늘의 이치를 깨달아 알게되어 어떠한 세상 도리를 깨닫게 되니.. 이것이 세상사 사람으로 살아가는 모습 아니겠는가..

    그런데 공자는 73세까지 살았으니 '종심소욕 불유구'는 꼴랑 2년 몇개월 정도였을 듯.. 지천명이나 이순에 비해서는 그 깨달음의 시간이 좀 짧긴 하지만, 깨달음은 한 순간이니 세월이 길고 짧음은 비할바가 아닌듯 하다.

AOP? 이게 뭐야?
제가 AOP를 처음 접한 건 2002년이었습니다. 그 땐 자료도 얼마 없었었거니와, 자료를 봐도 당췌 이해가 안가더군요. DeveloperWorks에서 AOP에 관한 아티클을 보면서 열심히 따라했는데, 뭔가 아리송한 것이 머리속이 흐릿하더군요. AOP 도구인 AspectJ도 버전 마다 상당한 차이가 있어서, 아티클 대로 실행도 안되었습니다. 그 후에 프로젝트 하나를 끝내고 2003년도에 틈틈이 AspectJ를 공부하기 시작했습니다만, 여전히 헤메게 되더군요 :-)

이렇게 과거의 저처럼 헤메는 지금의 분들을 위해 AOP에 대해 쉽게 설명해 보려고 합니다. 뭐 이렇게 말하는 저도 AOP 제대로 해 본 사람도 아닙니다만...;;; 모든게 그러하듯이 알고 보면 모두 쉽습니다. AOP도 그다지 어렵지 않습니다. 개념부터 이해한다면 말이죠. 기존의 사고체계에서 벗어나질 못한다면 어렵지만, 쉽게 벗어날 수 있다면 아주 쉽습니다. 예를 들어 이런겁니다.

기존 파일시스템의 한계 그리고 WinFS
우리는 윈도우든 유닉스든 파일 시스템에 매우 익숙해져 있습니다. 파일 시스템은 디렉토리와 파일 두 개의 개념이 핵심입니다. 디렉토리 밑에는 하위 디렉토리나 파일이 포함될 수 있죠. 파일시스템은 전형적인 트리구조를 따릅니다. 그런데 옛날에는 이로써 충분할 수 있었지만, 요새같이 디스크가 수백 기가에 이르고, 각종 작업 문서도 저장해야 되고, 게임, 음악, 동영상, 이미지, 프로그램 등등을 디스크에 저장해 두다 보면 수백만 수천만개의 파일이 디스크에 쌓입니다. 파일이 몇개 없다면 이런 많은 파일 들을 디렉토리 분류를 잘 해서 관리하는 것이 그리 어렵지 않지만, 나중에는 이 디렉토리 분류 자체가 어려워 집니다. 디렉토리 체계를 잘 잡는 것이얼마나 어려운 작업인지는 컴퓨터를 좀 다루시는 분이라면 대부분 공감하실 거라 생각합니다.

이 어려움의 이유는 파일시스템이라는 것이 트리구조에 기반한 1차원적 분류체계를 가지기 때문입니다. "재밌는만화.jpg"는 이미지 디렉토리에 둬야 할까요, 아니면 만화 디렉토리에 둬야 할까요. 이러한 근본적인 문제를 해결하기 위해 MS에서는 WinFS라는 파일시스템을 개발중입니다. 원래는 비스타에 포함시킬 예정이었으나 취소되었지만요.

전문가는 아니지만 제 관점에서 보면 WinFS의 핵심은 메타데이터입니다. 블로그 용어로 하면 태그라고 할까요. 각 파일에 디렉토리 체계에 의한 분류 그 이상을 위해서, 메타데이터를 이용해서 검색을 훨씬 강력하게 만드는 겁니다. 재밌는만화.jpg 파일에 "명작10선", "만화", "심심풀이" 라는 메타데이터를 부여한다면, 일일이 디렉토리를 기억하지 못하더라도 쉽게 찾아낼 수 있을 겁니다.

소프트웨어에서의 WinFS = AOP
소프트웨어에서의 AOP는 WinFS와 유사한 개념이라고 볼 수 있습니다. 소프트웨어에서 제일 중요한 것 중 하나가 관심주제에 따른 모듈화입니다. 유명한 말 있잖습니까. Divide and conquer. 어떤 비즈니스를 표현한 것이라면, 비즈니스를 각각의 주제영역에 분리하여 해당 주제를 프로그래밍 하여 모듈화할 것입니다. 예를 들어 "계약"이라는 비즈니스를 표현하기 위해 다시 주제 별로 "가입설계", "신계약", "계약변경" 모듈을 만들어 내지요. 이는 비즈니스 주제영역별로 디렉토리를 만들고, 각각의 주제별 파일을 만드는 것과 다름 없습니다. 그런데 만물이 모두 그러하지만, 프로그램 모듈 또한 자신을 탄생시킨 주된 주제영역 이외에도 다른 주제를 표현(실행)해야만 합니다. AOP에서 흔히 드는 예는 트랜잭션, 보안, 로깅 등이지요.

문제는 이러한 주제는 자신의 중심 주제와는 완전히(혹은 거의) 독립된 주제라는 점입니다. 게다가 여러 모듈의 중심 주제와는 거리가 있지만, 여러 모듈에 걸쳐 더부 살이 해야만 의미가 있는 주제이기도 합니다. 그런데 신계약 비즈니스를 표현하는 모듈 내에 트랜잭션 처리라는 주제를 심어 주는 것은, 관심 주제에 따른 모듈화를 위반하는 것입니다. 이는 기존의 절차형 언어이든 객체지향 언어이든 해결할 수가 없었던 문제입니다. 어떻게든 떼어내고 싶지만 떼어내기 힘든 찰거머리 같은 녀석들딥니다. 하지만 대안적인 해결로서 오랜 세월동안 사용되어 왔던 방법은 너무나 쉽고 또 당연한 방법이었습니다. 해당 주제를 표현하는 모듈(예를 들어 트랜잭션 관리자 모듈)을 만들고, 이를 필요로 하는 모듈에서 이를 인터페이스를 통해 호출하는 것이지요. 그러나 이는 "계약" 모듈 안에서 트랜잭션 관리자 모듈을 "호출하는 로직" 자체을 포함시키는 것은 어쩔 수가 없습니다. 게다가 이러한 로직이 각 모듈마다 반복적으로 반드시 명시해야만 실행되는 점, 해당 API에 대한 종속성, 그리고 이러한 인터페이스의 변경이 가져오는 여진은 피할 수가 없습니다.

AOP, 구조화 방법의 역전
MIT가 향후 10년을 주름잡을 10대 기술 중 하나로 선정한 AOP는 이러한 문제를 해결하기 위해 등장하였습니다. 그 핵심은 바로 "구조화 방법의 역전(Inversion of Structuring)"라는 제가 생뚱맞게 급조해 낸 용어 속에 있습니다. 헐리우드 법칙 - 나한테 연락하지마. 내가 연락할테니. - 에 빗대어 이야기하면, "니(계약) 모듈 안에 나(트랜잭션)를 포함시키지 마. 내가 니 안으로 들어갈테니." 정도가 될 것 같습니다. AOP에서는 이를 포인트컷pointcut에 대한 위빙weaving이라 합니다.

즉 AOP는 기존의 모듈화 방법으로 해결하기 힘든 주제를 구조화 방법의 역전 - 제 멋대로 붙인 말임을 상기하세요 ^^ - 을 통해 모듈화하는 방법을 제시함으로써, 기존에 일차원적인 모듈화 체계에 새로운 차원을 부여합니다. 실제 실행중에는 합쳐져야 하지만 코드베이스에서는 분리되어야 하는 모듈을 애스펙트화 하게 되면, 애스펙트 모듈은 다른 모듈이 자신을 호출하도록 두지 않고, 오히려 자신을 필요로 하는 모듈에 런타임에 결합되어 들어감으로써, 분리되어야 하나 분리되지 못했던 기존 모듈화 방법을 보완합니다.

패러다임부터 이해하자
이러한 패러다임으로 AOP를 보게 된다면, AOP에 보다 쉽게 접근이 가능할 것이라 생각합니다. AspectJ의 복잡한 포인트컷 문법이나 Spring Framework AOP 기능의 복잡함을 익히느라 AOP의 본질을 망각하지 마시고, 쉽게쉽게 접근하세요 :-)

  1. Commented by Favicon of http://cbiscuit.info BlogIcon cBiscuit at 2007.02.09 14:36

    Aspect에 Aspect도 가능한가...

    • Commented by Favicon of http://crosscutter.info BlogIcon EntWorks at 2007.02.09 23:06

      애스펙트를 컴포넌트화하고 그 컴포넌트에 다시 애스펙트를 적용하고... 리커시브 컴포넌트 베이스드 애스펙트.

  2. Commented by 넷개구락지 at 2007.04.02 10:05

    읽고 있으면 Spring AOP 보다 더 어려운것 같은데요 ^^;
    좋은 글 감사합니다.

티스토리로 이사

일상다반사 2007. 2. 2. 21:53 posted by 엔트웍스
닷네임 서버 호스팅에서 티스토리로 이사왔습니다~
떡이라도 돌려야 할까요...

그런데 http://www.crosscutter.info 는 티스토리로 잘 포워딩 되는데,
http://crosscutter.info 는 옛날 블로그로 들어갈까요?

아시는 분은 답좀... 흑

파란만장 PC 업글記 - 후기

일상다반사 2007. 1. 31. 21:39 posted by 엔트웍스
메인보드의 사망판정으로 메인보드를 새로 구입해야 하는 지경에 이르고 말았습니다.
그래도 이번 업글 중 구입했던 AGP 비디오카드는 그대로 쓸 방법을 찾아보던 중,
PCI-Express가 아닌 AGP를 지원하면서도 AM2타입의 AMD 씨퓨를 지원하는 보드를 찾았습니다.

메모리 뱅크가 2개에 PCI 슬롯이 3개 뿐인 미니 ATX 보드지만, 우선 착한 가격 4만 7천원이 마음에 듭니다.
거기다가 시피유는 AM2를 지원하고 메모리는 DDR2 800까지 지원하는 별난 보드입니다.
K8M800이라는 듣도보도 못한 칩셋을 쓰던데 뭐 어떻습니까.

결국 AMD 셈프론 2800+ 마닐라 5만 3천원, 디지웍스 DDR2 667 메모리 512M X 2 = 10만 4천원 해서 대략 20만원으로 보드, 씨퓨, 메모리를 장만할 수 있었습니다.
모니터의 폭발로 시작되었던 업글은 기나긴 시간을 거쳐 결국,

리치웰 20.1인치 모니터 (1680X1050)
AMD 셈프론 2800+ (AM2)
디지웍스 DDR2 667 512M X 2
Radeon 9550 AGP 256M
하드디스크 120G + 60G
파워서플라이 350W

로 종결되었네요.

업글하려고 구입했던 AMD 1200과 씨퓨 쿨러는 무용지물이 되었으니,
배송비까지 합치면 대략 2만5천원 정도 손해 봤네요.
그래도 그동안 잊고 있었던 PC 하드웨어 구조를 전체적으로 리뷰해 볼 기회가 되어 유쾌한 경험이었습니다.

업글 후 남은 SDRAM 512M (PC133)이랑 쿨러(소켓A)는 옥션에라도 팔아봐야 겠습니다.
사실 분 계시면 댓글 남겨주셔도 됩니다 ^^
(갑자기 장터란이 되어 버렸네요)
TAG 업글

Maven 2.0 간단 리뷰

엔터프라이즈 자바 2007. 1. 29. 20:24 posted by 엔트웍스
Maven 1.x 와 비교하면 다음과 같은 점들이 좋아졌다.
  • 리파지토리 레이아웃이 합리적으로 변경되었다. 특히 ejb, jar, war, ear을 따로 각각의 디렉토리에 저장하던 악습이 사라졌다.
  • 의존성 전파transitive dependency 기능을 지원한다. 예를 들어 A->B 의존성을 정의하고, B->C 의존성을 정의하면, A를 빌드할 때 Maven이 알아서 C까지 끌어와서 빌드한다.
  • 아무도 좋아하지 않던 Jelly 스크립트는 deprecate 되었다. Mavan 2.0의 플러그인은 모두 순수 자바로 구현된다.
그러나 더 나빠진 것이 있다.

Maven 2.0이 릴리즈 된지 1년이 넘었지만, Maven 2.0은 문서화가 꽤나 부실하다. Better Builds with Maven 이나 Maven 웹사이트 에서 Maven 2.0의 튜토리얼이나 소개자료, 즉 간단히 시작하는 데 필요한 내용은 얻을 수 있으나, 정말 필요할 때 참조할 수 있는 레퍼런스 문서는 빠진 것이 꽤 많다. 특히 Maven의 경우 모든 것이 플러그인인지라 플러그인의 활용이 주류를 이루게 되는데, 플러그인에 대한 레퍼런스 문서가 꽤나 부실하다. 예를 들어 EAR 내에 application.xml 외에 별도의 XML 파일을 같이 패키징하려고 했는데, 방법을 도무지 찾을 수가 없어서 포기해야 했다.
또 도움을 얻어 보고자 Maven 포럼에 들어가 보면 거의 폐허를 연상케 한다.

아마 개발자였던 Vincent Massol이 컨설팅 업체인 Mergere(머저리?)를 차려서 비즈니스 하느라 바쁜 것이 원인인 듯 한데, 이렇게 문서화가 불친절해서야 나름 본의아니게 Maven에 정들은 나라도 얼마 안있어 떨어져 나갈 것만 같다.

나름 이해를 해 보자면, 워낙 Maven이라는 녀석의 아키텍처(및 도메인 모델)이 복잡한지라, 그 설명에만 신경을 쓴 것 같기는 하다.

이번 기회에 JRake로...?
TAG Maven 2.0

이 하나의 화면을 띄우기 위해

엔터프라이즈 자바 2007. 1. 29. 19:18 posted by 엔트웍스
수많은 기술들이 동원된다.

직접 관련 있는 것만 추려보자면,
WebLogic 9.2, Spring Framework 2.0.2, Servlet, JSP, JSTL, EJB에,
개발은 Eclipse 3.2에, 빌드는 Maven 2.0으로.


JavaEE는 복잡하기도 하여라.
TAG RCA

당신의 추정estimation 능력은? - 해답편

프로젝트경영 2007. 1. 27. 16:48 posted by 엔트웍스
해답편이 늦어서 죄송합니다.
개인적인 사정으로 블로그에 시간을 쓸 수가 없더군요.

아래의 more 링크를 누르시면 해답이 보입니다.

혹시 이전 글에서 답을 내지 않으셨다면 이번 기회에 도전하셔도 좋습니다.
직접 추정을 해 보고 결과를 봐야 추정의 의마가 더 와 닿으실 겁니다.


< 스티브 맥코넬의 추정능력 테스트 비공식 한국버전 - 해답 >



채점결과가 나왔나요?
아마 대부분 저조한 점수가 나왔을 거라 예상합니다.
저도 마찬가지였고, 스티브 맥코넬도 이 테스트를 많은 사람들을 대상으로 실시하였는데 같은 결과였다고 합니다.

유일하게 답을 올려주신 민재님의 결과는 2점~5점 구간에 속해 있습니다.
(그래도 애매하게 공개했습니다 민재님 ^^ )

이러한 결과에 대해서는 다음 번에 설명할 예정입니다.
  1. Commented by 민재 at 2007.01.27 21:16

    음.. 2점인데.. 배려를 해주신듯.. ㅋㅋ..
    전 결과보다는... 설명이 기대되어서..
    근데 넘 뜸 드리는거 아니에용~~