학교에서 배운 소프트웨어 공학과 실제 회사에서의 개발환경의 거리감

실무에서 소프트웨어 공학은 왜 구체적으로 잘 쓰이지 못할까?

이 질문은 학교에서 배우는 소프트웨어 공학이 왜? 실제 업무에서 사용이 안되는가? 라고 바꾸어도 될것같다.

그동안 후배들에게 멘토링을 할 때에 가장 많이 받았던 질문 중의 하나인 이 질문에 대해서, 평소에 답변하던 것들을 글로 옮겨 본다.

소프트웨어를 전공하는 많은 후배들은 대학생활 4년 동안 배우는 다양한 이론들과 소프트웨어공학들의 수많은 이론을 배운다. 하지만. 대부분의 선배들은 사회생활의 실제 프로그래머로 취업을 한다고 해도, 프로그래밍을 실제 업무에서 하지만, 실제 관련된 이론과 기술. 수많은 가이드라인과 품질 관련 이슈에 대해서 실제 적용하기 어렵거나, 거의 사용하지 않는다고 선배들에게서 이야기를 듣는다.

물론, 이 경향은 많이 바뀐 것은 사실이다. 이제 대부분 공학적인 접근법을 사용한다. 하지만, 그럼에도 불구하고 실제 현장에서는 이 현상이 그다지 바뀌지는 않았다.

과연 우리가 학창 시절 배우는 그 많은 이론들은 도대체 왜? 만들어졌는데, 실제 사용이 안 되는 이유는 무엇인가? 학창 시절에는 자바나 C와 같은 프로그래밍 스킬만 높이면 되는 것인가? 도대체, 학생 시절 배우는 그 많은 이론과 공학, 품질 관련 이슈들은 실제 업무에서 그렇게 쓸모없는 것이라고 대부분의 선배들이 이야기하는가?

실전과 대한민국의 현실. 그리고. 소프트웨어 프로그래밍에 대해서 학생들에게 삽질의 대가가 한마디 하려 한다. 왜? 우리는 학교에서 배우는 이론을 실제 사용할 기회가 없는 것일까?

필자는 소프트웨어 공학을 학창 시절 배운 것이 아니다. 오히려, 실제 소프트웨어 개발 활동을 하면서, 공학적인 것이나 소프트웨어의 시각화를 해야만, 소프트웨어의 품질을 관리할 수 있다는 것을 몸으로 느끼고, 이것이 실제 소프트웨어를 상품이나 서비스의 명목으로 사용자들에게 제공하는 경우에 정말 필요하다는 것을 20년의 실제 개발자 생활을 하면서 그 필요성에 대해서 처절하게 느껴왔다.

차라리, 필자가 핵심 서비스와 중요한 개발 내용을 직접 코딩하는 개발자의 역할을 할 때에는 이러한 공학적인 것이나, 작은 규모의 소프트웨어를 개발할 때에는 이러한 필요성을 느끼지 못했었다. 대부분의 작은 규모의 소프트웨어를 개발할 때에는 단기적인 일들이 많았다.

사용자의 요구사항에 맞추어서 그 시기에 그때에 맞추어서 소프트웨어를 개발하였고, 해당 소프트웨어를 다시 유지 보수한다던가, 다시 수정 작업을 하지 않는 식의 작업을 하는 경우에는 이러한 공학적인 개념이나 그 배경으로 디자인하고 설계한다는 것에 대해서 매우 귀찮게 생각했었다.

과거 첫 경험이었던 코볼이나 클리퍼 시절에는 해당 소프트웨어의 규모가 크지도 않았으며, 데이터의 구조 설계 또한 대부분 파일 중심의 데이터였었고, 화면의 구조 또한 수십 개를 넘지 않는 정도의 규모였다.

오히려, 고속의 인덱스를 걸기 위한 테이블 접근법이나, 고속으로 화면에 출력하는 방법. 데이터를 조금 더 빠르게 구성하는 방법들에 집중할 시기에는 굳이 플로우 차트를 왜? 그리는 것이며, 파일 구조에 대해서 디자인해야 하는지에 대해서 의아함을 똑같이 가지고 있었으며, 굳이 설계나 디자인 없이 바로 코딩과 개발을 하던 시절이었다.

하지만, 대규모 시스템을 주로 구사하는 웹서비스의 시대에 있어서, 단순한 로그 정보하나를 시리얼라이즈화시키는 것만 봐도 그 사람의 수준을 파악할 수 있고, 텍스트 중심의 구성 설계를 보면 향후 시스템의 성능에 대해서도 예측이 되는 경험을 축적하게 되면, 가장 중요한 것은 역시... 공학적인 접근법이다.

필자가 소프트웨어 공학의 첫 번째 개념에 대해서 눈을 뜨고, 그 필요성을 절감하던 첫 번째가 바로, 고객에게 제공되는 소프트웨어가 지속적인 유지보수성을 가지기 시작할 때에 그 필요성을 처음으로 인지하기 시작하였다.

처음의 요구사항이 변화되면서 사용자의 업무 흐름이 소프트웨어의 구조와 데이터베이스의 구조를 계속 변화하여 나가고, 이러한 상황을 미리 설계된 자료를 통해서 예측하거나, 소프트웨어 아키텍처적인 관점으로 조금 더 세밀한 환경에 대해서 메모가 되어있고, 그 구성에 대해서 서술해두었다면, 상당히 고속 개발을 하고, 소프트웨어 품질을 향상시키는데 매우 중요한 첫 번째 개발 행위가 되었을 것이라고 느꼈었다.

또한, 개발자가 수십, 수백 명 단위로 소프트웨어의 설계가 대단위로 변화하고, 그 개발 품질에 대한 통제와, 적정한 수준의 개발 수준을 형성하게 하는 방법에 대해서 고민할 때에도 똑같이 이러한 소프트웨어 개발의 시각화에 대해서 인지하기 시작한 것이다.

당시에는 공학적인 개념 없이 유사한 방법이나 표현방법을 고안하였으나, 관련된 내용을 찾아보고, 전문가들에게 조언을 구해보니, 상당 부분 그 부분에 대해서 전문가들 간의 협의가 있었고, 그 표준화되는 시각화 방법들과 방법론들이 매우 많이 연구되었다는 것을 알게 되었다.

필자는 오히려, 이러한 개발과정에 있어서 필요한 것들을 개발하다가, 공학적인 베이스나 방법론들이 어떻게 실제 개발에 사용되어야 효과적인가에 대해서 실전에서 터득하고, 실전에 배치되는 것에 대해서 이해를 넓혔다.

또한, 미국에서 개발되어진 개발 방법론이 국내의 실정이나 환경에 적합하지 않은다는 것을 깨닫고, 그러한 부분들을 어떻게 지식을 바꾸어야 하며, 실제 실천해야 하는지에 대해서 아키텍트 포럼이나 모임에서 역설하기 시작하였고, 그 부분을 실제 개발에 접목하려 애써왔다.

그리고, 그 경험을 중심으로 소프트웨어 아키텍팅과 관련된 경험을 늘려왔고, 모바일과 웹서비스를 중심으로 하는 기업에서 개발 총괄을 하는 경우에는 그동안 축적한 소프트웨어 개발의 경험을 바탕으로 소프트웨어 형상관리 SCM(Software Configuration Management)을 중심으로 이슈관리, 개발, 테스트, 배포의 단계를 자동화하는 소프트웨어 개발의 비주얼라이제이션을 어떻게 실현할 것인가에 대해서 고민하고, 그 환경을 보다 쉽게 전파할 수 있는 공정과 형태를 미국 중심의 CMMI체계와 국내의 SP의 기준을 배경으로 상당 부분 고민하고 있다.

그런데, 가끔 만나는 후배들이나 이제 막 개발자의 생활을 시작하려는 친구들에게서 많이 받은 질문 중의 대표적인 질문이 ‘도대체, 학교에서 배우는 소프트웨어 공학은 언제 사용하나요?’, ‘도대체, 대학 4년 동안 배우는 그 많은 이론들은 언제쯤 사용할 수 있는 것일까요?라는 질문들을 그동안 수십 번, 수백 번 받아왔다.

심지어, 소프트웨어 개발 생활을 몇 년정도 한 후배들에게서 마저도 듣게 되니, 이 부분에 대해서 한 번쯤은 글로 남겨 두어야 하겠다고 생각하였다.

과거, ‘서울 행복 직업박람회’에서 질문받은 내용은 이러했다.

그 당시 필자에게 찾아온 대학생이 질문한 내용은 매우 간단하지만, 매우 어려운 답변일 수 있었다. 그것은, ‘왜 대학교 때 배우는 이론이나 원론과 같은 기본적인 내용들이 실제 사회생활 나가면 필요 없다고 자기의 선배들이 이야기하는 것일까요?. 실제. 취업하면 정말 그런가요?’

이 질문은 이번 이야기의 주제이며, 필자가 20년을 넘게 소프트웨어 개발자 생활을 하면서 받아온 질문 중에 가장 빈도수가 높은 질문이라고 하겠다. 필자가 자부해온 삽질의 대가라는 점에서 그 친구는 그 친구는 정말 그 이야기를 잘 해줄 사람을 찾아온 것이라고 생각하면서 다음과 같이 설명했다.

결과론적으로 '필요하지만, 필요없는 곳도 있다. 하지만, 가능한 필요한 곳을 찾아봐라.' 라는 식의 이야기를 해주었다.

자, 그렇다면. 필자가 이런 선문답 식의 답변을 하게 된 내용을 하나씩 풀어서 설명해보자. 도대체, 대한민국의 소프트웨어 개발을 하는 곳에서 왜? '소프트웨어 공학'적인 개념이나 이론들이 사용이 안되고 있는 것일까?

물론, 정답은 간단할 수 있다. 국내의 대부분의 소프트웨어 개발회사의 경우에는 소프트웨어 공학쯤은 없어도, 아무런 문제(?) 없이 소프트웨어 개발이 가능한 경우이다.

실제, 그런 회사도 그런 개발 조직도 상당히 많다는 것을 필자는 경험으로 알게 되었다. 그렇다면, 그렇게 소프트웨어 공학쯤은 필요 없는 기업이나 개발 조직은 어떤 곳들일까? 그곳들부터 알아보자.

개발 총괄 책임자의 대우가 형편없는 회사

필자는 개발자의 생활을 시작하는 어린 친구들이 첫 번째 직장을 가지는 곳에 대한 선택에 대해서 조언을 해왔을 때에 가장 먼저 해주는 조언은 이것이다. 면접을 보려는 회사의 개발 총괄 책임자나 리더에 대한 대우와 회사 내에서의 위치를 먼저 살펴보라는 것이다.

대부분 대우가 형편없거나, 매일 야근과 반복된 개발 일정의 반복이 계속되는 회사의 경우에는 그 대우가 형편없는 것 이상으로 개발의 공정이나 개발의 방법이 정형화되어있지 못할 가능성이 매우 높다.

물론, 소프트웨어 개발이 시각화가 되면, 요구사항의 변동폭이 보이게 되고, 해당 정량적인 지수가 도출되므로, 해당 부분에 대해서 대응이 가능하지만, 개발 총괄 책임자의 지위가 낮거나 대우가 형편없다는 이유는 다음의 두 가지의 경우에 해당이 된다.

하나. 공학적인 방법이나 정형화된 방법을 제안하는데, 회사의 최고책임자가 인정하지 않는 경우이다.

이 경우에는, 보통은. 제대로 알고 있는 소프트웨어 개발자들은 해당되는 조직을 빠르게 떠나고, 별로 기대할 수 없다는 것에 대해서 자괴감이나 패배감과 같은 분위기가 개발 조직 내에 흐른다는 것을 곧 감지할 수 있을 것이다.

둘. 실제 이러한 공학적인 방법 따위의 개발 방법론으로 통제할 수 없는 고객이 '슈퍼갑'인 경우이다.

실제, 소프트웨어 개발 활동을 해당 '슈퍼갑'에서 영업적인 능력으로 얻어낸 경우의 회사의 경우에는 아무리, 옳은 이야기, 옳은 방법론으로 대응한다고 해도, 개발 막판에 개발의 방향성 자체를 손 뒤집듯이 바꿔버리는 상황이 빈번한 경우이다.

대부분 이런 경우에는 소프트웨어 개발 총괄 책임자가 오히려, 공학적인 것을 알고 있거나, 똑똑한 사람이라면 멘붕에 빠지거나, 자괴감에 빠져서, 대충대충 소프트웨어 개발을 하거나, 자기가 먼저 자리를 뜨는 경우가 대부분이다. ( 버티는 사람은 몰라서 버틸 수 있다고 설명하는 것이 더 바람직하겠다. )

물론, 이 경우에도 그런 것을 당연시하면서, 공학적인 개념도 모르는 리더가 고객과 같이 동조하는 경우가 오히려, 업무가 수월해지는 경우가 많은 것 또한 현실이다. 고객과 개발 책임자가 같이 '닭짓'을 하는데, 개발 조직이 온전할 리 없다. 공학 따위는 집어치우고, 프로세스나 정량화된 목표, 자동화된 방법과 같은 소프트웨어 품질은 그냥, '책'에만 나오는 단어이며, 개념일 뿐이다.

실제, 똑똑하고 말 잘하고, 올바른 방향으로 이끄는 리더가 이 조직에 리더가 된다고 하더라도. 어쩔 수 없이, 버티지 못하고, 떠나게 되는 것을 흔히 보게 된다.

그리고, 이러한 조직에 있는 대부분의 개발자들은 '소프트웨어 공학'따위의 '장난'은 실제 개발이 필요 없다고 역설하고, 이것을 당연하게 여긴다. 보통, 이렇게 만들어지는 소프트웨어의 품질은 보장할 수 없고, 이 보장할 수 없는 소프트웨어를 통해서, '슈퍼갑'에서 꾸준한 유지보수 비용과 일거리가 발생하는 방법은.. 아마도, '4대 강'처럼. 한번 만들어 두면, 끊임없는 유지보수 업무를 발생시키는 식의 문제 정의와 처리방법이라고 할 수 있겠다.

당연한 것이지만, 결론적으로 이야기하자면, 이런 개발 조직에서 개발 총괄 책임자의 대우는 형편없고, 일정 조절이나 개발에 대해서 지휘할 수 있는 권리나 인사권 같은 것도 매우 부족한 상황으로 변화한다.

그래서, 이런 회사일 수록, 소프트웨어 공학은 그냥, 뜬구름 잡는 이야기가 되는 경우가 일상다반사이다.

실제, 소프트웨어 개발을 하지 않는 회사

소프트웨어 개발 조직이 있지만, 실제 소프트웨어는 개발하지 않고, 심지어. 소프트웨어 유지보수마저도 관련 업체에 일임하거나 위임하는 경우의 조직이 해당되는 경우이다. 대부분의 슈퍼갑인 회사와, 어설프게 소프트웨어를 개발하는 기업들의 전산실에 해당하는 곳이 이런 환경에 해당된다.

이 경우 소프트웨어의 공학적인 배경이나, 개발에 대한 스킬과 협조보다는, 일반 회사의 기획과 경영, 회계와 관리에 해당하는 업무들이 가장 중요하므로, 소프트웨어 개발의 시각화나 공정에 대해서는 그다지 관심이 없는 경우이다. 오히려, 제품을 선택하고, 유지보수 업체를 어떻게 관리하고 운용할 것이냐에 핵심과 초점이 있기 때문에, 소프트웨어 공학적인 배경은 가장 중요한 선택의 포인트가 되지 못한다.

오히려, 투입 대비 효과에 대한 경영학적인 관점의 스킬과 개념이 더욱더 중요하다고 하겠다. 필자는 개인적으로 대부분의 대학에서 이러한 관점으로 교육을 하지 않는 것에 대해서 매우 불만족스럽다.

분명, 소프트웨어 개발과 소프트웨어를 개발, 유지보수, 운영 및 관리한다는 것은 매우 연관성이 높기 때문에, 이와 관련된 과정이나 소통방법, 그리고. 윤리체계와 운영방법 등에 대해서도 충분하게 소프트웨어 관련학과에서 교육이 필요하다고 생각한다.

이러한 회사에 입사하게 되는 개발자의 경우에는 소프트웨어 개발자가 된다기 보다는, 소프트웨어 개발과 운영을 관리하는 회사를 관리하는 업무를 더욱더 많이 배우고 경험하게 되므로, 소프트웨어 개발공학 따위의 뜬구름 잡는 이야기는 경력이 쌓여갈수록 더더욱 필요 없게 된다.

사장이 직접 개발하는 소규모 개발회사

이러한 경우도 몇 가지의 사례로 나눌 수 있지만, 대부분의 구성 형태는 정말 비슷해지는 점이 매우 특이하다. 그것은, 소프트웨어 개발회사에 있어서 개발 총괄 책임을 '사장님'이 직접 통제를 하는 경우이고, 실제, 중요한 코딩도 '사장님'께서 직접 하는 경우이다.

이 경우에는 '소프트웨어 공학'적인 콘셉트보다는, '사장님'의 경험적인 바탕에 의해서 소프트웨어 개발의 시각화가 만들어지고, '사장님'의 지극히 개인적인 경험과 지식의 배 경위에서 '정량적'지수들이 결정되는 경우이다.

이 경우에는 '사장님'의 스킬이 높은 파트의 경우에는 매우 느슨할 수도, 매우 강하게 조일 수 있고, 사장님의 경험이 부족하거나 어색한 지식을 가진 파트의 경우에는 매우 불완전하고, 매번 변경된다는 것을 개발 조직 전체가 느낄 수 있다.

이러한 조직의 특성은 상당 부분 필요한 소프트웨어 품질을 유지하고 있기는 하지만, 특정 버그나 특정 형태, 특정 상황에 대해서는 포기하는 경우가 많다는 점이다. 또한, 개발 조직의 구성역시 특정한 방향으로 구성되어진 기형적인 개발 조직이 만들어진다는 것이다.

물론, 이 방향이 완전히 틀린 것이 아니라는 점 또한 매우 중요한다. 해당 업무나 설루션, 패키지에 적합한 방향에 대해서 '사장님'의 경험에 의해서 구축되었기 때문에, 특정 공학적인 지식을 가지고 있거나, 개발의 경험이 풍부한 사람이 해당 조직에 들어와서 보기에는 매우 어색한 점이나, 매우 이상한 형태를 느끼게 된다.

대부분 이러한 소프트웨어 개발 조직은 보통, 수년 이상 설루션이나 서비스를 진행해오고 있고, 특정한 형태로 발전되어 있고, 적당한 개발자들이나 서비스 운영조직과 내재화된 자체들의 경험들이 중첩되어 있어서, 정말 세밀하게 분석하고, 환경을 조절하기에는 정말 어려운 환경으로 진화된 경우가 많다.

대부분, 급여와 업무, 직원들의 잦은 이탈과 특정 개발 조직에 대한 '사장님'의 편애가 눈에 뜨일 정도로 보이는 경우가 많다. 그것은, 해당 소프트웨어와 서비스가 그 환경에 가장 적합한 구조를 가지고 있기 때문에 발생하는 경우이기 때문에, 냉정하게 분석해보면, 그 조직의 형태가 매우 적합한 구조인 경우가 많다.

그래서, 이러한 조직에 들어가는 경우에는 '이론적'인 소프트웨어 공학은 잠시 뒤로하고, '경험적으로 구축되어진 개발 프로세스'에 익숙해져야만 그 조직과 프로세스를 이해할 수 있게 된다. 이러한 회사의 경우에는 필요한 경험과 지식에 대해서 매우 제한적이기는 하지만, 나름대로의 규칙과 개발 철학, 향후. 발전방향에 대해서 어느 정도 구축하고, 이를 따라서 개발 조직을 운영하고 있다는 점이기 때문에, 어설픈 개발공학적인 개념으로 이러한 환경을 이해한다는 것은 매우 어려울 것이다.

초보 개발자들의 경우에는 이러한 개발 조직에서 수년 이상을 지내야만, 이러한 방법을 이해하는 경우가 대부분이다. 그래서, 초기에는 '공학'따위는 없다고 푸념하거나, 필요 없다고 이야기하는 경우이다.

소프트웨어 공학은 해당 개발 조직과 개발자들의 수준, 축적된 시각화 방법들을 종합화하여 보이는 활동이기 때문에, 이러한 개발 조직은 이러한 정착된 패턴에 대해서 한 번쯤은 시각화를 위한 종합진단과, 형태에 대해서 정립하고 자신들만의 개발 문화를 선언하는 방법을 택하는 것이 좋다. 그래서, 공학적인 방법에 대해서 고민하고, 품질에 대해서 조금은 더 발전적인 방법으로 진화할 수 있게 하는 방법이 될 것이다.

하여간, 잘 모르는 사람들에게는 이러한 개발 조직은 매우 이상하게 보인다. 단, 이 조건에 가장 적합한 회사의 경우는 '적당한 수익을 시장에서 얻고 있으며, 그 시장에 맞추어 개발 조직과 문화가 발전한 회사의 경우'를 의미하는 경우이다.

당연한 것이겠지만, 이러한 환경으로 '시장'에서는 버티기 매우 어려울 것이고, 곧 망할 가능성이 높은 경우이다. 물론, 영업적은 능력으로 개발 조직이나 회사가 운영되고 있다면, 자연스럽게, '개발 총괄 책임자의 대우가 형편없는 기업'으로 변화되기 때문이다.

특정 개발 조직이 관습화 된 인사권을 행사하는 경우

보통은 이러한 회사를 게임회사에서 잘 찾아볼 수 있다. 특정 서버의 기술이나 클라이언트의 개발팀에서 사람을 구인하는 데 있어서, 일반적인 구인의 방법보다는 인맥이나, 특정 방법에 의해서 인력을 수급하는 경우이다.

이 경우에 중요한 개발 공정이나 프로세스와 개발경험들은 내부의 팀에서 내부의 팀원들을 통해서만 서로 간에 운영되는 형태이며, 보통은 게임회사나 특정 하드웨어 기술을 가진 업체들에게서 이러한 환경들이 빈번하게 나타난다.

한편으로는 이러한 방법이 개발 조직 내에서의 테두리가 제한되기는 하지만, 어느 정도 회사가 성장하거나, 회사의 규모 이상이 되지 않는다면, 그렇게 문제가 되지 않는 경우가 된다. 필자의 경험에 의하면 매출 1조 원을 넘기는 기업이 되는 경우의 하드웨어 업체이거나, 매출 1천억을 넘기는 소프트웨어 기업의 경우에 이러한 개발 조직의 문화가 가장 큰 걸림돌이 되는 경우를 많이 보아왔다.

이런 경우에 대부분의 중심 개발 조직이 아닌 조직에서는 자신들이 공정을 변화시키거나 제품의 중요 기능을 다룰 수 없고, 반복적인 유지보수나 무의미한 행위들이 연속되는 경우를 계속 경험하게 되므로, 소프트웨어 공학에 대해서 많은 의아심을 가지게 되는 경우이다.

이상의 몇 가지 기업의 형태를 살펴보면서 필자가 알게 된 것은 소프트웨어 개발의 형식은 역시 무형식이며, 그 상황과 형태에 따라서 변화되고 진화한다는 것이다. 또한, 위에서 이야기한 몇 가지의 경우의 공통점은 바로, ‘소프트웨어의 품질’이 그다지 중요하지 않은 기업의 경우에 해당한다고 이야기할 수 있다.

위에서 언급한 회사들의 공통점은 ‘소프트웨어의 품질’ 때문에 개발 조직을 변화시키거나, 개발 문화에 대해서 고민할 필요가 없는 회사라는 점이다. 당연한 것이겠지만, 소프트웨어 공학은 ‘뜬구름 잡는 이야기’를 하는 학창 시절 때에나 이야기한다고 이야기를 하는 선배들을 대부분 만날 것이다.

대한민국에서 만날 수 있는 대부분의 소프트웨어 개발 활동들은 소프트웨어의 품질이 그다지 중요하지 않은 경우가 참 많다는 것이다.

일단, 가동을 시작한 서비스가 죽게 되면 크게 문제가 되는 경우이거나, 해당되는 소프트웨어가 작은 문제로 인해서, 실제 비즈니스와 업무에 크게 문제가 되는 경우가 아니라면, 소프트웨어의 품질에 대해서는 그 중요성이 떨어지게 되는 것이 당연하다.

충분한 소프트웨어 가치를 인정받을 수 있는 평가와 방향성에 대해서 충분하게 고민하고 있지 않은, 회사이거나 소프트웨어 개발 조직의 경우에는 당연한 것이겠지만, ‘소프트웨어 공학’은 그다지 중요하지 않다는 것이 결론이라고 하겠다.

소프트웨어 품질이 정말 필요한 곳인가?

이렇게 답변을 정의할 수 있다.

소프트웨어 품질이 중요한 가치를 가지는 곳에서는 충분하게 소프트웨어 공학적인 이론과 배경이 가장 중요한 것이 될 것이다. 필자가 아는 어느 회사의 경우에는 소프트웨어의 기본적인 행위하나 가 실제 큰 비용으로 계산되는 경우가 있었다.

단순한 하나의 물류이지만, 어떤 물류를 크레인을 사용하여 한 번 잘못 이동하게 되고, 해당되는 물품이 전혀 엉뚱한 나라에 가있거나, 해당 물품이 적재되고 내려지는 과정이 중첩되면서 만들어지는 비용을 단 한번 행위의 가치로 평가하였을 때에 1번 펑션이 1억 원 정도의 비용으로 계산되는 경우라면, 소프트웨어 개발의 펑션이나 개발 프로세스에 대해서 얼마나 고수준으로 설계하고 평가될 것인가에 대해서 생각해보면 될 것이다.

이미, 은행에서 자금이 이체되고, 움직이는 과정에 대해서도 개별적인 가치에 대해서 평가를 할 수 있을 것이다. 과연, 내가 만드는 소프트웨어의 기본가치는 어떻게 되는 것일까? 에 대해서 생각해보면, 우리가 만드는 소프트웨어에 얼마나 고품질이 필요한 것인가에 대해서 설명할 수 있을 것이다. 그렇지만, 필자는 이렇게 이야기하겠다.

슬프지만, 대한민국의 IT 중에서 소프트웨어 개발 분야에 있어서, 정말 고품질이나 고성능을 요하는 수준으로 요구하는 곳이 거의 없기 때문에 이러한 문제는 계속 발생할 것이며, 계속 이러한 질문은 만들어질 것이다.

대부분의 학생 시절에 우리가 배우는 기본과 이론들은 쉽게 설명해서 죽지 않는 서버와 데몬을 만들고, 가능한 정해진 규칙 하에서는 다운되지 않는 웹서비스를 만들려고 그런 기본과 이론을 배운다.

하지만, 대부분의 서비스들은 죽으면, 서버의 데몬 프로세스를 죽였다가, 다시 동작하면 되는 수준의 업무면 충분한 경우가 대부분이다. 더군다나, 외국에서 만들어진 프레임웍이나 만들어진 소프트웨어 위에서 동작되는 소프트웨어를 만드는 환경에서라면, 이러한 공학이나 이론 따위야 그다지 중요한 것이 아니게 될 것이 아니라는 점이다. ( 그 책임은 비싸게 구매한 DBMS나 프레임웍이 해결해야할 책임이라고 떠넘긴다. )

결론적으로 마지막 이야기를 한다면, 과연 이러한 소프트웨어 가치를 충분하게 만들어 낼 수 있는 소프트웨어 개발 활동을 내가 하고 있는가에 대해서 고민해보자. 그리고, 그러한 행위를 할 수 있고, 발전 가능성이 있는 곳이야말로, 이러한 고수준의 품질활동이 필요한 곳이 될 것이다.

그리고, 이러한 고수준의 소프트웨어 품질활동이 필요한 곳은, 바로. 아직은 단 한 번도 이러한 소프트웨어나 서비스가 만들어지지 않은 곳에서 이러한 활동이 더 많이 필요하다. 그것은 바로, 스타트업이나 이제 서비스를 개시하려는 곳일수록, 적절한 소프트웨어 품질활동이나 시각화가 필요하다고 이야기할 수 있겠다.

소프트웨어 활동을 시각화한다는 것은 결론적으로 소프트웨어 개발자가 투입하는 행위에 대한 가치에 대해서 얼마나 고수준으로 끌어올린 것이며, 어느 정도 적절한 품질 수준을 고려할 것인가에 대한 활동을 의미한다.

그러므로, 현재 스타트업을 꿈꾸고 있거나, 적적할 소프트웨어의 개발비용을 고민하고 있는 곳이라면, 소프트웨어 공학은 매우 중요한 활동이나 방향성에 대해서 정답에 근접하도록 도움을 줄 것이다. 소프트웨어 고품질의 세계와 소프트웨어 공학의 세계는 소프트웨어 개발자들이 어떤 생각을 하고, 개발에 참여하느냐에 따라서 결정되어진다. 그 선택은 역시, 각자가 하는 것이다.