lunatic temporary field

windows7.

lune_ — Thu, 01 Oct 2009 11:58:18 +0900

가끔 지름신이 심하게 신호를 보내시는 넷북들 중, 요거 장착 예정인 애들이 많은듯.
(넷북과 맥북중에 갈등하느라 결국은 아무것도 사지 못하는 상황의 연속 ==.)
xp보다 넷북서 쓰기 괜찮은 걸까나~. 반응은 나쁘지 않다긴 하던데..

windows7 런칭파티를 한다고 해서,
나름 신청은 해뒀지만.
순위권에 들 것인가 ㅠㅠ.

내게 알맞은 전공? ;-;

lune_ — Sat, 13 Sep 2008 17:42:06 +0900

바우 블로그에서 보고 해봤다. 대략 이런 영어로된 문제 ;-;...
근데 살짝 결과가..

dance가 상위권인건 납득(?) 이다만...

philosophy 100% ㅡㅡ;;;
사람의 존재에 대해 생각하는 걸 좋아한단다...(넌 누구냐!!!)
그리고 대략 순위권 중에 "Theater".....
이건 머냐....;; 씨어터댄스?ㅋㅋㅋㅋ

후보군 중에 music이 없어서 뭐 그닥ㅡㅡ.
머 걍 심심풀이 심심풀이~.

누구나 일주일 안에 피아노 죽이게 치는 방법.

lune_ — Sun, 27 Jul 2008 21:43:00 +0900

누구나 일주일 안에 피아노 죽이게 치는 방법 -
전지한 지음/에듀박스(주)

일단은 '피아노 교본' 이지만.. 피아노 교본만은 아닌 책.
(책 겉표지에 보면 "피아노 교본이 들어있어요!"하고 작게 쓰여있다. 초큼 깜찍함 허허허;-;)
사실 읽어보게 된 이유는 '전지한 씨가 썼기 때문에'가 79% 정도 된다.
하지만. 읽어 나가면서. 피아노를 하나의 도구로, 또 빼놓을 수 없는 친구로 여기는 저자의 마음이 느껴졌고.
쉉과 피아노와의 인연에 대해서도 자연스럽게 떠올리게 되더라.
"아 이 사람도 그랬구나. 나도 그랬는데." 이런 식의.. '피아노'라는 공통점을 가진 친구와의 대화랄까.

나도 체르니 xx(혹은 xxx)번이 참으로 재미 없었고.
처음 피아노를 배웠을 때 피아노 선생님의 30cm자가 정말 무서웠지.
연습하기가 귀찮아서 치지도 않고 사과를 30개씩 그려가기도 했고..

나 정말 음악적 재능이 조금은 있었구나.
뭐 없었더라도,
나 정말 지금도 피아노를, 나아가서 무슨 수단이건간에 "표현하는 것"을 좋아하는 구나..
이런 것.

피아노 학원 숙제 맨날 어려워서 지겹잖아 그 나이엔(백번치기 삼백번치기 ;-;).
그래서 한 한시간 넘게 머리에 그냥 떠오르는 가락을 마구 피아노로 쳤었어.
그리고 피아노가 그 가락을 맘에 들어하는지 아닌지.. 물어보면서 놀았던 것 같아.

지금 생각해보면 별게 아니라 그게 작곡이었나? 라는 생각도 들고..

그거 말고도 여러 재밌는 일화(?)가 있지만. 그건 기회가 있으면 다음에.

그런데.
"어려운 곡을 슁슁 칠수 있어야 피아노를 잘 치는 거니까" 라든지.
"작곡을 하려면 뭔가 어려운 걸 체계적으로 잔뜩 배워야 할거야" 라든지.
"음악가나 가수나 그런 건 천재들만 할 수 있는 거야" 라든지.
이런 통념이 무의식적으로 있던 채로 컸기 때문에 .
또 중학교 들어가서 부턴 집에서 "넌 공부를 해야 한다. 음악하면 뭐먹고 살거냐."하고 악기를 못하게 하면서.
내 인생은 지금 이런 모냥(?)이 되었지.

며칠 전에 우연히 초등학교 통지표들을 보았는데.
내가 스스로에 대해 평가(?)해서 적는 부분이 있고,
당연하겠지만 선생님이 적는 부분이 있거든.

나는 언제나 장래희망에 "작곡가", "음악가"를 적었는데...(클래식의 의미가 아니라 요새 흔히 사회가 말하는 뮤지션.의 의미였다고 생각한다.)
좋아하는 과목엔 음악을,
싫어하는 과목엔 산수를 적었는데...

선생님 종합 의견에는 "논리적인 사고가 뛰어나고 이해가 빠릅니다. 수리과학적 문제 해결을 잘합니다."
이런 말밖에 없더라. 나 산수, 자연은 가끔 우 받았어도, 음악은 올수였는데..ㅡㅡ.

지금 직업 싫어한 적도 없고, 가끔 스파크가 일면 재밌기도 하지만.
그리고 지나간 시간들에 대해 후회는 없지만.

새삼 "사회가 바라는 대로 커버린건가!!!" 라는 생각에..
누구도 내가 진정 하고 싶었던 것. 좋아했던 것을 이해해 주지 않았다는 생각에..
억울할 때가 있다.

그래도.
잘 한다곤 말할 수 없지만.
삶에 늘 함께 있으면서 거리낌 없이 이야기할 수 있는 친구들(그 중에 하나가 피아노)이 여럿 있다는 건 멋진 일이지.

뭔가 리뷰가 아니라.. 내 이야기만 끝없이 주절주절.

여튼 결론은.
적금타는 그날이 기다려진다(?).

블로그 문답

lune_ — Wed, 30 Apr 2008 16:19:25 +0900

야바위==(우주)독일인==군주사마==타이호==rein 님이 받으라 협박하신 바톤입니다.

1. 블로그는 어떻게 시작하셨습니까?

2008년 2월 어느날 새벽.
NDSL로 동물의 숲을 하다가 갑자기 만들까나~ 하는 생각이 들어 시작했습니다.

2. 하루 포스팅 수는 얼마나 됩니까?

1/7~1/14개 정도인 것 같습니다. 이야기 거리가 떠오를 때 / 정리된 생각들이 있을 때 포스트를 출력합니다.

3. 블로그의 주제는 뭐죠?

이성적인 주제이고, 누가 봐도 상관 없을(?) 것들이라면 딱히 제한이 없습니다.
감성적이거나 딱히 일정 분량 이상이 나오지 않을 것 같은 자잘한 글, 음악이나 춤 등 취미 관련 컨텐츠(?)는 미투데이나 사이월드로 갑니다.

4. 블로그 이웃들과의 사이는 어떤가요?

이글루스 전용 문제라고 하는군요. 패쓰!.(전 이웃이 엄서요 ;-;).

5. 메신저에 블로그 이웃들이 얼마나 있습니까?

이글루스 전용 문제라고 하는군요. 패쓰!.

6. 하루에 블로깅을 몇시간씩 합니까?

평균을 잡자면 머리에 포스트 입력은 대략 1/3~1/2시간, 포스트 출력은 5/7시간 정도입니다. 하지만 variation이 많아요. 출력은 주로 금욜~일욜, 휴일들의 자정 넘은 시간에 합니다.

7. 블로그 이웃들중에 자신보다 나이 많은 사람과의 교류는 어느정도죠?

이글루스 전용 문제라고 하는군요. 패쓰!.

8. 블로깅을 하면서 바뀐점이 있나요?

얼굴이 옆으로 퍼지기 시작했습니다.
신화 9집이 나왔습니다>.<!!!.

9. 존경하는 블로거가 있나요?

있습니다. 당연한거 아닌가요(훗).

10. 자신의 블로그의 수준은 어느정도 된다고 생각하나요?

유딩수준이지요. 출력할 땐 주석도 귀찮아서 안달고 주절주절합니다. 조만간 이전 계획이 있는데, 그때 뭔가 초딩수준으로 업그레이드를 시도해 볼 생각은 하고 있습니다.

11. 다음 바톤상대를 정해주시겠어요?

글쎄요.. 생각점 ;-;

개떡책 리뷰

lune_ — Thu, 24 Apr 2008 21:52:24 +0900

소프트웨어, 누가 이렇게 개떡같이 만든 거야 -
데이비드 플랫 지음, 윤성준 옮김/인사이트

이 책의 타겟이 굉장히 모호하다.
일단은 소프트웨어를 쓰는 개발에 대해 아무 것도 모르는 사용자들.
그리고 은근 슬쩍 이 책을 보며 괴로워할 개발자들.
플래시 천국을 찬양하는 웹디자이너.
등등.
정도인 거 같은데..

기분 전환으로 읽기 좋은 책이라고 생각된다.
번역하시는 분이 뒤로 갈수록 지구력이 떨어졌는지 약간의 오역과 비문이 보이긴 하지만.
(나한테도 보이는 정도면 사실은 더 오타가 있을듯?)
또한 주제도 이것 저것 복작복작해서 여기 저기 들쑤시고 다녀 난잡한 느낌이 있긴 하다만.
하드코더로만 살면 만들어 내기 어려운 "쎈쑤"가 이 책엔 있는 듯 하다.

개발자 생활을 하다보면 하드코더 유니버스에 빠져서 컴덕후가 되고, 흉측하고 복잡한 피규어를 생산해내면서 변태처럼 흐흐흐대기가 쉬운데,
적정 선에서 "그러지 말고 일주일에 한 번은 지구로 돌아와" 하고 말해주는 느낌이랄까.

음.. 근데 인터페이스에 대한 내용에 대해 약간 논란의 소지가 있는걸.

"확인 체크 박스"에 대해서

"확인 체크 박스"라는 건 다른 게 아니라, 윈도우에서 파일을 지울 때 "정말 지울거냐? 네/아니오" 하고 나오는 그 상자같은 애들을 말한다.

대학교 다닐 때 "컴퓨터와 마음"이라는 심리학 수업을 들은 적 있는데(컴퓨터와 마음이지만 컴퓨터와는 별 상관 없고, 뇌심리학 개론 정도였음), 거기서 심리학 교수님은 이 박스를 예로 들며 "마이크로소프트는 천재다. 사람들이 멍청하게 무심코 파일을 무의식적으로 용도도 생각해 보지 않고 지우려고 할 때 '정말 지울래?'라는 물음을 통해 잠시 정신을 번쩍 들게 한다" 며 엄청 칭찬했던 기억이 난다. 사람의 행동 패턴을 잘 반영한 거라고.

그러나 이 책을 지은 아저씨는 "쓰레기"라고 한다. 왜 괜히 팝업창을 내보내서 우리를 귀찮게 하느냐며.

뭐 사람의 관점에 따른 문제인 것 같기도 하고.
(쉉은 별로 좋아하지 않을 경우가 많다. 특히 가끔 웹페이지가 잘못 만들어져 있을 때 무한 에러창 루프를 돌 때가 있는데... 모니터에 폭탄을 던지고 싶다 ㅡㅡ)

보안에 대해서는 꽤 재미있는 관점을 읽을 수 있어서 즐거웠다. 보통 암호학이나 보안 수업들을 들을 때 인트로 격으로 많이 듣는 이야기가 바로 "아무리 보안 시스템 잘 만들어 봤자 도둑들면 말짱 황이다"였는데.. 뭐 사회적인 '오프라인 보안 불감증' 말고도 보안에 대한 글쓴 아저씨와 몇몇 해커들의 재미있는 철학을 살짝 볼 수 있었다.

인터페이스나 보안 말고도 컴덕후의 철학, 프로그래머의 심리, 고객의 심리, 마이크로소프트에 대한 철학 등등 여러가지 주제에 대해 이야기 하고 있다. 뭐 마소에 대한 이야기는 그냥 넋두리인 듯한 감도 없지 않아서(?) 쫌 지루했지만 나머지는 시간 들여 읽을 만 했다.

===이건 개인적인 감상===

책 자체가 그렇게 읽는 데 오래 걸리는 책은 아니지만, 들고 다니면서 차 안에서 안잘 때 가끔가끔 읽어서 시간이 좀 오래걸렸음.

제목에 낚여서 산 책이긴 하다만.
나름 재밌고, 리프레시가 되는 거 같다.

일에 대해 더 많이 배울 수록, 그 일을 전혀 다른 관점에서 관찰해야 주화입마에 들지 않고 훌륭한 어린이에 가까워지지 않을까?(쉉은 아직 배운 것보다 배울 게 오백만십배는 더 많다만 ㅡㅡ;;)

ps: 요새 쓸거리/생각할 거리가 너무 많다 보니 오히려 정리하는 게 무서워서 ㅡㅡ 그래도 책 리뷰가 금방 뚝딱뚝딱 하기 쉬우니 비중이 많은 듯 하다.

올해는 머할까용.

lune_ — Thu, 10 Apr 2008 01:04:19 +0900

이 추세로 보아하니 올해 농땡이질은 다음과 같고 있는듯.

컴질 이론
- 메타프로그래밍 : 뭔가효 오티엘.
- TAOCP 1권 문제: 풀어보기 시작
언어
- 일어 : 예숙샘 살려주셈 ㅠㅠ.
- 영어: 스티부샘 살려주셈 ㅠㅠ.
- erlang : C의 76.8% 정도는 익숙해지고 싶음.
- 이선이(python): C의 121% 정도 많이 사용하고 싶음.
춤
- 재즈 : 언제 머리가 땅에 닿을까효. 언제 1회전이 맘대로 될까효 ㅠㅠ.
- 힙합 : 팝핀도 배우고 싶지만 일단 참자(...).

뭔가 많은 듯도 싶으나,
쉉은 원래 빈둥빈둥이라 한개를 하든 열개를 하든 각각의 달성률이 고만고만하고, 폐인짓도 잘한다(머엉).
그래도 음악계까지 추가하면 하드웨어 과열될 것 같아서 얘는 연말에 신디 지르기 전까지 보류하기로 했다.

공통점은...
지진아ㅠㅠ/.

erlang으로 하면 잼날것 같은 아이들.

lune_ — Thu, 10 Apr 2008 00:40:51 +0900

근래 회사에서 erlang을 주제로 팀스터디를 하고 있다.
꽤 템포가 빠르게 진행되어 벌써 책 한권이 다 끝날 위기(?)에 놓여 있는 상황.

스터디를 하다보니 꽤 재미있는 언어인 듯도 하고.
기왕 언어 스터디를 했으니 앞으로 여기저기 써볼 수 있는 여지가 많지 않나 해서..
만들면 재밌을 것 같은 아이들을 호구조사+생각해 보고 있다.
내가 생각하기에 얼랭으로 뭔가 짠다고 한다면, 다음과 같은 특성을 가진 예제면 더욱 좋지 않을까 한다.

Concurrent Programming이 필요한 예제(예를 들면 분산처리 관련이라든가..)
함수지향 언어의 득을 볼 수 있는 예제(이건 좀 판별이 어렵긴 합니다만)

지금까지 후보로 올린 애들은 다음과 같다.

그래픽스 관련 예제 아이들.
- 그래픽스/아니메 시간에 배웠던 각종 근사기법들만 보아도 엄청 컴퓨팅 파워가 소모되고, 컨커런트하게 짜면 개선될 여지가 많다.
- 예: ㅎㅁ성인님께서 쏴주신 "레이트레이싱".
- 예상 난이도 : 중~상
MapReduce
- ㄹㄹ님께서 쏴주신 주제. 물론 책에 구현예가 있긴 하지만, 사람구실을 하게 만들려면 이것저것 추가해야 할 것이 좀 있는듯.
- http://labs.google.com/papers/mapreduce.html 에 보면 재밌어 보이는 리서치 페이퍼(?)가 있다. 휴일에 구경해야지 하고 프린트해서 왔건만. 지름신의 난때문에 아직 한줄도 못봤뜸 ;-;.
- 예상 난이도 : 중~상
엄청 컴퓨팅 시간이 오래 걸리는 계산 문제들
- 쉉의 생각에는 NxN 행렬 계산들만 해도 충분할듯.
- 예: ㄹㄹ님께서 쏴주신 NxN(N은 열라 큰 정수) 행렬의 eigen vector / eigen value 구하기.
- 예상 난이도 : 중하
멀티미디어 인코더 / 디코더
- 소싯적에 관련되어 있었던 수많은 병렬처리 실험 마루타들이 여기에서도 효과를 보지 않을까 싶다. 단점은 인코더/디코더 알고리즘 자체가 흠좀무 한것들이 많아서 분석 기간이 꽤 소요된다는 것. 뭐, 병렬로 쪼갤 수 있는 모듈만 erlang으로 짜고 나머지는 C로 인터페이스 하는 방법도 있지.
- 예: mp3 인코더인가가 책에 있었던 것도 같지만, jpeg, h26x 인코더/디코더 등 수많은 멀티미디어 예제들.
- 예상 난이도 : 상
검색 관련 테스트/분석 유틸들
- 골자만 말하자면, 테스트 입력 set을 가지고 패턴을 관측하는 애라든지, 서버가 여럿으로 분산되어서 어떤 처리를 해야할 때 효과적은 분산방법을 찾아주는 애라든지 등등이 있음. 뭐 앗싸리 "분산 검색 엔진"을 만들어도 인생경험은 될듯(ㅎㄷㄷ).
- 이건 부분부분 컨피덴셜(?)일 여지가 있어서 언급 생략.
- 난이도 : 중~최상
프로젝트 관리 유틸들
- TDD에서 테스트돌릴 때, 분산해서 돌리는 유틸 같은거 만들어보면 좋을듯. TDD는 CI(지속적인 통합)에서 유용한 개념으로 적용되기도 한다. 테스트셋이 무지 큰 경우, 분산해서 수행하면 더 빠를 수도 있다.
- 허나, 쉽게 찾아다 쓸 수 있는 유틸들이 많은 실태인지라 괜히 삽만 파고 안쓸 가능성도 조금은 있다. 게다가, 이런 정기적 테스트들은 대부분 오밤중에 걸기 때문에 왠만하면 속도는 고만고만하면 된다는 생각이 있을 수도 있음.
- 예상 난이도 : 중
분산 파일 시스템
- 말 그대로 분산 파일 시스템.
- 내가 만들지 않으면 지구상 누군가가 언젠가 "얼랭으로 DFS 만들었어염!!!" 하고 우쭐댈지도 모른다(아니면 누군가가 벌써 만들었거나). 시간은 쩜 오래 걸릴지도.
- 일단 쉉이 만들려면 분산 파일 시스템에 대해 공부를 좀 더 해야 하고, 혼자 만들면 쓸만한게 나오기 힘들기 때문에 깡좋은 누군가들을 섭외해야(...).
- 예상 난이도 : 상~최상

대부분이 개인적인 흥미에 치중된 지라 팀스터디에 추천하긴 그닥 좀 그런 애들(...).
이 외에도 누가 그럴싸하다 싶으면 추천점 부탁염 ;-;/.

ps: 개인적으로 쉉은 7번은 꼭 해보고 싶다!!!. 스터디에서 할 수 있는 규모는 아니지만.
ㄹㄹ님도 DFS에 워어어 불타시는 걸로 보아 유피넬 웕샵에 던지던지, 직딩 모임이라도 만들어서 추진해 볼까!!

지속적인 통합(CI).

lune_ — Tue, 08 Apr 2008 00:35:09 +0900

지속적인 통합 -
폴 M. 듀발 외 지음, 최재훈 옮김/위키북스

5만원 이상 5천원 할인쿠폰을 쓰기 위해(...) 겸사겸사 구입하였던 책.
"Ship it!"의 일부분과 내용이 좀 겹치지만,
개발 프로젝트에서의 "지속적인 통합"에 대해 한층 더 심도 있게 다루었다고 생각된다.

인상 깊은 부분들을 가리자고 하면 다음과 같다. "Ship it!"과 겹치는 부분은 가능한한 배제했음.

보기-스포일러지뢰밭

"데이터베이스"의 지속적인 통합
- DB를 소스코드와 거의 같은 방법으로 취급하는 이 책의 방식에 상당히 흥미가 생기더라. DBA의 역할은 쓰레기통 뒤치닥거리나 콜센터 요원이 아니라는 게 골자. 역시 모두가 머리싸매고 고민하는 것처럼, "기계가 할 수 있는 일은 기계한테 줘버리고 넌 사람만 할 수 있는 일을 하세요" 인 것이다. 아무래도 쉉은 대용량 자료들하고 관계있는 업계에서 일을 하다보니, DBA가 얼마나 스트레스를 받을 것인지 좀더 와닿는듯. 그러나 대부분의 회사에는 DB팀이 따로 있는지라, 윗사람이 되지 않는 이상에야 비효율을 고치는 건 상당히 힘들지도(...).
- "개발자도 DB를 왠만큼 잘 알아야 된다!!!" 라는 설교에 뜨끔 ㅠㅠ. 쉉은 사실 DB를 좀 싫어한다. 순전 취향+걸어온 길의 영향이라고 볼 수 있지. 그래도 개발을 하는 이상(게다가 요새는 DB랑 좀 많이 상관 있어진 일을 하게 되었다 ㅡㅡ;;) 편식을 하면 안되나보다.
"코드 검사의 자동화"
- 왠만큼 제정신인 회사들은 형식은 조금씩 달라도 다 저마다의 "Coding Standard"를 가지고 있다. 하지만 대부분 "이렇게 제발 해주세요" 하고 매뉴얼로 권장만 하고, 강제할 수단이 거의 없다. 그래서 보통 Coding Standard를 무시하는 개발자(개발 프로세스를 무시해야 개발을 빨리 끝낼 수 있다는 미친 생각을 하는 개발자들이 세상엔 꽤 많은 것 같다)들이 개발(말 그대로 dog의 foot을 의미) 코딩을 해놓고, 다음과 같은 순서로 일이 진행되는 듯.
  - 그나마 정해놓은 Rule을 검사도 안하는 회사에선, 걍 그러고 만다. 그 코드는 시간이 지나면 만든 사람도 모르는 코드가 된다.
  - 나중에 회사에서 정한 Coding Standard를 지키기 위해 몇주씩 체력소모작업을 한다(오마이갓).
  솔직히 난 이걸 자동적으로 검사해 주는 툴이 있다는 정보를 잘 몰랐다. 그래서 표준을 안지키는 개발자를 원망만 했지. 때로는 나도 못된 버릇이 들어 표준을 잘 안지키기도 했고 ㅠㅠ.
  정적 검사 툴들이 얼마나 도움을 주는지 함 구해서 써봐야 할듯.
챕터 시작 부분마다 있는 명언(?)들
- "이 빌어먹을 우주는 조각조각 내서 다시 구축해야 한다"
  4장 도입부의 명언이다. 우왕국!!! 머찌다!! 이 밖에도 가슴에 팍팍 꽂히는 명언들이.. 쎈쑤쟁이!!!
머릿말과 역자서문 아스트랄!
- "저는 영원처럼 느껴질 정도로 오랜 세월 지속적인 통합에 푹 빠져 지내왔습니다."(폴 줄리어스의 머릿말 중)
  -->감상: 컴덕후시군요(머엉).
  
  이 책의 온갖 머릿말들은 꼭 놓치지 않고 정독하시길.ㅋ.

물론 평사원이 범접할 수 없는 영역들이라는 것도 있게 마련이지만(또한 쉉은 이빠시 마루타가 되어본 뒤 이게 좋다고 확신하기 전까지는 남에게 이게좋아!!! 하고 주장할 수 없는 성질이기도 하다;-;).
자기가 할 수 있는 영역 내에서 계속 새로운 시도를 하면서 일을 하면 좀더 일이 신나지 않을까나.
취미 생활도 마찬가지고.

ps: Ant라는 게 이책 저책에 계속 주연급으로 나오는군. 함 써볼까 ㅡㅡ.

The No.1 Ladies' Detective Agency.

lune_ — Sun, 06 Apr 2008 23:28:04 +0900

The No. 1 Ladies' Detective Agency (Paperback) -
알렉산더 매컬 스미스 지음/Anchor

한 마디로 "black fat woman의 탐정질을 통한 인생 멜로 드라마" 라고 할 수 있겠다.

추리소설이라고 하지만 맨 끝까지 가도 스릴이나 긴장감이나 퍼즐 느낌은 한개도 없었다.
뭔가 있을꺼야 했으나 책 중반을 넘어가니 서서히 지쳐갔다. 이게 뭥미 ㅡㅡ.

맘에 안든 부분들-스포일러여행

저엉말 "꾸역꾸역" 읽은듯.
왕 비추.

이 작가 이런 비슷한 책을 5권 넘게 낸거 같은데.
절대 안볼테다 ㅡㅡ.

R&D에서 토론 진행하면서 유용하고 재밌는,(책과는 별 관계 없는) 몇 가지를 득템했는데.
그것에 대해선 나중에 포스팅을 따로(음 하나는 19금이라 포스팅은 못하겠군 머엉).

성실함과 귀찮음.

lune_ — Sat, 29 Mar 2008 02:18:12 +0900

오랫만에 잡담 포스팅.

어딘가 웹을 허부작대다가

"자기 일 다 끝났다고 분위기 파악 못하고 노는 개발자넘은 재섭다"
라는 내용의 글을 봤다.

뭐 그 사람의 의도는 그게 아니었다고 생각되나.
확실히 작년 1년동안 나의 특성이 변질된건지.
머리 속에서 버럭! *$#^*#(!!!! 하고 폭발이 있었다.

대충 이런 내용의 생각들.
"내 일 끝났어도 다른 사람이 일 못끝냈다고 일요일->월요일로 넘어가는 새벽 네시반까지 일해야 되는거냐!" 라든지.
"애당초 못끝낼 일을 오케이하라고 시킨/오케이 한 누군가가 잘못이지!" 라든지.
그 밖에 꿀렁꿀렁.

뭐 저런 건 지극히 극단적인 경우일지도 모르지만.

지금도 약간은 적용되는 논리.

아는 사람은 알다시피 쉉은 현재 서비스 개발(이라고 쓰고 개발겸 영자라고 읽는다) 노릇을 하고 있는데.
요새의 고민거리(?)라고 한다면.
"어떻게 하면 AS를 줄이고 탱자탱자 놀 것인가?" 이다.

짧은 시간이지만 영자를 하면서,
"이건 이렇게 하면 내가 더 놀 수 있겠구나."
"이런 툴을 만들면 난 더 땡땡이 칠 수 있겠구나."
이런 생각 하면서 영자 한 두달 정도 공부도 하고, 툴도 만들고, 코드도 다듬고 해서.
실제로 처음에 수동작업으로 처리했을 때보다 AS처리가 적어도 30%는 감소한 것 같다.
뭐 별로 대단하고 어려운 일을 한 건 아니다만(나를 아는 사람은 내가 어렵고 아름다운 일을 하기엔 한없이 허당이란 걸 잘 안다ㅠㅠ), 아주 간단한 일들만 해도 이렇게까진 할 수 있더라..

30% 감소한 시간동안 놀기도 하고, 다른 공부들도 했지만 별 죄책감은 없다.

만약 내가.
"우주 성실맨이 되어야지. 남이 귀차나 하는 일도 내가 다 해야지!!" 라든지
"야근따위 백만번 해도 상관업써 무조건 열씨미!" 라는 생각을 품었다면.
저렇게 잔머리 굴리고 더 관리하기 편한 방법을 모색하고 그랬을까나.
완전 무식쟁이처럼 영자노릇을 하면서 나는 성장하고 있구나 하는 말도 안되는 망상으로 므흣해했겠지.

고로 지금은.
"개발(과운영) 역량의 발전은 61%의 귀찮음과 29%의 책임감, 9.5%의 외계통신, 42%의 지겨운 일을 재밌는 일로 만들기, 34%의 전력토끼로 이루어진다" 주의인지라.

코웍이 정말 중요하긴 중요하지만.
그게 "니가 좀 느리면 내가 니꺼까지 다 떠맡아서 몇날 며칠 밤새서라도 해줄께"의 의미는 아닌데... 싶다.

서로가 서로의 줄주리타가 되어서 도와주고.
그 결과 달 한명은 주룩주룩 야근할 일을 한달 모두모두 칼퇴근으로 해낼 수 있으면,
거기까지가 아니어도 그 한명이 일주일 정도만 야근할 수 있도록 도와주면.
그게 킹왕짱이 아닌가나.
이렇게 만들기도 무지무지 어려운데!.
놀지도 말라는거냐!.

그렇다고 성실함은 아무 쓸모도 없다는 얘기는 아니고.
다른 도메인의 성실함이 필요한듯.

눈치 보느라 못놀고.
눈치 보느라 말도 안되는 얘기에 반박도 몬하고.
눈치 보느라 없는 야근 지어내서 잠못자고.
아무리 재밌는 일이라도 생존권을 침해하면 재미있을 리가 없다.
전력으로 시러한다 ㅡㅡ.

ps: 머 내가 10년 넘게 이 업계에서 일하면 가치관이 바뀔지도 모르겠지만.
허당 초보일 때 쉉은 이렇게 생각했습니다 하고 남겨놔야지.