드디어 프로젝트 BEP의 중반 부분인
시스템 설계의 들어설 차례이다.
사실 제 1장과 제 2장
특히 제 1장은 다소 실제 개발자가 하는 일과는
거리가 떨어져 있다고 할 수 있다.
따라서 모른다 하더라도
직접적으로 일을 하는데에 있어서
크게 문제는 없다.
하지만 이 설계 부터 시작하는 제3장 이후 부터는
일을 하는데에 있어서
충분히 인지하고 있지 않으면
실제 프로젝트에서 자신의 유용성을 증명하기 힘들 것 이다.
그렇다면
왜 개발자에게 시스템 설계가 필요할까?
물론 자신이 프로그래머 수준에 머물고 싶다면
딱히 설계를 배울 필요는 없다.
그냥 설계를 해준 대로
그대로 프로그램을 작성하면 되기 때문이다.
하지만, 그 위를 노리고 있는 사람이라면
설계는 반드시 배워야 할 것이며,
실제 프로젝트에서도 필요할 것 이다.
하지만 어떻게 설계를 배워야 하며,
어떻게 작성 해야 할까?
이번 글에서는 시스템 설계에 대해 배우기 앞서
이에 대한 이야기를 충분히 나누어보자.
설계(Design)의 정의
그렇다면 설계란 무엇일까?
사실 한자권 나라에서 설계라는
매우 명확한 그리고 매우 좁은 의미의 단어로서 사용하지만
영어권에서는 넓은 의미로서 Design으로서
애매하고 매우 넓은 의미로서 사용 한다.
Design에 대한 매우 다양한 의미를 볼 수 있는데,
IT 시스템 설계에서 의미하는 것은 그 중 2가지이다.
패턴의 의미로서 Design이라 부른다.
이에 대한 자세한 내용은 아래의 링크를 참고하길 바란다.
https://www.oxfordlearnersdictionaries.com/definition/english/design_1?q=design
다만, 이는 공학적인 의미에서 Design을 말한다.
공학적인 의미에서 이런 Design들의 기저에는
건축에서 사용하는 개념이 깔려있는데,
프로그램을 작성 또는 만든다는 의미에서
건축과 유사하다고 할 수 있지만 매우 다르다.
왜냐하면 일반적으로 건축에서의 Design은
비교적 현실적인 건물이라는
물건을 건설하기 위한 것이지만,
IT에서의 Design은 추상적인 프로그램이라는
물건을 작성하고 만들기 위한 것이기 때문이다.
따라서 애초에 실제 시행되는 프로세스는 유사하지만
프로세스 내부에서 실행되는 작업은 매우 다르다.
예컨데 건물을 짓기 위해서는
토지 크기, 건축 자제, 인원, 예산등이 고려되고
건축 기술을 활용해 건물을 건설하지만,
프로그램을 만들기 위해서는
개발 도구 ,인원, 예산등이 고려되고
개발 기술을 활용해 프로그램을 만든다.
다만,
건물 짓기 위해서 인원 뿐만아니라
부동산과 크기, 건축 자제도 예산에서 큰 부분을 차지하지만
프로그램 프로젝트에서는
인원을 고용하는 부분이 크게 차지 한다는 점이다.
때문에 프로젝트 운용하는데에 있어서 나타나는
리스크들이 매우 다르게 나타난다.
이에 더해
위에서 잠깐 언급했다시피
건축 프로젝트는 현실의 건물을 짓는것을 목표로 하기 때문에
프로세스 내부의 과정들이 매우 구체적인 반면에
프로그램 작성 프로젝트는
컴퓨터 시스템안에서 작동하는
가상의 프로그램을 만드는 것을 목표로 하기 때문에
프로세스 내부의 과정들이 매우 추상적이다.
그렇기에 프로그램 작성 프로젝트에서의
Design은 매우 추상적일 수 밖에 없다는 것이다.
시스템 설계(Design)의 목표
위를 통해 컴퓨터 시스템 설계는 매우 추상적인 것을 알 수 있다.
컴퓨터 시스템을 하드웨어와 소프트웨어,
이 두 가지로 분류 할 수 있는데
여기서 이야기하는 Design은 Software Design이다.
따라서 이 글에서 하드웨어 디자인에 대해
이야기하지는 않을 것 이다.
또한 시스템 설계를 하는 방법론 중
UML(Unified Modeling Language)만을 이야기할 예정인데,
UML은 객체지향형 언어에서 자주 사용되는
설계 방법론이기 때문에 여기서 이것만 알고 넘어간다면
충분하다고 생각 한다.
다른 설계 도구에 대해서는 각자 공부해보길 바란다.
시스템 설계의 목표는 말할 것도 없이
시스템을 구축하기 위한 청사진을 그리는 것이다.
하지만 이 외에도
설계를 했을 때 얻을 수 있는 이점이 몇가지 있다.
첫째, 커뮤니케이션에서의 이점
설계를 했을 때의 가장 큰 이점이다.
설계도라는 공통된 프로토콜을 사용함으로써
커뮤니케이션 함에 있어서 더욱 수월하게 해주어
제한된 시간을 효율적으로 사용할 수 있게 도와 준다.
이는 회의와 같은 커뮤니케이션의 효율이 좋아지고
시간이 줄어들게 됨으로써
좀 더 개발에 시간을 투자할 수 있게 해준다.
둘째, 역할 분류에서의 이점
설계를 하고 이를 문서화 해야하기 때문에
작업이 세분화 됨으로써,
역할 분류가 되고 책임 소재가 확실해지며,
이에 따라 효율성도 올라간다.
셋째, 리스크 관리에서의 이점
프로젝트에서 리스크 관리는 매우 중요하다.
프로젝트를 하다보면
여러가지 이유로 인해
부득히하게 인원이 추가되거나, 교체되는 경우가 많은데
이 경우 설계를 제대로 하고 이를 문서화했을 때,
새로 들어온 인원이 시스템에 대해
이해 하려고 할때 설계도는 큰 도움이 될 수 있다.
따라서 시스템 설계는 기본적으로
시스템 구축을 위한 청사진을 목표로 하되
그 외의 이점들을 좀 더 강화하기 위해
명료하고(Clearly), 간단하게(Simply) 작성해야 한다.
쉽게 말해서 가독성이 좋아야 한다는 것이다.
하지만, 이런 설계와 같은 문서화 작업은
시간을 매우 잡아먹기 때문에 지나칠 경우
프로젝트 진행의 늦추게 할 수 있기 때문에 주의가 필요하다.
이런 문서화를 줄이기 위한 개발 프로세스가
제 2장에서 언급했던 애자일이라는 프로세스이다.
그렇다면 개발자는 왜 시스템 설계를 배워야 하는가?
이제 우리는 본론으로 넘어갈 수 있다.
시스템 설계를 배워야 하는 이유는 명쾌 하다.
개인으로서는 좀 더 나은 개발자가 되기 위해
그리고 프로젝트로서는
위에서 언급한 4가지 이점인
시스템 구축을 위한 청사진,
커뮤니케이션, 역할 분류, 리스크 관리에서의
이점을 가지기 위함이다.
애초에 사람이 교육을 받고자 하는 이유는
좀 더 나은 사람이 되고 싶기 때문이 아닌가?
물론 만약 이 글을 읽고 있는 당신이
현재로서 만족하고 있고,
단순히 코딩하는 것으로 만족한다면
설계를 할 필요는 없을 것이며,
이를 딱히 배울 필요는 없을 것이다.
하지만, 현재에 만족하지 못하고
좀 더 나아가고 싶다면,
시스템 설계는 배워야 할 가치가 분명 있다.
왜냐하면 좀 더 나아가기 위해서는
코드의 세계에서 어느 정도 벗어나야 하기 때문이다.
사회의 해결사가 되고 싶건
높은 급여를 받고 싶건 상관 없이 말이다.
코드의 세계에서만 갖혀 있다면,
세계의 문제를 IT로서 해결해주는
해결사의 역할을 할 수 없다.
물론 그것이 나쁘다는 것은 아니다.
요는 자신이 어떻게 하고 싶느냐이다.
좀 더 나아가고 싶은가?
그렇다면 설계를 배우고, 코드의 세계에서 조금 벗어나길 바란다.
좀 더 나아가고 싶지 않은가?
그렇다면 배우지 않아도 좋다.
하지만 그렇다는 것은
사회에서 자신의 비중이 낮아지며,
이는 자신의 급료도 더 이상 나아지지 않는다는 것을 의미한다.
만약 더 나아가고 싶지도 않으면서,
사회에서 더 많은 몫을 차지하고 싶다면
이는 매우 잘못된 생각이며 부당하다.
그 몫은 당신의 몫이 아닌
좀 더 유용성을 증명한 사람의 몫이다.
그러한 생각은
사회의 유용함을 증명한 사람에게
몫이 돌아가지 못하게 하며
이는 결국 사회의 진보를 막는
매우 비열하고 잘못된 생각이다.
그렇다면 이제 본격적으로 다음 글 부터
시스템 설계 도구인 UML에 대해 이야기를 나누어보자.
참고 :
2020.09.21 초안 작성 및 개행 완료
