소프트웨어 개발 생명 주기의 이해

많은 사람들이 프로그래밍이라는 것에 매력을 느끼고 자신이 직접 프로그램을 만들어보고자 공부를 시작합니다. 여러 웹 사이트를 돌아다니며 정보도 찾아보고, 지인들의 추천을 받아 좋다는 책을 몇 권 구입하여 열심히 읽습니다. 당연히 책에 나와 있는 예제들은 하나도 빠짐없이 타이핑하고, 컴파일시켜 돌려보고는, 프로그램이 돌아가는 것을 확인한 순간 자신이 프로그램을 만들었다는 착각에 빠집니다. 그러고 나서 ‘난 무슨 언어, 무슨 언어를 공부했다’고 말합니다.

정말 이것으로 다 된 것일까요? 이런 사람들에게 문제를 주고 프로그램을 작성해보라고 했을 때, 프로그램을 작성할 수 있을까요? 대부분의 독자들은 ‘아니오’라고 답할 것입니다. 이런 경험을 직접 해본 사람들도 적지 않을 것이고요. 이것이 프로그래밍에 입문하는 대다수 사람들의 현실입니다. 그리고 많은 수의 입문자들, 또는 초보자들이 프로그래밍에 대해 가지고 있던 열정과 흥미를 잃고 쉽게 포기하게 되는 이유이기도 하죠. 생각해 보세요. 열심히 공부하고 또 공부를 했는데도 내가 직접 프로그램을 만들어 볼 수 없다면 그 공부가 과연 재미있겠습니까?

필자는 학원에 찾아오는 많은 사람들과 상담을 하면서 대다수의 초보자들이 왜 이런 시행착오를 겪는지에 대한 근본적인 원인을 너무나도 절실히 느끼고 있습니다. 그것은 다름 아닌 대부분의 사람들이 너무나도 막연하게 ‘프로그래밍 언어 한두 가지 정도만 공부하면 프로그램을 만들 수 있겠지’라고 생각한다는 것입니다. 아무리 프로그래밍 언어를 많이 알고 있어도, 그것을 언제 어떻게 써야 하는지를 모른다면 무용지물이 된다는 당연한 이치를 모르고 있는 것이죠. 중요한 것은 프로그래밍 언어가 아니라 프로그램을 만드는 방법입니다. 이 연재는 이와 같은 시행착오를 겪은 사람들에게 프로그램을 만들기 위해서는 어떻게 문제에 접근해야 하는지에 대한 방향을 제시하고자 합니다.

미술시간에 색칠부터 했던가?

문제의 발단은 대부분의 입문자들이 ‘소프트웨어 개발 = 코딩’이라는 잘못된 생각으로 접근한다는 것입니다. 그리고 이것은 비단 처음 프로그래밍을 접하는 사람들만의 문제는 아닙니다. 학교에서 여러 학기 강의를 듣고 오랜 기간 동안 전산을 공부했다는 사람들 중에서도 이와 같은 생각을 갖고 있는 사람들이 있기는 마찬가지죠. 하지만 여기서 한 가지 정확하게 알고 넘어가야 할 사실은 코딩 작업, 즉 프로그래밍 언어를 사용하는 단계가 소프트웨어 개발의 전부가 아니라는 것입니다.

가령 미술 시간에 그림을 그린다고 생각해 봅시다. 제일 처음에 해야 할 일은 그릴 대상을 면밀히 관찰하고 좋은 구도를 잡는 일이고, 그 다음에 해야 할 일은 대략적인 밑그림을 스케치하는 일이 될 것입니다. 그 후에 색칠을 하게 되는 것이죠. 만약에 앞의 여러 단계는 생략한 채 곧바로 색칠을 시작한다면 어떻게 될까요? 밑그림 없이는 색칠은커녕 전혀 그림에 손도 대지 못하는 경우가 대부분일 것입니다. 물론 몇몇 감각 있는 사람들의 경우는 색칠부터 하면서도 그림을 그려낼 수 있을지 모르겠습니다. 그렇다고 하더라도 밑그림 없이 그린 그림이 그렇지 않은 그림보다 더 완벽한 구도를 갖고 있다고 생각하기는 힘들겠죠. 밑그림이 없다면 좋은 그림이 나오지 않을 것이라는 사실은 누구라도 쉽게 알아챌 수 있습니다.

결국 좋은 그림을 그리기 위해서는 그림을 그리기 위한 절차를 잘 알고 있어야 하며, 좋은 구도를 잡는 방법과 스케치하는 방법에도 관심을 갖고 많이 연습해두어야 합니다. 이런 절차에 따라 작업이 잘 진행되었다면, 나중에 색칠을 할 때 물감으로 색칠을 하던 크레파스로 색칠을 하든 또는 파스텔로 색칠을 하든 구도가 잘 잡혀 안정되고 보기 좋은 그림이 나올 것이 분명하죠. 어차피 어떤 재료로 색칠을 하든 색을 표현한다는 면에서는 동일하고, 다만 결과물의 질감이 조금 다를 뿐이니 어떤 재료를 사용할지는 그림을 그리는 사람이 그림의 성격에 따라 결정하면 되는 것입니다.

프로그램을 만드는 작업도 마찬가지입니다. 좋은 프로그램을 만들기 위해서는 많은 작업이 필요하며 여러 단계를 거쳐야 합니다. 우선은 우리가 해결해야 할 문제를 잘 이해해야하고, 프로그램이 어떤 일을 해야 하는지를 명확하게 파악해야 하며, 이를 토대로 밑그림을 그려야만 합니다. 이런 밑그림 없이 바로 코딩을 시작한다면 어떤 일이 일어날까요? 대부분의 경우 어떻게 코딩을 해야 할지 손도 대지 못할 것이고, 설령 작업을 진행할 수 있는 사람이 있다 하더라도 그렇게 만들어진 프로그램이 구도가 잘 잡힌 좋은 결과물일 리 만무합니다.

반대로 밑그림이 잘 그려져 있다면 여러 종류의 재료 중에서 알맞은 것을 골라 색칠할 수 있었듯이, 여러 가지 프로그래밍 언어 중에서 적당한 언어를 골라 코딩할 수 있습니다. 따라서 프로그램을 작성할 때 C 언어를 사용할 수도 있고, 자바를 사용할 수도 있고, 베이직을 사용할 수도 있으며, 어떤 언어를 사용할 것인가는 작성하고자 하는 프로그램의 성격에 맞춰 결정하면 되는 문제입니다. 이처럼 프로그래밍 언어는 코딩을 할 때 필요한 하나의 도구일 뿐이며, 코딩이 소프트웨어 개발 전체를 말하는 것이 아니라는 사실을 이해해야 합니다.

소프트웨어 개발 생명주기

이제는 프로그램을 만들기 위한 작업 단계로서 어떤 것들이 있으며, 각 단계들이 어떤 순서로 운영되는지 살펴봅시다. 소프트웨어를 개발하기 위해서는 소프트웨어 개발 생명주기(이하 SDLC, Software Development Life Cycle)라는 것을 이해할 필요가 있습니다. 용어 자체는 좀 길지만 의미를 간단하게 정리해보면 소프트웨어가 탄생되고, 사용되며, 소멸될 때까지 절차를 정리해 놓은 것이라고 생각하면 됩니다.

그래서 생명주기라는 이름이 붙은 것이지요. 그래도 용어가 좀 길긴 길죠? 그래서 요즘엔 SDLC를 줄여서 개발 과정(Development Process)이라고도 합니다. 사실 SDLC의 각 단계와 절차는 어떤 입장에서 소프트웨어를 만드느냐에 따라 조금씩 달라집니다. 이런 입장의 차이와 그에 따른 운영 방식의 차이는 방법론이라는 형태로 정리되어 있습니다. 하지만 가장 고전적인 방식의 SDLC을 살펴보면 <그림 1>과 같습니다.

<그림 1> 고전적인 SDLC

각 단계별로 보면 계획 단계는 소프트웨어에 대한 타당성을 검토하고 개발에 필요한 자원과 일정 등을 예측하고 추정하는 단계이며, 분석 단계는 소프트웨어가 해야 할 일이 무엇인지를 파악하는 단계이고, 설계는 분석 단계에서 파악된 내용을 구체화하는 단계입니다. 이렇게 구체화한 후에야 구현(코딩)이 가능하며 작성된 코드는 철저한 테스트를 거쳐 완성됩니다. 완성된 후 사용자에게 전달된 소프트웨어는 지속적으로 사용되며, 여러 요인에 의해 유지보수가 필수적으로 동반됩니다.

이렇게 운영되던 소프트웨어를 사용자가 더 이상 쓰지 않게 된다면 그 소프트웨어는 생명을 다하게 되는 것이며, 이로서 생명 주기가 끝나게 되는 것이죠. 이렇게 이야기하니까 마치 소프트웨어가 무슨 생명체인 듯한 느낌이 들지 않나요? 여담이긴 하지만 자신이 고생해서 만들어낸 소프트웨어를 보면 마치 자기 자식과 같은 느낌이 든다는 개발자들도 있답니다.

좀더 명확하게 각 단계의 의미를 파악하기 위해서 다른 이야기를 하나 해보죠. 내집 마련을 목표로 하고 있는 지법서(45세, 주거 부정)라는 사람이 있습니다. 지법서 씨가 집을 마련하기 위해 제일 처음 해야 할 일은 무엇일까요?

우선은 자신이 처한 상황과 준비할 수 있는 예산 등을 정확히 판단하여 집을 살 것인지, 아파트를 분양받을지, 새로 집을 지을 것인지에 대한 결정을 내려야 합니다. 또 이런 결정과 함께 구체적인 계획도 수립해야겠죠. 계획의 내용이란 아파트를 분양받는다면 언제 어느 아파트를 청약할 것이며, 중도금은 어떻게 해결할 것인지 등의 내용이 될 것이고, 집을 짓는다면 어느 업체에 공사를 맡기고 언제까지 마무리 할 것인지 등의 내용이 될 것입니다.

지법서 씨는 모든 상황을 종합 판단하여 집을 새로 짓기로 결정했습니다. 그렇다면 우선은 설계사에게 설계를 맡겨야겠죠? 하지만 설계사에게 설계를 맡긴다고 해도 설계사는 바로 설계도를 작성하지 않을 것입니다. 현지답사도 해봐야 할 테고 지법서 씨에게 이것저것 물어볼 것이 많으니까요.

어느 정도 크기의 집이 필요한건지, 같이 살 가족은 몇 명인지, 방은 몇 개나 필요하고 마당은 어떻게 할 것인지 등 이렇게 모든 요구 사항들을 파악하는 단계가 우선되어야 하고, 이런 정보들이 있어야만 좋은 설계도를 그릴 수 있습니다. 물론 이런 과정 없이도 설계도는 그릴 수 있겠지만, 그렇게 된다면 그 것은 지법서 씨가 꿈꿔오던 그런 집은 아니겠죠.

어려운 여러 과정들을 거쳐 설계도가 완성되었습니다. 그럼 이젠 시공을 해야죠. 기초공사를 하고 벽을 쌓아올리는 등 도면에 그려진 집의 모습이 현실에서 구체화되어지는 과정을 거치게 됩니다. 물론 공사가 진행되는 틈틈이 집이 제대로 만들어지고 있는지 감리사가 감리를 하는 것은 당연한 것이고요. 이렇게 집이 완성되면 이젠 지법서 씨 가족이 들어가 살면 됩니다. 드디어 내 집 마련에 성공한 지법서 씨! 하지만 살다보니 집의 여기저기에 손 볼 일이 많군요. 노후한 부분에 대한 하자 보수는 물론이고, 필요에 따라서는 증축, 개축도 하는 등의 사후 관리가 필요하니 말이죠. 만만치 않은 비용이 들어가겠지만 그래도 내집 마련에 성공한 지법서 씨가 부러울 따름이네요.

왜 갑자기 장황하게 집 짓는 이야기를 했을까요? 집을 만들어가는 과정이 프로그램을 작성하는 과정과 비슷한 면이 많기 때문입니다. 얼마나 비슷한지 집을 짓는 과정과 SDLC의 각 단계를 비교해 보도록 하죠. 처음에 어떻게 집을 마련할지 생각했던 단계가 SDLC에서의 계획, 거주할 사람이 어떤 집을 원하는지 알아내는 단계는 SDLC에서의 분석, 설계 도면을 작성하는 단계는 SDLC에서의 설계에 해당하고, 공사의 진행은 코딩, 감리는 테스트에 해당한다고 볼 수 있습니다. 또 입주해 살면서 사후 관리를 하는 단계가 운영 및 유지보수 단계라고 생각하면 되죠. 많이 비슷하죠?

집을 짓는 일은 기존에 존재하지 않는 새로운 것을 창조해내는 작업입니다. 무에서 유를 창조한다는 것이 쉬운 일은 아니죠. 정확한 절차에 의해 차근차근 일을 진행하지 않으면 쉽게 이룰 수 없습니다. 무턱대고 설계 도면도 없이 공사를 시작한다면 부실 공사만 초래할 뿐이죠. 소프트웨어도 마찬가지입니다. 정확한 설계도 없이 코딩을 시작한다면 아무 것도 되지 않을 뿐더러, 설령 돌아가는 프로그램을 작성했다고 하더라도 그것은 부실한 프로그램이 될 수밖에 없다는 것을 명심해야겠습니다.

해야 할 일은 하나, 방법은 여러 가지

SDLC에서 계획이 무엇인지, 구현이 무엇인지, 또 테스트와 유지보수가 무엇인지는 명확합니다. 그러나 분석과 설계는 구별이 좀 모호하다고 느낄 수 있죠. 구체적으로 분석과 설계라는 개념의 차이가 무엇인지 알아보도록 하겠습니다. 다음과 같은 수열에서 20번째 항의 값은 무엇인지 알아내는 문제가 주어졌습니다.

1, 1, 2, 3, 5, 8, 13, ...

이 문제를 보고 ‘20번째 항의 값은 XXX이다’라고 바로 말할 수 있는 사람이 있을까요? 영화 레인맨 속에 나오는 더스틴 호프만 같은 사람이 아니라면 아마도 불가능할 것입니다. 일반적으로 이런 문제를 풀 때 제일 먼저 해야 할 일은 문제를 정확히 이해하고 분석해내는 일입니다. 이 문제에서는 주어진 수열이 어떤 규칙으로 구성되어 있는지를 분석해 봐야겠네요. 자세히 살펴본 독자들은 이미 눈치를 챘겠지만, 이 수열의 처음 두 항은 값이 1이고, 그 이후의 항부터는 이전의 두 항을 더한 값을 항 값으로 사용하고 있습니다. 그래서 셋째 항은 1과 1을 더한 2, 넷째 항은 1과 2를 더한 3, 그 다음 항은 2에 3을 더한 5가 되는 것이지요.

그렇다면 우리가 해야 할 일은 이런 규칙대로 계속 더해가면서 20번째 항까지 계산해내는 것입니다. 이렇게 문제를 보고 무엇(what)을 해야 할지 알아내는 것을 분석이라고 합니다. 이 문제의 경우 문제를 분석하는 것이 비교적 쉽군요. 하지만 많은 경우에서 문제의 이해와 분석이 그리 쉽지만은 않습니다. 어떻게 보면 이렇게 쉬운 문제로 우리의 논의를 시작하는 것이 행운이라는 생각도 듭니다.

분석 단계에서 문제 해결을 위해 무엇을 해야 하는지를 알아냈다면 그 다음에 결정할 일은 그 일을 어떻게 할 것인가 하는 문제입니다. 쉽게 말해서 방법을 찾아보자는 것이지요. 앞의 문제에서 답을 구하려면 이전의 두 항을 계속 더해나가야 하는데, 어떤 방법이 좋을까요? 암산이 빠른 독자라면 암산으로 하면 되겠죠. 하지만 암산에 자신이 없는 독자는 계산기를 이용하여 계산할 수도 있습니다.

이렇게 구체적으로 어떻게(how) 일을 진행해야 하는지를 정하는 것을 설계라고 합니다. 필자 역시 암산엔 별로 자신이 없으니까 계산기를 써야겠습니다. 직접 계산기를 두드려 볼까요? 7번째 항까지는 주어졌으니 8번째 항은 21, 9번째 항은 34, 10번째 항은 55, ... , 20번째 항은 6765가 되겠군요. 휴～계산기를 두드리는 일도 말처럼 그렇게 쉽지는 않네요. 수학에서는 이런 규칙을 갖는 수열을 피보나치(Fibonacci) 수열이라고 합니다. 전산에서는 피보나치 검색과 같은 알고리즘에서 유용하게 쓰이는 수열입니다. 어떻습니까? 이젠 분석과 설계의 차이가 무엇이고 왜 필요한지 조금 이해가 되셨나요? 이렇게 어떤 일을 해결하기 위한 실천이 이루어지기 전에, 무엇(what)을 해야 하고, 어떻게(how) 해야 하는지가 명확하게 정해져야만 정확하게 그 일을 해결할 수 있습니다.

갑자기 수학 얘기가 나와서 머리가 좀 아팠을지 모르겠습니다. 사실 필자도 수학과는 그렇게 친한 사이가 아니거든요. 이제는 좀더 현실적인 문제를 이야기해 보겠습니다. 요즘 한창 흥행에 성공하며 주가를 올리고 있는 영화 ‘매트릭스 2’가 어떤 내용인지 궁금해진 한 사람이 있습니다. 이 사람이 해결해야 할 문제는 ‘매트릭스 2를 보자’이겠죠. 이 문제를 해결해 봅시다. 언제나 ‘무엇을 해야 할 것인가’를 정하는 것이 먼저 입니다. ‘무엇을 할 것인가’를 고민하기에 앞서서 ‘어떻게 할 것인가’를 먼저 고민하는 사람은 없죠. ‘시청 앞에 가야지’라고 마음을 정한 다음에 ‘버스를 탈까, 지하철을 탈까, 어떻게 갈까?’를 고민하는 것이 옳지, ‘버스를 타야지’라고 정해놓은 다음에 ‘그런데 어디를 갈까?’라고 고민하는 것은 좀 어색하죠?

간혹 이렇게 어색한 일을 하는 사람들도 있긴 합니다. 무작정 방황하고 싶은 사람쯤 되겠죠. 하지만 그런 사람들에겐 ‘버스를 타고 아무데나 가자’가 ‘무엇을 해야 할 것인가’에 대한 고민의 결과일 것입니다. 사람들은 언제나 ‘어떤 일을 하자’라는 목표를 먼저 세우고, 거기에 대한 구체적인 방안을 마련한 다음, 실천에 옮기는 순서로 일을 처리한다는 사실을 기억합시다.

다시 영화 이야기로 돌아와서 영화를 보기 위해서 무엇을 해야 할지 생각해 봅시다. 우선은 언제 보러 갈지를 정해야하고, 혼자 보러 가면 심심할 테니까 같이 갈 수 있는 친구들을 찾아봐야겠죠? 물론 같이 갈 친구들을 먼저 찾은 다음에 친구들과 상의해서 영화를 볼 날짜와 시간을 정할 수도 있습니다. 하지만 지금 주어진 문제에서는 친구와 같이 영화를 보는 것이 목적이 아니라 영화를 보는 것 그 자체가 목적이므로, 내가 가능한 시간을 먼저 정해놓고 그 시간에 맞출 수 있는 친구를 찾아보는 것으로 일의 순서를 정하는 것이 좀더 합당할 것 같습니다.

그 다음으로 해야 할 일은 표를 예매하는 일이 될 것이고, 표가 예매되었으면 관람하려는 날에 시간에 맞춰 영화관에 가서 영화를 감상하면 되겠네요. 이렇게 무엇을 해야 할지에 대해서 먼저 생각해보는 단계가 꼭 필요한데, 이런 단계가 분석입니다. 분석의 결과를 <그림 2>와 같이 요약해 보았습니다.

분석에서 중요한 것은 ‘무엇을 할 것인가’에만 집중하는 것이며, ‘어떻게 할 것인가’에 대한 고려는 나중으로 미루어 놓는다는 것입니다. 그래야만 문제를 명확하게 파악할 수 있기 때문이죠. 처음부터 너무 상세한 부분까지 신경을 쓰다보면 큰 흐름을 놓칠 수 있습니다. 여기까지 작업이 진행되었으면 해야 할 일이 명확해졌으므로, 이제는 각 단계별로 어떻게 일을 해야 할지를 구체적으로 살펴볼 차례입니다.

1단계, 날짜와 시간을 정한다

날짜와 시간을 정하는 일은 어떻게 해야 할까요? 이건 혼자서 정하면 될 문제이니, 다이어리를 참고하여 약속이 없는 날을 고르면 되겠네요. 이건 처리 방법이 간단하군요. 다음으로 넘어가겠습니다.

2단계, 같이 보러갈 친구를 찾는다

친구를 찾는 방법 중에 제일 먼저 떠오르는 방법은 친한 친구들에게 일일이 전화를 걸어서 시간이 괜찮은지, 같이 보러갈 의향이 있는지를 직접 묻는 방법입니다. 조금 시간이 많이 걸리고 수고스럽겠지만, 내가 같이 하고 싶은 친구들을 선별해서 연락할 수 있다는 장점이 있네요. 또 하나의 방법으로는 속해있는 동호회 사이트에 번개를 하는 방법도 생각해 볼 수 있습니다. 재미있는 방법이긴 하지만 불특정 다수에 대한 공지이므로 정확한 인원 파악에 문제가 있을 수 있겠네요.

이럴 경우엔 공지를 올린 후 일정 기간을 줘서 그 기간 내에 참여 의사를 밝힌 사람들만 같이 가는 것으로 해야겠습니다. 지금으로선 이렇게 두 가지 방법으로 친구를 찾을 수 있으니, 이 두 가지 방법 중 한 가지를 고르면 됩니다. 이번에 영화를 볼 때는 좀 색다른 분위기를 위해서 번개를 해보도록 하겠습니다.

3단계, 표를 예매한다

표를 예매하기 위해서는 앞서 이야기한대로 정확한 인원 파악이 필요하며, 따라서 가장 우선적으로 해야 할 일은 동호회 사이트에 들어가서 참여 의사를 밝힌 사람이 몇 명인지는 알아내는 것입니다. 그 다음에 어떻게 예매할지를 생각해보는 것이죠. 만약 사무실 앞에 있는 영화관에서 본다면 점심시간 때 들어오면서 직접 예매를 할 수도 있겠고, 아니면 인터넷으로도 예매가 가능하죠. 조사해본 결과 사무실 앞의 영화관에선 ‘매트릭스 2’를 상영하지 않기 때문에 어쩔 수 없이 인터넷 예매를 해야겠네요.

4단계, 영화관에 간다

영화관에 갈 수 있는 방법은 버스, 지하철, 택시, 자가용 등이 있습니다. 택시는 비용상 문제가 있고 영화 관람이 끝난 후 친구들과 뒷풀이가 있을지도 모르니 자가용은 곤란하죠. 그렇다면 버스 아니면 지하철인데 차가 막히면 영화 시간에 늦을 수도 있으니 지하철로 결정!

5단계, 친구들을 만난다

친구들을 만나기 위해서는 약속 장소를 정해야합니다. 친구들에게 영화관 입구에서 기다리라고 해야겠습니다.

6단계, 영화를 감상한다

마지막이군요. 영화를 감상하기 위해서는 우선 예매한 표를 찾아야하고, 영화관에 입장해서 좌석을 찾아 앉아야 합니다. 그런 다음엔 편안한 자세로 감상하면 되지요.

자, 이제 모든 단계에 대해 구체적으로 어떻게 일을 처리할지에 대한 방법을 결정했습니다. 이렇게 어떻게 일을 처리할지에 대한 방법을 결정하는 것을 설계라고 했죠? 설계의 결과를 모두 모아 정리한 것이 <그림 2>입니다. 남은 것은 설계의 결과에 따라 그대로 실천하는 것 뿐 이죠. 즐겁게 ‘매트릭스 2’의 화려한 장면들을 감상할 수 있을 것입니다.

<그림 3> ‘매트릭스 2를 보자’의 설계 결과

열심히 설명은 했지만 조금은 멋쩍은 생각이 듭니다. 과연 저렇게 정리를 하고 일을 처리하는 사람이 실제로 있을까요? 영화를 보는 정도의 일이라면 특별한 절차를 거쳐 생각을 정리하지 않아도 이런 내용들이 순간적으로 머리 속에서 떠오를 것입니다. 그리고 바로바로 행동에 옮길 수 있겠죠. 그래서 인간의 두뇌는 위대하다는 것입니다. 순간적으로 모든 상황을 판단하고, 계획하고, 실행에 옮길 수 있도록 명령을 내리니까요.

만약 앞에서 언급한 문제를 컴퓨터가 수행하도록 프로그램으로 작성한다면 어떨까요? 컴퓨터도 인간의 두뇌처럼 ‘영화를 보자’라는 문제가 주어지는 순간 모든 것을 판단하고, 계획하고, 실행할 수 있을까요? 절대로 그럴 수 없습니다. 컴퓨터는 인간의 두뇌와는 비교조차 할 수 없을 정도로 단순하니까요. 따라서 컴퓨터가 직접 어떤 일을 실행에 옮길 수 있도록 명령을 내리려면 차근차근 한 단계씩 끊어서 명령을 내려야합니다. 그래야만 겨우 명령을 알아듣고 일을 수행하게 되는 것이죠. 결국 컴퓨터에게 내릴 명령의 집합체인 프로그램을 작성할 때에는 앞에서 해보았던 방식대로, 일처리 순서를 정확하게 한 단계씩 끊어서 정리한 후에 그 결과에 맞추어 차근차근 작성해야만 컴퓨터가 이해할 수 있다는 이야기가 됩니다.

이렇게 설계까지 마쳤다고 한다면, 프로그램을 만들기 위해 그 다음으로 해야 할 일은 설계의 결과를 컴퓨터가 알아들을 수 있도록 컴퓨터의 언어로 바꿔주는 것뿐입니다. 그 때 사용되는 도구가 바로 프로그래밍 언어입니다. 이제는 여러분이 열심히 공부한 프로그래밍 언어 실력을 십분 발휘하여 설계 내용에 맞춰 코딩을 한 후 나머지는 컴파일러에게 맡기면 되지요. 컴파일러는 여러분이 작성한 소스 코드를 컴퓨터가 알아들을 수 있는 언어로 무사히 번역해 줄 것이며, 이로서 프로그램이 완성되게 되는 것입니다. 이렇듯 여러 단계를 거쳐야만 제대로 된 소프트웨어를 작성할 수 있으며 코딩만으로는 소프트웨어 개발이 힘든 이유도 여기에 있습니다.

유지보수의 중요성

너무 영화 이야기를 오래 한 것 같습니다. 사실은 영화 이야기를 하려던 것이 아니라 분석과 설계에 대한 이야기를 하려던 것이긴 하지만요. 이제 SDLC에서 또 하나의 중요한 단계인 유지보수에 대해 이야기해 보겠습니다.

앞서서 새 집을 마련한 지법서 씨가 집을 지어서 입주할 때까지 걸린 시간은 얼마나 될까요? 몇 개월, 길면 1년 정도? 그러나 집에 입주한 후 그 집이 노후해서 헐어버릴 때까지의 시간은 짧으면 20년 정도, 길면 50년 이상이 될 수도 있을 것입니다. 새로운 집을 만들어내는 기간보다는 그 집을 계속 보수해가면서 사용하는 기간이 훨씬 길다는 말입니다. 따라서 초기 투자비용 못지않게 사후 관리를 위한 비용이 필요하게 됩니다.

어떤 독자들은 이렇게 생각할지도 모르겠네요. 사후 관리가 필요 없을 정도로 처음부터 완벽하게 만들면 될 것 아니냐고. 하지만 그 것은 불가능한 일입니다. 아무리 완벽하게 집을 지었다고 하더라도, 언젠간 수도관이 낡아서 물이 조금씩 샐 것이고, 방문은 삐거덕거릴 것입니다. 또 수십 년씩 지내다보면 유행이 지난 인테리어는 조금씩 바꿔줘야 할 필요성도 느끼게 되죠. 사후 관리는 피하지 못할 일인 것입니다.

이런 측면에서 생각해 볼 때, 거주자 입장에서 어떤 집이 좋은 집이라고 말할 수 있겠습니까? 수도관을 교체하기 위해 엄청난 비용을 지불해야만 한다면 물이 조금씩 새더라도 고칠 엄두를 내지 못하겠죠. 또 수도관 교체를 위해 일주일씩 단수가 된다면 불편함이 이만 저만 아닐 것입니다. 따라서 더 저렴한 비용으로 빠른 기간 안에 쉽게 고칠 수 있는 집이 좋은 집이라는 결론에 도달할 수 있습니다. 하지만 이런 일들이 가능하려면 분석과 설계 단계 때부터 철저히 사후 관리를 염두에 두고 작업을 진행해야 합니다. 만약 설계자가 집의 모양만을 염두에 두고 수도관을 이곳저곳에 마구 분산시켜 설계했다면 나중에 수도관을 교체하기 위해서 상당한 비용을 감수해야 하며, 교체 기간도 굉장히 오래 걸릴 것이 분명합니다.

이제 소프트웨어로 돌아와 봅시다. 소프트웨어의 경우도 앞에서 말했던 집의 경우와 비슷합니다. 개발을 위한 기간보다는 그 소프트웨어를 유지보수해가며 사용하는 기간이 훨씬 길지요. 그리고 소프트웨어도 역시 유지보수가 없도록 처음부터 완벽하게 만드는 일은 불가능합니다. 주변을 한번 둘러보세요. 버그 패치를 위한 서비스 팩이나 기능 개선을 위한 업그레이드가 없는 소프트웨어가 있던가요? 특히 소프트웨어의 경우 초기 개발비보다 유지보수비가 훨씬 높은 경우가 대부분입니다. 따라서 적은 비용으로 빠른 기간 안에 유지보수가 가능해야 된다는 것은 좋은 소프트웨어의 덕목이 되어버렸습니다.

소프트웨어 개발의 필수 지식

강의할 때 늘 말로 설명하던 부분을 글로써 설명하려니 쉽지는 않네요. 그래도 SDLC가 무엇이고, 왜 필요한 것인지에 대한 내용은 대충 정리가 된 것 같습니다. 어떻게 보면 이번 호에서 다룬 내용들은 소프트웨어 개발과는 전혀 관계가 없는 이야기처럼 보일지도 모르겠습니다. 구체적인 소스 코드도 하나 없었고, 그렇다고 소프트웨어의 설계도라고 할만한 그림도 하나도 없었으니 말이죠.

하지만 이런 내용이야 말로 소프트웨어 개발을 목표로 하는 독자라면 반드시 이해하고 있어야 할 내용들이라는 것을 다시 한번 강조하고 싶습니다. 이번 호에서 다루었던 내용들이 소프트웨어 개발에 어떻게 직접적으로 적용되는지 궁금하지 않은가요? 다음 연재에서는 이번에 이야기한 분석과 설계라는 개념을 좀더 쉽게 소프트웨어 개발에 적용시켜 볼 수 있는 방법들을 구체적으로 소개해보도록 하겠습니다. @