달력

072010  이전 다음

'2007'에 해당되는 글 241건

  1. 2007/12/28 구글 Collections 살펴보기
  2. 2007/12/27 스프링 개발자를 위한 이클립스 설정 리소스
  3. 2007/12/27 템플릿 타이핑 도우미
  4. 2007/12/27 Shift + Num lock
  5. 2007/12/27 프로젝트 관리자가 테스트에 대하여 알아야 할 것
  6. 2007/12/27 실용주의에 대한 반추(反芻) (5)
  7. 2007/12/23 여섯 번째 사용자 모임 후기 (2)
  8. 2007/12/23 체크리스트...
  9. 2007/12/21 문맥(Context) 공유 중요성을 다시 한번 실감하며
  10. 2007/12/20 iBatis 사용시 ResultSet을 객체에 매핑시키기 (4)
  11. 2007/12/18 Building Spring 2 Enterprise Applications 번역 관련 글 이동 (2)
  12. 2007/12/18 효율성 곡선과 작업 분장 (1)
  13. 2007/12/17 Spring 사이트에 KSUG 6th 공지
  14. 2007/12/14 스프링을 통해 진화하기 (2)
  15. 2007/12/14 TSE2008 소식 From 마이애미 By Toby (3)
  16. 2007/12/07 6번째 스프링 사용자 모임 공지 (2)
  17. 2007/12/04 유스케이스는 과연 유용한가? (6)
  18. 2007/11/29 [리뷰] Continuous Integration으로 결점을 조기에 발견하기
  19. 2007/11/29 [리뷰] 이슈 트래커 개발자가 들려주는 이슈 트래커 이야기, Part 1: 무엇을 어떻게 골라쓸까 (4)
  20. 2007/11/20 요구사항의 중요성: 문제 안에 답이 있다
  21. 2007/11/19 스스로에게 솔직하게 살아가기
  22. 2007/11/16 도메인 모델 주도로 보는 엔터프라이즈 애플리케이션 인프라 요건
  23. 2007/11/16 빌드/배포 자동화 필요성 (2)
  24. 2007/11/15 요구사항에 대한 도메인 모델 (1)
  25. 2007/11/15 중요한 것을 먼저 해야 하는 이유
  26. 2007/11/15 이분법은 훌륭한 생각의 도구
  27. 2007/11/14 IBM DW에 Acegi 관련 번역 글이 올라왔네요 (1)
  28. 2007/11/09 '컨설팅의 비밀'을 읽고 소회를 간략히 메모 (4)
  29. 2007/10/30 다섯번째 사용자 모임 후기 (4)
  30. 2007/10/28 무지한 감리인 (1)
Series Recap: Coding in the small with Google Collections을 보면서 google-collections가 실효성이 있나 보고 있다.

먼저 Preconditions을 보면  NullPointerException 반환하는 메소드는 그리 유용해 보이지 않으니 checkArgument가 적용 전과 후를 비교해본다.

if (composite.getProp() == null) throw new IllegalArgumentException();

Preconditions.checkArgument(composite.getProp()!= null);

if 보다는
Preconditions.checkArgument가 읽기에 좋지만, IllegalArgumentException가 발생하는 것이 암묵적인 내용이 된다. checkArgument가 IllegalArgumentException을 반환한다는 사실을 알아야 한다. 굵은 색으로 표시한 곳에 표현식(expression)을 넣어야 한다. 다시 말하면 일종의 비즈니스 규칙을 명제로 표현해야 한다. isOOO 류의 메소드로 도메인 객체의 Validation 메소드를 표준화한다면, Validation 메소드 안으로 저 내용이 들어가면 유익할 듯하다.

notNull()이 필요한 경우 Short cut은 쓸만하다.
Preconditions.checkNotNull(givenName);
this.givenName = givenName;
null이 아니면 할당을 하게 하는 위 구문은 짧게 쓸 수 있다.
this.givenName = Objects.nonNull(givenName);
Iterables.getOnlyElement를 보면 Set.iterator().next()List.get(0) 보다는 읽기에 좋다.

Comparators.max는 확연하게 마음에 든다.

return a.compareTo(b) > 0 ? a : b;
return Comparators.max(a, b);

숫자로 값을 반환하는 것은 진부한 것이 아닌가 생각된다.

Objects.equal and hashCode 경우도 IDE나 이클립스 플러긴을 이용하거나 직접 작성하는 것보다 좋아 보인다.
// equlas 구현 일부
return
(address != null ? address.equals(that.address) : that.address == null)
         && (targetArrivalDate != null ? targetArrivalDate.equals(that.targetArrivalDate)
             : that.targetArrivalDate == null)
         && lineItems.equals(that.lineItems);
// Google Collections 사용 시
return
Objects.equal(address, that.address)
          && Objects.equal(targetArrivalDate, that.targetArrivalDate)
         && Objects.equal(lineItems, that.lineItems);

// hashcode 구현
public int hashCode() {
   int result = 0;
   result = 31 * result + (address != null ? address.hashCode() : 0);
   result = 31 * result + (targetArrivalDate != null ? targetArrivalDate.hashCode() : 0);
   result = 31 * result + lineItems.hashCode();
   return result;
}


//
Google Collections 사용 시
 public int hashCode() {
   return Objects.hashCode(address, targetArrivalDate, lineItems);
 }


Lists.immutableList도 간소하다.
this.steps = Collections.unmodifiableList(new ArrayList<Step>(steps)); // 사용 전
this.steps = Lists.immutableList(steps); // 사용

슬슬 지루해진다. 나머지 API 역시 전체적으로 설계 사상은 비슷하다.
Collection을 이어붙이는 Iterables.concat도 있고, 하나의 키에 여러 개 요소를 Map에 담을 때 유용한 Multimap, SQL 문을 수작업으로 할 때 유용할 Join, 코드성 데이터 처리에 유익한 BiMap 등이 있다.
Posted by 영회

플러그인 업데이트
이클립스 유로파 JEE용(eclipse-jee-europa-fall2-win32.zip) 기본 업데이트 사이트에 다음 업데이트 사이트 추가
  • Spring IDE 업데이트 사이트
  • SVN 관련(Subversive plug-in, connector): 둘 다 필요
  • Implementor: 인터페이스에서 구현 클래스 검색하기

Code Formatter Profile
스프링용: Eclipse code formatter profile for Spring (spring-eclipse-code-conventions.xml)26.56 KB

Code Templates

- TDD를 위한 이클립스 메소드 생성 템플릿

Templates(Java/Editor)

- 템플릿 타이핑 도우미

JUnit4를 위한 Organize Imports 설정
1. Organize Imports Preferences 선택(Ctrl+3 단축키 이용)
2. 'Number of static imports needed for .*'를 '1'로 설정
출처: http://blog.gleamynode.net/2007/04/fixing-eclipse-organize-imports.html

갱신:
07.12.27. bookmarks.xml에 implementor  갱신 사이트 정보 추가, TDD를 위한 이클립스 메소드 생성 템플릿 추가
Posted by 영회
유로파는 JUnit4 테스트 메소드를 위한 템플릿을 포함하고 있어 자주 쓰는 구문 템플릿(Templates)으로 등록할 필요가 없다. 그러나, test 를 입력하고 나면 아래 그림과 같이 3.8 버전을 위한 것이 먼저 선택된다. 그래서, 마우스를 사용하거나 화살표키를 세번 눌러야 한다.
사용자 삽입 이미지

타이핑 흐름 유지를 위해 test4를 추가했다. test4까지 타이핑하고 자동 완성(Ctrl+Space) 키를 누른다.


import 하는 방법은 Ctrl+3 키를 누르고, templates라고 입력하면 나타나는 Java/Editor 그룹을 선택한 후 import 버튼을 누른다.
Posted by 영회

Shift + Num lock

2007 2007/12/27 12:56
종종 의도하지 않았는데 키보드 자판 배열이 엉뚱하게 바뀌어서 졸지에 어쩌지 못하는 상태가 되는 경우가 있다.

'우리는' 이라고 타이핑 하고 싶은데 '울3ㄴ0ㄴ'이라고 출력되는 경우다. 이런 난감한 상황을 벗어나게 해주는 단축키는 'Shift + Num lock'이다. 기선군에게서 얻은 꼭 필요한 팁이다. 무슨 일인지 최근 들어 부쩍 자주 쓴다. ㅡㅡ;
Posted by 영회
Stickyminds Column Posted: What Project Managers Need To Know About Testing을 읽어보면 외국도 우리와 상황이 비슷한 모양이다. 아래 그림은 Manage It!: Your Guide to Modern, Pragmatic Project Management 저자 Johanna Rothman이 자기 책에서 발췌한 그림이다.


우측으로 향할수록 프로그램 구성 단위(Unit)에서 시스템으로 진화한다. 선 위에 있는 리뷰는 자동화가 불가능한 테스트이고, 선 아래는 자동화를 권장하는 영역이다.
Johanna Rothman은 PM이 하는 가장 중요한 일이 선 아래 테스트에 대해서 지속적으로 확인하는 것이라 한다. 그리고, 120% 공감하는 내용은 사람들은 마지막 날이 되어야 자신이 만든 것을 제출하는 경향이 있기 때문에[각주:1] 가능한 조기에 리뷰/테스트 할 수 있게 하는 것이 중요하다.

Manage It!: Your Guide to Modern, Pragmatic Project Management
Manage It!: Your Guide to Modern, Pragmatic Project Management by Johanna Rothman
  1. 방학숙제를 떠올리면, 이런 현상은 비단 개발팀에 국한된 일은 아니라 보편적인 현상임을 알 수 있다 [본문으로]
Posted by 영회
로드 존슨 쓴 책을 조금 읽었다. Pragmatic이라는 단어도 나오지만, 그의 접근 방식은 그야 말로 실용적이다. 그의 아들, 스프링(Spring)도 그대로 닮아 있다. AOP라는 새로운 기술[각주:1]을 채용하는데 있어서 스프링이 취하는 방식은 실용적인 것이 무엇인지 그야말로 제대로 보여준다.

스스로 실용주의를 동경하기 때문에 실용주의 프로그래머라는 책을 곁에 두고 있다. 하지만  일터에서 진정한 실용주의자가 되기란 쉬운 일이 아니다. 

C라는 인물이 있다. 그는 하이버네이트라는 ORM이 워낙에 좋다고 하여 프로젝트 공통코드(혹은 프레임워크)에 이를 적용했다. 그런데 개발자들이 온통 불평이다. 이해할 수가 없다. 그런데 만일 함께 일할 개발자들 모두가 하이버네이트를 처음 쓰는 상황이라면 어떠한가? 그 뿐 아니라 자바 문법만 알 뿐, 객체에 대한 개념도 없는 상황이라고 한다면 C가 불평할만한 상황일까? 툴은 좋은데 개발자가 문제라는 대답은 전혀 실용적이 아니다.

K라는 인물이 있다. 그는 ActiveX를 쓴 웹을 너무나도 싫어했다. 왜 웹 표준을 쓰지 않고 그 따위(?) 기술을 쓰는지 이해할 수가 없다. 그는 ActiveX로 화면 개발하는 일은 자신의 커리어에 전혀 도움을 주지 않아 시간 낭비라고 생각했다. 그렇다고 그는 대안을 내놓을 수 없다.  이런 태도는 실용주의와는 정반대에 서 있는 모습이다.

실용주의 프로그래머 - 10점
앤드류 헌트 외 지음, 김창준 외 옮김/인사이트

가상의 이야기가 아니라 실존 인물 이야기를 해보자. A씨는 개발팀 대부분이 객체에 대한 개념이 없는 곳에서 설계 방안을 고민하고 있다. 더군다나 CBD를 적용하자고 하는데 고객이나 개발팀 대다수가 CBD에 대해 합의한 적은 없다.(아니, 합의 따위가 필요없다고 생각하는 듯 하다.) 단순히 CBD를 하면 '컴포넌트'(?)로 개발하니까 유지 보수에 좋지 않겠느냐 정도일까?

A씨는 팔을 걷어 붙이고 일을 해보고 싶지만, 상황이 그리 녹록해보이지는 않는다. 객체를 기반으로 하는 설계에는 경험이 전혀 없는 사람들로만 설계자를 뽑았다. 비즈니스 로직은 if문과 SQL로만 작성하는 것으로 아는 사람들에게 클래스 설계는 파일 분할과 다를 것이 없다. 게다가 과반수 이상은 자바 플랫폼에 대한 이해가 전혀 없다. 결과적으로 CBD 기반은 커녕 객체 기반 설계서는 기대하기 힘들다. A씨 입장에서 그들이 객체 지향의 설계를 하게 한다는 것은 그야말로 전도에 해당한다. 새로운 것을 배울 의지가 없는 사람들에게 패러다임 전환이라고 할 만큼 지대한 변화를 수용하라는 것은 무리한 요구다. Technical evangelist의 의미가 떠오르는 상황이다. 설계서를 만들 수 없는 설계자들은 남는 시간[각주:2]에 무엇을 할까? A씨의 경험에 따르면, 그들은 무엇가 비슷한 것을 만들려고 노력하며 시간을 보낸다.

A씨는 그 일이 벌어지지 않게 노력하는 것에 초점을 맞췄다. 아니. 막을 수는 없을 것 같아서 요식 행위가 가능한 실제 설계 작업과 비슷해지도록 할 참이다. 자주 했던 일인지라 방안을 찾는 것은 그리 어려운 작업이 아니다. 문제는 실용주의하고는 전혀 거리가 먼 잣대로 프로젝트를 진단하는 외계인들을 대비하는 일이다. 당장에는 유익한 작업이라고 설계서 형식을 바꾸고 설계 방식을 변경하지만, 훗날 실정을 전혀 모르는 감리사[각주:3]의 혹평으로 인해 개발팀이 고생할 수 있다. 그래서, 전혀 실용적이지 않은 기준과도 조우할 수 있도록 근거를 만드는 일이 도리어 실용적이게 된다.

그렇게 그렇게... 하루는 간다. 그 하루 속에서, 하루를 마감하며 읽어던 책 구절에서, 그 책의 내용을 자신의 목소리로 이야기해주던 사람에 대한 기억을 통해서, 아침에 들었던 오디오북에서... 실용주의가 무엇인지 배울 수 있었다. 배움이란 참 더딘 일이다.
  1. 최근 발표한 기술이라는 의미가 아니라, 자바 클래스와는 다른 애스팩트(aspect) 개념을 도입해야 하기 때문에 새롭다는 수식을 부여했다. [본문으로]
  2. 설계서를 만들어야 할 시간 [본문으로]
  3. 외계인이라고 한 것은 그들을 폄하하려는 의도가 아니라, 현지 사정이나 프로젝트 특수성을 전혀 알지 못한다는 의미이다. [본문으로]
Posted by 영회
연말이라 조촐하게 하겠구나 예상했는데 100여명이 함께 해 놀랐습니다. 한 가지 아쉬운 것이 있다면 올해는 모두 세미나 형식으로만 모임을 진행했다는 것이죠. 소프트웨어진흥원에서 좋은 장소를 제공해주어 발표하기에는 부족함이 없었습니다.

Toby님 발표는 역시 시간이 모자랐습니다. 토비님 발표는 언제나 차분하게 방대한 내용을 다룹니다. 단순히 지식 전달에 머무는 것이 아닌지라 많은 영감을 줍니다. 이번에는 발표를 맡지 않아서 저 역시 차분하게 앉아서 경청할 수 있어 좋았습니다. 좋은 발표는 듣는 사람 머릿속에서 화학작용을 일어나게 합니다. 무슨 말인고 하니, 토비님을 통해 알게 된 사실을 기반으로 새로운 생각의 확장이 일어나고, 그것을 어떻게 활용할 수 있겠구나 하는 영감을 생겨납니다. 그러니 이는 단순한 지식 전달 그 이상이죠.

발표 내용은 요약해서 전해드리기도 힘들 지경입니다. 주요 내용은 100 여 장의 PT가 매우 꼼꼼하게 만들어졌으니까 이를 참조하실 수 있을 것 같습니다. 조만간 KSUG 홈페이지Toby님 블로그에 올리겠죠. 아마 KSUG 참여하는 친구들이 주요 내용을 포스팅 하려고 벼르고 있는 것 같으니 해설판(?)도 만나 보실 수 있을지 모릅니다.

아쉬운 것은 토비님이 준비한 것 모두를 보여주기엔 3시간이 너무 부족했다는 사실입니다. 또 한가지는 토비님으로서는 QCon이나 TSE2007에서 자신이 받은 경이로움을 이 곳에 전해주고 싶었을텐데, 반응만 봐서는 전혀 알 수 없었다는 점입니다. 문화적 차이일까요? 스프링에 대한 기술적 수준 차이일까요? 아마 둘 다 관계한 것이겠죠. 그렇지만, 이번 모임에서는 매우 실무적인 질문이 오고 가기도 해서 고무적이었습니다.

내년 2월말에 JCO 컨퍼런스가 있는데 KSUG에서도 세션을 준비합니다. 토비님은 Spring OSGi 발표를 염두하고 있어서 토비님이 못다한 이야기를 제가 전해드리도록 하죠. JCO 컨퍼런스는 1시간 단위인데 이를 늘려달라고 요청하고 있습니다.

두 번째 발표 이야기를 안하면 찬욱군이 서운해 하겠네요. 첫 솔로 데뷔(?)인데 발표를 잘 했습니다. 쉽게 따라하기를 표방했는데 국내에서 JPA 활용이 아직 높지 않다는 점을 고려해보면, 모두가 쉽게 따라할 만한 내용은 아니었습니다. 그래도 애초 목적인 Spring IDE 활용을 보여주고, 평소 KSUG 발표에서 당연스럽게 사용하던 이클립스 활용법을 정리해본 것이면 충분했습니다.

7번째 모임은 JCO 컨퍼런스 때문에 Spring에 해야 할 것 같습니다. 좀 더 장시간 세미나를 해보았으면 하는 마음도 있고, 준비할 수 있는 기간도 길어서 스스로 기대하게 만듭니다.

사용자 삽입 이미지

이미지 출처: 제6회 KSUG ~ 스프링 2.5의 어노테이션과 로드존슨에 빠지다
Posted by 영회
사용자 삽입 이미지

The Power of Checklists를 타고 가서 본 그림이다. 백 마디 말보다 한 장의 그림이 강한 인상을 주는 경우다. 막강한 개발 도구와 복잡한 절차를 따르다보면 종종 해야 할 일에 대한 큰 그림을 잊을 수도 있다. 할 일이 많아지고 시간을 쪼개쓸 때는 종종 포스트잇이 어떠한 시간 관리 도구보다 유용할 때가 있다. 종종 잘 정리하려다 보면 핵심만 간결하게 요약하는 것이 어려울 때가 많다.

그림 출처: http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande
Posted by 영회
화면 프로토타입 시연회때 일이었다. 분석가가 분석한 화면을 프로젝터로 띄워놓고 고객들에게 설명을 한다. 어느 정도 설명이 끝난 후 질문을 받으면 다양한 스펙트럼을 보여준다. 고객 중 한 상급자가 프로젝트 전체 목적과 얼마나 부합하는지 관점에서 질문을 한다. 그리고 또 다른 상급자는 정책 변화를 감안한 것인지(유연성 문제) 확인하기 위한 질문을 한다. 눈에 보이는 화면을 단서로 대체로 형이상학적인 요인을 검토한다. 이는 개발 관점에서는 프로젝트의 방향성 혹은 아키텍처 이슈에 해당한다.

이와 다르게 실무자는 시스템 도입으로 인해 바뀌어질 직무 방식에 대해 묻고 한다. 사용 편의성이 주안점이다. 당연히 기능적으로 제대로 동작이 가능한가를 검토한다. 기능적으로 정상 작동하는가는 누구나 관심사다. 다만, 검증하는 방식에 있어 역시 차이를 보인다. 상급자는 외부 기관이나 시스템에서 데이터를 입수할 수 있는가 하는 거시적인 관점으로 조망한다. 데이터 자체를 가져올 수 있는가 또, 가져온 데이터가 충실한가를 보는 것이다. 하지만, 실무자 관점에서는 특히, 업무 전체를 이해하는 눈이 길러지지 않는 사람인 경우는 특정 화면이나 보고서를 보고 해당 내용이 유용한지, 입수한 데이터를 기초로 연산이 가능한지를 판단해본다.

다양한 의견이 나오는 것은 자연스러운 일이다. 그야말로 이해관계자(stakeholder)의 의미를 분명하게 인식해주는 장이다. 그런데 종종 질의 응답 과정에서 동문서답이 오고 가는 경우가 있다. 발표에 나선 개발자(프로젝트 관리자, 분석가 포함)가 고객의 관점을 이해하지 못하는 경우에 종종 엉뚱한 답변을 하기도 한다. 이러한 유형의 커뮤니케이션을 통찰력을 가지고 보는 경우에 종종 유용한 장이 되기도 하지만, 일반적으로는 효과가 떨어지는 소통 방식이다. 최소한 발표자나 사회자가 문맥 공유를 위해서 일관성 있는 시나리오로 끌고 가거나 구간별로 분명한 목표를 설정하는 것이 무척이나 중요하다.

이렇게 습득한 교훈은 일반화 하여 여러 곳에 적용할 수 있다. 앞으로 글쓰기도 이를 엄두에 둘 것이다. 어제 찬욱군 발표 리허설을 하는데도 이를 전해주었다. 조금 어색한 비유긴 하지만, 청중이 WYSWYG(What You See, What You Get)하도록 불필요한 군더거기를 다 배제하고, 발표자와 청중이 한 팀을 이루어서 공유할 것들에만 집중하는 방안을 2시간 동안 논의했다.
Posted by 영회
TAG 문맥
"Tommy!" OOO 님의 말:
네..질문 드리고싶은게 있어서...마땅히 글쓸곳이 없어서. 홈페이지에서 메신저 주소 보고 추가했습니다..;;^^
[永會] ahnyounghoe_AT_gmail.com님의 말:
네.. 어떤?
"Tommy!" OOO 님의 말: 스프링과 iBatis 연동하고있는데. 사이트에서 글보고 많이 배우고있는중인데.. vo개체라고 하나요.. 도메인 개체라고 해야하나. 테이블에서. 데이터를 담는 오브젝트.. 그걸 보통 테이블 당 1개 씩 1:1로 매칭시켜서 사용하는걸로 보여지는데.
만약.. 테이블이 2개혹은 그 이상 조인이 되어서 나오는 데이터를 받을때는 어떻게 해야하는지 궁굼합니다... 조인할때마다 DTO를 만들어야하는지. 아니면 조인될 경우의 수를 생각해서 모든 변수들을 한 DTO에 집어넣고 그걸 사용을해야하는지..;; 모두 올바른 방법이 아니라고 생각이되어서 고민중에있습니다ㅜㅜ

오전에 받은 질문인데 답변이 조금 늦었습니다. 일단 결론부터 말씀드리죠. 일단 '데이터를 담는 오브젝트'는 DTO(Data Transfer Object)라고 부르는 것이 좋겠습니다. 이유는 뒤에서 설명하죠.

쿼리 결과로 던져지는 ResultSet을 DTO에 매핑하는 방법은 크게 세 가지로 나눌 수 있습니다.
하나는 테이블과 클래스를 1:1로 대응시키는 방법입니다. 테이블과 객체를 비슷하게 만든 경우에 유용합니다. (테이블에 맞쳐서 객체를 설계했거나 객체에 맞춰서 테이블을 설계한 경우죠.) 조인해서 결과를 얻었다면 받아온 결과를 하나 이상의 객체에 담아줘야겠죠.

두번째는 객체 지향적으로 프로그래밍하는 방식인데 이런 경우에 도메인 객체라는 말이 어울립니다. User라는 객체가 있는데 기본 정보는 T_USR 테이블에 있고, 선호 사항을 담은 상세 정보는 T_PROL 테이블에 있고, 부서 정보는 T_DEPT에 저장한다고 가정해보죠. User 객체 하나로 다양한 테이터를 모두 담으려고 한다고 해보죠. 그렇다면 세 테이블 조인을 해서 매핑할 때, T_USR에서 조회한 데이터는 user.name, user.id 등에 매핑하면 될 것이고, T_PROL에서 가져온 결과는 user.profile.alias, user.profile.favoriteColor 등으로 하고, T_DEPT에서 가져온 결과는 user.dept.id, user.dept.name 등으로 매핑할 수 있겠죠. 이런 방식은 객체와 릴레이션을 매핑하는 ORM(Object Relation Mapping)의 전형적인 사례라고 하겠습니다.

마지막으로는 DTO가 별로 의미가 없을 때 동적으로 DTO를 만들어 씁니다. 굳이 타입을 정의할 필요도 없이 Map에 담으면 key/value 쌍으로 담거나 꺼낼 수 있어 프로그래밍 하기에는 편리하죠. 다만, 재사용을 할 수가 없고, 오타가 나기 쉽다는 단점이 있습니다. 표준화 관점에서는 추천하기 힘들지만, 소규모 개발이라면 고려해봄직 하죠.

* DTO에 대해서: 위키피디아에서 설명한 것처럼 과거에는 VO(Value Object)라고도 했습니다. 하지만 VO는 Domain-Driven Design: Tackling Complexity in the Heart of SoftwareImplementation Patterns (Addison-Wesley Signature) 에서 쓰는 것처럼 '식별할 수 있는 객체로 의미가 없고, 값으로 공유가 가능한 객체'로 이해하는 것이 좋다고 생각합니다. 마치 우편번호처럼 공유 가능한 값을 Value Object라고 부르는게 좋겠다는 거죠. DTO는 Data Transfer Objects 영문대로 '데이터를 나르는 객체'입니다.

Domain-Driven Design: Tackling Complexity in the Heart of Software Implementation Patterns (Addison-Wesley Signature)

 
** 점심시간 짬을 활용한 초고속 타이핑한거라 내용에 오류가 있을 수 있습니다. 지적 달게 받겠습니다. ^^
Posted by 영회
TAG iBATIS, ORM
Building Spring 2 Enterprise Applications 번역에 관련한 글은 Spring in Action 번역팀과 협력하기 위해서 팀블로그(http://springframework.tistory.com/)로 옮깁니다.
Posted by 영회
TAG Spring
후배가 흥미로운 포스트를 올렸다: The efficiency Curve

그림만 언뜻 봐도 말하고자 하는 바를 짐작할 수 있다. 요즘 프로젝트가 매우 바쁘게 돌아가고 있는 와중에 기고를 하며 초치기 능력에 새삼 놀랐기에 감이 바로 왔다.
만일 이러한 가정이 사실이라고 한다면, 이에 기반하여 무엇을 얻을 수 있을까? 가장 먼저 떠오르는 것은 테스트 주도 개발에서 배운 리듬이다. 일을 세밀하게 쪼개서 그 중에서 가장 중요한 일(most valuable task)에 총력을 다해서(single-mindedly) 할 수 있다면... 그런데.. (어릴 때부터 산만하기로 대한민국 대표였던 나로썬) 실천하기가 정말 힘들다. ㅡㅡ;

테스트 주도 개발 - 10점
켄트 벡 지음, 김창준 외 옮김/인사이트
Posted by 영회
사용자 삽입 이미지

파티(TSE2007)가 있어 KSUG 공지가 늦어지는 것 같았다. 파티가 끝났으니 Jaime(호주에 있는 SpringSource 직원)를 독촉하여 공지를 올려달라 했다. 시간대가 비슷해서 그런지 바로 응답이 왔다. 어제 접수 서버를 둔 곳에 정전이 있어서 접수를 못하고 있다. 어제 확인한 숫자가 100여명 정도라고 하는데 KIPA 강당이 200인실이라고 하니까 사전 접수 못한 분들이 있다고 해도 현장 접수가 가능할 것이다. Toby형도 오늘 귀국이구만.
Posted by 영회
TAG KSUG
이글은 SDS SW 센터 뉴스레터에 기고한 글을 허락을 얻어 공개하는 것입니다.
사용자 삽입 이미지

스프링을 통해 진화하기


요즘은 스프링 프레임워크에 대해 말하는 사람들을 흔히 만날 수 있습니다. 한동안 오픈 소스 소프트웨어에 대한 미신으로 스프링 도입이 어려웠던 상황을 생각해보면 흐뭇한 일입니다. 하지만, 아무리 좋은 도구라도 목적에 맞게 사용해야 제 구실을 합니다. 그래서, 스프링을 적용하고 있거나 배우는 분이라면 다시 한번 목표를 점검해보는 것이 어떨까요?


스프링 소스코드가 아름다운 이유

스프링의 아버지인 로드 존슨(Rod Johnson)은 최근 올린 글 Our approach to the JCP에서 Spring Source(Interface21의 새로운 회사 이름)가 자바 표준을 만드는 단체인 JCP에 임하는 자세를 기록했습니다. 굵은 글자로 쓰인 Honesty가 유독 눈에 띄었습니다. 예전에 스프링 웹 프레임워크(Spring Web MVC)를 살펴보다가 이해가 안되어서 소스코드를 찾아본 일이 있습니다. 그때 느낀 것이 정직하게 진심을 다해 코드를 작성하면 스프링과 같아지겠구나 싶었습니다.

사용자 삽입 이미지

그림 1. Strategy 패턴을 적용한 스프링 소스코드 일부


그때까지 온갖 패턴을 익히고 블루 프린트(Blue Print)와 프레임워크를 찾아 다니던 제가 그저 평범해 보였던 스프링의 진가를 보기 시작한 순간이었습니다.
동시에 정직하게 하나씩 배워가려고 하지 않고, 새로운 솔루션을 빌어 일거에 해결하려고 했던 마음이 부끄러워졌습니다.

한 순간에 사람이 바뀔 수는 없습니다. 하지만, 그 후로 스프링 곁을 떠나지 못하게 되었습니다. 저마다 다른 이유로 스프링을 대할 것입니다. 저에게 스프링은 개발자의 태도를 말해주는 경전과도 같습니다. (안타깝게도 필자는 그다지 경전에 충실하지는 못합니다. ^^)


스프링을 대규모 사이트에 적용하며

한창 스프링의 매력에 빠져 있을 때 실전에서 사용할 수 있는 기회가 왔습니다. 수백 억대 시스템 구축 프로젝트에서 스프링 도입을 허락한 것입니다.

프로젝트 수행업체는 그때 필자가 소속해있던 컨설팅 회사를 전적으로 신뢰했습니다. 그래서, 필자는 많은 부분을 직접 결정할 수 있었습니다.
스프링의 매력에 더하여 고객의 신뢰는 필자에게 엄청난 힘을 주었습니다. 누군가에게 전폭적인 신뢰를 받는다는 것이 어떤 것인지 독자 분들도 잘 아시리라 믿습니다.

그런 신뢰를 받지 못했다면 감히 스프링 적용을 시도하지 못했을지 모릅니다. 물론, 제가 단지 스프링을 좋아해서 결정한 것은 아니었습니다. 기술적인 면에서 보자면, 스프링 채택은 EJB 프로그래밍 모델을 대치하기 위한 것이었습니다.
대규모 사이트에서는 대부분 CBD 방법론을 적용하여 설계를 합니다. 분석까지는 객체 지향 기반으로 잘 끌고 와도 EJB 프로그래밍 모델에 적용시키려고 하면 설계 모델이 너무나도 복잡해지는 것이었습니다. EJB 컴포넌트는 다수의 클래스나 인터페이스로 구성되기 때문이죠.

그 무렵 필자는 TSS(TheServerSide.com)라는 J2EE 커뮤니티에 배포된 ‘The J2EE Architect’s Handbook’에서 소개한 방법을 채용하여 EJB 배포 모델과 애플리케이션 사이 종속성을 제거하는 기법을 사용하여 설계하도록
설계자들을 가이드 했습니다. EJB는 필수라고 여겼던 필자가 스프링에 관심을 가진 것은 스프링 1.2 버전이 준비될 즈음이었습니다.

사용자 삽입 이미지

그림 2. POJO 프로그래밍을 가능하게 하는 스프링의 3대 기술

The J2EE Architect’s Handbook’에서 제시한 방법보다 진보된 EJB 래핑(Wrapping) 방법을 제시하는 것 만으로도 스프링은 충분히 채택할 가치가 있었습니다.

그런데 스프링은 아예 EJB가 없어도 J2EE 애플리케이션 개발이 가능하게 해주었습니다. 또 한가지 놀라운 사실은 강력한 기능에 비해서 너무나도 쉽게 사용할 수 있다는 것입니다.
물론, 스프링 기반을 이루는 개념을 이해하는 것은 쉬운 일이 아니지만 개발자 모두가 스프링에 정통할 필요는 없으니까요. 필자는 매주 월요일 개발팀을 대상으로 스프링 기반 개발 교육을 했고 개발자들이 마주치는 문제점을 함께 고민하며 해결했습니다. 약 2.5개월로 예상했던 서버 모듈 개발은 한 달로 줄어들었고, 예상 코드 분량의 20%만으로 개발이 가능했습니다.

개발자들 대다수가 자바 개발은 처음이었다는 사실을 고려해보면 정말 놀라운 일입니다. 여러 가지 요인이 있었지만, 스프링이 제공하는 단순한 프로그래밍 모델과 강력한 지원 기능이 한 축을 차지했던 것은 부인할 수 없는 사실입니다.

분명한 목표 설정


자 이제 여러분의 차례입니다. 여러분은 어떤 이유로 스프링을 배우려고 합니까? 스프링이 제공하는 단순하고 강력한 프로그래밍 모델을 활용하여 팀의 생산성을 높이고 싶습니까? 아니면 스프링을 만들어가는 사람들을 닮아가고 싶습니까?

어떤 분 말로는 중국에서는 스프링과 하이버네이트(Hibernate)가 개발자 이력서 필수 기재 항목이랍니다. 유행은 오래가지 않습니다. 그리고, 언젠가는 스프링을 뛰어 넘는 새로운 솔루션이 등장할 것입니다.

중요한 것은 스프링이나 하이버네이트가 아니라 나 자신이 아닐까요? 누구나 스프링을 통해 도움을 얻고 발전하기 위해 스프링을 배우고 사용할 것입니다. 하지만, 목표를 분명히 한다면 보다 영리하게 스프링을 활용할 수 있지 않을까요? 스프링의 놀라운 발전속도를 보면 따라가기에도 벅차 보입니다. 그저 스프링 고수가 되기 위해서 쫓다 보면 곧 지쳐버릴 것만 같습니다. 필자 스스로 그런 생각이 들어서 잠시 멈춰서 자신을 돌아보는 와중에 같은 질문을 여러분에게도 해봅니다.

필자는 구현이 가능한 객체지향 기반의 설계 능력을 키우고 그 방안을 공유하는 것을 내년 목표로 삼았습니다. 그 목표를 위해서 스프링을 적극 활용할 예정입니다. 마치 종교인들이 경전을 읽듯이 스프링의 사상을 담은 책들을 꼼꼼하게 읽어볼 생각입니다. 그리고, 스프링 소스 코드를 통해서 프로그래밍 이디엄(idiom)과 패턴 적용에 대해서 정리해볼 계획입니다. 흥미로운 도전에 대한 계획을 세우니 벌써부터 신이 나는군요.


사용자 삽입 이미지

그림 3. 스프링 배경 철학이 닮긴 로드 존슨의 서적들
Posted by 영회
점심 먹고 올라왔더니 Toby 형이 메시지를 날리더니 TSE에서의 첫날밤 분위기를 전해온다. 올해는 작년과 달리 한국 사람들이 꽤 갔다고 한다. 인형 두 개 짚었다고 자랑한다. 내꺼도 하나 챙겨달라며 아쉬움을 달랬다. 사진까지 보내준다. 젠장. ㅡㅡ;

바로 이 사진인데.. 목에 스프링(Spring)이 달려서 흔들거린다고 한다. 로드존슨 액션피겨라고 할만하다. keith가 이 인형 옆에 놓고 페어 프로그래밍 하면 좋다고 권장했단다. ^^

이번 세미나 참석자 중에 뽑아서 준다고 하니 받는 분은 페어 프로그래밍을 해보시라..

사용자 삽입 이미지

올해 TSE 스케쥴을 보면 스프링의 위상을 여실히 알 수 있다. 이제 스프링을 기능적으로 소개하는 세션 류나 유관 프로젝트 소개는 거의 볼 수 없다. 통합(Integration), 웹서비스, 배치(Batch), 사례연구(Case study), 클러스터링 기법을 포함하여 각종 실무적인 프랙티스 일색이다. 트랙이 5개인지라 일민형 혼자서 모두 들을 수가 없어 아쉽다. 여름부터는 같이 가야지.

아무리 좋은 내용이라도 수용하기 어려우면 괴로운 이야기일 뿐이다. 여름에 갈 것을 대비해서 단계적으로 준비를 해야겠다. 적어도 훌륭한 청중은 될 수 있도록..

일민형은 블로깅 하고 잔다더니.. 와인 한잔 해서 일찍 잠이 든 모양이다. 내일부턴 본격적으로 세션이 시작하니까 이글 보면 블로깅 좀 열심히 해주길..ㅋㅋ

Toby님이 열심히 연재하고 있다.

Posted by 영회
TAG TSE
사용자 삽입 이미지


접수 페이지 바로 가기
Posted by 영회
유스케이스에 대한 고객 검토를 하면서 예상대로 대혼란이 일어났다. 개발자(분석가)들에게 유스케이스 개념을 설명하는 것도 쉬운 일이 아니다. 하물며 현업 고객에게 타원 몇 개 덩그러니 그려놓고 업무 범위를 모두 포괄하는 것으로 보이냐고 물으면...

고객은 오히려 비즈니스 프로세스를 그린 그림은 쉽게 생각했다. 메뉴 구조도를 보여줘도 쉽게 애플리케이션 기능 구조를 파악한다. 메뉴 레벨 2단계를 유스케이스로 잡으라는 어처구니 없는 가이드를 비웃은 적이 있다. 유스케이스는 메뉴로 분할할 수 있는 것이 아니다. 기초도 모르는 사람이 전문가랍시고 가이드 한 것일 수도 있지만, 한편으로는 현장 상황을 반영한 어쩔 수 없는 자구책인지도 모른다.

사용자 삽입 이미지

위 그림은 유스케이스 이해가 어려운 이유를 단적으로 보여준다. 현행 업무가 시스템 도입으로 인해 변모하는 모습(TO-BE)를 담고 있어 애초부터 고객들에게 시스템에 대한 이해에 기반한 상상력을 요구한다. 다시 말해서, 지금은 이렇게 일하고 있는데 앞으로는 다르게 일할 것이라고... 프로토타입 화면도 보지 않고 과연 고객이 이를 알 수 있을까?

필자 스스로도 현재 사이트에서 족보에도 없는 산출물을 만들고 있다. 적어도 국내 SI 현장에선 아직도 개발 과정의 산출물을 넘어서지 못하는 모델이 대부분이다.(그나마도 못하는 경우가 더 많은 것으로 짐작한다.) 고객에게 물었다. 유지보수할 때 모델을 보세요? 고객이 유스케이스 명세를 보나요? 물론 '안본다'가 대답이다. 볼 수 있는 산출물을 만들면서 표준 방법론이라는 틀을 어기지 않으려다보니 족보에 없는 변종을 만들어냈다.

그렇다면 유스케이스가 개발자에게는 유용한가? 비슷한 고민을 하면서 내놓은 해결책을 책으로 발행한 것이 있었다. 거짓말처럼 내가 글을 쓰고 난 후, 10분도 안되서 지인이 알려준 책 서두에 나온 그림을 캡쳐해놓는다.

사용자 삽입 이미지

출처: Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens


Posted by 영회
IBM DW Korea Java 관문 페이지에 'Continuous Integration으로 결점을 조기에 발견하기'가 올라와서 기대했는데 아쉽게 아직 번역이 안되었다. 첫 기사로 올린 것을 보니 곧 번역하지 않을까 싶다.

PDF로 받아본 원문에 대해 애기해보겠다. (DW Korea에 올라올 글에 대한 예고편 정도가 될 듯 하다.)

이 글에서 처음으로 Hudson에 대해 들었다. CI를 위한 도구에 대한 설명이 쭉 이어진다. Ant와 함께 JUnit, PMD, FindBugs. 그리고 CI와 SCM(CVS, SVN 등의 도구)의 관계를 설명한다. 뒤이어 대부분의 내용은 Hudson 설정과 활용에 대한 내용이다. 직관적인 UI가 끌렸다. CruiseControl에 비해 훨씬 호감(?)이 가고 직관적으로 보인다.

사용자 삽입 이미지


CI가 생소한 분은 Continuous Integration을 읽어보세요.
Posted by 영회
이슈 트래커 개발자가 들려주는 이슈 트래커 이야기, Part 1: 무엇을 어떻게 골라쓸까

아쉬운대로 골라서 쓰느냐? 새로운 것을 만드느냐? 필자도 똑같이 고민하던 일이라 120% 공감할 수 있었다. 또한 오픈마루에서 이슈 트래커를 만든다고 하니 반가웠다.

사실 이슈 트래커 뿐만 아니라 유사한 PMS(글에서 소개한 것처럼 trac은 PMS 역할도 한다)나 요구사항 관리도구도 쓸 만한 것이 별로 없다. 기능이 부족해서가 아니라 그 반대다.. ^^; (패러디) 이번에는 달성할 수 있을지 모르지만, 내년에 필자도 요구사항 관리 도구를 오픈소스로 개발해볼 생각이다.

이슈 트래커에 대해 고민해보는 분들이라면 유익한 글이다.
Posted by 영회
분석가들이 요구사항에 대해 기술한 내용을 검토하다가 떠오른 생각을 담아두려고 메모

놀라운 일이다. 출근 길에 읽었던 짧은 글에서 답을 찾을 수 있다니.

문제 속에 답이 있다.

수학멘토 앞부분에 나오는 내용이다. 함수에 대한 정의를 시스템 개발에 대입하면 요구사항이라는 정의역(domain)시스템이라는 공역에 대응시키는 활동이라 할 수 있다. 그런데 요구사항을 분명히 파해쳐 이해하지 않고서 해법을 구할 수 있을까?

답은 자명하다. 요구사항 기술에 대한 오류는 해당 분석가가 요구사항을 이해하지 못했음을 보여준다. 분석가를 포함하여 개발자들은 종종 문제에 대해 충분히 고민해보지 않고 개발을 하려 든다. 더구나 개발 과정을 통해 문제에 대한 인식이 높아져 자신이 해온 작업에 수정을 가해야 하는 피치 못하는 상황에 닥쳐서는 변경에 강한 적대감을 보이기도 한다. 어처구니 없는 일이지만 매우 흔히 볼 수 있다.


수학멘토 - 10점
장우석 지음/통나무
문제를 푸는 것은 결과가 아니라 과정이다. 시스템 구현이라는 것도 결국은 애초 문제에 새로운 문제를 더한 것에 지나지 않는다. 과정을 즐기지 못하면 결국 즐겁게 할 수 없다.

Posted by 영회
일민형이 올만에 마음으로 읽을만한 글을 올렸다. 아이를 갖더니 마음이 내는 소리가 잘 들리나 보다:
What makes people happy at work here

요즘 또 방황을 하고 있다. 사실 근래 들어 그런 것도 아니고 어찌 보면 청소년 시절부터 쭉 그랬는지도 모른다. 이 시점에서 일민형이 쓴 글은 함께 할 수 없는 다른 가치관을 두고 사이에서 방황하는 자신을 명확하게 보게 해준다.

문득 책장이 내 앞에 있다면 지금 꺼내보고 싶은 책이 떠오른다. 이 책도 일민형이 추천해서 읽은 책이구만.


성공하는 시간관리와 인생관리를 위한 10가지 자연법칙 - 10점
하이럼 스미스 지음, 김경섭.이경재 옮김/김영사
Posted by 영회
사용자 삽입 이미지

얼마전 읽은 PEAA 서론부 5줄을 읽다가 나름대로 해석해서 그렸다. 도메인 모델을 중심으로 시스템을 보면 기존 레이어링 그림과는 좀 다르게 인식할 수 있다. 기존에는 비즈니스 로직을 플랫폼에 기반하여 결정한 특정 레이어에 한다. 도메인 모델 입장에서 보면 엔터프라이즈 애플리케이션 개발을 위한 기술 기반이 요구사항이 된다. 보고를 준비하면서 잠깐 짬을 내서 그려봤다.
Posted by 영회
구독목록 중에서 이런 글을 보았다;

내가 SI사업을 발주하는 담당자라면
나는 이런 조건을 넣고싶다.
- 개발업체는 우리회사의 Subversion 서버를 사용해야 한다.
- 개발소스는 one-stop build가 가능해야 한다.
( Subversion에서 checkout을 받은후 build.bat를 치면 target폴더아래에 모든 실행파일(exe or war)가 나와야 한다.)

이 구절을 보고 처음 느낀 점은 곧 이런 문구가 RFP에 오를 수 있겠다는 짐작이다. 많은 사람들이 지적하듯 여전히 SI 사업에 부조리가 많지만 그러면서 서서히 발전하고 있다.

Posted by 영회
사용자 삽입 이미지

요구사항 유형을 정리하고, 그 출처와 추적 관계를 묘사한 그림이다. 이 그림은 기본적으로는 컨설턴트가 작성한다. 체계가 가지는 자체적인 합리성을 보장하는 것은 컨설턴트다. 그러나, 그 내용에 있어서는 현장(도메인) 고유의 합리성을 갖는다. 컨설턴트가 보기에는 비합리적으로 보이지만 현장에서는 그럴 만한 이유가 있어서 나름대로  개념으로 자리잡은 특수성이 자리한다.

1. 담당자와 리뷰를 하면서 한 차례 정제를 한다.
2. 모여서 논의할 때는 완벽한 것처럼 보여도 실제로 적용해보면 예상치 못하는 사례가 발생한다.

잘 정리했다고 해도 쓰이지 않으면 말짱 도루묵이다. 이러한 모델을 이해하기 쉽게 만들고 잘 보급하면 도메인 언어Domain Language 가 된다.
Posted by 영회
사용자 삽입 이미지

위와 같은 다차원 함수를 통해 중요한 것을 먼저 해야 하는 이유를 찾을 수 있다. 다차원 함수일수록 풀기가 어렵다. 변수가 많기 때문이다. 이럴 때 주로 쓰는 방법은 상대적으로 덜 중요한 요인을 특정 값으로 고정하는 것이다.

우리가 어떤 일을 하느냐에 따라서 미래가 달라진다. 한 번에 여러 가지 일을 해결하려면 문제를 복잡하게 만든다. 결국, 선택과 집중이 필요하다. SOC(Separation of Concerns) 원칙도, 선물(The Present)에서 말하는 현재(The present)에 집중하는 것도 다 유사한 맥락에서 이해할 수 있다. 관건은 이해가 아니라 실천이지만... ^^


선물 - 10점
스펜서 존슨 지음, 형선호 옮김/랜덤하우스코리아(랜덤하우스중앙)
Posted by 영회
TAG 선물
알라딘 마일리지 소멸 압박으로 구매한 책. 도올이 쓴 서문부터 기대하게 만든다. 그런데 서문에서 공시적(共時的, synchronic)동시적(通時的, diachronic) 측면이라는 표현이 나온다. 공시적이라는 말은 어느 한 시점에서도 통용될 수 있는 보편적 구조를 말하는 것이고, 통시적이라는 말은 시간의 흐름에 따른 변천 과정을 통관적으로 조명하는 것이라고 한다.

'또 이분법이구나' 하는 생각이 퍼뜩 들었다.


수학멘토 - 10점
장우석 지음/통나무

이분법은 정치적인 대결구도를 만들어낼 때도 사용하지만, 매우 훌륭한 사고의 도구이다. 가만히 보니 공시적과 통시적의 대비는 익숙한 아래 대비와 대응하는 듯 하다.

타입     vs   인스턴스
클래스  vs   객체
공시적  vs   통시적
원장     vs   이력
구조적  vs   동적


Posted by 영회
지난 KSUG 모임에서 Acegi(Spring Security) 발표할 때 모태로 삼았던 글을 번역해서 올렸습니다. 이전에 요청한 것인데 빠르게 대응해주셨네요. 발표 전에 공유했던 글을 보면 개념 정리하는데 도움이 될 수 있습니다. 발표 자료를 안올렸네요. 강의할 때 요청하신 분도 있었는데 주말에 짬을 내서 정리해야겠습니다.

Acegi로 자바 애플리케이션 보안화 하기, Part 1: 아키텍처 개요와 보안 필터 (한글)은 빠르게 Acegi를 읽히고자 할 때 매우 좋은 글입니다. 꼭 필요한 요소들만 간결하게 설명하고 있습니다. 샘플 코드 역시 불필요한 내용이 전혀 없어 KSUG 발표때도 활용했습니다. ^^

좋은 시나리오, 간결한 글, 좋은 샘플도 좋지만, 복잡한 내용에 대해서는 그림으로 묘사해서 별 다섯개를 주고 싶은 글입니다. 추후 LDAP 연계와 객체/메소드 보안을 다룰 2, 3 부가 이어지겠죠?
Posted by 영회
TAG Acegi
잘 적응되어 있을수록 적응력은 감소하는 경향이 있다. 61쪽
품질 팀이 있고, 가이드와 규정이 잘 갖춰진 곳을 보면 전형적인 업무는 매우 효율적으로 처리한다. 반면 새로운 요구나 환경 변화가 불어닥치면 잘 정비한 규정이 오히려 발목을 잡기도 한다. 환경 변화가 심해지는 추세에 따라서 애자일(Agile)이 부각하는 것과도 관계가 있다.

고객은 항상 자기 문제를 어떻게 푸는지 알고 있으며, 항상 해결법을 처음 5분 내에 말해준다. 116쪽
대단히 인상적인 문구라 책을 접어두었던 모양인데, 잘 기억이 안난다. 역시 메모는 바로 해야 한다. 돌연 프로젝트에서 RFP가 프로젝트 후반까지 매우 중요한 척도 역할을 하는 점이 떠오른다.

통상 무엇을 간과하는지 찾아보고 다시는 빠뜨리지 않도록 확실히 해주는 도구를 설계하라. 128쪽
공부법 설명할 때도 항상 '오답노트'가 등장했다. 고르게 신경쓰기 보다는 취약지구에 초점을 맞추는 것이 효과적이다. 위험요소에 초점을 맞춘 프로젝트 관리를 강조하는 UP(Unified Process)도 유사한 맥락이다.

뭔가를 잃는 최선의 방법은 그것을 지키려고 애쓰는 것이다. 201쪽
얼마전에야 그 의미를 알았고, 요즘에야 실천을 할 수 있다.

품질을 위한 마케팅(물량을 위해서가 아니라 품질을 위해서 마케팅하라.) 274~275쪽
1. 컨설턴트는 다음 두 상태 중 하나만 될 수 있다. 한가한 상태 아니면 바쁜 상태.
2. 고객을 얻는 최상의 방법은 고객을 갖고 있는 것이다.
3. 일주일에 적어도 하루는 노출에 시간을 할애하라.
4. 고객에게 당신이 중요한 것보다 당신에게 고객이 훨씬 중요하다.
5. 절대로 한 고객이 전체 사업의 1/4 이상을 차지하게 하지 말라.
6. 최상의 마케팅 도구는 만족한 고객이다.
7. 당신의 최고 아이디어를 거저 주어라.
8. 손수 넣은 계란 하나가 커다란 맛의 차이를 낳는다.
9. 최소한 자기 시간의 1/4은 아무것도 하지 말고 보내라.

주옥같은 지침이다. 나는 이 지침을 실천하기 위해서 주기적으로 스스로를 검증할 것이다.

최소 후회의 원칙: 어느 쪽으로 하든 후회하지 않게 가격을 책정하라. 289쪽
욕심 때문에 무리하게 협상을 하다가 스스로 자충수를 두는 경우는 종종 발생한다.

사람들은 절대 거짓말쟁이가 아니다. 적어도 자신의 눈에는 302쪽
그래서 사람을 신뢰해야 한다. 비난하거나 비판하지 말고... (하지만 너무 힘들어)

농장에서 얻은 교훈 316~317쪽
1. 절대 싸구려 씨를 사용하지 말라.
2. 준비된 토양이야말로 경작에 성공하는 비결이다.
3. 시기가 정말 중요하다.
4. 가장 단단하게 자리잡은 작물은 스스로 뿌리를 잘 내린 것이다.
5. 과하게 물을 주면 강해지는 것이 아니라 약해진다.
6. 최선을 다해도 일부는 죽을 것이다.

역시 자연과 함께 하면 주옥같은 교훈을 얻는다.

컨설팅의 비밀 - 10점
제럴드 M. 와인버그 지음, 홍성완 옮김/인사이트
Posted by 영회
스프링 사용자 모임 다섯번째 마당은 10월 27일에 열립니다.. 대놓고 기대하세요!에 기록한대로 Toby님과 온라인 협의한대로 철저한 준비는 하지 못했다. 둘 다 너무 바빠서 예상만큼 시간을 쏟지 못했다. 그럼에도 불구하고 개인적으로 만족스러웠다.

짧은 시간이나마 효과적으로 준비해서 전달했고, 준비 과정에서 다시 초심으로 돌아갈 수 있었다. 이번 발표가 그럭저럭 잘된 배경에는 기선이와 찬욱이도 한 몫했다.

동국님이 세미나 전반에 대해서 잘 요약했고, 윤걸군이 찍은 사진 일부를 모아둔다.
확대


Posted by 영회
TAG KSUG
무지한 감리인은 목소리와 눈빛으로만 권위를 세우려 하는 감리인을 보며 떠올린 말이다. 제3자가 객관적인 눈으로 프로젝트 상황을 조망한다는 것은 유익할 수도 있다.(사실 몇 일 와서 쓱 파악하고 보고서 하나 써주는 것이 유익한지는 모르겠다.)

종종 소통이 가능한 감리인이 있기도 하겠지만, 귀 막고 말만 하려는 감리인은 대개 무지하다. 짧은 기간에 프로젝트 상황을 파악하려면 귀를 쫑긋 세우고 총력을 다해도 모자랄텐데. 자기가 믿는 짧은 지식으로만 무언가를 만들어내려다 보면 프로젝트 정황 정보를 반영하지 못해 종종 어처구니 없는 실언을 하기도 한다.

두꺼운 보고서 중에서 건질 말은 5%를 넘지 못할 듯 하다.

여하튼 이들을 통해서 한 수 배운다. 누군가 혹은 무언가 지적하고 비판할 때 그 사람/것이 내포하고 있는 의도, 동기 혹은 연계된 정황을  충분히 파악하라고... 그래서 우리는 말하고 소통하는 것을 게을리 해서는 안된다.
Posted by 영회
TAG 감리