SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?

소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 

그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까?

남이 작성한 SRS를 보면 도움이 될까? 

가상으로 한번 써보면 도움이 될까? 

케이스별로 얼마나 도움이 될지 알아보자.

1%

스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까?

1%정도 밖에 도움이 안된다.

남이 치는 피아노, 골프를 보고 얼마나 도움이 될지 생각해보면 된다. 작성한 SRS의 내용이 그러게 도출되는 과정을 겪지 않고 결과만 보는 것은 1%밖에 보이지 않는다.

10%

그럼 실제 프로젝트에 적용하기는 어려우니 가상의 프로젝트를 생각해서 작성하면 어떻게 될까? 10% 정도는 도움이 될 수 있다. SRS에 포함된 수많은 내용 중에는 실제 상황이 아니면 도저히 생각해 낼 수 없는 부분들이 많다. 이런 부분은 가상의 프로젝트에서는 배우기 어렵다.

30%

이미 끝난 프로젝트의 SRS를 적어보는 것은 어떨까? 나중에 혹시 유지보수에 도움이 되지 않을까? 별 도움이 되지 않는다. 

SRS는 원래 개발하기 전에 개발을 빠르게 하기 위해서 적는 것이다. 이미 종료된 프로젝트라면 적을 수 없는 부분이 많다. 또한 꼼꼼하게 적지도 않게 된다. 미리 적는 SRS처럼은 절대로 적을 수가 없다.

이미 코딩까지 끝났기 때문에 창의적인 생각이 필요한 Interface 등은 제대로 적기 어렵다. 현재 상태를 Reverse Engineering으로 적는다고 해도 깨끗하게 적을 수 없을 뿐더러 뒤죽박죽이라서 적어봐야 아무 의미 없는 경우가 대부분이다. 또는 SRS를 작성하면서 필요한 커뮤니케이션 스킬, 분석 능력, 인터뷰 능력 등은 전혀 익힐 수가 없다. 이러한 것을 빼고 내용만 일부 Dump하는 것은 Template을 익히는 것밖에 기대하기 어렵다.

100%

SRS 작성하는 법, 스펙을 작성하는 법, 요구사항을 분석하는 법을 제대로 배우려면 크던, 작던 실제 프로젝트에서 SRS를 적어봐야 한다. 어떠한 프로젝트도 SRS의 모든 챕터를 다 커버하는 것은 없다. 따라서 하나의 프로젝트에서의 경험은 상당히 제한적이다. 오랜 기간동안 여러 프로젝트의 SRS를 작성해봐야 배울 수 있다.

따라서 일단 실제 프로젝트에서 작성해보는 것이 가장 좋은 방법이다. 물론 피아노를 코치없이 배울 수 없듯이 경험이 많은 선배나 전문가의 도움을 받는 것은 꼭 필요하다.

넣는 것 보다 빼는 것이 더 어렵다.

초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.

성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.

고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.

이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.

기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.

이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.

기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다.

하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.

스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.

그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.

1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.

소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다.

소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다

하지만 우리나라에서 "요구사항분석" 역량을 제대로 갖춘 개발자를 만나보는 것은 매우 어렵습니다. "요구사항분석"은 교과서를 통해서 배울 수 없고 실전을 통해서 익혀야 하는데 우리나라는 자수성가한 개발자들로부터 시작되고 이어져 왔기 때문에 이를 가르쳐 줄 수가 없었습니다. 대기업에서는 대규모 방법론이나 비싼 툴을 사용하여 "요구사항분석"을 해보려고 하는데 아무리 비싼 골프채가 있어도 골프를 잘치는 것은 딴 얘기이듯이 툴이 이것을 해결해주지는 않습니다.

결국은 요구사항분석의 핵심을 꺠닫고 꾸준히 현실 프로젝트에서 경험을 쌓아가는 것이 유일한 방법입니다. 그래서 그 실전적인 방법을 공유하고자 세미나를 개최합니다. 많은 성원 부탁합니다. 

시간과 장소는 아래 URL 참조하세요. 

http://projectresearch.co.kr/2013/03/11/대한민국-개발자들이여-깨어나라-올바른-sw-개발-방법/

참석하실 분들 댓글 달아주시고, 여기(http://onoffmix.com/event/13214)로 신청하시면 됩니다.

소프트웨어 개발시 일을 작게 쪼개야 하는 이유

대부분의 소프트웨어는 수명에서 수백명, 많게는 수천명이 같이 개발한다. 그래서 효과적으로 일을 나눠서 개발할 수 있어야 한다. 심지어는 혼자서 개발을 할 때도 일을 쪼개야 한다. 

왜 일은 쪼개야 하고 어떻게 쪼개야 하는것일까? 대부분의 다른 산업 분야는 일을 잘 쪼깬다. 시계하나를 개발해도 각 부품을 따로 개발해서 조립한다. 따로 개발하기 전에 이미 어떻게 연결이 되는지 인터페이스를 완벽하게 정의하고 개발한다. 그렇지 않으며 나중에 조립이 안되서 처음부터 다시 개발해야 할 수도 있다.

소프트웨어 프로젝트에서 일을 서로 어떻게 나눠서 개발을 하고 있는지 생각해보자. 

흔히 사용하는 방법이 화면 단위로 일을 나누는 것이다. 이 방법은 일을 나누기는 쉬워보이지만 문제가 많다. 나눠서 한 일이 서로 통합이 잘 안되고, 서로 중복된 개발도 많이 하게 된다. 다 개발해 놓고 서로 맞추는데 많은 시간을 소모하곤 한다.

일을 효과적으로 쪼개는 방법은 프로그램을 컴포넌트 단위로 잘 쪼개는 것이다. 컴포넌트는 특정 일을 담당하는 모듈로서 Class일 수도 있고, Class의 집합일 수도 있고, 함수의 집합일 수도 있다. 형태는 별로 중요하지 않다. 중요한 것은 컴포넌트의 외부 인터페이스가 간단하고 명료하게 잘 정의가 되면 되는 것이다.

분석/설계 과정에서 컴포넌트의 인터페이스가 잘 정의되면 많은 개발자들이 일을 나눠서 할 수 있게 된다. 10명이 개발을 하다가 시간이 부족하여 5명을 추가로 더 투입해도 큰 문제없이 개발이 가능하다.

서로 의존성이 있는 모듈들을 동시에 개발할 수 있게 된다. 특정 컴포넌트의 개발이 완료되어야 동작하는 모듈도 인터페이스가 확정되어 있으면 미리 개발을 할 수 있다. 개발 기간이 단축되는 것이다. 물론 모든 모듈이 다 개발되어야 테스트가 가능하지만 구현은 미리 해 놓을 수 있다.

또, 일부 모듈은 외주를 주는 것도 가능해진다.

이렇게 소프트웨어를 컴포넌트로 잘 나누게 되면 그 과정에서 문서화가 되고 서로 리뷰를 통해서 문제점을 발견하고 가장 뛰어난 아키텍처를 만들 수 있다. 또한 작업의 단위가 작아야 일정을 충분히 예측할 수 있다.

코딩을 시작하기 전에 이미 문서를 통해서 검증이 되고 공유가 된다. 그래야 변경이 최소화되고 가장 빠르게 소프트웨어를 개발할 수 있다.

분석 과정에서 부터 이미 주요 컴포넌트를 나누는 작업이 시작되고 외부 인터페이스를 정의하게 된다. 설계의 정도는 프로젝트마다 매우 다르지만 컴포넌트를 좀더 작게 나누고 function prototype까지 정의를 하면 설계가 완성된다. 간단한 프로젝트인 경우에는 스펙에서 정의한 컴포넌트와 인터페이스만 가지고 별도의 자세한 설계 없이 구현이 가능하다.

이렇게 일을 쪼개는 이유는 소프트웨어를 가장 빨리 개발하기 위한 것이다. 그렇지 않고 그냥 대충 일을 나눠서 서로 뭉쳐서 긴밀하게 의논해가면서 개발을 하는 것이 더 빨라 보인다고 생각하는 사람들이 매우 많다. 이 방법은 초기에 빠른 결과물을 보여주어서 초반에는 빨라 보이지만 결국 통합에서 지연되고 많은 재작업으로 시간을 소비하고 버그를 더 많이 만들어내어서 또 지연된다.

당장 코딩부터 시작하기 보다 생각을 더 많이 해서 컴포넌트를 잘 나눠 일을 쪼개서 재작업을 최소화하고 한번에 구현을 해 내는 것이 소프트웨어를 개발하는 가장 빠른 방법이다.

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.

1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.

위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."

위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.

99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.

스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.

1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구

이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.

프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.

변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.

변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.

변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.

이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.

또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.

스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 

스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.

개발자의 취향

소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다.

이 경우 Architecture상의 심각한 문제점을 내포하게 된다.

제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다.

Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 

이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.

그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에 심각한 문제를 초래하기도 한다.

그럼 어떻게 하면 이런 잘못된 결정을 막을 수 있을까? 답은 의외로 간단하다. 분석을 제대로 하는 것이다. 제대로된 스펙문서에는 최종 결론 뿐만 아니라 그런 결정에 이르게 된 근거와 의논 과정도 적어야 한다. 그래야 스펙을 읽는 사람들이 의문가 이의를 제기하지 않는다.

예를 들면 다음과 같은 것들이 있다.

• 현재는 Windows만 지원하지만 3년안에 Mac을 지원할 가능성이 90%라서 엔진은 ANSI-C로 개발을 하고 UI를 QT Framework를 이용한다.
• Java와 C로 모두 개발이 가능하고, 프로젝트 리더가 C언어를 더 좋아하지만, 기존 제품들이  Java로 되어 있고 회사에 Java개발자가 대부분이므로 Java를 선택한다.
• 회사에 자연어 처리 전문가가 있지만 자연어 처리 엔진의 직접 개발 비용과 상용라이브러리를 구매했을 때를 비교했다. 10년 후까지의 유지보수 비용을 고려하여 자체 개발보다는 상용라이브러리 구매를 선택했다.
• 현재 프로젝트는 아이폰/아이패드 용으로만 계획을 세웠지만, 영업부서와 논의결과 안드로이드를 지원할 가능성이 있어서 제품의 난이도가 그렇게 높지 않아서 Adobe Air를 사용하기로 했다.

이러한 결정 과정은 프로젝트를 진행하면 수십가지 또는 수백 번 진행이 된다. 스펙문서에는 이러한 결정과정까지 적어야 정확한 내용이 된다. 또한 중간에 상황이 변경되면 신속하게 영향평가를 할 수 있고 스펙을 변경할 수 있다.

소프트웨어 프로젝트는 개발자의 취향대로 진행되는 것이고 합리적인 근거를 바탕으로한 Architecture 결정에 따라 진행되어야 한다.

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

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

스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것을 판에 박힌 절차라고 생각하고 부정하기도 한다. 그런 주장을 하는 사람들은 이 방법은 Waterfall 방식으로 구닥다리이며 요즘은 Agile 등의 최신 방법으로 개발을 하기 때문에 과거처럼 스펙을 작성하지 않는다고 한다.

이렇게 주장하는 사람들에게 반문해보고 싶은 것이 있다.

"스펙을 한번이라도 제대로 작성해 본적이 있는가?" 

이런 생각을 하는 것 자체가 스펙을 제대로 이해하고 있지 못하다는 반증이다.

왜냐하면 스펙이 무엇인지 제대로 이해하고 있다면 이런 말이 나올 수가 없다.

지금 그렇게 부정하는 스펙을 작성하지 않아서 개발을 잘하고 있는가? 

99% 이상의 개발자는 죽을 때까지 제대로 된 Waterfall 방식의 개발을 한번도 해볼 기회가 없다. 그러면서도 과거에 Waterfall 방식으로 개발을 했다고 착각을 하는 것이다. Waterfall 방식을 참고하여 약간 응용을 한 것 뿐이다.

Waterfall 방식이 다른 모든 SW 개발 Lifecycle의 모델이 되는 이유는 소프트웨어는 나중에 고치기가 정말로 어렵기 때문이다. 빌딩 올리는 것과 별 차이가 없다. 즉, 코딩을 다 해놓은 다음에 설계나 스펙을 바꾸는 것은 10배, 100배 비용이 많이 드는 것이다. 아무리 최신 기술을 적용해도 이는 별로 나아지지 않는다.

따라서 그중에서 가장 앞단에 있는 스펙이 가장 중요한 것이다.

스펙을 작성하는데 있어서 가장 중요한 것은 필요한 만큼 적절하게 적는 것이다. 단계 별로 작성할 수도 있고, Unit test로 작성할 수도 있고 방법의 선택은 자유이다. 가장 효과적인 방법을 선택하면 그만인 것이다.

문제는 적는 방법이 아니고 그 내용이다. 대부분 스펙을 작성하지 못하고 어려워하고 반대하는 사람들의 공통점은 스펙에 무엇을 적는지 모른다는 것이다. 그렇기 때문에 아무리 잘 적으려고 해도 잘 안되는 것이다. 정리를 잘하고 예쁘게 적는 것은 추후 문제이다.

실제로 필자는 여러 회사의 다양한 프로젝트의 스펙(SRS)를 대신 적어준 경험이 있다. 해당 분야의 Domain 지식이 부족한 나는 해당 분야의 전문가들을 인터뷰하고 의논해가면서 스펙을 적는다. 대부분은 Domain 지식에 대해서는 훤하지만 스펙에 어떻게 적어야 하는지 모르고 있다. 즉, 지식은 있지만 스펙은 모르는 것이다. 스펙을 적는 방법에 대해서 구체적으로 적는 방법을 얘기하면 책 몇권도 모자르기 때문에 여기서 다 적을 수는 없다.

한마디로 요약하면 적어 놓은 스펙을 보고 설계/구현이 가능해야 하는 것이다.

조금만 더 설명하면 시스템을 기능, UI, Architecture의 뷰로 설명하고 비즈니스 요구사항, 비기능 요구사항 등을 포함해야 한다. 

스펙을 제대로 작성하는다는 것은 수십/수백페이지에 달하는 Template를 채우는 작업이 아니다. 어떤 SW를 만드는 것인지 정의 하는 것이다. 방법은 여러가지고 있고 그중에서 가장 효과적인 것을 선택하는 것이다. 

이것을 부정한다면 무엇을 만들지도 모르는 상태에서 무조건 코딩부터 시작하는 것이 가장 좋은 방법이라고 주장하는 것과 다를 바가 없다. 

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

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다.

2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?

소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.

여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.

필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.

그 이유는 다음과 같은 것들이 있다.

• 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다. 
• 보통 에러처리와 약간의 버그는 무시한다.
• 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
• 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
• 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다. 

따라서 재사용 가능하도록 만든다면 낭비가 될 수 있다.
보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.

제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.

그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다. 

그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.

• 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
• 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
• 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
• 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
• 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.

 사실 아주 작은 제품이나 소수의 팀이 개발하는 제품이 아니라면 위의 모든 것을 가정하기는 대단히 어렵다.

스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다. 

어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.

스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.

이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.

프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.

단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.

프로토타입이란?

프로토타입 (경제/경영)

양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다.

by 다음 백과사전 (http://100.daum.net)

소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다. 

이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다.
스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 경우가 있다. 스펙이 이렇게 불분명한 부분이 가득하다면 십중팔구 프로젝트는 산으로 갈 것이다.
그래서 스펙을 쓰면서 나중에 코딩에 들어가기 전에 미리 한번 만들어보는 것이다. 이렇게 만드는 프로토타입은 되는지 안되는지만 검증을 하는 것이므로 최대한 간단하게 만든다.

회사의 코딩 규칙을 따르지도 않고
에러 처리도 제대로 하지 않고
주석도 달 필요가 없다.

제대로 개발하려면 1주일 이상 걸릴 것도 몇시간에 걸쳐서 되는지만 확인해보는 것이다.
그렇기 때문에 이때 작성한 소스코드는 버리는 것이다. 절대 재활용하면 안된다. 규칙도 따르지 않고 에러처리도 안되고 주석도 없는 코드를 재활용하는 것은 대단히 불안한 일이다.

이렇게 검증을 해나가면서 스펙을 적으면 프로젝트가 계획된 시간에 끝날 가능성이 점점 높아지게 된다.

그렇다고 모든 내용을 다 검증해가면서 스펙을 적을 수는 없다. 어떤 항목은 된다는 감을 믿고 그냥 적어야 할 때도 있다. 모든 것을 다 검증하면 비용과 시간이 너무 많이 들기 때문이다. 따라서 검증할 것을 적당히 조율하면서 어느정도 Risk도 감수를 하면서 프로젝트를 진행해야 한다. 이때 발생한 Risk는 별도의 Risk 관리를 통해서 제어를 해야 한다.

프로젝트는 "해봤더니 안되더라"가 아니다.
그렇다고 모든 것을 검증하면서 할 수는 더욱 없다.
적절한 프로토타입을 통한 검증과 적절한 Risk관리를 병행하는 것이 가장 효율적이다.

스펙에 있어서는 안될 표현들

필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다.

스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다.

사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다. 비즈니스 관련된 부분은 예외이다.

그럼 스펙을 작성할 때 피해야 할 표현들에는 어떤 것이 있나 알아보자.

SMTP를 지원해야 하다.
지원한다는 말은 대단히 모호한 표현이다.  지원해야 하는 범위를 아주 구체적으로 기술해야 한다.

1~5의 값을 가진다.
1,2,3,4,5인지? 1,3,5인지? 1~5의 float값인지? 그 정밀도와 가질 수 있는 값을 정확하게 기술해야 한다.

데이터를 효율적으로 저장해야 한다.
효율적이라는 표현은 모호한 단어로서 피해야 한다. 메모리나 CPU 자원 대비 효율적인지,  Storage 용량을 적게 차지해야 하는지, 성능이 중요한지 구체적으로 적어야 한다. 또한 정확하게 요구되는 수준을 수치로 표시하는 것이 좋다.

사과, 배, 복숭아 등등을 지원해야 한다.
등등은 사용해서는 안된다. 지원해야 하는 모든 항목을 다 나열해야 한다.

기존의 값과 동일하다.
기존이 무엇인지 구체적으로 명시를 하고 해당 문서가 있으면 Link를 걸어줘야 한다.

충분한 메모리를 할당해야 한다.
충분하다는 것이 정확하게 얼마인지를 명시해야 한다.

사용자에게 친숙한 화면을 제공해야 한다.
어떠한 사용자가 친숙함을 느끼기 위해서 제공해야 하는 정확한 요구를 구체적으로 설명해야 한다.

일반적인 조건을 모두 만족해야 한다.
일반적인 조건을 구체적으로 기술해야 한다. 또한 일반적이지 않은 상황에서 시스템이 어떻게 되는지도 설명이 되어야 한다.

필요한 경우 메모리를 추가로 할당한다.
필요한 경우를 정확하게 판단할 수 있는 조건을 구체적으로 설명해야 한다. 수치가 나오면 좋다.

이외에도 수많은 표현들이 있다. 개발자라면 적어도 개발문서에서 이런 표현들이 나오지 않도록 항상 조심하는 습관을 갖는 것이 좋겠다. 이것도 하루아침에 이뤄지지 않는다.

개발문서를 만들기는 했는데 업데이트가 안되는 이유

필자는 여러 소프트웨어 회사들의 컨설팅을 진행하면서 먼저 회사의 분석을 위해서 그 동안 소프트웨어를 개발하면서 만들어 놓은 문서를 요구합니다. 사실 문서만 봐도 회사의 개발현황을 대부분 알 수 있습니다.

그런데, 제대로 작성된 문서를 제시하는 회사는 거의 없다시피 합니다. 물론 Wiki나 Google Docs등의 온라인 문서를 포함해서 제대로 작성된 문서는 거의 없습니다. 가끔 문서를 제시하는 회사들이 있기는 하나 수년간 전혀 업데이트를 하지 않아서 쓸모가 없어진 것들 뿐입니다. 

정리를 해보면 다음과 같습니다. 

• 문서가 아예 없거나 없다시피 한 회사
• 몇 년동안 업데이트 안된 문서들만 있는 회사 (오늘의 주제)
• 쓸모없는 문서들을 너무 많이 만든 회사 

야심차게 문서 한번 잘 만들어보겠다고 결심하고 개발 시에 문서를 열심히 만든 후에 소프트웨어는 계속 업그레이드가 되는데 문서는 과거에 머물러 있는 경우에 대해서 얘기를 해보겠습니다.

이런 문서는 죽은 문서입니다.

내용이 맞는지 틀리는지 확인이 안되는 문서는 혼동을 일으킬 수 있습니다.

이런 일이 발생하는 이유는 여러 가지가 있지만 대표적인 이유로는 진짜 문서가 필요해서 만들었다기 보다는 문서가 필요하다고 하니까, 또는 위해서 시켜서 만들었는데, 막상 개발에 크게 도움이 안되고, 단순히 문서를 만들었다는데 의의를 두는 경우가 있습니다. 또, 문서를 너무 잘(많이) 만들어서 소프트웨어가 업그레이드 될 때마다 문서를 갱신하려고 하니 초기 개발 때에 비하여 유지보수 시는 급하게 개발하는 요청이 많아서 미처 문서까지 갱신할 시간이 없는 경우도 있습니다.

이런 경우 모두다 "문서를 위한 문서"인 경우입니다.

문서가 진짜 필요해서 만든 경우가 아니라는 얘기입니다. 역량이 충분히 성숙되기 전에 문서 작성 문화를 정착하려면 어떻게 해야 할까요?

문서를 적게 만들어야 합니다. 

적게 만들면서도 개발에 유용해야 합니다. 그래야 문서를 만드는 일이 프로젝트에 큰 부담이 되지 않고, 추후 업데이트가 가능해집니다.

오래 되어서 쓸모 없어진 문서를 책꽂이에 잔뜩 꽂아 놓고 "옛날에는 문서를 열심히 만들었는데"하고 회상 하십니까? 지금은 그렇게 하고 있지 않다면 효과적이지 않은 방법으로 문서를 만들면서 조직 내에 정착되지 못한 겁니다. 문서 작성을 문화로 정착하려면 "작고 효율적으로 문서 만드는 법"을 익혀야 합니다.

왠만한 크기의 프로젝트도 문서는 한 두 개로 충분합니다. 스펙문서(SRS)와 경우에 따라서 설계문서 정도를 만들면 됩니다. 스펙문서는 요구사항을 분석하는 방법, 꼭 필요한 내용을 적는 방법, 리뷰하는 방법 등을 익혀야 합니다. 요즘은 스펙을 적는 방법에 있어서 다양한 시도들을 하고 있지만, 방법은 조금씩 달라도 꼭 필요한 내용을 빠짐없이 효과적으로 적어야 합니다.

SRS에 대한 인식의 변화

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데
2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요.
2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can
2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면
2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점
2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?
2009/01/29 - [소프트웨어이야기] - Head First Software Development 리뷰
2009/01/21 - [프로젝트/요구사항분석] - UI Mock-up
2009/01/20 - [프로젝트/요구사항분석] - 샘플만 보여주세요.
2009/01/19 - [프로젝트/요구사항분석] - 그냥 쓸 수 있겠네요.
2008/11/19 - [프로젝트/요구사항분석] - SRS(Software Requirements Specification)의 중요성2008/11/03 - [소프트웨어이야기] - 프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.

이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다. 

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다. 

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.  

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.

그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

이건 기능이 아닌데

의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.

소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.

하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 

이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.

첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.

둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.

셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.

그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.

딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.

기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?

그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.

비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.

고객이 요구사항을 너무 자주 바꿔요.

우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

Track me, if you can

"요구사항 추적"이라는 말을 들어 보셨을 겁니다.

요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다.

왠지 근사해 보입니다.

실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다.

요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 

요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 우주선을 만들 때나 사용하면 됩니다. 이 경우는 감히 비용대비 효과를 논하기가 어려우니까요.

우리가 접하는 대부분의 소프트웨어는 요구사항 추적이 필요 없습니다. 실제로 요구사항 추적이 대단히 어려울 뿐만 아니라 요구사항 추적을 해서 얻는 것이 별로 없습니다. 요구사항 추적을 해보신 분들은 아시겠지만, 실제로 어설픈 문서라도 만들어 놓고 써본 적도 별로 없을 겁니다. 또, 요구사항이나 컴포넌트가 변경이 되어도 요구사항 추적 문서를 갱신하는 것은 대단히 어렵습니다. 오히려 방해 요소가 됩니다.

대부분의 소프트웨어는 요구사항 추적을 하지 않아도 별 문제없을 만큼 작거나 테스트로 충분히 커버가 됩니다.

단 하나, 고객이 요구사항 추적 문서를 꼭 원할 경우 설득을 해보고 안되면, 엉터리 문서라도 만들어 주는 것이 좋겠죠. 이때는 어차피 요구사항 추적 문서를 활용하기 위한 것이 아니니 최소한으로 간단하게 만드는 것이 좋을 겁니다.

이렇게 문서를 꼭 만들어야 하는 상황이 아니라면 근사해 보인다고 괜히 요구사항을 추적해볼 필요는 없습니다. 추적한다고 추적이 되는 것이 아니니까요. 그런 노력을 테스트를 제대로 하는데 들이는 것이 훨씬 더 효율적입니다.

개발자들이 바글바글한 외딴섬에 떨어진다면

개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?

UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 

즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.

정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.

요구사항 분석의 출발점

소프트웨어 개발에 있어서 요구사항 분석이 가장 중요하다는 것은 앞에서도 이미 주지한 사실입니다.

2008/11/19 SRS(Software Requirements Specification)의 중요성

2009/02/04 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?

요구사항 분석의 산출물은 SRS, 요구사항분석서 또는 다양한 방법론에 의해서 다른 문서들이 나올 수 있겠죠. 그럼 요구사항분석의 출발은 무엇일까요? 어떤 기능을 제공하기를 원하나 조사하는 것일까요?

"왜 이 프로젝트를 하려고 하는가?"입니다.

프로젝트를 하는 목적과 목표를 알아야 모든 요구사항이 일관성을 갖게 됩니다.

이걸 누구나 다 알고 있다고요?

제 경험에 의하면 그렇지 않습니다. 프로젝트 구성원에게 각각 물어보면 프로젝트의 목적에 대해서 서로 다른 얘기를 합니다. 프로젝트의 목적이 공유가 안되어 있거나 심지어는 심각하게 고민도 해보지 않은 경우 입니다. 그렇다면 프로젝트는 산으로 가는 경우가 많습니다. 수많은 의견 충돌 시 프로젝트의 목적에 맞게 합리적인 결정이 이루어지지 않습니다.

지금 프로젝트를 하고 있다면 프로젝트의 목적이 정확하게 공유되고 같은 생각을 하고 있는지 확인해보세요.

개발자끼리가 아닙니다. 개발자, PM, PL, QA, 영업, 마케터 등 프로젝트 관련자 모든 사람이 같은 프로젝트 목적을 공유하고 있는지 입니다.

그럼, 서로 팀워크가 착착 맞아서 눈빛만 보면 서로 다 안다고 하면 서로 같은 생각을 할까요? 이런 경우에도 프로젝트 목적이 뭔지 명확하게 정의해서 공유하지 않으면 각기 다른 생각을 하는 일은 매우 흔합니다. 요구사항 분석 산출물의 맨 앞에는 프로젝트 목적을 명쾌하게 정리해서 모두 공유할 수 있도록 해야 합니다. 물론 모든 관련자가 동의를 하는 내용이어야 합니다.

프로젝트를 시작하면 왜 이 프로젝트를 하는지 명확하게 알아내고, 정의하고, 공유해야 합니다.