소프트웨어란?
소프트웨어라는 말을 들으면 처음 드는 생각은 작성한 코드, 컴파일한 바이너리 코드, exe 파일, app 등등을 먼저 생각하곤 한다.
그것들도 소프트웨어이긴 하나 그것만이 소프트웨어인 것은 아니다.
조금 더 넓은 의미로 아래의 것들도 소프트웨어로 볼 수 있다.
Computer Programs
우리가 보통 생각하는 프로그램들이다.
작성한 코드, 컴파일한 바이너리 코드, exe 파일, app 등등이 있다.
Configuration Files
Configuration file은 코드에는 포함되지 않지만 프로그램을 구동할 때 필요로 하는 파일을 말한다.
OS의 경우에는 OS가 구동될 때 사용하기 위해 따로 파일로 설정해놓은 값들이 Configuration File이라고 할 수 있다.
System Documentation
System Documentation은 개발자들이 개발하는 과정에서 만들어지는 모든 문서들을 말한다.
요구사항을 정의한 스택문서, 디자인하며 만들어진 다이어그램들, 테스팅할 때 필요한 테스트 플래닝 문서들, 테스트 결과, 버그 리포팅 등등 이런 모든 문서들을 말한다.
User Documentation
User Documentaion은 매뉴얼, 사용설명서를 말한다.
특정 제품에 대한 매뉴얼을 작성하려면 해당 제품에 대해 자세히 알고 있어야한다.
보통 제품에 대해 가장 잘 아는 사람은 그 제품을 만든 개발자다.
같은 이치로, 프로그램을 가장 잘 아는 사람은 그 프로그램을 만든 개발자가 된다.
매뉴얼에 대해서는 ‘이것도 개발자가 만들어야돼?’ 라고 생각을 하곤 한다.
필자도 그렇게 생각을 했는데, 다시 생각해보니 개발자가 만드는게 당연한 이치다.
매뉴얼은 해당 제품을 가장 잘 아는 사람이 만들어야 가장 잘 소개할 수 있고, 해당 제품을 가장 잘 아는 사람은 개발자니까 당연히 개발자가 만드는게 맞다.
연쇄적으로 생각해보면 개발자의 일이 맞는 것이다.
개발자라면 코드만 짜면 될 거라고 생각하지만, 이런 인식과는 다르게 위의 문서들도 다 만들어야 한다.
인식의 전환이 필요하다.
소프트웨어 제품은…
소프트웨어는 고객의 요구에 따라 그 형태가 달라진다.
크게 두 가지로 분류를 해볼 수 있는데 하나가 Generic, 다른 하나는 Customized다.
갑자기 영어로 용어를 써서 뭔가 싶을 수 있지만 사실 간단한 용어다.
개별화 되어있냐, 안되어있냐는 것이다.
Generic
Generic한 소프트웨어는 개별화되어있지 않은 소프트웨어들을 말한다.
이런 소프트웨어들은 누구나 구매할 수 있다.
예를 들면 마이크로소프트의 프로그램들이 있다.
엑셀, 파워포인트, 워드 등등 누구나 필요하면 정당한 대가를 지불하고 사용할 수 있다.
하지만 Generic한 소프트웨어들은 고객의 요구사항이 바로바로 만족되지 않는다.
지금 당장 마이크로소프트에 전화해서 ‘제가 여러분의 소프트웨어를 구매했는데 제가 원하는 어떤 기능이 있으면 좋겠습니다.’ 라고 말 해봤자 다음 업데이트에 그런 기능은 들어있지 않다. ▼
Customized
Customized된 소프트웨어는 뜻 그대로 개별화된 소프트웨어를 말한다.
이런 소프트웨어들은 특정 고객만 구매할 수 있고, 특정 고객의 요구사항만 만족시킨다. ▼
Generic & Customized
위에서 둘은 이분법적인 요소인거 처럼 이야기 했지만 사실 둘은 이분법적인게 아니다.
Generic하면서도 Customized된 소프트웨어들도 존재한다.
예를 들면 ERP 소프트웨어들이 이에 해당한다.
ERP는 Enterprise Resources Planning의 앞 글자를 따온 것으로 회사의 자원 관리 시스템, 전사 시스템을 말한다.
어느 정도 규모가 있는 회사라면 이 소프트웨어를 기본적으로 필요로 하기에 Generic 하다고 할 수 있다.
하지만 각 회사마다 원하는 기능이 다르기에 Customized되어야 한다.
게임 개발 회사에서 물류 회사에서 필요한 기능을 전부 필요로 하지 않는다는 것을 생각하면 이해하기 쉽다.
최근에 나온 서비스인 헤이영을 생각해봐도 이해가 쉽다.
대학교에서 필요한 소프트웨어인데, 각 대학에서 요구하는 기능이 다르기에 내부에 있는 기능은 대학마다 다르다.
소프트웨어의 스펙은 누가 결정할까?
개발 요구의 주체를 알았기에 이에 대한 해답도 쉽게 유추할 수 있다.
Generic한 소프트웨어의 경우 개발 요구의 주체가 개발자이기 때문에 소프트웨어의 스펙을 개발자가 결정한다.
반대로 Customized된 소프트웨어의 경우 개발 요구의 주체가 사용자이기 때문에 소프트웨어의 스펙을 사용자들이 결정한다.
소프트웨어 공학이란?
소프트웨어 공학에서 다루는 것
소프트웨어 공학은 소프트웨어를 어떻게 해야 잘 만들지에 대한 모든 걸 포함한다.
그 중에서도 Cost-Effective에 대해 고려한다.
Cost-Effective
Science VS Engineering
Cost-Effective에 대해서 알아보기 전에 우선 Science와 Engineering의 차이를 알아보자.
둘의 핵심적인 차이는 Discovery다.
Science는 원래 있는 자연법칙을 찾아나가는 것(discovery)인 반면, Engineering은 기존에 있는 것을 재조합하여 새로운 것을 만드는 것(invention)이다.
Scientist와 Engineer의 입장
둘의 입장차이를 극명하게 보여주는 예시를 보자.
깨져도 시간이 지나면 다시 수복이 되는 투명한 유리와 같은 물질을 찾았다고 해보자.
기존의 유리들과 특성이 거의 비슷한데 깨져도 붙여만 놓으면 금세 원래대로 돌아온다.▼
이런 물질을 찾았다고 했을 때 드는 생각은 ‘이걸로 스마트폰 액정을 만들면 내구성이 해결되겠는데?’ 일 것이고, 이를 이용해 깨져도 원상복구 되는 스마트폰 액정 개발도 성공했다고 하자.▼
그런데 이 액정은 스마트폰 하나에 들어가는 분량이 10억이다.
그렇다면 이 스마트폰은 상품가치가 있을까? 아마 이 가격으로는 절대 상용화가 될 수 없을 것이다.▼
하지만 Scientist들에게는 의미가 있다.
상용화를 시키든 말든 어쨌거나 새로운 물질을 찾은 것이니까.
허나 반대로 아까 말했듯이 Engineer들에게는 의미가 없다.
이 스마트폰은 중동 석유 부자들 외에는 팔 수 없기 때문이다. (심지어 석유부자들도 이걸 왜사? 할 수 도 있다.)▼
그래서 Engineer들은 Cost와 Quality를 조절해야하고, 이를 한 단어로 Cost-Effectiveness라고 한다.
Cost
그렇다면 cost로는 무엇이 있을까?
외적으로는 시간과 사람이 있을 것이고 이는 정해져있는, 한정된 요소이다.
사람하고 시간이 정해져있는 상황에서 퀄리티를 올리는게 목표다.
정렬 알고리즘을 만드는 상황에서 버블 정렬을 사용했다고 하자.
정렬이 잘 된다면 퀄리티는 같은 거라고 했을 때, 버블 정렬은 리소스가 너무나도 많이 들어간다.
메모리도 많이 먹고 시간도 오래걸린다.
이러면 Cost-Effective하다고 할 수 없다.
그렇기에 Cost-Effective한 소프트웨어를 위해 설계를 잘해야한다.
위의 경우에는 버블 정렬이 아닌 퀵 정렬이나 상황에 맞게는 합병 정렬을 사용하는 쪽으로 설계를 할 수 있다.
그것 외에도 유지보수를 하고 기능 추가를 하는 것도 자원으로 칠 수 있으므로 maintenance와 reuse하기 좋게 설계하는 것도 중요하다.
소프트웨어 요구사항
디자털 사회에서의 수요
21세기에 들어오면서 사회가 점점 아날로그에서 디지털로 변하기 시작했다.
불과 2000년대 초만해도 휴대전화는 소위 잘 사는 사람들만이 누리는 특권이었는데, 이제는 스마트폰 보급률이 90%를 넘어섰다.
그렇다고 보급만 잘되었는가 하면 그것도 아니다. 불과 20년전이지만, 그 때 당시의 사람들은 상상도 못할 서비스들이 대거 등장하고 소프트웨어에 대한 수요도 대폭 증가했다.
이렇게 사회 전반에서 소프트웨어에 관심을 가지고 소프트웨어 기반의 사회 시설, 서비스들이 구축이 되면서 개인, 기업 구분 할 것 없이 소프트웨어에 대한 수요가 증가하게 되었다.
수요의 증가와 함께 소프트웨어의 복잡도 또한 증가했다.
기존에 있는 시스템위에 계속해서 시스템을 쌓아올리다보니 코드의 길이가 엄청나게 증가하게 되었다.
우리가 사용하는 OS의 코드 길이를 생각하면 아마 쉽게 이해가 될 것이다.
소프트웨어의 수요와 복잡도가 증가했다는게 무슨 상관인가 싶을 것이다.
진짜 문제는 복잡도가 증가한 소프트웨어들의 빠른 출시를 요구하는 것이다.
복잡도는 계속해서 증가해가는데 그에 대한 요구도 증가하고, 그런 증가 속도보다 더 빠른 출시를 원하게 된 것이다.
그러면 어떻게 해야 요구사항을 맞출 수 있을까?
앞에서 이야기한 Cost-Effective하게, 더 싸고 더 빠르게 소프트웨어를 만들기 위해서는 장기적으로 소프트웨어 공학 기술이 필요하다.
(글 제목을 보면서 이 말이 언제 나오나를 기대하고 있었을 것으로 예상이 된다.)
반대로 이야기 하면 소프트웨어 공학 기술을 사용하지 않으면 Cost-Effective 하지 않게 소프트웨어를 만들게 된다는 것이다.
프로그래밍이라는 학문이 등장한지는 그리 오래되지는 않았지만, 비교적 예전에는 다 모여서 해야할 일을 N등분 하고 헤어져서 각자 만들고 합치는 방법을 택했다고 한다.
이렇게 일을 분담하는 것은 어느 분야에서든 공통적으로 행해지는 방식이고, 이 방식은 매우 공평하고 인력을 병렬적으로 이용할 수 있다는 점에서 굉장히 효과적이다.
말은 이렇게 했지만 아주 당연하게, 기본적으로 사용되는 일 분담 방식이다.
하지만 이렇게 개발을 하게 되면 N개로 분할된 일들은 합치기도 힘들고, 새 기능을 넣기도 힘들다.
심지어는 역할 분담이 잘못되면 개발 의존성 때문에도 지연될 수 있다.▼
이는 각자가 프로젝트를 이해하고 있는 방식이 다르기 때문이다.
이런 문제점을 느낀 초기 개발자들은 이렇게 개발을 해서는 안되고, 좀 더 구조적인 개발의 필요성을 느껴 소프트웨어 공학을 연구하기 시작했다.
소프트웨어 프로세스란?
소프트웨어 프로세스의 단계
Specification
Spec이라고 줄여서 부르기도 하고 아무래도 컴퓨터나 핸드폰에서 많이 본 용어일 것이다.
하드웨어의 Specification은 어떤 부품이 들어갔는지를 이야기하는 것이라면, 소프트웨어의 Specification은 기능을 명시하는 것이다.
즉, 소프트웨어에 들어갈 기능들을 문서화 시키는 것이다.
Design and implementaion
Specification 단계에서 나온 기능들을 코드로 옮기는 것을 말한다.
여기서 Design은 기능들을 구현하기 위해 필요한 클래스와 함수의 틀(매개변수와 반환 값)을 정의하는 것을 말하고, implementation은 비어있는 함수의 틀을 채우는 것을 말한다.
Validation(Testing)
Validation은 디버깅 과정을 말한다.
앞에서 구현한 것들이 제대로 구현이 되었는지, 디자인이 잘못된 것은 아닌지를 확인해보는 단계다.
쉬운 말로는 Testing이 있다.
Evolution(Maintenance)
Evolution은 이름 그대로 진화, 버전 업 하는 것을 말한다.
버전 업에는 새로운 기능 추가도 있겠지만, 유지보수를 하는 것도 포함이 된다.
소프트웨어 프로세스에 드는 비용
그렇다면 각 단계는 어느 정도의 비용(cost)을 소모하게 될까?
프로젝트 전체에 드는 비용을 100이라고 하면 아래와 같이 분할이 되곤 한다.▼
우리는 지금까지 구현이 프로그래밍의 전부라고 생각했지만, 프로젝트에서 구현의 부분은 큰 비중을 차지하지 않는다.
오히려 Integration and Testing, 즉 병합과 테스트 부분이 터 큰 비중을 차지하고 있다.
즉, 우리가 지금까지 해왔던 구현 부분은 소프트웨어 개발에 있어서 가장 비중이 적고 쉬운 부분이라고 할 수 있는 것이다.
프로그램에 따른 비용 비중
중요한(버그 생기면 큰일나는) 프로그램들, 예를 들면 금융, 군사, 자율주행과 같은 프로그램들은 실제 서비스가 될 때 예기치 못한 버그가 생기면 안된다.
따라서 Implementation 비중이 굉장히 적고 Integration과 Testing의 비중이 크다.
하지만 중요하지 않은 프로그램들, 어느정도의 버그는 수용할 수 있는 프로그램들은 상대적으로 Implementation의 비중이 크다.
우리가 내는 학교 과제들, 한 번 짜놓고 다시 안보는 그런 프로그램들은 Integration과 Testing의 비중이 0에 가깝다.
이런 비중은 상황에 따라, 어떤 프로그램을 개발하는지에 따라 달라질 수 있다.
아래는 시스템 개발에 들어가는 비용 비중을 보여주는데, 대체로 System development의 비중이 System evolution, 즉 유지보수보다 훨씬 적다. ▼
처음 만들 때 유지보수하기 좋게 만들어야 system evolution(버전 업) 하기 좋다.
물론 유지보수하기 좋게 만들기 위해서는 소프트웨어 공학적으로 시스템 설계를 잘 해야한다.
그렇다면 어떻게 해야 소프트웨어 개발을 잘 할까?
소프트웨어 개발에는 universal한 그런 툴이나 방식은 없다.
소프트웨어에는 정답이 없으니 ad hoc하게 해라. 각자 개발자들이 알아서 창의적으로 써라.
Ad hoc - 반대말은 standard. 특정 목적에 맞게끔 하는 이라는 뜻.
창의적이라는 말은 경험이 풍부해야한다는 말이기도 함. 요래요래 해봤는데 좋더라 같은거.
그럼에도 공통적으로 지켜야하는 것들이 있어야 한다.
- 마구잡이로 하지 말고 이해하고 관리한다.
- 요구사항을 분석하고 디자인한다.
- 소프트웨어 재사용을 해야한다. 처음부터 짜는건 불가능하다.
구체적인 방법론은 다 다를지언정 위의 것들은 지켜야한다.
좋은 소프트웨어의 특성
좋은 소프트웨어의 특성은 무엇일까?
아래에는 그 특성들의 키워드를 나열해보았다.
Maintainability
유지보수하기 쉬워야 한다.
소프트웨어의 구조가 체계적으로 설계가 잘 되어야한다는 것이다.
Dependability
Dependability의 depend의 뜻이 ‘의존’이기에 Dependability의 의미를 의존할 수 있는 으로 해석할 수 있다.
사전에도 그렇게 나와있기도 하지만, 소프트웨어 공학에서는 의존한다는 의미보다는 믿을 수 있다는 말에 더 가깝다.
즉, 신뢰라는 의미다.
신뢰라고 하면 여러 단어들이 떠오를 수 있다.
- Availability
- Reliability
- Security
- Safety
- Integrity
Dependable은 이 다섯가지를 다 포함하는 포괄적인 신뢰라는 의미다.
Available
사용 가능하다는 말 그 자체를 의미한다.
Ready for service, 서비스를 이용할 수 있다는 말이다.
Reliable
Reliable은 갑작스러운 이유로 종료되지 않는 것을 믿을 수 있음을 말한다.
서비스가 실행되면 서비스가 종료될 때 까지 중간에 다른 이유로 종료되지 않는 것을 말한다.
Secure
외부의 공격에 대해 방어할 수 있다.
이름 그대로 보안이다.
Safe
Secure와 Safe 둘 다 보안이라는 의미가 아닌가 싶지만 둘은 조금 다른 의미로 쓰인다.
Secure가 서비스 자체에 대한 공격으로부터 보호하는 것, 즉 서비스 제공자의 보호를 의미한다면, Safe는 사용자에 대한 보호를 의미한다.
이 서비스를 이용해도 사용자의 정보 유출과 같은 사고가 일어나지 않음을 의미한다.
Integrity
무결성이라는 뜻으로, 실제 유효한 연산만 반영되어있다는 뜻이다.
Efficiency
좋은 소프트웨어는 효율이 좋아야 한다.
그렇다면 효율적이라는 것은 알겠는데, 비슷하게 생긴 단어인 Effective 와는 무슨 차이일까?
둘의 차이를 정리하자면 아래와 같다.
Effective
뜻은 모두 알겠지만, 효과적이라는 의미다.
여기서 효과는 목적이라고 볼 수 있다.
즉, 목적을 얼마나 달성했냐로 볼 수 있다.
목적 이상을 달성했으니 효과적이다.
Efficient
효율적이라는 의미로 시스템의 리소스를 최소화 한다는 의미이다. ▼
적은 노력으로 목적을 달성했으니 효율적이다.
Acceptablility
수용성이라는 뜻인데, 받아들이는 주체는 고객이다.
고객이 해당 서비스를 받아들이는 것을 말한다.
예를 들면, 노인을 위한 앱인데 글씨가 굉장히 작아 보기가 힘들면 Acceptable하지 못하다고 할 수 있다.
마치며
이번에는 소프트웨어 공학의 전반적인 내용들에 대해서 알아보았다.
다음에는 소프트웨어 공학의 세부적인 내용들에 대해 정리를 해볼 것이다.
'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 |
| 1. 소프트웨어 공학 개요 (0) | 2024.01.18 |
