lunatic temporary field

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

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

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

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

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

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

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

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드 - 자레드 리차드슨 외 지음, 최재훈 옮김/위키북스

Ship it! 은 개발 프로젝트 수행 단계, Release it은 개발이 끝나고 라이브가 진행중인 단계에 도움이 될만한 책이라고 널리(?) 알려져 있다.
근데 난 어찌 순서가 좀 거꾸로 된듯 싶은게, Release it을 먼저 (빌려)읽은 후 이 책을 봤다(...).

Release it 같은경우 번역 문제도 그랬지만(참고로, r모님 말씀대로 Release it 같이 좋지 않은 번역서는 정말 번역서 질의 향상을 위해서라도 사서 보아선 안된다고 생각한다.), 특정 분야를 어느 정도 잘 알고 있지 않으면 원서로 보아도 많이 힘들 것으로 생각된다.

반면!.
ship it은 개발자에게도 좋은 참고/재밌는 이야깃거리가 될 뿐더러(개발자는 한번 두번 세번, 사과를 그려가며 읽어도 재밌다), 개발자와 같이 일해야 하는 비개발자들도 한번 거들떠 보면 더불어 살아가는 데 좋을 듯한 책이다.
다른 실용주의 개발 책들과 달리, 실험해 볼 수 있는 실제적인 방법들을 비교적 소상히(?) 소개하고 있다.
난 특히 다음과 같은 소재들이 마음에 들었다(스포일러이므로 볼 사람만 보시오).

===몇가지 소재들===

위의 스포일러도 호기심이 가지만, 정말 공감했던 부분은 Co-work의 중요성이다. 개발자 동료가 또라이라도, 덕후라도, 히스테리 노처녀라도, 혹은 히키코모리라도 이에 굴하지 않고 팀웍을 다지고 모두들 똑똑해지는 게 얼마나 중요한 일인지 강조하는 게 참 맘에 들었다. 아쉽게도 그건 현실에서 백만톤 정도 힘든 일이긴 하지만. 처음부터 어긋난 만남이라는 게 얼마나 무서운지. 일터가 평화로울지 전쟁터가 될지는 이미 구성원에서 XX% 정해진다고 난 믿는다. 아무리 좋은 프로세스/도구가 있어도 사람들이 고집스럽게 이를 무시하고 막나가거나 배째는 경우 결말은 "nice boat"임이 뻔히 보이는 것을(머엉).

대부분의 한국 회사(뿐만 아니라 외국에 있는 회사들도 어느 정도 그렇다고 들었지만,)는 수직적인 성향이 강하여 아래로부터 멋지구리하다고 생각하는 팀웍들을 실험해 볼 여지가 그닥 많지는 않다고 본다. 그래도 지금 버리버리 개발자 레벨일 때 이리저리 "어떻게 하면 정신줄 놓는 일을 덜 만들 수 있을까", "어떻게 하면 일을 확 줄여서 빈둥빈둥 일해도 월급 잘 받아 먹으며 살 수 있나" 잔머리 굴려보고 뚝딱뚝딱 해보는 건 정신/육체 건강에 꽤 도움이 될 듯.

이 글의 주제는 참으로 기본적이고도 중요하고 어려운, 내 8년 코딩 인생 "디버깅 쌈질 로그"의 78.675%를 차지하는 memory access violation이다.
포인터를 몇번 써본 개발자라면 척하고 다들 아는, 예를 들면 이런 슬픈 이야기이다.

---
안드로메다 마을에 사는 순이는 C언어로 된 동물의 숲 소스를 만지작 하고 있었습니다.
인사말을 여러개 정해서 하나씩 써먹고 싶어서, 인사를 하는 부분을 살짝 고쳤지요.
다음과 같이 포인터를 선언하고 인사말을 여러 개 채웠답니다.

char**  hi;
hi[0]="안녕하세요?";
hi[1]="왓썹맨~";
hi[2]="이 폐인아!!!";
hi[3]="공부나 하시지?";

print_hello_message(hi[random()]);

맨날 "안녕하세요?"만 하다가 다양한 레파토리를 확보한 순이는 신이 났어요.
컴파일 해서 다시 마을 문을 열고, 들어가 마구마구 휘젓고 다니기 시작했습니다. 패트라한테도 인사하고, 럭키한테도 인사하고, 못생긴 짠돌 너굴이한테 인사할 때마다 매번 다른 말을 할수 있는거에요!! 킹왕짱!.
드디어 이 마을에서 가장 동숲폐인부자인 룬님이 멀리서 오고 계세요. 어서 인사를 해서 잘보여야 돈을 주겠지요?

인사하자 고고!! 무브무브!!
하고 룬님을 향해 한발짝 발걸음을 옮기는 순간.



눈 앞에 빨간게 번쩍.



마을에 핵폭탄이 터져 안드로메다 마을 사람들은 모두 죽고 말았답니다.
빵!!!

(끛)
---

지금은 디버깅 쌈질 로그가 뇌에 8년어치 쌓여있는 상태라, 대략 이런 경우의 50.32% 정도는 대충 이러이러하겠네라고 금방 찾아나갈 수 있지만, 위의 순이 이야기에 나오는 것 같은 랜덤 폭탄은 여전히 무서운 이야기이다. 한번 멸망한 마을은 이전으로 돌아갈 수 없다(...).

이 폭탄들을 어떻게 하면 개발자들이 쉽게 찾아내고 안전하게 제거할 수 있을까 하는 문제는 고민해 볼만 한 것 같다.
메모리 공간을 꼼꼼하게 체크하는 메커니즘을 디버거에서만 고안해도 선량한 프로그래머의 철야 질주가 좀 덜하지 않을까나.

그러나 완벽하지 않은 데는 다 나름의 이유들이 있는 걸 알기에 ㅠㅠ.
OS나 컴파일러가 이래서 외계분야인 거지.

"남의 집 땅은 밟지 마세요" 라는 팻말보다는,
남의 집 땅을 밟는 순간 삐요삐요가 울리며 "꼼짝마"를 외치는 코딩 사회를 난 원한다고!!!.


ps: 한참 신나게 포스팅을 하다가 컴퓨터씨가 다운되는 바람에 다 날리고(쉤),
의욕이 30%로 줄어 내용의 의도와 성실함도 30%로 줄었다.ㅡㅡ;;

근 한달 넘게 ndsl 동물의 숲에 허덕이느라 다른 게임은 쳐다볼 시간(과 체력)이 없었답니다.
오늘도 동숲에서 여러 짐승들의 사진을 받기 위해 ndsl 본체 시간을 순차적으로 돌리다가 뽀숑하고 떠오르는 문제가 있어 결국은 날림 블로그마저 뚝딱뚝딱 하고 말았어요(...).
왜 본체 시간을 이랬다 저랬다 해야 동숲을 잘할 수 있는가!! 는 본론이 아니므로 생략하고(머엉) 우선 현상과 몇가지 단서를 정리해 봅시다.

• 문제
  • 어째서 ndsl의 시간은 전원을 꺼두어도 항상(거의) 정확히 흐르는 걸까요?
    
    
• 좀더 자세히
  • ndsl은 본체 시각을 한 번만 맞추면 그 뒤에는 알아서 시각을 계산합니다. 동숲같이 "시간"이라는 개념이 중요한 게임을 하고 있지 않다면 무시하고 넘어갈 수 있는 부분이지요. 현실 세계와 똑같이 시각을 맞춰놓은 분들이라면 기계를 껐다 켰다 해도 늘 본체 시계가 현실과 똑같은 시각을 가리키고 있다는 걸 알 수 있을 거에요.
    즉, 오전 9시 1분에 게임기를 끄고 10시간이 지난 후 다시 켜면 본체 시각은 정확히 19시 1분이라는 겁니다. 매번 전원 켤 때마다 시계를 다시 안맞춰도 돼! 라는 거지요.
  • 휴대폰과 같이 유선/무선 인터넷이 가능한 전자기기들 같은 경우 "전원이 켜질 때마다 시간 서버에 접속해서 동기화를 하면 상대적인 시각을 계산할 수 있어요!"라고 하겠지요. 네 맞습니다아~. 그래서 해외로 로밍 안하고 가져나가면 0시미아가 되는 핸드폰도 있는 게지요.
    그러나 제 ndsl은 Wifi도 없는 가난한 아이입니다(...).
  • 심지어 배터리가 오링이 난뒤 몇 날이 지나도 다시 켜면 ndsl의 시각은 정확히 지나 있습니다. 알람으로 쓰는 자명종 시계도 배터리가 오링나면 밥을 먹여주기 전엔 파업을 하는데!!. 도대체 무슨 조화로 배고파 죽은 애가 시간을 세며 부활을 꿈꾸는 걸까요?.
    
    
• 여기서 안드로메다로 가는 힌트!.
  • 다음과 같은 유사 제품(?)이 있습니다 :
    "인터넷을 연결하지 않은 컴퓨터는 무슨 조화로 시간을 맞추는 걸까요?
    본 문제는 위 문제에 + "컴퓨터와 ndsl의 차이"를 생각해 보면 쉬리릭~. 답이 나올지도 모릅니다(글쎄).
    
    
• 말이 되는 답은 뭘까나요?
  • 예상 답안을 공개하면 재미없잖아요(...). 심심한 분은 댓글을.
  • 다른 인생사의 문제들도 그렇지만 답이 꼭 하나는 아닐 것 같지 않아요?
    

의외로 신기함에 비해서는 가벼운 문제일지도 모르지만, 상상하다보면 제정신이 아닌 데까지 갈지도 모르지요(안드로메다 마을에 사는 순이가 ndsl 속에 살고 있어 매번 맞춰준다든지!). "시간"이라는 건 인간이 뛰어넘지 못하고 있는 축의 하나라서 그런지 생각하다 보면 재밌는 게 많아요. 코딩질만 하더라도, 관련된 사람이라면 "타이밍"때문에 눈물 흘릴 때가 많지요. 이런 "사소한" 문제부터 "우주의" 문제까지.


처음 "내컴퓨터"를 가졌을 때의 추억과 연결되어 1등 당선!.
자 이렇게 가벼운 형광등 거리로 첫 포스팅을 마칩니다(개날림).


ps: 귀찮아서 이거저거 꽁기꽁기 해봐도 결국 전 조만간 그랑엘베르님 돕기 성금을 낼 것 같습니다(머엉). 포스팅 백업이 잘 옮겨지면 덜 귀찮을듯(...).