개발수양록

Linux 바이너리 역어셈블로 커널 모듈 패치 확인하기

Sun, 12 Apr 2026 00:00:00 +0000

Table of Contents

1. 역어셈블의 기본 개념
2. 활용 예시: 커널 모듈 바이너리 비교
3. 주의할 점
4. 참고 자료

소스 코드를 구할 수 없는 Linux 바이너리를 분석해야 할 때가 있습니다. 이 글에서는 objdump 기반의 역어셈블 기법을 먼저 정리하고, 활용 예시로 Ubuntu 패키지의 intel_cvs.ko 커널 모듈과 DKMS 패치 버전을 비교한 사례의 핵심을 설명합니다.

1. 역어셈블의 기본 개념

1.1. ELF과 .ko

Linux의 실행 파일과 공유 라이브러리, 커널 모듈은 모두 ELF(Executable and Linkable Format) 포맷입니다. 특히 커널 모듈(.ko)은 relocatable object 파일로, 커널에 로드되는 시점에 주소가 확정됩니다. 따라서 역어셈블에서 call 대상이 `0x0000`으로 보이는 것은 비정상이 아니라 재배치가 아직 적용되지 않았기 때문입니다.

ELF는 섹션 단위로 구성됩니다.

.text — 코드
.rodata — 읽기 전용 데이터, 문자열 리터럴
.data — 전역 변수
.symtab — 심볼 테이블

최근 Ubuntu OEM 커널은 모듈을 zstd로 압축하므로 `zstd -d`로 먼저 해제해야 합니다.

1.2. 핵심 도구

도구 용도

도구	용도
`objdump`	ELF 역어셈블. `-d -M intel`이 가장 많이 쓰는 조합
`nm`	심볼 테이블 조회. 함수 주소와 이름 확인
`readelf`	ELF 헤더, 섹션, 재배치 정보 확인
`strings`	바이너리 안의 문자열 추출. 힌트 얻기 용도
`modinfo`	커널 모듈 메타데이터
`pahole`	DWARF 디버그 정보에서 구조체 레이아웃 추출

objdump

ELF 역어셈블. `-d -M intel`이 가장 많이 쓰는 조합

nm

심볼 테이블 조회. 함수 주소와 이름 확인

readelf

ELF 헤더, 섹션, 재배치 정보 확인

strings

바이너리 안의 문자열 추출. 힌트 얻기 용도

modinfo

커널 모듈 메타데이터

pahole

DWARF 디버그 정보에서 구조체 레이아웃 추출

1.3. x86-64 호출 규약 (System V AMD64 ABI)

역어셈블을 읽기 위해 가장 먼저 알아야 하는 것은 호출 규약입니다. Linux는 System V AMD64 ABI를 따르며, 함수 인자는 정해진 순서의 레지스터로 전달됩니다.

인자 순서 레지스터 비고

인자 순서	레지스터	비고
1번째	`rdi` / `edi`
2번째	`rsi` / `esi`
3번째	`rdx` / `edx`
4번째	`rcx`
5번째	`r8`
6번째	`r9`
반환값	`rax`

1번째

rdi / edi

2번째

rsi / esi

3번째

rdx / edx

4번째

rcx

5번째

r8

6번째

r9

반환값

rax

예를 들어 다음 시퀀스는 foo(0x805, NULL, 0) 호출과 정확히 대응됩니다.

xor    edx, edx            ; 3번째 인자: 0
xor    esi, esi            ; 2번째 인자: NULL
mov    edi, 0x805          ; 1번째 인자: 0x805
call   foo

1.4. 자주 보이는 x86-64 명령어

명령어 의미

명령어	의미
`mov`	값 복사. `mov edi, 0x805` → `edi = 0x805`
`movzx`	작은 값을 0 확장하여 복사. 1바이트를 32비트로 읽을 때
`lea`	주소 계산만 수행 (메모리 접근 없음). 포인터 전달 용도
`test reg, reg`	같은 레지스터로 AND. 0인지 검사
`cmp`	뺄셈 후 플래그만 설정
`je` / `jne`	조건 점프 (equal / not equal)
`xor reg, reg`	레지스터를 0으로 초기화 (`mov reg, 0`보다 짧음)
`call`	함수 호출

mov

값 복사. mov edi, 0x805 → edi = 0x805

movzx

작은 값을 0 확장하여 복사. 1바이트를 32비트로 읽을 때

lea

주소 계산만 수행 (메모리 접근 없음). 포인터 전달 용도

test reg, reg

같은 레지스터로 AND. 0인지 검사

cmp

뺄셈 후 플래그만 설정

je / jne

조건 점프 (equal / not equal)

xor reg, reg

레지스터를 0으로 초기화 (`mov reg, 0`보다 짧음)

call

함수 호출

1.5. 상수로 호출 지점 찾기

소스에서 #define 값을 알고 있으면 역어셈블에서 해당 상수를 검색해 호출 지점을 좁힐 수 있습니다. 다만 같은 값이 다른 맥락(예: 길이, 인덱스)에서 쓰일 수 있으므로, 그 상수가 어느 레지스터에 들어가는지와 주변 call 대상을 함께 확인해야 합니다.

2. 활용 예시: 커널 모듈 바이너리 비교

2.1. 문제 상황

Ubuntu의 linux-modules-vision-*-oem 패키지에 포함된 `intel_cvs.ko`가 Intel 업스트림의 특정 버그 픽스를 반영하고 있는지 확인해야 했습니다. 패키지 changelog에는 어느 커밋까지 포함되었는지 명시되어 있지 않고, DKMS로 설치한 패치 버전과 어떻게 다른지를 확인해야 했습니다.

2.2. 왜 GitHub 소스 비교 대신 역어셈블을 선택했나

Intel의 업스트림 저장소가 GitHub에 공개되어 있으므로 소스 레벨 `diff`가 더 쉬운 선택처럼 보입니다. 그런데도 역어셈블을 택한 이유는 다음과 같습니다.

어떤 커밋에서 빌드되었는지 모른다. Ubuntu OEM 패키지의 changelog에는 Intel 업스트림의 어떤 시점 스냅샷인지가 명시되어 있지 않았습니다. 임의의 커밋에서 찍은 소스와 비교하면 "차이"가 진짜 패치 누락 때문인지 단순한 버전 갭 때문인지 구분되지 않습니다.
Ubuntu가 자체 패치를 얹었을 수 있다. 패키지 빌드는 업스트림 tarball에 distro 패치를 덧붙이는 경우가 흔합니다. 업스트림 소스만으로는 실제로 빌드된 결과를 재현할 수 없습니다.
바이너리가 ground truth다. 커널이 실제로 로드하는 것은 .ko 바이너리입니다. "이 시스템에서 지금 돌고 있는 코드에 해당 가드가 있는가"라는 질문의 답은 바이너리 안에만 있습니다.
확인하려는 범위가 작다. 특정 한 가지 패치(특정 상수 호출 앞의 분기 유무)만 확인하면 충분했습니다. 소스 트리 전체를 받아 빌드 환경을 맞추는 수고보다 objdump 한 번이 더 빠른 상황이었습니다.

즉, 소스 비교는 "업스트림에 그 패치가 존재하는가"에 답하지만, 이번에 필요한 답은 "내 시스템에 설치된 바이너리에 그 패치가 반영되어 있는가"였고, 이 질문에는 바이너리를 직접 보는 것이 가장 확실한 방법이었습니다.

2.3. 모듈 추출과 역어셈블

# 압축 해제
zstd -d -c /lib/modules/$(uname -r)/ubuntu/vision/intel_cvs.ko.zst > /tmp/pkg.ko
zstd -d -c /lib/modules/$(uname -r)/updates/dkms/intel_cvs.ko.zst > /tmp/dkms.ko

# 동일성 확인
md5sum /tmp/pkg.ko /tmp/dkms.ko

# 관심 함수만 Intel 문법으로 역어셈블
objdump -d -M intel --no-show-raw-insn /tmp/pkg.ko \
  | sed -n '/<cvs_common_probe>:/,/^$/p' > /tmp/pkg_probe.asm

objdump -d -M intel --no-show-raw-insn /tmp/dkms.ko \
  | sed -n '/<cvs_common_probe>:/,/^$/p' > /tmp/dkms_probe.asm

-M intel`은 `mov dst, src 순서의 Intel 문법을 사용합니다 (기본은 `mov src, dst`의 AT&T 문법). `--no-show-raw-insn`은 기계어 바이트를 생략해 가독성을 높입니다.

2.4. 핵심 차이 찾기

확인하고 싶은 패치는 아래 형태의 가드였습니다.

if (icvs->magic_num_support) {
    ret = cvs_write_i2c(SET_HOST_IDENTIFIER, NULL, 0);
}

SET_HOST_IDENTIFIER = 0x0805`는 첫 번째 인자이므로 `mov edi, 0x805 패턴으로 역어셈블에서 검색할 수 있습니다.

DKMS 버전 (가드 있음)

movzx  eax, BYTE PTR [r12+0x4c]  ; icvs->magic_num_support 로드
and    ebx, 0x1
test   bl, bl                    ; 0인지 검사
je     12c7                      ; 0이면 호출 건너뜀
xor    edx, edx                  ; len = 0
xor    esi, esi                  ; buf = NULL
mov    edi, 0x805                ; SET_HOST_IDENTIFIER
call   cvs_write_i2c

패키지 버전 (가드 없음)

xor    edx, edx
xor    esi, esi
mov    edi, 0x805
call   cvs_write_i2c             ; 무조건 실행됨

mov edi, 0x805 바로 앞에 test + `je`로 된 분기가 있느냐 없느냐가 두 바이너리의 실질적 차이였습니다. 즉 패키지 버전에는 해당 패치가 반영되어 있지 않다는 결론이 나옵니다.

2.5. 재배치 정보로 call 대상 확인

.ko`의 `call 대상이 0x0000`이거나 어색한 주소로 보일 때는 `-r 옵션으로 재배치 정보를 함께 출력하면 원래 타깃 심볼을 알 수 있습니다.

objdump -d -r -M intel /tmp/pkg.ko

127f: call   1284 <cvs_common_probe+0x104>
      1280: R_X86_64_PLT32  cvs_write_i2c-0x4

3. 주의할 점

컴파일러 최적화로 같은 소스여도 명령어 순서와 레지스터 선택이 달라집니다. 정확히 같은 시퀀스가 아니라 논리적 흐름(분기 구조) 을 비교해야 합니다. DKMS 빌드와 패키지 빌드의 GCC 버전이 같으면 차이가 적고, 다르면 코드 구조 자체가 꽤 달라 보일 수 있습니다.

재배치 주소 차이는 무시해야 합니다. diff`를 돌리면 `je 1553 vs `je 12c7`처럼 점프 대상 주소가 대량으로 다르게 나오는데, 이것은 함수 배치 차이일 뿐이고 주목해야 할 것은 명령어 자체의 추가/삭제입니다.

상수 검색의 false positive: mov edi, 0x805`가 반드시 원하는 호출은 아닐 수 있습니다. 어떤 함수 안에 있는지, 직후의 `call 대상이 무엇인지로 맥락을 확인해야 합니다.

그리고 당연한 이야기지만, 소스를 구할 수 있다면 역어셈블보다 `diff`가 훨씬 빠르고 정확합니다. 역어셈블은 소스를 확보할 수 없을 때의 최후 수단입니다.

4. 참고 자료

x86-64 Assembly Language Programming with Ubuntu — x86-64 어셈블리 입문 교재 (무료 PDF)
Intel x86-64 Instruction Set Reference — Intel 공식 매뉴얼 웹 버전
System V ABI - OSDev Wiki — 호출 규약 요약
GNU Binutils Documentation — objdump, nm, readelf 공식 문서
ELF Format 공식 스펙
Ghidra — NSA가 공개한 역공학 도구. `objdump`보다 훨씬 강력한 디컴파일과 크로스 레퍼런스 제공
Compiler Explorer (Godbolt) — C 코드가 어떤 어셈블리로 컴파일되는지 실시간 확인

이 포스트는 Claude Code가 정상혁의 지시에 따라서 작성했습니다.

Claude Code의 Prompt Cache 버그 (v2.1.69~v2.1.89)

Fri, 3 Apr 2026 00:00:00 +0000

Table of Contents

1. 버그 요약
2. 원인: Resume 시 메시지 구조 불일치
3. 영향 범위
4. 비용 영향
5. 수정 내용 (v2.1.90)
6. 영향 받았는지 확인하는 방법
7. 참고 자료

변경 이력

2026-04-06: Prompt Cache TTL 기본값(5분)과 1시간 옵션에 대한 설명 추가

2026년 3월 초부터 약 한 달간 Claude Code에 Prompt Cache가 제대로 작동하지 않는 버그가 있었습니다. Claude Code 토큰 비용과 프롬프트 캐싱에서 정리했듯이 Prompt Caching은 입력 토큰 비용을 90%까지 절약하는 핵심 수단인데, 이 캐시가 작동하지 않으면 비용이 크게 증가합니다. 이 글에서는 해당 기간에 발생한 캐시 버그의 원인과 영향을 정리합니다.

1. 버그 요약

항목 내용

항목	내용
영향 버전	v2.1.69 (2026-03-05) ~ v2.1.89
수정 버전	v2.1.90 (2026-04-01)
근본 원인	v2.1.69에서 도입된 deferred_tools_delta`로 인해 resume 시 `messages[0] 구조가 새 세션과 달라짐
영향 대상	`--resume` 또는 `/resume`으로 세션을 재개하는 사용자
GitHub Issue	#34629, #28899

영향 버전

v2.1.69 (2026-03-05) ~ v2.1.89

수정 버전

v2.1.90 (2026-04-01)

근본 원인

v2.1.69에서 도입된 deferred_tools_delta`로 인해 resume 시 `messages[0] 구조가 새 세션과 달라짐

영향 대상

--resume 또는 `/resume`으로 세션을 재개하는 사용자

GitHub Issue

#34629, #28899

2. 원인: Resume 시 메시지 구조 불일치

2.1. 근본 원인

v2.1.69에서 도입된 deferred_tools_delta 기능이 원인입니다. 이 기능은 deferred tools 목록, MCP 서버 설정, skills 정보를 메시지에 첨부하는 방식을 변경했는데, 새 세션과 재개 세션에서 `messages[0]`의 구조가 달라지는 문제가 생겼습니다.

세션 유형	messages[0] 내용	크기
새 세션	deferred tools 목록, MCP 설정, skills, 날짜 컨텍스트	~13.4KB
재개 세션	날짜 컨텍스트만 포함 (나머지는 messages 끝에 추가)	~352B

세션 유형

messages[0] 내용

크기

새 세션

deferred tools 목록, MCP 설정, skills, 날짜 컨텍스트

~13.4KB

재개 세션

날짜 컨텍스트만 포함 (나머지는 messages 끝에 추가)

~352B

Prompt Cache는 prefix의 해시값으로 캐시를 조회합니다. `messages[0]`의 내용이 13.4KB에서 352B로 바뀌면 해시값이 완전히 달라지므로, 이전 세션에서 쌓은 캐시를 전혀 재사용할 수 없었습니다.

2.2. MCP 서버, deferred tools와의 관계

이 버그는 MCP 서버나 deferred tools를 사용하는 환경에서 더 큰 영향을 받았습니다. 다만 이것은 MCP 서버의 tool schema가 불안정해서가 아니라, deferred tools/MCP 설정/skills 정보가 resume 시 `messages[0]`이 아닌 다른 위치에 배치되어 prefix가 달라지기 때문입니다. MCP 서버가 매번 완전히 동일한 schema를 반환하더라도, resume만 하면 메시지 구조가 달라져서 캐시 미스가 발생했습니다.

v2.1.90의 수정 내용도 이를 뒷받침합니다.

Fixed --resume causing a full prompt-cache miss on the first request for users with deferred tools, MCP servers, or custom agents

2.3. 부수적 문제: 매 턴 tool schema 재직렬화

근본 원인과 별개로, Claude Code가 매 턴마다 MCP tool schema를 `JSON.stringify`로 재계산하여 캐시 키를 만드는 비효율도 있었습니다. 이것은 캐시 미스를 유발하는 직접적인 원인은 아니었지만 성능 오버헤드를 발생시켰고, v2.1.90에서 tool schema를 한 번만 계산하고 재사용하도록 개선되었습니다.

3. 영향 범위

이 버그는 --resume (CLI 플래그)과 /resume (슬래시 커맨드) 모두에 해당합니다. 두 방식 모두 세션 재개 시 동일한 메시지 구조 불일치가 발생하기 때문입니다.

단, Prompt Cache의 TTL이 기본 5분 ^[1] 이므로 실질적인 비용 손해가 발생하는 경우는 제한적입니다.

시나리오 영향

시나리오	영향
일반 연속 세션 (resume 없이)	영향 없음. `messages[0]`이 세션 내내 안정적으로 유지
5분 이내에 resume	캐시가 살아있어야 하는데 prefix 불일치로 캐시 미스 발생 → 비용 손해
5분 이후에 resume	어차피 TTL 만료로 캐시 소멸 → 버그와 무관하게 비용 동일
`--print --resume` 자동화	매 호출이 새 프로세스이므로 캐시를 전혀 재활용하지 못함 → 가장 큰 피해

일반 연속 세션 (resume 없이)

영향 없음. `messages[0]`이 세션 내내 안정적으로 유지

5분 이내에 resume

캐시가 살아있어야 하는데 prefix 불일치로 캐시 미스 발생 → 비용 손해

5분 이후에 resume

어차피 TTL 만료로 캐시 소멸 → 버그와 무관하게 비용 동일

--print --resume 자동화

매 호출이 새 프로세스이므로 캐시를 전혀 재활용하지 못함 → 가장 큰 피해

4. 비용 영향

정상 상태에서는 캐시가 쌓이면서 턴이 진행될수록 메시지당 비용이 감소합니다.

정상 (v2.1.68):  메시지 1 → $0.15,  메시지 4 → $0.02 (캐시 적중률 증가)
버그 (v2.1.69+): 모든 메시지 → $0.35~0.40 (매번 전체 히스토리를 Cache Write)

--print --resume 워크플로우에서는 cache_read 토큰이 ~11,000(시스템 프롬프트 분량)에 머물고, cache_creation 토큰이 300,000 이상으로 치솟는 현상이 관찰되었습니다. 메시지당 약 20배의 비용 증가가 보고되었습니다.

5. 수정 내용 (v2.1.90)

v2.1.90 (2026-04-01)에서 다음과 같이 수정되었습니다.

메시지 구조 정규화: 세션 재개 시 `messages[0]`에 deferred tools, MCP 설정, skills를 새 세션과 동일한 위치에 삽입하도록 변경
tool schema 재직렬화 제거: MCP tool schema를 한 번만 계산하고 캐시하여, 매 턴 `JSON.stringify`를 호출하지 않도록 성능 개선

현재 버전 확인:

claude --version

v2.1.90 이상이면 수정된 상태입니다.

6. 영향 받았는지 확인하는 방법

2026년 3월 5일~4월 1일 사이에 Claude Code를 사용했다면, 다음 방법으로 영향 여부를 확인할 수 있습니다.

6.1. Resume 사용 여부 확인

이 버그는 resume 시에만 발생하므로, 해당 기간에 resume을 사용했는지가 핵심입니다.

6.1.1. /resume (슬래시 커맨드) 확인

대화형 세션 안에서 `/resume`을 입력한 기록은 `~/.claude/history.jsonl`에 남습니다.

Claude Code 프롬프트

~/.claude/history.jsonl에서 2026년 3월 5일~4월 1일 사이의 /resume 기록을 찾아줘.
각 resume 시점에 대해, 같은 프로젝트의 ~/.claude/projects/ 아래 JSONL 세션 로그에서
직전 세션의 마지막 timestamp와의 시간 간격을 계산해줘.
5분 이내에 resume한 경우가 있는지 확인하고 싶어.

6.1.2. --resume (CLI 플래그) 확인

`claude --resume`처럼 CLI 인자로 실행한 경우는 `history.jsonl`에 기록되지 않습니다. 이 경우는 shell history에서 확인합니다.

bash 사용자

grep "claude.*--resume" ~/.bash_history

zsh 사용자

grep "claude.*--resume" ~/.zsh_history

bash는 기본적으로 명령 실행 시각을 기록하지 않으므로 ^[2], --resume 사용 여부만 확인할 수 있고 5분 간격 분석은 어렵습니다. zsh는 EXTENDED_HISTORY 옵션이 켜져 있으면 `~/.zsh_history`에 타임스탬프가 함께 기록됩니다.

--resume`을 주로 자동화 스크립트(--print --resume`)에서 사용했다면 해당 스크립트의 실행 로그를 확인하는 것이 더 정확합니다.

5분 이내에 resume한 기록이 없다면, Prompt Cache의 TTL(5분)이 만료된 후 재개한 것이므로 이 버그로 인한 추가 비용은 발생하지 않은 것입니다.

6.2. API 사용량 확인

Anthropic Console에서 해당 기간의 토큰 사용량을 확인합니다. 평소 대비 `cache_creation_input_tokens`가 비정상적으로 높고 `cache_read_input_tokens`가 낮다면 이 버그의 영향을 받았을 가능성이 있습니다.

6.3. 캐시 메트릭 모니터링

세션 중 API 응답의 캐시 관련 토큰을 확인합니다.

cache_creation_input_tokens: 대화가 진행될수록 감소해야 정상
cache_read_input_tokens: 대화가 진행될수록 증가해야 정상

버그 발생 시에는 `cache_read_input_tokens`가 낮은 값에 머물고, `cache_creation_input_tokens`가 계속 높게 유지됩니다.

7. 참고 자료

1. Anthropic API는 기본 5분(ephemeral)과 1시간("ttl": "1h") 두 가지 TTL 옵션을 제공합니다. 1시간 옵션은 cache write 비용이 기본 입력 토큰의 2배(5분은 1.25배)로 더 높습니다. Claude Code에서는 구독 플랜에 따라 자동 결정되며(Max 플랜: 1시간, Pro 플랜/API 키: 5분), 사용자가 직접 설정할 수는 없습니다. 자세한 내용은 Anthropic 공식 문서를 참고하세요.

2. HISTTIMEFORMAT`을 설정하면 `history 명령에서 시각이 표시되지만, ~/.bash_history 파일 자체에는 타임스탬프가 저장되지 않습니다.

Claude Code 비용 최적화를 위한 지표 수집

Wed, 1 Apr 2026 00:00:00 +0000

Claude Code를 효율적으로 사용하고 있는지 개인적으로나 팀 차원에서 자주 돌아보고 개선 시도를 한다면, 같은 작업을 더 적은 비용으로 할 수 있습니다. 이 글에서는 Claude Code의 Hook과 OpenTelemetry를 활용하여 사용 지표를 수집하고, 수집된 데이터로 개인별 개선 권고 리포트를 만드는 방법을 정리합니다.

1. 수집해야 할 지표

비용 최적화 관점에서 의미 있는 지표는 크게 네 영역으로 나뉩니다.

1.1. 컨텍스트 관리 효율성

컨텍스트가 가득 차서 자동 압축(autocompact)이 발생하면, 그만큼 한 세션에서 많은 토큰을 소비했다는 신호입니다.

지표 의미

지표	의미
세션 시작 유형 (`source`)	`startup`(신규), `resume`(재개), `compact`(압축 후), `clear`(`/clear` 후) 비율로 사용 습관을 파악
자동 압축 빈도	세션당 autocompact 횟수가 많으면 작업 단위를 더 작게 분리할 필요가 있음
압축 간격	압축 사이 시간이 짧을수록 컨텍스트를 빠르게 소진하고 있다는 의미

세션 시작 유형 (source)

startup(신규), resume(재개), compact(압축 후), clear(/clear 후) 비율로 사용 습관을 파악

자동 압축 빈도

세션당 autocompact 횟수가 많으면 작업 단위를 더 작게 분리할 필요가 있음

압축 간격

압축 사이 시간이 짧을수록 컨텍스트를 빠르게 소진하고 있다는 의미

1.2. 도구 사용 패턴

Claude Code는 파일 읽기, 편집, 명령 실행 등 도구를 호출할 때마다 API 호출이 발생합니다. 도구 사용 방식에 따라 같은 작업의 토큰 소비량이 크게 달라집니다.

지표 의미

지표	의미
도구별 호출 빈도	어떤 도구를 주로 쓰는지 파악. Bash`로 `cat, grep`을 반복 호출하면 전용 도구(`Read, `Grep`)보다 토큰을 더 소비
도구 호출 실패율	실패 후 재시도는 토큰 낭비. 반복 실패 패턴은 사용자 교육이 필요한 영역
서브에이전트 생성 빈도	`Agent` 도구로 서브에이전트를 생성하면 추가 API 호출이 발생. 불필요한 서브에이전트 생성은 비용 증가 요인

도구별 호출 빈도

어떤 도구를 주로 쓰는지 파악. Bash`로 `cat, grep`을 반복 호출하면 전용 도구(`Read, Grep)보다 토큰을 더 소비

도구 호출 실패율

실패 후 재시도는 토큰 낭비. 반복 실패 패턴은 사용자 교육이 필요한 영역

서브에이전트 생성 빈도

Agent 도구로 서브에이전트를 생성하면 추가 API 호출이 발생. 불필요한 서브에이전트 생성은 비용 증가 요인

1.3. 세션 수명 주기

지표	의미
세션 길이 (시작~종료 시간)	세션이 길수록 컨텍스트가 누적되어 턴당 입력 토큰이 증가 ^[1]
세션 종료 사유	정상 종료, 비정상 종료, rate limit 등의 비율

지표

의미

세션 길이 (시작~종료 시간)

세션이 길수록 컨텍스트가 누적되어 턴당 입력 토큰이 증가 ^[1]

세션 종료 사유

정상 종료, 비정상 종료, rate limit 등의 비율

1.4. API 호출과 비용

가장 직접적인 비용 지표입니다.

지표	의미
API 호출 횟수	세션당, 프롬프트당 API 호출 수
호출당 토큰 수	입력/출력/캐시 읽기/캐시 쓰기 토큰
호출당 비용 (USD)	모델별 단가 적용된 실제 비용
모델별 사용 비율	Opus vs Sonnet vs Haiku. Opus는 Sonnet 대비 5배 비용
캐시 히트율	캐시 읽기 토큰 비율이 높을수록 비용 효율적

지표

의미

API 호출 횟수

세션당, 프롬프트당 API 호출 수

호출당 토큰 수

입력/출력/캐시 읽기/캐시 쓰기 토큰

호출당 비용 (USD)

모델별 단가 적용된 실제 비용

모델별 사용 비율

Opus vs Sonnet vs Haiku. Opus는 Sonnet 대비 5배 비용

캐시 히트율

캐시 읽기 토큰 비율이 높을수록 비용 효율적

2. 지표별 수집 방법

수집 방법은 크게 두 가지입니다. Hook은 사용 행동 패턴을, OpenTelemetry는 정확한 비용 데이터를 수집합니다.

2.1. Hook으로 수집하는 지표

Claude Code의 Hook은 특정 이벤트 발생 시 셸 스크립트를 실행하는 기능입니다. 비용 데이터에는 직접 접근할 수 없지만, 사용 행동 패턴을 기록하는 데 적합합니다.

Hook 이벤트 수집 가능한 지표 비고

Hook 이벤트	수집 가능한 지표	비고
`SessionStart`	세션 시작 유형(`source`), 사용 모델(`model`)	`source` 값: `startup`, `resume`, `compact`, `clear`
`SessionEnd`	세션 종료 시각, 종료 사유	세션 시작 시각과 조합하면 세션 길이 산출
`PreCompact`	압축 발생 시각, 자동/수동 여부	`matcher: auto`로 자동 압축만 필터링 가능
`PreToolUse`	도구 이름, 호출 시각	고빈도 이벤트이므로 성능 영향 고려 필요
`PostToolUseFailure`	실패한 도구, 에러 내용	반복 실패 패턴 분석용
`SubagentStart`	서브에이전트 생성 시각	불필요한 서브에이전트 생성 패턴 분석

SessionStart

세션 시작 유형(source), 사용 모델(model)

source 값: startup, resume, compact, clear

SessionEnd

세션 종료 시각, 종료 사유

세션 시작 시각과 조합하면 세션 길이 산출

PreCompact

압축 발생 시각, 자동/수동 여부

`matcher: auto`로 자동 압축만 필터링 가능

PreToolUse

도구 이름, 호출 시각

고빈도 이벤트이므로 성능 영향 고려 필요

PostToolUseFailure

실패한 도구, 에러 내용

반복 실패 패턴 분석용

SubagentStart

서브에이전트 생성 시각

불필요한 서브에이전트 생성 패턴 분석

2.1.1. 수집 스크립트 예시

하나의 스크립트에서 이벤트 유형별로 분기하여 JSONL 형식으로 기록합니다.

~/.claude/scripts/log-usage.sh

#!/bin/bash
INPUT=$(cat)
EVENT=$(echo "$INPUT" | jq -r '.hook_event_name')
SESSION=$(echo "$INPUT" | jq -r '.session_id')
TIMESTAMP=$(date -u '+%Y-%m-%dT%H:%M:%SZ')
USER=$(whoami)

LOG_DIR="$HOME/.claude/usage-logs"
mkdir -p "$LOG_DIR"

case "$EVENT" in
  SessionStart)
    SOURCE=$(echo "$INPUT" | jq -r '.source')
    MODEL=$(echo "$INPUT" | jq -r '.model')
    echo "{\"ts\":\"$TIMESTAMP\",\"user\":\"$USER\",\"event\":\"session_start\",\"session\":\"$SESSION\",\"source\":\"$SOURCE\",\"model\":\"$MODEL\"}" \
      >> "$LOG_DIR/events.jsonl"
    ;;
  SessionEnd)
    echo "{\"ts\":\"$TIMESTAMP\",\"user\":\"$USER\",\"event\":\"session_end\",\"session\":\"$SESSION\"}" \
      >> "$LOG_DIR/events.jsonl"
    ;;
  PreCompact)
    echo "{\"ts\":\"$TIMESTAMP\",\"user\":\"$USER\",\"event\":\"compact\",\"session\":\"$SESSION\"}" \
      >> "$LOG_DIR/events.jsonl"
    ;;
  PreToolUse)
    TOOL=$(echo "$INPUT" | jq -r '.tool_name')
    echo "{\"ts\":\"$TIMESTAMP\",\"user\":\"$USER\",\"event\":\"tool_use\",\"session\":\"$SESSION\",\"tool\":\"$TOOL\"}" \
      >> "$LOG_DIR/events.jsonl"
    ;;
  PostToolUseFailure)
    TOOL=$(echo "$INPUT" | jq -r '.tool_name')
    echo "{\"ts\":\"$TIMESTAMP\",\"user\":\"$USER\",\"event\":\"tool_fail\",\"session\":\"$SESSION\",\"tool\":\"$TOOL\"}" \
      >> "$LOG_DIR/events.jsonl"
    ;;
  SubagentStart)
    echo "{\"ts\":\"$TIMESTAMP\",\"user\":\"$USER\",\"event\":\"subagent\",\"session\":\"$SESSION\"}" \
      >> "$LOG_DIR/events.jsonl"
    ;;
esac

2.1.2. settings.json 설정

~/.claude/settings.json

{
  "hooks": {
    "SessionStart": [
      { "hooks": [{ "type": "command", "command": "~/.claude/scripts/log-usage.sh" }] }
    ],
    "SessionEnd": [
      { "hooks": [{ "type": "command", "command": "~/.claude/scripts/log-usage.sh" }] }
    ],
    "PreCompact": [
      { "matcher": "auto",
        "hooks": [{ "type": "command", "command": "~/.claude/scripts/log-usage.sh" }] }
    ],
    "PreToolUse": [
      { "hooks": [{ "type": "command", "command": "~/.claude/scripts/log-usage.sh" }] }
    ],
    "PostToolUseFailure": [
      { "hooks": [{ "type": "command", "command": "~/.claude/scripts/log-usage.sh" }] }
    ],
    "SubagentStart": [
      { "hooks": [{ "type": "command", "command": "~/.claude/scripts/log-usage.sh" }] }
    ]
  }
}

2.2. OpenTelemetry로 수집하는 지표

Hook에서는 API 호출 횟수, 토큰 수, 비용 같은 핵심 비용 데이터에 접근할 수 없습니다. 이 데이터는 Claude Code의 OpenTelemetry 연동을 통해 수집할 수 있습니다.

Claude Code는 claude_code.api_request 이벤트를 OTLP로 내보냅니다. 이 이벤트에는 다음 필드가 포함됩니다.

필드 설명

필드	설명
`model`	사용된 모델 (예: `claude-sonnet-4-6`)
`cost_usd`	해당 API 호출의 비용 (USD)
`input_tokens`	입력 토큰 수
`output_tokens`	출력 토큰 수
`cache_read_tokens`	캐시에서 읽은 토큰 수
`cache_creation_tokens`	캐시에 새로 쓴 토큰 수
`duration_ms`	API 응답 시간
`event.sequence`	세션 내 API 호출 순번 (순서 보장용)
`prompt.id`	사용자 프롬프트 단위 UUID (한 프롬프트에서 여러 API 호출이 발생할 수 있음)

model

사용된 모델 (예: claude-sonnet-4-6)

cost_usd

해당 API 호출의 비용 (USD)

input_tokens

입력 토큰 수

output_tokens

출력 토큰 수

cache_read_tokens

캐시에서 읽은 토큰 수

cache_creation_tokens

캐시에 새로 쓴 토큰 수

duration_ms

API 응답 시간

event.sequence

세션 내 API 호출 순번 (순서 보장용)

prompt.id

사용자 프롬프트 단위 UUID (한 프롬프트에서 여러 API 호출이 발생할 수 있음)

2.2.1. 활성화 방법

환경 변수를 설정하면 Claude Code가 OTLP 프로토콜로 텔레메트리를 전송합니다.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

개발자 PC의 셸 프로파일(~/.bashrc, ~/.zshrc 등)에 추가하거나, 전사 dotfiles 관리 도구로 배포할 수 있습니다.

2.3. 수집 방법 요약

지표	Hook	OpenTelemetry
세션 시작/종료, 압축 빈도	O
도구 사용 패턴, 실패율	O
API 호출 횟수		O
토큰 수 (입력/출력/캐시)		O
호출당 비용 (USD)		O
모델별 사용 비율	O	O

지표

Hook

OpenTelemetry

세션 시작/종료, 압축 빈도

도구 사용 패턴, 실패율

API 호출 횟수

토큰 수 (입력/출력/캐시)

호출당 비용 (USD)

모델별 사용 비율

3. 개인 분석: 로컬 로그로 셀프 리포트 만들기

전사 수집 인프라가 없더라도, 앞서 설명한 Hook 스크립트로 로컬에 쌓인 ~/.claude/usage-logs/events.jsonl 파일만으로 개인 사용 패턴을 분석할 수 있습니다.

3.1. 분석 스크립트 예시

`jq`와 셸 명령만으로 주요 지표를 산출하는 스크립트입니다.

~/.claude/scripts/self-report.sh

#!/bin/bash
LOG="$HOME/.claude/usage-logs/events.jsonl"

if [ ! -f "$LOG" ]; then
  echo "로그 파일이 없습니다: $LOG"
  exit 1
fi

# 분석 기간 (기본: 최근 7일)
SINCE=$(date -u -d '7 days ago' '+%Y-%m-%dT00:00:00Z' 2>/dev/null \
     || date -u -v-7d '+%Y-%m-%dT00:00:00Z')  # macOS 호환
DATA=$(jq -c --arg since "$SINCE" 'select(.ts >= $since)' "$LOG")

echo "=== 셀프 사용 리포트 (최근 7일) ==="
echo ""

# 세션 수
SESSIONS=$(echo "$DATA" | jq -r 'select(.event=="session_start") | .session' | sort -u | wc -l)
echo "[세션 요약]"
echo "  세션 수: $SESSIONS"

# 세션 시작 유형 비율
echo "  시작 유형:"
echo "$DATA" | jq -r 'select(.event=="session_start") | .source' \
  | sort | uniq -c | sort -rn | while read count source; do
    echo "    $source: $count"
  done

# autocompact 횟수
COMPACTS=$(echo "$DATA" | jq -r 'select(.event=="compact")' | wc -l)
echo "  자동 압축 횟수: $COMPACTS (세션당 평균: $(echo "scale=1; $COMPACTS / $SESSIONS" | bc 2>/dev/null || echo "N/A"))"
echo ""

# 도구 사용 패턴
echo "[도구 사용]"
TOTAL_TOOLS=$(echo "$DATA" | jq -r 'select(.event=="tool_use")' | wc -l)
echo "  총 도구 호출: $TOTAL_TOOLS"
echo "  상위 도구:"
echo "$DATA" | jq -r 'select(.event=="tool_use") | .tool' \
  | sort | uniq -c | sort -rn | head -10 | while read count tool; do
    pct=$(echo "scale=0; $count * 100 / $TOTAL_TOOLS" | bc 2>/dev/null || echo "?")
    echo "    $tool: $count (${pct}%)"
  done

# Bash로 cat/grep/find 호출 비율 (도구 이름만으로는 Bash 내부 명령을 알 수 없으므로 Bash 비율만 표시)
BASH_COUNT=$(echo "$DATA" | jq -r 'select(.event=="tool_use" and .tool=="Bash")' | wc -l)
if [ "$TOTAL_TOOLS" -gt 0 ]; then
  BASH_PCT=$(echo "scale=0; $BASH_COUNT * 100 / $TOTAL_TOOLS" | bc 2>/dev/null || echo "?")
  echo "  Bash 도구 비율: ${BASH_PCT}% (30% 이상이면 전용 도구 활용 권장)"
fi

# 실패율
FAILS=$(echo "$DATA" | jq -r 'select(.event=="tool_fail")' | wc -l)
if [ "$TOTAL_TOOLS" -gt 0 ]; then
  FAIL_PCT=$(echo "scale=1; $FAILS * 100 / $TOTAL_TOOLS" | bc 2>/dev/null || echo "?")
  echo "  도구 호출 실패: $FAILS (실패율: ${FAIL_PCT}%)"
fi

# 서브에이전트
SUBAGENTS=$(echo "$DATA" | jq -r 'select(.event=="subagent")' | wc -l)
echo "  서브에이전트 생성: $SUBAGENTS (세션당 평균: $(echo "scale=1; $SUBAGENTS / $SESSIONS" | bc 2>/dev/null || echo "N/A"))"
echo ""

# 간단한 권고
echo "[자동 권고]"
COMPACT_AVG=$(echo "scale=1; $COMPACTS / $SESSIONS" | bc 2>/dev/null || echo "0")
if [ "$(echo "$COMPACT_AVG >= 3" | bc 2>/dev/null)" = "1" ]; then
  echo "  ⚠ 세션당 autocompact가 ${COMPACT_AVG}회입니다. 작업을 더 작은 단위로 분리하세요."
fi
if [ "$(echo "$BASH_PCT >= 30" | bc 2>/dev/null)" = "1" ]; then
  echo "  ⚠ Bash 도구 비율이 ${BASH_PCT}%입니다. Read, Grep, Glob 전용 도구를 활용하세요."
fi
if [ "$(echo "$FAIL_PCT > 15" | bc 2>/dev/null)" = "1" ]; then
  echo "  ⚠ 도구 호출 실패율이 ${FAIL_PCT}%입니다. 반복 실패하는 도구의 사용법을 점검하세요."
fi
SUBAGENT_AVG=$(echo "scale=1; $SUBAGENTS / $SESSIONS" | bc 2>/dev/null || echo "0")
if [ "$(echo "$SUBAGENT_AVG > 5" | bc 2>/dev/null)" = "1" ]; then
  echo "  ⚠ 세션당 서브에이전트가 평균 ${SUBAGENT_AVG}회입니다. 간단한 검색은 직접 도구를 호출하세요."
fi
echo "  (비용 관련 권고는 OpenTelemetry 데이터가 필요합니다)"

스크립트 실행 결과 예시:

=== 셀프 사용 리포트 (최근 7일) ===

[세션 요약]
  세션 수: 15
  시작 유형:
    startup: 10
    resume: 3
    compact: 2
  자동 압축 횟수: 5 (세션당 평균: 0.3)

[도구 사용]
  총 도구 호출: 312
  상위 도구:
    Read: 89 (28%)
    Edit: 67 (21%)
    Bash: 58 (18%)
    Grep: 45 (14%)
    Glob: 32 (10%)
    Write: 12 (3%)
    Agent: 9 (2%)
  Bash 도구 비율: 18% (30% 이상이면 전용 도구 활용 권장)
  도구 호출 실패: 8 (실패율: 2.5%)
  서브에이전트 생성: 9 (세션당 평균: 0.6)

[자동 권고]
  (비용 관련 권고는 OpenTelemetry 데이터가 필요합니다)

이 스크립트는 별도의 인프라 없이도 개인이 즉시 실행하여 자신의 사용 습관을 점검할 수 있습니다. 팀 평균과의 비교가 필요 없는 개인 수준의 개선에는 이것만으로 충분합니다.

4. 수집 데이터 저장소

다수 사용자의 데이터를 분석하려면 중앙 저장소가 필요합니다. 조직 규모와 기존 인프라에 따라 선택지가 달라집니다.

4.1. 저장소 구성

개발자 PC                         중앙 수집                    분석/리포트
┌──────────────┐                ┌─────────────────┐         ┌──────────────┐
│ Claude Code  │                │                 │         │              │
│  ├ Hook      │── JSONL 전송 ─▶│  저장소          │────────▶│  분석 파이프  │
│  └ OTel      │── OTLP ──────▶│                 │         │  라인        │
└──────────────┘                └─────────────────┘         └──────────────┘

4.2. 저장소 선택지

방식	장점	단점	적합한 규모
파일 기반 (JSONL + S3)	구축 비용 최소, 별도 인프라 불필요	실시간 쿼리 어려움, 분석 시 별도 로딩 필요	소규모 (10명 이하)
OpenTelemetry Collector + Clickhouse	OTLP 네이티브 수집, 대량 시계열 데이터에 강점	Clickhouse 운영 부담	중규모 (10~100명)
Grafana + Loki/Tempo	기존 모니터링 인프라 활용 가능, 대시보드 내장	학습 곡선, 커스텀 리포트 생성이 번거로움	모니터링 인프라가 이미 있는 조직
BigQuery / Athena	SQL로 자유로운 분석, 대규모 데이터 처리	클라우드 비용, 초기 파이프라인 구축	대규모 (100명 이상)

방식

장점

단점

적합한 규모

파일 기반 (JSONL + S3)

구축 비용 최소, 별도 인프라 불필요

실시간 쿼리 어려움, 분석 시 별도 로딩 필요

소규모 (10명 이하)

OpenTelemetry Collector + Clickhouse

OTLP 네이티브 수집, 대량 시계열 데이터에 강점

Clickhouse 운영 부담

중규모 (10~100명)

Grafana + Loki/Tempo

기존 모니터링 인프라 활용 가능, 대시보드 내장

학습 곡선, 커스텀 리포트 생성이 번거로움

모니터링 인프라가 이미 있는 조직

BigQuery / Athena

SQL로 자유로운 분석, 대규모 데이터 처리

클라우드 비용, 초기 파이프라인 구축

대규모 (100명 이상)

4.3. Hook 데이터 중앙 수집

Hook은 기본적으로 개발자 PC의 로컬 파일에 기록합니다. 중앙으로 모으려면 추가 처리가 필요합니다. 몇 가지 방법이 있습니다.

cron + rsync/scp: 주기적으로 로컬 JSONL을 중앙 서버나 S3로 전송
Hook 스크립트에서 직접 전송: `curl`로 수집 API에 POST (단, Hook 실행 시간이 세션 성능에 영향을 줄 수 있으므로 백그라운드 전송 권장)
Fluentd/Fluent Bit: 로컬 JSONL 파일을 tail하여 중앙 저장소로 전송

OpenTelemetry 데이터는 OTLP 엔드포인트를 중앙 Collector로 지정하면 별도 처리 없이 수집됩니다.

5. 권고 가이드 생성 로직

수집된 데이터를 분석하여 개인별 개선 권고를 생성하는 로직입니다.

5.1. 컨텍스트 관리 권고

조건 판정 권고

조건	판정	권고
세션당 autocompact >= 3회	컨텍스트 과다 사용	"작업을 더 작은 단위로 분리하세요. 한 세션에서 하나의 목적만 달성하는 것이 비용 효율적입니다."
compact 간격 < 10분	빠른 컨텍스트 소진	"프롬프트를 더 간결하게 작성하거나, 불필요한 파일 읽기를 줄여보세요."
`source=resume` 비율 < 10%	세션 재개를 활용하지 않음	"이전 세션을 재개(`claude --resume`)하면 컨텍스트를 처음부터 다시 구성하지 않아도 됩니다."

세션당 autocompact >= 3회

컨텍스트 과다 사용

"작업을 더 작은 단위로 분리하세요. 한 세션에서 하나의 목적만 달성하는 것이 비용 효율적입니다."

compact 간격 < 10분

빠른 컨텍스트 소진

"프롬프트를 더 간결하게 작성하거나, 불필요한 파일 읽기를 줄여보세요."

source=resume 비율 < 10%

세션 재개를 활용하지 않음

"이전 세션을 재개(claude --resume)하면 컨텍스트를 처음부터 다시 구성하지 않아도 됩니다."

5.2. 도구 사용 권고

조건 판정 권고

조건	판정	권고
Bash로 `cat`/`grep`/`find` 호출 비율 > 30%	전용 도구 미활용	"Bash 대신 Read, Grep, Glob 등 전용 도구를 사용하면 토큰을 절약할 수 있습니다."
도구 호출 실패율 > 15%	비효율적 도구 사용	"도구 호출 실패가 잦습니다. 에러 메시지를 확인하고 사용법을 점검해보세요."
세션당 서브에이전트 > 5회	서브에이전트 남용 가능성	"서브에이전트 생성을 줄이고, 간단한 검색은 직접 도구를 호출하는 것이 비용 효율적입니다."

Bash로 cat/grep/find 호출 비율 > 30%

전용 도구 미활용

"Bash 대신 Read, Grep, Glob 등 전용 도구를 사용하면 토큰을 절약할 수 있습니다."

도구 호출 실패율 > 15%

비효율적 도구 사용

"도구 호출 실패가 잦습니다. 에러 메시지를 확인하고 사용법을 점검해보세요."

세션당 서브에이전트 > 5회

서브에이전트 남용 가능성

"서브에이전트 생성을 줄이고, 간단한 검색은 직접 도구를 호출하는 것이 비용 효율적입니다."

5.3. 모델 선택 권고

조건	판정	권고
Opus 사용 비율 > 50%	고비용 모델 과다 사용	"단순 편집이나 검색 작업에는 Sonnet을 사용하세요. Opus는 Sonnet 대비 5배 비용입니다."
서브에이전트에서 Opus 사용	서브에이전트 비용 과다	"서브에이전트는 Sonnet이나 Haiku로 충분한 경우가 많습니다."

조건

판정

권고

Opus 사용 비율 > 50%

고비용 모델 과다 사용

"단순 편집이나 검색 작업에는 Sonnet을 사용하세요. Opus는 Sonnet 대비 5배 비용입니다."

서브에이전트에서 Opus 사용

서브에이전트 비용 과다

"서브에이전트는 Sonnet이나 Haiku로 충분한 경우가 많습니다."

5.4. 비용 효율 권고

이 항목은 OpenTelemetry 데이터가 있어야 산출 가능합니다.

조건	판정	권고
캐시 히트율 < 50%	캐시 활용 부족	"세션 중간에 모델을 전환하거나 CLAUDE.md를 수정하면 캐시가 무효화됩니다. 한 세션에서는 하나의 모델을 유지하세요." ^[2]
프롬프트당 API 호출 > 20회	한 프롬프트에 과도한 작업 요청	"하나의 프롬프트에 여러 작업을 한꺼번에 요청하면 API 호출이 급증합니다. 작업을 나누어 요청하세요."
일일 비용이 팀 평균의 2배 이상	비용 이상치	개별 상담 대상. 사용 패턴 상세 분석 필요

조건

판정

권고

캐시 히트율 < 50%

캐시 활용 부족

"세션 중간에 모델을 전환하거나 CLAUDE.md를 수정하면 캐시가 무효화됩니다. 한 세션에서는 하나의 모델을 유지하세요." ^[2]

프롬프트당 API 호출 > 20회

한 프롬프트에 과도한 작업 요청

"하나의 프롬프트에 여러 작업을 한꺼번에 요청하면 API 호출이 급증합니다. 작업을 나누어 요청하세요."

일일 비용이 팀 평균의 2배 이상

비용 이상치

개별 상담 대상. 사용 패턴 상세 분석 필요

5.5. 리포트 예시

위의 로직을 조합하면 다음과 같은 개인별 주간 리포트를 생성할 수 있습니다.

=== 주간 사용 리포트 (2026-03-24 ~ 2026-03-30) ===
사용자: hong

[요약]
  세션 수: 23
  총 API 호출: 847
  총 비용: $42.30
  주요 모델: Sonnet 68%, Opus 32%

[개선 권고]
  1. 컨텍스트 관리
     - 세션당 평균 autocompact: 3.2회 (팀 평균: 1.1회)
     → 작업을 더 작은 단위로 분리하세요.

  2. 도구 사용
     - Bash로 grep/cat 호출: 전체 도구 사용의 41%
     → Read, Grep 전용 도구를 직접 사용하면 토큰을 절약할 수 있습니다.

  3. 모델 선택
     - Opus 사용 비율: 32% (팀 평균: 15%)
     → 단순 작업에서는 Sonnet으로 전환을 권장합니다.
     → 예상 절감: 주당 ~$8.50

[잘하고 있는 점]
  - 캐시 히트율 87% (팀 평균: 72%)
  - 도구 호출 실패율 3% (팀 평균: 8%)

6. 주의할 점

PreToolUse는 고빈도 이벤트입니다. Hook 스크립트의 실행 시간이 길면 세션 응답 속도에 영향을 줄 수 있습니다. 스크립트를 가볍게 유지하거나, 샘플링을 적용하거나, 백그라운드로 기록하는 방식을 고려해야 합니다.
전사 배포가 필요합니다. Hook 설정과 환경 변수를 각 개발자 PC에 배포해야 합니다. Enterprise managed config, dotfiles 저장소, 또는 온보딩 스크립트를 활용할 수 있습니다.
Hook으로는 정확한 토큰 수와 비용을 알 수 없습니다. 비용 분석이 목적이라면 OpenTelemetry는 필수입니다. Hook만으로는 사용 행동 패턴 분석에 한정됩니다.
개인정보 고려가 필요합니다. 프롬프트 내용이나 코드를 수집하는 것이 아니라 메타데이터(이벤트 유형, 도구 이름, 타임스탬프)만 수집하지만, 수집 목적과 범위를 사전에 공유하고 동의를 구하는 것이 바람직합니다.

7. 참고 자료

1. 턴당 입력 토큰의 이차 증가에 대해서는 Claude Code 토큰 비용과 프롬프트 캐싱을 참고

2. Prompt Caching의 상세 원리는 Claude Code 토큰 비용과 프롬프트 캐싱을 참고

Claude Code Hook으로 quota 전환 자동화하기

Sun, 29 Mar 2026 00:00:00 +0000

Table of Contents

배경
전체 구성
구현과 테스트 프롬프트
- 구현 프롬프트
- 테스트 프롬프트
사용 방법
생성된 코드 분석
한계
macOS에서의 차이점

배경

Claude Code를 여러 quota로 사용하는 경우가 있습니다. 예를 들면 다음과 같습니다.

Max plan을 2개를 구독해서 번갈아 가면서 쓰는 경우
같은 이메일 계정에 여러 organization이 연결되어 각각 별도의 quota가 있는 경우
Team plan과 Enterprise plan을 동시에 구독하는 경우

이런 상황에서 한쪽 quota가 소진되면 다른 쪽으로 전환해서 쓸 수 있습니다. 문제는 quota A가 소진되어 quota B로 전환한 뒤, quota A가 초기화되는 시점에 다시 돌아오는 걸 잊기 쉽다는 것입니다. Claude Code의 Hook 기능을 활용하면 이 전환을 자동화할 수 있습니다.

이 글은 Claude Code에게 프롬프트를 내려서 hook 스크립트를 생성하고, 생성된 코드를 분석하는 방식으로 구성됩니다.

전체 구성

필요 환경

Claude Code v2.1.78(2026년 3월 18일 릴리즈) 이상 (StopFailure hook 이벤트 지원)
jq 설치 필요

원리: Quota 소진 시 Claude Code의 동작

사용자에게 보여주는 메시지

Claude Code에서는 API quota를 소진 시 초기화 예정 시간을 포함한 메시지를 안내합니다.

5시간 한도 소진 시

You've hit your limit · resets 2pm (Asia/Seoul)

주간 한도 소진 시에는 날짜도 포함됩니다:

주간 한도 소진 시

You've hit your limit · resets Feb 20, 5pm (Asia/Seoul)

메시지 형식은 Claude Code 버전에 따라 달라져 왔습니다. 과거에는 Claude usage limit reached. Your limit will reset at 2pm (America/New_York) 형식이었고, 중간에 5-hour limit reached · resets 12pm 을 거쳐, 현재의 You’ve hit your limit · resets … 형식이 되었습니다.

StopFailure hook 이벤트

Quota 소진 시 발생하는 hook 이벤트는 StopFailure 입니다 (2026년 3월 18일 릴리즈된 v2.1.78에서 도입). Notification 이나 Stop 은 quota 소진 시 발생하지 않습니다.

StopFailure 이벤트의 JSON 입력 (실제 기록된 데이터)

{
  "session_id": "5cbd3730-...",
  "transcript_path": "/home/user/.claude/projects/.../abc123.jsonl",
  "cwd": "/home/user/project",
  "hook_event_name": "StopFailure",
  "error": "rate_limit",
  "last_assistant_message": "You've hit your limit · resets 11pm (Asia/Seoul)"
}

초기화 시간 전용 필드는 없지만 (#36056, #30784에서 기능 요청 중), last_assistant_message 필드에 초기화 시간이 포함된 메시지가 담겨 옵니다. `on-rate-limit.sh`에서 이 필드를 grep하여 초기화 시간을 추출합니다.

실행 흐름

아래는 quota 전환 자동화의 전체 흐름입니다. 스크립트 3개와 hook 2개로 구성됩니다.

[Quota A 소진]
    │
    ▼
StopFailure hook (rate_limit) ──→ on-rate-limit.sh
    │                                  │
    │                          last_assistant_message에서 초기화 시간 파싱
    │                                  │
    │                                  ▼
    │                          quota-switch-reset-time 파일에 기록
    │
    ▼
[사용자가 /logout 후 Quota B로 로그인]
    │
    ▼
[Quota B로 작업 계속]
    │
    ▼
[초기화 시간 경과 후 새 세션 or /clear]
    │
    ▼
SessionStart hook ──→ check-quota-switch.sh
                          │
                  시간 비교: 현재 >= 초기화 시간?
                          │
                    Yes ──┤
                          │
                  credentials 삭제 + 세션 블로킹
                          │
                          ▼
                  [Claude Code 재시작 → Quota A로 로그인]

스크립트 역할 호출 시점

스크립트	역할	호출 시점
`on-rate-limit.sh`	Hook 입력의 `last_assistant_message` 에서 초기화 시간을 파싱하여 기록	`StopFailure` hook (`rate_limit`)
`check-quota-switch.sh`	초기화 시간이 지났으면 credentials를 삭제하여 재로그인 유도	`SessionStart` hook (`startup`, `clear`)
`record-quota-reset.sh`	초기화 시간을 수동으로 기록 (자동 파싱 실패 시 fallback)	사용자가 직접 실행

on-rate-limit.sh

Hook 입력의 last_assistant_message 에서 초기화 시간을 파싱하여 기록

StopFailure hook (rate_limit)

check-quota-switch.sh

초기화 시간이 지났으면 credentials를 삭제하여 재로그인 유도

SessionStart hook (startup, clear)

record-quota-reset.sh

초기화 시간을 수동으로 기록 (자동 파싱 실패 시 fallback)

사용자가 직접 실행

구현과 테스트 프롬프트

구현 프롬프트

아래와 같은 프롬프트로 Claude Code에게 구현을 요청합니다.

Claude Code를 quota A, quota B 두 개로 쓰고 있어. Quota A가 소진되면 quota B로 전환해서 쓰다가, quota A의 초기화 시간이 지난 후 새 세션이나 /clear 시에 자동으로 quota B를 logout시켜서 quota A로 복귀하고 싶어. 아래 요구사항대로 구현해줘.

quota 소진 감지: StopFailure hook에 rate_limit matcher를 걸어서 소진 시점을 감지해줘. 스크립트 이름은 on-rate-limit.sh로 해줘.

초기화 시간 자동 기록: on-rate-limit.sh에서 hook 입력의 last_assistant_message 필드에서 "resets TIME (TIMEZONE)" 패턴을 파싱하여 초기화 시간을 ~/.claude/quota-switch-reset-time에 epoch으로 저장해줘.

초기화 시간 수동 기록(fallback): 자동 파싱이 실패할 경우를 대비해 record-quota-reset.sh도 만들어줘. "4h", "30m" 같은 상대 시간과 절대 시간을 지원해야해.

자동 복귀: SessionStart hook에서 check-quota-switch.sh를 실행해서, 현재 시간이 초기화 시간을 지났으면 credentials를 삭제하여 재로그인을 유도해줘. startup과 clear 두 matcher 모두 등록해줘.

Claude Code는 이 요청을 받아 세 개의 스크립트 파일을 생성하고, `~/.claude/settings.json`에 hook 설정까지 직접 등록했습니다. 사용자가 `settings.json`을 수동으로 편집할 필요 없이, 프롬프트 하나로 스크립트 작성과 hook 등록이 모두 완료됩니다.

테스트 프롬프트

실제 quota를 소진하지 않고도 hook과 스크립트가 정상 동작하는지 검증할 수 있습니다. 테스트 역시 Claude Code에게 요청하면 됩니다.

~/.claude/settings.json에 등록된 on-rate-limit.sh와 check-quota-switch.sh를 실제 quota 소진 없이 테스트하고 싶어. on-rate-limit.sh는 hook JSON 입력을 직접 구성해서 stdin으로 넘기는 방식으로 테스트해줘. "resets 2pm (Asia/Seoul)" 같은 5시간 한도 메시지와 "resets Feb 20, 5pm (Asia/Seoul)" 같은 주간 한도 메시지 두 가지를 모두 테스트해줘. 각 테스트 후 hook-events.log와 quota-switch-reset-time 파일을 확인해줘. check-quota-switch.sh는 과거 시간의 epoch을 기록한 뒤 실행해서 credentials 삭제 동작을 검증해줘. 단, 실제 credentials가 삭제되므로 테스트 전에 백업하고 테스트 후 복원해줘.

Claude Code는 이 요청에 따라 hook JSON을 직접 구성하여 `on-rate-limit.sh`에 전달하고, 결과를 확인하는 과정을 수행합니다. 예를 들어 5시간 한도 메시지 테스트는 다음과 같이 실행됩니다:

echo '{
  "hook_event_name": "StopFailure",
  "error": "rate_limit",
  "last_assistant_message": "You'\''ve hit your limit · resets 2pm (Asia/Seoul)"
}' | ~/.claude/scripts/on-rate-limit.sh

테스트가 성공하면 ~/.claude/hook-events.log 에 "Auto-recorded quota reset time"이 기록되고, ~/.claude/quota-switch-reset-time 파일에 epoch 값이 저장됩니다.

사용 방법

1단계: quota A 소진

Quota A가 소진되면 StopFailure hook이 자동으로 on-rate-limit.sh 를 실행합니다. Hook 입력의 last_assistant_message 에서 초기화 시간을 파싱하여 `~/.claude/quota-switch-reset-time`에 기록합니다. `~/.claude/hook-events.log`에서 "Auto-recorded quota reset time"이 기록되었는지 확인할 수 있습니다.

자동 파싱에 실패한 경우, 로그에 실패 사유가 기록됩니다. 이때는 수동으로 쿼터가 초기화될 시간을 기록합니다:

record-quota-reset.sh 수동 실행 예시

# 절대 시간
~/.claude/scripts/record-quota-reset.sh "2026-03-29 09:00"

# 상대 시간
~/.claude/scripts/record-quota-reset.sh 4h
~/.claude/scripts/record-quota-reset.sh 30m

2단계: quota B로 전환

Claude Code에서 /logout 을 실행한 후 quota B 계정으로 재로그인합니다.

3단계: 자동 복귀

기록된 초기화 시간이 지난 후에 Claude Code를 새로 시작하거나 /clear 를 실행하면 SessionStart hook이 동작합니다. Quota B의 credentials가 자동으로 제거되고, Claude Code를 재시작하면 quota A로 로그인할 수 있습니다.

생성된 코드 분석

아래 코드는 Linux 환경에서 생성된 것입니다. macOS에서의 차이점은 macOS에서의 차이점를 참고하세요.

Quota 소진 감지 및 초기화 시간 자동 기록

~/.claude/scripts/on-rate-limit.sh 는 StopFailure hook에서 실행되는 스크립트입니다. Quota 소진 시 hook 입력의 last_assistant_message 필드에서 초기화 시간을 파싱하여 기록합니다.

on-rate-limit.sh

#!/bin/bash
# StopFailure hook (matcher: rate_limit)
# 1. Log the event for diagnostics
# 2. Extract reset time from last_assistant_message (hook JSON input)

LOG_FILE="$HOME/.claude/hook-events.log"
INPUT=$(cat)

# Step 1: Log the event
echo "=== $(date '+%Y-%m-%d %H:%M:%S') ===" >> "$LOG_FILE"
echo "$INPUT" | jq . >> "$LOG_FILE" 2>/dev/null || echo "$INPUT" >> "$LOG_FILE"
echo "" >> "$LOG_FILE"

# Step 2: Extract reset time from last_assistant_message
LAST_MSG=$(echo "$INPUT" | jq -r '.last_assistant_message // empty')
if [ -z "$LAST_MSG" ]; then
    echo "No last_assistant_message in hook input" >> "$LOG_FILE"
    exit 0
fi

RESET_LINE=$(echo "$LAST_MSG" | grep -oP \
    'resets?\s+(at\s+)?(\w+\s+\d+,?\s+)?\d{1,2}(:\d{2})?\s*[ap]m(\s*\([^)]+\))?')

if [ -z "$RESET_LINE" ]; then
    echo "No reset time found in message: $LAST_MSG" >> "$LOG_FILE"
    exit 0
fi

echo "Found reset info: $RESET_LINE" >> "$LOG_FILE"

# Step 3: Parse the reset time
TIME_PART=$(echo "$RESET_LINE" | grep -oP '\d{1,2}(:\d{2})?\s*[ap]m')
DATE_PART=$(echo "$RESET_LINE" | grep -oP '(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s+\d{1,2}' | head -1)
TZ_PART=$(echo "$RESET_LINE" | grep -oP '\(([^)]+)\)' | tr -d '()')

# Convert 12-hour to 24-hour
HOUR=$(echo "$TIME_PART" | grep -oP '^\d{1,2}')
MINUTE=$(echo "$TIME_PART" | grep -oP ':\K\d{2}' || echo "00")
AMPM=$(echo "$TIME_PART" | grep -oP '[ap]m')

if [ "$AMPM" = "pm" ] && [ "$HOUR" -ne 12 ]; then
    HOUR=$((HOUR + 12))
elif [ "$AMPM" = "am" ] && [ "$HOUR" -eq 12 ]; then
    HOUR=0
fi
TIME_24=$(printf "%02d:%s" "$HOUR" "$MINUTE")

# Build datetime string
TODAY=$(date "+%Y-%m-%d")
if [ -n "$DATE_PART" ]; then
    YEAR=$(date "+%Y")
    DATETIME="$DATE_PART $YEAR $TIME_24"
else
    DATETIME="$TODAY $TIME_24"
fi

# Convert to epoch
if [ -n "$TZ_PART" ]; then
    RESET_EPOCH=$(TZ="$TZ_PART" date -d "$DATETIME" +%s 2>/dev/null)
else
    RESET_EPOCH=$(date -d "$DATETIME" +%s 2>/dev/null)
fi

if [ -z "$RESET_EPOCH" ]; then
    echo "Failed to parse reset time: $DATETIME (TZ=$TZ_PART)" >> "$LOG_FILE"
    exit 0
fi

# If parsed time is in the past, assume next day (5-hour limit case)
NOW_EPOCH=$(date +%s)
if [ "$RESET_EPOCH" -le "$NOW_EPOCH" ] && [ -z "$DATE_PART" ]; then
    RESET_EPOCH=$((RESET_EPOCH + 86400))
fi

# Step 4: Record the reset time
RESET_FILE="$HOME/.claude/quota-switch-reset-time"
echo "$RESET_EPOCH" > "$RESET_FILE"
RESET_DISPLAY=$(date -d "@$RESET_EPOCH" "+%Y-%m-%d %H:%M:%S")
echo "Auto-recorded quota reset time: $RESET_DISPLAY" >> "$LOG_FILE"

exit 0

last_assistant_message 필드에서 resets TIME (TIMEZONE) 패턴을 grep하여 초기화 시간을 추출하는 원리는 StopFailure hook 이벤트를 참고하세요.

초기화 시간 수동 기록 (fallback)

~/.claude/scripts/record-quota-reset.sh 는 자동 파싱이 실패했을 때 초기화 시간을 수동으로 기록하는 스크립트입니다.

record-quota-reset.sh

#!/bin/bash
# Record when quota A resets so the hook can switch back from quota B
# Usage: record-quota-reset.sh "2026-03-29 09:00"
#        record-quota-reset.sh 4h    (4 hours from now)
#        record-quota-reset.sh 30m   (30 minutes from now)

RESET_FILE="$HOME/.claude/quota-switch-reset-time"

if [ -z "$1" ]; then
    echo "Usage: $0 <datetime or duration>"
    echo "  Examples:"
    echo "    $0 '2026-03-29 09:00'   # absolute time"
    echo "    $0 4h                    # 4 hours from now"
    echo "    $0 30m                   # 30 minutes from now"
    exit 1
fi

INPUT="$1"

# Parse duration format (e.g., 4h, 30m)
if [[ "$INPUT" =~ ^([0-9]+)h$ ]]; then
    HOURS="${BASH_REMATCH[1]}"
    RESET_EPOCH=$(date -d "+${HOURS} hours" +%s)
    RESET_DISPLAY=$(date -d "+${HOURS} hours" "+%Y-%m-%d %H:%M:%S")
elif [[ "$INPUT" =~ ^([0-9]+)m$ ]]; then
    MINS="${BASH_REMATCH[1]}"
    RESET_EPOCH=$(date -d "+${MINS} minutes" +%s)
    RESET_DISPLAY=$(date -d "+${MINS} minutes" "+%Y-%m-%d %H:%M:%S")
else
    # Absolute datetime
    RESET_EPOCH=$(date -d "$INPUT" +%s 2>/dev/null)
    if [ $? -ne 0 ]; then
        echo "Error: Cannot parse datetime '$INPUT'"
        exit 1
    fi
    RESET_DISPLAY=$(date -d "$INPUT" "+%Y-%m-%d %H:%M:%S")
fi

echo "$RESET_EPOCH" > "$RESET_FILE"
echo "Quota A reset time recorded: $RESET_DISPLAY"
echo "Saved to: $RESET_FILE"
echo ""
echo "Now run /logout in Claude Code and log in with quota B."
echo "When the reset time arrives, the next session start or /clear will auto-logout quota B."

절대 시간("2026-03-29 09:00")과 상대 시간(4h, 30m) 두 가지 형식을 지원합니다. 내부적으로는 Unix epoch 타임스탬프로 변환하여 ~/.claude/quota-switch-reset-time 파일에 저장합니다.

자동 복귀

~/.claude/scripts/check-quota-switch.sh 는 SessionStart hook에서 실행되는 스크립트입니다.

check-quota-switch.sh

#!/bin/bash
# SessionStart hook: check if quota A has reset
# If so, remove credentials to force re-login with quota A

RESET_FILE="$HOME/.claude/quota-switch-reset-time"
CRED_FILE="$HOME/.claude/.credentials.json"

# No reset time recorded, nothing to do
if [ ! -f "$RESET_FILE" ]; then
    exit 0
fi

RESET_EPOCH=$(cat "$RESET_FILE")
NOW_EPOCH=$(date +%s)

if [ "$NOW_EPOCH" -ge "$RESET_EPOCH" ]; then
    # Time to switch back to quota A
    RESET_DISPLAY=$(date -d "@$RESET_EPOCH" "+%Y-%m-%d %H:%M:%S")

    # Backup quota B credentials and remove current credentials
    if [ -f "$CRED_FILE" ]; then
        cp "$CRED_FILE" "$HOME/.claude/.credentials.quota-b.bak"
        rm -f "$CRED_FILE"
    fi

    # Remove reset time file
    rm -f "$RESET_FILE"

    # Exit with code 2 to block session and show message
    echo "Quota A has reset (reset time: $RESET_DISPLAY)." >&2
    echo "Quota B credentials have been removed." >&2
    echo "Please restart Claude Code to log in with quota A." >&2
    exit 2
fi

# Not yet time to switch
exit 0

이 스크립트의 핵심 동작은 다음과 같습니다.

기록된 초기화 시간 파일이 없으면 `exit 0`으로 아무 동작 없이 종료합니다. 평소에는 hook이 세션 시작을 방해하지 않습니다.
현재 시간이 초기화 시간 이상이면 전환을 실행합니다.
~/.claude/.credentials.json 을 ~/.claude/.credentials.quota-b.bak 으로 백업한 후 삭제합니다. Credentials 파일이 없으면 Claude Code가 다음 시작 시 로그인을 요청합니다.
`exit 2`로 세션을 블로킹하고 stderr로 안내 메시지를 출력합니다. Claude Code hook에서 exit code 2는 세션 진행을 차단하고 stderr 메시지를 사용자에게 보여주는 약속된 규칙입니다.

settings.json hook 설정

~/.claude/settings.json 에 StopFailure`와 `SessionStart hook을 등록합니다.

{
  "hooks": {
    "StopFailure": [
      {
        "matcher": "rate_limit",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/.claude/scripts/on-rate-limit.sh"
          }
        ]
      }
    ],
    "SessionStart": [
      {
        "matcher": "startup",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/.claude/scripts/check-quota-switch.sh"
          }
        ]
      },
      {
        "matcher": "clear",
        "hooks": [
          {
            "type": "command",
            "command": "/home/user/.claude/scripts/check-quota-switch.sh"
          }
        ]
      }
    ]
  }
}

"matcher": "rate_limit" 으로 quota 소진 이벤트만 필터링합니다. SessionStart 이벤트는 startup (새 세션 시작)과 clear (/clear 실행) 두 경우 모두 같은 스크립트를 실행하도록 설정했습니다.

한계

credentials 저장소 의존: Linux에서는 ~/.claude/.credentials.json 파일을, macOS에서는 Keychain을 직접 조작하는 방식이므로, Claude Code의 내부 인증 구조가 변경되면 동작하지 않을 수 있습니다.
완전 자동 로그인은 불가: Credentials 제거 후 재시작 시 로그인 화면이 나타나지만, quota A 계정을 자동으로 선택해주지는 않습니다. 사용자가 직접 quota A 계정으로 로그인해야 합니다.
세션 중간 전환은 지원하지 않음: SessionStart hook은 새 세션 시작이나 /clear 시에만 동작합니다. 세션 중간에 초기화 시간이 지나더라도 현재 세션에서는 전환이 일어나지 않습니다. 매 프롬프트마다 체크하는 방식(UserPromptSubmit hook)도 가능하지만, 세션 중간에 credentials가 제거되면 진행 중인 작업과 컨텍스트가 유실되므로 권장하지 않습니다.
메시지 형식 의존: on-rate-limit.sh`의 파싱은 `last_assistant_message 필드의 resets TIME (TIMEZONE) 패턴에 의존합니다. Claude Code 버전에 따라 메시지 형식이 달라져 왔으므로, 향후 형식이 변경되면 파싱이 실패할 수 있습니다. 실패 시 ~/.claude/hook-events.log 에 원인이 기록되며, `record-quota-reset.sh`로 수동 기록할 수 있습니다.

macOS에서의 차이점

Claude Code는 실행 환경의 OS를 인식합니다. macOS에서 같은 요청을 하면 date 명령어 부분이 BSD 문법으로 생성됩니다. 주요 차이는 다음과 같습니다.

용도 Linux (GNU date) macOS (BSD date)

용도	Linux (GNU date)	macOS (BSD date)
상대 시간 (4시간 후)	`date -d "+4 hours" +%s`	`date -v+4H +%s`
절대 시간 파싱	`date -d "2026-03-29 09:00" +%s`	`date -j -f "%Y-%m-%d %H:%M" "2026-03-29 09:00" +%s`
epoch → 표시 형식	`date -d "@$EPOCH" "+%Y-%m-%d %H:%M:%S"`	`date -r $EPOCH "+%Y-%m-%d %H:%M:%S"`

상대 시간 (4시간 후)

date -d "+4 hours" +%s

date -v+4H +%s

절대 시간 파싱

date -d "2026-03-29 09:00" +%s

date -j -f "%Y-%m-%d %H:%M" "2026-03-29 09:00" +%s

epoch → 표시 형식

date -d "@$EPOCH" "+%Y-%m-%d %H:%M:%S"

date -r $EPOCH "+%Y-%m-%d %H:%M:%S"

이 외에도 macOS에서는 다음 차이가 있습니다:

grep -oP (PCRE)가 macOS 기본 grep에서 지원되지 않습니다. brew install grep 후 `ggrep`을 사용하거나, 정규식을 POSIX 호환으로 변경해야 합니다.
macOS에서 Claude Code의 credentials는 macOS Keychain에 저장됩니다. ~/.claude/.credentials.json 파일이 존재하지 않으므로, check-quota-switch.sh에서 파일을 삭제하는 방식이 동작하지 않습니다. macOS에서 프롬프트를 내리면 security delete-generic-password 명령으로 Keychain에서 credentials를 삭제하는 스크립트가 생성됩니다.

Go 코드에 품질 도구 적용하기

Sun, 29 Mar 2026 00:00:00 +0000

Table of Contents

1. gofmt: 코드 포맷팅
2. goimports: import 정리
3. go vet: 정적 분석
4. golangci-lint: 통합 린터
- 4.1. 설정 파일
- 4.2. 기본 활성화 린터 (default: standard)
5. Makefile로 통합
6. 참고 자료

Go는 언어 차원에서 코드 포맷팅 도구(gofmt)를 제공하고, 표준 도구 체인에 정적 분석(go vet)이 포함되어 있습니다. 이런 도구들을 프로젝트 초기에 설정해두면 코드 리뷰에서 스타일 논쟁을 줄이고, 흔한 실수를 빌드 전에 잡을 수 있습니다.

이 글에서는 Go로 개발하는 프로젝트에서 기본적으로 갖추면 좋은 도구들과 설정 방법을 정리합니다.

1. gofmt: 코드 포맷팅

Go 커뮤니티에서는 gofmt 이 표준 포맷터입니다. 탭/스페이스, 중괄호 위치 같은 스타일 논쟁 없이 모든 Go 코드가 동일한 포맷을 따르게 됩니다.

gofmt -w .

-w 플래그는 파일을 직접 수정합니다. -l 플래그를 쓰면 포맷이 맞지 않는 파일 목록만 출력합니다.

gofmt -l .

포맷이 맞지 않는 파일이 있으면 파일 경로가 출력되고, 모두 맞으면 아무것도 출력되지 않습니다. CI에서는 이 출력을 검사해서 포맷팅되지 않은 코드가 머지되는 것을 막을 수 있습니다.

2. goimports: import 정리

goimports는 `gofmt`의 기능에 더해 import 문을 자동으로 정리합니다.

사용하지 않는 import를 제거
필요한 import를 자동 추가
import를 표준 라이브러리 / 그 외 패키지 2그룹으로 정렬 (-local 플래그를 쓰면 로컬 패키지를 별도 그룹으로 분리 가능)

go install golang.org/x/tools/cmd/goimports@latest
goimports -w .

gofmt 대신 `goimports`만 실행해도 포맷팅까지 함께 처리됩니다.

3. go vet: 정적 분석

`go vet`은 Go 표준 도구 체인에 포함된 정적 분석 도구입니다. 컴파일러가 잡지 못하는 의심스러운 코드를 검출합니다.

go vet ./...

대표적으로 잡아주는 문제들은 다음과 같습니다.

fmt.Printf`의 포맷 문자열과 인자 불일치 (`printf)
도달할 수 없는 코드 (unreachable)
sync.Mutex 등 잠금을 값으로 복사하는 코드 (copylocks)
context.WithCancel`의 cancel 함수를 호출하지 않는 경로 (`lostcancel)

별도 설치 없이 바로 사용할 수 있으므로, 모든 Go 프로젝트에서 기본으로 실행하는 것이 좋습니다.

4. golangci-lint: 통합 린터

golangci-lint는 여러 린터를 하나의 도구로 통합해서 실행해주는 린터 러너입니다. 개별 린터를 따로 설치하고 실행할 필요 없이, 설정 파일 하나로 원하는 린터를 선택해서 쓸 수 있습니다.

## 바이너리 설치 (go install은 공식적으로 권장되지 않음)
curl -sSfL https://golangci-lint.run/install.sh | sh -s -- -b $(go env GOPATH)/bin
golangci-lint run ./...

4.1. 설정 파일

프로젝트 루트에 .golangci.yml 파일을 만들어 설정합니다. 아래는 golangci-lint v2 기준 설정 예시입니다.

.golangci.yml

version: "2"

linters:
  default: standard
  enable:
    - misspell

formatters:
  enable:
    - gofmt
    - goimports

v2에서는 `version: "2"`를 반드시 명시해야 합니다. `default: standard`로 설정하면 errcheck, govet, ineffassign, staticcheck, unused 5개 린터가 기본으로 활성화됩니다. 추가로 필요한 린터만 `enable`에 넣으면 됩니다.

v2의 또 다른 변경점은 gofmt, goimports 같은 포맷터가 linters`가 아닌 `formatters 섹션으로 분리된 것입니다. 기존 v1 설정 파일이 있다면 golangci-lint migrate 명령으로 자동 변환할 수 있습니다.

4.2. 기본 활성화 린터 (`default: standard`)

린터	설명
errcheck	에러 반환값을 무시하는 코드 검출
govet	`go vet`과 동일한 정적 분석
ineffassign	이후에 사용되지 않는 변수 할당 검출
staticcheck	Go 코드의 버그, 성능 문제, 스타일 문제를 종합적으로 검사 (gosimple, stylecheck 포함)
unused	사용되지 않는 변수, 함수, 타입 검출

린터

설명

errcheck

에러 반환값을 무시하는 코드 검출

govet

`go vet`과 동일한 정적 분석

ineffassign

이후에 사용되지 않는 변수 할당 검출

staticcheck

Go 코드의 버그, 성능 문제, 스타일 문제를 종합적으로 검사 (gosimple, stylecheck 포함)

unused

사용되지 않는 변수, 함수, 타입 검출

이 중 `errcheck`은 특히 중요합니다. Go에서 에러를 반환값으로 처리하는 관례상, 에러를 무시하는 코드는 런타임에 예상치 못한 동작을 일으킬 수 있습니다.

5. Makefile로 통합

위 도구들을 개별로 실행하는 것은 번거로우므로, Makefile에 통합하면 편리합니다.

Makefile

.PHONY: fmt lint test check ci

fmt:
	goimports -w .

lint:
	golangci-lint run ./...

test:
	go test ./...

check: fmt lint test

ci: lint test

check`와 `ci 두 가지 타겟을 나눈 이유가 있습니다. fmt 타겟은 파일을 직접 수정하므로 로컬에서 커밋 전에 실행하기에 편리하지만, CI 환경에서는 파일을 수정하면 안 됩니다. ci 타겟은 `golangci-lint`의 gofmt, goimports 린터가 포맷 위반을 검출만 하고 파일을 수정하지 않으므로, CI에서 안전하게 쓸 수 있습니다.

로컬: make check (포맷 자동 수정 + 린트 + 테스트)
CI: make ci (린트 + 테스트, 파일 수정 없음)

`go vet`을 별도 타겟으로 두지 않은 이유는, golangci-lint에 govet 린터가 포함되어 있어서 `make lint`에서 이미 실행되기 때문입니다.

코드 수정 후 커밋하기 전에 `make check`를 실행하는 습관을 들이면, CI에서 실패하는 상황을 줄일 수 있습니다.

6. 참고 자료

(이 글은 개인 라이센스로 구매한 Claude Code의 도움을 받아 작성되었습니다.)

Claude Code의 '/model opusplan’과 showClearContextOnPlanAccept 옵션

Thu, 26 Mar 2026 00:00:00 +0000

Table of Contents

/model opusplan
showClearContextOnPlanAccept 설정
- showClearContextOnPlanAccept은 기본값 변경 이력
Plan 실행 전 컨텍스트 클리어의 트레이드오프

/model opusplan

/model opusplan 을 선택하면 Opus로 plan을 세우고 Sonnet으로 실행하는 전략을 쓸 수 있습니다. 복잡한 작업에서 Opus의 추론 능력으로 계획을 세우고, 실행은 비용이 낮은 Sonnet으로 처리하는 방식입니다. 그런데 같은 세션 안에서 모델이 전환되면, 그때까지 쌓인 히스토리 전체가 캐시 미스로 재과금됩니다. 턴이 많이 진행된 후에 전환할수록 삼각수 효과로 누적된 토큰이 크기 때문에 비용 타격이 큽니다.

Tip	토큰 비용의 삼각수 효과와 Prompt Caching에 대한 자세한 설명은 Claude Code 토큰 비용과 프롬프트 캐싱을 참고하세요.

showClearContextOnPlanAccept 설정

세션 중간에 모델이 전환될 때 발생하는 부정적인 효과를 줄이는데 도움이 될 수도 있는 옵션이 있습니다. Claude Code 설정의 showClearContextOnPlanAccept 옵션이 true 이면, plan 승인 시 컨텍스트를 클리어할지 선택하는 옵션이 나타납니다. 'Yes, clear context(??% used) and by pass permissions' 를 선택하면, 컨텍스트를 클리어하면 planning 단계에서 쌓인 히스토리가 제거된 상태에서 실행이 시작되므로, 모델 전환으로 인한 캐시 무효화 비용을 피할 수 있습니다.

이 선택지가 나오도록 활성화하려면 ~/.claude/settings.json 에 다음과 같이 추가합니다.

{
  "preferences": {
    "showClearContextOnPlanAccept": true
  }
}

showClearContextOnPlanAccept은 기본값 변경 이력

Claude Code의 CHANGELOG에 따르면 showClearContextOnPlanAccept은 아래와 같은 이력을 가지고 있습니다.

v2.1.0(2026-01-07) : "Clear context" 옵션이 plan 승인 시 기본 선택으로 처음 도입
v2.1.2(2026-01-09) : Shift+Tab 단축키로 이 옵션을 건너뛸 수 있는 기능도 추가
v2.1.81(2026-03-20) : 기본값이 false 로 변경

따라서 2026년 3월 말 현 시점에서는 showClearContextOnPlanAccept 속성값을 직접 추가하지 않으면 "clear context" 옵션이 나타나지 않습니다.

Plan 실행 전 컨텍스트 클리어의 트레이드오프

이 옵션은 opusplan이 아닌 경우에도 유용할 때도 있습니다. 같은 모델로 plan mode를 사용하더라도, plan 단계에서 많은 턴이 쌓였다면 컨텍스트를 클리어하고 실행을 시작하면 이후 턴의 입력 토큰 크기를 줄일 수 있습니다.

그런데 컨텍스트 클리어에는 트레이드오프가 있습니다. Plan 파일 자체는 디스크(~/.claude/plans/)에 저장되어 보존되지만, planning 중에 읽은 파일 내용이나 탐색 결과는 모두 사라집니다. 따라서 실행 단계에서 필요한 파일을 plan을 가이드 삼아 다시 읽어야 하며, 이 과정에서 추가 토큰이 소비됩니다. planning 중의 논의 내용 중 plan 텍스트에 반영되지 않은 부분도 유실됩니다.

Plan 실행 전에 컨텍스트 클리어에 대해서 아래와 같은 부정적인 사용자 피드백이 있습니다.

#18523 Plan 승인 대화상자의 기본 옵션을 설정할 수 있게 해달라는 요청. 컨텍스트를 유지해야 복잡한 문제에서 더 나은 결정을 내릴 수 있고, auto-compact가 이미 컨텍스트를 관리하므로 강제 클리어가 불필요하다는 의견.
#18878 "Clear context" 기본 옵션을 비활성화하거나 순서를 변경할 수 있게 해달라는 요청. plan에 포함되지 않은 대화 맥락이 유실되는 문제를 지적하며, 파괴적인 동작이 기본값이 되어서는 안 된다는 의견.
#25734 "Clear context and implement"가 기본 옵션인 것은 파괴적이고 되돌릴 수 없다는 문제 제기. 터미널 스크롤백까지 지워져 복구가 불가능하며, 가장 파괴적인 옵션이 기본값이 되어서는 안 된다는 의견.

Claude Code 토큰 비용과 프롬프트 캐싱

Wed, 25 Mar 2026 00:00:00 +0000

Table of Contents

과금의 기본 단위: 토큰
- 모델별 가격표
Prompt Caching의 효과
직접 시뮬레이션해보기
참고 자료

Claude Code는 Anthropic의 API를 호출하는 CLI 도구입니다. Enterprise Plan에서는 API 사용량에 따라 과금되므로, 과금 구조를 이해하면 같은 작업을 더 적은 비용으로 할 수 있습니다.

과금의 기본 단위: 토큰

Claude API는 토큰 단위로 과금됩니다. 토큰 종류별로 가격이 다릅니다.

토큰 종류	설명
Input 토큰	모델에게 보내는 모든 텍스트 (시스템 프롬프트, 대화 히스토리, 도구 정의 등)
Output 토큰	모델이 생성한 응답 텍스트
Thinking 토큰	Extended thinking 모드에서 모델이 내부적으로 추론하는 데 쓰는 토큰. Output과 같은 가격으로 과금

토큰 종류

설명

Input 토큰

모델에게 보내는 모든 텍스트 (시스템 프롬프트, 대화 히스토리, 도구 정의 등)

Output 토큰

모델이 생성한 응답 텍스트

Thinking 토큰

Extended thinking 모드에서 모델이 내부적으로 추론하는 데 쓰는 토큰. Output과 같은 가격으로 과금

모델별 가격표

2026년 3월 기준으로 백만(1M) 토큰당 가격은 다음과 같습니다.

모델	Input	Output	Cache Write	Cache Read
Sonnet 4/4.6	$3	$15	$3.75	$0.30
Opus 4/4.6	$15	$75	$18.75	$1.50
Haiku 4.5	$0.80	$4	$1.00	$0.08

Opus는 Sonnet 대비 모든 항목이 5배입니다. Haiku는 Sonnet의 약 1/4 수준입니다.

Prompt Caching의 효과

Claude API는 stateless입니다. 매 턴마다 시스템 프롬프트, 도구 정의, 이전 대화 히스토리를 모두 다시 보내야 합니다. 여기서 '턴’은 사용자가 한 번 입력하고 Claude가 한 번 답변하는 단위가 아닙니다. Claude Code는 agentic하게 동작하기 때문에, 사용자가 한 번 입력하더라도 Claude가 파일 읽기, 편집, 명령 실행 등 도구를 호출할 때마다 API 호출이 발생합니다. 즉 한 번의 사용자 입력이 여러 턴에 해당할 수 있습니다.

턴이 진행될수록 입력 토큰이 누적되어 증가합니다. 공식으로 표현하면 다음과 같습니다.

턴 n의 입력 토큰:
  input(n) = B + n·T + (O + Th)·(n − 1)

  B  = 시스템 프롬프트 + 도구 정의 (매 턴 고정)
  T  = 턴당 새 사용자 입력 토큰
  O  = 턴당 출력 토큰 (히스토리 누적)
  Th = 턴당 thinking 토큰 (히스토리 누적)

N턴까지의 총 입력 토큰:
  총 입력 = N·B + T·N(N+1)/2 + (O+Th)·N(N−1)/2

N(N+1)/2 는 삼각수 공식입니다. 즉 총 입력 토큰은 턴 수에 대해 이차(quadratic)로 증가합니다. 10턴 대화의 뒷쪽 턴은 앞쪽 턴보다 훨씬 많은 입력 토큰을 소비하며, 대화가 길어질수록 이 격차는 더 벌어집니다.

Prompt Caching은 이 삼각수 효과를 완화하는 핵심 수단입니다. 이전 턴까지의 히스토리는 대부분 캐시에 남아있으므로, 캐시가 적중하면 반복 전송되는 입력 토큰의 비용이 정가의 10%로 줄어듭니다. 캐싱 없이는 뒷쪽 턴의 비용이 급격히 올라가지만, 캐싱이 잘 적중하면 누적 비용 곡선을 크게 낮출 수 있습니다. 캐시가 잘 적중하면 입력 토큰 비용을 90%까지 절약할 수 있습니다.

캐시 유형	설명	가격(Input 대비)
Cache Write	새로운 내용을 캐시에 저장	125%
Cache Read	캐시된 내용을 재사용	10%
Cache Miss	캐시 만료 후 다시 저장	125% (Cache Write와 동일)

캐시 유형

설명

가격(Input 대비)

Cache Write

새로운 내용을 캐시에 저장

125%

Cache Read

캐시된 내용을 재사용

10%

Cache Miss

캐시 만료 후 다시 저장

125% (Cache Write와 동일)

캐시 히트율을 높이기 위해서 다음을 의식해야 합니다.

5분 안에 다음 턴 진행: 입력을 보내고 나서 다음 턴까지 5분 이내로 유지하면 캐시가 살아있습니다.
세션 중간에 모델을 전환하지 않기: 모델을 바꾸면 캐시가 완전히 초기화됩니다. 하나의 대화 세션에서는 가능하면 하나의 모델을 유지합니다.
가급적 대화 중 CLAUDE.md를 수정하지 않기: CLAUDE.md는 시스템 프롬프트의 일부로 매 턴 전송됩니다. 대화 중에 이 파일을 수정하면 시스템 프롬프트의 prefix가 달라져 기존의 모든 캐시가 무효화됩니다. 특히 턴이 많이 진행된 세션에서는 삼각수 효과로 쌓인 대량의 히스토리 토큰이 전부 Cache Write(125%)로 재과금되어 비용 타격이 큽니다. 수정이 필요하다면 새 세션에서 시작하는 것이 비용 면에서 유리합니다.

직접 시뮬레이션해보기

위의 내용을 바탕으로 자신의 사용 패턴에 맞는 비용을 직접 계산해볼 수 있는 시뮬레이터를 Claude Code로 만들었습니다. 세션 내의 턴 수, 토큰량, 캐시 히트율 등을 조절하면서 모델별 비용 차이와 누적 비용 곡선을 확인할 수 있습니다.

Claude Code Token Cost Simulator로 이동 →

참고 자료

Ubuntu에서의 OEM 커널 설치

Fri, 20 Feb 2026 00:00:00 +0000

Table of Contents

Ubuntu 설치 시점에 따른 경험 차이
OEM 커널 vs HWE 커널
OEM 커널이 자동으로 선택되는 원리
OEM 커널을 수동으로 설치/제거
참고 자료

Ubuntu 공식 홈페이지에서 ISO를 받아 같은 방법으로 설치했음에도 설치 시점에 따라서 Lenovo ThinkPad에는 OEM 커널이, Dell XPS에는 HWE 커널이 설치되는 경우를 경험했습니다. 이 글에서는 두 커널의 차이와 자동 선택되는 원리 등을 정리합니다. 현상의 분석과 이 글의 작성에는 Claude Code의 도움을 받았습니다.

Ubuntu 설치 시점에 따른 경험 차이

저는 Lenovo와 Dell 2개의 모델에 Ubuntu를 설치해서 사용하고 있습니다. 2024년 11월에 Dell XPS 13 9350 모델에 Ubuntu 24.04를 설치했을 때는 웹캠이 제대로 동작하지 않았습니다. 2025년 8월경 Lenovo ThinkPad X1 Carbon Gen 13에 Ubuntu 24.04를 설치했을 때는 웹캠이 바로 잡혔습니다. 이 둘의 차이는 당시 Dell에서는 HWE 커널이 설치된 반면, Lenovo에서는 OEM 커널이 설치되었기 때문입니다.

2026년 2월 현재에는 2개의 모델이 모두 Ubuntu 공식 인증기기로 등록되어 있어서 OEM 커널이 설치될 것으로 예상됩니다.

OEM 커널 vs HWE 커널

Ubuntu 24.04 LTS에서 최신 하드웨어 지원을 위해 제공하는 커널은 크게 두 가지입니다.

항목 OEM 커널 HWE 커널

항목	OEM 커널	HWE 커널
패키지명 예	`linux-oem-24.04d`	`linux-generic-hwe-24.04`
커널 접미사 예	`6.17.0-1011-oem`	`6.17.0-14-generic`
대상	특정 OEM 파트너 기기 (Lenovo, Dell 등)	일반 사용자 전체
포함 패치	해당 기기 전용 드라이버·패치 (카메라, 지문인식, 열 관리 등)	범용 최신 하드웨어 지원
관리 주체	Canonical OEM 팀 + OEM 파트너	Canonical / Ubuntu 커뮤니티
업데이트 경로	OEM 파트너 저장소 (`oem.archive.ubuntu.com`)	기본 Ubuntu 저장소

패키지명 예

linux-oem-24.04d

linux-generic-hwe-24.04

커널 접미사 예

6.17.0-1011-oem

6.17.0-14-generic

대상

특정 OEM 파트너 기기 (Lenovo, Dell 등)

일반 사용자 전체

포함 패치

해당 기기 전용 드라이버·패치 (카메라, 지문인식, 열 관리 등)

범용 최신 하드웨어 지원

관리 주체

Canonical OEM 팀 + OEM 파트너

Canonical / Ubuntu 커뮤니티

업데이트 경로

OEM 파트너 저장소 (oem.archive.ubuntu.com)

기본 Ubuntu 저장소

HWE(Hardware Enablement) 커널은 LTS 버전에서 새 하드웨어를 지원하기 위해 최신 업스트림 커널을 백포팅한 것입니다. OEM 커널은 여기에 더해 특정 기기에서만 필요한 패치가 추가로 적용됩니다. 즉, OEM 커널은 하드웨어 제조사와 Canonical이 협력하여, 해당 기기에서 "설치 후 바로 동작(out-of-the-box)"하는 경험을 제공하기 위한 것입니다.

Intel Meteor Lake / Lunar Lake CPU를 탑재한 기기들은 HWE 커널에서 완전히 지원되지 않은 하드웨어가 있었습니다. 대표적인 예가 내장 카메라(MIPI/IPU7)와 일부 지문인식 센서입니다.

OEM 커널이 자동으로 선택되는 원리

Ubuntu 인스톨러(Subiquity)는 설치 중에 ubuntu-drivers 도구를 호출하여 현재 하드웨어를 감지합니다. 이때 DMI(System Management BIOS) 정보를 읽어 Canonical OEM 파트너 목록과 대조합니다.

예를 들어 Lenovo ThinkPad X1 Carbon Gen 13의 경우, 아래와 같은 메타패키지가 매칭됩니다.

Package: oem-sutton-dacia-meta
Modaliases: meta(dmi:*bvnLENOVO:bvrN4B*:pvrThinkPad*)
Depends: linux-oem-24.04c, oem-sutton-meta
Ubuntu-Oem-Kernel-Flavour: oem
Description: hardware support for Lenovo ThinkPad X1 2-in-1 G10, X1 Carbon G13

Modaliases 필드의 패턴(dmi:*bvnLENOVO:bvrN4B*:pvrThinkPad*)이 현재 기기의 DMI 정보와 일치하면, 해당 메타패키지와 함께 OEM 커널이 자동으로 설치됩니다.

설치 흐름을 정리하면 다음과 같습니다.

Ubuntu 설치 중
└─ ubuntu-drivers 가 DMI 정보 확인
   └─ OEM 메타패키지 패턴 매칭
      └─ oem-sutton-dacia-meta 설치
         └─ linux-oem-24.04d 의존성으로 OEM 커널 설치
            └─ → 부팅 커널: 6.17.0-1011-oem

어떤 커널이 설치될지는 하드웨어가 Canonical OEM 파트너 목록에 등록되어 있느냐에 달려 있습니다.

다음과 같이 Intel Ultra 7 258V CPU를 쓰는 기기라도 차이가 생길 수 있습니다.

기기 OEM 메타패키지 설치되는 커널

기기	OEM 메타패키지	설치되는 커널
Lenovo ThinkPad X1 Carbon G13	`oem-sutton-dacia-meta`	`linux-oem-24.04d` (OEM 커널)
Dell XPS 13 9350	`oem-somerville-tyrogue-meta`	`linux-oem-24.04d` (OEM 커널)
OEM 파트너 목록에 없는 기기	없음	`linux-generic-hwe-24.04` (HWE 커널)

Lenovo ThinkPad X1 Carbon G13

oem-sutton-dacia-meta

linux-oem-24.04d (OEM 커널)

Dell XPS 13 9350

oem-somerville-tyrogue-meta

linux-oem-24.04d (OEM 커널)

OEM 파트너 목록에 없는 기기

없음

linux-generic-hwe-24.04 (HWE 커널)

그래서 설치 시기와 모델에 따라 어느 커널이 설치 될지가 달랐던 것입니다. 우분투 공식 인증기기라면 OEM 커널이 설치시에 바로 감지되어 설치될 가능성이 높습니다.

아래 명령을 참고로 알아두시면 기기에 대한 정보를 파악하는데 도움이 됩니다.

ubuntu-drivers list-oem : 기기에 감지된 OEM 메타패키지
sudo dmidecode -s system-product-name : 기기의 정확한 모델명

OEM 커널을 수동으로 설치/제거

현재 어떤 커널이 설치되어 있는지는 다음 명령으로 확인할 수 있습니다.

설치된 커널과 OEM 메타패키지 확인

# 현재 부팅된 커널
uname -r

# 설치된 커널 패키지 목록
dpkg -l | grep linux-image | grep '^ii'

# ubuntu-drivers가 감지하는 OEM 메타패키지 확인
ubuntu-drivers list-oem

우분투 초기 설치 시점에 HWE 커널이 자동 선택되었지만, OEM 커널로 전환을 하고 싶다면 아래와 같이 수동으로 설치할 수 있습니다.

OEM 커널 수동 설치

# 설치 가능한 OEM 메타패키지 목록 검색
apt search linux-oem-24.04

# OEM 커널 수동 설치 (24.04 기준)
sudo apt install linux-oem-24.04d

앞으로 업데이트에도 HWE 커널이 설치되지 않도록 하려면, HWE 커널의 메타 패키지를 제거하면 됩니다.

HWE 커널 제거

sudo apt remove linux-headers-generic-hwe-24.04

또는 HWE 커널의 메타 패키지를 보류(hold) 상태로 설정할 수 있습니다.

HWE 커널 보류 설정

sudo apt-mark hold linux-headers-generic-hwe-24.04

반대로 OEM 커널 없이 HWE 커널만 사용하고 싶다면, OEM 메타패키지를 제거하면 됩니다. 단, 해당 하드웨어에서 필요한 드라이버가 빠질 수 있으므로 주의가 필요합니다.

참고 자료

Ubuntu 24.04 설치

Thu, 9 Oct 2025 00:00:00 +0000

새 컴퓨터를 받아서 설치한 프로그램들을 정리해봅니다.

Ubuntu는 영문판으로 설치
- Desktop, Download 같은 디렉토리가 영문으로 나오는 것이 편리해서

한글 설정

sudo apt install ibus-hangul

Settings 에서

Regision & Language 에서 Manage Installed Lanauges 에 'Korean' 추가
Keyboard > Input Sources 에 Korean(Hangul) 추가하고 "…" 눌러서 Preference 선택
- Hangul toggle key 에 Shift + Space 지정

하드웨어 설정

키보드 설정

일부 키보드의 경우 F1~F12가 잘 인식되지 않은 경우도 있음. 해당 장비가 애플 키보드 타입으로 인식되고 자동 모드가 Fn가 기본적으로 눌러져있는 것으로 인식되기 때문. hid_apple 모듈의 fnmode 변수 설정으로 이 문제를 해결할 수 있음.

현재 모드 확인 : lsmod | grep hid_ (디폴트는 자동 모드인 3)
보통 2로 모드 설정을 하면 잘 되고, 그래도 안되면 disable인 3으로
일시적으로 설정 값이 변경하여 테스트 : echo 2 | sudo tee /sys/module/hid_apple/parameters/fnmode

키보드 펑션키 모드 변경이 재부팅 후에도 적용되도록

echo "options hid_apple fnmode=2" | sudo tee /etc/modprobe.d/hid_apple.conf
sudo update-initramfs -u

참고자료

웹 캠 설정

Intel Ultra 7 258v CPU를 쓰는 Dell XPS 13 plus 9350에서는 웹캠을 위한 드라이버 설치를 따로 해줘야했음. 같은 CPU를 쓰는 Lenovo Thinkpad X1 Carbon G13는 기본 설치만으로 잘 되었음.

Dell XPS 13 plus 9350에서 웹캠이 안 잡힐 때 참고한 자료

CLI 도구

Terminator

여러 창을 띄우기에 편한 터미널 프로그램

sudo apt install terminator

curl

sudo apt install curl

ifconfig

sudo apt install net-tools

ssh 설정

sudo vi /etc/ssh/ssh_config 하여 아래를 마지막에 추가

HostkeyAlgorithms ssh-dss,ssh-rsa
KexAlgorithms +diffie-hellman-group1-sha1

https://kr.analysisman.com/2018/08/linux-ssh.html 참조

git / gitk

sudo apt-get install git gitk

GitHub SSH 설정

https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

oh-myzsh

sudo apt install zsh
curl -L http://install.ohmyz.sh | sh

( https://github.com/robbyrussell/oh-my-zsh 참고 )

terminator의 Preference > Profile > Command 에서

Run a custom command instead of my shell 체크
Custom commands : zsh

scm_breeze

zsh에서 실행할 때의 기준

git clone https://github.com/scmbreeze/scm_breeze.git ~/.scm_breeze
~/.scm_breeze/install.sh
source "${ZDOTDIR:-$HOME}/.zshrc
bash
source ~/.bashrc
exit

( https://github.com/ndbroadbent/scm_breeze 참고 )

개발 환경

여러 JDK를 설치하고 관리하는 방법은 SDKMAN + direnv를 추천 ( https://blog.benelog.net/installing-jdk.html 참조)

SDKMAN

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk install java

https://sdkman.io/install 참조

direnv

sudo apt install direnv 설치
~/.bashrc 와 ~/.zshrc 에 eval "$(direnv hook bash)" 추가

https://direnv.net/docs/hook.html 참조

IntelliJ

sudo apt install fuse

https://www.jetbrains.com/ko-kr/toolbox-app/ 에서 Toolbox로 설치

Terminal에서 zsh 지정
- Settings > Tools > Application Settings > Shell Path : /bin/zsh
Plugin 설치
- https://plugins.jetbrains.com/plugin/7391-asciidoc
- https://plugins.jetbrains.com/plugin/1065-checkstyle-idea

Node.js

nvm 설치

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

~/.bash_profile, ~/.zshrc, ~/.profile, ~/.bashrc 등에 추가

export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

https://github.com/nvm-sh/nvm#installing-and-updating 참고

정보 관리 프로그램

크롬

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install ./google-chrome-stable_current_amd64.deb

Obsidian

snap으로 설치하면 한글 문제가 있음. Appimage로 설치

Pinta

snap install pinta

VidCutter

snap install vidcutter

https://github.com/ozmartian/vidcutter 참조

ShotCut

snap install shotcut --classic

https://shotcut.org/ 참조

기타 참고

이전 버전에서 참고한 자료

무선 인터넷 안 잡힐 때

NGINX 설치 후 자동으로 시작 안하게

sudo update-rc.d -f nginx disable

Secure Boot

https://wiki.ubuntu.com/UEFI/SecureBoot 참조

카멜 케이스를 쓸 때 약어 표기

Sat, 2 Dec 2023 00:00:00 +0000

(이 글에서는 위키페디아의 정의에 따라 '카멜 케이스’를 UpperCamelCase와 lowerCamelCase를 포괄하는 개념으로 사용했습니다.)

자바나 코틀린에서 약어(acronym)가 클래스명이나 메서드명의 일부로 들어갈 때 최대 두 글자까지만 대문자로 표기하는 방식을 권장합니다. 비슷하게 카멜 케이스를 쓰는 자바스크립트와 같은 다른 언어에서도 이 관례가 무난하다고 생각합니다. 기존의 바꿀 수 없는 코드나 외부 라이브러리 사용 등으로 어쩔 수 없는 경우에는 전부 대문자로 쓰더라도 이를 최소화하는 노력을 하고 프로젝트 내부 문서로도 예외의 경우로 명시하면 좋습니다.

위의 관례는 약어 전체를 대문자로 표기하는 관례에 비해서 다음과 같은 장점이 있습니다.

연속된 약어가 조합될 경우 단어 사이의 구문이 더 잘 인지됩니다.
- 예: XMLRPCAPIURL vs XmlRpcApiUrl
일관성을 유지하기가 더 쉽습니다.
- 전부 대문자로 표기해야할 단어들을 따로 기억할 필요가 없습니다.
- 사람마다 다르게 판단할 여지가 적은 단순한 규칙입니다.
- 영향력이 큰 책이나 가이드에서 지지받고 있는 규칙입니다. 새로 합류한 구성원도 따를 가능성이 높습니다.

자바와 코틀린으로 나누어서 이 관례에 대해 참고할 수 있는 자료를 정리합니다.

자바의 관례

JDK 내부에서는 이 관례가 통일되어 있지 않습니다. 다음과 같이 약어를 쓸 때 전부 대문자와 첫 글자만 대문자 표기가 혼재하고 있습니다.

java.net.HttpURLConnection (한 클래스 이름에서도 Http는 첫글자만 대문자, URL은 다 대문자로 표기했습니다.)
javax.xml.bind.annotation.XmlElement

Effective Java의 3판에서는 약어라도 첫글자만 대문자로 하는 방식에 대한 지지도를 더 높인 느낌입니다. 2판의 Upppercase may be more common 문구가 `Some programmers still use uppercase`로 바뀌었습니다.

3판에서의 해당 단락의 전체 내용은 아래와 같습니다.

Item 68: Adhere to generally accepted naming conventions (원서 289~290 페이지)

There is some disagreements as to whether acronyms should be uppercase or have only their first letter capitalized. While some programmers stil use uppercase, a strong argument can be made in favor of capitalizing only the first letter: even if multiple acronyms occur back-to-back, you can still tell where one word starts and the next word ends. Which class name would you rather see, HTTPURL or HttpUrl?

아이템 68: 일반적으로 통용되는 명명 규칙을 따르라 (번역서 382 페이지)

약자의 경우 첫 글자만 대문자로 할지 전체를 대문자로 할지는 살짝 논란이 있다. 전체를 대문자로 쓰는 프로그래머도 있지만, 그래도 첫 글자만 대문자로 하는 쪽이 훨씬 많다. HttpUrl처럼 여러 약자가 혼합된 경우라도 각 약자의 시작과 끝을 명확히 알 수 있기 때문이다. (HTTPURL과 비교해보자)

자바 초창기에 비해 점점 첫 글자만 대문자로 쓰는 점유율이 높아졌다고 해석될만도 합니다.

스프링 프레임워크에서도 초창기에는 두 방식이 혼재하다가 점점 첫글자만 대문자로 쓰는 관례로 바뀐 것으로 보입니다. URL 단어 표기는 다음과 같은 예시가 있습니다.

URLEditor : 2002년 작성
UrlResource : 2003년 작성
UrlTag : 2009년 작성 추정

DAO, XML, SQL 등은 모두 처음부터 첫글자만 대문자로 표기된 것으로 보입니다.

JdbcDaoSupport : 2003년 처음 작성
SqlXmlValue : 2008년 작성 추정
XmlMappingException : 2009년 작성 추정

코틀린의 관례

코틀린 언어 사이트의 코딩 컨벤션 가이드에서도 약어의 표기 방식에 언급하고 있습니다. 약어가 두 글자라면 다 대문자로 쓰고, 길어지면 한 글자만 대문자로 쓰라고 권장하고 있습니다.

https://kotlinlang.org/docs/coding-conventions.html#choose-good-names

Choose Good names

When using an acronym as part of a declaration name, capitalize it if it consists of two letters (IOStream); capitalize only the first letter if it is longer (XmlFormatter, HttpInputStream).

좋은 이름을 선택해라

선언된 이름의 일부에 약어가 들어 갈 때는 두 개의 문자로 구성된 약어는 대문자로 쓰고(IOStream) 긴 문자는 첫 글자만 대소문자로 쓰세요. (XmlFormatter, HttpInputStream).

언어 공식 사이트의 가이드에 있는 내용이므로 보편적으로 인지되고 유지될 가능성이 높은 관례입니다.

필독 개발자 온보딩 가이드

Thu, 23 Nov 2023 00:00:00 +0000

Table of Contents

감상
의견 메모
추천자료

이미지 출처 : https://www.yes24.com/Product/Goods/119108069
각 장의 참고문헌 목록을 옮겨 정리하는 것에 대해서는 책만 출판사(https://www.onlybook.co.kr)에 연락해서 게재 허락을 구했습니다.

감상

(내돈내산 후기입니다)

많지 않은 분량으로 실무 개발자의 폭넓은 업무를 다루면서 결코 얄팍하지 않은 지식을 전달하는 책입니다. 협업, 설계, 구현, 테스트, 문서화, 긴급 대응, 경력 관리 등 다양한 분야에 대한 알찬 조언을 책 한권에 눌러 담았고 더 많은 분량을 학습하고 싶은 독자를 위한 참고자료들도 매 장마다 소개하고 있습니다.

이 책은 신입 개발자를 대상으로 한 책으로 홍보되고 있지만 경력이 많은 개발자가 읽을만한 가치도 충분합니다. 저도 과거의 경험을 돌아보면서 생각을 정리할 수 있었습니다. 스스로 절실하게 얻은 교훈이 이 책에도 적혀 있는 보면 반가웠고 깊은 공감이 되는 문장들도 많이 만날수 있었습니다.

예를 들면, Dark launching이나 Feature toggle 같이 제 경험에서 유용했던 기법이 개발 실무의 액기스를 전하는 이 책에서도 소개되니 반갑고 안심이 되었습니다. 긴급 대응을 위한 당번(on call) 제도와 같이 더 개선을 해야 할 요소도 독서 후에 더 크게 느껴지기도 했습니다. 전에는 썼지만 근래에는 활용하지 않았던 Liquibase를 통한 DB 스키마 관리도 다음 프로젝트에서는 다시 시도해봐야겠다는 생각도 듭니다.

유용하다고 느낀 지침과 조언을 새겨두고 실천하기 위해 여러 번 읽어야겠다는 생각을 하면서 마지막 장을 덮었습니다.

의견 메모

책을 보다가 의견을 메모한 부분을 옮겨봅니다.

p102

예외는 일찍 던지고 최대한 나중에 처리하자.

최대한 나중에 처리하는 것보다는 적절한 추상화 레이어에서 처리하자는 것이 좋다고 생각한다. 예를 들면 사용자의 ID로 조회했을 때 DB 조회가 실패했을 때 생기는 `EmptyResultDataAccessException`을 어플리케이션 콜스택의 마지막에서 처리하기보다는 비지니스 로직을 다루는 레이어에서 `UserNotFoundException`과 같이 비지니스 맥락의 의미가 부여된 예외로 바꾸는 것이 좋을 때도 있다.

p204

기능 브랜치 기반 개발은 트렁크의 코드가 사용자에게 릴르스하기엔 너무 불안정해서 트렁크를 안정화시키는 동안 개발자가 기능 개발을 수행할 수 없는 경우에 사용하는 방법이다. 고객이 각자 다른 버전의 소프트웨어를 사용하는 경우에 보편적으로 기능 브랜치 기반 개발 전략을 채택한다. 서비스 지향 시스템(service-oriented systems)은 일반적으로 트렁크 기반 개발 전략을 채택한다.

가장 보편적인 기능 브랜치 전략은 2010년 빈센트 드리센이 소개한 깃플로(Gitflow)라고 부르는 전략이다.

Git-flow는 필요에 따라 팀 브랜치 정책의 종착역은 될수 있지만 시작점으로 권장하고 싶지는 않다. 자세한 의견은 Git-Flow에 대해서 다시 생각해보기라는 글로 따로 정리했다.

p212

버전 제어 시스템을 릴리스 리포지토리처럼 사용할 수는 있지만 원래 용도라고 보기 어렵다. 버전 제어 시스템에서는 검색이나 배포 관련 기능을 별로 제공하지 않는다. 대규모 배포를 위해 만들어진 시스템이 아니므로 그런 상황에서는 문제를 일으킬 수도 있다. 버전 제어 시스템 머신과 동일한 머신이 개발자 체아크웃, 도구로부터의 요청, 배포 요청을 모두 담당하면 프로덕션 배포에 영향을 미칠 수 있다.

Node.js나 Go언어의 오픈소스 생태계에서는 GitHub.com을 릴리스 리포지토리처럼 쓰는 관행이 굳어졌다. 하지만 사내에서라면 이를 분리하는 것이 좋다는 저자의 의견에 동의한다. 버전 관리 시스템은 GitHub Enterprise를 쓰더라도 릴리스 저장소는 Nexus나 Artifactory를 쓰는 식이다. 분리하면 두 시스템을 각각 업그레이드하기에도 유리하다.

p213

릴리스는 최대한 자주 수행하자. 릴리스 주기가 늘어지 거짓된 안정감을 심어줄 수 있다. 즉 릴리스 사이의 주지가 길면 변경사항을 테스트할 충분한 시간이 있는 것처럼 느껴지기 때문이다. 실제로 릴리스 주기를 짧게 가져가면 더 안정적인 소프트웨어를 구현할 수 있어 버그가 발견됐을 때 더 쉽게 처리할 수 있다. 매 주기마다 릴리스되는 변경사항의 수가 더 적으므로 각 릴리스의 위험도도 낮아진다.

공감한다. 1~2주에 한번 릴리스하는 조직과 한달에 한번 릴리스하는 조직을 비교했을 때 후자의 릴리스가 훨씬 힘겹고 위험한 일이 되는 현상을 몇 번 목격했다. 테스트와 모니터링의 자동화 수준이 높아져야 릴리스의 비용이 적어져서 더 자주 릴리스하게 될 수 있기도하다.

p212

배포를 원자적으로 만드는 가장 쉬운 방법은 기존에 설치된 소프트웨어를 덮어쓰는 것이 아니라 다른 경로에 소프트웨어를 설치하는 것이다. 일단 패키지가 설치된 다음에는 단축 아이콘이나 심볼릭 링크를 이용해 교체하면 된다.

(의견) 많이 쓰던 기법이다. 사내 배포 시스템에서 디폴트로 제공이 되기도한다. 이동욱 님이 발표한 우아한스프링배치 발표에서도 이 기법을 응용한 무중단 배포를 소개하고 있다. 배포된 최신 버전 파일로 심볼릭 링크를 교체하고 (ln -s -f v2.jar app.jar) readlink 명령어로 그 파일을 실행하는(java -jar ${readlink ./app.jar}) 이용하는 방식이다.

p219

한 번에 모조리 새 코드로 전환하는 일은 위험하다. 테스트를 아무리 많이 해도 버그 발생 가능성을 없앨 수는 없으며 한 번에 모든 사용자에게 코드를 롤아웃하면 모두가 동시에 문제를 겪을 수 있다. 따라서 변경 사항을 점진적으로 롤아웃하고 시스템 상태 지표를 모니터링 하는 편이 좋다.

규모가 있는 시스템을 변경하는 개발자라면 절실하게 읽어야할 문장이다.

p311

데이터베이스 스키마 마이그레이션 도구인 Liquibase 등을 소개함.

데이터베이스와 애플리케이션 수명주기를 결합해서는 안 된다. 애플리케이션 배포 과정에서 스키마를 마이그레이션하는 것은 위험하다.

의도한 바은 아니지만 JPA의 스키마 관리 기능이 운영환경에서 실행되어서 발생하는 장애를 종종 전해듣는다. 스프링 부트의 spring.jpa.hibernate.ddl-auto 같은 옵션도 Local PC에 DB가 따로 설치되어 있거나 Embeded DB를 쓸때만 활성화해야 한다고 생각한다. 공용 개발 DB에서부터는 Liquibase와 같은 스키마 관리 도구를 활용하는 것이 좋다. 공용 개발 DB라도 여러 개가 있는 것이 다양한 테스트를 하는데 유리하고, 개발 DB가 여러개가 되면 스키마 관리 도구의 필요성이 높아진다. Oracle 등 개발자가 여러 인스턴스를 설치하는데 제약이 있는 DB를 오랫동안 써 온 개발자는 이런 도구의 필요성을 느끼거나 적용할 수 있는 기회를 얻기가 어려울 수도 있다.

운영DB는 DBA가 따로 SQL파일을 실행해서 스키마를 반영하는 회사라도 Liquibase는 충분히 사용 가능하다. Liquibase는 오프라인 지원 기능이 있어서 실제 DB에 스키마 변경을 실행하지 않고 DDL을 파일로 뽑아낼수도 있다. 예를 들어 스키마 버전 1.0.0-RC1과 1.0.0-RC2 버전 사이에 변경된 컬럼을 반영하는 DDL을 담은 .sql파일을 뽑을 때는 아래 명령어로 가능하다.

rm target/release.csv
mvn liquibase:updateSQL -Dliquibase.url='offline:mysql?changeLogFile=target/release.csv' -Dliquibase.toTag=1.0.0-RC1
mvn liquibase:updateSQL -Dliquibase.url='offline:mysql?changeLogFile=target/release.csv' -Dliquibase.toTag=1.0.0-RC2

Git-Flow에 대해서 다시 생각해보기

Mon, 23 Oct 2023 00:00:00 +0000

Git의 브랜치 전략으로 Git-flow가 가장 유명하고 자주 언급됩니다. 그런데 이 전략은 복잡도와 실행하는 난이도가 높은 편입니다. Git-flow를 쓰고 있다고 주장하는 조직에서도 창시자 Vincent가 제안한 원래의 프로세스를 그대로 쓰는 경우는 드물다고 느껴집니다.

Git-flow가 특히 인터넷 서비스 개발에서 보편적으로 권장할만한 전략일지는 저는 의문입니다. 브랜치 전략은 복잡하게 시작해서 단순하게 줄여나가기 보다는 단순하게 시작해서 필요에 따라 복잡도를 늘여가는 편이 시행착오가 적다고 생각합니다. 여러 버전을 동시에 운영하고 백포트 패치를 해야하는 솔루션 개발에서는 Git-flow가 적합한 조직이 있을법도 합니다. 즉, Git-flow는 필요에 따라 종착역은 될수 있지만 시작점으로 권장하고 싶은 정책은 아닙니다.

Git-flow가 그 이름 때문에 필요 이상으로 권장되고 있다고 저는 생각합니다. Git이 지금보다 대중화되지 않았을 때 제안된 모델이고 그 당시 다른 유명한 모델이 없겠기에 Git-flow라고 불리지 않았을까 추정하기도합니다. 만약 창시자의 이름을 딴 Vincent-flow정도의 이름이였다면 많은 사람들이 따르려고 생각하지 않았을지도 모릅니다. Git-flow가 유용해보인다면 그 이름이 Vincent-flow라도 마찬가지일지를 한번 돌아봐도 이름에 과도하게 끌린건 아닌지 돌아보는데 도움이 될듯합니다.

뱅크 샐러드에서는 Git-flow보다 더 단순한 전략으로 리뷰-배포 프로세스를 개선했다는 사례도 있습니다.

https://blog.banksalad.com/tech/become-an-organization-that-deploys-1000-times-a-day/

먼저 Git-flow를 활용한다면 하나의 기능을 배포하는 데 있어서 무려 5번의 branch switching이 필요하고, 6번의 Pull Request와 이에 따른 6번의 Code Review가 필요했습니다. 이 말은 다르게 말하면 코드 오너가 6번이나 코드를 리뷰하고 승인을 해줘야 한다는 것이죠. 이렇게 복잡한 프로세스는 자연스럽게 배포를 귀찮은 존재로 만듭니다. 이로 인해 간단한 수정 사항의 경우 develop branch에 merge 한 뒤 배포하지 않는 일이 종종 발생하기 시작했습니다. 이런 배포되지 않은 변경 사항이 쌓이면서 나중에 필요할 때 한 번에 너무 많은 변경사항을 포함한, 부담스러운 배포를 진행해야만 했습니다. 배포 시 변경 사항이 많을수록 장애가 발생할 수 있는 확률은 당연히 증가하기 때문에 개발자에게는 배포는 무서운 존재가 되었습니다.

저는 GitLab-flow정도면 많은 사람이 협업하는 인터넷 서비스를 개발하는 브랜치 전략으로도 괜찮다고 생각합니다. 이를 참고해서 필요한 나름의 정책을 추가로 정의할 수도 있겠습니다.

Git-flow의 창시자 Vincent Driessen는 그의 아티클에 10년간의 회고를 덧붙였습니다. 거기서 지속적인 배포를 하는 프로젝트에서는 GitHub-flow와 같은 더 단순한 모델을 권장한다는 언급을 했습니다.

https://nvie.com/posts/a-successful-git-branching-model/

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

귀사의 팀이 지속적으로 소프트웨어를 제공하고 있다면, 귀사의 팀에 git-flow를 도입하는 대신 훨씬 간단한 워크플로우(GitHub flow와 같은)를 채택하는 것을 제안합니다.

(번역은 파파고에게 맡겼습니다.)

많은 조직에서는 특히 운영 환경에서는 지속적인 배포(continuous delivery)와는 먼 프로세스를 택하고 있을 수도 있습니다. 그럼에도 개발과 테스트 환경에서라도 자주 활발히 통합되어 테스트되고 리뷰되는걸 추구한다면 Vincent의 회고를 더 깊이 새겨둘만합니다.

아래 문장으로 Vincent의 10년만의 회고는 끝이 납니다.

To conclude, always remember that panaceas don’t exist. Consider your own context. Don’t be hating. Decide for yourself.

결론적으로, 만병통치약은 존재하지 않는다는 것을 항상 기억하세요. 자신만의 맥락을 고려하세요. 미워하지 말고, 스스로 결정하세요.

Jackson으로 파싱한 JSON 속성값을 생성자로 전달하기

Sun, 15 Mar 2020 00:00:00 +0000

Table of Contents

1. Jackson에서 (no Creators, like default construct, exist) 에러 메시지
2. 생성자로 JSON 속성값을 전달하는 방법들
3. 예제 소스 저장소

변경이력
- 2023.06.25 : Spring Boot Gradle plugin에서 -parameter 옵션을 넣어주는 소스로의 링크 변경
- 2022.05.07 : 예제 프로젝트를 JDK17로 변경

1. Jackson에서 `(no Creators, like default construct, exist)` 에러 메시지

파싱하고자하는 JSON

{
    "accessDateTime": "2019-10-10T11:14:16Z",
    "ip": "175.242.91.54",
    "username": "benelog"
}

위와 같은 JSON을 파생해서 아래와 같이 setter가 없는 객체에 집어 넣고 싶은 경우가 있습니다.

파싱한 결과를 넣을 클래스

public class AccessLog {
    private final Instant accessDateTime;
    private final String ip;
    private final String username;

    public AccessLog(Instant accessDateTime, String ip, String username) {
        this.accessDateTime = accessDateTime;
        this.ip = ip;
        this.username = username;
    }

    public Instant getAccessDateTime() {
        return accessDateTime;
    }

    public String getIp() {
        return ip;
    }

    public String getUsername() {
        return username;
    }
}

Jackson 라이브러리로 JSON을 파싱하는 테스트 코드를 아래처럼 작성했습니다.

테스트 코드

class ConstructorPropertiesTest {
    @Test
    void parse() throws JsonProcessingException {
        var json = """
            {
            "accessDateTime": "2019-10-10T11:14:16Z",
            "ip": "175.242.91.54",
            "username": "benelog"
            }
            """;

        var objectMapper = new ObjectMapper()
            .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .registerModule(new JavaTimeModule());

        AccessLog accessLog = objectMapper.readValue(json, AccessLog.class);

        then(accessLog.getAccessDateTime()).isEqualTo("2019-10-10T11:14:16Z");
        then(accessLog.getIp()).isEqualTo("175.242.91.54");
        then(accessLog.getUsername()).isEqualTo("benelog");;
    }
}

위의 코드를 실행하면 다음의 Exception이 떨어집니다. (no Creators, like default construct, exist) 이 핵심적인 메시지입니다.

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `net.benelog.jackson.ConstructorPropertiesTest$AccessLog` (no Creators, like default construct, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
 at [Source: (String)"{
"accessDateTime": "2019-10-10T11:14:16Z",
"ip": "175.242.91.54",
"username": "benelog"
}
"; line: 2, column: 1]

	at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:67)
	at com.fasterxml.jackson.databind.DeserializationContext.reportBadDefinition(DeserializationContext.java:1592)
	at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1058)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1297)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:326)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:159)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4218)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3214)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3182)

JSON을 파싱한 결과를 전달할 적절한 생성자를 찾지 못했을 때 발생하는 에러입니다. 이 문제를 해결하는 방법을 정리합니다.

2. 생성자로 JSON 속성값을 전달하는 방법들

2.1. `@JsonCreator`

Jackson에서 제공하는 @JsonCreator, @JsonProperty 를 값을 전달할 생성자와 메서드 파라미터에 붙입니다.

AccessLog의 생성자에 @JsonCreator 선언

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;

public class AccessLog {

    // 멤버 변수 선언 생략

    @JsonCreator
    public AccessLog(
        @JsonProperty("accessDateTime") Instant accessDateTime,
        @JsonProperty("ip") String ip,
        @JsonProperty("username") String username) {

        this.accessDateTime = accessDateTime;
        this.ip = ip;
        this.username = username;
    }

    // getter 생략
}

장점
- JSON의 속성명과 객체의 멤버변수명이 다를 때도 자연스럽게 활용할 수 있습니다.
- 생성자가 여러 개일 때 Jackson에서 사용할 생성자를 명시적으로 지정할 수 있습니다.
단점
- Jackson에 의존적인 방법입니다.
  - Jar파일로 배포하는 클래스 안에서 이 방법을 사용하려면 Jackson에 대한 의존성이 추가됩니다.
  - JSON 파싱 라이브러리를 교체한다면 전체 클래스를 수정해야 합니다.

2.2. `@ConstructorProperties`

JDK 1.6부터 제공되었던 @java.beans.ConstructorProperties 은 생성자의 파라미터 이름을 지정하는 표준적인 방법입니다. 이를 활용하면 생성자의 파라미터 이름을 Reflection API를 통해서 알 수 있습니다. Jackson은 2.7.0버전부터 @ConstructorProperties 를 인지합니다. ( https://github.com/fasterxml/jackson-databind/issues/905 참조)

생성자에 @ConstructorProperties 으로 파라미터의 이름을 지정하면, Jackson에서는 동일한 이름의 JSON 속성값을 생성자로 넘겨줍니다.

AccessLog의 생성자에 `@ConstructorProperties`로 속성명 지정

import java.beans.ConstructorProperties;

public class AccessLog {

    // 멤버 변수 선언 생략

    @ConstructorProperties({"accessDateTime", "ip", "username"})
    public AccessLog(Instant accessDateTime, String ip, String username) {
        this.accessDateTime = accessDateTime;
        this.ip = ip;
        this.username = username;
    }

    // getter 생략
}

Lombok을 활용한다면 이 과정을 더 편하게 할 수 있습니다. lombok.config 를 다음과 같은 선언을 하면 Lombok에서 만드는 생성자에서 @ConstructorProperties 를 자동으로 넣어줍니다.

lombok.config 설정

lombok.anyConstructor.addConstructorProperties=true

@Builder, @AllArgsConstructor 와 같은 애노테이션을 클래스에 붙이면 Lombok에서는 자동으로 생성자를 만들어줍니다. 이를 통해 JSON 파싱한 값을 넣을 클래스를 더 단순하게 만들 수 있습니다.

Lombok을 이용한 AccessLog 클래스 선언

@Builder
@Getter
@ToString
public class AccessLog {
    private final Instant accessDateTime;
    private final String ip;
    private final String username;
}

참고로 Lombok v1.16.20 전까지는 디폴트로 @ConstructorProperties 을 넣어줬었다고 합니다. 이 이후 버전부터는 디폴트가 아니므로 lombok.config 에 명시적인 선언이 필요합니다. ( https://multifrontgarden.tistory.com/222 참조 )

@ConstructorProperties 를 직접 쓸 때의 장단점은 다음과 같다고 생각합니다.

장점
- @JsonCreator + @JsonProperties 보다는 코딩량이 조금 적습니다.
- Jackson에 의존적이지 않습니다.
  - JSON을 파싱한 값이 들어가는 클래스를 jar 파일로 배포할 때 Jackson의 의존관계가 딸려들어가지 않습니다.
  - 같은 방식을 지원하는 다른 JSON 파싱 라이브러리로 교체할 때 코드 변경이 없습니다.
단점
- JSON의 속성명과 생성자의 실제 파라미터 명이 다른 경우에는 사용하는 것이 부자연스럽습니다.

만약 아래와 같이 @ConstructorProperties 에서는 "ip_address"로 지정한 속성이 실제 파라미터이름이 String ip 경우라면, 코드로는 잘 동작하지만 애노테이션의 원래 의도와는 어긋난 것이 아닌가 하는 생각이 들었습니다.

    @ConstructorProperties({"accessDateTime", "ip_address", "username"})
    public AccessLog(Instant accessDateTime, String ip, String username) {
        this.accessDateTime = accessDateTime;
        this.ip = ip;
        this.username = username;
    }

@ConstructorProperties + Lombok 은 코드량이 적다는 장점이 있지만 멤버 변수의 이름이 JSON 속성명과 일치해야 한다는 단점도 있습니다. jar 파일로 배포하는 클래스라면 Lombok에 대한 의존성이 부담스러울수도 있습니다.

2.3. ParameterNameModule 활용

앞의 예제들을 보면 @JsonProperty("ip") 와 같이 지정하는 속성의 이름과 생성자의 파라미터의 이름이 동일합니다. String ip 와 같이 생성자의 파라미터의 이름을 바로 가지고 올 수 있다면 일일히 속성명을 지정하지 않을 수 있겠다는 생각이 들만합니다.

그런데 JDK 8이 나오기 전까지는 Reflection만으로는 파라미터 이름을 가지고 올 수 없었고, ASM과 같은 바이트코드 조작 라이브러리를 이용해서 디버깅을 위한 정보를 이용해야만 가능했습니다. ( https://stackoverflow.com/questions/2729580/how-to-get-the-parameter-names-of-an-objects-constructors-reflection#2729907 참조) 그래서 앞서 소개한 @java.beans.ConstructorProperties 와 같은 애노테이션도 활용되었습니다.

JDK8 이상에서는 컴파일을 할 때 -parameters 라는 옵션을 붙이면 Reflection API로 파라미터 정보를 가지고 올수 있도록 컴파일된 클래스에 정보를 덧붙여 줍니다. Gradle을 쓰고 있다면 아래와 같이 설정할 수 있습니다.

build.gradle 안의 컴파일 옵션에 추가

tasks.withType(JavaCompile).each {
    it.options.compilerArgs.add('-parameters')
}

IDE 안에서도 컴파일 옵션을 신경써줘야합니다.

IntelliJ에서는 Settings > Build, Execution, Development > Build Tools > Gradle 에서 Build and Run using: 옵션을 확인해 봅니다.

이 옵션값이 Gradle(Default)`로 되어 있다면, `build.gradle 의 컴파일 옵션이 그대로 쓰입니다. 만약 그 값이 IntelliJ IDEA 로 되어 있다면 IntelliJ 안에서의 Java 컴파일 옵션도 동일하게 맞춰 줘야합니다.

Settings > Build, Execution, Development > Compiler > Java Compiler 메뉴에서 Addtional command line parameters 옵션에 -parameters 을 적어줍니다. 옵션을 바꾼 후에는 전체 프로젝트를 리빌드합니다. ( Build > Rebuild Project )

Jackson의 ParameterNameModule 을 쓰기 위해서는 다음과 같이 의존성을 추가해야합니다.

ParameterNameModule 의존성 추가

    implementation 'com.fasterxml.jackson.module:jackson-module-parameter-names:2.10.3'

ObjectMapper 선언에서는 registerModule() 메서드로 ParameterNamesModule 을 추가합니다.

ObjectMapper에 ParameterNamesModule 추가

    var objectMapper = new ObjectMapper()
        .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
        .registerModule(new JavaTimeModule())
        .registerModule(new ParameterNamesModule());

이렇게 하면 생성자에 특별한 애너테이션을 붙이지 않아도 Jackson은 JSON의 속성을 생성자에게 전달됩니다.

Spring Boot에서는 ParameterNamesModule 을 편하게 쓸 수 있도록 아래와 같은 기본 설정이 제공됩니다.

Spring Boot Gradle Plugin에서 Java 컴파일의 -parameters 옵션이 자동 추가됩니다.
- ( JavaPluginAction.java#L90 참조 )
spring-boot-starter-web 에서 이미 jackson-module-parameter-names 에 대한 의존성이 추가되어 있습니다.
- spring-boot-starter-web → spring-boot-starter-json → jackson-module-parameter-names 로 의존관계가 연결됩니다.
디폴트로 등록되는 ObjectMapper bean에는 ParameterNamesModule 이 이미 추가되어 있습니다.
- JacksonAutoConfiguration.java#L108 참조
- RestTeamplteBuilder 로 RestTemplate 을 생성한다면 디폴트 등록된 ObjectMapper 을 참조하는 MappingJackson2HttpMessageConverter 가 RestTemplate 에 주입됩니다.

ParameterNamesModule 은 Lombok에서 자동으로 만든 생성자도 잘 인식합니다. lombok.config 에 추가 설정을 하지 않아도 된다는 점이 @ConstructorProperties 를 쓸 때와의 차이점입니다.

이 방식의 장단점은

장점
- 코드가 짧습니다.
- Jackson에 대한 의존성이 없습니다.
단점
- 생성자의 파라미터명과 JSON 속성의 이름이 반드시 일치해야 합니다.
  - 생성자의 파라미터 이름이 JSON파싱에 쓰인다는것을 의식하지 않는다면, 파라미터 명을 잘 모르고 고쳐서 JSON 파싱이 안되게 하는 부작용이 쓰일수 있습니다.
- 컴파일 옵션을 의식하지 않으면 특정 개발자의 IDE에서는 의도대로 동작하지 않을수 있습니다.
- 생성자가 여러 개 일때는 @JsonCreator 와 같은 다른 방식과 병행해서 써야 합니다.

3. 예제 소스 저장소

예제는 https://github.com/benelog/jackson-experiment 에 올려두었습니다.

@JsonCreator 활용 : JsonCreatorTest.java
@ConstructorProperties 활용 : ConstructorPropertiesTest.java
- + Lombok : LombokTest.java, lombok.config
ParameterNameModule 활용 : ParameterNameModuleTest.java, build.gradle

이 예제는 JDK 17을 써서 작성했습니다. Text blocks 문법을 썼기 때문에 JDK 15이상이 필요합니다. 이 문법이 'Preview’로 들어간 JDK 13,14에서는 컴파일 옵션으로 '--enable-preview' 을 넣어야합니다.

ktlint로 Kotlin 공식 코딩 컨벤션 맞추기

Tue, 12 Nov 2019 00:00:00 +0000

Table of Contents

1. Gradle 빌드 설정
2. IntelliJ 설정

Kotlin 언어의 공식 사이트에서는 코딩 컨벤션 가이드를 제공합니다.

https://kotlinlang.org/docs/reference/coding-conventions.html

ktlint는 Kotlin의 공식 가이드의 규칙을 포함하여 코드 스타일을 검사하고, 맞춰주는 도구입니다. 이 글에는 ktlint를 Gradle, IntelliJ, Git과 연동하여 사용하는 방법을 정리했습니다.

1. Gradle 빌드 설정

ktlint는 jar 파일로 제공되고, https://jcenter.bintray.com/ 에도 배포되어 있습니다. 따라서 별도의 Gradle plugin이 없어도 Gradle에서 task를 정의해서도 쓸 수 있습니다. 그런데 ktlint의 공식 사이트에서는 Gradle plugin을 더 권장한다고 나와 있습니다. 이 글에서는 ktlint를 래핑한 Gradle plugin 중 Github에서 별 갯수가 가장 높은 jlleitschuh/ktlint-gradle를 사용했습니다.

1.1. `.editorconfig` 설정

ktlint는 .editorconfig 파일에 선언된 규칙을 포함하여 코드 스타일을 검사합니다. .editorconfig 는 다양한 에디터와 IDE에서 공통적으로 지원하는 코드 스타일에 대한 설정 파일입니다. 자세한 스펙은 https://editorconfig.org/ 에서 파악할 수 있습니다.

아래와 같이 .editorconfig 설정을 추가하면 Kotlin 코딩컨벤션과 함께 쓰기에 무난합니다.

.editorconfig 예시

root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 4
indent_style = space
trim_trailing_whitespace = true
insert_final_newline = true
max_line_length = 120
tab_width = 4

[*.{kt,kts}]
disabled_rules=import-ordering
# java.* 패키지를 의존하는 경우  IntelliJ의 Orgarnize Import 기능으로는 알파벳 순서대로 import 구문을 정렬할 수 없다.
# 이는 ktlint의 import-ordering 규칙과 맞지 않는다.

ktlint는 .editorconfig 파일이 없어도 디폴트 규칙으로 실행할 수 있습니다. 그렇지만 아래와 같은 이유로 명시적으로 이 파일을 선언하는 것을 권장합니다.

의도하지 않게 상위 디렉토리의 .editorconfig 가 참조되는 경우를 막아줍니다.
- .editorconfig 파일의 규약에 따르면, 이 파일을 지원하는 도구들은 root = true 라는 선언이 된 .editorconfig 파일을 찾기 전까지는 모든 상위 디렉토리를 탐색합니다. ^[1]
- ktlint에서도 이 규약을 준수합니다. 따라서 특정 컴퓨터에만 소스를 복제한 디렉토리의 상위 디렉토리에 .editorconfig 가 있다면 그 장비에서는 스타일 체크 결과가 다르게 나오게 됩니다.
ktlint가 버전이 올라가면서 규칙의 디폴트 값이 변경될 경우를 대비합니다.
- 예를 들면 ktlint 0.34.0 버전부터 insert_final_newline = true 가 디폴트 값이 되었습니다. ^[2]
다양한 IDE와 Editor등의 도구에서 이 설정을 참조합니다.
- IntelliJ, VSCode, GitHub등에서 뷰어,포멧터의 설정으로 자동 반영됩니다.
코드 포멧에 대한 문서와 역할도 할 수 있습니다.
- 위의 예시와 같이 .editorconfig 에 선언되는 속성의 이름은 이해하기 쉽습니다. 이 파일만 봐도 파일 포멧에 대한 일부 규칙을 파악할 수 있습니다.
Kotlin 공식 코딩 컨벤션에 명시되지 않은 규칙까지 일치시킬 수 있습니다.
- max_line_length , insert_final_newline 과 같은 규칙을 Kotlin 공식 코딩 컨벤션에는 명시되어 있지는 않습니다. 그러나 같은 소스를 고치면서 협업하는 개발자들이 이를 통일하지 않을 경우 불필요한 diff 가 발생하여 코드 변경분을 파악할 때 불편해집니다.
disabled_rules 속성으로 검사하지 않을 규칙을 지정할 수 있습니다.
- 특히 현시점에서는 import-ordering 규칙은 쓰지 않는 것이 좋습니다. 위의 예시 파일에도 이를 반영했습니다.

jlleitschuh/ktlint-gradle는 아래와 같이 설정합니다.

Gradle Groovy설정 (build.gradle)

buildscript {
    repositories {
        maven {
            url 'https://plugins.gradle.org/m2/'
        }
    }
    dependencies {
        classpath 'org.jlleitschuh.gradle:ktlint-gradle:9.1.0'
    }
}

plugins {
    id 'org.jlleitschuh.gradle.ktlint' version '9.1.0'
}

Gradle Kotlin설정 (build.gradle.kts)

buildscript {
    repositories {
        maven(url = "https://plugins.gradle.org/m2/")
    }
    dependencies {
        classpath("org.jlleitschuh.gradle:ktlint-gradle:9.1.0")
    }
}
plugins {
    id("org.jlleitschuh.gradle.ktlint") version "9.1.0"
}

Caution

jlleitschuh/ktlint-gradle는 Gradle 버전 5.4.1이상에서만 사용할 수 있습니다. 그 이하 버전에서는 아래와 같은 에러가 나옵니다.

* What went wrong:
Could not determine the dependencies of task ':ktlintCheck'.
> Could not create task ':ktlintTestSourceSetCheck'.
   > Could not create task of type 'KtlintCheckTask'.
      > Could not generate a decorated class for class org.jlleitschuh.gradle.ktlint.KtlintCheckTask.
         > org/gradle/work/InputChanges

이럴 경우에는 Gradle의 버전을 업그레이드해야합니다.

Gradle Wrapper를 쓰고 있다면 {프로젝트홈}/gradle/wrapper/gradle-wrapper.properties 파일의 distributionUrl 속성에 지정된 버전을 고쳐서 버전을 올릴 수 있습니다.

distributionUrl=https\://services.gradle.org/distributions/gradle-5.4.1-bin.zip

다양한 Gradle 버전을 별도로 설치하는데에는 SDKMAN 을 권장합니다. Gradle이 별도로 설치되어 있을 경우 Gradle Wrapper를 업그레이드하는 방법은 https://java.ihoney.pe.kr/476 을 참조합니다.

Gradle 버전을 업그레이드하기가 어려울 경우 https://ktlint.github.io/ 에 안내된 다른 Gradle Plugin이나 Plugin없이 사용하는 방법을 참고하시기 바랍니다.

gradle.properites 파일에도 공식 코딩 컨벤션을 사용한다는 정책을 아래와 같이 명시합니다.

gradle.properites 설정

kotlin.code.style=official

IntellJ에서 프로젝트를 import할때 위의 설정을 참조할 수 있습니다.

플러그인 설정이 완료되면 ktlint를 실행하는 Gradle 태스크는 ./gradlew tasks | grep ktlint 명령으로 확인합니다.

1.2. 스타일 검사

./gradlew ktlintCheck 태스크는 스타일 검사를 수행합니다. 이 태스크는 ./gradlew build 를 실행했을 때 연결되는 전체 프로젝트 빌드 싸이클에 포함됩니다. 따라서 디폴트 설정으로는 ktlint에서 가이드하는 코드 스타일을 지키지 않으면 빌드가 실패합니다.

1.3. 스타일 일괄 변환

./gradlew ktlintFormat 태스크로는 스타일에 맞지 않는 코드를 바꿔줍니다. 전체 프로젝트의 소스 코드를 한꺼번에 고칠 때 사용할 수 있습니다.

그런데, 이 기능을 사용하다가 의도하지 않게 파일이 삭제되는 경우도 있었습니다. 그래서 이 태스크는 조심해서 사용해야합니다. 이 글에서 설명한 IntelliJ로 포멧을 일괄변환하는 방법도 참고해서 병행해서 사용하는 편이 좋습니다.

1.4. Git hook으로 설정

앞에서 설명한 ktlintCheck , ktlintFormat 태스크를 Git의 Hook으로 등록하여 commit을 하면 자동으로 실행되게 할 수 있습니다.

./gradlew addKtlintCheckGitPreCommitHook : ktlintCheck 태스크를 pre-commit hook으로 등록
./gradlew addKtlintFormatGitPreCommitHook : ktlintFormat 태스크를 pre-commit hook으로 등록ktlintCheck 태스크로 검사하도록 설정합니다.

앞에서 설명한 것처럼 ktlintFormat 태스크는 의도하지 않게 파일을 바꿀 위험이 있기 때문에 addKtlintCheckGitPreCommitHook 를 더 권장합니다.

등록된 pre-commit hook은 rm .git/hooks/pre-commit 명령으로 삭제할 수 있습니다.

2. IntelliJ 설정

IntelliJ의 코드 포멧터는 Kotlin 공식 코딩 컨벤션이 나오기 전부터 쓰이던 디폴트 설정이 있었습니다. IntelliJ에서는 Kotlin 1.3에서는 신규로 생성되는 프로젝트에서, Kotlin 1.4에서는 모든 프로젝트에서 공식 컨벤션에 맞춘 포멧터가 디폴트로 설정될 것이라고 합니다. ^[3] 오랫동안 유지보수할 Kotlin 코드라면 공식 컨벤션에 맞춰서 IntelliJ에서도 포멧터를 설정되었는지 신경을 써야 합니다.

2.1. 포멧터 설정

다음에 안내한 A, B 2가지 방법 중의 하나를 선택하셔서 공식 코딩컨벤션에 맞게 IntelliJ의 포멧터 설정을 맞출수 있습니다.

2.1.1. A. `predefined ` 을 이용한 설정

IntelliJ 메뉴에서 Settings > Editor > Code Style > Kotlin 으로 이동합니다.
Scheme 항목을 Project로 지정합니다.
- 여러 프로젝트에서 다른 설정을 쓸 경우를 대비해 가급적 글로벌 설정을 바꾸지 않기 위함입니다.
Set from… → Predefined Style → Kotlin Style Guide 를 선택합니다.

2.1.2. B. Gradle plugin을 이용한 설정

앞서 설정한 jlleitschuh/ktlint-gradle를 이용하여 ./gradlew ktlintApplyToIdea 태스크를 실행합니다. 이 태스크는 IntelliJ 설정파일의 코드 스타일 부분을 덮어써서 ktlint의 규칙과 가급적 맞는 포멧터가 설정합니다.

포멧터가 설정되면 파일을 편집할 때 Code > Reformat Code 메뉴를 선택하거나 단축키 Ctrl + Shift + L 단축키로 포멧터를 적용할 수 있습니다.

2.2. 기존 코드 일괄 변환

IntelliJ의 프로젝트 탐색기에서 프로젝트의 최상위 디렉토리를 우클릭합니다.
Reformat Code 를 실행합니다.
- 우클릭을 하여 나오는 메뉴에서 Reformat Code 를 선택하거나
- Ctrl + Shift + L 단축키를 누릅니다.

2.3. 파일을 저장할 때마다 포멧터 적용하기

Save Actions Plugin를 사용하면 파일을 저장할 때 자동으로 포멧터를 실행할 수 있습니다.

File > Settings ( Ctrl + Alt + S ) > Plugins 메뉴로 이동합니다.
Marketplace 탭에서 'Save Actions' 로 검색합니다.
Save Actions' plugin의 상세 설명 화면에서 `[Install] 버튼을 누릅니다.
IntelliJ를 재시작합니다.
File > Settings > Other Settions > Save Actions 메뉴로 이동합니다.
아래 항목 혹은 그외의 원하는 정책을 체크합니다.
- Activate save actions on save
- Optimize imoprts
- Refomat file (전체 프로젝트의 스타일이 통일된 경우)
- Refomat only changed code (프로젝트의 스타일이 통일되어 있지 않아서 스타일이 맞지 않는 코드를 함께 고치면 변경 부분을 알아보기가 더 어려운 경우)

2.4. 포멧터가 바꿔주지 않는 규칙 신경쓰기

IntelliJ의 포멧터는 ktlint에서 검사하는 규칙을 다 자동을 맞추어주지는 못합니다. 즉 Reformat Code ( Ctrl + Alt + L ) 을 실행하는 것만으로는 ktlint 검사를 통과한다는 보장은 없습니다. 다음에서 설명하는 IntelliJ의 기능을 잘 활용하면 보다 빠른 시점에서 ktlint의 규칙을 준수하는데 도움이 됩니다.

2.4.1. 파일의 마지막에 자동으로 개행문자 추가

POSIX 명세에 따라서, 텍스트 파일의 마지막에 개행문자(LF)를 추가하는 것이 권장됩니다. ^[4]

그런데, IntelliJ의 Reformat Code 기능으로는 마지막 개행문자 추가가 되지 않습니다. File > Settings > Editor > General 메뉴에서 Ensure line feed at file end on Save 를 선택하면, 파일이 저장될 때 자동으로 마지막에 개행문자를 추가해줍니다.

이 설정은 .editorconfig 의 선언에 따라 자동으로 활성화될 수도 있습니다. 그렇지만 의도대로 동작하지 않는다면 한번 확인해볼만합니다.

2.4.2. IntelliJ 경고에 따라 고치기

Kotlin 공식 코딩 컨벤션에는 공백 등 단순한 파일 형식 외에도 문법적인 요소에 대한 것도 있습니다.

예를 들면 String Template를 쓸 때는 꼭 필요한 경우가 아니면 중괄호를 넣지 말라는 규칙이 있습니다. ( https://kotlinlang.org/docs/reference/coding-conventions.html#string-templates )

(O): println("$name is my friend.")
(X): println("${name} is my friend.")

이 규칙을 어긴 코드는 'Reformat Code' 로는 바로 바뀌지 않습니다. IntelliJ에서 이런 코드에 경고를 보내고 Alt + Shift + Enter 단축키로 코드로 바꾸는 기능을 제공합니다.

이처럼 IntelliJ에서는 언어 문법을 활용할때도 Kotlin 공식 코딩 컨벤션에서 권장하는 스타일대로 쓰도록 유도하고 있습니다. 이런 경고들을 무시하지 않고 반영한다면 ktlint의 검사에서도 통과할 가능성이 높아집니다.

1. https://editorconfig.org/ 에서 'When opening a file, EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory.'

2. 0.34.0 릴리즈 노트 참고 : https://github.com/pinterest/ktlint/blob/master/CHANGELOG.md#0340---2019-07-15

3. https://kotlinlang.org/docs/reference/code-style-migration-guide.html 에서 설명된 계획입니다.

4. https://blog.coderifleman.com/2015/04/04/text-files-end-with-a-newline/ 참조

여러 개의 JDK를 설치하고 선택해서 사용하기

Mon, 1 Jul 2019 00:00:00 +0000

Table of Contents

1. 특별한 도구를 안 쓸 때의 JDK 설치 & 버전 선택
- 1.1. JDK 설치
- 1.2. JDK 버전 선택
2. 다양한 JDK 설치와 사용을 편하게 하는 도구
3. 무엇을 어떻게 사용할 것인가?

다양한 배포판과 버전의 JDK를 명령어 한 줄로 설치하고 OS의 쉘에서 사용할 JDK를 쉽게 지정할 수 있게 해주는 도구들을 소개합니다.

주요 변경이력

2023.03.27
- Jabba 설치를 안내하는 URL을 현재 관리되는 포크된 버전으로 변경
2019.07.03
- Homebrew에 대한 소개를 별도의 단락으로 분리
- Chocolatey에 대한 설명 보강

1. 특별한 도구를 안 쓸 때의 JDK 설치 & 버전 선택

1.1. JDK 설치

JDK를 수동으로 설치하는 절차는 아래와 같습니다.

설치할 버전/배포판을 다운로드합니다.
- 예) Oracle의 OpenJDK 빌드 : https://jdk.java.net/
- 예) AdoptOpenJDK : https://adoptopenjdk.net/
- 예) Graal VM Community Edition : https://github.com/oracle/graal/releases
다운로드한 파일의 압축을 풉니다.
OS의 환경변수를 지정합니다.
- JAVA_HOME
  - JDK의 압축을 푼 디렉토리를 지정합니다.
  - Maven이나 Tomcat 같은 솔류션에서 이 환경변수로 JDK의 위치를 참조합니다.
- PATH
  - 쓰고 있던 PATH 변수에 $JAVA_HOME/bin 을 더합니다.
  - java , javac 등을 명령행에서 직접 실행할 수 있도록 하기 위해서 하는 작업입니다.

1.2. JDK 버전 선택

IDE에서는 프로젝트별로 사용할 JDK의 위치를 선택할 수 있습니다. IntelliJ에서는 File > Project Structure > Platform Settings (단축키 Ctrl + Alt + Shift + S ) > SDK 메뉴 에서 이를 지정합니다.

OS의 명령행에서 Maven, Gradle로 직접 빌드를 하거나 java -jar 로 직접 프로그램을 실행시킬 때를 대비해서 JAVA_HOME, PATH 설정이 되어 있어야합니다. 프로젝트마다 사용하는 JDK 버전이 다르면 사용할 JDK를 지정하기가 번거롭습니다. 매번 이런 JAVA_HOME 같은 환경 변수를 바꾸거나 /usr/lib/jvm/java-13-openjdk-amd64/bin/java 와 같이 전체 경로로 실행할 도구를 지정한다면 더욱 그렇습니다.

반복적인 작업을 쉘스크립트나 배치파일로 할 수도 있습니다. 그런데 이미 이런 작업을 편리하게 해주는 도구들이 몇 가지 있습니다.

2. 다양한 JDK 설치와 사용을 편하게 하는 도구

JDK의 설치와 OS의 명령행에서 사용할 버전을 지정할 때는 아래 도구들을 사용할 수 있습니다.

Table 1. JDK 설치와 버전 지정에 사용할 수 있는 도구들
이름	기능	사용 가능한 OS
YUM/APT	범용 패키지 관리 도구	Linux
update-alternatives/alternatives	범용 패키지 버전 선택 도구	Linux
Homebrew	범용 패키지 관리 도구	macOS
Chocolatey	범용 패키지 관리 도구	Windows
SDKMAN	범용 패키지 관리 도구	Linux macOS Windows(Cygwin, Git Bash)
jabba	JDK 설치 특화 도구	Linux macOS Windows
jEnv	JDK 버전 선택 특화 도구	Linux macOS
direnv	범용 디렉토리별 환경 변수 관리 도구	Linux macOS Windows

2.1. APT/YUM

Ubuntu, CentOS 등의 Linux 배포판에서는 해당 OS에 맞도록 빌드한 OpenJDK 배포판을 APT,YUM 등으로 간단히 설치할 수 있도록 제공합니다.

APT(Advanced Packaging Tool)는 Ubuntu 등 Debian 계열의 리눅스에서 사용할 수 있는 패키지 관리 프로그램입니다. Ubuntu에서는 APT로 아래와 같이 여러 버전의 JDK를 설치할 수 있습니다.

sudo apt install openjdk-8-jdk
sudo apt install openjdk-11-jdk
sudo apt install openjdk-12-jdk

YUM(Yellow dog Updater, Modified)은 Red Hat/CentOS 리눅스 배포판에서 사용할 수 있는 패키지 관리자입니다. 아래와 같이 사용할 수 있습니다.

sudo yum install java-1.8.0-openjdk-devel.x86_64

Adopt OpenJDK 배포판은 패키지 저장소를 추가해서 설치할 수 있습니다. Ubuntu에서는 아래와 같이 합니다.

sudo add-apt-repository ppa:rpardini/adoptopenjdk
sudo apt install adoptopenjdk-11-installer

설치된 JDK의 java , javac 도구는 /usr/bin/java , /usr/bin/javac 에서 심볼릭 링크로 연결되어 어느 디렉토리에서나 실행될 수 있게 됩니다. 이 심볼릭 링크는 이어서 소개할 update-alternatives / alternatives 도구로 관리할수 있습니다. JAVA_HOME 환경 변수는 직접 ~/.bashrc 와 같은 쉘별 설정 파일에 넣어줘야 합니다.

장점
- OS에서 기본 제공하는 도구이기에 도구를 위한 별도의 설치 과정이 필요 없습니다.
- JDK 외에도 Maven, Gradle의 설치에도 활용할 수 있는 범용적인 패키지 관리 도구입니다.
단점
- SDKMAN/ Jabba에 비하면 다양한 JDK 배포판을 제공하지는 않습니다.

2.2. update-alternatives / alternatives

update-alternatives와 alternatives는 여러 버전의 패키지를 관리할 수 있는 Linux에서 제공되는 도구입니다. 여기서는 Ubuntu에서 쓰는 update-alternatives 를 기준으로 설명하겠습니다.

앞서 나온데로 apt 로 설치한 JDK는 /usr/bin/java 에서 심볼릭 링크로 연결됩니다. 이 심블릭 링크는 /etc/alternatives/java 를 중간에 거쳐서 실제 설치한 디렉토리로 연결된 다는 것을 아래와 같이 확인할 수 있습니다.

➜  ~ ll /usr/bin/java
lrwxrwxrwx 1 root root 22  6월  9 22:20 /usr/bin/java -> /etc/alternatives/java
➜  ~ ll /etc/alternatives/java
lrwxrwxrwx 1 root root 43  6월  9 22:20 /etc/alternatives/java -> /usr/lib/jvm/java-12-openjdk-amd64/bin/java

readlink -f /usr/bin/java 명령으로도 동일한 결과를 볼 수 있습니다.

이 링크는 update-alternatives 로 관리됩니다. 아래와 같은 명령으로 현재 설치된 버전들과 우선 순위를 확인할 수 있습니다.

sudo update-alternatives --display java

수동으로 다운로드 압축을 풀어서 설치하거나 SDKMAN, Jabba등으로 설치한 JDK가 있다면 아래 명령으로 update-alternatives 의 관리대상에 추가할 수 있습니다.

sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.8.0_31/bin/java 1000

심볼릭 링크로 연결되는 버전을 바꾸고 싶다면 아래와 같이 입력합니다.

sudo update-alternatives --config java

설치된 버전을 확인하고 번호를 선택해서 심볼릭 링크를 바꿀 수 있습니다.

There are 4 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-12-openjdk-amd64/bin/java      1211      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      manual mode
  2            /usr/lib/jvm/java-12-openjdk-amd64/bin/java      1211      manual mode
  3            /usr/lib/jvm/java-13-openjdk-amd64/bin/java      1211      manual mode
  4            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode

Press <enter> to keep the current choice[*], or type selection number:

그런데 명령행에서 실행한 java 가 어느 곳으로 연결될지는 환경변수 PATH 에 영향을 받습니다. /usr/bin/java 보다 더 우선 순위가 높게 먼저 선언된 디렉토리에 java`가 있다면 `update-alternatives 에서 지정한 java가 실행되지 않을 수도 있습니다. SDKMAN, Jabba 등을 함께 사용한다면 이 점을 유의해야 합니다. 현재 쉘, 디렉토리에서 어느 java 를 실행하고 있는지는 which java 로 확인할 수 있습니다.

장점
- OS에서 기본적으로 제공하는 도구라서 별도의 설치 과정이 필요하지 않습니다.
- YUM/APT 과 자연스럽게 함께 쓰이는 도구입니다.
단점
- 심블릭 링크로 쉘에서 사용할 디폴트 버전을 지정하는 기능만 있습니다.

2.3. Homebrew

macOS에서 많이 쓰는 범용 패키지 관리 프로그램입니다.

Homebrew로 AdoptOpen JDK배포판은 아래와 같이 설치할 수 있습니다.

brew tap AdoptOpenJDK/openjdk
brew cask install adoptopenjdk11

제가 macOS를 써본적이 없어서 Homebrew로 설치하는 방법에 대해서는 homebrew로 opendjk 설치하기 글을 참조했습니다.

2.4. Chocolatey

Chocolatey는 Windows OS를 위한 패키지 관리자입니다. Linux에는 APT/YUM, macOS에는 Homebrew가 있다면 Windows에는 Chocolatey가 대표적인 패키지 관리자입니다. https://chocolatey.org/install 을 참고해서 설치할수 있습니다.

Chocolatey로 설치가능한 JDK 패키지는 https://chocolatey.org/packages?q=jdk 으로 확인하실 수 있습니다.

Oracle의 OpenJDK 빌드나 Adopt OpenJDK 배포판 등을 아래와 같이 설치할 수 있습니다.

Oracle의 OpenJDK 빌드 최신 버전 설치

choco install openjdk

AdoptOpenJDK 최신 버전 설치

choco install adoptopenjdk

Corretto 11 버전 설치

choco install corretto11jdk

zulu 최신 버전 설치

choco install zulu

--version 옵션을 붙이면

Oracle의 OpenJDK 빌드 11.0.2 버전 설치

choco install openjdk --version 11.0.2

위의 명령이 수행되고 나면 \Program Files\ 디렉토리 아래에 JDK 들이 위치하게 됩니다.

Oracle의 OpenJDK 빌드 : \Program Files\OpenJDK
Adopt OpenJDK : \Program Files\AdoptOpenJDK
Corretto : \Program Files\Coretto
Zulu : \Program Files\zulu

그런대 Chocolatey는 여러 JDK 버전을 동시에 쓰는 쓰임새가 우선적으로 고려되지는 않았습니다. JDK 12.0.1을 설치후에 11.0.2을 뒤에 설치하려고하면, 다운그레이드가 된다는 경고 메시지가 나옵니다. 이럴 때에는 '-sidebyside' 혹은 --force 등의 옵션을 붙여줘야합니다. JAVA_HOME 도 마지막으로 설치한 JDK의 위치로 지정됩니다. echo %java_home% 명령으로 이를 확인해 볼 수 있습니다. 여러 배포판을 설치할 경우 PATH 환경 변수의 값도 새로 설치한 배포판의 %JAVA_HOME%\bin 디렉토리가 뒤 쪽에 계속 추가만 됩니다.

장점
- JDK 외에도 Maven, Gradle의 설치에도 활용할 수 있는 범용적인 패키지 관리 도구입니다.
단점
- SDKMAN/ Jabba에 비하면 다양한 JDK 배포판을 제공하지는 않습니다.
- 여러 버전을 동시에 설치할 수 있는 동작이 디폴트가 아닙니다.
  - OS 명령행에서 여러 JDK 버전을 함께 사용하려면 direnv등 별도의 프로그램과 함께 쓰는 것이 좋습니다.

2.5. direnv

direnv 는 특정 디렉토리와 그 하위 디렉토리에서만 사용할 환경 변수를 지정할 수 있는 도구입니다. Linux와 macOS에서 사용할 수 있습니다. 설치 방법은 https://direnv.net/ 을 참조합니다.

direnv에서 참조하는 .envrc 라는 파일에 PATH, JAVA_HOME 을 아래와 같이 지정할 수 있습니다.

export JAVA_HOME=/home/benelog/.sdkman/candidates/java/12.0.1.hs-adpt
export PATH=$JAVA_HOME/bin:$PATH

파일을 처음 생성하거나 변경했을 때에는 direnv allow . 명령을 한번 내려줘야합니다. 이 파일이 의도하지 않게 생성/수정 되었을 때 보안을 위한 장치입니다.

이후로 이 파일이 있는 디렉토리에 들어가면 이 환경변수가 활성화됩니다. cd 명령으로 디렉토리에 들어가면 아래와 같은 메시지가 콘솔에 보입니다.

direnv: loading .envrc
direnv: export ~JAVA_HOME ~PATH

보편적으로 사용할 수 있는 도구이기에 JAVA_HOME 외의 다른 환경 변수도 관리할 수 있습니다. 같은 프로젝트를 하더라도 개발자의 PC마다 달라지는 값이나 테스트를 위한 변수도 .envrc 에 넣어둘만합니다. 그럴 경우에는 .envrc 은 .gitignore 에 추가해서 Git 저장소에는 들어가지 않도록 해야 하겠습니다.

장점
- JAVA_HOME 이나 PATH 외의 환경 변수도 관리할 수 있습니다.
단점
- 특정 디렉토리 내에서의 환경 변수 기능만 제공합니다.

2.6. jEnv

jEnv 는 JDK 버전관리만을 위한 전용 도구입니다.

아래와 같이 add 명령으로 관리할 버전을 추가합니다.

jenv add /usr/lib/jvm/java-11-openjdk-amd64/

add 로 지정한 디렉토리에서 JDK의 버전을 인식하여 아래와 같은 메시지가 나옵니다.

jenv add 명령의 결과

openjdk64-11.0.3 added
11.0.3 added
11.0 added

설치된 버전은 jenv versions 명령으로 확인할 수 있습니다.

jenv versions 명령의 결과

  system
  1.8
  1.8.0.212
* 11.0 (set by JENV_VERSION environment variable)
  11.0.3
  openjdk64-1.8.0.212
  openjdk64-11.0.3

디폴트로 사용할 버전은 global 명령으로 지정합니다.

jenv global 11.0

해당 쉘에서 임시로 사용할 버전은 shell 명령으로 지정합니다.

jenv shell 11.0

현재 디렉토리에서 사용할 버전은 local 명령으로 지정합니다.

jenv local 11.0

위와 같이 디렉토리에 지정된 버전은 .java-version 이라는 파일에 저장됩니다. 다음 번에 같은 디렉토리에서 java를 실행하면 이 파일에 지정된 해당 버전이 선택됩니다.

JAVA_HOME 환경 변수가 제대로 지정되기 위해서는 jENV의 export plugin을 아래 명령으로 활성화해줘야 합니다.

jenv enable-plugin export

jEnv를 다른 도구와 잘 어우러지게 사용하기 위해서는 동작 원리를 알아두는 것이 좋습니다. jEnv로 JDK 버전을 지정한 후 which java 로 어느 디렉토리에 있는 java 와 연결되는지 확인을 해보면 ~/.jenv/shims/java 가 나옵니다. 이 파일의 내용을 보면 실제 설치한 JDK의 java 가 아닌 쉘 스크립트라는 것을 알수 있습니다.

cat ~/.jenv/shims/java 명령의 결과

#!/usr/bin/env bash
set -e
[ -n "$JENV_DEBUG" ] && set -x

program="${0##*/}"
if [ "$program" = "java" ]; then
  for arg; do
    case "$arg" in
    -e* | -- ) break ;;
    */* )
      if [ -f "$arg" ]; then
        export JENV_DIR="${arg%/*}"
        break
      fi
      ;;
    esac
  done
fi

export JENV_ROOT="/root/.jenv"
exec "/root/.jenv/libexec/jenv" exec "$program" "$@"

따라서 다른 도구와 병행해서 사용할 경우, 환경변수 $PATH`에 `~/.jenv/shims/java`가 다른 도구에서 넣어준 JDK와 연결된 경로들보다 앞에 있어야 jEnv에서 설정한 버전대로 `java 가 실행됩니다.

$JAVA_HOME`도 어떻게 지정되어 있는지 `echo $JAVA_HOME 로 확인을 해보면 ~/.jenv/versions/11.0 와 같이 지정되어 있습니다. `~/.jenv/versions/ 디렉토리에 각 버전별로 실제로 JDK가 설처되어있는 디렉토리로의 심볼릭 링크가 들어가 있습니다.

~/.jenv/versions 디렉토리 안의 심볼릭 링크

lrwxrwxrwx  1 benelog benelog   33 Jun 30 17:05 1.8 -> /usr/lib/jvm/java-8-openjdk-amd64/
lrwxrwxrwx  1 benelog benelog   33 Jun 30 17:05 1.8.0.212 -> /usr/lib/jvm/java-8-openjdk-amd64/
lrwxrwxrwx  1 benelog benelog   34 Jun 30 17:08 11.0 -> /usr/lib/jvm/java-11-openjdk-amd64/
lrwxrwxrwx  1 benelog benelog   34 Jun 30 17:08 11.0.3 -> /usr/lib/jvm/java-11-openjdk-amd64/
lrwxrwxrwx  1 benelog benelog   33 Jun 30 17:05 openjdk64-1.8.0.212 -> /usr/lib/jvm/java-8-openjdk-amd64/
lrwxrwxrwx  1 benelog benelog   34 Jun 30 17:08 openjdk64-11.0.3 -> /usr/lib/jvm/java-11-openjdk-amd64/

그런데 jEnv는 여러 배포판을 동시에 설치할 때는 충돌을 일으킬수 있습니다. 예를 들어 Ubuntu 패키지 저장소의 OpenJDK 11을 이미 'jenv add' 로 넣은 다음, AdoptOpenJDK 11을 추가하면 아래와 같이 이미 존재하는 버전이라는 메시지가 나옵니다.

`jenv add /usr/lib/jvm/adoptopenjdk-11-jdk-hotspot 실행결과

 openjdk64-11.0.3 already present, skip installation
 11.0.3 already present, skip installation
 11.0 already present, skip installation

jEnv는 동일한 JDK 배포판의 여러 버전을 관리하는데 적합합니다.

장점
- 다양한 범위(디폴트(global), 디렉토리별, 쉘 범위)의 버전 방식을 지원합니다.
단점
- 다양한 배포판의 동일한 JDK 버전(예: 11.0.3)을 관리할 수 없습니다.

2.7. SDKMAN

SDKMAN(The Software Development Kit Manager)은 여러 개발도구를 설치할 수 있는 도구입니다. JDK 뿐만 아니라 Maven, Gradle, Ant, AsciidoctorJ 등 JVM 세계의 다양한 도구들을 설치할 수 있습니다.

OS별로 SDKMAN을 설치하는 방법은 https://sdkman.io/install 을 참조합니다.

SDKMAN으로 설치할 수 있는 JDK 배포판/버전은 sdk list java 명령으로 확인할 수 있습니다. 아래와 같이 사용할 수 있는 배포판들과 설치된 버전 등을 표시해 줍니다.

================================================================================
Available Java Versions
================================================================================
 Vendor        | Use | Version      | Dist    | Status     | Identifier
--------------------------------------------------------------------------------
 AdoptOpenJDK  |     | 12.0.1.j9    | adpt    |            | 12.0.1.j9-adpt
               |     | 12.0.1.hs    | adpt    | installed  | 12.0.1.hs-adpt
               |     | 11.0.3.j9    | adpt    |            | 11.0.3.j9-adpt
               |     | 11.0.3.hs    | adpt    |            | 11.0.3.hs-adpt
               |     | 8.0.212.j9   | adpt    |            | 8.0.212.j9-adpt
               | >>> | 8.0.212.hs   | adpt    | installed  | 8.0.212.hs-adpt
 Amazon        |     | 11.0.3       | amzn    |            | 11.0.3-amzn
               |     | 8.0.212      | amzn    |            | 8.0.212-amzn
 Azul Zulu     |     | 12.0.1       | zulu    |            | 12.0.1-zulu
               |     | 11.0.3       | zulu    |            | 11.0.3-zulu
               |     | 10.0.2       | zulu    |            | 10.0.2-zulu
               |     | 9.0.7        | zulu    |            | 9.0.7-zulu
               |     | 8.0.212      | zulu    |            | 8.0.212-zulu
               |     | 7.0.222      | zulu    |            | 7.0.222-zulu
               |     | 6.0.119      | zulu    |            | 6.0.119-zulu
 Azul ZuluFX   |     | 11.0.2       | zulufx  |            | 11.0.2-zulufx
               |     | 8.0.202      | zulufx  |            | 8.0.202-zulufx
 BellSoft      |     | 12.0.1       | librca  |            | 12.0.1-librca
               |     | 11.0.3       | librca  |            | 11.0.3-librca
               |     | 8.0.212      | librca  |            | 8.0.212-librca
 GraalVM       |     | 19.0.2       | grl     |            | 19.0.2-grl
               |     | 19.0.0       | grl     |            | 19.0.0-grl
               |     | 1.0.0        | grl     | installed  | 1.0.0-rc-16-grl
 SAP           |     | 12.0.1       | sapmchn |            | 12.0.1-sapmchn
               |     | 11.0.3       | sapmchn |            | 11.0.3-sapmchn
 java.net      |     | 14.ea.1      | open    |            | 14.ea.1-open
               |     | 13.ea.25     | open    |            | 13.ea.25-open
               |     | 12.0.1       | open    |            | 12.0.1-open
               |     | 11.0.2       | open    |            | 11.0.2-open
               |     | 10.0.2       | open    |            | 10.0.2-open
               |     | 9.0.4        | open    |            | 9.0.4-open
================================================================================
Use the Identifier for installation:

    $ sdk install java 11.0.3.hs-adpt
================================================================================

AdoptOpenJDK HotSpot 배포판 12.0.1 버전을 설치하고 싶다면 아래와 같은 명령을 내립니다.

sdk install java 12.0.1.hs-adpt

PATH , JAVA_HOME 환경변수도 알아서 잘 잡아줍니다.

명령행에서 디폴트로 사용할 JDK 버전은 ~/.sdkman/candidates/java/current 에서 심볼릭 링크로 관리됩니다. 이 링크가 환경변수 $PATH`와 `$JAVA_HOME 에 추가 됩니다.

이 심볼릭 링크는 아래 명령으로 바꿀 수 있습니다.

sdk default java 8.0.212.hs-adpt

현재 쉘에서 사용할 버전만 임시로 바꾸고 싶다면 default 대신 use 명령을 씁니다.

sdk use java 8.0.212.hs-adpt

장점
- 다양한 JDK 배포판을 설치할 수 있습니다.
- JDK 설치와 버전 지정을 하나의 도구로 관리할 수 있습니다.
단점
- 특정 디렉토리에 들어갔을 때 사용할 버전을 자동을 지정하는 기능이 없습니다.
- sdk use 명령이 jabba의 동일한 기능에 비해 실행 속도가 느립니다.

2.8. jabba

jabba는 JDK의 설치/버전 관리만을 위한 도구입니다.

각 OS별 jabba의 설치 방법은 https://github.com/Jabba-Team/jabba#installation 을 참조합니다.

설치할 수 있는 JDK의 배포판은 jabba ls-remote 명령으로 확인할 수 있습니다. 이중 Amazon에서 제공하는 Corretto 배포판 JDK 11을 설치한다면 아래와 같은 명령을 내립니다.

jabba install amazon-corretto@1.11.0-3.7.1

설치된 버전들은 jabba ls 명령으로 확인할 수 있습니다. 현재 쉘에서 사용할 버전은 아래와 같이 지정할 수 있습니다.

jabba use adopt-openj9@1.12.33-0

jabba use 를 실행하면 PATH 와 JAVA_HOME 환경변수를 지정한 JDK 버전을 참조할수 있도록 바꾸어줍니다. echo $PATH 로 PATH 값을 확인해보면, 가장 앞에 설치한 JDK의 bin 디렉토리를 지정할 것을 확인할 수 있습니다.

같은 디렉토리에 `.jabbarc`라는 파일이 있다면, 그 파일에 지정된 버전을 참조할 수 있습니다. 즉 아래와 같이 실행해도 특정 버전을 지정할 수 있습니다.

echo "adopt-openj9@1.12.33-0" > .jabbarc
jabba use

다음 번에 같은 디렉토리에 들어왔을 떄에는 jabba use 만 간단하게 실행해서 같은 효과를 낼 수 있습니다. direnv나 jEnv를 쓸 때처럼 디렉토리에 들어가면 자동으로 환경변수를 바꾸어주는 기능은 없습니다.

현재 쉘범위의 JDK 버전만 지정한다는 점이 jabba의 장점이나 단점입니다.

장점
- 다른 도구와 충돌없이 쓰기에 좋습니다.
- jabba use 명령이 SDKMAN의 sdk use 에 비해 실행 속도가 빠릅니다.
단점
- 디폴트 버전 지정이 없습니다.
- 디렉토리별 버전 비전 기능이 완전 자동이 아닙니다. 해당 디렉토리에서 jabba use 를 한번 입력해야 합니다.

3. 무엇을 어떻게 사용할 것인가?

위의 다양한 도구 중 어떤 것을 골라 쓸지는 개발장비의 OS와 필요한 범위에 따라서 결정해야할 것입니다.

우선 다양한 배포판의 JDK를 쓰는 것까지 필요가 없다면 아래 정도의 조합을 고려할만합니다.

Windows : Chocolatey + direnv
Linux : APT/YUM + update-alternatives + jEnv (또는 direnv)
macOS : Homebrew + jEnv(또는 direnv)
- [Mac에 Java 여러 버전 설치] 글에서는 Homebrew로 Oracle JDK를 설치하고 jEnv와 함께 사용하는 사례가 정리되어 있습니다.

Amazon Corretto, GraalVM 등 다양한 배포판의 여러버전을 설치해보고 싶다면 SDKMAN이나 jabba를 함께 쓰는 것을 추천합니다. 각 도구들이 지원하는 배포판은 아래와 같습니다. (2019년 7월1일 기준)

Table 2. JDK 설치 도구들이 지원하는 배포판
이름	지원하는 JDK 배포판
YUM/APT	OS 배포판별 OpenJDK *(1)** AdoptOpen JDK
Homebrew	Oracle JDK Adopt OpenJDK
Chocolatey	Oracle JDK Oracle의 OpenJDK 빌드 *(2)** Adopt OpenJDK Amazon Corretto Zulu OpenJDK
SDKMAN	Oracle의 OpenJDK 빌드 *(2)** Adopt OpenJDK Amazon Corretto GraalVM CE Zulu OpenJDK Zulu OpenJDK + OpenJFX SapMachine Liberica JDK
jabba	Oracle JDK Oracle의 OpenJDK 빌드 *(2)** Adopt OpenJDK Amazon Corretto GraalVM CE Zulu OpenJDK IBM SDK OpenJDK 참조 구현체 OpenJDK + Shenandoah GC Liberica JDK

(*1) : 해당 OS 배포판을 위해 빌드된 OpenJDK 배포판입니다. OS의 배포판을 관리하는 업체/커뮤니티에서 관리합니다.
(*2) : https://jdk.java.net/ 에서 다운로드 받을 수 있는 OpenJDK 배포판입니다. 출시 후 6개월까지만 최신 버전이 업데이트됩니다.

위에 정리한 것처럼 SDKMAN과 jabba가 많은 JDK 배포판을 지원합니다. 둘다 Adopt OpenJDK, Amazon Corretto, GraalVM CE, Zulu 등 주목받는 주요 배포판은 모두 포함하고 있습니다.

SDKMAN에서는 제공하는 반면 jabba에는 없는 배포판은 아래와 같습니다.

Zulu OpenJDK + OpenJFX
SapMachine

jabba에서는 제공하는 반면 SDKMAN에는 없는 배포판은 아래와 같습니다.

IBM SDK
OpenJDK 참조 구현체
- https://jdk.java.net/java-se-ri/8 등 에서 받을수 있는 배포판 입니다.
OpenJDK + Shenandoah GC

SDKMAN과 jabba는 JDK 설치와 버전 지정 기능을 동시에 제공합니다. 그런데 jenv등 다른 도구에서 제공하는 버전 지정 기능을 완정히 제공하지는 않습니다.

Table 3. JDK 버전 지정 기능
도구	디폴트	디렉토리별	쉘 범위
update-alternatives/ alternatives	O	X	X
SDKMAN	O	X	O
jabba	X	△*(3)**	O
jEnv	O	O	O
direnv	X	O	X

(*3) : jEnv나 direnv처럼 디렉토리에 들어가면 자동으로 특정 JDK 버전이 선택되는 방식은 아니기 때문에 △로 표기했습니다.

따라서 SDKMAN이나 jabba는 다른 도구와 조합해서 사용하면 더욱 편리하게 쓸 수 있습니다. 그런데 앞서 언급했듯이 jEnv는 SDKMAN이나 jabba와 함께 쓰기에는 적합하지 않습니다. $PATH 환경 변수에 지정된 경로의 순서에 따라서 여러 도구의 버전 지정 결과가 의도하지 않게 덮어 써질수 있습니다. 즉 SDKMAN에 지정한 경로가 앞에 있으면 jEnv에서 지정한 JDK 버전이 인식되지 않는 것처럼 보일수도 있습니다. 그리고 jabba로는 여러 배포판의 JDK 11.0.3 을 설치할 수 있지만 jEnv에서는 'jenv add' 로 같은 버전(11.0.3)의 다른 배포판을 추가할 수 없습니다.

따라서 다양한 배포판을 설치하고자 할때는 SDKMAN(또는 jabba) + direnv 조합을 추천합니다.

제가 이 도구들을 쓰는 환경은 아래와 같습니다.

각각 다른 JDK 버전을 쓰는 여러 프로젝트의 소스를 고칩니다.
업무 혹은 취미로 JDK의 여러 배포판/ 버전을 설치해서 차이가 있는지 확인하고 있습니다.
- (예: 포함된 ca-cert 목록 비교, GraalVM으로 네이티브 이미지 만들기 시도)
회사의 업무용 노트북과 집에 있는 PC에서 Ubuntu 19.04를 씁니다.

이에 따라 저는 아래와 같이 도구를 조합해서 쓰고 있습니다.

JDK 설치에는 APT, SDKMAN, jabba를 다 사용해 보고 있습니다.
사용할 버전을 선택할 때는
- 디폴트 버전은 SDKMAN으로 지정합니다.
  - SDKMAN을 설치하면 SDK에서 관리하는 패키지들이 /usr/bin 보다 앞에 오기 때문입니다. 디폴트 버전은 자주 바꾸진 않기 때문에 굳이 이를 조정하진 않았습니다.
- 특정 디렉토리에서 사용한 버전을 지정할 때는 direnv를 씁니다.
- 쉘에서 일시적으로 사용할 버전을 지정할 때는 SDKMAN, jabba를 씁니다.

정적 사이트로 블로그 마이그레이션

Mon, 6 May 2019 00:00:00 +0000

Table of Contents

1. 블로그를 이전한 동기
2. 요구사항
3. 선택한 기술
4. 마치며

1. 블로그를 이전한 동기

저는 이 블로그를 Egloos에서 커스텀 URL(blog.benelog.net)을 설정하여 쓰고 있었습니다. Egloos는 무난한 블로깅 플랫폼입니다. 그러나 개발과 관련된 글을 쓰면서 코드를 편집하기에는 저한테는 Egloos에서 제공하는 에디터가 잘 맞지가 않았습니다. 점점 글을 안 쓰게 되었고, 이 블로그는 갱신되지 않는 옛날 글만 가득하게 되었습니다. 공유할 글이 생길 때는 https://gist.github.com/ 를 이용하기도 했습니다.

이전처럼 가끔씩이라도 블로그에 글을 올리려면 블로그 플랫폼을 바꿔야겠다는 생각이 들었습니다.

2. 요구사항

블로그 플랫폼을 선택하는데 염두에 둔 조건은 아래와 같았습니다.

기존의 포스트의 주소가 동일하게 유지되어야 한다.
- 외부에서 걸린 링크가 깨어지지 않아야한다.
기존 블로그에 달린 댓글을 그대로 옮겨올 수 있어야 한다.
다른 서비스/도구로 다시 옮겨가기가 쉬워야한다.
AsciiDoc으로 포스트를 작성할 수 있어야한다.

3. 선택한 기술

앞의 요구사항을 충족시키는 다음과 같은 서비스/도구들을 선택했습니다.

정적 사이트 생성기 : JBake
컨텐츠 저장소 : GitHub
빌드/배포 : Netlify
댓글 : Disqus
방문자 통계 집계 : Google Analytics

새로운 블로그는 정적 사이트 생성기(Static Site Generator)로 Git 저장소에 있는 AsciiDoc 형식의 컨텐츠를 HTML 파일로 만들어서 배포하는 구조입니다. 덕분에 Egloos로부터의 마이그레이션 작업이 더 수월했고 더 좋은 서비스가 있을 때 쉽게 이전을 할 수 있습니다.

컨텐츠 저장소는 GitHub외에도 Gitlab, Bitbucket 등의 대안이 있고, 컨텐츠 빌드 배포 플랫폼도 다양합니다. 필요하다면 더 좋은 기능이 있는 서비스를 유료로 사용할 수도 있습니다. 컨텐츠 편집기도 여러가지를 사용할 수 있습니다.

사용할 기술을 선택하면서 했던 고민들은 아래에 정리했습니다.

3.1. 정적 사이트 생성기

정적 사이트 생성기로 JBake를 선택한 이유는 다음과 같습니다.

필수요구사항이였던 AsciiDoc 지원
JVM 기반
- 일할 때도 쓰는 환경이라서 문제를 만났을 때 해결하는 시간이 짧고, 직접 고쳐서 쓸 수 있는 가능성도 높습니다.
- Gradle 빌드 구성 등 이미 알고 있는 지식과 결합시키기에도 편했습니다.
JBake로 만들어진 템플릿인 jbake-future-imperfect-template의 편의성
- Disqus와 Google Analytics를 설정파일을 1줄씩을 고쳐서 간단히 적용할 수 있습니다.

비슷한 고민을 하실 분들이 참고할만한 링크들을 정리해봅니다.

정적 사이트 생성기가 정리된 사이트
- https://www.staticgen.com/
- https://staticsitegenerators.net/
AsciiDoc을 지원하는 정적 사이트 생성기
JVM 기반의 정적 사이트 생성기
- Orchid
- OpooPress
- StaGen
- Grain
- nakkaya staic

미래에 JBake를 다른 도구로 교체한다면 아래 2개의 도구를 가장 우선적으로 고려할 예정입니다.

Orchid
- JVM 기반이면서 AsciiDoc 지원
- 현대적인 기술 스택인 JAMstack 활용
- Netlify CMS와 연동됨
Hugo
- 빠른 빌드 성능
- 템플릿, 편집과 배포에 대한 생태계가 풍부함
  - https://gohugo.io/tools/frontends/ 참조
  - Netlify CMS와도 연동됨

3.2. Git 저장소, 빌드/배포

Git 저장소는 많이 쓰이는 GitHub를 무난하게 선택했습니다. AsciiDoc으로 작성된 포스트의 원본은 github/benelog/blog/src/content 에서 이력을 관리합니다.

처음에는 Travis CI와 Githb Page를 활용해서 빌드/배포를 구성하고 커스텀 도메인과 HTTPS를 적용하려고 했었습니다. 그래서 이 블로그는 https://benelog.github.io/blog 로도 접근이 가능합니다.

빌드 스크립트는 build.gradle에서 확인이 가능합니다. Travis CI 설정인 .travis.yml은 아래와 같이 단순합니다.

language: java
script: ./gradlew gitPublishPush

이 작업을 실행하기 위해서는 https://github.com/settings/tokens 에서 발급받은 Personal Access Token을 Tracis CI의 저장소별 설정에서 GRGIT_USER 라는 환경변수로 지정을 해주어야 합니다.

최종적으로는 지원하는 기능이 더 풍부한 Netflify을 이 도메인에는 사용했습니다.

Gradle로 만든 빌드 스크립트를 지정하고 Domain을 지정하고 HTTPS를 적용하는 작업까지 편하게 할 수 있었습니다. Netflify에는 Name 서버 기능까지 있어서 사용하던 Name 서버도 이 서비스로 이전을 했습니다.

Netflify에서는 ./gradlew bake 로 빌드를 합니다.

이 블로그의 JBake 설정으로는 https://blog.benelog.net/904735.html 와 같이 HTML 확장자를 붙인 주소를 씁니다. Egloos의 이전 포스트들은 https://blog.benelog.net/904735 와 같이 HTML 확장자가 없게 되어 있습니다. Netflify와 Github pages에서는 디폴트로 아무런 설정이 없어도 HTML 확장자가 없는 주소를 HTML 확장자가 붙은 주소와 동일하게 취급을 해주어서 URL의 하위 호환성을 쉽게 유지할 수 있었습니다. JBake의 설정으로 HTML 확장자를 제외하는 것도 시도해보았지만, 태그 링크 같은 블로그의 다른 요소의 링크들과 함께 잘 어우러지는 것이 쉽지 않았습니다. 호스팅 서비스 단에서 연결해 해주는 방법이 더 간편하고 부작용이 없어서 최종적으로 그에 의지하도록 했습니다. 즉, 기존 주소 연결을 위해서 아무런 설정도 안 했다는 이야기입니다.

정적 페이지를 호스팅할수 있는 다른 서비스를 찾는다면 아래의 링크들을 참조하실 수 있습니다.

3.3. 편집기

긴 글을 편집할 때는 IntelliJ Community Edition을 사용했습니다. 평소 개발할 때의 편집방식, 단축키와 Git 저장소 연동 방식을 그대로 활용할 수 있습니다. Find in Path (Ctrl + Shift + F) , Replace in Path (Ctrl + Shift + R) 으로 여러 파일에 걸쳐 문자열을 검색하고 치환하는 기능은 마이그레이션 된 컨텐츠를 정리할 때 많은 도움이 되었습니다.

AsciiDoc plugin을 설치하면 HTML으로 렌더링될 모습을 동시에 보면서 편집을 할 수 있고 이미지 파일을 참조할 때는 자동완성이 되기도합니다.

간단한 글을 쓰거나 수정할 때는 Github에서 바로 온라인으로 편집을 할 생각입니다.

참고로 정적 사이트 생성기를 기반으로 온라인 에디터를 제공하는 서비스들은 아래와 같은 것들이 있습니다.

Appernetic.io : Hugo 지원
Forestry : Jekyll, Hugo, Vuepress 지원
Netlify CMS : Hugo, Gatsby, Middleman 등 지원

3.4. 마이그레이션 프로그램

마이그레이션 프로그램의 소스와 사용법은 https://github.com/benelog/egloos-migration/ 을 참고하시기 바랍니다. 이것도 제가 알고 있는 기술들을 활용해서 Kotlin + Spring 으로 작성했습니다.

컨텐츠를 담은 파일을 생성할 때 Kotlin의 문자열 문법이 유용할 것으로 예상해서 언어는 Kotlin을 선택했습니다. 아래와 같은 코드입니다.

    private fun convert(post: EgloosPost): String {
        val asciiDoc = converter.convert(post.content)
        return """= ${post.title}
${post.nick}
${post.createdAt.format(formatter)}
:jbake-type: post
:jbake-status: published
:jbake-tags: ${post.tags}
:idprefix:

$asciiDoc
"""
        // String을 inputStream으로 읽어서쓰니 trimIndent가 안 먹음.
    }
}

그리고 프로그램을 부분적으로 실행하고 검증해보기 위해서 Spring Batch를 썼습니다. 원래 Spring Batch는 대용량 데이터를 메모리에 다 올리지 않고 처리할 때 적합한 프레임워크입니다. 제 블로그의 포스트는 100개 정도로 작은 데이터인데 여기에 Spring Batch를 쓰는 것은 어울리지 않을 수도 있습니다.

그런데, Spring Batch의 ItemReader, ItemProcessor, ItemWriter 구조에 맞춰서 프로그램을 만들고 이 기능 단위로 테스트를 해보면 것이 마이그레이션 프로그램을 만드는 효율적인 방법이라고 판단했습니다. Spring Batch를 쓰지 않았어도 비슷한 기능 단위로 프로그램을 쪼갯을 것 같았기에 이미 익숙한 프레임워크의 인터페이스를 활용했습니다.

부분적인 기능의 테스트들은 https://github.com/benelog/egloos-migration/tree/master/src/test/kotlin/net/benelog/blog/migration/etl 을 참조하실 수 있습니다.

4. 마치며

오랜 숙원 사업이였던 블로그 이전을 마쳐서 뿌듯합니다. 다른 개발자들에게 도움이 될만한 글을 가끔씩이라도 써보겠습니다. 이전에 썼던 글들도 틈틈히 최신화하려고 합니다. 할 작업들은 https://github.com/benelog/blog/issues 에 기록해두고 있습니다.

Robolectric을 활용한 안드로이드 쾌속 테스팅

Mon, 10 Oct 2016 00:00:00 +0000

2014년 8월1일 제9회 오픈 세미나 in 대구 행사에서 한 발표입니다.
예제 코드들은 당시의 Rolbectric의 최신 버전을 기준으로 한 것이라 현재의 최신 버전에서는 그대로 실행되지 않을 수 있습니다.

오늘 발표에서는 테스트 프레임워크인 Robolectric을 사용하면서 실무에서 얻었던 경험을 공유하고자합니다.

먼저 테스트코드란 무엇인지와 안드로이드에서 테스트 작성을 어렵게 하는 난관등을 말씀드리고 Robolectric을 활용하는 방법을 소개하겠습니다.

테스트 코드란?

참석하신 분 중에서 JUnit(제이유닛)에 대해서 한번이라도 들어보신 분은 손을 들어보시겠습니까? 이중에 Junit을 실제로 써보신분은 얼마나 되시나요? Android에서 JUnit으로 테스트를 시도해보신 분은 계신가요? 경험을 하신 정도가 다양하기 때문에 우선 오늘 다룰 테스트 코드란 무엇인지를 한번 정리하고 시작을 하겠습니다.

단순히 말해서 테스트 코드는 '검증’을 위한 코드입니다. 다음은 이미지로딩 라이브러리인 Universal ImageLoader의 소스 중 테스트 코드입니다. github에서 전체소스를 확인하실 수 있습니다.

@Test
public void testSchemeFile() throws Exception {
    String uri = "file://path/on/the/device/1.png";
    Scheme result = Scheme.ofUri(uri);
    Scheme expected = Scheme.FILE;
    assertThat(result).isEqualTo(expected);
}

@Test
public void testSchemeUnknown() throws Exception {
    String uri = "other://image.com/1.png";
    Scheme result = Scheme.ofUri(uri);
    Scheme expected = Scheme.UNKNOWN;
    assertThat(result).isEqualTo(expected);
}

( Android Universal Image Loader의 BaseImageDownloaderTest )

골뱅이 Test가 붙은 애노테이션으로 실행될 코드를 지정하고 assert 구문으로 기대하는 결과를 명시합니다. 이 코드는 uri를 파싱해서 Scheme (스킴)이라는 Enum(이늄)클래스를 만든 결과가 기대대로 FILE이나 UNKNOWN인지를 확인하고 있습니다. 이 코드는 오늘 이야기할 Robolectric으로 만들어졌습니다.

테스트를 도와주는 프레임워크도 굉장히 많습니다. 앞에서도 언급드렸듯이, 테스트를 실행하는데는 JUnit이 가장 많이 쓰입니다. 안드로이드 SDK에서도 이를 바탕으로 한 테스트 프레임워크를 제공하고 있습니다. 그리고 테스트에 쓰이는 가짜 객체를 흔히 목(Mock)이라고 부르는데, Mockito, JMock, PowerMOck과 같은 라이브러리들이 있습니다. 안드로이드를 위한 테스트 프레임워크에도 오늘 다룰 Robolectric을 비롯해 Robotium, Spoon, Robospock 등이 존재합니다.

오늘 설명을 이어가는데 혼동을 줄이기 위해 유의해야할 개념을 몇가지 말씀드리겠습니다.

첫째, JUnit으로 하는 테스트라고 전부 유닛테스트는 아니라는 것입니다. JUnit에 유닛(Unit)이라는 이름이 들어가서 생기는 혼동입니다. 테스트 Functional 테스트 (혹은 시스템 테스트)도 JUnit으로 작성하는 경우도 많습니다. 오늘 발표에서는 이를 엄밀히 구분하지는 않고 폭넓게 '테스트 코드’라는 말로만 칭하겠습니다.

둘째, 테스트 코드를 작성하는 작업을 'TDD를 한다’라고 한마디로 말하기는 어렵다는 것입니다. TDD는 테스트를 작성하는 하나의 방식입니다. TDD 기법은 테스트를 먼저 작성하고, 테스트를 통과시키는 코드를 구현한 후 리팩토링을 하는 절차를 거칩니다. 오늘 발표에서는 TDD 같은 절차와 상관없이 테스트를 작성하는 라이브러리 활용법에 대해서 주로 말씀드리겠습니다.

왜 이런 테스트를 만드는지에 대한 의문을 가지실분도 있을 듯합니다. 간단히 설명드리면, 그 이유는 다음과 같습니다.

첫째, 디버깅 편의성을 위해서입니다. 테스트 코드 작성에 능숙해지면 실제 어플리케이션을 실행하고 수동으로 반복 테스트하는것보다 훨씬 빠르고 정교하게 내가 짠 코드의 동작을 확인하고 오류를 수정할 수 있습니다.

둘째, 설계를 개선하기 위해서입니다. 테스트 하기에 쉬운 구조의 코드는 역할과 책임이 잘 나누어진 코드입니다. 그런 코드는 재활용하고 기능을 추가하거나 버그를 발견하기에도 편합니다. 테스트를 의식하면서 개발을 하면 그런 구조의 코드를 작성하는데 도움이 됩니다.

셋째, 테스트 자체가 동작하는 예제이자 명세가 됩니다. 다른 사람이 어플리케이션이나 라이브러리의 전체를 실행시키지 않아도 코드가 실행된 결과를 이해할 수 있습니다.

넷째, 반복적으로 수행할 회귀테스트를 자동화합니다. 앞으로 기능을 추가하거나 코드를 개선할 때 든든한 버팀목이 되고 시간을 아껴줍니다.

다섯째, 개발 작업에 더 집중하게 해줍니다. 테스트를 통과한다는 명확한 목표가 있고, 이를 빠른 시점에 명확하고 신호로 알려주고 작업의 난이도와 간격은 스스로 적당하게 조절할수 있습니다. 심리학에서 말하는 몰입경험의 조건과 일치합니다.

안드로이드 테스트의 장벽

그렇다면 이런 테스트의 장점을 안드로이드에서도 행복하게 누릴수가 있을까요? 불행히도 많은 장벽이 있다는 것을 경험했습니다. 그 이유를 몇가지 나누어서 말씀드리겠습니다.

첫째, Mock을 쓰기 어려운 기본 프레임워크 구조입니다. 안드로이드에서 굉장히 많이 쓰이는 getViewById, getSystemService 같은 코드는 상위클래스에 있는 메서드를 호출하는 구조입니다. 이런 형태는 가짜 클래스인 Mock을 주입하기가 어렵습니다.

둘째, 빈약한 기본 Mock클래스입니다. android.test.mock 패캐지 아래에는 MockContext, MockApplication, MockResource 등의 많은 클래스들이 있지만, 이들은 UnsupportedOperationException을 던지는 껍데기일 뿐입니다. 필요한 동작은 다음과 같이 직접 override해서 구현해야 합니다.

static public class MockServiceContext extends MockContext {
    @Overrride
    public getSystemService(String name){
        ……
    }
}

셋째, 기본적으로 제공되는 Instrumentation Test를 쓰는것도 배우기가 쉽지않습니다. 예를 들면 Activity를 테스트할때 ActivityTestCase, ActivityUnitTestCase, ActivityInstrumentationTestCase2의 세 가지 클래스 중 어느것을 써야할까를 하려면 많은 것을 알고 있어야합니다. 그리고 ActivityUnitTestCase에서 Dialog생성 등에 Event가 전달되면 BadToken Exception이 발생한다거나, ActivityInstrumentationTestCase2에서 Dialog 객체를 생성 후 dismiss() 메서드를 호출하지 않으면 leak window Exception이 발생하는등 부딛히는 예외상황도 많습니다.

넷째, UI 테스트 본연의 어려움이 있습니다. 안드로이드 코드는 역할상 UI 생성과 이벤트를 다루는 코드의 비중이 높습니다. 이는 웹어플리케이션 등 다른 플랫폼에서도 테스트하기 어려운 분야입니다. UI 객체의 속성은 자주 바뀌고 익명 클래스 등을 통해서 처리되는 이벤트는 Mock 객체로 바꾸고 추적하기가 어렵습니다.

다섯째, 느린 테스트 실행 속도입니다. 단 한줄을 고쳐도 패키징 → 설치 → 실행 싸이클을 거칩니다. 이 부분이 테스트의 장점을 다 말아먹는 가장 치명적인 단점입니다. 요즘 PC나 단말이 많이 빨라졌고 Genymotion같은 빠른 에뮬레이터도 활용할 수 있어서 많이 나아졌지만, 그래도 실행싸이클의 특성상 개선에 한계가 있습니다.

Robolectric 활용법

저도 Android의 기본 Instrutation테스트를 시도해보다 앞에서 말씀드린 이유로 많은 좌절을 느꼈습니다. 그래서 이를 개선하는 기술로 Robolecric을 시도해봤고, 어느정도 노하우를 쌓았습니다.

Robolectric은 배포, 설치가 필요없도록 PC의 JVM에서 안드로이드 코드를 실행해줍니다. 아마 한두번쯤을 만나셨을 메시지일듯한데, 이클립스 같은 IDE안에서 안드로이드 코드를 바로 돌리면 'java.lang.RuntimeException: Stub!?' 에러가 발생합니다. Robolectric은 Android SDK가 제공하는 클래스를 가로채어서 서 JVM에서 ANdroid 코드를 실행해도 저런 에러가 나지 않는 가짜코드를 실행합니다.

이 프로젝트는 Github에서 활발하게 개발되고 있습니다. ActionbarSherlock으로 유명한 JakeWharton도 주요 커미터입니다. 174명의 기여자가 참여했고, 저도 그 174명 중의 한명이기도 합니다.

릴리즈 노트를 보시면 아시겠지만, 이 프레임워크는 꾸준히 발전하고 있습니다. 최근에는 KitKat에 추가된 API를 지원하는 작업도 진행되고 있습니다.

그리고 Android를 만든 구글에서도 Robolectric의 1점대의 버전을 자체 포크해서 쓴 흔적이 Android 코드저장소에 남아있습니다. 이렇게 포크로 그치지 않고 구글에서도 같이 Robolectric 2점대 버전의 개발에 참여했으면 더 좋지 않을까 하는 아쉬움이 남습니다.

물론 Dalvik이나 Art같은 Android 본연의 환경이 아닌 JVM에서 실행되다는 점 때문에 이 라이브러리의 한계는 있습니다. 그리고 Android SDK의 모든 영역을 SDK 출시 즉시에 제공하지도 못합니다. 그렇지만 Robolectric의 한계를 잘 인식하고 효율적으로 테스트할수 있는 부분에 집중을 한다면 앱이나 라이브러리를 개발하는데 많은 도움이 됩니다.

몇가지 대표적인 사용사례를 들어보겠습니다.

로그를 System.out으로 출력하기

우선 LogCat으로 출력되는 로그를 Log를 System.out으로 출력하려면 아래와 같이 구현을 하면 됩니다.

@RunWith(RobolectricTestRunner.class)
@Config(manifest = Config.NONE)
public class SystemUtilsTest {
    @Before
    public void setUp() {
        ShadowLog.stream = System.out;
    }

android.util.Log를 이용한 클래스를 JVM에서 바로 실행가능합니다. java.lang, java.util등 기본 JDK에도 동일한 이름으로 존재하는 클래스를 주로 쓰는 유틸리티 클래스를 만들어도 Log를 찍는 코드가 중간에 들어가있으면 이를 Dalvik에서만 실행해야했습니다. Robolect은 그런 코드도 JVM에서 실행되도록 하며 위와 같이 ShawdowLog클래스에 stream속성을 System.out으로 지정하면 System.out.println으로 찍는것과 유사하게 PC의 표준출력에서 로그메시지를 확인할수 있습니다.

단말기의 정보 변경

종종 Build.VERSION.SDK_INT 변수의 값을 참조해서 SDK의 버전별로 분기처리를 해야하는 코드가 있습니다. Robolectric에서는 이런 상수값도 아래와 같이 조작을 할 수 있습니다.

	Robolectric.Reflection.setFinalStaticField(Build.VERSION.class, "SDK_INT", Build.VERSION_CODES.JELLY_BEAN);

이런 기법은 Http호출을 하는 클라이언트에서 userAgent에 단말의 정보를 조합해서 넣어하는 경우를 테스트하는 경우에 유용하게 썼습니다.

Activity 클래스는 ActivityController라는 클래스를 통해 생성할 수 있습니다. 아래 코드는 스크린밝기를 지정하는 유틸리티는 테스트하는 코드입니다. 이 소스코드는 github에서 전체를 확인해보실수 있습니다.

@Test
public void shouldChangeScreenBrightness() {
    TestActivity activity = createActivity(TestActivity.class);
    float brightness = 0.5f;
    ScreenUtils.setScreenBrightness(activity, brightness);

    LayoutParams lp = activity.getWindow().getAttributes();

    assertThat(lp.screenBrightness, is(brightness));
}

private <T extends Activity> T createActivity(Class<T> activityClass) {
        ActivityController<T> controller = Robolectric.buildActivity(activityClass);
        controller.create();
        return controller.get();
}

( ScreenUtilsTest )

DisplayMetricsDensity 속성은 직접 org.robolectric.Robolectric의 set메서드로 지정할 수 있습니다. 아래는 DP와 Pixel을 전환하는 코드를 예제로 들어봤습니다.

@RunWith(RobolectricTestRunner.class)
@Config(manifest = Config.NONE)
public class PixelUtilsTest {
    private Context context;

    @Before
    public void setUp() {
        ShadowLog.stream = System.out;
        this.context = Robolectric.application;
    }

    @Test
    public void shouldGetDpFromPixel(){
        Robolectric.setDisplayMetricsDensity(1.5f);
        int dp = PixelUtils.getDpFromPixel(context, 50);
        assertThat(dp, is(33));
}

( PixelUtilsTest )

이 클래스의 Setter 메소드를 살펴보면 그밖에도 다양하게 테스트를 위한 가짜 객체를 설정하는 기능을 찾으실 수 있습니다.

단말의 SDK 정보를 원하는 값으로

System 서비스의 결과를 원하는 값으로

몇가지 예를 들었는데, Robolectric을 결국 어떻게 활용할 것이 좋을까요? JVM에서 테스트해도 동일한 결과를 보장하는 문자열, 날짜 처리, 프로토콜 파싱 영역에서 이득이 많습니다. 주로java.lang, java.util , java.io 패키지가 다루는 영역에 우선 집중하기는 것이 좋습니다. 처음부터 Activity, Fragment같은 UI영역까지 포함한 통합 테스트에 너무 많은 기대를 걸면 오히려 어려울 수 있습니다. Utility 클래스부터 우선 적용해보면서 점점 영역을 넓혀가시기를 권장드립니다.

Robolectric의 버전 2.3부터는 실제 Sqlite 구현체를 이용하기 시작했습니다. 이 버전부터는 DB관련 테스트도 JVM에서 시도해볼만합니다.

당연히 Robolectric으로 테스트를 포기할 영역도 많습니다. 노하우가 쌓이면 이를 의식해서 테스트의 이득이 높은 영역을 분리해서 설계할 수 있습니다. 이는 재활용/기능 추가/버그 발견에도 좋은 구조가 될것입니다.

코드 기여

계속 발전하고 있는 프레임워크이기 때문에 Robolectric에는 미비한 기능도 많습니다. 테스트 대상인 ANdroid 자체가 계속 변화하고 있어서 더욱 그렇기도 합니다. Robolectric은 Github에 올라간 오픈소스 프로젝트이기 때문에 누구나 코드 기여를 할 수 있습니다. 저도 3번 정도 Pull request를 날렸는데 그 경험을 공유해보겠습니다.

처음에는 Javadoc의 오타부터 수정해봤습니다. Pull request 번호 804번에서는 ShadowCookieManager의 javadoc에서 TelephonyManager로 적힌 단어를 CookieManager 로 수정했습니다. 주석을 한번이라도 본 사람이면 할 수 있는 아주 단순한 수정이였습니다.

한번 해보고나니 조금 더 어려운 기여를 해보고 싶어졌습니다. 프로젝트를 진행하다가 Robolectric의 ShawdowCookieManager가 실제 android의 CookieManager의 동작과는 많이 다르다는 것을 발견했습니다. Robolectric 2.2까지는 단순히 HashMap에 key,value를 저장하는 수준이였습니다. Expires같은 속성이 들어가면 실제 SDK와 다르게 동작함. 아래 코드는 테스트가 실패합니다.

	cookieManager.setCookie(httpUrl, "name=value; Expires=Wed, 11 Jul 2035 08:12:26 GMT");
	assertThat(cookieManager.getCookie(httpUrl)).isEqualTo("name=value");

Pull request 번호 853번에서는 이를 실제와 비슷하게 재구현했습니다.

이 과정이 흥미로웠기 때문에 잠시 설명드리면, 먼저 실제 단말에서의 동작을 AndroidTestCase로 확인했습니다. ( https://gist.github.com/benelog/7655764 )

예를 들면 아래와 같이 removeExpireCookie를 호출했을 때 Expires값이 지나간 쿠키값은 삭제하는 동작을 확인해봤습니다.

CookieManager cookieManager;

public void setUp() {
    Context context = getContext();
    CookieSyncManager.createInstance(context);
    cookieManager = CookieManager.getInstance();
    cookieManager.removeAllCookie();
}

public void testRemoveExpiredCookie() {
    cookieManager.setCookie(url, "name=value; Expires=Wed, 11 Jul 2035 10:18:14 GMT");
    cookieManager.setCookie(url, "name2=value2; Expires=Wed, 13 Jul 2011 10:18:14 GMT");
    cookieManager.removeExpiredCookie();
    assertEquals("name=value", cookieManager.getCookie(url));
}

그리고 유사한 테스트 케이스를 Robolectric으로 작성했습니다.

CookieManager cookieManager = Robolectric.newInstanceOf(CookieManager.class);

@Test
public void shouldRemoveExpiredCookie() {
    cookieManager.setCookie(url, "name=value; Expires=Wed, 11 Jul 2035 10:18:14 GMT");
    cookieManager.setCookie(url, "name2=value2; Expires=Wed, 13 Jul 2011 10:18:14 GMT");
    cookieManager.removeExpiredCookie();
    assertThat(cookieManager.getCookie(url)).isEqualTo("name=value");
}

위의 테스트를 통과시키는 ShadowCookieManager를 구현하여 Pull request를 날렸습니다. Robolectric에 들어갈 코드를 Robolecric으로 검증한 셈입니다.

마지막으로 ShawdowProcess 구현한 코드입니다. 이 클래스로 android.os.Process.myPid()에서 나오는 값을 가짜로 지정할 수 있습니다.

@Test
public void shouldBeTrueWhenThisContextIsForeground(){
    int pid = 3;
    ShadowProcess.setPid(pid);
    createRunningAppProcessInfo(pid);
    boolean foreground = ActivityUtils.isContextForeground(context);
    assertThat(foreground, is(true));
}

구글의 Android 소스 저장소의 Robolectric fork판에도 유사한 클래스가 있습니다.

이 클래스는 Pull request 861번 으로 던져서 반영되었습니다. 중간에 이 클래스가 없으면 어떻게 되냐고 물어보길래 자세히 설명하려고 노력했던 과정이 재미있었습니다.

코드 기여에 유의할 점도 있습니다. Merge를 받아줄 주요 커미터들이 작업하기 편하게 Pull request를 하는 브랜치는 계속 master의 최신 commit으로 맞춰서 rebase를 해줘야합니다. 제가 한 요청들도 다른 요청에 밀려서 merge가 안 되고 있었는데, 계속적으로 rebase를 하고 있으니 그 정성을 봐서도 merge를 해준것 같기도합니다.

그외에는 컨티리뷰션 가이드를 참조하시면 됩니다. 대표적인 내용을 소개드리면, Indent에는 탭대신 공백 2칸을 쓰는등 컨벤션을 맞춰야하고, 적절한 테스트 코드를 같이 commit을 해야합니다. 앞에서 나온 CookieManager 사례를 참고하셔도 좋습니다.

정리

정리하자면 다음과 같습니다. Android 테스트는 난관이 많습니다. 특히 느린 실행속도가 치명적입니다. 여기서 Robolectric이 도움이 됩니다. 우선은 문자열, API 파싱. 유틸리티등 테스트하기 쉬운 영역부터 시도해볼만하고, 궁극적으로는 설계개선을 고민하는 것이 좋습니다. 코드 기여도 어렵지 않은, 기여자에게 관대한 프로젝트입니다.

오늘 발표와 관련해서 helloworld 블로그에 게시된 Android에서 @Inject, @Test글도 참고하실만합니다.

발표자료

https://www.slideshare.net/deview/5robolectric

[D2 오픈세미나]5.robolectric 안드로이드 테스팅 from NAVER D2

'네이버를 만든 기술, 읽으면서 배운다 - 자바편' 출간

Wed, 25 Feb 2015 00:00:00 +0000

( 이미지 출처 : http://wikibook.co.kr/how-naver-works-java/ )

네이버의 개발자 블로그인 헬로월드 ( http://helloworld.naver.com )에 공개되었던 글을 중심으로 책이 출판됩니다. 자바의 핵심영역을 다룬 17개의 글을 묶었습니다. 출판을 위해 새로 쓰여진 글도 있고, 사내에서만 공유되었던 글들도 재발굴했고, 이미 공개된 글도 최신 내용을 반영해 다듬었습니다.

자바개발의 A부터 Z까지 다 다루는 책은 아니지만, API를 설계할 때 고민해야할 요소, 반복해서 문제를 겪을 만한 부분, 장애 해결/분석 경험의 액기스를 담았습니다. 네이버의 주요 서비스를 개발한 담당자가 문제를 해결한 사례를 정리한 글도 있고, 플랫폼개발, 기술 지원조직인 웹플랫폼개발랩, 성능엔지니어링랩, 생산성혁신랩의 개발자들이 반복해서 전파해야할 지식을 효율적으로 공유하기 위해 쓴 글도 있습니다.

처음에는 조엘이 엄선한 소프트웨어 블로그 베스트 29선처럼, 온라인의 글을 오프라인으로 옮기는 성격의 책이 될것이라고 예상했었습니다. 그런데 생각보다 출판에 이르기까지는 많은 노력이 들어갔습니다. 글이 쓰여진 시점이 제 각각 이였기 때문에 현시점에 맞춰서 고칠 내용도 많았고, 사내에서만 공유되던 글은 서비스명, 담당자명, 부서명등이 들어간 문장은 바꿔야했습니다. 다양한 저자가 쓴 글이였지만 용어를 일관되게 맞추려고 노력했습니다. 기술문서팀의 담당자분께서 많은 수고를 해주셨습니다.

오류가 있어도 바로 고치면 되는 인터넷 페이지가 아닌, 종이로 찍혀나오는 책에 들어갈 글을 쓰는 부담은 생각보다 컸습니다. 이미 공개된 글도 여러 번 더 신중하게 검토를 했습니다. 블로그에 올릴 때는 '아직 정확한 답은 찾지 못했다.' 정도로 대충 쓰고 넘어갔었던, 타임존데이터베이스에서 우리나라 시간대 정보가 역사적 사실과 맞지 않았던 문제를 더 깊이 파악한 것이 그 예입니다. 책을 쓰면서 IANA ( Internet Assigned Numbers Authority)에 이 오류를 수정한 패치를 전달해서 JDK에도 반영되었습니다.

결국 종이로 찍혀나오게 되었으니, Helloworld의 글들을 좋아하셨던 많은 분들에게 소장할 가치가 있는 책으로 남았으면 좋겠습니다. 그 바램을 담아서 서문와 아래와 같이 적었습니다.

앞으로 자바 10, 자바 11이 나오고 시간이 흐르면 더 최신 정보를 담은 책이 나올 것이다. 그래도 이 시대의 자바 기술과 네이버에서 일한 개발자의 노력을 담은 타입캡슐이 돼 오랜 시간이 지난 후에도 누군가의 책장에 이 책이 꽂혀 있으면 좋겠다. 그것이 인터넷에 있던 글을 종이로 옮긴 가장 큰 의미가 아닐까 생각한다.

이 책이 호응이 얻는다면, 바쁜 시간을 쪼개어서 글을 썼던 저자에게 응원이 되고, 예비 저자에게도 용기를 주어 앞으로 더 좋은 글을 외부로 공개하는데 힘을 보탤 것이라 믿습니다.

글 하나하나가 독립적이기 때문에 관심있는 주제부터 읽으셔도 되지만, 가장 겉으로 들어난 영역인 API부터 시작해서 JVM내부, 분석도구, Garbarge Collection, DB연결까지 이어지는, 더 안쪽과 JVM 뒤쪽의 영역으로 흐름이 이어지도록 목차를 잡았습니다.

1부 : 자바의 API 이해하기

01장: 자바의 날짜와 시간 API - 정상혁
02장: 자바의 HashMap은 어떻게 작동하는가? - 송기선
03장: 자바에서 외부 프로세스를 실행할 때 - 정상혁
04장: 람다가 이끌어 갈 모던 자바 - 정상혁

2부 : 문제 분석과 사례

05장: JVM 이해하기 - 박세훈
06장: 스레드 덤프 분석하기 - 구태진
07장: 자바 애플리케이션 분석을 위한 BTrace - 이상민, 정상혁
08장: 하나의 메모리 누수를 잡기까지 - 김민수, 김택수
09장: 고맙다 JVM, 사과해라 JVM 크래시 - 강경태

3부 : 가비지 컬렉션

10장: 자바 가비지 컬렉션의 작동 과정 - 이상민
11장: 가비지 컬렉션 모니터링 방법 - 이상민, 송기선
12장: 가비지 컬렉션 튜닝 - 이상민
13장: 자바의 Reference 클래스와 가비지 컬렉션 - 박세훈
14장: 가비지 컬렉션과 Statement Pool - 최동순
15장: 아파치 MaxClients와 톰캣의 Major GC - 최동순

4부 : 데이터베이스 연결 설정

16장: JDBC의 타임아웃 이해하기 - 강운덕
17장: Commons DBCP 이해하기 - 최동순, 강운덕, 정상혁

시간대 DB에서 우리나라 시간의 오류

Mon, 3 Nov 2014 00:00:00 +0000

변경이력

2015/02/13
- tzdata2014j에 반영 사실 갱신
- 북한의 시간대에 대한 진행 상황 설명

2014년 2월, 회사의 기술블로그인 http://helloworld.naver.com에 Java의 날짜와 시간 API이라는 글을 기고한 적이 있습니다. 그 글을 쓰던 도중에 우리나라의 타임존 데이터에 대한 몇가지 의문을 가지게 되었지만 완벽히 해결하지는 못했었습니다.

얼마 전에 이 문제를 좀 더 깊이 파악을 해보았고, 원천 데이터인 IANA Timezone 데이터베이스에 패치를 전달해서 반영되었습니다. 조사과정에서 1920년대부터 1999년까지의 과거 뉴스를 조회하는 네이버의 뉴스라이브러리 서비스 ( http://newslibrary.naver.com/) 가 큰 도움이 되었습니다.

이 오류는 tzdata2014j에 반영되고, 이를 참조하는 Java, Android, FreeBSD에서도 2014년 11월경에 반영되었습니다.

tzdata2014j의 릴리즈노트
JDK-8064560 : Open JDK의 반영. TZUpdater 1.4.10가 오류가 수정된 이 데이터를 참조하고, JDK 8u40, JDK 7u80, JDK 7u75등 여러 버전에 백포트 패치
Android에 반영 Commit
FreeBSD에 반영 Commit

플랫폼별로 반영시점은 다르겠지만, 다른 OS에서 이를 반영할 것으로 예상합니다.

현시점에서는 드물것 같지만, 혹시 우리나라의 1912 ~ 1980년대의 섬머타임과 시간대 변경에 영향받은 프로그램을 만드셨던 분이 있다면 참고로 알아둘만 합니다.

섬머타임의 오류 발견

처음 발견한 오류는 1988년의 섬머타임이 시작된 시간이였습니다. 아래 자료에 따르면 이 해의 섬머타임은 5월 8일 새벽 2시부터 시작되었습니다.

'한국 표준시', 위키백과, http://ko.wikipedia.org/wiki/한국_표준시
'내일부터 서머타임… 새벽2시를 3시로', 매일경제, 1988. 5. 7.

그러나 Java프로그램으로는 1988년 5월 7일 23시의 1시간 후가 5월8일 1시인것으로 나와서 00시를 기점으로 섬머타임이 적용되어 있습니다. 아래 테스트는 아직 오류수정이 정식 릴리즈되지 않은 지금 시점에서는 통과합니다.

@Test
public void shouldGetAfterOneHour() {
    TimeZone seoul = TimeZone.getTimeZone("Asia/Seoul");
    Calendar calendar = Calendar.getInstance(seoul);
    calendar.set(1988, Calendar.MAY , 7, 23, 0);
    String pattern = "yyyy.MM.dd HH:mm";
    String theTime = toString(calendar, pattern, seoul);
    assertThat(theTime).isEqualTo("1988.05.07 23:00");
    calendar.add(Calendar.HOUR_OF_DAY, 1);
    String after1Hour = toString(calendar, pattern, seoul);
    assertThat(after1Hour).isEqualTo("1988.05.08 01:00");}

(자세한 설명은 Java의 날짜와 시간 API,전체 소스는 OldJdkDateTest.java) 참조)

시간대 변경에 대한 정보는 윈도우즈, 안드로이드, OSX, 리눅스, Java, 오라클 등 거의 모든 플랫폼에서 Internet Assigned Numbers Authority (IANA)라는 조직에서 관리하는 시간대 데이터베이스를 원천으로 참조합니다. 처음에는 이 타임존 데이터베이스의 오류일지 아니면 다른 이유가 있을지 확신을 하지 못했습니다.

오류의 역사

Helloworld에 글이 나간 후에 이응준님께서 알려주셔서 우리나라의 섬머타임을 기록한 사람이 누구인지 알게 되었습니다. Github에 올라간 https://github.com/eggert/tz의 커밋로그를 바탕으로 이를 자세히 분석해봤습니다.

우리나라의 섬머타임에 대한 기록은 'Arthur David Olson’의 1988년 1월 3일의 커밋에 아래와 같이 처음으로 등장합니다.

# Republic of Korea. According to someone at the Korean Times in San Francisco,# Daylight Savings Time was not observed until 1987. He did not know# at what time of day DST starts or ends.# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/SRule ROK 1987 max - May Sun<=14 2:00 1:00 DRule ROK 1987 max - Oct Sun<=14 3:00 0 S

주석을 봐서는 섬머타임의 시작시기도 정확히 몰랐던 사람의 증언을 참고로 한 듯합니다. 그리고 1987년 이전에는 우리나라에 섬머타임이 없었다는 이야기도 사실과 다릅니다.

위의 코드로는 1987년부터 섬머타임이 계속되고 있다고 정의되었습니다. 1987,1988년에 우리나라에서 섬머타임이 실행되었으니 commit시점에서는 적어도 이 년도에 대해서는 맞는 데이터였습니다.

그러나 1988년 이후로도 우리나라에서는 섬머타임이 계속되어 있는것처럼 한동안 유지가 됩니다. 1993년에 이르러서야 이 데이터는 정정됩니다.

1993년 11월23일의 커밋으로 다음의 날짜가 다시 반영됩니다.

Rule ROK 1960 only - May 15 0:00 1:00 DRule ROK 1960 only - Sep 13 0:00 0 SRule ROK 1987 1988 - May Sun<=14 0:00 1:00 DRule ROK 1987 1988 - Oct Sun<=14 0:00 0 S

이 commit은 아래 2가지 오류를 담고 있습니다.

1987~1988년도의 섬머타임은 시작시간 2시부터인데 0시부터로 표기되었습니다.
새로 추가한 1960년의 섬머타임은 실제로는 5월1일부터 9월18일까지였습니다. 위키페디아와 옛날신문의 자료가 일치합니다.
썸머타임 1일부터, 동아일보, 1960.05.01
없어지는 섬머타임, 동아일보, 1960.09.18

이외에도 이 Commit은 우리나라 시간대 변경에 대한 많은 오류를 포함하고 있습니다. 섬머타임 외의 오류는 나중에 다시 살펴보도록 하겠습니다.

주석으로 볼때 위의 1993년 11월23일의 커밋은 Thomas G. Shanks의 The International Atlas의 제3판에 있는 내용을 반영한것을 보입니다. 주석에도 아래와 같이 미국이외의 타임존 정보는 별다른 명시가 없다면 이 책을 참고로 했다고 나옵니다.

# A good source for time zone historical data outside the U.S. is# Thomas G. Shanks, The International Atlas (3rd edition),# San Diego: ACS Publications, Inc. (1991).# Except where otherwise noted, it is the source for the data below.

지금 이 책은 6판까지 나와있고, 이후의 commit에서도 5판,6판을 따라서 수정한 내용이 보입니다.

그 이후 2012년 7월 18일의 커밋이 한번더 섬머타임 데이터를 수정했습니다. 1987년, 1988년의 표현규칙을 바꾼것으로 근본적인 오류가 수정되지는 않았습니다.

Rule ROK 1987 1988 - May Sun>=8    0:00 1:00 DRule ROK 1987 1988 - Oct Sun>=8    0:00 0 S

1960년 이전의 데이터까지 포함한다면, IANA 데이터베이스에서 우리나라의 섬머타임이 제대로 반영된 적은 한번도 없었던 것입니다.

패치 전달와 반영

조사결과 섬머타임의 오류를 확신하고, 이를 수정하는 패치파일을 직접 만들어서 시간대데이터를 관리하는 IANA에 메일(tz@iana.org )로 보냈습니다. 여러 옛날 신문들을 많이 찾아본결과 위키페이디아의 '한국표준시’페이지의 정보가 신뢰할만하다고 판단했습니다.

1948.06.01. 00:00 ~ 1948.09.13. 00:00
1949.04.03. 00:00 ~ 1949.09.11. 00:00
1950.04.01. 00:00 ~ 1950.09.10. 00:00
1951.05.06. 00:00 ~ 1951.09.09. 00:00
1955.05.05. 00:00 ~ 1955.09.09. 00:00
1956.05.20. 00:00 ~ 1956.09.30. 00:00
1957.05.05. 00:00 ~ 1957.09.22. 00:00
1958.05.04. 00:00 ~ 1958.09.21. 00:00
1959.05.03. 00:00 ~ 1959.09.20. 00:00
1960.05.01. 00:00 ~ 1960.09.18. 00:00
1987.05.10. 02:00 ~ 1987.10.11. 03:00
1988.05.08. 02:00 ~ 1988.10.09. 03:00

예를 들면 1948년의 정보는 1948년 6월1일자 동아일보 기사에서 확인할수 있습니다.

패치절차는 시간대데이터베이스의 소스에 있는 CONTRIBUTING파일에 잘 설명되어 있습니다. 정식절차와는 별도로 github에도 올려봤습니다. ( https://github.com/eggert/tz/pull/9 )

얼마 후 제가 보낸 패치를 포함하는 2014년 10월30일의 Commit이 올라왔습니다. 'Unreleased, experimental changes’라는 문구가 포함되었지만, 이를 뒤집는 증거가 발견되지 않는한 정식릴리즈에 포함될 것으로 예상합니다.

IANA쪽에서 이 수정을 받아준 Paul Eggert은 제가 섬머타임 변경의 근거로 보낸 위키페이디아의 '한국표준시’페이지를 보고 우리나라의 시간대 변경시점에 대한 오류도 추가로 수정을 했습니다.

시간대 변경시점의 오류

처음에 보낸 패치에는 포함되지 못했지만 섬머타임 외에도 우리나라 시간대 변경에 대한 의문도 있었습니다. "yyyy.MM.dd HH:mm (Z)"을 포멧으로 해서, 1954년, 1961년, 1968년의 특정시간과 그 때와 UTC와의 차이를 출력해보면, 아래와 같이 나옵니다. (소스는 TimeZoneChangePoint.java 참조 )

1954.03.20 22:59 (+0900)1954.03.20 23:00 (+0800)1961.08.09 23:59 (+0800)1961.08.10 00:30 (+0830)1968.09.30 23:59 (+0830)1968.10.01 00:30 (+0900)

이 소스의 결과는 1993년 11월23일의 수정 때 반영된 타임존DB의 정보에 의지합니다. 위의 결과라면 우리나라의 시간대 변경시점은 아래와 같습니다.

1954년 : UTC+0900 → UTC+0800
1961년 : UTC+0800 → UTC+0830
1968년 : UTC+0830 → UTC+090

그러나 과거 신문에서 확인한 역사적 사실은 아래와 같습니다. 위키페디아의 내용과도 일치합니다.

1954년 : UTC+0900 → UTC+0830
- '오늘은 춘분 시간도 광복', 동아일보, 1954.03.21
- '입일일은 춘분, 표준시간광복의 날'. 경향신문, 1954.03.21
1961년 : UTC+0830 → UTC+0900
- '구일밤 통금 싸이렌 불면 시계 바늘을 12시반으로, 경향신문, 1961.8.09
- '새 표준자오선이란?', 동아일보, 1961.08.10

즉 현재의 시간대데이터로는 1961~1968년사이는 아예 우리나라의 시간대가 잘못 계산되어 나온다는 것입니다.

이 부분은 섬머타임이 반영되는 것을 보고 조금 더 조사를 한 후에 추가 패치를 하려고 생각했었습니다. 기존 데이터가 그렇게까지 다 틀렸다는 것이 믿기가 어려웠고, 우리나라의 시간대 정보에 대한 거의 모든것을 한번에 고치기가 조심스러웠기 때문입니다. 그런데 Paul Eggert가 먼저 적극적으로 반영해주었습니다.

Paul Eggert는 이와 더불어 위키페이디아의 '한국표준시’페이지에 따르면 1912년에 UTC+0900로 변경이 있었는데, 1910년에도 같은 변경이 있었던것으로 기록된 부분이 혼동된다며 이를 명확히 확인해주었다면 좋겠다고 했습니다. 위키페디아에서 1910년도 변경의 근거로 든 '여적 표준시 변경, 경향신문, 2000-08-14.'라는 자료는 현재 인터넷으로 찾을 수 없어서 대신 여러 기록을 확인해보았습니다. 많은 자료가 1912년에 변경되었다는것으로 일치했고, 1910년도의 변경기록은 누군가가 한일합방 연도와 혼동한것이 아닐까하는 의견을 답장으로 보냈습니다.

북한의 타임존 데이터

또하나 의문이였던 점은 1993년 11월23일의 커밋으로 북한의 시간대가 1961년에 UTC+0900으로 변경되었다는 내용입니다. 그때 남한 쪽에서 시간대 변경이 있었는데, 당시 신문을 다 찾아봐도 남북한이 동시에 추진을 했다는 내용은 없었습니다.

Paul Eggert도 이를 이상하게 여겨 일단은 북한쪽은 1940년대 이후로 변화가 없는것으로 가정했다고 합니다.

While we’re in the neighborhood, it’s completely implausible that Pyongyang faithfully mimicked Seoul time during and after the Korean war (which is what Shanks says), so let’s remove that obviously-bogus guess.

저도 답장으로 북한쪽의 변경에 대한 의미있는 기록을 찾지 못했고, Paul Eggert의 가정에 동의한다는 내용을 보냈습니다.

tzdata2014j버전대로라면 1954년과 1961년 사이 서울과 평양사이에는 30분의 시차가 존재합니다. 이 것이 역사적 사실과 부합하는지 알아내려고 계속 알아보고 있는 중입니다. 현재 한국표준과학연구원과 통일부, 국정원에 문의를 했지만, 의미있는 답변은 받지 못했습니다. 특히 친절히 전화까지 해주신 통일부 직원분께 감사드립니다.

1954년과 1961년 사이에 남파/북파 간첩활동을 한 분이 있다면, 그 사실을 정확히 알고 있을 것 같기도 합니다. 그런데 과거 간첩사건을 조사해보니 생각보다 간첩들의 나이가 많아서 지금까지 생존한 분이 계실 가능성은 별로 없어보입니다.

마치며

재미있게도 위의 오류를 신고한지 얼마뒤인 2014년 11월 1일에 'Be less enthusiastic about Shanks and clarify UT vs UTC. '라는 제목으로 commit이 올라왔습니다. 우리나라 시간대에 대한 잘못된 정보의 출처였던 Shanks의 저서에 많은 오류가 있음을 지적하는 주석이 들어갔습니다. 아시아, 아프리카, 오스트랄라시아, 유럽 등 지역별 정보를 기록하는 모든 파일에 'A good source for time zone historical data outside the U.S. is..'라는 내용이 삭제되고, 'unfortunately this book contains many errors and cites no sources.'라는 문장이 추가되었습니다.

저의 신고가 영향을 준것인지는 알 수 없지만, 이 주석을 기점으로 기존의 데이터를 조금 더 의심하는 계기가 될 것으로 기대합니다.

비록 오래전 과거데이터라서 지금 시점의 영향성은 적지만, 믿음직한 표준데이터라고 생각했던 IANA Timezone DB에 이렇게 오류가 많았다는 점, 특히 우리나라 관련한 데이터에는 제대로 된 것이 거의 없었다는 사실은 놀랍습니다. 우리나라의 과거 자료와는 별도로, 국제화관련 개발을 하는 사람이라면 내 컴퓨터/내 담당서버에 들어와있는 타임존데이터베이스가 언제 시점인지, 업데이트는 잘 되어 있는지도 잘 확인해봐야겠습니다.

지금까지의 내용과 관련된 메일스레드는 아래와 같습니다.

2014년 10월 30일 00:07:24 (UTC) From 정상혁, To tz@iana.org : 최초 패치를 보낸 메일 http://mm.icann.org/pipermail/tz/2014-October/021830.html
2014년 10월 30일 06:53:09 (UTC) From Paul Eggert, To 정상혁 : 답장과 1910년 시간대 변경에 대한 문의 http://mm.icann.org/pipermail/tz/2014-October/021831.html
2014년 10월 30일 09:18:57 (UTC) From 정상혁, To Paul Eggert : 1910년의 시간대 변경과 북한시간대에 대한 의견 : http://mm.icann.org/pipermail/tz/2014-October/021833.html

Android에서 @Inject, @Test

Wed, 17 Apr 2013 00:00:00 +0000

제가 지난달에 썼던 글이 네이버의 기술블로그인 http://helloworld.naver.com에 공개되었습니다.

Android에서 @Inject, @Test

Android에서 DI + Test 스타일로 개발을 하는데 겪는 어려움과 이를 극복하는데 도움을 주는 Android annotations와 Robolectric 등의 오픈소스 프레임워크를 비교하고 소개했습니다.

10 things you need to know about Android and Google Play - Tony Chan (Google), GDG Korea Android 컨퍼런

Wed, 17 Apr 2013 00:00:00 +0000

지난 2013/04/13일, 종로 페럼타워에서 열렸던 '구글 개발자와 함께하는 GDG Korea Android 컨퍼런스 '에서 공유된 내용입니다.

참석해서 메모했던 내용을 정리합니다.

구글 Play와 API, 권장 UI스타일, 정책 등 다양한 주제를 이야기한 발표였습니다. UX설계를 할 때 많은 고민이 필요하겠다고 느꼈습니다.

1. Think Global

한 지역만 염두에 둔다면 기회를 놓치고 있는것이다. 구글 Play 수익의 67%가 미국외에서 나오고 있다.
Localization을 고려해라. 구글 Play의 그래픽스와 비디오도 이제 로컬라이즈되었다.

웹애플리케이션은 국제화에 대한 고려를 하는 비율이 높지 않습니다. 앱개발은 반대로 국제화를 고려하지 않는 것이 더 합당한 이유가 있어야하는 듯합니다. 기준이 차이가 생겼다고 느껴집니다.

2. Pure Android

다른 플랫폼의 UI형태를 모방하지 마라. 각각의 플랫폼은 고유한 스타일이 있다.
플랫폼 특화된 아이콘을 밖에서 쓰지 말라.
바닥에 붙은 탭바를 쓰지 마라. (아이폰 스타일)
별도의 라벨이 붙은 백버튼, 'right point caret'(>) 버튼을 쓰지 마라. 백버튼을 플랫폼에서 제공하는 것을 쓰도록 유도해야 한다.
UI에 대한 지침을 지키지 않으면 사용자가 안 좋은 Rating을 할 것이다.
이전의 안드로이드 버전에 지원하던 스타일의 레가시 버튼을 쓰지 마라.
Action bar를 써라. 곧 support 라이브러리를 통해 하위 버전에서도 ActionBar를 쓸 수 있게 될 것이다. 지금도 오픈소스로 Actionbar-sherlock이 있지만, 기본 SDK에서 이제 지원된다.
가장 최신의 SDK에 targeting하라. 최신의 SDK에서만 돌아가야한다는 의미는 아니다. 하위버전에서도 돌아가도록 만들면서도 상위버전에서는 최신의 UI 요소들을 활용해야 한다.

개별 앱의 UI는 같은 플랫폼 내에서의 일관성을 해치지 않아야한다는 지침을 강조했습니다. 같은 사용자가 2개의 다른 플랫폼을 오가면서 같은 앱을 사용하는 경우보다는, 하나의 플랫폼에서 여러 앱을 사용하므로 플랫폼 내에서의 일관성이 중요한 것은 당연한듯합니다.

기획자나 디자이너 입장에서는 하나의 앱을 출시하면 여러 플랫폼이 동일한 UI로 나오기를 바랄 수도 있을 듯한데, 이러한 지침을 초기부터 염두에 두고 엔지니어가 피드백을 줄 수 있어야겠습니다. 안드로이드 디자인가이드도 정독해봐야겠구나 싶었습니다.

그리고 Actionbar-sherlock에서 해주던 ActionBar의 하위 호환성 지원이 support 라이브러리에 들어간다는 소식도 반가웠습니다. Fragment가 support 라이브러리에서 지원되는 것을 생각하면 자연스러운 개선이기도 합니다.

3. Design for all form-factors

Fragment를 써라
타블릿과 폰을 위해서 별도의 프로젝트를 프로젝트를 만드는것은 바람직하지 않다. Fragment를 이용해서 타블릿에서는 하나의 Activity에 여러개의 Fragment가, 폰에서는 Activity당 하나의 Fragment를 보여주는 식으로 구성하면 얼마든지 하나의 프로젝트로 구성할 수 있다.
UI요소의 크기는 기기의 해상도에 독립적이도록 DP를 쓰고, 텍스트에는 SP를 써라.
적어도 3개의 레이아웃을 고려해라. 폰, 7인치 타블릿, 10인치 타블릿. DP는 해상도 문제만 해결할 뿐, 다른 사이즈에 대한 문제는 별도로 고려해야 한다.
지원하려는 화면 밀도(Density), 해당도에 맞는 Asset, 이미지를 각각 준비해라. Aliasing은 보기에도 좋지 않고 CPU를 많이 사용해서 배터리 사용시간을 짧아지게 한다.

DP에 대해서는 아래 그림 1장이 직관적인 이해에 많은 도움이 되었습니다.

(이미지 출처 : http://www.kmshack.kr/317#.UWy9VIpdUbj )

웹에서는 '방탄형 웹’이나 '반응형 웹디자인’에 대한 많은 노하우가 공유되고 있는데, 안드로이드에서도 점점 더 섬세한 노하우들이 공유될 것 같습니다.

4. Correct back button behaviors

앱의 메인 화면에서 사용자는 홈스크린으로 바로 돌아갈 수 있어야 한다. 종료 할때 다이얼로그로 종료할지 물어보는 방식으로 Back에 대한 이벤트를 강제적으로 막지마라.

많은 앱이 이렇게 되어 있지 않기에 다소 의외의 가이드라고 느껴졌습니다. 이것도 일관성을 생각하면 의미 있는 지침입니다.

5. Proper notification

핵심 기능에 대해서 통지해라. 광고에 Notification을 쓰지 마라.

6. App quality improvement

http://bit.ly/google-play-core-checklist 참고
http://bit.ly/google-play-tablet-checklist 참고

한글 번역도 http://googledevkr.blogspot.kr/2013/01/app-quality-guidelines.html 에서 보실 수 있습니다.

(이 포스트를 쓰고 난 후에 권순선님께서 알려주셨습니다.)

7. Permission

핵심기능에 필요한 최소한의 권한만 부여하도록 해라.
민감한 권한을 너무 많이 가지고 있으면 당신에게 해가 된다. 앱의 다운로드 숫자나 주목 받을 기회가 줄어들 것이다.

8. Google play service

구글에서 제공하는 서비스 API를 나열하면서 소개.
Maps API 2, Google+, Google Authorization, Google Play services APK 등

위 내용은 http://developer.android.com/google/play-services/index.html에 자세히 나와 있습니다.

9. New platform API

새로 추가된 API를 간단히 나열.
- Lock screen widget
- Seconary display
- Day dreams (interactive screensaver mode)
- Natvie RTL(right-to-left) support
- Tablet sharing
최근 업데이트된 API 소개
- GCM
- Analystic SDK
- In-app Billing V3 (V2는 더이상 쓰지마라)
- Youtube android player

자세한 내용은 http://developer.android.com/about/versions/jelly-bean.html에 있습니다.

발표된지는 한참된 기능이지만, 이렇게 모아서 보니 앱개발자가 화면을 다양하게 활용할 수 있는 여지가 더 늘어나고 있다고 느껴졌습니다. 이에 따라 새로운 사업모델도 나올 수 있었는데, 이런 아이디어들이 기획부서에서만 나오기를 기다리는 것보다 개발자들도 적극 제안을 해 보면 어떨까하는 생각이 들었습니다. 개발자들은 새로운 API가 추가되는것을 늘 관심있게 보고 있기 때문에 자연스럽게 아이디어가 나올만도 합니다. Lock screen widget을 이용한 광고 제품이 나왔듯이, 앞으로도 그런 기회가 많이 남아 있을 것이라고 기대가 됩니다.

10. Publishing on google play

Google play는 풍부하게 미디어를 활용한다.
- 특징을 멋지고 깔끔한 이미지로
- 스크린샷
- 짧은 유튜브 동영상
- 로컬라이제이션
대표적인 정책 위반 사례들.
- 3rd party 지불
- 다운로드를 위해 3rd party 사이트로의 연결
- 스팸 키워드
- 별점에 인센티브 부과
정책에 대한 자세한 내용은 http://bit.ly/google-play-policy-edu 참조

정책에 따라 구현이 달라져야 할 부분을 미리 파악하고 있으려면 꾸준한 관심을 가져야겠습니다.

Android App과 TDD - 임유진 (Kakao), GDG Korea Android 컨퍼런스 중에서

Wed, 17 Apr 2013 00:00:00 +0000

지난 2013/04/13일, 종로 페럼타워에서 열렸던 '구글 개발자와 함께하는 GDG Korea Android 컨퍼런스 '에서 공유된 내용입니다

발표 자료

발표 자료 : http://goo.gl/1WyAz
예제코드 : https://github.com/eugenelgm/AndroidForTest

요약

제가 핵심으로 기억하는 내용은 아래와 같습니다.

앱이 기능이 점점 추가되고 복잡해져 가면서 코드가 점점 누더기가 되어갔다. 수정에 대한 부작용을 파악하기 어려워져 갔다. 그래서 테스트의 필요성이 느껴졌다.
Android의 기본 Test Framework는 너무 느려서 포기했다. 한번 실행에 30~40초가 걸렸다.
Robolectric도 검토했으나, 없는 기능이 많고 라이브러리 충돌 때문에 포기했다.
- 테스트가 실패할 때 Robolectric의 버그인지 앱의 버그인지 확인하기 어려워서 디버깅에 시간이 걸렸다.
- 암호화 관련 라이브러리에서 충돌이 일어남
결국 UI쪽의 테스트보다는 UI를 벗어난 layer에서 핵심로직을 테스트하는데 집중했다.
테스트 기법
- android.util.Log를 호출하는 부분은 별도의 Wrapping 클래스로 작성. 테스트 프로젝트에서는 같은 패키지에 같은 클래스 이름으로 System.out으로 로그를 출력하는 클래스를 작성. class loader의 순서를 조정해서 테스트 코드에서는 테스트용 Logger클래스를 호출.
  - 실환경용 Log 랩퍼 클래스 : Logger.java
  - 테스트용 Log 클래스 : Logger.java
- Background Thread에 대한 테스트도 래핑 클래스를 이용. 테스트 환경에서는 테스트 코드와 같은 쓰레드에서 동기적으로 실행되도록 Runnable.run을 호출하는 래퍼클래스를 호출함.
  - 실환경용 쓰레드 실행 클래스 : DatabaseJobQueue.java
  - 테스트용 Log 클래스 : DatabaseJobQueue.java
- 같은 interface를 구현한 테스트용 Mock객체를 작성하고, 주입은 별도의 setter 메소드를 사용.
- API에 대한 테스트는 정적파일을 통해서 함. 후임자가 API의 명세를 예시로 금방 확인할 수 있는 장점도 생김
- Context에 대한 참조 등 Android에 대한 의존성을 제거하기 어려운 부분은 PowerMock + Mockito로 해결
  - PowerMock + Mockto로 Context.getString(int)의 동작을 가로채는 예제 : MainActivityTest.java
테스트할 수 있는 Layer를 구분하다 보니 설계 개선을 이끔
TDD에 대한 오해
- 꼭 Dalvik에서 테스트해야 의미가 있다.
- TDD로 모든 에러를 잡을 수 있다.
- 개발 후에 만들어도 된다.

질문

좀 더 자세히 알고 싶은 점이 있어서 발표가 끝난 후에 아래 2가지를 질문했습니다.

1. Robolectric의 라이브러리 충돌의 구체적인 사례

앞에서 정리한 암호화 라이브러리와의 충돌사례를 알려주셨고, Robolectric의 버그 때문에 디버깅이 어려웠다는 이야기도 구체적으로 해주셨습니다.

2. Depenency Injection 프레임워크를 고려

검토는 했지만 쓰지는 않았고, 발표한 내용은 사례일 뿐이기 때문에 각자 생각하는 좋은 방법이 있으면 계속 시도해봤으면 좋겠다고 말씀해주셨습니다.

의견

추가로 제 의견을 덧붙이면, Roblectric에 빈틈이 많다는 단점은 저도 공감은 가지만 꼭 UI를 테스트하지 않더라도 Robolectric을 부분적으로 유용하게 쓸 수는 있다고 생각합니다. 예를 들면 android.util.Log 클래스를 쓰는 코드도 Robolectric을 쓰면 별도의 랩퍼 클래스가 없어도 편하게 테스트할 수 있습니다. ShadowLog라는 클래스를 사용하면 Console이나 특정 파일등 로그를 쓰는 위치도 좀 더 편하게 조정할 수 있습니다.

ShadowLog.stream = System.out;
Robolectric.bindShadowClass(ShadowLog.class);

그리고 멀티쓰레드에 대한 테스트를 할 때도 Robolectric의 RobolectricBackgroundExecutorService를 쓰면 편할 때가 있습니다. 이 클래스도 다른 쓰레드를 생성하지 않고 호출한 쪽과 같은 쓰레드에서 Runnable 클래스를 실행해 줍니다.

Android-annotations를 쓰면 @Background가 붙은 메소드는 BackgroundExecutor라는 클래스를 통해서 실행되는데, 이 클래스에 있는 executor라는 멤버변수를 교체하면 쓰레드의 생성 정책을 조절 할 수 있습니다. 따라서 테스트를 할 때는 아래와 같이 테스트용 Executor를 넣으면 자연스럽게 같은 쓰레드에서 동기적으로 Runnable 클래스를 실행할 수 있습니다.

BackgroundExecutor.setExecutor(new RobolectricBackgroundExecutorService());

참고로 구조적으로 Thread의 Executor를 바꿔치기 하기 힘든 경우에는 Awaitility라는 라이브러리도 사용해볼만도 합니다.

그리고 SDK버전에 따라서 다르게 돌아가는 코드가 있다면 Robolectric에서 아래와 같이 조작을 할 수 있습니다. (물론 PowerMock을 써도 같은 일을 할 수 있기는 합니다.)

Robolectric.Reflection.setFinalStaticField(Build.VERSION.class, "SDK_INT", Build.VERSION_CODES.JELLY_BEAN);

암튼 Robolectric에 빈틈이 많기에 큰 기대를 하지 말고 UI 레이어의 테스트에는 많은 욕심을 부리지 말자고 생각하지만 그래도 몇가지 매력적인 기능이 있어서 Robolectric을 아예 외면을 할 수는 없었습니다.

Mockito + Powermock의 조합은 강력하지만, 구조를 고치기 어려운 레가시 코드에만 한정해서 썼으면 한다는 의견입니다. 가능하다면 Powermock이 없어도 테스트할 수 있도록 구조를 개선하는 것이 더 클래스의 역할이 명확해지고, 앞으로 기능을 추가하거나 읽기에도 좋은 코드가 되기 때문입니다. 그렇게 구조개선을 하는데는 DI 프레임워크가 많은 도움이 되기도 합니다. DI 프레임워크를 쓰면 Context에 대한 직접 의존이나 안드로이드 기본 프레임워크의 final 메소드의 동작을 가로채야할 일이 적어져서 훨씬 테스트하기 편해집니다.

Helloworld에 올라온 Android에서 @Inject, @Test 에서 이에 대해 자세히 적었습니다.

소감

개인적으로 많은 고민을 했던 주제였고, 발표자께서 내리신 결론이 저와 거의 비슷했기에 무척 반가웠습니다. 저도 Android의 기본 테스트 클래스를 쓰면서 느꼈던 좌절감에 결국 JVM에서 테스트를 해야 TDD로서 의미가 있다고 느꼈습니다. UI에 대한 테스트보다는 안드로이드와 독립적인 Layer를 테스트하는 것이 ROI가 높고, 좋은 설계를 이끈다는 점도 공감이 갔습니다. 로그호출 부분이나 멀티쓰레드에 대한 테스트 등 제가 했던 고민도 보편적인 문제였다는 것도 확인했습니다. API의 호출결과를 정적 파일로 저장해두고 테스트 코드에서 파싱부터 검증하는 기법은 저도 Server to Server API클라이언트 모듈 테스트 때 많이 썼던 방법이였습니다

제가 편향된 생각을 가졌을지 늘 걱정이 되었는데, 같은 의견을 가지신 분이 구체적인 사례까지 공유해주셔서 많은 도움이 되었습니다. 앞으로 다른 분께도 안드로이드에서 TDD를 자신있게 권장해드릴 용기를 얻었습니다.

Spring tag library + Tomcat7.x 또는 Glassfish 2.2.x의 EL Injection 위험

Tue, 5 Mar 2013 00:00:00 +0000

취약점의 조건

아래 조건을 모두 충족시킨다면 코드는 치명적인 Remote code execution 취약성이 존재할 여지가 있습니다.

EL 2.2를 지원하는 서블릿 컨테이너를 쓰거나 EL 2.2 라이브러리를 직접 jar파일로 참조해서 쓰고 있다. (대표적으로 Tomcat 7.x혹은 Glassfish 2.2.x)
Spring 3.1.x 미만 버전을 쓰고 있다.
Spring의 JSP Tag( <spring:message.. 등)을 쓰고 있다.
Spring의 JSP Tag에서 EL을 지원하는 속성에 사용자가 입력한 값이 들어갈 수 있다.
- 각 태그의 속성의 EL지원 여부는 Stefano Di Paola 등의 Expression Language Injection 보고서 참조

위에서 첫번째 조건이 해당하지 않더라도 다른 취약점을 조심해야 합니다. EL 2.2을 사용하지 않더라도 JSP 2.0이상을 지원하는 서블릿 컨테이너를 쓰면서 2,3,4에 해당하는 코드라면 어플리케이션의 중요한 정보를 노출시킬 수 있는 취약점이 존재할 위험이 있습니다. Remote code execution만큼 심각하지는 않지만, 역시나 조치가 필요합니다.

이 취약 지점은 의도하지 않은 정보를 노출할 수 있는 위험성으로 이미 2011년 9월 지적되어 보안되었으나, 이번달인 2013년 1월에는 같은 취약 지점을 통해서 원격 코드를 실행하는 기법이 발견되어 위험성 등급이 올라갔습니다. 즉, 해당 라이브러리가 취약성을 유발한다는 점 자체는 새로운 것이 아니고, 이미 이를 보강하는 버전이 나와 있습니다.

이 취약점의 원인과 조치방법은 아래 링크에 정리해놓았습니다. (코드가 들어간 글은 GIST를 쓰는 것이 훨씬 편하네요.)

https://gist.github.com/benelog/4582041

Markdown + Dropbox

Tue, 5 Mar 2013 00:00:00 +0000

업데이트
- 2019.04.10 : 현시점에서는 Calepin 서비스도 종료되었습니다.
- 2013.03.05 : GIST에 썼던 글을 옮기어 봅니다.
  - Springnote 서비스 종료 전에 쓴 글이라서 Springnote의 마이그레이션 코드는 이제는 쓸수가 없네요)

자료를 정리하는 형식과 도구에 대한 고민

회사에서 만든 자료들은 MOSS(Microsoft Office SharePoint Server)나 위키, 메일함 등이 있으니 큰 아쉬움은 없는데, 개인적인 자료들은 어떻게 정리하고 보관, 공유할지가 늘 고민이 됩니다.

저는 공개하고 싶지 않은 것들은 에버노트와 드롭박스를 쓰고, 공유할 자료들은 스프링노트와 이글루스 블로그을 활용하고 있습니다.코드들은 주로 Github와 Gist에 올립니다.

이렇게 다양한 서비스를 쓰다보니 자료를 서비스 간에 이동을 할 일이 생기면 많이 불편합니다. 예를 들면 에버노트에 있는 자료를 블로그에 올린다거나 스프링노트에 있는 글을 구글사이트로 옮길 때가 그렇습니다.그냥 한 두 페이지면 복사해서 붙여넣기를 하겠지만, 여러 페이지를 옮길 때 그렇게 하면 단순 반복 작업에 들어가는 시간이 아깝습니다.웹 브라이저나 웹 에디터의 차이 때문에 칸 맞추기 같은 사소한 편집에 시간을 많이 허비하기도 합니다.웹이나 클라이언트 환경 등 다양한 환경에서 모두 편집이 간편했으면 하는 바램도 있었습니다. 우분투를 쓰는 시간이 많다보니 MS워드처럼 특정 OS가 종속적인 편집기는 별로 좋아하지 않기도 합니다. 그리고 정리한 내용을 자주 찾아보니 검색과 탐색 기능을 쓰기 쉬웠으면도 했습니다.

이번에 스프링노트가 종료될 예정이라 어떤 형식으로 자료를 정리할 것인지에 대한 고민이 더 커졌습니다.

요구사항을 정리하면

자료를 이동하는 비용이 적어야하고 (이식성)
자료의 모양 때문에 편집을 하는 시간이 되도록 없었으면 하고
특정 환경에 종속적이지 않은 다양한 문서 편집기를 사용할 수 있어야 하고
검색 기능을 간편하게 쓸 수 있어야 한다.

이런 점들을 고민하다보니 우선 정리하는 자료의 형식은 마크다운을 선택하게 되었습니다. Github와 Gist를 쓰면서 그 단순함에 만족을 했고, 텀블러, 트렐로등 지원하고 있는 서비스도 늘어가고 있어서 이식성도 높다고 생각했습니다.

그리고 원본 데이터를 파일단위로 관리하고 싶었습니다. 쓰던 서비스가 망하더라도 파일을 단순히 복사해서 다른 서비스로 옮길 수 있다면 이전 비용이 적을 것이기 때문이였습니다.

Github를 이용한 Octopress도 검토했으나, 버전관리까지는 필요없이 최종 파일만 관리하면 되었기 때문에 Dropbox를 썼으면 좋겠다고 생각했습니다.

사람 생각은 다 비슷한지, 이미 Dropbox + Markdown을 이용한 블로그와 위키 서비스가 나와 있었습니다.

블로그 서비스 : http://calepin.co, http://scriptogr.am/
위키 서비스 : http://wikipackit.com

Calepin( =Markdown + Dropbox)로 블로그 만들기

Calepin을 이용해서 http://book.benelog.net이라는 블로그를 만들어봤습니다.그동안 여러 곳에서 정리하던 읽은 책에 대한 메모를 Markdown으로 정리한 것입니다.

아래와 같이 .md 파일의 처음 시작에 날짜와 제목, URL, 태그 등의 정보를 달아주고, 파일을 [Dropbox 공유폴더]/Apps/Calepin이라는 폴더로 복사합니다.

Date: 2012-07-19
Title: 어제를 버려라
Slug: 어제를_버려라
Tags: IT업계

그리고 Calepin 사이트에 가서 'Publish’버튼을 누르면 약속된 폴더에서 파일정보를 읽어와서 블로그를 생성해 줍니다.

이 정보를 바탕으로 블로그를 만들어줍니다. 아래와 같이 굉장히 단순한 디자인인데, 저는 이 정도로 충분하다고 느꼈습니다.

scriptogr.am라는 서비스도 거의 비슷한 기능을 제공하는데, 블로그 테마 등 약간의 커스터마이징이 가능합니다. wikipackit도 사용법은 유사하고, 위키 페이지간의 링크 기능을 제공하지만, 현재까지는 페이지를 비공개로만 관리할 수 있습니다. 앞으로 유사한 서비스가 더 많이 나올수도 있고, 이전 비용도 크지 않으니 언제든지 좋은 서비스가 나오면 갈아탈 생각입니다.

스프링노트 마이그레이션

저는 스프링노트로 관리하던 페이지들 중 일부는 http://wikipackit.com 으로 옮겼습니다. 스프링노트의 API를 이용해서 Markdown형식으로 스프링노트 페이지를 다운로드하는 스크립트를 작성했습니다.Python과 Pandoc을 활용했습니다.

Eclipse Markdown Text Editor

편집기로는 주로 Eclipse에서 Markdown Text Editor을 사용하고 있습니다.Eclipse가 무거운 편이지만, Platform Runtime Binary를 찾아서 최소한 도로 설치하면 50MB가 넘지 않게 비교적 가볍게 쓸 수도 있습니다. 예를 들어 Eclipse 3.8의 최소설치를 위한 파일은 아래 링크에서 찾으실 수 있습니다.

http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/

편집을 하면서 HTML렌더링을 할 수도 있고, Eclipse의 단축키를 그대로 활용할 수도 있습니다. 예를 들어 파일을 찾을 때 Ctrl + Shift + R키를 눌러서 파일명의 일부를 입력해서 바로 찾아가는 것들이죠.

이렇게 구축한 글쓰기와 자료정리 환경을 굉장히 만족하면서 쓰고 있습니다. Markdown을 지원하는 서비스나 도구들은 앞으로 계속 나올 듯하고, 스스로 만들기도 쉽기 때문에 더 편하게 쓸 수있는 가능성도 크다고 봅니다.

Java에서 여러줄에 걸친 문자열 선언을 편하게 하는 @Multiline

Tue, 29 Jan 2013 00:00:00 +0000

Andrian Walker라는 영국 개발자가 만든 라이브러리를 제가 수정해서 Github에 올렸습니다.

이 프로젝트에 대한 자세한 설명은 아래에 있습니다.

Java에서 여러줄에 걸친 문자열 선언을 편하게 하는 @Multiline

(github wiki에 적고 블로그에 붙여넣기를 하니 코드 블럭이 깨지는 등 편집이 쉽지가 않네요. 그래서 링크로 대신 합니다.)

위 글의 핵심 내용은 아래와 같습니다.

Java에는 여러 줄에 걸친 문자열을 선언하는 문법이 없어서 긴 문자열을 편집하는 작업이 불편합니다.
이를 보완하는 방법을 찾던 중 Adrian Walker라는 개발자가 만든 Multiline-string 이라는 라이브러리를 발견했고, Eclipse에서도 쓸 수 있도록 코드를 수정해서 원저자의 허락을 받고 Github에 올렸습니다. (https://github.com/benelog/multiline)
이 과정 중에 Annotation Processing과 ECJ(Eclipse compiler for Java)에 대해서 알게 된 것들을 정리했습니다.
이 라이브러리와 비슷한 기능을 Lombok에 추가하거나, 안드로이드에서 annotation Processing을 활용할만한 방안을 더 연구해볼만 합니다

코딩 인터뷰 완전 분석 210쪽 17.3 변형 문제 풀이

Sat, 8 Sep 2012 00:00:00 +0000

계속 이어지는 인사이트 문제입니다.

http://www.insightbook.co.kr/post/3876

문제

코딩 인터뷰 완전 분석』210쪽 17.3 변형 문제

자연수 n을 입력받고, n!의 계산 결과 중 마지막에 붙은 연속된 0의 개수와 연속된 0 바로 앞에 나오는 숫자를 구하라.

실행 예

input n: 15
output: 3 8

설명

15!은 1307674368000이므로, 마지막에 연속된 0은 3개이고, 바로 앞의 숫자는 8이다.

조건

n의 범위는 1 이상, 10000 이하입니다.
테스트 입력은 다음과 같습니다.

20! = 2432902008176640000
30! = 265252859812191058636308480000000
40! = 815915283247897734345611269596115894272000000000
50! = 30414093201713378043612608166064768844377641568960512000000000000
100! = 93326215443944152681699238856266700490715968264381621468592963
8952175999932299156089414639761565182862536979208272237582511852
10916864000000000000000000000000

프로그래밍 언어에서 제공하는 자릿수 제한 없는 곱셈을 이용하거나, 이런 형태의 곱셈 함수를 직접 구현해도 답을 얻을 수 있지만, 문제의 의도와는 다릅니다.
정답 검토의 편의를 위해 블로그 포스팅에 2012!와 10000!의 결과를 남겨주세요.
(심화 문제) 연속된 0 앞에 나오는 여러 숫자를 구하는 것도 가능하니, 심심하신 분은 도전해보세요. ^^

풀이

먼저 입력값이 2012와 10000일 때의 결과는 아래와 같습니다.

input : 2012

output: 501 8


input : 10000

output: 2499 8

제가 푼 방식은 10은 5와 2의 배수라는 점을 이용했습니다. 곱해지는 숫자를 2와 5로만 소인수 분해하고 그 갯수를 각각 누적해서 구합니다. 즉 최종 팩토리안 값의 약수 중에서 2와 5가 몇 번 들어가 있는지를 계산하는 것이죠. 그리고 2,5가 아닌 나머지 약수는 구하고자하는 자릿수만큼만 잘라서 보관합니다.

예를 들면 5!에서 0의 갯수가 0이 아닌 마지막 숫자를 구한다면

5! = 1 * 2 * 3 * 4 *5 = 2^3 * 5 * 3

이이므로 2는 3번, 5는 1번 들어갑니다. 0의 갯수는 2,5가 짝이 맞는 갯수이므로 둘 중에 작은 숫자인 5의 약수의 갯수, 즉 1개입니다.

그리고 마지막 0이 아닌 숫자는 나머지 약수의 마지막 숫자인 3과 5와 짝이 맺어지지 못한 2의 배수를 곱해서 구합니다.

여기서는 약수인 2중 1개는 5와 짝이 맺어졌고, 나머지 2개가 남았으므로 2^2*3 = 12, 마지막 숫자만 남기면 2입니다.

테스트 코드에서는 이미 알려진 숫자를 검증했습니다.

public class FactorianAnalyzerTest {
    FactorianAnalyzer analyzer = new FactorianAnalyzer();

    @Test

    public void test5(){
        assertFactorianResult(5, 1, 2);
    }

    @Test
    public void test15(){
        assertFactorianResult(15, 3, 8);
    }

    @Test
    public void test20(){
        assertFactorianResult(20, 4, 4);
    }

    @Test
    public void test30(){
        assertFactorianResult(30, 7, 8);
    }

    @Test
    public void test40(){
        assertFactorianResult(40, 9, 2);
    }

    @Test
    public void test50(){
        assertFactorianResult(50, 12, 2);
    }

    @Test
    public void test100(){
        assertFactorianResult(100, 24, 4);
    }

그리고 꼭 마지막 1개의 숫자가 아닌 여러 숫자로 구할 수 있도록 확장했기 때문에 그것도 검증해보았습니다.

public class FactorianAnalyzerNonZeroTwoDigitsTest {

    FactorianAnalyzer analyzer = new FactorianAnalyzer();

    @Test
    public void test5(){
        assertFactorianResult(5, 2, 1, 12);
    }

    @Test
    public void test6(){
        assertFactorianResult(6, 2, 1, 72);
    }

    @Test
    public void test7(){
        assertFactorianResult(7, 3, 1, 504);
    }

    @Test
    public void test8(){
        assertFactorianResult(8, 2, 1, 32);
    }

    private void assertFactorianResult(int n,  int numOfLastNonZeroDigits, int expectedZeroCount, int expectedNonzeroDigit) {
        FactorianResult result = analyzer.countZero(n, numOfLastNonZeroDigits);
        assertThat(result.getZeroCount(), is(expectedZeroCount));
        assertThat(result.getNonZeroDigits(), is(expectedNonzeroDigit));
    }
}

전체 코드는 아래 주소에 올렸습니다.

문제로 풀어보는 알고리즘 0.3 생각해보기 풀이

Fri, 31 Aug 2012 00:00:00 +0000

출판사 인사이트 블로그에 아래와 같은 퀴즈가 올라왔네요 ( 원문: http://www.insightbook.co.kr/post/3814 )

문제

배열 arr[]과 위치 s, t가 있을 때,arr[s], arr[s+1], … , arr[t-1]을 오른쪽으로 한 칸씩 이동하고,arr[t]는 arr[s]로 복사하는 것을 ’1만큼 오른쪽으로 회전시켰다’고 한다.

예를 들어 길이가 8인 배열에서 s=2, t=6이면 다음 그림처럼 바뀐다.

길이가 n인 배열의 위치는 0, 1, 2, … , n-1이다.

문제 :k를 인자로 받아서 k만큼 오른쪽으로 회전시키는 함수를 작성하라.단, 1만큼 오른쪽으로 이동시키는 과정을 k번 반복해서는 안 된다.

조건 1 : 작성하는 언어에는 제한이 없습니다. 조건 2 : 답안으로 작성하신 글 제목에는 ‘문제로 풀어보는 알고리즘 0.3 생각해보기 풀이’라는 문장이 들어가야 합니다. (저희 블로그에도 트랙백을 걸어주세요.)

(주의: 이 코딩 인터뷰는 인사이트 입사와는 무관합니다. ㅡㅁㅡ /)

풀이

밀린 일이 많아서 정신적인 여유가 없지만, 경품에 눈이 어두워서 급하게 풀어봤습니다

우선 테스트부터 먼저 작성하고

import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
import org.junit.Test;

public class ArrayHandlerTest {
    ArrayHandler handler = new ArrayHandler();

    @Test
    public void testShift1() {
        int[] array = {1,2,3,4,5};
        handler.shift(array,0,3,1);
        assertThat(array, is(new int[]{4,1,2,3,5}));
    }

    @Test
    public void testShift2() {
        int[] array = {1,2,3,4,5};
        handler.shift(array,1,3,1);
        assertThat(array, is(new int[]{1,4,2,3,5}));
    }

    @Test
    public void testShift3() {
        int[] array = {1,2,3,4,5};
        handler.shift(array,1,2,1);
        assertThat(array, is(new int[]{1,3,2,4,5}));
    }
....

그리고 이를 통과시키는 실행코드입니다.

import java.util.Arrays;public class ArrayHandler {
    public void shift(int[] array, int s, int t, int k) {
        if (s > t) return;
        if (t >= array.length) return;

        int[] rangeToShift = Arrays.copyOfRange(array, s, t + 1);
        int rangeLength = t-s + 1; for(int i=0; i< rangeLength; i++) {
            int offset = (i+k) % rangeLength;
            array[s + offset] = rangeToShift[i];
        }
    }
}

대용량 배열일 때 메모리를 더 적게 쓰는 방법들도 고민해볼만도 하지만, 우선은 쉽게 문제를 푸는데 집중했습니다. t,s, k 같은 한글자 변수명은 별로 좋아하지 않지만, 문제에 있는 변수명이라서 그대로 살렸습니다.

전체 소스는 Github에 올렸습니다.

테스트 코드 : ArrayHandlerTest.java
문제 풀이 코드 : ArrayHandler.java

참고로 java.util.Collections.roate()메소드를 쓰면 위 문제는 아래 두 줄로 풀 수 있기도 합니다.

[source,java

List<Integer> range = list.subList(s, t+1);
Collections.rotate(range, k);

그런데 이렇게 하는게 이 문제의 의도는 아닐듯해서 참고구현 정도로 남겨 두었습니다. 처음 풀이에서도 Arrays.copyOfRange 메소드를 쓰기는 했지만 이 부분은 특별한 알고리즘이 없는 단순한 배열복사라서 활용했습니다.

Collections.rotate를 이용한 풀이 코드 : ListHandler.java

버전 관리 시스템 유랑기, 그리고 Git 적응기

Tue, 12 Jun 2012 00:00:00 +0000

https://gist.github.com/benelog/2922437#%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%9C%A0%EB%9E%91%EA%B8%B0-%EA%B7%B8%EB%A6%AC%EA%B3%A0-git-%EC%A0%81%EC%9D%91%EA%B8%B0버전 관리 시스템 유랑기, 그리고 Git 적응기

2011년 6월 9일과 11월 10일에 열린 세미나에서 두 번 발표했던 내용을 글로 정리했습니다.

지금까지 다양한 버전관리 시스템을 쓴 경험과 Git의 장점이라고 느낀 점에 대해서 발표했었습니다.

https://gist.github.com/benelog/2922437#%EB%B2%84%EC%A0%84%EA%B4%80%EB%A6%AC%EB%A5%BC-%EA%B1%B0%EC%9D%98-%EC%95%88-%ED%95%98%EB%8D%98-%EC%8B%9C%EC%A0%88버전관리를 거의 안 하던 시절

https://gist.github.com/benelog/2922437#%EB%B2%84%EC%A0%84%EA%B4%80%EB%A6%AC%EB%8A%94-%EB%A8%BC-%EB%82%98%EB%9D%BC%EC%9D%98-%EC%9D%B4%EC%95%BC%EA%B8%B0버전관리는 먼 나라의 이야기?

Git에 대해 이야기를 하기 전에 지금까지 어떻게 버전관리를 해왔는지 되돌아보겠습니다. 아마 비슷한 경험을 하시고 공감하실 분들이 많으실 듯합니다.

버전관리 시스템을 실무에서 쓰기 전에는 책에서 간단한 소개를 접한 정도였습니다. 김익환님이 지은 '대한민국에는 소프트웨어가 없다' 라는 책에는 아래와 같은 내용이 있습니다.

내가 아무리 소스코드관리 프로그램과 버그 관리 프로그램의 찬양자가 되어 조언을 해도 평생 사용하지 않을 회사들이 대부분일 것이다. 이건 진짜 좋은 건데. 안타깝다(153쪽)

이 책이 나온 때가 2003년 말이였는데, 그 당시에 국내에서 버전관리를 제대로 사용하는 개발 조직은 많지 않았나봅니다. 제 주변에서도 그랬습니다.

그때는 버전관리가 실무에서 필요하다기 보다 'CMMI' 같은 프로세스처럼 이론으로만 강조되는 분야라고 느꼈습니다. 아니면 엄격한 프로세스를 준수하고 그만큼 개발자에게 시간을 충분히 주는 소프트웨어 선진국에서나 가능한 기법이라고 생각했습니다.

김익환님이 미국에서 근무했던 'GTE’라는 조직에서는 개발자들마다 코딩하는 줄 수를 측정했더니 하루 평균 8줄이 나왔다는 내용이 있습니다.(171쪽). 그정도로 엄격한 리뷰와 관리를 거친다는데, 하루에 화면 4~5개씩 찍어내야하는 제 주변의 현실과는 동떨어진 이야기였습니다. 그래서 버전관리도 우리와는 다른 방식으로 개발을 하는 먼 나라의 일로, 우리와는 관계가 없는 절차로만 여겼습니다.

https://gist.github.com/benelog/2922437#%EA%B0%9C%EB%B0%9C%EC%84%9C%EB%B2%84%EC%97%90-%ED%8C%8C%EC%9D%BC%EC%9D%B4-%EC%9E%88%EB%8A%94%EB%8D%B0-%EC%99%9C-%EB%98%90-%ED%8C%8C%EC%9D%BC%EC%9D%84-%EB%94%B0%EB%A1%9C-%EA%B4%80%EB%A6%AC%ED%95%A0%EA%B9%8C개발서버에 파일이 있는데 왜 또 파일을 따로 관리할까?

신입 때 처음 투입되었던 프로젝트에서는 버전관리를 하기는 했지만, 공유폴더보다 더 불편하다는 느낌 뿐이였습니다.

그 프로젝트에서는 Local PC에 개발환경을 설치하지 않고, 개발서버에 FTP로 jsp 파일를 올려서 개발을 진행했었습니다. JSP로만 주로 개발을 하던 초기에는 흔한 방식이였습니다. 그래서 개발서버에 이미 최신 파일이 올라가 있는데, 따로 왜 버전관리 시스템이라는 것을 써야하는지 이해가 되지 않았습니다. 가끔 실수로 파일을 덮어쓸 때에는 백업 폴더에 가서 복사해서 복구했습니다.

그 조직에도 Merant Version Manager라는 버전관리 시스템이 설치되어 있기는 했습니다.그 도구를 개발자들이 필요해서 쓴다기보다는 본사에서 시키니까 쓰기는하는데, 뭔가 부가적인 작업을 한다고 느꼈습니다. 개발서버에 파일 올려서 테스트를 다 해본다음에, 버전관리 시스템에 로그인하고, PC에 있는 파일 찾아서 올리고, Local에서도 여러 군대의 파일을 같이 신경써줘야 했습니다. 귀찮고 그냥 빼먹고 싶은 작업이였습니다. 그때는 지금의 SVN처럼 Eclipse plugin이 있는 것도 아니어서 따로 클라이언트 프로그램을 띄워야했기에 더욱 불편했었습니다. 그래서인지 두번 째 투입되었던 조직에서는 개발서버에만 파일을 올려놓고 아예 버전관리를 안 했었습니다.

https://gist.github.com/benelog/2922437#%EA%B3%B5%EC%9C%A0%ED%8F%B4%EB%8D%94%EC%97%90-%EC%98%AC%EB%A0%A4%EC%A3%BC%EC%8B%9C%EB%A9%B4-%EC%A0%80%EB%85%81-6%EC%8B%9C%EC%97%90-%EB%B0%B0%ED%8F%AC%ED%95%B4-%EB%93%9C%EB%A6%BD%EB%8B%88%EB%8B%A4공유폴더에 올려주시면 저녁 6시에 배포해 드립니다~

세번째 프로젝트에서는 요즘처럼 Local PC에 WAS를 띄우고 Eclipse를 써서 개발을 하기는 했지만, 윈도우즈의 공유 폴더로 소스 관리를 했었습니다. 그때 완성된 프로그램을 서버에 배포하는 절차는 다음과 같았습니다.

개발이 끝난 파일은 공유폴더의 약속한 위치에 올린다.
담당자 한명이 매일 그 폴더의 파일을 자기 PC로 복사하고, Eclipse에서 컴파일한다.
컴파일 에러가 나는 것이 있으면 그 파일을 올렸을 것으로 추측되는 사람에게 이야기해서 고쳐달라고 한다.
컴파일 에러 안 나면 Eclipse에서 컴파일된 class파일과 JSP등을 FTP로 개발서버에 올리고 서버를 재시작한다.
서버 재시작이 끝나면 개발자들이 각자 자기가 만든 모듈을 확인해본다.
개발서버에서 잘 안 되는 기능 중에 급한 것은 다시 고쳐서 공유폴더에 넣고, 미안하지만 한번더 올려달라고 담당자에게 부탁한다.
안 급한 것은 그냥 내일 반영하기로 하고, 일단 Local PC에서만 고쳐둔다.
파일서버의 backup 폴더 아래에 날짜별로 오늘 배포한 것은 복사해 둔다.

매일매일 위의 절차를 반복하는데 30분을 넘게 썼었습니다. 프로젝트 구성원들 모두 개선을 해보려는 생각은 있었지만 당장의 업무가 급하다보니 투자할 시간이 없었습니다. 돌이켜 보면 프로젝트 개발기간이 6개월이 넘었는데, 6개월동안 매일 30분이면 엄청난 시간이 들어가는 작업이였습니다.

이 프로젝트에서도 버전관리시스템인 Merant Version Manager를 본사의 담당자가 와서 설치해주고,고객와 개발자들을 다 모아서 따로 교육까지 해주었습니다.그러나 역시나 버전관리 시스템에 파일을 올리는 건 파일서버에 복사를 하는 것보다 번거로운 일이라고 생각했었습니다. 그래서 버전관리 서버에는 1차 프로젝트 종료 후에 몰아서 한번 파일을 올리기로 합의했고, 그 방식이 효율적이라고 모든 프로젝트 구성원들이 공감을 했습니다.

그나마 개발 영역별로 업무분담이 명확해서 파일 충돌은 잘 일어나지 않았습니다. 충돌보다는 작업한 내용을 실수로 날릴까봐 걱정하는 사람은 많았는데, 어떤 개발자는 매일 퇴근 전에 개인 PC에 날짜별로 복사해 놓기도 했었습니다. 다들 그 개발자를 보고 부지런하고 좋은 습관을 가지고 있다고 칭찬을 했었죠. 이 기간 동안에도 공유폴더에 만족을 하고 버전관리는 업무를 더 느리게 하는 작업이라고 인식했습니다.

https://gist.github.com/benelog/2922437#merant-version-manager%EC%9D%84-%EC%93%B0%EB%8D%98-%EC%8B%9C%EC%A0%88Merant Version Manager을 쓰던 시절

https://gist.github.com/benelog/2922437#%EB%B9%8C%EB%93%9C-%EC%9E%90%EB%8F%99%ED%99%94-%EA%B7%B8%EB%A6%AC%EA%B3%A0-merant-version-manager%EB%A5%BC-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8B%A4빌드 자동화, 그리고 Merant Version Manager를 제대로 사용하기 시작하다.

그렇게 공유폴더를 쓰던 개발팀에서 고도화 성격의 2차프로젝트가 시작되었습니다.운영 중인 시스템에서 몇가지 업무가 추가되는 사업이였는데, 운영 중인 시스템에 당장 배포할 소스와 2차 프로젝트 오픈 때 배포할 소스를 따로 관리해야 했습니다. 유지보수성 요청 때문에 수정된 소스는 바로 운영 시스템에 배포를 하지만, 2차 사업에 추가요구사항으로 개발된 소스는 오픈 시점에 맞춰서 운영서버에 배포해야 했습니다. 그래서 유지보수와 신규개발 버전을 따로 브랜치를 분리할 필요성이 생겼습니다. 그리고 전에는 담당자별로 업무영역이 명확하게 나뉘어져 있었는데, 새로운 프로젝트에서는 그런 경계가 명확하지 않은 부분이 많이 생겼습니다.그런 필요성 때문에 버전관리를 본격적으로 시작하게 되었습니다.

그 시점에서 빌드자동화 스크립트도 구성했습니다. 수동으로 해서 매일 30분이 걸리던 빌드절차를 개선하는 시도였었습니다. 파일서버에 따로 복사한 파일이 아닌, 버전관리에 올라온 최신 소스 파일을 읽어서 컴파일하고 서버에 FTP로 올리고, WAS를 재시작하는 스크립트를 ANT로 구성했습니다. 제가 한 3일정도 걸려서 그 작업을 했었는데, 처음 맨바닥에서 하는 일이라서 지금의 기준으로 보면 정말 많은 시간이 걸렸습니다. 지금은 Maven + Hudson으로 하면 몇십분 안에 가능한 작업이지만, 그래도 3일 투자해서 매일매일 30분의 작업을 없애서 정말 만족스러웠습니다.그때부터 다른 개발자들도 이제 공유폴더에 파일을 복사해 넣는 대신 매일매일 버전관리시스템인 Merant Version Manager에 파일을 올리기 시작했습니다.

https://gist.github.com/benelog/2922437#-%EC%9D%B4-%EB%8C%80%EB%B6%80%EB%B6%84%EC%9D%B8-commit-%EB%A1%9C%EA%B7%B8'.' 이 대부분인 commit 로그

이 단계부터는 단순하게 파일시스템으로 백업을 하는 시대는 지났지만, 버전관리를 깊이 있게 사용하지는 못했습니다.그때 대부분의 커밋로그를 보면 점하나 (.)만 찍은 것이 많았습니다. 아무런 내용을 안 쓰면 입력하라고 메시지가 나오니까 그 걸 피하려고 넣은 문자가 '.'점이였습니다. 시스템을 운영하고, 담당자가 바뀌고, 업무 규칙이 바뀌어갈수록 버전관리 시스템에 있는 커밋로그가 정말 소중한데, 그때는 그런 걸 알지 못했습니다. SI프로젝트이다 보니 빨리 개발 다 끝내고 도망갈 생각이 먼저이지, 운영할 사람에게 도움이 되는 정보를 남겨야한다는 생각은 잘 나지 않았습니다.한참 지난 다음의 이야기지만, 불행스럽게도 제가 그 프로젝트에서 마지막까지 남아서 유지보수를 했습니다. 물론 그 덕분에 중간에 나갔으면 몰랐을 것들을 많이 느끼긴했습니다.

https://gist.github.com/benelog/2922437#lock-%EA%B1%B8%EA%B3%A0-%ED%87%B4%EA%B7%BCLock 걸고 퇴근

제가 처음 버전관리 시스템으로 썼던 Merant Version Manager는 CVS처럼 배타적인 방식으로 파일의 소유권을 관리했었습니다. 즉, 고칠파일이 있으면 먼저 그 파일들을 'Checkout’해야 하는데, 그 상태에서는 다른 사람은 그 파일을 건드리지 못하게 됩니다. 수정이 끝난 후에 'Check in’을 하면 고친 파일이 올라가고, 다른 사람이 'Check out’을 받을 수 있는 상태로 변합니다. 그 제품의 최신 버전은 어떤지는 몰라도 당시에는 그렇게 썼었습니다.

몇번은 다른 개발자가 파일을 Checkout 해놓은 상태로 퇴근을 했는데, 급하게 파일을 고쳐야 할 때가 있었습니다. 전화해서 비밀번호를 물어보고 해결을 했는데, 나중에는 업무가 밀접하게 관련있는 사람들끼리는 비밀번호를 거의 공유하다시피 했었습니다. 그리고 Lock 걸린 파일을 수정해야 할 때도 급한 일이 아니라면 먼저 'Check out’한 사람이 다 고칠 때까지 기다렸었습니다.

그때는 그게 당연한 방식이였고, 그렇게 해야 질서가 있고 안전하다고 생각했습니다. 얼핏 SVN이 lock없이 파일을 고쳐도 된다고 듣기는 했지만, 그렇게 하면 소스가 엉켰을 때 해결이 되지 않을 위험한 방식이라고 추측했습니다. 당시에는 그 버전관리 방식에 역시나 만족을 했었습니다.

https://gist.github.com/benelog/2922437#svn%EC%9D%84-%EC%93%B0%EA%B8%B0-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8B%A4SVN을 쓰기 시작하다

https://gist.github.com/benelog/2922437#svn-%EC%9E%85%EB%AC%B8SVN 입문

그러다가 직장이 바뀌어서 SVN을 쓰는 개발조직에서 일하게 되었습니다.

SVN을 특별히 공부한 적이 없었는데도 Subclipse나 Subversive같은 Eclipse plugin 덕분에 금방 적응을 했습니다. 그런 Plugin 덕분에 버전관리가 부가적인 작업이 아니고, 개발과정에 자연스럽게 녹아든다는 느낌이 들었습니다.배타적이지 않은 lock관리 방식과 'transactional’한 특성을 가진 commit 방식도 직접 써보니 더 편리한 개념이라는 것을 깨달았습니다. 가끔 Eclipse plugin의 버그나 뭔가 상태가 꼬였을 때 헤매기도 했지만, 얼마 지나지 않아 비슷한 상황에서의 문제해결에 익숙해지고, Plugin도 점점 안정화되어서 큰 불편없이 쓰게 되었습니다.

SVN을 쓰기 전까지는 이전의 버전관리 방식에 만족을 하고 있었는데, 막상 써보니 이전에는 그 불편함을 어떻게 견디었나하는 생각이 들었습니다.

https://gist.github.com/benelog/2922437#%EB%A8%B8%EC%A7%80%EB%8A%94-%EC%96%B8%EC%A0%9C%EB%82%98-%EB%91%90%EB%A0%A4%EC%9A%B4-%EC%9D%BC머지는 언제나 두려운 일

그러나 SVN에서는 브랜치 관리나 머지가 여전히 번거롭거나 두려운 일이였습니다.특히나 브랜치를 생성하고 오랫동안 유지하는 일은 정말 손이 많이 가는 일이였습니다.장기 프로젝트를 했을 때는 브랜치가 분기된 이후로 트렁크(trunk)에 반영된 사안들을 다시 브랜치로 옮기는 작업을 주기적으로 했는데, 자주 안하면 나중에 최종 머지가 두려워지고, 그렇다고 자주하기에는 시간이 많이 걸리는 작업이였습니다.

브랜치 관리와 머지를 잘하기 위해서 여러 개발팀에서 다양한 방법을 쓰고 있는 것을 보았습니다. 어떤 프로젝트에서는 일주일에 한번씩 트렁크 쪽의 이력을 가장 많이 알고 있는 사람과 브랜치를 가장 많이 수정한 사람이 같이 앉아서 작업을 했는데, 오래 걸리면 한번에 30~40분이 넘게 걸리기도 했습니다.팀에서 그런 머지작업을 많이 한 사람이 '머지 전문가’로 불리기도 했습니다. 당시 썼던 SVN버전에서는 머지한 후에 그동안의 이력이 남지 않기 때문에, 머지를 수정한 커밋 로그에는 "from revision 10244 to 10532" 와 같은 형식으로, 어디서부터 어디까지를 합쳤는지 로그를 적었습니다. 머지에 쓰는 도구도 사람마다 팀마다 다양했습니다. Subclipse나 Subversive의 메뉴를 활용하는 팀이 있었는데, 각자 개인마다 나름대로의 노하우가 있는 듯했습니다.어떤 팀에서는 그런 도구를 이용하면 오히려 실수가 많다면서 2개의 브랜치를 모두 Eclipse에서 띄운 후에 Diff로 하나하나 비교해가면서 파일도 하나하나 복사해서 가는 방식을 썼었습니다.시간이 상당히 많이걸리는 방식이였지만, 그 팀에서는 머지는 그렇게 하는게 최고라면서 상당히 만족하고 있었습니다.

오랜 노하우가 쌓인다고 해도 어떤 방식이든 여전히 실수할 여지는 많았습니다. 머지되어야할 이력이 빠져서 오류가 발생했던 경험도 있습니다.

그렇게 브랜치를 관리하는 부담이 크다보니, 규모가 큰 변경이 아니라면 왠만해서는 브랜치를 안 따고 Trunk만 사용하고 싶었습니다.그런데 개발서버에라도 언제 배포될지도 모르는 Trunk에 마음대로 커밋을 하는 것은 부담이 되는 일이였습니다. 부분적으로 잘 안 돌아가는 소스를 커밋할 수는 없으니,어느 정도 기능별로 완결된 것만 커밋을 하게 되었고, 그러다보면 커밋을 자주하지 않게 되기도 했습니다.

박재성님이 쓰신 Java 프로젝트 필수유틸리티라는 책에서도 아래와 같이 SVN merge의 어려움에 대해서 나와있습니다.

SVN에서 소스 코드 머지가 어려워 브랜치를 사용하지 않고 신규 메소드를 추가하는 방식으로 변경할 수 밖에 없는 상황도발생한다. 그렇지 않아도 VCS의 사용에 반대하는 개발자들이 있는 상황에서 머지의 어려움은 개발자들을 설득하기 어렵게 한다.(307쪽)

위의 문단을 포함해서 이 책의 306~307쪽에는 머지를 한후 커밋 로그에 리비전 번호를 기록하는 팁이라던지, SVN에서 merge를 하다가 문제를 겪으신 분의 이야기가 나와 있습니다.( 안영회님의 블로그 글에 달린 강수형님의 댓글 )

SVN의 최신버전에서는 머지를 하면 SVN에서 알아서 따로 추가적인 정보를 남기도록 개선이 되었다고는 합니다.

https://gist.github.com/benelog/2922437#git%EB%A5%BC-%EB%A7%9B%EB%B3%B4%EB%8B%A4Git를 맛보다

https://gist.github.com/benelog/2922437#dvcs%EC%97%90-%EB%8C%80%ED%95%9C-%EC%86%8C%EB%AC%B8%EB%A7%8C-%EB%93%A3%EB%8B%A4%EA%B0%80DVCS에 대한 소문만 듣다가..

그럭저럭 SVN에 만족했지만 브랜치 관리에는 다소 아쉬움이 있었던 차에, 여러 오픈소스 프로젝트들이 Git이나 Mercurial같은 분산버전관리시스템(DVCS)로 옮기어 간다는 이야기를 들었습니다.인터넷에도 분산버전관리 시스템에 대한 글들이 많이 올라왔는데, 그 중에서 조엘 스폴스키가 쓴 Mercurial 튜터리얼이 인상 깊었습니다.

그래도 직접 써본적이 없으니, 어떤 점이 좋을지 막연하게 상상한 하는 정도였습니다.그러던 중 팀내부에서 진행하는 프로젝트에서 Git으로 버전관리를 하게 되면서, Git의 좋은 점들을 직접 체험하게 되었습니다.

https://gist.github.com/benelog/2922437#%EC%B2%B4%EA%B0%90%ED%95%9C-%EC%9E%A5%EC%A0%90체감한 장점

아래에 정리한 Git의 장점들은 다른 누군가가 그렇다더라.. 해서 적은 것이 아니고, 실제로 프로젝트를 하면서 솔직하게 느껴졌던 것들입니다.오랫동안 쓰다보면 이것보다 더 많은 것을 느끼겠지만, 처음 써보는 프로젝트에서는 이정도가 개발하는데 도움이 된다고 생각되었습니다.

https://gist.github.com/benelog/2922437#ctrlz-%ED%8C%8C%EC%9D%BC-%EB%B3%B5%EC%82%AC%EB%B3%B4%EB%8B%A4-%EC%95%88%EC%8B%AC%EC%9D%B4-%EB%90%98%EB%8A%94-local-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%ACCtrl+Z, 파일 복사보다 안심이 되는 Local 버전 관리

개발자의 Local PC에서도 버전관리를 할 수 있다는 점은 DVCS의 대표적인 장점으로 꼽히고 있습니다.그런데 과연 그것이 꼭 필요한지, 오히려 버전관리 과정을 더 복잡하게 하지 않는지 우려하시는 분이 많고, 저도 그랬었습니다.

실제로 프로젝트를 해보니 지금까지 'Ctrl + Z’나 주석문으로 가리기, 파일복사로 해왔던 작업 중에 어떤 부분은 Local에서의 버전관리로 해결할 부분이 아니었나하는 생각이 듭니다.코드를 작성하다보면 성공의 확신이 없는 시도를 해볼 때도 있고, 시도한 것이 여의치 않았을 때 다시 돌아올 수 있는 지점을 기록하고 싶어지기도 합니다.물론 간단한 1~2줄의 수정 같은 정도는 Ctrl+Z, 주석문 등을 이용하는 것이 더 편리할 수도 있습니다. 그러나 파일의 여러 부분이 동시에 바뀌어야 하는데 나중에 되돌릴 가능성이 있다던지, 두가지 방식의 구현을 시험삼아서 같이 진행할 때는 Local에서 중간중간 commit을 하거나 브랜치를 생성하는 편이 훨씬 편리했습니다.

SVN에서는 따로 브랜치를 따고, 나중에 머지하는 일이 번거롭고 두렵기 때문에 통합할 가능성이 확실하지 않은 수정은 Local PC에서 원래의 파일을 복사본을 만들어서 수정하기도 했었습니다. 그러나 Git에서는 Local branch 생성과 이동이 빠르고 결과를 머지하는 것도 더 안정감이 있다는 느낌이 들기 때문에, Ctrl + Z,주석문 처리(//), 파일 복사로 때우던 소규모의 변경 지점 관리가 더 편해집니다.

Git을 썼던 프로젝트에서 XML파싱을 하는 모듈을 개발했었는데, JDOM과 DOM4J중에서 어떤 것이 해당 용도에 적합할지 확신이 없는 상태에서 2개의 Local branch를 만들어서 작업을 했었습니다.처음에 JDOM으로 갔다가, 마음에 안 드는 부분이 있어서 DOM4J로 구현했다가 다시 JDOM으로 돌아왔는데, 이렇게 결정을 번복하는 과정에서 Local의 버전관리가 없었다면 훨씬 번거롭고 다른 작업자들에게도 방해가 되었을 듯합니다.

https://gist.github.com/benelog/2922437#%EB%B2%84%EC%A0%84%EA%B8%B0%EB%A1%9D%EA%B3%BC-%ED%86%B5%ED%95%A9%EC%9D%98-%EA%B0%9C%EB%85%90-%EB%B6%84%EB%A6%AC'버전기록’과 '통합’의 개념 분리

앞에서 말했듯이, Local에서 버전관리가 가능하기 때문에 '버전기록’과 '통합’이 다른 개념이 됩니다.SVN에서 '커밋’은 '버전기록’이자 '소스 통합’을 의미합니다.. 즉, 작업한 내용을 기록하는 일과 다른 사람이 일한 소스와 합치는 일이 같은 일입니다.저도 지금까지 그것이 당연하다고 생각해왔기 때문에 두가지를 같이 취급하는 것이 전혀 어색하지 않았습니다.

그런데 엄밀히 따지면 2가지는 구분이 됩니다. 버전기록은 중간중간 의미 있는 단위의 작업이 끝날 때마다 할만한 일입니다. 그에 반해서 통합은 내가 작업한 소스를 다른 작업자들이 받아가도 괜찮은 시점에 하는 것이 바람직합니다. 예를 들어 컴파일도 되지 않는 소스를 커밋을 하고 그 에러를 고치는 커밋을 하기 전에 다른 동료가 소스를 받아간다면, 동료는 원래 하는 일에 방해를 받게 됩니다.SVN에서는 '커밋=통합’이라서 개인이 작업한 것을 전체 소스에 통합을 해도 괜찮은 시점에만 커밋을 해야 그런 부작용이 없습니다.만약 작업하는 브랜치가 언제라도 배포될 수 있는 브랜치라면 극단적으로는 개발작업에 완료된 시점에만 커밋을 해야 안전합니다. 이렇게 '커밋=통합’일 때는 버전관리의 모든 욕구를 다 충족시키지 못할 수도 있습니다. 오류가 있거나, 아직 확정되지 않은 인터페이스를 포함하고 있어서 다른 사람에게 전파되지 않았으면 하는 프로그램의 상태라도 버전기록은 하고 싶은 상황도 생길 수 있습니다.많은 경우, 통합보다 버전기록이 더 자주 필요한 일입니다.그리고 통합은 버전기록보다 더 신중하고 노력이 많이 들어가는 일입니다.예를 들면 안전한 통합을 위해서는 svn update → mvn test → commit의 절차를 거쳐야하는데, 버전기록이 필요할 때마다 위와 같이 안전한 통합을 위한 절차를 할지말지 고민해야 한다면 버전기록은 훨씬 무거운 일이됩니다.

물론 SVN으로도 별도의 브랜치를 딴다면 다른 작업자에게 영향없이 독립적으로 버전기록을 할 수 있지만, 굉장히 번거롭습니다.Git에서는 버전기록이 필요한 시점에서는 언제든지 commit을 하고, 통합할만한 상태가 되었을 때만 push를 하면 됩니다.

어떤 분은 통합 없는 버전기록을 할 수 있다면 통합을 자주 하지 않게 된다는 우려를 하시기도 합니다.그런데 SVN으로 작업할 때도 통합 가능한 상태를 염두에 두지 않고 버전기록이 필요할 때마다 자주 commit을 하다보면 CI서버의 빌드가 자주 깨지게 됩니다.빌드 실패는 빠른 피드백으로서 의미가 있지만, 너무 자주 실패하면 잡음이 되어서 다른 사람에게 방해가 되거나, 그 신호를 무시하게 됩니다.그런 부작용을 우려해서 오히려 commit을 자주 하지 않게 되는 경우를 보기도 했었습니다. 그래서 어떤 프로젝트에서는 '적어도 하루에 한번씩은 commit을 하자’라고 규칙을 정한 곳도 있었습니다.

버전기록과 통합을 강제로 묶어서 통합을 자주 하기를 바라기보다는 두 가지 개념을 구분하고 어떻게 활용할지는 상황에 따라서 선택하는 편이 좋다고 생각합니다.버전기록과 통합이 강제로 묶여있다면 개발자들이 오히려 둘 다 자주 하지 않게 될 수도 있습니다.통합을 자주하고 싶다면 필수적인 통합주기를 개발팀에서 약속을 하는 편이 더 실용적입니다. 기술 도메인의 특성이나 작업을 어떻게 분담하느냐에 따라서 통합과 버전관리의 주기는 다양할 것입니다.보편적인 버전관리 도구라면 상황에 따라서 다양한 정책을 적용할 수 있도록 개념이 섬세하고 유연한 편이 더 좋다고 생각합니다.

https://gist.github.com/benelog/2922437#%EB%B9%A0%EB%A5%B4%EA%B3%A0-%ED%8E%B8%ED%95%9C-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%9D%B4%EB%8F%99빠르고 편한 브랜치 이동

어느 정도 규모가 있는 프로젝트에 참여하다보면 여러 브랜치를 왔다갔다 하면서 작업할 일이 많습니다. SVN에서도 Local에 받은 소스 폴더를 다른 브랜치로 이동을 할 수 있고, Eclipse plugin으로 편하게 지원됩니다.

Switch to branchhttps://camo.githubusercontent.com/14111eced471ead7d87404b86e3d337f404dce42/687474703a2f2f646c2e64726f70626f782e636f6d2f752f31333936303330302f6769742f73766e5f7377746963685f6272616e63682e706e67[]

그런데, 저는 프로젝트를 하면서 저 기능을 거의 쓴 적이 없습니다. 네트워크로 다른 브랜치의 파일을 받아오기 때문에 이동하는 속도가 굉장히 느리기 때문입니다.그리고 원래 있던 브랜치에서 커밋을 아직 안 한 파일이 남아 있어도 이동이 안 됩니다.

그런 불편함 때문에 보통 여러 branch를 Eclipse에서 별도의 프로젝트로 받아서 한꺼번에 열어두는 일이 많습니다.

그러다보면 파일을 수정할때 어느 브랜치의 파일을 수정하는 건지 헷갈릴 때가 많습니다. 보통 저는 Ctrl + Shift + R로 파일을 찾는데, 여러 브랜치를 동시에 열고 있을 때는 같은 파일이름이 동시에 떠서 불편합니다.

이렇게 여러 브랜치가 열려있는 상황에서 의도하지 않은 브랜치의 파일을 고치는 실수는 주변에서 굉장히 흔하게 보였습니다.

Git에서는 이런 브랜치 전환이 굉장히 빠릅니다. 네트워크를 타지 않고 Local에서 branch를 전환을 하니 당연한 일입니다.Git을 처음 써본 프로젝트에서도 몇번 브랜치를 전환하면서 작업을 했었는데, 하나의 프로젝트만 열고만 있으면 되니 훨씬 편리하고 빨랐습니다.

https://gist.github.com/benelog/2922437#%EB%8D%94-%EC%A0%95%EA%B5%90%ED%95%9C-%EC%BB%A4%EB%B0%8B-%EB%A1%9C%EA%B7%B8더 정교한 커밋 로그

SVN에서는 브랜치에 있던 파일을 트렁크에 머지하면 그동안 브랜치에 커밋한 이력은 옮겨지지 않았습니다. 트렁크와 브랜치 사용 정책을 정하느냐에 따라서 다르지만, 어떤 프로젝트에서는 트렁크에는 아래와 같이 머지를 했다는 기록 밖에 없고, 머지를 담당한 사람의 이름밖에는 남아 있지 않았었습니다.

Git에서는 원한다면 모든 이력을 남길 수 있습니다. Eclipse plugin으로 보니 머지한 이력을 그래프로 이쁘게 보여줬습니다.

Git에서는 커밋 로그를 정교하게 수정할 수도 있습니다. 몇개의 커밋을 하나로 합칠 수도 있고, 앞에 커밋한 이력을 수정할 수도 있습니다.파일을 하나 빠뜨리고 커밋을 해서 불필요하게 커밋이 나누어지거나, 설명을 대충 적은 것 같아서 아쉬울 때가 많았는데 Git에서는 commit을 한 이후에도 그걸 보완하는 작업이 가능합니다. 어쩌면 한 번에 완벽한 코드를 짜는 것이 불가능한 것처럼, 한번에 깔끔한 커밋 이력을 남기고 논리적으로 균일한 커밋 단위를 관리하기는 어렵습니다.오래 가는 코드를 위해서는 커밋 로그는 깔끔하고 친절하게 정리되어야 합니다. Git을 쓰면 commit 로그도 리팩토링의 대상이 되어서 더 정교한 commit 관리를 원하는 사람에게 도움이 됩니다.

https://gist.github.com/benelog/2922437#%EA%B7%B8%EB%A6%AC%EA%B3%A0-gitflow-gerrit그리고 Gitflow, Gerrit

지금까지는 직접 경험한 장점을 이야기했는데, Gitflow와 Gerrit은 직접 써본 도구는 아닙니다. 그래도 Git의 매력중의 중요한 부분이라고 생각되어서 간단하게 언급하고 넘어갑니다.

Gitflow는 Best Practice라고 할만한 버전관리 절차를 Git으로 편하게 쓸 수 있게 도와주는 도구입니다.

Git이 워낙 기능이 많기 때문에 어떤 버전관리 정책을 써야할지 처음에는 막막하게 느껴질 수도 있을 것 같습니다. GitFlow는 'Feature' ,'Hotfix' ,'Release' 등과 같이 전형적인 역할의 브랜치들을 기본적으로 녹여내고 있습니다. 즉 좀 더 정형화되고 추상화된 개념들을 더 짧은 명령어로 쓸 수 있는 것입니다. 'git flow hotfix start’와 같이 명령어를 치면, hotfix를 위한 branch 생성을 해주는 식입니다.

Gerrit은 Git바탕의 코드 리뷰도구입니다.

어떤 블로거는 Getrrit을 소개하면서 'Someday, all software will be built this way.'라고 주장하기도 했습니다.

아래에 Gerrit과 Jenkins를 연동한 인상적인 Demo도 있습니다.

http://alblue.bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html

9분 40초부터 1분동안의 데모가 핵심적인 장면입니다. 코드를 수정하고 commit, push를 하고 Gerrit에 들어가보면 CI서버지인 Jenkins에서는 'verified’되었다는 표시가 나옵니다.그리고 그 코드를 리뷰해서 'Great’라는 메시지를 달아주고 +2점으로 점수를 부여해주는 장면이 나옵니다.

https://gist.github.com/benelog/2922437#%EB%85%BC%EC%9F%81%EA%B1%B0%EB%A6%AC%EB%A5%BC논쟁거리를

앞서서 Git을 쓰면 통합을 자주 안 하게 된다는 주장에 대해서 말씀드렸지만, 그외에도 Git에 대한 이런저런 불평들은 많이 있습니다.

https://gist.github.com/benelog/2922437#%EC%96%B4%EB%A0%A4%EC%9B%8C%EC%9A%94-%EB%B3%B5%EC%9E%A1%ED%95%B4%EC%9A%94어려워요~ 복잡해요~

우선 기능이 많고 어렵다는 것입니다. 이 부분은 저도 어느 정도 동감을 합니다.저도 프로젝트를 끝낸 후에 오랜 만에 다시 Git를 쓰려니 명령어가 잘 기억이 나지 않아서 헤메었던 기억이 있습니다.그리고 분명히 SVN보다 더 많은 개념과 기능을 제공하니 제대로 쓰려면 배워야할 것이 많기도 합니다. 중간에 많은 시행착오를 거치거나 실수로 소스를 날려먹은 사람도 몇번 봤습니다.

그렇지만 처음부터 그 많은 기능을 모두 알 필요는 없다고 생각합니다.간단히 SVN으로 하던 주요 사용법만 Git으로 배우는 것은 얼마 걸리지 않습니다.그리고 차근차근 기능을 익혀나가면 Git으로 더 편리하게 할 수 있는 일들이 늘어가고 앞에서 언급한 Git의 장점로 개발이 더 편해질 것이라 생각합니다.

Git의 많은 기능들은 Git 자체의 오버엔지니어링이라기보다는, 버전관리 업무 자체의 복잡함을 보여준다고 생각합니다.수많은 작업자가 같이 작업하고, 여러 배포 버전을 동시에 살려나가야 하는 대규모 소프트웨어는 버전관리 자체가 워낙 어려운 과제입니다.그런 문제 상황을 정교하게 분류하다보니, 점점 새로운 개념들이 생겨나서 처음 접하는 사람에게는 논리적으로 어렵다고 느껴질 듯합니다.그런데 그런 개념을 어떻게 응용할지 고민하면서 쓰다보면, 지금까지의 버전관리가 충분하지 않았음을 느끼게 됩니다.저도 파일 공유 서버로 버전관리가 충분했다고 생각하는 시절에는 SVN에서 제공하는 transactional한 commit 같은 기능이 필요하다고 생각하지 못했었습니다.마찬가지로 DVCS가 없이도 큰 아쉬움은 없었는데, Git등을 써보고 나니 이전에는 SVN에서 그냥 넘어갔던 부분이 더 불편하게 느껴졌습니다.

https://gist.github.com/benelog/2922437#eclipse-plugin%EC%9D%B4-%EB%B6%88%ED%8E%B8%ED%95%B4%EC%9A%94Eclipse Plugin이 불편해요

또 하나는 Eclipse plugin이 아직도 불안정하고 불편하다는 점입니다. 저는 Eclipse plugin은 history를 보는 용도로만 쓰고 모든 작업은 명령행으로 해서 특별히 불편을 겪은 적은 없습니다.다른 써보신 분들에 의견에 따르면 Eclipse plugin만으로는 Git의 모든 기능을 원활히 쓸 수 없다고 합니다.그래서 Eclipse plugin은 덤정도로 여기면서 큰 기대를 안 하고, 명령행 방식을 주로 쓴다고 생각하면 오히려 시행착오가 적을 것 같기도 합니다.명령어를 외우는 것이 처음에는 부담될지 몰라도, 나중에는 메뉴를 찾아해메는 것보다 작업속도가 더 빨리질수도 있습니다. 그리고 정보공유나 인수인계에서는 GUI보다 명령행이 더 유리하기도 하고, 더 재미있어할 개발자들도 많을 것입니다.

https://gist.github.com/benelog/2922437#%EB%A7%88%EC%B9%98%EB%A9%B0마치며

버전관리는 새로운 시도를 하기에는 워낙 두려운 분야이기는 합니다. 현재 방식의 버전관리로 충분히 만족하는 조직이 많고, 조직의 관습이나 변화에 필요한 비용등을 생각하면 그것이 어떤 조직에서는 정답일수도 있습니다.저도 돌이켜보면 버전관리의 필요성을 못 느끼던 시절부터 시작해서, Merant Version manager, SVN, Git을 거쳤고, 그 사이에 생각도 많이 바뀌었습니다.원래 하던 방식이 마음이 편했기에 제가 처한 환경의 특수성을 과대평가해서 새로운 방식이 필요하지 않다고 생각했던 시절이 많았었습니다.

그래도 발전한 도구들 덕분에 개발은 훨씬 편해진 것 같기도 하지만, 더 어려워지기도 했습니다. 단순히 소프트웨어 개발만 할 줄 알던 시절에서 빌드도구, 버전관리 도구에 대해서도 전에보다 더 많은 지식을 알아야 코드 한 줄을 쓸 수 있게 되었습니다.어떤 분들은 이런 흐름이 필요이상의 복잡함을 더했다고 느끼겠고, 새로 업계에 들어오는 개발자들에게는 점점 숙제거리가 늘어만 가는듯합니다.

저는 이런 변화는 발전이고, 여러 조직에서 비슷한 고민들이 있어서 공유하다가 약간씩 더 나은 해결방식이 나오고 있다고 봅니다. 저는 Git을 쓰는 프로젝트를 처음 해 보면서 다른 개발자들이 어떤 고민을 했을지 좀 더 많이 이해했고, 그런 고민들을 저는 지나쳤음을 깨달았습니다.그 점이 Git으로 얻은 가장 큰 선물이였습니다.

스레드 안정성의 문서화와 JCIP 애노테이션

Wed, 30 May 2012 00:00:00 +0000

스레드 안전성을 어떻게 문서에 표기할까?

Javadoc에서는 메소드 선언에 synchronized가 있는지 표시하지 않습니다. 그 이유는 동기화 여부는 세부 구현 방식이기 때문에 문서에까지 그것을 노출하지 않는 것은 적절하지 않기 때문이라고 합니다.

선언부에 synchronized가 있는 메소드도 메소드 안의 모든 블럭이 synchronized(this)와 감싸진 코드와 의미입니다. 즉 아래의 코드는

synchronized void run() {
//do something
}

다음과 똑같은 역할을 하는 코드입니다.

void run(){
  synchronized(this) {
  // do something
  }
}

구현방식을 개선하면서 동기화 구간을 메소드의 일부 구간으로 좁힐 수도 있고, this 객체 말고 다른 객체로 lock을 바꿀 수도 있습니다. 이런 세부구현 상황은 외부 인터페이스보다 더 쉽게 바뀔 여지가 있습니다. 그리고 lock으로 보호되는 모든 구간을 javadoc의 메소드 선언부에 표시하기도 어렵고, this로 전체 메소드를 lock으로 잡는 메소드인 synchronized 메소드 여부를 표시하는 것만으로 충분히 문서화가 되었다고 생각하기도 어렵습니다.내부적으로 더 효율적인 방식으로 동기화가 되어 있을 수도 있으니,Javadoc에서 synchronized가 있느냐 없느냐가 스레드 안정성을 판단할 수 있는 일관적인 기준도 되지 못합니다.

따라서 현재 javadoc의 정책은 적절하다고 생각됩니다. Effective Java 2nd Edition의 Item 70에서도 그렇게 언급되었습니다.

결국 현재 javadoc의 규약으로는 어떤 메소드가 멀티스레드에서의 안전한지 여부를 표시해야 하는 강제성은 없다는 이야기입니다.

Effective Java 2nd Edition에서는 스레드 안정성을 다음 4가지 분류로 구분해서 문서화하라고 권장합니다.

Immutable
- 상태가 없습니다. 당연히 Thread-safe합니다.
- 예) String, Long, Integer, BigDecimal
무조건 Thread-safe
- 상태가 있으나 내부적으로 알아서 동기화되어 있습니다.
- 예) ConcurrentHashMap
조건부 Thread-safe
- 어떤 메소드는 외부에서 sync가 필요한 클래스입니다.
- 예) Collections.synchronizedList로 받은 List의 iterator는 ConcurrentModificationException을 발생시킬수 있습니다.
Not Thread-safe
- 외부에서 synchronized를 해야 함
- 예) HashMap, ArrayList
Thread-hostile
- 외부에서 synchronized를 해도 멀티쓰레드에서는 못 쓰는 클래스입니다. 다행히 Java에는 거의 없습니다.
- 예) System.runFinalizersOnExit

저렇게 잘 구분해서 Javadoc 문서의 제일 앞에 설명을 해준다면 좋겠지만, 강제적인 표준이 없다보니 기존의 문서들은 클래스 설명의 중간에서 스레드 안정성을 설명합니다.

몇가지 클래스의 사례

그렇다면 현재 Java 클래스가 스레드 안정성을 문서화하고 있는지 몇가지 예를 살펴보겠습니다.

java.util.LinkedList

LinkedList의 javadoc에서는 클래스 설명의 중간 쯤에 볼드체로 강조해서 이 구현은 'not synchronized’되었다고 적혀 있습니다.

java.text.SimpleDateFormat

SimpleDateFormat의 javadoc에서는클래스 설명의 마지막 즈음에 synchronization이라는 제목의 절에서 'not synchronized’라고 설명합니다.

org.springframework.batch.item.file.FlatFileItemWriter

스프링배치의 클래스인 FlatFileItemWriter는 not의 앞 뒤로 별표를 붙여서 'not thread-safe’라고 적어놨습니다.

이렇게 클래스가 스레드 안정성을 표시하는 방법은 제 각각이고, 나름대로는 강조하고 있지만 주의깊게 API 문서를 주의 깊게 본 사람이 아니라면 지나치기 쉽습니다. 차라리 '스레드 안정성은 클래스별 설명 제일 윗줄에 넣도록 하고, 반드시 빨간색 Bold로 표시한다' 같은 규칙이 있었으면 얼마나 좋을까하는 생각까지도 듭니다.

JCIP annotation

JCIP annotation은 'Java concurrent in practice' 책에서 제안된 스레드 안정성을 표시하는 기법입니다.아래 4개의 종류의 애노테이션을 제공합니다.

@GuardedBy : 해당 객체가 어떤 Lock으로 보호되고 있는지 표시. 필드에 메소드에 사용 가능
@Immutable : 불변객체
@NotThreadSafe : 스레드 안전하지 않음
@ThreadSafe : 스레드 안전함

Apache Httpclient에서 활용 사례

실제 이 JCIP 애노테이션이 활용된 사례는 Apache Httpclient가 있습니다. 이 라이브러리의 클래스인 HttpGet, DefaultHttpClient, SingleClientConnManager는 아래와 같이 @NotThreadSafe, @ThreadSafe를 클래스 선언에 붙었습니다.

@NotThreadSafe
public class HttpGet extends HttpRequestBase {

@ThreadSafe
public class DefaultHttpClient extends AbstractHttpClient {

@ThreadSafe
public class SingleClientConnManager implements ClientConnectionManager {

이 애노테이션들은 원래의 JCIP 애노테이션의 패키지인 net.jcip.annotations 대신에 org.apache.http.annotation 패키지에 들어가 있기는 합니다.그런데 이 패키지에 있는 @ThreadSafe등의 javadoc를 봐도이 애노테이션들은 JCIP책에서 유래하였다고 설명합니다.

이 애노테이션이 붙어 있는 클래스의 avadoc에서는 클래스 설명 단락의 위 쪽에 이 애노테이션을 보여줍니다.

일관성 있는 위치에 표시되기 때문에 한 눈에 스레드 안정성 여부를 인식할 수 있습니다.

FindBugs에서의 지원

오픈소스 정적분석 도구인 Findbugs에서는 JCIP 애노테이션 중 @Immutable을 인식합니다. 버전 2.0부터 JCIP라는 버그 패턴으로 등록이 되어 있습니다. 아래 페이지에서 확인할 수 있습니다.

http://findbugs.sourceforge.net/bugDescriptions.html#JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS

Findbugs Eclipse plugin를 설치하면 보다 편하게 FindBugs가 주는 경고를 확인할 수 있습니다..

만약 아래와 같이 @Immutable로 선언된 클래스에 final이 아닌 필드가 있다면

import net.jcip.annotations.Immutable;

@Immutable
public class Memo {
  private String content;
  public void setContent(String content) {
   this.content = content;
  }
  public String getContent() {
   return content;
  }
}

Eclipse에서 경고를 보여줍니다.

그러나 FindBugs에서는 @Immutable외의 애너테이션은 특별히 확인하지는 않습니다.즉 @ThreadSafe 로 선언된 객체에서 @NotThreadSafe 로 선언된 멤버변수를 접근하더라구도 아무런 경고를 보내지는 않습니다. JCIP 애노테이션과 Findbugs를 동시에 쓰면서 많은 기대를 하지는 말아야 합니다.

Findbugs의 자세한 설명방법은 아래 포스트를 참고하시기 바랍니다.

FindBugs + Eclipse + Maven2 + Hudson

정리

Java에서 어떤 클래스가 멀티스레드에서 의도하지 않게 사용될 때 그 부작용은 심각하지만, 문제가 되는 지점을 추적하기는 어렵습니다. 그렇게 때문에 스레드 안정성은 반드시 엄격하게 문서에 언급 되어야 합니다.그러나 기존의 클래스를 보면 제 각각의 표현 방식으로, 때로는 눈에 잘 띄지 않게 문서에 적혀 있습니다.

JCIP 애노테이션은 일관된 방식으로 스레드 안정성을 문서화하는데 도움이 됩니다. 이 애노테이션은 Apache httpclient 프로젝트에 적용되었고, 강력하지는 않지만 findbugs에서 JCIP annotation이 걸린 클래스를 정적 분석을 해주기도 합니다.

대부분의 웹프로젝트에서는 비지니스 레이어를 상태가 없는 클래스로 멀티스레드에서도 안전하게 만드는 방식이 권장됩니다. 그러나 때로는 스레드 안전하지 않은 클래스를 만들게 될 수도 있습니다. 예를 들면 멀티스레드에서 공유되면 안 되는 외부 라이브러리의 클래스를 사용하는데, 그 클래스를 생성자로 받아서 멤버변수에 할당해야 하는 경우입니다. 또, 배치나 데몬서버 등을 만드는 프로젝트에서는 스레드 안전한 클래스와 그렇지 않은 클래스가 혼재하게 될 때도 많습니다. 그런 클래스들을 명확하게 구분하고 싶다면 JCIP 애노테이션으로 표시하는 것을 고려해볼만 합니다.

참고자료

[EJ2] : Effective Java 2nd Edition - Item 70
[JCIP] : Java concurrency in practice

초간단한 FTP server, One-FTPServer

Thu, 17 May 2012 00:00:00 +0000

배경

서버 작업을 하다보면, PC에 있는 파일을 서버에 올리거나, 서버에 있는 로그파일을 PC로 받고 싶을 때가 있습니다.그런 용도로 저는 다운로드를 할 때는 Winstone을, 업로드를 할 때는 간단한 웹애플리케이션으로 만든 Uploader 를 사용합니다.

제 블로그의 아래 포스트를 통해서 그 방법을 설명했었습니다.

또는 파이썬이 설치되어 있다면 'python -m SimpleHTTPServer’를 실행하면 간단한 웹서버를 띄울 수도 있습니다.

그런데, 여러 개의 파일을 올리거나 받을 때는 아무래도 FTP가 더 편하기도 합니다.그럴 때는 저는 Apache FtpServer를 사용합니다.Apache FtpServer가 설정이 간단한 편이지만, 기본 패키지를 wget으로 다운로드 받고, 압축을 풀고, 설정 파일을 편집하는 과정을 여러 번 하다보면 좀 번거롭기도 합니다.

그래서 Apache FtpServe의 모듈을 이용한 간단한 프로그램을 직접 만들어서 Github에 올려 보았습니다.'One-FTPServer'라고 이름을 붙여봤습니다.

https://gist.github.com/2711965#%EC%82%AC%EC%9A%A9%EB%B2%95사용법

간단하게 아래와 같이 다운로드를 받고

wget benelog.net/one-ftpserver.jar

Jar파일을 직접 실행하면 끝입니다.

java -jar one-ftpserver.jar
[source]

아무런 옵션이 없으면 익명 사용자(anonymous) 로그인을 통해 2121번 포트로, FTP서버가 실행 중인 디렉토리를 홈디렉토리로 접속할 수 있습니다.

포트, 아이디, 비밀번호 등을 명령행에서 바로 지정할 수 있습니다.

java -jar one-ftpserver.jar port=10021 id=benelog password=1234

그외 passive port, SSL적용여부 등 총 6가지 설정변수를 지원합니다.

java -jar one-ftpserver.jar port=10021 passivePorts=10125-10199 ssl=true id=benelog password=1234 home=/home/benelog/programs

자세한 파라미터의 설명은 https://github.com/benelog/one-ftpserver에 나와 있습니다. 혹시나 외국사람들도 쓸 일이 생길가봐 잘 되지 않은 어색한 영어로 적는다고 힘들었습니다;

다양한 FTP클라언트를 쓸 수 있지만,저는 wget이나 curl을 즐겨 사용합니다. 만약 benelog.net이라는 서버에 10021포트로 id가 benelog, 비밀번호 1234로 서버를 띄었다면, 아래와 같이 접근합니다.

wget
- download : wget filename
curl
- upload : curl -T [filename] ftp://benelog.net:10021 -u benelog:1234
- download : curl filename -u benelog:1234

재미있었던 코드

사용자 인증 정책 구현 클래스

Apache FtpServer는 UserManager라는 인터페이스로 사용자 인증 정책을 구현하도록 설계되어 있습니다. 기본 구현클래스로 Property파일이나 데이터베이스에서 사용자 정보를 읽어오는 클래스가 제공됩니다.

이 프로그램에서는 UserManager를 구현한 클래스에서 단순히 사용자 한명의 아이디, 비밀번호 값만을 가지고 인증을 하는 SingleUserManager라는 클래스를 만들었습니다.

net.benelog.oneftpserver.user.SingleUserManager

혹시나 다른 인증정책이 필요한 FTP서버를 만들게되더라도, 이 클래스만 간단하게 구현해주면 됩니다.

Apache Commons Net의 FTPClient모듈을 이용한 통합 테스트

특별히 어렵지 않는 프로그램이지만 여러 조합의 옵션이 다 의도대로 동작하는지 확인하는데에는 반복적인 테스트가 필요할 것 같습니다.그래서 Apache Commons Net에서 제공하는 FTP클라언트 모듈로 통합 테스트를 만들었습니다.

net.benelog.oneftpserver.CommanderFtpSslTest

아래와 같이 Console의 명령행에서 넘어가는 것과 똑같은 옵션을 넣어서 서버를 실행시킨 후, FTPClient로 접속했습니다.

@Test
public void loginFail() throws Exception {
  startServer(new String[]{"port=3131","ssl=true","id=benelog","password=1234", "home=" + home});
  client.connect("127.0.0.1", 3131);    // login
  boolean authorized = client.login("benelog", "13234");
  assertFalse(authorized);
}

이 통합테스트 덕분에 처음에 만들 때 디버깅 시간도 줄였고, 나중에 발견된 버그도, 버그를 드러내는 통합테스트를 먼저 추가해서 실패한 테스트를 만든 후에 그 것을 통과시키도록 수정해서 해결했습니다.

FTPClient모듈의 사용법도 덤으로 익혔습니다. Apache Commons Net에서는 FTP와 FTPS클라이언트가 동일한 인터페이스가 제공되어서 ssl옵션을 테스트 할 때 편리했습니다.

최상위권 n등의 점수 구하기

Wed, 29 Feb 2012 00:00:00 +0000

Effective & Agile Java Generics 글에 이은, Generics 활용 사례입니다.

배치 프로그램을 짜다가 수십만개의 점수 중에 상위 0.1%, 0.01%에 해당하는 값이 무엇인지 구해야하는 일이 생겼습니다. 기존의 프로그램은 Linux shell로 되어 있었는데, Linux의 sort를 이용해서 전체 정렬을 한 후에 찾고자하는 등수가 있는 줄을 찾아가는 방식이였습니다. 전체 건수에 비해서 구하고자 하는 등수가 상위 0.1%, 0.01% 등 아주 작은 비율임에도 불구하고, 전체 Sort를 하는 것은 비효율적이라는 생각이 들었습니다.

그래서 이 프로그램의 일부를 Java로 바꾸는 작업을 하다가 이 순위를 구하는 부분도 필요한만큼만 정렬을 하도록 바꾸고 싶었습니다. 저는 OS를 우분투를 쓰기 떄문에 상관없지만, Java로 만든 프로그램에서 중간에 Shell을 호출하는 부분이 남아있으면 다른 개발자들은 Local PC에서는 확인할 수 없는 부분이 생겨서 불편해질까봐 걱정되었던 이유도 있었습니다.

등수를 구하는 대상 데이터형은 Integer와 Float이였지만, Integer를 위한 클래스 따로 만들고 Float를 위한 것을 따로 만들기 싫어서 java.lang.Comparable를 구현한 클래스명을 다 사용할 수 있게 했습니다. 이정도 유연성을 두는게 추가 개발은 거의 없이 그냥 Generics 선언을 잘하면 되는 일이였으므로 그다지 과도한 확장은 아니였다고 생각했습니다. 덕분에 String형의 문자열도 비교할 수 있습니다.

즉, 문제를 다시 정리하면 아래와 같습니다.

데이터는 점수값만이 1차원으로 나열된다. (예: 1,5,3,10 …. )
java.lang.Comparable형의 클래스를 모두 계산 대상으로 받을수 있고, 명시적인 캐스팅이 필요없게 사용할 수 있어야한다.
전체 데이터 중에 지정한 등수를 구한다. 전체 데이터는 파일에 있고, 수십만건이라서 메모리에 모두 올릴 수 없으나, 지정한 등수까지는 메모리에 올릴 수 있을 정도로 최상위권의 값이 지정된다. 즉 예를 들면 80만건중 100등의 점수가 몇점인지를 구하는 상황이다

Integer, Float, String형을 대상으로 작성한 테스트 코드는 아래와 같습니다.

public void get3rdRankOf5() {
    //given
    List<Integer> rawData = asList(400,400,100,500,200);
    int rankToFind = 3;

    //when
    RankFinder<Integer> rankFinder = new RankFinder<Integer>(rankToFind);
    addAll(rawData, rankFinder);
    Integer rankedValue = rankFinder.getRankedValue();

    //then
    assertThat(rankedValue, is(400));
    assertThat(rankFinder.getTopValues(), is(asList(400,400,500)));
}

@Test
public void get2ndRankOf5WithFloat() {
    //given
    List<Float> rawData = asList(10.9F, 10.2F, 10.3F, 10.4F, 10.5F);
    int rankToFind = 2;

    //when
    RankFinder<Float> rankFinder = new RankFinder<Float>(rankToFind);
    addAll(rawData, rankFinder);
    Float rankedValue = rankFinder.getRankedValue();

    //then
    assertThat(rankedValue, is(10.5F));
    assertThat(rankFinder.getTopValues(), is(asList(10.5F,10.9F)));
}

@Test
public void get4thOfWord() {
    //given
    List<String> rawData = asList("e","fc","a","b","k");
    int rankToFind = 2;

    //when
    RankFinder<String> rankFinder = new RankFinder<String>(rankToFind);
    addAll(rawData, rankFinder);
    String rankedValue = rankFinder.getRankedValue();

    //then
    assertThat(rankedValue, is("fc"));
}

private <T> void addAll(List<T> rawData, RankFinder<? super T> rankFinder) {
    for (T num : rawData) {
        rankFinder.addTargetValue(num);
    }
}

이를 통과시키는 실행 코드와 테스트 코드 전체는 GIST에 올렸습니다.

더 효율적으로 개선할 여지가 많은 방식이지만, 1시간이 걸리는 전체 배치 중 1초 미만의 구간이였기에 속도향상이 큰 의미가 없어서 더 이상 리팩토링을 진행하지는 않았습니다. 알려진 selection alorithm을 참고하면 이 상황에서도 더 좋은 방식이 있을 듯합니다.

Spring 3.1을 활용한 AspectJ 표현식 테스트

Wed, 18 Jan 2012 00:00:00 +0000

AOP에서 AspectJ표현식은 다양하고 강력한 기능을 제공합니다. 예를 들면 Aspect가 결합될 JoinPoint를 아래와 같이 표현을 할 수 있습니다.

execution(public void set*(..)) : 리턴 타입이 void이고 메소드 이름이 set으로 시작되고 파라미터가 0개 이상인 메소드
execution(* com.benelog.ftpserver..() : com.benelog.ftpserver패키지의 파라미터가 없는 모든 메소드
execution(String com.benelog.ftpserver...(..) : 리턴타입이 String이면서 com.benelog.ftpserver패키지 및 하위 패키지에 있는 파라미터가 0개 이상인 메소드
execution(String com.benelog.ftpserver.Server.insert(..) : 리턴타입이 String인 com.benelog.ftpserver.Server의 파라미터가 0개 이상인 메소드
execution(* get*(*)) : get으로 이름이 시작하고 1개의 파라미터를 갖는 메소드
execution(* get*(,)) : get으로 이름이 시작하고 2개의 파라미터를 갖는 메소드 exceution(* read*(Interger,…)) : read로 이름이 시작하고, 첫번째 파라미터 타입이 Integer이며, 1개 이상의 파라미터를 갖는 메소드

그러나 다양하고 강력한 대신에 모든 문법을 다 익숙하게 쓰기는 힘들고, 컴파일 타임에 체크도 안 되기 때문에 실수할 여지도 큽니다. 조금이라도 표현식을 바꾸었을 때 유지하고 싶은 기존의 동작이 변함없이 작동되는지도 파악하기 어렵습니다.

그래서 AOP는 강력한만큼 통제되지 못한 부작용이 생기기도 쉽습니다. 표현식 한글자를 바꾸어도 어떤 동작을 하는지 테스트를 촘촘히 해봐야하는데, 그럴 때마다 WAS를 띄워서 테스트를 해본다면 시간이 많이 들어갈 것입니다.

Spring 3.1부터는 테스트 코드 안에서 @Configuration , @Bean 과 같은 JavaConfig 설정들이 지원됩니다. 그 기능을 이용하면 XML없이 보다 짧은 코드로 AOP에 대한 다양한 테스트를 편하게 해 볼 수 있습니다. 단순한 예제로 Spring 3.1의 기능으로 AOP 테스트하는 방식을 정리해보았습니다. 아래 설명한 예제들은 gist에 올라가 있습니다.

https://gist.github.com/1625374

LogAspect.java

LogAspect.java는 간단하게 로그를 저장소에 입력하는 Aspect입니다. @Before("execution(void *.run())") 라는 표현식으로 run 메소드가 실행되기 전에 로그메시지를 저장하도록 taget 객체와 결합됩니다.

@Aspect
public class LogAspect {
    private LogRepository repository;

    public LogAspect(LogRepository repository){
        this.repository = repository;
    }

    @Before("execution(void *.run())")
    public void log(JoinPoint jp){
        String message = jp.getKind() + ":" + jp.getSignature().getName();
        repository.insertLog(message);
    }
}

LogRepository.java

로그저장소 역할을 하는 클래스입니다. 실무에서라면 DB나 파일 등을 사용하겠지만, 여기서는 단순한 예제를 만들고 싶어서 그냥 String을 화면에 찍었습니다. 정교하게 만든다면 Log정보를 담는 Domain Object를 정의해서 String대신 사용해야 할 것입니다.

public class LogRepository  {
    public void insertLog(String message) {
        System.out.println(message);
    }
}

Taget 클래스

LogAspect와 결합될 Target 클래스입니다. 역시나 단순하게 화면에 메시지를 뿌려줍니다.

public class Printer implements Runnable {
    @Override
    public void run() {
        System.out.println("hello!");
    }
}

실제 코드에서의 applicationContext 설정

applicationContext를 설정하는 xml파일에서 aop: 네임스페이스를 이용해서 aspect J 표현식을 쓸 수 있게 하고, Aspect가 정의된 LogAspect를 bean으로 등록합니다.

<aop:aspectj-autoproxy/>
<bean id="printer" class="edu.tdd.aop.Printer"/>
<bean id="logAspect" class="edu.tdd.aop.LogAspect">
    <constructor-arg>
        <bean class="edu.tdd.aop.LogRepository"/>
    </constructor-arg>
</bean>

LogAspectTest.java

드디어 LogAspect의 표현식을 테스트하는 코드입니다. @Bean으로 Aspect와 tagetObject를 모두 XML설정 대신 java로 한 파일 안에서 표현했습니다.

각 테스트 메소드별로 2가지를 검증했습니다.

(1) proxyCreated() 메소드 : Proxy클래스가 생성되었는지 확인 (2) logInserted 메소드: LogAspect에서 호출하는 LogRepository에 원하는 메시지가 저장되었는지 확인

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(loader=AnnotationConfigContextLoader.class)
public class LogAspectTest {
    @Autowired Runnable targetProxy;
    @Autowired LogRepository repository;

    @Test
    public void proxyCreated() {
        assertTrue(AopUtils.isAopProxy(targetProxy));
    }

    @Test
    public void logInserted() {
        targetProxy.run();
        verify(repository).insertLog("method-execution:run");
    }

    @Configuration
    @EnableAspectJAutoProxy
    static public class TestContext {
        @Bean LogAspect aspect() {
            return new LogAspect(repository());
        }

        @Bean LogRepository repository(){
            return mock(LogRepository.class); // 검증용 객체를 application에다 등록
        }

        @Bean Runnable target(){
            return new Printer();
        }
    }
}

클래스 선언부분에서 @ContextConfiguration(loader=AnnotationConfigContextLoader.class) 를 붙이면 외부의 XML 대신 테스트 클래스 안에 포함된 JavaConfig로된 설정을 읽어올 수 있습니다. TestContext라는 내부 클래스에다 @Configuration을 붙여서 필요한 Bean을 등록했습니다. @EnableAspectJAutoProxy 는 <aop:aspectj-autoproxy/>와 같은 역할을 하는 애노테이션입니다.

아래와 같이 ApplicationContext에 LogRepository는 mock()으로 생성한 가짜 객체를 등록했습니다.

    @Bean LogRepository repository(){
        return mock(LogRepository.class); // 검증용 객체를 application에다 등록
    }

이 객체를 다시 Autowired로 받아온 후에 verify()를 했습니다. XML로 이와 비슷한 일을 하려면 코드가 더 길어지고, 별도의 파일로 분리가 됩니다. Mock을 Application에 등록하는 것이 바람직할지는 고민의 여지가 있지만 Aspect와 결합된 Proxy 클래스는 ApplicationContext를 통해야만 얻을 수 있고, 그 동작을 검증하고자 한다면 이 방식이 편하다고 느껴집니다.

여기서는 Printer객체를 target클래스로 사용했는데, 이 부분도 실제로 원하는 AOP 적용을 원하는 클래스나 제외 되어야할 클래스, 또는 직접 만든 테스트 전용 객체 등을 바꿔끼워가면서 다양한 조건을 검증할 수 있습니다.

덧붙여 verify(repository).insertLog("method-execution:run"); 부분에서 문자열을 직접 검증하는 것도 바람직하지 못한 방식일지도 모릅니다. 문자열 대신에 Log정보를 담는 도메인 객체를 따로 정의했다면, 그 객체에 메시지에 핵심키를 담고, equals를 override했을 것 같습니다. 문자열을 직접 검증하면 메시지의 형식이 바뀔 때마다 테스트가 깨어져서 유지보수가 번거로운 테스트 코드가 됩니다. 이 예제에서는 코드를 짧게 하고 테스트 코드 안에서 검증하고자 하는 동작을 단순하게 나타내려고 이 방식을 택했습니다.

Local 개발환경에서 WAS를 띄우는 여러가지 방법

Tue, 6 Dec 2011 00:00:00 +0000

Local 개발환경에서 WAS를 띄우는 여러가지 방식과 장단점에 대해서 정리해 봤습니다. 저는 상황에 따라서 아래 3가지 방법들을 그때 그때 골라서 씁니다.

Eclipse WTP (+Agent based reloading) : WAS를 올린 상태에서 클래스파일을 고칠 때, class파일 1개만 리로딩하는 것이 좋을 때
Maven Jetty plugin : JSP만 고칠 때나 클래스 파일을 고치면 전체 어플리케이션을 reloading을 하는 것이 유리할 때.
Maven Tomcat plugin : JSP만 고칠때. WTP가 뭔가 꼬인 것 같은데 같은 Tomcat에서 같은 에러가 나는지 확인해보고 싶을 때

1. Eclipse WTP(Web Tools Platform) + Agent Based Reloading

Maven 프로젝트가 <packaging>war</packaging>`로 선언된 경우 `mvn eclipse:eclipse 명령을 치면 Eclipse의 dynamic web project로 설정을 만들어 줍니다. Run as Server혹은 server 설정에 drag & drop으로 넣고 Eclipse안에서 서버를 실행합니다. M2Eclipse를 잘 활용하면 local에서는 수동으로 maven 빌드를 돌릴 일이 거의 없어지기도 합니다.

항상 쓰는 것은 아니지만, SpringSource Tool Suite의 Agent based reloading을 이용해서 class파일을 수정하고 빠르게 리로딩을 하기도 합니다. 모든 상황에서 잘 통하지는 않아서, 그냥 WTP만 쓰는 것이 나을 때도 있습니다. 예를 들면 XML파일을 고쳤을 때에는 Agent based reloading에서는 잘 반영되지 않았습니다. JRebel에서는 보다 다양한 경우를 지원하는 것 같지만, 저는 테스트 코드에서 View를 빼놓고는 왠만한 건 실행해보고 WAS를 올리기 때문에 보다 강력한 JRebel이 크게 절실하지는 않습니다

SpringSource Tool Suite의 Java Agent based reloading 사용해 보기 : http://blog.benelog.net/2796964

그런데, Eclipse의 Dynamic web project + WTP 환경에서는 JSP를 고칠때의 반영속도가 미묘하게 느린 것 때문에 web context 폴더를 소스폴더 외에도 별도로 잡고, /WEB-INF/classes나 lib까지 다 그 폴더로 복사해서 'add external web module’로 등록해서 쓰시는 분들도 많습니다. 어디가 소스폴더이고 어디가 목적폴더인지 정리되어 있지 않아서 WEB-INF/lib나 WEB-INF/classes같이 꼭 버전관리가 필요없는 파일까지 같이 SVN에 commit하기도 하고, 복잡하게 svn:ignore를 시키는 수고를 하기도 합니다. WTP에서 'Serve modules without publishing ' 옵션을 써서 이를 해결하기도 합니다. 이에 대한 자세한 내용은 아래 자료에 정리되어 있습니다.

https://docs.google.com/document/d/1fYoWD_0-3sGxHjHNHKgGNLmONVTQ9DmaLwO-MSXVCHU/edit

다음에 소개하는 maven jetty plugin과 Jetty나 Maven plugin을 써도 JSP가 더 빠르게 반영되기 때문에, WTP의 JSP반영 속도 때문에 일부러 'add external modules’로 WAS를 띄울 필요성은 적어집니다.

2. Maven jetty plugin

pom.xml에 Maven jetty plugin을 설정하면 따로 별도의 WAS설치과정이 필요없이 mvn jetty:run만 치면 바로 WAS가 뜹니다.

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
     <configuration>
         <scanIntervalSeconds>3</scanIntervalSeconds>
         <contextPath>/</contextPath>
      </configuration>
       <version>6.1.11</version>
</plugin>

디폴트로 8080포트를 쓰려면 위에서 "connector' 부분의 설정이 없어도 됩니다.

아래의 Tomcat plugin도 마찬가지지만, 이런 plugin이 설정되어 있으면, Eclipse가 없어도 SVN에서 checkout한후바로 명령어 하나로 WAS를 띄워볼 수 있습니다. 그 프로젝트의 개발자가 아닌 사람이 프로젝트를 띄워보거나 가끔 들어가는 프로젝트를 실행할 때도 편합니다.

대부분의 웹어플리케이션은 Servlet Spec만 따라서 개발하므로 Jetty에서 돌아가면 Tomcat에서 거의 돌아간다고 봐도 됩니다. 물론 성능테스트나 프로파일링 같은건 당연히 Tomat을 띄워서 해야겠죠.

다음에 소개할 Maven Tomcat plugin보다 WAS가 뜨는 속도나 리로딩 속도도 빠르다는 느낌입니다. "scanIntervalSeconds" 설정에 따라서 클래스 파일을 고쳐도 리로딩이 잘 됩니다. 'WTP + Agent based reloading’을 쓴다고 해도 뭔가 꼬이는 상황이 발생할 수 있고, 그럴 때는 전체 web context를 로딩하는게 좋습니다. 그런 상황이 많은 개발환경이라면 Jetty plugin이 유리합니다.

단점은 Tomcat이 아닌 Jetty이니 WAS level의 클래스가 던지는 에러메시지가 약간 다르기도 하고, Apache와 연결할때 AJP connector등을 설정할 수 없어서 Apache httpd의 모듈을 사용하는 페이지에는 쓸 수 없다는 점입니다.

3. Maven Tomcat plugin

jetty plugin과 비슷하게 pom.xml에 Tomcat plugin을 설정하고, mvn tomcat:run 을 치면 WAS 설치가 필요없이 Tomcat이 뜹니다.

설정은 아래와 같습니다.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>tomcat-maven-plugin</artifactId>
    <version>1.1</version>
    <configuration>
        <path>/</path>
        <serverXml>$\{basedir}/src/main/webapp/server.xml</serverXml>
    </configuration>
</plugin>

만약 AJP설정 같은게 필요없어서 server.xml을 지정할 것까지도 없고 포트만 지정하면 된다면 아래처럼 하면 됩니다.

<configuration>
    <path>/</path>
    <port>8080</port>
</configuration>

그리고 port도 지정할 필요가 없이 디폴트인 8080으로 띄우고 싶다면 "<port/>" 부분도 생략해도 됩니다.

장점은 Tomcat이니까 다른 개발서버, 운영서버와 똑같은 환경이고, 같은 에러메시지가 뜬다는 점입니다. 그리고 server.xml을 지정할 수 있으니 AJP연결등으로 Apache와 연동하는 개발에도 쓸 수 있습니다. WTP가 꼬인 것 같을 때 mvn tomcat:run으로 확인해보고 다시 Eclipse의 WTP로 돌아가기도 합니다.

위 Plugin은 org.codehaus.mojo의 아래에 존재했지만, 최신 버전은 아래 링크의 Apache Tomcat 프로젝트 산하로 들어갔습니다.

Tomcat7은 아래와 같이 지정합니다.

    <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.2</version>
        <configuration>
            <path>/</path>
        </configuration>
    </plugin>

mvn tomcat7:run 으로 실행할 수 있습니다.

마찬가지로 Tomcat6 plugin도 활용할 수 있습니다.

    <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat6-maven-plugin</artifactId>
        <version>2.2</version>
        <configuration>
            <path>/</path>
        </configuration>
    </plugin>

mvn tomcat6:run 으로 실행합니다.

참고로 spring-loaded를 함께 쓰면 Tomcat재시작 횟수를 줄일수 있습니다. ( https://gist.github.com/benelog/aee89ac5b6ff896b2e0f 참조 )

Winstone, 경량 Servlet container

Fri, 25 Nov 2011 00:00:00 +0000

Winstone(http://winstone.sourceforge.net/ )은 jar파일 하나로 실행되는 간단한 Servlet Container입니다.

FTP처럼 서버에 있는 파일을 다운로드 할 때나, 웹애플리케이션을 jar파일로 패키징해서 WAS 설치없이 독립적으로 실행되도록 만드는 용도로 사용할 수 있습니다.

참고로, Hudson에서도 winstone을 활용하고 있습니다. hudson.war를 WAS에 설치하지 않아도 java -jar 로 바로 실행시킬 수도 있는데, 이 기능이 Hudson 패키징 파일 안에 내장된 winstone을 이용하는 방식입니다.

이 winstone을 간단하게 활용하는 방법을 정리해봤습니다.

FTP대용으로 쓰기

아래 URL에서 winstone의 jar파일이 제공됩니다.

http://sourceforge.net/projects/winstone/files/

저는 접근하기 편한 URL에 올려놓고 wget 으로 다운로드하고 있습니다.

wget benelog.net/winstone.jar

받은 파일을 java -jar 로 간단하게 실행하면 됩니다.

현재 디렉토리를 최상위 폴더로 실행하려면 아래와 같이 하면 됩니다.

java -jar winstone.jar --webroot=.

HTTP 포트를 지정하려면 --httpPort 옵션을 붙이면 됩니다.

java -jar winstone.jar --webroot=. --httpPort=18080

그런 다음 해당서버에 지정된 포트로 접근하면 디렉토리의 파일 목록이 뜹니다. FTP와는 다르게 비밀번호가 없이 접근이 되므로 보안문제가 염려된다면 외부에 공개되지 않은 포트로 띄어야 하겠습니다.

그외의 다양한 옵션은 Winstone의 사이트(http://winstone.sourceforge.net/ )에 자세히 나와 있습니다.

웹애플리케이션을 jar파일 하나로 실행되도록 패키징

앞선 hudson의 사례처럼, 별도의 WAS설치 없이 웹어플리케이션 배포 파일 자체에 WAS를 내장하는 방식입니다.

Jetty를 애플리케이션 안에서 직접 심어서(Embedding) 실행시켜도 같은 효과가 있습니다. 제가 간단하게 만들었던, dumper라는 도구에서도 그 방식을 활용했습니다.

https://github.com/benelog/dumper/blob/master/src/main/java/Start.java

Jetty를 war파일 안에 패키징해서 독립적으로 실행가능한 방식도 있습니다. 아래 자료에 설명되어 있습니다.

그런데 위의 방식은 따로 실행 시작점이 되는 클래스를 만들어줘야하고, maven설정을 다소 많이 고쳐야하는 단점이 있습니다.

이에 반해서 winstone은 소스파일은 하나도 건드릴 필요없이, maven 설정도 건드리지 않거나 약간만 추가해서 혼자서 실행되는 jar파일을 만들어줍니다.

아무런 설정이 없어도 아래와 같이 실행하면 taget 폴더 아래에 .jar파일을 만들어 줍니다.

mvn net.sf.alchim:winstone-maven-plugin:embed

그리고 pom.xml에 아래 설정을 추가하면 'mvn package’로 패키징을 할 때마다 war파일과 함께 독립실행 가능한 jar파일도 만들어줍니다.

      <plugin>
        <groupId>net.sf.alchim</groupId>
        <artifactId>winstone-maven-plugin</artifactId>
        <version>1.2</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>embed</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

제가 만든 예제인 간단하게 서버에 파일을 올리는 프로그램에서도 이 방식을 썼습니다. 아래의 pom.xml에 이 설정에 포함되어 있습니다.

https://github.com/benelog/uploader/blob/master/pom.xml

위 프로젝트를 받고서 mvn package를 하면 target 폴더 아래에 uploader.jar가 생기는데 java -jar uploader.jar 만 하면 웹애플리케이션이 실행되는 것이죠.

어디에 쓸까?

직접 서비스 운영과 서버관리를 담당하는 일반적인 웹애플리케이션에서는 Winstone을 쓸 일이 그다지 많아보이지는 않습니다. 다만 Huson처럼 패키징해서 배포하고, 여러 가지 옵션을 제공하는 패키지성 웹애플리케이션에서는 고려해볼만도 합니다. 유사하게 Lucene바탕의 API서버인 Solr(http://lucene.apache.org/solr/)에서는 Jetty를 이용한 stand-alone 실행모드를 제공합니다. 그리고 간단히 소수의 인원이 쓰는 관리도구나, Desktop application 성격의 프로그램이라도 Swing, AWT대신 Web의 UI 기술을 이용하고 싶을 때도 Winstone을 포함한 패키징을 고려해볼만도 합니다.

하지만 비슷한 용도의 Jetty와 비교해볼 때 winstone이 유망하다고 생각하지는 않습니다. 2008년도 이후에는 프로젝트 업데이트가 안 되고 있어서 앞으로의 전망이 어두워보입니다. 계속 이런 상태라면 Hudson에서도 언젠가는 Jetty로 갈아타지 않을까하는 생각도 듭니다. 별도로 클래스를 만들지 않아도 되는 장점등도 언젠가는 Jetty에서도 제공될수 있어 보입니다. 그리고 jsp를 쓰는 프로젝트에서는 따로 라이브러리를 지정해야 하는 것도 다소 번거롭습니다.

그래도 Wistone은 알아두면 서버에서 파일 주고 받을 때라도 유용하게 쓸 수도 있고, 교육 용도의 실습 프로젝트, 취미용 프로젝트에도 편하게 활용해볼만한 도구입니다.

Java Stack dump 다운로드를 편하게

Sun, 20 Nov 2011 00:00:00 +0000

실행 중인 Java 프로세스의 Stack dump를 뜨는 작업은 간단합니다. Jstack 이나 kill -3 뒤에 process id를 지정하기만 하면 됩니다. Stack dump를 서버에 있는 stack dump파일을 PC로 옮길때면 Secure CRT나 putty에서 console에 찍히는 내용을 파일로 저장하는 기능을 주로 쓰고 있습니다.

언젠가 테스트를 한다고 자주 Stack dump를 뜨다보니 이런 작업마저도 번거롭게 느껴졌습니다. 그리고 파일이름에 timestamp가 들어가 있으면 나중에 찾아보기가 편한데, 그런 파일명 지정도 수동으로 하려니까 귀찮았습니다. 그래서 간단한 프로그램을 만들어 봤었습니다.

보통은 서버에서 vi로 덤프를 보는 때가 많아서 저도 잘 쓰지는 않는데, 그래도 코딩하면서는 재밌었던 기억이 나네요.

다운로드

wget file.benelog.net/dumper.jar 혹은 웹브라우저로 benelog.net/dumper.jar 접근해서 저장

실행

Windows : java -cp "dumper.jar;%JAVA_HOME%/lib/tools.jar" Start [port number]
Linux : java -cp "dumper.jar:$JAVA_HOME/lib/tools.jar" Start [port number]

Console 창에는 아래 메시지가 찍힙니다.

Usage:

 (Windows)

   Prompt>java -cp "dumper.jar;%JAVA_HOME%/lib/tools.jar" Start [port]

 (Linux)

   Prompt>java -cp dumper.jar:$JAVA_HOME/lib/tools.jar Start [port]

-----------------------------

The port is selected by ramdom.

Web address: http://192.168.0.11:17456

2011-11-20 04:04:32.901:INFO::jetty-7.x.y-SNAPSHOT

2011-11-20 04:04:33.248:INFO::started o.e.j.s.ServletContextHandler\{/,null}

2011-11-20 04:04:34.526:INFO::Started SelectChannelConnector@0.0.0.0:17456

파라미터로 port번호를 넘겨서 원하는 포트로 웹페이지를 띄울 수가 있는데, 지정된 포트가 없다면 10000번에서 20000번 사이의 포트를 임의로 찍어서 띄어줍니다. 위에 "Web address" 라고 적힌 칸 옆의 주소가 접근할 수 있는 URL입니다.

사용법

Console창에서 알려주는 주소를 웹브라우저 입력하면 아래처럼 jps의 정보를 보여주는 화면이 뜹니다.

pid를 찍으면 지정한 JVM의 jstack dump를 바로 다운로드할 수 있습니다.

파일명은 {pid}_{연도}-{일월}-{시분초}.log의 형식으로 했습니다.

혹시 덤프파일을 생성하는데 아래 에러 메시지가 뜬다면, 장비에 여러개의 JVM이 설치되어 있으면서 덤프를 뜨려는 JVM 프로세스와 tools.jar를 classpath로 지정한 경로의 JVM이 다르지 않는지 확인해보셔야 합니다.

java.lang.UnsatisfiedLinkError: no attach in java.library.path
com.sun.tools.attach.AttachNotSupportedException: no providers installed
        at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:190)

구현방식

Jps나 Jstack과 유사하게 sun.jvmstat.monitor 패키지의 클래스를 이용한 프로그램입니다.

http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/jvmstat/sun.jvmstat.monitor.htm

참고로 jdk의 tools.jar는 따로 배포하면 license에 어긋난다고 알고 있어서 묶어서 패키징하지 않고 classpath로 지정하도록 했습니다.

전체 소스는 github에 올렸습니다.

https://github.com/benelog/dumper

간단하게 서버에 파일을 올리기 + MockMultipartFile을 이용한 테스트

Sun, 23 Oct 2011 00:00:00 +0000

서버에 1,2개 파일만을 올려야할 때는 FTP를 따로 설치하는 일이 번거롭다고 느껴집니다. 그럴 때 간단하게 다운받아서 실행할 수 있는 웹어플리케이션을 만들어봤습니다.

jar파일 하나만 다운로드 받아서 바로 실행시키면 됩니다.

다운로드

wget file.benelog.net/uploader.jar

실행

java -jar uploader.jar (디폴트로 8080포트)
java -jar uploader.jar --httpPort=2010 (포트지정)

서버를 브라우저로 접속해서 파일을 올리기

예) http://localhost:8080/

따로 Tomcat과 같은 WAS를 설치할 필요가 없도록 경량 WAS인 Winstone(http://winstone.sourceforge.net/) 과 함께 패키징했습니다.

소스코드는 github에 올려놨습니다. ( https://github.com/benelog/uploader/ )

특별한 코드는 없지만, 아래 클래스에서 MockMultipartFile를 이용해서 파일업로드에 대한 테스트코드를 만들면서 나름 재미있었습니다.

https://github.com/benelog/uploader/blob/master/src/test/java/net/benelog/uploader/UploadControllerTest.java

Btrace로 DBCP의 connection정보를 모니터링 하기

Wed, 28 Sep 2011 00:00:00 +0000

Connection pool을 library로 DBCP를 많이 사용하고 있습니다. DataSouce가 선언되어 있는 설정 파일을 보면 min, max Connection 숫자는 쉽게 알 있지만, 현재 Active 한 것이 몇개 인지등은 실행시간에 쉽게 알아보기가 쉽지가 않죠. 그래서 JMX로 현재 Active한 Connection 수 등을 노출하는, DBCP를 한번 감싼 DataSource를 사용하기도 합니다.

Btrace를 이용하면 비교적 간단하게 DBCP의 속성들을 값들을 확인할 수 있습니다. 이미 실행되고 있는 JVM에도 붙일 수 있으니 설정을 바꾸고 WAS를 재시작하지 않아도 됩니다.

아래와 같이 간단한 소스로도 가능합니다.

import static com.sun.btrace.BTraceUtils.*;
import java.lang.reflect.Field;
import com.sun.btrace.BTraceUtils.Sys;
import com.sun.btrace.annotations.BTrace;
import com.sun.btrace.annotations.OnMethod;
import com.sun.btrace.annotations.Self;

@BTrace
public class DbcpMonitorSimple {

  private static final String DS_CLASS = "org.apache.commons.dbcp.BasicDataSource";

  @OnMethod(clazz = DS_CLASS, method = "getConnection")
  public static void onGetConnection(@Self Object basicDataSource) {
    Field urlField = field(DS_CLASS, "url");
    Object url = get(urlField, basicDataSource);
    print("=====DBCP BasicDataSource info (");
    print(url);
    println(" ) ==========");
    printFields(basicDataSource);
    Field poolField = field(DS_CLASS, "connectionPool");

    Object pool = get(poolField, basicDataSource);
    println("=====connectionPool (GenericObjectPool) info====");
    printFields(pool);
    println("==========");
    Sys.exit(0);
  }
}

DataSource.getConnection 요청이 있을 때 해당 객체를 얻어와서 속성값들을 찍어줍니다.

그리고 필요한 필드만 찍는다던지, 보기좋게 정렬한다던지 하는 작업은 필요에 따라 하면 되겠죠.

jps로 모니터링하고자 하는 JVM의 pid를 확인하고, btrace [pid] DbcpSimpleMonitor.java 로 실행하면 아래와 같이 속성값들을 쭉 찍어줍니다.

>btrace 4288 DbcpMonitor.java


=====DBCP BasicDataSource info (jdbc:hsqldb:file:store;shutdown=true ) ========

{defaultAutoCommit=true, defaultReadOnly=null, defaultTransactionIsolation=-1, d

efaultCatalog=null, driverClassName=org.hsqldb.jdbcDriver, driverClassLoader=nul

l, maxActive=8, maxIdle=8, minIdle=0, initialSize=0, maxWait=-1, poolPreparedSta

tements=false, maxOpenPreparedStatements=-1, testOnBorrow=false, testOnReturn=fa

lse, timeBetweenEvictionRunsMillis=-1, numTestsPerEvictionRun=3, minEvictableIdl

eTimeMillis=1800000, testWhileIdle=false, password=, url=jdbc:hsqldb:file:store;

shutdown=true, username=sa, validationQuery=null, validationQueryTimeout=-1, con

nectionInitSqls=null, accessToUnderlyingConnectionAllowed=false, restartNeeded=t

rue, connectionPool=org.apache.commons.pool.impl.GenericObjectPool@1f31079, conn

ectionProperties={user=sa, password=}, dataSource=org.apache.commons.dbcp.Poolin

gDataSource@be8958, logWriter=java.io.PrintWriter@12b1ff9, abandonedConfig=null,

 closed=false, }

===== number of Active : 0

==========

FIeld 객체를 얻어올 때 field(String,String)을 쓰면 static 필드초기화나 @OnMethod 메소드가 붙지 않은 메소드에서는 객체가 얻어지지 않는 에러가 있었습니다.

인터넷을 찾아보니 아래와 같이 비슷한 현상을 겪은 사람이 있었습니다.

http://kenai.com/projects/btrace/forums/forum/topics/1366-Drilling-into-a-method-argument-s-properties

결국 @OnMethod 가 붙지 않는 메소드에서 호출을 할 때는 field(classof(obj), "fieldName") 과 같이 피해가는 방법을 썼습니다. 되도록 메소드에서 매번 호출할 필요가 없는 부분은 static 초기화를 시킬 수 있었으면 하는데, static 초기화로는 하는 것도 잘 되지 않았습니다. 직접 field(BasicDataSource.class, "fieldName)으로 를 참조하기는 것도 잘 안 되었고, field(String,String)으로는 참조가 안 되었습니다. 이것만 아니면 좀 더 최적화된 호출을 할 수 있었을 것 같습니다.

첨부한 파일들은 아래와 같은 다소 다른 방식이나 출력형식으로 택했습니다.

DbcpMonitorSimple.java : BasicDataSource.getConnection이 한번 호출될 때 BasicDataSource의 모든 정보와 BasicDataSource.connetionPool의 정보를 출력
DbcpMonitor.java : 이벤트 방식은 1과 같고, BasicDataSource의 모든 필드와 BasicDataSource.connetionPool에서 _numActive 값만을 보여줌
DbcpActiveConnectionMonitor.java : 여러 개의 Datasource의 Active connection 갯수를 구할 때 사용. getConnection에서 URL별로 active connection 갯수를 저장해 두었다가, Btrace에서 이벤트를 날리면 출력을 해주고 종료

첨부한 스크립트 중 1,2번은 getConnection이 한번 호출되고 나면 스크립트를 종료하는 구조라서 큰 부하는 없겠지만, 증가 추이 등의 통계 정보를 쌓는기능 등이 필요하다면 Field poolField = field(DS_CLASS, "connectionPool"); 같은 부분도 중복호출되지 않게 하는 처리가 필요합니다.

소스는 gist에 올렸습니다. ( https://gist.github.com/1246239 )

Kent Beck과의 인터뷰 중에서..

Tue, 21 Jun 2011 00:00:00 +0000

2010년 9월에 Kent Beck과의 인터뷰가 SE-Radio 사이트에 올라왔었습니다.

http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/

이 인터뷰 중에 아래 내용이 가장 인상 깊었고, 몇달이 지나서도 기억에 남아있습니다.

19분 경에 나오는 내용입니다.

받아쓴 내용

Martin(사회자):

Do you think you’ve convinced most of people you talk to?

Kent Beck :

I don’t try to convince people any more.I think I spent probably 10 years really trying to convince people TDD, pair programming, you should do this, you should do that and I don’t do that any more.

I am always working to improve my own practice, I am eager to share what I learn and I try and listen and understand what other people learned and their experiences as well. So I don’t like … I don’t really keep score by how many people do TDD.

If the practice of software development is improving overall, then I think that’s a great thing, If I have some small influence on that, then I think that’s a great thing too.

번역

마틴(사회자)

그동안 이야기한 사람들을 대부분 설득했다고 생각합니까?

켄트벡 :

저는 더 이상 사람들을 설득하려 하지 않습니다. 저는 거의 10년동안 사람들에게 TDD를 꼭해라, 짝프로그래밍을 꼭 해라고 설득하려고 애써왔지만, 더 이상 그렇게 하지 않습니다.

전 항상 제가 수행하는 방식을 개선하려고 일하고, 제가 시도하고 배운 것을 공유하려고 노력합니다. 다른 사람이 배운 것과 경험도 듣고 이해하려 하구요. 그래서 전 얼마나 많은 사람들이 TDD를 하는지를 가지고 점수를 매기지는 않습니다.

소프트웨어를 개발하는 방식이 전반적으로 나아진다면 전 그걸 대단한 일이라고 생각하고, 만약 제가 거기에 약간의 영향이라도 끼친다면 역시나 대단한 일이라고 생각합니다.

Spring AOP의 Aspect에서 order 값에 따른 적용순서 확인해보기

Mon, 30 May 2011 00:00:00 +0000

Spring AOP에서 동일한 target클래스에 결합되는 Aspect의 우선순위는 Ordered 인터페이스를 구현하거나 @Order 애노테이션으로 지정합니다.

아래와 같은 방식입니다.

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.core.annotation.Order;

@Aspect
@Order(1)
public class OrderOneAspect {
    @Before("execution(void *.run())")
    public void printOrder(JoinPoint jp){
        System.out.println("order 1");
    }
}

import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.core.Ordered;



@Aspect
public class OrderTwoAspect implements Ordered{
    @Before("execution(void *.run())")
    public void printOrder(JoinPoint jp){
        System.out.println("order 2");
    }
    public int getOrder() {
        return 2;
    }
}

OrderOneAspect 은 애노테이션으로, OrderTwoAspect은 인터페이스로 order 값을 선언했습니다.

Ordered 인터페이스의 javadoc에 보면 order의 숫자 값이 작을수록 우선 순위가 높다고 적혀 있습니다.

The actual order can be interpreted as prioritization, with the first object (with the lowest order value) having the highest priority.

그렇다면 AOP에서는 여러개의 Aspect를 엮을 때 order값을 낮게 선언한 Aspect가 먼저 실행될까요?

한번 테스트코드를 짜봤습니다. 위의 OrderOneAspect , OrderTwoAspect와 함께, 각각 0과 -1의 order를 가지는 Aspect를 더 추가했습니다.

@Aspect
@Order(0)
public class OrderZeroAspect {
    @Before("execution(void *.run())")
    public void printOrder(JoinPoint jp){
        System.out.println("order 0");
    }
}

@Aspect
@Order(-1)
public class OrderMinusOneAspect {
    @Before("execution(void *.run())")
    public void printOrder(JoinPoint jp){
        System.out.println("order -1");
    }
}

그리고 Target클래스와 Proxy를 만들어줄 설정을 javaConfig를 이용해서 추가합니다.

public class MainBeans {
    @Bean
    public ProxyConfig proxyCreator(){
        return new AspectJAwareAdvisorAutoProxyCreator();
    }
    @Bean
    public Runnable main(){
        return new Runnable(){
            public void run() {
                System.out.println("target executed");
            }
        };
    }
}

Aspect는 모두 "before" Advice로 그 Aspect의 order 값을 찍도록했고, 적용대상인 클래스는 단순히 "target executed"를 출력합니다. 출력창에 찍힌 내용을 보면 어떤 순서로 Aspect가 적용되는지 보입니다.

모두 ApplicationContext에 등록해서 Target클래스를 출력하는 테스트 코드를 만들었습니다.

public class AspectOrderTest {
    @Test
    public void checkOrder() throws Exception {
        GenericApplicationContext  context =
            new AnnotationConfigApplicationContext(
                OrderZeroAspect.class,
                OrderMinusOneAspect.class,
                OrderTwoAspect.class,
                OrderOneAspect.class,
                MainBeans.class);
        Runnable printer = context.getBean(Runnable.class);
        printer.run();
    }
}

출력 결과는 아래와 같습니다.

order 2 order 1 order 0 order -1 target executed

Order의 숫자가 큰 값이 먼저 나옵니다. 큰 Order 값인, 낮은 우선 순위인 Aspect가 먼저 실행되었다는 결과입니다. 제가 처음에 매뉴얼만 보고 이해한 의미와는 반대의 결과였습니다. 제가 설정을 잘못한 부분이 있는지도 모르겠지만, 이 결과만을 해석을 해보겠습니다.

Aspect에서 우선순위가 높다는 의미는 '안쪽의 proxy가 된다.'는 의미입니다. 즉, Proxy를 만들 때 Order값이 작은, 우선 순위가 높은 Aspect부터 먼저 Proxy를 만들고, 그 뒤에 다음 우선순위의 proxy들을 차례로 입혀갑니다. 그러니 'before' 나 'Around’Advice라면 가장 바깥 쪽에 Proxy로 입혀진 , order값이 큰, 우선순위가 낮은 Aspect의 코드가 먼저 실행됩니다.

정리하면, Order값 숫자가 작을수록 우선 순위가 높아지고, 우선 적용되어서 더 안 쪽에서 감싸지는 proxy가 되어서 타겟 Object의 코드와 붙어있는 Apspect가 된다는 의미입니다. 즉, Aspect 설정에서 order값의 숫자가 클 수록 target객체에서 더 멀어지는 바깥 쪽의 Proxy로 결합됩니다.

Spring의 @Scheduled로 지정된 크론 표현식을 테스트하기

Mon, 23 May 2011 00:00:00 +0000

변경 이력
- 2024.06.05 스프링 프레임워크 버전 5.3 이상에 맞는 코드로 수정

스프링에서는 @Schedule 애너테이션을 통해 크론 표현식으로 특정 메서드를 예약 실행할 수 있습니다. 그런데 실제로 잘 실행될지는 해당 시간이 되어야 알 수 있으므로 실수가 있어도 늦게 발견될 가능성이 높습니다. 예를 들면 매일 5시 20분, 40분, 60분에 실행될 일정을 지정하고자 했는데 "* 0/20 5 * * * ?"로 써야 할 표현식을 "* 0,20 5 * * * ?"으로 써놓고는 실운영 서버에 배포 한 후 하루가 지난 다음에 실수를 발견하는 경우입니다. 크론 표현식이 기대대로 해석되는지도 이 글을 참고하여 테스트 코드로 검증을 한다면 이런 사고를 막을 수 있습니다.

예제는 스프링 프레임워크 6.1.8 버전에 의존하여 작성되었으나 버전 5.3 이상에서는 동일한 방식으로 사용할 수 있을 것으로 예상합니다. 5.3버전을 기준으로 날짜 관련 클래스가 JDK 8의 API를 활용하는 방식으로 바뀌었습니다. 스프링 3.0 에서는 java.util.Date 등의 과거 API를 활용하는 방식으로 응용하실 수도 있습니다.

크론 표현식으로 예약 실행할 메서드 지정

대상이 되는 메소드에 @Schedule 애너테이션의 cron, zone 속성을 지정합니다. zone 속성은 필수는 아니지만 지정하면 명확성이 높아지고 시스템 기본값에 영향받지 않는다는 장점이 있습니다.

JobSchedule.java

import java.time.Instant;
import java.util.Properties;
import org.springframework.scheduling.annotation.EnableScheduling;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
@EnableScheduling
public class JobSchedule {

  @Scheduled(cron = "0 0,10 0 * * ?", zone = "Asia/Seoul")
  public void startHelloJob() {
    // 실행할 코드
  }
}

테스트 코드

크론 표현식을 추출하고 검사하는 코드는 ScheduleTestUtils 클래스로 분리했습니다.

import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.util.List;
import org.junit.jupiter.api.Test;

class JobScheduleTest {
  @Test
  void scheduleHelloJob() {
    var initialTime = LocalDateTime.of(2024, 6, 10, 0, 5);
    List<LocalDateTime> expectedTimes = List.of(
        LocalDateTime.of(2024, 6, 10, 0, 10),
        LocalDateTime.of(2024, 6, 11, 0, 0),
        LocalDateTime.of(2024, 6, 11, 0, 10)
    );
    ScheduleTestUtils.assertCronExpression(
        JobSchedule.class, "startHelloJob",
        toInstant(initialTime),
        expectedTimes.stream().map(this::toInstant).toList()
    );
  }

  private Instant toInstant(LocalDateTime time) {
    return time.atZone(ZoneId.of("Asia/Seoul")).toInstant();
  }
}

ScheduleTestUtils.java

import static org.assertj.core.api.Assertions.assertThat;

import java.lang.reflect.Method;
import java.time.Instant;
import java.util.List;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.scheduling.support.CronTrigger;
import org.springframework.scheduling.support.SimpleTriggerContext;
import org.springframework.util.ReflectionUtils;
import org.springframework.util.StringUtils;

public class ScheduleTestUtils {
  public static void assertCronExpression(
      Class<?> targetClass, String methodName,
      Instant initialTime, List<Instant> expectedTimes
  ) {
    Method method = ReflectionUtils.findMethod(targetClass, methodName);
    assertThat(method).isNotNull();

    Scheduled scheduled = method.getAnnotation(Scheduled.class);
    CronTrigger trigger = getTrigger(scheduled);
    var context = new SimpleTriggerContext(initialTime, initialTime, initialTime);

    for (Instant expected : expectedTimes) {
      Instant actual = trigger.nextExecution(context);
      assertThat(actual).isEqualTo(expected);
      context.update(actual, actual, actual);
    }
  }

  private static CronTrigger getTrigger(Scheduled scheduled) {
    // 스프링의 ScheduledAnnotationBeanPostProcessor 코드를 참고함
    if (StringUtils.hasText(scheduled.zone())) {
      return new CronTrigger(scheduled.cron(), StringUtils.parseTimeZoneString(scheduled.zone()));
    } else {
      return new CronTrigger(scheduled.cron());
    }
  }
}

Quartz 설정을 읽어서 CronExpression 테스트

Mon, 23 May 2011 00:00:00 +0000

Cron expression은 실수하기가 쉽고, 오류가 뒤늦게서야 발견됩니다. 매일 5시 20분, 40분,60분에 실행될 일정을 지정하고자 했는데 "* 0/20 5 * * * ?"로 써야 할 표현식을 "* 0,20 5 * * * ?"으로 써놓고는 실운영 서버에 배포해서 하루가 지난 다음에 실행결과를 보고서야 실수를 발견한 경험을 해보신 분들이 많으실 것입니다.

Cron expression도 테스트 코드를 짜서 검증을 해본다면 치명적인 실수를 막을 기회가 더 많아집니다.

아래 예제는 ApplicationContext에 설정되어 있는 Quartz의 CronTrigger의 일정을 테스트하는 코드입니다.

ApplicationContext의 스케쥴링 설정 파일

<bean id="schedulerFactoryBean" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
     <property name="triggers" ref="triggers"/>
</bean>
<util:list id="triggers">
     <bean p:jobName="baseballJob" p:cronE-pression="0 * * * * ?" parent="jobTrigger"/>
     <bean p:jobName="baseballExportJob" p:cronE-pression="30 5-7 * * * ?" parent="jobTrigger"/>
</util:list>

위의 설정 예제에서는 반복되는 설정을 간편하게 해주는 FactoryBean을 썼습니다. parent="jobTrigger"라고 지정된 부분이 FactoryBean 클래스와 연결되는 bean id를 지정한 속성입니다. 여기에 쓰인 FactoryBean은 이"jobName"과 "cronExpression" 속성을 받아서 org.quartz.CronTrigger 타입의 bean을 생성해주는 역할을 합니다.

JobTriggerFactoryBean

package edu.batch.support.launch;

import java.util.HashMap;
import java.util.Map;

import org.quartz.Trigger;
import org.springframework.batch.core.configuration.JobLocator;
import org.springframework.batch.core.launch.JobLauncher;
import org.springframework.batch.sample.quartz.JobLauncherDetails;
import org.springframework.beans.factory.FactoryBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.scheduling.quartz.CronTriggerBean;
import org.springframework.scheduling.quartz.JobDetailBean;
import org.springframework.util.Assert;

/**
 * @author sanghyuk.jung
 */
public class JobTriggerFactoryBean implements FactoryBean<Trigger>, InitializingBean {
    private JobLocator jobLocator;
    private JobLauncher jobLauncher;
    private String jobName;
    private String cronExpression;
    private String triggerName;

    /**
     * @return
     * @throws Exception
     * @see org.springframework.beans.factory.FactoryBean#getObject()
     */
    public Trigger getObject() throws Exception {
        CronTriggerBean trigger = new CronTriggerBean();
        trigger.setCronExpression(cronExpression);
        JobDetailBean jobDetail = createJobDetail();
        trigger.setJobDetail(jobDetail);
        if(triggerName == null ){
        trigger.setName(jobName+"Trigger");
        } else {
            trigger.setName(triggerName);
        }
        trigger.afterPropertiesSet();
        return trigger;
    }

    private JobDetailBean createJobDetail() {
        JobDetailBean jobDetail = new JobDetailBean();
        jobDetail.setName(jobName);
        Map<String, Object> jobData = new HashMap<String, Object>();
        jobData.put("jobName", jobName);
        jobData.put("jobLocator", jobLocator);
        jobData.put("jobLauncher", jobLauncher);
        jobDetail.setJobDataAsMap(jobData);
        jobDetail.setJobClass(JobLauncherDetails.class);
        jobDetail.afterPropertiesSet();
        return jobDetail;
    }

    /**
     * @return
     * @see org.springframework.beans.factory.FactoryBean#getObjectType()
     */
    public Class<Trigger> getObjectType() {
        return Trigger.class;
    }

    /**
     * @return
     * @see org.springframework.beans.factory.FactoryBean#isSingleton()
     */
    public boolean isSingleton() {
        return false;
    }

    public void setJobLocator(JobLocator jobLocator) {
        this.jobLocator = jobLocator;
    }

    public void setJobLauncher(JobLauncher jobLauncher) {
        this.jobLauncher = jobLauncher;
    }

    public void setJobName(String jobName) {
        this.jobName = jobName;
    }

    public void setCronExpression(String cronExpression) {
        this.cronExpression = cronExpression;
    }

    /**
     * @throws Exception
     * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
     */
    public void afterPropertiesSet() throws Exception {
        Assert.notNull(jobName, "jobName must be provided");
        Assert.notNull(jobLocator, "jobLocator name must be provided");
        Assert.notNull(jobLauncher, "jobLauncher name must be provided");
    }

    public void setTriggerName(String triggerName) {
        this.triggerName = triggerName;

    }
}

테스트 코드

triggers라는 bean 이름으로 List<CronTrigger> type의 객체를 가지고 와서, List안에서 지정된 trigger의 이름을 탐색한다음에 그 안에서 그 trigger의 cron e-pression을 검사했습니다. 테스트 코드를 간결하게 유지하기 위해서 Cron e-pression을 검사하는 코드는 QuartzCronExpressionTestUtils라는 클래스로 분리해서 static import로 처리했습니다. QuartzCronExpressionTestUtils.findTriggerByName 메소드는 List<CronTrigger> 타입의 객체가 담고 있는 여러개의 CronTrigger에서 지정된 이름의 CronTrigger를 반환해줍니다.

package edu.batch.baseball.schedule;

import static edu.batch.support.launch.QuartzCronE-pressionTestUtils.*;

import java.text.ParseException;
import java.util.Arrays;
import java.util.List;

import javax.annotation.Resource;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.quartz.CronTrigger;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration( { "classpath:/launch-context.xml" })
public class BaseballQuartzScheduleTest {

    private static final String DATE_PATTERN = "yyyy/MM/dd hh:mm:ss";

    @Resource(name = "triggers")
    List<CronTrigger> triggers;

    @Test
    public void testbaseballJobTriggerSchedule() throws ParseException {
        CronTrigger trigger = findTriggerByName(triggers, "baseballJobTrigger");
        String initialTime = "2010/09/01 09:00:00";
        List<String> expectedTimeList = Arrays.asList(
                "2010/09/01 09:01:00",
                "2010/09/01 09:02:00",
                "2010/09/01 09:03:00",
                "2010/09/01 09:04:00");
        assertSchedule(trigger, initialTime, expectedTimeList, DATE_PATTERN);
    }

    @Test
    public void testbaseballExportJobTriggerSchedule() throws ParseException {
        CronTrigger trigger = findTriggerByName(triggers, "baseballExportJobTrigger");
        String initialTime = "2010/09/01 09:00:00";
        List<String> expectedTimeList = Arrays.asList(
                "2010/09/01 09:05:30",
                "2010/09/01 09:06:30",
                "2010/09/01 09:07:30",
                "2010/09/01 10:05:30",
                "2010/09/01 10:06:30",
                "2010/09/01 10:07:30");
        assertSchedule(trigger, initialTime, expectedTimeList, DATE_PATTERN);
    }
}

QuartzCronExpressionTestUtils

package edu.batch.support.launch;

import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;

import java.text.ParseException;
import java.util.Date;
import java.util.List;

import org.apache.commons.lang.time.DateFormatUtils;
import org.apache.commons.lang.time.DateUtils;
import org.quartz.CronTrigger;

public class QuartzCronExpressionTestUtils {

    public static void assertSchedule(CronTrigger trigger, String initialTime,
            List<String> expectedTimeList, String datePattern) throws ParseException {
            Date previousStartTime = DateUtils.parseDate(initialTime,   new String[]{datePattern});

            for(String expectedTime : expectedTimeList){
                trigger.setStartTime(previousStartTime);
                Date nextExecutionTime =  trigger.getFireTimeAfter(previousStartTime);
                String actualTime = DateFormatUtils.format(nextExecutionTime, datePattern);
                assertThat("executed on expected time", actualTime, is(expectedTime));
                previousStartTime = nextExecutionTime;
            }
        }

    public static CronTrigger findTriggerByName(List<CronTrigger> triggers, String triggerName) {
        for (CronTrigger trigger : triggers) {
            if (triggerName.equals(trigger.getName())) {
                return trigger;
            }
        }
        throw new IllegalArgumentException("cannot find trigger : "
                + triggerName);
    }
}

SpringSource Tool Suite의 Java Agent based reloading 사용해 보기

Mon, 9 May 2011 00:00:00 +0000

SpringSource Tool Suite의 Java Agent based reloading은 개발할 때 .class파일을 고치면 그 파일만 리로딩을 시켜주는 기능입니다. JRebel과도 유사한데 아직 "Experimental' 표시가 붙어있고, 생긴지가 얼마안되는 기능이라서 JRebel만큼 성숙한 기술인지는 잘 모르겠습니다. 그래도 모든 경우에 다 reloading이 되지 않더라도 한번이라도 서버내렸다 올리는 시간을 절약할 수 있으면 그만큼 이득이기 때문에 없는 것보다는 도움이 됩니다.

이런 도구들이 있으면 좋기는 하지만 WAS올리기 전에 테스트 코드로 왠만한 건 다 검증을 하고, WAS 올려서는 JSP같은 View만 고치는 개발 방식이 바람직합니다. 테스트 코드를 잘 짜고 있다면 '개발 중에 WAS 리로딩한다고 시간이 많이 들어요..' 와 같은 이야기가 별로 안 나올 것입니다. 테스트 코드 작성은 익숙해지면 시간이 별로 안 걸리는 일입니다. 그리고 테스트 코드를 만들면 로직이 있는 모듈의 가까운 위치에서 다양한 케이스를 반복해서 테스트해 볼 수 있고, 에러 추적과 디버깅이 훨씬 편해집니다. 아무리 리로딩이 잘 지원된다고 해도, 화면을 띄어서 손으로 데이터를 매번 입력하는 시간을 없애줄 수는 없고, 리로딩이 시간보다 훨씬 긴 에러 추적과 디버깅 시간을 줄여줄 수는 없습니다. 그래서 결국에는 테스트코드 작성하는 것이 개발시간을 더 빠르게 합니다.

STS를 설치할 때 SpringSource Tool Suite를 한번에 받아서 설치했다면 Tc server도 같이 설치되지만, 이미 깔려진 Eclipse 위에 update를 했다면 tc Server는 아래 URL에서 별도로 받아야 합니다.

http://s9.springsource.com/products/tc-server-developer-edition-preview

Java agent based Reloading 설정

'Servers' Tab에서 New메뉴로 새 서버를 추가한다.
tc Server를 선택한다.
- SpringSource tc Server v2.0 혹은 v2.1 또는 v2.5를 선택한다.
- 참고로 SpringSource Tool Suite 2.6.1부터 tc server v2.5가 포함되어 있고, "VMware vFabric tc Server v2.5"라는 이름으로 "VM Ware" 분류 폴더 아래에 포함되어 있다.
처음 설정하는 것이라면, Tc sever가 설치된 위치를 지정합니다.
처음 설정하는 것이라면 "Create new instance"를 선택한다.
같이 설치할 모듈을 지정합니다. 간단하게 'base’와 'nio’만 선택해 된다.
설정된 Server의 "Overview" 탭에서 "Enable Java Agent-based reloading"을 선택한다.
시험 삼아서 서버를 시작해 본다..
서버가 시작되면서 "Agent based reloading is active"라는 메시지가 처음에 뜨면 제대로 설정이 된 것이다.

Java agent based reloading 테스트 해보기

테스트용 프로젝트를 생성해서 reloading이 되는지 확인하는 과정이다.

Ctrl +N을 누르고 "Spring Template Project"를 선택한다.
- 2."Spring MVC project"를 선택한다.
- 3.프로젝트명과 상위 패키지이름을 적는다.
생성된 프로젝트를 Run AS→ Run On Server로 실행한다.
실행할 서버는 Java Agent Based Reloading을 설정한 tc Server로 지정한다.
서버가 올라간 다음에 템플릿의 HomeController 클래스를 수정해보고, 메소드의 내용을 수정한 다음에 아래와 같이 전체 "Realoding…" 메시지가 보이며 applicationContext loading 없이 해당 클래스만 리로딩 되는 것을 확인한다.

테스트 결과

Dynamic web project가 아니고 external web module로 추가한 경우 - 잘 됨
Servlet만으로 된 프로젝트 - 잘됨
Application Context 파일 수정 - 되기도 하고 안 되기도 함
Spring MVC의 controller에 @RequestMapping이 달린 새로운 메소드를 추가한 것을 인식 - 잘 안 됨

java.net.InetAddress + SpEL로 서버이름을 Bean 설정에서 바로 얻어오기

Fri, 6 May 2011 00:00:00 +0000

Spring 3.0부터 추가된 SpEL(Spring E-pression Language)를 응용한 사례입니다.

application context 파일 선언만으로 특정 빈의 속성에 서버 이름을 넣으려면 어떻게 해야하냐는 질문을 받았습니다.

질문자는 아래의 bean설정에 "serverName"이라고 지정된 곳에 각각 실행되는 서버마다 다른 이름을 넣고 싶어했습니다.

persistentMessageStore 선언

<bean id="persistentMessageStore" class="org.springframework.integration.jdbc.JdbcMessageStore">
   <property name="region" value="serverName" />
....

</bean>

나름대로의 FactoryBean을 따로 만들거나 JavaConfig을 써도 쉽게 풀리는 문제이지만, SpEL을 활용하는 것이 기존 설정을 가장 적게 바꾸는 방식입니다.

아래와 같이 java.net.InetAddress.getLocalHost를 bean으로 등록합니다.

<bean id="localHost" class="java.net.InetAddress" factory-method="getLocalHost"/>

SPel이 잘 먹는지는 다음과 같이 테스트 할 수 있습니다.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class HostNameTest {
    @Value("#{localHost.hostName}") String hostName;
    @Test
    public void hostNameShouldBePrinted() throws Exception {
        String expectedHostName = InetAddress.getLocalHost().getHostName();
        assertThat(hostName,is(expectedHostName));
        System.out.println(hostName);
    }
}

위의 테스트 코드에서는 @ContextConfiuguration선언 뒤에 Application context 파일 위치를 지정하지 않았으므로, default로 참조되는 같은 패키지 디렉토리의 HostNameTest-context.xml에 'localHost' bean이 선언되어 있어야 겠죠.

제일 처음의 코드1의 bean선언에서도 마찬가지로 #{localHost.hostName} 을 참조할 수 있습니다.

<bean id="persistentMessageStore" class="org.springframework.integration.jdbc.JdbcMessageStore">
   <property name="region" value="#{localHost.hostName}" />
....

</bean>

SpEL을 활용하면 아래와 같이 bean사이의 연결을 더 유연하게 할 수도 있지만, 컴파일타임에 검증되지 않는다는 단점이 있습니다. 이를 보완하려면 오타를 검증할 수 있는 테스트 코드가 있어야 합니다.

다른 방법으로는, JavaConfig를 활용해서 직접 명시적으로 메소드를 호출해서 hostName을 주입해도 됩니다.

@Bean JdbcMessageStore persistentMessageStore(){
    JdbcMessageStore store = new JdbcMessageStore ();
    store.setRegion(localHost.getHostName());
    return store;
}

@Bean public InetAddress localHost() throws UnknownHostException {
    return  InetAddress.getLocalHost();
}

파일 업로드를 하는 Servlet을 MockHttpServletRequest로 테스트하기

Sun, 24 Apr 2011 00:00:00 +0000

파일 update를 처리하는 Servlet도 Spring의 MockHttpSerlvetRequest와 MockHttpServletResponse로 테스트 할 수 있습니다.

다음 링크에 있는 소스를 참고했습니다.

http://milandinic.blogspot.com/2009/05/testing-upload-servlet-under-spring.html

request의 content 속성에 파일내용 등을 포함시켜 주면 됩니다.

아래 예제에서 Assert부분은 화면에 출력되는 문자열을 검사하는 방식입니다. 테스트 하고자하는 목적에 따라 파일업로드가 되었을 때의 특정 위치에 파일이 생성된 것을 확인한다거나, 그 뒤에 호출되는 클래스를 행위검증하는 방식등을 다양하게 응용하실 수 있을 것입니다.

publicclassUploadServletTest {
    UploadServlet servlet =newUploadServlet() ;
    MockHttpServletRequest request =newMockHttpServletRequest();
    MockHttpServletResponse response =newMockHttpServletResponse();

    private static final String ENDLINE ="\r\n";

    private static final String BOUNDARY ="qWeRtY";

   @Test
    public void testUploadNormalFile() throws Exception {
        // given
        String fileContent ="for upload test";
        String fileName ="message.txt";
        String reqContent = createContentWithFile(fileName, fileContent);
        request.setContent(reqContent.getBytes());
        request.setContentType("multipart/form-data; boundary="+ BOUNDARY);
        request.setMethod("POST");

        // when
        servlet.service(request, response);

       // then
       String output = response.getContentAsString();
      assertTrue("정상적으로 업로드 되었을 때에는", output.contains("File size"));
    }

    @Test
   public void testUploadEmptyFile() throws Exception {
       // given
       String fileContent ="";
       String fileName ="message.txt";
       String reqContent = createContentWithFile(fileName, fileContent);
       request.setContentType("multipart/form-data; boundary="+ BOUNDARY);
       request.setMethod("POST");
       request.setContent(reqContent.getBytes());

       // when
       servlet.service(request, response);

      // then
      String output = response.getContentAsString();
      assertThat("빈 파일이 올라갔을 때에는", output, is("No binary data contains"));
    }

    private String createContentWithFile(String fileName, String fileContent) {
        StringBuilder reqContent =newStringBuilder();
        reqContent.append("--"+ BOUNDARY + ENDLINE);
        reqContent.append("Content-Disposition: form-data; name=\"myfile\";"
        +" filename=\""+ fileName +"\""+ ENDLINE);
        reqContent.append(ENDLINE);
        reqContent.append(fileContent);
        reqContent.append(ENDLINE);
        reqContent.append("--"+ BOUNDARY +"--"+ ENDLINE);
        return reqContent.toString();
    }
}

참고로 Spring에서는 MockMultipartHttpServletRequest와 MockMultipartFile 같은 첨부파일에 특화된 테스트 전용 클래스를 제공하기는 하지만, Spring MVC를 사용하지 않는 그냥 Servlet에서는 위의 방식처럼 MockHttpServletRequest을 사용해야 합니다.

내가 생각하는 TDD

Sun, 6 Mar 2011 00:00:00 +0000

(이미지 출처: https://mystorypie.com/learn/ko/invention/traffic-light/ )

컴퓨터가 내 의도를 이해했는지 표시하는 신호등을 설치하고, 그 신호에 의지해서 사람이 더 읽기 편하고 고치기 쉬운 코드를 개발하는 기법입니다.

처음에는 내가 만드는 프로그램 조각이 어떤 상황에서 어떤 결과를 내는지 설명하는 글을 씁니다. 이것을 명세나 테스트라고 부르고 컴퓨터가 해석하고 실행가능한 형식으로 만듭니다. 그 설명을 컴퓨터가 실행해서 의도한 결과인지를 신호등으로 알려주게 합니다. 다음에는 그 설명과 맞아떨어지는 코드를 작성합니다. 신호등은 파란색이 되었다면 코드에 실린 사람의 의도를 모두 컴퓨터가 잘 받아들였다는 의미입니다. 파란색은 다음 발걸음을 내딛을 수 있다는 신호이기도 합니다.

컴퓨터를 이해시킨 다음에는 사람이 더 편안하게 읽을 수 있는 코드로 다듬어야 합니다. 다시 코드를 보는 사람이 헷갈리지 않도록 중복을 없애고, 의도를 더 확실하게 표현하도록 이름을 바꾸거나 프로그램 조각의 일부를 빼내서 정리합니다. 자신이 있어서 처음부터 컴퓨터와 사람에게 모두 충분한 코드를 만들었다면, 발걸음을 크게 해서 바로 그 다음 설명과 신호등을 만듭니다. 교통 신호등처럼 시간이 고정되어 있지 않고, 신호 사이의 간격, 신호등이 확인하는 설명의 크기와 다음 신호등을 만드는 시기를 마음대로 조절해도 됩니다. 그런데 하다보면 자주 파란불을 보고 싶어서 간격을 짧게 만들고 싶어집니다.

이런 과정을 거치다보면 여러 가지를 얻습니다. 신호등이 연결된 설명서는 컴퓨터와 사람이 모두 이해할 수 있는 문서입니다. 잘 설명되고, 검증될 수 있는 코드들은 역할과 책임이 명확해서 다음에 기능을 추가하거나, 수정을 할 때 더 적은 노력이 들어갑니다. 중간 중간 내부에 설치된 신호등을 한꺼번에 켜보면 엑스레이 사진처럼 프로그램 속이 들여다 보입니다. 깊숙이 박혀 있는 오류를 찾아내는 시간도 줄여줍니다. 무엇보다 빨간불, 파란불을 왔다갔다 하다보면 프로그래밍이 더 역동적인 일이 됩니다. 컴퓨터와 반응을 주고 받는 것이 마치 게임과 비슷해집니다. 파란불을 볼 때마다 뭔가 끝을 내고 성취했다고 느껴지고 칭찬을 받는 기분으로 그 다음 작업을 할 수 있는 힘을 얻습니다. 그래서 프로그래밍이 더 재미있어지고, 집중도 잘 됩니다.

신입사원 교육을 하면서 주로 유명인들이 이야기한 TDD의 여러 측면들을 인용해서 설명을 했습니다. 그런데 정말 저만의 단어로 TDD를 설명한다면 어떻게 할까. 스스로 궁금해졌습니다. 적고 나니 계속 다듬어야 할 것 같네요.

스프링과 클라우드가 무슨 상관이 있을까?

Thu, 3 Mar 2011 00:00:00 +0000

(덧붙임: 이글을 쓰던 시점의 CloudFoundry는 지금의 CloudFoundry와는 다른 기술이였고, 이전 CloudFoundry는 http://classic.cloudfoundry.com/ 으로 옮기어 갔습니다. )

스프링, 클라우드를 내세우다.

스프링 프레임워크의 개발사인 스프링소스(SpringSource)와 VMWare는 최근 스프링이 클라우드 환경에 적합한 기술이라고 홍보를 하고 있다. 현재 스프링과 관련이 있는 클라우드 플랫폼은 아래와 같다.

vFabric

VMWare에서 제공하는 프라이빗 클라우드를 위한 솔루션이다. VMWare의 가상화 솔루션과 스프링소스의 미들웨어, 프레임웍, 개발도구 등을 합한 기술 스택을 제공한다.

Coludfoundry (http://www.cloudfoundry.com/ )

스프링소스가 인수해서 운영하는 클라우드 서비스이다. 아마존의 AWS 인프라를 이용하고, Tomcat 등의 미들웨어를 제공한다.

VMForce (http://www.vmforce.com/ )

VMWare와 세일즈포스닷컴이 제휴한 클라우드이다. force.com 데이터베이스를 저장소를 이용하고, 스프링,Tomcat, vSphere 같은 VMWare의 솔루션이 들어간다.

VMFoce 클라우드 (출처 vmforce.com)

Google App Engine

구글과 VMWare의 제휴로 Google App Engine에 대한 지원이 스프링소스의 개발도구에 들어가게 되었다. Spring-roo에서 Google App Engine의 저장소를 쓸 수 있도록 JPA의 Provider로 Datanucleus를 선택할 수 있다.

2010년 10월에 열린 스프링원 컨퍼런스에서도 클라우드에 대한 홍보는 두드러졌다. 자사의 클라우드 솔루션인 vFabric과 CloudFoundry는 물론, VMForce와 Google App Engine 과도 스프링을 묶어서 홍보했다. 스프링원 2010의 플레티엄 스폰서 세 곳 중 두 곳이 구글과 세일즈포스닷컴이였다는 것을 봐도 그 컨퍼런스의 초점은 알 수 있었다

스프링은 애플리케이션 프레임워크일 뿐인데, 과연 클라우드와 무슨 관련이 있다는 것일까? 클라우드의 핵심기술은 가상화나 분산 저장소 같은 기술이 아닐까? 클라우드 환경에서 JVM만 제대로 갖추어진다면 스프링이 아닌 스트럿츠나 구글쥬스라고 해도 안 돌아갈 이유는 없지 않은가? 요즘은 서버 여러 대만 쓰는 기술이면 다 클라우드라는 이름을 붙이고 싶어하던데, 스프링도 이런 유행에 묻어 가고 싶은 마음이 아닐까? 여러 가지 의구심이 들만도 하다.

그러나, 이를 억지 홍보 전략이라고만 생각하면서 그냥 넘어가는 것보다는 왜 VMWare ,구글, 세일즈포스닷컴이 스프링을 클라우드에 끼워 맞추면서 제휴를 하고 있는지를 분석해 본다면 기술의 흐름을 이해하는데 도움이 될 것이다.

지난 10년, 그리고 수익 모델

널리 알려 진 것처럼, 스프링은 EJB의 초기 시대에 Java EE 표준에 대한 대안 기술로 시작되었다. 스프링의 아버지 로드존슨은 초기 EJB의 어려움을 해결한 자신만의 프레임워크를 만들었고, 그 코드를 저서 “Expert one to one J2EE development”에 공개했다. 그 코드가 많은 개발자들의 호응을 얻어서 오픈소스 프로젝트가 되었다. 스프링 프레임워크는 세계 10대 은행 중 9개가 쓰고 있다고 할 정도로 인기를 끌었고[주1], 핵심 개발자들은 사업체를 차리고, 벤처 캐피탈의 투자를 받기에 이른다.

스프링소스는 창업 이후에 계속 수익 모델을 고심 했을 것이다. 과연 어플리케이션 프레임워크만으로 어떻게 수익을 창출할 것인가? 한 때 스프링소스에서는 엔터프라이즈 서비스라는 것을 만들어서 라이선스를 산 고객에게 좀 더 편하게 마이너패치 버전을 제공하는 정책을 고려하기도 했었다[주2].

그리고 인수 합병을 통해 프레임워크 이외의 제품군도 확보를 한다. 스프링소스가 처음으로 인수한 업체는 Tomcat과 Apache Httpd의 핵심개발자들이 있는 Covalent라는 업체였다[주3]. 프레임워크와 미들웨어를 통합한 서비스를 제공한다는 명분이였지만, 프레임워크만으로는 수익 창출에 한계가 있었기에 그런 결정을 했을 것이다.

더욱 놀랍게도 스프링소스 자체가 2009년 4억 2천만 불(당시 환율로 5천3백억원 정도[주4]) 의 가격에 VMWare에 인수된다. 00만원짜리 서버 53만대의 가격이니 그 가격도 놀랍지만 무엇보다 인수자가 의외였다. 오라클이나 IBM처럼 자바 개발자가 친숙한 미들웨어를 많이 파는 업체가 아니였고, 자바와는 멀리 떨어진 듯한 가상화 솔루션으로 유명한 업체인 VMWare였기 때문이다.

로드존슨은 확장성 있는 사업모델을 고민했다[주5]. 컨설팅과 교육만으로는 인건비를 바탕으로 하는 수익 구조가 된다. 그래서 제품과 서비스를 판매하는 사업 모델도 필요했다. 그런데 제품도 상용 버전과 오픈소스 버전의 차이를 지나치게 크게 둔다면 오픈소스 커뮤니티를 홀대한다는 비판을 받을 수도 있다. 스프링소스에서는 Tc server라는 Tomcat에 기능을 강화한 제품을 판매하고 있다. 그러나 Tc Server에는 없는 버그가 Tomcat에는 있다면 많은 비판이 쏟아질 것이다. 제품 판매에도 어느 정도 한계가 있다 보니 더 확장성 있는 사업 모델인 클라우드 서비스와 스프링을 연결시키려고 했을 것이다. 그래서 클라우드 서비스 업체인 CloudFoundry를 인수했고, 결국 VMWare와 손을 잡았다.

이러한 사업 배경과는 별도로 스프링과 클라우드를 연관시키는 것이 기술적으로 무리 수는 아닌지, 그 연결에 어떤 노력을 하고 있는지 살펴보아야 할 것이다.

스프링 포트폴리오의 확장과 클라우드

VMWare의 인수 이후로, 스프링 포트폴리오의 발전 속도는 더욱 빨라 지고 있다. 최근 Spring-Android, Spring-Hadoop같은 프로젝트를 보면 자바 기술 중 스프링이 건드리지 않은 영역이 바로 생각나지 않을 정도이다. 이 중 클라우드와 관련이 있는 기술들은 아래와 같이 나누어 정리해 볼 수 있다.

첫째, 대용량 처리 미들웨어를 직접 스프링에서 인수한 것들이다. AMQP(Advanced Message Queuing Protocol) 바탕의 메시징큐 솔루션인 RabbitMQ와 데이터그리드 기술인 GemFire가 여기에 해당한다. 비동기 처리와 데이터 캐쉬는 대용량 처리가 많은 클라우드 환경에서 더욱 많이 쓰이는 기술이 될 것이다.

둘째, 분산 저장소에 대한 API의 래핑(Wrapping)을 제공하는 것이다. Spring-data라는 프로젝트 아래에서 많은 저장소를 위한 프로젝트들이 진행되고 있다. 이미 Redis, Riak, CouchDB , MongoD, Neo4j등을 지원한다. 물론 꼭 스프링에서 지원해 주지 않아도 그런 저장소를 쓰는 데에는 문제가 없다. 그런 프로젝트의 의도는 JDBC를 바로 사용하는 것보다 Spring-jdbc를 사용하는 것처럼, 저장소 API도 스프링의 설정과 프로그래밍 방식으로 API를 편리하고 일관성 있게 사용하도록 도와 주는 것이다. 물론 저장소 API들이 JDBC만큼 불편하지는 않겠지만, Template-callback 패턴으로 반복된 Try-catch를 줄일 수 있는 부분 등 개선점이 없지는 않을 것이다.

그리고 스프링 3.1에 추가되는 캐쉬 추상화도 분산 캐쉬 솔루션을 편하게 활용하도록 해 준다. 트랜잭션 처리 방식과 유사하게 애노테이션으로 캐쉬할 대상과 키를 지정하는 기능이다. EhCache에 대한 구현체는 기본 제공되고 SPI(Service Provider Interface)에 맞추면 다양한 캐쉬가 이 스펙에 맞추어서 활용될 수 있다.

셋째, 모니터링 기술이다. 클라우드 환경에서는 물리적인 서버에 대해서 사용자가 신경을 쓰지 않더라도 실제로 많은 서버와 미들웨어 인스턴스를 쓰게 된다. 그리고 사용량으로 요금이 결정되므로, 리소스 사용량을 지속적으로 확인할 필요도 생길 수 있다. 사용자가 쓰는 패턴을 빨리 파악을 하는 것도 비용 대비 효과를 판단하는데 도움이 된다. 그래서 모니터링이 전통적인 시스템보다 더욱 중요하다. 스프링소스에서 모니터링 도구인 Hyperic을 인수하고 Spring-insight 같은 도구들을 만들고 있는 것이 이에 대한 대응으로 보여 진다. Spring-insight에서는 Spring MVC의 Controller 정보 등 스프링에만 특화된 정보도 제공하는데, 모니터링이 독립적인 영역이지만 스프링을 썼을 때에 이득을 더 부각시키려는 의도일 것이다.

메시징큐, 데이터 저장소와 캐쉬, 모니터링 기술들은 기존 환경에 설치해서 사용할 수도 있지만,클라우드 서비스에서 제공하는 기술 스택에 포함되기도 한다. 클라우드 서비스에서도 기본으로 제공되는 솔루션들은 중요한 경쟁력이다. 아마존 클라우드에는 메시징 큐로 SQS(Simple Queue Servcie), 저장소로 SimpleDB가 있고, Google App Engine에서는 캐쉬로 Memcache, 저장소로 빅테이블에 바탕을 둔 DataStore를 쓸 수 있다. VMWare가 제공하는 클라우드 솔루션인 VFabric에는 TcServer의 세션 클러스터링을 Gemfire로 쓰고, Hyperic으로 모니터링을 하도록 구성된다.

최근 스프링 포트폴리오의 확장 중 많은 부분은 클라우드 시대에 맞춘 기술 투자라고 볼 수 있다

스프링과 클라우드 이식성(Cloud Portability)

스프링원 2010 컨퍼런스에서는 VMWare의 클라우드에서 돌아가는 애플리케이션이 Google App Engine에서 똑같이 돌아가는 데모를 보여 줬다. JVM의 이식성을 생각한다면 어떻게 보면 당연한 결과일 수도 있는데, 이것이 어떤 의미가 있을까?

클라우드를 도입하려는 쪽에서는 미래에 일어날 수 있는 다양한 상황들을 감안해야 한다. 애플리케이션을 레거시 서버에서 클라우드로, 클라우드에서 다른 클라우드로, 클라우드에서 다시 기존 방식의 서버로의 이전하는 모든 경우가 충분히 일어날 수 있다. 그렇다면 애플리케이션이 특정 실행 환경에 종속적인 부분이 많아 지는 것은 애플리케이션의 소유자에게는 큰 짐이 된다. 그래서 특정 클라우드에 애플리케이션이 묶여 버린다는 것은 얼핏 생각하면 클라우드 사업자에게 유리한 것 같지만, 클라우드의 잠재 사용자에게는 초기의 클라우드 도입을 망설이게 해서, 사용자층이 넓어지는데 부정적인 요인이 된다. 클라우드로 이사하는데 드는 비용이 많다면 기존 애플리케이션을 올리지도 않을 것이다. 그리고 이사 한 후에도 빠져 나오기 힘들다면 사용자가 가격 정책 협상에 불리한 위치가 된다. 그래서 클라우드 사업자는 클라우드 사용자가 기존 애플리케이션을 작은 수정으로 클라우드에 올릴 수 있고, 이사 나갈 때도 쉽게 옮길 수 있다는 것은 강조하는 편이 초기에 시장을 넓히는 데에는 유리할 것이다.

그런데 클라우드 환경이 정말 기존 애플리케이션을 똑같이 받아줄 수 있을까? 우선 웹어플리케이션이 올라갈 WAS부터 그러기가 쉽지 않다. 클라우드 서비스에서는 한정된 종류의 WAS가 제공된다. Google App Engine은 Jetty를 수정해서 쓰고 있고, VMWare가 관여하는 클라우드인 CloudFoundry, VMForce, VFabric은 당연히 Tomcat의 상용판인 Tc Server를 제공하고 있다. 거기다 클라우드에 올라가는 JVM이나 WAS는 지원하는 스펙이 제약된다. Google App Engine에서는 파일을 직접 쓰지 못하고, 쓰레드나 소켓을 생성할 수 없다. 서블릿 스펙에서도 ServletContext.getNamedDispatcher 을 호출해서 디폴트 서블릿의 이름을 알아내는 메소드가 제대로 동작하지 않는다. 보안 문제나 남용의 여지가 있는 부분은 지원하지 않는 것이다. 레가시 시스템을 클라우드 환경으로 옮기는 상황이라면 기존에 레거시 시스템에서 쓰던 WAS와 클라우드 위의 WAS의 종류가 다를 가능성이 높고, 기존의 WAS가 Java EE Server라면 더욱 그렇다. 더욱이 WAS 자체 혹은 애플리케이션에서 호출하는 기능까지도 제약된다.

여기서 스프링이 클라우드 사업자들에게도 도움이 될 수 있다. 클라우드 소비자에게 지정된 WAS, 그것도 서블릿 스펙만 지원하는 WAS를 제공한다는 클라우드 서비스의 약점을 스프링이 상쇄해 줄 수 있다. 즉, JavaEE 스펙을 지원하는 서버가 없어도 Tomcat만으로도 객체의 라이프 싸이클 관리와 관계 주입, 선언적 트랜잭션 등을 쓸 수 있다. 그리고 JavaEE server를 쓰는 경우라도 서버가 제공하는 데이터 소스, 트랜잭션 서비스들을 스프링을 거쳐서 사용할 수 있다. 스프링을 통해 간접적으로 Java EE 스펙을 쓴다면, 나중에 Tomcat이나 Jetty로 WAS를 바꿀 때에도 어플리케이션의 적은 부분만 수정하면 된다. 예를 들면 JNDI로 데이터 소스를 찾아오는 부분은 DBCP로 바꾸고, JtaTransationManager를 쓰도록 선언된 Bean선언을 DataSourceTransactionManager으로 바꾸는 정도이다. 그렇게 때문에 스프링을 사용한 어플리케이션은 WAS간의 이식성이 높아지고, WAS선택의 폭이 넒어 진다. WAS의 완충 지대 역할이라 할 수 있다.

한편으로는 스프링을 활용했을 때 WAS 같은 미들웨어에 대한 종속성은 적어지지만 프레임워크 자체에 종속성이 다시 생기기 때문에, 그것 또한 이식성을 줄이는 일이 아니냐는 생각을 할 수 있다. 하지만 굳이 둘 중에 종속성을 가져야 한다면, WAS보다는 프레임워크에 종속되는 편이 더 낫다고 생각한다. 프레임워크는 하나의 WAS 위에서 여러 개가 공존할 수도 있어서 점진적으로 바꿔나가기도 쉽다. 그리고 애플리케이션이 의존하는 부분을 WAS보다는 프레임워크에 두는 것이 유연성 측면에서는 유리하다. 프레임워크의 버전 업그레이드나 특정 라이브러리 변경은 WAS에 대한 업그레이드보다 간편하기 때문이다. jar파일을 바꾸는 일만 생각한다면 프레임워크의 업그레이드는 Maven의 pom.xml에서 버전 선언 몇 줄만 바꿔 주면 된다. 반면 WAS는 설치 자동화가 되어 있다면 간편하게 모든 서버에 한꺼번에 복사할 수도 있겠지만, 아무래도 프레임워크 업그레이드 보다는 부담되는 일이다. 그리고 스프링은 스프링에 종속적이기 않게 코드를 작성하는 방법들을 많이 제공하고 있다. @Inject 같은 표준 애노테이션이 그 예이다. 이를 적절히 활용한다면 프레임워크에 대한 종속성도 다소 덜어낼 수 있다.

세일즈포스닷컴, 구글은 스프링소스를 소유한 VMWare와 함께 스프링을 통한 클라우드 이식성(Cloud Portability)을 강조하고 있다. 어떻게 보면 경쟁 관계에 있는 이들이 한 목소리를 내고 있는 것은 초기 시장 확대가 무엇보다 중요하기 때문일 것이다. 그리고 사용자들을 자신들의 플랫폼 만으로 가두는 전략보다는 원한다면 오갈 수도 있는 길을 열어 두는 것이 장기적으로는 이득이라는 믿음을 공유하고 있는 것 같다. 그렇게 해도 될 만큼 핵심 경쟁력인 인프라 기술 등에서는 자신이 있다는 해석도 할 수 있다.

기술 포털로서의 스프링

스프링과 클라우드가 연관되고 있는 또 하나의 측면은, 스프링이 자바 기술 생태계에서 일종의 ‘포털’(Portal) 역할을 하고 있어서라고 분석된다. 인터넷 포털은 많은 사용자들이 방문하고 여러 정보들을 모아서 사용자에게 일관된 UX를 제공한다. CP(Contents provider)사가 컨텐츠를 포털과 제휴하는 것은, CP사 입장에서는 자사의 컨텐츠를 알릴 수 있고, 포털 입장에서는 방문자에게 풍부한 컨텐츠를 제공해서 트래픽을 더 늘릴 수도 있다는 점에서 양측 모두에 이득이 된다. 그리고 사용자는 포털의 일관된 접근 경로와 UX로 다양한 컨텐츠를 접할 수 있다. 예를 들면 네이버의 휘발류 가격 정보는 석유공사에서 운영하는 Opinet에서 데이터를 가지고 오는 것이지만, 사용자는 네이버 검색창을 통해서 다른 컨텐츠를 볼 때와 같은 화면 스타일과 사용 방법으로 컨텐츠에 쉽게 접근할 수 있다.

포털의 UI 일관화

마찬가지로 스프링은 많은 개발자들이 사용하는 기술이고, 다양한 기술들을 조율해서 일관된 설정 방식과 명명 규칙, API 스타일을 제공한다. API는 Application Programming Interface이니 포털의 User interface가 최종 사용자가 보는 화면이라면 개발자들이 보는 interface는 프레임워크와 라이브러리의 API라 할 수 있겠다. 그리고 스프링과 제휴하는 요소 기술의 보유 업체들은 CP사와 같이 자사의 기술을 알려서 사용자를 늘릴 수 있는 기회를 얻는다. 그리고 스프링소스는 스프링과 연결되는 기술 생태계를 더 풍요롭게 만든다는 이득을 얻는다.

스프링은 다양한 기술을 같은 API로 추상화 시켜서 유연성을 주거나, 비슷한 스타일로 정리해서 개발자들에게 초기 학습 비용을 줄여 준다. 예를 들면 데이터그리드인 Gemfire에서 기존의 스프링의 DB 트랜잭션 관리 인터페이스에 맞춘 GemfireTransactionManager를 제공하는 것이 있다. 그리고 Spring-amqp 같이 최근 추가된 프로젝트도 클래스명, 인터페이스명, 메소드명은 스프링에 익숙한 사람이면 처음 보아도 친숙한 스타일을 느낄 수 있다.

VMWare가 스프링소스를 인수한 일이라던지, 세일즈포스닷컴과의 제휴나 Neo4j, Terracotta같은 저장소, 캐쉬 기술과 스프링이 연결되는 것은 기술적인 시너지를 기대한 측면도 있다. 그러나 그것도 스프링이 많은 사람들에게 익숙한 기술이고, 사람들을 모을 수 있기에 성사된 일들이다. 어느 새 VMWare가 자바 개발자들에게 이전보다 친숙한 기업이 되었으니 스프링소스 인수로 홍보 효과는 충분히 성공을 한 듯하다. 물론 그리고 단순한 홍보 수단 이상의 가치가 있으려면, 소비자들에게 시너지를 체감하게 하는 과제가 남아 있긴 하다.

비침범적인 설계와 클라우드 시대

스프링이 처음 만들어 졌을 때 클라우드 시대를 염두에 두었을 리는 없다. 급작스런 시대의 변화에 스프링도 적응을 해야 하는 상황인데, 현재까지는 클라우드 업체 사이에 활발한 제휴 대상이 되고 있다. 인기 있는 기술이라서 홍보를 위해서 제휴를 하는 측면도 있겠지만, 그래도 스프링이 주는 유연성과 이식성이 클라우드에서도 의미가 있다는 평가를 받아서 투자와 협업 대상이 되었을 것이다.

이런 현상의 가장 근본적인 이유는 인프라성 코드와 업무 로직 코드를 침범적이지 않게 한다는 스프링의 설계 철학에서 비롯된다고 생각한다. 스프링에서 강조하는 POJO(Plain Old Java Object) 방식의 개발은 특별한 규약에 의존이 없는 자바 코드가 핵심 로직을 담당해서 실행 환경에 덜 의존적인 코드를 만든다.

예를 들면 트랜잭션 처리 같은 인프라성 코드는 WAS가 제공하는 JTA(Java Transaction API) 같은 규약을 쓸 수도 있다. 그렇게 특정 미들웨어에 의존적인 코드는 최대한 한 곳으로 모으는 것이 향후 그 미들웨어가 바뀌었을 때 더 적은 수정을 유발한다. 스프링에서는 JTA에 중립적인 트랜잭션 API(PlatformTransactionManager)를 만들고, 이를 AOP를 통해서 사용해서 결국 JTA를 쓰는 코드를 한 곳에 모으고, 한 두줄 수정으로 다른 방식으로도 바꿀 수 있게 되었다. 다른 예로 Spring security가 Google App Engine의 로그인 인증에도 쓰일 수 있는 이유도 사용자 정보 저장소 인프라에 의존하는 부분이 잘 추상화되어 있기 때문일 것이다[주6].

거창하게 '클라우드 이식성 '을 위해서가 아니고, 시스템의 변화가 있을 때 적은 수정으로 대응할 수 있도록 고려를 하는 것은 설계의 기본이다. 역할과 책임이 잘 구분된 설계는 시대와 환경을 초월해서 의미가 있다. 결국 유연성, 이식성이라는 것은 잘된 모듈화의 일반적인 결과이지 꼭 특별한 기술을 적용해야 얻어지는 것은 아니다. 스프링의 AOP니 Dependency Injection이니 하는 기술들도 결국 그런 일을 돕기 위해서 존재하는 것일 뿐이다. 스프링 이전에도, 스프링 이후에도 이런 모듈화는 중요하고, 스프링이 클라우드 시대에서도 유행하고 있는 것은 이런 보편적인 설계 원리를 잘 지켰기 때문이라고 할 수 있다.

클라우드 시대에 애플리케이션 개발은 얼마나 달라질까? 사용하는 저장소나 미들웨어 같은 인프라는 많이 달라진다. 클라우드에 들어오는 새로운 구성요소들에 잘 적응을 하는 것이 처음에는 생산성을 결정하는 요인이 될 것이다. 그러나 그렇다고 애플리케이션을 개발하는 방식이 크게 달라진다고는 생각하지 않는다. 잘 모듈화되어서 역할과 책임이 잘 구분된 코드는 클라우드 시대까지 살아남을 것이고, 그런 코드는 클라우드 시대에도 수정, 추가 비용을 적게 하고, 클라우드 이후 시대까지도 남겨 질 것이다. 프레임워크의 코드이든, 응용 개발자가 짜는 애플리케이션의 코드이든 마찬가지로 말이다.

덧붙여서, 그렇게 관심과 역할이 잘 정리된 좋은 코드를 만들었다는 것을 무엇으로 증명할 것인가? 바로 테스트 코드를 짜 보는 것이다. 인프라를 관리하는 코드와 업무 규칙의 코드가 섞여있다면, 테스트 코드를 짜기가 힘들 것이고, 그런 코드는 앞으로의 변경에도 더 많은 비용이 드는 코드가 되고 살아남기 힘든 코드가 된다. 특정 프레임워크를 썼다고 좋은 설계가 당연히 바로 나오지는 않는다. 스프링을 쓰면서 테스트하기 쉬운 코드를 짜고 있는지를 돌아보는 것이 스프링을 잘 쓰고 있는지를 가장 잘 확인하는 방법이다.

정리

스프링소스가 클라우드와 관련한 활발한 활동들을 하는 것은 확장성 있는 사업 모델을 찾기 위한 돌파구였고, 포트폴리오와 강화와 각종 제휴로 현재까지는 클라우드를 지원하는 기술 쪽으로도 빠른 발전을 보이고 있다. 그리고 스프링이 제공하는 이식성 덕분에 제한된 WAS를 제공하는 클라우드에 유리한 점이 있고, 넓은 사용자층을 가진 기술 생태계의 포털 역할로 그 가치를 인정받은 것으로 분석된다. 그런데 스프링이 클라우드 시대에도 흥행하고 적응하고 있는 가장 근본적인 이유는 애플리케이션의 핵심 로직과 인프라를 담당하는 부분을 구분한 설계를 하는데 도움이 되는 기술이기 때문이다.

10년전 한 개인이 만들었던 코드조각이였을 뿐인 스프링이 이제는 업계 흐름을 좌우하는 기술이 되었다. 스프링의 예처럼, 오픈소스는 더 이상 잉여시간이 넘치는 개인들의 습작이 아니고, 기업이 전략적 협업을 하는 매개체이다.

올해에도 스프링의 소식들이 마구 쏟아질 것이고 그 중 상당 부분은 클라우드와 관련이 있을 것이다. 그들의 전략이 자바 생태계의 참여자 모두에게 혜택이 될 수 있는 방향으로 이어지기를 바란다.

주

[주1] 관련 내용이 인용된 기사 http://www.bloter.net/archives/15878 . 물론 스프링 기술 중 작은부분만 활용하고 있어도 스프링을 쓰는 것으로 집계되었을 것이라고 생각된다. [주2] 당시 논의 되었던 라이선스 정책에 대해서는 http://toby.epril.com/?p=440 에 자세히 설명되어 있다. [주3]로드존슨은 Covalent 인수 배경에 대해서 아래와 같이 밝히고 있다. http://blog.springsource.com/2008/01/29/some-decisions-are-easy-%E2%80%93-like-springsource-acquiring-covalent/ [주4] 인수 가격과 원화 환산 금액은 아래 링크를 참조했다 http://younghoe.info/1192

[주5]로드존슨의 사업 모델에 대한 고민은 아래에 발표자료에 언급되어 있다. http://gotocon.com/dl/jaoo-brisbane-2010/slides/RodJohnson_bKeynotebThingsIWishIdKnown.pdf [주6] http://blog.springsource.com/2010/08/02/spring-security-in-google-app-engine/ 참조

SpringOne2GX 2010 (4) Spring Roo 관련 발표들

Thu, 11 Nov 2010 00:00:00 +0000

작년 SpringOne에서도 Spring Roo에 대한 발표가 있었고, Google IO 등 다른 컨퍼런스에서도 꾸준히 Spring Roo는 홍보되었지만, 이번 SpringOne에서는 부쩍 그 비중이 높게 느껴졌습니다.

키노트가 있었던 주행사장에는 Spring Roo, Spring, SpringSource, Groovy, Grails의 5개의 로고가 조명으로 비추어져 있었습니다. Groovy-Grais의 관계처럼 Spring-SpringRoo의 관계를 연상시켜서, Spring의 대표 기술로 홍보하려는 전략으로 보였습니다.

그리고 행사 기념품으로 나온 배찌에서도, Spring,SpringSource, Goorvy, Grails, Tomcat 등과 함께 Spring Roo의 로고가 박힌 것이 포함되었습니다. Security나 Batch같이 이미 현장에서 더 많이 쓰이고 있는 하위 프로젝트들도 있는데, Roo만 특별대우 한다는 느낌까지 들 정도였습니다. 다른 프레임웍 기술만과는 차별된 Spring만의 강점을 강조하기 위해서 Spring Roo가 전면에 나왔다고 생각됩니다. 스프링에서 지원하는 기술이 많아질 수록, API들을 전파하는 것도 쉽지 않을 것인데, Spring Roo를 통해서 사용할 수 있는 방법을 제공하면 코드가 자동생성 되므로 사용법이 더 간편해 보인다는 장점이 있을 것입니다. 그리고 Roo가 그렇게 새로운 API 전파 창구의 역할을 수행한다면 Roo를 직접 사용하지 않는 사람도 Roo가 생성해주는 코드를 샘플로 활용할 수도 있을 것입니다. Spring 3.0.4에 포함된 <mvc:default-servlet-handler/>가 Roo에 바로 반영된 것이나, Neo4j의 Roo addon등이 그 예입니다.

컨퍼런스가 끝나고 몇일 뒤에 바로 Spring Roo 1.1.0 버전이 발표되었는데, 이번 컨퍼런스에서 1.1.0에 포함된 기능을 소개하는 발표가 많았습니다.

http://blog.springsource.com/2010/10/27/spring-roo-1-1-0-is-released/

OSGi, GWT, GAE-J 지원, 검색서버인 Apache Solr 지원, Database reverse engineering 등 많은 발전을 보여줍니다. 아래 포스트에 있는 지난 1년간의 Roo의 commit 내력을 시각화한 그림에서도 그런 변화가 표현되었습니다.

http://stsmedia.net/spring-roo-1-1-ga-released/

벤알렉스 아저씨가 열심히 개발을 하는 모습이 보이는군요. 이번 컨퍼런스에 벤알렉스는 참석하지 않았고, 벤알렉스가 진행하기로 한 발표의 일부는 로드존슨이 직접 진행했습니다. 아파서 못 왔다고는 말했는데, 1.1 출시를 얼마 안 앞두고 마무리 작업 때문에 못 온 것이 아닌가 하는 생각도 들었습니다.

저는 Roo 관련 세션 중에 Add-On 개발 관련 세션에 들어갔었습니다. 아래 URL에 있는 toString addon을 샘플소스로 보라고 했는데, toString을 Addon도 크게 쉬워보이지는 않았습니다.

http://git.springsource.org/roo/roo/trees/master/addon-tostring/src/main/java/org/springframework/roo/addon/tostring

가장 흥미로운 이야기는 Roo에서 앞으로 iBatis, Spring jdbc 같은 JPA 이외의 Persistence 기술도 지원하겠다는 것이였습니다.

그리고 Maven 멀티 프로젝트를 언제 지원할 수 있으냐는 질문이 세션 중에 나왔는데, 명확한 일정을 확답을 하지 못한 것으로 봐서는 가까운 시일 내에 가능해지지는 않을 것 같습니다.

Roo 관련 발표 자료들은 아래에 공개되어 있습니다.

Java에서 XML없이 SQL개발하기

Mon, 8 Nov 2010 00:00:00 +0000

변경 이력

2015/01/21 : Eclipse에서 Groovy를 쓰기위한 plugin과 Maven 선언 부분을 현행화
2013/01/25 : http://www.dpriver.com/pp/sqlformat.htm 의 캡쳐화면 추가 등
2012/11/06 : Eclipse에서 Groovy를 쓰기위한 plugin과 Maven 선언 부분을 더 편한 방식으로 수정

요약하면, Java의 여러 프레임웍은 XML안에 SQL을 넣는 방식을 지원하는데, 줄바꿈이 있는 문자열을 편하게 쓰게 해주는 따옴표 세 개문법 (""")만 Java에 추가된다면 XML을 사용하는 목적을 충족시키면서도 XML로 인한 여러 단점들을 겪지 않아도 된다는 것입니다. 따옴표 세개는 Java에서 추가될 예정이지만, Groovy등에서는 이미 지원합니다. 지금이라도 SQL관리에만 Groovy를 쓰면 쿼리편집이 조금 더 편리해질만도 합니다.

XML로 SQL을 관리할 수 있는 Java framework

많은 Java 프레임웍들이 SQL구문들을 XML파일 안에서 코딩하게 되어 있습니다. 가장 대표적인 것이 iBatis입니다. 아래와 같이 SQL 구문, 파라미터를 운반하는 클래스, 쿼리의 결과가 담길 클래스를 XML안에 선언합니다.

    <select id="findByIsbn13" parameterClass="string" resultClass="book">
    SELECT  title,    author,     isbn13,     isbn10,     pages, content, imageUrl
    FROM book
    WHERE isbn13 = #isbn13#
    </select>
    <select id="findByTitle" parameterClass="string" resultClass="book">
    SELECT  title,    author,     isbn13,     isbn10,     pages, content, imageUrl
    FROM book
    WHERE title = #title#
    </select>

그리고 Hibernate와 JPA에서도 "named query"라는 개념으로, SQL을 따로 XML파일로도 뺄 수 있습니다. 아래는 Hibernate에서 SQL을 XML 파일안에 설정한 예입니다.

<sql-query name="findBookByIsbn13">
    <return alias="book" class="tdd.edu.domain.Book"/>
   SELECT  title,    author,     isbn13,     isbn10,     pages, content,  imageUrl
   FROM book
    WHERE isbn13 = :isbn13
 </sql-query>

Navie SQL과 Hibernate가 쓰는 HQL을 모두 .xml파일 안에 선언하는 것이 가능합니다. JPA를 사용해도 마찬가지로 JPA-QL, Native SQL을 Java에서 String으로 선언할 수도 있지만, XML 파일 안에 넣어도 됩니다.

Spring JDBC에서는 Jdbctemplate.execute 등의 메소드에서 SQL내용을 직접 문자열로 넘기게 되어있지만, Applicaton context 안에 쿼리를 저장해두고, 이를 사용하는 쪽에서 java.util.Properties 같은 객체를 Dependency Injection 받아서 사용하면 iBatis처럼 XML로 쿼리가 관리됩니다.

<util:properties id="bookSqls">
    <prop key="findByIsbn13">
   SELECT  title,    author,     isbn13,     isbn10,     pages, content,  imageUrl
   FROM book
    WHERE isbn13 = :isbn13
    </prop>
</util:properties>

그런데, Spring-jdbc나 Hibernate, JPA에서는 XML에 SQL을 저장하는 방식이 선택일 뿐이지만, iBatis 2.x에서는 반드시 XML안에 쿼리를 넣어야합니다. myBatis라고 이제 이름이 갈라진 iBatis 3.x에서는 Annotation으로 쿼리를 지정할 수 있어서, .java파일 안에 문자열로 SQL에 넣어도 되기는 합니다.

final String PERSIST_INFO =
“INSERT INTO simple_information(info_id, info_content) VALUES (#\{infoId}, #\{infoContent})”;

@Insert(PERSIST_INFO)
public int persistInformation(SimpleInformationEntity simpleInfo) throws Exception;

(예제는 http://java.dzone.com/articles/mybatis-formerly-called-ibatishttp://java.dzone.com/articles/mybatis-formerly-called-ibatis 에서)

그런데, 이런식으로 쿼리까지 Annotation으로 지정하는 것에 대해서는 의견이 분분할 것 같고, 개인적인 생각으로는 Spring jdbc나 Hibernate처럼 필요하면 직접 메소드 시그니처에 직접 SQL을 문자열로 넘기는 방식이 훨씬 더 자연스럽다고 보여집니다.

문제점은?

iBatis에서는 파라미터에 따라서 SQL이 다르게 구성되는 다이나믹 쿼리를 아래와 같이 선언합니다.

<isEqual property="writerSelected" compareValue="false">
  <isNotNull property="writerList">
    <iterate prepend=" AND writer in" property="writerList"
       open="(" close=")" conjunction=",">#writerList[]#
    </iterate>
  </isNotNull>
</isEqual>

if, for문 처럼 조건,반복문들이 XML로 표현되어 있습니다. 이는 절차적 프로그래밍을 SQL로 하게 되어서 아래와 같은 단점이 있습니다.

조건, 반복문에 해당하는 태그 문법을 별도로 배워야함
괄호"\{}"대신 열고 닫는 태그가 단락을 구분하기 때문에, 같은 조건,반복문을 코딩해도 Java 같은 범용언어에서보다 긴 코드가 나오게됨
Compile time의 validation범위가 더 줄어들게 됨. getter, setter로 참조하게 될 속성명에 오타가 있어도 직접 실행해봐야지 오타를 알 수 있음.
Java파일 밖이므로, Emma와 같은 Coverage 확인 툴로 실제 해당 절이 실행되었는지 확인할 수도 없음.

왜 SQL이 XML에 들어가게 되었을까?

직접 JDBC를 쓰면 Connection 관리와 Exception처리 등이 불편합니다. 그리고 JDBC의 Prepared Statement에서는 파라미터를 "?"를 표시하기 때문에 거기에 넘어가는 변수를 위치의 순서로 파악을 해야 합니다. ":id"와 같이 named parameter를 넣을 수 있다면 훨씬 쿼리의 가독성이 높아집니다. 그래서 그러한 Jdbc의 미흡한 점들을 보완해주는 프레임웍들이 각광을 받았습니다.

그런데, Connection이나 Excpetion처리의 편의성, named parameter의 활용하고 싶다고 해서 반드시 XML로 SQL를 관리해야 하는 것은 아닙니다. XML을 안 써도 되는 Spring의 JdbcTemplate에서도 그런 기능은 다 제공을 합니다.

SQL이 한 파일에 모여있지 않으면 DBA한테 쿼리 검수를 맡기거나, 여러 SQL을 한번에 수정할 일이 있을 때 불편해 지기도 합니다. 그러나 그런 점도 SQL 내용을 상수로 선언하는 .Java 파일을 따로 분리하면 해결할 수 있습니다. SQL을 보관하는 .java파일에 *SqlMap.java와 같은 명명규칙을 부여하고, SQL 검수를 맡길 때 그 파일만 넘기면 됩니다.

또, 과거에는 .java파일 밖에 SQL이 있으면 SQL만을 수정을 했을 때는 다시 컴파일을 안 해도 된다는 장점이 강조되었습니다. 그러나, 요즘은 개발 PC에서는 Eclipse로, 서버에 배포할 때는 Ant나 Maven으로 빌드과정이 간편해졌고, 설정파일을 수정해도 파일의 복사를 위해 그런 배포과정을 똑같이 거쳐야 하므로, 컴파일이 필요없다는 것도 더이상 장점이 되지 못합니다.

XML에 SQL을 썼던 가장 핵심적인 이유는 .java파일에서는 줄 바꿈이 들어간 문자열을 편집을 하는 것이 불편했기 때문입니다. Java 파일에서는 문자열이 한 줄이 넘어가면 아래와 같이 + 기호를 이용해서 이를 연결해주는 방법 밖에 없습니다.

public static final String SELECT_BY_ISBN13 =
    "SELECT name , id "
    + "FROM user "
    + "WHERE isbn13 = :isbn13 ";

보통 Toad와 같은 DB client 도구에서 SQL을 작성해서 프로그램에 붙여넣기도 하고, 디버깅 중에는 프로그램 내에 있는 SQL을 반대로 DB client 툴에 붙여넣어서 실행해보기도 하는데, 그 때마다 저렇게 줄바꿈마다 "+"가 있다면 쿼리 편집이 많이 번거로워집니다. 그래서 XML파일 안에 SQL이 있으면 줄바꿈이 있는 긴 문자열도 똑같이 붙여넣을 수 있기 때문에, SQL을 개발하는 작업이 훨씬 편해집니다. 이렇게 SQL이 XML안에 들어가다보니 동적쿼리를 만들기 위한 조건,반복문과 각종 파라미터 매핑 클래스등까지 다 XML에 포함되어 버렸고, 앞에서 말한 부작용들이 점점 드러나기시작했습니다.

물론 Eclipse의 설정으로 .java 파일에 붙여넣기를 할 때는 "+"를 넣는 것과 같이 줄을 바꿀 때 필요한 작업들을 자동으로 할 수도 있습니다.

Windows-Preference-Java-Editor-Typing란의 "Escape text When pasting into a string literal"을 선택하고, 큰 따옴표 하나를 연 채 여러줄을 붙여넣으면, 알아서 줄이 바뀔 때는 " + " 기호를 넣어줍니다.

그리고 반대로 이런 여러줄의 String을 DB 접속 툴에 붙여 넣을 때도 Sql-Squirrel이나 Toad 같은 툴에서는 그런 "+"와 같은 기호를 제거해 주는 기능이 있기도 합니다. 그리고 웹으로 이런 변환을 해주는 사이트도 있습니다. http://www.dpriver.com/pp/sqlformat.htm는 여러줄로 된 SQL문장을 Java, C#, Delphi, PHP등 다양한 언어의 문자열 선언으로 변환해줍니다.

이렇게 편집을 도와주는 설정이나 도구들을 쓰더라도 중간 변환과정에서 몇번의 키 입력과 클릭이 필요해서 아예 그런 과정이 없는 것보다는 번거롭게 느껴집니다. 그래서 문자열 전체를 중간 변환과정없이 편집할 수 있는 XML에 SQL을 선언하기 시작했다고 생각합니다.

대안으로 Groovy로 따옴표 3개 문법을 이용해서 SQL 관리하기

Python, Groovy, Scala, Ruby에서 이미 지원하고 있는 '따옴표 3개짜리 문자열 선언’이 Java에도 포함된다면 여러줄의 문자열을 따로 편집하는 불편함을 겪지 않아도 됩니다. 아래와 같이 중간에 줄바꿈이 있어도 전체 SQL 내용이 끊어지지 않고 들어갑니다.

 public static final String SELECT_BY_ISBN13 =    """

  SELECT  title,    author,     isbn13,     isbn10,     pages, content,  imageUrl
   FROM book
   WHERE isbn13 = :isbn13

""";

이 따옴표 3개는 이미 JDK7에 포함되는 것이 제안된 상태인데, JDK에 포함될 실험적인 내용을 구현해보는 "Kijaro"라는 프로젝트에서는 Enhanced String Handling for Java라는 이름으로 이 명세를 다루고 있습니다. 그러나, 내년 중반기 쯤에 JDK7에 포함되어 발표될 예정인, java의 문법 개선내용을 주로 담고 있는 project coin에서는 아직 이를 찾아볼 수 없어서, 언제 Java에 반영될지는 아직 미지수입니다.

그렇다면 Java에서 따옴표 3개를 지원해주기 전까지는 계속 XML의 불편함을 감수해야 할까요? 저는 이미 이 문법을 지원하는 Groovy를 SQL관리 용도로 사용해볼만 하다고 생각합니다.

Groovy를 사용하기 위해서는 Eclipse와 Maven에 아래 설정만 해주면 됩니다.

1.Eclipse에서 Groovy plugin 설치

Update site:

4.2 (Juno) : http://dist.springsource.org/release/GRECLIPSE/e4.2/
3.7 (Indigo) : http://dist.springsource.org/release/GRECLIPSE/e3.7/
3.6 (Helios) : http://dist.springsource.org/release/GRECLIPSE/e3.6/

Groovy-Eclipse Configurator for M2Eclipse도 설치가 필요한데, 2번 과정에서 pom.xml에 빨간 줄이 뜨면 Ctrl +1 을 눌러서도 설치할수 있습니다.

2.pom.xml에 Groovy를 compile할 수 있는 plugin과 runtime dependency 추가

Groovy를 Compile하는 Maven plugin은 Gmaven 과 Groovy-Eclipse Compiler Plugin For Maven이 있습니다. 후자가 Eclipse 최신버전의 me2와 더 나은 궁합을 보여줘서 컴파일을 할 때는 후자를 선택했습니다.

(1)Dependencies에 선언 추가

<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>2.4.5</version>
</dependency>

(2)build-plugins 에 아래 내용 추가

               <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <compilerId>groovy-eclipse-compiler</compilerId>
                    <meminitial>128m</meminitial>
                    <maxmem>512m</maxmem>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>utf-8</encoding>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-compiler</artifactId>
                        <version>2.7.0-01</version>
                    </dependency>
                </dependencies>
            </plugin>

<plugin>

3.Groovy 사용

그리고 New→ groovy class를 선택하여서 java 파일 작성하듯이 클래스를 만듭니다.

Java 문법을 그대로 쓸 수 있으니 따옴표 3개를 쓸 수 있다는 점만 다르다고 생각해도 됩니다. 아래와 같이 .groovy 파일 안에 들어간 SQL이 색깔도 다르게 표시되어 비교적 가독성이 높게 표시되는 것을 확인할 수 있습니다.

그런 다음 DAO 등 SQL을 호출하는 쪽에서는 이 상수 문자열을 바로 참조합니다. 상수 선언이 되어 있으니 아래와 같이 오타를 쳐도 미리 알려주고, Ctrl + Space를 치면 자동완성도 됩니다.

Dynamic SQL의 경우에도 직접 Java안에서 if문으로 써서 적어주면 됩니다. 아래와 같이 EclEmma 같은 도구로 coverage를 측정하면, 실제 실행되지 않은 조건분기도 눈으로 보입니다.

위의 코드를 Spring-JDBC를 사용했는데, 필요하다면 Hibernate나 apache commons DBUtils에서도 적용 가능한 방법입니다. 다만 Hibernate에서는 Criteria 같은 것을 이용하면 문자열로 길게 쓰는 쿼리가 많이 나오지는 않을 것으로 예상합니다. 그리고 myBatis(iBatis 3.0)의 Annotation으로 지정하는 쿼리 문자열에서도 똑같이 참조할 수 있습니다. static final String으로 선언된 문자열 상수만 쓰는 것이기 때문에 Groovy의 성능문제도 걱정할 필요가 없습니다.

단점과 꺼림직함도 물론 있습니다. 별도의 Eclipse plugin을 설치해야 하기 때문에, 이미 많은 수의 Plugin을 설치해서 Eclipse가 무겁다고 느껴지는 개발환경에서는 다소 부담이 될지 모른다는 점입니다. Groovy가 거의 java와 같은 문법을 지원하기는하지만, 이 문법 하나 때문에 새로운 언어를 도입하는 것이 과하다고 느끼시는 분들도 계실 것입니다. 이 문법을 위해서 Groovy의 다른 부분은 쓰지 않는데도 Runtime에 Groovy의 라이브러리를 올리는 것이 부담스러울 수도 있습니다. (따옴표 3개와 같은 Groovy만의 문법을 바이트코드로 변환하는 작업은 Compile time에 이루어지지만, Groovy로 선언한 객체는 groovy.lang.GroovyObject를 상속해야 하기 때문에, 다른 기능을 쓰지 않더라도 Runtime에서 추가 라이브러리가 필요합니다.) 그런 분들은 언제가 될지는 몰라도 Java에서 따옴표 3개를 지원하는 때까지 기다리는 것이 좋으실듯합니다.

SQL을 XML에 쓰는 것이 전혀 불편하지 않다고 느끼신다면 계속 하던대로 개발을 하면 되겠지만, 저는 위의 시도가 조금이라도 더 편한 개발환경을 만든다고 생각합니다.

SpringOne2GX 2010 (3) Spring and Java EE 6,Synergy or Competition?

Fri, 29 Oct 2010 00:00:00 +0000

논쟁에 응하다

2010년 10월 4일, http://www.theserverside.com 에는 이제 프레임웍의 시대는 가고, Spring에서 Java EE6로 옮겨야 한다는 주장을 담은 글이 올라왔고, 뜨거운 논쟁거리가 되었습니다.

Moving from Spring to Java EE 6: The Age of Frameworks is Over

과거 Java EE 스펙의 부족함 때문에 Spring이 떠올랐지만, 이제 Java EE 6에서는 그런 것들을 다 극복을 했으니 Java EE6로 갈아타자는 내용이였습니다.

이 글의 댓글에서부터 많은 반론이 올라왔고, 별도의 포스트로 쓰여진 아래와 같은 글들도 있었습니다.

http://raibledesigns.com/rd/entry/re_moving_from_spring_to

Spring vs. Java EE and Why I Don’t Care

반론들에 포함된 공통적인 내용들은 아래와 같습니다.

크게 볼 때, Spring과 Java EE6 는 비슷한 프로그래밍 모델을 가진 부분이 많다.Annotation을 @Stateless을 쓸지, @Component 쓸지는 프로젝트의 성공여부를 결정지을 만큼 중요한 차이는 아니다.
그러나 Spring이 Tomcat, Jetty를 비롯한 더 많은 WAS에서 실행될 수 있다.
Batch, Integration, Spring Roo 같은 Java EE 스펙이 미치지 못하는 영역을 스프링에서는 제공하고 있다.

JavaEE 진영과 스프링 쪽의 갈등은 이미 뿌리가 깊습니다. 스프링의 시초가 된 코드가 있는 "Expert One-on-OneJ2EE Design and Development"책에는 EJB의 단점들이 날카롭게 지적되어 있고, 로드존슨과 유겐할러가 써서최초로 스프링을 언급한 책은 이름부터가 "Expert One-on-One J2EE Development withoutEJB"였습니다. "with Spring"도 아닌 "without EJB"인 것이죠. EJB를 적용했을 때의 실패경험 때문인지로드존슨은 EJB에 맺힌 것이 많아 보이고, 그런 것들이 앞의 저서들을 저술한 동기를 더 강하게 하지 않았을까하는 생각도듭니다. 그래도 J2EE 시절만 해도 표준 스펙은 OS나 DB서버와 같이, low level의 기술을 제공하는 컨테이너로인식이 되었는데, Java EE5 이후 실사용자 레벨의 컴퍼넌트 모델을 제공하기 시작하면서 JavaEE와 Spring은경쟁관계로 인식이 됩니다. 사실 스펙을 정의하는 JavaEE와 구현기술인 Spring을 동등하게 비교할 수도 없고,Spring에서도 JavaEE스펙을 지원하는 부분이 있습니다. 하지만 JavaEE스펙을 더 지지하는 진영에서는 Spring을사유기술일 뿐이고 JavaEE에 근거한 기술은 표준이라는 것을 계속 강조하면서 스프링을 공격하고 있습니다. 로드존슨은 이전에올린 블로그 포스트의 댓글에서 오픈소스 기술인 Spring을 사유(proprietary)라고 표현한 것에 대해서는 그것은 의심스러운 용어일 뿐이라고 말한적도 있습니다. (In any case, "proprietary" is a questionable term when we’retalking about open source. )

마침 SpringOne2GX 컨퍼런스 직전에 또다시 이런 논쟁이 일어난 것이 흥미로웠고, 저는 로드존슨이 키노트에서 바로 이에 대한 반론을 하지 않을까 하는 기대도 했었습니다. 그런데 로드 존슨은 핵심가치 같은 큰 그림에서의 스프링이 추구하는 바를 이야기했고, 이 논쟁에 대한 직접적인이야기는 하지 않았습니다.

바로 셋째날에 한 이 발표 "Spring and Java EE 6,Synergyor Competition?"에서 유겐할러가 그에 대한 구체적인 대답을 했습니다. 유겐할러는 최근 이런 논쟁들을 보고서 발표제목을 바꾸었다고 했고 이미 발표 몇시간 전 팀블로그에 아래와 같은 글을 올려서 이날 발표에서 말할 내용을 먼저 공개하기도했습니다. 저는 컨퍼런스가 끝난 후에야 이 글이 올라온 것을 보았는데, 발표에서 가장 뒷부분에 강조한 핵심내용이 정리되어있었습니다.

http://blog.springsource.com/2010/10/19/spring-3-on-a-java-ee-6-server/

뒤에서 언급되겠지만, 간단히 정리하면 JavaEE6 환경에서도 스프링을 사용하면 플랫폼에서 제공되는 기술들을 일관된 프로그래밍과 설정 모델로 조화시키고, 더 많은 기술과 환경을 조합할 수 있으면서, Java EE7보다 더 빨리 발전하는 기능들을사용할 수 있는 것이라는 주장이였습니다.

사실 유겐할러는 이 날 발표와 비슷한 주제의 발표를 Java EE6 스펙의 확정 전에도 여러 번 한적이 있었습니다. 작년에 한 발표도 아래 링크에서 동영상으로 올라와 있습니다.

http://www.infoq.com/presentations/Spring-and-Java-EE-6-Jurgen-Holler

확정된 스펙을 가지고 이야기 한 것이 작년에 한 위의 발표와 달랐던 점이였습니다. 발표 중에 유겐할러는 Spring 쪽에서도오랫동안 EE 6 스펙의 확정을 기다렸다고 했고 EE6 확정 직후에 발표된 Spring 3.0에서도 EE6의 스펙을 많이지원하고 있음을 강조했습니다. 발표 제목 중에 포함된 "Synergy or Competition"중, "Synergy"를주장하고 싶었던 것이죠.

스프링의 역할

이 것은 이번 컨퍼런스 내내 키노트와 여러 세션에서 반복되어 언급된 말이였는데, 이 발표에서도 스프링을 사용하면 Java EE와 동등한 기능을쓰면서도 어플리케이션을 어느 서버에서도 배포될 수 있다는 것을 강조했습니다. 대상 플랫폼의 런타임에 적용되어서, 서비스추상화를 통해 공통적인 Programming model과 설정으로 개발을 할 수 있고, 전통적인 어플리케이션 서버 역할의 대안을 제공한다고 했습니다. Java EE 5의 스펙 중에서도 @PostConstruct, @PreDestoy ,@PersistenceContext, @PersistenceUnit , @Resource, @EJB, @TransationAttribute 등의 많은 Annotation을 지원하는데, 원하는 Semantics에 따라서 조합하고조화시켜(Mix & Match) 사용하라고 권장했습니다.

Java EE6 스펙 리뷰와 스프링의 지원

Java EE 프로파일

JavaEE프로파일은 EE 스펙 중 일부를 일부를 묶어서 구분하는 개념이였습니다. 가령 "Web Profile"이라고 하면 EE 스펙 중웹기술에 해당하는 Servlet, JSP, jSTL, JTA, JPA, EJB 3.1 Lite를 포함하는 것이라고 했습니다.그래서 벤더들이 초점을 두고 싶은 프로파일만 구현하고, 이미 지나간 잘 안 쓰이는 스펙에 대해서는 구현할 필요가 없이 그 분야의 프로파일에 대해서만 인증을 받을 수도 있다는 것입니다. 좋은 개념이기는 하나 현실적으로 웹프로파일만 구현하고 있는 벤더는아직까지는 없다고 말했습니다. 그런데 컨퍼런스가 끝난 뒤에 SIwpas라는 Web Profile만 구현한 서버를 우연찮게 발견하기도 했습니다.

그리고 스프링은 플랫폼에서 어떤 라이브러리가 제공되던지 상관 없이 사용할 수 있으므로 Java EE 프로파일은 스프링에 영향을 미치지는 않는 개념입니다.

Servlet 3.0

Servlet3.0 스펙에는 web.xml을 간결하게 해주는 "framework auto deployment"기능이 포함되고, 스프링도자동배포 기능 추가를 계획하고 있었습니다. 그리고 비동기적인 Http처리인 Comet은 Spring MVC에서 특별한request/reponse 형식으로 지원할 것이라고 했습니다. 당연히 이전 서블릿 스펙을 지원하는 서버에서의 하위호환성도유지할 것이라고 합니다.

JSF 2.0

JSF 2.0에는 UI 컴퍼넌트 부분에서 Ajax 지원와 페이지 선언 언어 등이 개선됩니다.. 그리고 스프링의 @Component와 @Value와 유사한 역할인@ManagedBean, @ManagedProperty 애노테이션이 있습니다. 스프링에서는 현재의 JSF지원 기능을 새 버전에맞추어 이어나가면서 3.1버전에서는 JSF 지원을 더 확장할 수 있도록 연구 중에 있다고 했습니다.

JPA 2.0

JPA2.0에는 쿼리 타임아웃, 표준화된 쿼리 힌트 등이 추가되었습니다. 역시 스프링에서는 현재의 JPA의 지원기능을 이어나가고,트랜잭션 관리에서 JPA 2.0의 모든 기능을 다 열어준다고 했습니다. 이미 Spring 3.0에서 Hibernate,EclipseLink, OpenJPA 등의 최신버전들과 이런 기능들을 쓸 수 있다고 합니다.

JSR-303 Bean Validation

JSF 2.0과 JPA 2.0에서 동시에 지원하는 스펙인데, Spring 3.0에는 SpringMVC의 Validation기능으로 사용할 수 있습니다.

JAX-RS

JAX-RS((Java™API for RESTful Web Services)는 REST방식의 웹요청 처리를 지원하는 표준 API입니다. 이미Jersey같이 JAX-RS를 지원하는 프레임웍에서 Spring을 자연스럽게 같이 연결해서 사용할 수 있습니다.

아래 코드에 @Path 아노테이션은 JAX-RS에서 정의된 것인데, 여기에 스프링의 @Autowired 를 같이 쓰고 있습니다.

@Path("widgets")
public class WidgetsResource {
    @Autowired
    private WidgetsService service;

    @GET  @Path("{id}")  @Produces("text/html")
    public String getWidget(@PathParam("id") int id){
     ...
    }

}

스프링 3.0에서도 Spring web MVC에서 나름대로의 스펙을 가진 REST지원 기능이 있습니다. 사실 위의 @Path와@PathParam 은 스프링의 @RequestMapping, @RequsetParams 아노테이션과 무척 유사해보이는, 비슷한프로그래밍 모델을 가지고 있습니다. 왜 스프링개발자들이 Spring MVC에서 JAX-RS를 바로 지원 안하고 나름대로의 스펙을만들었는지에 대해서는, 스프링소스의 팀 블로그를 통해서 밝힌 적이 있습니다.

http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/ 참조

기존의 JAX-RS 스펙을 바로 지원하는 것도 프로토타이핑해봤지만, 자연스럽게 않게 억지로 끼워 맞추는 듯한 방식이 나왔고, 결국Spring MVC사용자들에게 더 일관적이고 편한 방식을 제공하는 나름대로의 기능을 넣기로 결정했다는 것이였습니다. 결국JAX-RS와 Spring MVC는 REST 지원부분에서 겹쳐지는 부분이 생겼고, 이를 두고 스프링은 표준 스펙을 존중하지않는다는 비난을 하는 사람도 있었습니다.

이날 발표에서도 유겐할러는 Spring MVC는 근본적으로 MVC구조라서 View의 rendering을 하는 부분을 분리할 수 밖에 없고, 따라서JAX-RS 방식과 달라질 수 밖에 없다고 했습니다. 그리고 Jersey, RESTEasy, Restlet와같은 JAX-RS 구현체를 쓴다고 해도 Spring를 같이 쓸 수 있으니, 상황에 따라서 Spring MVC의 REST 기능이나JAX-RS 구현체를 모두 골라서 쓸 수 있다고 했습니다. UI페이지와 REST요청을 같이 처리해야하는 어플리케이션에서는Spring MVC로, 계층적인 리소스 구조처럼 REST 방식을 깊이까지 쓰는 어플리케이션이라면 JAX-RS 구현체를 쓰는것처럼 말이죠. 스프링은 언제나 그래왔듯이 선택에 대한 것이라는 말을 덧붙였습니다. (Spring is (and alwayswas) about choice),

그리고 JAX-RS 스펙은 Java EE6에서 독립적인 스펙이고, 다른웹스펙과도 연관관계가 없고, JSF와 프로그래밍 모델도 다르다고 유겐할러는 설명했습니다. 스프링은 그런 관련성이 있는 스펙들을 일관성 있게 묶어가고 있다는 것을 대비시켜 보이기 위해서 굳이 그런 언급을 한 것이 아닐까하는 생각도 들었습니다.

EJB 3.1

EJB3.1는 EJB 3.0에 singleton bean과 비동기 메소드 호출, JNDI 이름에 대한 Convention 제공 등의기능이 추가된 것입니다. 그리고 Local session Bean과 Singleton Bean만을 가지는 "EJB 3.1Lite"라는 것도 정의했습니다. 대부분의 서비스 객체가 원격호출이나 Object pooling이 없이 쓰이는 스프링의 방식과유사한 것인데, 과거의 그런 기능들이 대부분의 상황에서 오버엔지니어링 이였음을 다시 한번 인정하는 스펙 추가가 아닌가 하는생각이 들었습니다.

흥미로운 스펙은 컨테이너가 Lock 관리를 해준다는 것인데,(container-managed locking) 아래 코드에서 @Lock 아노테이션이 그런 역할을 하고 있습니다.

@Singleton @Startup
@DependsOn({"OhterBean1","OtherBean2"})
public class SharedService {
    private Data sharedData;
    @Lock(READ)
    public String returnSharedDataValue(){
        return this.sharedData;
  }
}

그리고 @Singleton이 붙은 클래스의 모든 메소드는 기본적으로 쓰기 잠금이 걸린다고 합니다.

유겐할러는 이런 스펙이 불필요할 상황이 많을 것이라고 했는데, ConcurrentHashMap 같이 thread-safe를 감안한자료구조를 선택할 수도 있고, synchronized나 volatile와 같은 키워드를 이용해서도 개발자가 그런 것들을 제어할수도 있다고 했습니다. 아뭏든 이런 Lock에 대한 디폴트 값을 제외하고는 @Singleton으로 설정되는 Bean은Spring이 관리하는 Bean과 상당히 유사해졌다고 말했습니다.

EJB가 컨테이너와 스프링과의 관계는 EJB3.1에서도 변하지 않는다고 했습니다. EJB 스펙은 나름대로의 Container에 의해서 지원되는 것이고, 필요하다면Spring에서 이를 접근할 수도 있는 것이죠. 그리고 EJB 3.1의 비동기 호출 스펙인 @Asynchronous은@Aysnc 로 Spring에  반영되어, 영향을 주었다고 했습니다.

JSR-299 Web Beans - CDI(Contexts and Dependency Injection)

"Webbeans"라는 이름으로 불렸던, 공식적으로는 "Contexts and Dependency injection"이라는 명칭으로붙여진 이 스펙과 스프링을 눌러싼 논쟁들은 표준 제정 과정 당시에도 가장 뜨거운 화제였었고, 이 날 발표에서도 개인적으로 가장관심이 가는 부분이였습니다. 이 스펙은 원래 JSF에서 Bean관리를 개선해서 JSF와 EJB를 잘 연결하는 역할을 위해만들어졌지만, 점점 확정된 스펙으로 발전해 나갔습니다.

CDI에서는 Type-safe DepedencyInjection, Interceptor, 이벤트 통지, Web conversation context 등의 풍부한Dependency Injection모델을 Annotation을 통해서 제공합니다. javax.decorator,javax.context, javax.inject, javax.event 등에 다양한 패키지에 나눠서 들어가 있고, 이미@Resource 등의 아노테이션이 있는 JSR-250이 담당하는 패키지인 javax.annotation,javax.interceptor 에도 추가되어 있습니다.

발표 슬라이드에는 나와있지 않지만,여기서 유겐할러는 CDI의 부정적인 면들도 언급을 합니다. EJB 3.1이 이 Component 모델을 뒤에서 떠받치는 역할을하지만, EJB와 CDI는 각각의 나름대로의 역할과 생명주기를 가지고 있는 그렇게 다른 Semantics가 섞이면 혼란을 불러일으킬 수 있다고 합니다. 그런 혼란에서 오는 어려움은 그 날 발표 슬라이드나 어떤 슬라이드 내에서는 표현될 수 없고, 실제로개발을 해보고 디버깅을 해서 겪어봐야지 알 수 있다고 했습니다.

그리고 이 스펙은 스프링의 프로그래밍 모델과겹쳐지는 부분이 있고, Spring 3.1에서는 스프링의 원래 프로그래밍 모델을 더 발전시켜서 JSR-299과 표현력과 기능을능가하겠다고 했습니다. 이미 Spring에서도 다양한 scope의 빈을 정의할 수도 있고, Stateful한 웹어플리케이션을개발할 수 있다는 Spring Web Flow가 따로 프로젝트로 나와있지만, Spring 3.1에서 추가될Conversation Management는 그런 것들을 더욱 일반화 시켜서 Spring Core 쪽으로 끌어올리겠다는 의미로해석됩니다.

Spring on Java EE6

앞에서 언급했듯이, 유겐할러는 발표의 뒷부분에서 최근 논쟁에 대한 대답들을 정리해서 설명해줍니다.

첫째, Java EE6 서버는 스프링이 참조하는 미들웨어를 제공하는 좋은 실행환경이라는 것입니다. Java EE6 서버에서제공하는 Servlet 3.0, JSF 2.0, JPA 2.0 등의 플랫폼 기술들은 스프링은 소비자로서 사용할 수 있다고했습니다. 그리고 다소 Java EE 스펙과 중복이 될 수 있는 부분인 EJB나 CDI관련 부분은 Java EE6 기능의일부분에 불과하다는 것이였습니다. GlassFish에서는 코드량 기준으로 5% 정도만 차지할 뿐이고, 아마 5%가 넘는 다른기능들도 사용하지 않고 있는 것이 많을 것이라고 했습니다.

둘째, 스프링을 사용하면 필요에 따라더 넓은 기술을 선택할 수 있기 때문에 그것이 Java EE6 서버를 사용하는 자연스러운 방식이라느 것입니다. JSF대신 Wicket이나 GWT, EE clustering대신 Coherence 등을 쓸 수 있고, , 스프링의 jar파일은 4MB바이트 정도로 크지 않아서 이 용량이 문제가 되는 경우는 거의 없다고 했습니다.

셋째,Java EE6 서버 중 GlassFish만이 지금 GA(Generally Available)버전 이상인 상태이고, JBoss나WebSphere는 아직 안정화된 버전이전이기 때문에 Java EE 6서버만을 선택한다면 실행환경에 제약이 있다고 했습니다.스프링은 Tomcat 5,6,7버전, Java EE5 서버, 그리고 Google App Engine 같은 것에서도 돌아갈 수있고, Java EE5를 쓰면서도 스프링을 사용하면 Hibernate 3.6 같은 구현체를 써서 EE6 스펙을 쓰는 선택도가능하다고 했습니다. 다양한 플랫폼 환경에서 스프링이 조율역할을 한다는 것입니다. 실제로 최근에 올라온 CDI - A Major Risk Factor in Java EE 6라는 글에서는 아직 안정화되지 않은 버전의 서버에서 CDI를 적용하다 어려움을 겪은 이야기가 있습니다.

넷째, EE6는 2009년 초 기술환경에 맞춘 것이고, 그 후로 지금까지 분산캐쉬, Cloud 등 많은 기술들이 중요하게떠올랐는데, 그런 기술들을 스프링을 통해서 서버를 업그레이드할 필요없이 훨씬 빠른 시기에 지원받을 수 있다는 것입니다. 이번컨퍼런스 내내 NoSQL, 분산 캐쉬, Social network 같은 다양한 주제들이 강조된 것도 그런 강점을 강조하기 위한전략으로 보였습니다.

정리하자면 Spring과 Java EE6는 잘 맞는 궁합이면서 중복되는역할의 라이브러리 용량은 현실적으로 문제될 것이 없으며, 스프링으로 더 다양한 기술과 실행환경을 활용하면서 일관된 프로그래밍모델로 개발할 수 있다는 것이 핵심 주장이였습니다.

PMD ruleset 검토 의견 사례

Thu, 28 Oct 2010 00:00:00 +0000

이전에 PMD 룰셋 검토했을 때 정리했던 의견입니다.

Rule에 대한 유용성은 프로젝트의 상황에 따라서 많이 다르기 때문에, 아래 의견은 참고만 하셨으면 합니다.

Rule Set

Rule name

Message

분류

의견

설명, 의견 사유

참고자료

Basic Rules

EmptryInitializer

Warning

제외요망

PMD 5.0에서 추가될 룰로 Maven plugin에서는 지원되지 않음

Braces Rules

IfStmtsMustUseBraces

Avoid using if statements without curly braces

Warning

논의필요

if문뒤의 한줄짜리 처리문도 \{}가 없으면 경고를 줌. 가독성을 높여주므로 포함시키는 것이 바람직.

Code Size Rules

TooManyMethods

This class has too many methods, consider refactoring it.

Warning

논의필요

한 클래스에 지나치게 많은 메소드가 포함되면 나는 경고. 적당한 클래스 크기를 정하는데 도움을 주나, 정말 논리적 연관성이 있는 작업을 많이 담고 있는 클래스도 존재할 수 있으므로 적정 숫자에 대해서는 논의 필요함

Controversial Rules

OnlyOneReturnRule

A method should have only one exit point, and that should be the last statement in the method

Warning

제외요망

메서드 중간의 return문은 복잡한 조건문의 구조를 단순하게 하는데 도움이 경우가 많고, 권장하는 사례도 있음.

켄트백의 구현패턴 - 7장 중 '보호절'

Controversial Rules

DataflowAnomalyAnalysis

Found 'DD'-anomaly for variable …

Info

제외요망

전체 데이터의 흐름을 분석해서 return값과 상관없는 변수에 값을 쓴다든지 하는 상식적이지 않은 경우를 잡아내줌. 캐쉬나 interceptor등 그런 흐름이 꼭 필요한 코드도 경고해줘서 지나치게 많은 경고를 생성함

Controversial Rules

Unused Modifer

Avoid modifiers which are implied by the context

Warning

논의필요

interface는 당연히 모든 method가 public이니 따로 선언해줄 필요가 없는 현상등을 주의를 줌. 개발자에 따라서는 public이 있는 것이 더 명시적이라고 생각할 수도 있고, 이미 모든 인터페이스가 public으로 다 선언되어 있는 상황에서는 개발자들에게는 무의미한 수정으로 인식될 위험도 있음.

Design Rules

UnnecessaryLocalBeforeReturn

Consider simply returning the value vs storing it in local variable ….

Warning

제외요망

return 전에 따로 local 변수로 반환할 값을 선언할 때 주는 경고. 기능적으로는 별 의미 없는 코드이나, return 문장에는 @SupressWarning 의 Annotation을 추가할 수 없기 때문에, Annotation 적용 범위를 최소화하기 위해 그런 선언이 필요한 때도 있음. Debug Mode에서도 값의 추적에 약간의 편리성이 생길 수 있음.

Java Language Spec 9.7, Effective Java 2ed - Item 24

Design Rules

UncommentedEmptyConstructor

Document empty constructor

Warning

제외요망

빈 생성자에 comment가 없어도 코드의 이해에 무리가 없는 경우가 많음

Design Rules

UncommentedEmptyMethod

Document empty method

Warning

제외요망

Listener류의 인터페이스의 구현에는 특정 메소드는 아무 일도 하지 않는 메소드로 남겨놓을 때도 있고, 종종 발생하는 상황임. 그리고 그 상황에 주석이 없다고 해도, 코드 이해에 무리가 없음

Design Rules

ImmutableField

Private field '…' could be made final; it is only initialized in the declaration or constructor. EmptyInitializer

Warning

제외요망

멤버변수 중 선언되어서 한번만 값이 대입된 변수는 final로 할 수 있다고 알려주는 경고. 개발자가 Final로 의도하지 않지만, 현재 기능에서는 한번만 대입하고 있는 상황도 존재할 수 있다고 생각됨.

Jakarta Commons Logging Rules

ProperLog

Logger should be defined private static final and have the correct class

논의필요

private static final Log log = LogFactory.getLog(해당클래스) 로 로거를 선언할 것을 알려줌. 대체로 무난히 적용가능하나, 프로젝트의 로그 정책이 특별한 경우도 있으므로 논의해볼만 함

Java Bean Rules

BeanMemberShouldSerialize

Found non-transient, non-static member. Please mark as transient or provide accessors.

Warning

제외요망

Java Bean의 명세를 검사하는 규칙. 일반적인 클래스는 transient하지 않으면서도 acessor가 없는 멥버 변수가 올 수 있는 경우가 많음. 스프링에서 선언하는 bean들은 setter만 가지는 경우가 많으므로 대부분 이 규칙에 어긋나게 됨. (스프링에서 bean은 java bean명세보다 보다 넓은 bean을 의미하는 것으로 생각하면 됨)

Java Loggins Rules

Systemprintln

System.out.print is used

Error

논의필요

웹Application에서는 반드시 피해야할 코드라서 출시시에는 꼭 걸러내야하나, 분류가 Error가 되어 있는 것에 대한 논의는 필요함. 그리고 Console에서 도는 간단한 프로그램이나 테스트코드에서는 System.out이 들어가는 것이 결함이 아니므로 폴더 범위나 네이밍룰을 추가한 보다 정교한 Rule지정하는 것이 바람직함(예를 들어 Controller, Service, DAO안에는 System.out불가)

Junit Rules

JunitAssertionsShouldIncludeMessage

JUnit assertions should include a message

Warning

제외요망

테스트 결과를 확인할 때, 메시지가 포함된 것이 바람직하나, 테스트 코드 작성을 장려하기 위해 테스트 코드에 대한 제약은 줄이는 것이 좋을 것으로 판단됨

Junit Rules

JunitTestsShouldIncludeAssert

JUnit tests should include assert() or fail()

Warning

제외요망

assert나 fail이 있는 테스트코드가 의미가 있으나, 그렇지 않은 코드도 없는 것 보다는 나으므로, 테스트 코드 작성을 장려하기 위해 관대한 정책을 권장함

Migration Rules

Junit4TestShouldUseTestAnnotation

JUnit 4 tests that execute tests should use the @Test annotation

Warning

제외요망

Junit3.8로 기준으로 작성된 코드에서 Junit4의 요건을 요구하면서 warning을 냄.

Naming Rules

LongVariable

Avoid excessively long variable names like …

Warning

제외요망

표현력이 높은 변수이름을 짓는 것을 권장하기 위해서 길이제한을 두는 것은 바람직하지 않음

Naming Rules

ShortVariable

Avoid variables with short names like…

Warning

논의필요

"is","os"등의 2글자 변수명일 때 나는 경고. 실제로 2글자만으로도 문맥상으로 충분한 표현력을 가지는 상황도 있고, 한 메소드가 크게 길어지지만 않는다면 local variable의 경우에는 다소 관대한 정책을 넣는 것도 무리는 없음

Optimization Rules

AvoidInstantiatingObjectsInLoops

Avoid instantiating new objects inside loops

Warning

제외요망

Loop안에서 new keyword가 존재하면 나는 경고임. 피할 수 있는 경우라면 피해야 겠지만, GC시점이 약간이나마 늦어질 수 있고, collection.clear같은 청소 매서드 호출이 필요해진다거나, Thread safe해지지 않는 경우 등 손해가 있는 상황이 있으므로, 항상 지켜야할 지침이라고는 보기 어려움

Optimization Rules

LocalVariableCouldBeFinal

Local variable '…' could be declared final

Warning

제외요망

local 변수 중 final이 될 수 있는 것을 알려주는 정보. Final이 되면 경고를 주는 이와 상반된 룰도 존재함

Optimization Rules

MethodArgumentCouldBeFinal

Parameter '…' is not assigned and could be declared final

Warning

논의필요

방어적 프로그래밍을 위해서 파라미터는 final로 선언하는 것이 바람직하나, 모든 메서드를 그렇게 하면 메소드 시그니처가 전부 다 길어지기 단점이 있음. 기술인프라성 공통코드에만 적용하는 방안이 바람직하다고 생각함

Strict Exception Rules

SignatureDeclareThrowsException

A method/constructor shouldn’t explicitly throw java.lang.Exception

Warning

논의필요

메소드나 생성자가 throws Exception으로 최상위 Exception을 던질때 주는 경고. Checked Exception의 남발을 막고, 정교한 Exception선언을 돕는다는 장점도 있어서 되도록 권장하고 싶지만, 기존 코드의 Exception 선언이 throws Exception이 남용되어 있을 때 등 프로젝트 후반기에는 적용이 어려움

String and StringBuffer

AvoidDpolicateLiterals

The String literal " rows, page " appears 4 times in this file; the first occurrence is on line 70

Warning

논의필요

중복 되는 문자열 상수가 많은 경우에 나타남. 내부적으로는 java의 상수풀을 사용하게 되므로 성능에는 영향은 없음. 반복되는 문자열도 따로 상수선언을 하게 하는, 좋은 코딩습관에 도움이 되나 ,테스트 클래스 등의 안내 메시지 등의 그리 중요하지 않은 부분에서 지나친 상수선언을 하게 할 수 있음.

SpringOne2GX 2010 (2) Spring 3.0 → 3.1 → 3.2 Themes & Trends

Sat, 23 Oct 2010 00:00:00 +0000

스프링 프레임웍의 핵심 개발자 유겐할러는 "Spring 3.0 → 3.1 → 3.2 Themes & Trends"라는 제목으로 두번째 날 첫시간에 발표를 했습니다. 로드존슨은 어느 인터뷰에서 지금까지 만났던 가장 뛰어난 개발자는 생각할 것도 없이 유겐할러라고 말한 적이 있었고, 그렇게 전적인 신임을 받고 있어서 인지 유겐할러는 스프링 core 모듈의 대부분의 코드를 만들었다고 합니다. 그래서 유겐할러는 스프링 커뮤니티에서 로드존슨에 버금가는 유명인인데, 예상대로 이 날 발표 장소에는 사람들이 꽉 차게 몰려왔습니다.

발표에 들어가기 전에, 스프링 3.0 버전을 쓰는 사람과, 그중 실제 3.0에 들어간 기능을 쓰는 사람들은 손을 들어봐라고 유겐할러가 이야기했는데, 절반 정도의 사람들이 손을 들었던 것 같습니다. 컨퍼런스에 와서 그 발표를 들은 사람을 대상으로 한 질문이라서 당연한 것일수도 있지만 3.0버전의 기능이 커뮤니티에서는 호응이 괜찮다는 느낌이 들었습니다.

유겐할러는 자신이 맡은 책임 중 핵심적인 것은 클라우드, 분산 캐쉬와 같은 최신의 경향(modern day trends)에 맞추어 스프링 Core에 어떤 것이 들어갈지를 결정하는 것이라고 했습니다. 뒤에서 설명된 3.1의 캐쉬 Abstraction, 3.2의 fork-join pool 지원 등이 그런 트렌드을 쫓아가기위한 대표적인 예였습니다.

3.1과 3.2는 3.0의 자연스러운 다음버전이라고 합니다. 큰 구조변화보다는 기능이 추가되는 성격의 버전이라는 의미라고 생각되었습니다.

릴리즈 일정

발표 중간 중간에 이야기한 향후 스프링버전의 릴리즈 일정은 아래와 같습니다.

3.0.5 : 2010년 10월에, 곧. 3.05 이후로 바로 3.1은 위한 마일스톤 버전으로 넘어간다고 했습니다.
3.1 M1: 2010년 11월 말
3.1 M2: 2011년 1월 초?
3.1 RC1 : 2011년 2월말?
3.1 GA : 2011년 3월말?
3.2 : 2011년 말 경

뒤로 갈수록 물음표(?)가 들어가 있고, 지금까지 일정을 정확히 지킨 적이 없었던 것으로 보아 실제로 저 일정에 나올 가능성은 적다고 예상됩니다. Spring 3.0도 2008년에 이야기할 때는 2009년 초에 나올 것이라고 말한 적이 있는데, 실제로 3.0.GA 버전이 릴리즈된 것은 2009년 12월이였습니다. (스프링 이슈트래커로 본 Spring 3.0의 전망, Spring Jira의 실제 release 날짜 참조)

일정관리를 엄격하게 안 하나 하는 생각도 들었는데, 공개 API의 모음인 프레임웍이라는 특성 때문에 일정보다는 완성도를 중요시 할 수 밖에 없을 것도 같았습니다. 두번째 날의 밤에 'Birds of a feather session’라고, 컨퍼런스의 트랙별로 발표자나 핵심개발자들과 이야기를 할 수 있는 자리를 마련해줬는데, 거기서 내부적으로 어떤 개발방법론을 쓰는지에 대한 질문이 나왔었습니다. 거기에서 스크럼 같은 일반적인 애자일 프랙티스를 따르기는 하는데, 프레임웍은 배포 한 후에 수정을 하는 것이 어렵기 떄문에 원래의 스크럼 방식과는 잘 맞지 않는 부분도 있다는 말이 답변 중에 나왔었습니다.

A review : 3.0

3.0에 추가된 기능들을 되돌아 봤는데, 이미 널리 알려진 기능들이라서 자세히 옮기지는 않겠습니다.

Annotated component model.(JSR 330, JSR 303, JavaConfig등)
Rest Support
Portlet 2.0 지원
스케쥴과 태스크 실행 개선
Java EE6 지원

(자세히 아시고 싶으신 분들은 http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/new-in-3.html 를 참조하시기 바랍니다.)

이중 JavaEE6에 대한 내용은 세번째 날 역시 유겐할러가 발표한 'Spring and JavaEE 6’라는 세션에서 자세하게 설명 되었습니다.

A preview : 3.1

3.1에 추가되는 주요 테마들은 다음과 같습니다.

Environment profiles for bean
Java-based applicaion configuration
Cache abstraction
Conversation Managment
Servlet 3.0, JSF 2.0, Groovy

Environment profiles for bean

이 기능은 bean 설정들을 환경별로 묶는 것을 지원합니다. 즉, 개발환경, 테스트환경, 운영환경에 맞는 bean 선언들을 그룹화해서 지정할 수 있게 하는 것이죠. Bean 선언이나 Annotation선언에 Profile을 이름을 지정하는 방식이 될 것이라고 합니다.

XML선언에는 다음과 같이 profile속성이 추가됩니다.

<beans .... profile="dev">

  <bean>...</bean>

  <bean>...</bean>

</beans>

Annotation으로는 @Profile 을 지정하게 됩니다.

@Service

@Profile("dev")

class UserService\{

.....

}

그리고 Inject 가능한 API 형식으로 환경에 대한 추상화도 지원할 것이라고 합니다.

보통 database의 URL 같은 속성들은 별도의 property 파일로 빼서 관리하는 placeholders라는 기능을 쓰는데, 이 기능도 실제 환경에 의존적으로 placeholder를 나름대로 지정할 수 있는 기능이 나온다고 합니다.

Java-based applicaion configuration

이미 3.0에 JavaConfig 기능이 포함되어서 @Configuration, @Bean 등의 Annotation이 추가되었는데, 어떤 기능들이 더 추가되는 것일지 궁금했었습니다. 3.1에 들어가는 Java-based configuration은 tx나, aop 같은 custom name-space와 같은 선언들이 Java파일로도 가능하게 하는 것이였습니다. Spring Batch나 Security, Integration에서도 이러한 custom name-space들을 많이 쓰는데, 그런 설정들이 xml로 bean 선언을 할 때는 설정을 간편하게 하지만, JavaConfig로 옮기기에는 불편해서 아쉬웠던 점이 있습니다. Spring Batch에서 ItemReader, ItemWriter 선언을 JavaConfig로 옮겨보니 훨씬 코드가 짧아지고 Compile time의 validation 범위도 넓어져서 만족했었는데, Job과 Step의 선언은 custom namespace로 하는 것이 더 간편해서, XML에 남겨두었었습니다. 그리고 유사하게

http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683/ref=sr_1_1?ie=UTF8&qid=1287800130&sr=8-1[Enterpise Interation Patterns]를 구현한 Apache Camel는 Java로 된 DSL을 지원하는데 반해서 Spring Integration은 간결한 선정을 하려면 Xml의 Custom name space를 사용해야 되어서 아쉬웠던 적이 있었습니다.(http://java.dzone.com/articles/spring-integration-and-apache 참조)

3.1에서 그렇게 javaConfig로도 추상화정도를 높인 선언을 할 수 있는 기능이 추가된다면, 스프링포트 폴리오의 다른 프로젝트에서도 많은 개선이 이루어질 것이라고 기대됩니다.

Cache Abstraction

현재도 스프링에 org.springframework.cache라는 패키지는 존재합니다. 그런데 아직까지는 EhCache에 대한 지원클래스만 있습니다. 3.1에서는 이 패키지를 채워넣을 것이고, 분산캐쉬를 기술과 연결되는 구현체도 포함될 것이라고 합니다. 기본적으로 EhCache, GemFire, Coherence를 지원한다고 밝혔습니다. 물론 인터페이스에 맞춰서 직접 구현하는 것도 가능하고, ConcurrentHashMap을 이용한 간단한 기본 구현체도 제공합니다.

발표가 끝난 뒤에 저와 같이 간 일행인 김훈민 대리가 직접 유겐할러에게 찾아가서 Memcached에 대한 지원 계획을 물어봤는데, out-of-box로 바로 쓸 수 있는 Adaptor는 아직까지는 계획에 없다고 했습니다. 여러 가지 라이센스 문제 등에 부딪힐 수 있어서 협의가 필요한데, 원한다면 이슈 등록을 하고 투표를 하라고 이야기했습니다. 개인적으로 Simple Spring Memecached( http://code.google.com/p/simple-spring-memcached/) 프로젝트와 유사한 Memcached 지원이 Spring Core에 들어갔으면 했는데, 다소 아쉬운 부분이였습니다.

많은 곳에서 이미 Annotation과 AOP를 활용해서 Cache를 활용해서 이미 예상을 했었는데, Spring 3.1에는 아래와 같이 Cache 지원을 위한 `@Cacheable`, `@CacheEvict` 라는 Annotation이 추가됩니다.

@Cacheable
public Owner loadOwner(int id) \{

....

}

@Cacheable(condition="name.length<10")
public Owner loadOwner(String name)\{

....

}

@CacheEvict
public void deleteOwner(int id)\{

....

}

Annotation이 붙은 메소드의 signature와 파라미터로 캐쉬에 넣을 key로 인식하게 됩니다. 유겐할러는 이런 방식의 처리가 Cache의 전형적인 사용의 80% 유형정도를 차지할 것이라고 말했습니다. Cache Abstraction은 Cache의 모든 기능을 통합해서 같은 API로 묶는 것이라기보다는, 주요 쓰임새를 더 짧은 코드로 편하게 쓸 수 있게 하는데 초점이 맞춰진 것으로 보입니다. 정교한 캐쉬처리나 각각의 캐쉬 특성에 맞는 API사용 등은 직접 특정 Cache의 API를 당연히 사용해야겠죠. 그리고 transaction처리에 쓰는 PlatformTransactionManager와 비슷하게 CachedManager라는 SPI가 들어가고, tx namespace처럼 cache에 대한 namespace도 추가된다고 합니다. <cache:annotation-driven />과 같은 선언은 기존에 스프링을 쓰던 사람에게는 익숙하게 보입니다.

이미 EhCache를 Spring에서 활요할 때 쓰는 @Cacheable annotation이 있는데, 이 모델이 좀 더 확장될 것으로 보입니다. 아래 자료에 현재에도 사용가능한 방식이 나와 있습니다.

http://code.google.com/p/ehcache-spring-annotations/wiki/UsingCacheablehttp://code.google.com/p/ehcache-spring-annotations/wiki/UsingCacheable
http://whiteship.tistory.com/1256

Converstion management

Conversation session에 대한 추상화 계층을 추가될 예정이라고 합니다. 기본적으로 HttpSession을 포함하여 더욱 유연한 생존주기와 저장소를 제공한다고 했습니다.

보통 웹어플리케이션에서 여러 페이지간의 상태를 공유해야하는 Conversation 범위가 생길 수가 있는데, 보통 Session을 쓰는 것이 일반적이지만, 같은 윈도우에 있는 다른 탭이라도 같은 Session의 id가 먹는 상황이 있고, 수동적으로 이런 경계를 관리해야 할 때가 있습니다. 새로운 기능은 이런 것들을 위임할 수 있는 공통적인 기반을 제공한다고 합니다.

이 기능은 Spring Webflow의 3.0에도 바탕이 될 것이고 MVC나 JSF에도 공통적으로 쓰일 수 있다고 했습니다.

그리고 웹어플리케이션 뿐만이 아니라 메시징 환경에서 메시지 헤더 안에 conversation id를 포함시키는 쓰임새에도 적용가능하도록 Conversation을 위한 인터페이스는 범용적인 목적의 API가 될 것이라고 합니다.

Support for Servlet 3.0

Tomcat 7, GlassFish 3 등에서 Servlet 3.0 스펙을 지원하는 Container에 대한 지원이 포함됩니다.

web.xml에 명시적으로 프레임웍에 대한 Listener 선언을 하지 않고도 자동으로 deployment되는 옵션을 지원하고, 표준적인 파일업로드에 대한 지원이 된다고 합니다. 스프링의 MultipartResolver interface도 그 안에 포함될 것 같습니다.

Enchance Groovy Support

<lang:groovy> 로 xml 파일안에 Groovy를 쓸 수 있는 지원이 강화됩니다.

base script classes
custom bidings
스프링 빈들을 이름으로 암묵적으로 접근
Velocity나 Freemarker 대신 쓰일 수 있는 Groovy 바탕의 Template 파일. Email 템플릿 같은 것에 사용할 수 있다고 하네요

`c:namespace`

XML로 Bean 선언을 할 때 p namespace과 같은 역할을 하는 c namespace가 추가됩니다. p가 <property name.. > 에 대한 짧은 표현였다면, c는 <constructor-arg>를 간결하게 표현할 수 있게 줍니다.

아래와 코드와 같이 거의 p namespace와 사용법이 똑같아 보입니다.

<bean class="..." c:age="10/>

<bean class="..." c:family-ref="myFamily/>

A sneak preview : 3.2

3.2에는 JDK 7을 바탕으로 추가될 수 있는 기능들을 계획하고 있었습니다. JDK 7은 2011년 7월에 release 예정이라서 3.2에 대한 Release도 당연히 그 뒤가 되겠습니다.

그리고 당연히 java 5, 6 user를 위한 기능도 있을 것이고, 그런 기능들은 Spring 3.1이 GA로 간 다음에 사용자들의 요청에 따라서 결정될 것이라고 합니다.

Java SE 7 Support

Spring 3.2의 초점은 JRE 7 을 가장 잘 쓰는 사용법이라고 했습니다. JDBC 4.1에 대한 지원과 Java concurrent 패키지에서 개선되는 fork-join 프레임웍에 대한 지원계획이 있었습니다.

멀티코어의 Concurrent 프로그래밍에 초점

동시 요청보다 Core수가 더 많은 시나리오에 초점을 맞추어서 API제공을 계획하고 있다고 합니다. 예를 들면 Spring Batch에서 큰 Xml파일을 처리할 때와 같이, 처리 요청은 하나이기 때문에 요청 건별로 병렬처리를 하기가 힘들지만 자원소모가 커서 병렬처리를 했을 때의 이득이 큰 경우를 염두에 둔 것이였습니다. 그런 곳에 사용할 수 있는 특화된 ForkJoinPool이 Application context안에 들어갈 것이라고 했습니다.

SpringOne2GX 2010 (1) 키노트

Wed, 20 Oct 2010 00:00:00 +0000

2010년 10월 19일부터 22일까지 시카고에서 열리는 SpringOne2GX 2010 행사에 참석하고 있는 중입니다. 정리가 완벽하게 되지 않아도 중간중간 듣고 본 것들을 올리도록 하겠습니다.

수정이력

(최초작성) 키노트의 내용을 발표 때 사용한 슬라이드 자료를 보면서 정리를 하려고 마음을 먹고 있었습니다. 그래서 특별히 메모도 하지 않고 있었는데, 키노트가 끝난 다음에서야 발표 자료가 아직 올라오지 않았다는 것을 알았습니다. 그래서 대략적으로 기억나는 것들을 같이 간 분들에게 물어보고 보완하면서 트위터에 올라온 글들 ( http://twitter.com/#!/search/s2gx )을 보고 회상한 내용으로 일단 정리합니다.

키노트의 제목은?

로드존슨은 첫장에 키노트의 제목을 표시하지 않고 '여기에 제목이 들어간다’는 슬라이드 템플릿에 있을법한 문구를 그대로 보여줍니다. 나름대로 웃음을 주려고 했던 의도도 있었지만, 지난 12개월동안 스프링 세계에 어떤 일이 일어났는지를 키노트에서 정리해야 하는데, 이번에는 그것이 쉽지 않았음을 이야기 합니다. 발표가 한참 지나서야 제목이라고 할만한 내용들을 이야기하는데, 간단히 정리하면 '스프링의 성공요인이였던 Portability, Productivity, Innovation을 다음 10년에도 새로운 영역에서 이어서 가고, 개발자들이 더욱 핵심 비지니스 가치의 전달에 전념할 수 있도록 돕는다’라고 말할 수 있었습니다.

그동안 스프링 세계에 있었던 일들..

키노트 발표는 이번 컨퍼런스의 주요 후원자인 Accenture, Google, Saleforce.com에 대한 스폰서들에 대한 감사의 이야기로 시작되었습니다. 이번 컨퍼런스를 통해 비니지스 어플리케이션을 전통적인 데이터 센터에서 클라우드 환경으로 올리겠다는 비전을 강조할 것이라고 미리 예상을 했었고, 인터넷 업계, 시스템통합, SaaS 업계의 최강자들인 이들 세 업체가 그런 비전을 공유하고 후원업체로 전면에 나와 있다는 생각이 들었습니다.

이어서 얼마전에 발표되었던 vFabric cloud platform의 그림을 보여줍니다.

참조 : http://blog.springsource.com/2010/08/31/cloud-platform/

이 아키텍처에서 모니터링은 Hyperic, 메시징큐는 RabbitMQ, 캐슁을 위한 데이터그리드는 Gemfire가 들어가는데, 작년부터 스프링소스가 인수합병을 통해서 확보한 솔루션들입니다.

이어서 이런 솔루션들이 현재 얼마나 중요한 시스템에서 쓰이고 있는지 레퍼런스를 알려줍니다. Gemfire는 NASA나 펜타곤에서, RabbitMQ는 인도의 수많은 인구들의 주민등록 정보를 관리하는 곳에 들어가 있다고 합니다.

그리고 다른 스프링 포트폴리오 프로젝트의 대표적인 발전도 정리해줍니다.

Spring 3.1 : Cache abstraction, 환경에 특화된 bean 설정
Spring Integration 2.0 : Spring Tools Suite를 통한 plugin지원, 더 많은 Adaptor 지원
Spring Web flow 3.0 : Java flow Definition 지원 (https://jira.springsource.org/browse/SWF-295 이 이슈를 말한 것으로 짐작됩니다.)
Grails : Spring Tools Suite에 추가된 Grails 지원 기능을 Demo로 보여주었습니다. 프로젝트 생성, Entity 생성, Grails command 입력등을 Eclipse 안에서 편하게 할 수 있고, Grails View에서 Grails에 구조에 맞는 디렉토리 구성을 더 편하게 볼 수 있었습니다.

개인적으로 Cache abstraction에 가장 관심이 가는데, 이 주제를 다룰 내일 유겐할러의 발표를 기대해 봅니다.

스프링의 지난 10년과 그 다음

로드존슨은 스프링 프레임웍이 이제 새로운 10년대를 맞이하고 있음을 강조합니다. 로드존슨이 직접 밝힌 스프링에서 가장 오래된 클래스는 RequstHandlerEvent.java로 2001년 1월 17일 처음 만들어졌습니다. (스프링의 오래된 클래스들에 대해서는 토비님이 쓰신 스프링코드의 역사 글에서도 재밌는 정보들을 찾을 수 있습니다.) 로드 존슨의 큰 아들의 다음 생일이 10번째 생일인데, 걔가 스프링보다는 나이가 어리다고 합니다.

그렇게 10년을 지나오면서 스프링을 성공으로 이끌었던 핵심가치들은 Portability, Productivity, Innovation의 3가지 단어로 설명했습니다.

Jetty, Tomcat을 포함한 많은 Application Server들에서 Spring 애플리케이션이 돌아갈 수 있었던 Portability는 이제 다음 목표를 이제 Google App Engine, VMForce와 같은 클라우스 서버 영역으로까지 나아가고 있습니다. 그리고 Grails, Spring Roo, Spring Tools Suite를 이용한 생산성 향상도 계속되고 있습니다. Spring Roo에서는 GWT 지원, Database reverese-engineering 기능이 포함된 다는 것을 홍보했습니다. 바이트코드 삽입(Instrumentation)을 통한 Application Monitoring 도구인 Spring Insight를 운영환경에서 사용할 수 있도록 성능저하가 없는 버전을 준비하고 있다고 합니다.

스프링이 나아가는 새로운 영역들 중에 Social media 결합, NoSQL 저장소 지원, 모바일 환경의 다양한 Client 지원 기능등이 특히나 신선한 소식이였습니다.

새로운 영역들

NoSql

로드존슨은 NoSQL을 Not only SQL이라고 풀어줬습니다. 전통적인 데이터 저장소였던 RDB도 나름대로의 영역을 지키겠지만, 이제는 RDB만으로는 해결할 수 없는 문제들이 많아 생겼다는 것입니다. 그렇다고 RDB를 배제하는 것이 아니라는 것을 Not only SQL이라는 말로 강조했다고 느껴졌습니다.

이미 GORM에서는 Redis를 지원하는 Addon을 넣었다는 소식을 이미 들은 적이 있습니다.

Grails adds GORM for Redis 참조

이날은 neo4j(http://neo4j.org/)를 이용한 GraphDB 지원에 대한 코드를 보여줬습니다. Graph DB는 친구사이 관계 같은 것이 저장되는 social media같은 서비스에 적합한 구조인데, 스프링과 neo4j의 결합은 원래 neo4j의 API를 쓰지 않고 annotation으로 필드 간의 관계를 설정하는 것이였습니다. 이것도 내부적으로는 Aspect J를 이용해서 동작한다고 했습니다. Graph DB를 위한 annotation은 JPA annotation과 같이 쓰여서 Domain object에서 관계형 DB와 Graph DB에 연결되는 정보를 동시에 볼 수 있었습니다. 로드존슨은 이를 polyglot persistence, cross persistence라고 표현했습니다. 다수의 저장소를 활용할 때 Java Object가 그 연결정보의 구심점이 되는 모습이 간단한 코드에서 잘 보여졌습니다. Spring roo에서도 Neo4j를 위한 Addon이 들어갔다고 합니다.

Spring-data 프로젝트(http://git.springsource.org/spring-data)에서는 Graph DB이외에도 key-value, document, column 저장소들을 위한 하위 프로젝트가 진행되고 있었습니다.

Social Media와 다양한 client의 시대

로드존슨은 근래의 기술환경이 Mobile 환경의 다양한 Client와 브라우저에 대처해야 한다는 것을 상기시킵니다. 그리고 Twitter와 Facebook과 같이 Social Media와 연결된 개발도 중요한 이슈입니다. 스프링에서도 이에 대비하고 있는데, Spring-mobile(http://git.springsource.org/spring-mobile)과 Spring-social(http://git.springsource.org/spring-mobile%29%EA%B3%BC%20Spring-social%28http://git.springsource.org/spring-socialhttp://git.springsource.org/spring-social[http://git.springsource.org/spring-social] ) 프로젝트가 이와 관련되어 있습니다. 그리고 GreenHouse(http://git.springsource.org/greenhouse) 프로젝트가 이들을 활용한 실제 예제가 되는 프로젝트입니다. GreenHouse는 https://greenhouse.springsource.org/ URL로 들어가볼 수 있고, Spring 개발자들의 social network 기능을 할 수 있어 보였습니다. iPhone와 Android client가 있는데, iPhone client는 시뮬레이터를 통해서 데모를 보여줬습니다.

Missing link - Code to Cloud

로드존슨은 지금까지 스프링이 많은 영역들을 지원해왔지만, 그 중에 빠진 연결점(Missing Link)가 있었고, 그 부분은 소스관리, 이슈관리, Contious Integration, 배포에 관한 영역이였다고 합니다. 개발자들의 각각의 도구를 설치한다고 많은 시간을 소모하고 있는데, 이제 그 영역도 Code to Cloud라는 통합솔루션을 제공한다고 합니다. 이 솔루션은 Git + Hudson + Bugzilra + Mylyn + STS을 엮은 것이였습니다. Tasktop이라는 업체와 제휴를 통해 이를 제공했고, 시연도 직접 Tasktop의 CEO가 나와서 했습니다.

관련기사 : http://www.marketwire.com/press-release/VMware-Brings-the-Cloud-to-Developers-With-Code2Cloud-Application-Lifecycle-Tools-NYSE-VMW-1337583.htm
소개와 데모 동영상: http://tasktop.com/connectors/c2c.php
Spring2gx 2010에서의 시연 동영상 (http://plixi.com/p/51699717 )

Eclipse에서 테스트 코드 작성을 편하게 하는 설정

Fri, 1 Oct 2010 00:00:00 +0000

Static Import 설정

Organize import (Ctrl + Shift + O) 해도 static import의 *가 풀리지 않도록 하는 설정. Junit4 이후의 assert나, mock library, matcher 등을 사용할 때 편리하다.

Windows-Preference-Orgnize import 의 Number of static imports… 를 1로

Test 메소드와 Import에 대한 Template 설정

Window-Preference-Java-Editors-Template 에 자주 쓰는 템플릿을 추가한다.

각각의 항목의 의미는 다음과 같다

name : 축약해서 사용할 문자
context : 해당 템플릿을 사용하는 에디터 종류. 여기서는 Java코드를 입력하므로 'Java’로 선택한다.
pattern : 템플릿 내용

즉, Java에디터에서 'name' 으로 정한 문자열을 치고 Ctrl + Space를 누르면 'pattern’의 내용이 자동입력 된다.

Test 메소드 추가

테스트 메소드를 추가할 때 필요한 library import로 메소드 선언을 한꺼번에 해주는 템플릿이다.이름을 spec으로 지정해서 쓰고 있다.

@${testType:newType(org.junit.Test)}

public void ${specDescription}() {
  // given ${cursor}

  // when
  // then
  ${staticImport:importStatic('org.junit.Assert.*', 'org.mockito.BDDMockito.*', 'org.hamcrest.CoreMatchers.*')}
}

Test 라이브러리 import

위의 메소드 추가 template에서 해주는 일 중 import를 하는 부분만 수행해준다. ti라는 이름으로 지정해서 쓰고 있다. (http://wiki.kwonnam.pe.kr/java/junit/staticimports 에서 참조했습니다.)

${is1:importStatic('org.hamcrest.CoreMatchers.*')}${is2:importStatic('org.junit.Assert.*')}${is5:importStatic('org.mockito.Mockito.*')}

Spring test 지원 Annotation 추가

Junit4에서 Spring의 Application context를 올리는 테스트를 할 때 필요한 Annotation과 import 선언을 추가해주는 Template이다. 'springtest’라는 이름으로 지정해서 쓰고 있다.

${:import('org.junit.runner.RunWith','org.springframework.test.context.ContextConfiguration','org.springframework.test.context.junit4.SpringJUnit4ClassRunner')}
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "/applicationContext.xml"})

Mockito 관련 템플릿 추가

JUnit에서 Mocito의 annotation을 편하게 쓸 수 있게 해주는 선언이다. 'mockrun’이라는 이름으로 지정해서 쓰고 있다.

${:import('org.mockito.runners.MockitoJUnitRunner')}
@RunWith(MockitoJUnitRunner.class)

참고자료

Favorite 설정

자주 쓰는 static import 등록할 수 있음. 여기에 등록하면 미리 해당 라이브러리를 static import하지 않아도 Conentnt assist(Ctrl + Space)에서 에서 나오게 됨

Windows-Preference-……- Favorites

Favorites에 등록을 추천하는 클래스 * org.junit.Assert. * org.hamcrest.CoreMatchers. * org.mockito.Mockito. * org.mockito.BDDMockito. * org.mockto.Matchers.*

자동생성되는 메소드에 UnsupportedOperationException 던지기 설정

자동생성 되어서 아직 구현되지 않은 메소드를 test fail로 인식하게 함 ( http://toby.epril.com/?p=706 참고)

Preference – Java – Code Style – Code Templates 안에 Code/Method Body에 아래 코드추가

throws new UnsupportedOperationException();

테스트 코드 짤 때 자주 쓰는 단축키

코드 생성

Ctrl+ 1 : Quick fix
Ctrl + Shift + O : import 절에 없는 클래스를 추가하거나 정리
Ctrl + Shirt + M : import 추가. 클래스 import를 static import로 전환할 수 있음.

테스트 실행

Alt + Shift + X, T : JUnit으로 실행
Ctrl + F11 : Run (JUnit 실행 가능)

코드 사이를 이동

Ctrl + J : 테스트 코드와 실제 코드 사이를 이동 (moreUnit이 설치되어 있을 때)
Ctrl + Q : 가장 마지막에 편집한 코드가 있는 곳으로 돌아가기
Ctrl + T : 인터페이스에서 구현 클래스 찾을 때
Ctrl + Shift + 위아래 방향키 : method 단위로 커서 이동(method 하나만 test 실행할 때 사용 하기 좋음

리팩토링

Alt + Shift + R : 리팩토링 이름 바꾸기
Alt + Shift + V : 리팩토링 – 이동
Alt + Shift + M : 리팩토링 – 메소드 추출
Alt + Shift + I : 리팩토링 - 메서드 인라이닝 (추출의 반대)
Alt + Shift+ L : 리팩토링 local 변수 추출

More Unit

테스트 코드와 실제코드 사이를 왔다갔다 할 수 있게 하는 Eclipse plugin. TDD의 리듬 유지에 도움이 됨

update site : http://moreunit.sourceforge.net/update-site/

Maven을 쓰고 있다면 설치후 Window-Preference-More Unit에서 아래 설정을 추가하는 것이 좋다.

Directory for testcases : src/test/java
Test Suffixes : Test

Eclemma

Eclipse 내에서 Code Coverage 측정. http://blog.benelog.net/2212119 참조

update site : http://update.eclemma.org/

STS를 쓴다면 Dashboard-Extensions에서 선택해서 설치해도 됨

private 메소드를 어떻게 테스트해야 할까요?

Mon, 27 Sep 2010 00:00:00 +0000

private 메소드를 어떻게 테스트해야 할지에 대한 질문은 테스트 코드 작성에 대한 자주 나오는 질문 중에 하나입니다. 이에 대한 답변을 간단히 정리해봅니다.

많은 경우에 private method는 public 메소드에서 extract method 되어서 나온 것이므로 public을 통해서 간접적으로 테스트를 하는 것이 자연스럽습니다.
그래도 private 영역만 따로 테스트를 해야지 더욱 다양한 테스트 케이스를 편하게 작성할 수 있다거나 디버깅이 쉬워진다면 설계를 개선하라는 신호로 해석할만합니다. private 메소드가 하는 일이 크다는 신호로 해석하고 별도의 클래스로 분리하거나, 하위 클래스에서 상속을 해서 대체할 수 있는 가능성을 고려해서 protected로 해두는 것도 고려해 볼만합니다.

그럼에도 불구하고 private 메서드를 테스트해야한다면

설계 개선 등을 바로 할 수 없는 상황이라 당장 private 메서드를 테스트해야할때 쓸수 있는 방법을 이어서 소개합니다.

테스트만을 해당 메소드를 package private(default 접근자)나 protected로 바꾸어서 테스트해볼 수도 있습니다. 일반적으로 테스트를 위해서 production 코드의 접근 범위를 넓히는 것은 클래스의 노출 범위를 커지게 하므로 바람직하지 않을 수도 있습니다.
Reflection을 이용하면 강제적으로 private 메소드를 호출할 수 있습니다. 다만 이렇게 하면 메소드이름 부분이 String값으로 넘겨지게 되므로, compile time에 메소드명의 오타가 검증되지 못하고, refactoring으로 메소드명을 바꾸어도 자동으로 String으로 적힌 부분은 바뀌지 않는 단점이 있습니다. 부작용을 감수하고서라도 쓰겠다고 각오가 된 곳에 제한적으로 사용하기를 권장드립니다.

Reflection으로 private 메서드를 호출하는 방법들은 아래와 같습니다.

(1) PowerMock에서 Whitebox.invokeMethod(..) 메소드 활용

http://code.google.com/p/powermock/wiki/BypassEncapsulation 참조

(2) JUnit Addons에 포함된 PrivateAccessor

프로젝트홈 : http://sourceforge.net/projects/junit-addons
API 문서 : http://junit-addons.sourceforge.net/junitx/util/PrivateAccessor.html
샘플코드 : http://entireboy.egloos.com/4030723

(3) 직접 Reflection 활용

package edu.tdd;

import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

import org.junit.Test;

public class ReflectionCallUtilsTest {

    @Test
    public void testCallPrivate() throws SecurityException, NoSuchMethodException, IllegalAccessException, InvocationTargetException {
        UnderTest ut = new UnderTest();
        String name = "jsh";
        String address = "서울시 마포구";
        invoke(ut, "print",name, address);
        assertThat(ut.isCalled(),is(true));
    }

    @Test
    public void testCallWithPrimitiveType() throws SecurityException, NoSuchMethodException, IllegalAccessException, InvocationTargetException {
        UnderTest ut = new UnderTest();
        String name = "jsh";
        int age = 35;
        boolean printed = (Boolean)invoke(ut, "print", new Class<?>[]\{String.class, int.class}, name,age);
        assertThat(printed,is(true));
        assertThat(ut.isCalled(),is(true));
    }
    private Object invoke(Object ut, String methodName, Class<?>[] argTypes, Object ... args) throws SecurityException, NoSuchMethodException, InvocationTargetException, IllegalAccessException {
        Method method = ut.getClass().getDeclaredMethod(methodName, argTypes);
        method.setAccessible(true);
        return method.invoke(ut, args);
    }

    private Object invoke(Object ut, String methodName, Object ... args) throws SecurityException, NoSuchMethodException, InvocationTargetException, IllegalAccessException {
        int argSize = args.length;
        Class<?>[] argTypes = new Class<?>[argSize];
        for(int i=0;i< argSize;i++){
            argTypes[i] = args[i].getClass();
        }
        return invoke(ut,methodName, argTypes, args);
    }

    static class UnderTest {
        private boolean called = false;
        public boolean isCalled(){
            return called;
        }
        private void print(String name, String address) {
            System.out.println(name);
            System.out.println(address);
            called = true;
        }
        private boolean print(String name, int age){
            System.out.println(name);
            System.out.println(age);
            called = true;
            return true;
        }
    }
}

필요하다면 test 코드 안에서 쓰이고 있는 invoke메소드를 따로 Util 클래스로 분리할 수도 있습니다.

위의 코드에서 Object .. args 넘어가는 부분이 primitive type이 포함되면 Object[] 로 바뀌는 과정에서 Wrapper class로 바뀌는 auto-boxing이 발생하게 됩니다. 그래서 매개변수에 primitive type이 있을 때는 invoke(Object ut, String methodName, Object … args) 사용하면 NoSuchMethodException이 발생하게 됩니다. 그럴 때는 type을 정확히 명시해 주는 invoke(Object ut, String methodName, Class<?>[] argTypes, Object … args) 을 사용하면 됩니다.

참고자료

Testing Private Methods with JUnit and SuiteRunner : 위의 글과 비슷하게 아래 4가지 방법을 제시하고 있습니다.
- Don’t test private methods.
- Give the methods package access.
- Use a nested test class.
- Use reflection.
채수원 저 테스트 주도개발 441페이지 : public을 테스트함으로서 간접적으로 테스트하는 방식을 권장하고 굳이 한다면 Reflection을 사용할 수 있다는 점을 언급하고 있으나 부서지기 쉬운 테스트 코드가 되기 쉬움을 경고 하고 있습니다.
http://xper.org/wiki/xp/TestingPrivateInterfaces : Xper에서 논의된 내용

로또 번호 생성기 파이썬으로 만들어보기

Sat, 28 Aug 2010 00:00:00 +0000

오래 전에 블로그에 Java를 이용한 로또 번호 생성기(http://blog.benelog.net/1646013 )코드를 올린 적이 있었습니다.

갑자기 생각이 나서, 이번에는 Python으로 코딩해봤습니다.

문제

1부터 45까지의 숫자 중에 6개를 뽑는다.6개의 값이 다 달라야 한다.
출력시 작은 숫자부터 순서대로 출력

풀이

import random
balls = range(1,46)
random.shuffle(balls)
print sorted(balls[0:6])

BeanUtils 성능비교 - Apache commons, Opensymphony, Spring

Thu, 17 Jun 2010 00:00:00 +0000

수정이력

2019.04.14
- 테스트한 코드를 https://github.com/benelog/beanutils-test 로 올림
2010.06.21
- EP님의 지적으로 Apache commons Beanutils에서도 PropertyUtils.getPropertyDescriptor를 사용한 방식으로 비교해봤습니다.
- 이상민님의 지적으로 직접 Bean의 setter를 호출하는 방식의 자료도 추가
- BeanUtils.populate의 경우 다양한 type을 가진 property 변환을 하는 등의 실제로 많은 기능을 수행함을 설명 추가를 했습니다.

덧붙임

2019년 2월 시점에 다시 이글을 보니, JMH로 테스트하는 것이 좋았을것 같다는 생각이 듭니다.

조사 내용

getter, setter가 있는 Java Bean들의 property들을 복사할 때 apache commons beanutils(http://commons.apache.org/beanutils/ ) 가 많이 쓰이고 있습니다.

그리고 Spring이나 Opensympony 쪽에도 간단한 BeanUtils가 따로 있습니다.

Spring BeanUtils : http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/beans/BeanUtils.html
Opensymphony BeanUtils : http://www.opensymphony.com/oscore/api/com/opensymphony/util/BeanUtils.html

이러한 BeanUtils들은 reflection을 내부적으로 쓰고 있으니 성능이 안 좋을 것이라는 우려를 할 수 있습니다. 어느 정도 성능 손해는 개발 편의성을 위해서 희생할 수 있는 경우도 많습니다. 그런데, 유사한 용도로 Bean복사를 하더라도 Apache commons BeanUtils쪽이 성능이 더 안 좋다는 소문은 있고 아래 자료에 의하면 100k byte object를 다룰 때는 Spring의 beanUtils에 비하면 거의 5~6배정도의 성능차이가 나는 것으로 알려져있습니다.

http://www.christianschenk.org/blog/java-bean-mapper-performance-tests/

이는 commons BeanUtils가 단순히 bean을 복사하는 것보다는 많은 기능을 가진 상위수준의 라이브러리 이기 때문에 당연한 결과라고 보여집니다. Spring이나 Opensymphony의 BeanUtils는 단순히 Bean간의 데이터 복사, 속성정보를 얻어오는 정도인데, apache commons의 BeanUtils는 DynaBean 등 보다 넓은 개념들을 확장해서 제공하고 있습니다. 그리고 BeanUtils.populate는 복사하려는 type이 정확하게 일치하지 않을 경우에도 복사를 해주는 등, 더 확장된 기능을 제공하고 있습니다. (첨부한 소스의 BeanConverterTypeConversionTest 파일을 보면 Map에 String으로 들어간 속성이 Bean에는 Integer, BigDecimal로 선언되어 있을 때, BeanUtils.populate는 제대로 복사를 해주는 것을 보여줍니다.)

그렇다면 type이 일치하는 단순한 Bean간의 복사등에는 굳이 apache commons beanutils까지 사용할 필요가 없은 경우도 많을 것입니다.

아래에서는 List<Map> → List<Bean> 로 변환을 시켜주는 기능을 각각의 library로 구현해서 성능비교를 해보았습니다. 소스들은 Eclipse project형태로 첨부파일에 들어가 있습니다.

비교군은 아래와 같습니다.

By Hand : 직접 map.get과 bean의 setter를 이용해서 복사
Spring(property descriptor) : Spring의 BeanUtils.getPropertyDescriptors를 사용. Spring의 BeanUtils에는 직접적으로 Map에서 Bean으로 복사해주는 메소드가 없어서 이 방식을 이용했습니다.
Apache Commons(property descriptor) : 2번과 같은 방식을 사용하고, 라이브러리만 Apache commons BeanUtils의 PropertyUtils.getPropertyDescriptor를 사용
Apache Commons(populate) : Apache comons BeanUtils의 BeanUtils.populate 메소드를 사용
OpenSymphony(setValues) : Opensymphony의 BeanUtils.setValues를 사용

실행 시간 비교 결과

1만번부터 10만번까지 변환갯수를 늘여주면서(X축), 밀리세컨트 단위로 간단히 수행시간(Y축)을 측정했습니다.

Opensymphony 쪽이 너무 많이 차이가 나서 제외하고 나머지 4개만 다시 그려봤습니다.

size	By hand	Spring (property descriptor)	Apache Commons (property descriptor)
0	0	0	0
10,000	15	78	63
20,000	32	93	125
30,000	15	141	141
40,000	32	188	187
50,000	15	218	250
60,000	15	250	297
70,000	32	297	359
80,000	32	359	360
90,000	46	406	438
100,000	63	454	484

결론

19개의 속성을 가진 Bean을 대상으로 했을 때, Map→Bean 변환의 10만건의 경우 순위는 아래와 같았습니다.

By Hand > Spring(property descriptor) = Apache Commons(property descriptor) > Apache Commons(populate) > OpenSymphony(setValues)

직접 손으로 한 것이 Sprng BeanUtils나 Commons의 PropertyUtils로 propery descriptor를 통해 호출한 것보다 7배 이상 빨랐습니다.

그리고 PropertyDescriptor를 활용한 방식들이 그 다음 순위로, 비슷한 실행속도가 나왔습니다. Spring BeanUtils쪽에서는 Bean객체의 정보를 CachedIntrospectionResults라는 클래스에 저장을 해 두고 있습니다. 그리고 Apache commons의 PropertyUtils에서도 유사하게 PropertyUtilsBean안에 descriptorsCache라는 속성으로 Bean정보를 Cache하고 있습니다. 그래서 실행속도가 거의 비슷하게 나온듯 합니다.

Apache commons BeanUtils.populate는 2,3위 순위의 Property descriptor를 활용한 것들보다 6배 정도 실행시간이 더 걸리는 것으로 나왔습니다.

BeanUtils.populate가 더 느린 이유는 두가지로 분석이 됩니다.

위에서 말한 것처럼 좀 더 확장된 type변환을 지원하기 떄문입니다.
PropertyDescriptor의 배열을 순회하는 방식이 아닌, Map의 keySet을 순회하는 방식을 쓰고 있는데, 아무래도 배열의 순회보다는 성능에는 불리할 것 같습니다.

Iterator names = properties.keySet().iterator();
while (names.hasNext()) {
    // Identify the property name and value(s) to be assigned
    String name = (String) names.next();
    if (name == null) {
        continue;
    }
    Object value = properties.get(name);
    // Perform the assignment for this property
    setProperty(bean, name, value);
}

Opensymphony쪽은 70배이상 더 느린데, 제가 구현한 방식이 문제가 있는 건지도 모르겠습니다.

아뭏든 위의 결과를 봐서는 되도록 성능이 민감한 곳에는 직접 setter를 호출해서 복사를 하고, BeanUtils.populate의 다양한 기능이 필요하지 않다면 Spring의 BeanUtils나 Apache commons PropertyUtils를 통해 캐쉬된 PropertyDescriptor를 정보를 통해 Bean에 접근하는 것이 성능에는 유리하다는 것을 알 수 있습니다.

소스

https://github.com/benelog/beanutils-test

Apache commons BeanUtils의 BeanUtils.populate 활용

public <T extends Map<String,Object>, C> List<C> convertMapToBean(List<T> list,
  Class<C> clazz) {
    List<C> beanList = new ArrayList<C>();

    for (T item : list) {
        C bean = null;
        try {
            bean = clazz.newInstance();
            BeanUtils.populate(bean, item);
        } catch (InstantiationException e) {
            new IllegalArgumentException("Cannot initiate class",e);
        } catch (IllegalAccessException e) {
            new IllegalStateException("Cannot access the property",e);
        } catch (InvocationTargetException e) {
            new IllegalArgumentException(e);
        }
        beanList.add(bean);
    }
    return beanList;
}

Apache commons BeanUtils : PropertyUtils.getPropertyDescriptors활용

public <T extends Map<String, Object>, C> List<C> convertMapToBean(
    List<T> list, Class<C> clazz) {
    List<C> beanList = new ArrayList<C>();

    for (T source : list) {
        C bean = null;

        try {
            bean = clazz.newInstance();

            PropertyDescriptor[] targetPds = PropertyUtils.getPropertyDescriptors(clazz);

            for (PropertyDescriptor desc : targetPds) {
                Object value = source.get(desc.getName());
                if (value != null) {
                    Method writeMethod = desc.getWriteMethod();
                    if (writeMethod != null) {
                        writeMethod.invoke(bean, new Object[] { value });
                    }
                }
            }
        } catch (InstantiationException e) {
            new IllegalArgumentException("Cannot initiate class",e);
        } catch (IllegalAccessException e) {
            new IllegalStateException("Cannot access the property",e);
        } catch (InvocationTargetException e) {
            new IllegalArgumentException(e);
        }
        beanList.add(bean);
    }
    return beanList;
}

OpenSymphony BeanUtils : setValues 활용

public <T extends Map<String, Object>, C> List<C> convertMapToBean(List<T> list, Class<C> targetClass) {
    List<C> beanList = new ArrayList<C>();

    for (Map<String, Object> map : list) {
        C bean = null;
        try {
            bean = targetClass.newInstance();
            BeanUtils.setValues(bean, map, null);
        } catch (InstantiationException e) {
            new IllegalArgumentException("Cannot initiate class", e);
        } catch (IllegalAccessException e) {
            new IllegalStateException("Cannot access the property", e);
        }
        beanList.add(bean);
    }
    return beanList;
}

Spring BeanUtils : getPropertyDescriptors 활용

public <T extends Map<String, Object>, C> List<C> convertMapToBean(
    List<T> list, Class<C> clazz) {
    List<C> beanList = new ArrayList<C>();
    for (Map<String, Object> source : list) {
        C bean = toBean(source, clazz);
    beanList.add(bean);

    }
    return beanList;
}

private <C> C toBean(Map<String, Object> source, Class<C> targetClass) {
    C bean = null;
    try {
        bean = targetClass.newInstance();
        PropertyDescriptor[] targetPds = BeanUtils.getPropertyDescriptors(targetClass);

        for (PropertyDescriptor desc : targetPds) {
            Object value = source.get(desc.getName());
            if (value != null) {
                Method writeMethod = desc.getWriteMethod();
                if (writeMethod != null) {
                    writeMethod.invoke(bean, new Object[] { value });
                }
            }
        }
    } catch (InstantiationException e) {
        new IllegalArgumentException("Cannot initiate class",e);
    } catch (IllegalAccessException e) {
        new IllegalStateException("Cannot access the property",e);
    } catch (InvocationTargetException e) {
        new IllegalArgumentException(e);
    }
    return bean;
}

성능측정 코드

@Test
public void testApacheCommonsBeanUtils() {
    BeanConverter converter = new ApacheCommonsBeanUtilsBeanConverter();
    executeIncrementally(converter);
}

@Test
public void testApacheCommonsPropertyUtils() {
    BeanConverter converter = new ApacheCommonsPropertyUtilsBeanConverter();
    executeIncrementally(converter);
}

@Test
public void testOpenSymphony() {
    BeanConverter converter = new OpenSymphonyBeanConverter();
    executeIncrementally(converter);
}

@Test
public void testSpring() {
    BeanConverter converter = new SpringBeanConverter();
    executeIncrementally(converter);
}

@Test
public void testByHand() {
    BeanConverter converter = new UserConverter();
    executeIncrementally(converter);
}

private void excuecteBeanConverter(BeanConverter converter, int iterations) {
    List<Map<String, Object>> testList = createMapListForTest(iterations);
    long start = System.currentTimeMillis();
    List<User> beanList = converter.convertMapToBean(testList, User.class);
    long end = System.currentTimeMillis();
    System.out.printf("%s,%d times, %d milliseconds \r\n", converter.getClass().getSimpleName(), iterations, (end - start));
}

private void executeIncrementally(BeanConverter converter) {
    for (int i = 0; i <= 100000; i += 10000) {
        excuecteBeanConverter(converter, i);
    }
}

private List<Map<String, Object>> createMapListForTest(int iterations) {
    List<Map<String, Object>> list = new ArrayList<Map<String, Object>>();

    Map<String, Object> user = new HashMap<String, Object>();
    user.put("id", 1);
    user.put("age", 1);
    user.put("name", "내이름");
    user.put("name1", "내이름");
    user.put("name2", "내이름");
    user.put("name3", "내이름");
    user.put("name4", "내이름");
    user.put("name5", "내이름");
    user.put("name6", "내이름");
    user.put("name7", "내이름");
    user.put("name8", "내이름");
    user.put("name9", "내이름");
    user.put("name10", "내이름");
    user.put("income", new BigDecimal("1000100100"));
    user.put("address", "오늘 아침 내가 행복한 이유는 이런거지 오늘아침 내가 서러운 이유는 그런거야 ");
    user.put("introduce", "오늘 아침 내가 행복한 이유는 이런거지 오늘아침 내가 서러운 이유는 그런거야 ");
    user.put("married", true);
    user.put("nickName", "뻐꾸기");

    for (int i = 0; i < iterations; i++) {
        list.add(user);
    }
    return list;
}

Customer tag library에 대한 테스트 코드 작성

Tue, 8 Sep 2009 00:00:00 +0000

JSP의 커스텀 태그 라이브러리는 그 실행결과를 확인하는 것이 많이 번거롭습니다. 따로 테스트 코드를 짜지 않는다면, Web Application 를 띄우고 커스템 태그를 사용하는 JSP를 직접 실행한 다음에 나오는 텍스트값을 확인해서 눈으로 값이 제대로 찍히는지 검증하고, 틀리면 다시 코드를 고치는 방식을 반복하는 경우도 많습니다. 그리고 보통 커스텀태그에서는 setter로 지정된 속성에 따라서 조건분기도 많이 들어가기 때문에 더욱 디버깅이 까다롭습니다. 이 때 위와 같이 JSP를 거치지 않고 바로 출력될 값을 찎어주고, 검증로직을 추가할 수 있는 테스트 코드를 짠다면 개발할 때 많은 시간이 절약될 것입니다.

javax.servlet.jsp.tagext.TagSupport를 상속한 클래스라면, TagSupport.setPageContext 메소드를 활용해서 mock같은 테스트용 객체들을 삽입하면 됩니다. 이 메소드를 통해서 PageContext와 PageContext.getOut으로 돌려주는 javax.servlet.jsp.JspWriter객체를 모두 mock으로 지정할 수도 있습니다.

Spring에서는 이를 더욱 간편하게 할 수 있는 MockPageContext라는 객체를 제공합니다.

이를 활용한 Custom 태그 테스트 코드는 아래와 같이 만들 수 있습니다.

ButtonTag tag = new ButtonTag();
tag.setFunctionName("alert");
tag.setType("basic");

PageContext pageContext = new MockPageContext();
tag.setPageContext(pageContext);

assertEquals(TagSupport.EVAL_BODY_INCLUDE, tag.doStartTag());
assertEquals(TagSupport.EVAL_PAGE, tag.doEndTag());
String output = ((MockHttpServletResponse) pageContext.getResponse()).getContentAsString();
System.out.println(output);
assertTrue(output.contains("<span class='r'>"));
//출력된 결과에 대한 추가  검증

Oracle을 사용해 입출력하는 Map-Reduce

Wed, 25 Mar 2009 00:00:00 +0000

Hadoop의 Map-Reduce처리에서는 DB를 바로 연결해서 처리할 수 있는 DBInputFormat, DBOutputFormat의 클래스가 제공되고 있습니다.

그러나 이 클래스들은 이름이 'DB’가 붙어있는 것이 무색하게 Oracle과 연결해서 사용해보면 에러가 납니다. DBInputFormat에서는 웹에서의 페이지 처리 쿼리처럼 데이터를 잘라서 가지고 오기 위해 원래 쿼리에다 LIMIT와 OFFSET 키워드를 붙이는데, 이 것은 Oracle에서는 지원되지 않습니다. 그리고 DBOutputFormat에서는 insert문의 맨 뒤에 세미콜론(;)을 붙여버리는데, 이것 역시 Oracle의 JDBC를 사용할 때는 에러를 냅니다.

따라서, 결국 이 클래스들을 Oracle에서 쓸 수 있도록 상속해서 구현을 해 줄수 밖에 없었습니다. 얼핏 생각하면 쿼리만 바꾸어주면 되는 것이니 메소드 하나만 오버라이딩 해주면 될 것으로 예상했으나, 원래 클래스들의 구조가 그 정도로 단순하지 않았습니다.Inner클래스가 많아서 여러 클래스와 메서드들을 다 overriding해 줄 수 밖에 없었습니다. 더군다나, 새로 상속한 클래스의 내부에서 꼭 호출해야 하는 DBConfiguration클래스의 생성자가 public이 아닌 package private(아무것도 선언안한 디폴트 접근자)인 탓에, 패키지를 원래의 DBInputFormat, DBOutputFormat와 같은 패키지로 맞추어야 하는 불편함도 있었습니다. protected로 선언된 메소드들이 많은 것보면 분명히 상속해서 덮어쓰라고 만들어놓은 클래스 같은데, 막상 그렇게 활용하기에는 간편하지 않았던 것이죠.

그리고 또 구조적으로 아쉬운 점은 두 클래스가 같은 DBConfiguration을 보게 있어서 Map에서 입력자료를 얻어오는 DB와 Reduce에서 쓰는 DB가 다를 때는 다시 별도의 클래스를 만들어주어야 한다는 것입니다.

Spring Batch에서도 JdbcPagingItemReader라는 약간 유사한 클래스가 있습니다. DBInputFormat이 하나의 쿼리에서 가지고 올 데이터를 동시에 여러번 쿼리해서 나누어 가지고 오는 반면에 JdbcPagingItemReader에서는 부분씩 가지고 오더라도 순차적으로 쿼리를 하는 차이점이 있기는 합니다. 그래도, 페이지 처리 쿼리처럼, 데이터를 나누어서 가지고 오는 쿼리를 제공한다는 점에서는 유사합니다. JdbcPagingItemReader에서는 내부적으로 PagingQueryProvider 라는 인터페이스를 사용하게 되어 있고, 이 인터페이스는 각 DB종류별로 OraclePagingQueryProvider, HsqlPagingQueryProvider, MySqlPagingQueryProvider, SqlServerPagingQueryProvider, SybasePagingQueryProvider 등의 구현클래스를 가지고 있습니다. Hadoop의 DBInputFormat도 이런 구조였다면 이를 응용하려는 개발자가 훨씬 쉽게 클래스 확장방법을 이해했을 것입니다.

아뭏든 지금까지 현재 공개된 API만으로는 Hadoop의 DB연결 지원 클래스들은 빈약해 보이고, API도 좋은 설계요건을 갖추었다고 느껴지지는 않습니다. 아무래도 포털 등에서 대용량 데이터를 처리하는 곳에 쓰이다보니 DB와 함께 연결되는 쓰임새가 그리 많지는 않았나봅니다. 더군다나 Oracle에서는 한번도 안 돌려본 클래스가 버젓이 DB…로 시작되는 이름으로 들어간 것 보면 Oracle이 쓰이는 동네와 Hadoop이 사는 곳은 아주 멀리 떨어져 있었던 것 같습니다. 그러나, 앞으로 엔터프라이즈 환경에서도 Hadoop이 쓰이려면 DB와의 integration은 반드시 거쳐야할 다리인 것 같습니다. Enterprise 시장에서의 mapreduce 링크를 보아도 이미 그런 시도들이 시작된 것을 알 수 있습니다.

한편, Hadoop의 FileInputFormat가 Spring batch의 FlatFileItemReader와 유사한 것 등이나 Spring batch도 2.0에서 아직 분산, 동시처리 등을 지원하기 시작했다는 점은 두 프레임웍의 겹치는 지점이 늘어날 수도 있다는 생각도 듭니다. 뭐 아직 Spring batch의 분산지원은 걸음마 단계이기는 합니다만, DB에서 HDFS에 들어가는 파일을 쓸 때 Spring batch의 API를 활용하는 것 같은 활용법은 시도해 볼만하다고 생각됩니다.

소스

OracleInputFormat

package org.apache.hadoop.mapred.lib.db;

import java.io.IOException;
import java.sql.SQLException;

import org.apache.hadoop.io.LongWritable;
import org.apache.hadoop.mapred.InputSplit;
import org.apache.hadoop.mapred.JobConf;
import org.apache.hadoop.mapred.RecordReader;
import org.apache.hadoop.mapred.Reporter;

public class OracleInputFormat<T extends DBWritable> extends DBInputFormat<T>{

    private DBConfiguration dbConf = null;
    private DBInputSplit split;

    @Override
    public RecordReader<LongWritable,T> getRecordReader(InputSplit split, JobConf job,
            Reporter reporter) throws IOException {
        dbConf = new DBConfiguration(job);
        this.split = (DBInputSplit)split;

        @SuppressWarnings("unchecked")
        Class inputClass = dbConf.getInputClass();
        try {
            @SuppressWarnings("unchecked")
            RecordReader<LongWritable,T> reader = new OracleRecordReader((DBInputSplit) split, inputClass, job);
            return reader;
        } catch (SQLException ex) {
            throw new IOException(ex.getMessage());
        }
    }

    public static void setInput(JobConf job, Class<? extends DBWritable> inputClass,
              String inputQuery, String inputCountQuery) {
        DBInputFormat.setInput(job, inputClass, inputQuery, inputCountQuery);
        job.setInputFormat(OracleInputFormat.class);
     }

    protected class OracleRecordReader extends DBRecordReader{
        protected OracleRecordReader(DBInputSplit split, Class<T> inputClass,
                JobConf conf) throws SQLException {
            super(split, inputClass, conf);
        }

        @Override
        protected String getSelectQuery() {
            long length = 0;
            long start = 0;
            try{
                length = split.getLength();
                start = split.getStart();
            } catch(IOException e){
                throw new IllegalArgumentException
                        ("cannot read length or start variable from DBInputSplit",e);
            }
            StringBuilder query = new StringBuilder();
            query.append(" SELECT * \r\n");
            query.append(" FROM (SELECT m.* , ROWNUM rno ");
            query.append("       FROM ( ");
            query.append(              dbConf.getInputQuery());
            query.append("             )  m");
            query.append("       WHERE ROWNUM <= " + start + " + " + length + ")");
            query.append(" WHERE RNO > " + start);
            System.out.println(query.toString());
            return query.toString();
        }
    }
}

OracleOutputFormat

package org.apache.hadoop.mapred.lib.db;
import org.apache.hadoop.mapred.JobConf;

public class OracleOutputFormat<K  extends DBWritable, V> extends DBOutputFormat<DBWritable, V>{
    @Override
    protected String constructQuery(String table, String[] fieldNames) {
            if(fieldNames == null) {
              throw new IllegalArgumentException("Field names may not be null");
            }
            StringBuilder query = new StringBuilder();
            query.append("INSERT INTO ").append(table);

            if (fieldNames.length > 0 && fieldNames[0] != null) {
              query.append(" (");
              for (int i = 0; i < fieldNames.length; i++) {
                query.append(fieldNames[i]);
                if (i != fieldNames.length - 1) {
                  query.append(",");
                }
              }
              query.append(")");
            }
            query.append(" VALUES (");

            for (int i = 0; i < fieldNames.length; i++) {
              query.append("?");
              if(i != fieldNames.length - 1) {
                query.append(",");
              }
            }
            query.append(")");
            return query.toString();
          }
    public static void setOutput(JobConf job, String tableName, String... fieldNames) {
        DBOutputFormat.setOutput(job, tableName, fieldNames);
        job.setOutputFormat(OracleOutputFormat.class);
    }
}

Job 구성 예

public class SampleJob {

    public static void main(String args[]) throws IOException, URISyntaxException{
        JobConf conf = new JobConf(SampleJob.class);
        initClasspath(conf);
        conf.setJobName("sampleJob");
        DBConfiguration.configureDB(conf, "oracle.jdbc.driver.OracleDriver",
                "jdbc:oracle:thin:@localhost:1525:TEST",
                "myuser", "mypassword");
        OracleInputFormat.setInput(conf, Query.class,
                "SELECT query, category, user_id FROM query_log ",
                "SELECT COUNT(*) FROM query_log");
        conf.setOutputKeyClass(Query.class);
        conf.setOutputValueClass(IntWritable.class);
        conf.setMapperClass(SampleMapper.class);
        conf.setReducerClass(SampleReducer.class);
        conf.setCombinerClass(SampleReducer.class);
        OracleOutputFormat.setOutput(conf, "category", "user_id","cnt");

        JobClient.runJob(conf);
    }

    private static void initClasspath(JobConf conf) throws URISyntaxException,
            IOException {
        DistributedCache.addCacheFile(new URI("lib/ojdbc5-11.1.0.6.jar"), conf);
        DistributedCache.addFileToClassPath(new Path("lib/ojdbc5-11.1.0.6.jar"), conf);
    }
}

hadoop의 DBInputFormat 참고자료

Java의 auto boxing과 unbox은 어떻게 컴파일될까?

Tue, 10 Feb 2009 00:00:00 +0000

아래 코드는 [프리미티브 타입과 Wrapper 클래스, 자동 Boxing, 자동 UnBoxing]이라는 글에 나오는 것을 입력해 본 것입니다. int와 java.lang.Integer객체를 "=="와 "equals()"메소드로 비교하고 있습니다.

위의 코드에서 생성한 .class파일을 역컴파일해보면 아래와 같은 코드가 나옵니다. autoboxing과 unboxing이 어떤 방식으로 이루어 지는지 잘 확인할 수 있습니다. java.lang.Integer가 int로 바뀔 때는 intValue() 메소드, int가 java.lang.Integer로 바뀔 때는 Integer.valueOf()메소드를 사용하고 있습니다. JDK 1.4이하 버전과의 하위호환성을 위해서 이런 방식을 쓰는 것이겠죠.

int a = 1;
int b = 1;
Integer c = new Integer(1);
Integer d = new Integer(1);
System.out.println((new StringBuilder("1:")).append(System.identityHashCode(Integer.valueOf(a))).toString());
System.out.println((new StringBuilder("2:")).append(System.identityHashCode(Integer.valueOf(b))).toString());
System.out.println((new StringBuilder("3:")).append(System.identityHashCode(c)).toString());
System.out.println((new StringBuilder("4:")).append(System.identityHashCode(d)).toString());
System.out.println((new StringBuilder("5:")).append(a == b).toString());
System.out.println((new StringBuilder("7:")).append(c == d).toString());
System.out.println((new StringBuilder("8:")).append(c.equals(d)).toString());
System.out.println((new StringBuilder("9:")).append(a == c.intValue()).toString());

new Integer() 로 생성자를 호출하면 매로 새로 객체를 생성하는데, Integer.valueOf()메소드를 사용하면 캐쉬된 값을 사용할 수 있습니다. 이 메소드의 소스를 보면 -128부터 127까지의 static영역에 캐쉬로 쌓아두고 있습니다.

 static {
  cache = new Integer[256];
  for (int i = 0; i < cache.length; i++)
  cache[i] = new Integer(i - 128);
}

public static Integer valueOf(int i) {
  if (i >= -128 && i <= 127)
  return IntegerCache.cache[i + 128];
  else
  return new Integer(i);
}

처음에 나왔던 저의 Eclipse 캡쳐화면을 보면 findbugs 플러그인에서 new Integer()사용 코드에 대한 경고를 보여주고 있습니다. 자세한 설명을 보니, Integer.valueOf() 를 사용할 경우 약 3.5배 정도 실행속도가 빠르다고 하네요.

M P Bx] Method invokes inefficient Number constructor; use static valueOf instead [DM_NUMBER_CTOR]

Using new Integer(int) is guaranteed to always result in a new object whereas Integer.valueOf(int) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.

Values between -128 and 127 are guaranteed to have corresponding cached instances and using valueOf is approximately 3.5 times faster than using constructor. For values outside the constant range the performance of both styles is the same.

Unless the class must be compatible with JVMs predating Java 1.5, use either autoboxing or the valueOf() method when creating instances of Long, Integer, Short, Character, and Byte.

이런 원리들을 잘 염두해 둬서, auto boxing과 unboxing이 사용될 때 필요없는 객체가 생성되지 않는지 유의해야 합니다.

다음 코드는 Effective Java 2nd Edition의 Item 5 - '불필요한 객체를 생성하지 마라’에 나오는 예제입니다.

Long sum = 0L;
for(long i=0;i< Integer.MAX_VALUE;i++){
   sum += i;
}
System.out.println(sum);

이 코드를 컴파일한 후 다시 역컴파일 해보면 다음과 같이 나옵니다.

Long sum = Long.valueOf(0L);
for(long i = 0L; i < 0x7fffffffL; i++)  sum = Long.valueOf(sum.longValue() + i);

System.out.println(sum);

java.lang.Double.valueOf(double) 메서드는 매번 새로운 객체를 생성하게 되어 있습니다.

public static Double valueOf(double d) {
  return new Double(d);
}

이렇듯 불필요한 객체생성을 막기 위해 되도록 primitive type을 선호해야 합니다. auto boxing은 Collection이나 Map에 들어가는 요소로 변수가 쓰일 때, generics가 적용한 코드를 작성할 때 등이 적절한 사용의 예입니다. (Effective Java 2nd Edition, Item 49 참조)

Spring MVC 2.5을 활용한 파일업로드

Sun, 8 Feb 2009 00:00:00 +0000

간단한 파일 업로드 기능을 만들어야 할 일이 생겨서, Spring 2.5의 annotation을 이용한 Action에서 이를 처리하게 했습니다. 실무에서 썼던 것을 더 단순한 예제로 재구성해서 정리해봅니다.

Maven의 pom.xml에 파일업로드 기능에서 참조하는 commons-fileupload 라이브러리에 대한 dependency를 추가합니다.

<dependency>
   <groupId>commons-fileupload</groupId>
   <artifactId>commons-fileupload</artifactId>
   <version>1.2.1</version>

</dependency>

web.xml에는 applicationContext 파일의 위치를 지정하고, *.do를 스프링에서 처리하도록 설정합니다.

<servlet>
   <servlet-name>dispatcher</servlet-name>
   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
   <init-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>classpath:applicationContext.xml</param-value>
   </init-param>
   </servlet>
   <servlet-mapping>
     <servlet-name>dispatcher</servlet-name>
     <url-pattern>*.do</url-pattern>
   </servlet-mapping>

업로드 기능을 간단히 테스트할 수 있는 jsp페이지를 만들어봅니다. 단순히 파일 1개를 "file"이라는 변수명으로 업로드 요청을 하는 페이지입니다.

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form"%>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>업로드 테스트</title>
</head>
<body>
<form action="/study/upload.do" method="post" enctype="multipart/form-data">
<p>
    <label for="file">파일1 </label>
    <input type="file" name="file">
</p>
<p>
    <input type="submit" value="전송"/>
</p>
</form>
</body>
</html>

그리고 applicationContext파일을 아래와 같이 선언합니다. DefaultAnnotationHandlerMapping 을 이용해서 annotation을 이용한 Controller 설정을가능하게 합니다. <context:component-scan/> 태그를 사용해서, 설정을 scan할 패키지를지정합니다. 그리고, 파일이 저장될 디렉토리는 ${repository.path} 속성으로 표시했습니다. Maven의 resource filter기능을 이용해서 실행환경에 따라 다른 값을 넣게 하면 편리합니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    <bean  class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
        <property name="alwaysUseFullPath" value="true"/>
    </bean>
    <bean id="multipartResolver"
        class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/>

    <bean id="respository" class="study.repository.FileRepository">
        <constructor-arg value="${repository.path}" />
    </bean>
    <context:component-scan    base-package="study.action"/>
</beans>

실제적인 파일의 저장기능을 담당하는 클래스인 FileRepository에서는 간단하게 UUID를 이용해서 키를 생성하고 path필드로 지정된 디렉토리에 저장을 해줍니다.

package study.repository;

import java.io.File;
import java.io.IOException;
import java.util.UUID;

import org.springframework.web.multipart.MultipartFile;

public class FileRepository {
    private String path;
    public FileRepository(String path) {
        this.path = path;
        File saveFolder = new File(path);
        if(!saveFolder.exists() || saveFolder.isFile()){
            saveFolder.mkdirs();
        }
    }

    public String saveFile(MultipartFile sourcefile) throws IOException{
        if ((sourcefile==null)||(sourcefile.isEmpty())) return null;
        String key = UUID.randomUUID().toString();
        String targetFilePath = path+"/"+ key;
        sourcefile.transferTo(new File(targetFilePath));
        return key;
    }
}

추가적으로 키값을 넣어주면 파일을 반환해주는 메소드나, 파일의 종류나 날짜에 따라서 하위 디렉토리를 구분해서 생성하는 기능도 넣을 수있을 것입니다. 그리고 더 확장한다면, 따로 주요 메서드를 선언한 Repository 라는 인터페이스를 정의하고, DB를저장소로 활용하는 DbRepository 와 같이 이름 붙인 구현 클래스도 만들어 볼 수 있겠습니다.

그리고 @Controller , @RequestMapping, @RequestParam, @Autowired의 Anntation을활용해서 Controller 클래스를 작성합니다. 업로드 후 화면에 키값만 뿌도록 해서 java.io.Writer클래스를 화면출력을 위해 사용했습니다.

package study.action;

import java.io.IOException;
import java.io.Writer;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.multipart.MultipartFile;

import study.repository.FileRepository;

@Controller
public class FileAction {
     private FileRepository respository;

    @Autowired
    public void setRespository(FileRepository respository) {
        this.respository = respository;
    }
    @RequestMapping("/upload.do")
    public void execute(@RequestParam("file") MultipartFile file,
            Writer out) throws IOException{
        String key = respository.saveFile(file);
        out.write(key);
    }
}

MultipartFile 클래스를 파라미터로 받는 메서드는 MockMultiPartFile를 이용해서 테스트하면 됩니다.

참고로 최근 로드존슨이 인터뷰에서 한 말에 따르면 기존 Spring MVC의 Controller interface는 삭제될 것이라고 하네요.

Spring MVC 2.5 관련 자료

EMMA + Eclipse + Maven2 + Hudson

Fri, 23 Jan 2009 00:00:00 +0000

EMMA는 테스트코드가 검증해 주는 코드영역에 대해서 보고해 주는 도구입니다. 전체 코드 중 몇 %가 테스트 코드를 거쳐가고 있는지 쉽게 수치를 낼 수 있습니다.

EMMA의 Eclipse plugin인 EclEmma는 http://update.eclemma.org/를 plugin의 update site로 지정하면 설치할 수 있습니다. 설치 후 프로젝트에서 우클릭-Coverage As - JUnit Test 메뉴를 선택하면 전체 Junit Test를 실행하고, Test Coverage에 대한 보고서를 생성해 줍니다.

EMMA의 Maven2 plugin인 Emma Maven Plugin Maven을 pom.xml파일의 reporting 선언에 아래와 같은 설정을 추가합니다.

<reporting>
  <plugins>
   ...
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>emma-maven-plugin</artifactId>
      </plugin>
    </plugins>
</reporting>

Hudson의 위키에 있는 Emma plugin 설명페이지나 Maven의 emma-plugin 설명페이지를 보면 build절에도 plugin 설정을 추가하라고 되어있는데, 그렇게 하지 않아도 잘 실행이 되었습니다. 오히려 그렇게 추가를 하니, mvn test site처럼 test와 site phrase가 같이 돌아갈 때 아래와 같은 에러가 발생했습니다.

java.lang.IllegalStateException: class [......] appears to be instrumented already

Emma plugin 설정을 reporting 부분에 넣으면 테스트가 실행되므로 일부러 test phrase를 넣어줄 필요는 없습니다. 즉 이 때는 mvn site만 돌려주시면 테스트 결과와 Coverage Report를 모두 얻을 수 있습니다. Emma plugin이 있을 때 'mvn test site’로 실행시켜서 테스트가 두번 돌면 Hudson에서 보고하는 테스트 개수도 2번씩 중복 집계가 되므로 더 혼동만 줍니다.

Maven의 emma-plugin 설명페이지에 따르면, maven-surefire-plugin 설정에서 별도의 JVM으로 테스트를 실행시키위해 forkMode를 always로 설정하는 것은 중요하다고 합니다. EMMA가 JVM의 종료 때도 기록을 하기 때문에 그렇다는군요. 다음과 같이 설정합니다.

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <inherited>true</inherited>
        <configuration>
          <forkMode>always</forkMode>
          <reportFormat>xml</reportFormat>
        </configuration>
</plugin>

이렇게 Maven을 통해 생성한 리포트를 Huson으로 보기 위해서는 Manage Hudson>Manage Plugins 메뉴에서 Hudson Emma plugin을 설치하고 Hudson을 재시작합니다.

설치가 잘 되었다면, 프로젝트의 Configure 메뉴에서 EMMA의 보고서에 대해서 설정할 수 있는 항목이 생깁니다.

여기에서 Emma XML report 항목에 workspace를 기준으로 한 상대적인 경로로 coverage.xml의 위치를 지정해줍니다. Hudson의 위키에 있는 Emma plugin 설명페이지에 보면 이 항목이 target/site/emma/coverage.xml으로 되어 있어서 혼동이 오기 쉬운데, trunk와 같은 Local module directory를 반드시 포함시켜줘야 합니다. 보통 SVN을 쓸 때 프로젝트 설정에서 별도로 지정을 하지 않으면 trunk같은 SVN의 path의 마지막 디렉토리가 Local module directory로 지정됩니다.

Emma 보고서 설정란에서 the work space root라는 링크를 눌러도 금방 확인 할 수 있습니다.

위와 같이 설정된 프로젝트를 build하면 빌드의 맨 끝에 Recording Emma reports trunk/target/site/emma/coverage.xml 와 같은 메시지가 Console out 화면에서 뜰 것입니다. 그렇게 생성된 보고서는 "프로젝트명>빌드번호>Coverage Report" 메뉴에서 보실 수 있습니다.

만약 Hudson에서 Emma를 실행한 빌드번호의 메뉴에서 'Coverage Report’라는 메뉴가 보이지 않는다면 Hudson plugin 수동으로 빌드&업로드를 참조해서 최신 버전으로 플러그인을 업데이트 해보시기 바랍니다.

JDepend + Eclipse + Maven2

Mon, 19 Jan 2009 00:00:00 +0000

JDepend는 Java패키지간의 의존성에 대한 수치들을 알려 주는 도구입니다.

JDepend의 Eclipse의 Plugin은 http://andrei.gmxhome.de/eclipse/를 Update site에 추가하면 설치할 수 있습니다. 다음의 링크들에서 보다 자세한 내용을 참조할 수 있습니다. 분석을 하고자 하는 소스폴더 위에서 우클릭을 한 후 'Run JDepend Analysis' 메뉴를 선택하면 의존성 분석 결과가 나옵니다.

이를 Maven을 통해서 생성하는 jdepend-maven-plugin 은 pom.xml에 아래와 같이 추가할 수 있습니다.

<reporting>

.....

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>jdepend-maven-plugin</artifactId>
  <version>2.0-beta-2</version>
</plugin>

</reporting>

mvn jdepend:generate 또는 mvn site 명령을 통해서 보고서가 생성됩니다. mvn site로 실행했다면 Hudson의 프로젝트 홈에서 Maven Generated Site 메뉴를 통해서도 확인할 수 있습니다. 샘플페이지 에 생성된 보고서의 형식이 나와있습니다.

JDepend 첫페이지나 생성된 보고서 안에서도 위의 요약 테이블에 수치들에 대한 설명이 잘 나와있습니다. 간단히 요약해서 정리하면,

TC (Total Classes) : 전체 클래스 수. CC + AC
CC (Concrete Classes) : Inteface나 추상클래스가 아닌 구상 클래스 수
AC (Abstract Classes) : Interface나 Abstract Class로 선언된 클래스 수
Ca (Afferent Couplings) : 이 패키지를 의존하고 있는 다른 패키지의 수. 이 패키지의 책임감을 나타내는 지표
Ce (Efferent Couplings) : 이 패키지가 의존하고 있는 클래스가 있는 다른 패키지의 수. 이 패키지의 독립성을 나타내는 지표.
A (Abstractness) : 총 클래스 갯수 중 인터페이스나 추상클래스의 비율. 1이라면 해당 패키지는 추상클래스나 인터페이스 밖에 없는 것.
I (Instability) : 총 결합도 중 이 패키지의 외부의존성의 비율 (Ce / (Ce + Ca)). 변화에 대한 내성을 나타내는 지표. I=0이라면 완전하게 안정적인 것.
D (Distance from Main Sequence) : 이상적인 균형의 상태인 A + I = 1 의 함수에서 수직으로 떨어진 거리. (아래 그래프 참조)

이미지 출저 : Managing Your Dependencies with JDepend

가장 중요한 것은 패키지 간의 순환참조를 보여주는 Cycles 부분입니다.

순환참조 관계의 패키지들은 부분적으로 배포될 수도 없고, 한 패키지를 변경할 때 그 영향력을 파악하기도 힘들게 만듭니다. 순환 참조에 대한 자세한 내용은 아래의 링크를 참조하시기 바랍니다.

JavaNCSS + Maven2 + Hudson

Fri, 16 Jan 2009 00:00:00 +0000

JavaNCSS를 Maven2을 통해 실행하고, Hudson을 통해 리포트를 확인하는 과정을 정리했습니다. JavaNCSS는 주석이 아닌 라인수(Non Commenting Source Statements,NCSS)와 순환복잡도 수 (Cyclomatic Comlexity Number, CCN) 등을 측정해 주는 도구입니다.

JavanNCSS에 관한 eclipse 플러그인도 찾을 수는 있었지만(http://sourceforge.net/projects/jncss4eclipse/ ) 가장 최신버전이 2002년에 올라온 것이라서 적용하지 않기로 했습니다.

그리고, JavaNCSS에 대한 Maven의 플러그인도 javancss-maven-plugin과 maven-javancss-plugin의 2가지가 존재했는데, javancss-maven-plugin 쪽이 보다 문서화가 잘 되어 있어서 그 쪽을 선택했습니다.

pom.xml 에 아래 선언을 추가합니다.

<reporting>

...

   <plugin>

     <groupId>org.codehaus.mojo</groupId>
     <artifactId>javancss-maven-plugin</artifactId>
     <version>2.0-beta-2</version>
      <configuration>
      <forceEncoding>utf-8</forceEncoding>
       </configuration>
    </plugin>
  </plugins>
</reporting>

그리고는 mvn javancss:report javancss:check 로 플러그인을 실행시켜 봅니다. 각각의 골에 대한 설명은 아래 페이지에서 보시면 됩니다.

javancss:report : 리포트 생성
javancss:check : CCN이나 NCSS 값이 너무 크면 빌드를 실패시킴

제외하거나 추가할 파일을 지정하려면 아래의 configuration 태그 아래에 includes, excludes 태그로 지정하면 됩니다.

<configuration>

.....
  <includes>
    <include>**/*foo.java</include>
  </includes>
  <excludes>
    <exclude>**/bar.java</exclude>
  <exclude>**/foobar.java</exclude>
  </excludes>
</configuration>

CCN이나 NCSS값의 한계 허용치는 아래와 같이 지정합니다.

<configuration>
....
  <failOnViolation>true</failOnViolation>
  <ccnLimit>12</ccnLimit>
  <ncssLimit>90</ncssLimit>
</configuration>

한가지 주의할 점은, 2.0-beta-2 버전을 실행할 경우, 메서드 내부에 annotation선언이 있다면 아래와 같은 에러메시지를 받게 됩니다.

Encountered "@ SuppressWarnings ( \"unused\" ) int notUsedVariable =" at line xxx, column yyy.

이 것은 javancss-maven-plugin 버전 2.0-beta-2가 이 의존하고 있는 JavaNCSS 버전 29.49 에서 가지고 있는 버그입니다. (http://jira.codehaus.org/browse/MJNCSS-16 참조) JavaNCSS 버전 29.50에서는 해결된 문제이고, 이 플러그인의 최신 버전인 javancss-maven-plugin 2.0-beta-3버전에서는 이런 문제가 발생하지 않는다고 합니다. 그런데, codehause의 Maven Repository를 뒤져보니 (http://repository.codehaus.org/org/codehaus/mojo/javancss-maven-plugin/) 아직 2.0-beta-3버전은 올라와 있지 않습니다. snapshop 버전을 찾아서 쓸 수도 있겠지만, 그것보다는plugin 설정에서 dependency설정을 덮어쓰는 편이 더 간편하게 느껴졌습니다. pom.xml 의 build절에 아래와같이 추가하면 됩니다.

<build>

   <plugin>
     <groupId>org.codehaus.mojo</groupId>
        <artifactId>javancss-maven-plugin</artifactId>
        <version>2.0-beta-2</version>
        <dependencies>
          <dependency>
            <groupId>javancss</groupId>
              <artifactId>javancss</artifactId>
              <version>29.50</version>
             </dependency>
         </dependencies>
     </plugin>
     </plugins>
  </build>

생성된 리포트를 보기 위해서, Hudson에서는 프로젝트에서 Configure 설정에서 Publish Java NCSS report를 선택을 합니다.

그리고는 javancss:report Goal이 포함된 빌드를 실행시켰다면 프로젝트 홈 화면에서 Java NCSS Report라는 링크가 생기게 됩니다.

클릭을 하면 생성된 리포트를 볼 수가 있죠. (패키지명은 제가 지웠습니다.)

Maven에서 mvn site명령으로 site 절(phrase)까지 들어갔다면 리포트를 모은 페이지를 따로 생성해 주기도합니다. Hudson의 프로젝트 메인화면에서 Maven-generated site 링크를 통해서 보실 수 있습니다.Hudson에서 생성해주는 페이지가 더 이쁘기는하지만, JavaNCSS의 보고서는 Maven-generated site가 더많은 정보를 제공합니다. 예를 들면 가장 주석을 제외한 라인수(NCSS)가 많은 30위까지의 클래스들, 메소드들 같은 순위등같은 것들을 확인할 수 있습니다.

PMD + Eclipse + Maven2 + Hudson

Fri, 19 Dec 2008 00:00:00 +0000

코드 검사도구인 PMD 를 Eclipse plugin을 설정하고, Maven을 통해서도 같은 규칙으로 코드를 검사한 보고서를 생성하고, Hudson을 통해서 확인하는 과정을 정리해 봤습니다.

Eclipse에서는 update site를 http://pmd.sf.net/eclipse 로 지정해서 플러그인을 설치합니다.

Eclipse 메뉴의 Window- Preferences를 가면 Rule설정 파일을 export, import할 수 있는 기능이 있습니다.

Project의 Properties에도 PMD관련 설정이 있습니다. 외부에서 만든 Rule파일을 바로 참조해도 되고, 여기서 설정된 것을파일로 생성할 수도 있습니다. 이미 있는 프로젝트에서 Rule를 설정할 때는 Project의 Properties에서 Rule들을고른 후에 생기는 warning이나 error를 보고 warning이 안 뜨게 소스를 고치거나 Rule을 제외한 후, 최종결정Rule들로 Ruleset 정의 파일을 생성하는 것이 편리할 것입니다. 저는 처음에 모든 Rule을 다 선택한 다음에warning들을 없애가면서 Rule들을 하나하나 검토해 나갔었습니다.

위의 화면에서 Enable PMD를 선택하면 .project파일에 아래와 같은 부분이 추가될 것입니다.

<natures>
      ....
   <nature>net.sourceforge.pmd.eclipse.plugin.pmdNature</nature>
</natures>

이제 해당 프로젝트는 Eclipse의 Problems View에서 PMD에서 보고하는 error, warning까지 모두 다 뜨게됩니다. 개발을 하면서 Rule 준수에 대한 빠른 피드백을 얻기 위해 되도록 이 기능을 사용하는 것이 좋습니다. 대신 이미Project에 warning이 많으면 새로운 warning들이 잘 눈에 띄지 않게 되므로, Project를 warning없이깨끗이 정리한 다음에 사용할 것을 권장해 드립니다.

모든 Rule을 다 적용하면 아마 굉장히 많은 warning과 때로는 에러까지도 나올 것입니다. 그런 것들을 다 검토해서 포함시킬지를 결정해야 합니다. http://pmd.sourceforge.net/rule-guidelines.html를 참조하셔서, 프로젝트 상황에 맞게 적용해야겠죠. 그중 몇가지 Rule에 대해서만 언급을 하고 넘어가겠습니다.

Basic Rules-EmptryInitializer: PMD 5.0에서 추가된 룰로 Maven의 PMD plugin버전 2.4에서는 PMD 버전 4.2.2를 참조하기 때문에 이Rule은 지원되지 않습니다. 따라서 PMD의 Eclipse plugin에서 이를 지원한다고 할지라도 Maven plugin과같이 쓰기 위해서는 이 Rule을 반드시 제외해야 합니다.
Optimization Rules-LocalVariableCouldBeFinal과 Controversial Rules-AvoidFinalLocalVariable : 서로 상반되는 Rule로 한쪽 Rule을피하면 다른 쪽에 걸려드는 Rule입니다. 그래서 warning을 안보려면 둘 중에 하나는 꼭 제외해야 합니다. 그런데,final을 Local variable에 일일히 선언하는 것도 번거로운 일이고, 메소드 내의 inner class에서 참조해야되어서 꼭 final이 되어야하는 local variable도 있으므로, 둘 다 제외하는 것도 좋습니다
Controversial Rules-OnlyOneReturnRule : 메서드에서 return문이 여러 개일 경우 경고를 주는데, 메서드 중간의 return문은 복잡한 조건문의 구조를 단순하게 하는데 도움이 경우가 많고, 켄트벡의 구현패턴 7장 중 '보호절’을 보면 이를 권장하고 있습니다.
Design Rules-UnnecessaryLocalBeforeReturn: return 전에 따로 local 변수로 반환할 값을 선언할 때 주는 경고인데, 기능적으로는 별 의미 없는 코드이나,return 문장에는 @SupressWarning 의 Annotation을 추가할 수 없기 때문에, Annotation 적용범위를 최소화하기 위해 그런 선언이 필요한 때도 있습니다. (Java Language Spec 9.7, EffectiveJava 2nd Edition Item 24 참조)

검토해보니 가장 부담없이 적용가능한 RuleSet이 괄호에 대한 규칙을 정의하는 Braces Rules이고, Controversial Rules가 이름 그대로 가장 제외할 것이 많은 Rule Set입니다.

이런 과정을 거쳐서 선별된 Rule 정의 파일이 만들어지면 그것을 Maven의 PMD plugin에서도 참조할 수 있게 설정합니다. 저는 Rule설정 파일이름을 .ruleset으로 하고 pom.xml에 추가했습니다.

  <reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-pmd-plugin</artifactId>
        <version>2.4</version>
        <configuration>
          <rulesets>
            <ruleset>$\{basedir}/.ruleset</ruleset>
          </rulesets>
          <sourceEncoding>utf-8</sourceEncoding>
          <targetJdk>1.6</targetJdk>
          <minimumTokens>10</minimumTokens>
        </configuration>
      </plugin>
  </reporting>

그리고는 mvn site 혹은 mvn pmd:pmd pmd:cpd 처럼 PMD plugin의 goal을 포함시킨 빌드를 한번 실행시켜 봅니다.

문제가 없이 돌아갔으면 hudson에도 PMD플러그인을 설정합니다.. PMD 플러그인의 goal이 포함된 빌드를 돌리고 나면PMD warning라는 링크가 해당 프로젝트에 생기고, 거기서 아래와 같은 보고서를 확인할 수 있습니다.

Effective & Agile Java Generics

Tue, 16 Dec 2008 00:00:00 +0000

수정이력

2019.04.13
- 유효하지 않은 JavaDoc 문서 링크 최신화
- 예제에서 Diamond 문법 활용
- JUnit4에 대한 일반적인 설명 링크 제거
- `ServletRequest.getParameterMap()`에 대한 최신 JavaDoc 내용 추가
- `List<ScheduledFuture<?>>`가 쓰인 예시를 Spring Integration의 소스에서 LogBack의 것으로 변경

Generics가 들어간 테스트 코드를 통과시켜 봅시다.

아래에 있는 테스트 1~5까지의 테스트 코드들을 모두 한번에 통과시키는 ListUtils.max메서드는 어떻게 선언하고 구현해야 할까요?

Generics를 써보신 분이라면 ListUtilsTest.java를 다운 받으셔서 한번 풀어 보시기 바랍니다. Collections.max()를 아시는 분도 그 메소드를 참고하시지 마시고 직접 메서드를 만들어 보시면 재미있으실 겁니다.

제약조건은 다음과 같습니다.

@SuppressWarnings("unchecked") 를 쓰지 않고도 Generics에 대한 warning이 없고, Casting도 한번도 하지 않아야 하고
컴파일 시점에서 ListUtils.max 메소드에 Comparable 인터페이스를 구현한 객체들을 쌓은 List가 넘어온다는 것을 검증할 수 있어야 한다.

테스트 1 : 빈 리스트가 넘어오면 null값 반환

    @Test
    public void getNullIfEmptyList(){
        List<Integer> numbers = new ArrayList<>();
        Integer max = ListUtils.max(numbers);
        assertThat(max,is(nullValue()));
    }

테스트 2 : Integer객체의 최대값 구하기

    @Test
    public void getMaxInteger(){
        List<Integer> numbers = new ArrayList<>();
        numbers.add(Integer.valueOf(1))
        numbers.add(Integer.valueOf(2));
        Integer max = ListUtils.max(numbers);
        assertThat(max,is(Integer.valueOf(2)));
    }

테스트 3 : BigInteger객체의 최대값 구하기

    @Test
    public void getMaxBigInteger(){
        List<BigInteger> numbers = new ArrayList<>();
        numbers.add(BigInteger.ZERO);
        numbers.add(BigInteger.ONE);
	BigInteger max = ListUtils.max(numbers);
        assertThat(max,is(BigInteger.ONE));
    }

테스트 4: java.sql.Date 객체의 최대값 구하기

    @Test
    public void getMaxDate(){
        java.sql.Date now = new java.sql.Date(new Date().getTime());
        java.sql.Date afterAWhile = new java.sql.Date(new Date().getTime()+6000);
        List<java.sql.Date> dates = new ArrayList<java.sql.Date>();
        dates.add(now);
        dates.add(afterAWhile);
        java.sql.Date max = ListUtils.max(dates);
        assertThat(max,is(afterAWhile));
    }

테스트5 : ScheduledFuture를 구현한 객체의 최대값 구하기

    @Test
    public void getMaxScheduledFuture() throws InterruptedException{
        ScheduledExecutorService executor = Executors.newScheduledThreadPool(2);
        ScheduledFuture<?> after1Second = executor.schedule(getTask("first"),1,TimeUnit.SECONDS);
        ScheduledFuture<?> after2Seconds = executor.schedule(getTask("second"),2,TimeUnit.SECONDS);
        List<ScheduledFuture<?>> futures = new ArrayList<ScheduledFuture<?>>();
        futures.add(after1Second);
        futures.add(after2Seconds);
        ScheduledFuture<?> max = ListUtils.max(futures);
        long maxDelay = max.getDelay(TimeUnit.SECONDS);
        assertThat(maxDelay,is(after2Seconds.getDelay(TimeUnit.SECONDS)));
        Thread.sleep(3000);
        assertTrue(max.isDone());
    }
    private Runnable getTask(final String message) {
        Runnable task = new Runnable(){
            public void run() {
                System.out.println(message);
            }
        };
        return task;
    }

(https://docs.oracle.com/javase/8/docs/api/index.html?java/util/concurrent/ScheduledFuture.html] API문서 참조)

풀이와 설명

테스트 1,2,3번 까지의 코드만이라면 아래와 같이 선언하셔도 됩니다.

리스트 1: 간단한 max 메서드 선언

public static <T extends Comparable<T>> T max(List<T> list)

이렇게 <T extends Comparable<T>> 처럼 Type parameter가 그 자신이 포함된 표현으로 그 범위가 선언되는 것을 recursive type bound라고 합니다.

Integer와 BigDecimal의 클래스 선언을 보면 아래와 같습니다.

리스트 2: Integer 와 BigInteger 클래스 선언부

public final class Integer extends Number implements Comparable<Integer>

public class BigInteger extends Number implements Comparable<BigInteger>

두 클래스 모두 자신의 타입이 Parameterized type으로 들어간 Comparable 인터페이스를 구현하고 있기 때문에 리스트3의 메소드 선언으로도 Integer나 BigInteger가 담긴 리스트를 받을 수 있습니다.

그러나 리스트 1의 선언으로는 테스트4,5에 있는 메서드에서 컴파일 에러가 날 것입니다. 그 이유는 다음과 같습니다.

테스트4의 java.sql.Date는 java.util.Date를 상속한 클래스입니다. 그런데 java.sql.Date 는 따로 comparesTo 메서드를 재정의하고 있지 않고, 상위클래스인 java.util.Date 에 있는 메서드를 그대로 쓰고 있습니다. java.sql.Date 는 Comparable<java.sql.Date> 한 것이 아닌 Comparable<java.util.Date> 를 구현한 것이라고 볼 수 있습니다. (두 클래스의 이름이 같아서 혼동이 되실 수도 있습니다. Java Puzzler에서는 이 두 클래스의 예를 들면서 자바 플랫폼 설계자가 이름을 지으면서 깜빡 존 듯하다고 언급하고 있습니다.)

그리고 테스트5의 java.util.concurrent.ScheduledFuture 인터페이스는 Comparable<ScheduledFuture> 를 구현한 것이 아닌, Delayed라는 인터페이스를 상속한 것이고, 이 Delayed는 Comparable<Delayed> 를 상속한 인터페이스입니다. 리스트 3의 인터페이스 선언을 보시면 쉽게 이해가 되실 것입니다.

리스트 3: Delayed 인터페이스 선언부

public interface ScheduledFuture<V> extends Delayed, Future<V>

public interface Delayed extends Comparable<Delayed>

이런 경우도 모두 통과할 수 있게 ListUtils.max() 메서드를 선언하고 구현하면 아래와 같습니다.

리스트4: ListUtils 구현

public class ListUtils {
    public static <T extends Comparable<? super T>> T max(List<T> list){
        T result = null;
        for(T each : list) {
            if (result==null) result = each;
            if(each.compareTo(result)>0) result = each;
        }
        return result;
    }
}

public static <T extends Comparable<? super T>> T max(List<T> list) 라는 긴 메서드 선언입니다. 이 선언 안에는 recursive type bound, wild card, upper bound, lower bound가 다 들어가 있습니다. 이 정도 메서드를 설계할 수 있어야지, Java generics를 제대로 아는 것이라고 할 수 있겠습니다.

bounded wild card를 적용하는 기준은 Effective Java 2nd Edition에 나와 있는 PECS(Producer-extends, Consumer-super)원칙을 기억하시면 도움이 됩니다. 원래 PECS의 뜻은 가슴 근육이라는군요.

`<T extends Comparable….`

Comparable인터페이스를 구현한 클래스가 그 대상이어야 max내부에서 Comparable.compareTo를 이용해서 최대값을 구할 수 있습니다. 그래서 타입 T는 T extends Comparable이 되어야 합니다. PECS원칙으로도 리턴값으로 생산되는 (Producer) 타입이 T이므로 extends를 쉽게 연상하실 수 있습니다.

`Comparable<? super T> 부분`

max 메서드 내부에서 타입 T는 Comparable.compareTo(T o)메서드 뒤에 파라미터로 넘어가는, 소비되는(Consumer) 대상으로 쓰이기에 PECS원칙으로 super로 연결시킬 수 있습니다. 테스트5의 코드를 예로 보면, ScheduledFuture는 ScheduledFuture의 상위 인터페이스인 Delayed가 Comparable의 Parameterized type으로 넘어가는 Comparable<Delayed>형태의 Comparable인터페이스를 상속하고 있습니다. T를 ScheduledFuture로 봤을 때 Comparable<? super T>는 Comparable<Delayed>와 잘 맞아떨어집니다.

이 리스트4의 ListUtils.max 메서드는 Effective Java 2nd Edition의 Item28에 나오는 코드를 보고서 약간 변경을 해 본 것입니다. 원래 책에 나오는 코드는 아래와 같습니다.

리스트5: Effective Java 2nd Edition에 있는 max메서드

public static <T extends Comparable<? super T>> T max(List<? extends T> list){
  Iterator<? extends T> i = list.iterator();
  T result = i.next();
  while(i.hasNext()){
            T t = i.next();
            if (t.compareTo(result)>0) result = t;
   }
   return result;
}

메서드 선언이 public static <T extends Comparable<? super T>> T max(List<? extends T> list) 로 예제보다 더 늘어난 부분이 있습니다. 끝에 있는 List<? extends T> 가 추가된 것입니다. 이 부분은 PECS원칙에 따르면 List객체로부터 T를 생산(Producer)해 오기 때문에 ? extends T 로 하는 것이 적절해 보이는 합니다. 그러나 테스트1~5의 코드에서는 List<T> 만으로도 컴파일러가 수행하는 형추론(type inference)에 문제가 없었기에 제가 만든 코드인 리스트4에는 추가하지는 않았습니다. 컴파일러가 수행하는 Type inference는 굉장히 복잡하고, Java Language Spec에서 16페이지나 차지한다고 합니다.

그리고 리스트5에서는 길이가 0인 List가 넘어간 값일 때는 첫번째 i.next();에서 NoSuchElementException을 내게 되어 있습니다.

java.util.Collections.max 메서드에서도 같은 결과가 나오는 것으로 보아서, 유사한 구현방식이 쓰인 것으로 추측됩니다. 제가 만든 문제에서는 Collection.max와 약간 다른 부분을 만들어 보고 싶어서 길이가 0일 list가 올 때는 null을 반환하는 방식으로 바꾸어 보았습니다.

그렇다면 `java.util.Collections.max`의 메서드 시그니처는 어떻게 되어 있을까요?

리스트6: java.util.Collections.max 메서드

static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll)

일단 대상이 List보다 확장된 Collection이니 Parameter가 Collection인 것이 눈에 들어 옵니다. 그런데 T의 제약조건이 <T extends Object & Comparable<? super T>>로 선언되어 있는 것이 리스트5의 코드보다 'Object &' 부분이 더 들어가 있습니다.

이것은 java1.4와의 하위 호환성을 위한 것입니다. Java에서는 하위호환성 지원 때문에 컴파일 시에 Generics관련 정보를 모두 검사한 후에는 실제로는 Generics 정보가 전혀 없는 바이트코드를 생성하게 되어 있습니다. 그래서 리스트5처럼 메서드를 선언했을 때에는 런타임시에는 리스트 7과 같은 코드와 같은 바이트코드가 생성됩니다.

리스트 7: 리스트5의 메서드 선언이 자료형 지우기가 수행된 뒤의 모습

static Comparable max(Collection c)

그러나 이전 버전에서의 max메서드의 모습은 다음과 같았습니다.

리스트8: Java5 이전의 Collections.max 메서드

public static Object max(Collection c)

따라서 리스트7처럼 Comparable을 반환하게 된다면 이것은 이전버전의 메서드 Signature를 바꿔버린 것이 되므로 하위버전에서 컴파일된 코드에서 Collections.max를 호출할 때 에러를 발생시키게 됩니다. 그래서 Object &이 더 추가된 것이죠. (Agile Java의 Lesson 12 중 Additional Bounds에서 참조)

여기까지 이해하셨으면, 실무에서 어떤 Generics 관련 코드를 봐도 이제 쉬워보이실 겁니다.

Generics의 표현력

하나의 예제로 Generics의 많은 부분을 설명하기 위해서 다소 복잡한 코드를 보여드렸습니다. 혹시나 Generics를 이제 막 적용하시고 싶으신 분들의 마음을 어둡게 한 것이 아닌가 걱정이 되기도 합니다. 그러나 대부분의 Generics적용 사례는 훨씬 간단하고, 특히 Collection 선언에 genercics를 활용하는 정도는 어렵지 않습니다.

Generics는 컴파일시점에서의 에러 검출 영역을 넓혀줘서 보다 이른 시점에 버그를 잡을 수 있게 해주고, 코드I의 설명력을 높여줘서 API사용자들이 보다 쉽게 API를 쓸 수 있게 해줍니다. 컴파일타입의 에러체크 능력은 위의 예제를 통해서 설명했으니, 표현력에 대해서도 제가 겪은 사례를 이야기해 볼까 합니다.

오래　전에 저는 Java 인터페이스를 엑셀파일로 만드는 산출물 작업을 했었는데, 리턴타입이 List인 메서드들은 그 안에 어떤 객체들이 들어있는지 메서드 시그니처만으로는 표현할 수 없어서 답답했던 적이 있었습니다. 그래서 아예 List대신 배열을 쓸까도 고민하다가 List가 가진 편의성들을 버릴 수가 없어서 List를 쓰고 따로 문서에 그 안에 어떤 객체가 들어가 있는지를 적을 수 밖에 없었습니다.

javax.servlet.ServletRequest.getParameterMap()를 사용할 때는 API사용자로서 아쉬움을 느꼈었습니다. API문서를 보면 이 메서드가 반환하는 Map에는 key로 String이, value로 String배열이 들어가 있는 것으로 설명되어 있습니다.

저는 처음에 이 문서를 안 보고 key가 String, 값이 하나일 때는 그냥 String, 값이 2개 이상이면 String배열이 들어가 있지 않을까하는 추측을 바탕으로 한 코드를 짜서 몇번 에러를 냈었었습니다. 결국 API문서를 보고서 어떤 형식으로 자료가 들어가 있는지 알게 되어있습니다. 이 메소드의 리턴타입이 Map<String,String[]> 과 같이 선언되어 있었다면, 문서를 안 보고도, Runtime 에러를 안 겪고도 바로 올바른 자료형으로 사용이 가능했을 것입니다. 이렇듯 Generics를 잘 활용할 수 없는 API를 쓸 때에는 소비자 입장에서 불편합니다.

나중에 저는 이 메서드를 호출하는 부분을 아래와 같이 감싸는 부분을 넣었습니다.

리스트9: javax.servlet.ServletRequest.getParameterMap() 메서드를 Generics를 이용한 코드로 감싸기

@SuppressWarnings("unchecked")
Map<String,String[]> requestMap = request.getParameterMap();

@SuppressWarnings("unchecked") 은 어쩔 수 없는 경우에만 써야 하고, 쓸 때도 클래스 단위, 메서드 단위가 아닌 이런 최소 라인 단위로 써야 합니다. Effective Java 2nd Edition Item 24참조) 이 경우는 Generics지원하지 않는 외부 인터페이스를 호출하는 것이라서 불가피한 경우입니다. 형에 대해서는 API 문서에 명시된 내용라서 이렇게 @SuppressWarnings을 선언해도 문제가 없습니다. 필요에 따라서 이 requestMap을 리턴해 준다면 그것을 쓰는 코드에서는 더 이상 이 안에 무엇이 들어있는지 문서를 찾아보지 않아도 됩니다.

JavaEE6 버전의 JavaDoc을 보니 이제는 request.getParamersMap`의 반환형이 `Map<String,String[]> 으로 바뀌어 있음을 확인할 수 있습니다.

스프링 프레임웍의 최근 소식들 모음 등

Wed, 10 Dec 2008 00:00:00 +0000

역시 최근 들어 스프링소스의 발걸음이 더욱 빨라졌습니다. Grails, Spring Python, tc Server, 3.0M1 발표.. 현란하게 소식이 쏟아지는군요. 그만큼 공부할 것도 더 늘겠지만, 그래도 반갑고 기대감을 가지게 하는 소식들입니다.

대규모 투자를 받고, 일을 더 벌이고 하면서 스프링소스가 돈맛에 초심을 잃을까봐 걱정을 하시는 분도 많이 계시는 듯 합니다. 그래도 성공적인 사업 구조가 정착되어서 그 수익이 개발자들에게 도움이 되는 제품들을 더 잘 개발하는데 쓰인다면야 굳이 돈을 많이 벌게 되는 것이 나쁘다고는 생각하지 않습니다. 유료로 제공되는 제품이 많아진다고 해도, 그럴만한 가치가 있는 제품이면 돈을 내고, 그것이 아니라도 프레임웍이나 서버, 개발도구의 시장은 독점 시장이 아니니 다른 선택을 할 수 있는 대안이 많을 것입니다. 물론 지금까지의 스프링의 행보를 봐서는 충분히 앞으로도 가치있는 결과물을 만들 것이라고 기대하고 있습니다.

여러 소식들 중에 솔직히 가장 재미있었던 것은, Spring one America 2008에 참석하신 분들을 통해 알게된, 로드존슨의 나이였습니다. 스프링 핵심 개발자인 유겐할러의 말에 의하면 로드존슨은 38살 정도라고 하네요.

왜 저는 로드존슨을 당연히 40대라고 생각했을까.. 하고 분석해보니, Expert one-on-one J2EE Design and Developement 책 때문에 그런 선입관을 가지게 된 것 같습니다.

이 책이 나온 것이 2003년인데, 그렇다면 이 때는 33살이였단 말이되는군요. 이 책을 쓰는데도 2년 정도가 걸렸다고 들은 것 같습니다. 그리고 책 표지에 보면 로드존슨은 음악학(Musicology)에 박사학위가 있다는 말도 있습니다. 그래서, 다른 분야도 박사까지 하고 컴퓨터 분야에서도 이정도 경지까지 가려면 적어도 이 책 출판시에 30대 중후반은 되지 않았을까.. 하는 추측을 한 것이죠.

FindBugs + Eclipse + Maven2 + Hudson

Tue, 30 Sep 2008 00:00:00 +0000

FindBugs를 이용한 코드검사를 Maven2을 통해 실행하고, Hudson을 통해 확인하는 설정을 정리해 봅니다.

Eclipse에서 findbugs로 코드검사를 해볼 수 있는 툴은 http://findbugs.cs.umd.edu/eclipse/ 를 update site로 지정하면 설치할 수 있습니다. 설치가 잘 되었다면 소스 폴더를 선택하고 마우스 우클릭을 하면 'Find Bugs’라는 메뉴가 생긴 것이 보일 것입니다. 그 메뉴를 통해 원하는 프로젝트를 검사하고, Bug Explorer 탭을 선택해보면 아래와 같은 화면이 나옵니다.

Bug Explorer 탭에서는 버그를 유형별로 정리해서 보여주고, 소스탭에서는 해당하는 코드에 벌레 모양 아이콘을 찍어줍니다. 그리고 Problems 창에서는 Eclipse에서 잡아내는 다른 경고처럼 warning으로 해당 소스를 표시해 줍니다. Bug Details 탭을 누르면 버그에 대한 자세한 설명도 볼 수 있습니다.

프로젝트의 Properties 메뉴에서 FindBugs 설정란으로 가면 검사할 규칙 등을 선택할 수 있습니다.

이 설정화면에서 'Run FindBugs automatically’를 선택하면, 소스가 바뀔 때마다 자동으로 검사를 수행해 줍니다. 이 기능이 선택되어 있지 않다면, 지적된 소스를 수정해도 다시 수동으로 검사를 돌려야지 경고메시지 지워지므로, 이클립스가 아주 느리다는 느낌이 안 들정도라면 선택하는 것이 좋습니다. 이 기능을 선택해서, Eclipse의 Problems 탭에서 코드 작성 즉시 에러와 경고를 확인할 수 있게 되었다면 .project 파일에 아래와 같은 부분이 추가되어 있을 것입니다.

<natures>

    ....

  <nature>edu.umd.cs.findbugs.plugin.eclipse.findbugsNature</nature>

</natures>

FindBugs 설정 화면 중 Detector Configuration 탭에서는 검사할 규칙들을 지정할 수 있고, Reporter configuration 탭에서는 보고해 줄 버그의 경고단계와 분류를 선택할 수 있습니다.

Filter files 탭에서는 별도의 XML파일로 선언된 포함하거나 제외시킬 버그와 파일에 대한 설정을 가지고 올 수 있습니다.

아래에 자세히 설명하겠지만, Maven 설정에서 참조하는 findBugsExclude.xml을 Eclipse plugin에서도 똑같이 지정해서 Maven과 Eclipse에서 같은 기준으로 검사가 수행되도록 했습니다.

Maven2의 findbugs-maven-plugin은 pom.xml에 아래와 같이 설정됩니다.

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>findbugs-maven-plugin</artifactId>
  <version>2.4.0</version>
  <configuration>
    <findbugsXmlOutput>true</findbugsXmlOutput>
    <findbugsXmlWithMessages>true</findbugsXmlWithMessages>
    <xmlOutput>true</xmlOutput>
    <excludeFilterFile>$\{basedir}/findBugsExclude.xml</excludeFilterFile>
   </configuration>
</plugin>

위의 설정에 들어가는 속성들에 대해서는 findbugs-maven-plugin 설명 페이지에서 자세한 내용을 보실 수 있습니다.

저는 제외할 검사규칙을 지정하기 위해서 excludeFilterFile속성에 findBugsExclude.xml을 지정했습니다.

findBugsExclude.xml의 내용은 아래와 같이 설정했습니다.

....
<FindBugsFilter>
....
....
  <Match>
....
....
   <Bug code="Se,SnVI,Dm,UwF,EI,EI2" />
....
....
  </Match>
....
....
</FindBugsFilter>
....

제외할 것을 선언하는 파일에 이렇게 적었으니 Bug code가 "Se,SnVI,Dm"에 해당하는 버그검사는 제외한다는 의미입니다. Filter의 설정 방법에 대해서는 findbugs의 매뉴얼을 참조하시면 됩니다.

버그 코드 중 Se,SnVI는 serialVersionUID에 관한 것이고 Dm은 String.toUpperCase 등의 메소드에서 Local설정을 권유하는 검사입니다. (버그 코드에 대한 설명 페이지 참조)

이렇게 설정을 하고 mvn findbugs:findbugs 로 maven을 실행시키면 필요한 라이브러리들을 다운로드 받고 빌드가 실행됩니다. 실행이 성공했다면 목적지 폴더에 findbugs.xml과 findbugsXml.xml파일이 생성이 되었을 것입니다.

이것을 Hudson을 통해서 보기 위해서는 Hudson에서도 findbugs plugin을 설치해야 됩니다.

Hudson 첫 화면에서 Manage Hudson - Manage Plugins 메뉴를 찾아갑니다. Available 탭에서 findbugs를 선택하고 화면 우측하단의 'install’버튼을 누르면 Hudson이 알아서 라이브러리를 다운 받아줍니다. 설치한 plug-in이 실행되기 위해서는 Hudson을 재시작해야 합니다.

그런 다음에 findbugs를 적용하고자 하는 프로젝트에 가서 Configure메뉴를 선택하면 아래와 같이 Publish FindBugs Analysis Result라는 부분이 추가된 것을 보실 수 있을 것입니다.

이것을 선택하고 원하는 기준값이 있을 경우 입력한 뒤에 "save’버튼을 누르고 build를 해보면 됩니다. 물론 build에는 findbugs:findbugs goal이 포함되어야 하겠죠.

빌드가 성공하는 것을 보고 프로젝트의 메뉴를 보면 FindBugs Warnings라는 메뉴가 추가된 것을 확인하실 수 있습니다.

그 메뉴를 누르면 생성된 보고서가 보입니다.

warning이 존재할 경우 건수를 클릭하면 해당하는 클래스들이 나오고, 클래스를 선택하면 소스에서 warning을 발생시키는 부분까지 보여줍니다.

만약 hudson의 findbugs plugin을 실행할 때 Cannot find setter nor field in org.apache.maven.plugins.site.SiteMojo for 'xmlOutput' 와 같은 에러가 난다면 Hudson plugin 수동으로 빌드&업로드를 참조해서 최신 버전으로 플러그인을 업데이트 해보시기 바랍니다.

Cubrid에서 commit시에 Statement가 닫히는 현상

Thu, 25 Sep 2008 00:00:00 +0000

다음의 코드는 1000건을 insert하면서 100건마다 한번씩 commit을 하는 기능을 수행합니다. 대용량 데이터를 입력 할 때 이렇게 주기적으로 commit을 해주는 것은 일반적인 처리방식입니다. Cubrid DB에서는 이와 같은 코드를 실행시키면 'Attempt to access a closed PreparedStatement.'라는 에러 메시지를 받게 될 수도 있습니다.

package test;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.util.Properties;

public class JDBCTest {

  public static void main(String[] args) {
    String query = "INSERT into common_cd(cd_type, cd, cd_name) values(?, ?, ?);";
    Properties cubrid = new Properties();
    cubrid.put("url","jdbc:cubrid:127.0.0.1:43003:test:::");
    cubrid.put("driver","cubrid.jdbc.driver.CUBRIDDriver");
    cubrid.put("user","test");
    cubrid.put("password","test");

    insertAndCommit(cubrid, query);
 }

  private static void insertAndCommit(Properties prop,String query) {
    Connection con =  null;
    PreparedStatement psmt  = null;
    try{
     Class.forName (prop.getProperty("driver"));
     con = DriverManager.getConnection(prop.getProperty("url"),prop);
     con.setAutoCommit(false);
     psmt = con.prepareStatement(query);
     for(int i=1;i<=1000;i++)\{
       psmt.setString(1, "00");
       psmt.setString(2, String.valueOf(i));
       psmt.setString(3, "code:"+i);
       psmt.execute();
       System.out.println(i+"th row set");
       if(i%100==0) {
         con.commit();
         System.out.println("commit-------------------------------------");
       }
     }
    } catch (Exception ex){
      ex.printStackTrace();
    } finally{
     try{ psmt.close();} catch(Exception e){}
     try{ con.close();} catch(Exception e){}
    }
 }
}

commit 을 했을 뿐인데, Statement가 닫혀버리는 현상이 발생한 것이죠. 원인을 찾기 위해 Cubrid JDBC드라이버의 클래스 파일들을 역컴파일 해서 봤더니, 아래와 같은 completeAllStatements()라는 메소드가 commit 메소드 안에서 호출이 되는 것이였습니다.

private void completeAllStatements() throws SQLException {
    for (int i = 0; i < statements.size(); i++) {
        UniSQLStatement unisqlstatement = (UniSQLStatement) statements.get(i);
        if (unisqlstatement instanceof UniSQLPreparedStatement) {
            statements.remove(i);
            if (u_con.brokerInfoStatementPooling())   unisqlstatement.complete();
            else   unisqlstatement.close();
        } else{
        unisqlstatement.complete();
        }
    }
}

Connection의 close시에 Statement가 close되는 것은 JDBC명세에 나와있지만 commit시에 close될 수 있다는 것은 의외였습니다. 혹시나 싶어서 MySql, Oracle, Hsql의 JDBC구현들을 다 살펴보았지만, 비슷한 동작을 할 가능성이 있는 코드들은 찾을 수가 없었습니다. Cubrid만의 독특한 점이죠.

이 문제를 해결하는 방법은 DB 서버에 있는 설정파일인 Cubrid_broker.conf 파일에서 STATEMENT_POOLING속성을 ON으로 표시해주는 것이라고 합니다.

이 속성은 서버에서 Statement Pooling을 하겠다는 의미가 아니고, Connection을 받아서 쓰는 Client 쪽에서 Connection Pooling을 하고 있으니 Commit시에 Statement를 끊지 말라고 알려주는 것이라고 합니다. 위에 있는 completeAllStatements메소드 안의 u_con.brokerInfoStatementPooling()코드가 그것을 검사하는 것 같습니다. 사실 앞의 코드의 commit을 여러번 하는 예는 Statement pooling도 아니고 한 번 만들어진 Statement를 계속 쓰는 것 뿐인데, 이것을 Statement pooling을 쓰는 것으로 인식시켜야 한다니 논리적으로 이상하기는 합니다.

그리고, Cubrid에 접근하는 Client는 CAS(Common Application Server)라는 것을 거치게 되어 있는데, 이 CAS보다 요청하는 Client의 갯수가 많을 때에는 항상 에러를 내는 것이 아니고, 이미 연결되어 있는 다른 Connection이 Transaction 중이 아니라면 그 Connection의 Statement자원을 해제시켜 버리고 가져와서 쓸 수 도 있다고 합니다. 이것을 막는 설정이 KEEP_CONNECTION이라는 속성입니다. CUBRID Manager Client프로그램에서 바꿀 수 있습니다.

또, Cubrid는 하나의 Connection에서 동시에 두개의 Prepare를 오픈 할 수 없는 구조라고 하네요. (참고자료:http://cubrid.com/bbs/view.php?id=faq&no=318&category=3[] http://cubrid.com/bbs/view.php?id=faq&no=318&category=3)

이런 특징들을 보면, Cubrid는 Client의 명시적인 요청이 없이도 자원을 최대한 빨리 해제시켜 버리는 것이 사상이 아닌가 하는 생각도 듭니다. 어쩌면 제대로 자원 해제를 못하는 JDBC 코드가 많았던 시절에 그로 인해 생기는 문제들을 대응하면서 생긴 구조일 것 같다는 추측도 해봅니다.(참고: JDBC에서 Connection, Statement,ResultSet의 close ) 그러나 대부분 프레임웍 기반의 개발을 하고 필요할 때 자원을 close시켜주는 코드들이 정착되고 있는 지금 시점에서는 큰 의미가 없는 특징이고, 오히려 다른 DB나 JDBC명세에 없는 동작으로 인한 혼란만 불러 일으킨다고 생각됩니다.

그래서 결론은 Cubrid에서 개발자의 의도보다 Statement를 먼저 해제시킬 수 있는 기능을 안 쓰려면 STATEMENT_POOLING과 KEEP_CONNECTION속성을 ON으로 하면 된다는 것입니다.

Spring batch 국내 자료링크, 그리고 KSUG 연재

Mon, 4 Aug 2008 00:00:00 +0000

(수정이력: 2008.01.19 - 스프링배치 관련 링크들은 http://www.ksug.org/94로 옮기고, 최근 자료를 포함시켰습니다.)

7월31일에 Spring Batch 1.1.1이 나왔군요. 버그수정 외에 특별한 기능의 update 사안은 없기는 합니다만, 진도가 빠른 느낌입니다. ( http://www.springframework.org/node/722 )

Spring batch에 대한 국내 자료도 점점 많이 생겨나고 있습니다. KSUG(한국 스프링사용자모임)에서 만난 분들 중 Spring batch에 관심을 가지고 계신 분들이 몇 분 계셔서, 새로운 자료들도 속속 올라올 것 같군요. 그런 분들과 정보를 주고 받을 수 있으니, 포럼(http://forum.ksug.org) 개설 등 최근 KSUG의 변화에 따른 수혜를 제가 많이 받고 있다고 느껴집니다.

스프링배치 국내 자료 모음 - http://www.ksug.org/94

그리고 제가 마이크로소프트웨어지에 연재하고 있는 글도 시일이 좀 지난 기사에 한해서 담당기자분의 허락을 얻어 KSUG의 블로그에 올리고 있습니다.

이미 잡지에 나왔던 내용이지만, 인쇄되어 나올 원고를 쓸 때와는 달리 링크와 인용을 더 편하게 할 수 있기에 웹사이트에 올릴 수 있는 기회가 온 것을 반가워하고 있습니다. 연재용 원고를 쓸 때는 참조자료의 URL이 들어가면 긴 주소를 독자들이 직접 쳐서 웹사이트에 들어가 볼까 하는 의구심도 들고, 주소가 차지하는 지면 공간도 많고 해서 사소한 것까지 웹사이트 주소를 쓰기가 망설여 지더군요. 웹에 올릴 때는 API문서 등 사소한 링크도 다 넣을 수 있어서 속이 후련했습니다. 그리고 티스토리에서 제공되는 '미주’를 다는 기능도 정말 마음에 듭니다. 개인블로그도 이글루스에서 이사가고 싶은 마음이 생길 정도입니다;

위의 연재 내용을 포함한 스프링에 대한 모든 질문과 토론은 http://forum.ksug.org을 통해서 하시면 됩니다~!

Apache commons DbUtils 활용하기

Tue, 15 Jul 2008 00:00:00 +0000

개발을 하다보면 간단한 화면 1~2개만 독립적으로 돌아가는 웹어플리케이션을 만들 때도 있습니다. 예를 들면 로그조회 프로그램 같은 것들이죠.

그런 곳에는 Hibernate나 iBatis를 쓰기에는 너무 거창하다는 느낌이 들기도 합니다. 그렇다고 JDBC로 날코딩하기는 성가실때, 이럴 때는 Apache Commons DbUtils를 써볼만 합니다.

다운로드 : http://commons.apache.org/downloads/download_dbutils.cgi
API 문서 : http://commons.apache.org/dbutils/apidocs/index.html

JDBC에서 Connection, Statement,ResultSet의 close 글에 나온 것처럼 Connection을 닫는 번거로운 처리가 DbUtils.closeQuietly(con);로 끝나는 것만 해도 상당히 편합니다.

아래 예제는 DBUtils + JSTL로 간단한 조회화면을 만들어 본 것입니다.

(Connection은 실무에서는 DataSource를 통해 얻어와야합니다.)

<%@ page language="java" contentType="text/html; charset=EUC-KR"
    pageEncoding="EUC-KR"%>
<%@ page import = "java.sql.*" %>
<%@ page import = "java.util.Properties" %>
<%@ page import = "org.apache.commons.dbutils.DbUtils" %>
<%@ page import = "org.apache.commons.dbutils.QueryRunner" %>
<%@ page import = " org.apache.commons.dbutils.handlers.MapListHandler" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%!
  private static final String SELECT_STMT =
                  "SELECT id, name, email, cell_phone_number FROM quiz_user";
%>
<%
 String url = "jdbc:hsqldb:hsql://localhost/sampledb";
 Properties prop = new Properties();
 prop.put("user","sa");
 prop.put("password","");
 Connection con =  null;
 try\{
  Class.forName ("org.hsqldb.jdbcDriver");
  con = DriverManager.getConnection(url,prop);
        QueryRunner runner = new QueryRunner();
        Object resultList = runner.query(con,SELECT_STMT, new MapListHandler());
        request.setAttribute("list",resultList);
   } catch (SQLException ex) \{

      throw new RuntimeException(ex);
   } finally \{
     DbUtils.closeQuietly(con);
   }
 %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
<title>사용자</title>
</head>
<body>
  <h1>사용자  조회</h1>
  <h2>사용자  목록</h2>
  <table class="list">
   <tr>
    <th>id</th><th>이름</th><th>전화번호</th> <th>이메일</th>
 </tr>
    <c:forEach var="item" items="$\{list}" varStatus="status">
 <tr>
  <td>$\{item.id}</td>
  <td align="center">$\{item.name}</td>
  <td>$\{item.cell_phone_number}</td>
  <td align="center">$\{item.email}</td>
 </tr>
 </c:forEach>
  </table>
</body>
</html>

몇 년전에 DbUtils와 비슷한 클래스를 만든 적이 있었는데, 그때도 좀 찾아볼 걸 그랬나봅니다. 그러고 보면 저도 Apache Commons에 이미 있는 것을 많이도 만들어본 삽질의 시간들을 겪었었습니다. 신입 때 commons beanutils하고 commons io에 포함된 것 비슷한 유틸리티 만들어 놓고 혼자서 뿌듯해 했었죠 -_-;

참고자료

이미 35개 이상의 Accenture 고객사에 Spring batch가 적용되고 있다

Thu, 10 Jul 2008 00:00:00 +0000

Spring batch 프레임웍은 스프링 프레임웍의 본부인 SpringSource와 컨설팅 회사 Accenture가 협업해서 개발하고 있습니다. SpringSource의 기술력과 Accenture의 현장경험이 합쳐진 것이죠. 작년 5월에 국내에도 이 소식이 보도된 기사가 있군요.

엑센추어, 오픈소스 프로젝트 「스프링 배치」참가

Spring batch 포럼에서 보면 이미 현장에서 적용하고 있는 사람들이 많아 보이기는 해도, 아직 얼마나 쓰이고 있는지 짐작하기는 어려웠습니다. 그런데, 얼마전에 Accenture에서 내놓은 기사에 따르면 이미 35개 이상의 고객사에서 활용되고 있다고 합니다.

Accenture and SpringSource Team to Deliver Production Version of Open Source Framework for Batch Processing

지난 5월에 Spring batch에 대해서 공개 세미나에서 발표를 한 적이 있었습니다. 그 때 받은 질문 중에 하나가 '금융권 등에서는 민감하고 고성능이 필요한 프로그램들이 배치로 돌고 있고, DB의 Stored procedure로 되어 있는 것이 많다. 그런 것들이 다 SpringBatch로 가능하겠느냐’는 것이였습니다. 그 때 저는 '성능에 대해서는 구체적으로 나온 자료가 없다. DB를 많이 쓰는 작업이라면 DB내부에서 돌아가는 Stored Procedure가 더 빠를 가능성이 크다. 그러나 배치 어플리케이션의 프로그래밍에서 추구할 우선적인 가치는 업무의 특성에 따라 다를 것이다. 그것이 성능일 때도 있고, 생산성이나 유지보수성일 때도 있다. 빠른 성능이 절대적으로 중요한 프로그램이 Spring batch의 모듈을 썼을 때 그 기대치가 안 나온다면 Store procedure로 주요부분을 짜고 그것을 Spring batch 내부에서 호출하는 방법도 가능하다.'라고 대답을 했었습니다.

그 때 위의 기사의 사례들을 알았다면 '이미 Accenture의 많은 고객사에서 사용하고 있는 것으로 보아 기업환경의 실무에서 충분히 사용 가능한 수준이라고 말할 수 있다.'라는 말을 덧붙일수 있었을 건데 아쉽군요.

우리나라의 SI에서도 적용될만한 곳이 분명 있을 것입니다.

Spring 3.0에 대한 소식

Tue, 17 Jun 2008 00:00:00 +0000

Live from SpringOne 2008: Collected bits about Spring 3.0

벌써 3.0에 대한 이야기가 나오고 있습니다.

잘 하면 2008년 4분기 정도에 GA(General Availability) release(일반사용 가능 버전)가 나온다고 하는군요. Spring Core 모듈이 Java 5에 대해 본격적으로 의존하고 이제 더 이상 Java 1.4에서는 돌아갈 수 없다고 합니다.

이미 어느 정도 윤곽이 잡혀있듯이, Spring MVC에서 REST에 대한 full scale 지원이 포함된다는군요. 그리고 Spring batch에서 지원되었던 repeat, retry, resume의 개념들과 Spring WS의 Spring OXM 등이 보다 상위 모듈에서 포함되어서 제공될지도 모르겠습니다. 또, Junit 3.8 기반의 통합테스트 클래스들은 deprecated로 표시될 것 같습니다. (아마도 AbstractSingleSpringContextTests같은 클래스들을 이야기하는 것이겠죠?)

Q33N의 비밀 - 뉴욕의 프로그래머 중

Mon, 16 Jun 2008 00:00:00 +0000

존경하는 임백준님의 책 '뉴욕의 프로그래머'에 있는 내용입니다.

노트패드로 할 수 있는 일이 생각보다 많다는 사실을 알고들 있는지?

어느 날 신나게 구라를 풀던 콜린이 말했다.

쌍 둥이 빌딩이 무너졌을 때 건물을 들이받은 비행기의 번호가 Q33N이었다는 것을 기억하는 사람은 없겠지만, 아무튼 그렇거든. 노트패드를 열고 Q33N을 입력해봐. 그리고 폰트 크기는 72로 최대한 키우고. 그 다음 글자체를 Wingdings로 선택하라고. 화면에 뭐가 나타나는지 보라고.
story 3. "무정부주의자 콜린" 중에서

전 책에서 이 부분을 읽자 마자 따라서 해봤고, 화면에 나온 결과를 보고 정말 신기하다고 느꼈죠. windows개발자가 몰래 911를 추도하기 위해서 넣은 것일 거라고 생각했었습니다. 나아가서 집에 있는 윈도우 2000이 깔린 컴퓨터에서도 되는 걸 보고 MS가 911이후에 2000버전의 노트패드에도 패치를 한건지, 아니면 개발자 중에 놀라운 예언가가 있었던것일까 하는 상상도 했었습니다.

그.러.나.

혹시나 해서 찾아봤더니, 실제의 비행기 번호는 그와 전혀 다른 번호였고, 위의 이야기는 정말로 '구라’였습니다. 원래 폰트가 그렇게 생겨먹은 겁니다.

http://www.hoax-slayer.com/wingdings-911.html

다음 링크의 아래쯤에 가면 'Q33NY’라는 문자열로 그런 소문이 도는데 사실이 아니라고 밝히고 있습니다.

http://www.hoax-slayer.com/wingdings-911.html

네이버의 지식인에서도 비슷한 질문들이 오갔고, 여기서보니 호기심 천국에도 옛날에 나왔다고 하는군요.

http://kin.naver.com/detail/detail.php?d1id=1&dir_id=106&eid=mEFZPG/iLDaISzjuCO7V4mXyyWV1VCWm&qb=cTMzbnk=

원래 저는 의심이 많은 편인데, 이번에는 완전 속을 뻔 했습니다 ^^; 아마 임백준님도 사실이 아니라는 것을 아시면서도 재미로 책에 넣으신거겠죠? ^^

Spring batch와 Spring integration의 만남

Mon, 16 Jun 2008 00:00:00 +0000

Spring portfolio의 일부 중 최근에 관심을 제가 관심을 가지고 있는 Spring batch와 Spring integration을 연결한 프로토타입 코드들이 나왔습니다.

Spring batch form에 최근에 올라온 글입니다.

Spring Integration Prototype

그리고 6월 18일에 이 것을 주제로 한 온라인 세미나 같은것이 있나 보네요.

Webinar: Enterprise Integration with Spring Batch

이 코드들은 Java 5를 사용하기 때문에 Spring batch 1.1 정식 배포판에는 들어가지 않을거라고 합니다. Spring batch 프로젝트에서는 2.0전까지 Java5 으로 가지는 않을거라고 하네요.

SpringOne 08의 Spring batch 주제의 발표에서도 관련 내용이 들어갈 것 같네요. Spring batch와 Spring integration의 convergence가 있는 것으로 보인다는 언급이 있습니다.

http://www.egloos.com/egloo/insert.php?eid=d0032573

Spring Batch와 Spring WS, Spring Integration은 얽히고 섞힌 관계라고 보입니다. Spring integration의 Web Service Adapters에서 Spring Web Service를 사용하고 있고, Spring batch에서도 XML파일 처리에 Spring WS의 일부인 Spring OXM를 통한 위임처리를 할 수 있습니다. 그리고 위와 같이 Spring integration는 Spring Batch도 연결시켰군요.

Spring Batch의 Job은 Spring Application Platform 통해서 OSGi 번들로도 실행가능하게 되었습니다.

Running a Spring Batch Job in The SpringSource Application Platform

향후 버전에서는 더욱 더 배치에 특화된 기능들이 추가될 것이라고 하네요.

Spring batch + Spring Integration + Spring WS + Spring Application Platform.. 그 미래가 어떻게 될지 정말 기대가 됩니다.

Effective Java 2nd Edition

Fri, 30 May 2008 00:00:00 +0000

Amazon에서 예약주문 단계에서 판매상태로 바뀌었습니다.

http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1212115691&sr=8-1

회사에서 Yes24에서 책을 주문할 수 있는 쿠폰을 주기 때문에 저는 공짜로 보기 위해서 거기서 주문할 수 있을 때까지 기다리고 있는 중입니다.

Joshua Bloch과의 인터뷰를 보니 역시 Generics등 Java5 이후의 주제들에 대해서 내용이 보강되었다고 하네요. 정확히는 21개의 항목과 83페이지가 늘어났다고 합니다. 기대가 되는군요.

Book Excerpt and Interview: Effective Java, Second Edition

더불어 121페이지의 예제코드의 실수도 언급되어 있길래 옮겨봅니다.

지금 인쇄판에 들어간 코드

static Object reduce(List list, Function f, Object initVal) {
    Object[] snapshot = list.toArray(); // Locks list internally
    Object result = initVal;
    for (Object o : list) // 오류 부분
        result = f.apply(result, o);
    return result;
}

수정된 내용

static Object reduce(List list, Function f, Object initVal) {
    Object[] snapshot = list.toArray(); // Locks list internally
    Object result = initVal;
    for (Object o : snapshot) // 수정된 부분 (list 대신 snapshot을 참조)
        result = f.apply(result, o);
    return result;
}

Joshua Bloch의 말에 따르면 다음에 찍는 인쇄판에서는 수정을 하겠지만 현재 시중에 나가는 판에는 이 오류가 포함이 되어 있다고 합니다.

Java에서 Checked Exception은 언제 써야 하는가?

Fri, 23 May 2008 00:00:00 +0000

Java 의 Exception 처리는 C++로부터 도입되었지만 checked exception은 Java만의 독특한 특징입니다. 아시다시피, 컴파일러가 exception을 꼭 처리해라고 강요하는 것이죠. 이것은 Java 이후에 설계된 언어인 C#이나 루비에도 채택되지 않았습니다. 즉 Java 이외의 다른 언어들의 Exception 처리 방식은 Java의 unchecked exception과 동일한 방식입니다.

Java의 초기에는 checked Exception을 사용하라고 권장했지만, 지금은 많은 반론이 제기되고 있습니다. 극단적으로 Java언어에서checked Exception 도입 자체가 실패라고 주장하는 사람도 많습니다. Thinking in Java의 저자인 Bruce Eckel도 그 중 한 사람입니다. Spring framework의 아버지 Rod Johnson도 Checked Exception이 쓰여야 할 때도 있지만 그 것이 과도하게 선호되어 온 것은 지적하고 있습니다.

어쨓든 Exception 부분은 Java로 API 설계와 코딩를 할 때 가장 어려운 부분이라고 느껴집니다. Java 아키텍트와 개발팀의 실력을 측정하는 좋은 방법은 그들이 만든 Exception 처리 코드를 보라는 말까지 있으니까요.

Exception 처리 방식 참고자료

Effective Java 2nd Edition Chapter 9 (Item 57 ~ 65)
- Item 57 : 예외는 예외상황에서만 써야 한다. 예외를 생성하고 던지고 잡는 것은 비용이 많이 드는 작업이고 JVM의 최적화 대상에서 빠질 수 있다. 프로그램 흐름을 예외로 제어하려 하면 안된다. 좋은 API는 클라이언트가 프로그램 흐름을 제어할 때 예외를 쓸 수 밖에 없도록 만들지 않는다.
- Item 58: 복구 가능한 조건에 Checked Exception을, 프로그래밍 에러에 RuntimeException을써라. Error의 하위 클래스는 만들지 말고 처리하지 않는 예외는 모두 RuntimeException의 하위클래스이어야 한다.
- Item 59 : Checked Exception은 꼭 필요할 때만 던져라. catch절에서 특별한 할 일이 없이 없는 API를 checked exception으로 처리하는 것은 프로그램만 더 복잡하게 만들 뿐이다.
- Item 60 : 표준예외를 선호하라. IllegalArgumentException, IllegalStatementException, UnsupportedOperationException, ConcurrentModificationException 등 Java의 표준예외를 활용해라.
- Item 61 : 예외를 적절하게 추상화 하라. 높은 계층에서 낮은 계층의 예외를 잡아서 높은 계층의 추상화 수준에 맞게 변환해서 던져야 한다. 예외변환(Exception translation) 패턴은 하위 레벨에 영향받지 않는 Exception 전파에 유리하지만 너무 남용하지는 마라. 가능하면 low-level exception이 없이 성공하도록 유도하는 것이 바람직하다. Exception chaining은 적절한 변환을 하면서도 세부 원인을 보존하는 장점이 있다.
- Item 62 : 메소드가 던지는 모든 예외를 명세문서에 기술하라 Checked exception은 메소드 선언부에 하나씩 선언하고, @throws 태그를 써서 모든 예외가 발생하느 상황을 정확하게 문서화하라. 단지 귀찮다는 이유만으로, 공통 상위타입으로 예외를 던지려 하지 마라. unchecked exception은 @throws 태그를 써서 명세문서에 기술하지만, 메소드 선언의 throws 절에는 나타나지 말아야 한다.
- Item 63 : 실패에 대한 자세한 정보를 상세 메시지에 담아라 실패원인을 포착하려면, 예외의 문자열 표현에 반드시 예외 발생에 영향을 준 모든 필드와 인자의 값이 들어 있어야 한다.
- Item 64 : 실패 원자성을 얻기위해 노력하라. 메소드 호출이 실패하더라도 객체상태는 메소드 호출 전과 같아야 한다. 오류(error)는 예외(exception)와 달리 보통 복구할수 없기 때문에 오류가 발생했을 때 실패 원자성을달성하기 위해 애쓸 필요가 없다.
- Item 65 : 예외를 잡아서 버리지 마라. 빈 catch block은 "예외 사항을 처리하라"라고 알려주는 예외의 존재 이유 자체를 짓밟는 것이다. catch block 안에서 정말 아무 것도 할 것이 없다면, 최소한 왜 예외를 잡아서 처리하지 않고 버리는지 그 이유라도 주석으로 달아 놓아야 한다.
Expert One-on-One J2EE Design and Development 중 Chapter 4 Design Techniques and Coding Standards for J2EE Projects, Exception Handling 부분
- alternative return value가 있는 경우에는 Checked exception
- data connection 생성 실패와 같이 뭔가 크게 잘못 되고 있어서 호출한 쪽에서 아무도 이를 처리할 수 없을 때는 Runtime exception.
- 소수의 호출자만이 Exception을 받아서 처리해야 할 때도 Runtime exception.
- 불명확하면 Runtime exception.
- checked Exception과 Runtime exception 페이지에서 일부 내용이 번역되어 있습니다.
- Spring 프레임웍크 워크북 (박재성 저) 88쪽에도 인용되어 있는 원칙입니다.
Barry Ruzek의 EFFECTIVE JAVA EXCEPTIONS
- Fault Handling(Unplanned condition)에는 RuntimeException, Contingency(Expected condition, alternative method result)에는 return type, exception, error code 등의 전략을 사용
- Fault를 한곳에서 잡아서 처리하는 Fault barrier pattern 사용 권장. Struts라면 org.apache.struts.action.ExceptionHandler, SpringMVC라면 SimpleMappingExceptionResolver
- AOP 적용이 도움이 될 수도 있음.
- 황상철님의 블로그 Effective Java Exceptions 발표자료 페이지에서 이 내용이 요약된 pdf 파일을 받을 수 있습니다. (effective java exceptions.pdf )
Jim Cushing Three Rules for Effective Exception Handling
- Be specific, Throw Early, Catch Late의 3가지 원칙을 제시하고 있습니다.
13 Exceptional Exception Handling Techniques
- Checked Exception을 RuntimeException으로 감싸기, throws 절에 RuntimeException이라도 선언해주기 등의 기법을 추천하고 있습니다.
Gunjan Doshi의 Best Practices for Exception Handling
- Client code가 할 일이 있을 때는 checked, 없을 때는 unchecked. progamming error에는 unchecked exception.
- 적절한 캡슐화. 비지니스 layer에서 SqlException을 던지지 말것.
Rob Walling의 Exception Handling에 관한 글 The Two Fundamental, No Frills, Square One Rules of Exception Handling
1. 에러메시지에 도움이 되는 정보를 더할 수 없다면, Exception을 잡지마라, 2. Exception을 잡았으면 기록하라." 두가지 원칙을 말하고제시하고 있습니다.
Alan Griffiths의 Exceptional Java
- 이 주제에 대해 비교적 초기에 나온 글로써, 다른 글에도 많이 인용되고 있습니다.
- Exception 처리에 대한 전통적인 원칙이 캡슐화 저해, 정보손실, 정보 과적의 문제를 일으킨다고 이야기합니다.
- public 메소드에서 던지는 Exception은 해당 패키지에 소속된 클래스일것, 다른 패키지에서는 이를 부를 때를 Exception을 전파시키지 말고 그 패키지의 Exception으로 감쌀 것을 추천하고 있습니다.
An Exception Handling Framework for J2EE Applications
- J2EE application에서의 Exception처리 전략에 대해서 설명하고 있습니다.

Checked Exception에 대한 부정적 견해를 정리한 글

Brian Goetz의 글: Java theory and practice: The exceptions debate
- Bruce Eckel, Rod Johnson, Joshua Bloch등의 주장을 정리해 놓은 글입니다. Checked Exception이 상세한 구현을 부적절하게 노출함,불안정한 메소드 시그너처,읽기힘든 코드,Exception 삼키기, 너무 많은 Exception wrapping의 문제점 있는 것을 나열하고 있습니다. unchecked exception은 Documentation이 더욱 중요하다고 강조하고 있습니다.
Rod Waldhoff의 글 : Java’s checked exceptions were a mistake
- Java의 Exception Handling은 실패한 실험이라고 주장하는 내용입니다. Checked Exception방식은 일부 low level에서만 의미가 있다고 말합니다.
Bruce Eckel의 견해(Thinking in Java의 저자): Does Java need Checked Exceptions?
- Error report 방식을 통일했다는 점에서는 의미가 있지만, 오히려 개발자들이 Exception을 그냥 삼키는 코드를 많이 짜게 하는 결과가 생겼다고 지적합니다.
Bill Venners(C#의 아키텍트)와 Bruce Eckel의 인터뷰 : The Trouble with Checked Exceptions
- versioning, scalability의 문제 때문에 C#에 Checked Exception이 도입되지 않았다고 밝히고 있습니다.

Checked Exception에 대한 논의가 진행된 페이지

Java Exceptions Are Particularly Evil
Checked Exceptions Are Of Dubious Value
Exception Tunneling
Opinion: The Eternal Debate on Checked Exceptions# : theserverside에서 벌어진 논쟁

이클립스 Exception처리 코드 템플릿 관련 자료

기타 자료

Exception-Handling Antipatterns : http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html
Error handling, A Pattern Language : http://www.objectarchitects.de/arcus/cookbook/exhandling/index.htm
Best practices in EJB exception handling : http://www-106.ibm.com/developerworks/java/library/j-ejbexcept.html
http://www.javaworld.com/jw-07-1998/jw-07-techniques.html
http://www.javaworld.com/jw-07-1998/jw-07-exceptions.html
http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html
http://www.javaworld.com/javaworld/jw-09-2001/jw-0914-exceptions.html
Beware the dangers of generic Exceptions : http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-generics.html
http://www.codemonkeyism.com/archives/2008/12/16/7-good-rules-to-log-exceptions/
http://northconcepts.com/blog/2013/01/18/6-tips-to-improve-your-exception-handling/

JDBC에서 Connection, Statement,ResultSet의 close

Wed, 21 May 2008 00:00:00 +0000

이미 많이 알려진 내용이지만, 아직도 문제를 많이 일으키는 주제입니다. 그래서 보다 이 주제를 검색엔진에서 쉽게 찾을 수 있었으면 하는 마음에서 이 글을 정리해봤습니다.

  Connection conn = null;
  PreparedStatement pstmt = null;
  ResultSet rs = null; // <---- !!!
  try{
     conn = ...<getConnection()>...;
     pstmt = conn.prepareStatement("select .....");
     rs = pstmt.executeQuery(); // <----- !!!
     while(rs.next()){
       ......
     }
  }  catch(Exception e){
     ....
  }  finally {
     if ( rs != null ) try{rs.close();}catch(Exception e){}
     if ( pstmt != null ) try{pstmt.close();}catch(Exception e){}
     if ( conn != null ) try{conn.close();}catch(Exception e){}

 }

이것이 JDBC API 사용시에 권장되는 코딩방식입니다. 코드는 참조자료에 있는 이원영님의 글에서 인용했습니다.

JDBC 스펙을 찾아보면 Statement가 닫힐 때 ResultSet은 닫히고, Connection이 닫히면 Statement도 닫힌다고 되어 있습니다. 하지만 Staement close 시에 Exception이 발생한다면 이것이 따로 Exception을 catch되지 않고서는 뒤에 Connection을 닫는 코드가 실행되지 않습니다. 그리고 Connection pool에서 얻어온 Connection객체는 connection.close()로 처리하는 것이 pool로의 반환을 의미하는 것이지 실제로 connetion을 close하는 것이 아니기 때문에 Statement까지 닫아준다고 장담할 수 없습니다. ResultSet의 경우도 WAS에도 제공하는 Statement cache 기능 때문에 명시적으로 close해주는 것이 확실한 자원해제를 보장할 수 있습니다.

DBMS에서 "maximum open cursor exceed !" 나 "Limit on number of statements exceeded " 에러를 내고 있다면 위와 같이 코딩했는지 한번 확인해보시기 바랍니다.

각 벤더별 드라이버의 구현이나 WAS의 Connection Pool의 구현등에 따라서 저 정도까지 안 해도 문제가 안 생길 수도 있습니다. 그리고 독립적으로 돌아가는 배치프로그램이나 커넥션풀을 쓰지 않는 경우에는 보다 덜 엄격해도 될 때도 있습니다. 그래도 어떠한 경우에도 안심하고 있을만한 코드는 위와 같은 구조입니다.

javaservice.net에서 이원영님이 처음에 이 문제에 대한 글을 쓰신것이 2000년 9월입니다. 그래서 많은 분들이 알고 계시지만 그래도 정말 반복적으로 만나게 되는 문제입니다. 저의 경험이 편향된지도 모르겠지만, 지금까지 제가 만났던 JDBC AP를 그대로 쓰는 개발팀은 세 팀이였었는데, 모두 이렇게 코딩하지 않을 경우 문제가 생길 가능성이 있다는 것을 모르고 있었습니다. 결국 그 중 한 팀은 시스템 전체를 몇 일동안 매시간마다 재부팅시키게 만들게 했었습니다.

미국의 모 대형항공사의 예약시스템을 3시간동안 멈춘 코드도 위와 같은 방식을 따르지 않았었습니다. finally절이 다음과 같았다고 합니다.

} finally{
    if (stmt!=null) stmt.close();
    if (conn!=null) conn.close();
}

그 예약 시스템은 이중화된 DB로 구성되어 있었고, 그 DB들은 가상IP주소로 어플리케이션과 연결되어 있었습니다. 정기 점검을 위해 DB중 하나를 수동 fail-over 시키는 순간 내려간 DB의 JDBC연결에서 나온 statement객체의 close문장은 Exception을 일으켰습니다. 이 문장은 별도로 catch 되지 않았기 때문에 그 다음의 conn.close()는 실행되지 않았습니다. 결국 이 때문에 반환되지 않은 Connection 자원들로 인해 리소스 풀은 곧 바닥이 났습니다. 그 후에 새로 Connection을 얻고자 하는 다른 프로그램들은 블록되어서 전체 시스템을 멈추었습니다.

아마도 JDBC API를 쓰는 곳에는 언제나 생길 수 있는 문제일 것입니다. 좋은 API는 문서를 안 보고 자연스럽게 써도 사용하기 쉽고 문제를 안 일으키는 것일텐데, JDBC는 제대로 사용하기가 오히려 더 어려운 API입니다. 위의 항공사 사건 같이 전 세계에서 JDBC로 인해 야기된 장애,생산성 저하를 다 따져본다면, 가히 이 API가 인류에게 끼친 해악이 엄청나다는 생각까지도 듭니다. 요즘은 Framework 기반 개발로 JDBC를 직접 안 쓰는 것이 이런 점에서는 다행입니다.

JDBC API에서 대표적으로 지적받는 문제점은 Checked Exception을 남발했다는 것입니다. catch 절에서 아무 것도 하지 않는 것은 바람직하지 않은 코딩이지만 JDBC API에서는 정말 할 것이 없습니다. 그래서 이런 문제점을 알고서 그 후에 나온 JDBC를 활용한 API들, Spring의 JdbcTemplet, Hibernate의 Query 인터페이스, JPA의 Query 인터페이스, JDO의 Query 인터페이스에서는 Checked Exception인 SqlException을 볼 수 없게 설계되어 있습니다.

그리고 Java6 이전의 JDBC에서는 접속에러, 쿼리에러, 제약조건 에러 등 다양한 원인으로 생기는 Exception을 SqlException 1개로 다 때우는 문제도 있었습니다. Spring에서는 이것을 더 섬세하게 구분한 Exception들을 정의를 하고 있습니다. DataAccessException의 하위 클래스를 보면 CleanupFailureDataAccessException, DataIntegrityViolationException, DataRetrievalFailureException 등이 보입니다. Java6에 포함된 JDBC 4.0에서는 SQLNonTransientException, SQLRecoverableException, SQLTransientException 등의 하위 클래스가 생겼고, ,Spring에서는 이런 클래스도 잘 인식해서 적절한 DataAccessException의 하위 클래스로 변환해줍니다.

Java의 Checked Exception 처리 문제에 관한 글은 따로 정리했습니다.

참고자료

미국 항공사 장애 사건 관련

Release It 릴리스 잇 : 성공적인 출시를 위한 소프트웨어 설계와 배치 (마이클 나이가드 저/신승환,정태중 역, 위키북스)
- 2장 사례연구 : 항공사를 정지시킨 예외(Exception) 사건

JDBC 관련

Javaservice.net에 이원영님이 올린 글

(죽은 링크) 서블렛 + JDBC 연동시 코딩 고려사항 -제1탄-
(죽은 링크) 서블렛 + JDBC 연동시 코딩 고려사항 -제2탄-

현 시점에서 찾을수 있는 해당 글의 복사본

Digester를 이용한 Naver Open API Java Client 모듈

Fri, 16 May 2008 00:00:00 +0000

네이버 Open API Cafe에서 검색 API의 Java Client 모듈을 보게 되었습니다.

위의 모듈을 참고해서 같은 역할을 하는 모듈을 다르게 구현해봤습니다.

특징은 아래와 같습니다.

RSS를 파싱하는 부분을 XML parsing API로 널리 알려진 Digester(http://commons.apache.org/digester/)를 사용했습니다. Digester의 예제 코드로 제공되는 RSS파싱모듈을 그대로 써서 짧은 코드로 파싱이 가능했습니다.
- API 문서 : (RSSDigester , Channel , Item)
요청 파라미터를 담는 클래스를 따로 뺐습니다. (RequestParameter.java) 이중 Target 값은 (blog, news 등 검색할 컨텐츠 유형을 선택하는 파라미터입니다.) enum으로 해서 정해진 값이 아닐 경우 compile이 안 되게 했습니다.
open API key값은 필수값이므로 OpenApiClient클래스의 생성자의 파라미터로 받았습니다. 대신 키 값이 없이 이 객체가 생성될 수 없도록 default 생성자는 private으로 돌려놨습니다.

첨부한 파일은 이클립스에서 Dynamic Web Project로 생성한 폴더를 압축한 것입니다. 테스트 실행 서버는 Tomcat 5.5를 사용했습니다. Eclipse WTP가 설치되어 있는 환경이면 실행이 가능합니다. 그리고 enum을 썼기에 Java5이상이어야 합니다.

Open API에 대한 자세한 사용법은 http://openapi.naver.com/index.nhn 를 참조하시면 됩니다.

소스코드

NaverSearchClient.java

package openapiclient;

import java.io.InputStream;
import java.io.UnsupportedEncodingException;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLEncoder;

import org.apache.commons.digester.rss.Channel;
import org.apache.commons.digester.rss.RSSDigester;

public class NaverSearchClient {

    private static final String OPEN_API_URL = "http://openapi.naver.com/search";
    private String key;

    @SuppressWarnings("unused")
    private NaverSearchClient(){};

    public NaverSearchClient(String key){
    this.key = key;
    }
    public Channel search(RequestParameter param) throws Exception{
        RSSDigester digester = new RSSDigester();
        URL requestUrl = getRequestUrl(param);
        InputStream is = requestUrl.openConnection().getInputStream();
     return (Channel) digester.parse(is);
    }

    private URL getRequestUrl(RequestParameter param) throws UnsupportedEncodingException, MalformedURLException {
        StringBuffer serverUrl = new StringBuffer(OPEN_API_URL);
        serverUrl.append("?target=" + param.getTarget());
        serverUrl.append("&key=" + key);
        serverUrl.append("&start=" + param.getStart());
        serverUrl.append("&display=" + param.getDisplay());
        serverUrl.append("&query=" + URLEncoder.encode(param.getQuery(), "UTF-8"));
        if(param.getSort()!=null) serverUrl.append("&sort=" + param.getSort());
        return new URL(serverUrl.toString());
    }
}

RequestParameter.java

package openapiclient;

public class RequestParameter {

 public enum Category{
  KIN,BLOG,CAFE,DOC,WEBKR,BOOK, SHOP, ENCYC,
  KRDIC, JPDIC, ENDIC, NEWS, LOCAL, VIDEO,IMAGE;
  public String toString(){
   return super.toString().toLowerCase();
  }
 }

 private Category target;
 private String sort;
 private int start;
 private int display;
 private String query;

 // getter and setters 생략
 }

JSP에서 사용한 예제

JSTL을 함께 사용해서 찍어본 예제입니다. http://openapi.naver.com/index.nhn 에 가셔서 API key를 발급 받으시고 소스 중간에 밑줄로 표시된 부분에 그 값을 넣으시고 돌려주시면 됩니다.

<%@ page language="java" contentType="text/html; charset=EUC-KR"   pageEncoding="EUC-KR"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ page import="openapiclient.RequestParameter" %>
<%@ page import="openapiclient.NaverSearchClient" %>
<%@ page import="org.apache.commons.digester.rss.Channel" %>
<%
 String KEY = "????"; // Open API key값을 넣으세요
 NaverSearchClient client = new NaverSearchClient(KEY);
 RequestParameter param = new RequestParameter();
 param.setDisplay(10);
 param.setStart(1);
 param.setQuery("미역국");
 param.setTarget(RequestParameter.Category.NEWS);
 Channel result = client.search(param);
 result.render(System.out); // 콘솔에 받아온 내용을 확인삼아 찍어봄
 request.setAttribute("result", result);
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=EUC-KR">
<title>Naver Open API를 이용한 검색</title>
</head>
<body>
<c:forEach var='item' items='${result.items}'>
  <p>
  <a href="${item.link}"> ${item.title} </a> <br/>
  ${item.description}
  </p>
</c:forEach>
</body>
</html>

실행결과화면

Batch job에서의 바람직한 트랜잭션 처리 방식

Thu, 15 May 2008 00:00:00 +0000

일반적인 온라인 어플리케이션에서는 사용자가 보내는 event 한번에 하나의 트랜잭션을 묶어서 처리합니다. 하지만 배치처리에서는 하나의 처리가 하나의 트랜잭션으로 관리되는 것은 때로는 문제가 될 여지가 있습니다.

몇 만 건 이상의 행과 같이 대용량 데이터를 다루는 경우에는 roll back segment 같은 공간의 부족현상이 생길 위험이 있습니다. 그리고 상대적으로 긴 처리 시간동안 DB에 lock을 걸리게 해서 전체 시스템에 병목을 만들지도 모릅니다. 사용자가 많은 웹어플리케이션이 동시에 접근하는 DB에서 배치처리를 돌릴 때는 이를 더 염두에 두어야 할 것입니다.

또, 데이터가 건마다 독립성을 가지고 있는 경우라면 한 두건의 처리실패 때문에 앞에 성공한 건들도 다 Roll back이 되어버린다면 더 많은 건의 데이터가 의도하지 않은 상태로 오래 유지됩니다. 배치처리의 에러가 발생 즉시 해결되지 않을 수도 있기 때문에 때문에 업무 규칙상으로 가능한 경우라면 부분적으로 성공한 건이라도 DB에 반영되는 것이 좋습니다. 그렇지 않을 경우에 재시도시에 다시 모든 데이터를 처리해야 하니 그 처리시간이 더 길어지게 됩니다.

그렇다고 해서 데이터 매 건마다 따로 트랜잭션 처리를 하는 것도 성능상 좋지 못합니다. 트랜잭션을 시작하고 끝낼 때 드는 비용도 감안해야 되기 때문입니다.

따라서 일정한 행 단위를 묶어서 처리를 하는 것이 배치처리에서는 더 바람직한 방식입니다.

WebSphere XD Compute Grid에서는 check-point algorithm을 time-based와 record-based 두 가지 방식으로 제공해서 이런 문제에 대한 해결책을 제시하고 있습니다. Spring batch에서는 SimpleStepFactoryBean 클래스에서 commitInterval이라는 속성으로 주기적인 commit을 설정할 수 있습니다. 데이터 특성이나 업무규칙에 따라서 적절한 값을 트랜잭션 단위로 묶이는 건수를 지정할 수 있는 것입니다.

참고자료 1

High-volume Transaction Processing in J2EE :

세번째 페이지의 Job Partitioning and Chunking 단락에서 아래와 같이 설명하고 있습니다.

Running your job as one long-lived transaction isn’t a good idea. Long-lived transactions are more fragile than short-lived transactions. They are more susceptible to errors and DBMS locking problems because the locks are held longer. Smaller chunks are more reliable and less likely to exceed your connection and session timeouts.

참고자료2

Misconception: Big batch jobs should use a ‘dedicated’ rollback segment :

Oracle의 경우를 설명한 글입니다. DBA들이 보통 긴 transaction을 유지하는 batch job에 전용 role back segment를 할당하는데 실제로는 이것이 별도움이 못 된다고 말합니다. 결국 다른 session들이 사용할 수 있는 roll back segment를 사용하는 것은 똑같기 때문에 ORA-01555 에러를 유발할 수 있다고 합니다. 결국 보다 작은 transaction 단위를 가지고 가는 것이 근본적인 해결책입니다.

그리고 실패시 재시도를 위해서 지난 번 처리한 영역까지 표시하거나 앞에 성공한 건들을 다 지워줘야 하는 경우 때문에 큰 transaction을 가지고 가는 문제가 .생기는데, 재시도를 위한 기능을 트랜잭션에서 제공받기 전에 응용프로그램에서 적절한 로직으로 처리하는 것이 필요하다고 나와 있습니다.

The problem that needs to be addressed in cases such as these is the design of the batch processes that require such a huge transaction. Transactions in Oracle should normally be kept fairly short. While it is undesirable to commit for every row processed (which will cause excessive redolog buffer flushing and high waits on “log file sync”), it makes sense to have batch processes commit for every few hundred rows processed.

Often the greatest barrier to changing batch jobs to commit continuously is failure tolerance. If a batch job that commits continuously fails part way through, then there must be a way to restart that batch job where it left off, or clean up from the first attempt so that the job can be started over. Whereas before this restart capability was provided by rolling back the large transaction, the proposed rollback-friendly model requires that the appropriate application logic be built into the batch processing software.

If you allow your semi-frequently committing batch jobs to randomly select rollback segments like all the rest of the transactions in your system, you will be less likely to overwrite recently committed changes, since the burden of the batch transactions is spread around, rather than concentrated in a single rollback segment

참고자료3

Solving Business Problems with WebSphere Extended Deployment :

WebSphere XD에서 제공하고 있는 check-point algorithm에 대한 설명을 볼 수 있습니다.

참고자료4

Spring batch documentation - 4.4.1.2. Configuring a CommitInterval :

Spring batch에서 주기적인 commit을 설정하는 방법입니다.

매쉬업(Mashup) 도구들

Wed, 23 Apr 2008 00:00:00 +0000

Yahoo Pipe

MS Popfly

http://www.popfly.com/
설명 : http://en.wikipedia.org/wiki/Popfly
Silverlight 기술에 기반
시연동영상 : Three Minut Mashup - Microsoft Popfly

IBM lotus mashup

http://www.ibm.com/lotus/mashups
2008년 중반에 공개 예정

Google Mashup Editor

Intel Mash maker

http://mashmaker.intel.com/web/
웹브라우저에 확장된 기능을 제공하는 형식
시연동영상 : http://blip.tv/file/get/Intel_SW-IntelMashMakerOverviewVideo814.wmv

Effective Java에 대한 서평에 재미있는 댓글

Thu, 17 Apr 2008 00:00:00 +0000

Effective Java의 Second Edition이 나올 때가 되지 않았나 싶어서 아마존에 가봤더니 아직이군요. 5월28일로 발매가 예정되어 있습니다. (http://www.amazon.com/Effective-Java-Second-2nd/dp/0321356683/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1208402810&sr=8-1)

대신 Effective Java의 서평 중에서 재밌는 내용을 발견했습니다.

http://www.amazon.com/review/R296QBPY6ZC2LB/ref=cm_cr_pr_cmt?_encoding=UTF8&ASIN=0201310058#wasThisHelpful

Spend a couple years writing Java code. Then come back, re-read the book, and revisit your review. You will change your mind, or career.

처음에 서평쓴 사람이 컴퓨터 과학전공 졸업자로서 35%의 내용정도만 유익했거나 재미있었다고 하니 밑에 답글로 '2년 정도 Java코드를 작성해보고 다시 책을 읽고 다시 서평을 쓴 것을 찾아봐라. 너는 생각을 바꾸게 되거나 진로를 바꾸게 될 것이다.' 라고 적었군요. ^^;

마인드맵(mind map) 그리기 도구들

Wed, 16 Apr 2008 00:00:00 +0000

마인드맵 관련 자료

마인드맵 도구와 관련 포스트

MindMeister : 웹기반 공유 마인드맵.
Thoughtex : 웹기반, WPF 기반
- WPF 기반의 온라인 마인드 맵 도구 입니다.
Mind42 : 웹기반
- 웹 기반의 멋진 마인드맵 (mindmap) - Mind42 를 써보자
ConceptDraw
- ConceptDraw MINDMAP 5.3 비주얼 이북 만들기
ThinkWise :
- MindManager에서 ThinkWise로
- MindMapper : ThinkWise의 해외 버전
MindManager
freemind : Java 기반, 오픈소스
- 마인드 맵을 그리는 FreeMind
- 무료 마인드맵(Mind Map) - Freemind
SmartDraw
ConceptLeader

자료나 생각을 정리할 때 마인드맵을 활용하고 싶다는 생각은 오래 전부터 해왔지만 쉽게 실현하지는 못했습니다. 제가 마인드맵을 처음 접한 것은 고등학교 때였는데, 몇 번 정도 공책필기 내용을 정리해보다가 그만두고 말았었습니다. 정리하는 내용이 재미가 없어서도 그랬었겠지만, 아무래도 책에서 본 예제처럼 이쁘게 마인드맵이 그려지지 않았던 이유도 컸었던 것 같습니다. 그후로도 몇번 마인드맵과 마주쳤지만 선뜻 작성해볼 의지가 생기지는 않았습니다.

위에 소개된 마인드맵 작성을 도와주는 프로그램들이 저 같은 사람에게 도움이 될 것입니다. 여러 도구를 다 써봐도 여전히 손으로 그리는 것이 가장 효율적이라고 생각하시는 분도 계실 것 같습니다만, 저의 경우는 손재주가 없어서 인지 프로그램이 더 편하게 느껴지더군요.

이 중에 MindMeister, Mind42 , Thoughtex 는 별도의 프로그램 설치없이 웹에서 마인드맵을 그릴 수 있습니다. 공동작업을 하거나 작업결과를 웹으로 공개할 때 편하게 쓸 수 있어 보입니다.

그리고 얼마전에 알게된 ConceptLeader 는 연결선의 시각적 효과가 돋보입니다. 제가 읽었던 마인드맵을 설명하는 책에서는 선을 뿌리 쪽에는 두껍께, 말단부로 갈 수록 가늘게 그리라고 되어있는데, 다른 프로그램들에서는 이런 효과를 줄 수 없었습니다. ConceptLeader는 홈페이지에서 사용자 등록을 하면 상업적이지 않은 목적의 개인사용자는 무료로 쓸 수 있습니다.

Java Coding Convention 관련 문서들

Tue, 1 Apr 2008 00:00:00 +0000

Coding Convention 문서

Sun에서 제시한Coding convention

http://java.sun.com/docs/codeconv/index.html
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
http://java.sun.com/docs/codeconv/html/CodeConventions.doc5.html#16817 : 블럭 내에서 변수선언 위치
- Effective Java (Joshua Bloch저 이해일역)의 7장 프로그래밍 일반 - 항목29 (지역변수의 유효범위를 최소화하라)에서 나온 의견과 다소 어긋남

기타

http://g.oswego.edu/dl/html/javaCodingStd.html : Doug Lea’s Java Coding standard
http://www.chimu.com/publications/javaStandards/part0003.html : Chimy Inc coding standards.
http://www.ambysoft.com/javaCodingStandards.html : Scott Ambler’s coding convention

한글 자료

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

그림

shuffle을 이용한 로또생성기

Fri, 14 Dec 2007 00:00:00 +0000

바로 아래 포스팅에서 간단한 로또생성기 코드를 만들어봤었죠. (http://blog.benelog.net/1642193).

같은 문제에 대한 dak99님의 풀이(http://dak99.egloos.com/3529054)를 보고 다시 다른 버전을 만들어봤어요.

shuffle을 이용해도 Collections의 메소드들을 불러서 쓰니 코드가 별로 안 복잡해 지는군요.

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class LottoMachine \{
    public static void main(String[] args) \{
        List<Integer> numberCards = new ArrayList<Integer>();
        for(int i=1;i<=45;i++) numberCards.add(i);
        Collections.shuffle(numberCards);
        List<Integer> picked = numberCards.subList(0,5);
        Collections.sort(picked);
        System.out.println(picked);
    }
}

n이 클수록 속도차이가 클겁니다.

로또생성기 java로 만들어보기

Wed, 12 Dec 2007 00:00:00 +0000

javaservice.net에서 보고 저도 한번 짜봤어요.

( 원글: http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=qna2&c=r_p&n=1196139164&p=3&s=t#1196139164 )

문제

1부터 45까지의 숫자 중에 6개를 뽑는다.6개의 값이 다 달라야 한다.
java.util.Random를 이용해서 임의의 값을 구한다.
출력시 작은 숫자부터 순서대로 출력

저의 풀이

간단하게 짠다면 일단 저는 아래와 같이 해보고 싶어요.

import java.util.Random;
import java.util.SortedSet;
import java.util.TreeSet;
public class LottoMachine1 {
    public static void main(String[] args) {
        SortedSet<Integer> pickedNumbers = new TreeSet<>();
        Random random = new Random();
        while(pickedNumbers.size()< 6) pickedNumbers.add(random.nextInt(45)+1);
        System.out.println(pickedNumbers);
    }
}

무엇인가를 만들고 싶다는 꿈

Thu, 29 Nov 2007 00:00:00 +0000

마이크로소프트웨어지 2007년 11월호의 특집기사는 '개발고수 7인의 천기누설, 슈퍼개발자로 가는 길’이였습니다. 왠지 얄팍해 보이는 제목이 마음에 들지 않았고, 내용을 읽기 전까지는 이제 이 잡지도 소재가 고갈되었나 하는 생각까지도 들었습니다. 그러나 거기에 포함된 델파이 고수 양병규님의 기사는 충격적일 정도로 감명을 주는 내용이였습니다.

취재기자의 글 : 당신의 가슴 속에 품은 꿈은 무엇인가요?, 꿈꾸는 개발자의 희망스토리

그 기사에서는 양병규님이 PC원격제어 프로그램을 혼자서 2개월만에 개발한 이야기가 나옵니다. 양병규님은 다른 PC원격 제어 프로그램을 처음 보는 순간부터 그런 프로그램을 직접 만들어보고 싶은 마음이 들었고, 그후로 부터 실제 개발을 시작한 시기 사이의 2년동안 틈틈히 아이디어를 생각하고 메모를 했다고 합니다. 화면 캡쳐, 이미지 압축, 소켓 전송 등 프로그램에 필요한 구체적인 것까지 다 미리 생각해 둔 덕분에 실제 개발기간인 2개월동안에는 코딩만 하니 끝이였다고 하네요. 대단하지 않습니까? 아래는 그 기사에서 인용한 내용입니다.

이런 방법으로 작은 수첩하나를 가슴에 품고 자신의 생각들을 차곡차곡 쌓아가다 보면, 방금 산 복권을 양복 주머니에 넣고 희망찬 모습으로 걸어가는 모습의 복권 포스터 주인공 못지 않게 희망찬 하루하루를 살 수 있을 것이다.

델마당 양병규 님의 40대 초보 프로그래머에 대한 답변 글에 있는 양병규님의 첫 프로그램 이야기도 감동적입니다. 저의 부모님께서도 예전에 어렵게 생활하셨던 분들이라, 어른들의 젊었을 적에 고생한 사연은 어릴 때부터 하도 많이 들어왔기에 왠만한 이야기들은 저는 무덤덤하게 느껴집니다. 하지만 그런 저도 양병규님의 이야기를 읽은 뒤에는 저절로 고개가 숙여집니다.

위의 글들을 다 보고나니, 제가 프로그램 개발을 하게 된 이유를 한동안 잊어먹고 있었다는 것을 깨달았습니다. 뭔가를 만들어보고 싶다는 마음, 만드는 과정의 즐거움, 결과물을 볼 때의 뿌듯함, 혹시나 다른 사람에게 도움이 될 수 있을까 하는 기대감.. 그런 감정들이였습니다. 다른 많은 분들도 마찬가지 일 듯합니다.

그런 시작을 잊고 살다 보니 만들어보고 싶은 것이 생각나도 '시간나면 해봐야지’하는 마음으로 흘려보낸 시간들이 많았습니다. 앞으로는 자주 안 잊어먹도록 여기에도 적어놓습니다.

제 꿈은 아래에 나오신 분들 같은 '발명 할아버지’가 되는 것입니다.

이명(99세) 할아버지 : 나이도 못 막은 열정 ‘98세 발명왕’ (주간동아)
최태진(70세) 할아버지 : 밥 먹다가도 작업실 뛰어가 (노컷뉴스)
정선영(70세) 할아버지 : “죽기전에 딱 5개만 더 발명하는게 소원” ‘정력팬티’로 100개국 특허 따낸 정선영씨 (조선일보)
정병일(73세) 할아버지 : 농기계 발명 구슬땀 귀농 70대 부부 화제 (국민일보) , 발명 삼매경에 빠진 할아버지 (SBS 생방송 모닝와이드 1818화 3부)
김병문(65세) 할아버지 : 가위 든 맥가이버(SBS 출발 모닝와이드 2556회 3부 )

(간혹 방송이나 인터넷에서 몇 분을 보기는 했는데 찾아보니 이런 할아버지들 꽤 많군요)

2050년쯤 '발명 할아버지’로 검색했을 때 어느 시골의 마을신문에서 낸 기사로 '집념의 발명 할아버지 정상혁’과 비슷한 제목이 뜬다면 제가 꿈을 이뤘다고 보셔도 됩니다. 혹시나 그 기사에 '그러나 만든 것 중 쓸모있다고 인정받은 것은 하나도 없음', '주변에서 계속 뜯어 말리고 있으나 소용없음','가족들은 갈수록 헛소리가 심해진다고 걱정이 많음’과 같은 내용이 포함된다고 해도 말이죠.

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

Mon, 22 Oct 2007 00:00:00 +0000

마이크로소프트웨어지에 '커뮤니티 노트’라는 컬럼을 연재하고 계신 최재훈님이 번역하신 책입니다. 사실 처음 책의 목차만을 보았을 때는 '실용주의 프로그래머’와 겹치는 내용이 많을 것 같아서 큰 기대를 하지는 않고 읽기 시작했었습니다. 아마 제가 블로그를 통해서 이 책을 알지 못하고 서점에서 우연찮게 만났다면 책을 안 사고 지나쳤을 법도 합니다. 그런데 다 읽고나니 다음에 프로젝트 시작할 때는 사비로라도 이 책을 사서 프로젝트 팀원들에게 돌리고 싶다는 생각이 들더군요.

이 책에서는 프로젝트를 성공적으로 이끄는 해결책으로 다음의 방법들을 제시하고 있습니다.

소스코드 버전관리 프로그램을 이용해라.
테스트 자동화를 해라.
프로젝트 첫날 빌드스크립트를 작성해서 자동화하고, 지속적으로 통합, 빌드, 테스트를 해라.
일일회의로 개발자들간의 의사소통을 활발히 해라
상호 코드 검토를 해라.

아마 이미 식상한 이야기라고 느끼실 분도 많을 것 같네요. 저도 요약한 것만 봤다면 그렇게 느꼈을 것 같습니다. 그러나 이 책의 조언들은 현장감이 넘칩니다. 상세한 행동 방법들과 잘 되어 가고 있는지 확인할 수 있는 검토사항들을 알려주고 있습니다. 부록으로 책에서 말한 지침을 실천하는데 도움이 되는 테스트 프레임웍 같은 도구들의 URL을 모아서 정리해주는 친절함도 있습니다.

요즘과 같이 지식이 잘 전파되는 환경에서 위의 조언들을 모르고 있는 개발조직은 거의 없을 것입니다. '외국에서나 통하지 우리나라 현실에 안 맞는 방법이다. ' , '실무를 모르고 책상에 앉아서 만든 이야기일 것이다', '내가 프로젝트를 많이 해봐서 아는데 다 이상적인 내용일 뿐이다.' 등의 생각으로 적용을 안하고 경우도 많습니다. 또는 당장 급하게 돌아가게 있는 프로젝트에서 변화를 주는 것은 위험하다고 판단하기도 하겠죠.

저도 그런 경험들을 거쳐왔었습니다. 몇년전에 제가 경험했던 프로젝트에서는 본사차원에서 버전관리 프로그램(PVCS Merant version manager)를 쓰도록 표준이 정해졌었고, 그 프로그램에 대한 설치, 개발자와 고객에게 같이 교육까지도 지원되었습니다. 당시에 저도 버전관리 프로그램이 좋다는 말은 책에서 들어서 알고 있었지만, 막상 쓸려고 하니 괜히 소스관리에 시간만 더 들이게 되는 것이 아닌가 하는 생각이 들더군요. 그리고 PVCS에 check in 한 다음에도 취합, 컴파일, 파일업로드는 한 개발자의 PC에서 이루어 졌기 때문에 실제로 버전관리는 해봤자 백업의 의미밖에 없었습니다. 소스의 최종버전은 결국 개발자들의 각자의 PC에 저장되어 있었고, 버전관리는 프로젝트 기간동안 한 두번 정도 한꺼번에 파일을 올리는 식으로 형식적으로 하고 넘어갔습니다. 파일서버에 각 개발자들이 그날 작업한 것을 폴더 형식을 맞춰서 올리면 한 명이 개인PC로 복사, eclipse로 컴파일, 알ftp로 업로드하는 일을 했는데, 한번에 30~40분은 걸리는 작업을 거의 매일 했었던 것으로 기억합니다. 통합,컴파일, 업로드까지 한꺼번에 해주는 빌드스크립트를 작성하면 좋겠다는 생각도 있었지만, 당장 매일매일 오늘은 프로그램 몇개 짰다고 엑셀파일에 체크를 안 하면 죄인이 되는 것 같은 프로젝트 분위기에 잠깐 다른 일을 할 엄두가 안 나더군요.

다음에 이어진 프로젝트는 연속사업이였기 때문에 운영서버에서 돌아가는 소스와 새로 개발되는 소스가 복잡하게 꼬일 위험이 있었습니다. 그 때부터는 버전관리의 필요성을 팀원 모두가 어느정도 인식하기 시작했었습니다. 그래서 빌드 스크립트를 작성하는데 시간을 쓸 수가 있고, 컴파일, 새로 바뀐 파일만 복사, 소스업로드, 서버 리부팅, 로그 남기기의 작업을 한번에 해주는 ant build script를 작성했습니다. 빌드 스크립트를 윈도우 스케쥴러에 걸어서 하루에 두 번 돌리고 로그만 아침에 출근해서 한번, 점심 먹고 한번 확인해주고 에러난 것 있으면 개발자에게 통보해 주는 절차를 거쳤습니다. 당시의 제 지식의 한계로 크루즈컨트롤 같은 툴을 활용해서 완벽한 CI를 해보는 수준까지 생각 못한 것이 아쉽기는 합니다. 그래도 그 수준이라도 만들고 나니 전에 프로젝트에서 했던 원시적인 작업방식들은 이제 다시는 불편해서 못할 것만 같았습니다.

개발자들의 버전관리 프로그램을 통해서만 소스를 수정한다는 것을 고객이 인식을 하고 나니, 몇몇 고객들은 자신의 PC에 버전관리 프로그램을 설치해 달라고 요구하기 시작했습니다. 그리고 간단한 글자수정 정도는 스스로 하는 고객도 나왔습니다. 비록 <font> 태그로 제가 별로 맘에 안 드는 색깔로 도배를 해서 찜찜해진 페이지도 있었지만, 그래도 고객에 취향에 맞는 결과를 제가 손대지 않고 얻었으니 만족해야겠죠.

지금 돌아보면 이슈관리를 위한 Tracker도 적극적으로 사용했어야 하는데 하는 생각이 듭니다. 연속사업의 첫번째 프로젝트에서는 Tracker도 본사에서 교육지원을 나온 인력이 고객과 개발팀 모두에게 사용법을 강의해 줬으나, 거의 활용되지 못했습니다. 두번째 프로젝트에서는 개발팀내에서만 진도관리 정도만을 체크하는 수준에서 Tracker를 사용했었습니다. 그때는 '어차피 고객이 안 쓰니까 우리만 쓰는 용도로 쓸 수 밖에 없다’라고 생각했었는데, Version Manager처럼 적극적으로 우리가 쓰서 고객을 끌어들일 시도조차 하지 않고서 너무 쉽게 단정을 내렸었습니다.

프로젝트가 끝난 뒤에 특정 방식이 얼마나 생산성을 향상시켰는지 객관적으로 비교하는 것은 어렵습니다. 프로젝트는 정해진 시간에 딱 한번 하는 것이기 때문에 '조건을 통제한 반복실험’이 불가능하기 때문입니다. 마음이 받아들이지 못하는 방식이라면 설령 그 프로젝트가 무사히 끝났어도 '그것만 없었으면 더 프로젝트를 편하게 했을텐데’라고 생각할 것이고, 믿고 있는 방식이라면 지연된 프로젝트라도 '그래도 그거 썼으니깐 이정도로 끝낼 수 있었지.'라고 여길 수도 있습니다.

그리고 새로운 방식의 적용은 사람의 습관을 바꾸는 일입니다. 누구나 몸에 익은 편한 방식이 있고 그 방식으로도 큰 실패는 없을 것이라고 믿고 있습니다. 더 나아진다는 확실한 증거가 없는데도 기존의 방식을 흔쾌히 바꿀 사람은 흔치 않을 것입니다. 그렇게 공감을 얻는 방식을 같이 찾아간다는 것이 쉽지 않은 일임에도 프로젝트에서 그것을 위한 소통의 노력들은 부족할 때가 많습니다.

저의 경험처럼 아무리 위에서 프로세스를 정해주고 지원을 해줘도 그것을 수행할 사람들이 그 필요성에 대해서 공감하지 못한다면 어떤 좋은 도구나 방법론들도 다 형식적인 것에 그치게 되고, 오히려 프로젝트 진행의 발목을 잡는 짐이 되기도 합니다. 어쩌면 가장 좋은 도구나 방법론은 위에서 똑똑한 사람들이 칼같이 정해준 것이 아닌, 팀원 중 다수가 그것이 좋다고 믿음을 가지고 있고, 그 방식의 전도사가 될 준비가 되어있는 것들일 것입니다. 그 믿음을 공유하고 있다면 팀원들은 그것을 증명하기 위해서 더욱 그 방법을 쓰는 작업에 몰입을 하고 정성을 다할 것이고, 공감하지 못한 상태라면 '거봐~ 그거 내가 안 될거라고 했잖아~' 라는 말을 언제라도 하고 싶어서 마음에 품고 다닐 것입니다.

몇년 전의 그 정신없던 프로젝트를 마치고 나서 가장 크게 들었던 후회했던 점은 '왜 그때 더 좋은 방법을 찾아볼 노력을 더 안 해봤고, 찾은 것을 알릴려고 애쓰지 않았을까?' 라는 것이였습니다. 빡빡한 일정은 사람의 시야를 좁게 만들어서 당장 오늘,내일을 위한 임시 방편들만을 양산했고, 결국에는 그것이 더 돌아가는 길이라는 것도 깨달을 수도 없었습니다. 프로젝트 초기에 전체 개발팀 회의만 몇번 더 하고 코드리뷰만 몇번 했더라면 그 약간의 시간이 그냥 앉아서 코딩하는 시간의 몇배가 가치가 있었다는 것을 확신하지 못했고, 그렇게 투자하지 못했습니다.

이 책에서 제가 가장 감명 깊게 읽은 내용은 다음 부분이였습니다.

최고의 아키텍처는 상아탑의 '아키텍트’에게서 나오지 않습니다. 공동의 노력을 기울여야 최고의 아키텍처가 나옵니다. 전문가 한 명이 독주해서 완성한 아키텍처 문서를 여러분 앞에 던져 놓고 가게 하지 말고, 팀이 함께 일해서 모든 이의 경험을 발휘하고 쌓아나가도록 하세요.

지난 7월7일, P-camp라는 행사에 참가했을 때, 저는 '함께하는 개발표준 만들어 가기'라는 글을 썼던 적이 있습니다. 프로젝트 후에 가장 절실하게 느꼈던 점을 정리했던 것인데, 비슷한 이야기를 이 책에서 보니 당연히 반가웠습니다.

책을 읽다보니 계속 '다음 프로젝트에서는 이런이런 일을 하고, 이런 말을 사람들에게 해야지..' 하는 상상과 기대를 해보게 되었습니다. 힘들고 황폐한 프로젝트라도 조금이나마 불행을 덜어줄 수 있는 일을 제가 할 수 있었으면 하는 꿈이 다시 불어넣어졌습니다. 앞으로의 현실이 어떨지는 몰라도, 이책을 보면 '그래, 이제 제대로 해보는 거야.'라는 말이 이 책의 요약으로 머리속에 떠오를 것 같습니다.

책에 첫장에는 다음과 같은 명언이 인용되고 있습니다.

현재의 우리는 반복적으로 하는 행동의 결과이다. 그러므로 탁월함이란 행동이 아니라 습관이다. -아리스토텔레스

저는 개발자들이 가질 수 있는 탁월한 습관은 '더 나은 방법이 있다는 것을 믿고, 찾고, 나누는 습관’이라고 생각합니다.

일본서점 컴퓨터 책 코너 탐방기

Fri, 21 Sep 2007 00:00:00 +0000

지난 8월4~7일 여름휴가로 일본 동경을 갔다왔습니다. 동경의 번화가를 구경하는데 4일을 다 썼어도 아쉬움이 남을 정도로 구경거리가 많더군요. 그 와중에서도 일본에는 어떤 컴퓨터 책들이 나오고 있을까 하는 호기심을 참지못해 시부야에 있는 북퍼스트와 신주쿠의 기노쿠니아 서점을 가 봤었습니다. 사실 일본어는 '다꾸앙','와리바시','덴뿌라' 수준의 단어 밖에 모르고, 글자는 전혀 읽을 줄 모르기 때문에 책표지만 감상할 수 밖에 없었습니다. 그래도 전체적인 기류는 명확히 와 닿았기에 인상적인 경험이였습니다.

역시 웹2.0, SNS(Social Network Service), SEM(Search Engine Marketing), SEO(Search Engine Optimization, 검색엔진 최적화) 에 관련된 책들이 컴퓨터 서적코너의 앞 쪽을 차지하고 있었습니다. 인터넷 비지니스에 대한 열기는 일본에서도 뜨겁게 느껴집니다. SEM/SEO는 아직 국내에서는 책 제목으로 붙일 정도로 보편화된 용어는 아닌 것 같은데 일본에서는 어느정도 알려졌나 봅니다.

구글, Yahoo, Myspace등 인터넷 서비스에 대한 책들도 많이 보였습니다. 서비스 사용자를 위한 이용법에 대한 내용도 있었지만, 개발자를 위한 Open API관련 서적이 눈에 띄게 많았습니다.

Goole earth에 관한 책들이 몇권보이는 마지막 사진은 컴퓨터 코너가 아닌 기노쿠니아 서점의 지학(땅 지 ,배울 학) 코너에서 찍은 것입니다.

Second life에 대한 책도 진열장의 잘 보이는 곳을 차지하고 있었습니다.

마지막 사진은 기노쿠니아 원서 코너에서 찍은 것인데, 그 서점에는 컴퓨터 원서가 몇권 없었음데도 second life와 my space에 대한 책이 보였습니다.

Java관련 책들을 찾아봤는데 반가운 책들을 여러 권 발견했습니다. Effective Java, Expert one and one J2EE developement, Core J2EE pattern.

Eclipse 관련 서적들도 비중있게 자리가 배정되어 있었습니다.

오픈소스 프레임웍에 관한 책들도 찾아보았습니다.

그리고 국내에서는 보기 힘든 책의 번역판도 보였습니다.

Inside JavaOS라는 책인데 돌아와서 찾아보니 yes24에서는 외국서적으로도 검색이 안 되는 책이더군요.

함수형 언어 Haskell에 대한 책도 발견했습니다.

두 서점을 통들어 가장 강렬한 느낌을 주었던 책장은 북퍼스트에서 본 Oreli 원서를 모아둔 곳이였습니다. 잘 정리된 모습이 깔끔해 보이네요.

그리고 바로 옆에는 Oreli 번역서를 모아둔 책장이 있었습니다.

Ruby를 일본 사람이 만들었으니 Ruby관련 서적이 한 칸은 차지하고 있지 않을까 하는 상상을 했었으나, 그렇지는 않았습니다. 국내와 비슷해보이는 몇권 정도였던것 같습니다.

더 구경을 하고 하고 싶었으나,불만 가득한 아내 때문에 적당히 보고 나올 수 밖에 없었습니다. 여기까지 와서 이런 데를 오는 것이 이해가 안 간다고 하더군요. 아내가 옷가게 구경할 때 저는 불평없이 있었다는 사실이 별로 고려되지 않은 듯합니다.

서점에 가기 전에도 일본이 우리나라보다 인구가 많아서 시장이 넓으니 국내보다 풍부한 책들을 구경할 수 있을 것이라고 예상을 했었습니다. 둘러보니 역시 다양한 책들을 많이 볼 수 있었습니다 . Inside JavaOS 같은 책은 소수만이 관심을 가질 것으로 보이고 , 국내에서 이런 책을 읽고 싶은 사람은 아마 아마존에서 직접 주문해서 읽을 것입니다. 이런 전문적인 책들이 일본에 번역판이 나왔다는 사실은 크게 부럽지는 않습니다. 그러나 Open API에 대한 책에 대해서는 아쉬움이 남습니다. 이런 책도 역시 적극적인 의지를 가진 사람은 인터넷으로 자료를 찾거나 원서를 사 보면서 공부할 수 있겠죠. 하지만 영어로 읽는 것이 속도가 늦거나 약간이라도 저렴한 번역서를 사고 싶어하는 사람들을 끌어드릴 수 있다면 더욱 그 분야가 활성화 될 수 있을 것입니다. 즉 대중화하는 것이 의미가 있는 분야의 책은 수요를 보다 도전적으로 창출해야 한다고 생각합니다.

계속 open API를 예로 들면, '막연하게 뭔가 open api로 프로그램을 만들고 싶다는 사람이 있다. 그런데 그는 바쁜 업무를 핑계로 적극적으로 관련 자료를 찾아보지 못하고 있다. 우연찮게 그는 서점을 갔다가 Open API에 대한 책을 발견하고 사게 된다. 그는 출퇴근 길이나 집에서 뒹구는 시간에 그 책을 읽고 더욱 흥미를 느끼고, 결국에는 매쉬업 서비스를 만들어서 공개하게 된다.' 와 같은 일도 생길 수 있지 않겠습니까?

다음, 네이버, 스프링노트 같은 국내 서비스의 open API에 대한 입문서가 있다면 좋겠다는 생각도 듭니다.

아뭏든 읽지도 못하는 책을 신나게 구경하게 온, 특이한 경험이였습니다.

JavaScript, JSUnit으로 풀어본 뉴질랜드 화폐 문제

Wed, 19 Sep 2007 00:00:00 +0000

1st JavaScript editor의 공짜 사용기한이 얼마 남지 않아서 JavaScript로 빨리 뭐라도 만들어봐야 겠다는 생각이 들었습니다. 프로젝트 업무 중에는 그런 일이 보이지 않아서 회사의 다른 팀원들이 하고 있는 스터디 모임에서 나왔던 http://blog.naver.com/i1j1jsy/70011900056뉴질랜드 화폐문제를 풀어보았습니다.

문제

원래 제가 문제를 봤던 URL : http://rdp.ahamoment.org/wiki/Dollars

요약

뉴질랜드 화폐는 $100, $50, $20, $10, $5 지폐와 $2, $1, 50센트, 20센트, 10센트, 5센트 동전으로 이루어져 있다. 주여진 합계액에 대해서 몇 가지의 방법으로 돈을 구성할 수 있는지 세는 프로그램을 작성해라.

예) 20센트는 4가지 방법으로 만들수 있다. : 1개의 20센트, 2개의 10센트, 10센트+ 2개의 5센트, 4개의 5센트

원래 문제는 파일에서 입력값을 받게 되어 있지만, JavaScript로 풀다보니 그 부분은 생략했습니다. 직접 풀어보실 분들은 풀이를 나중에 보세요~

풀이

<script language="JavaScript" type="text/JavaScript" src="app/jsUnitCore.js"></script>
<script language="JavaScript" type="text/JavaScript">

    var unitList = [100, 50, 20, 10, 5, 2, 1, 0.5, 0.2, 0.1, 0.05];


    function countWaysOfAmount(totalMoneyAmount, unitIndex, ways)\{
        if (unitIndex == null) unitIndex = 0;
        if (ways == null) ways = 0;

        var unit = unitList[unitIndex];
        var moneyLeft = totalMoneyAmount;

        do\{
          if (moneyLeft == 0) ways++;
          else if (unitIndex < unitList.length)
            ways = countWaysOfAmount(moneyLeft,unitIndex+1,ways);
          moneyLeft =  Math.round( (moneyLeft - unit) *100) /100;
        } while(moneyLeft >= 0)
        return ways;
    }

    function testDollars()\{
        assertEquals("0.05", countWaysOfAmount(0.05), 1);
        assertEquals("0.1",  countWaysOfAmount(0.1 ), 2);
        assertEquals("0.15", countWaysOfAmount(0.15), 2);
        assertEquals("0.2",  countWaysOfAmount(0.2 ), 4);
        assertEquals("2",  countWaysOfAmount(2), 293);
    }

    alert(countWaysOfAmount(2));
</script>

코드를 더 다듬을 여지가 있는 것 같지만 일단 올려봅니다

moneyLeft = Math.round( (moneyLeft - unit) *100) /100; 부분은 다른 언어들과 마찬가지로 JavaScript에서도 소숫점 계산이 정확하지 않아서 붙인 부분입니다. 이걸 안해주니 5가 나와야하는 값이 4.999999 같이 나오더군요. 이 문제만 아니면 moneyLeft -= unit 으로 간단하게 쓸수 있는데 말이죠, Java로 이걸 짠다면 BigDecimal을 쓰거나 별도의 클래스를 정의해야겠죠.

JSUnit 없이 로컬에서 수정해 보실 분은 `<script language="JavaScript" type="text/JavaScript" src="app/jsUnitCore.js"></script> 부분과 테스트 메서드만 지우고 돌려 보시면 되겠습니다.

Internet Explorer Developer Toolbar, 1st JavaScript editor, JSUnit, FireBug 를 한꺼번에 써서 코딩하니 이클립스가 부럽지 않았습니다 ^^; 그리고 jsunit에서 debug("로그"); 로 찍어보는 것도 상당히 유용했구요. 1st JavaScript edtior나 FireBug가 모두 디버거 기능이 훌륭하지만 반복문의 값을 추적하는 것은 break point 거는 것보다는 로그로 쫙 찍어보는 것이 편하더군요.

확장된 나선형 배열 출력 문제(Spiral Array)

Wed, 19 Sep 2007 00:00:00 +0000

지난 2월에 회사 워크샵에서 풀었던 나선형 배열 문제에 대한 글을 올린 적이 있었지요. ( http://blog.benelog.net/901106 )

알고보니 xper.org에도 이 문제가 올라와 있더군요 (http://xper.org/wiki/seminar/SpiralArray). 거기에 가면 다른 분들의 풀이도 많이 볼 수 있습니다. 저는 이 문제를 실컷 가지고 논 후에 더 이상 손 댈 것이 없다고 느껴질때 다른 분들의 풀이를 꼼꼼히 볼 생각입니다.

우연찮게 이에 대한 확장된 문제를 다른 블로그에서 보게 되었습니다. (http://blog.naver.com/itioma?Redirect=Log&logNo=40040118386 ). 그 포스트에서 본 문제에는 아래의 조건들이 더 추가되어 있었습니다.

작성된 코드에서 한 글자만 수정해서 '숫자는 1씩 늘어난다’를 '숫자는 2씩 늘어난다’로 바꾸시오.
코드에서 한 문장만 수정해서 시작점 좌표(x,y)를 마음대로 바꿀 수 있도록 만드시오
코드에서 한 문장만 수정해서 시작할 때의 진행방향을 (위/아래/왼쪽/오른쪽 중에서 ) 바꿀 수 있도록 만드시오
배열의 크기를 마음대로 정할 수 있도록 만드시오.
코드에서 한 문장만 수정해서 '시계방향으로 90도’를 '반시계 반향으로 90’도로 바꾸시오
코드에서 swich 문이나 else 문을 이용한 3단계 이상의 조건분기가 있다면 모두 제거하시오.
코드에서 한 글자만 수정해서 '한칸씩 진행하며’를 두칸씩 건너뛰며’로 바꾸시오.
1~7에서 수정되었던 문장/값/변수들이모두 하나의 함수 또는 블럭안에 존재하도록 고치시오.

그리고 숫자는 1에서 시작하고 , 채워지지 않은 부분이 있다면 0으로 표시된다는 점이 제가 처음에 풀었던 문제와 다르네요.

확장된 조건을 다 수용할 수 있는 만족시키는 코드를 다시 한번 만들어보았습니다.

소스코드

public class MatrixMain {
    public static void main(String[] args) {
       System.out.println("0.원래의 matrix");
       ExtMatrix mp = new ExtMatrix(6,6);
       mp.print();

       System.out.println("1.숫자가 2씩 늘어나게");
       mp.setIncrement(2);
       mp.print();

       System.out.println("2.시작점을 1,1로");
       mp.setStartPoint(1, 1);
       mp.print();

       System.out.println("3.시작방향을 아래부터");
       mp.setStartDirection(ExtMatrix.DOWN);
       mp.print();

       System.out.println("4.배열크기 바꾸는건 생성할때 파라미터 바꾸면 됨.");
       System.out.println();
       System.out.println("5.반시계 반향으로 회전");
       mp.setReverseClockWiseTurn();
       mp.print();

       System.out.println("6.그런 조건 분기 없음.");
       System.out.println();

       System.out.println("7.한칸씩이 아닌 두칸씩 건너뛰며.");
       mp.setMoveStep(2);
       mp.print();
    }
}

public class ExtMatrix {
    public static final int RIGHT = 0;
    public static final int DOWN = 1;
    public static final int LEFT = 2;
    public static final int UP  = 3;

    private static final int INIT_VALUE = 0;
    private static final int CLOCK_WISE_TURN = 1;
    private static final int REVERSE_CLOCK_WISE_TURN = -1;

    private int m = 0;
    private int n = 0;
    private int startX = 0;
    private int startY = 0;
    private int[][] matrix;
    private int startDirection = RIGHT;
    private int increment = 1;
    private int moveStep = 1;

    private int turnDirection = CLOCK_WISE_TURN;


    public ExtMatrix(int m, int n){
        this.m = m;
        this.n = n;
        matrix = new int[m][n];
    }

    public void setIncrement(int increment){
        this.increment = increment;
    }

    public void setStartPoint(int startX, int startY){
        this.startX = startX;
        this.startY = startY;
    }

    public void setClockWiseTurn(){
        turnDirection = CLOCK_WISE_TURN;

    }

    public void setReverseClockWiseTurn(){
        turnDirection = REVERSE_CLOCK_WISE_TURN;
    }

    public void setMoveStep(int moveStep){
        this.moveStep = moveStep;
    }

    public void setStartDirection(int startDirection){
        this.startDirection = startDirection;
    }

    public void print(){
        locateNumbers();
        for (int i=0;i< m ;i++){
            for (int j=0;j<n;j++) System.out.print(matrix[i][j] + "\t");
            System.out.println();
       }
       System.out.println();
    }

    private void locateNumbers() \{
       init();
       int[] startPosition = new int[]\{startX,startY};
       matrix[startX][startY]= 1;
       int direction = startDirection;
       while(move(startPosition ,direction)) direction= getNextDirection(direction);
    }

    private void init(){
        for (int i=0;i< m ;i++){
            for (int j=0;j<n;j++) matrix[i][j] = INIT_VALUE;
        }
    }

    private boolean move(int[] position, int direction){
        int nowNumber = matrix[position[0]][position[1]];
        boolean moved = false;
        int[] nextPosition =getNextPosition(position,direction);
        while(isMovable(nextPosition[0],nextPosition[1])){
            moved = true;
            nowNumber+= increment;
            position[0] = nextPosition[0];
            position[1] = nextPosition[1];
            matrix[position[0]][position[1]]= nowNumber;
            nextPosition = getNextPosition(position,direction);
        }
        return moved;
    }

    private int[] getNextPosition(int[] position,int direction){
        int x = position[0];
        int y = position[1];
        if (direction == RIGHT) y+= moveStep;
        else if (direction == DOWN) x+= moveStep;
        else if (direction == LEFT) y-= moveStep;
        else if (direction == UP)  x-= moveStep;
        return new int[]\{x,y};
    }

    private int getNextDirection(int direction){
        direction+= turnDirection;
        if (direction<0) direction+=4;
        direction = direction %4;
        return direction;
    }

    private boolean isMovable(int x, int y){
        if (x>=m) return false;
        if (y>=n) return false;
        if (x<0) return false;
        if (y<0) return false;
        if (matrix[x][y]!= INIT_VALUE) return false;
        return true;
    }
}

방향을 int로 나타내는 것이 처음에는 좋은 아이디어 라고 생각했는데 mp.setStartDirection(ExtMatrix.DOWN); 부분을 보니 타입안전열거형이나 enum을 도입해야지 좀더 코드가 이뻐질 것 같네요.

Sybase 날짜형(datetime)의 문자열 변환시 style number

Mon, 17 Sep 2007 00:00:00 +0000

sybase에서 select convert(varchar,getdate(),112)로 찍어보면 오늘 날짜가 20070831 형식으로 나오죠. 이런 형식들이 정리된 자료를 한 번 만들어 보았습니다.

제가 쓰는 sybase 버전은 12.5.3입니다. (select @@version)으로 확인할 수 있죠)

select convert(varchar,날짜데이터, convertType)` 형식으로 쓰고 *convertType * 위치에 숫자가 들어갈 때 옆에 적힌 형식대로 나온다고 보시면 됩니다. 예시로 옆에 찍힌 날짜는 2007년 8월27일입니다.

Style number

0 = Aug 27 2007 5:28PM
1 = 08/27/07
2 = 07.08.27
3 = 27/08/07
4 = 27.08.07
5 = 27-08-07
6 = 27 Aug 07
7 = Aug 27, 07
8 = 17:23:35
9 = Aug 27 2007 5:28:08:563PM
10 = 08-27-07
11 = 07/08/27
12 = 070827
13 = 07/27/08
14 = 08/07/27
15 = 27/07/08
16 = Aug 23 2007 17:28:08
18 = 15:17:08
19 = 5:11:39:086PM
20 = 17:12:30:633
21 = 07/08/27
22 = 07/08/27
100 = Aug 27 2007 5:28PM
101 = 08/27/2007
102 = 2007.08.07
103 = 27/08/2007
104 = 27.08.2007
105 = 27-08-2007
106 = 27 Aug 2007
107 = Aug 27, 2007
108 = 17:28:08
109 = Aug 27 2007 5:28:08:563PM
110 = 08-27-2007
111 = 2007/08/27
112 = 20070827
113 = 2007/27/08
114 = 08/2007/27
115 = 27/2007/08
116 = Aug 23 2007 17:28:08

응용

select convert(char,GETDATE(),112) : 오늘날짜를 YYYYMMDD로
select convert(char(8), DATEADD(DD,-1,getdate()) ,112) : 현재 날짜 하루전을 yymmdd형식으로 출력
select convert(char(8), DATEADD(DD,-1,'20070827') ,112) : 2007년 8월 27일 전날을 출력. string → datetime은 convert라는 함수를 사용하지 않고 내부적(implicit)으로 자동으로 변경됩니다
select str_replace( convert(varchar,getdate(),20),':',null) : 현재 분일초,밀리세컨드까지: 152515853
select convert(varchar,GETDATE(),112) || str_replace( convert(varchar,getdate(),20),':',null) : 현재 연월일시분초밀리세컨드를 다 붙여서

CSS 선택자 정리

Thu, 6 Sep 2007 00:00:00 +0000

주로 Head first HTML/CSS에 있는 내용을 정리했습니다.

여러개의 element 선택

h1, h2 { }

class 선택자

p.greentea { } /* class가 greentea인 <p/> 선택 */

.greentea { } /* class가 greentea인 모든 태그 */

id 선택자

#footer {} /* id가 footer인 모든 태그 */

p#footer {}

자식(Child) element 선택

div h2 {color:red} /* <div/> 하위에 있는<h2/> 선택  */

.detail p {}   /* class가 "detail"로 지정되어 있는 하위의 <p/> 선택 */

상태에 따른 선택자

a:visited\{}

a:link \{}

상태는 active, hover, link, visited, first-child 등

의사(Psdudo) element 선택자

p:first-letter {}

p:first-line {}

속성(Attribute) 선택자

img[width] {border:black thin solid;} /* width 속성을 가진 모든 이미지 선택 */

img[height="300"] {border:red thin solid; } /* 값이 300인 height 속성을 가진 모든 이미지 선택 */

image[alt~="flowers"] {border:red thin solid; }  /* "flowers"라는 단어를 포함하는 alt 속성을 가진 모든 이미지 */

형제(Sibling) element 선택자

h1+p {}  /* <h1> 다음에 오는 <p> 선택 */

선택자 결합

div#greentea > blockquote {}  /* <blockquote/>의 부모가 되어야하는 "greentea" id를 가진 <div/> 자손 선택자 */

div#greentea > blockquote p {} /* <blockquote/>의 자손이자 "greentea" id를 가진 <div/>의 자손인 <p/> 선택 */

div#greentea > blockquote p:first-line /* 그 <p/>의 첫 줄 */

java의 List와 반복문(loop), 그리고 변수 선언 위치에 대해서

Fri, 3 Aug 2007 00:00:00 +0000

수정이력

2019/04/09

Github로 글 이전하면서 이미지, 첨부파일 내용 복원

2007/08/13

'들어가며', '마치며' 대폭 수정
오타 수정 : 여러개의 메소드에서 같이 써는 코드였었습니다.=⇒ 여러개의 메소드에서 같이 쓰는 코드였었습니다.

2007/08/09

첫 단락 소제목 변경 ( "ArrayList나 Vector에는 iterator가 성능이 더 안 좋다."에서 )

2007/08/08

소제목을 h3태그로
iterator를 쓸때 고려할 점 설명에 내용 보강
반복될 필요가 없는 코드의 예 설명에서 오타수정, 문장 다듬기
바이트 코드설명 부분의 한 문장 추가, 문장 다듬기

들어가며

저는 요즘 유지보수 프로젝트에서 일하고 있습니다. 많은 시간을 코드를 다듬는데 쓰고 있고 다른 개발자들의 코드를 많이 볼 수 있는 기회가 되고 있습니다. 그러다 보니 List의 크기만큼 반복문을 돌리는 코드에서 많은 개발자들은 루프 블럭 안에서만 쓰는 변수의 선언을 밖에다 하고 있다는 것을 발견하게 되었습니다. 이에 대해서 개발기간에 대화를 해볼 기회가 없었다는 것이 아쉽게 느껴지더군요. 그래서 그 내용과 함께 list와 loop에 관한 몇가지 이야기들을 같이 묶어서 글로 정리해 보게 되었습니다. 첫번째 소제목과 두번째 소제목 아래의 내용은 성능을 약간이라도 더 개선하고 싶을 때 도움이 될 정보들이고, 세번째 소제목에서 위에서 말한 많은 개발자들의 습관이 실제로는 성능에는 아무 영향이 없음을 설명할려고 했습니다.

ArrayList와 Vector는 RandomAccess inteface를 구현하고 있다.

List의 크기만큼 반복문을 도는 방법에는 크게 두 가지 방법이 많이 쓰이고 있습니다.

java.util.List의 size()로 크기를 구해서 그 갯수만큼 반복문을 돌아서 get(int index)로 List안에 있는 객체를 가지고 온다.
iterator() 로 java.util.Iterator 객체를 얻은 후 이 객체의 hasNext()가 true인 동안 반복문을 돌아서 next()로 List안의 객체를 가지고 온다.

그런데 그 객체가 java.util.ArrayList나 java.util.Vector가 확실할 때는 1번의 방법이 더 빠르다고 합니다. 그 이유는 API문서를 보시면 확인할 수 있듯이 ArryList와 Vector는 java.util.RandomAccess interface를 구현하고 있기 때문입니다. RandomAccess의 API문서에는 아래와 같이 적혀있습니다.

Marker interface used by List implementations to indicate that they support fast (generally constant time) random access.

List의 구현체가 빠른 임의접근을 지원한다는 것을 나타내는 표시 interface라는 말입니다. 선언되어 있는 메서드도 아무것도 없지요.

API문서에는 이렇게 적혀있지만 성능이 항상 우선순위의 가치는 아니므로 RandomAccess List에는 get(int index)을 써야 한다는 법칙을 만들 수는 없을 것입니다. 가령 List와 다른 Collection 객체, 배열 등을 한꺼번에 묶어서 처리할 때는 iterator pattern이 유용합니다. (참고자료5: Head first design pattern).

하지만 성능이 중요한 코드를 짜는 경우에는 객체를 생성하는 부분에서 ArrayList나 Vector를 생성한다는 정보를 확실히 가지고 있고, 그것이 LinkedList같은 다른 객체로 변경될 가능성이 없다면 java.util.RandomAccess interface의 명세는 무시할 수만은 없을 것입니다.

List 처리 시에 성능을 극대화 시키기 위해서 RandomAccess interface를 구현했는지 검사해서 get(int index)를 쓸지 iterator()를 사용할지 결정하는 코드도 있기는 합니다. (참고자료2의 자바퍼포먼스 튜닝 중). 보통 그렇게까지 성능을 쥐어짤 경우는 흔치 않겠죠.

List의 크기를 반복해서 구할 필요가 없다.

위에서 1번으로 제시된 것처럼 get(int index) 를 쓰는 방법을 쓸 때도 아래와 같은 코드를 많이 보게 됩니다.

for( int i = 0; i < list.size(); i++)\{

//일하기

}

흔하게 보는 코드죠? 그런데 위 코드에도 굳이 필요없는 성능의 손실이 있습니다. 바로 list의 크기를 구하는 size() 메서드가 매번 반복해서 호출된다는 것입니다. 반복문 내에서 list의 크기가 변하는 경우가 아니라면 for문의 초기화 때 한번으로 충분합니다.

for(int i = 0, n = list.size(); i < n; i++)\{

//일하기

}

n을 for문 앞에서 선언하는 방법도 있지만, for block 밖에서 n이 필요한 경우가 아니라면 n이 for의 초기화 부분에 선언되고 할당되는 것이 좋습니다. 변수의 유효범위가 최소화되기 때문이죠.

Loop안에서만 사용하는 변수의 선언을 loop밖에 해야 할까?

코드의 중복을 없애라거나 적절한 API를 쓴다거나 등의 바람직한 코드를 위한 지침에는 항상 다음과 같은 이유들이 붙어다닙니다.

코드의 가독성이 좋아진다.
유지보수가 편해진다.
오류의 발생 가능성이 줄어든다.

지역변수의 유효범위를 최소화하라는 지침에도 위의 이유들이 역시나 인용되고 있지요. (참고자료1 Effective Java, 참고자료 3 Code completed 2nd Edition). 변수의 선언과 초기화, 사용 사이에 있는 코드가 많을 수록 취약성 있는 코드가 들어갈 여지는 커집니다. 이른 시점부터 쓰이지도 않는 객체가 초기화되어서 메모리를 낭비하고 있을 가능성도 있고, 선언되고 한번도 쓰이지 않는 변수들도 눈에 잘 들어오지 않게 됩니다. (뭐 쓰이지 않는 변수는 Eclipse의 warning으로 잡아낼수 있기는 합니다만)

지역변수를 쓰기 바로 전에 초기화하고, 선언과 함께 초기화 하는 좋습니다. 즉 가능한 변수가 처음 사용되는 곳의 가장 근접한 위치에서 선언되고 초기화되어야 한다는 말이죠. 변수의 수명을 가능한 짧게 유지하라는 말로도 표현됩니다. 하지만 많은 개발자들은 메소드의 처음에서 C언어처럼 쭉 변수를 선언하고 시작하고 있습니다.

반복문에서는 while보다는 for를 쓰는 것이 변수의 범위관리에 유리합니다.

보통 iterator와 while이 아래와 같이 많이 쓰이고 있습니다.

Iterator i = c.iterator();

while (i.hasNext())\{

 doSomething(i.next());

}

이 것을 for문으로 쓴다면 다음과 같습니다.

for (Iterator i = c.iterator() ; i.hasNext(); ) {

 doSomething(i.next());

}

작은 차이지만 Iterator i는 for block을 벗어나는 순간 잊어버려도 되는 것이니 block 밖에서 개발자의 머리는 조금이나마 가벼워 질 수 있습니다. 이것은 캡슐화의 원칙인 class의 맴버 중 밖에서 볼 필요 없는 것들은 private으로 선언해야 하는 이유와 일맥상통합니다.

그렇다면 다음의 경우는 어떠할 까요?

1.루프밖에서 list에서 꺼내서 담을 변수 선언

    static int countOfIncluded(List list, String str){
        int count = 0;
        String element;
        for (int i=0,n=list.size();i<n;i++)\{
           _*element = (String) list.get(i);*_
            if (element.indexOf(str)!= -1 ) count++;
        }
        return count;
    }

2.루프안에서 list에서 꺼내서 담을 변수 선언

    static int countOfIncluded(List list, String str){
        int count = 0;

        for (int i=0,n=list.size();i<n;i++){
            String element = (String) list.get(i);
            if (element.indexOf(str)!= -1 ) count++;
        }
        return count;
    }

많은 분들이 1번과 같이 코드를 작성하고 있고, 1번이 성능이 좋다는 '믿음’을 가지고 계실 것입니다. 실제로 한 번 테스트 해볼까요? 크기가 10000개인 리스트를 생성해서 100번씩 반복해서 실행시간을 찍어보는 코드를 만들어보았습니다. 1번 방법은 ListReader1.java, 2번 방법은 ListReader2.java, 시간을 찍어보는 코드는 LoopTester.java 로 첨부하였습니다. 이런 비교 시에는 실행순서에 따라서도 실행시간이 영향을 받으므로 1,2,2,2,1,1,2의 순서로 몇번씩 사이에 걸린 시간을 밀리세컨드로 출력하게했습니다. 실행결과는 다음과 같았습니다.

test1:밖에 선언 2243 test2:안에 선언 2153 test2:안에 선언 2184 test1:밖에 선언 2253 test1:밖에 선언 2213 test2:안에 선언 2123

거의 차이가 없거나 오히려 안에 선언한 쪽이 미묘하게 빠르기도 합니다.

이번에는 javap -c 를 이용해서 컴파일된 byte 코드를 분석해 보겠습니다.

> javap -c ListReader1

Compiled from "ListReader1.java"
public class looptest.ListReader1 extends java.lang.Object{
public looptest.ListReader1();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

static int countOfIncluded(java.util.List,java.lang.String);
  Code:
   0:   iconst_0
   1:   istore_2
   2:   iconst_0
   3:   istore  4
   5:   aload_0
   6:   invokeinterface #2,  1; //InterfaceMethod java/util/List.size:()I
   11:  istore  5
   13:  iload   4
   15:  iload   5
   17:  if_icmpge       50
   20:  aload_0
   21:  iload   4
   23:  invokeinterface #3,  2; //InterfaceMethod java/util/List.get:(I)Ljava/la
ng/Object;
   28:  checkcast       #4; //class String
   31:  astore_3
   32:  aload_3
   33:  aload_1
   34:  invokevirtual   #5; //Method java/lang/String.indexOf:(Ljava/lang/String
;)I
   37:  iconst_m1
   38:  if_icmpeq       44
   41:  iinc    2, 1
   44:  iinc    4, 1
   47:  goto    13
   50:  iload_2
   51:  ireturn

}

javap -c ListReader2
Compiled from "ListReader2.java"
public class looptest.ListReader2 extends java.lang.Object{
public looptest.ListReader2();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

static int countOfIncluded(java.util.List,java.lang.String);
  Code:
   0:   iconst_0
   1:   istore_2
   2:   iconst_0
   3:   istore_3
   4:   aload_0
   5:   invokeinterface #2,  1; //InterfaceMethod java/util/List.size:()I
   10:  istore  4
   12:  iload_3
   13:  iload   4
   15:  if_icmpge       49
   18:  aload_0
   19:  iload_3
   20:  invokeinterface #3,  2; //InterfaceMethod java/util/List.get:(I)Ljava/la
ng/Object;
   25:  checkcast       #4; //class String
   28:  astore  5
   30:  aload   5
   32:  aload_1
   33:  invokevirtual   #5; //Method java/lang/String.indexOf:(Ljava/lang/String
;)I
   36:  iconst_m1
   37:  if_icmpeq       43
   40:  iinc    2, 1
   43:  iinc    3, 1
   46:  goto    12
   49:  iload_2
   50:  ireturn

}

노란 줄이 많은 것은 라인수가 1라인 차이가 나고, local variable이 저장되는 공간의 index번호가 달라서입니다. 내용을 보시면 거의 똑같이 실행되고 있는 것을 알 수 있으실 것입니다. 루프가 도는 goto문장을 봐도 (왼쪽의 47라인과 오른쪽의 46라인) 같은 곳으로 (13라인과 12라인)으로 이동을 하기 때문에 특별히 오른쪽 예제2의 경우가 더 일을 하는 것은 없습니다. 다만 3번째 라인 istore n 이였던 것이 istore_n 으로 바뀌는 등 언더바(_)가 들어간 부분이 있습니다.

각각의 명령어의 의미는 다음 링크를 확인해 보시면 나와있습니다.

내용을 보면 istore과 istore_n은 전자가 암시적이라는 것만 빼고는 같다고 나옵니다. (Each of the istore_<n> instructions is the same as istore with an index of <n>, except that the operand <n> is implicit. ) iload의 경우도 마찬가고요. 어떤 차이가 있을까 해서 검색해 봤더니 아래와 내용을 발견했습니다.

'istore_<n>' is functionally equivalent to 'istore <n>', although it is typically more efficient and also takes fewer bytes in the bytecode

원본링크

istore_n 쪽이 오히려 효율적이라는 말이 나와 있습니다. 만약 iload_n도 마찬가지라면 goto가 찾아가는 라인에서는 iload_n이 있는 예제2가 더 효율적인 코드일 수도 있다는 것입니다. 어쨓든 이런 작은 차이를 접어둔다면 코드가 하는 일의 절차는 차이가 없습니다.

결국 "루프 안에서 반복되는 변수 선언을 밖으로 빼는 것은 성능상에 아무런 이점이 없고 소스에서 변수의 유효범위만 늘어나게 한다. " 는 것입니다.

여기서 이런 말을 하실 분이 계실 것 같습니다.

"원래는 변수를 loop안에 생성하는 루프가 돌 때마다 String 객체의 참조를 저장하기 위한 공간이 따로 할당되는 것인데 위의 경우는 JVM에서 최적화를 해 준 것 아니냐? JVM에 따라서 이런 최적화가 안 되는 버전도 있을 수가 있는데 개발자는 어떤 JVM에서도 한번만 선언이 되도록 루프 밖에 변수를 선언해야 하지 않겠냐? "

그러나 Java™ Virtual Machine Specification, The, 2nd Edition 이라는 책을 보면 다음과 같은 내용이 있습니다.

The sizes of the local variable array and the operand stack are determined at compile time and are supplied along with the code for the method associated with the frame .

위의 문장은 메소드가 호출될 때 생성되는 저장공간인 frame에 대한 설명에서 인용한 것입니다. (원문링크 : http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html#15722)

풀이하면 메소드 안의 local variable들의 값들은 고정된 크기의 배열에 저장되고 그 배열의 크기는 compile시에 결정된다는 내용이 있습니다. 즉 한 메소드 안에서 사용할 local variable이 저장될 공간의 갯수는 이미 compile 시에 정해져 있는 것이지 동적으로 변하는 것이 아니라는 말입니다. 만약 위의 소스에서 list의 갯수에 따라서 local variable의 값이 저장되는 공간(객체가 저장되는 공간을 가리키는 말이 아닙니다.)이 달라진다면 위의 설명과 모순되는 일입니다.

http://forum.java.sun.com/thread.jspa?threadID=707455&messageID=4098210

비슷한 설명과 논쟁이 인터넷의 여러 곳에서 이미 벌어졌으니 아래의 링크를 읽어보셔도 재밌을 것입니다.

local variables in Java : http://rmathew.blogspot.com/2007/01/local-variables-in-java.html
Myth - Defining loop variables inside the loop is bad for performance : http://livingtao.blogspot.com/2007/05/myth-defining-loop-variables-inside.html
http://forum.java.sun.com/thread.jspa?threadID=707455&messageID=4098210http://forum.java.sun.com/thread.jspa?threadID=707455&messageID=4098210
http://weblogs.java.net/blog/ddevore/archive/2006/08/declare_variabl_1.htmlhttp://weblogs.java.net/blog/ddevore/archive/2006/08/declare_variabl_1.html
http://www.theserverside.com/news/thread.tss?thread_id=41857

http://weblogs.java.net/blog/ddevore/archive/2006/08/declare_variabl_1.html

1,2번 링크가 바이트코드 역어셈블 결과와 함께 내용을 잘 풀어서 설명하고 있습니다. 3번 링크에서 Dru Devore는 primitive type일 때는 똑같고 Object type일때는 다르다는 결론을 쓰고 있으나, 사실 그가 든 object type의 예제는 '객체를 한번 생성하느냐' 대 '반복해서 생성하느냐'의 문제이므로 경우가 다릅니다. 3번 링크의 댓글에서 다른 사람들도 그 점을 지적하고 있고 2번 링크의 글에서도 관련 설명이 있습니다. 어쨓든 루프밖에 있으나 안에 있으나 바이트코드의 실행과정은 같고 성능은 차이가 없다는 내용은 모든 페이지에 다  있군요.

이런 오해들은 전에 Java의 호출은 pass by value 에서 말했던 객체선언에 대한 오해와 어느 정도 관련이 있다고 봅니다. 객체를 생성이나 사용을 안 하더라도 선언 자체만으로 저장을 위한 큰 공간이 할당된다고 믿는 경우가 많은 것 같습니다.

전에 이런 코드를 본적이 있습니다. 클래스의 멤버 변수로 임시 객체를 생성해 놓고 그것을 여러개의 메소드에서 같이 쓰는 코드였었습니다.

Class MyClass {
    String  temp;

    void work(List list){
        for (int i=0; i = list.size(); i++)\{
            temp = (String) list.get(i);
            //기타...
        }
    }

    void play(List list)\{
        for (int i=0; i = list.size(); i++)\{
            temp = (String) list.get(i);
            //기타...
        }
    }

}

이런 코드를 짰던 사람도 경력도 어느 정도 되고, 실력도 있어보이는 사람이였죠. 아마 이 개발자는 이런 구조가 temp 객체가 저장될 공간을 상당히 아꼈다는 뿌듯함을 가지고 있었을 지도 모릅니다. 그러나 객체는 Heap 메모리에 있는 것이기에 지역변수가 선언이 하나 덜 되었다고 해서 객체가 줄어든 것은 아닙니다. 그리고 여기서는 list에서 받아오지 새로 생성되는 객체는 없습니다. 더군다나 설계상 의미로도 temp는 Class의 멤버로써 아무런 의미가 없습니다. 성능측면에서 봐도 클래스 멤버 변수는 지역변수에 비해서 더 비용이 큽니다. (참고자료 2: 자바 퍼포먼스 튜닝)

한편으로는 변수의 범위를 줄인다고 해서 반복적으로 Loop 안에서 실행해줄 필요가 없는 작업까지 loop안으로 끌고 들어가서는 안되겠죠. 다음과 같은 코드를 본적이 있습니다.

for (int i=0, n=userList.size(); i<n;i++)\{

    UserBiz biz = (UserBiz) lookup(UserBiz.ROLE);#*_ //비지니스 컴포넌트 객체를 얻어온다.
    User user = (User)userList.get(i);
    biz.add(user;
 }

위의 코드에서 비지니스 컴포넌트를 얻어오는 부분은 반복적으로 수행될 필요가 없으므로 loop 밖으로 나가는 것이 맞습니다. 위의 biz 객체를 loop안에서만 쓴다고 하여도 위와 같이 해당 코드가 안으로 들어가 있다면 한번만 얻어오는 되는 객체를 얻어오는 작업이 계속 반복될 것 입니다. 사실 위의 경우는 비지니스 객체에서 List를 받아서 처리하는 메소드를 하나 더 만드는 것이 나을 것 같네요. 아키텍쳐에 따라 다르지만 비지니스 객체의 호출은 비싼 작업일 경우가 많고 그런 호출의 횟수는 최대한 줄일수록 좋겠죠.

개선된 for문

Java 5의 개선된 for문을 아시는 분이라면 아래의 방법을 많이 쓰실 것입니다.

ArrayList<Integer> list = new ArrayList<Integer>();

for (Integer i : list) \{ … }

( J2SE 5.0 in a Nutshell 에서)

보기에도 이쁘고, 변수의 유효범위가 loop을 벗어나지도 않는 좋은 문법이네요. ^^ 프로젝트에서 Java 5 이상을 쓰시고 계신다면 변수를 loop안에 넣느냐로 논쟁하기 전에 개선된 for문을 먼저 적용해 보는것이 나을 것 같습니다.

마치며

위의 내용을 묶어서 결론을 내리자면, "loop안에서만 쓰는 변수 선언을 밖으로 빼는 것은 성능에 아무런 영향이 없으며, 굳이 성능을 개선하고 싶다면 RandomAccess 인터페이스의 고려, 반복되는 list크기 계산의 제거 등을 먼저 신경쓰라. 그리고 Java5을 쓰고 있다면 개선된 for문을 쓰라."는 것으로 정리하고 싶습니다.

사실 성능에 대한 고려는 병목이 발견될 때 필요하다면 하는 것이 바람직한 순서겠죠. 개발자는 알아보기 싶고, 관리하기 쉬운 코드를 짜는 것에 먼저 집중을 해야 할 것입니다. 그리고 고용량의 CPU가 돌아가는 환경이라면 개발자가 성능을 고려해서 짠 코드와 그렇지 않은 코드의 차이도 대부분 사람이 인지하지 못하는 정도의 미미한 것일 가능성이 높습니다. (TA팀 이상민 선임님의 테스트와 조언). 그런 점에서 본다면 이 글에서 가장 강조되어야 할 내용은 '변수의 유효범위의 최소화’라고 생각됩니다.

다른 분들이 추가로 자료를 찾는 번거로움을 덜어 드릴려고 관련 자료를 되도록 인용하고 링크를 걸었습니다. 그렇게는 했어도 혹시나 제가 잘못 이해해서 오류가 있는 부분이 있는지도 모르겠습니다. 고수분들은 그런 부분을 발견하신다면 즉각 지적해 주시기 바랍니다~ ^^

그리고 이 글은 계속적으로 갱신해서 개선을 하고 있는 중입니다. 제가 가입해 있는 커뮤니티 사이트 중 두 곳에도 이 글을 올렸는데, 거기에서 조언을 주신 많은 분들께도 감사드립니다.

참고자료

Java API문서와 링크외의 책에서 참고한 내용입니다.

Effective Java , Joshua Bloch저 이해일역
- 7장 프로그래밍 일반 - 항목29 - 지역변수의 유효범위를 최소화하라.
자바퍼포먼스 튜닝, Jack Shirazi 저 서민구 역
11장 적절한 자료구조와 알고리즘
- 질의 최적화 - 불필요한 반복적 메소드 호출 제거
- RandomAccess 인터페이스
6장 예외 단언, 캐스팅, 변수 - 변수
Code completed 2nd Edtion, Streve McConnell 저 서우석 역
- 10장 변수사용시 일반적인 문제 - 10.3 변수의 초기화에 대한 지침
Head First Design Pattern
- 9장 이터레이터와 컴포지트 패턴

구글 검색 기록과 스위칭 코스트

Tue, 31 Jul 2007 00:00:00 +0000

많은 분들이 그렇듯이 저도 생활정보는 네이버로 찾고 일과 관련된 정보나 웹을 구석구석 뒤지고 싶을 때는 google을 쓰고 있습니다. google을 써오기는 해도 "검색기록"이라고는 것을 신경도 안 쓰고 있었는데, 얼마 전에 한번 찍어보니 꽤나 신기하더군요.

http://www.google.co.kr/history/

이 기능을 의식을 하고 쓴 것은 아니였는데 , 제가 어떤 키워드로 검색을 했는지 오래전의 기록부터 쫙 나오니깐 기분이 묘했습니다. 상위질문, 상위사이트, 상위클릭, 월별 일별 통계까지 나오니 좀 섬뜻하기도 했어요 삭제하고 싶은 키워드도 있는데 어떻게 삭제하는지 모르겠습니다 ^^;다음부터는 기록에 남기고 싶지 않는 검색어는 "일시중지"를 선택하고 검색해야겠군요. 얼마 전에 "구글, 사용자 검색기록 보관기간 18개월로 단축 " 이라는 기사를 보았었는데, 정말 이것이 축적되면 무서운 도구가 될 수도 있을 것 같아요. 찜찜하신 분들은 구글에서 로그인하지 않은 상태로 검색하거나 기록 기능을 꺼야겠죠.

검색기록의 첫 페이지에 나와 있는 다음의 문구가 눈에 띕니다.

맞춤 검색은 Google 검색을 개선한 기능으로서 이전의 검색을 토대로 귀하의 검색 결과를 표시합니다. 처음에는 큰 차이를 느낄 수 없지만 검색 기록이 축적되면서 맞춤 검색 결과가 지속적으로 향상됩니다.

이번달 16일, jmirror님이 주최하신 '차세대 검색에 대한 블러거 토론회'에 참석했습니다. 저는 특별한 발언없이 경청만 하다 왔지만, 다른 분들의 깊이 있는 말씀을 듣고 생각을 정리해볼 수 있는 자리였습니다. 거기서 몇몇 분들이 '검색의 개인화’가 앞으로 필요하다고 말씀하셨습니다. 그 때 저는 그 실제 적용 사례가 생각나지 않았었는데, 바로 이 구글의 검색기록을 한 번 찍어보고 갔었더라면 위의 화면이 머리 속에서 연결이 되었을건데 하는 아쉬움이 지금에서야 듭니다.

위의 토론회에서 들은 말인데, 구글이 유투브 동영상 검색에서 야후를 야후의 동영상 검색을 누르는데 걸린 시간은 6주였고, 국내 3위 업체였던 네이버는 지식검색으로 야후, 엠파스를 4주만에 추월했다고 합니다. 그렇게 짧은 시간내에 그것이 가능했던 이유는 검색엔진을 바꾸는 것에 대한 이사비용(스위칭코스트)이 거의 없기 때문이 아닐까 합니다. 메일, 블로그,커뮤니티의 경우에는 서비스를 바꾼다면 데이터 이전, 바뀐 주소 홍보 등의 번거로움을 감수해야하는 것에 비해서 검색은 그렇지 않다는 것이죠. 그리고 검색결과의 상호비교가 쉽기 때문에 조금이라도 나은 점이 보이는 서비스로 지체없이 옮겨갈 수 있습니다.

검색에서도 구글 검색 기록과 같이 쌓여가는 데이터가 있고, 그것을 바탕으로 개인화된 서비스를 제공할 수 있다면 스위칭코스트를 낳을 수 있다고 봅니다. 그리고 개인 검색기록 데이터를 쌓고 그 것을 바탕으로 개인화된 검색결과를 내놓을 수 있는 기술은 쉽게 따라할수 있는 일이 아닐 것 같아요. 네이버에 있는 지식인의 자료, 광고, 알바가 정리한 정보도 큰 자산이지만 그것만으로 사용자를 완벽히 묶어둘 수는 없지 않을까요?

AOP 관련 용어 정리

Thu, 19 Jul 2007 00:00:00 +0000

부서원들과 같이 하는 세미나를 위해서 정리했었던 자료 중의 일부입니다. 대충 알고 있었던 것도 막상 누가 물어보면 한마디로 설명하는 것은 어렵다고 종종 느낍니다. 세미나 발표 준비를 하면서 모르면서 알고 있었다고 착각했던 부분을 많이 발견할 수 있어서 좋았습니다.

약간 엉뚱한 이야기지만, 포스트를 작성하는 동안 '그림1’을 다시 보면서 최근 읽고 있는 'The world is flat'이라는 책의 내용이 생각났습니다. 그 책의 처음에는 기업의 아웃소싱에 대한 사례가 많이 나옵니다. 기업의 핵심 업무가 아니고 밖에서 할 수있는 업무들은 보다 싼 비용으로 처리할 수 있는 해외의 조직으로 넘기는 사례가 늘어나고 있다는 것이죠. 각 업무단의 코드에는 핵심로직만 남기고 공통적인 처리는 따로 정의해 둔 것을 weaving해서 쓴다는 내용과 왠지 비슷하게 보이더군요. (그런데 책을 아직 1장 밖에 못 읽었어요)

AOP 용어

AOP :보안, 예외등과 같이 프로그램에 처리해야 하는 다양한 관점을 분리(Separation of concerns)시키고 각각의 관점별로 구현을 한 후 이를 조합하여 완성된 프로그램을 만들고자 하는 개념. (참고자료1)
횡단관점(crosscutting concerns) : 분리된 모듈로 작성하기 힘든 시스템 전반적으로 산재된 기능(예로 보안, 로그, 인증)
핵심관점(main concern) : 해당시스템의 핵심가치와 목적이 드러난 관심영역 (primary concern, core concern)
조인포인트(join point) : 횡단 관심모듈의 기능이 삽입되어 호출될 수 있는 실행가능한 특정위치
포인트컷(point cut) : 조인포인트의 집합. 어떤 클래스의 어느 조인포인트를 사용할 것인지 결정하는 선택 기능. Code와 advice를 연결해주는 설정정보.
어드바이스(advice) : 각 조인포인트에서 행하는 행위, 삽입될 수 있는 코드. cross-cutting concern을 구현한 코드.
조합(weaving) : 핵심관점코드와 어드바이스를 조합해 애플리케이션으로 완성하는 과정
기술적 용어로서의 asepct : Advice와 point-cut을 함께 지칭하는 단어

참고자료

마이크로소프트웨어 2005/11 테크니컬 컬럼 - 객체지향을 넘어 관점지향으로 AOP (이일민) (http://www.zdnet.co.kr/builder/dev/java/0,39031622,39147106,00.htm )
마이크로소프트웨어 2006/09 S/W로 여는 세상 - 관점지향의 개념잡기 -상황중심의 프로그래밍 (임백준) (http://www.zdnet.co.kr/builder/dev/etc/0,39031619,39154322-1,00.htm)
3번 자료에 대한 반론 - http://toby.epril.com/?p=229 (이일민님의 블로그)
마이크로소프트웨어 2007/03 Cover Story- OOP한계 극복패러다임 AOP (이일민,김백기,박재성, 류대원)
한빛네트워크에 올라온 AOP소개 기사 : http://network.hanb.co.kr/view.php?bi_id=968
위키페디아

로그인별 process 숫자를 집계하는 sybase 쿼리

Tue, 10 Jul 2007 00:00:00 +0000

sa 계정으로 로그인해서,

select
    p.hostname,
    p.ipaddr,
    p.cnt,
    (select l.name from syslogins l where l.suid = p.suid) name
from
    (select s.hostname, s.ipaddr, s.suid,
        count(*) cnt from sysprocesses s
group by s.hostname, s.ipaddr ,s.suid ) p

현재 어느 로그인 아이디에서 많이 프로세스가 붙어있는지 볼 때 쓰면 됩니다. 내장 함수 중에 비슷한게 있는지 모르겠네요.

간단한 내용이지만 필요하신 분들이 검색엔진을 타고 오셔서 찾아가시길 바라는 의도에서 올립니다.

HTML & CSS 정리해본 예

Wed, 4 Jul 2007 00:00:00 +0000

제가 있는 프로젝트의 UI 표준은 2004년 10월경에 처음 정해졌습니다. 연속 사업 중 첫 번째 사업 때 정해진 틀을 수정없이 Copy&paste로 입혀서 쓰고 있는 중이였습니다. 디자이너가 HTML로 파일을 만들어 주었을 당시에는 팀원 중에 웹표준에 대해서 신경을 썼던 사람이 없었습니다. 지금 다시 들여다보니 CSS를 잘 정의했으면 훨씬 깔끔하게 중복없이 만들수 있었던 코드가 많이 보입니다.

저도 작년에 파주시 프로젝트에서 웹표준에 맞춰서 개발을 하고 있다는 말을 듣기 전까지는 스스로 css를 정리해볼 생각은 없었습니다. 그런 작업은 디자이너의 영역이라고 안이한 생각을 했었습니다. 새로 프로젝트 들어가면 깔끔하게 UI표준 만들어주는 사람을 만나기를 바라는 마음만 있을 뿐이였습니다. 그러다가 정동인씨나 최효근씨 같은 후배들에게 배우고 느낀 바가 많아서 저도 현재의 프로젝트에서도 서서히 적용하겠다는 의지를 가지게 되었습니다.

이번에 고객이 다른 업무와 독립적으로 쓰여질 프로그램을 요청했는데, 그 페이지에는 새로운 CSS를 만들어서 적용하고 싶었습니다. 현재 프로젝트에 남은 3명의 인원만으로는 모든 페이지를 다 갈아 엎는 것은 무리라고 생각했었는데 적당한 시작점을 찾은 것이였습니다.

처음 수정한 부분은 화면의 큰 제목과 하위 제목이였습니다.

와 같이 보여지는데, 기존 코드로는

<table border="0" cellpadding="0" cellspacing="0" width="100%">
 <!-- 제목 -->
 <tr>
  <td>
   <table border="0" cellpadding="0" cellspacing="0" width="100%">
    <tr><td class="title1"><img src="/image/title_header.gif" align="absmiddle">&nbsp;감사사항 목록</td></tr>
    <tr><td class="tilte_space"></td></tr>
    <tr><td class="title_line"></td></tr>
    <tr><td class="tilte_space"></td></tr>
   </table>
  </td>
 </tr>
 <!-- 조회조건 -->
 <tr>
  <td>
   <table border="0" cellpadding="0" cellspacing="0" width="100%">
    <tr>
        <td align="left" class="title_small">
            <img src="/image/title_small.gif" align="absmiddle">&nbsp;조회조건
        </td>
    </tr>
   </table>
  </td>
 </tr>

로 나와있는 부분입니다. CSS를 새로 만들고 나니 마크업은 아래와 같이 딱 두줄로 바꿀수가 있었습니다.

  <h1>감사사항 목록</h1>
  <h2>조회조건</h2>

CSS에 다음과 같이 배경이미지, 선 등을 넣어서 정리했습니다. 매 페이지마다 반복되는 글자 앞의 이미지, 선과 여백을 위한 table, tr, td 문장들이 모두 정리됩니다.

h1 {
  font-size:14px; color:#5C5C5C;
  font-family: 돋움, arial;
  font-weight:bold;
  height:14px;
  padding-left: 20px;
  padding-bottom: 10px;
  margin: 10px 10px 2px 10px;
  background-image: url(/image/title_header.gif);
  background-position: 0% 10% ;
  background-repeat: no-repeat;
  border-color:#C0C3C6;
  border-width:1px;
  border-bottom-style: solid;
}

h2 {
  font-family: 돋움, arial;
  font-weight:bold;
  font-size:12px;
  height:13px;
  color: #4f4f30;
  padding-left: 20px;
  margin-bottom: 4px
  padding-bottom: 10px;
  margin: 10px;
  background-image: url(/image/title_small.gif);
  background-position: 0% 0% ;
  background-repeat: no-repeat;
}

그리고 새로 개발되는 화면에 좌측 메뉴부분이 있는데, css에서 float:left 선언을 이용하니 table없이 레이아웃을 잡을 수가 있었습니다. 웹표준을 설명하는 자료에서 많이 드는 예제이죠. 반복되는 class 지정에도 선택자를 잘 활용하면 클래스 지정없는 태크만으로 처리할 수 있는 부분이 많아보였습니다.

이제 기초적인 것을 적용시킨 것 뿐이고 제가 공부할 것이 아직 많아서 갈 길이 멀다는 기분이에요. 그래도 간결한 jsp를 보니 몇달만에 방청소 했을 때보다 더 속이 시원합니다.

그동안 UI단 코드의 중복에는 지나치게 관대하게 살아왔었다고 반성했습니다.

웹표준 관련 권장 자료

(부서 후배 최효근씨가 추천해준 자료입니다)

한국소프트웨어진흥원의 실전웹표준가이드
Head First HTML(XHTML, CSS) -한빛미디어-
실용예제로 배우는 웹표준 -에이콘- // 본격적인 활용기
웹2.0을 이끄는 방탄웹 -에이콘- // 아이디어가 넘치는 책
CSS 마스터 전략 -에이콘-
CSS designing without tables -sitepoint-(원서) // 무릎을 탁 치게 되는 책
CSS the css anthology -sitepoint-(원서)

코드와 예술

Fri, 1 Jun 2007 00:00:00 +0000

CCK(Creative Commons Korea)의 'Code can be an art.' 행사 소식을 처음 들었을 때, 생각났던 자료들을 정리해서 올려봅니다.

다음은 임백준님의 책 '누워서 읽는 알고리즘' 중 '문학적 프로그래밍’이라는 장에서 소개 된 내용입니다. Art of computer proramming으로 유명한 카누스 교수가 1974년 11월 미국 샌디에이고에서 열린 ACM(Association for computer Machinery) 연례회의에서 '예술로써의 컴퓨터 프로그래밍(Computer programming as an Art)라는 제목의 강연을 했다고 합니다. 그 강연은 다음과 같은 말로 끝이 맺어졌습니다.

우리는 컴퓨터 프로그래밍을 하나의 예술로 생각한다. 그것은 그 안에 세상에 대한 지식이 축적되어 있기 때문이고 기술과 독창성을 요구하기 때문이고 그리고 아름다움의 대상을 창조하기 때문이다. 어렴풋하게나마 자신을 예술가라고 의식하는 프로그래머는 스스로 하는 일을 진정으로 즐길 것이며, 또한 남보다 더 훌륭한 작품을 내놓을 것이다.

We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak about the state of the Art.

위 강연의 PDF파일을 찾았는데 7페이지 밖에 안 되는군요. 이정도면 출력해서 퇴근길에 읽어볼만 한것 같습니다.

http://faq.ktug.or.kr/faq/LiterateProgramming?action=download&value=knuth-turingaward.pdf

그리고 1992년에 출판된 책 '문학적 프로그래밍(Literate Programming, Center for the Study of Language and Information,1992)은 카누스 교수의 논문과 '생각하는 프로그래밍’의 저자 존베틀리의 칼럼이 묶여진 책입니다. 이 책의 서문은 다음과 같습니다.

컴퓨터 프로그램을 작성하는 일은 재미있다. 그리고 잘 작성된 프로그램을 읽는 것도 재미있다. 세상에서 가장 즐거운 일 중 하나는 여러분이 작성한 컴퓨터 프로그램을 다른 사람들 혹은 여러분 자신이 읽고 기쁨을 얻는 것이다. 컴퓨터 프로그램은 또한 유용한 작업을 수행할 수도 있다. 세상에서 가장 큰 성취감을 맛보는 순간은 여러분이 창조한 무엇이 사회의 부와 진보에 기여한다는 사실을 깨닫는 순간이다. 어떤 사람들은 컴퓨터 프로그램을 작성함으로써 돈을 벌기도 한다. 따라서 프로그래밍은 세 가지 측면에서 결실을 맺는 행위다. 미학적으로, 인류학적으로 그리고 경제적인 면이 바로 그러한 결실에 해당한다.

카누스 교수의 관련 논문도 PDF파일로 구할 수 있었습니다. http://faq.ktug.or.kr/faq/LiterateProgramming?action=download&value=knuthweb.pdf

얼마 전에 '문장강화'(이태준 저)라는 글쓰기에 관한 책을 읽었습니다. 1940년에 처음 나온 책임에도 불구하고 아직까지 이 책을 넘어서는 글쓰기 공부책이 없다고 말하는 사람이 많더군요. 책에 들어간 예문이 다 옛날 글이라는 것이 아쉽지만, 그럼에도 이 책이 그런 찬사를 받는 것에는 그럴만한 이유가 있다고 느껴졌습니다. 제가 제일 감탄을 했던 내용은 글을 고쳐서 다듬는 '퇴고’에 대한 예시였습니다. 저자는 얼핏 보기에 별 흠이 없어 보이는 문장을 점차적으로 고치는 과정을 보여줍니다. 그 부분을 읽을 때 저는 마틴파울러가 쓴 책 '리팩토링' 제1장을 읽을 때와 굉장히 흡사한 느낌을 받았습니다. 퇴고가 코드를 리팩토링하는 것과 비슷하게 느껴진 것이죠. 유심히 안 보면 이상 없어 보이는 코드나 문장들이 여러 관점에서 따져가니 고칠 점이 투성이인 것들이었습니다. 그리고 고쳐진 최종결과물들은 처음에 비해서 훨씬 명확하고 이쁜 코드와 문장들이였고요. 그때 다시 한번 코드와 문학, 넓게는 예술과 유사점이 있다는 것을 떠올렸습니다.

많은 분들이 아시겠지만 '해커와 화가’라는 책에서는 미술과 프로그래밍의 유사점을 이야기하고 있습니다. 이 책의 저자인 폴그레이엄은 특이하게도 미술과 전산을 같이 전공한 사람입니다. 그 예 중의 하나가,세계적인 명화들을 엑스레이 투시해보면 그 아래에는 수많은 스케치 후에 많은 시행착오를 거친 선의 흔적들이 남아있다고 합니다. 코딩도 마찬가지의 과정을 거치는 것이고, 그것을 죄악시 할 필요가 없다고 저자는 이야기합니다. 저도 자바 코딩을 할 때 처음에는 전체의 클래스 선언과 비어있는 메소드부터 만들어서 틀을 잡은 다음에 나중에 메서드 안의 내용을 구체적으로 채워넣을 넣는 순서로 진행을 합니다. 그러고보니 그것이 스케치하는 것과 비슷하게도 느껴지더군요.

재미있게도 이외수님의 '글쓰기의 공중부양’이라는 책에도 비슷한 내용이 나옵니다. 여기서 저자는 글을 쓸 때 처음부터 한꺼번에 모든 부분을 구체적으로 쓸려고 하지말고 글 전체의 틀을 구어체로 스케치한 후에 나중에 세부묘사를 채워넣으라고 합니다. 인물화를 그릴 때 처음부터 이목구비의 정밀묘사를 하면서 그려나간다면 나중에 이목구비가 따로 노는 그림이 된다는 비유가 나오더군요. 이렇게 그림,글, 코딩이 다 통하는게 있나봅니다.

전 한때는 코딩 혹은 프로그래밍은 예술이라는 말이 지나치게 순진하다고 느껴졌었기에 밖으로 꺼내기에는 민망하다고 느낀 적도 많았습니다. 개발자 커뮤니티 사이트에 이런 글이 올라간다면 '코딩은 노가다인 걸 아직 모르냐?','고생을 덜해봤냐?' 같은 욕을 바가지로 퍼먹여줄 글이 될 수도 있겠죠 ^^; 하지만 프로그래밍을 하면 할수록 그 것이 진실이라는 생각만 강해지고만 있어요. 위에서 유명한 아저씨들도 다 그렇게 이야기하고 있는 것 보니 위안이 되네요.

인용자료 출처

'KTUG(Korean TeX User Group)의 문학적 프로그래밍에 관한 전반적인 소개' http://faq.ktug.or.kr/faq/LiterateProgramming ACM 강연의 원문, PDF 파일
누워서 읽는 알고리즘, 임백준 ( ACM 강연의 번역내용, '문학적 프로그래밍' 서문 번역내용

Code can be an art 행사 참석 후기

Fri, 1 Jun 2007 00:00:00 +0000

지난 2007/05/19(토)에 CCK(Creative Commons Korea)에서 주최한 ccSalon 행사가 있었습니다 . 이날의 행사 제목은 'Code can be an art’였었죠

관련 글과 같이 올릴려고 하다 보니 거의 2주가 지나서야 후기를 쓰게 되네요.

관련 글
- QB로 만든 Code can be an art 출력
- 코드와 예술

저는 이 행사를 김국헌님의 블로그에서 알게되어 혼자 행사장을 찾아갔었습니다. 제가 워낙 길치라서 노트북에다 약도를 저장해서 띄워놓고 화면을 계속 보고 갔는데도 힘들게 행사장을 찾아갔습니다. -_- 길에서 걷는 중에 노트북을 펴놓고 화면과 주위를 번갈아 가는 모습을 이상하게 본 사람도 있었을 것 같습니다.^^;

주요 행사 내용 중에 다음과 같은 내용들이 인상깊었었습니다.

DJ성우님의 발표

개발자와 DJ의 공통점으로 '밤늦게 컴퓨터 앞에서 작업하는 일이 많다','이미 있는 것으로부터 새로운 창조물을 만든다' 등을 드신 것이 기억납니다. 그리고 개발자들도 DJ들처럼 공동작업 그룹 같은것을 자발적으로 결성해서 활동하면 어떨까 하는 제안도 신선하게 들렸습니다.

미디어 아티스트 최승준님의 발표

최승준 님의 '입자인생'(http://beingmedia.tistory.com/entry/입자인생Net )이라는 작품은 예술적이면서 철학적인 설명을 해주셔서 심오하게 까지 느껴졌습니다. 그런 것 프로그래밍 하려면 물리학이나 수학도 많이 알아야 될 것 같다고 생각하니 저런 작품들은 여러 분야들의 종합성과물이라는 생각이 들었습니다.

황리건님의 발표

황리건님의 작품 중에는 맨 마지막 것이 가장 기억에 남습니다. 화면에 보이는 선의 한 부분을 클릭하면 거기서 원이 추가 되고 선분은 나누어져서 새로운 움직임을 보여주는 프로그램이였습니다. 이 작품을 꼭 보여주시고 싶어 하시면서, 이 것을 한달동안 힘들게 만드셨다고 말씀하시는데, 창작자로써의 뿌듯함이 느껴지시는 것 같았습니다. 요즘은 고객이 만들라고만 한 프로그램만 만들고 있는 저로서는 부러웠어요 ^^;

코드잼

QB로 만든 Code can be an art 출력 글에서 썼듯이 코드만 짜가고 발표는 못했습니다. 그래도 기획하신 분의 의도, 발표하신 분들의 기분은 알 수 있을 것 같았습니다.

패널토론 8Bit 키드의 생애

80년대 초반 컴퓨터를 처음 시작한 세대들의 추억담이였습니다. 저보다는 앞세대의 분들이였고 사용한 기계와 환경은 달랐지만, 그런 이야기를 하시면서 어떤 기분이 드실지는 왠지 알 것 같았습니다. 아마 제가 '허큘리스’라는 말만 들어도 느껴지는 기분과 비슷하지 않을까요? ^^;

패널토론 예술로서의 코드

타이틀이 맞는지 모르겠군요. 김창준님이 귀여니의 시구를 인용하시던 부분에서 웃지 않을수 없었습니다. 앞의 다른 순서들이 '코드로 만든 결과물인 예술', '만든다는 것의 기쁨’에 초점이 맞춰진 것이라면 이 순서는 '코드 자체로써의 예술’에 중심을 둔 것 같습니다.

모든 순서가 끝난 뒤에 뒤풀이가 있었습니다. 저는 아는 사람도 없고 해서 분위기가 어색하지 않을까 걱정을 했었는데, 저녁 식사 때부터 같은 테이블에 앉았던 자원봉사자 분들이 재밌는 자리를 만들어주셔서 편하게 술자리를 할 수 있었습니다 ^^; 그리고 개인적으로 평소 애독하는 블로그의 주인이신 류한석님, 김국헌님을 가까이서 뵐 수 있어서 영광이였습니다~ ^^ 같은 테이블에 앉았던 대학생 분은 그 두분께 블로그 내용이 인쇄된 종이에다가 사인을 해달라고 부탁하더군요.

보통 저는 술자리에 참석하면 끝까지 남거나 쓰러지거나 둘 중에 하나였었는데, 이날은 아내가 근처까지 데리러 오는 바람에 먼저 일어날수 밖에 없어서 무척 아쉬웠습니다.

다음 모임때부터는 저도 자원봉사자로 참여하겠다고 했는데 빨리 그 때가 왔으면 좋겠네요~

QB로 만든 Code can be an art 출력

Fri, 1 Jun 2007 00:00:00 +0000

CCK(Creative Commons Korea)의 Code can be an art 행사에서는 '코드잼’이라는 순서가 있었습니다.

'Code can be an art’라는 문자열을 출력하는 프로그램을 자유롭게 짜서 발표하는 것이었죠.

코드잼 설명 : http://ccsalon.tistory.com/4

저도 이날 점심을 먹는 것도 잊고 나름대로 코드를 준비해 갔는데, 발표를 하지는 못했네요 . 발표자가 적은 분위기면 앞에 나가볼려고 노트북까지 들고 가기는 했었습니다 ^^; 그런데 열띤 호응으로 많은 분들이 발표를 하셨고, MSX 에뮬레이터로 하신 분 등 제가 말하고 싶었던 내용을 다른 분들이 더 훌륭히 말씀해 주셔서 큰 아쉬움은 없습니다.

8bit 화면 같은 행사 로고를 보고 저도 제 세대에 맞게 Quick Basic으로 코드를 짜볼 생각을 해봤습니다. 이 행사 중에 '8bit kid의 생애’라는 패널토론 주제도 있었었죠. ^^; 저는 그 다음 시대인 IBM XT세대입니다. 허큘리스 그래픽카드, 5.25인치 FDD, 조금 지나서 ADLIB card, 2400bps MNP 모뎀 등이 저에게는 가슴을 파고드는 핵심단어들이에요.

그 추억의 시절에 제가 가장 많아 가지고 놀았던 프로그램 언어가 Quick-Basic이였습니다. Basic에서 행번호를 없애고 구조화프로그래밍 개념을 도입한, 당시 저에게는 충격적으로 대단한 언어였어요. 이 도구에다 basic을 배웠던 사람이면 누구나 회상할 추억의 명령어 line(선긋기), play(음악연주), read,data(데이터 읽는 구문)을 넣어서 코딩을 해봐야겠다고 마음 먹었습니다. 대신 제 PC환경상 그때의 Quick-basic 대신 Window XP에 내장되어 있는 q-basic을 사용할 수 밖에 없었어요. 프롬프트에서 qbasic이라고 치면 언제나 튀어나오는 도구죠.

Quick-Basic과 q-basic이 뭐가 다르냐구요? 문법은 거의 똑같은것 같아요. Quick-basic은 따로 패키지로 나와서 버전4.5까지 발표되었었는데, q-basic은 어느 새 MS-DOS의 상위버전에 포함되어서 나오더군요 . Quick-Basic에서는 실행파일(.exe)도 만들 수 있고, 각종 라이브러리도 많았었습니다. 아뭏든 대타로 q-basic을 썼기에 실행할때는 아래와 같이 치면 됩니다.

프롬프트> qbasic/run cba2.bas

단순히 화면에 큰 글자를 찍어주는 것 밖에 없지만, 꽤나 시행착오 작업을 많이 거쳤었습니다. 예전 Quick-Basic에서는 screen 12라는 화면모드를 주로 썼었었는데, 이번 환경에서는 screen 2 밖에 안 먹는 것이였습니다. 화면 전체 해상도가 몇곱하기 몇 인지도 모르고 그냥 무작정 네모를 그리는 숫자값을 바꿔가면서 화면을 만들어 봤습니다. 결국 한참 후에야 그럭저럭 화면중간에 크게 들어간 글자를 얻어낼 수가 있었죠. 평소에 일할 때 이렇게 무식하게 작업을 한다면 스스로 한심하게 느껴졌겠지만 이번에는 그것조차도 옛 추억을 되살리는 즐거움이였습니다.

그리고 이 프로그램에 들어간 멜로디를 아시는 분이라면 아마 저하고 비슷한 컴퓨터 세대이실 것 같아요. 불후의 고전명작게임 'Loom’의 메인테마 입니다. 처음에 노트북을 들고 행사장에 갈때까지만 해도 프로그램에서는 단순히 '도미솔' 정도의 소리만 났었습니다. 그러다가 행사가 끝난 다음 주에 문득 여기에다 듣기좋은 멜로디를 넣어보고 싶다는 충동을 느꼈고, 그때 게임 'Loom’의 음악이 머리 속에 떠올랐습니다. 당연히 악보 같은 건 없었고 기억하는 멜로디를 스스로 휘파람으로 불어서 청음으로 코드를 만들었습니다. 남다른 음감각을 가진 것도 아니어서 계속 시행착오를 거치면서 play문에 들어가는 음표코드를 넣었죠. 어쩐지 박자와 음이 약간 어설프고 불안정한 느낌이 들지 않나요?

행사 때 김국헌님께서 발표하시는 분들마다 물어보셨던 말이 있었습니다. '이 작업을 하시면서 즐거웠습니까?'' 저도 여기에 그때 다른 분들이 하셨던 말과 똑같이 '네. 굉장히 즐거웠습니다’라고 말할 수 밖에 없네요. 한 때는 왠만한 단축키는 다 외웠었던 Quick-Basic이였는데 오랜만에 쓸려니 함수 선언방법 조차도 가물가물 하더군요. 그래도 기억을 되살려 가면서 작업을 하다보니 이런 도구로 고등학교 때 축제 전시회 때 내놓을 게임을 만들던 일이 생각이 났었습니다. 그 때 정말 밥 먹는 시간도 잊어 버릴 정도로 매달려서 어설픈 게임을 만들었고, 어쩌면, 아니 확실히 그런 기억들 때문에 지금도 컴퓨터 코드를 짜는 일을 하고 있다는 사실도 새삼스럽게 떠올랐습니다.

뭐 어떤 분들은 이 글을 보시면, 몇줄 안되고 실행결과도 허접한 프로그램 짜놓고 제목은 아트니 뭐니 되어 있고 되게 거창한 척을 한다고 느끼실 것 같습니다. 하지만 누가 뭐래든 이 코드를 짜던 순간, 그리고 Quick-Basic이 어떤거니 하는 , 요즘은 별 정보도 되지 않을 이런 글을 주절주절 쓰고 있는 이 순간까지도 행복감의 여운을 느낍니다.

다 해놓고 보니 코드는 그리 길지는 않네요~

DECLARE SUB display (c$, p$)

SCREEN 2
lg$ = " Code can be an art! "
DATA "t90O1p4","e8","a8","b8",">c+8","g8","f8","<a8"
DATA ">d8","c+8","<e2","e8","a4","b8",">c+4","<b8","a2","e2","p4","p4","p4","p4"
FOR i = 1 TO LEN(lg$)
    READ p$
    display MID$(lg$, i, 1), p$
NEXT i
SCREEN 0
END

SUB display (c$, p$)
PLAY p$
CLS
PRINT c$
FOR i = 0 TO 10
  FOR j = 0 TO 10
    IF POINT(j, i) THEN LINE (j * 60 + 80, i * 25 + 10)-(j * 60 + 140, i * 25 + 40), 1, BF
  NEXT j
NEXT i
LOCATE 1, 1
PRINT " "

END SUB

다른분들의 발표작

방명록

Thu, 8 Feb 2007 00:00:00 +0000

블로그 방명록이에요. 댓글로 달아주세요

나선형 배열 출력 문제 Spiral Array

Wed, 7 Feb 2007 00:00:00 +0000

2007년 회사 워크샵 갔었을 때 풀었던 문제와 답

문제

풀이

정상혁&이상미 조의 풀이 답입니다.

public class MatrixMain {
    public static void main(String[] args) {
       Matrix mp = new Matrix(5,5);
       mp.locateNumbers();
       mp.print();
    }
}

public class Matrix {

    public static final int RIGHT = 0;
    public static final int DOWN = 1;
    public static final int LEFT = 2;
    public static final int UP  = 3;

    private static final int INIT_VALUE = -1;

    private int m = 0;
    private int n = 0;
    private int[][] matrix;

    public Matrix(int m, int n){
        this.m = m;
        this.n = n;
        matrix = new int[m][n];
    }

    public void print(){
        for (int i=0;i< m ;i++){
            for (int j=0;j<n;j++) System.out.print(matrix[i][j] + "\t");
            System.out.println();
       }
    }

    public void locateNumbers() {
       init();
       int[] startPosition = new int[]{0,0};
       matrix[0][0]= 0;
       int direction = RIGHT;
       while(move(startPosition ,direction)) direction ++;
    }

    private void init() {
        for (int i=0;i< m ;i++){
            for (int j=0;j<n;j++) matrix[i][j] = INIT_VALUE;
        }
    }

    private boolean move(int[] position, int direction){
        int nowNumber = matrix[position[0]][position[1]];
        boolean moved = false;
        int[] nextPosition =getNextPosition(position,direction);
        while(isMovable(nextPosition[0],nextPosition[1])){
            moved = true;
            nowNumber++;
            position[0] = nextPosition[0];
            position[1] = nextPosition[1];
            matrix[position[0]][position[1]]= nowNumber;
            nextPosition = getNextPosition(position,direction);
        }
        return moved;
    }

    private int[] getNextPosition(int[] position,int direction){
        int x = position[0];
        int y = position[1];
        int nowDirection = direction%4;
        if (nowDirection == RIGHT) y++;
        else if (nowDirection == DOWN) x++;
        else if (nowDirection == LEFT) y--;
        else if (nowDirection == UP) x--;
        return new int[]{x,y};
    }

    private boolean isMovable(int x, int y){
        if (x>=m) return false;
        if (y>=n) return false;
        if (x<0) return false;
        if (y<0) return false;
        if (matrix[x][y]!= INIT_VALUE) return false;
        return true;
    }
}

결과

0   1   2   3   4

15  16  17  18  5

14  23  24  19  6

13  22  21  20  7

12  11  10  9   8

이동하는 좌표를 사이즈가 2인 int배열에다 담았는데, 이걸 따로 클래스로 빼서 만들까 하다가 클래스를 더 늘리기 싫어서 그만뒀습니다. 소스에서 position[0], position[1] 이라고 표시된 부분이 좌표를 나타내는 부분입니다.

main메서드에서 Matrix mp = new Matrix(5,5);` 부분이 5*5 행렬을 만든다는 의미입니다. 사이즈를 바꿀려면 이 부분을 고치시거나, 사용자 입력에서 온 값을 연결시키면 됩니다.

더골(THE GOAL)

Wed, 7 Feb 2007 00:00:00 +0000

(이미지는 yes24에서)

더 골(The Goal) , 제프 콕스 저, 김일운 역, 동양문고

회사 소모임의 워크샵에서 이 책을 주제로 한 발표가 있었습니다. 그 때 생각난 내용을 나중에 회사 커뮤니티 게시판에 적었는데, 그 내용의 일부를 옮겨써 봅니다.

저의 사촌형이 이 책을 낸 출판사에 일하고 있어서, 저는 책을 공짜로 받았었습니다. 몇년전 제가 그 형 집에 놀러 갔을때 이책을 아마 제가 꼭 읽어야 할 것이라면서 그냥 저에게 주는 것이였습니다. 대충 넘겨보면서 내용을 훑어보니 공장에 대한 이야기라서 서비스업에 종사하는 저로써는 별 상관없는 내용으로만 보였습니다. 그래서 한동안 책장에 꽂아만 두고 있었죠. 책을 받고 한참 뒤에서야 잡지나 블로그 등을 통해 개발자가 읽을 책으로 이 책을 권하는 사람이 많은 것을 알게 되었고, 다시 찾아서 읽게 되었습니다.

소설의 내용은 공장장이 문제의 공장을 해결해 나가는 이야기입니다. 그 문제의 공장이 잘 돌아가지 않았던 것은 각각의 공정의 부분적인 생산성에만 작업자의 목표가 맞춰져 있었기 때문이라고 정리하고 싶습니다. "부분적인 최적화는 전체 최적화를 보장하지 않는다"는 말도 학교 다닐때 들었는데, 그 예가 이 소설 내용에 있는 것 같네요.

공장에서는 자동로봇을 도입하고 이를 자랑꺼리로 여겼는데, 그 로봇은 많은 부품을 찍어냈지만, 그 부품은 결국 재고만 더 쌓이게 만들어서 오히려 공장에 손해만 끼치는 결과를 낳았다는 내용이 있습니다. 그 로봇이 있는 공정에서는 부품의 생산양만 보고 높은 성과를 이루고 있다고 생각했겠죠.

모두들 열심히 일하고 로봇도 쉬지 않고 있는 공장이 고객이 주문하는 생산량을 못 맞추자 공장장은 대학 때 교수로 부터 자문을 받아서 이를 해결해 나가기 시작합니다. 그 방법들은

병목이 일어나는 공정에 대해서 외주를 주거나 동원가능한 다른 기계를 이용해서 지원작업을 한다.
우선 순위가 급한 부품을 다른 표시를 해서 그 부품이 해당 공정에 들어왔을때는 가장 먼저 작업을 하도록 한다.

등입니다. 위에 로봇의 경우와는 반대로 최적화된 한번의 작업량 (예를 들면 붕어빵틀에 모든 구멍에 밀가루를 채우는 것 같이 해당공정의 효율이 극대화 되는 한번의 양)을 포기했을 때 오히려 공장의 전체 생산성이 더 좋아지는 예도 책에 나옵니다. 그리고 "재고는 자산이 아닌 비용이다"라는 개념도 기존 통념을 뒤엎는 것이였죠.

전에 이 책을 다 읽고나서도 "그래도 나와는 큰 관련 없는 공장이야기군"하고 생각을 했었는데, 최근에 들어서야 IT업과 연관성을 생각해보게 되었습니다.

개발 프로젝트를 하면서 제가 경험한 일정관리는 프로그램의 목록을 엑셀시트나 이슈 트래커에다 나열해 놓고 그중에 몇개를 완성했느냐, 그것이 전체의 몇%냐로 평가를 받는 것이였습니다. 그 갯수가 적으면 다른 사람보다 생산성이 적은 것이 되고, 계획했던 갯수보다 적으면 일정을 못 맞춘것이 되는것이였습니다. 여기서 개발자가 충족해야할 목표는 그 갯수를 늘이는 것인데, 그러다보니 쉬운 프로그램, 고객이 별로 신경쓰지 않는 프로그램을 먼저 구현을 하게 되는 경향이 생기기 쉬워집니다. 그러다보면 오히려 정말 많이쓰이고, 고객이 민감해 하는 프로그램들은 나중에 급하게 졸속으로 구현되는 경우를 봐왔습니다. 이는 개발자가 평가받는 부분적인 목표(프로그램 갯수)와 프로젝트 성공의 목표(고객의 필요한 프로그램이 잘 돌아가서 검수를 받는것)이 상충되는것이 아닐까 합니다. 익스트림 프로그래밍 서적에서도 비슷한 이야기를 본것 같네요. 고객이 가장 우선시 하는것부터 먼저 구현을 하고 고객에게 피드백을 받고 다음 스토리로 넘어가야한다는 내용이였던것 같습니다.

그리고 프로젝트에서 "고객검토"가 병목인 경우가 많다는 생각도 듭니다. 한참동안 피드백이 없다가 프로젝트 종료시점에서야 요구사항을 쏟아내는 고객의 경험을 다른 분들도 겪었을것 같습니다. 병목을 보강하듯이 업무별 고객담당자를 적절히 분할해서 지정하거나, 개발팀 쪽에서도 고객검토을 촉진시킬수 있는 담당자를 두거나 하는 해결방안등이 생각이 납니다.

이 책이 공장의 이야기인데도 개발자들사이에 많이 권해지는 이유를 연결시켜서 생각해봤습니다. 그 외에도 연관시킬만한 것이 있는지 궁금합니다.