요즘은 개발자라 하면 다양한 직군들이 많이 존재 하는 시대 입니다만, 이전만 해도 C 나 C++ 로 개발 하는 것들이 많았고, 심지어 제 경우엔 그때 남들 다 쓰는 언어만 쓰면 재미 없다고 소시적 부터 쓰던 pascal 을 함께 병행 하기도 했습니다. 물론 inline assembler 를 즐겨 쓰는 이상한 취미 때문에 사용이 편이한 Borland 류를 더 쓴 것도 있습니다만..
개발자로서 십수년 일을 해 오면서 무엇이 좋은것인가, 나쁜것 인가를 아직도 잣대를 대어 나누기는 힘들지만, 적어도 '이것은 최악이다' 를 격어 본 입장에서 '최소 이런 것들은 피하자' 라는걸 공유 하고자 글을 써 봅니다.
회사에 들어 가면 처음엔 당연 아무것도 모릅니다.
경력직이던 신입이던, 처음 회사 들어 가면 그 조직 또는 팀에서 어떻게 개발을 하는지 알 턱이 없습니다. 다만 오랜 경력직은 빠르겐 몇분 안에 사태를 파악 할 테고, 신입은 길게는 일년이 지나도록 이게 뭐가 좋고 나쁜지 모르고 있을지도 모르겠습니다만 ... 최소 이런것들은 나쁜 것 이다라고 판단 하는 기준을 알아 가면 좋을 것 이라 믿어 의심치 않습니다.
혹시 회사 홈페이지도 없거나, 자사 이메일 주소가 없는가?
이런 개념 없는 회사는 일단 입사 조차 하지 말아야 하겠습니다. 집에서 혼자 일 해도 자기 회사 홈페이지, 이메일 주소 하나라도 가지는게 사업을 하겠다는 사람의 최소 자세가 아닐까요? 자기 도메인 이름과 렌탈 호스팅 이라도 받아 홈페이지 돌린다면 한달 만원도 안 하는 돈으로 구글에서 회사 도메인으로 메일 계정 파는게 어려운 일이 아닌 세상 입니다. 심지어 직접 메일 서버 돌리는 위험을 피할수도 있고, 오히려 유지 보수 하는데 돈도 적게 드는데다, 구글 드라이브 지원도 해 주고 하는데 이걸 몰라서 안 쓰는것도 모르지만 이게 좋은지 모르는 것도 큰 문제 입니다. 요즘 세상에 이런것도 안 하고 있다면 뭔가 개발을 하겠다는 회사의 존재가치로 그 의미가 어디에 있는지 의심을 해 봐야 할 것 입니다.
회사 사장 또는 대표가 개발을 직접 하겠다 나서는가?
이건 회사 사정 마다 다르겠지만, 명확히는 사장이나 대표로 있는 사람은 개발을 하라고 앉아 있는 위치가 아닙니다. 영업을 하고 회사에 각 위치에 있는 사람들을 관리하고 힘을 낼 수 있도록 관리를 해야 하는 자리 입니다. 심지어 자기가 제품을 제일 잘 안다면 설치며 오지랖이라도 떤다면 정말 그곳을 피하라 조언을 해 주고 싶습니다. 혼자 제품 다 만들지도 못할 양반들이 자기가 다 한다고 설치고 다니는건 큰 오만이며 결국 자신이 만든건 어디다 쓰기도 부끄러운게 나오는게 분명 할 겁니다. 결국 팀이나 회사 분위기 망치기만 하는걸 모르는 경우도 있으며, 심지어 자신이 그런 결과를 만들고 있는걸 모르는걸 물론, 다른 이유와 핑계를 타인으로 돌리며 자기 방어 하나는 확실히 할 겁니다. 이런 회사는 그냥 사장이나 대표에 있는 사람 혼자 제품 다 만들면 되는데 왜 직원을 필요로 하는지 의문을 가져야 할 곳 입니다. 즉, 내가 있을 필요가 없는 곳이니 회사에 나가는 의미가 없다 봐야 겠습니다.
내가 해 봐서 아는데...
진짜 어디서 많이 들어 본 대사 입니다. 쉽게 死대강 만든 어느 전직 대통령 떠올려 보시면 됩니다. 위에 있는 양반들이나 함꼐 일 하는 사람이 저딴 소리나 하며 '노오력' 드립치면서 정작 나에게 무얼 가르쳐 주기나 하는것도 없이 대사나 읊어 대고 있으면 당장 짐 싸서 적어도 뭔가 배울데 있는 곳으로 가는게 나의 시간과 값어치를 올릴 수 있는 기회를 찾을 수 있는 경우가 높아 집니다. 이런 부류의 존재들이 결국 뭔가를 만들어 낸다고 하면 결국 어느 전직대통령이 이룬 업적들 하고 같은 수준이 됩니다. 그냥 이런 부류는 딱 그런 부류들 입니다.
그냥 해 ! 또는 어쩔수 없다 ?
간단 합니다. 강압적 이거나, 어쩔수 없다라고 하며 본인이 모르니 남 이야길 들을 마음이 없어 내 맘대로 따라 해라 입니다. 둘 다 같습니다. 본인의 모자람을 받아 들이지 못하거나, 타인의 이야기를 듣지 않는 사람이 있는 회사에서 무슨 협업을 해서 함께 제품을 만들까요. 일부 공장 같은데서나 정해진 형태로만 뭘 만들거나 하는데선 저런게 더러 먹히는 경우를 봤습니다만 그런데 다니고 싶은 마음 아니면 이런 분위기가 있다면 피하는게 정석 입니다.
야근 많이 하면 일 많이 한 거다?
2000년 초만 해도 이런 곳이 많았는데 2010년이 넘은 지금도 이런곳이 많습니다. 오랜 시간 앉아 있으면 자동으로 프로그래밍이 막 되고 하는 시스템을 가진 곳이 세상 어디에 있으면 맞는 말 일지 모르겠습니다만, 인간이 하루에 집중 할 수 있는 시간은 보기보다 길지 않습니다. 제 경험으로 보통 저런 마인드를 가진 사람들은 회사에 있는 동안 반 이상을 딴 짓을 하다가 저녁 먹고 들어와 만화 좀 보다 퇴근 전 까지 두 세 시간 일 좀 합니다. 여러 이유가 있겠지만 이런 분위기를 가진 회사에선 어떤 창의적이거나 효율적인 작업이 진행 되지 않습니다. '나도 대충 저렇게 살다 회사 짤려야지' 란 생각으로 동참 하실거 아니면 어서 좀 더 제대로 일 하는 곳을 찾아 봐야 할 겁니다.
혹시 각 팀원이 소스를 자신의 컴퓨터에만 보관 하는가?
혹시 이러고들 있는 회사에 다닌다면 당장 짐을 싸서 나오던지, 아니면 팀장이나 높은 사람이 되어 소스관리 시스템을 도입 하던지 양자 택일 하기 바랍니다. 이런 회사들 대표적 특징이 이런것들이 많습니다.
- 내가 짠 소스는 내 것이다
헛소리 입니다, 회사에서 짠 소스는 회사의 것 입니다. 책임이 나에게 있는 것일 뿐이죠.
그리고 프로젝트가 커질수록 혼자 하는게 아니라 여러명이 합심하여 함께 일 하는게 현명합니다. - 소스를 압축 파일로 분리해서 잘 보관 하므로 문제 없다.
혹시 랜섬웨어 같은거 걸려서 다 날려 보면 그 생각이 얼마나 터무니 없는지 알게 되겠죠. - 오픈소스? 그냥 배끼기 좋은거 아닌가?
그리고 그걸 배껴 만들다가 나중에 털리면 아주 신나겠죠?
대부분의 오픈소스에 라이센스가 있는걸 알고 나면 이런 위험한 생각은 접게 될 겁니다. - 이건 우리들 문화다 !
문화같은 사운드 하고 있는 겁니다.
단체로 멍청함도 문화라고 주장하면 할말은 없겠습니다만...
대부분 이런 느낌이 많이 든다면 그냥 여긴 블랙 회사 라고 생각하고 뭔가 할 생각을 접고 빨리 나오는게 좋습니다. 세상에 협업을 할 수 있는 시스템이 얼마나 많고, 네트웍이 초고속으로 깔린 2016년에 이런 마인드로 아직 개발 하는 곳이 있다면 그 똥맛이 가득한 MFC 4.0 써야 하는 Visual Studio 6.0 쓰던 시절 마인드라 하겠습니다.
세상엔 개발자가 알아가기에 너무나 많은 것들이 깔려 있습니다. POSIX 관련 분야만 알아 가도 참 배워야 할게 많구나 하는 세상인데 저런 분위기의 회사들은 누군가 혼자 소스 말아 먹으면 그 프로젝트는 그냥 접히는 무서운 동네가 됩니다. 게다가 2명 이상이 함께 일 하면 가장 높은 사람이 자기가 다 만든걸로 퉁 치기 좋고 혼자 포상 받고 혼자 잘났다 하기 좋은 환경이 됩니다.
아니면 먼지(merge) 하는 사람이 남과 나의 소스를 관리 하는가?
이건 위의 '혹시 각 팀원이 소스를 자신의 컴퓨터에만 보관 하는가?' 와 같은 겁니다. 그냥 소스를 다른 사람이 한명 더 가지고 있다는 거 말고는 다를거도 없고, 이건 소스를 합치는 양반이 천재가 아니고서는 또 다른 위협이 발생 하는건 물론 이거니와, 결국 갈색 똥인가 검은색 똥인가? 차이 입니다. 그리고 이런 머지는 개발능력이 없거나 모자란 사람이 윗 사람이 되어 자신이 결국 모든걸 독식 하겠다! 라고 하는 경우 자행 하는데 가나다 도 모르는 양반이 남이 짠 소스를 막 합치고 하면 그게 제대로 될까요?
위 두가지를 피하려면? 무얼 하는가?
보통 협업이란건 여러명이 하나의 프로젝트를 수행 하는걸 말 합니다. 프로젝트에 따라 다르겠지만 디자이너도 한명 있고, 개발자도 두명 이상 있을 테고, 모든걸 통괄하는 매니저도 한명쯤 있을 테고 ... (아님 겸직 한다던가) 할텐데 .. 이들이게 중요 한 것은 이걸 통괄적으로 서로 다 볼 수 있고, 자동으로 합쳐 주고, 누군가가 말아 먹으면 다시 이전으로 언제든지 롤백 (roll back) 할 수 있는 좋은 시스템이 많다는 것 입니다.
게다가 이런 기능에 각 팀원 또는 담당자에게 무얼 해야 하는지 웹으로 사용하기 쉽게 해야 할 일을 지정하고, 어떻게 굴러 가는지 정리도 해 주는 시스템이 널리고 널린데다, 소규모 일 경우 무려 공짜 이기도 합니다.
인터넷으로 쓸만한 프로그램 없나? 또는 유용하다고 받아 보다가 이런 싸이트 한번은 들어가 본 적 있을 겁니다.
많은 소프트웨어들이 이곳 SourceForge 에서 만들어 지고, 이곳에서 한 프로젝트당 최대 수백명이 함께 작업을 하는 것도 있을 정도로 큰 동네라 하겠습니다. 물론 단점이라면 이런 곳에서 회사가 공개가 안되어야 할 걸 만들 일은 없겠지만, 이런 형태가 최소의 협업의 기본 조건이 됩니다. 각 프로젝트 당 소스 관리는 물론, 각 개별 작업자가 무얼 해야 하는지는 물론 WiKi 로 정보를 만들어 갈 수도 있고 합니다.
게다가 위의 gitHub 도 많이들 보거나 접해 보았을 것 입니다. SourceForge 와 달리 공개를 하지 않을 수 있는 프로젝트 등을 만들수 있고, 큰 돈 없이 회사에서 서버 비싸게 유지 보수 할 필요 없이 여기에다가 모든걸 이용해서 프로젝트 만들어 나가는게 가능 합니다.
그런데 회사가 너무 열악하고, 팀원도 꼴랑 2,3 명 뿐이라면 저처럼 Bitbucket 을 이용 할 수 도 있습니다. 물론 회사에 대표직에 있는 사람이 한달에 5 USD 도 아깝다고 이런거 필요 없다고 하는 저의 불우한 환경에도 전 이걸 쓰고 있긴 합니다만.
개인적으로 Bitbucket 을 5명 이하의 기업에서 운용 해서 프로젝트를 구동 한다면 정말 효과적인 결과를 얻을 수 있습니다. 지원되는 소스관리 형태도 git 나 mercurial 을 지원 합니다. (둘의 차이는 여기서 보실 수 있습니다) 자체적인 https 를 기본으로 지원 함 은 물론, 프로젝트나, 팀원간 조율도 편리 하며 5명 이하는 무료로 무제한의 비공개 프로젝트를 계속 만들고 관리 할 수 있다는 장점이 있습니다.
또한 Issue track, WiKi 개설, 각 릴리즈 판 마다 download 제공 등의 장점들을 모두 가지고 있으므로, 소규모 기업이나 팀이 사용하기엔 이만한 시스템도 없어 보입니다. 심지어 개인이 혼자 쓰기에도 개인적으로 github 보다 낫습니다. 또한 여유가 있다면 JIRA 를 이용할 수 도 있습니다.
이제 위 종류가 아니라면 회사나 팀에 서버를 따로 두고 CVS, SVN, git, Mercurial 등을 직접 관리 하며, REDMINE 이나 TRAC 이나 비싼 JIRA 같은걸 직접 꾸려 쓰며 매번 백업도 하며 관리를 하고는 있어야 합니다. 이런것 조차 없는 회사에서 협업이니, 개발이니 하는건 정말 어리석은 모습이라 하겠습니다.
더 많은 것들 ...
이 외에도 참 많은 것들이 있습니다만, 그걸 다 서술 하면 제가 책을 쓸 수 있을 정도 가 아닐까 합니다만 ... 개발자의 길을 개인으로 걷던, 회사에서 걸어 가던 중요 한 것은 다음 정도 아닐까 합니다.
- 나 자신을 믿지 말라.
내가 작업 하는 컴퓨터가 영원불멸의 존재이고, 어떤 공격이나 악재에도 살아 남을수 있다면 모르겠지만, 그게 아니라면 주기적은 백업은 물론, 소스를 계속 누적해서 merge 및 보관이 되는 최소 SVN 이나 git, mercurial 은 쓰도록 합니다.
저의 경우 소시적 이렇게 소스 말아 먹어서 중단 할 수 밖에 없었던 것들이 더러 있어 정말 중요하게 느끼는 부분 입니다. - 나는 신이 아니다.
가끔 나 자신이 신인거 처럼 느껴 진다면 ... 병원에 가 보시기 바랍니다.
인간은 포유류 이며, 누구나 실수를 하며, 오만에 빠지기 쉬우며, 언제 죽을지 모릅니다.
미래를 또는 타인을 위해서라면 혼자 다 할 생각은 버립니다. - 나 없어도 회사는 돌아 간다.
오만에 빠지면 안되는 것이 이겁니다.
'나 없으면 회사가 안 돌아가' 라는 착각을 하고 있다면 어서 마음을 바로 잡기 바랍니다. 당신이 회사 사장이나 대표가 아니면 그런 헛생각은 빨리 고치는 것이 좋습니다. 나 없어도 대신 할 사람이 생기는 것이 회사 입니다.
혹시 회사에서 '너 없으면 할 사람 없어' 라는 말을 윗 사람이 한다면 이렇게 해석 하세요: '너 만큼 부려 먹기 쉬운 존재가 없어'.
물론 그 만큼 회사에서 대우를 해 주고, 본인이 만족 한다면 상관은 없겠습니다만 ... 대부분은 그렇지 않은게 현실이기도 합니다.
개발자의 길은 멀고 험합니다.
개발자라 해도 각 분야에 따라 하는 형태도 다르고, 생각 하는 형태도 달라 집니다.
안드로이드 앱 개발 하는 사람이 Object C 를 함께 하지 않는 이상 아이폰/아이패드 앱을 개발 하는 개발자와 추구하는 형태와 개발언어 등이 모두 다릅니다. 물론 잘 만들어진 외산 게임엔진은 이런걸 고려 하지 않고도 각 플랫폼간 출시를 편리하게 해 주는 경우가 많긴 합니다만 .. 모든 앱을 그렇게 만들수는 없습니다.
또한 시스템 설계를 하는 개발자는 하드웨어와 OS 자체를 이해 해야 하고, 이의 경우는 상위 앱이나 프로그램 개발과는 또 다른 환경이므로, 이에 따른 생각과 추구되는 형태가 달라 집니다.
어떤 길을 걷던 하나 보단 둘, 둘 보단 셋이 좋을 수 있지만 각 수 마다 깊이를 깊게 파는 것이 좋습니다.
그리고 항상 내가 아는 것이, 내가 하는 것이 최선이다 라는 오만에 빠지지 않도록 계속 자신을 돌아 볼 수 있어야 합니다.
나이에 상관 없이 계속 배워야 하며, 열린 마음으로 계속 발전하는 모습들을 받아 들일 수 있어야 합니다.
그리고 내가 아는 것을 '내 것' 으로만 두는 것이 아니라, 여러 형태로 타인에게도 배풀고 함께 발전 할 수 있는 자세를 가지는 것이 중요 합니다.
앞으로 길면 길 개발자로서의 길을 꾿꾿히 잘 걸어 나갈 수 있길 바라며, 미약한 글로 도움이 되길 바랍니다.
