개발자로서 한 걸음 더 내딛기

한빛미디어 <나는리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

• 원제 : はじめての設計をやり抜くための本 第2版 (처음 설계를 시작하는 사람들을 위한 책 제2판)
• 저자 : 吉原 庄三郎
• 출간 : 翔泳社, 2022 / 한빛미디어, 2024

설계라는 영역의 세부 분야에 대해서 다루는 책은 많다, 아키텍처, UML, RDB 설계, 각종 개발 방법론, 프레임워크 개론 등, 제목만 붙여도 생각나는 책들이 많이 있다. 그러나 이들을 하나로 묶어내어 프로젝트가 진행되는 전체 과정을 다루는 실체는 대부분 다루지 않는다. 정답이 없는 영역이다. 그러나 저자는 프로젝트가 진행되는 큰 흐름을 한 호흡으로 설명한다.

IT 프로젝트는 크게 소프트웨어 설계와 인프라 설계로 나뉜다. 소프트웨어 설계는 다시 어플리케이션 설계와 데이터베이스 설계로 나뉜다. 이 책에서는 이 두가지 범위인 소프트웨어 설계에 대해서 다룬다.

설계는 막연히 뛰어드는 것이 아니라 요구사항 정의서를 토대로 구현의 방법과 명시되지 않은 내용 그리고 이해관계자들을 위한 정보공유가 목적이 되어야 한다고 저자는 말한다. 여기서 구현의 방법에 대한 내용은 다시 내부 설계로 이어지고, 명확하지 않은 내용들은 시스템 기능으로 외부 설계로 이어진다.

개발 프로세스에 대해서 저자는 점진적 개발 이라는 개발론을 소개한다. 점진적 개발이란 워터폴과 같이 완벽함과 확정을 요구받는 방법도 아니고, 애자일 같이 스크럼이나 XP같은 관리를 위한 방법론도 아니다. 각 Task에 따른 산출물을 가지고 다음 Task를 병렬적으로 개발하는 방법론이다. 하나의 Task에는 유스케이스 분석, 설계, 개발이 포함되어있다. 이를 반복하여 최종에 테스트 후 릴리즈하는 방식을 말한다.

외부설계는 시스템의 구체적인 기능을 설계한다. 다른 시스템과의 인터페이스나 화면이 여기에 포함된다. 구체적인 기능을 구현해야 하므로 유스케이스 분석 및 정의 또한 이 과정에서 이뤄진다.

유스케이스에 이어서 개념 모델링을 한다. 개념 모델이란 시스템의 정적인 구조다. 유스케이스에서는 개념간 관계나 종속관계가 표현되지 않는다. 개념 모델링은 이 연관관계를 표현한다. 엔티티 설계와 다르게 메소드나 자료형은 아직 포함하지 않는다. 책에서는 주문, 상품, 결제를 예로 들어 개념모델링을 한다. 이어서 화면 레이아웃이라고 부르는 화면 설계서와 데이터베이스 모델링까지 소개한다. 개인적으로 마음에 들었던 부분은 객체지향과 RDB는 개념이 사상되지 않는데 클래스 설계와 테이블 설계의 다형성과 DB성능에 따른 비교표를 첨부해줘서 좋았다.

이어서 비기능 요구사항 정의에 대해서도 설명한다. 유스케이스나 모델링 같이 요구사항과 연관되지 않은 스팩을 비기능 요구사항 정의라고 한다. 어플리케이션 수준에서는 SLA에 대해서 설명하고, 이를 산출하는 수식과 운영시간을 보장하기 위한 이중화 방안도 소개한다.

내부설계는 외부설계에서 정해진 입력과 출력 사이의 내부처리를 정한다. 예를들어 웹 어플리케이션이라면 컨트롤러, 비즈니스 로직, 엔티티 클래스, ERD 등이 여기에 포함된다.

책에서 또 재미있게 봤던 부분인데 Service 레이어에 메소드 단위로 트랜잭션을 묶는것이 일반적인데 책에서는 이같은 방식을 비즈니스 로직의 처리를 공통화 하는것이 어렵다고 설명하며 다형성을 구현할 수 없다고 설명한다. 그러므로 비즈니스 로직이 파편화되는 문제가 발생한다고 한다. 다만 대부분의 경우에서 설계를 단순화 할 수 있기 때문에 절차식으로 기술하는 트랜잭션 스크립트는 널리 쓰이고 있다. 요즘 많이 보이는 엔티티에 비즈니스 로직을 포함하는 도메인 모델 패턴에 대해서 설명한다. 다만 엔티티에 비즈니스 로직이 포함되므로 패턴을 이용해 클래스를 분리하는것이 좋다고 설명한다.

아키텍처 설계 편에서도 객체지향 설계, 서브시스템, 레이어 아키텍처 등을 포함해 이러한 소프트웨어 아키텍처 설계가 생겨난 이유를 거시적인 관점에서 설명하는 점에서 신선했다.

책의 마지막에 이르면 다시 설계의 본질에 대해 이야기한다. 설계는 비효율적이고 검증이 불가능 한것이라는 주장도 있다. 그러나 공학적 관점에서는 동일한 것을 다시 만들기 위해서 설계가 있어야 하고, 개발자의 관점에서는 정보공유 차원에서 설계는 필요하다고 한다. 현장에서는 요구사항 정의, 명세 변경, 일정한 품질을 위해서 설계는 반드시 필요하다. 개인적으로는 이 파트는 모든 개발자들이 읽어봤으면 한다.

개인적으로 과거에는 유지보수 측면에서 개발업무를 수행 했다면 근래는 기존 기능의 유지보수 보다는 새로운 기능을 추가하는 업무를 자주 하게 됐다. 그러다보니 어플리케이션 수준에서 모델링, 구현 패턴, 리팩토링 스킬은 꾸준히 사용하고 있지만, 머지않은 미래에 매니징을 하게 될텐데 프로젝트, 업무, 이슈를 어떤 기준을 가지고 매니징을 해야할지 모호한 부분이 있었다. 이 책을 제공받아 읽게 되었는데 뜻하지 않게 ‘개발의 관점’이 아닌 ‘프로젝트의 관점’에서 적정 수준의 선택을 할 수 있는 인사이트를 얻을 수 있었다.

한빛미디어 <나는리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.