스타트업에서의 개발은 초기의 시스템의 설계를 완벽하게 하여 개발을 시작하기 보다는, 당장에 결과물을 보여줘야 하는 경우가 많다. 시간이 지나면서 이러한 시스템을 만든 개발자는 이 시스템에 대해 점점 더 잘 이해하게 된다. 처음에는 시스템에 관한 지식이나 이해가 부족할 수 밖에 없다가 코드가 최상의 설계를 기반으로 하지 않는다는 사실을 인식했을 때 코드를 리팩토링하여 유지 관리할 수 있어야 한다.
여기서 말하는 바는 두 가지이다.
- 설계는 프로세스의 앞부분에서만 진행하는 작업이 아니다.
- 최선의 선택을 하려면 프로젝트 앞부분에 미리 시간을 투자하는 편이 합리적이지만, 프로젝트 시작 후에도 시간을 할애해야 한다.
- 실패 리스크 때문에 아키텍처 리팩토링을 해야할 수 있다.
- 구현을 완료할 때 쯤이면 거의 모든 시스템이 개발자가 최선이라고 생각하는 수준보다 구식이 된다.
현재 애자일 소프트웨어 개발은 당연시되고 있다. 우리가 목표하는 소프트웨어 시스템이 최종적으로 어떤 모습이어야 하는지 시작할 때부터 완벽하게 만들 수도 있지만, 대부분은 초기에 설계를 완벽하게 하여 최종 제품을 개발할 수 없다. 개발을 진행하면서 소프트웨어의 모습은 변하기 마련이다. 애자일 개발의 아키텍처에는 리팩토링을 통한 진화적 설계에 특징이 있다.
하지만 중요한 것은 프로젝트 초기에 '과연 우리가 프로젝트에 관한 정보를 충분히 아는가' 이다.
이 책은 이런 어려움을 완화해주는 대안을 제시한다. 리스크 주도로 아키텍처 설계를 반복하는 방법이다. 다시 말해 자신이 속한 팀에서 수행하는 소프트웨어 개발 프로세스에 맞춰 리스크가 해소될 정도로 충분한 설계량과 시간을 투자하자고 제안한다.
다음은 아키텍처 리스크가 높은 5가지 구체적인 사례다.
- 선택할 수 있는 해결책이 적음 : 채용할 수 있는 해결책의 범위가 작거나 적용 가능한 해결책을 설계하기 어려울 때
- 높은 실패 리스크
- 어려운 품질 속성 : 수백만 명의 사용자가 사용하는 빠른 성능의 시스템을 만들어야 할 때
- 새로운 도메인 : 구현해야 하는 도메인이 새롭거나 경험이 없는 분야일 때
- 제품 라인 : 공통 아키텍처는 어떤 종류의 제품 변경은 쉽지만, 다른 종류의 변형은 어렵게 만든다.
가장 중요한 것은 아키텍처를 잘못 만들면 얼마나 나쁜 영향이 미칠지 살펴보는 것이다. 위처럼 아키텍처를 올바르게 설정하면 전체 시스템 리스크를 크게 줄일 수 있다.
이 책은 크게 두 부분으로 나뉘는데, 1부에서는 소프트웨어 아키텍처와 리스크 주도 접근 방식을 소개한다. 2부에서는 소프트웨어 아키텍처의 개념 모델을 설명한다. 또한 컴포넌트 및 커넥터와 같은 추상화 개념을 자세히 다룬다.
이 책은 상세하고 완전한 아키텍처 셜계를 중요시 하는 사상과 아키텍처 설계를 최소화하고 경시하는 두 가지 사상 사이에서 '적정 아키텍처(just enough architecture)'를 제안한다. 저자는 아키텍처 설계가 얼마나 충분한지 결정하는 핵심 기준이 리스크 감소라고 주장한다. 설계 리스크가 거의 없는 곳에서는 아키텍처 설계가 필요하지 않다. 그러나 어려운 시스템을 설계해야 할 때 아키텍처는 엄청난 잠재력이 있는 도구가 된다.
이 책의 저자는 소프트웨어 엔지니어링 분야에서 박사 학위 까지 보유하신 분으로 이 책은 어려울 수밖에 없다. 이 책은 개발자들이 흔히 겪는 경험들이나 고민들을 기반으로 하기 때문에 실제 소프트웨어 개발 경험이 있고, 내가 짠 코드에 대해서도 나쁜 냄새를 잘 맡을 수 있는 사람들이 읽으면 좋을 것 같다.
숙련된 개발자 및 소프트웨어 아키텍트, 그리고 이 분야를 전공하는 학부 3, 4학년 혹은 석사 과정생을 대상으로 이 책을 추천한다.
"한빛미디어 < 나는 리뷰어다 > 활동을 위해서 책을 제공받아 작성된 서평입니다."
댓글