맥에서 Subversion 사용하기

최근에 맥북을 구매해서 아이폰 개발 작업을 하고 있는데 맥에서 Subversion을 사용하는 환경이 그리 좋지 않다는 것을 알게 되었습니다. 그래서 맥에서 Subversion을 제대로 활용하기 위한 글을 적어보려고 합니다.

Subversion 자체에 대해서는 블로그의 다른 글들을 보시기 바랍니다.

일단 Xcode에는 기본적인 Subversion연동 기능이 포함되어 있습니다. 그런데 막상 써보면 기존에 TortoiseSVN의 뛰어난 기능과 성능에 익숙한 사람들은 불만스럽기 짝이 없습니다. 그래서 맥에서 Subversion을 쓰기 위한 방법을 비교해보도록 하겠습니다. 

• Xcode 기본 기능 
• 유/무료 맥용 SVN Client 사용 - Syncro, Diffly
• 터미널
• 가상머신 + TortoiseSVN 

Subversion 서버는 이미 구축되어 있다고 가정합니다. Subversion서버가 아직 구축되지 않았다면 제 책을 참조하여 Subversion을 구축하시기 바랍니다. 또는 Google Code를 이용하는 방법도 있습니다. Google Code를 이용하면 소스코드가 공개가 되니 소스코드를 공개해도 되는 경우라면 Google Code를 이용하면 편리할 것입니다.

Xcode의 기본 기능 사용

사실 Xcode의 기본 Subversion연동 기능은 그렇게 편리하지 않습니다. 그래도 사용법에 대해서 잠시 알아보죠.

우선 Xcode의 Preferences의 SCM항목에서 이미 구축된 Repository를 등록해야 합니다. 그래야 Xcode에서 해당 Repository와 Xcode 프로젝트를 연결 할 수 있습니다.

그리고 Xcode>SCM>Repositories에서 해당 Repository의 디렉터리를 만들어야 합니다. 

위 그림과 같이 branches, tags, trunk로 나누면 됩니다. 디렉터리를 어떻게 나누냐 하는 이슈는 전략이 필요한 항목이므로 신중하게 판단해야 합니다.

소스코드를 서버에 등록하기 전에 먼저 설정할 것이 있습니다. Subversion에 등록되면 안되는 파일을 설정해야 합니다. ~/.subversion/config파일을 열면 global-ignores 항목이 있습니다. 여기에 등록되면 안되는 파일의 패턴을 적어주면 됩니다. 저는 일단 build 디렉터리만 등록되지 않도록 했습니다. 그외에도 빌드시 생기는 임시 파일들이 있거나 하면 그 패턴을 등록해서 Subversion에 등록되지 않도록 해야 합니다.

그리고 Import 메뉴를 이용해서 Mac에 저장되어 있는 소스코드를 모두 Subversion 서버에 등록합니다. 

이제 서버의 소스코드를 내려 받아야 하는데, 기존에 소스코드가 있던 디렉터리에는 내려 받을 수 없으니 소스코드의 디렉터리를 임시로 바꿔놓고 Check out을 통해서 소스코드를 내려받습니다. 소스코드를 내려 받았다고 해서 Xcode와 바로 연결되지는 않습니다. Xcode연동 기능을 사용하지 않을 거라면 여기까지만 하면 되지만 Xcode와 연동해서 사용하려고 하면 Xcode Project와 Subversion repository를 연결해 줘야 합니다.

Xcode에서 Check out하여 내려 받은 프로젝트를 Open하고 Project info를 보면 우상단에 "Configure Roots & SCM..."이 있습니다.

그 버틑을 클릭하면 이미 등록한 리파지토리중에서 본 프로젝트와 연결한 리파지토리를 선택하도록 되어 있습니다. 간단하게 고르면 됩니다.

그리고 Groups & Files에서 마우스 오른쪽 버튼을 눌러서 SCM을 선택하면 SCM과 연동 상태를 확인할 수 있습니다.

이제 Xcode의 SCM 메뉴를 통해서 소스코드를 관리할 수 있게 됩니다.

기본적으로 소스코드를 Check out하고 Commit하고 Tag, brach까지 이 기능을 이용해서 할 수 있도록 되어 있습니다. 하지만 제가 간략하게 본 바로는 Conflict를 해결하고 Merge를 하는 등의 협업이 필요한 작업은 지원이안되는 것 같더군요. 혹시 제가 모르는 방법이 있다면 알려주세요. 

그래서 이럴 때는 다른 솔루션들을 추가로 사용해야 하겠더군요.

맥용 SVN Client 사용

Syncro, Diffly등 몇몇 유/무료 SVN Client가 있습니다. 하지만 이 부분은 제가 Evaluation을 해보지 않았습니다. 추후 써보게 되면 내용을 보강하도록 하지요.

터미널 사용

Command line에서 SVN을 사용할 수 있다면 Windows, Linux, Mac 어느 OS에서든지 동일하게 SVN을 사용할 수 있습니다. SVN의 모든 기능은 Command line에서 사용할 수 있도록 되어 있습니다. 단지 Merge등의 몇몇기능이 GUI환경에서 더 편한 것 뿐입니다. Mac에서도 Command line 명령어를 이용하여 SVN을 사용할 수 있습니다.

가상머신 + TortoiseSVN 사용

마지막으로 제가 최종적으로 선택한 방법은 TortoiseSVN을 이용하는 방법입니다.

Windows에서 TortoiseSVN을 오랫동안 사용한 개발자라면 그 편리함을 잊지 못할 겁니다.

저는 Parallels Desktop에 Windows7을 설치한 다음에 TortoiseSVN을 사용하고 있습니다.

Mac의 모든 디렉터리가 Windows에서 접근 가능하니 Windows에서 사용하는 것과 거의 동일하게 TortoiseSVN을 사용할 수 있습니다. 이렇게 하여 Windows에서 사용하던 Merge tool도 그대로 쓸 수 있게 되었습니다.

Windows에서 TortoiseSVN을 사용할 경우는 Mac에서 SVN을 설정하는 것과 별도로 Windows에서 SVN을 설정해줘야 합니다. C:\Users\{사용자ID}\AppData\Roaming\Subversion\config 파일을 열어서 아까와 같이 global-ignores를 설정하면 됩니다.

저는 기본적인 SVN Commit기능만 쓸때는 Xcode기본 기능을 사용하고 브랜치, 태그, 머지 기능을 사용할 때는 Tortoise SVN을 사용하고 있습니다. 또한 개발자가 여러명이라면 그냥 TortoiseSVN을 사용하는 것도 좋을 것 같습니다.

이상으로 Mac에서 Subversion을 사용하는 방법을 알아봤습니다. Subversion을 제대로 사용하는 방법은 완전히 별개 이슈이니 제 책과 블로그의 다른 글들을 참고하세요.

수정하거나 덧붙일 내용이 있으면 댓글 남겨 주세요.

개발자를 잘못 채용하는 방법

뛰어는 개발자를 보유하는 것은 소프트웨어 회사의 절대 필요 조건입니다.

뛰어난 개발자를 보유하는 방법은 내부 개발자들이 잘 성장할 수 있도록 좋은 환경과 기회를 제공하는 것도 중요하지만 기본적으로 뛰어난 개발자를 뽑아야 합니다.

적어도 능력은 B급 이상은 되야 입사 후 성장 가능성이 높습니다. 하지만 좋은 개발자들을 채용하는 것은 그렇게 쉽지 않습니다. 공채, 헤드헌터, 소개 등 갖가지 방법을 써도 쉽지는 않지만 흔히 잘못된 방법이 무엇인지는 쉽게 알 수 있습니다.

어떤 경영자들은 같이 일할 동료들을 개발자 채용 인터뷰에 참여시킵니다. 같이 일할 동료들이 보고 같이 일하기 좋은지 판단하라는 이유에서 입니다. 팀웍이 중요하다는 이유에서 입니다.

하지만 이 경우 잘되는 경우도 있지만 문제가 있는 경우도 많습니다. 기본적으로 같은 레벨에서 개발자를 평가하는 것은 쉽지 않습니다. 즉 인터뷰를 할 능력이 없는 사람에게 인터뷰를 맡기는 것과 비슷합니다. 그런 정도의 인성은 상급자들이 더 잘 볼 수 있습니다.

인터뷰에 참여한 개발자의 입장에서 보면 자신보다 뛰어난 개발자를 뽑는 것은 상대적으로 자신의 비중이 낮아지고 결국에는 자신에게 손해를 가져오기 때문에 본능적인 자기 방어차원에서 그런 개발자들의 채용에 반대하곤 합니다. 이유야 다른 곳에서 찾지요.

채용인터뷰는 특히 개발자 채용인터뷰는 CTO와 개발팀장 등 충분히 기술적인 면과 조직적인 면을 모두 볼 수 있는 사람이 해야합니다. 동료가 될 개발자들에게 인터뷰를 맡기는 것은 인터뷰의 책임이 있는 사람들이 기술적인 식견이 부족해서 기술적인 판단의 책임을 개발자들에게 전가하는 것일 수도 있습니다. 이런 경우 차라리 외부 전문가에게 부탁을 하는 것이 나을 수 있습니다.

개발자는 똑똑하며 긍정적인 사람을 뽑아야 합니다.

하지만, 현실에서는 경력직을 뽑을 때는 해당 분야에서 일해봤는지가 가장 채용의 조건이 되곤 합니다. 이런 개발자들이 똑같은 일을 하다가 똑같은 분야로 옮긴다는 것은 실력이 그리 뛰어나지 않고 그저 경험만 있을 가능성이 높습니다. 정말 일을 잘 했다면 이전 회사에서 더 좋은 대우를 받으며 더 오래 일 했을 겁니다. 뛰어난 개발자들이라면 이런 식으로 옮기지 않습니다. 자신의 미래에 도움이 되는 분야나 최신 기술을 배울 수 있는 곳으로 옮길 겁니다. 또한 퇴사 이전에 이미 누가 데려가지 이렇게 인력 시장에 잘 나오지를 않습니다. 

따라서 급하다고 동일 경력 개발자라는 이유만으로 뽑는 것은 며칠 전에 그만 두었거나 곧 그만둘 개발자의 대타는 될 수 있어도 장기적으로는 회사에 손해가 될 수 있습니다. 

결론은 항상 좋은 개발자를 뽑기 위해서는 당장 발등에 떨어진 불을 끄기 위해서가 아니고 평상시에 꾸준히 노력해야 한다는 겁니다. 그래서 당장 급해서 경력직을 뽑는 것보다 신입으로 미리 준비를 해서 꾸준히 키워 놓은 것이 더 좋은 결과를 가져올 때가 많습니다. 하지만 회사의 프로세스나 개발문화가 엉망이라면 위의 모든 것이 공염불이죠. 이런 경우는 어쩔 수 없이 발등의 불끄기 모드로 채용을 할 수 밖에 없습니다.

결국 악순환이 또다시 시작되는 거죠.

채용은 단발성으로 진행하지 말고 장기적인 안목을 가지고 꾸준히 노력해야 합니다.

소스코드는 어디 있나요?

나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다.

"소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다.

그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다.

대부분 아래와 같은 답변들이 돌아옵니다.

• 내 PC에 소스코드가 저장되어 있습니다. 
• 아직 정리가 안되서 소스코드관리시스템에 등록하지 않았습니다.
• 빌드는 IDE(Eclipse 등)에서 해야 합니다.
• 빌드하기 위해서는 이런 저런 라이브러를 알아서 직접 설치해야 합니다.
• 아참, 설정을 이렇게 바꿔야 하는데 깜빡했습니다.
• 지금 내가 소스코드를 고치고 있어서 공유가 어렵습니다.

이런 얘기가 진행되는 동안에 일은 정상적으로 진행이 되지 못하고 여러 번 만나서 대화로 소스코드 공유 문제를 해결해나가야 합니다. 

혼자서 또는 개발자들끼리 익숙해져서 나름대로 방식으로 소스코드를 관리하면서 스스로 아무 문제가 없다고 생각하고 있는 개발자들은 냄비 안에서 물이 점점 뜨거워져서 죽는 개구리처럼 소스코드관리 문제가 점점 커져서 문제가 얼마나 심각한지 인식하고 있지 못하고 있는 겁니다. 이는 기본 중에 기본으로 자꾸 소스코드 관리 문제를 가지고 얘기를 하면 민망하고 한심하기도 합니다.

소스코드를 꽉 쥐고 요청하는 사람들에게 '모이'주듯이 하나씩 던져 주는 개발자들은 이로 인해서 얼마나 많은 자신의 시간을 낭비하고 있고 정작 자신이 제대로 개발할 시간은 모자라고 회사에도 손해를 끼치며 자신의 발전도 가로막는다는 것을 알아야 합니다.

정상적인 경우는 다음과 같습니다.

개발자가 1명이든 100명이든 1000명이든 상관없이 모든 소스코드는 당연히 소스코드관리시스템에 등록이 되어 있어야 합니다.  구차하게 이거 저거 물어보지 않아도 소스코드가 저장된 경로만 알면 누가나 소스코드를 Check out해서 클릭 몇 번이면 Build Script를 찾아내서 즉시 빌드를 할 수 있어야 합니다. 당연히 컴파일러 등의 빌드 환경은 설치가 되어 있어야죠. 여러명이 동시에 소스코드를 마구 고쳐도 전혀 걱정할 필요가 없어야 합니다.

이때 구차하게 이거 저거 물어 봐야 빌드가 되고 IDE를 실행 해야 하고, 빌드 중간에 명령어를 입력해야 하는 등의 바로 알기 어려운 행위들을 해야 하면 안됩니다.

이 정도는 되어 있어야 Daily Build가 가능해지고 프로젝트 내내 소스코드 관리 비용을 최소화 할 수 있습니다.

이 정도는 되어 있어야 엄청 복잡한 소스코드 상황을 깔끔하게 관리할 수 있습니다.

이 정도는 되어 있어야 내가 휴가를 가도 아무나 빌드를 할 수 있습니다.

이 정도는 되어 있어야 개발자들이 빌드를 하지 않고 빌드 담당자에게 빌드를 맡길 수 있습니다.

이 정도는 되어 있어야 누구와도 심지어는 외부인과도 협업을 할 때 말 한마디면 소스코드 공유 준비는 끝납니다.

이 정도는 되어 있어야 개발자는 진짜 개발에 집중할 수 있습니다.

이게 뭐 큰 일이냐라고 생각할지 모르지만 이렇게 생각하는 개발자는 위에서 얘기한 기초 중의 기초가 안되어 있다고 생각하면 됩니다.

소스코드 관리는 워낙 기초이기 때문에 누구나 제대로 방법만 익히면 제대로 수행하는데 오래 걸릴 일도 아닙니다. 똑똑한 개발자라면 일주일이면 방법을 다 터득합니다. 분석, 설계 작업이 방법을 제대로 익히고도 제대로 하는데 수년이 걸리는 것과는 안전히 딴판입니다. 그럼에도 아직도 많은 개발자들이 소스코드 관리를 제대로 하고 있지 못하거나 제대로 하려고 흉내는 내는데 엉뚱한 곳에서 헤매는 경우가 많습니다. 원리는 매우 간단한데 말입니다.

소프트웨어 개발이라는 것이 협업이라는 것을 깨달으면 됩니다. 혼자서 개발하더라도 협업과 똑같습니다. 그렇게 해야 더 혼자 개발하더라도 더 빨리 개발할 수 있고 여럿이 개발할 때는 더욱 더 중요합니다.

소스코드관리시스템을 쓰기는 하는데 어중간하게 흉내만 내고 있다고 생각한다면 한번 확실하게 제대로 배워 놓을 필요가 있습니다. 그렇지 않으면 평생 기초 중에 기초에 문제거리를 안고 가는 겁니다.  

개발문서를 만들기는 했는데 업데이트가 안되는 이유

필자는 여러 소프트웨어 회사들의 컨설팅을 진행하면서 먼저 회사의 분석을 위해서 그 동안 소프트웨어를 개발하면서 만들어 놓은 문서를 요구합니다. 사실 문서만 봐도 회사의 개발현황을 대부분 알 수 있습니다.

그런데, 제대로 작성된 문서를 제시하는 회사는 거의 없다시피 합니다. 물론 Wiki나 Google Docs등의 온라인 문서를 포함해서 제대로 작성된 문서는 거의 없습니다. 가끔 문서를 제시하는 회사들이 있기는 하나 수년간 전혀 업데이트를 하지 않아서 쓸모가 없어진 것들 뿐입니다. 

정리를 해보면 다음과 같습니다. 

• 문서가 아예 없거나 없다시피 한 회사
• 몇 년동안 업데이트 안된 문서들만 있는 회사 (오늘의 주제)
• 쓸모없는 문서들을 너무 많이 만든 회사 

야심차게 문서 한번 잘 만들어보겠다고 결심하고 개발 시에 문서를 열심히 만든 후에 소프트웨어는 계속 업그레이드가 되는데 문서는 과거에 머물러 있는 경우에 대해서 얘기를 해보겠습니다.

이런 문서는 죽은 문서입니다.

내용이 맞는지 틀리는지 확인이 안되는 문서는 혼동을 일으킬 수 있습니다.

이런 일이 발생하는 이유는 여러 가지가 있지만 대표적인 이유로는 진짜 문서가 필요해서 만들었다기 보다는 문서가 필요하다고 하니까, 또는 위해서 시켜서 만들었는데, 막상 개발에 크게 도움이 안되고, 단순히 문서를 만들었다는데 의의를 두는 경우가 있습니다. 또, 문서를 너무 잘(많이) 만들어서 소프트웨어가 업그레이드 될 때마다 문서를 갱신하려고 하니 초기 개발 때에 비하여 유지보수 시는 급하게 개발하는 요청이 많아서 미처 문서까지 갱신할 시간이 없는 경우도 있습니다.

이런 경우 모두다 "문서를 위한 문서"인 경우입니다.

문서가 진짜 필요해서 만든 경우가 아니라는 얘기입니다. 역량이 충분히 성숙되기 전에 문서 작성 문화를 정착하려면 어떻게 해야 할까요?

문서를 적게 만들어야 합니다. 

적게 만들면서도 개발에 유용해야 합니다. 그래야 문서를 만드는 일이 프로젝트에 큰 부담이 되지 않고, 추후 업데이트가 가능해집니다.

오래 되어서 쓸모 없어진 문서를 책꽂이에 잔뜩 꽂아 놓고 "옛날에는 문서를 열심히 만들었는데"하고 회상 하십니까? 지금은 그렇게 하고 있지 않다면 효과적이지 않은 방법으로 문서를 만들면서 조직 내에 정착되지 못한 겁니다. 문서 작성을 문화로 정착하려면 "작고 효율적으로 문서 만드는 법"을 익혀야 합니다.

왠만한 크기의 프로젝트도 문서는 한 두 개로 충분합니다. 스펙문서(SRS)와 경우에 따라서 설계문서 정도를 만들면 됩니다. 스펙문서는 요구사항을 분석하는 방법, 꼭 필요한 내용을 적는 방법, 리뷰하는 방법 등을 익혀야 합니다. 요즘은 스펙을 적는 방법에 있어서 다양한 시도들을 하고 있지만, 방법은 조금씩 달라도 꼭 필요한 내용을 빠짐없이 효과적으로 적어야 합니다.

[이벤트 결과] 도서 증정 - "소프트웨어 개발의 모든 것"

지난 일주일간 아래와 같이 이벤트를 진행했습니다.

제목 : 저자 사인 도서 증정 이벤트(소프트웨어 개발의 모든 것, 페가수스)

기간 : 2010-03-05(금) ~ 2010-03-14(일)

대상 및 배송 방법 : 이벤트 기간안에 "소프트웨어 개발 역량 분석 서비스"를 이용한 독자 중에서 이벤트 기간 종료 후 20명을 추첨하여 착불 택배로 보내드립니다.

주의사항 : 회사 및 담당자 정보를 입력하실 때 책을 배달 받을 "주소"를 꼭 입력해주시기 바랍니다. 주소를 모르면 책을 보내드릴 수가 없습니다.^^ 

많은 분들이 응모를 해주셨습니다. 그 중에서 주소를 입력해주신 분들 중에서 20명을 무작위로 추첨하였습니다.

모든 분들에게 책을 보내드리면 좋겠지만, 저자도 자신이 쓴 책을 사야하기 때문에 모든 분께 보내드리지 못해서 죄송합니다.

책은 보내드리지 못하는 분들도 설문 내용을 분석한 보고서는 순서대로 보내드리도록 하겠습니다. 보통은 바로 보내드리는데 접수자가 많아서 시간이 조금 걸리니 양해 부탁합니다.

그런데, 택배를 보내려고 하니 수취인의 전화번호가 없으면 인터넷으로 택배 접수가 안되더군요. 

그래서 각 당첨자에게 메일을 보내서 휴대전화 번호를 접수 받았습니다. 

아직 다섯분의 메일은 받지 못했습니다. 혹시 이글을 보시면 메일을 확인해보시고 제게 휴대전화 번호를 보내주시기 바랍니다.

당첨된 20분은 다음과 같습니다.

윤아* 서울시

김명* 서울시

김수* 서울시

신현* 서울시

김종* 서울시

이준* 서울시

이상* 경기도

이종* 서울시 

남종* 수원시

윤민* 서울시

김재* 서울시

손봉* 경기도

한성* 서울시 

고형* 경기도 수

강한* 경기도

장진* 서울시

이지* 경기도 휴대전화 번화 미접수

김강* 서울시 

조석* 서울시

조명* 경기도

빨리 망해서 없어져야 할 회사들

소프트웨어 업계에는 빨리 망해야 서로 도움이 되는 회사들이 매우 많지만 악착같이 버티면서 소프트웨어 생태계를 좀먹고 있습니다. 이렇게 좀비화 된 "좀비 회사"들은 또다른 "좀비 회사"를 만들어 내는 악순환의 고리를 만듭니다.

뛰어난 기술이나 별다른 경쟁력 없이 오로지 생존력만 가지고 시장을 갉아 먹는 회사들은 빨리 빨리 사라져 줘야 합니다. 즉, 망할 회사는 빨리 망해야 우리 모두가 삽니다.

정부지원으로 버티는 회사

정부의 지원은 이를 통해서 기술을 개발하고 소프트웨어 산업의 밑거름이 되라는 것이지 이것으로 연명하라는 것이 아닙니다. 하지만 예나 지금이나 기술 개발보다 떡밥에 관심있는 회사가 많습니다. 

이런 회사들의 엉터리 기술은 시장을 교란하고 가격 체계를 무너뜨리곤 합니다.

아직 미성숙한 소프트웨어 산업을 키우기 위해서 정부 지원이 필요한 것은 사실이지만, 종종 역효과가 일어나곤 합니다. 그래서 차라리 이럴바에는 정부에서는 그냥 내버려 두는게 나을 수도 있습니다.

방해도 하지 말고 도와주지도 않는 것이 소프트웨어 업계에는 도움이 될 수 있습니다.

덤핑을 일삼는 회사

기술이 부족하다보니 모든 bidding에 덤핑으로 대응하는 회사들도 있습니다. End user market이 매우 작은 우리나라에서 이런 덤핑의 일상화는 물귀신 작전이 아닐 수 없습니다. 덤핑도 전략이라고 말할 수 있지만, 이렇게 시장이 교란되고 나면 그 피해는 고스란히 소프트웨어 업계 전체에게 돌아갑니다.

덤핑은 이런 회사 뿐만 아니라 대기업들간에도 흔히 발생하는데, 시장에서의 지위와 자본력을 내세워 경쟁자를 망해버리게 하려는 덤핑은 법으로도 금지되어 있지만, 소프트웨어 업계에서는 유명무실이더군요. 그렇게 시장을 차지해봤자 소프트웨어 업계에서는 별 재미를 못보는게 일반적입니다.

대마불사

회사의 덩치를 잔뜩 키워 놓고 마음대로 죽지 못하게 만드는 방법입니다. 회사가 망하면 대한민국 경제에 악영향을 끼치기 때문에 정부에서 망하게 가만히 두지 않을 것이라고 기대하곤 합니다. 물론 로비도 잘 해야겠죠. 또한 고객들이 워낙 많아서 담당자들이 유지보수 때문에 망하게 놔두지를 않습니다. 발목잡힌 거죠. 

투자는 없이 개발자를 혹사해서 연명하는 회사

여기에 해당하는 회사는 너무나 많은 것 같습니다. 투자는 하지 않고 특별한 기술력 없이 오로지 개발자들의 개별 전투력에 의존하여 저가수주 후에 개발자들의 끊임없는 야근으로 버텨나가는 회사입니다.

기술에 투자를 하지 않기 때문에 회사의 기술력은 발전하지 않고 개발자들이 오래 버티지 못하고 나가면 그나마 축적된 노하우도 쉽게 유출되고 맨날 이런식으로 몸으로 때우는 회사들입니다. 회사나 개발자나 미래가 없는거죠.

임금 돌려막기

위의 회사들에 해당하기도 하지만 직원들의 임금을 정상적으로 지급하지 못하면서 다음달 영업하여 체불 임금을 지급하고 이런 현상이 장기화 되는 회사입니다. 벤처기업에서 단기적으로 이런일을 겪을 수도 있고 직원들이 이런 어려움을 서로 감내해서 극복할 수도 있지만, 이런 일이 일상화되고 장기화되면 회사는 자꾸 안좋은 비즈니스라도 단기적으로 직원들의 임금을 지급하기 위해서 수주를 해야 하는 악숙환이 반복됩니다. 기가 막히게 이를 극복하면 좋겠지만, 거의 대부분 회사나 개발자들에게 상처만 남는 경우가 많죠.

이 외에도 빨리 망해서 없어져야 소프트웨어 업계에서 일하는 우리 모두가 행복해지는 회사들은 매우 많을 겁니다. 어떤 회사들이 있을까요? 여러분들의 의견을 적어주세요.

[이벤트 종료] 도서 증정 - "소프트웨어 개발의 모든 것"

안녕하세요. 블로그 독자 여러분! 

대한민국의 소프트웨어 토양에 좋은 밑거름이 되고자 하는 제 블로그에 많은 호응을 해주셔서 감사드리며 이에 보답코저 아래와 같이 이벤트를 실시합니다. 많은 참여 바랍니다.

제목 : 저자 사인 도서 증정 이벤트(소프트웨어 개발의 모든 것, 페가수스)

기간 : 2010-03-05(금) ~ 2010-03-14(일)

대상 및 배송 방법 : 이벤트 기간안에 "소프트웨어 개발 역량 분석 서비스"를 이용한 독자 중에서 이벤트 기간 종료 후 20명을 추첨하여 착불 택배로 보내드립니다.

주의사항 : 회사 및 담당자 정보를 입력하실 때 책을 배달 받을 "주소"를 꼭 입력해주시기 바랍니다. 주소를 모르면 책을 보내드릴 수가 없습니다.^^ 

        

단, 이미 "소프트웨어 개발 역량 분석 서비스"를 이용한 분들은 제가 보내드린 "분석 보고서"를 제게 답장으로 보내면서 주소도 같이 적어서 보내주시면 추첨 대상에 포함하도록 하겠습니다.

감사합니다.