평일 저녁, 후배들과 이야기를 나누다.

최근 진행하고 있는 프로젝트가 한참 막바지라서 간만에 야근 및 특근을 밥 먹듯이 하고 있습니다. 아마도 제가 블로그에 글을 쓰지 못하는 첫번째, 이유가 이것이 아닐까 한데요.

얼마전에 선배와 이야기해서, 대학 동아리 후배들을 위해, 현업 소개를 하는 시간을 만들었습니다. 개발 일정의 한가운대서 어떻게 시간을 내서 학교로 갔는데요. 변명일 수도 있겠지만, 출퇴근 시간이나 짬 날 때, 휴대폰으로 발표 내용을 만들어서 준비한 발표의 2/3정도 밖에 못하고 왔습니다.

일단, 그 내용을 여기에 올려 놓고, 조금씩 다듬어서 다시 글로 써보려고 합니다.

----
1. 벤처부터 대기업까지 소프트웨어 개발 경험
1.1 벤처기업 : 2008.07 3개월 : 검색엔진 웹 프론트 개발
1.2 중소기업 : 2005.01 9개월 : wipi 플랫폼 개발
1.3 오픈소스 : 2008.03 5개월 : 모인모인 위키 개발
1.4 대기업 : 2009.03 2년 : 휴대폰 usim 모듈 담당 및 시큐리티 담당

2. 나중에 유용하게 쓰이는 것
2.1 전공 수업. PL, Data Structure, Algorithm, Database, OS, Compiler, …
2.1.1 특이한 프로그래밍 언어들을 공부 해보면 좋다. Haskell, Lisp, Python, Erlang, Javascript..
2.1.2 교수님과 친해져 보자. 난 그러지 못해서 아쉬움. 가깝게 여기고 찾아뵙고 물어보고 해야 정말 가까워진다.
2.1.3 쉽다고, 혹은 아는 것 같다고 학교 수업 무시 말고 잘 듣자. 더불어 학점도 잘 받자. 공부의 시작은 겸손이며, 겸손은 앎으로부터 나오고, 자만은 무지로부터 나온다.
2.2 자람이나, 수업에서 발표, 프로젝트
2.2.1 대학교까지는 발표는 선택이었지만, 이후의 삶에서는 발표는 필수이며, 발표 스킬은 평생 동안 활용할 수 있는 무기가 된다. 학회에서 최대한 많은 기회를 가지기 위해서 노력하고, 수업에서도 마찬가지다. 그리고 다양한 발표 기법을 공부하고 실제로 활용해 보자!
2.2.2 Unittest, SVN(or GIT or Mercurial) 등의 도구를 최대한 활용해서 프로젝트를 진행해보라. 현업서도 아직 제대로 쓰고 있지 않지만, 학교에서 적응하고 활용한 경험은 나중에 큰 자산이 된다.
2.2.3 프로젝트를 진행할 때는 활용성에 대해서 항상 생각하고 유용한 프로그램을 만들어야 한다. 가능하면 자신이 직접 사용할 프로그램을 만들어라. 그래야 재미있고, 오랜 기간 진행할 수 있다. 결국 자신의 자산이 된다.
2.3 공모전, 경진대회, 컨퍼런스
2.3.1 공모전 두려워 말고 도전해라. 생각보다 수준이 낮은 경우도 많고, 실패를 통해 배우는 것도 많다. 가능하면 팀을 짜서 도전하고 사람이 없으면 혼자도 괜찮다.
2.3.2 공모전 정보를 얻을 수 있는 사이트들을 참고하여 일정을 잡아보고 하나의 작품으로 여러 공모전을 노릴 수 있는 방법을 생각해 봐라. 소프트웨어 분야는 의외로 중복 출품이 가능하거나 그런 규정이 없는 곳이 많다.
2.3.3 경진대회도 마찬가지다. 실패를 생각 말고 도전부터 해봐라. 그런데 난 경진대회 안 나가봐서 잘 모른다. 스스로 찾아보도록
2.3.4 각종 컨퍼런스들은 대학생 할인 제도들이 존재한다. 저렴하게 고급 경험을 얻을 수 있다. 많이 참여해보고 문제점도 스스로 찾아 봐라.

3. 소프트웨어 개발자로 살아 간다는 것. 여러가지 길
3.1 프로그래머
3.1.1 가장 많이 알고 있는 길, 그리고 인원도 가장 많은 길. 필요한 스킬은 평생 공부할 수 있는 기술. 이를 위해서는 즐겨야 한다. 그리고 즐기기 위해서는 노력을 해야 한다.
3.1.2 나중에 사회에 나가 개발자로 일을 하게 되면, 주변 사람들이 자기 직업을 비관하는 경우를 많이 본다. 프로그래머는 결코 쉬운 길은 아니며, 공부한 지식을 소모하기만 하는 삶을 살게 되면 5년도 안 되어 틀림없이 후회하는 인생을 살게 된다.
3.1.3 후회 없는 프로그래머가 되기 위해서는 끊임 없는 자기 발전과 이를 통해 즐거움을 느껴야 한다.
3.2 품질 엔지니어
3.2.1 잘 모르는 길. 하지만, 현업에서는 프로그래머 다음으로 많은 존재 중 하나.
3.2.2 세부적으로 테스트 엔지니어나 품질 엔지니어, 프로세스 엔지니어 등 다양하게 나뉘며, 소프트웨어의 품질을 높이고 검증하기 위한 다양한 기법들과 지식들을 개발과 유지보수에 적용한다.
3.2.3 개발자중 품질 엔지니어로 가는 경우도 많으며, 소프트웨어 품질에 대한 기업의 관심이 많아지고 있는 최근 들어 더욱 발전하는 추세.
3.3 아키텍처
3.3.1 소프트웨어 설계, 감리 등을 담당하는 업무.
3.3.2 대기업들에는 부분은 아키텍쳐 팀이 따로 존재하며, 많은 인원은 아니다. 프로젝트의 초반에 전체적인 설계를 구상하고, 진행 과정에서 설계를 유지 보수 하면서 프로젝트의 진행을 돕는다.
3.3.3 관련된 다양한 기법들이 존재하나, 소프트웨어 개발 자체가 설계라는 초반 과정이 쉽지 않고, 변경도 많기 때문에 어려움이 많은 분야. 이는 앞으로 발전 가능성도 많은 분야라 볼 수 있다.
3.4 컨설턴트
3.4.1 기업 내부에 컨설팅 팀을 보유하고 있는 경우도 있고, 소프트웨어 컨설팅을 전문으로 하는 업체들도 존재한다.
3.4.2 아키텍처도 일종의 컨설턴트이며, 소프트웨어 개발에서 발생하는 문제점들을 미리 예방하거나 해결하기 위해 도움을 주는 역할을 한다.
3.4.3 다양한 소프트웨어 공학 기법들이나 개발 지식을 활용하여 개발팀이 성공적으로 프로젝트를 마무리 할 수 있도록 돕는 역할.
3.5 프로젝트 매니저
3.5.1 PM은 직종이라기 보다는 직책이지만, 수행을 위해 필요한 지식들이나 업무의 형태를 보면 새로운 직종이라고 봐도 무방
3.5.2 보통 현업(개발이나, 품질, 컨설팅)에서의 경험을 쌓은 후, 맡기 됨. 프로젝트의 처음부터 끝까지 관여하면서 구성원들의 작업을 조율하고, 일정이나 요구사항, 개발목표 등에서부터 구현 방향이나 인원분배등의 문제들까지 다양한 프로젝트 관련 업무를 총괄한다.
3.5.3 처음부터 PM을 하는 것이 아니니 만큼 PM을 위한 지식들을 미리 열심히 공부할 필요는 없지만, 능동적으로 프로젝트에 참여하기 위해서는 스스로가 작은 규모의 PM이란 생각으로 관련 지식을 공부하고 적용해볼 필요가 있다. 여기서 중요한 것은 적용해볼 만한 것들을 공부한다는 것.