Practice 였다. 내가 정말 하고 싶은 것은 연습을 통한 나 자신의 성장이었나 보다. 회사에서 하는 프로젝트만이 수련의 기회가 되다 보니, 그것을 떠나서는 스스로 연습할 줄 모르는 사람이 되어 있었던 것이다. 최근 스트레스도 여기서 많이 비롯된 것 같은데, 프로젝트와 프로젝트 사이의 농한기 같은 요즘에는 스스로 성장의 기회를 만들지 못하다 보니, 나 자신에게도 실망하고 다른 사람으로부터의 평가에도 실망하는 계기가 된 것 같다.
Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes
라는 문장이 와닿는다. 여러 다양한 시도를 찾아 헤매던 내 마음 속에는 실패하며 배울 수 있는 환경을 찾고자 하는 바램이 있었던 것 같다.
위의 책에서 나온 Actions 으로는 프로그래밍 고전들 몇 권을 보고 연습을 시작하는 걸 권하고 있다. 그런 후 그 결과 물들이 어떻게 나아져 가는지 보라고 한다. 마침 아주 예전에 사놓고 읽지도 않았던 Proramming Pearls 가 있는데, 이 참에 계획 세워서 한번 읽고 문제 풀이등을 정리해 봄직하다.
오피스 2010 에는 문서를 Skydrive 에 저장하거나, 원노트의 경우에는 Skydrive 에 공유 원노트를 올려놓고 쓸 수 있는 기능이 있다. 다만 Windows Live 가 업데이트 되어야 쓸 수 있었던 기능인데, 이번에 나온 베타 버전을 설치하면 그것들을 쓸 수 있다. 윈도우즈 라이브 필수 패키지 베타는 여기에서 다운로드 받아 설치하면 된다.
Office 2010 과 윈도우즈 라이브 필수 패키지 를 설치했으면, 시작-모든 프로그램-Windows Live-Windows Live Sync Beta 를 실행한다.
왼쪽 두번째에 보이는 Microsoft Office 를 클릭해서 Syncing turned on 으로 바꾸면 된다. 그 후 원노트를 실행하면, Web 에 싱크된 노트북을 사용하겠냐고 묻는다.
원노트 뿐만 아니라, 워드나 엑셀등에서도 문서를 바로 Skydrive 에 저장하는 기능이 활성화 된다.
어떤 버그에 대한 픽스를 두 명이서 동시에 썼다고 하자. A 의 것은 약 50 줄 정도를 수정했다. 반면 B 의 것은 약 200 줄 정도를 수정했다. LOC (Line Of Change)에 근거해서 볼 때, 누구의 픽스가 더 좋은 픽스일까?
생각
질문을 정제하기 위해 몇가지 기준들을 정해보자. 더 좋은 픽스란 무엇일까? 픽스에 포함되 bug 가 더 적은 것이 좋은 픽스라고 할 수 있겠다. 그럼 위 질문은 다시 말해
누구의 픽스가 더 적은 Defects(=bug) 를 가지고 있을까?
이걸 판단하려면, LOC 사이즈와 Change 안에 있는 defect 의 수에는 상관 관계가 있을까? 라는 질문을 먼저 해야 될 것 같다. 여기에 대해서는 예전에 읽은 Best Kept Secrest of Peer code review에서 그 영향력이 매우 적거나 증명된 바가 없다고 했다.
잠깐, 너무 빨리 답으로 뛰어들었다. 질문을 좀 더 정제해보자. LOC 를 어떻게 측정할 것인가? 단순한 Diff 의 크기로 비교할 것인가? 아니면 그 복잡도의 weight 를 고려한 값으로 계산할 것인가? 아니면 기계어로 바꾸어 놓고 그 차이를 비교해 볼 것인가? (LOC 를 셈하는 근원은 Assembly language 로 프로그래밍하던 시대에 기원하긴 한다.)
글쎄다. 이건 모르겠다. LOC 를 규정하는 방법은 너무 다양할 것 같다. 그럼 동일한 조건 하에서 비교한 실험등은 없을까? LOC metrics 로 인한 영향력을 없애려면, 동일한 프로젝트에서 측정된 연구 결과가 있으면 딱 좋을 것 같은데…
아 모르겠다. 논문을 쓸 것도 아니고 그냥 웹 검색을 하자. (라기 보다 논문을 써본적도 없고, 어떻게 쓰는 건지도 모른다.) 잽싸게 검색을 해보니 어쨋든 아주 재밌는 연구 결과가 하나 있다. 아니 있었나 보다.
…. Recent studies show a curvilinear relationship between defect rate and executable LOC. Defect density, or defects per KLOC, appears to decrease with program size and then increase again as program modules become very large (see Figure 3.1). Curiously, this result suggests that there may be an optimum program size leading to a lowest defect rate—depending, of course, on programming language, project size, product type, and computing environment …
그러니까, Defect density 가 최소가 되는 최적의 LOC 값이 존재한다는 이야기다. 물론 이 말을 곧이 곧대로 믿기에는 한계가 있다. 왜냐하면 LOC 와 # Defects 의 영향력을 무의미한 것으로 만들어버릴 정도로 이 결과는 외부 요소에 의해 크게 좌지우지 되기 때문이다. 어쨋거나 여기서 얻을 수 있는 것은 LOC 와 Defects Density 사이에는 선형적인 상관관계가 없다 정도 되겠다.
원점으로 돌아와서 다시 생각해보자. 방금 봤던 내용들은 머릿속 한 켠에 정리해두고 잊어버리자. 최초의 질문으로 돌아가서, 만약 A 와 B 의 픽스 둘 다 훌륭히 버그를 고쳤다면 우리는 둘 중 누구 것을 골라야 될까?
Occam’s razor 원칙에 따르자면, 일반적으로 더 단순한 것이 정답일 경우가 많단다. 그럼 다시 이렇게 물어보자. A 의 50 줄 짜리 fix 가 더 단순한 것일까? B 의 200 줄짜리 fix 가 더 단순한 것일까?
이렇게 질문을 바꾸고 나니, 내가 왜 이렇게 혼란스러워 했는지 알 것 같다. LOC 만으로는 Fix 의 단순함 또는 복잡함 정도를 나타낼 수 없기 때문이다. 만약 LOC 가 작은 픽스가 더 단순하다 라는 명제를 지지하려면, 다음과 같은 가설이 있어야 한다.
Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE
역시 검색으로 나왔던 블로그인데, 참으로 내가 하고 싶은 말을 그대로 해주었다. code size 를 줄여서 얻고자 하는 이득이 # of defects 를 줄이고자 하는 것이라면, (즉 정답에 가까운 답으로 만들고자 하는 것이라면) 그 과정이 code 의 readability 를 높이는 방향이어야 된다는 이야기다.
결론
애시당초 코드를 고치지 않는다면, 버그가 더 생길 가능성도 없다. (줄지도 않겠지만) 그럼에도 우리는 버그를 고쳐야 하는 운명이다.
LOC 와 Defect density 는 선형적 상관관계가 아니다.
LOC 보다 # of defects 에 영향을 주는 것은 Readability 이다.
Readibility 가 좋은 코드가 # of defects 도 적은 코드일 가능성이 높다.
LOC 를 줄여서 Fix 의 Quality 를 높이고자 한다면, 그 과정이 Readability 를 높이는 방향이어야 한다.
왜 혼자서 질문던지고 답변하는 놀이를 하고 있느냐? 라는 질문을 할 만한데, 그것은 최근에 겪은 일 때문이다. 회사 업무와 관련이 있어서 블로그에 자세히 쓰지는 못할 것 같은데, 공개해도 괜찮은 내용들로 가다듬어서 글 한 자락 더 써보려고 한다. 언제가 될지는 모르겠지만.
책을 구입한지는 꽤 오래 전이었지만, 책상 구석에 놔뒀다 얼마 전부터 읽기 시작해서 이제 다 봤다. 처음 기대했던 내용은 생활 속에서 도움이 될만한 법 상식들이었으나, 책 내용은 그것과는 다른 몹시 철학적인 주제로 시작한다.
기계적인 법치주의와 영화 로보캅
도둑의 아들은 아버지를 신고해야 옳은가?
살인을 통해 ‘살인하지 말라’는 계명을 전하는 모순
정의란 ‘강자의 이익’?
권력의 법, 민중의 법
노예 해방법 과 지도자 링컨에 관한 오해
계급간의 이익추구가 낳은 삼권분립
마르크스와 부르주아 법
악법도 법?
등 법에 대한 다양한 철학적 주제를 가지고 재밌게 얘기를 풀어간다. 특히 소크라테스 이야기는 정말 흥미로웠는데, 소크라테스가 왜 70 살이 나 되어서 사형을 선고 받고 독을 마셔야만 했는지에 대해 당시의 정치적 상황과 함께 알려준다.
이상과 현실 사이에서 법이 가질 수 밖에 없는 한계. 그 가운데서 최선의 것을 찾기 위해서는 끊임없는 법적 투쟁이 있었다는 이야기도 인상 깊다.
늘 컴퓨터관련 책들만 보다가 오랜만에 신선한 글을 읽었더니, 그 개운함이 머릿속에 남아 있다. 예전에 과학철학 수업을 들을 때 이런 느낌을 받았었는데, 그 이후 철학관련 서적들을 몇 권 사서 혼자 읽어보려다 낭패를 봤던 것 같다. 아무튼 법에 대한 시야를 넓혀주는 책이다. 추천.
종교가 제시해주는 것이 문제를 바라보는 방법이라고 한다면, 그 중에서도 불교는 ‘나’의 관점에 집중하는 방법을 가르쳐준다.
어떤 이들에게 불교의 방법은 너무 허망하다는 느낌을 주기도 한다. 그것은 불교가 지극히 개인적인 해법들을 내놓기 때문인데, 예를 들어 눈 앞에 활활 타고 있는 불을 끄고자 한다면 어떻게 해야 할 것인가? 라는 물음에, ‘눈을 감으면 된다’ 라는 대답이 나오기 때문이다. 이런 것들이 불교가 마치 현실의 문제를 외면하기 때문이라고 생각될 수 있다.
그러나, 불교의 목적이 중생의 구제. 즉 삶의 고통을 줄이는 방법에 집중하는 것이라고 생각한다면, ‘눈을 감아라’ 와 같은 대답을 이해할 수 있게 된다. 사실 그대로의 ‘문제’ 와 그것을 바라보는 이의 ‘고통’을 분리해냄으로서 우리는 보다 나은 해법을 찾을 발판을 만들 수 있게 되기 때문이다.
무엇이 우리를 고통스럽게 하는가? 고통의 끝에 해법이 존재하는가? 붓다가 고행 끝에 얻은 깨달음은 아니올시다 였다. 고통 속에 몸부림 친다고 해서 현실의 문제가 바뀌지는 않더라는 것이다. 그래서 고통은 고통 대로 해결하고, 현실의 문제는 문제 대로 해결해야 된다.
거기에 대해서 많은 이야기들을 할 수 있겠지만, 내가 그만한 깊이는 되지 못하고, 다만 한마디 할 수 있다면, 본질적으로 고통은 개인의 문제이기 때문에, 그 해법도 개인적일 수 밖에 없다라는 것이다. 나의 고통을 남이 잠재워 주지는 못한다는 말이기도 하다.
법륜 스님의 ‘행복한 출근길’ 은 삶의 고통을 호소하는 많은 사람들에게 가르침을 주는 내용이고, 법정스님의 ‘무소유’는 수행자로서의 삶은 어떠한지 엿볼 수 있게 해주는 책이다. 둘 모두 우리가 마주치는 고통에 어떻게 대처하는 것이 바른지 알려준다. 실천은 역시 우리의 몫이다.
지난 주 글에서 스트레스 받는 순간을 기록해보기로 하고 일주일 동안 실천을 해봤다. 하다보니 그냥 글로 적는 것만으로도 큰 도움이 되었는데, 아마도 불가에서 가르치는 수행법과 어느 정도 닮은 면이 없잖아 있었다.
그래서 참으려고 노력하지 말고, 화가 일어남을 알아차리고 그 알아차림을 지속하면서 저절로 사그라질 때까지 지켜보라고 하는 것입니다. 그 화의 존재를 매우 뚜렷이 바라본다는 뜻에서 이를 ‘관법(觀法)’이라고 하지요. 원어로는 ‘위빠사나’라고 부릅니다. –행복한 출근길, 법륜-
그 순간순간의 목록들을 써봤는데, 다음과 같다.
지난 몇 달 동안 쓸데 없는 일을 하느라 시간 낭비했다고 느껴진다.
마지막 체크인 날짜가 2009년 11월 26일이다. 지난 반 년간 나는 뭘 한 걸까?
나에게 오는 일들이 보잘 것 없이 느껴짐. 심지어 신입사원에 비해서도
현 조직으로 벤쳐회사를 만든다면 우리는 살아남을 수 있을 것인가?
지금 회사의 장점은? 단점은?
역시나 일에 대한 불만족이 가장 컸다. 그나마 지난 주에 버그 하나가 할당되어 작업을 시작하다 보니 좀 기분이 나아지긴 했다. 사실 이것은 달리 말하자면, 매니징에 대한 불만이기도 하다. 제품하나를 내고 난 뒤 몇 달간의 농한기가 오는 것은 뻔한 사실이었는데, 적절한 대비책을 세우지 못한 것이 잘못으로 보인다. 하지만 이 부분에는 내가 먼저 변화를 시도할 여지도 있었는데 그러지 못한 데 대한 아쉬움도 크다.
두번째는 사람에 대한 것이다. 회사에서 사람을 뽑을 때 실력보다 도덕성을 더 눈여겨 봐야 된다는 생각이 날로 확고해지는 요즘. 실력도 도덕성도 그리 높지 않은 경우들을 많이 본다. cheater 들이 생겨 나는 데는 이유가 있겠지만, 내가 고칠 수 있는 문제가 아니다. 게다가 사람과 사람사이의 문제는 자칫 잘못하면 쉽사리 선을 넘어서는 경우도 생기기 때문에 신중하게 생각하고 대처하려고 한다.
마지막은 커리어에 대한 것이다. 우리 회사가 좋았던 점 중 하나는 공룡만한 덩치의 조직이지만 하부 작은 팀에서는 아직 모험정신이 남아 있다는 것이었는데, 조금 생활해보니 그게 꼭 그런 것만도 아닌 듯 하다. 어쩌면 내가 이 회사에 기대하는 바와 얻고자 하는 바가 명확하지 않아서 그런걸까 싶기도 해서, 3개월, 3년, 30 년 뒤 회사에서 내가 얻고자하는 바가 뭔지 한번 정리해보는 것도 좋을 것 같다.
어제 잠깐 만난 친구들과의 대화에서도 비슷비슷한 고민들을 많이 하고 있는 것 같았다. 30대 중반이 멀지 않게 느껴지는 지금이 그런 고민으로 차오르는 때라서 그런지도 모르겠다.
몇 년 만에 이사 했다. 같은 건물 506 호에서 406 호로. 건물에 싱크대 설치 공사를 하느라 옮기게 됐다. 짐을 옮기면서 필요 없는 것들을 최대한 많이 버리자고 마음 먹었다. 책이며 종이들이며 그외에 잡다한 것들도 싹 다 버리겠다고 모아놓고 나니 책상이 아주 깨끗해졌다.
또, 책들 정리하면서 카테고리 별로 책장에 정리해 넣어 보았다. 컴퓨터, 소설, 철학, 과학, 자기계발, 기타로 분류해 놨더니 한결 보기 편해 졌을 뿐만 아니라, 책을 다시 꺼내서 보기에도 좋아졌다.
예전에 이 글 보고 물건 버리는 것도 순서와 방법이 있다는 것을 알고 놀라웠는데, 이번에 직접 해보니 그 효과가 확실하다. 청소의 80% 는 버리는 것에 있다고 해도 과언이 아니다.
버리게 될 책들은 목록을 정리해서 혹 필요한 사람들이 있진 않나 먼저 알아본 뒤 버릴 생각이다. 정리되는 대로 블로그와 미투에 올리려고 한다.
아직 방정리가 덜되어서 인증샷은 힘들다. 아마도 내일 마저 치우고 나며 사람 살만한 공간으로 거듭나지 않을까 싶다.
인생이 늘 제자리에만 머물러 있고 조금도 앞으로 못 나아간다고 느껴지는가? 걱정하지 마라. 삶이란 한 점에서 다른 점으로의 직선 여행이 아니다. 그것은 차라리 수직 상승하는 나선과도 같다. 그러니 반복되는 시련 앞에 좌절말라. 그대의 인생은 지금도 계속 좋아지는 중이다2010-06-17 23:34:54
선글라스끼고 한껏 뽐낸 나이 좀 되시는 아주머니가 경로석에 앉아있던 젊은 사람에게 멀리서 일어나라고 한 뒤 비집고 들어가 자리에 앉으며 다른아주머니에게 이렇게 말한다. '자기 밥그릇은 자기가 챙겨야지. 아줌마도 자기 거 알아서 챙기세요'2010-06-24 09:51:28
아는 분이 NEIS 사이트 접속해야 되는데, 여기가 IE7 만 접근 가능하댄다. 윈7&IE8 등이 나온지가 언젠데, cross browser 지원은 고사하고 IE8 조차 지원하지 못하고 있다. 학부모들의 경우는 http://parents.go.kr/ 이리로 접속하면 IE8 사용이 가능하나, 교사들 사이트는 지원이 아직 되고 있지 않다.
그래서 윈도우즈7 사용자들이 IE7 어떻게 써야 되냐는 질문에 답변드리다가 내용이 생각보다 길어서 블로그에다가 남겨 둔다.
-----------------------
먼저 CPU 가 Virtualization 을 지원하는 지 알아봐야 됩니다.
여기를 클릭하시고, havdetectiontool.exe 를 다운로드 받아 실행하시면 지원 여부가 나옵니다. 아래 그림에서 실행 클릭.
다음과 같은 화면이 나오면 xp mode 를 사용할 수 있다는 뜻입니다.
이제 XP 모드를 설치하러 가야 되는데, 그 전에 현재 사용중인 윈도우 7의 정보를 미리 노트해 둡니다.
