블로그 호스팅 기간이 끝났다. 가이드라인에서 호스팅을 받았는데 하드 용량 초과를 계속 해서 연장을 안 시켜준댄다. 그래서 그냥 그만두고 우리 회사 서버로 들어왔다. 복잡할 줄 알았는데 의외로 큰 삽질 없이 이전이 끝났다.

사실 거기 자바 호스팅이라서 처음에 신청한 건데 정작 자바 애플리케이션은 딱 한 번 잠깐 올려봤을 뿐이고 내내 쓴 건 이 모인모인과 php로 된 어플들 뿐이다. 간단한 웹 애플리케이션을 만들기엔 자바가 역시 무겁다.

요즘 자바 웹 개발에 대한 고민을 다시 하기 시작했다. 자바 웹 개발 일거리를 맡았기도 하고, 내 개인 프로젝트도 자바로 하는 게 하나 있기도 하고. 자바가 역시 IDE 지원은 좋다. 편안한 느낌이다. 하지만 맘에 안 드는 부분도 참 많다.

고민되는 부분은 ORM과 Controller다. ORM을 도입하려고 하니까 막상 hibernate는 부담스럽다. 설정도 많고 코드도 번잡하다. 그래서 simple orm으로 검색해봤더니 이것저것 나오는 게 있어서 검토해보는 중이다. DTO도 getter/setter로 할지, public field로 할지, 혹은 Map으로 할지 고민이다. fat model이라면 당근 클래스가 있어야지 싶다가도 실용성은 역시 Map이 낫다는 생각이 들기도 한다. JavaScript 같은 문법이라면 고민할 필요가 없을 텐데, 역시 자바 문법의 한계다.

Controller는 어느 정도 결론을 내려 가고 있다. 많은 프레임웍이 서블릿 API를 감추려고 애를 쓴다. 그래서 Action 같은 거 만들고 그런다. 하지만 어차피 thin controller, fat model로 간다면 controller가 하는 일이라곤 서블릿 API 다루는 일과 model 호출하는 일 밖에 없는데 굳이 감출 필요가 있을까 싶다. 오히려 서블릿을 그냥 쓰고 서블릿에서 model 코드를 호출한 후 JSP로 넘기는 게 좋아보인다. 현재는 이렇게 짜고 있는데 오래된 방식이긴 하지만 프레임웍 덕지덕지 붙인 것보다 훨씬 코드는 짧고 간결하다. 하지만 뭔가 아직은 부족한 느낌이 있다.

지금 프로젝트를 하면서 공통 컴포넌트들을 하나씩 뽑아내고 있다. 37signals가 Rails를 뽑아냈고 워싱턴포스트가 Django를 뽑아낸 것처럼. 이 프로젝트가 끝나면 어떤 결과물이 나오려나. 과연 범람하는 다른 자바 프레임웍보다 나을까?

마지막 블로그 업데이트 후 두 달 정도가 지났다. 정말 눈코 뜰 새 없이 바빴던 두 달이었다. 결혼식 준비와 사업, 양쪽 모두 일이 쏟아져 나오니 정말 감당하기 힘들었다. 그래도 예전에 이렇게 일이 몰렸을 때보다는 나았다. 대학교 4학년 1학기에 졸업프로젝트, 병특 준비, 합창단 파트장 세 가지가 몰린 적이 있었는데 그 학기에 난 두번째 학사경고를 받았고 졸업 프로젝트는 망했고 합창단 공연은 훌륭했지만 파트장으로서의 내 역할은 형편 없었다. 건진 건 병특 하나. 그래도 이번엔 여기저기 구멍이 조금씩 나긴 했지만 그럭저럭 다 해낸 것 같다.

결혼식 준비는 생각보다 일이 엄청 많았다. 결혼 준비하면서 서로 싸워서 많이 힘들다고 하는데 우리는 몇 년 동안 이야기해온 게 많아서 그런지 결혼식 자체 때문에 싸우지는 않았다. 싸우는 건 그냥 평소에 싸우는 정도? 그보다 문제는 쏟아지는 일들이었다. 결혼식 한 번 하는데 뭐 그리 해야 하는 게 많은지. 이처럼 수많은 아이템을 관리해야 하는 프로젝트는 경험해본 적이 없다. 100명 짜리 프로젝트의 PM을 한다 해도 이만큼 골치 아프진 않을 것 같다는 생각까지 들었다. 비서라도 두고 싶을 지경이랄까. 그러다보니 결혼식 연락 돌리는 게 너무 늦어져버려서 청첩장도 제대로 못 보냈다. 그런 거 치고는 손님들이 많이 오긴 했지만 섭섭해하는 사람이 많을 것 같다.

웨딩 플래너는 내가 기대한 역할을 해주지 못했다. 난 웨딩 플래너한테 맡기면 결혼식에 필요한 모든 사항들을 알아서 준비하고 스케쥴 잡고 우리가 결정해야 되는 문제가 생기면 우리한테 들고 와서 이러이러한 일이 있고 이러이러한 선택사항이 있는데 뭐가 좋고 뭐는 어떻고 한데 어떻게 하시겠습니까 하면서 비서처럼 해주는 줄 알았다. 근데 그런 게 아니었다. 그냥 업체 연결해주는 것 뿐이다. 웨딩 플래너가 아니라 웨딩 브로커랄까. 웨딩 산업에서 우리 같은 고객은 주 고객층이 아닌 것 같았다. 모든 웨딩 산업에서 돈 잘 버는 남자와 시간 많은 여자를 고객층으로 가정하고 있었다. 남자는 돈을 대고 여자는 발품을 팔면서 상품을 고르고 챙기는 것. 웃긴 건 이야기를 진행시키고 결정할 때는 다 선화를 보는데 계산할 때가 되면 날 쳐다본다는 것이다. 우리처럼 맞벌이면서 분업(?) 없는 부부들에게 맞춰진 웨딩 플래너가 있었으면 좋겠다. 잡다구레한 일들 다 처리해주고 청첩장은 언제부터 돌려야 된다, 친척들에게는 어떻게 인사해야 하고 어디까지 인사해야 하고 뭘 준비해야 하고 이런 거 다 비서처럼 챙겨줬으면 좋겠다. 다음 아이템으로 이런 거나 해볼까나.

결혼이라는 자체는 그렇게 큰 느낌이 아니었다. 한 달 가량 전부터 이미 같이 살기 시작해서 그 때 이미 생활에 큰 변화가 생겼었기에 결혼 이후에는 달라진 게 없는 느낌이었다. 같이 살기 시작할 때도 이미 4년 가까이 2분 거리에서 살다보니 그렇게 엄청 색다른 느낌은 아니었다. 사람들이 신혼 재미 어떻냐고들 많이 묻는데, 좋기는 좋지만 좋은 건 이미 이전부터 계속 좋았기 때문에 신혼이라고 즐거움이 두 배가 된다거나 그런 건 아니었다. 굳이 말하자면 1.254배 정도? ㅎㅎ 제일 좋은 건 밤이 깊어도 계속 같이 있고 아침에 같이 일어날 수 있다는 것.

삶의 질도 극적으로 높아졌다. 집부터가 내가 10년 동안 살았던 집 중에 제일 좋은 집이다. 제일 비싸니까 당연한 건가? 답답한 서울을 벗어나 분당에서 사는 것도 참 좋은 것 같다. 분당이라는 도시에 대한 이미지가 꽤 많이 바뀌었는데, 처음에는 그냥 몇몇 친구들이 사는 머나먼 곳이었다. 그러다가 NHN 분당으로 가고 나서는 선화가 힘들게 멀리 출퇴근하는 곳이었고 내가 오픈마루를 들어가면서부터 분당에 대한 좋은 이미지가 쌓이기 시작했다. 오픈마루 실장님이 분당 좋다는 말을 워낙 많이 해서 좀 세뇌된 것도 있고 다녀보니 동네가 괜찮다는 느낌이 많이 들었다. 그래서 선화도 분당에 있고 해서 집도 분당에 잡고 우리 사무실도 분당에 차려서 분당 생활권으로 완전히 옮기기로 한 것.

근데 막상 집 구하러 다녀보니까 그렇게 좋은 것만도 아니었다. 너무 아파트 중심적인 계획도시랄까. 아파트 단지 + 상가 단지의 공식대로만 만들어져서 오히려 좀 삭막한 느낌이 들었다. 물론 나름 환경과 생활의 편리함을 동시에 달성하는 좋은 시스템이긴 하다. 하지만 나한테는 좀 옛날 동네스러운 느낌도 필요했다. 정 붙일 데가 없는 느낌이랄까. 강북에 있는 동네들이 주는 느낌, 내가 옛날에 살던 동네가 주는 느낌, 낙성대가 주는 느낌. 정리되지 않은 건물들이 이곳 저곳에서 보였으면 했는데 분당엔 아파트 아니면 상가 건물 밖에 없다. 그냥 고만고만한 2층, 3층 건물들을 찾아보기 쉽지 않다. 그래서 아파트들 돌아보면서 조금씩 실망스런 느낌이 들기 시작했는데 미금에 아파트를 보다보니 옆에 약간이나마 아파트도 아닌, 상가 건물도 아닌 건물들이 옹기종기 있는 거리가 있었다. 여기도 딱딱 네모진 느낌이 없는 건 아니었지만 그래도 조금 더 정을 붙일 수 있을 것 같았다. 마침 여러 가지 다른 조건도 최적이라 이 까치마을에 입주하게 된 것이다. 입주하고보니 상당히 맘에 든다.

밥도 이제 저녁은 거의 직접 해서 먹는다. 선화랑 장도 같이 보고 밥도 같이 하고 설거지도 같이 한다. 같이 하니까 별로 힘들지도 않고 재밌다. 같이 늘어가는 재미도 있고. 전보다 훨씬 건강식으로 먹게 되서 그런지 화장실도 잘 가기고 컨디션도 많이 좋아졌다.

사업은 여전히 만만치 않다. 사람은 그럭저럭 5명이 유지되고 있는데 팀웍이 아직 좋지 않다. 삼성이랑 일하는 것 때문에 흩어져서 일하는 것이 큰 부담이다. 삼성이랑 일해보니 이런 식으로 외주 줘서는 잘 되기 힘들겠다는 생각이 많이 든다. 애니콜이 예전의 명성을 많이 잃어가고 심지어 햅틱은 빙틱(빙식 햅틱)이라는 소리까지 듣고 있는데 이런 식으로 개발하면 버그가 안 생길 수가 없지 않을까. 어쨋든 지금은 버텨내야 하는 시기인 것 같다.

내가 팀원들에게 가끔 해주는 이야기가 있다. 희망과 절망을 동시에 주는 이야기. 3M의 CEO는 13년 동안 월급을 못 받았다는. 우리는 그거에 비하면 상황이 훨씬 좋다는 점에서, 그리고 성공한 회사들도 초기에는 어려움을 겪는다는 점에서는 희망적이지만 우리도 3M의 초창기처럼 어려움을 견뎌야할지 모른다는 생각을 하면 절망적이다. 어쨋든 조금 위로는 되는 모양이다.

이래저래 정신이 없다보니 올해는 책을 많이 못 읽었다. [:독서목록]을 업데이트하고 세봤더니 올해 30권을 읽었다. 작년 내내 39권을 읽었는데 지금 페이스대로라면 작년만도 못 읽을 것 같다. 8점 이상의 좋은 책을 발견한 횟수도 엄청 줄었다. 한 편으로는 책을 더 읽어야 할 것 같기도 하고 또 한 편으로는 이제는 책에서 배운 내용을 현실화시킬 때라는 생각도 든다.

간만에 쓰려니 근황보고가 되버렸다. 결혼 이야기는 할 이야기가 워낙 많아서 모아서 시리즈로 블로깅하고 싶은 생각도 든다. 선화랑 같이 커플 블로그 만들고 블로깅이나 해볼까나.

이번 올림픽 시작하기 전엔 아무 관심도 없었다. 시작해도 거의 안 보리라 예상했다. 스포츠에 대한 관심이 줄어들고 있기도 했고 변질되어가는(?) 올림픽에 대한 거부감도 있었고. 하지만 정작 시작하니까 의외로 나날이 재미가 있다. 특히 요즘 프로젝트의 늪에서 허우적대면서 좌절하다가 올림픽을 보면 위로가 많이 되는 것 같다. 금메달 레이스도 처음엔 별 관심 없었는데 한국이 3위를 하고 있다는 이야기를 듣고부터 보니까 점점 관심이 갔다. 이 작은 나라가 저 대국들과 겨루어서 최상위권을 달리고 있다니. 하지만 그것보다 경기 하나하나가 너무 재미있다. 양궁 대표팀의 눈부신 기량, 결승에선 졌지만 카리스마가 느껴지는 양궁 은메달리스트 박경모, 한국 수영사를 새로 쓴 박태환, 장미란의 압도적인 파워. 펠프스의 압도적인 기량과 숨막히는 100미터 경기에서 관중을 의식하는 여유의 볼트도 정말 멋있다. 귀화 선수 당예서의 스매싱도 정말 대단했고 남자 역도 선수들의 근사한 몸매도 다시 삽질러의 길에 들게 한다. 하지만 무엇보다 이번 올림픽의 백미는 한국 야구대표팀이 아닐까. 난 야구를 그다지 좋아하진 않지만 우연히 이번 대회는 결정적인 장면을 대부분 라이브로 봤는데 정말 재밌었다. 오늘도 인천에 환경관리공단 가면서 기분 드러웠는데 이승엽 홈런 한방에 정말 가슴이 후련했다. 내친 김에 정말로 쿠바까지 누르고 전승우승 했으면 좋겠다.

오늘 오랜만에 오픈마루 실장님을 만났는데 이것저것 이야기하다가 이런 이야기를 들었다. 아프리카 어디 속담이라는데..

• 빨리 가려면 혼자 가고 멀리 가려면 함께 가라.

의미심장한 이야기인 듯.

벌써 바람에서 가을 냄새가 난다. 바람 느낌이 참 시원하고 좋다. 하지만 난 여름도 좋은데 너무 일찍 끝나서 아쉽다.

그 동안 창업해서 일하면서 배운 것이 참 많지만 프로그래밍에 대해서도 깨달음이 좀 있었던 것 같다. 사실 내 프로그래밍 실력이 이제 거의 정점에 다다랐다고 자만했던 적도 있었다. 하지만 다시 성장은 끝이 없다는 것을 느끼게 되니까 참 기분이 좋다. 그 동안 얻은 깨달음을 정리해본다면...

1. 멍 테스트
   • 생각 없이 코드를 약간 수정하고 실행해서 목적 의식 없이 이리저리 테스트 해보는 행동. 태근이를 통해서 발견한 패턴이지만 나 스스로도 엄청 자주 빠지는 함정이다. 피로할 때 자주 나타나는 현상이다. 생각하기가 싫으니까 그냥 이리저리 단순 테스트를 하고 생각 없이 코드를 고치면서 우연히 돌아가는 코드가 나오길 비는 심리가 있는 듯하다. 당면 목표에 대한 인식이 잘 안되어 있거나 문제가 잘 안 풀릴 때, 알고리즘을 명확하게 생각하지 않고 코드부터 만들 때 흔히 나타난다. 해결책은 의외로 쉽다. 이런 현상이 자신에게 생긴다는 것을 인지하는 것만으로도 큰 변화가 있다. 나도 이 패턴을 인지하고 나서 문제 해결 능력이 엄청나게 발전한 것 같다. 멍 테스트를 하다가도 금방 깨어난다. 그리고, 몇 가지 수단들이 있다. 가장 훌륭한 도구는 물론 TDD다. 하지만 지금처럼 TDD를 못하는 상황에서도 TDD의 장점을 끌어올 수 있다. TDD에서 테스트를 작성하듯이 이 코드가 맞다면 어떻게 되어야 하는지를 명확하게 정의해두고 출발하는 것이다. 그리고 실행할 때는 그것만 검증하고 다른 버그를 찾기 위한 시도는 따로 안하는 게 좋다. 우연찮게 버그를 찾더라도 그 버그에 대한 대응을 바로 하는 것은 좋지 않다. 문제가 잘 안 풀릴 때 일단 컴퓨터 앞을 벗어나는 것도 좋은 방법이다. 컴퓨터 앞에 앉아 있으면 깊이 있는 생각 없이 기계적인 코드 변경과 테스트만 반복하게 된다.
2. Do not extract method

   • 이클립스의 자동 리팩토링 기능 중 가장 프로그래머들이 좋아하는 것이 아마 rename과 extract method일 것이다. 그리고, 가장 남발하는 리팩토링이기도 하다. 나 역시 긴 메소드를 보면 일단 extract method부터 생각한다. 하지만, 이것도 생각 없이 기계적으로 하게 되면 더 나쁜 코드를 만들게 된다. 규영이가 언젠가 말한 바 있는데 메소드는 그 자체가 GoTo의 문제점을 해결한 것이 아니다. GoTo의 문제는 코드의 순서와 실행 순서가 맞지 않아서 사람이 코드를 읽어 내려 가다가 다른 곳으로 점프해서 봐야 하기 때문에 사고의 흐름이 끊긴다는 것이다. 그런데, extract method를 기계적으로 하게 되면 똑같은 문제가 생기는 것이다.

     그럼 이 문제는 어떻게 피할 수 있을까? 사실, 이 문제도 쉬운 문제다. 리팩토링의 기본 원칙에만 충실하면 된다. 중복을 제거하고 의도를 드러내는 것이다. 이 두 가지 목적을 만족시키지 못하는 extract method는 메소드가 아무리 길어도 해선 안된다. 특히 주의해야 할 것은 의도를 드러내는 리팩토링을 해야 한다는 것이다. extract된 메소드는 가서 보지 않고도 무슨 일을 하는지 알 수 있어야 한다. 가서 봐야 하면 GoTo와 똑같은 문제가 생기는 것이다. 이 문제는 메소드 작명과도 상관이 있다. 이벤트 핸들러 이름 짓는 걸 보면 onClick 핸들러의 이름을 _onClick이나 clickHandler 등으로 짓는 경우를 많이 보게 되는데 이것 역시 GoTo의 문제점을 고스란히 안고 있다. 실제로 그 메소드가 하는 일을 메소드 이름에 담아야 한다. 클릭했을 때 다이얼로그를 띄워 준다면 onClick 핸들러의 이름을 showDialog 등으로 지어야 하는 것이다. 결국 의도를 드러낸다는 것은 더 accountable한 코드를 만든다는 것이다. http://c2.com/cgi/wiki?MethodsShouldBePublic , http://jania.pe.kr/wiki/jwiki/moin.cgi/MethodsShouldBePublic 도 도움이 될 것이다.

3. 자동화된 TDD가 정말로 불가능하거나, 비효율적인 경우도 있다. 그러나, 그런 경우에도 TDD의 장점을 활용할 수 있다.
   • 예전에는 어떤 분야든 자동화된 TDD가 가능할 꺼라고 생각했다. 하지만 이제 생각이 좀 바뀌었다. GUI 테스팅에 대해서 여러 가지 이야기가 많은데, 이번에 플래시 애플리케이션 개발을 해보면서 느낀 것은 이 분야를 자동화시키긴 아주 어렵다는 것이다. GUI 툴킷을 이용해서 GUI 애플리케이션을 만드는 거라면 꽤 높은 수준의 자동화가 가능하다. 그러나, GUI 툴킷 자체를 만들어야 한다면? 거의 불가능에 가까운 도전이 될 것이다. 이걸 제대로 해낸 사람이 있다면 가서 한 수 배우고 싶다. 하지만, 지금까지 내가 판단하기로는 이건 정말 쉽지 않다. GUI 튜닝도 마찬가지, TDD의 영역이 아니다. 하지만, 그래도 TDD의 장점은 살릴 수 있다. xUnit 없이도 TDD를 할 수 있다. TDD의 장점은 목표를 먼저 명확히 정의한다는 것(=테스트를 작성하는 것)이다. TDD에 대한 오해 중 하나가 TDD를 하면 별 달리 생각하지 않고도 반복적인 실행을 통해서 코드를 만들어갈 수 있다는 것이 있다. 하지만, 이게 가능한 이유는 테스트를 작성하기 때문이다. 테스트를 작성하려면 문제를 적절한 크기로 쪼개야 하고 또 어떻게 동작해야 하는지를 명확하게 정의해야 한다. 이 과정을 거치기 때문에 이후의 과정이 쉬운 것이다. 그래서 TDD를 할 때 제일 많이 생각하고 시간을 들여야 하는 부분은 테스트를 만드는 시간이다. 이런 면에서 BDD는 유익하다. 이 점만 잘 인지하고 있으면 테스트 자동화 없이도 얼마든지 TDD의 장점을 활용할 수 있다. 물론 자동화되어 있을 때처럼 빠르고 편하지는 않지만 안하는 것보다는 월등히 좋은 결과를 낼 수 있다.