[ 프로젝트 BEP ] 최종장 - 엔지니어로서의 마인드셋에 대해 : 우수한 엔지니어는 누구이고, 가져야할 마인드 셋에 대해

이미지
  들어가면서 이제 2025년도 얼마 남지 않은듯 하다.  조금 길어질 수도 있기 때문에  실제로 업로드 하는 것은 새해 이후가 될 가능성도 있으나  올해는 이 글로 마무리 해보려고 한다. 이제 이 최종장을 끝으로 이 프로젝트를 다소 마무리 할 수 있을 것 같다. 물론 전체적으로 글 자체가 부족한 부분이 여려 곳 보이지만,  이는 천천히 개선하기로 하고 일단 마무리를 잘 지어보려고 한다. 이 프로젝트의 목표는 어디까지나 주니어 엔지니어(넓은 범위로서)에게  도움이 될 수 있는 부분을 정리해 놓은 것 이며, 이를 전달하는 것에 주력을 했다. 정확히는 그 사이에 몇 번이나 직장은 바뀌었지만,  내가 다니고 있는 회사에서 작게는 멘터,  크게는 주니어 교육에 활용하기 위한 초안이였다. 들어가기 앞서서 먼저 개발자는 무엇인가에서 부터 시작해서,  수학은 필요한가, 그리고 학위에 대한 이야기를 나누어보았고, 그 다음으로 컴퓨터가 무엇인가에 대해서는,  가장 첫 장인 컴퓨터 개론에서 메모리 손실과 함께 설명하였다. 다음으로는 개발 방법론과 시스템 설계,  그리고 프로그래밍 언어에 대한 이야기로 간단하고 이론적인 이야기를 하였다. 눈치가 빠른 사람은 알 수 있듯이,  현실에서 가질 수 있는 몇 가지 의문으로 시작해서  컴퓨터라는 하드웨어 부터 시작해서,  프로젝트(개발 방법론), 설계, 프로그래밍 언어 순으로  일부러 점점 컴퓨터 세계로 들어가도록 구성을 해 놓았다. 여기서 한 걸음 더 나아가자면, 알고리즘이 들어갈 수는 있겠으나  어디까지나 가볍게 전달하는대에 목적이 있기도 하고,  개인적으로는 당장은 크게 중요하지 않은 부분이 라고 생각 했기 때문이다. 먼저 이 부분에 대해서 좀 더 자세히 이야기해보도록 하자. 시작 부터 모든 지식을 쌓을 수는 없다 이는 개발 영역에서만 해당되는 이야기는 아니지만,  모든 것에는...

[ 프로젝트 BEP ] 제 3장 : 시스템 설계 ① - UML(Unified Modeling Language)에 대해

 


이전 글에서 시스템 설계에 대한 
이야기를 충분히 했다고 생각하기에 

이제 본격적으로 시스템 설계에 대해 
그리고 유용한 도구에 대해 이야기해보자. 

UML(Unified Modeling Language)의 정의에 대해


늘 그렇듯이 먼저 정의에 대해 알아보고 
좀 더 자세한 이야기를 해보자.



우리들의 위키피디아에 따르면 

UML은 시스템 설계를 시각화하는 표준 방법을 제공하기 위한
소프트웨어 엔지니어링 분야에서 사용되는 
범용적(a General-purpose)이고, 개발적(Developmental)인 
모델링 언어(Modeling Language)이다.


위와 같이 정의내리고 있다.

따라서 시스템 설계를 위한 
수 많은 모델링 언어 중 하나라고 생각하면 
다소 이해하기 쉬울 것이라 생각한다.

현재 최신 버전은 

공식 페이지에 따르면 2.5.1 버전이 최신으로 보인다.

UML에 대한 사양서는 공식 페이지인
위의 링크에서 참고하길 바란다.

내가 이야기하고자 하는 것은 
UML의 일부분 이기 때문에 
이렇게 살짝만 언급하고 넘어가기로 하겠다.

UML Diagram에 대해


UML에서는 설계 도구인 다이어그램(Diagram)을 표준으로서 제안한다.

UML의 다이어그램을 
구조적인 정보를 나타내는 구조적 UML 다이어그램(Structural UML diagrams)과 
상호 작용 측면을 나타내는 동작 UML 다이어그램(Behavioral UML diagrams)
두 가지 종류로 나눌 수 있는데

내가 이야기하고 싶은 부분은 
구조적 UML 다이어그램 중
클래스 다이어그램(Class Diagram)을 이야기 하려고 한다.

클래스 다이어그램(Class Diagram)에 대해


물론 어떤 사람은 수 많은 다이어그램 중 
어째서 클래스 다이어그램만을 이야기 하는가에 대해
궁금할지도 모르겠다.

그 이유는 현재 대부분의 언어에는 
객체지향형 패러다임이 녹아 들어가 있기 때문이다.

따라서 단순히 프로그래밍 측면에서만 본다면
클래스 다이어그램이 가장 뛰어나다고 나는 생각하고 있다.

현재 많이 이용되어지고 있는 언어들,
그러니깐 C계열, Java, Python등등 

모두 이 Class 형태를 지원하고 
기반으로 코드가 작성되어지기 때문이다.




물론 다음 패러다임일지도 모르는 
Go와 같은 언어를 논외로 치자면 말이다.

따라서 지금의 패러다임만 놓고 본다면
여러 설계 다이어그램 중 하나만 배워야 한다면
나는 클래스 다이어그램을 꼽고 싶다.

하지만, 내가 대부분의 글에서 언급하는 말이기도 하지만
나의 방법이, 나의 생각이 
결코 '진리'가 아님을 또 다시 강조하고 싶다.

나는 한 가지의 방법을 제시하는 것 뿐이며,
이것이 무조건 옳다고 주장할 생각은 없으며
심지어 옳다고 생각하지 않는다.

따라서 글을 받아들임에 있어서
자신에게 도움이 안된다고 생각되는 부분은 
과감히 넘어가는 것이 좋다고 생각되며,
넘어 갈 수 없다면 이에 대해 자신의 직감을 넣어 생각해보길 바란다.

그렇다면 이제 다음 글부터 본격적으로
UML 다이어그램 중 Class Diagram에 대해 이야기를 나눠보자.



이 블로그의 인기 게시물

[ Web ] 웹 애플리케이션 아키텍처 (Web Application Architecture)

[ Web ] 서버 사이드(Sever Side) ? 클라이언트 사이드(Client Side)? 1 [서론, 클라이언트 사이드(Client Side)]

[ Web ] 웹 애플리케이션 서버 아키텍처의 정의 및 유형 ( Define and Types of Web Application Server Architecture )