며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다.
2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?
소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.
여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.
필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.
그 이유는 다음과 같은 것들이 있다.
2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?
소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.
여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.
필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.
그 이유는 다음과 같은 것들이 있다.
- 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다.
- 보통 에러처리와 약간의 버그는 무시한다.
- 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
- 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
- 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다.
보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.
제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.
그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다.
그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.
- 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
- 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
- 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
- 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
- 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.
스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다.
어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.
스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.
이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.
프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.
단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.
저는 프로토타입은 2가지 경우에 사용한다고 생각합니다.
답글삭제1.고객과의 의사소통용(UI가 주가되는 프로토타입)
2.기술검증용
1번의 경우야 말할것도 없이 요구분석이 끝나면 버려야 하는 것이죠.
2번의 경우는 기술검증이 실패하면 어차피 버려질 코드입니다.
물론 성공했을때에 코드를 정리하여야 하지만 프로토타입을 만들때 발생하는 실패리스크에 비하면 그렇다하게 큰 리스크라고 보기는 힘든것 같습니다.
물론 프로토타입을 만들면서 발생한 이슈나 기술에 대한 이해가 떨어지는 상태로 만든부분은 주석으로 표시를 해두는정도의 정성은 있어야 한다고 생각합니다.
이 포스트에서 지적하신대로 자신의 코드에 저도 집착 합니다 ㅎㅎ;;그래서 테스트는 했지만 스팩아웃된경우 따로 정리해놨다가 블로그에 올리곤 하죠.
최소한 다음번에 같은 검증을 하지 않아도 되게 정리해두는것도 좋은 생각인것 같습니다.
안녕하세요. 당근천국님
답글삭제여기서 UI프로토타입은 전혀 언급하지 않았습니다. ^^ 별이슈가 없거든요.
현재 프로젝트의 특성이나 조직의 상황을 고려하여 가장 적절한 방법을 택하신 것으로 이해가 됩니다. ^^
좋은 글 잘 보았습니다. 저도 SW 분야에서 근무한지가 두자리 숫자를 좀 넘어가면서
답글삭제쓰신 내용에 대해서 감성적으로, 이성적으로 공감을 하는데요....
국내 현실은 너무나 무지한 것 같습니다. 모든 프로젝트가 그렇지만 일정, 리소스가 부족한데
비해 '우아한' 행위 - 불필요한 임원보고, 언론플레이용 데몬스트레이션 등 - 에다가 정작 개발하고자
하는 서비스/제품은 말도 안되고 유저 입장에서는 뭥미할만한 것인데 기획/UI는 수시로 변경하면서
실제 개발에 드는 시간은 쉽게 잡아먹고 마는 현실이....--;;
프로토타입을 대함에 있어서 고객은 '프로토타입'과 '실제 제품'의 차이를 인지하지 못하는 경우가
허다하다고 봅니다. 저도 수없이 많이 겪어봐서 사실...좀 회의적이긴 한데요...프로토타입을 통한
기술 혹은 시제품 정도의 검증으로 인식하게 하려면 어떤 방법이 있을까요?
일하면서 성격이 시니컬하게 변하는 걸 느끼고 있어서....희망적인 뭔가가 있기를 기대하면서
살고 있습니다.
항상 좋은 글 감사합니다.
안녕하세요.
답글삭제그래서 소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것이 스펙을 쓰는 겁니다. 즉 분석이 어렵다는 얘기죠.
UI프로토타입의 경우 그럴듯한 화면을 보여주면 개발이 거의 된 것으로 착각하는 경우가 있습니다. 그래서 몇몇 UI프로토타입 툴들은 진짜 프로토타입처럼 찌글찌글하게 보여주는 것들이 있습니다. 딱 단순히 프로토타입인것을 알게 됩니다.
마인드를 바꿔야 하는데 다른 사람의 생각을 바꾸는 것이 쉽지는 않죠.
제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 사서 읽어보라고 해보세요. 여기에 관련된 거의 모든 내용이 이해하기 쉽게 정리되어 있습니다.
버리지 못 할 것 같으면 실용주의 프로그래머에 나왔던 예광탄 방식을 활용해볼 수도 있습니다.
답글삭제