본문 바로가기

분류 전체보기

사업부가 소프트웨어 조직에 미치는 영향 주변 소프트웨어 회사에서 사업부 형태의 조직을 접하는 것은 어려운 일이 아닙니다. 사업부라는 조직 구조가 꽤 인기를 끈 것은 사실입니다. 사업부란 특정 시장에 집중하고 시장의 요구에 빠르게 대응하기 위해서 만든 특수한 형태의 조직입니다. 보통 사업부는 상당히 많은 독립권을 가지고 있고 대부분의 결정을 사업부 내부에서 독립적으로 할 수 있습니다. 하지만 작은 회사를 사업부로 나눠서 각 사업부에 독립적인 책임과 권한을 주게 되면 득보다 실이 더 많아집니다. 하지만 사업부가 가지고 있는 단기적인 성과에 대한 욕심 때문에 사업부 조직 형태에 현혹이 되곤 합니다. 하지만 장기적으로는 잃는 것이 더 많을 수 있습니다. 사업부는 장점도 가지고 있는 조직 구조이지만 다음과 같은 단점들을 가지고 있습니다. 사업부 간에 .. 더보기
개발자 5적 소프트웨어 회사의 가장 중요한 자산은 개발자입니다. 개발자는 회사를 흥하게도 하지만 망하게도 합니다. 안타깝게도 우리 주변에는 좋은 개발자보다 나쁜 개발자가 더 많습니다. 초년병 때는 대부분은 좋은 개발자이거나 좋은 개발자가 되려고 합니다. 하지만 시간이 흐를수록 주변의 환경 때문이던 본인 때문이던 나쁜 개발자가 더 많아집니다. 내가 생각하는 가장 나쁜 개발자는 다음과 같습니다. 자신의 지식을 남에게 공유하지 않는 개발자 다른 개발자를 도와주지 않는 개발자 개발보다 정치에 관심이 많은 개발자 자기 개발을 위해서 노력하지 않는 개발자 경영자, 관리자, 동료와 자신을 속이는 개발자 안타깝게도 이러한 개발자는 쉽게 구분하기 어렵거나 회사가 이러한 개발자에 완전히 종속되어서 어쩔 수 없는 경우가 대부분입니다. .. 더보기
빌딩과 개집 시중에는 넘쳐나는 수많은 소프트웨어 개발 방법론이 있습니다. 지금까지 알려진 방법론만 100가지가 넘습니다. 인터넷에서 이에 대한 설명만 보고 Template만 복사해 와서 회사에 적용하기에는 무리가 있습니다. Template과 Sample만 보면 방법론을 적용하여 선진 개발 방식을 따라 할 수 있을 것 같지만, 이는 착각입니다. 방법론 자체가 잘못되지 않았음에도 잘못된 방식으로 오해를 하여 적용을 하거나 특정 부분에 집착하여 전체를 놓치는 경우가 많습니다. 집을 짓는데 빌딩을 만드는 방법을 적용하면 안되고, 그렇다고 개집을 만들 때처럼 대충 지어서도 안 됩니다. 개집을 만들 때는 대충 만들어도 되고, 안되면 다시 만들면 됩니다. 빌딩을 만들 때는 한치의 오차도 없이 정확하고 복잡한 방법을 사용해야 합니.. 더보기
개발자 채용 시 코딩테스트를 하시나요? 연기자나 가수를 뽑을 때 오디션을 보듯이 개발자를 채용할 때는 코딩테스트가 꼭 필요합니다. 하지만 코딩테스트를 하지 않고 채용하는 경우가 매우 흔합니다. 이력서를 통해서 그 개발자가 과거에 참여했던 프로젝트가 무엇인지 보고 인터뷰에서 이거 저거 물어보는 것만 가지고는 개발자의 실력을 평가하기는 아주 부족합니다. 코딩 테스트는 다음과 같이 3가지 타입으로 진행할 수 있습니다. 첫째, 인터뷰를 하기 전에 E-mail을 통해서 코딩테스트 과제를 전달할 수 있습니다. 이때는 시간이 반나절이나 하루 정도 걸리는 과제를 줄 수 있고 꽤 많은 내용을 점검할 수 있습니다. 단순히 로직 뿐만 아니라 코딩 습관, 최적화 시도, 소스트리, 빌드 스크립트 등 다양한 실력을 엿볼 수 있습니다. 1차에 끝나는 경우도 있고, 시험.. 더보기
하루 8시간 일하시나요? 하루에 8시간 일하시나요? 그렇다고 프로젝트 일정을 예측할 때 하루 8시간 일을 하는 것으로 계산하십니까? 그러면 프로젝트 일정을 지키기 어려울 것입니다. 보통 아무리 집중해서 일을 한다고 해도 하루에 80% 일하기 어렵습니다. 나머지 20%의 시간은 회의를 하고, 커피도 마시고, Email도 봐야 합니다. 또 2개의 프로젝트에 4시간씩 할당이 되어 있어도, 업무 전환 비용(Context switching cost)를 무시할 수 없습니다. 물론 프로젝트 일정은 프로젝트 관리자 혼자서 마음대로 정할 수가 없습니다. 실제 업무를 담당할 담당자들의 도움을 받아서 일정을 산정하게 됩니다. 이때 담당자들이 산정한 일정을 그대로 받아들이나요? 아니면 스스로의 버퍼를 따로 두시나요? 저는 하루의 업무시간을 보통 8시.. 더보기
소프트웨어 회사가 기본적으로 갖춰야 할 것 소프트웨어 회사가 처음에 작은 규모에서 시작할 때는 제품도 빨리 만들어 내고, 품질도 좋으며 생산성이 높습니다. 눈빛만 봐도 서로 무슨 생각을 하고 있는지 알고 생산성이 대단히 높습니다. 이런 과정을 거쳐서 회사가 점점 커져나갈 때 그 규모에 알맞은 준비를 하지 않으면 심각한 문제를 겪게 됩니다. 그럼 소프트웨어 회사가 기본적으로 갖춰야 할 것은 무엇일까요? 바로 조직, 프로세스, 기반시스템 그리고 사람과 개발문화입니다. 회사가 작을 때는 달랑 사람만 가지고 시작을 하곤 합니다. 이 때는 사람이 모든 Risk를 다 감당해야 하지만 작은 조직에서는 큰 문제가 되지 않습니다. 커뮤니케이션이 원활하고 모든 이슈들이 핸들링하기에 충분히 작기 때문입니다. 하지만 회사가 커지기 시작하면 상황은 달라집니다. 커뮤니케.. 더보기
다 만들었어요. 이제 테스트만 하면 되요. 소프트웨어를 개발하는 회사에서는 자주 듣는 말입니다. 그런데, 이 테스트가 언제 끝날지 모르는 경우가 많습니다. 소프트웨어 개발 컨설팅을 하면서 정말 놀란 것 중의 하나가 대부분의 회사가 릴리즈 시 "알파", "베타", "RC", "GA", "FCS"와 같은 단계를 거치지 않는 다는 것이었습니다. 대부분이 알파수준의 소프트웨어를 만들어서 만족스러울 때까지 테스트와 수정을 동시에 병행한다는 것이었습니다. 이는 큰 회사나 작은 회사나 별 차이가 없었습니다. 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분 없이 일을 진행하다가 적당한 시점에서 한번의 테스트를 통해 제품을 완성하려고 합니다. 이를 빅뱅(Big bang) 테스트라 하는데 이 방법이 운 좋게 개발 기간을 단축시켜 줄지도 모른.. 더보기
소프트웨어 공학이 왜 필요하지? 복잡하기만 한데... 소프트웨어 공학 블로그를 운영하고 있으면서도 전면에는 소프트웨어 공학이라는 말을 사용하고 있지 않습니다. 그 이유는 소프트웨어 공학은 막연하고 왠지 모르게 문서도 많이 만들어야 할 거 같고, 절차도 엄격히 따라야 할 것 같아서 부담스러운 느낌을 줄 수 있기 때문입니다. 이것이 다 소프트웨어 공학에 대한 오해에서 비롯된 것 같습니다. 이미 유행이 한번 쓸고 지나간 CMMI나 외국의 유명한 방법론들을 도입했다가 실패한 경험과 소문들 때문일 겁니다. Naver 백과사전에서 소프트웨어 공학을 찾아봤습니다. 다음과 같이 설명되어 있더군요. 요약 컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을.. 더보기
티스토리 독립도메인으로 이동 전과정 정리 블로그를 시작한지는 얼마 안되었지만, "독립도메인을 사용해야 하는데"라는 생각만 가지고 있다가 오늘 과감하게 이동을 했습니다. 그러고 나니 할일이 꽤 많더군요. 그래서 독립도메인 설정과정을 한번 주욱 정리를 해봤습니다. 아직 새싹 블로그라서 이동하는데는 큰 문제가 없었지만, 혹시 많은 독자 때문에 이동이 어려운 블로거가 있다면 참조하세요. 1. 도메인 신청(구매) 도메인은 알아서들 구매하시면 되겠죠. ^^ 도메인 설정에 대해서는 다 아시겠지만, 일반 독자를 위해서 조금 설명을 해봅니다. 도메인이라는 것은 소유의 개념이 아니고 사용권을 획득하는 것으로써 매년 사용료를 지불해야 합니다. 제가 구매한 도메인은 allofsoftware.net입니다. 16,500원/년(VAT포함)을 주고 KT호스팅에서 구매를 했.. 더보기
효과적인 버그 처리 방법 HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다. 의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다. 개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다. 주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다. 여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠. 개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기.. 더보기

티스토리툴바