IT/Software 도서

김익환, '글로벌 소프트웨어를 꿈꾸다' 책 요약 정리 그리고 생각

데브렉스 2012. 12. 2. 16:48
반응형

[정리]

글로벌 소프트웨어만이 살아남을 수 있다. 열심히 쌓아온 막강한 기술력만으로 충분할까? 제아무리 기술력이 뛰어나다 하더락도 개발문화가 뒷받침되지 않으면 글로벌 소프트웨어 회사로 성장하는 것은 어렵다. 개발문화는 소프트웨어의 본질이기 때문이다.

 

- 혁신하든가 사라지든가

  70년까지 살 수 있는 솔개는 대부분은 40년에 수명을 다 한다. 40년이 다되면 부리는 너무 길어져 먹이를 쪼기 힘들어지고, 발톱은 무뎌지고, 날개는 기름에 절고 무성해져서 사냥을 할 수 없는데. 여기서 엄청난 자기 갱생의 노력을 한 솔개는 사라남는다.(부리를 일부로 돌에 부딪혀 깨뜨려서 새부리가 나오게 하고, 새로 나온 부리로 발톱을 쪼아 없애서 새 발톱을, 날개를 뽇아서 새 날개가 나오게 만든다. 이 노력을 6개월 하면 30년 더 살아남는다.

  소프트웨어 회사에 필요한 혁신 : 오랫동안 습관적으로 일해오던 것들이 대부분 혁신의 대상 (따라 하지 않던 프로세싱, 문서쓰기, 아키텍처 재정립, 소스코드 청소, 기반시스템 정립, 소스코드 리뷰 등...)

  롤 모델이 필요 혁신을 가이디 할 수 있는 선각자를 발견해서 배워야 한다.

 

- 변하지 않으면 죽는다.

  앨빈 토플러 : 회사가 생존하기 위해서는 항상 변해야 한다. 변하지 않는 회사는 죽는다. 변하는 회사는 70%가 살아남는다.

  경영자가 바꿔야 할 것 : 하드웨어 마인드를 버려라(변경을 최소화), 소프트웨어는 아무나 개발할 수 있다는 생각을 버려라(개발자의 능력에 따라 결과는 28배나 차이가 난다고 파나스가 말했다), 관리자나 영업이 개발자를 좌지우지 하지 않게 하라, 빠른 개발의 경영전략을 버려라, 일정을 협상하지마라, 2% 부족한 것을 간과하지 마라, 조급한 생각을 버려라

  개발자가 바꿔야 할 것 : 자신의 능력을 정확히 알고 행동하라, 급할 수록 천천히 가야한다, 처음부터 제대로 배워야 한다, 항상 자신을 변화시키려고 노력해야 한다.

 

- 소프트웨어 회사는 두번의 재건축이 필요하다.

  첫번째 : 소스의 벤처회사에서 수십 명 정도의 중소기업으로 자라날때

  두번째 : 중견기업에서 대기업으로 성장할 때

  기반시스템, 조직, 프로세스, 기술, 문화 등을 전반적으로 바꿔야 한다. (소스관리시스템이나 이슈관리시스템, 개발 스피드보다 관리와 안전)

 

- 미국회사는 기본이 70점, 한국회사는 20점에서 시작

  실리콘밸리에서 근무하는 소프트웨어 개발자의 직장 평균 재직기간 2년이 안된다. 개발자가 직접 여러 회사를 다니거나 이직한 동료 개발자를 통해서 개발자, 회사 모두 다양한 경험을 쌓는다. 이러한 이직 문화가 가능한 이유는 인력 이동에 대한 준비가 되어 있기 때문(기반시스템 설치, 프로세스 정립, 코딩의 표준화, 문서화 방법, 개발방법론, 공유 문화 정립 등)

 

- 꼬여버린 프로세스 코드, 기반시스템

  조화가 필요한 도구들, 도구는 한번 사용하기 시작하면 늪처럼 빠져 나오기 힘들다. 보다 위험한 경우는 어떤 사용도구도 자기 회사의 특수한 문제를 해결하지 못한다는 생각에 도구를 자체 개발하는 것.

 

- 공유를 싫어하는 사람은 소프트웨어 회사에 적합하지 않다.

  소프트웨어 회사에서 중요한 것은 공유의 문화, 중요한 인재는 정해진 프로세스, 개발원칙을 잘 지키면서 공유하고 협업하며 묵묵히 일하는 사람.

 

- 회사에 필수적인 소프트웨어 전문가

  컨퍼런스 세미나 참석 : 새로운 기술을 습득하기 위한 방법

  회사에서 승진하려면 관리자가 되어야 한다고 생각하는 것이 한국사회의 통념, 나이 많은 최고의 개발자가 미국엔 수없이 많다.

  구글에서는 개발자와 영업자 사이에 이견이 생기면 대부분 개발자가 이긴다고 한다

 

- 소프트웨어 회사가 성공하기 위한 다섯가지 조건

  기반시스템 : 이슈관리시스템(필수), 소스관리시스템(필수), 테스트관리시스템, 빌르/릴리즈관리시스템, 프로젝트관리시스템, 작업관리시스템, 고객관리시스템, ERP, 등

  조직

  프로세스

  기술 : 기술은 시대에 따라 변한다, 평균 수명은 3년, 기술에 관한 한 당장 먹을 만큼만 사오는 것이 효율적.

  문화 : 웹 2.0의 3대 키워드인 참여, 공유, 개방. 다른일에 참여도 하고 자기 것을 공유도 하고 개방도 하면 된다. 구글에서는 입사 첫날 누구든지 모든 소스코드를 다운받아 컴파일해서 사용할 수 있다고 한다.

 

- 이슈관리스템을 보면 회사를 안다.

  이슈관리시스템은 대시보드 형식으로 모든 직원이 항상 모니터에 뛰어 놓고 모니터링 한다. 개발자의 업무지시가 대부분 여기에서 온다. 출근후 가장 먼저 본다. 오늘 하루의 일과 예상(시간절약), 모든 직원 사용한다(email,전화사용 최소화), 이슈를 등록한다(발견한 사람이, 전체 시간이 더 걸리기도 하고 지속적으로 계속 대리인에게 의존하게 되어 모두의 생선성을 떨어뜨린다. 특히 윗사람이 아랫사람에게 시키지 않도록)

  전사적으로 제품이 몇 개나 있는지 한눈에 알 수 있다. 각 제품의 버전과 컴포넌트가 몇 개나 있는지 알 수 있다. 핵심 제품을 알 수 있다. 고객이 누군지 얼마나 많이 팔리는 제품인지도 추측가능, 제품의 안정성, 버그나 기능 요청이 얼마나 있는지, 어제 새로 발생한 심각한 문제가 있는지, 개발 혹은 유지보수의 진행 상태, 이슈 해결 상태, 어느 개발자 혹은 어느 부서의 업무가 과도한지 혹은 한가한지를 알 수 있다, 데이터 베이스로 관리되어 필터 할 수 있다.

 

- 소스관리시스템은 개발팀의 축소판이다.

  가장 기본적인 표준 준수 문화를 본다. 소스코드의 코딩 컨벤션이나 프로그래밍 스타일은 통일되어 있는지, 주석은 이해가능한지, Check in할때 로그 남기는지, 이슈번호는 있는지, 동료검토한 이름은 있는지, 누가 개발했고 누가 개발하는지, 버전수 등

 

- 문서를 적으면 개발시간이 단축된다는 것을 진정으로 믿어라

  문서가 없이는 소프트웨어의 전체 구조가 깨끗하게 만들어지지 않는다는 것. (10층 짜리 건물을 설계 없이 쌓아 올리는 것과 비슷), 필자는 문서 없이 잘 개발하는 것을 보면 기적이라고 생각한다.

 

- 스펙(SRS) 이란 ?

  SRS(Software Requirements Specification)는 분석단계의 결과로 나오는 산출물 : 기능명세서, 요구사항명세서, 요구사항분석서

  좋은 품질의 소프트웨어를 최소비용과 최소시간에 개발하기 위해 적는 문서

  IEEE 에서 말하길 소프트웨어 개발에서 가장 중요하고 어려운 것이 SRS를 적는것.

  모든 부서의 사람이 동시에 제품개발에 참여 할 수 있는 문서를 만드는 것.

  SRS를 적을때는 왜가 더 중요하다. 예를 들어 개발언어를 계발 언어를 Java로 하는 것이 중요한 것이 아니라 왜 C++인지, 왜 Java로 하기로 했는지가 중요, 또 왜 DBMS로 MS-SQL이 아는 Oracle을 사용하는지. SRS의 처음부터 끝까지 모든 문장에서 '왜?'라는 질문을 던져보는 것. 그리고 왜에서 무엇으로 진행된 과정도 적는다.

 

- 장식용, 제출용, 실용적인 방법론

  장식용 방법론 : 외부 과시용

  제출용 방법론 : 개발 후반부에 작성 기계적으로 적기만

  실용적인 방법론 : 필요한 만큼 문서 몇 개만 골라서 작성, 그래야 유지 보수도 가능

  방법론은 제대로 됭어가서 일하다 보면 저절로 배우는 것이지 미리 배우고 가서 써먹는 것이 아니다.

 

- CTO의 역할은 아무나 대신하지 못한다.

  벤처투자가가 벤처회사에 투자할 때 보는 첫 번째 조건 CTO가 있는가 이다. (연구소장, 개발실장,R&D부사장 등 과 혼란하지 말자, CTO는 인사관리를 안한다)

  CEO는 회사의 비전과 돈을, CTO는 기술에 관한 모든 것을 책임 지는 것(장기기술전략, 실행전략, 아키텍처, 구현, 일프라구조 정립, 프로세스 등 개발에 관한 기술적인 것이라면 모두 책임), 나중에 개발자한테 물어봐서 답해 드릴게요 라고 하면 CTO가 아니다.

  CEO, CTO를 한 사람이 수행하는 것은 슈퍼맨과 같은 역량과 두배의 시간을 요구.

  CEO가 컨퍼런스 발표를 할 때 기술적인 질문에 대답할 수 있는 CTO대동하고 다닌다. 그 둘이면 어떤 질문이 나와도 답 할 수 있다. 구글에서도 게르게이도 기술적인 질문이 나올 경우 대비 같이 참석. 빌게이츠도 은퇴전까지 Chief Software Architect라는 직함을 가짐(마이크로소프트의 최고 기술 전략책임자, 현재는 레이 오지) 빌게이츠는 CEO와 CTO 사이를 넘나들었는데, 어떤 제품의 설계 문서를 검토하다 날짜 Format이 잘못될 수 있다는 것을 발견해 내고 질문했다는 일화도 있다. 구글의 CEO인 에릭 슈미트도 썬마이크로시스템즈에서 CTO를 했었다. 그는 UNIX의 유명한 구문분석기인 LEX를 개발한 대단한 개발자다. 에릭 슈미트처럼 CTO가 비지니스 감각을 배우고 CEO로 전향한 경우도 많다.

 

- 관리자는 기술 전문가가 될 수 없다.

  전문개발자가 되려면 인사관리를 할 시간이 없다는 것이다. 미국의 소프트웨어 회사는 모두 관리직과 기술직의 두 경로로 나누어져 있다. 소프트웨어의 전문성을 이해하지 못하는 개발자가 있다. 원하는 것이 너무 많다. 개발자 경로에 있으니 코딩도 해야 한다고 하고 실력이 있으니 주니어 개발자의 기술 리더, 팀장이 되어야 한다고 하고, 그러면서 팀의 평가, 인사관리, 일정관리도 해야 한다고 한다. 필요로 하는 기능이 무엇인가 잘 알 고 있으니 제품기획도 할 수 있다고 한다. 혼자서 기술 전문가, 관리자 PM, 제품 마케팅 등 모든 역할을 다 하고 싶어 한다. 이 개발자는 다른 업무의 전문성을 이해하지 못하고 있다. 그중의 하나만도 잘하는 것이 어렵고, 하나만 잘해도 충분한 가치가 있는 것을 모르는 것. 인사관리에 발을 들여 놓는 순간 기술에 쏟아야 하는 시간을 빼앗긴다.

  '과거를 자랑하지 마라, 자랑할 과거밖에 소유한 것이 없을때 처량해 진다' 세익스피어

 

- 200의 능력을 가진 회사가 100에 만족하면 위험하다.

  미래 사상가인 앨빈 토플러 '과거에 성공을 거두는 데 도움을 주었던 제품, 프로세스, 조직 형태가 이제는 파멸의 원인이 되는 경우가 많다. 여기서 생존 기업이 되려면 제 1법칙은 뚜렷해진다. 즉 과거의 성공을 미래의 가장 위험한 요소로 파악해야 한다.'

 

- 소프트웨어 회사의 종류

  행정적 관점 : 패키지 소프트웨어 회사, IT서비스 회사, 임베디드 소프트웨어 회사, 콘텐츠 소프트웨어 회사

  개발방법론적 측면 : 패키지 소프트웨어 회사, SI(system intergration) 회사, 게임 개발회사, 웹 포탈 회사, 전자제품 제조회사(휴대전화,셋톱박스, 에어콘, 냉장고, TV등), 보안장비 개발회사 (FireWall, IPS, IDS 등), 전산팀(은행,증권사,대기업), On-Line 쇼핑몰 회사, 비즈니스 솔류션 개발회사, 라이브러리 개발회사, 소프트웨어 공학이나 개발도구 개발회사, 스마트폰 앱 개발 회사

  소프트웨어를 최소비용으로 최소시간에 개발한다는 목적 하에서 모든 소프트웨어 회사가 해야 할 일은 같다.

 

- 임베디드 소프트웨어의 본질, 컴포넌트와 인터페이스

  임베디드 시스템 (Embedded System, 내장형 시스템)은 시스템을 동작시키는 소프트웨어를 하드웨어에 내장하여 특수한 기능만을 수행하는 컴퓨터 시스템. 임베디드와 일반 소프트웨어의 다른점은 성능이 중요하다는 것 그리고 하드웨어 비용문제를 고려해야 한다는 점.

 

- 영업팀과 개발팀의 다툼은 건전한 것

  영업팀의 힘이 센 회사에서 개발팀은 빡빡한 일정으로 바쁠 것. 영업팀은 항상 이번 고객은 진짜 중요한 고객이라서 무조건 빨리 개발해야 한다고 한다. 그런 상황에서 개발자가 어떤 삶을 살아갈지는 눈에 선하다. 근본적으로 영업팀과 개발팀은 서로를 이해하지 못한다. 같은 회사에서 10년을 같이 근무했다고 해도 영업팀이 개발에 대한 통찰력을 갖기는 힘들고 개발팀이 영업팀의 고충을 가슴으로 느끼기도 힘들다. 영업은 하나의 고객만 있더라도 당장 제품을 판매하길 원하는 단기 전략이 우선이고, 개발팀은 선행연구도 해야하고, 유지보수도 걱정해야 하고, 버전도 최소해야 하고, 컴포넌트화된 산뜻한 제품을 만들기도 해야 하므로 중장기 전략이 우선이다. 미래 제품에 대한 아키텍처도 준비해야 하고, 기술 전략도 수립해야 한다. 이 두 팀이 잘 맞는다고 하면 회사에 심각한 문제가 있다는 것을 의미다. 그 다툼은 회사가 성장하면서 제품 영역이 넓어지고 고객이 늘어날수록 영원히 계속된다. 이 다툼을 조율하는 부서는 통상적으로 마케팅 부서다.

 

- 깨진 유리창 법칙

  스탠포드대학의 심리학자 필립 짐바르가 교수가 다음과 같은 실험을 했다. 치안이 허술한 골목을 고르고, 거기에 보존 상태가 동일한 두대의 자동차 창문을 열어놓은 채로 1주일간 방치해 두었다. 그 중 한대는 고의적으로 창문을 조금 깬 상태. 일주일후 단지 유리창을 조금 파손시켜 놓은 것뿐인데도 그렇지 않은 차와 비교하면 약탈이 생기거나, 파괴될 가능성이 매우 높아진다. 이것이 '깨진 유리창의' 시초다.

  상태계에서 파괴적인 습성을 가진 두 개가 있는데 인간과 바이러스라고 한다. 영화 <메트릭스>에 나오는 대사다. 지구의 모든 생명체는 환경과 잘 조화를 이루면서 살아가는데 인간과 바이러스만 자기가 사는 환경을 파괴하고 계속해서 다른 곳으로 옮겨간다고 한다. 그래서 기계가 인간을 컨트롤해야 좋은 세상이 온다는, 매트릭스를 설계한 아키텍트가 한 대사다.

 

- 시장은 창조하는 것이다.

  개리해멀은 <경영의 미래>에서 '미래는 예측하지 말고 창조하라'는 말을 했다. 피터 드러커도 다음과 같이 말했다. '우리는 미래를 예측할 수 없다. 대신 미래를 창조 할 수 있다.' 또 알랜 케이도 '미래를 예측하는 가장 좋은 방법은 미래를 만드는 것이다.' 예측은 해야한다. 사업계획서가 계획대로 실행된 경우가 있다면 기적이라고 본다. 그렇다고 사업계획 없이 시작한다면 그것은 더 위험한 일이다.

  먼저 아이디어를 가진 개발자 두세 명이 모여서 돈을 투자받기 위한 사업 계획서를 작성한다. 작성한 사업계획서를 벤처투자가에게 보여줘야 하는데 만날 기회가 없다. 벤처투자가는 시간이 돈인, 매우 바쁜 사람이라 아무하고나 얘기하지 않는다. 우연한 기회에 같은 엘리베이터를 탈 기회를 얻었는데 엘리베이터 안에 함께 머물수 있는 시간은 30초 밖에 없다고 하자. 이 짧은 30초 동안 얘기를 해서 벤처투자가의 흥미를 끈다. 이것이 바로 '30초 엘리베이터 스피치'라는 것. 짧은 시간에 매력적으로 설명해야 한다. 벤처 투자를 받기 전까지 회사 운영비를 위해 친지들한테서 조그만한 투자를 받기도 한다. 그들을 엔젤투자가라고 한다. 3F라고 하는데 Friends, Family, Fool을 의미한다. 그런과정을 거쳐 벤처투자가가 투자를 했다면 첫 번째 투자를 Series-A라고 부른다. 약 일 년 후에 또 투자를 받는데 그것을 Series-B라고 한다. 그 다음은 어느 정도 성공한 단계. 마지막 단계인 Series-C에서는 투자를 받고 주식시장에 상장한다. 아니면 인수합병 대상이 되어서 대기업에 팔린다. 이러한 상장이나 인수합병을 출구전략 (Exit Plan)이라고 한다. 이게 가장 통상적인 시나리오다.

  어느 단계에서 누가 이 벤처회사가 잘 되기를 바라고 도와주겠는가 ? 당연히 Series-A,B,C의 벤처투자가다. 그다음이 이사회의 이사다. 이사회는 'Board Of Driectors' (BOD)라고 한다. 혹은 짧게 Board라고 한다. BOD 멤버는 업계에서 영향력 있는 사람을 불러들인다. 그것도 투자가와 창업자의 능력이다. 한국의 형식적인 이사회와는 다르다. 이 투자가와 이사들이 회사가 잘되면 엄청나게 돈을 버는 사람이다. 얼마 전 구글의 CEO인 에릭 슈미트가 애플의 이사로 있다가 서로 경쟁을 하게 되니가 이사직을 물러났다. 두 회사가 본격적인 경쟁에 들어갔다는 것을 확실히 알 수 있다. 전략적인 파트너를 소개시켜 주기도 하고 회사 제품의 베타 사이트가 될 만한 고객을 구해 주기도 하고 또 Analyst라고 하는 업계의 전문가들에게 소개시켜 주기도 하고 잘 부탁하기도 한다. 이런 Analyst와 관계를 듀지하고 계속 공생하는 것이 벤처투자가이며 영향력 있는 이사들이다. 이들은 기회가 될 때마다 Analyst에게 연결해 주고 평가 대상에 선택되도록 노력한다, 그러니 항상 제품을 이해하고 있어야 한다. 그래서 벤처투자가의 투자 원칙 중 하나가 자기 사무실 근처에 있는 회사에 투자하는 것이다. 그래야 오다가도 들려서 어떻게 되는지 살펴보고 도와줄 기회를 찾을 수 있다. 가트너나 IDC같은 연구조사기관도 관계를 가지고 있어야 한다. 회사의 임원에게 당신 회사가 미래에 뭘 하려고 하느냐고 묻는 것이다. 임원은 자기 회사나 이해관계가 있는 회사에 도움이 되도록 시장이 이러저러하게 움직이고 있다고 얘기해 준다. 그 얘기를 전해 들은 조사기관은 미래의 시장은 이렇다고 큰 소리친다. 결국 시장은 이들이 장단을 맞추어서 만들어내는 것이다. 소비자는 그런 기사를 읽고 그 방향으로 움직인다. 시장은 이들에 의해 그 방향으로 흘러가는 것이다. 즉 시장은 생성되는 것이다.

 

-  신입사원은 문서(50%), 포로세스(45%), 선배(5%)로 부터 배운다.

  입사 첫날 관리자가 팀원들에게 인사시키고 자리를 안내 했다. 책꽂이가 어디 있는가를 알려주고 문서 몇 권을 주면서 읽으라고 했다. 학교에서는 들어보지 못했던 소프트웨어 개발방법론에 관한 책이 었다. SRS(Software Requirements Specification)를 작성하는 법, SDS(Software Design Specification)를 작성하는 법, 형상관리 규칙, 코딩 규칙 같은 것들이었다. 선배는 내게 아랑곳하지 않고 자기 맡은 일만 열심히 하고 있었다. 가끔가다 쉴때면 그때서야 나에게 이런 저런 얘기를 했다. 관리자는 가끔 들러서 체크하고 다음 읽을 책을 알려 줬다. 단 둘이 붙어서 일방적으로 배운적은 한번도 없다.

  위와 같은 환경에서 문서가 없다고 가정을 해보자. 도저히 배울 방법이 없다. 문서와 프로세스가 잘 되어 있지 않으면 신입사원은 선배 없으면 생존할 수 없는 상황이 된다. 이를 한국에서는 사수-조수 시스템이라고 부른다. 가내 수공업 시대 때나 성행하던 사수-조수 시스템이 문명의 최선두를 달리고 있는 소프트웨어 개발 현장에 아직도 나타난다는 것이 아리로니컬하다. 지식 공유가 효율적으로 이루어지려면 잘 작성된 문서와 프로세스가 필 수 조건이다.

 

- 최소 비용과 최소 시간

  (초보자) 시간 없는데 문서 만들지 말고 빨리 코딩 시작해야 하지 않습니까?

  (전문가) 왜 빨리 코딩을 시작해야 하나 ?

  (초보자) 제품을 빨리 만들어야 하니까요

  (전문가) 내가 바로 좋은 제품을 빨리 만들기 위해 문서를 만들고 있는 거야

  소프트웨어 공학의 유일한 목적은 '최소 비용으로 최소의 시간에 좋은 품질의 소프트웨어를 만드는 것'

 

- 서로 배우게 하라

  온라인 상점의 시초였던 비아웹의 공동창업자인 폴 그래함(Paul Graham)dㅣ 다음과 같은 얘기를 했다. '같이 일할 사람 한 명을 설득할 수 없다면 창업은 시작하지 않는게 좋습니다. 인생을 바쳐서 같이 일할 사람 두 명을 설득할 수 없다면 희망이 없습니다. 다시 말하건데 누군가 다른 한 사람을 공동 창업자로 구하십시오, 그것이 당신이 성공하기 위해 필요한 최소한의 일입니다.'

  다른 부서 일에 참견한다는 안 좋은 말을 들을지 모르지만 이런 사람이야 말로 회사에서 키워야 할 핵심 인력이다. 문제를 숨기는 것보다 다른 사람의 잘 못을 지적해 내는 사람이 그 순간에는 거북할지 모르나 신뢰할 수 있고 중요한 일을 해낸다.

  진정한 소프트웨어 전문가가 되기 위해서 어려운 세 가지가 있다. 좋은 개발환경을 접하기가 어렵고, 좋은 스승을 만나기가 어렵고, 마지막으로 자기자신이 깨닫기가 어렵다.

 

- 동료검토는 권장하지마라.

  동료검토는 개발의 가장 앞 단계부터 수행되어서 정보 공유가 계속되어 왔어야 가치가 있다. 이런 선행조건이 없다면 필자는 동료검토를 권장하지 않는다.

 

- 조삼모사, 유지보수의 늪에 빠지다.

  어느 개발자가 설계도 안하고 스펙도 안 적고 그냥 100시간 코딩해다고 치자, 필자는 시간이 없어서 코딩한다는 개발자치고 제대로 스펙을 적고 개발한 사람을 본 적이 없다. 현명한 개발자라면 30시간은 스펙에, 30시간은 설계에 30시간은 코딩에 사용해서 총 90시간으로 단축할 수 있다.

 

- 머지 데이를 정해서 할 이유가 없다.

  두 개의 수정된 코드를 가져다 놓고 합치는 행위가 2-Way 머지

  최초의 원본과 수정된 2개의 파일, 모두 3개의 이용해서 머지를 하는 3-Way 머지.

 

- 배우려면 잔을 비워라.

  시간을 절약하는 방법을 가르쳐 주려는데 시간이 없어서 배우지 못한다는 것은 자기 모순적인 상황이다. 이를 소설에서 유래한 '캐치-22'라고 한다. 한 마디로 빈곤의 악순환이다.

 

-  백발이 성성한 프로그래머는 없다.

  프로그래머는 수년의 경력 정도면 한계에 이른다. 프로그래밍 기술은 소프트웨어 개발의 시초이며 핵심 역량이지만 개발자의 경력으로 계속 유지될 수 있는 기술은 아니다. 'Are you a softwear engineer?'가 맞는 표현

  코딩을 하고 싶어서 개발자가 된 사람에게는 미안하지만 아르바이트생 프로그래머와 별로 위상이 다르지 않다고 말하고 싶다.

  백발이 성성한 개발자는 프로그래머와 구별되어야 하고 가치를 인정받아야 한다.

 

- 비싼 도구가 기술 역량을 올려주지 않는다.

  과거에 메인프레임에서 포트란 프로그래밍을 할 때는 모니터와 키보드가 아니라 천공기에서 카드 한 짱씩 찍어가면서 프로그래밍을 했기 때문에 실수하면 카드 값도 들고 타이핑도 다시 해야 하고 또 컴퓨터 시간도 순번제로 기다려야 하기 때문에 코드를 적을 때 심사숙고 생각했었다. 그래서 그 때는 에러도 적고 항상 전체적으로 모든 것을 생각하는 버릇이 되어 있었는데 요새는 대충 준비되면 소스코드 적는다고 달려든다. 도구가 좋아서 생기는 나쁜 현상이다. 도구를 사용하되 생각은 도구가 없는 환경에서처럼 하라고 권유하고 싶다. 가장 성능이 좋다고 평가받는 컴파일러도 오픈소스인 gcc이다. 가장 많이 사용하는 소스관리 도구도 역시 오픈소스인 SVN이다. 이슈관리 시스템도 마찬가지로 오픈소스인 Mantis가 가장 많이 사용된다. 구글의 안드로이드 프로젝트도 리누스 토발즈가 만든 GIT라는 오픈소스 무료 소스관리 도구를 사용한다.

 

- 표현법이 진보를 가져오지는 않는다.

  표현법은 가장 마지막 단계일 뿐이지 모든 것은 머리로 생각한다. 설계의 핵심은 컴퓨넌트와 인터페이스를 간단하고 깨끗하게 정의하는 것이다. 이는 머리로 하는 것이지 도구로 하는 것이 안다. 그 결과를 표현하는 수많은 정형적인 혹은 비정형적인 방법이 있으니까 적절히 사용하면 되는 것이다. 지금까지 있었던 프로그래밍 언어 중 가장 뛰어난 객체지향 언어는 SmallTalk이라고 한다. 그 후에 나온 인기 있는 C++이나 Java가 객체지향의 진화를 가져오지는 않았다. 마치 표현법이 바뀌면 대단한 진화를 한 것처럼 생각하는데 착각이다. 머리 속으로 분석하고, 머리 속으로 설계하고, 머리 속으로 코딩하는 법을 익히는 것이 진정으로 소프트웨어 개발에서 전문가가 되는 길이다.

 

- 지식과 기법은 달콤한 사탕과 같다.

  세 가지 유형의 개발자. 첫째 원론적인 것에 치우친 사이언티스트, 둘째 테크니션형은 기법적인 것에 신경을 쓴다. 마지막으로 개발자는 현실에서 고객이 무엇을 원하고 어떻게 하면 좋은 품질의 제품을 빨리 개발할 수 있을까 하는 것에 초점을 둔다. 즉 표현은 못하지만 실행할 줄 아는 암묵적 지식의 소유자다. 세 유형 모드 소프트웨어 회사에 어느 정도 필요한 존재다.

  도구를 잘 아는 사람은 Technician, 알고르즘에 신경 쓴다면 Scientist, 워드프로세서 사용법을 잘 아는 사람은 문학 Technician이다. 문학의 역사, 문학의 종류, 소설가의 생애와 업적 등을 잘 알고 있다면 '문학 Scientist'이다. 반면 실제 소설을 잘 쓴다면 '문학 Engineer'이다.

 

- 스파트폰, 소프트웨어 공학을 경험할 좋은 기회

  스마트폰 앱은 혼자서 개발하는데 뭐 하러 문서를 만드나? 라고 반문할지 모른다. 핵심은 문서의 양과 질이다. 스마트폰 개발처럼 소프트웨어 공학의 여러 측면을 다양하게 경험 할 수 있는 기회도 드물다. 큰 규모가 아니면서도 여러 플랫폼, 수많은 버전관리, 수많은 언어 지원과 같이 세계화를 목적으로 만든 애플리케이션이라면 꼭 다루어야 할 주제를 다 포함하고 있다. 스마트폰 앱을 개발하려고 할 때 지원해야 할 스마트폰 플랫폼을 살펴보자. 통상적으로 3단계 지원계획. 1단계 아이폰(아이패드) 안드로이드 지원, 2번째 블랙베리, 윈도우폰7 ... 초기에 시간이 들더라도 정교한 계획과 아키텍처를 결정하고 시작하는 것이 현명하다. 전 세계에 제품을 팔고 싶다면 방법을 바꿔야 한다. 돈키오테 같은 무모한 열정으로도 드물게 성공하기 하지만 현명한 방법은 아니다. 멀티-플랫폼에서의 디버그 방식만 해도 여러 가지를 고려해야 한다. 일단 모든 오류번호와 오류메시지도 통일해야 하고 그러려면 공통 파일을 공유해서 사용해야 하고, 소싀관리시스템도 그에 맞게 정교한 구조를 가져야 한다. 또 수많은 플랫폼, OS버전, 기기종류에서 발생하는 이슈나 오류를 추적하기 위해선 지금까지의 관리 방식보다는 더 복잡하고 체계적인 이슈관리 시스템을 필요로 한다.

 

- 기업문화란 무엇인가 ?

  세계적인 소프트웨어 개발자가 이런 회사에 와서 일한다고 해도 상황이 바뀌지 않는다. 기술은 있지만 문화의 희생물인 또 한명의 힘없는 개발자로 남을 것이다. 학습된 무력감 (Learned Helpllessness) 현상이 나타난다. 개에게 전기충격을 주면 처음에는 충격을 피하려고 뛰기도 하고 도피하려고도 하며 활동적으로 움직이다가 전기 충격이 계속 가해지면 나중에는 도피하려는 의욕도 없고 아무것도 하지 않으려 하고 무기력해진다는 것이다.

  우슷갯소리를 하나 더 소개한다. 참새 세 마리가 줄에 앉아 있다. 이중 두마리가 날아가기로 마음먹었다. 잠시 후에 남아 있는 참새는 몇 마리인가? 답은 여전히 세마리다.

 

반응형