뛰어난 개발자는 타고 나는 것

1. 처음부터 똑똑한 개발자를 뽑아라.  2. 똑똑하지 않는 개발자를 채용해 놓고 똑똑한 개발자로 바꾸려고 시도하지 마라.  3. 특출나게 똑똑하지 않은 개발자도 다 적절한 역할이 있다.  4. 그 역할을 찾아서 제 역할을 하도록 하라. 각 개발자에게 알맞은 역할을 찾아 주고 제대로 일하게 하는 것만으로도 얼마나 힘든지 아는가?

소프트웨어 회사 경영자와 관리자에게 전하는 말입니다.

요즘은 뛰어난 개발자를 구별하기 정말 어렵습니다. Labor market에는 실업자가 넘쳐나지만 뛰어난 개발자는 눈을 씻고 찾아봐도 볼 수가 없습니다. 뛰어난 개발자는 이직을 잘하지 않고 노출이 잘 안되기 때문입니다.

그래서 적당한 개발자, 또는 해당 분야에 경험이 좀 있는 정도의 개발자를 그냥 채용하는 경우가 많습니다. 하지만, 이런 개발자들은 뛰어난 개발자를 대신할 수는 없습니다.
뛰어난 개발자는 타고납니다.

뛰어난 개발자의 필수 조건인 논리력은 태어날 때 이미 50%는 결정되고 교육과정을 거치면서 나머지 49%가 결정됩니다. 사회에 나와서 아무리 노력을 해도 이미 완성된 두뇌는 별로 바뀌지 않습니다. 경험이 쌓이면서 좀더 지식이 풍부해지고 노련해질 뿐입니다.

요즘의 개발환경은 뛰어난 개발자와 그저 그런 개발자를 구별하기 점점 어렵게 만들고 있습니다.

뛰어난 개발자들은 정말 복잡한 알고리즘을 몇 시간 만에 구현해 낼 수 있지만, 그저 그런 개발자들은 몇 달을 줘도 불가능합니다. 하지만, 요즘은 그런 알고리즘을 구현하지 않아도 개발이 가능한 분야가 얼마든지 있고, 일반인 수준의 논리력만 가지고도 개발자로서 일하고 있는 사람들이 넘쳐납니다.

하지만, 이런 그저 그런 개발자들만 잔뜩 모아 놓은 회사는 그저 그런 회사일 수 밖에 없습니다.

물론, 소프트웨어 회사가 돌아가려면 이런 개발자들도 필요합니다. 그런데, 뛰어난 개발자와 그저 그런 개발자를 구분하지 못하는 회사는 챔피언이 될 수 있는 선수를 후보로 썩히는 것과 같은 행동을 합니다.

일단 수학을 잘한다면 뛰어난 개발자가 될 가능성이 아주 높습니다. 물론 수학을 잘하는 모든 사람이 뛰어난 개발자가 될 수 있는 것은 아니지만, 하나의 중요한 요소인 것은 사실입니다. 하지만 수학 실력은 아주 형편없는데 뛰어난 개발자가 될 가능성은 별로 높지 않습니다. 애초부터 복잡한 논리를 처리할 수 있는 두뇌를 가지고 있지 않기 때문입니다.  

경력직 개발자중에서 똑똑한 개발자를 찾기 어려우면 아직 세상 물정을 잘 모른 대학생들 중에서 찾는 것이 좋습니다. 참고로 저도 대학교 다닐 때부터 회사 생활을 했었습니다. 

뛰어난 개발자들은 대학 재학 중에도 이미 뛰어난 실력을 보입니다. 대학에서 적당히 학점 따서 졸업하는 학생들보다 학점은 낮을 수 있어도 확실히 실력은 뛰어날 수 있습니다. 하지만, 요즘 같이 치열한 취업 환경에서는 학점에서 탈락해서 취업이 어려울 수 있습니다. 이런 학생들을 찾아서 회사로 끌어들이는 것이 관리자들이 해야 할 중에서 가장 중요한 일이죠.

요즘은 보통의 머리를 가진 사람도 개발을 할 수 있는 세상이 되었습니다.

그렇다고 보통이나 그 이하의 개발자들만 뭉쳐 놓고 훌륭한 제품을 만들 수 있을 것으로 착각하면 안됩니다. 뛰어난 개발자 채용에 회사의 사활을 걸어야 합니다. 관리자나 HR부서에서는 채용 시즌이나 결원이 생길 때만 잠시 채용에 관심을 둬서는 안됩니다. 1년 내내 채용에 온 힘을 쏟아야 합니다. 그렇다고 미련한 방법도 소용 없습니다. 참신한 방법들을 만이 연구해야죠. 

언젠가 똑똑한 개발자들이 스스로 몰려가는 SW회사가 우리나라에고 생기면 좋겠습니다.

PS) 똑똑하다는 것이 개발자에게 필요한 오직 한가지 조건은 아닙니다. 즉, 똑똑하기만 하다고 최고는 아니죠. 특히 인성과 긍정적인 자세가 중하죠. 이런 부분은 나중에 기회가 되면 풀어 보겠습니다. 또한 다양한 채용 방법에 대해서도 글을 올려 볼 계획입니다.

아이디어 보상제의 함정

소프트웨어 회사에서 참신한 아이디어가 생존에 필수인 것은 당연합니다.

그래서 소프트웨어 회사는 좋은 아이디어를 뽑아 내기 위해 갖은 노력을 합니다.

하지만 이는 그렇게 쉬운 일이 아닙니다.

가끔 아이디어에 대해서 돈으로 보상하는 정책을 시행하는 회사를 보게 됩니다. 

그런데, 별로 큰 효과를 보지 못하는 경우가 많습니다. 오히려 역효과를 일으킬 수가 있습니다.

개발자는 원래 아이디어가 넘치는 사람들입니다. 또한 아이디어 내는 것을 좋아하죠.

이를 보상이라는 것으로 보답을 하기 시작하면 자칫 아이디어 내는 것을 더 방해할 수도 있습니다.

보상을 위해 아이디어를 내놓는다는 도덕적인 결함이 이를 가로막습니다.

아이디어에 대한 보상은 도덕적으로 상처가 되지 않을 만큼 작다면 문제가 되지 않습니다.

즉, 새로운 아이디어를 낸 직원에게 5,000원짜리 도서상품권은 별 문제가 되지 않습니다.

하지만, 아이디어 10개를 내면 백만원을 주고 상품화되면 매출의 몇%를 준다는 식의 보상은 그럴 듯 해 보여도 도적적인 압박이 개발자들의 두뇌를 억눌러서 아이디어가 나오지 못하도록 방해하기도 합니다. 

개발자에 대한 최대의 보상은 자신들이 낸 아이디어로 프로젝트를 할 수 있게 해주는 겁니다. 물론 기존의 업무는 그대로 하고 이것도 하라는 식으로는 곤란합니다. 또 나오는 아이디어마다 모두 만들어 보자는 식도 곤란합니다. 아이디어는 서로 활발히 의논하고 발전시킬 수 있는 분위기와 환경이 되어야 하면 회사의 지원도 필요합니다. 이렇게 도출된 아이디어는 아이디어 발의자의 이름이 따라다니고 개발자에게 이 프로젝트에서 활약할 기회를 주는 것으로 충분한 보상이 되기도 합니다. 

또한, 실제 대단한 성과에 대한 보상은 추후 감사의 의미로 지급할 수 있습니다. 하지만 보상을 유인책으로 쓰는 것은 부작용이 더 클 수도 있습니다. 따라서 진정한 감사 의미의 보상이 아니라면 서로에게 불편하며 큰 부작용 및 송사에 휘말릴 수도 있습니다.

정말 끝내주는 아이디어가 있어서 회사에 바치기 아까우면 아이디어를 가지고 퇴사를 하십시오. 그리고 직접 회사를 설립해서 개발을 해 보세요. 물론 실패할 가능성은 99%입니다. 하지만 성공하면 대박이겠죠.  물론 기존의 회사에서 시도하더라도 성공할 가능성은 10%가 안될 겁니다. 

지금의 회사에서 개발자가 가진 아이디어를 펼치는 것은 개발자에게는 좋은 기회가 될 것이고, 경력에도 긍정적인 영향을 끼칩니다. 수동적인 프로젝트 참여보다 본인의 아이디어를 기반으로 주도적으로 참여한 경력은 채용에서 훨씬 긍정적인 영향을 끼칩니다. 또한 개발자들은 이런 식으로 일을 즐기고 이렇게 일할 때 가장 퍼포먼스도 높습니다. 물론 매일 SI나 용역만 하는 회사는 이런 환경을 조성하기는 어렵겠죠. 그래서 저는 SI나 용역만 하는 회사에서 일하고 싶은 생각은 별로 없습니다.

소프트웨어 업계에서는 아이디어가 충만하고 현실화 할 수 있는 환경이 잘 되어 있는 회사가 성공할 가능성이 높습니다. 개발자에게는 돈으로 보상하는 것보다 기회와 업적으로 보상하는 것이 더 좋습니다. 또한 보상제보다는 아이디어가 샘솟을 수 있는 활기 넘치는 환경이 더 중요합니다. 

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, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

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

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

SW회사, 이런 사장이 문제

모든 회사가 마찬가지이지만, SW회사에서 경영자의 중요성에 대해서는 여러 번 얘기를 했습니다.

여러 경영자 중에서 어설프게 아는 경영자가 아예 잘 모르는 경영자보다 더 무섭습니다.

많은 SW회사 경영자들을 만나보면, 소시적에 코딩도 좀 해보고 밤새우면 개발도 해봤다고 SW 개발을 아주 잘 이해하고 있다고 착각하는 경우를 자주 접하게 됩니다. 또 본인이 상당한 수준의 전문가라고 착각하기도 합니다.

이런 경영자일수록 자신이 잘 알고 있다고 생각하므로 진짜 전문가인 내부 개발자들이나 외부의 목소리에 귀를 기울이지 않게 됩니다.

이는 마치 바둑 7,8급 정도 두는 실력으로 1,2단 실력을 가진 개발자들 머리 위해서 마음대로 휘두르는 것과 같습니다. 

비록 자신이 모르더라도 전문가를 채용하고 전문가의 의견을 존중하는 경영자가 오히려 낫습니다.

이런 어설픈 전문가 증상은 개발자 출신 경영자에게서 종종 나타납니다.

이러한 경영자들은 회사가 커지면서 부딪히는 문제들을 자신의 경험을 토대로 해결하려고 하곤 합니다. 그러면서 개발자들이 자신이 왕년에 개발하는 것처럼 열심히 안 한다고 한탄하기도 합니다. 본인은 과거에 꽤 괜찮은 소프트웨어를 개발하여 회사를 이만큼 키워 놓았지만, 잘 개발했던 것은 아닙니다. 회사가 작고 개발 인원이 얼마 안되니 그냥 주먹구구식으로 개발을 했어도 별 문제 없이 개발이 되었던 것일 뿐입니다.

차라리 소프트웨어 개발에 대해서 잘 몰라도 전문가의 말에 귀를 기울이고 이해를 하려고 노력하는 경영자가 어설픈 전문가 경영자보다 낫습니다. 물론 진짜 소프트웨어 전문가인 경영자가 있다면 좋겠지만, 이것은 거의 불가능한 일이고 그렇다면 그런 사람은 CEO보다는 CTO역할을 하는 것이 맞겠죠. 이러한 연유로 우리나라 SW회사에는 제 역할을 하는 CTO를 만나는 것이 쉬운 일이 아닙니다.

최고의 SW전문가는 아니더라도 경영자가 적절히 SW개발에 대해서 이해를 하고 있고 내부 개발자들의 의견을 존중하고 전문가의 말에 귀를 기울이고 개발팀에 적극적으로 투자를 해준다면 금상첨화입니다. (물론, 이런 경영자도 많이 만나 봤습니다.)

가장 말 안듣는 개발자는?

소프트웨어 업계에서 가장 독특한 개발자들을 꼽으라면 단연 "게임개발자"들입니다.

대부분 태생적으로 형식과 규칙을 싫어하고 개성이 강하며 자신만의 스타일을 즐깁니다.

물론 이런 방식으로 곧잘 쓸만한 게임을 개발해내기도 합니다.

게임 개발자들이 독특한 것은 비단 우리나라 얘기만이 아닙니다. 미국 실리콘 밸리에서도 게임 개발자들을 평가하라고 하면 프로세스를 따르기 싫어하고 해커와 같이 밤새 시스템에 매달리기를 좋아한다고들 합니다.

이러한 인식들이 게임 개발자는 자기 스타일로 마음대로 개발을 해도 좋은 게임을 만들 수 있을 것으로 착각하게 합니다. 물론 다른 소프트웨어와 마찬가지로 게임도 규모가 작을 때는 주먹구구든 어떤 방식으로 개발을 해낼 수 있습니다. 하지만 규모가 커지기 시작하면 비즈니스 S/W든 게임이든 주먹구구식으로 개발할 수가 없게 됩니다.

따라서 게임 개발자들의 강한 개성은 회사의 규모가 커지면서 성장하는데 더 큰 방해요인이 됩니다. 현재 성공한 게임회사들이 이런 개성 강한 개발자들을 멋대로 방치해서 그렇게 성장했다고 생각하면 착각입니다. 다들 프로세스와 게임 개발자 특유의 특징을 잘 조합해서 합리적인 개발 프로세스를 정착했기 때문에 그렇게 성장한 것입니다.

게임 개발자들이 프로세스와 규칙을 더욱 더 싫어 이유는 다음과 같은 것들이 있습니다.

• 원래 얽매이는 것을 싫어합니다.
• 자신의 스타일을 좋아하고 변화를 싫어합니다. (일반적인 개발자 또는 사람들도 그렇습니다.)
• 프로세스와 규칙이 잘 정비되면 자신에 대한 의존도가 떨어진다고 착각합니다.

이러한 이유들 때문에 회사에서 성장을 하기 위한 개혁 시도에 갖가지 핑계를 대면서 개혁을 방해합니다. 창의력을 저해시킨다는 등의 핑계를 꽤 효과적이어서 상당기간 개혁을 지연시키기도 합니다. 하지만 이는 회사에도 큰 Risk이고 개인에게도 성장을 방해시키는 요인이 되므로 결국 다 손해입니다.

소프트웨어 개발 프로세스는 바이블이 하나 있어서 모든 회사에 똑같이 적용할 수 없습니다. 각 회사에 알맞게 만들어가야 합니다.

또한 게임 개발자들도 장점인 창의성이나 개성은 유지하되 프로세스를 따르고 게임 뿐만 아니라 소프트웨어 공학에도 관심을 둬야 회사가 성장해 감에 따라서 회사의 게임 개발을 이끌 수 있는 리더로서의 능력을 갖출 수 있습니다.

Mensa(멘사)회원들보다 똑똑한 Waitress

Mensa Convention 멘사 회의   A few years ago, there was a Mensa convention in San Francisco, and several members lunched at a local cafe. 몇 해 전 샌프란시스코에서 멘사 회의가 열렸을 때 몇 명의 회원들이 동네 카페에서 점심을 했다.  While dining, they discovered that their salt shaker contained pepper and their pepper shaker was full of salt. 이들은 식사하다가 소금통에 후추가 들어 있고, 후추통에는 소금이 가득 차 있다는 것을 발견했다. How could they swap the contents of the bottles without spilling, and using only the implements at hand? Clearly this was a job for Mensa! 어떻게 하면 주변에 있는 도구만을 사용하여 병 속의 내용물을 흘리지 않고 서로 옮겨 담을 수 있을까? 분명히 멘사 회원을 위한 문제였다! The group debated and presented ideas, and finally came up with a brilliant solution involving a napkin, a straw, and an empty saucer. 그들은 토의도 하고 아이디어도 교환했다. 그리고는 마침내 냅킨, 빨대, 받침접시를 사용하는 기막힌 방법을 찾아냈다. They called the waitress over to dazzle her with their solution. 그들은 웨이터리스를 불러 그들이 생각한 놀라운 방법을 알려주고 싶었다. "Ma'am," they said, "we couldn't help but notice that the pepper shaker contains salt and the salt shaker..." “저기요.” 그들이 말했다. “여기 보니까 후추통에 소금이 들어 있고, 소금통에….” "Oh," the waitress interrupted. "Sorry about that."  “아, 죄송합니다.” 웨이터리스가 말을 끊으며 대답했다.  She unscrewed the caps of both bottles and switched them. 그러고는 두 통의 마개를 풀어서 서로 바꿔 끼웠다.  출처:이찬승 영어 등대

소프트웨어를 개발하는데 있어서도 이와 같은 일이 흔히 벌어집니다.

간단한 솔루션이 있는데, 복잡하게 접근하여 오히려 시스템을 망치는 경우도 많습니다.

간단하고 명쾌한 제품이 성공할 확률이 더 높습니다.

"간단하게 생각하기" 개발자에게 필요한 마인드입니다.

Google을 이끄는 힘

아이디어 내면 "네가 한번 만들어봐"

소프트웨어 업계만큼 아이디어가 넘치는 곳도 찾기 어렵습니다.

Google이 탄생하게 만든 힘도 아이디어이고, Google이 지속 성장하여 지금이 Google이 된 힘도 아이디어입니다. Google에서는 업무시간의 20%는 새로운 아이디어를 생각하거나 준비하는데 사용할 수 있고 좋은 아이디어만 있다면 얼마든지 시도해 볼 수 있습니다. Google이 풍족하기 때문에 그렇게 할 수 있다고 말하는 사람들도 있지만, 이는 닭이 먼저냐? 달걀이 먼저냐?의 이슈입니다.

소프트웨어 업계에 종사하고 있는 사람이라면 항상 새로운 아이디어에 대해서 고민하기 마련입니다.

하지만, 좋은 아이디어를 내면 "네가 한번 만들어봐"라고 하는 경우가 많습니다. 또는 "뜬구름 잡고 있네"라고 하는 경우도 있죠.

안 그래도 바쁜데 아이디어만 내며 그 책임이 나에게 돌아오고 지금 하고 있는 일에 지장을 초래할 수 있기 때문에 좋은 아이디어가 있어도 쉽사리 얘기하기도 힘들어 집니다..

그러다 보니 자연스럽게 지금 하고 있는 일이나 열심히 하지 "생각은 무슨 생각" 그냥 아무 생각 없이 일이나 하게 됩니다.

아이디어가 나오면 아이디어를 더 발전 시키는 일은 회사에서 할 일입니다.

물론 아이디어를 내놓은 사람이 아이디어를 Follow up하는 일을 맡을 수도 있지만, 이를 위한 배려는 해야 합니다. 안 그래도 바쁜데 언제 그러고 있냐고요? 그러다 보면 지금 하고 있는 업무에 지장이 있다고요? 그런 회사는 어차피 현재 일에만 치여서 미래는 준비 못하는 겁니다. 즉 R&D에 투자를 못하는 것이고 미래가 없는 것이죠.

SW 회사의 중요한 자산은 개발자의 시간이기 때문에 개발자의 시간을 사용하는 것은 중요한 투자 수단의 하나 입니다. 공짜가 아니죠.

아이디어가 나오면 일단 공론화 할 수 있는 창구가 필요합니다.

그래서 누구나 볼 수 있고 토론을 할 수 있어야 합니다. Wiki를 이용하는 것도 좋은 방법이고 주기적으로 아이디어를 발표하게 하는 것도 좋습니다. 사소한 아이디어 하나가 여러 사람의 머리를 거치면서 훨씬 더 멋진 아이디어로 발전하는 경우는 흔합니다.

아이디어를 많이 생각해 낼 수 있는 수단이 필요합니다. 간단한 포상을 해도 되고, 평가에 반영할 수도 있습니다. 또 아이디어가 실현되어서 수익을 내게 되면 그 수익의 일부를 지급하는 방법도 있습니다.

꾸준히 아이디어를 내지 않는 SW회사는 용역회사밖에 될 수 없을 겁니다. 

아이디어는 10개 나오면 그 중에 하나 쓸만하고, 그 쓸만한 아이디어 10개 수행하면 한 개 정도 성공하고 그 성공한 아이디어 10개 중에서 한 개 정도 대박이 터질까 말까 합니다.

즉, 아이디어가 1,000개는 나와야 대박이 나올까 말까 한다는 겁니다.

999개의 아이디어가 없으면 대박 아이디어 1개가 나오지 않습니다. 그래서 꾸준히 아이디어를 고민하지 않고 몇 명이 머리 맞대고 대박 아이디어 고민하는 것은 확률이 너무 낮습니다.

아이디어는 어느날 갑자기 계시를 받듯이 하늘에서 뚝 떨어지는 것이 아닙니다. 업계 동향도 꾸준히 살펴야 하고, 신기술도 열심히 익혀 놓고, 새롭고 창의적인 생각을 장려하는 기업 문화가 있지 않으면 아이디어가 생기지 않습니다. 좋은 아이디어라고 하더라도 시장의 상황과 맞지 않는 다면 별 효과를 발휘하지 못할 수도 있습니다. 이런 시기 적절하지 못한 아이디어라고 하더라도 잊혀지지 않도록 꾸준히 관리할 수 있는 도구도 필요합니다. 

아이디어를 먹고 살 수 밖에 없는 Software회사가 아이디어 발굴에 소홀히 한다면 지금은 그럭저럭 살아남을 수 있어도 지속적으로 성장하는 회사가 되기는 어려울 겁니다. 아이디어 없이 영업으로 성장한 회사의 개발자들은 참 고될 수 밖에 없습니다. 그런 회사에서 일하는 개발자를 흔히 "앵벌이"라고 하죠. 

끊임 없이 아이디어 발굴에 투자하는 기업문화가 개발자들을 더욱 즐겁게 일하고 건전하게 성장하는 소프트웨어 회사를 만들어 줍니다.