이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다. 최근에 국내 유수의 소프트웨어 회사들의 구조조정 회오리를 보면 착찹한 생각이 든다. 척박한 우리나라 소프트웨어 환경에서 참신한 개발문화를 도입하고 새로운 모습을 보여주려고 했던 회사들이어서 더욱 안타깝다. 필자는 이런 현상의 결과와 겉모습만 말고 다른 시각에서 좀 더 근본적인 원인을 살펴보고자 한다. 3D 취급을 받고 있는 국내 소프트웨어
교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다. 이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다. 예전에는 한국의 빌 게이츠를 키워야 한다고 하더니
소프트웨어 회사가 제대로 개발 역량을 갖추는데 최고의 걸림돌은 소프트웨어에 대한 이해가 부족한 경영진이다. 일반 경영자들이 소프트웨어를 이해할 수 없기 때문에 CTO가 존재한다. 하지만 우리나라 대부분의 소프트웨어 회사에는 CTO가 없거나 있다고 하더라도 CTO역할을 하지 않고 있다. 흔히 벌어지는 심각한 문제는 프로젝트 기간 아무때나 요구사항을 변경하고 심지어는 소프트웨어 기획의 방향을 완전히 뒤엎곤 한다. 이로 인해서 소프트웨어 개발에는
소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까? 남이 작성한 SRS를 보면 도움이 될까? 가상으로 한번 써보면 도움이 될까? 케이스별로 얼마나 도움이 될지 알아보자. 1% 스펙을 작성하는 방법을 배우기 위해서 남이 작성한 SRS를 보는 것은 얼마나 도움이 될까? 1%정도 밖에
그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다. 내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까? 그럼 한달동안 안나오면 어떻게 될까? 대부분의 소프트웨어 회사는 한달동안 심지어는 일주일만 직원 몇명이 안나오면 심각한 문제를 일으키곤 한다. 이러한 종속성은 회사에게는 큰 위험이고 개발자에게는 양날의 검이다. 개발자는 본인이 없으면 회사가 잘 안돌아가는 상황을 선호하곤
초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다. 성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다. 고객이
흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자. 투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다. 거의 모든 결정의 과정 및 결과가 공개되고 기록되는 것이다. 이것의 효과는 꽤 대단한다. 이슈관리시스템을 이용하여 모든 정보를 공개하는 것도 좋은 방법이다. 결정해야 할 이슈들을 공개하고 결정 과정이
여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자. 첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다. 테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다.
"거의 다 만들어서 2주후에 개발이 끝나요" 이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다. 개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다. 하지만 이런 대화는 여러 오해를 양산한다. 영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아
일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다. 프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다. 많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서