웹 개발을 시작하기전에 생각해야 할 것들

※웹비즈니스를 기획하고, 실행에 옮기는 분들께 도움되고자 작성합니다.

발췌 『클린 소프트웨어, 클린 아키텍처』

 

│개발에서 코드보다 더 중요한 요소는 사람이다

사람은 비즈니스 성공에 있어 가장 중요한 요소이다.

팀에 뛰어난 팀원이 없으면 좋은 프로세스와 많은 투자금이 있다 해도 프로젝트를 실패에서 구하기 어렵다. 단, 여기서 『뛰어난 팀원』이란, 실력이 우수한 에이스 프로그래머만을 의미하지 않는다. 동료와 함께 일하고, 대화하고, 상호작용하는 능력을 갖춘 사람이 바로 『뛰어난 팀원』이다. 실력은 평범하지만 서로 잘 대화하는 팀이 슈퍼 에이스로 이뤄졌지만 팀원으로서 녹아들지 못하고 상호작용이 어려운 조직보다 성공할 확률이 높다.

 

이기심·개인주의가 팽배하는 조직문화와 존중이 부족한 환경은 실력이 월등한 프로그래머들조차 비효율적인 작업을 하게 만든다. 그럼에도 불구하고, 많은 IT창업자·대표자·경영자들은 환경(기획선정,투자유치,사무실 구축 등)만 구축하고 나면 팀은 자동으로 굳게 결합되리라 기대하는 실수를 반복한다. 다시 말하지만, 팀을 구성하는 일은 비즈니스 환경을 구축하는 일보다 훨씬 더 중요하다. 지식 서비스 및 IT비즈니스는 투자금의 대부분이 인건비로 지출된다. 그러므로 먼저 좋은 팀을 만들기 위해 노력하고, 환경 구축은 팀의 필요를 기반으로 진행한다.

 

 

│그 필요가 급박하고 중요하지 않다면 아무 문서도 만들지 마라

소프트웨어 개발에 있어 추상적이며, 포괄적인 문서는 의미없다.

어떠한 경우건 대략적인 문서보다 동작하는 소프트웨어가 우선이다. 물론, 문서화가 전혀 되어있지 않은 소프트웨어는 재앙이 될 수 있다.(새로운 팀원, 외부 설명 등..) 하지만 지나친 문서화는 언제나 경계대상이다. 소프트웨어의 설계 원리와 구조에 대한 짧고, 요약적인 문서만이 필요하다. 여기서 짧은 문서의 길이란, 12~20p정도이다. 만일, 누군가에게 소프트웨어 원리와 구조를 설명해야 하더라도 해당 문서와 대화를 통해 설명하기를 추천한다. IT분야에서 비즈니스를 시작하려는 많은 기획자들이 문서화에 집착하는 경향이 있는데, 이는 치명적인 단점이 될 수 있다.  코드는 문서와 달리 유일하게 모호하지 않은 원천정보이다. 문서보다 코드를 우선시하라.

 

 

 

│고객의 요구사항을 100% 반영한 요구사항 명세서는 이 세상에 없다

소프트웨어 개발에서 불변의 법칙은 『요구사항은 변한다』이다.

고객·경영자의 요구사항은 어린아이가 떼쓰는 것과 같다. 고객은 자신이 얻고자하는 소프트웨어 혹은 프로그램을 이것저것 열정적으로 설명한 뒤, 몇일 뒤에 완성될 지를 물어보며 기다린다. 어떤 개발자는 고객의 변덕에 대비하기 위해서 요구사항을 빠짐없이 작성한 문서를 작성한다. 하지만 이는 부질없는 짓이다.

 

고객의 요구사항은 여지없이 바뀔 것이며, 이에 대해 개발자가 로봇처럼 문서에 있는 내용 그대로 대응한다면 보수를 받을 수 없거나 소송전을 준비해야 하기 때문이다. 고객의 요구사항을 100% 대응하는 유일한 방법은 프로젝트가 끝날 때까지 고객과 협력적인 관계를 유지하는 것이다. 고객과 협력관계가 밀접하게 형성되면, 요구사항 문서를 검토할 필요도 없다. 개발자는 고개를 갸웃하더라도 고객이 너무나 만족하는 상황이 발생하기 때문이다. 요구사항을 요청한 주체가 사람인 이상, 요구사항은 항상 유동적이다. 이를 해결하기 위해서는 고객과의 밀접한 관계가 해결책이다. 만일 고객과 밀접한 관계를 형성할 수 없는(거리,성향,연령 등) 프로젝트라면 빨리 포기하는 편이 낫다.

 

 

│계획보다 변화에 대한 반응이 우선이다

세상에는 계획이 좋았지만 실패한 프로젝트들로 넘쳐난다.

어떤 분야건 처음 계획대로 정확하게 실행되는 경우는 드물다. 항상 변수가 발생하고, 변화에 대한 대응결과에 따라 계획의 성패가 결정된다. 대개 초보 경영자 혹은 IT창업자들은 간트 차트나 퍼트 차트같은 것들을 벽에 붙여두고, 프로젝트 전체를 통제하고 있다는 만족감에 취한다. 그러나 머지않아 벽의 차트는 매일 스트레스를 주는 원천이 될 것이다. 계획과 현실의 차이를 차트 하나로 극복할 수는 없다. 날짜, 요구사항 심지어 팀원까지 변경될 수도 있다. 

 

가장 바람직한 계획은 변화의 여지를 남겨두는 계획이다. 가령, 결혼식을 생각해보자. 결혼식날 세운 계획을 평생 정확하게 지키며 살아가는 부부가 있을까? 결혼식 날은 일단 두리뭉실한 약속만 할 뿐이다.(파뿌리 약속) 소프트웨어 역시 마찬가지다. 다음 2주간의 세부적인 계획을 수립하고, 다음 3개월간의 개략적인 계획을, 그 이후로는 아주 대략적인 계획만 세운다. 어차피 3개월 이후의 상황은 어떻게 변할지 알 수 없다. 1년 후는 더욱 예측하기 어렵다. 심지어 회사가 망했을 수도 있다. 1년 후의 미래는 작업할 시스템에 대한 흐릿한 개념만 잡고 있으면 된다. 

 

계획은 몇 주간의 시간만 통제하면 된다. 나머지 부분은 탄력적으로 조정할 필요가 있다.

 

 

│실패를 빨리 하라

IT비즈니스 업계에서 성공을 하려면 빨리 실패를 해봐야 한다.

그리고 성공할 때까지 반복하는 과정이 필수다. 반복하다보면 언젠가는 성공한다는 말은 정말 식상하고, 무책임하다. 하지만 어쩔 수 없다. IT업계에서는 실패 & 신제품 출시보다 딱히 더 좋은 방법이 없기 때문이다. 왜 그럴까?

 

전자제품(스마트tv, 컴퓨터 등)을 구입하는 상황을 떠올려보자. 평범한 대다수의 사람들은 어떤 기준으로 전자제품을 선택할까? 아마도 '최신제품'일 것이다. 그렇다. 기술변화 사이클이 빠른 IT업계의 서비스나 제품은 대개 '최신 버전'이 각광받는다. 또, 쓰레기통으로 가는 기간도 짧고, 빈번하다. 한번 취향이 정해지면 쉽게 변하지 않는 생필품, 식품과 달리 소프트웨어는 버튼 클릭 몇번으로 손쉽게 제거할 수 있다. 그래서 기회가 많은만큼, 실패도 많다.

 

소프트웨어 개발에서 애자일과 같은 방식은 『실패를 빨리 그리고 반복하라』의 구체적인 방법론이다. 팀에 애자일을 도입할 계획이라면 아래 12가지를 생각해보자. 

---

『애자일 프로세스』

1] 소프트웨어의 빠르고 지속적인 공개를 통해 고객을 만족시킨다. 소프트웨어는 자주 공개할수록, 최종 품질은 좋아진다.

2] 개발 후반부라 할지라도 요구사항 변경을 환영한다. 요구사항 변경은 긍정적 신호다.

     개발 후반부에도 요구사항 변경을 수행할 수 있는 팀이 바로 최고의 경쟁우위다.

3] 개발 중인 소프트웨어를 2주에서 2달 사이, 혹은 더 짧은 시간 간격으로 자주 공개하라. 공개는 문서가 아닌 소프트웨어다.

4] 기획자와 개발자는 프로젝트를 통틀어 계속 함께 일해야 한다. 이들이 끝까지 좋은 관계로 붙어있을수록  성공확률이 높다.

5] 열정적인 개인들을 중심으로 프로젝트를 구성하라. 그리고 그들에게 환경과 필요자원을 제공한 뒤 끝까지 믿고 맡겨라.

    사람이 가장 중요하다. 열정적인 팀원들이 사무실을 옮겨달라고 요구한다면 사무실도 바꿔줄 수 있어야 한다.

6] 개발팀원들은 일대일로 직접 대화한다. 문서로 대화하는 문화는 조직을 비효율의 늪으로 끌고간다.

7] 개발 중인 소프트웨어가 진척 상황의 바로미터이다. 투자유치, 팀원 숫자, 사무실 등 아무것도 척도가 될 수 없다.

8] 소프트웨어 개발은 100m달리기가 아니라 마라톤이다. 팀원의 페이스를 지속 가능하게 유지할 수 있는 에너지를 관리하라.

     요령을 부려 빨리 끝내는 것은 전혀 중요하지 않다. 높은 질의 기준을 유지할 수 있느냐가 중요하다. 

9] 나중에 해결한다는 식은 철저하게 배제하라. 모든 팀원은 자신이 작성할 수 있는 가장 높은 품질의 코드만 만든다.

10] 목표에 이르는 가장 단순한 길을 선택하라. 내일 문제가 발생한다면 그때 변경을 하면 된다.

      오늘은 가장 간단하고 수준높은 품질의 코드를 작성한다.

11]  팀원 전체가 아키텍처, 요구사항, 테스트를 담당한다. 또, 팀원 전체가 책임을 공유한다.

        누구 한명에게 특정 업무를 분담하고, 책임지도록 하지 않는다.

12] 주변의 환경변화에 따라 팀도 항상 변해야 한다. 애자일 팀은 조직, 규칙, 대화, 관계 등을 계속 조정한다.

---