Younghoe.Info (final edition)

1. 흥분하면 지는 거다: 대기업에 속한 동지^[각주:1]가 물불 안 가리고 온 힘을 기울여 일했다. 대단하다 여겨졌지만, 누구나 약점은 있는 법이다. 동지의 주인의식과 넘치는 열정을 이용해 손 안 대고 코를 푸는 무뢰배를 자주 목격했다. 동지의 최대 약점은 쉽게 흥분한다는 점이고, 주변 무뢰배는 약점을 활용해 이익을 취한다.
   
2. 아이에게도 배우라: '좋은 학교', '나이와 사회적 위치' 탓에 자존심을 앞세워 스스로 컨테이너를 둘러서라도 벽을 만드는 사람을 본다. 그를 비난하는데 아까운 시간을 흘려보낸 후에야 가끔 깨닫는다. 드러나는 몇 가지 모습을 통해 만들어진 허상에 기대어 피 같은 시간은 낭비했던 내 모습을 본다.
3. 내 시간부터 관리해라: 국내 소프트웨어 산업은 80년대 묻지마 시대를 지나 90년대 후반부터 묻지마 신기술 도입기를 거쳤다. 정신없이 새로운 기술을 받아 들이기도 벅찼던 선배님들은 기술과 기술자를 관리하는 법은 배우지 못했다. 그런데 그에 앞서 내 시간부터 관리하지 못하면서 팀과 조직을 어찌 관리하랴. 애자일이라는 훌륭한 실마리를 통해 배운 바는 주 단위가 아니라 일 단위나 시간 단위로 계획과 반성으로 부족한 의지력과 실행 능력을 보완하는 법이다.
   

3년 전에 책에서 옮겨둔 구절을 다시 들려준다.


하루도 거르지 않고 말이 앞서 다른 이의 말을 듣지 못하는 순간이 많다. 어떤 경우는 문자 그대로만 들으며 지루해하다가 진심으로 하는 말은 듣지도 못한다. 어떤 때는 마주한 이에게 말할 기회조차 주지 않는다. 제자리걸음 속에서 종말을 맞이하는 멍청한 순간을 줄이기 위해서라도 다른 사람을 듣자.

모리와 함께한 화요일
미치 앨봄 지음, 공경희 옮김/세종서적

주말에 난데없이 몇 년 전에 술자리에서 들었던 말이 떠올랐다. 나를 이상주의자라고 했던 말이다. 당시 상황에 따르면 현실에 맞지 않는 꿈을 꾸는 사람으로 들려 반박했던 기억이 있다. 스스로는 주어진 조건에 맞춰서 답을 낸다고 자부했기 때문이다. 하지만, 그 사람 지적이 맞고, 술기운에 하릴없이 변명을 늘어놓았다는 사실을 몇 년이 지나서야 깨달았다.


사회를 잘 안다는 사람들이 말하는 존재 이유로는 행복은커녕 불편한 마음에 견디기가 어렵다. 더 오래전으로 돌아가 대학원 후배가 '형은 욕심이 많다.' 지적한 일이 있다. 당시에도 반박했다. 많은 것을 소유하고 싶은 마음은 없었다고 확신하고 있었으니까. 어떤 면에서 욕심이 많다는 사실을 인정하지 않을 수 없다. 


나는 분명 주어진 현실에 만족하지 못한다. 다만, 가슴 뛰는 일을 하기에 의지와 용기가 부족할 뿐이다.

이미지 출처: http://www.avatarmovie.com

3년 전에 이런 일이 있었다고 합니다. (기사 원문: 노대통령, 원전 해외진출 추진 지시 via http://twitter.com/jrogue) 최고위층이니만큼 대통령의 직무 추진 방식은 추상적입니다.


그런데 이번 UAE 원전 수주 기사를 보면 이명박 대통령이 김연아 선수라도 된 듯 보도합니다. 수주 가능성이 큰 상황에서 순발력 있게(?) 나서 그간 수년 아니 어쩌면 수십 년을 노력했을 많은 사람의 공을 이렇게 가로채는 모습은 대통령의 격에 맞지 않은 모습입니다. (청계천 복원, 대운하, 4대강 사업이나 이번 일에 직접 나서는 모습을 보면 건설회사 사장의 틀에 갇힌 듯하다.)




휴일 저녁 뉴스 일부만 보아도 순식간에 혐오하는 마음이 생깁니다. 하지만, 혐오하고 증오해보아야 저에게도 이롭지 않다는 사실을 깨닫습니다. 인정하고 싶지 않아도 이대통령은 제가 속한 사회 다수가 인정한 대통령이죠. 인정하기 싫은 현실의 부조리는 가까운 주변을 둘러보면 더욱 확고히 알 수 있습니다. 직원 월급도 주지 못하고 프로젝트에서도 남에게 고통을 주는 회사가 전자신문에 자랑스럽게 기사를 올리는 모습을 보고 역겨운 마음을 품었던 일이 불과 며칠 전이죠.

....

이러한 현실에서 과연 무엇을 하며 주어진 시간을 써야 할까요?

소모임에서 다른 사람이 쓴 글을 읽고 토의를 하는데 (1) 처음이라 어색하기도 하고 (2) 경험상 의견을 내는 사람이 몰리는 경향이 있어 도구를 만들었습니다. 나중에 개선할 의도로 백지에 쓴 네 개 항목인데, 모임을 더 갖으면서 개선하면 또 공유하겠습니다.

1. 글을 읽은 첫 느낌이나 생각은?
2. 글을 읽고 생기는 의문사항
3. 비슷한 경험이 있는지?
4. 한 발 더 나아가자면? (추가적인 제안)
   

오픈소스 ESB 제작으로 유명한 MuleSoft가 보낸 메일에서 Tcat Server란 표현이 있어서 갸우뚱했다. 톰캣(Tomcat)을 줄여 부르는 말인가 싶었는데, 링크를 타고 확인해보니 마치 SpringSource tc Server처럼 톰캣에 감시(monitoring)와 관리 기능을 내장하여  기업용으로 판매하는 제품이다. 제품에 대한 관심보다 오픈소스를 베껴서 자사 제품을 만들지 않고 함께 사용하며 시너지를 내는 제품 다수를 만드는 모습이 좋아 보인다. 예전에 이모부가 휴대전화 악세서리 사업을 했는데, 국내에선 새로운 설비를 구매하여 국내 경쟁사를 죽이려 들지만, 당시 경쟁국인 대만에선 조합 형태로 설비를 사들이고 공유한 후에 경쟁해 부러웠다고 한다. 데자뷔를 보는 느낌이다.

Toby형이 글을 자주 올린다. 구체적인 기술을 다루는 이야기라 댓글이 많지 않았는데, 모처럼 viz란 분이 논쟁을 부르는 댓글을 올렸다. 그랬더니 Toby형 뿐 아니라 entworks님까지 몰려 왔다. 흥미롭게 이어지던 글은 아쉽게도 노이즈로 바뀌었다. frankly speaking ID를 쓰는 분이 어구가 담고 있는 뉘앙스까지 담아낸 듯하다.

franklyspeaking 이란 분의 글을 보면 대단한 경력이 있어 자랑하고픈 듯하다. 그렇지만, 보편적인 문제 제기를 이해하지 못한다. 한 수 위라는 듯한 말투인데 그랬다면 Toby 형 주장의 오류를 드러낼 능력이 있어야 한다. 현장 경험을 중언부언 올린 댓글은 길기만 할 뿐이다. 기억에 남는 내용을 굳이 꼽으면 바로 이 부분이다.


Java EE와 스프링이 마치 상호배타적(Mutually Exclusive)인양 쓰고 있다.^[각주:1] 일단, 스프링을 잘 모르는데 감정이 있는 듯하다.


그런데 예를 정말 잘못 선택했다.


미안하지만 Prototype은 소프트웨어 개발 분야 최고의 정리 중의 하나인 GoF 패턴 이름을 빌린 보편적인 이름이다. Proxy는 어떤가? 역시 GoF에서 왔고, JDK에도 등장하는 어휘다. 스프링은 특정 개발팀 하나를 위해 작명하지 않기 때문에 보편 지식에서 용어를 정의했을 테니, 패턴이나 메커니즘 표현에 대한 배경 지식이 부족하면 어렵게 느낄 수 있다. 스프링에서 나쁜 작명을 찾으려고 한다면, 웹 MVC 모듈에서 찾을 수 있는 비슷비슷한 Template 메소드 이름을 권하고 싶다.

좋은 작명을 위해 고민하라며 쓴 글을 보자.


스프링의 IoC는 웹과는 무관하다. 웹에서 쓰도록 Request와 Session 스코프를 제공하지만 IoC 자체가 웹에 종속한 내용이 아니다. Toby 형을 두고 경험 운운하는데, 아무래도 웹만 경험해서 이런 글을 쓰지 않았을까 짐작된다.

설사 경험이 많다 하더라도 개념은 확실히 빈약하다. 다음 글을 보자. 도대체 무슨 말인가?


coherence는 왜 튀어나왔는지 모르겠지만, concurrency, transaction, caching 등등이 서버 프로그래밍의 이슈란다. 서버 프로그램이란 표현이 매우 모호하지만 대충 넘어가자. dependency injection은 서버 프로그래밍 이슈가 아니란다. 시스템 프로그래머가 가려준다는 말은 앞에 나열한 이슈를 해결해준다는 말이라고 번역하자. request, session, thread safety도 annotation으로 가려준단다. 세 가지도 서버 프로그래밍의 이슈인가? 짐작건대 시스템 프로그래머가 다루는 이슈는 주로 WAS 같은 미들웨어 성격의 내용이다. 그렇다면, WAS가 Dependency Injection은 제공하지 않을까? 마지막 말처럼 비즈니스 애플리케이션 개발자는 그냥 외워서 쓰면 되던가? 그렇다면, 스프링은 등장하지 않았을 것이다.

기술적인 글을 대할 때도 이렇게 난잡하게 이야기하는 풍토는 내가 속한 SI환경을 드러내는 현상이다. 계획 없이 무턱대고 개발하던 시기를 막 지나는 중이기에 우리 SI 환경은 문제를 진지하게 고민하고, 토론하고 공유하고 개선하는 일은 드물다. 자바나 JSP 등의 기술을 다룬 책 이외에 본격적으로 설계를 다루는 책조차 아직은 보기 어렵다.


하지만, 인스턴스의 스코프(Scope) 문제를 깊이 있게 다루며, 애노테이션 도입에 따른 자바 언어의 진화에 따른 파급효과도 함께 언급한 Toby 형 글처럼 고민한 내용이 쌓이고, 나뉘고 토론을 통해 발전하는 과정이 바로 미래를 여는 순간이라고 믿는다. 같은 시간에 독선적 프로그램을 만들어 타인에게 피해를 주는 구시대 프로그래머 역시 과거에 배운 짧은 지식과 경험을 음미하며 인생을 보낼 것이다. 

독선적 프로그램은 연동하는 프로그램을 작성하는 다른 이를 고통스럽게 한다. 독선적 프로그램을 무책임하게 남에게 넘겨주며 자리를 옮기는 이도 있다. 독선적 프로그램을 양산하여 판매하는 이도 있다. 아는 사람은 뻔히 아는 현실을 무시하고 IBM이나 오라클을 넘어섰다는 그 회사 코드를 보니 스프링 웹 MVC를 패키지 그대로 복사하고 org.springframework 부분만 자사 도메인으로 바꾼 부분을 확인할 수 있었다. 언젠가는 그 회사 패키지가 너무 느려서 APM으로 확인해보니 대부분의 SQL에 DECODE로 사용해 Full Scan을 유발했고, 자사 인력이 해결하지 못해 당시 프로젝트 DB 전문가가 쿼리를 만들어줬다. 이 회사의 무책임한 작태에 대해서는 말을 참기 힘들지만, 직원들이 받을 상처를 생각하면 조심스럽다.

가끔 '차세대 프로젝트' 경험을 자랑하는 개발자를 만난다. 관리자를 했다면 인정해줄 만하다. 많게는 수백 명을 통제하는 일은 쉽지 않다. 하지만, 개발자는 어떨까? 차세대 프로젝트건 소규모 프로젝트건 일정 비율의 사람은 중요한 일을 하고, 일정 비유의 사람은 적당히 일하고, 일부는 문제를 만든다. 도리어 차세대 프로젝트는 워낙 규모가 커서 사람도 많고, 여러 회사를 통해 처음 모인 서먹한 관계라 상당수가 다른 사람이 짜고 있는 코드가 있는 줄도 모르고, 바로 옆에서 거의 비슷한 코드를 짜면서 세월을 보내기도 한다. 증권 차세대 경험을 내세우면 제멋대로 짜는 이를 만난 일이 있다. 그가 짠 코드의 버그 탓에 오류가 발생했다. 일년 가까이 코딩을 손대지 않던 터라 문제가 있는 파일 이름을 알려주고 원인을 물었다. 버그가 있는 줄도 모르던 그에게 당신 코드에 버그가 있다고 말해줬더니 '자신이 요즘 얼마나 바쁜가'에 대해 설명한다. (SI  경험 탓에 포기하고) 처음 보는 코드에서 Stack Trace를 토대로 버그를 찾았다. 암호처럼 짠 코드지만 문제 소지가 있는 부분만 찾아 테스트해 보니 대략 20~30분이 걸렸다. 이를 모르던 개발자는 다음 날, 버그와 아무 관련이 없는 코드를 들먹이며, 그 내용을 수정해서가 아닌가 싶다고 근거 없는 추측을 아무 부끄러움 없이 말했다.

한동안 이런 상황을 탓하며 살았다. 마치 역사책을 훑듯 눈높이를 확장해서 보면 초창기에 겪는 시행착오일 수 있다. 그리고 미래로 나아가는 하루를 살려면, 더 솔직하게 모르는 내용을 꺼내서 잘게 쪼개고 하나씩 차분히 정리할 때다.

개발자와 아키텍트 사의 불협화음의 본질


그리고 해결책



아키텍처의 중요한 특성

architecture is a kind of “shared understanding"


아키텍처 수립/구현에도 기민한 접근이 필요한 이유에 대한 Temporal Aspect


부가 설명


Structural Aspect는


두 가지 츨면은 물론 조화를 이뤄야 한다.


출처: Agile Architecture Requires Modularity, Turtles and Architecture

현장에서 보통 "설계"라는 말을 하면 대개는 화면 요구사항 도출과 데이터 모델(ERD를 결과로 내놓는) 작성을 의미한다. 물론, 파레토 법칙을 감안해서 이해해야 한다. 주류에 속하는 다수가 그렇다는 말이다. 현실에 만족하는 개발자가 말하는 설계와 다른 맥락의 설계가 있는데 여기에 대해 상당수가 합의하고 있음도 어렵지 않게 알 수 있다. 징후는 꽤 많다.

• '한국에 과연 설계가 있느냐?'라고 말하는 사람
• 사랑스러운 책, Domain-Driven Design
• 실증적인 설계 접근을 제시하는 TDD(Test Driven Development)
• 다른 산업의 발전 양상

머지않아 이 바닥 10년을 맞이한다. 한 분야에서 10년을 하면 고수가 된다고 한다. 고수가 되고 싶지는 않지만, 인생을 허비하지 않기 위해 남은 날에 대해 목표를 설정했다. 현재 통용되는 설계와 다른 설계를 하겠다고 마음을 먹는다. 의지박약을 고려하면 결과는 미미할지 모른다. 그래도 의미 있는 일을 추구하며 사는 과정이면 충분하다. 분발하기 위한 반성문을 여기서 멈추고, 다른 이야기를 조금 남기고 싶다.

Eric Evans와 다른 관점에서 DDD를 공부하는 지인의 글에 대한 감상이다. 책에 비하면 짧은 글이지만 마치 한 장을 다시 읽은 듯한 효과를 준다. 가지치기를 해서 Aggregates, Factories, Repositories 셋을 부각한 요약이 바로 포스팅이 제공하는 부가가치다. 여기에 짧은 식견을 더해 정확도는 떨어져도 영감을 주는 요약을 더한다.

Aggregates
프로그램으로 정의하는 객체(혹은 자바 파일, JS 파일, UI 컴포넌트, ...)는 현실의 요구에 비해 너무나도 작다. 그래서 조직화는 필수다. 어쩌면 진리의 영역인지도 모른다. 둘러보라. 왜 우리는 정부를 구성하고, 시장을 만드는... (경고! 오버 금지)

여하튼 프로그램을 관리 가능한 구성으로 묶어야 한다. 이 방면에서 가장 앞선 기술 중의 하나가 스프링이다. Application Context는 다른 역할(이를테면 Event Propagation Mechanism, Factory 등)도 수행하지만, 분명히 Aggregates 구현체의 대표적인 모습을 띤다.

Factories
객체 생성시점에 고려할 환경적 요건이나 미리 설정할 사항에 대해 관리를 일원화하는데 좋은 도구가 팩토리이다. 수명이 장구한 서블릿 컨테이너가 이미 팩토리이고, 5년 천하 끝에 골동품 취급을 당하는 EJB 컨테이너도 역시 검증된 팩토리다. 스프링의 핵심 구성요소가 바로 세밀한 확장점을 제공하여 선택 가능성을 높인 팩토리다.

Repositories
가장 어렵게 느껴지는 부분이 바로 저장소(Repository) 구현이다. 어떻게 하면 물리적인 저장 방식(단일 DBMS, 복수의 DBMS, File System, ...)에 들어맞으면서 애플리케이션의 요구에 맞춰 객체를 공급할 수 있을까? Hibernate가 가장 세련된 저장소 구현 모델을 제시했다. 그리고 더 큰 그림은 이름 정도나 아는 새로운 기술(Data Grid, Big Table, ... )이 영감을 준다.

2009. 12. 15 갱신
우연하게 방금 Toby형이 올린 글이 Aggregates 구현 메커니즘의 핵심과 최근 자바 기술 동향을 정리하고 있다. 물론, 다른 시각이고 어렵지만 흥미롭다.

2009. 12. 16 갱신


OSGi 에반젤리스트 글에서 그림만 빌려 쓴다. 설계란 그림에서 Ivory Tower가 나타내는 모호함을 줄여서 종합적인 의도대로 코드를 작성하고, 시스템을 운영할 수 있게 하는 행위의 일종이다. 특정 기능 개발에 몰두하는 개발자는 자연히 깊이 고민하는 대신 다른 부분을 신경 쓰기 어렵다. 그래서, 외부에서 오는 제약(다른 개발자나 기존 코드, 하드웨어 등에 따른 제약)에 대해 누군가를 설명해줘야 한다.

* 이 글은 월간 마이크로 소프트웨어에 기고했던 글을 잡지사측 배려로 공개하는 내용입니다.

소통과 협업을 강화하는 프로젝트 문화 조성하기

약 2년 전 일이다. 프로젝트 스폰서인 임원이 대뜸 회의를 자주 소집하지 말고 포털 사이트 블로그 같은 시스템을 구축해서 서로 이야기하자고 말했다. 메신저도 연동하고, 한 주제에 대해서 개발 업체와 고객 사이에 치열하게 논쟁하기 위해 장벽을 허물자는 것이다. 소신이 워낙 강해서 개발업체 프로젝트 관리자에게 의사소통을 위한 시스템을 구축한 이후로 착수를 미루자며 엄포를 놓았다. 아쉽게도 프로젝트 관리자가 거부하여 기회(?)는 날아갔다. 프로젝트에서 고객과의 활발한 의사소통이 프로젝트 성공에 미치는 영향은 지대하다. 하지만, 당시 프로젝트 관리자는 고객 수장이 블로그를 언급할 때 이미 커다란 오해가 발생했다. 당시 프로젝트 관리자 시각에서는 프로젝트를 하는데 포탈 블로그 운운하는 일은 무리한 요구였다. 포탈 블로그는 업무 시간에는 접근을 차단할 정도로 업무와 무관하다. 더구나 간단하게 구축할 수 있는 프로그램도 아니다. 적어도 그 프로젝트 관리자 눈으로 보면 프로젝트 본질을 벗어난 고객의 무리한 요구일 뿐이었다. 나중에 기회가 생겨 예의 임원이 강하게 의사소통을 위한 시스템을 요구한 배경을 들을 수 있었다. 가장 큰 이유는 정적 조직인 터라 적극적으로 움직이지 않는 부하 직원들의 적극적인 참여를 유발하기 위함이었다. 두 번째는 그 임원이 외국 선진사례 탐방 이후 당시로써는 꽤나 이르지만, Enterprise 2.0 도입 필요성을 실감한 때문이었다. 물론, 그분은 Enterprise 2.0이란 용어를 몰랐지만, 마침 프로젝트가 시작하자 TFT(Task Force Team) 중심으로 활발한 공유와 협업 풍조를 만들 기회로 삼고자 했다.

Enterprise 2.0과 애자일(Agile) 방법론

잘 확립된 체계보다는 주목에 따라 구조를 발전시켜 나가고 혼돈 속에서 질서를 만들어가는 면모는 Enterprise 2.0의 주요 특성으로 알려졌다. 필자는 Enterprise 2.0 전문가는 아니지만, 앞서 언급한 특성은 변할 가능성이 큰 일에는 매우 유용한 접근이라 확신한다. 미래에 일어날 일에 대해 변경하지 않을 구체적인 계획을 수립하고 이를 그대로 따르는 일은 사소한 일에서나 가능하다. 변화에 효과적으로 대처하려면 분명한 비전이나 이정표로 삼을 목표는 수립하되 실천 과정에서 구성원의 참여를 통해 보다 효과를 낼 방안이 만들어지면 역동적으로 방향을 선회할 수 있어야 한다. 필자는 Enterprise 2.0의 태동이 역동적인 환경에 대한 적응력 강화의 일환이라 생각한다.  Enterprise 2.0은 Web 2.0 등의 조류에 기인하고 있으며, 태동 근거가 되는 환경 변화는 사회 여러 분야에 두루 영향을 끼쳤으리라 짐작할 수 있다. 개발 프로젝트에 있어서도 비슷한 영향의 결과가 애자일 방법론이 아닐까? 필자는 이를 전제로 애자일 적용 과정에서 Enterprise 2.0이 지향하는 가치가 드러난 사례를 소개하고자 한다.

 

백로그의 탄력성과 적시성

필자는 요구사항이 매우 모호한 프로젝트를 계획하면서 위험을 줄이기 위해 애자일 방법론을 택한 바 있다. 스크럼(Scrum) 방법론을 채택하고, 우리 팀에게 맞게 변형해 사용하기로 했다. 프로젝트를 준비 과정에서 처음 스크럼을 학습할 때, 여지를 두는 방식의 백로그(backlog)는 어색하게 느껴졌다. 오랜 시간 하향식(Top-down)인 WBS 기준으로 작업을 수행했던 터라 작업을 쌓아두고 특정 기간에 선택하여 일부를 구현하는 방식이 생소하게 느껴졌다. 그렇지만, 익숙해지고 나서 "여지"와 함께 "적절한 시기에 결정하는" 애자일의 이점을 바로 백로그를 통해 체득할 수 있었다. 백로그가 내포한 탄력성과 적시성은 애자일의 굉장한 매력이다. 백로그 항목은 특정 기간에 반드시 완료할 작업을 담지 않는다. 애자일 프로젝트는 보통 개발 기간을 스프린트라는 이름으로 몇 주 이내로 짧게 나누어 관리한다. 스프린트 시작할 때는 고객과 개발팀이 모여 백로그 항목을 늘여놓고 이번에 개발할 대상을 선정한다. 자연스레 지난주까지의 실제 작업 상황에 따라 결과물을 보고 달라진 고객 요구 사항에 따라 얼마든지 백로그 항목에서 우선순위를 바꿀 수 있다. 

그림1. 백로그(backlog) 예시

백로그의 진화

우리 팀은 그림1과 같은 전형적인 백로그 형태를 수정하여 썼는데 얼마 지나지 않아 불편함을 느꼈다. 이렇게 저렇게 바꿔가다가 이슈 트래커를 써서 그림2와 같은 형태로 백로그를 변형했다. 이슈 트래커 채택은 다양한 정보를 집약해서 보거나 개발도구와 연동하는데 유용하기 때문이었다. 먼저 백로그 항목을 이슈 트래커 작업으로 등록했다. 작업을 완료하면 작업 상태를 변경하고 결과물에 대한 설명을 덧붙여 고객에게 알렸다. 고객은 완료한 작업에 기록한 설명을 보고 의도한 대로 구현했는지 확인했다. 보완할 사항이 있으면, 이슈 트래커 작업 항목 하단에 의견을 덧붙였다. 버그가 있는 경우라면 오류 발생 로그나 스크린 샷을 이슈 트래커에 첨부하기도 했다. 이슈 트래커와 연결한 개발도구는 개발자에게 갱신 내용을 알려준다. 개발자는 고객 피드백을 확인하여 즉시 대응할 수 있다. 이슈 트래커로 이전한 백로그는 고객과의 협업 매개체일 뿐 아니라, 관련 정보를 집약하고 개발 이력 정보까지 제공했다. 나중에는 위키와 연계하여 그물망으로 엮인 정보체계를 구축했다.

그림 2. 이슈 트래커 활용 예시

마무리

필자가 소개한 일화만으로 엔터프라이즈 시스템 개발 프로젝트에 Enterprise 2.0 대입하기를 설명하기란 무리일지 모른다. 긴 부연을 더하는 대신 백로그가 진화한 과정을 다시 짚어보자. 출발은 여기저기서 백로그를 수집했다. 수집한 백로그 예제 중에 가장 적절한 형식을 채택하여 초안을 만들고서 고객이 거부감을 갖지 않을 수준으로 단순화했다. 몇주 사용하고 나서 우리 팀에 별로 도움을 주지 않던 공수(effort) 측정 지표를 뺐다. 개발도구와 연동(Eclipse Mylyn)을 통해 작업 관리를 효과를 높이기 위해 이슈 트래커를 설치하고 백로그 항목을 옮겼다. 구두로 추가 요구 사항을 말하면 우리 팀에서 이슈 트래커에 등록해서 백로그 항목으로 삼았다. 일부 고객은 이슈 트래커나 개발도구를 통해 직업 피드백이나 추가 요구 사항을 작업으로 올렸다. 모호한 내용 확인을 위해 개발자는 이슈를 올린 개발자를 찾아가 질문했다. 고객은 점차 다시 구두로 확인하는 시간을 줄이기 위해 피드백 내용을 충실히 기록했다. 코드 일부를 추가하거나 오류가 발생한 스크린 샷이나 로그 파일을 첨부했다. 작업을 완료하면 개발자는 클래스 이름이나 API 문서나 HTML 형태인 도움말 URL을 첨부했다. 개발도구 내에서는 클래스에 바로 접근할 수 있고, URL을 통해 문서를 바로 열어볼 수 있어 고객은 빠르게 결과물을 검토할 수 있다. 이슈 트래커가 웹 애플리케이션이므로 위키나 외부 사이트 내용 링크도 쉽게 할 수 있다. 프로젝트 진행과 함께 요구사항은 이슈(혹은 작업) 단위로 이슈 트래커 올라갔다. 구현을 진행하며 피드백을 위해 코드, API 문서 및 도움말, 산출물에 대한 피드백과 관련 정보 등이 체계적으로 쌓였다. 결과물뿐이 아니었다. 프로젝트를 마칠 즈음 고객과 개발팀 구분은 모호해지고, 대신 뚜렷이 나뉘는 역할을 통해 긴밀하게 협업하는데 익숙해져 있었다.

스프링 3.0 GA(General Availability) 출시가 내일이다. GA란 표현이 생소할 수 있는데 최종 버전 혹은 정식 버전을 의미한다. 스프링 3.0을 공부하고 있지도 않았고, 딱히 최종 버전을 쓰고 싶어 기다린 터도 아니라 동동 구르며 출시를 기다리며 쓴 글은 아니다. 솔직히 고백하면 유치하게도 자랑하고 싶어 올린 글이다. :)

금요일에는 분명히 열린 이슈가 4~5였는데 다시 늘었다.

 
그 중 하나의 이슈에 낯익은 이름이 있다.


Toby형 글을 읽고 메신저로 이야기를 나누다가 발견한 옥에 티다. 스프링의 Javadoc에 대한 신뢰가 있었던 터라 오류가 믿기지 않아 우선 Toby형에게 확인을 부탁했다. 그리고 혹시나 낡은 코드를 보고 뒷북치는 일이 아닐까 해서 스프링 프로젝트 Trunk에 있는 소스를 직접 확인했다. 이미 할당한 작업이 있는지도 보았는데 없었다. 짧은 영어 실력이지만 설명은 어렵지 않았다. 레퍼런스에서 예를 든 내용과 Javadoc에 기술한 제약사항이 정면으로 배치하고 있었기 때문이다.


자랑하려고 올린 글이 민망해 그럴싸한 미사여구를 덧붙이고 싶은 마음이 생긴다. 일요일 낮에 기대하지 못한 경험을 했다. 마찬가지로 #SPR-6546 역시 우연히 알아낸 사항을 별 생각 없이 올린 결과일 뿐이다. 근래에 부쩍 느끼지만, 일의 결과로 맞이하는 상황은 계획했던 모습과 아주 큰 차이가 있다. 삶에서 중요한 일은 상당부분은 우연이라고밖에는 설명할 수 없는 일에서 촉발한다. 하지만, 분명한 사실은 꿈을 꾸고 노력을 했을 때 무언가 결과를 얻었다는 점이다.



언젠가 미래의 내가 이 글을 읽으면 지금의 유치한 나를 떠올리며 입가에 미소를 지을 것이다. 혹시 그 친구가 꿈꾸는 삶의 소중함을 잊어버렸다면 기억하라고 하고 싶다.

• 여자친구에게 유치한 내 꿈을 설명하며 감격했던 마음을
• 고군분투하는 동지와 통닭을 먹으며 동업(同業)이란 말을 새로 배우던 그 날을
• 꿈을 위해 그에 합당하게 준비하는 사람의 모습을
• 그리고, 마음이 하는 말을 듣지 못하는 장애를 극복하라는 누군가의 가르침을
• 연말 구세군 냄비에도 멈칫하지만 말고 사소한 기부라도 시작하자는 마음을
  

(2009-12-14 갱신)

유겐 휄러가 이슈를 수정했다. 오류가 있던 내용은 이랬는데


수정 후(Rev 2645)는

어제는 영양가 없는 글을 비판하는 가운데 Java EE 스펙을 거론했는데, Toby형을 통해 좋은 글을 알게 되었다. RSS 구독이 불가능해 놓치고 있던 한국IBM DW의 칼럼이다. 이창신님의 자바 EE 6에서 의존성 주입은 그야말로 최신 글이고, 새로운 내용을 대하는 독자의 생소함을 생각해 무난히 따라 해 볼 수 있도록 썼다. 그리고, 얼만전까지 Java EE나 Servlet 3.0 과 같은 새로운 스펙에 대한 실용적인 글이 연재되었다.

S 서블릿 3.0에서 파일 업로드 (2009년 10월)

넷빈즈 6.8로 자바 EE 6 시작하기 (2009년 9월)

3년을 기다렸다 (2009년 6월)

Toby 형이 쓴 글도 있다. 자바 스펙을 직접 다루지는 않았지만, 자바 진영에서 일어나는 DI(Dependency Injection)의 발전과정을 그대로 담은 스프링의 애노테이션에 대한 글이다.

Spring 3.0 (56) @Bean 사용의 주의사항

요구하는 배경 지식이 많아 쉽지 않은 글이지만 개념을 잡는데 도움을 주는 글이다. 이를테면 다음과 같은 표현은 충분한 경험이 없다면 쉽게 포착할 수 없는 말이다.


이참에 공부를 좀 할까 하는데, 테스트를 위한 시험 문제도 제공했다.

Toby 형의 설명은 아직 Spring RC3 릴리즈 javadoc에도 반영하지 않은 최신 사항이다. 마침 InfoQ에서도 Java EE 6 Features: Dependency Injection, Bean Validation and EJB Enhancements 라는 기사를 올렸다.

Using a combined SOA and TOGAF environment for increased productivity: Part 1: Introduction to the TOGAF Enterprise Continuum

오늘 DW가 좋은 글을 많이 올린다. 요약을 시작하는 문구부터 마음에 든다.
 

그리고, 현실 인식이다.


이후에 스크랩해 둘만 한 그림이 연속으로 보인다.

최상위 개념도



Architecture Continuum의 여러 상태(혹은 단계)를 나타내는 그림



그리고, 상태 전이(혹은 단계 전진)의 특성을 명쾌하게 정리했다.

• From conceptual to logical to physical
• From technology solutions to business technology systems
• From industry-neutral to vertical business domain-compliant architectures
• From general taxonomies to physical architecture specifications

정리한 항목을 실제로 실현하는 일은 매우 어렵다. 오전에 올린 글만 예로 들어도 현황을 설명할 수 있다. 발표자와 같이 스펙과 제품을 비교하는 일은 AC와 SC 영역을 식별을 못하는 사례다. Java EE와 달리 Spring이 복잡한 이유는 업무를 고려치 않은 범용 기술(industry-neutral)을 특정 현장에서 활용하다 보면 산업적(vertical business domain-compliant architectures), 조직적 혹은 환경적(business technology systems, physical) 요소 들로 인해 변형이 필요하다. 그래서, Java EE 벤더는 표준을 일정 부분 여겼고 SpringSource도 마찬가지다.

중요한 사실은 발췌한 상태 전이 양상은 낱낱으로 드러나지 않고, 혼합된 형태로 드러나 사실 포착하기 적합하게 대응하기 어렵다. (그래서 SoC가 수도 없이 회지되지만...)




마무리로 TOGAF 참조 차트를 올렸다.

The Timeline/Milestone pattern라는 글을 보는데 마침 고민하던 문제라 모델이 한눈에 들어왔다. 결산 프로세스에 대해 고민하던 중이어서인지 꽤 인상적이다. 기사가 다룬 문제는 지표까지 관리한다는 점이나 특정 기술을 전제하고 있어 차이가 있지만, 참조할 내용이 있다는 점만으로도 고마운 그림이다. 도해(diagram)를 사용함에 있어서도 문제 상황을 보여주는 그림



정보의 구성을 다룬 그림


그리고, 주요 상태도




시스템 수준의 큰 그림




핵심이 되는 컴포넌트의 상호작용을 그린 그림은 훌륭한 모델링 결과이고 효과적인 전개다. 모델링을 하려면 이 정도는 해야 할텐데...

JBoss 월드에서 "Java EE and the Spring Framework: Compare/Contrast"란 제목의 발표가 있었나 보다. 웹에 발표자료를 공개하고 있다. 작동하는 제품이 아니라 스펙인 Java EE와 제품을 비교하는 이유가 궁금했지만, 결국 잘 포장된 FUD로 컨퍼런스 참가자를 현혹할 의도가 아니었나 의심하게 하는 내용이 눈에 띈다. 출발점과 결론을 기록한 박스의 내용은 수긍이 가지만, Java EE와 Spring 프레임워크 비교는 한심하다. 이제는 지루할 지경인 XML 논쟁이 2009년에도 등장한다. 만일, 스프링 설정이 복잡하다고 기술적인 비교를 하려면 정의에 지나지 않는 Java EE가 아니라 Java EE를 구현한 제품의 모든 설정과 Spring(혹은 Spring + Tomcat)이 요구하는 설정을 비교해야 하지 않을까?


Java EE 두 번째 항목을 보면 발표자의 수준을 의심할 수 있다.

Non-redundant APIs with specialized roles

꾸러미 성격의 스펙을 만들면서 일부러 중복을 만드는 이가 있을까? 반면 API를 구현한 제품은 어떤가? 하나의 표준(Spec)을 준수하는 다수 제품을 통해 경쟁하던 모습이 자바 커뮤니티의 강점 아니었던가? 'Non-redundant APIs'라는 표현을 쓴 이유는 다음 장표에서 확인할 수 있다. Java EE는 간결하고 Spring은 복잡한 듯 보인다. 저자가 추상화 수준(level of abstraction)이라는 개념을 탑재한 사람이라면 Java EE 를 표현한 박스 위에는 초록색으로 JBoss JSR250 implementation, IBM JSR250 implementation, Oracle JSR250 implementation 이라고 표기해야 옳다. 어떠한 기능을 구현한 제품(iBatis, Hibernate, TopLink)과 기능을 기술한 명세를 비교하는 짓은 한심하지만, 박스 그림 차체는 고쳐서 써먹을 만하다. :) 혹시라도 저자를 만난다면, "선택하는 고통"을 피하고 싶다면 닷넷으로 전향하란 충고를 해줘야겠다.


저자가 Spring에 대해 무지하지 않다는 점은 뒤에 나오는 장표가 잘 보여준다. 스펙과 제품 사이의 추상화 수준 차이에서 오는 Gap을 잘 활용하여 Spring에 대한 안 좋은 인상을 심어주려는 노력이 돋보인다. 보수일간지가 마음에 안 드는 인물은 얼굴을 찡그리는 사진만 싣듯이 화면의 반을 XML 스키마 정의에 할당해서 복잡함을 극대화해서 보여준다. 놀랍게도 Spring 설정이 나오는 모든 페이지를 중요치도 않은 XML 스키마로 덮었다.


그야말로 무의미한 일인데, 왜 Spring과 Java EE를 직접 비교할까? 2년도 더 지난 TSS 아티클에서 거론한 현상 탓이다. Spring의 인기가 높아질수록 Java EE는 힘을 잃고 있다. 변화를 깨닫지 못하는 이들의 공통점은 달라진 상황에 대해 남 탓에 무엇을 잃어버렸다고 인식한다는 점이다. Spring은 J2EE 기술에 기초하여 만들어졌고, Java EE 스펙에 대한 의존도가 줄어도 여전히 Java EE 수용에 앞장서고 있다. 심지어 스펙을 앞서 지원하는 일까지 있으니 말이다.

별생각 없이 보면 잘 만든 장표처럼 보일 수 있지만, 결국은 잘못된 전제를 활용한 세련된 FUD이다. 교훈이라면 추상화 수준(Level of Abstraction)을 어기면 어떤 함정에 빠져 시간을 허비하거나 어처구니 없는 사기에 현혹되기 쉬운지 알 수 있는 사례다.

마침 DW에 올라온 글을 보고 어제 트위터에서 본 후배의 푸념이 생각났다. 예전에 형상관리도구 사용에 반감을 품은 개발자를 개발자/팀을 자주 만나곤 했다. 파일서버를 쓰거나 빌드 시점에서 한꺼번에 코드를 통합해오던 습성을 가진 개발자/팀에게 형상관리시스템 적용은 코드를 관리가 어렵게 하는 제약으로 비춰지는 듯하다. 그도 그럴 것이 SVN을 쓰고 나서는 골치 아픈 충돌을 해결하는 과정이 생겨 무척 번거롭게 볼 수도 있다.

요즘은 CI 도구를 사용하는데, 뒤로 미루던 통합 작업을 당겨서 일상으로 만드는 역할을 한다. 만일, SVN/CVS 사용에 큰 무리가 없는 팀이라면 CI 도구 적용에 큰 거부감이 없다. 하지만, SVN/CVS을 파일서버 대용으로 쓰는 식으로 충돌이 발생하지 않게 작업하는 조직이라면 CI 도구 적용은 요원할 수 있다. 보통 이런 팀은 통합을 뒤로 미루다가 오픈을 못하기도 한다.

소개한 글에 제시한 3단계가 마음에 와 닿는다. 긴 글의 핵심을 담은 그림도 훌륭하다.

Communicate, collaborate, innovate

Ray 님의 글 뛰어난 개발자는 타고 나는 것에 동의하지만, 다른 생각을 더하고 싶어 주말에 글을 쓴다. 시스템이 점차 복잡해지면서(코드량 증가 뿐 아니라 다양한 프로그래밍 언어나 설계를 섞어 쓴다.) 알고리즘을 실제 구현 양상을 크게 달라지는 듯하다. ^[각주:1] 알고리즘이나 자료구조 책에서 다루는 원리는 여전히 유효하다. 그러나 책에 나오는 실제 코드는 용도가 매우 제한적이다. 이제는 알고리즘 구현체가 디자인 패턴의 모양을 띠는 일은 흔하다.

실무 경험이 늘수록 수학의 필요성을 절감한다. 수학은 개인차원의 문제 해결력이나 사고력에 있어 효용을 극대화하는 학문임을 피부로 느낀다. 하지만, 그에 못지 않게 중요한 능력이 바로 의사소통 능력이다. 사회가 복잡해지면서 혼자서 할 수 있는 일이 극히 드물다. 프로그래밍만 다루던 개발자도 업무 현장의 필요성에 진심으로 귀를 기울이지 않으면 비용 대비 효과가 매우 낮은 시스템을 구현한다. 또한, 날로 변하는 기술을 익힘은 물론 기술에 대해 선택을 해야 할 때는 업무 현장의 필요성에 따라서 최종 사용자의 언어로 바꾸어 말하는 기술도 필요하다.

최근에 애자일 조류가 기술보다는 문화나 팀의 성숙을 이야기하는 이유도 시대적 맥락 탓이라 생각한다. 묻지마 전산실을 지나 초창기 소프트웨어 공학(혹은 제대로 프로그램을 작성하는 일)에 눈을 뜬 산업이 그동안 버려뒀던 영역에 관심을 돌리는 것이다. 당시에는 어린 아이였지만, 박정희 대통령 주도로 새마을 운동하던 시절에 묻지마 경제 성장을 한 후에 지난 10년간 인권이나 권위주의 철폐에 시야를 돌린 것처럼. 물론, 현 정부에서 과거로 회귀하려는 관성이 느껴지지만, 항상 흥망성쇄를 거듭하며 진화하는 법이니까. 결론이 이상한 방향으로 흘러갔지만, 현대 개발자에게 있어 문제 해결을 위해서는 논리적인 명석함 만큼이나 의사소통 능력이 중요하다.

Adrian Colyer 가 일 년에 4개^[각주:1] 정도 글을 올리는 Adrian Colyer 가 포스팅을 했다.

Gemini project proposal at Eclipse.org

"쌍둥이자리"를 뜻하는 제미니를 별칭으로 하는 엔터프라이즈 모듈스(Enterprise Modules) 프로젝트를 소개하는 글이다. Eclipse Runtime Project 아래 제안한 제미니 자체도 여러 하위 프로젝트를 거느리는 Umbrella Project ^[각주:2]이다. 제안 내용을 찬욱군이 간략히 정리했는데, 범위를 보면 지향하는 윤곽을 짐작할 수 있다.


제안 내용과 Adrian Colyer 의 글을 읽으면서 JEE 진영이 한 바퀴 돌아 두 번째 반복에 진입했다는 생각이 들었다. 달라진 점은 일식(Eclipse) 탓인지 태양(Sun)의 위상이 바뀐 모습이었다. 과거 Sun이 주도한 JCP에서 이룩한 J2EE에서 컴포넌트 기술이 등장했다. 자바의 컴포넌트 기술은 실행 중에 여러 배포 버전을 관리할 수 있는 동적인 모듈의 세계로 발전하고 있다. 적어도 엔터프라이즈 분야에서는 OSGi가 가장 앞선 듯 보인다. 엔터프라이즈 부문 초기 노력(being developed by the Enterprise Expert Group)은 제미니를 중심으로 위상을 갖추고 있다. OSGi R4.2 스펙 일부 이름이기도 한 Blueprint Service 참조구현(RI)이 Spring Dynamic Modules v2 란 점도 흥미롭다. EJB가 부상하던 시절 "어떻게 프로그램을 짤까?"에 대한 답으로 Sun이 청사진(BluePrint)를 내놓았는데, OSGi 기반에서는 스프링소스가  그 역할을 하고 있고, 그 산물은 이클립스 커뮤니티를 통해 발전하려 하고 있다.

뒤이어 스프링소스의 Costin Leau가 Spring and OSGi 메일링에 Spring Dynamic Modules v2 moving to Eclipse Gemini project 라는 글을 올렸다. 제미니에 대한 공지인데 자세한 정보는 링크로 대신했다.

1. 필수 플러그인 설치

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

2. 설정 변경

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

3. 튜닝

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

eclipse.ini 예제

더보기

참고:

• Optimize Eclipse in 5 Steps
  

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


- 훈련 필요


- Fact to Act

벤자민의 글을 보고 돌연!

벤자민의 선택:

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

아래는 내 선택:

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

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

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

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

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

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

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


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

추가한 내용:

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

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

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

더보기

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


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

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

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

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

Update 주소 메모할 겸 기록함

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

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

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

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

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

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

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

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

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

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


HKLM과 HKCU 차이는 무얼까?