'2008/03'에 해당되는 글 4건

  1. 2008/03/29 성실함과 귀찮음. (2)
  2. 2008/03/04 ship it. (2)
  3. 2008/03/02 life of pi.
  4. 2008/03/01 남의 집 땅은 밟지 마세요. (3)

성실함과 귀찮음.

구리구리쑝쑝 2008/03/29 02:18
오랫만에 잡담 포스팅.

어딘가 웹을 허부작대다가

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ship it.

하얀건종이꺼먼건글씨 2008/03/04 00:22
Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드 - 10점
자레드 리차드슨 외 지음, 최재훈 옮김/위키북스



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

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

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


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



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

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

Trackback 0 : Comments 2

life of pi.

하얀건종이꺼먼건글씨 2008/03/02 02:06
Life of Pi (paperback) - 8점
얀 마텔 지음/Harcourt



나의 이 책에 대한 전반적 느낌은.
"노인과 바다" 틱하며 그것보다 난해하다는 것.

그것도 내가 너무나 힘들어하는 영어책으로 읽었기에 죽는 줄 알았으나 ㅡㅡ, 반 강제력을 이용해 겨우겨우 끝냈다(...). 아마 서점에서 내가 좋아서 이 책을 집어들진 않았을 거다. 절대로 ==. 영어책을 읽다가 무슨 얘긴지 당최 모르겠어서 서점에 가 번역서를 집어들었는데, 번역이 오역인건지 원래 어려운 말이 맞는 건지 더 헷갈리고 말아서 결국 오티엘 선언. 모종의 모임에서 꾸역꾸역 자세히 설명을 들어 먹어야 겨우 "아~~"할 수 있었다 ==.

여튼 뭐 쉽게 말하자면.
"한 인도 소년의 태평양 표류, 자아찾기 대모험 + 호랑이와 인간의 합체놀이 분신술 쑈쑈쑈" 라고 할 수 있겠다.

원래 난 이런 류의 안드로메다행 책을 싫어하지는 않는 편인데,
이번엔 영어책이라 알레르기가 난 건지, 힌두교/이슬람교 및 종교에 대한 전반적인 견해가 전혀 안맞아서 그런건지, 배경이 판타지도 아닌 것이 현실 세계도 아닌것이 두리뭉실해서 그런지.
그닥 많이 맘에 들진 않았다 ㅡㅡ;;.

지금부터는 앞서 언급한 모종의 모임에서 나왔던 이야기들과 나름 들었던 생각들에 대해 이야기를 할텐데, 이건 100% 스포일러 무차별 폭격이므로 책을 앞으로 볼 계획인데 김새기 싫다면 보지 마셈.


===실컷스포일러당하기===



끝으로 잡설.

알라딘을 뒤지다 보니  일러스트 판이 있다는 걸 발견했다. 한국어판도 있는듯.

Life of Pi (ILL, Hardcover) - 6점
Martel, Yann/Harcourt


흠.. 이 책 구명보트의 구조, 섬의 구조.. 이런 게 이해되지 않으면 책 절반 이상을 날리게 된다(한국말로 봐도 어렵다. tarpaulin이었던가? 번역본 들춰 봤을 때 "방수포"라고 하던데. 뱃사람도 아닌데 그게 뭔지 어케 아라 ㅡㅡ;;).
일러스트판에는 그런 배 구조나 상황같은게 좀 자세히 들어있을까?
뭐 사진 않겠지만.

Trackback 0 : Comment 0

남의 집 땅은 밟지 마세요.

안드로메다마을 2008/03/01 00:40

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

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

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

print_hello_message(hi[random()]);

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

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



눈 앞에 빨간게 번쩍.



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

(끛)
---

  • 안드로메다 마을은 왜 멸망했을까?

    이야기에 나오는 코드를 뚫어져라 보면 답이 나온다(...).
    알고 보면 굉장히 단순한 문제이면서, 늘 실수를 하게 되는 부분이다. 메모리 할당을 잊어버리는 경우 뿐만이 아니라, 보통 다음과 같은 아찔한 일들을 많이 저지른다.

    • 10개 원소를 가지는 배열이라고 해놓고 11번째 원소에다가 뭘 쓰셈! 이라고 한다.
    • 할당하지 않은 메모리 영역을 free하라고 시킨다.
    • 포인터 변수에 접근하다가 기존에 할당해 놓은 전역 변수의 주소값을 마구 침공한다.
    • define된 상수값을 바꾸려고 시도한다.

  • 시한폭탄의 무서움

    리눅스나 윈도우나, 어느 운영체제에서든, 경험적으로 저런 나쁜짓을 한 경우 100% 확실히 그 시점에 "빵!!"이라고 알려주지는 못한다. 심지어 운이 좋은 경우 죽을 때까지 이게 나쁜짓을 한 거였다는 걸 모르고 지나갈 수도 있다. 이 경우보다 조금 더 운이 좋은 경우는 특정 상황에서 "빵!!"이라고 터지는 것이 반복되는 경우. 이 경우 이 상황에서부터 짚어나가면 문제가 어디 있는지 언젠가는(...) 알아낼 수 있다.

    위의 순이의 경우는 가장 비참하고도 어려운 케이스.
    분명히 나쁜 애는 인삿말 루틴인데, 걸어갈 때 마을이 멸망했다. 그것도 그 전에 막 돌아다닐 땐 괜찮았는데!.
    나쁜 짓을 저지른 부분과 아무 상관없는 동작에서 랜덤하게 "빵!!"이 터지는 것이다.


  • 어떻게 고쳐!!!

    디버깅도 참 비참해진다.
    필자는 보통 다음과 같은 방법을 쓴다. 그러나 이것도 머신에 따라, OS에 따라, 디버깅 쌈질을 하는 시각에 따라 메모리가 할당되는 위치가 변경되면 대략 난감해지는 것이긴 하다ㅠㅠ.

    • 줄주리타 도와주세요 ㅠㅠ.
      코드 검토 헬프를 요청할 추가 뇌를 확보하여 옆에 앉혀놓고 확인을 받는다.
    • 디버거 신공
      gdb(임베디드 환경에서는 armsd같은 임베디드 컴파일러)로 각종 변수들의 16진수 주소값ㅡㅡ들을 마구 추적하여 메모리 값들중 어떤 값이 언제 별나라로 가버리는지 알아내는 방법을 쓴다.
    • 디버거가 없으면!
      그저 하염없이 "이 코드가 맞는걸까!!"를 외치며 해결될 때까지 머리를 쥐어 뜯거나 printf 신공을 쓴다(일반론이지요).
    • 애초에 이런 재앙이 일어나기 전에 되도록 많은 머신, 다양한 OS환경에서 실험하여 폭탄 탐지율을 높인다(보통 사실상 힘든 힘든 경우가 많지만 가능하면..쩝).

임베디드에선- 볼사람만 보세용


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

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

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

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


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

Trackback 0 : Comments 3