여행을 떠나지 않는 엔지니어는 불행하다.

2010년 데이터베이스 연구실 신년회

eritaka — Sun, 31 Jan 2010 17:43:53 +0900

2009년 연구실 신년회 기억이 아직도 생생한데 벌써 2010 연구실 신년회입니다.
항상 다른 연구실과 다른 신년회를 가졌던 것 같은데 올해는 더욱 특이한 신년회였습니다.

저녁식사야 매년 같았지만 올해는 2010년 1월 29일 강남 토즈 2호점에서 각자 자유주제로 페차쿠차 형식으로 발표하는 시간이 추가되었습니다.
페차쿠차 형식으로 짧은 시간으로 발표하진 못했으나 다들 새로운 시도로 페차쿠차 형식이 지향하는 바에 대해 공감했으리라 생각합니다.
아래는 제가 발표한 내용입니다.

2010 Dblab신년회 안명환

View more presentations from 동균 이.

무엇보다 변화를 받아들이고 실천하는데 있어서 학생들을 따라갈 수가 없는 나이가 되었나 싶어서 슬픈 신년회이기도 했습니다.
역시 아이폰이 대세더군요
10년을 써온 핸드폰 번호 바꾸는 것이 싫기도 하고 사람들과 즐겁게 얘기하는 것이 더욱 좋다며 애써 외면했으나 아이폰 4G가 나올 때 쯤이면 안드로이드폰이든 아이폰이든 바꾸지 않을까 예상합니다.
내년 신년회에는 저도 지지 않겠습니다. (부러우면 지는거다?)

디자인을 먼저 변경하라

eritaka — Mon, 05 Oct 2009 23:10:02 +0900

요새 가장 크게 영감을 얻고 있는 부분은 '실생활을 관찰하기' 입니다.
주변에서 관찰하고 흔한 것들에서 의미를 부여합니다.
흔하게 지나쳤던 것들을 관찰하다 보면 큰 영감을 받을 때가 있기 때문이죠

그렇게 실생활을 관찰하다 최근들어 가장 절감하는 것이 바로 '구조를 먼저 개선하자' 입니다.
우리는 보통 기술적 맹신에 빠지기 쉽습니다.
'누가 이런 걸 했더니 좋다더라. 우리도 도입하자!' 는 식이죠
그러나 그 이전에 '왜 우리가 먼저 도입 못했을까. 도입한 사람들과 우리와의 차이점은 무엇인가?' 에 집중해야 합니다.
그리고 나서 도입하기 쉬운 문화를 먼저 만들어야 합니다.
그러면 일이 쉬워집니다.
그렇지 않고 기술만을 도입하려 한다면 실패할 확률이 매우 높습니다.
기술 이전에 구조 혹은 문화를 바꾸어야 합니다.

이전 아파트에 살 때 꿈꾸던 것이 있었습니다.
'아 나른한 오후에 나가서 책을 읽고 사람들과 대화를 할 수 있는 그런 아파트 문화를 만들고 싶다'...
그렇게 10년을 넘게 살고 이사를 했습니다.
그런데 평생 나가서 하지 않던 저도 그렇고 다른 사람들도 갑자기 집 밖 벤치에 나와서 책을 읽는 사람들이 생기기 시작했습니다.
그럼 왜 이런 변화가 생겼을까요
이전 아파트 단지에는 벤치 주변에 차가 있는 경우가 많았습니다. 또한 차들이 주변에 지나가서 시끄럽죠.
또한, 설치된 벤치의 수도 적었지만 일자형 벤치만이 주를 이루었습니다.
새로 이사한 아파트 단지에는 사람들이 앉고 걸어다니는 공간과 차들이 움직이는 공간을 완전하게 분리했습니다.
그렇게 조용한 공간을 만들고 벤치만이 아니라 테이블도 설치하고 멋진 정원도 조성했습니다.

그렇게 아파트 디자인을 변경했더니 사람들이 갑자기 나와서 책을 읽기 시작한 겁니다.
누가 뭐라고 하지 않아도 자연스럽게 움직입니다.

새로운 문화를 도입하고 싶으세요?
먼저 구조를 변경하세요 문화가 자연스럽게 스며들 수 있도록 환경을 구축하면 문화가 자연스레 변경됩니다.

Kent Beck 세미나에 등록했습니다.

eritaka — Sat, 22 Aug 2009 23:39:38 +0900

최근에 거장들이 방한하고 있습니다.
며칠 전 GoF의 디자인 패턴으로 유명한 Ralph Johnson과 Erich Gamma 가 방한하더니 이번엔 XP로 유명한 Kent Beck이 방한합니다.

방한 중 세미나와 워크샵이 열리는데 'Being Agile(애자일이 되기)'란 주제인 워크샵은 비용이 180만원(VAT제외시) 정도 됩니다. oTL

어쨌든 다행히 세미나는 8만8천원(VAT포함)이며 냉큼 등록했습니다.
세미나의 주제는 'Responsive Design: When, How, and What (반응적 설계 : 언제, 어떻게, 무엇을)' 입니다.
2009년 9월 4일 강남역 과학기술회관에서 열립니다.
재미있는 것은 세미나 일정 중 사인회가 있습니다!
'13:00-13:20 저자, 역자 사인회 (인사이트 제공) 및 휴식'

기대됩니다. 현재 제가 가진 Kent Beck 책으로는 TDD(번역서), XP(번역서), Implementation Patterns(원서) 이 있습니다. 20분 동안 다 받을 수 있을지 모르겠네요!

그러고보니 사인회 말고 기념촬영 시간은 없는데 추가 되면 좋겠군요!
흑흑 뭐 혼자 등록했기 때문에 찍어달라고 할 사람도 없지만...

Kent Beck 의 TDD는 개발자를 인간답게 만들어주는 방법론입니다.
그것은 이론일 뿐이며 Real World 에서는 그렇게 진행할 수 없다는 사람은 다음의 그래프를 보시기 바랍니다.

이것은 최근에 임성현 기술사님을 통해 알게된 자료입니다.
IBM과 MS에서 각 프로젝트 별로 TDD를 하는 팀과 그렇지 않은 팀으로 진행된 연구결과이며 TDD 진행 팀이 그렇지 않은 팀에 비해 15~35%의 개발지연이 발생했지만 39~81%의 오류가 극적으로 감소한 것으로 보고되었습니다.

이번 그래프는 오류가 발생하는 시점이 코딩 시점에 80% 가 집중되어 있으며 그 때의 처리비용이 극히 낮다는 것을 보여줍니다. QA 조직 혹은 통합 테스트 시에 오류를 발견하고 수정하는데에는 비용이 급격하게 증가합니다. 이미 배포된 후에 발견된 버그를 수정할 경우 또 다른 버그가 생기는 일도 흔하게 발생합니다. 이것을 모두 테스트하는 것은 인간적인 일이 아닙니다. 이것이 가장 중요합니다. 인간주도형 회귀테스트는 인간적이지 않습니다.

그럼에도 불구하고 TDD는 정말 어렵습니다. 유닛 테스트를 도입하는 것도 정말 어렵습니다. Real World 의 프로젝트는 수많은 난관이 존재합니다. 혼자 작업하는 코드에는 고려하지 않았던 수많은 변수가 있습니다.

이 모든 것을 도입하는데에는 고통이 따릅니다. 용기도 필요합니다. Dependency가 극도로 증가되어 있는 프로젝트에 섣불리 도입했을 때엔 그 Side Effect로 인해 프로젝트가 좌초될 수도 있습니다. 그래서 저는 요새 Legacy 프로젝트에 큰 영향을 미치지 않으면서도 조심스럽게 도입하는데 큰 관심을 가지고 있으며 어느 정도 성과도 거두고 있습니다. 약 5년 정도 된 프로젝트이며 이전 Legacy 코드들 까지 합하면 8년, 아니 그 이상된 코드들입니다.

TDD! 힘들어도 지금 당장 아주 간단한 것에서부터 시작하세요. 새로운 프로젝트만이 가능한게 아닙니다. 이미 배포된 프로젝트에서 문제가 발생된 경우도 가능합니다.
버그가 보고되면 테스트 코드를 작성하여 해당 버그를 재현하며 그 테스트를 통과하기 위해 코드를 수정합니다. 여러 테스트 코드를 추가하여 다시 테스트를 통과시키기 위해 코드를 수정합니다. 무엇보다 테스트가 모두 통과하면 안심이 됩니다. 그리고 나중에 해당 코드를 수정하게 되면 다시 이전에 작성해놓은 테스트 코드를 돌려 회귀 테스트를 수행합니다.
그리고 가장 중요한 것! 개발하는 것이 즐겁게 됩니다. 당신은 기계에서 인간이 되는 느낌을 받습니다.

Real World 에는 수많은 암초가 있는 것 같습니다. 기술적 문제만이 아닌 거지요. ROI도 고려해야 하며 역량 문제도 있습니다. 사람들의 마음, 관계, 정치적 문제까지...
그런 문제를 제외한 채 기술적 문제만을 보아도 상황이 쉬워보이지 않습니다. TDD를 하려고 보면 설계부터 문제가 되는 거지요. 따라서 '프로그램은 왜 실패하는가?(원제: Why Programs Fail?)'에서는 처음부터 디버깅을 염두에 둔 설계가 중요하다고 역설합니다. 모든 것은 부메랑처럼 돌아오게 되어 있습니다. 유닛 테스트 혹은 TDD 도 만능이 아닙니다. 무수히 자라 밀림이 되어버린 정원을 마법처럼 가위손의 정원으로 되돌려줄 은탄환은 존재하지 않습니다.

그럼에도 불구하고 지금이라도 조금씩 정원을 가꾸는 좋은 기술들을 익혀나가는 겁니다.
그러면 언젠가 정원일에 익숙해져서 좋은 기회가 왔을 때 그 기회를 놓치지 않을 수 있을 겁니다.
밀림을 가꾸려는 조그만 발버둥질. 그 움직임이 당신을 인간답게 만들어 갑니다.

저는 포크 말고 젓가락으로 들어주세요.

eritaka — Tue, 04 Aug 2009 03:09:13 +0900

서양과 동양의 차이점을 이야기할 때 흔히 말하는 것 중에 포크와 젓가락이란게 있다.

나이프와 포크를 사용하는 서양 문화는 칼로 고기를 썰고 포크로 음식을 찔러 입으로 넣는 모습에서 공격적인 문화로 비춰진다.
음식을 자르는 나이프와 찌르는 포크에서 흡사 사자나 독수리가 발톱으로 먹이를 찢고 날카로운 이빨로 먹이를 뜯어먹는 모습이 연상되기 때문이다.
이에 반해 우아하게 음식을 집어드는 젓가락 문화는 자연을 이용하기보다 함께 하는 대상으로 비춰졌던 동양 문화에서도 백미라 불릴 만하다.

공격적인 포크문화의 서양과 부드러운 젓가락문화의 동양문화.

나는 젓가락 문화에서 사람을 배려하고 가장 소중히 여기는 마음을 느낀다.

이렇듯 옛부터 우리 문화에는 따뜻한 인본주의 문화가 잘 스며들어 있다.
예를 들어 위험에 처했을 때 한국인이 본능적으로 소리치는 '사람 살려'는 한국인의 의식을 단적으로 보여준다.

어떤 한국인이 영국 여행중에 인적이 드문 산길을 가다가 도둑을 만났다.
도둑이 칼을 들이대고 물건을 빼앗으려 하자 나그네는 '사람 살려'라고 비명을 질렀다.
이때 영국인 신사가 옆을 지나다가 그 장면을 보고 고민에 빠졌다.
'둘 다 사람인데, 저 한국인 나그네는 도둑이 목에 칼을 대고 있는데도 사람 살리라고 하는 걸 보니 대단히 훌륭한 동양의 성자와 같은 사람이다.
그러나 흉악한 도둑을 살려줄 수는 없으니 어떻게 하나'하고 고민했다는 이야기가 있다.
그 영국인은 '사람 살려'라고 소리친 사람이 '나'를 살려달라고 하지 않았으니, 거기서 '나(소리친 사람)'를 빼면 사람은 도둑뿐이라고 생각했다는 것이다.
재미로 꾸며낸 이야기이겠지만, 서양 사람들에게 있어 나, 즉 개인의 자아의식과 한국인의 사람에 대한 인간주의 의식의 차이를 나타내는 이 이야기에서 우리는 한국인의 마음을 읽을 수 있다.
영국인이나 프랑스인 같으면, '헬프 미(Help me)', '에데 므와 (Aidezd Moi)'라고 소리친다. '나 좀 도와줘'하는 것이다. 그들의 의식 저변에는 '나'라는 존재가 무엇보다 앞선 중요한 존재인 것이다.
- 한국인 답게 사는 길 -

'너'와 '나'를 분리된 개인적 존재로 인식하지 않고 '우리'를 '나'로 생각했던 그 문화.

그러나 그 옛날 '대지'의 작가인 펄벅을 감동시켰던 자랑스런 우리의 젓가락 문화는 요새 어디서도 찾아보기 힘들다.
배려하는 문화, 사람을 중시했던 문화는 가고...

윽박지르는 문화.
안되면 될 때까지 하는 문화.
그 누구도 '아니오'라고 하기 힘든 문화.
상처주는 문화.

끓는 물에 살아있는 채로 문어를 조리하는 그 모습에서 나는 포크를 본다.
내가 가능한 시간 대에 답변할 수 있는 이메일을 버려두고 '어서 대답해', '어서 해결해' 울리는 맹렬한 전화 벨소리를 들을 때 나는 포크에 찔린다.
강제로 납기일을 정해놓고 돼지들을 몰아 부치는 닭들을 볼 때 나는 포크를 본다.
업무는 그에 할당된 시간만큼 늘어지는 경향이 있다는 파킨슨의 법칙을 믿는 사람들을 볼 때 나는 포크를 본다.
인간적인 모욕과 함께 상대방을 배려하지 않고 윽박지르는 상사를 볼 때 나는 포크를 본다.
내가 기계를 조종하는 또 다른 기계로 생각될 때 나는 또 포크를 본다.

시골에서 한 농부가 소 두 마리를 데리고 농사일을 하고 있었다. 마침 황희 정승이 그 곳을 지나가다 농부에게 "저 두 소 가운데 어느 소가 더 일을 잘 합니까?"라고 물었다.
이 때 농부는 뜻밖에도 황희 정승에게 다가와서 "검은 색깔의 소가 일을 더 잘합니다."라고 귓속말로 말하는 것이었다. 이상하게 여긴 황희 정승이 "여보시오. 뭘 그런 걸 다 귓속말로 합니까?"하니 농부가 말하기를 "저들 짐승들도 일을 못한다고 하면 듣고 싫어합니다."했더란다. 미물도 저리 대할진대 하물며 사람인바에야...

글쎄, 나는 막 주차된 자동차의 본네트로 올라가는 고양이처럼 따뜻한 곳을 찾아나서고 싶다.

변화.

eritaka — Tue, 05 May 2009 23:59:22 +0900

이쯤 나이가 들면 이상하게 무언가 새로 시작하는 일들이란 무뎌졌을만도 한데
가끔 너무 무서워서 우주 한가운데 아무도 없는 암흑 속에 던져진 기분이 난다.

자신이 없어서 어딘가 갑자기 도망치고 싶은 마음도 든다.
특히 아무도 없이 나 혼자만 있는 시간이 되면 나는 이상하게 자꾸 움츠려들게 된다.

이 불안의 근원은 어디에서 오는 것일까.

인간은 필연적으로 외로운 존재라지만 이 불안의 근원을 그 탓만으로 돌리기엔 무언가 미심쩍은 기분이 든다.
이건 나만의 문제인가 아닌가. 나는 할 수 있는 것일까. 아니, 꼭 해야하는 것인가.

중요한 것은 멈추지 않는 것이다.
아무것도 하지 않는 것보다는 실패한 인생이 되더라도 자꾸 시도하는게 더 낫다.

그러나 달구어진 돌이든 식은 돌이든 그림자에 드리워진 어둠만은 떨쳐내기 어렵다.
그림자는 자국을 남기지 않는다는데 내 그림자는 상처만을 남길까봐 그게 무섭다.
그게 항상 나를 힘들게 한다.

강아지처럼 소리치고 고양이처럼 즐겨라.

eritaka — Mon, 13 Apr 2009 01:32:20 +0900

2009년이 시작된지 얼마되지 않은 것 같은데 어느새 봄날의 곰만큼 좋은 날씨가 되었습니다.
요즘처럼 따스한 날이면 창 밖을 바라보다 왠지 바깥으로 나가고 싶은 마음에 책 한 권과 커피 한 잔을 들고 바깥으로 나섭니다.
그렇게 조용히 걷다 아낌없이 주는 벚꽃 나무 아래 벤치에 앉아 고양이처럼 조용히 하루를 즐깁니다.
벤치에 앉아 나만의 시간을 즐기다보면 캠퍼스 시절에 가장 좋았던 바로 그 시간으로 돌아간 느낌이지만 안타까운 한 가지는 아는 사람 하나 없다는 것 뿐입니다.

4월도 벌써 여러 날이 지나고 봄과 여름의 중간이라고 할만큼 날씨가 따뜻합니다.
기업이라면 보통 1/4 분기의 실적을 보고 및 평가하여 연간 실적을 가늠하고 목표를 수정 및 보완합니다.
따라서 저도 잊어버리기 전에 2009년도 1/4 분기 자기 수련 평가를 해볼까 합니다.

가장 최근에 읽은 '실용주의 프로그래머'의 격언 중 하나인 '지식 포트폴리오'에서는 8가지 가이드라인을 제시합니다.
해당 가이드라인을 가지고 2009년 1/4 분기 평가를 해보겠습니다.

1. 매년 새로운 언어를 최소 하나는 배워라.
-> 아직 새로운 언어를 배우지 못했으나 배운다면 올해는 루비를 배우는 것이 좋겠군요.

2. 기술 서적을 분기마다 한 권씩 읽어라. (습관이 들면, 한 달에 한 권씩 읽어라.)
3. 비 기술 서적도 읽어라.
-> 2009년도 4월 12일까지 읽은 책은 권수로는 총 10권입니다. 그 중 기술 서적은 6권, 비기술 서적은 4권입니다.
분기별 가장 훌륭한 기술 서적으로는 'Refactoring to Patterns'을 꼽고 싶습니다.
비기술서적은 교양서적으로 '만들어진 신', 소설부문으로 '그림자 자국'을 선정하고 싶군요.
모두 추천합니다.

4. 수업을 들어라.
-> 올해 열린 2009 JCO 컨퍼런스는 가지 못했지만 대신 4월 18일 개최되는 제1회 닷넷 커뮤니티 컨퍼런스에 등록했습니다. http://www.devdcc.net/

5. 지역 사용자 모임에 참여하라.
-> 5월쯤에 개발자 모임에 등록하여 오프라인 상에서 정기적으로 교류할 계획을 가지고 있습니다. 가장 중요한 계획입니다.

6. 다른 환경에서 실험해보라.
-> 낙제점을 주고 싶군요.

7. 요즘 흐름을 놓치지 마라.
-> 온라인 잡지와 여러 구독지등을 읽는게 이전보다 뜸해졌습니다. 이것도 낙제에 가깝습니다.

8. 인터넷을 이용하라.
-> 요샌 다른 사람들 블로그를 읽는 일도 뜸하군요. 어쨌든 이것도 낮은 점수를 주겠습니다.

총평을 하자면 고양이처럼 즐기는 일에는 어느정도 선방했으나 강아지처럼 소리치지 못했습니다.
은둔형 개발자로 혼자 개발하고 혼자 탐독하고 혼자 평가합니다.
따라서 커뮤니케이션에 좀 더 신경을 써야한다고 하겠습니다.
즉 '나 자신을 드러내라' 정도가 되겠군요. 자신의 약점을 드러내고 평가받는 것이 아직도 두렵게 다가옵니다.
일단 현재 계획대로 된다면 점진적 개선을 이룰 수 있을 거라 가늠됩니다.

오늘의 이야기를 요약하면 제목과 같습니다.

강아지처럼 소리치고 고양이처럼 즐겨라!

사람을 사람답게.

eritaka — Sun, 05 Apr 2009 00:38:58 +0900

주중이면 나는 아침마다 수많은 사람들과 친구가 되기 위해 지하철을 탄다.

서로가 서로에게 극도의 친밀감을 나타내기 위해 애쓰는 이 공간 속에서
나도 함께 열심히 노력해보지만 아무도 나를 좋아해주지 않는다는 사실에 상처 입는다.

그렇게 상처입고 출근한 매일 매일의 일상.
나는 매일 이야기를 쓴다.
가끔은 나 자신이 만족할 만한 이야기를 쓸 때도 있지만
내 친구들도, 얼마후엔 나 조차도 이해할 수 없는 이야기를 쓸 때면 다시 상처 입는다.
오직 기계만이 친구가 되는 이야기를 쓸 때면
'상실의 시대에 공헌하는 사람들'을 위한 가입 신청서로 쓰면 좋겠다는 생각을 한다.

처음엔 상상도 하지 못했던 일을 이젠 매일 저지른다.
처음엔 그토록 고통스러웠던 죄의식도 이젠 흐릿해진다.

그래서 슬프다.
내가 슬프지 않다는 것이 슬프다.
내가 이런 일을 저지를 수 있다는 것을 납득하려 드는 자신이 슬프다.

그래서 나는 나 자신을 치유할 수 있는 레어를 만들었다.
이 레어가 나만의 마지막 방어선이자 치유되는 공간이다.

주말이면 나는 레어에 몸을 기댄다.
전장을 나가는 드래곤의 휴식처가 된다.

2008년 11월 17일 처음 마련했던 레어.

2008.11.17 시간과 공간의 방 - 나만의 공간.

2008.11.17 시간과 공간의 방 - 아이템 전시장

2008.11.17 시간과 공간의 방 - 아침마다 나는 선탠을 한다.

그리고 2009년 3월 29일 최근의 레어.

2009.03.29 시간과 공간의 방 - 내가 가장 좋아하는 것들 커피, 홍차, 브라우니와 함께.

2009.03.29 시간과 공간의 방 - 바뀐 그림 찾기

2009.03.29 시간과 공간의 방 - 바뀐 그림 찾기 2

2009.03.29 창가에서 - 나와 놀아주지 않는 아이들을 보며.

2009.03.29 창가에서 - 바라만 보아도 평온한 거리.

2009.03.29 창가에서 - 꿈으로 남겨놓은 올림픽 공원.

Proprietary DTO vs Common DTO

eritaka — Sun, 01 Mar 2009 01:33:00 +0900

DTO(DataTransferObject)는 아주 간단하면서도 인기있는 패턴입니다.
개발자라면 누구나 쓰고 있을 겁니다.

Martin Fowler는 DTO 패턴을 다음과 같이 설명합니다.

An object that carries data between processes in order to reduce the number of method calls.

내용은 아주 간단합니다.
분산 환경에서는 한번의 호출에 많은 비용이 들기 때문에 호출 횟수를 줄이는 것이 중요합니다. 따라서 한번의 호출로 해당하는 데이터를 모두 가져와야 합니다. DTO를 사용하면 호출 시에 파라미터가 많아지는 것을 방지할 수 있으며 하나의 Return Value만을 허용하는 언어에서는 한번에 모든 데이터를 가져올 수 있습니다.

즉, 위의 그림처럼 Album title과 Artist name을 각각 호출해서 데이터를 가져오지 않고 AlbumDTO로 그 내용을 Wrapping 하여 한번의 호출로 데이터를 가져오거나 전송하는 패턴입니다.

.NET 개발자라면 누구나 무심코 DataTable을 이용하여 DTO를 사용합니다. 자바 개발자라면 ResultSet을 사용하여 DTO를 사용합니다. 이것을 저는 Common DTO라고 부르고 있습니다. (적당한 용어를 찾지 못했기 때문에)
어쨌든 보통은 SQL query로부터 생성되며 수많은 컨트롤과의 Data Binding이 쉽다는 장점 때문에 흔하게 사용합니다만 단점도 있습니다.
그 단점 중 하나는 DTO로부터 다시 Object와의 매핑을 하지 않을 경우 getter 혹은 setter 에 접근하기 위해서는 문자열로 이루어진 key를 통해 계속적으로 접근해야 한다는 것입니다.
이것이 매우 유연하다는 장점이 있는 반면 잘못된 key에도 컴파일 시 에러를 내지 않는 단점이 있습니다. 또한, IntelliSense 기능을 제공하지 않기 때문에 로직 자체에서 ORM 변환 없이 빈번하게 접근해야할 경우 매우 불편할 뿐만 아니라 형변환으로 인한 Boxing과 Unboxing이 빈번하게 일어날 확률이 높습니다.
그 외에도 getter 시 'yyyyMMdd'와 같이 날짜로 표현된 문자열을 DateTime 형식으로 변환하여 돌려주고 싶을 경우 Common DTO를 사용하기엔 많은 제약이 따르며 setter 시 Validation 체크하기도 쉽지 않지요.

따라서, 저는 DTO를 직접 정의하여 DTO Assembler를 통해(이름과 다른 일을 하게 되버린) Common DTO로부터 한번 더 변환하도록 만드는 경우가 많습니다. 위의 그림처럼 AlbumDTO를 만드는 것이죠. 이것을 저는 Proprietary DTO라고 부릅니다.
특히나 저는 Utility 클래스를 통해 데이터를 여러 형태로 변환할 수 있도록 DTO를 만들곤 하는데 이 경우 유용합니다. 또한 IntelliSense 기능을 제공하여 DTO에 접근할 경우 매우 편하게 접근할 수 있으며 Boxing, Unboxing도 일어나지 않습니다.
그러나 현재 ORM Tool을 사용하지 않기 때문에 일일이 DTO를 만들어주는게 꽤 귀찮은 일입니다. 그래서 단순 조회하며 데이터를 변환할 필요가 없는 경우에는 Common DTO를 사용하여 View 컨트롤에 데이터를 바로 바인딩시켜 버립니다.

이처럼 두 가지 DTO는 각각 장단점이 있기 때문에 항상 고민을 많이 하게 됩니다.
개발 초기에는 Common DTO만을 사용해도 될 것으로 생각했는데 나중에는 그 필요성이 증가하여 모두 변경해야될 경우가 많기 때문에 조심스럽습니다.

그렇게 고민만 하고 결론을 내리지 못하는 나를 볼 때마다 평범한 개발자로 살아가는 것이 참 어렵다는 생각을 합니다.

설맞이 선물

eritaka — Sun, 18 Jan 2009 23:11:18 +0900

2009년 설을 맞아 날 위해 주말 사치를 부렸다.
도합 8만원어치 물건을 구입해서 나에게 선물했다. 과소비의 절정.

워낙 사재기했던 것들이 많아서 최근엔 좀 자제했던 일이지만.
어쨌든 최근엔 심적으로 충격받은 일이 많아 위안삼아 긁었다. (긁을 때는 역시 손이 부들부들, 아드레날린 분출)

다음은 그 목록이다.

1. 스크럼
항상 스크럼에 대해 명시적으로 설명한 책을 읽고 싶었으나 카드 봉인한지 오래되어 사지 못했었다. 토요일날 서점에서 직접 사서 속죄하는 마음으로 주말 내내 붙잡고 있었더니 다 읽었다. 어느 정도 체계적으로 정리된 것 같아 만족.

2. Watchmen
한 블로거의 글에서 '휴고상을 수상한 유일한 그래픽 노블이며 타임이 2005년 선정한 최고의 영어소설 100에 오른 유일한 그래픽 노블'이란 이야기에 덥석 사버렸다. 현재 배송 준비 중. 추석 때 차에서 읽으려고 샀는데 그 전에 밤새 빠져 읽을까봐 겁난다; 기대 중.

3. 만들어진 신
도킨스의 화제작. 다윈탄생 200주년을 기념하여 질렀다. 사실은 '이기적 유전자' 부터 읽고 싶었지만 고 피터드러커 선생님의 말씀을 쫓아 최신작은 기존의 이론을 포함 및 진보시켰을 거란 생각에 덥석. 역시 배송 준비 중.

4. Refactoring to Patterns 번역서 (패턴을 활용한 리팩토링)
이 책은 번역서 제목부터 너무 마음에 들지 않는데다 표지도 원서와 판이해서 원서로 지르고 싶었던 놈이지만 원서가 어마어마하게 비싼데다 최근 원서 한권 보는데 엄청 고생한 추억이 있어서 그냥 질렀다.

글쎄. 읽을 것을 쌓아두고도 계속 지를 수 밖에 없는 슬픈 짐승이지만 긁을 때의 아드레날린은 무언가 변태가 되어가는 느낌이다.

최근엔 이곳저곳에서 상처받았다. 앞으로도 계속 받겠지만.
그래서인지 요새 주말에는 항상 핸드폰을 진동으로 해둔다. 세상과 단절된 느낌.
시간과 공간의 방에서 조용히 자아성찰의 시간을 가져본다.

개밥은 먹는 것만으로는 충분하지 않다.

eritaka — Sun, 28 Dec 2008 00:54:49 +0900

소프트웨어 개발자라면 흔히 알고 있는 이야기로 '개밥먹기'란 것이 있다.
개밥은 사람이 만든다. 개밥은 개가 먹는다. 따라서 사람은 개밥을 먹지 않으므로 개밥이 어떤지 알기 어렵다.
소프트웨어도 마찬가지다. 내가 만든 소프트웨어가 사용자의 입장에선 어떻게 보일 수 있을지 알기 어렵다.
따라서 우리는 개밥먹기를 한다. 우리가 직접 소프트웨어를 사용해보고 체감하여 평가해보는 것이다.

그러나 그런 것으로는 충분하지 않다. 사용자와 개발자는 사전지식이 다르기 때문이다.
개발자에게 있어 당연하여 설명할 필요조차 없으리라 생각되었던 버튼 하나 조차도 사용자에겐 이해할 수 없는 버튼이 되어버리는 경우가 종종 있다.
그래서 개발자가 만든 소프트웨어에 대해 사용자는 많은 불평을 하고 처음에 이야기했던 그림과 다른 이야기를 하기 시작한다.
여기가 많은 개발자가 힘들어하는 지점이다.

최근에 본 서적 중에 'Prefactoring'이란 책이 있다.
책에서 개발자는 사용자와 커피를 함께 마시며 함께 대화를 통해 개발을 진행해나가는 모습을 보여준다. 게다가 유쾌한 농담까지.
이 얼마나 멋진 모습인가!
그러나 예제는 예제일뿐... 현실에서는 그와 같은 여유를 가지기 어렵다. (물론 여기에는 개발자의 역량부족과 현실적 기타 제약요소들의 복합적 원인이 존재하겠지만)
따라서 실제로는 싸워 이긴다 라는 표현이 무색할만큼 충돌이 빈번하게 일어난다.
자, 이쯤되면 슈퍼맨처럼 해결하는 개발서적의 저자들에게 돌을 던질 만하다.
왜 이렇게 현실 세계는 다른 것일까
왜 개발자는 이렇게 힘든 것일까

그러나 전산학은 다른 학문에 비해 특별하지 않다. 경제학을 참고하자.
수많은 경제 법칙에도 불구하고 현실은 시궁창 아닌가. 절대 공리인 수요와 공급의 법칙으로 설명이 되지 않는 수많은 예외와 혼돈이 경제를 지배하지 않던가.

이제 여유를 가져보자. 항상 말도 안되는 사용자의 요구사항에 대해 한걸음 물러나서 이해해보자.
받아들일 수 없는 요구사항이라 할지라도 한번 생각이라도 해보는 것이 좋다.
이것은 요구사항을 모두 받아들이라는 것과는 다르다. 차를 판다고 생각해보자. 소형차에 대형엔진을 달아달라는 고객의 요구를 받아들일 수는 없다.(물론 충분한 가격을 지불한다면 고려해보자. 혹 100억을 줄지도 모르니까;...)
그것이 불가능하다는 것을 고객에게 납득시키기란 어렵지 않다. 그러나 소프트웨어는 쉽지 않다.
소프트웨어는 보이지 않는다. 우리에게 당연하다고 생각되는 것들이 사용자에겐 전혀 당연하지 않다.
그들에겐 미지의 세계이다. 따라서 말도 안되는 요구를 할 수 있다. 아파트를 다 짓고 나서 아파트 기둥의 철근을 바꿔 달라는 사람은 없어도 DB나 OS를 바꿔달라는 사람은 많다.(설계 당시부터 이러한 점이 고려되지 않았다면 아파트 기둥을 바꾸는 것만큼이나 자원이 소비된다.)

이쯤되면 자부심을 가져도 된다.
우헤헤, 불가능이란 없어보이는 소프트웨어 개발자가 아닌가!

아무리 극단적 설계를 하더라도 소프트웨어의 변경은 피할 수 없는 숙명이다. 개발자라면 누구나 대단하다고 생각하는 설계조차 아무짝에도 쓸모없게 만들어주는 슈퍼 유저의 요구사항 변경이 일어난다.

진부한 이야기지만 어쩔 수 없다. 피할 수 없으면 즐기자.
고객의 요구사항을 대비한 내 설계로 인해 문제가 쉽게 해결된다면 그 얼마나 기쁘지 아니할까.
또한 소프트웨어가 모든 문제를 해결해주지 못한다. 다른 방법으로 해결할 수 있다면 그 방법도 적극 도입하라.