• 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학론

출판사 리뷰

일반적인 개발자들은 겸손한 태도로 자신이 맡은 역할을 성실히 그리고 묵묵히 해내고 있다. 그런데 그들의 손에 의해 빚어진 소프트웨어는 왜 거만한 모습으로 나타나는가? 이 책은 그 태생적이고 구조적인 원인을 적절한 예와 심플한 논조로 가볍게 풀어내고 있다.

- 개발자는 사용자를 잘 알고 있는가
- 프로젝트에 잘 맞게 정리된 방법론을 구체적인 현실에 제대로 구현하고 있는가
- 팀원 간에, 고객과의 관계에서 행하는 의사소통은 효과적인가
- 원활한 의사소통과 개개인의 암묵지를 담아낼 정도로 조직은 유연한가

이어서, 이 거만한 소프트웨어의 탄생을 막아낼 실천적 대안으로 PAPER원칙을 제안한다.
1. Peopleware
2. Active involvement
3. simPlicity
4. Experience
5. Repetition
6. PAPER

프롤로그; 여기서 치이고 저기서 치이는 겸손한 개발자 나대리, 온갖 악조건 하에서도 열심히 개발했지만, 결과는 사용자의 불만 가득한 목소리뿐이다. 그 원인은 무엇인가?

1~5장: 거만한 소프트웨어가 나오는 원인을 짚어 본다.
사용자와 개발자의 인식의 차이, 효율성만 쫓는 권위적인 조직 그리고 개인 간 의사소통의 실패, 이 모든 원인이 어우러져 거만한 소프트웨어가 탄생하게 된다.

- 하이테크 제품이라도 낮은 수준의 소프트웨어를 탑재하면, 품질 딱 그 소프트웨어의 수준만큼 떨어진다. 제품의 질만 떨어뜨리고, 사용자를 고려하지 않은 소프트웨어, 그것이 거만한 소프트웨어다.
- 사용자는 개발자가 생각한 대로 소프트웨어를 쓰지 않는다. 화성에서 온 개발자, 금성에서 온 사용자처럼 한 가지 소프트웨어에서 두 가지 사용법을 발견하기도 한다. 개발자는 사용자의 심리를 잘 이해하면서 소프트웨어를 만들어야 한다.
- 기능이 너무 많아도 사용자는 혼란스럽다. 꼭 필요한 기능을 직관적으로 쓸 수 있게 만들어야 한다.
- 실패를 개선의 기회로 바꾸지 않는 조직, 방법론만 적용하면 모든 게 잘 될 것이라는 착각에 빠진 조직, 효율화라는 명목으로 직원들을 내보내고 아웃소싱에 개발을 맡기는 조직, 단기적으로는 효율적이지 모르지만 장기적으로 손해를 입을 것이다.

6~16장: 그럼 이것의 원인을 어떻게 제거할 것인가?
해답은 PAPER원칙을 실천하는 것이다. PAPER 원칙은 그 원인을 제거하는 실천법(People, Active involvement, simPlicity, Eexperience, Repitition & Paper)이다.

- 무조건적 야근은 근본적인 해결책이 될 수 없을뿐더러 인센티브는 최종 보상이 되지 못한다. 내가 일하는 데서 보람을 얻는다는 느낌을 주는 것이 중요하다. 부서 사이에 협력이 되지 않을 때, 사일로가 생겼다고 한다. 다른 부서 사이에(디자인 부서+개발 부서) 존재하는 의견 대립에 타협점을 끌어내고 원래의 목표대로 팀을 이끌어 주는 제품 통합자가 필요하다.
- 개발자가 프로그램을 단순하게 만들면 사용자가 힘들다. 프로그램에 갖가지 기능을 넣었다고 외양을 복잡하게 만들어도 사용자가 힘들다. 가장 좋은 방식은 기능이 복잡하더라도 외양이 단순해 보이고 쓰기도 쉬워야 한다는 것이다.
- 프로젝트에 들어가기 전에 생각의 차이를 좁히고, 프로젝트 성격에 대한 합의를 거쳐야 프로젝트 진행에 있어 혼란이 적어진다.
- 사용자가 소프트웨어를 어떻게 사용하는지 알려면 인터뷰만 하지 말고 인터뷰와 동시에 그 사람이 어떻게 움직이며 어떻게 일하는지 관찰해야 한다. 일하는 맥락에서의 소프트웨어 사용법을 파악하는 것이 바로 맥락을 살피는 인터뷰다.
- 프로젝트 진행 시 그냥 반복하지 말고, 한 번 반복할 때마다 개선을 해 나가는 '지속적인 반복'이 필요하다.
- 일하면서 글로 적어두지 않은 경험과 노하우가 많다. 이런 것들을 정리해 조직적으로 학습을 해야 한다.
- 소프트웨어는 사람이 전부다. 오랫동안 부린 땅은 일정 기간 쉬게 해주듯이(아직 실현 가능성은 적지만) 사람에게도 안식년이라는 보상이 필요하다.

프롤로그 겸손한 개발자, 나대리 이야기

1장 과잉 친절의 시대, 그리고 거만한 소프트웨어
1-1 과잉 친절의 시대
1-2 No Software, It’s Everyware!
1-3 거만한 소프트웨어란?
1-4 거만한 소프트웨어를 만드는 것들


2장 개발자는 사용자를 모른다
2-1 보이는 것을 넘어서
2-2 엘리베이터 버튼: 심성 모형
2-3 Y를 깔았더니 X가 안 되요!: 귀인
2-4 앗! 나의 실수: 대응
2-5 한글인가? 젠장 영어잖아!: 주의 소재
2-6 사람한테 겨냥하지 마세요: 행동유도성
2-7 카드를 삼킨 욕심쟁이 현금인출기: 피드백
2-8 보기 좋은 떡이 맛있다!: 감성
2-9 개성이 없는 자동차: 색각 장애
정리

3장 GUI 문제
3-1 다다익선?
3-2 GUI, GUI, GUI
3-3 기술주도의 발전, 그리고 마케팅의 탄생
3-4 내가 필요한 건 믹서기
3-5 지금까지 통한 법칙
정리

4장 우리에게 있는 문제
4-1 성공신화
4-2 ‘우리만 그렇다는 미신’과 ‘우리만 그런 현실’
4-3 방법론이라는 애물단지
4-4 도덕적 해이?
정리

5장 조직의 문제
5-1 그릇이 다르면 장맛이 다르다
5-2 회사의 탄생
5-3 사일로의 등장과 위기
5-4 J-Firm vs. A-Firm
5-5 조직의 실패, 그리고 거만한 소프트웨어
정리

6장 PAPER원칙
6-1 프로젝트 이야기 두 개
6-2 쿨미디어 그리고 프로젝트 성공
6-3 거만한 소프트웨어를 만드는 원인
6-4 PAPER 원칙이란

7장 칼퇴근
7-1 이념 논쟁
7-2 팀워크가 전체주의가 될 때
7-3 3M, Muda, Muri, Mura
7-4 여유, 품질을 고민하는 시간
7-5 숨겨진 야근
7-6 근태가 성공 기준인 프로젝트
7-7 이것만은 잊지 말자!

8장 적절한 보상
8-1 돈에 관한 몇 가지 단상
8-2 관찰이 행동을 변화시킨다
8-3 인센티브, 그 오묘함
8-4 이 시대의 적절한 보상
이것만은 잊지 말자!

9장 자리 배치
9-1 파놉티콘
9-2 의사소통 게임
9-3 프로젝트 룸
9-4 이것만은 잊지 말자!

10장 사일로를 파괴하라!
10-1 팀을 구성하는 방법
10-2 무한 도전과 교훈
10-3 다양한 분야에서의 성공
10-4 제품 통합자
이것만은 기억하자!

11장 단순함의 법칙
11-1 메시지 창, 참을 수 없는 존재
11-2 구현할 때 단순함 vs. 사용할 때 단순함
11-3 구조조정이 정말로 필요한 곳
11-4 소프트웨어 생태계
11-5 단순함의 법칙 몇 가지
이것만은 잊지 말자!

12장 팀 빌딩
12-1 비밀작전 같은 프로젝트
12-2 프로젝트 관리계획 세우기, PM만의 임무?
12-3 스파게티 회식, 그리고 프로젝트 시작
12-4 팀 빌딩 방법
이것만은 잊지 말자!

13장 맥락을 살피는 인터뷰
13-1 사용자를 아는 방법
13-2 맥락을 살피는 인터뷰 방법
13-3 맥락 인터뷰 해석하기
이것만은 잊지 말자!

14장 반복을 계획하라!
14-1 지금까지 살펴 본 반복개발의 필요성
14-2 팀 빌딩에서 세우는 최초 반복주기
14-3 추정하기
14-4 두 번째 반복주기부터 할 일 기
이것만은 잊지 말자!

15장 암묵지를 조직화하라!
15-1 배움의 시작
15-2 학습의 방법
15-3 조직적인 학습
15-4 찻잔 속의 태풍
이것만은 잊지 말자!

16장 21세기 안식년
16-1 이직과 손실
16-2 암소 숭배 사상, 안식년
이것만은 잊지 말자!

에필로그
주
참조한 책