(서평) OS 구조와 원리 - 단연 최고의 OS 개발 서적

나는 학창 시절 주입식 교육의 영향인지 뭔진 몰라도, 일본에 대한 반감을 갖고 있는 편이다.

일본 게임, 일본 만화를 많이 접하면서도 일본색이 지나친 것들에 대해선 다짜고짜 싫어해서 (논리적으로 설명하지 못하면서까지 싫어해서) 친구들과 소모적 논쟁도 많이 하곤했었으니…정도가 좀 심했다.

그럼에도 불구하고, 일본의 문화적 역량과, 마인드는 대단하다는 것을 여러가지 측면에서 깨닳게 된다.

린 소프트웨어 개발에서 극찬한바 있는 도요타식 마인드라던가, 실제 일본인들의 일처리 방법에 대해서 깨닳게 되는 장점이 굉장히 많았다.

내가 느낀 일본인들은 변화에 민감하진 않았다. 오히려 두려워 하는 느낌이라면 맞을까?

그 대신 현재 알고 있는 것에 대한 집중도나, 꼼꼼함은 상상 이상이었다.

이렇게 꼼꼼하니 일본 제품이 뛰어날 수 밖에 없겠구나 싶은 느낌이었다. 또한 사람을 대할때 기본적인 친절함은 아 이사람이 날 존중하고 있구나 라는 생각에 기분이 좋았다.

국내 OS 제작 관련 서적중에서도 뛰어난 서적이 두권이나 발간 되었다. ‘고급 개발자들만이 알고 있는 OS제작의 원리 그리고 Codes’, ‘개발자를 위한 나만의 운영체제 만들기’가 그 책들이다.

하지만 왜…국내서가 번역서보다 설명이 어려운걸까?

번역서인 이 책이 더 친절하고, 더 설명이 이해하기 쉬웠다.

난이도 상승도 적절하다 싶은 생각이 들었고 말이다.

모든 일본서적이 좋은건 아니겠지만 성안당의 ‘성공과 실패를 결정하는…’ 시리즈도 매우 쉽게 이해를 도왔으니 내 느낌은 일본서적이 대체로 이해하기 쉽고 친절하단 느낌을 받게 되었다.

전반적으로 국내서들도 이 책처럼 쉽고, 친절한 구성을 갖춘다면 새로 입문하는 개발자들에게 큰 도움이 되지 않을까 싶은 생각이 들었다.

(서평) 메모의 기술 - 더 많이 기억하기 위해 기록하라. 그리고 잊어라.

사실 나는 메모를 자주 하긴하지만, 메모를 잘 활용한다 말하긴 힘들었었다. 나에게 있어 메모는 기록의 용도지, 기억의 용도는 아니었었다.   잊기 위해 기록한다? 쉬운 말이지만, 나에겐 너무나 혁신적이었다.   나의 기본 발상을 바꿔버릴 획기적인 발상이었던 것이다.     사실 나는 기록은 증빙의 수단으로 주로 사용해왔다.   최대한 많은 것을 외우길 바랬고, 외우려해왔다. 기록이란 최후의 수단에 불과했다.   왠지 기록에 의지하는 것이 내 자신의 기억력을 믿지 못하는거 같아 자존심이 상하기도 했다.     그런데 모든 사람은 기억력에 한계가 있다는 사실을 받아 들이고나니 너무나 편안해졌다.   잊기 위해 기록을 하고나니, 기억한 것들을 잊지 않기 위한 쏟는 노력을 하지 않아도 되었다.   지금 순간에 더 집중할 수 있게 되니, 일을 더 잘할 수 있었다.     또한 기록을 정리하기 위한 방법들도 알게 되니 너무 좋았다.   기록을 정리하는 나만의 기준을 갖게 되니, 기록 된 것들을 더 빨리 찾게 되어 시간도 단축 되고, 기록 된 것을 잘 활용할 수 있게 되었다.     단순히 기록만 많이 하던 나에서, 메모를 기록으로 발전시켜 잘 관리하는 나로 발전할 수 있는 좋은 책이었다.

Software Development MEME

Q. 몇살 때 프로그래밍을 처음했나요?

A. 초등학교 6학년 겨울에 시작했다.

Q. 프로그래밍을 어떻해 하게 되었나요?

A. 게임 만들자고 친구가 말해서, 그림은 못그리고, 기획은 그 당시엔 너무 막막해서 시작했다.

Q. 무엇이 첫번째 언어입니까?

A. C언어

Q. 프로그래밍을 시작한 이후로 어떤 언어들을 사용해봤습니까?

A. C언어, C++, Perl, 어셈블리, PHP

Q. 첫 번째 직업적 실패는 무엇이었나요?

A. 아직 실패한적 없다.

Q. 지금 알고 있는 것을 과거에 알았더라도 프로그래밍을 시작했을까요?

A. 물론이지! 나는 이 직업 말고 다른 직업은 생각치 않는다. 다른 일도 잠깐씩 해보긴했는데 다 지루하고, 적성에 안맞았었기 때문이다.

Q. 이 직업을 하면서 배운 것들 중에 신참 개발자에게 말하고 싶은 게 있다면 무엇인가?

A. 속성과정이란 없다. 프로그래밍 실력이 가장 잘 늘 수 있는 방법은, 프로그램을 많이 작성해보는 것 뿐이다.

Q. 프로그래밍했던 것 중에 가장 즐거웠던 것은?

A. 처음으로 내 손으로 게임을 완성한 그 순간…! 평생 못잊을거 같다. 그 감격을!

(서평) 사랑하지 않으면 떠나라 - 좀 더 나은 내가 되기 위한 가이드 라인.

내 꿈은 프로그래밍을 시작했을 때도, 지금도 프로그래머다. 그래서 프로그래밍을 잘하기 위해 노력해왔고, 다양한 언어, 다양한 툴을 익히기 위해 노력했다.

내가 프로그래밍만 ‘잘’한다면 모든게 다 잘될거라고 생각했다.

실상은 그렇지가 않았다. ‘프로그래밍을 잘한다’는 것과 ‘일을 잘한다’는 것과는 꽤나 큰 차이가 있었다.

취미나, 해커 (크래커적인 의미가 아닌)로써가 아닌 프로그래밍을 업으로 삼는 사람이라면, 일을 함께 잘해야 한다.

논쟁 거리가 될만한 얘기가 될수도 있다는 생각이 들지만, 존 카맥에 대한 내 생각을 말하자면 그는 뛰어난 프로그래머일 뿐, 같이 일하기 좋은 프로그래머는 아니다라는 생각을 갖고 있다.

재능이 뛰어난 것과, 같이 일하기 좋은 것에는 많은 차이가 있다. 또한 존카맥은 천재적인 재능으로 업계 리더로써 인정 받은 것이지, 만약 일반 회사의 직원이었다면 부적응자로 분류 되었을 가능성이 높다고 생각한다.

업계에 만연한 오해는 야근과 주말 근무가 좋은 프로그래머의 자질이라는 말에 있다고 생각한다.

일에 미쳤을 때에는 시키지 않아도, 누가 말려도 당연히 대부분의 시간을 일에 할애 한다. 더 좋은 프로그램을 작성하고, 더 완벽한 프로그램을 만들기 위해 조금이라도 더 일을 하고 싶은 마음이 생겨난다. 그래서 좋은 프로그램을 작성하는 개발자들은 야근을 하고, 주말도 일을 한다. 그러고도 뛰어난 집중력으로 일을 해낼 수 있다.

머릿속에는 일에 대한 생각만 가득한데, 그런 상태에서 여가 시간은 사치일 뿐이다.

하지만 그런 시기가 지나 자신의 삶에 다른 가치들도 찾게 된다. 일에 조금은 지쳤을 수도 있다. 하게 되는 업무가 자신이 원하는 일과 갭이 생겼을 수도 있겠지.

일에 미치지 않은 상태라면 휴식을 하지 않고선 능률을 내기가 매우 힘들다. 당연하지 않은가? 휴식은 집중력을 더 오래, 더 자주 발휘하기 위해 필요한 것이기 때문이다.

이 책은 일에 미쳐있고, 일만 생각해온 워크홀릭에 빠진 사람을 위한 책이 아니다.

오히려 대부분의 ‘보통’ 프로그래머들이 집중력이 떨어진 상태에서도 일을 더 잘해낼 수 있도록 가이드 라인을 제시해줬다.

또한 프로그래밍’만’ 잘하는 프로그래머에서, 프로그래밍’도’ 잘하고, 사람 관계도 잘하고, 인정도 받는 좋은 사람이 되는 법에 대해 알려준다.

자기 계발서는 많았지만, 이토록 디테일한 프로그래머 자기 계발서는 없었다. 좀 더 나은 내가 되기 위한 카운셀링을 받은 듯한 즐거움으로 책을 읽어냈다.

사랑하지 않으면 떠나라라는 책 제목이 편견을 갖게 하기도 했지만, 주어진 환경에서 더 나은 내가 될 수 있는 방법을 가르쳐주는 이 책이 앞으로 나의 개발자로써의 인생이 큰 보탬이 될 것은 확실한 것 같다.

(서평) 우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해 - 왜 같은 실수를 반복하는가?

소프트웨어 업계가 아직 젊다고 하지만, 벌써 50년 이상의 세월이 지나왔다.

그 세월 동안 다양한 경험과 통찰로 이루어진 결론들이 있었지만, 이 업계의 많은 사람들은 그 결론들을 일반화 시키는 것을 두려워하고, 인정하지 않으려 해온게 사실이다. (그리고 여전히 대부분 그렇다.)

사람 5명이 해오던 일을 10명이서 한다고, 수행 속도가 2배가 되는 것은 ‘절대’ 아니다.

소프트웨어 업계는 생산업계의 방식을 그대로 적용해선 안된다. (물론 같이 통용될 수 있는 것들도 있지만!)

업계의 대부분 관리자들이 생각하는 더 좋은 능률을 내기 위한 방법들은 여전히 너무나 무지하다.

왜 같은 실수를 반복하는가?

폭포수 방식에 대한 폐해는 여실한데, 업계는 여전히 폭포수 방식을 선호한다.

이유는? 그것이 관리하기 편하기 때문이다.

더 좋은 프로그램을 위해선 업무에 대한 자유가 필요하다. 개발자는 자신의 일을 직접 추정하고, 고칠 수 있어야 한다. 무엇이 변하지 않는단 말인가? 오늘의 모든 것은, 내일이 되면서 모든게 변한다.

이전 단계의 모든 사항이 불변이라 믿어버리는 폭포수 방식은 너무나 구식이다. (난 사실 예전이라고해서 잘 적용되었다고 믿긴 힘들다.)

작업 환경도 창의성을 억제한다. 업무시간에 창의성을 발휘할 수 있도록 조용한 환경에서 일할 수 있다면 업무 능률이 반드시 오를것이다.

또한 많은 회사들이 망각하는 사실은 개발단계보다 유지보수 단계의 중요성이 굉장히 크다는 것이다.

개발은 ‘완료’되지 않는다. 다만 멈출 뿐이다. 개선할 여지는 얼마든지 있다.

개발이 완료 되지 않는 것이기에 테스트와, 검사 과정은 유지보수 단계에서 지속적으로 반복 되어야 한다.

허나 유지보수 단계에서의 테스트와 검사가 등안시 되곤 하는 것이 현실이다.

사실 이 책에 나온 이야기들은 프로그래밍 업계에만 적용되는 이야기들이 절대 아니다.

대부분 다른 업계에서도 통용되는 ‘진실’들이고, 구구 절절 옳은 이야기지만 ‘그들’은 믿고 싶지 않을 뿐이다.

아니 알고 있으면서도 행할 수 없는 건지도 모르겠지만 말이다.

나아지고 싶다고? 잘해내고 싶다고? 행운을 바라지마라. 실천하라. 조금씩, 그리고 자주.