소프트웨어는 프로그램, 데이터 그리고 프로그램 설계서로 이루어져 있다. 우리가 쓰는 대부분의 소프트웨어는 필요한 데이터가 있어야 작동을 한다. 데이터가 없으면 프로그램은 무용지물인 경우가 많다. 사람도 지식이 없으면 생각할 수 없는 것처럼 프로그램도 지식과 같은 데이터가 꼭 필요하다. 소프트웨어 프로그램은 프로그램 언어로 만든다. 그런데 프로그램 언어 만을 보면 다른 사람이 이해하는데 어려움이 많기 때문에 프로그램의 내용을 설명한 프로그램 설계서가 필요하다. 사람의 지식을 정리한 책과 같다고 할 수 있다. 책을 보고 공부하듯이 말이다.

프로그램 만드는 원칙이 두가지 있는데 첫째가 설계서에 따라 만들기, 둘째가 만든 프로그램은 에러가 없어야 한다. 자기 마음대로 프로그램을 만들 수는 없다. 프로그램 설계서가 지시한 것들을 만들어야 여러 개의 프로그램이 모였을 때 다 같이 동작하기 때문이다. 또한 기본적으로 컴퓨터가 이해할 수 있도록 해야 하기 때문이다. 또한 만들어진 프로그램은 에러가 없어야 한다. 에러가 있는 프로그램은 사용할 수 없기 때문이다.

일반적인 소프트웨어 개발 프로젝트에서는 소프트웨어 아키텍트가 처음 소프트웨어를 기획하면 소프트웨어 구조 모델인 아키텍쳐를 만든다. 그 후에 설계 전문가가 소프트웨어 아키텍쳐를 기반으로 프로그램 설계서를 한 장 한 장 만들게 된다. 그리고 나서 최종적으로 설계서의 내용대로 프로그램을 만들어야 하기 때문에 프로그래머 마음대로 프로그램을 만들어서는 안되는 것이다.

소프트웨어 개발하기 위해서는 여러 사람이 참여하는 프로젝트를 구성한다. 작은 소프트웨어는 혼자도 몇 시간 혹은 몇 일 만에 개발해 낼 수도 있지만, 어떤 소프트웨어의 경우에는 몇 개월에서 몇 년이 걸리기도 한다. 이렇게 오랜 기간 동안 소프트웨어 개발하기 위해서는 특별한 관리 방법이 필요하다. 이 방법을 개발 방법론이라고 한다. 소프트웨어를 만들다가 실패한 사례가 많이 있기 때문에 ‘어떻게 하면 제대로 소프트웨어를 개발할까?’를 집중적으로 연구해서 만든 것이다. 요즘은 한 번에 모든 프로그램을 다 만드는 것이 아니라, 중요한 프로그램만 우선 만들어서 잘 되는지 확인하고 잘 되는 것이 확인되면 다른 기능을 추가해서 만들고 하는 방법으로 전체 소프트웨어를 완성하는 방법을 많이 사용한다. 다양한 프로젝트의 실패 경험을 가지고 다시는 동일한 실패를 하지 않겠다고 만든 방법이라고 할 수 있다.

제품 개발에서 사용되는 린스타트업 방식에서 제시된 MVP(Minimum Viable Product : 최소 존속 가능 제품)이라는 개념과 동일하다고 할 수 있다. 이것은 최소의 노력과 개발 기간으로 고객과 시장의 반응을 측정해 볼 수 있는 제품을 의미한다. 어차피 고객의 반응은 사전에 조사하고 파악하는데 한계가 있으므로 완벽한 제품을 만들려고 시간과 노력을 들이는 것보다 최소한의 필요 기능이 갖추어진 제품을 만들어서 출시한 후 고객의 반응을 보아 가면서 개선을 하는 것이 더욱 빠르고 효과적이라는 이론이다.

프로그램을 설계하기 위해서는 우선 프로그램을 요청한 내용을 정확히 이해하기 위한 분석을 실행한다. 요구사항 분석이라고 부른다. 특히 내가 필요해서 만든 프로그램이라면 요구사항 분석을 할 필요가 없을 수도 있지만 남이 요청하여 프로그램을 개발하는 것이라면 이 요구사항 분석은 상당히 중요하다. 사람의 요구사항은 구체적이지 않을 때가 많다. 요구사항과 욕구를 구별하여 구체적으로 정리하는 것이 요구사항 분석에서 중요하게 할 일이다.

고객이 요리사에게 배가 고프니까 밥을 해달라고 할 경우에 요리사는 요리를 하기 전에 고객에게 어떤 것을 먹고 싶은지 물어보고 요리를 하는 것이 좋을 것이다. 그렇지 않고 요리사가 하고 싶은 대로 요리를 해서 줬는데 상황에 따라서는 원하는 요리가 아니라고 안 먹을 수도 있을 것이다. 이런 낭패를 없애기 위해서 요리 전에 어떤 요리를 원하는지 확실하게 의사를 물어 보고 요리를 해야 한다. 프로그램도 마찬 가지로 상대방인 고객이 요구하는 프로그램의 내용을 구체적으로 물어보고 설계를 한 후에 설계의 내용이 상대방이 원하는지 확인을 하는 것이 더 좋을 것이다.

사람이 프로그램을 개발하다 보면 본의 아니게 실수로 프로그램을 잘 못 만드는 경우가 있는데, 다행히 사전에 찾아서 해결하면 좋겠지만 그렇지 못한 경우가 있다. 시간이 지남에 따라 다양한 종류의 버그와 결점을 사전에 발견하는 방법을 찾게 되었고 미처 발견하지 못한 버그나 결점에 대응하는 다양한 방법도 만들었다. 하지만 아직까지도 보이지 않는 소프트웨어의 알고리즘의 오류를 찾아 내는 것은 상당히 힘든 일 중의 하나이다.

미국의 나사(NASA)에서도 소프트웨어를 개발한다. 그런데 우주선을 개발하여 발사하는 것이 핵심 임무 중의 하나이므로 내재된 소프트웨어의 문제를 미처 발견하지 못한 채로 사용하다 문제가 생기면 우주선과 비행사들에게 큰 재앙이 발생할 수 있다. 그래서 생각해 낸 것이 동일한 소프트웨어를 두 곳의 프로젝트에서 각기 개발하는 것이다. 두 곳에서 개발하다 보니 소프트웨어의 프로그램 안에 있는 알고리즘이 조금씩 다를 것이다. 하지만 궁극적으로 소프트웨어가 하는 일은 동일하다. 그렇게 만든 두 종류의 소프트웨어를 우주선에서 사용한다. 만약 하나의 소프트웨어에서 에러가 나면 다른 소프트웨어가 대신 수행하게 하여 소프트웨어가 가진 알 수 없는 문제점에 대응하기도 한다.

채성수 chaesungsoo@iabacus.co.kr 소프트웨어 개발 전문기업 ㈜ 애버커스 사업총괄 부사장. 엘지전자와 엘지씨엔에스(LG CNS)에서 다년간 컴퓨터 관련 사업을 추진한 전문가이다. 국가 공인 최고 자격인 정보관리기술사로 성균관대 및 서강대에서 컴퓨터 관련 연구를 수행했으며 소프트웨어 공학, 컴퓨터적 사고에 대해서 관심을 갖고 다양한 활동을 하고 있다.

(*이 칼럼은 Nextdaily의 편집방향과 다를 수 있습니다.)