2009/12/19

카페북 시연 소감

카페북 시연을 했다.
카페북이란 무엇인가? 나도 잘 모르겠다. 내가 만드는 데 관여했음에도 불구하고. 이렇게 말하는 게 슬프지만, 지구는 돌고 있는데 안 돌고 있다고 말할 수는 없지 않은가?

그런 행사가 으례 그렇듯, 시연은 '고객을 위해' 이런 것을 생각하고 만들었으니 애용해 달라는 내용이었고, '고객들의 입장'은?
굳이 밝힐 필요는 없을 것이다. 내가 일일이 물어 본 것도 아니고, 검색하면 다 나올 테니까.

어쨌건 간에 내 코드의 흔적이 묻어 있는 결과물이 나올 것이라는 사실 자체에 만감이 교차한다.
미우나고우나 시간과 노력을 들여 세상에 내보낸 결과물이니, 그에 대한 감회를 흔적으로 남긴다. 속시원히 말할 수는 없을 지라도.

2009/12/18

어딘지 어색한 돈 단위, 16천원

가끔씩 어떤 글을 읽다 보면 요상한 단위가 튀어나온다.
16천원. 1만 6천원도 아닌 16천원.
특히 공공기관 문서에 많이 눈에 띄는 것 같다.

심지어 회사 어떤 사람이 회식비 1/n 하라고 메일 보낼때도 23천원 이렇게 쓴 것을 보았다.

왜 그렇게 살까?

나름 양인들 숫자 세는 단위에서 기인한 것으로 알고 있기는 하지만, 굳이 우리말로 읽으면서까지 그럴 필요는 없지 않은가?

이상하다, 이상하다.

해서, 숫자 표기도 1,000,000 이 아닌 100,0000 이어야 한다. 양인들이야 지들 일상이니 앞의 10 billion 이 1 mega 임을 쉽게 읽겠지만 우리는 "백만"이라 읽는 것이 자연스럽기에 숫자 4개씩 끊어 쉼표를 넣어야 한다. 지금 쓰는 숫자 표기대로라면 16,000 을 16천원이라 읽는다 해도 사실 할 말이 없다. 1,6000 이라 해야 만 6천원이라 읽을 것 아닌가.

드디어 iPhone 을 사다.

드디어 샀다. 나오자마자 산 것은 아니지만 iPhone 이 절대선은 아니기에, 나름 고민해 보아야 할 것이 있었다. 가장 중요한 고려사항은 지속적인 요금 지출이었는데 적어도 지금 쓰는 전화기보다 요금이 더 나오지는 않는다.

이미 Apple 제품들 여러 가지 - Mac mini, MacBook Pro, Time Capsule, Wireless KeyBoard, Mighty Mouse, ... - 를 쓰면서 느끼는 것이지만 뭔가 아쉬운 부분이 분명 있다. 때로는 치명적이라 느끼는 부분도 있다. 예를 들어, 타임캡슐의 경우 ftp/ssh/nfs 는 지원하지 않고 오직 afp 만 지원한다는 점 등...

어떤 기기도 단점이 없을 수는 없고, 아직 제대로 써 보지도 않았으니 단점을 이야기하기는 어렵겠지만 뭔가 애플 특유의 불합리함은 있을 것 같다.
그래도 아이폰을 택했는데, 아이폰을 써 보고 싶었다는 것이 가장 큰 이유가 되겠다. 한편으로는 국내 대기업, 특히 '삼X' 에 대한 혐오감이 너무나 컸다는 점도 작용했다. 장사의 가장 기본적인 원칙 중 하나이지만, 아이폰이 나오고 반응이 좋으니까 그제서야 X니아2(이름도 개떡같아 별로 부르고 싶지 않다)의 가격을 '파격적으로' 낮추지를 않나... 치사하고 옹졸하게도 KT 용으로 발매하는 제품에는 'X니아' 라는 이름을 빼버리지를 않나(그런데 개인적으로는 더 낫다. 그 이름 자체가 혐오스러워서)...
그게 글로벌 기업이라 자부하는 것들이 할 짓인가? (사실 기업이라는 게 원래 그런 것 같기는 하지만...)

요즈음 이런저런 책들을 읽고 있다. 별로 좋아할 수 없는 일본조차도 '고객을 위해서' 가 아니라 '고객의 입장에서' 생각해야 살아남을 수 있다고 하는데 '삼X' 가 한 일은 대체 뭔가?
무릇 스마트폰이라 함은 'application' 중심으로 가야 하는데 하드웨어 사양만 잔뜩 높여서 가격만 엄청 올려 놓았다. 그야말로 덩치만 큰 무뇌아들을 양산한 것이다(실제로는 아이폰보다 스펙이 높지도 않은데 혹세무민하고 있다).
물론 3개 통신사도 이런 부분에 대한 책임에서 자유롭지는 않다. 아이폰 발매를 시행한 KT 조차도.

2009/12/16

담배는 과연 그렇게 해로운 것일까?

상당히 오랜 기간 동안 담배를 피웠다. 나름 끊으려고 노력중이고, 요즈음에는 하루에 한두대 정도 필까말까지만 아직 끊었다고 할 수는 없겠다. 누군가 말하기를 담배는 일단 손댔으면 끊을 수 없다고, 그냥 평생 안 피는 것이라고 한다.

담배를 필 때 나오는 해로운 물질은 니코틴과 타르 뿐만 아니라 수천을 넘는 화학물질들이 나온다고 하는데... 어느날 갑자기 의문이 생겼다.

니코틴과 타르는 그렇다 치자. 그런데 이해할 수 없는 물질 목록들이 눈에 띈다. 나프틸아민, 니켈, 벤젠, 비닐 크롤라이드, 비소, 카드뮴 등... 이건 도저히 자연 상태의 식물에서 나올 수 없는 것들이 아닌가? 혹시 토양이 오염되어 축적된 것이라 치면, 다른 채소류들도 마찬가지 아닌가?

지금 파는 담배는 그냥 단순히 담배잎을 말려 발효시켜서 만든 것은 아니라고 한다. 아마도 다양한 풍미를 내기 위해 모종의 가공을 하는 듯 한데 그 때 들어가는 '첨가물' 들이 아마 그런 물질들의 모체가 아닌가 싶다.

물론 그렇다고 천연 상태의 담배라고 해서 몸에 좋을 리는 없을 것이다. 그러나 최소한 그렇게까지 나쁠 것 같지는 않다.
담배를 옹호하는 것은 아니다. 그러나 담배 자체보다는 각종 첨가물들이 그 원흉이 아닌가 싶다. 정말 그렇다면 담배는 정말 부당한 대우를 받고 있는 것이다.

투자한 시간이 가져오는 차이

같이 일하고 있는 사람 중 적어도 개발 실력 면에서 나를 비롯한 주변 동료들보다 실력이 몇 단계 월등한 친구가 하나 있다.

그 친구가 머리가 정말 좋아서 그런 것인지, 실제 경력이 나보다 상당히 길어서 그런 것인지 - 나의 경우로 따지자면 나는 만 7년 좀 넘는 시간, 그 친구는 전공까지 포함시켜 계산하기는 했지만 11년 - 정확하게 알 길은 없다. 그러나 나름 관찰해 본 바에 의하면 상당 기간에 걸친 시간 투자 없이 그런 경지에 올랐다고 생각하기는 힘들다. 아무리 그 친구 머리가 비상하다고 해도.

이미 그 친구는 학부 시절부터 TDD 에 대한 훈련을 해 왔었다. 본인 말에 의하면 그렇지만, 그 말은 충분히 믿을 만 했다. 정확한 시기는 모르겠으나 복학한 이후인 2002,3년 무렵부터라 해도 6~7년 동안 고민하고 훈련을 해 왔다는 계산이 나온다.
반면에 내가 TDD 책을 '읽은' 것이 아마도 2006년도일 것이다. 본격적으로 TDD 가 무엇인지, 그 위력을 실감한 것이 2008년도였으니, 그 차이는 굳이 말할 필요가 없겠다.

흔히 이런 일에 대한 예로 자주 등장하는 것이 "토끼와 거북이" 이야기다. 결국 이 이야기의 교훈이 틀리지는 않았지만 전혀 현실성이 없는 이야기가 예로 등장하는 것은 전혀 공감하기가 어렵다. 그렇다고 더 좋은 예가 있을까 싶지만 예시 자체가 식상한 면도 있고 실제 발생할 수 없는 일이라 오히려 화자의 의도를 방해하는 경우가 많다고 생각한다.

하지만 정말 꾸준함은 당할 수가 없다는 것을 수긍하게 해 준다. 돈을 모으는 것은 결국 시간과의 싸움이라는 이야기를 하는 책을 본 적이 있다. 누구나 복리의 마법을 이야기하지만 결국 그 열매를 맛보기 위해서는 지루하리만치 긴 시간 동안 복리투자를 실천하는 방법 밖에 없다는 것을. 역시 누구나 알 법한 이야기이지만 구체적인 수치가 나오는 얘기라 감은 바로 온다.

많은 곳에서 비슷한 이야기들을 하고 있다. 꾸준함이 가져오는 열매에 대해서. 나는 너무 날로 먹으려 하고 있는지도 모른다.

public method 변경하기

일하던 중 동료 하나가 말을 걸어 온다. 어느어느 프로젝트에서 에러가 나고 있다고. 내가 손대지도 않았는데 왜 나한테 이야기를 할까?

최근에 이런 일들이 몇 번 있었다. 그렇다고 팀원들이 정말 몰라서 그러는 것은 아니다. 오히려 그런 잘못이라면 이 프로젝트에서는 내가 처음 저질렀던 것 같다(하지만 모를 일이다).

수많은(실은 몇 안 되는) 명저들에서 본 내용 중 하나가 public method 는 함부로 고치지 말라고 했다. 혹은 신중을 기하라고 했던가. 그런 내용을 접하기 전 까지 별로 생각해 볼 수 조차 없었을 내용들인데 읽고 나서는 너무나 당연하게 생각되는 내용이라 당연히 잘 할 것이라 믿었었는데 나도 그렇고 동료들도 그렇고, 치명적인 실수를 저지르고 말았다.

동료 A 는 해당 기능을 하는 method 를 더 효율성이 높은 것으로 대체한다고 기존 것을 지웠다. 물론 본인은 충분히 확인을 한다고 하였겠지만, 문제는 그 class 가 구현된 main 프로젝트가 아니고 다른 sub 프로젝트에서 해당 method 를 참조하고 있어서 발생했다.
동료 B 는 단순히 메소드 이름을 변경하는 refactoring 을 했는데, sub project 에 그 변경이 반영되지 않았다. 상당히 신중하고 시야가 남다른 B 였기에 조금 의아했지만 결국 public 메소드에 대한 변경이 그만큼 단순한 일이 아니라는 증거일 것이다.

다들 잘못이라면 잘못을 하긴 했는데 온 세상에 널리 퍼뜨린 라이브러리도 아니고, 범위가 명확한 프로젝트 안에서 다른 참조 프로젝트에 그 변경이 반영되지 않았다는 것은 지금 쓰고 있는 eclipse 잘못인지, 너무 복잡하게 얽혀 있는 지금 프로젝트 잘못인지 모르겠다.

2009/12/04

가끔씩 보이는 '_' 는 대체 왜 쓰는 것일까?

가끔 포스터나 프레젠테이션 자료, 목차 등을 보면 '_' 를 사용한 것을 볼 수 있다. 이를테면

목적과 수단 _17
이런 식이다. 대체 왜 '_' 를 저런 곳에 사용할까? 항상 발견할 수 있지 않은 것을 보면 반드시 저렇게 사용해야 하는 것은 아닐 것이다. 게다가 어렸을 적 - 특히 컴퓨터가 지금처럼 널리 퍼지지 않았던 때 - 에는 저런 표현을 볼 수 없었던 것을 생각하면 바람직한 방향은 아닌 듯 싶다.

실제로 뭔가 만들다 만 것 처럼 보인다.

정말로 궁금하다.

2009/12/02

cURL을 사용하여 수많은 서버 상태를 확인하기

팀 내에서 일정 주기로 돌아가며 기술 관련 자유 주제를 선정하여 발표하고 있는데, 안 올 것만 같던 내 발표 순서가 돌아왔다.

새로운 주제를 찾기는 어렵고, 예전에 했던 것을 돌이켜 보니 한 3년 전에 하던 것 중 생각나는 것이 있었다. 당시 시스템 관리를 담당하고 있었는데 어느날 팀장님이 배포 이후 모든 서버를 수동으로(!) 확인하라고 한다...

그 방법은 단순무식해서, 다음과 같은 절차를 따르면 된다.

  1. /etc/hosts 를 열어 해당 도메인의 서버 ip 를 수정
  2. 브라우저 재시작
  3. 브라우저에서 http://www.target.com/path/to/test_application 접속하여 확인
  4. 1~3 반복
그 팀장님이 왜 이런 방법을 택했는지는 모르겠다. 그리고 왜 나도 이렇게 하라고 했었는지도. 그러나 서버들 각각이 제대로 작동하고 있는지 확인해야 한다는 점에는 동의한다.
한 10대만 되었어도 저 방법을 그럭저럭 감내할 수 있었겠지만, 50대가 넘는 서버를 그렇게 확인하고 싶지는 않았다...

반드시 브라우저로 확인할 필요는 없지 않을까? 뭔가 다른 방법이 있지 않을까? 없을 리가 없다. 이를 위해 쓸만한 것으로 cURL 이라는 것이 있었다. 실제로 이미 스트레스 테스트를 할 때 cURL 로 테스트 대상 서버에 부하를 주고 있었다. 그 스크립트에 사용하던 cURL 명령행은 매우 간단해서 그냥

형식이었고, 이게 제대로 작동하기 위해서 당연히 /etc/hosts/ 에는 www.target.com 에 대한 스트레스 테스트 대상 서버 ip 를 지정해 놓았었다.

그렇다면 curl http://192.168.111.111/path/to/test_application 도 작동하지 않을까?
되긴 된다. 그런데 우리의 www.target.com 은 저런 ip 기반으로 접근할 수 없었다. 그 밖에, Apache NameVirtualHost 를 사용할 경우 전혀 쓸모가 없다.

그래서 생각했던 것이, 스크립트로 /etc/hosts 안의 대상 ip 를 바꿔 가면서 curl 을 실행하는 방법이었는데... 아무래도 좋은 생각은 아니었다. 테스트 이후 /etc/hosts 를 원상복구하는 것이야 일도 아니라 쳐도, 시스템 전체에 영향을 줄 수 있는 부분을 건드리는 것은 별로 좋은 방법이 아니다. 게다가 이러한 스크립트를 실행하기 위해 root 권한을 사용해야 한다는 것도 별로 바람직한 상황은 아니다.

이런 것 말고도 다른 몇 가지 생각을 했었는데 더 바람직하지 않은 방법들이라 굳이 쓸 필요는 없겠다.

결국 cURL community 에서 힌트를 얻어 해결을 하였는데, 다음과 같이 하면 특정 도메인에 대해 어떤 ip 를 사용할 것인지 지정할 수 있다.

간단한 스크립트 등을 작성하여 대상 서버 ip 에 대해 위 명령을 순환하면 된다. 결과 html 을 적당히 처리하여 결과를 판단하면 될 것이다.
사람이 일일이 /etc/hosts 파일을 편집하고 브라우저를 재시동한 뒤 직접 주소를 입력하여 눈으로 확인하는 것은 정말 하고 싶은 일이 아니다.


P.S: 스크립트 혹은 각종 언어에서 시스템 콜을 하는 것이 그렇게 이상할 것은 없다고 생각하지만 보다 세련되게 처리하고 싶다면 libcurl 을 사용하면 된다. 이게 특별히 더 세련된 방법이라 말할 수 있을지는 모르겠다.