추가 적립 안내

엔지니어링 원칙을 적용한 현대 소프트웨어 개발의 시작
끊임없는 변화에 견고한 아키텍처와 검증된 프로젝트 설계 방법론

현재 수많은 소프트웨어 프로젝트가 놀라운 속도로 실패하고 있습니다. 끊임없이 변하는 요구사항으로 인해 시스템은 감당할 수 없을 정도로 복잡해지고 있습니다. 역동적이고 혼란스러운 환경에서 프로젝트의 마감일, 일정, 예산은 지켜지지 않습니다.

이 책은 검증된 아키텍처 및 프로젝트 설계 방법론을 도입하여 이러한 문제를 극복하는 데 도움을 줍니다. 먼저, 밀접하게 연결된 두 가지 구성 요소인 아키텍처 설계와 프로젝트 설계를 통합합니다. 이 두 요소가 합쳐져 소프트웨어 설계를 구성합니다.

아키텍처 설계에서는 더 작은 구성 요소나 서비스로 분해하는 방법을 제시하여, 현재 많은 소프트웨어 아키텍트가 실패하는 영역을 해결합니다. 다음으로, 아키텍처 설계에서 효과적인 프로젝트 설계를 도출하는 방법을 보여주며, 프로젝트의 기간, 비용, 위험을 정확하게 계산합니다.

이를 통해 얻은 방법과 원칙은 프로젝트나 회사 규모, 기술, 플랫폼 또는 도메인과 관계없이 적용할 수 있으며 개발자, 아키텍처, 팀장, 프로젝트 리더에게 고품질의 소프트웨어를 개발하는 가장 현대적이고 체계적인 접근 방식을 제시합니다.

여전히 많은 소프트웨어 프로젝트가 놀라운 비율로 실패하고 있으며, 출시된 프로젝트 중에서도 결함이 많은 경우가 많고 심지어, '신뢰할 수 있는' 소프트웨어 시스템조차 기대에 미치지 못하는 경우가 흔합니다. 일반 프로그래머들은 단순한 기술자로 활동하며, 소프트웨어 아키텍트들은 성공을 위한 충분한 교육을 받지 못하고 있습니다. 그들에게 제공되는 정보는 체계적이지 않거나 일관성이 없거나 잘못된 경우가 많습니다. 유발 로이는 '올바른 소프트웨어 설계'에서 시스템 및 프로젝트 설계를 위한 구조화되고 고도로 공학적인 접근 방식을 소개하여 이러한 문제를 해결하는 데 도움을 줍니다.

로이의 소프트웨어 설계 방법론은 두 가지 밀접하게 연결된 구성 요소를 통합합니다. 시스템 설계(일반적으로 아키텍처라고 함)와 프로젝트 설계입니다. 이 두 가지를 합쳐서 소프트웨어 설계라고 합니다. 시스템 설계를 위해 그는 시스템을 더 작은 구성 요소 즉, 서비스로 분해하는 공학적 방법을 제시하여 현재 대부분의 소프트웨어 아키텍트가 실패하는 영역을 해결합니다. 다음으로, 시스템 설계에서 효과적인 프로젝트 설계를 도출하는 방법을 보여주며 프로젝트의 기간, 비용 및 위험을 정확하게 계산합니다.

'올바른 소프트웨어 설계'에 담긴 기술과 아이디어는 소프트웨어 기술, 플랫폼, 프로젝트 규모, 회사 규모 또는 도메인에 관계없이 적용 가능하며, 오늘날 소프트웨어 실패의 주요 원인을 해결하는 데 특별히 설계되었습니다.

알렉스 카르포비치(Alex Karp owich)(소프트웨어 아키텍트)
비교적 경력 초기에 접어든 당시 20대 후반인 저는 이 과정을 통해 제 삶과 커리어 경로를 바라보는 시각이 달라졌다고 자신 있게 말할 수 있습니다. 제 인생에서 가장 중요한 계기가 될 것이라 확신합니다.

코리 토거슨(Kory Torgersen)(소프트웨어 아키텍트)
유발 로이에게 배운 뒤로 제 삶이 달라졌습니다. 다른 분야에 적용되던 엔지니어링 원칙을 소프트웨어 설계뿐만 아니라 제 경력에도 적용하면서 단순한 개발자에서 진정한 소프트웨어 아키텍트로 거듭났습니다.

리 메식(Lee Messick)(리드 아키텍트)
놀라운 경험이었습니다. 소프트웨어 개발을 대하는 내 자세가 완전히 바뀌었습니다. 그동안 내가 생각했던 설계와 코딩에 대한 원칙이 옳다고 생각했지만 제대로 표현할 수 없었는데, 이제 제대로 말할 수 있습니다. 소프트웨어 설계뿐 아니라 다른 종류의 설계에 대한 생각에도 큰 영향을 받았습니다.

로센 토테브(Rossen Totev)(소프트웨어 아키텍트/프로젝트 리드)
아키텍트 마스터 클래스와 프로젝트 디자인 마스터 클래스에 참석하기 전까지, 우리 팀은 아무리 노력해도 성공적인 결과로 이어지지 않는 이유를 모른 상태로 이어지는 죽음의 행군을 멈출 방법을 고민하고 있었습니다. 마스터 클래스를 통해 소프트웨어 개발 역시 다른 엔지니어링 분야와 비슷한 관점으로 접근하면서 보다 전문가답고 예측 가능하며 신뢰할 수 있는 방식으로 주어진 일정과 예산에 맞게 고품질 소프트웨어를 개발할 수 있게 됐습니다. 마스터 클래스를 통해 매우 값진 지식을 얻었습니다. 끝없이 변하는 사용자 요구사항으로부터 견고하고 바람직한 아키텍처를 만드는 방법 뿐만 아니라, 프로젝트를 계획하고 성공적으로 마무리하는 방법까지, 모든 내용을 저자의 프로다운 실력을 바탕으로 설명하고 있습니다. 저자로부터 배운 모든 내용이 실전에서 검증된 만큼, 소프트웨어 아키텍트를 지향하는 사람이라면 누구나 막강한 지식을 갖출 수 있을 것입니다.

매트 로볼드(Matt Robold)(소프트웨어 개발 매니저, 웨스틴 고비나 서비스 그룹)
프로젝트 설계 마스터 클래스 덕분에 제 경력을 획기적으로 바꿀 수 있었습니다. 마감일과 예산이 제대로 지켜지지 않는 환경에서 제게 유발(Juval)의 강의는 신의 축복과 같았습니다. 그를 통해 프로젝트를 제대로 설계하기 위한 부품과 도구를 배웠고, 그 결과 현대 소프트웨어 개발의 역동적이면서 혼란스럽기도 한 비용과 일정을 통제할 수 있게 됐습니다. 유발은 납기 초과와 비용 초과라는 적과 싸우는 전쟁에서 우위에 설 수 있다면서, 마치 칼싸움에 총을 든 기분을 받게 될 거라고 했습니다. 엔지니어링 기초와 제조 원칙을 그대로 소프트웨어에 적용하는 것에 불과한 것 같지만, 실제로는 엄청난 능력을 갖추게 될 것입니다.

서문
감사의 말

1장 더 메서드
‘더 메서드’란 무엇인가
- 설계 검증
- 빠듯한 일정
- 분석 마비 피하기
- 커뮤니케이션
더 메서드가 제공하지 않는 것

〈1부 시스템 설계〉
2장 분해
기능 분해 금지
- 기능 분해의 문제점
- 기능 분해 돌아보기
- 도메인 분해 피하기
- 잘못된 의도
- 테스트 가능성과 설계
- 예제: 주식 거래 시스템
변동성 기반 분해
- 분해, 유지보수, 개발
- 보편 원칙
- 변동성 기반 분해와 테스팅
- 변동성 문제
변동성 파악하기
- 변동성과 가변성
- 변동성의 축
- 요구사항을 가장한 솔루션
- 변동성 목록
- 예: 변동성 기반 거래 시스템
- 세이렌의 노래에 홀리지 않기
- 변동성과 비즈니스
- 경쟁사를 위한 설계
- 변동성과 지속성
- 연습의 중요성

3장 구조
유스케이스와 요구사항
- 필수 동작
계층형 접근법
- 서비스 활용
대표적인 계층
- 클라이언트 계층
- 비즈니스 로직 계층
- 리소스 접근 계층
- 리소스 계층
- 유틸리티 바
분류 가이드라인
- 명명 규칙
- 네 가지 질문
- 매니저 대 엔진 비율
- 주요 특징
서브시스템과 서비스
- 점진적 구축
- 마이크로서비스
개방형 아키텍처와 폐쇄형 아키텍처
- 개방형 아키텍처
- 폐쇄형 아키텍처
- 반폐쇄형(semi-closed) / 반개방형(semi-open) 아키텍처
- 규칙 완화
- 설계할 때 “해선 안 되는 것”
- 대칭 추구

4장 조합
요구사항 변경
- 변경에 대한 분노
- 핵심 설계 원칙
조합형 설계
- 코어 유스케이스
- 아키텍트의 미션
기능은 따로 없다
변경 사항에 대처하기
- 변경 사항 가두기

5장 시스템 설계 사례
시스템 개요
- 레거시 시스템
- 새로운 시스템
- 회사
- 유스케이스
반설계 노력
- 모놀리스
- 과립형 구성 요소
- 도메인 분해
비즈니스와 일치
- 비전
- 비즈니스 목표
- 사명
아키텍처
- TradeMe 용어집
- TradeMe의 변동성 영역
- 정적 아키텍처
- 운영 방식
- 워크플로 매니저
설계 검증
- 유스케이스: 기술자/계약자 추가
- 기술자 요청 유스케이스
- 기술자 매칭 유스케이스
- 기술자 할당 유스케이스
- 기술자 종료 유스케이스
- 기술자 결제 유스케이스
- 프로젝트 생성 유스케이스
- 프로젝트 종료 유스케이스
다음 단계는?

〈2부 프로젝트 설계〉
6장 동기부여
프로젝트 설계가 필요한 이유
- 프로젝트 설계와 프로젝트 상태
- 조립 설명서
- 욕구 단계

7장 프로젝트 설계 개요
성공의 기준
- 성공 보고하기
프로젝트 초기 인력 구성
- 아키텍트는 한 사람
- 코어 팀
노련한 결정
- 계획은 하나가 아닌 여러 개로
- 소프트웨어 개발 계획 검토
서비스와 개발자
- 설계와 팀 효율
- 작업 연속성
공수 추정
- 전형적인 실수들
- 추정 기법
- 전체 프로젝트 추정
- 활동 추정
크리티컬 패스 분석
- 프로젝트 네트워크
- 크리티컬 패스
- 리소스 할당
활동 스케줄링
- 인력 투입 분포
프로젝트 비용
- 프로젝트 효율
획득 가치 계획
- 대표적인 실수
- 완만한 S 커브
역할과 책임

8장 네트워크와 플로트
네트워크 다이어그램
- 노드 다이어그램
- 애로우 다이어그램
- 애로우 다이어그램 VS 노드 다이어그램
플로트
- 토탈 플로트
- 프리 플로트
- 플로트 계산
- 플로트 시각화
플로트 기반 스케줄링
- 플로트와 리스크

9장 시간과 비용
소프트웨어 프로젝트 진행 속도 높이기
스케줄 압축
- 리소스 보강
- 병렬 작업
- 병렬 작업과 비용
시간-비용 곡선
- 시간-비용 곡선 상의 점
- 이산 모델링
- 흔히 저지르는 실수 피하기
- 프로젝트 타당성
- 정규 솔루션 찾기
프로젝트 비용 요소
- 직접 비용
- 간접 비용
- 비용과 가치
- 총비용, 직접 비용, 간접 비용
- 압축과 비용 원소
- 인력 투입과 비용 요소
- 고정 비용
네트워크 압축
- 압축 흐름

10장 위험
옵션 선택
시간-위험 곡선
- 실제 시간-위험 곡선
위험 모델링
- 위험 정규화
- 위험과 플로트
- 위험과 직접 비용
- 중요도 위험
- 피보나치 위험
- 활동 위험
- 중요도 vs 활동 위험
압축과 위험
- 실행 위험
위험 압축 해제
- 압축 해제 방법
- 압축 해제 타깃
위험 메트릭

11장 실전 프로젝트 설계
미션
- 정적 아키텍처
- 콜 체인
- 활동 목록
- 네트워크 다이어그램
- 계획 가정
정규 솔루션 찾기
- 무제한 리소스 (첫 번째 반복)
- 네트워크와 리소스 문제
- 인프라스트럭처 우선 (두 번째 반복)
- 제한된 리소스
- 서브크리티컬한 상태에 빠지기 (일곱 번째 반복)
- 정규 솔루션 선택하기
네트워크 압축
- 더 나은 리소스로 압축하기
- 병렬 작업 도입하기
- 압축 반복의 끝
- 처리량 분석
효율 분석
시간 - 비용 곡선
- 시간-비용 상관관계 모델
- 죽음의 영역
계획과 위험
- 위험 압축 해제
- 시간-비용 곡선 다시 만들기
- 위험 모델링
- 위험 포함과 배제
SDP 리뷰
- 옵션 제시

12장 고급 테크닉
신의 활동
- 신의 활동 처리하기
위험 교차 지점
- 교차 지점 도출하기
압축 해제 대상 찾기
기하 위험
- 기하 중요도 위험
- 기하 피보나치 위험
- 기하 활동 위험
- 기하 위험 동작
실행 복잡도
- 순환 복잡도
- 프로젝트 타입과 복잡도
- 압축과 복잡도
대규모 프로젝트
- 복잡계와 취약성
- 네트워크의 네트워크
- 네트워크의 네트워크 설계하기
소규모 프로젝트
계층 기반 설계
- 장점과 단점
- 계층과 구성

13장 프로젝트 설계 예제
추정
- 개별 활동 추정
- 전체 프로젝트 추정
의존성과 프로젝트 네트워크
- 동작 의존성
- 동작이 아닌 의존성
- 몇 가지 의존성 뒤집기
- 확인 절차
정규 솔루션
- 네트워크 다이어그램
- 예정된 진행
- 예정 인력 분포
- 비용과 효율
- 결과 요약
압축 솔루션
- 적합한 활동 추가하기
- 리소스 할당
- 예정 진행
- 예정 인력 분포
- 비용과 효율
- 결과 요약
계층형 설계
- 계층형 설계와 위험
- 인력 분포
- 결과 요약
서브크리티컬 솔루션
- 기간, 예정 진행, 위험
- 비용과 효율
- 결과 요약
대안 비교하기
계획과 위험
- 위험 압축 해제
- 비용 다시 계산하기
SDP 리뷰 준비하기

14장 결론
프로젝트 설계 시점
- 진짜 답변
- 앞서 나가기
일반적인 가이드라인
- 아키텍처 vs 추정
- 설계 자세
- 대안
- 압축
- 계획과 위험
프로젝트 설계에 대한 설계
관점
- 서브시스템과 타임라인
핸드오프
- 주니어 핸드오프
- 시니어 핸드오프
- 시니어 개발자를 주니어 아키텍트로
실전
프로젝트 설계 보고
품질에 대하여
- 품질 관리 활동
- 품질 보장 활동
- 품질과 문화

〈부록〉
〈부록A〉 프로젝트 추적
활동 생명 주기와 상태
- 단계 종료 기준
- 단계 가중치
- 활동 상태
프로젝트 상태
- 진행 상태와 획득 가치
- 누적 공수
- 누적 간접 비용
진행 상태와 공수 추적
투영
투영과 교정 조치
- 순조롭게 진행 중
- 과소 예측
- 리소스 누수
- 과대 예측
그 밖의 다른 고려 사항
- 프로젝트의 정수
- 조금씩 범위가 달라지는 것 처리하기
- 신뢰 구축

〈부록B〉 서비스 계약 설계
이것이 바람직한 설계인가?
모듈화와 비용
- 서비스별 비용
- 통합 비용
- 최소 비용 영역
서비스와 계약
- 계약과 측면
- 서비스 설계부터 계약 설계까지
- 좋은 계약의 속성
계약 팩터링
- 설계 예제
- 하향 팩터링
- 수평 팩터링
- 상향 팩터링
계약 설계 지표
- 계약 측정하기
- 크기 지표
- 속성 피하기
- 계약 수 제한하기
- 지표 활용하기
계약 설계의 어려움

〈부록C〉 설계 표준
핵심 준수 사항
준수 사항
시스템 설계 권장 사항
프로젝트 설계 권장 사항
프로젝트 추적 권장 사항
서비스 계약 설계 권장 사항