보안 어떻게 할 것인가?

기업마다 자사의 기술 및 기밀을 유출시키지 않기 위해서 보안관련 규정을 엄격하게 재정비하고 있으며, X-ray 투시장비를 설치하거나 PC에서의 데이터 유출을 막기위한 시스템을 도입하는등 막대한 자원을 투입하고 있다. 그럼에도 불구하고 기업의 기술 유출 사고가 매년 보고되고 있으며, 그 피해 규모도 늘어나는 추세이다. 이에 따라 각 기업에서는 보안을 더욱 강화하는 악순환이 매년 되풀이 되는 듯 하다.
하지만 아무리 보안 규정이나 검열이 강화되어도 회사의 직원이 마음만 먹는다면 기밀이나 기술을 빼돌리는 것은 그리 어렵지 않다. 보안 규정 및 검열은 단지 선량하게 열심히 일하는 다수의 직원을 번거롭게 하고 업무 효율을 극도로 떨어뜨리는 "낭비"의 범주를 벗어나지 못하는 것이다.
그럼 어떻게 하면 업무 효율에 영향을 미치지 아니하고 보안을 강화할 수 있을까? 정답은 직원들의 회사에 대한 충성도를 높이는 것이다. 직원 개개인이 회사에 대해서 자부심으로 충만하고, 이런 직원을 상대로 보안 교육이 적절히 병행된다면, 더 이상의 보안 강화책은 필요하지 않을 것이다. 직원에 대한 복지를 높이고, 업무 외에 부당한 요구를 하지 않으며, 기업 및 기업주가 사회에 떳떳할 때, 이런 기업 아래에서 일하는 직원은 회사에 대한 자부심으로 회사에 충성하며, 열심히 일할 것임은 너무나 쉬운 이차라 모두가 잊은것 아닌지 모르겠다.

개발에 도움을 주는 사람 방해를 하는 사람

개발을 진행하다 보면 기술적인 측면 그 이상으로 인간 관계가 해당 프로젝트의 성패에 더 큰 영향을 미치곤 한다. 십인 십색 백인 백색... 사람은 사람마다 천차 만별이라 만나는 이마다 한명도 똑 같은 사람은 없고 이들사이에 형성되는 네트워크만큼 복잡한 시스템도 없을 것이다. 이ㅈ



모사꾼.


관리에 소질 없는 관리자.
여론을 만드는 사람.

엔지니어에게 직장 선택의 자유를...

법으로 보장된 직업선택의 자유가 유독 엔지니어에게만 제약사항이 많은 것 처럼 느껴지는 것은 내가 엔지니어이기 때문일까? 일반적으로 전자 업계에 근무중인 엔지니어가 다른 회사로 이직을 할 경우 "동종 업계" 이직이라 하여 2년간 이직을 제한 받을 수 있다. 하지만 오히려 엔지니어가 동종 업계로 이직하는 것은 당연한 것이다. 대학시절부터 줄곧 배운게 이 분야인데 당연히 "동종 업계"로 이직을 해야지 "이종 업계"로 이직하란 말인가? 공대를 졸업하고 엔지니어로 취직하고 일하다가 이직하려면 엔지니어 때려치고 보험회사 영업하란 말인가?
쉬운 예를 들어보자 만약 당신이 어떤 큰 중국집에서 주방장 보조로 10년간 내공을 길렀고 이제 다른 중국집에 주방장으로 스카웃 되어 이직을 하려는데 만일 "동종 업계" 이직 금지 조항이 있어 이직을 못한다면 어떻겠는가? 배운것이 중국요리인데 한식집이나 일식집으로 갈 수도 없고... 또한 한식이나 일식도 음식점이니 어떻게 보면 동종 업계인데.. 2년간 요식업계를 떠나라는 소리인지도 헷갈린다.
회사의 기밀 보호도 좋지만 영업사원의 영업 노하우를 회사 기밀이라고 해서 이직을 제한하지 않듯이 엔지니어의 머리속에 기억된 기술도 회사의 기밀이 될 수 없다. 만일 엔지니어의 기술이 회사의 기밀에 속하는 내용이 있을 경우, 해당 기술을 특허 신청하여 보호하여야지 엔지니어의 직장 선택의 자유를 박탈해서는 안될 것이다.
공학기술에 무지한 법학자들이 대기업들의 로비에 휘둘려 자신들도 모르는(? 의심스럽지만) 사이에 침해한 엔지니어의 권리를 돌려받아야 한다.

공감이 가는 글이 있어서 링크를 겁니다.
http://www.zdnet.co.kr/itbiz/column/anchor/hjkim/0,39030302,10062738,00.htm

리눅스 문제 분석과 해결, Mark Wilding/Dan Behman, 에이콘, ****

간만에 읽을 만한 책이라 판단되어 허겁지겁 읽어내려 갔지만, 결코 만만히 읽어치울 수 없어 마음을 고쳐잡고 찬찬히 읽고 있는 책. 어떤책인지 판단할 만큼 충분히 읽지는 못했지만 남은 부분이 무척이나 기대되는 책이다. 전반적으로 John Robbins가 쓴 Microsoft의 Debugging Applications 이란 책의 리눅스 버젼이라고 생각하면 크게 틀리지 않을 것 같다. 두 책 모두 stack이나 calling convenstion, Assembly level의 디버깅등 고급 디버깅 기법을 설명하고 있다. 단지 서로의 OS환경에 좀 더 의존하고 있기는 하지만, 이런 기술은 결국 하나로 통하기 마련아닌가? 여기서 어떤 책이 더 좋은지를 논할 필요는 없을 것 같다. 두 책 모두 훌륭해 보이며 둘 중 하나를 읽었다 하더라도 여전히 남은 하나를 읽을 가치가 있어 보인다.

여러개의 프로젝트에 참여하기

개발을 하다 보면 종종 여러개의 프로젝트에 동시에 참여하게 되는 경우가 있다. 프로젝트의 진행에는 강약이 있기 마련이지만 여러 프로젝트의 중요 일정이 겹치게되면 감당할 수 없을만큼 많은 일들이 동시에 주어지기도 한다. 서로 다른 프로젝트의 리더가 중요하고 급한 일이라고 각기 다른 일을 던져주고 빠른 피드백을 원한다면 일의 우선 순위를 어떻게 잡아야 할까?

한국적인 정서에서 두 프로젝트 리더를 모아놓고 "두분이서 협의해서 우선순위를 정해주세요" 라고 요청하는 것은 거의 자살행위에 가까워 보인다. 경우에 따라 조금 가혹한 평가일 수도 있지만 적당히 일의 우선 순위를 정해서 상사가 기분나쁘지 않게 적당히 완급을 조절하며 업무를 처리하는 것도 개인의 능력이라고 할 수 밖에 없을 것 같다. 일단 현재 내가 바쁘다는 사실을 인지시킬 수 있다면 어떻게든 상사의 기분을 상하지 않게 주어진 일의 기한을 연장하거나 다른 사람에게 양보? 할 수 있을 것이다.

자신에게 마이너스인지 알면서도 일이 바뻐 눈코뜰 새 없을 때 새로 업무를 던져주는 상사를 보며 인상을 찌푸리는 것은 내가 어쩔 수 없는 까칠한 인간이기 때문일까? 싸가지가 없어서 일까?

하여간 이런 방법으로 상사에게 눈치를 주어 일을 조금 덜 배정 받는 것은 정말 세련되지 못한 방법이다.. 그러지 말자..ㅠㅠ

프로젝트 일정을 제대로 계획하였다면...

프로젝트 일정을 제대로 계획하였다면 일정상의 공휴일 및 개인 휴가와 여유 기간, 통합 기간 그리고 디버깅 기간을 합친 시간이 실제 순수히 설계 및 코딩에 들어가는 시간보다 많아야 한단다.. 이것이 황금률은 아니더라도 수긍이 가는 이야기 임에는 틀림 없는 것 같다. 이세상의 모든 프로젝트 관리자에게 소리친다. "프로젝트가 일정을 준수하고 싶은가? 그렇다면 일정을 제대로 짜자..."

임베디드 개발자를 위한 리눅스 커널 심층 분석, Robert Love, 에이콘 ****

http://www.acornpub.co.kr/book/linux-kernel

리눅스커널을 설명한 책들이 많이 나와 있지만 대부분의 책들이 소스코드를 설명하려 하다가 방대한 커널 소스 코드의 일부만을 다루고 흐지부지 끝을 맺는 경우가 대부분 이었다. 소스 코드 때문에 책의 두께는 두껍지만 별로 읽을 만한 내용도 없고 그렇다고 소스 코드에 대한 설명이 자세한 것도 아니다. 하지만 이 책에는 소스코드가 거의 없이 커널의 구현이 깔끔 단백하게 설명되어 있다. 다행이 좋은 내용의 책이 믿을 만한 출판사에서 번역되어 한글 번역도 훌륭하다. 시중에 나와 있는 리눅스 커널 설명서 중에서는 단연 추천하고 픈 책이다. 책 제목에 "임베디드 개발자를 위한" 이란 말이 들어 있는데 이것은 원저에는 없는 사족이며 출판사에서 임의로 붙인듯 하다. 사실 이 책은 임베디드 개발과 큰 관련은 없으며 실제로 같은 출판사에서 번역된 이 책의 개정판에는 "임베디드 개발자를 위한"이란 표현이 없는 것으로 알고 있다. OS 커널을 공부하거나 리눅스 커널에 관심있는 사람이라면 필독, 강추. (이 책 구매 후 개정판이 원서로 출간되었길래 개정판을 원서로 구매하였는데 얼마되지 않아서 개정판에 대한 번역서가 또 출판되었다. 아직 개정판 원서는 모두 읽지 못하였는데... 읽을때 마다 가슴이 쓰리다.)

Programming Applications for Microsoft Windows 4th ed., Jeffrey Richer, Microsoft *****

기술서적을 읽으면서 눈물을 흘려본적이 있는가? 기술서적이 재미있어 다음장에 나올 내용이 궁금해 본 적이 있는가? 이 책은 꽤 두꺼운 책이지만 책 두께가 더 두꺼웠으면 좋을 정도로 중요하고 흥미로운 내용으로 꽉 차있다. 개인적으로 이 책을 읽어보지 않은 사람들은 상용 윈도우즈 프로그램을 만들지 않았으면 하는 생각이 들 정도로 윈도우즈 개발자들이 꼭 알아야 하는 내용으로 가득 차 있다. 전산 전공이 아니라 개인적인 흥미로 프로그래밍을 시작한 나에게는 이 책을 통해서 단지 윈도우즈 환경에서의 프로그래밍 뿐만 아니라 부족했던 전산관련 지식을 업그레이드 할 수 있었고, 이 책에서 배운 내용들은 더이상 윈도우즈용 풀그림이 아닌 임베디드 환경에서의 풀그림을 작성하는데도 많은 도움이 되고 있다. 아직 이 책을 읽지 않은 개발자라면 무조건 강추. (내공이 한갑자 이상이라면 pass)

"... 그럼에도 불구하고, 사람들은 직무 재조정을 전혀 거치지 않은 상태에서 상급 코딩 기술자를 관리자로 밀어붙이는 작업이 가능하다고 받아들입니다."-조엘 온 소프트웨어

현재 근무하는 회사에서 이러한 현실을 바꿀 수 없는 경우, 관리자로 밀어붙여진 개발자가 선택할 수 있는 길은 무엇일까?

임베디드 시스템 펌웨어 분석, Ed Sutter, 에이콘 ***

http://www.acornpub.co.kr/book/firmware

임베디드 시스템의 펌웨어 개발자가 알아야 하는 내용을 깔끔하게 설명한 책. (너무 깔끔해서 가끔은 좀 불친절해 보임) 이책은 간단한 기능의 디버그 모니터의 소스 코드 전부를 CD로 제공하고 이 디버그 모니터의 구현을 설명하였다.

최초에 H/W팀으로 부터 받은 H/W를 어떻게 동작시키는지부터 시작하여 target보드에 기본적인 개발 환경을 어떻게 만드는지를 설명한다.

디버그 모니터 소스 코드를 통째로 지원하므로 자신의 h/w에 책에서 제공하는 디버그 모니터를 올려서 테스트 해 볼 수 도 있다. (단 당신의 target board가 책에서 지원하지 않는 CPU를 사용하여 구성되었다면 해당 CPU의 assembler를 사용하여 초기화 루틴을 직접 작성해야 한다.)

앞서 잠깐 언급했지만 이 책을 읽다보면 종종 내용이 너무 깔끔해 설명이 충분치 못하다고 느껴지는 부분이 많다. 사실 이런 부분을 모두 제대로 설명하려면 책 분량이 엄청나게 커질 것이기 때문에 저자를 비난하기는 힘들것 같다. 하지만 CD에 첨부된 PDF 문서들을 열심히 읽으면 대부분의 궁금증을 해결할 수 있을 것이다. 물론 이해하려면 약간의 내공이 필요한 문서들이지만 모두 읽고나면 뿌듯히 충만한 공력이 단전에서 느껴질 것이다.