공짜 점심이 개발자를 행복하게 할까?

이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.

최근에 국내 유수의 소프트웨어 회사들의 구조조정 회오리를 보면 착찹한 생각이 든다. 척박한 우리나라 소프트웨어 환경에서 참신한 개발문화를 도입하고 새로운 모습을 보여주려고 했던 회사들이어서 더욱 안타깝다.

필자는 이런 현상의 결과와 겉모습만 말고 다른 시각에서 좀 더 근본적인 원인을 살펴보고자 한다.

3D 취급을 받고 있는 국내 소프트웨어 개발자들은 잘나가는 실리콘밸리의 소프트웨어 회사들과 높은 연봉을 받는 소프트웨어 개발자들이 부럽지 않을 수 없다. 종종 그런 회사들의 끝내주는 개발 환경이 부러움을 사곤 한다.

공짜 점심, 자유 출퇴근 제도, 공짜 커피, 편안한 사무실, 환상적인 휴게실/오락실/수영장, 선택 가능한 재택근무 등이 그것이다. 물론 회사마다 다르기는 하다.

우리도 개발자들에게 이런 공짜 점심 등의 혜택과 환경을 제공하면 개발자가 행복해질까? 회사는 더욱 성과를 낼 수 있을까? 뛰어난 개발자들이 모여들까? 

단순히 겉모습만 따라 하는 것은 단기적으로 효과가 있을지 모르지만 장기적이고 근본적으로는 해결책이 아니다.

여기서 우리는 착각하는 것이 있다. 그들이 제공하는 끝내주는 개발환경은 공짜가 아니다. 개발자가 예뻐서 주는 것이 아니다. 그들의 환경, 개발 문화, 개발 프로세스에 맞게 가장 성과를 잘 낼 수 있는 환경을 제공하고 있는 것이다. 

사무실 주변에 식당이 널려 있는 우리나라와는 다르게 실리콘밸리에서는 차를 타고 점심을 먹으러 가거나 샌드위치를 사다 먹어야 한다. 매번 차를 타고 점심을 먹으러 가는 것은 엄청난 시간 낭비이기 때문에 회사에서 공짜 점심을 제공하는 것이 회사에 더 이익이다. 실리콘밸리 회사들은 공유의 문화를 기반으로 수많은 리뷰가 있고 얼굴을 보지 않고도 효율적으로 일할 수 있는 프로세스와 시스템이 갖춰져 있다. 재택근무와 자유 출퇴근을 통해서 뛰어난 개발자를 효율적으로 활용할 수 있다. 이런 끝내주는 환경은 개발문화와 프로세스가 맞물려 나온 결과물이지 목적은 아니다. 

우리나라에서는 환경은 전혀 그렇지 않은데 그 결과나 겉모습만 따라 하면 회사가 잘 되기는커녕 자칫 악화를 초래할 수도 있다.

내가 생각하는 개발자가 진정으로 행복하게 일할 수 있는 환경은 좀 다르다. 개발자가 합리적으로 일할 수 있는 환경이 행복한 개발자가 될 수 있는 환경이라고 생각한다.

합리적인 커뮤니케이션이 가능하고, 개발자의 기술적인 의견이 존중되고, 적절한 개발 일정이 믿어지고 보장되며, 필요한 적절한 리소스가 제공되며, 빈번한 요구사항 변경으로 수많은 야근과 아키텍처가 산으로 가는 일이 없고, 개발자의 노력에 대한 적절한 보상이 이루어지고, 개발자 경력이 보장되는 환경이다. 물론 개발자도 그렇게 할 수 있는 역량이 있어야 한다.

좋은 복지 조건은 뛰어난 개발자를 유치하는데 도움이 되지만 아무리 뛰어난 개발자가 있다고 하더라도 비합리적인 환경에서 일한다면 효율적으로 개발이 되지 않을뿐더러 회사가 어려워 지면 좋은 복지가 오히려 회사의 발목을 잡는다.

나는 공짜 점심을 주는 것보다 경영진이 소프트웨어에 대해 좀더 이해를 하고 아무 때나 함부로 요구사항을 바꾸지 않고 합리적인 개발일정이 받아들여지면 좋겠다. 나는 공짜 커피보다 더 빠른 PC와 개발에 꼭 필요한 기반시스템에 투자를 해줬으면 좋겠다. 그것이 개발자인 나를 더 행복하게 만든다.

실리콘밸리 회사를 따라 가려면 겉모습보다는 그들의 개발 문화를 먼저 따라 하자. 공짜 점심은 약간의 돈만 있으면 쉽게 제공할 수 있지만 개발 문화를 따라 하는 것은 그보다 10배 100배 더 어렵다. 결실을 보는데 시간도 훨씬 오래 걸린다. 개발 문화를 따라 하는 방법은 책을 보고 배우기 어렵기 때문에 제대로 하더라도 5년, 10년 이상 걸릴 일이다. 그들이 50~60년 걸쳐서 쌓아온 문화를 단시간에 따라 잡기는 어렵다.

많은 회사들이 중요한 개발 문화 중 하나인 공유 문화를 따라 하려고 했지만 대부분은 겉모습 흉내만 내다가 정착에 실패를 했다. 또한 문화의 핵심은 모른 채 겉으로 드러나는 기법들만 쫓다가 회의에 빠져들기도 한다. 이렇게 실패한 경우에는 시도하지 아니한 만 못한 경우도 많다. 이도 저도 아니고 어중간해서 더 혼란스럽게 된다.

나름대로 깨어 있다는 개발자들도 의욕은 넘치지만 자수성가로 성장한 탓에 동료들을 이끌어서 효율적인 개발문화를 정착시키기에 한계를 느끼고 좌절하기 일쑤다.

제발 겉멋들어서 겉모습과 기법만 따라 하지 말고 진짜로 개발자가 행복해 할 수 있는 환경을 만들어 보자. 그것이 처음에는 힘들고 더 오래 걸리더라도 제대로 될 길일 것이다.

가끔 왜 두루뭉술하게 얘기를 하고 구체적인 방법을 알려 주지 않냐고 하는 사람들이 있다. 이런 짧은 글로는 방법을 구체적으로 알려주는 것은 불가능하다. 태권도를 글로 알려줄 수 없듯이 개발문화도 실전 경험을 많이 한 선배들의 코칭을 받아 직접 몸으로 부딪혀 보고 경험해 봐야 하는 것이다.

image by mcdonalds.com

‘한국의 저커버그’가 양성되기 위한 조건

교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.

이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.

예전에는 한국의 빌 게이츠를 키워야 한다고 하더니 요즘은 스티브 잡스를 거쳐서 마크 저커버그를 키워야 한다는 목소리가 높다.  정부 주도의 한국판 저커버그 양성 프로젝트가 생기는가 하면 기업이 주도하는 시도들도 있다.  이런 시도들이 나쁜 것은 아니다.

프로그래머 인력을 키울 수는 있을 것이다. 하지만 빌게이츠나 저커버그 같은 사람이 탄생하는 데는 별 도움이 안될 것 같다. 과연 특수한 교육기관이나 양성 기관에서 그런 인물을 양성할 수 있을까?

그럼 한국의 빌게이츠, 저커버그를 양성하기 위해서 그들이 어떤 역량을 가지고 있는지 살펴보자. 물론 “인생 운칠기삼”이라는 말이 있듯 역량이 뛰어나기 때문에 빌 게이츠나 저커버그가 성공한 것은 아닐 것이다.

또한 그런 역량이 있는 사람이 무조건 성공하는 것은 아니다. 하지만 그런 역량을 가진 사람이 많이 배출될 수 있는 환경이 있다면 우리나라도 빌게이츠 같은 사람을 배출할 가능성이 높아질 것이다.

필자는 소프트웨어 개발자가 가져야 하는 역량 또는 소양을 8가지로 구분하여 비교를 해보았다. 비교 대상은 주변에서 흔히 볼 수 있는 일반적인 코더 또는 프로그래머, 경험이 많고 뛰어난 아키텍트 그리고 마지막으로 청년 시절의 빌 게이츠다.

비교 수치는 지극히 필자의 개인적인 의견이기 때문에 실제와는 차이가 있을 수 있으며 전체 맥락을 설명하기 위한 것이니 수치의 정확성을 가지고 논하지는 말자.

각 항목은 뛰어난 개발자 또는 아키텍트가 되기 위해서 필요한 역량과도 상당히 비슷하니 개발자라면 관심을 가져보자. 그럼 각 항목을 살펴보자.

1. 창의력

남들이 생각하지 못하는 새로운 생각을 해내고, 문제에 봉착했을 때 참신하고 뛰어난 해결책을 찾아가는 능력이다. 단시간의 교육으로 배울 수 없으며 소프트웨어에 대한 지식뿐만 아니라 다양한 인문학도 창의력과 연관이 있다.

2. 논리력

소프트웨어 개발자에게 필수적으로 필요한 역량이다. 수학 교육과 다양한 논리 교육으로 향상 될 수 있으며 선천적인 지능에 크게 좌우된다. 이를 향상하기 위해서는 어렸을 때부터 오랫동안 꾸준한 교육이 필요하다.

3. 커뮤니케이션 능력

일반 코더에게는 그렇게 높은 수준이 커뮤니케이션 능력이 요구되지 않지만 뛰어난 아키텍트가 되려면 상당히 중요한 능력이다. 대화능력, 듣기능력, 토론기술, 대인기술, 설득능력, 인내력 등이 필요하다. 이런 능력은 암기식 교육환경에서는 키워지기 어렵다.  어렸을 때부터 토론식 교육 환경이 필요하며 능력을 키우기 위해서 시간이 매우 오래 걸린다.

4. 문서 작성 능력

가독성이 뛰어난 문서를 작성하는 기술이다. 일반적인 쓰기 능력, 정보 조직화 기술 등이 필요하며 일반 코더들이 가장 부족한 능력 중 하나이다. 십 수년의 학교 교육을 통해서 기초를 다져야 하며 실전 개발을 통해서도 오랫동안 단련해야 향상되는 능력이다.

5. 컴퓨터, 소프트웨어 지식

소프트웨어 동작원리, 자료구조, 알고리즘, 개발언어 등 개발의 기초 지식이다. 대학의 소프트웨어 관련학과에서 주로 가르치는 것이고 단시간에 기초를 닦을 수 있고 독학도 가능하며 실전 개발을 통해서 꾸준히 습득하는 지식이다. 단기적이고 집중적인 학습이 가능하다.

6. 코딩 능력

누구나 아는 코딩 파워다. 일반 코더의 능력을 구분하는 기준이며 그 능력차이는 코더마다 천지차이다. 다른 부분에 비해서 상대적으로 단기적인 교육의 효과가 있다.  우리나라 프로그래머들이 별로 떨어지지 않는 능력이다.

7. 소프트웨어 공학 경험

소프트웨어를 빠르게 개발하기 위한 공학적인 지식과 경험이다. 소프트웨어 분석, 설계, 소스코드관리, 이슈관리, 테스트, 프로세스, 툴, 개발문화 등 광범위한 영역의 경험이 필요하다. 학교에서는 배우기가 거의 불가능하며 제대로 된 개발환경에서 실전 개발을 통해 배워야 하며 매우 오랜 시간이 걸린다.

8. 도전정신

소프트웨어 개발자에게 꼭 필요한 역량은 아니지만 빌게이츠나 저커버그를 양성한다고 하면 필요한 정신이다. 타고난 유전자가 큰 영향을 미치며 주변 환경에 영향을 받을 수 있다. 단기적인 교육으로 향상하기는 어렵다.

이 중에서 교육기관이나 양성기관에서 단기적으로 키워서 효과를 볼 수 있는 분야는 소프트웨어 지식이나 코딩 정도이다. 나머지는 어렸을 때부터 꾸준히 키워야 하거나 실전 개발을 통해서 배워야 하는 것이다. 인위적이고 단기적인 교육으로 빌게이츠나 저커버그를 만들어낼 수 없다는 것은 자명하다. 인문학을 조금 더 가르치는 것도 새발의 피일 뿐이다.

교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.

직업훈련소 같은 학원을 세울 것이 아니고 불합리한 소프트웨어 업계를 바로잡는 제도와 법률을 손보고 도전하는 청년 창업자를 지원하는 것이 좋겠다. 그렇게 소프트웨어 생태계를 건강하고 매력적으로 만들어야 우수한 인재들이 모여들고 소프트웨어 환경은 더욱 좋아질 것이다.

출처: http://cnet.co.kr/view/18291 

결국 최고 걸림돌은 경영진이다.

소프트웨어 회사가 제대로 개발 역량을 갖추는데 최고의 걸림돌은 소프트웨어에 대한 이해가 부족한 경영진이다.

일반 경영자들이 소프트웨어를 이해할 수 없기 때문에 CTO가 존재한다. 하지만 우리나라 대부분의 소프트웨어 회사에는 CTO가 없거나 있다고 하더라도 CTO역할을 하지 않고 있다.

흔히 벌어지는 심각한 문제는 프로젝트 기간 아무때나 요구사항을 변경하고 심지어는 소프트웨어 기획의 방향을 완전히 뒤엎곤 한다. 이로 인해서 소프트웨어 개발에는 어떠한 일들이 벌어지는지 모르는 듯하다.

알파 버전이 출시된 이후에 아키텍쳐를 뒤흔들만한 기능을 추가하도록 하는 경우도 있다.

자동차를 개발하면서 양산 직전에 휘발유차를 디젤차로 바꾸자는 소리를 하는 사람은 아무도 없을 것이다. 그런데 소프트웨어 회사에서는 경영진의 개인적인 주관으로 이런 요구를 하곤 한다.

관리적인 측면에서도 문제가 생긴다. 관리자와 개발자의 차이를 구분하지 못하고 고참 개발자는 무조건 관리를 해야 하는 것으로 생각한다. 전문 개발자는 30년이 지나도 관리는 전혀하지 않고 개발만 하는 것이다. 그러나 이렇게 개발 경력이 보장이 되는 소프트웨어 회사를 우리나라에서 찾는 것은 그렇게 쉬운 일이 아니다. 아무리 개발이 하고 싶고 관리는 적성에 맞지 않아도 우리나라에서 개발을 하는 이상 관리 업무에 대한 압박은 떠나지를 않는다.

또한 합리적인 관리를 할 수 없으니 무조건 일정을 쪼는 일 밖에는 하지를 않는다. 그러다 보면 아키텍쳐는 형편 없어지고 개발 문화는 뒤쳐질 수 밖에 없다.

몇몇 경영자는 이러한 현상이 개발자들이 제대로 못해서 그렇다라고 핑계를 댈 수는 있다. 닭이 먼저냐 달걀이 먼저냐의 이슈 같아 보이지만 강자인 경영자가 바뀌는 것이 우선이다.

이러한 문제점의 고리를 끊을 수 있는 사람은 개발자가 아니라 경영자이다.

문제의 핵심도 경영자이고 이를 해결할 수 있고 해결 해야 하는 사람도 경영자이다.

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를 작성해봐야 배울 수 있다.

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

내가 없어도 회사가 잘 돌아가면 왠지 불안하다.

그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다.

내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까?

그럼 한달동안 안나오면 어떻게 될까?

대부분의 소프트웨어 회사는 한달동안 심지어는 일주일만 직원 몇명이 안나오면 심각한 문제를 일으키곤 한다.

이러한 종속성은 회사에게는 큰 위험이고 개발자에게는 양날의 검이다.

개발자는 본인이 없으면 회사가 잘 안돌아가는 상황을 선호하곤 한다. 실제로 우리나라에서는 개발자들이 자리를 지키기 위한 좋은 수단이 되기도 한다.  하지만 개발자가 좀더 중요하고 새로운 일을 하는데 발목을 잡히곤 한다.

물론 내가 없어도 회사가 쌩쌩 잘 돌아가는 상황이 매우 불안한 사람도 있을 것이다. 또한 그렇게 합리적으로 돌아가지 않는 회사도 있으니 잘 판단해야 한다.

개발자 뿐만 아니라 Operating에서도 문제는 벌어진다. 특정 직원이 없으면, 빌드나 팩키징을 못하거나 라이센스 발급이 안되는 경우도 있다. 업무는 특정인만 아는 형태로 진행되어서는 안되고 메뉴얼이 필요하고 백업이 가능해야 한다.

회사 입장에서는 리스크일 뿐만 아니라 이런 현상이 벌어지고 있다는 것 하나만 봐도 소프트웨어 개발 전반에 많은 문제가 있다는 것을 짐작할 수 있다.

첫째, 많은 정보, 지식이 특정인 머리 속에 들어 있고 시스템화 되어 있지 않다는 것을 알 수 있다. 또한 리뷰를 통한 공유가 잘되어 있지 않은 것이다.

둘째, 스펙이 제대로 작성되어 있지 않은 것이다.

세째, 개발 프로세스가 제대로 구축되어 있지 않은 것이다. 그 외에도 문제가 많다.

회사는 어떠한 개발자라도 한달 동안 또는 영원히 사라져도 문제 없이 돌아가는 상황이 되어야 한다. 이렇게 하기 위해서 프로세스, 스펙/설계, 기반시스템, 개발 문화를 제대로 구축하는 것이 부담이 된다고 생각하는 경우도 있다. 이는 무조건 주먹구구가 더 빠르고 효율적이라고 주장하는 것과 같다. 초 단기적으로는 주먹구구가 더 나을 수는 있지만 이런 상황은 오래 지속되지 않는다.

특정 개발자가 없어도 잘 돌아가는 환경은 개발자에게도 유리하다. 그래야 개발자는 과거의 일에 발목을 잡히지 않고 합리적으로 일할 수 있는 환경이 된다.

이를 검증하기 위해서는 개발자에게 휴가를 한달씩 줘 보면 된다. 개발자에게 한달짜리 휴가를 줄 수 있는 회사가 되어보자.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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