요즘 지상파 방송사에서 방영하는 사회화와 관련된 동물 다큐멘터리를 보면, 똑똑한 동물이라 할지라도, 후손에게 가르칠 수 있는 지적 능력이 존재하지 않기에 후손에게 학습을 시키는 동물은 사람밖에 없구나 하는 생각이 든다.
후손에 가르칠 수 있는 능력은 인간에게 주어진 축복이구나 하는 생각이 든다.

머리가 뛰어나다는 원숭이와 개에게 꾸준한 반복된 학습의 효과는 그 개체에 한정되어 있다.
어느 조직이든 그 조직에서 뛰어난 사람은 자연스럽게 존재한다.하지만 뛰어난 사람을 통해서 조직 자체가 뛰어나기까지는 시간이 걸리는 듯 하다.

즉, 조직이 뛰어난 것은 뛰어난 사람이 많은 것보다는 조직의 비전을 위해서 조직원 하나하나가 뚜렷한 비전을 보고
성공적인 임무를 수행하는 것을 말한다.어떻게 하면, 뛰어난 조직이 될 수 있을까? 뛰어난 사람이 없다면, 조직이 뛰어나기는 힘들고,뛰어난 사람이 있으면, 조직이 뛰어난 사람에 의해서 좌지우지 할 수 있는 가능성도 많다. 뛰어난 사람이 나가버리면, 조직은 와해되는 경우도 많다는 것은 다들 아는 사실일 것이다.

대안의 하나로서, 커뮤니케이션을 기반으로 하는 학습이다.

뛰어난 조직을 이루기 위해서는 조직원 자체가 배운 것을 유지하고, 새로운 것을 학습하고, 학습된 지식과 경험을 공유하며, 커뮤니케이션 활발화를 통해서 타인의 경험을 조직원 각자에게 간접체험을 통해서 겪도록 하고, 새로운 것이나 해야할 업무에 두려움을 최소화시켜야 한다.

또한, 커뮤니케이션은 조직원 모두에게 친근감을 줄 수 있는 수단으로서 좋은 방법이 될 수 있다. 저녁에 술을 먹을 때 커뮤니케이션이 일어나는 것이 아니라, 일과 시간에 틈틈히 조직의 각자 구성원간에 편한 커뮤니케이션을 통해서 친근감을 최대한 가지도록 하는 것이 필요하다.

조직에 갓 들어온 소프트웨어 엔지니어가 회사에 적응하지 못하고 사라지는 이유는 일이 힘든 이유가 있겠지만,
당장 필요로 하는 일을 배우지 못해서 끙끙대는 이유가 많은 듯 하다. 개발하면서 부딪히는 문제에 대해서 처리하는 것을 선임자가 봐주지 못하고, 유닛 테스트, 컴파일 하는 법, 디버깅하는 법을 간단히 듣거나 혼자서 해결해야 상황이 자주 생기는 듯 하다. 최소 3개월정도는 현장에 투입하지 않고, 회사와 팀의 커뮤니케이션하는 주류에 끼도록 하고, 기본적인 대처방법을 가르쳐 주어야 한다.

또한, 초보 소프트웨어 엔지니어는 반드시 겸허한 마음으로 도그마에 빠지지 말고, 넓게 보는 시각을 보고, 팀에 빨리 적응해야 한다. 너무 수동적인 엔지니어일수록 주위의 도움을 받기 어려운 부분이 존재한다. 아주 잘하는 고수가 아닌 이상은 빨리 성격을 고쳐서 배우고 물어봐 실력을 쌓는 것이 중요하다.

이런 과정의 조직과 구성원간의 피드백을 통해서 커뮤니케이션이 자연스럽게 증가되고, 친밀감이 형성시켜 서로 돕고 도울 수 있는 자연스러운 관계가 되도록 노력해야 할 것이다.

학부시절때 배웠던 컴퓨터 구조, 운영체제, 컴파일러 1장을 보면, 간단한 컴퓨터 및 컴퓨터 과학의 역사가 나옵니다. 그리고, 기사자격증을 따야 할 시기가 오면, 다시 한번 역사를 공부하게 됩니다. 1세대는 진공관이니... 머니 하면서 외우기 시작합니다.

 

깊은 전공 공부가 시작되면서 왜 이렇게 복잡스러운지.. 게다가 소프트웨어 공학은 뜬 구름같기도 하고요, UML은 현장에서 잘 쓰이지 않을 꺼 같은 생각에 내가 공부하고 있는 것이 잘 하고 있는 건지.. 괴리감에 빠져 있었던 것이 하루 이틀이 아니었습니다.

 

이미 누군가가 만들어 놓은 체계를 무작정 공부하는 것이 힘든 적이 있었습니다. 그리고, 작년에는 제가 하고 있는 일 자체에 회의를 느끼기도 했었지요. 과연 나는 내가 하고 있는 일에서 어떤 일을 하고 있는지, 얼마나 할 수 있는지 고민을 많이 하던 2005년이었습니다.

 

마음을 잡고, 새롭게 시작하는 마음으로 내 앞에 있던 많은 사람들의 글을 보기 시작했습니다. 회사에 처음들어왔던, 아니. 대학에 처음에 들어와 공부를 막 시작했을 때의 기분을 다시 느껴보고 싶었습니다. 정말 처음과 같은 마음으로 되돌아 가고 싶었습니다.

 

단순히 세금 계산을 쉽게 하는 계산기를 만들고 싶은 괴짜 찰스 베비지, 전쟁을 통해서 역작을 만든 마라톤에 심취한 튜링과 튜링의 어머니가 쓴 튜링의 전기과 새년, 병렬처리 구조의 문제점때문에 순차처리 구조방법을 고안한 폰 노이만외 21명의 인물들의 얘기를 즐겁게 볼 수 있었습니다.

 

셈, 컴퓨터, 컴퓨터 언어, 소프트웨어 공학이 나오기까지 많은 인물들의 이야기를 보면서 어록의 의미를 되새겨 보는 좋은 기회를 갖게 되었습니다. 특히 브룩스의 "인월의 신화 늑대 인간을 쏜 은의 탄환은 없다"라는 책 제목의 배경을 알게 된 것, 80세가 넘는 IBM 360 시스템을 디자인한 암달이 지금도 연구를 하고 있다라는 문구는 상당히 인상적었습니다.

 

사람이 가지는 열정이야말로 세상을 뒤바꾸는 힘이라는 것을 깨닫게 됩니다. 누가 머라고 하건, 자기가 옳다고 재미있다고 하는 것에 열정을 품는 모습이 상당히 인상적이었습니다.

그리고, 저자가 얘기하고 싶어하는 결론은 자신의 척도를 잘 확립하라고, 주위의 평가와 회사의 평가를 신경쓰지 말고, 자신의 평가기준을 스스로 만들어 존재이유를 뚜렷히 하여 허세도 비하도 아닌 다이즈크스트라의 '당신 만이 할 수 있는 일을 하라' 라는 말을 던지며 도전의식을 전하고 있습니다.

힘들고 지치고, 그 누구보다도 가슴 뜨거운 소프트웨어 엔지니어들~ 힘냅시다!!

해커에 대한 진부한 이야기가 아닌 사회, 교육학 측면에서 바라보는 시각입니다. 역자가 서문에서  "신선한 시각에서 바라본 책"이라고 평을 하면서 시작되는 책입니다. 역자는 그 유명하신(?) 임백준씨입니다.

역자가 서문에서 상기와 같이 "신선한 시각에서 바라본 책"이라고 쓴 이유는 치열한 해커의 열정, 왕따의 공부벌레의 열정은 반드시 성공하리라 생각하는 마인드일꺼라 생각이 듭니다.

틀에 박힌 사람은 그 이상의 틀을 벗어날 수 없습니다. 해커의 기본 법칙인 "해커는 법칙을 깨뜨렸을 때 승리한다"라는 사실을 강조하고 있습니다. 상식을 깨는 사람이 성공한다~ 이 말은 자주 듣죠?

IT에 들어서는 순간, 돈을 벌지 못하는 앵벌이다. 그런 말을 자주 듣지 않습니까? 요즘 KLDP에 보니, 부정적인 시각이 많이 있네요. 또한 후배 고등학생들은 이과를 선택안하는 세상이라, 공대생이 되는 순간, 성공하지 못하는 인생길로 생각합니다.

이 책은 부자가 되는 길은 바로 부를 축적하는 것을 말합니다. 상당히 철학이 있는 말이죠. 부 != 돈 이라는 등식인 겁니다. 부는 돈이 많음을 뜻하는 것이 아니라, 돈은 부를 움직이기 위한 수단이라는 것을 강조하고 있습니다. 부를 창출할 수 있는 사람은 즉 파이를 만들어 키우는 사람은 장인이라는 것을 포커스를 두고 있습니다. 창출할 수 있는 무언가나 위치를 움직임으로서 부를 얻는 것을 말하고 있습니다.

역사적으로 부를 창출한 사람은 시대의 흐름에 있어서 필요한 것을 만드는 사람, 즉 생산자임을 말하고 있습니다. 바로 스타트업을 하고, 그 스타트업이 비록 힘들더라도 몇 배의 노력(저자의 말에 의하면 10년 할 일을 2-3년만에 한다)을 해서 부를 창출할 수 있다라고 강조합니다.

테크놀리지, 이 새로운 흐름에 맞는 무언가를 만들어 소비하게 한다면 부를 얻을 것이라는 것외에 디자인이라는 또 다른 요소를 알려줍니다. "위대한 작품을 만드는 방법은 바로 자기 자신만의 미적 취향과 그것을 만족시킬 수 있는 능력에 달려 있는 것이다."라고요. 자신만의 설계 디자인 감각, 그리고 완벽을 추구하려 하며, 전보다 더 나은 작품을 만들고자 하는 열정(?)을 가르키는 것은 아닐까요?

프로그래밍 언어론에 대해서 나름대로 비교를 해 봅니다. 여러 언어중 리스프를 극찬합니다. 프로그램이 데이터처럼 취급되어 인공지능 언어로 분류되며, 함수 언어라고 알려져 있지요. 부끄럽지만, 저는 인공지능 수업을 듣다가 리스프 언어를 만나고 난 뒤 바로 드롭을 해버렸습니다. 너무나도 이해할 수 없는 언어라 참기 견디기 어려웠죠. 그 언어를 저자는 침이 마르게 칭찬합니다. 맥카시의 뜻을 잘 이은 사람인 듯 싶더라구요. 야후 쇼핑의 전신인 비아웹에서 언어의 일부분의 성능을 위해서 리스프를 사용했다고 합니다. 그러면서 장점을 부각을 합니다.

얼마전의 파이썬의 창시자(이름 못외웁니다...ㅡ.ㅡ)가 구글에 들어가 구글 검색엔진의 일부를 구현했다고 합니다. 이 일과 무관하지 않은 것입니다. 기존 언어가 할 수 없는 일을 해주는 언어, 오히려 복잡할 수 있는 부분이 풀릴 수 있는 일을 특정 언어로서 할 수 있는 것이겠지요. 예를 들어 자바위에 Pyton을 올리며 Jython이라 불리는 스크립트를 쓰는 것이라 생각할 수 있겠지요.

부끄럽지만, 저는 전에 언어 개발에 참여한 적이 있습니다. 새로운 언어입니다. 더이상 말하기는 어렵지만, 저는 얼마나 저의 무지를 배웠는 지 모릅니다. 그냥 이미 있는 기존의 언어를 사용하지, 왜 새로운 언어를 해야 하는 지 이해를 할 수 없었습니다. 하지만, 되돌아 생각해 보면 볼 때마다 귀한 경험이라고 생각합니다.

기존의 할 수 없던 일을 쉽게 할 수 있으며, 강력한 기능을 제공한다면, 새로운 언어 한 번 만들어 볼 수 있는 겁니다. 그래서, 여러 언어들이 계속 나오고 쓰이는 이유도 그런 해커의 정신이 아닐까 합니다.

프로그래밍 언어는 계속 진화합니다. 그리고, 계속 바뀌지만, 언어에 얽매이는 틀이 아닌 자유의 틀을 가진 사고는 가져야 할 듯 싶습니다. 어떤 프로그래밍 언어는 완벽하고, 어떤 프로그래밍 언어는 천박하다 라는 이분법적 사고나 교조주의는 지양해야 할 것입니다. 나름대로의 특징이 있으며, 할 수 없는 일을 하는 특징이 있게 마련이고, 그 쓰임때문에 지금까지도 남아 있는 것이겠죠.

꿈을 가져봅니다... 좋은 언어..

http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200509230033

버그는 제품이 개발되면서 생기는 자연스러운 현상이다. 이 버그는 항상 존재할 수 있음을 항상 가슴 속에 자연스럽게 담아야 하며, 버그로 인해서 어떤 문제가 생기는 것이지, 어떻게 해야해야 하는 것인지를 잘 깨달아야 할 것이다.
버그는 어떻게 생기는 것일까?

1. 요구사항의 이해 부족
요구사항이라고 할 수 있고, 표준에 대해서 제대로 이해하지 못해서 문제가 생길 수 있다.
특히 디자이너가 디자인 기획을 하고 나서, 명확한 UI 네비게이션을 생각하지 못하고, 기획을 하다가 구현을 하고 나서 문제가 생긴 경우가 종종 있다.

UI 요구사항에서 문제가 생긴 경우가 있다. 윗쪽 화살표만 가지고도 채널 업, 볼륨 업, 네비게이션에 대한 윗쪽 방향인지 구현하다가 문제의 소지를 그 때서야 발견하고, 기획자체를 수정하는 일이 생긴 적이 있다.

또는 개인적으로 자주 하는 것인데, 표준 문서에 대한 잘못된 이해에서 버그가 생길 수 있다. 분명 A, B를 이용해서 C를 만들어야 한다. 이렇게 되어 있어 있으면, A,B,C,D를 구현해서 E를 사용하게 하는 인터페이스를 만들어서 주위 프로그래머들을 고생시킨 적이 있다.

개발하기 전에 여러 시나리오에 대해서 체크하고, 잘 모르면 상급자에게 물어서 확인하고 잘 넘어갈 수 있도록 해야한다.

2. 지식의 부족
언어의 특징 혹은 개발 플랫폼에서의 특수한 상황을 인식하지 못한 상태에서 일어날 수 있는 버그가 있다.

정상적인 종료가 안되거나, 확실하게 null 또는 deconstructor를 호출하지 않아서 메모리에 조금씩 조금씩 메모리가 쌓여서 시스템이 작동이 되지 않는 현상을 발견될 수 있다.

메모리 할당을 잘못해서 스택이 엉키는 경우가 존재할 수 있으며, 한번은 CLDC의 thread와 관련된 suspend/resume을 제대로 이해하지 못해서 꼬일 수 있으며, 비동기 이벤트에 대한 처리를 잘 못해서 시스템이 깨질 수도 있다.

언어자체에 대한 공부가 필요하며, 만든 이에게 interface를 잘 사용하고 있는지 확인하거나 interface문서를 보도록 해야한다.


3. 잘못된 환경설정 파일
코드는 완벽히 잘 되어 있는데, 환경 변수를 잘못 기입하여 혼동된 값을 저장하여 문제를 일으킬 수 있는 부분이 있다.

assert를 잘 이용하거나 로그를 꼭 찍는 일이 필요하다.


4. 사명감
버그는 사람을 피곤하게 한다.
책임감과 사명감을 가지고 제품의 완벽성을 추구하려고 하는 것이 좋다.

그리고, 관리자는 적당하게 버그가 크리티컬하지 않으면, 나름대로 협상을 통해서 가이드라인을 정해서 버그를 피해 갈 수 있는 방법을 고객에게 제시하는 것이 필요하다.
모든 자동화는 복잡성을 늘리는 것이므로, 어느 정도의 수준의 합리적인 타협은 필요하다.
그렇다고 해서, 대충대충 넘어가는 것은 아니며, 제품이 완벽해 가는 과정속에서 사명감을 가지고 책임을 다해 제품이 나올 수 있도록 개발자 스스로, 관리자가 독려해야 한다.

먼 미래나, 힘든 프로그램 환경이나, 갑회사의 장으로부터 문제생기면 '박살'을 내겠다(사실은 더욱 좋은 것으로 패취해주는 것이었음. 그 말 생각해보니, 공기업은 깡패라는 생각이 들었다.) 라는 소리를 들으면, 우울하다.
돈받고 일하는 것이지만, 서비스를 제공하는 입장으로서는 썩 기분이 좋지 않다.

소프트웨어 개발 자체가 3D업종이라는 것은 소프트웨어업계에서 알려진 것이고, 싼 임금으로 밤새도록 돌리면 다 되는지 알고, 밤새워 해도, 인정받기 어려운 부분이 존재한다.
비전이 없기에 똑똑한 사람들은 다들 떠나고, 떠나지 못한 무능력한 관리자들 덕택에 새로 들어온 직원은 밤마다 시달린다.

내가 보는 소프트웨어 공학은 바로 이런 문제에서 시작되었다. 짧은 시간내에, 고품질의 소프트웨어를 산출어 내는 단계가 쉽지 않다. 어떻게 하면, 잘, 고급스럽게, 제 시간에, 삽질하고 않고 고품질의 양질의 소프트웨어를 만들어 낼 수 있을까?

요구사항 -> 설계 -> 구축 -> 테스팅 -> 유지보수

이 과정을 잘하는 것이 소프트웨어 공학이라고 생각이 든다. 버클리 대학의 소프트웨어 공학 교재에서는 "소프트웨어 공학은 가르칠 수 없다. 그러나 배울 수 있다."라는 구절이 있다고 한다. 소프트웨어 공학은 체계적인 교육이 아닌 체험에서 나온 것임을 잘 알려주는 것이다.

소프트웨어가 전부가 아닌 다양한 경험을 기반으로 해야 한다. 그리고, 그 경험을 인정해 주는 분야가 되어야 한다. 그리고, 그 경험을 싸구려처럼 여기는 관리자들가 있다하더라도 전문가가 되어야 한다.

비관하는 마음을 없애기 위해서는 자기 스타일을 죽여야 한다. 공학적이고, 자기 겸손적이고, 자신이 깨져야 서서히 보이는 것이 틀림이 없다. 긴 인생, 길게 보면서 가야지.. 짧은 목표 의식에 그 목표를 이루지 못해 비관한다면, 전문가가 되기보다는 비관주의자가 되기 쉽다.

자신을 비하하기 않기 위해서는 때로는 필요없는 욕심을 줄여야 한다. 힘을 다해서, 최선을 다해되 그 결과가 성공하지 못했다고 비하하지 않고, 환경이 나를 무너뜨리지 않고, 오기를 가지며 희망을 가져야 한다.
결국은 언젠가 그 결실을 맺을 거라 생각이 든다.

성실, 인내, 면학 이 세가지가 꾸준히 자기를 발전시키고, 자기 비하하는 시간을 줄이며, 목표를 향해 전진하는 좋은 덕목이 되는 것이 과거나 현재나 미래나 똑같이 써먹는 항목인거 같다.

이 기사를 내가 가장 공감하는 것은 로버트의 행동이었다.

엄청난 실수를 저지른 후, 도망가고 싶은 그 느낌은.. 정말 겪지 않은 사람은 이해를 할 수 없다. 일을 잘 해결하지 못하고, 수정된 버그는 엄청나게 커져서 더 이상의 도움을 받지 못해서 끙끙앓고 있는데, 상사는 언제 끝낼 수 있는 채찍을 들어서 괴롭힐 때면 엄청난 자괴감에 빠진다. 이런 상황에서는 내성적인 마인드가 살아나서 회사를 그만두고 싶은 충동을 느낀 적이 한 두번이 아니었다.

자신의 코드가 완전히 사라지고, 무력감을 느끼는 순간.. 답답했다. 이 자리를 영원히 뜨고 싶었다.
문제가 생기기 전에 교육을 제대로 받았으면 하는 생각이 얼마나 들었는지 모른다.

실수를 만회할 수 있는 시간이 짧아서 작은 실수가 다른 실수를 낳지만, 실수를 두려워하거나 거부하지 않아야 하고, 실수를 정정당당하게 끌어안고 그것을 뛰어넘는 사람만 발전할 수 있다라는 부분에서 큰 힘을 얻었다.

그러기 위해서는 개인자체가 스스로 마인드를 달리 해야겠지만, 조직의 변화도 같이 이루어져야 한다.

교육시스템과 조직시스템이 변경되어서 다시는 똑같은 실수가 없도록 해야되만, 똑같은 일이 계속 반복적으로 이루어지는 조직.. 변하지 않는 조직에서는 개인 스스로 어떻게 해야하는 것일까???

솔루션을 개발하고 나서 가장 먼저 하는 일을 개발한 솔루션에 대해서 홍보를 하는 것이다. 그 중의 하나가 '전시'혹은 '데모스트레이션'(이하 데모)을 하게 된다.

데모 준비는 가장 데모 환경과 똑같은 환경에서 준비를 해야함에도 불구하고 제대로 준비되지 않는다.
불안 요소로 인해서 데모가 진행되지 못하는 경우가 많다.

데모의 법칙을 한 번 얘기해 보려고 한다.

1. 막상 데모를 준비하려고 하는 순간 문제가 꼭 생긴다.

2. 1번의 문제 때문에 상황이 악화된다. 이 때 관리자는 폭발하게 되어 집중을 하지 못하게 한다. IBM에서 개발중인 과학자에게 관리자가 머라고 했다가 과학자가 이 한마디를 했다고 한다. "당신이 없는게 일이 더욱 빨리 할 수 있는 것이다"라고..

3. 1번의 문제를 피하려다 다른 문제로 꼬인다.

데모는 완전한 제품을 시연하는 것이 아니라, 현재 이런 솔루션을 통해서 무엇가를 할 수 있다라는 혹은 비즈니스를 창출하여 수익을 얻을 수 있다는, 혹은 생산성을 높여 최대한의 수익을 얻을 수 있는 것을 그 목적으로 한다. 그러기에 실수는 없도록 해야 하는데, 이 부분을 잘 모르는 경우가 많다.

데모 준비자가 실수하는 부분이 바로 여기에 있다. 단순히 자기가 맡은 역할만 다하는 것이 아니라, 자신과 엮인 부분이 (INTERFACE) 다른 모듈과 잘 동작되는지, 문제가 없는지를 파악하는 것이 필요하다.
그러기 위해서는 데모 준비자가 갖추어야 할 요소를 다음과 같이 정리해본다.

1. 데모 시나리오를 확정해야 한다.
글쓴 이는 방송 미들웨어 데모를 준비중이었는데, 데모 시나리오가 갖추어지지 않아 단순하게 내 입맛에 맡는 부분만을 생각하고, 그 부분만 완료가 되면, 다 되는 줄 알았다.
데모하는 날, 방송망으로 DVD 소스를 비디오 인코더를 통해서 송출할 때, 수신기에서 디코딩하는 부분이 문제가 생기는 것을 발견하고, 그제서야 관리자에게 보고를 하게 되었고 혼이 났다. 글쓴 이는 황당해서 데모 시나리오가 제대로 정해지는 지 몰랐다고 항변했으나, 관리자는 몰랐으면 확실히 물어보아야 하는 것이 아니냐고 하였다.

1차적으로는 글쓴 이에게 있었다고 본다. 불확실한 부분에 대해서 확실하게 책임을 지고, 데모의 경계선(BOUNDARY)을 일찍 파악하는 것이 중요했는데, 그 부분을 생각하지 못한 것이 큰 문제였다. 어플리케이션을 올려 테스트하는 것만을 생각했지, 동영상 디코딩을 할 줄을 몰랐던 것이다.
실제 방송에서 동영상을 방송 스트림으로 전송하는 것이 방송 데모에서 큰 부분인데, 미처 이 부분까지 생각하지 못했다.

2차적으로는 데모 시나리오가 확실히 잡히지 않은 문제가 가장 컸고, 의사소통이 제대로 이루어지지 않았으며, 책임자가 올바르게 선정되지 않았기에 문제가 생기는 소지가 발생하였다. 관리자는 반드시 자기의 소재를 확실히 하여, 데모 책임자가 어느 선까지 준비되었는지를 체크하는 것이 중요하다.

2. 데모 준비에 앞서 데모 준비 환경과 완벽하게 준비한다.
데모 준비 환경이 계속 바뀌게 되면, 데모를 준비하는 사람은 많이 힘들게 된다. 즉, 미리 준비할 때, 계획성있게 해야 하는데, 늦게 준비가 되면, 일을 또 하게 되어서 셋팅에 문제가 될 소지가 많다.
글쓴 이가 데모 환경을 3번이나 변경을 하면서, 갑작스런 문제가 생겼다. 3번째 데모 환경을 변경중에 수신기에서 방송스트림을 제대로 받지 못하는 일이 갑자기 발생하였다. 1시간 넘게 그 이유를 발견하지 못했다. 결국은 중형 스피커로 발견되었고, 스피커를 치우니, 동작이 되었다.
그리고, 3번째 데모 환경 변경시, 파워 스위치를 모르고 끄는 바램에 이유를 알수 없는 미들웨어 버그가 생기는 일이 벌어졌다. 정확하게 파워 리셋이 되었다고 문제가 생기는 것은 아니었지만, 다른 이류를 촉발시킨 듯 하다.
항상 데모 환경은 4시전에 끝을 내야 되고, 그 이후에 바뀌어서는 안된다.


3. 데모는 기록해 둔다.
데모에 대해서 무엇이 문제인지, 무엇때문에 데모준비, 데모를 하면서 변경 희망 사항이 생기면 제품에 반영할 수 있어야 한다. 또한 데모를 받는 고객에게서 좋은 힌트나 요구사항에 대한 정리를 통해서 제품에 반영할 수 있어야 한다.

또한, 데모 환경을 잘 기록하여 추후 잘 활용할 수 있어야 한다. 하드웨어, 물리적 네트웍의 변경을 한 부분을 잘 정리하여 추후에 데모를 할 경우 다시 할 때도 잘 할 수 있도록 해야 한다.

MS가 M&A로 구글을 사려했다는 소식은 유명하다. 깔끔한 디자인으로, 단순하고 명료한 검색엔진개발사 구글의 생각을 마소와 웹싸이트에서 얻어왔다. 명확한 목표의식을 통해서 연구원들에게 힘을 만들어주고, 격려하고, 신뢰성있는 소프트웨어를 만드는 일.. 을 꿈구고 싶다.


출처 : http://www.google.com/corporate/software_principles.html ,  http://www.google.com/jobs/reasons.html, 마소 2005 년, 10월호


구글에서 일해야 하는 10가지 이유

1) 상부상조(Lend a helping hand) : 위대한 삶을 살기 위해 필요한 정보를 사람들에게 제공한다.
2) 인생은 아름다워(Life is beautiful) : 리마커블한 제품 개발
3) 감사는 최고의 동기 부여책이다 (Appreciation is the best motivation) 
4) 놀이와 일은 별개가 아니다. (Work and play are not mutually exclusive)
5) 종업을 사랑하며 이런 사실을 알기를 바란다. (We love our employees, and we want them to know it)
6) 혁신이 생명줄이다 (Innovation is our bloodline). 정보처리 부분에서 최고를 지향한다.
7) 어딜 보더라도 좋은 동료가 있다.(Good company everywhere you look) : 다양한 부분에 걸쳐 온갖 경력으로 무장한 친구를 찾을 수 있다.
8) 세계를 하나로 묶는다 (Uniting the world, one user at a time. ): 모든 국가와 모든 언어를 지원한다.
9) 아무도 간 적이 없는 신세계로 용감하게 나가자(Boldly go where no one has gone before : 풀어야 할 수많은 난제가 있다. 여기서 수많은 사람을 기쁘게 해줄 창조적인 신제품을 만들 기회를 얻을 것이다.
10) 공짜 점심과 같은 선물이 있다. (There is such a thing as a free lunch after all)
사랑으로 만들어지고, 건강한 음식을 먹을 수 있다.
구글 식당은 품질이 높기로 유명하다. 최근 구글 식당의 수석 요리사가 그만둔다고 해서 새로운 요리사를 구하기 위해 난리가 났었다.

구글이 밝히는 설치형 구글 소프트웨어 원칙 (www.google.com/corporate/software_principles.html)

1) 설치 : 사용자를 속이면서 소프트웨어를 설치하지 않아야 한다. 소프트웨어를 컴퓨터에 설치하는 과정에서 거부할 수 있어야 하며, 다른 소프트웨어 설치 과정에서 끼어들어서도 안된다.
2) 솔직한 소개 : 소프트웨어를 설치하거나 활성화할 경우에 주된 기능을 알려줘야 하며 광고를 통해 돈을 벌어들일 경우 이런 사실을 밝히지 말고 가장 눈에 잘 띄는 곳에 보여줘야 한다.
3) 단순한 제거 : 소프트웨어를 비활성화하거나 삭제할 경우에 손쉬운 방법을 제시해야 한다. 응용 프로그램의 모든 기능을 제거해야 하며 삭제된 이후에 다른 응용 프로그램을 동작시킬 경우 동작해서는 안된다.
4) 명확한 동작 방식 : 사용자 환경 설정을 변경할 ㅅ경우에 이런 변경을 가하는 이유에 대해 명확하게 설명해야 한다.
5) 훔쳐보기 : 응용 프로그램이 개인주소와 같은 정보를 수집해서 전송할 경우 사용자에게 알려야 한다. 정보를 수집해서 전송한다는 사실을 명시적으로 알리고 동의를 구해야 한다.
6) 좋은 회사 만들기 : 응용 프로그램 제공자는 상기 가이드라인을 어기는 소프트웨어를 함께 포함시켜 배포하지 않아야 한다. 여러 가지 응용 프로그램이 동시에 설치될 경우에 사용자에게 각 소프트웨어가 무엇인지 알려줘야 한다.

요약

실패한 프로젝트의 유형
1. 프로젝트의 진행 중간에 취소 또는 중단된 프로젝트이다.
2. 프로젝트의 완료 시점에서 고객이 그것을 받아들이지 않아 결과적으로 프로젝트의 최종 인도물이 무용지물인 경우이다.

성공한 프로젝트
1. 계획된 시간, 비용, 범위를 제대로 충족시키고, 결과적으로 고객의 수용과 만족을 얻어낸 프로젝트를 뜻한다.

문제 프로젝트
1. 계획된 일정이 초과되었거나
2. 예산을 초과하였거나
3. 기능 중 일부를 구현하지 못하는 경우

프로젝트 매니저의 첫번째 덕목은 경영과 관리의 업무니다.
업종의 특수성을 초월하는 보편성을 깨달음으로써, 완전한 도의 경지에 도달한 사람이다.

소프트웨어 매지니맨트는 개발자의 심리를 깊이 이해해야 한다. 실무지식 및 통찰력이 필요하다.

프로젝트의 실패 요인 중 큰 부분
프로젝트에 혼란을 가중하는 가장 일반적인 원인은 역할 즉 권한 과 책임을 명백히 규정하지 않는 것이다.

요약
실용주의는 기존의 관념적이고, 형이상학적 사고를 부정하고,그 관념들이 실세계에 초래하는 결과가 유용하고 실용적인 실제들로 증명되었을 때만 의미가 있다라는 단초를 갖고 시작한다. 실제 프로젝트에서 이상적인 시스템을 구축할 수 있어야 그 유용성을 증명할 수 있는 것이다.

실용주의란 요구사항에 맞는, 시스템의 목적에 충실한 방법을 말한다. 실용주의에 맞는 개발을 하려면 다음의 방법론을 가져야 한다.

1. 자신의 능력에 충실한 방법
설계자는 아키텍처에 대한 거시적인 관점을 항상 유지해야 한다.

2. 개발 단계를 고려한 미시적 설계
두 쓰레드가 컨텍스트 스위칭을 하며 각자의 작업을 실행하듯이 양 관점을 주깆거으로 바꾸어 디자인하려는 습관을 기른다.

3. 모듈화 극대하기
소프트웨어 시스템에서 서브 시스템과 컴포넌트의 그룹핑을 통해 의미있는 분류 상태를 말한다.

4. 모듈화 인터페이스, 팀 나누기
변할 수 있는 인터페이스에 대해 변경을 위한 여지를 남겨두는 기법이 필요하다. 방법은 이런 부분의 인터페이스를 유연하고 다의적이며 느슨한 인터페이스로 구성함으로 가능하다.
변경을 염두로 한 유연하고 느슨한 다의적인 인터페이스를 정의한다.
자신이 할 수 있는 것과 할 수 없는 것을 냉정히 분석하여 자신이 할 수 있는 것을 확실히 잘 하는 지혜가 필요하다.

5. 거시와 미시 두가지 관점 갖기

6. 아키텍터를 반영한 거시적 설계
아키텍처 스타일을 따르기 위해 아키텍처 스타일을 숙지하고 적용할 부분을 잘 포착할 수 있어야 한다.
아키텍처 레벨에서 정의한 방법을 디자인레벨에서 재정의 한는 일이 없어야 한다. 잘못된 인터페이스의 설계로 모듈간의 불협한 소통은 곧 팀사이의 불협한 소통으로 이어진다. 그래서 모듈화를 잘해야 하며 모듈간의 인터페이스를 잘 정의해야 한다.

7. 모듈화와 공학적인 일정 추정, 관리
예상되는 기간 + a의 일정추정법을 사용한다. 노련한 개발자의 소양 중 하나는 일정 예측을 잘 하는 것이다.
조엘 온 소프트웨어에서는 모듈명, 작업내용, 우선순위, 최초 추정시간, 현재 진행시간, 경과시간, 남은 시간으로 구분한다.
안정된 프로젝트 관리와 자신의 생산성과 신뢰성을 확보하기 위해서이다.

8. 자신의 무지 인정하기
경험이 갖춰지기 전에 자존심이 강해지기 때문에, 데드라인을 지키지 못하는 일정을 잡아 억지로 납기일을 맞추다보니 기능이 제한되든가 품질이 떨어지는 소프트웨어가 만드는 경우가 빈번하다.
제작한 설계의 허점과 단점을 깨닫게 될 때, 적절한 자기 관용을 통해 어느 선으꼬 마무리를 짓고, 다음 기회에 더 괜찮은 소프트웨어를 설계하기 위해 노력하는 것이 유익하다.

9. 진화를 위한 방법
항상 자기 계발을 늦춰서는 안된다.

10. 진지전과 기동전
장기적인 계획이나 방향이 필요하다. 시대적인 트랜드나 개인적 호기심을 따라 두서없이 학습하다 보면 중심을 잃게 되고 균형 잡힌 지식형성을 효율적으로 못한다. 기술력을 만들기 위해서는 로드맵을 만드는 것이 좋고, 거시적인 비전을 갖고 비전에 으르는 과정의 사이마다 이정표를 세워 자신의 캐리어 패스를 구상해야 한다.

의지와 성실함의 성격이 중요하다.

11. 포교활동
새로운 기술을 배우면, 반드시 그 기술을 적용한 프로토타입 모델을 리뷰한다거거나 요점을 정리해서 메일을 돌리는 것만으로 새로운 반응을 얻을 수 있다.

12. 응집성과 결합성
역할과 의도에 따라 분류를 잘하고 방향성을 잡아야 한다. 자신의 주관적인 설계 의도가 시스템의 객관적인 설계 문제를 잘 해결하고 있는지 자주 평가 / 확인하는 습관이 필요하다.

13. 몸에 맞는 옷
무조건적인 패턴을 쓰는 것보다 원리 원칙은 알되, 현재 설계문제가 필요로 하는 용도를 분석할 수 있어야 한다. 용도가 정확히 맞아 떨어지는 모델을 말한다.

14. 다시 관념 속으로
자기 확인이 필요하다. 비판적으로 스스로를 확인하는 습관이 필요하다. 실용주의는 수동적인 수용을 거부한다. 계속해서 검증해야 하고, 비판해야 하며 확인해야 한다. 또한 새로운 것을 계속해서 찾아야 한다. 또한 새로운 것을 계속해서 찾아야 한다. 그래서, 실용주의 엔지니어는 부지런해야 한다.