Rath World » 2012 » May

Archive

Archive for May, 2012

스택 기반 시간 관리

May 31st, 2012 13 comments

프로그래밍을 하다보면 초심을 잃게 되는 경우가 많다. 세계 각지에 퍼져있는 정보들에 대한 접근성이 기하급수적으로 높아졌기 때문이다. 라고 썼지만 그 근원은 지적 욕심 때문이다.

그런데 지적 욕심을 버릴 생각은 없다. 자기가 뭘 제대로 모른다는 사실을 자각했고, 어느정도의 시간을 투자해서 그것을 내것으로 만들 수 있을것만 같다면 당연히 공부하고 직접 해봐야 한다고 생각한다.

2달째 사용중인 시간관리 도구가 있다.

이 앱을 실행하면 텅빈 메모장과 타이머가 하나 나온다. 메모장에는 진행중인 task 에 대한 context 들을 자유롭게 쓴다. 타이머는 00:00:00 부터 1초씩 증가한다. 몇년간의 시간관리 노력에서 내가 깨달은 것이 있다면 마감기한은 내게 결코 동작하지 않는다는 것이다. 그래서 이 도구는  사용자가 소요시간을 예측하는 능력이 전혀 없다고 가정한다. 마감기한이 주는 효과는 ‘압박’ 과 ‘퀄리티 제한’ 이다. 증가하는 타이머도 ‘압박’ 을 줄 수 있다. 내가 nn 분이나 썼다니! 를 알려주기 때문이다. 마감기한에 비해 증가하는 타이머가 가지는 장점이 하나 더 있다. 마감기한을 3일 후로 잡았을 경우, 당장 그 일을 시작하는 경우는 거의 없다. 늦게 시작한다. 어찌됐든 3일안에 끝나기만 하면 되기 때문이다. 그리고 그 일을 일찍 마쳤다고 하더라도 심리적으로 얻는 보상이 전혀 없다. 반면 증가하는 타이머를 썼을 경우, 3분안에 끝낼 수도 있고 30분안에 끝낼 수도 있다. 게다가 실제로 시작하지 않은 일에 대해 ‘진행중’ 이라는 개소리를 하지 않게 된다.

‘블로그에 MMM 글쓰기’ 일을 30분간 진행했다. 일을 마치지 못했는데 갑자기 배가 고프다. 그러면 타이머를 멈추고 밥을 먹으러 간다? 아니다. 그냥 새로운 일을 시작하기로 한다. 새 일의 이름을 ‘식사’ 로 정한다. 그러면 타이머가 00:00:00 로 리셋된다. context 메모장도 비워진다. 맛있게 밥을 먹는다. 15분정도 밥을 먹었다고 치자. 밥을 먹고 자리에 돌아왔다. context 메모장에는 아무것도 없다. 기분이 좋다. 체하지 않는다. 그래서 웹서핑도 하고 미투데이도 하고 페이스북도 하면서 40분정도 놀았다. 이제 그만 일을 해야겠다. ‘식사’ Task 를 종료한다. 그러면 자동으로 ‘블로그에 MMM 글쓰기’ task 로 전환되고 context도 이전으로 돌아가고 타이머는 01:10:00 이 된다. 00:30:00 이 아니다. 블로그에 글을 쓰기로 한지 1시간 10분이 지난것이다. 맞지않나. 관리자들의 사고방식이 그대로 반영된다. 어떤 일을 시작하고 삼천포로 3번 빠져서 실제로 그 일을 하는데 걸린 시간은 3시간 이였지만 총 2일이 걸렸다고 치자. 관리자가 그거 3시간 걸렸다고 인정해주나? 아니다 2일이다. 변명은 필요없다. 그것은 2일이다. 괜히 3시간 걸린다고 얘기했다가 나중에 밥먹을 시간에 밥도 못먹고 technical debt 왕창 끌어쓰고 잠도 제시간에 못자면서 스트레스 받을 일이 없다. 그것은 그저 2일 걸리는 일이다.

아무튼 이제 소화도 다 됐고, 블로그 글쓰기 일을 30분 더 진행해서 끝냈다. 그럼 작업 끝났다고 마킹한다. 이제 스택이 비워졌다. ‘블로그 글쓰기’ task는 총 100분이 걸린걸로 회계처리 된다. 이제 새 타이머가 시작된다. task 의 이름은 ‘Idle’ 이다. Idle task 에만 예외적으로 반영되는 규칙이 있는데, 다른 일을 하다가 Idle 로 돌아오면 타이머가 00:00:00으로 리셋된다는 것이다. 내가 얼마나 놀고(Idle) 있었는지 타이머가 계속 표시해준다. Idle task 의 context 에는 평소 하고 싶었던 일들을 마구 적었다가 지웠다가, 뭐 마음대로 한다. 눈치챘겠지만 이 프로그램의 타이머는 결코 멈추지 않는다. 끊임없이 돌아간다. 마감기한이 전혀 없음에도 불구하고 엄청난 압박을 받는다. 퀄리티 제한을 할만한 핑계도 없다.

이 툴을 쓰기 시작하고나서 처음 2-3주 동안은 말도 안되게 과로를 했다. 시간이 계속 흘러간다는 것이 계속해서 느껴지는데 그 시간이 너무 아깝게 느껴졌기 때문이다. 마감기한 타이머는 압박의 칼이 내게 향해있는 것같은 느낌을 받는 반면 증가하는 타이머는 ‘넌 놀든지 말든지 나는 간다.’ 의 느낌을 준다. 사람을 아쉽게 만든다. 결국 더 주도적으로 일을 하게 만들어준다.

업무중에 들어오는 인터럽트를 다루는 데에도 효과가 있다. 누가 말을 걸면, 일하면서 수동적으로 ‘ㅇㅇ’ 질하지 말고, 그냥 새 task 를 만든다 (혹은 무시하거나). task 이름은 ‘채팅, 홍길동’ 정도가 좋겠다. 이제 채팅에 집중한다. 타이머는 채팅을 얼마나 했는지를 계속 표시한다. 증가하는 타이머 덕분에 상대방에게 ‘나 대화시간이 5분밖에 남지 않았어’ 라는 자기중심적인 이야기를 전달하는 것이 아니라 ‘우리 대화한지 벌써 30분이 넘었다’ 를 공유할 수 있게 된다.

자러 갈 때도 ‘침실’ task 를 하나 만든다. 몇시에 일어나라고 강요하지 않는다. 그냥 속편히 잔다. 자고 일어나서 타이머를 확인하면 ‘내가 6시간 잤구나..’ 를 알 수 있다. 이제 task 를 종료한다. 전날 밤에 하던 일의 타이머가 나타나고 6시간이나 흘러가있다. 슬프지만 현실이다. 시간관리툴에게 내가 먹고 자고 놀아야 하는 인간임을 확실히 알려줘라. 장기적으로 보면 훨씬 더 편해질 것이다.

p.s. 이 프로그램 역시 릴리즈 계획이 없다. 만드는데 기술적인 어려움은 없을테니 자급자족하시길 추천한다.

Categories: Personal, productivity Tags:

자급자족 개발자

May 31st, 2012 4 comments

언젠가부터 만든 프로그램을 외부에 노출하지 않기 시작했다.

제작년에 만들었던 Android 용 MSN 클론 때문이다. public release 는 대단히 고통스럽고 에너지가 많이 소모되는 일이다. Total Installation 수는 360만정도였고, Active Installation 수는 내가 이 프로젝트를 버린지 1년이 넘었기도 하고 Microsoft 가 ‘왜 앱이름에 MSN이 있니? 마켓에서 내려라’ 해서 Market 에서 사라지고 이름을 바꿔 새로 올렸기 때문에 지금은 50만대 밖에 안된다. 50만대밖에라는 표현을 하긴 했지만, 혼자 감당하기에는 큰 숫자다. 배포 한 번 할 때마다 가슴 졸이며 받았던 스트레스는 어마어마했고 사용자 피드백도 많았다. 부정적인 피드백은 그 순간의 내 에너지를 빼앗아가고, 긍정적인 피드백은 당장은 기분이 좋지만 더 잘해야겠다는 생각으로 내 미래 에너지를 빼앗아간다. 어찌됐든 내 에너지가 소모된다.

나는 너무 지쳤고, 업데이트 시마다 받는 관심 리젠을 받지 않기 위해 업데이트를 1년째 안하고 있다. 성공했다. 제품이 만들어내는 수익은 1/10 수준으로 떨어졌지만 나는 에너지를 다른 곳에 쓸 수 있게 됐기 때문이다.

지난 3월경에 만든 버스앱이 있다. 2월 중순에 집을 이사했고, 여기는 지하철역과 15분이나 떨어져있지만 버스정류장과는 1분 거리기 때문에 버스앱이 필요했다. 런던에는 Transport for London 이란 사이트에서 각 버스정류소의 지리적 위치, 실시간 버스 도착 시간 등을 제공한다. 1-2주 정도의 시간을 들여 만들었고 쓸만한 수준이다. 이렇게 1달 정도를 쓰다보니 Google Maps 타일 이미지 때문에 3G 트래픽이 많아진 것을 발견했다. 그래서 OpenStreenMapMapnik 을 이용하여 런던 전체 지도를 렌더링하여 SD 카드에 넣었다. 줌레벨 14~18 PNG 타일을 다 넣었지만 670MB 정도면 되고 앱 반응속도도 빨라져서 좋다. 이렇게 또 1달 정도를 썼다. 아직 불만이 없다. 며칠전에 버스로 30분을 이동해야하는 헬스장을 끊었으니 조만간 앱도 개선이 될 듯 하다.

우리집 인터넷은 무지막지하게 느리다. 아내가 유튜브로 드라마를 보기만 해도 업무에 지장이 올 정도다. 그런데 내가 즐겨듣는 몇몇 음악은 유튜브에서만 들을 수 있다. 그래서 유튜브 다운로더를 만들었다. 나는 커멘드라인 중독자라 CLI로 만들었다. 다운로드 후 오디오만 ffmpeg 으로 뽑아서 Apple Script 으로 iTunes ‘YouTube’ 플레이리스트에 넣는다. 개발에 걸리는 시간은 수시간이였고, 여태까지 아무런 불만도 없었다. 이거 릴리즈한다고 생각해봐라. 일단 YouTube 컨텐트를 다운로드 하는 것 자체가 불법이다. 사람들이 다 Mac 을 쓰는 것도 아니고, Mac 사용자라 하더라도 iTunes 을 메인으로 쓸지 안쓸지 모른다. 그들의 플레이리스트 이름이 과연 ‘YouTube’ 일까? 게다가 ffmpeg 바이너리도 재배포해야한다. 내 ffmpeg 은 –enable-gpl 에 –enable-nonfree 다. ffmpeg 바이너리 재배포만 해도 불법이다. Mac 쓰는 사용자중에 몇명이나 Terminal.app 을 항상 띄워둘까?

Michael T. Nygard의 Release it: Design and Deploy Production-Ready Software도 읽어보았지만 내겐 효과가 없었다. 아니 역효과만 났다. 책 제목만 보고 ‘릴리즈 못하는 병이 없어질지도 몰라’ 했지만 Production Ready 의 눈높이만 올려줘서 릴리즈 안하는 이유를 더 잘 만들어 낼 수 있게 됐기 때문이다.

내 릴리즈 기준을 충족하는 제대로 된 제품을 만들어 릴리즈하려면 훌륭한 엔지니어(디자이너 포함)가 적어도 4명은 필요한 것 같다. 그런데 나는 내 밑에 사람을 두는 것을 끔찍히도 싫어하고, 협동을 하는데 꼭 필요한 희생의 미덕이 부족하다. 갈 길이 멀다. 그렇기 때문에 인생은 살만한 가치가 있다.

Categories: Development, Life, Personal Tags:

TextToSpeech API 구축 방안들

May 31st, 2012 1 comment

작년말에 Neospeech 에서 TTS 엔진을 구매했다. 한국어 Voice 인 유미, 준우 이렇게 2개를 구매했고 Voice 당 USD $138 를 줬다. Windows 전용이라 (리눅스 + API 버전은 가격이 정해져있지 않고, 마케팅 담당자를 계속 괴롭혀봤으나 혼자 쓸꺼라니까 안판다고 하고, 얼마면 되냐고 USD $1,000 까지 제시해봤으나 모호한 답만 나오는걸로 보아 욕심쟁이인듯해서 안쓰기로 함) Windows OS 라이센스가 필요하다. 중고로 구매해도 $50 정도 필요하다.

그런데 응용프로그램이 GUI 형태로 제공된다. GUI 응용프로그램으로 API 를 만들어야하므로 UI Automation 을 위해 USD $39.95 를 주고 Macro Express 를 구매했다.

그래서 한글 텍스트를 mp3 파일로 변환하려면

1) 서버가 text 를 받음
2) 해당 텍스트를 VMware 속의 Windows 소켓 서버로 보냄
3) 소켓 서버는 해당 텍스트를 클립보드에 넣고
4) Macro Express로 작성된 매크로를 실행함 (GUI 찾고, Focus 잡고, 클립보드 붙이고, 저장 버튼 눌러서 wav 로 떨구고)
5) 떨궈진 wav 파일을 VMware 밖으로 리턴하여 재생
6) 필요하다면 ffmpeg 으로 mp3 변환후 스마트폰으로 전송하여 재생

위의 과정을 거친다. 라이센스 비용만 $138 + $50 + $39.95 = $227.95 고, 각 브리징 코드들을 작성하는 인건비를 계산해보자. 내 연봉이 4천만원이라 치고 위에 열거된 브리징 프로세스를 생각하고 작성하는데 4시간 이상이 걸렸으니(Macro Express 공부가 컸음) 인건비로 8만원이 들어간거다. 그러면 인건비 $100 라 치고 총 개발비 USD $327.95 . 여기에 물리적 장비 비용은 포함되지 않았다. 똥컴이여도 되지만 아무튼 필요하다.

==========

안드로이드 TTS Engine 인 SVOX Korean 을 구매한다. Voice 당 1.99 파운드다. 대략 USD $3.

1) 서버가 text 를 받음
2) 해당 텍스트를 C2DM payload 로 보냄
3) C2DM BroadcastReceiver 에서 TextToSpeech.speak 으로 재생
4) 필요하다면 TextToSpeech.synthesizeToFile 로 떨궈서 외부로 리턴

라이센스 비용은 총 USD $3. 위 과정의 브리징 코드 작성에는 30분도 안걸리므로 인건비는 1만원. 총 개발비 USD $12. 안드로이드 사용자는 추가 물리적 장비가 필요없지만, 구지 따로 돌리고 싶다면 삼성 갤럭시 미니 정도가 좋다. 내가 자주 가는 마트에서 99 파운드 (대략 18만원, USD $150 정도).

==========

Neospeech 의 Yumi 보다 SVOX 의 Sora 의 음성 퀄리티가 떨어지긴 한다. Voice DB 파일 크기가 Yumi 의 경우 63MB, Sora 는 18MB 인데 딱 그만큼의 퀄리티 차이가 나는 느낌.

Categories: Development Tags: