깨끗한 개발 환경, 빌드 환경, 테스트 환경

개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다.

이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다.

따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다.

일반적인 경우 빌드는 깨끗한 환경에서 항상 원하는 빌드를 만들어 낼 수 있도록 하며, 테스트는 스펙에서 요구하는 테스트 요구사항에 따라서 각각의 테스트 환경을 구축해야 합니다. 여러 플랫폼을 지원하는 경우 테스트 환경 구축이 아주 복잡하고 비용이 많이 들기도 합니다. 테스트 환경에 대한 이해는 많이들 하고 있다고 가정하고, 빌드 환경에 대해서 조금 더 얘기를 해보고자 합니다.

빌드가 무엇인지 먼저 얘기를 해보죠. 개발자 Visual Studio나 Eclipse 같은 IDE을 이용해서 빌드하는 것은 여기서 말하는 빌드는 아닙니다. 여기서 말하는 빌드는 공식 빌드입니다. 공식 빌드는 Release를 위해서 빌드하는 것을 말합니다. 개발자들이 하는 빌드는 그냥 개발의 일부이죠.

많은 개발자들이 자신의 개발 환경에서 그냥 빌드한 결과물을 묶어서 제품을 만들어 고객에게 전달하곤 합니다. 그렇게 되면 IDE의 빌드 설정에 따라서 빌드의 결과가 달라져서 예기치 못한 문제가 발생하기도 하고, 개발자가 퇴사하고 새로운 개발자가 빌드를 하려고 하니 빌드가 안되기도 합니다. 또는 개발자 PC의 환경에 영향을 받아서 개발자 PC에서는 잘 동작했으나, 고객의 환경에서는 문제가 발생하기도 합니다.

각각의 환경의 관리는 개발팀, B/R팀, 테스트 팀이 맡고 있고 함부로 건드리지 못합니다. 

지금까지 이러한 구분없이 개발을 하고 계셨다면 혹시 이로 인한 문제는 없었는지 생각해보세요. 없었다면 정말 운이 좋은 겁니다. 시스템이 점점 커지고 고객이 많아지는데도 계속 운만을 바랄 수는 없겠죠. 

소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?

그동안 약 2달에 걸쳐서 제 블로그에서 Poll을 실시하여 이와 같은 결과가 나왔습니다. 

이런데 이상하게 제가 현장에서 만나는 여러사람들의 의견과 다른 결과가 나왔습니다.

그래서 그 이유를 2가지 정도로 추측해보고 있습니다.

첫째, 블로그 방문자들(주로 블로거)은 비 방문자보다 소프트웨어 공학에 더 많은 지식과 경험을 을 가지고 있다.

둘째, 실제 자신의 경험에 의한 생각보다는 정답이라고 생각하는 것에 투표를 하였다.

물론 첫째 이유겠죠 ^^

아래 목록을 보면 각 항목의 득표 비율이 나오는데, 제 생각과 크게 다르지 않습니다. 

하지만, 유난히 유지보수에 대해서 작게 나온 것은 대부분의 방문자들이 유지보수가 그렇게 중요하지 않은 프로젝트들을 수행하고 있는 것이 아닌가 추측해 봅니다. 

다음 투표로는 SCM 사용도에 대해서 진행을 하려고 합니다. 많은 성원부탁합니다.

Daily Build를 하십니까?

Daily Build는 많은 혜택을 줍니다.

소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며

모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다.

요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다.

여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다.

하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요.

저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Build를 할 수 있어야 한다고 생각합니다.

기본적인 개발 Stage를 사용하던, Iteration을 쓰던 간에 설계의 결과물은 빌드가 되어야 한다는 것입니다. TDD를 사용할 경우 Test 코드를 먼저 작성을 하기 때문에 빌드가 가능합니다. 테스트는 통과를 하지 못하더라도 말입니다. 즉 껍데기, Class, Public function의 Prototype을 정해 놓고 빌드가 가능한 상태로 만들어 놓고 구현을 시작합니다.

이때 SCM에 Baseline을 한번 설정을 하고 소스코드의 내용을 채워 나가기 시작합니다. Daily Build의 혜택을 누리기 위해서는 소스코드를 빌드 가능한 상태로 만들어 놓고 시작을 해야 합니다.

서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System)

소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다.

이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다.

만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다.

그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단하게 예를 들어 보겠습니다. 여기서 예라고 하는 이유는 계속 개량 발전시켜나면 연동하는 것들은 점점 늘어나고 자동화 되면서 효율은 더욱 높아지기 때문입니다.

물론 이 외에도 사용하는 기반시스템들도이 있지만, 아래 그림이 소프트웨어 회사라면 필수록 필요한 최소한만 추린 것입니다. 

  

각각의 연동 방식이나 자세한 내용은 많은 양이므로 추후 하나씩 설명하도록 하겠습니다.

그리고 하나하나의 운영 방법도 다양하고 계속 발전하고 있어서 자신의 회사에 적당한 방법을 찾아야 합니다.

이렇게 서로 연동되고 있지 않으면 자동화 될 수 있는 일에 괜히 시간과 노력을 들이고 있는 겁니다. 그렇게 된다면 개발자들은 개발을 해야 할 소중한 시간에 쓸데 없는데 시간을 허비하고 실수에 의한 사고 가능성도 높아집니다. 또 오랫동안 개발 정보가 쌓여도 그리 효율적으로 활용되지 못합니다. 

일단 이런 식으로 잘 갖추워진 기반시스템 하에서 개발을 하다보면 과거의 방식으로는 도저히 돌아갈 수 없고, 과거에 왜 그렇게 개발을 하면서 시간을 낭비했는지 안타까운 마음이 생길 겁니다.

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

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

 

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

 

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

 

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

 

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

 

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

 

4D (Difficult, Dirty, Dangerous, Dreamless)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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