소프트웨어 스타트업의 두 가지 필수 요소를 꼽으라면 좋은 아이디어와 뛰어난 개발자이다. 개발자가 스스로 창업을 하기도 하지만 좋은 아이디어를 가지고 개발자 파트너를 물색하기도 하고 본인이 개발자라고 하더라도 추가로 개발자 파트너를 찾기도 한다. 좋은 개발자는 스타트업의 성공의 중요한 열쇠이지만 구하기 쉽지 않다. 또한, 어떠한 개발자가 스타트업에 꼭 필요한 개발자인지 판단하기 어렵다. 실력이 뛰어나 보이지만 막상 일을 그르치는
필자는 많은 스타트업을 만날 기회가 있고 가끔은 스타트업 파운더가 우리 회사를 찾아와서 도움을 요청하기도 한다. 처음 만나면 먼저 회사의 전략이 무엇인지 물어보는데 여러가지 일이 벌어진다. 대부분은 파운더들이 자신들의 전략을 제대로 설명하지 못한다. 한참을 들어도 무슨 말인지 잘 이해가 안 되는 경우가 많고 이해가 살짝 되도 “이거 되겠는데”라는 생각이 바로 안 든다. 이런 경우는 제대로 된
대부분의 소프트웨어는 수명에서 수백명, 많게는 수천명이 같이 개발한다. 그래서 효과적으로 일을 나눠서 개발할 수 있어야 한다. 심지어는 혼자서 개발을 할 때도 일을 쪼개야 한다. 왜 일은 쪼개야 하고 어떻게 쪼개야 하는것일까? 대부분의 다른 산업 분야는 일을 잘 쪼깬다. 시계하나를 개발해도 각 부품을 따로 개발해서 조립한다. 따로 개발하기 전에 이미 어떻게 연결이 되는지 인터페이스를 완벽하게 정의하고
요즘 하루를 애니팡 하트를 받는 것으로 시작한다. 조용했던 내 카카오톡은 애니팡 하트를 받는 메시지로 가득 찼다. 최근에 가장 Hot한 게임이 애니팡이고 많은 사람들이 그 성공 스토리에 관심을 가지고 있다. 그러면서 자신도 그런 성공을 할 수 있을까 생각을 하기도 한다. 마크주커버그는 19살에 Facebook을 설립했고, 빌게이츠도 20살에 마이크로소프트를 만들었다. 스티브잡스는 21살에 Apple사를 설립했다. 레리페이지가 Google을 만들었을 때의
소프트웨어를 국제화해야 하기 위해서는 고려해야 할 것이 한두가지가 아니다. 그런데 많은 회사들은 메시지나 번역하면 되는 것으로 안다. 그렇게 쉽게 접근하다가는 해외 진출을 하면할 수록 문제가 커지고 비용이 늘어서 점점 어려워진다. 실제 만나본 거의 대부분의 회사가 국제화를 제대로 적용하지 못해서 낭패를 보고나 해외에서 크게 실패를 하였다. 비효율성이 높고 문제가 많아도 제품의 크기가 작거나 고객수가 적다면 그럭저럭
소프트웨어 공학이라는 용어는 사용하기가 상당히 꺼려진다. 소프트웨어 공학이라는 용어를 듣는 사람들이 많은 오해를 하기 때문이다. 일단 듣는 순간 거부감을 가지는 사람들도 상당히 많다. 소프트웨어 공학이 무엇인지 사람마다 서로 다르게 생각하고 있다. 그럼 스스로 소프트웨어 공학을 어떻게 생각하고 있는지 골라보자. 소프트웨어 공학이란? 소프트웨어를 체계적으로 개발하기 위한 방법이다. 고객이 만족하는 소프트웨어를 개발하는 방법이다. 소프트웨어를 여러 사람이 효과적으로 개발하기 위한
우리나라 소프트웨어 회사들의 가장 큰 취약점 하나만 꼽으라고 하면 나는 개발문화를 꼽겠다. 문화란 오랫동안 습득된 구성원들의 공통된 행동 양식이기 때문에 개인이 전체의 문화를 짧은 시간에 바꾸기가 매우 어렵다. 특히 조직이 크면 클수록 문화를 바꾸는데 엄청난 시간과 비용이 필요하다. 하지만 개발문화의 개선 없이는 소프트웨어 개발 역량을 얘기하기가 어렵다. 소프트웨어 개발은 너무 복잡하기 때문에 획일화된 프로세스대로 따라
우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다. 예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤
회의를 하면서 회의록을 작성하는 문화를 가지고 있는 회사들이 매우 많다. 회의록을 아예 작성하지 않는 회사도 있고, 작성을 해도 전혀 뒷처리가 안되는 회사도 있다. 회의는 회사의 가장 중요한 업무 중 하나이며 중요한 결정을 하고 부서간의 의견을 조정하고 업무를 나누고 서로 협업을 하기 위한 수단이다. 그런데 회의는 회의대로 진행하고 후속 조치를 제대로 하지 않는다면 반쪽 짜리 회의가
그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까? 첫째, 경영자 의식의 변화이다. 경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수