괴짜 프로그래머의 일상사~@@
프로그래밍, 컴퓨터, 그리고 일상에 관한 소소한 이야기들...
Blog | Guestbook
Keyword | Local | Tag
T 112 / Y 700 / Total 3405170
Catergories
Calendar
«   2008/06   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Tag
반야, 체스, 우아한세계, 그 참을 수 없는 가벼움, 배열, 진실, MSDN, 거스 히딩크, 태그, 스팸, 스페이스 니들, 블로그, 식별 기호, 극장판, 베토벤 바이러스, 스파, 그레이스케일, 김택용, 외국인, 시애틀,
Archive
Link
Search
  submit
Recent Articles
Recent Comments
Recent Trackbacks
해당되는 게시물 4건
2008/06/19 14:25
Head First Debugging

신입 개발자를 위한 조언
Head First Debugging
신영진 codewiz@gmail.com 

소프트웨어 출시를 지연시키는 가장 큰 원인 중의 하나는 버그다. 그 중에도 몇몇 복잡한 버그들은 개발자들을 지독하게 괴롭힌다. 심지어는 그런 버그 때문에 개발된 제품이 폐기되기도 한다. 또한 회사는 출시 지연이 심각한 단계에 놓이면 유능한 버그 사냥꾼을 따로 고용하기도 한다. 그런 복잡한 버그에 대항하는 초보 버그 파이터들이 저지르는 실수에 대해서 살펴보고 그런 버그들을 효과적으로 디버깅하는 방법에 대해서 알아보도록 하자.

대부분의 초보 버그 파이터들이 자주 범하는 실수는 버그가 발생한 지점에 집착하는 것이다. 그들은 끊임없이 ‘도대체 버그가 어디서 발생했을까?’란 질문을 던진다. 그와 동시에 그곳을 찾기 위해서 다양한 방법을 동원한다. 가장 애용하는 방법 중에 하나는 분할 정복법이다. 마치 바이너리 서치를 하는 것처럼 그들은 프로그램을 두 조각으로 나누고 어느 부분에서 버그가 발생하는지를 찾아나간다. 물론 좀 똑똑한 버그 파이터들은 크래시 덤프나 맵 파일등을 활용하기도 한다.

어쨌든 재현할 수 있는 버그라면 그들은 버그가 발생하는 바로 그 지점을 찾아내는데 성공한다. 하지만 문제는 지금부터 시작이다. 초보 버그 파이터가 찾아낸 바로 그곳은 십중팔구 다음과 갈은 어처구니 없는 라인일 것이기 때문이다.

*dst = *src;

물론 위와 같은 라인은 똑똑한 개발자에게는 몇 가지 암시를 던져주기는 한다. src가 읽을 수 없는 메모리 영역을 가리키고 있다거나, dst가 기록할 수 없는 메모리를 가리키고 있다면 이 코드는 분명히 실패한다는 것이다. 물론 그들은 저런 가정을 디버거의 추적 기능을 활용해서 확인할 수 있다. 그런 가정이 들어맞았다고 하더라도 그들은 속수무책이다. 왜냐하면 왜 그렇게 됐는지는 모르기 때문이다. SEH와 같은 방법들을 동원하더라도 그들은 예외 부분에 무엇을 넣어야 할지를 모른다. 만약 빈 예외처리 문장을 넣는다면 그건 단지 폭탄이 터지는 시점을 연장시킬 뿐이다. 그 폭탄은 언젠가 다른 곳에서 다른 형태로 다시 터질 것이기 때문이다.

때로는 정말 어처구니 없는 OutputDebugString(“some debug msg.”) 같은 부분이 문제가 되기도 한다. 그들은 이렇게 말한다. 이 디버그 메시지를 넣으면 잘 동작하는데 이걸 빼면 잘 동작하지를 않아요. 그러면서 원인도 모른 체 이 디버그 메시지를 릴리즈될 제품에 포함시킨다.

초보 버그 파이터들이 저지르는 이러한 실수는 버그에 대한 잘못된 이해에서 비롯된다. 복잡한 프로그램에 숨어있는 잡기 힘든 버그는 대부분 두 가지 특성을 가지고 있다. 첫째는 문제의 원인이 한 곳에 있지 않다는 것이고, 둘째는 버그를 관찰하는 행동 자체가 피드백이 되어서 버그에 영향을 미친다는 것이다. 이런 기준에서 보면 그들이 그토록 집착했던 버그가 발생한 지점은 중요하지 않은 요소에 불과하다는 것을 알 수 있다. 그 곳은 단지 폭탄이 터진 장소일 뿐, 실제로 폭탄은 다른 곳에서 다른 원인에 의해서 만들어졌기 때문이다. 중요한 것은 바로 그 폭탄이 생겨난 원인이고, 완전한 디버깅은 그런 원인 요소를 제거하는 것이기 때문이다.

프로그램은 데이터에 가공을 하는 절차들의 집합이다. 이렇게 가공을 하는 개별 절차들은 일정한 흐름을 만들어낸다. 순차적이기도 하고 중첩되기도 하고, 다른 절차를 기다리기도 하는 식으로 말이다. 대부분의 복잡한 버그는 이러한 흐름이 미묘하게 변경될 때 발생한다. 따라서 그런 복잡한 버그를 효과적으로 디버깅 하기 위해서는 프로그램의 흐름에 집중하는 것이 바람직하다. 흐름에 집중한다는 것은 머릿속으로 그런 과정을 재현해 보는 것을 의미한다. 정상적인 흐름을 다르게 만들어서 재생시켜 보면 아마도 버그의 증상과 일치하는 결과를 가져오는 흐름이 있을 것이다. 그 다음은 그 틀어진 흐름이 틀어지지 않도록 바로 잡아주면 된다. 이 과정이 숙달되면 마치 일류 정비공이 엔진 소리를 듣고 문제를 판단하는 것처럼 증상만 보고도 그 원인을 알 수 있게 될 것이다.


2008/06/16 15:54
뛰어난 엔지니어가 되기 위한 요건은 무엇인가?

슈테판 클라인 아저씨의 다른 책들을 사면서 같이 지른 책인데 아직 다 읽지는 않았습니다. (부담스러울 정도로 두껍습니다.) 스티브 워즈니악 부분만 살짝 읽어봤는데 내용이 맘에 드네요. 내용중에 엔지니어라면 귀감이 될 만한 부분이 있어서 옮겨봅니다.
고등학교 때부터 집에서 재미로 여러 종류의 컴퓨터를 설계했나?

그렇다. 그러나 사실은 하나도 만들지 못했다. 하나를 설계하고 또 다시 설계하고 그런 식으로 설계만 계속 반복했다. 새로운 칩들이 계속 나왔기 때문이다. 전에 설계한 컴퓨터에 새 칩을 써서 다시 설계하곤 했다. 좋은 생각이 떠올라 두 개의 칩을 절약할 수 있었기 때문이다. 돈이 없어서 그렇게 했지만 결국 한 대도 만들 수 없었다. 얘기 했듯이 당시 칩은 아주 비쌌기 때문에 컴퓨터를 만들 수는 없었고 그저 종이에다 설계하고 개선하고 다시 개선하는 일만 반복했다. 이런 과정을 통해 훌륭한 엔지니어로 성장할 수 있었다. 아무것도 만들지는 못했지만 다른 사람들이 생각해 내지 못하는 아이디어를 끌어내려고 나 자신과 끊임없이 경쟁했다.

사실 그때 어느 누구도 사용하지 않은 여러 가지 컴퓨터 개발방법을 가지고 있었다. 학교에서도 가르쳐주지 않는 방법들이었다. 많은 것들을 내 머리로 해냈고 스스로 터득했다. 그때 학교에 컴퓨터도 없었지만 컴퓨터를 설계했다. 우연히 학술잡지를 통해 컴퓨터 사용법에 관한 문서를 구하는 방법을 알게 되었고 아버지가 칩 설명서를 구해주었다. 그 설명서를 보면서 칩을 이용해 어떻게 컴퓨터를 만드는지 알아냈다.

뛰어난 엔지니어가 되기 위한 요건은 무엇인가?
아주 부지런해야 한다. 모든 것을 세심하게 챙겨야 하고 무엇을 빼먹었는지 주의 깊게 확인해야 한다. 보통 때보다 더 열심히 더 깊이 생각해야 한다. 하지만 요즘 같이 거대한 프로그램에서는 그렇게 하기 힘든 게 사실이다.

나는 어느 부분에서는 하드웨어, 어느 부분에서는 소프트웨어 엔지니어였다. 수많은 소프트웨어를 툴 없이 손으로 직접 개발했고 그 모든 것이 애플II로 들어갔다. (지금도 그때 손으로 쓴 코드를 가지고 있다.) 애플 II에 사용된 프로그램 중에는 다양한 산술프로그램, 그래픽프로그램, 컴퓨터 언어, 다른 기계의 에뮬레이터, 코드를 에뮬레이터로 집어넣었다 뺐다 하는 기능 등이 있었다. 이 모든 것들이 있었음에도 불구하고 결함은 전혀 없었다. 하드웨어는 물론이고 소프트웨어에서도 말이다. 요즘은 이런 제품을 찾아볼 수 없다. 나는 무엇인가를 만들 때 나의 일부분으로 생각하고 온 열정을 쏟았다. 그 컴퓨터가 바로 나 자신이었고 모든 것이 완벽해야 했다. 하지만 내 코드를 컴파일할 수 있는 컴파일러가 없었기 때문에 어려움도 겪었다.

결국은 장인정신에 대한 이야기 같죠? 사실 요즘 사람들 사이에서 회자되는 "뽑기"라는 말만 보더라도 제품에 장인정신이 얼마나 결여되어 있는지 알 수 있습니다. 수백만원이 넘는 노트북도 뽑기를 잘못하면 애물단지가 되는것처럼 말이죠. 당당하게 자신의 제품에 결함이 없다고 말할 수 있는 그런 엔지니어가 되어야겠죠. 쉬운 일이 아니기에 더욱 도전해볼 가치가 있는지도 모르겠습니다. 어쨌든 스티브 워즈니악 아저씨는 멋진 분입니당. 이 부분을 읽고 나니 "I WOZ"란 책을 더 읽어 보고 싶다는 생각이 들더군요.

2008/06/13 16:11
시간의 놀라운 발견

아침 출근길을 살펴보면(사실 아침에 잘 출근안하지만 ㅋㅋ) 걷는 사람들이 정말 없습니다. 죄다 뛰고 있죠. 제가 부산에서 살다가 처음 서울와서 살면서 가장 놀란 것은 사람이 무진장 많다는 것이고, 그 다음 놀란 것은 사람들이 무지 바쁘게 뛰어 다닌다는 사실이었습니다. 적어도 지금까지 제가 느끼기에 서울은 부산보다 빠른 세상입니다. 길가는 아무 사람이나 붙잡아 놓고 물어본다면 아마 십중 팔구는 시간이 없어어 뛴다고 말할겁니다. 그들은 똑똑하고 교육을 많이 받고 시간 관념이 철저하지만 늘 시간이 부족합니다. 하지만 왜 그런지는 모르죠. 그들은 시간에 대한 관심이 많습니다. 그래서 늘 시간관리 서적을 끼고 살죠. 하지만 늘 그들은 시간이 부족합니다. 이런 그들에게 권해주고 싶은 책이 바로 이 책 "시간의 놀라운 발견"입니다.

제가 적어도 이 책이 상콤하다고 느낀 단 하나의 이유는 내용이 진부하지 않았기 때문입니다. 제가 읽은 수많은 시간 관리 책의 내용을 딱 요약하면 다음과 같습니다.

할일을 순서대로 목록에 적는다.
그것들을 세분화한다.
개별 작업의 중요도를 표기한다.
개별 작업에 걸리는 시간을 추정한다.
그것을 소팅한다.
위에서부터 하나씩 처리한다.


그 많은 책들이 단지 저런 진부한 이야기를 하기 위해서 수 백 페이지를 낭비하는 것을 보면 정말 진짜 현기증이 날 지경이죠. 그런데 더 심각한 상황은 지금도 서점에는 저런 내용을 강조하는 책이 매일 수 십권씩 쏟아져 나온다는 사실입니다. 하여튼 요지는 이 책은 다르다는 겁니다. 적어도 저런 진부한 이야기를 하지는 않습니다. 또한 과학적입니다. 철저하게 과학적인 사실에 입각해서 내용을 적고 있습니다.

이 책은 누구나 한 번 쯤은 가져보았을 범직한 왜 즐거운 시간은 빨리 지나가는지, 왜 회의 시간은 길게 느껴지는지, 왜 나이가 들수록 시간이 빨리 가는 것처럼 느껴지는지에 대해서 과학적인 입장에서 설명을 하고 있습니다. 그런 것들이 궁금했던 분이라면 더더욱 읽어보면 좋겠죠.

재미있는 내용은 책의 148쪽을 보면 텔레비전 패러독스라는 부분이 나옵니다. 텔레비전을 보면 시간이 빨리 가는 이유가 텔레비전의 변화하는 화면은 우리를 그곳에 끊임없이 집중시키기 때문이라고 나옵니다. 반면에 그것을 보는 동안 우리에게는 아무런 기억도 남지 않기 때문에 기억이 없는 지대를 만든다고 합니다. 한마디로 텔레비전이 해롭다는 내용이죠. 이 부분을 읽으면서 저는 텔레비전을 별로 보지 않고 컴퓨터 게임을 많이 하니 다행이라고 생각했습니다. 컴퓨터 게임또한 끊임없이 집중시키지만 적어도 자신이 무엇을 해야하는지에 대한 판단은 끊임없이 개입되기 때문이죠. 그러면서 안심하고 있는데... 바로 다음 문단의 내용이 저를 두 번 죽이더군요.
독일의 사회학자 하르트무트 로자가 '텔레비전 패러독스'라고 명명했던 시간의 축소 현상은 컴퓨터 게임을 즐길 때 더 분명하게 다가온다. 컴퓨터 게임은 집중력을 완전히 사로잡는다. 컴퓨터 게임을 하다 보면 얼마나 시간이 빨리 지나가는지, 배에서 꼬르륵 소리가 나거나 엄마가 그만하라고 소리를 질러야 시간이 많이 흐른 것을 깨닫고 그만두게 된다. 그런데 컴퓨터 게임을 중지한 후에는 몇몇 장면을 제외하고는 아무 것도 기억이 나지 않는다. 블랙홀이 삶의 일부분을 집어삼켜버린 것처럼 말이다.
책의 내용은 두 가지 분명한 사실을 제시합니다. 집중을 하는 동안의 시간은 빨리 가는 것처럼 느낀다. 우리의 주의가 시간에 있지 않기 때문이죠. 새로운 경험의 개수는 우리가 느끼는 시간의 길이와 비례한다. 어린 시절은 새롭게 경험하는 것이 많기 때문에 길게 느껴지는 것이죠. 이런 맥락에서 현재에 집중하고, 새로운 경험을 많이 하는 것은 보다 삶을 풍요롭게 할 수 있는 방법이라는 것을 알 수 있습니다.

현재에 집중한다는 것은 매일 똑같은 일상 속에서도 다른 부분들을 관찰하는 것을 말합니다. 예를 들면 매일 똑같은 지하철 출근길이라 하더라도 그 곳에 타는 사람들은 매일 틀립니다. 오늘 지하철에 나의 천생연분을 만날지도 모른다는 생각으로 지하철을 타라는 것이죠. 그 곳에 있는 사람들, 그 상황에 집중하면 보다 많은 것들을 경험할 수 있을 겁니다. 잠자리에 누울때 오늘 하루 머했지 하고 생각해보면 적어도 지하철에 서있던 상콤한 아가씨의 얼굴은 떠오르겠죠. 이게 아닌뎅 ㅠㅠ

저자의 다른 책인 "행복의 공식"과 "우연의 법칙"도 상당히 기대가 되는군요.


거의 이외수님 플레이톡 내용이더군요. 새로운 내용도 별로 없고 참신한 것도 별로 없어서 쵸큼 써운했습니다. 거진 대부분을 플톡에서 이미 읽는 내용이라 ㅠㅠ. 그럼에도 비싼 책값때문에 열심히 읽었습니다. 아래 이야기가 역시나 가장 기억에 많이 남는다는 흐흐~~
대 학생 커플이 티브이에 출연해서 스피드 퀴즈를 풀고 있었다. 여자가 들고 있는 낱말카드에는 카페라는 글자가 인쇄되어 있었다. 남자가 다급한 목소리로 힌트를 던졌다. 자기하고 나하고 자주 드나들던 장소. 여자가 재빨리, 그리고 확신에 찬 목소리로 대답했다. 모텔!

http://playtalk.net/oisoo/microblog/2007-09-11/043304/


예전부터 디게 읽고 싶었던 책인데 절판되서 못 읽고 있었다죠. 그런데 재 출간됐나 봅니다. 잽싸게 사서 읽어 보았습니다. 역시 이외수님 책 답게 구구절절한 설명보다는 간략한 한 마디 한 마디가 인상깊더군요. 사소한 부분인데 명사와 서술어를 아무렇게나 결합하는 내용을 설명한 부분이 꽤나 인사깊더군요. 아래와 같은 부분입니다.
먹구름이 떠내려간다.
책이 떠내려간다.
먹구름이 녹는다.
돼지가 녹는다.
휴대폰이 도망친다.
고독이 흐느낀다.
절망이질펀하다.


이번달 마소 책 코너를 보다가 재밌을거 같아서 지른 책 입니다. 가격이 꽤나 비싸길래 두꺼운 줄 알았더니 출퇴근 시간에 정독하면 다 읽을 정도의 분량이더군요. 개인적으로 책 소개 코너를 별로 믿지 않는 편이지만 이번에는 특히나 톡톡히 실망을 많이 했습니다. 책 제목이 정말 거의 낚시 수준이 아닌가 하는 의문이 들었습니다. 저는 빌로퍼가 쓴 자서전격 책이거나 아니면 "둠(존 카맥)"이나 "아이콘(스티브 잡스)" 정도를 생각했었는데 이 책은 이도저도 아니었습니다. 빌로퍼 이야기가 없는 건 아니지만 거의 소소한 내용들이 전부입니다.

책 내용에서 특히나 실망한 부분은 저자가 끈임없이 방황한다는 것 입니다. 책 주제가 빌로퍼라면 빌로퍼에 집중을 해야 할텐데 계속 이야기를 하다가 삼천포로 빠지는 식입니다. ㅋㅋ 소제목이 "모험심이 강한 소년 빌로퍼"인 부분을 살펴볼까요. 시작은 빌로퍼가 어린시절 다양한 분야에 관심이 있었다는 것으로 시작됩니다. 그러다가 그가 특히 백거맨 게임을 좋아했다는 내용이 나옵니다. 이제부터 삼천포로 가기 시작합니다. 빌로퍼가 백거맨을 좋아한 이유는 부모님의 권유에서였고, 여기서 부모님이 얼마나 중요한지를 새삼 느낀다는 내용이 나옵니다. 그리고는 온갖 IT 인물들의 부모들에 대한 거론이 나옵니다. 블리자드, 빌게이츠, 래리 페이지, 스티브 잡스, ...그러다 끝은 게임 개발에는 창의성이 중요하기 때문에 게임 개발자중에는 좋은 집안보다는 평범한 집안 출신이 많다는 결론을 내립니다. 그 대표적 예로 존 카맥을 들죠. 빌로퍼 이야기 한 장, 나머지 이상한 이야기 두장반 입니다. 전체적으로 다들 이런 식입니다. 빌로퍼 만큼이나 빌게이츠, 래리 페이지, 스티브 잡스도 많이 나옵니다.

왠만하면 솔직히 별로 권하고 싶지 않군요. 낚였다는 느낌이 많이 들었습니다. 게임 인물 열전, IT 인물 열전, 내지는 게임 업계 이야기가 더 어울리지 않을까하는 생각을 해봤습니다. 게임 개발에 관한 정말 잡다한 이야기는 많이 나옵니다. 손노리 초창기 멤버중 몇 명이 폐렴으로 군대를 면제 받았는지까지 나오더군요. 헐헐~~

 Prev   1   Next 
codewiz’s Blog is powered by Tattertools.com / Designed by faido