Younghoe.Info (final edition)

ThoughtWorks Anthology의 Iteration Manager를 번역하는데 특정 산업에 대한 이야기가 없는 가운데 'the industry'라는 표현이 나온다. 어떻게 번역해야 할까? 하는 생각은 내가 속한 산업 구분으로 번졌다.

찾아보니 UN이 정한 ISIC(International Standard Industrial Classification)가 있고, 2008년 현재는 4번째 개정판이 존재했다. 최상위 코드는 A부터 U까지 21개다. 최상위에서 고르긴 어려워 모든 코드가 보이는 페이지에서 'computer'를 키워드로 검색해보니 3건이 걸러진다.

26 - Manufacture of computer, electronic and optical products(C - Manufacturing 하위 코드)

62 - Computer programming, consultancy and related activities(J - Information and communication 하위 코드)

95 - Repair of computers and personal and household goods(S - Other service activities 하위 코드)

ISIC Rev 4.를 적용하면 크게는 J - Information and communication 산업으로 분류할 수 있다. 흔히 IT 산업이라고 부르는 '정보통신'이다. 눈에 띄는 사실은 62와 유사한 63 - Information service activities 분류다. 컴퓨터 프로그래밍, 컨설팅 및 관련 활동과 정보 서비스는 무슨 차이일까? 63은 둘로 나뉜다.

631 - Data processing, hosting and related activities; web portals

639 - Other information service activities

631은 또 하위를 둘로 나누고 있다.

6311 - Data processing, hosting and related activities

6312 - Web portals

62(620)과 6311은 미묘한 중첩이 있지 않나 싶어 세부 사항을 찾아보았다. 620은 다시 3분 하고 있었다.

6201 - Computer programming activities

6202 - Computer consultancy and computer facilities management activities

6209 - Other information technology and computer service activities

PC 설치(6209)와 메인 프레임 설치(3320)는 최상위 구분부터 다르다. 메인 프레임 설치는 산업 장비 설치와 수리로 분류하여 제조업(33)에 속한다.

6311 상세 설명을 보면 62(620)와 경계가 드러난다.

1. 참 대단한 일입니다. 국내 환경에서 오픈 소스 활용이 아닌 오픈 소스 개발은 흔한 일이 아닌데 계기나 배경을 여쭤보겠습니다.

우선, 저를 간단하게 소개하겠습니다. 직장 9년, 소프트웨어 개발회사 대표 11년, 프리랜서 10년으로 모두 전산 경력이 30년입니다. 소프트웨어 회사를 할 때에도 1~2개 프로젝트는 제가 직접 수행을 했으니 소프트웨어 개발자로서 30년을 살았군요. 주변에 손자/손녀 재롱을 보면서 살아가는 친구도 있는데, 머리 싸매가면서 자판을 두드리고 있으니 무엇 하고 있는 건지 모르겠네요. :)

개발 배경, 계기

이것, 이야기하자고 하면 말이 길어집니다만, 한마디로 말하면 자존심이 상한다는 것입니다.
세계적으로 알려진 Ajax 관련 라이브러리가 미국에서 발표되고 있는데요, 자칭 소프트웨어 강국이라고 하는 대한민국에는 없다는 것입니다. 그들이 만든 것이 좋은 소프트웨어이기는 하지만 우리가 못 만들 정도는 아니라는 것에 더욱 화가 났습니다.

어쩌면 오기심의 발동이라고도 볼 수 있습니다만, 이는 제가 개발하는 것을 좋아하기 때문에 생긴 것인지도 모르겠습니다. 자기 자신이 좋아하는 일에 매진할 수 있다는 것, 행복한 인생이 아닐까요… 그런데요, 처음 개발을 준비할 때에는 이런 마음이었습니다만, 지금은 “하지 않으면 안되기 때문에 반드시 해야 한다.”라는 생각을 하고 있습니다.

제가 아니라도 누군가가 반드시 이 일을 해야 합니다. 바다 건너에서 새로운 기술이 나왔다고 하면 이를 도입/발표하는 사람이 선구자로 대접받았던 것이 지난 30년의 모습입니다. 정제도 없이 검증도 없이 마구잡이로 도입되었습니다. 여기까지는 그래도 좋습니다. 여기에 상업적인 면이 가미되면 시간 주고 돈 주는 아주 우스꽝스런 모습이 연출됩니다. 개발자는 광대이자 마루타일 뿐 실속은 딴 사람이 챙겼다는 것입니다.

그렇다고, 이렇게 비싼 대가를 치른 소프트웨어를 제대로 사용하지도 못했습니다. 이는 원천 기술을 확보하지 못하고 껍데기로 사용법만 익혔기 때문입니다. 버전이 올라갈 때마다 돈과 시간으로 해결해야 했습니다. 이젠 이런 어리석은 모습에서 하나씩 벗어나야 합니다. 적어도 대가를 치른 소프트웨어를 제대로 사용할 수는 있어야 합니다.

어떻게 보면 제가 지금 미친 짓을 하고 있는지도 모릅니다. 시쳇말로 돈도 안 되는데 만사 제쳐놓고 이 일에 몰두하고 있으니 한심하다고 할지도 모르겠습니다. 그런데요, 세계적으로 유명한 소프트웨어는 처음엔 저 같이 미친 사람이 만들었다는 것입니다. 하기야 미치지 않고서는 세계적으로 유명한 소프트웨어가 탄생할 수도 없습니다. 개발자의 혼이 담겨 있는 소프트웨어야말로 사랑을 받을 자격이 있으며, 혼이 담겨야만 아름다운 소프트웨어가 되기 때문입니다.


2. Method Chain이라는 이름이 생소한 분들이 많을 텐데 간단히 소개를 부탁합니다.

시나리오가 중요해!

저는 시스템을 개발할 때 시나리오를 매우 중요하게 생각합니다. 요구분석 단계에서 적어도 메서드 단위까지 시나리오를 정립하지 않으면 절대로 더는 진척을 하지 않습니다. 너무 자세한 것이 아니냐, 그것이 가능하냐라는? 반문도 나올 수 있습니다만, 이를 철저하게 지킵니다. 이렇게 하지 않으면, 보나 마나 중반 이후부터 우왕좌왕하게 될 것이며 이로 말미암아 여러 사람 고생하게 되고, 저 또한 마음에 상처를 받게 될 것이기 때문입니다.

가보지도 않은 먼 길을 전부 종이 위에, 머릿속에 그린다는 것이 만만치 않습니다만 이 점을 염두에 두고 경험을 쌓아가면 그리 어려운 것도 아닙니다. 이런 것이 습관화되면 사용자의 요구 사항을 들음과 동시에 머릿속에 아키텍처가 연상되고 클래스와 코드가 그려지기도 합니다.

다른 관점에서 보면 시나리오가 없다는 것은 목적지를 향해 무작정 걸어가는 모습이 될 수도 있습니다. 그 길엔 강도 있고 산도 있을 것입니다. 이에 대한 대책도 없이 걸어간다는 것은 홀가분하게 떠나는 여행이나 가능하지 않을까요?

한편, 이런 모습을 하는 저에게 사용자는 물론이고 개발자로부터도 곱지 않은 시선을 받는 적도 있었습니다. 하지만, 분명한 것은 요구분석 단계에서 갖은 고생을 하더라도 시나리오를 확고하게 수립하면, 프로젝트가 종료될 때 고객으로부터 박수를 받는다는 것입니다.

시나리오가 있다는 것은 전체를 보고 있다는 것을 의미하며, 앞으로 발생할 것을 예측하고 있다는 것을 의미합니다. 또한, 길목을 지키고 있다는 것을 의미합니다. 이를 기준으로 열심히 걸어가기만 하면 프로젝트에 성공할 수 있다는 확신을 할 수 있습니다.

기술적인 관점에서 보면 시나리오상의 각 요소는 서로 유기적으로 연결되어 연동하고 있다는 것을 의미합니다. 이것이 MathodChain의 기본 사상입니다. 기술적으로 유명한 세계적인 소프트웨어는 사상과 철학을 가지고 있습니다. 이를 이해하지 않고 기능적으로 접근하는 개발자가 있는데요, 이는 겉모습을 보고 접근하는 것과 같습니다. 물론, 처음부터 이를 이해할 수 없겠지만, 되도록 빨리 이를 간파해야 알맹이를 사용할 수 있습니다.

사상과 철학을 갖지 않는 소프트웨어는 코드의 나열에 불과하므로 발전에 한계가 있습니다. 즉 일회성이라는 것입니다. 유명 예술가가 독창적인 작품을 지속적으로 제시할 수 있는 것은 그 나름대로 사상과 철학이 있기 때문이며, 우린 그런 사람의 작품을 높게 평가합니다.

MethodChain은 코드가 유기적으로 연동하기 위한 메커니즘을 갖고 있으며 앞으로 발전 시나리오도 갖고 있습니다. 하나의 완성된 도자기를 만들려고 수없이 많은 도자기를 부수듯이 이를 정립하려고 몇백 줄 아니 1,000 줄 이상을 부수고 다시 짠 적이 한두 번이 아닙니다.

3. 'Ajax prototype.js : 프로토타입 완전분석'이라는 prototype.js에 대한 심층 분석 서적을 출간하신 바 있는데, 그때 경험이 Method Chain을 시작하는데 어떤 영향을 미쳤나요?

한마디로 음과 양으로 지대한 영향을 미쳤다고 할 수 있습니다. 앞서 사상과 철학에 대해 언급했습니다만, prototype.js는 정통파라고 할 수 있습니다. 기술자로서 원론적으로 접근하려고 애써 고민한 흔적이 여기저기에 있습니다. 하지만, 너무 코드 측면에서 정통을 지키려다 보니 다른 것을 놓쳤다고 할까요, 그런 점이 있습니다. 자바스크립트의 장점을 살리는 것에는 충실했지만, 단점을 보완한 구조를 만들었으면 하는 아쉬움도 남습니다. 그러다 보니 확장성에 조금 어려움이 있다고 할 수 있습니다.

처음 prototype.js를 접했을 때 코드가 그리 크지 않았고 일부 코드는 쉽게 눈에 들어왔으므로 스쳐 지나갔지만, 조금 시간이 흐르고 다시 접했을 때 풍기는 냄새가 달랐다고 할까요. 하여튼 분석을 하겠다고 결심하는 데까지 몇 번씩 생각을 바꾸었지만 지금 생각하면 분석한 것을 잘했다고 생각합니다. 여담입니다만, 코드를 분석할 때 잠자리에 누었는데 코드가 천장에 그려지기도 했습니다. 이런 미친 나날을 보내면서 어느 정도 개발자의 사상과 철학을 이해하게 되었고 아울러 비판력도 생겼습니다. 그랬더니 코드 분석이 더욱 재미있어지고 조금 더 근본적으로 접근하고 싶다는 생각도 들었습니다.

위로 거론된 책이 절판되어 이런 글을 쓸 수 있습니다만, 책이라는 한계 탓에 분석하면서 메모로 남겼던 더욱 근본적인 사항들을 쓸 수 없었으며 이는 결국 2008년 5월에 출판된 ‘웹 표준 Ajax DOM 스크립팅’이라는 책을 쓰게 된 동기가 되었습니다.

이런 일련의 홍역을 치르면서 우리나라는 왜 이런 것을 만들지 못할까? 라고 생각하게 되었으며, 그로부터 한 달 정도 시간이 지나고 개발해야겠다고 결심하고 이에 대해 준비를 했습니다. 그리고 지난여름 본격적으로 개발을 시작했습니다. 그때부터 집중력을 높이려고 낮과 밤을 바꾸었고 처참하리만큼 전체 시나리오를 수립하는데 몰입을 했습니다. MethodChain은 앞으로 1년 이내에 약 25,000줄 규모가 될 것입니다. 이는 아직 개발을 하지는 않았지만 25,000줄에 대한 시나리오를 수립했다는 뜻이 되기도 합니다. 안영회님을 만났던 때가 촛불 집회가 한창이던 시기였는데, 그때는 시나리오가 어느 정도 정립되어 가는 시점이었다고 생각됩니다.


4. 요즘 한창 인기를 구가하는 jQuery에도 Chain 개념(http://ejohn.org/blog/ultra-chaining-with-jquery/ )이 등장하는데 Method Chain과 연관이 있는가? 둘을 비교해주실 수 있나요?

자신이 만든 것과 다른 사람이 만든 것을 비교한다는 것이 조심스럽습니다만, 지금으로서는 비교할 사람이 없으므로 제가 조금만 비교를 해보겠습니다. 비교를 하기 위한 전제조건은 두 가지 모두를 거의 완전하게 숙지해야 한다는 것입니다. 즉, 개발자의 사상과 철학을 이해해야 한다는 것이 되는데요, 그 정도까지는 지면 관계도 있고 하여 아키텍처 측면에서 조금만 비교를 해보겠습니다.

jQuery는 메서드를 연결해서 사용할 수 있는 Method Chain 개념을 갖고 있습니다. 이는 유연성과 편리성을 갖고 있다는 것을 내포합니다. 그런데 이런 것을 인위적으로 만들어서 제공하고 있다는 것입니다. jQuery의 유연성과 편리성은 Selector를 근간으로 하고 있습니다. 여기서 Selector를 근간으로 한다는 점에 주목할 필요가 있습니다.

세계적으로 유명한 Ajax 라이브러리의 Selector 관련 클래스를 보면 400에서 700라인 정도가 하나의 묶음입니다. 이는 하나의 조건을 select 하려고, 이 많은 코드를 실행해야 한다는 것을 의미합니다. 특히 IE는 XPath를 지원하지 않기 때문에 XPath 기능을 날로 실행해야 합니다. 즉, 내부에서 이를 위한 메서드를 만들어서 실행하는 형태입니다. MethodChain의 경우 Selector 클래스 규모가 560라인 정도 됩니다만, 아무리 간단한 조건이라고 할지라도 for 루프를 한 번으로 간주하더라도 200라인 이상을 실행해야 합니다. 조건에 따른 메서드를 만들고, 이를 실행하고, 정제하는 과정을 거쳐야 합니다. 물론, 근간의 클라이언트 환경이 좋아 이 정도의 속도가 애플리케이션 실행에 영향을 미치는 것은 아닙니다. 하지만, 이미지 몇십 개를 처리하거나 텍스트 형태의 콘텐츠를 처리하기에는 편리하지만, 대량의 데이터를 처리해야 하는 기업의 비즈니스 환경에는 다소 어려움이 있을 것으로 예상합니다. 예를 들어 10개의 칼럼을 가진 1,000건의 판매 데이터를 웹 페이지에 뿌린다고 할 때 10,000항목이 됩니다. 여기에 Select 처리를 위해 200줄을 수행해야 한다면 2,000,000이 됩니다. 또 항목마다 click 이벤트가 발생할 수 있으며 이를 위한 처리가 50줄 정도가 된다고 한다면 100,000,000줄을 실행해야 한다는 수치를 도출할 수 있습니다. 데이터를 처리하려면 이것만 필요한 것이 아닐 것입니다. 사용자 인터페이스 관련 처리, 데이터 입력에 따른 에러 체크 등 다수 기능이 항목마다 발생한다면 이는 매우 많은 실행을 요구받게 될 것입니다. 어쩌면 저의 기우인지도 모르겠으며 훌륭한 개발자이므로 이에 대처할 것으로 생각됩니다만, 다소 확장성에 어려움이 있지 않을까라는 생각은 하고 있습니다.

Method Chain은 기본적인 아키텍처가 메서드 체인을 위한 구조로 되어 있기 때문에 Selector를 사용하지 않습니다. 또 인위적으로 연결한 형태가 아니므로 확장성도 높습니다. 이는 결국 실행속도에 영향을 미치게 될 것으로 생각됩니다.

그간 4GL로 개발되었던 애플리케이션이 웹 환경으로 전환하지 못했던 이유 중의 하나가 대량의 데이터를 처리함에 어려움이 있었기 때문입니다. 지금 정확하게 자료를 제시하는 것이 좀 그렇습니다만, 그간의 테스트 결과와 Method Chain의 아키텍처를 볼 때 UI가 포함된 10,000항목을 3초 이내에 뿌릴 수 있을 것으로 생각하고 있습니다.


5. 사이트를 우리말 외에 영어와 일어로 서비스하던데 직접 작업하시나요? 도와주시는 분이 있다면 어떤 분들인가요?

일본어는 제가 번역을 하고 있고요, 영어는 두 사람이 도와주고 있습니다. 그런데 공교롭게도 한 사람이 갑자기 영장을 받아 1월 6일 늦둥이로 군에 입대했습니다. 또 한 사람은 직장이 바빠 저도 미안하게 생각할 정도입니다. 이 자리를 빌려 영작 가능하신 분, 참여를 부탁합니다.
메일 주소는 다음과 같습니다:



조선족이 한국말을 잘하더라도 때로는 어색하며, 한국 사람이 쓴 글도 사람에 따라 차이가 있습니다. 한편, Ajax 라이브러리 사이트라는 경계도 있고 소스 코드, 샘플이 있으므로 너무 정교한 번역은 필요하지 않다고 생각됩니다. 그냥 번역기로 돌려서 체크, 수정하는 정도면 될 것 같습니다. 참, 몇 개월 후에는 중국어 버전을 공개할 것 같습니다. 중국에서 대학을 다녔고 지금은 통역 대학원 졸업을 앞둔 딸의 친구가 다음 주부터 도와주겠다고 했습니다.


6. 끝으로 Method Chain 프로젝트 종국의 목적이나 앞으로의 비전에 대해 한 말씀 해주시죠.

제가 생각하는 앞으로 전체 시나리오는 5단계입니다만, 전체를 제시하기에는 어려움이 있으므로 두 단계만 제시하려고 합니다.

Framework 개발이 1단계이고 widget 버전 개발이 2단계입니다. 1단계는 현재 진행 중이며 2월에 약 1,000줄 정도를 발표할 예정입니다. 이것으로 Framework 개발을 일단 완료할 것입니다. 소소하게 기능 추가는 발생하겠지만, 클래스 규모의 개발은 당분간 없을 것입니다.

2단계인 위젯 버전은 3월에 첫 버전을 발표할 예정입니다. 위젯 버전을 발표하고 전 세계 개발자들에게 평가를 받으려고 생각하고 있습니다. 지금은 Framework 상태이고 이미 세계적으로 알려진 라이브러리들이 있어서 위젯 버전 개발에 전념하고 있습니다만, 위젯 버전이 나오면 세계적인 라이브러리들과 자웅을 겨루어 볼 만 하다고 생각하고 있습니다.

소스 라인으로 소프트웨어의 규모와 기능을 판단하는 것이 마음에 들지 않지만, 발표할 위젯 버전의 소스 라인을 기준으로 세계적으로 유명한 라이브러리와 비교한다면 3위 정도가 될 것으로 생각합니다. 웹 환경에서 실행되는 라이브러리이므로 규모가 너무 커도 문제가 될 수 있고, 규모가 크다고 좋은 소프트웨어라고도 할 수 없습니다만, 그래도 어느 정도 규모가 되어야 할 것으로 생각합니다.

비영어권이라는 점, 미국으로부터 일본, 인도를 거쳐 유럽까지 펼쳐져 있는 보이지 않는 장벽이 있습니다만, 이를 헤치고 나갈 방법을 찾아보겠습니다.

라이브러리를 선정할 때 고려 사항 중의 하나가 미래의 확장성과 발전성을 들 수 있습니다. 그런데 이를 판가름하기 어렵다는 것입니다. 또 개발자의 말만 듣고서 판단할 수도 없습니다. 이때 참조할 수 있는 것이 라이브러리가 가진 아키텍처라고 생각합니다. 즉, 얼마나 구조적으로 튼튼한가를 점검해야 하며, 이를 통해 앞으로 개발될 기능을 예측할 수 있습니다.

아무리 좋은 소프트웨어라고 할지라도 유용하게 사용하지 않으면 그 효과는 반감될 것입니다. 이는 교육을 통해 달성할 수 있다고 생각합니다. 끝으로 제가 지금 한국 말을 하고 있다는 것입니다.

후기: 한국어 맞춤법/문법 검사기 쓰기 선언에 따라 보내주신 인터뷰 내용을 맞춤법, 스팸 방지, 가독성 향상 등을 위해 일부 수정했다. 교정을 위해 읽으면서 5번 항목 답변을 읽을 즈음에는 감동했다. :)

prototype.js가 자바 스크립트 라이브러리를 프레임워크 수준으로 승격한 1세대였다면 지금은 마치 춘추 전국시대와 같다. YUI, jQuery, dojo, ext, mootools 등이 고루 인기를 얻고 있다. 특히 dojo와 jQuery에 관심이 갔는데, IBM DeveloperWorks 웹 개발 분류에 좋은 기사를 번역해서 게재했다.

jQuery 기사
jQuery로 작업하기, 3부: jQuery와 Ajax로 RIA 만들기
jQuery로 작업하기, Part 2: 내일 나올 웹 응용을 오늘 구현해보자
jQuery로 작업하기, Part 1: 브라우저로 데스크톱 응용 옮기기
Ajax로 사이트 전면 개편, Part 4: 기존 사이트를 jQuery와 Ajax forms를 사용하여 개선하기
Ajax로 사이트 전면 개편, Part 3: jQuery, Ajax 탭, 회전식 슬라이드쇼로 기존 사이트 개선하기
Ajax로 사이트 전면 개편, Part 2: jQuery, Ajax, 툴팁, 라이트박스로 기존 사이트 개선하기
jQuery로 Ajax 개발을 단순화 하기

dojo 기사
Dojo Objective Harness를 이용한 웹 2.0 애플리케이션 단위 테스트
전문가다운 Ajax 애플리케이션 개발, Part 3: DWR, 자바, Dojo 툴킷을 사용하여 자바와 자바스크립트 통합하기
Dojo로 HTML 위젯 개발하기 (한글)
Dojo와 WebSphere Portal을 사용하여 클라이언트 측 포틀릿 간 통신 구현하기
Dojo와 DB2를 함께 Ajax로 사용하여 웹 애플리케이션 개발하기

자바 스크립트에 대해서는 잘 모르는 축에 속하지만, 시범적으로 사용해본 결과 jQuery는 문법의 간결함과 유용한 플러그인이 강점이고, dojo의 경우 자바 개발자에게는 API가 친숙했다. 상대적으로 무거운 느낌이 단점이다. 이유는 모르지만, Spring 웹 개발팀에선 dojo를 택했다.

한편, 오픈소스 Ajax 라이브러리 Method Chain 개발자 인터뷰를 보면 jQuery 아키텍처의 취약점을 설명하고 있다. 오는 2월 28일에 있을 JCO 콘퍼런스에서 Method Chain 개발자인 이벤트님이 "MethodChain과 Ajax 애플리케이션 아키텍처 구축 방안"이란 제목으로 70분간 강연을 할 예정인지라 관심 있는 분은 기억하시길.

얼마 전 개발 일정을 줄이는 방법-테스팅의 오류를 거론한 글을 쓴 바 있다. 간과할 수 없는 오류가 있어 짚고 넘어갔으나, 후속으로 블로고스피어에 등장한 글을 보면 내 글 역시 균형잡힌 내용은 아니다. 칼럼 필자의 이전 칼럼을 읽어 보면 개발 일정을 줄이는 방법-테스팅을 통해 진짜 하고 싶은 말이 무언인지 짐작할 수 있다. 정작 하려던 말을 골자는 우리는 개발자가 테스트해요. 에서 주장하는 바가 아닐까? 개발자에게 테스트 책임을 전적으로 위임하는 일은 위험하다.

자급자족(?)이 아닌 이상 최종 사용자의 요구에 맞는 결과인지를 판단 주체가 개발자일 수는 없다. 내용이 아닌 절차 측면에서 보면, 작업 주체가 합격 여부를 결정한다면 상대적으로 객관성이 떨어질 수밖에 없다. 개발과 검증은 분명히 다른 성격의 일이다.

검증 방법의 하나가 테스트인데, 테스트는 수행 주체, 목적 및 대상에 따라 구분할 수 있다. 혼자 개발하는 경우가 아니라면 특정 개발자가 만든 코드와 다른 개발자가 만든 코드를 합쳐서 하나의 시스템으로 수행하는 경우가 흔하다. 보통, 통합(Integration)이라고 부르는데 통합이 수월하게 하고, 이전에 만든 코드를 수정할 때 영향도 파악이 수월하게 하려면 개발자 테스트를 만들어야 한다. 이러한 개발자 테스트는 앞서 언급한 검증 목적으로 수행하는 테스트와는 구분할 수 있으며, HelloWorld 규모가 아닌 이상 자동화 테스트가 필수다.

프레임워크나 라이브러리와 같이 개발팀이 만든 코드를 사용하는 애플리케이션이 많아지면 유기적으로 구축한 자동화 테스트^[각주:1]가 얼마나 중요한지 알 수 있다. 비슷한 수준의 버그 수정이나 기능 추가 요청이 있을 때, 자동화 테스트를 잘 갖춘 코드는 쉽게 반영할 수 있다. 그러나 자동화 테스트가 없는 코드에 대해서는 수정을 망설일 수밖에 없다. 유지보수 담당자가 간단한 기능 추가에 대해 신경전을 벌이는 이유는 천성이 게으르기 때문은 아니다. :)

직전에 언급한 자동화 개발자 테스트의 중요성을 간과할 수 있어 역시 IBM DeveloperWorks 칼럼의 주요 필자인 토비님과 김창준님이 글을 썼다고 이해할 수 있다.

한편, 케빈 님은 한발 더 나아가서 칼럼 저자의 의도를 유추하여 정정을 시도하고 있다.

Abel Avram이란 사람이 InfoQ에 초 압축 기사를 올렸다. 1시간 18분짜리 긴 강의를 소개하는데 글감 목록 정도만 나열하고 직관적인 표하나만 떨렁 올렸다. 강의를 들어보면 더 깊이 있는 내용이 있을지 모르겠지만, 데모도 없을 법한 영문 강의를 한 시간 이상 견딜 수 있을지는 의문이다. ㅡㅡ;

아무튼, 인용한 비교표는 Anemic Domain Model, Domain Driven Design 등의 이야기가 나오는 배경의 골격을 잘 포착하고 있다. 한편, 자료처리에서 출발한 기업 정보시스템 개발 분야에서 객체지향 바이블 성격의 초기 이론서를 고스란히 구현한 예를 보기 어려운 근본적인 이유이기도 하다.

Data-Driven Design	Responsibility-Driven Design
Centralized control	Delegated control
Controllers	Coordinators
Inherited attributes	Inherited behavior
Many low-level messages	Fewer, higher-level messages
Lots of simplistic information holders	A few smart objects that blend role stereotypes

IBM DW 칼럼으로 올라온 글에 대해 일민형이 의견 개진을 요청했다. 글을 읽어보니 주장하는 바가 무언지 잘 모르겠다. 표면에 드러난 글만 보면, 기초적인 개념에서부터 문제가 있어 보인다. 글쓴이가 QA를 전문적으로 하는 분이라니 실수한 모양이다. 일민형의 글과 김창준 씨의 부연이 오류를 잘 설명하고 있지만, 좀 다른 각도로 몇 가지 덧붙여본다.

이 글을 보면 학부 소프트웨어 공학 서적에 흔히 나오는 V 모델에 대한 이해가 부족한 듯하다. 그림^[각주:1]에서 보듯 단위 테스트는 특정 프로그램 단위의 설계 검증이 목적이고, 시스템 테스팅은 요구사항 명세에 대한 검증이 목적이다. 그런 둘을 같은 선상에 놓고 결함 검출률을 이야기하는 일이 무슨 의미가 있을까? 볼트와 너트가 서로 맞물리는지 확인하는 일과 자동차가 정상적으로 주행하는가? 중에 어떤 검사가 더 효과적인가?





결함 검출에 대한 이상한 비교가 주장하고 싶은 바는 다음 내용으로 짐작할 수 있다. 이 사실을 알리려고 현재시점에서 도표까지 인용할 필요가 있을지 의문이다.


인용문을 한 줄로 줄여도 큰 무리는 없다.

'결함을 빨리 발견할수록 고치는데 비용이 적게 든다.'

과연 필요성을 몰라서 그동안 요구 사항 분석 단계에서 결함을 좌시했을까? 인용문에서 의미하는 리뷰나 인스펙션 정도로 90%까지 찾을 수 있는 결함은 과연 무엇일까?


외주개발이 보편적인 정보시스템 개발 분야에서 수년 전이 아닌 요즘에 리뷰/인스펙션의 중요성을 주장하는 경우는 거의 드물다. 리뷰/인스펙션이 효과적이기 위해서는 요구분석과 설계 문서가 완벽하다는 전제가 필요하다. 그런데 완벽한 요구분석서나 설계서를 작성하는 일이 얼마나 가능할까? 주류 방법론 변화를 살펴보면 산업계의 보편적인 답을 들을 수 있다.

최근 애자일 방법론 및 프랙티스는 제법 인기를 끌고 있다. Rational을 인수한 IBM은 한동안 주류였던 RUP 방법론에 애자일을 접목해서 Open UP를 만들어 공개했다. RUP에서 OpenUP로 변화하는 과정에서 가장 눈에 띄는 점은 매 반복 말에 아래 그림에서처럼 Demo-able or Shippable Build를 내놓는다는 점이다. 이는 반복마다 시행했던 공식적인 리뷰를 고객 데모나 실제 운영환경에 적용에 따르는 활동으로 대치함을 의미한다.


글로 기술하거나 화면 정의를 한다고 해서 고객이 의도한 바를 달성할지 어떻게 검증할 수 있을까? 소프트웨어 공학은 아직 비즈니스 환경이 제시하는 문맥 안에서 기능 검증을 할 수 있는 메커니즘 따위는 발견한 적이 없다. 또한, 업무 시스템은 현존하는 무엇이 아닌 아직 사용해본 일이 없는 새로운 무엇을 추구한다. 그런데 존재하지도 않는 시스템을 검증할 수 있는 Reviewer가 과연 존재할까?

OpenUP에서 이제 인스펙션이나 리뷰란 말은 찾아보기 어려워졌다. 궁극적으로 고객이 원하는 제품 검증(Validation)을 위해선 빠르고 잦은 출시/피드백이 필요하다. 개발절차를 변경해서라도 이를 가능하게 하는 것이 엄격한 리뷰/인스펙션보다 효과적이란 인식공유를 방법론에 반영한 것이다.


반면 결함 검출률에 대한 저자의 주장이 무색하게도 OpenUP는 단위 테스팅의 지위를 대폭 격상했다. RUP에서는 단위 테스트(unit test)란 용어를 사용했으나, OpenUP에서는 개발자 테스트(development test)로 이름을 변경하고, 구현 주요 활동 5개 중 2개를 개발자 테스트에 할애했다. 다시 말해 TDD를 채용했다.


그렇다고 리뷰와 인스펙션이 중요하지 않다는 뜻은 아니다. 비용 대비 효과를 중요시하는 산업계에서 그간 시행착오를 통해 리뷰/인스펙션보다는 더 빠르게 그리고 자주 최종 사용자에게 전달하는 방법을 택했다. 이를 실현하려고 개발자 테스트를 엄밀하게 하는 방법이 가장 효과적이기 때문에 애자일이 RUP의 반대편에 있다고 인식하게 했던 주역인 TDD를 채용하여 개발 과정의 심장부에 개발자 테스트를 추가했다.

'역사를 이해하는 데 있어 통시(通時)적 관점뿐 아니라 공시(共時)적 관점도 함께 봐야 한다.'라는 말을 들었다. 우리 역사를 통틀어 당파싸움이 지속적으로 있었다는 사실은 지나치게 부각하는 경우가 많다. 특정 시점을 설정해 다른 나라를 돌아봤다면 달리 이해될 것이다.

최초의 문제 제기는 다음과 같은 모양을 띤다. 한 문장이지만, 여러 가지 문제를 함께 의미하기도 하고, 대개는 문제의 수준에 관계없이 쭉 나열한다.


답을 내놓기 전에 문제를 분명하게 다시 정의하는 일은 널리 쓰이는 방법이다.


대화하는 상황이라면 순발력과 지속적인 훈련이 없이는 불가능한 일이다. 추상화 수준을 맞추는 일과 MECE에 입각하여 문제를 정제하는 연습의 생활화가 필요하다.

출처: When to use Dependency Injection

EA를 사용하여 작성한 객체를 자바 코드로 변환할 때 주요 설정에 대해 다룬다. 먼저 Tools > Options 메뉴를 선택한다. 단축키는 Ctrl+F9 이다.

첫 번째로 기억할 옵션은 파일 쓰기 방식이다. EA가 권장하는 Always synchonize ... 옵션은 코드를 생성할 때 기존 내용을 덮어쓰지 않는다. 수정한 내용만 반영하며, 모델에서 사라졌다고 파일에서 삭제하지는 않는다. 실수로 소스에서 특정 속성이나 메소드가 없어지는 일을 막을 수 있지만, 모델에서 사라진 요소가 그대로 남는다는 면에서 단점도 있다. 코드를 기준으로 하고, 모델을 생성하는 경우가 아니라면 오히려 Replace existing source file 옵션이 편리하다. 소스 코드를 생성하면서 기존 파일 내용을 덮어쓰므로 확인 창을 한 차례 보여준다.


두 번째는 위 그림에서 마지막에 보이는 Code page for source editing인데, 인코딩 설정이다.

세 번째는 생성자와 소멸자(Destructor)^[각주:1] 설정이다. 자바는 finalize 메서드가 소멸자에 해당한다. 기본적으로 선택한 상태인데 생성자/소멸자 생성을 막고 싶으면 선택을 해제한다. Object Lifetimes 그룹에서 할 수 있다.


네 번째는 언어별 옵션이다. Default Collection Class를 지정하면 1..* 연관은 해당 타입으로 멤버를 생성한다.
다섯 번째는 편집기(Editor)인데 기본인 내장 편집기를 원한다면 변경할 수 있다.



사족: 현실적으로 Embeded 분야가 아닌 정보 시스템 구현 환경이라면 모델링 도구에서 코드 생성 기능이 구현에 큰 도움을 주지는 못한다.

단축키	설명
Alt+G	다이어그램의 심볼을 프로젝트 브라우저에서 찾기
Alt+ ←, →	이전/다음 다이어그램으로 이동
Ctrl+U	모델링 요소를 다이어그램에서 쓰이는(Used) 경우 찾기
F3	다이어그램 작성시 연속 선 긋기
F4	색깔 등의 모양 바꾸기
Shift + F3	다이어그램 작성시 마지막에 선택한 UML 요소 재 선택
Ctrl + F4	현재 윈도우 닫기
Ctrl + F9	도구 설정(Tools > Options...)
F12	소스 보기(클래스와 코드 파일 링크가 있는 경우)

업무분석 과정에서 KORMARC 정보 검색하다가 발견



출처: http://www.nl.go.kr/kormarc/example/view.php?rec_key=2&page=1&search=&keyword=

첫인상이 좋은 책이다. 우리나라 책 중에선 흔치 않은 가벼운 종이부터 마음에 들더니, 책머리 글이 마음에 쏙 들었다. 마치 역사란 무엇인가를 다시 만날 것 같은 기분이 들었다. 특히 마음에 드는 구절을 일부 인용해둔다. (2008/12/30)



앞의 짧은 소감을 쓰고 일주일이 지난 지금 책을 대하는 느낌은 좀 다르다. 내 성격 탓이기도 하지만, 지나친 호들갑이 조금은 사그라졌다. 그래서 번거로움을 참고 별점 하나 줄인 링크를 붙여 달았다. 깊이 있고 해박한 시각을 보여줘서 책을 놓지 않게 하지만, 머릿속에선 '학문하는 사람들의 말버릇'이 자꾸 떠오르고 읽다 지치는 경우가 종종 생긴다.

전체 270쪽 중에서 170쪽가량 읽은 지금 책 내용을 관통하는 핵심 메시지는 명확하다. 더불어 뉴스 보도에서 흘러 듣긴 했어도 내용은 전혀 몰랐던 인혁당 사건의 배경과 지난 정권에서 과거사 위원회의 활동이 갖는 의미를 알 수 있었다. 102쪽을 통해 유신 판결을 했던 이 중에서 둘은 대법관이고, 둘은 고등법원장이고, 하나는 가정법원장임을 알 수 있었다. 문득 오랜 세월 위에 있던 이가 지난 정부 때 얼마나 두려웠을까 짐작이 갔다. 나라도 노무현을 증오했을 법하다.

한편, 가장 인상적인 부분은 링컨에 대한 오해였는데 다소 충격적인 내용이기도 하고, 시대상황과 같은 맥락을 통한 이해가 얼마나 중요한지 새삼 공감하는 좋은 글이다.(2009/1/7)

후반부 100 여 페이지를 읽으면서 가장 기억에 남는 내용은 단연 소크라테스가 "악법도 법이라."했다는 말은 독재정권이 왜곡한 것이란 주장이다. 저자는 또한 많은 분량 그리고 주요 근거를 마르크스에서 채용한다. 마르크스의 책은 읽은 바 없는데 이참에 읽어볼까? 한편, 마지막을 장식하는 '존재와 당위' 이분법으로 유용한 사고체계를 배울 수 있다.

그림 1에서 우측 음영처리가 있는 부분의 글은 WBS 변경에 대한 메모다. 프로젝트 중반 이후부터는 변경이 발생했다는 이야기다. 만일 이 부분에 대해 도입단계에서 고정해두었다면, 고객의 이해를 구하기 위한 설득 작업이 필요했을 것이다. 경우에 따라서는 고객이 계층적으로 존재하여 많은 보고 절차가 빈번하게 필요하기도 하다. 다행히 우리는 이러한 번거로운 절차를 피할 수 있었다. 이로써 얻은 교훈은 필연적으로 바뀔 가능성이 있는 부분을 인정하고 여지를 두라는 것이다. 

2.2 소프트웨어에 집중하라

Working software over comprehensive documentation
현장에서 종종 지나치게 상세한 명세 작업 혹은 표준화나 기법에만 초점을 맞춘 요구사항 모델링으로 비생산적인 분석 작업을 하는 것을 경험한다. 종국의 결과물은 작동하는 소프트웨어란 사실을 잊지 말아야 한다. 도입 단계에서 모호한 요구사항을 밝혀내는 일은 쉽지 않았다. 고객들마저 정확하게 무엇이 필요한지 모르는 상황이기 때문이다. 조기에 확정하기 어려운 것을 정하는데 지나치게 시간을 투여할 우려가 있어, 명세 자체보다는 요구사항 충족 기준이 되는 검증 기준 수립에 초점을 두었고 이는 표1에 보는 바와 같다. 이로써 약10주 후에 소프트웨어를 구현했을 때 사용할 지표를 2주 만에 만들 수 있었다.  앞서 말했던 것처럼 무리한 듯 보이는 개발범위에도 불구하고, 10주 후 70개의 모든 기준을 충족시킬 수 있었던 요인 중에 하나는 ‘5대1’ 비율 즉, ‘요구사항 정의 2주 대 소프트웨어 개발10주’에 있다.

[표1] 요구사항 정의 사례

3, 구축단계에서의 애자일 프랙티스
도입단계는 전체 26주의 기간 중에서 중반 15주에 해당한다. 실제 제품 개발의 대부분을 수행하는 단계이다. 애자일 프랙티스를 도입했을 때 구축 단계의 가장 두드러진 특징 중 하나는 조기에 통합이 이뤄진다는 점이다. 이는 이행단계의 부담을 한결 줄여준다. 결론부터 말하자면 조기 통합 및 상시 통합 수행은 구축단계에서 빠른 피드백과 팀 협력을 가속화 하는 효과를 가져왔고, 이행 단계로 연착륙할 수 있게 하는데 큰 공헌을 했다. 


3.1 CI 적용 과정에서 배운 협업의 가치

Individuals and interactions over processes and tools
프로젝트 초기에 나는 툴과 프로세스에 초점을 맞춰 환경을 잘 구비하고, 단위 테스트만 잘 실시하면 CI(Continuous Integration) 즉, 지속적인 통합이 가능할 것이라고 보았다. 그러나, 툴의 이점은 분명 한계가 있었고, 프로세스 실현은 그리 간단하지 않았다. 우리는 이번 프로젝트 처음으로 손발을 맞춘 팀이었고, 당연히 프로세스가 몸에 밴 팀은 아니었다. 또한, 프로젝트 일정 역시 프로세스 익히는데 사용할 여유라고는 없었다. 여기서 나는 해결책이 필요했다. 결국 개개인의 특성 파악으로 들어갔다. 프로젝트를 하면서 종종 그 사실을 잊어버리지만, 우린 모두 개성을 지닌 존재이다. 우선 각자 자신이 만들어야 할 산출물을 그리고, 해당 산출물을 통한 다른 사람과의 관계를 표현하게 했다. 작업자와 산출물 사이에 선을 그으면 행위가 나타난다. 나는 이를 문맥도(context diagram)라 칭하고, 모두에게 편한 방식으로 그려오게 했다. 흥미롭게도 관리자인 나와는 달리, 대부분 주변 개발자와의 관계를 완벽하게 알지는 못했다. 나는 그 부분을 찾아서 그려주었다. 이후에 팀원 개인과 서로가 맺고 있는 관계(Individuals and interactions)가 정형화된 부분에 대해서만, 이를 프로세스로 정의해서 공유했다.

[그림 2] 문맥도(context diagram) 작성 사례

3.2 고객과 마치 하나의 팀처럼 협력하라

Customer collaboration over contract negotiation
프로젝트에 잔뼈가 굵은 사람이라면 ‘계약서’, ‘날인한 회의록’, ‘명세서’ 등을 중요하게 취급한다. 하지만, 분쟁이 발생했을 때 이들이 개발팀을 유리한 입장에 놓을 수 있을지 몰라도, 그 이상의 가치는 없다. 구축 기간 초반에 앞서 언급한 것처럼, 70개의 기준을 충족했을 때 고객과 개발팀 사이에 신뢰 관계가 쌓였다. 신뢰 관계는 고객과 사전 협의한 사항에 대한 변경이 용이해졌음을 의미한다. 개발팀은 애초부터 지나치게 기술적인 어려움을 의식해서 요구사항 수용을 거부할 필요가 없어졌다. 고객은 언제든지 개발팀의 입장을 이해할 준비가 되어 있었다. 개발팀은 신뢰를 깨뜨리는 우를 범하지 않는 이상 계약관계에 입각해 서로를 인식하는데 에너지를 쏟는 대신에 본연의 활동 즉, 개발에 대해 집중할 수 있었다. 자신감을 얻은 우리는 고객의 요구사항 수집에 있어서도 장벽을 제거했다.

[그림 3] 개발도구에서 보는 작업목록 사례

우리는 그림3과 같이 개발도구에서 작업목록을 볼 수 있는 환경을 구축하고 있는데, 고객이 직접 올린 요청사항을 작업목록에 포함시켰다. 고객 요청의 즉각적인 수렴과 기민한 커뮤니케이션은 고객의 개발팀에 대한 신뢰감을 더욱 높여주었다. 종국에 고객과 개발팀의 협력은 마치 오랫동안 함께 해온 조직 구성원의 일상적인 협력을 보는 듯했다. 물론, 이러한 협력을 모든 프로젝트에서 실현할 수 있다고 할 순 없을 것이다. 착수보고 때 프로젝트 스폰서인 임원이 ‘고객’이라는 말에 대해 거부감을 표시하며, ‘어차피 같이 일하는 사람인데 고객은 무슨’이라며 호칭을 나무랐다. 고객들은 향후 인수인계와 기술이전을 받는데 매우 적극적이었기 때문에 고객과 마치 한 조직 내에 속한 다른 팀처럼 일할 수 있었다.

4. 결론
애자일 프랙티스는 SI 개발 환경에서 오랜 논의 끝에 나온 경험의 산물이다. 연구소나 학계에서 나온 것이 아니란 점에서 ‘새로운 방법론의 하나’로 취급하는 것은 실용적이지 않다. 오히려 현재 사용하는 혹은 익숙한 방법론이나 개발 프로세스를 사용하면서도 단계적으로 애자일 프렉티스를 충분히 적용할 수 있다. 본 글에서는 이에 대한 하나의 사례를 제공함으로 해서 현장에 응용하기 위한 논의의 단초를 제공하는데 의의를 지닌다.

국내 SI 프로젝트 현장에서는 문화적인 요소 때문에 애자일 방법론 보급이 힘들다는 얘기를 종종 듣는다. 애자일 방법론 도입을 통해 이미 구축한 기존의 방법론을 대치하거나 지금까지 해오던 방식을 완전히 바꾸어버리겠다는 발상은 오히려 애자일(?)하지 못하다. 필자는 애자일 방법론이나 프랙티스 전문가는 아니지만, 현장에서 애자일 프랙티스 적절히 적용하여 효과를 보았다. 실제 사례를 널리 알려 현장에서 소프트웨어 구축에 힘쓰는 이들에게 작은 영감이라도 주고자 이 글을 쓴다.

1. 개요
프로젝트 제안 단계에서 애자일 방법론을 채택한 이유는 프로젝트 특성 때문이다. 프로젝트 팀원의 숫자는 적은데 반해, 개발 범위는 다소 무리가 아닌가 싶은 수준 이었다. 이런 가운데 국내 SI에서 주류로 채택하는 CBD방법론은 많은 산출물을 요구하기 때문에, 애자일 방법론의 하나인 스크럼(Scrum)을 선정했다. 다만, 산출물 명칭과 양식만 기존 SI 프로젝트의 형식과 유사하게 수정하여, 새로운 방법론 도입에 따른 거부감을 최소화 하려고 노력했다. 프로젝트 착수 이후 3.5개월여 시간이 흐른 지금 프로젝트 양상은 애초에 예상했던 것보다 바람직한 모습으로 진행되고 있다. 아직 두 달여 시간이 남은 시점에서 성공을 운운하는 것은 성급한 일이지만, 애자일 소프트웨어 개발(Agile Software Development) 적용만 놓고 보면 분명 성공적이었다. 이 글에서는 성공적이었다고 스스로 평하는 내용들에 대해서 살펴보고자 한다. 그러나, 다른 프로젝트에서도 보편적으로 적용하기 위한 일반화를 시도하는 것은 아니며, 애자일 소프트웨어 개발이 지향하는 원칙에 입각해서 어떻게 해법을 찾았는지 그 과정을 공유하려는 것이 이 글의 목적이다.

1.1 애자일 선언(Agile Manifesto)

이 글에서는 애자일 소프트웨어 개발 혹은 애자일 방법론 자체에 대해 설명하지는 않을 것이다. 실제로 스크럼(Scrum)을 채택했다고는 하나 이미, 필자는 RUP(Rational Unified Process) 류의 방법론에 익숙해있고, 스크럼 자체에 대한 필요 이상의 학습비용을 지불할 생각이 없다. 그보다는 과거의 프로젝트 수행 경험에 비춰볼 때 애자일 선언 은 매우 공감하는 가치 기준을 제시해주었고, 이를 현장에서 활용하고자 했다.
애자일 선언에서는 소프트웨어 개발 방식에 있어 대비되는 가치를 기준으로 추구하는 바를 정의한다.
•    Individuals and interactions over processes and tools
•    Working software over comprehensive documentation
•    Customer collaboration over contract negotiation
•    Responding to change over following a plan

각 항목에 대한 내용을 여기서 설명하기 보다 사례와 함께 이야기하도록 하겠다.

1.2 프로젝트 단계

프로젝트는 도입, 구축 및 이행의 3단계로 나누어 진행하고 있다. 아직 이행 단계를 수행하지 않은 시점이라 도입과 구축 단계에 대해 사례를 짚어본다. 각 단계별로 애자일 선언의 가치 기준을 기초로 애자일 프랙티스 적용이 종래의 경험에 비해 어떠한 개선을 가져왔는지 살펴보자. 사전 정의 없이 애자일 프랙티스라는 말을 사용했는데, 앞으로 ‘애자일 선언의 가치에 준하는 문제 해결책’을 ‘애자일 프랙티스’라고 지칭하겠다. 

2. 도입단계에서의 애자일 프랙티스
도입단계는 전체 26주의 기간 중에서 초반 4주에 해당한다. 프로젝트 범위를 결정하는 기간인데, 이때 가장 초점을 맞춘 부분은 실현 가능한 계획 수립과 요구사항의 확정이다. 여기까지는 사실 애자일 소프트웨어 개발이 어떤 도움을 주었는지 살펴보자. 자 이제 애자일 선언의 가치기준이 등장할 시간이다.

2.1 변화를 수용할 수 있는 계획을 세운다

Responding to change over following a plan
애자일 선언에서는 계획을 따르는 것도 가치가 있지만, 그보다는 변화에 대한 적응에 더 높은 가치를 부여한다고 이른다. 필자가 앞서 참여한 대부분의 프로젝트에서는 WBS를 작성하는데 많은 공수를 소요했다. 고객과 개발팀은 WBS를 PMS 등을 이용하여 공유하고, WBS 상의 계획을 기준으로 진척을 산정했다. 프로젝트가 새로운 업무나 기술을 다룰수록 그리고, 규모가 클수록 더 많은 변화의 가능성을 내포하고 있다. 하지만, 대개의 경우 조기에 수립한 계획을 변경하는 일은 무척 번거로운 과정을 거쳐야 했다. 우리 프로젝트의 경우도 단위 시스템 개발이 아닌 플랫폼 성격의 제품 개발이기 때문에 전략적 결정에 의해 요구사항 변경의 여지가 많다. 또한, 고객 스스로도 필요한지 확신을 갖지 못하는 요구사항에 대해서도 유리한 고지를 점하기 위해 계약에 명시하고 있었다. 이와 같이 변경 가능성을 내포하고 있는 항목을 기준으로 계획을 수립한다면, 계획 변경의 여지가 많아진다. 이런 경우 먼저 변경할 수 있는 것과 할 수 없는 것을 구분해야 한다. 가장 먼저 고객사의 WBS 양식과 샘플을 구했다. 계획 사항 중에서 내규에 따라 진척 평가가 어떻게 이루어지는지 파악했다. 이를 기준으로 특정 단계까지는 가중치를 고정하고, 해당 단계 하위의 작업 항목에 대해서는 변경하여도 진척 평가에 영향을 미치지는 않게 했다.

[그림1] WBS

그림 1에서 우측 음영처리가 있는 부분의 글은 WBS 변경에 대한 메모다. 프로젝트 중반 이후부터는 변경이 발생했다는 이야기다. 만일 이 부분에 대해 도입단계에서 고정해두었다면, 고객의 이해를 구하기 위한 설득 작업이 필요했을 것이다. 경우에 따라서는 고객이 계층적으로 존재하여 많은 보고 절차가 빈번하게 필요하기도 하다. 다행히 우리는 이러한 번거로운 절차를 피할 수 있었다. 이로써 얻은 교훈은 필연적으로 바뀔 가능성이 있는 부분을 인정하고 여지를 두라는 것이다.

Grady의 골 때리는 디자인 패턴 1 - 세상에서 제일 재미있는 디자인 패턴란 글로 소개해드렸던 Grady님이 작년에 SOA에 대해 발표하신 자료를 공유합니다.

제 블로그를 2년 전부터 지나시더니 정제하지 않으셨으나 사고의 기회를 주는 좋을 댓글을 올려주셔서, 본문으로 옮겨 소개합니다. 일상적인 대화 상황을 가정하고 읽어주시기 바랍니다.

몇 일전 특별한 날이라 레스토랑에서 와인을 한 병 마셨는데 와인 문외한이지만, 단박에 이름을 기억하고 싶은 와인이 생겼다. 이름을 기억할 가능성이 작아 코르크를 챙겨왔다. 모처럼 주말을 맞아 와인하실 일이 있는 분에게 추천한다. :)



Santa Ema Cabernet Sauvignon Reserve 2005

참고: Reserve wine
이미지 출처: http://www.winechateau.com

감기 때문에 모처럼 초딩으로 돌아가 10시 반쯤인가 잠이 들었다. 덕분에 아침부터 눈을 떠 메일과 RSS 구독 목록을 읽는다. 구독 목록을 훑어 보다 어떤 논쟁 끝에 달린 댓글을 봤다.


한창 4GL 언어가 주종을 이루고 SI 전문 업체가 태동할 시점에 입사했던 선배가 후배에게 훈화한답시고 프로그래밍 지식은 중요하지 않다고 말했다. 댓글을 보는 순간 얼굴도, 이름도 기억나지 않지만, 그때 선배의 말이 생각났다.

지금 생각해보면 당시 선배는 큰 조직에 입사해 보니 절실히 깨닫는 부분이 있어 지나치게 강조해서 이야기했을 뿐이다. 하지만, 경험이 없던 당시의 나는 울컥해서 후배를 모으고, 스스로 모임을 만들어서 학교에서 가르치지 않는 내용을 배우고 가르쳤다. 일을 하며 학교에 다녀서 시간도 없고, 동문에 대한 애착도 없고, 더구나 모임을 조직하는 일은 문외한인 나^[각주:1]의 변화는 놀라운 일이었다. 결국, 선배의 조언(?)은 의도와 달리 내가 SE 컨설턴트로 성장하는 데 혁혁하게 이바지했다.

다시 댓글에 대해 이야기하면 포기할 때 'SI는 안된다.' 식의 표현을 거두자. 남아있는 동료를 위해 좋은 말은 아니지 않은가? 무언가 포기할 때는 반성을 통해 배움을 얻어야 한다. 그것이 역사가 존재하는 이유^[각주:2]라 배웠는데, 개인에게도 예외는 아니라 생각한다.

나는 한동안 SI에 종사할 계획이다. 솔직히 떠나지 못한다고 확신하고 있을 뿐 구체적인 계획을 하고 있다는 말은 아니다. 최근 SI 분야에서 애자일 바람이 대단하다. 이러한 열풍을 만들어낸 이들과 댓글을 쓴 이는 같은 어려움을 근거로 하고 있다. 너무 동떨어진 사건을 관계짓는다고 생각하는가? 그렇다면, 구체적인 예를 들어보겠다.

현재 나는 팀장으로 ^[각주:3] 팀원 각자에게 동기를 부여하려고 노력한다. 팀원이 작업에 흥미를 잃어 눈치 보며 진도만 맞추려고 한다면 관리가 힘들어지기 때문이다. 프로젝트를 6개월 이상 진행하고 나니 확실히 숙련도가 늘었다. 팀원 스스로 언제까지 하겠다던 추정을 정확히 맞추기 시작했다. 그리고 나니 이번에는 뜻하지 않던 부작용이 찾아왔다. 슬슬 긴장감이 떨어졌다. 그래서, 고객과 회사에 보고한 공식 행사로 매주 프로젝트 내부 세미나를 진행한다. 이 자리에서 팀원 모두는 각자 고민한 내용을 나누고, 노력한 만큼 자부심을 얻는다. 세미나가 궤도에 오르자 다시 외부 발표를 준비하고 있다. 확정 단계는 아니지만, 우리 팀이 배운 내용을 월간 마소에 기고하거나 JCO에서 발표할 예정이다.

너는 팀장이니까 그렇지 않으냐? 나는 팀장이 되기 훨씬 이전부터 이런 방식을 익혀왔다. 위키를 처음 배운 2000년 즈음부터 내가 배운 바를 체계적으로 개인 위키에 정리했다. 2003년부터 써온 블로그는 위키 관리할 시간이 없어 선택한 대안이기도 하다. 주변을 돌아보라. 내가 닮고 싶어했던 모든 사람은 비슷한 방식으로 하루하루 노력하고 있다.

만일, '그래서'가 지칭하는 바가 자신에 대한 반성은 빠진 채로 암울한 특정 환경에 대한 원망만 담고 있다면, 자신을 소외하는 격이 아닌가? SI를 떠나는 이유가 '다시 음악이 하고 싶어서'와 같은 낭만적인 이유까지는 아니더라도 '가족 때문에 돈을 더 주는 유사 분야로 직장을 옮기려고' 정도의 소박한 내용이었다면 아마 나는 이런 긴 글을 쓰지 않았을 것이다.

* 혹시 댓글을 쓴 분이 보신다면 '상황이 마음에 들지 않을 때, 개선하는 노력을 충분히 했는지 돌아보자!'라며 스스로 다짐해왔던 내용을 남겼음을 알려 드립니다. 댓글 쓴 분의 상황을 모르기 때문에 비난할 목적은 아니었습니다. 혹시나 모를 부작용을 막으려고 댓글로 가는 링크는 삭제했습니다.

재밌네.

애자일 → 뚱딴지일 ^[각주:1]
토비님→ 노비님
토비형 → 토지형

일민 형이 Spring DM(OSGI) 이거 쓸만한겨? 링크를 소개하며 의견을 물었다. 체격(?)에 어울리는 글을 주로 쓰는 행각으로 미루어볼 때 자신이 하고 싶은 말이 많은데, 마치 사석에서 하는 가벼운 발언에 대해 기자회견을 하는 모양새가 두려웠던 것일까? 평소 가벼운 글쓰기를 즐기는 나를 부추긴다. 일과 중이었으니 그럴 시간 없다고 넘어갔는데, 귀가 후 발을 씻는데 갑자기 몇 자 적고 싶은 마음이 생겼다.

지난해 다른 사람에게 상처주는 글은 자제하겠다고 마음먹었기에 조금 망설여지긴 했다. 어제 미네르바를 처벌하려 한다는 소문에, 뚱딴지같이 친일파를 만난 듯한 꺼림칙한 기분을 느꼈다. 그래놓고선 이글에 대해 독선적으로 깎아내린다면 도둑놈 심보가 아닌가? 나 자신도 미숙하지만, 생각을 표현하는 행위를 반복하면서 발전했다고 믿기에 이 글을 쓰신 행동은 존중한다.

이제 진정 하고 싶은 말을 하겠다. 후유~ 성숙해지려는 노력은 참으로 어려운 일이다. :)

나는 이분의 주장을 반박할 생각은 없다. 단지 용어를 쓰는 데 있어서 일반적인 용법을 크게 벗어나 있음을 말하려 한다.


SOA는 구체적인 기술이 아니라 아키텍처에 대한 사고 체계이다. 위키피디아 SOA 페이지 어디에도 SOA를 어떤 기술을 써서 구현하라는 이야기는 나오지 않는다. SOA 구현을 위해 PHP 파일이나 MS-SQL을 쓸 수 있고 POJO 역시 쓸 수 있다. SOA는 사고 체계이기에 구현 과정에서 A4 지 100권을 쓸 수도 있고, 대화를 위해 휴대전화도 쓸 수 있다. :) 하지만, EJB나 POJO만으로 SOA를 구현하는 것은 불가능하다.


REST를 위키피디아^[각주:1]에서 찾아보면 아키텍처 스타일 가운데 하나임을 알 수 있다. POJO는 EJB가 아닌 일반 자바 객체를 말한다. 위 표현에 대입해보자. 


REST는 아키텍처 스타일이지 자바 객체 설계나 구현 스타일이 아니다. REST를 이루는 원칙을 준수해 구현한 경우 "RESTful" 이라 표현하는데, 이를 지원하는 프레임워크로 유명한 것이 Ruby on Rails, Restlet (for Java)와 Django (for Python) 등이다. REST는 자바로만 구현할 수 있지 않고, 더구나 POJO로만 구현하는 일은 현실적으로 불가능에 가깝다. 다만, Spring 프레임워크 3.0 버전은 최대한 POJO 중심으로 "RESTful" 웹 애플리케이션을 구현할 수 있도록 지원할 전망이므로 REST와 POJO과 전혀 무관하지는 않다.

학자나 교수가 아닌 이상 REST나 POJO에 대해 이야기하려고 명세서(Specification)까지 읽을 필요는 없겠지만, 모르는 단어를 쓸 때 사전을 찾듯 약간의 학습을 해야 다른 사람과 대화할만한 글을 쓸 수 있다.

* 토비형이 잘못 읽은 부분을 지적해서 해당 내용을 삭제합니다.

• 지난해까지 쓴 글을 연도별로 묶고, 간소한 카테고리로 새 출발
• 자바 스크립트 콜백으로 구동하는 각종 서비스 제거로 화면 출력 속도 개선
  
• RSS 구독 버튼 간소화 및 한RSS 구독자 통계 제거
• 미아찾기 배너 제거(자신도 읽지 않는 모습을 보며 마음도 없으면서 걸어두는 일을 그만두기로 했다.)
  

경영학에선 가치 사슬(Value Chain)이라는 개념이 널리 쓰인다. 좋은 글을 읽고 글을 쓰고 싶은 마음이 동하는 순간 내가 하려는 행위에 생각이 미쳤다. Jeff Atwood는 Jon Raynor와 David Megginson의 글과 인상적인 드라이버 모음 사진을 수집한다. 그리고 주제와 부연을 섞고 적절하게 다시 구성한다. 나아가 Jeff의 글에서 "Ada"를 "Ruby"로 바꾸어보라는 제안처럼 인용문 활용 방식을 제안한다.

종종 어떤 이는 내가 '좋은 글을 가져다가 한 마디 덫 붙이는 재주가 있다고 한다. 과연 이런 행위가 의미가 있을까에 대해 잠시 의심했는데, 이처럼 반추해보니 일반적인 가공 행위와 크게 다르지 않다. 가치 사슬일지 어떨지는 글 쓰는 시점과 미래의 나를 포함한 독자에게 의미를 주느냐에 달렸다. 고로 이러쿵저러쿵 평하는데 혹은 그런 평에 신경 쓸 필요는 없다.

영어 읽기가 고통이 아닌 분에게 다음 글 읽기를 추천한다.



사족: 가치 사슬에 대한 빠른 이해를 돕는 그림

그림 출처: http://www.greengas.net/output/page20.asp

이 카테고리의 모티브

아직 계획적으로 책을 읽을 생각은 없지만, 읽고자 했던 책이 쌓이기 시작하는지라 정체를 풀 요량으로 메모한다. 교양서 순서를 정하려다 계획이 큰 도움을 주지 않아 보였다. 시행착오로 삼고 지워버린다. 기술서는 길지 않은 기간에 바짝 읽어야 하므로 관리를 위해 분류를 한다.


반드시 읽어야 할 책

• 진행 중인 모음(음미하며 모든 문장을 훑어보기): Spring 3종 세트
• 시작시점을 정하기 힘드나 뒤이어 진행할 모음:
•  Java Persistence with Hibernate, Domain-Driven Design, Patterns of Enterprise Application Architecture (프로그래밍 모델 정리 목적)
  
•  Java Power Tools, Wicked Cool Java, Test Driven, JUnit Recipes (개발 환경 개선 목적)
• 3월 이후 시작할 도서: Applying Domain-Driven Design and Patterns, Java Concurrency in Practice, Enterprise Integration Patterns

사실상 교양서인 기술서는 순서만 부여해둔다.

1. 엔터프라이즈급 애자일 방법론
2. 스크럼
3. Principles of Transaction Processing
4. 지속적인 통합 (Continuous Integration) + Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드 
   
5. 유쾌한 자바퍼즐러
6. 웹 표준 Ajax DOM 스크립팅
7. Managing Agile Projects (Robert C. Martin Series)

2003년 10월 2일부터 블로그를 써왔지만, 맞춤법 검사는 오늘 처음 했다. 지인께서 알려주신 한국어 맞춤법/문법 검사기 서비스를 활용했는데 대단했다. 어렴풋이 기억나는데 재작년 초 개발자 블로그 경연 수상자 인터뷰 때 오광섭님이 알려주신 바 있다. 그때는 흥미를 갖지 못했는데 이번에는 대번에 시도를 한 이유는 서비스를 알려주신 자리 탓이다. 당시 테이블 양편에는 출판사 측 대표자와 역자 대표자가 앉아 있었다. 장소는 식당이고 테이블은 식탁인지라 먹음직스런 음식이 놓여 있었지만 팽팽한 긴장감이 흘렀다. 각자 맡은 바를 충실하게 논쟁하는 모습이 글쓰기에 대한 내 태도에 파문을 던졌음이 분명하다. ^[각주:1]

어쨌든 5년 넘게 고수해온 '(낮은 품질을 감내하는) 빠른 글쓰기' 정책을 지금 이 시각부터 바꾼다. 이제부터는 '두 개 쓸 것을 하나로 줄이더라도 우리말 바로 쓰기'다.

한국어 맞춤법/문법 검사기는 부산대학교 정보컴퓨터공학부 인공지능연구실과 (주) 나라인포테크가 공동으로 만들고 있다는 소개를 함으로서 고마움을 표하고자 한다. 너무 약한가. :)

작년 초에 100개를 넘지 말자고 다짐했건만...

시간을 두고 읽어보지 못하던 것을 새해를 맞이하여 단호하게 지워버렸다. 지인의 소식을 알기 위해 남겨둔 34개를 빼면, 순수한 구독 목록은 10개만 유지하기로 했다. 10개라도 제대로 읽자는 마음이다. ㅡㅡ;

SpringSource Team Blog
InfoQ Personalized Feed for younghoe ahn
Miško Hevery
Test Early
The Enterprise Architect
developerWorks : ...
Spring in Practice
NOOP.NL
Martin Fowler's Bliki
웹초보의 Tech 2.1

연말연시를 맞아서 KSUG 필진 중심으로 올해 두각을 나타냈던 스프링 관련 기술과 내년 떠오를 것으로 보이는 유망 스프링 기술을 각각 다섯 개씩 선정하는 랭크놀이를 시작했다.

• 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (benelog 편)
• 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (안영회 편)
• 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (javajigi 편)
• 2008년 스프링의 아쉬웠던 것들, 2009년의 기대 top 5 (Toby 편)
• 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (박찬욱 편)

OSGi를 이용한 Java Enterprise Application 개발, Part 6: SpringDM의 테스트 전략

OSGi 와 Spring DM 스크린캐스트의 마지막회. IBM DeveloperWorks Screencast 마지막회 - SpringDM 테스트전략 에서 소개하고 있듯 Spring One Americas 2008 참석 과정에서 호텔방에서 찍은 것이라고 한다.