태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

소프트웨어는 소프트하지 않다.

2008/12/30 15:27 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
소프트웨어는 손쉽게 수정할 수 있다고 생각하기 쉽습니다.
특히 고객이나 개발을 잘 이해하지 못하는 Sales part에서는 소프트웨어가 대단히 Soft해서 쉽게 주물떡 주물떡 해서 변경이 가능할 것으로 생각합니다.

하지만 무엇이 언제 수정되냐에 따라서 소프트웨어는 절대로 소프트하지 않습니다.
프로젝트 막바지에 요구사항이 변경되면 요구사항 분석 시 반영된 것에 비하여 수십배의 비용을 지불해야 합니다.

소프트웨어가 소프트하다고 생각하는 것은 비단 고객이나 Sales만이 아닙니다.
개발자들도 그런 생각을 하는 것을 종종 볼 수 있습니다.

개발자들은 자신이 뚝딱뚝딱 만들어 보고는 수정이 쉽다고 생각할 수 있습니다.
하지만 이는 간단한 프로토타입에 불과하고 실제 프로젝트나 제품을 만들 때는 사정이 달라집니다.
요구사항이 바뀌면 아키텍처가 바뀌어서 전체를 다 뜯어 고쳐야 할 수도 있습니다.

빌딩을 지을 때는 뼈대를 다 올리고 나서 이거 저거 뜯어 고쳐달라고 하지를 않습니다. 하지만 소프트웨어를 개발할 때는 다 개발해 놓고도, 부담없이 고쳐달라고 하는 경우가 비일비재합니다.

SW분리발주법이 이러한 부작용을 줄여 줄 수 있는 좋은 제도이나 아직 형식적인 가이드에만 그치고 있고 기업들은 얼마든지 이를 피해갈 준비가 되어 있습니다. 이렇게 후진적인 마인드가 결국 소프트웨어 업계를 공멸하게 만들어가고 있는데, 이 기형적인 소프트웨어 산업 구조는 쉽게 바뀌기가 어려운 상황입니다.

소프트웨어가 소프트하지 않다는 것을 우리 모두 인식할 때 조금씩 희망이 보이지 않을까요?

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/46 관련글 쓰기
  1. 2009/01/02 11:59
    소프트웨어는 소프트한가? Tracked from Intellectual Wanderlust
  2. 2009/01/29 09:18
    소프트웨어는 소프트한가 Tracked from 호랭이 블로그...
  1. SI만 했던 개발자들은 SM의 중요성을 잘 모르더군요.
    SI땐 금방 뜯어 고칠 수 있지만 SM 할땐 뭐 하나 수정할려면 쉽지 않죠.
    제대로 돌아 가고 있는걸 수정하기란 여간 꼼꼼해서 되지 않습니다. ^^;

  2. 묘재님 안녕하세요.
    SM은 Legacy System을 잘 이해하고 있어야 하니 더욱 수정이 어렵죠. 게다가 담당자가 여러번 바뀌고 문서도 충분하지 않으면 곤란한 상황이죠. 팩키지 소프트웨어나 대부분의 소프트웨어는 뒤늦은 스펙변경은 대단히 비싼 비용을 치뤄야 합니다.

  3. Blog Icon

    사진이 멋지네요 ^^

  4. ks님 안녕하세요. 반갑습니다.
    사진은 그냥 골라본 겁니다. :)

  5. 좋은 지적입니다. 가장 큰 문제는 그 요구사항 변경에 따른 비용을 단지 "개발자가 좀 고생하면 된다"라고 인식하는데 있는 것 같습니다. 그리고 수정이 잘 되지 않으면 "능력없는 개발자 탓"이 되는게 현실인것 같습니다.

  6. Jake님 안녕하세요.
    바로 그런 비전문적인, S/W개발에 대해서 이해하지 못하는 고객이 문제죠. 개발자는 이들을 이해시키는 역할도 해야 하지만, 고객도 요구사항에 대한 의무가 있는데, 이를 잘 모르는 것이 일반적입니다. 요구사항을 잘 분석해서 줘도 고객은 잘 읽어보지도 않는 것이 흔하죠. 읽는 방법도 잘 모르기도 합니다.

  7. 제 생각에는 고객은 충분히 그럴 수가 있다고 봅니다. 어차피 고객들은 비용을 지불하고 구매하는 사용자에 불과하니까요. 문제는 그러한 무리한 요구사항을 무리하다는 것을 알면서도 무조건 맞춰주는 개발회사가 더 문제라고 봅니다. 어떻게든 매출은 올려야겠으니 개발자만 좀 고생시켜 요구사항 맞춰주면 된다는 생각을 바꿔야 하지 않을까 싶습니다. 한 회사가 안된다고 했을 때 다른 회사가 된다는 회사가 있으면 고객은 당연히 된다는 회사와 거래를 하겠죠. 문제는 고객에게 변경이 어렵다는 것을 인식시키기 보다는 변경에 따른 비용을 인식시키는 것이 중요할 것 같습니다. 사실 소프트웨어가 하드웨어보다 변경이 쉽죠. 그래서 소프트웨어라고 불리는 것이구요. 그 비용인식은 소프트웨어 업계만의 문제가 아닌 사회 전반적인 문제가 아닌가도 생각합니다.

  8. Jake님 안녕하세요. 새해 복 많이 받으세요.
    그렇습니다. 현재의 현상은 시장의 원리에 의해서 형성된 것이지요. 그렇게 시장에만 맡겨 놓으면 문제이니 S/W관련된 법도 자꾸 만들어내고 있지만 또 피해가는 방법들을 만들어내지요.

    제대로 하려면 요구사항을 Fix하고 ATP(Acceptance Test Plan)을 만들어서 계약시 포함을 시켜야지요. 그리고 요구사항이 바뀌면 원칙적으로 계약이 변경되는 것이지요. 그렇게 하면 갑도 전문적이어야 하고 계약시 신경도 많이 써야 하거든요. 하지만 우리나라에는 언제든지 마음대로 할 수 있는 개발사가 많으니 그렇게 노력을 하려고 하지 않죠.

    소프트웨어가 확실히 Soft하죠. 하지만 너무 Soft하게 생각하는 것이 문제입니다. 이런 불합리한 인식을 모두 바꾸는 것은 단시간에 불가능하겠죠. 결국 제도적으로 문화적으로 조금씩 바꿔나가야 할 것 같습니다.

  9. 개발자 입장에서는 이런 생각을 가진 고객을 만나면 정말 괴롭죠. 하지만 그런 고객이 생각보다 많다는 점이 문제이기도 하죠. 고객과 개발자 모두의 인식변화도 중요하지만 보다 더 현실적인 제도적 뒷받침도 강화되야 할 듯 합니다.

  10. 필넷님 안녕하세요.
    여전히 어려운 문제죠. 법을 만들어도 피해가는 일이 허다하니... 그래도 분석능력이 뛰어난 개발사는 열악한 고객이라고 하더라고 그 안에서 최대한 효과적으로 분석을 해내곤 하지요. 무조건 고개 탓만 할 수는 없을 것 같습니다. 고객은 다 그러니까요. 분석역량을 키우는 일이 우리가 해야 할 일인 것 같습니다.

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..

우리 식대로
우리 식대로 2011/10/30

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다. 체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을..

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된..