Younghoe.Info v3

구글코드(google code)와 Mylyn 연동

영회 — Mon, 09 Nov 2009 18:03:39 +0900

Using Mylyn with Google Code - Updated for Eclipse 3.4 (Ganymede) 을 따라 해서 성공

몇 가지 주의할 사항을 메모:

1. 가니메데(JEE)에는 Mylyn Connector: Web Templates (Advanced) 가 없어서 설치해야 한다. 업데이트 URL: http://download.eclipse.org/tools/mylyn/update/incubator

2. Eclipse Outliner (Google Code)가 제공하는 Query Pattern 값에서 개행문자(\n)를 빼야 Type, Priority가 작업 목록 표시 이름에서 빠짐

3. 처음에는(default) 활성(open) 이슈 목록만 반환한다. 즉, Query Request URL 값이 아래와 같이 설정되어 있다.
${serverUrl}/csv?colspec=ID+Status+Type+Owner+Summary

쿼리 요청 URL 형식이 다음과 같아서 can 파라미터 기본(default) 값이 2라고 추측할 수 있다.

Query Request URL:: ${serverUrl}/csv?can=${can}&colspec=ID+Status+Type+Owner+Summary&q=${search}

만일 마감한(closed) 이슈도 함께 보고 싶으면 Query Request URL 값에서 "can=1"로 지정해야 한다.
${serverUrl}/csv?can=1&colspec=ID+Status+Type+Owner+Summary

참조: http://alblue.blogspot.com/2009/04/google-code-and-mylyn-redux.html

JUnit 테스트 활용 사례

영회 — Fri, 06 Nov 2009 09:00:00 +0900

실용적 접근은 최근 전 분야에 걸쳐 대 유행이다. 설계 접근으로써 TDD에 대한 논쟁은 많지만 아쉽게 경험(practices)에 대한 공유는 찾아보기 힘들다. 그래서, 대단한 경험은 아니지만, JUnit 테스트를 특정 목적에 맞게 활용한 사례를 공유한다.

1. JUnit 테스트 작성을 통해 미지의 코드를 학습하기^[각주:1]
현장에서 일하다보면 많은 사람이 겪는 상황이 있다. 누군가 짜 놓은 프로그램(API)을 사용해야 하는 상황이다. 보통은 담당자 혹은 사수에게 묻거나 문서를 찾아본다. 경험상 오래된 코드는 기존 코드를 이해하기가 그리 쉽지 않다. 먼 옛날 선조(?)들이 밝혔지만, 개발보다는 유지보수에 훨씬 비용이 든다. 그 중에서도 기존 코드를 파악하는데 소비하는 시간/노력이 가장 크다.

실제로 겪은 일이지만, 혹시 경험이 없는 분을 고려하면 이런 가정을 해보자. 특정 시스템 인프라를 써서 시스템을 개발해야 하는 상황이다. ESB나 EAI, MCI, DW 뭐든 좋다. 그런데 애초에 시스템을 개발한 인력이 없어졌고 문서조차 없이 운영하는 아슬아슬(?)한 상황이라고 생각해보자. 잘 알지도 못하는 시스템 인프라를 써야 하는 개발자는 어찌 해야 할까?

흔히 쓰는 방법은 유사 사례의 기존 코드를 찾아 분석하는 방법이 있다. 확실한 방법이지만, 고생이 심하다. ㅡㅡ;

이보다 아주 조금 좋은 방법이 JUnit 사용이다. API를 설명하는 문서조차 없어도 이클립스가 제공하는 행복한 환경 덕이 크다. 객체를 생성한 후 점만 찍어도 API 함수 정도는 알 수 있는 바로 그 기능 말이다. 이를 활용해서 그럴싸한 함수(메소드)를 호출해서 결과를 확인해본다. System.out.println() 으로 확인한 후에 마무리는 assertXXX 함수로 정리한다.

이런 방법으로 오류 상황과 해당 시스템과 연동할 때 필요한 입출력 파라미터를 정리한 경험이 있다. 약 3일에 걸쳐 순수하게 8시간 정도 투입해서 필요한 사항을 충분히 파악한 경험이 있다. 만일 소스 코드 분석만으론 훨씬 더 오랜 시간이 걸렸을 일이다. JUnit을 안 쓰고 디버거를 활용해도 같은 결과를 얻는다. 그러나, 원격 시스템까지 고려한 배포를 해야 한다는 점을 고려하면 기다리는 시간이 만만치 않다. 적어도 JUnit으로 했던 시간보다는 더 걸린다. 물론, JUnit 사용법에 익숙치 않은 분에겐 예외다.

툴 사용에 익숙해야 생산성이 난다. 요즘 툴 사용에 대한 경험을 공유하고 싶어 집필에 대해 심각하게 고려중이다. :)

내년 어느 때에 KSUG 혹은 JCO 컨퍼런스에서 실제 코드를 가지고 경험을 공유하는 자리를 만들 생각이다.

2. 사후 테스트를 작성해도 회귀 테스트 위력은 대단하다
이미 여러 차례 회귀 테스트 위력에 대해서는 이야기했다. Test First는 우리 환경에 맞지 않다는 이야기를 워낙 많이 들었고, 조엘 말마따나 컴파일 항목이 아닌 외부 요인을 건드리는 테스트는 워낙에 힘들기도 하다. 그런 점을 인정하더라도 사후 테스트를 자동화 테스트로 작성하는 일은 충분히 가치가 있다. 두 어 차례 프로젝트에서 저항하는 다수 개발자에 대항하여 테스트 케이스를 작성하게 했다. 결과는 어떨까? 링크한 효과만도 대단한 결과지만, 문화라 할 만한 효과를 얻었다.

테스트 작성 전에는 '왜 테스트가 필요하냐?' 혹은 요구사항이나 표준이 바뀌면 글씨 하나 바꾸는 일에도 핏대를 세우던 개발자가 변한다. 테스트 작성을 하고, 리팩토링 하는 일에 익숙해진 개발자는 놀랍게도 서너 달만에 변화를 쉽게 수용했다. 변화에 대한 적응력을 갖는 점을 실제로 목격하곤 정말 놀랐다.

3. 문서화
개발자는 문서를 좋아하지 않는다. 작성도 싫어하지만, 잘 읽지도 않는다. 그래도 필수 사항은 알게 하려고 예제를 만든다. 그런데, 겉으로 드러나지 않는 작동원리(mechanism)는 예제를 만들기 쉽지 않다. 그래서, 주요 단면을 보여주기 위해 테스트 케이스를 만든 일이 있다. 그렇게 만든 테스트 케이스를 갈고 닦다보니 놀라운 경험을 했다. 책에서는 테스트 케이스가 요구사항에 대한 명세 역할을 한다지만, 피부에 와닿지는 않았다. 그러나, 적어도 작동원리나 조건에 따라 다른 결과가 드러나는 현상을 규명하는데는 놀라운 효과를 발휘했다. 심지어 자바를 처음 접하는 노련한 프로그래머에게 테스트 케이스를 보여주니 평소에 자기가 원했던 것이라고 반기는 일도 있었다.

물론, 한계는 있다. 모델이라고 부를 수 있는 큰 그림은 문서로 표현해야 한다. :)

Toby 형한테 배운 기법임을 밝혀둔다. [본문으로]

흐르는 강물따라 살아가는 찰나에서...

영회 — Thu, 05 Nov 2009 09:00:00 +0900

누구 말대로 허여멀건 스킨으로 바꾸고 블로그를 버려뒀다. 그러다 술 한잔 한 김에 Toby 님의 도발(?)에 응답한다. 아아~ 목소리 제대로 나오려나?

요즘 변화의 소용돌이 한가운데 있는 고객과 만난다. 제3자 입장에서 냉정하게 볼 수 있지만, 당사자는 매우 힘들어한다. 머리로는 이해하지만 사실 난 모른다. 그런 일을 겪을 기회가 없었으니까. TV를 보면 '변화가 제일 쉬웠어요.'라는 광고속 발언을 들을 수 있다. 후배 덕에 그 회사에 대해 좀 들었는데, 두 가지 측면에서 정말 놀라운 일이 벌어졌다. 회사 기밀일 수 있어서 더 언급은 자제한다.

생업 와중에 이런 격변기를 관찰자로 보내다 보니 마치 내가 포레스트 검프가 된 듯한 기분도 든다. 他山之石으로 배우는 바는 스스로 바꾸지 않으면 당한다는 사실이다. 대나무처럼 바람에 휘지 않으면 꺾인다.

또 한가지 배우는 사실이 있다.

나라를 빼앗기고 다시 토지 배분을 하다 보니 선점한 사람에게 돌아가는 이익이 크다. 그 이전부터 있었지만, 조선시대 김선달이 유명하지 않은가. 선점의 비법은 20년쯤 전부터 복부인이 계승했다. 대형 사업인 SI 분야도 비슷한 듯하다. 선점한 이들이 안락하게 시세차익(?)을 많이 얻었다. 그런데 종말이 멀지 않은 듯하다.

어차피 나 역시 한 시대를 살아가는 중생이다. 중생으로서 거대한 시간의 흐름을 마치 남의 일인 양 보는 재미가 쏠쏠하다. :)

자주 틀리는 표현

영회 — Thu, 05 Nov 2009 08:30:00 +0900

가능성이 높다 → 가능성이 크다
(의지를) 가지고 → (의지를) 갖추고
감안해 → 고려해, 참작해, 살펴, 생각해^[각주:1]
(~을/를) 갖고 있지만 → (~가) 있지만
검색을 할 → 검색할
갖아보면 → 가져 보면
관심을 갖는 → 관심을 두는
구비한 → 갖춘^[각주:2]
그러나, → 그러나^[각주:3]
근자에는 → 요즘에는
금새 → 금세^[각주:4]
(능력이) 급성장하다 → 급향상하다
기반한 → 기반을 둔
꺼림직한 → 꺼림칙한
꺽인다 → 꺾인다
꽤나 → 꽤 ^[각주:5]
나올라나 → 나오려나
난이도도 높고 → 어렵고
너무 좋아서 → 아주/매우 좋아서
누구말대로 → 누구 말대로
다달을수록 → 다다를수록
대개의 경우 → 대개
도식화 한다 → 도식화한다
동일하게 → 같이
뒤 이어는 → 뒤이어는
뒷풀이 → 뒤풀이
들여다 보면 → 들여다보면
맞냐 → 맞느냐
몇 일 → 며칠
모양을 띈다 → 모양을 띤다
무엇이었냐 → 무엇이었느냐
바꾼 후 → 바꾸고
방치했다 → 버려뒀다
병기하기 → 함께 적기
보내다보니 → 보내다 보니
보여질 → 보일
부르짓던 → 부르짖던
부합하는 → 맞는
분명 → 분명히
불러지는 → 불리는
블로그스피어 → 블로고스피어
빼앗긴 후 → 빼앗기고
빽빽히 → 빽빽이
사용할 수 있는 방법은 → 사용하는 방법은
새 집으로 → 새집으로
수 밖에 → 수밖에^[각주:6]
쉽상인 → 십상인
스스로도 → 자신도^[각주:7]
않는가 → 않은가
얼마전 → 얼마 전
얼핏보면 → 언뜻 보면
의례 → 으레
~의 경우 → ~는
이로 인해 → 이 때문에, 이로 말미암아, 이 탓에, 이 덕분에^[각주:8]
이와 같이 → 이처럼
익숙치 → 익숙지 ^[각주:9]
~인 반면 → ~이지만^[각주:10]
일체 없다 → 일절 없다
제3자 → 제삼자
주눅들어하는 → 주눅이 들어하는
중생으로써 → 중생으로서
지불한 → 지급한, 낸
지져분하게 → 지저분하게^[각주:11]
짖굳게도 → 짓궂게도
짜투리 → 자투리
쪽팔리게시리 → 쪽팔리게끔
촉진시켜 → 촉진해
최선을 다하지 → 온 힘을 다하지/기울이지
컨퍼런스 → 콘퍼런스
컬럼 → 칼럼
큰 경우에 → 크면
필요로 할 → 필요할
하고 있는 → 하는, 한 ^[각주:12]
하길래 → 하기에
~하기 위해서는 → ~하려면, ~하려고
하다보니 → 하다 보니
한 가운데 → 한가운데
한가지 → 한 가지
한김에 → 한 김에
해외여행 → 외국/재외/국외여행
향후 → (순화용어) 앞으로
혼돈스럽게 → 혼란스럽게
휴대폰 → 휴대전화
휴우 → 후유
힘든 → 어려운^[각주:13]
100 여 → 100여

수집 동기: 한국어 맞춤법/문법 검사기 쓰기에 따른 개선 활동

일본어에서 온 말입니다. [본문으로]
일반 순화 권장 용어로, 되도록 고쳐 쓰면 좋습니다. 따라서 굳이 쓰고 싶다면 써도 됩니다. [본문으로]
문장 첫머리의 접속이나 연결을 나타내는 말(접속부사 또는 연결을 나타내는 부사어) 다음에는 반점을 씁니다. 다만, 일반적으로 쓰이는 접속어('그러나, 그러므로, 그리고, 그런데'와 이에 대응하는 '이러나, 이러므로, 이런데') 뒤에는 쓰지 않음이 원칙입니다. [본문으로]
'금새'가 '물건의 시세나 값'의 의미로 쓰였다면 옳습니다. 그러나 많은 예에서 '금세'의 오용으로 '금새'가 사용되고 있습니다. [본문으로]
'보통보다 좀 더한 정도로'를 뜻하는 단어는 '꽤'입니다. '나'가 보조사이므로 '꽤나'처럼 쓸 수도 있지만, 부사는 조사가 필요하지 않으므로 '꽤'로 씀이 적절합니다. [본문으로]
'-밖에'가 '오직 그것뿐임'을 뜻하면 조사이므로 앞의 명사에 붙여써야 하고, '-밖에'가 '바깥, 범위나 한계를 넘어선 부분'을 뜻하면 '밖 (명사)+에 (조사)'이기 때문에 앞 명사와 띄어 써야 합니다. [본문으로]
'스스로'는 '저절로, 자진하여, 제힘으로'를 뜻하는 부사인데, 국어사전들이 부사 외에 자기 자신을 뜻하는 명사로 보아 '스스로가 스스로에게 물어 보라', '스스로를 생각해 보아라' 등의 용례를 보이고 있으나 분별 없고 치졸한 짓이다. 이 말 역시 아무 조사도 붙이지 말고 부사로만 써야 한다. [이수열, "부사를 옳게 써야 글이 산다", 말과글, 70권, 1997년 봄호, 32∼35쪽] [본문으로]
순화용어(일본어/외래어) -に因り, -에 인하여)을 옮겨다 '-로 인하여'로 쓰고 있는 말입니다. 영어(by+사물)를 번역하면서도 이를 가져다 쓰기도 합니다. 이는 토씨 '-로'가 '원인'이란 뜻 구실을 하므로 아예 '인해, 인하여'가 필요 없을 때가 많습니다. 대체로 명사 '탓·때문·덕분'이나 '-로 말미암아'로 바꿔써야 할 말입니다. 개정된 민사 소송법에는 '-로 인해'를 대체로 '-로 말미암아'로 바꿔 쓰고 있습니다.[한겨레 신문 자체 자료에 따름]" [본문으로]
[본문으로]
뒤에 오는 말이 앞의 말과 상반됨을 나타낼 때 '반면'이라는 말을 씁니다. 주로 '-은,는 반면에'의 형태로 쓰는데 한자어보다 '-지만'이라는 접속 조사를 쓰는 것이 좋습니다. [본문으로]
'ㅓ'와 'ㅕ'가 다른 자음에 붙었을 때 비슷하게 소리납니다. '지져분'이 아니라 '지저분'이 바릅니다. [본문으로]
'있다'가 보조용언으로 쓰이면 앞말이 뜻하는 행동이나 변화가 끝난 상태가 지속됨을 뜻합니다. 하지만, 용언에 현재형 어미를 쓰는 것으로 현재를 나타냄에는 무리가 없으므로 '있다'는 빼고 씀이 적절합니다. [본문으로]
'어렵다.'가 더 구체적으로 뜻을 전합니다.
예) 고르긴 힘들어 → 고르긴 어려워
낙관하기는 힘들다 → 낙관하기는 어렵다
[본문으로]

작업(Task)으로 기록하기 힘든 것

영회 — Fri, 23 Oct 2009 17:57:00 +0900

* 갑자기 불려가서 하는 회의
* 소프트웨어 업데이트(브라우저 등)
* 조언을 구하는 팀원이나 지인의 메시지에 응대하기
* 회의실을 예약해놓고, 승인을 기다리는 시간 (승인 여부에 따라 공지를 하고, 예약을 다시 해야 함)

이슈 트래커를 통한 작업 관리를 하며... 갑자기 생각나서 메모
단순 인터럽트로 보기 힘든 모호한 작업으로 공수 측정의 헛점

필수 프로그램 다운로드 주소 및 사용법 가이드 v2

영회 — Fri, 23 Oct 2009 11:25:29 +0900

노트북 새로 깔면서 필수 유틸리티 활용 환경 만들기 v3 나 Launcy를 모두 검색하기 v3 등을 정리했는데, 집에 PC도 곧 새로 깔아야 한다. 프로그램 구하는 URL과 사용법 링크를 준비

프로그램	다운로드 URL	사용법
빵집	http://www.bkyang.com/	-
Vista Switcher	http://www.ntwind.com/software/vistaswitcher/download.html	환상적인 Alt-Tab 대체 유틸리티 VistaSwitcher :: 웹초보의 Tech 2.1
Everything	http://www.voidtools.com/download.php	데스크탑 검색 툴 새로운 강자 Everything!!
Launchy	http://sourceforge.net/projects/launchy/files/	키보드로 몽땅 해결하는 Launchy 사용법과 활용팁 (1)
파이어폭스	http://www.mozilla.or.kr/ko/firefox/	초보자에게 추천하는 파이어폭스 확장기능 베스트 8
teracopy	http://www.codesector.com/download.php	윈도우의 아쉬운 2%를 채워주는 프리웨어 Top 10
KeyTweak	http://webpages.charter.net/krumsick/	윈도우의 아쉬운 2%를 채워주는 프리웨어 Top 10
Screen Hunter	http://www.wisdom-soft.com/sh/sh_free.htm	윈도우용 프리웨어 스크린샷 프로그램 screen hunter
Notepad++	http://sourceforge.net/projects/notepad-plus/files/	Notepad++ 의 몇가지 부가기능 사용하기
Autoruns	http://live.sysinternals.com/autoruns.exe	Sysinternal의 시스템 관리 프로그램을 한자리에.. Sysinternals Live
MKN TaskExplorer	http://www.mkn-software.de/en/software/desktop/taskexplorer/	Sysinternal의 시스템 관리 프로그램을 한자리에.. Sysinternals Live

전략사고 컴플리트북 메모

영회 — Thu, 22 Oct 2009 12:30:00 +0900

이러한 상황 속에서도 대부분의 기업들은 어떻게든 베이비붐 세대까지는 함께 끌고안고 가기 위해 필사적으로 노력하고 있다. 그러나 이들이 곶감을 모두 빼먹어 버린 후의 회사에는 현재의 주력 세대를 끌어안아 줄 힘 같은 것은 남아 있지 않다. 시험삼아 당신이 근무하는 회사의 사원 명부와 재무제표를 비교하여 베이비붐 세대의 퇴직금을 모두 지급했을 경우, 어느 정도의 현금이 남게 되는지 계산해 보라. 대부분의 회사는 빈 껍데기만 남게 된다는 것을 알 수 있을 것이다.

전략사고 컴플리트북 19~20쪽

- 일본이나 우리나 같은 시대상
- 후반부(시험삼아 ~) 냉철한 현실 인식 방법 ... 배우자

지식을 습득하는 일과 그것을 실제로 활용할 수 있는가의 사이에는 깊은 틈이 존재한다.

전략사고 컴플리트북 24쪽

- 훈련 필요

전략사고 컴플리트북 33쪽

- Fact to Act

전략사고 컴플리트북 43쪽

하늘 단계의 사실 수집과 비 단계의 사실 분석에서는 우직하게 사실(=팩트)을 직시할 필요가 있다. 분석은 사실에만 기초하여 실시하면 된다. 주관적인 의견은 필요하지 않다.

전략사고 컴플리트북 44쪽

전략사고 컴플리트북 48쪽

전략사고 컴플리트북 -
가와세 마고토 지음, 현창혁 옮김/일빛

이클립스 새로 설치하고 할 일 v3

영회 — Thu, 22 Oct 2009 09:08:15 +0900

1. 필수 플러그인 설치

자동화 테스트(JUnit)를 위한 이클립스 필수 유틸리티

2. 설정 변경

오피스 파일이 이클립스 안에서 열리는 일 방지: 이클립스에서 엑셀 파일 바로 띄우기
자주 쓰는 단축키 추가: 이클립스에서 사용자 단축키 만들기 v1.1
단축키 인터셉터(?) 제거: 이클립스 단축키 살려내기
코드 템플릿 반영(import): 이클립스용 자바 코드 템플릿
Liberation Mono으로 폰트 바꾸기(위키 피디아 예제와 달리 이클립스에 적용하면 숫자 0 가운데 점이 있다.): 다운로드

3. 튜닝

Heap 메모리 보기 설정: Preferences -> General 에서 Show heap status를 체크
GC 줄이기 위한 메모리 설정: eclipse.ini에서 -Xms와 -Xmx 값을 -Xms1000M -Xmx1000M 로 변경
불필요한 플러그인 초기 기동 방지: Preferences -> General -> Startup and Shutdown 에서 디폴트로 선택되는 플러그인 중 불필요한 것 제외 (내 경우는 모두 불필요함)
저장시 Organize Imports 자동 실행: Preferences -> Java -> Editor -> Save Actions에서 Perform the selected actions on save와 Organize imports 를 순서대로 선택
워크스페이스 자동 리프레시 설정: 이클립스 밖에서 워크스페이스 파일 수정한 경우 자동으로 이클립스에서도 인식하게 함. Preferences -> General -> Workspace 에서 Refresh automatically 선택
자바 파일 아이콘을 다양하게: 자바 파일을 펼쳐야 해당 파일이 Class, Interface, Enum 중에 어떤 타입을 정의했나 알 수 있다. Preferences -> General ->Appearance -> Label Decorations 에서 Java Type Indicator를 선택하면, 자바 파일 아이콘이 Class, Interface, Enum 등의 타입 정보가 드러나게 바뀐다.

eclipse.ini 예제

참고:

Optimize Eclipse in 5 Steps

이클립스 단축키 랭킹놀이 v2

영회 — Wed, 21 Oct 2009 14:06:33 +0900

벤자민의 글을 보고 돌연!

벤자민의 선택:

Code Assist (CTRL + Space)
Quick Fix (CTRL + 1)
Refactoring (ALT + SHIFT + T)
Source (ALT + SHIFT + S)
Surround With (ALT + SHIFT + Z)
Delete Rows (CTRL + D)
Call Hierarchy (CTRL + ALT + H)
Quick Type Hierarchy (CTRL + T)
Quick Outline (CTRL + O)
Show All Shortcuts (CTRL + SHIFT + L)

아래는 내 선택:

Code Assist (CTRL + Space)
Quick Fix (CTRL + 1)
Quick Access (CTRL + 3) ^[각주:1]
Refactoring (ALT + SHIFT + T) ^[각주:2]
Source (ALT + SHIFT + S) ^[각주:3]
Delete Rows (CTRL + D)
Maximize Active View or Editor (CTRL + M) ^[각주:4]
Back/Forward (ALT + LEFT/RIGHT)
Quick Outline (CTRL + O)
Open Resource (CTRL + SHIFT + R)

한국 스프링 사용자 모임 메일링에 공유했더니 다양한 노하우가 주렁주렁 달렸습니다.

특히 주목을 끄는 단축키를 모아 보면:

Open Task (CTRL + F12) - Mylyn
Open Editor Drop-Down (Ctrl + E)
에디터 활성화 (F12 )

벤자민과 다른 선택을 굵게 표시 [본문으로]
빈도로 따지면 Rename... (ALT + SHIFT + R)을 압도적으로 많이 쓰지만, Refactoring 하위 메뉴를 모두 뺄 순 없네. [본문으로]
getters/setters 만들 때 주로 씀. [본문으로]
순전히 노트북 사용 때문에 자주 씀. [본문으로]

Launcy로 모두 검색하기 v3

영회 — Tue, 20 Oct 2009 09:08:59 +0900

launchy를 배워 쓰다 보니 매우 편리했다. Weby라는 플러그인을 통해 즐겨찾기나 검색엔진과 연결해주는 기능이 있음을 알았다.

1. 즐겨찾기 검색
내친김에 먼저 즐겨찾기 바로가기를 찾아 시도했다. 파이어폭스 3 에서는 about:config으로 들어가서 browser.bookmarks.autoExportHTML의 값을 true로 바꿔주고 파이어폭스를 재기동하고 나서 카탈로그를 다시 만들어야(Rebuild Catalog) 했다. 이제 즐겨찾기 이름을 기억한다면 바로 페이지를 열 수 있다.

2. 검색엔진 호출
다음으로, 검색엔진을 연결해본다. launcy를 쓰기 전까지는 파이어폭스에 필요한 검색엔진을 추가해서 썼다.

Weby에 설정은 간단하다. %s가 문자열로 바뀐다는 사실과 검색 결과 URL 형식만 알면 쉽게 설정할 수 있다.

추가한 내용:

내 블로그 내 검색
RFC 검색
JSR 검색
구글 이미지 검색
Naver 사전 검색
구글 코드 검색
Krugle
약어 검색 (v3에서 추가)^[각주:1]

Google Image 등은 모두 입력하지 않고, Gooi 나 goi만 입력해도 찾아준다.

설정을 다시 사용할 수 있을까? 설정 화면에서 import/export 기능은 제공하지 않는다. 하지만, 수작업 import/export는 가능하다. 비스타 기준으로 C:\Users\ahnyounghoe\AppData\Roaming\Launchy 폴더를 보면 Launchy.ini 파일이 있다. [weby]로 구분한 영역을 아래 내용으로 바꾸고 Rebuild Catalog 명령을 실행하면 import 완료!

3. 파일 및 폴더 검색
웹초보님 블로그에서 편리하고 빠른 검색 :: Launchy에서 Everything 검색하기라는 글에서 찾을 수 있다. 그대로 하는 대신에 응용해서 Runner 플러그인을 사용한다. Runner plugin options 를 다음과 같이 설정한다.

Name: find
Program: C:\Program Files\Everything\Everything.exe
Arguments: -search $$

find 라고 입력하고, Tab키를 누른 후에 검색어를 입력한다. Everything의 검색 속도는 정말 놀랍다.

4. 다운로드 파일 검색
옵션 catalog 탭에서 각종 메신저나 브라우저에서 내려 받은 파일을 바로 찾기 위해서 파일 내려 받은 디렉터리를 추가하고 모든 파일 유형(*.*)을 지정한다. 다운로드 받은 이후 바로 사용할 때는 유용하지만, 2번 이상 쓰지 않는 경우도 있다. 설치 파일(installer)이 대표 사례인데, 이와 같은 경우 다른 폴더로 옮겨서 검색 대상에서 뺀다.

dictionary와 thesaurus 둘 대신에 통합해서 보여주는 thefreedictionary로 교체 포함 [본문으로]

파이어폭스에서 특정 영역을 제거하기

영회 — Tue, 20 Oct 2009 08:30:00 +0900

Adblock Plus 설치만으로도 광고 대부분이 사라진다. 그러나 포탈 사이트에서 눈을 현혹하는 플래시는 남아 있다. 약간의 설정으로 제거할 수 있다. 하루에도 수 십 통을 보는 지메일에 있는 광고는 Adblock Plus 설치만으로는 해결을 못 한다. 이를 가능하게 하는 확장 기능이 따로 있다. 이제 ABP 아이콘을 클릭하면 '감출 요소 선택'이라는 메뉴가 나타난다. 친절하게 Ctrl+Shift+K 단축키도 제공한다.

이제 광고 없이 지메일을 읽을 수 있다.

대소문자 변환 이클립스 단축키

영회 — Thu, 15 Oct 2009 15:56:22 +0900

* 다시 떠올리기 위해 날짜 갱신

대소문자 변환 단축키를 잊어버려서, Ctrl+Shift+L 키로 단축키를 찾아본다. Ctrl+Shift+X 또는 Ctrl+Shift+Y 다. 아쉬운 건 토글이 안된다는 점...

자동화 테스트(JUnit)를 위한 이클립스 필수 유틸리티

영회 — Thu, 15 Oct 2009 15:38:58 +0900

Update 주소 메모할 겸 기록함

* Test Coverage 측정: Alt+Shift+X, T 대신 Alt+Shift+E, T만 써주면 OK
http://update.eclemma.org/

* TestCase와 테스트 대상 사이에서 Jump to 지원:
http://moreunit.sourceforge.net/org.moreunit.updatesite/

관련 글:
TDD를 위한 기본 코딩 습관 3종 세트
TDD를 위한 이클립스 메소드 생성 템플릿

자동화 테스트의 또 다른 효과

영회 — Thu, 15 Oct 2009 13:21:25 +0900

SI 현장에서 자동화 테스트를 적용하면서 테스트 작성 여부에 따라 개발자 성향이 바뀌는 모습을 경험할 수 있다. 같은 기반 기술을 사용하지만, 개발 일정이 달라 A 시스템과 B 시스템 개발자 투입 사이에 한 달 정도 공백이 있었다. 국내 SI에선 JUnit 테스트 작성을 필수 활동으로 삼고, 테스트 내용이 적절한가 까지 동료 검토 혹은 인스펙션하는 일은 흔치 않아 반발이 심하다. 우여곡절 끝에 개발이 한 달쯤 지나자 90% 가까이 테스트를 작성한다.

A 시스템 개발이 약 두 달쯤 진척했을 즈음의 일이다. 공통으로 사용하는 기반 코드(혹은 프레임워크)에 API 변경이 필요했다. 그래서, 거의 모든 DAO 클래스에 몇 줄이지만 변경이 필요했다. 공교롭게 개발 착수가 늦은 B 시스템 개발자에게 먼저 공지를 했다. 예상대로 상당한 반발을 겪을 수 있었다. 심지어 아직 완성한 DAO가 하나도 없는 개발자마저 변경 발생에 대해 불평을 토로했다. B 시스템 개발자는 한 달 남짓 새로운 개발환경(Spring과 X-internet 사용 기반을 공통화한 기반 코드 사용 및 화면 입력 데이터 및 DB 접근 로직에 대한 JUnit 작성)에 익숙해지는 중이었다.

긴 설득 과정에서 얻은 피로감을 안고 이번에는 A 시스템 개발자에게 공지했다. A 시스템 개발자는 두 달 전과 달리 수정사항에 대해 거부감이 확연하게 적었다. 단지, '바꿔야 하는 이유'와 '현재 방법이 가장 나은가?' 등을 확인해왔다. 안도감을 넘어서 고마움을 느낄 수 있었다. 태도 변화는 어디서 왔을까? 답은 확실했다. 우리는 TDD를 채용하지는 않았다. 무슨 말이냐면, 테스트를 먼저 만들지는 않는다. 사용자 입력 값과 DB 상태를 고려하여 서버측 로직이 정상작동 하는가를 확인하는 기능 테스트를 JUnit 기반으로 작성한다. 어차피 화면을 통해 제삼자가 테스트를 하기 때문에 JUnit이 제공하는 기능 검증 효과는 크지 않았다.^[각주:1] 가장 두드러진 효과는 회귀 테스트가 주는 이점이다.

이와 달리 눈에는 잘 띄지 않았지만, 훨씬 강력한 이점을 발견했다. 아직 대다수 개발자가 JUnit 테스트 작성에 서툴다 보니 동료 검토를 강화했다. 개발자가 코드를 작성하고 나면, 이슈 트래커(툴은 Redmine)를 사용하여 동료 검토를 요청한다. 코드 전체를 몇 사람이 나누어서 검토해주고 지적사항은 '결함'이나 '권고'로 다시 이슈 트래커에 올린다. 처음에는 개발자가 수정에 반감을 갖지만, 반복하다 보면 일상으로 변한다. 일상으로 변하면, 이유가 어떻든 더 나은 코드를 만들기 위해 수정을 수용한다. 회귀 테스트를 갖췄으니 리팩터링은 한결 수월하다. 자동화 테스트를 몇 달 이상 수행한 개발자는 분명히 그렇지 않은 개발자 혹은 테스트 수행하기 전보다 변화에 대해 관대했다. 물론, 테스트를 작성하지 않아도 동료 검토 과정을 통해 성향을 바꿀 수 있다. 하지만, 기준 부합 여부를 명확히 성공이나 실패로 판별해주는 방법이 있는 경우는 그렇지 않은 경우에 비해 확연히 유리하다.

화면을 띄워서 확인하는 기능 테스트를 JUnit 기반으로 대체하려면 테스트 케이스 작성에 더 큰 공수를 투입해야 하는데 현실적으로 어려웠다. [본문으로]

시작 프로그램에 두 번 등록된 버그 해결하기

영회 — Thu, 15 Oct 2009 08:42:00 +0900

일 때문에 쓰는 프로그램이 설치 가정에서 시작 프로그램에 두 번 등록하는 버그를 갖고 있다. 그래서, 시작하자마자 두 개의 프로세스가 뜬다. autoruns를 써서 등록 상황을 확인해보니 아래 두 개 키 아래에 해당 프로그램이 모두 등록되어 있다.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run

만일을 위해 레지스트리를 백업한다.

Windows Vista 또는 Windows 7

시작
그림 축소그림 확대
을 클릭하고 검색 시작 상자에 systempropertiesprotection을 입력한 다음 Enter 키를 누릅니다.
그림 축소그림 확대
관리자 암호나 확인을 요청하는 메시지가 나타나면 암호를 입력하거나 허용을 클릭합니다.
Windows에서 사용 가능한 디스크와 가장 최근의 복원 지점을 검색할 때까지 기다립니다. 시스템 속성 대화 상자의 시스템 보호 탭에서 만들기를 클릭합니다.
복원 지점 이름을 입력하고 만들기를 클릭합니다.
복원 지점이 성공적으로 만들어지면 확인을 차례로 두 번 클릭합니다.

HKLM과 HKCU 차이는 무얼까?

HKCU means HKey Current User, ie your personal profile related settings,
HKLM means HKey Local Machine, ie your machines specific settings.

출처: http://www.portegeclub.com/forum/viewtopic.php?t=305

필수 유틸리티 활용 환경 만들기 v3

영회 — Wed, 14 Oct 2009 11:37:14 +0900

노트북 설치를 새로 했다. 일하는 데 필요한 프로그램만 깔고 쓰다 보니 필수 유틸리티가 고프다. 그중에서 설치형 프로그램이 아닌 process explorer, autoruns 등은 설치 위치까지 찾아가 실행하려면 번거롭다. 바로가기를 만드는 방법도 있지만 바로기가는 최대한 아끼는 성격이다. 일단, Utils라는 폴더를 만들어 설치가 필요 없이 바로 실행하는 프로그램을 몰아넣는다. 그리고 나서, '윈도+R' 키를 누르고 나서 명령어로 타자해서 실행하기로 한다. 경로를 못 찾는다. 이클립스 등장 이후로 사용한 기억이 가물가물한 환경 설정을 한다.

(Launchy 사용자)
Launchy 사용법은 웹초보님이 친절하게 설명하고 있다. Alt + Space로 실행하면 깔끔한 UI가 나타나는 인터페이스가 마음에 쏙 든다.

기본으로 시작 프로그램 등록한 프로그램(설치형)만 사용 가능하다. 옵션 catalog 탭에서 원하는 디렉터리와 파일 유형을 지정해주면 원하는 프로그램 무엇이든 실행 가능하다.

주의 사항: '*.exe'로 하지 않고, 'exe'로 했더니 작동하지 않았다.

조금 응용해서 다른 필요에 맞춰 설정했다. 각종 메신저나 브라우저에서 내려 받은 파일을 바로 찾기 위해서 파일 내려 받은 디렉터리를 추가하고 모든 파일 유형(*.*)을 지정했다. 이제 내려 받은 후 이름을 타자하면 바로 읽을 수 있다.

(플러긴 설명에도 눈이 가지만 일단 패스)

(Launchy 사용 안함)
비스타 기준으로 바탕화면에서 '컴퓨터' 아이콘 선택 후 Alt+Enter > 고급 시스템 설정 선택 > 환경변수 버튼 클릭 > Path 항목에 폴더 위치 추가

이클립스에서 사용자 단축키 만들기 v1.1

영회 — Fri, 09 Oct 2009 12:48:00 +0900

중복 제거는 코드뿐 아니라 일상 작업에서도 유용하다. 하루에도 수 십 번씩 클릭하는 메뉴가 있는데 단축키가 없다. 요즘 Team > Show History를 반복해서 사용한다. 지루하고 손목 아픈 일이다. 이클립스에서 단축키를 정의할 수 있음을 떠올렸다.

Ctrl+3 키를 누른 후(Quick Access) 'keys'로 검색한다. Preferences 창에서 General > Keys 항목에 접근할 수 있다. 필터에서 'show hi'까지 입력하면 둘만 남는다. 물론, Subversive를 설치하지 않으면 하나만 나타날 것이다.

Team 하위 주요 명령이 Ctrl+Alt와 알파벳 조합키인 점에 착안하여 Ctrl+Alt+H로 하고 싶지만 이미 사용중이다. Open Call Hierarchy가 쓰고 있다. Preferences 창에서 General > Keys 항목 아래쪽에 있는 Binding 입력 상자에 키 조합을 넣어보면 충돌을 확인할 수 있다. 한발 양보해서 Ctrl+Alt+H로 대신하려 했더니 Add to svn:ignore...가 쓰고 있다. 아예 마지막 글자를 선택해서 Ctrl+Alt+Y로 정했더니 OK다.

꾸준한 개선

영회 — Fri, 09 Oct 2009 09:21:00 +0900

3년 전에 한껏 고무되어서 이런 글을 써 놓았지만, 별반 나아지지 않았다. 개발 프로젝트에서 컨설팅하는 일 외에는 생활의 아주 기본까지도 서툰 터라 삶을 대부분 일에서 배운다. 일외에 준비 없이 당하는(?) 많은 경험 속에서 가끔 '그렇구나.'하며 깨닫기도 한다. 편식을 하듯 마음을 끄는 일만 쳐다보고 그 외에는 내버려뒀던 과거는 고스란히 대가를 묻는다. 제풀에 지쳐서 종종 부질없이 현실과 동떨어진 천국(?)을 꿈꾸기도 한다. 나이만큼의 세월 덕에 부질없음을 이제는 안다.

어제 다른 사람에게 준 상처가 나에게 되돌아오는 일을 경험했다. 한두 번 있는 일도 아니지만, 짧게나마 진심으로 반성했다. 생활에 휩쓸려 다니면 나도 몰래 다른 사람을 비난하는 일에 몰두해 정작 내 모습은 버려두곤 한다. 이런 일이 쌓이고 쌓이면 결국 그게 나 대부분을 구성한다.

요즘 일터에서 개발 프로젝트를 유지보수처럼 하고 있다. 지속적으로 개선하는 프로젝트 구도가 만들어졌다. 같은 코드를 다시 보고, 여러 번 생각해보는 과정에서 코드가 나날이 좋아지는 모습을 확연히 느낄 수 있다. 처음에는 잦은 수정에 강한 반감을 품은 개발자도 코드가 좋아진 만큼 성숙해진다.

이러한 일터의 경험이 반성하고 있던 나에게 말해준다. '프로젝트에만 그리하지 말고, 너의 생활에도 적용해봐.' 엉망인 주변과 자신을 그대로 두지 말고, 보고 싶지 않은 모습은 애써 감추려 하지 말고, 개발자에게 리팩토링을 종용하듯 차츰 개선을 해보라고 말한다. 생소한 리팩토링을 강요받은 개발자와 똑같이 반감을 갖는다. 망설이고 있지만, 실천에 옮겨야지. 꾸준한 개선이 보여준 놀라운 힘은 눈으로 확인했다. 다만, 내 몸을 구성하는 거대한 악성코드를 끈기를 가지고 엉킨 실타래를 풀듯 개선해나갈 일이 좀 버겁게 느껴진다. 자꾸 잊어버리지만 틈만 나면 반성하고, 호흡을 짧게 가져가는 TDD 스타일을 접목해봐야겠다.

군계일학

영회 — Wed, 07 Oct 2009 15:30:00 +0900

그라운드의 지휘자라는 로시츠키도 그 재능을 사랑하는 약관의 주장 세스크 파브레가스. 혁명과도 같은 행보를 보여준 벵거 키드지만, 킹 앙리 이후에 단연 돋보이는 존재다.

그리고, 올 여름 내 티셔츠의 주인공이자 가장 사랑하는 축구 선수 제라드.

내 평생 잊지 못할 개인기를 보여줬던 호나우두에 비할 수 없고, 무회전킥을 선보이는 호날두(크날두)보다 킥이 화려하진 않지만, 축구를 통해 감동을 선사하는 스티븐 쩨라~~드

그리고, 전통 강호지만 최근 어려운 살림에도 불구하고, 제라드 판박이인 마드리드의 마법사 토레스....

리버풀은 최강과는 거리가 있지만, 좋아하지 않을 수 없다. 세상이 나를 저버려도 끝까지 최선을 다하는 군계일할 있음에...

복식부기와 TDD (바뀌는 글)

영회 — Wed, 07 Oct 2009 13:07:20 +0900

TDD is like dual entry bookkeeping for accountants, ...

TDD를 복식 부기 1에 비유하다니 절묘한 은유다. 동시에 외과 의사의 어떤 절차(sterile procedure for surgeons)^[각주:2]를 함께 예로 들면서, 전문가들이 이러한 규율이 주는 이점을 알고 활용하듯 TDD 역시 전문적인 규율(TDD is a professional discipline)라 설명한다.

소프트웨어 산업은 아직 초창기인 듯하다. 최소한의 검증 장치가 없는 코드를 인정해주는 문화가 증거다. 현장에서 아직 TDD를 적용해보지 못했지만, JUnit 기반 자동화 테스트 구축으로 변화에 대응하기 위한 회귀 테스트를 5년에 걸쳐 4개 프로젝트에 적용하고 있다. 변화를 강제 당하는 개발자가 테스트 작성을 반대하는 목소리는 이해할 수 있다. 그러나 관리자마저 정확한 내용도 모르고 그저 개발자에게 부담을 준다고 테스트 작성을 반대하는 일을 최근에도 경험할 수 있다. 조금 과장해서 이야기하면, 개발자가 자기 마음대로 코드를 짜도 화면으로 결함을 확인할 수 없으면 문제없다는 이야기다.(세상에~ 내가 일하는 곳이 이렇게 엉성하게 일할 수 있는 곳이었다니... 새삼스럽다.) Uncle Bob이 TDD가 개발을 더디게 한다는 사람을 석기 시대(the stone age) 사람이라 했는데, 소프트웨어 산업은 이제 막 석기 시대를 지난 듯하다. :)

트위터에 링크를 소개했더니 복식부기를 쉽게 알려주는 만화를 공유한 분이 있다: http://ow.ly/t4qk [본문으로]
무엇을 말하는지 모르겠다. [본문으로]

있는 집... :)

영회 — Tue, 06 Oct 2009 15:26:00 +0900

대한민국 에이스 박지성이 속한 전통 강호 MAN UTD에게 선두를 내주곤 하지만...
완벽을 추구하는 이들의 플레이는 감독이 바뀌어도 여전하다.
그리고... 불멸의 드록신~ 크헉...

웹 개발은 쉽지 않은 일

영회 — Tue, 06 Oct 2009 08:30:00 +0900

종종 쇼핑몰 사이트 개발을 주로 경험한 사람을 무시하는 사람을 접한다. 동의하기 어렵지만, 수긍이 가는 부분도 있다. 수긍이 가는 부분은 웹 개발자 사이에 팽배한 태도다. 코드를 작성하다 문제가 발생하면 원인을 정확하게 파악하기 보다는 바로 해결하는 방법만 찾는다. 하지만, 이는 웹 개발자에만 유효한 이야기는 아니다. 수능 때 공부했던 '성급한 일반화의 오류'가 생각나는 순간이다.

동의할 수 없는 이유는 Miško Hevery가 어제 쓴 글에서 찾을 수 있다.

Building web-applications is hard! Even the simplest hello world application will take you hours to set up and you have to know a lot about how many different pieces of technologies work together. Here is a quick inventory from the browser to the back end of what a typical web-application developer needs to know about: HTML, CSS, JavaScript, cookies, HTTP, URL encodings, Servlets, web-framework (i.e. web-work), authentication, threading, SQL, ObjectRelational mappers, DB Schema, RDMS, DB indexing.

예전에 문득 웹 개발을 위해 필요한 기술이 모두 담긴 책이 있었으면 했는데, 책이 포함해야 할 내용을 모두 담았다. ㅡㅡ;

새 술은 새 부대에... 새롭게 태어나는 KSUG

영회 — Mon, 05 Oct 2009 08:59:00 +0900

(미사여구 조금 붙이자면) 열심히 하려는 개발자 마음에 따뜻한 봄날을 느끼게 해주자고
일민형과 즉흥적으로 시작했던 오프라인 세미나
일주일은 준비했던 1회 이후에 결국은 10개월간 열 번의 세미나를 개최했다.

그리고...

스프링 쓰다 모르면 물을 곳이 없다고 하기에
온라인에 스프링 포럼을 본뜬 KSUG 포럼을 만들었다.

그리고...

활발한 소통을 위해 천 명이 넘는 회원 정보를 싹 지우고
구글 그룹스로 옮겨 구수한(?) 메일링 리스트를 쓰고 있다.

대표니... 회장이니...
한 일에 비해서 민망하기 짝이 없는 이름이지만...
모든 일을 즐겁게 했다.

그리고...

나보다 훨씬 열심히 해주실 분이 있어서
편안한 마음으로 떠난다.

오늘부터 KSUG(한국스프링사용자모임) 대표는 박성철(gyumee) 회장(?)이다.

세미나할 때는 꼭 부르세요.

회귀 테스트 효과 (수정)

영회 — Wed, 30 Sep 2009 14:39:30 +0900

프로젝트 초기부터 DB 접근 로직에 대해 자동화 테스트를 작성하니 슬슬 효과가 나타난다. 그 중에서도 변화에 대한 감지기 역할을 하는 부분이 눈에 띈다. 먼저, 잘 돌아가던 테스트 메소드 하나가 NOT NULL 필드 제약 탓에 입력 오류를 뱉었다. 테이블에 변경이 가해졌음을 알 수 있는 부분이다.

1. 파티션 적용 후 코드 수정 않은 경우:
더 흥미로운 부분은 파티션 적용에 따른 테스트 실패다. DbUnit을 이용해 엑셀에 넣어둔 테스트 데이터를 DB에 넣는 방식을 쓴다. 개발DB에 점차 실제 데이터를 넣고 개발하는 탓에 테이블에 파티션을 적용했더니 DbUnit을 통한 데이터 INSERT에서 ORA-14400 오류가 발생했다. 확인해보니 일자를 기준으로 파티션을 만들었는데, 엑셀 파일 테스트 데이터에 해당 컬럼에 파티션 범위 밖의 데이터를 넣었다. 파티션 설정에 따른 보너스(?)로 '2222년 11월 22일'과 같은 개발자 편의에 따른 테스트 데이터 입력을 검출할 수 있었다.

2. NOT NULL 제약 없다가 추가한 경우:
개발 초기에 DBA 통제를 받지 않는 프로그램 테스트 전용 스키마를 허용했다. 아직 고객 요건에 따른 제약사항을 충분히 구현하지 않은 테이블이다. 특히 업무 설계 과정에서 나타난 필드 이외에 앞으로 운영을 담당할 고객 DBA가 요구하는 검사(Audit)용 필드 중에 NOT NULL이 있는데 빠뜨려도 드러나지 않았다.

레코드 수가 아주 많은 경우를 빼고는 DbUnit을 통해 초기 레코드 상태를 관리했다. 이 경우 빈 셀은 null 로 들어간다. 이후에 같은 코드를 제약이 걸린 테이블을 대상으로 테스트해보니 실패한다. NOT NULL 제약을 걸러내는 ORA-01400 오류 코드를 확인할 수 있다.

3. 코드 수정 없이 컬럼을 추가한 경우:
테스트를 위해 DB 상태를 맞추기 위해 사용하는 다음과 같은 코드가 있었다.

jdbcTemplate.execute("INSERT INTO TBL_USERS VALUES ( ... );

처음 테스트 시점에서는 TBL_USERS 테이블 칼럼에 맞춰서 VALUES 안에 값을 넣어놓고 테이블에 칼럼 추가 후에 테스트 코드는 확인해보지 않았던 모양이다. ORA-00947(값의 수가 충분치 않습니다.) 라는 메시지를 확인할 수 있다.

프로젝트에서 효과를 발휘하는 개발 방법론 적용 기법(상)

영회 — Mon, 28 Sep 2009 08:32:00 +0900

본 기사는 월간마소 9월호 특집으로 기고한 내용으로 잡지사측에 양해를 구하고 공개하는 내용입니다.

프로젝트에서 효과를 발휘하는 개발 방법론 적용 기법
개발 방법론이 숨을 쉬게 하기

여러분이 어떤 조직의 IT운영팀장이라고 가정해보자. 우리 회사는 이미 오래 전에 선진 사례라고 알려진 RUP(Rational Unified Process)^[각주:1]를 받아들였다. 예산을 편성해서 프로젝트를 발주했고, 유명 컨설팅 회사가 우리 회사에 맞도록 RUP를 테일러링(tailoring)했다. 결과물은 우리 회사 표준 개발 방법론으로 지정했다. 표준 개발 방법론은 시스템 개발 과정에서 필요한 역할, 작업 진행을 위한 프로세스를 설명하고 있다. 또한, 각 작업마다 참조할 수 있는 지침과 표준 양식 그리고 점검표 등을 포함하고 있다. 표준 방법론을 만든 이후에 시행하는 모든 시스템 개발 프로젝트에 적용해보았지만 반응은 기대 이하다. 성과가 없다 보니 자조적인 평가도 나왔다. UML 표기법을 썼다는 점이나 유스케이스(use case) 단위로 산출물을 다룬 형식적인 측면을 빼면 예전보다 나아진 점이 없다고 불평하는 직원도 있었다. 더구나 UML 표기법이나 유스케이스 개념을 조직 내에서 널리 쓰이고 있지도 않다.

방법론은 표준 산출물 양식집?
필자가 최근 3년에 걸쳐 진행한 프로젝트 중에서 두 번은 방법론 담당자로 일했다. 두 차례 모두 표준 방법론을 갖고 있는 회사였다. 하지만, 흥미롭게도 가능하면 그대로 지키는 일은 피해달라고 했다. 현실과 맞지 않기 때문에 자사 표준이지만 가능하면 유연하게 해석해 달라고 했다. 시간과 노력을 들여 만든 방법론을 지키지 말라니 아이러니한 주문 아닌가? 하지만, 프로젝트 경험이 많은 베테랑이라면 입가에 미소를 머금으며 충분히 수긍할 수 있는 부분이다. 모든 상황에는 원인이 있는 법이다. 방법론을 거추장스러운 절차나 복잡한 문서양식 따위로 취급하는 경우는 왜 발생할까? 우선 방법론을 만든 후에 문자 그대로 고지식하게 적용하려고 했던 아픈 기억(?)탓일 수 있다. 개발 방법론 도입 초창기^[각주:2]에는 사용자가 방법론을 충분히 이해하지 못한 상태에서 곧이곧대로 따르던 시절이 있었다. 시스템 개발과 동시에 팀원 다수가 방법론 훈련을 병행해 상당한 스트레스를 받았다고 할 수 있다.

개발 방법론이 숨을 쉬게 하기
개발 방법론을 답답한 문서 안에서 숨도 못 쉬게 놓아두지 말고 현실과 만나게 하라. 현실과 만나야만 방법론이 숨을 쉰다. 현실은 방법론에 변화를 요구하는 다양한 변수를 갖고 있다. 어떤 변수가 있을까? 참여하는 사람만 놓고 보아도 일하는 방식을 바꿀 소지는 쉽게 찾을 수 있다. 일단 사람이 많아지면 모든 의사 소통을 구두로 할 수는 없다. 더구나 참여 기간이 달라지거나, 물리적으로 떨어진 공간에서 일하는 경우에 똑같이 일할 수 있을까? 또한, 숙련된 개발자와 그렇지 않은 개발자 모두에게 같은 방법을 고수하면 결과는 어떨까? 사람을 기준으로 얼핏 살펴보았지만, 개발하는 기능 개수, 사용하는 기술 플랫폼 종류, 계약이나 납품 절차 등을 하나하나 꺼내어보면 변수는 매우 다양하다. 방법론을 프로젝트에 효과적으로 사용하기 위한 방법은 매우 간단하게도 정리할 수 있다. 방법론이 현실을 만나게 하라. 다시 말해, 널리 써라. 그리고, 불편한 부분을 그냥 지나치지 말고 지속적으로 개선하라. 번거로운 부분은 과감하게 제거하거나 단순하게 하고, 모호한 부분은 분명하게 해둬라. 기사의 남은 분량은 두 줄 남짓 정리한 비법을 실천할 수 있도록 경험을 담은 부연이다.

첫 단추는 개발 케이스 만들기
필자가 가장 익숙한 RUP에는 세 개의 케이스(Case)가 있다. 비즈니스 케이스(Business Case), 유스케이스(Use Case) 그리고 개발 케이스(Development Case)이다. 비즈니스 케이스는 사업 수행을 다루고, 유스케이스는 시스템 사용 시나리오를 다루지만 모두 “어떻게 하겠다”는 내용을 정형화한다. 개발 케이스도 마찬가지로 어떻게 개발하겠다는 시나리오를 정의한다. 개발에 관한 모든 사항을 처음부터 모두 세세하게 정의하기는 힘들다. 기존에 정의한 방법론 내용이 있다면 큰 노력이 들지 않는 부분만 초기에 수정하고, 문제에 봉착했을 때 해당 부분을 수정한다. 개발 케이스를 어떤 형식으로 얼마나 상세하게 하느냐는 프로젝트마다 달리해야 한다. 하지만, 개발 케이스를 집약해서 모두에게 누가 무슨 일을 하는지 알려야 한다. 그래야만 역할이 분명해지고, 필요한 사람을 찾을 수 있다. ^[각주:3] 그림1에서 빈칸에 담당자를 명기하면 각 단계별로 산출물 작업 기준이 드러나고, 특정 업무에 따라 산출물 작성자를 한 눈에 볼 수 있다. 이러한 표를 만들어 공유하면 모호했던 역할과 서로 다르게 생각하고 있는 부분이 드러난다. 자연스레 이어지는 협의 과정에서 점차 역할과 책임이 명확해진다. 한 가지 팁이라면 프로젝트 규모가 커서 여러 장의 표를 작성해야 할 정도라면, 프로젝트 관리자는 대표자를 명기한 표만 활용하고, 상세 내용은 각 업무 단위로 관리를 위임한다.

그림1. 개발 케이스 관리표 예제

모호한 부분 구석구석 밝혀내기
규모를 막론하고 개발 프로젝트 초기에는 단계별 산출물을 기준으로 책임자를 명기해두고 합의를 이끄는 과정을 반드시 수행해야 한다. 그림1의 표는 만들고 나면 매우 명확하지만, 앉은 자리에서 그냥 작성할 수 있는 내용이 아니다. 필자는 주로 외주 계약 기반인 SI 프로젝트에 컨설턴트로 참여하는데, 복잡한 하도급 계약을 고려하면 어떤 역할을 수행하는지 세부 사항은 매번 새로 정의해야 한다. 대부분 기존에 해오던 방식을 선호하는 경향이 있어 필연적으로 갈등이 빚어지고, 노련한 개발자가 많으면 서로 자신에게 유리하게 협상을 하려 해서 설득과 조정 과정이 필요하다. 한편, 여러 업무나 여러 단위 시스템으로 구성된 프로젝트의 경우 역할이 상충하기 마련이다. 주고 받는 데이터가 발생하면 누가 전송을 책임지느냐 여부가 관건이다. 함께 쓰는 기능이 있다면 공통 기능 개발 주체가 초미의 관심사다. 항상 분명한 사실은 오래 끌어봐야 갈등만 커진다는 점이다. 가능한 빨리 문제를 이슈화 해서 초반에 정리해야 한다.^[각주:4]

실행 능력 키우기
단조로움을 피하기 위해 잠시 다른 이야기를 해보겠다. 한일월드컵 4강 신화를 이뤄낸 거스 히딩크 등장 이전에 국가대표는 4(four)백을 잘 쓰지 않았다. 4백이란 수비수 네 명이 일렬로 서서 수비 라인을 구축하는 전형을 말한다. 4백 대신 중앙 수비수 세 명을 두는 3(three)백 시스템을 썼다. 당시 선진 축구 흐름은 전원공격과 전원수비를 함께 하는 이른바 “토탈사커”였다. 토탈사커를 구사할 때 4백을 구성하는 측면 수비수 2명은 특히 중요한 역할을 했다. 기본적인 위치는 좌우 측면 수비이지만, 공격할 때는 공을 갖고 상대편 깊숙이 침투하여 크로스를 올리는 역할을 맡았다. 따라서, 공수 양면에서 탁월한 능력과 함께 기동력, 그리고 강한 체력을 요구했다. 동시에 중앙 수비수는 역습 상황에서 둘이서 최후방을 책임져야 하기 때문에 강력한 대인 마크 능력을 요구했다. 당시 우리나라는 홍명보와 짝을 이룰 중앙 수비수 제목이 약했고, 측면 침투와 수비를 책임질 측면 수비수 제목이 없었다. 히딩크는 어떻게 4백을 도입할 수 있었을까? 히딩크 역시 처음부터 4백을 고집하지 않았다. 월드컵 본선 직전까지 3백과 4백을 함께 사용하다가 끝내 본선에서 주요 경기에 4백을 사용했다. 이를 가능하게 한 힘은 극한에 이르는 체력훈련이다. 히딩크가 수행한 체력훈련을 빼고 4백(4-3-3) 도입을 논하는 일은 무의미하다.

그림 2. 4-3-3 전형

필자가 히딩크의 접근방식을 꺼내놓은 이유는 방법론 적용에 대해서도 마찬가지의 노력이 필요하기 때문이다.

http://en.wikipedia.org/wiki/RUP [본문으로]
필자 경력상 주로 객체지향 분석설계에 바탕을 둔 개발 방법론 도입 시기에 국한한다. [본문으로]
방법론의 핵심은 R&R [본문으로]
프로젝트 초반에 이슈화하기 [본문으로]

프로젝트에서 효과를 발휘하는 개발 방법론 적용 기법(하)

영회 — Mon, 28 Sep 2009 08:30:00 +0900

본 기사는 월간마소 9월호 특집으로 기고한 내용으로 잡지사측에 양해를 구하고 공개하는 내용입니다.

실행 능력을 키우는 코치
지난 해 바쁜 시간을 쪼개서 ‘소트웍스 앤솔러지: 소프트웨어 기술과 혁신에 관한 에세이’ 번역에 참여했다. 번역 작업은 처음이었지만, 7장 ‘반복 관리자’ 내용이 무척 실무적인 터라 번역 요청에 응했다. 때마침 프로젝트 관리를 하고 있었고, 소수의 팀원에 비해 개발 물량이 무척 많아 애자일 방법론을 채택한 상황이기도 했다. 책 내용 일부를 소개하면, 반복 관리자가 팀이 일정을 지키게 하기 위해 다음과 같은 질문을 하라고 한다.

    개발자가 자신이 맡은 스토리 범위를 이해하고 있는가?
    애초 예측 이후 스토리 작업에 변경이 있었는가? 그렇다면, 어떻게 변했는가?
    개발자가 해당 스토리가 목표로 하는 상태에 대해 더 잘 이해하기 위해 업무 분석가나 고객 도움이 필요한가?
    개발자에게 선임 개발자 도움이 필요한가?
    개발자의 스토리 완수에 장애가 있는가? 가령 하드웨어, 소프트웨어 또는 기반구조 문제가 있는가?
    개발자가 다른 프로젝트에도 참여하고 있거나 스토리 완수를 위해 지나치게 많은 잡다한 회의까지 참석하고 있지 않는가?

필자는 번역을 수행할 당시, 스스로 뽑은 최고의 팀원으로 프로젝트 관리를 수행하고 있었다. 하지만, 기대만큼 좋은 결과를 내지 못했다. 얼마간의 시행착오를 겪은 이후에 필자는 팀원의 작업 내용에 직접 개입하기 보다는 위 질문과 같은 내용으로 도움을 주려고 노력했다. 스스로 해결할 수 없는 문제는 빨리 도움을 요청하도록 유도했고, 회의는 주로 관리자인 내가 전담하면서 검토를 수행할 경우에 한해서 개발 담당자를 참여시켰다. 또 가장 중요한 점은 스스로 자신의 작업 계획을 수립하게 했다. 약 4개월 동안은 주마다 계획을 하고, 매일 아침 진척을 보고하게 했다. 주단위로 보면 늘 조금은 지연 이 있었고, 매일 아침 물어봐야 며칠 동안 같은 작업을 진행 중이라고 답했다. 속으로 답답했지만, 인내심을 가지고 기다렸다. 매번 반복해서 가능한 일을 잘게 나누어 보고하라고만 요청했다. 놀랍게도 4개월 이후부터는 하루 단위 작업 추정이 가능했다. 주 단위로는 거의 모든 팀원이 자신의 말을 지켰다. 처음에는 상상도 못할 작업 측정과 관리가 가능했다.

거스 히딩크가 했던 일도 이와 비슷한 일종의 코치가 아니었을까? 반복 관리자는 애자일 코치(agile coach)라고 부르기도 한다. 갑자기 방법론 이야기하다 말고 왜 애자일 코치 이야기를 꺼냈을까? 앞서 이야기했지만, 기초 체력 훈련 없이 4백은 불가능하다. 최소한의 체력이나 개인기가 없는데 마법 같은 부분전술이나 훌륭한 전략을 소화할 수는 없다. 마찬가지로 효과적인 방법론 적용을 위해 팀원의 기본 역량 강화는 필수다.

팀웍 빌딩
축구팀이나 개발팀이나 팀웍은 중요하다. 축구는 11명이 하지만, 개발팀 구성원 숫자는 이보다 많을 수 있다. 특히, 방법론을 도입하는 프로젝트는 수 십, 수 백명인 경우가 많다. 숫자가 늘면 팀웍을 갖추기는 더욱 어렵다. 더구나 서로 다른 회사에 속한 팀원을 모아놓았을 때 이들을 진정한 팀으로 만드는 일은 과연 가능할까 싶을 정도로 힘들다. 대규모 프로젝트에서는 팀웍을 위해 워크샵을 가기도 하고 몇 차례 회식을 한다. 얼마나 효과가 있을지는 의문이다. 함께 일하는 빈도가 높은 팀원 사이에서라면 필자가 했던 다음과 같은 시도를 한 번쯤 권해보고 싶다. 필자는 함께 일하는 팀원을 불러다 놓고 자신과 관계된 담당자와 산출물을 표기한 후 관계를 그려보라고 했다. 훈련된 팀이어서 산출물을 빠뜨리는 경우는 없었지만, 다른 사람과의 관계는 팀원 대부분이 빠뜨리고 그렸다. 놀라운 점은 서로가 그린 그림을 공유하는 정도만으로도 팀웍 개선이 있었다는 점이다. 보지 못하던 부분이 드러난 이후에는 굳이 계속해서 지적하지 않아도 새로 인지한 부분을 고려해서 작업했다.

그림 3. 자신을 중심에 두는 맥락도(context diagram)

획일화의 함정에 빠지지 말라
지금까지는 사람에 초점을 맞췄는데 세부적으로 들어가면 방법론은 각종 산출물 작성법을 포함한다. 종종 방법론과 표준 양식을 대등하게 생각하는 사람도 있다. 올바른 판단은 아니지만, 그만큼 표준 양식은 모두가 명확히 인지하고 필요로 한다. 문서 작성 방식이 명확하다면 작성도 편하지만, 읽기에도 좋다. 그러나, 프로젝트가 커지면 지나치게 관리 편의성을 내세우기도 한다. 지나치게 일관성을 강조하면 획일화의 함정에 빠질 수 있다. 대규모 프로젝트에서 프로그램 식별자(ID)는 여러 가지 용도로 쓰인다. 사업 관리 측면에서 진척 관리 기준으로 쓰이기도 하고, 설계자, 개발자 및 테스트 담당자가 작업 항목을 식별하고 서로 추적할 용도로 쓰기도 한다. 수많은 프로그램 가운데서 일관성을 부여하기 위해 대개는 다양한 약어와 일련번호를 조합한 이름을 지정한다. 그러나, 프로그램 내부의 변수에까지 모두 동일한 체계를 부여해 프로그램을 암호처럼 만드는 경우를 종종 목격할 수 있다. 산출물 특성을 무시하고 모두 똑같이 처리하려고 시도한 탓이다. 엑셀 문서에서 특정 프로그램을 지칭하기 위해 ‘IF-CMD-001’과 같은 식별자를 쓰는 일은 긴 이름에 비해 효율적일 수 있다. 하지만, 프로그램 이름을 ‘IF-CMD-001.java’ 혹은 ‘IF-CMD-001.jsp’ 라고 만드는 일은 과연 적절할까? 비슷한 획일화 함정의 예로 ‘유스케이스 크기 기준’^[각주:1]을 들 수 있다.

프로세스 최적화와 도구의 적용

산출물 형식뿐 아니라 용도와 상황에 부합하게산출물 작성 프로세스를 최적화한다. 산출물 작성 프로세스의 경우에도 그림 4와 같이 시각화하여 공유해야 한다. 누가 무엇을 하고, 이어지는 작업은 무엇인지 관련자나 관련 시스템을 무엇인지 명확하게 해서 혼선을 없애야 한다.

그림 4. 프로세스 시각화 예시

프로세스가 복잡해지면, 단순화를 위해 시스템 도입을 고려해야 한다. 최근에 다양한 협업 도구가 오픈소스로개발하고 쓰여지고 있다. 의사소통을 문서로만 관리할 때 보다 도구를 도입하면 효율적이지만, 소수 관리자의 관리 편의성이나 도구에 대한 거부감으로 문서를 고집하는 경우도 있다. 명심하라. 개발 프로젝트에서 최종 산출물은 소스 코드다. 그 이전에 만들어지는 수많은 문서는 결국 중간 결과를 담는 그릇이다. 의사결정사항을 알려 오류를 찾아내고, 누락시킨 요구사항을 다시 수렴하고, 다음단계로 진화하고, 필요하다면 변경을 수행하기 위한 정보 전달에 사용한다. 목적에 부합하는 수단과 방법을 쓰고 있는지 항상 고민해야 한다.

생생하게 유지하기

얼마 전 모회사에서 꽤 잘 만든 조직 표준 체계를 열람했다. 2년전에 만들었는데 내용이 그대로였다. 만들기는 잘했지만, 널리쓰이지는 않았구나 짐작했다. 널리 쓰이지 않는다면, 그리고상황에 맞게 옷을 갈아입지 않는다면 가치가 있을까? 방법론 무용론도 같은 맥락이 아닐까? 아무리 욕을 해도 마구잡이 개발보다 나쁜 방법론은 없다. 방법론이쓸모가 없다고 생각한다면 자신이 제대로 활용하고 있는가 돌아보자.

http://cavin.egloos.com/4869054 [본문으로]

프레임워크 하위 호환성 검증 방법

영회 — Fri, 25 Sep 2009 20:44:00 +0900

예전 버전의 프레임워크로 개발 중인 사이트가 있다고 하자. 해당 프레임워크의 새로운 버전을 사용해도 문제가 없음을 즉, 하위 호환성을 검증할 방법은 무엇이 있을까?

흔히 사용하는 방법은 이미 개발한 애플리케이션에 프레임워크를 바꿔 넣고 기능이 잘 수행하는지 보는 일이다. 우선, 프로그래밍에 의한 API 불일치는 컴파일부터 문제가 생긴다. 그렇지만, 인터페이스는 같지만 다르게 작동하면 검출이 쉽지 않을 수 있다. 이럴 때 차곡차곡 모아둔 회귀 테스트는 보험으로 쓰일 수 있다. 물론, 효용성(coverage, test case 적합성 등)에 따라 효과는 크게 달라진다.

얼마 전 프레임워크 개발자와 프로젝트에 프레임워크를 적용하는 동료가 호환성에 문제가 없다고 한 이야기를 덜컥 믿어 버리는 우를 범했다. 만 하루도 지나지 않아 문제가 드러났다. 표면으로 드러나 현상은 화면 그리드에 특정 칼럼에만 데이터가 나타났다. 개발자는 코드를 고친 일이 없다. 데이터 역시 그대로다. 개발자가 판단하기엔 귀신이 곡할 노릇이다. 더구나 개발서버가 아닌 로컬PC에선 잘 돌아간다. 알고 보니 개발서버엔 테스트를 마친 새로운 버전의 프레임워크와 설정을 반영했고, 개발자PC에선 아직 저장소와 동기화를 하지 않은 상태였다.

원인을 찾아보니 암묵적인 API 호환성을 놓쳤다. 각기 다른 작명 지침(naming convention)을 쓰는 테이블 컬럼과 객체 속성을 바인딩할 때 약속한 바와 다르게 구현한 부분이 있었다. 다행히 개발 초기부터 자동화 테스트와 화면을 띄워 진행하는 기능 테스트를 병행하고 있어 개발팀에서 본의 아니게 빠르게 문제를 보고해주었다. 한편으로는 빠른 테스트의 효과를 실감할 수 있었지만, 하위 호환성에 대한 검증 방법을 돌아보게 했다.

툴킷 수준의 검증 도구까지는 아니더라도 점검 목록(check list)도 없이 프레임워크 하위 호환성을 검증한 일은 바람직한 절차는 아니다. 당장 뾰족한 묘안이 있지는 않지만, 담당자끼리는 상황 인식을 공유했다. 일 회로 그만두는 활동이 아니라면 다음번에는 더 나아져야 하기 때문이다.

이야기를 쓰다보니 얼마전 비즈니스 패키지 설치 검증 방안에 대해 협의했던 기억이 떠올랐다. 비즈니스 기능을 탑재한 솔루션의 정상적인 설치와 작동을 어떻게 보장할 수 있을까? 나아가 인수 담당자가 어떻게 안심하고 검수 사인을 할 수 있을까?

기억이 정확하지 않지만 아마도 협의 끝에 몇 가지 산출 값을 지표로 삼고, 특정 모듈과 테이블 존재 여부 등을 점검 항목으로 정리했다. 그리고 생각했다. 만일 해당 패키지에 회귀 테스트가 가능한 테스트 스위트가 있다면 훨씬 나았으리라 생각했다. 최소한 기능 작동까지는 아니더라도 설치 후에 테이블 존재 여부, 모듈 존재 여부, 초기 데이터 존재 상황 등은 쉽게 자동 확인이 가능하다.

이클립스에 질의하기?

영회 — Thu, 24 Sep 2009 12:20:00 +0900

일민형과 오룡해삼을 먹고 나서 소화를 시키려고 이런저런 이야기를 나누다 잠시 이클립스에 대해 이야기했다. 유로파 1에 추가한 최고의 핫키로 Ctrl+3 (Quick Access)을 꼽았다. 마치 데이터베이스에 LIKE 쿼리를, 그것도 이력 테이블을 포함한 여러 테이블에 LIKE 조회 쿼리를 날리고 결과를 UNION ALL로 붙인 후 GROUP BY 하는 듯하다. 이 핫 키를 처음 봤을 때, 이것 하나만으로도 새 버전을 써야 할 이유가 충분한 듯 보였다.

그리로 이와 비슷한 기능인 Preferences 창의 필터 필드다. 여기에 몇 자 입력하면, 광대한 이클립스 설정 옵션 중에서 원하는 녀석과 유사한 설정을 변경할 수 있는 페이지를 걸러준다.

토비형이 옆에서 3대 선호키를 말했는데, 그 중 하나가 Ctrl+Shift+R(Open Resource) 키다. Quick Access와 필터 필드가 광활한 명령과 실행에 대한 검색을 지원한다면, Open Resources(이하 OR)는 워크 스페이스 안에 있는 광활한 파일에 대한 검색을 지원한다. 심지어 우리 프로젝트 DBA도 SQL 인스펙션을 위해 가장 많이 쓰는 단축키가 Ctrl+Shift+R일 정도로 다수 파일 중에 검색할 때는 최고의 효용성을 보여준다. 작성하는 파일이 늘어날수록 OR의 필요성은 절실해진다. 더구나 내가 짜지 않은 파일까지 자주 열람해야 한다면 곱절로 절실해진다. :)

집에 돌아오는 길에 Preferences 창에서 "쿼리를 한다."고 인식하고 있던 나를 돌아봤다. 그리고 생필품인 구글이 떠올랐다. 초창기 웹에선 "수작업 분류와 링크"로 구현한 야후의 디렉터리 서비스가 유효했다. 마찬가지로 이클립스 초기 버전에선 Preferences에서 트리를 펼치는 방식도 그리 불편하게 느껴지진 않았다. ^[각주:2] 그러나, 이젠 검색은 필수다. 이클립스가 제공하는 자원(명령, 뷰, 설정 옵션 등등)이 많아지면서 검색이 역시 필수인 듯하다.

가니메데에 추가한 기능인 줄 알았더니만, 시간 참 빠르다.. ㅡㅡ; [본문으로]
사실 필터 기능도 없었을 테지만... (이노무 기억력) [본문으로]

페이징 예외 처리를 다루면서...

영회 — Thu, 24 Sep 2009 08:52:32 +0900

적합한 소프트웨어 설계(design)를 위해서는 기술 요소에 대한 구체적인 지식과 함께 사용자 요구 사항에 대한 깊은 이해가 필요하다. ^[각주:1]

예전에 경험한 일이 떠오른다. 대량 데이터 조회 화면에서 페이징(paging) 고려는 흔한 일이다. 구체적인 사항에 대해서는 고객에 앞서 UI 개발 전문가가 예제를 보여주고 선택하게 했다. 그리고 나니 고객은 적극적으로 의견을 피력했다. 주관식보다는 객관식이 답하기에 좋은 법이니까. 두 가지 사항을 결정했다.

페이지로 나누어진 그리드(list) 하위에 이동할 페이지가 숫자로 나타나는 형태 선택^[각주:2]
그리드 상단에 콤보(drop-down list)를 부착하여 한 페이지에 보일 데이터 건수를 선택하게 함

이외에도 UI 개발 전문가가 뽑은 일반적인 고려 사항에 대해 기본 정책을 결정했다. 얼마 지나지 않아 구현한 화면을 띄우고 동료 검토를 하는 가운데 몇 가지 문제가 발생했다.

하나는 데이터 수정(입력, 삭제 포함) 후에 돌아가는 페이지와 커서 위치다.
두 번째는 데이터 건수 선정 후에 페이지 이동을 함께 반영할 때 처리를 어찌 하느냐 문제다.

HTML 페이지 기반 웹 화면에서는 콤보(select) 선택을 이벤트로 잡아서 목록에 변화를 주는 경우가 많다. 하지만, 스크롤(Scroll)을 적극적으로 사용하는 X-인터넷에서는 콤보에 이벤트를 거는 방법을 피해야 한다고 UI 개발 전문가가 지적했다. 오히려 부자연스런 느낌이 있지만 데이터 건수를 변경하고 페이징을 적용하는 방식을 원하는 고객도 있다고 한다. 후자는 잘 수긍이 가지 않지만, 전자는 고개를 끄덕일 수 있다.

여하튼 이러한 예외적인 사용자 입력에 대해 정상적인 페이지를 보여줄 수 있도록 코드 수정이 필요했다. 개발자가 작성하는 화면 스크립트, 서버 코드, 연동을 처리하는 공통 코드(혹은 프레임워크) 세 곳 중에서 가장 영향이 적은 방안을 택해야 한다. 아쉽게도 화면 스크립트는 수정은 막을 수 있었지만, 서버 코드 수정은 피할 수 없었다. 공통 코드가 로직 대부분을 감싸고 있기에 변화를 줄일 수는 있었지만...

마침, 비슷한 논지의 글을 읽었다. '너도 나도 그렇게 폼나고 상위의 일을 했을 때, 디테일이 살아있는 디자인이 나올 수 있냐는 질문을 던집니다.' 출처: 누끼마녀와 아웃소싱 [본문으로]
화살표 클릭이나 페이지 직접 입력 등을 배제 [본문으로]

하루에도 열두번...

영회 — Wed, 23 Sep 2009 08:46:00 +0900

노랫말도 아니고... 하루에도 열두 번 들쭉날쭉한 감정
한때는 내가 철이 들었다고 생각했는데
깃털처럼 가벼운 감정은 시시때때로 달라 한심하다 하지 않을 수 없다.

출근해서 마주하자마자 미안해지는 사람 얼굴이 있었다.
여지없이 언젠가 욕을 했거나 얼굴을 붉히는 논쟁을 했던 사람이다.

쩝...

특정 종교에 귀속한 몸은 아니지만
어릴 때 기독교 영향을 받아서인지

(크게는) 안식일을 지키고
(중간에는) 잠들기 전에 회개하고
(짧게는) 쉬지 말고 기도하라고 했던가?

간접 경험이지만 불교에선
초심자용 108배를 비롯해서... 삼천배를 하시는 분도 봤다.

그리고 보니
심지어 SW 개발에서도 TDD라고 해서
짧은 호흡으로 결과를 만들고 즉시 반성(Refactoring)하는
도(TAO) 혹은 선(ZEN)을 이제야 눈치챘다.

쩝....

이젠 일기가 아니라 시기를 쓰더라도 매시간 반성을 해야지.