개발자에서 아키텍트로 #3 -설계-전략-고안하기

3장 설계 전략 고안하기

단단한 설계 전략을 가지면 폭풍 속에서도 정해진 길을 걷는 기분이다.
디자인 싱킹은 단번에 정답을 만들기보다는 학습과 실험을 중요시한다.

3.1 만족스럽게 설계하기

이상적으로 해결해야 하는 문제를 온전히 정의한 후 이를 해결하는 완벽한 아키텍처를 설계할 수 있지만, 현실은 그렇지 않다.
시간, 돈, 기술 지식에서 발생한 이론적인 제약이 소프트웨어 아키텍처처럼 복잡한 문제를 합리적으로 설계하는 걸 어렵게 만든다고 하는데
이는 허버트 사이먼이 말하는 결박된 합리성이다.
그렇기 때문에 이성적인 판단만 하며 최적의 설계를 찾기보다는 만족감을 목표로 삼을 수 있어야 한다.

실험으로 해결하기
가설을 빠르고 저렴하게 평가할수록 이해관계자들이 만족할 만한 구조로 더 빨리 조합할 수 있고, 그만큼 빠르게 이해관계자들의 이익을 실현

위험 요소 줄이기
소프트웨어의 가치는 우리가 끝까지 지켜야 할 단 하나의 변수이다.
아키텍트는 어떤 부분이 잘못되고 있고 있는지 늘 고심하며, 각 상황에 맞는 시나리오를 고려해야한다.

문제단순화하기
참여하는 이해관계자 수를 줄이면 쟁점이 되는 사안도 그만큼 줄일 수 있다.
복잡도를 낮추기 위해 제약을 추가 또는 삭제하거나 문제의 한 부분에만 초점을 맞출 수 있다.

빠르게 반복하고 빠르게 배우기
빠른 실패는 곧 빠른 학습을 의미한다.

문제와 해결책을 동시에 생각하기
문제를 이해하려면 그 주변을 탐험해야 한다
탐험을 잘하려면 문제를 잘 이해해야만 한다.
소프트웨어 아키텍처 설계는 문제를 파악하면서 동시에 해결책도 생각해야한다.
설계 초기부터 코딩하는 방법도 문제와 해결책을 동시에 다루는 전략 중 하나이다.

3.2 설계를 얼마나 우선해야하는가

시스템마다 요구사항과 규모에 맞는 설계 최적점이 있다

3.2.1 설계의 최적점 찾기

베리 베임은 프로젝트 스케줄을 결정하는 가장 큰 요소는 개발 시간, 아키텍처 설계 계획, 재작업이라고 했다.
재작업은 설계 결함을 수정하거나 코드를 재작성하거나 실수를 되돌리는 일 등을 의미한다.

• 시스템의 규모가 클수록 초기 설계에 투자하는 데서 얻는 이득이 커진다.
• 시스템의 규모가 작으면 초기 설계에 투자하는 데서 얻는 이득이 작아진다.
• 아키텍처 설계에 거의 투자하지 않으면 큰 타격을 받을 수 있다.
• 아키텍처에 투자할수록 재작업이 줄어든다.