천객만래 [千客萬來] (It has an interminable succession of visitors)

SW 개발자의 길, 아니다 싶으면 포기하라!




20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다.
Posted by SB패밀리

Visual Studio 2008 에서 컴파일할 때 자꾸 발생하는 현상이다.
그것도 한 번씩 새로 컴파일할 때마다 발생하고 다시 빌드가 된다.
비주얼 스튜디오 2008에서 "LINK : fatal error LNK1000: Internal error during IncrBuildImage" 가 계속 발생한다면 서비스팩 1(Service Pack 1:SP1)을 설치하면 해결이 된다고 한다.

그래서 나도 설치하려고 한다. 혹시나 영문판을 사용중이라면 서비스 팩 또한 영문버전으로 설치하기 바란다.

Microsoft Visual Studio 2008 Service Pack 1(iso)
http://www.microsoft.com/downloads/ko-kr/details.aspx?familyid=27673C47-B3B5-4C67-BD99-84E525B5CE61&displaylang=ko



아래는 참고로 비주얼 스튜디오 2010 서비스 팩 1 이다.
http://www.microsoft.com/downloads/ko-kr/details.aspx?FamilyID=75568AA6-8107-475D-948A-EF22627E57A5
Posted by SB패밀리

재미있는 5대 IT 기업명 유래

마이크로소프트


마이크로소프트는 빌 게이츠의 선견지명이 드러난 사명이다. 그가 회사를 창업한 1975년만 해도 건물의 벽 전체를 차지하는 대형컴퓨터를 떠올리기 마련이었지만 빌게이츠는 소형컴퓨터의 미래를 예상하고 회사의 이름에 아주 작은 것을 뜻하는 마이크로(Micro)라는 단어를 넣었다.

또한 컴퓨터와 프로그램이라는 개념만 존재했을 때 사명에 소프트웨어를 전면에 내세웠다. 그가 회사를 창립했던 1975년도에 이 회사명은 사람들에게 희귀하고 생소한 전문적인 용어였다. 회사명 때문에 마이크로소프트는 한때 사람들로부터 작고 부드러운 아이스크림을 만드는 회사로 오인을 받아야 할 정도였다.

애플


스티브 잡스가 애플이라는 회사 이름을 떠올린 이유는 그가 청년 시절 아르바이트를 했던 사과농장에서의 즐거운 추억 덕분이었다. 또한 애플이라는 이름을 확정한 것은 전화번호 리스트에서 아타리(Atari)보다 앞에 있다는 점이 마음에 들었기 때문이었다. 참고로 아타리는 바둑 용어인 단수(單手)의 일본식 발음이다.

구글


래리 페이지와 세르게이 브린이 처음 검색서비스를 할 때는 백럽이라고 불렀다. 하지만 검색 서비스 인기가 높아지자 좀 더 친숙하면서 의미가 있는 이름을 찾으려고 했다. 검색엔진 작업에 참여하고 있는 대학원생들과 함께 메신저를 통해 새로운 이름을 고민했다.

이때 마침 동료 중 하나가 10의 100제곱을 뜻하는 의미가 있다는 구글(Google)을 제안했다. 1에 0이 백개 붙여있는 어마어마한 숫자를 뜻하는 구글이 검색서비스의 거대함, 방대함과 일맥상통해 래리와 세르게이는 구글로 이름을 결정했다. 며칠이 지나서야 원래 10의 100제곱을 뜻하는 단어는 구글이 아니라 구골(GooGol)이라는 사실을 알게 됐지만 두 사람은 구글이 마음에 너무 들어 계속 구글을 사용했다.

인텔


처음 로버트 노이스와 고든 무어는 회사명으로 자신들의 이름을 따서 노이스-무어 일렉트로닉스(Noyce-Moore Electronics)로 정했다. 하지만 사람들이 잡음을 뜻하는 노이즈(Noise)와 많다를 뜻하는 모어(More)의 합성어로 헷갈려 부정적인 이미지의 노이즈 무어, 즉 “잡음이 많다”를 떠올렸다.

하는 수 없이 그들은 새로운 회사 이름을 찾아야 했다. 그들의 전문분야인 전자 집적회로를 표현하기 위해 통합을 뜻하는 인터그레이트(Integrate)와 전자를 의미하는 일렉트로닉스(Electronics) 두 단어의 앞 글자를 조합해 인텔(INTEL)이라고 정했다.

로버트 노이스는 새로운 회사명이 지적인 느낌의 인텔리전트(Intelligent)를 떠올린다고 생각해서 특히 좋아했다. 그런데 이미 호텔 체인사업을 하는 다른 회사에서 인텔코(Intelco)라는 사명을 가지고 있었다. 회사이름에 애착을 느낀 노이스는 인텔코에 1만 5,000달러를 주고 회사이름을 구입했다.

IBM


원래 IBM의 이름은 CTR이었고 컴퓨터와는 전혀 상관없는 사무기기 업체였다. 1914년 토마스 왓슨이 당시 적자에 허덕이던 CTR의 총책임자로 임명됐는데 그는 'Think'라는 슬로건을 내세워 회사의 기술혁신을 이뤄냈다. CTR의 부활은 해외시장에서의 활약이 컸다. 그래서 토마스 왓슨은 1924년 해외시장에서의 인지도 상승을 위해 사명을 IBM(International Business Machines)으로 바꿨다.

그 밖에 회사 유명 IT 기업들의 이름의 유래
모토로라는 원래 그들이 자동차에 들어가는 라디오를 전문으로 만드는 회사이기 때문에 모터(Motor)가 들어갔고 당시 라디오 회사이름의 끝에는 'ola'가 들어가는 게 유행이라 'Motorlola'가 되었다. 시스코(Cisco)는 샌프란시스코에서 따왔으며 야후는 걸리버 여행기에 나오는 야만족을 뜻한다


출처 : http://www.ebuzz.co.kr/content/buzz_view.html?uid=86720

쌈꼬쪼려 소백촌닭
Posted by SB패밀리

사진, 동영상, 작업 데이터, 중요한 데이터는 MS SyncToy로 간단히 설정해서 백업받거나 동기화할 수 있다.


출처 : http://technet.microsoft.com/ko-kr/magazine/2007.03.utilityspotlight.aspx


SyncToy
Jay Munro

이 기사의 코드 다운로드: SynctToy (971KB)

IT 전문가, 네트워크 관리자 및 기술 지원 부서 직원에게 있어서 가장 골치 아플 때는 백업도 마련해 두지 않은 상태에서 컴퓨터에 오류가 발생한 사용자로부터 지원 요청을 받을 때입니다. 컴퓨터에 대해 잘 안다는 사람들도 작업을 로컬뿐만 아니라 네트워크에 저장하는 습관을 기르는 것이 쉽지 않을 수 있습니다. SyncToy를 사용하면 이러한 경우에 도움이 됩니다.
카메라, 컴퓨터 및 외부 드라이브 간에 디지털 사진을 동기화할 목적으로 설계된 SyncToy는 거의 모든 종류의 파일을 백업하는 데 사용할 수 있는 융통성이 뛰어나고 안정적인 도구입니다. Windows Vista™는 물론 Windows® XP 및 Windows Server® 2003에서도 실행할 수 있는 SyncToy는 로컬 드라이브, 외부 드라이브, USB 드라이브는 물론 네트워크 공유 또는 작업 그룹 공유와도 잘 작동합니다.
SyncToy는 왼쪽 및 오른쪽 디렉터리로 구성된 쌍으로 된 폴더 구조를 사용합니다. 폴더 쌍은 원하는 만큼 얼마든지 만들 수 있으며 단추를 한 번만 클릭하여 한 폴더나 모든 폴더를 동기화할 수 있습니다. 폴더 쌍을 만들려면 4단계로 구성된 마법사를 단계별로 진행하여 왼쪽 및 오른쪽 폴더의 경로를 입력하거나 붙여 넣습니다. 폴더의 위치를 찾아볼 수도 있습니다. SyncToy는 UNC 파일 이름 지정(예: \\MyServer\Joe_smith\backup\)은 물론 로컬 드라이브 매핑과 경로(E:\doc_backup)를 인식합니다. 경로를 입력한 후에는 다음 다섯 가지 작업 중 하나를 선택합니다. 이 다섯 가지 작업은 SyncToy에서 폴더를 비교할 때 수행하는 작업입니다.
Sync 두 디렉터리 모두로 새로운 파일 및 업데이트된 파일을 복사합니다. 한 폴더에서 파일 이름을 바꾸거나 파일을 삭제한 경우에는 해당 작업 내용이 다른 폴더에 복제됩니다.
Echo 왼쪽 폴더에서 오른쪽 폴더로만 새로운 파일 및 업데이트된 파일을 복사하고 삭제 및 이름 바꾸기를 수행합니다.
Subscribe 왼쪽 폴더에 파일이 이미 있는 경우에만, 업데이트된 파일을 오른쪽 폴더에서 왼쪽 폴더로 복사합니다. 왼쪽 폴더의 변경 내용은 오른쪽 폴더로 복제되지 않습니다.
Contribute 왼쪽 폴더의 새로운 파일 및 업데이트된 파일을 오른쪽 폴더로 복사합니다. 삭제된 내용은 무시합니다.
Combine 한 폴더에는 있지만 다른 폴더에는 없는 파일을 복사하여 여러 컴퓨터를 동기화된 상태로 유지합니다. 두 폴더 중 하나에서 삭제되거나 이름이 바뀐 파일은 영향을 받거나 복제되지 않습니다.
작업을 선택한 후에는 폴더 쌍의 이름을 선택합니다. 현재까지는 SyncToy에서 폴더 쌍을 한번 만든 후에는 폴더 쌍의 경로를 편집하거나 이름을 변경할 수 없으므로 잘못 만든 경우에는 폴더 쌍을 선택하고 삭제를 클릭하여 폴더 쌍을 제거한 다음 다시 만듭니다. 포함할 파일 및 하위 디렉터리를 비롯하여 덮어쓴 파일을 휴지통에 저장할지 여부 등의 옵션도 설정할 수 있습니다. 기본적으로 덮어쓴 파일은 휴지통에 저장됩니다.
Synchronizing files with SyncToy(더 크게 보려면 이미지를 클릭하십시오.)

기본 SyncToy 대화 상자의 왼쪽에는 폴더 쌍과 함께 폴더 쌍의 경로와 폴더 쌍에 설정된 옵션 및 작업이 표시됩니다. All Folder Pairs 옵션은 모든 폴더 쌍을 나열합니다. 선택한 폴더 쌍에 대해 Preview나 Run All을 수행할 수 있습니다. Preview를 선택하면 실제로 동기화가 수행되는 것과 같이 일련의 동작이 일어나지만 실제로는 어떤 것도 변경되지 않습니다. 무인 동기화를 예약하려는 경우에는 이러한 미리 보기 기능이 상당히 유용합니다. 미리 보기를 수행하면 어떤 작업이 수행될지를 보여 주는 보고서가 표시됩니다. 보고서의 내용에 아무 문제가 없으면 Run을 클릭합니다.
예약 기능은 기본으로 제공되지 않습니다. 하지만 도움말 파일에서 Windows Vista와 Windows XP의 스케줄러를 사용하여 작업을 예약하는 단계를 볼 수 있습니다. 관련 지식이 없는 사용자의 경우 작업 예약을 설정하는 데 도움이 필요할 수도 있습니다. 하지만 한 번만 설정해 두면 폴더 쌍의 변경 내용, 작업 및 옵션은 SyncToy 자체에서 수행되므로 걱정할 필요가 없습니다.
모든 Power Toy와 마찬가지로 SyncToy도 일반적으로 제공되는 소프트웨어와 동일한 표준에 따라 작성되기는 했지만 Microsoft에서 별도로 지원하지는 않습니다. 도움이 필요하면 커뮤니티 포럼과 설명서를 참조하십시오. 모든 것을 직접 해결해야 합니다. 도움말 파일은 모든 수준의 사용자에 맞게 작성되었으며 관련 기능을 매우 자세하게 다룹니다. UI는 처음 보면 기본 기능을 금방 이해할 수 있을 정도로 직관적입니다.
이제 SyncToy를 다운로드하여 사용자에게 파일을 백업하는 방법을 보여 주십시오. 그러면 한밤중에 지원 요청을 받는 일 없이 숙면을 취할 수 있을 것입니다.
Posted by SB패밀리