책: 모던 소프트웨어 엔지니어링 - 1부

개요

출간 소식에 관심이 있던 모던 소프트웨어 엔지니어링. 언제고 읽어야지 했는데 출판사에서 주최하는 북토크에 참석하게 되어 예습을 겸하여 읽어보았다. 결론부터 말하자면 현실과는 동떨어진, 대학때 배웠던 과목으로만 기억했던 소프트웨어 공학이, 이 책의 제안과 시도로 재정립되어 여타 공학들(토목, 건축, 화학, 전자 등)과 견줄 날이 올 수 있겠다는 기대가 되었다.

저자는 소프트웨어 공학을 다음과 같이 말한다.

소프트웨어 공학software engineering은 소프트웨어의 현실적인 문제를 풀기 위한 효율적이고 경제적인 해법을 찾아 나서는 경험적이고 과학적인 접근 방식의 응용이다. p31

이렇게 풀어서 말해보자.

1. 해결해야 할 현실적인 문제가 있다.
2. 이 문제는 소프트웨어를 통해 해결해야 한다.
3. 해결 방법은 효율적이고 경제적이어야 한다.
4. 공학은 단순한 해결이 아닌, 현실적인 제약 속에서 최적의 방법을 찾는 것을 중요시한다.
5. 이러한 해결 방법은 경험과 과학적 접근을 바탕으로 한다.
6. 소프트웨어 공학은 이 두 가지 기반을 응용하여 실질적인 해법을 설계하고 구현해낸다.

정리

책에서 이야기하고자 하는 중요 개념을 정리해본다.

학습 5원칙과 복잡성 관리의 5원칙

이 책에서는 이를 해소하기 위해 과학적인 방식으로 가설을 수립하고 실험하고 여기서 얻은 결과를 토대로 점진적으로 역량을 높여가는 과정인 학습을 강조한다. 또한 우리가 직면한 다양한 문제와 이 문제를 풀기 위한 해법의 복잡성을 관리하기 위한 전문가가 되어야 한다고 제안한다. p19

학습 5원칙

• 반복 iteration
• 피드백 feedback
• 점진주의 incrementalism
• 경험주의 empericism
• 실험 experimentation

복잡성 관리 5원칙

• 모듈성 modularity
• 응집성 cohesion
• 관심사 분리 seperation of concerns
• 정보은닉(추상화) information hiding(abstraction)
• 결합도 managing coupling

소프트웨어 공학의 참뜻

프로덕션 목적의 공학과 설계 목적의 공학

TL;DR. 대부분 분야의 공학은 제품을 만들어내는, 프로덕션 목적의 공학이다. 하지만 소프트웨어 공학은 설계 목적의 공학이어야 한다. 그동안의 소프트웨어 공학의 실패는 프로덕션 목적의 공학으로 접근한 것에 기인한다.

설계를 위한 공학

소프트웨어 공학은 설계를 위한 공학이기에 유리한 점이 있다. 다리를 만드는 공학자는 설계가 끝나면 이제부터 시작이다. 모든 시뮬레이션이 끝나면 실제로 물리적인 다리를 건설하는 프로덕션 공학이 기다리고 있는 것이다. 하지만, 소프트웨어 공학은 바로 그 시뮬레이션 자체가 우리의 제품, 프로덕션이다.

공학은 코드가 아니다

소프트웨어 공학은 코드, 설계와 같은 결과물이 아니다. 공학은 결과물을 만들어내는 과정이다. 공학은 프로세스이며, 도구이고, 기법이다. 공학은 아이디어이며, 철학이며, 접근 방식이다. 소프트웨어 공학은 소프트웨어를 만드는 데 필요한 모든 것이다.

이 책에서 내가 공학이라고 이야기할 때는 특별히 한정하지 않는 이상 소프트웨어를 만드는데 필요한 모든 것을 의미한다. 프로세스, 도구, 문화 이 모두가 전체의 일부다. p54

소프트웨어 장인과 소프트웨어 공학

기술을 아는 사람 → 소프트웨어 장인 → 소프트웨어 공학이라는 방향성을 가지는 것이지 둘이 서로 대립하거나 양립하는 것이 아니다. 단지 기술을 아는 사람에서 장인 정신을 가지고 소프트웨어를 만드는 사람으로 성장하는 것이지만 이러한 수공예의 한계를 뛰어넘기 위해 공학이 필요하다.

조선의 도자기 수공예 장인은 명품을 만들었지만 현재는 공학을 적용한 도자기 공장이 좋은 제품을 안정적으로, 반복해서 만들고 있다. 수공예 장인도 소중하지만 우리는 공학이 필요하다.

공학은 수공예로부터 더 확장 가능해지고 더 효과적으로 변신한 자손이다. p65

생산성 측정의 두 기준

안정성과 처리량이라는 두 기준으로 생산성과의 인과관계까지는 몰라도 상관관계는 발견했다고 한다. 실제 조직에서는 이를 어떻게 측정할 수 있을까 고민이 되기는 했다. 이 두가지를 생산성 측정도구로 사용하자. 조직, 팀, 코드 자체에서 변화를 일으키고 이 두 기준이 어떻게 변하였는지 측정하는 것이다.

안정성

• 변경 실패율change failure rate: 코드 수정했는데 문제 생긴 비율
• 복구 실패 시간recovery failure time: 실패한 뒤 복구까지의 시간

처리량

• 리드 타임lead time: 아이디어가 실제 동작하는 소프트웨어가 되기까지의 시간
• 빈도frequency: 변경사항이 프로덕션으로 배포되는 빈도

밑줄

인상 깊었던 부분과 생각을 기록해둔다.

이 책은 소프트웨어에서 문제를 해결하기 위한 현실적이고 실용적인 접근방법에 기초하고 있으며 과학적인 기초원리의 비공식적인 채택, 다시 말하여 공학에 기반한다. p36

공학이란 과학의 비공식적인 채택! 공학을 기반으로 하여 현실적이고 실용적으로 소프트웨어를 이용해 문제를 해결한다.

이 책은 더 나은 소프트웨어를 안정적이고 반복적으로 만들기 위해 적용해야 하는 규율, 프로세스, 아이디어에 관한 책이다. p30

독일 맥주는 순수령이라는 법령 덕분에 흥할 수 있었다. 제대로된 규율과 프로세스, 그리고 아이디어를 강제하는 것은 어느 프로젝트이건 더 나은 소프트웨어를 안정적으로 만들 수 있게 만든다.

인간 조직도 여느 컴퓨터 시스템과 마찬가지로 정보 시스템에 불과하다. p82

우리가 시스템을 만들 때는 만들고 있는 시스템의 복잡도를 관리할 필요가 있으며, 단일 소규모 팀의 범위를 넘어서 큰 규모로 일을 수행하려면 더 기술적인 소프트웨어 정보 시스템은 물론이고, 조직 정보 시스템의 복잡성도 관리할 필요가 있다. p83

복잡도 관리는 단순히 코드 수준만을 말하는 것이 아니다. 팀과 조직에 대한 고민도 해야 한다. 마이크로서비스나 콘웨이의 법칙이라는 키워드를 떠올려보자.