“XX, 뽑아놓으니 졸라 못하잖아!”

앞의 두 글의 이후 글입니다.

요즘 기업들이 이런 소리 합니다. “뽑을 개발자가 없다.”

기업들이 이런 소리 하는 거 공감합니다. 실제로 이력서에 적어놓 것과 전혀 다르게 진짜 기술 딸리는 개발자들도 많이 있습니다.

프로젝트는 혼자 하는 게 아닙니다. 특정 인원들이 모여서 하죠. 그 중에서도 기술자가 상, 중, 하 등 여러 실력을 가진 기술자들이 있습니다. 혼자 일당백으로 미친듯이 하는 거 아니면 왠만해선 무리입니다. 돈 오가는 곳들은 더더욱 그렇죠. 뭐, 그렇다 보니 동일한 프로젝트를 한 개발자라 해도 차이가 나게 되어 있습니다. 그걸 소스코드나 기술 보고서 등으로 어떤 개발을 했는지를 알아서 어떤 수준의 개발자인지를 알려고 하는 겁니다. 그래야 그에 맞는 일을 시킬 수 있는 거죠.

근데 한국은 좀 특이합니다. “이왕이면 다홍치마”라는 말을 당장이라도 금지어로 만들어야 하는 특별법을 제창하자고 하고 싶을 정도로 여러 경력을 가진 사람을 좋아합니다. (문제는 돈은 그렇게 안준다는 거. 그래서 없애야 한다는 거!) 이력서에 한 줄 더 들어가있는, 뭐라도 좀 더 해본 그런 개발자를 선호하죠. 그래서 뽑아보니 각각의 프로젝트가 전부 주니어급에서 멈춘 개발자를 뽑았다. 같은 현상 자주 생깁니다. 학생의 경우에는 뭐 경진대회 나간 경력이 있었는데 까고보니 별거 없는 코드만 양산했던 친구였다라던가 하는 그런 경우죠. 팀플했는데 이름만 걸쳐졌다 이런 수준도 있고요.

해당 기업의 개발 팀장 입장에서는 뽑아놓으니 그런 개발자였다 그러면 미친듯이 속이 탈 겁니다. 그 차이는 기존의 개발자들이 매워줘야 합니다. 그래도 안되면 팀장인데도 불구하고 현업 시니어들과 같은 수준으로 미친듯이 코딩하는 팀장이 나오게 되는 현상까지 벌어지죠. (왠지 이 부분은 논란 좀 많이 생길 이야기 같은데… 팀장의 역할이라는 건 코딩 외에도 좀 따로 있습니다. 나중에 좀 자세히 적겠습니다.)

회사 입장에서는 미친듯이 사기당하는 기분일 겁니다. 당연히 그 개발자한테는 말 안하죠. 정말 회사에서 개발 한번도 안해본 갓 졸업한 학생이라던가 하면 모를까 현업에서 몇 년 뛰었다고 하는 개발자가 그러면…

아마 글 읽고 상상만 해도 소름 돋는 분들 있을 겁니다. 그게 본인이 될지 본인 주변에 이런 개발자가 있었다가 될지는 모르겠지만…

괜히 기업들이 알고리즘 테스트나 깃헙 보려고 하는 게 아니라는 것 정도는 좀 제대로 알았으면 합니다.

Advertisements

“공개 못해요.”

앞의 글의 연속 시리즈다.

가끔 보면 소스코드 공개 여부에 엄청 애매한 것들이 있다.

바로 “돈 받고 진행한 코드”들이 이런데, 한국식 인사 채용 시스템에서는 이런 거 없이 전부 공개하라고 하는 이상한 환경 또한 존재한다. (아직 내가 세상 좀 덜봐서 그런지 모르겠는데 지금 내가 미국, 일본, 독일, 네델란드, 스웨덴, 싱가포르 회사에 이력서랑 Tech repo 낸 곳 중에 소스코드 전부 공개하란 곳은 아직 단 한곳도 못봤다. 그래서 한국식 인사 채용 시스템이라고 하겠다.)

20171231_131427

규링같은 경우에는 GitBlit이라는 설치형 git 서버를 이용하여 버전 관리를 따로 한다. 게다가 모든 프로젝트가 프라이빗이다. 가끔 그냥 공개로 올리자고 싶은 것들만 github에 같이 올리곤 한다. 근데 아마 이 블로그에도 올릴 것이다.

이 중에는 계약서 작성하여 진행한 프로젝트도 있고, 당연히 계약서에서는 “이 프로젝트의 소스코드는 공개하지 않겠다.”라는 조건 또한 들어있는 코드들도 있다. 이거 털어가려면 규링 집에 들어와서 규링 죽이고 하드 빼가는 게 제일 빠를 것이다. 괜히 규링이 개인집에 방화벽 따로 쓰는 게 아니다.

특히 학생때 돈받고 하는 프로젝트 중에서 “이 소스코드를 다른 곳에 유출 및 공개하지 않겠습니다.” 라는 계약서에 써있는 내용 이행을 충실히 하는 친구들은 아마 100% 소프트웨어 마에스트로를 비롯한 각종 장학금 받고 진행하는 프로그램에 떨어졌을 것이다. 뭐, 다른 프로젝트 낼 게 많아서 합격한 친구들도 있다고 보겠다만 그런 거 없이 진짜로 돈받고 프리랜서 수준으로 하던 친구들 중에 소스코드 못내서 떨어진 친구들 무지 많을꺼라 본다. 나도 그랬으니깐. (근데 이미 프리랜서 할 친구들이면 이런 거 할 이유가 없다만 난 좋은 멘토한테 해보는 거 어떻냐고 추천받아서 해봤다.) 난 진짜 소프트웨어 마에스트로의 일부 멘토한테 정말 경악했다. (물론 좋은 멘토도 있다.) 돈 받고 개발한 소스코드를 왜 자기들이 봐야 한다고 하는지 진짜 놀랐고, 그들은 그 코드가 없으면 무조건 탈락시킨다고 했었다. 그리고 그걸 엄청 당연시했다. 상업적으로 몇만 곳에서 돌아가는 코드고, 고객의 특허 시스템을 갖다 붙인 코드들이다. 그걸 간단히 내놓으라고 하는 그 정신머리를 이해할 수 없었다.  소마 진행하는 뭐 좀 높아보이는 분이 나한테 와서 그거 꼭 공개 못하겠냐고 하니 내가 “그사람과 계약에서 이미 그렇게 한 건데 그걸 왜 제 3자가 봐야 하느냐. 정 보고싶다면 그 회사 변호사랑 이야기하겠다.” 라고 하니 뭐 할 말도 없는지 그냥 갔다만… 여기만한 비슷한 집단을 다른 곳에서 더 봐서 이젠 그냥 그러려니 중이다.

기존에 경력 있던 분들은 뭐 재직증명서 하나면 다 끝날 이야기다. 나도 그런 회사들 몇 몇 있어서 그런 곳들은 그냥 재직증명서로 퉁쳤다. 해당 회사 홈페이지 들어가서 어떤 솔루션인지 확인하고 포트폴리오나 테크 문서 내용하고 비교해서 어떤 건지 알기만 하면 될테니깐. (이래도 안믿는 새끼들 있다. )근데 이게 학생 개발자들한테는 안통한다. 뭐랄까. 틈새망..? 진짜 허점이다.

“부정경쟁방지 및 영업비밀보호에 관한 법률”이라는 것이 지들한테 당하면 졸라 욕하고 지들이 좀 위치 높으면 법따위는 무시해도 되는건가? 그래놓고 지들이랑 유사하지만 전혀 다른 시스템으로 구축되어 있으면 그거에 대해서 “베꼈다”만 외치다가 회사 문 닫는 꼬락서니 펼치려고?

회사들이 실력 좋은 개발자를 뽑고싶고, 이를 알기위해서 소스코드 보고싶어 하는 건 안다. 근데 이게 좀 도를 지나치는 인간들이 있다. 그런 부분은 솔직히 좀 욕하고 싶다.

“당신의 소스코드를 공개하세요.”

“당신의 소스코드를 공개하세요.”

“당신의 Github를 공개하세요.”

취업 시즌때 한번 싹 지나고 나면 한번씩 나오는 이야기 중 하나 같다. 지원자가 github 주소를 줘서 확인했는데 뭐 제대로 된 거 하나도 없는 주소라서 깠고, 남의 소스 포크해서 자기 껄로 채워넣기 바빴다고 해서 까고….

포트폴리오 달라고 하면 문서만 달랑 주고 소스코드 안줬다고 소스코드 달라고 난리치고 하는…

당연히 이번 취업시즌때도 엄청 나온 이야기라고 한다. 그러다보니 뭐 이런 저런 사고 터지고 하는 일들 허다했을 거다.

우리가 흔히 아는 그룹 기업에서도 저렇게 소스코드 내놓으라 뭐라 하는지는 모르겠지만, IT만을 전문적으로 하는 회사에서 개발자 뽑을 때에 저런 소리 꼭 나온다. 작성한 소스코드를 보여달라거나 github를 보여달라거나.. 어느쪽이던 그 사람의 소스코드를 보고 어떤 실력을 가지고 있는지 판단하기 위해서 이용하는 것이다. 제일 확실한 방법이다.

학생들과 프로그래머 지원자들은 잘 모르겠지만, 특히 신입일수록… 알고리즘 테스트나 코딩 테스트를 하면 회사쪽에서는 95%의 쭉쩡이 개발자들을 걸러낼 수 있다. (이들을 가지고 개발자라고도 하지도 않지만… 좋게 불러줘야 코더, 나쁘게 부르면 코드몽키(영미권에서 단순한 수준의 코드만 양산해내는 개발자를 뜻하는 용어)라고 한다. 그러나 둘 다 같은 뜻이지만…) 그 다음으로 쭉정이를 걸러낼 수 있는 것이 바로 소스코드를 직접 보는 것이다.

근데 여기서 github를 보는 것과 그냥 소스를 보는 것에는 큰 차이가 있다. 이에 접근하기 위한 과정을 알 수 있다는 점에서는 버전관리된 github가 훨씬 더 유용하다. 개발을 하면서 특정 디자인 패턴을 이용해서 개발을 하였는데, 자기가 쓴 디자인 패턴이 어떤 패턴인지도 모르고 그냥 막 갖다쓴 거랑 제대로 알고 쓴 거랑의 차이를 알 수 있는 것이 바로 소스코드와 change log다. 어떤 과정을 이용했는지 잊어버리지 않기 위해서라도 변경 로그를 남기게 되어 있다. 근데 그런 부분이 빠져있다면? 게다가 주석조차 없다면? 아마 면접때 질문 던지면 바로 “모릅니다.” 크리티컬 뜰 꺼다.

자기 코드를 얼마나 소중히 작성하였는지도 여기서 알 수 있다. 그냥 막 짜는 개발자 치고, 버전 관리 잘 하는 개발자 없다. 대학원에서 조교를 할 때, 학부에 과제를 github로 제출하도록 해본 적이 있다. 제대로 알고 쓴 학생은 35명 중 6명이었다. 이 친구들은 원래 잘했고, git이 몰랐던 친구는 뭐 좀 제대로 찾아보면 금방 따라할 수 있는 내용 가지고 금방 따라해서 적용해봤다. 이들은 앞으로도 잘할 친구들이다.

그 외에는 그냥 커밋 메시지에 0,1,2,.. 숫자로만 적은 친구도 있었고, 과제 제출 하루 전에 git 생성해서 첫 커밋하고는 오류 수정하는 데 두번째 커밋하고 올리고 땡하는 친구들도 많다. “그런 거 못들었어요.” 같은 친구가 C를 초과해서 받은 적은 없었으니 그런 부류는 제외하고… 학교다보니 그냥 “과제 제출”이라는 거에만 맞춰서 대충 구색 갖추고 해서 그런지 아니면 우리 교수 수업이 재미 없었는지는 몰라도 정말 대충하는 친구들이 많았다.

그리고 github가 하도 많은 양의 프로젝트들이 올라와서 그런지 뭔가 자기가 알고싶었던 것이나 자기가 과제에 참고하려고 이미 만들어진 프로젝트를 fork 하는 친구들 엄청 많다. 자기는 레포 하나 만들어서 뭐 하나 제대로 해본 건 없으면서 그런 식으로 남의 프로젝트 포크하는 건 대체…

프로젝트 포크를 하면 “내가 이 프로젝트의 현재 버전을 내 입맛대로 수정해서 쓰겠다”라는 의미다. 그러니 포크만 하고 아무것도 안한 프로젝트만 산더미처럼 쌓였다는 건 포크라는 걸 모르는 거다. 즐겨찾기 하듯 해봤는데 내 저장소로 복사되더라. 편하네? 같은 수준이다.

당신이 위에 적은 이런 저런 분류에 속하는 상황에서 당신의 소스, 당신의 github를 받은 기술 담당자는 무슨 생각이 들까?

그들은 다행이도 나머지 쭉정이 걸러 낸 거다.

만약 억울하다면? 당신이 평소에 어떤 맘으로 프로그래밍에 임했는지를, 어떠한 관심을 가진 프로젝트들을 해봤는지를 여실히 보여주는 걸 안했을 뿐이다.  그에 비할만한 걸 갖춰서 도전해봐라.

졸업논문 쓰는 와중에도 이런 이야기가 엄청 나와서 한번 적어봤다.