요구사항을 뽑아내는 일은 결코 쉽지 않다. 시스템의 중점 아이템을 꺼집어 내어 지금까지 나왔던 자사 및 모든 경쟁 제품보다 훨씬 뛰어난 제품을 만들어야 하는 요구사항을 뽑아내야 하기 때문이다.
지난번 요구사항을 파악하기 첫번째에 이어서 요구사항 파악하기 두번째를 써보게 되었다.

사용자 시나리오나 기능성을 기반으로 하는 모듈을 분리하여 요구사항을 얻어 내는 것만으로는 완벽히(!) 부족하다.
모듈단위의 기능을 파악하는 것 외에 무엇을 생각해야 하는가?

1. 완성된 컴포넌트 모듈은 자주 바뀌는 가? 아니면, 한 번 만들어지면 계속 바뀌지 않는가? 에 대한 깊은 고민이 필요하다. 모듈의 타입에 따라 유지 보수할 때 유지 보수성을 생각하며 깊게 생각해야 되는 부분이 존재한다.

소프트웨어의 생명 주기중 가장 긴 부분이 "유지보수"라는 것을 잘 생각해야 한다. 소프트웨어의 생명은  "디자인", "개발", "유지보수"라고 하는 큰 3단계의 단계가 있는데, 이의 비용(시간 포함) 비율은 3:2:5 라고 생각한다. 그만큼 유지보수적인 부분이 굉장히 소요되기 까닭에 디자인단계에서 잘 생각하여 유지보수의 비용을 최대한 낮추는 설계방법을 가져야 한다.
디자인이 한 번 잘 못되면, 시스템의 변경이 필요해지고, 변경에 따른 비용, 변경을 하지 않아서 생기는 비용을 잘 염두해야 한다. 컴포넌트 모듈중 static, dynamic한 부분을 잘 나누어 본다. 컴포넌트 모듈의 input, output을 잘 생각한다. 각 컴포넌트의 모듈의 연관(아직 기능적인 모듈간의 인터페이스만 생각!)을 머리 속에 그리며, input과 output의 고민을 잘 해야 한다.

시스템에서 가장 많이 사용될, 아니 상용화될 때 가장 많이 바뀌는 부분은 신경을 써서 요구사항을 잘 파악하는 것이 중요하다. 20:80의 이론처럼 전체 시스템의 20%는 전체 프로젝트의 80%를 차지하고 있다는 것을 염두해야 한다.

보통 데이터를 동적으로 받아서 처리하는 부분을 프로퍼티, XML형태로 받아들 일 수 있도록 해야 하며, 네트웍인 경우는 Push인지 Pull방식이 좋을지 고민을 잘 해야 한다.

2. 네트웍 환경에 맞는 모듈 설계를 고려해야 한다.
Closed  네트웍을 사용해야만 하는 경우도 존재하므로, 네트웍 환경까지 생각할 필요성이 있다.
public ip를 받지 못하는 환경을 쓸 수 있는 네트웍 환경이 주어지는 경우가 존재 할 수 있다. 그 가능성에 대해서 염두할 필요성이 있다.

특히 방송환경은 네트웍 환경에 맞는 요구사항을 파악하는 것이 중요하다. 방송 서버는 Closed 망을 쓰기 까닭에 바깥으로 패킷은 허용될 수 있으나, 들어오는 패킷은 막는 형태로 되어 있다. 그런 부분까지도 잘 감안해서 요구사항을 뽑아내야 한다.

요구사항을 뽑아내는 것은 무척 어려운 일이다. 즉 대략 설계를 들어가지 않는 다고 하지만, 설계를 염두하지 않은 요구사항은 프로젝트에 큰 영향을 끼치기 까닭에, 요구사항을 단순한 부분이 아닌, 설계를 염두한 세부 요구사항까지 파악할 필요가 있다.
Posted by 김용환 '김용환'
집중해서 읽으면 금새 다 볼 수 있었는데도 천천히 읽혀 지더라구요. 리더의 고민, 리더로서 어떤 길을 가야 할 지, 리더의 책임, 리더로서 해주고 싶은 말들.. 꼭 제가 잘 아는 선배나 형이 알려 주는 것 같습니다.
나는 책을 통해서 인생의 한 선배를 다시 한 번 보게 되었습니다.

이 책을 읽은 이유는 책 표지 뒤의 안철수씨가 쓴 '기업의 목표'를 읽게 된 이유입니다. 저는 그 문구에 멍청난 충격을 받았습니다.

제가 한 서점에서 아르바이트를 할 때였습니다. 사장님 아들이 사장님, 직원, 아르바이트생을 모두 모아놓고 이런 말을 하였습니다. "우리 서점의 목표가 무엇이냐?" 저는 이렇게 말했습니다. "사회의 기여입니다. 책을 고객에게 파는 것이 아니라 친구와 선배를 그들에게 알려 주는 것입니다." 라고 말을 했더니, 사장님 아들이 "우리는 이윤을 추구하는 것이 목표야"하며 엄청 혼난 적이 있습니다. 그 옆에 계신 사장님도 맞다며 고개를 위 아래로 끄덕이며 맞다고 하시더군요. 저는 그 이후로 모든 기업과 상점은 모두 이윤추구가 최고의 목적이라고 생각해 왔습니다. 한번도 사회에 공헌하는 것은 말뿐인 허울이라고 생각해 왔습니다. 그냥 선전이며 위선이라고 생각했었습니다.

"CEO 안철수, 지금 우리에게 필요한 것은"에서 안철수씨는 기업의 존재의미에 충실하는 것이 그 목표라고 했습니다. 사회에 기여하는 것 자체에 보람을 느끼는 구성원이 모여 공동작업하는 것이 기업의 존재 의미라고 하였습니다. 이윤은 자연스럽게 따라온다고 생각한다며, 이윤추구가 목적이 되면 안된다고 했습니다.

우리 사회를 한 번 둘러봐 주십시요. 돈 버는 것이 잘 못된 것은 아니지만, 과연 정당하게 사회에 기여하면서 돈 버는 사람이 있나 돌아봐 주십시요. 어떻게 하면 사행성을 조장하여, 음성적인 것을 이용해서 돈을 벌 수 있을까 고민하는 사람들 잊지 않습니까? 아니, 저부터 그런 생각을 까닭인지 약간은 우울합니다.

하지만, 이 책을 통해서 많이 부끄러웠는지 모릅니다. 자신이 깨끗하게 자신의 펜으로 기업의 목표를 사회에 기여하는 것을 최우선 가치에 두고 있는 안철수씨를 존경하게 되었습니다. (이전에 그 분의 책을 읽었지만, 존경까지는 가지 않았습니다. 정말 존경스럽더군요. 한 개발자 아닌 선배로..)

조직문화를 제대로 세우고, 조직의 위부터 아래까지 의사 소통이 잘 되기 위해서, 개인의 이익보다는 조직의 우선을 최우선하며 조직의 역할을 감당하기 위해서 조직의 리더가 해야하는 책임과 임무, 조직 구성원이 해야하는 책임과 임무에 대해서 잘 알게 되었고, 지금의 제가 느끼는 조직문화의 중요성을 다시 한번 깨닫게 되었습니다.

올바른 양방향 커뮤니케이션, 원칙과 본질의 충실, 존중과 배려, 목표에 대한 치열함을 최고의 미덕으로 가지는 안철수씨의 의견에 공감을 하며, 저도 원칙과 본질에 충실하고 존중하고 배려하며 커뮤니케이션을 잘 할 수 있도록 최선을 다하며 치열한 노력을 다할 것입니다. 특히 조직문화에 대한 배움은 상당히 컸습니다. 조직문화를 잘 다루는 그런 리더를 꿈꾸어 봅니다.

http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200412160001#0
Posted by 김용환 '김용환'
요즘 지상파 방송사에서 방영하는 사회화와 관련된 동물 다큐멘터리를 보면, 똑똑한 동물이라 할지라도, 후손에게 가르칠 수 있는 지적 능력이 존재하지 않기에 후손에게 학습을 시키는 동물은 사람밖에 없구나 하는 생각이 든다.
후손에 가르칠 수 있는 능력은 인간에게 주어진 축복이구나 하는 생각이 든다.

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

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

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

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

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

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

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

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

'철학' 카테고리의 다른 글

디자인-요구사항 파악하기-1  (0) 2006.07.20
디자인-요구사항 파악하기-2  (0) 2006.07.20
커뮤니케이션을 기반으로 하는 학습.  (0) 2006.07.20
버그의 원인  (0) 2006.07.20
자기 비하 하지 않기..  (0) 2006.07.20
개발자와 QA엔지니어와의 협력  (0) 2006.07.20
Posted by 김용환 '김용환'

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

Posted by 김용환 '김용환'

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Posted by 김용환 '김용환'

버그의 원인

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

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

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

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

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

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

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

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

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


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

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


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

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

'철학' 카테고리의 다른 글

커뮤니케이션을 기반으로 하는 학습.  (0) 2006.07.20
자기 비하 하지 않기..  (0) 2006.07.20
버그의 원인  (0) 2006.07.20
자기 비하 하지 않기..  (0) 2006.07.20
개발자와 QA엔지니어와의 협력  (0) 2006.07.20
소프트웨어 공학 - 사람 키우기  (0) 2006.07.20
Posted by 김용환 '김용환'
먼 미래나, 힘든 프로그램 환경이나, 갑회사의 장으로부터 문제생기면 '박살'을 내겠다(사실은 더욱 좋은 것으로 패취해주는 것이었음. 그 말 생각해보니, 공기업은 깡패라는 생각이 들었다.) 라는 소리를 들으면, 우울하다.
돈받고 일하는 것이지만, 서비스를 제공하는 입장으로서는 썩 기분이 좋지 않다.

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

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

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

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

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

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

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

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

'철학' 카테고리의 다른 글

커뮤니케이션을 기반으로 하는 학습.  (0) 2006.07.20
버그의 원인  (0) 2006.07.20
자기 비하 하지 않기..  (0) 2006.07.20
버그의 원인  (0) 2006.07.20
개발자와 QA엔지니어와의 협력  (0) 2006.07.20
소프트웨어 공학 - 사람 키우기  (0) 2006.07.20
Posted by 김용환 '김용환'
이 기사를 내가 가장 공감하는 것은 로버트의 행동이었다.

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

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

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

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

교육시스템과 조직시스템이 변경되어서 다시는 똑같은 실수가 없도록 해야되만, 똑같은 일이 계속 반복적으로 이루어지는 조직.. 변하지 않는 조직에서는 개인 스스로 어떻게 해야하는 것일까???
Posted by 김용환 '김용환'
솔루션을 개발하고 나서 가장 먼저 하는 일을 개발한 솔루션에 대해서 홍보를 하는 것이다. 그 중의 하나가 '전시'혹은 '데모스트레이션'(이하 데모)을 하게 된다.

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

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

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

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

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

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

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

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

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

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

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


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

또한, 데모 환경을 잘 기록하여 추후 잘 활용할 수 있어야 한다. 하드웨어, 물리적 네트웍의 변경을 한 부분을 잘 정리하여 추후에 데모를 할 경우 다시 할 때도 잘 할 수 있도록 해야 한다.
Posted by 김용환 '김용환'
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) 좋은 회사 만들기 : 응용 프로그램 제공자는 상기 가이드라인을 어기는 소프트웨어를 함께 포함시켜 배포하지 않아야 한다. 여러 가지 응용 프로그램이 동시에 설치될 경우에 사용자에게 각 소프트웨어가 무엇인지 알려줘야 한다.

Posted by 김용환 '김용환'