| 000 | 00653camcc2200217 c 4500 | |
| 001 | 000045688301 | |
| 005 | 20120202165819 | |
| 007 | ta | |
| 008 | 111227s2011 ggka 000c kor | |
| 020 | ▼a 9788992939973 ▼g 93560 | |
| 035 | ▼a (KERIS)BIB000012620072 | |
| 040 | ▼a 211062 ▼c 211062 ▼d 244002 | |
| 082 | 0 4 | ▼a 005.1 ▼2 22 |
| 085 | ▼a 005.1 ▼2 DDCK | |
| 090 | ▼a 005.1 ▼b 2011z18 | |
| 100 | 1 | ▼a 신승환 |
| 245 | 1 0 | ▼a 대한민국 소프트웨어, 리스타트 : ▼b 위기를 넘어 도약으로 / ▼d 신승환 지음 |
| 260 | ▼a 파주 : ▼b 위키북스, ▼c 2011 ▼g (2012) | |
| 300 | ▼a 287 p. : ▼b 삽화 ; ▼c 23 cm | |
| 440 | 0 0 | ▼a 위키북스 IT leaders 시리즈 ; ▼v 014 |
소장정보
| No. | 소장처 | 청구기호 | 등록번호 | 도서상태 | 반납예정일 | 예약 | 서비스 |
|---|---|---|---|---|---|---|---|
| No. 1 | 소장처 과학도서관/Sci-Info(1층서고)/ | 청구기호 005.1 2011z18 | 등록번호 121216738 (4회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
| No. 2 | 소장처 과학도서관/Sci-Info(1층서고)/ | 청구기호 005.1 2011z18 | 등록번호 121216739 (4회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
| No. 3 | 소장처 세종학술정보원/과학기술실(5층)/ | 청구기호 005.1 2011z18 | 등록번호 151305180 (3회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
| No. | 소장처 | 청구기호 | 등록번호 | 도서상태 | 반납예정일 | 예약 | 서비스 |
|---|---|---|---|---|---|---|---|
| No. 1 | 소장처 과학도서관/Sci-Info(1층서고)/ | 청구기호 005.1 2011z18 | 등록번호 121216738 (4회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
| No. 2 | 소장처 과학도서관/Sci-Info(1층서고)/ | 청구기호 005.1 2011z18 | 등록번호 121216739 (4회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
| No. | 소장처 | 청구기호 | 등록번호 | 도서상태 | 반납예정일 | 예약 | 서비스 |
|---|---|---|---|---|---|---|---|
| No. 1 | 소장처 세종학술정보원/과학기술실(5층)/ | 청구기호 005.1 2011z18 | 등록번호 151305180 (3회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
컨텐츠정보
책소개
대한민국에서 좋은 소프트웨어가 나오지 않는 이유는 뭘까? 좋은 소프트웨어가 나올 만한 환경이 아니라서 정부나 회사에서 그토록 바라는 좋은 소프트웨어가 나오지 않는 것이다. 컴키드에서 소프트웨어 컨설턴트로서 우리나라 소프트웨어의 현실을 경험한 저자가 어떻게 하면 좋은 소프트웨어를 탄생시키는 개발문화를 만들어낼 수 있을지, 그 해법을 제시한다.
얼마 전에 중소기업에서 초봉 4천만원을 제시해서 65:1이라는 놀라운 경쟁률을 보였다는 기사가 있었다. 이에 반해 SI 업체에서는 날코딩에 해당하는 업무를 백만 원이 조금 넘는 돈으로 중국에 아웃소싱할 수 있어, 비용 측면에서 상당한 이득을 보고 있다는 기사도 소개됐다. 사실 이 이야기는 새삼스러울 것도 없다. 그런데 그 기사의 댓글을 읽다가 먹먹해졌다. 자신들도 백만 원 조금 넘는 돈 받아가면서 일하고 있다는 댓글이 상당수 달렸기 때문이다.
삼성전자에서는 소프트웨어 인력을 확실히 키우기 위해 S직군을 신설했다는 소식도 전해졌다. S직군은 기본적으로 다른 직군에 비해 초봉도 높고 대우도 좋다고 한다. 삼성전자인만큼 여타 대기업보다 훨씬 더 많은 돈을 줄 것임이 틀림없다. 여기에 더블S라는 신조어도 나온다고 한다. S직군에서도 S급 인재를 말한다고 한다. 옥상옥 정도가 될까?
같은 대한민국 아래에서 소프트웨어라는 타이틀을 걸고 일어나는 인재전쟁을 관통하는 키워드가 있다. 바로 돈이다. 신입사원들이 중소기업을 꺼려한다고 하지만 돈만 많이 준다면, 그곳이 비정상적인 회사가 아닌 이상 지원하는 건 인지상정이다. SI 업체는 비용 절감을 위해 외국으로 잇달아 나가고 있다는 기사와 최상위권에 속하는 회사에서는 최고의 인재를 대우한다는 기사, 그리고 최근에 개발자 모집과 관련해 넘쳐나는 기사에서 공통점을 찾을 수 있다. 바로 돈이다.
기사에 나오는 대한민국 소프트웨어 살리기 해법은 개발자에게 돈만 많이 주면 될 것처럼 비춰진다. 과연 그럴까? 회사에서는 직원들을 동기부여하려고 노력한다. 그리고 어떤 이상가들은 직원들에게 꿈과 비전을 심어서 동기부여하라고 한다. 그러면서 돈이 중요하지 않다고 한다. 진짜? 그럴싸한 이론을 가져다 붙이지 않더라도 먹고사는 데 돈이 필요하기 때문에 당연히 돈은 중요하다. 하지만 돈으로 모든 문제가 해결되지 않는다는 건 보상이론이나 행동경제학 같은 것들로 충분히 실증되고 있다.
핸드폰 제조업계에서 유발된 소프트웨어 위기로 우리는 모두 개발자를 잘 대우하고, 그래야 경쟁력 있는 소프트웨어가 나온다고 생각한다. 그런데 소프트웨어는 최근에 위기를 맞은 게 아니라 저자가 이 세계에 입문했을 때인 20여 년 전부터 위기였다.
소프트웨어는 돈을 주고 사는 물건이 아니라, 아는 형이나 아는 동생한테 부탁만 하면 디스크나 CD로 구해서 설치할 수 있는 품앗이 대상이었다. 그래서 최근에 급부상하는 소프트웨어 위기는 정말로 허구다. 그 허구는 핸드폰 제조업의 추락 때문에 생겨난 것이다. 즉, 제조업의 붕괴 때문에 발생한 대기업의 위기를 걱정하면서 생겨난 것이다.
소프트웨어 위기가 제조업의 붕괴에 대한 걱정 때문에 조명을 받았든 받지 않았든, 소프트웨어가 현재 위기에 처한 원인을 되짚어 보면 결국 소프트웨어를 제값 주고 사지 않았다는 데 있다. 만약 좋은 소프트웨어에 대해 적절한 비용을 지불하고 구입하는 문화가 있었다면 우리나라 소프트웨어는 위기에 처하지도 않았을 것이며, 그토록 많은 개발자 지망생이나 경력 개발자들이 월급 많이 주주는 회사에 취직하려고 목숨을 걸지도 않았을 것이다. 이런 생각이 너무 단순한 생각일까?
물론 지금에라도 개발자들이 중요하다는 사실을 인식하고 그들에게 제대로 된 대우를 해주는 건 다행이다. 하지만 소프트웨어 생태계가 복원되지 않고 단순히 제조업의 영속만을 위한 개발자 키우기(다시 말해, 개발자 모집하기)에만 집중한다면, 그리고 돈도 중요하지만 돈으로 살 수 없는 가치를 소중히 여기는 개발 문화가 생기지 않는다면 정말 대한민국의 소프트웨어가 처할 미래는 암울할 것이다. 자, 그렇다면 좋은 소프트웨어를 만들어내는 좋은 개발 문화는 어떻게 만들어낼까?
우선 앱 시장처럼 돈을 주고받는 시장이 조금씩 살아난다는 건 다행이다. 이런 경제적 환경의 개선과 더불어 소프트웨어를 만들어내는 개발문화도 바뀌어야 한다. 컴키드에서 소프트웨어 컨설턴트로서 우리나라 소프트웨어의 현실을 경험한 저자가 어떻게 하면 좋은 소프트웨어를 탄생시키는 개발문화를 만들어낼 수 있을지, 그 해법을 제시한다. 자! 이제부터 대한민국 소프트웨어를 리스타트해보자!
정보제공 :
저자소개
목차
목차 시작하는 글 = 9 대한민국 소프트웨어는 위기? = 10 PART 01 소프트웨어 엔지니어링을 지배하라 = 25 정도의 차이가 있을 뿐 요구사항 명세는 개발의 핵심이다 = 30 요구사항, 요구사항 명세, 설계는 다르다 = 34 회사에서 만드는 소프트웨어가 망해간다면 UX에 주목하자 = 42 UX란 개발 이상의 것이다 = 46 사용자의 말보다 행동을 믿자 = 53 아키텍트가 없더라도 아키텍처는 꼭 필요하다 = 57 PM과 아키텍트는 다르다 = 61 사공이 많은 프로젝트 팀이라면 아키텍트가 반드시 필요하다 = 64 매뉴얼을 만들기보다 매뉴얼이 필요 없는 소프트웨어를 만들자 = 68 제대로 테스트하려면 자원, 프로세스, 문서가 필요하다 = 71 최적의 테스트 기법을 찾아라 = 74 테스트하기 전에 품질을 개선할 수 있는 방법이 있다면 그걸 선택하자 = 78 개발자도 테스트해야 한다 = 81 형상관리와 버전관리는 다르다 = 85 소프트웨어 프로덕트 라인은 은총알이 아니다! = 90 우수한 품질은 명확한 품질 기준에서 나온다 = 95 QA는 체크리스트를 채우는 게 아니라 품질을 완성하는 것이다 = 98 프로세스를 개선하려면 절차, 도구, 인력 모두 개선해야 한다 = 104 CMMI와 애자일 방법론은 양립하기가 매우 어렵다 = 108 애자일 방법론은 한물 간 방법론이 아니다! = 114 CMMI가 적당한 조직이 있다! = 120 레거시의 저주를 피하려면 선배, 후배 모두 노력해야 한다 = 128 PART 02 소프트웨어, 사람이 만든다! = 133 자격증이 프로젝트 관리자의 역량을 보증하지 못한다 = 137 인본주의 관리가 효과가 있으려면 개발자의 자세가 매우 중요하다 = 140 진짜 보수개발자와 진짜 진보개발자가 일하는 문화를 만들자 = 143 업무가 중심이 되는 일터를 만들자 = 148 야근은 필요악이라도 악일 뿐이다 = 154 관리자는 회의를 하면 일을 한다고 생각한다. 이건 정말 착각이다! = 163 이해당사자의 역학관계를 파악하자 = 169 일을 지정하기보다 범위를 정하자 = 173 멋진 의사결정 결과보다 그 과정이 더 중요하다 = 177 신입사원에게는 멘토링을 하자 = 181 피드백이 성공하려면 문제에 대한 객관화가 먼저다 = 186 이기지 않는 게 이기는 것이다 = 189 아이디어를 많이 얻으려면 말을 자르지 마라 = 193 너무 적게 혹은 너무 많이 측정해서는 안 된다 = 196 프로젝트 관리자는 완전한 잣대가 돼서는 안 된다 = 201 갑질은 대물림해서는 안 된다 = 205 을을 대하는 자세 = 209 외호내혐 PM이 강한 팀워크를 만들 수도 있지만 그래도 문제는 있다 = 213 관리자도 0.5MM는 힘들다 = 217 영업을 하든 관리를 하든 둘 중에 하나만 하자 = 220 권한이 없다면 관리할 수 없다 = 223 성공일지라도 팀원이 꼭 좋아하는 건 아니다 = 227 프로젝트에서 시간은 늘 부족하다 = 231 열심히 일한 개발자에게 잠깐의 휴식이라도 허하라 = 233 PART 03 위험을 감수하고 이익을 극대화하라! = 239 제안서나 기획서가 아무리 상세해도 불확실성을 최소화하지 못한다 = 243 위험, 이슈, 문제를 구분하자 = 247 PM은 불확실성의 화신이다 = 252 불확실성이 제거되지 않는다는 건 프로젝트가 망해간다는 명백한 증거다 = 256 불확실성을 극복하려면 팀 내 이견을 최소화해야 한다 = 259 일찍 실패하는 것이 좋다 = 263 계획이 변하더라도 계획은 늘 세워야 한다 = 266 프로젝트는 어쨌든 끝난다 = 270 맺는 글 = 275 오픈 이노베이션을 DNA화하라, 그리고 DNA의 핵심은 사람임을 잊지 말자! = 276



