[서평] 좋은 설계를 위한 도구, UML
『UML 실전에서는 이것만 쓴다』를 읽고
지난번에 디자인 패턴에 관한 책을 통해 객체 간의 관계가 중요하고, 그것을 시각적으로 표현한 것이 UML이라는 것을 알게되었다. 그래서 이번에는 UML에 관련된 책을 읽게 되었다. 『UML 실전에서는 이것만 쓴다』라는 책인데, 로버트 C. 마틴이 저자다. 이 책을 근거로 설계원칙을 설명하는 경우를 몇 번 본적이 있다. 단순히 UML 그리는 법만 설명한 책이 아니라는 뜻이다. 그렇다면 저자가 강조하는 UML은 무엇이고, 언제 사용하는 것이 좋은지 알아보자
UML은 무엇일까
UML은 '소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표현법'이다.(p.1) UML의 종류는 아주 많다. 책에 소개된 것들을 간단히 요약하면 다음과 같다.
클래스 다이어그램: 클래스 간의 관계. 서로의 연관(association)을 보여줌.
객체 다이어그램: 시스템 실행 중 어느 순간의 객체와 관계를 포착함. 메모리 상태의 스냅샷.
시퀀스 다이어그램: 시간에 따른 흐름. 메시지를 보내고 받는 순서를 명확히 함.
협력 다이어그램: 시퀀스 다이어그램과 정보는 동일하지만, 객체 사이의 관계를 더 명확히 함.
상태 다이어그램: 시스템의 상태(state), 상태가 변경할 때 발생하는 일(전이, transition)을 설명함.
이렇게 다양한 종류를 그리는 법을 다 외우고 사용해야하는 것은 아니다. 각 종류를 꼭 필요한 때에, 필요한 만큼만 사용하는 것이 중요하다.
언제 사용할까
건축가는 건물의 모델을 만들어서, 건물이 제대로 서 있을지 확인한다. '모델을 만드는 비용이 실제 물건을 만드는 비용보다 훨씬 적을 경우에 모델을 만들어서 설계를 검사해본다.'(p.11) 결국 비용의 문제다. 소프트웨어에서는 이런 모델을 만들지 말지에 대한 기준이 애매하다. '시험해 볼 구체적인 것이 있고, 그것을 코드로 시험해 보는 것보다 UML로 시험해 보는 쪽이 비용이 덜 들때 UML을 사용한다.'(p.11) 동료와 함께 설계 아이디어를 논의할 때 UML은 좋은 도구가 된다. 함께 칠판에 UML을 그려보고, 사용이 끝나면 지운다. 문서로 보관하는 것보다, 필요할 때 그리는 것이 좋다고 한다. '정말로 유용한 다이어그램은 자꾸만 그리게 된다.'(p.18)
어떻게 사용할까
단순함. 이 책의 핵심 주제라고 생각한다. 긴 문서는 읽히지 않는다. 반드시 짧고 핵심을 찔러야 한다. 소프트웨어 문서의 가치는 그 분량에 반비례 한다.(p.29) 이 부분에서 무조건 자세한 문서가 좋은 것은 아니라는 것을 배웠다. 앞서 읽었던『어떻게 읽을 것인가』책의 '난독' 파트에서 알게된 것과 같은 내용이다. 사람들은 모니터에 있는 글을 F자로 읽어 나간다. 앞부분만 읽고 뒷부분은 아래로 쭉 스크롤하면서 읽지 않는다. 긴 문서를 읽히지 않는 문서가 된다.
저자는 '내일이면 변한다'는 것을 아주 강조한다. 언제든지 요구사항이 변할 수 있다. 이 내용은 5장 유스케이스에서 나온다. 기본적으로 애자일 방법론에 기초해서 설명한다. 초반의 스프린트에서는 대략적인 유스케이스만 있지만, 반복해가면서 구체적으로 만들어 간다. 하지만 유스케이스 자체를 목적으로 삼아서는 안된다. 이 조언은 UML 등 다른 문서화에도 똑같이 적용된다고 생각한다. 아무리 구체적으로 문서를 작성해둬도 내일이면 변할 것들이라서 간단히 작성하고 버리는 것이 좋은 태도다. 필요할 때만 사용해야 한다는 저자의 조언을 기억하자.
왜 사용할까
UML 표기법만 배우고 끝난다면, 고깃집에 가서 고기냄새만 맡고 오는것과 같다고 저자는 비유한다. UML을 통해서 얻기 원하는 것은 좋은 설계이다. 이해하기도 쉽고, 재사용하기도 쉬운 것이 좋은 설계인데, 반면 나쁜 설계는 이해하기 어렵고, 작업할 때 기분이 나쁘다. 누구나 자신의 코드가 작업할 때 기분좋은 코드가 되길 바랄 것이다. 좋은 설계 위한 다섯가지 원칙이 있다. 조금이라도 고통을 느끼기 시작하면 이 원칙들을 적용해보자.
단 하나의 책임 원칙(SRP)
오직 하나의 책임만 져야 한다.
개방-폐쇄 원칙(OCP)
모듈 자체를 변경하지 않고도 그 모듈을 둘러싼 환경을 바꿀 수 있어야 한다. 테스트 코드를 작성하면 모듈의 주변 환경을 바꿀 수 있어야 하기 때문에, 이 원칙을 지키는데 도움이 된다.
리스코프 교체 원칙(LSP)
서브타입은 언제나 자신의 기반 타입으로 교체될 수 있어야 한다. 기반 클래스(base class)의 사용자는 instanceof나 다운캐스트(downcast)를 할 필요 없어야 한다. 파생 클래스가 있다는 사실 조차 알 필요가 없어야 한다.
의존 관계 역전 원칙(DIP)
고차원 모듈은 저차원 모듈에 의존하면 안된다. 추상화된 것은 구체적인 것에 의존하면 안된다. 자주 변경되는 클래스에 의존하지 마라. 추상 클래스와 인터페이스는 구체적인 클래스 보다 덜 변한다. Vector나 String 같은 기본 언어 타입은 자주 변경되지 않는다.
인터페이스 격리 원칙(ISP)
사용자마다 자신이 관심 있는 메서드들만 있는 인터페이스를 제공받는다.
결론
책의 뒷 부분에는 실제 사례를 통해 UML을 사용하면서 설계를 개선할 수 있음을 보여준다. 커피메이커를 만드는 예시를 보면서 물리 단위로 표현하는 것이아니라, 논리 단위로 추상화해야 한다는 것을 배울 수 있다. UML을 기초로 생각하면서, 잘못된 추상화를 발견하는 것은 새로운 경험이었다. 여전히 코드를 보고, UML로 옮겨보라고 하면 정신이 아득해 질테지만, 필요한 만큼 작성하고 동료와의 의사소통을 위해 작성한다는 핵심을 배울 수 있었다. UML에만 해당하는 것이 아니라, 개발 과정에서 나오는 모든 문서에 해당하는 내용이다. 이 책을 읽으면서 설계를 논의할 때 자연스럽게 간단한 UML을 그려보게 되었다. 앞으로도 필요할 때 적절하게 UML을 사용해봐야 겠다.
https://book.naver.com/bookdb/book_detail.nhn?bid=6439362
