[후기] 자바 개발자 컨퍼런스 JCO(12회) 를 다녀와서…

국내 최대 개발자 행사중에 하나인 JCO에 이번에 강연자로써 참여를 했다. 그래서 다른 사람들과는 조금 다른 후기가 되지 않을까 싶다. 일단 내 세션의 제목은 “초보자를 위한 분산캐시 활용전략” 이었다. 사실 내 세션의 핵심은, “왜 캐시를 써야할까?” 에 초점을 맞추고 있었다. 그래서 특히 앞부분에서의 성능 이슈를 설명하는 것이 초점이었는데, 아뿔싸!!! “초보자를 위한” 이라는 걸 붙였지만… 초보자가 아닌 분들이 너무 많이들어오셨다.(일단 뒤에서 다시…)

일단 내가 들어간 세션만 소개하자면 이번에는 강연자로 참여를 해서 1세션과 5세션 밖에 듣지를 못했다. 1세션은 김형준 수석님의 “빅데이터 플랫폼 기반 소셜네트워크 분석 사례” 를 들었는데, 역시 김형준 수석님 강의는 들을 때 마다 좋다라고 해야할까? 특히 그루터에서의 실제 사례를 들어서 설명해 주시기 때문에(본인 입으로는 깔대기와 약을 판다고 하시지만) 상당한 도움이 되었다.  원래 김형준 수석님 성격이 하나를 물어보면(1분짜리 질문), 그것이 어디서 부터 시작되고, 왜 그렇게 되는지, 그리고 최종적으로 어떻게 해결해야 하는지(30분~60분 소요) 알려주시는 성격이라, 상당한 도움이 되는데, 그런 성격이 딱 묻어나는 강연이지 않았을까 싶다.

두번째 세션은 내 세션이 3번째라, 마지막 준비한다고 못들었고, 4번째 세션은 발표 후 너무 긴장이 되어서, 배가 너무 아픈 나머지, 꼭 듣고 싶었던 이용혁님의 “대용량 고가용성 분산 캐쉬서버(infinispan)를 활용한 웹서비스” 를 듣다가 나왔다.

마지막 세션은 양수열님의 “스타트업을위한 Rapid Development” 였는데, 사실 여자개발자 모임이 듣고 싶었는데, 철혁과장님이 거기 자리없어라는 말과 함께 날 끌고 가셔서 T.T(나중에 보니, 자리가 남았다고 T.T) 그래도 양수열님의 강의는 상당히 재미있었다. 핵심은 스타트업에서는 생산성이 높은 프레임웍을 사용하자라고 요약하면 될까?

이제 마지막으로 내 세션은… 시간을 잘못 계산해서 10분 일찍 끝났다 T.T 흑흑흑, 그러나, 끝나고 질문하신 분들이 3~4분 되셔서 1시간 다 채운듯 T.T, 개인적으로 memcached 등으로 replication은 권장하지 않는 방법인데, 대부분(나도 사실 처음에는…) 가장 관심을 가지는 부분이 memcached로 어떻게 리플리케이션 하나요? 였던거라는 점이 날 당황하게 했다. “권장하지 않는다. 캐시는 캐시답게 사용해야 합니다.” 라는 답변을 드리긴 했지만(사실이예요. 이게 정답입니다.) 좀 마음이 아프다고 해야할까…

강연자 입장에서 보면, 강연자들끼리 소개하는 시간이 있었으면 어떨까라는 생각이 들었다. 일단 같은 세션에 발표하신다고 준비하신 최홍식님, 이연희님, 마지막 세션에 발표해주신 진성주님 세분하고만 대기실에서는 인사를 할 수 있었다. 물론 뒷풀이 때는 양수열님과 인사를 나누긴 했지만…

상당히 개인적으로 아쉬움이 남는 발표라, 다음번에는 좀 더 알차게 준비해야 되지 않을까 라는 생각을 계속 들지만, 이런 자리가 지속적으로 있었으면 좋겠다라는 생각이 들고, JCO 운영진 여러분들 정말 고생하셨습니다.(이분들 정말 고생하셨습니다. 전부 자원봉사라고 보시면 된다는…)

[건강] 담낭용종 이야기(강남성모병원)

처음, 제가 담낭용종이라는 친구를 알게 된 것은 대략 2년 정도 전입니다. 이 때는 이 친구가 0.7~0.8 Cm 정도라서, 그냥 추적 검사만 받으면 된다고 했지만, 1Cm 가 넘어가면 수술을 해야할 것이라는 무서운 얘기도 이때, 처음 들었죠. 그 뒤로 6개월 정도마다 추적검사를 받았는데( 대략, 복부 초음파의 경우 6만원 정도 합니다. ) 올해 9월에 대략 1.2~1.3Cm 정도 된다고 해서 수술을 결정했습니다.

 

일반적으로 특별한 자각증상 없이, 건강검진에서 담낭용종이라고 판정 받았을 경우는 보통 큰 이슈는 없다고 합니다.(그냥 수술만 받으면 된다는…) 다만, 복부 초음파나 CT등으로 해당 담낭용종이 악성이다, 아니다를 판단할 수 없어서, 조직검사를 해야하는데, 담낭 자체가 장기들 사이에 있고 해서, 조직검사를 할 바에 그냥 담낭 자체를 잘라버리는 것이 일반적입니다. 그래서 담낭용종 수술은 결국은 담낭절제술이 됩니다.

 

담낭 절제술은 꼭 담낭용종 뿐만이 아니라, 담석증이라고 해서 담낭(쓸개)에 담석이 많이 생기신 분들도 하게 됩니다.  일단, 잡설은 이만 풀고, 제가 입원했던 강남 성모 병원 기준으로 얘기를 들이자면, 저는 수요일 오후에 입원해서 목요일에 수술을 받고, 토요일 오전에 퇴원을 하였습니다.

 

수요일(오후 3시 입원) – 밤 12시 부터 금식 – 목요일(오전 10시 수술) – 오전12시 수술 완료 – 금요일 8시경 까지 금식 – 금요일 점심 죽, 금요일 저녁 죽 -> 토요일 아침 밥

 

이런 형태입니다. 담낭용종 수술 자체가 간단하고, 수술 시간 자체는 3~40분 이고, 출혈 자체도 복강경으로 해서 거의 없기 때문에 위험하지 않은 수술입니다. 다만 수술 동의시에는 각종 안좋은 말은 다 들게 됩니다. 최악의 경우는 죽을 수도 있다. 등등등

 

수술 자체는 복강경이라고 해서 배에 구멍을 몇개 뚫어서 집어넣고 이를 통해 수술을 합니다. 실제로 배를 째는게 아니라서, 통증이나, 회복시간이 엄청 빠르다고 하네요. 실제로 경험해 보니(수술 과정은 전혀 모르지만) 생각보다 괜찮습니다.

 

전신 마취를 처음해봤는데, 심호흡 두번 하세요. 해서 심호흡 두번 하고 눈 뜨니, 제 인생의 두 시간과 담낭(쓸개) 가 사라져 있었습니다.(정말 이렇게 쉽게 당할 줄 몰랐어요.) 정말 신기해서 눈 뜨자 마자, 간호사에게 수술 잘 되었나를 물어본게 아니라, 전신 마취가 이런건가요? 이 기계는 뭔가요? 전신 마취하면 다시 약으로 깨우는 건가요? 등, 의학적인 질문만 똘망똘망하게 해버렸습니다.  수술이 잘 됬다라는 얘기는 오후 6시경에 의사선생님 회진시에 들었다는…

 

담낭용종 수술은 상식을 벗어나는게, 수술 후 2시간 정도 누워있고, 그 다음부터는 계속 돌아다니라고 강요합니다. 적당히 운동을 해야 빨리 낫는다는 거죠. 그래서 수술 후에도, 거의 나일롱 환자라는 느낌이 가득합니다. 제 주변에는 어르신분들, 어린아가들 전부 좀 큰 병이었는데, 좀 미안하더군요.

 

입원기간동안 가장 힘들었던 것은, 수술 전부터 수술 후까지 36시간 정도 물을 못마신 거였습니다. 포도당 맞고 있으면, 별로 배도 안고프고, 다이어트에도 쿨럭…

 

앞에 2틀은 2인실에 있어서 입원비가 좀 비쌌는데, 병원을 보니 특실, 1인실, 2인실, 5인실 형태로만 요새 나오는 거 같더군요. 개인적으로 수술 당일은 좀 조용한 2인실이 좋았던거 같구요. 나머지는 5인실이 좋을듯 합니다. 전 앞에 이틀은 2인실, 마지막날은 5인실에 운좋게 배정이 되었습니다.( 2인실은 하루에 18만원 5인실은 2만원 T.T)

 

수술도 모두 특진으로 처리되서 이래저래 하면 대략 220만원 이상 든거 같습니다.(맥북프로 15인치 한대가 사라졌어요.)  혹시나, 담낭용종 수술로 고민하시는 분들은 크게 고민안하셔도 될것 같긴 합니다만, 저도 아직 조직검사 결과가 안나와서 두근 두근 기다리고 있습니다.

 

그럼 모두들 건강하세요.

클라우드는 정말 마켓팅 용어일 뿐일까?

Google이 Google App Engine 의 사용료를 올리면서, 특정 서비스들은 거의 10배 이상 가격이 올라간다라고 아우성이다.  결국, 클라우드란 것은 마켓팅 용어일 뿐이고, 싸지 않다라는 얘기도 흘러나온다. twitter 에 @_nodelay 올려주신 링크를 보면 http://groups.google.com/group/google-appengine/browse_thread/thread/d6d8631bbf938351 결국 Lock-In 되버리고, 그 돈이면 서버 30대는 사겠다라는 얘기도 나온다.

 

사실 예전에 SDEC에서 들은 세미나에서도 그렇고 개인적으로 사이트를 뒤적거려보아도, 실제 Cloud 서비스를 받는 것보다, 자체적으로 구축하는 것이 1년 이상 운영한다고 가정하고 단일 가격만 본다면, 더 싸게 먹힌다.  그렇다면 정말 “클라우드” 라는 것은 마켓팅 용어일 뿐인 것일까?

 

결국 Trade-Off 의 문제가 발생하는데, 일단 먼저 인정하고 넘어가야 할 것이, 클라우드가 무조건 싸지 않다라는 것이다. 실제로 계산해보면 클라우드 서버 한대를 빌리는 비용은 그렇게 적지 않다.

 

비교를 위해서, 클라우드의 장점부터 설명하자면, 일반적인 장애에서 대부분이 스토리지 장애, 즉 HDD가 나가는 일이 많은데, 보통 스토리지가 네트웍으로 연결되고 RAID 처럼 구성되어 있어서,  실제로 RAID + HotSpace 를 구성해둔 효과가 난다는 것이다.( 위와 같이 구성되면, 디스크 한두개가 나가도, 정상적인 서비스가 가능하다. 다만 디스크가 나간  시점에 RAID 재구성 등으로 느려지는 것은 어쩔 수 없다. 이 시간이 지나면 제 속도가 나오고, 온라인으로 하드만 교체하는 것도 가능하다.), 즉 자체적으로 장비를 구축하는 것 보다 장애에 대해서 안전해 진다고 할 수 있다.

 

그리고 더 큰 장점은 사실 필요할 때 서버의 증설이 쉽다는 것이다. 보통 예상대로만 로드가 증가하면 미리 미리 준비할 수 있지만, 장애 상황이거나, 갑자기 로드가 급증할 때, 클라우드는 호스팅 서비스보다 정말 빠르게 서버의 증설이 가능하다. 그리고, 그 시점이 지났을 때, 바로 반납도 가능하다. (이런 특성으로, 창업이나 서비스 시에, 초반 투자비용이 적게 든다는 장점도 있다.)

 

반대로, 단점을 들자면, 클라우드 서비스 업체에서 장애가 발생하면, 이를 제어할 방법이 거의 없다는 것이다.

그리고 호스팅 업체에서 클라우드라는 부분에 대한 단점과 호스팅을 비교한 블로터 닷넷의 http://www.bloter.net/archives/72587 이 기사도 꼭 읽어보길 바란다.

 

단순히 클라우드라는 것이 너무나 범위가 많아서 이렇게 뭐라고 단정하기는 힘들지만, 결국 클라우드라는 것이 단순히 마켓팅 용어만은 아니라는 것이 나의 생각이다.  그러나 점점 클라우드 서비스의 비용이 증가한다면, 클라우드를 고려 할 때, 마이너스가 될 것만은 분명하다.

 

 

무엇이 정말 진정한 행복일까?

최근에 나의 생각의 화두는 “무엇이 진정한 행복일까?” 이다.

계속된 야근으로 인한 탈출 심리도 있었고, 옛날 부터, 단순히 평범한 일상을 사는 것은 별로다라는 생각이 있었기에, 항상 내가 생각하는 것 중에 하나는, “뭔가 다른 걸 해보는 건 어떨까?” 라는 것이다.

 

일반적으로,  “돈을 많이 버는 것” 이 행복의 기준이라고 생각하는데, 물론, 이걸 부정할 수는 없는 것 같다.  최소한 사랑하는 사람과 근사한 데서 밥 한끼 맛나게 먹을 정도는 되어야지, 파지 팔아서 하루에 겨우 한끼 먹으면서 살아가야 한다면, 그리고 그걸로 사랑하는 사람을 부양해야 한다면? “행복함” 을 느끼기 힘들지 않을까?

 

하지만, 그런 상황이 아니라면, 가족과 조금 더 시간을 함께 할 수 있는 것을 택하는 것이 좋지 않을까 라는 생각이 든다. 하지만, IT, 프로그래머라는 직업이 내 적성에도 맞고, 일이 즐거워서, 이 일을 버리고 다른 일을 택한다는 것은 또, 나에게는 “행복” 이라는 단어에 위배가 되기 때문에,  무엇이 좋을까? 에 대한 고민은 선듯 답이 나오지 않고 있다.

 

옛말에, 해도 후회하고, 하지 않고도 후회할 것 같다면, 그냥 하고 후회하는 게 낫다라는 말이 있듯이, 그래서 한번 질러보고 나중에 후회하는 길을 찾아보고 있는 중이다.

 

그냥 나중에도 굶어죽지는 않겠지라는 희망찬 자신감 하나로, 일단 일을 한번 벌려보려고 하는데, 과연 나중에 죽도록 후회하지는 않을 지 걱정이 된다.

동료 평가 이야기

누구나, 자신의 “단점” 에 대해서 얘기를 듣는 다는 건, 사실 재미난, 또는 느낌이 좋은 이야기는 아니다.

하지만, 자신의 단점을 알게 해준다는 면에서, 사실 가장 귀담아서 들어야 할 얘기 중에 하나이다.

 

최근에 가장 많이 들은 이야기 중에 하나가, 말이 빠르다(논조가 자주 흐뜨러진다.), 중간에 상대방의

이야기를 끊고 자신의 이야기를 한다라는게, 나의 단점으로 가장 많이 나왔다. 평소에 내가 느끼던 부분들

이기도 하지만, 잘 고쳐지지 않고 있다라는 반증이기도 하다.

 

꾸준히 이런 얘기가 나오는 것은, “뭔가 자랑하고 싶어하는 또는 인정받기 원하는 욕구” 라는게 강하게

숨어있어서 그런것은 아닐까 라는 생각이 든다.

 

그래도, 다행히 “천성이 착하다” 라는 이야기가 나와서 좀 다행이라고 할까?, 남이 보는 장단점이, 내가 보는

장단점보다 훨씬 나를 잘 설명할 수 있다고 생각하기 때문에, 이런 평가 시즌에, 이런 부분은 정말 도움이 되는

것 같다.

 

하반기에는 말을 좀 줄이고, 남들이 더 많이 의견을 낼 수 있도록 내 스스로에게 자물쇠를 하나 달아야겠다.

 

SDEC2011 참관기 – 영어를 공부해야겠습니다.

6월 27, 28일 이틀 연속으로 경원대학교 비전타워에서 진행된 SDEC(Seoul Data Engineering Camp) 에 참여했습니다. NHN 과 정보과학회에서 주최한 대용량 데이터 처리에 관한 컨퍼런스인데, 첫날에는 이미 많이 알고 있던 내용들 때문에, 조금 심심했다면(그래도 모두 좋은 내용이었습니다.), 정말 중요한 내용들이 많았던 둘째날은, 영어가 관건이었습니다.

 

일단, 토익 시험도 바닥을 기고, 제대로 영어를 공부하지 않았던, 저로서는, 다양한 영어를 전혀 이해하지 못하겠더군요. 다시 한번 깨달았습니다. 일단 제 인생의 주적은 영어라는 거!!!

 

페이스북 엔지니어, CouchBase 의 엔지니어, Linked in( 링크드인 역시 굉장한 내부 기술력을 가지고 있습니다. SNS 하는 회사들 전부 -_- 괴물들입니다. ) 이렇게 큰 회사들에서도 많이 참여했는데, 개인적으로는 Heroku 에서 온  Keith Rarick의 BOF 세션이 가장 맘에 들었습니다. 기술적인 부분을 떠나서, 자신이 하고 있는 것에 대한 자신감!!!이 멋지더군요. 특히 제가 참여한 BOF 세션이 가장 사람들이 적게 참여해서 많은 얘기를 억지로라도 해야했는데요. 이전 세션에서 발표한 내용을 제가 못들었다고 다시 질문하니, 열정적으로 알려주더군요. 다만, 제가 잘 못알아들었다는!!!

 

사실 국내에서 이정도의 Quality 를 낼 수 있는 세미나는 개인적으로는 Platform Day 밖에 없는 듯 합니다.  실제 부딫쳐본 문제에 대해서 들고 나오고, 서로 논의하고, 이런 것을 느끼며, 참 즐거웠고 SDEC 을 준비해주신 분들에게 감사드리고 싶습니다.

 

그리고 무엇보다 -_-, 영어를 몰라서 잘 못알아듣는 케이스는 앞으로 없었으면 좋겠다라는 개인적인 바램이 있습니다.(영어 공부를 해야겠죠!!!) SDEC이 2012, 2013년 계속 진행되기를 바랍니다.

앞으로 어떻게 개발할 것인가?

최근에 실수를 여러번 하게 되었다. 특히 평가시즌에 실수가 겹친것이 슬프긴 하지만… 덕분에 앞으로 어떻게 개발해야 할 것인가에 대한 좋은 생각을 하게 되었다. (문제는 내가 시니어급 개발자라는 것 T.T 이제서야 이런 생각을 가지면 어떻하자는 건지…)

1. 먼저 Input 과 Output을 정의한다.

이번에 첫번째 실수중의 하나이다. 코드에 문제가 있었는데, Test Framework의 파싱 모듈의 오류로, 중간의 공백이 체크가 되지 않았다. 이로 인해, 실제로 눈에 보이는 결과가 동일했던것… 바이너리 체크를 했다면, 쉽게 찾을 수 있었을 텐데…

명확한 Input 과 Output 을 정의하여,  이에 대해서 원본과 비교하는 Framework 을 만든다. 이것은 Regression 테스로 이용한다. 이를 위해 Python Test Library를 정비해야 한다.

2. 전체 범위를 테스트 한다.

1번과 연결되는 내용이다. 빠지고 넘어간, 그리고 특정 기능이 적용된 유저, 그렇지 않은 유저군으로 나누어서 전체 케이스가 커버 되도록 테스트를 한다. 이는 물론, Test Framework 을 이용해서 할 수 있도록 해야 한다.

3. 코드 리뷰는 중간 중간 올릴 수 있도록 한다.

딱히 큰 해결책이 없어보이지만, 기능별 Commit의 경우, 그 범위가 크면, 다른 사람이 코드 리뷰를 할 수 없게 된다. 이번에도, 그런 일이 생겨서, 코드 리뷰가 되었지만, 부족할 수 밖에 없었다. 이를 위해서, 변경 사항을 중간 중간 올려서, 코드 리뷰를 받는 것이 좋을듯 하다.

4. 설계 리뷰를 중간 중간 한다.

이번에 실수한 것 중에, 기능 적인 문제는 없지만, 설계가 미진한 부분이 있었다. 중간 중간 다른 사람들과 리뷰를 했지만, 심도 있게 하지 못해, 장애에 Flexible 하지 못한 부분이 생겼다. 이는 충분히 리뷰했으면 초반에 해결할 수 있었을 듯 하다.

위의 4가지만 혼자서 지킬 수 있다면, 앞으로, 실수는 많이 줄어들 것이다. 확실히, 실수를 안 할 수 는 없다. 앞으로 당연히 많이 하겠지만, 위의 과정을 잘 지킨다면, 최소한 같은 실수들을 반복하는 것은 많이 줄일 수 있을 것 같다.

실수를 하는 것이 문제가 아니라, 이에 대해서 깨닮음을 가지지 못하는 것이 문제라고 생각하자. “Failure is an opportunity!” 라는 말 처럼, 실수나 실패에서도 발전할 수 있는 사람이 되자!.