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

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

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

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

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

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

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

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

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

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

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

image by Kingfox

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

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

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

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

image by naotakem

"거의 다 만들어서 2주후에 개발이 끝나요"

이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.

하지만 이런 대화는 여러 오해를 양산한다.

영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.

그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.

우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.

"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.

따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.

그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.

일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.

알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 

따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 

그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.

RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.

따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.

"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.

좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.

관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 

하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 

알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.

세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.

그래야 좀더 합리적인 일정으로 개발이 진행된다. 

여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자.

첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다.

테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다. 

테스트 팀은 새버전을 가지고 어제 테스트한 시점의 다음 단계부터 또 테스트를 진행한다. 이렇게 테스트 기간 내내 여러번 새버전을 받는다.

두번째 방법은 다음과 같다. 테스트가 2주가 걸리면 2주 동안 테스트 팀은 새버전을 절대로 받지 않고 한 버전을 가지고 테스트를 완전히 종료한다. 개발팀은 버그를 계속 고치지만 새 버전을 테스트 팀에 전달하지 않는다.

어느 방법이 더 효율적으로 보이는가? 많은 회사들이 첫번째 방법을 사용하고 있다. 믿기 어렵겠지만 사실이다. 첫번째 방법은 큰 문제가 있다. 테스트 기간 도중에 테스트 팀이 새로운 버전을 받으면 이전에 테스트 한 내용이 무효가 된다. 여기서는 그걸 무시하고 계속 테스트를 했기 때문에 테스트가 끝나도 끝난 것이 아니다.

그럼에도 첫번째 방법을 사용하는 이유는 있다. 도저히 테스트 할 수 없을 만큼 불안정한 제품을 테스트 해달라고 전달한 경우이다. 그래서 테스트 팀과 적당히 테스트를 하면서 차츰 안정화를 시켜가는 것이다. 이런 품질의 제품은 테스트를 할 필요가 없다. 이 경우는 테스트 팀을 개발팀의 딱까리로 생각하는 것이다. 

원래 테스트를 진행할 수 없을 정도의 제품을 테스트팀이 받으면 테스트를 중단하고 개발팀으로 다시 돌려보내야 한다.

이렇게 비효율적인 테스트가 우리 주변에서 흔히 벌어지는 이유의 원인 따지고 들어가면 앞단계인 분석과 설계가 엉망이거나 없기 때문인 경우가 많다. 

제품의 품질을 유지하기 위해서는 분석/설계도 중요하고 전문적인 테스트를 해야 한다. 대충 개발하고 테스트팀이 개발팀을 도와주는 형태로는 평생 주먹구구식 개발에서 못벗어나고 비용과 시간도 많이 들뿐만 아니라 개발팀은 잦은 야근에서 벗어나기도 어렵다.

앞으로 테스트에 관한 얘기를 좀더 쉽게 풀어서 써보도록 하겠다.

image by cseward

일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다.

프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다.

많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서 어떻게든 활용하려고 버티다보면 소프트웨어의 아키텍처가 점점 이상하게 된다.

많은 인력이 투입되는 단계는 구현단계이며 핵심 구현 인력들이 분석/설계 단계에 리뷰어로 참석할 수는 있다.  일정이 촉박하면 분석/설계를 최대한 빨리 끝내고 할일의 범위와 아키텍처를 명확히 한 후에 인력을 투입해야 한다.

필요한 라이브러리를 개발하지 말고 상용라이브러리를 구매하는 것도 일정을 단축하는데 도움이 된다.

가장 안좋은 방법이 프로젝트 초기에 시장통처럼 개발자를 잔뜩 투입하는 것이다. 소프트웨어 개발을 잘 모르는 경영자들이 이런 실수를 종종 하곤 한다.

우리 주변에서 1년짜리 프로젝트인데 10명의 개발자가 투입되면 10명이 12달동안 계속 같이 일하는 경우를 흔히 볼 수 있다. 이렇게 일정 투입 계획이나 현황만 보아도 개발이 얼마나 주먹구구식으로 진행되고 있는지 알 수 있다. 10명의 개발자가 투입되는 프로젝트도 초기 2,3개월 또는 3,4개월동안은 분석/설계를 담당하는 1,2명만 필요하다. 이 프로젝트에서 분석/설계를 담당한 엔지니어는 많은 개발자가 투입되는 구현기간에 같이 구현에 참여할 수도 있고 다른 프로젝트에서 또다시 분석이나 설계를 담당할 수 있다.

이렇게 인력이 효율적으로 순환이 되면 훨씬 적은 인력과 비용으로 많은 프로젝트를 효과적으로 진행할 수 있게 된다.

인해전술로 많은 인력을 투입하는 방법은 해당 프로젝트를 망치는 방법일 뿐만아니라 회사 전체적으로 효율적인 인력운영을 할 수 없게 만든다. 

image by   Boston Public Library

"코딩은 늦게 할수록 프로젝트가 빨리 끝난다."

대부분의 개발자들은 이 말을 제대로 이해하지 못한다. 그래서 프로젝트 일정이 촉박하면 무조건 코딩부터 시작하곤 한다. 코딩을 빨리 시작하면 프로젝트가 빨리 끝날 것으로 믿곤 한다. 말은 그렇게 하지 않더라도 일정이 부족하면 문서 작성할 시간도 없고 무조건 코딩부터 시작한다.

물론 프로젝트에 따라서 대충해도 되는 경우가 많다. 그런 프로젝트를 예로 들어서 모든 프로젝트에 확대 적용하지는 말자. 즉, 개집은 어떻게 만들어도 다 되는 것이다. 

코딩 시작은 빨리 시작할수록 재작업은 급속히 늘어난다. 코딩을 최대한 뒤로 늦춤으로써 재작업 가능성을 낮춘다. 물론 스펙이 완전히 끝나야 코딩을 시작할 수 있는 것은 아니다. 스펙을 합리적으로 작성하는 요령 중 하나가 미리 확정할 수 있는 라이브러리나 Sub system들은 인터페이스를 미리 확정하고 코딩을 먼저 시작할 수 있다.

보통 프로젝트에서 분석을 해보면 코딩부터 할 수 없다는 것을 알게 된다. 코딩부터 시작하는 경우는 무엇을 개발할지도 모르고 코딩을 시작하는 것이다. 그렇게 미리 작성된 코드는 스펙이 정해지면 버리고 다시 짜야 하는 경우가 많다. 아키텍처에 요구사항이 제대로 반영되지 않는다. 그럼에도 미리 코딩을 해 놓으면 코드를 버리기가 아까워서 그냥 사용하게 된다. 그러다보면 아키텍처는 엉망이 된다.

개발자들은 자신이 작성한 코드를 살리기 위해서 요구사항을 거부하기도 하고 코드에 꼼수를 부리기도 한다. 

가끔은 코딩만하기에도 정말 일정이 부족한 프로젝트들이 있다. 이런 경우도 코딩부터 한다고 프로젝트가 빨리 끝나는 것은 아니다. 무모한 시도를 하는 것이다. 스펙을 작성할 시간도 없는 프로젝트는 안하는 것이 낫다. 그렇다고 회사에서 프로젝트를 거부할 수는 없다. 최대한 빨리 스펙을 써서 합리적으로 가능한 일정와 범위를 제시하는 것이 더 좋은 방법이다.

일정이 촉박하다고 매번 코딩부터 시작하면 10년을 개발해도 별로 나아지는 것이 없을 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

image by explainthatstuff

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

소프트웨어를 국제화해야 하기 위해서는 고려해야 할 것이 한두가지가 아니다. 그런데 많은 회사들은 메시지나 번역하면 되는 것으로 안다. 그렇게 쉽게 접근하다가는 해외 진출을 하면할 수록 문제가 커지고 비용이 늘어서 점점 어려워진다.

실제 만나본 거의 대부분의 회사가 국제화를 제대로 적용하지 못해서 낭패를 보고나 해외에서 크게 실패를 하였다. 비효율성이 높고 문제가 많아도 제품의 크기가 작거나 고객수가 적다면 그럭저럭 버티지만 큰 제품이나 대규모 서비스는 타격이 엄청나다. 심지어는 회사가 휘청할 정도의 문제를 야기 시키기도 한다.

국제화 기술은 알아야 할 지식도 많고 경험도 많이 필요하다. 

기본적으로 국제화(i18n)과 지역화(L10N)으로 나뉜다. 국제화(i18n)은 소프트웨어가 여러 Locale을 지원할 수 있는 기본 기술이고 지역화(L10N)은 각 Locale을 지원하는 것이다.

이 과정에서 고려해야 할 것은 수백가지가 넘는다. 그 중에서 49가지만 알아보자. 만약에 국제화된 소프트웨어를 개발하고 있는 개발자라면 이중에서 몇가지나 알고 있는지 세어보자. 어떤 항목은 그 하나가 엄청나게 큰 것도 있다. 특별하게 순서를 가지고 정리한 것은 아니지만 하나씩 살펴보자. 

여기에 모든 것을 다 나열한 것은 아니다. 하지만 이중에서 필요한 일부를 고려하지 않고 소프트웨어를 개발한다면 이것은 버그가 될 것이고 또는 해당 국가에서 보면 어색하고 기분 나뿐 소프트웨어가 될 수도 있다. 물론 소프트웨어의 종류에 따라서 국제화시 고려해야 하는 항목이 다르다. 따라서 위의 모든 것을 모든 프로젝트에서 고려해야 하는 것은 아니다. 한번씩은 생각해봐야 할 항목들이다.

좋은 소프트웨어를 가지고 비즈니스를 아무리 잘해도 국제화가 잘 안된 소프트웨어는 현지에서 성공하기 어렵다.

1~49번까지의 항목들이 제목만 본다고 쉽게 해결할 수 있는 것은 아니다. 하나의 항목을 가지고 10년 넘게 연구하고 개발하고 있는 것도 있을 정도로 크고 복잡한 것도 있다. 제대로 국제화를 적용하고 싶다면 국제화 전문가의 도움을 받는 것도 한 방법이다. 이것을 처음부터 제대로 하지 않고 시행착오를 거쳐서 고객이 버그를 찾을 때마다 하나씩 고쳐주는 것은 끝도 없고 제품의 이미지는 처음부터 추락할 것이다. 

확실한 것은 국제화를 스스로 생각해서 직접 개발하면 잘못될 가능성이 99%이다. 대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

국제화 기술이 소프트웨어 해외 진출 필수임을 잊지 말자.

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

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

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

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

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

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

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

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

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

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

1. 시장 상황의 변경

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

3. 기술 환경의 변화

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

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

6. 경영진의 변덕

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

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

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

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

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

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

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

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

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

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

image by  m.a.r.c.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

대한민국 이름을 걸고 해외에서 크게 성공한 Software가 없는 것은 안타까운 일이 아닐 수 없다. 내가 아는 한 그런 Software가 없다. 그런 Software가 있다면 알려주기 바란다.

게임 등 일부 분야에서는 성공 사례가 있지만 일부 특수 분야의 일이다.

그렇게 실패하는 이유는 여러가지가 있겠지만 내가 보는 가장 큰 이유는 소프트웨어를 개발하는 기초 역량이 부족해서이다.

누구는 해외 문화를 이해하지 못했다고 하기도 하고, 영업을 잘 못했다고도 하지만 가장 큰 이유는 개발 역량의 차이이다.

국내에서 개발했던 주먹구구의 방식이 해외에서도 그대로 먹힐 것이라고 생각하는 것은 큰 착각이다.

국내에서 성공했던 대부분의 회사들의 성공요인은 국내에서만 먹히는 서비스 전략 때문이었다. 대충 만들어 놓고 고객이 불만을 표시하면 무한 감동 서비스를 제공하는 것이 그것이다. 많은 회사들이 이 전략을 사용해서 국내에서는 성공을 했다.

작은 땅덩어리에서는 고객이 부르면 언제든지 달려갈 수 있지만, 시장이 세계로 넓어지면 그런 고객 감동 서비스는 꿈도 꿀 수 없는 일이 된다. 고객이 부르면 비행기 타고 날아가고 호텔에서 숙박을 해야 하기 때문에 비용과 시간이 너무 많이 들어간다.

해외에서 성공하려면 진짜로 제대로 개발을 해야 한다. 고객이 해달라는대로 개발하는 것이 아니고 제대로 전략을 세워서 제품 기획을 하고 분석/설계를 해서 개발을 해야 한다. 또, i18n Technology(국제화 기술)도 제대로 적용해야 하는데 99%의 회사는 나름대로 방식으로 또 엉터리를 만들어서 적용하기 때문에 해외에서 대패를 하게 된다.

이런 것을 모두 갖추어야 비로소 비슷한 출발선상에서 경쟁을 시작하는 것인데, 국내에서 하던 방법대로 해외서 성공하려고 하는 것은 100m 달리기에서 20~30m 뒤에서 출발하는 것과 다를 바가 없다.

근본적인 역량을 되돌아볼 때이다.

Image by bettlebrox