Younghoe.Info v3

세상에서 제일 재미있는 디자인 패턴

 

들어가기 전에 잠깐 우리들의 영원한 고전... Hello World를 살펴보자. (만약 당신이 코딩에 대한 경험이 없거나, Hello World가 무슨 의미인지 모른다면, 당장 읽는 것을 중지하기 바란다. 심한 경우, 당신의 우뇌부분에 상당한 손상이 가해질 수 있다. 또한 당신이 MMORPG가 뭐에 쓰는 것이 모른다면. 당장 읽는 것을 중지할 뿐만 아니라, 이 것을 읽으려 했던 사실조차 망각하기 바란다. 그 이유는... 당신은 분명히 재미없는 사람이 틀림없기 때문이다. 이 글은 재미를 추구하는 자에게만 허락된 내용이다.)

 

[Hello World]

"Hello World"를 찍는 다양한 프로그램....

가장 빨리?

가장 단순(LOC)?

재사용성을 높인다면?

String을 찍는 프로그램으로 개발하고, String을 "Hello World"으로 입력?

"Hi, YourName."을 찍는 것으로 바뀌었다면?

이때 별도 File 입출력을 했다면?

편지의 앞 또는 마지막 서명 형식으로 찍는다면?

Hello World 사이에 공백을 넣어서, 한 페이지에 당신의 얼굴을 그린다면?

목적에 따라 재사용성을 미리 고민할 것인지, 복잡도를 높일 가치가 있는지가 달라진다.

수많은 Decision들. Goal을 알고, 이유Why를 알고, 최적의 솔루션을 찾고, 적임자를 찾고, 맞는 환경을 찾고,...

고객의 생각이 바뀌면 모든 것이 바뀐다!

...

 

흠... 뭔가 요구가 바뀌고, 환경이 바뀌면... 뭐... 체력으로 버팅기지...뭐... 이건 진리지, 진리...

음...글고, 디자인 패턴을 보기 전에 "객체"를 빠삭하게 알아야하는데... 객체 이전의 방법과 객체 지향적 방법을 간단히 살펴보자. 여기서부터 모든 것은 게임으로 통한다. 게임.ㅎㅎㅎ

 

[전통적 프로그래밍]

main()이 있고, initGame()이 있고, startGame()이 있고, endGame()이 있다.

initGame()에는 Player를 만들고, Monster를 만들고, BattleField를 만들고, 암튼 무지하게 만든다.

start()에는 초기 화면이 나온다. 마을일 수도 있고, 전투가 바로 시작될 수도 있다. 모든 시나리오가 이 안에 있으며, (KeyBoard, Mouse)이벤트에 따라 계속 움직이고... Player찍고 땅 찍으면, Player 상태에 따라 달릴 수도 있고 걸을 수도 있다. Monster 찍으면 공격한다. Player의 공격과 Monster 상태를 보고, 다친 정도를 결정한다,... 죽으면 또는 다 죽이면 끝난다.

endGame()이 있다.

 

게임 본연의 기능 외에 CPU Clock, 메모리 최적화 등 비기능적인 문제들은 항상 따라다녔다. 뭐... 이런 것들은 항상... 기본이지.

 

[객체 모델링]

...Player찍고 땅 찍으면, Player는 자기 상태를 보고, 걸을 것인지 뛸 것인지 결정한다. Monster 찍으면 공격하고, Monster는 상대방 공격력과 자신의 상태를 보고 다친 정도 또는 죽을 것인지를 결정한다....

Passive user data type에서 Active user data type이 된 것이다. 객체들은 자기 상태에 따라 적절한 행위를 취한다. 즉, 로직이 객체안에 캡슐화되어있다.

 

객체지향 시대로 접어들면서 데이터와 로직이 캡슐화된 클래스의 등장과 함께, 다양한 관계 표현이 나타났다. 함수 수준의 위임이 클래스 수준의 위임(delegation)으로 확장되기 시작했으며, 상속, 포함, 의존(Dependency), 추상클래스(Abstract class), 인터페이스(interface) 등이 등장했고, 이에 따라 객체들간 다양한 형태의 상호작용 표현이 가능하였다. 실세계의 복잡도를 기능과 데이터로 해체하기 보다는 복잡도 자체를 객체 속에 담고 인터페이스를 통해 보다 유연한 상호작용을 할 수 있는 능동적(Active) 소프트웨어 개념이 언어 속에 스며든 것이다.

 

객체지향 프로그래밍에 대한 메모리 배치를 보면(실제 눈으로 보면... 안보인다.), 코드(Code)와 데이터 공간이 분리되어 별다른 변화가 없는 것처럼 보인다. 객체가 생성될 때마다 데이터 부분의 메모리 공간이 할당되지만 코드는 공유한다. 뭐가 달라진걸까? 객체 속에 static으로 선언되지 않은 일반 멤버함수라면, 자기 자신을 가리키는(this) 포인터가 첫번째 인자로 숨겨져있다. 이렇게 데이터와 코드를 분리했지만, 논리적으로 그들을 엮어 객체라는 개념을 메모리에 실현한 것이다. 이때부터 본격적인 표리부동과 꼼수의 역사가 시작되었고, 객체 모델링이라는 매우 강력한 파워를 얻은 대신 패러다임의 혼란이 시작되면서 1980년대 후반부터 방법론의 춘추전국시대가 열리게 된다.

자... 여기서부터, 나의 게임관이 펼쳐진다. 디자인 패턴을 재미있게 읽기 위해 반드시 거쳐가야하는 놀라운... 게임관이다.

 

[게임]

Any Where, Any Time, Any Game

게임은 인생이다. 아니, 내게 게임은 또 다른 형태의 완전한 세상이다. 모든 것이 있다.

* AnyWhere

게임은 항상 내 곁에 있다. 학교에서는 Portable Game Mashine, 겜방에서는 PC, 길거리에서는 휴대폰... 난 어디에서든 게임을 즐긴다.

 * AnyTime

난 상항 게임을 한다. 심지어는 자면서도 게임을 한다. 게임안에는 나의 분신(GameAgent)이 있다. GameAgent는 허드렛일을 도맡아서 한다. 내가 밥먹고, 잠자는 시간처럼 바쁠때는 스스로를 키워나간다. 내가 게임에 임할때 GameAgent는 나의 행동을 모두 배우고 스스로 규칙화하며, 내가 없을 때 나를 대신한다. 물론 그는 나의 통제하에 존재한다. 나는 24시간 게임을 즐긴다.

 * AnyGame

나의 인생이 하나인 것처럼, 나에게 모든 게임은 하나다. 게임안에 시뮬레이션, 아케이드, 롤플레잉 등 모든 게임이 통합되어있다. 그들 게임은 캐릭터를 공유하며, 서로간 영향을 미친다. 철인경기에서 우승할 수록, 기본 전투력은 급성장하며, 레이싱에서 우승할 수록 나의 지적 판단능력은 높아만 간다. 나는 영웅이며 나는 모든 것을 누릴 수 있는 능력과 권한이 있다. 나는 무적이다.

 

음... 패턴이란 무엇인가를 설명하는 것은 재미없고, 당신이 하고 있는 것들 중 어떤 것을 패턴이라고 말하는 것인지만 알려주면... 끝.

 

[우리나라에서 가장 많이 쓰이는 패턴]

* 가쓰(가장 많이 쓰는) 패턴 - BFP(Brute Force Pattern) : 일명 노가다 패턴, 무뇌 패턴이라고도 한다.

* 다쓰(다음으로 많이 쓰이는) 패턴 - CPP(Cut & Paste Pattern) : 재사용이라는 심오한(!) 철학을 사용하기 시작했다. 설사 남이 만든 코드라도 쓰고 말겠다는 적극적 의지가 돋보였으며, 학교를 통해 CPP를 철저히 익힌후 실제 프로젝트에 지속적으로 적용하였다. 다만 품질 있는 코드의 재사용이 아닌 무분별한 재사용이라는 점 때문에 패턴을 계속 쓰다 보면. 정제되는 느낌 보다는, 음식 냄새가 코드에 스며드는 기분 나쁜 경험을 할 수 있다는 점이 있다. 우리 나라의 뚝배기 스타일이 아닌 스파게티와 꽈배기라는 음식냄새가 코드에서 풀풀 나기 시작한다.

재사용을 좋아하지만 스파게티나 꽈배기를 싫어하는 사람들을 위한 패턴은 없을까?

 

드디어... 진짜 칼을 뺄 때가 왔군... 슈슝. 나의 칼을 받아라.

위와 같이 브라우저에서 로그를 보고 싶다면. 자바 프로그램을 개발할 때 이클립스 콘솔에서 로그를 보는 것이 흔한 일이다. 그러나, LogDigger 홈페이지에 소개한 바와 같은 상황.


통합 테스트 시점에 공용으로 사용하는 테스트 서버 로그 대신 테스터가 자신이 발생시킨 이벤트 로그를 확인할 때 쓸만하다. 아쉬운 점은 FireBug 콘솔에서 결과를 볼 수 있다는 제약. IE에서는 방법이 없다. X-internet 솔루션을 쓴다거나 IE 중심으로 개발하는 국내 정보시스템 개발에서는 큰 도움이 안될 듯 하다. 반면에 Firebug를 이용하여 디버깅을 해야 하는 화면 개발을 함께 하는 자바 개발자라면 유용할 듯 하다.

Firebug에 다시 LogDigger extension를 설치해야 한다. 그리고 나서, jar 파일을 lib에 넣어주고, 필터를 등록해준다. log4j.jar 도 필요하다.

Resource를 보고 그린 그림이다. javax.annotation 패키지에 있는 애노테이션 중심에는 Resource가 있다. javax.annotation 패키지의 다른 애노테이션은 컴포넌트 초기화에 관계된 것이다. (Generated 제외) 이들은 JSR-250(Common Annotations)으로 Java EE 5 에 처음 추가되었고, 다시 Java SE 6 에 포함되었다. 이들 중에서 스프링이 지원하는 애노테이션은 아래 세 가지이다.


이는 한 줄의 코드로 CommonAnnotationBeanPostProcessor를 등록하는 것만으로 가능하다.


@Resource 의 경우 @Target이 TYPE, FIELD, METHOD 모두 가능한 것을 스프링은 매우 효과적으로 활용했다.

TYPE 타겟은 아래와 같이
@Resource
public class AccountRepositoryImpl ...

FIELD 타겟은 이렇게:

@Resource

private DataSource dataSource;

위와 같은 방법을 쓰면, 스프링 초기에 지적받던 setter-based injection은 immutability 저해도 막을 수 있다.

METHOD 타겟은 이렇게 구현했다:
@Resource
public void setDataSource(DataSource dataSource)

스프링은 이들을 좀 더 확장한 애노테이션들을 제공한다.

자세한 사항은 InfoQ의 기사를 통해 살펴볼 수 있다.

Service (economics)에 대한 위키피디아 정의를 보면..


명확하다. 물리적인 재화에 대응하는. 초중때 배운 '3차 산업'이 떠오른다.

A service provision comprises a sequence of activities that does not result in ownership of the outcome, and this is what fundamentally differentiates it from furnishing someone with physical goods.

좀 더 읽어보면 명확해진다. 서비스 제공 결과로 물리적인 재화를 얻는 것은 아니란 점. 기본적으로 시스템은 물리적인 것을 전송하지는 않으니까 서비스업에 속한다. 위키피디아의 내용을 계속 읽어보면 당연한 것을 보면서, 영감을 얻고 있는 나를 관찰했다. 그만큼 통합적 사고에서 멀리 떨어져 있었던 모양이다.

IT 산업은 점차 'without the restrictions of carrying stock (inventory) or the need to concern themselves with bulky raw materials'에 가까워지고 있다. 규모의 경제를 실현한 아마존 S3 나 구글이 선행 모델 역할을 할 뿐, 다른 기업의 경우도 마찬가지가 되지 않을까. X값(?)이 된 LCD TV 가격을 생각해보라. 모바일 디바이스들도 갈수록 하드웨어는 소프트웨어에 끼워파는 모습으로 변모하는 인상을 받는다. 각설하고, 서비스 실현을 위해 공급자가 하는 일은 composing and orchestrating the appropriate level of resources, skill, ingenuity,and experience 이다.

자원, 스킬, 재능, 경험

이를 기준으로 본다면 함수를 만들어보면.. 대충 이런 식

benefits(QoS) = f(R, S, I, E)

이 중에서 투여 비용을 가장 낮출 수 있는 것은 자원을 재사용하는 방법이다. 재사용도만 높이면 서비스가 성공하느냐? 물론 중요한 요소겠지만...


지속적인 서비스 마케팅과 경쟁 우위

여기선 IT 서비스라고 해서 뾰족한 대책은 없어 보인다.

길다.. 일단 여기까지...

위키피디아 정의 항목은 다섯 가지가 있다:

• Service (economics)
• Service (music)
• Service (record label)
• Service (motor vehicle)
• Service (systems architecture)

그 중에서 Service (systems architecture)를 보면 Enterprise architecture, Service-orientation, and Service-oriented architecture 맥락의 정의가 있다.


살면서 수차례 들었을 '서비스'를 지칭한다고 할 수 있을만큼 일반적이다. 특징이라고 할 만한 부분은 business or technical functionality 로 양분한 내용이다.

웹 서비스 관련 컨소시움인 OASIS (organization)의 정의를 보자. 좀 더 구체적이다.


OASIS (organization)는 서비스를 기능성(functionality) 차원이 아니라 일종의 메커니즘(mechanism)으로 정의한다. 앞서 언급한 일반적인 서비스에 대한 정의는 one or more capabilities 에 대응시킬 수 있다.

OASIS (organization)는 서비스 정의를 채택한다면 서비스 정의하는 행위가 좀 더 명확해진다.

• 제공할 기능(capabilities)에 대한 인터페이스 정의(the access is provided using a prescribed interface)
• 제약사항과 정책(constraints and policies)을 담은 서비스 기술 혹은 명세(specified by the service description) 제공
• 서비스 기술/명세 준수하는 시스템 구현(is exercised consistent with ...)

위키피디아의 정의에서 서비스 실현 방안(Service Engineering)도 간단히 설명한다.

업무 기능(Business Functions)을 서비스(Services)로 분할

예가 있다.


사실 SOA 기반이 아니라도 해야 하고, 다들 해오던 일이다. 단지 방식에 있어서 외부와 소통할 수 있게 하는 것이 차이점인 듯 하다. 네트워크를 통해 점차 통합을 향해 가고 있는 세상을 살면서 당연한 일 아닌가 싶다.

위키피디아의 정의는 아인슈타인의 명언 'Make everything as simple as possible but no simpler.'^[각주:1]을 실천했다. :)

위키피디아에서 서비스 기술/명세에 대해 설명하는 부분은 매우 구체적인데 읽어도 감이 오지 않는다. 일반적인 내용만 털어내면:

• 프로세스 모델에 대한 상세한 정의(경우에 따라 시스템간 교신 감안)
• 일련의 성능 지표(availability, duration, rate 등)
• 조직의 정보 모델과의 연계(서비스를 기준으로 어떤 정보를 관리해야 하고, 어떤 정보를 외부 서비스에서 공급받아야 할지)
• 소비자 역할을 하는 서비스(해당 서비스에 의존하는 서비스 목록)

여기까지... 조금 더 구체적인 내용을 습득하기 위해선 Reference Architecture for Service Oriented Architecture Version 1.0 으로..

써니님의 글을 읽다가... 생각나서
원저자인 Grady님의 허락을 구해 올립니다.

출처: 'Grady의 골 때리는 디자인 패턴' 중에서

호응이 있으면 MMORPG와 엮어서 디자인 패턴을 어디에 써야 하는지 짧은 글로 명쾌하게 설명한 'Grady의 골 때리는 디자인 패턴' 을 제 블로그에 연재하도록 하겠습니다.

전체 구성만 훑어본 정도라 내용에 대해 말하긴 이르지만....
닷넷쪽에서 요즘 희귀한 가이드를 찍어내듯이 발표한다.
이 바닥에 일하는 자바 개발자로서 누군가는 자바 기반으로 해석/변환 해서 정리해야 하지 않을까?

Agile Architecture Method Pocket Guide
Web Application Architecture Pocket Guide
RIA Architecture Pocket Guide
Mobile Application Architecture Pocket Guide
Rich Client Application Architecture Pocket Guide
Download the Service Architecture Pocket Guide

"Spring Python" 파이썬 개발자에게도 봄(?)을

Java > Editor > Templates 에서 Import 해서 사용할 수 있다.

포함하는 템플릿

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

debug ... if 조건이 있는 debug 문 작성용


참고: 자주 쓰는 구문 템플릿(Templates)으로 등록하기

TDD line 이라니 한글 '줄'을 번역한 모양이다. 본문 첫줄을 보면 '안할까'는 Anhalkka로 번역했다.

내 글을 누가 볼까 하고 가끔 레퍼러 로그를 보는데, 간혹 번역을 통해 블로그를 보는 이들이 있다. 그 중에 메신저로 연락하면 친구가 된 Rob도 있다.

일민형이 대답을 요구하는 글을 썼다. 알면서 왜 안할까? TDD

대답은 명쾌하다. 의지가 부족할 뿐.

나는 의지가 투철한 사람이 아니다. 초중고는 물론이고 대학교는 물론 회사에서까지 끊임없이 지각을 하는 행태를 고쳐야지 마음먹어도 이렇게도 오랬동안 고치지 못하는 것이 이를 입증한다. @@

그런데도 왜 자꾸 포스팅을 하고 난리냐? 부족한 의지를 채우는 나름의 방식이다. 좋은 글을 통해 만날 수 있는 동시대인들의 동경하는 모습은 부족한 의지를 극복하는데 도움을 준다. 그리고, 그때 생겨나는 열정이 식어버리기 전에 흔적을 남기는 수법이 아닐까 싶다. ^[각주:1]

한 가지 확실한 것은 적어도 나에게 있어 TDD는 일단 아침에 일찍 일어나는 것보다 쉽다. 그래서, 그리 멀지 않아서 'TDD를 하자'고 말할 필요도 없는 상태가 오지 않을까 기대하고 있다. 그때 되면 또 딴거 하자고 (스스로를 그리고 나와 같은 생각을 하는 이들을) 선동(?)하고 나서겠지만...

테스트 스위트를 어떻게 정리할까 고민하고 있는데 관련 글이 올라왔다.

My Unified Theory of Bugs

이 그에서는 테스트를 세 가지로 분류했다. 실용적인 분류다. 내가 즉흥적으로 메모한 분류와도 일맥한다.

- 클래스 수준의 단위 테스트
- 리소스나 DB 값을 확인하기 위한 테스트
- 설정 정보를 확인하기 위한 테스트
- 성능 테스트

일찌기 Scott Ambler는 시계열까지 동원해서 훨씬 더 복잡하게 테스트를 정리한 바 있다.

Miško Hevery는 테스트 하기 좋은 코드(Testable code)가 갖춰야 하는 요건으로 다음과 같은 사항을 제시하면서 다른 글을 소개한다:

• Clear separation between classes (Testable Seems) --> clear separation between classes makes it less likely that a wiring problem is introduced. Also, less code per class lowers the probability of logical bug.


• Dependency Injection --> makes wiring explicit (unlike singletons, globals or service locators).


• Clear separation of Logic from Wiring --> by having wiring in a single place it is easier to verify.

말미에 눈에 띄는 얘기를 한다.


읽고 보니 그렇다. 테스트를 하지 않고 머리속으로 테스트 하기 좋은 코드를 작성하거나, 작성한 뒤에 테스트를 하면서 수정하기 보다는 당연히 먼저 테스트를 할 때 테스트 하기 좋은 코드를 작성하기가 수월할 것이다. :)

2008.11.21 점심 시간 추가:

최근 스프링을 사용하는 고객이 다음과 같은 문제를 올렸다: Long 타입이 oracle에 integer로 맵핑되는 문제

DTO 객체에서 Long으로 정의한 필드 값이 insert나 update할 때 integer 처럼 들어간다는 것이었다.


확인해보니 integer 처럼이 아니라 Integer로 들어가게 되어 있었다. 동료가 문제를 찾았는데 내가 그 코드를 확인해보니 문제가 없었다. :) 로컬에 서로 첨부한 소스 버전이 달랐다. 구글링을 해보니 쉽게 버그 리포팅을 찾을 수 있었다: SPR-4840

 javaTypeToSqlTypeMap.put(long.class, new Integer(Types.INTEGER));
javaTypeToSqlTypeMap.put(Long.class, new Integer(Types.INTEGER));  

2.5.3 버전에서 버그를 찾은 Pavel Marinchev은 수정할 코드까지 제시했다:

  javaTypeToSqlTypeMap.put(long.class, new Integer(Types.BIGINT));
 javaTypeToSqlTypeMap.put(Long.class, new Integer(Types.BIGINT));

StatementCreatorUtils 클래스 소스를 보면 정적 블럭으로 초기화하는 코드 중에 이를 볼 수 있다. 아쉽게도 해당 버그에 대한 테스트 코드^[각주:1]는 찾을 수 없었지만, 2.5.5 ChangeLog에서 변경사항을 찾을 수 있었다:
* BeanPropertySqlParameterSource uses specific integer/decimal SQL types by default now (e.g. TINYINT, BIGINT, DOUBLE)

spring.jar 라는 jar 파일만 보면 버전을 알 수 없다. Manifest를 열어보니 2.5.4 임을 확인할 수 있었다. 이럴 때는 번거롭더라도 Maven을 사용하여 라이브러리를 명시적으로 관리하는 것이 이점이 있어 보인다. 일민형이랑 채팅하다가 'jar 버전 테스트를 해야 한다'는 말에 바로 테스트를 추가하기로 했다. 권남님한테 배운 것인데 SpringVersion 클래스를 이용하면 매우 쉽게 테스트 작성이 가능했다.


참고로 2.5.6 과 2.5.4 버전에서 위에 언급한 코드 차이를 보여주는 부분을 첨부한다.

찾아보니 2년 전에도 같은 내용의 글,  G메일과 구글 카렌더를 함께... 구글 개인화된 홈을 쓴 바 있었다. 구글 개인화 페이지는 나에게 맞지 않아 접었다. 마일린 사용 빈도가 높아지면서 노트북을 사용한 일정관리가 늘고, 프랭클린 다이어리의 역할이 많이 줄었다. 로딩 속도가 느려서 한 동안 쓰지 않던 구글 캘린더를 다시 도입해보려고 한다. 메일과 왔다 갔다 하는 번거로움을 줄이려고 Integrated Gmail을 깔았다.


메일과 캘린더를 한 화면에 넣었다. 더불어 CustomizeGoogle 확장을 통해 스팸함의 카운터를 안보이게 했다. 평소 빈번하게 스팸함에 카운터가 보이면 지워주느라 매일 시간 낭비하던 것을 없애줄 것이다.

이틀 정도 써보니 종종 적용이 안되고, Gmail이 뜨기도 해, 이럴 때 카렌더가 필요하면 새로 고침을 하기도 했다. BetterGmails2나 GustomizeGoogle을 함께 써서 그런 것인지도 모른다. 아직 유용한지 결론을 내릴 수 없지만, 적어도 없는 것보단 좋다. @@

SRS(Software Requirements Specification)의 중요성을 보니 떠오르는 게 있어 포스팅합니다. 소프트웨어 공학은 잘 모른다고 해도, 현장 경험을 쌓다보면 수학 문제뿐만 아니라 소프트웨어 개발 역시 문제 속에 답이 있음을 배웁니다. SRS(Software Requirements Specification)의 중요성을 읽고 당장은 '음, 그래' 하고 공감을 한다고 하더라도 실천하는 과정에서는 수많은 시행착오를 거치게 됩니다. 예전에 저는 현장에서 겪는 시행착오를 이런 저런 글로 쓴 바 있습니다. 저 역시 그 안에서 시행착오와 함께 배우고 있습니다. 검색해보니 근 2년쯤 전에 이 정도까지 배웠더군요. 최근에 술자리에서는 이런 말을 한 바 있습니다.


이 내용을 좀 더 일반화시켜서 표현하면 다음과 같습니다.


SRS(Software Requirements Specification)의 중요성에서 언급한 것처럼 SRS 템플릿은 매우 중요합니다. 우선 잘 만들어진 템플릿은 그렇지 않은 것에 비해 쉽게 작성할 수 있습니다. 결과적으로는 시간을 아껴주죠. 이를 개발 생산성 향상이라고 표현하기도 하죠. 그러나, 이때도 함정이 있습니다. 표준화라는 이름으로 자칫 일관성을 지나치게 강조하다가 중요하지 않은 것을 강제하는데 시간을 쏟는 경우들이 있습니다. 경험적으로 SRS 작성할 때 혹은 요구사항을 정리할 때 다음과 같은 내용이 도움을 줍니다.

• 요구사항이 아닌 것을 정의하기(가령, 화면 그리드 기능을 정의한다고 하면, '동적인 컬럼 추가는 배제한다' 등)
  
• 위와 같은 맥락으로 요구사항 검증 기준을 수립하기
• 요구사항이 다양한 추상화 수준을 띄거나 다른 요건에 따라 영향을 받는 다면 혼선을 빚지 않도록 정리하라(사례: 요구사항에 대한 도메인 모델)
  

Trac
Trac과 함께한 2주
이슈트래커(trac) + Mylyn의 효용성
이슈트래커(trac) 설정 + 마이린(Mylyn) 연결
TRAC 0.10.4 Window 설치 정리
Subversion, Trac, SSL 함께 설치하기
Trac, 설정 파일(trac.ini)의 비밀
Trac과 SVN 연동: svn revision -> trac ticket 연동 

mylyn
마일린(Mylyn) 사용 팁
이슈트래커(trac) 설정 + 마이린(Mylyn) 연결
이슈트래커(trac) + Mylyn의 효용성
Mylyn 버전 문제로 인한 로그인 오류
Mylyn 2.0, Part 1: 통합된 태스크 관리
Mylyn 2.0, Part 2: 자동화 된 콘텍스트 관리 (한글)

이슈 트래커 비교
위키피디어 이슈 버그 관리 시스템 비교
이슈 트래커 개발자가 들려주는 이슈 트래커 이야기, Part 1: 무엇을 어떻게 골라쓸까
JIRA와 다른 이슈트랙커 비교 및 관련 정보
15 Useful Project Management Tools

JIRA
Using Keyboard Shortcuts on JIRA
JIRA를 이용한 이슈관리
JIRA Installation
Tomcat 6, MySQL에 JIRA(WAR/EAR 버전) 설치하기
요즘 프로젝트 진행을 JIRA로 보면...

Mingle
Mingle: Team Collaboration and Project Management Made Easy

이클립스에서 Ctrl 키와 함께 클릭을 하면, 해당 식별자가 정의된 곳으로 이동한다. 클래스를 클릭하면 클래스를 정의한 자바 파일로 가고, 메소드를 찍으면 자바 파일에서 해당 메소드를 향해 가고, 변수를 클릭하면 변수를 정의한 곳으로 이동한다. 그런데 소스 코드가 없는 클래스 혹은 그 클래스의 메소드를 클릭하면 어떻게 될까? 다들 알다시피 다음과 같은 휑한 장면을 만나게 된다.


위에서 Attach Source... 버튼을 클릭하고, PC 어딘가에 다운받은 소스를 찾아 넣어주면 내가 사용하는 클래스나 라이브러리로도 이동할 수 있다. 이와 같이 소스를 부착하고 쓰다 보면 자연스럽게 내가 사용하는 라이브러리에 대한 지식이 높아지고 디버깅도 용이하다. 물론, 해당 소스를 읽는다는 전제가 따른다.

부가적으로 몇 가지 이점을 더 갖는다. 소스에는 Javadoc 주석이 있기 때문에 Javadoc API를 이클립스에서 바로 볼 수 있다.


여기에 더해서 잘 드러나지 않지만, 코딩 생산성(?)에 꽤나 영향을 미치는 효과가 있다. 이클립스 JDT에서 자동 완성(Code Assist)은 이제 없어서는 안될 기능이다. 소스가 없는 라이브러리를 사용할 때 자동완성을 사용하면 다음과 같이 변수명이 만들어진다.


문맹(?) 수준의 자바 구사를 하고 싶다면 그대로 두어도 좋다. 그러나, 대부분의 상식적인 개발자라면 변수 이름을 변경할 것이다. 사용하는 API가 늘어나면 수정을 위해 타이핑하는 자판 수나 마우스클릭도 늘어난다. 사실 이보다 더 두드러져 보이는 현상이 하나 더 있다. 다음과 같이 소스 부착을 한 후에 생겨난 자동 완성 코드를 보자.


만일 rejectValue() 메소드에 들어가는 인자/매개변수가 뭔지 가물가물하다고 생각해보자. 나에게 그런 일은 너무나도 잦다. 그럼, API 문서를 열어서 볼 것인가? 만일 위와 같이 생성되었다고 해보자. 적절한 작명으로 만든 API라면 굳이 문서를 열 필요가 없다. arg0, arg1 이라면 문서가 필요하지만... ^^

지난 번에 IBM 개발자 수다에 갔는데 SI 개발자들의 지나친 야근이라는 화두가 있어 우리 경험을 들려줬더니 호응이 좋았다. 그래서, 관리자로서 가치 있다고 판단하고 실천하는 과정을 남겨본다.

매주 요일을 정해서 프로젝트 내부 세미나를 한다고 했더니, 지인이 어떤 걸 대상으로 하느냐고 물었다. 그래서 '딱히 정해진 건 아니고, 매주 설계에 관해서 오래 얘기할만한 것들을 모아서 한다'고 답했다. 그랬더니 단순히 업무연장이라고 판단했다. 업무 연장이긴한데 분명 다른게 있다는 점을 말해주려는데 쉽게 설명이 어려웠다. 그래서 동기부터 이야기를 해야했다.

애초에는 프로젝트 팀에 야간에 대학원에 가거나 신혼인 팀원이 있었다. 배려가 필요한 직원들이 최초 동기 부여 요소였다. 프로젝트 관리자로서 딱히 시급한 일이 아닌데 야근을 종용할 수는 없었다. 그러다 보니 흐름을 갖고 논의해야 할 중요한 이야기들을 중간에 그만둬야 할 때가 있었다. 이런 류의 논의는 맥락이 중요한데 그 날 마치지 못한 맥락을 다음 날에 이어가는 것은 많은 노력을 요했다. 종종 시간에 쫓겨 충분히 검토하지 않은 아이디어가 그대로 구현되어 버리는 경우가 발생했다. 그래서, 매주 요일을 정해놓고, 팀원 모두가 합의 하에 설계 리뷰를 하기로 했다. 하지만, 매주 논의할꺼리가 균일하게 쌓이는 것은 아니다. 지난 주에 처음 시행을 했을 때는 평소 수행하는 리뷰 회의와 다른 것이 없었다. 그래서, 두번째는 조금 형식을 바꿨다.

우선 프로젝트와 간접적으로 관계가 있으나 프로젝트 참여자가 아닌 사람을 참여시켰다. 그렇게 하자 리뷰에서 다루는 내용은 프로젝트 내용이긴 해도 설명은 다소 일반화 되었다.^[각주:1] 그리고, 리뷰 내용은 향후 문서화를 염두해서 준비하도록 했다. 리뷰 준비는 원칙적으로 코드 조각이나 작동하는 프로그램으로 시연을 하는 방식이거나 발표자료 형식으로 준비를 하기로 했다. 토의때 논의하는 내용을 적절히 메모를 해서, 여러 주에 나눠서 연속으로 진행하는 세션은 흐름을 가진 스토리로 향후 문서화 가능하게 하기로 했다.

외부인의 참여로 리뷰 장소도 평소 프로젝트에서 회의하던 공간이 아니라 내방객 참여가 가능한 회의실로 바뀌었다. 이러한 형식적인 변화로 인해 우리의 내부 세미나는 더욱 "세미나"다워(?)졌다. 세미나 결과는 기대 이상으로 좋았다.팀원들은 서로 다른 팀원의 작업을 압축해서 전달받을 수 있었다. 지식 전달 효과가 상당히 뛰어났다. 이러한 효과는 유기적인 준비 과정에서 나왔다. 나는 관리자로써 이번 주 해야 할 일 중에서, 기술 세미나가 최소한의 기준 이상의 효과가 나오는 것을 주요 과제로 삼았다. 생소한 시도일수록 첫 인상이 스테레오 타입으로 남기 때문이다. 지난 주에 팀원 개별적으로 자신의 작업 가운데 발표할 사항을 선정하고 계획하게 했고, 어떤 내용(코드? 문서?)으로 발표할 것인지 확인했다. 그리고, 발표 전까지 적절한 간격을 두고 진척을 확인했다.

프로젝트 팀 입장에서 보면, 기술 세미나를 통해 평소 불현듯 튀어나와 회의 시간을 길게 잡아먹던 잠재 이슈를 상당히 줄일 수 있을 것으로 기대된다. 대개 불필요하게 긴 회의나 논쟁은 고객과 개발팀, 관리자와 개발자, 설계자와 개발자, 서로 다른 개발자 등과 같이 협업 대상 사이에서 '나와 같이 생각하고 있겠지' 하고 묵시적으로 갖고 있던 생각이 다르다는 사실을 인지할 때 시작하는 경우가 많다. 우리가 만일 내부 기술 세미나 상시화를 "정말로" 성공한다면, 적어도 개발팀 내에서는 암묵적인 인식차를 주기적으로 줄일 수 있을 것이다. 이는 오해로 인해 똑같은 이야기를 여러 차례 반복하는 일과 오해가 만들어낸 재작업을 줄여줄 것으로 믿는다.

상시화가 성공한다면, 우리 팀을 위한 다음 스텝도 준비하고 있다. Martin Fowler가 그렇게 한다고 들었는데, 프로젝트 경험을 문서화 해서 인쇄물로 공개하려고 한다. 개인적으로 블로그에 종종 공유하지만, 팀원들과 함께 문서를 작성해본 일은 드물다. 그들에게도 자기 생각을 전달하는 훈련을 할 겸, 나와 다른 생각을 섞어서 공동의 창작물을 만드는 일은 쉽지 않겠지만, 충분히 유익할 것이다.

프로젝트 설계 리뷰를 진행하면서 교훈이 될만한 내용을 정리해본다. 한 팀원이 사전 준비 자료에 다음과 같은 그림을 넣었다. 아래 그림이 등장한 배경은 복잡한 오류 처리 방식을 개선해보자는 것에서였다. 그 중에서도 '오류가 나는 상황에 따라 다른 로그를 남기기 위해서 각 상황과 로거(Log4J를 사용한다는 전제하에)의 관계를 얘기해보자'는 논의 이후에 아래 그림이 나타난 것이다.


헌데 그림은 솔루션 영역만 그려져 있었다. 문제 영역이 나타나있지 않다. 위 그림을 보고 어떤 논의를 할 수 있을까? Log4J 내부를 공부하고자 할 때는 위 그림이 효과를 발휘할 것이다. 하지만, 지금 우리에겐 그렇지 않다. 문제 제기를 팀원이 받아들여 적절히 변경한 결과, 리뷰 때 위 그림은 사라졌다. 사전 필터링 과정에서 적절하게 자료를 바꾼 결과로, 우리는 충분한 시간을 몰입해서 의미있는 논의를 할 수 있었다.

만약 저 그림을 프로젝터로 투사했다면 무슨 이야기를 할 수 있었을까? 아마도 누군가는 '왜 저걸 보여주지'하는 생각에 사로잡혀서 다음 화면으로 넘어가기를 기대했을 것이고... 발표자는 화면에는 저걸 보이고, 말로는 다른 이야기를 했을지 모른다. 그러다 참가자 중 누군가 Log4J에 대해 평소 궁금했던 것을 늘어놓거나 UML 사용법에 대한 질의가 이어지거나,  Log4J 무용담이라도 등장하면 리뷰 시간을 자연스럽게 날려버릴 수 있다.

스크롤 해야 할 만큼 많은 버그가 보인다. 물론, 상당부분이 테스트 코드에서 발생한 것이지만, spring 코드에도 버그가 꽤 있다. 코드를 드려다보면 '과연 이를 버그라고 해야 하나' 의문이 드는 것도 있다. FindBugs는 소스코드를 분석하여 버그 혹은 버그로 의심할 수 있는 코드를 찾는데 도움이 되기는 하지만 만병통치약은 아니다.

Spring, Grails를 품에 안다

우리는 개념 설계를 시작했다.


클라이언트와 서버 사이의 데이터는 Service Context 로 묶어서 전달한다. 굳이 "Service" Context인 이유는 설계를 리딩하는 팀원이 선호에 의한 것이다. 작명에 대해 충분히 논의한 결과는 아니다.



ServiceContext 에 담길 데이터 구분 내역이다.


이제 개념 검증을 위해 dojo 기반의 javascript mvc 예제를 참고로 하여 POC(Proof of Concept)를 한다.

웹 표준 UI는 애초에는 개발 범위에 없던 내용이었다. 개발팀에서 고객사 상황에 비춰볼 때 UI 쪽 학습 비용을 줄이는 것이 관건이라고 판단해서 제안한 내용이다. 추가로 무언가를 개발하려면 기존에 계획한 무언가는 개발 범위에서 빼야 한다. 돈을 지불한 입장에서야 무언가 추가하겠다면 반가운 소리겠지만, 뺀다고 하는 이야기는 쉽게 수긍할 수 없는 것이 당연하다. 우리는 고객 설득을 위해 자료를 만들었다. 그 가운데 전체적인 맥락을 설명하는 그림도 포함시켰다. 이해관계자 전체가 같은, 적어도 비슷한 방향을 바라보고 일을 해야 하니까.


웹 표준 UI의 기초가 될 자바 스크립트 라이브러리는 몇 가지 기준을 가지고 비교한 후에 결정했다.


GPL 라이선스로 자유롭지 못한 ext.js는 후보에서 배제했고, 결국 jQuery를 선택했다.

참고로, 고객은 대체로 UI를 가볍게 여기는 경우가 많다. 이럴 때 기술적으로 고객을 설득하려고 시도하면 성공하기 어렵다. 고객의 입장에서 UI에 투자했을 때 얻을 수 있는 점 혹은 투자하지 않았을 때 잃게 되는 점을 설명하는 것이 좋다. 우리는 다음과 같은 근거를 들어 고객을 설득했다.

• 화면 자동 생성 데모 시연
• 새로운 UI 솔루션(X-인터넷 제품 등)을 처음으로 도입할 때 겪는 긴 학습/개발기간
• 직원 교육 필요성: 자바는 고객사 SM 인력들에게 신규 시스템을 개발/운영을 위해 필수지만, 화면 기술은 다시 변경할 수 있어 교육 효과가 떨어짐
  
• 스크립트 언어가 갖는 개발 환경의 어려움(취약한 IDE, 디버깅의 어려움)
  

잊지 말아야 할 것은 고객의 관심사에 맞춰서 이야기하는 것이다.

IE8을 설치해서 쓰다가 문제가 생겼는데... 어디서 지워야 할지 몰라 헤맸다. 프로그램 제거에는 없고, 업데이트 설치 제거에서 찾을 수 있었다. @@

본격적으로 설계에 들어가기 전에 우리는 서로의 아이디어를 나눴다. 서로 공유한 설계 주안점은 다음과 같은 사항이다.

• API 스타일
• 클라이언트와 서버 사이의 데이터 전송 방식
• 외부 라이브러리에 대한 의존성
• 기존 제품/코드와의 호환성 혹은 양립 문제

API 스타일은
사용자층이 웹 개발에 친숙하지 않은 정보시스템 개발자이기 때문에 태그를 선택했다. 자바에 비해 자바스크립트나 DOM 스크립팅은 학습비용이 상당히 높기 때문에 태그 개발자와 사용자로 개발자를 분류하는데 역점을 뒀다. 구체적인 API 스타일은 예시 코드를 만들면서 설계하기로 햇다.

클라이언트와 서버 사이의 데이터 전송 방식
JSON 선호. DTO 나 Map 기반으로 변환하는 것이니까 JSON만 가능한 것은 아니다.

외부 라이브러리에 대한 의존성
기존 화면 코드들이 protoype에 의존하고 있는데... 이번에는 dojo나 jQuery를 쓸 예정이다. 이러한 변화에 대해 완충지대를 만들기 위해 어댑터를 떠올렸다. ext.js의 설계가 눈에 들어왔다.


하지만, 개념을 검증하기 위한 코드(POC)를 만든 팀원이 위젯 성격으로 패키징한 코드를 깔끔한 래핑하기 어려울 것이라는 의견을 제시했다. 하여 아직 분명한 필요가 없는 시점에서 처음부터 과도하게 힘 빼지 않기로 했다.

기존 제품/코드와의 호환성 혹은 양립 문제
prototype 기반의 기존 코드와의 호환성은 배제하기로 했다. 기능적으로 워낙 차이가 커서 새로운 프로그래밍 모델이 등장할 것이기에 호환성은 의미가 없다.

종종 '산출물 작업'을 고객 때문에 어쩔 수 없이 하는 요식 행위로 보는 경우를 볼 수 있다. 이에 대해 꽤 공감할만한 글이 있다:

프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?

좋은 내용이지만, 자신의 상황과 연결지을 수 없으면 느낌이 약하다. 문서 작업이 필요하다고 느껴서, 문서 작업을 하다가 위 글이 생각나서 문서 일부를 공유해본다.


얼핏 보아선 그냥 말로 해도 될만한 간단한 그림이다. 그러나, 회의를 통해 위 그림 한 장에 그려진 내용을 전달하다 보면 훨씬 긴 시간을 소모한다. 상황을 재연해보자. 이 그림을 그리는데 혼자서 20분 정도를 사용했다. 내가 위 내용을 공유해야 하는 사람이 4명 더 있다고 치자. 4명에게 일일이 위 내용을 설명하느니 회의를 여는게 났다고 판단해서 회의를 하기로 했다. 위와 같은 그림이 없이 회의를 하면, 아무래도 그림이 있을 때보다 오랜 시간이 걸릴 것이다. 최소 10분만 더 걸려도, 10 * 5 = 50분이 추가로 소비된다. 이해관계자가 늘어나면 그림 즉, 산출물의 위력이 더 커질 것은 두말할 나위가 없다.

역할 변경이 별 거 아니라고 보고 얘기를 안하거나, 꼭 보고를 해야할 대상 즉, 고객이나 상위 관리자에게 단지 '역할이 바뀌었다'라고만 보고했다고 치자. 그럼 어떻게 될까? 역할변화를 반영하지 않고, 일을 진행하는 기간이 생길 것이다. 기존에 홍길동 과장이 하던 업무라 생각하고, 관련한 실무자는 이제는 임꺽정 대리가 할 일에 대해 홍길동 과장에게 문의를 할 것이다. 다들 알겠지만, 이런 일을 일컬어 '의사소통이 안된다'라고 한다.

웹과 세미나의 장점만 모은 웨비나(webinar)

아직 KSUG에 공지도 하지 않았는데 일민형이 정보를 흘렸다. 마치 내가 바쁘단 핑계로 안할까봐 못을 박으려는 듯.. ^^


잘 정제한 내용이지만, 좀 더 리얼하게는 이렇다. 어제 오후 요구사항 큰 축을 변경하여 WBS를 새로 짜야 하느라 고민하고 있는데, 호주에서 토비옹이 채팅으로 대뜸 스크린캐스트 대신에 웨비나를 하라고 독촉했다. 순간 머리속에는 '새로운 시도를 할 때 들어가는 노력', '토비옹이 딴지 걸 것을 대비한 부가적인 사전 준비', '시청자가 필요한 웨비나 특성상 공지하고 반응을 기다려야 하는 부담' 등이 스쳐갔다. 그래도, 자꾸 권유를 하니까. 동영상 녹화의 최대 단점이 떠올랐다. NG가 나면 다시 해야 하는 것과 피드백이 없는 것. 지난 IBM DW 시리즈의 경우 3편은 듣기에 거불할 정도였는데, 늑장 등록을 해서 확인을 못해봤다. 그럼에도 불구하고 중간중간 실수한 부분 때문에 다시 녹화했다.^[각주:1] 그렇게 놓고보면 시간대가 문제지 웹비나가 비용 대비 효과가 좋은 듯 하다. 일민형이 좋은 툴을 발견했고 테스트도 해봤고, 단기간 무료로 쓸 수가 있다. 영구적으로 웹비나를 하려면 비용이 꽤 필요하다. 공언한 바대로 KSUG에서 자체 마련하거나 기업에서 필요한 웹비나를 해주고 후원을 받거나 해야 할 듯 하다.

웨비나 주제는 @MVC 즉, 스프링 2.5 스타일의 MVC 구현이다. 기존에 Spring MVC를 써본 분이라면 뭐가 달라졌는지를 데모를 통해 보여드릴 예정이다. Spring MVC를 안 써본 분이라면 Strut류의 타 MVC에 비해 스프링 MVC가 얼마나 유연하고 똑똑한지 확인하는 자리가 될 것이다. 관심있는 분들은 시청하고 싶은 시간대를 올려주시면 참고가 될 듯 하다. 대강 다음 주에 진행할 것인데, 주중이며 늦은 밤이고... 이번주 일요일도 가능은 한데.. 아직 모르겠다.

그래서... 관심 있는 분들은 여기서 혹은 블로그 댓글로 의견 주세요.

디벨로퍼웍스 늦가을 행사: “개발자들의 수다”

• 일 시: 11월 8일 토요일 오후 2:00~6:00
• 장 소: 도곡동 군인공제회관 23층 온디맨드홀 (약도 참고)
• 참가 신청
  참가 신청은 전자우편(dWkorea@kr.ibm.com)으로 해주시고, 신청시 이름, 소속, 연락처 등을 적어서 보내주시기 바랍니다.
  장소 관계상 참가 신청은 선착순 200명으로 한정하니, 빠른 신청을 부탁드립니다.
• 그 동안 developerWorks에 기고하였던 김도형, 김석준, 김승권, 김영후, 김창준, 박재호, 송치형, 이영석, 박찬욱, 서광열, 이준하, 지형준, 권용호, 안영회 씨 등 다양한 분야의 전문가들이 참석할 예정입니다.
• 수다 예고편
  "개발자들의 스타트업과 창업", "나는 어떤 일을 잘 할 수 있는가?", "오픈소스에 대한 나의 생각", "개발자들의 제태크", "개발자와의 연애, 불가능한가?", "여성개발자의 커리어패스", "개발자와 QA, 친해지길 바래" 등 이외에도 참가자들이 즉석에서 주제를 제안할 수 있습니다.
• 관련기사: 한국IBM, "개발자들끼리 수다 떱시다"

원문: EarlyPain

comment: 무척 공감이 가는 글입니다. 아래 글도 함께 보시면 좋을 듯 합니다.

• 프로젝트 초반에 이슈화하기
• 혼란스런 프로젝트 초기에서 컨설턴트의 임무
• 반복의 중요성을 반복해서 거론하다
• 애자일 선언 in Practice

토비님이 쓴 기업의 오픈소스제품 공개라는 글을 보니 NHN에서 인수한 제품들을 오픈소스로 공개하는 모양이다. 토비형이 인용한 글을 보면 담당자가 현황을 잘 모르는 것 같다.


'전혀 없다'는 표현은 SDS 애니프레임 공개에 힘을 써온 사람들을 서운하게 할지도 모른다. 공개하는 규모가 어느 정도인지 모르지만, 이미 지난 6월에 SDS에서 공개한 애니프레임 역시 작은 규모는 아니다. 기자의 해석인지, SDS 담당자의 의견인지 모르지만, 기사를 보면 다음과 같이 말하고 있으니까.


기업은 자사의 이익을 위해 행동하게 되어 있지만, 어떤 형태로든 기업이 오픈소스를 활용한다는 측면은 분명 긍정적인 것 같다. 그런 점에서 한중일 3국이 협력하려는 조짐도 눈에 띄고, 정부 부처에서 기업의 오픈소스 활용을 적극적으로 도우려는 조짐도 보인다. 기사에 따르면, 정부 부처가 나서서 라이선스 검증을 위한 시스템을 만든다고 하는데 매우 반가운 일이 아닐 수 없다.


오픈소스를 활용하거나 자사 산출물을 오픈소스화 하려는 기업은 앞 서 소개한 곳 뿐만은 아니다. 이런 일을 추진하는 입장에서 꽤나 큰 장벽은 라이선스 문제다. 기업 내에 존재하는 법무팀의 경우도 오픈소스에 대한 경험이 부족하여 속시원한 답변을 해주지 못하는 경우가 비일비재하기 때문이다.

문두는 오해를 낳을 수 있는 문구를 지적했지만, 근래 보이는 오픈소스 활성화 조짐과 의미있는 정부 부처의 노력이 반가워서 글을 쓴다. 그런데 왜 이런 일을 문화체육관광부가 하는 지는 모르겠다. 이미 이런 곳도 있어왔는데, 컴퓨터프로그램보호위원회도 그렇고.