인도에 처음 갔을 때 그다지 주류라고 할 수 없는 기술을 써봤냐는 질문에 "그런 일을 할 기회가 없었다." 라는 대답만 들을 때 사실 미칠 것 같았다. "기회가 주어지지 않았다고?! 내게도 그런 기회는 주어지지 않았다!"고 나는 생각했다. 나는 배울 기회를 "붙잡았다."

기회가 없었다고?
기회를 붙잡으라 

인도에서 얼마 동안 지낸 후 나는 '기회가 전혀 없었어요'라는 말이 왜 그렇게 자주 나오는지 설명하는 약간 피상적인 이론을 발견했다. 이른바 저임금 국가인 인도는 영국의 식민지 통치를 받았다. 내가 미국과 유럽을 떠나기 전에는 상상도 못했을 극심한 가난을 그들의 부모나 조부모들은 겪었던 것이다. 1,2세대 상위 중류층과 이야기해 보니 이들의 최우선 순위는 자신의 가족이 상위 중류층에 계속 남아 있는 것이었다.

서양 사람들이 자유분방하게 직업을 고르는 호사스러움을 누리고 있는 반면, 인도 사람들이 서양 사람들과 같은 재정적 자유를 누리려면 앞으로 한두 세대가 더 지나야 할 것이다. 나는 '기회가 없었다'는 답변에 실망했지만 이들 중 많은 이가 집에 컴퓨터도 없었다. "컴퓨터도 없는 소프트웨어 개발자라니!" 아마도 그들에게는 내가 당연하게 여기는 그런 기술들을 배울 여유가 정말 없었는지도 모른다. 이 사실로부터 우리는 중요한 것을 깨닫게 된다.


좋은 조건을 낭비하지 말라. 우리는 자신에게 투자할 수 있는 여가 시간이 있고 대부분의 인도 사람들이 바라는 것보다 더 깊은 지식을 갖출 수 있는 조건에 있다. 여러분이 소파에 앉아 시트콤 한 편 보기, 엑스박스 한 판 하기, 잠깐 공부하는 것 중에서 뭘 할까 고르는 동안 인도 경쟁자(우리 직업을 빼앗는 사람이라고 알고 있음)들은 한 단계씩 승진하려고 애쓰고 있다. 자신의 부모, 배우자의 부모와 함께 살 집을 사기 위해서 말이다. 


지금 읽고 있는 책 '사랑하지 않으면 떠나라'에는 인도의 프로그래머 이야기가 많이 나옵니다. 이 중에 저자가 면접관으로서 바라본 인도 개발자들의 자세가 맘에 들지 않아서 싫어 했는데, 나중에 알고보니 그들 대다수는 형편이 어려워서 정말 자기 계발을 할만한 조건이 못되더라는 이야기가 인상 깊었습니다. 

최근에는 여가부의 정말이지 뭐같은 난리법석 때문에 서비스의 조건이 좋다고는 못하겠지만... 자기 계발을 위한 조건은 인도 개발자들에 비하면 말도 못하게 좋은 수준이겠지요. 책 내용 한 번 옮겨봅니다.

이 것 말고도 좋은 메세지를 많이 가지고 있는 책입니다. 장담할 수는 없지만 책을 다 읽고 나면 다시 한 번 리뷰를 정리해 볼까 합니다. 아직 읽지 않은 프로그래머가 있다면 추천 드립니다.
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

내적 동기유발

2009. 11. 19. 11:16 from 마인드/태도


출처 : http://www.ted.com/talks/lang/kor/dan_pink_on_motivation.html

동기유발에 대한 내용도 그렇지만
창의력을 요구하는 일을 할 때, 틀에서 벗어난 자유로운 사고방식이 중요하다는 내용도 포함한다.

멋진 강의다.
내용의 구성, 발표자의 표현력도 배울점이 많다.

(출처 링크를 따라가서 보시거나 동영상 밑에 SUBTITLE 항목에서 KOREAN을 선택해서 한글 자막을 켜고 보세요)
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://network.hanb.co.kr/view.php?bi_id=981

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://gl3d.net/entry/낮은-자존감이-모든-문제의-근원이다
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

인식의 전환

2008. 11. 12. 11:25 from 마인드/태도
http://xper.org/wiki/xp/_bb_f3_bb_f3_b7_c2_c0_c7_ba_f3_b0_ef

쿄세라의 명예회장 이나모리 카즈오 씨의 저서 "경제학"에는 마츠시타 코노스케 씨가 했던 말이 실려 있다.

"30% 절감하기란 쉬운 일이 아니다. 그렇다면 반으로 줄이면 어떨까 생각해 보라. 30% 절감을 생각하기 때문에 자잘한 것까지 들쑤시려고 생각하고 있는 건지도 모른다. 그러나 반으로 줄인다고 생각하면 근본부터 다시 생각하지 않으면 안 된다. 그러니 오히려 더 편한 것이다"

...

도요타 사에서 근무하던 시절에 필자는 오노 다이이치씨로부터 자주 "0을 하나 줄여라" 또는 "만 엔으로 해보라"는 지시를 받았다.

[도요타식 최강의 사원 만들기]에서 인용

    국내 모 대기업의 회장도 10% 개선은 어려우나 100% 개선은 쉽다는 맥락의 이야기를 한 것으로 안다. 작은 개선을 생각하려고 하면 일단 주어진 패러다임 내에서 쥐어짜는 법을 생각하게 된다. 하지만 일견 터무니없어 보이는 개선을 생각하면 종종 기존의 패러다임을 벗어날 수 있다. 알고리즘적으로 말하자면 O(N)에서 O(log N)이 될 수도 있는 것이다. 와이프에게 수학 문제를 내어줬는데 끙끙 대며 고생을 했다. "그 문제 쉬워"라고 말해주니 그냥 순식간에 풀어버렸다. --김창준


코딩 할 때도 마찬가지.
나는 종종 경력이 오래 되지 않은 프로그래머들이
초반에 잡아놓은 잘못된 방향 때문에 사고의 폭이 좁아져 버리는 경우를 본 적이 있다.

사실 처음부터 다시 생각해보면 아무 것도 아닌 시스템이고 정말 간단하게 코딩할 수 있는 문제인데도 초반에 별로 깊게 생각해보지 않은 기반 구조(framework)위에서 코드를 확장해 나가려는 생각만 하다보니 코드는 점점 더 망가지고, 시스템은 조악(fragile)해진다.

내가 만들고자 하는 시스템의 기획적 요구사항은 그리 복잡하지 않은데 나는 혼자 코드의 수렁에 빠져서 허우적 거리고 있다던지, 그런 경우에 몇 차례 곤혹을 치르고 나서 '그런 확장은 불가능해요. 너무 복잡하거든요.' 라고 변명하고 있다면 일단 자리에서 일어나 차를 한 잔 마시고 좀 더 멀찍이서 자신의 코드를 살펴보자. 이 땐 한 손에는 찻잔을 또 다른 손에는 자신의 구현을 명세해둔 개괄적인 다이어그램 등의 문서를 쥐는 정도가 좋겠다.

자신만 혼자 삽질해서 일을 완성해 냈다고 해도 문제는 여전히 존재한다.
 - '완성' 했다고 하지만, 사실 진정한 '완성'이라고 할 수 있을까? 다시말해 그 부분은 더이상 추가 변경이 없을까?
 - 다른 프로그래머가 이 부분을 보기에도 충분히 파악이 용이(high readability)하며, 수정하기도 쉽게 되어있는가?
 - 당신은 아마도 모든 경우 (every case)에 대해 테스트 해보지 않았다. 그 코드는 버그가 없는가? 버그가 있다면 쉽게 파악/수정이 가능한가?

사실 이미 작성된 기반 위에서 조금씩 기능 확장을 해나가는 것이 당연한 작업 방식이지만, 대부분의 프로그래머들은 어디로 튈 지 모르는 기획적 요구사항을 모두 수용할 견고한 기반구조(framework)을 설계하려고 시간을 쓰지 않는다. 또한 사실 어떤 요구사항이 발생할지 파악이 불가능하기 때문에 애초에 불가능한 점도 있다.

나도 이보다는 매번 기능확장이 거론 될 때마다 시스템 전체를 다시한번 재평가 해보고, 점진적인 수정을 해 나가는 것이 더
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://window31.com/entry/%EA%B3%B5%EC%97%B0%EA%B3%BC-%EC%84%B8%EB%AF%B8%EB%82%98%EC%9D%98-%EA%B3%B5%ED%86%B5%EC%A0%90

밴드 공연을 할 때나 볼 때나, 한번씩 그런 때가 있습니다. 관객이 적으면 아무래도 무대 위에선
상대적으로 신이 좀 덜 나기 때문에 "아~ 왤케 반응이 없으세요~ 환호좀 해 주세요~" 라고 보컬이
찌질하게 읊어대는 경우죠. 아이러니 한 것은 무대 위에서 공연자들이 저런 "호소"를 하면 할수록
관객들은 더욱더 반응이 없다는 것입니다.

세미나나 강연자의 발표 때 역시 비슷한 상황이 있습니다. 강연자 중에서는 발표를 하면서 유독
사람들에게 질문아닌 질문을 해가며 (ex) 여기서 이 구조체는 뭐죠? 누구 말씀해보세요!" ) 청중의
반응을 무척이나 신경 쓰는 사람들이 있는데, 그 때 역시 듣는 사람이 별 반응이 없다면 위에서
얘기한 밴드처럼 "아? 대답이 아무도 없으시네" 하는 태도를 보인다는 겁니다. 비슷한 상황이죠?

저는 개인적으로 두 경우 모두 "너는 앞으로 공연을 하지마라" & "넌 앞으로 세미나 하지마라"
라고 말해주고 싶습니다. 공연을 보러 온 사람들이나 세미나를 들으러 온 사람들은 무대위의
사람을 위해서 이자리에 참석해 준 것이 아니고 현재 무대 위의 사람이 관객을 위해 선 것입니다.
즉 관객이 있기에 발표자가 있는거지, 관객을 발표자의 부속품 쯤으로 생각하는 것은
거대한 착각이라는 얘기입니다.

저는 이것이 공연과 세미나 공통점이라고 생각합니다. 즉 앞에 나선 자는 관객을 무시하면
안됩니다. 혹은 무시하는 듯한 질문이나 발언조차도 삼가해야 된다고 봅니다. 무대 위에서
기껏 보여준다는 모습이 "이건 뭐죠? 아 왜 반응이 없어요?" 등의 꼬라지는 정말 피해야 할
행동입니다. 관객은 그걸 몰라서 대답을 안하는게 아니고 발표자의 행태가 별볼일 없기
때문입니다. 또 이렇게 생각하는 분들도 상당수 됩니다. "아 ㅅㅂ 짜증나 그냥 계속
설명이나 하지 시간 때우려고 하는건가"


무대의 책임을 관객에게 넘기는 것은 발표자에게 있어 노상방뇨와 같은 수준의 실례라고
생각합니다. 다시한번 강조하지만 "그들"이 있기에 발표자가 있는거지, 발표자를 위해
관객들이 모여준게 아닙니다.


window31. 2008년 11월
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://wangmul.egloos.com/792588


요즘 재미있게 읽고 있는 책이 Game Coding Complete이다.
아직 초반부를 읽고 있어서 뭐라고 가타부타 확실하게 말하기는 어렵지만 꽤 재미있게 술술 읽어나갈 수 있다.

이 책의 초반부에 [모든 게임 프로그래머가 알아야 할 '멍청한 것들']이라는 장을 보다보니 꽤나 재미있는 구절들이 많다.

클레스 구조를 생각하는 한가지 흥미로운 방식은 클레스들과 그들의 관계를 가전제품과 전기코드로 비유하는 것이다. 멀티탭으로 연결된 코드를 최대한 줄이고, 서로 연결된 가전제품들 역시 최대한 줄이고, 뭐 하나를 켜려고 해도 일일이 따라가야 할 정도로 뒤엉킨 코드들을 풀어내는 것이다.

클레스를 설계하면서 항상 고민스러운 부분이 이런 것이다.
클레스를 어떤 기준으로 설계할 것인가.
클레스에 어떤 철학을 넣어줄 것인가에 대한 문제.


이것을 어떻게 하는지는 모든 프로그래머들 마다의 개성이 있다.
클레스의 설계와 구현을 어떻게 하는지에 따라서 코드를 읽어가는 것이 재미있기도 하고 지루하게 보이게도 한다.

B는 A를 포함하고 C는 B를 포함하고 D는 E를 포함하고 B에서는 B', B'', B'''메소드가 있으며 A에는 AB, AC, AD메소드가 있는데.... 라는 식의 클레스는 따라가는 것 자체가 짜증나게 한다.

한 세단계정도 따라들어가면 내가 어디 들어왔는지조차 잊어버린다. 전기코드를 따라가다가 잠시 집중력을 잊어버리면 내가 따라가고 있던 선을 잃어버리는 것과 비슷하다.

코드를 단순하고 간결하게 구현하는 것.
프로그래밍을 배운지 3~4개월된 개발자가 봐도 쉽게 이해될 수 있도록 코드를 만드는 것. 아니, 2,3년이 지난 뒤에 내가 짠 코드를 오랜만에 봤는데도 모든 라인들이 이해되도록 코드를 만드는 것.

지금의 내게 가장 중요한 클레스 설계의 원칙은 바로 이것이다.
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://wangmul.egloos.com/1497504

PMP를 구입한 이후 너무 책 읽는 것에 소홀해져 나름대로 다시 한번 예전의 감각을 찾아보기 위해서 시간 날때마다 읽으려고 구입한 '패턴을 활용한 리펙터링'을 구입했다.

몇년째 관심을 가지고 있지만 과연 이것이 유용한 것인지 대답을 찾지 못했던 패턴이라는 주제와 언제나 실력의 벽에 부딛히도록 만드는 리펙터링이라는 주제를 함께 다룬 책이기에 제목만으로도 구입할 수 밖에 없도록 만들었다.

이 책의 45페이지에 보면 Martin Fowler가 한 말을 인용한 구문이 나온다.

컴퓨터가 이해하는 코드는 어느 바보나 다 짤 수 있다. 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

이걸 읽는 순간 "두둥!"하고 머릿속에서 울리는 느낌이 들었다.
코드를 보면서 문맥을 놓치게 만들거나 "왜?"라는 의문이 들게하는 코드가 생기게 하는 것은 보는 사람의 실력이 떨어져서가 아니라 만든 사람의 실력이 부족하기 때문이다.

어떤 프로그래머가 보든지 한눈에 쭉 읽어가며 "대단해~"이라는 찬사를 보낼 수 있도록 만드는 코드를 만드는 것이 진정한 실력.

난 아직도 너무나 부족하다.
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

실용주의 프로그래머의 22. 죽은 프로그램은 거짓말을 하지 않는다.편 중에서

그렇지만 기본 원칙은 똑같다. 방금 불가능한 뭔가가 발생했다는 것을 코드가 발견한다면, 프로그램은 더 이상 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료해야 할 일이다.
일반적으로, 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.

이란 구절이 나온다.

이 구절은 서버 프로그래머로써 생각해왔던 많은 것들을 고민스럽게 만든다.

우리는 서버 프로그램이란 관리자가 종료를 하려고 시도했을 때 조차도 의심해보고 종료해야 할 만큼 절대 죽어서는 안된다고 생각하고 있다. 오류가 발생했을 때에는 그 오류를 무시하고 다른 동작은 계속 시도되어야 한다는 것이 게임 서버 프로그래머가 가져야 할 기본적인 베이스라고 여겨왔다.

그런데 이것이 아니라는 말일까?
에러가 발생하였다면 종료되는 것이 맞는 것일까?
(한가지 미리 정의하고 갈 것은 종료된다는 것은 현재 접속되어 있는 모든 유저들의 데이터를 보관/저장 한 후에 죽는 것을 의미한다.)

이것은 두가지의 정 반대의 상황을 만들어낸다.

1. 서버가 종료되지 않고 계속 동작할 경우
- 서버가 죽지 않기 때문에 유저는 계속 게임을 플레이 할 수 있다
- 발생한 오류로 인해서 서버가 어떤 식으로 동작할 지 예측하기 어려워진다.
- 게임의 밸런스가 의도하지 않은 문제로 무너질 수 있다.

2. 오류가 발생했을 경우 서버가 자동 종료될 경우
- 오류로 인하여 예상하지 못한 동작을 하지 않는다.
- 그 서버에 접속되어 있던 유저들이 강제 게임 종료 상태가 되어버린다.
- 유저의 불만은 증가하고 게임에 대한 신뢰도가 떨어지게 된다.

무엇이 더 옳은 선택일까?
오류 메시지를 산더미처럼 뿜어내면서도 결코 죽지 않고 서비스를 계속 이어가는 서버.
오류 메시지가 발생한 순간 해당 오류를 기록하고 종료되는 서버.

어려운 선택의 문제이다.

출처 : http://wangmul.egloos.com/1119215
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://wiki.kldp.org/wiki.php/HowToBeAProgrammer
TAG kldp
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요