2011년 4월 28일 목요일
당구병법
현수막에 오타가.. 박창대소 --> 박장대소
당구엔 일본말이 너무 많아..ㅡㅡ;
옛날 알고있던 엽기 당구송..
철없던 다마
-지은이 미상
-원곡:철없던 사랑(홍수철)
철없는 마음으로 큐대를 잡았었지
오시도 모르는 채 시끼도 모르는 채
불타는 가슴으로 초크를 칠하면서
영원토록 아름다운 우리의 다마인생
우라는 싫어 쫑이 날 가망성이 너무 많아
그리워져요 똥창에 모인 꽃다마
내사랑 시끼 시끼여 다시 한 번 빨아줘요
아름다워요 뽀루꾸 쓰리쿠션
철없는 마음으로 큐대를 잡았었지
오시도 모르는 채 시끼도 모르는 채
불타는 가슴으로 초크를 칠하면서
영원토록 아름다운 우리의 다마인생
우라는 싫어 쫑이 날 가망성이 너무 많아
그리워져요 똥창에 모인 꽃다마
내사랑 시끼 시끼여 다시 한 번 빨아줘요
아름다워요 뽀루꾸 쓰리쿠션
안드로이드폰 갤럭시s 후기/리뷰 안드로이드 마켓(비밀메모/잠금장치)- 어플 다운받기 [ securememo ]
안드로이드폰에서 빠질 수 없는 것은 뭐? 바로, 안드로이드마켓 입니다!
안드로이드 마켓(Android Market)은 구글이 운영하고 있는 구글 안드로이드용 애플리케이션을 다운로드를 할 수 있게 해주는 서비스 입니다.
안드로이드마켓을 이용해서 유용한 어플리케이션을 다운 받아, 나만의 휴대폰을 만들 수 있다는 것! 바로 안드로이드 폰만의 장점이죠?
이제 그 방법을 알려드릴게요.
안드로이드폰을 쓰면서 '잠금장치'에 대하여 불편함을 느끼셨던 분들에게 아주 좋은 어플리케이션일 것 같아요.
'비밀메모'어플을 이용하시면 메모 하나하나가 개별적으로 암호화되어 계좌번호나 주민등록번호 등 안전하게 메모장에 입력하시고
타인이 볼 염려를 하지 않으셔도 됩니다. 또한 원하지 않는다면 암호화를 하지 않고도 저장하실 수 있으십니다.
다운 받는 것을 바로 확인할 수 있습니다.
'성공적으로 설치되었습니다.' 라는 메시지가 보이네요.
Secure Memo를 실행해주세요.
깔끔한 화면이네요^^ 저는 요란하고 화려한 것보다 이런 깨끗한 것을 좋아합니다. 메모는 제목/크기/날짜로 정렬이 가능하니 편리하게 사용하시면 될 것 같아요.
메모를 추가해볼까요?
상단에 연필모양을 클릭해주세요.
나만의 secure memo를 작성해주세요.
삼성키패드로 입력을 했습니다.
(키패드설정이 나옵니다. 이때, 저는 삼성키패드로 설정을 했습니다.)
내용을 입력 후 저장버튼을 누르시면 이런 창 하나가 뜨는데요.
제목을 지정하시고 암호화를 클릭, 비밀번호를 입력해주세요.
비밀번호를 입력한 후에 저장버튼을 눌러주세요.
메모별로 암호화를 설정할 수 있으니 까먹지않게 조심하셔야 해요^^
저장된 메모를 클릭하니 비밀번호 입력창이 뜨네요. 일부러 틀린 비밀번호를 입력하니까 '비밀번호가 일치하지 않거나 손상된 파일입니다.'
라고 뜨네요. 확실히 ^^아무도 못 보겠네요. 나만의 비밀메모를 안전하게 저장하세요^^
월남전당시의 한국군 사진들..
출처는 오유 ( http://todayhumor.co.kr )
(정확한 페이지는 모르겠네요)
치열한 전투중에 목숨을 걸고 베트남의 아이들을 구해내는 용감한 한국군.. 우리들의 아버지, 할아버지입니다..
간절한 소망이 씌여있는 한 병사의 철모..
파병전 환송식에서 아들을 바라보는 어머니...
곧 전쟁터로 떠나는 아들 앞에서 망연자실한 어머니..
The Joel Test: 나은 코딩을 위한 12단계
The Joel Test: 나은 코딩을 위한 12단계 |
글 : Joel Spolsky
번역 : B.K. Chung 정봉겸
감수 : Jang Han Goo 구장한
2000년 8월 9일
SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다.
The Joel Test
|
Joel Test이 특별한 점은 각 직문에 예/아니오로 바로 대답할 수 있다는 것이다. lines-of-code-per-day(하루동안 산출되는 코드의 줄수)나 average-bugs-per-inflection-point(산출 시점의 평균 버그수) 같은 것은 알 필요가 없습니다. "예"에 해당 하는 질문에 1점씬 가산됩니다. 하지만 이 테스트는 핵 원자로에 사용하는 소프트웨어가 안전한지를 검사하는등 에는 사용하지 말아주십시오.
12점은 완벽, 11은 충분한 점수이지만 10점이나 그 이하는 심각한 문제가 있다는 신호입니다. 사실은 대개의 소프트웨어 회사 들이 2~3점을 받고 있고, 심각한 도움을 필요로 하고 있습니다. Microsoft같은 회사는 12점 만점을 받고 있습니다.
당연한 이야기지만 이것들만으로 성공과 실패를 가를 수는 없습니다. 특히, 아무도 필요없는 제품을 굉장히 훌륭한 소프트웨어 팀이 만들고 있다면, 역시나 아무도 원하지 않을 것입니다. 반대로 이런 방식을 따르지 않는 명인들이 세상을 바꾸는 소프트웨어 를 만드는 경우로 생각할 수 있겠습니다. 그러나, 이 12가지 이외의 요소를 모두 동등하게 놓고 본다면, 이들만 제대로 한다면 지속적으로 좋은 결과를 내는 잘 훈련된 팀이 될 것입니다.
1. Source Control(소스 컨트롤)을 사용하십니까?
상용 소스 컨트롤 패키지들도 사용해보았고, 무료로 사용할 수 있는 CVS도 사용해보았습니다. CVS는 무료이기는 하지만 충분합니다. 그렇지만 소스 컨트롤이 없다면 프로그래머들을 조율하는 일이 상당히 피곤할 것입니다. 프로그래머들은 다른 사람들이 어떤 것을 했는지 알 수 있는 방법이 없습니다. 이를 사용하면 실수를 쉽게 롤백할 수 있습니다. 소스 컨트롤의 다른 장점은 소스코드 자체가 모든 프로그래머의 하드디스크에 체크아웃(check out)되어 있다는 것입니다. 소스 컨트롤을 사용하는 프로젝트에서 코드를 날렸다는 이야기를 들어본 적이 없습니다.
2. 한번에 빌드를 만들어낼 수 있습니까?
"최신의 소스로부터 몇단계를 거쳐서 완제품(shipping build)을 만들 수 있습니까?"라는 의미의 질문입니다. 잘 되어있는 팀인 경우라면 하나의 스크립트로 checkout부터 시작하여 각 소스를 리빌드(rebuild)하고 각 버젼, 언어, #ifdef같은 조건별로 실행파일을 만들어내어 마지막 CDROM 레이아웃, 다운로드할 수 있는 웹사이트를 만들어 내는 정도까지 되어 있을 수 있겠습니다.
만일 이 과정이 하나의 단계 이상을 거친다면, 여기서부터 에러가 발생할 확률이 생깁니다. 정해진 기일이 가까워질수록 "마지막" 버그를 수정하고 실행파일을 만드는 등을 위해 빠른 사이클을 필요로 할 것입니다. 코드를 컴파일하고 설치파일을 구성하는데에 20단계가 필요하다면 급박한 시간때문에 사소한 실수를 저지르게 될 것입니다.
필자가 마지막으로 근무했던 회사에서는 이런 이유로 WISE를 InstallShield(역자주 : 두 제품 모두 설치본을 만들기위한 도구 입니다.)로 교체하였습니다. 설치 과정을 스크립트를 통해서 NT 스케줄러로 밤새에 자동으로 실행하도록 하고자 하였는데, WISE는 스케줄러로 실행할 수 없던 이유입니다. (WISE의 친절한 분들이 최신 버젼에는 이것이 가능하다고 알려왔습니다.)
3. daily build(일별 빌드)를 만드십니까?
소스 컨트롤을 사용하다 보면 누군가가 빌드를 실패하게 만드는 코드를 체크인 할 수 있습니다. 예를 들면, 새로운 소스파일을 추가해서 그 사람의 컴퓨터에서는 잘 컴파일되지만, 이를 코드 레파지토리(repository)에는 추가를 하지 않았을 수 있습니다. 이 사람은 이를 잊고 만족한 상태에서 컴퓨터를 잠그고 집에 돌아갑니다. 그렇지만 이로 인해 다른사람들은 작업을 할 수 없게 되고 결국 찝찝하지만 결과없이 집으로 돌아갈 수 밖에 없습니다.
모르는 사이에 빌드를 실패하는 이런 컴파일 오류가 나지 않도록 daily build를 만들게 됩니다. 큰 팀에서는 이런 경우를 위해서 daily build를 매일 오후 - 점심시간등 - 에 합니다. 사람들은 점심시간 이전에 될 수 있는 한 많이 체크인을 합니다. 점심을 먹으로 갔다가 다시 돌아오면 빌드는 이루어져 있습니다. 빌드가 실패하면, 사람들은 빌드가 성공한 이전 소스로 작업을 하면 됩니다.
엑셀팀에서는 누군가 빌드를 깨면 벌칙으로 다른 사람이 다시 깰때까지 빌드를 관리하도록 벌칙을 주었습니다. 이는 빌드를 깨면 받는 벌칙으로써 뿐만 아니라 모든 이들이 돌아가면서 빌드를 관리할 수 있게하여, 어떻게 돌아가는 지를 익히게 하는 방법으로써도 좋았습니다.
daily build에 관해 더 자세히 아시려면 저의 기사 daily builds are your friend를 읽으십시오.
4. 버그 데이타베이스를 가지고 있습니까?
뭐라고 반박하셔도 확신합니다. 코드를 짜고 있다면 설령 혼자 짜더라도 정리된 버그 명세 데이타베이스를 가지고 있지 않다면 낮은 질의 코드로 제품을 출시할 것입니다. 많은 프로그래머들이 머리로 버그들을 모두 기억할 것이라고 생각합니다. 말도 안되는 이야기입니다. 제 경우에는 한번에 2~3개의 버그밖에 기억을 못하고, 다음날이 되거나 출시를 위해 급해지면 전부 잊어버리게 됩니다. 버그를 제대로 트래킹해야합니다.
버그 데이타베이스는 복잡할 수도 있고, 간단할 수도 있습니다. 최소한으로 갖추어야할 요소는 다음과 같습니다:
- 버그를 완벽하게 재현할 수 있는 과정
- 버그가 없었다면 이루어졌어야할 결과(동작)
- 버그로 인하여 생긴 결과(동작)
- 누가 이 버그에 할당되어 있는지
- 고쳐진 버그인지 아닌지
버그 데이타베이스를 사용하지 않는 이유가 제품들이 너무 복잡해서라면, 이것들을 포함한 5컬럼의 테이블을 만들어서 사용하기 시작하세요.
버그 트래킹에 관해 더 읽으려면, Painless Bug Tracking을 읽으세요.
5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
마이크로소프트 Windows용 Word의 첫 버젼은 죽음의 프로젝트였습니다. 끝이 없었습니다. 계속해서 스케줄을 펑크냈습니다. 팀 전체는 말도 안되는 시간동안 일했고, 계속해서 연기되고 또 연기되었습니다. 그 스트레스는 엄청났습니다. 빌어먹을 제품이 몇년 후에 출시되었을때, 마이크로소프트는 팀 전원을 Cancun으로 휴가보내고, 이 원인을 분석하기 시작했습니다.
그들이 깨닫게 된 것은 프로젝트 매니저들이 스케줄을 너무 강요하였기 때문에 프로그래머들은 코딩을 빨리 할 수 밖에 없었습니다. 게다가 버그를 고치는 단계는 스케줄에 아예 존재하지 않았습니다. 결과적으로 질이 아주 나쁜 코드를 만들게 되었습니다. 버그 갯수를 줄이려는 노력은 전혀 하지 않았습니다. 한 프로그래머는 텍스트의 높이를 계산하는 루틴 대신에 "return 12;"로 대체하여 버그 리포트로부터 이 값이 어떤 영향을 주었는지를 알고자 했습니다. 스케줄은 단지 버그일 수 밖에 없는 기능들을 모아 놓은 체크리스트였습니다. 나중에 이 상황을 "무한 결함 방식(infinite defects methodology)"이라고 이름지었습니다.
문제를 해결하기 위해서 마이크로소프트는 반대의 "무결함 방식(zero defects methodology)"라는 방식을 체택했습니다. 많은 프로그래머들은 경영진들의 명령에 의해서 버그 갯수를 줄일 수 있다고 생각했음직한 이 방식의 이름 탓에 이를 비웃었습니다. 하지만 실제로는 "무결함(zero defects)"이라는 이름은 주어진 시간에 가장 우선순위가 높은 것은 코딩하기전에 버그를 잡는 것이란 사실을 지칭하는 말이었습니다. 이유는 다음과 같습니다.
일반적으로 버그를 고치지 않고 방치하는 시간이 길어지면 길어질수록 고치는데 더 많은 시간과 금전이 요구된다는 것입니다.
예를 들면, 오타나 문법오류등은 컴파일러가 쉽게 잡아서 고치는데도 별로 문제가 되지 않습니다.
만일 버그가 처음 실행시에 발생하여 보이게 되면, 모든 코드가 머릿속게 생생하게 존재하기에 바로 고칠 수 있을 것입니다.
며칠전에 작성한 코드에서 버그를 찾게 되면 이를 고치기 위해 조금 시간이 더 걸릴 것입니다. 아마도 코드를 다시 보게 되면 대부분의 내용이 기억나고 적정한 시간내에 버그를 고칠 수 있을 것입니다.
하지만 몇달전에 작성한 코드에서 버그가 발견된다면 이미 그 코드에 관해서 많은 것이 이미 생각나지 않을 것이고, 고치기도 상대적으로 힘들 것입니다. 그때쯤 되면 다른 사람의 코드를 수정하고 있는 와중일지도 모르고, 그사람은 Aruba로 휴가를 떠나있을지도 모릅니다. 이렇게 된다면 버그를 고치는 것은 기술을 익히는 것같이 되어버릴 것입니다. 천천히 꼼꼼하게 그리고 주의 깊게 코드를 살펴봐야 하고, 물론 문제를 해결하는데에 얼마나 걸릴지 정확하게 판단하기 힘든 상황이 될 것입니다.
게다가 이미 출하된 코드에서 버그를 발견한다면, 이를 고치는데에 큰 대가를 치뤄야할지도 모를 것입니다.
이렇게 시간이 적게 들기 때문이라는 이유가 하나의 이유가 됩니다. 또다른 이유는 버그를 수정하는데 걸리는 시간을 예상하는 것보다는 새로운 코드를 작성하는데 걸리는 시간을 예상하기가 훨씬 쉽기 때문입니다. 예를 들면, 내가 당신에게 리스트를 소트하는 코드를 만드는데 얼마나 걸리냐고 물어본다면, 꽤 정확한 대답을 할 수 있을 것입니다. 그렇지만, 질문을 바꿔서 당신의 코드가 Internet Explorer 5.5만 설치되어있으면 동작하지 않는 버그를 고치는데 걸리는 시간을 묻는다면, 문제가 무엇인지도 모르는 상황이기 때문에 얼마나 걸릴지 추측하지도 못할 것입니다. 3일이 걸릴 수도 있을 것이고, 운좋으면 2분이 걸릴 수도 있을 것입니다.
이것이 의미하는 바는 고쳐야할 버그가 많이 존재하는 상태의 스케줄이라면 그 스케줄은 정확할 수가 없다는 것입니다. 그렇지만 이미 알고있는 버그들은 모두 고친 상태라면 그 스케줄은 상대적으로 상당히 정확하게 지킬 수 있는 스케줄일 것입니다.
버그 갯수를 0에 가깝게 하는 또하나의 좋은 점은 경쟁에서 훨씬 빠르게 대응할 수 있다는 것입니다. 어떤 프로그래머들은 이를 두고 제품을 바로 출하할 수 있는 항상 유지하는 것이라고 이야기합니다. 경쟁자가 고객들을 가로채갈만한 굉장히 좋은 기능을 새로 만들었다면 축척된 많은 버그를 수정할 필요없이 바로 이 기능을 추가할 수 있을 것입니다.
6. up-to-date(최신) 스케줄을 가지고 있습니까?
비즈니스에 당신의 코드가 조금이라도 중요한 부분이라면, 코드가 언제쯤 완성될 수 있는지를 아는 것 또한 중요하다는 것은 당연할 것입니다. 프로그래머들은 엉터리 스케줄을 만드는데 악명이 높습니다. "언젠가는 될꺼야!"하고 외칩니다.
불행하게도 그런 식으로는 해결할 수 있는것은 없습니다. 비즈니스에는 코드를 출하하기 전에 데모, 전시회, 광고등등 미리 많은 것들을 판단하여 결정해야합니다. 이를 할 수 있는 단 한가지 방법은 스케줄을 가지고 이를 계속해서 현실적으로 최신내용으로 유지하는 것입니다.
스케줄을 가져야하는 또다른 중요한 이유는 이를 통해서 어떤 기능이 필요한지를 결정하게끔 만들어준다는 것입니다. 때문에 어떤 기능이 덜 중요한지 결정해야하고 featuris 가 되기 전에 이들을 포기하도록 합니다.
스케줄을 관리하는 것이 어려울 필요는 없습니다. 제 글Painless Software Schedules 에 좋은 스케줄을 만드는 간단한 방법을 설명하였습니다.
7. spec(설계서)를 가지고 있습니까?
스펙을 만드는 것은 이빨을 쑤시는것과 같습니다: 모든 사람들이 좋다고 인정하지만, 아무도 하지 않습니다.
왜 그런 현상이 일어나는지는 정확히 모르겠습니다만, 아마도 프로그래머들이 문서를 만드는 것을 굉장히 싫어하는데에 기인하는 것 같습니다. 그 결과로, 프로그래머밖에 없는 집단에서 한가지 문제를 해결하고자 하면, 이들은 문서를 만들기 보다는 코드로 자신들의 의견을 표명하려 합니다. 스펙을 먼저 만들기보다는 차라리 코드를 짜서 보여주는 것을 택한다는 것입니다.
설계 단계에서 문제를 발견하면 몇줄을 고쳐서 이를 수정할 수 있습니다. 그렇지만 코드가 짜여진 상황이라면 이 문제를 수정하는 댓가는 감정적으로나(코드를 그냥 버리는 것을 좋아하는 사람은 없습니다) 시간적으로나 훨씬 높게 되고 더 힘든 작업이 되어버립니다. 스펙을 통해서 만들어지지 않은 소프트웨어는 대개 설계가 잘못되어 스케줄을 엉망으로 만들어놓습니다. Netscape에서도 이런 문제로 인해 브라우저의 초기 네개의 버젼이 너무 엉망이 되어 결국 관리자들이 멍청하게도 코드를 전부 버리고 다시 짜도록한 결정을 내려버리게 되는 상황이 벌어졌습니다. 거기다 한술 더 떠서 Mozilla에서 이런 실수를 다시 반복하여 겨우 Alpha 단계에 가는데 몇년이라는 시간이 걸리게 되었습니다.
필자의 지론은 이 문제는 프로그래머들이 문서를 작성하는데 거부감이 없도록 작문 강의를 듣도록 보내는 것으로 해결할 수 있다는 것입니다. 다른 해결책이라면 스펙같은 문서 작성에 능숙한 관리자를 두는 것입니다. 두 경우 모두 "스펙없는 코드는 금물"이라는 간단한 규칙을 따라야 할 것입니다.
저의 4부짜리 글에 스펙 작성하는 요령에 대해 이야기했습니다.
8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
지식 근로자에게 공간, 조용함, 프라이버시를 줌으로해서 많은 생산성 향상을 얻는다는 것은 이미 증명된 사실입니다. 소프트웨어 관리의 고전인 Peopleware에서는 이 생산성 향상에 대해 자세히 기술합니다.
문제는 여기에 있습니다. 지식 근로자는 "in the zone"상태라고도 하는 "flow"상태에 들어섬으로써 가장 최상의 상태가 되어 일에 완벽히 집중하고 외부에 개의치 않게 됩니다. 완벽한 집중으로 시간 가는 것을 잊고 좋은 결과를 내게 됩니다. 이때에 바로 대부분의 생산적인 일들을 처리하게 됩니다. 작가, 프로그래머, 과학자 그리고 심지어 농구선수들까지도 "in the zone"상태가 있음을 이야기할 것입니다.
문제는 "zone"으로 들어가는 것이 쉽지 않다는 것입니다. 측정해보면, 최상의 생산성으로 일을 하기 위해서는 평균 15분이 걸립니다. 하지만 어떤 경우에는 피곤하고 이미 많은 일을 한 상태에서 "zone"상태에 들어가지 못하고 다른 일을 하거나 웹서핑이나 테트리스로 시간을 허비하게 될 수도 있습니다.
또다른 문제는 "zone"상태에서 빠져나가는 것이 매우 쉽다는 것입니다. 잡음, 전화소리, 점심식사, 잠시 스타벅스에 5분간 갔다오는 것 그리고 특히 동료에 의한 방해등에 의해 바로 "zone"에서 빠져나가게 됩니다. 동료가 1분이라는 짧은 시간 동안이라도 질문을 하여 "zone"상태에서 빠져나간다면 다시 되돌아가기 위해서 30분이 넘는 시간이 걸려 전체 효율에 치명적인 영향을 미칠 수 있습니다. 카페인 가득한 닷컴 회사들이 좋아하는 합숙소같은 곳에 옆의 마케팅 부서에서 계속해서 오는 전화에 대고 소리지르는 그런 시끄러운 환경이라면 계속된 방해로 지식 근로자들의 생산성은 추락하여 "zone"상태에 절대 이르지 못할 수도 있습니다.
프로그래머들에게 있어서 특히 어렵습니다. 생산성은 단기적인 기억력으로 한번에 얼마나 많은 작은 세부사항들을 다루느냐에 달려있습니다. 어떠한 방해도 이런 세부사항들을 잊어버리게 할 수 있습니다. 일을 다시 재개하면 그것들을 다시 기억하지 못하여 (사용하던 지역변수나 검색 알고리즘을 만들던 중에 어디에서 멈줬었는지등) 다시 찾아보게 되고, 이로 인해 다시 속도가 붙을때까지 느려지게 됩니다.
직관적으로 계산해보면 다음과 같습니다. 만일 프로그래머가 단 1분이라도 방해를 받아서(명백한 근거에 의해) 15분의 생산성을 날려버린다고 합시다. 철수와 영희 두 프로그래머가 낮은 칸막이로 주욱 늘어선(a standard Dilbert veal-fattening farm) 열린 사각 파티션 옆자리에 앉아 있다고 합시다. 영희가 strcpy함수의 유니코드 버젼 이름을 잊었습니다. 30초면 찾아볼 수 있겠지만, 철수한테 물어보면 15초가 걸립니다. 그래서 바로 옆에 앉아 있는 철수에게 묻습니다. 철수는 산만해지고 - 영희의 15초를 아끼기 위해 - 15분을 낭비하게 됩니다.
이번에는 벽과 문으로 나뉘어진 별도의 사무실로 가정을 합시다. 여전히 영희는 함수를 기억하지 못합니다. 다시 찾아보는 것으로 30초를 보낼 수 있을 것이고 옆 방에 있는 철수에게 물어보기 위해서 (일반적인 프로그래머의 평균 물리적인 건강상태를 봐서는 쉽지 않은) 일어나서 걷는 것을 포함한 45초를 보낼 수 있을 것입니다. 결국 찾아보는 것을 선택하여 30초를 보내게 되지만 철수의 15분을 벌어주게 됩니다. 대단하죠!
9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
컴파일 되는 언어로 코드를 작성하는 것은 여전히 아무 PC에서 할 수 없는 것 중의 하나입니다. 컴파일을 하는데 몇초 이상 걸린다면 최상의 기종을 사용함으로써 시간을 절약할 수 있을 것입니다. 15초 이상 걸린다면 지루해서 그 시간동안 The Onion을 읽게 될 것이고 너무 재미있는 관계로 거기에 빠져 수시간의 생산성을 날려버릴 것입니다.
모니터 하나로 GUI코드를 디버깅한 것은 불가능하지는 않지만 고통스러운 작업입니다. GUI코드를 작성하고 있다면, 2대의 모니터로 훨씬 쉬운 작업을 할 수 있을 것입니다.
대개의 프로그래머들은 아이콘이나 툴바를 위해 비트맵을 수정해야하고 대부분의 프로그래머 역시 좋은 비트맵 에디터를 가지고 있지 않습니다. 마이크로소프트에서 기본적으로 제공하는 Paint 프로그램으로 비트맵을 수정하는 것은 웃긴 일이지만 대부분 이렇게 하고 있습니다.
필자의 가장 최근 직장에서 시스템 관리자가 계속해서 자동적으로 스팸을 보냈습니다. 이유인 즉슨 220MB이상의 하드드라이브를 사용하고 있다는 것이었습니다. 필자는 요즘 HD가격을 본다면 이 공간의 환산된 가격은 내가 이용하는 화장실 휴지보다 싸다는 것을 지적했습니다. 디렉토리를 정리하기 위해 10분을 허비하는 정도로도 큰 생산성 저하일 것입니다.
"최고의 개발팀은 절대 그들의 프로그래머들을 고문하지 않습니다!" 후진 제품으로 인한 작은 불편함이 쌓여서 프로그래머들이 불만에 찰 수도 있습니다. 그리고 그로 인한 불만에 찬 프로그래머는 비생산적인 프로그래머이기 쉬울 것입니다.
이런 것들을 모두 종합하면 프로그래머들은 최고/최신의 것들로 쉽게 매수된다는 뜻이 됩니다. 이는 높은 연봉을 주는 것보다는 훨씬 싼 방법일 것입니다!
10. 테스터들을 고용하고 있습니까?
팀이 최소한 2~3명의 프로그래머에게 테스팅만 전담하는 테스터가 할당되어 있지 않다면, 버그가 많은 제품을 출하하고 있거나 시간당 $100짜리 프로그래머에게 시간당 $30의 일을 시키는 낭비를 하고 있는 것입니다. 테스터를 고용하는 것이 낭비로 생각하는 것은 정말 잘못된 계산을 하고 있는 것이며, 많은 사람들이 이를 깨닫지 못하고 있는데에 놀랍니다.
이에 관해 더 자세히 알고자 한다면 Top Five (Wrong) Reasons You Don't Have Testers 를 읽으십시오.
11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
마법사를 고용하는데 그의 마법을 보지 않고 고용하시겠습니까? 당연히 그렇지 않겠죠.
결혼식에 요리사를 고용하는데 요리사가 만든 요리의 맛도 모르고 고용하시겠습니까? 그렇지 않을것입니다.(역자주: 실제로 결혼식장 요리사의 맛을 보는 비유는 우리나라에 맞지 않을 것 같네요. 이 문구의 뜻만 이해하세요)
하지만 현실에서는 매일 인상적인 이력서나 면접에서 맘에 든 이유로 고용하는 일들이 일어납니다. 혹은 ("CreateDialog()와 DialogBox()의 차이점은 무엇입니까")등의 문서만 보면 알 수 있는 사소한 질문으로 채용하기도 합니다. 프로그래머를 채용하는데 있어서 중요한 것은 그런 사소한 것들을 얼마나 많이 외웠느냐가 아니고 코드를 잘 작성할 수 있느냐입니다. 혹은 "아하!"류의 질문으로 채용하기도 합니다. "아하!"류의 질문이란 답을 알면 간단하지만 모르는 경우에는 절대 맞출 수 없는 질문을 이야기합니다.
제발 이런 방식을 그만 두십시오. 면접때 무얼해도 상관없지만 반드시 코드를 작성하도록 해야합니다.(더 많은 것을 알고 싶다면 Guerrilla Guide to Interviewing를 읽으십시오)
12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?
무작위 사용성 테스트(hallway usability test)는 복도를 지나가는 다음 사람을 붙잡고 방금 짠 코드를 사용하게 하는 방식입니다. 5명에게 이 테스트를 한다면 95%의 사용성 문제에 대해 배울 수 있을 것입니다.
좋은 사용자 인터페이스 설계는 생각처럼 어려운 것이 아니고 사용자들이 당신의 제품을 구입하고 사용하게 하는데 있어서 절대적으로 중요합니다. 짧은 프로그래머 입문서로 UI 설계에 관해 필자가 쓴 무료 온라인 책을 읽어보실 수 있습니다.
하지만 사용자 인터페이스에서 제일 중요한 것은 많은 사람들에게 당신의 프로그램을 보여주면(5~6명이면 충분합니다) 제일 큰 문제점을 빠른 시간에 발견할 수 있다는 것입니다. Jakob Nielsen의 글에서 그 이유에 대한 설명을 찾을 수 있습니다. UI 설계 경험이 별로 없다고 하더라도 - 비용이 전혀 들지 않는 - 무작위 사용성 테스트를 한다면 당신의 UI는 훨씬 좋아질 것입니다.
Joel Test를 사용하는 4가지 방식
- 자신이 속한 소프트웨어 팀의 점수를 매기고 그것에 대해 언급할 수 있도록 결과에 대한 이유를 필자에게 알려주십시오.
- 프로그래머 팀의 관리자라면, 당신의 팀이 최대한 잘 운영될 수 있는지 확인할 수 있는 지표로 사용하십시오. 12점을 받기 시작하면 프로그래머들을 간섭없이 그냥 두고 비즈니스쪽 사람들이 그들을 간섭하지 못하게 하는데에 모든 시간을 할 수 있습니다.
- 프로그래머 일을 맡을지를 결정해야하는 상황이라면 그 팀의 친한 사람에게 이 테스트 결과가 어떤지를 물어보십시오. 결과 점수가 너무 낮다면 이를 고칠 수 있는 권한을 받을 것인지를 확인하십시오. 그렇지 않으면 불만과 스트레스에 빠질 것입니다.
- 프로그래밍 팀을 평가하여야 하는 투자자이거나 당신의 회사가 다른 소프트웨어 회사와 합병을 한다면 이 평가가 급한대로 괜찮은 지표가 될 것입니다.
임진왜란의 오류
출처 : 오유 (자세한 링크를 까먹었네요)
임진왜란의 오류
제가 아주흥미로운 얘기해드릴께요
제가 아주흥미로운 얘기해드릴께요
이건 역사왜곡일수도있는 우리들이 알고있는 역사와
많이 다른 내용의 역사입니다 이것이 사실이라면 정말 정부고관들
역사책 다시써야합니다,,
임진왜란은 이순신의 전쟁이었다!
1592년(선조 25)부터 1598년까지 지리멸렬 하게 벌여졌던 임진왜란은 이순신과 왜의 전쟁이었다. 조선의 관군과 명군은 거의 한일이 없다고 봐야 한다. 결정적으로 왜가 퇴각을 한 것은 이순신, 이 단 한사람에 의해서이다.
정말로 조선은 왜의 침략을 사전에 몰랐을까?
당시 조선의 조정은 동인과 서인으로 나뉘어 왜의 조선침략에 서로 다른 의견을 내게 된다. 그래서 당쟁의 분열로 일본의 침략을 대비하지 못하게 되었다고 우리는 배웠지만 이것은 제대로 된 역사의 실상이 아니다. 대마도 도주나 여러 루트를 통해서 조선의 조정은 왜 침략 정보를 끊임없이 귀찮게 받게된다. 그래서 조선의 조정도 바보가 아닌 이상 서둘러 왜 침략에 대비해 준비를 하게 된다. 틀림없이 왜의 침략은 없다고 주장을 한, 동인의 수장인 류성룡이 임진왜란을 방비하게 한 것이다. 부산성전투나, 동래성 전투, 우리가 알고 있는 이 전투에서의 이 성들은 류성룡의 지시로 임진왜란을 대비해서 축성된 것이다. 그래서 우리가 알고 있는 동래성, 부산성전투가 남아있는 것이다. 이성들은 그 이전에는 없던 새로 축조한 성들이었던 것이다. 이것에서 우리는 식민사학의 폐해를 볼 수 있다. 지긋지긋한 당쟁 때문에 조선이 망했고 그리고 또 임진왜란도 어이없이 당하게 되었다는 것이다.
이이가 주장한 10만양병을 준비 못 했을까?
당시 이이가 10만양병설을 주창한다. 그렇다면 임진왜란 당시 조선은 이이가 말한 10만을 준비 못해서 임진왜란에 어이없이 연전연패했을까? 그 답은 아니다. 당시 조선은 10만이상의 병력을 대비하고 있었다. 그 예가 용인전투이다. 용인전투는 너무나 치욕적인 전투이었기에 이 전투를 입에 담는 다는 것은 생각도 해볼 수 없고, 다만 불문율에 붙이고 있다.
그 용인 전투는 무엇인가? 조선은 경상, 충청, 전라의 삼도의 관군을 집결시켜 용인에 주둔시킨다. 그런데 용인에 모인 조선군의 숫자는 6만에서 10만까지 이르렀다. 10만을 대비하지 못해서 왜에게 허망하게 당했다라는 상식은 잘못된 역사의 상식이다.
이 전투에서 조선의 10만대군은 와키자카의 천명에 의해 무참히 대패를 당한다. 와키자카가 천명을 거느리고 기습을 감행한다. 왜군의 조총에 놀란 조선군은 도망가기에 바빴다. 1000명이 10만 대군을 쫓는 웃지 않을 수 없는 상황이 벌어진 것이다. 조선군은 조총에 맞아죽은 사람보다 조선군에 의해 밟혀 죽은 사람이 더 많았다.
이로인해 와키자카는 조선군을 허수아비로 생각한다. 왜군이 나타났다고 하면 무조건 도망가 버리는 겁쟁이로 인식한 것이다. 후에 와키자카는 이순신의 수군을 제압하라는 특명을 받고 바다로 나간다. 후에 바다에서 와키자카는 이순신 또한 오합지졸 조선의 장수로 생각한다. 왜놈만 보면 도망가기 바쁜 그런 한심한 조선의 장수로 생각한 것이다. 그의 이러한 생각은 한산해전에서 이순신 장군의 유인술에 걸려 참패를 당하는 꼴을 만들어 버린다. 조선수군이 거짓으로 도망가는 척을 하니까 와키자카는 그러면 그렇지 하면서 돌격을 하다가 이순신 장군의 학인진에 걸려 대패를 당하게 된다.
정말로 조선은 임진왜란을 대비하지 못 했을까?
류성룡은 나름대로 임진왜란을 소리 소문 없이 조용히 준비하였다. 당시의 선조는 병권을 가진, 누가 혹시라도 자신의 왕권을 침탈하지 않을까 하는 병적인 왕권 집착증을 가지고 있었다. 그래서 혹여 신하가 왜의 조선 침략이나 그로인한 병권 확립등의 간언을 하면 역적으로 몰아 파면를 하는 병적인 상황을 공공연히 벌이곤 하였다.
당시 조정은 대마도 도주의 보고등으로 왜의 조선침략은 기정사실임을 알게 된다. 그러나 병권확립의 최대 걸림돌은 선조였다. 그리하여 류성룡은 선조의 비위를 건드리지 않으면서 임진왜란을 준비한다. 이순신을 전라좌수사로 발령하고 남해지방에 성들을 축성케하고 나름대로 임진왜란을 준비한 것이다.
당시 이순신의 장군의 전라좌수영의 군세는 보잘 것 없었다. 함선은 25척 군사는 4000명에 지나지 않았고, 우리가 알고 있는 함포나 거북선, 판옥선은 없었다. 전부 이순신 스스로 만든 것이다.
이순신 장군은 왜의 침략은 대비하기 위해, 화포를 만들고, 개량하고, 함선을 건조하기 시작한다. 거북선과 판옥선, 그리고 함포, 화약등은 기존의 조선군의 이상의 것이었다. 이순신 장군에 의해 만들어진 것이다. 이순신 장군은 농사를 지어서 군량미도 확보해야 했다. 이순신은 장수를 넘어서 지도자수준의 경영의식을 가진 위인으로 보아야 한다.
이순신은 최초로 함대함전의 함포 전술을 고안해 낸다. 이제까지 함대함전이란 배를 맞대고 백병전을 치루는 것이었다. 그런데 이순신은 이것을 뛰어넘어 미래의 함포전을 예상하고 그에 알맞는 전술과 함포 사격 훈련 및 진법을 구상해 내었다.
평양에서 이순신 장군이 왜군을 무찌르다?
왜군은 조선의 동래성 부산성, 탄금대 전투이후 조선 함락은 시간 문제로 생각하고 장기전의 생각은 하지 않는다. 왜군의 전투방식은 도성을 함락시키고 상대방의 최고 지휘관을 처치하는 것이다. 그러니 왜군은 한양을 함락시키고 조선왕을 처치하면 전쟁이 끝나는 줄 알았다. 왜군은 기동전을 펼쳐, 단지 부산성을 함락한지 약 보름만에 한성을 점령하게 된다. 왜군은 기동전과 단기전에 필요한 의복, 군량, 화약등의 보급품만을 소지하고 있었기에, 그들은 한성에서 평양으로 도주한 조선왕을 쫓지 않고 16일 가량을 머무르게 된다. 보급을 기다린 것이다.
그들은 생각지도 않은 장기전에 휘말리게 된다. 일개국왕이 도성을 버리고 도망간다는 것은 왜군의 상식에는 없었기 때문이다. 왜국에서의 전투란 도성을 빼앗으면 그걸로 끝이다. 장수는 명예를 위해 도성과 함께 장렬히 최후를 맞이하는데 조선의 왕은 명예같은 건 없었던 것이다.
전쟁에서 보급은 전쟁의 승패를 판가름 짓는다. 과거에 나폴레옹이 러시아의 초토화 작전에 휘말리고 보급이 제대로 이루어 않아 러시아 원정에서 실패한다. 나폴레옹도 똑 같이 일주일 가량의 보급품만 유지한채 진격을 감행하였기 때문이다. 히틀러도 스탈린의 초토화 작전에 휘말리고 보급이 제대로 이루어지지 않아, 2차대전에서 패망하는 결과를 맛보게 된다.
왜군은 육로로 그들의 10만군대에게 보급을 한다는 것은 애당초 무리가 있기 때문에 그들이 가장 자신있어 하는 해상으로 보급을 추진하게 된다. 그러나 그들의 보급품은 이순의 장군의 옥포해전에 의해서 2000톤이나 되는 그들의 보급품과 보급선단이 그대로 바다로 수장하게 된다. 그들은 꼼짝없이 굶어죽게 된 것이다. 그러나 하늘이 도운 것일까? 정말로 현명한? 선조가 자기 몸만 빠져나오고, 고스란히 왜군에게 군량미 10만석을 넘겨주게 된다. 굶어 죽게 될 왜군을 조선 선조가 먹여살린 것이다. 아사직전의 왜군을 선조가 살려준 것이다. 그러나 10만석도 10만명에겐 궁여지책이다.
왜군은 평양까지 진격하고 평양에서 더 이상 진격을 못한다. 이유는 간단하다. 식량과 화약등의 보급이 절대로 부족했기 때문이다. 그러나 동쪽방면으로는 함경도까지 다다른다. 동쪽 방면의 왜군은 거칠 것이 없었다. 그것은 동쪽 해상의 보급은 제대로 이루어 졌기 때문이었다. 그만큼 보급이 전투에 절대적인 영향을 미친다.
평양의 왜군을 명나라가 패퇴시켰다는 것은 정말 잘못된 역사의 상식이다. 명군은 조선군보다도 형편없는 전투력에, 전쟁수행 능력도 보잘 것 없는, 한 마디로 거지 집단이었다. 그들의 나라사정도 말이 아니었기에 그들의 보급에 필요한 식량과 군수품을 대줄 형편이 안되었다. 그래서 후에 명나라는 겨우 5만을 조선에 보내놓고 나라가 휘청 휘청거리다가, 결국은 패망하게 된다. 명나라 군대는 이렇다할 전투를 한 적이 없다. 제대로 치른 전투는 평양성 전투가 처음이자 마지막이다. 명군은 조선의 충고를 듣지도 않고 왜군을 얕잡아 본채 평양성을 공격하다가 참패를 당하게 된다. 평양성 전투이후 명군은 왜군을 보곤 겁을 먹고 이렇다할 전투는 벌이지 못하고 군량미만 축낸다. 조선왕을 괴롭히는 일개 거지 집단에 지나지 않았던 것이다.
평양에서 왜군이 후퇴를 하게 되는데 그들을 물리친 것은 명군도 아니고 선조의 조선육군도 아니었다. 바로 동장군과 이순신 장군의 활약에 의한 보급로 봉쇄였다. 왜인들은 조선 평안도의 겨울을 경험해본적도 없었고, 그리고 겨울옷이란 것은 애초에 있지도 않았다. 그 때의 상황에 대해 왜병 요시노 진고자에몬은 후에 그의 일기를 통하여 생생하게 증언하고 있다.
“이 날 밤은 북풍이 몹시 불었다. 추위는 살을 에는 듯하였고, 인간의 지각을 모두 앗아가는 듯하였다. 동상에 걸린 병사들은 지팡이 대신 활을 잡지도 못할 정도였고, 막대기가 다 된 다리를 그저 몽유병자처럼 질질 끌고 갈 뿐이었다. 그렇게라도 하지 않으면 동사(凍死)나 아사(餓死)라는 죽음만이 길가에서 커다란 아가리를 벌리고 기다리고 있었기 때문이었다....”
“이 날 밤은 북풍이 몹시 불었다. 추위는 살을 에는 듯하였고, 인간의 지각을 모두 앗아가는 듯하였다. 동상에 걸린 병사들은 지팡이 대신 활을 잡지도 못할 정도였고, 막대기가 다 된 다리를 그저 몽유병자처럼 질질 끌고 갈 뿐이었다. 그렇게라도 하지 않으면 동사(凍死)나 아사(餓死)라는 죽음만이 길가에서 커다란 아가리를 벌리고 기다리고 있었기 때문이었다....”
왜군은 한성으로 철군도중 무려 1400명이 죽고 살아남은 자가 6600명에 지나지 않았다.
이순신 장군 행주산성에서 권율을 도와 승리로 이끌다?
권율의 행주대첩도 왜군이 만약 보급이 제대로 이루어지고 계절이 여름이었다면 있을 수 없었던 것이다.
왜군은 동장군을 피하고 먹을 것을 찾기 위해 남으로 남으로 후퇴하고 성을 쌓고 성안에서 무려 4년을 기다린다.
이때 왜군이 후퇴할 당시 명군은 왜군과 정치적 교섭을 하여 그들의 안전한 퇴로를 약속해준다. 조선의 선조 또한 왕자등의 인질문제로 안전한 퇴로를 보장한다. 왜군이 성안에 틀여박혀 수세에 몰릴때 명군과 조선의 육군은 공성전을 벌인다던가, 성을 짓는 것을 방해하는 일도 하지 않는다. 왜군이 성을 다 짓고 나서도 4년동안 가만 놔둔다.
이순신을 죽이려 했던 것은 왜군이 아닌 선조였다!
왜군은 4년후 정유년에 그들의 패전의 원인을 철저히 인식하고 이순신을 제거하는 것에 온갖 방법을 강구한다.
전투로는 이순신을 제거하지 못하니, 선조의 병적인 쿠테타 망상증을 이용한다.
왜장 유키나가가 권율에게 이제 바다를 통해 쳐들어 간다고 선전포고를 한다. 이에 권율이 조정에 그대로 보고를 한다. (권율을 냉철하게 다시 역사적 재평가를 해보아야 한다.) 선조는 권율을 통해 바로 이순신에게 출전명령을 내리고 유키나가를 바다에서 잡을 것을 명령한다. 정말 한심하기 그지 없다. 내가 쳐들어 간다고 적에게 미리 알리는 착한 적도 없거니와, 적의 말을 믿고, 아군의 말을 믿지 못하는 한심한 왕도 없을 것이다.
이순신은 적의 계략에 놀아나지 않고 자리를 지킨다. 왜군은 정유재란을 준비하면서 이순신 수군의 판옥선에 대응하는 대형함선을 건조한다. 대형함선등을 합쳐 약 2000척의 함선을 준비한다.
이순신의 수군과 왜군은 견내량을 사이에 두고 팽팽한 대치상황을 벌이고 있었다. 이 대치상황에서 먼저 나서는 자가 지는 것은 자명한 사실이었고, 더욱이나 조선의 함선은 250척에 지나지 않았기에 먼저 공격해 들어간다는 것은 더욱 무리였다.
후에 원균도 이러한 상황을 알고 있었기에 쳐들어 가지 못하고 있었다. 그런데 같은 사령관의 지위임에도 불구하고 권율이 원균을 불려들어 곤장을 치고 압박을 가한다. 이에 원균은 마지못해 출진을 하게 되고 참담한 패배를 당한다. 권율은 용인전투에서도 10만의 대군을 잃었고, 여기에서도 250척의 판옥선과 거북선을 모두 잃는다. 권율을 조선을 구한 구국의 영웅으로 보는 것은 타당하지 않다. 그는 조선의 선조 비위나 맞추는 일개 평범한 조선의 장수에 지나지 않았던 것이다.
적의 계략임이 밝혀진 이후에도 선조는 왕명을 거역한 죄로, 이순신을 사형까지 집행하려 한다. 유능한 장수와 한 나라에 같이 있다는 것은 자신의 왕권을 위협하고 언젠가는 왕위를 찬탈할 것이라는 망상에 늘 젖어 있었기 때문이다. 선조는 이를 기회를 삼아 제거를 꾀한 것이다. 그러나 대소신려들의 만류로 사형집행만은 이루어지지 않고 백의 종군하게 된다.
이순신을 손쉽게 피한방울 흘리지 않고 제거한 왜군은 파죽지세로 전라도를 점령하고 서해를 통해 북상하기 시작한다. 그러나 백의종군한 이순신은 불과 12척의 함선으로 왜의 200척을 쳐부수는 명랑대첩의 신화를 이룬다.
명랑대첩이후 왜군은 전의를 상실하고 퇴각을 서두르게 된다.
이순신 장군 왕명을 거역하고 왜군을 공격하다!
노량에서 왜군은 일본으로 철수를 하려하지만 이순신이 뒤에서 해상을 봉쇄하고 있어서 철수를 하지 못하고 또 다시 동장군과 굶주림을 떠올리며 경악하게 된다. 그러나 이 해상봉쇄를 풀어 왜군의 안전한 퇴각을 명군과 선조는 보장하려 한다. 또 다시 선조는 적을 안전하게 돌려보내라는 웃지 못할 왕명을 내리고, 또 다시 이순신은 왕명을 거역하고 적에게 달려들어 마지막 왜란의 전투를 치른다. 이것이 노량해전이다.
이전투 이후 이순신에게 남은 것은 선조의 사형집행 명령 뿐이었다. 이순신에게 남은 것은 세장의 카드가 있었다. 자신이 사형을 당하던가! 새로운 왕조를 열어나가던가! 적에게 죽던가! 이순신은 충의의 장군이었다! 왕권을 찬탈하는 것은 생각도 할 수 없었고, 다만 적에게 죽는 것을 택할 수밖에 없었다.
이전투 이후 이순신에게 남은 것은 선조의 사형집행 명령 뿐이었다. 이순신에게 남은 것은 세장의 카드가 있었다. 자신이 사형을 당하던가! 새로운 왕조를 열어나가던가! 적에게 죽던가! 이순신은 충의의 장군이었다! 왕권을 찬탈하는 것은 생각도 할 수 없었고, 다만 적에게 죽는 것을 택할 수밖에 없었다.
만약 이순신이 일말의 다른 생각을 품었다면 역사는 달라졌을 것이다. 권율휘하의 조선 육군은 5000명에 불과 하였으나 이순신 휘하의 수군은 3만명에 이르렀다. 이순신의 수군은 자체적으로 개량한 각종 화기와 조총을 구비하고 있었고, 조선의 백성과 수군은 이순신에 대한 존경심과 충성심으로 불타오르고 있었다.
이순신 장군을 트라팔가 해전의 넬슨과 비교하는 것은 망발이다. 이순신 장군은 함선도 무기도 스스로 만들고 농사를 지으면서 군량비도 스스로 자급해야 했다. 이순신은 일개 넬슨같은 제독이 아니라, 리더쉽과 자질을 갖춘 비운의 지도자였다.
지식인에서 퍼왔습니다.
저는 마지막의 말이 사실이라면 이순신을 조금 원망할지도 모릅니다.
만약 이순신 같은 사람이 왕이 되었더라면
그래도 일제에게 지배 당할 정도로
정치나 기술이 낙후되어 있진 않았을테니까요.
역시 지배자는 잘난 사람이 되어야 되나 봅니다.
만약 이순신 같은 사람이 왕이 되었더라면
그래도 일제에게 지배 당할 정도로
정치나 기술이 낙후되어 있진 않았을테니까요.
역시 지배자는 잘난 사람이 되어야 되나 봅니다.
------------------------------------------------------------------
오직 왕권밖에 눈에 안들어와서 똥인지 된장인지도 구별 못하는 꼴통 임금.
자기만 살겠다고 나라를 통째로 명나라에 들어바치려했던 꼴통 임금.
충신과 간신, 적과 아군도 구별 못하는 꼴통 임금.
적을 이롭게하는 꼴통 임금.
이런 꼴통을 왕이라고 모시던 신하들과 백성들이 불쌍타....
피드 구독하기:
글 (Atom)