소프트웨어 개발이 즐거운가요?

나는 소프트웨어가 대학 전공이 아닙니다. 그럼에도 지금 소프트웨어 일을 하고 있는 이유는 소프트웨어를 개발하는 것이 즐거웠기 때문입니다. 처음부터 즐거웠고, 지금도 즐겁습니다. 옛날에는 아침에 눈을 뜨면 오늘 개발할 것들이 머리 속을 스치고 지나가면서 엔도르핀이 나왔었습니다.

 

이러한 이유 때문에 소프트웨어 개발에 종사하시는 분이 정말 많을 겁니다.

 

하지만 현실에 치여서, 즉 SI나 용역을 수행하면서 무리한 일정과 말도 안되는 요구사항, 수시로 바꾸는 요구사항 피곤한 사람들에 치여서 개발 일이 점점 즐겁지 않게 된다고 합니다.

 

그런데 가만히 보면 개발이 즐겁지 않은 것이 아니라 사람과 자신에게 주어진 무리한 요구가 싫은 것입니다. 이는 소프트웨어 필드뿐만 아니라 정도는 다르겠지만 모든 필드에 다 있는 현상입니다. 즉, 아무리 즐거운 일도 일이 되면 계속 즐겁지만은 않다는 것이지요.

 

결국, 주위 환경만 잘 갖추면 계속 즐겁게 일할 수 있는 방법이 있지 않을까 생각합니다. 당장 바꾸기 불가능한 고객과 관련된 것은 미뤄두고라도 내부에서 바꿀 수 있는 것부터 잘 갖춰나가야 합니다. 그런 제대로 된 환경에서 즐겁게 일하는 것은 얼마든지 봐왔으니까요. 그래야 개발자는 그 안에서 정상적으로 성장을 하고 그래야 더욱 즐겁죠. 개발 일이 좋다고 단순히 성장 없이 과거에 하던 일을 계속 반복하면 진짜 좋아 한다고 하기는 어려울 것입니다. 당구 치는 것이 즐겁다고 20년째 150을 치고 있는 사람은 진짜로 당구를 좋아하는 것이 아닙니다. 성장의 욕구와 기쁨이 없이 단순히 즐기는 것은 반쪽 짜리입니다. 특히 협업이 중요한 개발 일에서 그러한 것은 민폐지요.

 

개발자들이 즐겁게 일할 수 있는 환경이 좀더 늘었으면 좋겠습니다. 3D를 넘어서 4D까지로 평가 받는 소프트웨어 개발이 다시 좋은 직업으로 인식되는 날이 와야죠.

 

4D (Difficult, Dirty, Dangerous, Dreamless)

미국에서는 소프트웨어 엔지니어가 좋은 직업 5위에 올라와 있네요. - -;

소프트웨어 프로젝트 성공이란?

소프트웨어 프로젝트 성공을 한마디로 말하면 다음과 같습니다.

"주어진 시간에 주어진 비용으로 요구된 품질의 제품을 만들어 내는 것"

여기서 가장 중요한 것은 시간과 비용입니다. 어차피 품질도 시간과 비용에 귀결됩니다. 

소프트웨어 공학은 이 둘을 충족시키기 위해서 즉, 최소비용으로 최소시간에 소프트웨어를 개발하기 위해서 40년간 연구되어온 실전 학문입니다. 즉 연구소에서 연구만 한 것이 아니라 실제 프로젝트에 적용이 되면서 계속 발전해 온 것입니다.

이 문장에는 많은 함축적인 의미가 있습니다. 

고객과 합의한 스펙은 만족했으나 최종 제품이 고객의 요구를 만족시키지 못하면 분석부터 잘못된 것이므로 진정한 성공으로 보기 어렵고, 개발과정에서 개발자를 너무 밤낮, 주말 가리지 않고 혹사해서 개발자가 몇몇 퇴사를 했다면 비록 종료 날짜는 지켰어도 시간과 비용 면에서 성공적이지 못하다고 할 수 있습니다.

하지만 몇몇 프로젝트에서는 프로젝트 성공을 절차를 지키는 것으로 굳고 믿고 있는 경우가 많습니다. 방법론의 프로세스를 따르고 그에 따르는 산출물들을 만들어내는 것을 중요하게 생각합니다. 특히 공공 프로젝트에서는 별 쓸모도 없는 문서를 많이 만들어 내야 하는 경우가 많은데, 담당자가 무슨 문서가 필요한지를 모르니 나중에 있을 문제를 회피하고자 대부분 그냥 모든 문서를 다 요구합니다. 문서를 봐도 뭔지 잘 모르고 그냥 책꽂이에만 장식을 해 놓고, 나중에 문제 생기면 어차피 개발자를 부를 것이면서 장식용 문서 또는 감사용 문서를 요구하는 것이지요. 또 중간에 감수도 있어서 중간에 요구하는 문서도 만들어내야 합니다.

이렇게 절차와 문서를 요구하는데도 잘 안되니 절차를 잘 안 지키는 것으로 생각하고 중간 마일스톤 단위로 또다시 점검을 하겠다고 하는 것인데, 무지가 가장 무섭다고 하는 말이 딱 떠오릅니다.

이런 환경에서 꾸준히 일을 하다 보니 개발자도 소프트웨어 개발에 꼭 필요한 문서가 뭔지 잘 모르고 문서를 제대로 만드는 훈련이 못하게 됩니다. 그리고 나서 자기 회사의 솔루션을 개발할 때는 헷갈리는 상황이 됩니다. 기존에는 갑이 요구하는 절차와 문서에 불평을 많이 했지만, 진짜 제대로 할 기회가 오면 제대로 하기 어려운 것입니다. 훈련이 안되어 있으니까요. 그렇게 부적합한 절차와 많은 문서를 만드느니 그냥 주먹구구식으로 똘똘 뭉쳐서 열심히 개발하는 것이 더 잘 됩니다. 이 방식으로 성공한 많은 선배들이 있으니까요. 

소프트웨어를 왜 개발하고 있고 어떻게 하는 것이 성공적인 개발인지 다시 한번 생각해 봤으면 합니다.

개발자는 일자리 구하기 힘들고 회사는 개발자 구하기 힘들고

개발자는 일자리 구하기 힘들고 회사는 개발자 구하기 힘든 현상은 오래된 현상이지만, 요즘 들어서는 더 심해지는 것 같습니다. 이러한 고충을 얘기하는 주변 분들이 많아진 것으로 봐서 확실히 채용 문제가 점점 어려워 지는 것 같습니다.

이와 같은 불일치가 일어나는 원인이야 뻔하죠.

서로의 눈높이가 높기 때문입니다.

개발자는 좋은 직장을 구하기가 어려운 것이고, 회사는 좋은 개발자를 구하기가 어렵습니다.

이중에서 회사의 채용활동에 포커스를 해보려고 합니다.

과거에 한창 거품일 때는 개발자의 "개"자만 붙어도 일단 뽑아갔는데, 쓴맛을 좀 봤죠. 개발자가 다 같은 개발자가 아니라는 것을 알게 되었습니다. 개발자들의 퍼포먼스 차이는 최대 28배까지 난다는 조사도 있듯이 어설픈 개발자 뽑아봤자 해고도 못하고 골치덩어리라는 것을 알게 되었습니다. 그렇다고 좋은 개발자를 뽑기도 어렵습니다. 저도 소프트웨어 개발자 면접을 수백 명 이상 봐왔지만 실력 있는 개발자는 정말 찾기가 어려웠습니다.

또, 기업들은 단기적으로 성과를 낼 수 있는 경력 개발자를 뽑는데만 치중을 해서 채용 구조는 갈수록 왜곡이 되고 있습니다. 누구나 신입 시절이 있는데, 경력만 뽑아가면 신입은 언제 경력 개발자가 될 기회를 잡을 수 있을까요? 이러는 이유 중의 하나가 대부분의 회사가 신입 개발자를 제대로 키울 수 있는 능력조차 없다는 겁니다. 많은 경우 개발자가 알아서 일하면서 배우는 방식이고, 회사의 지원은 사수나 멘토 하나 붙여주고 도재 식으로 하나씩 가르쳐 주는 것이죠. 이 경우 선배와 후배간의 끈끈한 정이야 생기겠지만, 둘다 교육에 많은 시간을 쏟아야 하지만, 정작 가르쳐 주는 것은 그리 많지 않습니다. 

이런 식으로 2, 3세대 거쳐가면 즉, 회사가 7~10년쯤 지나게 되면 회사 초기의 지식들은 대부분 사라지고 개발자 인원수는 늘었으나 각자 또는 팀 별로 각개격파 형식으로 개발을 하고 있는 모습을 발견하게 됩니다. 그럼에도 회사 설립 초기보다는 엄청나게 낮은 생산성과 많은 커뮤니케이션 부재과 제품의 낮은 품질로 고민들을 하고 있죠. 

이러다 보니 그냥 경험 많은 경력사원을 선호하지만, 그렇다고 각개격파 식 개발 방법은 크게 바뀌지 않습니다. 이런 개발방식은 회사의 규모와 생산성이 반비례하기 때문에 더 이상 개발팀의 규모를 키울 수가 없습니다.

이러한 이유로 대부분의 소프트웨어 회사는 성장의 한계에 부딪치게 되는데, 개발자 인원수로 100명 내외를 못 넘기게 됩니다. 물론 이를 훨씬 넘기고 크게 성장한 회사들 중에서도 영업적으로 드라이브해서 덩치만 키워 놓은 회사들이 많습니다. 이런 회사도 결국 한계에 부딪히는 것은 마찬가지죠. 물론 모든 소프트웨어 회사가 덩치를 키워야만 하는 것은 아니지만, 성장을 위해서 덩치를 키워야 하는 회사들의 발목을 잡는 것은 사실입니다.

회사가 채용한 개발자를 제대로 활용하려면, 회사가 제대로 갖추고 있어야 합니다. 회사가 갖춰야 할 것을 한 줄로 표현 할 수는 없지만, 조직, 프로세스, 기반시스템, 개발문화 등을 제대로 갖추고 있어야 합니다. 이것도 회사의 규모와 성격에 알맞게 갖추고 있어야 합니다. 또 이는 개발자 개개인의 몫이라기 보다는 주로 경영자가 해야 할 일이 더 많습니다. 경영자들이 이에 대한 필요성을 깨닫는 것이 먼저 해야 할 일입니다. 

최고가 되지 마라

소프트웨어를 개발하는 개발자입니까?

주변을 한번 둘러보세요.

개발자 중에서 자신이 최고로 뛰어난 실력을 가지고 있습니까?

그렇다면 심각한 상황입니다. 

더 이상 배울게 없다면 도태될 것입니다. 시행착오를 통해서 배우게 될 가능성이 더 높아졌습니다.

뭔가 더 배울 수 있는 사람들이 있는 곳으로 옮기거나 주위에 자신보다 더 뛰어난 사람을 두십시오.

모든 분야가 아니더라도 특정 부분이 배울 수 있는 사람이 있어도 좋겠죠. 

주변에 항상 자신보다 뛰어난 사람들을 둬야 합니다.

뛰어난 사람의 행동 양식을 익히게 됩니다.

자신이 최고인 줄 알면서 살아온 10년보다 자신이 뭐가 부족한지 알고 뛰어난 사람에게서 배운 1년이 더 배울 것이 많다는 것을 알게 될 것입니다.

어차피 우리가 지금 배우고 있는 대부분도 뛰어났던 앞서간 사람들에게서 배우는 것이나까요. 

그리고 "자신이 최고인줄 착각하지 말자"라고 말하고 싶습니다. 설령 자신의 실력이 대단히 뛰어나다고 하더라도 배울 수 있는 대상을 찾을 수 있는 자세가 부족하다면 성장에 저해 요소가 되겠죠.

소프트웨어를 개발하는 끝내주게 좋은 방법

블로깅을 시작한지는 그리 오래 되지 않았지만 블로그 운영을 시작하면서 자연스럽게 인터넷에서 소프트웨어를개발에 대한 다양한 글들을 보게 되었습니다. 

대부분의 글들은 자신의 직,간접적인 경험에 의해서 작성되지만 모든 글들을 쓰면 그 백그라운드에 대해서는자세히 설명할 수가 없으므로, 글을 읽는 독자들은 오해를 하는 일들이 잦을 것으로 생각합니다. 즉 그 경험들과 지식들이 나에게 똑같이 적용이 되거나 도움이 될 것이라고 단순히 생각하는 오류가 벌어질 수도 있을 것 같습니다. 

그래서 제가 쓰는 글들은 자연스럽게 소프트웨어를 개발하는 기본 원리나 원칙에 포커스를 하고 있습니다. 수많은 소프트웨어 개발사와 개발자들을 만나면서 단순한 기법이나 툴의 사용보다 기본 원리를 익히는 것이 더중요하다는 것을 알게 된 것도 한 이유입니다. 그리고 그런 글들을 계속 읽다보면 자연스럽게 친숙해지면서 몸에 익는다면 소프트웨어를 개발하는데 도움이 좀 되지 않을까 생각합니다.

결국 끝내주게 좋은 방법은 없고 원리를 알고 나서 응용을 하는 것이 제대로 소프트웨어를 개발하는 방법이라고 생각합니다.

소프트웨어를 개발하는 기본 원리는 소프트웨어의 종류나 규모에 따라서 다르지 않습니다. 다르다면 원리라고할 수 없겠죠. 팩키지 소프트웨어나 펌웨어나 SI나 게임이나 기본 원칙은 다르지 않습니다. 단지, 현실에 응용이 될 때는 각각의 특성에 따라서 다양한 방법의 변화가 있을 수 있죠.

최대 30MM이나 50MM짜리 프로젝트만을 수행해 본 개발자는 그 테두리에서의 경험에 대해서만 얘기를 할수 있는데, 그 방법이 수백MM 규모의 프로젝트와는 맞지 않을 수 있을 것입니다. 수백MM짜리 규모의 프로젝트는 차원이 다르죠. 어설픈 방법으로도 소규모 프로젝트는 그럭저럭 수행이 될 수 있어도 규모가 그정도 커지만 요행을 바라기는 어렵습니다.

또, 주로 SI프로젝트나 외주 용역 프로젝트만 수행을 해 본 경험이라면 소프트웨어를 개발하는 기본 원리보다는 예를 들어 고객을 다루는 법, 계속 변하는 요구사항에 대응하는 법, 적당한 품질로 타협하는 법 등에 대해서더 많이 고민해 봤을 수도 있습니다.

저 또한 SI의 경험보다는 팩키지라던가 대규모 프로젝트의 경험이 더 많기 때문에 모든 분야를 다 경험해보고하는 얘기는 아닌 것이죠. 

결국 글을 일고 판단하는 것은 읽는 사람의 몫일 수도 있는데, 저의 괜한 기우일 수도 있겠네요.

판단은 스스로하고 너무 끝내주게 좋은 것을 찾으려고 하지는 맙시다.