UML 실전에서는 이것만 쓴다

• 로버트 C.마틴 지음
• 이용원,정지호 옮김

 

 

 유명한 저자 로버트 C.마틴의 책은 정말 실전에서 쓰는 유형들을 압축해서 보여줍니다. 이 책에서 놀라웠던 것은, 세세한 백과사전으로 우리에게 사용법을 안내하는 것이 아니라, UML이란 어떻게 활용해야 하는가, 정말 실전에서 사용할만한 효과적인 방법들은 무엇인가, 더 나아가 객체지향은 무엇인지까지도 설명합니다. 절대 UML의 사소한 사용법으로 에너지를 낭비하지 말 것을 당부하며, 결국 코드로 증명하는 것이 최고임을, 절대로 UML을 몇백장 심지어 몇십장을 그리는 행위를 그만두라고 엄청나게 강조합니다. 

 

 

 

왜 모델을 만들어야 하는가?

---

UML 다이어그램에는 확고한 시험 기준이 없다. 
우리가 UML 다이어그램을 살펴보고 평가하고 여러 원칙과 패턴을 적용할 수는 있지만 
언제나 이 평가는 상당히 주관적일 수 밖에 없다.

시험해 볼 구체적인 것이 있고, 그것을 코드로 시험해 보는 것보다 
UML로 시험해 보는 쪽이 비용이 덜 들 때 UML을 사용한다

UML 다이어그램에는 확고한 정의가 없습니다. 사람에 따라서, 회사에 따라서 조금씩 자신들만의 규칙이 있을 것입니다. 

따라서 정확하게 그려야 한다는 강박관념에서 조금 벗어날 수 있었습니다.

 

반드시 코딩을 시작하기 앞서 포괄적인 설계를 해야 하는가?

---

코드를 파기하는 것보다 UML 다이어그램을 던져 버리는 편이 비용이 훨씬 적은지도 명확하지 않다. 
코드를 작성하기에 앞서 포괄적인 UML 설계를 만들면 드는 비용만큼 효과가 있는지 명확하게 알 수 없다.

UML은 소프트웨어 개발자끼리 설계 개념에 대한 의견을 주고받을 때 굉장히 편리하다. 
만약 다른 사람에게 말해 줄 아이디어가 있다면, UML은 큰 도움이 될 수 있다.

 

 학교에서 프로젝트를 할 때 항상 다이어그램을 먼저 그리고 코딩을 시작했습니다. 하지만 이 책에서는 그럴 필요가 없다고 합니다. 결국 가장 중요한 것은 코딩을 하는 것이고, 과연 이 다이어그램이 실질적으로 코딩에 도움을 주느냐 질문을 던지고 있습니다. 설계를 하면서 필요한 그때 그때 이용하라고 합니다. 하지만 문득, 전체적으로 큰 그림을 한번 그리는 것이 나중에 수정할 때도 영향도를 잘 파악할 수 있지 않나 생각해봅니다.

백엔드 문서

---

설계에 대한 문서를 작성하기에 가장 적당한 때는 언제인가?
문서 작성을 프로젝트 막바지에 팀의 마지막 작업으로 하는 것이 가장 좋다. 

아무도 몇천 장짜리 시퀀스 다이어그램을 원하지 않는다! 
그 대신 우리가 원하는 것은 시스템의 핵심 내용을 짚어서 기술하는 핵심적인 다이어그램 몇 개다.

 

UML을 잘 그리는 것도 중요하지만, 결국 이 다이어그램들을 어떻게 문서화 해야하는지도 같이 고민이 됩니다. 수백장, 수천장을 열심히 그린다고 한들 정말 문서를 위한 문서인지, 다른 사람에게 도움이 되는 유용한 문서가 되는지 잘 고민해야 합니다. 핵심적인 기능들을 그릴 때에만 집중적으로 사용해야 합니다.

 

무엇을 보관하고 무엇을 버려야하는가?

---

UML 다이어그램을 던져 버리는 습관을 길러라.
더 좋은 방법은, 다이어그램을 오랫동안 기록되는 매체에 기록하지 않는 습관을 기르는 것이다.
칠판이나 종이 조각에 다이어그램을 그려라.
칠판을 자주 지워 버릇하고, 종이 조각은 던져 버려라.

 

 다이어그램 자체가 목적이 되지 않도록 주의하라고 합니다. 즉, 다이어그램은 좋은 코딩을 위해서 사용되는 도구이지 그것들이 모든 사람들에게 이해되고 공감이 된다면 과감히 지워버릴 수 있어야 합니다. 

 

반복을 통해 다듬기

---

한순간 번뜩이는 통찰력으로 UML을 그리는가?
클래스 다이어그램을 그린 다음 시퀀스 다이어그램을 그리는가?
구체적인 세부사항에 들어가기 앞서 시스템 구조의 골격을 모두 짜놓아야 하는가?
이 모든 질문에 대해 큰 소리로 "아니다"라고 대답하겠다

 

학교에서도 그렇게 배워서 너무나도 익숙한 프로세스인데, 이 방법을 절대로 사용하지 말라고 한다.!!

 

 

행위를 제일 먼저

---

칠판과 UML과 기록에 대해 내가 한 말을 기억하라. 
우리는 아마 칠판을 앞에 두고 이 과정을 진행하고 있을 것이며, 
뒷날을 위해 지금 하는 일을 기록하지도 않고 있다는 점을 명심하라. 

우리는 형식을 아주 잘 지키려고 하지도 않고 아주 정확하게 다이어그램을 만들려고 하지도 않는다.
 여러분은 이렇게 정확하거나 형식을 잘 지켜서 그리면 안된다. 

목표는 칠판 앞에서있는 모든 사람이 지금 논의하는 내용을 다 이해하는 것이며, 
칠판에서 그만 작업하고 빨리 사람들이 코드를 작성하기 시작하게 하는 것이다.

 

가끔 저는 사소한 하나를 가지고 맞는지 아닌지를 궁금해하는 경향이 있습니다. 이 책도 UML을 잘 그리고 싶어서 읽었는데, 어쩌다보니 완벽하게 그리기 말며, 오래 보관하지 말며, 많이 그리지 말라는 이야기를 중점적으로 보고 있었습니다. 계속 이렇게 강조했던 이유는 그동안 수십년 프로젝트를 하면서 얼마나 많은 리소스가 낭비되었는지를 봤기 때문 일 것입니다. UML을 꼼꼼히 완벽하게 그려야한다는 저의 불안감과 기대감을 한번에 깨버리는 책이어서 좋았습니다.

 

미니멀리즘

---

다이어그램이 가장 유용할 떄는 다른 사람과 의사소통을 할 떄와
여러분이 설계에 관한 문제점을 푸는 일에 도움이 될 때다.

목적을 달성하기에 꼭 필요한 분량만큼만 세부사항을 사용하는 것이 중요하다.
다이어그램은 단순하고 깔끔하게 유지하라.
UML 다이어그램은 소스코드가 아니며, 따라서 모든 메서드나 변수, 관계를 선언하는 장소로 취급해서는 안 된다.

 

다이어그램은 열심히 그려서 이렇게나 멋진 문서를 만들었다고 자랑하는 것이 아니라, 내가 코딩을 잘 하기 위한 하나의 방편으로 이용하는 것입니다.

 

 

 

다이어그램을 그려야 하는 경우

---

1. 여러 사람이 동시에 작업해서 모두 설계에서 특정한 부분의 구조를 이해할 때 그려라. 모든 사람이 다 이해했다고 동의하면 그때 멈춘다

2. 두 명 이상이 특정 요소를 어떻게 설계해야 할지 의견을 달리하고, 팀의 의견을 모을 필요가 있을 때 그려라. 결정이 내려지면 그 때 멈춘다. 그리고 다이어그램을 지운다

3. 어떤 설계 아이디어로 이것저것 시도해 보고 싶을 때 그린다. 아이어그램은 그 아이디어를 생각하는 일에 도움을 줄 것이다. 핵심을 깨닫게 되어서 여러분의 생각을 코드로 옮길 수 있을 정도로 만족스럽게 종결지을 수 있을 때 멈춘다.

4. 누군가에게 또는 여러분 자신에게 코드 일부분의 구조를 설명할 때 그려라

5. 프로젝트 마지막에 가깝고 여러분의 고객이 다른 사람을 위한 문서에 포함하기 위해 다이어그램을 요구할 때 그려라

 

 

다이어그램을 그리지 말아야 할 경우

---

1. 공정에서 다이어그램을 그려야 한다고 정하는 경우는 그리지 않는다.

2. 다이어그램을 안 그리면 죄책감을 느끼거나, 훌륭한 설계자는 누구나 다이어그램을 그린다는 생각이 든다고 그러지 마라. 훌륭한 설계자는 코드를 작성하며 꼭 필요한 때에만 다이어그램을 그린다

3. 코딩을 시작하기에 앞서 설계 단계의 포괄적인 문서를 만들기 위해서 그리지마라.

4. 다른 사람에게 어떻게 코딩을 해야 할지 알려주기 위해서 다이어그램을 그리지 마라.진정한 소프트웨어 아키텍트는 자신의 설계를 코딩할 때 참여한다.

 

그렇다면 자연스레 언제 다이어그램을 그려야 하는지, 그리면 안되는지에 대해 생각해 보게 됩니다. 다이어그램은 나의 만족을 위해서도, 프로젝트의 필수 과정으로서도 아니고 실제 코딩에 직접적인 도움이 되는 용도로 사용을 해야 합니다. 내가 새로운 아이디어가 떠올랐을 때, 여러사람이 설계를 고민하면서 서로 의견을 달리할 때, 특정 코드의 구조를 설명할 때 유용하게 사용합니다.

 

 

 

하지만 문서화는 어떻게 합니까

---

'문서화 하지 않기'로 한 결정이 문서화하기로 한 결정만큼 중요한 떄도 자주 있다.
복잡한 통신 프로토콜, 복잡한 관계형 데이터베이스의 스키마,
재사용 가능한 복잡한 프레임워크는 문서화 해야 한다.

하지만, 이것들이 모두 UML을 몇백 쪽이나 요구하지 않는다. 소프트웨어의 문서는 반드시 짧고 핵심을 찔러야 한다.
이 문서에서 중요한 모듈의 고차원 구조에 대한 UML 다이어그램, 관계형 스키마의 ER 다이어그램, 한쪽이나
두쪽 분량의 시스템을 빌드하는 방법, 테스트 방법 설명, 소스코드 컨트롤 방법 등 범위가 적을수록 좋다.

 

문서화를 할 때 굳이 UML을 몇백 쪽을 그려야 하는지 고민해봐야 합니다. 정말 중요하고 복잡한 프로세스에는 UML이 필요하지만, 그마저도 범위가 좁을수록 좋습니다. 왜냐하면 사람들은 결국 짧은 문서 읽기를 선호하기 때문입니다.

 

따라서, 전부 문서화로 기록을 남길 생각을 하는 것이 아니라, 어떤 것을 문서화해야하는지, 어떤 것을 버려야 하는지도 정해야 합니다.

 

 

마무리

---

UML을 잘 그리고 싶다는 나의 욕구에서 시작된 이 책의 독서의 끝은 처음 예상과 완벽하게 달라졌습니다. UML 사용법도 중요하지만 그것보다는 UML을 언제, 어떤 의도를 가지고 그려야하는지 더 큰 숲을 보게 되었습니다.

 

물론, 각 UML을 어떻게 사용하는지 정말 핵심적인 부분을 담았는데, 그 부분은 이 감상에 담지 않았습니다. 만약 필요한 내용들이 있다면 그 내용들은 따로 정리할 생각입니다.

 

특히, 유스 케이스의 경우에도 화살표를 어떻게 하고, 점선과 실선의 차이는 무엇이고... 이런 규칙들이 오히려 설계를 방해한다고 전혀 신경쓸 필요가 없다고 한 부분들이 신선했습니다.

 

결국 액터가 어떤 기능을 사용하는지 안다면 그것으로 1차 목표 달성입니다. 앞으로 UML을 그리는 순간들이 온다면 좀 더 실전에 사용되는 내용 위주로 공부를 하고, 완벽할 필요 없이 홀가분하게 작성할 수 있을 것 같습니다.