그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까? 첫째, 경영자 의식의 변화이다. 경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수
소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다. 1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다. 2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다. 3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다. 위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면
우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다. 특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다. 여기 이와 관련된 과거 글이 있다. 2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데 주먹구구식으로 개발을 하다가 현재 체계를 갖추려고
소프트웨어 회사가 경쟁력을 가지려면 전통적인 관리와는 좀 다른 관리 방법이 필요하다. 첫째, 상하관계 탈피이다. 전통적으로 관리자는 윗사람이고 팀원들은 관리자의 지시를 따르고 관리자가 거의 모든 것의 결정권을 가지고 있다. 하지만 소프트웨어 회사에서 관리자는 기술적인 결정을 할 수 없다. 개발자 출신이라고 기술적인 결정도 하려 하는 경우도 있지만, 기술적인 결정은 개발자의 몫이다. 그리고 전사적인 중요한 기술적인 결정은 CTO나
고참은 유지보수를 하고 신참들이 신제품을 개발하는 모습을 어렵지 않게 볼 수 있다. 고참들이 경험도 많고 신제품을 만드는데 더 적임이지만 그럴 수 없는 이유가 있다. 기존 제품의 유지보수에서 도저히 빠져나갈 수 없는 것이 그 한 이유이다. 간단한 업그레이드가 아니고 완전히 새로운 제품을 만들려고 하는 이유도 기존 제품이 유지보수가 너무 복잡하고 기능을 추가하거나 수정하기에 아키텍처가 더이상 감당이
최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다. 비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다. Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서
대한민국 이름을 걸고 해외에서 크게 성공한 Software가 없는 것은 안타까운 일이 아닐 수 없다. 내가 아는 한 그런 Software가 없다. 그런 Software가 있다면 알려주기 바란다. 게임 등 일부 분야에서는 성공 사례가 있지만 일부 특수 분야의 일이다. 그렇게 실패하는 이유는 여러가지가 있겠지만 내가 보는 가장 큰 이유는 소프트웨어를 개발하는 기초 역량이 부족해서이다. 누구는 해외 문화를 이해하지
소프트웨어 개발자의 경력이 제대로 보장 받지 못하는 가장 큰 이유는 회사, 사회, 문화의 문제 때문이다. 그렇다고 개발자 된 입장에서 회사가 바뀌고 사회가 바뀌기만을 기다릴 수는 없다. 이는 마치 닭과 달걀의 관계처럼 누가 먼저인지 알기 어렵다. 어느 한쪽이 먼저 깨끗하게 해결되면 자연스럽게 전체가 해결되지만 그걸 기대하기는 현실적으로 어렵다. 경영자도 회사가 살아남고 경쟁력을 키우기 위해서는 바뀌어야 하지만
소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다. 이 경우 Architecture상의 심각한 문제점을 내포하게 된다. 제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다. Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고,
과거 필자가 근무했던 회사에서는 “백발을 휘날리며 개발을 할 수 있는 개발자”를 공개 채용한 적이 있다. 그 당시 수많은 경력직 개발자들이 지원을 했고 개발자로서 경력을 보장받고자 하는 열망을 충분히 알 수 있었다. 필자의 회사는 Technical career path를 확실하게 보장을 하고 있었다. 따라서 관리를 하지 않고 개발자로서 꾸준히 성장할 수 있고 그렇게 성장할 수 있도록 기업 문화와