최근 수정 시각 : 2024-07-07 14:17:05

UML


1. 정의2. 적용 분야3. 한국어로 번역된 서적들4. 파생 표준 및 언어5. 장단점
5.1. 장점5.2. UML을 사용하면 개발이 쉬워지는가5.3. 개발 방법론으로 보아야 하는가5.4. 컴퓨터 분야에서의 효용성에 대해

1. 정의

Unified Modeling Language, UML

수학적인 문법과 구성으로 이뤄진 프로그래밍 언어와는 달리 UML은 모델링 언어이다. 다시말해 설계도를 그리기 위한 언어라는것. 학교다닐때 실과나 기술시간에 간단한 건물 도면 기호에 대해 배운 기억이 있다면, 그런 건축 도면과 유사하게 정해진 기호로 구조를 설명할 수 있도록 하는 언어라고 보면 된다. 4+1 View라는 소프트웨어의 여러 관점들(시나리오, 논리뷰, 개발뷰, 프로세스 뷰, 물리 뷰)를 모델링이 가능한 언어이다.

기원은 Rational 사의 Grady Booch, James Rumbaugh에 의해 1994년 10월에 처음 개발에 착수되었다. 이후 1995년 10월에 Unified Method 0.8의 명칭으로 OOPSLA '95에서 발표되었으며, 이후 Ivar Jacobson이 UML 개발에 함께 협력하면서 1996년에 버전 0.9를 발표하였고, 1997년 11월에는 UML 1.1 이 OMG[1]에 의해 표준으로 채택되었다.

2005년에 UML 2.0이 발표되었으며 현재 2011년에 발표된 UML 2.4.1 이 최신 표준이다. 2012년 10월에 진행중인 상태의 UML 2.5가 발표되었다.

2020년대 부근에서 보면 사실상 산업에서 거의 사멸된 모델링 언어다. 즉, 산업에서 사내 조직들이 UML을 적극적으로 사용되는 곳은 매우 적어졌다는 의미다. 이에 대해서는 많은 원인이 있지만 UML과 프로그래밍이라는 관계와 간격을 잘 메우지 못했다는 것이 공통된 지적이다. 90년대 전후의 정적인 소프트웨어에서는 폭포수 모델이 어느정도 탄력을 받으며 UML이 동반돼 사용됐지만 IT 산업과 생태계가 웹 생태계로 이동한 2010년대 즈음에는 비즈니스의 빠른 변화에 대응하기 위해 애자일 방법론이 대두되며 이와 상충되는 폭포수 모델과 함께 사용이 급감하기 시작했다. 그래도 UML이 남긴 클래스 다이어그램이라든지 시퀀스 다이아그램이라는 유산은 지금도 도식과 학습을 위해 어느정도 사용되긴 한다.

아래는 모두 영문판이다.
현재 체계가 어느정도 잡힌 UML 2.5
인터넷에 배포되고 있는 영문 UML 입문 자료들중 일반적으로 쓰이는 James Rumbaugh의 UML 2.0 핸드북 2판
인터넷에 배포되고 있는 영문 UML 입문 자료들중 일반적으로 쓰이는 UML superstructure
인터넷에 배포되고 있는 영문 UML 입문 자료들중 일반적으로 쓰이는 UML Infrastructure
로버트 마틴의 자바 프로그래밍용 UML 실전 입문서

2. 적용 분야

- 컴퓨터 비즈니스 설계
- 자동차 개발[2]
- 항공기 개발[3]
- 원자력 발전소[4][5]

3. 한국어로 번역된 서적들

한국에 UML 관련 서적은 수십 종이 나왔으나, UML의 의미를 정확히 알고 설명하는 책은 없다. 번역의 질은 더더욱 기대하면 곤란하다. 온전한 의미를 설명하는 책은 위 정의 파트에 링크 걸린 PDF를 보길 바란다. 실용서로 공부하는 것은 별로 추천하지 않는다. 다른 모델링 언어 익히듯이 가볍게 수박 겉 핥기로 배워서 간단한 다이어그램을 그리는 것이라면 모를까, 대규모 프로젝트에 UML을 쓸 때도 이런 식으로 접근하면 반드시 문제가 생긴다. 대규모 팀을 이루는 원전 건설사, 항공기 개발사에서는 UML(혹은 UML같은 모델링 언어)에 통달한 언어학자/기호학자/수학자를 채용한다.

4. 파생 표준 및 언어

- OMG SysML (System Modeling Language)
- OMG UML Testing Profile외 약 20여가지 모델링 언어
- AUTOSAR (AUTomotive Open Software ARchitecture)
- EAST-ADL (Architecture Modeling Language) 시리즈
- MATLAB / Simulink
- 각종 Visual based Languages

5. 장단점

5.1. 장점

장점은 동일한 통합적인 모델링언어로 소프트웨어 개발의 비지니스가 가능해진다. 소프트웨어를 만들기를 요구하는 이해관계자(Stakeholder)가 필요한 언어부터 개발자들 사이에서 필요한 언어가 모두 존재하는 것이 UML이다. 소프트웨어는 이해관계자들이 원하는 기능 요구사항은 물론이고 그 밖에 소프트웨어 품질 요구사항도 달성해야한다. 예를 들면, 이해관계자가 어떠한 데이터를 저장하고 불러올 수 있는 Dropbox같은 소프트웨어를 만들기를 원할 때 데이터를 저장하고 불러올 수 있는 기능 자체는 당연히 달성해야 하고 이외의 품질 요구사항이 될 수 있는 속도, 가용성(Aavailability)[6], 신뢰성[7] 등을 소프트웨어 아키텍트가 이해관계자들고 같이 추출하고 이러한 설계가 반영할 수 있도록 소프트웨어 아키텍처를 설계해야 한다. 이러한 품질 요구사항이 반영되는 관점을 볼 수 있는 View가 4+1뷰이고 그것을 모델링할 수 있는 언어가 UML인 것이다. UML에는 상당히 많은 다이어그램이 존재하는데 그것들은 필요에 따라 선택적으로 그려질 수 있다. 모두다 사용하지 않아도 되며 그 다이어그램 관점으로 모델링이 필요한 경우에만 그린다. 프로세스 뷰도 소프트웨어가 하나의 프로세스만 사용한다면 굳이 그릴 필요가 없다. UML로 소프트웨어 아키텍처를 그릴 수 있고 아키텍처 대로 개발이되면 기능 요구사항, 품질 요구사항도 만족이되는 소프트웨어를 만들 수 있다.

그리고 또다른 장점으로는 MDD(Model Driven Development, 모델주도적개발)이 가능해진다. MDD라는 것은 모델을 기반으로 소프트웨어 개발을 하는 것이다. 사실상 다이어그램만 그리면 소프트웨어가 나온다는 것이다. 실존 개발 도구로 IBM Rational의 Rhapsody가 있다.

5.2. UML을 사용하면 개발이 쉬워지는가

누군가는 UML의 장점을 개발 용이성이라고 하는데, 연구하는 사람이 봐도 용이함과는 거리가 멀다. UML 2.5에 대한 영문 설명이다. 대충 흝어만 보아도 새로운 언어 하나를 배우는 수준의 수고가 필요하다.

UML을 배울 때 중요한 것은 UML은 언어라는 점이다. UML이란 언어체계는 의사소통을 위한 도구이지, 당신의 설계능력을 직접적으로 키워주지 않는다. 개발능력은 따로 키워야 함을 명심하라. 다만 우리가 말빨을 기를 때 글로 표현해보면 더 빨리 늘고, 음악을 배울 때 악보로 그려보면 더 수월하듯이, UML 역시 설계 능력을 키우는데 도움을 간접적으로 준다.

5.3. 개발 방법론으로 보아야 하는가

사실 UML은 단순한 모델링 언어라서, 이것을 소프트웨어 개발 방법론으로 보기는 힘들다. UML의 개발 과정에서 객체지향이나 컴포넌트 기반 개발 방법론의 토대를 세우려는 시도가 이어졌으나, 그냥 모델링 언어 체계만 만들어지고 있다.

5.4. 컴퓨터 분야에서의 효용성에 대해

UML을 두루 사용하는 쪽은 주로 SI 업체에 근무하던 사람들이다. 정확히는 비지니스 프로세스 개발 분야에 특화되어 사용, 발전되었으며, 개발 요구 사항은 이들에 맞춰져 구성되었다. 이론적으로는 모든 것을 표현 가능하나, 기본적으로 배우기 어렵다는 문제 때문에 아직 널리 퍼지지 못하고 있다.

일단 UML을 도입하면 이런 효과를 기대해 볼수 있다.
  • 개발 기획과 산출물에 대한 확실한 증거. UML이 소프트웨어의 설계도를 그리기 위한 물건이다보니 UML을 그렸으면 그린대로 만들고 그린대로 동작하면 일단 그 설계는 성공한 것으로 본다. 하지만 실제 설계된 대로 돌아가고 설계된 대로 돌아가게끔 하는 것은 쉽지가 않기에 이런 부분은 전문적인 아키텍트가 붙어서 해결한다. SI업체의 경우 업체별로 각자 업무흐름이 있으니 다 똑같지는 않지만, 한번 UML을 그리면 관련된 모든 사람들에게 설계문서를 돌려 도장을 찍고 그대로 만들겠다는 계약서를 쓴다 카더라. 그래도 나중에 변경사항 나오는건 어쩔수가 없다.
  • 프로그램 개발이라는 행위에 대해 전문가와 비전문가가 서로 대화할수 있는 도구. 일반적인 프로그램 언어와는 달리 도형으로 표현이 가능하기 때문에 프로그램에 대한 지식이 없는 사람도 프로그램이 제공해야할 기능과 구조를 표현하는게 가능하다. 물론, 비전문가가 설계하는 컨셉을 그대로 프로그램 언어로 옮길수는 없기에 일반적으로 개발을 요청한 쪽과는 UseCase 정도만 사용해서 일을 하고 그 UseCase마다 구현을 위한 내용을 설계한다.

하지만 UML을 도입하면 이런 피곤한 일들이 생긴다.
  • 제대로 배운 사람이 없다: 기본적으로 모델링 분야는 기호학과 언어학을 바탕으로 만들어진, 인공 기호/논리/언어체계이다. 인터넷을 개발한 사람이 물리학자이고, MIT MediaLab 설립자가 건축학자이듯이 컴퓨터는 제대로 전공을 배운 사람이 없다. 그리고 그리는 표준에 관련된 방법론을 책이 아닌, 제대로 익힌 사람은 더더욱 드물다.
  • 다양한 학문의 접점이라, 그리기는 쉬워도 적용하기는 어렵다: 모델은 기호학, 모델 변환 도구는 수학과 논리학, 언어학 등이 결합된 부분이어서, 전문 개발 회사 이외에는 손대기 매우 어렵다. 그리고 컴파일러 만들어서 큰 돈 벌은 회사는 없다. MS나 Oracle은 Lock-in 전략을 위해서 사용하지, 직접적인 매출을 위해서 개발하지 않는다. MS 홈페이지 들어가면 Visual Studio Community 버전 공짜로 받을 수 있다.
  • 설계한 내용대로 구현이 불가능할 경우 실무자 입장에선 구현이 최선이기 때문에 설계를 무시하고 프로그램을 만들게 된다. 그런데 이렇게 초기 설계에 없던 구현을 하게되면 이 부분은 설계문서에 재반영시켜야 하는데 개발일정에 쫓기다보면 그렇게 하기가 힘들다. 다행히도 요즘은 개발툴들[8][9]이 많이 발전되어 소스코드와 UML을 상호 연관시켜 자동으로 갱신될수 있도록 해준다.[10]
  • UML 전문가가 따로 담당해야 할 정도의 서류의 산이 만들어진다. UML 설계문서는 정말 작정하고 그리기 시작하면 시스템 규모에 따라 틀리지만 그 양이 엄청나다. 그래서 이런 부분을 전문적으로 관리해주는 사람이 있다면 모를까 그렇지 않으면 개발자가 서류에 깔려죽는다. 그래서 필요한 부분만 서류화시키려고 하는데, 개발팀의 규모가 커질수록 그렇게 하기 어렵다.

그러한 이유로 항공기나 원자로 제작 등 거대한 회사 규모를 갖추어야 하는 경우에만 UML 담당 매니저와 인사교육 담당자를 따로 둔다. 소규모 개발회사의 경우 단위기능별로 밑그림이 필요할 때 시퀀스나 유즈케이스, 클래스 정도만 조금 사용한다.

대표적인 UML 파생 제품은 National Instrument사의 LabView를 이용해서 개발된 미군 무인전투기 프레더터가 있다. UML과 모델 기반 개발 방법의 채용을 통해 개발 비용 및 검증 비용을 절감하였다.[11] UML을 피상적으로 이해하고 사용하였던 F-35[12]는 개발자 부족으로 인해 개발언어를 Ada[13]에서 C++로 교체하다가... 세계 최고가의 비행기가 되어버렸다.

UML은 실제로 프로그램을 제작하는데 직접 사용되는 것이 아닌, 프로파일을 이용한 모델 기반 개발(Model-based development)에 사용된다. UML은 모델 기반 개발 및 요구조건-개발-검증 단계를 명시한 V 프로세스의 핵심 부분이며, 전자 장비의 기능성과 안정성을 규정해 높은 IEC 61508, IEC 61508에서 파생된 자동차 세부 표준인 ISO 26262 및 기타 7가지 세부 개발 방법론, 자동차 개발 및 소프트웨어 구현 표준인 AUTOSAR 표준에서는 기본으로 사용한다.[14]

LG CNS에서 MDD(Model Driven Development) 100%로 400건 이상의 개발을 완료했다고 자랑한다. #
[1] CORBA 아키텍처를 만든 그곳 [2] 개발 프로세스 표준도 2011년에야 만들었다... 모델 기반 개발로의 전환은 2015년 이후에나 가능 [3] MATLAB/Simulink, LabView 등 사용 [4] 1차로 상태 모델 개발하고, 2차로 UML 등의 모델을 이용한 설계하고, 3차로 구현하고, 4차로 코드별로 까서 검증한다. [5] 후쿠시마 발전소 폭발 사고에서도 프로그램은 정해진 설계대로의 성능을 발휘했다. 수소 기체를 안정화하기 위한 기기의 외부 전원을 연결하기 위한 콘센트 길이가 짧을 줄 누가 알았나. 물론 전선을 만들기만 하고 30년 동안 꼽는 시늉도 안했던 일본 정부 및 도쿄전력의 잘못이다. [6] 서버가 시도 때도 없이 죽으면 가용성이 떨어지는 것이다. [7] 소프트웨어에서 저장했다가 불러오는 파일이 달라진다면 신뢰성이 떨어지는 것이다. [8] 다만 무진장 비싸다. 분야에 따라서는 정가가 아닌 제품에서 % 단위로 떼어간다. [9] 공개를 해버린 MS Robotics Development Studio는 순식간에 로봇 관련 중소기업들의 de facto 표준이 되었다. [10] 이론적으로는 모델 기반 개발은 최적화 작업을 죄악시한다. 후임 개발자가 손 댈 수 없으니까... [11] 이론적으로는 개발 언어가 변경되더라도 언어 변환 어댑터만 교체하면 된다. [12] 모델 기반 개발 분야의 재앙이라고 불리다가, 이제는 미국 국가재정의 재앙이라고 불린다. http://nationalinterest.org/blog/the-buzz/the-f-35-14-trillion-dollar-national-disaster-19985 [13] 미 국방부 무기 표준 개발 언어 [14] 이들 모델은 UML을 직접적으로 사용하지 않고, 나름대로 변형된 모델을 사용하지만, UML 모르고서는 읽을 수도 없다. 물론 OMG에서 이들 표준 및 단체에 사용료 받는다.

분류