소프트웨어 공학의 목적
소프트웨어 공학의 목적은 질 좋은 소프트웨어를 만드는 것이다.
하지만 목적만 있으면 결코 그 목적에 도달할 수 없다.
목적에 도달하는 과정인 ‘어떻게’, 'How'가 중요하다.
코드는 남이 보기 쉬워야한다.
재검토하지 않은 코드가 일으킨 나비효과
우리가 코드를 작성할 때를 생각해보자.
코드가 한 번 제대로 돌아간 이후, 그 코드를 유심히 본 적이 있거나 유지보수를 한 적이 있었을까?
굉장히 부끄럽게도 나는 코드를 재 검토한 횟수가 굉장히 적었다.
코드를 다시 보지 않는다는 것은 복습을 제대로 하지 않는다는 것이다.
그렇다면 지금 하고자 하는 이야기는 복습을 제대로 하라는 것일까? 그건 아니다.
코드를 재검토하지 않는 것은 복습의 문제보다 더 중요한 문제를 일으킨다.
남들이 봤을 때 코드가 읽기 쉬운지에 대한 문제가 발생한다.
내가 작성한 코드는 읽기 너무나도 힘들지만… 난 내꺼 안읽어
일단 돌아가는데에 중점을 둔 코드를 누군가가 봤다고 해보자.
운이 좋게도 이번에는 내가 코드를 정갈하게 작성하여 내 코드를 본 누군가가 굉장히 편하게 읽을 수 도 있다.
하지만 어디까지 이건 ‘운이 좋게도’ 다.
내 운이 어디까지 좋을까? 아마 한 두번 정도는 읽기 쉬운 코드가 나오고 그 이후부터는 나 스스로도 읽기 힘든 코드가 나올 것이다.
그 이유는 무엇일까?
바로 앞에서 말한 이유인, 내가 내 코드를 제대로 읽어본 적이 없기 때문이다.
"나도 읽기 힘들게 쓴 글씨를 과연 남이 제대로 읽을 수 있을까?"
"나 스스로도 읽기 힘든 코드를 과연 남이 제대로 읽을 수 있을까?"
이는 굉장히 중요한 사항이다.
남이 내 코드를 왜 읽어야하는데?
이 글을 작성하는 필자도 그저 대학교 4학년짜리 허접에 불과하다.
나도 잘 모르는 상황에서 누군가를 가르치려고 들고자 하는 것은 아니지만, 이것 하나는 확실히 알 수 있다.
지금까지 내가 작성한, 만든, 프로젝트들의 볼륨은 굉장히 작다는 것을 말이다.
볼륨이 작은 프로젝트를 혼자 하는 것은 전혀 문제가 되지 않지만, 프로젝트 볼륨이 커지게 되면 혼자서 개발하는데는 무리가 있다.
아무리 적게 잡아도 5명 이상이서 개발을 하게 될 때가 오게 된다.
이런 상황에서 나머지 4명이 내 코드를 읽는데 시간이 걸리게 되고, 내가 나머지 4명의 코드를 읽는데 많은 시간이 걸리게 되면 프로젝트는 끝이 날 수가 없게 된다.
사공이 많으면 산으로 간다는 말이 있지만, 그렇게 가기라도 하면 다행이지 이런 경우에는 산으로도 못가고 제자리에서 빙빙 돌게 된다.
그렇기에 협업하는 과정에서 남의 코드를 이해하는 과정이 생기게 되고, 코드를 빠르게 이해하기 위해서는 남이 보기 좋게 코드를 짜는 것이 중요하다.
분석과 설계가 중요하다.
설계 없이는 제대로 만들 수 있는게 없다.
남이 내 코드를 읽었을 때 빠르게 읽혀야하기에 코드를 정갈하게 짜야한다는 것은 이해했다고 치자.
"그렇지만 이걸로 좋은 질의 소프트웨어가 나올 수 있을까?"
우리가 조별과제를 했을 때를 생각해보자.
3명이서 특정 기능을 구현하는게 과제라고 했을 때 우리가 보통 하는 일은 일을 공평하게 나누는 것이다. ▼
그렇게 일을 공평하게 나누고 나중에 모였을 때 합치는 게 쉽지 않다.
각자의 과제에 대한 이해도가 다르기 때문이다. ▼
어찌저찌 합치고 나면 더 이상 유지보수는 물론 새로운 기능 추가도 할 수 없는 프로젝트가 된다.
분명히 공평하게 일 분배를 하고 모두 맡은 일을 충실히 했는데 왜 이런 프로젝트가 된 걸까?
이는 프로젝트 설계가 잘못 되었기 때문이다.
사실 잘못됐다는 말도 잘 쳐준 것이다.
왜냐면 설계 자체를 안했기 때문이다.
설계도 없이 자동차를 만들 수 있을까?
만들 수는 있겠지만 아마 얼마 안가서 고장이 날 것이다.
프로그램도 마찬가지다.
처음부터 설계를 제대로 하고 들어가야 합치기도 쉽고 새로운 기능을 추가하기도, 고치기도 쉬워진다.
설계를 잘 하려면 분석을 잘 해야한다.
여기서 추가로 드는 의문은 ‘설계는 그럼 어떻게 해야 잘 할 수 있냐’는 것이다.
설계를 잘 하기 위해서는 내가 무엇을 만들어야하는 것을 알아야한다.
그리고 내가 무엇을 만들어야하는지를 알려면 분석을 잘 해야한다.
요구사항에 대한 분석을 제대로 해야 무엇을 만들지 확실하게 알게되고 그에 맞게 설계도를 만들 수 있다.
잘 된 설계는?
"그렇다면 어떤 설계가 잘 된 설계일까?"
합치기 좋고, 나중에 유지보수와 기능 추가, 그리고 코드를 재사용할 수 있는 설계가 좋은 설계라고 할 수 있다.
이를 위해서는 모듈화와 추상화를 잘 해야한다.
모듈화를 통해 새로운 기능의 추가/삭제를 용이하게 할 수 있고, 추상화를 통해 실제 세계에 있는 요소들을 컴퓨터로 불러올 수 있다.
소프트웨어 개발 요소
가변적 요소와 본질적 요소
소프트웨어 개발 요소에는 두 가지 요소가 있다.
하나는 가변적인 요소로 프로그래밍 언어, 개발 및 운영 플랫폼, 개발 도구, 소프트웨어 개발 프로세스 등이 있고,
다른 하나는 본질적인 요소로 소프트웨어 추상화 (모델링) 및 설계, 요구사항 분석 및 설계가 있다.
가변적인 요소인 프로그래밍 언어와 개발 도구, 플랫폼 등을 공부하는 것 역시 소프트웨어 개발에 도움을 주지만 장기적으로 봤을 때는 불리한 입장에 처할 수 있다.
iOS앱 개발로 예를 들어보면 이렇다.
초창기 iOS는 지금의 Swift와는 달리 Objective-C로 개발을 했었다.
하지만 이후 애플이 Swift라는 언어를 새로 만들면서 Objective-C로 iOS를 개발하는 일이 없어졌다.
게다가 비교적 최근에는 UIKit을 대신할 SwiftUI라는 새로운 프레임워크가 등장하면서 프레임워크를 전환하고자 하는 움직임을 보여줬다.
iOS만 개발하는 개발자는 Objective-C에서 Swift, UIKit에서 SwiftUI의 큰 두가지 변화를 맞이한 셈이다.
이것이 의미하는 것은 가변적인 요소만을 집중적으로 공부하게 되면 이렇게 큰 변화가 닥치게되면 해당 분야에서의 개발이 어려워질 수 있다는 것이다.
그렇기에 우리는 가변적인 부분에 대해 공부를 진행하기 보다 본질적인 부분에 대해 공부를 할 필요가 있다.
소프트웨어 추상화 및 설계와 요구사항 분석 및 설계는 소프트웨어 개발이 시작한 이후로 바뀌지 않았다.
프로그래밍 언어는 수단이라는 말도 있듯이, 전체적인 틀인 본질적인 설계만 잘 잡혀있다면 어떤 수단을 사용하든 질 좋은 소프트웨어를 개발할 수 있다.
코더와 디벨로퍼
가끔 프로그래머들은 스스로를 코더와 디벨로퍼로 분류하곤 한다.
둘 다 프로그래머나 개발자가 아닌가 싶지만 둘에는 엄연한 차이가 있다고 한다.
건축의 예시와 함께 보면 이렇다.
다리를 만든다고 할 때, 설계를 맡은 사람과 주어진 설계에 따라 벽돌만 쌓는 사람이 있을 것이다.
여기서 설계를 맡은 사람이 디벨로퍼고 설계에 따라 벽돌만 쌓는 사람을 코더라고 할 수 있다.
다른 기술이 아닌 그저 벽돌을 올리는 것은 누구나 할 수 있다.
코드에서도 마찬가지다.
프로그래밍 언어 문법을 배워서 특정 동작을 하는 코드를 짜는 것은 누구나 시간을 들이면 가능하다.
심지어 요즘엔 인공지능이 다 짜준다.
그렇기에 우리는 누구나 다 할 수 있는 것을 하기보다 누구나 다 할 수 없는 것들을 할 줄 알아야한다.
그것이 우리가 우리의 가치를 스스로 높이는 것이기에 우리는 디벨로퍼가 돼야한다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 6. Agile (0) | 2024.01.21 |
|---|---|
| 5. Process Iteration (0) | 2024.01.21 |
| 4. Process Activities (0) | 2024.01.20 |
| 3. 소프트웨어 프로세스 모델 (0) | 2024.01.19 |
| 2. 소프트웨어 공학이란 (0) | 2024.01.19 |
