무위도식하는 잉여 코더

저는 파이썬을 그다지 좋아하지는 않지만 유닉스 쉘스크립트 보단 낫다고 생각하며 딱 그 수준으로만 쓰고 있습니다. 
누구는 파이썬으로 몇천~몇만 라인 되는 프로그램을 작성하기도 한다는데, 저는 몇화면 넘어가게 짜본적이 없네요.
그런 목적이 필요하면 걍 자바로 짭니다. -.- 

어쨌거나.. 본인의 스크립트 기록 목적 등의 이유로 종종 작성한 파이썬 스크립트를 올려볼까 합니다.
저는 파이썬 코딩 레벨은 초급이며 더 나은 기법 등에 큰 관심이 없습니다.. 걍 특정 문제를 해결하면 그만..
(제 코드에서 뭔가 배울건 아마 없다는 뜻 ㅋ)

오늘의 문제:
마구 다운로드한 다량의 *.torrent 파일들을  노가다없이 transmission-daemon 에 등록하고 싶다..

 배경설명:
저는 토런트 프로그램으로 리눅스 서버에서 transmission 을 돌리며, 메인 PC 는 항상 켜두지는 않는 윈도 입니다. 윈도에서는 uTorrent 등이 .torrent 파일을 다운로드하면 자동으로 감지하여 등록하고 다운로드를 시작한다고도 하는데, 리눅스에서 도는 transmission 에서 다운로드하려면 transmission remote gui 라는 프로그램을 써서 .torrent 파일을 전달해야 하는데, 자동 기능이 없으며 한번에 하나씩만 추가할 수 있습니다.
가끔 한두개 .torrent 파일을 다운받을때는 걍 마우스로 찍어가며 등록하면 되지만, 모 사이트에서 폭풍 갈무리한 .torrent 파일이 수십, 수백개 된다면 이거 하나하나 등록하는 것은 짜증나는 일이지요..

해결책:
다운로드한 .torrent 파일들을 리눅스 서버로 전송하고, 서버에서 파이썬으로 이 파일들을 쭉 등록하는  스크립트를 작성, 실행한다.

최근 모 아이폰용 앱 만드는 것을 도와주면서 리소스 파일 용량이 너무 커서 이를 해결하기 위해 WebP 포맷에 대해 좀 알아봤습니다. (  http://code.google.com/speed/webp/ )

처음 테스트할때 가장 큰 이미지 파일을 cwebp 를 통해 압축을 해봤는데 무려 45% 로 용량이 줄어 대단하다고 느끼며 전면적으로 도입하기로 하였습니다. 기본적으로 WebP 의 소스는 XCode 에 추가만 하면 별 문제없이 컴파일이 가능하기 때문에 사용에 큰 어려움은 없습니다. 

그런데 프로그램쪽에서 준비를 마치고, 리소스 이미지들을 전부 WebP 로 바꾸었는데 (Quality 는 60)
오히려 전체 파일 크기가 늘어난 결과가 나왔습니다.

여러가지 원인을 분석해본 결과 내린 결론은
WebP 는 컬러 수를 적게 쓰는 팔레트 기반의 이미지에 대해 압축률이 좋지 않음을 발견하였습니다.

다음은 샘플 이미지 입니다. 팔레트로 27 컬러만을 사용하고 있습니다.

이 이미지 파일을 cwebp 로 압축하면 오히려 파일 크기가 늘어납니다. 

 
23826 바이트에서 52546 바이트로 늘어났습니다. 심각하게 많이 늘어났네요. 

이것의 원인으로는 일단 cwebp 가 팔레트 기반 이미지를 네이티브하게 지원하지 않는다는 문제가 있습니다. libpng 가 자체적으로 indexed color 에서 rgb888 으로 변환해주는데 그 기능을 사용하여 입력 이미지를 다루기 때문에 일단 팔레트를 적용하여 만든 raw 트루칼라 비트맵에서 압축을 시작합니다.

그럼 cwebp 를 그대로 쓰지 않고 팔레트를 살려 indexed image 소스 상태에서 압축을 하면 되지 않을까.. 그런데 WebP 인코더 쪽 인터페이스 함수들을 아무리 살펴봐도 트루칼라 이미지가 아닌 팔레트 기반 이미지를 입력 파라메터로 받는 함수가 없었습니다. (인터페이스만 없고 내부 코어 기능을 잘 조합해서 구현 가능할런지는 모르겠습니다.)

그래서 결론은..
1. WebP 는 사진같은 이미지 압축에만 사용하자..
2. 팔레트기반 이미지는 PNG 나 GIF 를 사용하자.. 

구글앱엔진은 일종의 무료 웹 호스팅 서비스 입니다.
트래픽이 거의 없으면 공짜이고 트래픽이 많으면 돈을 내는 서비스인데,
그 무료 허용량이 꽤 높아서 개인적 사용에는 돈을 낼 일이 거의 없습니다.

그런데 최근 외국발 소식으로 구글앱엔진 약관이 바뀌어서 배반(?)이라는둥 안쓰겠다는둥 여러 말이 많았습니다.
대충 제목만 보고 무료 허용량이 좀 줄었나보다~ 생각하고 관심있게 안봤었는데,
모르고 지내던 사이에 저도 신용카드가 구글로부터 털렸습니다. -.-

신용카드 번호를 언제 등록했는지 잘 기억은 안나는데, 확실한 것은 제가 직접 결제 버튼을 누르지 않았다는 것..
구글이 일주일에 한번씩 구글앱엔진에 웹사이트를 개설한 사용자로부터 2.1달러를 뽑아가고 있었습니다. -.-

앱엔진 대시보드에 들어가 혹시 트래픽이 조금이라도 생겼나 확인해봤습니다.

 
그러나 예전과 같이 항상 쿼터에 못미치는, 한없이 0 에 수렴하는 트래픽이었습니다;;

(사이트 주소는: http://abcdsee.appspot.com/bugs/list )

여기저기 살펴보고 조사해본 결과 원인은 파일 저장 API 를 썼기 때문.. 
저장된 파일을 유저가 많이 봐서 트래픽이 발생했으면 과금된 것에 대해 수긍하겠지만, 그냥 그 API 를 쓸 수 있게 셋팅해 놓은 것 만으로도 돈이 나가는 약관이더군요.. -.-

그래서 당장 안쓰는 것으로 바꿨습니다. 파일 저장이 사이트의 메인 기능은 아니라서 일단 사이트가 동작하는데는 큰 문제는 없지만, 뭔가 업로드하려면 에러가 나겠죠.. 

사실 구글앱엔진은 별로 좋은 개발환경은 아니었다고 생각합니다. 일단 DB 처리가 RDBMS가 아니라 무척 까다롭고 불편하고요, 사이트 트래픽이 적으면 주기적으로 서버 메모리에서 내리기 때문에 가끔 사이트를 보려고 할때 처음에 10초 이상 기다려야 합니다. 로딩 오래걸리는건 상당히 짜증스럽지요.. -.-

빨리 풀컨트롤이 가능한 아마존 EC2 가 국내 서비스를 했으면 좋겠네요.. 어짜피 돈내고 쓸꺼라면 안되는게 많은 구글앱엔진보다 걍 VM 에 내 맘대로 할 수 있는 아마존 클라우드 서비스가 개발자 입장에선 훨씬 매력적일 것이라고 생각합니다.
 
Good-bye~ 구글앱엔진.. 그거 익히느라 삽질했던 내 시간을 돌리도~ ㅠㅠ