본문 바로가기

개발문화

문서화 딜레마 우리나라 소프트웨어 회사 중에서 문서를 제대로 작성하고 있는 곳을 찾기란 그리 쉬운 일이 아닙니다. 제대로 작성한다는 의미는 꼭 필요한 만큼 적절히 효과적으로 작성하는 것입니다. 대부분의 소프트웨어 회사는 변변한 문서 하나 없이 개발을 하고 있고 반대로 소수의 회사는 불필요한 문서를 잔뜩 만들어서 오히려 효율성을 떨어뜨리고 있습니다. 물론 제대로 하고 있는 회사도 있지만 그 수는 극히 적습니다. 대부분의 여러분들도 겪은 현상이거나 앞으로 겪을 것입니다. 변변한 문서하나 제대로 만들지 않고 소프트웨어를 개발하고 있는 회사는 구멍가게 이상의 규모로 성장하기 어렵습니다. 회사의 규모가 커지면서 문서가 부족하면 커뮤니케이션 비용이 기하급수로 증가하기 시작합니다. 회사가 작았을 때 숨어있던 문제들이 마구 터져 나.. 더보기
내가 지금 하고 있는 일의 가격 개발자 여러분... 아침에 출근하셔서 여러분들이 하루종일 일하는 업무의 가격을 생각해보신 적이 있으신가요? 이것을 여러분의 "하루의 부가가치"로 생각을 하죠. 여러분의 연봉은 "하루의 부가가치" x "일년동안 일한 날"에서 회사에서 여러분에게 사용한 비용을 제하면 됩니다. 대기업은 보통 60~70%를 비용으로 제하면 되고, 중소기업들은 30~50%정도의 비용이 듭니다. 여러분은 자신이 만들어 내는 부가가치에 비해서 높은 연봉을 받고 있나요? 낮은 연봉을 받고 있나요? 회사입장에서는 연봉보다 높은 부가가치가 있는 개발자를 더 많이 보유하기를 원하고 있습니다. 물론 이보다 좀더 복잡하기는 합니다만 일단 간단히 생각해보죠. 여기서 문제는 "하루의 부가가치"가 얼마나 되는지 측정하기 어렵다는 겁니다. 특히 여러.. 더보기
개발자를 잘못 채용하는 방법 뛰어는 개발자를 보유하는 것은 소프트웨어 회사의 절대 필요 조건입니다. 뛰어난 개발자를 보유하는 방법은 내부 개발자들이 잘 성장할 수 있도록 좋은 환경과 기회를 제공하는 것도 중요하지만 기본적으로 뛰어난 개발자를 뽑아야 합니다. 적어도 능력은 B급 이상은 되야 입사 후 성장 가능성이 높습니다. 하지만 좋은 개발자들을 채용하는 것은 그렇게 쉽지 않습니다. 공채, 헤드헌터, 소개 등 갖가지 방법을 써도 쉽지는 않지만 흔히 잘못된 방법이 무엇인지는 쉽게 알 수 있습니다. 어떤 경영자들은 같이 일할 동료들을 개발자 채용 인터뷰에 참여시킵니다. 같이 일할 동료들이 보고 같이 일하기 좋은지 판단하라는 이유에서 입니다. 팀웍이 중요하다는 이유에서 입니다. 하지만 이 경우 잘되는 경우도 있지만 문제가 있는 경우도 많습.. 더보기
Google을 이끄는 힘 아이디어 내면 "네가 한번 만들어봐" 소프트웨어 업계만큼 아이디어가 넘치는 곳도 찾기 어렵습니다. Google이 탄생하게 만든 힘도 아이디어이고, Google이 지속 성장하여 지금이 Google이 된 힘도 아이디어입니다. Google에서는 업무시간의 20%는 새로운 아이디어를 생각하거나 준비하는데 사용할 수 있고 좋은 아이디어만 있다면 얼마든지 시도해 볼 수 있습니다. Google이 풍족하기 때문에 그렇게 할 수 있다고 말하는 사람들도 있지만, 이는 닭이 먼저냐? 달걀이 먼저냐?의 이슈입니다. 소프트웨어 업계에 종사하고 있는 사람이라면 항상 새로운 아이디어에 대해서 고민하기 마련입니다. 하지만, 좋은 아이디어를 내면 "네가 한번 만들어봐"라고 하는 경우가 많습니다. 또는 "뜬구름 잡고 있네"라고 하는 경.. 더보기
SW개발과 Teamwork, 그리고 Review 거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다. 그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다. 하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다. 이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 .. 더보기
우리는 다르다. "우리는 다르다" "우리는 너무 바빠서 문서를 쓸 시간이 없다." "우리는 고객이 요구사항을 너무 자주 바꿔서 스펙을 작성할 필요가 없다." "우리가 개발하는 시스템의 업무는 너무 복잡해서 문서로 만들 수도 없고 개발자도 몇 년 일해야 제대로 일할 수 있다." "우리 고객은 문제가 생기면 당장 고쳐주지 않으면 큰일 난다." "우리의 기술은 너무 어려워서 설명할 수가 없다." "우리 소스코드는 너무 중요해서 아무에게도 보여 줄 수 없다." "우리 제품의 시장은 너무 경쟁이 치열해서 고객이 원하는 것은 다 들어 줘야 한다." "우리 프로젝트는 항상 너무 촉박해서 제대로 된 프로세스를 밟을 수 없다." "우리는 도저히 리뷰할 시간이 없다." "우리는 프로젝트 기간이 항상 너무 짧아서 테스트는 대충하고 출시해야.. 더보기
Peer review의 혜택 "Peer review를 해야 하는데 바빠서 못하고 있다"라는 말을 종종 듣게 됩니다. 이 말을 들으면 Peer review를 해야 한다는 필요성을 사실은 알지 못하고 있다는 것을 알게 됩니다. 다들 Peer review를 해야 한다고 하니까 거기서 Peer review를 할 필요 없다고 하면 혼자 이상한 사람이 되니까 그냥 그렇게 얘기를 하는 것이지요. 정도는 다르지만 소프트웨어를 개발하고 있다면 기본적으로 Peer review는 꼭 필요합니다. Peer review의 기본적인 2가지 목적은 다음과 같습니다. 1. 결함의 발견 2. 정보의 공유 Peer review를 말하면 Code review를 먼저 생각하는 사람들이 많은데, 사실 Code보다도 문서 Review가 더 필요합니다. 그 중에서도 스펙(.. 더보기
개발자 여러분~ 문서 만들기 싫죠? 흔히들 소프트웨어를 개발하는데 문서를 만드느라고 시간이 더 오래 걸린다고 생각합니다. 문서가 필요한 것은 알고 있는데, 만들기는 싫다고들 합니다. 이러한 생각을 깨기 전에는 문서의 필요성에 대해서 이해하기가 어렵습니다. 소프트웨어를 개발하는데 문서를 만들어서 더 오래 걸렸다면 잘못된 것입니다. 필요도 없는 문서를 잔뜩 만들고 있거나, 문서를 작성하는 실력이 없어서 낑낑대고 시간만 잡아먹는 경우 일겁니다. 두번째 경우야 그러면서 실력이 늘 수도 있지만, 필요 없는 문서를 잔뜩 만들고 있다면 정말 헛고생하고 있는 겁니다. 문서를 만드는 이유는 소프트웨어를 더 빨리 만들기 위해서 입니다. 거꾸로 문서도 안 만들고 어떻게 더 빨리 만들 수 있냐고 반문하고 싶습니다. 모든 내용을 머리 속으로 모두 기억하고 있다?.. 더보기
이 정도도 안되면서 Peer Review를 한다고요? 소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다. 개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은 배워서 무엇 하겠습니까? 그래서 히딩크가 강조한 것이 기초체력이지요. Peer Review를 정상적으로 진행하려면 최소한 소스코드관리시스템과 버그관리시스템은 제대로 사용하고 있어야 하며, 스펙과 설계문서를 제대로 만들어야 하며, 코딩 컨벤션을 따라서 개발을 .. 더보기
Peer Review의 방해꾼들 Peer Review가 정말 중요하다고들 다들 생각할 것 같지만, 실상은 그렇지 않습니다. Peer Review의 중요성을 알고 있는 사람은 정말 많은 경험과 깨달음을 얻은 사람이고 대부분은 Peer Review의 중요성을 모르거나 심지어는 노골적으로 또는 은연 중에 방해를 합니다. Peer Review는 (이미 언급했지만), 소프트웨어의 결함을 줄이고 개발 비용과 시간을 절약하며, 개발자들 간의 정보와 지식을 공유하고, 개발자들을 성장시키며, 개발자들의 사기를 높여줍니다. 그런데, 결함을 줄이고, 비용과 시간을 절약하며, 지식을 공유하는 것을 싫어하는 개발자들이 의외로 꽤 많습니다. 공유를 통해서 자신만 알고 있는 지식이 빠져나가면 자신의 가치가 줄어들 것으로 생각하며 심각한 버그를 만들어서 자신만이 .. 더보기